ホソカワです。
上手さんのコメントを反映しました。コメントありがとうございます。
on 2000/04/03 11:01 AM, Yutaka Kamite at y-kamite@....jp wrote:
>
> ここから重要そうなので、ニュアンスを変えてみました。
>
>> 顧客は、重要な機能をリリース毎に落とされては困ります。このようにならないよう
>> にXPでは次の戦略をとります。
>
> 各リリースサイクルの最後に来て、重要な機能が落ちていると、顧客はとても心配に
> なります。これを避けるために、ＸＰでは２つの戦略を用います。
>
各リリースサイクルの最後に来て、重要な機能を落とすと、顧客はそのうち心を悩ま
します。これを避けるために、XPでは２つの戦略を用います。
[upsetは、「心が病む」と訳しました。]
>>
>> １、見積もりと結果を（見積もりに）フィードバックすることの練習がたくさんでき
>> るようにします。見積もりがよりよいものであれば、機能が落とされる確率を減らす
>> ことができます。
>>
>
> 予想（見積り）をし、（それに）現実の結果をフィードバックすることを沢山行います
> 。
> ＃以下同じ
>
１、見積もり（予想）をし、（それに）現実の結果をフィードバックすることを何回
も行います。見積もりがよりよいものであれば、機能が落とされる確率を減らすこと
ができます。
[You get lots of practiceを「何回も行う」と訳しました。]
>> ２、顧客が重要と思っている機能から着手します。仮に、機能が落とされてもその機
>> 能は稼動しているシステムの機能よりは重要度の低いものです。
>>
>
> ＃これも同じですが・・
> 顧客の最も重要な要求を最初に実装します。ですから、もし別の機能が落とされても、
> それは、すでにシステムで動いている機能よりは重要でない、ことになります。
２、顧客の最も重要な要求を最初に実装します。ですから、もし別の機能が落とされ
てもそれは、すでにシステムで動いている機能より重要ではない、ことになります。
--
Kaoru Hosokawa
khosokawa@....com
----
Chapter 4 Four Variables
========================
ソフトウェア開発モデルを基準変数のシステムという観点から紹介します。このモデ
ルには４つの変数があります。
・コスト
・時間
・質
・スコープ
このモデルのソフトウェア開発ゲームでは、外部勢力（顧客、マネージャー）が、３
つの変数の値を決めることができます。開発チームは残りの４番目の変数の値を決め
ることができます。
マネージャーと顧客の中には変数の値を全て決めることができると信じている者もい
ます。「来月の頭までにこのチーム構成ですべての要件を満たしておいてください。
もちろん、質は落とさずに。」このような状況が起きた時、必ず質がおざなりになっ
てしまいます。また、時間もコントロール不能になります。
解決策は４つの変数があるということを認識させることです。全員がすべての変数を
認識するようになれば、意識してコントロールする変数を選択することができます。
４番目の変数の値から導かれる結果になっとくがいかないのであれば、値を変えるこ
ともでますし、新たに違う３つの変数をコントロールすることができます。
Interaction Between the Variables
---------------------------------
コスト − お金を増やせば、多少円滑に進むことができますが、大量のお金をすぐに
提供することは問題を増やすだけです。逆に少なすぎると顧客の問題を解決すること
ができません。
時間 − 時間があれば、質の向上とスコープの拡大が見込めます。稼動しているシス
テムからのフィードバックは、非常に優れているので時間を掛け過ぎるのはプロジェ
クトにとってよくありません。
質 − 質は非常に悪い基準変数です。質を落とすことで短期的な利得を得ることがで
きますが、（リソース、ビジネス、テクニカル）コストは巨大になります。
スコープ ー （そのスコープが顧客の問題を解決しているのであれば）控えめのスコー
プは質の向上に繋がります。それから、納期を前倒しすること、または、安く納品す
ることができます。
多くの点でコストが一番制約された変数です。お金を注ぎ込んでも、質、スコープ、
開発リリースサイクルの短縮は達成できません。プロジェクトの初期段階では、あま
りお金を費やすことができません。小さくはじめて徐々に増やしていきます。
コストに対するあらゆる制約はマネージャーの気を狂わせかねない。特に年間の予算
案プロセスだけに集中して、コストからすべてを割り出すため、コストの影響力を無
視して、大きな間違いを起こすでしょう。
コストのもう一方の問題は、高いコストがステータス、名声を意味するようにとらわ
れることです。「私のプロジェクトは、150人体制で、…（へへ）」マネージャーが
プロジェクトが凄いことアピールしたいだけですから、このようなプロジェクトは失
敗します。そもそも同じプロジェクトを10人で半分の期間で完成することのどこにス
テータスがあるのでしょう？
これに反して、コストは他の変数と密接な関係にあります。良心的な範囲での出資は、
スコープの拡大、もっと計画的な行動、納期の（ある程度の）短縮を可能にします。
時間に対する制約は、外部からくる場合が一般的です。最近の例では2000年がありま
す。従って、時間はプロジェクトマネージャーのコントロールではなく、顧客にコン
トロールされます。
質も一風変わった変数です。時々、質の向上を強要することでプロジェクトが早く完
成したり、同じ時間内にもっとやり遂げたりします。Beck氏も、単体テストを行うこ
とによって、コードに自信を持つようになり、速くコードが書けるようになりました。
チームでも同じようなことが起きました。
内部と外部的な質には一風変わた関係があります。外部的な質とは顧客が評価する
質のことです。内部的な質とはプログラマが評価する質です。一時的に、納期を短縮
するために内部的な質を犠牲にし、外部の質もそれほど落ちないようにすることは、
短期的な誘惑です。結局は、内部的な問題が浮上してきて、保守が法外に高くつくか、
外部の質が競争できるようなレベルに達しなくなる。
これとは逆に、質の制約を緩めることによって早く完成することもできます。Beck氏
は、レガシーシステムを置き換える作業を行ったことがあります。そのときの制約は、
古いシステムと全く同じ結果を出すということでした。プロジェクトの終盤に差し掛
かったとき、古いシステムのエラーまで完全に再現するためには納期を遅らせるしか
なかったので、顧客に新しいシステムの答えの方がより正しいことを説明し、納期を
守りたいなら、新しいシステムの答えを信じるように勧めました。
質は人間にも影響を及ぼします。だれもがいい仕事を行いたいと思っています。そし
て、良い仕事をしていると感じれば、より良く働きます。計画的に質を落とすと、チー
ムは早く進みますが、すぐに役に立たないものを作成していることへの士気喪失
（demoralization）が、テストをしない、レビューを怠って、スタンダードを無視し
て得た、利得を圧倒します。
Focus on Scope
--------------
ソフトウェア開発で一番意識していなければならないのが、スコープです。スコープ
を積極的に管理できれば、マネージャーや顧客にコスト、質と時間を管理させられま
す。
スコープの凄いところは、しばしば変化するという点です。要件が最初から明確になっ
ていることなど一度もありません。顧客は何がほしいか一度も正確に言えたためしが
ありません。
ソフトウェアの一部分の完成でも要件を変えます。顧客が最初のリリースを見た瞬間、
つぎのリリースの要件を学習します…というか最初に欲しかったことを学習します。
これは重要な学習です。顧客は、プログラミングができるガイドではなく仲間を必要
としています。
要件の柔軟性を好機ととらえると４つの変数のうち一番管理しやすいものとなります。
柔軟なため、私達が形を変えることができます。リリースに間に合いそうもなければ、
次期のリリースに移せるものもあるでしょう。
このモデルをベースに開発方法を作成するとすれば、時間、質とコストを固定します。
この３つの変数から導かれるスコープを検討します。開発が進むにつれて状況に合う
ようにスコープを調節します。
このプロセスは、プロジェクトの方向性が頻繁に変わるので、変化を簡単に取り込め
なくてはなりません。また、このプロセスは変更に対するコストをプロジェクトの期
間中、正当な範囲にとどめなくてはなりません。
各リリースサイクルの最後に来て、重要な機能を落とすと、顧客はそのうち心を悩ま
します。これを避けるために、XPでは２つの戦略を用います。
１、見積もり（予想）をし、（それに）現実の結果をフィードバックすることをたく
さん行います。見積もりがよりよいものであれば、機能が落とされる確率を減らすこ
とができます。
２、顧客の最も重要な要求を最初に実装します。ですから、もし別の機能が落とされ
てもそれは、すでにシステムで動いている機能より重要ではない、ことになります。