「バイモーダルITモデル」とは？　企業を変える2つの推進力を解説する

コスト削減や効率化を追求するSystems of Record（SoR）と、企業を変えて新しいビジネスチャンスを生み出すSystems of Engagement（SoE）。この2つを推進する「バイモーダルITモデル」とは。

公開 2017年04月05日 12時00分

著者

Stephen J. Bigelow

[TechTarget]

印刷する

2016年6月にガートナージャパンは、バイモーダルなIT組織に関する調査結果を発表。デジタルテクノロジを使用したプロジェクトの予定や実績がある企業のうち、約3割は従来のIT部門とは別に専門組織を立ち上げていることが明らかになった（出典：ガートナージャパン）

　「バイモーダルITモデル」では、ITは2つの異なるモードに分割される。Systems of Record（SoR）としてのモード1と、Systems of Engagement（SoE）としてのモード2だ。ではITが分割されるとコストも2倍に増えるのだろうか。

　モード1の構造は、安定性と信頼性が求められるレガシーハードウェアと中核的なバックエンドソフトウェアスタックで構成され、これは一般的に、従来型のIT運用を通じて達成される。モード2は高速で非直線的なアジャイル業務で構成され、一般的には会社にとっての新しいチャンスをもたらす。2つの独立したチームが同時に機能して、その2種類のシステムの最適化に当たる。バイモーダルIT戦略の長期的な価値についてはITエキスパートの間で論議があるものの、この概念は、システム開発の中核的な前提、すなわち必ずしも1つで全てに対応できるとは限らないという前提を追認したものだ。

　サイロの解消や人材と技術の最適化を図るこの時代にあって、バイモーダルITでは新旧の間の壁が制度化され、組織が予想せず、予算割り当ても行っていないコストが発生する。そのような見過ごされたコストは、バイモーダルITの戦略を台無しにしかねない。

バイモーダルITとは何か

DevOpsとアジャイル開発

1.スキル獲得のための投資

　組織では、バイモーダルIT環境のためのハードウェアおよびソフトウェアスキルセットを育成あるいは獲得するために必要な投資が見過ごされがちだ。新しいITプロフェッショナルは、メインフレームのような従来型のハードウェアプラットフォームに関する専門知識をほとんど持っていない。同様に、新しい開発者はC++、Java、HTML、Python、PHPのことをほとんど知らず、メインフレームOSに使われているCOBOLやジョブ制御言語（JCL）などのスクリプトを扱う年配プログラマーの代替を務めることができない。モード1では、GoやSwiftといった新興の言語に機会を求める人材の獲得は難しい。

　企業は割増給与を支払ってスキルを持った従業員を獲得したり、つなぎ留めたりすることもできるが、金銭だけではそれほど長期的な動機付けにはならない。横断的な研修を行って既存の従業員に両方のモードを担当させることも可能だが、研修は予想が付きにくく、従業員の職務が変わったり退社したりすれば繰り返しコストが発生する。業務の外部委託は、少なくともレベルの低いタスクの場合はもう1つの選択肢となり得るが、一部のプロジェクト管理や知的財産は社外に移転される。

2．ヘルプ求む

　たとえ適切なスキルが存在していたとしても、既存の従業員の構成ではバイモーダルITが現実的ではない場合もある。すなわち、バイモーダルITモデルにおける別々の2つのITデリバリグループを支えられるだけのスキルを持った適切な人材が不足しているかもしれない。企業はいずれかのモード、または両方のモードについて、従業員数を増やさなければならない。

　追加的な人件費に加え、バイモーダルは従業員の動機やキャリア目標に複雑な影響をもたらす。バイモーダルITに対する主な不満の1つとして、レガシーシステムと革新システムとを意図的に切り分けることによって、モード1の従業員がただシステムを稼働させ続けるだけなのに対し、モード2の従業員はビジネスの価値を増大させる興味深い業務を担うことになる。ITプロフェッショナルならどちらのチームに所属したいと思うだろうか。

　バイモーダルIT戦略を採用するビジネスリーダーは一致して、モード1プロジェクトの価値の高さを強調し、それに応じた報酬をモード1の担当者に支払う努力をしなければならない。一部の組織はチーム間で定期的に担当者の入れ替えを実施する。これは横断的なスキル獲得の一助となり、チーム間のコミュニケーションや協力を促して互いの間の障壁やサイロを緩和させる。

3.技術者のツール

　ITデリバリのそれぞれのモードは、必然的に、異なるツール群を必要とする。メインフレーム管理プラットフォームやソフトウェア開発ツールは、クラウドリソースを使うDevOps形式の継続的な開発やデプロイには適さない。

　例えば、特定のメインフレームではCOBOL、TSO I/Oスプーラ、z/OS、Interactive System Productivity Facilityのソースコード、テキストエディタおよびJCLスクリプトを必要とする。同じ会社内の分散型サービスクラスタはWindows Server 2012 OSインスタンスを搭載し、仮想化ツールのVMware ESXiやMicrosoftの管理ツールであるSystem CenterやChefといったポイントツールを使ってモニタや管理を行っている。そのシステムでホスティングされているサービスは、.NETなどの開発プラットフォームに依存する。

　エンタープライズITツールの利用が無料であることはほとんどなく、特に複数のツールセットは予算上の課題となっている。全てのツールについて、取得コストとそのツールをホスティングする環境、ライフタイムを通じたメンテナンス（構成、パッチ、更新を含む）、ユーザーの継続的な研修のコストを考慮する必要がある。ベンダーによるサポート料金がかかるツールも多い。オープンソースツールでさえも時間を取られ、チームの専門知識が求められる。

　ITツールセットが異なれば、バイモーダルITチーム間のコミュニケーションギャップが生じる可能性もある。

4.古いシステムのメンテナンス

　従来型のソフトウェアは必然的に、ハードウェアと結び付き、直接的に専用のメモリロケーションやバッファ、ポートといった物理要素を必要とする。そうしたソフトウェアと新しいハードウェアは、集中的かつ大規模な支障も出かねない移行を行わない限りは、相互運用はできない。結果としていつの間にか、開発者が古くなったコードをメンテナンスしてさらに古いハードウェアを稼働させなければならない状況に追い込まれる。バイモーダルITモデルでは、これが一部のモード1業務にとっての課題となる、

　古いハードウェアは企業にとって、増大し続けるサポート関連コストとリスクを発生させる。ベンダーには、新しいツールやサービスを売り込むために古いシステムを引退させる動機がある。古いパーツの希少性が増すほど、極めてありふれた部品でさえも価格は上昇する。場合によっては部品がベンダーから調達できなくなり、再販・中古市場でしか見つけられなくなることもある。

　前述した通り、ハードウェアを支えるスキルベースも時間がたつにつれて衰退する。ベンダーは一般的に、保証期間とサービス契約期間を通じて研修や技術サポートを提供する。しかしシステムのライフサイクル終了時期に到達すると、OEMベンダーはサービス契約を打ち切り、IT部門はサードパーティーのサポート組織を探す必要に迫られる。

　最終的に、企業は投資を回収できる見込みのない状況でレガシーハードウェアに出費する。モード1のシステムとソフトウェアは、いずれ引退させなければならない。

5.時は金なり

　ビジネスリーダーはポリシーや手順から抜け落ちたコストがあることを想定しなければならない。現代のITデリバリではポリシーをワークフローに変換し、オーケストレーションと自動化を通じてそのスリム化を図る。バイモーダルITはモデル1とモデル2のポリシーおよび手順を必要とする。各チームは2種類のプロセスの策定と実装、メンテナンスに時間を費やし、ツールを調達する必要が生じるかもしれない。複数のプロセスをバイモーダルITモデルで運用する複雑さやスタッフの混乱に伴う予想外のコストも発生する。1つのモードに慣れた担当者が別のモードに移ると、見過ごしや手違い、コンプライアンス違反が発生し得る。

　バイモーダルITプロセスは、関係が交錯することもある。例えばモード2チームがリリースした革新的な新アプレットが、モード1システムの複雑なデータベースに問い合わせを行う場合、最も低速な部分（モード1）が最速部分（モード2）の開発の足かせとなることもある。この場合、データベースを更新して新しい複雑なクエリーに対応できるようになるまで、アプレットは待たなければならない。プロセスの遅れは、収益の減少や市場での競争力の低下につながることもある。

　バイモーダルITのもう1つの原則として、モード1のレガシーアプリケーションは近代化され、機動性の高いシステムに入れ替えられる。モード2の革新的なシステムは時が経てば確立され、安定した予測可能なワークロードになる。もしチームが静的なモード1とモード2の業務を画一化すれば、両方でこの展開が妨げられる。バイモーダルITを中心としたビジネスの構築を計画している場合でも、DevOpsのような動的なITデリバリパラダイムへの移行と見なす場合でも、1歩下がって潜在的な落とし穴とコストを確認する必要がある。両モードとも、運用に大きな違いはあったとしても、いずれは会社に目に見える価値をもたらすはずだ。

印刷する