プロジェクトの失敗は組織の失敗

ソフトウェアプロジェクトがおかしくなると、私たちは必ず開発者を責めたてます。締め切りに間に合わなかったり、成果物に昆虫学者もびっくりするほどバグ（虫）があると、チームには実力と賢明さがなく、必要な生産性あるいはチャレンジ意欲が足らないのではないかと思ってしまいます。チームもそれなりの非難を受けるとしても、ソフトウェアプロジェクトが成功するためには、すべてのステークホルダーが積極的かつ適度にプロジェクトに参加する必要があることを忘れてはいけません。

全員参加が不可欠です。失敗を回避するためには、だれが、何を、いつ、なぜ作っているのか、あなたは知る必要があります。優先順位にしたがって、慎重にビジネス機能を追加する必要があります。不要とされた要求について、何が問題なのか見つける必要があります。また障害になりそうな人物を見極め、コミュニケーションミスに注意し、大量の仕事に閉口している（しかし情熱あふれる）開発チームをなだめることで、隠れた障害の芽を取り除く必要があるのです。

ソフトウェアを開発するためには、確かな測定基準、明確なコミュニケーション、ビジネスおよび幹部ステークホルダーの参加が不可欠です。全員がソフトウェアを納品するという活動にかかわり、良い結果であろうと悪い結果であろうと、どちらにも一部責任を負わなくてはなりません。プロジェクト・マネジャーはその結果を測定し、成功と失敗どちらの実績も記録する必要があります。堅実に納品してくれたチームは、また今度もそうしてくれるとステークホルダーから信頼されます。ほとんど納品できなかったチームは、さらなる監督、トレーニング、再編成が必要です。一部のメンバーには出ていってもらう必要もあるでしょう。

ただし、チームには混乱を整理するための時間を与えましょう。そのままリリース†に突き進んでしまうと、Wiki の草分けであるワード・カニンガムが「技術的負債」と呼んだものを負うことになります。これは実際の負債と同様、絶えず責任をもって支払っていかないと、やがて自分たちの手に負えなくなり、いつも返済を気にしなくてはならなくなります。

各イテレーション†には、新しいビジネス機能を追加するだけでなく、否応なくコードに現れるハックをリファクタリングする††という活動も含むべきです。これはサボるための免罪符ではありませんし、出来の悪いチームの兆候でもありません。これは単なるプログラミングの現実にすぎません。幹部ステークホルダーからの十分な支援のもと、定期的に解決していかなくてはなりません。

組織は業界トレンドを把握し、適切なツールを手に入れ、プログラマの仕事にはっきりとした効果のある実装方法を採用することを明言しなければなりません。勤務時間の内外で、開発者が知識を広げることを奨励しましょう。新しいツールをいじったり、トレーニングを受けたり、価値あるカンファレンスに参加したり、本やブログを読んだりすることは、ソフトウェア開発に要求される不断の努力に必要なものです。

チームランチを開催して、メンバー同士が知識を共有し、新しいアイデアを出し合うことは、メンバーの成長を促す安上がりですばらしい手段です。雇い主に支援されていると感じているソフトウェアエンジニアには忠誠心が芽生え、自ら進んで一層の努力をするものです。要求や技術展望の変化に対応する心構えもできるでしょう。

ソフトウェア業界の現場では、高品質で約束通りのリリースを着実に納品するためにできることがたくさんあります。継続的に繰り返し成功する機会を高めるために、ソフトウェアを作る組織はあらゆるレベルでプロセスにかかわらなくてはなりません。