「重なり」は迎える側がつくる ― 人もAIエージェントも歓迎するプロダクトエンジニアリング ―

「境界が溶ける」と言われる時代でも、越境は越える側のマインドや動きを主軸に語られがちです。しかし越境が根づくかどうかを決めるのは、迎える側だと考えています。踏み込んだ先に歓迎がなければ、越境は一過性のもので終わってしまいます。

タイミーではプロダクトエンジニアに求める要素のひとつに「越境性」を定義し、あわせて迎える側の整備を進めてきました。開発Handbookは、人が読むだけでなく、越境者が連れてくるAIエージェントが読む前提で書いています。歓迎をマインドで終わらせないよう、ガイドとセンサーで越境者とそのエージェントを支援し、ガードレールで快適に走れるようにしています。

こうした実践から、越境とは一方向の挑戦ではなく相互の設計であり、担う領域は人だけでなく、共走するエージェントも含めたものだと捉え直しました。越境を継続性のある取り組みへ育てた先で、境目は専門性の重なりに変わっていきます。本セッションでは、迎える側のマインドと仕組み、人とエージェントが同じHandbookを読む前提の整備、ガイド・センサー・ガードレールの設計を、タイミーの事例を用いてご紹介します。

Transcript

1. 「重なり」は迎える側がつくる 人もAIエージェントも歓迎するプロダクトエンジニアリング Product Engineering Conference 2026 / 2026-09-05 株式会社タイミー VPoE 株式会社タイミーフィナンシャル 取締役 赤澤 剛（@go0517go） 1
2. 自己紹介 赤澤 剛 @go0517go 株式会社タイミー エンジニアリング本部 VP of Engineering 株式会社タイミーフィナンシャル 取締役 2009-2018 株式会社ワークスアプリケーションズ（SWE, VP） Works Applications Singapore Pte. Ltd.（VP） 2018-2020 LINE Financial株式会社（Technical PjM） 2020-2024 株式会社ユーザベース 株式会社アルファドライブ（執行役員CTO） 株式会社NewsPicks for Business（取締役） 2024株式会社タイミー（VPoE） 2026株式会社タイミーフィナンシャル（取締役） プロレス・ゲーム・アニメ・漫画・特撮ヒーローが好きです！「ええやん！」が仕事をする上でも口癖なので、最近は VP of Eeyan といじられたりもしてます。 2
3. Agenda タイミーはどんな会社か 越境が根づくかどうかは、迎える側で決まる 迎える相手は、人だけではない 越境は過程であって、到達点ではない 少しでも参考になる部分があれば、と思ってお話しします 3
4. タイミーはどんな会社か スポットワークの会社、だけではない 4
7. 金融事業もスタート 株式会社NTTドコモ及び株式会社ドコモ SMTBネット銀行（旧 住信SBIネット銀行 株式会社）と金融領域における業務提携に 関する基本合意書を締結 2026年7月に金融関連ソリューション等 の事業化に向けた子会社、株式会社タイミ ーフィナンシャル設立 出典: 株式会社タイミー コーポレートサイト「ニュース」（対外公表情報のみ） 7
8. タイミーの事業は、 エンジニアリングそのもの 適切に属人性を下げて、組織と状況に再現性と継続性を与える → タイミーは、エンジニアにこそ合っている事業だと思っている 8
9. お客様の現場でやっていること（BPR） 今日はじめて来てくださる方が、スムーズに把握して活躍できる状態を、お客様と一緒につ くる 業務プロセスの分析 現状の業務を棚卸しし、必要 な経験や判断の度合いで整理 する スポット業務の切り出し はじめての方でも担当しやす い単位に分解し、手順を再構 成する 手順書・ワークフロー化 属人的なハンズオンだった手 続きを、初めて来てくださっ た方でも活躍できるプロセス にする 初めての方でも活躍しやすいように、お客様と共にプロセスをアップデートする 9
12. 越境は、迎える側で決まる ここからが本題 12
13. 「越境する」と「越境される」 越境する側 職能の壁を越えて、プロダクトの価値に 向き合う 意欲・学び・踏み込む勇気 よく語られるのは、こちら 越境される側（迎える側） 踏み込んできた人が、止まらずに進める 状態をつくる 読めばわかるもの・ずれを知らせるも の・危ういところで止めるものが、最初 から用意されている 今日話すのは、こちら 越境する側の意欲は前提。根づくかどうかを分けるのは、越境される側の設計 13
14. 越境が根づくかどうかは、 迎える側で決まる 越える側の意欲は前提。それがなければ始まらない ただ、踏み込んだ先に歓迎がなければ、越境は一過性で終わる 14
15. 専門家のレビューをガードレールにしない 却下した案: バックエンドエンジニアによる Approve を「必須の関所」にする チーム内のレビューと、難しい設計判断の相談は今もある ただし、専門家の Approve を必須の関所にした瞬間、速度は落ちる 関所の代わりに置いたもの → ガイド・センサー・ガードレール（後述） 15
16. 差が出るのは、実装ではなくその手前 後から直しにくい 概念（何が存在するか） モデリング テーブル設計 手前ほど、差が出る 実装 後から直せる バックエンドエンジニアが何を考えながら開発しているか、外からは見えない → 見えない部分を言語化した 開発Handbook 16
17. 開発Handbook 全体: はじめに・設計・ 実装レビュー・QA…と領 域ごとの Handbook が 並ぶ バックエンド版: 対象範 囲・想定読者・目次。越 境してくる人が読む前提 で書いてある 人はブラウザで読み、エ ージェントはスキルとし て読む（次） 17
18. 迎える相手は、 越境者本人だけではない 越境してくる人は、多くの場合AIエージェントを連れてくる → Handbookは、人が読み、エージェントも読む前提で書く 18
19. Handbookを、エージェントが読める形にする 層 実体 Handbook本体 GitHub Pages。人はブラウザで読む Reference Skill 1ページ = 1スキル。設計・レビューの場面でそのページを読みに行く 理解・モデリング・設計・実装・法務チェックの各フェーズ。必要なページをエージ Workflow Skill ェントが自分で選ぶ バックエンドのリポジトリでは、このスキル集がプラグインとして最初から有効（Claude Code） 19
20. 指摘の隣に、根拠が置いてある 開発Handbook 参照 AIレビュー PR コメント 末尾に「Handbook 参照:」＋根拠のリンク 指摘が微妙なら、直すのは Handbook のほう AIレビューはHandbookの関連する章を読んでから指摘し、根拠のセクションへのリン クを添える 指摘が微妙なら、直すのはレビューの設定ではなく Handbook 障害 → 「この観点のレビューがあれば」 → 「Handbookに盛り込もう」 20
21. 迎える側が用意する3つのもの ガイド 行動の前に、何を考えてから 手を動かすかを示す （feedforward） Handbook ＋ 読むスキル 取り返しのつかない領域は、 該当ファイルを触るときに必 ず読み込まれるルールに センサー 行動の後に、ずれを検知して 知らせる（feedback） 推論型: Handbookを読んだ AIレビュー（根拠つき） 計算型: 静的解析・型検査・テ スト ガードレール 計算型のセンサーが通らなけ れば、ターンを差し戻す ターン終了ごとに、変更した ファイルへ自動で走る（差し 戻しは最大3回） 人の判断ではなく、機械が止 める 判断の質はガイドとセンサーで支え、止める役だけを機械に ガイド／センサーの整理は Harness Engineering（B. Böckeler, Thoughtworks）に拠る 21
22. 越境は過程であって、到達点ではない 越境 重なり A B A B 境目があって、それを越える 止められなければ、越えた人はそこに留まる 「自分の専門はここまで」と自分で線を引い 留まる人が増えるほど、専門性のふちが広が ていたからこそ、必要だった言葉 って重なる 境目は、専門性の重なりに変わる 22
23. まとめ 1. 越境が根づくかどうかは、迎える側で決まる — 出発点は「専門家のレビューをガードレールにしない」 2. 迎える相手は、人だけではない — 同じHandbookを人とエージェントが読むと、ガイドとセンサーが揃い、止める役は 機械に任せられる 3. 越境は過程であって、到達点ではない — 止められなければ人は留まり、専門性のふちが広がって重なる 23