Win-Winプロセス(アジャイル編)

アジャイル開発の場合でも、プロセスのテーラリング(カスタマイズ)は必要です。Win-Winを実現するには、以下のような点を考慮すべきだと思います。

1.あらかじめアーキテクチャの検討をする

規 模が大きくなる前に全体を統一できるアーキテクチャがあると、開発が進めやすくなります。アーキテクチャはいくらでも発展する余地があるので、シンプルか つ効果的なものを追求しないと、UNIXの反面教師になったMULTIXや、消えていった多くの基盤ソフトウェアのように肥大化してしまいます。とはい え、中途半端だと役に立ちませんので、バランスが大切です。

2.決定権のない人の意見には依存できない

決定権のない、あるいは、調整能力のない担当者が近くにいても手戻りが発生するので、担当者の意見に依存できません。そのような場合は、担当者の根回しが容易になるように、資料やプロトタイプを用意するほうが現実的です。

3.他組織と連携する場合は、リリースタイミングを同期させる

ハードチームとの連携、別業務との連携など、協調開発が必要な場合は、計画的なイテレーションが必要です。アジャイルリリーストレインやスクラムオブスクラム(リンク先はプログラマの思索)の考え方が参考になると思います。

4.必要なドキュメントを作成する

3の場合など、実装重視でインターフェースを作成するだけでなく、隠れた制約などは厳密に定義すべきです。無駄なドキュメントは良くないですが、必要なドキュメントは積極的に作るべきです。あまり体裁を気にしないことがポイントかもしれません。

5.微妙なアジャイルもある

全 体はウォーターフォールで製造工程だけをアジャイル開発で、という表現をたまに聞きますが、それは、変化がない中で技術要件のリスクを下げているだけなの で、分割リリースやプロトタイプじゃないのか、と思わなくもないです。ただし、UIの仕様決定や細かな仕様の調整などがあれば、アジャイルかもしれませ ん。

6.基本ポリシーを決めておく

イテレーション中の仕様変更をどうするかのポリシーが明確でないと、もうリリースが最後な のでどうしてもと言われると、無理をしてでも実現したくなります。また、イテレーションをいつ終わるかのポリシーがはっきりしていないと、いつまでも終わ らないイテレーションが終わらなくなります(内製ソフトなど、終わらなくて良いようなアプリケーションが向いているという考え方もできるかもしれませ ん)。

アジャイル開発には

• 変化が前提
• スコープで調整
• 軽量プロセス

といった特徴が確かにあります。しかし、Win-WInプロセスを考えたなら、基にするプロセスの議論よりも、どのように効果的なプロセスにするか ということの方が、大切だと思います。ソフトウェアプロセスもソフトウェアであり、プロセスも実装が重要です。あらかじめきれいに作るのではなく、ある程 度見えてからリファクタリングしても良いのではないでしょうか。

そんな、Win-Winプロセスの実装にはケット駆動開発は非常に有効だと思っていますが、眠くなったので、また次回としたいと思います。