お仕事のヘルプとprotocol buffersと。
-
2023年9月26日
はじめまして！ココネでエンジニアリングマネージャーをしているSと申します。
ココネのエンジニアリングマネージャーは主に「人＝メンバーの成長と評価」を担当するため、コードを書くことの比重が低くなりますが、それでも書くことがあります。
その1つが、お仕事のヘルプに入る時です。
特にここ数年のご時世においては大変辛いことですが、流行病によって昔よりもヘルプに入る可能性としては上がっているのではないでしょうか。ココネのカルチャーとして掲げている「相手7、自分3の “7:3で生きる”」にも繋がる話かと思いましたので、実際に最近実施したヘルプ内容について記事に書いてみました。
前提条件
- ココネでは、多くのプロジェクトでprotocol buffers（以下、protobuf）が利用されています。
- 今回はとある既存のプロジェクトで、クライアントエンジニアとサーバーエンジニアでprotoファイルの最初のすり合わせが終わったくらいで、しかしコーディングは進んでいないくらいの状態です。
- 申し遅れましたが、私はサーバーサイド出身なのでサーバーエンジニアからの観点でのヘルプの話になります。
ヘルプのプロセス
さて、ヘルプに入ることになりました。今回の企画は何をやりたいのか、右も左も分かりません。以下の通りに行動してみました。
- ドキュメントの読み込み（企画書や仕様書）
- protoファイルの読み込みと既存ソースコードの確認
- 関係者との再キックオフ
- コーディング
1. ドキュメントの読み込み
まずは、兎にも角にも私は何をつくれば良いのかを把握してゆきます。ココネではConfluenceやGoogle Slideなどでドキュメントが展開されることが多いです。仕様書や、付随する企画書を読み込んでいきます。必要に応じてSlackの該当チャンネルの会話も一気に見ます。
ここで重要なのは、お客さまにどういう体験をしていただきたいのかのコア部分を把握してゆくことです。ヘルプとは言っても、ただ欠けた部分を埋めるだけではなく、せっかくなので第三者的に新鮮な観点で見ることで、より良いものが作れる可能性もあります。
スケジュールが遅れるかもしれないと心配になるプランナー、休んでしまって迷惑をかけたと感じるメンバー、、、そうした不安から救うためにも、ヘルプは、ぜひポジティブに行きましょう。
このフェーズでしっかり読み込み、理解度を上げることで、後の工程でプランナーの方を初めとして、話をするときにストレスを減らすことができます。
2. protoファイルの読み込みと既存ソースコードの確認
自分なりに企画のコア部分を把握したら、protoファイルを読みます。
企画の規模にもよりますが、おそらく多くの場合、いくつかの新規RPCと既存RPCの変更があるかと思います。
既存RPCの変更が多かった場合は、まずは今の状態のRPCをひたすら読んで理解を深めます。
既存RPCの変更については、よほどトリッキーでない限りすぐに理解可能だと思います。逆にトリッキーな感じだった場合は「本当に…？」という気持ちで考え抜くと、より良い方法が見つかるチャンスです。逆に、より良い方法が見つからなかった場合、なぜそういった仕様になっているかを聞けば、理解度が一気に高まります。
今回は既存RPCの変更が主でしたので、ひたすら読みました。
これは人によると思いますが、私の場合はまずはResponseを見て「何が欲しいのか」を知り、その次にRequestを見ることで「いつ欲しいのか」を把握してゆきます。
また、protoファイルのcommit履歴などを見て、クライアントエンジニア、サーバーエンジニア、それぞれの参加具合を見ます。これにより、さっと決まったのか、議論で試行錯誤したのか、なども把握できます。
ここで理解度を上げることで、後の工程でクライアントエンジニアの方と話をするときにストレスを減らすことができます。
3. 関係者との再キックオフ
さて、ここまで来ると、答え合わせをしたくてたまらないような状態になっているのがエンジニアなのではないでしょうか（？）
プランナーの方と、クライアントエンジニアの方と、ここまでの工程でやってきたような
- 企画のコア部分に対する確認と、質問
- クライアントエンジニアとの、把握した注意点の擦り合わせ
といったことをする、再キックオフのようなことをします。
このミーティングを終えて、初めてコードを書ける状態となります。ここも重要で、先にコードを書き始めてはなりません。例えば、既に時間差で不要となっている機能が実はあるかもしれません。コードを書き始める前に、必ず会話をするのが重要です。
ヘルプの際は時間も限られていることも多いです。それゆえに重要なのは手を動かす時間を最小限にすることとなります。
また、時間が限られているからこそ「実はこの機能はカットした方がお客様体験が良くなるのではないだろうか？」という発想も出やすいです。
今回も、工数が減って不具合も減るような提案があったのですが、実はその方がお客様的にもシンプルだよね、といったものがあり、採用していただきました。
（シンプルな物の方がお客様にとっても良いことがありますよね、というのは、また別の深いテーマですね）
4. コーディング
いよいよコーディングです。
ここまで来れば、あとは全力で走って追いつくだけです。がんばりましょう。
まとめ
さて、いくつかポイントがあります。
- protobufというフォーマット
- ココネの雰囲気
私は前職ではRESTなどがメインで、クライアント（フロント）エンジニアと仕様を擦り合わせるのに時間がかかる状態でした。protobufはクライアントエンジニアとの会話がprotoファイルで非常に迅速にできる点が好きでしたが、今回のようなヘルプの観点でも優れている点をあらためて感じました。
また、ココネはプランナーの方ともクライアントエンジニアの方とも和気藹々しているので、「よっしゃヘルプだ！」という感じで前に進むことができます。
当然、リリースのスケジュールをずらすこともありますが、ヘルプをして前に進むのであれば何よりお客様にいち早くつくったものを体験していただくことができます。
お客様の方を向き、仲間の方を向き、物事を前に進めてゆく、、、ココネっぽい話かもなぁ、と自分で書いてあらためて思いました。
皆様のヘルプ体験なども機会があれば、是非聞いてみたいです！
