全2回　IT部門が知っておくと便利な法則12選 《連載:第1回》 システム／ソフトウェア開発に役立つ法則

世の中には様々な法則がありますが、ビジネスにおいても同様です。その中から今回は、特にIT部門の仕事に役立つかもしれない法則を10個選んで紹介します。第1回目はシステムやソフトウェア開発に関する法則。実際にすべての法則がすべてのケースに当てはまる訳ではありませんが、知っておくと意外な場面で課題や問題の解決に役立つかもしれません。

ブルックスの法則

アメリカのソフトウェア技術者F・ブルックス氏が提唱した、「遅れているソフトウェアプロジェクトへの要員追加はプロジェクトをさらに遅らせるだけ」という法則です。その理由としてブルック氏は、コミュニケーションコストの増加、追加人員への教育が必要なこと、さらに人員が増えてもタスクの配分には限界があることを挙げています。

確かにソフトウェア開発は、人数が多ければ多いほど早く進むものではありませんし、10人で6カ月かかるプロジェクトが60人なら1ヵ月で終わる訳でもありません。事前の遅延対策はもちろんのこと、遅延してしまった場合は安易に人を増やそうとせず、まずは本質的な原因を突き止めて問題解決を図ることが重要と言えるでしょう。

ジャムの法則

NHK『コロンビア白熱教室』にも出演していたコロンビア大学S・アイエンガー教授による、「選択肢が多ければ多いほど、顧客の購買意欲は低下する」という法則です。スーパーマーケットで6種類のジャムを並べたときは買い物客の30％近くが購入したのに、24種類のジャムを並べたときは3%しか購入しなかったという実証的研究の結果から導きだされため、このように呼ばれています。

ITの領域ではWebサイトの構築やUI・UXデザインを考える際に参考にされており、例えばECサイトやランディングページで多数の商品を一度に表示したり、入力フォームの選択肢が多すぎたりすると、ユーザーはストレスを感じて離脱する可能性が高くなると言われています。

80:20の法則

ざっくり言うと「全体の数値の8割は2割の要素が生み出している」という法則です。イタリアの経済学者W・パレート氏によって提唱されたため、“パレートの法則”という名前でも知られています。。

ビジネスでは「全体の売り上げの8割は2割の商品（または顧客）が生み出している」といったように営業やマーケティングの領域で多く活用されていますが、ソフトウェアの品質管理においても、「発生頻度の高い上位20％の不具合がプロジェクト全体の80％の不具合件数を占める」といった形で使われることがあります。ちなみにその対策として有効とされているのは、発生順ではなく、発生頻度の高い上位20％の不具合から対応すること。そうすればプロジェクトへの影響を80％解消できるという訳です。

ハインリッヒ第1の法則

「1件の重大なアクシデントの背後には29件の軽微な事故があり、その背景には300件の異常（インシデント）が存在する」という法則です。1929年、アメリカでH・W・ハインリッヒ氏が労働災害5,000件超を調査して導き出した、労働災害における経験則の一つとして知られています。

近年、ITシステムのBCP（事業継続計画）である「IT-BCP」の整備が喫緊の課題として叫ばれていますが、大きなアクシデントを未然に防ぐためには小さなアクシデント＝ヒヤリ・ハットを減らしていくことも重要ということでしょう。リスクマネジメントとしては、ヒヤリ・ハット事例を収集し共有しておくことも効果的です。

KISSの法則

KISSは「Keep it short and simple.」または「Keep it simple, stupid.」の略語で、日本語で「短く（簡潔）かつ単純にしておけ」という意味。主にプレゼンや報連相など、コミュニケーションの領域で使われる法則（というより格言のようなもの）ですが、ソフトウェア開発においても重要な概念です。

コードにせよ外部設計にせよ、人は良いモノを作ろうとすると、どうしても複雑なやり方や構造を選んでしまうもの。しかしそれは、常にコストやリスクの上昇、あるいはユーザビリティの低下と背中合わせです。またプロジェクトで問題が発生した際も、状況を整理した上で“シンプルに考える”ことが大切なのは言うまでもありません。

コンウェイの法則、逆コンウェイの法則

初期のコンピュータ科学者・プログラマーであるM・コンウェイ氏が提唱した、「あるシステムを設計する組織は、その組織のコミュニケーション構造を反映した構造の設計を生み出す」という法則です。簡単に言い換えると「システム設計の構造は組織の構造に影響されやすい」ということになります。

現在ではこのコンウェイの法則を引っ繰り返して、「開発するシステムの構造に合わせた組織をつくるべき」という“逆コンウェイの法則”も使われており、とりわけマイクロサービスやクラウドネイティブといった分散型アーキテクチャの開発においては意思決定が迅速で柔軟性の高い自律分散型の組織づくりが重要とされています。

↓クラウドネイティブやマイクロサービスについては下の記事で詳しく解説しています。
【入門編】クラウドネイティブの特徴・メリット・事例