この記事は一休.com Advent Calendar 2023 8日目の記事です。
2023-09-25に入社して2か月半が経ったので、既存のWebサービスの開発にソフトウェアエンジニアとして参加するにあたって役立ったことを書いておく。
『Webサービスのソフトウェアエンジニアとしての転職活動で役立ったこと』の続編といえるかもしれない。
前提
- レストラン予約のサービスの開発に参加した
- 歴史が長い（2006〜）
- Webアプリケーションを開発する
- 技術スタックは転職前後で完全に変わった
- 前: Rails, PHP, Nuxt, MySQLなど7年
- 後: Rust, Next.js, Python, Microsoft系技術（SQL Serverなど）1
観点
『知らないWebアプリケーションの開発に途中からJOINしたとき、どこから切り込むか？』というスライドでは
- どのようなサービスか
- どのようなアーキテクチャか
- どのようにデータを保持するか
- どのような開発環境か
- どのようなコードか
という観点で、新たに参加したプロジェクトで開発を始めるために何が必要かを論じている。
加えて、次のような観点も結果的には必要だった。
- どのように「未知の未知」を減らすか
- どのようにチームは開発を進めているか
これらをもとに、今回は次の観点でやってみて役立ったことを挙げる。
- どのようなサービスかを調べる
- どのようにデータを保持するかを調べる
- どのようなコードかを調べる
- 「未知の未知」をできるだけ早く減らす
- チームの開発体制に興味を持つ
どのようなサービスかを調べる
プロダクトには、解決すべき問題が属する業務ドメインがある。そこで、まずその業務についてざっくり知っておくと、自分が担当するプロダクト以外も含むサービス全体のアーキテクチャを把握するときや、仕事の会話でキーワードが出てきたときに理解を早められる。
また、インセプションデッキで得られる情報のように、ある程度高い抽象度でプロダクトが解決したいことを把握しておくと、自分のやっていることが結局なににつながるのかというのが腹落ちしやすい。
宿泊予約サービスもやっている会社なので、入社前は宿泊が絡む業界に関する本も読んだ。
![図解入門業界研究 最新旅行業界の動向とカラクリがよ～くわかる本 [第5版]](https://m.media-amazon.com/images/I/51kVDPqHhvL._SL500_.jpg "図解入門業界研究 最新旅行業界の動向とカラクリがよ～くわかる本 [第5版]")
![図解入門業界研究 最新ホテル業界の動向とカラクリがよ～くわかる本 [第4版]](https://m.media-amazon.com/images/I/51f2NytOtrL._SL500_.jpg "図解入門業界研究 最新ホテル業界の動向とカラクリがよ～くわかる本 [第4版]")
航空業界との連携によって古くから基幹システムが導入されていたりとか、サイトコントローラというサービスで複数チャネルからの予約を管理する仕組みができあがっているというのがおもしろポイント。サイトコントローラは飲食店予約の業界でも存在する。また、部屋という総数が減らせない在庫を捌くためにダイナミックプライシングが発達しているというのも普通のECとちょっと違うところ。
一方、肝心の飲食店予約の業務知識については世の中にあんまり出回っていない。これについては、入社後にわからんとインターネットで発言していたらCTOに見つかり、結果として飲食店予約の取り扱いからお店で利用する台帳まで、さらに今後の事業戦略などいろいろと社内で教えていただけたので助かった。知りたい人は入社してください。
どのようにデータを保持するかを調べる
システムがどのようにデータを持っているかは、これまでアプリが何度かリプレースされても同じデータ構造を保ってきたという点で重要。かつ、アプリから生成されるデータがプロダクト開発上早めに知っておくべきものたちなので、アプリからのデータの使い方とデータのライフサイクルを突き合わせて理解していく。
参加したサービスでは、店舗の方がオペレーションするための管理システムも提供している。その管理システムをテスト環境で操作しながらデータベースのドキュメントを読むことで、各画面で生成されるデータの構造とその意味についておおまかに把握していった。また、店舗の方に提供する網羅性の高いマニュアルがあるので、そのマニュアル上のガイドを読みつつ操作することで、自分で操作しているだけだと気づかない細かい仕様とそれに関連するデータベース上のデータについても理解を深められた。
この作業で各テーブルのデータについて理解を深めたうえで、アプリケーションのコードを読んでデータをどのように生成、参照、変更しているかもあわせて把握することで、データのライフサイクルの中盤から後半、つまり変更や（論理）削除についても理解を深めていった。
それなりに規模が大きいデータベースでまだまだ全体像を把握しているとは言えないものの、普段の開発に必要なデータについてはこの方法である程度目星がつけられるようになった。
どのようなコードかを調べる
前提で述べたとおり、今回の転職で技術スタックがすっかり変わっている。そんな中でもある程度早く成果を出したいので、とくに最初の段階ではコードベースで読むところを絞った。深くコードベースを理解するためのコードリーディングもまた重要だが、今回は割愛する。
まず、開発タスクを進めるにあたって変更する必要がある箇所のエントリポイントを探す。リクエストがどのように各モジュールを通ってコアのビジネスロジックにたどり着くかを読む。そのうえで、変更が必要な主要モジュールに限定して、それらは自分の言葉で説明できるぐらい理解を深めるようにした。また、同じ箇所を変更している過去のプルリクエストをgit blameで探して、最初のモチベーションを調べたりするのも理解につながりやすかった。
そのほか、コードベースの多くを書いた人が近くにいるなら、設計思想を聞くのがよい。これは次の「未知の未知」にもつながる。
「未知の未知」をできるだけ早く減らす
"A Philosophy of Software Design"の2.2節では"unknown unknowns"がソフトウェアの複雑さの中で一番厄介であり、減らす必要があるという話があった。
一方で、実際は「未知の未知」が初めのうちは数多くあるので、その解決は優先度高めでやる必要がある。
今回だと、初めて取り組んだ大きめのタスクを進めるには、5年以上前の開発の歴史を調べる必要があった。自分やチーム内で見ても進捗しないものだったので、チーム外のシステムの歴史に詳しいエンジニアの方にインタビューする会をささっと企画していろいろ伺うことで、ふつうに調べていたらわからないシステムの挙動に関する話が聞けた。結果、その後の開発方針の決定や進行が楽になった。
また、転職で技術スタックやコードベースが変わったことによって、現状はコードを書くうえで知らないことが多いと実感している。詳しい人からすると、私のプルリクエストはプロダクトの都合で必要な変更が足りない箇所や、もっと適切なメソッドやマクロを使える箇所があったりするかもしれない。そんななかでフィードバックサイクルを早めるために、一通りやりたいことをコードとして書いた時点で早めにドラフトのプルリクエストにして、作業の透明性を上げて早めにコメントをもらえるようにすることで、未知の未知を減らす機会を増やしている。
チームの開発体制に興味を持つ
エンジニアとして転職して開発に参加すると、どうしても技術的な課題解決で頭の中がいっぱいになる。その一方で、チームとしての開発体制がどうなっているかを見ておくと、結果として自分のタスクもスムーズに流せるようになるかもしれない。
まず、あらためて会議の話をちゃんと（！）聞いて、自分がわかっていないことやチーム内外の関心事をいかに把握するかが大事な気がしている。最近は出社したときのミーティングで（議事メモを取ったり何かを確認する必要がないときは）ラップトップを閉じて、能動的に聞く状況に追い込んだりしている。また、抑制的な傾向があるので、素朴な質問をちゃんとすることを最近は意識している。
そのうえで、チームの状況に合わせて、開発プロジェクトを進めるうえで手伝えるところは手伝うようにしている。たとえば、カンバンの運用、ストーリーの切り出し、計画づくりのための規模の相対見積りの導入、プロジェクト管理ツール運用のサポートなどを、アジャイルプラクティスの文脈を補足しつつやっている。開発ペースを予測可能にしてタスクのフロー効率を上げることで、結果として自分含め開発者の満足度を上げたい気持ちでやっている。また、フロー効率が向上すれば毎スプリントのインクリメントが生まれる確率が上がるので、ステークホルダーも嬉しいはず。
このあたりの領域でそれなりに動けるのは、アジャイル事業部がある会社の出身者や関係者が同僚に多くいた過去が影響しているのでラッキーだったと思う。
所感
オンボーディングにおけるアンチパターンの記事が話題だったので、最近オンボードした人間の視点での工夫を書いてみた。実際、オンボーディングの準備をする側も大変な現場が多いと思うので、双方とも楽になる方法を考えていきたい。他にいい方法があれば教えてください。
