Transcription
皆さん、こんにちは。今回はAIの先進企業から、今後エンジニアがどういう役割やスキルを求められるのかという点について、アンソロピックとギットハブそれぞれで参考になる資料がありましたので、そちらから、え、皆さんにシェアをすることで価値の高そうな内容がいくつかありましたので、今回それをご紹介できればなと思います。
アンソラピックとアンソラピックのレポートがこれですね。2026年のエージェンティックコーディングトレンドレポートというやつで、え、ギットハブの方が、ま、え、開発者の、ま、働き方とかマインドセットの変化、移り変わりを調査したレポートがありまして、そちらを元に、ま、共通する部分もたくさんあ、あるので順番にご紹介していきます。
まずアンソロピックからいきたいんですが、アンソロピックは、ま、皆さんご存知かなと思うんですが、え、クロードコードを開発している企業ですね。で、まず、え、ページの5ページ目で、こちらの資料の5ページ目の方でソフトウェアの開発サイクルがAIによって劇的に変化するという風に書いています。その中でエンジニアの役割の変化っていうのが結構大ターンな変化がありまして、エンジニアはより今よりも上流へ流工程シフトしていくと、そしてシフトしていくべきであるという風に書いていました。
メインで上流工程にシフトするというのはどういうことかと言うと、メインのタスクが行動コーディングからエージェントを管理する統括する作業に変わるということですね。つまり、ま、AIエージェント使うので、その出力を人間が評価して妥当性を見て、え、戦略的な方向性を示し、システム全体が正しい問題課題を解決することを人間が保証していく、担保していく、責任を持つっていうことですね。
で、変わるのはエンジニアの変化、エンジニアの役割の変化だけではなく、エンジニア組織チームの構成とかリソース配分人員配置この辺りも大きく変わっていくだろうという風に書いています。ま、それもそのはずで、AIによって例えばオンディング新しい人がサインされる時なんかには今まで数週間かかっていたものが数時間で完結するであったりとか、ま、いろんなところでやっぱり人材配置の適切な振り分け方とか調整最適化プロジェクトリソースの考え方っていうのがガラっと変わってきたなっていう風になっていますね。ま、今やっていることに対しての人数が多すぎる、全体的に人数が多すぎるっていう風になる傾向があるのかなと思いますね。なので同じ組織でもより小人数高密度な体制へ再変される可能性があるということについても触れています。
ただし、え、AIエージェントと人間は共同すべきであって、AIによってエンジニアが不要になるということではないというのも抑えておく必要があります。ま、スキル面に関してもマインドセットに関してもこういうAIによって時代が映り、時代の移り変わりが激しいのでやっぱり現状維持っていうのは危険であると、現状維持のままの意識ではAIに置き換えられるエンジニアも一定存在してしまうっていうのが、ま、これは現実ですね。ま、こういった役割の変化とかに対応できないジニアっていうのはAIに到達されていくっていうことですね。
ま、エンジニアはより工程で行くと、ま、火流から上流に行き、さらにフルスタックに振る舞う必要があるということですね。ま、フルスタックに踏まう必要があるっていうのはどういうことかと言うと、例えばフロントエンドだけしかできないとか、バックエンドだけしかできないとか、インフラだけしかできないとか、そういう考え方とか働き方は、ま、今後あんまりAI時代には適合してないという風に言えるのかなと思いますね。ま、幅広く全体をできできてなおかつ1つあるいは複数の専門的な知見体経験がある。ま、こういったエンジニアがAI時代に適合できる仕事を行う上ではAIを前提とした仕事の進め方ができるということですね。
で、え、まとめますとエンジニアは行動を書く人から、ま、AIエージェントを統括し、幅広く上流工程から一貫して対応し、最終的にAIエージェントの出力をに責任を持つ、こういう人が、ま、求められてくるということですね。で、やっぱり個人的に重要だと思うのは、やっぱりいろんなこのアンソラピックのこのレポートに限らず、いろんなところでとにかく言われてるのはやっぱこの実装者からエアエージェントのオーケストレーターになるべきであると。で、先進的な企業はもうすでにそうなっているという風に書いていますね。
ま、やっぱ実装量アウトプットよりもアウトカムを重視したアーキテクチャー設計やエージェントを前提としたアーキテクチャ設計とかタスク分解課題解決問を立てたりとかユーザー価値とかあとエアエージェントの品質に品質を評価し責任を担保する責任を持つま、エアエージェントをオーケストレーションしうまくいかいかなかった部分に関してフィードバックをしよりこう改善していって能力であったりとか、ま、あとは、え、ま、1つの分野だけではなくて、幅広い分野でなおかつ複数機能を同時に開発行うことができ、広い範囲でAIを前提とした仕事ができる人、ま、こういう人が必要になって、求められてくるのかなと思います。
で、これが、え、ソフトウェア開発ライフサイクルの変化になるんですが、続けてP8のところで、え、単一エージェントが、え、連携チームへと進化したということも同時に書いてますね。え、AIが出た当時初期の頃っていうのはチャット型のインターフェースで1対1人間とAIが1対1で解放するだけの構成だったんですが、ま、難しいタスクとか、ま、AIを業務に組み込んだり、AIネイティブな組織を作るとなった場合には、ま、このチャット型インターフェースだけではなかなか限界があると。で、そういった時に2026年には複数エージェントが連携して複雑なタスクを処理するというのが、ま、登場してきたということですね。
ま、主にはプランナー、計画を立てるプランナーとか調査するリサーチャーとか実装を行うコーダーとかジェネレーターでテストを行うテスターとかでレビューを行うレビューアーとか役割を専門化して連携して成果を最大化していくとでそれらを統括式するのは人間であるということですね。で、こういった中で必要なスキルとしてはタスク分解、エージェントの専門家、ま、AIに対するキャッチアップで必要な環境としては、ま、複数のエージェントを並列で動かすので、それらを、ま、見える化したり管理したり、ガードレールを準備したり、ハーネスを構築したりっていうことができる開発環境を作れる人であったり、必要なワークフローとしては、ま、並列でもちろん作業を行わせることになるので、え、それぞれが、ま、コンフリクトしたりとかバッティングしたりしないように並列の良さを最大限かせるワークフローを作り上げることができたりとか、ま、Gitubと組み合わせたバージョン管理を行うことができたり、こういったところが、ま、必要な求められてくるところになるのかなと思います。
で、現時点では今このところないですが、ま、将来的には非エンジニアでもオーケストレーション可能なUIとかに、え、ま、進化してくる可能性もあるのかなと私個人的には思っています。ま、なかなかクロードデスクトップのチャットのUIとかだけだ。あれに関しはサブエージェントとか使えないんですが、ま、クロードコードの方が使えるんですが、ま、ああいうのも、ま、結構一般、一般層、ライト層だったり、非エンジニアに対してもタスクの難しさにによってはサブエージェントを起動させることが定義させたり起動させることができたるんじゃないかなとは見ています。
で、さらに、ま、AIエージェントをこう使っていくと人間とAIのコラボレーションを通じて人間の監視体制が強化されるということも言及されています。やっぱりこうAIが大量のアウトプットを生み出せるようになる、高速で大量のアウトプット出せるようになる一方で、ま、人間の数っていうのはもちろん限られているので、生きつくところは人間のレビューがボトルネックになりやすい。ま、もしくは品質保証の部分がボトルネックになりやすいですね。なので人間によるレビューをAIでできるだけ減らしていく仕組み作り、0に近づけていく仕組み作りっていうのが、ま、今重要になっていて、これからも重要になるのかなと思います。
そのためには、ま、AIの自己評価の甘さとか特性とかを理解しつつ、今使っているモデルの特性特徴、どういうプロンプが効くのか効かないのか、どういう機能が使えるのか、え、組織全体でレビューをスケールさせていくための仕組み作りもAIを使うことと同時、AIで何かを作ることと合わせて、ま、それ以上に重要であるということですね。一応見ておきますと、丸1のところでAIが大量生成できるようになりましたが、ま、並列で実行したりとかっていうので大量にコード、ソースコードであったり、成果物、ドキュメントとかいろんなものを作れるようになったんですが、ま、ここを理想的にはAIが自動でレビューし、ま、体感では80%から90%ぐらいの品質保障、セキュリティ面での贅沢性のチェックなどを完了した上で、人間が重要な箇所、本当に重要な箇所とか見落としてはいけない場所とかを重点的に場所を限定して重点的に確認できるような仕組み作りとか、ま、人間が確認しやすいような仕組み作りとか、ま、あるいは、え、レビューのAIがレビューする段階でAIに対して成功基準と検証方法を、ま、与えてあげるっていうのが、ま、今注目されているアプローチになりますね。なのでこの辺りを何も整備せずにひたすらにこうAIによるアウトプットだけを増やしても、ま、思ったようにスケールしないとかっていうのは、ま、いろんな企業で起きたり起きたりしてるのかなとは思います。
続いてP17の方では、ま、今後1年間どういうことが重要になってくるのかなっていう部分をまとめて書いてるところがあるんですが、まあまあ繰り返しになりますが、え、ソフトウェア開発は行動各活動から行動各エージェントをオーケストレーションする活動に移行しつつあるということだったり、そのオーケストレーションを構成する中で、きっちんとレビューアーに相当するような、え、チェックを行うためのエージェントに必要な検基準と検証方法などを与えることによってきちんとした質の高いアウトプットを出させるこういう仕組み作りも合わせて必要になるということに加え、ま、やっぱりAIは常に人間と共同していく存在であるということを、え、意識した上でAIに置き換えられないようにするためにはどういう部分に力を入れてどういう意識でどういうスキルを身につけていけばいいのかっていうのをきっちんと認識しておくていうことも重要ですね。
じゃ、これらを踏まえた上でネクストアクションとして何をすべきかという話なんですが、ま、ここまで何度も出ているのである程度重複した内容にはなってしまいますが、まず1つ目として単一エージェントでは対応できない複雑さに対応するためにマルチエージェント強調オーケストレーションの構成のための機能であったり概念あとはそれを実践していくということをまやっていく必要があるかなと思います。
2つ目がこのオーケストレーションの中でAIが自動でレビューするシステムを同時に作り上げる。そして、え、AI生成薬とレビュー役がこうフィードバックループをAIが自動で回せるように検証手段、検証基準と検証手段を与えてあげる。言語化して人間が指示してあげるっていうことも必要ですね。ま、検証手段とか成功基準とかこうなればクリアアっていうのを与えずに、ま、曖昧な指示を出している間は、ま、いつまでだってもこういった、ま、AIを使って生産性を向上させるっていうことはなかなか難しいのかなと思います。
さらに3つ目として、ま、エンジニアはエンジニアリングの枠を超えてやっぱりこう工程も上流から入る必要がありますし、ま、さらにこうどうしてもこう実装をコーディングをしたいっていう、ま、人も中には結構いたりするかなとは思うんですが、ま、今後AIにAIと勝負するっていうのはかなりナンセンスなので、ま、必然的にコーディングフェーズっていうのはAIに任せて上流の部分をもっと行うようにしつつドメイン知識だったりユーザーの解像度なんかも上げていく作業も必要ですしも横断しつつ自分の領域に収まらない。ま、本当にこう1人1人がエンジニアでありプロダクトオーナーでありみたいな感じで、え、振まっていく必要が、ま、あるということですね。ま、営業、マーケティング、保守、開発、ま、そういったところはもう本当に課金でなくやっていく必要があるのかなと思います。
で、4つ目は、ま、エアエージェントのシステムをこう構築していく上で初期段階からセキュリティやアーキテクチャーをセキュリティを担保するための仕組みも同時に入れていく必要があるということですね。認証認可データ保護なんかにあったり組織の管理設定であったりどんどんエアエージェントを使って自動化していくっていう部分ももちろん大事なんですが、ま、そのそれと同じぐらい重要なこのセキュリティ面の制御仕組み化っていうのも合わせてやっていく必要があると。それができて初めて仕組み化ができたという風に今言えるかなと思います。
で、最後に、え、このアンソラピックのレポートから得られるもののまとめとしては、まず役割がどう変化すべきかという点についてはエンジニアは実装車からオーケス、AIエージェントのオーケストレーになるべきであると。で、工程に関しては上流工程に移るべきで、ま、要件定義とか設計とか企画とかそういう段階、あ、あとは、ま、仮説を立てたりとか問を立てたりとか、ユーザー価値とか顧客の課題とかっていうのをを通っていく、立てていくっていうところから、ま、えっと、その問題課題を分解したり、あとは意思決定をしたり、AIの出力品質に責任を持ったりとか、こういうところに非重が移動していくし、移動していくべきであるし、そういったところをおろかにしているとAIエージェントと勝負しないといけないので、ま、それはあまりにも何センスだろうということですね。
で、AIの出力を、ま、評価するっていう役割は、まだまだ、え、どれだけこうAIエージェントによるフィードバックグループを作れたとしても、最終的に責任を持つのは人間なので、AIの出力を評価する役割とあとはそれを評価するためには専門、一定専門的な知識っていうのは引き続き必要で、そういった土台になる部分っていうのはもちろん、え、これまでやってきたことが無駄になるというわけではなく、これまで以上に重要になってくるということですね。
で、スキルに関してはタスクを分解してエアエージェントが理解しやすいように適切な流度に分けたりとか指示を出したりとかコンテキスト最適化を意識して指示をしたりとかあとはエージェントAエージェントのオーケストレーションの設計とか調整ハーネスの整備レビュー検証品質評価バージョン管理と共同フロー設計セキュリティを前提にしたシステム設計この辺りが求められてきますね。ま、これらを行うためにはそもそも日々のAI関連のツール情報のキャッチアップっていうのは、ま、マストになってくるかなと思います。ま、少なくともドキュメントに書かれている内容の60%70%以上を理解しスキルっていうのは必要かなと思います。ま、ただただただそのクロードコードとかコーデックスのチャットを起動してそこに、え、質問したり指示をしたり、え、ていうのをしているレベルではなかなか難しいのかなと思います。
あとはマインドセットとしては、ま、AIを人間の代替ではなくて共同相手として扱うであったりとか、ま、現状維持、え、今の自分自身の役割とかポジションのに囚われずに部門部署、分野を横断してより幅広い範囲と上流の工程から一期痛感でできるスキルで、え、何をするにしてもやっぱりこうAIを前提とした仕事の進め方。まず1番初めに考えるのはここはAIでできないかなとか。これはちょっとAIではちょっと難しいかなっていうその辺りの感所とか、え、姿勢、マインドセットっていうのも必要になるかなと思いますし、やっぱり任せるところは任せるAIが出力する、え、ものに対して信頼ができないので、やっぱり全部に人間がやってしまうっていう人も、ま、中には一点数いたりはするかなと思うんですが、そうではなくて、どちらかと言うと、え、AIが正しい出力をできるようにするために自分が使い方が使える機能をキャッチアップするとかどうやったらうまく出力できるのかなっていうのに方向にシフトしていくっていうことが重要かなと思いますね。
あとは、ま、個人1人が、え、こういう仕組みを作って自動化とか仕組み化をしたとしても、その効果っていうのは非常に小さいので、え、これをいかにチームに、チーム全体、組織全体に共有し、シェアし、成果を最大化していくかっていうことも、ま、求められるかなと思います。
え、ではアンソロピックのレポートの内容に続きまして、Gitubのこの興味深いブログの記事を見ていきたいなと思います。こちらの記事の内容としては、ま、AI時代に入ってどういう風にソフトウェアエンジニアリングのやり方とかエンジニア自身の振る舞いとかタスクの種類とかどういう変化があったのかっていうのを調査結果としてまとめたものになります。で、このアンソロピックのレポートとこのGitッubのブログから共通する部分も複数あるので、ま、今後どういう風にキャリアアップ、ステップアップしていけばいいのか、エンジニアとしてキャリアをステップアップしていけばいいのかっていう風に、ま、悩んでる方とか迷ってる方、は、ま、かなりヒントというか参考になる部分は、ま、多いんじゃないかなと思います。
で、まずGitHubはこのブログの中でエンジニアは行動で行動を書く人ではなくなるという風に言っています。AI時代には開発者はコードのクリエイティブディレクターになるという風に書かれていて、で、これはGitッハの研究チームの調査をもにAI開発で進歩した開発者の働き方の変化を4つの視点で整理したものになっています。
まず1つ目の視点としては、ま、コードの作成者からコードのクリエイティブディレクターに移っていくということですね。従来は行動を書く人、実装が中心、低量が価値とされてきました が、これは働き方とか技術の再想像として捉えることができ、これからのAI時代の変化としては実装ではなく行動の方向性を決めてAIエージェントに指示をする人、技術的な制約とか標準、アーキテクチャーを設計する人、取りまとめる人ですね。あとはオーケストレーションと検証のフィードバックグループの仕組みを作ったりするのが中心になるということです。で、重要なポイントとしてはAIによってエンジニアの仕事が奪われるというよりも実装はAIに移任し人間はその方向性を導いたり起動修正したりガードレールを設置したりいかにAIエージェントをうまく動かすかというところに注力するようになるということですね。
で、2つ目の視点としてはこのブログの中で色々こうエンジニアのギitアブの研究チームの調査の中ではエンジニアの働き方の変化とかを観察すると、ま、AIの成熟度という観点で4つの段階に分けれるということが書かれていました。まず1つ目、レベル1に関してはAI会議論者ですね。これは、ま、どちらかというとマインド的には、ま、AIに任せると信用ならないので自分自身でやった方がいいっていう風に、ま、ざっくり言うとそういう考え方をする人です。疑念深くて抵抗的でAIを実際試してみたが面倒と感じたり1発でうまく行かないと納得いかないとかそういう考え方のレベルにある状態でレベル2というの はAI探求者まレベル1よりもまAIに対する好奇心構成でより解放的なマインドを持っている。ただ使い方としてはそんな本格的に使うというよりかは自分のできることをでかつAIに任せたら方が効率的で成功率も高い。割と簡単面な作業をAIに任せて自分の作業を加速させるていう使い方。デバッグボイルプレートスニペッドなどですね。ま、こういうレベルにある状態の音を指しています。
で、レベル3として、ま、AI系のツールの機能をモ羅していたり、ま、公式ドキュメントなんかもしっかり読み込んでいて、機能の背景とか必要性とかそういったものをしっかり理解していて、使いこなせている状態、AIをうまく活用できている状態にあるというレベルの状態ですね。AIコラボレーターでレベル4がAIストラテジストと言って、ま、もう完全にAI前提で全ての仕事を進める。さらにはAIの出力を最大化する品質とか仕組み作りとか。ま、それ仕組み作りというのはもちろんその並列化AIエージェントを並列化させたり、フェードバックグループを構築したり、ガードレールを設置したり、え、セキュリティ面の制御をしっかり権限設定とか組織で使う時のプラクティスを知っていたりとか、その辺りのことを全てモーラできている、活用できている、さらに組織にそれらを展開できている。自分1人ではなくてもっとスケールするようにAIを活用できている。ま、そういったレベルにあるイメージなのかなと思います。
で、このレベル1にいる人ほどうまくこうAIをうまく使うためのそのAIの癖とか特徴とかを理解しておらずAIに指示したとしてもなんか自分の意図していたものと違うものが返ってくる。ま、1発で成功を求めようとしてるので、ま、そういう風になってしまうのと、あとは自分自身のそのエアに対するキャッチアップとか知っていることが少なすぎるので、ま、そういう状態になってしまうんですが、ま、割とレベル3とか4の人に関しては1発で行うとよりも何回もこう繰り返して指示をして感染に近づけていくっていうそういうこと、そういう必要性があることを理解している。つまりAIの限界っていうもの、AIのできることと同じぐらいAIの限界っていうのを理解している。つまりそれは自分自身が使って思考錯誤したり使い込ん でるのでAIの限界っていうのをある意味理解してる状態にあるのでそういうことがでるということですね。
で、3つ目のこの観点としてはちょっとこれあの少し離れがそれるっちゃそれですが、これなぜタイプスクリプトが2025年8月に1位になったのかっていう話で、ま、これ2025年の8月の段階の話なんですが、え、このタイプがGitubの月刊貢献者数で1位になったというデータがあります。で、これは単なる流行りではなくて、AI時代の戦略的な言語選択と非常に相関があるのではないかという話ですね。で、やっぱりこのタイプスクリプトという型定義が存在している言語でかつコンパイル言語なので、ま、このAIエージェントに与えるガードレールが、ま、同的片付け言語よりは、ま、コンパイルの時点でいろんな情報を与えれたり、エラーになっ たり、コンパイルがエラーになったりっていうことで早期にバグであったり、守られるべきルールっていうのを担保することができるように、もう構造的に言語使用としてなってるので、ま、やっぱりこのA時代に使いやすい言語として、ま、このタイプスクリプトの上昇っていうのが、ま、おずと高まってきているのかなというところで、ま、こういう話もこのブログのところには書かれていました。
え、4つ目の観点の学ぶべきは3つのスキルレイヤーということで、じゃあこれからのAI時代に適用するためにはどういうスキルを習得していく必要があるのかっていう話になるんですが、まずレイヤー1としてはいわゆる今行おうとしてる作業の理解ですね。コード書く前の判断軸の話で具体的には何を作るのかとかなぜ作るのかとかまずどういう課題があってその課題に対して技術でどう解決できるのかっていうのをちゃんと作業を理解できる力。これがレイヤー1としてまになるという話ですね。
で、それに加えて、ま、作業自体の理解も重要なんですが、まずAIに関する知識っていうのもまず必須になってくる。なぜかと言うと、ま、AIを前提とした仕事の進め方をできない人はこれからどんどんきつくなっていくので、ま、こういうAIに関する知識のキャッチアップっていうのは当然必要になってくる。で、キャッチアップするだけではなく、実際どんどん使っていって、AIが得意なところとか苦手なところをちゃんと理解していく、使い方をちゃんと理解していくっていうことが必要ですね。で、AIに関する知識としては、ま、特に苦手必要な根キスト量とか、ま、この作業を行うの時に、ま、こういうこれぐらいのトークン使うんだとか、あとアップデートに対しての追従とか、あとそのモデルの特徴とか、今後のアップデートの方向性の理解とか機能の背景とかっていうのをちゃんと公式ドキュメントとかを見ていくなりして追従していくっていうことが必要ですと。で、もちろんそういったキャッチアップも必要なんですが、やっぱ1番重要なのは自分自身で使うということですね。え、他の人の発信とか、ま、もちろん参考にはなるんですが、それを受けて自分自身が使わないと人から聞いた情報とかだけではなかなか試して実際に分かるものなので、ま、これは、え、自分自身が使うっていうことちゃんとするのが必要ですね。
で、AIエージェントに関する知識というのは、ま、これからこうな、何て言うんでしょう？複雑なタスク、ま、元々コード保管とか、ま、なんかちょろっとAIを使う、1部分的にAIを使ったりするだけっていう感じではあったんですが、これからはよりどんどん複雑なタスク、長時間実行するためのタスクっていうのをAIに任せていくようになっていくので、ま、それを実現するための、ま、AIだけのそのAIモデルだけの単体の性能に頼らないエアエージェントのオーケストレーション、ま、ハーネスの設計とかガードレールの設置とかっていうのは、ま、できるようにタスクごとに適切なアーキテクチャーをちゃんと組める設計力っていうのも非常に重要ですね。
で、2点目が技術の基礎です。で、やっぱりこのAIの複雑な出力とか、え、ま、ソースコードでも何でも良いかなとは思うんですが、ま、それに対して妥当性を判断する土台とか、ま、あの、足腰の強さみたいなものがないと、え、なかなかAIをうまく使いこなせないだろうという風に書かれていました。AIの複雑な出力を評価できる、評価したり妥当性を判断できるスキルっていうのが、ま、今後これよりもさらに重要になってくるということが書かれています。ま、やっぱりこのどれだけこうアウトプットを高速化できたとしても、ま、その妥当性を判断して、え、その品質とか、え、出力に責任を持つ、最終的に責任を持つのは、ま、人間であることにはまず変わりないので、ま、ここの評価とかをできる技術的な素とか基礎的な部分の能力っていうのは、ま、非常に重要ということですね。
で、3つ目が製品理解です。え、断編、断片的なコードではなくて、え、成果だったりシステム全体で考える視点っていうのが必要です。ま、ユーザーニーズとか要件定義、変更影響とかも広く幅広く、ま、視野が1つの部分、1つの領域、1つの部分だけを見るのではなくて、ま、全員がこうエンジニアでありプロダクトオーナーであるというような捉え方で、そもそも例えばこの機能を追加するのはどういうことが解決したくて、どういう理由でやっているのかっていう、ま、あの、仕事作業の理解っていうところにも関わってくるんですが、ま、これと、これに対して深く考えられる言われたことだけをするとかいうのはこれはもうAIエージェントの役割というか、AI、つまりエアエージェントと同じ土俵で戦っていかないといけないっていうのはかなり、え、きつすぎるので、ま、必然的にこういったエアエージェントには難しいところ部分ところの部分を担っていくっていうことが求められてきますね。で、これはあのアンソロピックのあのレポートの方でも仕切りに語られていた内容と結構重複している部分が、ま、多いのかなと思います。ま、上流工程に移っていくべきであるっていう点とかの辺りです。
で、レイヤー2としてはこの作業の式です。ま、AIを効果的に動かす技術です。1つ目としては移任とエージェントオーケストレーションですね。問題を明確タスクを分割して、え、必要な適切なコンテキスト、制約、成功条件、え、成功基準とその成功基準を満たすための手段を一緒に与えてあげる、言語化して人間が与えてあげるっていうところと、ま、バックグラウンドの実行でも全然問題ないであろうっていう作業と、ま、しっかりこう張り付いて見とかないといけないだろうなっていう作業とかの、ま、見極めと、ま、いかにこうバックグラウンド実行で、並列化させて作業をスケールさせていくかっていうところが、ま、重要なポイントですね。ま、さらに、ま、このオーケストレーションの仕組みっていうのは自分自身が使えるだけではあまり意味がないので、ま、他の一緒の一緒に仕事しているメンバーとかも再現性を持ってちゃんと実行できる、再現できるものに作るとして設計するっていうことが必要です。ま、あの、一定のそのエアに対する知識とかが必要とかなんかこの人じゃないと実行できないとかっていうのは、ま、あまりよろしくないっていう感じですね。
で、丸2としてはアーキテクチャーとシステム設計でこれはおずと、ま、上流工程に、人間が映っていくので、AIが低レベル実装になっていくほど重要性が人間にとってのその仕事の割合とか重要性が増していく部分領域になっていきますね。システム協会、パターン、データフロー、相互作用設計で、きちんとコードベースのアーキテクチャーを組んだりとか、AIエージェントが理解しやすいような、ま、例えばクリーンアーキテクチャーとかデザインパターンとかすごくごく標準的で一般的かつ広く知られているようなAIが理解しやすいアーキテクチャーとかシステム設計、最適化されたデータベースの設計、ちゃんと正規化がされているとかっていう部分が、ま、非常に重要になってくるのかなと思います。ま、AIをうまく効果的に動かすための技術という話でした。
で、4つ目の鑑定の続きで、え、レイヤーさんの、え、作業の検証という話です。ま、これが1番やっぱり重要、これから重要になっていくのかなという部分、人間の役割として重要な部分になっていくのかなという、え、感じがしていまして、ま、そういう風に書かれていますね。で、性格で高品質の成果物をちゃんと保障する。で、それに対して責任を持つというスキルとかマインドセットです。これが、ま、開発者の役割を定義する中心的要素になりつつあるという話です。検証と品質管理っていうのは、ま、具体的にどういう話かと言うと、ま、レビュー、テスト、セキュリティ、チェック、前提条件の検証でAI出力を確かめる、検証するということですね。多くの開発者は生成検証に時間を使うという風に報告をしていて、で、強力な検証方法が大規模な移任を可能するというのは、ま、これは、ま、AIを使って出力を増やすだけではスケールしないということの裏付けで生物を増やすのと同時にその生物の検証方法とか、え、クオリティの基準、成功基準とかていうのを一緒に与えてあげないとこれはスケールしないということを表していますね。なので、ま、型、先ほどのタイプスクリプトの話ではないですが、肩の定義であったり、自動テスト、自動検証の仕組みが、え、より重要になっていくという話につがります。で、これからは生成も検証が重要になっていくということで、レビューテスト、型定義、CI、セキュリティチェック、ま、こういったところはいかにうまく組み込んでいくかということがこれからの時代求められていくし、これができる人が、ま、価値が高くなっていくという話ですね。
はい。いかがでしたでしょうか？今回はエアンソロピックのレポートとギッブのブログから、え、これからのエンジニアの働き方とか、え、マインドセットとか求められるスキルとかっていうのを確認してきました。で、この2つの記事でかなり共通する部分も多いですし、え、今から積極的に、え、どんどん取り入れて、ま、業務とかプライベートとかも含め、え、実行していくことが、ま、これからのAI時代にエンジニアとして生き残っていく、成長していく、え、ことができるヒントとかが、え、たくさん含まれているので、え、皆さんの方でも是非、あの、参考にしていただいて、是非キャリアのステップアップの宛てにしていただければなと思います。え、今回の動画が少しでもためになった、面白かったと思っていただけた方は是非高評価とチャンネル登録の方よろしくお願いします。ではまた次の動画でお会いしましょう。
皆さんこんにちは。今回は、ま、AI時代の組織のあり方とか、ま、エンジニアのどういうスキルを磨いていったらいいのかとか、そういうキャリアの方向性とかに関するとてもいい記事がありましたので、そちらの方をご紹介したいなと思います。今回ご紹介するのはサのテックブログのこのAI時代の技術型組織への変革でこちらの記事はこの33技術本部で開催されたまエンジニアが集まる反送総会の中でAI時代の挑戦型組織へというテーマで語られた内容になっています。で、こういったあの先進的な企業とかのブログとかを見るのは、ま、自分自身の取り組みにもすごく参考になりますし、定期的に目を通して置くとすごく学びになる点が多いかなと思います。
で、上戦型組織というのはどういうものなのかと言うと、ま、この全員1人1人のエンジニアがこうリーダーシップを発揮する具体的には、ま、この現状の枠を加えて新しい価値の想像、未当の領域への挑戦、そして自分だけではなくて組織全体を巻き込む変革を恐れずに押し進めるというAI時代にエンジニア1人1人がリーダーシップを持って挑戦できる、積極的に挑戦できるようなそういった組のことを、ま、しているみたいですね。
じゃあ、この挑戦型組織を作っていくにはどういうことをする必要があるかという具体的な話で、ま、AIネイティブな組織に進化していく必要があるという風に言っています。で、それはどういうものかと言うと、エンジニアは単に技術をどう使うかを考えるだけではなくて、その技術で具体的に、ま、技術を手段として何を実現したいのかっていうのをちゃんと言語ができる存在である必要があるということで、ま、要するにこのプロダクトマネージャーなどにこういった顧客価値とかビジネス面の領域とか課題解決とかそういった領域をエンジニア1人1人がちゃんと考えて深くコミットしていく。で、それにはAIを使っ、え、で、その際にはAIを駆使して未来をどんどん想像していくっていうことが今この挑戦型組織を作る上では不可欠になってくるということですね。
で、この方向性は本当にいろんな他の先進的な企業で言われてるような方向性と似ていて、ま、火流の作業っていうのはAIが基本的に人間がやるよりも高速で実行できるようになっていくので、人間がやるべき、エンジニアがやるべき部分っていうのはこういう今までプロダクトマネージャーがメインでやってやっていた顧客価値とか課題解決とかビジネスドメインとかその辺りの知識をちゃんと身につけで、1人1人がプロダクトマネージャーのように振る舞っていく必要があると、ま、そういうことなのかなと思います。
で、これ面白いのがこのAIネイティブな組織を築づき、AIとの共同知能を実践するためのガイダンス、ガイドラインとしてのイサーモリックという人の著書の著書のこれからのAI正しい付き合い方と使い方というのをこの4つの原則を33のエンジニアリング部門問題内で共有しているという、ま、こういう指標みたいなものを全車的に出すのはすごく効果的なことかなと感じますので、ま、是非他の企業さんもなんか参考にできる部分は多いのかなと思いますね。
で、まず1つ目ですね。これ他のところでも言われ、よく言われてるんですが、AI前提の仕事の進め方、常にAIを参加させるという考え方ですね。ま、あらゆるタスクや問題解決の最初から常にAIを使えないかっていう風に考える。先にそういう風に考えるっていう取り組み方ですね。
で、2つ目が人間参加型にするということ。で、これは結局AIの出力に対してはちゃんと人間がこの審議を見抜いて見抜けることは必要で、それには自らのその専門知識、専門性が専門性だったり、ま、エンジニアの基盤、土台みたいなところがこれからも重要になっていくということですね。
4番、この4番目のとこに書いてるの面白くて、今使ってるAIは今後使用するどのAIよりも列枠だという風に仮定して、この現状に満足せずに今後AIが進化していくことをちゃんと念頭に置きながらAIを活用していったり、サービスにAIを組み込んだりっていうのをちゃんとしていく。なのでこうAIに対する捉え方をちゃんと短期的ものと中長期的なもので住み分けてAIと向き合うということですね。
で、こういったあの原則に基づいて33では3ヶ月間で具体的な調整目標を設定しているということでこの3つ上げているんですがこれすごく参考になる点ですね。え、1つ目が各部でAIネイティブな組織への変革ロードマップを作成し、車内公開する。これ具体的な行動ですよね。アクションというか。これをこれをする必要があるという風にもう決めてしまうのがすごく解像度が高くて、あの良いなという風に感じますね。
で、さらに解像度がもっと高いのがこの各プロダクト部門でAIを全開発プロセスに組み込んだプロダクトバックロを1件以上リリースすると。要するにAIを使った開発プロセスの改善を用いて1つ以上はリリース機能をリリースするということをもうこの挑戦目標に対して組み込んでいるということとあとこれもすごく重要かなと思うのが部長とかの役職者もちゃんとAIを活用した開発を軽減するということです。なんか開発でAIを使った時にどこまで効率化できてどこまでができないのかっていうのをそんなに細かく詳細まで知る必要はないとは思うんですが、ある程度役職者だったり、ま、管理職の方も知っておくことはすごく重要。エンジニア組織を管理する上では非常に重要かなと思います。
次にこのAI時代に進化するエンジニアエンジニアの本質的な価値というところもすごく学びが多くて結構その考え方とかきAIに対する向き合え方というかいままでの考え方というのをこの学びほぐしアンしていく必要があるということ書かれていまああのエンジニアの醍醐ミとして行動を書いたりっていうのがまメインのタスクではあったと思うんですがま今後そういうのま、非重がどんどん減っていく。ただこれはエンジニアの価値が下がっていくのではなくて、むしろAIに定型的な作業を任せて、より上流の作業、価値想像に集中していくことができていう風に捉えてますね。
で、それをしていくためにはマインドを変えていく必要があって、例えば行動を書くイコール価値喪失っていうこの固定概念をなくす必要がありますね。例えば実装量実装量とか行動を難したとか複雑な行動っていうのが評価される時代は終わってこれからは課題を定義することAIをAIを生かす構造を設計することに価値を移すという風に言ってて、これはまさにその通りだなと思います。あとすごくこれも多いと思うんですが、自分の手でやらなければいけない。なんかこう手を動かしたら仕事したみたいな感じが出るのは、ま、結構あるのかなと思うんですが、ま、こういう考え方っていうのはできるだけ今後捨てていかないとなかなか難しいのかと思います。あの、AIによる生成生物の品質をコントロールとする仕組みとか枠組を作るっていう取り組みとあとはそれに対してきちんとレビューできるっていうこと、レビューだけするだけのスキルがあるっていうことが求められてくるかなと思いますし、あとは今まで正解のある世界での最適化思考だったんですが、今後使用とか課題が流動的なA時代に入っていくので、私たちが、ま、正解が決まっているというよりかはどんどん他の競合もAIを使って課題設定してそれに対して機能をリリースしてどんどん高速で回していく時代に入っていくので、その問を立てる側にどんどんエンジニアが回っていく必要があって、どちらかというと仕様が決まっていてそれをいかに早く人間が完成させるかっていう戦からどんどん問を立てていってエンジニアが問を立てていってそれをAIを活用して機能をリリースしていくていうことが求められてくる。つまりエンジニアにはそういった課題設定とか仮説とか言語化とか問題解決能力とかそういったものがより求められてくるということですね。
で、具体的にどういうスキルが、どういうスキルとか能力が今後エンジニアの価値として考えられるのかという点については、まず問題を定義する力ですね。課題を設定したりとか仮説を立てたりとかっていう、ま、技術はあくまでも手段なので、その課題解決であったり、そもそも何のためにこれを実装するのかっていうのをちゃんと説明できる言語化できる構造化できる人っていうのが今後スキルとして求められてくる。さらに実際にとんどんこのAIを活用して自分自身もそうですし、チーム全体組織全体にこのAIを使ったAIファーストな開発とかもうそれ以外の業務もそうなんですがこのワークフローを設計構築してそれを自分以外の人にもどんどん展開していく。それによって組織全体の血を進化させていく。こう加速させていくっていうこういうスキルがどんどん求められていく。ま、もう少し別の言い方をすると自分自身だけができる再現性のないAI活用っていうのはあまり意味をなしてこない。なぜかと言うと、自分自身ができたとしてもそれは1人なのでどんどんスケールさせていく必要がある。AI時代において、ま、競合に打ち買って行くにはどんどんスケールしていく必要がある。なので、ま、1人だとなかなかスケールには限界があるので、これをちゃんとチームだったり組織、他の人に展開して行ける再現性を担保できる仕組みを作れる人っていうのが今後非常に重要になってくるということですね。
で、AIを活用してPDCAを高速で回す。課題設定して全体の設計をして機能を追加してリリースして運用してそれらをフィードバックを取り入れてまたPDCAを回してっていうのを環境を仕組みとして整えられること整えられる人またはそういったスキルこのMVPをどんどん作って早期にリリースしフィードバックを得て改善つげていくっていうのを仕組みとして整えることができるでフィードバックを受けて優先順位を決めたりフィードバックからこれをこれは早めにやるべきでこれは早めにやるべきでないみたいな優先順位をつけたり、ま、こっちの方がより重要性が高いみたいな仮説を立てたり課題設定をしたたりっていうのがまでできる人できるスキルっていうのが非常に重要になってくるっていう点であったり、ま、え、AIがどれだけ賢くなっても結局あのプロダクトのその機能であっ何がこの機能が何を解決するのかっていう意味付けをしたり説明をしたりでき るっていうのが、ま、どこまで行ってもエンジニアのあ、人間の役割なので、ま、AIに火流の部分は任せるのであれば今後こういった意味付けの部分とかあのフと かワットの部分を考えられるスキルとかそういう人が今後価値が高くなっていくということを、ま、書いてますね。
はい。いかがでしたでしょうか？今回はAI時代の挑戦型組織への変革という33のテックブログの記事を紹介させていただきました。え、こんな感じで、え、企業のテックブログとかWeb上の記事とか、ま、先進的な企業の何かブログ記事とかっていうのを、え、今後もご紹介できればなと思っておりますので、え、この動画チャンネル登録と高評価の方をよろしくお願いします。ではまた次の動画でお会いしましょう。
皆さんこんにちは。今回は、ま、AI関連のすごく面白い記事があったので、え、そちらの方ご紹介させていただければなと思います。サイバーエージェントさんのデベロッパーズブログで、え、2028年に、ま、AIを使った開発プロセスの完全自動化をするというテーマでのエンジニアの評価制度の見直しであったりとか、ま、そういうところのお話になりますので、ま、よければ最後まで見ていただければなと思います。
で、私は、えっと、ま、いくつかこういう記事を見る時に観点をあらかじめ絞っておくようにしてまして、で、観点大きく、ま、3つぐらいありますね。3.1が、ま、AI時代のエンジニアの役割の変化について、ま、その記事がどのぐらい言及があるのかという点と、もう1つが、え、エージェンティックエンジニアリング、エージェンティックコーディングとかも言われてますが、ま、バイブコーディングとしてのAIの使い方ではなく、ちゃんとエンジニアリングの中にAIを組み込んで、ま、雰囲気でやるのではなく、しっかりAIを活用してアウトを重視した、AI活用を実現するためのこういったエージェンティックエンジニアリングとかの実践プラクティスについてのどの程度言及があるかという点と、ま、あとはこれからすぐにこの記事を読んでどういうことが試せそうかとか、どういうことを取りこの記事を参考にして取り組んでいけそうかっていう内容が、ま、より具体的であればあるほど、ま、点数が高くなるようにしていて、ま、そのスコアからこの記事の内容を判定して、で、その部分を中心に読むことで記事の全てを読む必要がなくなるので効率的にインプットをしていける方法を取っています。こういった観点でいいなと思っている部分をいくつかご紹介させていただければなと思います。
で、この記事の概要としてはこの全車的に、ま、2028年までに開発プロセスの完全自動化を目指すというビジョンを掲げた内容になっていまして、で、しっかりとこうAIエンジン、あ、AIエージェントとエンジニアが共同して開発のあり方そのものを再発明していく、再構築していくための挑戦ですね。で、え、会社の中でこういったエンジニアが抱えるリアルな不安とかっていうのをちゃんとヒアリングしたり現場の声を聞いた上でどういう風に変えていきますというのを、ま、掲げているものになるんですが、で、ここからこの4のAI時代で活躍するエンジニアとは新評価制度の前貌っていうここの辺たりがすごく興味深いですが、ま、このAI時代になったとしても変わらないことと変わることがちゃんとあるっていうのを定義しておく必要があっで、特に私が注目しておかないといけないなと思っているのがこのアウとかカムを喪失する力っていうところです。結局、ま、AIを使うとアウトプット出すことは基本的に誰でもできるようになるので、AIを使ってアウトカムちゃんと成果きちんとビジネスだったりユーザー価値に対してのアウトカムを喪失する力っていうのがすごく今後の重要なテーマになってくるかなと思っているので、ま、この点はすごく共感する部分が多いかなと思っています。
で、同時にやっぱりこうアウトプットの品質の担保とか誰が責任を持つ持つのかっていう観点もしっかり抑えておかないといけない点だと思っていてAIを使ってアウトプットを出した時のその品質とか信頼性のに対して責任を持つのはエンジニアであってそれは結局そのま、ここに足越しの強いエンジニアっていう表現してるんですがそのAIの出しアウトプットの妥当性を判断できる足腰しの強さというか、土台、基盤みたいな基本的なエンジニアリングの知識経験っていうのが必要になってくるということを書いていますね。で、私が1番、え、絶対避けておいた方がいいなという振る舞いというか行動がAIに聞いたの、AIに聞いた内容とかを結構そのまま報告したりとか、なんでそれを採用するに至ったのかとか、なぜこの行動を書くに至ったのかっていうのをちゃんと自分の言葉で、ま、当たり前ではあるんですが、結構、ま、あんまりでき、ちゃんとできてない方も多いのかなと思っていたりもします。なので、あくまでちゃんとこの自分がAを使って出力した内容に対する責任は他の誰でもなくそのAIを使った人にあるので、ま、ちゃんとそこの妥当性を見極めれるだけの専門性とか足腰の強さっていうのは重要性っていうのは、ま、少なくとも今のAIの性能の段階ではしばらく必要になっていくのかなと思います。
AIに適用したキャリアですね。ま、新設したものとか強化したものとか色々あったりするんですが、ぜ、もう基本的にこの4つの触手はAIを前提とした仕事設計になっていて、ま、すごくこの分類すごとても利にかなっているとか利にかなっているなと私も見ていて思うんですが、ま、例えばテックリードエンジニアとかですね。ま、どちらかと言うと、ま、スペシャリストとテックリードエンジニアちょっと、あの、若干似ているところはあるとは思うんですが、割とテックリードっていうのがこのAIを使いつつ、ま、あの、技術的な知見とか経験を用いてプロダクトの開発を、ま、牽引していく、ま、ビジネスサイドとのビジネスサイドとの連携とか、ま、スペシャリストよりもよりその、ま、ビジネス価値ととかプロダクト開発っていう方面に、ま、色合いが強いこういう触手になってくるのかなと思います。ま、その中でAIをどんどん活用していくっていう内容ですね。ま、スペシャリストより専門性がないわけなので、ま、当然いろんな触種との、ま、コミュニケーション取ったりとかどんどんこの食域を超えてプロジェクトとかプロダクト開発を推進していくっていうポジションですね。
で、ビジネスエンジニアっていうのもあって、ま、エンジニアがビジネス領域に影響する役割ポジションというものらしく、ま、どちらかというと今よくあるのがそのフロントエンドとかバックエンドとかインフラとかっていう分け方をしてると思うんですが、おそらくこれはそういうのをひっくるめたもそのポジションによる分け方というよりか、ま、プロダクトを作るエンジニア、プロダクトエンジニア的な、こビジネスリードエンジニなっていう位置づけにあるのかなと思っていて、さらにおそらく誰しもがこの課題発見から運用まで一期通感で担うっていうことを期待しているはずで、ハウの部分よりもwhatとかファイとかよりこうビジネスよりとか上流工程を意識した触種になるのかなと感じています。で、その中でやっぱAIを使うことによって基本的に作業、火流の作業っていうのはAIが実行するのでエンジニアっていうのは今後そういう火流の中心、火流のタスクが中心ではなく上流の課題発見とか要件定義も担っていく必要があるっていうま、そういう意思を込めての触種なのかなと思っています。
ま、スペシャリストは、ま、スペシャリストですね。ま、よりこの2つの触手よりも特定の領域に特化したエンジニアとしてAIには大体できないほどのかこたる技術。ま、これかなりあのどういう人がいるのかなっていうのはあるんですが、今でもAIの専門性っていうのはかなり高いので、ま、これだいぶ数が限られてくかなと思っていますが、ま、こういう触手もあったり、あとはマネージャーもあったりしますね。ま、マネージャーはそこまでAIを使ってどうのというよりかはそこまでなんか変わらないのかなとは思います。
で、え、ま、特に、ま、ジュニアエンジニアの方とかっていうのがこういうAIが登場したことによって今後のキャリアの不安っていうのが結構大きかったりするっていう話もあっ たりしまして、で、そういう面に関しては、ま、AIに頼ると家庭が育てないっていう不安とかもあったりするので、ま、ジュニアエンジニアに対しては教育特化で対応するということも書いていたりします。ま、AIのアウトプットをみにせずにレビューとか修正したりする力、基礎的な技術力、足腰の強さっていうのが重要になってくるので、ま、これまで以上に力を列ということみたいです。
で、この公平な評価の不安っていうのがエンジニア版、AI版付けっていうのがこれすごく面白いていうか、共感が強い部分なんですが、これAI活用をしているっていう評価結構評価する側から難しいかなと思っています。で、これは結構その会社の評価制度の作り方に工夫がいるかなと思っていまして、ま、このエンジニアリング品質とか技術熟に評価を行いますという風に書いているんですが、ま、このAIを使って自動化しましたとかっていうのもこれは冒頭のところに戻るんですが、今後重要になってくる仕様というか評価の1つの大きな軸になってくるアウトカムベースの貢献度というのが今後より重要になってくるのかなと思います。なのでエンジニアに関してもいやエンジニアなのでそんななんか成果とかにはあまりこう出しに成果とかもこう表現言語化しにくかったりまとめれなかっ たりしにくいかなしにくい触手ではあるかなと思うんですがま今後はこういうアウトカムベースでの成果のアピールとかっていうのをしていかないと評価者からの評価を得にくい時代になっていくのかなと思います。
で、結構これあの大きい会社だとあるあるありがち内容かなと思うんですが、チームとか携ってるプロジェクトによって結構このAI活用の格差というか、ま、差が結構あるかなと思って、そこに不公平が生まれたりするかなと思うんですが、ま、この課題に対してもこのAIドリ分推進室っていうのを立ち上げたようで、で、これはもうあの現場のなんかAIに詳しい人がAI工藤開発のなんかフローを作ってくれたとかなんかそういうこの事情努力だけでタウルのではなくてちゃんと全車的にこういう組織を立ち上げてエンジニアとAIエージェントが共同する自立型開発体制の構築をこう横資で全車的に支援するという風な取り組みをしているみたいです。ま、具体的にはリスリスキリングプログラム提供とか生産性の貸化、評価基盤の整備、ヒアエージェント開発スキルを競そうとか、これ武将対抗のコンテコンテストを行ったりとか、イベントを通じたベストプラクティスの共有推進とかっていうのを、ま、全車的にやっていくっていうのもこれはすごく素晴らしいというか、重要な取り組みなのかなと思います。ま、やっぱりあのチームの誰かがやっていたりとか会社の中での誰かがやってるだけではなかなかこうスケールしていかないので、ま、これをいかに全車的に評価の対象にしつついかに横に広げていくかっていうのがすごく重要なその会社の事業の成功とかにつがってくる重要な取り組みなのかなと思います。
で、私が見てるこの観点の、ま、AI時代のエンジニアの役割の変化っていうのに、は、言及が結構あって、ま、例えばこういう上流工程がメインのタスクになるとかっていうのもやっぱりこうエンジニアがビジネス領域をに影響するっていうことが求められていて、それに沿ったその触種の区分っていうのが設けられていたりするので、ま、この辺りはやっぱり意識しているのかなと思いますし、タスクのメイメインが上流工程になるということ、は、つまり火流工程の作業はAIエージェントに任せるわけなので、結局エンジニアは全員がこのAIエージェントをウォーケストレーションし監督者になるっていうそういう存在になるっていうことを期待しているのかなと思います。