「AI時代の開発職は、なぜ変わるのか」実践資料24ページを無料公開。利用者の事実と背景から、設計・検証・採用・育成を考える

同じ「確認したい」でも、必要な仕組みは異なる。備品修理の受付を例に、実現したい状態を仕様・テスト・利用後の評価へつなぐ

980社・33.8万人の働く人のデータを基盤に、組織行動科学®の研究・教育開発を行うリクエスト株式会社（本社：東京都新宿区、代表取締役：甲畑 智康）は、Web・ソフトウェア開発者と、開発の依頼・採用・育成を担う方に向けて、実践資料「AI時代の開発職はなぜ変わるのか」を無料公開します。

資料はA4横・全24ページ。利用者の行動と、その背景にある目的や制約を捉え、実現したい状態を設計・検証・運用へつなぐ方法をまとめました。前作「AI時代の開発職は、何を担うのか」の続編です。

実践資料PDFをダウンロード（A4横・24ページ・無料）

「AI時代の開発職はなぜ変わるのか」をダウンロード

d68315-289-144a0154aea5ac0772a71c094fb7a4e6.pdf

そもそも、なぜ利用者の事実と背景が重要なのか

プログラムが正しく動くことは重要です。その動きが誰の何を助けるかは、利用される場面まで確かめる必要があります。例えば、備品修理の依頼を送信できても、受付済みか分からなければ、本人は確認の電話をかけるかもしれません。

本資料では「この変更で、誰が何を進められるようになるか」を開発の出発点に置きます。

利用前後の仕事、報告や承認の相手、期限、失敗した場合の影響を確かめると、作るべき機能と必要な条件が具体的になります。

同じ「確認の電話」でも、必要な仕組みは変わる

資料では、備品修理の依頼後に二人が確認の電話をかけた、という架空の場面を扱います。

Aさんは、依頼が届いたか分からない。
受付番号と、保存済みの受付状態を確かめられる仕組みを検討します。

Bさんは、上司への報告に次の連絡時期が必要。
受付番号に加え、現在の状態と次の連絡予定を知らせる仕組みを検討します。

電話の回数だけでは、この違いは分かりません。行動を減らす前に、その行動によって本人が何を確かめようとしていたかを知ることが、改善する対象を決める手がかりになります。

利用者への約束を、仕様とテストへ落とし込む

「受付済みと分かるようにする」という目標にも、保存、通信、権限、通知の設計が関わります。資料では、一つの具体例を使い、次のような確認へ進みます。

• 依頼の保存が成功した後に、受付番号を表示する

• 通信が途切れて同じ送信を再試行しても、二重受付を防ぐ

• 依頼の受付、修理の手配、通知の送信を分けて扱う

• 権限のない人が、他の依頼者の情報を閲覧・更新できないか確かめる

• 画面を読み上げる支援技術でも、受付結果を把握できるか確かめる

公開後は、確認の電話が減ったかに加え、本人が必要な報告へ進めたか、受付担当や別部署の作業が増えていないかを見ます。利用者の理解と技術の判断を、一連の開発の仕事としてつなぎます。

AIで変わる仕事の配分を、チームで確かめる

AIは実装案・コード・テスト案の作成を助けます。同時に、生成物を読み、実際の条件に合うかを確かめる仕事も生じます。

DORAやMETRの報告を参照し、生成の速さだけでなく、レビュー・手戻り・運用を含めて仕事の配分を見直す考え方を整理しました。

資料には、AIへ渡す「確認した事実」「未確認の点」「実現したい状態」「今回の作業範囲」「検証してほしいこと」をまとめた依頼例も収録しています。AIが補った説明と、実際に観察した事実を分け、根拠を追えるようにすることを提案します。

「開発職の採用は不要になるのか」を、担う仕事から考える

作業の一部が自動化されても、その割合だけで必要な採用人数は決まりません。実装、利用者への確認、レビュー、運用のどこで仕事が滞っているかによって、必要な体制は変わります。

採用・育成の章では、判断した理由と検証した結果を確かめる選考の例、若手が一つの変更を公開後まで担当して学ぶ進め方を提案しています。開発者一人へ全てを任せるのではなく、利用者、業務責任者、開発・品質・運用の担当者が、必要な事実と判断材料を持ち寄る体制を考えます。

AIに関する研究の結果は、課題・経験・道具・組織の条件によって変わります。本資料は、開発職の消滅や採用人数を予測するものではありません。

資料の構成と使い方

• 3～8ページ：なぜ利用者の事実と背景が重要なのか

• 9～16ページ：備品修理の受付を例に、設計・検証・運用を考える

• 17～20ページ：開発職の採用と若手育成を考え直す

• 21ページ：一件の開発で使う記入用書式

• 22～24ページ：参照した一次資料12件

これから変更する機能を一つ選び、21ページの書式へ「実際に起きていること」「相手と共有した良い状態」「確認する結果」を書き出すところから使えます。分からない点は、次に誰へ何を確かめるかを残します。

実践資料PDFをダウンロード（A4横・24ページ・無料）

実践資料PDFはこちら（24ページ）

d68315-289-73b601d4ea3efa04eeccdfa6b62b4822.pdf

参照した知見と、資料の位置づけ

利用者調査に関するGOV.UKの実務指針、DORA・METRの報告、GitHub・Amazon・OWASP・W3Cの公式文書、Google SREの運用指針、AIと学習に関する研究など、一次資料12件を参照しています。出典と参照範囲は資料末尾に記載しました。

備品修理の場面・会話・仕様は例です。掲載した手順・書式・選考案は実践提案であり、効果を検証済みの評価尺度ではありません。980社・33.8万人は当社の研究基盤の規模であり、今回の資料の効果検証数ではありません。

主な参照先：
GOV.UK：Learning about users and their needs
DORA：Balancing AI tensions
METR：Developer Productivity Experiment Design

前作：「AI時代の開発職は、何を担うのか」
公開資料を探す：知と実践

知を社会へひらく。仕事を見直す、次の一歩へ。

リクエスト株式会社は、「成果につながる方法を、本人が使える仕事へ。」を軸に、組織行動科学®の研究・教育開発と実践支援に取り組んでいます。仕事の事実を確かめ、本人が判断する経験と周囲の支援を整えるための資料を公開しています。

会社概要

会社名：リクエスト株式会社
代表者：代表取締役 甲畑 智康（こうばた ともやす）
所在地：〒160-0022 東京都新宿区新宿3丁目4番8号 京王フレンテ新宿3丁目4F
公式サイト：https://requestgroup.jp/

本件に関するお問い合わせ

リクエスト株式会社
メール：[e-mail]
お問い合わせフォーム：https://requestgroup.jp/request

資料の内容、職場での活用、取材に関するお問い合わせは、上記窓口までお寄せください。