株式会社アンドパッドの白土慧と申します。OSSなどではkei-sで活動しています。アンドパッドではリアーキテクティングチームに所属し、チームの立ち上げから携わっています。リアーキテクティングチームの活動を簡単に紹介すると、アンドパッドにある大規模なRailsアプリケーションを、コードや構造も含めて、もっと拡張しやすくて、開発者が使いやすく、ミスの防止などもできるようにする活動をしています。今回のRuby/Railsのアップデートも取りまとめているほか、チームのスコープにはマイクロサービスやモジュラーモノリスなどへの移行の検討も含まれます。<h3 id="hee53e05de9">アンドパッドでのRailsの役割</h3>アンドパッドにある大規模なRailsアプリケーションをもう少し掘り下げます。このアプリケーションは「ANDPAD施工管理」や「ANDPAD黒板」、「ANDPAD検査」などのアプリ向けのAPIサーバーであり、ブラウザレスポンスも返しています。他の製品ではGoも使って開発していますが、アンドパッドではこのRailsアプリケーションが最も歴史があります。それだけに大規模で、モデルだけで20万行はあります。私の開発経験上でも一番の規模です。この中で、コード品質を上げる取り組みとして、例えばRuboCopを使った検査や写真といったデータの持ち方などを整理しています。<h2 id="hd26e0f350d">アンドパッドがRuby/Railsを最新に保つ理由</h2>では、本題に入りましょう。まず現在のバージョンを申し上げると、Railsは、ほぼ最新の7.0系で、さらに近々アップデート予定です。一方でRubyはつい先週に最新の3.2.2にアップデートしたばかりです（2023年10月執筆時点）。そして、アンドパッドでは「最新に追従すること=&quot;しょっちゅう&quot;アップデートすること」*を方針としています。その理由をこれから紹介します。*<a href="https://cruel.org/freeware/cathedral.pdf"> 「伽藍とバザール(The Cathedral and the Bazar)」(Eric S. Raymond 著 / 山形 浩生 訳 ©2000 YAMAGATA Hiroo.）</a>の見出し、&quot;はやめのリリース、しょっちゅうリリース&quot;からのインスピレーションです。<h3 id="ha814922afd">大きなジャンプの歴史</h3>読者の皆さまには、これだけの規模だと影響範囲が広く、アップデートしにくいことを察していただけるのではないかと思います。ご多分に漏れず、アンドパッドでもアップデートが停滞し、過去にはジャンプが発生していました。私が入社後に行われたものでは、2022年末から2023年1月にかけてのRubyのバージョンを2.7系から3.0へとアップデートしたことがそれに当たります。そのときは今のリアーキテクティングチームのような専門チームはなく、私のほか数名とSREの有志のチームで行ったため、通常業務とアップデート業務の両方をこなす必要があり、非常に負荷が高い状況になりました。また、本来のアップデート作業以外にも、各製品開発チームすべてが行う動作確認とその確認結果の集約に、とりわけ多くの工数がかかりました。このようにジャンプが発生すると、どうしても工数が膨らみ、各製品チームのロードマップやマイルストーンにも影響を与えます。これはRubyに限らず、Railsでも発生し、誰もが苦労をしていました。<h3 id="h745d6ec3f1">アップデートを止めることは「後退する」と同じ意味</h3>アップデートはいつかはやらないといけません。放っておいても楽になることはなく、スキップすればするほど、後回しにすればするほど、どんどん作業が膨らむだけです。アンドパッドはこれまでのジャンプでそれを痛感しました。フルタイムRubyコミッターとしてアンドパッドに入社したhsbtからも、「世の中のほうが進んでいるので、止まる=後退すると同義である。前に進んでようやく留まっている」というアドバイスもあり、先ほど挙げた「&quot;しょっちゅう&quot;アップデートする」方針に変更しました。小さくアップデートすれば、影響範囲も限定的になり、工数も抑えられます。<h3 id="hbea341950c">ANDPADユーザーにもいい影響がある</h3>&quot;しょっちゅう&quot;アップデートする方針に変更することには、ANDPADユーザーにもメリットがあります。特にRuby3系は3×3構想の通り、レスポンス速度が上がっており、タフな建築・建設現場でのユーザー体験の向上に寄与し、ポジティブな影響を与えられます。話題のYJITもスイッチONで動くことはわかっていますので、これも視野に入れています。もしアップデートが停滞した場合、脆弱性があったとしてもすぐに直せない可能性があり、ANDPADユーザーはもちろん、ビジネスとしてもリスクでしかありません。ANDPADは17万社44万人ものユーザーの毎日の業務を支える大規模SaaSだからこそ、安心して使える環境を用意しなくてはならないため、常に最新にアップデートすることにより、セキュリティも担保しやすくなります。関連して、一般的には、アップデートのような内部品質の向上よりも、外部品質（例えば、ビジネスサイドや経営陣からの新機能開発の要求など）の向上が優先されがちです。しかし、アンドパッドが内部品質向上を専門とするリアーキテクティングチームを組んだことそのものが、ビジネスサイド・経営陣の理解がある証拠であり、また内部品質に投資するだけの体力・体制があるとも言えます。<h2 id="h35a070217c">アップデート体制と進め方の工夫</h2>では、実際にどのようにアップデートを進めているのか、詳しく紹介します。<h3 id="hd94232778f">リアーキテクティングチームが中心</h3>先ほど触れたRuby2.7→3.0へのアップデートでの教訓から、リアーキテクティングチームが進める体制となりました。ただし、他のチームに「アップデートはリアーキテクティングチームの仕事だから、やらなくていいや」と認識されることは本意ではなく、エンジニア全体でやることが理想です。現在はその過渡期にあり、リアーキテクティングチームがその環境整備を進めている段階です。リアーキテクティングチーム主導になったことで、チームはアップデートに集中できるようになり、前回のような高い負荷はありません。また、ジャンプではなく、小さなアップデートにフォーカスしたことで、影響範囲を絞り込めて、自動テストでエラー検知がしやすく、安心してアップデートを進められました。そのほかhsbtからアップデートで影響がありそうな変更やYJITの話、注意点のアドバイスをもらえ、見通しがつけやすくなりました。ただ実際hsbtに手を動かしてもらう場面はなく、アップデート作業そのものはチームですべて完結できました。<h3 id="hf971e18d0c">数週間に及ぶmainブランチを使った開発検証でアップデートを検証</h3>自動テストでアップデートによる非互換が検知されるとはいえ、エッジケースでの分岐や込み入った実データなど、手で触ってみることで自動テストではカバーできない部分の非互換が見つかることも考えられます。このため引き続き、各製品チームの動作確認が必要であり、工数がかかることが予想されました。また、一定期間だけ特定の開発環境を用意→動作確認→OK→マージと進んでも、その期間に新たに追加された機能の動作確認漏れが発生し、エラーが起きる可能性が高まります。そこで社内検証環境の中に、プロダクションと同じmainブランチが動いているものがあり、それを最新のRubyバージョンにして何週間も動かす、ということに取り組みました。日々のプルリクエストなどによる開発の動作確認もその環境で行っているので、何週間にも及ぶ検証の結果、アップデートしても問題がないことがわかりました。この取り組みにより、動作確認の工数が膨らむこともなく、大きなエラーも発生しませんでした。これにはRuby2.7→3.0で取り組んだCI/CD環境などの知見がそのまま活きています。詳しくはアンドパッドのテックブログで紹介していますので、ぜひご覧ください。<a href="https://tech.andpad.co.jp/entry/2023/02/21/100000" target="_blank" rel="noopener noreferrer nofollow">複数チームが開発するモノリシックなサービスにおける、Rubyのバージョンアッププロジェクトの進め方とこのプロジェクトから学んだこと - ANDPAD Tech Blog</a><h2 id="h3a22275536">これからはRuby/Railsアップストリームへのコントリビュートが視野</h2>最後に今後の展望です。今回のRuby3.2.2のアップデートにより、最新の環境になりました。これでhsbtたちRubyコアチームが毎日開発している最新バージョンを取り込み、実験できるようになりました。Nightly Buildを取り込み、テストを動かせば、すぐに問題箇所がわかり、アップストリームへのフィードバックも即座にできます。アンドパッドだけでなくRubyコミュニティにもメリットをもたらせるようになりました。こういうことができるのがフルタイムRubyコミッターを抱える強みの一つです。また、リアーキテクティングにはRailsチームのメンバーにも関わってもらっているので、Railsでも同様のことができます。今後は<a href="https://github.blog/2023-04-06-building-github-with-ruby-and-rails/" target="_blank" rel="noopener noreferrer nofollow">Building GitHub with Ruby and Rails - The GitHub Blog</a>でGitHubが発表したように、アンドパッドはRubyやRailsの改善に積極的に貢献し、ANDPADユーザーの体験向上に還元したいと考えています。編集：中薗昴提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a><hr>著者: 白土 慧 (Shiratsuchi Kei) GitHub:<a href="https://github.com/kei-s"> kei-s </a>ソフトウェアエンジニア。好きな言語はRubyとRust。好きな小説家は舞城王太郎。現在はアンドパッドでRailsアプリケーションの大規模リファクタリングに携わっている。過去にはKaigi on Rails 2022「実践 Rails アソシエーションリファクタリング」などで登壇している。

本コラムでは「株式会社アンドパッド社がなぜ最新のRuby/Railsにこだわるのか？」についてリアーキテクティングチームのkei-sさんがご紹介します。

なぜ、アンドパッドは最新のRuby/Railsにこだわるのか？アップデートを止めないための体制と仕組み

2017年の設立以来、「一人ひとりの時間を豊かに」というビジョンのもと、事業の成長を遂げてきた株式会社タイミー。同社は「働きたい時間」と「働いてほしい時間」をマッチングするスキマバイトサービス「タイミー」を提供しています。「タイミー」は登録ワーカー数が500万人を突破し、利用企業は約46,000社。また、事業開始時は5人だったタイミーの社員数も、2022年には546人に到達。2023年中に1,000人規模を目指しています。急拡大を実現できた裏側には、開発組織において数多くの「スケールする仕組み作り」の工夫がありました。今回はタイミーの執行役員CTOである亀田彗さんに、これまで行ってきた意思決定のなかで、印象に残るものを聞きました。<h2 id="h02df3f285b">モノリシックなRailsアプリとして構築されている「タイミー」</h2>――亀田さんがタイミーで担当されている業務についてまずは教えてください。私がタイミーに参画したのは2019年5月で、会社のフェーズとしてシリーズAの資金調達が終わった頃、アーリー期でした。会社全体で社員が30名、エンジニアが5名くらいの規模でしたね。私は入社してしばらくの間CTOではなくCPOを担い、プロダクトマネジメントの体制を整えていました。当時は「何をどのタイミングでどう作っていくか」についての課題が重要で、それを解決する必要があったためです。2020年からは、開発組織やシステムのアーキテクチャ・品質などの課題を解決することにより注力したいと考え、CTOにロールチェンジしました。タイミーの特徴として「タイミー」という単一プロダクトだけで事業成長をさせてきたことが挙げられます。かなり成長率の高いビジネスを実現できているので、マルチプロダクトでクロスセルなどによって売り上げのトップラインを作るのではなく、スケールしているプロダクトをより大きな幹にしていくことにフォーカスする技術的な意思決定が多いです。また、他にも技術的な特徴として、Ruby on Railsの巨大なモノリシックアプリケーションとして「タイミー」のシステムを構築していることがあります。開発組織が大きくなるなかで、モノリシックなアプリケーションでいかにして開発・運用をうまく進めるかといった方針を考えています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8f80fad6a3ee4cad870e5270c26fa7ad/image2.jpg" alt="" width="1999" height="1334"></figure><h2 id="h0b3149146b">Four Keysを重視。デプロイ頻度は月間約200回</h2>――ここからは過去に取り組んできた技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきたいです。まず、タイミーがこれまで注力してきた施策で、成功したと考えていることからお話しします。タイミーはFour Keys*の指標がすごく良い状況なんですよね。特に良好な数値が出ているのがデプロイの頻度で、調子の良いときは月間約200回程度になっています。*…ソフトウェア開発チームのパフォーマンスを示す4つの指標。「デプロイの頻度」「変更のリードタイム」「変更障害率」「サービス復元時間」から構成される。もちろん、最初からこの体制を実現できていたわけではありません。私が入社して間もない頃は、週次くらいの頻度で手作業のデプロイを行っていました。でも、なるべく細かく頻繁にデプロイするほうが1回あたりの変更の差分も小さくなりますし、問題があった際の検知や切り戻しも容易になります。そこで、デプロイ頻度を高める方針を選びました。最も理想的な状態は、mainブランチにコードがマージされた際にデプロイされることです。しかし、手作業での週次デプロイからいきなりその状態に変えるのは、技術的な変化が大き過ぎて開発組織の混乱が起きてしまうと思いました。そこで、SREのメンバーと一緒に取り組んだのが、まずデプロイをChatOpsに変えることでした。デプロイ対象となるブランチやコミットハッシュなどをSlack上で指示すると、デプロイできる仕組みを構築しました。なぜこれがFour Keysの向上に貢献したかというと、デプロイの頻度を開発者自身がコントロールできるんですよね。ChatOpsを導入して間もない頃はまだ不安も大きいので、「まずは1日1回だけChatOpsでデプロイしよう」といった運用を行います。そこから、慣れてきたら徐々にデプロイ頻度を高めていくことができます。この事例では、開発者たちがデプロイ頻度を段階的に変化させて、ブランチの運用ルールもより良い形に変えていきました。そうして徐々に運用を改善し、2年後くらいには「mainブランチにコードがマージされた際にデプロイ」に切り替えることができました。――この事例を踏まえて、読者の方々に伝えたい学びはありますか？まず、先ほども述べましたが開発者にデプロイの裁量があることは重要です。タイミーではトップダウンでデプロイのルールを決めるのではなく現場に委ねることで、徐々に改善のサイクルが回るようになりました。それから、デプロイ頻度の向上は必ずシステム監視の強化とセットで行うことです。デプロイしたものに不具合があった際に、なるべくすぐに気づけるような体制を構築しています。加えて、タイミーでは初期フェーズからSREのスキルを持った人が各チームにいる状況を実現しています。これにより、障害のアラートが発生した際にSREのスキルを有するメンバーを中心として対応するので、障害発生時のオーナーシップをそのチームが持ってくれるようになるんですよ。そうすることで、デプロイとその後の対応について、特定のチームが責任を持ってフィードバックサイクルを回す仕組みが実現できます。この事例についてまとめると「システムや組織に対して行った投資が、その後のリターンとして返ってくるのか」という観点が重要です。タイミーは単一のプロダクトを扱っており、数年後も必ずそのプロダクトが事業の中核として存在しているはずなので、監視やデプロイの改善に投資をすれば必ずリターンがあるんですよ。やみくもに開発・運用体制の改善を行うのではなくて、「その改善が投資対象として適切かどうか」を考えるほうがいいです。<h2 id="h52290ee2cb">マイクロサービスからモノリシックへの移行</h2>――では、次の事例についても伺います。「タイミー」では事業者とワーカーとがマッチングすると、メッセージを通じてやりとりができます。メッセージ機能をもともとはマイクロサービスとして切り出しており、そのサービスではアカウントの認証やプロフィール情報の保存、メッセージの送受信、既読の有無の管理などを担っていました。サービスの機能の関心を分離することで、「タイミー」のビジネスの全体的なコンテクストをあまり理解していない方でもメッセージ機能を開発できるようにしたい、というモチベーションに基づいてマイクロサービス化をしていたんです。しかし、マイクロサービスとして切り出したことにより複数の課題が発生したため、結果的には「タイミー」の本体側のサービスに取り込んでモノリシックな構造に移行することを決めました。発生した課題の詳細や移行の流れなどは「<a href="https://tech.timee.co.jp/entry/2022/03/01/112239" target="_blank" rel="noopener noreferrer nofollow">マイクロサービスからモノリシックへ。メッセージサーバ移行の道のり</a>」というブログに記載しています。もともと「メッセージ」はサブドメインの領域だったんですが、サービスが成長していくにつれて予想よりもはるかにユースケースが広がったんですよね。それに伴い、たとえば「タイミー」本体のシステムとの連携が複雑になったり、単一機能を提供することを前提とした設計のため追加の開発が困難になったりと、マイクロサービス化したことでいくつも課題が発生していました。――読者のなかにも「自分たちも特定機能をマイクロサービスにしたけれど、課題が発生しておりモノリシックに移行しようか迷っている」という方もいらっしゃると思います。そういった方に伝えたいことはありますか？この課題についても、やはり「その事業ドメインやシステムに対して継続的に投資したいかどうか」が一番大事だと思っています。たとえば、仮に設計面に課題のある機能だったとしても、今後あまりユースケースが広がる見込みのないシステムだとすれば、コストをかけて戻す必要はないという判断になるかもしれません。一方で、その機能で今後多くの拡張が行われることが見えているのならば、できるだけ早く適切なアーキテクチャに移行したほうが、アジリティを向上させやすいと思うんですよね。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/cc5c6121035147c6a250f01875e1f367/image1.jpg" alt="" width="1999" height="1334"></figure><h2 id="heb13b32cf1">ポストモーテム改善のために、CTOを巻き込む</h2>――他の技術的な取り組みとしては何が挙げられますか？タイミーの開発組織では、開発と運用がうまく結合する状態を目指しています。「タイミー 」は事業者とワーカーとのマッチングに加えて労務管理や給与支払いなども行うので、サービスのバリューチェーンが長いです。それらの一連の流れが何かの原因で止まると、ビジネス全体が停止するリスクを抱えています。かつ、「タイミー 」は前年比で募集人数が3倍以上くらいのペースで成長しているプロダクトなので、それに伴って開発や運用の課題も増えていきます。発生している障害や運用の負荷などに真正面から向き合って、課題を継続的に解消していかなければサービスが立ち行かなくなる可能性があるんです。そのための施策として、ポストモーテム*1の実施やトイル*2の洗い出し・手作業の削減などにはかなり力を入れています。*1…システムやサービスで発生した不具合や障害の振り返りを行う事後検証。*2…プロダクションサービスを動作させることに関する業務で、手作業でくり返し行われ、自動化することが可能であり、戦術的に長期的な価値を持たずに作業量がサービスの成長に比例する傾向を持つもの。――ポストモーテムは具体的にどういった運用形態をとっていますか？何かしら顧客に影響があったものは、ほぼすべてポストモーテムを実施しています。そして、ポストモーテムのコンテンツは、不具合や障害への対応が適切にできたかという振り返りと根本解決のための取り組みという2軸に分かれています。タイミーでは「ポストモーテムを行う際には、CTOの私を巻き込んでほしい」とメンバーに伝えています。最近は私が忙しすぎて参加できないケースもありますが、それでも可能な限り参加したいと考えています。それによって何をしたいかというと、障害が起きたことに対する改善のサイクルが、現場レイヤーだけではなくリソースアロケーションの権限を持ったレイヤーでも回るようにしたいんですよね。要するに「障害が起きたらCTOを巻き込んでポストモーテムをしてほしい」と伝えておくと、CTOも徐々に「障害発生の対応にかなり時間を取られているから、対策を行うための人を配置しよう」というモチベーションが起きるんですよね。だから、もしも自社のポストモーテムの改善を行いたいならば、CTOや場合によってはCEOなどを参加させることをおすすめします。<h2 id="haf326eb366">長い時間軸でシステムに携わることで、得られる学びがある</h2>――「タイミー」の開発・運用を通じて得てきた知見が山ほどあるのですね。他にも、いま挑戦中でまだ結果が出ていない取り組みがいくつかあります。具体的には、モジュラモノリス化やマイクロサービス化などを行って、アプリケーションの各機能をより疎結合にして独立的に開発やデプロイ、スケールができないかと検討しているところです。タイミーは開発組織の人数がすごい勢いで増えています。このペースで人が増えていくと、モノリシックなアプリケーションでは徐々に問題が生じてくるはずなんですよね。制約を取り払うために、そろそろサービスを分けていくべき時期だと判断しています。タイミーが扱っている事業ドメインがビジネスとして確実にグロースしていくこと、かつそれがものすごいボリュームであることが見えています。だからこそ、それに適した体制を構築するには、開発プロセスへの投資だけではなく技術的な投資も必要になってきます。モジュラモノリス化やマイクロサービス化もそうですし、最近ではSPA化を完了させました。そういった取り組みを積み重ねていくことで、より良いものづくりができるんだろうなと考えています。――かつてはマイクロサービス化に失敗したけれど、事業としてのフェーズが変わったことでマイクロサービス化に適したタイミングが来たとは。不思議なものですね。最適なアーキテクチャのあり方は、会社や組織の状況に応じて変わりますからね。かつては正解だと思っていたことが時間の経過とともに失敗になることもありますし、その逆もあります。だからこそ、アーキテクチャ設計などに携わる人は、数年単位という長い時間軸で事業やシステムに携わることで、経験から得る学びを最大化できると思います。自分たちの行った技術的な意思決定がその後どのように評価されるのか。成功も失敗も含めて、意思決定をした結果と長いサイクルで向き合うことで、実のある知見を得ることができます。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/96cf3d446dba449aa83b7febd7a2db07/image4.jpg" alt="" width="1999" height="1334"></figure>――たくさんの学びがあるインタビューでした。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？成功事例だけではなく、失敗事例もたくさん学ぶことが大事です。それによって、実行可能性が上がっていくんですよね。エンジニアリングもプロダクトマネジメントも、良いとされている理論・手法は世の中に数多くあります。そして、「その理論・手法を取り入れることでどのような失敗が起こり得るか、それはなぜかという知識を持っていること」と「その理論・手法を自分たちの組織にうまく適用できるかどうか」には密接な関係があります。私自身も、駆け出しのエンジニアだった頃はさまざまな理論や手法を学んで、「これを組織に導入しよう」と行動しては失敗して、ショックを受けていました。でも、数々の事例からエッセンスを学び取っていくことで、より良い技術的な意思決定が徐々にできるようになってきました。そのための学びを得るうえでも、失敗に対する耐性をつけるという意味でも、インタビューやコラムを通じて他の人たちの事例を知ることには価値があると思いますね。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/">株式会社Haul</a>

2017年の設立以来、「一人ひとりの時間を豊かに」というビジョンのもと、事業の成長を遂げてきた株式会社タイミー。今回はタイミーの執行役員CTOである亀田彗さんに、これまで行ってきた意思決定のなかで、印象に残るものを聞きました。

体制構築もアーキテクチャ設計も、“投資”の観点が重要。タイミーCTOに「スケールする仕組み作り」を学ぶ

DIGGLE株式会社でエンジニアリングマネージャーをしている岡崎と申します。普段はエンジニアチーム全体のマネジメントを担いつつ、開発業務も行っています。DIGGLEは予実管理クラウドサービス「<a href="https://diggle.jp/" target="_blank" rel="noopener noreferrer nofollow">DIGGLE（ディグル）</a>」を提供するスタートアップであり、「<a href="https://rubykaigi.org/2023/" target="_blank" rel="noopener noreferrer nofollow">RubyKaigi 2023</a>」の<a href="https://rubykaigi.org/2023/sponsors/#sponsor-498" target="_blank" rel="noopener noreferrer nofollow">スポンサー</a>を担うなどテクノロジーやそのコミュニティへの投資を積極的に行っています。本記事ではDIGGLEのエンジニアチームが、どのように技術的負債解消を行っているかについてご紹介します。<h2 id="h48ed43c917">工数の何%を負債解消に充てるかを四半期ごとに経営と合意する</h2>技術的負債解消は、エンジニアチーム単体でやり切るにも限界があり、経営陣の理解を得ることが重要です。弊社はCTOが共同創業者であるため、エンジニアの意見が経営陣へダイレクトに届き、経営陣の技術に対する理解度が非常に高いのが特徴となっています。CTOから技術的負債がビジネスに及ぼす影響を経営陣に説明することで、技術的負債解消の重要性を経営陣も理解し、技術的負債解消に対して一定の工数を割くことができる状態になっています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/90021b12fa5c4ad2b95ae2b93b342a63/image4.jpg" alt="" width="1920" height="1290"><figcaption>CTOがProductチームと経営陣のハブとなっている</figcaption></figure>実際にどの程度の工数を割くかについては、四半期ごとに、私とCTOで技術的負債解消に割り当てられる工数の目安を相談して決めています（おおよそ20%程度に収まることが多いです）。このような仕組みにすることで、技術的負債を会社全体の関心事として捉え対応することが可能となり、「日々の作業が忙しくて技術的負債解消を行うことができない」という状態に陥らないようにしています。実際に、技術的負債解消の中で解決した問題を弊社のエンジニアブログで取り上げていますのでご紹介します。<a href="https://diggle.engineer/entry/fixed-issue-railsapp-caused-by-updating-ruby31-to-ruby32" target="_blank" rel="noopener noreferrer nofollow">Ruby のバージョンを 3.1 系から 3.2 系にアップデートしたら Ruby on Rails アプリの動きが変わったのを解決した話</a>DIGGLEでは経営陣に技術に対する理解があるためこうした体制を実現できていますが、読者の中には「なかなか経営陣に技術的負債解消の重要性を理解してもらえない」という環境の方もいらっしゃるかもしれません。その場合は、臨機応変に可能な限り権限が高い方（CTO、部長、リーダーなど）と技術的負債解消の重要性を共有し、組織やチームで継続的に技術的負債に対応できるように働きかけていくことから始めると良いと思います。そして、技術的負債の解消により得た実績（工数が削減した、バグが減少したなど）を収集することで、技術的負債解消がどのような好影響を与えたかを定量的に測れる仕組みを作ることが肝要となります。そうして計測した数値を基に、経営陣と根気強く対話をし、ゆくゆくは会社全体で技術的負債に立ち向かえる環境にしていきましょう。参考までに、弊社で計測している数値をご紹介します。弊社では以下の数値などを四半期ごとに計測し、CTOを含む開発チーム全体で状況を共有する仕組みを作っています。<ul><li>どの作業にどのくらいの工数が掛かったか（新規機能開発 / 既存機能改善 / 技術的負債解消 など）</li><li>本番環境でどのようなバグが発生したのか（インシデント / デザイン崩れ / 軽微なバグ など）</li><li>上記のバグ対応でどのくらいの工数が掛かったか</li></ul><h2 id="h374361b6fc">開発作業の終わりにリファクタリングを行う文化</h2>弊社のエンジニアチームには、開発作業が終わったタイミングでリファクタリングを行う文化があります。これは私が社員3人目として入社した2019年当時から存在しているのですが、開発作業が終わってPull Requestを投げる前に、リファクタリング用のタスクを切って、コードの整理やテストコードのバリエーション追加などの対応を各エンジニアの裁量で行う文化です。これにより、常日頃から各エンジニアが個人レベルで意識を持って作業し、「そもそも技術的負債がたまりにくい土壌」が作られています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b13cf930af924a2a8cbdcef3f932f86e/image8.jpg" alt="" width="1417" height="643"></figure><h2 id="hfea3fe6791">TODOやFIXMEを放置しない仕組み</h2>エンジニアの皆さんは共感してくださると思うのですが、ついつい書いておきたくなってしまうTODOやFIXMEは、時間が経って数が多くなってくると以下のような問題が起こります。<ul><li>多過ぎてどこから手をつけてよいかわからず、結局放置する</li><li>時間が経ち過ぎて、書いた本人すらどんな内容だったかを覚えていない</li><li>コメント量が少なくて、そもそも何に対するTODO / FIXMEなのかがわからない</li></ul>弊社では、これらの解決策として「TODOやFIXMEを書く場合はJIRAにタスクとして挙げ、TODOコメントにはJIRAのリンクを記載する」というルールを作っています。これにより、先ほどの問題点は以下のように解決することができます。<ul><li>多過ぎてどこから手をつけてよいかわからず、結局放置する→常日頃使っているJIRA上でタスクとして確認することが可能になる</li><li>時間が経ち過ぎて、書いた本人すらどんな内容だったかを覚えていない</li><li>コメント量が少なくて、そもそも何に対するTODO / FIXMEなのかがわからない→JIRAの本文に背景・内容を記載することで把握ができる→バックログリファインメントで新規JIRAタスクを確認する際に、背景・内容が理解できるものになっているかチェックすることができる</li></ul>上記運用に際して、Pull Requestレビュー時に目視でチェックすることは難しいため、TODOやFIXMEにJIRAリンクを付けていないとエラーになるようにCIを組んでいます。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/fa06a9c72c4042138f0afb4a685dce92/image5.png" alt="" width="1207" height="218"></figure>参考までにrubocopのソースコードを添付します。<pre><code class="language-ruby">class TodoComment &lt; RuboCop::Cop::Base
 include RuboCop::Cop::RangeHelp

 MESSAGE = &apos;Annotation comment, with keyword `%&lt;keyword&gt;s`, should have JIRA TASK (ex: DEV-N).&apos;.freeze

 def on_new_investigation
 processed_source.comments.each_with_index do |comment, index|
 next unless first_comment_line?(processed_source.comments, index) ||
 inline_comment?(comment)
 annotation = RuboCop::Cop::AnnotationComment.new(comment, keywords)
 next unless annotation.annotation?
 next if jira_task?(annotation)

 register_offense(annotation)
 end
 end

 private

 def register_offense(annotation)
 range = annotation_range(annotation)
 add_offense(range, message: format(MESSAGE, keyword: annotation.keyword))
 end

 def first_comment_line?(comments, index)
 index.zero? || comments[index - 1].loc.line &lt; comments[index].loc.line - 1
 end

 def inline_comment?(comment)
 !comment_line?(comment.loc.expression.source_line)
 end

 def annotation_range(annotation)
 range_between(*annotation.bounds)
 end

 def jira_task?(annotation)
 annotation.comment.text.match?(/DEV-\d+/)
 end

 def keywords
 %w[TODO FIXME]
 end
end</code></pre><h2 id="h92a239a3a7">ライブラリのアップデートを、SaaSを使って自動で行う</h2>弊社プロダクトは主にRuby on RailsとReactで構成しているのですが、gemやnpmなどのアップデートは<a href="https://depfu.com/" target="_blank" rel="noopener noreferrer nofollow">depfu</a>というサービスを使って、自動でPull Requestを作成する仕組みにしています。depfuで作成されたPull Requestについては、逐次対応するのは大変なので（後述のセキュリティアップデートは異なります）、3カ月に1回、エンジニアチーム全体で分担してdepfuが作成したPull Requestの確認と、必要に応じた修正をしています。セキュリティアップデートについては、即対応が求められるものとなりますので、毎朝Slackに通知を飛ばします。アップデートがある場合は、デイリースクラムで担当者を割り当てて即日中にリリースするような仕組みとなっています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8f995f55d8f143b2b0aec5cd37ef86f6/image7.jpg" alt="" width="565" height="225"><figcaption>Slack上でのセキュリティアップデートの通知キャプチャ</figcaption></figure><h2 id="h447e0f8f3a">OSのミドルウェアアップデートは週次で自動実行する</h2>次にサーバーのOSミドルウェアのアップデートについてですが、弊社ではAWS Fargateを利用し、Docker imageを使ってリリースしていますので、Docker image内でのライブラリアップデートをどのように行っているかについてご説明します。各サーバーが利用しているDocker imageに関しては、CIにより週次でライブラリのアップデートを行っており、各エンジニアが意識することなく、日々のデプロイを行うタイミングで最新のライブラリが自動適用されるようになっています（もちろん、試験環境で動作検証を実施してからリリースを行っています）。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/009be8374642472984c853378494c3c4/image2.png" alt="" width="1067" height="674"><figcaption>週次でDocker imageを更新しているGithub Actionの図</figcaption></figure><h2 id="h27325700b4">バグやSlow Queryを自動検知する</h2>弊社では<a href="https://www.bugsnag.com/" target="_blank" rel="noopener noreferrer nofollow">Bugsnag</a>というサービスを使って、バグが起きた際にSlackへ通知を飛ばす仕組みを作っています。バグについては、営業時間内であれば即時、営業時間外であれば次の営業開始時に確認します。そして、この仕組みに相乗りする形で、Slow QueryについてもBugsnag経由でSlackに通知が飛ぶように設定しているので、同じフローで確認ができるようになっています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b3dd7aa7c2884c3abdcd593a2d983e8d/image6.png" alt="" width="814" height="396"></figure><h2 id="h97864f4768">積極的に自動化やシステム化をする</h2>技術的負債解消に限ったことではありませんが、弊社では、前述したように自動化できるものは積極的に自動化しています。そして、自動化できないものについてもスクリプトを組むなど、なるべく人が行わなくて済むような仕組みを構築することを重要視しています。自動化・スクリプト化する理由としては、工数削減と、ルール化・仕組み化の抑止の2つが挙げられます。<h3 id="h905af46c97">工数削減</h3>こちらは想像しやすいと思いますが、自動化することにより手作業で実施するよりも工数を削減することができます。これにより、エンジニアの対応が必要な技術的負債解消に注力することが可能となります。<h3 id="h2e318cd4ca">ルール化・仕組み化の抑止</h3>定常的に何かをチェックしたり、対応したりする必要があるものについて、手作業で対応を行う場合、チェック表であったり、手順書であったりを作成することになると思います。そういった資料を用いつつ、ルールや仕組みを作って運用していくのですが、1つ2つであれば問題ないものも、数が多くなってくると把握が難しく、窮屈に感じるようになってしまいます。そのため、弊社では可能なものについては自動化・スクリプト化し、ルールや仕組みをなるべく増やさないように心がけています。上記2点の結果として、余分なところに貴重なエンジニアのリソースが割かれてしまうことを抑止できます。効率よく必要な箇所へ工数を注入することができるようになり、それが日々増えていく技術的負債に対する特効薬となります。<h2 id="h3bcda3e6b0">最後に</h2>以上、DIGGLEにおける技術的負債解消方法を、いろいろな切り口でご紹介しました。技術的負債はエンジニアを苦しめる問題であり、技術的負債が多ければ、それだけエンジニアの職場環境は悪いと言えます。そして逆に言えば、技術的負債の解消はエンジニアの職場環境改善の一助となります。この記事が、読んでくださった方の職場環境改善の一助となることを願い、本記事を締めさせていただきます。編集：中薗昴提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

予実管理クラウドサービス「DIGGLE（ディグル）」を提供するスタートアップ企業DIGGLEのエンジニアチームが、どのように技術的負債解消を行っているかについてご紹介します。

「Ruby」の記事一覧