2020年1月15日（水）に弊社主催のセミナー「DXを成功に導くための３つのキーファクターとは」を開催いたしました。
今回のセミナーでは、DXに取り組む企業が直面しやすい課題を解決し、プロジェクトを成功させるためのキーファクター「体制・プロセス・技術」について解説いたしました。
以前のセミナーでは、DXにこれから取り組むための情報収集をしている方が多くいらっしゃいましたが、今回は「DXに取り組んだことがある」、または「現在プロジェクト進行中だ」という方が多く、より具体的に課題解決のヒントを求めている方が多いと感じました。
セミナーレポートをまとめましたので、みなさまのお役に立てれば幸いです。
1.DXが難しいのはなぜか
既存業務のDXや、デジタルを活用した新規サービスの開発はなぜ難しいのか。
それは前例のないことにチャレンジし実現していくため、誰にも予測できないところに難しさがあります。
例えば、「見積もりが大きくなってしまい開発に着手できない」「やったことがない業務の要件が決められない」「技術を最大限活用できていないのでは」といった悩みをよく耳にすることがあります。こういった課題はプロジェクトが進行する中で表面化してくるので、最初から完璧に予測して始めることができません。
このような理由から、要件が流動的になりやすいDXや新規サービスの開発においては、柔軟で俊敏性の高い開発体制や手法を採用することが望ましいです。
2.３つのキーファクターについて
・体制（チーム）
体制（チーム）については、プロダクトオーナー（PO）を中心とした、小さなチームが望ましいです。
プロダクトオーナーとは、サービスやプロダクトの目的や方向の舵取りをする役割のことです。
主な業務としては、サービスやプロダクトの目的を定義する、機能の優先度を決定する、プロダクトの要件を正確に開発者へ伝える、プロトタイプを検証してサービスの方向転換をするかどうか検討する、成果物のレビューをする、などが挙げられます。
従来のソフトウェア開発では、事業部門とIT部門、発注者と受託者といったように、ビジネスサイドと開発サイドが分離されることが多くあります。プロダクトの要件がしっかり決められる場合は、費用や期間の計画が立てられるため、従来の体制でも問題はありません。
一方、DXを実行する場合は冒頭でもお話したように試行錯誤が必要なので、検証と改善を細かく繰り返す必要があります。そのためチームメンバーの構成はビジネスサイドと開発サイドが一体となり、意思決定がスムーズに行える小さなチームがベストです。
メンバーが社内の人材だけで補えない場合は社外から受け入れることも可能ですが、DXを推進する企業の社員がプロダクトオーナーとして意思決定をしていくことが重要です。
ここでシステム面の話にも触れてみたいと思います。小さなチームで素早く開発と検証を行うには、マイクロサービスを活用したアーキテクチャが適しています。
マイクロサービスとは、簡単にいうと、システムに必要な機能をできるだけ細かく分割し、それぞれ独立して動く小さなサービスの組み合わせで大きなシステムを構成するというものです。
小さなサービス単位で開発に取り組めるため、小さなチームでの開発に適しています。
マイクロサービスについてはこちらのコラムで詳しく解説していますので、ご参照ください。
・プロセス
今回のセミナーでは、DXのアイデアはすでにあるという前提で、実行フェーズにフォーカスを当ててプロセスについて解説いたしました。
DXのアイディア出しについては、「ゼロベースからどうやって新サービスを考えるか？」 こちらのコラムが参考になると思います。
DXや新規サービスのプロセスには「Lean Startup」の考え方が有効です。
Lean Startupはスタートアップ企業が成功するための方法論としてまとめられた考え方ですが、大企業の新規サービス立案にも活用できます。
成功までの道筋を「課題/解決フィット」「製品/市場フィット」「拡大」の３つのステージに分け、第１ステージでは顧客が必要としているかどうか、課題は解決できるのかを検証し、第２ステージは製品にどれくらい顧客がいるのかを検証し、第３ステージで成長と拡大をしていきます。
始めの２つのステージでは測定と検証を繰り返します。
ユーザーの反応を測定するために、検証が可能な最低限の機能を備えたプロダクト＝MVP（Minimum Viable Product）の開発を行い、測定結果を元に改善案を考えながら、ピボットと呼ばれるプロダクトの概念や目的の転換をします。ピボットとはバスケットボールの選手が軸足を残して方向転換を行うようなイメージで、プロダクトの軸は残しつつ、より良いサービスの可能性を探ることです。
よくある課題の例として、「開発の見積もりが大きくなりすぎて、プロジェクトがスタートできない」というのを挙げましたが、MVPが大きくなりすぎないようにプロダクトオーナーがマネジメントすることで、まずは自分たちのプロダクトが本当に価値があるのかを検証するための取り組みをスタートすることが重要だと考えます。
また、プロセスについては近年、アジャイルというキーワードをよく耳にします。
従来のシステム開発手法のウォーターフォールとは反対に、アジャイルは柔軟な無駄のない開発ができるメリットがありますが、柔軟な故に期間や費用が流動的になりやすいデメリットもあります。
NCDCでは作りたいサービスやシステムの性質によって、アジャイルなのか、ウォーターフォールなのか、またはそれらを組み合わせたプロセスなのかを選択することをお勧めしています。
開発プロセスの検討事例については、お客様向けに「デザイン思考、アジャイル開発、DevOpsについて」というテーマで勉強会を開催 した時のレポートが参考になると思います。ご興味のある方はぜひご一読ください。
・技術
技術面で新規サービスに適しているのは、クラウドネイティブな構成です。
クラウドネイティブには明確な定義がなく、ベンダーによって異なる部分がありますが、NCDCでは、AWSなどのクラウドベンダーが提供しているマネージドサービスやサーバレスなどの技術を積極的に利用し、クラウドに最適化されたアプリケーションの設計・開発を行うことだと考えています。
クラウドネイティブにするメリットは、インフラの調達や管理をクラウドベンダーに任せることができるため、迅速に開発をスタートできる点が挙げられます。また、利用者の増減に応じてオートスケールができる基盤やアプリケーションの設計にすることで、保守運用の負担を減らすこともできます。
このように任せられる部分はクラウドベンダーに任せることで、少ない人数でも開発や検証に集中し新規サービスの質を高めることに時間をかけられます。
3.まとめ
DXや新規サービスを実現する３つのキーファクターをまとめると、
・体制（チーム）：プロダクトオーナーを中心とし、ビジネスサイドと開発サイドが一体となった小さなチームを作ること。
・プロセス：LeanなプロセスでMVPと計測を繰り返しながらプロダクトを開発し、ピボットの見極めをすること。
・技術：クラウドを最大限活用し、アジリティやスケーラビリティを考慮したアーキテクチャを設計すること。
前例のないことを実現するためには、作りたいサービスによって最適な手法を取捨選択し、必要に応じて検証と改善を繰り返すことが大切です。
NCDCでは サービス企画、UX/CXのコンサルティング、PoCやシステム開発 を一貫して承ることで、DX実現の流れをサポートしています。
DXの推進にお困りの方や、現在課題を抱えている方はぜひ一度ご相談ください。
