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
31
  07 ,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を使用するとよいと思う。

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

スポンサーサイト

27

Category: 思考法

Tags: ---

Comment: 0  Trackback: 0

ミーティングはうんざり、な貴方に
スケジュールを確認すると、またミーティング・・・
定例、進捗確認、なんだか分からない共有会。
要件レビュー、設計レビュー、テスト仕様レビュー、○○レビューのオンパレード。

出席してみれば、ミーティングのオーナーは準備不足で
こちらの質問の半分くらいしか答えられない。
議論は紛糾、ミーティング内ミーティングがいたる所で始まる。

おいおい、この時間でどれだけの工数が消費されていると思っているんだよ・・・


上記はフィクションです。実在の組織や人物と一切関係ありません。
でも、読者のみなさんは身に覚えがあるので苦笑いをしていることでしょう。

というのも、以下の記事がとてもよかった。
時間の価値は人によって違う!30分が100時間を生む5つの考え方
とくにミーティングは参加者の人数が増えるほどに、工数の消費がバカにならない。
ここはとくに重要だと思う。

例をあげよう。
ぼくが何かのレビューのミーティング・オーナーで
資料の準備に0.5人日かかるとする(ホントはもっと早いけど)。
参加者は8人、1時間かけて行うとしよう
(一日8時間労働を想定)。

パターン1: 一発O.K.(優秀な感じ)
  かかる工数=0.5人日+8×1時間=1.5人日

パターン2: 二回レビュー(ふつうな感じ)
  かかる工数=(0.5人日+8×1時間)×2=3人日

パターン2: 三回レビュー(ダメな感じ)
  かかる工数=(0.5人日+8×1時間)×3=4.5人日

という具合に、資料の準備と思考の精度が甘いと
工数がふくらんでいく。

これに人数が多い部会とかになって
目的意識がうすい発言が相次ぐと実質的に無駄工数になってしまう。
そうなると、もうあの手この手の言い訳を考えて、参加したくなくなる。

自分がミーティング・オーナーの場合に備えて、ぼくが参考にしたのは以下の本だ。
1回の会議・打ち合わせで必ず結論を出す技術1回の会議・打ち合わせで必ず結論を出す技術
(2008/06/27)
斎藤 岳

商品詳細を見る


もっとも参考になったのは GAP を意識すること。
 Goal: ミーティングのゴールは何か。何を達成すればよいか。
 Agenda: 何を話し合うのか(ある程度の発散は容認するけど)。
 Point Of View: どんな観点で発言を期待しているか。

とくにゴールを意識するだけで、全然ちがった。
発言がミーティングのゴールに沿ったものか、関連があるか、
発散させることがミーティングのゴールに貢献する可能性があるか、
という判断ができる。

よろしければ、お試しあれ。

テーマ : ビジネス    ジャンル : ビジネス

26

Category: 思考法

Tags: ---

Comment: 0  Trackback: 0

ニュースと what-if 分析
現職に転職したばかりのこと。
今思うと相当なムチャブリだったが、新製品の企画・開発にアサインされた。
最初はある程度の仕様があったので、画面設計を作りもした。
しかし、
  ・お客さんのマーケティング業務がわからなかったこと、
  ・システム化するにあたって仕様がよく変わったこと、
  ・関係者が増えてきて収拾がつかなくなったこと、
などなどがあって、最終的には古株の人にひきとってもらった。

これって苦い思い出。

今、もう一度同じことをやったとしたら、
さほどの自信はないが、若干マシなのではないか。
そう思えるようになったのは、以下の記事を読んだためだ。

第45回 想像力はwhat ifで鍛えよう

過去のブログ記事でも、ニュースから what-if 分析を使って
将来予想を立てることをよくやっている。
これを使ってお客さんの業務を想像すれば、いくつかの仮説を立てられただろう。

まだ3カ月近くしかたっていないが、ブログを書き続けることで
予想していなかった成長を得られたように思う。
少しうれしい。

テーマ : ビジネス    ジャンル : ビジネス

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