「越境」に漂う3つの不安

河治：FDEやプロダクトエンジニアという言葉が最近よく耳にされるようになっています。実装をするという役割から、バリューを出すという役割になっていく。そんな変化が見えてきているからこそ、このままエンジニアリングで生き残れるのだろうかと感じている方も多いのではないでしょうか。

一方で、経営者や周囲から「越境しよう」「業務にしみ出そう」という話をされる機会も増えています。いざ言われてみると何をすればいいかわからない。わからないままとりあえずやってみると、仕事の種類が増えていくだけになってしまい、本来やりたかったバリューの発揮につながらないという体験になりがちです。

実際に越境してみると、社内調整、ステークホルダーとの期待値調整、業務フローの把握・整理、顧客ヒアリングといった、これまでやったことのない仕事が次々と出てきます。エンジニアとしてこれまで磨いてきた開発スキルが急に通用しなくなる感覚があり、試行錯誤がどうしても必要になります。加えて、本来エンジニアとして発揮したかったバリューが満たされたのかが分からなくなるという問題もあります。仕事が増えた事実は残るけれど、それが本当に価値につながっているかが見えないという状態です。




越境への不安の正体とは、能力の問題ではなく、準備のないまま仕事と役割が増えていくことにあります。「慣れていない」「やったことがない」「失敗が許されない」という3つの要因が重なることで、認知負荷が高く不確定要素が大きく予想も立てられない状態になっています。顧客と近い距離でやることになりやすいので、失敗が許されづらく、失敗を防止できる対策も打ちづらいという状況でもあります。

まるで勉強せずにテストに臨むようなチャレンジです。これだけ条件が重なれば、不安がどんどん大きくなるのは当然のことです。ただ、越境自体は本当は怖いものではありません。準備をした上でやることで、楽しい未来につながるチャレンジになります。

生成AIの登場で「プロダクトエンジニア化しよう」「FDEとして動こう」という話が加速していますが、それはあくまで外から来た動きです。この発表では、その先に本当に必要なものとは何かを、グラファーの実践を交えながらお伝えしたいと思います。

「越境」の本質。目的ではなく手段

越境とは何かを改めて定義するところから始めます。辞書的には「境界を越えて移動すること」とされていますが、エンジニアリングにおける越境とは「ユーザーへの価値提供や本質的な課題解決のために、自らの専門領域・役割・チームといった人為的な境界（サイロ）を自発的に飛び越え、協働すること」と捉えています。最も重要なキーワードは「価値提供」です。




越境は目的ではなく、あくまでも手段です。越境によって本来得られるものは3つあります。1つ目は「解像度を上げる」こと。チケットや要件書を通じてしか把握できなかった顧客の実情が、直接の対話を通じて見えてくる。それがエンジニアとして提供できる機能の質を格段に上げていきます。2つ目は「信頼を強くする」こと。解像度が上がることで直接やり取りできるようになり、その積み重ねが顧客との信頼関係になっていきます。3つ目は「機会を掴む」こと。顧客との関係が深まることで、従来だと気づけなかった、あるいは引き出せなかったビジネスチャンスが見えてきます。

これらを目的にしてしまうと、越境した事実だけが残り、顧客への提供価値につながらないという状態になってしまいます。越境は手段であって、その先にある価値提供にちゃんとつながっているかどうかが問われます。

役割の「拡張」と「膨張」

越境を端的にやってしまうと何が起きるかを考えてみます。




役割の「膨張」とは、自らの意思とは関係なく先にやることが増えていく状態です。外から仕事が押し寄せてきて認知負荷だけが増え、役割の定義が広がったのではなくただ負荷が増えただけという体験になります。役割の外のものをどんどんやっていくと、それがそのまま役割の膨張につながっていきます。

一方、本来の越境は役割の「拡張」であるべきです。拡張とは、やるべきことをちゃんとこなした上で自分の意思で着手するという状態です。降りかかってきたから仕方なくやるのではなく、自分の意思でやってみようと動く。そういったあり方が、越境の本来の姿です。




越境することで何が変わるかというと、顧客から情報収集する手段の拡張と、提供すべき機能の見極めの精度の変化です。VoCチケット対応よりも精度高くヒアリングができる、オンラインに加えて対面という手段が追加される。顧客との情報交換が充実し、価値提供機能において必要な情報をより正確に獲得できるようになります。

真に価値があるのは、顧客の要望に対して本質的な提供価値につながる機能を提供するという「泥臭い仕事」です。文書には出てこない本質的課題を掴みにいく、品質・拡張性を担保した上で機能に翻訳する、他の顧客にも応用が利く「売れるもの」を作る。そういったことがエンジニアとして提供できる本当の価値です。このAI時代においても、この部分は今すぐ人間以外が精度を上げることはできないため、ここが人間の独占的な価値になるというのが私の見立てです。

「越境」へのアプローチ。3つのステップ

越境を正しく進めるには、どのようにアプローチすればいいでしょうか。3つのことが重要だと考えています。

既存の役割を効率化・省力化、あるいはやめる

何か新しいことを始めようとすると、役割がどんどん積み上がっていきます。そのため、まず今持っている役割でやらなければならないことを効率化・省力化するか、思い切ってやめるという選択肢を取ることが重要になります。本当にこれをやる意味があるのか。そう判断できる余地があれば、大胆にやめることも大切な意思決定です。

こうして役割が絞られてくることで、新しいことに着手できる余地が生まれてきます。「省力化」「業務の整理」「効率化」「無価値ならやめる」。この順番で向き合っていくことが越境を正しく進めるための最初のステップです。

AIに作らせるプロセスを設計する

AIを使って課題を解決するというだけでは不十分です。大事なのは、課題を解決しながら同時に「再現性」を作っていくこと。これはAIのハーネスを整備していくことに当たります。

端的なAI利用の取り組み方だと、課題に着手してプロンプトを作り、成果物をレビューしてAIで修正してリリースして終わり、結局そのプロンプトを逐一なぞったり、人の手でドキュメントを確認したりしないといけないので、これでは従来の開発手法にAIを組み合わせただけで、人がプロセスそのものを削減できている状態ではない形になりがちです。それに対して再現性を伴った取り組み方では、課題解決に必要な情報をDoc化し、AIが最短で到達できる場所に保管していくということを並行して進めます。再現性を上げることを重要視するというのが、単なるAI利用からプロセス設計へというシフトの意味するところです。

問いを作る・問うべきものを決める

越境で未知なことに取り組む際、商談の仕方や顧客課題の深掘りの仕方といった「How」に注目されがちです。しかし本当に重要なのは、そもそも「何を問うべきか（What）」を理解することです。

開発・設計・実装といったこれまで経験してきた業務では、達成すべき目標がわかっているためHowを問えば済みます。一方、要求・要件定義やヒアリング、社内調整といった「越境」でやることになる業務は、達成すべき目標がわかっていないため、まずWhatを問わなければなりません。顧客から何を引き出すべきなのかを考え、相手の心理状況やシーンの仮定を置いた上でロジックを作っていく。そういったWhatから始めるアプローチが、未知の業務を進める上で欠かせないステップです。

AIが変えるエンジニアの役割。3つに収束する未来

AIの業務への浸透と、やるべきことの選定・廃止を繰り返していくと、最終的にエンジニアリングで必要なものは大きく3つに収束すると考えています。「開発作業の監督・レビュー」「要件締結・デリバリとフィードバックの解釈」「ハーネスの管理・評価」です。

現在は人間とAI（またはAIエージェント）が成果物を一緒に作っている協業状態です。これからは完全な分業へとシフトしていきます。設計・コーディング・具現化・可視化、データモデルやプログラム・システムの生成はAI/AIエージェントが担い、人間は顧客との要件締結、フィードバックの解釈と反映、顧客への機能提供と改善施策の実行、そしてハーネスの管理・評価・改善点の抽出に専念することになります。

AIによって仕事が奪われるというよりも、人間がやるべきことが明確に絞られてくると見た方がポジティブです。越境を通じて顧客の解像度を上げ、信頼を築き、ビジネス機会を掴む。そういった力を磨いてきたエンジニアこそが、この収束する先で価値を発揮できます。越境で培った顧客との対話力と、ハーネスを通じてAIを制御する技術力。この両輪がこれからのエンジニアに求められる核心になっていきます。

グラファーが実践するフルサイクル×AI駆動開発

グラファーは創業当初からプロダクト志向×多能工というアプローチを一貫して採用しています。ユーザーの業務知識と課題を少人数に集約し、分業的ではなく一気通貫でプロダクトを作るというものです。グラファーは「価値を生まない手順をなくす」ことをミッションの核として、Govtech領域や食品・飲料業界、AI駆動開発領域で事業を展開しており、2026年1月にミッションを「We Remove Steps.」へと刷新しています。Graffer Platformでは自治体を中心に273団体への導入実績があり、Findy Team+ Awardを2年連続で受賞、直近のリリース頻度は9.4回/日（2026年5月集計）に達しています。

かつては数人のメンバーでスモールスタートしてプロダクトを立ち上げていましたが、AIの登場によって今では1人＋AIでプロダクトを立ち上げることへとシフトしています。去年のリリース頻度は6〜7回程度だったのが、最近の集計では9.4回/日にまで向上しており、DORAと呼ばれる生産性のメトリクスで見ても相当高いレベルになってきたというところです。




フルサイクル開発体制では、エンジニア一人ひとりが課題発見から要件定義・設計・実装・テスト・リリース・運用までを分業することなく一気通貫で担います。各プロセスでAIを伴いながら判断・承認・改善を行うことで、AI駆動開発の効果を最大化しています。AIが登場する前は複数人で協業しながら1人がオーナーシップを持つ形でしたが、今は事実上1人でこなすということが実現されています。

グラファーでは、このフルサイクル開発を実現するための具体的な取り組みを3つ紹介しています。

Devinによる仕様確認問い合わせの自動化

1つ目は、Devinの導入によるSlack経由の仕様確認問い合わせの自動化です。従来は仕様調査・確認・報告という一連のプロセスをエンジニアが担っていましたが、AIに託すことで回答品質を落とすことなく作業を大幅に削減し、エンジニアは開発作業に集中できるようになりました。これまでに仕様回答でミスがあったというトラブルは起きていません。

クラウドシフト案件でのAI駆動リバースエンジニアリング

2つ目は、受託しているクラウドシフト案件における、基幹システムのリプレイスへのAI駆動開発の適用です。基幹システム開発は複雑大量のソースコードを扱うため全体把握が困難で、ドキュメント更新も追いつかなくなり形骸化しがちです。従来は人海戦術によるリバースエンジニアリングが必要でしたが、AIによるリバースエンジニアリングと人手による監督、規則・制約条件の記述を組み合わせることで進めています。ドキュメント管理もAIフレンドリーなフォーマットに変え、コードと完全に同期した仕様書を整備することで、AIが次の開発でも同じ判断軸で動けるようになっています。

未経験から1人で事業を立ち上げる

3つ目が、未経験から1人で事業を立ち上げた事例です。エンジニア業務の経験は豊富でも事業開発は初めてだったメンバーが、AIをフル活用しながら不足した知識・知恵を補いつつ、ニーズ発見・市場探索・事業立案・顧客提案を1人でやり遂げ、その後の課題定義・要件定義・設計・実装・テスト・運用まで一貫して担当しています。これがGraffer Databridgeというプロダクトの立ち上げにつながっています。

グラファーでは創業当初からのフルサイクル開発というスタイルを発展させながら、1人のエンジニアがオーナーシップを持ち、AIと共に課題発見から運用まで担う体制を整えています。エンジニアリングが本来持つべき価値、つまり顧客の課題を深く理解して正しいものを作り切る力を最大化するための環境づくりを、これからも続けていく予定です。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
エンジニアの役割の変化に向き合うConference

※動画の視聴にはFindyへのログインが必要です。