この記事はGoodpatch Advent Calendar 2022 19日目の記事です。
Goodpatchのエンジニアのトゥイスクです。自社事業であるオンラインホワイトボードツール「Strap」のチームで開発をしています。 product.strap.app
早速の手前味噌なのですが、Strapの開発チームは、とてもいいチームなのです 🥺
３年ほど前に入った当初から、開発している体験も、アウトプットの質も、よくなるように進められていると思っていて、このチームの一員として働けていることはラッキーだなと思っています。（手前味噌 🙏 ）
しかし、「じゃあ、このチームの開発を良いものたらしめているようなやり方って一体何？」と言われると、具体的にまとめられていたわけではありませんでした。そのため、新しく入ったメンバーの実装レビューをするときに、「チームでこういう認識でやってると思うけど、、、」と、若干フワッとしてしまう場面が結構あることに気づきました。
なので、このチームで開発時に大切にしている観点を言語化して、ちゃんとみんなの認識にしていければと思い、開発時の重要観点をまとめてみるという企画をやってみました。
今回は、その企画で実際にどんなものを作ったかの一部紹介と、どんなことをしたのかを紹介できればと思います。
Strap開発チームが開発時に重要と考えている点をまとめました
早速ですが、まとめた内容の簡易版がこれです。
- 開発におけるメンタリティ
- コードを書くとき
- レビューをするとき、受けるとき
という大項目があり、それぞれの中に３〜４つくらい詳細項目があります。
大項目1. 開発におけるメンタリティ
この大項目では、細かいコードの書き方というよりも、開発全体に対する取り組みの認識についてを、以下の項目にしてまとめています。
- Inspire with Why
- Play as a Team
- イテレーティブな開発
そもそもGoodpatchにはコアバリューという指針があり、前提それがベースにはなっています。 特に「Inspire with Why」と「Play as a Team」はその内容のものを開発用に翻訳したイメージです。
加えて、Strapチームでは、「とにかくなんでも小さくTRYして、やってみてまた軌道修正をしていく」、という気持ちを大事にしているというメンバーの声が多く、項目として「イテレーティブな開発」も追加しました。
領域を超えた全社単位のコアバリューを、よりStrapチーム向けに、より開発者の実際の業務に照らし合わせた観点に落とし込んだ内容しています。
さらに次の分類では、より具体的なコードに関する詳細な観点も入れています。
大項目2. コードを書くとき
この分類では、実際にコードを書くときやレビューをするとき、大事にしている観点を以下の項目にまとめました。
- 人にやさしいコード
- 同じ言語、同じ認識
- チームとアプリのパフォーマンス
- セキュリティ
細かい命名規則やルールは既に存在するコーディングガイドラインに書いてあるので、ここでは「コーディングルールよりも１段上の、思想的な部分となるもの」を入れる形にしました。 特にレビューでよく話に上がる項目かつ、人によって考え方が分かれる可能性がありそうなところを入れようという意識でまとめています。
リーダブルコードはもしかすると当たり前の考え方なのかもしれませんが、例えばStrapチームには「汎用化は急がない」という考え方がずっとあり、ブレストの際（詳細後述）も意見が上がったためDos and Dont'sに内容を入れています。
大項目3. レビューをするとき、受けるとき
前提として、Strapチームはすごくレビューが細かいですw これは、私含め結構他の方も最初カルチャーショックを受けるところなのです 😂
ただ、デリバリーするものの品質へのこだわりと、技術的な負債をできるだけ抑えることを考えると、それが最善と私たちは考えています。
だからこそ、レビュアーには細かくみること、レビュイーには細かくみてもらう前提でいることが求められるということを、チームの認識として揃えていきたく、大項目に入れています。
どうまとめていったか？まとめた流れをフェーズごとに紹介
あくまでも、「みんなで守るルールを作る」という思想押し付け的なものではなく、「こんなことを大事にして今まで開発していってるよ、の言語化」になるのがポイントだと思っているので、やり方も、なるべくメンバーの意見が強く反映されるものにしていければと工夫をしました。
あと、正直、こういう思想系のものをまとめるタスクの優先度って本当難しいと思うのです。
みんななんとなくあった方がいいと思いつつも、こういった指針は長期的に効いてくるものなので、直近の開発が優先ではあります。
その中で、今回の場合はどう進めていったかを次に紹介します。
1. キックオフ：何をどうやるのかを決める
キックオフで、エンジニアメンバーと話して、どうまとめるか？を話しました。
- 演繹的なアプローチをするか？帰納法的なアプローチをするか？という議論があったが、結論としては、実際の細かい事例から考えてまとめていく帰納法的な方でということに
- 1スプリント（2週間）のうち30分と決めて、エンジニアメンバーでZoomミーティングする
- Dos and Don’tsを出すことをネクストアクションに
2. 個人のDos Don’tsを出す
次に、「個人としてのYES, AGREE!」と「個人としてのNO, DISAGREE!」をワークで出しました。
3. Dos Don’tsをグループ分け
２で出した内容を一緒にグルーピングしていって、大きい分類をしました。
4. それぞれの分類の詳細を言語化
付箋で出したものをより伝わりやすい文章にして、表現などを確認していきました。
5. 添削、フィードバックをもらう
コアで関わっていたメンバー以外への共有やフィードバックがあるかを確認しました。実はまだ微妙に終わっていないところなので、これが終われば晴れてv1として紹介できるかなと思います。
プロセスを振り返ってみて
よかったこと
- 1スプリント30分だけ（若干オーバーした時もありますが）と時間を区切ったこと。開発工数への影響は最小限に抑えられたかなと思います。
- まずやり方をチームで相談して決めたこと。自分で進め方から設計でもよかったかもですが、やり方自体も相談できたことで、スムーズに進んだと思います。
- 個人個人の細かい事例のDosとDon’tsから全体へ収束したこと。それぞれのメンバーの考えがより反映されるものができたかなと思います。
改善できそうなところ
- 誰をいつどのように巻き込むかについて。前からいたメンバーをコアメンバーとしていましたが、収束はそのメンバーでやるとしても、DosとDontsだけは新しいメンバーも含めてやってもよかったかもしれないです。
- 周知について。これからやる部分ですが、作って終わりにならないように、みんなが存在を認識できるように周知はしていきたいです。
最後に
今回は、Strap開発チームの開発重要観点についてまとめた件について紹介しました。
Strapチームの良さ、伝わりましたかね、、？（手前味噌 🙏）
私たちの開発の雰囲気が伝わったり、あわよくば何かしら皆様の開発ライフのヒントになれればとっても嬉しいです！
みなさま良いお年を！👋