DXの進め方がわからない。
経済産業省のDXレポートにも概念的な情報は多く記載されていますが、具体的な進め方については書かれていません。ネット上でも見つけることができません。
この「結局、どう進めればいいの？」という疑問に100％応えている本がこちら、
企画立案からシステム開発まで 本当に使えるDXプロジェクトの教科書 著者：下田 幸祐、飯田 哲也 出版：日経BP
T文字通り「教科書」のように、順を追って細かく説明されています。
「DX おすすめ本」で検索すると、どのページでも紹介されている名著。今回は全体的なポイント、次回・次々回はフェーズごとのポイントについてご紹介していきます。
DXプロジェクトは「課題がない」【本の概要】
DXプロジェクトは、経営者もDX推進担当者も「何をやりたいかと言われても、よくわからない」という状態からスタートするパターンが多いそうです。
なぜなら、DXプロジェクトには「課題がない」からです。
これまで、システム開発と言えば「基幹系システム開発」が主でした。基幹系システムは既存業務の整理・改善のために行うもので、つまり「既存業務を改善するという課題」が明確に存在します。
ですが、DXプロジェクトの場合「デジタルで新規事業を作る」のとほぼ同じ。既存業務など存在しないため、課題がありません。ここが本書における一番重要なメッセージです。
明確な課題がない状態からなにをするかを考えるところからスタートするため、基幹システムにおけるシステム開発の従来の流れとは異なるプロジェクトの進め方が必要になってきます。
システム開発の流れもまた、変革する必要があるということです。
「構想」からはじまる
課題がそもそもある基幹系システムは、要件定義からはじまります。
一方、DXプロジェクトは、課題を考えるところからスタート。課題とは「誰のどんな課題を解決するのか」です。課題を考え、解決策を考えるフェーズが最初に入ってきます。このフェーズを「構想」と呼んでいます。
DXプロジェクトの場合、
構想⇒PoC⇒要件定義⇒設計・テスト
という順番でシステム開発が進みます。
構想とは、文字通りアイディア。DXプロジェクトはシステム開発というよりも、新規事業開発だと考える方が良いと思います。
要件定義とは、構想を元にシステム要件をより具体的に落とし込んでいくことです。構想フェーズで固めたシステム像を元に、システムのUI・管理画面・システムに付随する業務の内容などを決めていきます。
DXプロジェクトは新規開発と同じとお話しましたが、細かくは
①RPAやAIを使って業務を改善する「業務系DX」
②IoTやAIを使って新しいサービスを作る「新サービス系DX」
の2パターンがあり、①もDXの一つです。
上記①は一見、基幹システムの開発プロジェクトのように見えますが「RPAやAIを使って、社内業務におけるどの課題をどう解決するか」を”構想”するところからスタートするという点でDXプロジェクトです。ちなみに、この①のパターンがいわゆる「デジタル化」。
本書では、よりDXプロジェクトらしい②を軸に話を進めています。(次回・次々回で各フェーズの大きなポイントをご説明)
DXプロジェクト 注意すべきポイント
ここからは、DXプロジェクトにおいて注意すべき大きなポイントについてお話していきます。
DXはすべてアジャイルで、は違う
経済産業省 DXレポートにも、DXプロジェクトはアジャイル開発で推進することを推奨する記載があったりなど「DX＝アジャイル」という論調になっています。
アジャイル開発とは、反復的に開発を行い、少しずつ完成形に近づけていく開発スタイルのこと。DXは、60点ぐらいの状態でサービス・プロダクトをリリースし、市場の反応を見て高速で改善・ブラッシュアップしていくビジネススタイルを確立していくことでもあり、DXとアジャイル開発の親和性は高いように思えます。
ですが、アジャイル開発を成立させる条件が存在します。
1) システムの開発規模が大きくない
2) 高品質が求められるシステムでない
3) プロダクトオーナーがいて意思決定できる
4) スキルの高いエンジニアが確保されている
1) システムの開発規模が大きくない
エンジニアの人数が増えると、教える・理解させる、感情的ないさかいなどコミュニケーションコストが増大します。(アジャイルチームは10人以下がベストという話もあります)
2) 高品質が求められるシステムでない
作りこまずリリース・改善を高速で繰り返すことを前提としている開発手法であるため、品質保証テストを厳密にやるとなると向いていません。(不完全なモノをリリースするという考え方を選択できる日本企業は多くはありません)
3) プロダクトオーナーがいて意思決定ができる
素早く作ってリリースしていくスピード感をキープするには、経営判断を仰がずとも即座に判断できるリーダーが必要です。(トップダウン企業では実現が難しいです)
4) スキルの高いエンジニアが確保されている
スキルはもちろん、ビジネス理解もあるエンジニアでなければ素早く形にしていくことは難しくなります。(希少なエンジニアの中でも、このレベルのエンジニアはわずかです)
これらすべてを満たさなければ、スケジュールの大幅な遅延やプロジェクト中止など、重大なトラブルを招くリスクが発生します。
結局、すべてをアジャイル開発で対応するのではなく、ウォーターフォールの流れの中にアジャイルを混ぜ込むやり方が主流になります。
本書では、アジャイルを混ぜ込むべきは「構想」「要件定義」「設計・開発」。テストはウォーターフォールで行うというのが最適な形だと提唱しています。
ベンダー企業だけに発注するのは危険
ここまででお分かりいただけたと思いますが、DXプロジェクトはいわゆるシステム開発とは異なります。新規事業開発そのものです。
そのため「システム開発」と同じと考え、ベンダー企業だけに発注するのは危険です。
構想フェーズは、新規事業専門のコンサルティング会社や広告代理店などプランニングに強い企業が適しています。最近では、デザイン思考によるアイディア出し専門企業などもあります。ベンダー企業が適しているのは、IT・AI人材の確保。
このあたりを理解しておらず、付き合いのあるベンダー企業にDXプロジェクトを丸ごと任せてしまうというパターンも多いそうです。ベンダー企業も「出来ますよ」と軽請けしてしまう傾向があるようで、しっかりジャッジが必要です。
構想フェーズは準委任で
構想が進むにつれ企画はどんどん膨れ上がり、作業が増えていきます。そのため外部パートナーとの契約は、作業内容の増減に柔軟に対応できる準委任が適切です。
請負の場合、最初に決めた作業以外対応しません。作業量の変化に対応することはまずないといえます。
準委任契約とは、作業の指示命令権はパートナー企業が持つ契約です。そのため、顧客とパートナー企業は対等な立場で、パートナー企業から「知見・経験」を提供してもらう内容です。順を追って説明します。
ですが、準委任契約を名乗りながら、実情は顧客に指示命令権をゆだねている「偽装請負」が横行している側面もあります。そのため、準委任契約はマイナスなイメージで捉えられがちですが、対等であることを理解していれば有効な契約内容です。
「すべて内製に切り替えるべき」という論調もありますが、DXプロジェクトに必要な人材をすべて自社で抱えるというのは非現実的です。また、フェーズごとに必要な人員数が変わります。ことDXにおいて準委任契約の活用は必須といえます。
まとめ「システム開発という考え方を捨てる」
DXプロジェクトの進め方についてお話してきました。
●従来の基幹システム開発とDXプロジェクトの違いは「課題がない」こと。
●「課題を設定する」構想フェーズからはじまるDXプロジェクトは、従来と進め方がまったく異なる。
●DXプロジェクトをすべてアジャイル開発で賄うというのは非現実的。また、ベンダー企業だけで対応できるモノではない・準委任を活用すべきなど特徴的なポイントがある。
途中触れたお話ですが、おそらく日本企業の多くは「RPAやAIで業務改善を図る業務系DX」をDXと捉えている傾向があります。業務系DXはデジタル化であり、DXの一部です。本来のDXは新規事業開発のほうであり、新規事業を創ることで業務内容や必要な人がガラッと変わっていくことから、DXは改革だと言われているということです。
こういった違いが認識できないこともまたDXが進まない要因になっているのではないでしょうか。
次回・次々回は、各フェーズにおけるポイントについてお話していきます。
■参考：
企画立案からシステム開発まで 本当に使えるDXプロジェクトの教科書 著者：下田 幸祐、飯田 哲也 出版：日経BP
執筆者
リビルダーズ編集部
