見出し画像

Devバリュースタンプたちのご紹介

mofu

みなさん初めまして！

aisaacでエンジニアをしているmofuと申します。

最近は、自分がメインでアサインされている事業が変わったり、他事業間での交流が多く、さまざまな意見を聞くことができました。事業ごとにフェーズが違うので、学べることが幅広いのがaisaacのとてもいいところだと思っています。

そこで今日は、「Devバリュースタンプたちのご紹介」と題しまして、
最近僕が入ったDevチームで大切にしているバリューたちを紹介します！

※Devバリュースタンプとは、Slackのスタンプのことで、紹介するバリューを感じた時や、足りてない時に使ってチーム全体で意識を高めていこうというものです

（少し長くなりますが、ぜひ読んでみてほしいです！）


全ての作業を小さく頻繁に

:small_batch:

🗣️「プルリクも差分も小さければ小さい方がいいし、リリースも毎日おこなった方いいよね」

Task Size, Commit, Push, Refactoring, Pull Request, Review, Merge, Deploy, Release...などのさまざまな作業・変更はできるだけ小さく行なっていこうというものです。

作業や変更を大きくしてしまうことは、下記のようなデメリットを伴います。

  • 影響範囲が大きく、不具合などのリスクが大きい

  • エンジニアの負担がかかる

1つ1つの作業を細かくすることで、安全かつある意味気楽に開発を進めることができます。

全員が全てのStack, Processに触れる

:full_cycle

🗣️「1人1人がサービスを作っているんだから、全部触れる方がよき」

Front, Back, Infra, Analytics, Customer Support, Data & System Monitoring, Release...など全部に触れる

そうすることで、いちいち他の人に確認したり依頼することなくシームレスに開発ができます。また、自動的に各エンジニアが全体を把握することになるので、システムやサービスに対して高解像度で開発や提案ができます。

さらに、属人的になりづらいため、休みや異動などで仮に誰か欠けてしまっあ場合でも、止まることなく動き続けることができます。

僕のDevチームでは、フロントエンドエンジニア、インフラエンジニアなど垣根はなく、ある程度分担はあるものの基本的に全部やります！

着手したら1つずつ本番に運ぶ・WIPを増やさない

:flow_efficiency:

🗣️「1つ1つ確実に流していけば、チーム・ユーザ共にWin-Winだ」

複数のことをたくさんやらない。WIPを増やさない。

複数のことを同時にやると、進められるものも後回しになったりしてしまいがちです。また、チームやコード、脳などさまざまなスイッチングコストがかかってしまいます。

止まっているものがあれば、まず流して目の前のタスクに集中できるようにしましょう。

ソフトウェア開発は逐次工程でなくても良い

:non_sequencial:

🗣️「建築物やハードウェアと違って、途中でも前に進められるよね」

code review前にSTG確認して良い、開発の途中でもリリースしていいしRefactoringしてもいい...など

ソフトウェア開発の強みは、アップデートやロールバックできるところにあります。システムを健康に保ちながらであれば、フレキシブルに進行することで頻繁にリリースができ、ユーザーへの価値提供スピードが上がります。

アンチパターン例
- 「AさんのこのPRのレビュー終わるまで、マージできないです！」
- 「OK！じゃあ今mainブランチに溜まっているリリースは遅らせるね。」

上記のようなことが起こらないために自分のチームでは、例えばFeatureFlagというフラグをコード内に仕込み、機能開発中にリリースしてもユーザーには公開しないなどしています。

CodeとTestは並行で書く

 :test_in_timely:

🗣️「ユースケース実装終わったし、テストコード書くぞ！」
🗣️「あれ、実装終わったならテストも終わってるはず…？」

テストは実装が終わってからのプラスの作業ではなく、「実装を効率的に進めるためのツール」として付き合うようにします。

そうすることで、テストで受けられる恩恵を最大限に生かすことができます。

慣れてきてテストと仲良くなると、テスト書いた方が書かないより正確なのはもちろん、実装スピードも早くなるはずです！

良いデータマネジメントが効率を助ける

:data_knowledge:

🗣️「このAPI動かしたいけど、どのテーブルにどんなレコード入れたらええんや…」

正しいデータセットをコード化し、いつでも誰でも "あの機能", "あの動作" をlocalで瞬時に再現、動かせる状態を作ります。

例えばAPIであれば、「Usecase動かすのに必要なデータをSpecに記述しながらテスト用DBに繋いでテスト」を作る。

そうすることで、自動的にUsecaseに必要なデータセットがテストコードに保存され、いつでも誰でもすぐUsecaseを実行することができます。
Test in timelyしながら、正しいデータ知識をまとめておきましょう！

やりすぎない、面倒見るものを増やさない。小さく済むならそれが良い

:min_dev:

🗣️「（値をここで表示しなければ4時間くらい工数減らせるんだよなあ...でも必要って言われたしなあ...）」

その機能や設計は今本当に必要か？そのコーナーケースまでカバーする必要あるか？などを考えます。

↑のセリフ、PMなどに代案と一緒に伝えたらみんな楽になれるかも。

最後に

いかがだったでしょうか？
共感いただいたもの、目から鱗だったもの、それは間違っている！などさまざまな意見があると思います。

事業フェーズやチームによって、バリューとなるものは変わるので、取り入れられるものは盗んでいただいて、合わないな、と思うものはそちらを続けてください。

チームや自身の開発状況を再確認する機会になれば幸いです！
もっと話したいことはたくさんあるので、もし気になった方はいつでもaisaacでお待ちしています🙌

最後まで読んでくださりありがとうございました！



いいなと思ったら応援しよう！