はじめに
ピープルウェアに下記の一節があります。
「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。」
個人的にも共感するところがあるので、参考になりそうな法則をいくつか集めてみました。
ソフトウェア開発における法則として知られているもの
現在では賛否ありそうですが示唆に富んでいるものが多いです。
ブルックスの法則
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」
私が新人の頃はソフトウェア開発においても「人海戦術」で乗り切れると考えられていました。
納期に間に合わせるための増員が逆の結果を生むという、悲劇。
パーキンソンの法則
「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する（第一法則）」
60年以上も前に提唱されたものですが、未だにある程度の説得力を持って語られます。
皮肉が効いてて面白いですが、前述のピープルウェアでは明確に否定されています。
見積もりや計画の際にこの単語が出てきたら、納期と寿命が縮むサインかも。
90対90の法則
コードの最初の90%が開発時間の90%を占め、残りの10%がさらに90%を占める
進捗が90%を超えたら急に小刻みになりがち、もこれに含まれそうですね。
組織・社会にまつわる法則
組織全般に適用されそうな社会学上の法則です。
ハインリッヒの法則
1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する
失敗学にも通じる法則ですが、実は90年も前の論文で紹介されたのだとか。
ソフトウェア業界でも、バグやヒューマンエラーに対して軽微なうちに対策を立てないと大きな障害に繋がりうるということを説明するの時に使われます。
軽微な問題のことをヒヤリ・ハットと言ったりもします。
割れ窓理論
建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される
ニューヨーク市のエピソードで有名な犯罪学の理論で、モラル低下は早めに防ぐべしというものです。
形骸化したルール、とっちらかったドキュメント、負債のあるコード、などが該当しそうですね。
ピーターの法則
能力主義の階層社会では、人間は能力の極限まで出世する。したがって、有能な平構成員は、無能な中間管理職になる。
なかなかインパクトのある法則で、個人的に好きな法則のひとつです。
研究によると、無作為に昇進させたほうがこの法則の影響を受けないため組織の効率が良いとかなんとか。
優秀なプログラマーが無能なマネージャーになる事例は枚挙にいとまがないです。
言い出しっぺの法則
最初に提案した人間が実行するべきであるという理念
しばしば、問題の指摘・課題提起に対して「言ったもん負け」になるときの法則。
正直、これがWikipediaのページとして存在しているとは思いませんでした。
グッドハートの法則
計測結果が目標になると、その計測自体が役に立たなくなる
目標は数値化できるとよいと言うのは正しいと思いますが、一つの指標のみにこだわったり、その数値が持つ意味をしっかり精査しないともともとの目標を見失ってしまうことになります。
類似のものにキャンベルの法則がありますが、こちらは指標を意思決定に用いるのはよろしくないというものです。
汎用的な、経験則に基づく法則
何にでも当てはまるような法則は開発の現場にも当てはまります。
パレートの法則
全体の数値の大部分は、全体を構成するうちの一部の要素が生み出している
「80:20の法則」の方がよく聞くかもしれませんが、経済や自然現象でも見られるものです。
開発の場合、8割のコードを2割のエンジニアが書いている、とかとか。
マーフィーの法則
起こる可能性のあることは、いつか実際に起こる。
失敗する余地があるなら、失敗する。
ソフトウェア業界ではあまり聞かないですが、この有名な法則で亜種も多くあるようです。
リスクについて検討するときにはこの概念を知っているかどうかは重要になります。
人間心理に関連する法則
心理学的なものは、スキルとかではないので、特性を理解して誤らないようにするのが肝要です。
バンドワゴン効果
ある選択肢を多数が選択している現象が、その選択肢を選択する者を更に増大させる効果
経済・政治的な集団心理による効果ですが、会議において賛成票が集まりだした案がよく思えて来る現象もこれに相当します。
ハロー効果
ある対象を評価する時に、それが持つ顕著な特徴に引きずられて他の特徴についての評価が歪められる現象
イケメンだから仕事ができそう、みたいなやつ。逆に、服装がズボラだから仕事が雑そう、というもの。
確証バイアス
仮説や信念を検証する際にそれを支持する情報ばかりを集め、反証する情報を無視または集めようとしない傾向のこと
成功シナリオをまとめた企画書、エラーケースのない仕様書、あたりも心理学的に説明がつくという。。
正常性バイアス
自分にとって都合の悪い情報を無視したり、過小評価したりしてしまう人の特性のこと
「自分は大丈夫」「今回は大丈夫」「まだ大丈夫」というやつ。
ソフトウェアエンジニアは基本的に最悪の事態を考慮するように教育されていることが多いですが、そうは言っても、です。
おわりに
これらの法則や効果についてはしっかり把握して対策すれば問題を回避できるものも多いと思います。
日々の業務においてもこれらの法則を意識することでよりよい開発環境を維持できるようにしたいですね。