こんにちは、技術本部 Mobile Application グループの山名です。
早いもので今年も残すところ僅かになってきました。
そういえば大学時代のこの時期は、新卒採用が本格的に始まってそわそわしていたなあと懐かしい気持ちになっている今日この頃です。
そんな新卒2年目の自分ですが、入社して感じたのは良くも悪くも選考時に抱いていたイメージとは大きく違うなということです。
特に開発プロセスは実際にフルタイムでプロパーとして働いてみないと分からないことも多いため、人によっては思わぬミスマッチが起きることもあります。
とはいえ、それを確かめるために数カ月の就業インターンに飛び込むのもハードルが高いので、知りたくても難しいのが実情ではないでしょうか。
そこで今回は、六捨七入すればまだ新卒1年目の自分が『いちエンジニア視点で見る、Sansan iOS アプリの新機能をリリースするまでの道のり』についてお話しします。
リリースまでに何をするのか、どういった人と関わるのか、Sansan ならではの楽しさといった深いところまで解説していきますので、ぜひ最後までご覧ください。
※ 以降で出てくる『Sansan』は、会社全体ではなく、プロダクトの Sansan を扱う組織のことを指します。
リリースまでの道のり
まず全体像をお伝えしますと、リリースまでの道のりは以下のステップで舗装されています。
- 新機能の企画
- 開発の承認
- 開発計画の作成
- 開発
- 品質検証
- リリース
これだけ見るとよくあるソフトウェア開発の工程なので、以下で各ステップについて掘り下げていきます。
新機能の企画
企画の段階ではプロダクトマネージャ（PdM）、デザイナー、データ分析チームが主体となり、リリースしたい機能を発案します。発案に際してはアプリの各種数値分析、仮説の立案と検証、モックアップを用いたユーザへのヒアリングなどが行われます。
これだけ聞くとエンジニアがやることはなさそうに思えますが、そうではありません。
機能の性質にもよりますが、主に以下の関わり方をします。
- プロトタイピング・技術検証
- 機能や体験へのフィードバック
- 技術選定
まずプロトタイピング・技術検証についてです。
開発に入ってから手戻りや開発取りやめにならないよう、体験として成立するのかや、現実的な工数で実現できるのかについて検証を行います。
アーキテクトが請け負うことが多いですが、リソース状況によっては我々メンバーが手伝うこともあります。
企画段階なので PDCA のスピードが速く、開発フェーズにはない楽しさがあります。
次に機能や体験へのフィードバックです。
Sansan では機能開発に際して専用の Slack チャンネルが作られるので、自発的に入って様子を伺い、気になったことを聞いたり意見したりできます。
また隔週で PdM と雑談する機会があり、企画中の機能や検討中の体験について話してもらえるので、そこでも議論できます。
実際に上記の場で出た案が採用されることもあるので、自分のようなプロダクトにも関心を持ちたいエンジニアにとっては大変ありがたい機会です。
最後に技術選定ですが、これはプロセスとして存在する訳ではなく、自分が意識していることです。
現状のアプリにない体験ならどうやって実装するのか、既にある体験でも UI や設計をより良くするためにはどうしたら良いかを考えます。
Sansan には補助が出るランチもくもく会や、技術研鑽といって特定の曜日に好きな勉強ができる制度があるため、そういった機会を活用して行っています。
最近だと既存の機能を Compositional Layout で置き換えてみたり、Mirror を使って struct から分析ログを自動生成したりしました。
技術研鑽については Android チームが資料を出しているので、詳しく知りたい方はそちらをご覧ください。
開発の承認
企画がある程度固まると、次は開発の承認を得ることになります。
手順としてはプロダクトに関わる全エンジニアが参加可能な場で PdM が企画を発表し、質疑応答を行います。
最終的な判断をするのは部長ですが、エンジニアからも多くの質問が出ます。
背景の深掘り、要件を満たす際に発生する技術的な課題、既存機能との兼ね合いなどさまざまです。
その過程で開発に着手するには時期尚早だと判断されれば差し戻され、上がった課題を解決して後日再度臨むことになります。
実際承認を得るのはかなり大変で、差し戻されることは日常茶飯事、場合によってはそもそも企画が消滅するなんてこともあります。
ただ、だからこそハードルを超えた案件は質の高いものばかりですし、作り手側に拒否権を与えることで納得した上で開発に臨めるので、非常に良いプロセスだと感じています（とか言ってますが自分はこんな高いハードルを超えられる気がしないので、企画側の人には尊敬の念しかないです）。
エンジニアの関わり方としては上記で述べた通りで、企画に磨きをかけるために質疑応答するのが仕事になります。
自分のような若輩者でも発言できる空気感なので、企画段階と同様にプロダクトにも関心を持ちたいエンジニアにとっては大変ありがたい機会です。
またプラットフォーム横断で開催されるため、普段開発できない Web 側の知識を付けるきっかけになり、聞き専でも非常に有用な場となっています。
開発計画の作成
開発の承認が下りたのでいよいよ開発チーム側がメインとなって動き始めます。
チームに開発できるリソースがある場合、承認された企画がアサインされ、まずは計画を立てます。
機能によっては大々的にプレスリリースを打つこともあるので、きちんと責任を持ちつつ、安全に倒しすぎないという難しい塩梅を求められます。
手順としてはプロジェクトリードがタスクの洗い出し & 見積もり、ガントチャートの作成を行い、チーム内で合意を取り、アーキテクトのレビューが通れば完成です。
アーキテクトのレビューではタスクに過不足がないかを要件と技術の二面から見られます。
特に技術面に関しては実装前の設計でも見られますが、計画段階でコードの品質に関わりそうな箇所（例：単なる機能追加では見通しが悪くなるため、既存機能を含めたリアーキテクチャを行う必要がある）が判明していれば、あらかじめ計画に含めるようにします。
下記の記事でも書きましたが、計画段階できちんとリファクタリングをタスクとして積むことで技術的負債を返済できているのは、弊チームの良いところだと感じています。
エンジニアとしての関わりですが、このフェーズではそんなにありません。
理由はこのフェーズはプロジェクトリードの仕事が主だからです。
見積もられたタスクに抜け漏れや違和感がないか、作成されたガントチャートに無理がないかなどを確認する程度になります。
余談ですが、弊チームでは手を挙げればプロジェクトリードをやらせてもらえます。
基本的にはチームリーダが請け負うのですが、プロセスとして役職の制約がある訳ではないので、メンバーが望めば移譲が可能です。
ですので、自分のようなモノ作りにエンジニアリング以外の面からも貢献したいタイプにとっては非常にありがたい環境です。
実際やってみるとリーダーシップを取ること、プロジェクトマネジメント、チーム外とのコミュニケーション、アーキテクトと設計について議論する機会など、いろいろと貴重な経験を積むことができるので、裁量があるって良いことだなあと感じています。
開発
計画が完成すると、ようやくエンジニアの本分？である開発に入ります。
開発で取り組むことは主に以下の3つです。
- 設計
- 実装
- 仕様調整
設計
まず設計に関してですが、計画段階で洗い出したタスクの具体化や、UML を用いた議論を行います。
Sansan くらい歴史が長く規模も大きいアプリだと、変更が思わぬところに影響して手戻りが発生したり、ただ変更するだけだとコードの見通しが悪くなるのでリアーキテクチャが必要になったりすることがよくあります。
そのため、計画段階で見積もった工数が小さい場合や、実現方法にあまり議論の余地がない場合を除き、基本的に設計してから実装に入ります。
UML を書く際はプロダクトの今後を知るために PdM や機能が先行している Web 側のエンジニアとコミュニケーションを取る必要があり、書いた後もアーキテクトと何回も議論を重ねることになるので中々大変ですが、その分学ぶことも多く非常に楽しいフェーズです。
実装
次に実装に関してですが、Sansan では Pull Request に2人以上の Approve がつかないとマージできないため、いろいろと考えることが多いです。
速さだけを追い求めれば指摘が沢山ついて急がば回れになってしまうし、かといって質を高めることだけを考えるとリリース計画に影響してきます。
また自分や他メンバーのタスクに依存すると並列数が上げられないのでタスク同士をなるべく疎にしたり、PR のレビューが早く終わるよう分かりやすい説明を書いたり、コミットの粒度を調整したり 、PR を分割したりと、タスク単位でも QCD を意識して進める必要があります。
そんなただ実装するだけでは上手くいかないところがチーム開発の面白さでもあるので、日々楽しみながら開発しています。
仕様調整
最後に仕様調整に関してですが、開発を進める過程で考慮漏れや、実際に触ってみるともっと良くできそうな箇所が見つかってくるので、それらを調整します。
対応によってリリース計画に影響が出るか、出てもやりたいのか、Android との兼ね合いはどうするかなど、ここでも QCD を意識して進める必要があります。
余談ですが、この仕様調整の提案が開発側からも結構な数出てくるのが Sansan の好きなところです。
企画や承認の段階と同様に、開発側が作るものに対して納得感を得るための場が用意されていて、それがきちんと活用される文化が形成されているのは素晴らしいことだなと思います。
品質検証
開発が終わったら、リリース前に成果物の品質を検証します。
検証は PdM・デザイナー・開発側、および QA (Quality Assurance) によって行われます。
PdM・デザイナー・開発側による検証
まず PdM・デザイナー・開発側による検証についてですが、他プラットフォーム（Android・API）のメンバーも交えて各々の観点でテスト用のアプリをチェックします。
観点としては PdM とデザイナーは要件を満たす体験になっているか、API チームはパフォーマンスに懸念がなさそうか、Android チームは意図せぬ仕様差分がないかなどがあげられます。
そこで課題が見つかれば修正して後日再度確認し、QA による検証に進みます。
入社して1年半程度経ちましたが、毎回 PdM・デザイナーの思い描いた通りのものができているか不安で、いまだにこの場に臨む時は緊張しまくりです…
ただ、だからこそ期待通りかそれ以上のものを出せた時は達成感もひとしおなので、エンジニアをやっていて良かったなと思える瞬間でもあります。
QA による検証
次に QA による検証についてですが、いわゆる結合テストにあたるもので、QA 側で企画時の資料を元にテスト項目が作成され、実行されます。
エンジニアとしてはテスト項目の精査と発覚したバグ修正が主な仕事ですが、円滑な進行のためにはいろいろと工夫する必要があります。
例えばテスト項目作成時に質問がきそうなところを先んじてプロダクト側と調整しておいたり、テスト項目を最新に保つために仕様変更を忘れずに伝えたり、複数端末 & OS で繰り返しテストが実行できるようデータ調整用のデバッグ動線を作成したりなどがあげられます。
余談ですが、Sansan の QA はめちゃくちゃ優秀で本当にいつも助けてもらってばかりです。
特定の端末や OS でだけ発生するようなマイナーなバグを発見してくれるのは日常茶飯事ですし、先日は Web 側の事情に詳しいメンバーが非常に限定的なテスト項目の追加を提案してくれて、実際にそこにバグが見つかるなど、本当に感度も精度も高くて頭が上がりません（ちなみに、当時の自分はそんなところバグらへんから流石にいらんやろ…とか思っていましたごめんなさい）。
リリース
品質検証も終わり、待ちに待ったリリースの時間です。
主な仕事は App Store のボタンを押すだけですが、個人的に好きなのが社内向けリリースノートの投稿です。
多くの人からお祝いのリアクションをもらえますし、スレッドでも役員やビジネス職の方々から待ち望んでいた旨のコメントが寄せられます。
品質検証でのプロダクト側へのお披露目会と同様に、自分の作ったものが喜ばれている様子を見ると、エンジニアをやっていて良かったなと感じます。
おまけ：リリース後のイベント
リリースが完了して晴れてお仕事終了…ではなく、実はその後も以下のイベントがありますので、おまけとして軽く紹介させてもらいます。
- 新規クラッシュの監視
- KPI の監視
- 振り返り
新規クラッシュの監視
品質検証には力を入れていますが、どうしてもリリースしてみないと分からないバグはあります。
本番データ特有の違い、ユーザの動作環境によるもの、膨大なリクエスト時のパフォーマンスなど、さまざまです。
そういった障害にいち早く気づけるよう、Sansan では日次のクラッシュチェックを実施しているのですが、新機能がリリースされた後は特に注視するようにしています。
またライブラリアップデートや新規 iOS バージョンへの対応といった全ユーザに影響が見込まれる内容に関しては、段階リリースを活用するなどの対策も取っています。
KPI の監視
機能はリリースして終わりではなく、きちんと仮説通りの効果が出ているかを確認する必要があります。
Sansan では企画段階で効果を判断するための KPI を設定し、実装段階でそれを測るための分析ログを仕込みます。
仕込んだログの結果は1カ月に一度 PdM によって開催される KPI 報告会で開発側に共有され、KPI の達成状況に加えて結果の考察や今後の展望について質疑応答が行われます。
また開発者が自発的にログを閲覧することもできるので、自分はリリースした機能のログを見て、ここはこうした方が良かったのかな〜みたいなことを考えていたりします。
Sansan は多くの人に使ってもらえるのでそれ自体も嬉しいですが、十分なユーザ数があるからこそ有意な分析ができたりもするので、貴重な経験ができてありがたいです。
振り返り
プロダクト側からの要求レベルは日々上がっていくので、それに耐えうる状態を作るため、開発側は常に改善のサイクルを回していく必要があります。
そのために、振り返りを通して前の開発時より QCD を上げるためにはどうするか？を考えます。
ただ、記憶や感情に頼りすぎると建設的な議論にならないので、さまざまなデータを集めてその結果を元に議論するようにしています。
具体的には以下のような議題があがります。
- 見積もったタスクの予実、理由、改善策
- 以下がどれくらい、何故発生して、どうすればなくせそうか
- 追加・削除された仕様
- 結合テストで見つかったバグ
- Android との仕様差分
- コードレビューが白熱して後続タスクが滞った箇所
また振り返った結果はパブリックな場に置かれるので、他チームの結果を見て自チームの改善に活かすこともあります。
他チームには自チームにない文化や慣習があることが多く、思わぬ突破口が見つかることもあるので、大変ありがたいです。
おわりに
以上、『いちエンジニア視点で見る、Sansan iOS アプリの新機能をリリースするまでの道のり』でした。
改めて言語化してみると実装以外にも沢山の機会や仕事があり、それらに参加できる裁量があるのは非常に恵まれた環境だなと感じました。
とはいえ自分はまだまだ未熟者でそれらを全うしきれていないなとも感じているので、引き続き精進していきたいと思います。
最後に次回の予告をさせてもらいます。
実は最近の Sansan iOS チームでは今回でいう開発のフェーズを大きく変えようとしています。
チームの統廃合や属人性の排除、正確なベロシティの計測など目的はいろいろありますが、ちょうどよく大型案件も降ってきたので、その中で理想像を模索中です。
そこで次回の記事では、現状の組織やプロセスに感じていた課題、それらを解決するための試行錯誤の過程、実際に大規模案件で運用してみて得られた知見などについてお話ししようと思います。
ご期待ください。
それでは、最後まで読んでいただきありがとうございました！
