 |
第２回（2003.11.30） ロジックツリーで原因を分析し，対策を立案する |
◆ロジックとは プロジェクトマネジメントは問題解決の連続である．問題解決とは，問題を特定し，その問題を解決する方策を考えることであるが，いずれにおいてもポイントになるのはロジックである．ロジックとは「風が吹けば桶屋が儲かる」というアレである． 「風が吹く」→「砂が舞う」→「砂が目に入る」→「失明し盲人になる」→「盲人が三味線を弾く」→「三味線の需要が増加」→「三味線用のネコの皮の需要が増える」→「ネコが減る」→「ネズミが増える」→「桶がかじられる」→「桶屋が儲かる」 「風が吹けば桶屋が儲かる」というのはあまり良い思考法としては使われておらず，どうも「こじつた理屈」という印象が強い．なぜだろうか？まず，ここを押さえておこう． 「風が吹けば桶屋が儲かる」については齋藤嘉則氏が「問題発見プロフェッショナル」で面白い指摘をしている．詳しくは説明しないが，要は上のようなそれぞれのロジックには発生確率があり，その発生確率が低いものがあるとロジックはそこで破綻するという指摘である．例えば，砂が目に入って失明する可能性はほとんど０だが，三味線の需要が増えて，ネコの皮が必要になる可能性は１００％である．このように発生確率が全く違うロジックの連鎖はロジックとしてほとんど意味がない． ロジックを展開するという場合には，この発生確率をうまくコントロールしていく必要がある．これを齋藤氏は「ロジックの筋のよさ」と呼んでいるが，ロジックを考えるということは，まさに「筋の良いロジック」を考えるということである．「風が吹けば桶屋が儲かる」を信じる人は皆無であろうが，実際にプロジェクトにおける意思決定の場面では，この程度ナンセンスな意思決定は意外と多いものである．これをまず，よく頭に入れておいて欲しい． ◆ロジックの種類 さて，一般にロジックという場合，以下の３種類がある． ・結果／原因 ・目的／手段 ・全体／部分（あるいは，実体／属性） ロジックツリーはその名前の通り，これらのロジックを表現するのに最も適した手法であり，文字通り，事象間のロジックをツリー上に表現していく図法です．ここでは，それぞれに対応するロジックツリーを，原因結果型ロジックツリー，手段目的型ロジックツリー，構成要素型ロジックツリーと呼ぶことにする． 以下では，ロジックツリーがどのようなものかを理解するために実際にロジックツリーの作り方を説明する． ◆原因結果型ロジックツリーの作り方 原因結果型のロジックツリーは，結果から始めて，その原因をずっと展開していくロジックツリーである．プロジェクトで何かトラブルが発生したときに，そのトラブルの原因を究明するために使われるものである． ロジックツリーを作るにはまずテーマを決める．原因結果型の場合，テーマは結果であり，「･･･が･･･する」，「･･･が起こる」というテーマになる．「設計納期が遅れる」，「製作コストがオーバーする」などである． テーマが決まったら，次に１次の要因を決める．ロジックツリーを作る上ではここが極めて大切である．前回ＭＥＣＥの説明をしたが，ＭＥＣＥはここで使う．ここが漏れてしまうと原因が究明されないし，ダブルと同じ原因がたくさん出てくることになる．１次要因は事象を引き起こしている直接的要因である．例えば，テーマとして設計納期が遅れるだったとすると，以下のようなツリーを作っていくのだ． 設計納期が遅れる−−−−−設計者のスキル不足 ｜ ｜−−作業量の見積もりミス ｜ −−−作業者の不足 １次の要因が洗い出せたら，それぞれについて，２次以降の要因を洗い出していく．上の一つの項目を例にすると 作業量の見積もりミス−−−−−実施作業の抽出抜け ｜ ｜−−単位作業の実施時間の想定誤り といった具合である． さて，ここで難しいのはどこまで行けば，展開を終えてよいかという問題である．これはそのロジックツリーを何に使うかにより異なるが，一般論としていえば原因結果型の場合，対策が立案できるところまでは展開しておく必要がある．例えば，上の例で，実施作業の抽出抜けに対しては，作業の標準化とリスト化といった対策を考えることができるのでもうこれでよいことになる．しかし，「単位作業の実施時間の想定誤り」に関しては，これだけではどのような対策を講じればよいかは明確にならないので，もう少しブレークダウンする必要がある． 結果原因型のロジックツリーを作るときに注意しなくてはならないことは「論理の飛躍」である．例えば，上の例では「設計納期の遅れ→経験の浅い設計者の作業」というような論理展開を目にすることが結構多い．これは経験的に考えてそうであるということで，中のロジックを飛ばしているのだ．この部分のロジックとしては，例えば，作業環境が悪かったとか，作業者のバイオリズムが悪かったとか，他にもいろいろな原因が考えられる．ロジックツリーを作る意味は，このようなＫＫＤ（勘，経験，度胸）による推理を排除することにあることを意識しながらロジックの展開をしていく必要がある． もう一つの難しい点は，階層間の整合性である．例えば 後工程からの手戻りがある（結果）←前工程の作業者のスキルが低い（原因） という論理展開を考えてみよう．一見正しいように思うかもしれないが，後工程からの手戻りは前工程でチェックをしていれば起こらない．このようなロジックはロジックとしてのミスである． ◆目的手段型のロジックツリー 目的手段型のロジックツリーは，目的を決めて，その目的を実現するための手段を展開していく．プロジェクトでトラブルが発生した際の対策の立案，リスクマネジメントの中のリスク対策の考案などの際に使うことができる． ロジックツリーを作っていく手順は，結果・原因型と変わらない． まず，テーマの選定であるが，目的手段型では，テーマは目的であるので「･･･を･･･する」となる．例えば，「設計期間を計画通りにする」，「製作コストを計画通りにする」といったものがテーマになることが多い． 次に，１次要因を洗い出す． 設計期間を計画通りにする−−−−−設計作業を減らす ｜ ｜−−設計要員を増やす ｜ ｜−−計画を延ばす といった具合である．目的手段型の場合にも，１次要因がＭＥＣＥであることが重要である．目的手段型でＭＥＣＥを構成する場合には，二分化していく方法がよいとされるが，実際には二分化は難しい場合が多く，ある程度のその後の展開を考えてできるだけＭＥＣＥになるように事象の洗い出しを行う．ここで注意しなくてはならないことは，モレがあると的外れな対策になってしまう可能性があり，ダブリがあると，同じ問題への対処を複数の方法で行うことになり，コストや時間の無駄が生じてしまうことになる点である． １次要因の洗い出しが終わると，２次以下の要因の洗い出しを行う． 設計作業を減らす−−−−−仕様の見直しをする ｜ ｜−−モジュール化をする ｜ ｜−−過去の設計の再利用をする 目的手段型のロジックツリー展開を終えるタイミングは，手段としてそのまま実行に移せる項目になったときである．上の例では，仕様の見直し，モジュール化はもう少し展開が必要であるが，過去の設計の再利用はこのままでよいだろう． ◆構成要素型ロジックツリー 構成要素型は文字通り，対象物や機能の構成をブレークダウンしていくロジックツリーである．構成をロジックというのは奇異に感じるかもしれないが，構成の中には構成のルールが含まれており，それが（構成）ロジックになっていると考える． 構成要素型のロジックツリーのプロジェクトでの応用場面はＷＢＳやＯＢＳである．構成要素型という場合，物理的な構成を表現する場合と，機能を表現する場合があり，ＷＢＳは物理的な構成であり，ＯＢＳは機能である． 従って，構成要素型の場合のテーマは，ものの名前や，機能になる．これらを出発地点にして，１次の要素を洗い出す．構成であれば Ｗｅｂプログラム−−−−−ＨＴＭＬプログラム ｜ ｜−−ＧＵＩプログラム であったり，機能であれば Ｗｅｂプログラム開発メンバー−−−−−ＨＴＭＬプログラム開発メンバー ｜ ｜−−ＧＵＩプログラム開発メンバー となるわけである．そして，これをさらに細分化していく．これは，ＷＢＳやＯＢＳの作成そのものである．展開終了のタイミングは，一般的にこれ以上分けても意味がないというところであるが，これも応用の仕方によって異なる．ＷＢＳであれば，アクティビティとして作業定義ができるところが完了タイミングである． ◆ロジックツリーをうまく作るには 結果原因型は，事象を引き起こす原因を具体的にあげていく．この場合上で述べたように，１次要因がＭＥＣＥになっているかどうかが最も重要なポイントになる．問題解決の中で原因の究明を行う理由は，その後で対策を考案するためであるので，無駄な対策や的外れな対策をしないためにも，１次の要因がモレなく，ダブリなく洗い出されていることが重要である． 目的手段型では，抽象的な目的を，具体的な方策に展開するわけであるが，やはり，１次要因に何をとるかがポイントになる．例えば，よいシステムを開発するという目的があった場合に，考えなくてはならないことは，顧客の要求を適切に理解する，システムのアーキテクチャーをうまく設計する，よいプログラムを作るといったことである．つまり，さまざまな対策が考えられるわけであるが，これがＭＥＣＥになっている必要がある．一般論として，あることを好ましい方向に持っていくには，部分部分で異なる性質を見つけ，それに対応する方策を発見することが有効である．上の例はソフトウエアのライフサイクルにしたがっているので分かり易いと思うが，よいシステムを開発するには，ライフサイクルのそれぞれの場面で違った対策が必要になってくるわけである． ３番目の構成要素型では部分（要素）の捉え方というのがもっとも重要なポイントである．機能と要素の関係を考えてみると， ａ）分けた要素ごとに一つ一つ異なる機能が割り付けられる ｂ）いくつかの要素で一つの機能が達成される ｃ）一つの要素に複数の機能が集約される の３つの場合が考えられる．構成要素型は，ｂ）のタイプであることが望ましい．ＷＢＳを考えてもらえば分かると思うが，ａ）として作ってしまうと非常に効率が悪くなり，また，ｃ）として作ってしまえば，あまり用をなさなくなる．ところが，ｂ）として作るのは意外と難しいものである．ロジック展開をあまり厳密にやりすぎるとａ）になったり，いい加減に行うとｃ）になってしまう．ここでも，ポイントは１次要因がＭＥＣＥであることであり，１次要因をきちんとＭＥＣＥにすればｃ）になることは防げるので，後はどこで展開を終了するかを考えればよいだろう． |
|
| ◆参考文献 中村伸「変革のマネジメント―できる組織の仕事術」，日科技連（１９９８） 齋藤嘉則「問題発見プロフェッショナル」，ダイヤモンド社（２００１） |
|
| スポンサードリンク | |
| 読者からのコメント | |
■本稿に対するご意見，ご感想をお聞かせください．■ ■は必須入力です |
|
| このコンテンツは「プロジェクトマネージャー養成マガジン」としてメルマガで配信されています．メルマガの登録はこちらからできます． | |