高額の申請は現代では特に申請しにくい。何本にも分けて申請が上がるのは、経営からまたか?と言われてしまい、とてもやりにくい。した問題に対処するために、「プログラム管理」という名称でかつ複数プロジェクトで統合的にROIを管理するという考え方がないわけではないが、そうした管理体制が整っているなんて全く期待できない。段階的に作るのはいい面が沢山ある。習熟した開発陣が次から次へのシステム構築にあたることができ、生産性が後稼働のシステムほど高くなる。ケースが乗数的に少なくなり、システムテストが楽になる。その分、プロジェクト管理や一つ当たりのスケジュールが速くなる。成功の可能性もあがるのだが、如何せん、開始から終了までの期間が長い。期間が都合5年かかるということなどざらで、3年間以上かかることも覚悟しなければならない。なると、途中で経営陣が変わる、コアとなる幹部層が人事異動することなどもざらで、プロジェクトへの波風を乗り切ることが難しくなるうえ、現代の速度重視の経営とは少々折り合いが付きにくい。ここには、発想の転換が必要だと考えている。答えは、「作り続ける」ことにある。大規模なシステム開発の場合、「次世代」とか「次期」とか、そういう呼び方をしていくことが多い。自然と投資をする局面としない局面をわけて考えていることが多い。ある局面で大規模投資をして、ある局面では休む。システムの利用年数は、ある調査によれば平均17年という結果もあるが、数年大規模投資を行って10数年は保守・運用費用でしのぐというやり方だろう。この業務的慣習は、歴史的な経緯によると筆者は考えている。最初に作ってから、HW等が老朽化してきて作り直す、新たなソリューションが現れて作り直すということが行われてきているが、そうしたサイクルをそのまま今も継続しているのであろう。しており、これらを作り直すことは大予算化、長期化することは当然であり、失敗の可能性は極めて高い状態である。一定の投資をし続け、作り続けることを考え、どんどん生産性を上げるような形にしていくべきだ。これは、経営からしてみると、財務的なインパクトがないうえ、毎年効率化効果を期待できるモデルでもある。理解さえしてもらえれば、経営は数年サイクルでやってくる大規模投資を考える必要性はなくなってくる。財務的には固定化が進んでいくからだ。欧米の大企業ではこの考え方を取り入れるとこも沢山ある。インドやイスラエル、東欧、南米などに大規模開発センターを作るところがそうだ。欧米の技術者よりも、これらの国の「オフショアセンター」の開発者は安い。した技術者を大量に抱え、これらの技術者が作れる分だけ、システムを作り替えていくのだ。後述で語っていくこととなるが、これらは要件定義力の問題ではなく、戦略の問題である。戦略を立てることで、要件定義を簡単にしていく。したIT部門の業務の再構築が、失敗を減らす肝となっていくのだ。した戦略施策を用いることは、次の段階だろう。ここはやはり、オーソドックスな施策を考えておきたい。それは、月並みな言い方なのであるが、経営とユーザーに諦めてもらう努力をすることだ。経営とは、「やれ、急げ、安くやれ、障害は出すな」としか言わない。そこに、優先順位をつけてもらうことだけは、やっておこう。最近は、経営も随分とものわかりが良くなってきていると感じる。要件定義をきちんとやらないとシステム開発は失敗するということは理解している。Tweet関連する記事2017.12.11要件定義力を徹底的に再構築する:5要件定義を簡単にしていく。MiyamotoBA参画前は、某外資系ファームで統括を務める。17業種のNo1/No2企業を経験した異色のIT戦略コンサルタント。