フリーワード検索


タグ検索

  • 注目キーワード
    業種
    目的・課題
    専門家
    国・地域

NRI トップ ナレッジ・インサイト コラム コラム一覧 DX時代においてIT部門に求められる目利き力とは

DX時代においてIT部門に求められる目利き力とは

2023/07/19

  • Facebook
  • Twitter
  • LinkedIn

序章

現在の企業経営において、ITが担う領域は日々加速度的に広がるばかりである。流行りのChat GPTに、試しにこんなことを聞いてみた。

「IT部門の部長になりきって、日々の悩みをぼやいてみてください。」

  1. 経営層が「デジタルトランスフォーメーションを加速しよう」と言っているけど、現場ユーザーの業務効率化にも目を向けないといけないと悩んでいる。
  2. 現場ユーザーが「業務改善に役立つシステムが欲しい」と言っているのを聞いて、どうすれば経営層の期待と現場の要望を満たせるシステムができるのか悩んでいる。
  3. ウォーターフォール開発とアジャイル開発のどちらが我が社のプロジェクトに最適か、なかなか決断ができず悩んでいる。
  4. 社内で開発スキルを持つ人材を確保するための教育プログラムを検討しなければならないが、何を重視すればいいのか分からない。
  5. 自社で開発を進めるか、ベンダーと協力して進めるか、どちらが経営層と現場ユーザーの要望を実現できるか悩んでいる。
  6. ベンダー選びで迷っているうちに、他社との競争力がなくなってしまうのではと心配している。

(2023年2月時点の回答)

真に迫る悩みの数々に、目を見張るばかりである。
DXの号令のもとに、安易なSaaSやアジャイル手法をとりあえず導入してみる。現場部門をプロジェクトオーナーにした結果、これまでのシステム開発のナレッジが役に立たず、IT部門の開発手法が悪いとやり玉にあげられる。どちらも往々にしてありえるシナリオだ。

このコラムでは、技術刷新が加速するなかで、企業のIT部門がシステム開発を適切に進める為のプロジェクト分類方法、その分類に基づくITベンダー選定のポイント、すなわち「IT部門に求められる目利き力」を整理してみたい。

システム開発プロジェクトの類型化

企業におけるシステムは、企業価値を創造し、適切に管理し、分析するため、つまり、いずれも価値を取り扱うために存在すると言えるだろう。したがってシステム開発プロジェクトは、「自社の価値をどのように取り扱うためのシステムか」という観点に着目することで分類できる。以下の項で、具体的に見ていこう。

価値を管理するシステム

価値を管理するシステムとは、自社が生み出した価値を効率的に管理するためのシステムのことである。社内情報共有システムやメール・チャットなどのコミュニケーション基盤、セキュリティ基盤などのインフラ基盤に加えて、財務会計システム、他社との差別化要因とならない周辺業務領域における業務システム等が挙げられる。本類型に属するシステム開発プロジェクトのゴールは業務の合理化・省力化などとなる。業務標準化を目指すため、SAPに代表されるERPやパッケージソフトを利用することが多い。留意するべきは、他社との差別化要因となる競争優位性を保持した基幹業務領域のシステムについては、本類型に含まれないという点である。

価値を分析するシステム

価値を分析するシステムとは、自社が生み出した価値を見える化し、経営判断を支援するためのシステムである。BI(Business Intelligence)、収益・需給シミュレーション、管理会計システムなどが挙げられる。本類型に属するシステムは、社内の価値の適切な集計・加工を可能にして、作成されたアウトプットは、迅速な経営判断のために活用される。一方で、アウトプットを確認するのはマネジメント層などに、ある程度限定される。別システムでの利用も限定的なことが多い。したがって、比較的チャレンジングなプロジェクトを実行しやすい類型といえよう。

価値を創造するシステム

価値を創造するシステムとは、自社が相対する顧客に付加価値を提供する、利益の源泉を生み出すためのシステムである。商品・サービス管理、顧客が直接利用するECフロントなどが挙げられる。この類型に属するシステムは、ときに社内に存在しない業務を生み出す必要があるため、技術的にも確立されたノウハウがあるとは限らない。一方で、後続の業務を実行するために「1.1価値を管理するシステム」に適切にデータを連携する必要がある。最新技術や新規事業への挑戦とセットになることの多いプロジェクトでありながら、システム品質も両立する必要がある難解な類型である。

ここまでで気づく方も多いと思う。この類型化はメインフレームの導入から始まり、ERPの隆盛、BIシステムの導入、DXブームといったシステム開発の流行の歴史に重なるものである。しかし現在において、その歴史は過去のものになったわけではない。価値という観点で整理すれば、企業におけるシステム開発プロジェクトは、上記が全て並列に存在する時代なのである。

出所)野村総合研究所

システム開発プロジェクトの特性とIT部門の関わり方

次にそれぞれの類型に対して、企業のIT部門はどのように関わる必要があるのか。システム類型別に見ていく。

価値を管理するシステムへの関わり方

価値を管理するシステムの最大の目的は、業務プロセスの実行にともなって発生するデータの適切な管理、及びプロセスの合理化・標準化である。他社との差別化要因とならないのだから、パッケージ製品やSaaSの活用を前提とした従来の開発手法を踏襲する想定でよいだろう。ただしIT部門がプロジェクトを主体的にリードすることが求められるため、下記を意識する必要がある。

重要Point①「ユーザーのこだわりの分析」

業務標準化が目的のシステムの場合、「業務をパッケージにあわせる」という方針で進める必要があり、ユーザーのこだわりを考慮する余地は少ない。しかし、ユーザーがパッケージに適合しない業務にこだわりを持っているケースもある。そのような場面でIT部門が行うべきは、「こだわりが自社の生み出す価値に直結しているか」を判断することである。もし、そのユーザーの言い分が正しければ、業務標準化はユーザー部門からの反発ばかりか、自社の価値の低減に繋がる可能性がある。

重要Point②「こだわりの切り出し、結節点のAPI化」

上記を踏まえて、IT部門がとるべきアクションは、こだわりの切り出し、結節点のAPI化である。具体的には下記2パターンとなる。

①こだわりが価値を生んでいないなら、プロジェクトオーナーの号令のもとで、業務の標準化を断行する。もしくはシステムから、データを手動で出力できるように対応し、引き続きユーザーに当該業務を実施させる。

②こだわりが価値を生むなら、別システムにデータを取り扱えるようなAPI化を検討する必要がある。価値を生むこだわり部分は、標準化や合理化の枠組みからは外れる場合が多いので、価値を創造するシステムとして別建てした上で、APIを結節点として連携させる必要があるだろう。

価値を分析するシステムへの関わり方

価値を分析するシステムにおいて、重要なのはリアルタイム性とわかりやすさである。ユーザーであるマネジメント層は常に多忙であり、スピードを求めている。そのため、現状の基幹システムが保持しているデータをどれだけ分かりやすく、迅速に伝えられるかが大切だ。

重要Point「業務データの保持粒度・更新サイクルの把握」

こうした背景をふまえ、適切なシステムを開発するためには、現状の基幹システムがどのような組織単位で、どのような粒度のデータを保持しているかを理解していることが大前提である。具体的には自社の財務・管理会計システムのデータ保持粒度、更新サイクルを把握する必要がある。

一方で本領域のシステムは、利用者も少なく、作成したデータが後続のシステムに連携されることも限定的である。したがって、求められるシステム品質が相対的に低い。PoCによるシステムのお試しや、自社開発を最初に行うターゲットとして、適切であるとも考えられる。

価値を創造するシステムへの関わり方

価値を創造するシステムにおいては、いかに顧客に価値を柔軟に俊敏に提供できるかが最大の要件となる。現在において、価値を創造するためには、最新デジタル技術の活用を選択肢として持たなければならない。結果として、花形の領域の野心的なプロジェクト計画が立てられる傾向にある。またシステムのユーザーが顧客であることが多いため、業務に近い部門がオーナーとなってシステム開発プロジェクトが進められることも多い。IT部門としては後方支援が多くなることがありがちな領域であるが、注意しなければならないことは2点ある。

重要Point①「スケーラビリティの妥当性判断」

こうしたシステムは、DXプロジェクトの冠のもとに、アジャイル開発やリーン開発などの流行りの開発方法論を選択してしまいがちである。また、開発当初はスモールスタートで効果を検証し、本格導入に併せて、ユーザーや業務領域を拡大することも多い。そのため、リリース後のスケールアップを前提として、クラウドの利用を選択することも多々ある。IT部門のプロジェクト担当者は、その際に課題が発生するリスクを、当初から意識すべきだろう。
本格的に利用を開始したタイミングで、データ量や利用者数が当初想定を大きく上回るとシステムが設計通りに機能しない問題(所謂、性能問題)が発生し、解決に多くの時間と費用を必要とする。場合によっては、プロジェクトが頓挫することもあるだろう。特にマイクロサービスや分散化を前提とした開発されたシステムは、性能面で問題を抱えることも多い。IT部門としては、その点を意識してプロジェクト計画時点の評価を行う必要がある。

重要Point②「会計システムを代表としたビジネスプロセスへの影響」

次に注意すべきは、本類型のプロジェクトで発生したデータは、価値を創造するだけで終わりではなく、それを会計的に正しく記帳するところまでがシステムのスコープであるという点である。すなわち、これらのシステムに対しては、受発注・在庫管理を行うシステム並みの品質が求められる。

ユーザー部門は自らが従事する業務範囲については詳しいが、結果として生み出された売上利益が、どのような勘定科目で、どのように会計システムに連携されているのか、間接費用の諸掛・手数料などが、どのように計上されているかまでは理解していないケースも散見される。

会計システムへ連携されるデータに漏れや誤りが発生した場合、その影響は会計業務に直結する。IT部門は、その業務においてどのような勘定科目が発生し、どのようなデータが、いつ会計システムに登録されるかという点については、ユーザー部門に任せきりにすることなく、自分たちで把握する必要がある。

【図】システム類型別・IT部門が気を付けるべきポイント

出所)野村総合研究所

システム開発プロジェクトの特性ごとのITベンダーの選定基準

最後に、システム開発プロジェクトの特性を踏まえて、IT部門はITベンダーをどのように選定するべきかを整理したい。

そもそも、システムを初期開発するだけであれば、必ずしもITベンダーを利用する必要はない。技術者を集めて、自社開発すればいいのだ。 それでも、ITベンダーと協業するプロジェクトが多数存在するのは、ITベンダーが、一企業では想定・対応できないようなリスクを吸収するリスクテイカーとして機能するからである。しかし、ITベンダーによるリスクヘッジにも特色がある。企業のIT部門は、先述したシステムの類型を参考に、適切なリスクテイクできる強みを持ったITベンダーを選定することが重要となる。

価値を管理するシステムにおけるリスク

本類型においては「標準化するべき業務」と、付加価値を生み出している「こだわりの業務」の見極めの失敗がリスク要因となる。それを防ぐためには「標準化に向けた説得力のある他社事例を提示できる他社の業務要件に精通した人材・システムに強みがあること」「付加価値を生み出している『ユーザーのこだわり』を、プロジェクトオーナー・ユーザーに双方が納得できる形で見える化し、落としどころを見つけられるスキルがあること」を選定基準とする必要がある。

価値を分析するシステムにおけるリスク

本類型においては、他の類型に比べ、システム開発のリスクは相対的に低い。したがって、システムソリューションの内容、開発コストを重視して、チャレンジングなITベンダーを選定することが可能である。

価値を創造するシステムにおけるリスク

本類型においては、「スケーラビリティ」「実運用での既存システム・ビジネスプロセスへの影響」がリスク要因となる。野心的なプロジェクトとなりがちな本類型のシステム開発プロジェクトでは、ITベンダーの選定において、ソリューションの革新性や初期開発のコストを選定基準としてしまうことが多い。しかしリスクテイクのために必要なのは、「同様の規模のシステム導入が可能なケイパビリティ」や「システム保守経験」となる。今後の新規事業の根幹となるシステムを開発するという意識が必要となる。

上記に挙げたようなリスクを、一企業が抱えていくのは非常に困難である。IT部門に今求められるのは、自社の抱えるべきリスクと、抱えきれないリスクを分析し、リスク管理の観点でITベンダーを選定することなのである。

【図】システム類型別・ITベンダー選定のポイント

出所)野村総合研究所

終章

これまで、システム開発プロジェクトの類型、各類型にIT部門の関わり方をそれぞれまとめてきた。最後に、IT 部門はシステム開発プロジェクトを目利きし、適切なリスクテイクを行うために理解するべきことを2点にまとめ、結びとしたい。

  1. 自社がどのように付加価値を生んでいるのか、利益の源泉を理解する
  2. 1.を踏まえて自社が背負うべきリスクとITベンダーとともに背負うべきリスクを見極める

上記を意識することで、さまざまなシステム開発プロジェクトにおける適切なマネジメント、開発手法、ベンダー選定の基準が見えてくる。システム開発プロジェクトにおいて必要なのは不確定な未来予測であり、すなわち将来発生する「ユーザー要望」「開発リスク」を想定することが重要である。現状の生成AIが得意とする過去事例からの連想ではなく、将来リスクの見極めこそ、IT部門に求められるエッセンスに他ならない。ますます技術の進化の速度が速まる現代において、本稿が悩めるIT部門の一助となれば幸いである。そして、読者様の行動の結果、ChatGPTのIT部門長の悩みの回答にも変化を与えるだろう。“悩んでいる暇はない。非連続な技術革新の中での未来予測が私たちの仕事なのだから”

執筆者情報

田中 佑高
2006年野村総合研究所に入社。
大手アパレルのシステム運用、新規システム開発を担当。その後は商社をお客様とした穀物・エネルギー・車載部品に関するビジネスの新規システム設計・開発、プロジェクト管理に従事。専門はプロジェクトマネージャ、システムアーキテクト。

DX時代のシステム導入最前線一覧ページへ

  • Facebook
  • Twitter
  • LinkedIn