1. 常にユーザーストーリーを第一に考える
新規プロダクト開発では、当然ですが何もないところからシステムに関する全ての要素を自分たちで作り上げていく必要があります。これには大きな裁量が伴いますが、それゆえに開発チームは常に選択を迫られます。例えば、大きなところではアーキテクチャの選定だったり、小さなところではメッセージを出すタイミングなどの細かな画面動作だったり、多岐にわたります。開発に入る前の段階で細部にわたって設計されていれば迷うことはありませんが、新規プロダクト開発においては変化も多くスピード感が求められるため、作りながらエンジニアが主体的に判断していく必要があります。そのような場面で最速で迷わずに意思決定を行うためにこの方針を定めました。
とはいえ、この方針を掲げたところで実現したいユーザーストーリーがチームメンバー全員に浸透していないと意味がありません。この解決策として前回の記事で触れられているように、物理的な合宿を行い、プロダクトマネージャー・UXデザイナー・エンジニア全員でユーザーストーリーマップを作ることによって「誰に何を届けるためのサービスなのか」という大前提を共通認識として持つようにしました。
これは新規プロダクト開発においては非常に重要な考え方で、限られたリソース・求められるスピード感の中で、全メンバーが常に「ユーザーにとっての価値を追求する＝ユーザーストーリーを第一に考える」という単純なルールに立ち返ることで、芯がぶれることなく最速で意思決定を行っていくことができました。
2. 動くものをベースに会話をする
1の方針を定めることでぶれない芯を作ることができました。ただ、その方針に沿っても十分にユーザーストーリーを満たす新しいプロダクトを生み出すには不確実性が多くあります。それをカバーするために、この方針を定めました。
新規プロダクト開発においては、不確実性が高い状態が多いかと思われます。これ自体は悪いことではなく、不確実性に向き合い、その中で試行錯誤することでより本質的な価値に近づけるはずです。
プロジェクト管理freeeにおいても同様で、従来行われていた業務を一から考え直し、再構築する中で、新しい機能を開発する場面が多くありました。特に開発初期はそのような機能が有用なのか、動作を含め実際のUXを検証する必要が多く、実際にプロダクトマネージャーやUXデザイナーが触りながら議論する時間が必要でした。その解決策として、開発初期はあえてプロダクション環境で使っているAWSではなく、Heroku上に簡易な環境を用意し、pushした数分後にはコミット単位での検証環境ができるようにするなど、常に全員が動くものをベースに会話することを心がけました（このあたりの詳細は次回のエンジニア編をお楽しみに）。
アジャイルソフトウェア開発宣言の「包括的なドキュメントよりも動くソフトウェアを」という有名な言葉がありますが、やはり動くものを全員で見ながら改善策を考えることが不確実性を解消していくためには最速だと実感しています。
