上手＠データ通信システムです。
第14章 Splitting Business and Technical Responsibility の解説です。
コメントお願いいたします。
-----------------------------
Chapter 14 Splitting Business and Technical Responsibility
ビジネスおよび技術の責任を分割する
各章のタイトルの下に、小さな字でその章の一番のポイントが簡単に書いてあ
るようです。１４章ではこんなことが書いてあります。
・我々の戦略の一つのキーは、テクニカルな人々はテクニカルな問題に集中し、
ビジネスの人々はビジネスの問題に集中することだ。
・プロジェクトはビジネスの決定により運営されなければならないが、その決
定は、コストとリスクについての技術の決定を知らされていなければならない。
Business（ビジネス）
ビジネス（業務担当）が権力を持つと以下のような事態になるといっています。
４つの変数（４章のcost,time,quality,scope)について命令する。
これを作れ。この予定でやれ。新しいワークステーションなんて無い。最高の
品質じゃ無かったら、問題が起きるのは覚悟しとけよ。
このシナリオではビジネスが出す仕様が膨らみすぎる。開発は力が無いので反
対できず、不可能とわかっていてもやるしかない。
余り重要で無い要求の中に大きなリスクが潜んでいる。
結論：ビジネス主導では、プロジェクトは非常に大きなリスクの下、非常に大
きな努力をしても、成果はほとんどあがらない。
Development（開発）
開発が主導権を持っても同じだと言っています。
新しいツール、新しい言語、新しいテクノロジーをインストールする。技術的な
興味や目新しさからそれを選んで、それに時間をつぎ込むだけ。
結論：ビジネスと全く同じ
What to Do？（何をすべきか）
そこで、ビジネスもプログラマも、分担を明確にし、何事も自分たちだけで勝
手に決めないようにする、と述べています。
ビジネスは以下を選択する
・スコープとリリースのタイミング
・提案された機能の相対的な重要度
・提案された機能の正確なスコープ（実現範囲）
この決定のために、開発は以下を支援する
・機能を実装するのにかかる時間を見積もる
・技術的な選択肢の検討結果の見積り
・人的資源、ビジネス環境、会社の文化を考慮した最適な開発プロセス
・最初に使うpracticesのセット。practicesの効果をレビューし、practicesを
変更する方法。
ビジネス決定はプロジェクトの続く限り発生するので、顧客はプログラマの一
員となり、更に、チームに加わってフルタイムで質問に答えられれば一番良い
結果を生む、と述べています。
Choice of Technology
テクノロジの選択
テクノロジの選択は純粋に技術的な決定の様に見えるかもしれないが、インプ
ットが開発からされるだけで、実際はビジネス決定だ、としている。
開発が技術的なコメントを述べ、ビジネスが決定する例が挙げられている。
一方で、開発の決定としてメンテナンスコストを計算に入れることが強調され
ている。
What if It's Hard
もし難しいとしたらどうだろう（＃これで良いか？）
このパラグラフは実際のプロジェクトはどうなるかの話をしているのですが、
「やるしかないからやろう！」 みたいな感じで、何をいいたいのか良くわか
りません。最後の５行は、こんな感じです。
ビジネスと開発の責任分担をしたから仕事が楽になる訳ではない。逆に、きつ
い仕事を、まだ単純化出来ない仕事から切り出しているだけだ。でも、思った
よりもシンプルに仕事ができるよ。そうじゃなくても、なんとかなるさ、それ
で喰ってるんだから。
（以上）