Prowise Business Forum in Tokyo 第57回【日立ソ … · ＜プロジェクトの定義＞ - 大規模システムの構築から、小さな組み込みプログラムまで幅広い

© Hitachi Solutions, Ltd. 2012. All rights reserved.

失敗事例から見た、プロジェクトマネジメント～3つの勘所～

Prowise Business Forum in Tokyo 第57回

【日立ソリューションズセッション１】

2012年 3月 13日

株式会社日立ソリューションズ


１．プロジェクトとは２．プロジェクト管理者３．プロジェクトの成功４．成功する（かもしれない）プロジェクト５．プロジェクトの失敗事例６．まとめ

Contents

© Hitachi Solutions, Ltd. 2012. All rights reserved. 2

１．プロジェクトとは

＜プロジェクトの定義＞ - 大規模システムの構築から、小さな組み込みプログラムまで幅広い

案件？タスク？プロジェクト？

・プログラム規模

・期間

・費用

・要員数などで呼び分けている場合もある

- プロジェクトマネジメント協会：「独自の成果物、またはサービスを創出するための期限のある活動」

定義

製品やサービスなどを作り出すために、期間が定められている業務かつ、リーダと複数の担当者で構成されている


２．プロジェクト管理者

＜プロジェクトマネージャという呼び方＞ - 日本の多くの企業では職位によって呼び方が変わる（外資系では職位

に関わらず、役割として定着している）。

・主任/係長：チームリーダ／サブリーダ・・・・・

・課長：プロジェクトリーダ（実際はプロジェクト責任者）

・部長：プロジェクトマネージャの上司（予算等を管理）

- プロジェクトマネージャとは、プロジェクト全体の指揮管理を行う責任者

- プロジェクトマネージャは、組織において新しい成果物を生み出すために立ち上げられたプロジェクトについて、計画の立案、資材や要員などの調達、進行方法の確立や納期、品質、進捗状況の管理までを包括的に監督し、プロジェクトを円滑に推進させる役割を果たす。

定義プロジェクトを実際に動かし、日々の管理を実施している責任者


３．プロジェクトの成功

＜プロジェクトを成功に導くことがプロジェクトマネージャの役目＞期限内に決められた予算金額内で期待レベルの品質・技術成果の元で割当てたリソース（人的資源、物的資源）を有効活用して顧客が満足する状態で完了する

バランス

成功のために

プロジェクトマネジメントが重要

プロジェクトマネジメントの方法は様々・名人が経験と勘に裏付けられた手腕で実施する →しかし、その人がいなくなったら・・・・・ＰＭＢＯＫ®やＣＭＭＩ®などを利用する →多くの企業が取り組んでいる


４．成功する（かもしれない）プロジェクト

5

Ａさんはいわゆる「達人」：・要件定義から設計、テストまで、すべてを高い水準でこなすスーパーエンジニア・プロジェクトメンバからの信頼は厚く・問題が発生しても、人並み外れた集中力で、遅れを取り戻してしまう

Ａさんの力が及ぶ範囲で、プロジェクトは成功する

…でも、Ａさんがいつまでもいるとは限らない・・・


プロジェクトマネジメントが重要・属人的な要素に頼らないマネジメント


５．プロジェクト失敗事例

・仕様が確定しない

・プロジェクトマネージャが作業を担当している（人（組織）の話）

・プロジェクトの状況が正しく把握できていない


「原理原則17ヶ条」

1. ユーザとベンダの想いは相反する

2. 取り決めは合意と承認によって成り立つ 3. プロジェクトの成否を左右する要件定義の先送りは厳禁である 4. ステークホルダ間の合意を得ないまま、次工程に入らない 5. 多段階の見積りは双方のリスクを低減する 6. システム化実現の費用はソフトウェア開発だけではない 7. ライフサイクルコストを重視する 8. システム化方針・狙いの周知徹底が成功の鍵となる 9. 要件定義は発注者の責任である

10. 要件定義書はバイブルであり、事あらばここへ立ち返るもの 11. 優れた要件定義書とはシステム開発を精緻にあらわしたもの 12. 表現されない要件はシステムとして実現されない 13. 数値化されない要件は人によって基準が異なる 14. 「今と同じ」という要件定義はありえない 15. 要件定義は「使える」業務システムを定義すること 16. 機能要求は膨張する。コスト、納期が抑制する 17. 要件定義は説明責任を伴う

※出典：IPA－ SEC「超上流から攻めるIT化の原理原則17ヶ条」より

格言


■仕様が確定しない

• 要件が曖昧なまま作業が進められている

× 担当者個人の判断で作業している

・要件の抜け・漏れが発生する

・無用な仕様が入り込む

× 下流工程になって要件変更が多発する

・納期遅延

× 仕様変更の受入条件が曖昧

・要件の確定期日が決められていない

・要件変更の受入れが個人任せ

・要否回答に時間がかかり、結局、既成事実化し、仕様変更せざるを得なくなる

Why?


■仕様が曖昧

仕様決定のプロセスに問題がありませんか？


事例：仕様が確定しない

11

◆上流工程でQ,C,Dを作り込む（自社の品質方針）はずが・・・・要求（書）が曖昧なため機能仕様が決められない。・機能仕様の設計工程がずれ込む・このような上流工程の遅れから下流工程が逼迫する

不十分な機能仕様

設計作業が混乱ソフト製作工数の圧迫

テストケース不足テスト工数の圧迫

品質（悪）タイムリミットで出荷したものの・・

設計途中で仕様を

確認したり、調整したり・・・

ここからは漏れのないソフト製作はできないし、過不足のないテストもできない

曖昧

曖昧

テスト工数を圧迫


テストチームからのQ&A：「これって仕様ですか？」

12

◆テストフェーズで、仕様書に書かれていない動きをして、バグなのか判断できないシーンにしばしば遭遇する ◆ところが、設計部門に確認すると次のような回答が・・・「それは仕様です」「その仕様には制限を付けました」

◆結局、この１件のQ&Aのために「何時間」も時間を無駄に！「仕様は設計しながらでないと抽出できない」という発想の下では、上記のシーンは永遠に続く・・・

そして、マネージャーは品質が安定しないまま納期が近づいてくる恐怖にさいなまれる


対策手段を訊くと・・・

13

◆対策手段として、・開発側は要求側とF2Fでソフトスペックからの制約を基として、仕様を詰めるようにします、と口では言うが、、、、

しかし、

要求と仕様を互いにイメージしやすいコミュニケーション方法で調整・決定しようとしていない

要求漏れ/仕様漏れ

結局、そのツケは下流工程へ持ち越すだけ？！

制約はソフトスペックだけに依存しない・・・

要求は網羅できたか？

未解決


◆上流工程でQ,C,Dを作り込む（自社の品質方針）はずが・・・・要求（書）が曖昧なため機能仕様が決められない。・機能仕様の設計工程がずれ込む・このような上流工程の遅れから下流工程が逼迫する

14

不十分な機能仕様

設計作業が混乱ソフト製作工数の圧迫

テストケース不足テスト工数の圧迫

品質（悪）タイムリミットで出荷したものの・・

設計途中で仕様を

確認したり、調整したり・・・

ここからは漏れのないソフト製作はできないし、過不足のないテストもできない

曖昧

曖昧

テスト工数を圧迫

ここに問題がある曖昧の元


１．何がソフト製作やテスト作業を混乱させているのか？ → そこで書かれている仕様書（成果物）の出来映えに端を発している

２．要求仕様の表記方法によってソフト製作やテスト作業が変わる ◆仕様書（成果物）の表記を変えてみる

要求仕様

（要求側）

機能仕様

（開発側）

共通の言葉で話さないと、必要な要求は満たされない

■ 概要書や取説のような仕様書からソフト開発ができますか？

要求側と開発側が互いに理解できる資料（成果物）が必要


■仕様書（成果物）の表記を変える

相互理解

気づき気づき

追加や変更要求を明らかにできる仕様書（成果物）

要求側と開発側とが互いに理解できる資料

要求と仕様を適切に決定するには

漏れなく

相互理解

相互理解

・必要な要求が視えてくる・必要な要求を視せられる・仕様が視えてくる・仕様を視せられる

要求仕様

（要求側）

機能仕様

（開発側）


■追加や変更要求を明らかにできる仕様書（成果物）を作るために

・要求を引き出すコミュニケーション

・要求の可視化

・要求の管理

仕様決定プロセスが必要

上位組織主導で改善上位組織はプロジェクトマネジャーの能力も含めて戦略実行に必要な組織能力を見極め、不足している部分を常に改善していく必要がある。




・プロジェクトマネージャが作業を担当している



■プロジェクトマネージャが作業を担当している（人（組織）の話）

• 腕に覚えが有り、担当業務に手を出すマネージャがチームを率いるという意識を持って作業分担や業務の割

当てをしていない

• 他のプロジェクトを兼任人材不足が解消できない中での組織作り（組織問題）

→ 担当分が忙しくなるにつれ、

× レビューに参加できなくなる

プロジェクトメンバーの作業が止まってしまう

× 情報が流れてこなくなる

プロジェクトが混乱

× 進捗などの管理が疎かになる

プロジェクト状況がわからなくなってしまう


事例：PM（腕に覚えあり）がプログラミング

最初は注意程度

仕様で問題が発生

自ら単独で実装を始める仕様のレビューが疎かに・・・

問題部分を修正

責任を取って問題部分を自分で実装

メンバーがテスト実施

不具合発生

手持ち作業が多すぎてダウン

プロジェクト内混乱（内部崩壊）


案件Aが混乱

事例：PMが担当プロジェクトの他に現業を持たされる

案件Aのみ管理

案件A

B案件の担当お願い

小案件B

案件Aの他に小案件Bを兼任（人材不足？コスト最適化？）

案件A

B案件は小規模だし、経験もあるから、大丈夫だろう・・・

案件A 小案件B

案件Bでトラブル発生

案件A 小案件B

案件Bを優先して作業

案件Aが野放し状態

案件A

上位組織の問題！


プロジェクトマネージャの役割

■体制作りと責任分担・プロジェクト体制を整備し、個々の役割・責任分担を明確にする。

・重要な事項に関しては、まずリーダーに、さらにリーダーからプロジェクトマネージャに迅速に報告が伝わる仕掛けを作る。

・メンバーの希望を確認し、できるだけやりたい仕事につかせる。モチベーションや生産性、品質が高まる場合が多い。

・適材適所にメンバー、リーダーを配置する。できる人はリーダー格に抜擢する。

チームを率いているという自覚

一方、組織としてやるべきことは何？

PMの采配


組織の役割

• 上位組織は、プロジェクトマネージャの能力も含めて戦略

実行に必要な組織能力を見極め、不足している部分を

常に改善していく必要がある。（プロセス改善やプロジェクトマネージャ不足解消など）

・開発期間や予算が厳しく制限、技術は専門化／高度化

＜困難な条件で力を発揮できる

技術者の確保難しい＞

最適な組織体制を決める「組織デザイン」が重要

・情報共有やリソース（人・モノ・カネ）

プロジェクトの特性に応じた組織作り、運用する人を育成

上位組織




・プロジェクトマネージャが作業を担当している（人（組織）の話）



■ プロジェクトの状況が正しく把握できていない

• メンバーからの報告内容が曖昧

× 個人毎に報告の粒度や数値の意味が異なる「できている」「進捗率５０％」の意味が個人で異なる、

「盛り返せます」の根拠

× 課題がどれだけ残っているか判らない「概ね順調です」「問題がないことはありませんが大丈夫」

外注任せ、言い値を鵜呑み

• リスクの把握を怠った

× 不測の問題が起きてから慌てる事後対策に時間がかかる

× リスクと課題とを同一表に載せているリスクは未来、課題は現在、ごちゃ混ぜに管理している

※ 協力会社との作業の進め方を曖昧にしてはいけない

一括請負契約の場合は協力会社に成果物責任があるが、それ以外の契約だと成果物責任が無いので、作業の進め方を曖昧にしていると高い生産性や品質を期待できない .


PMの仕事は報告の曖昧さとの闘いである

×あうんの呼吸

→相手に察してもらう文化は通用しない。（例：オフショア開発）

PMは、様々な報告内容からできる限り曖昧さを排除し、正確な状況を把握するように努めなければならない。

PMは、報告者に対して積極的に質問や指導を行わなければならない。

→報告者が曖昧さを排除した報告ができるような報告ルールを定めたり、報告書フォーマットを用意することが重要（仕掛作り）

喫煙所に行くと正しい報告（真実）が聞けるのはおかしい。

「メンバーが報告しなかった」の責任はPMにある

コミュニケーション管理はプロジェクト管理の基盤である

ＰＭ


予兆（危険の察知）

• 会議が予定通り開催できない。

直前の日程変更、先送り

• 報告資料に定量的データが無い。

日頃からデータを把握していない、進捗遅延回復の根拠が示されない

• 状況報告資料を前日徹夜で作成している。

日頃視てない、矛盾する報告、実態との乖離

• 協力会社の作業状況を把握していない。

丸投げ

危険を察知できる仕掛けやチェックリスト

進捗の視える化（ツールでサポート）


６．まとめ

失敗しないための留意点

1

2

3

仕様書(成果物）の表記変更と仕様決定プロセス

不足部分を改善する組織のサポート

危険察知と進捗の視える化


• プロジェクトの手順等のプロセスを明確にして作業する。ＣＭＭＩやＰＭＢＯＫなどを使った成功事例をうまく利用する。

• 外部の要員を使って、プロジェクトの意識改革をする。（客観的に支援（ＰＭＯによる支援）することも必要であるが、そればかりだと、プロジェクトから反発される可能性もある）

プロジェクトと一体となって進めていくプロジェクトマネジメント支援サービス等の利用


「MICrew」関連サービスメニュー一覧

30

カテゴリ分類サービスメニュー

分析・診断 MICrew診断サービス MICrew初期診断サービス

MICrew詳細診断サービス

特化型診断サービス品質詳細診断サービス

CMMI®アプレイザル

開発プロセスプロセス改善活動代行／支援サービス SEPGSM

支援

プロセスQA支援

ソフト調達プロセス改善支援

教育品質関連トレーニングサービス品質管理

プロセスQA入門

ピアレビュー/テスト技法

プロセス改善関連トレーニングサービス CMMI入門

SEISM

公認 TSPSM

/PSPSM

教育

技術・手法受託開発サービス受託開発サービス

プロジェクト管理代行/支援サービスプロジェクトマネジメント(PM)支援サービス

基準類整備支援サービス品質管理ガイドライン策定支援

コーディングガイドライン策定サービス

品質向上支援サービス品質保証支援

第三者評価サービス

ソフトウェア受入検査(検収)代行サービス

ソースプログラム検証サービスソースプログラム検証サービス InspectPro

開発環境・ツール開発環境構築／運用サービスクラウド型組込み開発環境構築支援

開発プロジェクトの計測・分析EPM導入サービス

ソースコードチェッカ

トレーサビリティ向上

状態遷移表設計

テスト自動化

モデル駆動開発

要件管理

構成管理

SPL(Software Product Line)

© Hitachi Solutions, Ltd. 2012. All rights reserved. © Hitachi Solutions, Ltd. 2012. All rights reserved.

失敗事例から見た、プロジェクトマネジメント～3つの勘所～

END

2012年 3月 13日

株式会社日立ソリューションズ

Documents

Prowise Business Forum in Tokyo 第57回 【日立ソ … · ＜プロジェクトの定義＞ - 大規模システムの構築から、小さな組み込みプログラムまで幅広い

Prowise Business Forum in Tokyo 第57回【日立ソ … · ＜プロジェクトの定義＞ - 大規模システムの構築から、小さな組み込みプログラムまで幅広い