DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ここのところ各企業のシステム再構築の話をよく耳にする。残念ながら景気回復というよりも2000年前後に導入したシステムの老朽化対応の感が強いが。今回のブログはこの再構築のあり方に触れてみたい。

私なりの解釈では、新システムの価値 = Ｆ（ユーザNeeds ＋ 新たなIT-Seeds ） となる。待ちに待った投資タイミングの到来なので、目の前のユーザNeedsを満たすだけでなく、ITのもたらすバワーを思いっきり活かして、業務や生活の様式を変える新たな価値創造を狙いたい。ここでのIT-Seedsは新しい電子機器にかぎらず、新しい志向のソフトウエアやアプリケーションも含む。そして、“狙いたい“としたのはこのことが簡単ではないからである。

現実に、皆さんの周辺にある再構築プロジェクトはどうであろうか。近年、コンサルタントの普及もあって、企画段階では実現可能性はともかくモバイル技術や高速演算等の新たなテクノロジーを活用した業務改革（ＢＰＲ）を伴うものが増えてはきた。しかしながら構築プロジェクトが発足し、要件定義行程（そもそもこれが曖昧）を進むにつれて不思議とＢＰＲ部分が薄れてこないだろうか。そして、これはベンダー主導のプロジェクトの場合に顕著である。これは「プロジェクトを無事に終える」という意向が、「良いプロダクトを構築する」という意識を上回り、チャレンジ精神が薄くなるという現象である。

リスクアセスメントばかりが先行して少しでも難易度の高いことに挑戦しない姿勢は、ＩＴによるイノベーションの芽を摘んでしまうことになる。これでは１０数年に１度、多額の費用と長い年月をかけて出来上がったシステムがとても残念な結果となる。完成したシステムはハードウエア、OS、PG原語といったプラットフォームは新しくなっても、機能は以前と変わらなければイノベーションはゼロに等しい。私はこれを”コンバージョン”（変換）と呼んでいる。

本来、プラットフォームだけの変換を施すのであれば、新システム要件は「機能は変わらずプラットフォームを移植すること」となる。従って、ソースコードがインプットの主役となる。例えばメインフレームのＣＯＢＯＬをＰＣ－ＣＯＢＯＬやＪＡＶＡに書き換えたり。。。近年、このコンバージョンを専門に手掛けるベンダーは数多く存在し、費用も比較的安価である。少なくとも再構築に要する費用の何分の１かになるハズである。

上記の再構築とコンバージョンの違いは明らかである。再構築が新システムを“創る“のに対して、コンバージョンは新システムを”作る“という表現になる。プロジェクトの企画段階で両者を識別せずに曖昧なままシステム構築に臨むケースが現実に多い。コンバージョンであればはっきりとそれを明記してベンダーへアウトソースすべきである。そうでなく再構築であれば、最後までイノベーションを追い続けなければならない。また、ＢＰＲの設計を構築ベンダーに求めてはならない。事実、大手ベンダーの品質管理の教科書には”魅力的品質は不充足であっても「仕方ない」と受け取られる品質です“と書かれている。

メソドロジーやフレームワークは生産性よくシステムを量産するための物であって、革新的なシステムを“創る”ためにはユーザ企業側のアイデアが必須である。そしてそのためのブレーンストーミングに多くの時間をかけるべきである。新たなＩＴがもたらす価値を自社の業務にどのように活かすことができるか？プロセスやデータのデザインを汎化することでシステムスコープを広げられないか？データのさらなる上流エントリーで革新的ワークフローを実現できないか？等々、そこにはまだまだイノベーションのネタは転がっている。今まで実現不可能と思っていた事でも新たなＩＴにより解決できることは間違いなく増えている。

さりとてイノベーションは簡単には行かない。ユーザへの地道な説得も必要である。プロジェクトの納期もコストも守らねばならない。様々な制約事項によってイノベーションのネタも少なからず削られていくだろう。しかし、当初目論んだ新システムの“売り“の部分は絶対に譲らないといった信念を持ち続けることは必要である。そうでなければ尖った部分は全て削られ真ん丸のつまらないシステムが出来上がるだけである。初期のシステム化の目的をキープすることは、紛れもなくプロジェクトマネージャの責務である。経営にも現場にも魅力的なシステムであることを最後まで諦めてはならない。