開発での無駄がコスト高に繋がる

開発コストを下げ、リスクを下げ、稼働までの時間を短縮して業務に貢献する開発手法はあるのか？
あります。単純な話です。無駄なものを開発しない。ソレにつきます。

ではどうすれば無駄な開発をしなくてよいのか？
通常の開発での無駄はここにあります。

1. 実物で検証しない設計に基づく実装で、テスト段階に入ってから不具合が多発する開発

2. 役割分担の不明確なアーキテクチャに基づく設計

3. 既存基幹システムの入替えに伴う間違ったゴール設定

実物で検証しない設計に基づく実装で、テスト段階に入ってから不具合が多発する開発

従来の開発手法だと、設計の確からしさの担保を取らず、実装では作るだけ作って、テストフェーズにて初めて機能的バグ・性能的バグに遭遇し、設計からやり直す事もできず、とりあえず動くだけのモノを仕上げるという流れのはずです。これではSIベンダー側もリスクを工数に載せて見積もるため、巨額の見積もりになってしまっています。
設計を実証することは非常に重要です。机上検証で済まそうとするプロジェクトが非常に多いですが、実際にモノを作って確認することで、気付きがたくさん生まれます。業務側が必要と思っていたことは実は必要ではなかった、むしろ他の要件が必要だった、非同期通信でも業務として成り立つ事がわかった等、結構あるものです。
モノは完成品を指すのではなく、2−3のユースケースが実行できるだけの範囲で構いません。木を描くのであれば、枝葉はなく幹だけを描いた状態です。
初期段階で設計上の問題点、改善点がわかると、それを修正したものを次に作ります。その繰り返しで最終的に業務が完全に遂行できるものを作ることで、品質を最優先とした設計開発ができ、それは工数の削減に大きく寄与するのです。

役割分担の不明確なアーキテクチャに基づく設計

JavaやVisualBasic等の高級言語は、やろうと思えば何でも出来てしまいます。その利便性のおかげで、いろんな役割を一つのソースコードとしてアプリケーションに仕立ててしまいます。これが所謂「モノリス（一枚岩）」の構造というものです。言うなれば昭和時代にあったデパートの「お好み食堂」です。
この「モノリス」の何が良くないかというと、データ・ロジック・プロセス・画面が渾然一体となっているため、改修を行おうとするといろいろなところを修正しなければいけません。すなわち、どこを修正すればよいかの事前検証も行う必要があります。さらに性能が出ないような場合、モノリスのアプリごと多重化しなくてはならず、無駄なリソースの消費に繋がります。

アプリケーションアーキテクチャとして役割分担を明確にし、それぞれのサービスが役割を超えたことを行わないようにするだけで、全体はシンプルになり修正箇所もわかりやすくなるのです。「お好み食堂」から複数の専門店の集まる「フードコート」にすることで、どこを修正すべきか、どこを多重化すべきかが明確になり、結果的にコストの削減に繋がります。

既存基幹システムの入替えに伴う間違ったゴール設定

システムをリニューアルするときに良くある指標として、「ソースコードレベルでの完全移植」があります。現行システムの全てのモジュール・関数をそのまま移植することでリスクを減らすというのがその狙いと思われますが、これは現在は必要としていないものまで移植するだけではなく、言語仕様の違いを無理やり合わせることによるバグの創出に繋がります。
多くの経営者や業務側が望んでいるのは、現行ソースコードの完全移植ではなく、現行と同じ処理結果になる、軽量化されモダナイズされた新しいシステムです。つまり、設定すべきゴールは処理結果の同一性であり、完全移植ではないのです。

解決策

この3つの鍵をコントロールできるのが、アプリケーションの中心的役割にフォーカスし、実装・テストを繰り返し、課題を解決しながら開発するルール駆動開発です。さらに、ロジックを業務ユーザが作るのと同じく宣言的に記述し、手続き的に書かないルールエンジンを併用すると、その効果は更に向上します。

私が過去に関わった複数のお客様プロジェクトでは、現行システムからの作り直しプロジェクトにおいて、開発工数では50〜90%以上の削減を達成しています。従来の開発より高度な設計・開発をしており、工数の単価をそれなりに上げさせていただいていますので、残念ながら「費用も90%の削減」とはなりませんが、10年以上にわたって適切に更新し続けており、長期で見たときの工数削減と適時施策の実施による収益の向上にかなりの貢献をしているのは間違いありません。