職能は溶ける。溶かさなきゃいけない。

最近わたしが感じていることです。巷ではもうすでに似たようなことは散々言われていることかもしれませんが、わたしなりになぜそう感じたのかを今回書いてみようと思います。

はじめに

はいさい！しまぶだよ。

最近「ザ・ゴール」を読みました。とある工場の業績改善を題材に、制約理論（TOC: Theory of Constraints）を解説した本です。物語形式で書かれていて、単純に読み物としても面白かったです。

わたしは今、AIを活用したソフトウェア開発のプロセス改善に取り組んでいます。ザ・ゴールを読みながらこのプロセス改善を進めていたのですが、読み進めるうちに、現場で感じている課題と制約理論の考え方が驚くほど当てはまることに気づきました。そこで、自分なりの解釈も交えながら、AI時代のソフトウェア開発の未来について考えてみたいと思います。

特に、「制約を解消すると、制約は別の場所に移動する」 という考え方は、AIによって開発のやり方、その景色が変わりつつある今の状況とすごくマッチしていると感じています。

「ザ・ゴール」ってなに

「ザ・ゴール」はエリヤフ・ゴールドラットという人が書いたビジネス小説で、制約理論（TOC: Theory of Constraints）を物語形式で解説した名著です。工場の業績改善がテーマなんですけど、言っていることはシンプルです。

システム全体のパフォーマンスは「ボトルネック（制約）」によって決まる。

ボトルネック以外の工程をいくら改善しても、全体のスループットは上がらない。むしろ仕掛品（在庫）が増えるだけだということを言っています。

そして改善のステップはこうです。

1. 制約を特定する
2. 制約を最大限活用する
3. 他のすべてを制約に従属させる
4. 制約を強化（解消）する
5. 制約が解消されたら最初に戻る

※ 制約 = ボトルネック です

大事なのは、制約を解消すると、制約は別の場所に移動する ということです。

ソフトウェア開発に当てはめてみる

ソフトウェア開発のフローをざっくり分けると、こうなるかと思います。

Spec / Design（仕様決め） → Develop（開発） → QC（品質保証） → Release（出荷）

もちろん、ソフトウェア開発は工場のラインほど単純じゃなくて、仕様を決めながら作ったり、QCで見つかった問題が仕様に戻ったりと、実際にはフィードバックループがあります。ただ、大きな流れとして捉えると当てはまる部分が多いと感じたので、ここではざっくり直列に並べて考えています。

従来のソフトウェア開発フロー

従来、この中で一番時間がかかる工程は「Develop（開発）」だった現場が多いのではないでしょうか。ここがボトルネックでした。

コードを書くのに時間がかかるから、仕様を決めるところやQCが早かったとしても開発工程の影響が全体のスループットに大きく影響していたはずです。

ところが今、生成AIの登場によって 「Develop（開発）」のスループットが上がっています。

すると何が起きるか。TOCが言っているとおり、ボトルネックが移動します。真ん中が速くなった結果、両端が詰まるようになります。

これに思い当たる節がある方は多いのではないでしょうか。開発工程のスループットが上がっても、リリース頻度が上がったか？と言われるとそうではないように感じるやつです。けっきょくのところ、ボトルネックに収束するのです。

部分最適をしても意味はない。開発工程のスループットが上がっても、仕様決めやQCのやり方を変えないままだと、結局全体のスループットは上がらないということです。

AIの力で両端を非ボトルネックにする

AIの力で開発工程のスループットが上がったのであれば、両端の工程もAIの力で非ボトルネックにしていけばいいのでは？と思うはずです。

わたしたちがそうでした。冒頭であげたAIを活用したソフトウェア開発のプロセス改善の取り組みは、まさにこの両端を非ボトルネックにすることを目指したものでした。
その中でもQCの部分です。そこをまず改善していこうと考えたわけです。

かんたんに言ってしまうと、テストケースの観点出しや、テストケースの自動生成をAIに実行してもらうことを目指しました。
人間がコンフルやスプレッドシートへ手書きでやっている部分ですね。

いざやってみると難しい

ところがどっこい、やってみるとこれがなかなか難しい。
おそらく、やりたいこととしては、「QC業務で時間のかかる作業の自動化」だったはずです。
テストケースをAIが書いてくれた！うぇーい！楽勝！みたいなイメージだったと思います。

そのようなイメージで実際にやりはじめてみると、以下の課題にぶち当たりました。

• コードを書かせるにしろ、テストケースを書かせるにしろ、何を元に書かせればいいのか
• AIに実行させると早いが、実行させる元となるものが揃っていない
  • 出力させたものが本当に正しいのか判断がつかない

つまり、AIに実行させるための「コンテキスト」を用意することが難しい ということです。

「なぜそれを作るのか、なにが正解であるか」が無いと、AIは望むものを作ってくれない。
なので、自動化の前に、AIに実行させるための「コンテキスト」を用意することに注力するチームが多かったように感じます。

自動化を試みたが、その前段階の「コンテキスト」を用意することの方が難しいと感じた、というのが実際のところでした。

“コンテキスト = Why / What” が無いと難しいということです。

Why / What が無いと成り立たない

つまりは、こういうことなんじゃないかと思います。

• 何を作るべきなのか
• なぜ作っているのか
• 何が（我々の思う）正解なのか
• お互いに行間を読み合っている
  • たぶん、こうなんだろうな で作っている
    • アプリエンジニアもQAエンジニアも、行間を読んで作っている
  • AIにそれは伝わらない

何を作って欲しいのか、ということがしっかり定義されていないと、AIは望むものを作ってくれないということです。
今まで人間が行間を読んでやっていたことを、AIにやらせるためには、行間を読まなくてもいいように、「なぜそれを作るのか」「なにが正解であるか」 をしっかり定義してあげる必要があります。

つまり、要求です。
それが揃っていれば、AIは実行することができる。

例えば、個人開発を想像してみてください。個人開発では、作りたいものが自分の頭の中にある。行間を読む相手もいない。だからAIに要求をそのまま伝えられるし、AIはものの見事にそれを形にしてくれる（もちろん100%ではないですよ）。 チーム開発でうまくいかないのは、この「頭の中にあるもの」がチーム内で共有されていない、あるいは言語化されていないからです。要求が明確に定義されているなら、AIは上手に作ってくれる、そんな感覚はすでにあるのではないでしょうか。

QC業務改善の経験を通じて気づいたのは、これはQCだけの話じゃないということです。Spec/DesignもDevelopも、けっきょく同じ構造をしています。「Why / What」が揃っていなければ、どの工程をAIで自動化しようとしても同じ壁にぶつかるはずです。

これからのソフトウェア開発

そう考えると、これからのソフトウェア開発の姿はこうなるんじゃないかと思います。

開発のフローは「要求」と「実行」の2つに分かれていきます。

要求（Why / What）

何を作るのか、なぜ作るのか。Spec、デザイン（UI/UX）、QC（テスト・非機能要件）を含む。
ここは 人 が主体。

実行（How）

どう作るか。Developを含む。
ここは AI が主体。

エンジニアはこれまで「実行」側、つまりコードを書くことに多くの時間を使っていました。でもこれからは「要求」側に介入していくことが求められるようになると思っています。

「何を作るのか」「なぜ作るのか」を正しく定義できるかどうかが、開発全体のスループットを左右するようになるからです。

要求はみんなで考える

エンジニアは要求側に介入していくことが求められるようになると書きましたが、これは決してエンジニアだけではなく

• POはPOの仕事をやればいい
• デザイナーはデザイナーの仕事をやればいい
• QCはQCの仕事をやればいい

の考え方ではだめで、みんなが繋がるように考えていく必要があります。

「仕様だけを考える」「与えられたものを作る」「テストケースを考えて実施する」だけの人間はAIに代替されるはずです。

なので、職能は溶ける。溶かさなきゃいけない。 と思っています。

実際、この改善活動を通してちょっとした変化がありました。QAエンジニアの方がアプリエンジニアに質問をして、gitコマンドを覚えて、ターミナルを触るようになって、Claude Codeの環境を自分で整えていたんです。Windows環境で苦戦していたりもして。
こう言ってしまうと語弊があるかもしれませんが、今まで「テストだけする人」の職能が溶け始めていました。AIを活用しようとしたら自然とそうなっていたのです。職能が溶けるって、たぶんこういうことなんだと思います。

要求はガードレールに

「なぜ」「何を」の要求はガードレールとして機能するようになる。AIはそのガードレールの中で実行される。人はAIが実行した結果を確認するだけ。

テストやCI/CD、コードレビューの自動化などもガードレールにあたるでしょう。要求側でガードレールを用意し、実行側ではAIが作ったものをそのガードレールで品質担保する。人間はその確認をするだけ。こういう世界観になっていくんじゃないかと考えています。

ガードレールが整えば、実行はほぼAIに任せられるようになる。そうなったとき、エンジニアの立ち位置はどうなるでしょうか。

AIが実行を担う時代に「コードを書ける」というスキルは、自動車があるのに「わたし、馬を乗りこなせます！」と言うことに近くなってしまって、必要ないわけではないけれど、全員が持つべきスキルではなくなる気がします。 一方で、AIの実行基盤そのものを作る人、適切なガードレールを設計できる人、パフォーマンスチューニングに特化した人、セキュリティを担保する人、AIでは判断できないエッジケースに対応する人。こういったエンジニアの需要は残り続けるはずです。希少価値も上がるでしょう。ただ、その数は今より少なくなると思います。（そこに滑り込む自信はないです）

もう少し先の未来

「要求」と「実行」のモデルがさらにシンプルになっていくと思います。

要求を人が考えて、AIに実行させる。

開発プロセスの中にあった細かい工程、職能の区切りはどんどん曖昧になって、最終的には「要求 → 実行」というシンプルな構造に収束していく。

なので、何度でも言います、職能は溶ける。溶かさなきゃいけない。

おわりに

冒頭で「職能は溶ける」と書きました。ザ・ゴールを読んで、AIを活用したプロセス改善に取り組んでみて、その感覚はますます強くなっています。

「仕様を決める人」「コードを書く人」「テストする人」という区切りは、必要ないと感じています。これからは「何を作るべきか」をみんなで考えて、AIに実行させる。そういう時代になっていくんじゃないかと思います。

でも、「何を作るべきか」をみんなで考えるって以前からきっとそうで、AIが入ってきたことによって、より顕著になっただけなんじゃないかとも思います。

職能を溶かして、ひとつになって、みんなで生きのこってこ。

おわりのおわりに

この話は、オフラインでチームメンバーと集まったときに、わたしの考えをホワイトボードに書き殴ったのがもとになっています。ホワイトボードに書き殴るのは捗りますね！