M1
USER
強引に仕様を確定す
る
ユーザーの要求を強引に統一し
て仕様を確定する。作業と期間を
節約できるが、内容として不十分
な部分ができてしまう。
A RISK
Quality Cost Delivery
-3 +1 +1
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M2
USER
コスト追加の承認を
受ける
プロジェクトの追加予算を獲
得する。ただしスケジュールの
遅延は許されない。「不景気で
予算削減される」をキャンセル
できる。
A RISK
Quality Cost Delivery
-1 +2 -2
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M3
USER
新しい技術を使う
未検証の先端的な技術を採用す
るという決定をする。検証に時間
がかかり、また期待通りの機能
や性能を発揮できない部分があ
るが、生産性向上でコストを減ら
せる。
A
Quality Cost Delivery
-2 +2 -1
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M4
USER
仕様を頻繁に変える
途中で仕様の変更が多発する。
追加のコストが必要となり、また
テスト不十分な部分が出てくる。
B
Quality Cost Delivery
-1 -1 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M5
USER
厳しい期間を設定す
る
スケジュールを厳しめに設定する
ことで、コストの圧縮を図る。
B
Quality Cost Delivery
0 +1 -2
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M6
USER
厳しい品質要求を提
示する
品質要求を高く設定することで、
品質を担保する。検証のための
コストがかかる。「全く動かないモ
ジュールが発見される」をキャン
セルできる。
B
Quality Cost Delivery
+1 -2 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M7
USER
大規模な仕様変更を
要求する
ユーザー側の要求を調整した結
果、大規模な仕様変更が必要と
なる。スケジュールを遅らせるこ
とはできない。
B
Quality Cost Delivery
0 0 -2
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M8
USER
ドキュメント標準を
提示する
包括的ドキュメントの標準を提示
し、品質の確保をはかる。標準作
成と準拠確認の作業コストが必
要。
C
Quality Cost Delivery
+1 -2 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M9
USER
プロセス監査を厳し
くする
厳格なプロセス監査を導入する。
品質を担保できるが、追加の作
業が必要なため、コストと期間に
影響する。
C
Quality Cost Delivery
+1 -1 -1
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M10
USER
仕様未定で着手する
仕様が決まるめどが付かないま
ま見切り発車するため、そのぶ
んスケジュールが遅延する。
D RISK
Quality Cost Delivery
0 0 -1
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M11
USER
膨大な仕様を提示す
る
予算とスケジュールに対して仕様
が大きすぎる。ただちに影響は出
てこないが、どこかにしわよせが
行く。「部署間調整に失敗」をキャ
ンセルできる。
D RISK
Quality Cost Delivery
0 0 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M12
USER
現場のわがままを聞
く
現場の要望を受け入れて仕様を
変更する。追加のコストがかかる。
「部署間調整に失敗」の影響を半
分にできる。
D
Quality Cost Delivery
0 -1 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M13
DEVELOPER
スケジュール延長を
説得する
ステークホルダーを説得し、スケ
ジュールの延長に成功する。期
間は延びるが、コストに対する引
き締めが厳しくなる。「協力会社
が逃げる」のDelivery変化をゼロ
にできる。
A RISK
Quality Cost Delivery
0 -3 +2
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M14
DEVELOPER
オフショア開発をす
る
開発の一部をオフショアに依頼す
る。大幅なコスト圧縮とスケ
ジュールの前倒しが見込まれた
が、思った以上に品質が悪かっ
た。「競合他社が新サービスを発
表」のDelivery変化を-1にできる。
A RISK
Quality Cost Delivery
-3 +2 +1
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M15
DEVELOPER
プロセス監査を導入
する
プロセス監査を導入して品質を
担保する。対応のための作業が
増加し、コストとスケジュールに
悪影響。
B
Quality Cost Delivery
+2 -2 -1
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M16
DEVELOPER
難しい技術を使う
複雑で習得や利用が難しい技術
を採用する。生産性が下がり、コ
ストに悪影響を与える。「パフォー
マンスが出ない」をキャンセルで
きる。
B RISK
Quality Cost Delivery
0 -1 -1
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M17
DEVELOPER
メンバーを入れ替え
る
プロジェクトメンバーを一部入れ
替える。引き継ぎのドタバタに時
間を食われるが、品質が改善。
「開発者が大勢退職する」の
Delivery変化をゼロにできる。
B RISK
Quality Cost Delivery
+1 0 -1
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M18
DEVELOPER
残業でこなす
残業を積み重ねて生産性を上げ
る。作業は前倒しで進むが、徐々
に品質が悪くなっていく。
C RISK
Quality Cost Delivery
-1 +1 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M19
DEVELOPER
テストを自動化する
テスト自動化を導入する。品質に
好影響があるが、導入と習得ま
でに時間がかかる。「協力会社が
逃げる」のQuality変化をゼロに、
Delivery変化を-1にできる。
C
Quality Cost Delivery
+1 0 -1
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M20
DEVELOPER
厳しい品質管理を導
入する
品質管理プロセスを導入する。
品質は上がるが、コストもかかる。
「全く動かないモジュールが発見
される」をキャンセルできる。
C
Quality Cost Delivery
+1 -1 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M21
DEVELOPER
若く安価なメンバー
を調達する
プロジェクトメンバーを若手中心
に構成し、コストを圧縮する。未
熟なため品質に問題が出がち。
「開発者が大勢退職する」の
Quality変化を-1に、Delivery変
化を-1にできる。
D
Quality Cost Delivery
-1 +1 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M22
DEVELOPER
短期リリースする
リリースを短期で繰り返す。リ
リースの手間で作業が増えるが、
フィードバックを得て品質が上
がった。
D
Quality Cost Delivery
+1 -1 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M23
DEVELOPER
優秀なメンバーを集
める
コストがかかることを覚悟して、
優秀なメンバーを社内外から集
める。「協力会社が逃げる」の
QualityとCostの変化をゼロにで
きる。
D
Quality Cost Delivery
+1 -1 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4

M24
DEVELOPER
空き要員を活用する
社内の手空きのメンバーに手
伝ってもらう。「不景気で予算が
削減される」のCost変化を-1にで
きる。
D RISK
Quality Cost Delivery
0 0 0
(C)2009 やっとむ・安井力 http://yattom.jp Rev.4