ベテランならホントに安心なのか？：開発現場の天国と地獄（3）（3/3 ページ）

[佐藤大輔（オープントーン），＠IT]

3カ月以上遅れの納品へ

地獄的アジャイル

　顧客は運送会社であったために、長距離ドライバー向けの宿泊施設を持っていました。そこがその日からプロジェクトルームになりました。事実上、要件定義と、設計と、詳細設計、実装を同時にしているような状態でした。最大の効率で構築が行えたのは、本来プロジェクトチームが分担すべき各ロールを2人の人間に集約し、その人間が月間400時間を超える労働時間で対応したからでした。この対応方法に学ぶべきものは何もありませんが、効率が非常に良かったのは事実です。

　通常プロジェクトの効率化の最大の障壁はコミュニケーションにあります。顧客の欲しいものをどう仕様策定者に伝えるか、仕様策定者はどう実装者に伝えるか、実装者は実装で起こった問題をどう仕様策定者や顧客にフィードバックするか。これらの間のロスは「打ち合わせ」や「文書の作成コスト」という形で表れます。つまり、仕様策定者がそのまま「地獄の対応」をすることは、下手にプロジェクトメンバーを増やすより、コミュニケーションロスを減らし、「効率が良い」作業が行えるということになります。もっともこの対応は多くの場合、開発組織全体のモチベーションの低下を招くため、最終的なコストの割は合わないことになります。つまり、結果的にこのときのエースメンバーはこの後あっさりと退職してしまい、結局人材がすべてともいえるこの業界で「最大の痛手」を受けることになったのです。ともあれ、2名の実装者が客先で要件を聞きながら作り、動かしてゆくアジャイル的な地獄の開発は格段に効率がいいものでした。

増員して取りあえずテストでも……

　この状況に上司が打てる対応方法は多くの場合、「増員」に集約されるでしょう。多くの場合、増員は物事を人月で測る、という実効性の薄い考え方に基づく対処です。しかし、時間をかけるという選択肢がなくなると、後は機能とのトレードオフ以外に解決方法がありません。それすらも閉ざされると、最も単純な人員増という選択肢になってしまうのです。

　このプロジェクトにもあっという間に、4〜5人の増員がなされました。こういうときによくいわれるのが「取りあえず人員を集めたのでテストとかだけでもやらせて早く仕上げてくれ」というセリフです。いままでも多くのプロジェクトで手詰まると、泡を食って人員を増やし、「テストとか簡単なことをやらせて……」という話はよく聞きました。しかし、考えてもみてください。テストこそ、仕様の中で最も重要な部分です。動かしてみて「動きました」ではテストになりません。「仕様どおり動いているか？」が問題なのです。つまり、仕様を知らない人にテストをさせるには、詳細にわたるテスト手順書を作り、細かく説明して、しかも結果は1つ1つ「仕様の分かる人々」が検証しなければなりません。

　さて、このときに追い詰められた「仕様の分かる人々」にとってこの増員はどれだけの助けになるのでしょう？ 何日もかかってテストを文書化し、また何日もかかって結果を検証する。少なくとも今回のような規模のプロジェクトであれば、アジャイル的に「顧客と動かしながら構築していく」方がはるかに効率的です。せっかくオンサイト顧客なのですから、その最大のメリットを可能な限り生かさない手はありません。もう納期もスケジュールも破たんしている以上、とにかく「作る」「見てもらう」「動かしてもらう」、そして「指示してもらう」。この方がはるかに早いのです。

プロジェクト再生の可能性

　このとき、顧客の要望が要件から逸脱していけば要件が発散してしまい、本当に破たんしてしまいます。しかし、ここまで破たん的な状況になると、顧客も「プロジェクトを何とか形にする」ことに集中します。このときに学んだ大きな教訓が「プロジェクトが破たんすれば、開発者も困るが顧客はもっと困る」です。顧客の決裁者も、社内の「偉い方」や「取引先」にプロジェクト成功の責任を負わされています。ですので、開発側に「では構築費用は要らないので手を引かせてほしい」といわれても顧客は引き下がれません。むしろ、何とか「謝って済む範囲に状況を持っていってくれ」という姿勢になるのです。

　ですから、破たんしかかったプロジェクトの顧客は意外に協力的です。というより破たんしかかったプロジェクトが再生する可能性があるとすれば、ひとえに「まだ顧客があきらめていないか否か」にかかっているのです。

　このとき、2人のメンバーはひたすら疲弊していきました。彼らの休みは3カ月以上まったくなく、労働時間はすでにカウントもあきらめていましたが、おそらく400時間超だったでしょう。こういったプロジェクトを続けると、メンバーや社員のモチベーションは極端に下がり、生活と会社をてんびんに掛けて真剣に悩み始めます。開発組織にとって最も重要なファクターである、「戦力になる人材」を失うことにもなりかねません。

納品はしたものの……

　結論からいうと、案の定、納品後に人材が次々と去るという事態がやって来ました。もちろん、顧客にとっても憂慮すべき事態です。ようやく問題を解決できる人材を得たはずなのに、今度はその人材が開発組織からいなくなってしまうのですから。私自身も零細企業の経営者ですが、やはりこういう事態を目の当たりにすると、顧客がわれわれのような零細企業に頼みにくい実情がうかがえます。

エピローグ：地獄プロジェクトのもたらすもの

　結局アプリケーションは納期後3カ月ほどして一応動く形になりました。顧客企業の努力と、2名の「献身」によって救われたのです。とはいえ、すでにテーブル設計などが狂っていたところに無理に上物を構築したわけですから、パフォーマンスはかなり厳しい状態でした。おそらく顧客にしても、請けた企業側にしても「後は稼働させながらバージョンUPしていけばいいのでは」と思っていたでしょう。しかし、納品後「ひどい目に遭わされた」技術者は次々と去っていってしまったのです。

　結局、顧客にとっても成功とはいい難い結末を迎え、請けた会社にとっては失敗としかいいようのない無残な結果が残ったのです。

　ちなみに……、この案件を請けた会社はいまはもうありません。

　このプロジェクトの教訓！！

• 顧客の責任者にとっても「プロジェクトの失敗」は大きな問題である。そのため、何らかの形でプロジェクトを完遂する方向を検討してくれる
• 開発会社の決裁者にとっても自分の任命したリーダーマネージャーに問題がある場合は、やはり、何らかのペナルティとなる。そのため、対処は遅れがちになる
• スキルシートを片手に集めた多人数よりも、優秀な少人数の生産性の方が驚くほど高い
• 論理設計までなら、ベテランであれば技術（汎用機やホスト型の経験）に関係なく能力を発揮できるというのはうそである。論理設計もまた、実装技術の上にある
• 建て直しの成功要因はアジャイルである
• 進ちょく管理は「表向き」は粗く、裏で細かく
• ミラクルは起きない。レビューなどでダメ出しされても最後はうまく乗り切れるということはない