資料公開｜DXを成功に導く鍵。クラウドやアジャイルを活用した迅速なアイデア実現手法とは？

2021年11月9日にオンラインセミナー「DXを成功に導く鍵。クラウドやアジャイルを活用した迅速なアイデア実現手法とは？」を開催いたしました。
この記事では当日用いた資料を公開しています。

動画で見る

DXのタイプと進め方

NCDCではDXを以下の２つのタイプに分けています。

• 新規サービス系DX：デジタルを活用した新たなサービス・事業を作り、新たな収益源を創出する。
• 業務改革系DX：デジタルを活用した既存業務の効率化や、得られたビッグデータを活用する。

上記のいずれの場合であっても、DXにおけるシステム開発はその不確実性から従来型の進め方では困難が多く、苦労されている方も多いのではないかと思います。

DXでよくある課題

DX推進のためにサービスやプロダクトとして開発する時、以下のような課題にぶつかった経験をお持ちの方もいるのではないでしょうか。

これらの課題を解決するためのキーファクターは「チーム」「プロセス」「テクノロジー」の３つだとNCDCでは考えています。

DXを実現するチーム

DXを実現する「チーム」は「プロダクトオーナーを中心とした小さなチーム」であることが望ましいです。
ここでの「チーム」とは人事上の組織ではなく、サービス開発の体制を指しています。

プロダクトオーナーを中心とした小さなチーム

「プロダクトオーナーを中心とした小さなチーム」は、「ビジネス」と「開発」が一体であることが重要です。

これまでのソフトウェア開発では、「ビジネス」と「開発」が分離した体制がよく見られました。「ビジネス」側でプロダクトの要件がしっかり決められる場合は、要件を決めて、作る部分を「開発」にお願いするという分離した進め方で問題ありませんでした。

一方、DXにおける開発では「サービス・プロダクトの価値」を検証しながら進めるため、サービスの内容が頻繁に見直されます。その変化に対して素早く意思決定するためには「ビジネス」「開発」のメンバーが一体となっている必要があります。

プロダクトオーナーの役割

「小さなチーム」の中で最も重要な役割はプロダクトオーナー（PO）です。
POとはサービスやプロダクトの目的や方向の舵取りをする役割のことです。

POの主な業務は以下の通りです。

• サービスの価値を定義する
• サービスのコンセプトやビジョンを定義しメンバーに伝える
• 機能開発の優先順位を判断する
• サービスの方向転換を検討、判断する
• エンジニアに開発要件を伝える

ここでアーキテクチャ面の話にも触れておきます。「小さなチーム」で素早く開発・検証を進めるには、「マイクロサービス」が適しています。
「マイクロサービス」とは、複数の規模の小さなサービスを組み合わせてひとつの大きなアプリケーションを構成する、ソフトウェア開発の技法のひとつです。

「マイクロサービス」の対義語としては「モノリシック」という言葉があります。
モノリスは「一枚岩」という意味の英語で、ソフトウェアの世界では大きな岩の塊のように全体がひとつのモジュールになっている構造をモノリシックアーキテクチャと表現します。

モノリシックなシステムの場合、一部の小さな変更でも容易に着手できません。なぜなら、さまざまな機能やデータが複雑に絡み合っているため、変更の影響範囲を調査して進める必要があるからです。また、変更の影響が広範囲に及ぶと、各所への情報伝達や、変更への合意形成に時間と労力が必要です。

マイクロサービスの場合、他システムとの接点（APIなどのインターフェイス）に影響がなければ変更はサービス内で完結します。そのため、モノリシックなシステムと比べて迅速な機能改善が可能です。

DXを実現するプロセス

新規サービスやプロダクトによってDXに取り組む場合「リーンスタートアップ」の考え方が有効です。

リーンスタートアップ

「リーンスタートアップ」とはスタートアップが新規サービスを立ち上げる際のプラクティスを大企業も活用できるようにまとめたものです。
簡単に説明すると「コストをそれほどかけずに最低限の機能を持った製品やサービスを短期間で作り、顧客に提供する」そして「顧客の反応を観察して改善を繰り返す事で、成功モデルに素早く近づける」というアプローチのことです。

DXでは創出したアイデアに価値があるかMVP※で検証することが重要です。
検証の結果から、想定していた効果が得られないと判断した場合はピボット※も検討します。

※MVP（Minimum Viable Product）

実行可能な最低限の機能を持ったプロダクトのことです。
リーンスタートアップではMVPを利用したユーザーの反応から、サービスの価値を検証します。「最低限の機能」として開発する機能は検証内容によって変わります。

※ピボット

Pivotいう英語は「中心」や「旋回軸」という意味で、リーンスタートアップにおいては上記のMVPを用いた検証結果から改善案を考える際、プロダクトの目的や概要を従来のものから別のものへ転換することを指します。

ウォーターフォールかアジャイルか

開発のプロセスを考えるときにもう一つ重要なのが「ウォーターフォール」と「アジャイル」です。近年はアジャイルの認知が高まっているため、「ウォーターフォールは古い」と考えている方もいるのではないでしょうか。
しかし、一概に「ウォーターフォールは古いからダメ」と考えるのは早計です。

ウォーターフォールは、「要件定義→設計→開発→実装→テスト」と順番を決めて、一つずつ工程を進めていく開発手法です。
最初に定めた計画通りに開発するため、途中での計画変更が難しく、プロジェクトが開始されてからの変化に対して柔軟に対応しづらい開発プロセスといえます。

アジャイルは、「要件→設計→開発→実装→テスト」を短期間に繰り返して完成を目指す開発手法です。最初から全体の仕様を細かく決めてしまうことはなく、「変化すること」を前提として何度も「実装→テスト」を繰り返します。
柔軟性があり、変化に強い開発プロセスですが、開発範囲が流動的になり想定予算・スケジュールが想定を超えてしまうこともあります。

それぞれに向き不向きがあるので、二者択一と考えて「どちらかを選ぶ」のではなく、「目的に合わせて使い分けると良い」とNCDCは考えています。

DXを実現するテクノロジー

技術面でDXに適しているのはクラウドネイティブなアーキテクチャです。
具体的には「環境構築に可能な限りクラウドを活用すること」と「クラウド活用を前提としてアプリケーションを設計すること」です。

環境構築に可能な限りクラウドサービスを活用する

各種クラウドサービスを利用して、インフラの調達・保守を可能な限りクラウドベンダーに任せられる構成にすることが重要です。

現在、AWSやAzureなどのクラウドサービスを利用することは一般的になっています。
クラウドサービスを利用することで、データセンターやサーバーなどの調達・設定にかかる工数を大幅に削減できるようになりました。

クラウド活用を前提としてアプリケーションを設計する

アプリケーションを設計する際にも、コンテナ、サーバレスの技術、クラウドベンダーが提供している各種マネージドサービスを積極的に利用することで「俊敏性」と「拡張性」が得られます。

• 俊敏性：インフラだけではなくOSやアプリケーションを実行するためのミドルウェアもクラウドベンダーに任せていることで、サービス（付加価値）の提供に集中できます。
• 拡張性：DXで開発したサービスやプロダクトは、リリース後の利用状況を予測できません。クラウドサービスであれば、開発段階では小規模で利用し、利用者の増加に合わせて拡張可能です。

このように任せられる部分はクラウドベンダーに任せることで、少ない人数でも開発や検証に集中し新規サービスの質を高めることに時間をかけられます。

まとめ

DXを実現するために重要な３つのキーファクターは以下の通りです。

• チーム：プロダクトオーナーを中心としたビジネスと開発が一体となった小さなチームを作ること
• プロセス：リーンスタートアップなサービス開発やアジャイルの方法論を意識し、変更があることを前提とした開発プロセスを取り入れること
• テクノロジー：クラウドを最大限活用し、俊敏性や拡張性を考慮したアーキテクチャを設計すること。

冒頭でお伝えした「DXでよくある課題」への対策は以下の通りとなります。
DXに取り組む際は参考にしてみてください。

NCDCでは独自のDX推進方法論を定義しています。
資料も公開していますので、ぜひ併せてご覧ください。
日本企業向け、DX推進力を高めるフレームワーク

DXのご相談はNCDCへ

NCDCではDXコンサルティング、PoCサポート、内製化支援、DX人材採用支援などのサービスを通じて、DXに取り組む企業を幅広くサポートしています。
DX推進のためにまず何から取り組むべきかというような初期のお悩みから、PoCの実施、内製チームの立ち上げ、クラウドインテグレーションなど具体的なプロジェクトまで、DXに関するご相談がある方はぜひお問い合わせください。