知っている vs 知らない

作者 Christopher R. Goldsbury , 翻訳者 徳武 聡 投稿日 2011年10月25日

セクション

プロセス/プラクティス

トピック

Agile ,

マネジメント

共有 |

原文(投稿日：2011/10/21)へのリンク

ウォーターフォールで開発するかアジャイルで開発するかは双方の問題と解決策をどの程度知っているかに基づいて決定されるはずだ。これはScrumologyのオーナであるDavid J Blant氏の提案だ。

氏は下記の点を指摘している。

1. アジャイルかウォーターフォールかを決めるのは、問題と解決策がほとんどわかっている場合は、趣味の問題だ。

2. 問題がほとんど分かっていて解決策が分かっていない場合、アジャイルは有効に働く。ウォーターフォールは上手くいかない。

3. アジャイルは問題も解決策も分かっていない場合に有効に働く。ウォーターフォールは上手くいかない。

氏は下記のように自身の見解をまとめている。

“アジャイルとウォーターフォールの戦いは古くさくうんざりするものになり始めています。どちらもすぐになくなるものではありませんし、議論もノイズだらけです。この戦いは問題や解決策を知っているかどうかという真の課題から私たちを遠ざけています。

なのでウォーターフォールを難じるのはやめて、正しいツールを使っているかどうか自問してみましょう。”

この記事はLinkedInのアジャイルグループで大きな注目を浴びた。最初は氏の考えに賛同するコメントが多かったが、グループ内での議論が深まると、ソフトウエア開発で解決策も問題も明確になっていることはほとんどないということがはっきりした。この点はChris Shield氏がコメントで指摘している。

“ソフトウエア開発で解決策が100%分かっている場合はないと思います。いつも新しい変更が生まれ、新しい前庭条件が生まれ、その前庭条件が無効であることが分かり、後になってビジネスサイドから新しい要求が現れる。そんなことばかりです。”

Greg Robinson氏は下記のようにコメントしている。

“ソフトウエア開発は本質的には、無数にある可能な解決策の中から最適で適用可能なひとつを選ぶための研究と開発プロセスです。設計図を書いたら皆が賛成してくれて、最初の開発で設計図通りのものが出来上がるというような製造業のようなプロセス(OTOBOS)を適用できると考えているなら、それは楽観的すぎるし、ウォーターフォールプロセスの本質的欠陥を孕んでいるとも言えます。1年間の詳細なリリース計画を立てるのを無視して２週間のスプリントを計画するのですら難しいのです(いわゆる要求が一年後もそのまま残っていることはありますか)。ウォーターフォールが上手くいくのは幸運なときだけです。

他のコメントでもソフトウエア開発を始める時点で問題を知っていて解決策を知っている状態あるいはどちらか一方を知っている状態は可能かどうかについて議論されている。アジャイルもウォーターフォールもそれぞれに適用すべき状況があるという点では意見の一致をみたようだ。

しかし、違う意見もある。Pawel Bradzinski氏の記事で、氏はプロセスや方法論ではなく人がソフトウエア開発の成功を左右すると書いている。

ソフトウエア開発について他の文脈的要因をより深く分析している人もいる。2008年のTom Peplow氏の記事はこの問題についてよく書かれている。

1. トップへ戻る

   製造業の製品開発プロセスだって、OTOBOS (on time, on budget, on scope ～ 工期・予算・スコープ通り) ではない。

   by 康彦 山本

   まず、翻訳のささいな問題点を。
   
   

   設計図を書いたら皆が賛成してくれて、最初の開発で設計図通りのものが出来上がるというような製造業のようなプロセス(OTOBOS)を適用できると考えているなら、それは楽観的すぎるし、ウォーターフォールプロセスの本質的欠陥を孕んでいるとも言えます。

   
   この訳だと、製造業では設計図を書いてから開発が行われる (製造業の開発では、設計図通りのものを作るだけ) と誤解される恐れがあります。設計図を書く作業も、もちろん開発の一部分です。
   
   

   To think that you can apply more of a manufacturing process where you can write down a blueprint, get everyone to agree it and build it right (OTOBOS) 1st time is at best optimistic and a fundamental flaw of all waterfall processes.

   
   原文の "1st time" をどう解釈するかは難しいのですが、「設計図を書いたら、皆が賛成してくれて、設計図通りのものが出来上がる」こと全体に掛かっているでしょう。
   
   さて、その上で Greg Robinson 氏の意見に対する指摘を。
   
   製造業、その代表として自動車で話をします。その製品開発プロセスは、1パス(ウォーターフォール的)ではありません。設計→試作(ビルド)→実験・評価(テスト)→(設計へフィードバック)というループを何回か繰り返します。こちらの図を見てください。⇒ twitpic.com/6nmd0g
   
   評価結果が思わしくなければ、このループをさらに回すこともあります。あるいは、まれではありますが、製品コンセプト段階に戻ってやり直すことさえあります。すなわち、製造業の製品開発プロセスも、当初の工期・予算・スコープ通り(OTOBOS)に開発が完了するとは限らないということです。
   
   製造業の製品開発プロセスがOTOBOSだと考えているなら、それは楽観的すぎるし、ウォーターフォールプロセスの本質的欠陥 (製造業でもそんなやり方では開発できない!) を擁護するものだと言えます。

   返信