Proposal Issueを書くようにしたらめちゃくちゃ良かった話です。
この記事は matsuri technologies 株式会社 Advent Calendar 2023 の 24 日目の記事です(スーパー遅刻)。
# ADR について
弊チームでは、数ヶ月ほど前からアーキテクチャの決定については、 ADR を issue として立てるようになりました。 内容としては、コード規約に相当するようなものや、新しい機能を作る際に考えた設計の話などが多いです。
きっかけとしては上記のスライドを見たのが始まりで、面白そうと思ってやってみたのですが結構感触が良かったなと思っています。
良かった点としてはやはり Context が書かれていることで、後から見返した時になぜそうしたのか、どういう議論があったのかがわかるので、安心感があったり、それをベースに他の設計上の意思決定を行うことができる、などがメリットとして感じられました。
そして ADR を書くようになってしばらくしたら、次に説明する Proposal Issue という概念が生まれていました。
# Proposal Issue とは何か
単に通常の issue と全く同じですが、違うことは「Proposal」のラベルをつけることと、他のチームメンバーに意見を求めることです。
内容としては ADR の Proposal でも、NewFeature の Proposal でも、Refactoring の Proposal でも何でも構いません。
「自分はこうしたい、こうするのが良いと思う」という提案のようなものを、issue の体裁を整えてみんなに向かって投げます。弊社チームでは、だいたいチームの過半数の同意を得られたら Proposal を剥がして正式な issue として昇格する、という流れです。
# 何が良いのか
見切り発車で issue を書ける、というのが良いと思っています。
今までは、なんとなくこういうものがあったらいいかなと思いついてもチームメンバーを捕まえて議論をすること自体のハードルがあったり、その前に自分の考えを整理する必要があったりしたのが個人的にはネックに感じていました。そこが、なんとなく思いついたことを issue の体裁にしていく過程で自然と整理されていきますし、もし仮にそれが間違っていたとしても、他のメンバーからの指摘などで修正されたりしてより良いアイデアになっていくと思えるので、以前にも増して気軽に issue を立てることができるようになりました。
特にプロダクト全体にわたるような意思決定や設計に関する決め事は、何をもって採用とするのかも難しく二の足を踏んでしまいがちなので、そういう心理的ハードルが下がったのが大きいと感じています。
また、余談ですがこの業界を支えてきた RFC という形式の強さ、良さを再確認しました。
# おわりに
今後も気になったことや思いついたことは気軽に Proposal にして投げていこうと思います。