はじめに
こんにちは。EventHubの西内です。
前回はEventHubにおけるリリースフローの紹介というタイトルで記事を書かせていただきました。
その際に「リリース後の話」や「開発着手前や着手中の細かい話」を話さないこととして挙げていたので、今回はそのあたりについて触れていければと思います。
また、EventHubではフルサイクルエンジニアを前提とした働き方を推進しており、いわゆる設計や実装およびテストといった一般的な開発業務以外で実際にどのようなことを行っているのかについてもお伝えしていければと思います。
リリース後の話
さて、リリース後の話についてですが、エンジニア採用資料のスライドから引用した図を元にすると”O&M”と”Support”が該当します。
O&M ( Operation & Maintenance )
いわゆる運用保守と呼ばれる活動を指します。組織によっては新規開発とは全く別の管轄になっているところもあるかも知れません。
EventHubだと以下のような活動例が含まれます。
- 障害対応
- インフラの監視や運用
- 各種ライブラリ等のバージョンアップ
障害対応や監視を除けば、これらの対応を行うことが決定したら普段の開発スケジュールに乗ってくるので、特に難しく考える必要はないかと思います。
フルサイクルの文脈で言えば、自分たちで開発したプロダクトに責任を持ち運用することを踏まえて開発する必要がある、ということになります。「責任を持つ」と表現すると、プレッシャーを感じることになるかも知れませんが、その分だけ自由さを手に入れられることにもなると考えています。
たとえば、Aという設計や仕様だと運用が難しくなると思うなら、「A’という設計や仕様にしたい」と提案することができますし、EventHubはそういった提案への理解や尊重をしてくれる組織です。
Support
顧客や社内メンバー向けに、プロダクトに関してサポートする活動のことを指します。
O&Mと同様に活動例を載せると、以下になります。
- 技術的な質問回答や調査
- 不具合報告の一次受け
エンジニアがあらゆるサポートを行うかというとそういうわけではなく、EventHubにはCustomer Support（通称Cサポ）というポジションの方が数名在籍しており、社内外からの問い合わせに対して最初はCサポの方々に回答をしていただいています。そこからさらに技術的な調査や機能に関する詳細な振る舞いについての回答が必要な場合は開発組織に連携が行われます。
そうして連携された内容に関して、週替りの2名体制で対応する仕組みとなっています。
“技術的な質問回答や調査”では、先述の通りCサポだけでは回答が難しい技術的な質問やプロダクトの機能のエッジケースなどについて調査・確認を行い、結果をお伝えしています。
“不具合報告の一次受け”では、報告された内容を精査し不具合の重篤度を判断しています。このことをEventHubでは「バグレベル判定」と呼んでおり、判定のための目安になる定義も存在しています。また、同時に緊急度も判断し、必要に応じてエスカレーションを行うことがあります。
ちなみにこれらのやり取りはそれぞれ専用のSlackチャンネルがあり、Slackのワークフローを使って問い合わせや報告をテンプレートに沿って投稿できるようになっています。
その他
サイクルの図にはないですが他の活動で言えば、リリースした機能がどれぐらい利用されているかを不定期でチェックすることがあります。
このあたりはプロダクトマネジメントの文脈に当たるかとは思うので詳細は省きますが、こういった数値を調べることが顧客理解に繋がることがあると個人的には感じています。
開発着手前や着手中の細かい話
では次の話題に移ります。
前回、自分が記事を投稿したのは2024年の8月末頃でした。つまり、約8ヶ月ほど経過しています。
その間に、いくつかの記事がアドベントカレンダーやテックブログにて投稿されており、それらでも開発着手前や着手中の話について触れられているので、このタイミングで紹介しておきます。
もし良ければ以下の素敵な記事にも目を通していただければと思います！
さて、まずは話の前提を揃えておければと思います。
- ここで扱う”開発”とは？
- お客様の要望に基づくスモールな開発（以下、スモール開発）
- 今後のプロダクト戦略に沿った中・長期規模の開発（以下、エピック開発）
- 開発フローの概要は？
- 要件定義
- 調査(Spike)&設計
- 実装&テスト
- リリース
EventHubではスクラムによるアジャイル開発を用いており、そしてどちらの“開発”についてもほぼ同じ開発フローで進め、規模感や要件に応じて適宜調整を行うイメージです。
スモール開発であれば、事前の調査や設計というフェーズを省いて実装しながら考えるということもありますし、事前にすり合わせてから実装に臨むこともあります。いずれにせよ、スケジュールは短めです。
エピック開発であれば、調査や設計に一定の時間を使うことが多いです。これは実現可能性の調査や後戻りできない（しづらい）設計にならないようにするためとなります。 また、実装とテストを進めていくうちに要件や仕様の調整や提案をエンジニアから持ちかけ、期日/品質/コスト/運用などのバランスを取りつつ、開発を進めていっています。
ここまでの話を聞くと「うちと大体一緒だな」と感じた方もいると思います。そしてその感覚はおそらく正しいと思います。大枠としては、他社と比較して特別な工夫をしているわけではないのかな、と感じています。
そのため、ここからは自分が感じたEventHubにおける開発組織の特徴を挙げる形で「開発着手前や着手中」の様子をお伝えできればと思います。
エンジニアからPdM/デザイナーに提案することがよくある
1つ目はこちら。
タイミングとしては随時発生する可能性があるものなのですが、実装に着手し始めてからが多い気がします。開発が進むにつれて解像度が上がってきたり、UIを実装して動くものが出来てきたりするからかなと思っています。
提案する際の観点としては、より良い機能にするためであったり、実装コストを抑えて素早くリリースするためであったりします。他の観点もあるとは思いますが、最たる例はこの2つだと感じます。
具体例としては、仕様に関して「なぜAという仕様ではなくBなのか」みたいな疑問を感じて質問や相談をすることがあるかと思います。そういった場合にはAやBの仕様のメリットとデメリットを考えたうえで、提案しつつ質問や相談することをEventHubでは推奨しています。
可能であれば提案ベースで話すことを推奨しているので「提案することがよくある」のは至極当然の話ではあるのですが、自分がこれまで在籍した3社と比較しても多いほうなんじゃないかと感じています。
いまやる必要があるのか？の判断軸での議論がよくある
2つ目はこちら。
たとえばPull Requestの内容として、本来のタスクでやりたかったことに加えてリファクタを含んでいたとします。そのリファクタについて「いまやる必要があるかどうか」の軸でレビュイーが意義を説いたりレビュアーが意見したりする、そういった場面を目にすることがあります。
言わずもがなですが、リファクタ自体を否定しているわけではなく、むしろ推奨しているぐらいではあります。しかし、EventHubではそれ以上にタイミングを大事にしているということかなと個人的には感じています。
「リファクタリングをしていてリリースが遅れた」となれば、顧客への価値提供がその分遅れることになります。反対に「今後の開発速度に影響を与えかねないから、いまリファクタリングをする」という判断をすることもあります。
だからこそ”いまやる必要があるのか？”を問う必要があるのだと思っています。
さいごに
けっこう具体例を盛り込んでみたのですが、いかがだったでしょうか。前回同様、開発組織の雰囲気が少しでも伝わっていれば良いなと思います。
あと、リリースフローの紹介というタイトルでしたが「EventHubにおけるフルサイクルエンジニアはどういったことをしているのか？」みたいなタイトルでもあんまり違和感がない話になったな、と書いた内容を振り返ってみて感じました。
…というわけで、ここまで読んでくださりありがとうございました！
いつもの採用情報などを記載しておいて本記事を締めさせていただきます。
