ビジネスとITのハブとなるIT部門がやるべき4つのステップ 後編 ～あるべき姿～
前回の記事では、企業におけるIT部門の現状を「業務内容」と「期待されていること」の観点でまとめさせていただきました。
本稿では、IT部門が将来のための時間を割くことにも苦労している構造的な課題を挙げ、業務を標準化・効率化しつつ時間を創出し、「あるべき姿」にシフトするために行うべき4つのステップについてご紹介します。
目次
前稿の記事の通り、非常に高い期待を背負わされているIT部門ですが、事業部門のユーザーや顧客が日々利用している既存システムを安定的に運用保守するという「守りの領域」への対応は必須となるため、新たな「攻めの領域」にまでなかなか手を回せていないというのが現実です。ここには以下のような課題があります。
企業がIT人材に対する期待として今後重要視している領域としては、IT戦略、IT企画といった戦略・企画工程、また業務プロセス設計といった上流工程があり、そこで社内ITならではの業務を担って欲しいと期待されています。社内システムの導入、保守・運用についても担う事が期待されているものの、平均して20%強といった数字であくまで業務の一部という位置づけで考えられています。
出典：独立行政法人情報処理推進機構 社会基盤センター、IT人材白書2020、P154 図表3-2-29
このように、新たなIT企画を担って欲しいという期待は大きいものの、実態としては企業におけるIT人材に対する不足感は非常に大きなものとなっています。
若干データが古いものの、IT人材白書2020によると、年々不足感は拡大しており90%近い企業でIT人材の不足を感じているといった結果となっています。
出典：独立行政法人情報処理推進機構 社会基盤センター.IT人材白書2020,P154 図表3-2-17
この結果には、DXなどの流れの中でIT領域の業務量が増加しているという総量的な側面もあり、社内IT人材による対応領域の優先度・注力ポイントを明確にした対応が求められます。
先の話の通り、攻めのIT投資に向けた企画といった領域への対応がより期待されている一方で、実際のIT部門の業務においては、既存システムの保守・運用、サポート対応といった点に多くの労力が割かれています。
既存のシステムでは利用者が日々の業務を行っているため、円滑な運用を実現するための業務、トラブル対応などが日々発生し、将来に向けた業務に時間を割けていない現場が多くあります。また、新たにシステム化される領域が拡がるほど、運用保守対象のシステムの数が増えて行く事となるため、そのままにしておくと業務が増加することはあっても減ることはないという事態に陥ります。
このように、攻めの投資に向けて期待される役割に対して、現場のIT人材は守りの運用保守業務に非常に工数が割かれており、企業としてはIT人材の不足感を感じています。
同じような話は、予算の面からも明確になっています。ランザビジネス予算を「現行ビジネスの維持・運営」、バリューアップ予算を「ビジネスの新しい施策展開」と定義し調査したキャッシュベースの IT 予算配分の調査結果によると、平均して75%超の予算は現行ビジネスの維持・運営向けのIT予算として利用されており、既存ITの運用保守(既存システムの更改含む)といった守りの領域に費やされている事が分かります。
一方で、将来的な比率についてはビジネスの新しい施策展開向けといった「攻めの領域」への予算配分を増やしたいといった結果となっており、守りから攻めへのシフトが課題となっています。
出典：一般社団法人 日本情報システム・ユーザー協会、企業IT動向調査報告書 2 023、P37 図表2-1-17
ゼロベースのスタートが許されるなら、まず「あるべき姿」を定め、ギャップを特定し、それらの解決に向けたロードマップを描いて進めていくことが、あらゆる業務改善の定石です。
しかし、そのロードマップ作りを検討する時間さえ、割くことができないというのがIT部門の実情であることが見えてきました。
そこで今回は下図のようなステップを踏み、徐々に運用保守業務を標準化・効率化しながら、可能な範囲で若手社員やアウトソーサーへ仕事を移管することで、社員の時間を創出する所から始めます。できるだけ早く、高スキルな社員を実務から引き離し、改善サイクルの管理・推進と、事業部門のDX支援にシフトさせていくことが狙いです。
また、本アプローチは「IT部門でDXを実践すること」に他なりません。この経験を通してIT部門の人材が事業部門のDX推進のコーディネーターとなることで、新たな付加価値を生み出すことを意図しています。
一般的に国内企業では年間IT予算の約70%は運用保守費、その内の約半分は社員の人件費及びベンダーへの委託費用だと言われます。
この中身がブラックボックス化し、作業内容やかかる工数が妥当なのか誰も評価できなくなっているという実情はないでしょうか。
直接業務と間接業務(管理業務)、定型業務と非定型業務、社員がやるべき業務とアウトソースすべき業務などの区別が曖昧なまま、現状踏襲で引き継がれてきた可能性があります。まずはそれらを明確に仕分けするために、業務の棚卸を行います。
問い合わせ管理、イベント管理、インシデント管理、問題管理、変更・リリース管理などの業務は初期の段階では業務領域やシステムごとに存在し、そのプロセスも担当者も利用ツールもバラバラです。
現状把握段階ではこれらを[業務の分類] X [バリエーション]別にリストアップし、それぞれについて担当者、業務量、利用ツール、業務フローや手順書の有無などを表形式で可視化します。本表は次のStepで標準化やアウトソーシングの範囲を検討する土台となり、自社の「サービスカタログ」として継続的に管理する台帳となります。
サービスカタログの現状版ができたら、バラバラで属人性の高い状態であったそれぞれのプロセスを標準化できないかを検討します。サービスカタログにおいて[バリエーション]が複数あるようなサービスについて、代表的な[バリエーション]を例にとって業務フローを描き、各プロセスステップにおける役割分担、利用ツール、業務ルール、成果物フォームなどを洗い出します。この4点が業務標準化における着眼点となります。
役割・ツール・ルール・成果物を共通化できるなら、プロセスは同じで良いはずだ、と考えます。多少乱暴でも仮の標準プロセスを描いてみて、この通りにやってみてもらえないかと各担当に相談し、微調整していくのが良いでしょう。
業務フローと手順書を揃え、一定期間その設計通りに仕事が進むことが検証できたら、当該「サービス」の定型化・標準化が完了したことになります。このサービスの単位でアウトソースができないかを検討します。縦割り化した組織構造では、組織ごとにシステムが構築され、システムごとにその運用保守を委託されたベンダーが存在します。
ベンダーは運用保守の委託費で売上を得ているため、自らこの売上を手放すような提案はしにくいという事情があります。
従って、ベンダー任せでは業務の改善や標準化は進むはずもないと言うことができます。運用保守業務の標準化や全体最適化を抜本的に進めるには、並行してベンダーマネジメントを強化し、委託した業務のアウトプット(対応件数や成果物の量)、品質、それに要した工数などを定量的に評価し、サービスに対する適正な対価を合意できるようにすることが重要です。
運用保守業務において継続的に活用・分析すべきデータは、まずは前述のサービスカタログごとのアウトプットと工数が挙げられます。インシデント管理を例に取れば、インシデント件数とその対応時間です。インシデントといってもその内容は大小さまざまで、かかる工数も異なりますので、そのインシデント内容のカテゴリ分け、発生源、重要度、緊急度などの属性情報も重要なデータです。
Step3ではこれらのデータを各サービスごとに何の目的で、どのように取得・蓄積していくかを設計します。Step1〜2の段階ではデータの記録はExcel管理でも構いませんが、Step3では一元管理するためのツール導入(または既存ツールへの標準化)を検討します。
逆に、Step1〜2を経ずにツール導入ありきで進めると、バラバラで属人化したままのプロセスにツールを埋め込むこととなり、設計が難航する上、本来の目的である学習サイクルを回す所には遠く及ばない結果になるので注意が必要です。
サービスごとの生産性(アウトプット/工数)を定量評価できるようになれば、そのサービスを担う組織の価値も明確になります。継続的な改善により、効率化・生産性向上をさらに進めてくれるベンダーは高く評価され、新規投資案件のパートナーとしても採用されやすくなる、逆にそうではないベンダーは淘汰される、という仕掛けを早期に確立することで、運用保守業務をアウトソースしても、そのアウトソーサー自身によって継続的な改善サイクルが回るようになります。
Step 3により、データを一元管理できる仕組みが構築されると、日々データが蓄積されることになりますが、単に溜めておくだけでは宝の持ち腐れになってしまいます。
定期的に内容を確認し、実績値を根拠として、さらなる効率化・改善に繋げていくことが重要です。使用するツールによっては、集計値を数値やグラフでダッシュボードとして確認できるものもありますので、こちらも活用しましょう。
先ほどと同じくインシデント管理を例として、蓄積されたデータの活用方法を考えてみましょう。Step3で、目的に応じてデータをどう蓄積していくか、ということが設計できていれば、インシデントの起票の際に、カテゴリや発生源など、属性情報を付加して蓄積することを検討しているかと思います。その属性別に、インシデントの発生件数や平均対応時間を確認してみましょう。特定のカテゴリに偏ってインシデントが多く発生しているということはないでしょうか？ その場合は当該領域を重点的に対応できるように人員配置を見直す必要があるかもしれません。
また、特定のカテゴリに限って平均対応時間が多い場合、対応難易度が高い内容が発生している可能性があり、FAQを作るなどノウハウの共有が必要になる場合もあるでしょう。
さらに、カテゴリ分けが実態と合わなくなってくると、現状のカテゴリのどれにも当てはまらない「その他」に分類されるインシデントが多くなるという事象が発生します。
「その他」に分類されているインシデントの内容は定期的に見直しを行い、「その他」の中でも多く発生しているものがあれば、カテゴリの選択肢に増やしていくことをお勧めします。カテゴリ以外のデータ項目についても、日々発生するデータの全体的な傾向を踏まえて、現状の内容で充足しているか?の確認を定期的に行い、都度更新していくことが望ましいです。
月間のインシデントのクローズ件数や、平均対応時間などを部門のKPIに設定しているところもあるかと思います。
こういった値は、現在の値や日々の推移について、グラフやダッシュボードでいつでも確認できるようにしておくと良いでしょう。
さらに、状況が芳しくない兆候が見えた場合に、どこに時間がかかっているのかを深堀りして調べられるような仕組みになっていると、対策を検討しやすくなります。
以上、IT部門において、業務を標準化・効率化しつつ時間を創出するために行うべき4つのステップについてご紹介しました。
後編の記事では、4つのステップを経て時間を創出できるようになった後に、その創出した時間を使って取り組むべき内容を提言します。
企業におけるIT 部門の現状と構造的な課題を示し、「あるべき姿」にシフトするためのステップバイステップのアプローチを提言します。
困難な道のりであるからこそ、その工程を分解してシンプルに捉え、一歩一歩着実に進んでゆくためのガイドとしていただければ幸いです。
執筆者情報：
ユニリタ DXアクセラレーションチーム
株式会社ユニリタ DXイノベーション部
DXアクセラレーショングループ
ユニリタグループのプロモーション担当チームです。
企業の経営課題である「働き方改革」と「DXの推進」の実現に向けたアプローチを「4つのステージ」として整理しました。 企業内事業部門のDXを加速させるために、日々セミナー講師や執筆を行い、情報発信をおこなっています。
Rankingランキング
New arrival新着
Keywordキーワード
