SoRとSoEをどう展開するか
「バイモーダルITモデル」とは？ 企業を変える2つの推進力を解説する
コスト削減や効率化を追求するSystems of Record（SoR）と、企業を変えて新しいビジネスチャンスを生み出すSystems of Engagement（SoE）。この2つを推進する「バイモーダルITモデル」とは。
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の戦略を台無しにしかねない。
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歩下がって潜在的な落とし穴とコストを確認する必要がある。両モードとも、運用に大きな違いはあったとしても、いずれは会社に目に見える価値をもたらすはずだ。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？ PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？ 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
-
4
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
5
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”？ データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
BMWも導入 78兆円市場に化ける「フィジカルAI」の衝撃
-
9
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
10
「AI活用を前提とした業務PCへの移行」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー