シニア開発者が専門性を伝えられない理由
(nair.sh)- シニア開発者と非開発者は、AIエージェントが開発者を代替するという同じ文を、安定性と市場学習という異なる基準で受け止める
- ビジネス組織は素早くリリースしてフィードバックを得て不確実性を減らそうとするが、シニア開発者はシステムを壊す複雑性の増加を警戒する
- 顧客がついた後は、市場探索とサービス継続という2つのループが同時に回り、シニア開発者の中核的な責務は複雑性の管理へと変わる
- 説得は「複雑性が問題だ」と言うだけでは終わらず、Google Formsや既存UIのボタンのようなより速い実験で相手のスピードへの欲求を満たしてこそ可能になる
- AIはリリース速度を高めるが、理解・修正・デバッグ可能性を損ないうえ責任も負わないため、シニア開発者はSpeedとScaleを分離できる
同じ文を異なる基準で聞く理由
- シニア開発者と非開発者は、「AIエージェントがソフトウェア開発の未来であり、開発者は不要になるだろう」という同じ文をそれぞれ異なる形で受け止める
- コピーライティングではメッセージは聞き手に合わせる必要があり、同じ文でも聞き手によって意味が変わる
- シニア開発者の直感がAI楽観論と分かれる理由は、仕事の焦点が市場学習なのかサービス安定性なのかによって、問題の定義が変わるためである
シニア開発者が警戒しているもの
- シニア開発者の中には、新しいツールや他社のやり方、Hacker Newsのベストプラクティスを根拠に何かを導入しようとするタイプがいる
- より好まれるシニア開発者は、まず「本当に必要か？」「やらなければどうなるか？」「今は持ちこたえて、後でもっと重要になったときに見直せるか？」と問う
- このタイプは、開発をできるだけ避け、減らし、再利用しようとする
- プロフェッショナルなソフトウェア開発で、シニア開発者が最も警戒する対象は複雑性である
- 特殊ケース、条件分岐、新しいデータベーステーブル、新しいコンポーネントは、いずれもシステムに複雑性を加える
- 稼働中のシステムに責任を負う開発者は、最終的に複雑性の増加を恐れるようになる
- 新しく創造的な設計が得意なシニア開発者であっても、稼働中のシステムを任されれば複雑性を警戒するようになる
ビジネス組織が警戒しているもの
- マーケター、営業担当者、プロダクトマネージャー、CEOは、市場に何かを出してフィードバックを受け取り、それに価値があるかを学ぶループの中にいる
- このループの目標は学習であり、最大の脅威は不確実性である
- どんな戦略も成功が保証されていないため、不確実性は容赦なく作用する
- マーケティング・営業の報酬、創業者の給与、プロダクトマネージャーのデータが時間と結びつくと、締切までに不確実性を減らす唯一の方法は、できる限り早く市場に出すことのように感じられる
- 市場により多く出すほど、より多くのフィードバックが得られ、潜在的に不確実性をさらに減らせる
- すべての会社はこのループから始まり、このループは純粋なスピードを中心に動く
顧客が生まれた後の2つ目のループ
- 顧客が支払いを始めると、サービスの継続と保証を目標とする2つ目のループが生まれる
- システムは継続して動作しなければならず、理解可能で、デバッグ可能で、修正可能で、教えられて、安定していなければならない
- シニア開発者は顧客に継続してサービスを提供しなければならないというビジネス上の責任を担うため、安定性を重視する
- これらすべてを脅かすものは、やはり複雑性である
- 複雑性はシステムを、理解しにくく、デバッグしにくく、修正しにくく、教えにくくし、最終的に安定性も下げる
- 複雑性が上がれば安定性は下がり、シニア開発者は責務を果たせず、決済停止のような問題が起こりうる
- 1つ目のループの目標が不確実性の低減なら、2つ目のループの目標は複雑性の管理である
コミュニケーションが失敗する地点
- 顧客がついた後は、市場探索とサービス継続という2つのループが同時に回る
- ビジネスは可能性を探索しながら、同時に顧客へサービスを提供しなければならない
- どのループに時間を使うかによって、同じ問題でも違って見える
- ビジネス組織は不確実性を減らすために、より速く作って市場に出そうとする
- シニア開発者は、要求が増えるほど、複雑性、保守コスト、理解可能性、継続的な開発速度、時間の経過に伴う生産性を心配する
- しかし、複雑性管理の言葉だけでは、他部門の不確実性の低減への欲求を満たしにくい
- 説得するには、シニア開発者の解決策を、相手の問題に対する解決策としても表現しなければならない
- コミュニケーションは、複雑性管理の観点で問題を語りながら、不確実性低減の観点で解決策を語れないときに失敗する
シニア開発者の実質的な強み
- シニア開発者の最も有用な能力は、不必要なものを作らず、すでに作られているものを再利用する機会を見つけることにある
- アンケートデータを集める必要があるなら、Google Formsを使えばよい
- 新機能全体を作ってテストする代わりに、既存UIにボタンを追加して、人々がクリックするかどうかを見ることもできる
- 新しい分析サービスを導入する前に、分析が必要な最も重要な意思決定は何かをまず問い、1つの意思決定、1つのチャート、1つの指標から始められる
- 誕生日ケーキを丸ごと焼く代わりに、サンドイッチにろうそくを1本立てるようなアプローチも可能である
- シニア開発者は、既存のソフトウェアを活用して人々が望むものを提供する方法を学ぶ
- これを短く伝える文は「Can we try something quicker?」である
- 「quicker」は、相手が実際に求めているスピードを認める
- 「something」は、別の達成方法があることを示唆する
- 「try」は、不完全でも十分によいかもしれないという可能性を含む
- この文は、会社が求める不確実性低減の速度を認めつつ、シニア開発者が減らし、再利用し、可能なら避けるという専門性を発揮する余地を与える
AIが変える圧力と残る責任
- AIは短時間で多くのものを作れるため、減らす・再利用する・避けるという姿勢は無意味に見えるかもしれない
- しかしAIはまだ、シニア開発者が担う仕事の1つである責任を負うことはできない
- シニア開発者がシステムの理解可能性を重視する理由は、問題が起きたときに直せなければならないからである
- 理解可能性は、システムが成長しなければならないときに賢く拡張できるようにし、有料顧客に継続して安定したサービスを提供できるようにする
- AIは市場に出す速度を大きく高める一方で、シニア開発者が責任を負う安定性のループにも影響を与える
- AIエージェント、ジュニア開発者、非開発者、投資家やその周辺の人々までがシステムにコードを追加すると、システムはスピードを過剰に報い、その代わりに安定性を手放すようになる
- AIは理解可能性、修正可能性、デバッグ可能性、教えやすさ、保証可能性を悪化させうる
- AIはシステムを不安定にしうるが、責任は負わない
- ここがシニア開発者の核心的な懸念である
書き手より編集者に近いシニア開発者
- シニア開発者が使える1つの方法は**分離（decoupling）**である
- 長い間、ソフトウェアを作れるのはソフトウェア開発者だけだったため、開発者は市場学習とサービス安定性という2つのループの両方に責任を負っていた
- 1つのシステムが2つの目標を同時に支える構造だった
- それぞれの目標に別のシステムを置けば、スピードと安定性を分離できる
- これは、小説家が素早く初稿を書き上げた後、うまくいく部分を抜き出し、うまくいかない部分を捨てる編集工程を経るのと似ている
- 編集者の仕事は、うまく機能する断片を取り出して、まとまりのある全体へと磨き上げることである
- Speed版はスピードのためのシステムであり、AIエージェント、生成された未レビューコード、ジュニア開発者、マーケティングなどが素早くアイデアを形にする場になりうる
- Speed版は理解可能性ではなく、市場のフィードバックを得るのに十分によい状態を目標とする
- Scale版は安定性のためのシステムであり、シニア開発者が安定的で理解しやすく、拡張可能に設計する
- Speed版はビジネスが市場から学び続けられるようにし、シニア開発者はその後を追って、十分にレビューされ理解可能なシステムを構築する
- Scale版の設計は、Speed版で何がうまく機能し、何が機能しなかったかの影響を受ける
- 機能はSpeedで作られ、その後Scaleで安定化される
- 実際の実装形態は明確でないかもしれないが、核心はスピードを追求する仕事と安定性を追求する仕事が異なることを明示的に分離する点にある
- 野心的な要求を受けたとき、「Speed版は3日以内に用意し、Scale版は約6週間後に用意します」と言える
- 相手はスピードと推進力を得られ、シニア開発者は観察と設計の時間を得られる
- この観点では、シニア開発者は「シニアソフトウェアライター」よりもシニアソフトウェアエディターに近づきうる
1件のコメント
Hacker Newsの意見
専門性の最も重要な部分は内面の世界モデルから生まれ、それとは切り離せない
たいてい私たちは、どんなことでも言葉で表現でき、言葉さえ伝えれば聞き手は話し手の意図をそのまま理解できると信じているが、この思い込みのせいで、開発者の専門性を他人に「伝達」せよという要求が生まれる
実際には知識そのものは言葉でかなりうまく伝えられるが、あらゆる知識が結びついて固まった世界モデルはそうではない。AIは事実をはるかに多く知ることができても、その知識を土台に驚くほど頻繁に当たる洞察を生み出す形では、まだ活用できていない
専門性の伝達とは、実際にはどこへ向かい何を学ぶべきかについてのヒントに近く、受け手が内面化する努力と適切なプロジェクトを通じて同じ専門性を獲得しなければならない
ソフトウェアの「物理法則」を理解して応用する人と、ただ手順を書き連ねるだけで各段階の本質を理解しようとしない人は区別できる
オブジェクト指向に慣れた人に関数型プログラミングを教えるときに特に顕著で、ある人はモデルが壊れ、ある人は変数の世界からモナドの世界へ比較的容易に翻訳できることをすぐ見抜く
ほぼ30年間、主にある大企業で働いてきて、毎週かなりの時間を新しく入ってきた人たちが直面する問題への回答に費やしている。質問を聞くだけで、問題の根が彼らの世界モデル、Naurの言うTheoryが不完全だったり歪んでいたりして推論を難しくしていることにすぐ気づくことが多い
課題は、自分の理論をテキストや図表のような記号表現に変換し、十分な経験と知性を持つ人が似たようなメンタルモデルを思い描けるようにすることだ。つまり、自分の理論を他人の頭の中にインストールしたいわけだ
Naurの言うタイプの理論は直接移植できないが、シニア開発者の仕事は、教室であれ現場であれ、経験を引き出してそうした理論を再生産する方法を見つけることだと思う。だからコミュニケーション能力が重要であり、他人から動作理論を受け取る過程を何度も経験してこそ効果的な直感が育つ
今ではこの仕事が業務の中で最もやりがいのある部分になっており、意味のある形でこの役割を果たしていると感じられる限り、引退を急ぎたいとは思わない
ジュニアを訓練しメンタリングするとき、何が可能で何が失敗につながるパターンかを示そうとするが、その訓練はたいてい断片的で不完全だ
できるだけ、なぜそうするのかを説明するが、絶対にするなと言い切ることはあまりない。自分が教えた人たちの問題解決の仕方にはよく驚かされるし、自分もまたよく学ぶ
自分の貢献に関心がなく、仕事を給与を得る手段としてしか見ていない人に対しては、訓練はあまりうまくいかない。そう考えること自体が間違っているという意味ではないが、無関心を土台に仕事の世界観を作ると、訓練を内面化しにくい
https://andymatuschak.org/books/
シニア開発者として、一律の断定が本当に嫌いだ
「本当にこれが必要か？」「やらなかったら何が起きる？」「ひとまず持ちこたえて、後でもっと重要になったら戻ってこられるか？」といった姿勢のせいで失敗した例も、実験家たちのせいで失敗した例と同じくらい見てきた
システムごとに違い、製品ごとに違う。CTスキャナーのファームウェアを作るなら、新しい試みに対する向き合い方は、顧客100人のCRUD SaaSとは違っていなければならない
情熱的で過度にオープンなシニアがシステムを抜け出しにくい隅へ追い込むことも確かにあるが、PHP5で十分だと言う人たちもいる
良いシニアはその見極めができなければならない
すると技術判断をするときは副社長の言うことを聞いてElasticsearchを使え、という話になってしまう
もちろん行動が必要なときもあるが、今日ではバランスが必要以上にあらゆるものを複雑にする側へ傾いている
新しい製品やサービスを作るなという意味ではなく、作るなら全体のエントロピーが最も低い経路を探そうということだ。運用や技術的負債の削減にも当てはまる
早すぎる最適化は諸悪の根源である
スタートアップなのか、すでにキャッシュフローの強い大企業なのかによって、製品の中核機能を変える際の判断は変わる
記事は面白く読めたし、中心的なメッセージである相手に合わせてよりうまくコミュニケーションすることには同意する
ただ、フレーミングは正しい道から始まったものの、やや別の方向に曲がっていった感じがする
提示された二つのループは、どちらもより密で速いほど有利だ。一方はシステムをすばやく「安定」して保守可能な設定点へ連れて行き、もう一方は不確実性を扱う
AIによりうまく適応するためにシステムを分割しようという追加の洞察も、AIが主流になるずっと前からスパイクで説明されてきたことだ
自分の専門性を伝え共有しようとする意志には、たいていジュニア開発者側の需要がないと気づいた
おおむね開発者たちはメンターを探すことに関心がない。LinkedInプロフィールすら見ず、私を知識や専門性の潜在的な源泉とも見ていない
業界での30年の経験のあとに共有するものがないのではなく、共有する相手がいないのだ
経験の浅い開発者がURLバリデーターをAIマジックに置き換えようと言い出し、私はAIで事前充填したキャッシュベースのファジーマッチング解法を提案して反対したが、誰も気に留めなかった。今やAIモデルが突然停止し、システムは壊れてしまった。システム全体を再検証しなければならない
私より先に昇進した若い開発者が、これを直す方法を文書にまとめている途中で「Dan、これ手伝ってくれる？」と言ってきた。合理的に働くのではなく、文書を書いて会議をするのが前進のやり方だったから彼は昇進したのに、今度は私の仕事を使ってリーダーシップを示そうとしている
より良い解決策を提案するほど、経験の浅い開発者たちには脅威になり、だいたいは一応動くのでマネージャーも気にしない。自分にももっとうまく対処する方法はあったかもしれないが、くだらない話と戦うのに疲れすぎていて、ただ良いコードを書きたい
一方でジュニアたちは、話したり昼食を一緒にしたり、自分のやっていることを共有したがっていた。シニアたちは壁を作り、孤立していた
たぶんうちの職場だけかもしれないが、オフィスは重要だ
そこでは何人かのシニア開発者が、ジュニアに質問されると怒っていた。20年働いた人に何かを尋ねるだけでも勇気が必要だったのに、50%の確率で意地悪な対応をされた
良い学習経験にはなったし、今では意識的にメンタリングをしようと努めている
ここ数十年、断続的にメンターをしてきて、素晴らしいメンティーたちに出会う幸運に恵まれた。何人かは10年近く見てきたが、今ではとても良くやっている
どう見つけるかについてこれ以上役立つことは言えないが、そういう人たちは存在する
ところが私が到着した直後、彼は後任を見つけたと言って退職届を出し、結果として私にとってはうまくいかなかった
私が見てきた概念実証の大半は、勢いがつくとプロダクションになっていた
「軌道に乗ったら最初から書き直そう」と皆が約束したことは何度かあったが、そんなことは起きなかった
記事は責任と説明責任に触れているが、リスクを取る人にはそんなものはない。狂ったアイデアを急いで世に出し、顧客が食いつくことを期待して利益を得る。それをどう動かし拡張し、販売価格より運用コストが高くならないようにするかは、その人の問題ではない
右側のループを極端まで持っていった会社はいくつもあり、最近ではそのうち二つが非常に有名だ。何かをすばやく出して、線形にしかスケールしないので資金調達に走る。成功した会社であり、数えきれないほどのユーザーがいて、その一部は金も払っている。「これは持続可能か、出口戦略はあるのか」と尋ねるシニア開発者や常識的な人は解雇され、残るのは信奉者だけになる
エンジニアが非技術系のステークホルダーに言われたことをおとなしくやるだけだと、責任の空白が生まれ、いつか大惨事のように爆発したとき、いちばん自己弁護が下手な人が責められる
逆に、十分に視野を広げて「なぜ」を十分に問い続ければ、ほとんどどんなビジネス上の問題でも、システムを恐ろしい一方通行の扉へ押し込まない合理的なやり方で解ける
どこでもエンジニアリングにその権限が与えられているわけではないが、与えない場所は、判断を尊重してくれる場所へ去っていくシニアを引き留められない。技術的負債がビジネス上正しい選択であることもあるが、十分にシニアなエンジニアなら、常に出口を作っておける
ただしシステムの純粋性をビジネス課題より上に置くことはできない。システムのコストを支払うのはビジネスであり、それを忘れれば影響力の土台も失う
記事の結論は実質的に、古い助言である「一つは捨てるつもりで作れ」だ。私もMythical Man-Monthは読んだが、意思決定者をどう説得するかが問題だ
期待に届かなければ機能を無効化するか削除し、そうでなければレビューのうえで適切にリファクタリングした
チームの自律性は高く、スケジュールへの不満もほとんどなかった。たいてい他部門のほうが遅れていたからだ。マーケティングだけは常に「アイデア」を持っていた
それがプロトタイプや概念実証だという事実は、実際の問題が何かを列挙できないなら、本質的には重要ではない
多くのチームが技術的負債にはまり、大きなリスクで速度を落としていると不満を言うが、インシデント記録には大した件数がなく、危険なコードを本番で走らせたせいだと見なせるものもない。リスク登録簿にも「このコードは古くてひどく、サポート終了の依存関係がある」という項目はなく、どのチームも技術的負債がどう、どれほど遅くするのか説明できない
逆に、リリース前に自分たちのアプリをもっと「良く」できると言って何か月もリファクタリングしたチームも見た。価値提供はすべて遅れ、リーダーシップが怒るのは当然で、信頼もほとんど残らなかった
チームとステークホルダーの間に、納品についての良い対話が必要で、そうであれば皆が満足できる。しかしそれがなければ、常にステークホルダーが勝つ
根本問題であるインセンティブを見落としている。「会社」が何を望むかは重要ではなく、特定の意思決定をする人々が何を望むかが重要だ
新機能やアプリをリリースして会社のメトリクスのどこかに現れさえすれば職を維持できる人たちがいる。シニア開発者が悪いアイデアだと言っても、そうした人たちは聞かないか、気にしない。自分の仕事が懸かっているからだ
しかしプロダクト側なら顧客要求に機能を合わせる必要があるので、研究者には押し込みをやめるよう言うべきだ
本当に有能なシニアは、現在の会社の支配的な文化が何か、そして5年後に何が必要かを把握したうえで、それに合わせて適応する
5人のスタートアップには、ランウェイを縮めるような追加の複雑性は不要かもしれない。500人の会社には、あらゆる事業判断の二次的影響を緩和するためにその複雑性が必要かもしれない
「常に複雑さを避けろ」という白黒の論理ではなく、「意味があるときに複雑さを加えろ」であり、その問い自体も、ビジネスがあと数か月生き延びなければならない状況では非常に繊細になる
嵐が来る2時間前なら、アーキテクチャよりも「水が増えすぎてもう汲み出せなくなるのか？」を問うことになる
私が見る問題は、経営陣が実際にどれだけ資金が残っているのか、本当のスケジュールがどうなっているのかを語らず、駆け引きをすることだ。重要な瞬間の前に貢献者たちが去るのを恐れているからだが、その結果、人々はその文脈の中で愚かな判断をし続け、結局みんな新しい仕事を探すことになる
数日前から、チームにほとんどまったく同じ感情を伝えようとしていた。特に「新機能全体を作ってテストする必要があるのか？ 既存UIにボタンを一つ追加して、人が押すか見たのか？」という一文はほとんどそのままだった
プロダクト側が、もう自分たちの認知機能を使わなくていいと決めたあと、エンジニアたちが集団で苦しんでいるように見える。とにかく作って、ユーザーペルソナや有用性はあとで、あるいは永遠に、考えればいいという感じだ
以前はドメインやユーザー、製品がどんなプロセスに当てはまるのかを理解するのに時間を使っていたのに、今では架空のユーザーが欲しがると思い込んだものをただリリースし、成功するまで実験する
元記事が述べていたまさにその問題が起きる。バイブコーディングで作られた任意の機能はどれも不安定さとリスクの源泉になり、その対象について動作するメンタルモデルを誰も持っていないので、さらに多くのバイブコーディングでしか保守できなくなる
複雑さを単一の測定軸に還元できるとしても、それは解法空間の複数ある要素の一つにすぎない
保守性、拡張性、信頼性、レジリエンス、アンチフラジリティ、スケーラビリティ、汎用性、耐久性、合成可能性といった他の属性があり、しかもそれらすべてが常に当てはまるわけではない
単一の次元ではなく、解法空間におけるトレードオフとして語れる能力こそが、シニアやStaff+の開発者を分ける違いだと思う
一方で、これからの10人年にわたってこのシステム開発を簡単かつ迅速にする要素として捉えるなら、それは素朴なアプローチが正面突破しようとする場所を横から回り込む選択を意味する
ウサギとカメの寓話のように、最初の2週間を急いで燃やし、低い位置の果実や見えやすい成果、MVPを得て、その後は未熟な設計や開発中の保守のせいで速度が落ち続ける流れは理解しにくい。数週間は「速い」ように見えても、結局スケジュールは6か月遅れる
プログラマーであれば、結局のところ設計のあらゆる側面がトレードオフだと理解しなければならない