DXのプロセスにおける検証の”正しさ”とは
先ずは、新規事業におけるDXのプロセスについて説明します。スタートアップ / 新規事業において新規サービスを構築する場合、基本的なDXのプロセスは下図の様になるかと思います。
Lean Startup※1等にもあるように、これらのDXのプロセスで重要なのは検証したい”コト”に対し、”正しい”プロトタイプを構築することです。ここで言う正しいプロトタイプとは、検証したいコトを計測・測定したいと思った時に、それを達成するために十分で必要最低限の機能を持っているものの事を言います。又、検証の順序を”正しく”実行することも重要です。上記の図でいうと、各フェーズ毎に検証のための”正しい”プロトタイプ例が記載されていますが、例えば以下の様な状況は危険信号です。
- Webサービスのアイデアが出来たぞ！先ずはこのサービスが受け入れられるかシステムプロトタイプを開発しよう
- 市場分析の結果、参入する価値はありそうだ。ユーザにコンセプトが受け入れられるかどうか、早速β版を開発してユーザヒアリングしてみよう
01.については市場分析を行わず、デザイン/機能検証を進めている例です。プロダクト・アウト戦略に基づき、潜在ニーズを想定した上で進めている場合であれば良いですが、マーケットインにも関わらず市場分析をせずに進めているのであれば危険です。
02.の場合は、コンセプトを検証するために必要なプロトタイプが重厚すぎている可能性があります。最近はローコード/ノーコードのプラットフォームの機能が充実してきており、システムプロトタイプ/β版が従来と比較して格段に早く構築出来る様になっていますが、それでもコストはかかりますし、場合によってはエンジニアの調達も必要です。
早く・安くシステムプロトタイプを作るための開発手法って？
では、実際にシステムプロトタイプを構築するためにどの様な開発手法を利用すれば良いのでしょうか？
上記でノーコード/ローコードについて触れましたが、ある程度簡易な要件の場合、ノーコード/ローコードを活用することでスクラッチ開発より格段に早くシステムプロトタイプを構築することができます。（図2参照）
スクラッチ開発一からオリジナルのシステムを開発する手法では仕様の複雑性に対応できる分、ある程度の期間・開発コストが掛かります。ノーコードはその逆で、機能制限はあるものの比較的短期・安価に開発できます。システムの要件が複雑になるとノーコード/ローコードプラットフォームによっては対応できないものも出てくるのですが、上図の様に主にローコードは近年多くの機能を拡張機能をしているため、外部APIを組み合わせることで大体の機能を実現することが可能になっています。
一方でもちろん注意点もあります。ノーコード/ローコードではソースコードをエクスポート出来ないものが殆どであり、プラットフォームがサービスをクローズした場合、サービスを継続することが難しくなる点が挙げられます。
又、いざシステムトラブルが発生した際にシステム内部がブラックボックスになっているため、迅速な対応ができない場合がある点も注意が必要です。これについてはクラウドベンダが提供するマネージメントサービスを利用する際にも同様の事が言えるのですが、更にブラックボックスの範囲が広がっているので、一部を代替して回避策を取る（DBの参照先を一時的に切り替える等）事が難しくなっています。
そして、セキュリティです。これはクラウドベンダの*aaSを利用する際にも同じことが言えますが、プラットフォーム側のセキュリティ管理体制が重要になります。ここ数年でGoogle※2/ Microsoft※3/ AWS※4等の大手クラウドベンダがそれぞれノーコード/ローコードツールをリリースしていますが、セキュリティの観点で導入企業にとっては結構大きな意味を持っています。というのも、通常ノーコード/ローコードを利用してシステム開発する場合、特に個人情報を扱う場合等は社内のセキュリティポリシとしてセキュリティ管理のISO/IEC認証（27001:*等）をプラットフォーム側が保持している事が求められます。大手クラウドベンダはこれらの認証を保持しているので、いずれかのベンダを利用している場合は、導入は比較的容易かと思います。
プラットフォームについてはノーコード業界でシェアNo.1のbubble.io※5も有名です。bubble.ioのページを見ると、bubble.ioを利用して作成された実績を確認することが出来るので、どの程度まで実現出来るのかを把握するために興味のある方は一度目を通してみるのが良いかと思います。
因みに、bubble.ioを使って以下の要件のアプリを構築したのですが、bubble.ioのチュートリアル〜開発完了（正常系動作確認のみ、デザインは簡素）まで、大体1.5日程度で完了しています。
- アプリ概要
-
- 小売店舗で店舗担当者がPC上から商品在庫の管理（一覧/登録/更新/削除操作）を出来るシステム
- 機能要件
-
- 認証：2要素認証（認証コードをメール宛に送信し、パスワード + 認証コードで認証）
- 在庫管理：商品の一覧/登録/編集/削除
- メール通知：在庫の登録が完了したタイミングで店舗責任者にメールを送信する
これらの点を踏まえ、以下の様な用途の場合にノーコード/ローコードを採用するのが良いと考えています。
- 簡易なプロトタイプとしてのみ利用するシステム
- 社内向けで業務効率化用途などミッションクリティカルではないシステム
- 社外向けである程度のユーザは存在するが、要件がシンプルで、イザとなったらスクラッチで短期間で再構築が可能なシステム
又、プロトタイプ開発のもう一つのやり方として、システムの画面などインタフェースだけを用意し、裏側のロジックは人が実施する、いわゆる人力プロトタイプも選択肢の一つです。但しユーザ数が増えると人的リソースが大量に必要になることがあるのでそこは注意が必要です。
仕様の複雑度/開発規模/リソースを加味してシステムプロトタイプの開発手法を選択しましょう。
まとめ
本記事では、新規事業におけるDXプロセスにおける”正しい”検証のポイント、早く・安いシステムプロトタイプ開発手法について紹介致しました。Insight Edgeでは、住友商事グループ事業領域を対象に、新規事業のDXプロジェクトも実施しています。プロジェクトの特性に応じて新旧様々な開発手法を組み合わせ、常に最適なものづくりを実践しているので、本記事を読んでいただき、より詳しい情報を聞きたい方、興味のある方は、是非HPからお問い合わせください！