自己紹介 生成AIで増えた仕事に責任の線を引く
生成AIを使えば、成果物は増える。
コードも、テストケースも、設計案も出る。議事録も、提案資料も、レビューコメントの下書きも出る。
それ自体は悪くない。
実際、助かる場面は多い。調査のたたき台、コードの初稿、テスト観点の洗い出し、資料の骨子作り。使えるところは使った方がいい。
ただ、現場で引っかかるのはその先だ。
増えた成果物を、誰が見るのか。
どこまで見れば十分なのか。
見落としたとき、最後に説明するのは誰なのか。
この問いが、いまのエンジニアの胃に消化不良の昨日の晩飯のように残っている。
私は、企業内でソフトウェア開発、スクラム活動、クラウドアプリケーション開発、生成AI機能のプロダクト導入を進め、チーム内外のレビュー、顧客提案、社内外調整をしてきた。作って終わりではなく、企画も設計も実装も運用する。
説明するもの、決めるものが複雑に絡む大規模システムの開発をリードする時間が長かった。
だから、AI活用の話を聞くたびに引っかかる。
生成AIで開発が速くなる。
その話は分かる。一人のエンジニアとして、ChatGPTが公開された日から毎日ワクワクしている。こんな素敵な世界になるなんて想像していなかった。
一方で、現場の負荷は消えていない。負荷の場所が変わったのだ。実装の手前にあった負荷が、レビュー、受入、運用、説明、合意形成に移動する。成果物が増えれば、見る回数も増える。見る回数が増えれば、責任の置き場が必要になる。
生成AIで増えたのは成果物だけじゃない。レビュー待ち、判断待ち、説明責任も増えた。
このnoteで書きたいのは、そこだ。
最新AIツールの紹介なら、もっと速い人がいる。モデル比較、プロンプト技法、エージェント構築、海外ニュース。その領域には専門で走っている人がいる。
私が書くのは、AIが現場に入った後の話だ。
これから先、生成AIとエンジニアの共同成果物に対して、以下の点を明確にしたい。
PRをどう見るか
設計案をどこで止めるか
テストケースに何が足りないか
AIがまとめた資料を、そのまま会議に出してよいか
AI利用をチームのDoRやDoDにどう落とすか
レビュー担当が全部を抱え込まないために、どこから上位者へ上げるか
評価面談で、自分の判断貢献をどう説明するか
私の記事は華やかなAI活用談より地味だ。
しかし、現場に求められているものはこっちだと思っている。
エンジニアの価値は、手を動かした量だけで語りにくくなっている。生成AIがコードを書ける時代に、コード量だけで自分の価値を守るのはかなり苦しい。だからといって、エンジニアの価値が消えるとも思っていない。
価値の場所が動いている。
どの仮説を採るか
どの仕様を止めるか
どのリスクを先に見るか
どこまでを現場で決め、どこから上司や関係者に上げるか
何をDoneと呼び、何を未完了として扱うか
この仕事ができる人は、生成AIの時代に負荷が高まる。問題は、その負荷の重さが評価されにくいことだ。生成AIの導入で組織全体の成果物が増えても局所的に特定のエンジニアに負荷を押し付けている。
作る速さより、どこで止めるかを決められる人が残る。
このnoteでは、そういう仕事を言葉にする。以下の項目はほんの一例だ。
AI生成物レビューのチェックリスト
レビュー係が抱え込まないための境界線
AI利用を前提にしたDoR・DoD
User Storyを仮説検証に変えるBacklogテンプレート
テックリードが背負いすぎないための責務整理
評価面談や1on1で、自分の判断貢献を伝えるための成果説明テンプレート
私の記事は精神論には寄せない。
現場で使える形にする。会議で読める文にする。チケットに貼れる粒度にする。レビューコメントとして使える言葉にする。上司に説明するときに、作業量の話で終わらない表現にする。
私はこれからのエンジニアに必要なのは、根性だとは思っていない。必要なのは、自分が背負う責任の範囲を正しく決めることだ。見ること、任せること、止めること、上げること。この境目を持たないままAI活用だけが進むと、真面目な人から先に潰れていく。生成AI導入がエンジニアを潰す社会を生み出したくない。
真面目にレビューする人ほど、何でも詳細に見ようとする。
責任感のある人ほど、自分が拾うべきだと思ってしまう。
チームを支えたい人ほど、判断の空白を埋めに行く。
でも、その働き方は決して長く続かない。
生成AIで成果物が増える時代、善意や忍耐より境界線が要る。
レビュー観点も、Doneの定義も、上申条件も、評価で語る成果も、明確な定義と共に言葉にして持っておく必要がある。
このnoteは、そのための道具箱にしたい。
読んでほしいのは、AIに夢を見たい人より、AIが入った後の現場で責任が重くなっている人だ。テックリード、PO、スクラムマスター、開発リーダー、レビュー担当、情シス、改善担当。肩書きは違っても、共通している感覚がある。
だから私は書く。
もし今、Backlogが作業票の山になっているなら、まずこの記事から読んでほしい。
AIで実装速度が上がるほど、User Storyの粗さはあとから効いてくる。
レビューで迷う。受け入れで揉める。リリース前に説明が詰まる。
その前に、User Storyを仮説検証の形に戻す。
