プロジェクト概要
AI を活用して開発を進めている企業から、「不具合が多いという指摘はあるが、原因を誰も特定できていない」という相談を受け、開発現場の調査と改善提案を行いました。
対象は 14 ヶ月分の開発記録です。第三者の立場で全期間を実測し、個人の力量の問題なのか、進め方の問題なのかを数字で切り分けることを目的としました。
| 項目 | 内容 |
|---|---|
| クライアント | SaaS・AI プロダクトを開発する企業 |
| 対象者 | 現役エンジニア (すでに AI を使って開発中) |
| 調査対象 | 14 ヶ月分の開発記録 |
| 範囲 | 調査と改善提案 (改修は先方で実施) |
クライアントの課題
相談の時点で分かっていたのは「不具合が多い」という事実だけでした。
社内では原因についていくつかの見方が出ていましたが、いずれも根拠は体感です。この状態で改善策を決めると、原因を外したまま現場の負担だけが増えます。
もう 1 つの難しさは、原因を議論すると「誰の責任か」の話になりやすいことでした。実際に手を動かしているエンジニアがいる以上、避けられない構造です。第三者が数字で整理する意味は、ここにもあります。
アプローチ
まず、何が起きているのかを数字で確かめる
改善策の検討には入らず、14 ヶ月分の開発記録をすべて実測するところから始めました。
見たのは「どれだけ作ったか」ではなく、作った後に何が起きたかです。
実測して分かったこと
壊れたものを直す作業が、新しく作る作業の 2 倍あった。
修正の作業が 1,077 件に対し、新規の作業が 516 件。開発に使っている時間の多くが、すでに作ったものを直すことに向いていました。
直した箇所のうち 29% が、1 週間以内に再び壊れていた。
修正が一度で終わっていません。同じ箇所に繰り返し手が入っている状態です。これは個人の注意不足というより、修正が正しいかを確認する手段が無いことを示しています。
変更のうち 74% が、誰のチェックも受けずに本番へ入っていた。
ここが最も大きい数字でした。10 件のうち 7 件は、書いた本人以外の目を通らずに反映されています。
数字が指していたこと
この 3 つを並べると、原因は個人の力量ではないことが分かります。
生成の速度が上がったこと自体は問題ではありません。問題は、速度が上がったのに、確認の仕組みが元のままだったことです。作る量が増えれば、確認しなければならない量も増えます。そこが追いついていませんでした。
提示した直す順番
作り方そのものを変える前に、問題のある変更を本番に入れない仕組みを戻す必要があると判断しました。
今週やること — 不具合を自動で見つける仕組みを、動く状態に戻す
調査の時点で、不具合を自動で検出する仕組み自体が機能していませんでした。
ここを直さないと、他の改善策も効果を出しにくい状態でした。 何かを変えても、変えた結果が良くなったのか悪くなったのかを確認する手段が無いためです。改善の効果を測れる状態に戻すことが、最初の一手になります。
今月やること — レビューを通らない変更は本番に入れない仕組みにする
変更の 74% が誰の目も通っていなかったので、レビューを通らなければ本番に入らない構造を作ります。
運用のルールとして「レビューしましょう」と決めるだけでは、急いでいるときに飛ばされます。仕組みとして通れないようにするほうが確実です。
継続して取り組むこと — 指示書を実態に合わせて直す
AI に読ませる指示書が、実際の開発の実態と合っていませんでした。ここを合わせないと、生成される内容が現場の規約から外れ続けます。
あわせて、中長期で手を入れるべき箇所を優先順位つきで提示しました。
成果
この診断をもとに、開発体制と開発環境の見直しに着手いただいています。
数字で整理したことの効果は、優先順位が決まったこと以上に、議論の対象が人から仕組みに移ったことにありました。「誰が気をつけるか」ではなく「どこでレビューを必須にするか」の話になると、対策が具体的になります。
学びと再利用可能なナレッジ
体感の原因と、実測の原因は一致しない
調査前に想定されていた原因と、実測で出てきた原因は違いました。これは珍しいことではありません。
不具合は目につくところで起きるため、印象に残った事象が原因だと解釈されやすくなります。実際には、目につかないところで起きている構造的な問題のほうが影響が大きいことがあります。
AI で速度が上がったときに壊れるのは、確認の側
作る速度が上がると、確認しなければならない量も比例して増えます。確認の仕組みが元のままだと、そこがボトルネックになり、やがて飛ばされます。
本事例のように AI 駆動開発で品質の問題が出ているとき、疑うべきは生成の質より確認の仕組みです。 生成の質を上げても、確認が追いつかなければ本番に入る不具合の数は変わりません。
「直す順番」は、他の施策の効果を打ち消すものから
改善策を並べたときに、どれから着手するかで結果が変わります。判断の基準は重要度ではなく、他の施策の効果を打ち消してしまうかどうかです。
本事例では、効果を測る仕組みが止まっていました。ここを直さずに他を変えると、良くなったのかどうかが誰にも分からないまま作業だけが積み上がります。
調査をしても改善につながらない 3 つの原因
調査を飛ばして改善策から入る。 原因が特定できていない状態で施策を入れると、効果が出なかったときに「やり方が悪かったのか、原因が違ったのか」が切り分けられません。
レビューを運用ルールとして決める。 ルールは急いでいるときに飛ばされます。飛ばせない構造にするほうが確実です。
数字を人の評価に使う。 実測した数字を個人の評価に結びつけると、次からは記録そのものが歪みます。数字は仕組みを直すために使うものです。