@ippokm ともうします。すごく当たり前のことを書きます。
この記事はGaiax Advent Calendar 2015の11日目でもあります。

LeanUXっぽい話をします。
LeanUXはLeanStartUpのメソッド（MVPの作成による仮説検証）をDesignThinkingという手法とアジャイル開発という手法によって実現したものです。ただし、独断と偏見を混ぜながら雑にまとめています。

コードを書く時間はもったいない

事業を進めていくうえで、開発をする時間はとても貴重な時間であって、エンジニアが最大の価値を発揮する瞬間でもあります。
このコードを書くという行動をするために、エンジニアという職業があるといっても過言ではありません。
コードを書き、動作するシステムを作って、事業を推進していくということこそがエンジニアの知的生産性なのです。

しかし、これには重大な前提があるということを、考えたことはあるでしょうか。

重大な前提

エンジニアの価値が発揮されるのは、書いたコードが、
事業の中で適切にユーザーに価値を届けられた時だけだ、ということです。

仮に、寝る間を惜しんで作った機能が、ユーザーに気付かれもしなかったら…
仮に、頑張って実装した機能が、ユーザーにとって全く必要のないものだったら…

意味がなくなってしまいますよね。
今までの俺達の努力は何だったのか。。。

こういうことは、特に新規事業に関わるエンジニアであれば、誰でも一度は経験したことがあるのでは無いでしょうか。

「結果：アウトプット」ではなく「成果：アウトカム」

LeanUXでは、プロジェクトの進捗を、

結果：アウトプット「正確に動く機能やアプリケーションを作りきった」

ではなく、

成果：アウトカム「ユーザーの行動が変わった」「ビジネスゴールに近づいた」

で測定すべきだと考えます。

当前ですよね。

しかし、私たちはこの重大な前提をしばしば忘れがちです。
では、どうすればよいか。

ユーザー視点に立とう！

そこに一番近づく方法はユーザーの視点に立つこと。
しかし、開発者自身がユーザーと同じ視点で、自分たちが作った製品を客観的評価し続けることができるのでしょうか。

答えは簡単です。

絶対に不可能なのです。

そこで必要となってくるのがユーザーテストや行動観察といった手法です。

ユーザーテスト

ユーザーテストでは、自分たちの作った製品を、ターゲットとなるユーザーに実際に使ってもらい、その行動を観察することによって、製品・サービスに含まれる課題を明らかにするというものです。

ユーザーテストでテストできることには、様々な物があります。

ユーザーのフォーム入力がどのように行われるのか。スムーズにできるのか。
ボタンの位置が適切であるか。ボタンに気づいているか。
ユーザーはそのページのどこを見ているのか。どんな順番で見ているのか。
ユーザーがそのページを開いた瞬間、何を感じたのか。どんな気持ちだったのか。

Google Analyticsでは取得できない様々な課題が、ユーザーテストから明らかになるのです。
そしてその課題は、時として、そのサービスを利用する上での重大な欠陥であったりするのです。

開発した機能に気づかない
機能を追加したことで、途中でページから移動してしまいサービス全体にとっては実は悪影響だった。
そもそもこのページで何ができるのか、理解されていない

などです。

ユーザーに最速で価値を届ける

それでは、ユーザーに最速で価値を届けるにはどうすればよいか。
それは、LeanStartUpで言うところの仮説検証を高速で回すこと。

仮説を思いついたら、最も高速でその仮説を検証する方法を考え、そのために行動することです。

検証する方法はユーザーテストだけではもちろんありません。
A/Bテスト、インタビュー、ユーザーテスト、登録フォームだけを作る、などの方法があります。

そして、重要な事は、

機能を作りきって大きく失敗する

のではなく

最小限の労力で仮説を検証して
最大のアウトカムを得ることです

ユーザーテストをする際には
機能を全て作りる必要はありません。
プロトタイプで十分なのです。

例えば

ペーパープロトタイプ
ワイヤーフレーム
ページデザインのイラスト
クリックできるワイヤーフレーム
静的なHTMLページ
実際には動かない偽のボタンを設置する

こういったものでも、ユーザーに実際に製品の一部として使ってもらうことはできます。
そして、自分が検証したいものに合わせて、これらの手法を利用して、仮説を紐解いていくのです。

「それはデザイナーの仕事」ではなく「エンジニアこそやるべきこと」

そう、これは UXデザインの領域ですよね。
しかし、サービスの価値を高めるためには、必ずエンジニアの力が必要なのです。

高速でテストを回していくには、高速でプロトタイプを作成する必要があります。
チーム全員がテストをしていれば、「構成書」などの書類を作らずとも、全員の合意が取れるようになります。
自分たちが実装すべき機能、追加すべき要素をチーム全員で明らかにしていくので、スムーズにプロジェクトをすすめることができます。

プロトタイピングをするときに静的ページ作ったり、A/Bテストをできるようにしたり、そもそも仮説検証をするにあたっての仮説や検証方法を定義するという論理的な行動などは、エンジニアが最も得意とする領域です。

事業の核を作り、推進していくフェーズにおいて、こうしたエンジニアのコードを書く以外の働きは、今後必要不可欠になっていくでしょう。

コードを書かずにプロトタイプを作ろう！

プロトタイピングはチーム全員が取り組むべきものです。
アイデアにデザイナーもエンジニアもありません。
最終的には、エンジニアがコードを書き、デザイナーが綺麗なデザインを上げ、製品が作られていきます。

しかし、仮説を検証するプロトタイプは、綺麗である必要も、ちゃんと動く必要もないのです。
僕達が作ろうとしているサービスや機能が、本当に必要とされているものなのか、ということを確かめるだけなのですから。

Gaiax / Q-LINKチームでの取り組み

LeanStartUpで新規事業の作り方は劇的に変化した、と言われています。
もはや、なにが当たるのかわからない時代。成功する方法を模索するには、このような手法が不可欠だといわれています。

私の所属しているQ-LINKチームでも、UXデザインの手法を取り入れたところ、課題が次々と湧き出てきました。目からうろこ状態です。
事業としての仮説検証も大きくスピードアップしてきました。そしてこれからもどんどん加速していきます。

製品のUXをチーム全員で考え、UXを大きくするために全ての行動をとる。
そして、Leanの手法を用いて早く失敗に気づくこと。
さらに、いち早く次のアクションにつなげていくことが大切なのです。