市谷です。
この夏に手がけていた仕事が1つ終わりました。仮説検証のためのMVP開発であったため、プロダクトとしての作り込みはむしろこれからになります。2ヶ月足らずの短い期間でしたが得られた学びは大きく、一部始終をご紹介したいと思います。
※注意：この記事は2014年9月29日にGuildWorks Blogで公開したエントリをリライトしたものです。
今回のプロジェクトの位置付けはプロダクトの仮説を検証するための動くMVPを作るというものでした。クライアント様にて想定ユーザーへのインタビューを進めてきており、その結果を踏まえてMVPに必要なバックログを見立て、開発を始めました。バックログの見立てに際しては、ユーザーストーリーマッピングを実施しました。コンセプトメイキングのための道具立ては、「正しいもの」を探すための「4つの道具」で述べたとおりです。今回のプロジェクトは下の図における仮説検証フェーズの真っ只中にあるプロジェクトでした。
開発を進めている間も、クライアント様にてインタビューを継続的に実施していました。インタビューのプランニングと実施にはかなり力を入れられていました。これほど顧客発見に真摯に向かうクライアント様とご一緒することはそうないだろうと感じるくらいでした。
顧客開発からプロダクト開発への宿題
一方、インタビューを日々実施し仮説の検証を並行しているということは、プロダクトに関する意思決定がいつ起きてもおかしくないということになります。検証によって新たな学びが得られるということは、プロダクトへの影響が出てくるということ。「発生する変化に適応しながら開発を進めていく」ということにはなるのですが、関係者が抱えている期待とのすり合わせができていませんと結果として「こんなはずではなかった」になりかねません。
というのも、関係者には「このくらいの予算をかけて、このくらいの時期には、このくらいのモノが出来ていて欲しい」という期待が暗黙的に(根拠の確からしさは別にして)あるものだからです。逆にいうと「一定額の投資をかけて、1ヶ月後に、なんでもいいから出来ていたらいいなぁ」なんてのんびりとしたことは現実としてなかなか無さそうですね。あるいは自分自身が自分のお金をかけると考えたときに、そんなのんびりと構えていられるでしょうか。そう想像してみると「期待」というあやふやな思惑が無視できないものと捉えられます。
「方針を変えながらも、一定の期待通りにプロダクト開発を進めたい」という要請は難易度としては高めです。そもそもプロジェクトに影響を与える要素(品質、コスト、ローンチ時期、スコープ)が基本的にトレードオフの関係にあることを考えると、どこまで受け入れるかは関係者の考え方次第です。ただ、状況に応じて変化を受け入れつつ、それでいて関係者の期待を高いレベルで達成できるとしたら。ビジネスが前進するのもまた、事実です。どのような姿勢でプロダクト開発に臨むのかは自分たちを含めた関係者次第です。私たちはこのプロジェクトでは変化を受け入れながら、どれだけ期待を満たせるかチャレンジする方を選びました。
顧客発見、顧客実証に真摯なプロダクトオーナーと組んだ場合、つまり顧客開発に忠実であろうとすればするほど、プロダクト開発はカオスへと近づきます(顧客開発の詳しい内容は書籍やこちら等を参考にしてください)。それは「顧客開発に適応できるプロダクト開発とは何か？」という、顧客開発からプロダクト開発への要請といえそうです。顧客開発に寄り添うプロジェクトのバランスを取るのが難しいと感じる時、逆にそれは、知り得なかった事実を発見できているといえるかもしれません。
プロダクト開発から顧客開発への回答
イテレーティブかつインクリメンタルな開発。いわゆるアジャイルな開発は変化に寄り添うために必要な姿勢ですが、反復的な開発の遂行によってのみ期待を達成するというのは難しいでしょう。ここでいう期待とは、アウトプットに対する関係者の主観的定性的な希望です。これをプロジェクト全体の共通理解にするために客観的定量的に表現できると良いのですが、ソフトウェア開発の歴史を紐解くまでもなく、関係者共通のものさしを用意すること自体が難しい。では、どのような作戦が取れるのでしょうか。以下にまとめます。
期待の可視化
まずもって関係者がプロジェクトに対してどのような期待を持っているのか把握が必要です。プロジェクトを終えるときどうなっていたいか。達成できなければプロジェクトを実施する意味がないと言えることとは何か。このレベルの期待自体も変わることがあります。どこまで期待に応えられるかは状況に応じて異なりますが、一ついえることは、頭の中にしかない期待はその変化を追うことができないということです。期待の可視化はインセプションデッキによってアウトプットすることが多いです。
着地点を常に追う
変化が生じれば、プロジェクトの着地点も変わる。変化に寄り添うほど着地点は変わっていくことになりますが、このトレースの手を抜くと着地点に対する共通理解が育まれず、結果として期待違いとなる恐れがあります。必要なことは、そもそもどの変化に対してどのような意思決定が生じるのかという事実の理解。その結果、どうなるのかという見立ての共有。その結果は望ましいのか、望ましくないのかという議論の機会を作ること。私の場合は、イテレーション毎に簡単なレポートを関係者に提示するようにしています。
先読みする
私自身は「先読み」を重視しています。プロジェクトを旅に例えるなら、先読みは安全な旅をデザインするガイドの役割です。プロジェクトのリスクヘッジや関係者の期待の実現のために、先々の状況、展開を読みます。もちろん先読みが外れることはあります。では先読みはムダな行為でしょうか。先読みはこれまでの経験によって精度が左右されます。どこまで、どれだけ先読みするかは属人的に判断すると良さそうです。なお「アジャイルな見積りと計画づくり」に「移動する先読み範囲」という考え方があり、こちらの書籍も参考になると思います。
目線をあわせる
ビジョナリーなプロダクトオーナーほど、しっかりと目的、目標を持っています。目線をあわせることで、着地点でどうありたいかというプロダクトオーナーの期待を自分ごと化することができます。「その目的ならば、私も着地点はこうありたい。」「むしろ、こうあるべきではないのか。」といった会話がプロダクトオーナーと出来るようになっていれば、もはや「誰の期待をどうするのか」と言う必要性はあまり重要ではなくなっているかもしれません。もちろん理想(期待)と現実にはGapがあるものです。このGapをどう埋めるかが、チーム開発の工夫であり、マネジメントの工夫であるといえます。
期待を現実にあわせる
期待と現実のGapを解消するための選択肢のひとつ。「先読み」と「着地点」の可視化によって期待があまりに現実離れしていることが分かれば、今どのような判断をとるべきなのかも、見えてくるはずですね。
期待に早めに近づいておく = バッファを残しながら開発を進める
つくるべきものの中でも、固いところ(mustで必要なこと)と柔らかいところ(まだどうあるべきか決まっていない)がありますね。固くできそうなところは早く固める。そして固いところを出来る限り早めに倒す。そのために関係者の協力も遠慮なく求めます。期待しているアウトプットに早めに近づいておくことで(=バッファを作る)、柔らかいところが後で決まったときに「想定よりもボリュームが上振れしたとしても」可能な限り吸収する。「目線をあわせられている」ならば、その上振れの必要性を理解できるため、むしろそうあるべきだとこちらから提案できますね。
幅で合意、深さで調整
どのようにアウトプットにコミットメントするのか。私は、不確実性が高いプロジェクトでは幅をコミットメントし、深さで調整するようにしています。幅とは、着地点に対する期待のことです。深さとは期待の実現手段のことです。例えば「お買い物客として、クレジットカード決済がしたい。」という要求があったときに、どんな機能、どんな画面構成にするかは手段の話です。この実現手段をレベル的に、松竹梅の3案くらい用意します。このうち梅案が要求実現レベルとして少なくとも満足できる内容になっていれば、他の状況から少なくとも梅案採用になったとしても目的は果たせるわけです。もちろん、場合によって松案が採用できることもある。「期待に早めに近づいておく」ことができたとき、3案からの選択に自由をきかせることができるのではないでしょうか。
ビジネスと開発、一方の基準に偏らないチーム開発
ビジネス的な成果だけを優先してプロジェクトを運営し、開発を破綻させる。逆に、開発プロセスを型通りに回すことを優先し、ビジネス的な成果が乏しい結果となる。どちらも望ましい結果とはいえませんね。どちらの基準を優先したとしても、おそらくプロジェクトやプロダクトに込めた目的には辿り着けないでしょう。プロジェクトやプロダクトの目的を実現するための作戦を、関係者と協力して打ち出すことが私たちに求められることですね。関係者の期待を追いながら、開発チームが十分に力を発揮できるための環境を作っていく。それがマネジメントの意義といえます。
さて、最後にこのプロジェクトの開発チームの体制について紹介しておきましょう。最終的に、プログラマー2名、テスター1名、マネジメント1名の体制としました。プログラマーの2人は仙台と鎌倉に在住し、ほぼリモートワークでした。リモートワークを実現するための環境もだいぶ整ってきたと感じています。使っている道具については、ギルドワークスのリモートワークを支える技術を参照してください。プロセスについては機会があれば別で書きたいと思います。
顧客開発とプロダクト開発の先へ
以上ような工夫を駆使しながらも、短期決戦なプロジェクトであったため力で倒す局面もありました。協力頂いたクライアント様や、チームに感謝しています。一方、冒頭に書いたとおり、本当のプロダクト開発はむしろこれからになります。ベースができて動くソフトウェアで検証ができるようになりました。今後も、顧客開発と寄り添いながら、プロダクト開発を進めていかねばなりません。そこには、「この期日になれば終了」というプロジェクト的な終わりはもはや存在しなくなったのです。
正しいものを探す => 正しくつくる => 正しいものを探す...というサイクルを回すことは、ひとことで書くほど簡単なことではありません。顧客開発とプロダクト開発への深い理解と、強い信念(=目的を達成したいという意思)がそれを下支えすると感じています。顧客開発とプロダクト開発が両輪となってしっかりと噛み合った開発は、どこかワクワクとした雰囲気になります。日々生み出していくアウトプットがビジネスの成果に繋がっていくだろうという期待をチームにも関係者にももたらすからです。
こういった仕事や成果に関心をもたれた方は「ギルドワークスに依頼する」「ギルドワークスと組む」などを参照いただき、お気軽にお問い合わせください。
0
取り消す
この記事に共感したら、何度でも押してこの記事のポイントをみんなでアップしよう。