一括受注形態は，確実に崩壊の道をたどるだろう。今までの開発は価値を生み出さないことをユーザーが知る。そして，ユーザー自らがコントロールしながら，その近くにITエンジニアを置いて開発を行う形態が普通になる。つまり，リスクはユーザー自身がヘッジしたほうがリスクがないことに気がつく。
そのような状況になると，開発会社との契約形態は，一括受注形態からタイムアンドマテリアル契約になっていく。
|
これは，はじめから時間制限で出された要求に基づく見積もりと一括契約がナンセンスであることにユーザーが気づくころから急激に変化するように思われる。
現在，一括受注形態は，開発会社主導による無駄な要求の獲得，根拠のない見積もり，という状況がユーザーだけではなく開発会社自身をも苦しめている。
「一括受注形態が崩壊するなんてそんなバカな」と思われるかもしれないが，一度この流れが起こると，途端に津波のようにパラダイムシフトが押し寄せるだろう。もし，このような津波が日本にやってこないとすれば，日本のIT業界自体が崩壊の道をたどるようにも思える。
また，ユーザー企業が本格的に，ITがビジネスの根幹を担うことを理解すると，IT系企業とユーザー系企業の中でエンジニアの流通が始まるだろう。
フロントローディング開発は将来の布石
技術は，IT企業の生産性向上を目指す方向に発展していくばかりが注目されるが，今後生き残る技術やIT企業は，ユーザーのビジネス追従性を目指していなければならない。
将来のITプロジェクトは，システム開発プロジェクトではなく，要求開発のようなプロジェクトがビジネスとIT課題を融合したセルチームによって行われる。そのセルチームの中で，ビジネスを理解したエンジニアたちがアジャイル開発によって，ToBeのビジネスをデザインし，動かしながら評価することになるだろう。
規模の大きな開発はほとんどなくなり，ビジネスの戦略や変化を見える化しながら，ユーザー主導でかつ，ユーザー・コントロールの配下で継続的に行われる。
開発は極端に小さい単位に要求開発段階で切り出され，それぞれがSOA的な視点によりビジネス・サービスとしてWebサービス技術やコンポーネント技術によって構築される。それをマッシュアップすることで企業連携/部門連携，Web2.0的な開発が行われる。
最後まで残ると思われる大規模バックエンド系開発は，システム開発段階に必要最低限に留めつつ行われる。その姿は，むしろシステムの負の財産をいかに無くしていくかという方向で行われる。ビジネス価値の高い部分だけ，ビジネス・スピードに追従できるようにブラッシュアップされる。
これから目指すべきことは，システム開発の前段階となる要求開発段階で，必要な開発をビジネス・アジャイルによって見える化しながら，開発したり評価したりすることである。その中で行うべきテーマは次のようなものである。
- 不必要な開発を避ける
- 要求の早期検証を行う
- アーキテクチャの早期検証を行う
- 重要なビジネスはできるだけ早くリリースする
- ビジネスの変化を要求レベルで見える化しておく
このような要求開発段階における開発のことを，要求開発では「フロントローディング開発」と呼ぶ。
要求開発のフロントローディング開発は，将来のITの姿を見通した布石なのである。
| （萩本 順三＝要求開発アライアンス理事） |
