1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  09 ,2017

ビジネス、心理、マーケティングを軸にいろいろなニュースや事象を分析します


プロフィール

なおゆき

Author:なおゆき
Web広告代理店でシステムエンジニアをしています。
セルフイメージはProblem Analyzer(問題を分析する人)。

このブログでは、IT を中心に
新ビジネスのニュースや現場でよくある問題について
分析します。

検索フォーム
ブロとも申請フォーム
QRコード
QRコード
--

Category: スポンサー広告

Tags: ---

 

スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

26

Category: 思考法

Tags: ---

Comment: 0  Trackback: 0

【閑話休題】分析の切り口

ベテランと若手の分析力


よくわからないな・・・
ボソッとつぶやいた。

プロジェクトの PM から仕事を請け負った。
若手が抱えている仕事が滞っているのでヘルプに入ってほしいとのこと。
本番環境にリリースしたのだが、障害を起こしたいわくつきの仕事だ。
同じ失敗はできないので、求められる品質は高い。

ブリーフィングで方向性はわかった。
影響分析が6割くらい片付いたところで若手に内容についてヒアリングしたのだが、
どうもシステムの設定と食い違っている。
PM に相談するとすべてが整合性のとれた形でつながった。

そのあと、若手が質問をしてきた。
PM と僕の話を聞いていたが、よくわからなかったらしい。
ついでにテスト仕様書を出させていたのだが、
PM からブリーフィングで言われた作業手順をそのままテスト観点にしていた。
切り口としてはイマイチ。

――テストの前に考え方を教える必要があるな――
僕は一般的な分析の型から説明を始めた。

分析の前に


上記は筆者の実体験です。
実在の人物とすごーく関係があります。

まずはツールを使う前にやることがある。
自分が求められていることが何か、正確に理解すること。
ありがちなのはTOR(BOSCAR)かな。
Background:背景。経緯を含めてまとめる。
Objective:この仕事の目的。達成したいこと。
Scope:スコープ、作業範囲。むしろ、やらないことを明確にする。
後で拾いにいくけど、それは別のお仕事としてやるか、サービスとしてやる。
Constraint:制約事項。期限やお金もそうだけど、物理的に無理なこと、方針的に無理なことを明確にする。何らかの代替案を用意する。
Assumption:仮定、前提。困ったら誰に聞けばいい?とか。
Reports:成果物。ついでにそのイメージ、完成度もすり合わせしておく。

これができたら分析に入る。

分析の6+1の型


分析にはいくつものやり方があるけど、ビジネス系の場合はだいたい6つの型がある。
参考情報はコレ。
1回の会議・打ち合わせで必ず結論を出す技術1回の会議・打ち合わせで必ず結論を出す技術
(2008/06/27)
斎藤 岳

商品詳細を見る


1. 親和図・ベン図
高校数学にトラウマがある人は頭が痛くなるかもしれないけど、
マクロレベルで考えるときにもっとも基本となる型。
そもそも分析の観点・切り口の妥当性を考えるときに使える。
重複があれば MECE なんて言えないしね。

親和図

2. 因果関係図
ミクロ~マクロレベルで分析をする場合にまで使える型。
もっとも万能な型だけど、人に伝えるには複雑になる。

因果関係図

泥沼系なじり貧環境は、ネガティブな事象のループができてることが多い。

3. ロジックツリー
やっと出てきたベタベタな型。
よく、問題分析にも解決にも使えると言われるが、
分析の切り口が正しいことが前提になる。
ある程度モノが見えてきて、分かりやすく整理するときに使える。

ロジックツリー

4. マトリクス(テーブル型)
二つの観点の組合せが重要になるとこれを使う。
SE なんかだとテスト仕様を考えるときに威力を発揮する。
マトリクス(テーブル型)

5. マトリクス(グラフ型)
二つの観点で傾向の変化をとらえたり、あるべきポジションを考えるのに使う。
数学が苦手な人は頭がかゆくなるかも(笑)。
マトリクス(グラフ型)

6. プロセス・フロー
マクロの視点でざっくりとした手順や流れを考えるのに使う。
これをたたき台にして因果関係図を考えることもある。

プロセス・フロー図

で、これに加えてシステムエンジニアやプログラマには「ひも付け」がある。

7. 紐付け

データを例にとると、設定に関する静的なデータと
入出力が頻繁に起こる動的なデータ(注文とかログとか)がある。
一般には、動的なデータの量を少なくするために
静的なデータは必要な分だけ取り入れておき、
あとは静的なデータに寄せておく。
ただし、後から関連性をたどれるようにしておく。これが紐付け。

プログラムを例にとると、
ひな形となるプログラムと実処理をするプログラムがある。
後から実処理の部分を入れ替えられるようにしておく。
その入れ替えを設定ファイルで行うことが多い。
これも一種の紐付け。
紐付け

まとめ


まとめよう。

分析をする前には必ず目的や成果物を明確にする。

ビジネス系の分析には6つの型がある。
1. 親和図
2. 因果関係図
3. ロジック・ツリー
4. マトリクス(テーブル型)
5. マトリクス(グラフ型)
6. プロセス・フロー
とくに3,4,5 は観点の切り口が筋の良し悪しを決めるので注意。
1で検証、代替案として2,6を使用するとよいと思う。

で、エンジニアにはこれらに加えて紐付けがある。
データの関連性やプログラムの柔軟性に一役かっている。
スポンサーサイト

Comments

Leave a Comment

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。