【読書】『CIO/IT責任者が語る、DX時代を打ち勝つための30の提言』特定非営利活動法人CIO Lounge
業務に必要で、またビジネス書に戻ってきましたw（必要ならしゃーないということで）
所感
一足飛びにDXは難しい。まずは見える化、業務改革へ
「DX」とあるが、まだまだその実現はむずかしいものの、第一ステップの業務プロセスの見える化、そして第二ステップの業務改革で不要な業務を削減しながら、RPAなど自動化できるところは効率化するという動きは実現し始めているとのこと。
一方で、この延長線上にあるかもしれない「DX（BX by D）」にはまだ到達できてない。（もしかしたら非線形かもしれないですしね）
IT部門は開発からコンサルティングへ
やらされ仕事と自分たち自身も思ってしまっているIT部門の意識改革を行なう必要があり、ある企業ではこれまでの業務システムの開発を中心とした組織から、コンサルティングに力点を置いた組織へと変革させるチャレンジも行なっていた。
はたまた、評価基準を変えるなどしてでも、挑戦する文化の醸成したり、挑戦するメンバーを育成する必要がある。でも、その失敗の責任はリーダーが取ること。
IT部門は事業課題にそのまま取り組め
事業側から挙がる要請はタスクレベルが多く、それをそのまま100個解決しても、結局経営からは「IT部門は何やってるの？」から抜けられない。IT部門は中期経営計画の事業側の事業課題にそのまま取り組むことで、経営に直結した貢献が可能になる。
最後は意思。経営課題、事業課題に挑みつづける
「波風は立つかもしれないが、経営に認められ、企業にとって価値あるIT部門になるには、受け身では何も変わらない」という旨のことが書いてある部分には、強い意志が伝わってきます。
上記は組織変革に対するIT部門内部の反応に対するものであるが、経営サイド・事業サイド・IT部門と「三位一体」で取り組んでいる際も、事業変化に伴う意思決定は頻繁にあるとのこと。それに対して、先送りせずに課題に立ち向かう意思が求められていることも、理解しました。
こうした、チャレンジをされているのがCIO/IT責任者なのだ、と改めて最前線を知ることができました。
印象に残った箇所をいくつか
「地道に、企業全体で各部門のメンバーが業務プロセスを紐解き、レガシーシステムにより何がどのように回っているのかを読み解いていく必要がある」
たしかに。前職で基幹システムとRDBを駆使して業務を回していたのだが、その全貌を把握できている人は誰もいなかった。使っている人は部分的な理解。そのため、システム移行する際に、あるパートの一連の業務を棚卸して、再構築するのに結構ファシリテーションした（そして「この作業必要ですかね？」みたいな問いも結構してました。その回答は後続パートの部署の利用方法を知らないと判断できないため、ヒアリングしに行って、全然使わないとわかり、「不要でした〜」みたいな確認を何度もしていた）。
ちょっと理解できなかった箇所をいくつか
業務の標準化で海外に遅れをとった
海外の事例に疎いため、海外のどの企業がどういう業務において標準化できているのか、なども知りたかった。上記フレーズは結構聞いたことがあるが、具体例で知らなかったので。（他の文献に自分で当たれ、ということだと思うが）
メモ的にピックアップ（意訳あり）
DXは「BX by D（ビジネストランスフォーメーションbyデジタル）」（P49）
ユーザー部門、ITベンダー、IT部門による「三位一体」で信頼関係を強めて、セキュリティや情報管理などの課題にあたるべし（P65）
IT部門は「いわれたことをやるだけの部署」ではない。CIOは経営と現場をつなぐ架け橋となるべし（P84）
「BX by D」を実現するために、経営層、事業部門、IT部門の「三位一体」で企業活動を推進すべし（P84）
「IT関連業務は、従来の業務システムの開発・保守に加え、社内外の子湯ニケーションに関するシステム、セキュリティ対策、IT内部統制、海外関連会社を含めたガバナンスなど、担当領域が大きく増えていた。しかし、IT部員は増えず、むしろ減っていた（1990年代60人→20人。疲弊していた）」（P87）
「種々の業務システムに横串を刺し、全社最適の観点から業務を俯瞰できること」を強みとして、従来のシステム開発を中心とした組織からコンサルティングに力点を置いた組織へと変革させることにチャレンジした（P88）
「IT部門のスタッフには、業務システムの知見に加えコンサルティングのノウハウを備えた、いわば「多能工化」することを求め、IT中期計画として「業務プロセスの見える化」に取り組むことを打ち出した」（P89）
「業務コンサルティングユニット」から「RPA推進ユニット」へ。不要な業務はわざわざ時間をかけて効率化するのは無駄。業務そのものも改廃する（P90）
失敗を容認するカルチャーを醸成するために場合によっては評価基準も変える（P91）
最初に挑戦させる担当者個人に失敗の責任を負わせない。CIO自身が負う
企業の継続的な繁栄に不可欠な以下2点を支えるためにIT戦略がある（P102）
「ビジネスチャンスの拡大」=自社の強み、弱み、マーケットや顧客の現状やこれまでの推移などの分析する「データドリブン経営」
「収益構造の強靱化」=「業務自体の見直しを前提とした効率化・省力化」・コスト削減などの「最適化」
経営・事業側とIT部門との合意形成の重要性。ITのプロジェクトなんてない。経営に関わるプロジェクト（P166）
「強い信念がプロジェクト成功の鍵」ビジネスを巡る状況は絶えず流転する。システム部門長はさまざまな課題が押し寄せる中、問題を先送りせず、自身が「ど真ん中でやる」という強い思いが必要（P168）
セキュリティソリューション導入の契機（P178）
自社でインシデント発生
情報セキュリティ関連法令の施行・改正
親会社からの指示、自社の経営戦略に基づく対応、経営層からの指示
自社に関連する業界や組織でのインシデント発生
販売先や関係企業からの要請や取引条件
社会的責任の達成
セキュリティベンダーからの提案・売り込み
自社の脆弱性分析結果
同業他社の導入事例
特定のインシデントの発生
情報セキュリティ対策：文字よりイラストの方が訴求効果あり。専門用語を駆使した提案はかえって経営層や他部門と意思疎通を阻害し、稟議承認に手間取る可能性も。（P180）
一般企業では、情報セキュリティ対策はコストと見なす考え方が主流。トップランナーになることはなくとも業界平均程度には対応するのが落としどころ。とはいえ、インシデントが起きれば、ダメージの大きさ次第で再発防止策を打つ（P182）
事業側から挙がる要請はタスクレベルも多い。そのまま100個解決しても、経営からは「情シスは何やってる？」から抜けられない。情シスも中経の事業側の事業課題にそのまま取り組む
何を問題とするかのスコーピングは内製で行なう。開発は外注しても。
外注したとしても、各業務担当者のモジュール部分と外注システム（ex. S/4HANA）の間でどのようなデータが行き来しているかは自ら手を動かして理解を深める。それを積み重ねることで、全容を把握でき、混在する知識を整理し、単純なベンダーの伝言者にならず、現場からも信頼を得られる（信頼を得るのはダイジ。存在価値証明と次のプロジェクトも進みやすくなる）
この記事が気に入ったらサポートをしてみませんか？