標準化のトレードオフ その５ - 従来法と改善 -

「ウォーターフォールなんて！最初に全部決める事はできないだろう！」アジャイラーには、そんな意見もある様です。たしかにそういう組織もあるでしょうが、そうでない組織もあると思います。

現場でウォーターフォールをベースとした開発と言われている従来法には、ロイスでもDoDの定義でもなく、ドキュメントを必須とする計画駆動で、標準プロセスを元に監査が行われていることも多くあります。

このような開発法では工程をまたがる作業を許容していたり、プロトタイプの開発も可能な場合があり、 最初に仕様を全部を決めているとは限りません。

しかし、実際にはプロトタイピングをした方が良い局面でも、実施できない場合があります。その理由には以下のものがあるでしょう。

• 技術検証チームが別にある
• 開発標準で禁止されている
• プロジェクトの立ち上げ時に想定（テーラリング）していない
• 計画や契約に入れていない

安定した技術を採用してプロトタイピングを不要にし、手戻りが生じる事になっても工程毎のレビューを厳密にする事が選ばれる事もありますが、ルールとしてプロトタイプの開発を禁止していない組織も少なからずあります。

しかし、プロトタイプに積極的でないことで計画や契約で考慮されず、現実的にできない場合もあるでしょう。

その背景として考えられるのは、管理者や現場がプロセスに対して保守的になっている場合でしょう。過去にプロセスを工夫しようとして許可されなかった事がトラウマになって、チェックに対して安全策を取るような場合です。

プロセス標準を決めるのは習慣で実施されていたプロセスを定義する事で、組織的に改善するための基盤を構築するためです。抜けのない作業を全てのプロジェクトがきちんと実施していれば、改善に成功した試策が他のプロジェクトへの適用が容易になります。

しかし、現場が改善活動に協力しなかったり、上に書いたように現場が守りに入るようでは、プロセスの安定が得られても改善に結びつきません。

そこで、プロセス改善の集まりであるJASPICのSPI Japanやソフトウェア技術者協会のソフトウェアシンポジウムなどでは、現場と共に改善する方法について多くの議論が行われました（他にもたくさんあるでしょう）。

その結果、多くの成果が発表されました。その反面、そのような活動に参加せず、トップダウンに標準プロセスを強要することに終始して、改善に結びついていない会社もある様です。

その理由を考えると、組織の標準プロセスというトップダウン的なプローチが、そもそも危険を含んでいたのかもしれません。しかしそれ以外にも、現場と共に行うプロセス改善の議論がコミュニティ中心で、プロセス改善の営業的な利用の勢いに負けた事も原因の一つではないかと思います。

ウォータフォールだからという単純な理由ではなく、トップダウンに標準化する際のノウハウの不足が、プロセス改善がうまくいかなくなる大きな原因ではないでしょうか。