BMUF (Big Modeling Up Front)＝上流設計のインチキを斬る

DDJのCounteracting the False Arguments for Big Modeling Up Front (BMUF)という記事が面白い。BMUFは、日本語なら「上流設計」だろうね。SI屋の自称上流設計エンジニアがやってる、アレだ。[*1]

この記事を書いているのはScott Ambler。Refactoring Database著者だ。例によって無断適当意訳。読みやすくするために原文よりも段落を増やした。

上流設計(BMUF)にまつわる嘘を斬る
自分は１９８０年代から数々のプロジェクトで上流設計をしてきたし、様々な手法をみてきた。
そして、うまく行った事例よりは、うまくいかなかった事例の方が多いと言えるね。プロジェクトは明らかに失敗しつつあるのに、上流設計は順調に進んでいる、という現象を誰よりも多く見てきた、ということも言っておこう。
まだあるよ。上流設計担当の人たちが、「設計開発をする連中がもっとしっかりしていればうまくいったはずなのに」、という愚痴をたれているのも何度も聞いてきた。（ちなみに、特定分野を担当する人はほぼ必ず他分野の担当に文句を言う。）
こういう文句をたれる上流担当も、設計開発をする人たちも間違ってはいないかもしれない。でもね、自分はこの手の愚痴を２０年も聞き続けてきたんだ。さすがに聞き飽きてきたね。

古典的上流設計担当者がおかしてきた基本的な間違いは、上流設計の成功とプロジェクトの成功とを取り違えてきたことだ。
古典的な世界では、上流設計担当者はプロジェクトの立ち上げ時にやってきて、何か仕事をして-念のため言っとくけど、大抵は良い仕事だよ-、で、そのプロジェクトが終わる前に別のプロジェクトに移ってまた上流設計をする。
何ヶ月か何年か経過して、その古典的プロジェクトは崩壊するか、納期が延ばされるか、予算超過しちゃうわけだ。そうなってから初めて、上流設計担当は自分が担当したプロジェクトの状況を聞いてびっくりする。だって、自分が見てたときは何も問題がなかったわけだし。もちろん、上流設計担当者は立派な仕事をしていたわけだよ。
様々な視点からあらゆる問題点を洗い出し、「概要図」をもとに検討を重ねて、後半の開発者のために詳細なガイドラインを残していく。これはすごい仕事だよ。
問題なのは、「大きな視点で考えよう」とか「問題領域の分析と理解が大事だ」とか抜かしている上流設計担当者自身が、自分のやっている上流設計という仕事に何の疑念も抱いていない、ということだ。
もし、上流設計担当者が自分でソフトウェアの開発をやることになれば、その上流設計など現場ではほとんど役に立たないということを瞬間的に理解するはずだ。

古典的な上流設計担当者は、問題領域をプロジェクト着手時にできるだけ詳細に分析してモデル化することが望ましい、と主張する。私はこの手法をBMUF(Big Modeling Up Front)と呼んでいる。
BMUFはBRUF(Big Requirements Up Front: 上流要件定義)とセットになっているのが常で、プロジェクトの開始直後に分厚い業務要件定義書が出てきて、それを受けて上流設計者がこれまた分厚いシステム要件定義書を書き上げるわけだ。
このやり方は、貴方が上流設計専門家なら当然と思うはずだ。特に古典的上流設計担当者はこのやり方を好む。そして彼らが持ち出す話は大抵嘘っぱちであることも、自分は経験上理解している。
以下は、古典的上流設計担当者が持ち出す嘘の数々と、それに対する反論だ。
上流設計の嘘その１：　先々に起こることを見通すことは可能だ
事前に要件定義をぎっしりと並べて「この通り作れ！」と言う人に限って、プロジェクトの途中でどこかに消えちゃうんだよね。
で、こういう人達ってのはお客様が要件定義に変更を加える機会を葬り去っているんだな。
もちろん、きっちりしたプロジェクトでは要件定義の変更を「変更管理プロセス」とかいう名前で管理しているところもある。
でも、私に言わせればそれは「変更阻止プロセス」と名付ける方がいいと思うんだな。
古典的上流設計者達は、要件の変更を難しくしすぎてしまうため、お客様は要件変更をあきらめざるを得ないのが普通だ。そこをわかってないから、古典的上流設計者は、事前に要件を徹底的に固めてしまうことを自慢しちゃうし、俺って一番！みたいに考えてしまうわけよ。
別に貴方が一番なんじゃなくって、他にもっと良いやり方があることを他の人は気づいているだけなんだけどね。

上流設計の嘘その２：　橋に例えるやつ
システム開発を橋の建設に例えるというのは、こんな感じだ。
「橋の建設はとても複雑な工程が必要だ。複雑なのはソフトウェア開発も同様だ。橋はまず詳細な設計図が作られて、建設計画書ができあがって、それから建設が始まる。つまり、ソフトウェア開発も同様の手順でなければだめなんだ。」　
橋の建設とソフトウェア開発の両方に経験がある人は別として、なんでこの例えに誰も疑問を持たないの？　
自分には建築家の知り合いが何人かいるけれど、彼らの仕事は非常に創造的かつ革新的で、ソフトウェア開発者には想像もつかない世界だ。
世界レベルの建築家が働いている所を観たければ、「The Sketches of Frank Gehry」をお勧めする。
自分は、Gehry氏のことをAgile設計者だと断言できるね。彼は古典的設計者ではない。ソフトウェア開発を橋の建設に例えることは可能かもしれないけれど、それは古典的開発ではなくAgileとしてとらえるべきかもね。
上流設計の嘘その３：　お客様は何が欲しいか理解している
あなたは自分の部屋を模様替えするときに、事前に完璧な要件定義を書いたことがある？　
仮にそんなことをしたとしても、実際に住んでみればソファーの角度がよくないだとか、壁の絵が絨毯の柄と合ってないねとか、なにかしらの問題がでてくるはずだ。結局、絵を取り替えたり家具の位置を変えたり、時にはもっと大規模な模様替えをする羽目になる。
部屋の模様替えよりも遥かに大規模で複雑なシステム開発ではどうなると思う？　
人間ってのは、何が欲しいのかを理解していないものだ。ゴールや目的を理解していれば、まだ良いほうだ。
でも一方で、人間ってのは嫌いなものを指摘するのは得意だ。
そして、嫌いなものを指摘することで、何がしかの改善を要求する。Agileなどの革新的手法が台頭してきた理由はまさにここにあって、お客様からの要望を日常的に吸い上げて、実現するわけだ。
古典的手法がとる、一方的かつ文書記述に基づくやり方とは違うのだ。もちろん、この話はお客様の要望に応じたシステムを開発する、という前提が必要となるけどね。
上流設計の嘘その４：　詳細な文書整備は価値を高める
これは必ずしも嘘とは言えない。ただし、詳細な文書をプロジェクトの前半で整備するというのは感心できない。
Agile設計手法では、「整理する情報が確定し」「誰かがその文書の所有コスト(TCO)を理解し、負担することを了承する」という条件を満たさない限り文書整備は行わない。
憶測情報を文書化したい奴はいないはずだ。そして、プロジェクト初期段階での要件や設計案というのは、どう考えても憶測情報だ。
憶測は時間とともに変化していくのが常だから、その憶測を文書にまとめてしまうのはTCO増加につながる。
上流設計の嘘その５：　革新的手法が機能する証拠はない
古典的開発手法に取って代わる革新的開発手法では、反復的かつ漸増的に開発を進めていく。その一つがAgile開発だ。
古典的開発主義者達は、これらの革新的手法が効率的に機能すると証明されたことはない、と主張しがちだが、これは明らかに間違っている。革新的手法は従来型開発よりも非常に優れており、間接的な証拠は山ほどある。
「決定的な証拠を出せ」と言う人達は、今の仕事のやり方を変え変えたくない、ということを表明しているんだろうね。
古典的手法は、革新的手法に比べると遥かに少ない実績で体系化されてきた。そして、その実績こそが全てを物語っている。上流設計などやめてしまえ、と。

設計というのは、設計を本業としている人達には重要だよ。でも、複数の能力を持った専門家にしてみれば、設計というのは数ある重要な要素の中の一つでしかない。
専門家は、自身の専門性こそが実戦では何よりも重要だと考えがちだけど、本当の現場では、自分の狭量な知識に固執するよりは、幅広い知識を持った人の語る選択肢を聞き入れることの方が大切なんだな。