※この記事は 2021年06月09日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。
今回は、「プロダクトの開発スピードを落とさずに、かつユーザーの芯を食ったソリューションを提供するためには、すべてのスコープをいかに小さくできるかが重要」だということについて書いてみたいと思います。
ちなみに弊社はこれを実践することで開発がものすごくスムーズになり、リリース頻度が体感で 50% くらい向上しました！
スピードは失われていく
前提として、プロダクトの開発スピードは意識的に改善し続けなければ、機能の追加とともに失われていきます。
提供する機能の増加に伴い、仕様の辻褄合わせだとか実装の順番だとかの複雑に関連するパラメータも同時に増えてしまうので、結果として人や時間といった必要なリソースが指数的に増えていくという話ですね。 （技術的な負債もこのパラメータに含まれますが、今回は触れません）
機能数とリソースの相関関係イメージ
弊社も tebiki というプロダクトを作り始めて最初の1～2年くらいはスムーズに機能追加できていたのですが、見事にこの典型的なシチュエーションに遭遇してしまいました。
改めてリリースまでの過程を振り返ると、特に仕様検討においてすべてのスコープが大きすぎるのが問題なのでは？と推察されたので、各スコープが小さくなるよう少しずつ変えていくことにしました。
チームを小さくする
それまではミーティングは毎朝実施し、かつ関係者全員が参加する形式にしていました。これはミーティングに参加することでプロダクトの解像度が上がるよね、という考えからでした。
ですが、思い切って開発する機能ごとにミーティングを分割し、最低限の関係者のみ参加するようにしました。考え方としては Spotify モデルの Squad が近いです。
Product Manager と Designer は兼務
これにより意思決定までのスピードが上がっただけでなく、各メンバーに与えられた課題が小さくなったことで、その課題に対するソリューションをより深くまで考えることができるようになりました。
一方で機能の横断的な判断も必要となります。それについてはプロダクトマネージャーとデザイナーが Tribe 的な動きをしてフォローする形を採っています。
決めることを少なくする
改善前はプロダクトマネージャーが仕様の叩きを作って、それをもとに UI を決めてチームみんなで揉もう、という最低限のルールだけを決めていました。
これについても、実装待ちのバックログまでのフローと次のステップに移行してよい ％ をチーム内で合意して決めました。
目に触れやすいよう GitHub の Project に記載
合わせて仕様ドキュメントのフォーマットも策定しました。主に課題とゴールを書いてもらうスタイルです。
ドキュメントのテンプレート
導入前はゴールを決めずに UI 設計に移ったり、逆に UI のパターンも出せないくらいにガチガチに仕様を検討しすぎていたりしましたが、この変更により現在のステップでは何をどのレベルまで決めればいいのかが明確になり、結果としてフロー全体のスループットが大幅に向上しました。 プロジェクトの進め方に時間を割く必要がなくなって、仕様検討のみに思案を巡らせれば良くなったのが主原因ですね。
また実装着手まであとどれくらいかが可視化されたため、全体の開発スケジュールもコントロールしやすくもなりました。
リリースを小さくする
これは以前からやっていましたが、今回のスコープ話と根っこは同じなのでちょっとだけ書くと、リリースする機能を最小限にできないかは常に検討するようにしています。
1st リリースとか 2nd リリースとか
詳しくは『リーンスタートアップ』の第9章を読んでみてください。
確認すべきファイルを少なくする
関係者全員が参加するスタイルの名残で1つの議事録ファイルに日別でミーティングのログを残すようにしていましたが、これも廃止して個別の仕様ドキュメントの末尾にログを書くようにしました。
それと合わせて Figma のコメントや GitHub の issue コメントに散っていた仕様の断片は仕様ドキュメントにまとめるようにし、必ずそれが正となるようにしました。 その結果、仕様や経緯が分からなくなったときに確認すべき箇所は常に仕様ドキュメントのファイルのみでよくなったので、仕様を確認する時間が大幅に削減されました。
ただ常にその仕様ドキュメントの正しさを担保する必要はあるので、実装するエンジニアが仕様ドキュメントをメンテナンスしつつ、かつ実装前に読み合わせをするようにしています。
副次的には、ドキュメントに対する責任の所在がエンジニアに移ったことで、 Feature Factory になりがちなメンタリティを変えることにもつながったと思っています。
まとめ
開発スピードは個人のスキルで改善することももちろんありますが、組織の仕組みを改善することのほうが当然レバレッジが効きます。 組織の規模やフェーズで常にベターなやり方は変わるのでどれくらい参考になるか分かりませんが、この記事が誰かの役に立てば幸いです。
ピナクルズ社では一緒に働く仲間を募集してます！
店舗／倉庫／工場などで働く「デスクレスワーカー」の教育課題にご興味がある方は、オールポジションで絶賛採用してますので、ぜひご応募ください！ 3.エンジニア の求人一覧 - Tebiki株式会社 Tebiki株式会社が公開している、3.エンジニア の求人一覧ですherp.careers
