NTTPCで取り組んでいる仮説検証型の
サービス開発とアジャイル開発について

はじめまして。NTTPCの渡里です。普段はソフトウェアエンジニアとしてサービス開発業務を担当しています。
今回は、発展途上ではありますが、自分達のチームで取り組んでいる仮説検証型のサービス開発とその中で行われているアジャイル開発についてご紹介します。
また、この記事はサービスの企画や開発に携わっている方に向けた内容となっています。

これまでソフトウェアエンジニアとして多くのサービス開発に携わってきましたが、様々な失敗パターンがありました。
いくつかそのパターンを挙げてみると

• 「役立たずを作ってしまう」
  頑張ってコストをかけて追加開発した機能が4年に1度程度しか使われないものだった…
• 「大きな失敗をする」
  とても大きなコスト（人的リソース、お金、期間）をかけたものが売れない…
• 「サービスや機能の必要性を誰も理解できないが、プロジェクトが進行する…」
  とりあえず開発してみよう！
  〇〇だと思っているから！
  偉い人が言ったから！

このような失敗パターンをどのように回避できるのか日々考えていたところ、出会ったのが仮説検証型のサービス開発という形でした。

仮説検証型のサービス開発は、サービスを開発する際に仮説を立て、その仮説が正しいかどうかを事前に検証することで、サービスの失敗のリスクを最小化する手法です。

仮説検証の方式を用いることによって、実際にサービスをリリースする前に問題点を発見し、改善することが可能になり、必要のないものを開発してしまうといったような開発リスクを低減し、よりユーザーニーズに応えられる有用なサービスを開発する確率を高めることができます。

仮説検証の具体的な進め方について説明します。
私達は昔懐かしのリーンスタートアップと呼ばれている手法に倣って、大まかに構築（Build）、計測（Measure）、学習（Learn）の3つのプロセスに分けて仮説検証を進めています。

仮説検証のプロセス

もう少し分かりやすく表現すると、構築が仮説を立てること、計測が仮説の検証、学習が検証結果の分析といったところでしょうか。
これら3つのプロセスを1つのサイクルとして、ループ的に行いながら、サービスを作っていきます。

まず、仮説を立てることからすべては始まります。最初に立てる仮説は自分の中にある経験や憶測で良いと思います。
いずれにせよ仮説検証のサイクルの中でそれが正しいのか、そうでないのかが検証されます。

実際に仮説を立てるにあたって、個人的に最も重要なのは思い込みを仮説に昇華することだと考えています。

思い込みと仮説、一見すると両者にどういった違いがあるのかピンと来ないかもしれませんが、非常にシンプルな違いがあります。それは検証可能かそうでないかです。

例えば、とあるWebサービスのスマートフォン向けのアプリを開発するプロジェクトがあったとします。
多少誇張しますが、よくある思い込みはこうです。
「このアプリは便利なので、作ったら利用してもらえる」
もはや予想に近い感じですね。強引にこれを検証するには、実際にサービスをリリースして検証する大きなギャンブルになってしまいます。
さすがに実際にはこういった思い込みは発生しないと思うかもしれませんが、サービスに対する思いの強さや熱量ゆえにサービス開発の場では案外起こる現象だと思います。

では、先ほどの思い込みを仮説のようにするとこうでしょうか。
「このWebサービスを利用している多くの顧客はスマートフォンでこのサービスを利用したいと考えている」

もしくは
「Webサービスの契約に至らなかったユーザーはスマホアプリであれば利用したいと考えている」

このような仮説であれば、アンケートやインタビューで検証が可能ですね。
実際にギャンブル的にアプリをリリースするより、はるかに小さいコストと期間でスマホアプリの価値を検証できると思います。

仮説を立て終わったら、次にその仮説の真偽を検証します。
自分達は仮説を検証する際、Experiment Board（Javelin experiment board）を少しアレンジしたものを用います。

Experiment Board

Experiment Boardには次のような項目があり、その項目を埋めていくことで仮説の検証を進める準備や検証結果の可視化をすることができます。

• 検証したい仮説
• ペルソナ
• 検証方法と指標
• 学び

実際に先ほどのスマホアプリの例をExperiment Boardに落とし込むと、このような感じでしょうか。

スマホアプリでの例

Experiment Boardの項目の中で、個人的に最も慎重に取り扱うべきだと考えている個所は指標の項目です。
私達は、統計に基づいた数値指標というよりモチベーションを高めたり、維持できるチームの全員（ステークホルダー含め）が納得できる数値指標を設定しています。

仮に、ステークホルダーの鶴の一声で設定された指標やチームやプロジェクトを存続させるために明らかに低い納得ができていない指標を設定し達成したとしても、納得のできていないもやもやした状態で仕事をするのはチームとしても良くないことだと思います。

私達のチームでは、NTTPCのサービスをご利用いただいているお客さまや、ビジネス上関係性のある会社さまに対してインタビューやアンケートを行っています。

検証する仮説や検証を行いたい対象の人数によっては、外部のスポットコンサルサービスやアンケートサービスを利用するパターンもあります。
インタビューやアンケートを行う際にも、インタビューの原稿やアンケートの設計など様々な工夫ポイントがありますが、ここでは割愛させてください。

検証を行い結果が出た後は、その結果を分析し、1つのサイクルとしての結論を出します。
検証結果の分析では特に何か手法めいたものは使っていません。地道にインタビューやアンケートなどで得られた回答を集計し、グループ化したり、将来役に立ちそうな情報を抽出したりし、Experiment Boardの指標との比較や学びの項目を埋めていきます。

分析の結果、指標に達せず仮説が偽の場合は、その時点でプロジェクトを終えることもあります。ただし、チームとして可能性が感じられた場合は諦めずにもう1度、得られた学びや情報をもとに新たな仮説（〇〇なお客さまはダメだったけど××なお客さまならどうだろうなど）を立て、リベンジすることもあります。非常にありがたいことにチームとして熱があれば粘らせてくれます。

仮説が真の場合は、サービス開発として次の仮説検証のサイクルに入ります。(スマホアプリは使ってもらえそうだ。ではアプリにどういった機能を持たせるべきかなど)

これはオマケで個人の経験則による主観での話ですが、インタビューやアンケートへの反応として、「いいサービスですね」「これ使う人いそうですね」といった"緩い"ポジティブな反応や自分事ではない反応はあまり参考にならないような気がしています。

逆に「いつリリースするの？」、「β版を試させてほしい」といった熱量のあるポジティブな反応は大いに参考にするべきだと思いますし、協創のパートナーになる可能性の高い人だと思います。

仮説検証のプロセスについてご紹介してきました。では、仮説検証のサイクルと実際のサービス開発のステップを例として重ね合わせてみます。

1サイクル目：課題の仮説検証（実際にお客さまはこの課題で困っているか、お金を払ってでも解決したい課題なのかどうか）

2サイクル目：課題の解決策の仮説検証（お客さまの課題はこの解決策で解決できるのかどうか）

3サイクル目：課題の解決策の実現方法の仮説検証（解決策はこの提供方法、システム、UIUXなどで達成できるのかどうか）

4サイクル目以降：さらなるブラッシュアップ（機能追加やUIの調整など）

このような感じでしょうか。

正直な話、挙げたような例ほど上手くいったことはあまりありません。何サイクルも同じ仮説検証をこねくり回すことが多いです。

ここまで、仮説検証型のサービス開発について述べてきました。仮説検証のサイクルを通じて、「何を解決するべきか」といった問題設定や様々な判断を小さく細かく行うことで、リスクを最小化することが可能です。

しかし、私達が開発・構築するシステムに関するリスクは残っています。仮説検証のサイクルが進むにつれて、実際の動作を模倣したモックや最小限実行可能な製品（MVP）が必要になります。これらの作成に時間をかけ過ぎることは、現代のビジネスのスピード感に合わず、仮説検証のサイクルを停止させるボトルネックになるばかりか、開発コストの増大やプロジェクトの失敗につながるリスクがあります。

このような理由から、仮説検証型のサービス開発では、小さく、迅速に、正確に開発を進めることができるアジャイル開発を採用する必要があると考えています。

私達のチームでは、アジャイル開発手法の1つであるエクストリームプログラミング（XP）を採用しています。
エクストリームプログラミングに関する詳細は多数の記事で扱われているため、ここでは割愛しますが、私達が特に意識している、有効だと感じるプラクティスを、使用しているサービスやソフトウェアとともに紹介します。

YAGNI原則（You ain't gonna need it）をはじめとするプラクティスに従い、システム開発を小さく、迅速に、アジャイルに進めるためのシンプルな設計を心がけています。

ウォータフォール開発を行っていた時代は、「念のため」の過剰な設計や実装が多く見られましたが、アジャイル開発、特にMVPの開発時にはシンプルなものを作ることを強く意識しています。

NTTPCでは現在、フルリモートでの働き方が主流です。このため、コミュニケーションは特に重視されています。

最近は、バーチャルオフィスサービスのoViceを利用し、音声やカメラを通じたコミュニケーションを常に取っています。
また、ホワイトボードツールのMiro、デザインツールのFigma、情報集約のためのGROWIやConfluenceも活用しています。

ペアプログラミングは、2人1組でのプログラミング手法です。1人がコードを記述するドライバーとして、もう1人がそれをサポートするナビゲータとして働きます。

NTTPCの開発チームは比較的若い年齢層が多く、オンボーディングやシステムに関する知識共有に時間を要していました。そのため、ペアプログラミングはチームメンバーの育成やサポートに大いに役立っています。

さらに、経験豊富な開発者同士のペアでは、設計やコードの品質向上につながるだけでなく、作業の効率も向上し、楽しいと感じることもあります。
チームによってはペアを毎日交代しています。これは、新しいペア相手に前日の作業を説明することで、自分自身の理解不足に気づく機会にもなります。

また、あるペアで解決できなかった問題が別のペアで解決できることもあり、非常に有効な手法だと考えています。

ペアプログラミングにはVisual Studio CodeのLiveShare機能を利用しており、フルリモートでの作業もスムーズに行えています。

テスト駆動開発では、コード本体を書く前にテストコードを先に作成します。これにより、不具合を早期に発見できるメリットがあり、アジャイル開発の思想に沿ってリスクを最小化できます。

テストコードの作成を通じて仕様の漏れに気がついたり、テストをパスするために必要最低限の実装を行うことで、シンプルな設計や実装を促進します。

私達のチームではペアで作業していることもあり、Aさんがテストコードを書く→Bさんがソースコードを書く→Bさんがテストコードを書く→Aさんがソースコードを…のように交互に作業しています。

アジャイル開発では短いサイクルを継続的に繰り返しますが、無理な努力は長期的に見て良くありません。（おそらく）システム開発は短距離走ではなく、長距離走です。
緊迫した状況で良いアイデアを出し、優れたソースコードを書くのは難しいため、60分から90分毎に休憩を取るなどしています。また、午後3時頃にはラジオ体操や筋トレでリフレッシュする時間を設けています。残業はほとんどありません。

失敗を完全に避けることは不可能ですが、それを経験や学びとして次に活かすことはできます。
真に避けるべきは、不用意に大きな失敗やリスクのある判断をすることです。
仮説を検証し、事実を積み重ね、小さく細かく進めることで、仮説検証型のサービス開発とアジャイル開発は間違いなく有効です。

今後も、仮説検証型のサービス開発とアジャイル開発への理解を深め、より良いサービスを作っていきたいと思います。