このブログの内容をポッドキャストでも配信中！ こんにちは。ソフトウェアプロセス改善コーチでFindy Tech Blog編集長の高橋（ @Taka_bow ）です。 さて、前回の続きです。 tech.findy.co.jp 順調に行っていたかに見えたState of Devops Reportですが、ここにきて大きな壁が立ちふさがります。それが、 ソフトウェア界の巨匠Martin Fowler（マーティン・ファウラー） でした。 Martin Fowler(Image source: Wikimedia) このブログの内容をポッドキャストでも配信中！ Martin Fowler氏とは 巨匠の不満 2015 State of Devops Report DORAの設立へ 2016 - 2017 State of DevOps Report DORA激動の年 Puppet版State of DevOps Report GoogleになってからのState of DevOps Report 入れ替わる著者陣 David Farleyの登場 Eliteレベルがまた消える Four Keysの定義が変更 ソフトウェア開発は、今も昔も、どこか実験的である Martin Fowler氏とは （良くご存じの方は飛ばしてください） Martin Fowlerを知らない方向けに簡単に紹介すると、ソフトウェア設計やアジャイル開発の分野で世界的に影響力を持つスーパーエンジニアです。「マイクロサービス」の提唱者であり、彼の著書『リファクタリング』は、コードの品質を向上させる方法論としてエンジニアのバイブルとなりました。 www.ohmsha.co.jp 個人的な印象は、最初は「UMLモデリング」に長けた方という印象だったのですが、徐々に「パターン」の話が多くなり、最終形態として「アジャイル」に話題が移っていった気がします。 また、この写真、エンジニアだったら見たことありますよね？ Alistair CockburnのFacebookより( https://www.facebook.com/TotherAlistair/posts/10156214284634035 ​) アジャイルマニフェスト （アジャイルソフトウェア開発宣言） の背景画になってるアレですね。 この、ホワイトボードを指さしている人物こそMartin Fowlerそのひとです。（と、言われています） アジャイルマニフェストの署名者の一人であり、 ブログ や講演を通じてアジャイルを実践的に解説してくれる重要な立役者です。 巨匠の不満 さて、State of DevOps Reportの話に戻しましょう。Martin Fowler 本人によって、書籍「LeanとDevOpsの科学[Accelerate] 」 *1 の冒頭では、次のようなエピソードが寄稿されています。 本書に寄せて 2、3年前、あるレポートを読んでいたら、こんな文に出くわしたーー「今や我々は自信をもって断言できる。IT部門のパフォーマンスの高さには、生産性、収益性、そして市場占有率を高める効果があり、組織全体の業績と高い相関をもつ」。この手のレポートは即、 ゴミ箱に投げ捨てる のが私の通常の反応である。大抵は 「科学」を装ったたわごと にすぎないからだ。しかしそのとき読んでいたのは 『2014 State of DevOps Report （DevOpsの現況に関するレポート2014年版）』 であったため、私はためらった。著者の1人が私の同僚であり友人でもある Jez Humble氏 で、私に負けず劣らずこの種のたわごとを嫌う人物であることを知っていたからだ（もっとも、正直言ってゴミ箱に投げ捨てなかった理由はもう1つある。あのレポートはiPadで読んでいたのだった）。 苛烈な文章です。紙だったら捨てられていたのでしょうか！Martinは、さっそくNicole ForsgrenとJez Humbleと3人で話す機会（電話会議）を作ります。 Forsgren氏は根気強く丁寧に研究の論拠を説明してくれた。その説明は、そういった調査・分析方法には詳しくない私にとっても十分な説得力があり、通常をはるかに上回るレベルの（学術論文で発表される研究さえ凌ぐ）厳密な分析が行われている、ということが理解できた。 実際に書籍が出版されるのは、この会議から4年後（2018年）になるのですが……2014年時点で、まずは一旦は納得したようです。 しかし…… そのため、 私はその後もState of DevOpsレポートを興味深く読み続けていたが、その一方で不満も募ってきた。 どの年度のレポートも研究の成果を公表するばかりで、Forsgren氏が電話で私にしてくれたような説明が一切ないのである。おかげでレポートの信頼性が大きく損なわれていた。 推測だけに基づいた研究ではないことを示す根拠がほぼ皆無なのだ。 Martin Fowlerはレポートの方針に納得がいっていないようです。 そこで私も含めて内情を知る者が3人を説得し、 研究の調査・分析手法を紹介・解説する本を執筆してもらった。 このように、Martin Fowlerの不満があったからこそ「LeanとDevOpsの科学[Accelerate] 」が存在すると言っても過言ではありません。 「LeanとDevOpsの科学[Accelerate] 」が技術者からすると慣れない文体で書かれているのは、あれが技術書ではなく 「研究の調査・分析手法を紹介・解説する本」 だからだと思われます。統計手法の解説本ですものね。 2015 State of Devops Report Martin Fowlerから「根拠の提示がない」と言われた2015 State of DevOps Report ですが、前年と比べ分析に苦慮していた様子が伺えます。 まず、Change Failure Rate（変更失敗率）は、あいかわらずITパフォーマンスの主要な構成要素（construct）からは除外されています。レポートには具体的な事に触れられていませんでしたが、後日出版された「LeanとDevOpsの科学[Accelerate] 」には次のような記述がありました。 クラスター分析では「ハイパフォーマー」「ローパフォーマー」「ミディアムパフォーマー」のいずれの集団についても、この4つの尺度で有意な分類と差別化（チームのカテゴリー化）が行えた。ところが、この4つの尺度で1つの構成概念を得ようとすると問題が生じた。 妥当性と信頼性を検証するための統計的仮説検定にパスしないのである。 分析の結果、リードタイム、リリース頻度、サービス復旧までの所要時間の3つの尺度だけを使えば、妥当で信頼性のある構成概念が得られることが判明した。 ちょっと分かりにくい文章なので整理すると、ソフトウェアデリバリーのパフォーマンスを正確に測定するには、 「リードタイム」「リリース頻度」「サービス復旧までの所要時間」の 3つの尺度だけなら 信頼性高く妥当な評価ができる。 変更失敗率も重要な指標であり、これら 3つの尺度と強い相関はある 。が、独立した構成概念として扱うには適していない。 「変更失敗率」は予測しずらい 異質な指標 であり、分析や予測の際には補足的な要素として考慮する必要がありそうです。最新の2024 DORA Reportでも「変更失敗率」はイレギュラーな結果を残しています（別ブログで詳しく触れたいと思います）。 2015年のパフォーマンス・クラスターはSuper High、High、Medium、Lowに分けられ、それぞれ「4段階のスピード」で集計されました。 2015 State of DevOps Reportより しかし、パフォーマンスの傾向を特定するまでには至っていません。かろうじて、高パフォーマンスチームと低パフォーマンスチームの間には、明らかに大きな差がある、ということを突き止めたに過ぎませんでした。 【高パフォーマンスチームと低パフォーマンスチーム間のITパフォーマンス指標の比較】 2015 (Super High vs. Low) 2014 (High vs. Low) Deployment Frequency 30x 30x Deployment Lead Time 200x 200x Mean Time to Recover (MTTR) 168x 48x Change Success Rate 60x 3x DORAの設立へ 翌年2016年10月、Nicole ForsgrenとJez HumbleはDevOps Research and Assessment (DORA)を立ち上げます。これは、誰からの支援（投資）を受けずに立ち上げた会社だったそうです。そもそも、なぜ会社設立に至ったのか？ 後日書かれたJez Humbleのブログをもとに解き明かしたいと思います。 medium.com State of DevOps Reportの研究は地道に成果を上げ始め、その取り組みが実際のビジネス成果を改善することも証明し、多くの企業からデータを集めることにも成功していました。 一方で、組織が抱える2つの大きな問題も見えてきたそうです。その2つとは…… ビッグバン型変革の問題 多くの組織が陥った失敗パターンの代表例が「ビッグバン型変革」でした。これは、アジャイル手法と成熟度モデルを一度に導入しようとしたアプローチです。「どんな組織にも当てはまるテンプレート」として導入されたものの、実際の組織の状況とは相容れないことが多く、持続可能な改善にはなかなかつながりませんでした。 特に大きな問題は、現場で働く実務者の関与が不足していたことでした。日常業務の中で原則や実践を少しずつ試しながら改善していくプロセスが欠如しており、このことが変革の成功率を大きく下げる要因となっていました。 コンサルタントモデルの問題 多くの組織は改革のためにコンサルタントを採用し、現状分析と改善策の提案を求めました。しかし、このアプローチにも課題がありました。コンサルタントが話を聞けるのは、実際に作業を行っている現場の人々のほんの一握りに過ぎません。さらに、改善提案はコンサルタント個人の専門知識に大きく依存することになり、客観的に進捗状況を追跡することも難しくなりました。 実は、このやり方はコンサルティング会社にとっても理想的なビジネスモデルとは言えませんでした。なぜなら、優秀な人材を現場に配置しなければならないにもかかわらず、継続的な仕事が保証されているわけではなかったからです。また、このアプローチは規模の拡大も難しく、ビジネスとしての成長にも限界がありました。 これらの問題認識から、NicoleとJezは、アルゴリズムを活用して組織の改善領域を特定し、具体的な改善戦略を提案できるプラットフォームの必要性を認識しました。 特に注目すべきは、変革や改善を 「どこから始めるべきか？」 という組織からの本質的な問いに、データとアルゴリズムを用いて客観的に答えられる仕組みを作ろうとした点です。 この話題が出た時、Nicoleの目が輝きました。「ねえ、もしソフトウェアデリバリーのプロセス全体から何十人もの人々のデータがあれば、その質問に答えることができる。どのアルゴリズムを使うべきか、そしてそれをどのように修正すべきかも分かっている。これは 制約理論（TOC）の問題 に過ぎないのよ！最も賢く、効率的な方法で戦略を立てる方法を伝えることができるわ。」 私は一瞬考えて言いました。「待って、本当に？それならば作ってみよう！」そして、そこからDORAは誕生したのです。私たちは翌日からモックアップの作成に取り掛かりました。 Jez Humbleのブログから 2016年にDORAは設立されました。同年10月にはNicoleがフルタイムでの経営を開始し、DevOps Enterprise Summitでは最初の顧客となったCapital Oneとともに、DORAの正式な「お披露目」が行われています。 2016 - 2017 State of DevOps Report かくして、Puppet + DORA の連名で発表された2016年と2017年のState of DevOps Reportは、制約理論をベースにしたアルゴリズムを活用し、数千の組織から得られたデータを統計的に分析することでDevOpsの実践と組織のパフォーマンスの関係性を客観的に実証しました。 【2016 パフォーマンス指標】 パフォーマンス指標 High Medium Low Deployment Frequency オンデマンド（1日複数回） 週1回〜月1回 月1回〜6ヶ月に1回 Lead Time for Changes 1時間未満 1週間〜1ヶ月 1ヶ月〜6ヶ月 MTTR 1時間未満 1日未満 1日未満* Change Failure Rate 0-15% 31-45% 16-30% * ローパフォーマーは概して（統計的に有意なレベルで）成績が悪かったが、中央値はミディアムパフォーマーと変わらなかった。 【2017 パフォーマンス指標】 パフォーマンス指標 High Medium Low Deployment Frequency オンデマンド（1日複数回） 週1回〜月1回 週1回〜月1回* Lead Time for Changes 1時間未満 1週間〜1ヶ月 1週間〜1ヶ月* MTTR 1時間未満 1日未満 1日〜1週間 Change Failure Rate 0-15% 0-15% 31-45% * ローパフォーマーは概して（統計的に有意なレベルで）成績が悪かったが、中央値はミディアムパフォーマーと変わらなかった。 これらの結果を元に読み取った洞察が、あの有名な 「パフォーマンスの改善と、安定性と品質の向上との間に、トレードオフの関係はない」 というものです。 さらに、統計的に有意な形で改善できるケイパビリティ（組織全体やグループとして保持する機能や能力）を24個特定したのです。このケイパビリティモデルは、研究の進展とともに進化し続けています。 これこそが、DORA設立の背景にあった 「どこから始めるべきか？」 の答えでありFour Keysのパフォーマンス・スコアと、この相関図を見比べながら改革や改善の戦略を立てられるようしたことがDORA研究のもたらした最大の成果と言えます。 LeanとDevOpsの科学[Accelerate] 図A.1 本研究の全体の構成 を元に筆者が作成 また同じ年2016年に、Gene KimとJez Humbleは他の著者とともに"The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations"（邦題：The DevOps ハンドブック 理論・原則・実践のすべて）を刊行します。 bookplus.nikkei.com この本の内容は、DORAが提唱したケーパビリティモデルを補完する内容であり、DevOpsに必要な実践内容が書かれた本です。 2021年には2nd Editionが刊行されているのですが、残念ながら日本語訳はありません。 itrevolution.com なお、2nd Edition ではDr. Nicole Forsgrenも新たに参加し、加筆しているという個人的には胸熱な展開になっています。 DORA激動の年 2018年は、DORAにとって激動の年でした。 まず、2018年3月27日、かねてより進めていた新しい書籍が発売となります。 Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations （邦題「LeanとDevOpsの科学」）です。 itrevolution.com この本の出版でMartin Fowlerと約束を果たしたことになります。冒頭で述べた通り、この本はDORAの「研究の調査・分析手法を紹介・解説する本」として生まれました。 発行はIT Revolution Pressで、DORAの二人Nicole Forsgren、Jez Humble、そしてIT RevolutionのGene Kimの名前で発行されました。 ここにPuppet Labsのメンバーはいません。（謝辞の中には出てきますが） そして「LeanとDevOpsの科学」が出版された翌月、書籍名（原題"Accelerate"）を冠した Accelerate State of DevOps Report という、新しいプログラムを発表します。 これは、長年共に歩んできたPuppet社とのパートナーシップ解消を意味しました。DORAは、次のパートナーとしてGoogle Cloudを選択したのです。当時のインタビュー記事があります。 www.infoq.com 新しい Accelerate State of DevOps Reportは 2018年8月29日にリリース されます。 筆者としてクレジットされたメンバーは3人だけでした。 Nicole Forsgren PhD（ニコール・フォースグレン博士） Gene Kim（ジーン・キム） Jez Humble（ジェズ・ハンブル） 2018 Accelerate State of DevOps Reportの表紙 パートナーであるGoogle Cloudがダイヤモンドスポンサーであることはもとより、ゴールドスポンサーがAmazon Web Services、CA Technologies、CloudBees、Datical、Deloitte、Electric Cloud、GitLab、IT Revolution、Microsoft、PagerDuty、Pivotal、Redgate、Sumo Logic、Tricentis、XebiaLabsであり、非常に豪華です。 肝心の中身ですが、2018年のパフォーマンスの指標とレベルにはちょっとした変化が生じます。 それは、MTTRが "Time to restore service" という言い方に変わったことと、レベルに初めて Elite が登場したことです。 【2018 パフォーマンス指標】 パフォーマンス指標 Elite High Medium Low Deployment Frequency オンデマンド（1日複数回） 1日1回〜週1回 週1回〜月1回 月1回〜6ヶ月に1回 Lead Time for Changes 1時間未満 1日〜1週間 1週間〜1ヶ月 1ヶ月〜6ヶ月 Time to restore service 1時間未満 1日未満 1日未満 1週間〜1ヶ月 Change Failure Rate 0-15% 0-15% 0-15% 46-60% このように、リサーチは順調であったようですがDORAのCEO兼主任研究員であったDr. Nicole Forsgrenには大きな重圧がかかっていたようです。 この頃のことをJez Humbleはブログで次のように振り返っています。 経費を抑えた自力での会社運営には大きな代償がありました： それは燃え尽き症候群です 。スタートアップは創業者を疲弊させることで有名ですが、私たちも例外ではありませんでした。特に最も大きな負担を背負っていたのはNicoleでした。CEOとして彼女は、会社の戦略、財務、そして事業運営全般に責任を負っていました。それだけではありません。CEOとして市場戦略の立案と実行をほぼ一人で担うだけでなく、State of DevOpsレポートの主任研究者、『Accelerate』の主執筆者、そして買収交渉の責任者も務めていました。彼女が言うように、これらの成果はすべて何年もかけて築き上げたものですが、驚くべき仕事の処理能力を持っていた彼女でさえ、膨大な時間の労働なしにはこれらを実現することはできなかったでしょう。 これこそが投資を受けなかったことの代償でした - より大きなチームを雇って、この重荷を分散することができなかったのです。 Jez Humbleのブログから 2018年12月、Nicole Forsgrenは DORAをGoogleに売却する決断をしたのでした。 Puppet版State of DevOps Report 一方、Puppet社も2018年は独自のState of DevOps Reportを発行します。 しかし、これはDORA版とは異なるポリシーで編集されたものでした。2013年版に原点回帰するかの如く、DevOpsの進化の段階を特定し、DevOpsへの変革プロセスの定量化に舵を切っています。 Puppet版 2018 State of DevOps Reportについて語る人物は、あのAlanna Brownでした。 その後、Puppet社は、2022年4月にソフトウェア開発ツール大手 Perforce Software, Inc. に買収 されましたが、現在もState of DevOps Reportはシリーズを継続中であり、主にDevOpsに取り組む現場での実用性に重点を置いています。 2024 State of DevOps Report GoogleになってからのState of DevOps Report Googleの一員となったことで、安定した環境、持続可能な研究環境を手に入れたDORAは、途中COVID-19による2020 DORA Reportの中止もありましたが、晴れて今回で10冊10年目を迎えることができました。 ここでは2019年〜2023年までのトピックを駆け足で紹介します。 入れ替わる著者陣 2019年にGene Kim、2021年にはDr.Nicole ForsgrenとJez HumbleがDORAを去ります。現在は、他のDORAメンバーやGoogleのリサーチャーを中心に研究が引き継がれています。 Gene Kim は現在もIT Revolutionの代表であり、執筆活動や講演を精力的にこなしています。2019年に来日しており、DevOpsDays Tokyo 2019のキーノートセッションに登壇しています。（私は現地で拝聴できました！） thinkit.co.jp Jez Humble は現在もGoogleに席を置きSRE(Site Reliability Engineering)のエンジニアとして活躍する傍ら、カリフォルニア大学バークレー校（UC Berkeley）の教員も続けているようです。 www.ischool.berkeley.edu Dr.Nicole Forsgrenは現在Microsoft Research のパートナーとして Developer Experience Lab を率いており、ACM Queue の取締役も務めています。最近は、科学を活用しソフトウェア開発者をより楽しくする研究を実践しています。DevExやSPACEフレームワークに関する研究論文を発表し、精力的に活動中です。 彼女の最近の論文について、以前解説ブログを書いたので貼っておきます。 tech.findy.co.jp また、今年の6月に来日しファインディ主催の「開発生産性Conference 2024」にて基調講演をご担当頂きました。 Dr. Nicole Forsgren （開発生産性Conference 2024にて） David Farleyの登場 2022年と2023年の2年間だけ、著名なエンジニアDavid(Dave) Farley（デイビッド（デイブ）・ファーリー）が関わりました。 David(Dave) Farley(Image source: InfoQ.com) 彼は、Jez Humbleと共にベストセラー「Continuous Delivery」を書いた人物です。 www.kadokawa.co.jp 書籍「Modern Software Engineering」の筆者でもあり、文中、Dr. Nicole ForsgrenにまつわるエピソードやDORAの研究成果が引用されており、非常に参考になる本です。 bookplus.nikkei.com Eliteレベルがまた消える 2022年の分析では、 パフォーマンスレベルからEliteが消滅します。 これは、最もパフォーマンスの高いクラスタが、2021年のEliteの特徴を示していなかったためと述べられています。翌年2023年は復活しました。 これは、クラスター分析の特性として仕方のない現象でもあります。クラスター分析は、データの分布やその年の回答者の特性に基づいて自然に分類を形成する手法であり、 事前にクラスター数やその特徴を固定するものではありません。 そのため、特定のパフォーマンス層が少数であったり、他の層と重なりがある場合、ある年には明確なクラスターとして現れず、翌年に再び明確化することがあります。この柔軟性こそがクラスター分析の利点であり、 データに忠実である ことを意味しています。 Four Keysの定義が変更 2023年から、Four Key Metricsの一部名称と定義が変更され、より簡潔かつ実務的な表現に更新されました。次の表に、2022年までの定義と2023年の定義、および具体的な変更点をまとめています。 指標 2023年の定義 2022年までの定義 変更点 Deployment frequency (デプロイ頻度) 変更を本番環境に push する頻度。 主なアプリケーションまたはサービスで、組織が本番環境にコードをデプロイする頻度、またはエンドユーザーにリリースする頻度はどのくらいか。 定義が簡潔化され、 本番環境への変更適用に焦点が絞られています。 Lead time for changes (変更のリードタイム) コードの変更を commit してからデプロイするまでの時間。 主なアプリケーションまたはサービスで、変更のリードタイム（commit されたコードが本番環境で正常に実行されるまでの時間）はどのくらいか。 定義が簡潔化され、 コミットからデプロイまでの具体的な工程に限定。 「本番環境で正常に実行される」という表現が省かれています。 Change failure rate (変更失敗率) デプロイにより障害が発生し、すぐに対処する必要が生じる頻度。 主なアプリケーションまたはサービスで、本番環境に変更を加えた、またはユーザーに変更をリリースしたとき、サービスの低下（サービス障害、サービスの停止など）が発生して、対策（修正プログラム、ロールバック、フィックス フォワード、パッチなど）が必要になった割合はどのくらいか。 「デプロイにより障害が発生し」という表現 に変更され、障害の発生原因がデプロイに限定。具体的な対策例が削除されました。 Failed deployment recovery time (失敗デプロイの復旧時間) (旧名称: Time to restore service (サービス復旧時間)) デプロイの失敗時に復旧にかかる時間。 主なアプリケーションまたはサービスで、サービスのインシデントや、ユーザーに影響を与える障害（計画外のサービス停止やサービス障害など）が発生した場合、サービスの復旧に通常どれくらいの時間がかかるか。 指標名が変更され、定義が「デプロイの失敗」に絞られました。 例として挙げられていた「計画外のサービス停止やサービス障害」が削除されました。 ソフトウェア開発は、今も昔も、どこか実験的である ここまでが去年までの振り返りとなります。 前回のブログで、Tom DeMarco はのIEEE Software誌を引用し「ソフトウェアの力で世界を変えるようなプロダクトを生み出すことの方が重要」というDeMarco自身の「気づき」について引用しました。実は、彼はその記事の最後で、こう締めくくっています。 Photo of Tom DeMarco by Hans-Rudolf Schulz ソフトウェア開発は、今も昔も、どこか実験的である。 実際のソフトウェアの構築はそれほど実験的ではありませんが、その構想は実験的です。そして、この点にこそ私たちの焦点が当てられるべきでしょう。私たちは常にここに焦点を当てるべきでした。 (Tom DeMarco, 2009) DORAの10年は、まさにDeMarcoが語った「ここに焦点」を当て続けた挑戦そのものだと感じます。日々の実践と実験の中から何が本当にチームを強くし、ソフトウェアをより良いものにするのかを探求し続けたその姿勢こそ、彼の言葉を現実のものとし未来を照らし出す希望そのものだと私は信じたいのです。 では、いよいよ2024 DORA Report の中身を見ていきましょう！ 次回に続きます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers *1 : Forsgren, N., Humble, J., & Kim, G. (2018). LeanとDevOpsの科学 [Accelerate]: テクノロジーの戦略的活用が組織変革を加速する. インプレス.

このブログの内容をポッドキャストでも配信中！ こんにちは。ソフトウェアプロセス改善コーチでFindy Tech Blog編集長の高橋（ @Taka_bow ）です。 2024年10月23日、2024 DORA Accelerate State of DevOps Report、通称DORA Reportが公開されました。 2024 DORA Accelerate State of DevOps Report 表紙 このレポートは、ソフトウェア開発における運用と実践について、科学的な手法で調査・分析した結果をまとめたものです。 私は毎年このレポートを楽しみにしています。今年は10回目10年目の節目ということで、いつもより丁寧に読みました。 詳しい人でしたら、10年よりもっと長くないだろうか？と不思議がる方もおられるでしょう。 その辺の複雑な事情を含め、DORA Report 10年間の軌跡とその上に成り立つ最新レポートを解説したいと思います。全4回の予定です。 本記事では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のこちらのページ からダウンロードできるので、ぜひ一次情報に触れてみてください。 このブログの内容をポッドキャストでも配信中！ DORAの知見を「実践」に活かすために 科学とは何か？ 「科学的リサーチ」方法とは 定量的データと統計分析がもたらす信頼性 DORA Report 10年の変遷 State of DevOps Report のはじまり なぜ2013年版はカウントされないのか？ Dr. Nicole Forsgren の参画 最初はFour Keysじゃなかったし、Eliteも居なかった DORAの知見を「実践」に活かすために 私の35年のエンジニア人生を振り返ると、かなりの時間「意味のない計測データ」の収集と加工に時間を費やしたと思います。なぜなら、（その時の）品質保証部門がプロダクトの「出荷」をなかなか認めてくれないからです。 いま思い出すと、 私は被告側の弁護士のようであり、品質保証部門はまるで検察側のよう でした。 裁判長は、事業部のトップです。 私はプロジェクトを終わらせるために、ありとあらゆるデータを集めて「そのプロダクトは動く。（きっと）問題ないはずだ！」を弁護する必要がありました。 DFD（data flow diagram）の生みの親であり、 「ピープルウェア」「デッドライン」等の名著 で有名なTom DeMarco（トム・デマルコ）というエンジニアの巨匠がいます。 Photo of Tom DeMarco by Hans-Rudolf Schulz 彼は、若かりし頃（1982年）の論文で次のような言葉を発しました。 「計測できないものは制御できない」 “You can’t control what you can’t measure.” これは、私のような古いエンジニアにとっては、しばらくのあいだ 呪言 となりました。 しかし、2009年7月、IEEE Software誌7月8月合併号 *1 に、Tom DeMarco は衝撃的な記事を寄稿します。 タイトルは ”Software Engineering: An Idea Whose Time Has Come and Gone?（ソフトウェアエンジニアリング：その考えは、もう終わったことなのか？）” “You can’t control what you can’t measure.”（計測できないものは制御できない） このセリフには本当の真実が含まれているのですが、私はこのセリフを使うことに違和感を覚えるようになりました。 (中略)例えば、過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算通りに終わらせることができないことで自らを苦しめてきました。 この文章は当時、Tom DeMarco 自身が「測定できないものは制御できない」は誤りだったと認めた！ということで業界に衝撃が走りました。しかし、Tom DeMarco が本当に言いたかったことは、次の文章に含まれます。 しかし、先ほども申し上げたように、これは決して至上命題ではありませんでした。 もっと重要なのは、世界を変えるような、あるいは企業やビジネスのあり方を変えるようなソフトウェアを作るという「変革」です。 Tom DeMarcoが指摘したように、時代はさきほどのような「裁判ごっこ」よりも、もっと顧客との関係性を重視する方向に確実に変化してきました。それが、リーンであり、アジャイルでありDevOpsなのだと思います。 そんな中で登場してきたFour Keysですが、出会ったときの衝撃は今でも鮮明に覚えています。その指標があまりにもシンプルで、なおかつ説得力に満ちていたからです。 DORAの研究成果は決して一時的なトレンドではありません。Four Keysを単なる「流行り」と捉えるのは誤りです。しかし、その一方で、すべてを鵜呑みにする必要もありません。 2024年で10周年を迎えたDORA Reportには、この取り組みが成熟してきたことを示す重要なメッセージが随所に見られます。その代表例が"Applying insights from DORA"（DORAの知見を実践に活かすために）という章です。 一部を訳します。 私たちの調査結果は、皆様が独自の実験や仮説を立てる際の参考にしていただけます。チームや組織に最適なアプローチを見出すために、変更による影響を測定しながら実験を重ねることが重要です。それにより、私たちの調査結果の検証にもつながります。結果は組織によって異なることが想定されますので、ぜひ皆様の取り組みを共有していただき、その経験から互いに学び合えればと思います。 これは、DORAの取り組みが科学的だからこそ言えることであり、数々の困難があったなかで10年間継続してこれた理由でもあると思うのです。 科学とは何か？ DORA Reportから少し脱線するのですが、とても大事なことなので説明させてください。 書籍「LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する」(原題"Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations") が、DORAの研究ベースに書かれていることは広く知られているところです。 book.impress.co.jp ところで、このタイトルの 「科学」 は何を指しているのでしょうか。 科学とは「なぜだろう？」という疑問に対して、実験と観察を重ねながら、誰でも同じ結果を得られる答えを見つけ出す取り組み、と言えます。天文学者であり小説家でもあった、20世紀屈指の科学者カール・セーガンは科学について次のような表現をしていました。 "Science is a way of thinking much more than it is a body of knowledge." Carl Sagan 科学は、思考の方法であり、知識の集積ではない。 カール・セーガン 例えば、あるカレー店の人気の秘密を科学的に考えてみましょう。 「このカレーが美味しいのはなぜか？」という問いに対して、「シェフの腕が良いから」という個人的な感想や、「創業100年の伝統の味だから」という言い伝えだけでは、科学的な説明とはいえません。 科学的なアプローチでは、次のような調査と実験を行います。 100人のお客さんに同じ条件で食べてもらい、評価を集める スパイスの配合を少しずつ変えて、味の変化を測定する 調理時間や火加減を細かく記録し、最適な条件を探る 異なる調理人が同じレシピで作っても、同じ味になるか確認する このような過程を経て、「このスパイスの配合で、この温度で30分煮込むと、8割以上のお客さんが美味しいと感じるカレーができる」と言った、誰でも確認できる答えにたどり着けるのです。 開発の現場でも同じです。 「このやり方は効果的だ」という個人の経験や、「有名な企業がやっているから」という理由だけでは、本当にそれが正しいのかわかりません。 DORAの研究では、これらを科学的アプローチによってDevOpsの成功要因を明らかにしました。個人の経験や直感を超えて、数多くの組織のデータを分析し、客観的な証拠に基づいて「何が効果的なのか」を示したのです。これは単なる成功事例の集積ではなく、 科学的リサーチ によって検証された信頼性の高い知見なのです。 「科学的リサーチ」方法とは 科学的リサーチとは、現象を体系的に調査し、新しい発見や理論を導き出す手法です。観察から始まり、概念化、測定可能な 変数 への置き換え、モデル化という段階を経て、客観的なデータに基づいた結論を導きます。 向後, 千春. (2016). 18歳からの「大人の学び」基礎講座: 学ぶ, 書く, リサーチする, 生きる. 北大路書房. 図3-3に筆者が加筆 研究の流れは次の通りです。研究プロセスは次の4段階で進みます： 現象の観察 例えば、「なぜある開発チームは他のチームより高い成果を上げているのか」という問いからDORA（DevOps Research and Assessment）チームの研究が始まりました。 概念の特定 DORAの研究では、継続的デリバリー、継続的インテグレーション、自動化テストの実施などを成功要因として特定しました。 変数への変換 概念を測定可能な形に変換します。例えば、デプロイ頻度、変更リードタイム、障害復旧時間、変更失敗率などの具体的指標として定義します。 モデルの構築 収集したデータを統計的に分析し、因果関係を明らかにします。DORAの研究では、自動化テストの実施が変更リードタイムを短縮することや、チームの独立性がサービスの信頼性向上につながることを実証しました。 この一連のプロセスを通じて、科学的リサーチは客観的な検証可能性、再現性、そしてデータに基づく実証性という特徴を持ちます。これらの特徴により、DORA Reportは他の研究者が検証・発展させられる形でDevOpsの成功要因を明らかにできました。 定量的データと統計分析がもたらす信頼性 DORA Reportで用いられる科学的アプローチに対して、「都合の良いデータ解釈をしているのではないか」という批判を目にすることがあります。 しかし、この批判は科学的リサーチの本質を十分に理解していないことから生じている可能性があります。科学的リサーチとは、単にデータを収集し結果を得ることではなく、現象を客観的に理解し、実証可能な方法で結果を導き出す「方法論」そのものです。 この考え方は、DORAの研究において次のように具体化されています： 思考の方法の適用 DORAの研究では、特定の仮説（例えば「継続的デリバリーはパフォーマンス向上に寄与する」）を立て、それを証明または反証するために厳密な手法でデータを収集・分析しています。これは、科学的な「疑う」姿勢と「検証する」姿勢の両立です。 透明性と再現性 測定方法や分析手順を厳密に文書化し、他の研究者が追試可能な形で公開しています。これは、科学が単なる知識の蓄積ではなく、「共有されるべきプロセス」であることを象徴しています。 実践への応用 科学の思考方法をもとに導き出された成果が、現場での実践を通じて再び検証されています。たとえば、継続的デリバリーやテストの自動化が現実の組織で具体的な効果をもたらすことが示されています。 DORAの研究は10年にわたり、理論と実践の両面で成果を示してきました。カール・セーガンが述べたように、科学とは「知識の集積」ではなく「より良い問いを立て、より深く理解するための思考の道具」です。 DORAはこの科学的アプローチを用いて、LeanやDevOpsの成功要因を信頼性の高い方法論として確立し、現場の改善や組織変革に直接応用できる形で提供しています。毎年のクラスター分析結果の微細な変化も、このような継続的なデータ分析の重要性を示しているのです。 DORA Report 10年の変遷 今回の2024 DORA Reportでは、 "A decade with DORA"（DORAと共に過ごした10年） という章があります。DevOpsの起源から、State of DevOps Report誕生の背景、今日に至るまでの歴史が書かれています。 私は、その説明内容からこれまでの変遷を1枚の画にまとめてみました。 State of DevOps Reportの歴史 この画から分かるように「DORA Report 10年」とは 2014年版State of DevOps Reportから2024年版State of DevOps Reportまでを指します。2020年版はCOVID-19の影響で発行されていませんので、時間の経過を指す10年ではなく、この10冊が10年というわけです。 ですが、2013年版のState of DevOps Reportは10年の10冊には含まれていません。それはなぜなのか？ 順を追って解説します。 State of DevOps Report のはじまり 2011年、Puppet Labsで働いていたAlanna BrownはDevOpsについてより深く理解するための調査を開始しました。この調査は、「'DevOps'的な働き方がITにおける新しいビジネスの方法として台頭している」ということを裏付ける助けとなりました。 itrevolution.com この調査の成功をベースに、2012年に新たな調査を開始、2013年 Puppet LabsとGene Kim氏が率いるIT Revolution Pressが共同で、最初のState of DevOps Reportを発行しました。 書籍「LeanとDevOpsの科学[Accelerate] *2 」には、次のような記載があります。 「State of DevOps Report』の初回は2014年版だが、研究自体はそれ以前に始まっていたという点に留意されたい。Puppet社のチームは、 DevOpsという（まだそれほど知られていなかった）概念 をより良く理解し、それが現場でどう採用されつつあるか、組織パフォーマンスの改善を組織がどう実感しているかを把握するための研究を始めており、 2012年にこの研究への参画をGene Kimに求めた。 Gene KimはTripwire, Inc.の創業者兼CTOとして13年間務めたあと、IT Revolutionを創業し出版活動、DevOpsコミュニティへの貢献に尽力する人物でした。 itrevolution.com さらに、優秀なキーマンが巻き込まれることになります。 そしてGene Kimがその後、 Jez Humbleにも応援を仰ぎ、 ともに調査に加わって全世界の組織から4,000件の回答を集め、分析した。この種の調査では最大規模である。 Jez Humble は、カルフォルニア大学バークレー校で教鞭も執っているDevOpsの研究者でした。 github.com このような経緯を経て、2013 State of DevOps Reportはリリースされたのです。 なぜ2013年版はカウントされないのか？ 一言で言えば「調査方法が違う」からです。 現在の統計的アプローチが取られたのは2014年以降となります。2013年当時のPuppet社は、ITインフラストラクチャの自動化を支援するソフトウェアを開発・提供している会社でした。 その中心的なプロダクトは Puppet Enterprise であり、これはサーバーやクラウド環境、ネットワークデバイスなどの管理を効率化し、DevOpsやインフラ管理の自動化を推進するツールでした。 2013 State of Devops Report は、当時あまり知られていなかったDevOpsという概念を広め、Puppet Enterpriseの市場を開拓することが主な目的だったと思われます。実際、2013年版の調査による【主要な発見】は、やや意図的な印象を受けます。 【主要な発見】 DevOps導入状況 回答者の63%がDevOpsを導入（2011年から26%増加） 導入期間が長いほど、高パフォーマンス達成の可能性が5倍に上昇 高パフォーマンスを実現する共通実践 バージョン管理システムの使用（89%） コードデプロイの自動化（82%） DevOpsスキルの需要 コーディング/スクリプティング（84%） コミュニケーションスキル（60%） プロセス再構築スキル（56%） また、このレポートでは、後のDORAメトリクスの基礎となる4つの主要指標、デプロイ頻度・変更のリードタイム・変更の失敗率・復旧までの平均時間、いわゆるFour Keysが登場します。 しかし、現在の観点とは異なる分析結果でした。下記に、2013 State of DevOps Reportのパフォーマンス指標の解説と、グラフを転載します。 DevOpsの成熟度（未導入から12ヶ月以上前に導入） に基づいて、デプロイ頻度、変更のリードタイム、変更の失敗率、復旧までの平均時間という4つの主要なDevOpsパフォーマンス指標を分析しました。DevOpsの導入が成熟している組織は、 まだDevOpsを導入していない組織と比較して、すべての指標において著しく高いパフォーマンスを示しました。 2013 State of DevOps Report, p5 ご覧の通り、4つの指標はそれぞれ、「DevOpsを導入しているか否か」で期間分類されているのです。 Not Implemented（未導入） Currently Implementing（導入中） Implemented <12 Months（導入後12ヶ月未満） Implemented >12 Months（導入後12ヶ月以上） そして、このレポートは回答者の多くがDevOpsに関心の高い層に偏っている可能性を検証しておらず、バイアスの制御が十分でないという問題も抱えていました。 Dr. Nicole Forsgren の参画 2014年、State of Devops Report に大きな転機が訪れます。 それが、当時ユタ州立大学ハンツマンビジネススクールの教授であったDr. Nicole Forsgren（ニコール・フォースグレン博士）の参画です。 彼女は、ITインパクト、ナレッジマネジメント、ユーザー体験の専門家でした。 itrevolution.com 「LeanとDevOpsの科学[Accelerate] 」に書かれた「謝辞」には、Nicole Forsgrenの次のようなコメントがあります。 私が初めて皆さんのところへお邪魔して、「ここは違っています」などと指摘させていただいたとき（そのときの私の口調、失礼じゃなかったですよね、ハンブルさん？）、皆さんは私を部屋から蹴り出したりしなかった。 おかげで私はその後、忍耐力と共感力を養い、冷めかけていたテクノロジーへの愛を再燃させることができた。また、「あともう1回だけ、分析やってみて！」が口癖であるキム氏の無尽蔵の熱意と気合いは、我々の仕事を堅牢で大変興味深いものにしてくれている。 この謝辞から読み取れるように、Dr. Nicole Forsgren は2014年以降のState of Devops Reportに科学的厳密性をもたらした重要な人物です。それまでの調査手法に対して建設的なフィードバックをし、その結果、2014年のレポートから、より体系的で科学的なリサーチがもたらされます。 そして、2014年から2017年までの間、State of Devops Report は次のメンバーによって調査・研究がなされました。 Nicole Forsgren Velasquez（ニコール・フォースグレン・ベラスケス） Gene Kim（ジーン・キム） Jez Humble（ジェズ・ハンブル） Nigel Kersten（ナイジェル・カーステン） Puppet LabsのCIO Alanna Brown（アラナ・ブラウン） 2012年からState of Devops Report を担当する発案者 最初はFour Keysじゃなかったし、Eliteも居なかった Dr. Nicole Forsgrenの参加は、リサーチプログラムに科学的な厳密さをもたらしました。 このことで、最初のFour Keysは統計学的有意（＝確率的に偶然とは考えにくく、意味があると考えられる）が検証されるようになります。 このことで、 Change Failure Rate（変更失敗率）は、他の3つの指標とは有意な相関が見られなかった ため、ITパフォーマンスの定義から除外されています。 【2014 パフォーマンス指標】 指標 High Medium Low Deployment Frequency 1日に複数回 週1回〜月1回 月1回〜6ヶ月に1回 Lead Time for Changes 数分単位 1日〜1週間 1週間〜6ヶ月 MTTR 分単位 時間単位 日単位 とはいえ、2014 State of DevOpsレポートは、ソフトウェアデリバリーのパフォーマンスと組織のパフォーマンスの関連性を明らかにし、 「高パフォーマンスのITチームを持つ上場企業は、低パフォーマンスのIT組織を持つ企業と比較して、3年間で市場価値の成長率が50%高かった」 ということが発見されています。(2014 Accelerate State of Devops Report） 2014 State of Devops Reportは、Nicole Forsgrenの「科学的リサーチ」によって次第にデータは説得力のあるものに変わっていきました。 ところが、ここにきて大きな壁が立ちふさがります。 それが、 ソフトウェア界の巨匠Martin Fowler（マーティン・ファウラー） でした。 次回に続きます。 tech.findy.co.jp ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers *1 : https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf *2 : Forsgren, N., Humble, J., & Kim, G. (2018). LeanとDevOpsの科学 [Accelerate]: テクノロジーの戦略的活用が組織変革を加速する. インプレス.

こんにちは。 FindyでMLエンジニアをしているyusukeshimpo( @WebY76755963 )です。 今回は直近で公開した「 スキル偏差値ver.3 」機能について、その内容や具体的な機械学習モデルの作成方法について紹介します。 Findyのスキル偏差値とは？ スキル偏差値の概要 アップデートすることになった背景 スキルの見える化する、スキル偏差値ver.3の詳細 1.学習データの作成 1-1.使用言語ごとのデータ準備 1-2.ペアワイズ形式のデータ構築 1-3.勝敗アノテーションの付与 2.ランキング学習 2-1.ペアワイズデータの特徴量生成 2-2.機械学習モデルによる勝敗予測 3.モデルによるスコアリング 実装で苦労した点と解決策 1.モデル精度の担保 アノテーションの工夫 評価設計 2.言語固有の特徴量設計 言語特徴の言語化をしてデータ化 最後に Findyのスキル偏差値とは？ スキル偏差値の概要 まずはプロダクトの概要を説明いたします。 「スキル偏差値」は、Findyに登録されているユーザーのGitHubリポジトリ（※Open-access repositoryのみ）を解析し、 コミット量、OSSプロジェクトへの貢献度、他者からのコードの支持などに基づいて技術力をスコアリングする機能です。 GitHubの解析は機械学習技術を用いて実施しており、これまでに何度かアルゴリズムや学習データのアップデートを行ってきましたが、 今回は2017年のリリース以降で最も大幅なリニューアルを行なっており、大元のアルゴリズムや学習データの作り方自体をガラッと変更しています。 アップデートすることになった背景 アップデートの背景には、大きく分けて2つの理由が存在します。 リリースから数年が経過する中でユーザーの方からの要望が増えてきたから。 特に「言語別」のスコアに対する要望が強く、言語別のスキル判定の精度改善を求めるニーズが強かったため。 2023年以降、LLMやAI Agentが登場し、エンジニアリング（特にコーディング）の領域でも、それが当たり前に使われるようになってきたから。 今後エンジニアに求められる「スキル」も環境に合わせて変わっていくことが予想される中で、よりサービス開発や運用に直結する能力を評価できるモデルに進化させていく必要があったため。 上記「ユーザーボイス」と「開発を取り巻く環境変化」を受けて、このタイミングで新たな「スキル偏差値」を作ることを決めました。 スキルの見える化する、スキル偏差値ver.3の詳細 今回のスキル偏差値の開発では次の3つの手順でスキルの見える化をしています。 学習データの作成 ランキング学習 学習モデルによるスコアリング この3つの手順について詳しく解説します。 1.学習データの作成 ランキング学習を支えるのは「質の高いデータ」です。 GitHubリポジトリから収集したデータを加工し、言語ごとに特徴量を整備することで、正確なモデル構築を目指しました。 1-1.使用言語ごとのデータ準備 GitHubリポジトリを次の主要言語ごとに分類しました。 Python JavaScript TypeScript Go Ruby PHP 各言語ごとで重視される特徴量に違いがあり、言語ごとにデータを分ける方針にしました。 1-2.ペアワイズ形式のデータ構築 ランキング学習するために、今回は「ペアワイズ形式」のデータを用意しました。これは、2つのエンティティ間でどちらが優れているかを比較する形式です。 今回のケースではGitHubユーザー間のリポジトリ情報を比較し、相対的なスキル勝敗データを生成しました。また、ペアはバイアスが生まれないようにランダムでペアを作るようにしています。 1-3.勝敗アノテーションの付与 生成したペアデータに対して、上の図のようにスキルの「勝敗」をラベリングしました。 特にラベル基準をある程度明確化しておくと担当者間でのクロスレビューの際の議論がまとまりやすかったです。 2.ランキング学習 次に、上で用意した学習データに対して、次の2つのステップを経て、「ランキング学習」の手法を用いて特徴量間の比較します。 「ランキング学習」（Learning to Rank）は、複数ある事象の「順位」を目的変数とした場合に用いられる機械学習の手法で、身近な例としては「検索エンジン」などで使われています。 機械学習を用いた「ランキング学習」の実装にはいくつか方法がありますが、今回は上述したペアワイズなデータ間の「勝敗」を学習し、 2-1.ペアワイズデータの特徴量生成 2-2.機械学習モデルによる勝敗予測 以下、それぞれのステップを解説していきます。 2-1.ペアワイズデータの特徴量生成 ランキング学習するために、まずは各々のデータを機械が認識できる形にする必要があります。 具体的には、各データを「特徴化」し、ベクトル化した数値で比較できるようにしています。 当初はこの「特徴」抽出のプロセスについては、言語を問わずある程度一元化できると考えていましたが、 実験過程で、言語間の「特徴」に大きな違いが見られました。 詳細は社外秘情報にあたるため公開できませんが、一例として、ある言語では「Readmeなどのテキストの長さ」が重要な意味を持ちます。 別の言語だとボイラープレート内にReadme用のテキストが充実しているため「Readmeの長さ」を特徴として重視しない方が好ましい、という傾向が出ていました。 上記のように、言語ごとに利用者を取り巻く環境が大きく違う点も考慮し、現段階では「言語ごとに異なる特徴を採用する」という意思決定をしています。 *1 2-2.機械学習モデルによる勝敗予測 データを特徴化したら、機械学習モデルによるランキング学習をし、当該データ間の順位を予測します。 検討初期にはより複雑なモデルを利用することも検討しましたが、「言語ごとに個別のモデルを動かす」という仕様上の制約や、特徴抽出の工夫によりシンプルなモデルでも十分な精度が実現できたため採用しています。 上記のアルゴリズムにペアワイズの学習データとその勝敗を学習させ、勝敗の判定を行なっています。 モデルの精度についてはこちらも非公開ですが、検証方法としてはこちらも「複数人が判断した際の判断と同様の出力（＝勝敗）を出せるか」を基準に評価しています。 リリース時点で、対象としている6言語はいずれも人間の判断を8割以上の精度で模倣できており、一定正確なジャッジができていると判断しています。 *2 3.モデルによるスコアリング 学習モデルを作成したら、その推論結果を元にユーザーのスキルをスコアリングしていきます。 学習したのは、ペアワイズデータの勝敗ですので、計算したいユーザーと他のユーザーとの勝敗をシミュレーションして、それを元にユーザーのスキルスコアを算出します。 このスコアを一般的に偏差値計算をする数式に当てはめ、最後に調整（言語ごとに異なる尺度を正規化するなど）をしたものを「スキル偏差値」としています。 実装で苦労した点と解決策 上記を実装する上で困難な点が多々ありました。 今回は次の苦労した点と解決としてどんなことをしたかも説明していきます。 モデル精度の担保 言語ごとの特徴量 1.モデル精度の担保 アノテーションしたデータを使用しているので、モデルはアノテータに影響を受けます。 アノテータのバイアスを極力抑えて客観的に良いモデルを作成するための工夫が必要だったため、次の工夫をすることで精度改善を試みました。 アノテーションの工夫 データ作成時のアノテーションには次のような手順を導入しました。 言語経験者による判断: 経験者がアノテーションをすることで正確性を担保 ラベル基準の明確化: ラベル基準を言語化してアノテータに共有 クロスレビュー: 複数人がレビューすることでバイアスを極力抑える 例として、社内でRubyを日常的に利用する有識者へアノテーションの基準づくりを依頼しました。筆者は普段の業務でRubyを使用しないため、このように経験者から合意を得ることで、より良質な正解データを作成できました。 評価設計 アノテーションという定性的な評価を学習データにしているため、ただ単に評価関数の良し悪しで判断できません。 そんな中 どのようにモデルの精度を評価したのか も非常に重要かつ難しいポイントでした。 そこで、アノテーションとモデルの精度を担保するために定性と定量の両方で確認しました。 定量評価: 正解率や偏差値の分布を測定 定性評価: 偏差値の妥当性を人間が確認 勝敗の正解率を確認したのち、Ratingや偏差値を実際に算出しますが、正規分布に基づいているか、ユーザーはこの数値で妥当かを定性的に評価しました。 これによるアノテーション結果の正当性を確保しつつ、モデルの方向性も正しいと確認できました。実際には次のサイクルでモデル評価とアウトプット評価をして都度アノテーションから見直すこともしました。 2.言語固有の特徴量設計 また、言語ごとに特徴量設計をするのも苦労したポイントです。同じ特徴量では表現できなかったため、言語ごとに最適な特徴量設計を見つける必要がありました。 言語特徴の言語化をしてデータ化 言語ごとにどんな特徴を持っているのかを言語化し異なる特徴を設計しました。 例えば、あるプログラミング言語ではボイラーテンプレートが充実しているため独自ロジックにスキルが出やすい傾向にあったり、ライブラリの利活用が盛んなプログラミング言語など特徴量が変わってくることがわかりました。 この特徴量の言語化のフローは大きく4つのポイントに分かれます。 まず、仮説の立案し、各言語の特性を調査し、スキルの違いを反映するための特徴を言語ごとに仮説立てを行います。その後実験を重ねて、仮説に基づいて特徴量を作成し、推論結果や評価指標を確認します。 確認した結果に違和感があれば、仮説を見直して新たな特徴量を追加・修正します。これらを繰り返し、最後に評価基準と実際の結果にズレがあれば、特徴量の設計を見直し、適正化という流れを繰り返しました。 最後に 以上が スキル偏差値ver.3 の開発についてでした。参考にしていただければ幸いです。 また、弊社では機械学習エンジニア・データエンジニアなど一緒に働いてくれるメンバーを募集しております。 興味がある方は↓からご応募していただければと思います。 herp.careers *1 : 今回のリニューアルが6言語限定になったのも、上記の理由からモデルを言語別に作る必要があったためです *2 : 余談ですが、人間が判断した際も"意見が分かれる"ペアは10~20%程度存在するため、8割の精度というのはかなり妥当な水準だと考えています

こんにちは、ファインディでFindy Team+（以下Team+）を開発しているEND（ @aiandrox ）です。この記事は Findy Advent Calendar 2024 10日目の記事です。 adventar.org Team+ではコード管理ツール・イシュー管理ツール・カレンダーなど、様々な性質の外部サービスと連携して、エンジニア組織における開発生産性の可視化・分析を行うためのデータを取得しています。 この分析を行うためには、外部サービスごとに異なるデータ構造やAPI仕様の差を吸収した統一的なデータ管理を行う必要があります。この課題を解決するため、異なるサービスのデータを統合し、単一のUIで一貫性を持って表示する仕組みを整えています。 この記事では、コード管理ツールのデータインポートをどのようなアーキテクチャで実現しているかを紹介します。 Team+と外部サービス差分の例 全体のアプリケーションアーキテクチャ メリット 責務が明確になりコードの見通しがよい 不具合が起きたときの原因がわかりやすくなる 2種類のデータを扱うことで、柔軟性と速度を担保する 層ごとにスケールすることができる デメリット 層ごとの独立性が高いがゆえの複雑さがある リアルタイム性に欠ける 一部のリソースのみインポートするといった処理が難しい 各層について Client層 Importer層 Transformer層 API層 おわりに Team+と外部サービス差分の例 前提として、Team+では現在GitHub, GitLab, Bitbucket, Backlogから取得したコード管理系のデータを以下のように表示しています。 この画面の分析のために取得しているデータは、プルリクのステータス、コミット日、オープン日、最初のレビュー日、レビューステータス、マージ日です。 外部サービスごとの小さな差分の例として、プルリクのステータスがあります。Team+では「対応中」「クローズ」「マージ」の3種類がありますが、各サービスのAPIレスポンスの値は以下を返すようになっています。 GitHub GitLab Bitbucket Backlog open, closed opened, closed, locked, merged OPEN, MERGED, DECLINED, SUPERSEDED Open, Closed, Merged GitHubの場合、ステータスの値だけを参照してもクローズとマージの区別がつかないため、 merged_at に値が入っているかどうかで判定しています。また、GitLabの locked やBitbucketの SUPERSEDED のようなイレギュラーなステータスは、他の値に丸めるようにしています。 全体のアプリケーションアーキテクチャ 全体の流れは、以下のようになっています。これらのインポート処理は、各サービスごとに分割して全8インスタンスで行い、それぞれのインスタンス内で組織ごとに20プロセスで並列して処理しています（2024年12月時点）。 層 主な役割 Client層 APIの仕様差を吸収し、レスポンスをRepresentationインスタンスとして返す Importer層 エラーハンドリングをし、サービス独自テーブルに保存する Transformer層 各サービスごとのデータ形式差分を吸収し、共通テーブルに保存する API層 表示データのフロントエンド提供 GitHub, GitLabはClient層とImporter層の設計が少し違うため、この図では省略しています このように4つの層と2種類のテーブルを使うことで、以下のようなメリットとデメリットがあります。 メリット 責務が明確になりコードの見通しがよい この設計では、新しい外部サービスを追加する際はClient層とTransformer層、それぞれ単独で実装することができます。また、コードレビュー時も変更範囲が限定されるため、確認すべき箇所を絞りやすく、レビューの効率がよいです。 不具合が起きたときの原因がわかりやすくなる 例えば、外部サービスのAPIのエラーによってデータが取得できなかった場合、Importer層でエラーがキャッチされます。また、値がTeam+で扱うものとして想定外だった場合はTransformer層でエラーになります。 外部サービスのAPIを使っているため、こちらで対応できないエラーが起きることや想定されないデータが返ってくることは避けられませんが、それによる影響が最小限になるようにしています。 2種類のデータを扱うことで、柔軟性と速度を担保する Team+には、サービス独自テーブルと共通テーブルの2種類があります。前者はAPIレスポンスの形に近い形で保存することを目的とし、後者はTeam+で扱いやすい形式で保存することを目的としています。これにより、フロントエンドからのリクエストに対しては、外部APIと独立して安定したデータソースとして迅速に提供することができます。 他にも、サービス独自テーブルに保存されたデータはTransformer層でエラーが発生しても再利用可能なため、外部APIを再度叩く必要がありません。 層ごとにスケールすることができる 現時点では行っていませんが、Import処理とTransform処理が独立しているため、必要に応じて片方のみスケールするという選択肢を持つことができます。 デメリット 層ごとの独立性が高いがゆえの複雑さがある 層ごとに責務が分離しているため、全体の流れを把握するのが大変です。特に新しいメンバーが参加した場合、どの処理がどの層で行われているかを理解するまでに学習コストがかかります。また、デバッグ時には層の間をまたぐデータフローを追う必要があり、状況によっては負担になることもあります。 リアルタイム性に欠ける このアーキテクチャは、データの取得から変換、提供までを複数の層に分割しているため、一連の処理がリアルタイムで完結する用途には適していません。例えば、ユーザーがリアルタイムにデータを参照したい場合、現行のバッチ処理的なインポートでは対応が難しいです。 Team+でも、初回連携の際の一時的なデータ取得ではClient層しか利用していません。 一部のリソースのみインポートするといった処理が難しい このアーキテクチャでは、すべてのデータのImport処理が完了した後にTransform処理を行っています。これが完了するまで画面上にデータを表示できないため、Import処理に時間がかからないリソースから逐次的に表示できるようにするなどの柔軟性は持たせづらいです。 各層について Client層 この層では、外部サービスのAPIレスポンスや仕様がサービスごとに違うため、その差分を吸収することが大きな目的としています。 libディレクトリ配下に置いてGemのように独立して作用できるようにしつつ、アプリケーションで統一して扱えるようにしています。主に、以下のような処理を行っています。 外部サービスのAPIにリクエストを行い、そのレスポンスをアプリケーションで扱いやすい形に成形加工するRepresentationクラスに格納する リトライ処理を行う 例外を発生させる エラーに対しては、Rate limitのみリトライ処理を行っています。その他のエラーと、最大回数を上回ったエラーは例外を投げるようにしています。ここでは、主にレスポンスステータスを参照しています。 これらの処理には、外部サービス独自のGemは使わずスクラッチで実装しています。また、1ページごとに遅延実行をするようにしてメモリを圧迫しないように対策しています。 Importer層 Client層から取得したRepresentationインスタンスを使い、レコードごとのアソシエーションに応じて関連レコードと一緒に独自テーブルに保存します。 また、Clientインスタンスのような依存性を注入することで、Importerの単体テストを容易にしています。 class PullsImporter def self . call (client, repo_id :, repo_full_name :) new(client, repo_id :, repo_full_name :).call end def initialize (client, repo_id :, repo_full_name :) @client = client @repo_id = repo_id @repo_full_name = repo_full_name @user_finder = UserFinder .new end def call client.pulls(repo_full_name).each do |response| attributes = response.map do |representation| PullApiMapper .call(representation, repo_id :, user_finder :) end Source :: Pull .import!(attributes) end end end Importer内では、FinderやApiMapperなどを定義し、それを用いてインポート処理を行っています。 関連レコードの取得はFinderクラスを作成し、これを介するようにしています。これにより、関連レコードを読み込むためのN+1を最小限に抑えることができるようにしています。 class UserFinder def find_by ( uuid :) users_index_by_uuid[uuid] end private def users_index_by_uuid @users_index_by_uuid ||= Source :: User .reload.index_by(& :uuid ) end end ApiMapperは、Representationからサービス独自テーブルへの変換のためのattributes作成を行っています。関連レコード（この例ではuser）の外部キーを取得するためにFinderを渡しておき、レコード取得の処理はApiMapper内で行っています。 class PullApiMapper def call { repo_id :, user_id : user.id, title : representation.title, state : representation.state } end private attr_reader :representation , :repo_id , :user_finder def user @user ||= user_finder.find_by( uuid : representation.user.uuid) end end Transformer層 サービス独自のテーブルからレコードを取得し、各サービスのデータ構造の差分を吸収し、表示データ用のテーブルに保存します。 class PullConverter def self . call (duration) sources = Source :: Pull .where( updated_at : duration) attributes = sources.map { |source| PullMapper .new.call(source) } View :: Pull .import!(attributes) end end ここでもPullMapperが使われていますが、これはImporterで使われているApiMapperとは似ているようで少し違います。前者は、Representationクラスのインスタンスをテーブルに保存するためのもので、後者はモデルのレコードを共通テーブルに保存するためのものです。外部サービスのデータ形式の差分はここで吸収されることがほとんどです。 class PullMapper def call (source) { source_type : source.class.name, source_id : source.id, repo_id : source.repo.view_repo.id, user_id : source.user.view_user.id, title : source.title, status : to_view_status(source) } end private def to_view_status (source) return :merged if source.merged? return :closed if source.closed? :created end end API層 バックエンドから表示データ用のテーブルの値をフロントエンドに返します。ここでは、サービス独自テーブルにはアクセスせず、共通テーブルの値のみを使用します。 リアルタイムのデータ集計には独自のアーキテクチャを利用していますが、こちらに関してはまた別の機会にご紹介します。 おわりに 今回、Team+のデータインポート周りのアプリケーションアーキテクチャについて紹介しました。 このアーキテクチャは、最初からこの形だったわけではありません。複数の外部サービスと連携する中で、API仕様やデータ形式の違いに直面し、それらを克服するために少しずつ設計を見直してきました。また、例えば、初期にはエラー処理がClient層やImporter層に散在していたり、それぞれの層が密結合になっていたため、層ごとの役割分担を明確化しました。こうした試行錯誤を繰り返しながら、現在の仕組みに至っています。 今も、旧アーキテクチャの名残が残っている箇所があったり、データインポートの時間が長い組織があるといった伸びしろがあります。これからも、改善を重ねて、みなさんにとって価値のあるサービスを提供していきます！ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味のある方は、ぜひカジュアル面談で話を聞きに来てください！ herp.careers

こんにちは！ファインディでFindy Team+開発チームのEMをしている 浜田 です。 この記事はFindy Advent Calendar 2024 6日目の記事です。 adventar.org 今年の上旬、フロントエンジニア向けにバックエンド勉強会を開催しました。この記事ではバックエンド勉強会を開催した目的や内容、効果について紹介します。 バックエンド勉強会を開催した背景 バックエンド勉強会の概要 バックエンド勉強会の内容 RubyやRailsの学習 VS Codeのプラグイン設定 Rails console / dbconsoleを使ってみる ruby-lang.orgを読む Railsガイドの紹介 Railsの構成を説明 バックエンドのライブコーディング DBの基礎 SQL実習 SLQ実習で書いたSQLをActiveRecordで書く N+1問題 正規形 インデックス、実行計画 トランザクションとロック 外部キー まとめ バックエンド勉強会を開催した背景 私のチームが開発しているFindy Team+はWebアプリケーションとして提供しており、フロントエンドはReact/TypeScript、バックエンドはRuby on Railsを使用しています。 ファインディでは、エンジニア個人の志向に合わせて、特定の技術領域を深く理解することでバリューを発揮している方や複数の技術領域を幅広く扱ってバリューを発揮している方など様々な方がいます。 そのため、自分の得意領域以外への挑戦を推奨しています。 ただ、現在では1チームに6〜8名ほどのエンジニアで構成され、各自が得意領域を担当することで効率よく開発が進む状況です。 このような状況では、得意領域以外にチャレンジしたい気持ちがあったとしても、最初の一歩が踏み出しづらいものです。 そこで、今回はフロントエンドを主軸としているエンジニアがバックエンドに挑戦する一歩を後押しするためにバックエンド勉強会を実施しました。 バックエンド勉強会の概要 期間: 2024年2月〜8月 頻度: 毎週30分 回数: 23回 講師: 私 RubyもReact/TypeScriptも業務で使った経験あり 参加者: 3名 バックエンドほぼ未経験、または数年触っていない。React/TypeScriptはバリバリ書いている カリキュラム RubyやRails、DBの基礎 業務で使うコードを使ったライブコーディング バックエンド勉強会の内容 バックエンド勉強会では、前半はRubyやRails、後半はDBについて学習をしました。 業務で使っているコードを使ってAPI開発の基礎知識を学ぶことで、簡単なAPIの作成や修正ができることを目指しました。 RubyやRailsの学習 VS Codeのプラグイン設定 まずはエディタを整備しました。 参加者は全員VS Codeを使っていたので次のプラグインをインストールしました。 Ruby Ruby LSP Rails console / dbconsoleを使ってみる 開発環境には全員バックエンド環境も構築しているので環境構築は不要です。 RubyやSQLをサクッと試すことができるように、Rails console / dbconsoleの使い方を紹介しました。 railsguides.jp ruby-lang.orgを読む ruby-lang.org の一部を読み合わせしました。 読み合わせした箇所をいくつか紹介します。 他言語からのRuby入門 普遍の真理 Rubyでは、nilとfalseを除くすべてのものは真と評価されます。 CやPythonを始めとする多くの言語では、0あるいはその他の値、空のリストなどは 偽と評価されます JavaScriptを書いている人にとって 0 はFalsyですが、Rubyだと 0 はTruthyでありハマりやすいので強調しておきました。 不思議なメソッド名 Rubyでは、メソッド名の最後に疑問符(?)や感嘆符(!)が使われることがあります。 珍しいルールなのでこちらも詳しく説明しました。 ?はbooleanを返すメソッドにつけることが多く理解しやすいです。 # 偶数かどうかを判定するメソッド def odd? (n) n % 2 == 1 end !は破壊的メソッドに付けることが多く、破壊的メソッドと同じ役割だが破壊的ではないメソッドがある場合には破壊的メソッド側に!が付けます。ただし、破壊的メソッドしかない場合は!をつけません。 # !あり・なしメソッドがあるパターン str = " string " str.upcase! str # => "STRING", 元の値がstrが上書きされている str = " string " upcased_str = str.upcase str # => "string", 元の値が上書きされていない upcased_str # => "STRING", upcaseの結果がupcased_strに代入されている # 同名の非破壊メソッドがないため、破壊的メソッドだけど!がつかない str = " string " str.replace " STRING " str # => "STRING", 元の値が上書きされている また、Railsだと例外を発生させるかどうかで!を付けたり付けなかったりすることがあります。 hoge.save # 保存に失敗した場合falseを返す hoge.save! # 保存に失敗した場合例外を発生させる 「存在しなかった」メソッド Rubyはメッセージに対応するメソッドを見つけられなかったとしても諦めません。 その場合は、見つけられなかったメソッド名と引数と共に、 method_missingメソッドを呼び出します。 method_missingメソッドはデフォルトではNameError例外を投げますが、 アプリケーションに合うように再定義することもできます。 Rubyではメソッドが見つからなかった場合の処理を簡単に上書きできます。 アプリケーションコードで多用することはないですが、ライブラリではよく使われている仕組みなので知っておくと良いです。 class Hoge ; end hoge = Hoge .new hoge.fuga # undefined method `fuga' for an instance of Hoge (NoMethodError) # method_missingを上書き def hoge. method_missing (name, *args) puts " メソッドが見つかりませんでした: #{ name }" end hoge.fuga # メソッドが見つかりませんでした: fuga 演算子は糖衣構文(シンタックスシュガー) Rubyにおけるほとんどの演算子は糖衣構文です。 いくつかの優先順位規則にもとづいて、メソッド呼び出しを単に書き換えているだけです。 たとえば、Integerクラスの+メソッドを次のようにオーバーライドすることもできます。 class Integer # できるけれど、しないほうがいいでしょう def + (other) self - other end end Rubyでは"+"もメソッドです。面白い仕組みなので紹介しました。 メソッドなので次のような呼び方ができます。 1 + 2 # => 3 # 1(Integerのインスタンス)の+メソッドの引数に2を渡している 1 .+( 2 ) # => 3 Ruby 3.2 リファレンスマニュアル > オブジェクト Ruby で扱える全ての値はオブジェクトです。 「全ての値はオブジェクトです」はRubyの特徴だと思うので説明しました。 クラスをインスタンス化したものがオブジェクトなのは理解しやすいですが、数値や文字列などのリテラルもオブジェクトであり、クラス自体もオブジェクトです。 全てオブジェクトなのでメソッド呼び出しや既存メソッドの挙動を上書きなどを行えます。 Ruby 3.2 リファレンスマニュアル > クラス／メソッドの定義 ここでは次の項目について説明しました。 クラス定義 モジュール定義 クラスとの違いがわかりづらいので説明 インスタンス化できず、共通の振る舞いを複数のクラスで共有したい場合などに使うことが多い メソッド定義 引数がなければ()を省略できる 特異クラス定義 / 特異メソッド定義 / クラスメソッドの定義 Railsのモデルで多用するので説明 Ruby 3.2 リファレンスマニュアル > 制御構造 if文など基本的な制御構造やunlessなどRubyの特徴的なところを紹介しました。 また、forは他の言語では多用するがRubyではあまり使わずeachを使うことが多いということも説明しました。 Ruby 3.2 リファレンスマニュアル > 変数と定数 よく使うローカル変数、インスタンス変数、定数を説明しました。 Ruby 3.2 リファレンスマニュアル > リテラル さらっと全体を眺めつつ「シンボル」「ハッシュ式」「ヒアドキュメント」「%記法」は初見だと戸惑うポイントなので詳しく説明しました。 ハッシュ式 キーとバリューのペアを保持するオブジェクト。 キーには数値・文字列・シンボルが使える。キーにはシンボルを使うことが一般的。 { 1 => 2 , 2 => 4 , 3 => 6 } { " a " => " A " , " b " => " B " , " c " => " C " } { :a => " A " , :b => " B " , :c => " C " } { a : " A " , b : " B " , c : " C " } # シンボルの場合、このような書き方ができる。この書き方が推奨。 ヒアドキュメント 複数行の文字列を表示するときに使う。 << <<-: 終端子にインデントをかける <<~: インデントをいい感じに削ってくれる Railsガイドの紹介 Railsガイドについてはこの勉強会では紹介だけ行いました。 Railsの機能が網羅されており、最新バージョンに追従しているとてもよいドキュメントなので、困ったらまずはRailsガイドを読むことをおすすめしました。 railsguides.jp Railsの構成を説明 実際に開発しているバックエンドのディレクトリ構成を説明しました。 Gemfile / Gemfile.lock package.jsonみたいにライブラリを管理しているもの Dockerfile / Dockerfile.dev / compose.yml .devは開発環境用 compose.ymlはdocker composeの設定ファイル config 各種設定ファイル db データベーススキーマやマイグレーションファイル log ログファイル dockerで実行している場合、ここに出力されないので docker compose logs -f web で確認 lib 本体とは切り離して使えるライブラリが格納されている taskにコマンド実行するタスク(ジョブ)が格納されている app admin 管理画面用のgem activeadmin で使うクラス controllers MVCのC enums localeやメトリクスのenum情報 graphql GraphQLのgem graphql-ruby のquery/mutation/typeなど interactors interactor gemを使ってCUDのビジネスロジックを実装 Controller -> Interactor -> Modelの依存関係 jobs 非同期処理 mailers メール送信処理 models MVCのM DBアクセスクラスが一般的だが、分析クラスや外部接続クラスなども入っている views MVCのV バックエンドのライブコーディング RubyやRailsの基礎的な部分は抑えたので、ここからは実際にバックエンドのコードを使ってライブコーディングを行いました。 既存のGraphQLのQueryにfieldを追加 フロントエンドを開発しているときにバックエンドを触りたくなる最も多いケースは、APIのインターフェースの変更だと思います。 そこで、既存のGraphQLのQueryにfieldを追加するというテーマでライブコーディングを行いました。 GraphQLの新規作成 次はよりがっつりバックエンドを触るケースとして、次の仕様を満たすGraphQLをライブコーディングしました。 このテーマでAPIを作成するときに必要となるDBのテーブル作成・Model作成・GraphQL作成の一連の流れを学びました。 userに紐づくメモを保存する機能 ユーザーごとにメモは複数作成可能 1つのメモは100文字まで 空のメモはNG メモは1ユーザー10件まで ユーザーIDに紐づくメモを取得できる テキスト検索できる メモIDに紐づくメモを取得できる メモを新規登録できる メモを更新できる 自分のメモしか更新できない DBの基礎 バックエンドの学習を進めるうち、データベースの知識を底上げする必要があると感じたため、ここからはデータベースについて学びました。 SQL実習 既存のテーブルを使って、お題を取得するSQLを書いてもらいました。 単一テーブルのSELECT JOINを使ったSELECT 複数のテーブルをJOINするSELECT INNER JOIN、LEFT JOINの使い分け GROUP BY、HAVINGを使った集計 SLQ実習で書いたSQLをActiveRecordで書く Railsで開発する場合、生のSQLを書かずActiveRecord経由でDBにアクセスするので、SQL実習で書いたSQLをActiveRecordで書いてもらいました。 N+1問題 N+1問題について説明し、RailsでN+1を回避するプラクティスを紹介しました。 preload / eager_load / includes 結合が不要な場合はpreload、joinするときはeager_load(left outer join) includesはpreload or eager_loadを自動判断する。 意図せずクエリーが変わってしまうことがあるので使わない方が無難 経験上、includesで発行するSQLが変わって困ったことはあってもincludes禁止で困ったことはない Rails始めた人が絶対辿り着く記事 ActiveRecordのjoinsとpreloadとincludesとeager_loadの違い GraphQLではpreloadやeager_loadを使った先読みが適さないこともあるので注意 graphql-rubyのN+1を遅延ロードで解決する 正規形 リレーショナルデータベースを使う場合、第3正規形までは必修だと思うので非正規形と第1〜3正規形を説明しました。 インデックス、実行計画 テーブル設計をするようになったらインデックスの検討も必須なので説明しました。 インデックスはとても良いスライドがあるのでこちらを共有しました。 speakerdeck.com また、発行したSQLがどのインデックスを使っているのか判断する手法として EXPLAIN を使う方法を紹介しました。 トランザクションとロック トランザクションは更新系の処理を実装する時に必須なのでRailsでトランザクションを使う方法を説明しました。 transaction do # この中の更新処理は1つでも失敗したら全部ロールバックされる # データの整合性を保つために更新系の実装では考慮が必要 end Railsを使ってWebアプリケーションを作っている場合、明示的にロックを意識することは少ないのですが、概念として楽観的ロックと悲観的ロックについて軽く説明しました。 外部キー 外部キーについてもMySQLのドキュメントをなぞりながら軽く触れました。 特にON DELETEは便利なので活用していきたい機能の1つです。 dev.mysql.com まとめ バックエンド勉強会で実施した内容をざっくりではありますが紹介しました。 勉強会に参加したメンバーから「勉強会後からバックエンドのコードがスムーズに読めるようになった」などの感想をいただくことができました。さらに次の機能開発でバックエンドに挑戦するメンバーもいたので開催して本当に良かったと感じています。 次の画像は参加したメンバーのバックエンドのプルリクを Findy Team+ で表示したものです。GraphQLのQueryやMutationの追加や、フィールドの追加・修正などを行なったことがわかります。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

ファインディ株式会社でフロントエンドのリードをしている新福( @puku0x )です。 この記事はFindy Advent Calendar 2024 4日目の記事です。 adventar.org Nxはモノレポ管理の便利なユーティリティとして @nx/devkit を提供しています。 今回は @nx/devkit を利用したStorybookの設定の自動化についてご紹介します。 Nxについては以前の記事で紹介しておりますので、気になる方は是非ご覧ください。 tech.findy.co.jp モノレポでStorybookをどのように管理するか？ どうやってパス設定を自動化するか？ 実装してみよう！ まとめ モノレポでStorybookをどのように管理するか？ 皆さんはモノレポでStorybookを運用されたことはありますでしょうか？ 概ねどちらかの方法を採用することになるかと思います。 単一のStorybookで集中管理 Storybook Composition を使って管理 前者はStorybookのデプロイ設定をシンプルにできますが、全プロジェクトのStorybookへのパスを記述する必要があります。後者は設定がやや複雑であり、プロジェクト毎にStorybookのデプロイ設定も必要です。 Findyのフロントエンドはモノレポで管理されており、フィーチャ単位に細分化された多数のプロジェクトを持つという性質と運用の難易度を考慮し、前者の手法を選びました。 どうやってパス設定を自動化するか？ 単一のStorybookで集中管理する際に課題となるのは↓の部分でしょう。 // .storybook/main.js const config = { addons : [ '@storybook/addon-essentials' ] , framework : { name : '@storybook/react-vite' , options : {} , } , stories : [ // 👈 ここ！👇 '../apps/app1/src' , '../libs/components/src' , '../libs/app1/feature-a/src' , '../libs/app1/feature-b/src' , '../libs/app1/feature-c/src' , // 以下、全プロジェクトのパスが続きます // : ] } ; export default config ; 数個程度であれば十分に運用できそうですが、モノレポ上となると話が違ってきます。 ちなみに、Findyのフロントエンドではプロジェクト数は 70 個でした。 ※他プロダクトでは100個近くになる場合もあります 「え？これ全部手動で管理するんですか！？」 さすがに手動での管理には限界がありますので、ここはNxの力を借りましょう。 使用するのは createProjectGraphAsync というユーティリティです。 createProjectGraphAsync | Nx Nxは各プロジェクトの依存関係を保持しており、そこからStorybookのパスを算出できます。 最終的に次のようなものを目指します。 // .storybook/main.js const config = { addons : [ ... ] , framework : { ... } , stories : getStories () , // https://storybook.js.org/docs/configure#with-a-custom-implementation // 👇 こんな感じの配列を返して欲しい // [ // { titlePrefix: 'app1', directory: '../apps/app1/feature-a/src' }, // { titlePrefix: 'app1-feature-a', directory: '../libs/app1/feature-a/src' }, // { titlePrefix: 'app1-feature-b', directory: '../libs/app1/feature-b/src' }, // { titlePrefix: 'app1-feature-c', directory: '../libs/app1/feature-c/src' }, // ... // ] } ; export default config ; 実装してみよう！ 方針が決まったところで実装していきましょう。 事前の準備として、Storybookのパスを取得したいプロジェクトに tags を設定しておきましょう。Nxの @nx/enforce-module-boundaries ルールによる依存の制御を導入している場合は自然と設定されてあると思います。 // apps/app1/project.json { "name" : "app1" , "tags" : [ "scope:app1" ] , ... } // libs/app1/feature-a/project.json { "name" : "app1-feature-a" , "tags" : [ "scope:app1" , "type:feature" ] , ... } nx.dev @nx/devkit の createProjectGraphAsync を利用して、各プロジェクトの name および sourceRoot を取得します。 // apps/app1/.storybook/main.js import { createProjectGraphAsync } from '@nx/devkit' ; const getStories = async () => { const graph = await createProjectGraphAsync () ; // Storybookが不要なプロジェクトは無視 const ignoredProjects = [ 'app1-e2e' , 'app1-utils' ] ; return Object . keys ( graph . nodes ) . filter (( key ) => graph . nodes [ key ] . data . tags ?. includes ( 'scope:app1' )) // 関連するStorybookの絞り込み . filter (( key ) => ! ignoredProjects . includes ( key )) . map (( key ) => { const project = graph . nodes [ key ] . data ; return { titlePrefix : project . name , directory : `../../../ ${ project . sourceRoot } ` , } ; }) ; } ; あとはこれを stories に渡せば完成です。 // apps/app1/.storybook/main.js const config = { addons : [ '@storybook/addon-essentials' ] , framework : { name : '@storybook/react-vite' , options : {} , } , stories : getStories () , // 👈 プロジェクトの追加・削除に応じて自動的に設定されます } ; export default config ; Storybookが表示されました！ Nxによる自動化のもう1つのメリットは、↓のように titlePrefix にプロジェクト名を関連付けることで、フィーチャ毎の分類がより明確になる点だと思います。 const project = graph . nodes [ key ] . data ; return { titlePrefix : project . name , directory : `../../../ ${ project . sourceRoot } ` , } ; 開発メンバーからは、 「モノレポ構造とStoryの構造がリンクすることで画面の使い勝手が非常に良い」 「検索したときにStory名が同じでもどの階層にいるか判断して目的にたどり着ける」 といったフィードバックを受けることができました👏 検索性の向上に一役買えましたね！ 今回のサンプルは次のリポジトリから動作を確認できます。是非お試しください。 github.com まとめ この記事では @nx/devkit を利用したStorybookの設定の自動化についてご紹介しました。 Nxの機能を活用すれば「モノレポにプロジェクトを追加した後のStorybookの設定が漏れていた！」といった事とは無縁になるでしょう。 検証した時点では、 @storybook/test-runner と stories をAsync Functionで渡すパターンとの相性がまだ悪いようでした。今後の更新に期待したいですね。 今回はStorybookとの組み合わせでしたが、同じ仕組みを使ってGraphQL Codegenの設定自動化も可能であると確認しています。また別の機会にご紹介できればと思います。 それではまた次回！ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

【エンジニアの日常】エンジニア達の人生を変えた一冊 Part2 に続き、エンジニア達の人生を変えた一冊をご紹介いたします。 今回はPart3としまして、 Findy Freelance の開発チームメンバーから紹介します。 人生を変えた一冊 マスタリングTCP/IP―入門編 ハッカーと画家 コンピュータ時代の創造者たち UNIXという考え方 まとめ 人生を変えた一冊 マスタリングTCP/IP―入門編 マスタリングTCP/IP―入門編―(第6版) 作者: 井上 直也 , 村山 公保 , 竹下 隆史 , 荒井 透 , 苅田 幸雄 オーム社 Amazon 主にバックエンド開発と開発チームのリーダーを担当している中坪です。 私が紹介する「マスタリングTCP/IP―入門編」は通信プロトコルのTCP/IPの基礎について解説している書籍です。 私が最初にこの本を読んだのは、新卒入社した会社で、システムエンジニアとして働き始めた頃です。 当時、Webやスマホなどのアプリケーション開発部署への配属を希望していました。 しかし、実際にはネットワーク機器の設定、導入を業務とする部署に配属となりました。 最初はネットワークという分野に興味を持てず、仕事をする上での必要な知識も足りず、苦労しました。 そんなときに、先輩に勧められて読んだのがこの本です。当時、私が読んだのは第3版です。 本を読み進めながら、業務でPCとルータやファイアウォールを接続し、疎通確認をしたり、Wiresharkを使ってパケットの中身を確認する作業をしました。 本に記載されているプロトコルの仕様と、実際に目の前で行われている通信の挙動を結びつけることができました。 いくつか具体的な例を出すと次のようなことです。 IPアドレスとMACアドレスの役割 パケットのカプセル化の仕組み 代表的なプロトコルがTCP/UDPのどちらをベースにしており、何番ポートを使っているか デフォルトゲートウェイの役目やルーティングの挙動 そこから、徐々にネットワークに興味を持つようになりました。 目論見どおりに通信を制御できたときは、達成感を感じることができました。 今振り返ると、最初興味がなかったのは知識がないからであって、 理解することで後から興味が湧いてくること を体験しました。 また、 基礎を学ぶ大切さ や、本を読むことと 実践を組み合わせることで、学習が加速する ことも学びました。 エンジニアとしての原体験をもたらしてくれた一冊です。 新しい技術や役割に挑戦する際の姿勢に影響を与えてくれていると感じています。 自分がなにか新しいことを任せる立場になったときも、このときの経験を活かしていきたいと思っています。 今はネットワーク関連の仕事をしていませんが、 本ブログを書くにあたり、久々に最新の第6版を購入して読んでみました。 現在はWeb開発をしているので、その立場から見たときのおすすめの章は次の通りです。 1章 ネットワーク基礎知識 4章 IPプロトコル 5章 IPに関連する技術 8章 アプリケーションプロトコル 9章 セキュリティ ネットワークの分野でもIPv6やHTTP/3などの変化がありますが、TCP/IPはこの先も当分は通信の基盤として使われると考えています。 そのため、本書にある基礎知識は長い期間有効であり、 ネットワークを専門としないエンジニアであっても1度は読んでおいて損はないと思います。 ハッカーと画家 コンピュータ時代の創造者たち ハッカーと画家 コンピュータ時代の創造者たち 作者: ポール グレアム オーム社 Amazon インフラ・バックエンドエンジニア兼、Embedded SREの久木田です。 著者のPaul Grahamによって書かれたエッセイ集です。コンピュータ時代の革新を担うハッカーたちのものの考え方について書かれています。 各章は独立して書かれているので、どの章から読むことができます。 私がこの本を読んだのは大学1年のときです。もう10年以上前になります。 情報系の学科に入学してはじめてプログラミングにふれた自分としては、今後プログラマとして食べていけるのか、やっていけるのかを非常に悩んでいた時期でした。2011年当時は、プログラマ35年定年説やIT業界はブラックな環境が多いというネガティブな情報が目立っていたように感じ、その影響を受けていました。 そんなときに出会ったのがこの本でした。この本に書かれている「ハッカー」にすごく憧れて、勉強を続けていくこともできて、いまの職につけていると思っています。 私が一番好きな章は第16章の「素晴らしきハッカー」です。 良いハッカーとはどのようなことを好んでいるのか、何を大切にしているのかについて書かれています。良いハッカーとはプログラミングを本当に愛していて、コードを書くことを楽しんでいると書かれています。他にもどういった要素がハッカー足らしめているかを書かれているので興味を持って詳しく知りたいと思った方はぜひこの章を読んでいただきたいと思います。 また、良いハッカーを見分けるには同じプロジェクトで一緒に仕事をすることで初めてわかると書かれていて、当時はそういうものなのかと思って読んでいましたが、今は確かにそうかも知れないと思っています。エンジニアを採用する立場であったこともあるのですが、面接時にわからなかった特定の分野に関する知見の深さを同じチームで一緒に働くことで気づき、その人の凄さを初めて知ることが有りました。 この章のすべてが好きなのですが、特に好きなのは次の一節です。 何かをうまくやるためには、それを愛していなければならない。ハッキングがあなたがやりたくてたまらないことである限りは、それがうまくできるようになる可能性が高いだろう。14歳のときに感じた、プログラミングに対するセンス・オブ・ワンダー 1 を忘れないようにしよう。今の仕事で脳みそが腐っていってるんじゃないかと心配しているとしたら、たぶん腐っているよ。 大学での勉強や研究室配属後の取り組みを通して感じた、プログラミングの面白さやWebサーバ・ネットワークの仕組みを知ったときの感動が原体験となって私を形作っています。 初版が2005年 2007年 2 と古い本なので、エピソードはコンピュータ黎明期の話が多かったりしますが、ハッカーのマインドに関する説明などは今でも通じる部分は多いかと思います。ハッカーの考え方を理解したい人やコンピュータを扱う世界にいる人、飛び込もうとしている人には特におすすめしたい一冊です。 UNIXという考え方 UNIXという考え方: その設計思想と哲学 作者: Mike Gancarz オーム社 Amazon バックエンド開発を担当している金丸です。 この本はUNIXというOSの背後にある基本的な考え方を知ることができる一冊です。 UNIX自体の利用方法やコマンドについての説明はほとんどなく、UNIXがどのような思想に基づいて作られたかが説明されています。 本書と出会ったのは、新卒入社した会社で、情シスとしてFreeBSDを利用したサーバー管理の業務に従事しているタイミングでした。 当時の私は初めてのCLIに四苦八苦しており、ファイルをコピーするシェルスクリプトを作成するのにも苦戦していました。 「なんでコピー完了したことを教えてくれないんだろう」と同僚に話していたところ、この本を薦められました。 当初は疑問の答えを求めて読み進めていましたが、疑問の答えだけでなく、システムをどのように設計すべきかの指針も学ぶことができました。 プログラミング経験がなかった当時の私にとって、UNIXの考え方は初めて自分が理解できる内容で納得感のあるものでした。 この本は「定理」という形でUNIXの思想を説明しています。 9つの定理を紹介していますが、私の中で特に印象に残ったのは次の3つです。 定理1: スモール・イズ・ビューティフル 定理2: 一つのプログラムには一つのことをうまくやらせる 定理3: できるだけ早く試作を作成する 定理1と2ではUNIXというソフトウェアの大前提となる部分で、互いを補完している関係にあります。 この定理により、シンプルなコマンドを自由に組み合わせて処理を行うことができます。 例: ls , awk , sort コマンドを組み合わせて、ディレクトリ内のファイルを名前順に並べて表示するシェルスクリプト $ ls -l | awk '{print $9}' | sort スクリプトで利用されている ls コマンドはディレクトリが空の場合、何も表示せずプロンプトに戻ります。 これにより、次に組み合わせるコマンドに必要な情報だけを渡すことができ、コマンド同士がスムーズに連携できるようになっています。 $ ls $ この設計思想を知ったとき「なるほど！」と、非常に納得感がありました。 不要なメッセージを出さないことで、コマンドの組み合わせが直感的で柔軟にできるという点にUNIXの考え方への感銘を受けました。 上記の考え方を通じ、疑問と思っていた cp コマンドの役割はコピーすることであり、その機能のみをもつことが、定理2の「一つのプログラムには一つのことをうまくやらせる」に即していると理解しました。 合わせて、完了メッセージが必要であれば、コマンドを組み合わせて出力するのがUNIXらしい考え方だと解釈しました。 定理3では、プロトタイプを活用した開発の重要性を説いています。 この定理で紹介された次の一節が特に印象に残っています。 製品の完成後に百万のユーザーから背を向けられるより、少数から批判を受けるほうがはるかにいい。 当時の私は自分の仕事が批判されたように捉えてしまっていたため、プロトタイプを社内レビューで見せることに抵抗がありました。 ですが、この定理を読んで、自己本位の開発になっていることに気が付き、これではダメだと衝撃を受けました。 それ以来、プロダクトを誰のために作っているのかという意識を持つようになりました。 現在でも、機能の根幹となる部分から優先的に開発し、早い段階からPdMに都度確認してもらいながら実装を進めるスタイルを取っています。 実際の画面を確認していただくことで必要な情報が欠けていたことに気づくこともあり、細かく試作することでより良いプロダクトを作ることができると感じています。 紹介される定理はいずれもシステム設計の指針を示しており「設計の思想とは何か」を本書を通じて学ぶことができます。 設計を担当される方はもちろん、設計の指針となる考え方を学びたい方にもおすすめの一冊です。 まとめ いかがでしたでしょうか？ 偶然ですが、今回はどれもメンバーの初期キャリアに影響を与えた本の紹介となりました。 このブログを読んでくださった方で、そのような本がある方も多いのではないでしょうか。 久々に読み返してみると、原点に立ち返ったり、新たな気づきを得ることができるかもしれません。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers ここでいうセンス・オブ・ワンダーとはプログラミングに触れたときに感じた感覚や感動を意味していると私は解釈しています。 ↩ 正しくは2005年でした。はてぶのコメントでご指摘があり気が付きました。ありがとうございます！ ↩

ファインディ株式会社でフロントエンドのリードをしている新福( @puku0x )です。 皆さん、GitHub ActionsのLarger runnerはご存知でしょうか？ 高性能なマシンを使ってCIを実行できる一方、変更の少ない場合や計算負荷の低いCIではコストパフォーマンスが悪くなってしまいがちですよね？🤷‍♂️ この記事では、Nxの機能を利用してLarger runnerを動的に切り替える方法をご紹介します。 Nxについては以前の記事で紹介しておりますので、気になる方は是非ご覧ください。 tech.findy.co.jp Larger runner（より大きなランナー） 課題 解決策 結果 まとめ Larger runner（より大きなランナー） Larger runnerは、「GitHub Teamプラン」または「GitHub Enterprise Cloudプラン」の場合に利用可能です。 docs.github.com プライベートリポジトリ用の通常のランナー（GitHub-hosted runner）は、Linuxマシンの場合、CPUは2コアとなりますが、Larger runnerでは4コアや8コア、16コアなどより高いスペックのマシンを選択できます。 Larger runnerの例 最近は ArmベースのCPUも利用できるようになり 、x64ベースのCPUを使う場合よりもコストを抑えられるようになりました。積極的に使っていきたいですね。 課題 Larger runnerは強力ですが、その分コストがかかります。 コードの変更が少ない場合や、CI全体が数分で終わってしまうような場合では、せっかくの高いスペックも宝の持ち腐れとなってしまうでしょう。 負荷が高い時だけLarger runnerのスペックを上げるにはどうすれば良いか？ というのが今回の課題となります。 現在のGitHub Actionsには、変更の規模や負荷に応じて動的にランナーを切り替える機能が標準で備わっていないため、自分で組まなくてはいけません。 解決策 単純に変更されたファイル数や行数をカウントしても実際の影響範囲とは乖離があるため、より高度な制御が必要となります。 ✨そこで、Nxの登場です。✨ Nxはモノレポ内のプロジェクトの依存関係を Project Graph として保持しており、コードの変更から影響範囲を割り出すことが可能です。 次のコマンドを実行すると、影響されるプロジェクトをJSON形式で取得できます。 npx nx show projects --affected --json show - CLI command | Nx あとは実行結果をパースしてLarger runner切り替えの条件を組めば実現できそうです。 ワークフローの例を示します。 on : pull_request : jobs : check : runs-on : ubuntu-latest timeout-minutes : 5 outputs : runs_on : ${{ steps.output.outputs.runs_on }} steps : - uses : actions/checkout@v4 with : fetch-depth : 0 - uses : actions/setup-node@v4 with : node-version : 20 - uses : nrwl/nx-set-shas@v4 with : main-branch-name : ${{ github.base_ref }} - run : npm ci - name : Get affected projects id : get_affected_projects # 1. 影響されるプロジェクト数を算出 run : | length=$(npx nx show projects --affected --json | jq '. | length' ) echo "length=$length" >> "$GITHUB_OUTPUT" - name : Output id : output # 2. 影響されるプロジェクト数に応じたLarger runner名をセット run : | if [ $ {{ steps.get_affected_projects.outputs.length }} -gt 20 ] ; then echo "runs_on=arm64-4-core-ubuntu-22.04" >> $GITHUB_OUTPUT else echo "runs_on=arm64-2-core-ubuntu-22.04" >> $GITHUB_OUTPUT fi build : needs : check # 3. 指定されたLarger runnerで実行 runs-on : ${{ needs.check.outputs.runs_on }} timeout-minutes : 30 steps : - uses : actions/checkout@v4 with : fetch-depth : 0 - uses : actions/setup-node@v4 with : node-version : 20 - uses : nrwl/nx-set-shas@v4 with : main-branch-name : ${{ github.base_ref }} - run : npm ci - run : npx nx affected --target=build ※ actions/checkout や actions/cache は適宜最適化しましょう（1分ほど速くなる余地あり） ワークフローを実行すると、まず影響されるプロジェクト数が算出されます。 後続のジョブでは、その結果を元に runs-on: ${{ needs.check.outputs.runs_on }} で利用するLarger runnerを設定します。 やりたかったことが実現できていますね！🎉 負荷の高い時は高スペックのLarger runnerが動くため、CI時間の短縮が見込めます。負荷が低い時は、Larger runnerのスペックを落としてコストを節約できます。 結果 直近100回のCI結果を元に、4コアマシン固定の場合と2〜4コア可変の場合でコストを計算してみました。 Before（4コア固定） After（2〜4コア可変） $6.53 $4.79 ※ArmベースのCPUを使用する想定でコストを算出しています ※直近100回中、約1割が高負荷なCI（約12分）、残りが低負荷なCI（約5分）でした Larger runnerを動的に切り替える方法を採用することにより、コストを3割ほど削減できました。 以前の状態と比較してコストパフォーマンスが改善されたと思います。 まとめ この記事では、Nxの機能を活用してLarger runnerを動的に設定することで、コストパフォーマンスを改善する方法を紹介しました。 今回は runs-on の切り替えのみ紹介しましたが、他にもNx CLIの --parallel オプションの動的設定など応用は様々です。 皆さんの参考となりましたら幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 このテックブログでは開発生産性を向上させるための取り組みや、開発テクニックを紹介してきました。 意外に思われるかもしれませんが、弊社では全てのことを100％でやってるわけではなく、ユーザーへの価値提供を最優先するために後回しにしている部分もあります。 しかし、その影響で障害が多発したり、困ったことになることは滅多にありません。 そこで今回は、ユーザーへの価値提供を最優先するために弊社で実践していることを紹介していこうと思います。 それでは見ていきましょう！ 綺麗なコードは後。アプリケーションの振る舞いが先。 コミットの粒度は不問。Pull requestの粒度は維持。 実装途中のコードでもマージOK まとめ 綺麗なコードは後。アプリケーションの振る舞いが先。 Pull requestをレビューする中で、「もっと良い書き方がありそうで、議論が長引いて中々マージされない」といったケースがあるかと思います。 そのような場合、弊社ではテストが網羅されていればマージしてOKというスタンスを取っています。 もちろん、パフォーマンスやセキュリティ等に悪影響が出るようなコードはマージしませんが、基本的にはアプリケーションの振る舞いに影響がなければマージします。キレイなコードを書くことは非常に重要ですが、ユーザーが求めているのはアプリケーションの振る舞いであるからです。 マージ後に良い書き方を思いついたら、そのタイミングでリファクタのみの修正を行ったPull requestを出します。 後でリファクタするとしても、アプリケーションの振る舞いをテストコードで守っているので、強気でリファクタできます。 弊社のとあるリポジトリでは、リファクタのPull requestが1ヶ月で50個程度作成されていました。思いついたり気づいたりしたら日常的にリファクタを行う文化が根付いている証拠です。 このように、最初の段階で綺麗なコードを突き詰めることよりも、ユーザーに早く価値提供をすることを優先しています。テストコードの存在が、このような開発手法を許しているのです。 コミットの粒度は不問。Pull requestの粒度は維持。 Pull requestの粒度については以前、 別の記事 で触れましたが、コミットの粒度に関してはレビュー対象にはしていません。 コミットの粒度まで指摘してしまうと気軽に修正できなくなり、開発そのものを楽しむことが難しくなってしまうと考えているからです。 もちろん、試行錯誤のコミットが多すぎてgitのログに悪影響を及ぼすと判断したらrebaseなどで纏めることはありますが、基本的にローカル環境では自由に色々と試して欲しいと考えています。 その代わり、コミットメッセージには一定のルールを設けています。コミットメッセージのルールやprefixには Conventional Commit や Semantic Versioning などがあります。 例えば既存のAPIに対する機能追加があった場合のコミットメッセージは、 minor-feat: add hoge feature のようになります。 コミットメッセージのprefixに悩むということは、1つのコミットの中でたくさんのことをやりすぎているということに気づくことができます。 このようにコミットメッセージにルールを設けることによって、自然に一定内のコミットの粒度を維持できるようになっています。そのため、コミットの治安が悪くなることはほとんどありません。 実装途中のコードでもマージOK 実装途中のコードであっても、次の条件の全てを満たす場合はマージを許容しています。 テストコードがあり、CIが通っている 本番環境の振る舞いに影響がない 実装途中であることが、コードやPull requestのコメントなどで明確になっている 対応スコープ内の全てが完了してからマージするのではなく、Pull requestを細かく作成し、少しずつ作成、修正をしていくような流れです。 マージしてしまうとどうしても本番環境の振る舞いに影響が出てしまう場合は、Feature Flagを使ったりtopic branch運用を行うこともあります。 Feature Flagやtopic branch運用に関しては、↓の記事を参照してください。 tech.findy.co.jp tech.findy.co.jp 対応予定の全てが完了するまでマージを止めてしまうと、base branchとの差分が大きくなりやすく、conflictや不具合が発生しやすくなり、ユーザーへの価値提供までのスピードが遅くなってしまいます。 本番環境で利用されないコードをマージしてしまうのは抵抗感があるかもしれませんが、本番環境の振る舞いに影響がないということは悪影響もないはずであり、ユーザーへの価値提供を最優先するためにこのような開発手法になっています。 本番環境への影響がないということについては、既存コードに対するテストコードによって守られているため、強気でマージ出来るようになっています。 まとめ いかがでしたでしょうか？ 開発組織によっては「そんなことやっていいの？」と思われるかもしれませんが、弊社ではユーザーへの価値提供を最優先するために、このような開発手法になっています。 もちろん、しっかりとしたテストコード、CI/CD環境が整っているからこそ、このような開発手法が可能となっています。 他にも、このような開発手法を支えている開発テクニックを別記事にて紹介していますので、興味がある方は是非読んでみてください。 tech.findy.co.jp tech.findy.co.jp 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

はじめに こんにちは。ソフトウェアプロセス改善コーチでFindy Tech Blog編集長の高橋（ @Taka_bow ）です。 経済産業省の2019年発表によると、日本のIT人材不足が2030年には79万人に達する可能性があると予測され、しばしばメディアにも引用されてきました。 この調査レポート発表から5年以上が経過しましたが、果たして79万人という人材不足は現実となるのでしょうか？ 今回は最新のデータからこの予測を検証してみたいと思います。 2023年11月2日のNHKニュース www3.nhk.or.jp 2024年7月9日 5:00 (2024年7月13日 17:40更新) 日経新聞 [会員限定記事] www.nikkei.com はじめに 「IT人材需給に関する調査」とは 労働生産性の低さ 最新のデータを読む 「人月の神話型請負」が生産性向上を阻む 受託開発でもアジャイル開発はできる お知らせ！ 「IT人材需給に関する調査」とは このレポートは、みずほ情報総研株式会社が2015年に経済産業省からの受託調査研究として実施した調査レポートです。 2019年3月に経済産業省から発表されました。当時話題となったのは、このデータです。 出典：「IT 人材需給に関する調査」（経済産業省）（ https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf ） これは 「今後、IT需要が高位に推移した場合約79万人の人材不足になる可能性がある」 という試算でした。なお、需要が中位シナリオで約45万人、低位シナリオでも約16万人の不足する可能性があります。 この背景には2つの要因があります。 日本の労働人口（特に若年人口）が減少 （新卒IT人材の入職率は一定右肩上がり） 日本の労働生産性が低い （2022年、OECD 加盟 38 カ国中 30 位） 日本の労働人口減少に関しては、IT業界に限らず日本全体の問題です。 冒頭のNHKニュース「日本のIT人材79万人が不足？ インドで始まった人材獲得戦略」は、まさしくこの問題に対応するための動きのひとつと言えます。 労働生産性の低さ さて、もうひとつの要因「労働生産性の低さ」ですが、次の表をごらんください。これは上記のグラフの一部を表にしたものです。 出典：「IT 人材需給に関する調査」（経済産業省）（ https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf ）を加工して作成 IT需要が 高位 と仮定したとき、 赤で囲んだ部分： 生産性上昇率が0.7% だった場合、 78.7万人の人材不足 青で囲んだ部分： 生産性上昇率が5.23% だった場合、 人材不足はゼロ を表しています。生産性上昇率が5.23％以上アップしていれば人材不足は起きない、という予測です。 では、最新の労働生産性はどうなっているでしょう。 最新のデータを読む 現時点で最新の日本生産性本部が公表している「労働生産性の国際比較2023」から、情報通信業の労働生産性の推移分析を見てみました。 出典：日本生産性本部「労働生産性の国際比較2023」から情報通信業の労働生産性の推移 https://www.jpc-net.jp/research/detail/006714.html 日本の2000年から2021年にかけての生産性上昇率（年率平均）は「-0.1%」にとどまっています。これは、経済産業省が予測した平均成長率0.7％を大きく下回る結果です。 そして、調査レポートが予測する「78.7万人の人材不足」というシナリオよりも深刻な状況である可能性があります。 日本の特徴は、 付加価値額は拡大傾向にある 就業者数も同等ペースで増加している ことから、付加価値が就業者数の増加に見合った成長をしておらず、生産性の上昇を抑えてしまっていると考えられます。 「人月の神話型請負」が生産性向上を阻む なぜ、比較的安定推移すると言われる情報通信業において、日本の生産性上昇率は低いのでしょうか。 ひとつの要因として、日本におけるソフトウェア産業の構造的な問題が挙げられます。 まず、多くの企業はソフトウェア開発を外部の受託企業に委託する傾向があります。その際、事前に詳細な仕様を確定し、その通りに開発を進める「ウォーターフォール型」の手法が一般的です。 *1 この手法では変更に柔軟に対応することが難しく、生産性向上に課題があると指摘されています。 さらに、多くの受託開発は「人月」に基づく見積もりと請負契約に依存しており、多重下請け構造が蔓延しています。この構造は、柔軟な対応や効率的な開発を妨げる要因となっています。 私はこれを「人月の神話型請負」と呼んでいます。 定義：「人月による見積もりを前提とし、事前合意の仕様とプロセスを厳守するため柔軟な変更対応が難しい請負契約」 「ブルックスの法則」や「銀の弾などない」で有名なフレデリック・ブルックスは、著書「人月の神話（The Mythical Man-Month）」の中で、このように述べています。 私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。人月は、人を惑わす危険な神話である。なぜなら、人月は、人と月が置き換え可能であることを暗示しているからである。（第二章「人月の神話」） この本が書かれたのは1975年、私でさえ幼少期であり、読者の多くは生まれる前の話ではないかと想像します。 しかし、現代日本のIT業界では「人月で見積もる」が未だに健在である事実に着目せざるをえません。 なぜなら「人月の神話型請負」には、次のような負の側面があると考えられるからです。 負の側面 内容 要求仕様の硬直化 事前合意した仕様に縛られ、 状況に応じた柔軟な改善が難しい 形式的なプロセス管理 決められた手順の遵守が優先され、 効率化や創意工夫の余地が少ない 人月ベースの評価 投入工数で報酬が決まるため、 生産性向上への意欲が生まれにくい 人員増加による解決 課題への対応を人員増員で行うため、 チームの効率が低下しやすい エンジニアの裁量不足または制限 顧客からの指示が中心となり、 技術的な改善提案を行いにくい 技術力の蓄積不足 技術資産が顧客側のものであり、 自組織内にナレッジが貯まらない これらの負の側面は、開発チームの「自立」を損ない、エンジニア個人の「自律」も抑え込みます。 結果として、組織全体の生産性が低下し、改善や変革が難しくなる要因となります。 また、「人月の神話型請負」の問題は、すぐには目に見えにくい「遅効性の毒」のように、ゆっくりと組織全体を蝕むのが特徴です。 この構造的な問題に対処するためには、柔軟で価値を重視した新たな開発体制への転換が不可欠です。少なくとも、次の2点を変えることが必要だと思います。 事前確定型から状況適応型の開発プロセスへの移行 形式的な遵守よりもビジネス価値を重視した評価の導入 つまり、「人月の神話型請負」から脱却し生産性向上を図るには、 アジャイル開発を基盤に据え、委託側と受託側双方で「価値を共に創り出す体制」を築く ことが重要です。 受託開発でもアジャイル開発はできる しかし、「人月の神話型請負」をビジネスモデルの柱としてきた多くのソフトウェア受託企業にとっては、どこから手をつけるべきかが大きな悩みだと思います。 そんな難題に光を当てるヒントが、2024年10月30日に開催された「 プロジェクト成功への挑戦 」というイベントで共有されています。 イベントでは、株式会社永和システムマネジメント Agile Studio プロデューサー／アジャイルコーチの木下史彦さん（ @fkino ）が、「アジャイル開発と契約」のテーマで、主に「モデル契約」についてお話しくださいました。 木下さんは、従来型の契約が「決めたことを守る」ことを重視するのに対し、アジャイル開発における契約では「変化に対応する」柔軟な仕組みが重要であると説明。 さらに、IPAのモデル契約を例に、準委任契約の採用や、スプリントごとの計画調整が可能な体制づくりをどう進められているかについても詳しく解説されました。 speakerdeck.com 続いて、株式会社永和システムマネジメントのエンジニア、藤田みゆきさんからは「受託開発でのアジャイル奮闘記」と題して、実際の受託開発におけるアジャイル導入の取り組みをご紹介いただきました。 speakerdeck.com 永和システムマネジメントの皆様が示してくださった変化に対応する具体的なアイデアや実践方法は、『人月の神話型請負』から脱却するための大きな一歩となると感じました。 以下に、イベントの録画ビデオもリンクしていますので、ぜひご覧ください。 youtu.be お知らせ！ 現在、私と一緒にイネイブリングチームの立ち上げを行うメンバーを探しています！ イネイブリングチームは、エンジニア組織だけではなくファインディ社全体を支援するチームとしていく予定です。 組織全体のエンジニアリング力を向上 開発スキル向上のためのトレーニングやワークショップを実施 プロセス改善の提案とコーチングを行い、開発生産性とDevExを向上 社内外のエンジニアを対象とした活動を展開 このチームで、ファインディの成長エンジンとなりませんか？興味がある方は、ぜひこちらをクリックしてみてください↓ herp.careers エンジニアのポジションは他にも色々あります。ファインディでは一緒に働くメンバーを募集中です！ herp.careers では、本日はこのへんで。 See you! *1 : ウォーターフォール型の元となったと言われるウィンストン・W・ロイスによる論文”Managing the Development of Large Software Systems(1970)”では「手戻り」が推奨されています

こんにちは。 ファインディでソフトウェアエンジニアをしている栁沢です。 ファインディの各プロダクトでは、1日に複数回デプロイしています。 例えば、私が所属するFindy転職のプロダクトでは、1日に6回ほど本番環境にデプロイしています。 高いデプロイ頻度でもデプロイ起因による障害や不具合がほぼ発生しておらず、開発スピードと品質の両立を実現できています。 今回はファインディ社内でのFeature Flagの使い方について詳しく解説します！ Feature Flagを使うことのメリット Feature Flagの実現方法 Feature Flagを使った開発の流れ 1. Feature Flagを追加する 2. Feature Flagを使って新機能を実装・テストコードを書く 3. 検証用の環境で動作確認を実施する 4. 動作確認が完了したら、本番環境で機能を有効化させる 5. 一定期間の安定稼働を確認できたら、Feature Flagの処理を削除する まとめ Feature Flagを使うことのメリット Feature Flag（フィーチャーフラグ）は、コードを書き換えることなく特定の機能を有効化や無効化できる開発テクニックです。 Feature Flagで機能を無効化しておくことで、ユーザーに影響がでないように本番環境にコードをガンガン反映させることができるようになります。 これにより次のようなメリットがあります。 開発途中でもどんどんメインブランチにマージできる。そのため、複数人の開発でもコンフリクトがほぼ起こらない。 本番環境で特定のユーザーやセグメントのみに機能を限定公開できるので、リスクを抑えながら機能を公開できる。 万が一本番環境で問題があった場合、機能を無効化させることですぐに切り戻しができる。 Feature Flagの実現方法 Feature Flagの実現方法は、ライブラリやSaaSを使うなど様々な方法がありますが、現在のFindyでは「環境変数」と「ライブラリ」の2パターンが採用されています。 Findy転職プロダクトでは、導入や運用がシンプルな「環境変数」を使ってFeature Flagを実現しています。 環境設定ファイルで環境変数を追加することで機能を有効化させる 環境変数の値で条件分岐を実装して機能をだし分ける 実際のコード例を見てみるとシンプルなことがわかると思います。 envファイルに環境変数を追加することで機能を有効化させます。逆に、環境変数を削除することで機能を無効化できます。 # .env FEATURE_NEW_LABEL=true 実装コードは、環境変数の値によって条件分岐を実装することで振る舞いを変えています。 export const SampleComponent = () => { // 特定の環境変数の値が'true'なら"NEW"というラベルを表示する const isEnabledNewLabel = process .env.FEATURE_NEW_LABEL === 'true' ; return ( < div > { isEnabledNewLabel && < span > NEW </ span > } < span >Sample</ span > </ div > ); } ; 補足：この実現方法の伸びしろとしては、「環境設定ファイルの修正が手間」、「フロントエンドとAPIでFeature Flagが分散している」、「一部のユーザーに部分的に公開がしづらい」という課題があります。そのため別チームでは、ライブラリを使ってAPIから機能のON/OFF情報を取得する仕組みでFeature Flagを実現しているようです。 Feature Flagを使った開発の流れ ここからは、より具体的にFeature Flagを使った開発の流れを説明していきます。 Feature Flagを追加する Feature Flagを使って新機能を実装・テストコードを書く 検証用の環境で動作確認を実施する 動作確認が完了したら、本番環境で機能を有効化させる 一定期間の安定稼働を確認できたら、Feature Flagと条件分岐を削除する 1. Feature Flagを追加する 環境変数を追加し、ローカル環境や検証用環境で機能を有効化させます。 # .env.local や .env.qa FEATURE_NEW_LABEL=true Tipsとして、早めに検証用環境で機能を有効にしておくことでバグを早く発見しやすくなり、バグ対応の工数を減らせます。（シフトレフトを進められる） 2. Feature Flagを使って新機能を実装・テストコードを書く 環境変数の値によって条件分岐をすることで機能のON/OFFをできるようにします。 export const SampleComponent = () => { // 特定の環境変数の値が'true'なら"NEW"というラベルを表示する const isEnabledNewLabel = process .env.FEATURE_NEW_LABEL === 'true' ; return ( < div > { isEnabledNewLabel && < span > NEW </ span > } < span >Sample</ span > </ div > ); } ; また、機能をON/OFFしたときに、それぞれのケースで振る舞いが壊れないように自動テストを書いておきます。 describe ( 'SampleComponent' , () => { it ( 'should render "NEW" label when FEATURE_NEW_LABEL is true' , async () => { process .env.FEATURE_NEW_LABEL = 'true' ; render(< SampleComponent />); expect ( screen .getByText( 'NEW' )).toBeInTheDocument(); } ); it ( 'should not render "NEW" label when FEATURE_NEW_LABEL is false' , async () => { process .env.FEATURE_NEW_LABEL = 'false' ; render(< SampleComponent />); expect ( screen .queryByText( 'NEW' )).not.toBeInTheDocument(); } ); } ); 自動テストを書いておくことで、開発途中でもどんどんメインブランチにマージして、自信をもって本番環境にデプロイできます。 3. 検証用の環境で動作確認を実施する 機能開発が完了したら、検証用の環境で動作確認を実施します。 本番環境では機能が無効化されているため、ユーザーに影響ない形で検証を進めることができます。 4. 動作確認が完了したら、本番環境で機能を有効化させる 検証環境で動作確認が完了したら、本番環境で機能を有効化させます。 # .env.production FEATURE_NEW_LABEL=true 本番環境で深刻な不具合が発生し、機能を緊急で無効にする必要がある場合は、環境変数を削除することで簡単に切り戻しができます。 # .env.production # 削除 # FEATURE_NEW_LABEL=true 切り戻しを素早くできるのもFeature Flagの強みです。 5. 一定期間の安定稼働を確認できたら、Feature Flagの処理を削除する 最後に、機能が実際に使われて安定稼働していること確認できたら、環境変数と分岐の処理を削除していきます。 export const SampleComponent = () => { return ( < div > < span >NEW</ span > < span >Sample</ span > </ div > ); } ; Feature Flagの削除時に間違って必要な処理を削除してしまいデグレをおこしてしまうミスはやりがちです。しかし、自動テストがあることで自信をもって削除作業を進められることができます。 まとめ 今回は、Findyの爆速開発を支えるFeature Flagの使い方を紹介しました。 Feature Flagを使うことで、ユーザーに影響ない形で、開発途中でもどんどんメインブランチにマージできます。これにより、本番環境へのデプロイも1日に複数回実施することが可能になります！ 個人的に爆速開発を支える1つの要素として、Feature Flagの活用は必須だと感じています！ もしまだ導入していない場合は、この記事をきっかけにぜひトライしてみてください :) 他にもファインディではいろいろなテクニックを使っているので、興味がある方は次の記事も合わせて読んでみてください。 Findyの爆速開発を支える「システムを守るテストコード」の実例3選 - Findy Tech Blog Findyの爆速開発を支えるPull requestの粒度 - Findy Tech Blog 現在、ファインディでは一緒に働くエンジニアを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは。 Findy Tools の開発をしている林です。 私たちのプロジェクトではフロントエンドのフレームワークにNext.js App Routerを使っており、AWSのECSへデプロイして運用しています。 そして、一部のレンダリングの処理が重いページのキャッシュを実装する際に、直面した課題と解決策を紹介します。 Next.jsのキャッシュ機構について 今回実現したいこと 課題と解決策 課題1: Next.jsの機能では要件に合わない 解決策1: CloudFrontのみでキャッシュ 課題2: エラーページがキャッシュされる 解決策2: Lambda@Edgeを用いたCache-Controlヘッダー制御 まとめ Next.jsのキャッシュ機構について まず、Next.jsのキャッシュ機構について簡単に説明します。 Next.jsではサーバサイドで使えるキャッシュ機構が次の3種類あります。 Request Memoization 同一リクエストの中で外部APIリクエストをメモ化する Data Cache 外部APIのレスポンスなどを一定時間キャッシュする Full Route Cache HTMLおよびRSC Payloadをユーザセッションまたは共通で一定時間キャッシュする キャッシュの細かい仕様に関しては詳しくは公式ドキュメントを参照してください。 Building Your Application: Caching | Next.js また、Full Route Cacheでは revalidatePath APIで任意のタイミングでキャッシュを削除できます。 Functions: revalidatePath | Next.js 今回実現したいこと 今回の要件は、 一部の処理の重いページのレンダリング結果を丸ごとキャッシュしてレスポンスを高速化したい というものです。 これには、Findy Toolsはメディアサイトという側面もあり、多くのページは更新頻度がそれほど高くなく、フルページでのキャッシュがやりやすいという背景もあります。 さらに、ログインが必要なユーザ固有の情報はすべてクライアントフェッチをしているため、ユーザごとのキャッシュを考慮する必要もありませんでした。 また、エンドユーザーが利用するフロントエンドアプリケーションの他に、コンテンツ管理用のアプリケーションがあります。そして、この管理用アプリケーションからコンテンツが更新された際に、フロントエンド側にすぐに反映させたいという要件もありました。 補足: 現状のFindy Toolsのインフラ構成図は次の図のようになっています。 すべてAWS上に構築されており、CloudFrontを経由してNext.jsへリクエストを送っています。 また、コンテンツ管理用のアプリケーション(Rails)もECSへデプロイしています。 Findy Tools インフラ構成図 2ヶ月でリリースしたFindy Toolsの技術選定の裏側 - Findy Tools より 課題と解決策 今回の要件を実現するにあたり、直面した2つの課題と解決策をそれぞれ紹介します。 課題1: Next.jsの機能では要件に合わない まず、ページのレンダリング結果を丸ごとキャッシュしたかったので、Full Route Cacheを検討しました。 しかし、セルフホスティングのNext.jsではキャッシュをメモリと .next/cache ディレクトリに保存しているため、ECSのコンテナを水平スケールして複数台でリクエストを受ける構成にすると、キャッシュの一貫性がなくなります。 負荷軽減目的のキャッシュで、一貫性が問題にならない場合はこれでも良いですが、キャッシュの削除をする revalidatePath が全てのコンテナで実行されず、一部で古いキャッシュが残るのは今回の要件を満たせません。 このため、ドキュメントにはコンテナオーケストレーションプラットフォームではRedisやS3のような外部のストレージにキャッシュを保存するようcache-handlerを実装する必要があると紹介されています。 Building Your Application: Deploying | Next.js Data CacheやFull Route Cacheをフルに活用したい場合には、カスタムのcache-handlerを用意しても良いと思いますが、今回の要件にはオーバースペックすぎると判断しこれは見送りました。 また、Next.jsのFull Route Cacheを使った場合にもレスポンスヘッダーに Cache-Control: stale-while-revalidate が付与されるため、 削除の際にcache-handlerのデータと後術するCDNのキャッシュの2つを削除する必要もあり、複雑になるということもFull Route Cacheを見送った理由の1つです。 解決策1: CloudFrontのみでキャッシュ 私たちの構成ではNext.jsへのリクエストは静的ファイルを配信するため、CDNであるCloudFrontを経由させています。 そこで、Next.jsのアプリケーションレベルではキャッシュをせず、CDNでレンダリングされたHTMLやRSC Payloadをキャッシュすることにしました。 当初、Next.js App Routerでは特定のページにカスタムのCache-Controlヘッダーを付与するにはmiddlewareの処理で対処する必要がありましたが、v14.2.10 からPagesRouterと同様に next.config.js の headers() で指定できるようになりました。 Add ability to customize Cache-Control by ijjk · Pull Request #69802 · vercel/next.js next.config.js で特定のパスにCache-Controlヘッダーを設定するコードの例を以下に示します。 module . exports = { async headers () { return [ { source : '/path/:slug' , headers : [ { key : 'Cache-Control' , value : 's-maxage=86400, stale-while-revalidate' , } , ] , } ] } , } これで、CloudFrontの設定でオリジンのCache-Controlヘッダーを元にキャッシュするよう設定すると、CDNでレスポンスをキャッシュができます。 コンテンツが更新された際のキャッシュの削除は、CloudFrontのAPIで特定のパスのキャッシュを削除するようにコンテンツ管理用アプリケーションから呼び出しています。 課題2: エラーページがキャッシュされる CloudFrontではHTTPレスポンスコードが404や一部の5xxの場合も、Cache-Controlヘッダーに基づいてキャッシュされる仕様になっています。 CloudFront がオリジンからの HTTP 4xx および 5xx ステータスコードを処理する方法 - Amazon CloudFront 特に私たちのプロジェクトでは、公開前のコンテンツのURLにアクセスされることがあり、404ページがキャッシュされてしまうという課題がありました。 公開前にキャッシュの削除をすれば良いのですが、時間を指定して公開するケースではキャッシュの削除が複雑になってしまいます。 一見するとNext.jsでバックエンドのAPIから情報を取得して、404やエラーの時はCache-Controlヘッダーをno-cacheに指定すれば解決しそうなのですが、Next.jsではレスポンスをストリーミングしており、リクエストの最初に処理されるmiddlewareやnext.config.jsのheadersの設定を条件に基づいて変更できません。 これに関してはページごとにカスタムヘッダーを設定できるような generateHeaders() というAPIが必要か、という議論がNext.jsのGitHub Discussionsで行われています。 App Router Custom Header Use Cases · vercel/next.js · Discussion #58110 解決策2: Lambda@Edgeを用いたCache-Controlヘッダー制御 Next.jsではCache-Controlヘッダーを条件に基づいて変更することが出来ないため、別のアプローチとしてLambda@EdgeでステータスコードによってCache-Controlヘッダーを書き換えることにしました。 Lambda@EdgeはオリジンとCloudFrontのキャッシュ(Regional Edge Cache)の間で動作し、リクエストやレスポンスを操作することが出来ます。 次のコードはオリジンのNext.jsのレスポンスを受け取り、ステータスコードが4xx, 5xx系の時にCache-Contorolヘッダーをno-cacheに上書きしてCloudFrontへレスポンスを返すような例です。 'use strict' ; export const handler = async ( event , context , callback ) => { const response = event . Records [ 0 ] . cf . response ; const headers = response . headers ; if ( response . status >= 400 && response . status <= 599 ) { headers [ 'cache-control' ] = [{ key : 'Cache-Control' , value : "private, no-cache, no-store, max-age=0, must-revalidate" }] ; } callback ( null , response ) } ; これにより、Next.jsのステータスコードによってCache-Controlヘッダー書き換え、CloudFrontにキャッシュしないということが実現可能になりました。 まとめ この記事では、App Routerを用いた場合の「コンテンツ更新の際のキャッシュ削除」という課題に対して次の工夫をして、エラーレスポンスまで含めた柔軟なキャッシュ制御を実現しました。 AWS CloudFrontを用いてApp Routerのレスポンスをキャッシュ Lambda@Edgeを用いてCache-Controlヘッダーを書き換え また、レンダリングの重いページや更新頻度の低いページをCloudFrontから返すことで、レスポンスタイムが改善され、ユーザ体験の向上やサーバ負荷の軽減も達成できました。 Next.js App Routerは一部の機能においてまだ発展途上ですが、将来的に、セルフホスティングやCDNでのキャッシュが扱いやすくなることに期待ですね。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

ファインディ株式会社でフロントエンドのリードをしている新福( @puku0x )です。 弊社では Nx を活用してCIを高速化しています。この記事では、最近導入した Nx Agents でフロントエンドのCIをさらに高速化した事例を紹介します。 Nxについては以前の記事で紹介しておりますので、気になる方は是非ご覧ください。 tech.findy.co.jp フロントエンドのCIの課題 Nx Agents Nx Agents導入の結果 Nx Agents利用上の工夫 プロジェクトを細かく分割する Node.jsのバージョンを揃える キャッシュの活用 特定のステップの省略 高度なエージェント割り当て まとめ フロントエンドのCIの課題 これまで「キャッシュの活用」や「並列化」「マシンスペックの向上」といった工夫により、フロントエンドのCIを高速化してきました。 しかし、コードベースの増大により時間のかかるタスクにCI時間が引きずられてしまう問題が顕著になってきました。 次の図は、キャッシュヒットしなかった場合のCI時間の一例です。 他のタスクが早く終わっても一番時間のかかるタスクを待つ必要があるため、結果としてCI時間が伸びる傾向にありました。 Nx Agents タスク単位の並列化では、CI時間のボトルネックを解消するのが困難です。 「DTE（Distribute Task Execution）」はその問題を解決する手法であり、Nx CloudにはDTEのマネージドなサービスである「 Nx Agents 」が提供されています。 Nx Agentsの動作イメージ（Nx公式ドキュメントより抜粋） Nx Agentsは今年2月にリリースされました。費用はGitHub Actionsより安価となっています。 blog.nrwl.io Nx Agents GitHub Actions（Larger runner） Linux 2コア $0.0055/min $0.008/min Linux 4コア $0.011/min $0.016/min 参考: Nx Cloud - Available Plans GitHub Actions の課金について - GitHub Docs 使い方は非常に簡単で、NxワークスペースをNx Cloudに接続した後、CIのタスク実行前に次のようなコマンドを追加するだけです。 npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" 利用するマシンの数やスペックは、変更の影響範囲に応じて動的に設定できます。 npx nx-cloud start-ci-run --distribute-on=".nx/workflows/dynamic-changesets.yml" # .nx/workflows/dynamic-changesets.yml distribute-on : small-changeset : 3 linux-medium-js medium-changeset : 6 linux-medium-js large-changeset : 9 linux-large-js DTE自体はGitHub Actionsの matrix の機能を用いて構成することも可能ですが、CIが失敗した場合は 必ずDTEホスト側のマシンをRe-runする必要があります 。検証した限りでは誤操作を確実に防ぐ方法が無かったため、Nx Agentsの利用をおすすめします。 Nx Agents導入の結果 Nx Agentsを有効にした場合のCI時間の例を示します。 このワークフローでは、アプリケーションのビルドやテスト、型チェックなどを全てNx Agentsで実行する構成となっています。 npx nx-cloud start-ci-run --distribute-on=".nx/workflows/dynamic-changesets.yml" npx nx affected --target=build,build-storybook,test,lint,stylelint,typecheck --configuration=ci npx nx-cloud complete-ci-run 元の構成では約18分かかっていたものが約11分になりました。 CI本体が約10分、後述する事前処理が追加で約1分かかる計算です。 CI時間は約7分削減されており、およそ 40% ほど高速化できたということがわかりました。 各タスクが複数のエージェントで分散実行されたことで、タスク単位で並列化していた場合よりも高速化できました。 Nx Agents利用上の工夫 Nx Agentsは今年リリースされたばかりのサービスであるため、ドキュメントの不備やノウハウの不足といった課題があることに注意しましょう。ドキュメントに示されているセットアップの例は、最低限のものしかないため最適化の余地があります。 ここでは、弊社で実践している利用上の工夫を紹介します。 プロジェクトを細かく分割する DTEの性質上、単体のタスクの実行時間が長くなるほどエージェントの利用効率が下がります。 コードを全て apps/** 側に置くとキャッシュヒット率が下がりCI時間も延びるため、まずは libs/** に分離することから始めると良いと思います。 共有ライブラリについては、コンポーネント系、ユーティリティ系で別のライブラリとして作ると良いでしょう。 弊社の場合、例えばビルド時間が 2分 を超えるようなものを確認した場合は、モジュールの移動や分割を実施しました。 分割が難しい場合は、Nx Agentsの実行対象から外すといった工夫が必要かもしれません。 Node.jsのバージョンを揃える nx-cloud-workflows の workflow-steps/install-node は nvm に対応しています。nvm以外の管理ツールを利用している場合は自前でセットアップ用のスクリプトを書く必要があります。 例として asdf を用いる場合のスクリプトを示します。 # .tool-versions nodejs 20 . 18 . 0 # .nx/workflows/agents.yml launch-templates : custom-linux-medium-js : resource-class : 'docker_linux_amd64/medium' image : 'ubuntu22.04-node20.11-v10' init-steps : - name : Checkout uses : 'nrwl/nx-cloud-workflows/v4/workflow-steps/checkout/main.yaml' - name : Setup Node.js script : | git clone https://github.com/asdf-vm/asdf.git $HOME/.asdf --branch v0.14.1 source $HOME/.asdf/asdf.sh asdf plugin add nodejs https://github.com/asdf-vm/asdf-nodejs.git asdf install nodejs echo "PATH=$PATH" >> $NX_CLOUD_ENV CI時間は5〜10秒ほど延びますが、Node.jsのバージョン不一致によるエラーを回避できます。 キャッシュの活用 workflow-steps/cache を利用した依存ライブラリのキャッシュはほぼ必須と言えるでしょう。 node_modules をキャッシュすることで大幅な時間削減が可能です。 # .nx/workflows/agents.yml launch-templates : custom-linux-medium-js : （中略） - name : Restore NPM Cache uses : 'nrwl/nx-cloud-workflows/v4/workflow-steps/cache/main.yaml' inputs : key : '.tool-versions' paths : ~/.npm base_branch : '<デフォルトブランチ名>' - name : Restore Node Modules Cache uses : 'nrwl/nx-cloud-workflows/v4/workflow-steps/cache/main.yaml' inputs : key : '.tool-versions|package-lock.json|yarn.lock|pnpm-lock.yaml' paths : node_modules base_branch : '<デフォルトブランチ名>' - name : Restore Browser Binary Cache uses : 'nrwl/nx-cloud-workflows/v4/workflow-steps/cache/main.yaml' inputs : key : '.tool-versions|package-lock.json|yarn.lock|pnpm-lock.yaml|"browsers"' paths : | ~/.cache/ms-playwright base_branch : '<デフォルトブランチ名>' ここで示した例では、以前の記事と同様に ~/.npm をキャッシュすることで、 node_modules がキャッシュヒットしなかった場合でも可能な限り高速動作するようにしています。 tech.findy.co.jp workflow-steps/cache の使い勝手は actions/cache とほぼ同じです。デフォルトブランチ以外にキャッシュを共有する場合は、デフォルトブランチへのpush時にキャッシュを更新すると良いと思います。 # .github/workflows/update-cache.yml on : push : branches : - '<デフォルトブランチ名>' paths : - package-lock.json jobs : cache : runs-on : ubuntu-latest steps : （中略） - uses : actions/cache@v4 id : cache （中略） - run : npx nx-cloud start-ci-run --distribute-on="3 linux-small-js" - name : Install dependencies if : steps.cache.outputs.cache-hit != 'true' run : npm ci - run : npx nx-cloud complete-ci-run 設定可能な最小エージェント数は 3 である点に注意しましょう。 安く済ませたいところではありますが... 特定のステップの省略 2024年10月現在、Nx AgentsではGitHub Actionsのような条件分岐の構文はサポートされていません。適宜スクリプトを書いて対応しましょう。 # .nx/workflows/agents.yml launch-templates : custom-linux-medium-js : （中略） - name : Install Node Modules (if needed) script : | if [ ! -d node_modules ] ; then npm ci fi 高度なエージェント割り当て --distribute-on=".nx/workflows/dynamic-changesets.yml" は記述が簡潔である一方、現状では small medium large の3段階しか設定できません。また、負荷に応じてマシンスペックを上げるといった高度な割り当てもサポートされていません。 nx.dev Nx Agentsの今後のアップデートに期待しても良いですが、待ちきれないという場合は次のように、メインジョブの前段で nx show projects --affected を実行し、 outputs 経由でオプションを渡すと良いでしょう。 jobs : check : runs-on : ubuntu-latest outputs : distribute_on : ${{ steps.output.outputs.distribute_on }} parallel : ${{ steps.output.outputs.parallel }} steps : （中略） - uses : nrwl/nx-set-shas@v4 with : main-branch-name : ${{ github.base_ref }} - name : Get affected projects id : get_affected_projects run : | length=$(npx nx show projects --affected --json | jq '. | length' ) echo "length=$length" >> $GITHUB_OUTPUT - name : Output id : output run : | if [ $ {{ steps.get_affected_projects.outputs.length }} -gt 20 ] ; then echo 'distribute_on="4 custom-linux-large-js"' >> $GITHUB_OUTPUT echo 'parallel=4' >> $GITHUB_OUTPUT elif [ $ {{ steps.get_affected_projects.outputs.length }} -gt 10 ] ; then echo 'distribute_on="3 custom-linux-medium-plus-js"' >> $GITHUB_OUTPUT echo 'parallel=3' >> $GITHUB_OUTPUT else echo 'distribute_on="3 custom-linux-medium-js"' >> $GITHUB_OUTPUT echo 'parallel=2' >> $GITHUB_OUTPUT fi main : needs : check runs-on : ubuntu-latest steps : （中略） - name : Setup Nx Cloud run : npx nx-cloud start-ci-run --distribute-on=${{ needs.check.outputs.distribute_on }} - run : npx nx affected --target=build,test,lint -parallel=${{ needs.check.outputs.parallel }} この手法は dynamic-changesets.yml による判定と nx affected で検出された影響範囲に乖離がある場合にも有効です。 まとめ この記事では、Nx Agentsの導入によりフロントエンドのCIを高速化した事例を紹介しました。 Nx Agentsの提供するDTEの仕組みは、タスク単位の並列化を超えた高速化が可能です。 一方で、プロジェクトの細分化が十分でない場合や、単一のタスクが非常に時間のかかる場合では期待する効果が得られないため、適材適所で利用するのが良いでしょう。 国内のNx Agents導入事例はまだ少ないと思われますが、検証中に得られた知見は今後も発信していきますので、是非お役立てください。私たちの取り組みが少しでも皆様の助けとなれば幸いです。 現在、ファインディでは一緒に働くメンバーを募集中です。 ご興味がある方は↓こちらからご応募ください。 herp.careers

【エンジニアの日常】エンジニア達の人生を変えた一冊 Part1 では大変ご好評をいただきました。 今回はPart2としまして、弊社エンジニアの人生を変えた一冊をご紹介いたします。 ぜひ、読書の秋のお供としてご参考にしていただければ幸いです！ 人生を変えた一冊 SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム プログラマが知るべき97のこと この本を読んだきっかけ Clint Shankさんのエッセイ「学び続ける姿勢」 Karianne Bergさんのエッセイ「コードを読む」 この本から学んだこと Clean Coder プロフェッショナルプログラマへの道 まとめ 人生を変えた一冊 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム オライリージャパン Amazon こんにちは。ファインディでSREを担当している大矢です。ファインディ一人目のSREとして入社し、SRE歴は8年目になります。 「Site Reliability Engineering -- How Google Runs Production System」の日本語訳は、多くのエンジニアに愛読されている名著です。 GoogleのSREチームの取り組みも書かれており、これからSREを目指す方はもちろん、既にSREとしてご活躍されている方も、まだ本書を読まれていないようでしたら是非一度手に取って頂きたい一冊です。 私はかつて2010年代前半から中盤まで大規模なシステムでインフラエンジニアとして働いていましたが、実際はSREに近い業務を担っていました。 同システムでは開発メンバーとのコミュニケーションは活発でモニタリングやCI/CDも導入していましたが、運用面に対して次のようなプレッシャーを感じていました。 システム変更に対する失敗は許容されない 手作業による環境構築や運用が多い 24/7でのオンコール担当 これらのプレッシャーに対する答えの1つが「SRE Book」でした。 この本ではSLIやSLO、エラーバジェット、ポストモーテム、トイルといったSREにとって重要な概念や、オンコール体制の考え方が解説されています。 例えば前述のプレッシャーに対しては次のようなアプローチをとることができます。 SLI/SLOを定めエラーバジェットに基づいた運用をおこないポストモーテムを活かす トイルを減らすため自動化を進める オンコール体制は適切な人数で適切な持ち回りを行う 上記は当たり前のことかもしれませんが、私自身の考えを整理するうえで強力な後押しをしてくれました。 ところで、ファインディではプロダクト毎にSLI/SLOを設定しエラーバジェットに基づいた振り返りを推進しています。 弊社SREチームは立ち上げから日が浅いですが、これからもこの一冊で得た知識を活かし、ファインディのサービスをより信頼性の高いものにしていきたいと考えています。 プログラマが知るべき97のこと プログラマが知るべき97のこと オライリージャパン Amazon 開発推進チームで、RubyとRustとTypeScriptを書いているバックエンドエンジニアの 西村 です。エンジニア歴は4年目です。 この本はエンジニアとして仕事していく中で素晴らしい知見を共有してくれるエッセイ集です。 エッセイ集であるため、タイトルが気になるエッセイから読んでいく形でも問題ないです。 どのエッセイも経験豊かなエンジニア達が執筆しています。例えば、システム設計に熟練したエンジニアやプログラミング言語のコミッタが執筆している豪華な一冊になっています。 エッセイのテーマは、リファクタリング、設計原則、エンジニアとして仕事をしていく姿勢、テスト等の様々なものがあります。 この本を読んだきっかけ 私がエンジニアとして働いて半年ほど経った頃、自分の理想の姿へ近づくために、どうすればいいのか分からなくなった時期でもありました。 そんな中、毎週通っていた ジュンク堂書店池袋本店 でたまたま「プログラマが知るべき」という文字が目に入って、この本を読み始めました。 次のエッセイを読んで、自分がどうすればいいのかを思いつくきっかけになりました。 当時の私を助けてくれたエッセイは次のものです。 Clint Shankさんのエッセイ「学び続ける姿勢」 このエッセイでは、自分自身で学び続けるために、書籍やインターネットを利用した学習やレベルの高い人と仕事をすることなどが推奨されています。 また、技術の進化に対応できるように、常に学び続ける重要性についても書かれています。 このエッセイを読んで、当時は次のことを毎日欠かさずやっていました。 仕事でわからなかったライブラリのメソッドや仕組みをその日のうちにライブラリのドキュメントを読む ライブラリの挙動を理解するためにローカルPCでコードを動かす このエッセイにある「普段利用しているライブラリについての知識を深める」という記述を参考にしていました。 現在、数ヶ月前から新規プロダクトでRustの検証をしています。そんな中、Rustのことをもっと知りたいと思い、 Osaki.rs というコミュニティを立ち上げて、勉強会を開催しています。 この勉強を立ち上げた背景のひとつに、このエッセイにある「勉強会を自ら立ち上げる」という記述を参考にしています。 このOsaki.rsは、connpassのメンバー数が40人ほどになりました。これからもRustの勉強会を続けていきます。 Karianne Bergさんのエッセイ「コードを読む」 このエッセイでは、エンジニアが他のエンジニアや自分の過去のコードを読むことの重要性について述べられています。他のエンジニアが書いた読みやすいコードを読むことで、自身の成長につながると強調されています。 また、過去に自分が書いたコードを読み返すことで、スキルの向上を確認でき、さらなるやる気が湧くとも述べられています。 このエッセイを読んで、当時は次のことを毎日欠かさずやっていました。 自分が関わるプロダクトのリポジトリの全てのプルリクエストに目を通す チームメンバーが作成したプルリクエストを読むことで、チームメンバーがどのようなコードを書いているのかを知ることができ、自分のスキルアップにつながると考えていました。 現在、Rustらしい書き方と読みやすいコードの書き方が分からない時、スター数が多いライブラリのソースコードを読んで、Rustらしい書き方を日々学んでいます。 この本から学んだこと 上記のエッセイを読んで、当時悩んでいた自分がどうすればいいのかを思いつくきっかけになりました。 ぐずぐず悩んでなにも動かないより、少しだけでもいいから知らなかったことを潰していく・挑戦していくことの大切さを学べたと思います。 キャリアやこれから何を学ぶ？と悩んだときは、今でもこの本を読み直します。 また、定期的に書店へ行って、素晴らしい書籍を探しています。 Clean Coder プロフェッショナルプログラマへの道 Clean Coder プロフェッショナルプログラマへの道 作者: Robert C.Martin KADOKAWA Amazon 2024年4月にファインディへ入社して、 Findy Tools の開発をしている林です。 私からは Clean Coderプロフェッショナルプログラマへの道 という本を紹介します。 私はエンジニアとして働き始めて2年目に本書を読みましたが、自身が業務の中で感じていた課題とその解決策のヒントの多くを得られました。 そして、この本の考え方が日々の業務に大きな影響を与えてくれたと考えています。 本書は、タイトルの通り「プロフェッショナルプログラマ」になるための技術的なスキルだけでなく、コミュニケーション力やエンジニアリングに対する向き合い方などのソフトスキルに焦点を当てて紹介されています。 ここでいう「プロフェッショナル」とは、「責任を取る」姿勢を持つことと定義されています。これは、エンジニアが求められた仕様を実現するためのコードを書くだけでなく、最終的にビジネスの成果を達成する責任を果たすことを意味します。 本書では、エンジニアが直面しやすい具体的な課題とその解決策が解説されています。例えば： プロダクトにバグが生じる テスト駆動開発（TDD）や、効果的なテスト戦略の構築が重要。 無理な要求や納期に間に合わない場合 明確に「ノー」と言い、仕様を交渉することがプロの姿勢。 精度の高い見積もりができない PERTやプランニングポーカーなどで具体的な数値を挙げ、現実的な見積もりをする。 チームワークの問題 プログラミングは一人で完結するものではなく、他者との円滑なコミュニケーションが不可欠。 特に印象に残ったのは、本書の第2章にある無理な要求に対して「ノー」と言うことの重要性です。 私は本書を読む前、プロフェッショナルなエンジニアとは、どんな要求にも対応する技術力を持つべきだと考えていました。 しかし、本書を読んで、「できないことは断る」ということもプロフェッショナルの責務であることに気づかされました。 さらに、「試しにやってみる」という曖昧な言葉も問題視されています。 このフレーズは、調査の時間を指しているのか、あるいは実装を試すことを意味しているのかが不明瞭で、誤解を招きかねません。 私自身、何気なく使っていた言葉なのでより明確に何が問題で何をするのかを具体的に言うようにしました。 本書の内容は一朝一夕で身につくものではありませんが、私は業務で困ったときに何度も読み返しています。 特に、最近エンジニアになった方や「プロフェッショナルとは何か？」と漠然としている方にとって、強い指針となる一冊です。ぜひ手に取ってみてください。 まとめ いかがでしたでしょうか？ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。こんばんは。 開発生産性の可視化・分析をサポートする Findy Team+ 開発のフロントエンド リードをしている @shoota です。 先日、 END が 【フルスタックエンジニアへの道！】React と TypeScript の修行をした話 というタイトルで、フルスタックエンジニアを目指すためのフロントエンドの修行の記事を投稿いたしました。 こちらの記事では React / TypeScript において個人学習程度のレベルにあった END が、機能開発を自走可能になるまでの内容が書かれています。 そこで本記事では、END の成長と挑戦をサポートし、実際に指導にあたった私がメンター視点での話をいたします。 育成のはじまり 下準備 ゴール設定 助走をしてもらう 実践 育成の方針と実践 トレードオフ 3 ヶ月の成果と分析 プルリクエストの可視化 メンティーの分析 メンターの分析 所感とまとめ 成長したいエンジニアを探しています！！ 育成のはじまり Findy Team+の開発メンバーはバックエンド・フロントエンドにそれぞれ主軸を置きつつ、多くのメンバーがその垣根を超えた貢献ができることを目指しています。 そのなかでバックエンドを主軸としていた END がフロントエンド領域に集中して挑戦したいという話が持ち上がりました。 フロントエンドメンバーの比率が少なく、「片手間ではなく集中して挑戦する」という決意もあり、自分としても前向きに指導担当をさせてもらいました。 下準備 ゴール設定 急に育成をするとなっても何となく始めてしまうとちゃんと成長できているのか、育成をサポートできているのかどうかがわからなくなります。 まずはじめに私がしたのは、エンジニアリングマネージャー(EM) とのすり合わせでした。 具体的には次のような質問から「どのくらいの時間でどこまでできるようになるのか？」をある程度の幅で決めていきました。 メンティーが目指すゴールはどのレベルか？ EM の期待するゴールはどのレベルか？ どれくらいの育成期間をとるか？ ゴールのレベルもざっくりと 3 段階を想定しました。 基本はバックエンドを主軸としつつも、状況にあわせてフロントエンドも書けるようになりたい バックエンド・フロントエンドに分け隔てなく両輪で活動できるようになりたい フロントエンド主軸に移りたい 結果 2 番目のレベルをイメージしながら、 「フルスタックな動きをキャリアの目標として想定しつつ、まずはフロントエンドを自走できるレベル」 を 「とりあえず 3 ヶ月」 で目指してみようとなりました。 助走をしてもらう もともと個人で React は書いたことがあるといっても、Team+の膨大なコードの前に立つとなかなかどこから手を付けたらよいかと不安になるものです。 なのでまずはメンティーの心の準備体操として、フロントエンドの考え方をまとめた読み物を書きました。 読み物 MVC アーキテクチャやオブジェクト指向といった馴染みの概念と照らしながら、どんなパラダイム・シフトが待っているのかをブログのように書いておきました。 このほか、これまでにもフロントエンドの設計や React の思想などに関する社内記事を書いていたので、それらも合わせて共有しておきました。 実践 育成の方針と実践 自分で調べたり考えたりしたことがいちばん身につくので、基本的には寄り添い過ぎず、私のなかでいくつかのゲートを設けて見守ることを計画しました。 私はこれまでもジュニア層のフロントエンドエンジニアの育成経験があったので、これらのゲートが多くの人がぶつかる壁であることを知っており、これをクリアできてそうかをみながらサポートの強弱をつけていく算段です。 成長ステップ React に Props を渡して単純な HTML を出力するコンポーネントを書ける コンポーネントを組み合わせた大きなコンポーネントを型を含めて書ける ユーザーインタラクションのハンドラーを純粋な関数として書ける バックエンド API との通信インターフェースを理解し、コード生成ができる データとコンポーネント間を TypeScript をつかって型安全かつ整合してつなぐことができる 多くの場合に Step. 3 と Step. 5 がよく詰まるポイントで、ここを乗り切るための知識や理解のための伏線を張っていくように、ドキュメントなどをプルリクエストや Slack でどんどん渡していきました。 特に Step. 5 がジュニア層の鬼門で、それまでの React Component の積み上げと API の型定義を同時に整理しなければならないため、データとビジュアルの責務分離、そのための関数と型の設計などで苦戦します。 渡した資料の中で、誤読しやすいものや前提知識が多く必要なものは口頭で補足するなどしながら、これまでの理解度を測って次のステップに必要なものを選んでいくようにしました。 こうして Step. 5 を乗り越えるための理解が積み上がるように進路補正をしていきました。 トレードオフ このように挑戦するメンティー側にはいろいろな壁を超えるための頑張りが必要になってきますが、一方でサポートするメンター側も、自分のパフォーマンスを維持し続けるのが難しくなってきます。 どれくらいの厚みのサポートが必要かは個々人によって違いますが、少なくともメンターの 20%くらいはサポートに力を注ぎたいものです。 Findy では Findy Team+ を使って自分のパフォーマンスを計測する習慣がありますが、私は 育成に際してこの数値がある程度は落ち込むことを覚悟 の上で、その落ち込み幅をできるだけ小さくすることにも挑戦していました。 私のマネージャーにもこの想定の落ち込み幅のすり合わせをし、育成と自己パフォーマンスのバランスをとっていることを 1on1 などで話しています。 パフォーマンスを可視化することで数値の変動にきちんと理由付けをできるのが Findy Team+ を使っていく最大の利点です。 3 ヶ月の成果と分析 プルリクエストの可視化 実際には想定よりも成長速度が安定していたので最初の 2 ヶ月弱で設定したゴールに到達しそうでしたが、とりあえずはそのまま 3 ヶ月間みっちりと進めてみました。 難易度が高すぎないタスクを中心に実施してもらってはいたものの、最終的にフロントエンドへの プルリクエスト数は私とほぼ同等かそれ以上 が出せるようになっていました。 Team+のグラフで可視化してみると次のようになりました。 青が私、オレンジがEND メンティーの分析 先ほどのメンター（私）とメンティー（END）の両方の PR 作成数でした。これをメンティー（END）だけに絞ると、中盤に数値の谷があります。 実はこれが狙い通りで、前述の想定した Step と期間を照らし合わせることで成長の過程が見えてくるようになります。 育成方針とパフォーマンスの谷 はじめは単純な HTML 合成のための Component 作成（Step. 1, 2）で伸びていく数値が、ユーザーインタラクションの実装 (Step. 3) が始まると徐々に鈍化していきます。 インタラクションの実装に慣れてくるとバックエンド API との連動 (Step. 4) のイメージもつきやすきなってきますが、いざこれらをつなごうとすると考慮することが一気に増えるため、数値が下がっています。 そしてこの鬼門を乗り越えると、またぐんぐんと順調に伸びていく事がわかります。 メンターの分析 次に自分がメンターをしている期間にどれくらいのパフォーマンス影響があったかを見てみます。 同じ期間での私の PR 作成数をグラフにすると、何ともつまらないくらいに変化が少ないグラフになりました。 メンターのPR作成数 しかしこれには秘密があります。 まずメンターを始めてからメンティーのプルリクエストはすべてレビューしており、すぐに自分のパフォーマンスに対する影響を感じていました。 具体的には次のようなことを、プルリクエストがあがるごとに都度実施していたためです。 設計意図を汲み取りにくい構造になっている部分を読み解く 厳密でない型定義によって型チェックをすり抜けている箇所がないかチェックする 指摘内容とともに実装サンプルを書いたり、その理由を示すリファレンスを探して提示する。 そこでマネージャーと相談して、自身のプルリクエスト作成数が 4 以下にならないように水準を維持していくことを宣言し、レビューの濃度を調整していったのです。 （それまでの私の平均プルリクエスト作成数は 5.6〜5.8 程度でした） 「そこまで狙い通りにプルリクエスト数を調整できるものか？」と思われるかもしれません。 しかし自分のパフォーマンスを落としては開発が進まず、また一方でメンバーの成長にも投資しなければ全体の生産性が高まりません。この 実績と投資のバランスを自分の数値を軸にする ことで全体最適を図っていったのです。 もっと自分がプルリクエストを書ける状況でもその分は育成への投資に使いました。こうしてマネージャーと合意したパフォーマンスを維持しながら、最大限の育成を進めるのは意外と難しくありません。 所感とまとめ 今回の育成期間の全体を通して、おおむね計画どおりに進めることができました。もちろんメンティーのポテンシャルの高さやメンターの経験もあってのことですが、次のような点が成功への道しるべになったと思います。 メンティーのゴール設定を 技術リードとエンジニアリングマネージャーの両者 で合意してから開始したこと 適切なステップとぶつかる壁を用意したこと 成長のための「適度なストレス」を感じ続けられるようにすることで、モチベーションを維持 最も大きな谷を超えるための準備としてサポートを意識した メンターのパフォーマンスへの影響とその保証ラインも適切に設定し、 そのパフォーマンスラインを指標として サポートの厚みを可変できるようにしたこと これらによって、開始時に設定したゴールを超えて爆速で成長してもらえました。 卒業の様子 最後に、「メンティーの分析」であげた END のプルリクエスト作成数グラフをもう一度みてみると、非常にゆるやかなダニングクルーガー曲線になっており、非常に興味深いなと思いました。 成長したいエンジニアを探しています！！ バックエンド主軸のあなたでもフロントエンド開発を自走できるレベルまで成長することが出来ます。 もちろんフロントエンドが大好きなあなたも、リードエンジニアを目指してスキルアップできることでしょう！ ぜひ、ご応募お待ちしております (∩´∀ ｀)∩ herp.careers

こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 既に皆さんも御存知かと思いますが、弊社では開発生産性の向上に対して非常に力を入れています。 以前公開した↓の記事で、弊社の高い開発生産性を支えている取り組み、技術についてお話させていただきました。 tech.findy.co.jp ありがたいことに、この記事を多くの方に読んでいただき反響をいただいております。 そこで今回は、↑の記事でも紹介されている「Pull requestの粒度」について更に深堀りしてお話しようと思います。 Pull requestの粒度は、弊社にJOINしたら最初に必ず覚えてもらう最重要テクニックの1つです。 それでは見ていきましょう！ 大きなPull request 適切な粒度とは 適切な粒度を維持するために タスク分解 迷ったら小さく レビューを最優先にする CI高速化 feature flag運用 topic branch運用 まとめ 大きなPull request Pull requestのレビュー依頼が飛んできて確認したら、大きなPull requestでブラウザをそっと閉じた経験がある方は少なくないと思います。 大きなPull requestにおけるデメリットは数多く存在します。 パッと思いつくデメリットを列挙してみます。心当たりがある読者の方もいるのではないでしょうか？ topic branchの生存期間が長くなり、結果的にbase branchとの差分が大きくなりconflictの発生確率が高くなる 変更内容が多岐に渡るため、問題発生時の原因特定に時間が掛かってしまう revert時に余計な内容までrevertされてしまう レビューの質が落ちる レビュワーが見るべき範囲が広くなるため、認知負荷が大きくなる あとで見とこ、、、となりがち 結果的にtopic branchの生存期間が長くなる base branchとの差分が大きくなる conflictの発生確率が高くなる 指摘内容が増え、結果的に手戻りが増える etc このようにデメリットは数多く存在します。システム開発において大きなPull requestの存在は、円滑な開発を阻害する要因となるでしょう。 では「大きなPull request」とは具体的にどんなPull requestのことを指しているのでしょうか？ 適切な粒度とは ここでサイズと粒度の違いを説明する必要が出てきます。 そのPull requestが1つのことに注力できているかどうかが、粒度を語る上で非常に重要なポイントになります。 Pull requestのサイズとは、コードの変更行数や変更ファイル数のことを指します。 しかし、コードの行数や変更ファイル数が多かったとしても、変更内容が一意であれば問題ないはずです。 例えば、関数名を変更して一括置換した場合を例に挙げましょう。変更ファイル数は多くなりますが、変更内容は一意です。 こういったケースの場合、Pull requestの概要欄に一括置換した旨を記載しておけば、変更内容を全て確認せずとも変更後の関数名をレビューし、CIが通ればマージ出来るはずです。 一方、Pull requestの粒度とは、コードの変更内容のことを指します。 例えば、変更ファイル数が少ない一方、データ取得・データ加工・描画処理を同じPull requestで対応した場合を例に挙げて考えてみましょう。 この場合、それぞれの処理は全く異なる内容です。しかし同じPull request内で対応してしまったため、変更内容全てを一度にレビューする必要があり、レビュワーに対する認知負荷が大きくなってしまいます。 極論ですが、たとえ変更行数が1万行を超えていたとしても、変更内容が一意であれば問題は無いと考えています。 逆に変更行数が20行程度の不具合修正の中に「ついでにリファクタ」した内容が含まれていた場合、粒度が大きいと判断しPull requestを分割すべきなのです。 なぜならば、もし不具合修正に失敗していてrevertしようとした際に、ついでにリファクタした内容もrevertされてしまうからです。こういったケースの場合、リファクタをしたPull requestを別で作成します。 つまり本質はコードの変更行数や変更ファイル数ではなく、変更内容そのものにあるということを理解できたかと思います。 粒度が適切であれば、1行だけの修正でも、1万行の修正でも問題ありません。 10のプルリクを1回レビューするよりも、1のプルリクを10回レビューする方が、作成者、レビュワー共に負担が少ないのです。 適切な粒度を維持するために タスク分解 Pull requestの粒度について完全に理解したので、これからは適切な粒度でPull requestを作るぞ！と思い立っても、すぐに実現させるのは難しいものです。 理解はしているけど、やってみるとやることがどんどん増えていき、結果的にPull requestが肥大化しがちです。 それを解決するのがタスク分解です。概要は↓のページを参照してください。 tech.findy.co.jp タスク分解に関しても、別の機会で詳細にお話できればと思います。 迷ったら小さく とは言え、最初のうちは粒度に対して悩むことが出てくると思います。 もっと作り込んでからレビュー依頼を出す？それとも今の段階で出す？でも修正内容が小さすぎないか？などといった葛藤は自分にも経験があります。 そういう時は、より小さい粒度の段階でレビュー依頼を出すことをオススメします。レビューのやり取りの中で粒度に対する議論を行い、そこで認識を合わせればOKです。 Pull requestを大きく作って後から分解するより、小さく作って後から修正内容を追加する方が圧倒的に楽だからです。 まずは小さすぎても良いので小さく作り、そこから肉付けしていくようなイメージでPull requestを作成していくと良いでしょう。 レビューを最優先にする Pull requestの粒度が小さくなった場合、レビュー依頼に対して最優先で取り組む必要があります。 なぜならば、マージしないと次の修正に着手出来ない場合に、レビューがボトルネックになり結果的に開発スピードが遅くなってしまうからです。 自分の作業を一時中断して、10分程度レビューして自分の作業に戻るとコンテキストスイッチを戻すのが非常に難しいと思います。 でも心配しなくてよいです。Pull requestの粒度が適切であれば、レビュワーが確認する内容も小さくなるためレビューに掛かる時間が短縮されます。 そのため、自分の作業を一時中断することになったとしても、すぐまた自分の作業に戻ることができるようになります。 弊社では1つのPull requestのレビューに掛ける時間はほんの数分程度となっています。1分以内で終わることもあります。 粒度が適切なPull requestが当たり前となれば、レビューを最優先にする習慣、文化が組織に根付くはずです。 CI高速化 粒度が小さくなってくると、当然ながら作成されるPull requestの数が増えます。つまりCIの実行回数も比例して増えていきます。 CIの実行回数が増えた状態で実行速度が遅いと、逆に開発効率が落ちてしまいます。CIが遅いからPull requestの粒度も大きくなってしまうといったケースも見たことがあります。こうなってしまうと本末転倒です。 そこでCIの高速化も同時に進めた方が良いでしょう。詳細はこの記事では割愛しますが、↓の別記事を参考にしてみてください。 tech.findy.co.jp feature flag運用 Pull requestの粒度は適切にしたいが、本番環境には影響を出したくない。というパターンはfeature flagを使うと良いでしょう。 ローカル環境でのみ実行されるようなコードにしておいて、その状態を維持しつつbase branchにマージし続けます。本番公開OKのタイミングでfeature flagを解除し、本番環境に反映します。 feature flagの運用方法はSaaSを使う、ライブラリを使うなどの方法がありますが、今回は一番カンタンに導入できる方法の、コード上にフラグを埋め込んで切り替える手法を紹介します。 実際にコードの例を見てみましょう。 export const SampleComponent = () => { const isEnabledNewLabel = process .env.FEATURE_NEW_LABEL === 'true' ; return ( < div > { isEnabledNewLabel && < span > NEW </ span > } < span >Sample</ span > </ div > ); } ; 環境変数に埋め込まれている FEATURE_NEW_LABEL の値によって、 NEW の表示を切り替える単純なcomponentです。 この仕組みにより、ローカル環境の環境変数をtrue、本番環境の環境変数をfalseにすることで、本番環境に影響を与えずに新機能の開発を進めることが可能になります。 開発が完了して本番環境に反映する際には、本番環境の環境変数をtrueにすることで新機能を公開できます。何かしらの問題が発生した場合、本番環境の環境変数をfalseに戻すことで、新機能を非公開に変更可能です。 本番環境で問題が起きなければ、環境変数のフラグとコード上の分岐を削除します。 この手法はfeature flagの管理が煩雑になったり、コード内の分岐やテストケースが増えるといったデメリットもありますが、Pull requestの粒度を適切に維持するためには非常に有効な手段です。 本番環境に影響を出さずに、Pull requestの粒度を適切に維持し続け、スピード感を持って開発する手段の１つとして活用してみてください。 topic branch運用 様々な事情によってfeature flagを使えない、使いたくない場合の手段として、topic branch運用を紹介します。 base branchからtopic branchを切って、そこから更にdevelop branchを切ります。develop branchからtopic branchへのPull requestを作成し、そこで粒度を維持しつつレビューをします。 本番反映OKのタイミングでtopic branchからbase branchへのPull requestを作成し、マージします。このタイミングでのレビューは必要最低限でOKです。なぜなら、develop branchからtopic branchへのPull requestでレビューしているからです。 この手法により、base branchにはリリースのタイミングまで変更内容が反映されません。そのため本番環境への影響を与えず、Pull requestの粒度を適切に維持し続けることが可能になります。 定期的にbase branchからtopic branchへ変更をmergeしておくのがポイントです。topic branchの生存期間が長くなるので、base branchとの差分が大きくなりconflictが発生しやすくなるからです。最低でも1日1回はbase branchの修正内容を取り込んでおくと良いでしょう。 まとめ いかがでしたでしょうか？ 粒度を適切に維持することで、レビュワー、レビュイーの両者に対して優しいPull requestを作成し続けることができます。 弊社では最重要テクニックの1つとしていますが、比較的カンタンに覚えることができ、コツさえ掴めば誰でも実践できる内容です。 是非、皆さんも試してみてください。 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらから ↓ herp.careers

こんにちは、ファインディでFindy Team+（以下Team+）を開発しているEND（ @aiandrox ）です。 普段はバックエンドの開発をメインで担当しているのですが、3ヶ月間フロントエンドの開発に挑戦する機会がありました。短い期間でしたが、フロントエンドテックリードから直接指導してもらいながら実装をすることで、フロントエンドの開発を一人でできるくらいに慣れることができました。 今回は、その経験と学びについて書いていきます。 フロントエンドに挑戦する前の自分について フロントエンドに挑戦することになった経緯 フロントエンドを学ぶ上で助けられたこと フロントエンドのノウハウが溜まった記事の充実 開発ツールが揃っている テックリードとマンツーマンでタスクをやっていく react.devの輪読会 つまづいた点 タスク粒度を適切に分割すること Team+のフロントエンドの責務の考え方 TypeScriptで慣れる必要があったこと 3ヶ月の挑戦の成果 自身の伸びしろ おわりに フロントエンドに挑戦する前の自分について もともとはバックエンド（Ruby on Rails）の開発をメインでしていました。 前職では特にバックエンドとフロントエンドが分かれておらず、Rails View / CoffeeScript / FlowType / jQuery / Reactの混在したフロントエンドを触っていました。また、個人開発でReact / TypeScriptを触ったことはあったものの、あくまでも動くことを重視していたため、アーキテクチャの意識はあまりしていませんでした。 Team+のフロントエンドでは、前年に修正プルリクをいくつか出したので、アーキテクチャはなんとなく把握していました。しかし、既存の実装を踏襲したまま一部を修正する程度だったので、新規でComponentを作ったことはありませんでした。 フロントエンドに挑戦することになった経緯 もともと個人開発などもしていたので、フロントエンドへの興味もありました。将来的にはフルスタックエンジニアとしてスキルを広げたいという思いもありましたが、まずはバックエンドの技術を身に付けることを優先していました。そんな中、「フロントエンドの手が足りないんだけどやってみない？」という提案がありました。 いい機会！ということで、「やりたいです〜」「テックリードと一緒にやってもらおうと思ってます」「やったー」とトントン拍子で進んでいきました。 フロントエンドを学ぶ上で助けられたこと フロントエンドに挑戦するにあたり、以下のサポートがあることにより、スムーズに実装を進めることができました。 フロントエンドのノウハウが溜まった記事の充実 社内記事に「フロントエンドを書くときに何を考えているか、どうしているか」というものがあり、これを参考にできました。「データ層を扱うものはデータ層の責務に閉じ込め、プレゼンテーション層は見た目に注力する。つまり、Pureな Presentational Componentは原則としてロジックを持ってはならない」といった基本的な考え方と、実際に画面を作るときの作業工程を書いていたので、とても役立ちました。 基準の考え方があったので、迷ったときにこれに立ち返ったり、「この場合はどうなのか？」と具体的に質問することができました。 開発ツールが揃っている 開発中はJavaScriptの統合テストツールWallaby.jsを使用していたので、デバッグがスムーズに進み、開発作業が非常に効率的になりました。 tech.findy.co.jp また、CIによって一定の品質が自動的に担保されるので、レビュー前に自分で気付けることも多かったです。ESLintは実装に寄ってくれている感じがあり、hooksの依存などを自動で補完してくれるため初学者としては安心できました。 テックリードとマンツーマンでタスクをやっていく テックリードとは同じチームなので、朝会で進捗の共有をするとき悩みポイントを共有したりしていました。また、実装方針に悩んだときは分報チャンネルに投げて拾ってもらったり、都度ペアプロなどでサポートしてもらいました。 また、自分が作成したプルリクに関してはすべて見てもらっていたので、私の理解度を把握されていました。そのため、プルリクの実装についての指摘や、理解度が浅そうなところなどがあったタイミングで呼び出していただきました。都度口頭で説明されたり自分からも「この理解で合ってます？」と壁打ちすることで、具体的な話から理解度を高めることができました。 ※「体育館裏」は一見怖そうに見えるかもしれませんが、怒られたりすることはありません。コワクナイヨ react.devの輪読会 もともと、フロントエンドをメインとするメンバーでReact公式の Learn React の輪読会を行っていたので、自分も途中から参加するようになりました。 書かれている文章だけだと言葉や概念が難しかったのですが、輪読会では具体的な解説があったりわからない点を質問できたりしたので、実践を理論で補強できました。これにより、プルリクで指摘された内容について「つまりそういうことなのか」と理解できるようになりました。 つまづいた点 タスク粒度を適切に分割すること バックエンドに関しては、技術的にもドメイン的にも慣れているので、1つのクラスごとにプルリクを作成することができていました。しかし、フロントエンドに関しては、ローカルの画面で動く状態まで実装すると大きすぎるプルリクになることがありました。 これを解消するために、1つずつ実装した箇所のテストを書くことで安心してプルリクを出すことができました。バックエンドでは当然のように考えていたことでしたが、フロントエンドではつい画面でのデバッグをしようとする心が働いてしまっていたことを自覚しました。 また、最初はComponentを分割して実装するという意味をあまり理解できておらず、中途半端な状態で1プルリクにしたりもしていました。 Team+のフロントエンドの責務の考え方 フロントエンドの設計は以下のようになっています。 コンポーネント名 カスタムフック名 扱うデータ Page Component Params Hook ブラウザURL Container Component Facade Hook API や ストレージ等 Presentational Component Presenter Hook フォーム Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog この思想をなんとなく頭に入れていたものの、実際に実装している途中で、「この記述はFacadeで書くべきなのか、Presenterで書くべきなのか」と迷うことがありました。 例えば、GAトラッキングの記述を最初はFacadeに書いていたのですが、「GAの実行はUIのクリックアクションをトリガーとするので、Presenterに書くのが適切」といったフィードバックを受けました。propsで渡された関数をPresenterでwrapするといったやり方が、最初は選択肢になかったので、新鮮に感じました。 また、ContainerからContainerを呼んでいる場合もあり、どのようにコンポーネントを分割するべきか迷う場面もありました。画面内のAPIを基準にFacadeを分割し、それに応じてContainerを組み立てていくとわかりやすかったです。 TypeScriptで慣れる必要があったこと 今まで書いてきたRuby / Railsと比較して、TypeScriptには型があるというのが大きな違いですが、個人的にはその堅牢さの中でJavaScriptの関数などを使いこなすのが難しかったです。 例えば、以下のような点です。 null や undefined だけでなく、 0 もfalsyな値になる 配列に対して find を実行すると戻り値が undefined になりうるため、必ず値が存在する場合に find を使うと、型と実態が合わなくなってしまう 3ヶ月の挑戦の成果 この機会に、1つの新機能をテックリードと2人で分担して開発しました。私は、以下のような一覧画面と分析画面をそれぞれ2画面ずつ担当しました。 一覧画面 分析画面 また、安定してプルリクを作成することもできるようになりました。 この3ヶ月を通して、React全体やTeam+のフロントエンドでの設計思想を学び、コンポーネントの責務の分離や状態管理の方法について、実践を通して理解することができました。これにより、他のエンジニアへのレビューもある程度自信を持って行えるレベルになりました。 改めて感じたのは、ただ動けばいいのではなく、Reactで可読性・設計を考慮したコードを書くのは難しいということでした。記述方法の自由度が高い分、意図を設計として乗せる必要がある（テックリードからの受け売り）というのを実感しました。 自身の伸びしろ 今回の挑戦では表示するデータを取得するものばかりだったので、フォーム処理やデータの更新などに今後は積極的に挑戦したいです。 また、react.devの輪読会や共通コンポーネントを変更しようとしたときに、自分の実力不足を感じました。TypeScriptの知識不足や型の伝播を読み解けなかったり、既存の実装の変更対象がわかっても修正方法がわからない、概念はわかるが名称を知らない、などの伸びしろを見つけました。これに関しては、実際にやってみたり他の人のプルリクを参考に考えることを積み重ねていくことで、自身の糧にしていくつもりです。 ライブラリに関する理解もまだ浅いので、今後は開発にくわえて、フロントエンド環境のメンテナンスをできるような知識も増やしていきたいです。 おわりに このように、ファインディではフルスタックを目指す環境で働くことができます。また、現在ファインディでは共に働く仲間を募集中です。興味のある方は、こちらのページからぜひどうぞ！ herp.careers

こんにちは。 2024/7/1 からファインディに入社した斎藤です。 ファインディでは、 Findy Team+ という、エンジニア組織の開発生産性を可視化し、開発チームやエンジニアリングメンバーのパフォーマンスを最大化するためのサービスの開発に携わっています。 今回は、私が入社初月からさくさくアウトプットできた理由についてご紹介します！ 入社初月からプルリク1日4件出せました ファインディでは1日あたり4件プルリクを作成するというのを1つの指標としています。 入社直後は慣れるまでは結構厳しい指標だなと思っていたのですが、この記事で紹介する様々な仕組みのサポートもあり気がついたら初月から達成できていました。 中途入社あるあるだと思いますが、入社直後になかなか成果が出せなくてプレッシャーを感じてしまうということがあります。 簡単なタスク中心ではありますが、初月から貢献しているという実感が持てたので心理的にもたくさんプルリクが出せて良かったなと感じています。 ※1日4件という数値はあくまでアウトプット量の参考です。 闇雲にプルリクをたくさん出せばいいということではありません。アウトプットをプロダクトの成果につなげることが大切です。 入社1ヶ月目プルリク数 1日平均4.6件!! 入社2ヶ月目のプルリク数 1日平均5.7件!! 入社初月からさくさくアウトプットできた理由 Good First Issueの粒度が適切であったこと 新しく参画した人向けのIssueとしてGood First Issueを準備する文化がファインディにはありますが、粒度として難しすぎず簡単に終わりすぎず良い粒度で取り組めるタスクになっていました。 その中で複数箇所に同じ修正を加える作業があり、それをなるべく速く終わらせる意識で対応しました。 例：同じリファクタリングを複数ファイルに渡って対応するタスク ある処理を別ファイルに移動するというリファクタリング 対応すべきファイル名が列挙されていてわかりやすい スムーズな開発を支えるレビューとCI/CDがあること 入社前は開発生産性を可視化するプロダクトを開発しているくらいなので、さぞかし開発がしやすいんだろうなーと思っていましたが、 入社後はその想像を超えて開発がしやすい環境だなと感じました。 特に次のことが要因で開発をサクサク進めることができています。 レビューが速い！とにかく速い！ 1PRあたりオープンからレビューまでの平均時間：3.3h プルリクの粒度を小さくして出す文化が根付いているためレビュー負荷が少ない リリース作業が楽で、時間が取られない リリースPR作成、e2eテストが自動化されていて基本的にマージボタンを押すだけで完了できる この辺りは他の方の 入社エントリー で詳しく紹介されているのでもしよかったら見てみてください。 メンターと密にコミュニケーション メンターとの1on1で不慣れな点を解消しつつ、やることを明確に設定していただけたことで開発に集中できました。 1on1で印象的だったのは一度に多くの情報をインプットしないようにしていただけたことです。 入社後に必要な情報を適切なタイミングで適切な量に分けてインプットしていただけたので、ストレスなく業務に慣れることができました。 適切な頻度(私の場合は週1回)でメンターとの1on1があり、そこで課題を解消できた 1on1以外でも都度メンターに質問して迅速に疑問点を解消でき、開発に集中できた ふりかえりをして日々改善が行われる 私のチームでは2週間に1回の頻度でFindy Team+の「KPTふりかえり」機能を使ってふりかえりを行っています。 そこで出た課題に対する打ち手を議論して改善に繋げる取り組みがとてもいいなと思いました。 ふりかえりで出たアクションはまずは試しにやってみましょうという感じですぐに実行されます。 アクションがすぐに実行されるというスピード感がとてもいいなと思いました。 そしてやってみたアクションについてどうだったかも合わせて次のふりかえりで確認しているので 継続的に改善が行われる仕組みになっています。 新しく参画した私が感じた課題はすでに改善のアクションが進んでいるという状態でした。 (なので課題が思いつかないという課題があります。。。) このように現状に満足せず、より良くするにはどうしたら良いかを全員で考え行動していることが高い開発生産性に繋がっているんだろうなと感じました。 挙げられたProblemに対してTryを設定 全てのコードベースを把握していなくても既存を壊さない仕組み またテストカバレッジが99%で、自分の改修で他へ影響があった場合にはちゃんとテストが落ちるようになっています。 このように、自分の開発に集中できる仕組みが整っているため、 最初から全てを把握していなくても、安全に開発を進めることができます。 なので、全くプロダクトの知識がない入社直後でも 自分の担当作業に集中できるので、サクサクプルリクを出すことができました。 不明点は遠慮せずにすぐに聞いたり相談できる 前述したメンターとの1on1もありますが、定例以外でも不明点はすぐにSlackのメッセージやハドルで聞くことが推奨されています。 オンボーディング資料にも「不明点は都度Slackやハドル、(出社している場合は)対面で確認しましょう！」と明記されており、みなさん快く応じてくれます！ また、ファインディではSlackでtimes(分報)チャンネルを各自持っています。 自分のtimesで疑問をつぶやくといろんな人が助けにきてくれる文化があるので助かっています！ 今後の抱負 ファインディのバリューであり、自分の強みでもある「スピード」を大切に爆速で開発をやっていきたいです！ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

ファインディ株式会社でフロントエンドのリードをしております 新福( @puku0x )です。 GitHub Actionsは、CI/CD以外にも様々な業務の効率化に役立ちます。 この記事では、弊社で実施しているGitHub Actionsを使った自動化について紹介します。 自動化 担当者アサイン ラベル設定 リリース QAチェック項目の抽出 定期実行 まとめ 自動化 担当者アサイン 開発フローの中では、Pull requestを作ってからレビューに出すまでにいくつかのタスクを行うことがあります。 弊社では、Pull requestの作成者がAssignee（担当者）となる場合が多いため、↓こちらのActionを用いてアサインの自動化をしています。 github.com - uses : kentaro-m/auto-assign-action@v2.0.0 with : repo-token : ${{ secrets.GITHUB_TOKEN }} addAssignees : author runOnDraft : true Assigneeのみ自動化しているのは、レビューに出すタイミングをPull requestの作成者側で制御したかったためです。 レビュアーについては、GitHubの標準機能でレビュー用のGitHubチームを作ってランダムアサインするようにしています。 ラベル設定 弊社では、Pull requestをラベルを用いて管理しているチームもあります。 付与するラベルについては、セマンティックバージョニングと相性の良いものが用いられることが多いです。 GitHub - azu/github-label-setup: 📦 Setup GitHub label without configuration. ラベル設定の自動化は、公式のActionがありますので比較的導入しやすいでしょう。 github.com actions/labelerは、最近の更新でブランチ名を基にラベルを設定する機能が追加されました。 この例では、ブランチ名の先頭が feat や fix 等であった場合に対応するラベルを付与するようにしています。 'Type: Feature' : - head-branch : [ '^feat' ] 'Type: Bug' : - head-branch : [ '^fix' , '^bug' ] モノレポの場合、ファイルのパスに対応するラベルを設定すると、どのプロジェクトに影響するか判断しやすくなります。 'Scope: App1' : - changed-files : - any-glob-to-any-file : - apps/app1/**/* - libs/app1/**/* 'Scope: App2' : - changed-files : - any-glob-to-any-file : - apps/app2/**/* - libs/app2/**/* actions/labelerは、Pull requestのタイトルを基にしたラベル設定には、2024年9月現在だと対応していないようです。 その場合は、手動でGitHubのAPIを呼ぶシェルを組む必要があります。 run : | pr_title=$(curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \ -H "Accept: application/vnd.github.v3+json" \ "https://api.github.com/repos/Findy/***/pulls/${{ github.event.pull_request.number }}" \ | jq -r '.title' ) if [[ $pr_title =~ ^feat ]] ; then pr_type='Feature' fi curl -X POST -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \ -H "Accept: application/vnd.github.v3+json" -d '{"labels": ["Type: '"$pr_type"'"]}' \ "https://api.github.com/repos/Findy/***/issues/${{ github.event.pull_request.number }}/labels" いつか公式のActionにも欲しいですね！ リリース 手順の多いリリース作業も、弊社では自動化を取り入れて負担を減らしています。 ここではフロントエンド系のリポジトリに採用されているものを紹介します。 バージョニング用ワークフローを実行 バージョニング用Pull requestが自動生成される バージョニング用Pull requestをマージ バージョニング用Pull requestのマージを起点にリリース用Pull requestが自動生成される （プロダクトによってはここでStaging環境へのデプロイも実行されます） リリース用Pull requestをレビュー後、マージ リリース用Pull requestのマージを起点に本番デプロイ 開発者は「ワークフローの起動」と「自動生成されるPull requestのマージ×2」というシンプルな手順で本番デプロイまでできるようになります。 また、 Conventional Commits に準拠したコミットメッセージを採用しており、自動バージョニングやリリースノートの自動生成といった恩恵も得られています。 デプロイ頻度はFour Keysの指標にも入っていることから、チームの健康状態を知る手掛かりになります。可能な限り高い頻度でデプロイできるよう、仕組みはしっかりと整備していきましょう💪 参考: https://dev.to/puku0x/github-actions-1mi5 QAチェック項目の抽出 リリースの際に、QA担当者がチェックすべき項目をPull requestの履歴から自動抽出しているチームもあります。 まず、 .github/PULL_REQUEST_TEMPLATE.md に次のような項目を設定しておきます。 次に、リリース時に起動するGitHub Actionsから、チェック済みの項目を抽出するスクリプトを起動します。 def category_by_pull (pull) return :planner_qa_pr if body.include? " - [x] 企画側QA " return :developer_qa_pr if body.include? " - [x] 開発側QA " return :other_pr end リリース用のPull requestの本文に反映されるため、QA担当者が何を見るべきかがわかりやすくなります。 定期実行 cron が使えるのもGitHub Actionsの良いところです。 on : schedule : - cron : '30 0 * * 1-5' # 平日09:30 (JST) 休日・祝日の考慮が必要な場合は、次のように前段に判定用のジョブを仕込んで needs で繋ぎます。 check : outputs : is_holiday : ${{ steps.check_holiday.outputs.result }} steps : - run : npm install @holiday-jp/holiday_jp - uses : actions/github-script@v7 id : check_holiday env : TZ : 'Asia/Tokyo' # タイムゾーン固定必須 with : script : | const holidayJp = require('@holiday-jp/holiday_jp'); return holidayJp.isHoliday(new Date()); some_job : needs : check if : needs.check.outputs.is_holiday == 'false' outputs は string で返ってくるため、 boolean で扱いたい場合は fromJson(needs.check.outputs.is_holiday) のように変換すると良いでしょう。 まとめ この記事では、GitHub Actionsを使った様々な自動化の手法を紹介しました。 公式が提供するActionの他にも、世の中には有用なActionがたくさんあります。 サードパーティ製のActionの利用については、「要件を満たせるか」「セキュリティ上の懸念はないか」「継続的なメンテナンスが期待できるか」等が選定の基準となるでしょう。 前回の記事では GitHub Actions高速化の事例 を書いておりますので、合わせてご覧いただけたらと思います。 弊社の他のGitHub Actions活用事例は、次のスライドで紹介しております。 ファインディでのGitHub Actions活用事例 - Speaker Deck こちらの発表については、connpassのイベントページにアーカイブ動画へのリンクを載せております。皆様の参考となれば幸いです。 findy.connpass.com ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに こんにちは。プロセス改善・アジャイルコーチで、Tech Blog編集長の高橋（ @Taka_bow ）です。 皆さんは、2021年6月に生まれた GitHub Copilot を利用していますか？ この生成AIベースのコーディング支援ツールは、コードの自動補完や生成、関数の自動生成、エラー修正支援など、開発者の作業を多面的にサポートします。 ファインディでは2023年3月から導入し、開発チーム全員が日常的に活用しています。Findy Team+で効果を測定した結果、コーディングの効率化やコミュニケーションコストの削減、さらには開発者の満足度向上など、多くの利点が確認されました。 今回は、このような ソフトウェア開発における生成AIの影響を分析した最新の論文を紹介 します。GitHub Copilotが開発プロセスにもたらす変化や、開発者の生産性への影響についての研究が書かれた、興味深い論文です。 はじめに 生成AIが高度なスキルを要する仕事に与える影響 実験の概要 具体的な成果 シニア開発者には控えめな効果 ジュニア開発者への影響 シニア開発者への影響 詳細な比較 ツール採用パターンの違い 補足：Accentureの実験初期のデータ破棄（論文付録D） おわりに：試されるのは「人間」 お知らせ！ 生成AIが高度なスキルを要する仕事に与える影響 2024年9月5日、GitHub Copilotに関する1つの論文がプレプリントサーバーのひとつ SSRN(Social Science Research Network) に公開されました。 papers.ssrn.com 直訳すると 「生成AIが高度なスキルを要する仕事に与える影響：ソフトウェア開発者を対象とした3つのフィールド実験からの証拠」 といったところでしょうか。 査読前論文なので、現在は誰でも読むことが出来ます。 この論文は、Kevin Zheyuan Cui氏（プリンストン大学）、Mert Demirer氏（マサチューセッツ工科大学）、Sonia Jaffe氏（マイクロソフト）、Leon Musolff氏（ペンシルベニア大学ウォートン校）、Sida Peng氏（マイクロソフト）、およびTobias Salz氏（マサチューセッツ工科大学）によって執筆されたもので、 大規模な実験 の結果を分析した科学的アプローチの成果が記されています。 実験の概要 この研究では、GitHub Copilotの効果を検証するため、大規模なランダム化比較試験が行われました。実験の舞台となったのは、Microsoft、Accenture、そして匿名のFortune 100エレクトロニクス製造会社の3社です。 驚くべきことに、この実験には実に 4,867人 もの開発者が参加しました。 参加者は2つのグループに分けられ、一方には GitHub Copilot が提供され、もう一方は 従来の開発手法 を継続しました。この比較により、GitHub Copilotが本当に開発者の生産性を向上させるのか、客観的に検証することが目的でした。 また、各社の実験期間は次の通りです。 Microsoft ：2022年9月初旬から2023年5月3日まで（約7ヶ月間） Accenture ：2023年7月末から2023年12月まで（約4ヶ月間） 匿名の大手企業（Fortune 100） ：2023年10月から2ヶ月間（段階的にロールアウト） このような実験の設計により、異なる企業環境や期間での GitHub Copilotの効果を包括的に評価することが可能となりました。 具体的な成果 実験結果は、GitHub Copilotの効果を明確に示しています。 GitHub Copilotを使用した開発者グループでは、次のような顕著な改善が見られました。 タスク完了数: 平均で26.08%増加 （標準誤差: 10.3%） コミット数: 13.55%増加 （標準誤差: 10.0%） コードコンパイル回数: 38.38%増加 （標準誤差: 10.0%） これらの数字は、GitHub Copilotが開発作業全体の効率を確実に向上させていることを示しています。特筆すべきは、経験の浅いジュニア開発者への効果です。このグループでは、 GitHub Copilotの採用率がより高く 生産性の向上がより顕著 であったことが報告されています。このことから、GitHub Copilotが特にキャリア初期の開発者のスキル向上と生産性増加に大きく貢献する可能性が示唆されています。 シニア開発者には控えめな効果 この研究で特に注目すべきは、GitHub Copilotがジュニア開発者とシニア開発者に与えた影響の違いです。 ジュニア開発者への影響 GitHub Copilotは、経験の浅い開発者に対して特に大きな効果を示しました。 新しいコードの書き方や構文を効率よく学習 タスクの進捗が大幅に向上 プルリクエスト数が40%増加（シニア開発者は7%） これらの結果から、GitHub Copilotはジュニア開発者にとって単なる補助ツールを超えた 学習ツール としての役割を果たしていると考えられます。 シニア開発者への影響 一方、シニア開発者に対する影響は比較的小さいものでした。これには次のような要因が考えられます。 すでに確立された作業スタイルがある 新しいツールの採用に対する慎重さ 詳細な比較 次の表は、ジュニアとシニア開発者におけるGitHub Copilotの効果の違いを示しています。 項目 ジュニア開発者 シニア開発者 プルリクエスト増加率 40% 7% コミット数増加率 21% 16% ビルド数増加率 29% 13% GitHub Copilot採用率 82.1% (±2.1pp) 76.8% (±2.1pp) 採用後1ヶ月後の継続使用率 84.3% 74.8% GitHub Copilot提案受け入れ率 25.2% 24.7% 注：この研究では、会社での採用時の職位や在職期間に基づいて開発者を「ジュニア」と「シニア」に分類しています。具体的な基準については詳細が明らかにされていません。 ツール採用パターンの違い 実験結果から、GitHub Copilotの初期採用率は予想外に低かったことが分かりました。 Microsoftでは最初の2週間で採用率が42.5%にとどまり、 リマインダー後に64%まで上昇 。Accentureでは全体で約60%の採用率でした。 この結果は、新しいツールの導入には単なる提供以上のものが必要だということを示しています。適切なトレーニングやサポートが不可欠で、段階的な導入や定期的なリマインダー、効果的な使用法の教育セッションなどが有効な戦略となりそうです。 これらの知見は、GitHub Copilotに限らず、新技術の導入時に直面する一般的な課題を反映しています。単にツールを導入し、現場任せにするだけでは、効果的に活用できないでしょう。急速に進化する開発環境では、新ツールを戦略的に導入し、継続的にサポートすることが、組織の競争力を保つうえで極めて重要です。 補足：Accentureの実験初期のデータ破棄（論文付録D） Accentureの実験には意外な展開がありました。2023年4月に同社が実施した大規模なレイオフ（19,000人の従業員削減）により、当初の実験が中断を余儀なくされたのです。 このレイオフは実験にも大きな影響を与えました。 実験参加者の42%が影響を受ける データの質に問題が生じる GitHub Copilotの使用状況や採用データの記録が不十分に 結果として、この初期実験のデータは信頼性に欠けるものとなりました。しかし、204人の開発者に絞って行った分析では、次のような傾向が見られました。 プルリクエスト数: 39.18%減少 (標準誤差: 36.78%, 統計的に有意ではない ) コミット数: 43.04%増加 (標準誤差: 38.80%) ビルド数: 12.33%増加 (標準誤差: 53.60%) これらの結果は統計的な信頼性が低く、実験結果としては参考程度にとどめるべきでしょう。 おわりに：試されるのは「人間」 この研究から、GitHub Copilotがソフトウェア開発者の生産性向上に確かな効果をもたらすことが明らかになりました。特に、ジュニア開発者への顕著な効果は注目に値します。 一方で、シニア開発者への効果が限定的だった点も興味深い発見です。これは、経験豊富な開発者がすでに高いスキルを持ち、AIのサポートをそれほど必要としていない可能性を示唆しています。 しかし、ジュニア開発者がAIの提案を鵜呑みにするリスクも考慮する必要があります。ここで、シニア開発者によるコードレビューの重要性が一層高まると言えるでしょう。 調査会社の 米ガートナーが発表した内容 によると、AI コードアシスタント（生成AI）に関するマジック・クアドラントと共に、次のような予測がなされていました。 戦略的計画の仮説 2027年までに、ソフトウェア開発ライフサイクル（SDLC）のあらゆるフェーズを拡張するためにAIを活用するプラットフォームエンジニアリングチームの割合は、5%から40%に増加する。 2027年までに、80%の企業がAIで拡張されたテストツールをソフトウェアエンジニアリングツールチェーンに統合しており、これは2023年初頭の約15%から大幅な増加となる。 2027年までに、AI生成コードに対する”ヒューマン・オーバーサイト”（人間がAIに対して動きを見たり止めたりできる） *1 が不足しているために、本番環境に流出するソフトウェア欠陥が25%に達し、2023年の1%未満から大幅に増加する。 2028年までに、90%の企業のソフトウェアエンジニアがAIコードアシスタントを使用するようになり、2024年初頭の14%未満から増加する。 2028年までに、生成AI（GenAI）の使用により、レガシーアプリケーションのモダナイゼーションコストが2023年の水準から30%削減される。 Figure 1: Magic Quadrant for AI Code Assistants ここでも、人間側によるチェックが不足することでソフトウェア欠陥の上昇が予測されており、結局のところ、 AIツールの活用と人間の経験や判断力のバランスが、質の高い開発プロセスの鍵 となりそうです。 私たちに求められるのは、技術の進化を単に観察するだけでなく、それを最大限に活用しつつ、人間ならではの創造性や洞察力を発揮していくことです。この新しい時代の開発環境で、私たちはどのような価値を生み出していけるでしょうか。その答えを、皆さんと一緒に見つけていきたいと思います。 お知らせ！ 現在、私と一緒にイネイブリングチームの立ち上げを行うメンバーを探しています！ イネイブリングチームは、単なる開発支援を超えた重要な役割を担います。 組織全体のエンジニアリング力を向上 開発スキル向上のためのトレーニングやワークショップを実施 プロセス改善の提案とコーチングを行い、開発生産性とDevExを向上 社内外のエンジニアを対象とした活動を展開 このチームで、ファインディの成長エンジンとなりませんか？興味がある方は、ぜひこちらをクリックしてみてください↓ herp.careers 他にも、ファインディでは一緒に働くメンバーを募集中です。 herp.careers *1 : AIの文献で良く出てくる"human oversight"は適した日本語訳がなく、一旦このように訳した