システム開発の属人化を防ぐ｜工程のフロー化とAI開発基盤

システム開発の属人化は、担当者の腕に頼る進め方そのものから生まれます。この記事では、開発工程をフロー化（工程ごとに入力・出力・確認を決めて流れにすること）すると、属人的な事故がなぜ減るのかを整理します。あわせて、AIを開発に取り入れたときに属人性がどう変わるのか、発注する側が確かめたい点も具体的にまとめます。

システム開発の「属人化」とは何か、どんな事故になるのか

属人化とは、仕事の進め方や判断の根拠が特定の人の頭の中にしかなく、その人がいないと続けられない状態を指します。システム開発では、次のような形で表に出ます。

• 担当者が退職・異動したあと、仕様の意図や過去の判断理由が分からなくなる
• 同じ依頼でも、担当する人によって品質や進め方が変わる
• 「この人が見たから大丈夫」という確認が、記録に残らないまま通っている
• 設計の前提が口頭でしか共有されておらず、実装時に食い違いが起きる

新規事業の開発では、この影響が特に大きくなりやすい面があります。仕様が固まりきらないまま走り出すことが多く、「なぜこうしたのか」という判断の経緯が、あとから事業の方向を見直すときの大切な材料になるからです。経緯が個人の記憶にしかないと、方向転換のたびに前提の確認からやり直すことになります。

また、属人化は「特定の人が優秀だから起きる」とは限りません。優秀な人ほど暗黙のうちに多くの判断を引き受け、結果として、その人の外に出ない知識が増えていきます。人を責める話ではなく、進め方の構造の話として捉えるほうが、対策を考えやすくなります。

属人的な事故が起きる3つの構造

事故の原因を分解すると、多くは次の3つに行き着きます。

知識が個人の中にとどまっている

要件の背景、設計の理由、過去に試して外した案といった知識が、文書や成果物ではなく担当者の記憶に残っている状態です。引き継ぎのときに残るのは「できあがったもの」だけで、「なぜそうなったか」が抜け落ちます。引き継ぎ後の改修で意図せず仕様を壊してしまう事故は、この構造から起きます。

工程の区切りが曖昧になっている

要件定義が終わったのか、設計に入ってよいのか、実装を始めてよいのか。この境目が曖昧だと、前の工程の抜け漏れを後ろの工程の個人が、その場の判断で埋めることになります。埋め方は人によって違うため、同じプロジェクトの中でも判断の基準がばらつきます。

確認が人の気づきに依存している

レビューやテストが「経験のある人が気づいたら指摘する」形になっていると、気づく人がいるかどうかで品質が変わります。何を確認したかの記録もないため、あとから「確認済みだったのか」を検証することもできません。

3つに共通するのは、人の能力が足りないのではなく、能力を頼りにしなければ成り立たない設計になっているという点です。フロー化は、この設計を変えるための考え方です。

開発工程をフロー化するとはどういうことか

フロー化とは、開発を「要件定義 → 設計 → DB設計 → 実装 → テスト → レビュー」のような工程に分け、それぞれについて次の3点を決めて流れとして運用することです。

入力と出力を決める

各工程が何を受け取り（入力）、何を渡すのか（出力）を明確にします。たとえば要件定義の出力が「機能一覧と画面の流れ」なら、設計はそれを入力として始まります。前の工程の成果物が次の工程の出発点になるため、口頭の補足に頼る余地が小さくなります。

完了の条件と確認の観点を決める

「どうなれば、この工程は終わりか」を先に決めておきます。確認の観点が事前に決まっていれば、誰が確認しても同じ項目を見ることになります。経験者の勘だけに任せていた部分のうち、言葉にできるものは基準として残せます。

判断と経緯を残す

各工程の成果物は、そのまま判断の記録になります。なぜこの構成にしたのか、どの案を見送ったのか。これが工程ごとに文書として残れば、担当者が変わっても経緯をたどれます。設計書の残し方についてはAI設計書の自動生成は可能？後から困らない残し方でも触れています。

フロー化と事故の対応関係

属人化で起きる事故	フロー化での考え方
担当者の退職で意図が不明になる	工程ごとの成果物に判断の経緯が残る
担当者により品質が変わる	完了条件と確認観点が共通になる
確認の有無が分からない	工程ごとの確認が記録として残る
前の工程の抜け漏れを個人が補う	入力と出力が決まり、抜けが次工程の入口で見える

なお、フロー化は工程を細かく区切って書類を増やすことが目的ではありません。「次の工程に何が渡るのか」が誰の目にも分かる状態をつくることが目的です。形だけ整えて作業が増えるなら、フロー化の狙いから外れています。

AIを開発に入れると、属人化はどう変わるのか

LLM単体で使うと、新しい属人化が生まれやすい

GPTやClaudeなどのLLM（大規模言語モデル）は、コードの生成や設計の相談に使えます。ただ、LLMに個別に指示を出す使い方では、結果が指示を書く人の腕に左右されます。指示の出し方に慣れた人の出力は良く、そうでない人の出力はばらつく。つまり、「AIの使い方に詳しい人」への属人化が新しく生まれます。

さらに、生成AIは一見もっともらしい誤りを含むことがあります。その見つけ方は生成AIのハルシネーションが開発に混ざるとき｜見つけ方と防ぎ方で整理していますが、見つける役割も個人の経験に頼る形だと、ここでも属人性が残ります。

AI開発基盤は「頭脳」に役割と手順を与える

そこで考え方として出てくるのが、AI開発基盤（AI開発フレームワーク）です。LLMを「頭脳」と捉え、その上に工程ごとの役割と手順を与える仕組みを重ねます。要件定義、設計、DB設計、実装、テスト、レビューといった工程に、それぞれ専門の役割を持たせたAIを置き、チームのように連携させる形です。違いの詳細はAI開発フレームワークとは｜LLMだけの開発との違いに書いています。

この形が属人化の抑制につながる理由は、先ほどのフロー化の3点とそのまま対応します。

• 入力と出力が決まる：各役割が受け取るもの、渡すものが定義されている
• 観点が共通になる：レビューやテストの役割は、毎回同じ基準で確認する
• 経緯が残る：工程ごとの成果物が、次の工程と後からの確認に使える

つまり、「誰が指示を書いたか」ではなく「どの工程の、どの役割が、何を根拠に出したか」で品質が決まる構造に近づきます。AI駆動開発全体の役割分担は、AI駆動開発とは｜AIと人の役割分担と発注側の要点も参考になります。

工程のAIが連携するときの考え方

複数のAIが連携する仕組みは、AIエージェントが開発チームになる仕組みと発注の要点で詳しく扱っています。ここで押さえたいのは、役割を分ける目的が「速さ」だけではないことです。役割ごとに見る観点を固定することで、1つの出力に何でも混ぜ込んでしまう状態を避け、どこで何が決まったかを追いやすくしています。

フロー化しても残る属人性と、人が担う部分

フロー化とAIの活用で、すべての属人性がなくなるわけではありません。むしろ、残すべき人の判断をはっきりさせることが、フロー化のもう一つの狙いです。

「何を作るか」は人が決める

新規事業では、どの課題を解くのか、どの機能を最初に入れるのか、何を後回しにするのかは事業の判断です。これはフローの中で自動的に決まるものではありません。発注する側の担当者が、判断の軸を持っていることが前提になります。この役割については発注側のプロダクトオーナーとは｜役割と判断のしかたで整理しています。

品質の最終判断も人が担う

AIによるテストやレビューは、確認の観点を揃えたり、見落としを減らしたりするのに役立ちます。一方で、事業として許容できる品質かどうかの最終判断は、人が行う領域です。何をAIに任せ、何を人が見るのかはAI開発でも品質には人の確認が必要な理由や、AIコードレビューで指摘される点と人が判断する点で具体的に扱っています。

経験や品質基準は、仕組みに組み込めるか

属人化の中には、「ベテランの経験」という価値のある部分も含まれます。これを個人にとどめず、設計やレビューの基準として組み込めるかどうかが、AI開発基盤の差になります。経験を基準としてフローに入れておけば、担当者が変わっても同じ観点で提案やチェックが行われ、案件を重ねるたびに基準を見直して改善していくことも可能になります。逆に、経験が仕組みの外にあるままだと、AIを入れても結果は担当者次第になります。

フロー化しすぎることの注意点

工程と確認を固定しすぎると、想定外の事態に柔軟に対応しにくくなる面もあります。新規事業では、作りながら前提が変わることが珍しくありません。そのため、フローは「変えてはならない手順」ではなく、「変えたときに経緯が残る土台」と考えるほうが実態に合います。仕様変更の扱いはシステム開発の仕様変更への対応｜追加要望の扱い方も参考にしてください。

発注する側が確かめたい点

属人化の事故を避けるには、開発する側の仕組みだけでなく、発注する側が事前に確かめておける点もあります。新規事業に取り組む会社が、依頼先を検討する際に見ておきたい観点を挙げます。

工程ごとの成果物が見えるか

要件定義、設計、テストなど、各工程でどのような成果物が出て、どのタイミングで確認できるのかを聞いてみます。成果物が具体的に挙がるなら、工程が仕組みとして動いている可能性が高いといえます。納品物の全体像はシステム開発の納品物一覧｜ソースコード以外に受け取る成果物が参考になります。

担当者が変わったとき、どうなるのか

担当者の交代や不在の場合に、進行や品質がどう保たれるのかを確認します。「担当者が慣れているので大丈夫」という説明だけでなく、記録や基準にもとづく引き継ぎの方法が語られるかが見どころです。乗り換えや引き継ぎの場面はシステム開発会社の乗り換え前に確認したい引き継ぎの要点にまとめています。

AIが作ったコードの扱いはどうなっているか

AIが生成したコードを、あとから別の人が保守できるのか。ここは属人化と直結します。引き継ぎと改修のしやすさについてはAI生成コードの保守は可能か｜引き継ぎと改修の確認点で確認点を整理しています。セキュリティの観点はAI生成コードのセキュリティ｜確認点と人の役割、権利面はAI生成コードの著作権｜事業で使う前の確認点が参考になります。

実物を触りながら確認できるか

言葉だけで要件を決めると、同じ言葉でも人によって受け取り方が違います。これも属人化の一種です。動く実物を見ながら「ここはこう」と指摘できる進め方であれば、解釈の差を早い段階で直せます。この点はシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで詳しく扱っています。

サーバーや権利の管理が会社の側にあるか

意外に見落とされるのが、サーバーやアカウントの名義が特定の担当者や依頼先に結びついているケースです。これも属人化の一形態で、関係が変わったときに動けなくなります。確認の観点はシステム開発のサーバー名義は誰にする？外注前の決め方にまとめています。

依頼前の確認全般は、AI受託開発に依頼する前に確かめたい6つのことも合わせて参照できます。

まとめ

システム開発の属人化は、担当者の能力不足ではなく、知識が個人にとどまる、工程の区切りが曖昧、確認が人の気づきに依存するという構造から生まれます。工程をフロー化し、入力と出力、完了条件、判断の経緯を決めておくことで、担当者が変わっても品質と経緯を保ちやすくなります。

AIを開発に取り入れる場合も、LLMを個別に使うだけでは「AIの使い方に詳しい人」への属人化が生まれます。役割と手順を与えたAI開発基盤の上で、複数の専門AIが工程ごとに連携する形にすることで、フロー化の考え方を実際の開発に反映できます。そのうえで、何を作るかの決定と最終的な品質判断は人が担う、という役割の線引きが大切です。発注する側は、工程ごとの成果物、担当者交代時の扱い、AI生成コードの保守性、実物での確認、名義の管理といった点を、依頼前に確かめておくことができます。

JustFitは、AIを活用した独自の開発基盤「LAF（LEGAREA AI Framework）」を使っています。GPTやClaudeなどのLLMを「頭脳」とし、要件定義・設計・DB設計・実装・テスト・レビューの役割を持つ複数の専門AIがチームとして開発を進め、人は「何を作るかを決めること」と「品質の最終判断」を担います。設計やレビューでは、LEGAREAの経験と品質基準にもとづいて提案・チェックを行い、案件を終えるたびに知見が加わって基盤自体が進化していきます。開発工程のフロー化によって属人的な事故を抑える考え方を、構想から約1ヶ月で動くプロトタイプを作る進め方に組み込んでいます。詳しくはJustFitのサービス紹介をご覧ください。