この記事は hacomono advent calendar 2024 の16日目の記事です
こんにちは、hacomonoのプロダクト開発本部のたつ（X）です。僕からはhacomonoの「プロダクトエンジニア」について今回も書かせてもらいます。前回は「プロダクトエンジニア」という役割を定義しましたというお話」という記事の中で、hacomonoのプロダクトエンジニアの定義やそのスキル・マインドについて紹介させていただきました。
さて本日のお話は、そのプロダクトエンジニアの定義や考え方をどのように浸透させていくか、育成していくかという視点からhacomono社内での取り組みの一つである開発設計書のテンプレートを紹介させていただこうと思います。
hacomonoでは機能の開発のフロー中で、実装に入る前に「開発設計書の作成」と「設計レビュー」という段階を用意しています。設計レビューとは端的に言ってしまえば、「今回の開発でこういう課題を解消する機能を開発します。詳細はこんな感じです。」といったものをドキュメントにしたため、そしてそれを関係者でレビューするというものです。そのドキュメント（以後、開発設計書と言います）について、hacomonoで用意しているテンプレートをお見せつつ、工夫しているポイントを紹介します。
こちらがhacomonoの「開発設計書のテンプレート」です
早速お見せします（ドーン）。
掲載している画像は要点だけに絞って見せているので、いささかコンパクトに見えますが、本来はここに開発者の思いの丈を存分したためてもらっています。利用しているドキュメントツールはNotionです。
構成は大きく分けて4つに分かれていて
- タイトル
- 解決したい課題・概要
- ユーザーストーリー/機能一覧
- 参考資料・調査メモ
とあります。書くのはもちろんプロダクトエンジニアです。
hacomonoではこの開発設計書を書く前にPdMからPRD（要求一覧）をもらい、それを元に書き起こしていきます。ただしPRDに書かれている要求についてのことだけを書けば良いかというともちろんそうではありません。PRDに書かれていることをカバーしつつ、さらにそこに自分で考えたアイディアも盛り込みます。
また、後ほど改めて触れますが設計レビューはエンジニア以外の関係者全員で行います。そのため開発設計書と言えども技術専門用語は大部分で利用せず、社内のメンバー誰もが読んでも理解できる記載を心がけます。
それではいくつかポイントを紹介していきます。
と、その前に留意事項です。
一つは全ての開発案件で導入していません（重要です）。不具合修正や小さな改善といった類は省いています。またチームの状況（担当機能の成長フェーズやメンバー構成）によって書く書かないの選択をしてもらっています。
そしてもう一つは各チーム・メンバーでアレンジしてもらっている場合もあります。この後紹介するポイントを押さえておいていただければ問題なし👍️としています。
それではいきます。
POINT 1: 解決したい課題は何かを明確にすること
hacomonoでは開発設計書の中で最も重要なポイントとして、ユーザーが解決したい課題を必ず明確にすることにしています。そのために「解決したい課題・概要」という欄を設けています。
この欄をプロダクトエンジニアが改めて書くことで、解決すべき課題を自身で再認識してもらいます。どんな問題を解決するのか、そのためにはどんな解決策があるのか、プロダクトエンジニア自身が自分の言葉で語れるようにします。
課題と併せて、ユーザーの感情をそのまま記載することもあります。「〇〇な作業が面倒」「××の確認に時間がかかる」といった感情的な部分も含めて書くことで、その後のレビューのときにも関係者全員がより課題が理解しやすくなります。
また、書いていくと一つの設計書に複数の課題が含まれることもあります。その場合、それぞれの課題に対する解決策（実装する機能）が異なるようでであれば、設計資料を分割するといった気づきも得られることがあります。
POINT 2: 機能単位ではなくユーザーストーリー単位で書く
本筋の実装する機能について書く部分です。と、言いつつもポイントは機能単位で書くのではなく、ユーザーストーリー（ユーザーの業務の流れ）に沿って書いてもらっています。ユーザーの業務の流れで実装する機能をどう利用するのかを意識して書いてもらうことで実際のユーザーの業務を逸脱したシステム操作や余計なオペレーションが増えることを抑えるといったことができます。
もちろん開発設計書なので、実装する機能に対する仕様や制限についても明記します。その際には必要に応じて画面のイメージ図（デザイナーさんが用意してくれたFigmaや、ときには自分でラフに書いたり）なども追加します。とにかく誰が読んでもわかりやすく書くことを心がけています。
またこのタイミングで自分のアイディアを盛り込みます。プロダクトエンジニアとしての醍醐味と言えるところです。PdMが用意してくれた「種」（PRD）を大きく花開かせるための要素を考えます。そのためにも機能ではなくユーザーストーリーにフォーカスを当てることで、ユーザーの業務の流れの中で「こんな機能があったら便利かも」というアイディアが生まれやすくなります。
アイディアは必ずしも大きな機能である必要はありません。小さな機能でももちろんOKです。また、工数等の都合で今回は実装できなさそうな案であっても、「将来機能」として書いておくことで、チームで共有し、将来の開発の種として残しておくことができます。
POINT 3: 準備・運用・確認分析でシーンを分けて考えてもらう
皆さんもご経験多いかと思いますが、機能開発の設計を考えるとどうしてもその一点だけを考えてしまいがちです。そして大抵ここでいう「確認・分析」のシーンまで思考が広がらず疎かになりがちになります。
そういった罠に陥らず機能を「点」で考えるのではなく「線」で考えられるように、全ての機能開発において「準備」「運用」「確認」「分析」の4つのフェーズに分けて考えられるように項目を設けています。
またもう1つ大事な要素として、各フェーズにおけるイレギュラーシーンについても考慮します。例えば
- ユーザーの特殊な業務ルールにも幾分かカバーできているか
- 何か問題が発生した際のユーザーでのリカバリー方法は用意されているか
- ユーザーがミスオペレーションしやすい仕様やUXになっていないか
- 問題が発生した際のエンジニアの調査しやすさを考慮したデータ構造やログ出力になっているか
といった具合です。
準備・運用・確認・分析、そしてイレギュラーシーン。これら全方位をおさえることで、機能がより業務に寄り添った形になっていきます。
POINT 4: レビューは関係者全員で
ここで一度、テンプレートの説明から離れてレビューについても紹介します。
開発設計書のレビューは、プロダクトエンジニア、PdM、デザイナー、QA、場合によってはビジネスメンバーも加えて、みんなで様々な視点からブラッシュアップしていきます。
議論はユースケースごとに行います。そこで出た議事録やTODO、テスト観点なども設計書に盛り込めるように、テンプレートにはユースケースごとにそれぞれの項目を設けています。
また、エンジニアチーム内での議論用として「実装方針」の項目も設けています。DB構造など、この段階で相談できるものは一緒に議論していきます。ただし厳密にすべてを決めるというところまではしません。
この項目内だけは技術用語満載ですが、それ以外の項目は先に書いた通りPdM・デザイナー・QA・ビジネスメンバー、誰が読んでもわかりやすく書きます。
このように開発に入る前に関係者全員で合意形成をしておくことで、開発後に大きな手戻りが発生する（いわゆるちゃぶ台返し）確率を極力減らすこともできます。
レビューの場こそ育成・観点共有の場
また、レビューには多くの視点・観点が集まる場であるので、プロダクトエンジニアにとってはとてもよい育成・成長の場にもなります。自分の考え（仮説）を盛り込んだ開発設計書をそれぞれのエキスパートに見てもらうことで、仮説の答え合わせができます。
自分の仮説を盛り込めば盛り込むほど、その答え合わせ（良いアイディアだったのか、考慮点がまだあったのか等）ができるので、盛り込んだアイディアが多ければ多いほどプロダクトエンジニアとしての成長速度も早くなるとも言えそうです。
POINT 5: 開発しながらドキュメントもアップデート
レビューを追加したら開発設計書は完成ではありません。開発が始まってからも積極的にアップデートしていきます。
開発中に更新された仕様の反映したり、実装しながら気づいたテスト観点の充足させたり、最終的にできた画面や実際の動作が確認できる動画の掲載したりもします。随時ドキュメントをアップデートしていくことで、プロジェクトメンバーもいち早く変化に気づけることもできるようになります。
またここまでアップデートを進めておくと最終的には仕様書としても利用することができます。この資料を見てサポートサイトに反映したり、営業やCSのみなさんや今後チームにジョインしたメンバーへのキャッチアップ材料にできたりと、社内で長く利用できるナレッジドキュメントとしても機能するようになります。
まとめ
最後にこのテンプレートを利用することでの効果をまとめてみました。
- テンプレートからスタートすることで、設計レベルを一定水準に保ち、よりよい機能開発を考える時間を増やすことができます。
- プロダクトエンジニアが主体的に考え、書くことで「オーナーシップ」を持ってもらうことができます。
- レビューに関係者全員を巻き込むことで越境しやすい関係性を構築し、その経験を通じてプロダクト機能案の発想の幅を広げていくことができます。
- QAチームが設計段階から参加することで、QAのシフトレフトを実現し、早期から品質向上に貢献できます。
hacomonoの開発設計書のテンプレートの紹介。いかがでしたでしょうか？
読んでいく中で、「うちでも取り入れてみよう」とポイントがあったならば、プロダクトエンジニアという役割を広めていきたいと思う僕にとっては嬉しい限りです。
それでは良い年末年始を。今年もお世話になりました。来年もどうぞよろしくお願いいたします。
株式会社hacomonoでは一緒に働く仲間を募集しています。
エンジニア採用サイトや採用ウィッシュリストもぜひご覧ください！
