Develop：実装するのはプログラムではなく価値【第10回】

　IBM Garageのコンポーネントの1つである「Develop」において「MVP（Minimum Viable Product：実用最小限の製品）」を開発する目的は、エンタープライズに適応したデザイン思考によって創出したアイデアをビジネス展開する際に、利用者にとって本当に価値あるものになっているかどうかを検証することにある。

　開発したプロダクトを実際に使用して検証し、期待していた価値を生み出せるかどうかを判定する。期待にそぐわなければ、そのMVPは廃棄する。

　Developの実践においてIBM Garageでは、グループごとの取り組みが定義されている。（1）Test iteratively（反復テスト）、（2）Code in one day bits（日単位の機能実装）、（3）Architecture considerations（アーキテクチャー洞察）、（4）Accelerate delivery（開発の加速）、（5）Data, AI and analytics（データとAIと分析）だ。以下では、その中でも特に重要なポイントを説明する。

不確実性に対応するためにイテレーション（反復）型を採る

　Garageでは第8回に紹介した「Envision」の活動を通じて「MVP（Minimum Viable Product：実用最小限の製品）」の仮説を記述し、それを基にMVPを構築していく。そこでは、リーンスタートアップなどを中心とした手法を使って、開発・実証実験・学習というステップを繰り返す。

　不確実性が高い状態においては、イテレーション（反復）型の開発手法である「アジャイル手法」は開発との相性が良い。アジャイル手法を導入し、価値を検証する最小単位のみを開発し、MVPのための仮説の有効性を確認しながら進んでいく。

　実験の結果いかんによっては当然、ピボット（仮説を入れ替える）が生じる。ユーザー体験を表すコンセプトを表現した「目標の丘」そのものから考え直す場合も多い。それだけに、アプリケーションをコンポーネントに分け、作り直しが容易な形にしておくことで、コア部分は使い回すなどを工夫する。

　なおアジャイル開発でも、法令やガイドラインは当然遵守しなければならない。例えば個人情報保護法が典型的な例だ。GDPR（General Data Protection Regulation：EU一般データ保護規則）に至っては莫大な制裁金が課される。法令やガイドラインを遵守できない場合は、MVPの再考が必要になる。

　筆者の経験として、仮説検証を実施する際に、法令は遵守すべきだが省庁が出しているガイドラインを遵守すべきかが議論の対象になったことがある。識者や法務担当と相談した結果、法令とガイドラインを共に遵守することにした。これらは、前提・制約になり得ることが多いため、早めに確認する必要がある。

　状況に応じた考え方を以下のミニ演習で確認していただきたい。