この記事は「Unifa Advent Calendar 2022」の17日目の記事です。
こんにちは。
今年8月、ユニファに入社したPdM（プロダクトマネージャー）の田代です。
早いもので入社して4ヶ月が過ぎ、年末に近付いて参りました。
この時期になると毎年「今年は1年経つの早い」と言ってます。時間は有限なので大事にしていきたいですね。
今回は、最近取り組みを開始したSDRという内容についてお話したいと思います。
初めてのブログ投稿となりますので、温かい目でご覧ください。
【目次】
SDRとは
SDRとは「Specification Decision Records」の略で、日本語で言うと「仕様の決定記録」です。
元々「ADR（Architecture Decision Records）」というアーキテクチャの意思決定を決まったフォーマットで記録し続ける手法があります。
下記は、ThoughtWorksからの引用です。
Much documentation can be replaced with highly readable code and tests. In a world of evolutionary architecture, however, it's important to record certain design decisions for the benefit of future team members as well as for external oversight. Lightweight Architecture Decision Records is a technique for capturing important architectural decisions along with their context and consequences. We recommend storing these details in source control, instead of a wiki or website, as then they can provide a record that remains in sync with the code itself. For most projects, we see no reason why you wouldn't want to use this technique.
要するに可読性の高いコードとテストからでは分からない内容（背景や経緯）を記録するための手法が、ADRです。
今年AWSでもこのADRを使うためのガイドが公開されていました。
これはアーキテクチャの世界だけではなく、仕様に関しての意思決定を記録するためにも使えるのでは？と思い、SDRという名前を勝手に付けました。（既に存在している言葉でしたらすみません。）
SDRを導入した理由
PdMは様々な場面で意思決定が必要です。と同時に意思決定をするからこそ説明責任もあります。
私自身も担当するプロダクトの中で仕様の変更や追加の意思決定をする場面が何度もありました。入社して間もない私は、そもそも過去の経緯が分からないことがあったり、前任の担当者も不在であったり、意思決定をする上で、資料を漁ったり、関係者への聞き取りからスタートしていたため、検討から意思決定までに多くの時間を使っていました。
それでも意思決定をすることが出来たのは、ユニファのドキュメント文化やフォローしてくれるチームメンバーがいたからこそです。
関係者への聞き取りが出来る場合はまだ良いですが、関係者がいないとき、もしくは関係者がいても覚えていない時は、誰もどのような仕様の背景があったか分からないことになります。この場合、完全に無視して仕様の変更を図ったり、盲目的に現在の仕様を受け入れるということを強いられることになるのだと思いました。
過去の経緯が分かれば、課題感や他の選択肢は有効かの検討に幅が出て、意思決定へのスピードが上がり、穏当なプロダクト改善が行いやすいと考え、SDRを導入してみることにしました。仕様の意思決定の記録が残ることによって、チームメンバーや将来のメンバーにとってもハッピーになると思います。（人の記憶は不確かなため、意思決定をした私にとってもその記録が便利になるだろう、というのもあります。）
寿命の長いプロダクトを作っていく（利用者に愛され続ける）ために、これからも仕様に関して数多くの意思決定をすることになると思います。その未来にためにも。
期待している効果
SDRを活用していくことで、以下の効果を期待しています。
意思決定をする上での検討の幅が出る
意思決定した時にいなかった人も背景を知ることができる（時間が経過した後も誰でも簡単にアクセスできる）
意思決定の速度が上がる
情報の透明性が上がる（決定した結果だけでなく、その過程もチームメンバーに共有できる）
業務の引き継ぎの負担が減る
作って終わりにならないために
まずはやってみて改善を繰り返せば良いという精神ではいますが、出来るなら最初からしっかり続けられる運用をしたいものです。
そもそも仕様の背景の記録は残りにくい、という側面もあるので、なるべく負担にならないように記録できるように意識しています。
効果を受けるために気を付けること
１つのファイルはなるべく小さくしてシンプルに
テンプレートを用意する
作成や更新のフローを明確にしておく
テンプレート
ユニファはドキュメント管理に Confuluence を使用しているため、そこにテンプレートを用意しました。
決定した日時や決定内容だけではなく、その理由、他の選択肢などの情報があることで、「何を考慮されて今に至ったのか？」が明確になると考えました。
このテンプレートは他の事例や運用を重ねながらアップデートしていく予定です。
まとめ
まずは始めてみたSDR。記録した内容は、同じくConfuluenceに纏めている仕様書にリンクさせ、その仕様の背景をすぐに確認できるようにしたいと考えています。
始めたばかりですが、効果を得られた点として、実際に他のメンバーから「〇〇の機能ってどういう風に決めました？」と聞かれて、すぐにこのSDRで記録した内容を見せて考慮したポイント等を共有することが出来たことです。
しばらくしたらもっと意思決定に関わる記録が溜まり、どのくらいの効果があったのか見えてくると思います。この効果についてはまた改めて発信できればと思います。
ユニファでは、一緒に働いてくれる仲間を募集しています。
詳細については、こちらからご確認ください。
