職人からソフトウェアファクトリーへ。変わったのは作り方、まだ変わっていないのは頼み方

2026.11.09#生成AI #受託開発 #開発体制 #要件定義

「長くお願いしている外部のエンジニアは、実装が速くて対応も丁寧。でも、業務知識がいつまでたっても身につかない」。AI に実装を任せられるようになったいま、こうした理由で外部エンジニアとの契約を見直したという話を、発注する側から聞く機会が増えました。

こうした話は、エンジニア個人の資質の問題として語られがちです。しかし私たちは、ソフトウェアの作り方が「職人」から「ファクトリー（工場）」へ移ったのに、発注の仕方が昔のまま残っていることの表れだと考えています。この記事では、職人の時代とファクトリーの時代で何が変わり、何が変わらないのかをたどり、ファクトリーの時代に合った発注の仕方を紹介します。

※ この記事では、ソフトウェア開発で「ドメイン知識」と呼ばれることの多いもののうち、発注者の業務に関する知識を「業務知識」と書きます。エンジニアにとって「ドメイン」は、セキュリティやアプリケーションの負荷といった技術の領域を指すこともあり、そうした領域にはむしろ詳しいエンジニアが多くいます。言葉の指す範囲が人によって変わりやすいので、この記事では業務に絞った言い方を使います。

『ソフトウェア職人気質』は、ソフトウェアは工場では作れないと考えた

『ソフトウェア職人気質』は、Pete McBreen が2001年に書いた本で、邦訳は2002年にピアソン・エデュケーションから出ています。私はずいぶん前にこの本を読み、技術は職人的なアプローチでなければ継承できない、と感じました。

McBreen がこの本で疑問を投げかけたのは、当時主流だった「ソフトウェアエンジニアリング」の考え方です。ソフトウェアエンジニアリングは製造業からプロセスや用語を借り、要件を固める人、設計する人、実装する人と工程を分け、大勢の開発者を工場のラインのように動かそうとしました。McBreen は、こうした分業がソフトウェア開発に本当に合うのかを問い、代わりに職人という見方を示しました。

本が描く職人は、少人数の腕のいいチームで、顧客と近くで話しながら、作るものの全体に責任を持つ存在です。作った人が業務の背景まで分かっていることを重く見ていて、完成したシステムを別の保守チームに引き渡すと、元のチームが持っていた業務の理解が失われてしまう、とも指摘しています。

ところが、受託開発の発注の現場に根づいたのは、職人の考え方よりも分業の発想でした。発注者が業務を仕様に落とし、作る範囲を切り出して、開発者に渡す。開発者は実装の腕で応える。実装を人の手で書くしかなかった時代は、腕そのものに大きな価値があったので、この「腕に頼む」発注でも仕事が成り立っていました。

ファクトリーの時代、実装はラインで量産される

McBreen が工場のようには作れないと考えたソフトウェアのうち、実装の部分は、AI の登場で本当に工場のラインで量産できるようになりました。私たちの開発現場でも、要件と受け入れ条件を定めたタスクを渡すと、AI が計画・実装・テスト・レビューを繰り返し、プルリクエストを作るところまで進めています（対話型コード生成からループエンジニアリングへの移行）。ラインから大量に出てくるコードを人がどう検査するかは、製造業の品質検査になぞらえたコードレビューの記事で書きました。

ただし、工場で量産できるのは「どう作るか」です。「何を作るか」を決め、ラインに流す仕様を決め、出てきたものを検査する仕事は人に残ります。Anthropic が2026年6月に公開した、約40万件の Claude Code のセッションを分析した調査でも、何をするか・何をもって完了とするかといった計画の判断は約70%を人が、どのファイルをどう書き換えるかといった実行の判断は約80%を AI が担っていました。同じ調査は、AI をうまく使えるかどうかを決めるのはコーディングの腕よりも、解こうとしている問題の領域をどれだけ理解しているかだ、と結論づけています（Agentic coding and persistent returns to expertise）。

ファクトリーに残るのは、職人が大切にしてきたこと

実装がファクトリーに移っても、顧客と近くで話し、業務を理解し、作るものの全体に責任を持つという、職人が大切にしてきた仕事は置き換えられずに残ります。職人からファクトリーへの移り変わりで変わるのは、次の3点です。

価値の置き場所：実装の腕から、何を作るかを決めるための業務知識へ
エンジニアの役割：切り出された実装を担う1つの工程から、業務を理解し、ラインに流す仕様を決めて検査する仕事へ
発注の単位：切り出したタスクから、業務の課題と「何ができたら完了か」へ

実装の速さで差がつかなくなった分、エンジニアの仕事の中心は、業務を理解して課題を整理するほうへ移ります。McBreen が職人に求めた姿に、ファクトリーの時代になってようやく仕事の形が追いついてきた、とも言えます。

「腕」に頼む発注が「業務知識が身につかない」を生む

ところが、3つ目の「発注の単位」だけは、なかなか変わりません。「この画面を作ってください」「この API を追加してください」という依頼は、作る範囲がすでに切り出された状態で届きます。その範囲を速く正確に実装すれば評価され、業務の背景を知らなくても仕事が終わります。この発注の形が続く限り、エンジニアが業務を学ぶ理由は仕事の中に生まれません。

エンジニアは、セキュリティやアプリケーションの負荷のような技術の領域では、深い知識を持っていることが少なくありません。それは、そうした知識が日々の仕事の中で必要になり、触れ続けているからです。同じエンジニアが業務知識に弱いのは、学ぶ力がないからではなく、業務に触れる機会が仕事の中に用意されていないからです。何年一緒に仕事をしても業務知識が身につかないのは、エンジニアだけの問題ではなく、腕に頼む発注の形が生んでいる面が大きいのです。

実装を人の手で書いていた時代は、それでも仕事が成り立ちました。実装の腕そのものが、頼む理由になっていたからです。ファクトリーの時代に腕に頼む発注を続けると、エンジニアに頼める仕事は、ラインで代わりがきく部分ばかりになっていきます。「業務知識が身につかないから契約を見直す」という判断は、人の問題というより、発注の形が時代に合わなくなったことの表れだと私たちは考えています。

作る人と使う人が、ようやく直接話せるようになる

業務知識が身につきにくい理由は、もう1つあります。ソフトウェアを実際に「作る人」と、実際に「使う人」が、直接話す機会がほとんどなかったことです。

発注する人と使う人は、たいてい同じではありません。システムを発注するのは経営者や情報システムの担当者で、毎日使うのは現場の担当者です。作る人と使う人のあいだには、発注の担当者や営業、プロジェクトマネージャー、ときには元請けと下請けが入り、現場の困りごとは仕様書や伝言を何度も経て作る人に届きます。届くころには、困りごとの具体的な言葉は削られ、機能の一覧に変わっています。作る人は実装に、使う人は日々の業務に手を取られていて、どちらにも直接話す余裕がなかったことも、この形が続いた理由です。

AI は、この両側を同時に変えつつあります。作る側では実装がファクトリーに移り、作る人の時間は、手を動かすことから何を作るかを考えることへ移っています。使う側でも、入力や転記、集計、定型の問い合わせ対応といった業務の一部が AI に置き換わりはじめています。作る人と使う人の両方で、手を取られていた作業が減っていく。だからこそ、これまで難しかった両者の直接の対話が、ようやく現実的になるのではないかと私たちは考えています。

対話の質も変わります。AI で試作をすぐに作れるようになったので、使う人に動くものを見せながら話し、その場で直して確かめることができます（「作ってから考える」が可能になった時代の開発）。仕様書の言葉ではなく、実際に触った感想で話が進むので、伝言の途中で失われていた具体的な困りごとが、作る人に直接届きます。

ファクトリーの時代に、ソフトウェアの価値を決めるのは実装の速さではなく、使う人の業務にどれだけ合っているかです。作る人と使う人のあいだの距離を縮めることが、ソフトウェアの価値を上げるいちばん確かな方法だと私たちは考えています。McBreen が職人に求めた顧客との近さは、AI によって、ようやく多くの現場で手の届くものになりつつあります。

ファクトリーの時代は、業務の理解を発注者と開発者で一緒につくる

業務の理解は、仕様書に書いて渡すだけでは開発者に伝わりません。発注者と開発者、そしてできれば実際に使う人が同じ業務を見て、使う言葉をそろえていくなかで少しずつ深まります。私たちは受託開発で、次のように進めています。

依頼を、画面や機能の一覧ではなく、業務の流れと困りごとから始める
発注者と開発者、できれば実際に使う人も同じ場に集まり、業務フローを書き出す
「何ができたら完了か」を、受け入れ条件として発注者と開発者で書く
契約の目的を、工数の消化ではなく事業で使えるシステムの完成に置く

業務管理ツールの相談で、「顧客への連絡履歴を残す入力フォームが欲しい」という要望を受けた案件がありました。ホワイトボードに業務フローを時系列で書き出していくと、営業担当が紙のメモで事務に指示を出していることが分かり、必要なのは入力フォームより連絡通知の自動化だと分かりました（要件定義前の「対面ヒアリング」を大切にする理由）。機能の一覧から始めていたら、エンジニアはこの紙のメモを知らないまま入力フォームを作っていたはずです。

受け入れ条件を一緒に書く作業は、ファクトリーの時代にはそのままラインに流す仕様、つまり AI への指示の中身になります。AI に実装を任せるとき、AI が従うのは受け入れ条件と終了の基準だからです。先の調査でも「何をもって完了とするか」は人が決める計画の判断に分類されていました。条件を書く過程で、発注者は業務の具体的な言葉を開発者に渡します。ラーメン屋の店主が語るのが「知識」ではなく、スープの取り方や常連客に合わせた味の濃さであるように、業務を分かっている人の言葉はいつも具体的です。開発者はそれを自分の言葉で書き直しながら理解していきます。

契約の形も業務の理解に関わります。準委任契約についての記事で書いたとおり、私たちは成果物の完成に責任を負う形を選んでいます。完成に責任を持つ以上、開発者は事業の目的を知らなければ、何を作り何を削るかを決められません。業務を理解することが、契約の上でも開発者の仕事になります。