倍速で進めるNutmegのプロダクト開発
Nutmegでは重視しているコアバリューの一つに「Quickness」があります。
某調査では日本人の生産性が先進国の中では低水準なんて言われてますが、Nutmegには無縁の話。Nutmegのプロダクト開発ではスピード感と生産性が実践されており、プロジェクトの進め方など、今までに私が参画してきたプロジェクトとも異なる部分がいくつもあります。
常にプロセスも改善しながら、新機能や機能改修をより早くリリースできるようにプロダクト開発を進めてきて、2022年には12個以上の大きな機能をリリースしました。
Nutmegを開発しているエンジニアはまだ3名。そんな中でこれがどのくらいのスピード感かというと、私個人の感覚ですが、これまでに参画していたプロジェクトの1.5〜2倍近い早いサイクルです。
この記事ではNutmegのちょっと他とは違うプロジェクトの進め方をご紹介します。
その作業、そのこだわりは本当に必要なのか？
私は、大手旅行サイトの再構築、新規ECサービスの立ち上げ、外資・国内の事業会社の自社システムの開発など、さまざまな立場・フェーズでシステム開発のプロジェクトに携わってきましたが、
細部まで詰めたドキュメントの作成
徹底した資料レビュー
が当たり前でした。
要件定義から始まりリリースまでの基本設計や詳細設計書などのドキュメント作り・レビューを行いながら進めていくため、数ヶ月の期間をかけて1つの機能をリリースしていました。
また、既存機能の改修の場合には、昔作った資料の改修箇所を修正してレビューを行なっていたので、案件の大きさに関わらずドキュメント作成とレビューは欠かせない作業でした。
早く使ってもらった方が良くなるはず
時間をかけてドキュメント作成やレビューを行うことは、本当に必要なのか？と思ったことは1度や2度ではありません。
ドキュメント作成やレビューがまったく必要ないとは思わないけれど、必要以上に時間をかけている印象はどこの現場でもありました。いち早く機能をリリースすることでユーザーの反応も早く見られるようになり、作った機能の良し悪しの判断や機能の改善等、早く次のアクションに繋げた方が結果として良いものが作れると今では思っています。
少し違うNutmegでの進め方
じゃあNutmegはどうなんだという話。
新機能の追加でも機能改善でも、要件定義〜テストの流れは同じですが、各フェーズの進め方を常に模索して、早く機能をリリースしてお客様に使ってもらえるようにすることを心がけています。その中で、今までとはやり方が少し違う点をご紹介します。
企画・検討のタイミングから全員の認識を合わせる
まずは、とにもかくにも認識合わせです。プロジェクトごとに社長や代表を含めて関係者を集めて認識合わせとレビューを2度行っています。
1度目は企画の早い段階で「ユーザーが感じている課題」「解決方法」「システム化する機能」を整理して、全体の方向性やスコープのズレがないことを確認します。次にモックアップを見て、最終的なアウトプットになる形を目で見て確認しています。
当然、その都度調整や修正がありますが、レビューを2回行うことでエンジニアも同じ理解を持った上で進められるので、開発もスムーズに進められています
WFより画面モックアップ
通常はワイヤーフレーム（WF）からモックアップの作成、コーディング、と段階を踏んでいくことが多いと思います。しかしNutmegでは、ある程度要件が固まったら、WFではなく、実際の画面のようなモックアップを作成してイメージのすり合わせを行なっています。
実際の画面に近いモックアップの方が利用シーンを想像しやすく、WFで擦り合わせていた時より「気づき」も多く、早く最終的な画面に到達できています。
詳細よりも「利用ケース」を明確に
SIerのプロジェクトで作っていたような詳細設計書は、Nutmegでは作っていません。もちろん、ドキュメントをまったく作っていないわけではないですが、想定されるパターンや各種文言・条件等を全て挙げて資料に落とし込むことまではしていません。
それよりも「誰がどういう意図で使うのか」を整理してドキュメントに落とし込むようにしています。細かな部分を詰め込みすぎて「木を見て森を見ず」とならないように、ユーザーが実際に利用するケースについて関係者全員が同じ認識を持てるような資料作りを心がけています。
ドラフト状態で動きを見て調整
エンジニアがしっかり作り込んでテストが終わるまで何も見ない場合、ほぼできあがった状態で初めて動くものを見ることになります。そのタイミングで何かあった場合、後戻りは難しいですよね。（必要であれば当然戻しますが。）
モックアップでは良さそうに見えていた物が、いざ触ってみると思っていたモノとは少し違って感じることは少なからずあるので、しっかり機能していなくてもある程度動くUIができあがったらドラフト版として触ってみるようにしています。
細部の作り込みはまだ荒い状態でも、実際に使ってみた感覚が掴めると、方向修正や調整はやりやすいし、手戻りの時間・コストも減らせます。
特に意識しているポイント
最初から詳細まで詰め過ぎない
エンジニアも一緒に企画の初期段階でモックアップのレビューなどを行い、機能の根本の部分は理解してもらっているので、細部までドキュメントに詰め込まなくても開発は進められるのです。また、時間をかけて内容の濃いドキュメントを作るよりも、早く開発着手ができるように、機能や動きがわかるように整理して、開発を進めながらやドラフト版での動作を見ながら細部の詰めを行なっています。
必要ないモノは作らない
ドキュメントに記載する内容もスリム化していますが、作成する資料の種類も減っていて、新機能のプロジェクトで作成する資料は主に3つだけです。
ユーザーの課題から作る機能を紐付け、整理した資料
モックアップの画面イメージ
画面に表示する項目や機能の動きを整理したドキュメント
案件の規模にもよりますが、1・2は飛ばして3だけで開発着手する時もあり、手厚い資料がなくてもリリースできると改めて実感しています。
まとめ
最終的にリリースする機能自体にも言えるのですが、モックアップやドキュメントなど、すべてにおいて時間をかけて100点満点を狙えるような精度まで磨き上げてから次に進めるのではなく、ある程度できたら次のフェーズへ、という進め方を実践しています。
各フェーズで細かな修正は常に入るし、ユーザーからのフィードバックを受けてリリース後すぐに改修することもあります。ただ、それは多くの時間をかけて細部まで詰めて作った機能だったとしても同じで、最初からユーザー全員が満足する機能を作ることはできません。なので、早く出して早く使ってもらい、フィードバックがあればそれにも早く対応するようにしています。
ドキュメントやその中身を減らしても、全員が同じ理解を持つことで、これまでよりも早い機能開発ができています。全てを当てはめることはできないと思いますが、スピーディなプロダクト開発のために少しでも参考になれば嬉しいです。
Nutmeg では一緒にプロダクトを作っていくメンバーを募集中です。興味を持っていただいた方は、是非一度お話しできればと思いますで下記よりお問い合わせください。
