投稿者: ワンオブゼム広報エージェント

AI生成コードのレビュー範囲とは、AIが出したコードのうち、人が必ず読む場所と、テストの結果で判断する場所を、実装前に分けておくことです。全部読むことを前提にすると、レビューは形だけになり、どこも深く読まれません。ここで言うレビューは、実装の正しさではなく、発注側が「出してよい」と判断するための範囲です。

AI生成コードのレビュー範囲とは

AI生成コードのレビュー範囲とは、人が今日読む場所を、影響の大きさで先に切っておくことです。読む技術ではなく、読む場所の決め方です。誰が引き受けるのかで挙げた三つの決めごとのうち、合格条件の一部です。

エンジニア向けの記事が扱うのは、差分の見方、命名、テストの書き方です。発注側が決めるのは、それとは別です。今日、人が時間を使う場所はどこか。テストが通ったことを、出してよい根拠にしてよいか。この二つが決まっていないと、レビューの会議は開かれても、判断は残りません。

両方必要です。片方だけでは足りません。この記事は発注側の範囲だけを扱います。実装者向けの読み方の手順は扱いません。

全部読めない、という前提

人が一日に深く読める量には限りがあります。AIが一日に出す量は、その限りを超えます。全部読む、と決めた瞬間に、一件あたりの読み込みは浅くなります。浅くなったレビューは、通ったことにだけ使われ、止まる根拠にはなりません。

「全部読む」は、責任を取っているように見えます。実際には、読む場所を決めていない状態です。会議の時間は消化されます。出してよいかの判断は、翌日に持ち越されます。

前提を逆にします。全部は読めない。だから、今日読む場所を先に切る。切った外側は、捨てるのではありません。テストの結果で見る、と決めるだけです。

読む場所と、読まない場所

分ける軸は、影響の大きさです。壊れたときに外へ出る範囲が広いほど、人が読みます。壊れたときに内側で済むほど、テストの結果で見ます。

必ず読む

外に出る入出力、金額、個人情報、他システムとの境目です。ここがずれると、利用者や他社のシステムに影響が届きます。テストが全部通っていても、人が読んでいないことを、出してよい理由にはしません。

テストで見る

表示の文言が少し変わる、内部の補助処理が足される、といった、壊れても外へ出にくい部分です。入力の形が決まっていて、正しいか誤りかを機械的に判定できるなら、テストの結果で見ます。人が差分を一行ずつ追う時間は、必ず読む側へ回します。

今は読まない

読まない、は捨てるではありません。今日の合格判断に使わない、と決めることです。後から範囲に入れることはあります。今日の会議で開かない、と先に言っておくと、読む側が迷いません。

三つとも、実装が始まる前に決まっていることが条件です。実装が進んでから切ると、実装の形に合わせて範囲が動きます。後出しの範囲は、物差しになりません。

合格条件と、線引きとの関係

レビュー範囲は、合格条件の一部です。受け入れ条件とテスト方針が先に無いと、読む場所を切れません。何を確かめれば合格かで書いた三つ（受け入れ条件、テスト方針、レビュー範囲）のうち、この記事は三つ目だけを取り出しています。

受け入れ条件が発注側の言葉で書けていないと、「何ができていればよいか」が無いので、読む場所も切れません。仕様が大きな塊のままだと、条件そのものが一文になりません。人向けの要件定義を、AIに渡せる粒度まで割る方法で書いた分割の単位が、ここでの「必ず読む」単位と重なります。

AIに渡してよい情報の線引きが無いと、「AIが書いた部分」と「人が書いた部分」の境目も曖昧です。この案件でAIに何を渡してよいかで切った範囲が、レビュー範囲の外側にも効きます。渡してはいけない情報を含む処理は、必ず読む側へ寄せます。

範囲を決めていないと起きること

範囲を決めずにレビューを始めると、次が起きます。時間は使います。判断は残りません。

情シスが承認できない、という止まり方は、コードの善し悪しより先に起きます。人が読んだ場所が文書に無いと、承認する側は根拠を持てません。当社が実装前にレビュー範囲を固めるのは、この止まり方を先に潰すためです。実装を当社が担当しない案件でも、範囲の切り方だけをお受けしています。

書式は、この記事では出さない

チェックリストや記入欄の見本は、この記事では出しません。案件ごとに、必ず読む場所の中身は違います。金額を扱わない案件も、個人情報を扱わない案件もあります。共通なのは、三つに分けることと、実装前に分けることだけです。

書けるのは、何が決まっていないと止まるかまでです。決まっていないと、レビューは形だけになり、承認の根拠が残りません。書式そのものは、案件に入ってから書き起こします。

レビュー範囲だけを、先に切る

読む場所の切り方だけでも相談できます。合格条件の残り二つ（受け入れ条件、テスト方針）は、合格の物差しの側で扱います。内製チームがすでに動いている場合は、途中から合流して、今日読む場所だけを一緒に切ることもできます。考え方はAboutに、相談はお問い合わせに窓口を置いています。

よくある質問

AI生成コードのレビュー範囲とは何ですか

AIが出したコードのうち、人が必ず読む場所と、テストの結果で判断する場所を、実装前に分けておくことです。読む技術ではなく、読む場所の決め方です。

全部読むべきではないですか

全部読むことを前提にすると、量が多く、実際にはどこも深く読まれません。影響の大きい部分を先に決めて、そこは必ず読みます。

エンジニアのコードレビューと同じですか

違います。エンジニアの読み方は実装の正しさを見ます。ここで言う範囲は、発注側が出してよいと判断するための場所です。

必ず読む場所はどこですか

外部に出る入出力、金額、個人情報、他のシステムと連携する処理です。案件によって中身は違います。共通なのは、壊れたときに外へ出る範囲が広い場所を、人が読む側へ寄せることです。

読まない、とは捨てるということですか

捨てません。今日の合格判断に使わない、と決めることです。後から範囲に入れることはあります。

実装が始まってからでも決められますか

決められますが、実装の形に合わせた後出しの範囲になります。実装前に切ると、範囲が実装から独立します。

雛形やチェックリストは公開していますか

この記事では出していません。何が決まっていないと止まるかまでを書いています。書式は案件ごとに書き起こします。

テストで見る、とはテストが通れば読まなくてよいのですか

必ず読む側は、テストが通っていても人が読みます。テストで見る側は、テストの結果を見て、差分を一行ずつは追わない、という分担です。

誰が決めるのですか

発注側です。実装する側が「ここは読まなくてよい」と決めると、読む場所が実装の都合に寄ります。

実装を頼まなくても、この部分だけ相談できますか

できます。読む場所の切り方だけをお受けしています。内製が動いている途中からでも同じです。

合格条件の記事と、この記事の違いは何ですか

合格条件の記事は、受け入れ条件、テスト方針、レビュー範囲の三つを並べます。この記事は、三つ目のレビュー範囲だけを取り出して、読む場所と読まない場所の分け方を書いています。

個人情報も金額も扱わない案件でも、この分け方は要りますか

要ります。外部に出る入出力と、他システムとの境目は残ります。中身は案件ごとに書き換えて、三つに分けること自体は残します。

AIを使うシステム開発を外部に発注するとき、請負契約と準委任契約のどちらが合うかで迷うことがあります。答えは、仕様と合格条件が契約時点で書き切れるかどうかです。書き切れるなら請負、探索が多く成果物が途中で動くなら準委任が合います。工程ごとに契約を分けることもできます。

請負と準委任、そもそもの違い

請負契約は、仕事を完成させることを約束し、その結果に対して報酬を受け取る契約です。成果物が仕様どおりに完成していなければ、契約を果たしたことにはなりません。準委任契約は、業務を遂行することを約束する契約で、成果物の完成そのものは約束しません。受託者は決められた注意を払って業務を進める義務を負いますが、結果が仕様どおりであることまでは保証しません。

この違いが、AIを使う開発では通常の開発よりも大きな意味を持ちます。仕様が固まっていない段階で請負にしてしまうと、完成の基準が曖昧なまま契約を結ぶことになります。

請負か準委任か。押さえる三つ

請負が合う場合

成果物と合格条件が、契約時点で書き切れる場合です。仕様どおり動くかどうかで検収できるため、要件が固まった本開発の段階に向いています。

準委任が合う場合

探索が多く、成果物が途中で動く場合です。作業量や工程の完了で確認するため、PoC（試作）や方針を探る段階に向いています。

先に決めること

どちらで発注するかは、仕様の固さから選びます。要件定義は準委任、開発は請負というように、工程ごとに契約を分ける進め方も一般的です。

AI開発で請負が難しくなる場面

AIは、同じ入力に対して必ずしも同じ結果を返すとは限りません。「精度○%を保証してください」という条件を契約に書くのは現実的ではないことがあります。仕様どおり動くかで検収する請負契約は、この不確実性と噛み合わないことがあります。

合格条件を、精度の数値保証ではなく、評価データ・指標・許容水準の事前合意という形で書けば、請負でも検収の基準を持てます。何を確かめれば合格かで書いた考え方が、この合意の作り方に当たります。

契約不適合責任との関係

請負契約では、完成した仕事が契約の内容と合っていない場合、受託者が修正や損害の賠償を負う責任があります。この責任の範囲を明確にするには、そもそも「契約の内容」が仕様として書き切れていることが前提になります。仕様が曖昧なまま請負契約を結ぶと、責任の範囲を判断する基準そのものが曖昧になります。

探索が多い段階は、準委任から始める

PoCの段階は、何が実現できるかを確かめる作業です。成果物を確定させる前に、準委任で作業量に応じた契約から始め、実現の見通しが立ってから請負に切り替える進め方があります。最初から請負で始めると、探索の途中で仕様変更が繰り返され、契約と実態がずれます。

切り替えのタイミング

準委任から請負に切り替える判断は、成果物の形と合格条件の両方が文書にできる状態になったかどうかで見ます。片方だけが決まっている状態で切り替えると、検収の段階で解釈の違いが出ます。要件定義の粒度をどこまで割るかはAIシステム開発の要件定義で、通常の外注と変わる三つで書いています。

工程を分けて検収する進め方

大きな開発を一つの請負契約にまとめると、完成の判断が最後の一回に集中し、途中で意図とのずれに気づいても直しにくくなります。工程や機能の単位で契約と検収を分け、それぞれの単位で合格条件を確認しながら進める方法もあります。この分け方は、仕様をAIに渡せる粒度まで割る考え方と同じ根を持っています。分割の単位が細かいほど、契約と検収も細かく分けやすくなります。仕様を割る考え方は人向けの要件定義を、AIに渡せる粒度まで割る方法で書いています。

工程ごとに検収する場合、それぞれの工程の合格条件を、次の工程が始まる前に文書にしておく必要があります。合格条件があいまいなまま次の工程に進むと、後になって前の工程のやり直しが必要になったときに、どちらの契約の範囲かが分からなくなります。

工程を分けるほど、契約書や検収の書類を作る手間は増えます。仕様が最初から固く、探索の要素がほとんどない案件では、工程を分けずに一つの請負契約で進めたほうが、手間と検収の確実性のバランスが取れることもあります。工程を分けるかどうかも、仕様の固さから判断します。

開発を頼まなくても、ここだけ相談できる

契約形態の選び方、合格条件の書き方だけでも相談できます。実装を当社が担当しない案件でも同じです。すでに契約を結んでいる案件でも、次の工程の契約形態を選ぶところから相談できます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

AI開発の契約は、請負と準委任のどちらを選ぶべきですか

仕様と合格条件が契約時点で書き切れるなら請負、探索が多く成果物が途中で動くなら準委任が合います。

工程ごとに契約を分けることはできますか

できます。要件定義やPoCの段階は準委任、成果物が固まった本開発は請負というように分けることが一般的です。

精度を契約でどう保証すればよいですか

「精度○%を保証」という数値の約束ではなく、評価データ・指標・許容水準を事前に合意する形にします。

最初から請負で発注してはいけないのですか

仕様が固まっていない段階で請負にすると、探索の途中で仕様変更が繰り返され、契約と実態がずれます。探索が多い段階は準委任から始めることを勧めます。

PoCと本開発で契約を分ける理由は何ですか

PoCは実現可能性を確かめる作業で、成果物を確定できません。本開発は成果物と合格条件を確定させた段階です。段階が変わると、合う契約形態も変わります。

この判断は、AIを使わない開発でも同じですか

基本的な考え方は同じですが、AI開発では精度の不確実性という要素が加わる点が異なります。

開発を頼まなくても相談できますか

できます。契約形態の選び方、合格条件の書き方だけをお受けしています。

知財の帰属はどちらの契約でも決めておくべきですか

はい。請負・準委任のどちらでも、AIが生成したコードの著作権・利用条件は契約に明記します。

準委任から請負に切り替えるタイミングは、どう見ればよいですか

成果物の形と合格条件の両方が文書にできる状態になったかどうかで見ます。片方だけでは、検収の段階で解釈の違いが出ます。

請負契約での契約不適合責任は、仕様が曖昧でも問えますか

問いにくくなります。責任の範囲を判断する基準は契約の内容、つまり仕様です。仕様が曖昧なまま契約を結ぶと、責任の範囲を判断する基準そのものが曖昧になります。

大きな開発を、工程ごとに契約と検収を分けるメリットは何ですか

完成の判断が最後の一回に集中せず、工程ごとに意図とのずれを確認できます。分割の単位が細かいほど、途中でのやり直しの範囲も小さくできます。

工程ごとに検収する場合、次の工程に進む前に何を決めておく必要がありますか

その工程の合格条件を、文書として先に決めておきます。合格条件があいまいなまま次の工程に進むと、あとでやり直しが必要になったときに契約上の範囲が分からなくなります。

AIを使うシステム開発を外部に発注するとき、通常のシステム開発と同じ渡し方で要件定義をすると、動くものは出ても意図と違うものになりがちです。変わる点は三つあります。仕様の割り方、AIに渡してよい情報の範囲、何を確かめれば合格かです。この記事は発注側の目線で書きます。実装者向けの書き方の手順は扱いません。

通常の外注と変わる三つ

三つとも、実装が始まる前に決めることが条件です。実装が進んでからでは、実装に合わせた基準になります。

仕様の割り方が変わる理由

人向けの要件定義をそのままAIに渡すと、動くものは出ても意図とは違います。手戻りは、人手だけの開発より大きくなります。何が確定していれば、その塊をAIに渡してよいかを先に決めます。画面、入出力、例外の扱いを、人の言葉で先に書きます。

この分割は、エンジニアが読みやすい仕様書の書き方とは別の話です。発注側が、渡す前に何を確定させるかという分割の単位を持つことが目的です。分割の考え方そのものは人向けの要件定義を、AIに渡せる粒度まで割る方法で詳しく書いています。

行間を読む前提が働かない

人が実装するときは、書かれていない部分を経験で補います。画面の細かい挙動や、想定していない入力への対応がそれに当たります。AIにはこの前提が働きません。書かれていないことは、書かれていないとおりに実装されます。要件定義の段階で、この差を意識しておく必要があります。

入力の範囲を区切る理由

顧客情報や未公開の事業計画を、AIに渡してよい範囲を先に区切ります。区切らないまま進めると、機密が外部のAIサービスに渡ったあとで気づくことになります。この案件でAIに何を渡してよいかで書いた線引きが、ここに当たります。

通常の外注と違う理由

通常の外注では、実装者に渡す情報の範囲は契約と業務上の慣習で決まります。AIを使う開発では、実装者だけでなくAIサービス自体にも情報が渡ります。渡す先が一段増える分だけ、確認する範囲も広げる必要があります。

合格条件が変わる理由

AIが実装もテストも書くと、テストが実装の写し鏡になり、検証として成立しません。何を確かめれば出してよいかを、実装前に人が書きます。何を確かめれば合格かで詳しく書いています。

検収の物差しが変わる

通常の外注では、仕様どおりに動くかどうかで検収します。AIを使う開発では、仕様どおりに動くことに加えて、頼んだとおりに動くことまで確認する必要があります。この二つの違いは何を確かめれば合格かで書いています。契約の形にどう反映するかはAI開発の契約形態は請負か準委任かで扱っています。

要件定義書に書く前に、決めておくとよいこと

要件定義書を書き始める前に、この案件がどこまで仕様を固められる段階にあるかを見立てておくと、書く手間が減ります。仕様と合格条件がすでに固まっている段階であれば、要件定義書は確定事項の記録として書けます。まだ探索の要素が多い段階であれば、要件定義書よりも先に、どこまでを固め、どこからを進めながら決めるかという区切りを話し合っておく必要があります。

この見立てが、契約形態の選び方にもつながります。仕様が固まっている段階なら請負契約で仕様どおりの完成を約束できますが、探索の要素が多い段階では、成果物の完成を約束しない準委任契約のほうが実態に合います。契約形態を選ぶ考え方はAI開発の契約形態は請負か準委任かで書いています。

発注側が見落としやすい前提

通常の外注に慣れている発注側ほど、要件定義書さえ渡せば、あとは実装者の経験で細部が補われると考えがちです。この前提は、AIを使う開発では成立しません。実装者の経験に相当する「行間を読む力」を、AIは持っていないためです。見落としやすいのは、正常な操作だけを想定した要件定義書を渡し、異常な操作や想定外の入力への対応を実装側の裁量に任せてしまう進め方です。この部分をAIに任せると、想定していない挙動として実装されることがあります。

もう一つ見落としやすいのは、発注側の担当者が複数人いて、それぞれが実装者に口頭で補足を伝えている場合です。人が実装者であれば、複数の担当者から伝わった補足情報を、経験でまとめて整理してくれることがあります。AIに渡す情報は、口頭の補足も含めて、着手前に一つの文書へまとめておく必要があります。まとめずに進めると、担当者ごとに違う前提のまま実装が進み、後になって食い違いが表面化します。

開発を頼まなくても、ここだけ相談できる

仕様の割り方、入力の範囲の線引き、合格条件の設計だけでも相談できます。実装を当社が担当しない案件でも同じです。すでに要件定義書がある案件でも、AIに渡す前提で見直すところから相談できます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

AIを使うシステム開発の要件定義は、通常の外注と何が違いますか

仕様の割り方、AIに渡してよい情報の範囲、何を確かめれば合格かの三つが変わります。実装が始まる前に、この三つを決めます。

なぜ人向けの要件定義をそのまま渡してはいけないのですか

動くものは出ても意図とは違うものになります。手戻りが人手だけの開発より大きくなります。

仕様をAIに渡せる粒度まで割るとは、具体的に何をすることですか

何が確定していれば、その塊をAIに渡してよいかを決めることです。画面、入出力、例外の扱いを、人の言葉で先に書きます。

この記事は、エンジニア向けの仕様書の書き方を解説していますか

していません。発注側が渡す前に何を確定させるかという分割の単位を扱っています。実装者の書き方の手順は対象外です。

AIに渡してよい情報の範囲は、誰が決めるのですか

発注側です。顧客情報や未公開の事業計画をAIに渡してよいかどうかを、着手前に区切ります。

合格条件を実装前に決めるのはなぜですか

AIが実装とテストの両方を書くと、テストが実装の写し鏡になります。全部通っても、確かめたことにはなりません。

開発を頼まなくても相談できますか

できます。仕様の割り方、入力の範囲の線引き、合格条件の設計だけをお受けしています。

AI開発は通常のシステム開発より費用が安くなりますか

書く時間は短くなりますが、決める時間と確かめる時間は増えます。安くなる前提では進めません。

すでに要件定義書がある場合、作り直す必要がありますか

作り直す必要はありません。既存の要件定義書を、AIに渡せる粒度まで割り直すところから始められます。

仕様がまだ固まっていない段階でも、要件定義書を書くべきですか

その段階では、要件定義書よりも先に、どこまでを固め、どこからを進めながら決めるかという区切りを話し合うことを勧めます。

要件定義の段階の見立てが、契約形態の選び方にどう関わりますか

仕様が固まっている段階なら請負契約が合い、探索の要素が多い段階なら準委任契約が合います。要件定義の見立てと契約形態の選び方は、地続きの判断です。

正常な操作だけを想定した要件定義書は、なぜ問題になりますか

異常な操作や想定外の入力への対応が、実装側の裁量に任されてしまうためです。人であれば経験で補いますが、AIは想定していない挙動として実装することがあります。

PMO（プロジェクト・マネジメント・オフィス）は、複数のプロジェクトを横断して進捗・課題・リスクを管理する組織や役割です。当社が主柱にしているのは、これとは別の判断です。AIが書いたコードを、誰の責任で本番に出せる状態にするかを、実装前に決めることです。この二つは、同じ「プロジェクトマネジメント」という言葉で呼ばれますが、頼める中身が違います。

PMOが管理するもの

PMOは、プロジェクトの計画策定、進捗管理、リソース配分、リスク管理、品質管理、コミュニケーション管理、ステークホルダー管理など、進行に関わる業務を横断的に支援します。PMOを置く目的は、プロジェクトマネージャーが戦略的な判断やチームのリーダーシップに集中できる体制を作ることです。

複数のシステム開発プロジェクトが同時に走っている企業では、プロジェクトごとに進め方がばらつきます。PMOはその横串を通す役割です。

PMOが得意な場面

PMOは、複数プロジェクトの進め方を揃え、リソースの配分を全体で見る場面で力を発揮します。1件のプロジェクトの内側で、AIが書いたコードを誰が引き受けるかという判断までは、PMOの標準的な役割には含まれていないことが多いです。

PMOの機能は、大きく分けると三つの型があると言われます。個々のプロジェクトを支援する型、複数プロジェクトの型を揃える型、経営に近い立場で全体を統制する型です。企業がPMOを立ち上げるときは、このどの型を求めているかによって、期待する役割が変わります。いずれの型でも、1件のAI開発案件の中で「誰が合否を決めるか」という判断そのものを担うことは、標準的な役割の中心ではありません。

当社が主柱にしている「引き受け」

進行管理

PMOが管理するのは、複数プロジェクトの進捗・課題・リスク・会議体です。プロジェクトが計画どおり進んでいるかを、横断的に見る役割です。

引き受け

当社が主柱にしているのは、AIが書いたコードを本番に出せる状態にする判断です。当社のメンバーには、大手企業のシステム基盤の刷新や、大手SNS内サービスの開発とUIUXを担当してきた経験を持つ人がいます。実装に近い距離で判断してきた経験が、この引き受けの型に反映されています。

見分け方

進行管理を頼みたいのか、合格の責任を頼みたいのかで、依頼先が変わります。

誰が引き受けるのかで書いたとおり、主柱の一行は「AIが書いたコードを、誰が引き受けるのか。」です。PMOの進行管理とは、扱う対象そのものが違います。

見分け方

進行管理を頼みたいのか、合格の責任を頼みたいのかで、依頼先が変わります。プロジェクトが複数走り、横断的な体制を整えたい場合はPMOが向きます。AIが書いたコードを、誰の責任で本番に出せる状態にするかを一緒に決めたい場合は、当社の主柱に近い依頼になります。

両方が必要な場合もあります。PMOが進行を管理する一方で、AIが書いたコードの引き受けだけを別に切り出して相談することもできます。外部PMへの依頼一般についてはシステム開発のPM外注、丸投げにしないために発注側が決めることで書いています。

両方が必要になる、よくある組み合わせ

複数のシステム開発プロジェクトを同時に進めている企業では、PMOが全体の進め方を揃え、個々のプロジェクトの中で「AIが書いたコードを誰が引き受けるか」という判断だけを、案件ごとに別で固めることがあります。この組み合わせでは、PMOに報告する進捗の数字と、AIが書いたコードの合否という判断の質は別のものとして扱う必要があります。進捗が計画どおりでも、合否の判断が固まっていなければ、本番に出せる状態にはなりません。

特に、AIを使うシステム開発を外部に発注する場合は、要件定義の段階で通常の外注とは異なる判断が入ります。この違いはAIシステム開発の要件定義で、通常の外注と変わる三つで書いています。PMOが進行を揃える一方で、この要件定義側の判断は別の物差しで見る必要があります。

開発を頼まなくても、ここだけ相談できる

仕様の割り方、AIの利用範囲の線引き、合格条件の設計だけでも相談できます。実装を当社が担当しない案件でも同じです。PMOが別に入っている案件でも、合否の判断だけを切り出してご一緒することができます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

PMOと、当社が主柱にしていることは何が違いますか

PMOは複数プロジェクトの進捗・課題・リスクを横断的に管理します。当社が主柱にしているのは、AIが書いたコードを誰の責任で本番に出すかという、もう一段別の判断です。

PMOに依頼すれば、AIが書いたコードの合否も見てもらえますか

PMOの役割は進行管理が中心で、合格条件そのものの設計は含まれないことが多いです。別に切り出して相談することができます。

PMOと当社の両方に依頼することはできますか

できます。PMOが進行を管理する一方で、AIが書いたコードの引き受けだけを当社に相談することができます。

PMOを置くべきかどうかは、どう判断しますか

複数のプロジェクトが同時に走り、進め方がばらついている場合はPMOが向きます。1件のAI開発案件で、誰が合否を決めるかだけを先に固めたい場合は、当社の主柱に近い依頼になります。

「引き受ける」とは、具体的に何をすることですか

生成されたコードの権利、機密を入力してよいか、問題が起きたときの責任、本番に出してよいかの判断です。

開発を頼まなくても相談できますか

できます。仕様の割り方、AIの利用範囲の線引き、合格条件の設計だけをお受けしています。

PMBOKに基づくプロジェクトマネジメントとは別物ですか

PMBOKは進行管理の体系的な知識体系です。当社が主柱にしているのは、その体系の中でも、AIが書いたコードの合否という特定の判断です。

内製に着手したあと、進まなくなった場合も対象ですか

対象です。止まっている場所が、仕様の割り方・AIの線引き・合格条件のどれに当たるかを先に見ます。

PMOと当社を両方使う場合、報告の仕組みはどう分けますか

PMOへの進捗報告と、AIが書いたコードの合否判断は別のものとして扱います。進捗が計画どおりでも、合否の判断が別に固まっていなければ本番には出せません。

外部PM一般への依頼と、PMOへの依頼はどう違いますか

外部PMは1件のプロジェクトの進行を担うことが多く、PMOは複数プロジェクトを横断します。外部PMへの依頼で発注側が決めるべきことはシステム開発のPM外注、丸投げにしないために発注側が決めることに書いています。

PMOには、いくつかの型があるのですか

個々のプロジェクトを支援する型、複数プロジェクトの型を揃える型、経営に近い立場で統制する型の三つがあると言われます。どの型でも、1件のAI開発案件の合否判断は標準的な役割の中心ではありません。

AIシステム開発の要件定義とPMOは、どう関係しますか

直接は関係しません。PMOは進行を横断的に揃える役割で、要件定義の中身そのものには踏み込みません。AIを使う開発特有の要件定義の変化は別に見る必要があります。

システム開発のプロジェクトマネジメントを外部に任せても、発注側の関与がゼロにはなりません。「開発会社に依頼したのだから、あとはお任せでいい」という進め方は、失敗の原因になります。丸投げにしないために、着手前に三つを決めます。外部PMに渡す範囲、発注側が見る場所、外注先の「終わった」をどう受け取るかです。

外注しても、発注側の仕事が消えるわけではない

PMを外部の会社やフリーランスに依頼すると、進捗管理・課題管理・会議の運営といった作業は外部に移ります。しかし、何を優先するかの判断、仕様の変更を認めるかどうか、費用が増えたときにどこまで許容するかは、発注側にしか決められません。この判断を外部PMに預けてしまうと、進んではいるが誰も責任を持てない状態になります。

QCD（品質・コスト・納期）にコミュニケーションを加えた4つが、外部委託でも発注側が管理すべき要素だと言われます。外部PMは進行を管理しますが、この4つの最終判断は発注側に残ります。

判断と作業を分ける

外部PMが担うのは、進捗表の更新、課題を一覧にすること、会議の運営といった「作業」です。何を優先するか、どこまでの変更を認めるかという「判断」は、作業とは別のものです。この二つを分けずに丸ごと外部PMに渡すと、判断まで現場任せになります。

丸投げにしないために決める三つ

渡す範囲

外部PMに任せる作業と、発注側が残す判断を分けます。進捗管理や会議運営は渡してよい作業ですが、優先順位や仕様変更の承認は発注側が残す判断です。この境界を最初に文書にしておくと、外部PMも判断を仰ぐべき場面を迷わずに済みます。

見る場所

進捗表を誰が持ち、何を見て「止める」と判断するかを先に決めます。進捗率の数字だけを見ていると、実際には行き詰まっている作業が「順調」に見えることがあります。数字の裏にある根拠まで確認する場所を、あらかじめ決めておきます。

受け取る基準

外注先の「終わった」を、発注側がどう受け取るかを書きます。仕様どおりに動くかという確認だけでなく、実際の利用場面を想定した確認まで含めるかどうかを、着手前に合意しておきます。

この三つは、外部PMが優秀かどうかとは別の話です。優秀なPMでも、発注側が何を残すかを決めていないと、判断の拠り所がありません。

丸投げが起きやすい場面

新規事業の立ち上げなど、発注側の担当者が他の業務と兼務している場合、外部PMに依頼した時点で安心してしまい、進捗確認の頻度が落ちることがあります。外部PMからの報告を待つだけの体制になると、報告に上がってこない小さな懸念が、大きくなってから発注側に届きます。

複数の案件を同時に抱えている担当者ほど、丸投げが起きやすくなります。渡す範囲・見る場所・受け取る基準の三つをあらかじめ文書にしておくと、担当者が忙しいときでも、最低限確認すべき場所が明確なままになります。

外部PMとPMOの、どちらに近いか

外部PMへの依頼は、プロジェクト単体の進行を任せる形と、PMOとして複数プロジェクトを横断的に見る形があります。当社が主柱にしているのは、どちらでもありません。AIが書いたコードを、誰の責任で本番に出せる状態にするかを、実装前に決める仕事です。誰が引き受けるのかで書いた内容がこれに当たります。PMOに依頼できることと、この主柱との違いはPMOに依頼できることと、当社が主柱にしている「引き受け」の違いで詳しく書いています。

進行を管理してほしいのか、AIが書いたコードを引き受けてよいかの判断まで含めて相談したいのかで、依頼先の選び方が変わります。

外部発注の契約形態も、あわせて決めておく

PMを外部に依頼するときも、進行管理そのものを準委任で依頼するのか、特定の成果物（要件定義書やAI利用方針の文書など）を請負で依頼するのかを決めておくと、渡す範囲がより明確になります。進行管理は業務の遂行そのものが目的であり、成果物の完成を約束する性質のものではないため、準委任が合うことが多いです。開発本体の契約形態を選ぶ考え方はAI開発の契約形態は請負か準委任かで書いています。

開発を頼まなくても、ここだけ相談できる

渡す範囲の決め方、見る場所の設計、受け取る基準の書き方だけでも相談できます。実装を当社が担当しない案件でも同じです。すでに外部PMが動いている案件で、この三つの線引きだけを後から一緒に整理することもできます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

PMを外注すると、発注側は何もしなくてよいのですか

いいえ。進捗管理などの作業は外部に移りますが、優先順位の判断や仕様変更の承認は発注側に残ります。

丸投げにしないために、最初に決めることは何ですか

外部PMに渡す範囲、発注側が見る場所、外注先の完成をどう受け取るかの三つです。

フリーランスのPMと、PM会社への依頼はどちらがよいですか

プロジェクトの規模で選び方が変わります。小規模でスポット的な案件はフリーランスが向き、規模が大きく体制ごと任せたい場合は会社への依頼が向きます。どちらでも、この記事の三つは同じように必要です。

PMOへの依頼と、この記事の内容はどう違いますか

PMOは複数プロジェクトを横断した進行管理が中心です。当社が主柱にしているのは、AIが書いたコードを誰の責任で本番に出すかという、もう一段別の判断です。

見る場所とは、具体的に何を指しますか

進捗表を誰が持ち、何を見て「止める」と判断するかです。問題が起きてから気づくのではなく、事前に決めておきます。

受け取る基準を決めないと、何が起きますか

完成の認識が発注側と外注先でずれます。外注先が「終わった」と言っても、発注側が思っていたものと違う状態で引き渡されることがあります。

開発を頼まなくても相談できますか

できます。渡す範囲の決め方、見る場所の設計、受け取る基準の書き方だけをお受けしています。

この考え方は、AIを使わない開発でも当てはまりますか

当てはまります。ただし当社が主柱にしているのは、AIが書いたコードを誰が引き受けるかという、AI開発に特有の判断です。

丸投げが起きやすいのは、どういう状況ですか

発注側の担当者が他の業務と兼務している場合や、複数の案件を同時に抱えている場合です。安心して進捗確認の頻度が落ちると、小さな懸念が大きくなってから発注側に届きます。

すでに外部PMが動いている案件でも、途中から相談できますか

できます。渡す範囲・見る場所・受け取る基準の三つが決まっていない場合、途中からでも整理することができます。

外部PMへの依頼と、開発本体の契約形態は別に決めるのですか

別に決めることを勧めます。進行管理は準委任が合うことが多く、開発本体は仕様の固さに応じて請負か準委任かを選びます。

QCDにコミュニケーションを加えた4つとは何ですか

品質・コスト・納期に、関係者間の連携を加えた考え方です。外部委託でも、この4つの最終判断は発注側に残ると言われています。

この開発案件で、AIにどこまで使わせてよいか。着手前に決めておかないと、生成コードの権利、機密の扱い、責任の所在が決まらないまま実装が進み、本番リリースの判断が止まります。決めることは三つです。何を入力してよいか、生成物の権利をどう扱うか、問題が起きたときの責任をどこに置くかです。誰が引き受けるのかで挙げた三つの決めごとの、二つ目です。

社内の生成AI利用ガイドラインとは別物

「AI利用ポリシー」と聞くと、従業員がChatGPTに何を入力してよいかという社内規程を思い浮かべることが多いです。ここで言う線引きは違います。従業員向けの規程は、日々の業務でAIを使う人に向けたものです。開発案件のAI利用方針は、特定の1案件でAIに何を渡し、生成物を誰が引き受けるかを決めるものです。

この二つを同じものとして扱うと、開発案件の承認が社内規程の会議に紛れ込み、決まらないまま進みます。社内規程を管理する部門と、開発案件を承認する部門が別であることも多く、どちらの会議で決めるかが曖昧なままだと、両方の会議で「まだ決まっていない」という状態が続きます。

対象が違う

社内規程は全従業員の日常的な利用を対象にします。開発案件のAI利用方針は、その1案件だけを対象にします。同じ会社の中でも、案件によって扱う情報の性質が違うため、案件ごとに決める必要があります。

着手前に決める三つ

入力してよい情報

顧客情報、未公開の事業計画、認証情報などを、AIに渡してよい範囲を先に区切ります。この範囲は、案件の性質によって大きく変わります。当社が手掛けた生成AIを組み込んだ開発では、問い合わせメールの内容を判定して返信テンプレートを提案する仕組みや、アプリストアのレビューを分析して返信を支援する仕組み、SNS上の誹謗中傷を検知して記録・対処する仕組みなど、扱う情報の性質が案件ごとに異なる実績があります。個人情報を含む問い合わせメールを扱う案件と、社内の規約・マニュアルだけを検索対象にする案件とでは、AIに渡してよい情報の範囲がまったく違います。

生成物の権利

AIが生成したコードの著作権・利用条件を、契約書に明記します。納品後に権利の帰属で揉めることを避けるため、契約時点で扱いを決めておきます。

責任の所在

AIが誤った生成物を出したときに、誰がどこまで責任を持つかを決めます。本番で問題が起きたとき、発注側と実装側のどちらの責任か切り分けられる状態にしておく必要があります。

この三つが文書になっていないと、情報システム部門は承認できません。動くものはあっても、出してよいと言い切れず、リリースの判断が止まります。

承認が止まる、よくある場面

内製に着手したあと、この三つが決まっていないまま実装が進み、リリース直前で情報システム部門から止められることがあります。実装が終わってから権利や機密の扱いを決めようとすると、すでに動いているコードに条件を後から当てはめる作業になり、手戻りが大きくなります。

複数の外部ベンダーが関わる案件では、どのベンダーがどこまでAIを使ってよいかも、着手前に揃えておく必要があります。ベンダーごとに基準が違うと、納品物の扱いが不揃いになります。あるベンダーは機密情報を含む入力を許可し、別のベンダーは許可していない、という状態になると、納品物全体の扱いを一つの基準で説明できなくなります。

案件の性質によって、線引きの厳しさが変わる

すべての案件に同じ厳しさの線引きを当てはめる必要はありません。当社の実績では、補助金申請に必要な事業計画の作成を支援する案件と、医療領域の大手企業向けに規約・マニュアルを検索する社内文書検索システムの案件があります。前者は事業計画という会社の意思決定に関わる情報を扱い、後者は社内文書という比較的公開性の高い情報を扱います。扱う情報の性質が違えば、AIに渡してよい範囲の決め方も違ってきます。着手前に、この案件がどちらに近いかを見立てることが、線引きの最初の一歩です。

開発を頼まなくても、ここだけ相談できる

入力してよい情報の線引き、生成物の権利の書き方、責任の所在の決め方だけでも相談できます。実装を当社が担当しない案件でも同じです。複数のベンダーが関わる案件で、基準をひとつに揃える役割だけをお受けすることもできます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

開発案件のAI利用方針は、社内の生成AI利用ガイドラインと同じですか

違います。社内規程は従業員がどのツールに何を入力してよいかを決めるものです。開発案件のAI利用方針は、その案件でAIに何を渡し、生成物を誰が引き受けるかを決めるものです。

着手前に決めることは、具体的に何ですか

AIに入力してよい情報の範囲、生成物の権利の扱い、問題が起きたときの責任の所在の三つです。

なぜ実装が始まってからではなく、着手前に決めるのですか

実装が始まってから決めると、すでに動いているコードに条件を後から当てはめることになり、手戻りが大きくなります。

情報システム部門が承認できない、とはどういう状態ですか

権利、機密、責任の所在が文書になっていない状態です。動くものはあっても、出してよいと言い切れず、リリースの判断が止まります。

複数の外部ベンダーが関わる場合はどうしますか

ベンダーごとに基準が違うと、納品物の扱いが不揃いになります。どのベンダーがどこまでAIを使ってよいかを、着手前に揃えます。

生成物の権利は、どこに書いておくのですか

契約書に明記します。AIが生成したコードの著作権・利用条件を、納品後ではなく契約時に決めます。

開発を頼まなくても相談できますか

できます。入力してよい情報の線引き、生成物の権利の書き方、責任の所在の決め方だけをお受けしています。

内製に着手したあと、進まなくなった場合も対象ですか

対象です。止まっている場所が、入力情報・権利・責任のどれに当たるかを先に見ます。当たるなら、そこを固めます。

案件によって、線引きの厳しさを変えてよいのですか

よいと考えています。事業計画のような意思決定に関わる情報を扱う案件と、社内文書のような公開性の高い情報を扱う案件では、同じ厳しさを当てはめる必要はありません。

AI利用の方針は、実装が始まったあとに見直せますか

見直せますが、見直しの都度、動いているコードへの影響を確認する作業が発生します。着手前に決める範囲を広めに取っておくと、見直しの頻度を減らせます。

AIが実装もテストも書くと、テストが実装の写し鏡になり、検証として成立しません。全部通っても、それは「頼んだとおりに動く」ことの証明にはなりません。何を確かめれば合格かは、実装が始まる前に人が決めます。中身は三つあります。受け入れ条件を発注側の言葉で先に文書にすること、テストの方針を決めること、AIが一日に出す量のうち、どこを人が読むかを決めることです。誰が引き受けるのかで挙げた三つの決めごとの、三つ目です。

テストが実装の写し鏡になる、とは

人が実装し、人がテストを書くときは、二人の目が入ります。実装した人の思い込みを、テストを書いた人が気づくことがあります。役割が分かれているからこそ、片方の見落としをもう片方が拾えます。AIが実装とテストの両方を書くと、この二人目の目がありません。実装のとおりに動くことを、実装のとおりに書いたテストが確認するだけになります。

結果は、テストが全部通ることです。しかし、それは「実装した通りに動く」ことしか確認していません。「頼んだ通りに動く」かどうかは、確認されていません。この差が、本番で壊れる原因になります。

この二つは別のことです。テストが通ったことを、出してよい根拠にしないことが最初の一歩です。ソフトウェア開発では、実装した人とは別の立場が確認を担う考え方が以前からあります。AIが実装とテストの両方を書く状況は、この役割分担を一人分に圧縮してしまいます。だからこそ、確かめる側の基準を、実装が始まる前に人の手で用意しておく必要があります。

実装前に決める、合格の物差し

実装が始まってから合格条件を決めると、実装に合わせて基準が動きます。実装前に、次の三つを文書にします。

受け入れ条件

何ができていれば合格かを、実装する側の言葉ではなく、発注側の言葉で先に書きます。実装が終わってから書くと、実装に合わせた基準になり、後出しの物差しになります。

テスト方針

どこまでをテストで確認し、どこからを人が確認するかを分けます。AIの実装範囲とテストの範囲が同じままだと、テストの網が実装の形をなぞるだけになり、抜けが見えません。

レビュー範囲

AIが出したコードのうち、人が必ず読む部分を先に決めます。範囲を決めずに全部読もうとすると、量が多く、実際にはどこも深く読まれません。読む場所と読まない場所の分け方は、AI生成コードのレビューは、どこを読んで、どこを読まないかに書いています。

三つとも、実装が始まる前に決まっていることが条件です。実装が進んでから決めると、後出しの基準になります。

レビュー範囲は、なぜ絞る必要があるか

AIが一日に出すコードの量は、人が一日に全部読める量を超えます。全部読むことを前提にすると、レビューが形だけになり、結局どこも深く読まれません。人の集中力には限りがあり、量が増えるほど一件あたりの読み込みは浅くなります。

絞る基準は、影響の大きさです。外部に公開される入出力、金額や個人情報を扱う処理、他のシステムと連携する部分は必ず読みます。表示だけが変わる部分や、内部でしか使わない補助的な処理は、テストの結果で判断してよい範囲に回します。

この線引きを実装前に決めておくと、レビューする人が「今日はどこを読むか」で迷わなくなります。迷う時間が減った分だけ、影響の大きい部分に時間を割けます。

受け入れ条件は、仕様の割り方と地続きになっている

受け入れ条件を発注側の言葉で書くには、そもそも仕様がAIに渡せる粒度まで割れていることが前提になります。仕様が大きな塊のままだと、何ができていれば合格かを一文で書けません。人向けの要件定義を、AIに渡せる粒度まで割る方法で書いた分割の単位が、ここでの受け入れ条件の粒度と一致します。

同様に、AIにどこまで渡してよいかという線引きが決まっていないと、テスト方針の中で「AIが生成した部分」と「人が書いた部分」の境界も曖昧になります。この案件でAIに何を渡してよいかで決めた範囲が、レビュー範囲の設計にも影響します。

テスト方針を分けるときの目安

どこまでをテストで確認し、どこからを人が確認するかを分けるとき、目安になるのは「入力の組み合わせが有限で、機械的に判定できるか」です。入力の形式が決まっていて、正しいか誤りかを機械的に判定できる部分は、テストで確認する範囲に向いています。反対に、複数の選択肢のうちどれが利用者にとって望ましいかという、判断が分かれる部分は、人が確認する範囲に残します。

この分け方をしておくと、AIが実装した範囲のうち、どこがテストで守られ、どこが人の目でしか守られないかが見えるようになります。人が確認する範囲が広いほど、レビューにかける時間の見積もりも立てやすくなります。

開発を頼まなくても、ここだけ相談できる

受け入れ条件の書き方、テスト方針の分け方、レビュー範囲の線引きだけでも相談できます。実装を当社が担当しない案件でも同じです。内製チームがすでに動いている場合は、途中から合流して合格の物差しだけを一緒に固めることもできます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

テストが全部通っているのに、なぜ合格と言えないのですか

AIが実装とテストの両方を書くと、テストが実装の写し鏡になるためです。実装のとおりに動くことは確認できても、頼んだとおりに動くことは確認できていません。

受け入れ条件は誰が書くのですか

発注側です。実装する側の言葉ではなく、何ができていれば合格かを発注側の言葉で書きます。実装前に文書にします。

受け入れ条件と、いわゆる単体テスト・結合テストはどう関係しますか

単体テストや結合テストは、実装が仕様のとおりに動くかを内側から確認するものです。受け入れ条件は、発注側が外側から見て合格と判断するための基準です。両方が必要で、片方だけでは足りません。

テスト方針とは、具体的に何を決めるのですか

どこまでをテストで確認し、どこからを人が目で確認するかの分担です。AIの実装範囲とテストの範囲が同じにならないようにします。

レビュー範囲を絞ってよいのですか。全部読むべきではないですか

全部読むことを前提にすると、量が多く、実際にはどこも深く読まれません。影響の大きい部分（外部公開、金額、個人情報、他システム連携）を先に決めて、そこは必ず読みます。

この合格の物差しは、実装が始まってからでも決められますか

決められますが、実装に合わせた後出しの基準になります。実装前に決めることで、基準が実装から独立します。

雛形やチェックリストは公開していますか

この記事では出していません。何が決まっていないと止まるかまでを書いています。案件ごとに書き起こします。

AIが書いたコードのレビューは、エンジニアが読む観点と同じですか

違います。エンジニアの読み方は実装の正しさを見ますが、ここで言うレビュー範囲は、発注側が出してよいと判断するための範囲です。

開発を頼まなくても、この部分だけ相談できますか

できます。受け入れ条件、テスト方針、レビュー範囲の設計だけをお受けしています。

受け入れ条件とテスト方針は、同時に決める必要がありますか

同時に決めることを勧めます。受け入れ条件が先に決まっていないと、テスト方針を立てる根拠がありません。

レビュー範囲を決めても、AIが出したコード全体の品質は保証されますか

保証にはなりません。レビュー範囲は、限られた時間の中で優先して確認する場所を決める考え方です。範囲外の部分はテストの結果で判断します。

「AI駆動開発のプロジェクトマネジメント」という言葉には、いま二つの意味が混在しています。一つは、AIを使って進捗表や議事録、リスク管理表を素早く作る仕事です。もう一つは、AIが書いたコードを誰が引き受け、本番環境に出せる状態にするかを、実装が始まる前に決めておく仕事です。株式会社ワンオブゼムが主柱に据えているのは後者で、内容は三つの決めごとに分かれます。仕様をAIに渡せる粒度まで割ること、AIの利用範囲を着手前に線引きすること、そして何を確かめれば合格と言えるかを実装前に人が決めることです。この記事では、二つの意味がなぜ混ざるのか、当社がなぜ後者を主柱に選んだのかを書きます。

二つの意味

「AI駆動開発」も「プロジェクトマネジメント」も、それぞれ単体では長く使われてきた言葉です。二つを組み合わせた瞬間に、AIツールでPM業務を進める話と、AIが書いたコードの責任を誰が持つかという話が、同じ検索結果の中に並びます。読み手が探しているのがどちらかを確かめずに記事を読み進めると、ツールの使い方の話を、責任の話だと思い込んだまま終わることがあります。

意味Aは、PMの手元にある議事録や進捗表、リスク管理表をAIが下書きする話です。効率を上げるための記事やツールの比較記事が数多く出ており、この記事では扱いません。意味Bは、発注する側が本番リリースの直前に下す判断そのものです。ここには、相談先として名乗っている会社がまだ多くありません。株式会社ワンオブゼムが主柱として扱うのは、この意味Bです。

書いたコードを引き受ける、とは

もう少し具体的に言うと、AIが書いたものを誰の責任で本番に出せる状態にするか、実装が始まる前に決めておく仕事です。決めるのが遅れるほど、後から条件を当てはめる作業になり、手戻りが大きくなります。

AIに書かせること自体は、いまや多くの会社ができます。短くなるのは書く時間だけです。何を作るかを決める時間と、出来上がったものが本当に動くと言い切るための確認の時間は、むしろ増えます。当社は2016年からAIの研究開発に取り組んでおり、生成AIが広く使われるようになる以前から、この種の判断の難しさに向き合ってきました。

止まる場所は、技術そのものではありません。次の三つです。

意図とのずれ

人向けに書かれた要件をそのままAIに渡すと、動くものは出ても意図とは違います。人が実装するときは行間を読んで補ってくれた部分が、AIでは埋まりません。書かれていないことは、書かれていないとおりに実装されます。

承認が下りない

機密情報の扱いや、生成コードの権利についての線引きが無いまま実装が進むと、出来上がった後の本番リリースの判断で止まります。動くものはあっても、情報システム部門が出してよいと言い切れません。

テストが写し鏡になる

AIが実装もテストも書くと、テストが実装の写し鏡になります。全部通っても、それは「実装のとおりに動く」ことしか確認していません。「頼んだとおりに動く」かどうかは、別に確かめる必要があります。

主柱の一行は、この三つを一つの問いにしています。

AIが書いたコードを、誰が引き受けるのか。

詳細はAI時代のプロジェクトマネジメントに置いてあります。

先に決めておく三つ

型は、発注側が踏む場所に合わせて三つに分けています。雛形の公開は、この記事ではしません。決まっていないと止まる場所だけを書きます。

仕様を、AIに渡せる粒度まで割る

人向けの要件をそのまま渡すと、動くものは出ても意図とは違います。何を確定させてから実装に入るかという分割の単位を、着手前に持っておく必要があります。詳しくは人向けの要件定義を、AIに渡せる粒度まで割る方法に書いています。

AIをどこまで使うかを先に決める

生成コードの権利、機密の扱い、責任の所在が決まらないと、本番リリースの判断が止まります。社内の生成AI利用規程とは別に、案件ごとの線引きが必要です。詳しくはこの案件でAIに何を渡してよいかに書いています。

何を確かめれば合格かを、実装前に人が決める

AIが実装もテストも書くと、テストが実装の写し鏡になり、検証として成立しません。受け入れ条件、テスト方針、レビュー範囲を実装前に固める必要があります。詳しくは何を確かめれば合格かに書いています。

三つとも、実装が始まる前に決まっていることが条件です。実装が進んでからでは、実装に合わせた後出しの基準になります。

なぜ、いま線引きが必要になったのか

生成AIがコードを書く量が増えるほど、実装そのものにかかる時間は短くなります。一方で、発注する側の負担は減りません。何を作るかを決める難しさ、AIをどこまで使ってよいかという判断、出来上がったものが本当に動くと言い切るための確認作業。この三つは、AIが速くなるほど重くなります。実装が速くなった分だけ、決める作業と確かめる作業に時間を使う必要があります。

この負担を減らす方向で考えると、AIの利用を狭める話になりがちです。当社が主柱にしているのは逆の発想です。AIをどこまで使ってよいかを先に決めてしまえば、その範囲の中では迷わずに進められます。線引きは、AI活用を止める理由ではなく、AI活用を進める条件です。

どちらを探しているか

探している語が、どちらの意味に近いかだけを見ます。費用の安さや期間の短さを求めている語は、この記事の対象ではありません。

この四つの近い語のうち、意味Bに当たるものだけが、この記事とその子記事の対象です。単価や期間の話は別の土俵であり、当社が主柱として扱う三つの決めごととは接続しません。

開発を頼まなくても、三つだけを頼める

当社が実装を担当しない案件でも、仕様の割り方、AI利用の線引き、合格条件とレビュー範囲の設計だけをお受けできます。要件定義とAI利用方針の策定、品質保証の設計に加えて、複数のベンダーが関わる案件では取りまとめもご一緒します。内製に着手したあと進まなくなった段階からでも、見るべき場所は同じ三つです。

決めるだけでなく、そのまま手を動かして本番稼働まで運ぶ形もあります。考え方はAboutに、相談はお問い合わせにあります。

よくある質問

AI駆動開発のプロジェクトマネジメントとは何ですか

AIが書いたものを、誰の責任で本番に出せる状態にするかを、実装の前に決めておく仕事です。進捗や書類をAIで回す仕事ではありません。

AIでプロジェクトを管理することとの違いは何ですか

「AIでプロジェクトを管理すること」は意味Aで、PMの手元の書類や進捗をAIが下書きします。この記事が扱う意味Bは、書いたコードを誰が引き受けて出すかを先に決めることです。呼び方が同じでも、買い手も成果物も違います。

「誰が引き受けるのか」は、具体的に何を指しますか

生成されたコードの権利、機密を入力してよいか、問題が起きたときの責任、本番に出してよいかの判断です。ツールの操作者のことではありません。

開発を頼まなくても相談できますか

できます。仕様の割り方、AI利用の線引き、受け入れ条件とレビュー範囲だけをお受けしています。

なぜ合格条件を実装前に決めるのですか

AIが実装とテストの両方を書くと、テストが実装の写し鏡になります。全部通っても、確かめたことにはなりません。合格の物差しは、人が先に持ちます。

AI利用の方針は、社内の生成AI規程と同じですか

違います。社内規程は、従業員がどのツールに何を入力してよいかです。ここで言う方針は、この開発案件でAIに何を渡し、生成物を誰が引き受けるかです。

AIを使うと開発は安くなりますか

書く時間は短くなります。決める時間と確かめる時間は増えます。安くなる前提では進めません。

雛形やチェックリストは公開していますか

この記事では出していません。決まっていないと止まる場所だけを書いています。案件ごとに書き起こします。

情報システム部門が承認できない、とはどういう状態ですか

権利、機密、責任の所在が文書になっていない状態です。動くものはあっても、出してよいと言い切れず、リリースの判断が止まります。

内製に着手したあと、進まなくなった場合も対象ですか

対象です。止まっている場所が、仕様の割り方・AIの線引き・合格条件のどれに当たるかを先に見ます。当たるなら、実装の前にそこを固めます。

「意味A」と「意味B」を、両方同時に進めることはできますか

できます。AIで進捗管理を進める取り組みと、AIが書いたコードを誰が引き受けるかを決める取り組みは両立します。この記事は後者に絞って書いています。

この主柱は、当社が2016年から取り組んできたAIの研究開発とつながっていますか

つながっています。当社は2016年からAIの研究開発に取り組んでおり、生成AIが広く使われる以前からの経験を、この判断の型に反映しています。