今月のはじめに書いたポエムだが、割と反響もあり、多くの人に読まれたエントリになったようでありがたいことである。
ワタシがエントリを書いた数日後に、ずっとこの話題に関して注目してきたマイク・ルキダス（オライリーメディアのコンテンツ戦略担当副社長）が、未来のプログラマにクリエイティブな仕事は残されているだろうか、というワタシの問題意識に偶然にも答える文章を書いている。この話題のフォローアップの意味で、今回はこのエントリの内容を紹介したい。
まず取り上げられているのは、マイクロソフトの Build カンファレンスで CTO のケヴィン・スコットが語った、GitHub の何千ものプロジェクトのコードを学習した AI が実際にプログラムを作成する実験プロジェクトの話である。この AI は、コメント内容から関数本体のコードを生成する。そのデモの動画を見てみよう。
[2020年07月21日追記]：時間指定したつもりだったが、はてな記法では利かないのか。コード自動生成のデモは29分過ぎです。
それに似た取り組みとしてマイク・ルキダスは、教師なし学習によるプログラミング言語間の翻訳についての研究論文をとりあげている。
しかし、デモはデモでしかなく、研究論文やあくまで研究論文だ。正直マイクロソフトのデモを見ても、AI が作成する関数の本体は、ほとんどワンライナーで収まる単純な内容であって、やりたい内容をコメントで正確に記述しなければならないし、まだまだ限定的だと一目見て分かるレベルである。現状ではこのモデルにお金をかけてコードを書かせるより、人間の開発者を雇ったほうが安いに違いない。
プログラミング言語間の「翻訳」にしても、単純なコードなら COBOL を Rust に置き換え可能かもしれないが、1960年代や1970年代に極めて限られたコンピュータリソースを駆使すべく書かれたトリッキーなコードを正しく「翻訳」できるなんて期待するのは無茶だろう。
つまり、プログラミングの仕事が AI によって明日にでも消え去るなんてことはありえない。
とは言え、こうしたコーディングの自動化がプログラミングの未来にどんな意味を持つか考えてみることは重要だとルキダスは書く。プログラミングは今後ますます自動化されるだろうし、というか昔と比べれば、今だってプログラミングは既に高度に自動化されているのだ。優れた最適化コンパイラは既に進化した AI システムなわけで。
プログラミングは「消え失せ」たり「時代遅れになる」ことはない。そうじゃなくて、その意味合いが変わるのだ。そこでルキダスが持ち出すのは、「ブルーカラー（配管工）」のプログラマと「ホワイトカラー」のプログラマという分類である。
既存のコードをつなぎ合わせる前者と、そのつなぎ合わせるものそのものをデザインしたり、つなぎ合わせるツール自体を作る後者とでは、重なる部分も多いとはいえスキルセットが異なる。で、前述のマイクロソフトのデモは、プログラマはいずれ単純な関数をコーディングする作業から解放される可能性を示している。しかし、高レベルなタスクを実現するツール、一例をあげればマイクロソフトがデモしたコーディングエンジン自体は人間に残される。API のデザインとかも。
それなら「ブルーカラー」のプログラマはどうか？ くだんのデモは関数のコードを吐き出していたが、とてもでもないがその関数から巨大なシステムが構築可能には見えない。既存の関数をコールする能力はありそうだが、記述された仕様から大規模なプログラムを組み立てることはできない。たとえるなら、シンプルな請求書は吐き出せても、完全な請求システム一式は無理ということ。それを目指す研究プロジェクトはあれども、実現には十年以上かかるだろう。「ブルーカラー（配管工）」のプログラマの仕事もまだ安全ということになる。
動画の中で（マイクロソフト CTO の）ケヴィン・スコットは、プログラマが退屈で繰り返しの作業に費やす時間を減らすことについて語っている。これは AI 全般にあてはまる話である。AI は退屈で繰り返しの作業に費やす時間を減らし、クリエイティブな仕事に取り組む時間が増える。プログラミングの大部分は、いかに特定の処理を実行するかを明確、詳細に記述することである。それは退屈かもしれないし、繰り返しが多いし、間違いなくエラーが紛れ込みやすい。
だから我々はプログラミングはどうあるべきかについてもっと考える必要がある、とルキダスは注意を向ける。ケヴィン・スコットの言葉を借りるなら、プログラミングにおける「クリエイティブ」なところって何かということだ。
ルキダスは、「クリエイティブ」という言葉は正しくないかもと書く。1960年代や1970年代、プログラマは「アナリスト（analysts）」と呼ばれることが多かった。今もプログラマの求人を検索すると、その名残りがあるのが分かる。
それなら「アナリスト」の意味について考えてみよう。アナリストは問題を解析する。問題が何であるか、その問題をどうすれば効率的に解決できるか。アナリストは問題をパーツに分解することを考えるし、そもそもその問題が解決されるべきなのかさえ考える。その問題を解決したらどんな倫理的な問題が生じるか、その新たな問題はどう対処されるべきか？ ソフトウェアは悪用可能か、もしそうならどう悪用される？ どういう手順で悪用を防げるか？ アナリストは、人々がそのソフトウェアをどう使うかについても考慮する必要がある。ユーザインタフェースやユーザエクスペリエンスの話だが、障碍者にも使えるかも考慮する必要がある。
つまり、その仕事はソフトウェアが何を行い、どう構築されるべきかという全体像に関わる決定を行う、ソフトウェアアーキテクチャをどうするかということである。
だから、「コードを何行書いた」かで生産性を測るのは短絡的である。我々がコードの作成、テスト、アーカイブ、デプロイに絶対欠かせない素晴らしいツールを考えると、確かにそれらのツールは必要不可欠だし革命的なのだけど、それらは本当の問題を解決することはない。その本当の問題とは、「我々は正しい問題を解決しているか？」ということだ。Code for America のような組織の業績は、必ずしも技術的にディープなものではないし、GetCalFresh（カリフォルニアの低所得者が食糧支援を受ける手続きを簡易化するサービス）のラディカルなところは、本当に利用すべき人たちに使ってもらうべくシステムを再設計しているところにある。そして我々は、これらのプロジェクトが行っているような問題の解析をもっとやる必要がある。
つまり、プログラミングには単にコードを書く以上の意味があるということですね。その仕事で一番重要なのは、面接でホワイトボードにクイックソートのコードを書くこととは何の関係もない（余談だが、このホワイトボードを使ったコーディング面接は技術スキルを測るのに失敗しているという研究があるみたい）。もっと考えるべきことはたくさんあるとルキダスは訴える。現状、プログラマは大局的な問題に取り組むより、リリース日に間に合うようコードを書くために多大な時間を費やしている。そういう大局的な問題に取り組むのは、いつだって誰か他の人の仕事だったわけだ。マイクロソフトの研究は、プログラミングにどんな意味があるか、本当にやるべき仕事は何なのか考える機会を我々にくれたんじゃないか、とルキダスは締めくくっている。
うーん、イジワルに考えるならコードの自動化の現状がまだ実用的でないのが見えてきたので、うまく方向転換を図ったなと見ることもできるだろう、というのがワタシの私見。
オフショア・AI・ノーコード（銃・鉄・病原菌っぽく） https://t.co/KskZfneFsW
— 小野マトペ (@ono_matope) July 13, 2020
ノーコードや AI で簡単にプログラマが不要になることはない。が、今こそプログラミング、そしてプログラマという仕事の意味を考え直すときというルキダスはアピールしているわけだが、ちょっとズルい着地点な気もする。
プログラマーと言うべきなのにエンジニアという用語が定着した理由、単に日本国政府の裁量労働制とかの指針に使われている言葉がエンジニアだったからという気がする。別の言葉を使ってしまうとそれはエンジニアじゃないから裁量労働制の対象じゃないだろと国家のさじ加減で言われるリスクは飲めない。
— Ryou Ezoe(江添 亮) (@EzoeRyou) July 18, 2020
ひるがえって日本のプログラマの現状を考えると、最近の話題でITに奪われた「エンジニア」って言葉、なかったことにされた「工学系エンジニア」が代わりに付与された属性が「現場猫」なのではないか話があったが、この日本的事情はプログラマのあり方を考える上で果たして好ましいかどうかも今一度考えられたほうがよいかもしれない。
