2024 Accelerate State of DevOps Report 概説#3『AIがもたらす変革と課題』

こんにちは。ソフトウェアプロセス改善コーチでFindy Tech Blog編集長の高橋(@Taka_bow)です。

少し時間が空いてしまいましたが、前回の続きです。

tech.findy.co.jp

DORA Reportを正しく読み解くために、前回のブログまでに説明してきたポイントをまとめます。

  1. DORA Report は単なるサーベイの結果ではなく、2014年以降「科学的リサーチ」に基づいて分析されている。
  2. 「科学的リサーチ」の具体な内容は書籍『LeanとDevOpsの科学』で解説されている。
  3. Four Keysを元にしたパフォーマンスレベルは統計的な分析手法(クラスター分析)が用いられ、調査年ごとに変化する。
  4. DORA はこのレポートを用いて、各組織(企業)が独自の実験や仮説を立てることを望んでいる。

これらを念頭にレポートを読み解くことで、より公平で客観的な視点を養うことができると思います。 では、2024年版レポートの具体的な内容とその示唆について詳しく見ていきましょう。今回はDORA Reportの中から、私が個人的に気になったAIに関するトピックを中心にまとめました。

本記事ではv.2024.3をベースに解説します。なお、執筆時点で日本語版はまだリリースされていませんでした。また、正誤表を確認しなるべく最新の情報を参照するように努めました。
DORA Reportのライセンスは次の通りです。
“Accelerate State of DevOps 2024” by Google LLC is licensed under [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/)

なお、DORA Report原文はGoogle Cloudのこちらのページからダウンロードできるので、ぜひ一次情報に触れてみてください。

開発現場におけるAIの浸透

DORAの調査に対する回答者の大多数(81%)が、自社がアプリケーションやサービスへのAIの導入を強化するために優先順位を変えたと報告しています。さらに、49.2%の回答者は、この変化の規模を「中程度」または「大きな変化」と表現しています。

AIの活用範囲は広範囲で【Figure 3. Percentage of respondents relying on AI】によると具体的なタスクごとの活用率は次のようになっています:

Figure 3. Percentage of respondents relying on AI を元に筆者が翻訳

ソフトウェア開発業務におけるAIの最も一般的な使用例はコードの作成と情報の要約であり、これらのタスクを職務に含む回答者のうち、それぞれ74.9%と71.2%が少なくとも一部でAIに依存していると回答しました。

職種別の分析では、データサイエンティストと機械学習スペシャリストで特にAI依存度が高い傾向にありました。一方、ハードウェアエンジニアのAI依存度は最も低くなっています。これは、ハードウェアエンジニアの業務内容がAIの一般的な活用領域と異なる性質を持つためと考えられます。

利用方法としては、

  • チャットボット:78.2%
  • 外部ウェブインターフェース(インターネット):73.9%
  • IDEに組み込まれたAIツール:72.9%
  • 内部ウェブインターフェース(社内イントラ):58.1%

でした。

生産性向上の実態

生産性への影響に対する回答は次の通りでした。

  • 10%が「極端に向上」
  • 25%が「中程度に向上」
  • 40%が「わずかに向上」

「極端」と「中程度」を合わせて、回答者の3分の1以上となっており、AIが開発者の日常業務に実質的な価値を提供していることを裏付けています。

Figure 4: Respondents’ perceptions of AI’s impacts on their productivity. を元に筆者が翻訳

また、職種別にみると次のような傾向が見られるそうです。

生産性向上の程度 職種
高い • セキュリティ専門家
• システム管理者
• フルスタック開発者
低い • モバイル開発者
• サイト信頼性エンジニア
• プロジェクトマネージャー

※他の職種と比較した相対的な評価です

DORAは、開発作業におけるAIの新規性とそれを習得するまでの時間が、開発者のコード作成能力を阻害する可能性があると考えていましたが、調査結果はDORAのこの仮説を支持しませんでした。生成AIについては、それだけ容易に扱えたということなのでしょう。

なお、AIがコード作成能力を阻害したと報告した回答者はわずか5%でした。67%の回答者はAI支援のコーディングツールによってコード作成能力が少なくとも何らかの向上を見せたと報告し、約10%はAIによって「極端な」改善が見られたと述べています。

デリバリーパフォーマンスへの悪影響

DORAにとって予想外の発見もされています。それは、ソフトウェアデリバリーのパフォーマンスへの影響です。DORAはここ数年の調査から、ソフトウェアデリバリーにおける生産性(スループット)と安定性の指標が、互いに独立した動きを示し始めていることが分かってきたのです。

従来、この2つの指標には相関関係があるとされてきました。

しかし、最新のデータは、それぞれが独立した要因として機能していることを示唆しており、個別の評価が必要になってきています。

Figure 10. Impacts of AI adoption on delivery throughput and stability. を元に筆者が翻訳

この調査結果はAI導入がソフトウェアデリバリーパフォーマンスに悪影響を与えていることを示しています。

  • デリバリースループットへの影響は小さいものの、ネガティブな傾向(AI導入が25%増加するごとに推定1.5%の減少)

  • デリバリー安定性への悪影響は大きく、AI導入が25%増加するごとに推定7.2%の減少

この結果に対しDORAは、コード生成AIが「小さなバッチサイズの重要性」を損なっていると分析しています。

過去の調査結果に基づき、AIによる生産性とコード生成速度の根本的なパラダイムシフトが、DORAの最も基本的な原則の一つである「小さなバッチサイズの重要性」を見落とさせている可能性があると仮定しています。 つまり、AIによって同じ時間内により多くのコードを生成できるため、変更リストが大きくなっている可能性があります。DORAの調査では一貫して、大きな変更は遅く、より不安定になりやすいことが示されています。 総合的に見ると、デベロップメントプロセスの改善は、必ずしもソフトウェアデリバリーの改善に直結しないことを示唆しています。少なくとも、小さなバッチサイズや堅牢なテスト機構といった、成功するソフトウェアデリバリーの基本を適切に守らなければなりません。

この問題は、開発作業における認知負荷の観点から理解できます。当社のテックリードは開発パフォーマンス向上について次のように述べています

tech.findy.co.jp

極論ですが、たとえ変更行数が1万行を超えていたとしても、変更内容が一意であれば問題は無いと考えています。

逆に変更行数が20行程度の不具合修正の中に「ついでにリファクタ」した内容が含まれていた場合、粒度が大きいと判断しPull requestを分割すべきなのです。

なぜならば、もし不具合修正に失敗していてrevertしようとした際に、ついでにリファクタした内容もrevertされてしまうからです。こういったケースの場合、リファクタをしたPull requestを別で作成します。

つまり本質はコードの変更行数や変更ファイル数ではなく、変更内容そのものにあるということを理解できたかと思います。

粒度が適切であれば、1行だけの修正でも、1万行の修正でも問題ありません。

10のプルリクを1回レビューするよりも、1のプルリクを10回レビューする方が、作成者、レビュワー共に負担が少ないのです。

コード生成AIは一度に大量のコードを生成できますが、本質的な問題は生成されるコードの量ではなく、認識可能なフィーチャーサイズ、つまりPull requestの粒度にあると考えられます。これがDORAの指摘する「小さなバッチサイズの重要性」の本質なのではないでしょうか。

コード生成AIが書くコードは信頼されにくい?

開発業務で使用されるAI生成コードの信頼性に対する参加者の認識は劣っていました。

大多数の回答者(87.9%)がAI生成コードの品質にある程度の信頼を寄せているとするものの、信頼の程度は全体的に低く「やや信頼」(39.2%)、「少し信頼」(27.3%)または「全く信頼せず」(11.9%)と報告しました。(Figure 5)

Figure 5. Respondents' reported trust in the quality of AI-generated code. を元に筆者が翻訳

開発者がAIを急速に導入し、それに依存し、パフォーマンス向上に貢献すると認識している一方で、AIに対する信頼は薄いということになります。

しかし、興味深いのは、この「不信感」がAIの活用を妨げていないという点です。

開発者たちはAI生成コードを「完璧」なものとしてではなく、「改善が必要な出発点」として捉えている実態が明らかになっています。

以前このようなブログを出しましたが、

tech.findy.co.jp

このブログで紹介した論文では、GitHub Copilotの効果を検証するため、大規模なランダム化比較試験を行っています。結果は、ジュニア開発者には生産性向上に効果をもたらすものの、シニア開発者には効果は限定的という発見がされています。

DORA Reportには回答者の熟練度による分析は含まれていません。しかし、「AIを活用しつつも信頼度は低い」という表面的な現象を裏付ける結果となっています。この点については、さらなる研究を期待したいところです。

AIがチームや組織のパフォーマンスに与える影響とは

DORAの研究では、AIの導入がチームや組織、さらには製品にどのような影響を与えるのかを分析しました。この調査によって、AIの具体的な効果や課題が明らかになっています。

Figure 11. Impacts of AI adoption on organizational, team, and product performance. を元に筆者が翻訳

組織のパフォーマンス向上

研究によれば、AIの導入が25%増加すると、組織のパフォーマンスが約2.3%向上することが分かりました。この「組織のパフォーマンス」とは、収益性、市場シェア、業務効率、顧客満足度など、複数の要素を総合的に評価したものです。 AIは、業務の効率化や意思決定の迅速化、目標達成能力の向上といった面で組織にプラスの影響を及ぼしていると考えられます。

チームのパフォーマンスにも効果

チームのパフォーマンスもAIの導入によって約1.4%向上するという結果が出ています。この「チームのパフォーマンス」には、メンバー間の協力、イノベーション、効率的な作業、適応力などが含まれます。 特に、AIはチーム内でのコミュニケーションや知識共有の促進、意思決定プロセスの効率化といった課題を解消し、チーム全体の生産性を高める役割を果たしているようです。

製品のパフォーマンスとの関連性は限定的

一方で、製品のパフォーマンス(使いやすさ、機能性、価値、セキュリティなど)については、AIの導入による明確な影響は確認されませんでした。これは、製品の成功にはAI以外の要素、たとえば開発プロセスやクリエイティビティ、ユーザー体験のデザインなどが深く関係しているためと考えられます。

チーム、組織、製品のパフォーマンスが互いに密接な関連を持つことも示しています。例えば、優れたチームは高品質な製品を生み出す可能性が高い一方で、低品質な製品を扱うとチームの力が十分に発揮されないことがあります。また、良い組織は適切なリソースやプロセスを提供することで優れたチームを育てますが、逆に組織の問題がチームの力を制限するケースも見られます。

AIが個人に与える影響:利点と課題

次に、AIの導入が個人の仕事や生活にどのような影響を与えるのかが明らかになりました。この研究では、個人の成功やウェルビーイング(幸福感)に関連する要素を分析し、AIの影響を定量的に評価しています。

AIの導入で得られる明確な利点

DORAの調査によると、AIの導入が個人の「フロー(集中力)」「生産性」「仕事の満足度」を向上させることが分かりました(下表)。たとえば、AIの導入が25%増加すると次のような効果が予想されます:

アウトカム 予想される%の変化 (推定値)
フロー +2.6%
仕事の満足度 +2.2%
生産性 +2.1%
バーンアウト -0.6%

このような効果の背景には、AIによる情報の統合と効率的な作業環境の提供があります。従来は多くの時間を要した作業の効率化により、フロー状態に入りやすくなり、結果として仕事の満足度も向上します。

AIによる潜在的な課題:トレードオフ

一方で、AI導入による課題も浮かび上がっています。特に、価値ある作業に費やす時間の減少という予想外の結果が観察されました。

アウトカム 予想される%の変化 (推定値)
苦労する作業の時間:長期的な価値がほとんどない反復的な手作業に費やした時間の割合を測定する単一の項目 +0.4%
価値ある作業の時間: 価値があると考えるタスクに費やした時間の割合を測定する単一の項目 -2.6%

AIは、価値ある作業(たとえばコーディング)を迅速に進めることで効率化を実現しますが、単調で繰り返しの多い労苦的な作業(たとえば会議や事務処理)にはほとんど影響を与えていません。これにより、余った時間が新たなタスクで埋められる「真空現象(vacuum hypothesis)」が起きている可能性があります。

訳注:vacuum hypothesis(真空仮説/空席仮説) 生態系において「空いている場所には必ず何かが入る」という考え方を示す仮説です。例えば火山噴火後の新しい土地や、大量絶滅後の生態系の空白地帯には、時間の経過とともに必ず生物が進出し、その環境に適応した種が定着していきます。この仮説は特に、ガラパゴス諸島のフィンチ類(文鳥のような小鳥の類)のように、新しい環境で生物が多様化していく「適応放散」という現象を説明する際によく用いられます。名称の由来は、物理学における真空(vacuum)が必ず何かによって埋められようとするのと同様に、生態的な空白も必ず埋められていくという類推から来ています。

DORAが示す、AIのこれから

DORAは今回の回答者に、今後1年、5年、10年のAIの影響についての見解や期待を尋ねています。

まず、楽観的な見方としては、AIによって製品の品質が引き続き向上すると予想しています。

一方で、AIが自身のキャリア、自然環境、そして社会全体に対して純粋にマイナスの影響を与えると予想しており、これらの悪影響が約5年後に完全に顕在化すると考えています。

「自然環境」が唐突に思われるかもしれませんが、DORAレポートの前半ではAIの環境負荷についての懸念が言及されており、具体的には、

  • 2030年までにAIによってデータセンターの電力需要が160%増加する可能性
  • AIモデルの学習に、米国の1,000世帯以上の年間電力消費量に相当する電力が必要
  • 回答者の30%以上がAIは自然環境に有害と考えている

といった情報が添えられていました。

DORAレポートは "So now what? "という章で次のように提言しています。

私たちは、現時点でのAIが個人、チーム、そして組織を支援する可能性についての理解を深めたいと考えました。これまでに見えてきたパターンは、AIが単なる誇大宣伝ではなく、実際に確かな変化が起きていることを裏付けています。

AIを導入することの利点を示す明確な証拠が存在します。しかし同時に、多くの潜在的な障壁や成長に伴う痛み、そしてAIが有害な影響を及ぼす可能性があることも明らかです。

AIの大規模な導入は、単にスタートボタンを押すように簡単にはいきません。慎重で透明性があり、柔軟に適応できる戦略があってこそ、大きな効果が期待できます。この戦略は、リーダー、チーム、組織、研究者、そしてAI開発者が共同で作り上げていく必要があります。

リーダーと組織は、従業員を最もよく支援できる領域を優先してAIを導入する方法を見出す必要があります。

ここまで、AIに関するトピックをまとめてみました。

次回はAI関連以外の内容についてご紹介します。


ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers

2024年の軌跡と2025年の方針 〜エンジニアリングで事業に革命を起こす〜

こんにちは、ファインディ CTOの佐藤(@ma3tk)です! 今回は2024年の振り返りと、2025年のファインディのエンジニア組織における今後の方針についてお話します。

2024年はエンジニアが20名加わり60名規模の組織となり、退職者もほとんど出ない良好な組織文化を築きました。ファインディ全体でも100人以上も増え少しずつ大きくなってきました。テックブログは70本を超え、プロダクト開発の人数が増えていながら開発スピードは1.5倍に向上しました。

数字だけを見ても、この1年の変化の大きさを実感いただけるかもしれませんが、まだまだやるべきことが多く、この成長があってもファインディが実現したいことに少し近づいたというくらいです。今後の見通しについても後ほどご紹介します。

仲間が増え、組織で役割・状況が明確になった2024年

1年前を思い返すと、意図せず役割が不明確なメンバーもいたり、複数の業務を兼務しながら課題を解決する動きが多くありました。この1年で、元VPoE経験者や部長経験者など、様々なバックグラウンドを持つメンバーが加わってきたことで誰が何をすべきかを整備し、役割の明確化を行うことが出来ました。

お恥ずかしながら、ツールの運用確認などは昨年まで後手に回っていました。例えば、利用しているSaaSツールなどの管理をより精緻化しました。これにより「なんのために何を購入し、どれくらいの費用がかかっているのか」「今後の費用はどう推移していくのか」などがより細かく把握できるようになりました。その結果、組織として適切な支出ができているか、不要な支出を抑制できているかなど、経営状況の見える化が進みました。エンジニアリングのROIを見える化することで、より効率的な運用ができるようになったことで、お金をしっかり使うべきポイントにはきちんと使い、効果が見合わない場合は利用者と認識を合わせてきっぱりやめるというメリハリをつけられるようになりました。

また、印象的だったのは、Findy Team+の開発チームを4チーム体制へと拡大したことです。プロダクトの急成長に合わせて開発体制を強化する必要があり、沢山のメンバーに関わってもらいながら様々な角度からFindy Team+の開発を強化してきました。おかげで直近ではSOC21を取得したり、利用者の皆様にとって必要な機能を爆速で提供し価値を感じてもらえるようになってきました。 同時にSREチームも新設され、それと共にインフラ面での強化がなされ、より安全で不要なリスクを排除できる環境を実現しました。セキュリティマネジメント室もでき、組織全体でも安全に運用できる体制にもなってきました。

その他にもこの一年でデータ基盤を整備しました。これにより、データ分析やデータサイエンスに必要な正しいデータを早いタイミングで提供できるようになりました。また、認証基盤の整備により、ファインディのサービスをより便利で安全に活用できる開発体制を実現しています。

前述したテックブログを始めたことで、「テックブログの取り組みを見て強くを興味を持った」と言って入社していただけるメンバーも増えました。メンバーが増えたことで、テックリードを始めとして組織的にオンボーディングを強化してきました。別な記事で詳しく触れていますのでご覧ください。 tech.findy.co.jp

全体的には組織を知ってもらう一年でしたが、後半からはどうやってメンバーを即戦力化し、技術力の高いエンジニアにすぐに近づけるための環境整備をしました。

個人としても1年がかりで開発生産性の教科書という書籍を執筆し、多くの方に読んでいただける状態になりました。レビューをしていただいたエンジニアの皆さん、ありがとうございます。まだ読まれていない方はぜひ読んでみてください。

https://www.amazon.co.jp/dp/429714249Xwww.amazon.co.jp

2024年は総じて、2025年以降に向けた新しい仕込みを開始できた素晴らしい年だったと思います。

生成AIで開発がより加速した

2024年は生成AI元年とも呼べる年でした。GitHub Copilotの各種リリース、ChatGPT 4oをはじめとする様々な生成AIが我々の開発環境をアップデートし、仕事の進め方を大きく変えてきています。

ファインディではGitHub Copilotを全社的に導入し、開発効率を大きく向上させることができました。具体的には、エンジニア一人あたり月間でPull request2個分くらいを平均的に上げることに成功しました。インタビューしていただいた記事もありますのでご覧ください。 xtech.nikkei.com

アーキテクチャの観点では、8年目を迎えたプロダクトには、率直に言って古い箇所もあります。しかし、継続的な投資と改善を怠らず、アーキテクチャの刷新も進めてきました。その結果、デプロイ頻度は月平均20回から29回へと向上し、1.45倍以上プロダクトの改善が進むようになりました。開発スピードとクオリティの両立が実現できていると言えるでしょう。

2025年はエンジニアリングで事業に革命を起こす

ファインディ社内に向けた2025年のエンジニアリング・デザイン組織のテーマ

「技術とデザインで事業に革命を起こし、挑戦するエンジニアを支え続ける」を我々エンジニアリング組織とデザイン組織の2025年テーマとして定めました。

生成AIを組み込むことがゴールではありませんが、プロダクト、サービス、そして組織そのものをより良くしていく。そのためのツールとして生成AIを活用していきます。

具体的には、以下のような挑戦をします。

  • 生成AIを活用し、ユーザーのニーズに合わせた必須機能をつくり続ける開発体制の強化
  • より多くのユーザーに価値を届けるためのアーキテクチャ刷新やツールのリプレイス
  • グローバル展開の加速に向けた国際化対応とセキュアで高品質な技術基盤の強化
  • メンバー数やつくりたい機能数が増えてもチーム開発の革新を実現する開発生産性の高いチームづくり

この4点について1つずつ説明します。

生成AIを活用し、ユーザーのニーズに合わせた必須機能をつくり続ける開発体制の強化

昨年、我々ファインディでもFindy Team+に生成AIを活用したオンボーディング機能を組み込んでいきました。

「チームに開発革命を起こす」というプロダクトビジョンを発表し、サービスは大きく進化しています。この過程で様々なフィードバックをいただきました。僕の体感値では、今のFindy Team+は持てるポテンシャルの10%前後しか発揮できていない状況です。フィードバックから見えてきた課題を解決しようとすると、まだまだつくりたい機能が無限に湧いてきます。

この1年でも生成AIによって日々開発環境が進化し続けています。コードを書くこと自体も大切ですが、その作業時間は大幅に効率化されてきました。その分、「どんなサービスにするか」「どのような技術の組み合わせが最適か」といったアーキテクチャ設計により多くの時間を投資する動きが世の中でも見えてきました。

こういった環境を踏まえて、プロダクトの企画としても、ユーザーの皆様に向けて生成AIを活用しながらエンジニアの課題やエンジニアリング組織の課題を解決する開発を進めています。まだ検証中や開発途中のものも多く、さらなる進化を実現させていきます。

僕自身も生成AIに投資しながら新しい技術をプロダクトに組み込むアイディアを日々出し続けています。

より多くのユーザーに価値を届けるためのアーキテクチャ刷新やツールのリプレイス

事業が4つに拡大し、ファインディのサービスをより便利に連携させる仕組みを構築しています。

現在のファインディにおける4つの事業

基盤開発として、ファインディのサービスで利用できる認証基盤を強固にしながら、サービス間の連携を便利にしています。

また、日々新しく生まれるライブラリや外部ツールを最新にしていくため、継続的にアーキテクチャを見直しています。我々ファインディの成長、そしてファインディを取り巻く開発環境の変化を踏まえて、変更に寛容なアーキテクチャを目指し続けます。

グローバル展開の加速に向けた国際化対応とセキュアで高品質な技術基盤の強化

昨年は、Findy Team+でインド、韓国、台湾を中心にグローバルでの事業展開を強化してきました。そのために多言語化対応をし、様々なタイプのエンジニアリング組織の課題を解決するための開発を進めています。

日本でよく見られる課題を解決するプロダクトでしたが、各国で悩みの種類が異なることに気づきました。そこで、すべての国でワンプロダクトとして解決できるよう進めています。まだまだ多くの課題に応えきれていない状況です。

グローバル展開では、さらなるセキュリティ強化が求められます。常に安定した稼働ができるサービスづくり、そして万が一の障害時も爆速で復旧できる開発体制を維持します。これからも、グローバルで価値提供ができるプロダクトを複数つくっていきます。

メンバー数やつくりたい機能数が増えてもチーム開発の革新を実現する開発生産性の高いチームづくり

人材も増やしていきたいですし、つくりたいものもこれからますます増えていきます。

「エンジニアリングで事業に革命を起こす」ために、まずはファインディの開発組織を世界一の開発組織へと進化させる必要があります。

この5年で開発組織のレベルは大きく成長し、チームとしては開発生産性が高いと言えます。直近の課題は、メンバーが入社してすぐに慣れたと言える環境をつくることでした。そこで、組織全体でエンジニア育成に時間を投資してきました。

2024年は、組織全体で開発がスムーズに進み、障害が起こりにくく、起こっても解決できる体制を築きました。それだけでなく、エンジニア個人も市場価値の高い人材になれるよう育成してきました。

どこでも通用するスキル、そしてファインディで開発することが最高の福利厚生となる組織を目指し続けます。

そして、まだ工数の関係でできていない改善にも、積極的にチャレンジしていきます。「やりたいことリスト」は日々増えており、それだけ可能性が広がっているということでもあります。

これからエンジニアリングで革新を一緒に起こしませんか?

我々ファインディは今、非常に面白いフェーズにいます。組織は大きく成長し、技術的な挑戦も加速しています。しかし、まだまだ道半ばです。役割も明確にして集中して技術と事業に没頭しながらもっと面白いことができる、そんな環境に進化しました。

2025年は、さらにワクワクする変化の年になると確信しています。この革命が起こせそうな瞬間に興味を持っていただけた方は、ぜひファインディでカジュアル面談やイベントを通してお話ししませんか?

先ほど挙げたようなチャレンジを実現するために、次のような方も募集しています。

  • エンジニアリングをターゲットにしたプロダクトづくりに興味がある方
  • 開発生産性の高い環境でアーキテクチャを進化させ続けたい方
  • 生成AIを活用してプロダクトを進化させたい方
  • グローバル展開を技術で支えたい方
  • 生産性の高いエンジニアリング組織で働きたい方
  • 日常的に英語を使う環境で開発したい方

もちろんAND条件ではなく、どれかにマッチすれば是非お話しましょう!

herp.careers

2024年は多くの優秀なメンバーがジョインし、新しいファインディへと進化するための仕込みの1年でした。2025年も、まだ見ぬ新しい仲間とともに、より大きな挑戦をしていきます!


  1. System and Organization Control 2:アメリカの公認会計士協会(AICPA)が制定した、クラウドサービス提供者やデータセンターなどの受託会社を対象とした信頼性を証明する国際的な仕組みです。

Slackワークフローとスプレッドシートを連携して開発工数の内訳を簡単に可視化

こんにちは!ファインディでFindy Team+開発チームのEMをしている浜田です。

Findy Team+開発チームでは、Slackワークフローとスプレッドシートを連携して開発工数の内訳を可視化しています。 開発工数の内訳を可視化することで、どの開発にどれくらい工数がかかったかや全体の工数のうちどれくらいの割合を開発に使えているかなどを定量的に把握できます。

Slackワークフローとスプレッドシートの説明

ここからはTeam+開発チームで実際に使っているSlackワークフローとスプレッドシートをキャプチャを交えつつ説明します。 Slackワークフローで入力した内容がスプレッドシートに連携されるので、スプレッドシートで集計して表やグラフに加工しています。

Slackワークフロー

開発メンバーの稼動終了時にSlackワークフローを使って日報を提出してもらっています。 日報としての役割を兼ねているため工数の可視化と直接関係ない項目も含んでいます。

Slackワークフロー

午前のタスク / 午後のタスク

その日に取り組んだタスクを午前・午後で1つずつ選択します。 自由記述の場合、選択肢が人によってブレるので選択式にしています。

選択肢は、改善開発 / トイル / 休暇 / 開発以外の4項目は固定で、現在進行中の施策開発ごとに選択肢を追加しています。

タスクリスト

細かく分ければ工数の精度は上がりますが、入力の手間を考慮して0.5人日精度にしています。 全体の傾向を把握するだけであればこの精度で十分だと感じています。

トイル時間

アラート、問い合わせ、セキュリティチェックなど、Team+プロダクトに関係する運用作業に使った合計時間(0.5h単位)を入力。

※トイルとは、SRE サイトリライアビリティエンジニアリングで紹介されており、次のように定義されています。 Findy Team+の開発チームでは、繰り返し発生し、かつ手動で実施しなければいけないタスクとして主にアラートや問い合わせ、セキュリティチェックなどの作業が顕在化しているため、それらの時間をトイル時間として計測しています。

トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。

やったこと / 次やること / 所感

その日にやったことや翌営業日にやること、所感を自由記述。 こちらは日報としての役割のための項目です。

今日の調子

その日の調子を5段階で選択。 調子の推移を可視化したら面白そうと思って項目を追加したが、あまり活用できていない😭

担当イシューは見積もり通りに完了しそう?

イシューの進捗を3段階(まかせろ/多分そう/ダメそう)で選択。 自身のタスク現状を考えるきっかけにちょうど良い項目だと感じています。 「ダメそう」の場合は、即相談を推奨しています!

工数の内訳と割合

Slackワークフローの「午前のタスク」「午後のタスク」のデータをもとにタスクごとの工数を集計しています。 午前と午後で入力しているので、工数の精度は0.5人日です。 黒塗りのところは実際の施策開発の名称が入っているのでマスクしています🙏

工数の内訳

タスクを「施策開発」「改善開発」「トイル」「開発以外」に分類して、それぞれの工数の割合をグラフ化しています。

工数の割合

開発以外の作業やトイル対応が多い場合、「トイル」や「開発以外」の割合が大きくなります。 今までの傾向から施策開発と改善で7割を超えていたら開発に集中できていると判断しています。 トイルや開発以外のタスクが定常的に多い場合、開発に集中できるように早急に原因を取り除く必要があるとわかります。

また、開発の割合が多かったとしても「改善開発」の割合が多い場合は注意が必要です。 この場合、着手可能な施策開発がなく改善開発ばかりを実施している可能性があり健全とは言えません。施策開発に着手できていない原因を探り対策する必要があるとわかります。

トイル

Slackワークフローの「トイル」のデータをもとにトイル対応した時間を集計しています。 トイル時間が定常的に多い場合、開発に使える時間が少なくなることを意味するので早急に対処する必要があります。

トイル

トイルに使った工数の割合をグラフ化しています。今までの傾向から5%未満で推移していたら健全と判断しています。

トイルの割合

Slackワークフロー作成手順

Slackワークフローの設定方法を説明します。*1

ワークフローを作成するために、サイドメニューから「その他」>「自動化」を選択します。

Slackワークフロー作成手順1

自動化の画面から「新しいワークフローを構築する」を選択します。

Slackワークフロー作成手順2

ワークフローを開始するイベントを選択します。 今回は任意のタイミングで起動したいので「Slack内のリンクから開始します」を選択します。

こちらを選択することで、発行されたリンクを実行したり、Slackのスラッシュコマンドから実行できるワークフローが作成できます。

Slackワークフロー作成手順3

1つ目のステップでは、日報の内容をフォームで収集するため「情報をフォームで収集する」を選択します。 ステップから見つからない場合は、検索ボックスからキーワードを入力して探すこともできます。

Slackワークフロー作成手順4

フォームのタイトルや項目を設定する画面が開くので収集したい項目を設定します。 入力形式はフリーテキストだけではなく、ドロップダウンやカレンダーから選択など様々な方法が準備されているので適したものを選択しましょう。

Slackワークフロー作成手順5

フォームで入力した内容をスプレッドシートに連携したいため、2つ目のステップでは「スプレッドシートに追加する」を選択します。

Slackワークフロー作成手順6

連携するスプレッドシートは1つ目のステップで作成したフォームを基に生成できます。利用者のユースケースが的確に捉えられており、とても良いUXですよね!

Slackワークフロー作成手順7

フォームの項目とスプレッドシートの列を紐づけます。

Slackワークフロー作成手順8

入力した内容をSlackチャンネルにも投稿したいため、最後のステップでは「チャンネルへメッセージを送信する」を選択します。

Slackワークフロー作成手順9

Slackチャンネルへ通知するメッセージのテンプレートを作成します。

Slackワークフロー作成手順10

作成できたら公開します。公開すると実行するためのURLが発行されます🎉

Slackワークフロー作成手順11

Slackワークフローを実行すると、次のように連携したスプレッドシートにデータが1行追加されます。 スプレッドシートにデータが溜まりさえすれば、スプシ芸(?)を活用して様々な切り口でデータ分析できますね! ガンガン活用していきましょう💪

Slackワークフロー作成手順12

まとめ

この記事では、Slackワークフローとスプレッドシートを連携して開発工数の内訳を可視化する方法を紹介しました。

前半に書きましたが、工数の可視化は入力の手間と精度のバランスが大事だと思います。 必要最低限の精度で手間なく可視化できるように工夫しつつ、開発工数やトイル時間を把握して開発組織が健全に開発を推進できている状態にしていきましょう!


ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers

*1:こちらは2025年1月時点の情報です。Slackのバージョンアップ等で変更される可能性があります。

Findyの爆速開発を支えるタスク分解

こんにちは。

ファインディ で Tech Lead をやらせてもらってる戸田です。

既に皆さんも御存知かと思いますが、弊社では開発生産性の向上に対して非常に力を入れています。

以前公開した↓の記事で、弊社の高い開発生産性を支えている取り組み、技術についてお話させていただきました。

tech.findy.co.jp

ありがたいことに、この記事を多くの方に読んでいただき反響をいただいております。

そこで今回は、↑の記事でも紹介されている「タスク分解」について更に深堀りしてお話しようと思います。

タスク分解は、弊社にJOINしたら最初に必ず覚えてもらう最重要テクニックの中の1つです。

それでは見ていきましょう!

タスク分解とは

何かしらの開発タスクを任されたあなたが最初にやるべきことは何でしょうか?

もしいきなりコードを書き出す人がいるのであれば、この記事を読むことをオススメします。

開発タスクを任された際、まず最初にタスクの洗い出しを行い、それらを可能な限り分解していきましょう。

分解したタスク毎にPull requestを作成することで、自然とPull requestの粒度を適切に保つことが可能になります。

まずはタスク分解におけるメリットを紹介します。

メリット

事前に対応方針の認識を合わせやすくなる

弊社ではGitHubのIssueにタスクリストを作成し、実装着手前にタスクリストをレビューしてもらうようになっています。

実際に対応する内容と、考えているタスクの内容が一致しているのか、対応する順番は適切か、などを確認して実装着手前に認識を合わせるようにしています。

これからのタスクの予定を目に見える形で確認することが出来るので、事前に対応漏れや考慮漏れに気づきやすくなり、手戻りの発生が減ります。

これにより工数見積の精度も上がり、開発スケジュールが大きくずれ込むことを防ぐことが出来るようになります。

Pull requestの粒度を適切に保つことが出来る

基本的に作成したタスクごとにPull requestを作成することになります。

Pull requestの粒度が大きくなってしまう原因の1つに、「やるべきことがどんどん増えていって、結果的に大きくなってしまった」というものがあります。

しかし、事前にタスクをある程度の粒度で切り出しているため、Pull requestを作成している途中に肥大化してしまうことが少なくなります。

それでも考慮漏れなどでPull requestの粒度が大きくなってしまうこともゼロではありません。その場合、着手中のタスクの粒度が大きいと判断し、そこから更にタスクを分解するようにします。

実装中にタスクを細分化することにより、意図しないPull requestの肥大化を防ぎ、結果的に適切な粒度のタスクリストに近づくようになります。

また、Pull requestのレビュワーからの視点だと「これからどんな事をしようとしているのか」がIssue内のタスクリストによって把握することが出来るようになります。

そのため、Pull requestの粒度が細かい状態でレビュー依頼が来たとしても、局所的なレビューではなく全体像をある程度把握した上でのレビューが可能となります。

進捗管理、引き継ぎをしやすくなる

タスクリスト内の終わったタスクにはチェックを入れ、進捗管理としても利用します。

全体を通してやるべきことと現在終わっていることがタスクリストを見ることで一目でわかるようになっているため、開発の進捗がどうなっているのか確認出来るだけでなく、他のメンバーに開発の引き継ぎをしやすくなります。

タスクの作り方

まず弊社では、GitHubのIssueのテンプレートにタスクリストの項目を用意しています。

---
name: Feature request
about: 新機能や改善等の仕様用

---

## なぜやるのか
<!-- やることになった背景等を書く -->


## ゴール
<!-- これをリリースすることで何を達成したいのか -->


## 仕様
### 概要
<!-- 量が多ければ、概要と詳細に分ける -->
<!-- 期待する・期待しない動作を書く -->

### タスクリスト
- [ ] add task

## 補足事項
### 懸念
<!-- 気になる点や仕様上での懸念事項等あれば記載する -->

## 関連Issue

このように、Issueを作成し開発に着手する前にタスクリストを作成することが必要であることを明確にしています。

また、チェックボックスで作成したタスクからIssueを直接作成する機能などもGitHubから提供されているので合わせて確認してみてください。

docs.github.com

具体例

例えば、「ユーザーデータの一覧を返すREST APIを追加する」タスクが割り振られたとしましょう。

これだけだと、タスクリストの初稿はこうなります。

- [ ] ユーザーデータの一覧を返すREST APIを追加する

これだけでは何がどう必要なのか、具体的によくわかりませんね。そこでPdMに確認すると、次のような要望が上がっているとのことでした。

- 登録しているユーザーの一覧を表示したい
- idとnameで絞り込みが出来るようにしたい

現状わかっている要件だけでタスク分解をしてみましょう。

- [ ] ユーザーデータの一覧を返すREST APIを追加する
  - [ ] データベースからユーザーデータの一覧を取得して返す
  - [ ] 絞り込みに対応する
    - [ ] id
    - [ ] name

とりあえず「動くもの」であれば、これだけで実装できそうです。

この状態でフロントエンド担当のメンバーにレビューしてもらいましょう。画面モックを確認するとページネーションとソートの機能が必要であることがわかりました。

ここでタスクを追加しておきましょう。

- [ ] ユーザーデータの一覧を返すREST APIを追加する
  - [ ] データベースからユーザーデータの一覧を取得して返す
  - [ ] 絞り込みに対応する
    - [ ] id
    - [ ] name
  - [ ] ページネーションに対応する
  - [ ] ソートに対応する
    - [ ] idのasc/desc

要件や必要な機能が少しずつ明確になってきましたね。次に他のバックエンドエンジニアにレビューしてもらいましょう。

すると、「nameの検索条件は完全一致、部分一致のどっちなのか?」という指摘をもらいました。

確かに画面モックから読み解くのは難しかったです。PdMと議論し、部分一致で実装することに決定しました。

ここで既存のタスクを修正しましょう。

- [ ] ユーザーデータの一覧を返すREST APIを追加する
  - [ ] データベースからユーザーデータの一覧を取得して返す
  - [ ] 絞り込みに対応する
    - [ ] id
    - [ ] nameの部分一致
  - [ ] ページネーションに対応する
  - [ ] ソートに対応する
    - [ ] idのasc/desc

一通りの要件はこれで揃ったようです。これで実装に着手していきましょう。

ところが実装を開始してテストコードを書いていると、退会ユーザーのレコードが存在している可能性が出てきました。この場合、退会ユーザーは一覧に表示したくありません。

この要件をタスクリストに追加しましょう。

- [ ] ユーザーデータの一覧を返すREST APIを追加する
  - [ ] データベースからユーザーデータの一覧を取得して返す
    - [ ] 全件返す
    - [ ] 退会ユーザーは一覧から除外する
  - [ ] 絞り込みに対応する
    - [ ] id
    - [ ] nameの部分一致
  - [ ] ページネーションに対応する
  - [ ] ソートに対応する
    - [ ] idのasc/desc

ひとまず全件データを返すところまでPull requestで対応して、別のPull requestで退会ユーザーを一覧から除外するコードを追加すればOKです。この様に、実装中にタスクを更に細分化することも十分ありえます。

ひとまず退会ユーザーを一覧から除外するところまで対応が完了したので、チェックボックスにチェックを入れて進捗を管理します。

- [ ] ユーザーデータの一覧を返すREST APIを追加する
  - [x] データベースからユーザーデータの一覧を取得して返す
    - [x] 全件返す
    - [x] 退会ユーザーは一覧から除外する
  - [ ] 絞り込みに対応する
    - [ ] id
    - [ ] nameの部分一致
  - [ ] ページネーションに対応する
  - [ ] ソートに対応する
    - [ ] idのasc/desc

チェックを入れて進捗を管理することで、完了しているタスク、していないタスクを一目で確認することが可能になり、他のメンバーに開発の引き継ぎをしやすくなります。

今回は極端な例で紹介しましたが、タスクリストの作り方、整理の仕方を具体的に理解できたかと思います。

良いタスクリストを作るコツ

良いタスクリストを作成するためのコツは、最初から完璧なタスクリストを作ろうとしないことです。

まず最初に大枠のタスクを考え、そこから分解していくように意識してタスクリストを作成すると、結果的に詳細なタスクリストが完成しています。

小さくコツコツと修正を上乗せしていき、最終的に完成形に近づけていくような分解の仕方が良いでしょう。

大きな機能の実装担当になった際に、一度に全ての機能を実装するのではなく、小さい機能追加を何回も繰り返して結果的に大きな機能を完成させるようなイメージを持つと良いです。

まとめ

いかがでしたでしょうか?

実装コードを書く前の準備は非常に重要です。タスク分解の精度を上げることにより、結果的にスピード感を持った開発を行うことが出来るようになります。

現在、ファインディでは一緒に働くメンバーを募集中です。

興味がある方はこちらから ↓ herp.careers

2024年ふりかえり!Findy Tech Blogの人気記事まとめ

あけましておめでとうございます!

Findy Tech Blog編集長でソフトウェアプロセス改善コーチの高橋(@Taka_bow)です。

昨年2月末にスタートしたFindy Tech Blogが、なんと総PV数30万を突破しました!

ここまで成長できたのも、記事を読んでくださる皆さんのおかげです。本当にありがとうございます。

今日は2024年、特に人気を集めた記事をいくつかの視点からピックアップしてご紹介します。技術のトレンドから生産性向上テクニックまで、きっと皆さんの関心に響く記事が見つかるはずです。

それでは早速、ふりかえっていきましょう!

2024年下期トピックス

ITmedia NEWSの「IT企業デスクツアー」に取り上げて頂く

当ブログ人気シリーズ「【エンジニアの日常】エンジニア達の自慢の作業環境を大公開」で紹介した数々のデスク環境が、ITmedia様により改めて記事化して頂いてます!これは嬉しい!

「自慢の作業環境」の解説は、ブログの方が詳しいですのでぜひこちらもご覧ください。

下期では、Part5をリリースしております。

「修行をした話」から広がった新しい試み

2024年10月に公開した「プロダクト開発の修行をした話」シリーズが、新たな展開を見せました。弟子エンジニアと、師匠エンジニア、それぞれの視点で綴った2本のブログ記事が大きな反響を呼び、ついにはLTイベントの開催へと発展したのです。

このシリーズでは、実際のプロダクト開発現場で行われた「修行」の様子を、両者の生の声でお届けしました。技術的な学びはもちろん、メンターとメンティーの関係性の築き方、プロダクト開発を通じた成長の過程など、普段はなかなか表に出てこない貴重な体験が詳しく語られています。

そして、記事での反響を受けて実現したLTイベント。ブログには書ききれなかったエピソードや、視聴者から寄せられた質問への回答など、より深い内容をお届けできました。テックブログの新しい可能性を探る試みとなりました。

ブログでは語りきれなかった生の声を届ける、という新しいチャレンジをしました。

youtu.be

【2024年】年間総PV数ランキングTop3

ここからは、2024年一番アクセス(PV)のあった記事を紹介します!

第3位

\ 第3位 /19,305 PV

【エンジニアの日常】エンジニア達の人生を変えた一冊 Part3 - Findy Tech Blog

ファインディのエンジニアたちが自身の成長に影響を与えた一冊を語る人気シリーズ「エンジニア達の人生を変えた一冊 Part3」ランキング。

記事では、『マスタリングTCP/IP―入門編』や『ハッカーと画家 コンピュータ時代の創造者たち』、そして『UNIXという考え方』といった名著が取り上げられており、それぞれがどのようにエンジニアたちの視点やスキルに変化をもたらしたのかが語られています。

とても玄人なラインナップでしでしたが、とても読まれています。ぜひチェックしてみてください!

第2位

\ 第2位 /19,379 PV

【エンジニアの日常】エンジニア達の人生を変えた一冊 Part2 - Findy Tech Blog

第3位に続き、同じシリーズがランクイン!

この記事では、『SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム』や『プログラマが知るべき97のこと』、そして『Clean Coder プロフェッショナルプログラマへの道』など、多くのエンジニアに愛読されている名著が取り上げられています。それぞれの書籍がどのように読者の成長を後押ししたのか、具体的なエピソードを交えて解説されています。

こちらも、ぜひチェックしてみてください!

第1位

\ 第1位 /20,108 PV

開発生産性指標を向上させるためにやってはいけないアンチパターン - Findy Tech Blog

2024年、最も多くの方に読まれた記事は「開発生産性指標を向上させるためにやってはいけないアンチパターン」でした。

開発現場で生産性向上に取り組む際、ついやってしまいがちな落とし穴について、実例を交えながら解説しています。デプロイ頻度やリードタイムといった指標を改善しようとするあまり、かえって本末転倒になってしまうケース。例えば、数字を上げるために無理にデプロイ回数を増やしたり、リードタイムを短くするためにコードレビューを省いたり...。一見、指標は改善されるものの、実は長期的に見るとチームの成長を阻害してしまう、そんな危険性を具体的に紹介しています。

「勝って兜の緒を締めよ」的、エンジニアの心構えを解いたブログです。

【2024年】はてなブックマーク数Top3

こちらでは、はてなブックマーク(はてブ)の数が多かったランキングをお届けします!*1

第3位

\ 第3位 /217 users

【エンジニアの日常】エンジニア達の人生を変えた一冊 Part1 - Findy Tech Blog

こちらでは「Part1」がエントリー!

記事では、ソフトウェアとビジネスの未来を描く『ソフトウェア・ファースト』や、組織運営とリーダーシップの重要性を説く『1兆ドルコーチ』、アジャイル開発の実践的な手法を学べる『アジャイルサムライ』、さらに長期的なコード品質を支える設計の重要性に触れた『Clean Architecture』が取り上げられています。

加えて、Appleのデザインを牽引したジョナサン・アイブ氏のキャリアや哲学を深掘りした『ジョナサン・アイブ』も紹介され、デザインとエンジニアリングの融合が生むイノベーションの重要性について考えさせられる内容が語られています。

第2位

\ 第2位 /218 users

開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog

この記事では、開発をスムーズに進めるために、プロジェクト開始前に押さえておきたいポイントをまとめています。

プロジェクトのゴールをしっかり定めることはもちろん、ユーザー目線に立った設計の大切さ、既存の仕組みを上手く活用するコツ、将来の拡張も考えたシンプルな設計の進め方など、具体的な例を交えながら解説しています。段階的なリリースを通じて、ユーザーの声を活かしながら改善を重ねていく方法についても詳しく紹介されています。

日々の開発現場で使える知見が詰まっているので、プロジェクトの進め方を見直したい方や、開発の効率を上げたいと考えているエンジニア、マネージャーの方には、特に参考になるはずです。

第1位

\ 第1位 /328 users

IT人材不足79万人の真因:生産性向上を阻む『人月の神話型請負』からの脱却 - Findy Tech Blog

はてブが一番付いた記事は「IT人材不足79万人の真因:生産性向上を阻む『人月の神話型請負』からの脱却」でした!

2030年、日本のIT人材が約79万人不足するという衝撃的な予測をご存知でしょうか。この深刻な課題に対して、Findy Tech Blogでは「IT人材不足79万人の真因:生産性向上を阻む『人月の神話型請負』からの脱却」という記事を公開しました。 記事では、人材不足の根本的な原因として、日本のIT業界に根付いている「人月」という考え方と、ウォーターフォール型開発による従来の請負開発に着目。これらが開発現場の生産性向上を妨げ、人材不足を加速させている構造を丁寧に解き明かしていきます。 さらに、アジャイル開発の導入事例や新しい契約モデルの提案など、この課題を乗り越えるためのヒントも紹介しています。

おわりに

2024年に公開した73件の記事の中からほんの一部をご紹介させていただきました。

紹介しきれなかった記事もたくさんありますので、ぜひ他の記事もご笑覧頂ければと思います。 昨年は特に「【エンジニアの日常】シリーズ」に大きな反響をいただきました。これらのテーマは2025年も引き続き追求していきつつ、新しい技術への挑戦やファインディならではの爆速開発についても積極的に発信していきたいと思います。

そして何より、読者の皆さんとの対話を大切にしていきたい。記事へのコメントやSNSでの反応は、私たちの大きな励みになっています。

2025年も「面白い!」「参考になった!」と思っていただける記事をお届けできるよう、編集部一同張り切っていきますので、引き続きFindy Tech Blogをよろしくお願いします!


ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers

*1:2024年12月31日時点で集計したランキングです。以後、増減する可能性はあります。

Findyのエンジニアおみくじの舞台裏を大公開!

新年、明けましておめでとうございます。

ファインディ株式会社でフロントエンドのリードをしている新福(@puku0x)です。

今年も「エンジニアおみくじ」の季節がやって参りました 🎉

企画の詳細につきましては↓の記事をご参照ください。

findy-code.io

今回はエンジニアおみくじ開発の舞台裏をお話ししようと思います。

エンジニアおみくじとは

エンジニアおみくじは Findy で毎年1月に開催しているイベントです。

期間中にFindyへログインし、引いたおみくじをシェアすると抽選でプレゼントがもらえます。

期間中は毎日おみくじを引けます。目指せ超大吉!

さらに今年はおみくじのパターンを増やしました。

その数、なんと 18万7,500通り !!

たくさんご用意しましたので是非お楽しみください。

舞台裏① 企画からエンジニアが関わる

ファインディでは、企画の段階からエンジニアがプロジェクトに参加しており、おみくじの内容に関してもエンジニアの監修が入っています。

エンジニアチームからは、用語やトレンドを共有したり、技術検証のフィードバックなどを行いました。運勢の一覧も皆でチェックしました。

おみくじにはエンジニアの監修が入っています

今年は年収やスキル偏差値などに加え、生成AIセキュリティといった項目が盛り込まれてあります。

中には思わずニヤニヤしてしまうものもあるでしょう。

面白い運勢が出ましたら「#Findyエンジニアおみくじ2025 」のハッシュタグを付けてシェアをお願いします。

舞台裏② おみくじパターンは18万通り以上

実は、これまでのエンジニアおみくじは「運勢別に固定の画像を返す」という仕様であり、画像作成の工数を抑えるため、60パターンしかありませんでした。

単純な構成だっため実装面では楽でしたが、画像を作成するデザインチームへの負担が大きいという課題がありました。また、おみくじを引き直した際に結果が重複する確率もそこそこあり、ユーザー体験の面からもパターンの増加は必須でした。

このような背景から、今回は運勢(6通り)、各項目(55通り)、コメント(10通り)からなる 6×5×5×5×5×5×10 = 187,5000 通りの組み合わせを用意することにしました。

すごい数ですね。ちなみに既存のやり方では休まず働いて15年かかる作成量であると試算されました。

すべての組み合わせの画像を手動で作成すると完成は...15年後!

ここはエンジニアチームの出番です💪

大量の組み合わせの画像を作成するのは現実的でないため、実装を根本から見直し、動的に画像へテキストを挿入する形式を採用しました。

// ※説明のためコードを一部変更しております
const textMaps = [
  // 年収
  {
    '超大吉': {
      0: '項目1',
      1: '項目2',
      2: '項目3',
      3: '項目4',
      4: '項目5',
    },
    '大吉': { ... },
    '中吉': { ... },
    :
  },
  // スキル偏差値
  {
    '超大吉': { ... },
    '大吉': { ... },
    :
// ※説明のためコードを一部変更しております
const noteMap = {
  '超大吉': {
    0: 'コメント1',
    1: 'コメント2',
    2: 'コメント3',
    3: 'コメント4',
    4: 'コメント5',
    5: 'コメント6',
    6: 'コメント7',
    7: 'コメント8',
    8: 'コメント9',
    9: 'コメント10',
  },
  '大吉': { ... },
  '中吉': { ... },
  :
// ※説明のためコードを一部変更しております
const ids = [...];
const index = '超大吉';
const texts = [textMaps[0][index][ids[0]], textMaps[1][index][ids[1]], textMaps[2][index][ids[2]], textMaps[3][index][ids[3]], textMaps[4][index][ids[4]]];
const note = noteMap[index][ids[5]];

return (
  <div style={{ backgroundImage: 'url(...)' }}>
    <span>{texts[0]}</span>
    <span>{texts[1]}</span>
    <span>{texts[2]}</span>
    <span>{texts[3]}</span>
    <span>{texts[4]}</span>
    <p>{note}</p>
  </div>
);

実装が新しくなったことで、将来的に運勢や項目が追加された場合でも柔軟に対応できるようになりました。

どのような内容になっているか気になった方は「#Findyエンジニアおみくじ2025 」でシェアされている投稿を是非ご覧ください。

まとめ

この記事では、Findyのエンジニアおみくじ実装の舞台裏をご紹介しました。

企画をより良いものにするためエンジニア、デザイナー、QA、マネージャーが一丸となって取り組んでおります。

過去に触ったことがあるという方におかれましても、これを機にアップデートされた「エンジニアおみくじ」をお試しいただければと思います 🙇‍♂️

findy-code.io

それでは、本年もよろしくお願いします。


ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers

「改訂新版 良いコード/悪いコードで学ぶ設計入門」を使ったリファクタリングの事例

こんにちは!ファインディのプロダクト開発部でエンジニアをしているham (@hamchance0215)とEND(@aiandrox)です。 この記事はFindy Advent Calendar 2024 25日目の記事ということで、2人で共同執筆しています。

adventar.org

この記事について

ファインディでは日頃からお世話になっている皆さんに感謝の気持ちを込めて「Findyユーザー感謝祭 2024」を12/19に開催しました。

イベント中に、参加者の一人であるミノ駆動(@MinoDriven)さんが12/25発売の著書「改訂新版 良いコード/悪いコードで学ぶ設計入門」を参加者4名にプレゼントしてくださいました!

じゃんけんで勝った4名が書籍をゲットするルールであり、hamとENDがじゃんけんの強さを発揮して書籍をゲットし、なんやかんやあってこの記事を書くことになりました。

さらにサインも頂きました!

なんやかんや
なんやかんや

「改訂新版 良いコード/悪いコードで学ぶ設計入門」を使ったリファクタリングとは?

ユーザー感謝祭の懇親会でミノ駆動さんとお話しする機会があり、設計の知識を開発チームにインプットしていく方法について教えていただきました。

「改訂新版 良いコード/悪いコードで学ぶ設計入門」には、タイトルの通り「良いコード」だけではなく「悪いコード」の例もたくさん載っています。そこで、書籍に記載されている「悪いコード」をプロダクトのソースコードから探して「良いコード」にリファクタリングするという実践形式の学習をしているとのことです。

この学習方法、プロダクトのソースコードを使っていることから業務で活用できる生きた知識が身につくだけではなく、プロダクトがリファクタリングされて綺麗になっていくという一石二鳥な学習方法であり、とても興味を持ちました。

もっと知りたい方は、1/17にミノ駆動さん本人から紹介していただくイベントも企画されているのでぜひご覧ください!

findy.connpass.com

実践

それでは早速プロダクトのソースコードから「悪いコード」を探して「良いコード」へリファクタリングしていきます。

今回はFindy Team+のコードを使って実践しました。

実践1: 11.4 意図がわからない名前

実践1では「11.4 意図がわからない名前」に記載されている悪いコードを参考に探しました。

「意図がわからない名前」のデメリットについて、本著の一部を抜粋しました。

あいまいな変数名では、実際の意図に翻訳する作業が読むたびに必要になります。たとえば仕様変更の依頼があったとき、対応するメソッドや変数が何であるのか頭の中で翻訳作業が必要になります。また、チームに新しく参加したメンバーに対しての説明コストが増大します。

チーム開発において、コードは書くことより読むことの方が多いため、読み手に負担がかかっている状態は好ましくありません。

次のコードは、Team+で扱っている指標の1つである「LEAD_TIME_FOR_CHANGES_HOURS(変更のリードタイム)」を管理しているハッシュマップです。今回はこちらを対象にしました。

{
  statsType: 'LEAD_TIME_FOR_CHANGES_HOURS',
  expectData: {
    label: '変更のリードタイム',
    unit: 'h',
    negativePositive: true,
  }
}

各項目を見ていくと、labelは表示名でありunitは指標の単位であることが直感的にわかりますが、negativePositiveは何を意図しているかおわかりいただけるでしょうか?

negativePositiveは「値が小さいほど良い指標か?」を表すboolean型の変数です。 ただ、negative(値が小さいほど良い) or positive(値が大きいほど良い)を示そうとしているところまでは理解できますが、trueの場合にどちらなのかを変数名だけで判断するのは困難であり、実際の設定値などから意図を推測する必要がありました。

そこで、isLowerBetterへリネームしました。 下記が修正した箇所の差分の1つです。isLowerBetterに変更したことで「値が小さいほど良い指標」の場合、ifの中に入ることがコードから読み取れるようになりました。

- if(negativePositive) {
+ if(isLowerBetter) {
    // do something
  }

学習しながらリファクタリングしてマージまで完了!

merged

実践2: 7.1 ロジックの流用

Team+では、インポートに伴うさまざまな処理があり、それぞれを呼び出すBatchクラスも多く存在します。その中に、次のようなコードがありました。

module Batch
  class TransformXX < Batch::Base
    # @param [ActiveSupport::TimeWithZone] xx_after 存在する場合はXXの更新処理を行う
    def call(duration:, xx_after: nil)
      Transformer.call(duration:)

      # 実際にはここでXXをアップデートする処理が走る
      UpdateXX.call(start_at: xx_after) if xx_after
    rescue StandardError => e
      Rails.logger.error 'データ変換処理に失敗しました'
    end
  end
end

問題はこの引数です。

# @param [ActiveSupport::TimeWithZone] xx_after 存在する場合はXXの更新処理を行う

これは8.6 フラグ引数の節でも紹介されているものです。特に、Batchクラスでは引数によって処理を分岐しているものがちらほらあります。

フラグ引数付きのメソッドは、何が起こるか読み手の想像を難しくさせます。何が起こるのか理解するには、メソッド内部のロジックを見に行かなければなりません。可読性が低下し、開発生産性が低下します。

このBatchクラスは管理画面から呼び出される処理で、管理画面にチェックボックスがあるので、すぐにフラグを削除することは難しそうです。幸い、この条件分岐によってどう処理を行うかはクラスに切り出されており、可読性は悪くないと思われます。

問題は、このBatchクラスが管理画面を介する処理以外のいろんな箇所から呼ばれていることです。以下は一例です。

# Before
def transform_resources(start_at)
  Batch::TransformXX.call(duration: start_at..Time.current)
end

ここでは、xx_afterが指定されていないので、xx_afternilになっています。つまり、実際にはTransformerの処理しか行っていません。

ということで、不要な共通化をなくして直接実行クラスを呼び出すようにしました。このリファクタリングによって例外処理がなくなりましたが、ここでは例外処理を行う必要はなかったのでスッキリしました。

# After
def transform_resources(start_at)
  Transformer.call(duration:)
end

これにより、過度な共通化がなくなり、フラグ引数が散乱する懸念も少なくなりました。

実践3: 15.1.3 条件を読みやすくする

また、次のようにunlessnil?を使っている箇所がありました。

return unless user.nil?

二重否定となっていて読みづらかったため、次のようにリファクタリングしました。

return if user

注意するべき点としては、条件がfalseになりうる場合、nilと区別をする必要があります。そういった場合はunlessnil?を使う方がわかりやすいかもしれません。

まとめ

今回は「改訂新版 良いコード/悪いコードで学ぶ設計入門」を参考に、プロダクトのソースコードから「悪いコード」を探してリファクタリングしてみました。

本著では、さらに大きな「悪いコード」の事例についても紹介されており、実際に探してみるとそのようなコードもちらほらありました。短い時間だったため大きな設計変更はできませんでしたが、小さな変更でもコードの可読性が向上し、コードの意図が明確になることを実感しました。

また、なんとなく「悪いコード」と感じていた箇所が、本著を読んでみるとどのような問題があるのかが理解でき、リファクタリングの方向性が見えてきたのもよかったです。

今後も、本著を参考にしながら新規の設計やリファクタリングを行っていきたいと思います。


ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers