re:Invent 2025: Keynote with Dr. Werner Vogels
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: Keynote with Dr. Werner Vogels
この動画では、Amazon.com CTO Dr. Werner Vogelsが最後のre:Inventキーノートとして、AI時代における開発者の進化と「ルネサンスデベロッパー」という新しいフレームワークを提示しています。開発者の歴史を振り返りながら、ツールと共に進化してきた開発者に必要な5つの資質を解説。好奇心を持ち失敗を恐れず学び続けること、Donella Meadowsのシステム思考でフィードバックループを理解すること、仕様駆動開発による正確なコミュニケーション、メカニズムで品質を担保するオーナーシップ、そしてJim Grayのような深い専門性と幅広い知識を持つT字型の博学者になることです。Kiro IDEチームのClare Liguoriがspec-driven developmentの実践例を紹介し、要件・デザイン・タスクという3つのドキュメントを通じてAIとより正確にコミュニケーションする方法を示しています。ルワンダの保健システムやナイロビのKOKO Networksなど世界中の開発者が実際の課題に挑む事例を通じて、AIツールは開発者を時代遅れにするのではなく、より重要な仕事を可能にすることを強調しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
開発者の終わりか、新たな始まりか：Werner Vogelsの最後の基調講演
開発者の終わり。前に聞いたことがあるな。
...やあ、ロレイン。何してるの？ああ、昨日落としちゃったプログラムカードを整理してるのよ。それと、なぜマシンがカード442で止まり続けるのか調べてて。コンパイラの本当に厄介なバグを記録して、それであなたと話してるわ。本社で何か新しいことある？これについて読んでたんだ。Bubble。そう、それが新しい高水準言語なの。すごいわ。これで誰でもコードが書けるようになる。誰でもかどうかはわからないな。ソフトウェアを書くのはかなり難しいよ。
ここはどこだ？マーティー、何を読んでるんだ？VBを勉強してるんだ。ビジュアルプログラミング。コードの歴史だよ。ドラッグアンドドロップが未来なんだ。ドラッグアンドドロップもまだコードだよ。バグもあるし、エンジニアも必要なんだ。「すべてのものは常に障害を起こす」・・・これは本当なのか？クラウドってエンジニアが減るってこと？エンジニアが数分でサーバーが立ち上がる。オンデマンドでスケール。従量課金制。わあ、毎日新しいことを学べるね。あなたが作ったら、あなたが運用する。すごいな。
お母さんに電話するのを忘れずに。やあ、マーティ。いいワームホールだろ？一緒に入ってもいいか？これは俺たちが知ってる開発の終わりなのか？それとも、また新しい始まりに過ぎないのか？...
Amazon.comの副社長兼CTO、Dr. Werner Vogelsをお迎えします。
私は探し求め、そしてあなたの中に毎日何か新しいものを見つけます。何か新しいもの、異なる視点に対するオープンな心、そして他には何も重要ではありません。おはようございます。今のビデオは、変化の新しい波に直面するあらゆる世代の開発者たちを映し出していました。ツールは進化し、アーキテクチャは進化し、期待は進化し、そして私たちも進化します。しかしその話をする前に、 部屋の中の象について話しましょう。 私は2012年からこのkeynoteを行ってきて、すべてやってきました。たくさんのTシャツですよ、ちなみに。しかし今日、 この連続記録は終わります。これが私の最後のre:Invent keynoteです。
まだやるべきことはあります。Amazonを去るとかそういうことではありません。しかし14年間のre:Inventの後、みなさんには 若くて、新鮮で、新しい声を聞く権利があると思うんです。Amazonには素晴らしいエンジニアがたくさんいて、彼らには語るべき素晴らしいストーリーがあり、教え、助け、教育することができます。そしてAWSのそういった若い、異なる声がみなさんの前に立つ時が来たと思います。でも誰も私に強制したわけではありません。Amazonを去るとかそういうことでもありません。これは私自身の決断で、みなさんが私だけでなく異なる声を聞けるようにするためです。
AIは私の仕事を奪うのか？進化し続ける開発者の役割
では、もう一つの部屋の中の象について話しましょう。 私は世界中のAWSのお客様を訪問してきましたが、あらゆる 国、あらゆる都市で繰り返し出てくる質問が一つあります。AIは私の仕事を奪うのか？ おそらく。AIは変革をもたらします。一部のタスクは自動化されます。一部のスキルは時代遅れになります。新しいスキルが生まれます。だから、おそらく私たちはこの質問を、言い換え、再構成すべきでしょう。AIは私を 時代遅れにするのか？ 絶対にそうはなりません、もしあなたが進化すれば。そしてAmazonでの過去数年を振り返ると、 私たちはこれらすべての新しいツールを使ってきましたが、時間とともに進化し、手に新しいツールセットを持ちながらも素晴らしいエンジニアであり続けることができることを見てきました。なぜなら私たちは開発者として進化するからです。そしてツールもそうでなければなりません。変化は常に起こるものであり、これは昔からずっとそうでした。何も新しいことではありません。
少し時間を遡ってみましょう、ちょっと楽しみのために。私が 学校に通っていた頃、68000アセンブラ、COBOL、そしてPascalを教わりました。これらの言語はもう 使われていません。そして60年代には、突然コンパイラが登場し、そのコンパイラがどんな種類のアセンブリを吐き出すかはもう重要ではなくなりました。しかし、アセンブリを学ぶことで、Pascalのループが実際にどのように マシンコードに変換されるかを学び、それは私にとって重要でした。時間が経つにつれて、 コンパイラはほとんどの開発者が必要とする最高レベルの抽象化となりました。1970年代には、 突然構造化プログラミングが人気になり、私たちはそちらに向かって進んでいました。Bell LabsやBerkeleyの コンパイラがこの変化を支えました。それらは開発者にフローに対するより明確な制御を与え、非構造化コードの混沌から脱出する手助けをしました。
それから数年後、Bjarne Stroustrupが 現実世界の概念をオブジェクトとクラスを使ってコードに直接モデル化する方法を探求し始め、それがC++となり、 オブジェクト指向プログラミングの形成を助けました。1990年代後半、Amazonはまだ 1998年にモノリスとして動いていました、そしてこれは有名な瞬間でした。成長が加速し、チームはモノリスの一部をサービスに分割し始めました。それぞれの サービスはオーナーシップを持ち、独自のインターフェースを持ち、 それは開発者の働き方を完全に変えました。彼らはより速く動き、他のチームから独立し、 自分たちのシステムをエンドツーエンドで所有しました。時間が経つにつれて、業界全体が 大規模分散システムを構築し運用するための実用的なモデルとして、このような実践を採用しました。
当時のツールはどうだったでしょうか？2000年代には、ほとんどの開発者は まだオンプレミスで構築とデプロイを行っていました。コードを書くということは、ハードウェア、キャパシティプランニング、そして長い調達サイクルと格闘することを意味していました。クラウドサービスが登場したとき、それは再び役割の期待を変えました。開発者は突然オンデマンドのインフラストラクチャを手に入れ、ハードウェアを待つことなく実験する自由を得ました、そしてこれには新しいスキルが必要でした。世界中の開発者が、クラウドインフラストラクチャがソフトウェアを構築し運用する通常の方法となる世界を採用しました。
私の最初のIDEは、たぶんviでした。 いいえ、私はEmacsの人間ではありません。IDEは実際に私たちと共に進化しました。 覚えていますか、Microsoftには画面上にボックスを描くことができた時期があり、これが最初の本当のIDEでした。その後Visual Studioが登場し、Visual Studio Codeが素晴らしいプラグインのおかげでデフォルトになりました。今日の環境はCursorとKiroであり、それが新しいワークフローです。来年、5年後、10年後に新しいワークフローがあるでしょうか？もちろんあるでしょう。
しかし、今日の私たちのツールは、本当に素晴らしいものだと思います。 MattのKeynoteで、AI支援ワークフローによって開発者が劇的に生産性を高めている例を見せてくれましたが、これらのどれも、あなたにしかできない仕事を取り除くものではありません。 覚えておいてください、仕事はあなたのものであり、ツールのものではありません。重要なのはあなたの仕事なのです。私たちのツールは、 私のキャリアの中で何度も変わってきましたし、これからも変わり続けるでしょう。私たちは依然としてビルダーであり、依然として重要な存在であり、何も変わっていません。開発者であることにこれほどワクワクできる時代は、かつてなかったのです。
複数の黄金時代が交差する現代：ルネサンスとの類似性
Bezosは、それほど昔ではないインタビューで、私たちが複数の黄金時代が同時に到来する震源地に生きているという話をしていました。宇宙旅行、人工 知能、そしてロボティクスは、それぞれが信じられないスピードで進歩しています。しかし、この瞬間を特別なものにしているのは、これらのブレークスルーが実際にお互いを強化し合っているということです。ある分野での進歩が、他の分野での進歩を加速させているのです。
これは実際、歴史を振り返ると、似たようなことがあった時代を思い起こさせました。ルネサンス、 つまり再生の時代は、暗黒の時代の後に訪れました—暗黒時代、中世、死の疫病の時代です。Monty Pythonを知っている人なら、それがどんな様子だったか分かるでしょう。しかしルネサンスは、人々が好奇心を持つようになったことで、すべてが変わった時代でした。好奇心が爆発的に広がり、その結果は素晴らしいものでした。
科学者や 哲学者がこの時代に登場しました。これを見ると、Medicis家はおそらくベンチャーキャピタリストやフィランソロピスト、あるいはどう呼ぶにせよ、その最初のバージョンだったでしょう。GalileoやCopernicusは素晴らしい科学者でした。Petrarchは最初の哲学者の一人でした。Da Vinci—彼については後で触れます。しかし同時に進化していたのは、彼らのツールでもありました。 彼らだけではないのです。好奇心のおかげで、鉛筆が発明されました。今日では大したことのない発明のように思えますが、 当時は大きなことでした。消失点と呼ばれるものについて考え始めたという事実。突然、ルネサンス以前の絵画や素描と比較すると、それらはすべて平面的でした。ルネサンスでは、突然奥行きが現れ、絵画や素描に異なる照明が現れたのです。
そしてこれらのツール、 顕微鏡や望遠鏡は、もちろんオランダ人によって発明されました。何も言ってませんよ。そして 印刷機は、もちろん、私たちはルネサンスにおける発明の頂点のようなものと見なしています。しかしそれは単一の発明ではありませんでした。Gutenbergは 実際にワインプレスを最初のステップとして使いましたが、それだけが彼が発明する必要があったものではありませんでした。彼は活字—基本的には組み合わせることができる文字—を発明する必要がありました。それらの文字に実際に塗ることができるインクを発明しなければなりませんでしたし、それから押し付けるための紙も、当時はほとんど想像もつかないものでした。
それは芸術と科学が同じ会話の一部であった時代でした。創造性とテクノロジーが共に進化していたのです。さて、少し時間を取って、何が人々をその世界でそれほど効果的にしていたのかを考えてみてください。彼らは好奇心旺盛でした。彼らは前提を疑いました。彼らは幅広く学び、その学びを深く応用しました。彼らは分野間の境界を見ることはなく、分野間に橋を架けたのです。彼らはまた大胆な実験者でもありました。彼らはスケッチし、測定し、失敗し、そして再び挑戦しました。彼らは実践することで学んだのです。
これらすべてを受け止めると、私たちは再びルネサンスの時代にいると思います。そしてあなたは新しいルネサンスデベロッパーなのです。ルネサンス時代のそれらの科学者たちの資質は、今日でも同じように重要です。私はこれらの資質をまとめて、ルネサンスデベロッパーと呼ぶフレームワークを作りました。そして今日、この新しい時代において進化し成功するために役立つであろうこのフレームワークをお見せしたいと思います。
ルネサンス デベロッパーの第一の資質：好奇心を持ち続けること
この全てにおいて重要なのは、あなたが育む必要がある最初の資質です。それは好奇心を持つことです。好奇心は極めて重要です。デベロッパーとして、あなたは常に継続的に学ばなければなりません。なぜなら、すべてが常に変化しているからです。
私が出会ったすべてのデベロッパーは、何かを分解してその仕組みを見るという本能を持っています。これもまた好奇心であり、理解したい、改善したい、構築したいという欲求なのです。あなたはその本能を守らなければなりません。好奇心を持ち続けてください。なぜなら好奇心は学習と発明につながるからです。
学習にとって同じくらい重要なのが実験です。すべての新しい発明には実験が必要であり、うまく実験するには失敗を厭わない姿勢が必要です。結局のところ、ダ・ヴィンチは飛ばなかった飛行機をモデル化しましたが、私たちは今飛んでいます。ちなみに、実験は結果がすでにわかっているなら実験ではありません。実験は学習を促進し、この失敗を厭わない姿勢が極めて重要なのです。
私が新しい言語を学ぶとき、それがオランダ語であれ英語であれポルトガル語であれドイツ語であれ、同じ原則が当てはまることがわかります。学ぶための最良の方法は、失敗して優しく訂正されることです。文法をいくら勉強してもいいですが、本当の学習が始まるのは、会話につまずいて誰かが正しく導いてくれるときなのです。ソフトウェアも同じように機能します。ドキュメントを延々と読むことはできますが、システムがどのように動作するかを本当に教えてくれるのは、失敗したビルドや壊れた前提なのです。
最近Rustコンパイラを使ったことがある方なら、どれだけ多くのフィードバックが得られるかご存知でしょう。しかし、実際にやってみることでしか学べないこともあります。読むこと、見ること、聞くことには限界があります。本当の学びは、実際に取り組んだとき、プレッシャーがあるとき、結果が重要なときに起こるのです。ストレスとパフォーマンスの関係には、Yerkes-Dodsonの法則と呼ばれるものがあります。図は釣鐘曲線を示しています。プレッシャーが少なすぎると集中できません。プレッシャーが多すぎると圧倒されてしまいます。最適なポイントは、好奇心と挑戦が出会う、その上昇する傾斜のどこかにあります。
そこで脳は完全に覚醒し、集中し、成長する準備が整うのです。快適に座っているだけでは、そのポイントには到達できません。自分自身を試される立場に置く必要があるのです。さて、この背景には全体的なストーリーがあります。今日皆さんの席に置かれていた新聞、Kernelに載っています。そこにはAndy Warfieldによる記事があり、彼がこのことについて書いています。もっと理解したい方は、ぜひその記事を読むことをお勧めします。
さて、学びにはもう一つの側面があります。学びは社会的なものです。私たちはただ部屋に座って、一人の人が何をすべきか正確に話すのを聞くためだけにここにいるわけではありません。本当に学ぶのは、お互いに話し合うことによってです。学びは認知的なだけでなく、社会的なものなのです。時にはガラスに触れる必要があります。つまり、いつもの環境から出て、ユーザーグループに行ったり、re:Inventのようなカンファレンスに参加したり、友人とコーヒーを飲みながらシステムについて話したりする必要があるということです。鋭敏さを保つ最良の方法の一つは、何かを作っている他の人たちの周りにいることです。
私にとって、それはよく出張中に起こります。私は仕事で多くの旅をしていて、それらの旅は、人々が実際にどのようにテクノロジーを使っているかについて、私たちが想像するかもしれない使い方ではなく、実際の使い方とつながり続けることを可能にしてくれます。今年は非常に幸運でした。私は2回、それぞれ1ヶ月の旅をしました。1つはサハラ以南のアフリカへ、もう1つはラテンアメリカへです。両地域でいくつか講演をしましたが、主にお客様とお会いし、本当にやっていることはそれらのお客様から学ぶことです。
世界の課題に挑む開発者たち：アマゾン川からルワンダ、ナイロビまで
いくつか例を挙げましょう。こちらはAJEです。これは実に特別なものです。実際にAmazonに辿り着くまでに21年かかりました。Grupo AJEは飲料会社です。彼らはAmazon川沿いのコミュニティを支援しており、若者たちが大都市に出て行かなくても済むように、村に経済的な未来を提供しています。これは素晴らしい経験であり、善行が同時に利益を生むことができる素晴らしい例です。Amazon川は美しかったです。ピンクのイルカも見ました。しかしそれは私が学んだ別のことを思い出させてくれました。それは、すべてがそれほど素晴らしいわけではないということです。
今年の初めに、私はポッドキャストのエピソードでThe Ocean Cleanup ProjectのBoyan Slatと話をしました。彼が教えてくれたのは、海で見つかるプラスチックの80%は、世界の300万の河川のうちわずか1000分の1の河川から発生しているということです。海のプラスチックを通じて、彼らはすでにそこにあるものをクリーンアップするだけでなく、新しいプラスチックがこれらの河川を通じて海に流入するのを止める必要があります。そして彼らはそれを実行しています。
彼らはドローン、AI、カメラ分析、さらにはGPSタグ付きのダミープラスチックを使用してRiver Modelを作成しました。私たちがアマゾンに行った場所では、彼らは実際にプラスチックを取って川に入れ、それがどこに行き着くかを確認しました。結局、アマゾンは大きな汚染源ではないことがわかりました。しかし、この計算モデル、彼らが構築したもの、橋の上や船の後ろに設置されているこれらのAIカメラは、プラスチックがどのように、どこに移動するかを予測する計算モデルを作成し、最大の効果を得るためにクリーンアップシステムを配置するのに役立っています。
さて、もう一つこの旅で私を完全に驚かせたのは、実はルワンダでのことでした。ルワンダでは、これが保健省の本部です。そしてこれが彼らのhealth intelligence centerです。彼らのオペレーションセンターでは、巨大なスクリーンが国中の4つの異なる階層の医療施設からのほぼリアルタイムのデータを表示しています。彼らは膨大な量の医療データを取り込んで処理する印象的なシステムを構築し、疾病の発生から母体健康の結果まですべてを可視化しています。そして彼らはそれを使って新しい政策を作成しています。彼らはこのモデルを作成し、国のどの地域が医療提供者から徒歩30分以上離れているかを示し、このデータを使用して、サービスが行き届いていない地域に新しい母体健康施設を戦略的に配置しています。彼らはデータを使って政策を推進し、実際にその政策を実施しています。
もう一つの訪問ですが、つまり、これらの旅のほとんどで、私は毎回驚かされます。特に若い企業が世界で最も困難な問題のいくつかにどのように取り組んでいるかについてです。この場合、私たちはナイロビにいます。そして私は、多くの場所で、人々が朝に1ドルか2ドルを借りて、いくつかの商品を買い、市場や路上でそれを売りに行くことを学びました。そして夕方には彼らはこれらのドルを返し、うまくいけばその日稼いだ40セントか50セントを持っています。そしてそれは食べ物を買うのに十分です。しかし、食べ物を調理するためのガスを買うには十分ではありません。そのため、貧しい地域では、すべて炭素で燃やされており、これは大規模な汚染を引き起こしています。そこでKOKO Networksというこの若い企業が、まったく異なるソリューションを考え出しました。
この場合、私たちはナイロビにいます。私は多くの場所で、人々は朝に1ドルか2ドル借りて、商品を買って、市場や通りで売りに行き、夜にこれらのドルを返して、うまくいけばその日に稼いだ40セントか50セントを手にすることを学びました。 それは何か食べ物を買うのに十分です。しかし、あなたの食べ物を調理するためのガスも買うのには十分ではありません。だからそれらのより貧しい地域では、すべてが炭素で燃やされており、それは非常に汚染しています。だからこの若い KOKO Networksという企業は、完全に異なるソリューションを思いつきました。基本的に彼らはエタノール入りのATM機と人々が持ち運べる小さなキャニスターを構築しました。
彼らは基本的にエタノールが入ったATMマシンと人々が持つ小さなキャニスターを構築し、人々は基本的にマシンに歩いて行き、そのキャニスターを差し込んで、その夜の食事を調理するのに十分な5セント分のガスを求めることができます。これが、開発者が自分のスキルを実際の人間の課題に適用したときに起こることです。
開発者は常に進歩を推進してきました。あなた方はデジタル世界の基盤を構築してきました。そして今日、あなた方はAIを可能性から有用で、安全で、スケーラブルなものに変えている人たちです。あなた方のような開発者は過去に不可欠でした。今日も不可欠です。そして将来も不可欠であり続けるでしょう。国連は2050年までに、この惑星にさらに20億人の人々が増えると予測しています。私たちはどうやって彼らに食料を供給するのでしょうか？どうやって彼らが経済的な未来を持つことを確実にするのでしょうか？どうやって彼らが医療を受けられるようにするのでしょうか？それは、世界最大の問題のいくつかを解決するのに役立つ技術を開発することが私たちにかかっています。技術者として、私たちにはその能力があります。
そして、あなた方の中には、部屋の隅で何かを構築するだけでなく、実際に他の人を助けるために多くの時間を費やしている人たちがいます。AWS Heroesです。現在200人います。彼らには拍手が相応しいです。また、Community Buildersもいます。私はAWS Heroesに会ってきましたが、彼らは世界中のそれぞれの場所で難しい問題を解決している人たちです。現在、58カ国に265人のHeroesがいます。しかし、私が常に驚かされるのは、彼らから学べることがいかに多いかということです。
ちなみに、今年のNow Go Build 賞はRafael Vincent Wangに贈られます。Rafiは本当にルネサンス デベロッパーを体現しています。彼はただコードを書くだけでなく、コミュニティを構築し、他の人をメンターし、2013年からフィリピンのAWSユーザーグループを共同でリードしています。さあRafi、もう一度彼に拍手を送りましょう。
ルネサンス デベロッパーの第二の資質：システム思考
それでは、ルネサンス デベロッパーが持つべき最初の資質は、好奇心を持つことだと思います。そして、私はWalt Whitmanのこの言葉が好きです。私たちは自分が知っていることではなく、学ぼうとする意欲によって定義されるのです。ルネサンス デベロッパーが持つもう一つの資質は、システムで考えるということだと思います。ちょっと私と一緒に考えてみてください。もしあなたが本当に理解していないなら、この場合、私はコンピュータシステムを意味しているのではなく、もっと大きなシステムのことです。
1970年代に、Donella Meadowsという生態学者が複雑なシステムがどのように振る舞うかを研究し始めました。彼女はコンピュータサイエンティストでしたが、彼女の洞察は私たちのソフトウェアの世界を完璧に説明しています。そして彼女はこう書きました。システムとは、物事、人、細胞、あるいは何であれ、それらが相互に接続され、時間の経過とともに独自の行動パターンを生み出すような一連のものである、と。これは非常に優れた定義でした。なぜなら、すべてのエンジニアが最終的に学ぶこと、つまり私たちのシステムには独自の生命があるということを捉えているからです。
ちなみに、コンピュータとは関係のない例を挙げましょう。システムの最も印象的な例の一つは生態学から来ています。20世紀初頭、オオカミがYellowstone国立公園から排除されました。それは論理的に思えました。捕食者が少なければエルクが増え、より多くの生命が生まれると。
しかし、その逆が起こりました。谷は過放牧され、木々は消え、川は浸食し始めました。この現象はTrophic Cascadeと呼ばれています。2010年にオオカミを公園に再導入したとき、ゆっくりと公園は回復し始めました。植生が戻り、ビーバーが戻ってきて、川さえも流れを変えました。オオカミが川を動かしたのではありません。彼らはシステム全体の振る舞いを変えたのです。その単一のフィードバックループ、捕食者と被食者が、システム全体のバランスを再形成しました。そして構造が変わると、振る舞いが変わります。そしてフィードバックが変わると、結果が変わります。それがシステム思考と呼ばれるものです。
システム思考をする際には、孤立した部分だけでなく、完全なシステムとして考えます。すべてのサービス、すべてのAPI、すべてのキューは、より大きなシステムの一部なのです。一つの部分を単独で変更することはできません。リトライポリシーを変更すれば、負荷に影響します。キャッシュを追加すれば、トラフィックフローが変わります。チームのオーナーシップを変更すれば、デリバリーのペースが変わります。それぞれの変更が新しいパターンを生み出し、安定するものもあれば、そうでないものもあります。
すべての動的システムは、フィードバックループによって形作られています。強化ループ、ポジティブループと呼ばれることもありますが、これは変化を増幅します。バランシングループ、またはネガティブループは、変化に対抗してシステムを平衡状態に押し戻します。私が思うに、このようなパターンが見えるようになると、小さな、適切に配置された変更が、システム全体の振る舞いをどのように変えるかが見えてくるのです。
Donellaは「Leverage Points: Places to Intervene in a System」という論文を書きました。この中には、コンピュータサイエンスで日常的に知っている言葉、ポジティブフィードバックループやネガティブフィードバックループなどがありますが、本当にこの論文を読むべきです。これを宿題としましょう。前に来て、QRコードの写真を撮ってください。これが来週の宿題です。
ルネサンス デベロッパーの第三の資質：明確にコミュニケーションする
ルネサンス デベロッパーはシステム思考をします。そして、レジリエントなシステムを構築するには、より大きな全体像を理解する必要があります。ルネサンス デベロッパーの3つ目の特質について考えると、それはコミュニケーションです。彼または彼女はコミュニケーションをとります。そして、このより広い視点に立つと、自分の考えを明確に表現する能力は、考えること自体と同じくらい重要だということに気づきます。だからこそ、エンジニアやテクニカルリーダーがキャリアのためにできる最も重要なことの一つは、強力なコミュニケーションスキルを実践し、開発することだと私は信じています。
例を挙げましょう。2年前に戻って、The Frugal Architectをやったときのことです。この写真を覚えていますか。これはAmazonのホームページです。そして、私はこのホームページ、つまりAmazonシステム全体を、3つの異なるティアに分割した方法を説明しました。ティア1は、システムを機能させるために絶対に必要なものです：検索、ブラウズ、ショッピングカート、チェックアウト、そしてレビューです。この5つがなければ、サイトは機能しません。ティア1です。ティア2は、お客様にとって重要なものです：パーソナライゼーション、レコメンデーション、そういったものです。そしてティア3は、あると良いかもしれない種類のパーツです。
これは、私たちエンジニアにとってだけでなく、ビジネスに向けたコミュニケーションツールとしても重要です。ビジネスと一緒にテーブルを囲んで座り、どれだけの9の可用性が必要かについて話します。99.99、それにはこれだけのコストがかかります。あるいはティア2は、おそらく99.9。ティア3は、もしかしたら全く気にしないかもしれません。99%で良いと思います。まあ、データセンターがオフラインになったら、手動でフェイルオーバーをします。しかし、これはあなたが持つ必要があるコミュニケーションなのです。自分のシステムと、その機能、そしてビジネスへの機会を明確に説明できる必要があります。コミュニケーションは極めて重要です。
さて、人間の言語というのは、少し難しいところがありますよね。自然言語は曖昧だからです。しかし、私たちは同時に非常に多くの感覚を持っているので、この自然言語をより曖昧でないものに変えることができます。文法をグリルに乗せるのか、それとも今夜は夕食を食べるのか？コンマがなくても、おそらくもう理解できているでしょう。
さて、私たちは常にプログラミング言語を通じてマシンとコミュニケーションをとってきました。なぜなら、それらは正確だったからです。マシンに何をさせたいのかを正確に指示することができました。しかし、今日のAI支援コーディングの世界では、私たちはますます自然言語でマシンとコミュニケーションをとるようになっており、それは曖昧です。ですから、その言語の曖昧さを減らし、人間の曖昧さを減らすメカニズムを開発する必要があります。そうすることで、マシンがロジックを作成できるようになります。
仕様は曖昧さを減らします。そして、私たちの歴史は仕様駆動開発の物語で満ちています。Dijkstraの構造化プログラミング環境は、実装する前にプログラムの正しさを証明する形式仕様に基づいていました。Apollo Guidance Systemは、145,000行のコードを導いた綿密な仕様に依存していました。それは非常に正確な設計図で、人類を月に着陸させるのに役立ちました。そして、仕様についてさらに詳しくお話しするために、KiroチームのシニアプリンシパルデベロッパーであるClare Liguoriをお迎えしたいと思います。Clare、お願いします。
Clare Liguoriが語るKiro IDE：仕様駆動開発とラピッドプロトタイピング
ありがとうございます、Werner。昨年のある時期から、私はバイブコーディングをすればするほど、コミュニケーションの問題があることに気づき始めました。AIに何をしてほしいかを説明するのに、ますます多くの時間を費やすようになっていました。AIが生成するコードは良かったのですが、最終的なソフトウェアは私が望むことをしてくれませんでした。私はしばしば新しいプロンプトで最初からやり直し、もう一度試してみることがよくありました。
時間が経つにつれて、私はソフトウェアが何をすべきかを定義するために、より長く、より詳細なプロンプトを書くようになっていることに気づきました。私はこれらの長く詳細なプロンプトをObsidianやMarkdownで書いて、それをコーディングアシスタントにコピー&ペーストしていました。私は本質的に、AIに自分が望むものをより良く伝えるための仕様書を作成していたのです。ソフトウェア仕様書は、システムがどのように動作すべきか、何をすべきで何をすべきでないかを明確に伝えることができます。
そしてWernerが言ったように、歴史上の多くのシステム、例えばApolloミッションなどは仕様書に基づいて作られてきました。仕様書こそが、私のコーディングアシスタントとのやり取りに欠けていたものだと感じました。しかしその時、私は考えました。この仕様書をプロンプトとして使うというアイデアをどう活用できるだろうか？仕様駆動開発とはどのようなものになるだろうか？そしてこのひらめきが、私たちをKiro IDEの開発に着手させることになったのです。
しかし、このアイデアを持って、私たちは新たなコミュニケーションの課題に直面しました。このアイデアを潜在的なユーザーにどのように伝え、検証すればよいのか？私たちはそれがどのようなものになるかわからず、ユーザーが何を望んでいるかもわかりませんでした。また、仕様駆動開発が何であるかを説明するのもやや難しいものでした。彼らはそれを見たことがなく、私たちもまだ構築していなかったのです。自分のアイデアを伝える最良の方法の一つは、ユーザーが見て触れることができるプロトタイプを素早く構築することです。ラピッドプロトタイピングは、もちろん新しいアイデアではありません。パンチカードの時代、60年代に戻ってみましょう。
1964年、SRIのDoug Engelbartは、底に車輪がついていて、それをテーブルの上で滑らせてコンピュータ画面上の何かを指し示すデバイスの大まかなアイデアを持っていました。おそらく私たちは皆、このデバイスを頭の中で思い描くことができるでしょう。しかし、60年代に戻って、この人にマウスとは何かを説明しようとすることを想像できますか？ Engelbartのチームは木のブロックからプロトタイプを素早く作りました。それは底に車輪があり、上にボタンがついた木製の筐体でした。そしてこの粗削りなプロトタイプは、どんな図面や説明よりも優れた方法でマウスとは何かを伝えました。それは人々が手に取ることを可能にし、そのコンセプトを即座に理解させました。それは優れた人間工学を持ち、手に素晴らしくフィットしました。
マウスと同様に、Kiroにとってラピッドプロトタイピングは極めて重要でした。私たちは、spec-drivenな開発の人間工学、つまり開発者の手にどう馴染むかが重要になることを理解していました。私たちはspec-driven開発がどのように機能するかについて、考えられるプロトタイプを素早く構築し、それらのプロトタイプを社内ユーザーの手に渡して、毎日Kiroを使ってもらうようお願いしました。それが、何が良い感触で何がそうでないかを理解するための最良の方法だったのです。
これは、AIが今私たちのために何ができるかを示す素晴らしい例です。AIはソフトウェアのラピッドプロトタイピングを根本的に可能にしました。過去には、私たちは皆、単一のアイデアを手作業でコーディングするのに何ヶ月も費やしてきたと思いますが、今では数分で実際に動作するプロトタイプをユーザーに提供し、何が正しく感じられるかについてフィードバックを得ることができます。Kiroを素早くプロトタイピングすることで、KiroでKiroを構築することさえできました。Kiro IDEの最初のプロトタイプはコーディングしかできませんでしたが、その瞬間から、Kiro IDEを使ってKiro IDEのコードを生成できるようになったのです。そしてKiro IDEを使って製品を構築することで、spec-driven開発がどのように機能するかについて、多くのアイデアを反復することができました。
一つのアイデアは、test-driven developmentのspecでした。TDD技術からインスピレーションを得て、望む変更を記述すると、Kiroが記述した動作を検証するためのテストを生成します。そしてKiroがアプリケーションコードを生成し、それらのテストに合格することを確認するのですが、開発者がテストだけでは、ソフトウェアに何をさせたいか、どのように見せたいかのニュアンスを常に捉えられるわけではないことがわかりました。私たちは、WernerがApollo Guidance Systemについて説明したような、従来の技術仕様書を試してみました。それらはシステム全体と各コンポーネントを詳細に記述していました。これにより、全体のspecに新しい機能を追加すると、Kiroが記述した変更に基づいてコーディングタスクを開始します。
これらのspecは、AIにとって、そしてコードベースにあまり詳しくない開発者にとっても、素晴らしいコンテキストでした。しかし実際のプロジェクトでは、時として圧倒的に長くなってしまい、この長いspecのどこに新機能の変更を入れるべきかを把握するのが難しくなりました。
私たちは一歩下がって、チームとして既にどのように働いているかを見直し、新しい機能のアイデアを得ました。それを記述し、製品要件を検討し、設計ドキュメントをレビューし、スプリントタスクを作成する。そして、おそらくspecも同じパターンに従うことができるのではないかと考え、それがfeature-driven specsになりました。
私たちはフローを3つのドキュメントに分けました：requirements、designs、そしてtasksです。そして、これにより開発者がAIをより制御でき、望むことをより良く伝えられることがわかりました。これらすべてのラピッドプロトタイプは、今日のKiro IDEにあるspec-driven開発ワークフローにつながる重要なユーザーフィードバックを私たちに与えてくれました。Kiroにspecワークフローが整ったことで、製品の構築を続けるためにより効果的に使用できるようになりました。なぜなら、今では望むことをAIにより正確に伝えることができるようになったからです
ライブコーディングでは、AIに対して非常に曖昧なタスクを与えることがよくあります。例えば、ウェブトリビアゲームを作ってくれと言うかもしれません。そしてこの非常に短いプロンプトから、おそらく百万通りもの異なる最終結果が考えられます。しかし、その中であなたの頭の中にあるものはおそらく一つだけでしょう。ライブコーディングでは、AIはあなたが何を意味したのか最善の推測をします。コードを生成しますが、それによってあなたは元々意図していたことではなく、コードに対してAIと反復作業をすることになります。spec-driven developmentでは、specsを通じてより正確に自分の意図を洗練させる機会があります。Kiro IDEに同じ曖昧なタスクを与えることができますが、すぐにコードに飛び込む代わりに、まず要件、設計、タスクを生成します。
そして、それらがあなたの頭の中にあるものと一致しない場合、Kiroに変更を依頼して洗練させる機会があります。spec-driven developmentを使ってKiro IDEで構築した本番機能の実例を見ていきましょう：システム通知です。
私たちは、Kiro IDEの初期バージョンで自分たち自身が経験した小さな不便さから始めました。エージェントがコーディング作業を完了するのに時間がかかることがあり、その間に私たちは別のアプリに切り替えていました。しかし、エージェントがユーザー入力を必要としたり、作業を完了したりしても、私たちが他の作業をしている間にそこでアイドル状態になっていることに全く気づかないのです。そこで、エージェントが注意を必要とするときにユーザーに通知する機能を構築することにしました。
まずKiroにspecを生成してもらいました。生成された要件は実際に、どのエージェントアクションがユーザーへの通知をトリガーすべきかなど、いくつかの詳細を考える助けになりました。設計フェーズに入ったとき、これはKiroエージェントコードへのかなりシンプルな統合になると予想していました。しかし代わりに、Kiroは非常に複雑な設計を生成し、エージェントコード内に直接まったく新しい通知システムを構築するものでした。
もし私たちがこれをvibe codingしていたら、実際には望んでいなかった大量のコードを作ることになっていたでしょう。しかし代わりに、specプロセスによって、これが当初考えていたよりもはるかに大きなプロジェクトであることを素早く認識できました。私たちはspecを反復して、まずエージェントコードの外部に通知システムを構築することに焦点を当て、基盤となるIDEコード内に直接構築することにしました。これはElectronのネイティブ通知APIの上に構築する必要がありました。
Kiro IDEはCode OSSをベースにしており、これは10年にわたる開発と200万行のコードにまたがるコードベースです。どの開発者にとっても、このコードベースのどこに変更を加える必要があるかを把握するのは難しいことがあります。しかし、Kiroのspecワークフローは、実際にこれらの変更をどこに加える必要があるかを探索し理解するのに役立ちました。そして、これらの変更が実装されると、私たちは再びspec駆動開発を使用して、それをエージェントコードに統合することができました。
のプロジェクト全体を通じて、私たちはAIから望むものを正確に得られるまで、specを素早く反復することができました。spec駆動開発により、私たちは自分たちでコーディングした場合の約半分の時間でこの機能を出荷することができました。Kiroを構築する経験の中で、私たちはAIがコミュニケーションの方法と反復の速度を変えたことに気づきました。私たちはspecを通じてAIとコミュニケーションすることでソフトウェア設計を反復でき、実際に動作するアプリケーションを素早くユーザーの手に渡してフィードバックを得ることで、ソフトウェアが何をするかを反復できます。
AIとspec駆動開発は、より良いKiro IDEを構築するのに役立ちました。そしてこれは主に、迅速なプロトタイプを通じたユーザーとの、そしてspecを通じたAIとの、より正確なコミュニケーションによるものでした。自然言語は高い曖昧性を意味する必要はありません。そして個人的に、これがKiro IDEを特別なものにしていると私は考えています。Kiro IDEは自然言語に精度をもたらします。それでは、Wernerに戻します。
ルネサンス デベロッパーの第四の資質：オーナーシップとソフトウェア品質への責任
ありがとう、Claire。Claireが示したように、コミュニケーションは非常に重要です。それはミスの少ないシステムにつながります。私自身の若い頃の話をさせてください。私がコンピューターサイエンスの学校に通っていたとき、Interview Techniqueという授業がありました。そして私は、なぜインタビュー？と思いました。ジャーナリストとかそういうことを考えますよね。いいえ、それは顧客と話す方法を学ぶためのもので、彼らが本当に何を望んでいるのかを理解しようとするためのものでした。なぜなら、彼らはテクノロジーについて何も知らないのに、テクノロジーソリューションを持ってあなたのところに来るかもしれないからです。
最近、顧客に会う時に「GenAI で何をすべきですか？」と言われることは 初めてではありません。そして、本当に 深く理解しようとするトレーニングを受けているので、申し訳ありませんが、あなたの質問に質問で答えさせてください。なぜあなたはそれを私に聞いているのですか？ほとんどの場合、その理由は取り残されることへの恐れです。ですから、顧客と本当に深く掘り下げて、彼らが解決したい問題は何か、彼らが見ている機会は何かを理解すること、これらすべてが私たちエンジニアが持つべきコミュニケーションなのです。
それでは、ルネサンス デベロッパーの4つ目の資質である、オーナーシップについてお話しします。これまでにも触れてきましたが、今日はその中の一つの側面、つまりソフトウェアの品質に対するオーナーシップに焦点を当てたいと思います。AIによって、私たちはこれまで以上に大規模なシステムを構築し、より多くのアイデアを探求し、かつてないスピードで前進できるようになります。これらのツールは、現代の哲学者であるDaft Punkがかつて言ったように、より困難に、より良く、より速く、より強く構築することを助けてくれるでしょう。そして、これらのツールを正しく使えば、高品質なソフトウェアを生み出すことができます。しかし、一部の開発者がこれらのツールを使い始めている方法には、リスクがあります。Vibe codingは構いませんが、何が構築されているかに細心の注意を払う場合に限ります。IDEでレバーを引いて、何か良いものが出てくることを期待するだけではいけません。それはソフトウェアエンジニアリングではなく、ギャンブルです。そういうことはVegasのどこかでやるべきです。
冒頭で申し上げたことを思い出してください。仕事はあなたのものであり、ツールのものではありません。もしあなたが規制要件の対象となっている場合、例えば医療、金融サービス、その他何であれ、規制要件に違反するコードを作成したとして、規制当局に行って「ああ、それはAIがやったことです」とは言えません。いいえ、それでもあなたの責任なのです。仕事はあなたのものであり、ツールのものではありません。
さて、私たちの仕事の性質は変化しています。生成が非常に速いため、書くコードは少なくなるでしょう。しかし、理解には時間がかかるため、レビューするコードは増えるでしょう。自分でコードを書くとき、理解は作成という行為と共にやってきます。しかし、マシンがそれを書くとき、あなたはレビュー中にその理解を再構築しなければなりません。これは検証負債と呼ばれるもので、この新しい作業スタイルについて開発者と話すときに聞く2つの主な課題の1つです。AIはあなたが理解できるよりも速くコードを生成できます。コードは瞬時に到着しますが、理解はそうではありません。このギャップにより、ソフトウェアは誰もそれが実際に何をするのかを真に検証する前に、本番環境に向かって進んでしまうのです。
2つ目の課題は、もちろんハルシネーションです。Claireが先ほど完璧な例を示してくれました。モデルは自信ありげに見えるデザインを生成しましたが、アーキテクチャに対しては完全に間違っていました。一部のAPIは変更され、LLMは存在しない属性を発明します。時には、完全に不適切だったり、過剰に設計されたソリューションを提案したり、あなたのシステム独自のパターンを無視したりします。これらの出力はもっともらしく見えますが、現実に基づいていません。この点については進歩していると思います。私たちはspec-driven developmentのようなプラクティスを開発しており、Claireが示したように、それが品質を劇的に向上させることができます。Byronの基調講演では、Kiroのようなツールが実際に仕様を使った自動推論を使用して、検証されたコードを作成できることを示しました。彼はまた、AWS APIに対して生成されたコードが正しいことを保証するために、自動推論を使用できることも示しました。また、多くの開発者がCI/CDパイプラインを見直し、より多くの自動テストを構築しているのも見ています。これらはすべてメカニズムの一種です。
この点については進歩していると思います。私たちはspec-driven developmentのようなプラクティスを開発しており、Claireが示したように、それが品質を劇的に向上させることができます。Byronの基調講演では、Kiroのようなツールが実際に仕様を使った自動推論を使用して、検証されたコードを作成できることを示しました。彼はまた、AWS APIに対して生成されたコードが正しいことを保証するために、自動推論を使用できることも示しました。また、多くの開発者がCI/CDパイプラインを見直し、より多くの自動テストを構築しているのも見ています。これらはすべてメカニズムの一種です。
ここで、変化を起こしたいと思います。この2つのことを本当に理解していただきたいのです。メカニズムと善意があります。それらは同じものではありません。それを説明するために、再び少し過去に戻って、Jeff Bezosについての話をさせてください。Amazonの初期の頃、経営幹部は毎年2日間カスタマーサービスで顧客からの電話対応をすることが義務付けられていました。それは、私たちが顧客が何を経験しているのかを真に理解するためでした。
そして私たち下っ端の経営陣だけでなく、Jeff自身もです。それでJeffはこのカスタマーサービス担当者の隣に座り、電話が鳴ると、自動化システムがすでにこの顧客の注文履歴を表示します。顧客が何か言う前に、カスタマーサービス担当者がJeffに言うんです。「彼女はテーブルを返品するつもりです」と。そして実際、顧客は破損しているのでテーブルを返品したいと電話してきました。電話が終わり、Jeffは担当者を見て言います。「どうしてわかったんだ?」彼女は言います。「ええ、あのテーブルの70%が返品されているんです。梱包の仕方を本当に知らないドロップシッパーがいるからです」
もちろん、Jeffはみんなを部屋に集めて考え始めます。みんな良い意図を持っているんです。もちろん私たちはこんなことが起きてほしくない。でもメカニズムがなければ、何も変わらなかったんです。なぜならみんなすでに良い意図を持っていたからです。そこで彼は新しいメカニズムを導入しました。Amazonバージョンのトヨタの有名なアンドンコードです。トヨタのアンドンコードは、既知の欠陥がある車は生産ラインから出してはいけないという原則に基づいており、ライン上で作業するどのエンジニアもこのコードを引いて、欠陥が修正されるまで製造ライン全体を停止させることができました。
カスタマーサービス担当者が得たアンドンコードは、製品を利用不可にするボタンでした。それによって製品の責任者にアラームが鳴り、彼らが行って修正するんです。でもこれ以前は、みんなすでに良い意図を持っていました。でもメカニズムを導入するまで、何も変わらなかったんです。では、私たちのテクノロジーの世界に戻りましょう。メカニズムは多くの形をとります。各チームは、自分たちの作業の規模と性質に合った独自のものを構築します。
例えば、S3チームは、durability reviewsと呼ばれるものを使っています。エンジニアが耐久性に影響を与える可能性のある変更を提案すると、彼らは一時停止してリスクをモデル化します。変更を書き留め、想像できるあらゆる脅威をリストアップし、データを安全に保つためのガードレールをマッピングします。これは非常に強力な効果を持つメカニズムです。耐久性をコードの特性から組織の習慣に変えるんです。エンジニアに、ハッピーパスではなく、障害モードで考えさせます。そしてこれがメカニズムが重要である理由を示しています。メカニズムは良い意図を一貫した成果に変換するんです。
さて、考えてみると、コードレビューもメカニズムです。そして私たちはみんなコードレビューが嫌いですよね。12歳でクラスの前に立っているようなものです。でもこれらは非常に重要なメカニズムなんです。なぜなら、意図と実装が出会う瞬間を作り出すからです。そこで別のエンジニアが前提に疑問を投げかけ、作成者がもはや見えなくなっているものをキャッチできるんです。AI駆動の世界では、これらはこれまで以上に重要です。AI駆動の世界では、これらは極めて重要です。モデルは私たちが理解できるよりも速くコードを生成できます。だからレビューがバランスを回復するための制御ポイントになるんです。
ここで人間の判断をループに戻し、ソフトウェアが実際に期待通りに動作することを確認するのです。皆さんには、人間同士のコードレビューを継続し、増やしていくことをお勧めします。シニアエンジニアが一緒にコードを検討する時、それは私たちが持つ最も効果的な学習メカニズムの一つになります。シニアはパターン認識と苦労して得た判断力をもたらします。ジュニアは新鮮な目をもたらし、他の人が見落とす詳細にしばしば気づきます。これが知識を伝達する方法であり、次世代のビルダーを育てる方法なのです。AIは多くのことを変えるでしょうが、技術は依然として人から人へと学ばれるものです。私が考えるルネサンス デベロッパーの4つ目の資質はオーナーであることです。あなたが作ったものは、あなたが所有する。
ルネサンス デベロッパーの第五の資質：博学者（ポリマス）になる
さて、最後にお話ししたい資質は、未来のルネッサンスである皆さんは、博学者になる必要があるということです。さて、博学者は数学とは何の関係もありません。mathematicsやmathsとか、何と呼ぼうとも関係ありません。博学者という言葉はそれとは何の関係もないのです。実際には「多くの」という意味で、「math」はギリシャ語の「mathein」から来ており、これは学ぶという意味です。深いドメイン経験を持つことですが、同時に多くの異なる分野にまたがる知識を持つことでもあります。Da Vinciはおそらく博学者の最高の例でした。なぜなら彼は非常に多くの異なる分野で活動したからです。彼は画家であり、エンジニアであり、解剖学者であり、発明家でした。
さて、皆さん全員がDa Vinciになることを期待しているわけではありませんが、深いドメイン専門知識を超えて知識を広げるべきです。これを私はI型デベロッパーと呼んでいます。I型デベロッパーとは、一つの分野で本当に深く、本当に高度に専門化している人のことです。
私自身の経験から、また興味深い話をさせてください。これは私の昔のメンターで友人のJim Grayです。JimはTuring Awardを受賞しました。なぜなら、実際、皆さんはJim Grayを知っているべきです。彼はトランザクションの発明者だからです。今日皆さんが行うすべてのトランザクションは、Jimに感謝すべきものですが、彼はまた素晴らしい頭脳を持っていました。彼はデータベース以外の多くのことに興味を持っていました。そしてこれが彼の有名なチャレンジの一つです：データに対して尋ねたい20の質問、20の重要な質問を教えてください、そうすればあなたのためにシステムを設計しましょう、と。
彼が最初に取り組んだものの一つがSloan Digital Sky Surveyでした。これは当時存在した最初の大規模データセットの一つでした。Sky Surveyの開発における画期的な仕事でした。データベースエキスパートとしてのJimの深い知識は、天文学データの計算に変革をもたらしました。実際、それについて本当に面白い話があります。ある時JimはグループがいるBaltimoreに行き、サーバールームに入ります。30秒後に彼は出てきて、データベースのレイアウトが間違っていると彼らに告げます。そして全員が彼を見て、どうしてわかるのですか？と言います。ディスクのガタガタという音を聞いただけで、彼はランダムアクセスが多すぎることを知ったのです。何十年もの経験から培われたこの直感が、彼にシステムがどう振る舞うべきかという第六感を与えていたのです。彼はアーキテクチャを再設計するようアドバイスし、パフォーマンスは劇的に向上しました。
さて、Jimは私がいわゆるI型開発者とは全く呼べない人物でした。彼の好奇心はデータベースをはるかに超えていました。彼は人を理解し、ビジネスを理解し、そして幅広い技術を理解していました。偉大な技術者と同様に、彼をT型と表現します。つまり、一つの領域では深く、しかし理解は広いということです。あなたの仕事で成功するために必要なスキルは、個人的なスキル、機能的な深さ、そして業界知識のユニークな組み合わせです。フロントエンドのパフォーマンスやコストを理解しているデータベース開発者は、アーキテクチャがより良いアーキテクチャの選択をすることができます。なぜなら、彼らは自分の仕事がシステム全体をどのように形作るかを見ているからです。
その幅広い知識は、トレードオフを理解しているため、構築するものを改善する視点を与えてくれます。T型開発者は深さと広さを組み合わせています。彼らは特定の問題に深く潜り込むことができますが、それがより大きなシステムにどのように適合するかも理解しています。これが皆さんへの私のアドバイスです。両方を構築してください。自分の領域で深さを養い、しかし複数の分野やアイデアとつながるための幅も育ててください。
ですから、ルネサンス デベロッパーからの最後の教訓は、博学者（博学者）になるということです。まあ、皆さん全員がそうなることを期待しているわけではありませんが、チームを広げるべきです。偉大な開発者はT型です。彼らは自分の分野の専門家であり、自分の仕事がより大きなシステムにどのように適合するかを理解しています。あなたはチームを広げなければなりません。さて、この講演を通してルネサンス デベロッパーを見てみると、私は彼らをさまざまな方法で呼んできました。好奇心を持ち続け学び続けること、システムで考えること、正確にコミュニケーションすること、オーナーであること。作ったら、それを所有するのです。そして最後に博学者になること。知識を広げることです。
目に見えない仕事への誇り：Werner Vogelsからの最後のメッセージ
来週、これらすべてを実践し始める時間はたっぷりあります。しかし今夜は、Las Vegas Festival Groundsで私と一緒に楽しみましょう。素晴らしい食事、クレイジーなゲーム、そしてもちろん、BeckとKaskadeをヘッドライナーとするライブミュージックがあります。真剣な学習と構築の一週間の後、チームと一緒に祝い、リラックスするチャンスです。
さて、今年皆さんに残したいことがもう一つあります。アプリのようなものを構築するとき、お客様はその下にあるすべての作業について考えることがあるでしょうか？Amazonのお客様はボタンをクリックすると荷物が届きます。彼らは実際にカタログを管理している人々、サプライチェーンを担当している人々、そのすべての作業について考えるでしょうか？誰もそれを見ていません。お客様は、あなたのデータベースエンジニアが素晴らしい仕事をしていて、彼らがやったことを気に入っているとは決して言ってくれません。それに費やされる作業を理解しているのは、あなただけなのです。
私は、私たち全員が自分の仕事に誇りを持つことが重要だと信じています。夜通し稼働し続ける目に見えないシステムに、クリーンなデプロイメントに、誰も気づかないロールバックに。私たちが構築するもののほとんどは、誰の目にも触れることはありません。そして、私たちがこれをうまくやる唯一の理由は、オペレーショナルエクセレンスに対する私たち自身のプロフェッショナルとしての誇りです。それこそが最高のビルダーを定義するものです。彼らは誰も見ていなくても、物事を適切に行うのです。そして、あなたたちが毎日提供している仕事を見ると、私はそのコミットメントをあらゆるところに見ることができます。ですから、そのことに対して、私はあなたたちを非常に誇りに思います。あなたたちがしてくれていることすべてに感謝します。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion