こんにちは。Findyでモバイルアプリ開発を担当している加藤と主計です。 Findy初のモバイルアプリ「Findy Events」については、先日 React Native選定の経緯と立ち上げの全体像 を公開しました。 前記事ではUIライブラリ周りには深く踏み込めなかったので、今回はその続編です。UIライブラリの選定と実装パターンに絞ってお届けします。 具体的には、当初採用していたTamaguiからHeroUI Native + react-native-unistylesに乗り換えるまでの判断と、Wrapper Componentを軸にしたUI構築の進め方が中心です。 なお、本記事で題材にしているFindy Eventsは、 App Store と Google Play で公開しています。 Tamagui採用の背景 Tamaguiを使ってみて見えてきた課題 Android実機固有の挙動 Sheet表示直後のタップが効かない Sheet内のScrollViewでスクロールするとSheetが閉じる Expo SDK 54対応のタイミング HeroUI Native + react-native-unistylesに変更を決めた理由 β版採用のリスクとその対策方針 具体的なコード例 HeroUI NativeのWrapper Component react-native-unistylesとWrapper Componentを組み合わせたUI Componentの実装 まとめ Tamagui採用の背景 Findyのモバイルアプリ開発で、当初UIライブラリとして採用していたのは Tamagui 。 選定時の候補は gluestack-ui とTamaguiの2つで、最終的にTamaguiを選びました。 決め手となった理由は大きく3つあります。 1つ目は、ライブラリとしての信頼性と情報量です。 Tamaguiはv0.1.0が2021年3月にリリースされ、5年以上にわたって開発が続いているOSSです。 GitHubのスター数や提供されるComponent数の充実度から、本番プロダクトに採用しても大きく外さないと判断しました。歴史がある分、ネット上の記事も比較的多く、開発時の調査コストを抑えやすい点も後押し材料です。 2つ目は、iOSエンジニアとしての開発経験との親和性です。 iOS開発ではOSSとして提供されたUIをそのまま利用する、あるいは許容範囲で改変するアプローチが一般的で、Tamaguiはこのメンタルモデルに合致していました。 SwiftUIと同じ宣言的UIの思想を持ち、縦方向に並べるSwiftUIの VStack がTamaguiの YStack に対応するように、子要素を軸方向に積み上げてレイアウトを組み立てる考え方が共通している点も馴染みやすいポイントです。 一方のgluestack-uiは、shadcn/uiと同様にCLIでComponentのコードを自分のリポジトリに生成し、必要に応じて編集して使う方式を採っています。Tailwindライクなクラス指定と合わせて、モバイルエンジニア出身の自分にはやや取っ付きにくく感じました。 3つ目は、Propsベースで直感的にスタイリングできることです。 <Stack m="$2" p="$2" backgroundColor="$background"> のように、Componentに対してProps経由でデザイントークンを直接当てられ、感覚としては昔ながらのCSSやSwiftUIのmodifierに近い書き味で扱えます。 デザイントークンによるテーマ管理でライト/ダークテーマの切り替えが容易な点も決め手になりました。 Tamaguiを使ってみて見えてきた課題 Tamaguiを採用してアプリを開発する中で、幾つか見えてきた課題もありました。HeroUI Nativeへの乗り換えを判断した背景でもあるため、ここで率直に共有します。 Android実機固有の挙動 iOSシミュレータやAndroidエミュレータでは問題ないものの、Android実機でのみ起きる挙動に幾つかぶつかりました。ここでは印象に残った2つのケースを、実コードと合わせて紹介します。 Sheet表示直後のタップが効かない メニューや確認ダイアログとして Sheet を表示した直後に、内部のボタンをタップしても反応しないことがありました。 最初はダブルタップが必要なのかと感じましたが、少し時間をおくと反応するため、UIアニメーションの完了までタップが受け付けられていないと推測しました。デフォルトのアニメーションは完了までに時間がかかり、その間タップを取りこぼしていたようです。 そこで Sheet に animation="200ms" のように短い時間のアニメーションを明示的に指定したところ、表示完了までの時間が短くなり、表示直後のタップにもすぐ反応するようになって解消しました。 <Sheet modal open = { open } onOpenChange= { setOpen } snapPoints= {[ 50 ]} animation= "200ms" // 明示しないとAndroid実機で表示直後のタップが効かない > < Sheet . Overlay /> < Sheet . Frame padding = "$4" > < Button onPress = { handleConfirm } > 確定する </ Button > </ Sheet . Frame > </Sheet> Sheet内のScrollViewでスクロールするとSheetが閉じる 選択肢が多い項目を選ばせるUIとして、選択肢一覧を ScrollView で表示した Sheet を出していたのですが、Pixel 10で動作確認していたところ、 Sheet 内をスクロールしようとするとそのまま Sheet ごと閉じてしまう事象が発生しました。 該当箇所はおおよそ次のような構成です。 import { ScrollView } from "react-native" ; import { Sheet } from "tamagui" ; < Sheet modal open = { open } onOpenChange = { setOpen } snapPoints = { [ 80 ] } > < Sheet . Overlay /> < Sheet . Frame > < ScrollView > { options. map (( option ) => ( < Option key = { option. id } option = { option } /> )) } </ ScrollView > </ Sheet . Frame > </ Sheet > Sheet 内の ScrollView でのスクロール操作が、 Sheet を閉じるためのドラッグジェスチャと衝突しているのが原因と推測しています。 暫定対応として Sheet 側に disableDrag を指定したところ、スクロール時に Sheet が閉じる事象は解消されました。 <Sheet modal open = { open } onOpenChange= { setOpen } snapPoints= {[ 80 ]} disableDrag // ドラッグでSheetを閉じる挙動を無効化し、ScrollViewのスクロールと衝突しないようにする > < Sheet . Overlay /> < Sheet . Frame > < ScrollView > { options. map (( option ) => ( < Option key = { option. id } option = { option } /> )) } </ ScrollView > </ Sheet . Frame > </Sheet> ただし disableDrag を指定すると、本来ドラッグで閉じられるはずの Sheet が閉じられなくなり、UX上の妥協が発生してしまいます。 Sheet 周りはAndroid実機での挙動が安定しないケースが続いたこともあり、根本的にはTamaguiの Sheet 自体の利用を見直す必要があると感じはじめ、後にHeroUI Nativeへの乗り換えを検討する一因にもなりました。 Expo SDK 54対応のタイミング ExpoはReact Nativeでクロスプラットフォームのアプリを開発するためのフレームワークで、モバイルアプリの証明書周りを簡単に扱える仕組みや、様々な便利機能をSDKとして提供しています。そのExpo SDK 54は2025年9月11日にリリースされ、TamaguiのGitHub上でも対応に向けたWIP Pull Requestや議論が動いていました。 一方で、Tamagui側の対応版がリリースされたのは2025年11月15日で、対応版リリース日のアナウンスは事前にはなかったと記憶しています。 5年以上の歴史を持つライブラリで、内部に多くの実装を抱えている分、最新Expo SDKへの追従は簡単ではないのだろうと推測しています。OSSライブラリを採用する以上、こうした追従コストとはトレードオフだと改めて感じる出来事でした。 HeroUI Native + react-native-unistylesに変更を決めた理由 ここまで見てきた課題を踏まえ、次のUI基盤としてHeroUI Nativeとreact-native-unistylesを組み合わせる構成を選びました。 HeroUI Nativeを選んだ理由は、Componentの完成度が高く、画面実装のスピードを上げられると考えたためです。デフォルトの見た目が洗練されており、アニメーションやインタラクションも作り込まれているため、細かい調整を加えなくてもそのまま画面を組み立てられます。Findy Eventsはまだ機能を増やしていく段階にあり、必要な画面を素早く形にできることは、UIライブラリに強く求めていた点でした。 スタイリングにreact-native-unistylesを採用したのは、スタイル定義を標準のAPIに寄せたかったためです。HeroUI Native自体は内部のスタイリングにUniwind（Tailwind v4ベースの仕組み）を使っていますが、プロダクト側のスタイルは、React Native標準のStyleSheet APIに近い書き味で扱いたいと考えました。react-native-unistylesなら StyleSheet.create を起点に、色やfontSize、spacing、radiusといったトークンを定義でき、モバイルエンジニアにとっても馴染みやすい書き味になります。 β版採用のリスクとその対策方針 一方で、HeroUI Nativeの採用にはリスクもありました。 検討していた当時のHeroUI Nativeはまだβ版段階のライブラリでした。正式版のv1.0.0は2026年3月19日にリリースされ、Findy Eventsのアプリリリース時点ではv1.0系に到達しています。ただ、採用を判断した時点ではまだ正式版前のライブラリです。β版段階のライブラリを本番プロダクトの土台に据える以上、特に破壊的変更には注意が必要でした。APIがまだ固まりきっておらず、バージョンアップのたびに利用側のコード修正を迫られる可能性があるためです。 そこで、HeroUI NativeのComponentは画面から直接使わず、必ずWrapper Componentを挟んで利用する方針にしました。Wrapper Componentという境界を1枚挟むことで、HeroUI Native側のAPIが変わっても、修正をPrimitive層に閉じ込められます。 この方針は、破壊的変更への備えであると同時に、将来的にHeroUI NativeのComponentを自分たちの独自実装へ切り替えたくなった場合にも効きます。利用側はWrapper Component経由でしかComponentに触れていないため、内側の実装をHeroUI Nativeから独自実装へ差し替えても、画面側のコードに影響を出さずに移行できます。 具体的なコード例 ここでは、HeroUI NativeのComponentをWrapper Componentとして定義し、react-native-unistylesと組み合わせて画面を構築するまでの流れを紹介します。 HeroUI NativeのWrapper Component まず、最もシンプルな例として、 Skeleton のWrapper Componentのコードを見ていきましょう。 // src/components/primitives/skeleton/skeleton.component.tsx import type { SkeletonProps } from "heroui-native" ; import type { PropsWithChildren } from "react" ; import { Skeleton as HeroUISkeleton } from "heroui-native" ; type Props = PropsWithChildren < Pick < SkeletonProps , "isLoading" | "style" > >; export const Skeleton = ( { isLoading = true , style , children } : Props ) => { return ( < HeroUISkeleton isLoading = { isLoading } variant = "shimmer" style = { style } > { children } </ HeroUISkeleton > ); } ; HeroUI NativeのComponentは多くのPropsを持っていますが、アプリ内で実際に使うPropsは限られます。 Wrapper Componentを定義する時に、 Pick<> で必要なPropsだけを公開することで、利用側のインターフェースをシンプルに保つことができます。 また、 variant のようにアプリ全体で固定したい設定値はWrapper Component内で埋め込むことで、利用側が意識する必要がなくなります。 次に、もう少し複雑な例として、 Button のWrapper Componentのコードを見てみましょう。 HeroUI Nativeには Button.Label や Card.Body のように、サブComponentを持つCompound Componentがあります。 ラップした後も Button.Label のような呼び出し方を維持したい場合は、 Object.assign() を使って親ComponentにサブComponentを紐付けます。 // src/components/primitives/button/button.component.tsx import type { PropsWithChildren } from "react" ; import { Button as HeroUIButton } from "heroui-native" ; import type { ButtonLabelProps, ButtonRootProps } from "heroui-native" ; import { StyleSheet } from "react-native-unistyles" ; export type ButtonComponentProps = PropsWithChildren < Pick < ButtonRootProps , "style" | "size" | "onPress" | "isDisabled" | "animation" > >; export type ButtonLabelComponentProps = PropsWithChildren < Pick < ButtonLabelProps , "style" > >; const ButtonRoot = ( { children , style , size , onPress , isDisabled , animation , } : ButtonComponentProps ) => { return ( < HeroUIButton style = { style } size = { size } onPress = { onPress } isDisabled = { isDisabled } animation = { animation } > { children } </ HeroUIButton > ); } ; const ButtonLabel = ( { children , style } : ButtonLabelComponentProps ) => { return ( < HeroUIButton . Label style = { style } > { children } </ HeroUIButton . Label > ); } ; export const Button = Object . assign (ButtonRoot, { Label : ButtonLabel, } ); このように Button.Label の形でアクセスできるため、利用側のコードはHeroUI Nativeの元のAPIと同じ使い心地を維持できます。 react-native-unistylesとWrapper Componentを組み合わせたUI Componentの実装 続いて、定義したWrapper Componentをreact-native-unistylesと組み合わせて、実際の画面で利用するUI Componentを作る例を紹介します。 まず、カラートークンを定義したファイルを用意します。 // src/styles/generated/primitive-colors.ts export const primitiveColors = { black : "#000000" , white : "#ffffff" , ... blue400 : "#377ecd" , blue500 : "#055ec1" , blue600 : "#044b9a" , ... } as const ; export type PrimitiveColors = typeof primitiveColors ; 次に、react-native-unistylesで、テーマに沿ったスタイリングを効率的に行えるように、 StyleSheet.configure でアプリ全体のテーマトークンを定義します。 本アプリでは、色やフォントサイズ、spacing、角丸などをトークンとして管理しており、Componentごとの配色もここに集約しています。 // src/styles/index.ts import { StyleSheet } from "react-native-unistyles" ; import { primitiveColors } from "./generated/primitive-colors" ; const tokens = { colors : primitiveColors, fontSize : { xs : 11 , sm : 12 , md : 14 , lg : 16 , xl : 20 , "2xl" : 22 } , radius : { xs : 2 , sm : 4 , md : 6 , lg : 8 , xl : 12 } , space : { "2xs" : 4 , xs : 8 , sm : 12 , md : 16 , lg : 24 } , } as const ; const lightTheme = { // グローバル定義 background : primitiveColors.white, backgroundPress : primitiveColors.grey50, ... // Componentごとの定義 button : { danger : { background : primitiveColors.red500, color : primitiveColors.white, backgroundPress : primitiveColors.red600, } , } , fontSize : tokens.fontSize, radius : tokens.radius, space : tokens.space, } as const ; const darkTheme = { ... } StyleSheet .configure( { themes : { light : lightTheme, dark : darkTheme } , } ); StyleSheet.create のコールバック関数からこのテーマトークンにアクセスでき、さらにスタイル定義自体を関数にすることで、Propsの値に応じた動的なスタイル切り替えも実現できます。 これを踏まえて、先程のButton Wrapper Componentをカスタマイズした「DangerButton」UI Componentの例を見てみましょう。 // src/components/buttons/danger-button/danger-button.component.tsx import { StyleSheet , useUnistyles } from "react-native-unistyles" ; import { Button } from "@/components/primitives/button" ; import type { ButtonComponentProps, ButtonLabelComponentProps, } from "@/components/primitives/button" ; const DangerButtonRoot = ( { children , style , ... rest } : ButtonComponentProps ) => { const { theme } = useUnistyles(); return ( < Button style = { [ styles.root, style ] } animation = { { highlight: { backgroundColor: { value: theme.button.danger.backgroundPress } , }, }} { ...rest } > { children } </ Button > ); } ; const DangerButtonLabel = ( { children , style } : ButtonLabelComponentProps ) => { return < Button . Label style = { [ styles. label , style ] } > { children } </ Button . Label > ; } ; export const DangerButton = Object . assign (DangerButtonRoot, { Label : DangerButtonLabel, } ); const styles = StyleSheet .create(( theme ) => ( { root : { backgroundColor : theme.button.danger.background, } , label : { color : theme.button.danger.color, } , } )); このように、HeroUI Nativeの className などを隠蔽し、プロダクト固有のスタイル定義をreact-native-unistylesで与えており、HeroUI Nativeとreact-native-unistylesで責務を分割しています。 まとめ 本記事では、Findy Eventsの開発で当初採用していたTamaguiからHeroUI Native + react-native-unistylesへ乗り換えるまでの判断と、Wrapper Componentを軸にしたUI実装パターンを紹介しました。 振り返って改めて感じたのは、UIライブラリの選定は「一度決めて終わり」ではなく、運用しながら継続的に見直す前提で向き合うべきだということです。 Tamaguiは選定時の評価としては妥当な候補で、採用後も多くの場面で十分に機能していました。一方で、Android実機特有の挙動やExpo SDK追従までのタイムラグなど、プロダクトとして長く育てる上で無視できない課題も見えてきます。β版というタイミングを活かしてHeroUI Native + react-native-unistylesに踏み込んだ判断は、開発体験の改善という形で素直に効いています。 実装面では、HeroUI NativeをそのままUI Componentとして使うのではなく、Wrapper Component経由で型・Propsを絞り、スタイル定義はreact-native-unistylesに寄せる責務分離が機能しました。プロダクト固有のテーマや配色をWrapper Component側で受け止めることで、UIライブラリ更新の影響範囲を最小化しつつ、画面側のコードもシンプルに保てています。 Findy初のモバイルアプリということで、技術選定もアーキテクチャも手探りで進めた部分が多くありますが、その都度の判断と振り返りそのものが大きな資産になっていると感じます。本記事の経験談が、同じような選定や設計に向き合っている方の判断材料になれば嬉しいです。 ファインディでは一緒に働くメンバーを募集しています。少しでも興味を持っていただけた方は、ぜひこちらをご覧ください！ herp.careers

こんにちは、ファインディでFindy Toolsの開発をしている本田です。 この記事は「 エンジニア達の人生を変えた一冊 」として、ファインディのエンジニアが人生を変えた本を紹介していくシリーズです。 Part7では、本田・加藤・山田の3名でお届けします。アジャイル開発との出会いになった本、iOSアーキテクチャ設計の答え合わせになった本、AI時代に再読して背筋が伸びた本。3冊それぞれ切り口は違いますが、いずれも自分の中の「開発の判断軸」を作り直してくれた一冊です。 それでは、さっそく紹介していきましょう。 RailsによるアジャイルWebアプリケーション開発 第4版 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ iOSアプリ設計パターン入門 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ 世界一流エンジニアの思考法 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ おわりに ■ 本田 / フルスタックエンジニア ■ ファインディでFindy Toolsの開発をしている本田です。 RailsによるアジャイルWebアプリケーション開発 第4版 RailsによるアジャイルWebアプリケーション開発 第4版 作者: Sam Ruby , Dave Thomas , David Heinemeier Hansson オーム社 Amazon 本書は、原著「Agile Web Development with Rails」をもとに、Rails 3.1に対応する形で翻訳された一冊です。著者には、アジャイルソフトウェア開発宣言の起草者の一人であるDave Thomasと、Railsの作者であるDavid Heinemeier Hanssonが名を連ねています。アジャイルの源流とRailsの源流が、ひとつの本のなかに揃っているというのは、今振り返ってみると改めてすごい組み合わせだと感じます。 ちなみに、そのDave Thomasが、2026年6月17日・18日にファインディが主催するオンラインカンファレンス 「エンジニアの役割の変化に向き合うConference 2026」 に登壇予定です。本書の著者本人の話を聞ける機会でもあるので、興味のある方はぜひチェックしてみてください。 この本を読んだきっかけ 業界4年目の頃、私はC#でウォーターフォールの開発をしていました。仕様を固めて設計書を書き、それに沿って実装し、最後にまとめてテストとリリース。それが「開発」というものだと思っていました。 そんなときに、Railsを使った新しいプロジェクトが立ち上がりました。チームメンバーは全員、Railsも本格的なアジャイル開発も未経験で、何から始めればいいのか分からない状態でした。そこで、みんなでこの本を教科書にして、毎日お昼に少しずつ読書会をしながら進めることにしました。各自一章ずつ読んできて集まり、分からないところを話し合い、サンプルを動かしてみる。それを繰り返して、RubyやRailsを少しずつ自分たちのものにしていきました。 本を中心にしたチームの学びの時間は、いまでも当時を思い出すたびに頭に浮かぶ景色になっています。 本の内容 構成のおもしろさは、Depot（デポ）というオンラインショップの架空のプロジェクトを、章を追って少しずつ作り上げていく形式になっているところです。最初は商品一覧の表示だけ、次にカートをつけて、注文できるようにして、メール送信を加えて……というふうに、本一冊を通じて一つのアプリケーションがインクリメンタルに育っていきます。 機能ごとの章タイトルが「タスクA」「タスクB」と続く構成で、まるで開発の現場でユーザーストーリーをこなしていくかのような体験になっています。Railsの機能を学べると同時に、 「動くものを少しずつ広げていく」開発スタイルそのものを擬似体験できる ように設計されていて、書名どおりまさに「Railsによるアジャイル」を体現した本だと感じました。 この本から影響を受けた点/学んだ点 この本を読んで一番大きかったのは、開発の進め方そのものに対する自分の考え方が変わったことです。 それまでの私にとって、「仕様を固める」「設計を作る」「実装する」「テストする」は、それぞれが大きな塊として順番に並んでいるものでした。ところがこの本でDepotを作っていく体験は、まったく違いました。小さく動くものをまず作って、そこに機能を足し、動かしてみて、足りなければ調整して、また次の機能を足していく。短いサイクルで「動くもの」を中心に開発が進んでいく感覚は、当時の自分には完全に新しいものでした。 同じくらい衝撃的だったのは、Rubyという言語とRailsというフレームワークの書き心地そのものです。それまで書いていたコードと比べると、コードの量が圧倒的に少なくて、それでいて表現したいことがすっと書ける。フレームワークが規約として用意してくれている部分にうまく乗ると、書くべきものに集中できる。これも「開発って、こんなに違うものになるのか」という気づきでした。 「Webアプリケーションをアジャイルに作る」というのは、ツールやフレームワークだけの話ではなく、考え方と書き心地と進め方が一体になって初めて成立するものなのだと、サンプルアプリケーションを作りながら肌で理解できた気がします。 特に印象に残った部分 特に印象に残っているのは、Depotを章ごとに育てていく構成そのものです。 本の最初のほうで作ったDepotは、商品一覧を表示するだけのとてもシンプルなものです。それが章を進めるごとに少しずつ機能が増えていき、最後にはちゃんと注文ができてメールが届く、ひとつのアプリケーションになっている。途中で「これで動くようになった」「ここはこういう改善ができるのか」と、小さな達成感が積み重なっていく感覚は、技術書を読みながら得られる体験としてとても新鮮でした。 そして、それをチームで読書会として体験したことも大きかったです。お昼に集まって、一章ずつ進めて、分からないところは議論して、サンプルを動かしてみる。今思えば、これ自体が「短いサイクルで動くものを増やしていく」という本書で学ぼうとしていたスタイルを、学び方そのもののなかで実践していたのだと思います。本を読むという行為が、ただ知識を得る時間ではなく、チームで開発のスタイルそのものを共有する時間になっていました。 このような方におすすめ 日本語版は更新が止まっているため、今からRailsを学び始める人に第一の選択肢として薦める本ではないかもしれません。ただ、原著は今もアップデートが続いていて、最新版ではRailsの新しいバージョンに対応した内容で読むことができます。 pragprog.com 私個人としては、 Railsとアジャイル開発の出会いをひとつの本でまるごと体験した原体験の本 として、今でも特別な位置に置いています。AIで開発の速度や進め方が変わっていく今だからこそ、「小さく動くものを作って、フィードバックを得ながら育てていく」という当時学んだスタイルが、自分のなかでの開発の考え方の土台になっていることをあらためて感じます。 続いては、Tools開発でファインディ初のモバイルアプリ「Findy Events」を担当している加藤さんです。Clean Architectureを採用したプロダクトをリリースした直後に出会った、設計選定の「答え合わせ」になった一冊について語ってもらいました。 ■ 加藤 / モバイルエンジニア ■ ファインディ株式会社でモバイルエンジニアをやっている加藤です。ファインディ初のモバイルアプリ「Findy Events」を開発しています。 iOSアプリ設計パターン入門 peaks.cc ※現在はPEAKSの公式サイトで電子版のみ購入可能です。 私が紹介する「iOSアプリ設計パターン入門」は、iOSアプリのアーキテクチャを網羅的にまとめた書籍です。 この本を読んだきっかけ 当時の私はMVCのみの開発経験しかない中で、業務でClean Architectureに挑むことになりました。 手探りで設計を進め、なんとかリリースまで漕ぎ着けたものの、本当にこれで良かったのか、正しい形は何だったのかという確信は最後まで持てませんでした。 チーム内でClean Architectureに対する共通認識を取り切ることができず、QCDのDを優先して走り切った経緯もありました。そもそもClean Architectureを採用すべきだったのか、別のアーキテクチャの方が適していたのではないかという迷いも残っていました。 そんなタイミングで本書が発売され、自分の中の答え合わせをしたいという気持ちで手に取った一冊です。 本の内容 本書は冒頭で、一般的なアーキテクチャの歴史と構造を整理するところから始まります。 GUIアーキテクチャとシステムアーキテクチャの両面から解説されており、それぞれの位置づけがクリアになる構成です。 その上で、各アーキテクチャをiOSアプリにどう適用するかが具体例とともに示されています。 アーキテクチャの選定に関する考え方にも一定のページが割かれており、サンプルコードがGitHubで配布されているため、手を動かしながら理解を深められるのもありがたいポイントでした。 この本から影響を受けた点/学んだ点 一番大きかったのは、GUIアーキテクチャとシステムアーキテクチャは組み合わせて使うものだという視点を得られたことです。 それ以前の私は、この二つを同じレイヤーのものとして捉えており、MVCとClean Architectureを並べて比較するような考え方をしていました。 本書を読んでから、例えば、「MVPでGUIを構築しつつClean Architectureでシステム全体を整理する」といった組み合わせの発想ができるようになりました。 実際にその後の業務で「MVP + Clean Architecture」という形に取り組み、本書で得た視点を現場に持ち込めたのは大きな収穫でした。 特に印象に残った部分 第2部のまとめ「アーキテクチャの選定基準」に書かれていた次のような問いかけが、強く印象に残っています。 なんとしてでもClean Architectureを採用すべきでしょうか。 どんなアーキテクチャパターンを採用するとしても、そのパターンの経験があったり、パターンに精通していることが望ましいです。 アーキテクチャパターンが目的になっていないか これらは、当時の私の悩みに正面から答えてくれる内容でした。 Clean Architectureを採用したプロダクトをリリースした直後に本書を読んだこともあり、チームでパターンへの精通が揃わないまま走り切ってしまったことを、ページをめくるごとに痛感させられました。 本来であれば設計を選ぶ前に向き合うべきだった問いを、後追いで突きつけられている感覚です。 iOSに限らず、アーキテクチャ選定の場面では常に心に置いておくべき視点だと感じています。 長期的な開発・保守・運用まで見据えて選ぶことの大切さを、自身の反省と重ねて受け取った章でした。 このような方におすすめ これから、あるいは今まさにiOSアプリのアーキテクチャ設計に取り組むエンジニアにおすすめの一冊です。 iOSアプリのアーキテクチャを体系的にまとめた書籍は今でもそう多くないため、最初に手に取る一冊として機能すると思います。 また、iOSに限らずアーキテクチャの歴史や系譜に興味がある方にも価値のある内容です。 発売から7年近くが経つためTCAは扱われていませんが、TCAにつながるFluxの解説があり、現在のiOS開発の文脈でも参考になる部分は多く残っていると感じています。 最後は、事業推進でカンファレンスサービスを開発している山田さんです。山田さんが選んだのは、世界トップクラスのエンジニアの思考プロセスを言語化した一冊。AIコーディングエージェントが日常になった今だからこそ、再読の意味が増した本について語ってもらいました。 ■ 山田 / フルスタックエンジニア ■ ファインディ株式会社でフルスタックエンジニアをやっている山田です。ファインディのカンファレンスサービスを開発しています。 世界一流エンジニアの思考法 世界一流エンジニアの思考法 作者: 牛尾 剛 文藝春秋 Amazon 私が紹介する「世界一流エンジニアの思考法」は、Microsoft Azure Functions開発チームに身を置く著者が、世界トップクラスのエンジニアたちの思考プロセスと働き方を観察して言語化した一冊です。生産性の本質を「基礎理解の深さ」と「試行錯誤の前に思考する姿勢」に求めており、AI時代に再読する価値がむしろ増した本だと感じています。 この本を読んだきっかけ 最初に手に取ったのは、自身やチームの生産性向上を目的に、社内で技術的に優れたアウトプットを圧倒的な量で出し続ける同僚を意識した時期でした。実装スピードも設計の練度もPRの打数も桁が違う。その差分を言語化したくて、世界一流の現場で同種の人々に囲まれて働く著者の本を読みました。 最近になってAIコーディングエージェントが日常の道具となった時期に、自分の中の「思考順序」がAIを挟んで再び崩れ始めている自覚が芽生え、改めて初心に返り本書を再読することになりました。 本の内容 本書は7章構成で、第1章「世界一流エンジニアは何が違うのだろう？」から始まり、マインドセット、情報整理・記憶術、コミュニケーション、チームビルディング、生活習慣を経て、第7章「AI時代をどう生き残るか？」で締められます。 主軸は「生産性は時間ではなく思考の質で決まる」という立場で、具体的には次のような原則が繰り返し強調されます。 Be Lazy: 作業量を減らし、インパクトのある対象に集中する 理解の三要素: 説明可能／いつでも使える／応用可能、を満たして初めて「理解した」と言える 仮説駆動: 試行錯誤を悪とし、事実→仮説→検証の順序を守る シングルタスク／タイムボックス: マルチタスクは生産性が最低なのでやらない AI時代の生存戦略: 自分が学んだものとAIをどう掛け算するか この本から影響を受けた点/学んだ点 初読で強く影響を受けたのは次の二点でした。 基礎理解には時間をかけること。シニアが平気で数日を「読むだけ」に費やす描写から、表面的に動かす速度よりその後の実装と判断の速度を取りに行く姿勢を学びました。 試行錯誤の前に思考すること。手を動かす前に「事実を掴む → 仮説を立てる → 検証する」の順序を必ず通す習慣です。 再読で痛烈に蘇ったのは、AI時代において自分が崩していた順序の自覚でした。具体的には次の3つの兆候です。 AIのアウトプットの質を上げるために、プロンプトを試行錯誤で叩く回数が、自分の思考時間より長くなっていた AIを並列で走らせる並列業務に流され、シングルタスク原則が崩れていた AIが最初に出した "good code" を正にしてしまい、「bestなコードは何か／そこに至る道筋」を自分の頭で検討する工程が薄くなっていた ここから得た結論は、AIの登場は基礎の重要性を消したのではなく、見えにくくしただけということ。基礎力の向上は今も昔も時間がかかり、長い時間、同じ対象に向き合って初めて芽が出ます。AIを係数として効かせるための「自分側の係数」を、地道に上げ続ける意志が問われていると改めて認識しました。 特に印象に残った部分 第3章で示される「理解の三要素：説明可能／いつでも使える／応用可能」は、初読時から自分の判断基準として一番手元に残った概念です。再読時には、この三要素をそのままAI出力のレビュー基準として転用し、「生成されたコードを自分で説明できるか／別文脈で使えるか／応用が効くか」を改めて意識するようになりました。 もう一箇所は、第1章の「マルチタスクは生産性が最低なのでやらない」という言葉です。AIが並列処理を肩代わりしてくれる時代だからこそ、人間側がマルチタスクで思考の解像度を落とすのは本末転倒で、今手をつけている仕事を1つに限定することがAIを使いこなす前提条件だという文脈は再読で初めて腹に落ちたところがありました。 このような方におすすめ 周囲に桁違いのアウトプットを出すエンジニアがいて、その差分を言語化したい方 AIコーディングエージェントを使い始めてから、プロンプトの試行錯誤に時間を溶かしている自覚がある方 AIが出してきた "動くコード" をつい best として採用してしまっていることに違和感を持ち始めた方 並列タスクで日々が埋まり、1つの対象に深く向き合う時間が減っている方 「AI時代に技術力は不要になるのでは」という風潮に、戒めとしての軸を持ち直したい方 おわりに アジャイルを支える開発スタイル、iOSアーキテクチャを選ぶ視点、そしてAI時代に通用する思考法。今回紹介した3冊は扱うテーマこそバラバラですが、いずれも「自分の中の判断軸」を作り直す体験を与えてくれた本でした。 私はRailsとの出会いを通じて「小さく動くものを育てる」スタイルを、加藤さんはアーキテクチャ選定の問いを、山田さんは基礎理解と思考順序の重要性を、それぞれ本から受け取っています。年次を重ねるほど一冊の影響は薄まるのかと思いきや、振り返ってみるとむしろ「あのとき出会えた」一冊が、いまの判断や設計、思考のクセを支え続けている。エンジニアという仕事ならではの面白さだなと感じます。 皆さんにも、そんな一冊との出会いが一つでも増えるきっかけになれば嬉しいです。 ファインディでは一緒に働くメンバーを募集しています。少しでも興味を持っていただけた方は、ぜひこちらをご覧ください。

はじめに こんにちは！ファインディのTeam+開発部でエンジニアをしている澁谷（ TENTEN11055 ）です。 普段はチームで Findy Context というプロダクトの開発に取り組んでいます。 prtimes.jp 2025年11月、AWS主催のAI-DLC Unicorn Gymに参加し、AI駆動開発の手法であるAI-DLCを実践しました。 学びはとても大きかった一方で、自分たちのチームにそのまま持ち込むには壁もあり、現場の実態に合わせて作り変える必要がありました。 Unicorn Gym参加時の様子はこちら。 tech.findy.co.jp AI-DLCはAIが作業を実行し、人間が監視と判断に集中する開発手法です。 要件・ストーリー・作業単位を整理する Inception 、設計・実装・テストを進める Construction 、IaCやデプロイを担う Operation の3フェーズで構成され、AIが提案する成果物をチーム全員で検証しながら進めます。 チームではそのうち実装に関わるInceptionとConstructionの2フェーズを採用しました。 詳細は次の記事を参照ください。 aws.amazon.com この記事ではAI-DLCをClaude Skill化し、Epic制開発フローの中で要件整理からテストまでを一人のメンバーが一貫して担えるようにした取り組みを紹介します。 はじめに チームが抱える課題 担当領域越境の必要性 AI-DLCをそのまま取り入れる難しさ Epic制開発フローの導入 AI-DLCの2フェーズと付随する作業をClaude Skill化する 1. フォーマットのばらつきが改善 2. 横展開を容易にする 3. ツールを利用してよりシームレスな設計ができる 4. 付随するスキルの精度が上がり、人間の負担を下げる スキル運用後の効果とまとめ チームが抱える課題 これまではPMやデザイナー、QAエンジニアといった専任者と分業する形で開発してきましたが、チーム構成の変化により、エンジニア自身が担当領域を越境していく必要が出てきました。 担当領域越境の必要性 チームのフロントエンド専任者が一人のため、フロントの設計・実装を全て頼るわけにもいきません。 また4月末でQAエンジニアが別プロダクトへ異動となり、実装者のみでのテスト設計、ケース実装を担うことになりました。 さらに専任のPMも他プロダクトを兼務しており割ける時間が限られるため、要件整理など本来PMの領域だった部分にも開発者が踏み込んでいく必要があります。 これらを加味し、エンジニア一人一人が担当領域を広げる必要が出てきました。 AI-DLCをそのまま取り入れる難しさ そこで越境を支援する手段として、これまで個々人で自由に行なっていたAI-DLCをチームの開発フローとして取り入れることを検討しました。 しかしInceptionフェーズは関係者が集まって仕様を決めていくスタイルであり、その実施には一定の同期コストが発生します。 作りたい機能の具体が曖昧であればあるほど全員参加は効果的になりますが、Epicイシューが作成された段階で既に一定の解像度がある場合は、PMも含め全員で擦り合わせをすると、得られる解像度向上に対して投入する時間（チーム全体の同期コスト）の方が目立ってしまいます。 Epic制開発フローの導入 これらの課題を解決する一環としてチームではEpic制を導入しました。 こちらはVPoEの ham さんが Findy Team+ 開発で実施した 個人アサインへのシフト に影響を受けています。 tech.findy.co.jp 各Epicにメンバーをアサインすることで要件整理から開発まで一貫して責任を持つようになり、ボトルネックも発生しづらくなります。 実際の運用としては、大まかに次の流れで開発を進めています。 Epic担当者はAI-DLCスキルを用いてInceptionドキュメントを作成する ワイヤーフレーム作成スキルに1のドキュメントを読み込ませ、HTMLでワイヤーを作成する 1と2を元にデザイナーとPMに確認をとる AI-DLCスキルでConstructionドキュメント、テスト設計、テストケースを実装する デザイン、実装、テスト 受け入れ確認、リリース チーム内ではこれらを用いたフローを AI-E-DLC (AI - Epic - Driven Development Life Cycle) と名付けており、今後も運用と改善を重ねていこうとしています。 ここからはこのフローの1と4で利用するAI-DLCスキルについて掘り下げていきます。 AI-DLCの2フェーズと付随する作業をClaude Skill化する 同じプロンプトを用いてドキュメントを作成しても、AIの成果物にはばらつきが生じる可能性があります。 そのためAI-DLCにおけるInceptionとConstructionのドキュメント生成をそれぞれスキル化し、潜在的な課題をいくつか改善することができました。 1. フォーマットのばらつきが改善 同じAI-DLCのプロンプトを使っても、書き手によって構成・粒度にばらつきが生じたり、必要な情報が抜けたりすることで、実装・テスト設計・レビューなどの工程でAIが読み取りにくいドキュメントが生まれていました。 この課題に対し、スキルで手順と出力フォーマットを固定し、誰が実行しても同じ骨格のドキュメントを出力できるようにしています。 ちなみにこのフォーマットの固定化が多くの改善の起点になっており、これなしでは後述の内容も実現しえませんでした。 2. 横展開を容易にする AI-DLCの手法を各メンバーが再現するには、フェーズ理解・プロンプト設計・観点整理の習熟が必要であり属人化しやすいものですが、スキル化により手順がガイドされるため、未経験者でも気軽に実践できる「型」として提供できます。 またFindy Contextが複数リポジトリで構成されるため、リポジトリ非依存で動くスキルにしています。 今まで各リポジトリに合わせたプロンプトを用意する必要がありましたが、どれにおいても同じスキルを呼べばOKな状態にしています。 汎用性の高いスキルにすることでどこでも誰でもAI-DLCに則ったドキュメントを作成できるようになりました。 3. ツールを利用してよりシームレスな設計ができる AIからの質問事項にはClaude Codeの AskUserQuestion ツールを必ず利用させています。 InceptionではAIから人間への質問フェーズが存在し、ドキュメントに記載された質問に対し人間が回答を書き込むのが基本でした。 これに対し選択 or 自由回答という形式をとり回答候補を提示してもらうことで一から考えることがなくなるため、回答作業だけでなく脳の負担も軽減されました。 他にも一部の難易度の高い作業をAgentに任せるなど、場面に適した設定を共有できるのもスキル化の利点の一つです。 AskUserQuestionを利用した際のサンプル 4. 付随するスキルの精度が上がり、人間の負担を下げる フォーマットのばらつきが改善されたことにより、 専用のテスト設計・ケース実装スキルとドキュメントレビュースキル も作成することができました。 テストをAIで用意する際、何を材料とするかが重要です。 もしコードを材料とした場合、そのコードが仕様に沿っていなければ誤ったテストとなってしまいます。 このテスト設計・作成スキルはInception・Constructionドキュメントを材料とし、エンジニア・PM・デザイナー間で認識が揃った仕様を前提とするため高い精度を出すことができます。 またドキュメントレビューに関してはAI-DLCの中で最も人間の負荷が高い作業です。 AI-DLCスキルで生成されるドキュメントは10ファイルを超え、全部均等にレビューしようとすると破綻します。 そこでレビュースキル側で、生成されたドキュメントを「核となるドキュメント（仕様の中核を担うもの）」と「補助となるドキュメント（核を支える補足）」に分類し、Epicイシューとも照らし合わせて齟齬や抜けがないかをチェックさせています。 これにより人間が熟読すべきドキュメントを明確にし、レビュー負荷を下げることができました。 スキル運用後の効果とまとめ 運用を始めて数日が経ちましたが、想像以上に強力なスキルとフローであると感じています。 チームの課題でもあった「役割の越境」に対して有効なアプローチとなり、これまで専任者（PM・デザイナー・QAエンジニアなど）に頼っていた作業の下地を実装者が担い、専任者はレビュー・判断に集中できるようになりました。 習熟度の壁を下げられたことも大きな成果で、スキル作成後に説明する場を設けなくても気づいた時には他メンバーが使っており、数日後にはスキルの改善PRも上げてくれていました。 レビューにおいてもAI-DLCを始めた頃によくあった「ドキュメントレビューしんどい...」という声は幸いまだ聞こえてきていません。 今回の取り組みはAI-DLCをそのまま導入するのではなく、チームの開発体制や課題に合わせて適応させる試みでした。 まだ運用を始めて間もないため改善の余地はありますが、その部分に誰もが参加できる間口を用意できるのもスキル化の利点かもしれません。 ファインディでは一緒に働くメンバーを募集中です！ よかったら覗いてみてください。 herp.careers

こんにちは、ファインディのCTO室でスタッフエンジニアを担当している及川(@rojoudotcom)です。 4月14日(火)〜16日(木)にDevOpsDays Tokyo 2026が開催されました。本記事は、スポンサー登壇者として参加してきたレポートです。 DevOpsDaysは、世界各地で開催されるエンジニア向けの国際カンファレンスです。 開発（Dev）と運用（Ops）の連携、自動化、組織文化、最新の事例やプラクティスを発表しています。日本では DevOpsDays Tokyo として、年に1回開かれています。 本記事では、開発組織の成果を経営層にどう伝えたらいいのかを悩まれている方や、AIを導入したのに成果が見えないと感じる方に向けて書きました。3日間のイベント参加を通じて改めて確信した「可視化は組織が動き出すための前提条件である」というメッセージを、登壇・基調講演・現地での会話の3つの角度から振り返ります。 開発組織は、経営から「見えない」 成果を見やすい形で可視化すれば、見える投資に変わる 経営から「見えない」と言われた開発組織を、仕組み・文化・習慣の3層で診断 組織設計に意図を持つことで組織の活動が見える 成果を見る側に立って翻訳する 仕組みを作り、文化を育て、習慣を変えれば、見えない現場は見える投資に変わる 可視化がない改善は、AIに増幅されない 「可視化されてはじめて、人は動く」 おわりに 開発組織は、経営から「見えない」 DevOpsという言葉についてのおさらいですが、もともと「DevとOpsの壁を壊す」ことから始まりました。コンテナ、CI/CD、SREといった方法論が広まり、Dev-Ops間の景色が変わったと感じる方は多いと思います。 一方で、 Devと経営(Biz)の間の壁は依然として高いままではないでしょうか 。 開発部門が作るソフトウェアは形がなく、損益計算書には給与や販管費などの「費用」としてしか記録されません。経営層の関心は売上向上や費用削減にあるのに対して、開発の関心は製品開発におけるリリース頻度の向上やリードタイム削減にあります。お互いが重要だと思う指標が異なることが、すれ違いを生み続けていると考えています。 成果を見やすい形で可視化すれば、見える投資に変わる 今回の登壇では、ファインディ以前に在籍していた現場の事例を話しました。経営層から状況が見えないと言われていた開発組織を意図を持って再設計し、活動の良し悪しを計測したことで投資の判断ができる状態とした体験談です。 テーマは「Dev-Bizの壁をどう越えるか」。20分のスポンサーセッションで持ち時間は短かったものの、自分の問題意識を言語化する貴重な機会になりました。   経営から「見えない」と言われた開発組織を、仕組み・文化・習慣の3層で診断 私が過去に在籍していたある企業の開発部門の話です。配属された開発部門は発足から20年が経つ自社サービスを担当しており、内製化を進めていたところでした。歴代の担当者は退職済みで、ドキュメントもなく、現場の判断は開発担当者の属人的なナレッジに委ねられていました。 エンジニアリングマネージャとして組織の状況を把握するために現場関係者にヒアリングを始めると、様々なことが見えてきました。 まず、組織のサイロ化が進む仕組みが見えてきました。開発に関わるメンバーはプロジェクトの終了と共に解散するため組織ナレッジが溜まりにくいこと、そして新機能開発チーム（Dev）と運用改善チーム（Ops）は分断されており、特にOpsチームに届けられる改善要求は、その背景が不透明なまま改修が行われていました。 次に、受け身の文化が根付いていました。歴史的に要求は事業部が作成し、開発側は要求を待つ立場だったためです。さらに、上位下達の関係性から、開発側からの提案や意見を出しづらい状況でした。 最後に、経営層からすると、PLやBSの数字以上に開発の状況が見えない状態が続いていて、それ以上踏み込めない状況が習慣化されていました。リソースをどこに集中すべきか、開発予算は適正なのかの判断ができない状況でした。 組織設計に意図を持つことで組織の活動が見える 見えない状態は、組織の設計に「なぜそうしたか」の意図がないことが原因です。最初の取り組みとしてTeam Topologiesで組織体制を再設計しました。すると、顧客の要望がどこからきてどこに流れていくのか（バリューストリーム）を見えるようになり、それぞれの開発チームの責任範囲やチーム間の関係性も明確になりました。 組織の枠組みが整ったところで次はチームの中身（マインドセットや運用ルール）です。アジャイル開発のスクラムフレームワークを導入し、自己管理化を進めていきました。チーム自身が開発案件の優先度や実現方法を話し合うようになりました。さらに、システム的観点から事業部の要望に対する逆提案が生まれるようになりました。 そして、新体制が動き出してきたところでFindy Team+を導入し、開発チームのリードタイムやボトルネックを可視化し、定量的なデータを取り始めました。半年後にはリードタイムが従来比8割短縮、デプロイ頻度も3割増加し、経営層に対しても改善を数字で示せるようになりました。 成果を見る側に立って翻訳する Four Keysによる開発活動の成果や、新機能が完成したときに得られるであろう期待される売上やコスト削減効果は重要な数字ではありますが、経営層が理解するにはもう一歩踏み込む必要があります。 例えば開発生産性が向上したことで稼働可能な人月が増えたと同等の効果と捉えれば、管理会計の項目のどこに増減の影響が生まれるのか。あるいは、リリース回数が増えたことで事業計画がどの程度短縮できるのか。こうした情報は決算書にも書けるような話題で、経営層にとって必要な情報です。 このように、投資判断を行う経営層の立場に立ち、開発の活動を翻訳して伝えることで、ようやく開発部門に対する投資判断の議論ができるようになりました。 仕組みを作り、文化を育て、習慣を変えれば、見えない現場は見える投資に変わる 以上、目の前の問題の直接解決ではなく、問題を生み出す構造（仕組み・文化・習慣）に目を向けて根本解決を促すストーリーでした。 さらに詳しい内容はスライドをご覧いただけるとうれしいです。 見えない開発現場を、見える投資に変える — Speaker Deck 可視化がない改善は、AIに増幅されない 「可視化が大事」とは言われ続けてきました。それでも今このテーマで登壇しようと思ったのは、AI時代に入って、その重要性が以前にも増して大きくなっていると感じていたからです。そして、その直感はカンファレンスの基調講演で裏付けられました。 Google CloudでDORA（DevOps Research and Assessment）プログラムを率いるNathen Harvey氏によれば、 2025年の調査でAI採用率は90%に達した そうです（前年比＋14%）。 一方で、コード品質や個人の生産性は上がったものの、 ソフトウェアデリバリーの安定性は悪化していました 。Harvey氏はこの現象を踏まえて、AIの役割を「 増幅器（amplifier） 」と表現していました。 良いシステムには良い結果を、悪いシステムには悪い結果を増幅するもの という意味合いです。 この比喩がしっくり来たのは、増幅されるためにはまず「何が起きているか」が見えていなければならない、という当たり前の前提が浮かび上がるからです。 可視化されていないデータをAIに与えてもノイズを増幅するだけです。可視化されていない開発組織は、AIを入れても何が良くなったのか悪くなったのかすら判断できません。 AI採用は、可視化された土台の上ではじめて成果に結びつく 基調講演から受け取ったメッセージはそこに集約されていました。 そして、もう一つの基調講演でDevOpsムーブメントの礎を築いた一人であるAndrew Clay Shafer氏が残した「 行動を変えるまでは、何も学んでいない 」という一言も、同じことを別の角度から言っていると感じました。見えなければ学ぶことはできないですし、闇雲に行動することになります。それは学んでいないのと同じことです。 ここで触れた2つの基調講演のセッション情報は次のとおりです。 confengine.com confengine.com 「可視化されてはじめて、人は動く」 3日間で一番心に残ったのは、技術的な議論ではなく、夜の懇親会で交わした一つの会話でした。 懇親会で日本酒を参加者に勧めていたとき、たまたまDay1の基調講演スピーカーのNathen Harvey氏が近くにいました。興奮して握手を交わし自己紹介をすると、彼は「 ファインディのプロダクトを見せて欲しい 」とリクエストしてくれました。 その場でブース担当者を呼んで、開発生産性可視化のデモをしました。彼はそれを見終えた後、こう言いました。 可視化することで、ようやく人は動き出すんだよね。 自分の登壇で伝えたかったことも、基調講演で語られていたDORAの研究も、3日間で出会った人たちが共有していた問題意識も、この一文で言い表されていると感じました。 Four Keysのような生産性指標で 内側の現在地 を、DORAのような調査レポートで 外側の方向性 を捉え、両者のギャップを埋めていきます。 可視化はゴールではなく、組織が動き出すための出発点です。 Dev-Bizの壁を越えるにも、AIを増幅器として活かすにも、共通して まず見えていること が要ります。これが3日間を貫いていたメッセージでした。 翌日のスピーカーインタビューのアイスブレイクで「日本に来てどうですか？」と聞かれたHarvey氏が「 ファインディに会えたことが思い出になった 」と答えてくれたのは、嬉しいおまけでした。 おわりに 開発組織を率いるマネジメント層にとって、可視化は「あれば便利な機能」ではなく「動き出すための前提条件」だと、今回の3日間で改めて確信しました。当社は指標を計測するサービスを提供する側だからこそ、組織を歪ませない設計に責任があると、身が引き締まる思いです。 DevOpsDays Tokyoに参加することで、スピーカー同士、運営の方々、そして海外登壇者との繋がりをつくることができ、DevOps文化に貢献したい気持ちも高まりました。来年の開催も楽しみにしています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

ソフトウェア開発現代史年表Ver2.08 はじめに デリバリーは速ければよいのか 改めて、Four Keysは何を測っているのか 「デプロイ」と「リリース」の混同がFour Keysを遠ざける Dave Farley氏とは 『Continuous Delivery』(2010) は何を変えたか 二つの意味を持つ「リリース」 AI時代に、継続的デリバリーはなぜ重要になるのか AI駆動開発を空回りさせないために 【告知】AI DevEx Conference 2026 - Future of Development Productivity - おわりに はじめに こんにちは。テックブログ編集長の高橋（ @Taka-bow ）です。 冒頭に掲載した「ソフトウェア開発現代史年表Ver2.08」は、ソフトウェア開発の考え方がどのように変化してきたのかを、できるだけ一枚で見渡せるように整理したものです。 この年表の中に、2010年の『Continuous Delivery』があります（赤枠）。 Jez Humble（ジェズ・ハンブル）氏とDave Farley（デイビッド・ファーリー）氏によるこの本は、CI/CDやFour Keysを考えるうえで、出発点にあたる一冊です。 本記事では、この『Continuous Delivery』を起点とする流れを取り上げます。 生成AIによって、コードを書く速度は大きく上がりました。AI駆動開発という言葉も広がり、実装からデプロイまでの時間はますます短くなりました。 しかし、ソフトウェアを速く作れることと、価値あるものを継続的に届けられることは、同じではありません。 そこで今回は、Dave Farley氏の初来日に寄せて、AI駆動開発を機能させる土台としての継続的デリバリーに焦点を当てます。 Dave Farley氏が築いてきた継続的デリバリーとは何か、それがDORA Metricsとどうつながっているのか、そしてAI時代にこの思想がなぜいっそう重要になるのかを整理します。 デリバリーは速ければよいのか むかし、その場しのぎの言い訳や曖昧な返答を「蕎麦屋の出前じゃないんだから」とたしなめる言い回しがありました。そんな比喩が通じるほど、かつての出前（デリバリー）は「遅くて当てにならないもの」と見られていたのでしょう。 いまは違います。Uber Eatsやmenu、出前館のような専門サービスが増え、マクドナルドのように飲食店自身が届けてくれることも当たり前になりました。 「ピザのデリバリーは30分以内」。そんなイメージを持っている人も多いのではないでしょうか。速く届くこと自体が、ひとつの価値になっています。 しかし、30分で届いたピザでも、冷めきっていたり、注文と違うものが届いたりしたらどうでしょう。速く届いたかと、価値あるものが届いたかは、別の問いです。 ソフトウェアの「デリバリー」も同じです。 私たちエンジニアにとってのデリバリーといえば、CI/CDの「CD」、すなわちContinuous Delivery＝継続的デリバリーです。文字どおり、「ソフトウェアの価値」を「継続的」に「届ける」ことを指します。 近年は生成AIの登場によって、実装からデプロイまでの流れが目に見えて速くなっています。ソフトウェアの「デリバリー時間」が短くなっていることは、多くの現場で体感されているはずです。 ただし、速さはソフトウェアのデリバリーパフォーマンスの一面にとどまります。フードデリバリーと同じく、速く届くことと、価値あるものが届くことは別の話です。 この前提に立つと、Four Keysの見え方も少し変わってきます。 改めて、Four Keysは何を測っているのか ソフトウェア開発のデリバリーパフォーマンスを測る指標として、Four Keys、および現在のDORA Metricsが広く知られています。 これは、継続的デリバリー（Continuous Delivery）が重視してきたソフトウェアデリバリーの能力を、計測可能な指標として捉えようとするものです。DORA Metricsを理解することは、継続的デリバリーが目指すものを理解することに直結します。 一方で、お客様と話しているとこんな声をよく耳にします。 「我々にはFour Keysのような計測手法はしっくり来ません。なぜなら、アジャイルみたいに何度もリリースしたりしないんです」 この疑問を考える前に、まずDORAが現在「ソフトウェアデリバリーパフォーマンス」をどう捉えているかを整理しておきましょう。 DORAにおけるソフトウェアデリバリーパフォーマンスの構造 DORAは近年のレポートで、「ソフトウェアデリバリーパフォーマンス」を2つの軸に整理しています。 ひとつは「ソフトウェアデリバリースループット（software delivery throughput）」、つまり、スピードと効率性の軸です。次の3つで測ります。 変更リードタイム（change lead time） デプロイ頻度（deployment frequency） デプロイ失敗時の復旧までの時間（failed deployment recovery time） もうひとつは「ソフトウェアデリバリーの不安定性（software delivery instability）」、これは、品質と信頼性の逆指標（低いほど良い）です。次の2つで測ります。 変更時の障害率（change failure rate） やり直し率（rework rate） 旧来の「Four Keys」（2018年頃）はデプロイ頻度・変更リードタイム・変更時の障害率・サービス復旧時間の4指標でしたが、現在のDORAでは5指標を「スループット」と「不安定性」の2軸に整理し直しています。 この再整理は、DORAがソフトウェアデリバリーを単なる速さではなく、速さと不安定性の両面から捉えようとしていることを示しています。AI駆動開発によってコードの生成量や品質の傾向が大きく動くいま、この見方はますます重要になっています。 次に、これらの指標がSDLC（ソフトウェア開発ライフサイクル）上のどこに当てはまるのかを見てみましょう。 DORA MetricsがSDLC上のどこに当てはまるかを示した図 この図でまず見てほしいのは、デプロイとリリースの位置関係です。デプロイはSDLC上のひとつのフェーズであり、リリース（図中の▼）はそのあとに位置します。 DORA Metricsのうち、頻度として測るのはリリース回数ではなくデプロイ頻度です。ここを取り違えると、「リリース回数が少ない自分たちにはFour Keysは合わない」という違和感が生まれます。 実際、デプロイとリリースをひとまとまりのイベントとして扱う現場も少なくなく、歴史の長い組織ほど、その傾向が根強い印象です。 しかし、DORA Metricsが見ているのは「ユーザーに何回公開したか」ではなく、「変更をどれだけ継続的に本番へ届けられているか」です。図の中でリリースが何度も登場している理由は、後の章「二つの意味を持つ『リリース』」で詳しく扱います。（ここではまず、DORA Metricsは「リリース回数」ではなく、変更をどれだけ速く、安定して届けられているかを捉える指標だと押さえてください。） また、最近はAI駆動開発が広まるにつれて、こんな声も聞くようになりました。 「AI時代にFour Keysは合わないですよね」 この見方も、少し立ち止まって考える必要があります。 生成AIは、とりわけ実装・テストのフェーズを大きく速くします。さきほどの図で見たとおり、実装・テストはデプロイの手前にあります。ここが速くなれば、その変化は下流のデプロイや、DORA Metricsの「変更リードタイム」にも表れます。 もちろん、速くなるのは良い面だけではありません。 生成AIが出力したコードを鵜呑みにすれば、欠陥を見逃すリスクも高まります。その影響は、DORAがいう「ソフトウェアデリバリーの不安定性（software delivery instability）」（やり直し率や変更時の障害率）にも現れます。 つまり、生成AIはDORA Metricsを不要にするどころか、数値を大きく動かします。 だからこそ、DORA Metricsが何を測っていて、何を測っていないのかを理解する必要があります。その理解の出発点が、「デプロイ」と「リリース」の違いです。 次章では、Four Keysへの違和感を生みやすいこの混同を、もう少し丁寧にほどいていきます。 「デプロイ」と「リリース」の混同がFour Keysを遠ざける Four Keysへの戸惑いは、AIが現れるよりも前からあります。 その大きな理由のひとつが、「デプロイ」と「リリース」という二語の混同だと思っています。まずは、この二つを分けておきましょう。 デプロイ（Deployment） リリース（Release） 意味 コードや設定を本番環境に反映する作業 機能をユーザーが実際に使える状態にする判断 性質 機械的・技術的（自動化が可能） ビジネス判断（公開タイミングをコントロール） 頻度 高頻度（日次・時間単位もありうる） 機能ごと・公開戦略次第 ところが、多くの現場ではこの二つが切り離されず、ひとつの大きなイベントとして扱われています。デプロイもリリースも「めったに行わない重い作業」になっていれば、Four Keysが自分たちとは無縁に見えてしまうのも当然の感覚です。 たとえば、ゲートキーパー型のQAを置き、「リリース判定会議」を経て本番に出す流れです。この場合、現場の感覚としては「リリース判定会議 → デプロイ」の順序に見えます。 昔のリリース候補マイルストンも、何ヶ月もかけて次の段階へ進めていく形でした。 flowchart LR A["プレアルファ版<br/>(pre-α)"] --> B["アルファ版<br/>(α)"] --> C["ベータ版<br/>(β)"] --> D["リリース候補版<br/>(RC)"] --> E["ゴールドリリース版<br/>ゴールデンマスター版<br/>(GM)"] これは、ソフトウェアが物理パッケージで出荷されていた時代の名残でもあります。CD-ROMを焼き（書き込み）、紙のマニュアルを同梱して箱に詰める。バグが見つかればディスクの焼き直し、マニュアルにミスがあれば製本のやり直し⋯⋯手戻りは、時間とコストの両面で致命的なダメージでした。 しかし、時代は変わりました。高速なネットワーク、パワフルなPC、ストレージの大容量化、紙媒体の電子化⋯⋯やり方を過去のままにしておく理由は、もうありません。 それでもこの流れを前提にしていると、リリースとデプロイの適切なタイミング、順序、そして頻度の感覚は分からないままです。 この混同をほどき、「リリース」の二つの意味を分離する考え方を体系化したのが、Jez Humble氏とDave Farley氏です。 Humble氏はその後、DORAの設立メンバーとして、DORA Metricsの礎を築いていきました。今回は、もう一人の著者であるDave Farley氏にスポットを当てます。 Dave Farley氏とは Dave Farley氏は、継続的デリバリーを語るうえで避けて通れない人物です。 David(Dave) Farley(Image source: InfoQ.com) Jez Humble氏との共著『Continuous Delivery』（2010、Jolt Award受賞）は、CI/CD、デプロイメントパイプライン、デプロイとリリースの分離といった考え方を広め、現代のソフトウェアデリバリーの前提をつくった一冊です。単著『Modern Software Engineering』（2021）でも、ソフトウェア開発をエンジニアリングとして捉え直す考え方を示しています。 DORA Metricsも、この継続的デリバリーの思想と地続きにあります。つまりFarley氏は、「継続的デリバリーの本を書いた人」にとどまらず、現在のソフトウェアデリバリーの議論そのものに影響を与えてきた人物です。 Farley氏の言葉に重みがあるのは、実践の現場でも大きな仕事を残してきたからです。 低レイテンシシステムの分野では、Duke Awardを受賞したオープンソースプロジェクト「LMAX Disruptor」に貢献しています。並行処理や高スループットの設計を語る場面で、いまも参照され続ける仕事の一つです。 さらに、応答性や回復性、弾力性を重視する「リアクティブシステム」の考え方を示した Reactive Manifesto の共同執筆者でもあります。 近年はYouTubeチャンネル「 Modern Software Engineering 」（旧名Continuous Delivery）の主宰者として、世界中のエンジニアに継続的デリバリーやモダン・ソフトウェアエンジニアリングの考え方を発信し続けてきました。チャンネル登録者数は26万人を超えています。 www.youtube.com 英語圏のエンジニアにとっては、継続的デリバリーの代表的な書籍を世に出した人でありながら、いまもYouTubeを通じて最新のソフトウェアエンジニアリングを語り続ける存在です。 www.youtube.com Farley氏は近年、DORA（DevOps Research and Assessment）の年次レポートにも参加しています。2022年は10人の著者の一人として、2023年は「継続的デリバリーの効用（Benefits of continuous delivery）」の章の執筆者および分野アドバイザーとして、2024年は分野の専門家として報告書に名を連ねています。 『Continuous Delivery』(2010) は何を変えたか Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble , David Farley Addison-Wesley Professional Amazon 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 作者: Jez Humble , David Farley KADOKAWA Amazon Jez Humble氏とFarley氏が2010年に出版した『Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation』は、何を変えたのでしょうか。 2010年当時、リリースは重く、失敗が許されないイベントとして扱われていました。本番投入の前には長い調整期間があり、変更はできるだけまとめて出すのが当たり前でした。 『Continuous Delivery』は、この前提を見直す考え方を示しました。 ここでいう「Delivery」は、ソフトウェアをいつでもリリースできる状態に保ち続けることを指します。デプロイ作業そのものや、ユーザー公開としてのリリースとは別の概念です。 主張の柱は、次の3つです。 デプロイメントパイプラインという概念の提唱 「ソフトウェアを常にリリース可能な状態に保つ」という考え方 自動化の範囲を「統合（CI）」から「デプロイメント」まで広げたこと これらは自動化の対象範囲を広げるとともに、ソフトウェア開発の文化にも影響を与えました。変更をまとめて重く出す形から、頻繁に小さく出して安定性を高める形へと、考え方が変わりました。 リリースは一大イベントではなくなり、デイリーないし時間単位の活動になりました。 こうした変化のなかで、「デプロイ」と「リリース」を分けて考える発想が広がりました。次章ではこの分離について詳しく見ていきます。 二つの意味を持つ「リリース」 「リリース」という言葉がややこしいのは、継続的デリバリーに取り組んでいるかどうかで、指しているものが変わるからです。 旧来のリリース管理では、「リリース」は本番投入に向けた承認・計画・調整を含む、大きなマネジメント上の区切りでした。リリース判定会議を経て、デプロイし、ユーザーに公開する。これら全体をまとめて「リリース」と呼んでいたのです。 flowchart LR A["リリース判定会議"] -- "判定OK" --> B subgraph Release["リリース"] direction LR B["デプロイ<br/>（手動）"] --> C["ユーザー公開"] end 一方、継続的デリバリーでは、このまとまりを分解します。デプロイは自動化された反映作業として高頻度に行い、ユーザー公開としてのリリースとは切り分けて考えます。 この文脈での「リリース」は、ユーザーが新機能を実際に使えるようになる瞬間です。つまり、先にデプロイしておき、後で公開判断によってリリースする、という順序になります。 flowchart LR A["デプロイ<br/>（自動）"] --> B["本番環境<br/>（まだ非公開）"] B -- "公開判断" --> C["リリース<br/>（ユーザー公開）"] だから、「リリース → デプロイ」も「デプロイ → リリース」も、現場ではどちらも正しい言い方になりえます。問題は順序そのものではなく、それぞれの「リリース」が別の意味を指していることです。 この違いは、コンビニにたとえると分かりやすくなります。 デプロイ = 商品をバックヤードに搬入する作業 リリース = その商品を陳列棚に並べて、顧客が買えるようにする判断 flowchart LR Code["新商品<br/>（コード）"] --> Deploy(("デプロイ<br/>（機械的・高頻度）")) Deploy --> Backyard["バックヤード<br/>（本番環境）"] Backyard --> Release(("リリース<br/>（ビジネス判断）<br/>※Feature Flag")) Release --> Shelf["陳列棚<br/>（ユーザーに公開）"] Shelf --> Buy(("商品を選んで<br/>購入")) Buy --> Customer["顧客<br/>（ユーザー）"] バックヤードに搬入すること（デプロイ）と、陳列棚に並べる判断（リリース）は、本来別々のものです。Jez Humble氏とFarley氏は『Continuous Delivery』で、この二つを意図的に分離する発想を提示しました。 デプロイは機械的な反映作業として、できる限り自動化し、高頻度に行う リリースはビジネス判断として、機能の公開タイミングをコントロールする この分離を支える代表的な仕組みが、フィーチャーフラグ（Feature Flag）、カナリアリリース、ブルーグリーンデプロイメントです。たとえばフィーチャーフラグを使えば、コードは本番環境に置いたまま、機能の有効／無効や公開対象を切り替えられます。 ただし、これらの仕組みにも限界はあります。データベースのスキーマ変更や外部サービスへの副作用を伴う処理では、設計や運用ルールも含めた備えが必要です。 具体的な運用例は、Findy Tech Blogの過去記事でも紹介しています。 tech.findy.co.jp AI時代に、継続的デリバリーはなぜ重要になるのか ここまで見てきたように、継続的デリバリーは単なる自動化の話ではありません。 変更を小さく保ち、素早くフィードバックを得て、いつでも安全にリリースできる状態を維持するための規律です。 Farley氏は『Modern Software Engineering』（2021）でも、開発そのものをエンジニアリングとして捉え直し、素早く学ぶことと複雑さを制御することの重要性を説いています。 Modern Software Engineering: Doing What Works to Build Better Software Faster (English Edition) 作者: Farley, David Addison-Wesley Professional Amazon 継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣 作者: David Farley 日経BP Amazon 変更を小さく保ち、素早く学び、複雑さを制御する姿勢は、AI時代にこそ重要になります。なぜなら、生成AIは変更を生み出す速度を上げる一方で、その変更が安全で価値あるものかどうかまでは保証しないからです。 生成AIは、速さの面でも品質の面でも、DORA Metricsの数値を動かします。その意味で、DORA Metricsは今も計測の出発点です。 一方で、動いた数値をこれまでと同じように読み解き、開発の良し悪しを判断することは難しくなりました。 DORA Metricsだけでは、「速く届いた先で、ユーザーにどんな価値が生まれたのか」までは見えないからです。 2025年のDORAレポートはAIを「増幅器（amplifier）」と呼び、その効果を引き出す組織側の条件を「AI Capabilities Model」として整理しています。 %%{init: {'flowchart': {'curve': 'linear'}}}%% flowchart LR AI("AIの導入") MUL("×") subgraph CAP["7つのケイパビリティ"] direction TB C1("ユーザー<br/>中心の視点") C2("優れたバージョン管理<br/>プラクティス") C3("AIでアクセス可能な<br/>内部データ") C4("小さいバッチ<br/>単位の作業") C5("明確で周知された<br/>AIのスタンス") C6("質の高い内部<br/>プラットフォーム") C7("健全なデータ<br/>エコシステム") end subgraph OUT["アウトカム"] direction TB O1("チーム<br/>パフォーマンス") O2("コードの品質") O3("個人の有効性") O4("プロダクト<br/>パフォーマンス") O5("摩擦の低減") O6("スループット") O7("組織<br/>パフォーマンス") end AI ~~~ MUL MUL ~~~ C4 C1 --> O1 C2 --> O1 C2 --> O3 C3 --> O2 C3 --> O3 C3 --> O4 C4 --> O3 C4 --> O4 C4 --> O5 C5 --> O3 C5 --> O4 C5 --> O5 C5 --> O6 C5 --> O7 C6 --> O5 C6 --> O7 C7 --> O7 DORAの「AI Capabilities Model」をもとに作成 冒頭のピザのデリバリー話に戻しましょう。 「速く届いた」ことと、「価値あるものが届いた」というアウトカムは、必ずしも一致しません。 DORA Metricsはあくまで「届けるまでの速さと安定性」を示すものです。ピザでいえば、配達時間だけでなく、配送中に崩れずに届いたか、問題が起きたときに素早く立て直せるかまで含めた指標に近いでしょう。大事な指標ですが、それだけでは「届いたあと、ユーザーや事業にとって何が起きたか」までは見えません。 DORAは2025年のレポートで、まさにこの「ユーザー側に何が届いたか」を主役に据えました。 AI Capabilities Modelの7つのケイパビリティ（上の図）のひとつに「ユーザー中心の視点（User-centric focus）」を掲げ、AIを「正しい方向」に効かせるための北極星（North Star）と位置づけています。 チームがアウトプット（出荷した機能の数や速度）を追うばかりで、ユーザーに届いたアウトカムを見失うと、AIは「フィーチャーファクトリー（機能量産工場）」を加速させます。 活動量は多くてもインパクトの出ない状態に陥る、とレポートは警告しています。 DORAの調査では、ユーザー中心の視点が欠けたチームではAIを導入するとチームパフォーマンスにマイナスの影響さえ及ぼす、と報告されています。一方、ユーザー中心の視点を持つチームでは、AIがプラスの影響を大きく増幅すると報告されています。 生成AIでデリバリーがさらに速くなる時代だからこそ、速さの先にあるユーザー側のアウトカムを見失わないことが、これまで以上に重要です。 AI駆動開発を空回りさせないために 「デプロイ」と「リリース」の混同は、用語の取り違えにとどまりません。AI駆動開発を進める組織にとっては、そのままリスクの増幅につながります。 日本のソフトウェア開発現場でも、「リリース＝大イベント」「デプロイ＝リリース当日にやる作業」という理解が、いまだに根強く残っています。 『Continuous Delivery』の日本語訳は2012年に出版されました。 それから14年が経ったいまも、継続的デリバリーの重要な概念的貢献である「デプロイとリリースの分離」は、少なくとも日本の多くの現場で十分に共有されているとは言えません。 継続的デリバリーを実践している組織では当たり前に使われる "Deployment ≠ Release" という整理が、日本の現場ではいまも「同じこと」として語られがちです。 Farley氏は2021年の『Modern Software Engineering』で、誤った考えが根強く残る理由をこう書いています。 間違った考え方をなかなか捨てられない理由のひとつは、ソフトウェア開発のパフォーマンス（能力、業績）を効果的に計測できていないことにあります。 Farley, D.(2022), 長尾高弘 (訳). 継続的デリバリーのソフトウェア工学: もっと早く、もっと良いソフトウェアを作るための秘訣 (Nagao, T., Trans.). 日経BP社. (Original work published 2021) p.70 デプロイとリリースを分離できれば、デプロイの頻度を上げながら、機能の公開タイミングは別途コントロールできます。 逆に、分離できなければ、リリース＝デプロイ＝大イベントの連鎖から抜け出せません。 いまも日本の多くの現場は、「動いているコードには触れるな」という考え方の延長線上にあります。 Farley氏は同書で、こうも指摘しています。 私の印象では、ソフトウェア産業は学ぶことも進化することもなかなかできないで苦闘しているように見えます。この相対的な停滞は、コードを実行するハードウェアのとてつもない進化によって見えなくされているのです。 Farley, D.(2022), 長尾高弘 (訳). 継続的デリバリーのソフトウェア工学: もっと早く、もっと良いソフトウェアを作るための秘訣 (Nagao, T., Trans.). 日経BP社. (Original work published 2021) p.69 2021年のこの指摘は、いまの生成AIにもそのまま当てはまります。生成AIは、変更を大量に、しかも高速に生み出します。 だからこそ、問われているのは「AIでどれだけ速く作れるか」だけではなく、作られた変更を、小さく、安全に、継続的に届けられるか、つまり「開発資本」を組織として持てているかです。 デプロイとリリースを切り分ける土台がなければ、AIは変更の速度だけでなく、リスクも増幅します。DORA Metricsの数値が動いても、それだけではAIが良い方向に働いているかは判断できません。 技術的発展の階層構造。これらの土台作りが重要。 ここでいう「継続的デリバリーができない」は、単にデプロイ自動化がないことではなく、変更を小さく保ち、デプロイとリリースを切り分け、ユーザーへの影響を制御しながら継続的に届ける仕組みがない状態を指します。 「デプロイ」と「リリース」の混同に、「フィーチャーファクトリー」の罠が重なれば、AI駆動開発はいくら進めても成果に届きません。継続的デリバリーができない組織で、AIは増幅器(amplifier)として空回りを生むのです。 まずは、自チームで「デプロイ」と「リリース」をいまどう区別しているのかを言語化してみてください。境界がぼやけているなら、それ自体が改善の第一歩になります。 【告知】AI DevEx Conference 2026 - Future of Development Productivity - 継続的デリバリーとAI時代のソフトウェア開発について、Farley氏本人の言葉で聞ける機会があります。 AI DevEx Conference 2026で、Farley氏が初めて日本に登壇します。 開催概要は以下のとおりです。 項目 内容 開催日時 2026年7月22日（水）・23日（木）9:30〜18:40 開催形式 オフライン・オンライン配信（要事前登録） チケット 現地参加チケット（アーリーバード第2弾） ¥3,000（税抜）※締切日：5月27日（水） 現地参加チケット ¥5,000（税抜） オンライン（無料） 開催場所 JPタワーホール＆カンファレンス（東京・丸の内） 申込URL https://dev-productivity-con.findy-code.io/aidevex2026 主催 ファインディ株式会社 対象者 DevExやソフトウェア開発の改善に関心があるエンジニアやマネージャー、経営者など Farley氏は、初日の7月22日に次のテーマで登壇します。 「AIと共存する世界のソフトウェアエンジニアリング ─不変の本質とプログラミングの未来」 AIと共存する時代に、より良いソフトウェアをより速く作るためには何が必要なのか。この記事で扱ってきた継続的デリバリーやエンジニアリングの話とも、まっすぐつながるテーマです。 このほか、t_wadaさんこと和田卓人氏や、「DevEx」の第一人者であるEirini Kalliamvakou氏も登壇予定です。DeNA、Uber、Citibank、LinkedInなど、国内外50社以上が登壇します。 ぜひご参加ください！ おわりに ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

こんにちは！ファインディの大石（ @bicstone ）、甲斐（ @karukan013L23 ）、千田（ @_c0909 ）です。先日、ファインディはベルサール羽田空港で開催された「TSKaigi 2026」に協賛しました。 今回はDevRelメンバーとフロントエンドエンジニア3名で参加し、ブース運営を行いました。本記事ではTSKaigi 2026において印象深かったセッションの紹介や登壇、ブース出展などの活動内容を紹介します。 ブースで実施したユーティリティ型アンケートの集計結果（480票）も後半で公開していますので、ぜひ最後までお読みください。 TSKaigi 2026について 印象深かったセッション 【大石】TS 7: How We Got There 【甲斐】tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか 【千田】Oxlint は ESLint / typescript-eslint を置き換えられるか？ 【大石】CfP登壇: TypeScript 6.0での型推論修正を追う ファインディの活動 アンケート結果 さいごに お知らせ TSKaigi 2026について TSKaigiは日本最大級のTypeScriptをテーマとした技術カンファレンスです。東京都大田区のベルサール羽田空港にて、2026年5月22日(金)〜23日(土)に開催されました。 2026.tskaigi.org 印象深かったセッション 興味深いセッションが多くありましたが、その中でも3名それぞれが印象に残ったセッションを紹介します。 【大石】TS 7: How We Got There 2026.tskaigi.org TypeScriptチームのJake Baileyさんによる、TypeScript 7をGo言語へ移植した経緯と成果についての基調講演です。 特に印象的だったのは、Goを採用した理由を体系的に知ることができた点です。 JavaScriptではスレッド間でオブジェクトを共有できず、async/awaitが関数全体に伝播してしまうため、並列化が困難でした。 Goのgoroutineを活かすことで、Parse・Bind・Emitの各フェーズを並列化し、Checkerも複数並べることで高速化を実現しています。 VS Code (Electron) のプロジェクトを tsc と tsgo それぞれで実行した際の所要時間とCPU使用率の差を見せていただいたデモでは、マルチスレッドの活用やCPU使用率の変化が一目で分かり、なぜ大幅な高速化を実現できたのか直感的に理解できました。 発表のなかで繰り返し強く呼びかけられていたのが、コミュニティからのフィードバックでした。「ぜひbetaやnightlyを試してほしい」「VS CodeのNative Preview拡張を入れてほしい」「クラッシュやコンパイル挙動の変化、特にAPIへの意見を送ってほしい」と呼びかけていました。 過去1年でコミュニティから1141件のIssueと1487件のマージ済みPRが寄せられ、テレメトリ経由のクラッシュ情報も含め、利用者からの報告が開発の方向性を支えていることが伝わってきました。 私たちのチームでは、すでにコミット時のフックで tsgo を試験的に採用しています。今後は開発フロー全体への導入を進めながら、検知した問題は積極的にフィードバックを送っていきたいです。 ファインディでも従来からOSSへのIssue起票やPull Requestの作成、メディア企画を通じた寄付などの形で支援を続けてきましたが、TypeScriptのように多くの利用者を抱えるプロジェクトでは、利用者一人ひとりの報告こそが大きな貢献になることを再認識しました。 これまで断片的にしか追えていなかったTypeScript 7について体系的に理解でき、とても学びの多い発表でした。社内にもぜひ共有していきたいと思います。 【甲斐】tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか 2026.tskaigi.org Denoのmaguroさんによる、DenoのTypeScript基盤を tsc から tsgo へ移行する取り組みについてのセッションです。 元々DenoはTypeScriptをフォークしたパッケージを使用し、Deno Rust側と必要な情報をやり取りし、Deno固有の概念を tsc が解釈できるよう、 tsc にパッチを当てたものをDeno binaryの中に埋め込んでいました。 tsgo への移行の最初のアプローチは tsgo をフォークし、Deno固有の概念を tsgo に渡せるようにするアプローチでした。 tsgo はDeno固有の概念をそのまま解決できないため、Deno Rust側で処理できるよう対応しています。LSP対応のコスト、フォークしたパッケージのメンテナンスコストが高く、現在はフォーク版ではなく公式のTypeScriptパッケージを利用するアプローチが試みられています。 TypeScript向けにDenoの依存と型をローカル生成することで、パッチを当てずにDeno固有の概念を解釈できる構成にしています。 特に印象的だったのは、DenoのWeb標準の哲学を少し曲げてでもTypeScriptで扱える形に寄せていった点です。Deno binaryの中→Deno binaryの外→Deno projectの外へTypeScriptパッケージが押し出されており、フォークによる運用コストの増加を避けつつ実行可能なアプローチをとっています。 型チェックを使用したい他のライブラリも同様にフォーク以外の選択肢を模索しており、方向性は同じだがそれぞれ異なるアプローチになっていることが興味深かったです。 普段Denoは使用していませんでしたが、現在の形に辿り着くまでにどのような意思決定があったかを見ていくことで、ここに至るまでの課題や意思決定ごとのトレードオフを学ぶことができ、現在の思想を理解する助けとなりました。 今後もツールチェーンやライブラリの意思決定の背景を学ぶ機会を定期的に設けていきたいなと思います。 【千田】Oxlint は ESLint / typescript-eslint を置き換えられるか？ 2026.tskaigi.org 株式会社うるるの藤田翔雅さんによる、OxlintがESLint / typescript-eslintをどこまで置き換えられるのかを整理したセッションです。 特に印象的だったのは、Type-Aware Linting（型情報を使ったLint）の有無でパフォーマンスが大きく変わる点をベンチマークで示していたことです。 型情報を使わない比較ではESLintの8.213秒に対しOxlintは0.304秒と約27倍速く、型情報を使うルールを有効にしてもESLintの16.121秒に対しOxlintは0.807秒と約20倍速いという結果でした。 型情報を使わないLintが構文解析だけで完結するのに対し、型情報を使うLintはプロジェクト全体の型グラフ構築（ tsc / tsgo ）を必要とするためボトルネックになる、という構造的な解説も理解の助けになりました。 導入判断についても踏み込んでおり、型情報を使わないLintであればOxlintは主要ルールを十分カバーしており移行は現実的である一方、 oxlint-tsgolint によるType-Aware Lintingはまだ非安定版であること、カスタムルールを抱えるプロジェクトでは移行コストが上がることなど、現場目線のトレードオフが具体的に語られていました。 結論として、非Type-Aware LintingであればOxlintへの移行を推奨するというメッセージが明快でした。 私たちのチームでもESLint + Prettierを利用しており、CIの実行時間は継続的な課題です。すでにOxc系（Oxlint + Oxfmt）への移行を計画しており、既存のプロダクトはType-Aware Lintingに依存しない構成となっています。 本セッションの「非Type-Aware LintingならOxlint移行を推奨」という結論は私たちの状況に当てはまり、実際の移行計画に重ねて考える良い機会になりました。 【大石】CfP登壇: TypeScript 6.0での型推論修正を追う 当日のCfP枠では、大石が「プロパティの順序で型推論が壊れる!? TypeScript 6.0の修正からContext-Sensitivityの仕組みを追う」というタイトルで登壇しました。 プロパティの記述順序を入れ替えるだけで型推論が壊れる挙動を入口に、TypeScript 6.0でマージされたPRの中身まで踏み込んだ内容です。詳細は別記事にまとめていますので、あわせてご覧ください。 tech.findy.co.jp speakerdeck.com ファインディの活動 ファインディはGoldスポンサーとして協賛し、ブース出展という形で支援しました。 ブースでは「よく使うユーティリティ型」をテーマにしたアンケート企画を実施しました。普段の開発でよく使うユーティリティ型を選んでいただく内容で、2日間かけて多くの方に投票いただきました。 TSKaigi2026始まりました！入口すぐです！ お待ちしております🌟 #TSkaigi2026 #tskaigi pic.twitter.com/ecf1Zzok0V — いわさき@Findy DevRel (@iwasakitchen) 2026年5月22日 x.com アンケートの最終結果はこちらになります。たくさんの投票ありがとうございました。 TSKaigi 2026改めて2日間ご参加いただき、ありがとうございました！よく使うユーティリティの「型」は？の最終結果です！😊🎊 #TSkaigi #TSkaigi2026 pic.twitter.com/0Nt4xun2bQ — いわさき@Findy DevRel (@iwasakitchen) 2026年5月23日 x.com アンケート結果 総数：480票 順位 ユーティリティ型 割合 票数 1位 Record<Keys, Type> 33.3% 160票 2位 Pick<T, Keys> 17.7% 85票 3位 Readonly<T> 14.6% 70票 4位 Partial<T> 9.4% 45票 5位 ReturnType<T> 8.8% 42票 6位 Exclude<T, U> 4.2% 20票 7位 Extract<T, U> 2.5% 12票 8位 NonNullable<T> 2.5% 12票 9位 Awaited<T> 1.0% 5票 - その他 6.0% 29票 その他内訳 ユーティリティ型 票数 その他・使っていない 22票 Omit<T, Keys> 5票 Beautify<T> 1票 & 、 | 1票 加えて、マーケティング担当のメンバーがAIを活用して自ら開発したルーレットアプリと、ファインディオリジナルのノベルティをご用意し、立ち寄っていただいた方に楽しんでいただきました。 さいごに セッションは多岐にわたるなかで、私たちが特に注目したのはGoによるコンパイラの再実装（コンパイラ本体のネイティブ化）、tscからtsgoへの基盤刷新（他ランタイムによる採用）、Rust製Linterの可能性（周辺ツールへの波及）でした。 3つを通して、TypeScriptエコシステムがNative実装へと動いている流れを実感する2日間となりました。TSKaigiはとても温かい素敵なコミュニティで、いち参加者としても多くの学びと交流の機会を得ることができました。 カンファレンスの開催にあたりご尽力いただいた、運営スタッフの皆様、関係者の皆様、登壇者の皆様に感謝申し上げます。 お知らせ 同日参加したファインディのDevRelメンバーによるレポート記事も公開されています。あわせてご覧ください。 note.com TSKaigi 2026のアフターイベント「TSKaigi Night talks 〜after conference〜」をスポンサー企業9社で共催します。当日のCfP枠で採択されなかった知見もコミュニティへ還元することを目的としたイベントです。 ファインディからは千田が「OSSのUIライブラリでESLintのカスタムルールを作っている話」、甲斐が「Temporal - TypeScript 6.0で始める新しい日時API」というテーマで登壇予定です。 2026年6月10日(水)19:00から、ファインディのイベントスペースにて開催します。TSKaigi 2026に参加された方も、参加できなかった方も、ぜひお越しください。 findy.connpass.com ファインディでは一緒に働くメンバーを募集しています！ 興味がある方はこちらから ↓ herp.careers

はじめに こんにちは、ファインディ株式会社でエンジニアをしている中嶋（ @nakayama__bird ）です。現在は、新規プロダクトであるFindy Contextの開発に携わっています。 ファインディでは、これまでSREチームが担っていた新規プロダクトのクラウド環境の構築から監視体制の整備までを、プロダクト開発チーム主体で行う体制に切り替えました。 本記事では、私自身がFindy Contextの環境立ち上げを担当した経験を、アプリケーションエンジニアの視点で振り返ります。 経験の浅いエンジニアにとって、0→1のクラウド環境構築は不安の大きい領域です。「自分にできるのか」と思いながら着手した私が前に進めたのは、「SREチームが整えてくれた仕組み」と「自分で進めた学習」、その2つが揃っていたからでした。 それぞれがどう機能したかを、これから体験ベースでお伝えします。 はじめに Findy Contextとは 背景: なぜ開発チーム主体に切り替わったのか これまでの体制 直近の事情の変化 方針転換: 開発チームメインの立ち上げへ 着手前の筆者スペック 委譲のスコープと私が担当した範囲 AWSアカウント発行とインフラ構築基盤整備 インフラリソースの構築 デプロイと運用の整備 監視（Datadog）の整備 個人として取り組んだこと 今後の伸び代 自分側 仕組み側（汎用モジュール・テンプレートへの改善余地） まとめ Findy Contextとは Findy Contextは、ファインディが2026年4月にリリースしたAI駆動開発支援プロダクトです。 プロダクト開発で日々生まれる文脈（過去のPR、関連議論、意思決定の経緯）をAIが資産化し、開発の調整コストを削減することを目指しています。 Findy Contextが目指すのは、特定の個人に依存せず、少人数でも高い開発能力を維持できる組織運営です。 あちこちに散らばっていた判断のプロセスを蓄積していくことで、組織の経験を資産として再活用できる土台を作っていきます。 findy.co.jp このFindy Contextの本番運用基盤を、なぜSREチームではなく開発チームが主体で構築することになったのか。その背景から振り返ります。 背景: なぜ開発チーム主体に切り替わったのか これまでの体制 ファインディにはSREチームが存在し、共通インフラやプラットフォームの運用、汎用モジュール・テンプレートの整備、セキュリティ・コスト最適化など、全社横断の取り組みを担っています。 インフラはTerraformでコード管理されており、SREチームが提供する汎用モジュールやテンプレートもTerraformで書かれています。オブザーバビリティの基盤としてはDatadogを採用しています。 また、既存プロダクトでは、プロダクトの一部メンバーがEmbedded SREとして、次のような役割を担っています。 アプリケーション開発に必要なインフラの整備・管理 モニタリングの整備 SLOの振り返り 一方、新規プロダクトの立ち上げに関しては運用が異なっていました。 SREチームが環境を構築し、ある程度の運用準備を整えてからプロダクト開発チームに引き渡す形が基本でした。 直近の事情の変化 ここ1〜2年で、事業成長や生成AIの追い風もあり新規プロダクトの立ち上げ件数が大きく増えたことで、これまでの体制で支えられる範囲を超えつつありました。 一方で、SREチームの人員を急に増やすことは難しく、既存プロダクトの運用や全社横断の取り組みも並行して走り続けています。新規プロダクトすべての環境構築をSREチームが担う体制は、現実的に維持できなくなりつつありました。 方針転換: 開発チームメインの立ち上げへ そこで、新規プロダクトの立ち上げ〜運用フェーズを、 プロダクト開発チームが主体となり、SREチームがイネーブリングを担う 体制へと切り替わりました。 これは、「開発側にオーナーシップを置く」というEmbedded SREの発想を、新規プロダクトの立ち上げフェーズにも広げた形と言えます。 SREチームが整備した汎用モジュール・テンプレート・イネーブリング体制を活用して、開発チームが自分たちの責任で立ち上げる。Findy Contextの立ち上げは、この新方針の第一弾として位置付けられたプロジェクトでした。 着手前の筆者スペック 未経験からファインディに入社し、当時は経験1年のエンジニアでした。業務の中でAWSの一部サービスを使うことはあっても、新規プロダクトの基盤として複数のサービスを組み合わせて構築した経験はありませんでした。0→1のクラウド環境構築は今回が初めてです。 そんな中、Findy ContextのEmbedded SREとして配置されることになりました。 開発チーム主体で環境構築を進める新方針のもと、その構築をメインの担当者として進めてほしいと依頼されました。 着手当初はそもそも「何から手をつければいいのか」が分からない状態でした。設計の手順も、優先順位も、判断基準が自分の中にありませんでした。 委譲のスコープと私が担当した範囲 まず、SREチームと開発チームの担当範囲を整理しておきます。 領域 SREチームが担当 開発チームが担当 AWSアカウント Organizations管理 アカウントの発行、発行後の初期設定 インフラリソース（ネットワーク・アプリケーション基盤） 共通方針、汎用モジュール・TerraformのCI/CDテンプレートの整備 汎用モジュールを使ったリソース構築（足りないものは個別作成）、CI/CD設定 監視（Datadog） Datadogの管理 ダッシュボード・モニター作成、運用 開発チームが引き受けた範囲は、SREチームが整備してくれた仕組みを使って自分たちで構築する、という形でした。 今回のFindy Contextの環境構築は、約2ヶ月をかけて、主にSREチームが事前に分解してくれた作業を順に消化する流れで進めました。ここからは、その流れを4つのフェーズに分けて振り返ります。 AWSアカウント発行とインフラ構築基盤整備 最初のフェーズは、Findy Context用のAWSアカウントを作り、Terraformで管理する基盤を整える作業でした。次のようなタスクです。 新規AWSアカウントの作成 HCP TerraformへのProject作成 Terraform用のGitHub Actionsワークフロー作成 ファインディには、SREチームが整備した初期セットアップ用のテンプレートがあり、Terraform用リポジトリの初期化はこのテンプレートで一気に進められました。 CI/CD・Docker・Trivy・TFLintなど、新規プロダクトに必要な基盤が一式揃った状態でスタートできます。 それでも詰まったのは、 GitHub ActionsからAWSへのOIDC認証の設定 でした。 Identity ProviderやIAM Roleの信頼ポリシーといった、IAM周りのポリシー理解が必要になります。IAMポリシーの仕組みをこれまで触る機会がなく、何をどう書けば期待通りの認証が通るのかが最初は全く分かりませんでした。 乗り越え方は、既存プロダクトのTerraformリポジトリを参考に、動いている設定を「型」として読み解くことでした。 特に初期は、SREチームの方と毎日ペアで作業する時間を持ち、レクチャーを受けたり質問を重ねたりしながら、自分の中に手順のイメージを作っていきました。 インフラリソースの構築 ここからが、Findy Contextのインフラを実際に組み立てるフェーズです。約1ヶ月かけて、次のようなリソースを順に構築していきました。 ドメイン / DNS Zone / 証明書（ACM） ネットワーク（VPC・サブネット等） コンテナ関連（ECSなど） データベース関連（RDSなど） 認証（Cognito） 配信（CloudFront） ここで強く助けられたのが、SREチームが整備した 汎用モジュール です。汎用モジュールの整備については、別の記事で詳しく紹介されています。 tech.findy.co.jp ネットワーク・コンテナ・データベースなど、アプリケーション開発で標準的に必要なリソースは汎用モジュールが用意されており、変数を指定するだけで適切な構成が組み上がります。 「ベストプラクティスを毎回ゼロから調べる」必要がない状態でスタートできることは、学習コストを大きく下げる効果がありました。 それでも詰まったポイントが2つありました。 1つ目は、 汎用モジュールにないリソースの作り込みやレビュー です。Findy Contextでは、まだ汎用モジュール化されていないリソースを複数扱う必要がありました。 作成だけでなくレビューも、構成のイメージが頭の中にないと判断が難しく苦労した部分でした。AWS公式ドキュメントに加え、Claudeを活用して疑問に思った箇所を一つずつ理解していくアプローチで進めました。 2つ目は、 リポジトリ構成とリモートステートの設計 です。新規のリソースを作成する際、AWSのサービスごとに細かくstateを分割しようとしていたところ、SREチームから「リモートステートを多用しすぎない設計」をお勧めされました。 stateを分けるほど依存関係が複雑化し、apply順や terraform_remote_state の管理コストが増えるためです。アプリケーションエンジニア側のみで進めていたら気付けなかった視点で、SREチームのレビューを受けながら進められた価値を強く感じました。 デプロイと運用の整備 インフラリソースが揃ったら、次はアプリケーションをデプロイし、運用できる状態にするフェーズです。デプロイ用ワークフローの作成、Operationコンテナ環境の整備、Cognitoとアプリケーションの繋ぎこみなどを進めました。 ここで助けになったのは、既存の他プロダクトでしっかり整備されていたCI/CDフローでした。 tech.findy.co.jp デプロイの流れもOperationコンテナの構成も、基本的に「ゼロから設計する」のではなく「動いているフローを参考にする」アプローチで進められたのです。 SREチームと既存プロダクトを担当するエンジニアの両方に相談しながら、Findy Contextの構成に合わせた設計を組み立てていきました。 監視（Datadog）の整備 環境構築のクローズ後、別途取り組んだのが監視体制の整備です。Datadogでのダッシュボード作成、モニター（アラート）設定、ログ・メトリクスの収集設計、エラー検知の整備などを進めました。 SREチームが整備したDatadog基盤のおかげで、「Datadog自体をどう使うか」は迷わずに進められました。 このフェーズで一番大きな気付きは、 監視や可視化はインフラ側だけでは完結しない ということです。 例えばログ・エラー検知の領域です。エラーを正しく追跡できるようにするには、アプリケーション側で例外ハンドリングの設定を見直す、ログの出し方を整える、といった作業が必要でした。 「Datadogでエラーが見えない」という現象の根本原因が、Datadogの設定ではなくアプリケーションコード側にあるケースがありました。 詰まったポイントは2つです。 1つ目は、 アラートの閾値とチューニング です。「何を、どの値を超えたらアラートを出すべきか」は、各サービスや時期に応じて判断が必要で、最初は誤検知が頻発したり、逆に本来検知すべき異常を見逃したりしながら調整を重ねました。 2つ目は、 ダッシュボード設計とアプリ側のログ整備 です。「何を載せるか、載せないか」「どんなログをどう出せば後で追跡できるか」は、メトリクスやログの選定だけでなく、アプリケーションの実装と表裏一体でした。 SREチームや既存プロダクトを参考にしつつ、Findy Contextのコードにも並行して手を入れていきました。 監視整備は、「インフラだけ知っていればよい」という認識を一番大きく崩した経験でもありました。 可視化の基盤として、アプリケーション側の知識が必要 だと、身をもって学んだフェーズです。 個人として取り組んだこと ここまで「仕組みが整っていた」という話を中心にしてきましたが、それだけで踏み出せたかというと、そうではありません。仕組みを活かすには、自分側でも一定の準備が必要でした。 私が並行して取り組んだのは、 AWS認定ソリューションアーキテクト アソシエイト（SAA）の取得 でした。 試験勉強の中ではAWS公式の「AWS Hands-on for Beginners」も活用し、書籍だけでは身につきにくい「実際にコンソールを触ってリソースを作る」感覚も合わせて身につけました。 SAAを通して、実際の業務で使うサービスだけでなく、AWSの主要サービスとアーキテクチャパターンを体系的に学べたことで、知識の幅が広がりました。 例えばコスト最適化のように、業務で直接深掘りしていない領域でも、「ここはもう一歩改善できそう」という気付きを得られる引き出しが増えた感覚があります。 「環境が整っていれば誰でも自走できる」わけではなく、整った環境を活かすための準備として、自分の側に基礎知識のストックを作ることが、踏み出す上で大きな支えになりました。 今後の伸び代 今回の構築で見えてきた、自分側と仕組み側の伸びしろを書いておきます。 自分側 複数リポジトリにまたがるサービスならではのオブザーバビリティ設計です。 Findy Contextは複数リポジトリで構成されており、1リクエストが複数サービスを跨ぐ場合の追跡や、ログ・メトリクスの相関付けには、まだ改善の余地があります。 Datadog APMなどを活用しながら、どう設計していくかは今後の課題です。 仕組み側（汎用モジュール・テンプレートへの改善余地） ここまで書いてきたとおり、SREチームが整備してくれた汎用モジュールやテンプレートには、非常に大きな価値を感じています。その上で、実際に使ってみて感じた「もう一歩テンプレート化されると嬉しい」領域も挙げておきます。 初期セットアップ（AWSアカウントの発行 → OIDC認証 → Terraform / GitHub Actionsの初期構成）の部分は、想像以上に時間がかかった領域でした。 中核のリソース構築は汎用モジュールのおかげで早く進められた一方で、初期のアカウント・認証まわりは、まだ個別対応の比率が高めだと感じました。 ここがもう一段テンプレート化されると、次に立ち上げる新規プロダクトの初動はさらにスムーズになりそうです。 まとめ Findy Contextのクラウド環境立ち上げを通して、最も強く感じたのは、 「仕組み」と「個人の学習」の両方が揃って初めて、経験1年のエンジニアでも0→1に踏み出せる ということでした。 仕組み側（SREチーム）が整備してくれた汎用モジュール、テンプレート、既存プロダクトの参考実装、相談しやすいサポート体制など、これらがなければ「何から手をつけるか」の段階で長く立ち止まっていたはずです。 一方で、SAAを通した体系的な学習や、ハンズオンでの実機感覚がなければ、整った環境を活かしきれなかったとも感じます。 仕組み側の整備は、開発者の「やってもらう」マインドを「自分たちでやる」オーナーシップへと自然に切り替えてくれる装置でもあります。 SREの開発チームへの委譲は、人手不足への対応策にとどまらず、開発組織全体のスキルと当事者意識を底上げする取り組みになりうると感じました。 自社で似た取り組みを検討している方や、キャリアの早い段階で挑戦を考えているエンジニアの方の参考になれば嬉しいです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディでフロントエンドエンジニアをしている大石（ @bicstone ）です。 2026年5月22日〜23日に開催される TSKaigi 2026 で、 「プロパティの順序で型推論が壊れる!? TS6.0の修正からContext-Sensitivityの仕組みを追う」 というタイトルで登壇します。本記事は10分のトーク内では時間の都合で端折った内容も含めた拡張版としてお届けします。 2026.tskaigi.org TypeScriptでオブジェクトリテラルにメソッドを書いたとき、プロパティの記述順序を入れ替えただけで型推論の結果が変わるとしたら、どう感じるでしょうか。「そんな不思議な挙動があるのか」「気になるけどTypeScript内部のソースコードは難しそうで自分には縁がない」と思った方もいるかもしれません。 この記事では、この不思議な挙動を入り口にしてTypeScriptコンパイラの中で何が起きているのかを1つのPRから追いながら解説します。 背景: プロパティの順序で型が変わる アロー関数なら問題ないのはなぜか Context-Sensitive Functionの考え方 推論の全体像 メソッド構文に隠れている暗黙のthisパラメータ 両方スキップで起こる順序依存の正体 今回の修正を読み解く binder.ts: ContainsThisフラグを立てる utilities.ts: hasContextSensitiveParametersの変更 checker.ts: Generator固有のエッジケース 修正前後の推論を比較する TypeScript 5.9 TypeScript 6.0 TypeScriptのコンパイラを読む最初の一歩 おわりに 参考資料 背景: プロパティの順序で型が変わる 次の test 関数を見てください。型パラメータ T を持ち、2つのプロパティ a と b を受け取ります。 function test < T >( options : { a : ( c : T ) => void ; b : () => T ; } ) {} 次の2つの呼び出しは、プロパティの記述順序が違うだけです。しかし、TypeScript 5.9以前では、この2つの結果は異なります。 test ( { b () { return 123 } , a ( c ) { return c } } ); // c: number test ( { a ( c ) { return c } , b () { return 123 } } ); // c: unknown プロパティの順序を入れ替えただけで c の型が number から unknown に変わります。 手元で挙動を確認したい場合は、 TypeScript Playground を開いてみてください。 c をホバーすると unknown が表示されるはずです。 アロー関数なら問題ないのはなぜか 一方、同じコードをアロー関数で書き換えると、順序に関係なく推論が通ります。 // アロー関数は、どちらの順序でもc: number test ( { a : ( c ) => { c } , b : () => 123 } ); // c: number test ( { b : () => 123 , a : ( c ) => { c } } ); // c: number メソッド構文では順序に依存するのに、アロー関数では依存しない。この差はどこから来るのでしょうか。 答えはTypeScriptの型推論パイプラインにおけるContext-Sensitive Functionという考え方にあります。 Context-Sensitive Functionの考え方 Context-Sensitive Functionとは、型注釈のないパラメータを持つ関数のことです。パラメータの型を決めるために、外部のコンテキストが必要になります。 // context-sensitive: (c) => c // cの型がわからない → 外部に依存 // context-sensitiveでない: (c: number) => c // cの型が明示されている () => 123 // パラメータがない TypeScriptの型推論において、context-sensitiveな関数は特別扱いされます。推論の過程で「後回し」にされるのです。 なぜ後回しにする必要があるのでしょうか。次のコードで考えてみます。 function callFunc < T >( callback : ( x : T ) => void , value : T ) {} callFunc( x => x. toFixed (), 123 ); // ^ ^^^ // xの型を知りたい Tの情報源 callback の引数 x の型を決めるには T が必要です。しかし T を推論するためには callback の情報も必要です。鶏と卵の問題が発生します。 TypeScriptはこれを解決するために、context-sensitiveな関数（ここでは callback ）をいったんスキップし、他の引数（ここでは 123 ）から先に T = number を推論します。その後、 callback に戻って x: number を確定させます。 推論の全体像 TypeScriptのジェネリック関数における型推論は、おおまかに次の流れで行われます。 引数を走査し、context-sensitiveな関数を特定する context-sensitiveな関数をスキップする 残りから型パラメータ T を推論する 確定した T で後回しの関数のパラメータを型付けする ステップ2で全ての関数がスキップされてしまうと T を推論するソースがなくなります。その場合、TypeScriptはフォールバック処理に入り、左から右の順番で処理を試みます。 メソッド構文に隠れている暗黙のthisパラメータ メソッド構文で書かれた関数は、暗黙の this パラメータを持ちます。 // メソッド構文 { a(c) { return c } } // ↓ TypeScriptの内部的な解釈 { a( this : ???, c: ???) { return c } } // ^^^^ 暗黙のthis → 型注釈なし → context-sensitive this パラメータには型注釈がないため、TypeScriptはこの関数をcontext-sensitiveと判定します。 this を実際には使っていなくても、存在するだけでcontext-sensitiveになってしまいます。 一方、アロー関数は this パラメータを持ちません。 // アロー関数 { a: (c) => c } // → thisパラメータなし // → cだけが未注釈のパラメータ この差が、メソッド構文とアロー関数で推論の挙動が異なる根本的な原因です。 両方スキップで起こる順序依存の正体 冒頭の例に戻りましょう。 test ( { a ( c ) { return c } , b () { return 123 } } ); a が先に書かれている場合、推論パイプラインでは次のように処理されます。 a(c) → 暗黙の this → context-sensitive → スキップ b() → 暗黙の this → context-sensitive → スキップ 両方スキップ → T を推論するソースがない フォールバックとして、左 → 右の順番で処理を試みる a(c) を先に処理 → T が未確定 → c: unknown b が先に書かれていた場合はどうなるでしょうか。 同じく両方スキップされる フォールバックとして、左 → 右の順番で b() を先に処理 b() の戻り値 123 から T = number を推論 a(c) に T = number を適用 → c: number これがプロパティの順序で型が変わる原因です。フォールバック処理が左 → 右の順番で行われるため、どちらのプロパティが先に書かれているかが推論結果を左右していました。 今回の修正を読み解く この問題を修正するTypeScriptのPR #62243 はAndarist氏によって実装され、2025年12月にマージされました。 github.com this を実際に使っていない関数は、context-sensitiveと見なさない、という修正が実施されました。 この変更は3つのファイルにまたがっています。 ファイル 役割 変更内容 binder.ts フラグを立てる 関数内の this 使用を追跡し、 ContainsThis フラグを設定する utilities.ts 判定を変える ContainsThis がなければ、暗黙の this パラメータを無視する checker.ts 補完する Generator固有のエッジケースに対応する それぞれの変更箇所を見ていきます。 なお、以降に掲載するコードは、解説の都合上、各ファイルから該当箇所のみを抜粋し、 // ... 中略 ... などで省略しています。実装の正確な差分は PR #62243のFiles changed をあわせて参照してください。 binder.ts: ContainsThisフラグを立てる TypeScriptの binder.ts は、AST（抽象構文木）を走査してシンボルテーブルを構築します。今回は、関数ノードのバインド時に this キーワードの使用を追跡する処理が追加されました。 まず、AST走査中に this キーワードを見つけたら、 seenThisKeyword フラグを立てます。 case SyntaxKind.ThisKeyword: if (node.kind === SyntaxKind.ThisKeyword) { seenThisKeyword = true ; // 追加 } // ... 既存処理 ... 次に、関数のコンテナをバインドする bindContainer で、関数本体のバインド前後で seenThisKeyword を退避・初期化し、本体内で this が出現していれば NodeFlags.ContainsThis を立てる処理が追加されました。 const saveSeenThisKeyword = seenThisKeyword; // 退避（追加） // ... 他ステートの退避 ... seenThisKeyword = false ; // 初期化（追加） bindChildren(node); // 増分コンパイル向けのリセット対象にContainsThisを追加 node.flags &= ~(NodeFlags.ReachabilityAndEmitFlags | NodeFlags.ContainsThis); // ... 中略 ... if (seenThisKeyword) { // フラグを立てる（追加） node.flags |= NodeFlags.ContainsThis; } // ... 中略 ... // 復元（アロー関数は内部のthis使用を外側に伝播） seenThisKeyword = node.kind === SyntaxKind.ArrowFunction ? saveSeenThisKeyword || seenThisKeyword : saveSeenThisKeyword; seenThisKeyword はバインド中にローカルに管理されるフラグで、関数本体内で this キーワードが出現したかどうかを追跡します。関数のバインドが完了した時点で this が使われていれば、 NodeFlags.ContainsThis フラグがノードに設定されます。 末尾の復元処理がアロー関数とそれ以外で分岐しているのは、アロー関数自身は this バインディングを持たず、内部の this はコード上で自分を囲っている外側の関数の this をそのまま参照するためです。アロー関数の内部で this が使われていれば、外側のメソッドの ContainsThis を立てる必要があります。 つまり、 this を使っている関数だけに ContainsThis フラグが立ち、使っていない関数にはフラグが立ちません。 utilities.ts: hasContextSensitiveParametersの変更 utilities.ts の hasContextSensitiveParameters 関数は、関数がcontext-sensitiveかどうかを判定するための関数です。 export function hasContextSensitiveParameters ( node : FunctionLikeDeclaration ): boolean { // Functions with type parameters are not context sensitive. if (!node.typeParameters) { // Functions with any parameters that lack type annotations are context sensitive. if (some(node.parameters, p => !getEffectiveTypeAnnotationNode(p))) { return true ; } if (node.kind !== SyntaxKind.ArrowFunction) { // If the first parameter is not an explicit 'this' parameter, then the function has // an implicit 'this' parameter which is subject to contextual typing. const parameter = firstOrUndefined(node.parameters); if (!(parameter && parameterIsThisKeyword(parameter))) { return !!(node.flags & NodeFlags.ContainsThis); // 変更箇所 } } } return false ; } 実際の変更点は最後の return の1行のみです。 - return true; + return !!(node.flags & NodeFlags.ContainsThis); この行が発火するのは「型パラメータがない」「アロー関数ではない」「最初のパラメータが明示的な this パラメータではない」という3条件を満たす場合、つまり暗黙の this を持つメソッド構文の関数です。 変更前は、この条件に合致するメソッドを無条件にcontext-sensitiveとして扱っていました。変更後は、 ContainsThis フラグが立っている（=本体で this を実際に使っている）ときだけcontext-sensitiveとして扱うようになりました。 checker.ts: Generator固有のエッジケース Generator関数はアロー関数として書くことができません（ function* 構文のみ）。そのため、 this を使わないGeneratorでも常にメソッド構文（= this あり）で書かれることになります。 this なしの関数がcontext-sensitiveでなくなると、Generator関数も一律にcontext-sensitiveでなくなってしまいます。しかし、Generator内の yield 式自体がcontext-sensitiveである場合があります。 declare function pipe < T >( gen : () => Generator <( arg : T ) => string , void , void > , initial : T , ): void ; pipe( function* () { yield ( arg ) => arg. toFixed ( 2 ); // yield式がcontext-sensitive } , 42 ); この yield (arg) => arg.toFixed(2) は、 T の型が確定しないと arg の型が決まりません。つまり、このGenerator全体はcontext-sensitiveとして扱う必要があります。 checker.ts では、 isContextSensitive の switch に YieldExpression のケースを追加し、 isContextSensitiveFunctionLikeDeclaration に新規関数 hasContextSensitiveYieldExpression を呼ぶ分岐が追加されました。 case SyntaxKind.JsxExpression: case SyntaxKind.YieldExpression: { // 追加 const { expression } = node as JsxExpression | YieldExpression ; return !!expression && isContextSensitive(expression); } function isContextSensitiveFunctionLikeDeclaration ( node : FunctionLikeDeclaration ): boolean { return hasContextSensitiveParameters(node) || hasContextSensitiveReturnExpression(node) || hasContextSensitiveYieldExpression(node); // 追加 } function hasContextSensitiveYieldExpression ( node : FunctionLikeDeclaration ): boolean { // 追加 return !!( getFunctionFlags(node) & FunctionFlags.Generator && node. body && forEachYieldExpression(node. body as Block , isContextSensitive) ); } これにより、 yield 式がcontext-sensitiveな場合はGenerator全体をcontext-sensitiveとして扱えるようになります。 修正前後の推論を比較する 冒頭のコードで、修正前後の推論を比較してみましょう。 test ( { a ( c ) { return c } , b () { return 123 } } ); TypeScript 5.9 a(c) → 暗黙の this → context-sensitive → スキップ b() → 暗黙の this → context-sensitive → スキップ 両方スキップ → T を推論するソースなし フォールバックとして、左→右の順番で処理 a(c) を先に処理 → T が未確定 c: unknown TypeScript 6.0 a(c) → this 不使用 → ContainsThis なし → スキップしない b() → this 不使用 → ContainsThis なし → スキップしない 通常の推論へ b() の戻り値から T = number を推論 a(c) に T = number を適用 c: number this を使っていないメソッド構文の関数がcontext-sensitiveと判定されなくなったことで、アロー関数と同じ推論に入るようになりました。プロパティの記述順序に依存しなくなります。 TypeScriptのコンパイラを読む最初の一歩 TypeScriptコンパイラの checker.ts は5万行を超える巨大なファイルです。kkk4oruさんがTSKaigi 2025で登壇された「 checker.tsに対して真剣に向き合う 」も印象に残っている方が多いのではないでしょうか。 2025.tskaigi.org 5万行に圧倒されますが、一つの機能を追うのであれば全部読む必要はありません。 OSSのPRを読むときは、次の観点で読み進めると迷子になりにくくなります。 リンクされているIssueを先に読み、課題や何を解決しようとしているのかを理解 先に修正されたテストを読むことで、何を直したのかを理解 PRの説明やレビューコメントを読むことで、修正の意図を理解 NodeFlags / TypeFlags が増えていれば、それを追うことで変更の意図を理解 これらは今回の自分の読解で実際に役に立った観点です。 おわりに 1つのPRからTypeScriptの型推論の仕組みを追うことで、Context-Sensitivityという概念と、TypeScriptの内部に踏み込むきっかけを持ち帰っていただけたら嬉しいです。 参考資料 Announcing TypeScript 6.0 Beta - TypeScript microsoft/TypeScript - GitHub Improve inference by not considering thisless functions to be context-sensitive by Andarist · Pull Request #62243 · microsoft/TypeScript microsoft/TypeScript-Compiler-Notes - GitHub TypeScript Compiler Internals | TypeScript Deep Dive ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers 本記事の binder.ts / utilities.ts / checker.ts のコードは、 microsoft/TypeScript から引用しており、 Apache License 2.0 のもとで配布されています。

こんにちは。こんばんは。 Findy Team+ 開発のフロントエンドリードをしている @shoota です。 今回はフロントエンドからは少し離れ、AIによるプルリクエストのレビューシステムを作成した話を書きます。 Findy Team+フロントエンドの現状と課題 AIコーディング時代の新たな課題 AIによる自動レビュー（Approve）を作ろう 解決したい課題 レビューは大きく3種類ある 誰が使えるのか 何を判定するのか 判定のキモはTidy First?の分類 実装とポイント GitHub Actions Claude Code Actions ワークフローの変化とプロンプトの改善 実行コスト おわりに Findy Team+フロントエンドの現状と課題 過去のブログでも触れていますが、Findy Team+のフロントエンドは、非常に大きなモノレポで構成されています。 tech.findy.co.jp このため、CIの最適化・チューニングはもちろんのこと、コードベース全体の秩序の品質を維持するためにさまざまな工夫や制約をもって運用してきました。 AIコーディングが主流になってからは更にこれらを強化し、制約やルールの策定、ESLintやユニットテストなどのガードレール整備や強化をおよそ1年をかけて進めてきました。 （この内容については別で発表したいと思います） これらの投資とAIモデルの進化により、これまでバックエンドを中心に活動しているメンバーのフロントエンドの参入障壁を大きく下げることに成功しています。 現在では、AIが生成するコードの質は1年前から大きく向上していると体感しています。 AIコーディング時代の新たな課題 しかしここで新たな課題が生まれました。それは、「AIが真似すべきでないコードの修正や、それらを防ぐルールの導入のためのレビューコストが異常に高い」ということです。 AIの活用のためにコードを直し続ける活動は巨大なコードベースではかなりコストがある 技術的な障壁よりも単純な物量がつらく、対抗する手段がない ESLintのルールを1つ変更するだけでプルリクエストが大量に必要になる 特定のルールのちょっとした厳格化で25件のプルリクエストを作成 あたらしいルールを追加したときは150件のプルリクエストが必要になった 軽微な変更でも意味のある粒度で修正しなくてはレビューできないため、ひたすらに数を重ねる このような事象が定常的に発生しており、次のFindy Team+でのグラフでも確認できます。 大量のプルリクエストが発生する様子 Vitest の一部のassertionがdeprecatedになったことに対して、私が一人でClaude Codeを回し、1日に72件、2日で100件以上のプルリクエストを作成しました。 レビュー待ちが多く発生する割に、内容は関数の置き換えなのでレビュー価値が低いプルリクエストが大量に必要になったのです。 このような 「AIを利用して品質を維持するための整備が人間を苦しめている」 という状況は、近頃話題になっていた Hustle Porn に近いのではないか？と考えました。 hustle porn 覚えた https://t.co/y3jpiLDL0x — Takuto Wada (@t_wada) 2026年4月13日 プルリクエストをたくさん書くことは素晴らしいですが、そこに意味のある粒度と価値が伴わなければなりません。 AIによる自動レビュー（Approve）を作ろう このような背景からレビュー負荷を可能な限り低減させ、ただしい 怠惰 を取り戻すために、AIレビューの仕組みを作成することにしました。 まずはやりたいことから全体の構想とコンセプトを決めていき、次のような内容になりました。 解決したい課題 プルリクエストを高速に作り続けることはむしろ歓迎すべき 課題の本質は「レビュープロセスが対ひとでしか機能していない」こと 人の時間をうばう 人のアクションを待つ 両者にメリットが少ない レビューは大きく3種類ある レビューする価値がないことを確認するレビュー。レビューというワークフローを実施しているだけであり、本質的なレビューはしていない。レビューワークフローに相乗りしている儀式のひとつ。 品質、プログラム観点としてのコードレビュー。いわゆる本質的なコードレビュー。 レビュー結果が反映されていることのレビュー。論点が絞られており、コードの内容がレビュー指摘に即して修正されているかを「確認する」だけの作業的な儀式。 今回は1. の「レビューする価値がないことを他者が保証する儀式」をAIにやらせることをゴールとします。 誰が使えるのか 初手はフロントエンドのレビュワーチームのみに絞る 最大リスクは、誤判定や手順のハックによるレビューのザル化 フロントレビュワーチームはセルフレビューで一定の品質担保ができている前提で考える 条件的に一般解放は想定するが、判定の成功率データがたまるまではリスクのほうが大きい 何を判定するのか 要はプルリクエストの分類器をつくる Claude CodeのReview (~$25) は必要がない 変更内容から人間がレビューする必要があるかどうか？を判定する 振る舞いが変わらない 構造的なリファクタリング code generatorなどの既存の機械的なワークフローの結果も不要と判断する 判定のキモはTidy First?の分類 レビューの必要性を測る判定処理に、 構造的なリファクタリング という概念を持ち込みました。 これは昨年の弊社のイベントでキーノートを務めていただいたKent Beck氏の書籍 Tidy First? から引用した言葉です。 この書ではリファクタリングの分類が紹介されており、リファクタリングを効率的に進めるための作業を指します。 和訳では「整頓」と表現されています。 振る舞いの変化を伴わない、「コードの移動・分割」、「名前の変更」、「配置の変更」 プログラム（群）の凝集度に対するリファクタリングアプローチ これらの修正は人間が目で追うのは意外と面倒で、レビューコストが割に合わない 例）ファイル移動や統合、変数・関数のリネームor削除、関数統合・分離 www.oreilly.co.jp Tidy First?に関する考察は非常に多く議論されているので、Claude Codeに調査させながら「人間のレビューが不要」の定義を確定し、プロンプトに起こしていきました。 次に示すのがそのパターンの概要です。詳しい内容はぜひ書籍を確認していただけるとよいかと思います。 対象パターン（T1〜T14） T1: ファイル移動・リネーム T2: import整理・barrel export T3: 型定義の移動・分離 T4: コンポーネント・関数の分割・統合・抽出 T5: 変数・関数・propsのリネーム（テスト/モックへの機械的波及含む） T6: ESLint/Prettier修正 T7: 不要コード・ファイル削除 T8: 非推奨APIの機械的移行（1:1対応） T9: GraphQL codegen実行結果 T10: Nx generator実行結果 T11: ガード節への変換 T12: 説明変数・定数の導入 T13: Feature Flag名の追加 T14: コメントの追加・修正・削除 NGパターン（NG1〜NG7） 新条件分岐、新ビジネスロジック、API変更、状態管理変更、テスト追加、UI変更、設定値変更 実装とポイント 全体の要件が決まったのでここからは実装です。 GitHub Actions GitHub Actionsをランナーとし、プロンプトファイルを読み込んだうえでClaude Code Actionsに渡して実行、結果をパースしてレポートする非常にシンプルなフローです。 またFindy Team+はCI結果を送ってCIの実行分析ができるので、これも組み込んであります。 GitHub Actionsのフロー Claude Code Actions Claude Code Actionsの呼び出しのポイントは --max-turns です。 これはClaude Codeが処理を何手まで行うかを制限するもので、変更ファイル数やそれらのファイルの関連性によって前後します。 - name: Classify PR changes id: claude uses: anthropics/claude-code-action@5d5c10a4f389689f992ea10bb14dcb6fcc83146d # v1.0.102 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} claude_args: '--max-turns 20' prompt: ${{ steps.prompt.outputs.content }} 何パターンかの構造的なリファクタリングのプルリクエストで試したところ 〜15 turns におさまるようでしたが、余裕を見て20を設定しています。 これを設定しておくことでプロンプトの誤認や想定しない大きな差分で実行された場合でも「判定不能」で安全に終了するようにしています。 ワークフローの変化とプロンプトの改善 何度か試していくうちに、ひとつの気づきがありました。 これまでプルリクエストは 「人間が認知できる変更量」にサイジングするようにすべき でしたが、AIは機械的にこれを分析できるので「同じ作業なら差分が大きくても1つのプルリクエストにまとめる」ことができる、ということです。 そのため大きな差分でもApproveができるような負荷耐性をもたせる必要があります。 そこで変更ファイルが多い場合は変更そのものを見るのではなく、いくつかをサンプリングし、「diffのパターンが同一であるか？」をClaudeが確認するようにしています。 <!-- 追加したプロンプトの抜粋 --> ## 大規模 PR のフォールバック - **変更ファイル数が 30 ファイルを超える場合**: 同一パターンの変更が繰り返されるファイル群はサンプリング（代表的な数ファイルの確認）で判定してよい。サンプリングした旨と確認したファイルを注意事項に記載する - **サンプリング時は副作用の取り逃しに注意する**: ある T パターンを特定したら、**その波及先ファイル群（スナップショット、spec、モック、`index.ts` の re-export、import 更新 等）も必ず1件以上サンプリングに含め、元の T パターンとの対応を確認する**。波及先のファイルだけを単独で見ると NG に誤分類しやすい（例: T5 リネームのインラインスナップショット更新を NG5 と誤認）。波及元・波及先を**セットで**サンプリングすること （以下略） 実行コスト Claude CodeのReviewは 最大$25の費用が必要 ですが、今回はプルリクエストの分類器なのでそこまでのコストがかかりません。 CIから実行したログからみると、1 runあたり、$0.20〜0.50で分類ができていました。 { " type ": " result ", " subtype ": " success ", " is_error ": false , " duration_ms ": 62472 , " num_turns ": 10 , // Claude Codeの手数の実績値。最大20で絞ってある。 " total_cost_usd ": 0.24731475000000003 , // 約$0.25を消費 " permission_denials_count ": 0 } おわりに プルリクエストの分類器をGitHub Actions + Claude Code Actionsで作成することで、人がレビューしなくて済むプルリクエストは作成者が単独でマージできるようになりました。 この仕組みの導入は想定以上に開発者体験がよく、また機能開発の合間でリファクタリングするモチベーションも高めてくれます。 まさに Tidy First? のなかでの「先に整頓、あとに整頓」を仕組みで支えることができたと感じています。 Claude Code Actionsはチャット形式に似たJSONレスポンスを返すため、AIチャットの実装経験もCIのデバッグに役立ちました。 今後はさらに対象を拡大させつつ、組織的に利用するAIワークフローを充実させていきたいと思います。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディ株式会社でデータエンジニアをしている 開 です。 2026年4月28日（火）に、データソリューションチーム主催の採用イベント 「事業成長に効かせるファインディ流データエンジニアリングの実践」 を開催しました。 findy-inc.connpass.com この記事では、イベントを企画した背景と当日の3本のセッションを参加できなかった方にもイメージが伝わるようにまとめます。 イベント開催の背景 セッション1: ファインディの事業拡大を支える拡張可能なデータ基盤へのリアーキテクチャ セッション2: データモデリングを通して管理会計のオペレーションを再設計 セッション3: 社内で使われるLooker整備の進め方 まとめ イベント開催の背景 ファインディでは、既存4プロダクトに加えて、新たに4つのプロダクトをリリースし、エンジニアの皆さまへサービスを多角的に展開しています。会社規模の拡大とともに、扱うデータの量と種類は急速に広がってきました。 prtimes.jp 変化の激しい事業環境のなかで客観的な意思決定を支えるには、社内の情報流通をより活性化させる仕組みが欠かせません。私たちは、その土台を担うのがデータエンジニアリングだと考えています。 データソリューションチームは少数精鋭で推進してきましたが、事業成長のスピードに合わせてデータ基盤をさらにスケールさせるには、共に挑戦してくれる仲間の存在が不可欠です。今回のイベントは、ファインディがどのような課題に向き合い、どのような技術と組織で解いているかを直接お話しする機会としました。 セッションは3本立てで、データ基盤・データモデリング・BIの3つの観点からファインディのデータエンジニアリングをお話ししました。 セッション1: ファインディの事業拡大を支える拡張可能なデータ基盤へのリアーキテクチャ 登壇者: 開 speakerdeck.com 事業拡大に合わせてデータ基盤をどうリアーキテクチャしているかを紹介しました。直近1年でデータソースは10倍、Google Cloudプロジェクトは6倍に増える一方、データエンジニアは3名のままで、認知コストと運用負荷が膨らんでいました。 これまでは事業＝ドメインとしたデータメッシュ的な構成で、技術選定も各チームに委ねていました。アジリティは出る一方で、ドメイン間の連携不足や技術のばらつき、作業重複が課題になっていました。 そこで、データメッシュの利点は残しつつ実装を見直し、Google Cloudプロジェクトの統合、IAMのデータセット単位での管理、dbt Platformへのオーケストレーション集約やマネージドサービスの活用を進めています。これによりマネージドサービスのAPIやMCPを用いてAIエージェントに運用を一部移譲することができています。作成したスキルやサブエージェントは以前テックブログで紹介したプラグインとしてチーム全体で使えるようにしています。 tech.findy.co.jp DataOpsの省力化が進む一方、コスト透明性の低下といった新しい課題も見え、FinOps体制の構築や、浮いた時間をデータ活用者との会話やイネーブリングに使っていくことを次のテーマにしています。 セッション2: データモデリングを通して管理会計のオペレーションを再設計 登壇者: 田頭さん speakerdeck.com 経営判断に直結する管理会計という業務領域に対して、データモデリングの観点からオペレーションを再設計した取り組みを紹介しました。 ファインディの管理会計は、長らくスプレッドシートを中心に回っていました。月次のたびに関数とピボットを手作業で組み直し、IMPORTRANGEやVLOOKUPで絡み合ったスプレッドシートのリネージは50件を超え、どこか1枚崩れると全体が連鎖して壊れる脆さを抱えていました。同じKPIが部署ごとに別ロジックで計算されて数字が合わない、月次締めに2〜3日かかって意思決定が後追いになる、といった状態も常態化していました。 再設計の起点に置いたのは、技術選定ではなく業務担当者へのヒアリングです。「計上組織」「補助科目」「配賦」「予算番号」といった専門用語が飛び交うなか、勘定元帳やマクロを眺めるだけでは掴めない集計粒度や分析軸を、経営管理部の担当者と何度もMTGを重ねて引き出していきました。書籍 『アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド』 のBEAM✲を参考に、誰が・何を・いつ・どこで集計したいのかを対話から輪郭化し、総勘定元帳を起点に売上・費用・原価を月次粒度のファクトとして整理しています。 実装は、会計データソースをGoogle DriveにアップロードしてTROCCOで取り込み、dbtで集計してLookerやスプレッドシートから参照する構成に落としています。これにより、ワンボタンで月次の実績値が揃い、想定外の科目も自動で検出できるようになりました。「どの数字が正しいか」を議論する場面はなくなり、月次締めの所要時間と数字の信頼性が同時に改善しています。 今後は、実績ファクトと同じ粒度で予算・見通しを取り込んだ予実分析の自動化や、整備済みのファクトを起点にAIエージェントが自然言語で会計分析を行える基盤への展開を進めています。 セッション3: 社内で使われるLooker整備の進め方 登壇者: 出相さん speakerdeck.com 社内で実際に使われるBIにするためにLookerをどのように整備してきたかを紹介しました。「ダッシュボードを作った瞬間がピークになって使われなくなる」「事業部からはデータ活用の入口が見えない」「スプレッドシート運用が属人化して限界が見えている」といった、よくある課題を出発点にしています。 ファインディでは、Lookerを意思決定にひも付くダッシュボードを定常的に見る場としてだけでなく、Exploreや会話分析でデータそのものを探索する場にすることを目指しています。ただし、最初はLookerを見に行く習慣もExploreの操作にも慣れていないため、進め方の工夫が欠かせません。 そこで、ヒアリングで課題を引き出す → 最低限の機能に絞って最初のダッシュボードを素早く提供する → 共有MTGで一緒に触りながら改善ループを回す → 利用が定着してからディメンショナルモデルやメタデータを整える、という4ステップで価値を積み上げてきました。完璧な設計よりも早い体験提供を優先し、苦労していたことから先に解消していくことを大切にしています。詳しい進め方は以前のテックブログでも紹介しています。 tech.findy.co.jp その結果、MAUは2026年1月から4月途中で約1.5倍、WAUは1月中旬から4月中旬で約2.6倍に成長しました。経営管理部からも「BigQueryやLookerを駆使したモニタリングが事業拡大に不可欠」というコメントが届くなど、Lookerが信頼できるデータソースとして社内に定着してきています。 まとめ 今回のイベントを通じて、ファインディがデータエンジニアリングをどのように事業に効かせようとしているかを、3つの異なる切り口でお伝えできたと思います。データ基盤・データモデリング・BIのいずれも、技術そのものよりも「事業や業務にどう接続するか」を軸に進めてきた取り組みです。 参加してくださった皆さん、ありがとうございました！ ファインディでは、データエンジニアリングの力で事業成長を支える仲間を募集しています。今回のイベント内容に少しでも興味を持っていただけた方は、ぜひお気軽にカジュアル面談などでお話しできるとうれしいです。 herp.careers

こんにちは、ファインディでFindy Toolsの開発をしている本田です。 このたび、Findy Toolsの新機能として「アーキテクチャAI」をリリースしました。要件を入力するとAWSのアーキテクチャ図と設計の提案が生成される機能です。 findy.co.jp 今回の開発では、PM・仕様策定・スコープ定義・インフラ・FE/BE開発・テストまで、ほぼ一人で1か月で担当しました。そして、コーディングはほとんどClaude Codeに任せ、私自身はほぼコードを書いていません。 この記事では、そんな開発を進めるなかで分かったこと、難しかったこと、そして改めて実感したエンジニアの仕事について紹介します。 アーキテクチャAIについて 一人開発の全体像 エンジニアが価値とコストを自分で判断する 対話で判断の視野を広げる 動くもので共通認識を作る 自分の仕事は減らず、判断と意思決定の時間が増えた まとめ アーキテクチャAIについて 本題に入る前に、リリースした機能を軽く紹介させてください。 アーキテクチャAIは、Findy Toolsの中で提供している機能の1つで、「作りたいシステムの要件」を入力するとAWSを使った構成案とアーキテクチャ図、そして設計の考え方の解説がまとまった形で得られるものです。 ai-architecture.findy-tools.io アーキテクチャの設計はサービスの土台を決める工程で、経験や周辺知識の広さが問われる領域です。そうした知見を持った人に相談しづらい場面でも、構成の検討を前に進める助けになることを目指しています。 ここから先は、この機能を一人で1か月で作ったなかで気づいたことを中心に書いていきます。 一人開発の全体像 今回は、PMから開発、テスト、リリースまでを一人で担当しました。具体的には次のような範囲です。 プロダクトの方向性・優先順位の決定 仕様策定、スコープ定義 インフラの構築 フロントエンド・バックエンドの実装 テスト、リリース作業 開発のワークフローはシンプルで、だいたいこのサイクルを回していました。 GitHub Issueに「なぜ作るのか」「何を作るのか」を、PRDやユーザーストーリーの形で書く Claude CodeにIssueを渡して実装してもらう 自分は差分をレビューし、必要に応じて指示を出す 別チームのメンバーにレビューしてもらい、PRをマージする 実装の途中でも、作りたい背景やユーザーに届けたい価値に立ち戻って方針を調整することはよくありました。 仕様策定やUIのモック作成も、AIと壁打ちしながら進めていました。結果として、自分でコードを書いた量はごくわずかで、ほとんどの実装はClaude Codeが書いています。 一方で、「自分はほぼコードを書いていない」からといって仕事が少ないわけではありませんでした。むしろコーディング以外にやることが山ほどあるというのが実感です。 何を作るか、何を削るかの判断 仕様の細部に関する意思決定 技術選定 コードレビューと品質の担保 スケジュール管理とリリース計画 ここからは、この進め方で1か月やってみて感じたことを書いていきます。 エンジニアが価値とコストを自分で判断する 最も強く感じたのは、 エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携わることの強み です。 今回は一人で担当していたので、事業やプロダクトの意図、技術的な実現可能性、実装コストが、すべて自分の頭の中に揃っていました。「ユーザー価値として外せない部分はどこか」「コストをかける価値があるのはどこか」を、自分の中でつなげて考えながら開発を進めることができます。 具体的には、開発の途中でアーキテクチャ図の描画ライブラリを切り替える判断をしたり、リリースの2週間前になってからSNSで共有されたときに見栄えの良い画像を生成する機能を追加する判断をしたりと、方針転換を素早く進められました。技術的に成立するかをClaude Codeで素早く検証しつつ、プロダクトとして本当に必要かを自分で判断できたことで、価値とコストの両取りを狙える選択肢を見つけやすくなっていました。 体制を一人にしたことが本質ではないと思っています。大事なのはやはり、作る側のエンジニアがユーザー価値や事業価値を理解したうえで、コストと価値のバランスを判断しながら開発に携われているかだと、今回の開発を通じて改めて感じました。 対話で判断の視野を広げる 意思決定が速いのは良いことですが、速ければ良いわけではありません。一つの視点だけで速く判断を続けていると、気づかないうちに筋の悪い方に流れてしまいます。 ここで効いてきたのが、一人で担当していても孤立はしていないという体制づくりでした。 開発中は、事業部長・PO・デザイナと定期的に相談・共有できる場を持ち、それ以外の場面でもいつでもコミュニケーションを取れるようにしていました。 プロダクトとして何を大事にしているか 事業としてこの機能にどういう期待があるか デザインとして譲れない部分はどこか こうした観点を継続的にすり合わせることで、自分一人では見えていなかったより良い選択肢を見つけやすくしていました。 自分の頭の中だけで判断すると、どうしても視野が狭くなります。そこに他の立場の視点が入ると、「他にもっと良い選び方はないか」という問い直しができます。スピード重視の体制であっても、というよりスピード重視だからこそ、チームとの対話は欠かせないと感じました。 動くもので共通認識を作る もう1つ強く感じたのが、 速く見せられるもの・動くものを使って共通認識を作ることの効果 です。これ自体は昔からよく言われる話ですが、AIの力でぐっとやりやすくなりました。 今回は、実プロダクトの開発を始める前に、別リポジトリでPoCアプリを作り、ステークホルダーやインタビューにご協力いただいた方に、実際に見たり触ったりしてもらう時間を取りました。 PoCアプリの画面。デザインは作り込まず、ユーザーに価値を体験してもらうことを優先した。 文章やスライドだけで議論すると、どうしても抽象的になり、認識のズレに気づきにくくなります。動くものがあると、「これは欲しい」「ここは期待と違う」というフィードバックが具体的に返ってくるだけでなく、「どういう価値が得られそうか」という部分でも共通認識を作りやすくなります。 PoCを見たり触ったりしてもらうなかで見えてきたのは次のようなことです。 ユーザーが本当に価値を感じるのはどの部分か 最初はあると便利そうに見えたが、実際はなくても困らない機能 技術的に見落としていた制約や、逆に想定より軽く実現できそうな部分 PoCで得られたこれらの情報が土台になって、本開発のスコープと方針が定まっていきました。 AIで「仮に動くもの」を高速に作れるようになった強みを活かして、動くものを中心に仮説検証のサイクルを回せたこと が、1か月という限られた期間のなかで特に効いたポイントだと思います。 自分の仕事は減らず、判断と意思決定の時間が増えた ここまで書いてきたことを踏まえて、改めて感じたのは 少なくとも今回の自分の経験では、コーディングをAIに任せても、エンジニアとしてやることは減らなかった ということです。むしろ、本質的な判断に集中する必要が出てきた感覚でした。 今回の開発で自分が時間を使っていたのは、次のような部分です。 この機能を作る意味は何か、誰のどんな課題を解くのか スコープをどこまで広げ、どこで切るか どの技術を選び、どの技術を見送るか 出てきたコードが本当に要件を満たしているか、将来の運用に耐えるか どれも、意思決定と判断の仕事です。コーディングそのものをAIに任せられるからこそ、こうした判断に集中できる時間が増えました。 AIと協業するなかで変わる部分と変わらない部分があり、「コードを書く時間」は確実に減りますが、「エンジニアリングを行う時間」は減らない、むしろ増えている感覚でした。 まとめ ほぼ一人で1か月かけてアーキテクチャAIをリリースしてみて、次のことが学びとして残りました。 エンジニア自身がユーザー価値と実装コストのバランスを判断しながら開発に携われると、価値とコストの両取りを狙える選択肢を見つけやすい 速さだけを追うのではなく、複数の視点を対話で取り込んで選択肢を広げていく AIで仮の動くものを高速に作れるようになった強みを活かせば、短期間でも動くものを軸に仮説検証を回しやすい 少なくとも今回の自分の経験では、コーディングをAIに任せても仕事は減らず、判断と意思決定に集中する時間が増えた AIと一緒に開発する時代になっても、「何を作るか」「どう作るか」「なぜそれを選ぶか」を考え抜くことの大切さは変わらないなと、今回の開発を通じて改めて感じました。 アーキテクチャAIは次のページから触れます（Findy Toolsの会員登録が必要です）。ご興味のある方はぜひ試してみてください。 findy-tools.io ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。プロダクト開発部の森 @jiskanulo です。 2026年4月22日から24日までRubyKaigi 2026 Hakodateが開催されました。 rubykaigi.org 函館アリーナを3日間に渡って貸し切る大規模イベントの運営をしていただきましたスタッフの皆様に感謝を申し上げます。 ファインディ株式会社もPlatinumスポンサーとして協賛しました。 私もブースに立って出展やファインディ各サービスのご案内をさせていただきました。 お話しをしていただいた皆様にも重ねて感謝申し上げます。 ブースに立つ合間にセッションを聞いて自分でやれそうなことに思いを馳せたり、他社様のブースを回ってプロダクトのお話をしたり、昔の同僚や知人と再会したりと個人的にもいい刺激の多い3日間でした。 さて、4月24日、最後のセッションのMatzさんのキーノートにてRubyファイルをネイティブバイナリにコンパイルする Spinel が発表されました。 早速Spinelを使ってみた感想とつかいどころを記します。 Spinelとは 検証環境とセットアップ 動かしてみた Hello, World! eval / requireの挙動：エラーにならず無音で間違う eval は no-op に置き換わる require は文ごと消える 現時点での注意点 Spinelを使ってみる requireなしでJSONを扱う ハマりどころは個別に踏みに行く価値がある Spinelを試すときの判断基準 個人的所感 おまけ: Spinelの由来 おわり Spinelとは SpinelはRubyのAOT (Ahead-Of-Time) コンパイラです。 RubyソースコードをPrismでパースし、全プログラム型推論を行いCのコードに変換してネイティブバイナリを生成します。 パイプラインは次のとおりです。 Ruby → Prism → AST → 全プログラム型推論 → Cコード → ネイティブ実行ファイル リポジトリのREADMEによると、miniruby比で約11.6倍、Conway's Game of Lifeでは86.7倍という性能が示されています。 またバイナリサイズもmrubyを含めずに数十KBに収まるので容量が厳しい環境にも適用できるとのことです。 実体としての ./spinel はPOSIX shell wrapperで、内部で spinel_parse → spinel_codegen → cc を直列に呼び出している、という作りです。 検証環境とセットアップ 検証は手元のmac環境で行いました。 4月24日公開直後にmacで動かそうとしたタイミングでは malloc.h が存在しないなどでエラーになったのでDockerでUbuntuのコンテナを起動して操作しましたが、現在は対応されています。 土日で函館観光しているうちにコントリビュートが進んでいますね。コントリビュートのチャンスですね。 mac build対応 https://github.com/matz/spinel/commit/4593581eb87cea45b59fb28b9dcf2cd75a9bcbab windows対応 https://github.com/matz/spinel/commit/1fe3136aa9bf834b5f37176faca7346503fb1446 環境は次のとおりです。 macOS (arm64) Apple Clang Spinel masterブランチ（2026-04-28時点） ビルドと実行の基本フローはシンプルです。 spinel をmakeし、 spinel にrubyファイルをわたせば実行形式バイナリが出力されます。 make deps # 初回のみ: libprism 取得 make # spinel_parse / spinel_codegen / ランタイムをビルド ./spinel app.rb # Ruby → 実行形式（./app） ./app 動かしてみた Matzのキーノートとも被りますがサンプルコードを動かしてみました。 またキーノートで話があったとおり eval と require はサポートしていないとのことです。 eval, requireを使うと具体的にどうなるのかも試してみました。 Hello, World! 最小の動作確認はそのまま動きます。 # hello_world.rb puts " Hello, World! " ./spinel hello_world.rb ./hello_world # => Hello, World! eval / requireの挙動：エラーにならず無音で間違う 2026年4月28日の現時点では コンパイル時にエラーにならず、warningも出ず、しかし実行すると無音で間違った出力 を返すという挙動です。 具体的に2つのケースを見ていきます。 eval は no-op に置き換わる 次のRubyコードをSpinelでコンパイルして実行します。 # test_eval.rb code = " 1 + 2 " result = eval (code) puts result $ ./spinel ./tmp/jiska/samples/test_eval.rb ./tmp/jiska/samples/test_eval.rb -> test_eval 実行すると結果は 0 です。 $ ./test_eval 0 生成されたCのコードを見ると eval() の呼び出しがno-opに置き換わり、戻り値は型推論で決まったゼロ値（ mrb_int のため 0 ）になります。 const char *lv_code = "1 + 2" ; mrb_int lv_result = 0 ; // mrb_int = int64_t typedef lv_code = "1 + 2" ; lv_result = 0 ; // ← eval() 呼び出し自体が消滅、0 を代入するだけ printf ( " %lld\n " , ( long long )lv_result); mrb_int はmrubyのような」命名に見えますが lib/sp_runtime.h で int64_t のtypedefとして定義されたSpinelランタイムの整数型です。 https://github.com/matz/spinel/blob/64105ec86d08c9edc92c3d17bf059126ceaa15d3/lib/sp_runtime.h#L53 require は文ごと消える 次は require "json" と JSON.generate を使うケースです。 # test_require.rb require " json " puts JSON .generate({ name : " spinel " , year : 2026 }) こちらも実行すると 0 になります！ $ ./spinel ./tmp/jiska/samples/test_require.rb ./tmp/jiska/samples/test_require.rb -> test_require $./test_require 0 require の行は生成されたCのコード上で文ごと消えます。 続く JSON.generate もSpinelから見れば未定義メソッドであり、 eval と同じくゼロ値を返す呼び出しに化けます。 最終的に puts には 0 が渡って表示される、という流れです。 現時点での注意点 現時点では「コンパイルが通った」「実行ファイルができた」「実行できた」の3点だけを見ていると間違った結果を吐いていることに気づけません。 Spinel向けにRubyを書くときは README を都度確認することが重要です。 Spinelを使ってみる 次に実際のユースケースを想定してみます。 実例として、GitHubのPR一覧JSONを入力に取り、各PRの number と author を表示するスクリプトを書いてみました。 入力はARGV、stdinの優先順で受け取ります。 requireなしでJSONを扱う require "json" が使えないので標準の Regexp と String 操作だけで処理を組む必要があります。 なお、ここで示すコードは正しいJSONパーサではありません。 require "json" が使えないSpinelの制約下で、入れ子オブジェクトや }, を含む文字列値が現れない、フラットな配列形式の固定データから number と author をアドホックに取り出す例として読んでください。本格的なJSON処理が必要な場合は、入れ子・エスケープなどで容易に壊れるため、この実装は使えません。 実際のRubyファイルは次のとおりです。 多少トリッキーなところは感じますが、こうした限定的な用途であれば、RegexpとStringの標準機能だけで実装できることがわかりました。 if ARGV .length > 0 input = ARGV [ 0 ] else input = readlines.join end records = input.split( / }, / ) results = [] records.each do |chunk| if chunk =~ / "number" \s* : \s*(\d+)/ num = $1 if chunk =~ / "author" \s* : \s* " ([^ " ]+) " / auth = $1 results << " # #{ num } by #{ auth }" end end end if results.length == 0 $stderr .puts " Error: failed to parse JSON (no matching number/author pairs found) " exit 1 end results.each do |line| puts line end 実行サンプルは次のとおりです。 引数渡し、パイプ、リダイレクトそれぞれに対応しています。 JSONを展開できない場合は標準エラーへエラーメッセージを出して exit 1 します。 SAMPLE='[{"number":1,"author":"Findy"},{"number":2,"author":"jiskanulo"}]' # 1) 引数渡し ./pr_extract "$SAMPLE" # 2) パイプ echo "$SAMPLE" | ./pr_extract # 3) リダイレクト ./pr_extract < sample.json # それぞれの出力: # #1 by Findy # #2 by jiskanulo $ ./pr_extract "not json" Error: failed to parse JSON (no matching number/author pairs found) $ echo $? 1 なお、引数もパイプもなしで ./pr_extract を起動すると readlines がEOF待ちでブロックします。 最初は $stdin.tty? で判定してUsageを表示しようとしましたが、実機で試すとTTYでもパイプでも両方 0 が返ってきました。これも eval / require と同じく、Spinel未対応のメソッドが silent failしている例です。 # test_tty.rb puts $stdin .tty? $ ./test_tty # TTY実行 0 $ echo "" | ./test_tty # パイプ実行 0 Spinelで標準入力を扱うときは $stdin.tty? に頼った分岐ができないため、引数で渡すかパイプ・リダイレクトで明示的に流し込む運用に倒すのが安全です。 ハマりどころは個別に踏みに行く価値がある 実装してみると String#<< でmutable化すると Regexp#scan に渡せない、 Regexp#scan(/(...)/) { |m| ... } のキャプチャは効かない...などとハマりどころがいくつかありました。 ただ、現時点での詳細を解説しても開発が活発に進んでいるのですぐに風化してしまうので詳しくは記しません。 Spinelを試すときの判断基準 ここまで触ってみた感触から、Spinelを触るときの判断基準を次にまとめます。 成功体験を得やすいのは次のようなコードです。 入出力が puts / printf で完結する 標準ライブラリに依存しない 数値計算・文字列処理・正規表現( =~ + $1 )で書ける範囲 逆に、現時点で踏むと詰まる、もしくはsilent failになるのは次のような領域です。 require を前提とするコード（標準ライブラリの利用） eval を含むメタプログラミング 未対応メソッドに依存する処理（呼び出しがゼロ値返却に化ける） 「コンパイルが通ったから動いている」とは限らない、というのが現時点での最も大事な感触です。 CRubyとSpinelの両方で実行して出力をdiffする運用を組むのが安全です。 個人的所感 ローカル環境のlintやチェッカーなど今までワンライナーでやっていたことを置き換えて使ってみたいですね。 コンパイル済みのバイナリを配布できるのであれば環境構築の手間も減るかもしれません。 まだ少し触っただけですが、Spinelに可能性を感じています。また、こういうワクワクするものを提供してくれるMatzさんの凄さをあらためて実感します。 これから機能が拡充されていくのが楽しみです。 自分でもコントリビュートしていきたいですね。 おまけ: Spinelの由来 Rubyと同じく宝石つながりでSpinelなのかなあとはじめ思っていましたが、漫画アニメ『カードキャプターさくら』のスピネル・サン（スッピー）から名前をとっているそうです。 相棒はルビー・ムーンなのでここでもRubyに繋がってきますね。 由来聞いた時はそっちか〜〜！！となりました。かわいい。 おわり ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 Claude CodeのPluginを使うと、社内で育てたSkillやAgentを、組織のメンバーにまとめて配布できるようになります。ファインディでも、この仕組みでセルフレビュー用のSkillを開発組織全体に配り、各自がPull request作成前に呼び出す形で活用してきました。 この記事では、そこから さらに一歩踏み込んだ使い方として、PluginをGitHub Actionsから呼び出してCIで動かす 取り組みを紹介します。具体的には、Pluginに含まれるセルフレビューSkillをCIから定期実行し、指摘内容を反映したPull requestを自動で生成する仕組みです。 Pluginの使い方というと「Skillを社内で共有して、各自がローカルで叩く」という一面が語られがちですが、 同じPluginをCI基盤から起動する という選択肢をとると、Pluginで育てたSkillが個人の開発体験だけでなく、チーム全体のプロセスにも効いてきます。 PluginとセルフレビューのSkillについては次の記事を参照してください。 tech.findy.co.jp tech.findy.co.jp Pluginで配って各自に使ってもらう運用 PluginをCIから呼び出す 実際のWorkflowを読み解く トリガーとスコープ PluginをCIに引き込む 自動生成Pull requestにもCIを走らせるための GitHub App 1指摘1Pull requestに切り出す GitHub Actionsのmatrixを使って並列でPull requestを作る まとめ Pluginで配って各自に使ってもらう運用 まず、ファインディでのセルフレビューの流れを整理します。 社内の開発用Pluginには、セルフレビューSkillが含まれていて、Pull request作成前にローカルでPull request作成用のコマンドから呼び出されます。Pluginとして配布しているので、新しくジョインしたメンバーも、追加の手順なしに同じSkillを使える状態になっています。 このあたりの「Pluginで開発ナレッジを横展開する」話は、冒頭に貼った記事で詳しく紹介しているので、そちらをぜひご覧ください。 この運用は、個人の開発体験を底上げするうえで十分機能しています。この記事が公開された頃には実に1500個ものPull requestで実行されており、「最後の一押し」として働いてくれています。 PluginをCIから呼び出す この運用をベースに、 さらにもう一歩踏み込んで、同じPluginをCIからも呼び出してみる というのが本記事のテーマです。 PluginはSkillやSub Agentなどの集まりなので、 Pluginを参照できる実行環境さえ作れば、人間の代わりにCIから呼び出すこともできます 。普段ローカルで走っているものと同じSkillを、 anthropics/claude-code-action 経由でGitHub Actionsから起動すれば、Skillを再実装することなくCI化できるわけです。 github.com 本記事では、この考え方の一例として、セルフレビューSkillを定期実行し、指摘事項ごとに別々のPull requestを自動生成するWorkflowを取り上げます。対象にするのは、既存コードのうち長期間触られていないファイルです。人間のレビューでは目が届きにくい箇所に対して、機械がレビューすることで技術的負債の蓄積を抑えるというねらいがあります。 具体的に組み上げたWorkflowは、2つのjobで動きます。 指摘抽出 job ：Pluginのセルフレビュー用Skillを呼び出し、対象コードに対する指摘を抽出する。 修正Pull request作成 job（matrix） ：指摘の件数を matrix strategy に展開し、 指摘内容ごとに独立したjobを並列起動 。各jobは新しい runner 上で指摘内容を1件だけ修正したのち、PluginのPull request作成SkillでPull requestを作成 結果として、朝出社すると 改善Pull requestの候補が並んでいる 状態になりました。ローカルで個人が手動実行するSkillと、CIから定期実行されるSkillが、同じPluginの中身を共有している——これが、Pluginの使い方をもう一段広げてくれるポイントでした。 この仕組み自体はセルフレビュー専用のものというより、「PluginをCIから起動する」というパターンの1つの応用です。同じ構造で、様々なSkillをCIに組み込めます。 実際のWorkflowを読み解く まずは、今回組み上げたWorkflowの全体像です。PluginのSkillをCIから呼び出して指摘、Pull requestを並列生成するという流れを一通り確認できます。 name : Scheduled Self Review on : schedule : - cron : '0 19 * * 0-4' # 平日 JST 04:00（UTC 19:00 Sun-Thu） workflow_dispatch : env : SELF_REVIEW_MAX_FINDINGS : "3" jobs : # --------------------------------------------------------------------------- # Job 1: findings 抽出 # セルフレビューSkillで stale files をレビューし、 # 指摘を findings.json として artifact 化。matrix 展開用の index も出力。 # --------------------------------------------------------------------------- extract-findings : runs-on : ubuntu-latest timeout-minutes : 30 outputs : finding_indices : ${{ steps.compute-matrix.outputs.finding_indices }} findings_count : ${{ steps.compute-matrix.outputs.findings_count }} steps : - id : app-token uses : actions/create-github-app-token@fee1f7d63c2ff003460e3d139729b119787bc349 # v2.2.2 with : app-id : ${{ secrets.SELF_REVIEWER_APP_ID }} private-key : ${{ secrets.SELF_REVIEWER_APP_PRIVATE_KEY }} - uses : actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 with : token : ${{ steps.app-token.outputs.token }} fetch-depth : 0 - name : Compute stale file list run : | git log --since="1 month ago" --name-only --pretty=format : origin/main \ | grep -v '^$' | sort -u > .stale-recent.txt git ls-files | sort > .stale-all.txt comm -23 .stale-all.txt .stale-recent.txt > .stale-files.txt - name : Clone plugin repository run : | git clone https://x-access-token:${{ secrets.PLUGIN_REPO_READ_TOKEN }}@github.com/your-org/plugin-repo.git /tmp/plugin-repo - name : Extract findings via self-reviewer uses : anthropics/claude-code-action@4e5d8b13ca281a6d163cdb287d8917b216e00d6f # v1.0.103 with : anthropic_api_key : ${{ secrets.ANTHROPIC_API_KEY }} github_token : ${{ steps.app-token.outputs.token }} plugin_marketplaces : | /tmp/plugin-repo plugins : | example-dev-plugin@plugin-repo claude_args : >- --allowedTools Read --allowedTools Write --allowedTools "Skill(example-dev-plugin:<review-skill>)" --allowedTools "Skill(<review-skill>)" --allowedTools "Bash(cat:*)" --allowedTools "Bash(jq:*)" --allowedTools "Bash(gh pr list:*)" prompt : | .stale-files.txt に列挙された stale files を対象に、 セルフレビューSkillを呼び出して指摘を抽出し、 各指摘を 1 finding としてスキーマに従い findings.json に書き出せ。 コード修正・Pull request作成は行わない（後続 matrix job が担当）。 - id : compute-matrix run : | COUNT=$(jq length .self-review-findings.json) INDICES=$(jq -c 'to_entries | map(.key)' .self-review-findings.json) echo "findings_count=$COUNT" >> "$GITHUB_OUTPUT" echo "finding_indices=$INDICES" >> "$GITHUB_OUTPUT" - uses : actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1 if : steps.compute-matrix.outputs.findings_count != '0' with : name : self-review-findings path : .self-review-findings.json include-hidden-files : true # --------------------------------------------------------------------------- # Job 2: finding ごとに修正 + Pull request 作成（matrix で並列） # 各 matrix job は独立した runner で新規 checkout するため、 # worktree を使わずに済み、job 同士の編集衝突もそもそも発生しない。 # --------------------------------------------------------------------------- fix-per-finding : needs : extract-findings if : needs.extract-findings.outputs.findings_count != '0' runs-on : ubuntu-latest timeout-minutes : 40 strategy : fail-fast : false matrix : finding_index : ${{ fromJSON(needs.extract-findings.outputs.finding_indices) }} steps : - id : app-token uses : actions/create-github-app-token@fee1f7d63c2ff003460e3d139729b119787bc349 # v2.2.2 with : app-id : ${{ secrets.SELF_REVIEWER_APP_ID }} private-key : ${{ secrets.SELF_REVIEWER_APP_PRIVATE_KEY }} - uses : actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 with : token : ${{ steps.app-token.outputs.token }} - uses : actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0 with : name : self-review-findings - name : Extract single finding id : finding run : | FINDING=$(jq -c ".[${{ matrix.finding_index }}]" .self-review-findings.json) { echo "finding<<EOF" echo "$FINDING" echo "EOF" } >> "$GITHUB_OUTPUT" echo "branch=fix/self-review-$(date -u +%Y%m%d-%H%M)-${{ matrix.finding_index }}" >> "$GITHUB_OUTPUT" - name : Clone plugin repository run : | git clone https://x-access-token:${{ secrets.PLUGIN_REPO_READ_TOKEN }}@github.com/your-org/plugin-repo.git /tmp/plugin-repo - name : Fix finding and create Pull request uses : anthropics/claude-code-action@4e5d8b13ca281a6d163cdb287d8917b216e00d6f # v1.0.103 env : FINDING_JSON : ${{ steps.finding.outputs.finding }} FINDING_BRANCH : ${{ steps.finding.outputs.branch }} with : anthropic_api_key : ${{ secrets.ANTHROPIC_API_KEY }} github_token : ${{ steps.app-token.outputs.token }} plugin_marketplaces : | /tmp/plugin-repo plugins : | example-dev-plugin@plugin-repo claude_args : >- --allowedTools Read --allowedTools Edit --allowedTools "Skill(example-dev-plugin:<pr-skill>)" --allowedTools "Skill(example-dev-plugin:<review-skill>)" --allowedTools "Skill(<pr-skill>)" --allowedTools "Skill(<review-skill>)" --allowedTools "Bash(git switch:*)" --allowedTools "Bash(git commit:*)" --allowedTools "Bash(git push:*)" --allowedTools "Bash(gh pr create:*)" prompt : | $FINDING_JSON が担当 finding、$FINDING_BRANCH が担当ブランチ。 origin/main から $FINDING_BRANCH を切り、 affected_locations のみを Edit → PR作成Skill で Pull request を作成。 ここからは、このWorkflowを設計するうえでポイントになった箇所を取り上げて解説していきます。 トリガーとスコープ Pull requestではなく スケジュール をトリガーにしているのは、普段のPull requestで触る機会が少ないコードにも、同じSkillの観点を届けたいからです。 さらに対象ファイルは「直近1ヶ月以上変更されていないファイル（stale files）」に絞っています。最近の変更は通常のPull requestレビューで既にカバーされている前提で、それ以外の領域にフォーカスする設計です。 絞り込み自体は、 git log --since で直近の変更ファイル一覧を作り、 git ls-files と comm で差分を取るだけのシンプルな処理です。AIにリポジトリを丸ごと渡すと、コンテキストも費用も膨らむので、 「今効かせる価値がある範囲」に絞り込むための前処理を1段挟む のが運用上のコツでした。 PluginをCIに引き込む Workflow内では、社内Plugin配布リポジトリを都度cloneし、Claude Code Actionの plugin_marketplaces に渡しています。 ここで効いているのが、 Skillの実体をWorkflow側にコピーせず、Pluginからそのまま引き込む という構造です。Skillの改善はPlugin配布リポジトリにマージするだけで、自動的にすべてのリポジトリのCIに反映されます。ローカルで配っているSkillと同じものが、何のコピーもなしにCIで動く。これが、「Pluginで配るとローカルで使える」から「Pluginで配ったものがCIでも走る」への、ちょっとした発想の飛躍でした。 自動生成Pull requestにもCIを走らせるための GitHub App 地味に重要だったのが、 github_token にGitHub Appのinstallation tokenを渡している部分です。 なぜ GITHUB_TOKEN ではなくAppを使うのか。理由は、 GITHUB_TOKEN で作成されたPull requestはWorkflowを自動で発火させない というGitHub Actionsの仕様にあります。 自動生成されたPull requestに対しても、通常のPull requestと同じようにCIやセルフレビューのSkillを走らせたい。しかし GITHUB_TOKEN で作るとこれらが自動で発火しません。App token経由のPull requestはこの制約の対象外なので、「AIが生成したPull requestにも、人間のPull requestと同じCIが自動で実行される」状態を作れます。 「PluginのSkillをCIから走らせる」を本気で運用に乗せるなら、token戦略はワンセットで考える必要がありました。 1指摘1Pull requestに切り出す このWorkflowで考慮した設計判断の1つが、「見つかった複数の指摘を、1つのPull requestにまとめるか、1指摘1Pull requestに分けるか」です。 最終的に選んだのは、 指摘事項ごとに別々のPull requestに切り出す 方針でした。理由は次の通りです。 1つ目は レビュー観点の分離 です。1つのPull requestに複数の無関係な改善が混ざると、レビュアーが見るべき観点がまばらになってしまいます。「このリファクタは妥当だが、あちらは慎重に見たい」といった判断を、Pull request単位で切り分けられる状態にしたいというのが背景でした。 2つ目は revert単位の粒度 です。生成AIによる特定の変更が本番で不具合を起こした場合を想定すると、他の変更を巻き込まずに戻せるような粒度に保つのが安全であると考えました。1指摘1Pull requestであれば、revertひとつで該当の変更だけ元に戻せます。 3つ目は 依存関係なしにマージできること です。複数のPull requestを1本にまとめると、どれか1つがマージできないだけで全体がブロックされます。依存関係が少なくなるようにPull requestを分けておけば、マージできるものから順に処理できます。 代償として、レビュアーは「Pull requestの件数が増える」ことになります。ただし各Pull requestの変更量は小さく、観点も絞られているので、1本あたりのレビュー時間はむしろ短めになります。 GitHub Actionsのmatrixを使って並列でPull requestを作る 指摘ごとにPull requestを分ける前提に立つと、次は「どうやって並列で安全にPull requestを作るか」が論点になります。ここで採用したのが、 GitHub Actionsの matrix strategy による job 並列化です。 具体的には、job を2つに分けています。 最初の job（ extract-findings ）でセルフレビューSkillを走らせ、指摘内容をまとめる 後続 job（ fix-per-finding ）は、その指摘内容ごとに matrix に展開する。matrix の要素数ぶん、 独立した runner 上で並列に job が起動 する 各matrix job は、指摘内容を1件だけ取り出して修正して、PluginのPull request作成SkillでPull requestを作ります。 並列化でありがちな事故は、編集の衝突です。複数のエージェントが同じファイルを同時に触ると、どちらかの変更が失われます。今回はこれを、 matrix で分散した各 job が別 runner 上で独立に checkout する という構造で、そもそも発生しない形にしました。 strategy : fail-fast : false matrix : finding_index : ${{ fromJSON(needs.extract-findings.outputs.finding_indices) }} fail-fast: false にしているのは、1つのmatrix jobの修正が失敗しても他の matrix job を止めないため。AIが生成する修正は当たり外れがあるので、「一部が失敗しても残りは流す」という姿勢で運用するほうが現実的でした。 この構造で効いているのが、Pluginとして配布されているSkillの存在です。 extract-findings ではセルフレビューSkill、 fix-per-finding ではPull request作成Skillをそのまま呼び出すだけで、「レビューする→修正する→Pull requestを作る」という流れが組み上がります。 Pluginで配ったSkillが、CIの job 分割の単位とそのまま噛み合う 。これが、「Pluginで配ってローカルで使う」の一歩先にある使い方です。 まとめ Pluginで配ったSkillをGitHub Actionsにも載せたい場合に使えるポイントをまとめます。 Plugin配布用リポジトリをWorkflow内でcloneし、 plugin_marketplaces に渡す 。Skillの改善はPluginリポジトリへのマージだけで、ローカルにもCIにも同じ内容が反映される 自動生成Pull requestにもCIを回したいなら、 GITHUB_TOKEN ではなくGitHub App tokenを使う 。発火チェーン抑制の対象外になる 並列で動かすなら、GitHub Actionsの matrix strategy で job を分離する 。各 job は独立した runner で新規 checkout するので、編集衝突はそもそも発生しない Pluginで配ったSkillは、個人の開発体験を底上げするだけでなく、 CIに載せることでチーム全体のプロセスにも効いてくる 使い方ができます。「ローカルで配って使う」の次の一歩として、参考になればうれしいです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに こんにちは。プロダクト開発部 転職開発チームでエンジニアリングマネージャーをしている松村( @shakemurasan )です。 2026-04-22(水)から2026-04-24(金)までの3日間開催されているRubyKaigi 2026に現地参加しています。 rubykaigi.org この記事は、Day1 13:00-13:30のkoicさんのセッション『Exploring RuboCop with MCP』について、事前準備編と当日編（セッション当日に残したメモと感想）を1本にまとめたものです。 事前準備編にはAIによる予想が含まれるため、実際のセッション内容と一致するとは限らない点をあらかじめ断っておきます。 はじめに 事前準備編 koicさんの人となり AIに予想させてみたら、本人告知で焦点が絞れた 本人おすすめの教材とPRを少し覗いた 当日編 前半: MCP Ruby SDKとStreamable HTTP 後半: この1年間の試行錯誤 結びへ: 決定性と非決定性、そしてElicitation 聴き終えて腹落ちしたこと おわりに 事前準備編 koicさんの人となり koicさんはRuboCopのトップコミッターで、2025年にはMCPの公式Ruby SDK ( modelcontextprotocol/ruby-sdk ) のメンテナーにも加わっています。 github.com そこまでの道のりはFindy Engineer Labの取材記事『 365日欠かさずコミットを積む。なぜRuboCopコミッター伊藤浩一はOSSと向き合い続けるのか 』と、直近のお話はご本人のブログ『 MCPの公式Ruby SDKのメンテナーに加わった 』で詳しく綴られています。 findy-code.io koic.hatenablog.com 個人的な話をすれば、私がRubyを書き始めて数年の頃、地域のRubyコミュニティで何度かkoicさんをお見かけし、ジュニア時代の自分に刺激をくれた方の一人でもあります。 AIに予想させてみたら、本人告知で焦点が絞れた セッションタイトルだけでは論点が見えにくかったので、実は事前に予習の材料として、AIにkoicさんの直近のPRやIssueをもとに内容を予想させていました。 返ってきたのは大きく3通りの案でした。 1つ目は、stdio実装とMCP primitives（tools / resources / prompts）の写像を中心に据える構成。 2つ目は、MCPのtool annotationとRuboCopのCop属性の対応を核に据える構成。 3つ目は、Streamable HTTPを軸に据え、組織運用論にまで広げていく構成。 いずれもkoicさんの公開PRやIssueから拾えそうな筋ではあり、最初は「なるほどこのどれかだろうな」と眺めていました。 その後、koicさんご本人が『 RubyKaigi 2026に登壇します 』で背景と予習の案内をすでに公開されていることに気づきました。 koic.hatenablog.com 本人告知で軸に置かれていたのは「RubyツールチェインへのAI時代の課題提起」で、Streamable HTTPは副題として明示されていました。 一方で、tool / resource / promptといった「よく溢れている情報」は深掘りしない、とも明言されています。 AIの予想と本人告知を観点ごとにまとめると、次の通りです。 観点 AIの予想 本人告知 中心軸 RuboCop実装詳細 / MCP primitivesの写像 RubyツールチェインへのAI時代の課題提起 Streamable HTTP 1案の中心、他2案では末尾に触れる程度 副題として明示 、講演の大きなトピック tools / resources / prompts 写像の中心概念として扱う 「よく溢れている情報」として深掘りしない旨を明言 当たっていたのは「Streamable HTTPが主要トピックの1つ」と見立てていた点で、大きく外れたのは「tool / resource / promptを写像の中心概念として扱う」という方向性でした。 AIの予想は世に広く出回っている話題の重心に引っ張られやすく、本人が「あえて深掘りしない」と宣言していた領域こそがむしろ中心に置かれていた、というコントラストになります。 そのおかげで、当日聞きに行くべき焦点が一気に絞れました。 本人おすすめの教材とPRを少し覗いた 本人告知で紹介されていた教材のうち、RubyWorld Conference 2025でのkoicさんの登壇アーカイブに目を通しました。 「なぜstdioだけでは足りず、双方向のHTTP通信が必要なのか」という道筋が登壇の流れで追えるため、セッション前のウォームアップに助かりました。 当日編 本編は事前告知どおりの2部構成で、前半がMCP Ruby SDKの話、後半がRuboCop x MCPの話でした。 なお、当日のセッション資料は『 Exploring RuboCop with MCP 』としてすでに公開されています。 speakerdeck.com 以降は、現地で受け取った温度感の記録として読んでもらえればと思います。 前半: MCP Ruby SDKとStreamable HTTP Ruby SDKはもともとShopify社内で少人数のエンジニアが始めたもので、koicさん自身もRuboCopを念頭に早い段階から参画し、コミッターに招かれたのち、 mcp gemとして公開された、という経緯が紹介されました。 MCPにはTier1〜3のランクが定義 されていて、現在のRuby SDKはTier3。 Tier1を目指していく、と明確に宣言していました。 本題のtransportsの話では、規格としてstdioとStreamable HTTPの2つが並びます。 stdioの単純さはさらりと触れ、時間が割かれたのはStreamable HTTPのほうでした。 HTTPの規格のままで、WebSocketのような独自プロトコルに寄らずに双方向通信を成立させる。 実装はRackアプリケーションとして組んでおり、HTTPで叩かれたタイミングでMCPセッションIDを払い出してセッションを確立し、Queueを介してやり取りを何往復も成立させる。 1リクエスト1レスポンスではなく、1リクエストを起点にサーバー・クライアント間で通信が走る、という絵が丁寧に描かれていきます。 手を動かさないと実感が湧きにくい領域ですが、Rackの上に素直に乗っているという話を聞いた瞬間、普段触っているWeb技術の延長線上で捉えていい話なのだ、と急に距離が近く感じられました。 そして前半の締めでkoicさんが置いた次のようなニュアンスの一言が、個人的に一番刺さっています。 「AIになってガラッと変わったと思われるが、Linuxであるとか低レイヤの世界は何も変わっていなくて、我々はその上で開発をしているに過ぎない」 弊社でもたびたび話題に上がる「AIの台頭によりエンジニア自身にとってはむしろ基礎が大事になっていく」という考え方と一致しており、強く共感しました。 後半: この1年間の試行錯誤 後半はトーンが少し変わりました。 「1年間いろいろ試行錯誤してきたが、うまくいかなかったことが多かった。その話をします」とkoicさんが率直に切り出します。 成功譚ではなく、試行の経過と現在地の共有だ、というモードに切り替わりました。 最初のアイデアはシンプルで、RuboCopの結果をJSON構造でMCP化すればAIフレンドリーになって良いのではないか、というものでした。 しかし実際に手を動かしてみると、RuboCopはそもそも著名なgemなので、AI側もすでに相当学習していたように感じられた、と振り返ります。 わざわざMCPの皮を被せなくても、ある程度のことは既にできてしまう相手だった、ということです。 アイデアを広く募集して議論もしたものの、寄せられたものをそのまま実装して全員が喜ぶ機能になる自信は持てなかった、とも続きます。 結びへ: 決定性と非決定性、そしてElicitation そこから結びに向けて「RuboCopはこれまで、インプットに対して結果が一意に定まるものだった」と改めて位置づけ直されます。 「決定性こそがLinterとしての価値だった」という前提を言葉にしたうえで、そこに非決定性を持つLLMを組み合わせたら何ができるのか、と続きました。 具体例として並べられたのは、LLM側に委ねるSamplingと、ユーザーに聞き返すElicitationでした。 どちらもサーバーからクライアントに問い合わせを返せる仕組みですが、自分の耳に特に残ったのはElicitationのほうです。 ユーザーに対して定まったフォーマットの質問と回答フォームを返せる仕組みで、「この修正、どう進めたい？」と聞き返す余地をMCPの上で作れる、という話として置かれていました。 決定性のあるRuboCopの流れのなかに人間に問いを返すポイントを差し込み、そこを挟んだ非決定性を許容する。 決定性を捨てる話ではなく、どこで問いを立て、どこで非決定性を受け入れるかの設計の話として受け取りました。 この時私が思い出したのは、自チームでRuboCopのルール改廃を議論する時の話です。 一元的に適用するか悩ましいものが出てきたとき、その悩みには既存コードの暗黙的な規約、各エンジニアの思想や経験、copとして定義されているベストプラクティス、と様々な要素が絡んでいます。 これらは機械的に一意には定められないものです。 この統治過程にLLMが自然な形で介入し、対話を経てLinterに落とし込んでいくのはありそうな役割だと感じました。 (それをRuboCopの機能として提供されてユーザーが嬉しいかはさておき) ちなみにMCPの規格としてElicitationが発表された当時、弊社でも管理者向けのLocal MCP Serverにこれを組み込む事例があり、『 生成AI時代のサービス運営管理 - MCP Server for Administratorの実践 - 』（2025年9月16日公開）としてまとめられています。 tech.findy.co.jp 一方通行になりがちなMCPのやりとりに confirm / approveのステップを挟むという考え方は、koicさんが当日RuboCopの文脈で示したElicitationの位置づけとそのまま重なるものでした。 聴き終えて腹落ちしたこと 少なくともセッションの内容は「RuboCop x MCPのベストプラクティスがバシッと決まっている」わけではないということです。 むしろ、当事者として踏み抜いた人しか持ち得ない肌感を、苦労ごと公開してもらった30分だった、というのが近いと思います。 文字にするとシンプルですが、現場で聴講した皆さんにはkoicさんの試行錯誤と苦労が生々しく伝わっていたのではないかと思います。 現地参加する醍醐味をこういうところにも改めて感じました。 MCP化が思ったほど刺さらなかったこと、アイデアを集めても一意の答えに収束しないこと、Human in the Loopをどう設計するかが実装より先にあること。 どれも、ドキュメントや事例紹介を眺めていても掴めない、当事者として踏み抜かないと分からない種類の手触りです。 前半と後半を通して一本の線で繋がっていたのは、RubyツールチェインをAI時代にどう位置づけ直すかという問いだったように思います。 Streamable HTTPという具体的な技術基盤の話と、RuboCop x MCPという応用の試行錯誤、そして「低レイヤの世界は何も変わっていない」という立ち位置。 3つが重なって、Rubyのツール群とAIの関係をReframingする、という輪郭が浮かび上がる構成になっていたように私は感じました。 先頭に立ってこれだけの領域を踏み抜いてきたkoicさんへは、感謝と尊敬の気持ちでいっぱいです。 Ruby SDKへの貢献はRuboCop単体の話に留まらず、Rubyツール群全体が立つ足場を整える仕事なのだろう、と自分には受け取れました。 本セッションはAI時代にもRubyが最前線で使われる言語であり続けるための重要な歩みの1シーンを見せてくれたのだと改めて感じました。 おわりに AI時代だからといって銀の弾丸はなく、Rubyツールチェインも、HTTPやRackやQueueといった土台の上で地道に積まれていきます。 前半の締めの「低レイヤの世界は何も変わっていなくて、我々はその上で開発をしているに過ぎない」という言葉は、AIに振り回されずに使う側に回るのに必要なのは近道ではなく基礎だ、ということを改めて思い出させてくれました。 ファインディでは、一緒にRubyやRailsの開発をしてくれる仲間を募集しています。 興味のある方は、ぜひこちらからチェックしてみてください！ herp.careers

こんにちは。ファインディ株式会社でモバイルエンジニアをしている加藤です。 先日、「 React Native Lunch Talk ～いま選ばれる理由とアプリの現在地～ 」にて、「新規サービス開発におけるReact Nativeのリアル〜技術選定の裏側と実践的OSS活用〜」というテーマで登壇しました。 本記事は、その発表内容を改めてテックブログとして書き起こしたものです。 発表では時間の都合で駆け足になった部分や、質疑応答で答えきれなかった論点もあったため、本記事ではそのあたりも含めて踏み込んで書いています。 背景：Findy Events β版の開発 前回の記事 でも少し触れましたが、昨年、Findy初のモバイルアプリ「Findy Events」をα版としてAndroidアプリのみリリースしました。 現在はα版から得た学びをもとにUI・UXをフルリニューアルし、技術カンファレンス向けのiOS/Androidアプリとしてβ版のリリースを目指して開発を進めています。 Findy Eventsが長期的に目指しているのは、「カンファレンスでの学びとつながりを、その場限りで終わらせず継続的な成長の資産に変える」ことです。 β版では、その第一歩として、カンファレンス当日の体験をスムーズにする次のような機能を提供予定です。 QRコードを提示してのチェックイン 予約済みセッションやタイムテーブルなど、カンファレンス情報の閲覧 カンファレンス前日やセッション開始前に届くリマインダーPush通知 本記事では、そんな新規モバイルアプリの立ち上げにあたって、なぜReact Nativeを選ぶに至ったのか、そしてOSS選定や実装で直面したリアルな所感について紹介します。 前回の記事 では技術選定の結論だけを紹介しましたが、本記事ではその判断に至るまでの比較過程やOSS選定の裏側までを踏み込んで書いています。 背景：Findy Events β版の開発 React Nativeの技術選定の背景 OSSモジュールの選定と活用事例 独自選定の事例1：Sign in with Apple 独自選定の事例2：UIライブラリ React Nativeに対するリアルな所感 立ち上がりは、AI時代でも想像以上に苦労した OSS活用で感じたこと AI時代に、今からReact Nativeをやる意味 まとめ React Nativeの技術選定の背景 まず触れておきたいのは、「なぜ数ある選択肢の中からReact Nativeを選んだのか」という話です。 Findyにとって初のモバイルアプリ開発。しかも、技術選定を一から設計できる、エンジニア冥利に尽きる環境です。 ただ、自由度が高いということは、言い換えれば判断の重みも大きいということ。「モバイルアプリを開発する」と一言で言っても、その道筋はひとつではありません。 出発点として置いたのが、次の3つのアプローチの比較です。 最適な開発手法は、置かれた環境と考え方で変わる。これが私の基本スタンスです。 そして今回の前提は、「最小リソースで最速リリース」。この一点に照らして、まずCross Platformを選びました。 次に、Cross Platformの中から、国内外で実績が豊富なFlutterとReact Nativeの2つに絞って比較しました。 次の表は、iOSエンジニア出身である私の主観も踏まえて、2025年8月頃に整理したものです。 一見、表だけを見ればFlutterが優位に映ります。 正直なところ、私自身も最初はFlutterに馴染みを感じていました。 それでも最終的に選んだのは、React Nativeです。 決め手は、「組織のアセット」と「モバイルエンジニアとしての自身のナレッジ」の掛け算。この2軸をかけ合わせることこそ、「最小リソースで最速リリース」という目標に最短で近づく道だと確信しました。 仮にFlutterを選べば、私だけでなく将来参画するメンバー全員に一定の立ち上げコストがのしかかります。特にモバイルエンジニア出身でないメンバーほど、負担は大きい。 対してReact Nativeなら、ReactとTypeScriptの素養を持つメンバーが多い今の組織にそのまま馴染みます。 自分さえ立ち上がってしまえば、その後の開発速度は中長期的に最も出せる。これが最終的な決め手です。 具体的に、「組織のアセット」と「モバイルエンジニアとしての自身のナレッジ」についてですが、「組織のアセット」としては、 社内の優秀なWebフロントエンドエンジニアからReactやTypeScriptの知識提供、レビュー協力を得られる React製の既存プロダクトの設計思想やソースコードを参考にできる という期待感がありました。 また、「モバイルエンジニアとしての自身のナレッジ」として、 iOS/Androidのプラットフォーム特性への理解 プッシュ通知などのモバイル固有の課題への対応力 を活かすことができると考えていました。 「社内のWeb資産をどこまで活かすことができたのか？」という部分が気になる方もいらっしゃるかもしれません。結果としては、次の技術スタックのとおり、組織のアセットをフル活用することができました。 実は、アーキテクチャに関しても、既存のWebプロダクトをほぼ流用する形で開発しています。 つまり、設計思想や実装パターンまで踏み込んで参考にできるほど、React NativeはReactと親和性が高いということです。 OSSモジュールの選定と活用事例 続いて、OSSモジュールの選定についてです。 iOSエンジニア出身の私がReact Nativeに触れて最初に感じたのは、「とにかくOSSが豊富」ということ。 ただ、裏を返せば「多過ぎて、どれを選べば良いか迷う」という別の課題が立ち上がってきます。 そこで採った方針は、 Expo公式ドキュメント を「羅針盤」として活用すること。 Expo公式ドキュメントは非常に充実していて、Expo公式モジュールはもちろん、推奨される3rd Party OSSも明記されています。第一候補をここに置くだけで、選定コストは大きく圧縮できるというわけです。 もちろん、これで100%をカバーできるわけではありません。その場合は、プロダクトのコンテキストに合わせて独自に選びます。 ここからは、その独自選定した2つのOSSを紹介します。 独自選定の事例1：Sign in with Apple モバイルアプリの認証では、GitHub・Google・Appleの3つのOAuth認証を新規に導入する方針を採りました。中でもSign in with Appleは、iOSの審査要件として必須の機能です。 そこで選定軸に据えたのは次の2点です。 審査で認証ボタンのデザインも厳格に確認されるため、iOS SDK標準の ASAuthorizationAppleIDButton を内部で利用していること iOSだけでなくAndroidでもSign in with Apple機能を提供できること Expo公式には expo-apple-authentication があるものの、Androidが対象外。今回は見送りました。 最終的に選んだのは、両OSに対応した react-native-apple-authentication です。 独自選定の事例2：UIライブラリ 冒頭で述べた通り、自社初のモバイルアプリということもあり、社内にモバイル用のデザイン資産はありません。「最小リソースで最速リリース」を実現するには、UIライブラリの活用が欠かせない要素になります。 選定軸に据えたのは次の2点です。 豊富なUIコンポーネントが提供されていること iOSエンジニア出身の自分にとって、学習コストが高すぎないこと 実はα版では Tamagui を採用していました。ただ、β版でUI・UXをフルリニューアルすることが決まり、より要件に合致するライブラリを改めて探すことに。 たどり着いたのが、選定軸2点をしっかり満たす HeroUI Native です。 ここで一つ頭を悩ませたのが、採用を決めた当時（2026年1〜2月頃）のHeroUI Nativeがまだβ版だったこと。利用によって課題が顕在化するリスクを抱えての判断になります（※現在はstable版が提供されています）。 そこで採った工夫が、「HeroUI NativeのWrapper Componentを実装し、画面側からは直接HeroUI Nativeに触れない構成」にすること。 影響範囲をWrapper層に閉じ込めておけば、将来の差し替えや仕様変更への耐性が確保できる。β版OSSを採用する際のリスクヘッジとして、有効な型の一つだと感じています。 React Nativeに対するリアルな所感 立ち上がりは、AI時代でも想像以上に苦労した React Nativeを選んだ結果として率直に感じたのは、「AI時代と言えど立ち上がりにはそれなりに苦労した」ということ。 実は10年ほど前に少しだけReactに触れたことがあったのですが、React HooksやLifecycleに相当する考え方はほぼ初学者の状態。概念の再学習が必要でした。 また、TypeScriptも「Swiftと似て非なるもの」であることを痛感します。 型による安全性という思想は近いものの、 as によるキャストや enum がベストプラクティスとしては非推奨とされている点など、Swift感覚で書くと足をすくわれる場面が少なくありません。 一方で、React Native自体に対するハードルはそれほど感じません。理由は次の2つです。 宣言的UIによるUI構築は、SwiftUIで経験していた プッシュ通知など、モバイル固有機能の仕組みそのものを理解していた LT会では「どうやってReact Nativeを勉強したか？」という質問もいただきました。取ったアプローチは、過去にSwiftで開発していた個人アプリをReact Nativeで書き直してみるというもの。 題材を一から考えずに済む上に、Swift版という答え合わせの対象がある状態で進められるため、SwiftUIとの共通点や差分を体感しながら学べます。 こうして実感できたのは、React Nativeを選んでも、モバイルエンジニアとしての経験や強みは十分に活かせるということです。 OSS活用で感じたこと OSS活用の面でも、幾つか印象的な気付きがあります。 1つは、OSSの更新速度の速さです。 React / React Native界隈は更新サイクルが早く、iOS Nativeとの文化の違いを肌で感じます。 加えて、脆弱性検知などのエコシステムが整っており、開発者体験として足かせになっていない点も心強いところです。 もう1つは、Expoの利便性への驚きです。 ExpoはReact Native界隈ではデファクトスタンダードと言える立場を確立しており、信頼性も高く、証明書やリリース周りといった「モバイルアプリ開発ならでは」の知識を手厚くカバーしてくれます。 これは、Webフロントエンドエンジニアがモバイルアプリ開発に参入するハードルを相当下げていると言って良いでしょう。 実際、Webフロントエンドエンジニアの方から「React Nativeって実際どうなの？」と聞かれた際は、Expoのおかげで「モバイルアプリ開発は想像以上に始めやすい」と答えることができています。 AI時代に、今からReact Nativeをやる意味 最後に登壇の中では時間の都合で踏み込めなかった論点について書いておきます。 それは、「AI時代に、今からReact Nativeをやることに意味はあるのか？」という問いです。 個人的には、少なくとも次の3点で意味があると考えています。 1つ目は、iOSとAndroidを同時に立ち上げる中で、OS間の差分に向き合う経験が積めることです。 Cross Platformと言えど、プッシュ通知や認証、OSの作法といった領域では差分が必ず顔を出します。 AIに任せれば書ける時代だからこそ、差分の勘所を自分の中に持っているかどうかが効いてくると考えています。 2つ目は、アーキテクチャ選定やOSS選定といった、プロダクトの土台を作る判断を経験できることです。 ゼロからモバイルアプリを立ち上げる機会はそう多くなく、「何を選んで、何を選ばなかったか」を自分の言葉で語れるようになる経験は、AI時代でも色褪せにくい資産だと感じています。 3つ目は、Webフロントエンドへの足掛かりになることです。 React NativeでReactやTypeScriptを書いている時間は、そのままWebフロントエンドの学習コストを前払いしていると言えるかもしれません。 そのため、モバイルエンジニアとしてWebフロントエンドへ領域を広げたい人にとって、React Nativeは自然な入り口になると思います。 （もちろん、Webフロントエンドエンジニアとして、モバイルアプリへ領域を広げたい人にとっても同様です。） まとめ Findy初のモバイルアプリ開発を通じて、React NativeやOSSの選定と実装で多くの知見を得ることができました。 初めは慣れないReact Nativeに四苦八苦することもありましたが、一度慣れてしまえば、モバイルエンジニアとしての強みを存分に活かすことができると実感しました。 AI時代においては、人がガードレールとしてソフトウェアの責任を背負う場面がますます増えていきます。 その観点で見ても、React Nativeは「AI時代に、人が責任を取れる技術」として十分に選定に耐えうると考えています。 モバイルアプリの技術選定に迷っている方や、iOS/Androidの経験を活かしてReact Nativeに踏み出そうとしている方は、ぜひ一度触ってみてください。 本記事がその一歩を踏み出すきっかけになれば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 「AI活用を推進したいが、思うように進まない」──この悩みを抱えているエンジニアの方は、少なくないのではないでしょうか。 ファインディも例外ではありませんでした。2025年の上半期までは、普段の業務をやりつつ片手間でAIのキャッチアップや社内展開を進めていました。 今回は、そこから潮目が変わるきっかけとなった決断と、その後1人あたりのプルリクエスト作成数が前年比で約1.5倍になるまでの過程を紹介します。 同じようにAI活用の推進に手応えのなさを感じている方の参考になれば幸いです。 片手間で追いかける限界 1つの小さな決断 最初にやったこと：Findy Team+で現状を知る Claude Code Pluginsで展開を仕組み化する 継続的な浸透：毎日の通知と月一の共有 結果：PR作成数が前年比で約1.5倍に 振り返って気づいたこと まとめ 片手間で追いかける限界 2025年の上半期まで、ファインディの開発組織では興味と意欲のあるエンジニアが、普段のプロダクト開発と並行して、最新の動向をキャッチアップし、使えそうなツールを社内で共有していました。いわゆる"片手間"で進めるスタイルです。 最初のうちは、これでも回っていました。しかし、次第にこのやり方では追いつかなくなっていきました。 理由は単純で、 AIのアップデートが多すぎた からです。 ほぼ毎日のようにアップデートが公開され、新しいエージェントや機能が登場する。上半期の半ばあたりから、キャッチアップに充てる時間がどうしても足りないという感覚が強くなっていきました。 努力で巻き返せるレベルの遅れではなく、物量的に両立が不可能な状態に近づいていました。 1つの小さな決断 この状況を動かすために取った1つの決断が、 「AI推進だけを専任で担うポジションを作る」 というものでした。 その人を普段のプロダクト開発業務から外し、AI推進そのものを業務にする。兼務で時間を増やすのではなく、業務から外して全振りするという発想への切り替えが、このポジションの本質です。 この判断の背景には、 「全員が業務の10%をAI推進に充てるよりも、1人が100%を充てたほうが組織としての前進量は大きい」 という確信がありました。 兼務スタイルで各自が少しずつ動く形では、日々のAIアップデートの速度には追いつかない。仮に追いついたとしても、それらを使ってアウトカムを出せるまでが遠すぎました。一方、1人が専任で全力でコミットできれば、情報の集約・検証・社内展開を最速のスピードで回せると判断しました。 AI推進ポジションのエンジニアの仕事は、AI活用と組織への展開そのもの。日々のプロダクト開発タスクは原則持たず、AI関連の動向調査・検証・社内展開・仕組み化に集中してもらう形にしました。 プロダクト開発の手を減らすことに対しては、当然ながら社内でも葛藤がありました。それでも踏み切れたのは、片手間で続けていた半年間を通して、兼務では絶対に追いつかないという確信があったからです。 最初にやったこと：Findy Team+で現状を知る 専任ポジションを置いてから最初に取り組んだのは、派手な施策やスキル作成などではなく現状把握でした。 組織全体のAI活用を推進するといっても、感覚だけで動くと認識のギャップが生まれます。そこで、Findy Team+を使ってチーム単位・メンバー単位でAI活用の度合いを可視化するところから始めました。 ここでわかったのは、想定していたよりAIの恩恵を受けられていない、という事実でした。 もう少し掘り下げると、チームや事業部ごとにAIの活用度合いに明確な差があり、同じ役割のエンジニアでも使っているスキル・エージェントにばらつきがあることが見えてきました。よく使えている人の工夫が、他のメンバーに自然には伝わっていない状態です。 組織として全員で底上げされているのではなく、一部の熱量の高いメンバーが先行している状態だった、というのが当時の姿でした。 Claude Code Pluginsで展開を仕組み化する 現状把握でわかったスキル・エージェントのばらつきを埋めるために選んだ打ち手が、Claude CodeのPlugins機能を使った社内展開です。 Plugins機能については以前の記事でも紹介しています。 tech.findy.co.jp Claude CodeのPluginsは、スキル・エージェント・カスタムコマンド・各種設定などを1つのパッケージとして配布できる仕組みです。AI推進のエンジニアが作成した開発用スキルなどをプラグインとしてインストール可能にしておけば、各メンバーが自分の環境でコマンド1つで使える状態になります。 この仕組みに乗せることで、便利なコマンドや開発標準化のスキルなどをそのまま開発組織全体に配布できるようになりました。新しく入ったメンバーも初日からファインディのAI活用の恩恵を受けられるようになっています。 実際に、ファインディの開発組織で運用しているスキル・エージェントの一部は、次の記事でも紹介しています。 tech.findy.co.jp tech.findy.co.jp tech.findy.co.jp いずれも個人の工夫として始まったものを、プラグイン化して全員に配布できる形にしたものです。 継続的な浸透：毎日の通知と月一の共有 プラグインを配布するところまで作っても、更新を知ってもらえなければ次第に忘れられてしまいます。そこでファインディでは、配布の仕組みに加えて、更新が自然と目に入る状態を保つ工夫を並行して走らせています。 1つ目は、プラグインの更新内容をSlackの専用チャンネルに毎日通知する仕組みです。新しく追加されたスキルや、アップデートされたコマンドが翌日には目に入る状態にしておくことで、いつの間にか変わっていたではなく、今日こんな機能が追加されたという鮮度で情報が流通します。 2つ目は、月一のエンジニア定例のなかに、プラグインやAI活用の使い方を共有する時間を設けたことです。ドキュメントだけでは掴みきれないニュアンスやちょっとしたコツを口頭で流す場として、思った以上に機能しています。 プラグインという土台に加えて、通知と定例という継続的な露出。この組み合わせが、AI活用を一部のメンバーだけで閉じさせず、組織全体に浸透させる力になっています。 結果：PR作成数が前年比で約1.5倍に こうした取り組みを進めた結果、 1人あたりのプルリクエスト作成数は前年比で約1.5倍 になりました。 AI活用が進んだ実感というあいまいな言葉ではなく、開発のアウトプットそのものが定量的に伸びた、というのが大きなポイントです。 もちろん、プルリクエスト作成数は開発の速度やスタイルの指標の1つに過ぎません。それでも、組織としての変化が数字として見える状態になったこと自体が、AI活用のどこに投資すべきかを議論する大きな土台になりました。 振り返って気づいたこと 半年ほど取り組んで気づいたのは、専任を置いたから任せきる、では成り立たないということです。 専任1人ですべてを背負う構造にすると、その人自身がボトルネックとなってしまいます。専任の役割は、自分がすべてを実行することではなく、組織のAI活用を前に進めるための仕組みをつくること。 現場のエンジニア・マネージャーが自走するための土台を整え、みんなで良くしていくというスタンスが重要だと感じました。 まとめ ファインディのAI活用推進は、特別なツールや大がかりな制度改革ではなく、「AI推進だけを専任で担うポジションを作る」というシンプルで小さな意思決定から加速しました。 そこから専任が取り組んだのは、Findy Team+を使った現状把握、Claude Code Pluginsを使ったスキル・エージェントの社内展開、そしてSlack通知と月一定例による継続的な浸透。 いずれも派手さはありませんが、これらの積み重ねによって、1人あたりのプルリクエスト作成数が前年比で約1.5倍になるまでの変化を生み出すことができました。 AI活用は一日にして成らず。小さな意思決定や地道な取り組みの積み重ねが、組織全体の大きな変化につながることを実感しています。 全員が10%ずつAI推進に充てるよりも、1人が100%を充てる。この発想の転換が、ファインディのAI活用を動かす原動力になっています。 AI活用が思うように進まないと感じている組織の責任者の方がいれば、制度や研修を考える前に、専任を置く（業務から外す）という選択肢を検討してみてください。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 ファインディではClaude CodeのスキルやカスタムコマンドなどをPlugins経由で社内展開しています。 tech.findy.co.jp コードレビューやタスク分解といった開発業務の効率化が進む一方で、登壇準備はまだ手作業の割合が大きい領域です。話す内容を固めて、構成を考えて、スライドに落とし込んで、デザインを整えて……。発表の本質は「何を伝えるか」なのに、準備工程に時間を奪われがちです。 本記事では、この課題に対処するために社内Pluginsに作った登壇スライド生成スキルを紹介します。壁打ちによるコアメッセージの言語化からMarkdownスライド生成、Google Slidesへのエクスポートまでを一気通貫で行えるもので、壁打ちから完成まで30分で終わるようになりました。 登壇準備にかかる時間の内訳 NotebookLMを試して感じた限界 Claude Codeスキルという選択肢 ワークフローの全体像 壁打ちフェーズ：コアメッセージの言語化 テンプレート設計：発表時間から逆算するスライド枚数 Google Slides API テンプレートコピー方式 Markdownからスライドへの変換ルール デザインガイドラインの組み込み 70点の完成度で出す割り切り まとめ 登壇準備にかかる時間の内訳 登壇準備のどこに時間がかかっているかを振り返ると、スライドのデザインや配置よりも、その手前の工程が大きいことに気づきます。 前半は「何を話すか」の整理です。話したいことはぼんやりあるけれど、コアメッセージを一文にまとめるのが難しい。構成を決めても「この流れで聴衆に伝わるか？」と不安になって何度も組み替える。ここが一番時間を食います。 後半はスライドの作成とリハーサルです。ようやく構成が固まっても、今度はスライドツールを開いてフォーマットやデザインと格闘する。前半さえ効率化できれば、発表内容そのものの質を上げる時間に使えるはずだと考えました。 NotebookLMを試して感じた限界 最初に試したのはGoogleのNotebookLMでした。ソース資料を読み込ませてスライドを生成できる機能があり、期待して使ってみました。 ただ、実際に使ってみるといくつか壁がありました。出力がPDFや画像形式のため、生成後の編集が難しい点です。スライドの順番を入れ替えたい、テキストを修正したいといった基本的な操作ができず、結局ゼロから作り直す羽目になりました。 もう一つは、社内のスライドガイドラインに沿った出力が非常に難しかったことです。フォントやカラースキーム、ロゴの配置などは組織ごとにルールがあります。汎用的なAIツールではそこまで制御できず、ガイドラインに準拠させるための手作業が発生していました。 Claude Codeスキルという選択肢 これらの課題を踏まえて、Claude Codeのカスタムスキルとして登壇スライド生成ワークフローを自作しました。Claude Codeスキルを選んだ理由は、対話的なワークフローを自然に組めること、Markdownで中間出力できること、そしてAPIを叩いて外部サービスに連携できることの3点です。 開発したのは2つのスキルです。1つ目がMarkdownスライドの生成、2つ目がGoogle Slidesへの変換を担います。 ワークフローの全体像 スキルを実行すると、次の流れで処理が進みます。 参考URLやコードスニペットの収集（任意） 壁打ちでコアメッセージを言語化 タイトル・概要・発表時間の入力 テンプレートに基づく構成設計 Markdownスライドの生成 Google Slidesへのエクスポート（任意） 各フェーズを詳しく見ていきます。 壁打ちフェーズ：コアメッセージの言語化 このスキルで最も力を入れたのが壁打ちフェーズです。登壇準備で一番時間がかかるのは「何を伝えるか」を固める工程だからです。 スキルを起動すると、まず対象オーディエンス（テックリード、シニアエンジニア、EMなど）を選択します。次に「発表内容はすでに決まっていますか？」と聞かれ、「まだ漠然としている」を選ぶと壁打ちモードに入ります。 ? スライドに取り込みたいURLやコードスニペットはありますか？（任意） > なし ? 対象オーディエンスを教えてください（複数選択可） エンジニア系: ✔ テックリード ✔ シニアエンジニア マネジメント系: ✔ EM ? 発表内容はすでに決まっていますか？ > まだ漠然としている（一緒に考えたい） どんな発表をしたいですか？テーマや話したいこと、伝えたいことを 自由に教えてください。まだ漠然としていても大丈夫です。 壁打ちは次の順序で進みます。 コアメッセージの確定 — 「この発表で一番伝えたいこと」を1文に絞る 逆算による構成設計 — コアメッセージを結論として、聴衆が納得するために必要な情報を逆順に積み上げる タイトル・概要の決定 — 構成が固まった後に、コアメッセージが伝わるタイトルを考える ポイントは「逆算」というアプローチです。結論から遡って構成を組むことで、「話したいことを全部詰め込んだけど結局何が言いたいのかわからない」というよくある失敗を防ぎます。 実際のやり取りはこんな感じです。 > 生成AI時代のエンジニア育成について話したいんですけど、 まだ切り口が定まってなくて エンジニア育成×生成AIですね。テックリードやEM向けなので、 現場のリアルな課題感が求められます。 AI導入後に育成面で一番変化を感じたのはどこですか？ 学習速度、コードの質、それともチームの生産性でしょうか？ > AI導入後にシニアの生産性は上がったんですが、 若手のアウトプットの質がむしろ落ちていて。 AIの出力をそのまま使ってしまって、理解が追いついてない感じです なぜAIの出力をそのまま使ってしまい、理解が追いついていないと感じていますか？ > AIが出力したコードを理解せずにレビュー依頼するケースが増えていて、 結果的にリードタイムが悪化していることはわかった。 AI時代の今だからこそ原点回帰が必要。 なるほど。つまり「生成AI時代だからこそエンジニアの基礎力の価値が 上がっている。AIを"使う"側に立つには原点回帰が必要。」 ということを一番伝えたい、という理解で合っていますか？ > はい Claudeがコアメッセージを1文に言語化してくれるので、対話で壁打ちを進められます。コアメッセージが確定すると、逆算で構成を組んだうえでまとめを提示してくれます。 壁打ちの結果をまとめました！ タイトル案: 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト 概要: 生成AIの導入でシニアの生産性は上がったが、若手のアウトプットの 質は低下していた。AIが出力したコードを理解せずにレビュー依頼する ケースが増え、結果的にリードタイムが悪化。基礎知識なきAI活用は 「AIに使われている」状態であり、今こそ原点回帰が必要だと気づいた 実体験を共有する。 コアメッセージ: 生成AI時代だからこそエンジニアの基礎力の価値が 上がっている。AIを"使う"側に立つには原点回帰が必要。 ? このまとめでスライド生成に進みますか？ > 進む テンプレート設計：発表時間から逆算するスライド枚数 スキルには3種類のテンプレートを用意しました。 standard — 20〜60分のカンファレンストーク向け。背景→本題→デモ→まとめの王道構成 lt — 5〜10分のLightning Talk向け。「結論ファースト」で1点突破 tutorial — 30〜40分のハンズオン向け。手順ごとに検証ステップを挟む 発表時間を選ぶと、テンプレートが自動選択されます。5分や10分ならLTテンプレート、15〜20分ならstandard、30分以上でハンズオン形式ならtutorialです。 スライド枚数は「1分1枚」を基準に算出しています。20分の発表なら15〜20枚。セクションごとの配分は、背景10〜15%、メインコンテンツ50〜60%、デモ15〜20%、まとめ・Q&Aで残りという割合で自動配分されます。 ? 発表時間を選択してください > 20分 テンプレート: standard（カンファレンストーク向け）を自動選択しました 目標スライド枚数: 15〜20枚 構成を設計しています... ? スライドに取り込みたいURLやコードスニペットはありますか？（任意） > https://tech.findy.co.jp/entry/2026/02/20/070000 URLの内容を取得しています... ✓ 取得完了: https://tech.findy.co.jp/entry/2026/02/20/070000 → 要点を抽出し、背景・メインコンテンツのセクションに反映します → 参考資料スライドにリンクを追加します Google Slides API Markdownで生成したスライドをGoogle Slidesに変換するスキルも開発しました。Google Slides APIを実行しており、OAuth2認証でユーザーのGoogleアカウントに紐づけています。 developers.google.com ? Google Slidesにエクスポートしますか？ > エクスポートする Google Slidesにエクスポートしています... ✓ エクスポートが完了しました URL: https://docs.google.com/presentation/d/1abc.../edit テンプレートコピー方式 今回は会社のスライドマスター（テンプレート）をGoogle Drive API経由でコピーし、そこにスライドを追加していく方式を採用しました。テンプレートには表紙・中扉・詳細ページのレイアウトが定義されており、Markdownの見出しレベルに応じて適切なレイアウトを選択します。 Markdownからスライドへの変換ルール Markdownのパース結果は、見出しレベルとボディの有無でスライドの種類を自動分類しています。 Markdownのパターン スライドの種類 デザイン # タイトル 表紙 背景画像あり ## 見出し + 本文あり 詳細ページ 背景画像あり ## 見出し のみ（本文なし） セクション区切り グレー背景 + 白文字 ## の中に ### の小見出しが含まれる場合は、自動的にセクション区切り1枚 + 小見出しごとの詳細ページに展開します。たとえば「AI時代の到来と変化」の下に「変わったこと」「変わらなかったこと」の2つの ### があれば、計3枚のスライドに分割されます。 デザインガイドラインの組み込み 会社指定のスライドガイドラインをスキルの定義ファイルに直接記述しています。フォントやカラーパレット、サイズといったルールをスキルの中で持ち、エクスポート時に各要素に適用します。 70点の完成度で出す割り切り 運用上、重要にしているのは「70点の完成度で一発出力し、残りは人間が仕上げる」という割り切りです。 AIが100点のスライドを作るのは現状難しいですし、目指す必要もないと考えています。スライドの完成度を70点から100点にするのは人間の感性が必要な部分です。逆に、0点から70点の工程（構成決め、テキスト配置、フォーマット統一）はAIの得意分野です。 この分業により最速で「壁打ち15分 + スライド生成5分 + 手動調整10分 = 30分」で登壇準備が完了するようになりました。 まとめ 今回紹介したスキルで作成されたスライドがこちらです。 登壇準備の工程をClaude Codeスキルで一気通貫にしたことで、壁打ちから完成まで30分程度で終わりました。 このスキルの価値は「スライドを自動生成すること」自体ではなく、「コアメッセージの言語化を対話で支援すること」にある点です。登壇準備で本当に時間がかかるのは構成やデザインではなく、「自分が何を伝えたいか」を整理する工程だったのだと、スキルを開発する過程で改めて実感しました。 登壇の機会があるエンジニアの方は、ぜひ挑戦してみてください。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。ファインディ株式会社でテックリードマネージャーをしている戸田です。 2026年4月15日に、Findy AI Meetup in Fukuoka #5を福岡で開催しました。 今回のテーマは「AI×育成 AI時代のエンジニア育成」です。 この記事では、当日の登壇内容を振り返りながら、生成AI時代におけるエンジニア育成で私たちが直面した課題と、そこから見えてきた「変わらない大切なこと」を紹介します。 https://findy-inc.connpass.com/event/383906/ findy-inc.connpass.com 当日参加くださったみなさま、ありがとうございました！ Findy AI Meetup in Fukuokaについて 登壇内容 新メンバーのために、シニアエンジニアが環境を作る時代 エンジニア以外のメンバーがPull requestを作るようになった Pull requestの品質が課題に AI時代のシニアエンジニアができること 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト 生成AIでコードの作り方が変わった 現場で起きた逆説 AIに「使われる」のではなく「使う」 原点回帰 — 基礎力の価値が上がっている 明日から試せるアクション AIの出力を必ず検証する習慣をつける 基礎知識を体系的にインプットする 「AIに聞く前に公式ドキュメントを読む」時間を意識的に作る チームの開発ルールをエージェントスキルやカスタムインストラクションに落とし込む まとめ Findy AI Meetup in Fukuokaについて Findy AI Meetupは、ファインディのエンジニアが主催する技術系オフラインイベントです。 生成AIやAIエージェントの活用を通じた開発生産性の向上をテーマに、社内での実践事例の紹介やエンジニア同士の交流を目的としています。 福岡での開催は今回で5回目となりました。回を重ねるごとに参加者同士の顔なじみも増え、福岡のエンジニアコミュニティとして根付いてきたことを実感しています。 登壇内容 新メンバーのために、シニアエンジニアが環境を作る時代 1つ目の登壇は、フロントエンドエンジニア/テックリードの新福が担当しました。 エンジニア以外のメンバーがPull requestを作るようになった 生成AIの普及により、エンジニア以外のメンバーでもコードを書けるようになりました。 ファインディでは、デザイナーがClaude Codeを使ってUIドキュメントを作成したり、PdMがCursorでモックを作成するといった事例を確認しています。 直近では、エンジニアがBizメンバー向けにNotion MCPを用いた求人票改善ツールを開発しました。 tech.findy.co.jp 実はこの話にはまだ続きがあります。しばらくすると、今度はBizメンバーが自分でプロンプトを修正し、エンジニアにPull requestを送るようになったのです。 コミットやPull requestの作り方を誰かに教わったわけではありません。AIチャットに聞きながら操作し、Pull requestを作り上げていました。AIチャットが開発の入口となる時代、その波は既にエンジニア以外のメンバーにも届いています。 Pull requestの品質が課題に 一方で、コミットメッセージのフォーマットや命名規則など、開発ルールを知らないまま作られたPull requestには品質面での課題がありました。レビュアーの負担が増え、指摘のたびに手戻りが発生するような事態は避けたいです。 この解決策としては、エージェントスキルの整備が有効と考えられます。 AIチャットから自然言語でエージェントスキルを呼び出すだけで、誰でも開発ルールに準拠したPull requestを作成できます。 AI時代のシニアエンジニアができること シニアエンジニアはこれまで、知識を言語化して伝えること、コードレビューによる品質担保、ペアプロでの指導といった形で、チームの品質と成長を支えてきました。 これらの役割は引き続き重要ですが、AI時代はそれに加えてカスタムインストラクションやエージェントスキルの整備などもシニアエンジニアの仕事になると思われます。 誰でも参加できる仕組みを作ることは、教える相手を選ばない育成インフラの構築につながります。入社1週目の新メンバーが初日からコントリビューションを体験し、「何を作りたいか」に集中できる環境を整えること——それがAI時代のシニアエンジニアの新しい役割となるかもしれません。 生成AI時代のエンジニア育成 — 変わる時代と変わらないコト 次にテックリードマネージャーの戸田が担当しました。 生成AIでコードの作り方が変わった 生成AIの登場によって、開発の進め方は大きく変わりました。「調べる→試す」だったプロセスが「AIに聞く→コピペ」に変わり、詰まる時間は激減しました。 基本的な知識がなくても動くコードが手軽に出せるようになった一方で、公式ドキュメントよりAIへの問い合わせが先になりがちで、「なぜ動くのか」を知らずに実装する機会が増えていました。 現場で起きた逆説 AI導入後、シニアエンジニアのアウトプット量は増えていました。しかし若手エンジニアについては逆の現象が起きていました。 Pull requestの質が落ち、AIが出力したコードを理解せずにレビュー依頼を出すケースが増えたのです。その結果レビューコメントが増え、レビュー負担が上昇し、リードタイムは悪化していました。 トータルで見ると、チーム全体の生産性はさほど変わっていなかったのです。「AIで効率化できた」という実感とのギャップがそこにはありました。 AIに「使われる」のではなく「使う」 この状況を整理すると、若手エンジニアの一部はAIに「使われている」状態でした。 AIが出力したコードが正しいかどうかを判断できず、間違いに気づかないままレビューを依頼する。ハルシネーションを見抜けず、誤った実装をしてしまう。AIに正しい指示を出せないから「作ってください」としか言えず、意図と異なるコードが出てくる。 「使う」状態はその逆です。自分の意図に沿ってAIを動かせる。正誤を判断できるから間違いをその場で弾ける。正しい指示が出せるから意図通りの出力が得られる。 この違いを分けるのは、エンジニアとしての基礎力です。 基礎知識がなければ、正誤判定も正しい指示もできません。動くものを作るレベルは「AIに使われている」状態であり、正しい方法と手順で作るレベルが「AIを使う」状態です。 原点回帰 — 基礎力の価値が上がっている 生成AI時代だからこそ、基礎力の価値はむしろ上がっています。基礎知識、座学、資格取得といった、一見すると地味な取り組みが重要性を増しているのです。 ファインディでは、基本情報技術者試験相当以上の資格を取得することを推奨しています。広く浅い基礎知識を体系的に習得できるという点で、コスパもタイパも高い学習方法です。合格した場合は受験料を会社が負担する制度も用意しています。 基礎力がつくとAIの出力に対する正誤判定の質とスピードが上がり、レビュー前のセルフチェックで問題を潰せるようになります。ハルシネーションを見抜けるようになり、「何かおかしい」と気づける感覚が身に付きます。 さらに、AIに正しい方法と手順で指示を出せるようになるため、レビューでの議論が設計やパフォーマンス、UI/UXといった本質的な内容になります。 今回の登壇と資料が皆さんの参考になると幸いです。 ■ 明日から試せるアクション ■ 明日から試せるアクション 登壇内容を踏まえて、明日から実践できることを整理しました。 AIの出力を必ず検証する習慣をつける AIが生成したコードをそのままコピペするのではなく、「このコードは何をしているか」「なぜこの実装なのか」を自分の言葉で説明できるか確認してからレビューに出しましょう。説明できないコードはレビューに出すべきではありません。 基礎知識を体系的にインプットする 基本情報技術者試験の教材は、ネットワーク、データベース、セキュリティ、アルゴリズムなど、開発の土台となる知識を広くカバーしています。資格取得そのものが目的ではなく、AIの出力を正しく評価するための「物差し」を手に入れることが目的です。 「AIに聞く前に公式ドキュメントを読む」時間を意識的に作る すべてをAI経由にするのではなく、まず公式ドキュメントで基本を理解したうえでAIを活用する、という順序を意識するだけで、コードの理解度は大きく変わります。 チームの開発ルールをエージェントスキルやカスタムインストラクションに落とし込む シニアエンジニアが持つ暗黙知を仕組みとして整備することで、新メンバーやエンジニア以外のメンバーでも開発ルールに準拠したPull requestを作れるようになります。「教える」から「仕組みで支える」への転換です。 まとめ 今回のFindy AI Meetup in Fukuoka #5では、AI時代のエンジニア育成というテーマで2つの登壇を行いました。 登壇を通じて伝えたかったのは、AI時代で環境は大きく変わったが、変わらないこともあるということです。 手を動かし、汗をかき、積み重ねた基礎と経験は絶対に裏切りません。同時に、シニアエンジニアがエージェントスキルやカスタムインストラクションといった仕組みを整備し、誰でも開発に参加できる環境を作ることも重要です。 AI時代だからこその原点回帰として、エンジニアとしての基礎力を鍛えていきましょう。 Findy AI Meetup in Fukuokaは今後も継続して開催していきます。福岡のエンジニアの皆さんとオフラインでつながれるこの場を、これからも大切にしていきたいと思っています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは！ファインディでプロダクト開発部のVPoEをしている 浜田 です。 AI駆動開発が浸透するなかで、エンジニア1人あたりの開発能力は大きく向上しています。しかし、従来のチーム単位のアサイン方式のままでは、そのポテンシャルを十分に引き出せていないと感じていました。 この記事では、私たちが開発プロセスを「チーム単位」から「個人単位」のアサインへ移行した背景と、その結果得られた変化について紹介します。AI駆動開発を取り入れたものの、チームの開発プロセスをどう変えるべきか悩んでいる方に向けた内容です。 これまでの開発プロセス AI駆動開発で見えてきた課題 個人アサイン方式への移行 個人のオーナーシップを高める 技術改善が進みやすくなった まとめ これまでの開発プロセス ファインディのプロダクト開発部には複数の開発チームがあり、それぞれ5名前後のエンジニアにPdMとデザイナーを加えた構成で、協働しながらプロダクト開発を進めています。 これまでの開発プロセスでは、施策開発をチームにアサインし、メンバーそれぞれが優先度の高いタスクをフレキシブルに取っていくスタイルで運用していました。1つの施策開発をチームにアサインすると、結果的に4名程度のエンジニアが集中して取り組み、一気に開発を完了させるという進め方です。いわばフロー効率を重視した開発スタイルで、最も優先度の高い施策を最速で完了させることに注力していました。 この方式はチームの連携が生まれやすく、うまく機能していました。複数人が同じ施策に取り組むことで、設計の議論がその場で生まれたり、実装中に詰まったときもすぐに相談できたりと、チームで動くからこその強みがありました。 AI駆動開発で見えてきた課題 AI駆動開発の導入により、エンジニア1人が同時に扱える開発量は増えました。タスク分解をおこなって依存関係さえ明確にできれば、かなりの数のタスクをAIエージェントに渡して並列で進めることが可能です。加えて、これまではキャッチアップに時間がかかっていたような、自身の習熟度が低い技術スタックの部分であっても、AIをパートナーにして自力で開発を進められるようになりました。 しかし、フロー効率を重視した従来のスタイルでは、このAIのポテンシャルを十分に引き出せませんでした。複数のエンジニアで1つの施策を分担している状態では、一人ひとりが持つタスクの粒度はすでに細かくなっています。そこからさらにタスクを分解して複数のAIエージェントに並列で任せるのは難しく、AIの役割はあくまで副操縦士としての補助にとどまっていました。 加えて、タスクのアサインを明確に決めず、手が空いた人から優先度の高いタスクを取っていくスタイルでは、自分がこの先どのタスクを担当するかが見通せません。先の計画が立たない以上、AIエージェントに先回りしてタスクを渡して並列で進めてもらうこともできず、結局は目の前の1つのタスクをAIと一緒にこなすだけになってしまいます。 個人アサイン方式への移行 そこで、施策開発を個々のエンジニアにまるごとアサインする方式へと切り替えました。 1人が施策全体を担当することで、タスクの分解と計画を自分の裁量で行えるようになります。どの部分をAIエージェントに並列で任せ、どの部分を自分で手を動かすかを事前に整理できるので、AIを副操縦士ではなく、複数の作業を同時に進めるパートナーとして活用できるようになりました。 具体的には、Claude Codeのような自律型エージェントを用いて複数のワーカーを立ち上げます。そして、あるコンポーネントの実装やテストコード生成をそれらに並列で進めさせながら、自身は全体の設計やオーケストレーションに集中する、といった働き方です。 この「1人のエンジニアが複数のAIエージェントを指揮する」具体的なワークフローについては、以下の記事で詳しく解説していますので、あわせてご覧ください。 tech.findy.co.jp フロー効率を重視していた頃と比べると、最も優先度の高い施策が完了するまでの速度は低下します。4名で集中して取り組んでいたものを1名で担当するのですから、これは当然のトレードオフです。しかし、エンジニア間のコミュニケーションコストが減ることや、AIによるアウトプット量と速度の向上により、大きく低下させることなく開発を進められています。さらに、2番目、3番目に優先度の高い施策も別のエンジニアが並行して開発を進めるため、個々の施策にかかる期間が延びても、結果としてより多くの施策を素早くリリースできるようになりました。 実際に、この変化は定量的な指標にも明確に表れています。以下のグラフは紹介した変更を行なった開発チームのPR（プルリクエスト）作成数の推移ですが、個人アサインへの移行を本格的に進めた2026年2月中旬以降、PR数が明確に一段増えていることがわかります。個人のポテンシャルを引き出すアプローチが、開発チーム全体のアウトプット最大化に繋がった形です。 一方で、チーム全体のまとまりという意味では変化がありました。これまでのように全員で1つの開発に集中する場面は減り、どちらかというと個々の集まりに近い形になっています。 ただし、チームとしての連携を完全に手放したわけではありません。たとえば設計の方針に関わる判断は、個人で抱えずチームで議論してから進めるようにしていますし、実装についても「属人化」を防ぐためにプルリクエストをこまめに分割してレビューし合うプロセスを維持しています。さらに、各自が何に取り組んでいるかを定期的に共有する場を設けることで、お互いの状況が見えなくなることも避けています。つまり、チームとしての協働がなくなったのではなく、その関わり方が変わったというのが正確な表現です。 個人のオーナーシップを高める AI時代だからこそ、個人を目立たせることが重要だと考えています。 チームの一員として開発に参加するだけでは、個々のエンジニアの貢献が見えにくくなります。極端に言えば、AIに代替されやすいポジションになってしまう可能性もあります。個人がオーナーシップを持ち、「これは自分がやった」と自信を持って言える状態をつくることが、エンジニアとしての価値を高めることにつながると思っています。 個人アサインに移行したことで、各エンジニアが担当する施策に対して当事者意識を持って取り組むようになりました。設計の意思決定からリリースまでを一貫して担うことで、施策全体を自分ごととして捉える姿勢が自然と生まれています。また、チームで開発していた頃はどうしても窓口がチームリーダーに集中しがちでしたが、施策ごとに個人をアサインしているため、メンバーそれぞれがPdMや事業メンバーと直接やりとりをおこなうようになりました。その結果、施策の背景やリリース後の効果に対する意識が上がるなど、良い効果が出ています。 これはマネジメントの観点からも好ましい変化でした。誰がどの施策を推進しているかが明確になるので、成果の可視化にもつながります。チームの中で埋もれるのではなく、一人ひとりの仕事が見える状態をつくることが、エンジニアのモチベーションにもよい影響を与えていると感じています。 技術改善が進みやすくなった 個人アサインに切り替えたことで生まれたもう1つの変化として、技術的な改善が進みやすくなったことがあります。 チーム全体で施策開発に集中していた頃は、技術改善やリファクタリングはどうしても後回しになりがちでした。個人にアサインされる形になったことで、自分の裁量で改善タスクを差し込みやすくなりました。実際に、以前はなかなか手がつけられなかったライブラリのアップデートやテストの整備といった地道な改善が、各エンジニアの判断で着実に進むようになっています。 チームとしてもリソース配分を明確にしました。施策開発、改善、その他の割合を7:2:1と定めたことで、「2割のリソースは技術改善に使おう」という共通認識が生まれ、改善活動に取り組みやすい環境が整っています。 まとめ フロー効率を重視したチーム開発から、AIのポテンシャルを引き出す個人アサインへと開発プロセスを移行しました。個々の施策が完了するまでの速度は下がるものの、AIエージェントを活用した並列開発によってチーム全体のアウトプットはむしろ増加し、実際にPR数にもその変化が表れています。加えて、個人のオーナーシップが高まり、技術改善にも手が回るようになりました。 チームのまとまりが薄れるリスクはありますが、設計判断の議論やレビューといった連携ポイントを意識的に残すことでバランスを取っています。AI駆動開発を推進するなかで開発プロセスの見直しを検討している方の参考になれば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。 ファインディ株式会社でFindy AI+の開発をしているdanです。 Findy AI+ は、AIツールを導入したけれど、実際にどれくらい効果があるのかという問いに対して定量的に答えるための分析ワークフローを新たにリリースしました。 今回は、これらのワークフローを使って実際にどのような示唆を得られるのかについて実践形式で紹介します。AIツールを導入したものの効果が見えづらいと感じているEMやPdM、チームの活用状況を把握したいエンジニアの方に向けて、MCPサーバーとGitHub Actionsそれぞれでの実行手順と、分析結果からチームの改善ポイントを見つけるまでの流れを紹介します。 Findy AI+とは 開発チームで分析してみた AI環境整備コミット履歴分析（MCPサーバー経由） AIと人のPR作成量比率分析（GitHub Actions経由） Findy AI+の分析ワークフローについて 分析ワークフローでできること GitHub Actionsで分析を自動化 おわりに Findy AI+とは Findy AI+ は、GitHub連携やプロンプト指示を通じて生成AIアクティビティを可視化し、生成AIの利活用向上を支援するサービスです。 人と生成AIの協働を後押しし、開発組織の変革をサポートします。 Claude Code、GitHub Copilot、Codex、Devinなど様々なAIツールの利活用を横断的に分析しています。 今回リリースされた分析ワークフローはMCPサーバー・GitHub Actionsの両方に対応しており、定期的に開発組織の状態について改善サイクルを回せる仕組みをサポートしています。 開発チームで分析してみた ファインディのある開発チームで分析してみました。 分析ワークフローは7種類ありますが、今回はそのうち2つをMCPサーバー経由、GitHub Actions経由の両方で実行しています。 AI環境整備コミット履歴分析（MCPサーバー経由） AI設定ファイルへの貢献者を分析することができます。コミッター統計、PR作成者統計、ファイル別の分析結果が表示されるため、有識者の把握やナレッジ共有のきっかけにすることができます。 MCPサーバー経由の分析は、VS Codeを使用していればChatからスラッシュコマンドを実行するだけで始められます。 コマンドを実行すると、対話形式でリポジトリ名・開始日・終了日の3つのパラメータを順番に入力していきます。 次のようなプロンプトで分析を依頼できます。 以下の条件でAI設定ファイルへの貢献を分析してください： 【分析対象】 - リポジトリ: Repository-A - 期間: 2025-10-01から2026-02-28 【分析観点】 - AIツールの設定に最も貢献しているメンバーの特定 - 設定ファイルごとのメンテナンス状況 - 貢献パターンや傾向の洞察 パラメータの入力が完了すると、MCPサーバーへのツール実行許可を求められます。内容を確認して許可すると、分析が開始されます。 MCPサーバーのツール実行結果です。 Ran AI Configuration File Contributions Input { "repository": "Repository-A", "date_from": "2025-10-01", "date_to": "2026-02-28" } Output # AI環境整備コミット履歴分析レポート **リポジトリ**: Org/Repository-A **分析期間**: 2025-10-01 〜 2026-02-28 **分析実行日**: 2026年03月26日 ## 🎯 論点別サマリ ### 論点1: 誰がAI活用環境整備に貢献しているか？上位は誰か？ **回答**: user1が圧倒的な貢献者で全体の73.5%を占める。次いでuser2が20.6%、user3とuser4が少数貢献。 **インサイト**: user1が中心的役割を担い、特に2025年12月に集中的なリファクタリングと拡充を実施。user2は初期構築とCI整備に貢献。 ### 論点2: 最後に最新化されたのはいつか？更新が古すぎないか？ **回答**: 最終更新は2026-01-21で約2ヶ月前。月平均7.0コミットで継続的に更新されているが、直近2ヶ月は停滞気味。 **インサイト**: 2025年12月に大規模な整備が完了後、更新が減少。定期的なメンテナンスサイクルの確立が望ましい。 ## 1. 貢献パターン分析 **インサイト**: user1は.claude/context/配下の構造化に注力（11コミット）し、アーキテクチャ設計を主導。user2はCI/CDとエージェント初期設定に特化。役割分担が明確。 --- 📊 貢献者別コミット割合 user1 ███████████████░░░░░ 73.5% (25件) user2 ████░░░░░░░░░░░░░░░░ 20.6% (7件) user3 █░░░░░░░░░░░░░░░░░░░ 5.9% (2件) user4 █░░░░░░░░░░░░░░░░░░░ 2.9% (1件) 分析が完了すると、次のようなレポートが出力されます。トップコントリビューターの一覧、設定ファイル別のメンテナンス状況、月別コミット推移などが可視化されており、誰がいつどのファイルを整備したのかが一目で分かります。 一部出力内容ですが、出力データをもとに、メンテナンス状況と貢献パターンのサマリーも整理されます。 ## AI設定ファイル貢献分析レポート **リポジトリ**: Org/Repository-A | **期間**: 2025-10-01 〜 2026-02-28 ### 1. 設定ファイルごとのメンテナンス状況 | ファイル/ディレクトリ | 最終更新 | 主要メンテナー | 状態 | |----------------------|---------|---------------|------| | CLAUDE.md | 2025-12-10 | user1 | 約3.5ヶ月未更新 | | settings.json | 2026-01-14 | user1 | 約2ヶ月未更新 | | .claude/context/ | 2025-12-09 | user1 | 約3.5ヶ月未更新 | | .claude/agents/ | 2025-12-16 | user1, user2, user3 | 約3ヶ月未更新 | ### 2. 貢献パターンと傾向 **時系列の傾向**: - **2025年10月**: user2による初期構築フェーズ（Claude Codeエージェント設定、PR作成エージェント） - **2025年11月**: user1がCI/CD軽量化から参入 - **2025年12月**: **最も活発な月（23コミット）** — user1による`.claude/context/`への大規模分割、Copilot設定統合、@記法導入。user2によるセキュリティ関連整備も同時進行 - **2026年1月**: 2件のみ。整備完了後の安定期に入った可能性 - **2026年2月**: コミットなし **役割分担**: - **user1**: アーキテクチャ設計・構造化のリード（context分割、設定統合） - **user2**: 初期設計とCI/CDセキュリティ強化 - **user3 / user4**: セットアップガイドやドキュメント補完のスポット貢献 **推奨アクション**: - 主要設定ファイル（CLAUDE.md、copilot-instructions.md）が3ヶ月以上未更新のため、プロジェクトの現状と乖離がないか定期的なレビューサイクルの確立が望ましい - 貢献者がuser1に集中しているため、バス係数（Bus Factor）の観点からナレッジ共有の促進も検討すべき AIと人のPR作成量比率分析（GitHub Actions経由） AIに任せられる可能性がある業務領域を特定し、最適な分担を提案することができます。メンバー別AI活用率やPR作成量の偏在度を確認できるので、新機能開発と運用開発の分担を考え直すきっかけ作りにつながります。 GitHub Actionsでの分析は、リポジトリのActionsタブから手動実行できます。対象リポジトリ名と分析期間を入力して「Run workflow」を押すだけです。 分析が完了すると、結果のサマリーがSlackに自動通知されます。チームメンバー全員がすぐに結果を確認でき、定期実行と組み合わせることで月次の振り返りにも活用できます。 結果はGitHub Issueとしても自動作成されているので、Slack通知内のリンクから遷移できます。構造化されたレポートが作成され、チーム内での共有や議論をする親Issueとしても活用できます。 詳しいセットアップ方法は GitHub Actionsでの分析セットアップガイド をご覧ください。 Findy AI+の分析ワークフローについて ここまで紹介してきた分析は、Findy AI+が新たに提供を開始した分析ワークフローを使って実行したものです。ここからは、ワークフローの全体像と活用方法を紹介します。 分析ワークフローでできること 今回のリリースでは、次の7種類の分析ワークフローを提供しています。 ワークフロー できること Agent Environment Analysis AI向け指示ファイル・フォルダをスコア化し、自走環境の整備度合いを診断 PR Reviews Analysis コード変更者・開発環境の伸びしろを特定し、改善施策を提案 PR Productivity Analysis AI活用によるアウトプット量の変化や機能開発への影響を分析 AI-Human Collaboration Analysis AIに任せられる業務領域を特定し、最適な分担を提案 Multi AI Cost Comparison 複数AIツールのROIを人件費対比で算出 PR Type Summary PRの作業種別ごとにサマリーを生成 Findy AI+ PR Review PRオープン時にAIレビューを自動実行し、結果をコメント投稿 これらはMCPサーバー・GitHub Actionsの両方からご利用いただけます。 GitHub Actionsで分析を自動化 GitHub Actionsを使えば、上記の分析をリポジトリから定期実行できます。デフォルトでは毎月1日にスケジュール実行される設定になっており、頻度はカスタマイズ可能です。GitHub Web UIやCLIからの手動実行にも対応しています。 分析結果はSlackチャンネルに自動通知されるため、チーム全体で定期的に確認し改善サイクルを回す運用が実現できます。チーム単位での分析にも対応しているので、組織全体だけでなくチームごとの傾向把握も可能です。 気になるポイントをさっと確認したいときはMCPサーバー、じっくり深堀りしたいときはGitHub Actionsという使い分けがおすすめです。 おわりに 今回は、Findy AI+の分析ワークフローを使って、ある開発チームのAI活用状況を約1年にわたって追いかけてみました。 AI環境整備コミット履歴分析では、誰がAI設定を整備しているのか、どのファイルがどの時期に集中的に更新されたのかが見えてきました。AIと人のPR作成量比率分析では、AI活用率の推移やメンバー間の活用度の差が可視化されました。こうした数字があることで、「なんとなくAIを使っている」という感覚ではなく、具体的にどこに課題があり、何を改善すべきかを議論できるようになります。 AIツールを導入したものの効果が見えづらいと感じている方は、まず自分たちのチームの現状を可視化するところから始めてみてください。データがあれば、次の一手が見えてきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers