Embed Size (px)
DESCRIPTION
プロジェクトポートフォリオの施策カード(5x3;表のみ)です。詳しくはこちら→ http://yattom.jp/trac/public/wiki/ProjectGames/ProjectPortfolio なぜか画面上では表示されません。Downloadすれば見られます(印刷も)。
Citation preview
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M1
強引に仕様を確定する
Cost
+1
Quality
-3
Delivery
+1
USER
ユーザーの要求を強引に統一して仕様を確定する。作業と期間を節約できるが、内容として不十分な部分ができてしまう。
A RISKRISK
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M2
コスト追加の承認を受ける
Cost
+2
Quality
-1
Delivery
-2
USER
プロジェクトの追加予算を獲得する。ただしスケジュールの遅延は許されない。「不景気で予算削減される」をキャンセルできる。
A RISKRISK
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M3
新しい技術を使う
Cost
+2
Quality
-2
Delivery
-1
USER
未検証の先端的な技術を採用するという決定をする。検証に時間がかかり、また期待通りの機能や性能を発揮できない部分があるが、生産性向上でコストを減らせる。
A
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M4
仕様を頻繁に変える
Cost
-1
Quality
-1
Delivery
0
USER
途中で仕様の変更が多発する。追加のコストが必要となり、またテスト不十分な部分が出てくる。
B
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M5
厳しい期間を設定する
Cost
+1
Quality
0
Delivery
-2
USER
スケジュールを厳しめに設定することで、コストの圧縮を図る。
B
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M6
厳しい品質要求を提示する
Cost
-2
Quality
+1
Delivery
0
USER
品質要求を高く設定することで、品質を担保する。検証のためのコストがかかる。「全く動かないモジュールが発見される」をキャンセルできる。
B
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M7
大規模な仕様変更を要求する
Cost
0
Quality
0
Delivery
-2
USER
ユーザー側の要求を調整した結果、大規模な仕様変更が必要となる。スケジュールを遅らせることはできない。
B
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M8
ドキュメント標準を提示する
Cost
-2
Quality
+1
Delivery
0
USER
包括的ドキュメントの標準を提示し、品質の確保をはかる。標準作成と準拠確認の作業コストが必要。
C
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M9
プロセス監査を厳しくする
Cost
-1
Quality
+1
Delivery
-1
USER
厳格なプロセス監査を導入する。品質を担保できるが、追加の作業が必要なため、コストと期間に影響する。
C
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M10
仕様未定で着手する
Cost
0
Quality
0
Delivery
-1
USER
仕様が決まるめどが付かないまま見切り発車するため、そのぶんスケジュールが遅延する。
RISKRISKD
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M11
膨大な仕様を提示する
Cost
0
Quality
0
Delivery
0
USER
予算とスケジュールに対して仕様が大きすぎる。ただちに影響は出てこないが、どこかにしわよせが行く。「部署間調整に失敗」をキャンセルできる。
D RISKRISK
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M12
現場のわがままを聞く
Cost
-1
Quality
0
Delivery
0
USER
現場の要望を受け入れて仕様を変更する。追加のコストがかかる。「部署間調整に失敗」の影響を半分にできる。
D
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M13
Cost
-3
Quality
0
Delivery
+2
DEVELOPER
ステークホルダーを説得し、スケジュールの延長に成功する。期間は延びるが、コストに対する引き締めが厳しくなる。「協力会社が逃げる」のDelivery変化をゼロにできる。
スケジュール延長を説得する
A RISKRISK
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M14
Cost
+2
Quality
-3
Delivery
+1
DEVELOPER
開発の一部をオフショアに依頼する。大幅なコスト圧縮とスケジュールの前倒しが見込まれたが、思った以上に品質が悪かった。「競合他社が新サービスを発表」のDelivery変化を-1にできる。
オフショア開発をする
A RISKRISK
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M15
Cost
-2
Quality
+2
Delivery
-1
DEVELOPER
プロセス監査を導入して品質を担保する。対応のための作業が増加し、コストとスケジュールに悪影響。
プロセス監査を導入する
B
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M16
Cost
-1
Quality
0
Delivery
-1
DEVELOPER
複雑で習得や利用が難しい技術を採用する。生産性が下がり、コストに悪影響を与える。「パフォーマンスが出ない」をキャンセルできる。
難しい技術を使う
B RISKRISK
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M17
Cost
0
Quality
+1
Delivery
-1
DEVELOPER
プロジェクトメンバーを一部入れ替える。引き継ぎのドタバタに時間を食われるが、品質が改善。「開発者が大勢退職する」のDelivery変化をゼロにできる。
メンバーを入れ替える
B RISKRISK
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M18
Cost
+1
Quality
-1
Delivery
0
DEVELOPER
残業を積み重ねて生産性を上げる。作業は前倒しで進むが、徐々に品質が悪くなっていく。
残業でこなす
RISKRISKC
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M19
Cost
0
Quality
+1
Delivery
-1
DEVELOPER
テスト自動化を導入する。品質に好影響があるが、導入と習得までに時間がかかる。「協力会社が逃げる」のQuality変化をゼロに、Delivery変化を-1にできる。
テストを自動化する
C
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M20
Cost
-1
Quality
+1
Delivery
0
DEVELOPER
品質管理プロセスを導入する。品質は上がるが、コストもかかる。「全く動かないモジュールが発見される」をキャンセルできる。
厳しい品質管理を導入する
C
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M21
Cost
+1
Quality
-1
Delivery
0
DEVELOPER
プロジェクトメンバーを若手中心に構成し、コストを圧縮する。未熟なため品質に問題が出がち。「開発者が大勢退職する」のQuality変化を-1に、Delivery変化を-1にできる。
若く安価なメンバーを調達する
D
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M22
Cost
-1
Quality
+1
Delivery
0
DEVELOPER
リリースを短期で繰り返す。リリースの手間で作業が増えるが、フィードバックを得て品質が上がった。
短期リリースする
D
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M23
Cost
-1
Quality
+1
Delivery
0
DEVELOPER
コストがかかることを覚悟して、優秀なメンバーを社内外から集める。「協力会社が逃げる」のQualityとCostの変化をゼロにできる。
優秀なメンバーを集める
D
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4
M24
Cost
0
Quality
0
Delivery
0
DEVELOPER
社内の手空きのメンバーに手伝ってもらう。「不景気で予算が削減される」のCost変化を-1にできる。
空き要員を活用する
D RISKRISK
