どう「見せる」か（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

下手に話をややこしくしないこと。これに尽きる。Simple is the best. 真理は単純である。ただしむやみに抽象化・汎用化してはならない。適用範囲が広がってしまう。具体的な前提を定義することが重要である。具体的かつ単純。これがコツである。自分を利口に見せることにこだわってはならない。バカでした。ごめんなさい。これで話が早く済むのならさっさと謝ってしまうのがよい。

Javaで開発しているプロジェクトで障害が発生した。障害の原因がNullPointerExceptionだった。NULLチェックを入れ忘れていた。このように見せてしまうと、影響範囲は甚大である。NULLを取りえる全てのコードにチェックが必要となる。Javaが分かっている人間であればNULLチェックはするし、ほとんどのは単体テストか結合テストで分かる判明するはずのトラブルである。しかしNullPointerExceptionが一人歩きしてしまうとただひたすらこの例外にフォーカスが当たってしまう。原因への対処には不釣合いな、膨大なリソースが投入されてしまう。NULLチェック漏れではなく、さまざまな要因が重なっているはずである。条件があるはずである。そこをちゃんと見せなければならない。そうすればそのトラブルをクローズし、次のトラブルにリソースを投入することが出来る。

また政治的な問題を軽視してはならない。現場から見れば大したことがない修正でもマネジメント層や顧客からすると大変なハードルとなることがある。現場が「大した変更じゃない」と思っても、政治的にはその選択はありえない、という可能性がある。例えば顧客の他の部署に依頼する必要がある変更である。絶対に変更を受けつけてもらえない。顧客はまず青い顔をし、次に現場を恨み始める。現場は「顧客の問題であって俺たちは知ったこっちゃない」と思う。どんどん関係が悪化し、プロジェクトがまずい方向に進む。健全にプロジェクトを運営したいなら、決して政治を軽視してはならない。

見せるにあたってはスコープを広げないこと。むしろ狭めるよう努力する。スコープとはタスクの範囲を指す。タスクの範囲を下手に広げてしまうと、完了させることが出来なくなる。あれはどうなった？と聞かれて常に状況を報告する羽目になる。タスクはシンプルに、ピンポイントで定義すること。そして何をどうしたら完了できるか、そこまであらかじめ射程に入れておくこと。完了までの道筋を見極めることなく、課題を定義しないこと。ついうっかり不安をそのまま課題にすると、却って政治的に厄介になる。重要度が最終的に低いと判明したとしても、だ。また課題を提起する際にその完了条件まで射程に入れておくと課題をクローズする効率が全く違ってくる。スコープを広げないこと。特に広げさせないこと。これが重要である。

やたらと宿題のキャッチボールをしないこと。決定事項のやり取りをキャッチボールに例えた。顧客に決定権をゆだねるとさしあたりは自らのタスクではなくなるため安心する。また待ち状態となるため、責められることがない。少なくとも決定を依頼すれば、作業を進める責任は顧客にある。だがこれは単なる作業の先送りに過ぎない。未来から時間を借りているだけである。下手に先送りすべきではないのだ。顧客への意思決定依頼は最小限にする。適切に提案し迅速にクローズ。結局はそれが一番早くて体力が掛からない。

管理されるが故に完了困難になることもある。重箱の隅が突付かれ、優先度の低いタスクが山ほど発生する。課題のクローズに完璧さが求められる。なんてことはない課題がどんどん広がり、収集がつかなくなる。最後には原型を留めないほどに課題が変質してしまう。そんなことにならないよう、出来る限りクローズを急ぐことだ。