見出し画像

お届けチームでオーナーシップを持っていくぞ

すずき

この記事は 10X アドベントカレンダー2023 12日目の記事です。
前日の記事は genkey6さんの Relay Proxyを活用してLaunchDarklyを導入する でした。

10Xのお届けチームのSWE鈴木です。10Xには入社1年が過ぎました。

今回はこちらの記事でも書いているお届けチームでしている、自分たちのあずかる領域のプロダクトにオーナーシップを持って仕事をするために行なっていることを紹介していきます。
オーナーシップを持つなんて当然じゃない？という意見もあると思いますが、お届けチームの組成は23年4月とまだ最近です。

メンバーはお届け領域にあるプロダクトの機能やそれを実現するために実装されたものの詳細や経緯を全くというほど知らないところからスタートしました。
また突貫工事で実装された内容も多く、コードを見ると驚くことも少なくありません。
それでも領域に実装されているものはチームでオーナーシップを持ってメンテナンスする必要があるので、

  • 問い合わせやバグ報告が上がってきたコードには積極的にコメント、テスト、ログの追加をする

  • お届けチームを超えて課題のあるコードにはﾁｮｯﾄだけ整理をする

  • チャンスでは大胆に書き換える

等々コードに対するオーナーシップを醸成するために取り組んでいます。
とくに日常的に取り組んでいける
「問い合わせやバグ報告が上がってきたコードには積極的にコメント、テスト、ログの追加をする」について取り上げます。

問い合わせやバグ報告が上がってきたコードには積極的にコメント、テスト、ログの追加をする

コメント

コメントを追加、それでPRを出す

チーム組成当初、お届け領域のコードにはほとんどコメントがない状態でどんな問い合わせが来てもとにかく書かれたコードを目を凝らして見て、動作検証し調査するしかない状態でした。
どんな調査も最終的にはそうなるのですが、コメントのあると不具合へ仮説が建てられたり、修正へのヒントになりますよね。

テスト

PRでのポジティブなコメントの応酬もお届けチームのいいところです

テストがあるだけでこの持ち上げようです。やりがいがありますね。
コメントの件と同じですが、テストも後からコードを読む上で大事な手がかりですよね。
過去にテストが書かれなかったコードへの改善もする一方で、新しく書くコードへのテストコード実装も熱量高くしています。
画像は新しいコード群へのコメントやテストコードの書きっぷりをPRのマージごとに通知している時の文言です。
私は通知がくると「やらなきゃ！」と思うタイプです。

お届けbotさん、名前が可愛いですね

ログ

ここまで読んでくれた方はお気づきかもしれませんが、テスト、コメント同様にログも少ない状況です。
状況が把握できるように必要なところにログを追加する。というのもその時の調査やその後の調査のためにしています。

さらに新しくバリデーションや制御を実装したい！ってときに「これ、バリデーション追加するとできなくなる操作だけど大丈夫かなあ」という場合にもログを追加していっています。
アプリケーションとは不正な状態に陥るので穴を塞ぎたいけど、利用者の方はハックして利用している場合があるのでシュッと塞いでしまうと最悪、現場の業務に不便を発生させてしまいます。

もちろん、不正な状態が致命的であれば早急に塞ぎにいき、不便をかけるなら利用者の方にコミュニケーションが必要ですが、不正な状態が「最終的にはまあ大丈夫」であれば時間的な猶予はあるはずで、まず発生頻度を把握するためにログ出力とアラートや集計の仕組みを設定しています。

Cloud Loggingからぽちぽちアラートが設定できて便利です

あまりに不正な状態になっていたり、その状態にするような操作が多ければ業務で日常的に使われているので「とにかく塞ぐ」から「塞いだ上で新しい道を用意する」と対策が変わります。

取り組みんださきに

どの取り組みも足元の辛みを和らげることには繋がっています。
また、

  • お届けチームを超えて課題のあるコードにはﾁｮｯﾄだけ整理をする

  • チャンスでは大胆に書き換える

といった他の取り組みの足場になっています。 とくにエンジニアの楽しみの1つでもあるリファクタリングをするには既存のコードへのテストコードが必要ですよね。

課題を把握して解消するためにリファクタリングしてもよし、しなくてもよし。
機能開発や運用改善のために自分の意思をもって判断できるようになったらオーナーシップ、めちゃくちゃ持ってますよね。
実際に今私たちは「チャンス」でどこは改善して、どこはこのままでヨシとするか実際にチームで話ができているのでオーナーシップ強く持っているはずです。

ログの追加も最初は「怖いからログ出しとこ…」のように恐れからやっていた側面もありますが、「利用者から見えずらい改善の効果が見えるようにログを出そう！」のようにポジティブに追加するケースも出てきています。
まさに作るものにオーナーシップを持ちだしたからこそ出てくるアイディアですね、素敵。

最後に

今回記事ではStailerの実装がオーナーシップの希薄化から「おーキツイねー」というスタート地点から、前に進むためにしている取り組みをTakeOwnerShipしてやっていきしています。とバーンと書かせていただきました。
ここでは書ききれなかった「チャンスで具体的になにしているの？」「実装にどんな展望をもっているの？」「もっと楽しいエンジニアライフの話が聞きたい。」「もっと辛い話聞かせてよ。」などもっと詳しく知りたい人は、カジュアル面談フォームからよろしくお願いします。
明日は、Sota Sugiura さんによる「GitHub audit log exportの話を書く」です。楽しみですね！

この記事が気に入ったらサポートをしてみませんか？