SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

人生を『変化するシステム』として捉える

AIで成果は増えた。自分は何を学んだのか #3

nwiizo[著]

完成は早くなる。理解は後回しになる。AIで空いた時間をすべて次の作成へ回すと、選んだ理由を説明したり、実際に試したりする機会が減ります。困るのは条件が変わったときです。完成件数とは別に、予測と結果を比べる時間を仕事に残します。

前回の記事はこちら!

完成と理解の時間差

 資料は完成。次へ進めます。ところが、理解の不足に気づくのは、説明を求められたり想定外の問題が起きたりしたときです。完成実績だけを見て次の仕事を増やすと、この不足を見つける機会も減ります。

 たとえば、AIが作った設計で普段は動いていても、連携する別のシステムから返事が来ないときの動きはわかりません。返事を待つ処理がどこにたまるか。処理をやり直す「再試行」で、同じ処理が二重に行われないか。先に予測し、実際の業務に影響しないテスト環境で確かめます。

 テストは後で。記録も後で。そうやって完成件数を増やしても、次の担当者にはどこまで試した設計なのかが伝わりません。

悪循環1:完成した資料を説明できない

 「何か違う」。そう感じたとき、理由を考えるより再生成の方が速いです。候補を見比べるうちに締め切りが近づき、元のデータへ戻る時間がなくなる。選んだ根拠が残らず、次も新しい出力に頼る。結果が次の行動を左右し、同じ状態を繰り返させる経路をフィードバックループと呼びます。

再生成と判断基準の不足

 図の箱は増えたり減ったりするものを表します。矢印の(+)は、手前の量が増えると次の量も増える向きの影響です。他の条件は変えず、増やさなかった場合と比べます。(−)は次の量を減らす向きで、良い・悪いの記号ではありません。

 ここで想定しているのは、比較へ時間を使いすぎると、目的や根拠を確かめる経験が減るという関係です。候補の数だけで判断基準の変化は決められません。

 AIの案はすぐに届きます。自分の理解が足りないことには、別の課題で説明を求められるまで気づけない場合があります。この時間差があるため、理解を確かめるより先に、次の再生成へ進みやすくなります。

 しかも、記事や報告書の件数はすぐに成果の一覧へ並びます。生成量だけが評価される職場では、理解するために立ち止まる人ほど、仕事が遅く見えてしまいます。

 成果物を先に受け取り、理解を後回しにする状態を負債になぞらえて理解負債と呼びます。後で学び直すほうが手間がかかります。資料を伏せても採用理由を説明できるか、別の課題でも同じ基準を使えるかが、その不足を知る手がかりになります。

 渡す前に採用理由を一行でいいから書く。まずはそこからです。書けたとしても、AIの説明を覚えただけかもしれません。冒頭の設計なら、返事が来ない場合の待ち件数や再試行による重複の有無を予測し、テスト環境と照合します。

 予測より待ち件数が増えた。起きないはずの重複処理が起きた。こうした結果が出たら方式を考え直す、と先に決めておく条件を「反証条件」と呼びます。試せなかった条件は未確認として残します。説明を覚えただけでも話せますが、結果を予測して確かめれば、どこまで理解できたかがわかります。

 候補を比べて、はじめて必要な条件に気づく場合もあります。判断基準を得られたかは、再生成の回数だけでは決まりません。問題は候補を選んだ理由が、候補を並べた画面の外へ持ち出せないことです。利用者の状況や元のデータへ戻れず、「この中では一番よい」で止まるなら、新しい案が出るたびに選び直しになります。

 再生成の前に一度止まります。誰へ何を伝える資料なのか。何を根拠に選ぶのか。「何か違う」の中身を言葉にできれば、次の出力に求める修正も伝えられます。回数の上限を決める方法もあります。たとえば生成は二回までとし、三回目が必要なら指示が曖昧なのか、目的や判断基準が決まっていないのかを先に分けます。

 採用理由を確かめるかどうかを本人の余裕に任せると、締め切り直前ほど省かれます。採用理由と未確認点は提出前の確認項目に含めます。省くときは理由ごとに扱いを分けます。

  • 急ぎのために後回しにするなら、いつ誰が確かめるかを決める
  • 手順が実情に合っていないなら、その手順を直す
  • 特定の条件で省けるなら、その条件と判断する人を記録する

 不要と未完了は別です。同じ確認が繰り返し省かれるなら、項目や時期が実情に合うかを見直します。提出の決まりを変える権限がなくても、差し戻しの原因を残せば、担当者へ変更を相談する材料になります。

悪循環2:成果物からは見えない学習

 完成品はよくできています。担当者は何を学んだでしょうか。この二つは別に確かめる必要があります。

 AIがプロジェクトのファイルを読み、変更を作り、動作を確かめ、その結果を別のAIが確認する環境も現れました。変更の量が、人間がすべてを読める量を超える事例もあります。ここで「人間が読まないから危険」「別のAIが見たから安全」のどちらかへ決めつけると、変化を見誤ります。

 確認は個々の行を読むことから、検査や実際の結果との比較へ移せる場合があります。どこまで移すかは課題の難しさに加えて、次の三つで判断します。

  • 外れたときに誰がどれだけ困るか
  • どれだけ速く気づけるか
  • どこまで戻せるか

 たとえば、案内文の宛先と日付を確かめる検査では、受け手がその説明で準備できるかまでは確かめられません。検査へ移した範囲と、まだ判断が必要な範囲を分けます。

 資料や提案書の下読みにAIを使うなら、指摘の正しさを確かめる時間まで含めて、確認が短くなったかを見ます。誤った指摘の調査に時間がかかれば、下読みだけの短縮とは結果が変わります。確かめるのは、AIを含む仕組み全体が期限内に必要な問題を見つけたかどうかという点です。仕事の目的が達成されて安全に使えるなら、AIの支援を受けること自体は問題ではありません。

 ただし、AIの支援が使えない場面、AIが見落とす種類の欠陥、初めて扱う条件では、別の能力が必要になります。普段の成果物だけを見ても、どこまでが道具の働きで、どの判断基準が人やチームに残ったかはわかりません。AIの支援が使えなくなったとき、人やチームが自分で確かめられる範囲の偏りが初めて表に出ます。

 AIにコード(プログラム)を任せた後も、処理を分解して実行結果と比べれば、判断を練習できます。受け取るだけなら、その機会はありません。差が表れるのは後日です。今日の完成品に不備がなくても、初めての条件で担当者が判断に詰まることがあります。これが連載第2回で見た遅延です。

 練習時間の増加を、そのまま技能の向上とはみなせません。予測し、確かめ、直す経験は技能を形成する条件であって、経験した分だけ必ず学べるという式ではないからです。技能の変化は、どの条件変更に対応できるようになったかで見る必要があります。

 予測と検証をAIへ渡した結果、人が条件の変化を確かめる機会が減ったとします。それでも提出物が受け入れられれば、仕事を配る人には今の分担で足りているように見えます。その実績を根拠にさらにAIへ任せ、空いた時間も次の作成に使えば、人が予測して結果を確かめる時間は次の仕事でも減ります。

 これが二つ目の悪循環です。成果物の不備が少なくても、担当者が初めての条件で判断できるかは、まだわかりません。

 AIがどの判断を補っているかは、実際の業務に影響しない練習用の課題で比べられます。支援ありと支援なしで試す場合は難度、体調、使える時間に加えて、同じ課題を二度解いたことによる慣れにも注意が要ります。この比較で見えるのは、その条件で支援が補った範囲であって、過去から能力が低下した証拠ではありません。本番の仕事から必要な支援を外して試す必要もありません。

 能力の変化を知りたいなら、後日、条件の近い別の課題で誤りの発見や採用理由の説明を比べます。以前は見落とした条件に気づけるようになったなら、AIを使う頻度が増えていても学習不足という見立ては見直します。逆に、説明の流暢さだけが増え、同じ条件変更で判断を誤るなら、その判断を練習する時間を仕事へ戻します。道具なしで速く作れるかだけで、人の能力を評価しないためです。

次のページ
悪循環3:次の担当者による調べ直し

この記事は参考になりましたか?

人生を『変化するシステム』として捉える連載記事一覧

もっと読む

この記事の著者

nwiizo(ヌウィゾウ)

インフラエンジニアとしてホスティングサービスの開発・運用に携わり、深夜のオンコール対応をきっかけに、運用のあり方を本気で考えるように。現在は株式会社スリーシェイクにソフトウェアエンジニアとして在籍。技術書の翻訳や書籍の執筆をいくつか手がける。本を作ると、わかることが1つ増えるのと引き換えに、わからな...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー