【ついにプロマネを任された！】あなたのDXプロジェクトがしぐじる理由(エンジニア編)

▼この記事でわかること

　「こんなはずではなかったのに…」
　もともとITについての知識が豊富で、コーディングやエンジニアのリーダなどをこなしてきた社内IT部門担当者が、初めてDXプロジェクトマネージャー(プロマネ)に任命され、営業部と社内システムを作ろうと奮闘。でも営業部にはITの知識がなくまったく言語が伝わらない、ITを理解する気もあまりなく要件も出し切れず、結果、全く使えないシステムができあがって、なぜかプロマネが怒られる・・・。こんな悲しい状況を数多く見てきました。
　今回は、なぜ優秀なエンジニアであってもDXプロジェクトを成功させられないのか、過去のしくじりをもとにご紹介します。
　なお、説明をシンプルにするために以下語句定義をしておきます。

・DX側
　社内ITやIT会社に勤めてDXを進めるエンジニアなど。　
　ITの技術については詳しいが、利用者のニーズやビジネスモデルについては知らない。　
・事業側
　営業、人事など非IT領域の人たち。
　自身の業務領域について非常に知見があるが、IT/DXについては知らない。

▼DX側の課題

①デジタル化で解決される課題を正しく理解しているか

　例えば営業部から「AI OCR（文字の自動読み取り）で業務を効率化したいんだよね」、という相談があったとします。この時に、プロマネとしてあなたが真っ先に考えなければならないのは？

そう、「本当にその技術が課題解決になるの…？」という疑いの目を持つことです！

　例をあげますね！例えば社内で以下のような会話が想定されます。

営業：「AI OCRって文字読み取れる技術で業務効率化したいんですよ～」
プロマネ：「へ～。何に使いたいんですか？」
営業：「顧客からの発注書が手書きでシステムへの入力が手間なので、読み取れたらいいかなって」
プロマネ：「そうなんですね、この発注書って顧客指定なんですか？」
営業：「ううん、自社のフォーマットだよ」
プロマネ：「なるほど。じゃぁこの発注書をそもそもデジタル化してしまえば、顧客も手書きじゃなくてよくなるし、社内でもシステムへの入力がなくなりますね！」
営業：「・・・たしかに！」
（終）

　いかがでしょうか。笑い話かと思うかもしれませんが、こんな話が本当によくあるのです！

　つまり気を付けるべきは、事業側からこの技術で何かやりたいと技術指定で来た時には、現在解決したい根本課題は何で、それを解決するうえで最適な課題は本当はどれなんだ、という最初の深堀りをしっかりしましょうという点ですね。
　ありがちなのは、プロマネ側もついつい技術への好奇心につられて、「AI OCR案件やってみたいな～」という欲が出て技術先行で話をポンポン進めてしまうケースです。この場合には、システムが出来上がって初めて、「全然投資対効果でないじゃん！使えないじゃん！」という期待値ギャップが生じてしまうい皆が不幸になるので、ぜひ気を付けてください…！

②事業側の都合や業務を理解しようとしているか

　ITの教科書に書いてあるように、要件定義→基本設計→詳細設計→構築→テスト→リリース、ときれいにスケジュールが進んでくれればいいですよね。ただ、私の経験ではそんなことはまずないです！
　それはなぜか。

　事業側は、現在の業務をしながら、追加でシステム化のことを考えているから単純にリソースがないのです！

　DX側にとっては、プロジェクトを絶対成功させたくて、スケジュール通りにすべて進めたい。ただ、事業側は既存顧客を抱えていて、日々の報告業務もあれば、クレーム対応もあれば、決算期には事業計画策定など重要な社内プロセスも入っています。
　そんな中、要件を全部出してください、出来上がったシステムのテストしてください、と言ってもない袖は振れない・・・ということになります。結果、どんどんスケジュールが遅れていき、コストが膨らんでいく…。

　このような不幸を防ぎたいですよね！どうしたらいいか。

　スケジュールを作成する際に、事業側の都合をしっかり計画に組み込んでおきましょう！
　
　例えば、「繁忙期はいつですか？」「要件だしは大変だと思うのですが、少しAさんの稼働をこのプロジェクトに割いても現業は回りますか？」など、今の業務へのリスペクトを払って都合を確認したうえで始めからスケジュールを作っておけば、急に体制がガタガタになるというプロジェクトの危機は避けられますね！

③作って終わり、だと思っていないか

　①、②を乗り越えてうまく作れたシステムやプロダクトがあったとします。事業側もとても喜んでくれて、達成感いっぱい。皆ありがとう。ではこのプロジェクトも解散です。皆、元気でね！・・・といった１年後、今どうなっているかな？と顔を出すと、そのシステムは使われなくなっていました。
　…これはホラー話のようですが、残念ながらあるあるです。
なぜ、使われなくなってしまうのか。

保守・運用・改善フェーズをしっかり設計しておかなかったからです！

　システムやプロダクトは育児のようなもの。生み出して終わりではなく、風邪をひいたり理由なく泣いたりトラブルはつきものです。育児において、面倒を見てくれる人がいなかったら大変なことになりますよね。システムも同じです。
　当初想定した業務プロセスが変更になったり、担当者が変わって使い方のノウハウが組織に残っていなかったり、OSのアップデートなど技術的な要因によって対応しなければいけないことが出てきます。そのような時に、「前任者が作って今どこにも聞ける人がいないなぁ」という状況だと、皆使い勝手が悪いので、じゃぁまたエクセルやFAXなど、自分たちのわかる範囲でのITツールでいいか、ということになってしまったり、プロダクトを畳むことになりかねません。
　プロマネは、自分のプロジェクトの『今』だけではなく、将来自分や今のプロジェクトメンバーが全員いなくなっても回るか、という『未来』についても責任を持つことが必要です。
　せっかく取り組んだプロジェクトが一過性のイベントにならないよう、困ったときの問い合わせ先や分かりやすいマニュアル、毎年で対応しなければいけないセキュリティ対策のプロセス、などしっかりまとめておくことで、初めてプロジェクトが成功と言えるでしょう。

▼事業側の課題

　散々DX側のお話をしましたが、もちろんシステムやプロダクトを作る要件を出す事業側にも課題があります。
　こちらについては別の記事で触れていますので、ご確認ください。

▼結局どうすりゃいいのよ！

　結局DXプロジェクトを失敗させないためには、以下の3つを徹底することが重要です！

①手を動かす前に、現在の課題を正しく理解し、それに対する適切な技術を提案する！（内容によってはソリューションはデジタルでなく社内プロセス変更などの可能性も大）

②事業側に関心をもち、プロジェクトへの影響を正しく認識した上で計画を立てる！

③プロジェクト内で、『未来』の運用・保守・改善へ注意を向け持続可能なデジタル利用を実現する。

上記をまずやってみるのはいかがでしょうか。皆さんのDXプロジェクトの成功を強く強く願っています！

以上です。
この記事がもし少しでもためになっていれば、励みになりますので「いいね！」やフォローをお願いします！

Twitter(現、X)のフォローもお待ちしています！→https://twitter.com/nomusan_JP1