コーディングはAIの仕事、エンジニアリングは人間の仕事
ショーニング氏自身、職能の境界をまたいできた人物だ。最初は個人的な興味からエンジニアとして出発し、自らのスタートアップ、Heroku、GitHubを経てきた。デザイン側の仕事をした時期も、扱ったのは一貫して開発者向けのプロダクトだったという。
「自分のバックグラウンドが何なのか、自分でもよく分からないんです。エンジニアリングでもあり、プロダクトでもあり、デザインでもあります」
Notionには、AIエージェントと自動化を担うワークフロー領域の、エンジニア・デザイナー・プロダクトからなる小さなクロスファンクショナルチームを率いるために入社した。この1年半で、そのチームのモデルを全社に広げてきた。
専門分化や階層型の組織は、人間が集中するために生まれたものだ。仕様を決め、デザインし、エンジニアリングに渡すという直線的な進め方を、同氏は「とても古いやり方」と呼ぶ。
「AIモデルには階層が要りません。同じ一つのモデルが、優秀な弁護士で、優秀なエンジニアで、優秀な数学者で、デザイナーとしてもどんどん良くなっているのですから」
だからNotionでは、エンジニアリング・プロダクト・デザインの境界を積極的に溶かしている。ただし、すべてが一つに混ざるわけではない。
「私は『重力』という言葉を使います。エンジニアリングにも、プロダクトにも、デザインにも重力がある。互いにどんどん近づいてはいますが、主な軸足はやはり残ります」
最終的に職種が一つになるのかと聞くと、答えは「分かりません」だった。「そのことにオープンでいて、あいまいさをそのまま許容することが大事だと思います」
では、エンジニア以外の職種もコードを書くようになったとき、品質はどう保つのか。生産量を一気に増やしながら品質を保つ方法を見つけた企業は、まだ多くないと同氏は見ている。そのうえで示したのが、コーディングとエンジニアリングを分けて考える視点だ。
「コーディングは、いまやAIモデルがやることです。エンジニアリングは、ソフトウェアを支配する法則を理解しているからこそ、それがどうスケールするかを予測できる専門分野です」
「エンジニアは、トラックが橋を渡っても橋は壊れないと、実際に渡る前に言えるんです」
この区別は、開発の段階によって求める水準を変えることにつながる。ディスカバリー（何を作るべきかを探る段階）では、動くかどうかすら重要ではない。1人か2人のユーザーに対して動けばよく、信頼性も要らない。もともとタダで作れたのだから、コードを全部捨てても構わない。良いと確かめられたものだけを、デリバリー（顧客に届ける段階）としてエンジニアリングの手に移す。
AIに任せる仕事は3種類ある
ショーニング氏は、AIに任せる仕事を3つに分けて考えている。
| 種類 | 仕事の性質 | AIへの任せ方 |
|---|---|---|
| 探索 | 行き先が分からない。何を作るべきかを探す | 主に人間の仕事。自動化する方法はまだ見つかっていない |
| 仕様が明確な仕事 | 作るものが決まっている（例：外部サービスとの連携機能） | システムをうまく設計すれば、工場のように追加コストなしで量産できる |
| オラクル型 | 目指すお手本がある | 近づいているかを評価できる「目と耳」を与えれば、AIは最も効率的な版まで改善を続ける |
表の2つ目（仕様が明確な仕事）について、同氏は工場にたとえる。システムをうまく設計しておけば、物理的な製造工場と同じように、同じものを次々に流して、追加のコストなしに新しい連携機能ができ上がる。
3つ目の「オラクル」は企業名ではなく、正解を告げる存在という意味の概念だ。
「近づいているかどうかを評価するのに十分な目と耳、感覚を与えれば、AIモデルは最も効率的な版を作り上げるまで、登って、登って、登り続けます」
残る一つ、探索だけはAIに任せる方法がまだない。だからこそ、CTOとしての目標はそこに人間の時間を戻すことにあるという。
「エージェントにできるだけ多くのコンテキストを与えて、退屈な作業を全部自動化する。そうすれば私たちは、アイデアについて、何を作り何を作らないかについて考える時間を増やせます」
ラウンドテーブルで語られた「コンテキストレイヤー」の構想は、開発の現場から見れば、この時間を取り戻すための仕組みでもある。
