標準化のトレードオフ その5 - 従来法と改善 -
「ウォーターフォールなんて!最初に全部決める事はできないだろう!」アジャイラーには、そんな意見もある様です。たしかにそういう組織もあるでしょうが、そうでない組織もあると思います。
現場でウォーターフォールをベースとした開発と言われている従来法には、ロイスでもDoDの定義でもなく、ドキュメントを必須とする計画駆動で、標準プロセスを元に監査が行われていることも多くあります。
このような開発法では工程をまたがる作業を許容していたり、プロトタイプの開発も可能な場合があり、 最初に仕様を全部を決めているとは限りません。
しかし、実際にはプロトタイピングをした方が良い局面でも、実施できない場合があります。その理由には以下のものがあるでしょう。
- 技術検証チームが別にある
- 開発標準で禁止されている
- プロジェクトの立ち上げ時に想定(テーラリング)していない
- 計画や契約に入れていない
安定した技術を採用してプロトタイピングを不要にし、手戻りが生じる事になっても工程毎のレビューを厳密にする事が選ばれる事もありますが、ルールとしてプロトタイプの開発を禁止していない組織も少なからずあります。
しかし、プロトタイプに積極的でないことで計画や契約で考慮されず、現実的にできない場合もあるでしょう。
その背景として考えられるのは、管理者や現場がプロセスに対して保守的になっている場合でしょう。過去にプロセスを工夫しようとして許可されなかった事がトラウマになって、チェックに対して安全策を取るような場合です。
プロセス標準を決めるのは習慣で実施されていたプロセスを定義する事で、組織的に改善するための基盤を構築するためです。抜けのない作業を全てのプロジェクトがきちんと実施していれば、改善に成功した試策が他のプロジェクトへの適用が容易になります。
しかし、現場が改善活動に協力しなかったり、上に書いたように現場が守りに入るようでは、プロセスの安定が得られても改善に結びつきません。
そこで、プロセス改善の集まりであるJASPICのSPI Japanやソフトウェア技術者協会のソフトウェアシンポジウムなどでは、現場と共に改善する方法について多くの議論が行われました(他にもたくさんあるでしょう)。
その結果、多くの成果が発表されました。その反面、そのような活動に参加せず、トップダウンに標準プロセスを強要することに終始して、改善に結びついていない会社もある様です。
その理由を考えると、組織の標準プロセスというトップダウン的なプローチが、そもそも危険を含んでいたのかもしれません。しかしそれ以外にも、現場と共に行うプロセス改善の議論がコミュニティ中心で、プロセス改善の営業的な利用の勢いに負けた事も原因の一つではないかと思います。
ウォータフォールだからという単純な理由ではなく、トップダウンに標準化する際のノウハウの不足が、プロセス改善がうまくいかなくなる大きな原因ではないでしょうか。
« 標準化のトレードオフ その4 - 慣性の法則 - | トップページ | スルーと情報発信で良い情報を集める - 情報量とは驚きの量 - »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
コメント
« 標準化のトレードオフ その4 - 慣性の法則 - | トップページ | スルーと情報発信で良い情報を集める - 情報量とは驚きの量 - »
ピープルウェアの第三版がでたので、今読み進めています。
一般的にウォーターフォール批判の対象となっているのは、第29章にでてくるメソドロジーの押し付けに会うからなのかな?と思っています。
わたしの現役のころはウォーターフォールくらいしか表現方法がなかったですが、わりかし柔軟にやり方を状況にあわせながら開発していましたよ。
プロトタイプは特にUI関連だとできるといいと言われながら、見てくれができると完成だとお客が判断するので敬遠されたり、うまく構造を作っていないとデグレードを多発させたりといった問題で使われなかったですね。でも、やらなかったわけでもないです。
投稿: おおのすすむ | 2014年2月 4日 (火) 14時13分
経験談をありがとうございます。
プロトタイプに関しては以下のシリーズに書いていますので、良かったらお読みください。
実装優先時の考慮点 その1 - プロトタイピングとスパイクソリューション - http://sakaba.cocolog-nifty.com/sakaba/2013/12/----984e.html
投稿: さかば(阪井) | 2014年2月 4日 (火) 22時56分
プロトタイプのできるくらいの大きさの要求ならいいですが、複雑なシステムになると要求自体も複雑で巨大であることが多いです。こういうやつはおそらくプロトタイプだけでは対応できないのではないでしょうか?
要求と実装の間には深い谷があると表現されることがあります。それをできるだけ飛び越えられるようにするのがWFでいうところの上流設計なのだと思いますよ。
ただ、それでも、システム要求のツインピークモデルのように実装の終盤まで要求の確定が延びると考えるのが実際的だと思います。
投稿: おおのすすむ | 2014年2月 5日 (水) 10時36分
ベーム先生の「アジャイルと規律」を引用するまでもなく、開発対象や組織などにあわせてプロセスは設計すべきだと思います。それが複数の開発法を組み合わせるプロセスなら、それにあわせて切り出すことも必要ですね。ウォーターフォールしかり、アジャイルもしかり、もちろんプロトタイプもです。
投稿: さかば(阪井) | 2014年2月 5日 (水) 22時34分