こんにちは、DX 事業本部エンジニアの中嶋（@nyamadorim）です。
私は「イエウール」というプロダクトにおいて、数年前に頓挫した「住所データ更新プロジェクト」の再開に携わりました。この記事ではそうしたプロジェクトで成果を出すために重要だった意思決定と学びについて話します。
やることが大量にありしかも既存事業に大きな影響を与える、そういった頭を抱えるような改修プロジェクトに携わるエンジニアの参考になれば幸いです。
背景
イエウールにおける住所データ
イエウールというプロダクトにおいて住所データはさまざまな場所で利用されています。わかりやすいところでは例えばイエウールのトップページにある次のような入力フォームです。
イエウールでは、一括査定依頼を行う物件住所を「都道府県」「市区町村」「丁目」「字・丁目」の 4 つの階層で入力し、そのエリアを取り扱える不動産会社群に対し一括査定依頼を行うことができます。
また SEO 集客用の「エリアページ」には、いくつかのデータソースから取得した相場情報などが掲載されています。こうしたエリアに紐づく情報は、住所データそのものではありませんが、住所に紐づくデータなので、住所データを更新したときの影響などを考慮する必要があります。
住所データ更新プロジェクト
住所データ更新プロジェクトは、こうしたイエウールの住所データを最新の市区町村統廃合が反映された状態にするプロジェクトです。
プロジェクトは数年前に始まり、比較的新しいプロダクトにおいては最新の住所データに更新できていましたが、歴史の長いプロダクトであるイエウールについては、一度プロジェクトが頓挫して以来、古い住所データのまま残されてきました。
こうした状況に終止符を打つべく、住所マスター更新プロジェクトが去年（2021 年）再開されました。とはいえ十分な時間はなく、次の開発プロジェクトが始まるまでの 2 ヶ月間でできるところまで進めることになりました。
結論から言えば、この 2 ヶ月間という限られた時間において、私たちが出しうる最大の成果を残せたと思います。その後、プロジェクトは新卒エンジニアを中心とするチームに引き継がれ、イエウールの住所データの更新が今年の 8 月に無事終わりました。
本記事では、2 ヶ月という限られた期間のなかで最大の成果を出すために重要だったいくつかの意思決定について話します。住所データの更新に限らず、プロダクト全体に影響があるような大きな改修に携わるエンジニアの参考になれば幸いです。
（引き継いだプロジェクトの奮闘記については、22 新卒の黒須くんが明日の AdventCalendar の記事で紹介してくれると思います!）
重要だった意思決定
はじめの 2 週間で準備しきる
2 ヶ月という限られた期間でしたが、最初の 2 週間を準備期間にしました。この 2 週間では、プロジェクトにおいて重要な次の質問に答えることをゴールとしました。
- 住所データが最新化された状態の定義
- 住所データが最新化された状態をどう実現するかの方針、計画、作業規模の見積もり
- この 2 ヶ月間のスコープ
2 週間という時間を作ったことで、その間にさまざまな調査と方針策定ができたため、前述の質問に対し精度の高い答えを出すことができました。
2 ヶ月でできるところまでやる
振り返ると「1. はじめの 2 週間をゴールを定めるための準備期間にする」という意思決定ができたのは、「2 ヶ月間でできるところまでやる」と決めたからでもあります。もし仮に「2 ヶ月間で完全に終わらせる」と最初から決めていれば、はじめの 2 週間を準備期間にあてる意思決定に躊躇したかも知れません。
この点については、プロジェクトの開始を決めたマネージャーのさとーるさんの「できるところまでやってほしい」というキックオフの言葉がとても心強かったと思います。
2 ヶ月間で複雑かつ重要な部分は必ず解決する
「2 ヶ月間でできるところまでやる」ということは、2 ヶ月間でできなかったことを誰かに引き継ぐ必要があります。引き継ぐ候補としては 22 新卒エンジニアを想定していましたが、いくら素晴らしい新卒メンバーであっても、いきなり事業上重要かつ複雑な部分の改修を入社すぐに任せることはリスクがありますし、引き継ぎも大変です。
そこで私たちは、事業上重要かつ複雑な部分をこの 2 ヶ月のなかで必ず解決し、残りの作業は改修作業が明確なものだけが残るように 2 ヶ月間の優先順位を決定しました。これによって、2 ヶ月間で改修する事業上重要な箇所について、時間をかけて万全の体制で改修することができました1。
既存のコードはできるだけ書き換えない
これまでの住所更新プロジェクトでは、住所の更新のために多くのコードを書き換えていました。具体的には次のどちらかで住所更新を実現していました。
- API 方式: アプリケーションを住所マイクロサービスの呼び出しコードに書き換える
- gem 方式: アプリケーションを住所情報を同梱した内製 gem の呼び出しコードに書き換える
しかし、コードの書き換える量が増えるとそれだけ不具合を誘発するリスクがあります。特にイエウールの場合は、歴史が長くコード規模が大きいため、コードの書き換えによる不具合のリスクが他の新しいプロダクトよりも大きくなります。加えてイエウールは、歴史的経緯から Ruby だけでなく Java で書かれたシステムが一部残っているため、Ruby で通用したコードの書き換えがそのまま Java に適用できないことも懸念としてありました。
そこで私たちは「既存コードをできるだけ書き換えない」という方針を最初に定めました。イエウールの開発者との議論を経て、最終的にはこれまでの住所更新プロジェクトで試みられなかった「既存の住所モデルに対して新しい住所レコードを登録する」という方式を選択しました。
この方針によって、コードの書き換えがまったくなくなるわけではありませんが、住所データ更新のためのコードの書き換えを最小限に抑えることができますし2、同時に既存の「API 方式」「gem 方式」が抱えていたパフォーマンス悪化の問題やアプリケーションのテーブルと SQL で JOIN できないなどの問題を解決することができました。
漠然とコードリーディングするのではなく、事業ドメイン知識から書き換えるべき領域を見立てる
「既存コードをできるだけ書き換えない」という方針であっても、ある程度アプリケーションを書き換える必要はあったので、その箇所を絞りこむ必要がありました。
そこで、住所データがどの領域でよく使われているかをざっくり掴み、書き換えるべきコードの領域を見立てることにしました3。具体的にはアプリケーションの主要なディレクトリごとに住所データを使うコード（city や town といった文字列が含まれるもの）が何行あるかを調べたり、ドメイン知識から書き換えるべきコードの領域を特定することにしました。
結果、書き換えるべき領域は toC 向けに公開しているページやフォーム部分と一部の集計バッチだけであり、それ以外の箇所は書き換えが不要か、別プロジェクトに引き継げると判断できました4。
学び
冒頭の通り、2 ヶ月のプロジェクトが終わった後、プロジェクトは新卒エンジニアを中心とするチームに引き継がれ、今年 8 月に住所データの更新が完了しました。
2 ヶ月間でおこなった意思決定についてはここまでで書いたとおりですが、もう少し抽象化して学びをまとめてみたいと思います。
目的を持って準備期間を設けることでプロジェクトの成功確度が上がる
こうしたプロダクト全体に渡る改修プロジェクトでは、わかりやすい How 先行でタスクを着手した結果、途中で根本的な方針に疑問が生じて迷いが生じたり、気合で頑張った結果、成果が出ずにプロジェクトが頓挫することがしばしばあります。おそらく過去に頓挫した住所更新プロジェクトもこのパターンだったと思います。
今回のプロジェクトでは、はじめから準備期間を設け、準備期間を終えたときのゴール状態をチーム内外に明確に示すことにしました。その結果、チームが安心して調査に集中することができたため、住所更新のための方針を精度高く出すことができました。
目的に整合した明確な方針を立てることでチームの速度が上がる
プロジェクトの随所で目的に整合した明確な方針を設定することができたことも、プロジェクトの成功において重要だったと思います。
プロジェクトの目的はただ一つ「イエウールの住所データの最新化」です。この目的に対して、例えば「既存コードをできるだけ書き換えない」という方針を設定しましたが、これは目的達成に沿ったシンプルでよい方針だったと思います。まだ何もわからないプロジェクトの開始時点であっても「既存コードをできるだけ書き換えない」という方針には、作業量を圧縮でき目的の達成を近づくイメージが湧きますし（障害のリスクも最小化できる）、具体的な手法に縛られていないので、学習が進んだプロジェクトの中盤でもブレることはありませんでした。
プロジェクトのどの段階においてもぶれない方針によって、チームの迷いを減らし、結果としてチームのスピードを早めることに寄与できました。
前例を鵜呑みにせずよりよい方法をフラットに模索する
私たちは、これまで試みられなかった「既存の住所テーブルに対して新しい住所レコードを登録する」という方式で住所更新を実現しましたが、2 ヶ月間という限られた時間のなかでは、普通ならこれまでの実績を踏まえて既存手法を踏襲したほうが短期的には楽ですし、他のプロダクトと足並みも揃います。
しかし、そうせずに各方式をフラットに比較検討したことで、プロジェクト達成の実現可能性を高め、既存方式の問題点を明らかにすることができました。また、比較検討した結果を社内の Kibela 記事に残したことで、プロジェクトが終了したあとも開発組織全体でよりよい手法を選択する流れを作ることができました。
こうした動きがきっかけとなり、イエウールの開発組織ではアーキテクチャ、設計、技術選定などの重要な意思決定の際に ADR（Architectural Decision Records）5を書く習慣が広がりました。
不確実な状況を目的思考で突破できるチームだからこそ成功できた
プロジェクトで成果を出す上で、チームの仲間が自律して目的達成のボトルネックを見つけ解決していけることが重要でした。そうでないといつまでもプロジェクトの不確実性を下がらず、目的の達成に近づけないからです。今回のように難易度の高いプロジェクトには、そうした振る舞いをチームで促せるような強みのもつ仲間を組成できると非常に心強いと思います。
結び
この記事では、一度頓挫したイエウールの住所データ更新プロジェクトを成功させるうえで重要だった意思決定とそれらを通して得た学びについて紹介しました。
このプロジェクトを終えてから 1 年経ちますが、今なお良かったプロジェクトだと胸を張って言えますし、マネージャーともこの記事を書いているときにそういう話をしました。このプロジェクトはイエウールの開発組織にとって重要な資産になったと思います。
やることが大量にありしかも既存の事業に大きな影響を与える、そういった頭を抱えるようなプロジェクトに携わるエンジニアにとってこの記事が参考になれば幸いです。
Speee では一緒にサービス開発を推進してくれる仲間を大募集中です!
こちらのフォームよりカジュアル面談も気軽にお申し込みいただけます!
Speee は様々なポジションを募集しています。 「どんなポジションがあるの？」と気になってくれてた方は、こちらをチェックしてみてください! もちろんオープンポジション的に上記に限らず積極採用中です。
※この記事は、2022 Speee Advent Calendar 20 日目の記事でした。昨日のたかてぃーの記事も要チェック!
- 主にカバレッジが不足しているテストコードがあればテストケースを補強したり、実装者以外の動作確認などを行いました↩
- ieul.jp の一括査定依頼の入力フォームやページには統廃合後の新住所だけを出したいが、過去の問い合わせ情報に含まれる住所については統廃合があったとしても旧住所のまま残すなど、ユースケースに応じて住所を出し分けが必要だったためいくつかのコードの書き換えが必要でした↩
-
最初は住所データを使うコード（
cityやtownといった文字列が含まれるもの）を grep し、該当したものを愚直に読んでいましたが、しばらくするとそのコード量が辛くなってきました。そもそも grep では前後の文脈を読みきれないため、本当に書き換えるべきコードなのかが判断できませんし、人間はこうした単純作業に向いていません↩ - 細かいことですが、コントローラーのネームスペースが ToC 向け、ToB 向け、社内向けときっちり分けられていたのは調査する上でかなり助かりました↩
- ADR はアーキテクチャ、設計、技術選定などの重要な意思決定の際に、意思決定のプロセス（背景、課題、意思決定の際に洗い出された選択肢、それらの比較など）と結果（何に決めたか、それによるトレードオフなど）を記録するドキュメントです。ADR を書くことで、課題解決にふさわしい意思決定をチームで促すことができます。また、過去の ADR を参考に将来発生する重要な意思決定を支援することができます。↩
