DX時代の情報システム部門のあり方、そして役割とは 第03回 情報システム部門がDX施策を牽引するようになる日

株式会社レッドジャーニー 代表 政府CIO補佐官 DevLOVE オーガナイザー
市谷 聡啓 氏

DX推進の蚊帳の外にある情報システム部門

2019年のデータですが、独立行政法人情報処理推進機構(IPA)が発信している「デジタル・トランスフォーメーション推進人材の機能と役割のあり方に関する調査」において、以下のような結果があります。

出典:IPA デジタル・トランスフォーメーション推進人材の機能と役割のあり方に関する調査/p15
https://www.ipa.go.jp/files/000073700.pdf

DX推進のための組織体制を構築するにあたって、4割の企業が専門組織を立ち上げていることが分かります。同レポートからは推進レベルも「DX専門組織+情シス部門関与」が最も高く、DX推進にあたっては専門組織の設置が一つの手がかりになると言えそうです。

一方、推進レベルが最も低かったのは「DX担当組織無し」であり、これは妥当と言えますが、それに次ぐのが「情シス部門のみ」のケースなのです。上の図に戻ると、DX推進の体制を「情シス部門のみ」と置いているのは実に1割程度であり、これは「DX専門組織+情シス部門関与無し」よりも低い値です。つまり、DX推進を情シス部門のみで進めること自体が少なく、なおかつその結果も低調にあるということです。

実際に、DX支援として企業に関与してみると、情シス部門が蚊帳の外にあるというケースがあります。関与があるとしても、必要なときにのみ限定するような状況です。プロダクトをリリースする際の各種規程やポリシーのチェック、セキュリティテスト、もしくはリリース後の運用の取り決めなど。DX推進に関する企画や開発の段階では実に関与が薄い状況です。DX専門組織側からは、できるだけ情シス部門と接点を持たないようにしている空気が感じられます。なぜ、このような状況になってしまっているのでしょうか。

それは、情シス部門が基本的に「守り」の役割だからです。規程やポリシーに照らし合わせて判断可否を問うまでもなく、できることなら今まで取り組んだことがない施策は無しにしておきたい。企業のITシステムを間違いなく稼働させ続けることをミッションとする情シス部門のスタンスとしては、何も間違ったものではありません。しかし、DXとはその取り組みの多くがこれまで組織が取り組めてこなかった業務の改革であり、事業の創出であり、そのためのプロダクト開発であったりするわけです。組織として「攻め」の活動に振り切るDXと「守り」を基本とする情シス部門とでは、立ち位置上相容れることができません。自ずと、情シス部門がDX推進から外に置かれてしまうわけです。

ところが、実際には「攻め」の施策を進めていく際にも、自組織のITを唯一司る情シス部門が果たす役割は大きくなります。企画段階ではなく、施策が運用に乗った後からの局面においてです。

• プロダクトのローンチ後、徐々に自組織のITシステムとの連携が増えて行くことになる。
• 当初はMVP（Minimum Viable Product）として提供を始めたサービスだったが、運用に乗り始めるとサービス品質が問われるようになる。
• 企画と開発段階では外部の開発会社と良好だった関係が、徐々に手が行き届かなくなり、やがて期待が合わなくなってしまう。

情シス部門からすればだいぶ案件が進んでしまってからの参画となるため、情報収集に苦労しながら状況を掴んでいく必要があります。DX専門組織側からしても、後で関係することが多くなって、その分そもそもの情報共有で時間を費やすくらいなら、企画の最初の段階から情シス部門を巻き込んだ方が良いのではないかという考えに辿りつくわけです。企画段階から情シス部門が参画し役割を果たしていくためには、施策の実行に必要で何らかの貢献につながる専門性を有していることが望ましいと言えます。

しかし、DX施策に必要とされる技術は多岐に渡ります。どのような専門性を情シス部門として備えていくべきなのでしょうか。私は、あらためて「アジャイル」であると考えています。

DX施策の運営にスクラムを適用する

どのような施策であれ、その遂行にあたってはチームとステークホルダーが協働できる「運営」が求められます。この運営が特に考えられていなかったり、雑なものだとすると、取り組み自体の結果がおぼつかなくなります。ですから、チームの運営自体を機能させるフレームが必要となるのです。DX推進においては数多くのプロジェクトやテーマが並走することになり、その分チームやステークホルダーの数も多くなります。そうした混沌とした状況の中で、運営を支えるのがアジャイル、特に「スクラム」なのです。

スクラムを開発プロジェクトではもちろんのこと、企画段階の仮説検証や実験プロジェクトでもチームの運営フレームとして適用していきます。こうした運営については、施策自体の華やかさに比べるとあまり重視されない場合があります。多少の運営上の混乱があったとしても、新規性の高い取り組みを行っているためあえて留意しないということもあります。

しかし、実際にはこうした足元の取り組みが機能しなければ、全く結果につながっていきません。筆者も「炎上プロジェクト」という言葉は2000年代に置いてきたつもりですが、DXの取り組みに関与してみると炎上状態が散見されることがあります。運営を甘く見た結果です。

多くの場合、やるべきことの見える化から始めて、チーム活動が成り立つようスクラムイベントを始めるところが取っ掛かりです。スクラムは何よりも経験主義に基づいた学習のためのフレームです。取り組みを行い、その結果から学びを得て、次の取り組みへと活かすことをそもそもの狙いとしています。新規性の高いプロジェクトでも非常に相性が良いと言えます。

進まないアジャイルなケイパビリティ獲得

スクラムでプロジェクトを運営するにあたっては、情シス部門はスクラムマスターを務めるのが適しています。スクラムマスターとは、スクラムの運営が機能するよう各種働きかけを行う、サーヴァント・リーダーシップを体現する役割です。

スクラムでいうプロダクトオーナーをDX専門組織側が務めて、開発チームを社外のベンダーが担う。そうしたフォーメーションの中で情シス部門はスクラムマスターとして、社内と社外の間で発生しがちな情報量の差を適切に整えたり、エンジニアリングの専門外であるDX専門組織の担当者が状況を理解できるように情報の中身を翻訳したりと、コミュニケーション上の課題を解消するように務めていきます。

ところが、実情としては情シス部門がスクラムの運営をリードするという状況が増えているとは言い難いはずです。情シス部門がスクラムで実践的な役割を果たすためには、相応のケイパビリティを獲得するところから始める必要があります。スクラムの取り組みについての支援（研修やコンサルティング、コーチング）も増えてきていますが、こうした支援を上手く活用できない課題が情シス部門側にあります。それは既存業務に追われていて、あらかじめ決めいていた計画以外の活動に時間を割くことができないという状況のことです。こうした閉塞状況の下で、どのようにして情シス部門がDX推進のためのスクラムを習得していくのか、次回のテーマとしたいと思います。

• 第04回 情シス部門が組織のアジャイルを担う