その「大丈夫です」は本当に大丈夫？──「不安」を可視化してプロジェクトのトラブルを未然に防ぐ

「計画の難しさ」にマネージャーはどう立ち向かう？

　プロダクト開発における「難しさ」には、大きく3つの側面があると武方氏は言う。1つ目は、プロダクトが顧客と市場に受け入れられるために何が必要かを考える「企画の難しさ」。2つ目は、目的とする『価値』を一定以上の品質で期日までに届けられるかという「開発の難しさ」。3つ目は、正しい計画を立てて遂行する「計画の難しさ」である。

　本セッションのテーマである「計画の難しさ」は、市場のニーズが変わったり、重要なチームメンバーが急に離脱したりといった問題をきっかけに「予定したスケジュールまでに開発が完了しない」といった『トラブル』として具体化する。武方氏は「プロダクト開発には『不確実性』がつきもの。それによって生まれる問題への対応が後手に回れば回るほど、計画の狂いが大きくなっていく」と指摘した。問題への対応を後回しにせず、計画への影響を最小限に抑える対応を行う上で必要なのが「リスクマネジメント」の考え方だ。

　武方氏は、このセッションでは「リスク」を「計画を阻害する『起こり得る』事柄」、「問題」を「計画を阻害する『すでに発生した』事柄」と定義した。この定義に基づけば、まだ具体的な形として現れていないトラブルの種が「リスク」であり、「リスク」が顕在化したものが「問題」ということになる。

　「リスクをマネジメントするために必要なことは大きく2つ。一つは『潜んでいるリスクを洗い出す』こと。もう一つは『リスクが顕在化した時の影響を考えて、行うべき対応を考える』ことだ」（武方氏）

　システム開発の領域における、主な「リスク」要因としては、

• スケジュールの欠陥
• 要求の増大
• 人員の離脱
• 仕様の崩壊
• 生産性の低迷

といったものが知られている。しかし、こうしたリスクのすべてに同じように備えておくことは、リソースの制限などから難しい。その場合、必然的に「優先度の高いリスク」から順に対応していくことになる。その際、判断基準の一つとして「顕在化する可能性が高いリスク」への対応を優先するという方針が考えられる。そのためには「注目すべきリスク」を見つけ出し、その状況を詳細にモニタリングする必要がある。

「顕在化しそうなリスク」を見つけ出す方法

　では「顕在化しそうなリスク」は、どうすれば見つけ出せるのだろうか。前出の「プロジェクト炎上の例」を改めて見てみよう。

　マネージャーが進捗会議でメンバーに「進捗どうですか？」と訪ねた際、メンバーは言葉では「大丈夫です」と回答していながら、実は心の中で「リスク」の予兆を感じ取っていた可能性がある。数週間後に状況を確認したとき、「リリースに間に合わなさそう」と話したメンバーは、その前の段階で「仕様確認の手戻りが多いな」あるいは「この感じで進めて大丈夫なのだろうか」といった不安を抱えていた可能性がある。また「リリース後に不具合報告が多数出ている」と発言したメンバーは「今のタスクには影響が出ていないが、コードの品質が下がっている気がする」と感じていたかもしれない。

　そのほかにも「会議ばかりで時間がとれない」「見積もりが間違っていたかもしれない」「この機能、優先度が低い気がする」「仕様の理解があいまいになっている気がする」「ステークホルダーと話すと手戻りがあるから気が進まない」「このタスク、自分には荷が重いけれど他の人は大変そうだし自分でやらなければ」などなど、「進捗どうですか？」の回答にはならないが、プロジェクトに対するあいまいな「不安」がメンバーの中に芽生えていた可能性がある。

　「メンバーはそれぞれの役割を果たす中で、ささいな違和感や不安を覚えることがある。これは『プロジェクトのリスク』を『不安』という形で敏感に感じ取っていると考えられる」（武方氏）

　こうした違和感や不安を「顕在化しそうなリスク」「すでに部分的に顕在化しているリスク」と捉えるべきだというわけだ。

　マネージャーであれば「分かっているなら先に言ってよ」と思うかもしれない。しかし、ここで問題にすべきは「メンバーが思っていた不安を『言わなかった』こと」ではなく「不安を『言えなかった』こと」あるいは「マネージャーとしてそれを聞き出せなかったこと」であると武方氏は指摘した。