計画比で見ると、失敗しているプロジェクトは多いものです。

仮に、黒字になっていても、計画より高い利益を出していても、それは「計画」と言う答えから外れているという時点で、マネジメント上は失敗です。なぜなら、計画と言うのは「見積り」の元になったプロジェクトの進め方そのものだったはずだからです。金額見積りはそれらの活動工数に、実際に従事する人たちの単価をかけているにすぎません。ですから、どんなに黒字になろうとも、仮に想定より利益率が高かろうとも、それは

　「マネジメント精度が低いゆえにそうなった」

だけであって、「計画・見積り精度が低い」「メンバーを計画通りにコントロールする能力が低い」と言ったマネージャーの資質が疑われることに変わりはありません。もちろん、ステークホルダーによって計画が乱されることもありますが、むしろそんなことは最初からリスクとして想定できてしかるべきことですので、"回避"・"低減"・"転嫁"などのリスク対策を講じておくことができるはずです。

黒字が大きければ大きいほど会社は諸手を上げて喜ぶでしょう。ひょっとすると出世させてくれるかもしれません。ですが、肝心の「マネジメント」のスキルは粒度が粗く、精度が低く、お粗末な結果となる実力しかないことは確かなわけですから、もしも出世できたところで身にそぐわないポジションでの重い責任は、その後の人生を辛いものに変えることだってあります。ハロー効果やピーターの法則がまさにそのいい例です。

経営者は、今一度「人事評価」のあり方を考えた方が良いでしょうし、これから出世する人たちは「マネジメント」の正確性についてもう一度自省し、研鑽した方が良いと思います。

そして、プロジェクトが計画的に進まない要因は色々なサイトでも報告されていますが、たいていの場合は

　・どう進めば、あるいはどうなれば正しいのか定義されていない
　・どう進めば、あるいはどうなれば正しいのかマネージャが知らない

という問題に尽きます。何を以って「成功」かを知らない人が、チームが、何を以って「成功」かを知らないままプロジェクトを進めても成功する確率は高くはありません。

成功を評価するための「答え」とは、言い換えれば「目標」であり、行き着くべき「ゴール」です。これが一つひとつの活動に対してあらかじめ用意されていないのです。

現状の課題１

目標や成功基準が不透明な（どうすることが正解かを定義しない）ままで進むとどうなるでしょう。

おそらくはメンバーは、手探りで作業を進めることになります。ちょっとしたベテランの場合、過去の経験則を参考にして、自分なりに「答え」を作って進めると思いますが、ベテラン一人ひとりが持っている「答え」はチームになった時点で必ずしも揃うとは限りませんので、チーム活動としてはバラバラになっている可能性が出てきます。

通常のプロジェクト活動において、スケジュールを立てたにもかかわらず、スケジュール通りに進まない理由は、「スケジュールに無い作業」「スケジュールで見込んだ作業以上のボリューム」が発生している証拠です。

メンバー層になると、たいていの場合は、スケジュール通りに作った後に頻発する「指摘」や「不良」が想像以上に多すぎて、あるいは想像そのものが少なすぎて（無さすぎて）、スケジュールと現実が乖離してしまうケースが殆どだと思います。こうして発生する作業を総括して手戻りと言います。

この手戻りは、ある程度は計画時点で見込まれている（はず）ものの、その想定を超えた場合、スケジュールに歪みが生じます。この時、スケジュール通りに進めようと思えば残業や休日出勤が発生し、残業を抑えようと思えばスケジュールを延長するか、人員を増やすしか方法は無くなります。

こうして、プロジェクトは歪に進められていくことになります。

これは、ときに「お客さまのせい（外的要因）」で発生することもあると思います。そういう経験をしたエンジニアも多いことでしょう。ですが、もしそう認知できているなら、２回目以降のプロジェクトでは「何を疎かにしたから、お客さまから要求を引き出せなかったのか」「何の確認が取れていなかったから、あとで当初と違う要求に変わってしまったのか」など原因を特定し、対策を打つ機会は設けられたはずですし、実際にそうすることができるはずです。

その「振り返り」を疎かにしたまま、幾度も同じようにお客さまに振り回されているようでは、正しいマネジメントが行えているとはいい難いでしょう。

指摘や不良の量は、そのまま手戻り工数に比例（∝）します。つまり、指摘や不良を圧倒的に減らすことができれば、ゼロにすることは難しくても、手戻りはグッと減少するはずです。その分、時間的余裕が生まれれば、他の作成作業の品質も向上することになります。

私の過去経験から言えば、１／８～１／１０程度に圧縮できると見込んでいます。

指摘や不良がある段階から急激に増えるのは、その活動、その成果物に対する明確な「答え」が存在していないからです。

　「どう書けばいいのか」
　「どう進めればいいのか」
　「最終的にどうなっていればいいのか」
　「何を確認すればいいのか」

そういった一つひとつの「答え」が用意されていないため、一人ひとりが自由に作成し、一人ひとりが自由に確認しようとします。だから、すべてが「後出しジャンケン」方式になってしまって、レビューやテスト時に指摘件数／不良件数が増大してしまうわけです。

そして、手戻りコストが、見積り当時の想定規模を超えた場合、見積りと手戻りそれぞれのコスト／スケジュール数値が乖離し始めます。

マネージャーのみなさんは、各工程、各作業あたりに手戻りが発生するコストはどの程度と見込んでいますか？

この見込みに画一的な絶対値なんてものは存在しません。
企業としての平均値なんてものは役に立ちません。

メンバーのスキルやチームの体制、マネージャーの用意するルールの質などによって大きく変わるからです。大手SIerの中には、たとえば「不良件数」などの定量的な基準値がざっくりと用意されていることがありますが、１件あたりの不良の質や規模によっては、かかる工数がどの程度になるのかわからない場合もあります。

それでも仮説を立てて、「仮に」立てるとしたらどうしますか？

あくまで一例ですが、

　「一人当たり、平均10件／100ページの指摘があるとして、
　　一件当たり、平均30分の修正、15分の再確認を要するとした場合…」

と言った具体的にイメージできる見積りをされているでしょうか。もしされていれば、初回は実績とズレていたとしても、２回目以降は微調整をしていくことで、どんどん精度が向上していくことでしょう。もしも、メンバー一人ひとりごとにデータを取っていれば、詳細な計算ができるかもしれません。

ですが、それでも先に「答え」が用意されていないプロジェクトでは、レビュアーを担当する人が変わるたびに、「指摘するチェック観点が異なる」「気になったからと言う理由で急に厳しく見られる」など、作成者にとっては、どんなところを気を付けて作成しなければならないかがわからないまま進むため、手戻りコストをまともに見積もることすら不可能になっていくのです。

たとえば、「プロジェクトの進め方」に対して答えが用意されていない場合、マネージャーの経験やスキルによって、全く異なる結果となります。

結果、上記のようなことがよく起き、スケジュールが形骸化していきます。

たとえば、「各種成果物の作り方」について答えが用意されていない場合、エンジニアの経験やスキルによって、全く異なる結果となることでしょう。

結果、画一的に立てられたスケジュールは、その効果を示さず、形骸化していくことになるでしょう。形骸化すると、たいていの場合は、

　・スケジュールそのものを使わなくなってしまう
　・毎週のようにリスケ（再スケジュール）する

と言った事態に陥り、前者であれば本当に期日までに納品できるのか図れなくなってしまい、後者であれば管理作業が増大し、マネージャーが疲弊または潰れてしまうことになるでしょう。

そして、「品質保証（レビューや確認）の仕方」に答えが無い場合、作成者はどんなところに気を付けて作成すればいいかわからず、実際に見てもらうまで正解かどうかもわからないため、常に"後出しじゃんけん"形式のチェックしかしてもらえず、全く意図しない成果物を作った場合は、一から作り直さなければならないような事態に陥ります。

プロジェクト内部において、手戻りが発生する理由は大抵こんな感じです。

現状の課題２

コミュニケーション（情報の伝達と共有）が不足している場合、課題１のように「答え」があっても無くても問題となり、手戻りが発生することがあります。

以前からお伝えしているように、コミュニケーションとは

「情報の伝達」と「情報の共有」をすることです。その実現手段として、「話す」「聞く」「書く」「読む」などの具体的行動があるだけです。逆にいえば、それぞれの具体的行動は「情報の伝達」と「情報の共有」という本質的な目的が果たせる内容となっているのかどうか、しっかりと確認できている必要があると言うことです。

これができていない最たる例が「いった／いわない」の水掛け論です。伝達が仮にできていても、共有ができていない、あるいは共有状態が維持できていない時点で、コミュニケーションは成立していないのと同じ結果を生み出します。

ゆえに、コミュニケーションの目的が成立するのであれば、どんな実現手段を用いてもかまいませんが、目的そのものが達成できないやり方をする以上は、必ず認識齟齬や情報不足による行動品質劣化、ひいては成果物品質劣化を招きます。

そして、それはなにも「個人⇔個人」の双方向コミュニケーションだけをさしているわけではありません。「マネージャー⇔メンバー」などの１対多を指しているわけでもありません。

　現在の自分から、未来の自分へのコミュニケーション
　現在の担当から、次工程以降の担当へのコミュニケーション
　現在のプロジェクトから、次プロジェクトの担当へのコミュニケーション

と言った時間軸観点でも見なければなりません。

みなさんは経験ないですか？

既存システムの改修や改造、機能追加、あるいは再構築（Replace）プロジェクトにおいて、既存リソース（設計書やソースコード）を調査していると嫌になってしまうくらい酷い内容、エビデンスだったりしたことは。

私は、以前からお伝えしているように数多くのトラブルプロジェクトに火消しとして参画してきた経験上、ものすごい量の駄作を見てきましたし、ものすごい量のストレスを溜め込んできました。

みなさんは、作る側としてはともかく、それを読む側として辟易したことは無かったでしょうか。そして、コスト低減のために、そういった酷いつくりの既存リソースをそのまま流用しろと言われて、つらい思いをしたことは無かったでしょうか。

そういうことです。

酷いつくりのモノを再利用すれば、余計な縛りができて、良いものが作れなくなってしまいます。スパゲティ化した成果物を紐解いて、解読する調査にも時間はかかりますし、読みづらくて見落とすようなことも出てくるでしょう。「適切な日本語は一切使わずに、会話しろ」と言われているようなものです。

このように、時間軸を超えたコミュニケーション（情報伝達／情報共有）も意識して作るようにしなければなりません。

また、各工程ごとに作成する中間成果物は、原則として次工程以降に必要となる引継ぎ情報となります。そのため、工程間コミュニケーション上、本当に必要な情報の欠落があるような作り方をしていると、そのアウトプットをベースに次工程以降は進むため、必ず欠落した状態のまま進むことになります。

これは、「設計書」１つとっても、

　次の工程へのコミュニケーションツール

であると言う意識がない限り、絶対にどこかで失敗します。

ですから、私は「テスト」だけでなんとか品質が保証されるような開発プロジェクトなどと言うものはこの世に存在していないと思っています。

そして、こうした問題をプロジェクト内で吸収できなくなりがちなのは、次のような背景が起因しています。

お客さまのリソースには「要望」と言う情報の他に「予算」と「期限」があります。

　・どんなことを実現してほしいのか
　・それはいつから実現したいのか
　・そして、いくらくらいで実現してほしいのか

これらは常にセットです。そして常にバランスが取れていなくてはなりません。どれか１つでも「あぁ、適当でいいよ」なんて言ってくれません。ですが、上図のように「要望」が色々あるにもかかわらず、予算限度枠はそこまで余裕がありません。あわよくば少しでも安くしたいと考えています。しかも、スケジュールはそれよりももっと短納期で、できるだけすぐに欲しいと思っています。

これが、一般的なお客さま側の都合です。

ＩＴ企業側は、さすがに指定された予算、指定された期日に納めるために現実的となる調整を行います。この時、大半は「要望から、実現対象スコープを絞る」と言う選択を取ることでしょう。お客さまの「要望」はたいていの場合、「出来れば欲しい」「あったら嬉しい」と言った、必須ではないものも含まれていますので、そういった贅肉を削ぎ落とそうとします。

が。

それはおそらく、スケジュールギリギリで、しかも手戻りをあまり考えないパッツンパッツンの内容となっているはずです。なぜなら、ただでさえお客さまの当初の「要望」を削っている手前、あまり余裕があるように削ると、心象が良くないと思っているからです。結果、一切の失敗が許されない、針の穴を通すような完璧な進行の上にやっと成立する開発が求められるようになっていることでしょう。

ですが、そうは問屋が卸しません。

お客さまはプロジェクトが進行していく中で、少しずつ「要望」がハッキリしてきて、どんどん要望（仕様）の追加・変更を依頼してきます。ＩＴ企業は、自分たちが指摘や不良が多いためにお客さまに迷惑をかけていたりすると、赤字にならない範囲である程度受け入れてあげようとします。

でも、予算的に受け入れたところで、スケジュール自体が変わらなければ、その歪みは「稼働時間を増やす」「人員を増やす」のいずれかで対応しなければならなくなります。ですが、残業で疲弊させてもパフォーマンスは落ちていくし、徐々に属人化が進んでいってしまいます。また、急に人を増やしたところで、これまでの経緯を知らないメンバーのパフォーマンスは上がりませんし、むしろ既存のメンバーの負担を増やすことにもなりかねません。

そうして、逼迫しすぎてプロジェクト作業そのものが破綻し始めてくると、お客さまに泣きつき、リスケ（再スケジュール）をさせてもらうように調整するわけです。この時、予算の調整が難航すると、プロジェクトは赤字へと転落していくことになります。

かと言って、途中で逃げ出すようなことがあれば、契約次第では損害賠償金の支払いを求められることになりかねません。逃げ出すことも許されず、心身ともに疲弊し、唯一許される逃げ道として身体を壊す結果となってドロップアウトしていくわけです。

これが、ＩＴ業界の闇です。

そして、多くの大手SIerが長年実施し、多くのエンジニアを苦しめてきたやり方ではないでしょうか。

こういうサイトが立ち上がるのは、そのためです。ここで出てくる常駐先と言うのは、ほとんどがユーザー企業の現場ではありません。大手SIerのビル、または大手SIerがプロジェクト活動のためだけに借り上げた賃貸ビル／フロアばかりです。

このサイトの調査でもあるように、手戻りは後工程になればなるほど、大きくなります。まぁそりゃそうですよね。手戻りっていうくらいなので、「どこまで戻るのか？」の距離が長ければ長いほど、作業量はそれに比例して増加するようになっています。プロジェクト発足時、あるいは工程開始時に初期投資として「答え（ルールや基準、手順、標準など）」を明確に作る面倒さとコストを考えても、こうした問題が起きた時の損害に比べれば、些細なもののはずです。

また、ちょっとした「答え」のあり方、本質を理解しようとしないがために、不良や指摘が出るたびに類似見直しをしろと強制するSIerやマネージャーをたまに見ることがあります。

もし、テストで不良を発見しても、チェックリスト（試験仕様書）の内容に不備が無かった場合、そのままテストを続けていっても、必ず類似不良は検知できるということですよね。

にもかかわらず、盲目的に類似見直しをさせると、品質は変わることなく、実際に発見する不良の数が変わることもなく、ただただ「調査に要したコスト」だけ大きく差がつく結果となってしまいかねません。

こんな無駄な時間を使うくらいなら、

　設計書（仕様書）⇔チェックリスト間

のコミュニケーションがどうあるべきなのかを定義し、実施するようにした方がマシだと思いませんか？

解決方法

既にフレームワーク…と言うか、開発モデルとして私の中には、これまで述べてきた問題を解消する答えは具体的にできています。

とは言え、こうした問題は「プロジェクト」の中で、

　・どんな進め方にしようと思っているのか
　・どんな成果物を作ろうと思っているのか

・・・つまりは、定型化された開発体系がある程度ハッキリしていないといけないため、微妙に調整が必要になってきます。

私が作ったモノはそのまま使えばいいわけではありません。あくまで抽象化されたモデル／ガイドライン／マニュアルなので、プロジェクトごとの進め方や成果物、及びその様式などによって、適宜、テーラリングが必要となっていくことでしょう。こればかりは、色々なプロジェクトで活用しながら、そのフィードバックをもらっていかないと、詳細化することは難しいかも知れません。

ただし、ボディとなる開発体系さえあれば、それに対して衣服のように簡単に着せ替え出来る私のモデルは、フレームワークのようになっていて簡単に着脱可能となっています。既に存在しているチームにとって進めやすいマネジメントからのスイッチングコストは、あまりかからずに進めることが可能になります。

どこかのコンソーシアムなどで発表でもしたいところですが、そういった機会が今のところないので、いずれ解決方法も公開したいと思いますが、今はここまでとしたいと思います（まだ、noteで有償化する予定もないですし）。