ITシステム開発のミニマリズムとリリース（過去のプロジェクト振り返りその12）

今回は、ITシステム開発におけるミニマリズムについて書く。

ソフトウェアプロジェクトサバイバルガイドによると
"ソフトウェアプロジェクトで開発に成功するためには、ソフトゥアコンポーネントとその機能の複雑さという点について、要求定義時からリリースまで「単純なほど良い」という方針が必要である。"
とある。

自分は、古い業務システムをリプレースするプロジェクトが多かったが、古いシステムとなると過去のいろいろな経緯（機能追加の蓄積等）によって、どうしても置き換える新しいシステムは複雑になりがちである。その場合、自分はシステムの断捨離を推奨する。過去に組み込まれた多くの追加機能のほとんどは、ちょっと便利な機能であり、システムの根幹を左右するほどの機能はほとんどない。
いまだ人間は非常に優秀なシステムの一部であり、追加機能に100人月かけるならば、2人の人間の手作業でしのげないかどうかを検討するべきであると考える。

ただプロジェクトを実際にやっていると、そうは言ってもということがよくある。しかし最終的にリリースするソフトウエアが複雑であっても。最初のフェーズは単純に作り、その後、機能追加していくフォーズを設ければ良いと思う。つまり最終的なリリースとコア機能の構築フェーズ、追加機能の構築フェーズを切り離し、何段階にも分けて開発・テストを繰り返せば良い。

特にウォーターフォール開発では最初に（しかも短い期間で）、すべての機能要件の詳細をつまびらかにしなければ、次のフェーズに移れないという考えがあるが、そんなことは人間には無理である。

1. コア機能の要件と理解
2. コア機能の開発・テスト
3. コア機能を踏まえた上での追加機能の要件の検討
4. 追加機能の開発・テスト
5. 繰り返し
6. リリースタイミングは、ユーザーが追加機能の充足度から判断して決めれば良い。
• 永遠に開発し続ける可能性もあるが、どこかで割り切ってリリースするはず。

おお！アジャイルっぽいとも思ったが、ちょっと違う気もする。アジャイルは早期リリースを重視するんじゃないんだっけ？？