チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。

詰め込み型のプロジェクトは、誰にとっても利点がなく、そのうえ持続不可能なやり方なのです。

「詰め込んでもなんとかなる」という楽観主義

詰め込み型のアプローチは、組織内でプラクティス化しやすいプロジェクト計画手法です。この手法で完了したプロジェクトは、一見すると、上手くいったように見えます。多少の遅延があったとしても、概ね一通りの機能がリリースされるからでしょう。そのうえ、欠陥による本番トラブルが何度か起きても、苦労した分、リリースまで漕ぎ着けたという事実が関係者らにとって成功体験として残ります。それが、「詰め込んでもなんとかなる」という楽観主義を生み出すのです。

この手法は、実行チーム以外の関係者がプロジェクト計画を作る組織において駆使されます。プロジェクト期間に対して見積り結果が大き過ぎても、何とかすべてを盛り込もうと、チームに無理を強いるのです。チームが好んでプロジェクトを詰め込み型にするわけではありません。

詰め込めるだけ詰め込めばチームの稼働率が上がり、チームの開発生産性を高められるという狙いもあるのでしょう。チームに高い負荷をかけることで、仕事に対してより懸命になり、ムダが削られ、創意工夫も生まれる。そうして、人員数に比してアウトプットの量が増えると信じているのです。

「時間でカバーするしかない、いつものことだから何とかなるだろう」という麻痺症状

詰め込み型の計画を受け入れるチームは、その時点で、過積載な仕事量を時間でカバーすることを覚悟します。詰め込まれたそれらがユーザーやビジネスにとっていかに重要であるかを説かれたら、断りきれません。同じような状況は、今まで何度もありました。そして、その度になんとか乗り切ってきた経験もあります。だから、「今回もなんとかなるだろう」と諦めと楽観が入り混じった感情で受け入れます。

彼らも本音としては、「やることを絞り込んで欲しい」と考えています。なんとかなるだろうとは思っても、やはり高負荷の中での仕事は心身ともに疲れ切ります。息をつく暇もないほどプロジェクトのタスクに追われ、それ以外にやるべきことがあっても手をつけられません。その日の予定が定時までに終わらないから、残業で片付けることも増えます。期限に追われるストレスにもさらされ続けます。

実際に手を動かす立ち場だからこそ、このようなやり方が、アウトプット品質とのトレードオフであることも実感しています。間に合わせようと頑張ることだけで精一杯で、品質にまで気を配る余裕がなくなってしまうからです。

こうした品質悪化が後になって問題を生じさせると自分たちだけが責められることが、彼らにとってもっとも心配な点です。だから、詰め込み型の計画を受け入れる時に、関係者らに品質に対するリスクを伝えます。アウトプット品質が悪くなる原因が、実行ではなく計画にあることを明確にしておきたいからです。しかし、この予防措置が効果を発することはありません。実際に問題が起きた時、プロジェクト関係者には、その問題と計画との因果関係がわからないからです。なにしろ、「プロジェクトはうまくいった」と認識しているのですから。

誰も得しない、持続も不可能

要求を過度に詰め込んで始めたプロジェクトが成功したと感じているのならそれは幻想です。このやり方は、ユーザーにとっても、チームにとっても、関係者にとっても利点がありません。アウトプット品質が悪くなるだけでなく、将来の開発生産性が悪化します。また、チームワークが機能せず、チームや組織が成長することもありません。プロジェクトは遅延し、後からスコープが削られます。そうして、チームは疲れ切ってしまいます。

・アウトプット品質が低下する

完成した機能の品質は、褒められたものではありません。確かに、表面上は要求どおりに作られていますが、実際に触ってみるとその粗さが目立ちます。ソフトウェアは、動くものを実機で触るまで、体験上の問題や仕様の問題に気づけないものです。机上での設計が完全であるはずがありません。しかし、仕事量に圧迫されて時間に追われたプロジェクトでは、その細かな調整にまで意識が行き届かないのです。

たとえ、開発途中で仕様上の問題や漏れに実装者が気づいたとしても、その多くは放置されるかもしれません。仕様の調整をしている余裕などないからです。それよりも、完成させることが最優先です。できることはせいぜい、発見者の解釈に基づいて修正することぐらいでしょう。しかし、それでは体験上の一貫性や、設計上の整合性が失われかねません。

欠陥も多く含まれます。急いで設計・実装したのだから当然でしょう。さらに、テストまで急いで実施したのであれば、欠陥の多くは検出されないまま、本番リリースを迎えることになります。こうして撒き散らしたトラブルの火種は、いずれ、本番環境で幾度も火を吹くことになるでしょう。

・開発生産性が悪化する

リリース後の高い運用負荷の圧迫によって、チームが今後、開発にあてる時間は削り取られることになるでしょう。機能を追加し、システム規模が大きくなるほど、運用負荷は高まります。しかし、プロジェクトの計画に、運用負荷の対策をタスクとして含める余裕がありません。何度も繰り返されるような運用作業を自動化することも、トラブル発生時の原因特定や復旧をやりやすくする仕組みを構築することもできないのです。

また、ソフトウェアの内部品質も悪くなり、それがチームの開発生産性の足を引っ張ることにもなります。突貫工事のようにして開発したソフトウェアシステムです。その内部構造が適切に設計されているはずがありません。今後、そこにあらたに機能を追加しようとするたびに、どこかがボロボロと崩れ去っていくことになるでしょう。それを補修するだけで、多くの時間が奪われます。

・チームワークが機能しない

チームワークも壊滅的です。みんな自分のことだけで手一杯の状態で、助け合っている余裕などありません。チームプレーが生み出されるほど周囲の動きに気を配ることなど、誰もできないのです。とにかく、担当するタスクだけに集中し、次から次へとこなすだけです。一人ひとりがマルチタスク気味となり、そのオーバーヘッドによって生産性も低下します。

・チームも組織も成長しない

チームがこんな状態だから、関係者らが期待した「創意工夫が生まれる」なんてことも起こりません。とにかく、時間を目一杯使って仕事をこなすだけになってしまいます。

最速で開発しようとすると、やり慣れた方法のみが採用され、新たなチャレンジもなくなります。新しい技術や開発手法を試す余裕はありません。チームの成長機会がなくなるのです。ひいては、組織の競争力が失われていきます。

・プロジェクトが遅延し、スコープも削減される

現場では、大量のタスクを期限までにやり切ろうと努めるも、結局は遅延します。チームの誰もが、はじめから、多少の遅れは覚悟していたところでしょう。一部の関係者らも、そうなるだろうと気づいていたものの、そこに目を瞑って計画を立てました。

こうなってようやく、遅れを最小限にとどめようと、関係者とチームの間でスコープの削減に手を付けます。はじめからスコープを調整していれば良かったのですが、それができるぐらいなら詰め込み型の計画でプロジェクトを始めたりはしません。そうして急遽調整した結果、最適ではないスコープでプロジェクトはリリースを迎えることになります。

・チームが疲弊する

プロジェクトが終了しても、チームは疲弊し、達成感を感じることもできません。ただただ、「ようやく終わった」という安堵と疲労を感じるだけです。燃え尽き症候群に見舞われてしまうこともあるかもしれません。

プロジェクトの成功基準が無いことで生じる「うまくいった」ような錯覚

それでも詰め込み型でのプロジェクトが繰り返される理由は、それを行使した関係者らに、失敗したという認識が無いからでしょう。前述したように、この手法で完了したプロジェクトは、多少の遅延があったとしても、概ね一通りの機能がリリースされます。それに加え、無理はしたがなんとかゴールに辿り着けたという手応えが、関係者らの「成功」感をより高めてしまいます。

これは、「リリースすること」自体がゴールになってしまっている症状をよく表しています。ユーザー価値・ビジネス価値といった「アウトカム」や「インパクト」ではなく、リリースという「アウトプット」が目的化しているのです。加えて、苦労してそこまで漕ぎ着けたという「エフォート」が、その肯定感をさらに後押します。この定義に従えば、プロジェクトは成功したと言えるでしょう。

しかし、プロジェクトの成功とは、概ね計画どおりにアウトプットすることなのでしょうか。

詰め込み型のプロジェクトに対して失敗したという認識を持てない原因は、これを議論せずにプロジェクトを開始することにあります。どうなったら、プロジェクトが成功したと言えるのか、その基準が明確ではないのです。物差しがなければ、測ることもできず、そもそも測るという概念すら持てないかもしれません。そうであれば、リリースすることがゴールのように感じてしまうことも頷けます。そのアウトプットがどのようなアウトカムやインパクトを生んだのかを測ろうという意識を持つことはないのです。

プロジェクトの成功基準の定義とそれに基づく結果の評価

プロジェクト計画時に成功基準を定義すれば、プロジェクト終了時にその結果を評価できます。さらに、成功基準を作れば、計画づくりにも良い影響を与えます。その達成に向けた活動が、計画に盛り込まれるようになるからです。機能を「ただ作るだけ」「リリースするだけ」ではなくなるということです。

これを実践するフレームワークとして、ODSCが使えます。ODSCは、プロジェクトの計画や目標を明確にするためのフレームワークで、以下の3つの要素で構成されます。

• Objectives（目標）：プロジェクトの全体的な目標の定義。何を達成したいのか、そのプロジェクトの意図を短く明確な文章で列挙する。

• Deliverables（成果物）：プロジェクトを通じて具体的に提供するもの。プロジェクトの最終的なアウトプットを粗い粒度で書き出す。

• Success Criteria（成功基準）：プロジェクトが成功したとみなされる条件。プロジェクトのアウトカムやインパクトにあたるものを明らかにする。

1つめの「目標」は、プロジェクト内でも意外と共有されないことが多い項目でしょう。これは、「why」とのセットで語られるものです。目標が共有されていないということは、もっとも重要であるはずの「why」も共に抜け落ちていると考えてまず間違いありません。それだけで、この項目をODSCの中で言語化する意味があります。

2つめの「成果物」は、ODSCを導入しなくともプロジェクト計画の中で明らかにされている項目です。それなら書き出す意味はないようにも思えますが、ソフトウェアに付随するドキュメントやマニュアルなどは、計画から漏れやすい対象です。そういったものも洗い出して、ここに書き留めておくと良いでしょう。

3つめの項目である「成功基準」を明らかにすることで、プロジェクトが目指すゴールがより明確になります。2つめの成果物だけが定義されたプロジェクトでは、それらをアウトプットすることがゴールになってしまいます。しかし、それは手段でしかありません。その手段を使ってどんな成果を得たいのか。それを、目標と対比して書き出します。他の項目とは違い、この項目は、プロジェクト内で明確にされにくい対象です。ODSCなどを用いて、成功基準を明らかにする活動をプロセスに組み込むことで、忘れずに定義できるようになります。

成功基準は特に、次の6つの視点で洗い出すことで、多角的な側面から定義できるようになります。

• 財務の視点

• 顧客の視点

• 業務プロセスの視点

• 成長と育成の視点

• 経営理念の視点

• 社会貢献の視点

（出典：岸良 裕司 著『最短で達成する　全体最適のプロジェクトマネジメント』KADOKAWA, 2012, P83-84）

プロジェクト終了後の振り返りでは、計画時に定義したODSCを使って、成功や失敗について話し合います。

プロジェクトを通してチームも組織も成長を

6つの視点で導かれた成功基準は、プロダクトのユーザー価値やビジネス価値を高めるだけでなく、チームや組織に成長をもたらします。ただ消費し、すり減らすだけの詰め込み型のプロジェクトでは、そのような効果が得られるはずもありません。そんなことを続けていたら、組織の競争力は、やがて失われてしまうでしょう。

チームにとって、「成長と育成の視点」は特に重要です。ここに、新しい技術へのチャレンジとその習得といった内容を含めることもできるからです。プロジェクトは決して、チームのリソースを消費する場ではありません。プロジェクトを通して、チームやメンバーが成長する機会を得る場でもあるのです。

チームや組織のパフォーマンスを高めるためには、最適な組織設計と共に、次の4つの要素が必要だと私は考えています。

1. チームおよび個人の高いスキルと知識、経験

2. チーム思考がもたらす練度の高いチームワーク

3. 磨き上げたプロセス（自動化やツール化も含む）

4. 求められる特性を満たし、今後の開発を柔軟にする高い内部品質

組織の中で実行されるいくつものプロジェクトは、これらを高めるチャンスでもあるのです。