「何を作るか」の前に「何を成したいか」を問う
私がキャリアをスタートさせたのは、今から20年近く前、新卒で入社したコンサルティング会社でした。右も左も分からない新人時代、先輩方から耳にタコができるほど叩き込まれたのが、システム開発プロジェクトにおける「3つのA」、すなわち「トリプルエー」という考え方です。
その3つとは、「アチーブメント（Achievement：達成すべき目的）」、「アーキテクチャ（Architecture：構造やロジック）」、そして「アプローチ（Approach：進め方や管理）」です。当時はフレームワークの一つとして機械的に覚えていましたが、その後、ソフトウェア開発の現場で実際にコードを書き、レビューを行う立場になって初めて、この「アチーブメント」という概念が持つ真の重みに気づかされました。
多くの開発現場では、設計や実装の美しさに目が向きがちです。しかし、そもそも「このシステムを使って、顧客は何を実現したいのか」というアチーブメントが欠落していれば、どれほど洗練されたコードを書いても、それは顧客にとって「高価な無用の長物」に過ぎません。極論を言えば、業務上の目的が果たせるのであれば、手段はExcelでもWebシステムでも構わないのです。目的を見失った開発は、時間とお金の浪費という最悪の結果を招くことを、私は何度も現場で見てきました。
コードレビューの優先順位を再定義する
エンジニア同士のコードレビューにおいて、よく議論になるのは「オブジェクト指向の原則に反している」「変数名が適切でない」「インデントが崩れている」といった、アーキテクチャやコーディング規約に関する事柄です。もちろん、メンテナンス性や拡張性を担保するためにこれらは重要です。しかし、私の実感として、レビューの最優先事項はそこではありません。
まず確認したいのは、「この実装は、顧客のニーズを正確に満たしているか」「やりたいことが正しく理解されているか」という点です。構文チェックやロジックの美しさは、あくまでアチーブメントが達成されていることが前提の「二の次」の話なのです。目的を外したままアーキテクチャを磨いても、間違った方向に全力疾走しているだけになってしまいます。
「画面」から透けて見える業務理解の解像度
業務的な整合性を確認する際、私が現場で実践してきたのは、バックエンドの複雑なロジックを精査する前に「画面（UI/UX）」のレビューを行うことです。なぜなら、画面には開発者が「ユーザーの業務をどう捉えているか」が如実に現れるからです。
例えば、ユーザーが「大量のデータを一括で処理して効率化したい」と考えているにもかかわらず、用意された画面が一件ずつしか処理できない構造になっていれば、その時点で業務要件を満たしていないことが一目で分かります。細かいデータベースの設計やバックエンドの実装に入り込む前に、画面を通じて「業務を回せるか」を検証することで、手戻りを最小限に抑え、本質的なレビューが可能になります。画面が固まれば、そこから先のバックエンド構築はある種、半自動的に進めることができるのです。
AI時代に人間にしかできない「文脈の理解」
昨今、GitHub CopilotやCursorといったAIコーディング支援ツールの進化には目覚ましいものがあります。構文の生成や、一般的なアルゴリズムの提案、定型的な単体テストの作成において、AIはもはや人間を凌駕しつつあります。しかし、どれほどAIが進化しても代替できない領域が、まさにこの「アチーブメントの把握」です。
顧客の要望は、常に完璧な仕様書として言語化されているわけではありません。その会社固有の力学、現場の担当者が抱く暗黙の不満、業界特有の商習慣、さらには会話の端々に現れる「本当はこうしたい」というニュアンス……。これらを複合的に解釈し、業務背景との整合性を見極めるのは、人間にしかできない高度な知的活動です。AIは「指示されたコードを正しく書く」ことは得意ですが、「その指示自体が顧客の幸福に繋がっているか」を判断することはできません。
まとめ
これからのAI時代のエンジニアに求められるのは、単に「動くコードを書く能力」ではなく、顧客の業務に深く入り込み、「何が真のアチーブメントなのか」を定義・検証する能力です。コードレビューの本質を「構文チェック」から「業務背景との整合性確認」へとシフトさせること。それこそが、私たちがAIを賢く使いこなし、価値あるソフトウェアを生み出し続けるための唯一の道ではないでしょうか。
20年前に教わった「トリプルエー」の教訓は、技術が激変した今、これまで以上にその輝きを増しているように感じます。まずは目的を問い、次に構造を磨く。このシンプルかつ強力な原則を、私も日々のレビューの中心に据え直していきたいと思っています。