エンジニアのコミュニケーションスタイルにポジティブな変化も
──ガイドラインの運用を開始したことで、社内のビジネス側、およびエンジニア側の現場にはどのような変化が見られましたか。
ビジネス側における最大の成果は、「現場で困っている人自身が、困りごとをクイックに解決できる手段が増えた」ことです。例えば、マーケティング担当者がデータ集計の効率化ツールを作りたいと考えたとき、従来であれば社内外からエンジニアを探して要件を伝え、実装されるまでに2～3か月かかることも珍しくありませんでした。それが今では、レビューを含めて1か月足らずで実用化できるようになっています。
また、新規事業のアイデアを検証する際も、ランディングページを即座に作って広告を回し、ユーザーの反響を2週間ほどでテストするといった超高速なアプローチが可能になりました。制作会社を選定している間に検証そのものが終わってしまうようなスピード感は、組織にとって大きな変化です。
一方、エンジニア側にとっても、コミュニケーションスタイルの変化という面白い兆候が見られます。これまではエンジニア同士でフィードバックする際、GitHubのプルリクエストでコメントを残すのが一般的でした。しかし非エンジニアのメンバーは、コメント上で専門的な指摘をされてもどう修正すればいいかわかりません。
そのため、現在では修正すべき要件をマークダウン形式のドキュメントに綺麗にまとめ、「これをそのままAIに読み込ませて修正させてください」という前提でテキストを渡すようになりました。AIに読ませることを前提とした「万人に優しい、明確に構造化されたデータ」を作る意識が現場に根付いたことは、エンジニア自身の言語化能力や仕組み化の視点を養う上でも、非常にプラスになっています。
AI時代、エンジニアの価値は「非機能要件の担保」にアリ
──誰もがAIでシステムを作れるようになった今、専門家であるソフトウェアエンジニアが果たすべき「本質的な役割」や「存在価値」はどこにシフトしていくとお考えですか。
私はエンジニアの役割を「機能要件の充足」から「非機能要件の担保」、そして「アウトプット＝作った成果物」から「アウトカム＝創出した成果」へのコミットへとシフトしていくと考えています。
今の生成AIは非常に優秀ですから、ボタンを押したら意図通りに動くといった「機能要件」のクリアは、非エンジニアであってもAIの力を借りて十分に達成できるようになりました。しかし、そのシステムが本番環境での運用に耐えられるか、セキュリティの脆弱性はないか、2年後も保守し続けられるかといった「非機能要件」の良し悪しは、作った直後にはわかりません。正解やリスクが数年後に顕在化する領域だからこそ、これまでの経験に裏打ちされたプロの目によるチェックと担保が不可欠です。
また、これまでのエンジニアは「これだけの機能を作ってリリースした」というアウトプットだけで評価される側面がありましたが、作る行為自体がコモディティ化した世界では、作った結果「どれだけお客さまに喜ばれ、ビジネスの成果につながったか」まで責任を持つことが求められます。
今後、エンジニアが生き残る道は大きく3つに分かれると私は考えています。お客さまの課題の近くに身を置いて事業を牽引する「プロダクト／ビジネスサイドへの浸透」、組織やチームの力を最大化する「ピープルマネジメント」、そしてAIには簡単に代替できないインフラや高度な非機能要件を追求する「ディープな技術への特化」です。中途半端な位置にとどまるのではなく、自分の専門性をこの3つのいずれかに尖らせていくことが、これからのエンジニアの存在意義になるのではないでしょうか。
──最後に、非エンジニアのAI開発や組織のガバナンスのあり方に悩んでいる方々へ向けて、メッセージをお願いします。
AIの進化によって、エンジニアの能力は「より強化」されましたが、非エンジニアにとってはこれまでできなかったことができるようになる「能力の拡張」が起きています。この非線形な変化がもたらすビジネス上のメリットはとても大きなものです。
歴史を振り返っても、こうした圧倒的なテクノロジーの潮流やパラダイムシフトに対して「抗う」という選択が成功した例は一度もありません。私たちはこの変化を拒絶するのではなく、受容せざるを得ないという前提に立つ必要があります。
全面禁止にするのではなく、「変化を受容した上で、いかにリスクをヘッジし、いかに望ましい組織の形をデザインするか」を考える方が建設的です。エンジニアリングのプロフェッショナルとして、この時代における組織の最適なガバナンスをリードしていただければと思います。
