ContractS開発者ブログ

契約マネジメントシステム「ContractS CLM」の開発者ブログです。株式会社HolmesはContractS株式会社に社名変更しました。

「ゴール未達が当たり前」になったチームに、どう介入するか — 仕事終わりのスクラムマスター道場 Vol.3 参加レポート

はじめに

先日、レッドジャーニー主催のオンラインワークショップ「【ワークショップ】仕事終わりのスクラムマスター道場 Vol.3 〜実践知を持ち寄り、介入を学び合う場〜」に参加しました。

ファシリテーターはレッドジャーニーの瀬川晋平さん。「スクラムマスター道場」は、"こんな時、あなたならどうする…?" というお題に対して、参加者それぞれの実践知を持ち寄り、チームへの「介入」を学び合うワークショップ形式のイベントです。

じつは瀬川さんは、私が以前スクラムマスターをやっていた頃にアジャイルコーチとして伴走してくださった恩師です。スクラムマスターとは何か、チームにどう向き合うかを一から教わった相手。その方が主催する道場に参加できるとあって、申し込んだ時点から楽しみにしていました。久しぶりに学ぶ側に戻れる、貴重な機会でもありました。

今回の題目は 「ゴール未達が当たり前になったチーム」

スプリントゴールを立てても達成できない。それが一度や二度ではなく、いつの間にか「まあ、いつものことだよね」と誰も気にしなくなっている——そんなチームに、スクラムマスターとして(あるいはマネージャーとして)どう向き合うか。

私はContractSのFDE(Field Development Engineering)チームでマネージャーをしています。チーム運営に日々向き合う立場として、このテーマはまさに「自分ごと」でした。学びと、自分なりに考えたことを共有します。

「部活の雰囲気」で、正解のない問いに向き合う

このイベントの面白さは、講義形式ではなくワークショップ形式であるところです。

今回参加したのは、恩師に再会できることもあったのですが、ワークショップ形式で自分で考え、そして参加者と一緒に学び、お互いの知見や意見により、自分では気づけなかった発見、学びがあることです。 この経験がスクラムマスターには絶対的に必要で、絶対的に足りていないと感じていました。 私も今でこそマネージャーをやっておりますが、マネージャーとしての動きにも言えることだなと考え、参加しました。

冒頭で示されたグランドルール。これがしっかり最初に擦り合わせられるのはとても良いですね。 目指すのは 「部活の雰囲気」。気楽に過ごしましょう、互いに顔馴染みになっていきましょう、というスタンス。 そして 「正解はない」。ここはスクラムマスターにとっての練習の場であり、互いに学び合う機会にしよう、と。

「正解を教わる場ではない」と最初に宣言されることで、変に身構えず、自分の考えを素直に出せる空気ができていました。介入のような繊細なテーマこそ、この心理的安全性の設計が効いてくるなと感じました。

ワークの流れ:違和感 → 構造の深掘り → 介入 → 現場で試す

進め方は、Miroボードで付箋を貼りながら段階的に深めていく形でした。ざっくりこんな流れです。

  1. 音声を聞いて「違和感(ここが変)」を書き出す — まず、あるチームの状況が音声で提示され、「どこが引っかかるか」を各自付箋に書き出す。
  2. 自己紹介&共有 — 名前だけの軽い自己紹介と、書いた違和感をグループで共有。
  3. 「なぜこの現状が起きているのか」を深掘りする — 出てきた違和感に対して、その背後にある構造をみんなでディスカッション。ここが一番の肝でした。
  4. 「あなたならどう働きかけるか/何て声をかけるか」を考える — 自分の付箋だけでなく、他の人が書いた付箋も含めて、具体的な介入・声かけを考えて書く。
  5. 共有 — 考えた介入をグループで共有。
  6. 今日の気づき/現場で試してみたいことを書く — 持ち帰りを言語化。
  7. 焚き火トーク — 最後は「ふりかえりについて、でもなんでもよい」とゆるく雑談。

いきなり「どう解決するか」に飛びつかず、「違和感」→「なぜ(構造)」→「どう介入するか」 という順番を踏むのがよくできていると思いました。問題への介入は、原因の構造を理解しないと的外れになりがちです。この順番自体が、現場でそのまま使える型だなと感じました。

お題:あるチームのスプリントレビュー

題材は、音声で流れる「あるチームのスプリントレビュー」の一場面でした。 ざっくり要約すると、こんなやり取りです。

  • PO「今回のスプリントゴールは達成できましたか?」
  • メンバーA「全部は終わらなかったですね」
  • PO「今回のスプリントゴールは何でしたっけ?」/メンバーB「『会員登録機能を完成させる』ですね」
  • PO「完成というと、どこまでを想定していましたか?」
  • メンバーA「会員登録、ログイン、パスワード再設定、確認メール、それとエラー表示までですね」
  • (最終的に完成したのは会員登録とログインのみ。残りは次スプリントへ持ち越し)
  • メンバーB「全部終わることって、あまりないですよね」/メンバーA「毎回何かしら次に持ち越してますしね」
  • PO「もし次も『会員登録機能を完成させる』だったら、また終わらない可能性はありませんか?」
  • メンバーB「でも、スプリントゴールって大きい方がチームの目線は合わせやすいと思うんですよね」
  • PO「私は『初めてのユーザーが登録できるようになる』だけでも十分価値があると思っていました」
  • スクラムマスター「では、このあたりは次のスプリントプランニングでもう一度話してみましょう」

一見すると「アジャイルだし改善しながら進められて良かったね」で流せそうな、和やかなレビューです。でも、よく聞くと引っかかるところが山ほどある。それを付箋に書き出していきました。

「ここが変」:場に並んだ違和感

グループで違和感を出していくと、こんな言葉が付箋に並びました。

  • 「完成の定義が曖昧」 — 「会員登録機能を完成させる」の"完成"が、人によって指す範囲が違う。
  • 「なんでしたっけ、ってなっている状態も問題では?」 — チームがスプリントゴールを覚えていない。
  • 「POはレビューの場でそれを知ったの?」 — スプリントの途中でPOとチームの対話がない。
  • 「毎回持ち越し」を誰も問題視していない — 未達の常態化。
  • POの価値仮説とチームの認識のズレ — POは「登録できるだけで価値がある」、チームは「大きいゴールの方が目線が合う」。同じ言葉で全く違うものを見ている。

そして個人的にいちばん刺さったのが、このチームはレトロスペクティブ(継続的な改善活動)を行なっていないことでした。改善のきっかけになりそうなことがいくつか出てきているのに、それを放置してしまっている。 継続的な改善はアジャイル開発にとって大事な要素の1つなのにそれが仕組みとして抜け落ちてしまっている。 それが定常的に続いてしまったら、そりゃそうだよね、と感じました。

「なぜ起きるのか」:構造を深掘りする

次のステップは、この違和感が「なぜ」起きているのかの構造の深掘りです。ここが一番熱い議論になりました。出てきた見立てを整理すると——

  • ゴールが「作業リストの合計」になっている:会員登録・ログイン・パスワード再設定・確認メール・エラー表示…と機能を盛りすぎて、「何のために」が消えている。だから未達でも「全部は終わらなかったね」で終わる。
  • 完成の定義(受入基準)が握れていない:どこまでやれば完成かの合意がないまま走っている。
  • POとチームの距離:「POはチームから遠い存在なのかも」「同席する頻度が少なかった」「判断を求めなかった」。コミュニケーションの頻度と質の問題。
  • 成功体験の欠如:「具体的なゴールの方が終わらせやすい、という体験がないから」大きく曖昧なゴールを立て続けてしまう。
  • 改善が"先送り"され続ける:未達の議論を「次のプランニングで」と先送りし、ふりかえりのループがそもそも始まっていない。

付箋の中で忘れられないフレーズが2つありました。「詰め込みすぎ成功体験」「余白=悪」。予定を詰め込むことが正義になっていて、余白を持つことが悪だと感じている——この価値観こそが、未達を生み続ける構造の根っこなんじゃないか、と。とても鋭い言語化だと思いました。

未達が続くと、チームは「どうせ今回も終わらない」という前提で動き始めます。これは学習性無力感に近い状態で、放っておくと当事者意識がどんどん削られていく。だからこそ「介入」が必要になる、というのが今回のテーマの背景だと腹落ちしました。

「どう働きかけるか」:介入を考える

構造が見えたら、次は「あなたならどう働きかけるか/何て声をかけるか」。ここが道場の本題です。

面白かったのは、介入案にもかなり幅が出たことです。たとえば 「未達だったものは一度全部捨てて、理想のスプリントゴールの設定からもう一度プランニングをやり直す"実験"をしてみる」 という大胆な案。これには「🔥」「🚀」と反応が集まっていました。一方で 「プランニングで言い直すのか、ふりかえりで扱うのか」 という、介入する"場"の選び方に注目した意見も。同じ問題でも、どこで・どう声をかけるかで打ち手が変わる。まさに実践知の持ち寄りでした。

私が「自分のチームでこれが起きたら」と考えたのは、まず 「未達を責める」のではなく「ゴールの意味を取り戻す」介入です。

「なんで達成できないの?」と問い詰めても何も変わりません。むしろ「そもそもこのゴールで何を届けたかったんだっけ?」を問い直したい。今回の寸劇でいえば、POの「登録できるだけでも十分価値がある」という仮説がチームに共有されていなかった。ここのズレを埋めることが最初の一手だと思います。完成の定義(受入基準)を一緒に握り直すところから始めたい。

次に、ゴールのサイズを"確実に届く"単位に落とす。「詰め込みすぎ成功体験」から抜けるために、あえて小さく区切って「達成できた」感覚を取り戻す。余白を持つことは悪じゃない、と体験として示したいです。

そして、ふりかえりで未達を正面から扱う場を作る。未達を「事実」として淡々と、感情ではなく仕組みの問題として扱う。前回のレポートで書いた「セーフティネットとしての自動テスト」の話ともつながりますが、チームが安心して問題に向き合える土台があるかが効いてきます。

AI駆動開発の時代に、この問いはどう変わるか

もう一つ、自分の文脈で考えたことがあります。

私たちのチームはAIコーディングエージェント「Kiro」を日常的に使っていて、実装のスピードは上がってきています。ただ、スピードが上がったからといって「ゴール達成」が自動的についてくるわけではない。むしろ、速く動けるようになった分、「何を達成したいのか」というゴール設定の質がこれまで以上に問われると感じています。

前回参加したイベントで「開発が速くなるとバックログが枯渇する」という話が刺さったのですが、今回の「ゴール未達が当たり前」というテーマは、その裏側の問題のように思えました。速く作れるのにゴールに届かないとしたら、それは実装能力の問題ではなく、ゴールの立て方・向き合い方の問題です。AIが実装を担うほど、人間が担うべき「ゴールをデザインする力」の重要性が増していく。そう再認識しました。

もう一つ、これはAI時代だからこそ効いてくると思うのが、ふりかえりや意思決定のログを貯めて学習資産にするという発想です。未達が常態化するチームは、たいてい「なぜ届かなかったか」が記録に残らず、毎回ゼロから同じ議論を繰り返しています。逆に、スプリントゴールの立て方・完成の定義・未達の理由といった判断の履歴を残しておけば、チームの学習は積み上がっていく。私たちのチームでも、要件やIssueを言語化してKiroに委任するスタイルを取っていますが、その過程で残る「なぜこう決めたか」の記録は、そのままチームの財産になります。介入の効果を測るうえでも、ログは強力な味方になりそうです。

おわりに

「ゴール未達が当たり前になったチーム」という題目は、耳が痛い人も多いテーマだと思います。私自身、完全に他人事とは言えませんでした。

このワークショップで一番よかったのは、答えを一つに決めるのではなく、いろんな介入の選択肢を持ち寄って引き出しを増やせたことです。チームの状態は千差万別で、効く介入も一つではない。だからこそ、実践知を持ち寄る場に価値がありました。最後は「焚き火トーク」と称して、参加者同士が自分の現場のリアルをポツポツ話す時間もあり、この肩の力が抜けた空気こそが「部活の雰囲気」だなと感じました。

持ち帰った一番の学びは、介入は「解決策」からではなく「違和感」から始めるべきだということです。今回のように「違和感 → なぜ(構造)→ どう働きかけるか」の順番で丁寧に降りていくと、表面的な対処ではなく根っこに手を当てられる。そして何より、改善のきっかけになりそうな小さな引っかかりを放置せず、言葉にして場に出すこと。それ自体が最初の介入なんだと気づきました。まずは自分のチームのふりかえりで、「今のスプリントゴール、何のためだっけ?」を改めて問い直すところから試してみます。

スクラムマスター道場はシリーズで開催されているので、また参加して実践知を増やしていきたいと思います。

参考

AI駆動開発時代、コードの品質とセキュリティをどう守るか

はじめに

最近、セキュリティ関連のウェビナーに参加して、1つびっくりしたことがあります。

「仮に、自分たちがAIを使わない選択をしていたとしても、依存しているOSSにはすでにAI生成コードが入っている」ということです。

自前で全て作っているアプリやサービスでなければ、気づけばAIが書いたコードの上で動いている。世の中の流れは自分たちの意思とは関係なく進んでいて、もうこの流れを止めることはできないほど、AIが世の中に浸透してきていることを強く実感しました。

その昔Googleが出てきて「ググる」が日常になったように、開発のやり方も急速に変わってきている。気づけば自分の中でも行動変容が起きている。。

もう「使うな」では止まらない

いくつかの調査データを見ると、その加速具合がよくわかります:

  • 2028年までに75%の開発者がAIコードアシスタントを利用予定(Gartner)
  • 現状25%のコードがAI生成、2030年までに95%へ(Microsoft)
  • AIコーディングアシスタントの使用を禁止している企業のうち、76%がポリシー違反の利用を認識(2026 OSSRAレポート)

特に3つ目の数字は印象的でした。禁止しているのに76%が使っている。 ただ、それだけみんなAIに興味があるし、実際にやってみて便利で役に立っているから使いたくなってしまう。 その気持ち、とってもよくわかります。

AIが書くコードのどこが危ないのか

これまでの経験から、コード生成においては、AIはかなり進歩を感じています。 時に動かないプログラムだったこともあれど、よほど抽象的な指示をしなければ、かなり正確にこちらの意図を汲んだコードを生成してくれるなという実感があります。 ただ、AIも必ずしも完璧なコードを生成してくれるわけではないというところは考えさせられましたし、もっともなことだと思いました。 AIの学習データにも、脆弱性を含むコードがきっと含まれているし、世の中にはそういうコードが溢れているだろうから、それを元に吐き出すAIのコードも同じように脆弱性を含むコードを生成してしまうこともある。当然と言えば当然ですね。

しかも、全く同じ指示でも毎回同じコードを生成してくれるかというとそうではないといったお話も「確かに」と思いました。

AIは「当たり前」を汲み取ってくれないんですよね。セキュリティ要件は暗黙知が多いからこそ、明示的な指示や検証の仕組みがないと品質を担保できない。この辺りはまだまだ仕組みで補っていく必要があるなと気づかされました。

AI開発の段階と、自分の現在地

ふりかえると、最初はChatGPTやGeminiに質問して答えを聞く→聞いた内容を元に自分の手で編集する、というのが主流でした。それが徐々に、AIに作業の一部や全体をやってもらうスタイルにシフトしていったように思います。

サブエージェントを駆使して作業を任せるところは一部やっていますが、複数のAIが自律的に動いてコードを書いてくれるような使い方はまだまだです。それでも日々AIを使っていく中で、もうAIが欠かせない重要な存在になってきているなと感じます。

そしてここで問題になるのは「AIが書いたコードを人間がどこまでレビューできるか」ということです。

AIが自律的に書くコードの量がさらに増えてくると、全部人力でレビューするのは無理が出てきます。ツールによる自動検証を前提にした開発フローを考えておく必要があると思っています。

攻撃側もAIを使う時代

もう1つ深刻だなと思ったのが、攻撃側もAIで武装しているという現実です。

今後さらにAIの進化が進み、高度なAIモデルが世に出てくると、攻撃する側のスピードも格段に速くなります。脆弱性の発見・悪用のコストとスキルレベルが大幅に低下し、これまで専門知識がなければできなかった攻撃が、ずっと手軽にできるようになってしまいます。

ということは、こちらも素早くパッチを適用していかないと、ほったらかしにしている間に攻撃されてしまう。そんな危険を孕んでいることに危機感を覚えました。

これを「脆弱性パッチの洪水」と表現していたのを聞いて、「なるほど」なと思いました。 発見される脆弱性が爆発的に増え、脆弱性を発見してから攻撃までの時間が劇的に速くなると、これまでの「脆弱性が公開されたら数ヶ月かけてパッチを当てる」サイクルでは、もう間に合わなくなります。修正サイクルそのものの見直しが急務だと感じました。より一層、CI/CDやDevSecOpsの最適化が求められる時代になっていきますね。

じゃあどうするか

自分のチームでも考えていることとしては、静的解析をCI/CDに組み込んでAI生成コードも人間のコードも同じ基準で自動チェックする仕組みを作ること。それからパッチ適用サイクルの短縮もチームとして向き合うべき課題だと思っています。

「速く書ける」だけで終わらせず、品質とセキュリティを仕組みで担保していく。それが次のステップですね。

まとめ

  • AI生成コードは便利ですが、品質・セキュリティの検証は人力では限界があります
  • ツールによる自動検証をCI/CDに組み込む必要があります
  • 攻撃側もAIで高速化しています。修正サイクルの見直しが急務です
  • 本質は「使うな」ではなく「どう安全に使うか」のガバナンス設計です

AIで速く書けるようになった分、品質・セキュリティの担保にどう向き合うかというのは新たな課題です。速さもさることながら、安全・品質のバランスを仕組みで解決していかなければと思っています。

参考資料

AI駆動開発で速くなった"その先"に何があるか — 「AI駆動開発 × アジャイル開発」参加レポート

はじめに

先日、レッドジャーニー主催のオンラインイベント「AI駆動開発 × アジャイル開発 〜生成AIでアジャイル開発はどう変わるのか?〜」に参加しました。

スピーカーはレッドジャーニーの田中基淳さん。AI駆動開発の「その先」について、ライブデモを交えながら語ってくれるセッションでした。

私はContractSのFDE(Field Development Engineering)チームでマネージャーをしています。チームではAIコーディングエージェント「Kiro」を日常的に活用しており、まさに実践者として共感する内容が多かったので、学びと実感を共有します。

ライブデモ:AIが実装している間に、人間は別のことをする

イベントの冒頭で、印象的なデモがありました。

あらかじめ参加者全員に共有されていた、イベント中に実際に使っていた質問投稿サービスに「いいねボタンを追加する」というシンプルな要求を題材に、AIに設計から実装、デプロイまでを任せるというもの。

面白かったのはその演出です。AIに指示を出した後、裏で設計・実装が進んでいる間に、田中さんは本編の資料を使ってAI駆動開発についての説明を始めました。そして説明を聞いている20〜30分の間に、実際に自分の手元のサービスにいいねボタンが追加されていた。

「AIが働いている間に、人間は別の価値ある仕事をする」——これはデモの演出であると同時に、AI駆動開発の本質を体現していました。

刺さったポイント①:バックログが枯渇する

セッションの中で最も刺さったのは、「開発が速くなった結果、次のバックログが枯渇していく」という指摘でした。

実装速度が上がるのは良いこと。でも「次に何を作るべきか?」の供給が追いつかなくなる。だからこそプロダクトマネジメント、仮説検証がより重要になる——人間がボトルネックになる、と。

これはまさに自分のチームで起きていることでした。メンバーがKiroを活用して自走できるようになり、生産性が上がってきたタイミングで、「じゃあ空いた時間で何をするか?」が次の課題として浮上していたのです。

私たちFDEは、CLM(契約ライフサイクル管理)プロダクトを顧客に提供して終わりではありません。プロダクトを使い続けてくれているお客様には契約データが蓄積されています。そのデータを分析し、ボトルネックを特定して改善提案を行い、より良い運用を一緒に作っていく。それがFDEの役割です。AIを使って現場の方が法務に頼ることなく自立して契約業務を回せる仕組み——その世界を目指して、顧客と伴走しながら仮説検証を繰り返す必要があります。

だからこそ、AI駆動開発で生まれた余力は「次に何を作るか」だけでなく、「顧客の課題解決に向き合う時間の確保」に直結します。速くなったこと自体がゴールではなく、速くなったことで生まれた余力を顧客価値にどう繋げるか。それがFDEマネージャーとしての本当の仕事だと改めて感じました。

刺さったポイント②:セーフティネットとしての自動テスト

もう一つ刺さったのは、AI駆動開発における「セーフティネット」の話です。

田中さんは、AIを暴走させないために必要な3つの土台を挙げていました。

  1. バージョン管理
  2. テスティング
  3. 自動化

特に自動テストについては「生成AIとは異なり、自動テストの結果は安定させることができる」という指摘が印象的でした。AIはハルシネーションを起こすことがある。人間も間違える。だからこそ、安定して品質を担保してくれる仕組みが必要になる。

私自身、ちょうどE2Eテストの環境整備に取り組んでいたタイミングだったので、「自分がやっていることは間違いじゃないんだ」と確信を持てた瞬間でした。AIに実装を委任すればするほど、品質を保証する責任の取り方が変わる。コードを書く責任から、テストを整備して品質を保証する責任へのシフトです。

マネージャー兼プレーヤーとしての実践

私はFDEチームのマネージャーでありつつ、一プレーヤーとしても開発に携わっています。そのなかで自然と辿り着いたのが、Notionに要件(何を実現したいか)を書き、Issueに実装の具体(どう作るか)を言語化して、実装自体はKiroに委任するスタイルです。

イベントで語られていた「補完から委任へ」という変化は、まさに日々実感していることです。マネジメント業務をこなしながらプレーヤーとしてもアウトプットを出すために、AIへの委任は不可欠になっています。マネージャーの仕事が「自分でコードを書く」から「AIが正しく動ける状態を作る」に変わっている。要件の言語化、テスト環境の整備、そして「次に何を作るべきか」の判断——そこに集中することが、AI時代のマネジメントなのだと思います。

おわりに

このイベントを通じて、AI駆動開発における2つの重要な問いを再確認しました。

  • 速くなった先に、何を作るのか?
  • AIに任せた先に、どう品質を保証するのか?

どちらも技術の問題ではなく、意思決定とマネジメントの問題です。AIがコードを書く時代だからこそ、人間が考えるべきことがより本質的になっている。そう実感できたイベントでした。

AI活用は待ったなし。セーフティネットを固めつつ、生まれた余力を顧客の課題解決にすぐ繋げていく。そのスピード感を持ってやっていきます。

名は体を表す — CREからFDEへ、職能名を変えて見えたもの


開発部の組織マネジメント会議で、部長からこんな提案がありました。

「CREって名前、変えませんか」

「名は体を表す」という言葉とともに切り出されたその一言を、私たちは議論の末に受け入れ、職能名を FDE(Forward Deployed Engineer) に変えることを決めました。

名前を変えた。仕事は同じ。でも、採用も、KPIの議論も、チームの自己認識も、少しずつ動き始めています。

この記事では、なぜ名前を変える判断に至ったのか、そして変えた先に何が見えるのかを書いてみます。

ContractS株式会社で開発部 Platformグループ FDEのマネージャーをしている佐藤です。「チームの名前と実態のズレ」に心当たりのあるマネージャーの方や、今後のキャリアを考えているエンジニアの方の参考になれば幸いです。


1. CREという名前の違和感

私たちのチームは長く CRE(Customer Reliability Engineering) を名乗ってきました。

CREはもともとGoogleが提唱した職種で、その本来の定義は「顧客システムの信頼性を保証する役割」——いわばSREの考え方を顧客側に向けたものです。名前だけを見れば、インフラやSREに近い信頼性エンジニアリングの仕事を想像する人が多いでしょう。

ところが、ContractSのCREが実際にやっていたのは主にこんな仕事です。

  • 顧客の業務プロセス(BPMN)の設計・構築
  • API連携・iPaaS統合の提案と実装
  • AI-OCRのカスタマイズ
  • 顧客折衝とプロジェクト推進

顧客の最前線に立ち、業務課題をヒアリングし、プロセスから設計する。必要とあれば自分たちでコードを書き、週単位でデリバリーする。本来のCREの定義とは、重なる部分もありますが、軸足がまるで違います。

この「名前と実態のズレ」は、採用の現場でも顔を出していました。「SRE的な人を募集しているんですか?」「カスタマーサポートですか?」——面談のたびに、まず誤解を解くところから始めなければならない。名前のせいで、候補者にも社内にすら、自分たちの仕事が正しく伝わっていなかったのです。


2. FDEという選択肢

代わりに浮かび上がったのが、FDE(Forward Deployed Engineer) という職種です。

FDEはPalantirが生み出した職種で、いまOpenAI、Anthropic、SalesforceといったAI・SaaS企業で急速に広がっています。その定義はシンプル——「自社プロダクトを持つ企業で、顧客の最前線に配置されるエンジニア」。

この定義は、私たちの仕事にそのまま当てはまりました。

そして重要なのは、独自定義をひねり出す必要がなかったこと。すでに業界で確立された概念をそのまま借りられる。外部に説明するときは「FDEです」のひと言で通じる。採用候補者が職種名を調べれば、その意味も役割も自分で理解できる。名前が、説明コストを肩代わりしてくれるのです。

参考: Forward Deployed Engineerとは(レバテック)


3. リネームの経緯 — 組織の意思決定として

名前を変えるという判断は、誰か一人の思いつきで決まったわけではありません。

きっかけは、冒頭に書いた組織マネジメント会議での部長の提案でした。

正直に書くと、最初はモヤッとしました。「これは提案なのか、決定事項なのか」がわからなかったからです。自分たちのチーム名を、自分たちが関与しないところで決められたのだとしたら——そう思った瞬間、受け入れがたい気持ちが先に立ちました。CREという名前で積み上げてきたものへの愛着もあります。

でも、話を聞くうちに、これは「提案」であり「問題提起」であることがわかりました。そして、問題提起そのものには同意できた。決め手になったのは、こう問い返されたときです——「採用候補者に『CREです』と言って、正しく伝わっていますか?」。答えはNoでした。

議論のポイントは、おおよそ3つに整理できます。

  1. CREという名前が「保守的・リアクティブ」な印象を与えている — 実際の私たちは、顧客の課題に能動的に踏み込んでいくチームなのに、名前がその逆を連想させていた。
  2. 採用市場で正しく伝わらない — 候補者の解像度が上がらず、ミスマッチを生んでいた。
  3. すでに確立された概念(FDE)がそのまま使える — 独自定義のコストを払わずに済む。

これらを合議のうえで決定しました。トップダウンの号令でもなく、現場の独断でもなく、組織としてそう判断した。ふりかえってみると、このプロセス自体がよかったと思っています。


4. 名前を変えて、何が動き始めたか

リネームから日は浅く、劇的な変化を語れるフェーズではありません。ただ、すでにいくつか具体的な変化が起きています。

JDの書き直しで、言語が定まった。

FDE募集としてJD(ジョブディスクリプション)を書き直す過程で、「どんな人に来てほしいのか」をクリアに言語化できました。CRE時代は「SREっぽい人? コンサルっぽい人?」と自分たちでも曖昧だったのが、「顧客の最前線でプロダクトを武器にアウトカムを出すエンジニア」と一文で言い切れるようになった。これは名前が変わったから自然に出てきた言葉です。

「効率×品質」への意識が明確になった。

FDEは時間を売るモデルではありません。「いかに少ない工数で、高い品質の成果を出すか」が価値になる。名前の変更を通じてこの方向性がメンバーにも伝わりやすくなりました。AIの活用も、この文脈で自然と推進力が増しています。

社内への説明が楽になった。

これはまだ道半ばですが、「FDE=顧客の最前線に立つエンジニア」と一言で説明できるようになったのは確かです。CRE時代の「えーと、SREとは違って……」から始まる前置きが不要になっただけでも、地味に大きい。


5. FDEとSES・テクニカルサポートの違い

「顧客先に出ていくエンジニア」と聞くと、SESやテクニカルサポートと混同されがちです。ここは線を引いておきます。

SES は、時間を売るモデル。稼働時間がそのまま収益に直結します。 FDE は違います。プロダクトをパッケージで売り、かけた時間を圧縮するほど利益が出る。つまり「効率×品質」が成果。時間を多く使うことが価値ではなく、少ない時間で大きな成果を出すことが価値——インセンティブの向きが正反対です。

テクニカルサポート は、問い合わせに受動的に対応する役割が中心。 FDE は能動的です。顧客のビジネス課題を起点に、プロセス設計から開発まで一気通貫で担う。待つのではなく、踏み込む。


まとめ

職種のリネームは、「名前を変えるだけ」の作業ではありません。チームのアイデンティティを再定義する行為です。

名前と実態のズレは、採用のミスマッチを生み、社内の認知をゆがめ、メンバーのアイデンティティを揺らがせます。逆に、正しい名前はそれらを静かに整えてくれる。

名前が定まったことで、次のアクションも明確になりました。KPIの言語化、等級ごとの役割定義、オンボーディング設計——「FDEとして何ができたら一人前か」を言葉にする作業が、いま進んでいます。

名前を変えたのは、ゴールではなくスタートライン。ここからが本番です。


FDEに興味がある方はこちら 👉 募集要項


Kiro CLIを開発に導入して、AIコードレビューを役割別に並行実行した

はじめに

最近、開発業務にAIアシスタント「Kiro CLI」を導入した。Kiroはターミナル上で動くAI開発支援ツールで、コードの解析やレビューなど幅広いタスクに対応できる。

今回は、Kiroを使ってコードレビューを複数の専門的な観点から並行実行する仕組みを作った話を書く。

課題感

導入前、以下のような課題を感じていた。

  • レビュアーの知識や経験によって指摘内容に偏りがある
  • 脆弱性対応(ライブラリやフレームワークのバージョンアップ)で、対応に必要な知識が不足しており、結果として不具合が多発していた

やったこと

Kiroに対して4つの役割を与え、それぞれの専門的な観点からコードレビューを並行で実行させた。

設定した役割(実際のプロンプトの一部):

### バックエンドエンジニア
**責任範囲**: サーバーサイドロジック、データベース、API実装
**レビュー観点**:
- ビジネスロジックの正確性
- データモデルの整合性
- トランザクション処理の妥当性
- パフォーマンス(N+1、クエリ効率)
- エラーハンドリング
- コーディング規約の遵守

### フロントエンドエンジニア
**責任範囲**: UI/UX、クライアントサイド、API連携
**レビュー観点**:
**バックエンド変更時**:
- APIレスポンス構造の変更影響
- 後方互換性(既存フロントエンドが壊れないか)
- エラーレスポンスの適切性
- JSONシリアライゼーションの問題(循環参照、null値)
**フロントエンド変更時**:
- コンポーネント設計の妥当性
- 状態管理の適切性
- API呼び出しのエラーハンドリング
- ユーザビリティ(ローディング、エラー表示)
- アクセシビリティ
- パフォーマンス(再レンダリング、バンドルサイズ)

### QAエンジニア
**責任範囲**: 品質保証、テスト戦略
**レビュー観点**:
- リグレッションリスクの特定
- テストすべきシナリオ(正常系、異常系、境界値)
- テストカバレッジの充足性
- 既存テストの更新必要性
- エッジケースの洗い出し
- データ整合性の検証ポイント
- 手動テストが必要な箇所

### インフラエンジニア
**責任範囲**: デプロイ、運用、監視、インフラ
**レビュー観点**:
- デプロイ戦略(ダウンタイム、ロールバック)
- データマイグレーションの必要性と手順
- 環境変数・設定の変更
- ログ出力の適切性
- 監視・アラートの追加/変更
- パフォーマンスメトリクスへの影響
- スケーラビリティへの影響
- 依存関係の変更(ライブラリ、バージョン)

効果

人間のレビューだけでは見落としていたであろう指摘が実際に出てきた。

  • BFF(Backend For Frontend)の変更に伴うUI側の修正漏れの指摘(レスポンスボディの構造変更による影響など)
  • 公式ドキュメントに記載されている修正方法と実装が異なる箇所の指摘

また、4つの観点が毎回必ず走るので、レビュアーのコンディションや得意領域に依存しなくなった点も良い。

工夫したこと・ハマりどころ

  • プロンプトで使用するツールを明示的に指定しないと、必ずしも並行実行してくれるわけではない
  • 指摘の出力が長文になりがちで、重要度の判断に慣れが必要(要改善点)
  • 並列実行時、ツール使用の許可を都度求められるため、自動許可の設定をしておかないと4倍の確認が発生するので注意

まとめ

Kiro CLIを使って役割別の並行コードレビューを導入したことで、レビューの質と網羅性が上がった。AIレビューは人間のレビューを置き換えるものではないが、見落としを減らす補助として十分に機能している。

今後はプロンプトの精度をさらに改善しつつ、他の開発フローへの活用も模索していきたい。

なぜ自動テストは「負債」になるのか。Autify Meetup 2026で語られた安定化のポイントと実践ノウハウ

「自動テストを導入したけれど、保守が辛くて結局負債になっている……」そんな悩みを抱える開発現場は少なくありません。2026年3月12日に開催された『Autify Community Meetup 2026 #1』では、そんな「テストの負債化」を打破し、"攻めの品質保証"へと転換するための熱い知見が共有されました。

近年、ソフトウェア開発においてテスト自動化の導入が進む一方で、「保守工数の増大による本来の業務への圧迫」や「テスト失敗時の原因究明に伴う心理的・時間的負荷」といった、自動テストの「負債化」が多くの開発現場で共通の課題として浮上しています。本イベントでは、「自動テストの安定化」をメインテーマに掲げ、現場の最前線でこれらの課題に取り組み、顕著な成果を上げている登壇者より実践的な知見を共有していただきました。

1. テスト自動化を安定化させるポイント

本セッションでは、3名の登壇者により、実際の運用環境におけるテスト自動化のノウハウがLT形式で発表されました。

【LT1】リグレッションテストを2週間→2日へ

最初の登壇者からは、複雑な業務ソリューションにおいて、月間4.5万ステップ年間54万ステップという大規模な自動テストを運用している実績が報告されました。この継続的な取り組みにより、従来1〜2週間を要していたリグレッションテストの期間が、1〜2日へと大幅に短縮されたとのこと。

さらに特筆すべき点として、不具合検知率が9.9%に達していることが挙げられました。これは、テスト失敗の約半数が実際の不具合や仕様変更に起因していることを意味し、テスト群の極めて高い信頼性を示唆しています。

安定運用のための具体的な施策として、以下の3点が提示されました。

  • 適切な待機(wait)処理の設定:
    • 実行環境における応答速度の変動を許容しつつ、週次での定期実行によって早期に異常を検知する体制の構築。
  • XPATHを用いた動的ID対策:
    • 特定のプラットフォームに散見される不安定な要素指定に対し、堅牢な記述手法を採用することで安定性を確保。
  • 二要素認証(2FA)の制限回避:
    • 連続試行回数の制限(50回)を回避するため、全シナリオ間でセッション情報を共有・再利用し、認証プロセスを最小化する設計の導入。
【LT2】「録画(レコード)」依存からの脱却とテストの組織的運用

次いで、テスト自動化の導入期に陥りやすい「手動操作の単純な録画(レコード)」の危険性について指摘がなされました。録画によるシナリオ生成に過度に依存した場合、テストスクリプトが肥大化し、将来的な製品仕様の変更に伴う保守コストが指数関数的に増大する傾向があります。これが自動化プロジェクト頓挫の主要因となり得ると論じられました。

自動テストを単なるツールとしてではなく、「継続的に保守・改善を行うべき組織的な仕組み(生きた組織)」として捉えることの重要性を説いていました。

  • 主要機能への焦点化:
    • 全機能を網羅するという非現実的な目標を排し、品質保証上不可欠な重要機能に絞ったテスト設計を行う。   
  • テストスクリプトの鮮度維持:
    • 日次あるいは週次での高頻度な実行を通じ、対象製品の変化に即座に追従できる体制を維持する。
【LT3】運用プロセスの改善によるアンチパターンの打破

最後の発表では、自動テスト運用において頻出するアンチパターンとその解決策が提示されました。「保守作業の恒常的な後回し」という悪循環を断ち切るための具体的な方策として、「自動テストを通過したコードのみマージを許可する」といった、開発フローへの強制的な組み込みが有効であると指摘されています。

初期段階から完璧なテスト網羅を追求するのではなく、スモールスタートから始め、効果を定量的に可視化しながら段階的なプロセス改善を図ることが、長期的な安定稼働への最適解であると結論付けられました。

2. ハプニングも味方に 開発者の生実況でデモ

ここで1つ、イベントの熱量を象徴するエピソードをご紹介します。

動画デモの最中に音声が途切れるトラブルが発生したのですが、会場にいたデモ動画の作成者が即座にマイクを握り、無音動画に合わせた生実況で解説を代行。

トラブルもなんのその、臨機応変にさすがのご対応でした。

会場からは温かい拍手に包まれました^^

3. 総括:高度なツールの活用に不可欠な運用体制と意識改革

このMeetupを通じて得られた最大の結論は、「ツールの機能がいかに高度化しようとも、それを適切に運用するための組織的な体制と、担当者のマインドセットが不可欠である」という点であるということでした。

強力なテスト自動化ツールの導入は、保守工数の削減という直接的な恩恵をもたらす可能性を秘めていますが、ツールを活用し、形骸化しない「実効性のあるテスト」を組織内に定着させ、ひいては品質向上とリリースサイクルの短縮というビジネス価値の創出に結びつけるためには、品質保証に携わるエンジニアおよび開発陣の継続的なコミットメントが求められます。

自動テストを「負債」から「攻めの品質保証」の要へと転換するための戦略的アプローチが多数共有された本イベントは、今後のテスト自動化のあり方を考えていく上で非常に参考になるイベントでした。

🚀 GoogleのAntigravityを試したら、5分でアイスブレイクコンテンツ不足が解消した話

ContractSの㓛刀です。

エンジニアとして就職して以来、仕事とは別にまとまった学習時間をがっつり取ろうとすると、趣味の時間が消え去ってしまうのが長年の悩みです。そこで、最近は「トレンドぐらいは暇な時に追えるようにする」という方針で、Qiitaなどの技術記事を軽く眺めるようにしています。

余談ですが、意外と軽く眺めるだけでも「あったなこんな技術」と記憶を呼び覚ましてくれるので、私のように「あまり勉強をしたくないけど、知識のアップデートはしたい」というエンジニアにこそ、色々な記事を軽く眺めることをお勧めしたいなぁと思っています。

Antigravityに遭遇し、即座に試してみた

そんな中、ちょうどGoogle が 2025-11-18に発表したAntigravityに関する記事が流れてきたので、これは触ってみるしかない!と、飲み会終わりに自前のパソコンでいそいそとインストールを始めました。

Antigravityの概要についてはまだちゃんと調べられてはいませんが、使ってみてから考えるのがエンジニアの性です。

📌 開発テーマ:アイスブレイクコンテンツ不足の解消

何か作ってみるにあたり、現状の業務や生活で欲しいツールがないか少し考察してみました。

最近、社内のミーティングや研修でアイスブレイクコンテンツ不足に悩んでいたことを思い出しました。毎回新しいネタを考えるのは地味に大変です。

「ワンクリック(ワンポチ)でアイスブレイクコンテンツを出力してくれるツール」を作成するのは非常にアリではないか?

早速、この課題をAntigravityくんにお願いすることにしました。

🕒 驚異の5分で実装完了

暫く待っていると、Antigravityはまずツールの実装計画書を吐き出してくれました。 出力された計画書。設定すれば日本語でも出してくれるでしょう。

そして、待つこと僅か...たった5分程度でツールが完成したという通知が!

無事に作成されたツールを開けてみると、問題なく動作しました。

まとめ

Googleが発表したばかりの技術「Antigravity」を試したところ、たった5分で実用的な課題解決ツールを作成することができました。その進化のスピードにはただただ驚くばかりです。

まだ触りの段階ですが、エンジニアの働き方を大きく変える可能性を感じています。次はもう少し複雑なツールを依頼して、Antigravityの可能性を探ってみたいと思います。