プロジェクト成功の鍵：意識と得意領域を最大限に活用

プロジェクトが2つあるとします。
一つは、ビルのワンフロアを貸し切ってプロジェクトルームを設置し、厳格なコーディング規約を作って、担当毎に目標とゴールを設定した数年単位の大規模プロジェクト。
もう一つは、リリース後に不具合が発生し、顧客が激怒の中で修復するプロジェクト。
どちらがより高い満足度を得られるプロジェクトでしょうか？

業務コンサルタントを入れて戦略と戦術を完璧にし各部門毎にKPIを設定した企業が、引かれた線路の上を走っていると思いきや、在庫過多や納期遅れが多発していてもしれっとした顔でお客様に迷惑をかけていて、顧客満足度がガタ落ちした、なんていう話、聞いたことありませんか？そしてその企業の工場で火災が発生してしまったのですが、そこからのリカバリで在庫も捌けて納期に間に合う配送をして、利益率も顧客満足度も爆上がりした、なんて話もあったりします。この違い、何が原因なのでしょうか？

前者は、部門ごとに設定したKPIが、部門内では当然の目標であったにも関わらず、全体としては顧客目線ではなかった場合の話、後者は、部門ごとのKPIよりもお客様優先で対応した場合の話です。よく個別最適化/全体最適化の話に思われますが、そうではなく、どこを向いて仕事をしているのかということです。そして、結果というものは始める前に決まっているものではなく、行動を起こした後になってついてくるものなのです。

ITのプロジェクトにおいても全く同じ構造なんですよね。統制されているように見える大規模プロジェクトでも、個々のタスクは概ね順調に見えても大概の場合において遅延が発生し、その遅延がチリツモとなってゴールまで到達できず、発注側もプロジェクトの遅延と余計な出費を強いられ、システムインテグレータ側も無償対応せざるを得ない状況になっているのを嫌というほど見てきています。

一方、炎上プロジェクトの方は、全員が正常化に向けて動くので、短時間で問題の修正が終わるものです。お客様としては、炎上プロジェクトのほうが高い評価をつけられ、担当したシステムインテグレータ側も、やり切った感が強く出ると思います。

今の話は意識をどこに持っていったかの話でしたが、実はもう一つ観点があると思っています。それは、担当する人材がどういう作業を得意としているのかです。
成功体験を積み重ねることに喜びを得るタイプか、議論を尽くしてリスクが0になることに喜びを得るタイプか。

成功体験を積み重ねることに喜びを得るタイプの人は、とにかくやってみて、試行錯誤で前進することが好きなタイプです。逆にこの方々は机上検討や決まり切った作業を延々に行うのは苦手です。
議論を尽くすことに喜びを得るタイプの人は、自分で手を動かすのが苦手で、誰かにやってもらいたいと思っているタイプです。一方でこの方々は辛抱強く、確実性を追求するタイプです。

どっちが良い・悪いではなく、どちらも得意領域・不得意領域があるわけで、得意領域を利用した開発手法もあるのではないかと思います。（もちろん両方ともイケるスーパーマンがいれば何の心配もないのですが）なので、成功体験を積み重ねる方のタイプの人は繰返し型開発に向いていると思いますし、議論好きな方はウォーターフォール型開発や、開発マネージャーに向いていると思います。

製品ベンダーが「ハンズオン」や「ハッカソン」というものを強烈にお勧めするのも、成功体験を積み重ねることに喜びを得るタイプは開発者に多いということを利用したプログラムなのです。開発アジリティの向上や高品質化・コストの削減が求められる開発の現場で、そこに集まる方々の属性で開発手法を決めて実行すると、意外と桁外れな開発生産性を生むかもしれません。やるべきでない事は、ダラダラと長く検討ばかりすることでアクションを起こさないこと。「成功体験」の反意語は「何も行動しないこと」です。