2011.09.21 yossy a.k.a. 会長
はいどうも～。
本日はhidetarouの番ですが休業中のため代打でしゃしゃり出たエンジニア吉田です。
「○○○な●●つの○○○」なんて感じのタイトルを付けると、
なんだか興味が惹かれるというのを目にしたので活用してみました。
※個人的にはそうでもない気がしている。
というわけで、今回はソフトウェアに関係しそうな「法則」を５つほど紹介し、
それをソフトウェア開発業務にどう生かしていくかを考えてみます。
本日ご紹介する法則は以下の5つです。
でわでわ、早速。
「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」
これは、IBMのOS/360（メインフレームOS）の開発者であるフレデリック・ブルックスが
名著「人月の神話」で提唱したプロジェクトマネジメントに関する法則です。
プロジェクトが遅延している時に、新しい人をプロジェクトに参画させても、
その人の作業パフォーマンスよりもコミュニケーションにかかるコストが
上回ってしまい、結果的にさらに遅延するといった感じです。
確かに、ドキュメントがなかったり、きちんと引き継ぎ資料がなかったりすると、
打合せやら仕様確認やらにかなりの時間が取られたりしますからね。
きちんとしたドキュメントがあれば、コミュニケーションにかかるコストを
多少は下げられるんじゃないかと個人的に思ったりしているので、
この法則からは 「ドキュメンティングは大切なのだ」 と、学んでおきたいと思います。
【参考】 ブルックスの法則 - Wikipedia
「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」
これは、例えば何らかのソフトウェアを開発する場合、そのソフトウェアを
開発するチームを5つに分けて進めた場合、ソフトウェアの構造も大きく5つに
分かれた形で開発されますよね、といった感じの法則です。
確かに、ソフトウェアを作るのは人ですから、チームの構造がそっくり
ソフトウェアの構造に反映されるというのも納得ができますね。
裏を返すと、それらのチームが上手にコミュニケーション取れている場合は
ソフトウェアも品質が高くなるということかもしれませんね。
この法則からは 「コミュニケーションは大切なのだ」 と、学んでおきたいと思います。
【参考】Conway's Law - Wikipedia
「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」
これは、例えば、本来5日で終わるプログラムの仕事を10日間のスケジュールで
与えた場合、その仕事は10日間いっぱいかけて完了される、という法則です。
時間的な余裕があると、仕事の密度が薄くなり、無意識のうちに無駄な時間を
使っている可能性があるのかもしれませんね。
仕事は自分に厳しくストイックに望む姿勢が大切だと感じさせられます。
この法則からは 「自己管理は大切なのだ」 と、学んでおきたいと思います。
【参考】パーキンソンの法則 － ＠IT情報マネジメント用語事典
「不都合を生じる可能性があるものは、いずれ必ず不都合を生じる」
これは、バグの匂いが感じられるものは、いずれバグる。と捉えてしまってよいでしょう。
この法則も裏手にとると、ソフトウェアの不都合は気づいた時点ですぐに
取り払ってあげることで、品質が向上するということに繋がりそうです。
また、その不都合に気づくためには、十分なテストを実施することも重要ですね。
この法則からは 「テストは大切なのだ」 と、学んでおきたいと思います。
【参考】マーフィーの法則 - Wikipedia
「1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する」
これは、例えるならば、1つの重大なシステム障害の背後には、29のエラーログが出力されており、
その背景には300のインデントミスやスペルミス、命名規約ミス、不適切なコメント、重複したコード、
環境に依存したコード、といったような「コードの臭い」が存在する、といった感じでしょうか。
ソフトウェア開発ではちょっとしたミスでも徹底して直していく姿勢が重要ですね。
この法則からは 「リファクタリングは大切なのだ」 と、学んでおきたいと思います。
【参考】ハインリッヒの法則 - Wikipedia
以上、5つの法則を紹介してみましたが、他にも興味深い法則がまだまだあります。
以下のサイトに様々なソフトウェア開発に関連する法則が紹介されていましたので、
興味のある方は参考にしてみては如何でしょうか。
【参考】人名を冠したソフトウェア開発の19の法則
デワデワ。
