ソフトウェアエンジニアリングの最近のトレンドについて思うこと
最近のソフトウェアエンジニアリングのトレンドについて考えてることをまとめてみる。
昨今はほんとにAIの進化が著しく、ソフトウェア開発の方法論やチーム運営にも大きな影響を与えている。
セキュリティ問題とかパフォーマンス問題とかもあるけど、ここでは主に開発プロセスやチーム運営に関することに焦点を当てる。
なお、この文章中で「エンジニア」とはソフトウェアエンジニアを指す。
文章力の重要性の増加
AI開発によるソフトウェア開発の効率化については解像度の高いエンジニアは多いと思う。 僕自身もコーディングのほとんどをClaude Codeに任せることでかなり効率化できていると感じている。
問題点としては結局AIの書くドキュメント、実装の品質は現状では人間のインプットに大きく依存していることだ。
ある程度具体的な指示・方向性や整合性の取れた要件のインプットがないと、いくらAIといえどもまともなアウトプットを出せない。
なのでエンジニアには、「AIに正確かつ具体的な指示を与える能力」が求められるようになってきている。
端的に言えば日本国内の場合は「国語力」と「論理的思考力」と「それらを文章・図・表で表現する力」のことだ。
特に文章力はまじで重要だと個人的には感じている。
昔の上司に「お前の文章は『てにをは』ができてない、修飾子も適切に配置されてない」と指摘されたことがある。 当時はドキュメントよりも動くソフトウェアだろ、なんてアジャイル宣言みたいなことを思ってたけど、今となってはその指摘の意味がよくわかる。 AIはともかく「なぜAIがそういうアウトプットをしたのか？」を理解するには、書かれたドキュメントを正確に理解することと、 AIが誤って理解した内容について、正しいインプットを文章で伝える能力が必要になるからだ。
多くのエンジニアは期待しない実装や設計ができたときこんなやり取りをAIと交わしたのではないだろうか
1
2
3
4
5
6
7
8
エンジニア「いやいや、なんでそうなるの？実際はXXです。あなたが誤った理由を説明して」
AI「申し訳ありません。あなたの要件を誤解しました。XXに基づいて修正します」
エンジニア「いや、修正してほしいんじゃなくて、誤った理由を説明してほしい」
AI「了解しました。あなたの要件を正確に理解できなかった理由は、私のトレーニングデータに類似のケースが少なかったためです。XXに関する情報が不足していたことが原因です」
エンジニア「そうじゃなくて、あなたが私の要件を誤解した具体的なポイントを説明してほしい」
AI「申し訳ありません。あなたの要件を誤解した具体的なポイントは、XXに関する情報が不足していたことです。これにより、私の解釈が不正確になりました」
エンジニア「その部分についてはXXです。この前提で再度要件を整理して設計・実装してください」
AI「了解しました。あなたの要件を正確に理解しました。XXに基づいて修正します」
つまりAIがミスった理由を正確に説明させるには、エンジニアがAIに対して正確かつ具体的な質問を投げかける能力が必要。 そしてこれは結局文章力に依存する。問答法でソクラテスが弟子に真理を教えたように、ひたすらAIと対話するしかないだろう。
こんな感じで僕はClaude Codeとの対話の流れでそれぞれ「こうしたほうがいいよね」というポイントをひたすらAIに考えてもらい、 それをCLAUDE.mdにClaude自身にまとめてもらっている。そうすると少しいい感じにAIが配慮してくれるようになる。
エンジニアの役割の変化：プロダクトエンジニアへ
エンジニアの役割がコードを書くとか設計するだけでなくなってきているのも最近のトレンドだと思う。
じゃあなにをするのか？というと、わかりやすいところではプロダクト開発に深く関与することなんじゃないだろか。
昔々「特定業界のドメイン知識を深く持つエンジニアには価値がある」とSI時代の役員に自分の考えを補足してもらったことがある。 当時も今もSIの現場ではプロダクトマネージャーという役割が明確ではなく、ドメイン知識を持つエンジニアが要件定義や設計に深く関与することが求められていると個人的にも感じている。 顧客側がドメイン知識を持っている場合は多いものの、プロダクト開発のプロではないこともあり、 プロダクトマネージャーに適任か？というと必ずしもそうではないからだ。
AIがコードを書くようになった現在、ドメイン知識はエンジニアのAIへの指示の具体性にも寄与するし、
プロダクトの価値を高めるための重要な要素にもなる。
SIの現場ではドメイン知識の深いエンジニアが顧客とプロダクトの要件をすり合わせ、間を取り持つ役割を担ってきたが、
今後は自社開発やスタートアップの現場でも同様の役割がエンジニアに求められるようになると思う。
エンジニアは単に設計・実装するだけでなく、プロダクトをどう作るか、どう成長させるかについて、
プロダクトをエンジニアリングする役割も担っていくことになると言えそうだ。
（これをプロダクトエンジニアだとかビジネスエンジニアだとか呼ぶのかも）
マネジメントの話
ソフトウェアエンジニアリングのトレンドはチームマネジメントにも影響を与えている。
AIのおかげでノーコードやローコードよりももっと抽象度の高い「俺・私の作った最強の業務効率化ツール・フレームワーク」が、
個人・組織・チーム単位で増えてる会社もあるのではなかろうか。
ここだけみれば良い話ダナー( ；∀；)で終わるものの、いざセキュリティだとか野良ツールの管理だとかコストなど考えると、マネジメント的には悩ましい問題も増えていると思う。
これまでは人の属性やスキルセット、経験値でチームをマネジメントできたのだが、
AIがエンジニアリングの一部を担うようになったことで新しい指標や考え方が必要になってきている。
つまりマネージャーこそがAIを活用してチームの生産性を最大化する方法を模索しなければならない時代になってきている。
このような背景を踏まえるとマネジメントとコーディングを一緒にしてはならない的なプレイングマネージャー論はもう古いのかもしれない。 別に新規実装や改修をせずとも、誰がどのようなコーディングをしたのか、経緯はどうだったのかをコミット内容からAIに解析させて推測することもできるので、 今まで以上にマネージャーがプロダクトの中身について理解を深めることが求められるようになるだろう。
透明性
上述した通り、AIによって埋もれてしまいがちな様々な開発のプロセスにおいて、どこの誰が何をしているのか？を可視化し、それらの透明性を高めることも必要になりそうだ。 現にAI関連の勉強会やイベントに参加してもAI開発の浸透具合や利用率を計測・可視化し、 社内勉強会をやったり、ナレッジ共有を促進したりしている企業の話を見聞きする。 んで、その透明性こそが新しい開発プロセスの在り方やチームマネジメントの基礎になるのではないだろうか。
要するに局所最適化されたAI活用ではチーム開発においては最大のスループットを発揮できないし、
未知の領域がより一層増えるわけである。具体的に例えると、今まではXさんが知っていることだったが、Xさんすら知らずAIのみが知っている（あるいはAIすら過去の会話は知らない）みたいな状況が発生しうるということだ。
こういう観点からもAIのアウトプットの透明性も同様に重要になる。ただ、いちいち従業員のインプットとAIの回答をログに残すのも現実的ではない。
もしかしたら大企業だとやってる（やろうとしている）かもしれないけど……。
コードの透明性の確保という観点では、モノレポがますます注目されるようになるかもしれない。
いろんなリポジトリにPRが飛んだりIssueが立ったりするよりも、モノレポで一元管理しておけば、チーム全体のコードの変更履歴や責任者が把握しやすいからだ。
また、コードレビューのプロセスもAIを活用して効率化できるようになるだろう。
ついでにドキュメントもモノレポで一元管理して、コードとドキュメントの整合性を保つということをやってる企業もチラホラいるようだ。
自律性
AIがボトルネックにならないよう透明性を上げた組織づくりをしたあとは、各メンバーが自律的に働ける環境を整えることも重要になる。 言葉としては古いがフルスタックエンジニアリングチームのようなイメージだろうか。 各メンバーがプロダクトの全体像を理解し、AIを活用して自分のタスクのアウトカムを最大化できるようにする感じ。
例えばUIデザインについて、今まではデザイナーがワイヤーフレームを作成し、エンジニアがそれを実装するという流れが一般的だった。
このプロセスにおいてはデザインの品質や一貫性を保つために、デザイナーとエンジニアの間で多くのコミュニケーションが必要になる。
例えばデザインシステムの構築やアトミックデザインの導入などが考えられる。多くの場合デザイナーとエンジニアのスキルレベルに極端に依存するし、
落とし所を見つけるのも難しいのではないかと思ってる。
ここにAIを活用することで、UIデザインから実装に使えるルールやコンポーネントをデザイナーが自動生成できるようになる。
エンジニアはその生成されたルールやコンポーネントを基に実装を行うことで、デザイナーとエンジニアの間のコミュニケーションコストを削減できる。
あとAIが解決するのはデザインとエンジニアリングの間だけではないのではないかという仮説も個人的には持っている。
組織が大きくなってくると情報伝達による情報の劣化や欠落が多くなる。
だからといってCEOや上司が色んなところで出しゃばると、今度はタスクが「偉い人の承認・確認待ち」でボトルネックになっていく。
この場合各チームやメンバーに責任や判断の移譲を行っていく必要がある。判断の軸にはKPIやミッション、ビジョン、バリューなど会社の経営や存在意義などの価値観に紐づくものであることも多い。
AIがあればこの辺の情報をいい感じにドキュメント化&ナレッジベースとして構築し、判断をAIに仰ぐこともできるのではなかろうか。
まぁそんなことよりもまずは人間同士のコミュニケーションと役割と責任の分担で、組織構造をいい感じにするほうが先かもしれない。
最後に
AI 駆動開発カンファレンス 2025 Autumnで「AI時代のソフトウェア開発を考える」というセッションをt_wadaさんが講演されていたが、 僕の考えのほとんどがより良い形でまとめられていて非常に参考になった。
初演時の公開資料はこちらです
— Takuto Wada (@twada) <a href="https://twitter.com/twada/status/1983852813437563215?ref_src=twsrc%5Etfw">October 30, 2025
AI時代のソフトウェア開発を考えるhttps://t.co/1ufjybPpfV
この講演も踏まえて、個人的に課題だなーと思っていることをまとめると以下だ。
- 文章力の向上 AIに正確かつ具体的な指示を与える能力を高めるために、エンジニアは文章力を鍛える必要がある。
- アウトカム志向の強化 エンジニアは単にコードを書くのではなく、プロダクト全体の価値を最大化することに注力する必要がある。 AIによって生産性を上げるというよりは試行回数を増やすイメージ。そこからのフィードバックループと改善のほうがより重要になる。
- 透明性と自律性の確保 チーム全体の透明性を高め、各メンバーが自律的に働ける環境を整えることが求められる。 透明性の確保にはモノレポの活用やAIによるコードレビューの効率化が有効かもしれない。 自律性の確保は人間同士のコミュニケーションも多めに絡んでくるのだが、組織・人の役割や責任分担とAIによるいい感じの共通言語・共通認識化による判断の統一が有効かもしれない。
SaaS id deadと言われる昨今、実際に日本のIT市場でもSaaSやってるだけじゃ企業価値もつかず上場しても株価は上がらず横ばいか下落傾向にある。 このあたりにテコ入れするには、コンパウンド戦略だとかネットワーク効果だとかプロダクトの差別化要素を強化したり、金やモノや人、情報の流れを一括して最適化できるプロダクトにしたりという工夫が必要らしい。 今まで1つのSaaSに対してプログラミングやアーキテクチャ設計に注力してきたエンジニアが、これからはプロダクト全体の価値を最大化することにも 意識を向けなければならないのだろうなーと思う次第である。
