DX推進の足かせとなるシステムのブラックボックス化・属人化を回避するには

デジタルトランスフォーメーション（DX）を推進する上での足かせとなるシステムの属人化やブラックボックス化。こちらのコラムでも記載したとおり、経済産業省が2018年に発表したDXレポートに詳しく書かれております。

なぜDXを推進しなければならないのでしょうか。そのヒントは経済産業省が2018年に発表したDXレポートにあります。このレポートでは、

・デジタル技術により業界の破壊的変化が進む。

・デジタル技術を活用した新サービス創出や柔軟な改変ができる体制に移行する必要がある。

ということを説いております。しかしながら国内の企業はシステムのブラックボックス化やIT人材不足、現場の反対といった要因で体制移行が困難であることを指摘しています。

引用元

既存システムのドキュメント不足が引き起こす課題

既存顧客を調査、分析することで導き出される最適な顧客体験。この最適な顧客体験をエンドユーザーに提供するためのさまざまなウェブサイトやアプリなどのインターフェースの改修、店頭オペレーションの変更、システムの改修などを計画するときに必ず課題に上がるのが、既存開発リソースの課題です。

この開発リソースの枯渇に対する対策としては通常4つの方法が考えられます。

• 既存の保守運用業務のアウトソース化
• 新規構築業務のアウトソース化
• 自社エンジニアのリソース強化
• 可用性のあるシステムの刷新

しかしながらこれらは既存システムの仕様が可視化された状態に限った対策です。現在、多くの企業では既存システムのドキュメンテーションを正しく行ってこなかったことによるシステムのブラックボックス化、現場のエンジニアの頭の中でしか仕様が管理されていない属人化という大きな問題を抱えております。これらの問題が原因でこういった対策が打てない状況があります。では、なぜシステムのブラックボックス化や属人化が原因となっているのでしょうか。一つずつ解説していきます。

・既存の保守運用業務のアウトソース化 既存の機能やその仕様が不明確なので、現行システムの改修や保守業務を引き継げない。

・新規構築業務のアウトソース化 既存システムとの連携が必要な場合に、インターフェースの機能やその仕様が不明確なので、既存システムと連携機能の実装ができない。

・自社エンジニアのリソース強化 新規リソースの調達をした場合、仕様理解に時間を要するためリソース投下の効果を最大化できない。

・可用性のあるシステムの刷新 時間・コストが必要であるとともに、既存の仕様がわからないので正しくシステムを復元できない。

上記のように、既存のシステムの仕様が可視化されていないことで、アウトソース化が難しかったり、対策の効果が最大化できなでしょう。

ブラックボックス化と属人化が引き起こすマイナスの経営インパクト

ブラックボックス化と属人化が引き起こすマイナスの経営インパクトについても解説します。

まずはブラックボックス化の大きな要因となるのは、「システムの複雑化」と「設計書の不足」です。 多くの企業では、既に複雑なシステム構成になっていることに加え、今後のDX推進でさらなる機能改修、機能追加が予想され、さらなる複雑なシステム構成になると考えられます。また、仕様把握に必要なドキュメントが不足していることから、機能改修、機能追加をする際の影響調査などが困難になるでしょう。これらが要因となりシステムのブラックボックス化を引き起こします。

一方で属人化の大きな要因となるのは、「ドキュメント管理体制の不在」と「IT人材不足」です。 機能改修、機能追加時のドキュメント更新ルールや推進する体制がない場合、既存のエンジニアに依存した体制になっていきます。また、経済産業省のDXレポートでも言及されているIT人材不足と保守運用すべきシステムが増えることで、自社リソースが不足し品質維持が難しくなるでしょう。これらが要因となりシステムの属人化を引き起こします。

このシステムのブラックボックス化と属人化が、システムの品質低下や保守コストの増大化、開発スピードの低下を招き、DX推進の大きな足かせとなり、結果マイナスの経営インパクトを与えることは確実と言えます。

「リバースエンジニアリング」と「プロジェクトマネジメントルールの策定」で打破しよう

システムのブラックボックス化の課題に対してはリバースエンジニアリングによるドキュメント整備が有効です。リバースエンジニアリングとは開発されたシステムをプログラムレベルで分解し分析することで、正しい動作や開発方法、設計プログラム構造、エラーハンドリングなどの仕様詳細を明らかにすることです。明らかになった仕様は以下のようなドキュメントにしていくことでシステムのブラックボックス化を回避します。

• 外部設計書
• 内部設計書
• 運用保守定義書
• 非機能要求仕様書

など

一方で、システムの属人化の課題に対してはプロジェクトマネジメントルールの策定を通して回避しましょう。

• コンフィギュレーション・マネジメント

設計書などシステムに関わる様々な資源に対して最新の状態を維持するためのコンフィギュレーション・マネジメント（構成管理）を行います。ドキュメントの変更の手順、変更追跡の仕組みや、レビューの方法などを明確にして作成したドキュメントが形骸化することを防止します。

• コミュニケーション・マネジメント と チーム・マネジメント

プロジェクトに関わるメンバーが多数になると、コミュニケーションのルールやチーム育成が欠かせません。チームが成熟することで様々な作業の精度が向上し、品質やコストなどの課題解決に繋がります。コミュニケーション・マネジメントとチームマネジメントでは下記のようなルールを定義します。 -進捗報告の書式や方法、会議体の定義 -チーム憲章（行動指針、意思決定、コンフリクトの解消方法） -RAM（責任分担表）

• 品質マネジメント

現状、起こっている品質コスト増大の課題は、品質マネジメントの向上により軽減できる可能性も考えられます。 例えばサイト開発において上流フェーズからテスト計画などの予防安全措置を実行することで、下流で発生する不具合を軽減することが可能です。品質マネジメントのセオリーでは「検査よりも予防」を重視します。一般的に不具合を予防するためのコストは、検査により発見された不具合を是正するコストに比べてはるかに少ないためです。

「顧客体験発想」で考えるDX推進アプローチ

ここまでは、DX推進の足かせとなるシステムのブラックボックス化・属人化を回避策について解説させていただきました。ここからは、ブラックボックス化、属人化の課題や回避策については理解したが、DX推進をしていく上で何からはじめればいいかわからない方に対して、DXの第一歩となるDX推進アプローチについてご説明します。

当社は業界破壊によるビジネスモデル変革の裏で新たな事業価値の創造、新たな顧客体験の提供が最重要になると考えております。まずはウェブサイトやアプリを作ろう、システムを改修しよう、店舗での顧客管理方法を変えようと、機能単位でのデジタル化を考えるのではなく、今まさに向き合わならない顧客に対してなにを提供しなければならないのか？をベースに考えることが、DX推進の成功のカギだと考えております。