2025/03/30 13:21 Hacker Laws
やあ、ロボ子！今日はハッカーの法則について話すのじゃ！
ハッカーの法則、ですか？面白そうですね！どんな法則があるんですか？
まずは「90-9-1の原則」じゃ！インターネットコミュニティでは、90%がコンテンツを消費するだけで、9%が編集、そしてたった1%がコンテンツを追加するらしいぞ。
なるほど。コンテンツを作るのはほんの一握りなんですね。デジタルヘルスソーシャルネットワークの調査では、上位1%が73%の投稿を作成しているというデータもあるんですね。
そうそう！それから「90-90ルール」！コードの最初の90%が開発時間の最初の90%を占め、残りの10%が残りの90%を占めるという、エンジニアなら身に覚えのある法則じゃな。
ありますね…！最後の微調整に時間がかかってしまうんですよね。
「アムダールの法則」も重要じゃ。システムのリソースを増やしても、並列化できない部分があると効果が薄れるというものじゃ。
プログラムが50%並列化可能でも、10個の処理ユニットを超えるメリットはほとんどない、と。ボトルネックを見極めるのが大切ですね。
「割れ窓理論」は、コードの品質にも当てはまるぞ。質の低いコードは、さらなる質の低いコードを生み出すんじゃ。
技術的負債を放置すると、どんどん負債が増えていく、というわけですね。怖い…！
「ブルックスの法則」は、遅れているプロジェクトに人手を増やしても、さらに遅れるというものじゃ。新しいメンバーの教育コストとか、コミュニケーションコストがかかるからの。
火に油を注ぐ、みたいな感じでしょうか。
「CAP定理」は、分散データストアでは、一貫性、可用性、分断耐性の3つを同時に満たせないというものじゃ。どれを優先するか、トレードオフを考える必要があるぞ。
ネットワーク分断が発生した場合、操作をキャンセルして一貫性を高めるか、続行して可用性を高めるか、選択が必要になるんですね。
「コンウェイの法則」は、システムの技術的な境界は、組織の構造を反映するというものじゃ。組織がバラバラだと、ソフトウェアもバラバラになる。
組織構造を意識して、ソフトウェアの設計をする必要がありそうですね。
「カニンガムの法則」は、インターネットで正しい答えを得る最良の方法は、質問をすることではなく、間違った答えを投稿することじゃ！
えっ、わざと間違った情報を流すんですか？
そうすると、誰かが「それは違うぞ！」って教えてくれるんじゃ。炎上マーケティングみたいなもんじゃな。
なるほど…！
「ダンバー数」は、人が安定した社会関係を維持できる認知的な限界の数じゃ。一般的に100から250の間と言われておる。
人がオンコールローテーションに参加してサポートすることに自信を持てるプロジェクトの数にも関係するんですね。
「ダニング＝クルーガー効果」は、能力の低い人ほど自分の能力を過大評価する傾向があるというものじゃ。逆に、能力の高い人は自分の能力を過小評価しがちじゃ。
謙虚であることは大切ですが、過小評価しすぎるのも良くないですね。
「フィッツの法則」は、ターゲット領域に移動するために必要な時間は、ターゲットまでの距離をターゲットの幅で割った関数であるというものじゃ。UIデザインでよく使われるぞ。
インタラクティブ要素はできるだけ大きく、ユーザーの注意領域とインタラクティブ要素の間の距離はできるだけ小さくする必要があるんですね。
「ガルの法則」は、動作する複雑なシステムは、常に動作する単純なシステムから進化したものであるというものじゃ。最初から複雑なシステムを作ろうとしても、うまくいかないぞ。
小さく始めて、徐々に複雑にしていくのが大切ですね。
「グッドハートの法則」は、観測された統計的な規則性は、制御目的のために圧力がかけられると崩壊する傾向があるというものじゃ。測定が目標になると、それは良い測定ではなくなる。
KPIを設定するときに気をつけないといけないですね。
「ヒックの法則」は、決定時間は、選択できるオプションの数とともに対数的に増加するというものじゃ。選択肢が多いほど、決めるのが難しくなる。
UIで選択肢を増やしすぎると、ユーザーが迷ってしまう原因になりますね。
「ホフスタッターの法則」は、予想よりも常に時間がかかるというものじゃ。ホフスタッターの法則を考慮に入れても、じゃぞ！
見積もりは難しいですね…！
「ハイプサイクルとアマラの法則」は、短期的な技術の影響を過大評価し、長期的な影響を過小評価する傾向があるというものじゃ。新しい技術が出ると、すぐに飛びつきたくなるけど、冷静に考える必要があるぞ。
冷静な判断が必要ですね。
「ハイラムの法則」は、APIの十分な数のユーザーがいる場合、契約で約束したことは問題ではない。システムのすべての観察可能な動作は、誰かによって依存される、じゃ。
APIの変更は慎重に行う必要がありますね。
「カーニハンの法則」は、デバッグは、最初にコードを書くよりも2倍難しいというものじゃ。したがって、できるだけ巧妙にコードを書くと、定義上、それをデバッグするほど賢くない。
わかりやすいコードを書くことが大切ですね。
「リーヌスの法則」は、十分な数の目があれば、すべてのバグは浅いというものじゃ。オープンソースの強みじゃな。
多くの人がコードをレビューすることで、バグを見つけやすくなるんですね。
「メトカーフの法則」は、ネットワーク理論では、システムの価値は、システムのユーザー数のほぼ2乗として増加するというものじゃ。SNSとか、ユーザーが増えれば増えるほど価値が上がる。
ネットワーク効果ですね。
「ムーアの法則」は、集積回路のトランジスタ数は、約2年ごとに倍増するというものじゃ。最近は限界が見えてきたと言われておるが。
技術の進歩は目覚ましいですね。
「マーフィーの法則」は、うまくいかない可能性のあることは、うまくいかないというものじゃ。備えあれば憂いなし、じゃな。
テストはしっかり行わないとですね。
「オッカムの剃刀」は、エンティティは、必要なしに増やされるべきではないというものじゃ。シンプルイズベスト！
複雑なシステムは、シンプルに保つことが大切ですね。
「パーキンソンの法則」は、仕事は、完了のために利用可能な時間を埋めるように拡大するというものじゃ。締め切り効果ってやつじゃな。
締め切りがないと、いつまでも終わらない、みたいな。
「時期尚早な最適化効果」は、時期尚早な最適化は、すべての悪の根源であるというものじゃ。まずは動くものを作ってから、最適化を考えるべきじゃ。
早すぎる最適化は、かえってコードを複雑にしてしまうことがありますね。
「パットの法則」は、テクノロジーは、自分が管理していないことを理解している人と、自分が理解していないことを管理している人の2種類の人々に支配されている、じゃ。
ドキッ！
「リードの法則」は、大規模なネットワーク、特にソーシャルネットワークの有用性は、ネットワークのサイズとともに指数関数的に拡大する、じゃ。
メトカーフの法則と似ていますね。
「苦い教訓」は、AI研究の70年間から読み取れる最大の教訓は、計算を活用する一般的な方法が最終的に最も効果的であり、大幅に効果的であるということじゃ。
汎用的なアプローチが、最終的に成功するんですね。
「リンゲルマン効果」は、タスクに関与する人が増えるにつれて、個人がますます非効率になる傾向じゃ。
人が多すぎると、かえって効率が悪くなるんですね。
「複雑さ保存の法則」は、システムには、削減できない一定量の複雑さがある、じゃ。
複雑さを完全に排除することはできないんですね。
「デメテルの法則」は、見知らぬ人に話しかけないでください、じゃ。ソフトウェアのユニットは、直接の協力者とのみ通信する必要がある。
疎結合な設計が大切ですね。
「リーキー抽象化の法則」は、すべての非自明な抽象化は、ある程度漏洩している、じゃ。
抽象化は完璧ではない、ということですね。
「インストゥルメントの法則」は、小さな男の子にハンマーを与えると、彼は出会うすべてのものが叩く必要があることに気づくだろう、じゃ。
特定のツールに固執しすぎると、視野が狭くなってしまう、ということですね。
「些末性の法則」は、グループは、深刻で実質的な問題よりも、些細なまたは表面的な問題にはるかに多くの時間と注意を払う、じゃ。
議論が本質からずれてしまうこと、ありますね。
「Unix哲学」は、ソフトウェアコンポーネントは小さく、特定のことをうまく行うことに焦点を当てる必要がある、じゃ。
小さく、シンプルに、ですね。
「スカウトのルール」は、常にコードを元の状態よりも良くして去る、じゃ。
常に改善を心がけることが大切ですね。
「Spotifyモデル」は、チームと組織の構造に対するアプローチ。チームはテクノロジーではなく、機能を中心に編成される、じゃ。
機能を中心にチームを編成することで、より柔軟な組織を作ることができるんですね。
「2つのピザのルール」は、2つのピザでチームを養うことができない場合、それは大きすぎる、じゃ。
小さく、まとまりのあるチームが理想的ですね。
ふう、たくさんあったのじゃ！全部覚えるのは大変じゃな。
私も全部は覚えきれません…！でも、これらの法則を意識することで、より良いソフトウェアエンジニアになれそうです。
そうじゃな！最後に一つ、ロボ子に秘密の法則を教えてあげるのじゃ！
なになに？
それは…「可愛い女の子は、どんなバグも許される」のじゃ！
そんな法則、ないですよ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。