そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

作るシステムの特性と、開発プロセスの相性

こちらのブログを読みまして、面白いテーマだと思いました。
アジャイルがダメだと思う7つの理由
"アジャイル"開発の長短みたいなのか。


よく「内製か・外注」か、「請負か・業務委託か」というのでアジャイルが向いているかどうかという議論があります。
他の要因として、作るシステムがどんなものかと、と開発プロセスには相性があるのではないでしょうか。

必要な機能が予想できるか

コンシューマ向けのシステムでは、どんな機能が使われるのか完全に予想するのは難しい。

企業内で使われるシステムであっても、業界内でも先進的なアプリケーションではれば、どんな機能が自社に必要なのか予想するのは難しいでしょう。
この場合、優先度の高い最小限の機能をすばやく実装し、ユーザテストをする手法が有効です。

一方、企業内のシステムの基本的な機能であれば、機能は予測し易い

受注、発注、会計のような基本機能はもう企業内に既存のシステムがあるでしょうし、ベストプラクティスを実装したといわれているパッケージソフトもあります。この領域のアプリケーションであれば、事前に調査することで機能を定義することはできそうです。
(その企業が例えば出荷の仕組みを独自にこれから新しい仕組みを作っていくんだという場合は、この限りではありません。)

また、企業システムの基本的なシステムであれば、一部は新しいシステムに実装されていて、残りは古いシステムに残っている状態で、ユーザの二重入力や、システム間のデータ同期はやりたくないので、リリースの単位も大きくなる傾向があります。
その為、リリースのロードマップとしては、A機能やってから半年後にB機能という機能単位ではなく、全てメインの機能をA事業部にパイロット導入し、次にB事業部といった導入になろうかと思います。

この場合、アジャイル的なプロセスのメリットのいくつかは関係ないでしょう。
パッケージを使ったプロトタイピング型の導入方法や、その他の条件でウォータフォールやアジャイルを選択することになるのではないでしょうか。


下記でやっているプロジェクトでは、2つめのパターンに近いので変化への対応という観点ではアジャイルのメリットは小さかったのですが、内製で細く長くシステム開発を続けるために、チームの学習という効果に着目してアジャイルを取り入れた開発プロセスを採用しました。

アジャイル開発プロセスへの様々な関係者からの期待値とプロジェクトスタート
改善した開発プロセスを評価する。定量評価だけではなく、情報システム部門の戦略にあっているか?