PMstyleはこちら	第５４回（2004.04.29）　 「プロジェクトの難しさ（１）」
◆大規模プロジェクトのマネジメント 　ブログにも少し書いたが、読者の方から興味深い指摘を戴いた。それは、プロジェクトの規模によってプロジェクトマネジメントの方法が違うのではないかという指摘である。 　今回の戦略ノートはこの問題についてみなさんと議論する機会がもてればと思っている。 　プロジェクトマネジメントに限らず、この規模の問題というのは結構、頭を悩ませる要素である。システムの規模が大きいと仕事は難しくなる。これは、マネジメントであろうが、設計であろうが、開発であろうが同じだと思う。 ◆難しさの厳選 　大規模なプロジェクトやシステム構築の難しさというのは２つの種類がある。ブログでは量と質という表現をしているが、もう少し、正確に書くと、資源投入でプロダクトの品質が確保できるものと、資源投入では確保できないものだ。 　たとえば、自動車を１台作るプロジェクトと、同じ自動車を１０台作るプロジェクトを比較する。その場合、投入資源（要員、設備、コスト）を１０倍に増やせば同じ「同じ納期で、同じプロダクトの品質」を確保するのは難しくない。 　さて、ここまではそんなに異論はないと思うが、ここで重要なポイントがある。現実には１０台の自動車を作るプロジェクトで、１台のときの１０倍の資源投入することが現実的かどうかだ。この例だと明らかに、違う。１０倍を投入することはありえないだろう。せいぜい、５倍程度か（公共工事なら１０倍投入するが） 　すると何が起こるか？資源を有効に活用するマネジメントが必要になる。これが、大規模なプロジェクトの一つの難しさだろう。 ◆マネジメントコスト 　もう一つの側面がある。それが、マネジメントコストの問題だ。上の議論は、プロダクトプロセスに対する資源投入の議論であるが、当然、マネジメント量も増え、マネジメントに対する資源投入を考えなくてはならない。具体的には 　プロジェクトマネージャーを複数体制にする 　リーダーを作ってマネジメントスパンを細分化する といったことが必要になる。ブログにも書いたように、僕は本当の意味での複数マネージャー体制を引くような規模のプロジェクトマネジメントを経験したことがない。従って、想像に過ぎないが、本を読んだりした大規模プロジェクトでもっともやっかいなのはここではないかと想像する。 　この分かりやすい例は、マイクロソフトのオフィスの開発だ。クスノマのマイクロソフトシークレットによると、複数のプロジェクトマネージャーが、オフィススイーツのそれぞれの製品を担当している。オフィスのような正確の製品は市場における競合製品の状況とともに、開発中にどんどん仕様が変わっていく。各プロジェクトマネージャーはマーケティング機能を併せ持ち、オフィスプロジェクト全体で調整をしていかなくてはならない。 　プロジェクトの規模が大きくなると、部分最適と全体最適がうまく一致しない。ここが難しい点だろう。 　さて、好川からのインプットはここまでにして、この件について、読者の皆さんからの意見を募集したい。 【意見募集】 　プロジェクトのサイズが大きくなったときに、留意すべき点はなんでしょうか？ ◆関連セミナーを開催します ━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆プログラム＆プロジェクトによる価値創造の進め方　　　　　　　　　　　　　　 ◆7PDU's 　　日時：2017年 06月 06日（火）10:00-18:00（9:40受付開始） 　　場所：ちよだプラットフォームスクウェア（東京都千代田区） 　　講師：好川哲人（エムアンドティ・コンサルティング） 　　詳細・お申込　http://pmstyle.biz/smn/initiative.htm 　　主催　プロジェクトマネジメントオフィス、PMAJ共催 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ 　　【カリキュラム】 　　　１．プロジェクトによる価値創造のためのマネジメントとは 　　　２．プロジェクト・イニシアチブの実践 　　　（１）プロジェクト・イニシアチブの構想と計画 　　　（２）ポートフォリオによるインパクトのデザイン 　　　（３）プログラムによるインパクトのマネジメント 　　　（４）価値を創造する個別プロジェクトの構想、計画、マネジメント 　　　３．プロジェクト・イニシアチブの構想演習 　　　４．プロジェクトによる価値創造の実際 ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
前の記事 | 次の記事 | 記事一覧
著者紹介 好川哲人、ＭＢＡ、技術士 株式会社プロジェクトマネジメントオフィス代表、PMstyleプロデューサー ２０年以上に渡り、技術経営のコンサルタントとして活躍。プロジェクトマネジメントを中心にした幅広いコンサルティングを得意とし、多くの、新規事業開発、研究開発、商品開発、システムインテグレーションなどのプロジェクトを成功に導く。 １万人以上が購読するプロジェクトマネジャー向けのメールマガジン「PM養成マガジン（無料版）」、「PM養成マガジンプロフェッショナル（有料版）」や「プロジェクト＆イノベーション（無料）」、書籍出版、雑誌記事などで積極的に情報発信をし、プロジェクトマネジメント業界にも強い影響を与え続けている。 メルマガ紹介 本連載は、「PM養成マガジン」にて、連載しております。メルマガの登録は、こちらからできます。
スポンサードリンク
読者からのコメント
1. 根本的に「末端までの意識共有」 2. (今後)ITSSで言う基盤技術構築スキル（＝「ITアーキテクト」）の高い要員の確保 3. ＰＭ方法論（特に、レビュー方法やリリース承認・管理）として、効率的ツールの適用 Tadamasa（３２歳・ＦＪＢ） ２．の意見は大変、参考になります。 プロジェクトマネジメントの中で構造を捉えるツールはＷＢＳだけで、成果物の構造は作業の構造に反映されるという前提になっています（大体、ＰＭ本のＷＢＳの説明をみても意図的にそのようなものを出している）。これは不十分だろうと思っています。構造といっても物理的な構造もあれば、論理的（機能的）な構造もあり、どちかを反映させるかという議論すらありません。 そのような前提で考えた場合、アーキテクトがきちんといないとまともなプロジェクトの計画はできないと思います。その意味で同感です。 ちなみに、弊社では、今、この問題を解決しようと考え、ＷＢＳとＱＦＤとＯＢＳを併せて、タスク分解をする方法を開発しています。 好川哲人 2000人月規模のプロジェクトの経験より。 100人月程度で当然できたことができなくなった経験が多かったと思います。 実際には割り切りが必要だったと思います コスト面 ・コミュニケーション工数の増大 　中間リーダー層は業務時間中はほとんど打ち合わせだけで消化 　サブシステム仕様、共通機能\仕様の調整工数なども必要 ・サブシステムI/F数が多いほど不整合リスクが上がる（予\備費の計上が必要） ・段階的サービスインを行うことが多くなり、テスト工数が重複する （似たようなテストを繰り返す必要あり）→段階数に応じた工数上乗せが必要 （政治的に早期に効果を出さざるを得ない例が多い） スケジュール面 ・特定のサブシステムが遅れ「追いつき」が発生する（要員の集中投入が発生） ・段階的サービスインに伴うテスト（段階的結合テストが発生） ・局面化の遵守困難（個別に追いつかせる必要あり） 品質面 ・変更対応の「ゆらぎ」の大きさ（影響工数が相対的に大きくなる） ・パフォーマンスの良くない要員の増加：適宜入れ替えが必要 ・標準化の困難さ（HOSTとWEBなど仕組み的に相容れない部分が多い） ・成果物の定期チェックが必要（開発されていない部分やドキュメント不在が 　発生する） ・管理が行き届かない部分の発生（大規模になるとどうしても「穴」が発生する） ・ユーザー、ステークホルダーマネジメントが必要 　（管理対象が増加し、それそれ言うことが異なり、変更対応が複数発生） hama-（３５歳・プロジェクトリーダー） 2000人月というのは、総工数でしょうか？それともピーク時でしょうか？総工数で2000人月というとピークは300〜400人だと考えればいいですか？ 　いずれにしても、丁寧に整理をしていただき、好川だけではなく、読者の方にも大変、貴重な情報ですね！ 　「ゆらぎ」の大きさのところで、相対的に大きくなるとありますが、コミュニケーション（軌道修正）が遅くなるといったこともあるんでしょうか？ 　hama-さんが「割り切り」が必要だと書かれていますが、ブログで紹介した読者の方が好川の主張が実務感覚と合わないと違和感をもたれているところは、拘りがありすぎるところだろうと推測しています。 　僕が常々、思っているのは、「割り切り」が必要なのですが、割り切りも背後にロジックが必要なのではないかということです（判断が正しいかどうかはともかく、判断に至る筋道があること）。ただし、最終判断はロジカルでなくてもいいとも思っています。「積み上げて考えると、要員投入をした方がいいけど、直感的にここは待ちだな」といった判断って必ずあるように思います。その場合も、「積み上げて考える」というのは大切なプロセスだと思っています。 好川哲人 プロジェクト全体が把握できる仕組みを作るのが最優先事項だと思います。 私は、あるPM研究会に所属していますが、そこでも同じような議論がされました。 そこでの結論としては、PMとして把握できる規模にプロジェクトを分割することを検討したら良いのではということになりました。 では、PMが把握できるプロジェクトのサイズはというと、、、。 PMの経験にもよるので一概には言えませんが、5000万円規模という意見が多かったですね。 noshi（３９歳・自営業） 大きくなったときに、というよりは、大きくすることで複雑さが増してコントロールが難しいことがわかっている＝成功確率が下がるので、プロジェクトのサイズを大きくしないことに注力する。どうしても大きくなる場合は、プロジェクトマネージャがマネジメントできる範囲で区切る。（サブシステムごととか、段階C/Oとか） 匿名希望 なるほど！ 何を把握するのかも大切な気がするし、把握するものによって把握できる規模が変わってくるような気もします。そんな議論はありませんでしたか？ 好川哲人 経験上、コミュニケーションの保持が一番難しいと考えます。コンタクトするチーム、メンバー、関係部署、顧客、ベンダー等ステークホルダーの数はプロジェクトの規模に比例しますので、より円滑なコミュニケーションは不可欠です。PM一人で全員を相手にするわけにもいかないので、自分やプロジェクトとしての意図を汲むリーダをいかにコントロールするかにかかっているのではないでしょうか。 Chopper（３２歳・住商情報システム株式会社）