いまやAIを使えること自体は差別化要因ではありません。
重要なのはどの道具を使うかではなく、どんな問題を定義し、それを実際に動くプロダクトにできるかです。最近読んだ文章も同じ点を指摘していました。AIはすでに強力な道具になりましたが、開発の議論はしだいにプロダクト価値よりも道具の使い方そのものへと傾いています。結局重要なのは技術そのものではなく、その技術で誰のどんな問題をどう解くかです。
私は仕事を始めるとき、技術より先に問題を見ます。
この機能が本当にユーザーの問題を解くのか、社内の不便さをユーザー課題と取り違えていないか、リリース後も運用できるのかを先に確認します。実務では、実装そのものよりこの判断のほうが重要なことが少なくありません。一見すると機能要望でも、実際にはポリシーの問題であることがありますし、大きな改修に見えてもデータ構造ひとつで解けることもあります。だから私はAIを素早い実行のためには積極的に使いますが、問題定義そのものを代替する道具だとは考えていません。
私が作りたいのも、単なる機能ではなく、運用できるプロダクトです。
良いプロダクトはデモ画面よりも運用段階で実力が表れます。権限、データフロー、例外処理、修正可能性、運用者視点での説明可能性まで耐えられてこそ、はじめてプロダクトになります。だから私は画面ひとつを見るときでも、その背後にあるポリシー、管理構造、保守コストまで一緒に見ます。技術・企画・デザイン・運用を切り分けて考えないのもそのためです。プロダクトはこれらの要素がつながったときに、はじめて完成します。
AIの活用も同じです。
たくさん使うことが重要なのではなく、どこにどう配置するかが重要です。反復作業、整理、下書き、プロトタイピングには強力ですが、優先順位の決定、構造設計、ブランドトーン、運用判断まで委ねてしまうと、成果物は速くなっても浅くなりがちです。しばらくの間Product Engineerという言葉が注目された理由も、ここにあると思います。コードよりもプロダクト価値に集中しようという流れは健全でした。反対に、いまのようにツールの使用量や自動化そのものを実力のように語る態度は、本質から遠ざかっています。
ポートフォリオで見せたいものも、結局は同じです。
何を作ったかよりも、どんな問題を見て、どんな基準で判断し、それをどう運用可能な構造に設計したのかを残したいと思っています。AI時代には、誰もがある程度までは速く作れます。だからこそ、よりはっきり表れるのは速度ではなく、判断の質です。
私が仕事でよりどころにしている基準は単純です。
技術より先に問題を見て、機能より先に構造を設計し、リリースより先に運用可能性を考えることです。
私は機能を実装する人というより、問題を構造化して
実際に回るプロダクトへ変える人でありたいと思っています。