プロセス改善エッセンス (PHASE 0)長沢 智治

はじめに

ソフトウェアの開発業務は、チームで遂行されています。チームで実施されている以上、そこには何らかのプロセスが存在しています。仮にプロセスがなかったならば、そのプロジェクトは、何を基準にして遂行されていくのでしょうか? 何を基準に進捗や品質を測っていくのでしょうか? 何を基準に人々はコラボレーションしていくのでしょうか?

このコラムでは、開発プロセスについてエッセンスをご紹介していきます。開発ライフを充実させるための考える材料の一部としていただければ幸いです。

オープンな開発プロセスのススメ

開発のプロセスは、明確に規定しているかいないかは別として、必ずプロジェクトには存在しているはずです。また、開発プロセスを標準化している組織もあれば、標準化せず各プロジェクトの裁量に任されている場合もあるでしょう。しかしながら、どの場合にせよ、開発プロセス自体は、暗黙知であっても存在しているはずです。

ひとつの理想形としては、標準の開発プロセスが確立されており、さらに開発するシステムやプロジェクトに応じてカスタマイズ (テーラリング) が行えるとよいでしょう。

すなわち、必要最小限の作法は、基本的にエンジニア共通で持ち合わせ、その上で、プロジェクトの特性に応じて柔軟に対応できる開発プロセスを確立するということになります (図 1)。

図 1.　開発プロセスの一つの理想的な形

そのためには、開発プロセスのオープン性が重要になってきます。オープンというのは、開発プロセス文書をファイリングして、各チームの書棚に配布するとか、社内の Web サイトや、ファイルサーバーで閲覧できるようにするということではなく (これらももちろん重要です)、開発プロセスの「今」をオープンにするということを指しています。

開発技術の進化やシステムに対する期待、部門の状況に応じて、開発プロセスも日々進化し続けられることが重要になってきますが、その上で、気をつけるべきは、「今」を知ることです。

その開発プロセスが状況に対応しているのか、対応していないのかを知ることも重要です。これにより、その開発プロセスを採用すべきかどうかが決まってきます。また、その判断材料の提供も必要になってきます。ある意味膨大なドキュメントとなる傾向のある開発プロセスのすべてを読み解かなくては、適用可能性が把握できないならば、その開発プロセスがどんなにすばらしくても、採用されることはないでしょう (図 2)。

図 2.　開発プロセスの適用とフィードバック

そのためには、開発プロセスの改訂について見える形にしておくことが重要になります。これが開発プロセスのオープン性のひとつのカギとなります。今回の改訂で何が変わるのか、それが自分たちのプロジェクトにとって影響があるのか、それは抱えている課題の解決になるのかを知ることができれば、開発プロセスの活用が促進されます。それだけではなく、開発プロセスに対するフィードバックも行いやすい土壌となるでしょう。

このフィードバックが、開発現場と標準の開発プロセスの間に次第に広がってくるギャップを作らない秘訣となります。開発プロセスの不備や、不足部分を埋めるベストプラクティスなどをフィードバックし、積極的に取り入れていることで、開発プロセスを進化させていくことで、現場で実践しやすい開発プロセスを作り上げ、維持していくことが可能となるでしょう。