プロジェクトマネジメントに関する著名な原理・原則の一覧

プロジェクトマネジメントやシステム開発全般に関する、著名な原理・原則をまとめる。個人の思い付きで掲げた標語ではなく、世間的に知られているベストプラクティスなら、皆に従ってもらいやすいだろうという権威主義的な考え。

• コンウェイの法則 : Conway's law
  • 意味 : システムを設計する組織は、自分たちの組織のコミュニケーション構造をそっくりそのままコピーした設計を生み出してしまう
  • 例示 : 組織構造がバグの再現率に寄与する。組織自体のコミュニケーションが大事
  • 出自 : コンピュータ科学者、プログラマである Melvin Conway が1967年に提唱
  • 参考 :
    • Wikipedia - Conway's law
    • Wikipedia - メルヴィン・コンウェイ
• ブルックスの法則
  • 意味 : 遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである
  • 例示 : 新たに参画した開発者が生産性向上に寄与できるまでには時間がかかり、人員が増えるとコミュニケーションコストが増加するため、遅延解消には繋がりにくい。また、タスクを分解するにも限度がある
  • 出自 : 1975年に出版された Frederick Phillips Brooks, Jr. の著書「The Mythical Man-Month (人月の神話)」
  • 参考 : Wikipedia - ブルックスの法則
• ホフスタッターの法則
  • 意味 : いつでも予測以上の時間がかかるものである - ホフスタッターの法則を計算に入れても
  • 例示 : 「予測以上に時間がかかる」と思って見積しても、やっぱりそれ以上に時間がかかる
  • 出自 : Douglas Richard Hofstadter の1979年の著書「ゲーデル、エッシャー、バッハ - あるいは不思議の環」
  • 参考 : Wikipedia - ダグラス・ホフスタッター
• パーキンソンの法則 : Parkinson's law
  • 意味 : 「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」「支出の額は、収入の額に達するまで膨張する」
  • 例示 : 「データ量は与えられた記憶装置のスペースを満たすまで膨張する」「ある資源に対する需要は、その資源が入手可能な量まで膨張する」「どんなに大きな冷蔵庫を買っても、必ず満杯になる」
  • 出自 : 1958年、イギリスの歴史学者・政治学者シリル・ノースコート・パーキンソンが著作「パーキンソンの法則 : 進歩の追求」で提唱
  • 参考 : Wikipedia - パーキンソンの法則
• マーフィーの法則 : Murphy's law
  • 意味 : 「不都合を生じる可能性があるものは、いずれ必ず不都合を生じる」など、経験則に基づく教訓集
  • 例示 : 「起こる可能性があることは、いつか起こる」がベース。「洗車しはじめると雨が降る。雨が降って欲しくて洗車する場合を除いて」「落としたトーストがバターを塗った面を下にして着地する確率は、カーペットの値段に比例する」など。ほとんどはユーモア・ジョークの類なので、あまり盲信しないように
  • 出自 : 1993年のアスキー出版「マーフィーの法則」がよく知られるが、大本は1949年頃、アメリカ空軍の研究に携わっていた Edward A. Murphy, Jr. 少佐の発言をベースにパロディなどが寄せ集められて生まれたもの
  • 参考 : Wikipedia - マーフィーの法則
• ハインリッヒの法則 : Heinrich's law
  • 意味 : 1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する
  • 例示 : 些細なこと、ちょっとしたミスを軽視していると、その積み重ねでいつか重大な障害を起こしたりする。日頃から業務やマニュアルを見直したり、リファクタリングしたりすることが大事
  • 出自 : この法則を生み出した Herbert William Heinrich の1929年の論文「Relation of Accident Statistics to Industrial Accident Prevention」
  • 参考 : Wikipedia - ハインリッヒの法則
• 90対90の法則
  • 意味 : 「コードの最初の 90% が開発時間の 90% を占め、残りの 10% がさらに 90% を占める」「プロジェクトの 90% は予算の 90% を使用し、残り 90% も予算の 90% を使う」
  • 例示 : 最後の 10% と思っていたところが中々終わらないし、合計して想定の 180% の時間や予算がかかるもの。という皮肉・ユーモア
  • 出自 : ベル研究所の Tom Cargill が考え出し、1985年9月のACM学会誌「Communications of the ACM」の Jon Bentley のコラム「Programming Pearls」で著名になった
  • 参考 : Wikipedia - 90対90の法則
• パレートの法則 : 80対20の法則
  • 意味 : 「成果の 80% は、作業の 20% から得られる」
  • 例示 : ある事象・結果の8割の要因は、作業全体の2割の影響が大きい、ということ。作業全体からすると些細なことでも、結果の大部分に影響を与えたりする
    • 働きアリの法則と同様に、「組織の2割の人が大部分の収益を上げていて、その2割の人が間引かれると残りの8割中の2割が大部分の利益をもたらすようになる」など
    • プログラムの処理にかかる時間の 80% は、コード全体の 20% の部分が占める
    • 全体の 20% が優れた設計ならば、実用上 80% の状況で優れた能力を発揮する
  • 出自 : 20世紀初頭、イタリアの経済学者ヴィルフレド・パレートが発見
  • 参考 : Wikipedia - パレートの法則
• NIH 症候群 : 独自技術症候群 : 自前主義
  • 意味 : ある組織が、別の組織の製品やアイデアを採用したがらず、自前で再開発すること
  • 例示 : 俗にいう「車輪の再発明」が起こる原因の一つ。「目的を容易に達成できる既存ツールの存在を知らずに、自前で作ってしまった」という場合ではなく、「アレはどこそこが作ったオープンソースだから使わない」などというそれ以外の理由で独自開発すること
  • 出自 : 1982年の Katz, Ralph, and Thomas J. Allen の論文「Investigating the Not Invented Here (NIH) syndrome: A look at the performance, tenure, and communication patterns of 50 R & D Project Groups」が出典？
  • 参考 :
    • Wikipedia - NIH 症候群
    • Not Invented Here 症候群 : お前のアイディアがそんなに優れているはずがない
    • 拙記事 : 「NIH 症候群」は誰も得しない
• ピーターの法則 : Peter Principle
  • 意味 :
    1. 人間は能力の極限まで出世する。したがって、有能だったヒラ社員は、無能な中間管理職になる。
    2. 時が経つにつれ、人間はみな出世していく。無能なヒラ社員は、そのままヒラ社員の地位に落ち着く。有能なヒラ社員は無能な中間管理職の地位に落ち着く。その結果、各階層は、無能な人間で埋め尽くされる。
    3. その組織の仕事は、まだ出世の余地のある人間によって遂行される。
  • 例示 : ヒラ社員としては能力があるとして評価された人も、管理職になってより困難な問題を扱うようになると、段々と評価されにくくなっていく。「管理職としては無能」となった人はその地位に残り続ける。たとえ管理職として評価された人も、経営層に出世して同じように評価されるかというと難しく、「無能な経営者」に落ち着いてしまったりする。結果的に、どの層にも無能が溢れることになる。それでも仕事がなんとか進んでいるのは、その階層において出世の余地がある人の頑張りによってなされているから
    • 「働きアリの法則」「パレートの法則」に類似するもので、「2割の勤勉者」が何故いるかというと、この「ピーターの法則」でいう「出世の余地がある人間」ということになる
    • 優秀なヒラ社員が、優秀な管理職になるとは限らない。しかし人は「ある有効な手段を、別の困難な問題に応用したがる」ので、結果的に失敗する
  • 出自 : アメリカの教育学者ローレンス・J・ピーターの1969年の著書「ピーターの法則 - 創造的無能のすすめ」の中で提唱
  • 参考 : Wikipedia - ピーターの法則
• 大きな泥だんご : Big ball of mud
  • 意味 : 理解不能な構造がないシステムのこと。アンチパターンの一種
  • 例示 : 機能追加、拡充を繰り返したことで、当初のシステム化の目的や、システム化対象範囲がよく分からなくなってしまうシステム。「一つのプログラムは一つのことだけ上手くやれ」という UNIX 哲学に反した作り、といえる
  • 出自 : Brian Foote・Joseph Yoder の1997年の論文「Big Ball of Mud」によって普及
  • 参考 : Wikipedia - 大きな泥だんご
• HRT
  • 意味 : 謙虚・尊敬・信頼の3つの頭文字を取ったもの。「優れたチームが優れたソフトウェアを作るのに必要な三本柱」として提唱された、エンジニアが人に対して持つべきマインドセット
  • 例示 : HRT はチームメンバに対して持つべきマインドセットで、コードに対しては適用すべきでない。コードに対してはどちらかというと「プログラマの三大美徳」で挑むべき
  • 出自 : 書籍「Team Geek」
  • 参考 : 「プログラマの三大美徳」と「HRT」を使い分ける - 「コードを憎んで人を憎まず」

参考

• Qiita - 何かのときにすっと出したい、プログラミングに関する法則・原則一覧
• Wikipedia - Category:コンピュータに関する法則
• 人名を冠したソフトウェア開発の19の法則
• Wikipedia - アンチパターン
• Jargon! Jargon!
• Qiita - 技術系の名言まとめ++
• Qiita - 世界の凄腕エンジニア達からのプログラミングに関するお言葉集は不思議にココロを打つのでした