カスタマーコンサルティングチームの矢戸 政法です。
先日、職域接種で1回目のコロナワクチンを接種してきました。予約の際に自治体から配布された接種券の番号の登録を要求され、自治体での接種のみならず職域接種でも大規模接種センターでも同様に自治体から配布された接種券番号を要求されているようなので、この番号をキーに管理するんだろうな〜と想像していたところ、「ワクチン接種記録システム(VRS)」というのが内閣官房情報通信技術(IT)総合戦略室により提供され、このシステムで接種者を一元管理するようですね。
2021年9月には「デジタル庁」も発足するようですし、日本においてもようやくデジタル化に向けた改革がいよいよ本格的に進んでいくのではないかと個人的には期待しております。行政のデジタル化も進んでおりますが、多くの民間企業においてもDXの重要性は認識されており私も日々の業務の中でお客様企業のデータ活用推進のための取り組みに協力させていただいております。
巷では企業のDXが進まないのは「上層部がITに対する理解が低いことが理由だ」というようなことを言われていたりするようですが、私個人としては上層部の方々も十分にDXの重要性をご理解していると感じています。今回はこのようなギャップが何故生まれているのかについて少し考えてみたいと思います。
架空のプロジェクトを題材に考えてみる
以下のストーリーはあくまでもフィクションですのでご理解ください。私が考えた架空のプロジェクトのお話です。ある企業で基幹システムをクラウド上に新規にシステムを構築しリプレイスするプロジェクトが進んでいたと仮定しましょう。基幹システムのリプレイスなのでかなり大規模なプロジェクトです。
基幹システムは複数の子システム同士が連動しており、このうちシステムAとシステムBのセキュリティ要件に差異がありどちらかに合わせる必要があることが判明しました。システムAに合わせる場合は開発仕様の変更が発生し、改修には時間とコストがかかってしまいますが会社で定めるセキュリティガイドラインの変更は不要です。
一方システムBに合わせると自社のこれまでのセキュリティガイドラインに反する部分があるためセキュリティガイドラインの変更を余儀なくされます。また、業務フローの変更も発生してしまいます。システム要件の変更はありますが改修によるコスト、工期へのインパクトは極小です。まとめると以下のようなイメージです。
内容 | クオリティ | コスト | 開発期間 | |
A案 | システムAに合わせる | ◎:現状のセキュリティを担保できる | ✕:追加コストが必要 | ✕:開発期間は延伸 |
B案 | システムBに合わせる | ✕:セキュリティガイドラインの見直しが必要 | ◎:追加コスト必要なし | ◎:開発機関の延伸なし |
プロジェクトマネージャーであるX氏の考えは、セキュリティは会社として絶対に守らなければならないものであり、コストをかけてでも安全性を担保することが重要である。また、B案にした場合は業務の見直しも発生してしまうため、社内の反発も大きいだろうと考えA案で進めようとプロジェクトチームとして意見をまとめ、プロジェクトオーナーである取締役Y氏に説明し、追加コストと工期の見直しの了承を得ようと試みました。
プロジェクトマネージャーX氏の視点
X氏としてはその役割である「プロジェクトを前に進めクオリティの担保されたシステムを構築する」ことにあるので、その視点で判断を進めることになると思います。つまり上記のA案B案それぞれのPros/ConsをQCD(品質、コスト、期間)の観点で比較検討を行いました。最も重視すべきはクオリティ、つまり安全品質を担保することです。そして上層部に報告する際もこの検討結果を報告することになるのではないでしょうか。つまり現状で定められているセキュリティ基準をクリアするために、A案を採用したいと考えました。
しかしY氏に説明したところ、セキュリティ対策について質問され、技術的な詳細についての解説を交えて丁寧に説明したつもりですが、Y氏からは「B案にした場合の対策はないのか?結局どちらのメリットが大きいのか分からない。次回もっと分かるように説明せよ」と言われてしまいました。X氏は思いました「ウチの役員はITが分かっていない。結局コストかよ。セキュリティのほうが大事だって当たり前じゃん?分かってないよね〜」
役員/プロジェクトオーナーY氏の視点
Y氏は役員として会社のDX推進全体の責任をおっています。DX推進のために必要な情報や国内外の事例を学び、DXの推進のためには会社全体の変革が必要であると感じています。つまり、現状の業務フローやセキュリティ基準の見直しも場合によっては必要であり、柔軟に対処することがDX推進の鍵と考えていました。
そのためX氏の提案を聞いた時に現状のセキュリティ基準や業務フローの見直しによってもたらされるメリット/デメリットを知りたいと考えたのだが、説明はシステム的な安全対策という技術的な話に終始してしまい、判断したい「将来的に当社が取るべき道筋」を見いだせずにいたのです。「なぜXは目の前のことしか考えないんだ?会社の将来を担う人材として期待してプロジェクト責任者にしているのにどうして分かってくれないかね?」
説明を終えたX氏は「Y氏はシステムのことが分かってない。ITへの理解が足りない」と感じてしまったかもしれません。しかし、Y氏が知りたいのはシステムの詳細ではなく、このプロジェクトに限定せず、会社として取るべき方針はどちらかの判断材料です。コストのことばかり考えてA案に反対しているわけではないのです。お互いの目線や判断基準が異なるため、説明が噛み合わず、相互理解を得ることができなかったのです。
たしかにB案はシステムセキュリティガイドラインや業務運用の変更などが必要になるため、現場への負担が大きくなることでしょう。しかし、今後DXをすすめる上で他システムとの連携を考慮に入れると、どこかのタイミングでセキュリティガイドラインの見直しは必然のものになるかもしれません。セキュリティを担保するための代替策も必ず見つかるでしょう。実際、オンプレミスのシステムを念頭に置いたシステムセキュリティガイドラインはクラウドベースのシステムにおいては無意味な項目なども存在します。
また、業務フローの見直しは新たな目線で業務の効率化を検討できる良い機会になるかもしれません。新たな業務運用ツールを導入する際には必然的に業務フローの見直しも必要になってくるため、業務フローの見直しは業務の効率化とセットで検討すべきでしょう。X氏に欠けていた視点は「会社の将来を見据えた場合、近い将来他システムと連携する可能性も考慮すると、それぞれどのようなメリット/デメリットが考えられるか?」といった点だと考えます。Y氏もX氏にその点を伝えてあげるべきとは思いますが。
DXの現場で感じること
上記は架空の物語なので極端な例ではありますが、実際のプロジェクトにおいても現場のプロジェクトチームとプロジェクトオーナーの間での合意形成に苦労する場面も少なくありません。プロジェクトチームとしてはメリットを説明するために開発中のシステムの詳細の詳細まで説明することができるので、どんどん深い話になりがちですが、本当に合意すべきところはシステムの詳細とは限らず、システムの拡張性や将来性を含めた性能要件かもしれません。「求められていることは何か」を常に意識し、理解するように務めること、相手の立場で考えてみることが重要と個人的には思っております。
私が所属するコンサルティングチームにおいてもプロジェクトを進める過程でステアリング・コミッティやビジネスレビューの場などで上層部の方々を交えてお話させて頂く機会が多々あります。現場の方々の意見を伺いつつ、上層部の考えも考慮し最適な解をご提案させていただいております。もちろん、DXプロジェクトは一朝一夕で完結するものではないので長期に渡りお客様とご一緒させていただき、お役に立ちたいと考えております。