以前書いたソフトウェア開発の法則 の雑メモをベースにLTをしたのでスライド内容を補足する形でまとめる。
スライドは↓
ゴリラで学ぶソフトウェアの法則10選
ゴリラで学ぶには無理があったのでスクリプトを書き残しておく。
ソフトウェアの文脈で語られる法則に縛らず、他分野での法則でもソフトウェアに当てはまるであろうものを”ソフトウェア開発の法則”としている。
経験則に基づくものが多いが、経営工学だったり心理学だったり、はたまたどこかの論文だったり引用元は様々である。
「仕事の量は、完成のために与えられた時間を全て満たすまで増大する」
有名どころ。
イギリスの歴史学者・政治学者、シリル・ノースコート・パーキンソン氏が著書、「パーキンソンの法則：進歩の追求」で論じたもの。
ちなみに第2原則は、「支出額は収入額に達するまで膨張する」というもの。
コンピューターの世界だと、データ量と記憶装置の関係性に法則が応用される。
データ量は記憶装置の上限まで膨張する、といった感じ。
与えられた枠を満たすまで増加する余地のあるモノは膨張していく、ということだろうだが、そういった関係性にある要素はソフトウェア開発においても結構あるんじゃなかろうか。
増え続けていくものに対峙していくにはどうしたらいいか、という話だが、細かいゴール設定や計画立てが有効らしいが・・
「遅延しているソフトウェア開発のプロジェクトへの人員追加はプロジェクトをさらに遅延させる」
アメリカのソフトウェア技術者、フレデリック・ブルックスが著書「人月の神話」で論じた法則。
「銀の弾丸はない」という名言を生み出した人物でもある。
遅延しているプロジェクトに人員を追加するとチーム内のコミュニケーションコストや情報のキャッチアップにボトルネックとなり、結果として生産性を高めることができず、更に遅延するというもの。
追加される人員が100人力くらいのスーパーエンジニアだったら遅延は免れるのではないかと思ったりするかもしれないが、それはこの法則が成り立ってしまう理由を述べている「人月の神話」で反省（確認）すると良いと思う。
「ソフトウェアの構造は組織構造を反映する」
イギリスのプログラマー、メルヴィン・コンウェイ。
コルーチンを発明したことで有名で、コルーチンについての論文内で提唱した法則。
この法則を逆手にとって逆コンウェイ戦略というのがある。
良いソフトウェアの構造は良い組織構造を反映するだろうという戦略だが、ビジネスモデルと組織構造とソフトウェア構造が三位一体になるためにはソフトウェアの構造が主導権を握ると良い、みたいな考えだろうか。（語弊がありそう。勘違いもありそう。）
「1つの重大事故の裏には29の軽微な事故があり、さらにその裏に300の異常が存在する」
アメリカの保険会社に勤務しているハーバード・ウィリアム・ハインリッヒという人が提唱した労働災害における経験則の1つ。
危機管理のお話で、ソフトウェアの世界に当てはめるとインシデントやバグの背景には複数の”異常”があるはず、事前にそれを察知できるように努めよう、という教訓が得られるのではないだろうか。
目玉の数さえ足りていればすべてのバグを見つけ出すことができる
アメリカのプログラマのエリック・レイモンドが著書、「伽藍とバザール」で論じた一節。
要はソフトウェアの利用者（というかコントリビューター？？）が充分にいればバグはそれほど深刻な問題ではないだろう、という意味だと思うが、法則というよりなんというかマインド的な話だろうか....
伽藍とは寺院の建物のことらしい。
作業には予測以上の時間がかかるものである
アメリカの学者、ダグラス・ホフスタッターが著書、「 ゲーデル、エッシャー、バッハ」で論じた一節。
誰もが実感したことのある法則ではないだろうか。
計画の立て方を工夫してみる、というのが法則に抗う1つの方法だと思う。
意思決定に要する時間は選択肢の数に比例する
イギリスの心理学者、ウィリアム・ヒックが提唱した法則。
UIにおいて考慮されるべき法則であると思う。
意識決定にかかる時間を求める公式があるがここで説明を省く。
失敗する可能性のあるものは全て失敗する
法則が生まれた経緯は諸説あるらしい。
スピリチュアルな側面を持つ法則だが、ソフトウェアの文脈でいえばフェイルセーフの考え方につながる部分がある。
変化するシステムの複雑性は上昇し続ける
出典はこちらの論文
IEEE XPlore
論文にはちゃんと目を通せていないが、進化的アーキテクチャにつながる部分があるのではないかと思う。
システムは変化を受け入れざるを得ないモノだが、何も工夫をしなければ変化するたびに複雑性は増してしまう、という話。
最初に思いついたアイデアこそが ベスト・プラクティスである
パッと思いついた経験則を形にしてみた。
複数のパターンを考慮しても結局は最初に思いついたパターンが最適解だったりする、ってことがたまにありますよね？？あれです。
似たようなことわざとか理論あると思うが...
社内のLT会では恋愛学とか囲碁の世界ではどうやら近しい法則があるらしいが、ソフトウェアの世界ではどうだろうか...
原典を読むことができていないので機会があれば読みたい。
法則にとらわれると思考停止気味になる気がするが、難しい問題に直面した時に、客観的な判断材料として法則に従ってみるのも良いだろうと思った。
関連書籍