「開発プロセス」＝「画一化」というイメージ

普段、仕事で開発に携わっている方との雑談の中で、共通して5, 6回出てきた話。分野や業態がかなり異なっていながら共通している話だったので意外だった。ソフトウェア開発プロセスというと、だいたい手順を部門統一、全社統一するというイメージを持つそうだ。必ずしもそういう意味合いは含まれていないが、単語のコロケーション（共起関係）を調べてみたいと思いたくなったほどだ。

ソフトウェア開発プロセスは作業を定義したものであり、必ずしも全てのプロジェクトで同じものを使う必要はない。標準化という観点では統一することができるが、必ずしも全てを同一のものにする必要はない。個々の作業を部品として考え、対象ソフトウェア、メンバ、ソフトウェアへの要求、によって組合せ、調整する（プロセステーラリングと呼ばれている）。プロジェクト毎へのカスタマイズという表現がなじみやすいのではないかと思う。

開発プロセスは、カスタマイズがしやすいレベルで画一的に定義しておき、それらをもとに個々のプロジェクトの事情（コンテキスト）や制約に応じて変更してから利用する。これらが自発的に行われないと、期待する効果が得られないのではないだろうか。さらに、ここ（本ブログの過去エントリ）でも述べたようにプロセスの一部の自動化を目指していくことになると思う。

プロセスアセスメントやプロジェクトレビュー等、第三者検証や管理の面からみると画一化されていたほうが扱いやすい。これが「開発プロセス」＝「画一化」というイメージをもたらしている原因ではないかと推測するが、マイルストーンとなる作業を必ず含めることにより、管理と柔軟性を両立できると思っている。

ソフトウェアレビュー、インスペクションのプロセスにもテーラリングはもちろん可能であり、ドイツのフラウンホーファ 実験的ソフトウェア工学研究所のChristian Denger, アメリカのメリーランド大学フラウンホーファセンタのForrest Shullが2007年のIEEE Softwareの論文記事としてまとめている。詳細はこちら（アブストラクトは無料で読める）。

皆さんの組織でのソフトウェアプロセスは画一化されているだろうか？