ITプロジェクトにとって、技術力よりもプロジェクトマネジメント力のほうが最も重要であるといわれ始めてから、だいぶ時が過ぎました。そして、今では、ソフトウェア開発の現場は、組織がプロジェクトに介入することになり、管理・監督が隅々まで生き渡ったることになりました。
しかし、これでプロジェクトの失敗は、消えうせることになったかと言えば、まったくそうはなっていません。
なぜでしょうか？
■ 完璧なプロジェクトマネジメントとは何か
プロジェクトマネジメントの目的は、言うまでもなく、プロジェクトを完遂することです。
プロジェクトの管理対象は、以下の３つです。
①品質（Quality）
②コスト（Cost）
③納期（Deadline）
これら各々のバランスを取りながらプロジェクトを運営することではなく、各々を「100％満足」することこそが、
完璧なプロジェクトマネジメントです。
採用される開発手法は、管理を細分化して徹底すればするだけ、プロジェクトを見える化できる「ウォータフォール」一択です。
プロジェクトマネジメントを完璧にするということは、組織が主体となり、「ウォータフォール」を細かく執拗な「マイクロマネジメント」の”仕組み”として仕立て上げることです。
具体的には、各管理対象に対して、以下のようなマイクロマネジメントを実施します。
１）品質
ソフトウェアの品質は、目で見ることはできません。ソフトウェアを動作させることで、大まかな品質の状態を推し測ることはできますが、細部まではわかりません。
そこで、ITエンジニアの発言や行動の記録を残し、その中でミスの数を数え、その品質を推し測ります。
それが「メトリクス」と呼ばれるものです。
「メトリクス」を算出するには、ソフトウェアの開発規模が明確でなければなりません。ソフトウェアの開発規模は、ステップ数です。また、設計書のページ数も開発規模に比例して増えるため、「メトリクス」を算出するために使われます。以下のようなメトリクスがあります。
「メトリクス」は、量的に品質を推し測る指標です。ウォータフォールの工程内で元になるデータが収集され、工程が終了した時点で集計されます。メトリクスは、工程で作り込まれたソフトウェアの状態を「数字」で、推し測るために使われます。
２）コスト管理
コスト管理において重要になるのは、受注の可能性を高めつつ、利ザヤを確保することです。
ソフトウェア開発のコストは、ITエンジニアの人件費がほとんどを占めることになります。
人件費には、社内工数と社外工数がありますが、会社や組織から社外に支払われる”出金”である社外工数は、徹底的に管理されます。
ソフトウェア開発に必要な費用を見積もる場合、見積もり時点で、詳細の仕様まで決められてることは100%ありえません。
それでも見積もりを算出するには、たっぷりとリスク見合いの工数をのせるしか方法がありません。
しかし、多くのケースでは、受注の可能性を上げるため、逆に、リスク見合いの工数はギリギリまで削減されることとも珍しくありません。
不明瞭で、理解できない仕様を無視し、リスクがないものとして見積もることで、表面上、１００％精度が確保された見積もりが出来上がります。
３）納期管理
プロジェクトの進捗を定点監視するため、組織に進捗状況を報告する定例会議を毎週開催されます。
しかし、この会議の目的は、プロジェクトの遅延がないこと、大小の問題が発生していないことを、単に報告するためにあります。
そのために、ITエンジニアは、一週間の仕事を詰めて、翌週の報告の内容を”汚さない”ように、毎週、決まった進捗＝ピッチを刻もうとします。その結果、毎週、組織からの得られる承認欲求を満たすことを中心に、仕事を回すことになります。
こうなると、プロジェクトの全権を掌握し、プロジェクトを牽引するはずのプロジェクトリーダであっても、ただの組織の下僕であり、リーダシップを発揮するはずのモチベーションなどは無用の長物であり、ただただ言われたことを忠実にやるだけの組織の手足として動くことだけが求められます。
■ 失敗する理由
完璧なプロジェクトマネジメントには、本質的な現場での創意工夫が軽視され、機械化が進みます。
組織が期待するのは「労せずして回るプロジェクト」です。
そこに、次のような闇が生まれます。そして、その闇の先には、人海戦術とデスマーチが待っています。
１）品質の闇
メトリクスで管理されることで、そこには歪みが生じます。
ITエンジニアは仕事をする上で、日常的にミスをすることを強く恐れるようになり、
前例を踏襲するやり方しか行わない保身的で、自己の担当範囲だけに固執するようになってしまいます。
ミスをしないようにするには、何も話さず、何もしなければいいという穿った考えが蔓延し、プロジェクトの柔軟性が失われ硬直化していきます。
メトリクスの数字には表れない文字通り「質的」な品質そのものである「問題」が放置され続け、最終的には大きな「品質問題」を引き起こすことになります。
そのメトリクスに潜む闇とは、以下のようなものです。
・レビュー指摘率
レビューに参加した人からの指摘に重要度をつけて、集計します。指摘の重要度には、仕様や設計、コードのロジックを修正する必要のあるものがA、修正するにしても誤記程度のものがB、調査と確認が必要なものがC、質疑や確認事項がDといったようにランク付けされます。
ミスとしてカウントされるのは、AとBの指摘です。確かに、ロジックに関する考え方の間違いは、バグであり、致命的です。テストをする前に欠陥を発見することで、手戻りを無くすことができます。開発効率を上げる意味では効果的です。しかし、逆に言えば、ほぼ間違いなくテストで検出される欠陥でもあり、ある意味、見つけやすいミスです。
質的な面で品質を推し測るためには、CとD指摘を分析することです。その理由は、第三者であるレビューアの過去の知見をもとにした指摘であるため、テストでも検出できない本質的な欠陥であることが多いからです。
・レビュー時間比率
設計書やソースコードをレビューをするために割いた時間とは、ミスの検出に使った労働量のことを意味します。
レビュー時間は、レビュー会議に参加した人数分の積算となりますので、たとえ一言も発言しない人がいても、その時間が加算されます。
つまり、ミスの検出に貢献しない人の時間も水増しされた時間で、品質が判断されることになります。
・テスト項目設定率
テスト項目の数え方に、特に決まりはありません。「一つのテスト」をどうとらえるかは、プロジェクト、ITエンジニア、テスターによって異なります。この「テストの単位」は、時に都合よく変えられます。
たとえば、一連の処理シーケンスを１件と数えるか、それとも、シーケンスの中にある個々の処理を１件と数えるかで、テスト項目数は大きく変わり、テスト項目設定率も変わります。
メトリクスから本質を判断する上であえて使えるのは、残ったバグ発生率と仕様変更数です。
ただし、件数だけではなく、その内容を分析し、発生するに至った理由や経緯を明らかにした上で、対策や変更内容が妥当かを判断する必要があります。
２）コストの闇
見積もりが組織的に合意された場合、以後、変更されることは、まず、あり得ません。
当然、金額が減る分には何も言われませんが、1円でも見積もりした金額よりも増えるものであれば、組織によって拒絶されます。
プロジェクトを進める過程で、見積もりと支払いのギャップに苦しめられます。
発注間際になって、厳しい委託先との価格交渉を担当者に強いられることになるのです。
このようなソフトウェア開発には直接関係ないことに、精神と時間をすり減らす行為が繰り返され、さらに委託先への発注も遅れていきます。
３）納期の闇
プロジェクトに問題がないことなどをあり得ませんし、プロジェクトははじまったときから遅れていきます。
そのため、作業の優先度を入れ替えたり、一時的にコストをかけてリソースを集中させ、問題を解決したりなど、日々やりくりをしながら、どうにかこうにか前進し、最終的な納期に間に合わせていくものです。
本来、それが「マネジメント」です。
遅延や問題を隠蔽するため、実体スケジュール、社内報告用スケジュールの２枚のスケジュールを作成します。当然、社内報告用には遅延がないきれいなスケジュールを提示し、実体スケジュールを使って本当のマネジメントを実施していきます。いわゆる「二枚舌」です。
■ やわらかいプロジェクトマネジメント
数値で表される量ばかりに着目し、質には着目されていない点が問題です。
会議で数字だけが議論され、そこから指示が出て終わりでは、まったく現場感がありません。
失敗しないためには、プロジェクトマネジメントの視点を、量的側面を中心におくのではなく、質的側面を中心に置けるかどうかです。そのためには、作業中心型プロジェクトではなく、問題解決型のプロジェクトへの転換する必要があります。
問題解決型プロジェクトとは、問題の発見と解決を実務の中心におき、組織によるプロジェクトマネジメントはわき役として、問題解決の活動をサポートすることです。問題解決に必要な情報収集のために社内人脈を活用したり、各種事務処理を担ったり、費用などの必要なリソースをタイミングよく提供するといった支援をすることが必要です。
一方で、問題解決を担うITエンジニアは、プロジェクトの主役として、組織から信頼されるように結果に責任を持つ代わりに、組織からモチベーションと自由度を得て仕事にあたることです。
飼いならされたITエンジニアは、下請根性に染まったソフトウェア労働者に成り下がります。野生を失わわず、自らの意見を持ち、地頭を鍛えることが問題解決型プロジェクトで活躍できるITエンジニアの条件です。
そして、管理優先ではなく、つねに、実務優先であることを徹底できるプロジェクトであることが、成功の鍵を握ります。
