/note/tech

ソフトウェアに関わる人が知っておくといいかもしれない法則10個

コンウェイの法則

「システムを設計する組織は、その組織の構造をそっくりまねた構造のシステムを設計してしまう」という法則。

例えば、1つのソフトウェアを複数のチームが協力して作るとき、そのソフトウェアはチームと同じ数のモジュールに分割された内部構造を持つシステムとして設計されてしまう。

コンピュータ科学者メルヴィン・コンウェイ氏により提唱された。

パレートの法則

「全体の数値の8割は、全体を構成する要素のうちの2割の要素が生み出している」という法則。

イタリアの経済学者ヴィルフレド・パレートが発見した。

グッドハートの法則

「計測結果が目標になると、その計測自体が役に立たなくなる」という法則。

数値目標が重視される組織では、組織の構成員はその数値目標を達成することを優先し、本来の目的を見失い、場合によっては不正な手段に走ってしまうことに対する警鐘が込められている。

英国のエコノミストであるチャールズ・グッドハート氏により提唱された。

パーキンソンの法則

「第1法則:仕事の量は、その仕事を完成させるために与えられた時間をすべて満たすまで膨張する。第2法則:支出の額は、収入の額に達するまで膨張する」という法則。

元は英国の官僚制を観察して導かれた経験則だが、コンピュータに適用されたバリエーションとして「データ量は与えられた記憶装置のスペースを満たすまで膨張する」なども存在する。

英国の歴史学者・政治学者シリル・ノースコート・パーキンソンの著作「パーキンソンの法則:進歩の追求」で提唱された。

ブルックスの法則

「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則。

フレデリック・ブルックス氏の著書「人月の神話」で提唱された。

リトルの法則

「自分が行列に並んだときに、1分待って、前に並んでいる人数を後ろに並んでいる人数で割ると、何分待つかが予測できる」という法則。

リトルの法則は、ソフトウェアの性能テストにおいて応答時間などの見積もりや改善に応用できる。ケース・ウェスタン・リザーブ大学にいたジョン・リトル(John Little)氏によって証明が発表された。

ピーターの法則

「能力主義の階級社会においては、誰もがその能力の極限まで出世してしまう。例えば有能な平社員は無能な中間管理職に出世する。そして最終的には各階層が無能な人間で埋め尽くされてしまう」という法則。

教育学者ローレンス・J・ピーター氏とレイモンド・ハル氏の共著による書籍で提唱された。

ハインリッヒの法則

「1件の重大事故の背後には、重大事故に至らなかった29件の軽微な事故が隠れており、さらにその背後には300件もの危険な状況、いわゆるヒヤリハット(ヒヤリとしたりハッとしたりする危険な状態)が隠れている」という法則。

1920年代にアメリカの損害保険会社に勤めていたハーバード・ウィリアム・ハインリッヒ氏に由来する。

ピーク・エンドの法則

「人はある出来事に対し、感情が最も高まったとき(ピーク)の印象と、最後の印象(エンド)だけで全体的な印象を判断する」という法則。

心理学・行動経済学者のダニエル・カーネマン氏が1999年に発表した論文の中で提唱された。

ホフスタッターの法則

「物事はつねに予測した以上の時間がかかるものである。あらかじめホフスタッターの法則を計算に入れていたとしても」という、複雑な作業にかかる時間は正確に見積もることができないことを示す法則。

ダグラス・ホフスタッター氏の1979年の著書「ゲーデル、エッシャー、バッハ」の中で提唱された。