生成AIがコードを書き、テストを作り、障害の原因まで指し示す時代に、開発者という職業はどこへ向かうのか。手を動かす前に、まずは原理原則から整理したい。本記事では、株式会社X-Tech5取締役CTOの馬場俊彰氏の講演をもとに、AI時代の開発者像を捉え直す。人間・AI・プログラムの特性差、開発者が負う3種類の責任、そして機能的便益・情緒的便益・自己表現的便益からなる提供価値の構造を紐解いていく。明日から自分の仕事を捉え直すための判断軸が見えてくるはずだ。

アーカイブ動画

原理原則から考える、開発者の責任と価値の再定義

AI時代に開発者の役割はどう変わるのか。答えのない問いに対し、人間・AI・プログラムの特性差、開発者が負う責任、そして提供価値の構造という3つの理屈から整理していく。取締役CTOとして開発と運用の現場に長く関わってきた馬場氏が、「原理原則が分かれば怖くない」という信念のもと、開発者が向き合うべき視点を示す。

株式会社X-Tech5
取締役CTO
馬場 俊彰（ばば としあき）氏

複数の立場から、答えのない問いに向き合う

馬場氏は自己紹介の中で、自身が複数の顔を持つ人間であることをまず提示した。エンジニアとしての顔、エンジニアのマネージャーとしての顔、CTOとしての顔、取締役としての顔、そしてICT業界の一員としての顔。株式会社X-Tech5の取締役CTO、株式会社iCAREの技術顧問、学生向けのインフラ主体トラブルシューティングコンテスト「ICTトラブルシューティングコンテスト」の会長など、肩書きも多岐にわたる。「なんかこう矛盾しているような気がしても、実は使っている顔が違うんだなというケースもある」と馬場氏。今日の話は答えがない、人によって答えが異なって当然、という前提のもと、講演は始まった。なお、本講演における「AI」は主にLLMおよびLLMを使ったAIエージェントを指す。

職業として成立し続けるための4つの要件

そもそも「開発者はAIがコードを書く時代に職業として成立し続けるのか」を考える前提として、馬場氏は職業の成立要件を4つ挙げる。

• 社会的に価値があるか
• 成立を許されるか（暗殺者のように許されない職業もある）
• どのくらい希少か
• どのくらい専門的か

これらの条件によって、その職業が成立できる市場の大きさや、そこで働ける人の数も変わってくる。友人の親御さんに刀の研ぎ師がいるが、間口は昔よりずっと狭い。それでも専門性と希少性が非常に高いため、市場規模は小さくても職業として成立している。開発者がこれからどうなるかは分からないが、「原理原則がわかれば怖くない」という信念のもと、馬場氏はこの4要件を土台にして考えていくと語った。

人間・AI・プログラムの特性を並べて見えるもの

議論の基礎として、馬場氏は人間・AI・プログラムを軸に、それぞれの特性を横並びで整理する。

• 確実な繰り返し：人間は不可能、AIも確率的動作のため不可能、プログラムは仕組み上可能
• 複製・スケールアウト：人間は難しい、AIは可能、プログラムも可能
• 疲労：人間は疲れる、AIとプログラムは疲れない
• 柔軟性（指示の解釈幅）：人間は大きい、AIは中程度、プログラムは基本的にない
• 狭い文脈理解：人間・AIは可能、プログラムは不可能
• 広い文脈理解（暗黙知、直接与えられていない関連情報の取り込み）：人間のみ可能
• 責任を負うこと：人間は可能、AIとプログラムは基本的に不可能

AIが騒がれる理由は、プログラムが得意な領域と人間が得意な領域を「ちょうどいい感じにつなぐ」位置にあるからだ、と馬場氏は指摘する。そのグラデーションこそが、今AIが注目される理由の一つだという。そして最終行の「責任を負うこと」は、今日のテーマにおいて特に重要な観点だ。馬場氏は、法人が責任を負うケースであっても、最終的にはその中にいる人間が責任を引き受けることになる、と整理する。

遂行・結果・説明という3つの責任

責任は大きく3つに分けられる、と馬場氏は整理する。

• 遂行責任：決まっていることをちゃんとやる
• 結果責任：望む状態に持っていく
• 説明責任：なぜそうなったかを解説できる

組織のメンバーレベルでは遂行責任の比重が大きく、エグゼクティブや上位職層になるほど結果責任と説明責任の比重が増していく。これはグラデーションになっており、職位が上がれば全体の責任量そのものも縦に大きくなる。

馬場氏は、責任を「負う」ことを、求められる結果を実現するために必要な活動を適切に果たすことだと捉える。その水準を決めるのは、作り手だけではなく、利用者や関係者、社会である。交通機関の事故を例に挙げ、決められた点検を怠った場合と、必要な点検を尽くしたうえで事故が起きた場合とでは、社会からの受け止められ方も異なると説明した。AIやプログラムを活用する場合でも、この構造自体は変わらないと馬場氏は捉える。

そして開発者は社会全体から見れば高度専門職である。どんなにメンバーレベルであっても、遂行責任だけで済むわけではなく、結果責任と説明責任も多少なりとも発生する。開発者の文脈に落とし込むと、決まったことをその通り実装する、合理的な手段を講じてセキュリティチェックやアップデートを行う、システムを説明可能な状態に保つ、といった行為につながる。

書けないけど読める、はまやかしである

責任の話から少し離れ、馬場氏は「リテラシー」という概念に触れた。リテラシーとは読み書き能力である。文字、自然言語、プログラミング言語、システム、給与明細、財務諸表。「書けないけど読めるってまやかしですよね」と馬場氏。「読み書きはセットであり、書けないけれど読めるという状態は、本当の意味でリテラシーがあるとは言いづらい」と捉える。この視点は後段のプログラミング再定義の議論への伏線となる。

開発者が提供している価値をAakerで整理する

3つ目の理屈として、馬場氏は開発者が提供している価値の構造を、マーケティング理論のAaker（アーカー）とSREで扱う信頼性・可用性などの観点をベースに再構築して示した。価値は大きく3つに分類できる。

• 機能的便益：有用性と保証
• 情緒的便益：興奮、快楽、快適、満足感、安心感
• 自己表現的便益：ブランドロイヤリティのような、そのものを持っていること自体が価値になる要素

機能的便益の中でも、有用性は「効率を上げる」「不可能を可能にする」「大量データから何かを取り出す」など、結果的に評価しやすい。星取表で比較できるようなものだ。もう一方の保証は、いわゆる非機能要件に近い。信頼性、可用性、キャパシティ、パフォーマンス、セキュリティ、持続性など。障害復旧時間、発生確率、可用性の数字といった指標で曲がりなりにも数値化されている。

一方、情緒的便益はシステムを作るだけでは届きにくい遠い場所にある。自己表現的便益はさらにその先だ。

ここで馬場氏が注目するのは「客観的な評価のしやすさ」である。客観的に評価しやすいものはコンピューターが扱いやすい。プログラムで済むならプログラムが最も得意で、次にAIが得意だ。つまり、客観的に評価しやすい領域ほど、AIに任せる余地が大きくなる。開発者がどのジャンルで戦うかを考えるうえで、この整理が一つの判断軸になる。

なお、買い手の側から見れば、機能を100%満たしていない製品を選ぶかどうかは人によって大きく分かれる。多少の有用性を妥協して安心感やスピードを取る人もいれば、有用性をノックアウト要件にする人もいる。良し悪しではなく、そういう人がいることを前提に社会は成り立っている。

客観指標が得意なAI時代に、開発者はどこで戦うのか

ここまでを踏まえ、馬場氏は現状の見立てを共有した。

情報システムが存続する限り、リテラシーのある誰かは必ず必要になる。映画『ターミネーター』のスカイネットのように、情報システムそのものが社会に大きな害を及ぼす事態にでもならない限り、開発者という職業は一定程度残るだろう。その意味で悲観はしていない。

ただし、有用性を実現する仕事、つまり客観的に評価しやすい領域を最適化する仕事へのニーズは下がる可能性が非常に高い。次いで保証を実現する仕事も、AIに任せる余地が広がるだろう。

もっとも、有用性を実現すること自体の価値低下は必ずしもAIだけが原因ではない。競合の増加や業界の成熟によって、20年前と今では同じ機能を実装するコストは全く違う。AIがあろうがなかろうが、この領域は変わり続けている。

同じやり方でずっと食べていくのは、これまで通り厳しい。ICT業界はむしろ自ら率先して変化してきた業界だ、と馬場氏は語る。そのうえで馬場氏は、AIをうまく使うことが、こうした変化に適応していく一つの手段になると見る。

「AIと仕事するのは、他の人と仕事するのにすごく似てる」と馬場氏。仕事をお願いして、結果を受け取り、評価して、全体を次に進める。これは管理職の仕事そのものだ。つまりAI時代とは、全員の職位が1つ上がったつもりで働く時代である。

レイオフするのはAIではなく人である

もう一つ、馬場氏が念を押したのは、雇用と社会の関係だ。「レイオフするのはAIじゃなくて人である」。

馬場氏は、AIそのものが雇用を継続するかどうかを決めるわけではなく、その判断を下すのはあくまで人間だと指摘する。責任を負うのも、ルールや社会のあり方を決めるのも人間である以上、「AIだから仕方がない」と外部要因のように扱うべきではない、という考えだ。

AIの活用を理由に新卒採用をやめたり、大規模な人員削減を行ったりする企業があるとして、その判断をどう評価するかも社会や個人に委ねられている。違和感を持つのであれば、その企業を選ばない、周囲に意見を伝えるといった行動も、市民としてAIと向き合う一つの姿勢だと馬場氏は語った。

馬場氏は、企業は収益を追求する組織であると同時に、社会の公器でもあると捉える。「道徳なき経済は犯罪であり、経済なき道徳は寝言である」。馬場氏の著書『バックエンドエンジニアのためのインフラ・クラウド大全』の表紙モチーフの由来である二宮尊徳（金次郎）の言葉として知られる一節を引きながら、この視点をあるタイミングで思い出してほしいと語った。

ちょうどいい品質を、本当に自分で選べるか

締めくくりに馬場氏は、いくつかの話題提供を残した。

ひとつは「ちょうどいい」の難しさである。「そこまでやらなくていいんだよ」「こんな品質は出せません」といったやり取りが現場で発生しがちだが、そもそも自分で「ちょうどいい」を判断できているだろうか。AIにコーディングやレビューを任せた瞬間、1行1文字レベル、爪の先までの品質は、これまでと同じにはできない。馬場氏は、自身も同様の立場があり顔があると前置きしつつ、細部まで直接責任を負わない立場の人ほど、「AIで置き換えられる」と捉えやすいのではないかと指摘する。一方、実際に1行1文字レベルの品質まで責任を負ってきた開発者とは、見えている「置き換え可能性」が異なる。そこに認識のずれが生まれるという。

もう一つはプログラミングの再定義だ。読むだけをやっていれば、いずれ読む能力を失う。書けないが読めるはまやかしだ、という原理原則がここでも効いてくる。とはいえ、「AIで置き換えられる」と捉えている人の多くはもともとプログラムを読み書きできず、つまりプログラムを読み書きできない人がAIへの転換をやっているから課題感がない、という側面もあるかもしれない。馬場氏は、書く力を手放すことで読む力まで失ってしまえば、業界全体の技術力が低下する可能性もあると指摘する。一方で、こうした変化を乗り越え、新たな能力を獲得していく道もある。能力を新たに獲得するか、諦めるかはそれぞれの判断だ。

そして3つ目、書く能力がなくなっても、最低限の有用性と、パフォーマンス、セキュリティ、スケーラビリティ、キャパシティ、持続性といった保証は本当に実現できるのか。できるとしたら、できないとしたら、どうやっていくといいのか。馬場氏はここを聴衆と一緒に考えたい問いとして残した。

一緒に楽しく乗り越えていく

馬場氏の講演から見えてくるのは、「AIが開発者の仕事を奪うか」という二択ではなく、開発者が担う責任や提供価値の重心そのものが変わっていく可能性だ。有用性を実現するだけでなく、どの水準まで品質を保証するのか。その先で、利用者の安心や満足といった情緒的な価値にどう向き合うのか。

馬場氏の言葉を借りれば、AI時代は「全員の職位が1つ上がったつもり」で仕事をする時代でもある。AIに任せる部分が増えたとしても、何を任せ、どこまでの品質を求め、その結果にどう責任を持つのか。最後にその水準を選び取る役割は、人間に残り続ける。続くQ&Aセッションでは、この講演で提示された理屈が、評価制度・現場のレビュー・スキルアップといった具体的な現実にどう接続していくのかが問われていく。

Q&A セッション

Q. AIが学習によって自己変化・成長していく中で、かっちりしたプログラムとは異なるAIに対して、結果責任や学習成果をどこまで保証できるのか。どう整理していけばよいか。

馬場氏: 今みんな答えがなくて、困りながら何とかしようとしている領域だと思っています。逆に言うと、金脈かもしれないですね。人に対してアプローチしていたのと同じような保証のプログラム、制度や働きかけは、少なくとも最初の方はある程度有効に機能するのではないかと考えています。そう思っている人が多いので、いわゆるハーネスエンジニアリング（AIの出力を外側から検証・制御する仕組みを設計するアプローチ）だとか、ハーネスをもっと大規模にしてプロセスレベルでフィードバックループを回していこう、といったアプローチが取られている。Martin Fowler氏のサイトでも「Feedback Flywheel」（継続的にフィードバックを回して精度を上げていく考え方）という考え方が紹介されています。作り上げる側だけで品質を保証するのは難しいから、外側から統制する方向に振っている、というのが今の状況で、ここが従来の感覚とのギャップを生みがちなところかなと思っています。

Q. エンジニアの成果はどのような基準で評価しているか。

馬場氏: 大っぴらに言うとあれなんですが、基本的にはお客様の満足度、お客様が満足していること、期待を果たしていることを基準にしています。定量化はすごくしづらいと認識したうえで、そのしづらさを前提にやっています。指標化できるものはハックされるので、ある固定の指標だけでバッチリOKだぜ、と客観指標だけで済ませることは構造的にありえないんじゃないかと思っています。バランスを取りやすい指標群はもちろんありますが、環境と前提条件が変わってしまうので、この指標群だけを満たせばOK、という世の中の真理みたいなものは登場しないと思っています。

Q. マネジメントができる中間管理職が日本企業にいないと言われる中、この変革はどの立場の人なら起こせるものか。

馬場氏: ちょっと危ないことを言ったら忘れてほしいんですが、経営層といっても何パターンかありますよね。切り開いてきた人たちと、切り開かれたものをうまく管理して上がってきた人たちでは、発想も何も全然違う。漫画でもよくありますが、戦国時代なら有能なボスだった、平時なら有能だった、みたいなことはあり得るので、今の基準で変革が必要なのであれば、変革してきた経験のある人じゃないと難しいケースはあると思います。経営者・経営層だからできる、できないという単純な話にはならないかなと思います。

Q. 開発者が職業として成立するには、平均ではなく尖った付加価値を社会に与え続けられるかどうか次第だと思うが、意見を伺いたい。

馬場氏: そのために、付加価値を作って販売することで、私たちはお金をいただいているわけですから、付加価値を作ることは、市場の中で仕事を成立させるうえで不可欠だと思います。ただ、その付加価値が何か、というコンセンサスが今ちょっと崩れているところで、組み直しのタイミングにあるんだろうなと思っています。

Q. AIがコードを書いた時に、コードレビューの必要性はどう変わるか。

馬場氏: これは「やり方がどう変わるか」という話だと思っていて、正直わからないですね。爪の先までの品質が要るシーンか、いらないシーンかにも大きく依存します。コードレビューそのものというよりは、達成したい品質水準をどう作り上げるか、外に出す時にどう担保するかというアプローチの選択肢が増えた、というのが現状だと思います。

Q. 開発者、QAエンジニアそれぞれに求められる役割と技術的能力は何か。

馬場氏: 難しいですね。答えがある話じゃないので、どう思っているかというお話ですが、どんな専門職でも基礎知識プラス原理原則が分かれば怖くないと思っています。その領域の基礎、背景、仕組み、そこで果たさなければいけない価値は何なのか、それをちゃんと把握してやることを変えるのは絶対に必要です。開発者とQAエンジニアが今分かれているのは、本当は分かれる必要がないという話もあります。SREもそうですが、全部同じ人がやればいい、と言えばそうだし、それも難しいから専門化する。くっついたり離れたりを繰り返しているのがIT業界です。役割と言ってしまうと分からなくなりますが、果たさなければいけないことがそれぞれにあって、それを組織の中でどの水準まで発達させるかは決めないといけないと思っています。

Q. 尖った付加価値が必須だとすると、平均で日々の仕事をしていければいい、というスタンスの人は生きづらくなるということか。

馬場氏: それはそうかもしれないです。ただ、少なくとも現状のICT業界はそんなに小さくないので、いろんな人のいろんな普通が混ざり合って成立している。ロックスターのような人はずっといますが、そういう人に追いつき追い越さないと生きていけないかというと、職業としてはそれだけでもない。一生懸命やるべきことをやる、というボリュームゾーンの人たちがいるから業界として成立している面もあります。ただ、平均そのものが移り変わるので、そこはちょっと難しくなっていくというのはあり得る。市場規模が小さくなった業界には尖った人しか残らない、というパターンもあり得ますが、それがどのくらいの速さで変わるかは何とも言えないですね。

Q. 爪の先までの品質が必要かの判断が、ビジネスサイドとエンジニアで食い違った場合、エンジニアはどのような視点で語ればよいか。多くの場合、ビジネスサイドは爪の先までAIが作ってくれると思っているように見える。

馬場氏: これはビジネスでもエンジニアでもなく、お客さんが決めるものだと思っているので、やってみて評価すればいい、と思っています。もちろん法規制などがあればそれに則る必要はありますが、そもそもビジネスとエンジニアで話し合ったところで、本当に基準を持っているのはこっちじゃなくて選ぶ側の人。だから選ぶ側の人に使ってもらって、どうかを評価するのがいい。手前の段階で仮説と評価基準を持って会話しておくのは非常に有効です。ビジネスサイドは「爪の先まで作ってくれるから、これくらいの期間でいいはず」、エンジニア側はまた違う仮説を持っている。「今食い違っていますね、じゃあやってみましょう」で試して、うまくいかなかったらいかなかったで、そのまま終わりにせず次のフィードバックに回せば、品質が過剰だったか過小だったかも分かります。話しても進まないので、やった方がいい。全部で一気にやるか、カナリアで小さくやるかはまた別の話ですけどね。

Q. AIを活用する場合の品質保証について、必要なコンピテンシーを伺いたい。

馬場氏: 私は品質保証の専門家ではないのですが、この辺の話で強く思うのは、品質の作り込みに対するイメージ合わせをいろんな人と共有しないといけない、ということです。0から積み上げて作るからそれができる、という世界観もあれば、いろんな観点で適切な評価をたくさんするからそれができる、という世界観もある。もちろんどちらか一方だけではない。だから専門家として必要なコンピテンシーは、いろんな手法・方針・方法論の基礎知識を持ち、それを適切に組み合わせ、ちゃんとディスカッションして形にしていく力です。あるパターンをなぞる仕事の仕方が難しくなっている、特に今は過渡期なので、その難しさを強く感じますね。

Q. AIが有用性を実現できるようになったとき、開発者の仕事はAIに指示をして責任を負うことだけになるのか。

馬場氏: いいですね。私はそうは思っていません。開発者の仕事はもともと有用性だけでなく、保証の方、つまりパフォーマンス、セキュリティ、スケーラビリティ、信頼性、可用性、持続性にも責任を負っているはずです。ここをうまくできる人が、いわゆる腕がいい人だと思っています。誰かプロフェッショナルが担わないと、事故がめちゃくちゃ起きて「情報システムなんかもういいや」ということになりかねない。まず保証の要素は大きくある。そこから転じて、プラスアルファで情緒的なところにもちゃんと足を出していく、というのが必要になると考えています。

Q. コードが書ける・読めるだけではダメだと感じるが、スキルアップする上でどのようなことを勉強すればよいか。

馬場氏: 何度も言っちゃってごめんねという意味で最初にも触れましたが、基本的に原理原則が分かれば怖くないと思っています。パターン学習や「やり方」のところではなく、原理原則をちゃんと押さえましょう、基礎知識を大事にしてほしい、ということです。機能的便益の有用性だけでなく、保証の方にも目を向けてほしい。宣伝になってしまいますが、そういう思いがあって『バックエンドエンジニアのためのインフラ・クラウド大全』を書きました。原理原則と基礎知識、大事な価値観を押さえていくのはお勧めしていて、それはやり方がどう変わっていっても引き続き使えると思っています。

Q. 保証の要素はAIには実現不可能というお考えか。

馬場氏: できるかできないかで言うと、一定できると思います。ただ、そのバランスをどうするか、ちょうどいい水準をどうするかは、誰かが決めないといけない。なぜなら、達成される「ちょうどいい良さ」の水準自体が価値になるので、それ自体を誰かが決めてあげる必要があるからです。

Q. 情緒的価値、自己表現的価値のところが人間の仕事になるとすると、開発者というより企画者に仕事がシフトしていくのか。

馬場氏: 今の役割分担からすると、そういう側面がかなり出てくるだろうなと思います。それって、今も現場の開発者からちょっと職位が上がると、だんだんそうなっていくものだと思うんですよね。AIの登場によって、皆さんの職位が1個2個上がったような振る舞いになってくるかもね、というところと合致するので、そうなんだろうなと思っています。あともう1つ、どうしても言い忘れたことがあって。私たちがプロフェッショナルに対して思うのは「普通にやっていてほしい」ということなんですが、その「普通」が難しい。料理の塩加減1つにしても、普通にしてくれ、と言われても人や状況によって全然変わる。それをちゃんとアジャストしてあげるためには、文脈が広くて、価値にちゃんと向き合っている人間がやはり必要だろうな、と思っています。