プロジェクトマネジメント講習「目指せスーパーPM」

80/20の法則を取り入れる

（20％の重要プログラムが機能の8割を実現する。）パレートの法則（イタリアの経済学者ヴィルフレド・パレートが発見したべき乗則）

【重要プログラムの見極め】

• 機能に優先順位をつける。
• 重要機能から優先的・段階的に開発する計画を立てる。
• 重要機能を実現する最低限のプログラムをリストアップする。
• フェーズ１開発は、最低限のプログラムの完成を目標とする。
• プロトタイプシステムを基盤ソフトとして有効利用する。
• フェーズ１開発完了までに、全体機能の内、優先度の低い機能を「可能な限り大量に（＝できれば全体の20％以上の機能）」削減する作戦をとる。

システム開発において仕様変更をなくす事は困難である。

しかし、仕様変更の発生＝失敗プロジェクトの第一歩と考えるべきである。

• ユーザーインタフェース（操作画面、入力画面、出力表示などのヒューマン＝マシンインタフェース）が、開発項目に含まれている場合、なによりも先に、このインタフェース部分のプロトタイプ作成を計画するべきである。

【プロトタイピングが必要な主な理由】

1. プロトタイプは容易に変更可能であることから、柔軟性に優れたシステム開発の基盤となりえる。
2. UIが早期に目に見える形で実現することで最終的にどういうシステムになるのかユーザーが予想できる。
3. 企画者～開発者間で活発な意見交換が行われ、仕様変更機会を早期に実現する。
4. 仕様凍結を早期に実現させ、開発費用を抑える事ができる。
5. プロトタイプが基盤となり、開発メンバの仕様把握が促進され品質が高まる。
6. システム開発が加速される。
7. 性能・品質目標を定める事が容易になり、かつ評価しやすい環境を提供する事が出来る。

【ポイント】

プロトタイピング手法をとる場合、全体工程の10％以上を費やしてはならない。さらに、全ての機能が納期までに完成できるという幻想を防ぐために、後述する「搭載できなくても問題ない機能」を中心に説明するべきである。

機能割のチーム構成から役割単位への構成へ

チーム構成を計画する場合の注意事項

1. 各チームの役割を明確にする（作業内容、期間、成果物、中間成果判定）
2. 共通化できる作業項目を集約し、さらに分析を行い、効率化を考慮する
3. 各チームにはリーダーを設置し、リーダー集会を定期開催する
4. リーダー集会では以下の確認を行う

• 進捗状況
• 成果物確認
• 問題点に対する情報交換（気軽に意見交換できる事が重要）

チーム運営のポイント

PMOは常に以下の視点でチーム毎のパフォーマンスを監視する必要がある。

もし問題がある場合は、チーム構成員の変更、計画の変更が必要。

• リーダー、構成員のスキルと作業内容がマッチしているか？
• 作業ボリュームに無理はないか？（No残業で計画できる事が必須）
• 問題検出のタイミングが適当か？（もっと早期に検出されるべき問題は無いか）
• リーダー～構成員、リーダー間のコミュニケーションに問題は無いか？

周辺システム構成がプロジェクト管理に影響する事に注意

• 各周辺システムの機能配置の考え方、確定方法　（性能重視？メンテ性重視？拡張性重視？）

システム開発のポリシーとして重要な事項です。何を実現するために計画を作るのかはっきりさせましょう。

• プログラム開発規模に対する影響
• システム性能に対する影響
• 障害発生時対策に対する影響
• システム運用に対する影響
• 移行作業に対する影響
• 保守性、拡張性に対する影響
• 試験計画（テストケース設計、テストデータ設計、手順、検証方法）

周辺システム構成図から関連リスク要因を拾い上げ、

プロジェクト管理対象として認識・計画・管理する

• 開発体制・管理体制における考慮
• 作業分担における考慮
• 工数・費用・作業項目など見積りに対する考慮
• 進捗管理方法に対する考慮
• レビュー方法や中間成果の確認方法に対する考慮

 

要員推移表の作成ポイント

特にキーパーソンがネックにならないように配置する

有効なキーパーソン配置の例

• システム企画者 ⇒　フィールドトライアル計画者
• システム設計者 ⇒　システム試験計画者
• 詳細設計者 ⇒　単体試験・結合試験計画者

• チームリーダー ⇒　遅延しているチームへの管理強化
• システム設計者 ⇒　詳細設計が遅延しているモジュールの助っ人
• スーパーエンジニア⇒　品質・性能が上がらないモジュールの助っ人

要員推移表を作成したら・・・

• キーパーソンが同時に2つ以上の業務を兼務してはならない
• 上記のようなケースを想定し、事象発生時でもキーパーソンがシフトできるよう考慮
• 以上をチェックし、要員推移表を最適化することが重要。

俯瞰図の作成

まずは、以下のような資料が整った時からマネジメントが始まるものと考えてください。大抵の場合、なんらかの理由で資料が欠けていたり、不十分だったりします。そのプロジェクトが「不完全な状態である」と認識してください。 PMはこれらの資料を上流工程が始まる前、全体工数の見積り作業と並行で作成しなければなりません。

プロジェクトが窮地になると、なぜかセットで「納期を前倒ししたい」という話が出てきます。なぜそうなるのかは不明ですが、過去の経験からみても、必ずと言ってもよいほど発生する事象です。

登山の例でいえば、怪我をして動けないのに、早く帰って来いと言われるようなものです。 また、システム開発の計画において遅延が発生する可能性は必ずあると考えなければなりませんが、計画の前倒しについては、何も犠牲を出さずに実現する事は不可能と断言してもよいでしょう。

たいていの場合、お客様や上司から前倒しの要求があった場合に、「機能を削減すれば可能です」と答えれば、「お前は馬鹿か？もう一度考え直してこい！」と怒鳴られるのが落ちです。しかも機能を削減しても、結果的に、思惑どおりにスケジュールの短縮ができない場合がほとんどです。システム開発というものはそういう摩訶不思議なもので、人間社会が作り出す混沌を絵に描いたかのように流れていくようです。

はじめから余裕をもった計画を作るしかない

不測の事態（しかし当たり前のように起こる）に備えて、貯金（時間と予算）を蓄えておく事が最も簡単で、安全な方法ではないでしょうか？しかし、いつもプロジェクトの最初から参加できるとは限りません。途中から参加したプロジェクトで不測の事態が起きたら（いや、絶対に起きるのですが）どうするか・・・それは後述したいと思います。

絶対に、人を犠牲にしてはいけない

システム開発は、人間の頭脳によって築きあげられるものです。工数、人月という用語を使うため、人足作業と同等に考えられることが多いのですが、最も高度な環境下では全く異なる発想が必要です。

本当に優れたプログラマがいれば、100人月の仕事を1ヶ月で仕上げることが可能。これが実際にありえる事実なのです。ですから、システム開発の状況が良くないからといって、むやみに残業させたり、不眠不休で働かせるなどもってのほかです。

むしろ状況を正確に判断し、現実的な対策を検討し、余分な作業を排除して効率を最大限に向上させる・・・これが、管理を行う者の責務なのです。優秀な管理者が存在するチームでは、いつも笑い声が絶えません。チーム全員が明るく、前向きに、仕事を楽しんでいる・・・そういう状況を作り上げることがマネージャに求められる必須条件です。

マネージャー＝上司という考え方から脱却する

本土決戦の日本軍的玉砕作戦などビジネスの世界ではそもそも通用しません。プロジェクトの組織は軍隊とは違うのですから、上司/部下の関係は、会社組織では存在しても、プロジェクトの中では誇示してはいけません。部下という意識を植え付けられた担当者は、上司だというPMに対しては、決して現場の状況を正確に伝えることはないでしょう（査定にひびくかもしれないから）。

 PM、チームリーダーのあるべき姿は、そういった権力とは全く違うレベルで、個々の役割の中でどれだけ能力を発揮できて、PMのやるべき仕事を全うできるかにかかっているのではないかと思います。

プロジェクトを管理する3つの目的は、相互に影響・関連しあっているもので、切っても切り離せない構造となってい、あす。

それぞれの目的を達成するだけではなく、バランスが肝心であり、かつ全ての要素が「人」によって実行される事が、複雑性を増している原因となっているのです。

プロジェクト管理は
登山や航海に例えられることが多い

登山に例えられる例･･･

• 装備は大丈夫か？・・・　プロジェクト事前準備
• 健康状態は？ ・・・　スキルマッチ状況
• ルート選定は？ ・・・　スケジュールの作成
• 天候状態は？ ・・・　ステークホルダーの状況
• 不意の事故は？ ・・・　コンティンジェンシープラン

などなど・・・

しかし・・・全く登ったことのない登山には、必ず経験者（ガイド）をつけるものだが、システム開発においては、「世界中探しても経験者がほとんどいない前人未到の境地」である場合がほとんどなのです。

従って準備周到であっても何が起きるか分からない、冒険と考えるべきで、緊急時にどうすべきかを考えておくべきだと思います。

【不定期連載予定】

この講習では、システム開発における全体の流れの中で、一般的に知られているソフトウェア工学の教科書には載っていないような事項を織り交ぜて、プロジェクト管理のポイントをお話したいと考えます。

一部、個人的な経験をもとにご説明を進めるため、ご異論もあるかと存じますが、一つのアプローチ方法であるとお考えいただきたくお願いします。