理解の喜びと力

 (binaryigor.com)
3 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • ソフトウェアを深く理解すれば、ツールに振り回されず、自分が責任を負うシステムに対する コントロールとオーナーシップ を持てる
  • 検索やLLMは素早く答えをくれるが、説明できない解決策をコピーする習慣は、修正する力や 中核的な能力 を弱めるおそれがある
  • 使い捨てスクリプトや低リスクな内部UIでは、生成やコピペが合理的なこともあるが、長く保守するコードは 深く理解している技術 で作るべき
  • 生産性をコード行数やPR数のような output だけで測ると簡単に歪み、安定したリリース・単純化・自動化・テストのような outcome の方が長期的価値に近い
  • 現代のソフトウェアはランタイム、ネットワーク、セキュリティ、データベース、AIまで複雑になったが、基礎原理 を身につければ新しいツールやアプローチをより速く理解できる

理解がもたらすコントロールと楽しさ

  • 深い理解は、コードやシステムを修正し変更するための 実質的な条件 である
  • 理解していない対象は修正や変更が難しく、最終的には自分が責任を負うコードに対するコントロールとオーナーシップも弱くなる
  • 理解はツールの主人になれるだけでなく、心理的な満足感も与える
  • 環境をよりよく制御できる行動がポジティブな感情と結びつくのは自然なことだと考えられる

人間の怠惰とLLM依存

  • 人間には、エネルギー消費を減らし、投資に対する報酬を最大化しようとする傾向がある
  • この 怠惰さ は、退屈でコストの高い作業を自動化する動機になる一方で、学習や熟達においては弱点になり得る
  • インターネットとLLMのおかげで、似た問題の答えを望む形で簡単に得られるため、理解のプロセスを飛ばしやすくなっている
  • SQLを自分で学ぶ代わりに、テーブルと欲しいデータをLLMに伝えて結果だけをコピーすれば当面は楽だが、きちんと扱う能力は身につかない
  • LLMがSQLをより速く作ってくれても、過去に自分で繰り返して培った読む力・理解する力は、使わなければ衰える
  • LLMや検索エンジンは、最良の場合 能力増幅器（force multiplier） だが、その前提として強い基礎力が必要である
  • 中核的な技術と知識は、検索・プロンプト・手動検証だけでは維持しにくく、自分で構築し創作する過程に参加しなければならない
  • 定期的に怠惰な傾向に抗い、文書やソースを読み、解決策の理由やツールのトレードオフを理解し、解決策やアルゴリズムを自分で設計する必要がある

短期的生産性と長期的理解のバランス

  • すべてのコードや解決策を完全に理解しなければならないわけではなく、状況に応じて基準を変えてよい
  • 重要度とリスクが低い 使い捨てスクリプト であれば、コピーしたり生成したりしても構わない
  • 2〜3人が使う内部UIやページでも、同じやり方が許容されることがある
  • 何か月、あるいは何年も所有・保守・進化させるコードは、深く理解している言語と技術で作るべきである
    • すべての行、単語、文字、設定オプションを理解できる、あるいはその方向を目指すべきである
    • 今すぐ多くの成果物を出すことより、長期的な理解・保守性・生産性を最適化すべきである
  • MVPや既存製品内の実験的機能のように、成功するか不確実な場合は、品質と理解の基準を少し下げてもよい
  • こうした選択は 認知的負債 を負うことに近い
    • 今はより速く動ける
    • 製品や機能が動き、修正や変更が必要になれば、あとでより多く返済しなければならない
  • それでも最低限、自信を持って「動く」と言える程度には理解し、検証すべきである
  • 場合によっては、いったん生成して検証し、最初から書き直す戦略が合理的なこともある

技術スタックと熟達の複利効果

  • たまにしか使わないプログラミング言語、ライブラリ、ツールであれば、深い学習や熟達に多くの時間を投資しなくてもよい
  • 結果を検証できるなら、部分的にしか理解していないものをコピー・生成するやり方も、ときには問題ない
  • しかし学習と苦労の段階を飛ばすと、その技術に熟達し、生産的に扱える可能性を自ら減らすことになる
  • 定期的に使う中核的な技術スタックでは、熟達 が数百倍、数千倍の報いをもたらし得る
  • 知識と技術には 複利効果 がある
    • より多くを知るほど、自分でより速く作れるようになる
    • 新しい知識や技術も、ますます速く習得できるようになる
    • 能力が伸びるほど、新しい解決策やアイデアを思いつけるようになる

OutputよりOutcomeに合わせた生産性

  • 生産性を理解し測定する方法は、大きく output中心 と outcome中心 に分けられる
  • outputの測定は簡単で、数字で数えやすい
    • 生産したコード行数
    • 作成してマージしたPR数
    • 実装した機能数
    • 発見して修正したバグ数
    • 完了した作業数
  • output中心の指標は簡単に操作できてしまう
    • 冗長なコードを書けてしまう
    • 小さなPRを大量に作れてしまう
    • 作業を人為的に細かく分割できてしまう
    • 役に立たない機能を追加できてしまう
  • 数字が増えても、それが正しい方向だとは限らない
    • PRが多いほど必ずしも良いわけではない
    • コードベースが大きくなることが常に望ましいわけでもない
    • 機能を足すより、使われていない機能を削除する方がよいこともある
  • outcome中心の例は、長期的価値とより直接結びついている
    • 新しいCI/CDプロセスにより、本番リリースが安定する
    • リファクタリングと単純化によって、保守と今後の変更が容易になる
    • 統合ソリューションの再設計によって、新しいパートナーの追加が速くなり、計算資源を節約できる
    • テスト を増やして、バグを事前に発見し、回帰を防ぐ
    • 指標とアラートを追加して、潜在的な問題やバグを先回りして発見する
    • 退屈な手作業を自動化して、時間を節約し、致命的なエラーの可能性を減らす
  • 長期的な生産性と理解はoutcome中心の指標とよりよく一致し、outputが多いことが常により良いことを意味するわけではない

複雑化するソフトウェアと基礎原理

  • ソフトウェア工学の基本定理は、「コンピュータ科学のどんな問題も、もう一つの間接層で解決できるが、間接層が多すぎる問題を除いて」という文で要約される
  • 現代のソフトウェア開発は、多くの層と要素のため非常に複雑である
    • ランタイムとプラットフォーム: ブラウザ、サーバー、クラウド、モバイル、デスクトップ、組み込み
    • ネットワーク: HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC、データベースやメッセージブローカーのプロトコル
    • セキュリティ、認証、認可
    • オペレーティングシステム
    • 仮想化、コンテナ化、Kubernetes系オーケストレーション
    • データベース: SQL, NoSQL, ローカル、リモート、分散
    • 高水準プログラミング言語と、コンパイラ・インタプリタ・トランスパイラのパイプライン
    • ライブラリ、フレームワーク、パッケージマネージャ
    • APIと外部サービス
    • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
    • LLMとAI
  • 複雑性に対応できる理由もある
    • 多くのシステムは過剰設計されており、かなり単純化できる
    • ある期間においては、通常、ソフトウェア開発の地形の小さな一部分だけを専門的に習得すればよい
    • 残りは認識レベルで十分なこともある
    • ツールの背後にある一般的なパターンと原理を身につければ、新しいツール・アプローチ・技術を学ぶ際のてことなる

基礎原理の範囲と効果

  • 基礎原理 とは、ソフトウェア開発で使われるツール、ライブラリ、フレームワーク、プロトコル、構成要素の下にある、基本的で変わりにくい規則・制約・メカニズムのことである
  • 中核的な範囲には、複数の分野が含まれる
    • コンピュータアーキテクチャとハードウェア: CPU構造、命令実行、メモリ階層、レジスタ、キャッシュ、ストレージ装置
    • 機械語、アセンブリ、高水準言語: アセンブラ、コンパイラ、インタプリタが必要な理由と言語タイプごとのトレードオフ
    • オペレーティングシステム: プロセス、スレッド、スケジューリング、ロック、同期、仮想メモリ、ファイルシステム、IPC、システムコール、I/O
    • アルゴリズム、データ構造、複雑度解析
    • ネットワーク: コンピュータ間通信、信頼性、スループット、レイテンシ、階層構造
    • データベースとデータシステム: ACID、トランザクション、分離レベル、インデックス、保存方式、関係、データモデリング
    • ソフトウェア設計とアーキテクチャ: モジュール性、依存関係と責務の管理、情報隠蔽、カプセル化、階層、クライアント-サーバー、イベント、結合度と凝集度
    • 状態とデータフロー: 識別性、単一の信頼できる情報源、競合解決、キャッシュとメモ化、状態の無効化、状態機械、一貫性と同期
    • 分散システム: CAP定理、レプリケーション、遅延、パーティション、合意、サービスディスカバリ、結果整合性
    • 並行性と並列性: ロック、同期、並列化可能性、競合状態、デッドロック
  • すべての分野を習得する必要はなく、また可能でもないかもしれないが、各分野を少しずつ知り、自分が選んだいくつかで卓越することを目指すべきである
  • 基礎原理に焦点を当てると、時間の経過とともに 普遍的な直感 というメタスキルが生まれる
  • コンピューティングとコンピュータが単体でもクラスターでもどう動くかを深く理解すれば、絶えず変化するツールやフレームワークの細部に振り回されにくくなる
  • このレベルに達すると、新しく流行するツールを学ぶこともずっと容易になる

理解の喜びと影響力

  • Leonardo da Vinciの言葉のとおり、「もっとも高貴な喜びは理解する喜び」である
  • ソフトウェア開発において、理解は喜びだけでなく、実践的な影響力と力も与える
  • ソフトウェア工学の範囲は非常に広いが、基礎原理 に集中すれば、扱える領域は広がる
  • 現在の認知的限界を継続的に押し広げていく姿勢が、定期的な喜びと影響力の拡大につながる

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rs のコメント

  • このブログ記事の全体的なトーンが本当に気に入った
    最近は「内部で何が起きているのかも分からないがツールを作った」という類いの文章をあちこちであまりにも頻繁に見かけるので、それを誇らしげに語る雰囲気にうんざりしている

    • その通り。深い理解こそが本当の優位性を生み、新しいアイデアや洞察につながる
      しかも、その過程自体がとても楽しいのも大きい

  • 興味深い記事だったし、人々に理解していない成果物を出すよう迫る流れには、ある程度意図的なものがあると思う
    AI研究所の立場から見ても、経済的な理由は明らかだ。人々が自社製品に依存しなければ、バリュエーションを正当化し始めることはできず、ユーザーの能力を弱めるのもその方法のひとつだ
    ちょうど今日、似たような記事を書いたのだが、本当に学んで習熟する喜びという中心的な前提を共有している: https://hgrsd.nl/blog/simplicity-agency-and-mastery/

    • 共有ありがとう。主体性と雪だるま効果についての指摘が特によかった
      主体性は絶対に手放してはいけないし、より多くを知り、より多くをできるほど、さらに多くを知り、できるようになるという好循環が生まれる。本当に美しく前向きなフィードバックループだ

  • この記事に恐ろしい vibecoding タグが付いていないのがうれしかった。実際、こういう話は何十年も前から、もっと短く、たいていはもっと不平混じりの版で語られてきた
    ソフトウェアは恐ろしいほど複雑なので、認知的ショートカットは多く、ある時点では生き残るために必要ですらある。だが人間には、慎重であるべきときほど怠けやすい傾向がある。コンピュータは厳密なモジュール化と相性がいいが、人間はそうではない
    この記事が、理解を単なる「義務」ではなく、何かがどう動くのかを理解することがどれほど楽しいかを強調しているのがよかった。世界を理解することを楽しめない人もいるのだろうが、自分の性格にとってはあまりにも中核的な部分なので、ほとんど理論上の存在のように感じる。そういう喜びがないなら、ソフトウェアのキャリアを始める前に考え直した方がいい

    • この記事には vibecoding タグが見える
      最近はほとんどすべての記事に vibecoding タグが付くレベルなので、むしろ発想を逆転して non-vibecoding タグを導入した方がよいのかもしれない。バイブコーディングではないもの、あるいはバイブコーディングの利点についての記事だけをそうタグ付けし、残りはそのままにしておく、というやり方だ。残念ながら、これが新しい標準のように見える
      自分の感情とも「バイブ」が合う良い記事だ

  • 学ぶことが本当に好きで、記事で扱われている「部分的にしか把握していない何かを生成し、それを理解するためにさらに時間を費やさなければならない」状況についても、個人的にはそうした認知的負債は嫌いではない
    興味のある問題領域であれば、その負債を返済して理解を得るために時間をかける意思がある。結局のところ、同じ理解にたどり着くための別ルートのように感じる
    リーンスタートアップの概念も思い出す。目に見える何かがあれば、真っ白な画面を前に何が重要か推測する代わりに、具体的な対象を分解しながら始められる。どこから始めればよいか分からない方がもっと悪く、AIは素早く走り出すのを助けてくれる
    まだうまく整理できていないのは、経験の少ないジュニアがどうやって悪い臭いを嗅ぎ分け、異議を唱える直感を育てるのかという点だ。自分のAIの使い方は非常に反復的で、改善のためにソクラテス式問答のように扱っている。現在のツールで可能なワンショットのバイブコーディングの世界とはかなり違う

    • 「経験の少ないジュニアがどうやって悪い臭いを嗅ぎ分け、異議を唱える直感を育てるのか」という部分について、昨年末に業界に入りたての親しい友人や家族がいる
      現実的には、以前とそれほど大きくは違わないと思う。よりシニアな人たちが助言し、反論もしてくれるし、ほとんどの技術系企業にはピアレビューもある。だからジュニアが完全にひとりきりというわけではない。むしろ、失敗して適応する時間は十分にある

  • 多くの基礎的なテーマをかなりたくさん列挙している点がよかった
    読者はこれを Gish gallop や parading of horribles のようなレトリックだと受け取りがちだが、実際には私たちの生活のあらゆる瞬間に交差している基礎理論が何十個も存在すると自分は思う
    コンピュータも、ひとつの統一理論でプログラムされているというより、多くの小さな理論をつなぎ合わせた overlapping set-inclusion diagram に近い

  • とても楽しく丁寧に読み、何人かの友人にも共有した
    スピードを落とすことがますます難しくなっているので、新年には基礎学習に公に取り組もうと https://writing.tidefield.dev/hello-world-again/#honing-my-focus も書いた
    「2026年以降は、基礎的で、すぐに流行遅れにならないものを学ぶつもりだ…」という方向性が同じでうれしい