仕事柄、各社のエンタープライズシステム再構築案件という情報をキャッチすることが多いです。この2年ほど、国内では超高速開発ツールを使った再構築というテーマが急浮上しており、Wagbyも選択肢の一つとして検討されるためです。ツールを使った開発を検討するユーザー企業は、SIerへの一括発注ではなく、自らプロジェクトを主導しようという意気込みがあります。しかしユーザー企業の立場は一枚岩ではありません。超高速開発ツールの評価の前に、そもそもこのような大規模なプロジェクトが（自分たち主導で）できるのか？という不安を抱えています。それは当然で、ブラックボックスと化した現在のエンタープライズシステムを解析し、その上で新システムを再構築するというのは、先輩たちがゼロから開発した時代に比べて、より難易度が高くなっているといえます。
それでも再構築には、さまざまなメリットがあります。
- 若手技術者への技術継承（プログラミングスキルではなく、業務ノウハウの継承）を通して、会社の存続を確かなものにする。
- 現行システムで使っていない、あるいは使う機会の少ない機能を減らすことで、保守コストを削減する。
- インターネットを使った新しいサービスとの親和性を高める。
特に
「人」
の問題は重要です。エンタープライズシステムを知るということは、企業の収益の源泉であるヒト・モノ・カネの流れを把握できるということです。そういう人材を社内で育成すれば、経営と IT の直結というテーマが理想論ではなく、現実的になります。
しかしそうはいっても、再構築のリスク要因はあまりにも高いというのも直視すべき事実です。特に悩ましいのが現行システムの踏襲という部分です。
- 複数のサブシステムで業務用語が統一されていない、もしくは異なる意味で使われている。
- なぜ、そういう仕様になったのか、わからない。
- あまり使われていない機能にもかかわらず、これがないと仕事ができないという現場の声に押し切られ、作らざるをえない。
関係者が増えるほど、この調整は時間を費やします。結果、プロジェクトリーダーが調整段階で燃え尽きてしまい、再構築が頓挫するのはもったいない話です。
そこで私から提案があります。再構築にあたって、この機能は対象外とする（捨てる）基準づくりを最初に行うというものです。
各部門とのヒアリングにあたっては、この基準に照らし合わせることにします。
捨てる基準は、経営指標で捉える
現行システムで、ほとんど使わない機能であっても、現場としては保険のために確保しておきたいでしょう。
さらに、丁寧に作りこまれた画面機能であればあるほど、同じ機能を求めるでしょうが、これが再構築を難しくする理由の一つでもあります。
私の知る範囲では、情報システム部は「捨てる基準」を明確にしないまま「使われていない機能があれば（再構築のタイミングで）削減したい」という話を切り出し、現場の反対に押し切られるということが多いようです。そこに新システムへの要望が重なり、仕様は膨らみ続けます。これではプロジェクト開始前の見積もりをオーバーするのは当然です。
そこで最初に、現行システムの機能が支えている売上および利益率を洗い出す、ことを提案します。つまり、その機能が生み出す売上および利益率を一覧表とするのです。
可能であれば、過去10年の推移があるとよいです。これによって、伸びているのか、現状維持なのか、減っているのかということも明確になります。さらに、この機能の保守のために要している現行費用（外部エンジニアの常駐コストを含む）や、再構築に要する見積もりも加味します。
この一覧表を、経営陣に判断してもらいます。「ITのことはわからない」という経営者であっても、これは興味をもつに違いありません。その上で、限られた開発予算をどの分野に重点配分するかを決めてもらいます。情報システム部が決めるのではありません。経営判断がなされるということです。当然のことながら、現在の売上は高くても、売上自体が横ばいか減少傾向にある分野への高い投資は望めません。経営陣として、将来伸ばしたい分野へ開発予算を投資するという判断を行うはずです。
この結果をもって、再び現場と話し合うのです。情報システム部は経営陣からのお墨付きがないと現場との交渉は難しいでしょう。社長から、単に「情報システム部に任せている」という程度の言質は、ないよりはマシという程度です。どの組織も数字で語る文化があるでしょうから、見える化された一覧表は説得力があります。
しかし現場から「そうはいってもこの機能がないと困る」という声が上がるのは当然です。そこで次は、会社全体のシステム開発予算とは別に、現場自身の負担でシステム開発費を上乗せできるかどうかの調整を行います。自らの身を削っても欲しい機能なのかどうか、は一考に値します。または、この機能が新たに追加されれば、売上もしくは利益率が伸びるという提案があれば、それも一考すべきです。再構築の究極のゴールは、それによって会社の売上または利益が向上することです。部門の長が約束するのであれば、情報システム部としてもやりがいのある仕事と判断でき、難しい機能（画面）であっても実現しよう、という気持ちになるでしょう。ただしその約束は、部門の長が（情報システム部に対してではなく）経営陣に対して行うものです。
逆にいえば、そこまでの熱意をもった議論にならないのであれば、それは捨てる機能（または簡素化できる機能）と判断してよい、ということです。
捨てる基準づくりのもう一つのメリット
この基準づくりを通して、経営陣がどの分野を伸ばそうとしているか、そして現場はどこまで具体的な改善案を提示できるかが明らかになります。システム再構築という切り口をとおして、このような議論を内部で活発化させることは、組織を熱くするメリットです。それが面倒だからと目をつぶって「現行と同じ機能を踏襲すること」や「パッケージソフトに乗り換えること」を優先するのは、なんとも、もったいないことです。
まとめます。経営陣ならびに情報システム部の責任者が、システム再構築とはハードウェアのリース切れや、クラウドにすれば保守コストが安くなりそうだから、という理由で捉えるのは、スタート時点ですでに間違っています。そうではなく、会社をさらに成長させるエンジンをつくるのだという気持ちで企画・主導していくという意思で進めることができれば、再構築プロジェクトは全社を熱くすることができます。エンタープライズシステムには、それだけの力があります。
