■ 1. 背景: AIと開発者の役割
- AIエージェントによるソフトウェア開発の普及に伴い、開発者の必要性への疑問が生じている
- シニア開発者の役割は単なるコード記述にとどまらず、不要な開発の回避、複雑さの抑制、稼働中のシステムの維持にある
- コピーライターのトゥヒン・ナイール氏が、シニア開発者の専門知識が伝わりにくい理由を「複雑さ」と「不確実性」の観点から説明している
■ 2. シニア開発者の2つのタイプ
- 新しいツールや外部のベストプラクティスを持ち込むタイプ
- 実装の必要性を問い、既存のもので対応できないかを検討するタイプ
- ナイール氏はこの後者を評価している
- コードを増やす前に、実装の回避・規模の縮小・既存リソースの再利用を検討する
■ 3. 複雑さと不確実性の対立
- シニア開発者が警戒するもの: 「複雑さ」
- 新しい条件分岐、データベーステーブル、コンポーネントの追加がシステムを複雑にする
- コードを増やす前に「本当に必要か」を確認する
- ビジネス側が恐れるもの: 「不確実性」
- 市場向けループ: 会社が市場にプロダクトを出し、フィードバックを受け取る
- マーケター、営業、PM、CEOなどが「何に価値があるか分からない」という不確実性を減らそうとする
- できるだけ早く市場に出して反応を得ることが重要
- 既存ユーザー向けループ: 会社が既存ユーザーにサービスを提供し、支払いを受ける
- サービスの継続稼働、問題発生時の理解・修正・デバッグの容易さが重要
- 複雑さが増すほどこれらが困難になる
■ 4. 専門知識が伝わりにくい理由
- 市場向けの人々は「早く出してフィードバックを得たい」と考える
- シニア開発者は「複雑さを抑えて安定したサービスを提供したい」と考える
- 優先する問題が異なるため、専門知識が伝わりにくい
■ 5. シニア開発者の専門知識の示し方
- 「複雑さを増やしたくない」と伝えるだけでなく、「不確実性をより早く減らす方法」として専門知識を示す必要がある
- 不要なものを作らない力と既存のものを再利用する力が有用
- 具体例:
- 調査データ収集: 新しい機能を作る前にGoogle Formsを活用する
- 新機能への需要確認: 完全な機能開発前に既存UIへのボタン設置でクリック率を確認する
- 新しい分析サービス: 「一つの判断、一つのグラフ、一つの指標」から始める
- フレーズ: "Can we try something quicker?"
- 「quicker」: 相手が求める速さを認める
- 「something」: 別の方法の存在を示す
- 「try」: 不完全な状態でも試せる余地を残す
■ 6. AIの役割と責任の所在
- AIによって試作品やコードの作成速度は大幅に向上する
- AIにはシニア開発者が担う「責任を取ること」はできない
- AIが書いたコードでシステムが理解しにくく、修正・デバッグ・教育が困難になっても、顧客への責任はAIではなく開発者が負う
■ 7. 2システム構造の提案
- スピード版: 速く試すためのシステム
- AIエージェント、未レビューの生成コード、ジュニア開発者、マーケティング担当者が使用
- 市場からフィードバックを得られる程度のものを素早く作ることが目的
- スケール版: 安定して運用するためのシステム
- シニア開発者が安定性・理解しやすさ・拡張しやすさを重視して整える
- スピード版で有効と判明したものを顧客向けに信頼できる形へ組み込む
- 実用例: 「スピード版は3日、スケール版は6週間」という提案が可能になる
■ 8. シニア開発者の再定義
- ナイール氏は、シニア開発者を「senior software developer」でなく「senior software editor（シニアソフトウェア編集者）」と呼ぶべきと結論づけている
- 小説家が初稿を急いで書き、編集者が整えるプロセスに例えている