スタートアップで働くエンジニアが銀の弾丸を求めて愚直に働いている話 ~ 銀の弾丸なんてものは存在しない ~

こんにちは。こんばんは。おはようございます。アンドパッドで現在はバックエンドの方のエンジニアをやっている北村です。

アンドパッドには2021年4月にJOINしまして、現在までANDPADボード(以下ボード)の開発に携わっています。ANDPAD施工管理が比較的長期間の工事をターゲットにしているのに対してANDPADボードは1日〜数日の間に短期間の工事や施工を行う際のスケジュール管理を行えるサービスです。

lp.andpad.jp

半年ほど前に同チームのバックエンドエンジニアの原田さんに技術的負債を粉砕する記事を投稿してもらいました。今回はその続きの話をしようと思います。

前回記事は塵積もった技術的負債に対する技術的なアプローチがメインでしたが、今回はプロセスやチームビルディングの参考になりそうな話をバックエンドエンジニア目線で書いたものになります。

ANDPADボードの開発チーム紹介

話をイメージしやすくするために、開発チームを紹介します。

メンバーは

  • プロダクトマネージャー(PdM)
  • エンジニアリングマネージャー(EM)
  • デザイナー
  • ソフトウェアエンジニア

といった役割をそれぞれで分担しています。

メインの開発・運用業務はこちらのメンバーで行いつつ、必要に応じてCREやSREなど他チームの方と協力して仕事を進めていきます。

開発プロセスはPdMが開発計画および要件書を作成し、それをもとに各ロールが協力して機能開発〜リリースまで進めていくスタイルです。朝会と週次のMTGは行っていますが、スクラムではありません。

前回の技術的負債を粉砕しますの後に実施した施策

PdMの作成した開発計画に載っている機能開発と並行して以下を行いました。

  • 開発プロセス・要件整理関係
    • 製販会議の実施
    • DevDocテンプレート作成と活用
      • チーム全体で運用している、実装の理由や背景、仕様の詳細、テストの方法などが集約されたドキュメント
    • レビュー観点-SQLの作成
      • パフォーマンスを劣化させる可能性のあるSQLを書かないためのセルフチェックシート
    • Locustを用いた負荷試験の追加
  • リファクタリング
    • DeadCodeの削除
    • 本来分離できるはずだが密結合していたモデルの分離
    • etc...
  • パフォーマンス改善
    • n + 1の解消
    • Preloadを整理して使いやすい仕組みを導入
    • GORM V2へバージョンアップ
    • RDS リードレプリカ対応
  • テストコードの改善
    • 不足していたE2Eテスト(RailsのRequest Specに相当するテスト)の拡充
    • Structのasserts helperを作成
    • E2Eテストの見通しを良くする仕組みの導入
    • test fixtures追加
    • テスト時にAWS S3をMockせずにMinioに差し替え
    • 日本語対応のFakerの作成
  • CI/CDの改善
    • DockerのBaseImageを Alpine から Distroless にした
    • Develop環境作成
      • 今までは本番とStagingの2つしかありませんでした
    • Swagger Docの自動生成
  • 運用改善
    • 監視設定の見直し
      • ボードではSentry, Datadog, AWS CloudWatch Alarmを使用しているのでそれらを整理しました。
        • オオカミ少年アラートをなくす
        • 不足していたアラートの追加
        • Alert内容を見やすくする

※主にAPI目線なので、Webフロントとネイティブアプリも含めるとさらにたくさんあります。

手前味噌ですがかなりの量を実施できたのではないかと思っています。

ブログ執筆という機会を利用してなぜ実施できたのか振り返りつつ言語化してみます。

なぜ施策が実施できたのか

チームビルディングが上手くできた

ボード開発チームのメンバーは半数以上が2021年入社です。もともと開発していたメンバーから開発を引き継ぎ、試行錯誤してきたという経緯があります。

最初はお互いの期待値と役割の認識が揃わないこともあったのですが、

を通して認識齟齬が起こりづらい、起こったとしても建設的に議論ができる関係性作りができたと思います。

特に朝会とお茶会を通して雑談をしていることが心理的安全性を高め、チームの結束を高めることに大きく寄与していると感じています。

ちなみにどのくらい心理的安全性が高いかでいうと「その日は仕事終わりに趣味の活動があるからMTGの時間を調整して欲しい！」と言えるくらいです。*1

参考ですが、定例MTGは以下を実施しています。

  • 朝会
    • 毎朝10:30 ~ 30分で開催
    • 進捗報告と相談と雑談をする
  • プロダクトMTG
    • 毎週金曜日に13:30 ~ 1時間半で開催
    • 直近1〜2週間の開発計画の目線合わせをメインにやりつつ、中長期にやりたい大きめの開発案件の頭出しなどを行う
  • お茶会
    • 毎週水曜日に16:30 ~ 40分で開催
    • 任意参加
    • 雑談がメイン
    • 仕事に関係する相談をしてもOK
  • 製販会議
    • 隔週水曜日に17:30 ~ 30分で開催
    • ANDPADボードの営業責任者と開発チームが話す場。
    • 課題の吸い上げを目的に実際の業務フローやプロダクトの使われ方などをヒアリングする

課題を1つずつ片付ける

SaaSを運営していると障害は必ず発生しますが、障害発生時に影響範囲の洗い出しに手間取るということがありました。

ボードではDatadogでログをモニタリングしているので、Datadog上にUserIDを表示させるという対応を行いました。

内容は単純ですがこれをやらずに放置していると、障害発生のたびに「影響範囲はどうやって洗い出しましょうか？」というコミュニケーションおよび影響範囲の洗い出し作業が発生してしまいます。

後回しにされがちだけど、1回やれば2回目以降はやらずに済むというタスクを1つずつ片付けることで大きめの改善をするための時間を生み出すことに繋がったと考えています。

今後のAPIをどうしていきたいか話す場

通称「今後のAPI MTG」として週次で30分でディスカッションをしています。*2

目的は

  • 課題を課題として認識する
  • 課題を解決するための方向性の認識を揃える

です。

普段の機能開発はGitHubのPR上でコミュニケーションを取ることが多いですが、PRに収まらない中長期で認識を揃えておきたいことを話す場として活用しています。

例えば、

新機能開発に時間がかかっている→なぜか→ボイラープレートが多いからだ→ボイラープレートのうちこの部分は消してしまって問題ないよね。といった内容を話しています。

ここまで認識を揃えた状態でボイラープレートがないPRが上がってくるとレビュワーとしては認識が揃っているのでLGTMしやすいです。(自分がコードを書く際も迷わなくなるのでいいですね。)

反対に認識を揃える過程を飛ばしてボイラープレートがなくなっているPRをレビューするとなると

「あれ？ここのコードはなんでないんだろう？」

「まあ、たしかになくても大丈夫か」

「けど、他のコードとの一貫性はどうしようか」

「ボイラープレートっぽいから削除したと思われるけど他にもボイラープレートは残っている。どんな基準で消していこうとしているんだろうか？」

みたいに考えたり質問したりすることが増えてしまい、

  • レビューに時間がかかる
  • 最初に上がったPRから大幅に変更になってしまう

などの可能性があります。

「今後のAPI MTG」によって手戻りや仕掛品となるコードを減らし、限られたリソースを効率よく活用することに寄与していると思います。

圧倒的な実装力

「時間がないからリファクタリング、自動化ができませんは言い訳。現実的な工数でリファクタリングと自動化を進めることが技術力。」という言葉を聞いたことがあるですが、それを体現してくれているのがバックエンドエンジニアの原田さんです。

スケジュールされた機能開発を前倒しで完了させつつ、改善系のタスクをガンガン進めてくれるのでとてもありがたいです。

(体感ですが、自分が改善系タスクを1やっている間に5くらいやってくれている感じがありますw) *3

そんな圧倒的な実装力を止めないために

  • レビューは最優先で行う
  • Scheduled remindersを設定してレビュー依頼を見逃さない

ようにしています。

PdMの要件整理・スケジューリングスキルが神

PdMからは適宜ANDPADボードというプロダクトの現在の立ち位置と目指している世界観を共有してもらっています。

そして、それ自体が非常に納得感のある内容になっているおかげで「次はこれを作ろうと思います！」と言われたときに「たしかにそれは必要だ。作ろう！！」と迷わず前に進むことができています。

機能開発時はWhyとWhatを共有してもらい、Howのところはエンジニアが検討するという役割分担で進めています。

  • Howを検討したが大変なのでWhatが変えられないか
  • スコープが大きいので小さくリリースできないか
  • 機能開発Aと機能開発Bは修正箇所が被っているので並行して進めずに直列で進めたい

といったことは相談して調整してもらっています。

ボード開発チームでは「夏と冬に合宿期間を設けて一括で技術的負債の返済をする」という取り組みを行っていますが、こちらもPdM発信でスタートしたものです。

EMの調整力

ボード開発チームの現状把握と他チームとの調整を主に行ってもらっています。

普段の機能開発もそうですが「今後のAPI MTG」で決まった方針に従って改善施策を進めるためにはある程度まとまった時間の確保が必要です。

プロダクト横断で進めたい施策などの情報を事前に共有してもらい、マルチタスク等にならないように調整してもらっています。

リファクタリングに協力的なフロント陣

APIのリファクタリングの対象にはインターフェースの変更もあります。

インターフェースの変更を伴うリファクタリングはAPIの都合だけでは進めることはできませんが、フロント陣はめっちゃ協力してくれます。(シンプル)

落ちているボールがほぼない

「課題を1つずつ片付ける」と通じるところがあるのですが、「このタスクは誰がやるんだろう？」という状況になることは観測している範囲ではほぼありません。

もちろん、俎上に上げて検討した結果やらないという判断をすることはあります。

人によって拾えるボールの大きさや頻度は異なりますが、「チームに関係しそうなものはウォッチしておこう」というメンバーしかいないので、たとえ自分が忙しくて拾えなかったとしてもチームの誰かは拾ってくれるだろうという安心感があります。

ボールを拾う人が常に同じだと「ボールを拾う人のキャパ = チームが拾えるボールの数」になっていまいますが、ボールを拾う人が一人に固定されなければチームで拾えるボールの数は相対的に増えることになります。

(チーム全員が限界まで忙しいという状態が長期間続くことって基本的にはないですしね。)

落ちているボールというのは「ちょっとめんどうなもの」が多いので、それらを協力して拾えているというのはチームとして成熟しているなと感じます。

上手く行かなかったこと

KPTは不定期で実施

KPTを不定期で開催しているのですが、日々の開発に追われて間隔が空きすぎることが多いです。

KPTを盛り上げるためにReacji Channelerを使ってKPTの集約を試みたりしましたが、あまりワークしませんでした。

f:id:shin1rok_andpad:20220217160500p:plain ※ 画像のSlackコメントではKPIと言っていますがKPTのことです。

現状チームが上手く回っているので問題にはなっていませんが、チームが機能しなくなったときにはKPTをしっかりやることが必要になるかもしれません。

終わりに

半年間の実績とそれが達成できた要因を振り返ってみました。

EMからよく言われる言葉で「ボード開発チームは役割が充足している」というのがあるのですが、改めてバックエンドエンジニア目線で振り返ってみてもそのとおりだなと思いました。

また、APIとしてはリリース優先で作り込んでしまった負債を解消した半年間となりました。

周囲のサポートも得ながら改善を積み重ねた結果、今後プロダクトを更に成長させるための下準備を整えることができたと思います。

今回紹介したチームは一つの例で、アンドパッドの開発チームのあり方は多種多様です。プロダクトや事業の状況に合わせてそれぞれが工夫しています。（メンバー間で相談しながら常に進化し続けています。）

入社した直後から積極的にどんなチームにするのが良いかを主体的に考えて取り組むことができる文化がアンドパッドにはあります。

現在、たくさんのエンジニアを募集しています。皆さまのこれまでの経験を活かして、ぜひ素晴らしいチーム作りに参加してください！*4

engineer.andpad.co.jp

*1:その時のMTGは19時終わりの予定だったけど盛り上がって延長しそうな雰囲気だったので

*2:話はそれますが、MTGのタイトルって意外と大事ですよね。

*3:社内でもMVPとして表彰されていました！すごい！！👏

*4:本文に最後まで銀の弾丸という言葉が登場しなかったことにお気づきでしょうか。銀の弾丸なんてものは存在しないんですよ。