<p>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のエンジニアチームが、どのように技術的負債解消を行っているかについてご紹介します。</p><h2 id="h48ed43c917"><strong>工数の何%を負債解消に充てるかを四半期ごとに経営と合意する</strong></h2><p>技術的負債解消は、エンジニアチーム単体でやり切るにも限界があり、経営陣の理解を得ることが重要です。弊社はCTOが共同創業者であるため、エンジニアの意見が経営陣へダイレクトに届き、経営陣の技術に対する理解度が非常に高いのが特徴となっています。CTOから技術的負債がビジネスに及ぼす影響を経営陣に説明することで、技術的負債解消の重要性を経営陣も理解し、技術的負債解消に対して一定の工数を割くことができる状態になっています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/90021b12fa5c4ad2b95ae2b93b342a63/image4.jpg" alt="" width="1920" height="1290"><figcaption>CTOがProductチームと経営陣のハブとなっている</figcaption></figure><p>実際にどの程度の工数を割くかについては、四半期ごとに、私とCTOで技術的負債解消に割り当てられる工数の目安を相談して決めています（おおよそ20%程度に収まることが多いです）。</p><p>このような仕組みにすることで、技術的負債を会社全体の関心事として捉え対応することが可能となり、「日々の作業が忙しくて技術的負債解消を行うことができない」という状態に陥らないようにしています。</p><p>実際に、技術的負債解消の中で解決した問題を弊社のエンジニアブログで取り上げていますのでご紹介します。</p><p><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></p><p>DIGGLEでは経営陣に技術に対する理解があるためこうした体制を実現できていますが、読者の中には「なかなか経営陣に技術的負債解消の重要性を理解してもらえない」という環境の方もいらっしゃるかもしれません。</p><p>その場合は、臨機応変に可能な限り権限が高い方（CTO、部長、リーダーなど）と技術的負債解消の重要性を共有し、組織やチームで継続的に技術的負債に対応できるように働きかけていくことから始めると良いと思います。</p><p>そして、技術的負債の解消により得た実績（工数が削減した、バグが減少したなど）を収集することで、技術的負債解消がどのような好影響を与えたかを定量的に測れる仕組みを作ることが肝要となります。そうして計測した数値を基に、経営陣と根気強く対話をし、ゆくゆくは会社全体で技術的負債に立ち向かえる環境にしていきましょう。</p><p>参考までに、弊社で計測している数値をご紹介します。弊社では以下の数値などを四半期ごとに計測し、CTOを含む開発チーム全体で状況を共有する仕組みを作っています。</p><ul><li>どの作業にどのくらいの工数が掛かったか（新規機能開発 / 既存機能改善 / 技術的負債解消 など）</li><li>本番環境でどのようなバグが発生したのか（インシデント / デザイン崩れ / 軽微なバグ など）</li><li>上記のバグ対応でどのくらいの工数が掛かったか</li></ul><h2 id="h374361b6fc"><strong>開発作業の終わりにリファクタリングを行う文化</strong></h2><p>弊社のエンジニアチームには、開発作業が終わったタイミングでリファクタリングを行う文化があります。</p><p>これは私が社員3人目として入社した2019年当時から存在しているのですが、開発作業が終わってPull Requestを投げる前に、リファクタリング用のタスクを切って、コードの整理やテストコードのバリエーション追加などの対応を各エンジニアの裁量で行う文化です。</p><p>これにより、常日頃から各エンジニアが個人レベルで意識を持って作業し、「そもそも技術的負債がたまりにくい土壌」が作られています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b13cf930af924a2a8cbdcef3f932f86e/image8.jpg" alt="" width="1417" height="643"></figure><h2 id="hfea3fe6791"><strong>TODOやFIXMEを放置しない仕組み</strong></h2><p>エンジニアの皆さんは共感してくださると思うのですが、ついつい書いておきたくなってしまうTODOやFIXMEは、時間が経って数が多くなってくると以下のような問題が起こります。</p><ul><li>多過ぎてどこから手をつけてよいかわからず、結局放置する</li><li>時間が経ち過ぎて、書いた本人すらどんな内容だったかを覚えていない</li><li>コメント量が少なくて、そもそも何に対するTODO / FIXMEなのかがわからない</li></ul><p>弊社では、これらの解決策として「TODOやFIXMEを書く場合はJIRAにタスクとして挙げ、TODOコメントにはJIRAのリンクを記載する」というルールを作っています。これにより、先ほどの問題点は以下のように解決することができます。</p><ul><li>多過ぎてどこから手をつけてよいかわからず、結局放置する<p>→常日頃使っているJIRA上でタスクとして確認することが可能になる</p></li><li>時間が経ち過ぎて、書いた本人すらどんな内容だったかを覚えていない</li><li>コメント量が少なくて、そもそも何に対するTODO / FIXMEなのかがわからない<p>→JIRAの本文に背景・内容を記載することで把握ができる</p><p>→バックログリファインメントで新規JIRAタスクを確認する際に、背景・内容が理解できるものになっているかチェックすることができる</p></li></ul><p>上記運用に際して、Pull Requestレビュー時に目視でチェックすることは難しいため、TODOやFIXMEにJIRAリンクを付けていないとエラーになるようにCIを組んでいます。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/fa06a9c72c4042138f0afb4a685dce92/image5.png" alt="" width="1207" height="218"></figure><p>参考までにrubocopのソースコードを添付します。</p><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"><strong>ライブラリのアップデートを、SaaSを使って自動で行う</strong></h2><p>弊社プロダクトは主にRuby on RailsとReactで構成しているのですが、gemやnpmなどのアップデートは<a href="https://depfu.com/" target="_blank" rel="noopener noreferrer nofollow">depfu</a>というサービスを使って、自動でPull Requestを作成する仕組みにしています。</p><p>depfuで作成されたPull Requestについては、逐次対応するのは大変なので（後述のセキュリティアップデートは異なります）、3カ月に1回、エンジニアチーム全体で分担してdepfuが作成したPull Requestの確認と、必要に応じた修正をしています。</p><p>セキュリティアップデートについては、即対応が求められるものとなりますので、毎朝Slackに通知を飛ばします。アップデートがある場合は、デイリースクラムで担当者を割り当てて即日中にリリースするような仕組みとなっています。</p><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"><strong>OSのミドルウェアアップデートは週次で自動実行する</strong></h2><p>次にサーバーのOSミドルウェアのアップデートについてですが、弊社ではAWS Fargateを利用し、Docker imageを使ってリリースしていますので、Docker image内でのライブラリアップデートをどのように行っているかについてご説明します。</p><p>各サーバーが利用しているDocker imageに関しては、CIにより週次でライブラリのアップデートを行っており、各エンジニアが意識することなく、日々のデプロイを行うタイミングで最新のライブラリが自動適用されるようになっています（もちろん、試験環境で動作検証を実施してからリリースを行っています）。</p><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"><strong>バグやSlow Queryを自動検知する</strong></h2><p>弊社では<a href="https://www.bugsnag.com/" target="_blank" rel="noopener noreferrer nofollow">Bugsnag</a>というサービスを使って、バグが起きた際にSlackへ通知を飛ばす仕組みを作っています。バグについては、営業時間内であれば即時、営業時間外であれば次の営業開始時に確認します。そして、この仕組みに相乗りする形で、Slow QueryについてもBugsnag経由でSlackに通知が飛ぶように設定しているので、同じフローで確認ができるようになっています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b3dd7aa7c2884c3abdcd593a2d983e8d/image6.png" alt="" width="814" height="396"></figure><h2 id="h97864f4768"><strong>積極的に自動化やシステム化をする</strong></h2><p>技術的負債解消に限ったことではありませんが、弊社では、前述したように自動化できるものは積極的に自動化しています。そして、自動化できないものについてもスクリプトを組むなど、なるべく人が行わなくて済むような仕組みを構築することを重要視しています。</p><p>自動化・スクリプト化する理由としては、工数削減と、ルール化・仕組み化の抑止の2つが挙げられます。</p><h3 id="h905af46c97"><strong>工数削減</strong></h3><p>こちらは想像しやすいと思いますが、自動化することにより手作業で実施するよりも工数を削減することができます。これにより、エンジニアの対応が必要な技術的負債解消に注力することが可能となります。</p><h3 id="h2e318cd4ca"><strong>ルール化・仕組み化の抑止</strong></h3><p>定常的に何かをチェックしたり、対応したりする必要があるものについて、手作業で対応を行う場合、チェック表であったり、手順書であったりを作成することになると思います。そういった資料を用いつつ、ルールや仕組みを作って運用していくのですが、1つ2つであれば問題ないものも、数が多くなってくると把握が難しく、窮屈に感じるようになってしまいます。</p><p>そのため、弊社では可能なものについては自動化・スクリプト化し、ルールや仕組みをなるべく増やさないように心がけています。</p><p>上記2点の結果として、余分なところに貴重なエンジニアのリソースが割かれてしまうことを抑止できます。効率よく必要な箇所へ工数を注入することができるようになり、それが日々増えていく技術的負債に対する特効薬となります。</p><h2 id="h3bcda3e6b0"><strong>最後に</strong></h2><p>以上、DIGGLEにおける技術的負債解消方法を、いろいろな切り口でご紹介しました。</p><p>技術的負債はエンジニアを苦しめる問題であり、技術的負債が多ければ、それだけエンジニアの職場環境は悪いと言えます。そして逆に言えば、技術的負債の解消はエンジニアの職場環境改善の一助となります。</p><p>この記事が、読んでくださった方の職場環境改善の一助となることを願い、本記事を締めさせていただきます。</p><p></p><p>編集：中薗昴</p><p>提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a></p>

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

技術的負債の解消のためには、“経営層との合意形成”が不可欠。DIGGLE社に学ぶ開発体制構築の秘訣

<p><a href="https://corp.moneyforward.com/" target="_blank" rel="noopener noreferrer nofollow">株式会社マネーフォワード</a>のCTO室副室長の松本と申します。主にデータエンジニアのチームのマネジメントを担当しています。本記事では執筆時点（2023年8月）のマネーフォワード内のデータ分析における業務やアーキテクチャについて説明します。</p><h2 id="h3e48e533b6">事業紹介</h2><p>より具体的なイメージを持っていただくために、マネーフォワードはどのような事業を行っているかについてまずは説明します。法人向け・個人向け・金融機関向けという3つの事業領域を定義しており、法人向けは事業者の経理や人事労務などの作業効率化のためのバックオフィスSaaSの提供、個人向けは家計簿・資産管理アプリなどのPFMサービス、金融機関向けでは、金融機関の顧客への業務DXサービスやコンサルティングサービスなどを提供しています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5ddcd75d6b1048c2a122b3bd7eae0536/image1.png" alt="" width="1462" height="655"><figcaption>「2023年11月期第2四半期決算説明資料」より抜粋。グラフは2023年11月期第2四半期累計売上高に占める内訳。</figcaption></figure><p>IR資料にもある通り、法人向け領域は売り上げの多くを占めており、特にデータ活用の社内ニーズも高まっている領域です。エンジニアチームも注力領域として日々改善を続けています。そのような背景から、本記事では法人向け領域でのデータ活用を中心に記載しています。</p><h2 id="hed5e2f5a5c">データ分析のワークロード</h2><p>続いてデータ分析におけるワークロードについてです。データ分析のための業務と一口に言ってもさまざまな技術要素や知識が組み合わさって構成されています。生産性や専門性の観点から3つのプロセスに大別し、それぞれに業務プロセスや開発フローを定義し運用しています。</p><h3 id="h2cd7571313">1.データ収集</h3><p>1つ目はデータ収集プロセスです。データ分析に利用されるデータはプロダクトのデータベースだけではなく、利用しているSaaS・広告関連などのツール・行動ログなど多岐にわたります。通常これらのデータは1カ所に集約されていることはないため収集する仕組みを新たに構築する必要があり、収集する際には収集元の仕様やセキュリティ強度を理解した上で設計することが求められます。マネーフォワードのデータ分析環境は利用者が差異を意識せずに分析ができるよう連携先ごとに異なる仕様を吸収するために、スクラッチの仕組みやツールなどを組み合わせて構築しています。</p><h3 id="h14d5d243b1">2.データロード</h3><p>2つ目はデータロードのプロセスです。こちらもユースケースによって同じデータソースに対してもさまざまな処理要求があります。用途によってリアルタイムに近いデータが必要である場合や、日次レポートや月次集計処理などの場合はそれぞれのタイミングに合わせる形でよいケースもあります。全てのデータを一律に処理すると仕組み上はシンプルですが、キャパシティやコストなどの問題を抱えることになるため、データロードにおいても異なった要件に対応できるよう複数の仕組みを用意しています。</p><h3 id="hb3d85062bf">3.データ利用・分析</h3><p>3つ目は実際のデータ利用・分析のユースケースになります。データ収集とデータロードの工程を経て利用可能となったデータを用いて事業KPI管理のためのダッシュボードを構築したり、マーケティング施策の改善などビジネスのためにデータを活用したりすることなどが主な用途ですが、特別定額給付金が家計消費に与える影響に関する研究論文に利用された事例もあります。</p><h2 id="hfd97687f98">アーキテクチャ構成と設計意図</h2><p>上記を実現するためのアーキテクチャについて解説します。データの連携元としては代表的なものとしてRDB・SaaS・行動ログ・広告データの4つがあり、それぞれについて説明します。</p><h3 id="hf8fcd0af10">多数のプロダクトから迅速にデータを集めるために</h3><p>まずRDBとの連携ですが、マネーフォワードでは日々新たなプロダクトが生まれており、それぞれのチームが独立して意思決定を行い構築・運用しています。一方でデータ分析はさまざまな軸で行われるためシームレスに利用可能なことが求められます。それらを実現するために複数あるRDBのデータ変更をキャプチャし、集約した後に各環境へ配布するという方式をとっています。</p><p>直接的にデータロードをすることも可能ですが、一度同じ形式に変換する方式をとることにより、新規プロダクトの仕様差分を抽象化して分析可能なデータのデリバリー速度を向上させています。現状はこの方式に落ち着いているのですが、元々はそれぞれのプロダクトごとにデータ分析のパイプラインや環境が存在しており、開発や管理も煩雑な状態でした。そのため数年かけて集約に取り組みました。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/1d7c21c81d024a95aa9eee41c82ae7ab/image2.jpg" alt="" width="1920" height="1112"></figure><p>SaaSとのデータ連携においてボトルネックになりやすいのが仕様変更時の対応です。マネーフォワード内では業務効率化やビジネス成長を目的として各部署でさまざまなSaaSの導入検討や活用が進んでいます。一方でSaaSはそれぞれの仕様があり、安定して分析用途のデータを提供するためにはそれらの仕様変更に追随し続ける必要があります。</p><p>これらに対しては外部のETLツールを積極的に利用することで、社内のエンジニアがSaaSの個別仕様への追随を意識せずに済むようにしています。行動ログ・広告データもSaaSと同じく外部ソースなので、仕様変更を吸収するために外部のツールを利用しています。</p><p>一方で、ツールでは実現できない要件であるケースも多々あります。その場合は独自の実装をするケースがありますが、マネージドサービスと比較して技術面での負債化やメンテナンスコストの増大につながる懸念が大きいため、一定期間で再評価して継続すべきか否かの判断を行っています。</p><h3 id="hdc6685d508">安全管理対策としての環境分離</h3><p>またこれらのデータにはさまざまな情報が含まれています。情報の安全管理のために、各項目に情報レベルを定義・分類し、異なる環境へ格納するようにしています（言い換えると情報レベルごとに環境を分断しています）。各環境は参照できる情報が制限されていたり、エクスポートが制限されていたりとレベルに応じた安全対策がそれぞれなされています。</p><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5b2ff1df32ee41cb8a9ca0e5855fd6bd/image4.jpg" alt="" width="1920" height="1262"></figure><p>制約が多い環境は分析体験が悪化するため、分析者は分析の目的によって環境を使い分けています。そして、それぞれの環境に異なったレベルのデータが混入しないように自動で検知するための仕組みを構築し対処しています。</p><h3 id="hf6bbcaf0eb">メタデータの重要性</h3><p>これまでデータそのものの収集に関して説明しましたが、付帯情報（メタデータ）についても同様の課題を抱えています。つまり複数のプロダクトからデータを集約できても、それらのデータが何を意味するのかがわからなければデータとしての価値は低いですし、分析者が分析作業を中断して調査を行うのも合理的ではありません。</p><p>また、先に述べた通りマネーフォワードでは多くのプロダクトを運営しており、それぞれに開発チームが存在しています。つまり、多くの開発チーム・エンジニアが社内にいるということであり、問い合わせ先を確認するのもそれなりの作業量になります。これらの課題に対処するために独自で情報に対してメタデータを登録・更新できる仕組みを構築しています。分析者が一度調べた内容をこの仕組みに登録すれば、他の分析者もそれらの知見を再利用できるようになっています。</p><p>さらに、これらのデータは構成情報のみのため1カ所に集約して管理し、先に述べた各情報レベルの環境へ「配信」するという構成にしています。理由としては将来的には情報レベルのさらなる細分化や、利用技術によって環境を分離する必要が出てくることを想定しているためです（売上集計の業務環境と大規模なモデルを構築する環境では必要な機能・リソースが異なるというようなことを想定しています）。現在は分析者用途ですが将来的にはエンジニアも他プロダクトのメタデータを知りたいというニーズは出てくると考えられるので、エンジニア向けの用途としても想定しています。</p><h2 id="hcbec2bf0d9">終わりに</h2><p>マネーフォワードにおけるデータ分析に関するワークロードとアーキテクチャを紹介しました。最後にこれからデータ分析のアーキテクチャを検討されている方にお伝えしたいことがあります。</p><p>データ分析に関連した業務や職務は細分化し続けています。以前は分析環境といえば専ら分析用データベースがあるという形でしたが、現在ではデータ量が増加し分析手法も多様化して、単一のデータベースでは実現できないユースケースがたくさん出てきています。それらの実現のために多くの機能や複数の環境が求められるように変化してきていると感じています。</p><p>一方で環境の増加はメンテナンスコストや技術的負債の増加を招きます（それらを避けるために機能拡張に消極的になるケースもあります）。これらの最適解を見つけるためには、なるべく多くのステークホルダー・関係者と適切にコミュニケーションをとり、正しい意思決定をし続けることが肝要だと考えています。本記事がみなさまのデータ分析に関する業務の一助となれば幸いです。</p><p></p><p>編集：中薗昴</p><p>提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a></p>

株式会社マネーフォワードのCTO室副室長である松本さんが、同社におけるデータ分析業務の内容やそのアーキテクチャについて解説します。

技術的負債の解消のためには、“経営層との合意形成”が不可欠。DIGGLE社に学ぶ開発体制構築の秘訣

データ連携の運用効率化の秘訣は「中間レイヤの抽象化」にあり。マネーフォワードを支えるデータ分析基盤の知見

ニュースレター購読