第7章法則

ここで言う法則とは、ソフトウェア開発で陥りやすい罠のことである。
こうするとこうなるという、否定的な結果を生み出す経験則である。
望ましくない結果とそれにつながる行動の因果関係を把握しておくことで、未然に問題を防ぐことができるかもしれない。

ブルックスの法則

スケジュールが遅れているからと言って安易な人員追加を行うと、さらに遅延を招き、火に油を注ぐ結果となる。
プロジェクトの工数は人×月の人月で管理されることが多いが、この人と月は可換ではない。
人数が多くなった場合、作業の独立性が低いほど生産性は直線的には増加しないし、人数分の教育コストもかかる。

スケジュール的に遅れが出た場合は人員を追加するのではなくリスケジュールするべきである。
人員の追加もメンバーに無理をかけるのもデメリットが大きいことだと認識しなければならない。

コンウェイの法則

ソフトウェアの構造であるアーキテクチャは、それを作った組織の情報を反映する。
ソフトウェアの設計は、組織構造が持つ文脈に従ってアーキテクチャを構成しがちである。

本来は効率的なアーキテクチャを設計した後で組織を構成するのが良い。
組織に依存したアーキテクチャより、よいアーキテクチャを作った上でそれに組織構造を適合させていくほうが明らかに効率が良い。

割れた窓の法則

放置された割れた窓は、次第に建物全体へ悪影響を波及させることになる、という法則である。
ソフトウェアでもこれは同様で、小さな欠陥を放置してしまうと、それを気がついた人に投げやりな感覚を植えてしまい、ソフトウェア全体を腐敗へと進めていくループに陥ってしまう。
長く放置されている欠陥はそれ自体が些細なものであっても、それを見る人を「自分がちゃんとやっても仕方がない」「どうせ誰も見ていない」といった感覚にさせる。

設計、意思決定、コードなど、欠陥を作らないようにすべきだし生じた場合は速やかに直すべきである。
悪いところは見つけたら即座に直す、修正できなくても問題点のある箇所を把握しておく。
悪い部分を放置しないというチームの雰囲気がソフトウェアの腐敗を防ぐ。

エントロピーの法則

自然現象の議論ではエンタルピーとエントロピーを合わせた自由エネルギーの増減に着目することは一般的である。
特にエントロピーに着目してみれば、系の安定化とエントロピーの増大は基本的にセットで発生する。
複雑な定義を持つエントロピーだが、エントロピーは物理学の文脈では乱雑さの指標とされる。
ここで、ソフトウェアの複雑さの増大に伴う無秩序さをエントロピーと捉えるとすると、ソフトウェア開発でもエントロピーが増大しコードが無秩序になるのは自然な傾向である。

エントロピーが増大しやすい傾向や兆候を掴み、そこに自然的ではなく人為的な操作を加えることでエントロピーの増大を抑えることになる。
硬いコード、脆いコード、移植性のないコード、扱いにくいコード、複雑なコード、繰り返しの多いコード、わかりにくく不透明なコードなど、危険な箇所を抑えるようにしたい。
開発への取り組み方に、エントロピーの増大に対応しやすい手法を採用することも良い対策である。

80-10-10の法則

当初の要求から進めた時、全体の作業の80%は短時間で実現することができる。
しかし、残り20%のうち10%は実現可能だがコストがかかり、さらに残り10%は実現が不可能である。
もし100%を要求された場合、かなり泥臭い作業によって実現していく道を行くことになる。
プログラミングに万能薬がないことは周知の通りで、泥臭いやり方が必要なケースは少なからずあることは受け入れなければならない。
また、ピンポイントの要求に応えてくれる専門的なツールが存在する場合もあるので、効率化する道も模索しながら地道な作業に取り組んでいきたい。

ジョシュアツリーの法則

名前を知らなければ気にならないものでも、名前を認識した途端にそれが見えるようになり、気が付けるようになるという法則である。
目に見えない概念的なものでも命名することで意識できるようになることも多い。
チームでユビキタス言語を使用し、認識に要するコストを削減していきたい。

セカンドシステム症候群

セカンドバージョンはもっとも危険性の高いバージョンである。
プログラマがその開発に慣れてきて多くの機能を追加した結果、コードの品質が落ちる上に使い勝手も悪いものになるというケースが多い。
クライアントもプログラマも、慣れてきたからといってあれこれ手を付けるのではなく、ユーザー目線で本当にセカンドバージョンに必要なものをイメージしたい。
もちろんセカンドバージョン以降の開発でも留意する必要がある。

車輪の再発明

すでに存在していて利用できるものは作らない。
工数が無駄になるし、たいてい既存の広く使われているものは品質も良い。
仮に出来上がったとして、標準の規格を無視した独自路線は、移植性がなくあまり使い勝手が良くならない可能性も高い。
知識不足でうっかり作ってしまったというケースや作りたいから作ったというケースが考えられる。

あくまで本来やるべき作業に注目し、作らなくていい部分は作らないということを徹底したい。

ヤクの毛刈り

ヤクという毛量が多い牛の一種がいる。
ヤクの毛刈りをすると、あまりの毛量の多さに体になかなか到達しない。
プログラミングで問題を取り組んでいるときも、次々と別の問題が発覚して当初の問題にたどり着かないことがしばしばある。
この全体像の見えてこないヤクの毛刈りはストレスのたまる作業である。

こうなってしまったら早々に問題から切り上げるのが良い。
時間に対するリターンが割に合わないことも多い。
切り上げるときは他の人が同じ轍を踏まないように備忘録を残すと良い。

どうしてもヤクの毛刈りに立ち向かわなければならないときは脳がオーバーフローしてしまわないように問題を整理しながら進めたい。