目の前にある事象を分析できていますか?

はじめに

第2回、第3回とプロジェクトマネージャの基本に近いスキルに関するお話しが続いたので、今回は少し趣きを変えて障害などが発生した際の障害分析や、(ITストラテジスト業務に近い話になりますが)要件の分析などに使われる情報整理のスキルについてお話しします。

プロジェクトマネージャと
ITコンサルタントで共通する業務

今回のお話しは、研修などで学ぼうとすると、一般的には「ITコンサルタント入門研修」や「要件定義研修」などで取り上げられるものになります。そして、それらの研修を受けるのは、一般的にITストラテジスト(ITコンサルタントなどと呼ぶ場合もあります)と呼ばれる職種を担う方や目指す方です。

ITストラテジストの仕事は「事業を行っている組織の経営陣を相手にする業務で、経営陣がいつまでに、どうやって、いくら儲けようと計画しているかを把握し、その計画にITを絡めてどうやって実現するか」を計画し、経営陣に向けて提案するものです。一方で、ITストラテジスト以外の仕事は、ITストラテジストが計画した活動をITにより具体的に実現することなので、両者で考え方も行う業務内容も相当異なります。

ところが、ITストラテジストが行う業務と、プロジェクトマネージャが行う業務で使い方は異なるものの、全く同じ手法で行う業務があります。以降では、それらの業務で必要となるスキル・手法を紹介していきます。

PMの仕事で2番目に大変なこと

第1回から何度も書いている内容になりますが、プロジェクトマネージャの仕事は「ITシステムを決められた納期までに、決められた要件を決められたコストの範囲内で実現するため、事前に詳細な計画を立案し、プロジェクト立ち上げ後は、計画が予定通りに行く様にマネジメントしていく」ことです。一般的にプロジェクトマネージャの仕事の中で一番大変で負荷が掛かるのはプロジェクト立ち上げの工程でのプロジェクト計画の策定になるのですが、では2番目に大変で負荷が掛かる仕事は何でしょうか。

答えは「品質の分析」です。プロジェクトマネージャは、前述の通りプロジェクト計画で計画した内容に従ってプロジェクトを推進します。その際に、計画が上手く進んでいるかを客観的に判断する要素としてQCD(品質・コスト・期限)を確認しながら、問題を未然に防いだり、発生した問題の対応を行ったりします。

QCDの各要素は、基本的にトレードオフの関係にあります。例えば、同じような条件の他プロジェクトと比較して納期を短く設定した場合、当然ながら設計・開発の多重度を上げなくてはならないためコストが上がり、増員によりプロジェクトに関わる人間も増える分、管理負荷が上がり品質は下がります。プロジェクトマネージャはこれらの要素のバランスを取りながらコントロールしますが、CとDは基本的にプロジェクトが計画通り上手くコントロールできているのか把握することも、問題が発生している際の対策も定量的な情報が手に入りやすいため容易です。一方で、品質に関しては、その状況を把握するだけでも時間とスキルの両方が必要になります。

品質管理の大変さ

多くの場合、品質管理では作成された設計書やプログラムレビューの指摘事項、テストで発見された不具合をインプットに、その原因を1件ずつ丁寧に確認していくことで状況を把握しますが、一番大変なのは原因の追究とその後の対策の検討です。成果物は基本的に人が作るものなので、不具合が0であることはありません。そのため、分析時点で挙がった指摘事項や不具合の原因を見極め、今後の成果物で同じ問題が発生しないように対策を打つのです。文章で書くのは簡単ですが、これを実際にやるのが非常に難しいのです。

皆さんは「ハインリッヒの法則」という言葉をご存知でしょうか。アメリカの損害保険会社で働いていたH.W.ハインリッヒさんが1931年(昭和6年)に経験から導き出した法則で、1件の重大な事故や災害の裏には29件の軽微な事故や災害があり、さらにその裏には300件のヒヤッとしたこと、ハッとしたことがある。そこから転じて、重大な事故や災害を防ぐためには、軽微な事故や災害、さらにはヒヤッとしたこと、ハッとしたことが発生した時点で、原因を追究し、対策していくことが必要という考え方です。

この考え方に従うと、ITプロジェクトでも軽微な指摘事項や不具合、ヒヤッとしたこと、ハッとしたことが存在し、それら軽微なものを分析し対策を打つことでシステムに致命的な問題を与える問題にある程度対処できますが、当然ながら、設計書の誤字・脱字やコーディングミスで発生した単体テストの障害の類まで、全ての指摘事項や不具合を確認し、原因分析を行った上で対策するためには労力とスキルが必要になります。全ての指摘事項や不具合の確認だけであれば膨大な時間は掛かりますが、スキルはそれほど必要ありません。問題はどのように原因の分析と対策の検討を行うかです。

ロジックツリーとは

では、原因の分析と対策は、どのように行うのでしょうか。私が知る限りで圧倒的に多いのが「ロジックツリー」と呼ばれる手法を用いて情報を整理し、分析する方法です。

ロジックツリーを直訳すると「論理木」です。木は地中から生えた幹が途中で次々に枝分かれし、さらにそれぞれの枝に花や葉が付く形になっています。論理木はそのイメージを物事の因果関係に当てはめたもので、発生した問題や課題が幹、その背後にある直接的な原因枝、さらにその背景にある根本的な原因がさらに細かい枝や葉という形で問題の相関関係を整理・発見するためのツールです。

ロジックツリーが使えるようになると非常に便利ですが、使えるようになるまでの学習コストはやや高めです。実際にやってみると分かりますが、初心者にはどうやって情報を整理したら良いのか分かり辛いのです。

そこで、今回は私が実践形式の研修で皆さんに教えてているロジックツリーの作成方法と作成例を公開します。なお、ロジックツリーはWebなどの説明によっては「What、Why、Howの3種類のロジックツリーにプラスしてKPIのロジックツリーの合計4種類がある」と記載されていることがあります。KPI以外のロジックツリーはほぼ同じ思考で対応可能なので、プロジェクトマネージャが品質分析で使うWhy(原因追及)のロジックツリーで説明します。

• STEP1：分析対象とした事象の原因を思いつく限り、短い言葉で列挙する
• STEP2：列挙した原因の裏にある原因も思いつく限り、短い言葉で列挙する
• STEP3：列挙された原因をさらに分割できないか考え、分割できるものは分割する
• STEP4：分割した原因の前後関係を比較し、前後関係・相関関係がないか考える
• STEP5：確認用のキーワードを使って考えた前後関係・相関関係に破綻や飛躍がないか考える
  　→左端の要素から順にキーワードを読む。その際キーワードの間に「なぜなら」を挟んで違和感がないか確認する。
  　逆に右端要素から順にキーワードを読む。その際キーワードの間に「だから」を挟んで違和感がないか確認する
• STEP6：破綻や飛躍があると考えられる前後関係・相関関係の間に、見えない原因がないか類推し補足する
• STEP7：確認用のキーワードを使って破綻や飛躍が補正されたか、確認する

相当簡単に書いたつもりですが、まだ難しいですね。では、具体的かつ簡単な事例に当てはめてみましょう。例えば、以下のような事例があったと仮定します。

この問題を詳しく原因追及しないで是正したら、どのような対策になるでしょうか。おそらく「遅刻をしないように注意しましょう」程度のものになってしまうでしょう。

では、仮にこの問題をAさんの上司であるBさんがロジックツリーを使って分析したらどうなるでしょうか。上記のロジックツリー作成STEPをAさんとBさんのやり取りとして当てはめてみました。

【STEP1】
Bさん:何故大幅に遅刻をしたのか思い当たる理由を簡潔に教えてください。
Aさん:思い当たるのは以下2つの理由です。
　①昨夜、夜更かしをしたため寝坊しました
　②急いで乗った電車が遅延しました

【STEP2】
Bさん:では何故昨夜は夜更かしをしたのですか?
Aさん:どうしても見たい海外のスポーツ中継があり、それを見てしまったためです。
Bさん:そのスポーツ中継を見たら寝坊するというリスクを考えなかったのですか?
Aさん:過去にも同じ中継を見て遅刻をしなかったことがあったので、大丈夫と考えました。

【STEP3】
Bさん:つまり、Aさんが遅刻した理由を簡潔にキーワードで整理すると以下になりますね?
　・寝坊した
　・乗った電車が遅延した
　・前日の就寝時刻が遅かった
　・どうしても見たいスポーツ中継を深夜に見てしまった
　・以前の実績からスポーツ中継視聴は出社に影響ないと考えた
Aさん:はい、そうなります。

【STEP4】
Bさん:キーワードで整理した理由の相関関係を考えると下図のようになりますが、認識違いはありますか?

Aさん:いいえ、認識は合っています。

【STEP5】
Bさん:では、確認用のキーワードを使って確認してみましょう。隣り合う相関図の要素を、間に「なぜなら」を付けて左から読んでみてください。次に、隣り合う相関図の要素を、間に「だから」を付けて右から読んでみてください。どうですか、違和感はありますか。
Aさん:…いえ、特に違和感はないです。
Bさん:本当ですか? 私は違和感を感じました。確かに1つ1つの要素の間に「なぜなら」と「だから」を加えて読んでも違和感はありませんが、要素を飛び越えて見ると違和感を感じます。右から読んだ際に「経験上、中継を見ても遅刻しないと思った」と「寝坊した」が矛盾します。実は、この図には書かれていない別の原因があるのではないでしょうか。Aさん、何か心当たりありませんか?
Aさん:そう言えば、スポーツ中継は現地の天候が悪く開始が遅れ、番組終了も遅くなりました。
Bさん:なるほど、Aさんは放送の開始と終了が遅れると思わず、遅刻しないと思ったのですね。でも、実際は放送の開始も終了も遅れてしまった。その際にAさん、あなたは目覚し時計をセットするなどの対策をしたのですか?
Aさん:確かに放送開始が遅れた不安はありましたが、開始と共に興奮してしまい、寝坊の対策を行っていませんでした。

【STEP6】
Bさん:では、追加で出てきた内容をロジックツリーに反映してみましょう。

【STEP7】
Bさん:どうですか? もう一度「なぜなら」と「だから」のキーワードを補足して読んでみてください。違和感はありますか?
Aさん:違和感はありません。こうして整理してみると、私が遅刻をした原因が非常によく分かりました。遅刻しないために何をすべきだったか、考えてみます。

いかがですか。ロジックツリーを作成していく細かいプロセスがイメージできたでしょうか。ロジックツリー作成の経験が少ないうちは非常に時間が掛かると思いますが、これができないと品質管理のための問題分析もできません。ぜひ頑張って身に着けてみてください。

なお、ITストラテジストなどが要件などを整理する「How」の場合は、キーワードを「どうやって」と「をすることによって」、要素の分解・整理をする「What」の場合は、キーワードを「と聞いてイメージするのは」と「をまとめて一言で言うと」に置き換えることで確認できるようになります。

おわりに

今回は、障害分析や要件分析などに使われる情報整理のスキルについて解説しました。次回は、できているようでできていない方の多い、兆候管理とその対策について解説したいと思います。