はじめに
こちらは バイセルテクノロジーズ Advent Calendar 2024 の5日目の記事です。 昨日は野口さんによるハッシュベースの楽観ロックで解決する編集画面の整合性問題でした。
こんにちは、テクノロジー戦略本部 開発2部の小島です。 私は今年の4月に新卒として入社し、EC販売管理システムの開発・運用に携わっています。
私は開発期間3年以上となる大規模プロダクトのリリース期真っ只中にチームへジョインし、リリースの波に飲み込まれる形で、オンボーディングを途中で中断して開発へ専念することとなりました。
リリースという開発における大きなイベントを経験できたことなど、チームにジョインしてすぐに開発に参加することで良いこともたくさんありました。
その一方、現在進行形でオンボーディングの重要性を強く感じるような経験も多々しています。
今回は私が開発に専念するにあたってどのような取捨選択をしたのか、その結果ぶつかった壁や課題について説明し、オンボーディング期間にどのような知識や能力を身につけるべきかについて自分なりにまとめました。
私と同じような新卒のエンジニア、ジョインしたチームへ早く貢献しなくてはと焦っている人、オンボーディングを早く終わらせて手を動かしたいと思っている人などの助けになれば幸いです。
前提
システムの簡単な概要
この記事の中で、私たちが実際に開発しているシステムを例に挙げることがあるため、ざっくりと概要を説明します。
私たちの作っているシステムは、複数のECモール（ヤフーショッピングやメルカリShopsなど）への出品情報や受注情報を一元管理するアプリケーションです。 ECサイトに商品を出品して注文を受け、その商品を配送するまで管理することができます。
また、ECモール毎に仕様が違う処理を、１つのシステム内で標準化して実装しているため、技術的にはバックエンドが大規模なシステムとなっています。
自身の説明とチームの状況
当時の状況についても少しだけ説明します。
自身について
フロントエンドに関しては学生時代からずっと開発してきたこともあり、苦労せずコードを一通り読める程度の理解はありました。一方でバックエンドに関しては全くの素人で「ポインタ？なにそれプレゼンで使うやつですか」といった状態でした。
そのため、チームにジョインする前に、約1ヶ月半ほど技術のキャッチアップの期間をもうけてもらい、システム開発に必要な技術の基本は押さえた状況でチームにジョインしました。
チームの状況
3ヶ月後にリリースを控え、現場では導入にあたってトレーニングが開始されていました。そこで改善点が見つかったり、バグの修正が残っていたりなどタスクは山積みで、猫の手も借りたいような状態でした。
チームにジョイン
チームにジョインしてから約2週間ほどはプロダクトの説明を受けながらオンボーディングタスクを行なっていました。Go製のCLIツールを実装するというタスクで、Goの書き方などを改めて確認しながらドメインの理解ができるといったようなものです。
しかし、想定以上のバグが見つかるなど、チームの状況が厳しくなり切羽詰まっていくのを見ていました。「その脇でゆっくりオンボーディングタスクをしていられるような状態ではないな」というのを肌で感じており、メンターとの1on1でオンボーディングを切り上げて開発に入り、チームのサポートをしたいという旨を伝えて承諾してもらいました。
開発に加わるという意思決定について
オンボーディング期間を途中で切り上げる意思決定をした主な理由は
- リリースに貢献することで、信頼を積み上げて成果に繋げることができる
- 自分が開発に加われば、あきらかに状況が良くなるのが目に見えていた
- リリースはそう経験できるものではないし、この状況に身を置くことでリリースとはどのようなものか理解できる
というようなメリットが、理解が不十分な状態でオンボーディングを切り上げるデメリットより大きいと考えたからです。また個人的にがっつりコードを書きたい、チームに目に見える形で貢献したいという思いが強くなってきた頃合いだったのも大きな理由の一つです。
約2週間のオンボーディング期間で学んだことは
- システムの概要
- 開発の経緯
- システム構成とアーキテクチャ
- Goの作法
の4点くらいだったので開発ではかなり工夫しました。
オンボーディングにかける時間が少なかった中で工夫したこと
開発をする上で継続的に1つの機能に特化することを自分の中で大切にしていました。
理解にも時間をかけることができるので、実質オンボーディングに近い感覚で取り組むことができます。ここは自分の領域ですといった感じを出して他の人には手出しできない雰囲気をだしてみたり…
自分は注文確認メールのような、お客様にメールを送る機能の中で、メールの文章の出力の実装をGoのtext/templateで行なっていました。ECモールや注文情報、支払い方法に応じてメールの内容を変えるといったものです。
また空いている時間はメールの送信など、同領域のコードを可能な限り読むようにしていました。機能を絞って進めていたので、ドメイン知識もそれなりについてきており、バックエンド初心者の自分でも実装内容がすんなりと入ってきて理解が捗ったのは相乗効果としてかなり良かったと思います。
開発に参加した結果
結果、リリースを迎えることができ無事現場へ導入をすることができました 🎉🎉
リリースに対しては一定以上の貢献ができたのではないかと個人的には思っています。
領域を絞るという戦略も功を奏し、メールの文章の出力〜送信の一通りの実装はチームの中でもかなり詳しくなったと思います。また、実装の依頼や相談などを通して事業部と密にコミュニケーションをとることができ、リリース直後に現場でサポートを行なった際、気兼ねなく質問や話ができたのも良かったなと感じています。
リリース期間では総じて、それなりの成功体験を経て自信を深めることができました。
オンボーディングを中断したことによるデメリット
リリースへの貢献という選択をする上で、自分は一通り開発に入れる技術的なキャッチアップを優先し、業務フローの一連の流れなどドメイン周りの十分な理解は諦めるということを決断しました。さまざまなECモールを扱っている性質上、複雑な実装や仕様があるのですがそれも一旦は放置することにしました。
発生した問題
リリースを経て運用フェーズに移行し、それと同時に新たな機能開発をしていく中で2つの大きな問題を自身が抱えているということに気付かされました。
アラート、問い合わせに対して対応ができない
リリースの直後には緊急の問い合わせやアラートが多く発生しました。しかしながら、
- 問題が発生した際にどんな業務リスクがあるのか、緊急度はどれほどなのかの切り分けができない
- 業務フローもシステムの流れもわからないのでどのような問題が考えられるのか、現場にはどのような対応が必要なのかのアナウンスもできない
といった状態でした。初めてのアラート対応ではテンパって頭も真っ白に近い状態になってしまい、とにかく何もできませんでした。
例を一つ挙げて、アラートの対応方法について一緒に考えてみましょう。
ECモールで注文を受けた際、同時に他のECモールで出品されている同一商品の在庫数を減らすという処理があり、その処理に失敗してアラートが発生したとします。その際どのようなリスクがあって何をすべきでしょうか。
リスクとしては、在庫数にずれが生じて本来は買えないはずの商品が買える状態で残ってしまい、その商品をお客さんが購入してしまうというものです。
なので、はじめにすべきことは
その商品を出品していた他のECモール上でどうなっているかを確認する
です。そこで商品の在庫数が間違っていたら、修正するという早急な対応が必要です。
このような判断ができないので、運用フェーズに入ってからは何もできず、一人ではなかなか力になれないといった状態に陥りました。
主体的な課題解決が難しい
システムに対しても現場で行われていることに対しても理解が足りないため、設計などもできなければ意見も出てきません。そのため、実装手順が丁寧に用意された開発タスクを愚直に実装すること以上に、価値を発揮することに難しさを感じました。
指定された通りにコードを書くだけで、それによってどのようなことができて現場のどのような課題を解決できるのかという本質的なことが不明瞭なので、自分が何を作っているのか実感が湧きませんでした。
また、テストや動作確認でも網羅性に不安が残り品質的にも自信が持てませんでした。
エンジニアリングの本質である課題解決ができない状態で「自分は何のためにエンジニアをやってるんだろう」という迷いがありました。
オンボーディング期間にやるべきこと
このような経験を経て、今はオンボーディング期間にドメインのキャッチアップをおろそかにしたことを本当に後悔しています。
技術の理解がそれなりにできていれば、用意された実装自体はそれほど問題なくできてしまうのが厄介なところだと個人的には感じています。
技術的なキャッチアップさえできれば、コードも読めてドメイン周りは勝手に後からついてくるだろうと思っていましたが、大規模なシステムでECモールの特性を抑えた複雑な処理が多いということも相まって、コードを読んだところでそれは「木を見て森を見ず」の状態で、システムの全体観や深い理解などには全くつながりませんでした。
このような経験から、オンボーディング期間には技術と同様またはそれ以上に、ドメインの理解に時間をかけること意識して疑問を持ってシステムを眺めることを心の底からおすすめします。
技術的に恥ずかしくて聞けないレベルのことはChatGPTが解決してくれますが、ドメインの分野はそうではありません。
オンボーディング期間内は、チームでも育成にコストを割くべきフェーズという認識なので気兼ねなく相談できますが、一度開発に入ると、わからないことの理解にしっかり時間をかけることは厳しくなっていきます。
なので、理解にしっかり時間を取れ、鬱陶しいほどたくさんの質問をしても許される最後の機会だと思って、この期間を大切にしてほしいと思います。
ドメインの理解度チェックにちょうど良いボーダーライン
開発しているシステムのメイン機能で問題が発生した際に何をすべきなのか、一通り説明できるようにするのが個人的には筋が良いと思います。
前述した、在庫の連携に失敗した場合のように
- 発生したリスクや緊急度の判断
- 問題が発生した際、具体的にどのような動きをするのか
- どのような操作やアクションで問題を解決に導くか
問題発生から一旦の暫定的な解決まで簡単に説明できるようになれば、システム、ドメインなど一通り理解できていると考えられ、実務に入った際にも良いスタートダッシュが切れると思います。
チームにジョインしてから今までを振り返って
失敗したことをメインに書いてきましたが、チームにジョインしてから現在までを振り返ると、経験したことやその中での学びが非常に濃い半年間だったと思います。
リリース当時の雰囲気や熱量をチームと共有できたことは自分にとってすごく刺激的でした。また、品質とリリースの天秤の掛け方といったシステムに対するバランス感覚やリリース判断に対する議論など、リリース間近という渦中にいたからこそ体験できたことは多かったです。
そして何よりも、オンボーディングに対して深く向き合うことができたということが、今後の大きな糧になったと思います。
新しくチームにジョインしたメンバーや私と同じような新卒のエンジニアに対して、積極的に自分の経験を還元していきたいと考えています。
この記事を書いている今でも、ドメインの全てを理解したとはまだまだ言えない状態で、わからないことはたくさんあります。
1つずつではありますが、地道に丁寧に理解しながら開発を進めていきたいと考えています。
最後に
オンボーディング期間をできるだけ早く終わらせてチームに貢献したい。という気持ちは自分も痛いほど分かります。ただ、長期的にチームへ貢献する上でオンボーディング期間は非常に重要です。
焦ることなく、開発に必要な一連の基礎を過不足なく固めてもらえればと思います。
この記事が、その一助となれば嬉しいです。
最後に、バイセルではエンジニアを随時募集しています。興味のある方はぜひ以下の採用サイトをご覧ください。
https://herp.careers/v1/buyselltech/04-VP5QnJ0aM https://herp.careers/v1/buyselltech/gEErQO6Jho3-
明日のバイセルテクノロジーズ Advent Calendar 2024 は小貫さんの「Whisper のバッチ処理時に生じる文字起こし性能劣化問題の対策と理論的な考察」です。 そちらもぜひ併せて読んでみてください！
