開発生産性Conference2025に参加してきました！

こんにちは！タイミーでBackend Engineerをしている@akitoshigaです！
7月3日（木）、7月4日（金）に東京の丸の内で開催された「開発生産性Conference2025」に参加してきました！🙌

dev-productivity-con.findy-code.io

自身は7月3日（木）のDay1に現地参加したので、その時の様子を振り返ってみたいと思います！

当日の様子

関西在住の自分は「Kaigi Pass」という社内制度を利用して参加しました。
「Kaigi Pass」とは、世界中で開催されているすべての技術カンファレンスに無制限で参加できる制度です。 productpr.timee.co.jp

会場はJPタワーホール&カンファレンスという東京駅近くにある会場で行われました。

最初のセッションで基調講演を行ったのはケント・ベック氏でした。
彼のファンである自身は今回聴講できて感無量でした。

Day1 Keynote、Kent Beck @KentBeck 氏

11時からはサイン会も実施します！✒️#開発生産性con_findy #開発生産性con_findy_A pic.twitter.com/s0COYqZCY2

— 開発生産性Conference/Developer Productivity Engineering (@dpe_findy) 2025年7月3日

その後のサイン会でケント・ベック氏にサインをもらいました！

サイン会の場で彼に対する想いと感謝を直接伝えることができて嬉しかったです。

サイン会の後、スポンサーブースを回ってみたのですが、非常に盛況でした。
ブースもたくさんありましたが、それ以上に参加者の多さに圧倒されました。

タイミーのブースもこんな感じで出展していました！

＼ #開発生産性con_findy ブース紹介✨ ／
株式会社タイミー様 @TimeeDev pic.twitter.com/lq9LWwyE8y

— 開発生産性Conference/Developer Productivity Engineering (@dpe_findy) 2025年7月3日

また、タイミーからはプラットフォームエンジニアリング部部長の恩田が登壇しました。

参加したセッション

自身が参加したセッションについてもいくつか紹介をしたいと思います。

基調講演：開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった

• ケント・ベック氏

冒頭で「物事をより良くしようとしてかえって結果が悪くなってしまう」という旨のドイツのことわざを紹介しており、要所要所でこちらに言及しているのが印象的でした。

「グッドハートの法則」とは「指標が目的になった途端それは良い指標ではなくなる」ことを言うそうで、これを提唱した英国の経済学者の名前にちなんで名付けられたそうです。
生産性向上のために指標を設け測定したとしても、開発者にプレッシャーをかけるとその指標を達成することが目的になってしまうと主張していました。
タイトルに「もっと悲観的に捉えるべきだった」とありますが、このような指標の目的化現象は我々の想像以上に起こりやすく、またいろいろなところでそのような場面にケント・ベックは直面していたようです。
実際にこのような事態は誰しもが一度は経験があるのではないでしょうか。
このことについて、開発者にはプレッシャーをかけるのではなく目的意識を共有することが重要だと主張されていました。

また、測定すること自体は良いが、決して目標にしてはならず測定のポイントにも注意が必要だと主張していました。
ケント・ベック氏は「Path of Value」として以下の4つのプロセスを紹介しました

1. Effort
   • コードを書くこと
2. Output
   • 具体的な成果物（画面上のボタンなど）
3. Outcome
   • ユーザーの価値変容
4. Impact
   • ユーザーの行動変容

1から4に行くほど測定はしづらいが、ユーザーの価値につながるため、測定の判断は先送りにしてなるべく後ろのプロセスで測定することを推奨していました。

最後にグッドハートの法則に対応する形で以下を結論づけました。

• Observe later（計測はなるべく遅らせ後ろの段階で行う）
• Encourage awareness（気づきを奨励する）
• Avoid pressure（プレッシャーをかけること避ける）
• Instill purpose（目的意識を共有する）

「グッドハートの法則」に基づくケント・ベック氏の主張は、ある種当然と言えば当然のようにも思われるのですが、彼がこの主張をすることにものすごく意味があると感じました。
開発プロセスにおける本質的な部分をテーマにした彼らしい発表だと感じました！

NTTデータによる生成AI活用：開発効率化とビジネス変革

• 株式会社NTTデータグループ 海浦 隆一氏

NTTデータは2025年7月にApps&Data技術部からAI技術部へと組織改編して生成AIの活用を本格的に推進しており、これまでのミッションクリティカルなシステム構築で培った生産性向上ノウハウを基盤に、開発スピード向上と品質維持の両立を目指しているそうです。
取り組みのロードマップとしては自動化の段階的推進: 2023年のタスク自動化から始まり、2025年にはプロセス自動化、2027年にはビジネス全体の自動化を目指しており、既に250以上のプロジェクトでAIを活用しているとのことでした。

主な取り組みと成果として以下について紹介していました（一部）

• モダナイゼーションとレガシーシステムの解明
  • FigmaからのReactコード生成（Locofy）
  • ソースコードからの開発ドキュメントのリバースエンジニアリング
  • OSSからのマニュアル生成などにより、システムの理解と保守にかかる工数を削減
• 属人化防止とドキュメント作成の効率化
  • 有識者の暗黙知を形式知化し、独自様式の設計書を標準形式に変換する「Coding by NTT DATA」の活用
  • ExcelからMarkdownへの変換など、AIが読み取りやすいフォーマットを採用
• 開発プロセスの各段階でのAI活用
  • GitHub CopilotやAzure OpenAIを利用
  • 設計書からの結合テスト項目を作成

さらなる生産性向上への展望として開発工程全体の生産性向上を目指し、要求分析から直接コードを生成し、その後設計書をリバースエンジニアリングする「逆Wモデル」といった新しい開発プロセスの実現を模索していることが非常に印象的でした。
全体的にAIを中心に据えて最大限AIの恩恵を受けられるように開発プロセスを設計しているように見受けられ興味深かったです。
また、多種多様なプロジェクトに携わっている強みを活かしてシステム開発における全域に渡って実践・フィードバック・形式知化・横展開を行えているのが組織として非常に魅力的に感じました！

生成AI時代の品質保証：自動化とAIによるテスト改善

speakerdeck.com

• mabl株式会社 小田 祥平氏

現状を取り巻くQAの問題点と、そのソリューションとしてAIエージェントによる自律型テストを紹介されていました。
QAに関して課題を抱えているところは多いそうで、独自アンケートによると対象者の6割が手動でのテスト対応を行っているとのことでした。
この背景には以下の問題があるそうです。

• 保守コスト
• 基盤の構築と実施コスト
• ナレッジ不足

特にAIの台頭によりデプロイ頻度の増加と品質維持の要求が高まる中で、テストの自動化とAIの活用が不可欠であるということを強調されていました。

これらの課題のソリューションとしてAIを活用したテストマネージドツールの提案をされており、「mabl」というサービスをベースとして以下のようなテストマネージドツールの機能について紹介されていました。

• マネージドツールの活用
  • 生成AIによるテスト自動修復機能でメンテナンスコストを削減
• AIによるデータ分析・推論
  • テストログからの原因分析、flakyテストへの対応
• 自然言語でのテスト構築
  • ユーザーストーリーからテストケースを自動生成
• CI/CD環境との統合
  • シームレスなテストプロセスを実現

AIを活用したテストツールはこれまで詳しく追っていなかったので想像以上の多機能・高機能さに驚きました！
開発速度の向上に伴い迅速なQAは今後より求められていくので、こういったツールが不可欠になっていきそうだと感じました。

楽天のAI戦略：70以上のサービス運営と開発生産性向上

• 楽天グループ株式会社 久田 直次郎氏

楽天グループの展開する70以上サービスの中で、AIを事業成長と開発生産性向上の両輪として活用している現状を紹介されていました。
楽天グループのAI推進戦略として「トリプル20」を打ち出しています。
この戦略はAIを活用してマーケティング・オペレーション・カスタマーサポートの利益をそれぞれ20%向上させることで、年間105億円の利益貢献を目標としています。
社内でのAI活用は非常に効果が出ているそうで、既に16,000個以上のAIツール・テンプレートが作成され、営業資料の作成時間は48%減、ビジネスメール作成時間54%減などの効果が出ているとのことでした。

また、新たな事業として「Rakuten AI for Business」を開始しており一般ユーザー向けに事務・営業・企画/マーケティング・エンジニア向けサービスを提供しているそうです。
それだけでなく、「Rakuten AI LLM」という自社LLMの開発も行っており、用途に合わせた最適化・日本企業に合わせた設計・日本語性能の高さを強みとしているそうです

開発におけるAI活用ではコーディングが最も多く、GitHub Copilotなどの生成AIコーディングツールの導入PoCで一定の効果を確認しているとのこと。
開発サイクルタイムのデータ収集と標準的な可視化を進めており、30%～80%の開発効率削減を目指しているそうです。

楽天グループには約30,000人の従業員の方がいるそうで、AIによる業務効率化のインパクトは非常に大きいと思いました。
また、自社で日本語性能を強みにしたLLMを開発されているのが非常に興味深く、どういったところで活用されていくのかについても興味が湧きました。

まとめ

開発生産性Conferenceには今回初めて参加したのですが、各社の開発生産性に対する様々な取り組みや参加者の熱量を感じました。
今回参加して得た知見を自身や周りの開発にも活かし、より生産的なプロダクト開発を行ってまいります！

お知らせ

開発生産性Conference2025でタイミーと同じく登壇されたログラスさん、DELTAさんと合同で「生産性改善しNight」と題したアフターイベントを開催します！
「開発生産性 Conference 2025」に参加された方はもちろん、開発生産性の向上や、社外のエンジニアとの交流に興味がある方も大歓迎ですのでぜひ遊びに来てください！ timeedev.connpass.com

DevinのプロンプトをDevinに自己改善させる

こんにちは！タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。

最近、私たちのチームでは自律型 AI エージェント Devinの活用が広がっています。特に、GitHub Actionsのスケジュール実行や特定のイベントをトリガーに、定型的なタスクをDevinに任せるといった使い方を試しています。

しかし、Devinを使いこなそうとすると、多くの方がこんな課題に直面するのではないでしょうか。

「最初に作ったプロンプトでは、なかなか期待通りのアウトプットが出てこない…」

結局、何度か追加の指示を繰り返して、ようやく望む結果にたどり着く。これは「AIあるある」とも言える状況ですよね。そして、本当に大変なのはここからです。今回のやり取りで得た知見や改善点を、次回の実行のために元のプロンプトへ手動でフィードバックする作業。これが地味に面倒で、つい後回しにしてしまいがちです。

そこで私たちは、このプロンプトの改善作業自体をDevinに任せるという、面白い試みを始めました。今回はその具体的な手法と、それによって得られるメリットについてご紹介します。

面倒なプロンプト修正は、Devin自身にお任せ

Devinとの数回のラリーを経て、タスクが無事に完了したとします。ここで、Devinに次のようなプロンプトを投げかけます。

今回私が行った指摘を、次回以降はしなくて済むように、{ここにGitHub ActionsのYAMLファイルのパス} に記載しているプロンプトに変更を加えてください。

たったこれだけです。これにより、Devinは今までのやり取りをすべて学習し、人間からのフィードバックを反映した新しいプロンプトを自ら生成してくれます。

Pull Requestによる変更提案で、レビューも簡単

さらに、私たちはDevinに次の条件を追加で指示しています。

条件

• 変更内容は、新しいPull Requestとして作成してください。
• 今回のやり取りで追加した指示と、既存のプロンプトに意味的に重複する部分があれば、それらを統合してプロンプト全体を最適化してください。

この指示により、Devinはプロンプトの変更内容をまとめたPull Requestを自動で作成してくれます。

Devinが作ってくれたPull Request

エンジニアは、そのPull RequestをレビューするだけでOKです。

1. 新しいプロンプトでテスト: 実際に新しいプロンプトを使ってDevinにタスクを依頼し、意図通りのアウトプットが出るかを確認します。
2. 評価とマージ:
   • 改善された場合: Pull Requestをマージし、プロンプトをアップデートします。
   • 変わらない・悪化した場合: マージはせず、なぜ期待通りにならなかったのかをDevinに再度フィードバックします。このサイクルを繰り返すことで、プロンプトは継続的に洗練されていきます。

AIが生成したコードを見なくて良い時代はまだ先か。でも…

「AIエージェントが書いたコードを、人間が一切レビューしなくて良い」という未来は、まだ少し先かもしれません。しかし、AIエージェントに与えるプロンプトを、人間が逐一メンテナンスしなくても良い時代は、もう目の前に来ていると感じています。

Devinにプロンプト自身を改善させるアプローチは、単なる作業効率化に留まりません。これは、AIを単なるツールとして使うのではなく、対話とフィードバックを通じてAIを育てるという、新しい協業の形と言えるのではないでしょうか。

最後に

今回は、DevinのプロンプトをDevin自身に改善させるという、私たちのチームの取り組みについてご紹介しました。この小さな工夫が、皆さんの開発プロセスをよりスムーズにする一助となれば幸いです。

皆さんなりのDevin活用術や面白いアイデアがあれば、ぜひ教えてもらえると嬉しいです。

AI x PlatformEngineeringへの取り組み(立志編)

はじめに

プラットフォームエンジニアリング1G Managerの橋本です。チームの名前の通り、私達はクラウドインフラ（AWS）やCI/CDパイプライン、Observability、クラウドセキュリティを軸としてタイミーのサービスプラットフォームを開発者へ提供しています。

昨今、AI Coding Agentの発展は目覚ましく、弊社でもCursorやDevinなどを日常的に利用して開発が行われています。そんな中、AIとPlatformEngineering（PFE）の交差によって、よりビジネスに資するPFEの推進ができるのではないかと"妄想"しました。その青写真や取り組む方向性について記事にします。

まずPFEや開発者との関わりを整理

jacopenさんの以下の登壇スライドが分かりやすいため、本記事に関わるポイントを抜粋します。

speakerdeck.com

背景：DevOpsと認知負荷の増大

• クラウドの登場とDevOpsにより、開発とデリバリーの継続的な実施を目指すアプローチが広まった。DevOpsのプロセスにセキュリティ対策を組み込むDevSecOpsも登場
• 扱う技術スタックの激増により開発者の認知負荷が非常に高くなった（特にこの10年）
• これをやり切れる人材は少なく「真のDevOps」（開発者がフルサイクルでデプロイ・実行を行う）の実現は多くの組織で現実的ではない

そこでPFE

• 開発者体験と生産性を向上させるために、セルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野
• 本質は、開発者体験と開発生産性を高める取り組み
• PFEの始め方は、開発フローの「ペイン」（辛いところ）を洗い出し言語化し、必要な対応を行うこと
• 例えば、セルフサービス化やInternal Developer Portal/Platform（IDP）構築などがある（が、これが必須でもないと資料では言及されています）

開発者との関わり方

• Team Topologiesの整理で、ビジネス価値に一気通貫で関わるStream-aligned team（ストリームアラインド・チーム）と、その道のプロであるPlatform teamなどが定義されている
• チーム間のインタラクションモードとして以下があり関わりの濃淡で捉えている
  • Collaboration (Embedded)
    • ゴールを共有して一緒に動く（ガッツリ関わる）
  • Facilitating (Enabling)
    • 障害を取り除くためにその道のプロとして支援する（中程度の関わり）
  • X-as-a-Service (XaaS)
    • ツールを提供する（関わりが最も薄い）
• Platform Teamは、まずCollaborationから始めるのが良い。Stream-aligned Teamと1:1で協力し、必要なものを理解して作ることで、誰得なものを作り込むことを防ぐ
• Collaborationで得た知見をもとに、より多くのチームを助けられるXaaSモード（プラットフォーム提供）を構築していく。ここでIDPの要素が出てくる

我々PFEチームの現状・課題

先の認識をもとに私達の組織の現状認識や課題感について書きます。

PFE1Gの立ち位置と現状

我々が所属するプラットフォームエンジニアリング部では、開発ライフサイクルの各所でドメイン知識を持ったチームやメンバーにより支援を行っています。（以下の図の 開発プラットフォーム Tribe ）

私達1Gはその中でもサービス実行環境であるAWS基盤全般、リリースツール(CI/CD)や運用(observabilityやAWSに関わるOps)の一部に責務を持ち、開発生産性に寄与するための業務を担っています。実態としてインフラチーム + SREチームの混合というイメージです。

なお、PFEの文脈で出てくるセルフサービスやIDPの提供はしていません。これらの仕組みがなくても価値提供の大きなボトルネックやブロッカーになる状況が観測されていなかったためです。

しかし、将来的に我々自身がボトルネックとなりうる懸念がありました。

開発組織イメージ図

懸念とは？

提供サービスの整理

主な領域に切り出した場合、以下のような整理になり、AWSという大きな領域以外はおおよそXaaS的なサービス提供ができており、関わりが薄い状態で開発者体験や生産性に寄与できている状態と考えています。

領域	提供方法	提供詳細
AWS	いろいろ(後述)	-
Observability	Datadog 関連記事1, 関連記事2	ダッシュボード化など XaaS的な提供ができていそう
CI/CD	GitHub Actions 関連記事3	CI/CDパイプライン XaaS的な提供ができていそう

AWS周りを分解

AWS環境はTerraform/IaCによる管理をしています。GitHub上でコード管理されており、おおよそのCODEOWNERは1Gになっています。開発者は必要な変更があればPullRequestを作成し、1Gのエンジニアが問題ないことを確認してmergeができます。これは、XaaS的な提供と言えそうです。

ベースラインの運用は先の通りXaaS化がなされています。しかし、必要となるAWSに関する知識、設計難易度やドメイン知識に応じてTeam Topologiesでいう、FacilitatingやCollaborationが必要となるケースがあります。なお、用語的にイメージしやすいFacilitating → Enabling、Collaboration → Embedded として以降は表記します。

なお、例としてバケット追加にXaaS or Enablingと書いていますが、ほぼ依頼をもらって我々が作業を行うことがほとんどです。頻度があまりなく、対して要件によって必要なパラメータが変わるため、Terraform Module化や詳細な手順書を書いていたとしても、結局聞いて我々が考えて設定した方が提供が早く認知負荷も低かったためです。

要件	難易度・範囲	例	Team Topologiesのモード
実装済へ軽微なもの	簡略的・限定的	既存のバケットpolicy変更	XaaS
明確な要件/定型化可能なもの	繰り返し・限定的	バケット追加	XaaS or Enabling もしくは依頼作業型
新しいAWS機能の利用開始	新規・不確定	AWS 〇〇を新規構築	Enabling or Embedded
新サービス/サブシステム構築	新規・広範囲	-	Embedded

現状は問題ない？

先の整理が現状ですが、今時点は大きな問題は起きていません。

しかし、将来への課題感がありました。Embeddedのチームへの負荷の高さです。XaaS, Enabling, Embeddedのチーム間の距離感や工数感をイメージにした画像を示します。この絵のようにEmbeddedはほぼ対象チームに人を派遣する形になり、比例して工数的にも他パターンよりも大きくなる傾向があります。Embeddedは、例として新しいサブシステム構築プロジェクトが発生した場合にチームから人を送り込むようなものになります。数ヶ月にわたってヘッドカウントが減ることになり、チームの計画に影響があります。

もちろん、組織全体のビジネス達成観点ではプラスなので間違っていませんが、Embeddedが継続的に発生したり、複数発生した場合はチームが機能不全に陥るリスクがあります。結果、組織全体へ悪影響や我々がボトルネックになるリスクが発生しうると考えました。

XaaS/Enabling/Embeddedの距離感・工数感のイメージ

XaaSやEnablingへの移行が鍵ではあるが

リスク回避のアプローチはPFEの考えに沿えば、XaaS化やEnablingによって関わり（≒ 工数）を減らし開発者生産性向上を目指すことです。しかし、先に述べたバケット追加が依頼作業型になるように、現実としてはインフラ領域のドメイン知識は多岐にわたるため簡略化・手順化することが困難なケースが多くあります。仮にenablingパターンで進めたとしても、あれこれお手伝いをしているうちにEmbeddedになってしまうことが想像されました。

Embeddedでチームが劣化してしまうかも

Embeddedが多発すると、チームへの負担が増すと述べました。例えば、1人から2人、瞬間的には3人がサブシステム構築プロジェクトに関わることがあります。こうなると、チーム（だいたい1pizza的な人数で構成しています）の半数が出払ってしまうことにもなり、定常的な業務遂行が劣後してしまいます。

サブシステム構築が1つだけであれば「暫く待てば皆戻って来る」という期待が持てますが、2つ以上並走した時点で詰みになります。まだ2以上の並走プロジェクトはありません。しかし、弊社の今後の事業成長・加速に応じて発生する可能性があります。

複数のembeddedパターンが走るケース

こうなると、PFEチームがスケールできない = 事業開発への遅延となってしまいます。

このリスクを如何に回避できるか？を考えていた中でAI Coding Agentの急激な成長を見てできることがありそうだと思い至ったこと。これが本ブログの趣旨になります（やっと本題です）

今までのお話をまとめると

以下のようになります

• 新システム開発のようなEmbeddedでなければならない（XaaSやEnablingでは限界がある）ケースがある
• 理想はEnablingではあるものの、インフラ領域自体のドメインが巨大であり一朝一夕で開発者が自走できるものではない
• 結局、巨大なドメイン知識に対応しうる人材が張り付く（Embedded）する必要があり、このスケーラビリティが事業成長のボトルネックになりうる

AI Coding Agent x PFEの青写真

AI Coding Agent技術の現状と可能性

我々はIaC/TerraformによりAWS環境を扱うことが多いため、AI Coding Agentのコード生成についてはHCLの記述性に着目することが多いです。

AIのHCL記述力は急速に改善されています。以前はHCLを扱うのが苦手で、古いAWSプロバイダー仕様や新しく出たサービス定義に対応できないケースが多発していました。ウェブなどの情報からでは正しい一次情報をAIがピックアップできないからだと思われます。

しかし、Terraform MCP ServerやAWS MCP Serversによって正しい一次情報へアクセスした上で生成するようになるなど、以前のような課題は解決されつつあります。

これら改善により、CursorやDevinなどのAI Coding Agentを活用して、開発者が直接AWS基盤に変更や追加を加えることが現実的になってきました。とはいえギャップが大きいのも事実です。

理想のかたち：AI Enablingの実現

宣言的なインフラ変更の実現

現状では「terraformのリソース○○に○○なパラメータで追加して」のようなかなり明示的・指示的なプロンプトになりがちです。しかし理想は「○○な要件でバケットがほしい。追加して」といった宣言的な自然言語での要求を実現することです。

また、「〇〇な要件では〇〇への考慮が必要なので、以下の質問に答えてくれますか？」といったAIからの打ち返しを通じて、特にセキュリティ的なガードレールが満たされる実装まで開発者とAIの対話によってなされることが理想です。

開発者とAIのインタラクションの図

最終形としてこれが達成されれば、簡単な自然言語によるAWS基盤の変更がXaaS的に提供できそうです。また、変更適用までは難しくてもAWS基盤に関する壁打ち相手としてAIが提案をしてくれ、気にすべき点を開発者が適切に認知できるようになればEnablingとして機能していると言えそうです。

余談ですが

我々のチームではDevinに対してIaCの変更を依頼することが多くあります。一例として以下の画像のような、とても指示的な依頼になってしまいがちであったります。

指示的・明示的なプロンプトになる例

これをできる限り宣言的に行えるようにすること、AWSやTerrafromリソースに対して知識がなくても依頼できるようにすることが目指すかたちだと言えます。

EnablingモードのAI化イメージ

例として、開発者が「○○な用途で○○したいけれどどうしたらいい？」といった質問を、従来PFEエンジニアに問い合わせていた内容をAIに対して行い、適切な回答を得られるようになります。

副次的効果として、PFEチームのエンジニア自身も当然AIに質問できるので、PFEエンジニア間のドメイン知識のばらつき解消やSPOF防止（Aの領域はXさんしかしらない。Bの領域はYさんしかしらない）が期待できます。

現実的な課題：コードの外側のコンテキスト

事業要件とコードのギャップ

AWS基盤はほぼコード化されていますが、コード化されていること＝事業要件ではないケースが存在します。

例えば、S3バケットのセキュリティ要件は、保存するデータが個人情報かどうか、グローバル公開するかどうかなど、事業要件によって変わります。また、IAM Roleなども組織体制や運用要件によって大きく変わります。しかし、コードにはそこまでの要件が細かく記述されていることは少ないのではないでしょうか。IAM Roleであれば、どのRoleが付与されているかと追加・変更理由ぐらいまではコメントにあっても、なぜこのRoleが存在するのか、どのような使われ方をするのかについては別のドキュメント・手順書にコンテキストがあるのではないかと思います。

つまり、コードの外側に事業や運用に関わるコンテキストが存在することが多いと考えています。

解決アプローチ：コンテキスト注入とドキュメント化

必要なドキュメント化

コードの外側にあるコンテキストをAIに理解してもらうため、例えば以下のようなドキュメント化が必要になりそうです。

サービス仕様のドキュメント化

• アプリケーションの仕様
• ユビキタス言語などのローカル言語定義
  • Devinを賢くする秘訣は「ユビキタス言語」にあり？ NotionとTerraformで実現する半自動ナレッジ更新術
• 実行に関わる運用ルール・実装方法・GitHubコメントの書き方などのナレッジ
  • 気づけばDevinのナレッジが山積みに。Terraformで片づけてみた

技術仕様に応じたAWSリソースのドキュメント化

• コードの外側にある情報（人間が補足する情報）
  • 例えば、 特定のIAM Roleに付与された権限の文脈や運用ドキュメントとのリンクなど

AIによるEmbeddedモード連発からの脱却

上記が達成されれば、現状Embeddedモードで人が大きく関わっている新規サブシステム構築プロジェクトでも、XaaSやEnablingのような薄い関わりで遂行できると期待されます。開発者とPFEの関わり方・分担は以下のようなイメージになれば良いと考えています。

開発者の作業フロー

• Devin, CursorなどのAI Coding Agentに並走してもらい、作りたいサービスのTerraformコードを生成
• インフラ構築を実行

PFEチームの関わり方

• コードや変更の正しさ・ガードレールが必要かなどレビューで関わる
• 誤りや複雑性・危険な操作の予兆を発見した場合は訂正・ガードレールの規し修正事項をドキュメントに反映する
• 新しい設計などコンテキストに存在しないものがあれば一時的なEmbeddedモードで並走

開発者・PFE・AI・ドキュメントの相関の絵

PFEの役割

先の絵を見るとHCLの記述やIaC・クラウドインフラのメンテナンスはAIによって行われることがより効率的であるという未来が見えます。その時、我々PFEは何を責務とすべきなのでしょうか。

絵を見ると、コード外のコンテキスト・ドキュメントを充実させることにあるかもしれません。大まかなイメージではありますが

• 日々の開発・運用・ビジネス変化を観測・メトリクス/KPIの計測から問題を発見する
• 問題を解決するための議論・必要に応じてルールメイキングを行う
• 解決策・ルールをドキュメントに反映してAIが正しい出力をできるようにする

言うなれば、ビジネスを観測し経験などに基づいて課題抽出を正しく行ったり、目まぐるしく変わる優先順位を整理して、AIに"気持ちよく"仕事をしてもらうために必要な情報やルールメイキングをドキュメントに反映したり、"お願い"することが仕事になるかもしれません。なんだか、エンジニアリングマネージャーっぽいですね。

この話のまとめ

• 新システム開発のようなEmbeddedモードでなければならないケースが連発するとPFEのスケーリングが事業ボトルネックになるリスクがある
• リソースが限られるのでEmbeddedの連発は不可能。しかしながら、AIによってEnabling + 最小限のEmbeddedで事業のスケーリングに対応できるプラットフォームエンジニアリングができるのではないか、と、現在は"妄想"段階
• コードに表現されていない様々な要件をAIに与える必要があり、ドキュメント化や入力方法を工夫してAI Coding Agentに正しい出力をしてもらうことが鍵になりそう。AIに気持ちよく仕事をしてもらう工夫をすることに労力を費やすことになるかもしれない。

最後に

既に弊社の他の方々がブログに取り組みを書いているように、先の取り組みが始まりつつある状態です。また、AI Coding Agent界隈の変化が激しく1〜2週間でも目まぐるしく注目の話題が生まれてくる状況にあります。（2025年6月現在）

変化によってやり方が全く変わる可能性がありますが、2〜3ヶ月後にはある程度の目処が見えてくるのではないかと思います。過去半年のAI Coding Agentの発達を思えば、今年中にはさらに大きな発展をしている期待感もあります。

不確実なことが多い取り組みではありますが、もし達成できればPFEがビジネス上のボトルネックになるリスクを回避できる、少ない人数で最大のアウトカムを得るチャンスだと思うので、力を入れて取り組んでいきたいと思います。

長い文章になりましたが、最後まで読んでいただいてありがとうございました。

スクラムイベントがうまくいかない時は大抵前のフェーズがうまくいっていない

読んで欲しいと思っている人

• スクラムイベントがうまくいかない感じがして困っている方
• スクラムイベントをもっと良くしたいと思っている方

読むとわかること

• スクラムイベントを改善するための1つのアイデア
• スクラムイベントは互いにインプットとアウトプットとなりながら循環していること
• スクラムを改善したい時はシステム思考を勉強するとちょっと助けになること

はじめに

バックエンドエンジニアを務めている @Juju_62q です。スクラムでのロールとしては「開発者」を務めています。突然ですが質問です。

スクラムイベントがうまく改善できないという経験はありませんか？

例えば「スプリントプランニングが時間内に終わらない」という問題があるとします。この時にスプリントプランニングで効率的に意思決定を行うための実験を開始してもどうにもうまく問題が解決していかないことがあります。時間内に収めるために強引な意思決定手法を導入することもできますが、それだと開発者のコミットメントをうまく引き出せないこともしばしばあります。

こういった時に自分が気をつけていることの1つを紹介させていただければと思います。 スクラムイベントが何かうまくいかないと感じている方はスクラムをやめる前にぜひ考えてみて欲しいです。

Devinを賢くする秘訣は「ユビキタス言語」にあり？ NotionとTerraformで実現する半自動ナレッジ更新術

タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。

タイミーでは自律型 AI エージェント Devin を活用した開発を行っています。

Devin を効果的に活用する上で鍵となるのが、どのような「knowledge（知識）」を与えるかです。Devin を活用している各社で、試行錯誤が進められているのではないでしょうか。

もし Devin に一つだけ知識を与えて賢くするとしたら、何が最適でしょうか？
私は「会社固有の知識であり、かつ社員にとっては当たり前すぎて、AIに教えるという発想に至らない情報」が、AIの精度を向上させる鍵になるのではないかと考えています。

社員は知っているが Devin は知らない、そんな情報の代表格として思いついたのが「ユビキタス言語」です。実際に Devin にユビキタス言語を knowledge として教えてみたところ、抽象的な概念に対する理解度が向上する手応えがあったため、その TIPS を共有します。

また、Devin に教えるユビキタス言語が古くなっては逆効果です。そこで、ユビキタス言語の knowledge を半自動で更新する仕組みも作ってみたので、合わせて紹介したいと思います。

前提

私たちタイミーの環境における、2つの重要な前提について説明します。

1. Notion DBによるユビキタス言語の管理

タイミーでは、ユビキタス言語を Notion のデータベースで一元管理し、常に最新の状態に保つワークフローが確立されています。このデータベースには、以下の情報が含まれています。

• 表現（事業者向け）： 企業向けの表現。企業向けとワーカー向けで指すものが同じでも表現が異なることがあるため分けています。 （例：求人を公開）
• 表現（ワーカー向け）： ワーカー向けの表現。（例：募集を公開）
• 意味： 用語の意味
• NG表現： 誤って使われやすい用語例
• 実装の英語表記： 用語に対応する実装上のキーワード
• 備考： 用語を使用する際の注意事項

こちらに関して詳しく知りたい方は以下の記事をご覧ください。

note.com

2. TerraformによるDevin knowledgeの管理

次に、タイミーでは Devin の knowledge を Terraform で管理しています。

以下のような Terraform ファイルを記述することで、knowledge を登録できます。

resource "devin_knowledge" "this_is_knowledge_1" {
  body                = <<EOT
Pull Requestの説明には、.github/PULL_REQUEST_TEMPLATE.md のテンプレートをベースとして使用してください。
このテンプレートは、このリポジトリのすべてのPull Requestで使用する必要があります。
EOT
  name                = "PR作成時のテンプレート利用"
  parent_folder_id    = data.devin_folder.this_is_folder_name.id
  trigger_description = "foo リポジトリで Pull Request を作成する場合"
}

こちらに関して詳しく知りたい方は、以下の記事をご覧ください。

tech.timee.co.jp

実装

運用されているユビキタス言語の Notion DB と Devin の knowledge を Terraform で管理する仕組みが整備されているので、あとはそれらをつなぎこむだけです。

今回 Notion DB を CSV Export し、Terraform ファイルとして出力する Shell スクリプトを用意しました。
Shell スクリプトを生成するプロンプトは以下です。参考にしてみてください。

ユビキタス言語CSVからDevin KnowledgeのTerraformファイルを生成するスクリプト

=== 生成プロンプト ===
以下の要件でユビキタス言語データベース（CSV）からDevin knowledgeのTerraformファイルを
自動生成するBashスクリプトを作成してください:

【目的】
- CSVに定義されたユビキタス言語をDevin Knowledgeに変換
- Devinが「お仕事リクエスト」→「offeringRequest」のような用語対応を理解できるようにする
- 用語について質問された際に適切な検索指示を提供するナレッジベースを構築

【CSVファイル構造】
- ファイルパス: source/ubiquitous.csv
- 列構成: 事業者向け表現, ワーカー向け表現, 意味・定義, 避けるべき表現, 実装上の英語表記, 備考
- 文字エンコーディング: UTF-8
- 引用符内の改行やカンマを含むデータあり（CSVパーサーで適切に処理が必要）

【処理要件】
1. CSVパーサー: Rubyの標準CSVライブラリを使用（引用符内改行問題を解決済み）
2. フィルタリング: 意味・定義がある全エントリを処理対象（実装向け表記の有無は問わない）
3. primary_expr決定: 事業者向け表現 → ワーカー向け表現 → "用語N" の優先順位
4. カウンター管理: 正しいインクリメントでリソース名重複を防止
5. 動的トリガー生成: 実装向け表記の有無でトリガー記述を分岐

【ナレッジ内容構造】
- タイトル: 「ユビキタス言語「XX」の用語対応ガイド:」（検索指示中心）
- 【用語の定義】: 意味・定義の内容
- 【実装・開発時の検索キーワード】:
  * 実装向け表記がある場合: 「コードや実装: 「XX」」
  * 事業者向け・ワーカー向け表現も追加
  * 実装向け表記がない場合: 「概念・ドキュメント用語として使用」を追加
- 【避けるべき表現】: 避けるべき表現がある場合のみ
- 【使用ガイダンス】: 実用的な使用方法の3項目リスト
- 【補足情報】: 備考がある場合のみ

【トリガー記述】
- 実装向け表記あり: 「「XX」やその関連用語（YY等）に関する質問、実装、ドキュメント作成を行う場合」
- 実装向け表記なし: 「「XX」に関する質問やドキュメント作成を行う場合」

【出力ファイル】
- パス: envs/knowledge/ubiquitous_language.tf
- 自動生成ヘッダー付き
- terraform fmt で自動フォーマット
- data.devin_folder.ubiquitous_language.id 参照（data.tfで定義済み）

【エラーハンドリング】
- CSVファイル存在チェック
- 一時ファイル管理（trap使用）
- 処理結果の統計表示
=== 生成プロンプト終了 ===

上記によって生成した Shell スクリプトを実行すると、以下のような Terraform リソースが作成されます。

resource "devin_knowledge" "ubiquitous_language_53" {
  body                = <<EOT
ユビキタス言語「グループ限定公開」の用語対応ガイド:

【用語の定義】
グループ機能で作成したグループに所属する、特定のワーカーのみに求人を公開する機能

【実装・開発時の検索キーワード】
- コードや実装: 「limited」
- 事業者向け文書: 「グループ限定公開」

【使用ガイダンス】
この用語やその関連概念について質問・実装・ドキュメント作成を行う際は：
1. 上記の適切なキーワードで検索してください
2. 文脈に応じて事業者向け・ワーカー向け・実装用の表現を使い分けてください
3. 避けるべき表現は使用しないでください
EOT
  name                = "ユビキタス言語: グループ限定公開"
  parent_folder_id    = data.devin_folder.ubiquitous_language.id
  trigger_description = "「グループ限定公開」やその関連用語（limited等）に関する質問、実装、ドキュメント作成を行う場合"
}

更新手順

更新ステップは以下の通りです。

1. Notion DB を CSV としてエクスポートし、Terraform を管理しているリポジトリに配置
2. CSV から tf ファイルを生成する Shell スクリプトを実行し、Pull Request を作成
3. terraform plan & apply を実行

現状は手動での CSV エクスポートが必要ですが、 Notion API・MCP などを活用すれば、この更新フローの完全自動化も可能だと考えています。

Devin がどのように賢くなったか

このナレッジを与えたことで、Devin の振る舞いにどのような変化があったかを見ていきましょう。

まず、Devin が knowledge を適切に参照できているかを確認します。

Devin スクリーンショット

確認した結果、数あるユビキタス言語の中から、本当に関連するユビキタス言語のみを参照することに成功していました 🎉

次に、質問に対する回答の精度を比較します。上記のスクリーンショットにあるように、「“limited”という単語は何を意味しますか？」と質問してみました。

【ユビキタス言語 knowledge なしの場合】

「limited」は求人の公開範囲を制限する包括的な機能を表します。

【ユビキタス言語 knowledge ありの場合】

「limited」は求人の限定公開機能を指し、特定の条件を満たしたワーカーのみに求人を表示する仕組みです。

どちらも内容は似ていますが、よりタイミーの社員らしい、解像度の高い回答になったのは「ユビキタス言語あり」のパターンだと感じました。

ナレッジがない場合、Devin はコードベースを広範囲に検索・抽象化して回答を生成するためか、少し曖昧な表現に留まっています。一方、ナレッジを与えた後は、私たちが定義した「意味」に沿って、より的確な言葉で回答できるようになりました。

最後に

生成 AI ツールの進化によって、これまでチームの暗黙知とされてきたものを、いかに形式知として AI に与えていくかが、これまで以上に重要になってきています。

タイミーのエンジニアリング組織はフルリモートという特性もあり、以前からドキュメント化の文化が根付いています。今回の取り組みは、その文化をさらに一歩進めるものになりました。

これからも、AI との協業を前提とした開発体制の構築を進めていきたいと思います。

気づけばDevinのナレッジが山積みに。Terraformで片づけてみた

はじめに

タイミーでPlatform Engineerをしている 徳富(@yannKazu1)です。

2025年2月、私たちの開発組織にAIエージェント「Devin」が導入されました。

Devinは、機能開発のサポートやテストケースの提案など、日々の開発に自然と溶け込む形で活躍してくれていて、今では月に数十〜数百件のマージに関わる頼もしい存在になっています（2025年4月17日時点で489件マージ！）。

そんなDevinと一緒に開発を進めるなかで、ある悩みが浮かび上がってきました。それが「ナレッジの管理が難しくなってきた」ということです。

ナレッジが増えてうれしい、でも……

Devinには「ナレッジ」と呼ばれる、ルールや指針のような情報を登録する機能があります。 「こういうときはこう書く」「こう判断する」など、チームの経験や判断基準をDevinに覚えてもらうことで、より実用的な回答を得ることができます。

ですが、チーム内のいろんなメンバーがナレッジを追加するようになると、次第にこんな状況が生まれてきました：

• どのナレッジが誰の意図で変更されたのかわからない
• 重複したり矛盾した内容が出てきてしまう
• Devinの提案にブレが出るようになった

このままだと、Devinの力を活かしきれない。そう感じた私たちは「ナレッジにもレビューと履歴の管理が必要だ」と考えるようになりました。

Terraformで「Knowledge as Code」を実現してみる

インフラをコードで管理する「Infrastructure as Code（IaC）」のように、ナレッジもコードで管理できたらどうだろう？

そうしてたどり着いたのが、「Knowledge as Code」というアプローチでした。

Terraformを使えば、ナレッジの追加・変更・削除をコードとして記述でき、次のような良いことがあります：

• Gitで履歴が追える：誰がどんな意図で変更したかを残せる
• Pull Requestでレビューできる：ナレッジにブレが出るのを防げる
• terraform planで差分が見える：意図しない変更に気づける
• 他のAIエージェントに移行しても再利用しやすい

「これならナレッジの質も保てるし、チーム全体での共有もしやすくなるはず」——そんな期待を込めて、Terraformによる管理に挑戦することにしました。

でも、Terraform Providerがない……！

とはいえ、Terraformで管理するには専用のProviderが必要です。 調べてみたところ、Devin用のTerraform Providerは世の中に存在していませんでした。

そこで、私は思いました。「それなら、作ってみよう」

Devin Terraform Provider を作ってみた

自作したTerraform Providerでは、以下のような操作が可能です：

👉 Devin Terraform Provider — Terraform Registry

• Devinへのナレッジの作成・更新・削除（devin_knowledgeリソース）
• フォルダー一覧の取得（data "devin_folders"）
• 既存ナレッジの参照（data "devin_knowledge"）

ナレッジの作成

resource "devin_knowledge" "example" {
  name                = "Example Knowledge"
  body                = "This is an example knowledge resource."
  trigger_description = "Use this knowledge when talking about examples."
  parent_folder_id    = "optional-folder-id"
}

フォルダー一覧の取得

data "devin_folders" "example" {
  name = "example"
}

ナレッジの参照

data "devin_knowledge" "existing" {
  name = "Example Knowledge"
}

これにより、ナレッジの変更内容をコードで管理しつつ、レビューを通して安心して運用できるようになりました。

これからのこと

Terraformでのナレッジ管理は、私たちにとってとても大きな一歩でした。 でも、それは「Devinの管理がしやすくなった」だけの話ではありません。

私たちは今、AIエージェントが自然とチームにいる時代に生きています。 そのなかで、単なる効率化ではなく「人とAIが一緒に考え、一緒に働く」開発のあり方をどう作っていくかが重要だと感じています。

タイミーでは日頃から、Notion上にユビキタス言語やチームごとのナレッジが丁寧にまとめられており、ドキュメンテーションの文化が根付いています。 こうした文化があるからこそ、今回のような取り組みも自然な流れとして始められましたし、ナレッジを「コードとして残す」ことにもチーム全体で前向きに取り組むことができました。

これからの開発の現場では、Devinだけでなく、Jules、Cursor、Copilotといった様々なツールが活躍するようになるかもしれません。 そうした多様なAIと気持ちよく協力していくために、私たちは次のような基盤づくりを進めていきたいと思っています：

• Devin以外のAIでも参照できる、再利用しやすいドキュメントとその自動更新の仕組みを整える
  • ナレッジを「読み物」ではなく「役立つデータ」として整理し、どのエージェントでも活用できるようにする
• 「Knowledge as Code」から「Project as Code」へと視野を広げる
  • スプリントの運用方法、CI/CDの流れ、ドキュメントの構成や技術方針までをコードで一元管理し
  • AIがそれらを理解した上で、プロジェクトの流れに沿った提案をしてくれるような世界へ
• 全社的にナレッジを育てていける運用の仕組みを整える
  • 各チームがそれぞれルールを持つのではなく、共通のガイドラインと形式で蓄積・再利用できるようにし
  • 自動化と人のレビューをうまく組み合わせて、スピード感と品質の両立を目指す

こうした取り組みを通じて、ただAIを活用するだけでなく、チームの一員としてAIと一緒に働ける環境を整えていきたいと考えています。

RubyKagi 2025参加レポート（Day3）

2025年4月16日から18日の3日間、愛媛県松山市にて、RubyKaigi 2025 が開催されました。

https://rubykaigi.org/2025/

タイミーでは、昨年に続き、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を活用し、新卒内定者やインターン生を含む総勢16名が現地でカンファレンスに参加しました。 この記事では、現地参加した各エンジニアの印象に残ったセッションとその感想をまとめてお届けします。 今回はその第4回で、Day3の内容をまとめています。 Day1, Day2のセッションに関する内容についてもぜひ合わせてお読みください！

tech.timee.co.jp

tech.timee.co.jp

tech.timee.co.jp

各セッションごとに内容を整理し、参加者自身の視点から学びや気づきをまとめています。読者の皆様にとって、今後の学びの参考になれば幸いです。