こんにちは、大河原です。情報システム部サービス開発チームにて、Linkers.net の開発チームリーダーをしています。
このたび、私は10/22金-23土に開催されたKaigi on Rails 2021 にて、「Railsバージョンを倍にしたサービスのそれまでとそれから」というタイトルで登壇いたしました。
発表に至る経緯と反響
本発表では、Linkers.net が技術的負債を積まざるを得ない状況から、3年がかりのリファクタリングプロジェクトを経て、技術的負債を返済し続けるチームになるまでを語っています。
本発表の内容は、Linkers.netが歩んできた歴史そのものです。しかし、そのぶん社外に出しづらい内容を多分に含んでおり、公開に慎重にならざるを得ないものでもありました。
CfPを書いた私もその点は承知していましたが、
- サービスの成長を止めることなく、
- 大規模なリファクタリングプロジェクトを成功に導き、
- その後も安定して技術的負債を解消し続けている
というチームの歩みを語ることで、技術的負債に納得しつつも苦しみながら仕事をしている、当時の我々のような方々へ強力な事例を提供できると思い、応募へと踏み切りました。
発表にはTwitter上を中心に予想を上回る反響がありました。
また、発表後のQAや懇親会では、自社の技術的負債の状況を（もちろん話せる範囲で）興奮気味に話して下さった方が複数いました。 発表で話した内容を振り返りながら、経営判断と開発現場にどうしても距離が生じてしまうことの難しさや、アプリケーションアーキテクチャと開発組織の構造の関係などについて議論できました。
これらを通じて、届けたかった状況にいる方々へ実際に事例が届いた実感があり、発表した意味が大いにあったと思える時間でした。
普段お世話になっているコミュニティへの貢献ができて、この上なく嬉しく思います。
スライド
スライドはこちらです。
尺の都合で盛り込めなかった話
発表内で「技術的負債は機能負債とコード負債に分けられる」という話をしました。
それに続けて、
- 機能負債を余計に作り込まない方法
- 機能負債を継続的に解消する方法
- コード負債を継続的に解消する方法
をお話ししたわけですが、「コード負債を余計に作り込まない方法」がなかったのにお気付きでしょうか。
こちらは尺の都合で泣く泣くカットした部分でした。
コード負債を余計に作り込まない方法とは、ずばり「コードレビュー」です。
これ自体は広く行われていることですが、Linkers.net 開発チームでは少し変わっていて、以下のような体制でレビューを行っています。
- チームが「コミッター」「レビュアー」の2つに分かれている
- コミッターは、ドメイン知識に特に詳しいメンバー3名
- レビュアーはそれ以外のメンバー。オンボーディングタスクが終わったらすぐ参加する
- Merge Request1を作成した開発者が「レビュアーガチャ」2を回し、レビュアーがランダムにアサインされる
- レビュアーによるレビューが完了したら「コミッターガチャ」を回し、コミッターがランダムにアサインされる
- レビュアー/コミッター指名や忙しい時の回し直しはOK
- コミッターによるレビューが完了したらマージされる
- 軽微なものは、開発者の判断でレビュアーによるマージOKとしてガチャを回す
要は、ダブルチェックするレビュー体制です。この体制を取ることで、レビューが持つ役割である
- バグ・実装漏れの検出して修正
- 設計の軌道修正
- 網羅性の乏しいテストの検出
- 影響範囲やエッジケースの考慮漏れ検出と要件定義の見直し
を手厚く行い、不具合または負債になりうるコードがマージされるのをなるべく防ぎます。
また、ダブルチェックすることでドメイン知識の浸透がやりやすいというメリットもあります。
Linkers.net では、入ったばかりのメンバーにも早い段階でレビューに参加してもらうようにしています。これによって、コミッターを命綱にすることで気負いすぎることなく様々なコードを見てもらい、ドメイン知識を素早く吸収してもらいます。
これは技術的負債とは一見関係ないようですが、「ドメイン知識の不足した開発者による実装」が大きな要因となるコード負債の発生を防ぐのに役立ちます。
この体制には「開発からリリースまで時間がかかる」という大きなデメリットがあります。
しかし、「バグによる緊急対応や技術的負債の蓄積による開発速度の低下を、ある程度先取りした上でコントロール可能にしている」という見方もできるため、本チームでは大きな問題にはなっていません。
もちろん、これは競合よりもいち早く新機能を出し続けなければ利益のでないレッドオーシャンの業界にいたり、Product Market Fitがまだ見いだせていない創業期だったり、とにかく機能を速くリリースしないといけない状況では使えない手法なので、その点は注意してください。
この内容も最初は発表に盛り込むつもりだったのですが、施策としてはあまり目を引くものではなかったため「整地タスク」を優先し、ボツになってしまいました。
チームを2つに分けてのダブルチェック体制、よろしければご検討ください。
イベントについて
私は昨年のKaigi on Railsにも一参加者として参加していましたが、今年のKaigi on Railsは2日間開催になっただけでなく、様々な面でのパワーアップを感じました。
トーク群はスピーカーの皆さんが日々現場で向き合っている課題から生まれたもので、公式サイトの「コンセプト」にある通り「明日からの仕事に役立つ」内容が満載でした。
また、スポンサーブース/QA会場となっていたreBakoではオフラインのカンファレンスでしていたような
- 話し込んでいるうちにトークが始まってしまい、そのまま話し続けてしまう
- 初対面の人と技術をフックにお話しする
- 久しぶりに会う方と近況報告をする
などの体験ができ、チーフオーガナイザーの大倉さんがおっしゃっていた「Kaigi感」を存分に楽しむことができました。
それから、最後のRafael França氏のkeynoteを観終わったあとは青春映画を1本見たかのような感覚に陥り、思わず涙腺が緩みました。
総じて、学ぶ場としても、楽しむ場としても、素晴らしいイベントでした。
これだけのイベントの開催には、様々な方が並々ならぬ準備を重ねられたことと思います。
今年は「トークにおける事例の提供」という形での貢献になりましたが、来年以降もまた何らかの形で貢献できたらと思います。
改めて、スタッフの皆様、他のスピーカーの皆様、スポンサーの皆様、参加者の皆様、お疲れ様でございました。
謝辞
本発表を無事行えたのは、貴重な時間を割いてインタビューに応じて下さった前CTOのSさんやリファクタリングプロジェクトをリードしたIさん、今では目も当てられないような初稿の段階から何度もレビューしてくださった上司、リスクとなりかねない内容ながらも外に出すことを許して下さった経営陣、ブラッシュアップの段階で様々な意見を提供してくれた同僚、そしておふたりの技術顧問のおかげです。
また、なによりスタッフの皆様のおかげで、本発表は「Kaigi on Rails」という素晴らしい場を得ることができました。
皆様にこの場を借りてお礼を申し上げます。
We're Hiring!!
発表の中でもお話した通り、リンカーズではWebアプリケーション開発チームのエンジニアおよびエンジニアリングマネージャーを募集しています。
我々はビジネスマッチングを通じて新たな産業構造を創造し、日本のものづくりを変えていくという野望をいだいて日々仕事をしています。
共感いただける方は、採用情報 よりご応募ください。
