＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊  ９５／１／２７

［はじめに］

「失敗する可能性のあるものは失敗する」
　こんな、世の中の条理を皮肉ってとらえた機知と知性の「マーフィーの法則」
のソフトウェア編を、第２分科会では次のような観点からまとめてみました。

（１）本当はあってはならないことなのに、何も疑うことなく
　　　行われていることを言葉にする。
（２）望ましくないことなのに、その自覚が欠けているようなことを
　　　言葉にする。
（３）自分は外側に置いて他人をからかうようなことを避け、
　　　自分自身の反省を言葉にする。
（４）何となくまずいとは思っていても、どう扱ったらよいのか
　　　わからないようなことについて、
　　　自分の経験から学んだことを言葉にする。

それでは、第２分科会「ＱｕａＳＴｏｍの法則」を紹介いたします。


［作業に関する法則］

１．コンビ二の法則
ａ．線表が厳しく作業量が多いため、「徹夜で作業をして頑張ります」と申告
    した担当者が、夜の９時頃、近くのコンビニに買い出しに出かけて、持ち
    帰る買い物袋の大きさと、本人が主張する作業量は比例関係にある。
ｂ．コンビニの買い物袋の大きさと、その晩の徹夜作業の効率は反比例関係に
    ある。
ｃ．コンビニの買い物袋の大きさと、徹夜明けの翌朝その担当者から「徹夜勤
    務で体調を崩したため、今日は年休を取ります。」と、連絡が入る確率は
    比例関係にある。

２．木曜日の法則
　作業が間に合わないため「徹夜勤務をさせて下さい。」と担当者が申告する
  日は、木曜日が最大となる。

３．仕様変更発生の法則
　仕様変更が発生する時期は、変更すべきプログラムの試験が終了したときに、
  発生の確率が最大となる。

４．徹夜の法則
　どの案件にも深夜しか発生しないバグが必ず報告され、しかもほとんど解決
  されない。
５．コーディング量増大の法則
　エディタの高機能化により、コピーが容易にできるようになったため、関数
  （モジュール）丸ごとにコピーして、処理内容を少しだけ変更することが多
  い。よく考えて作り込んだ人ほどコーディング量が少なくなり、もっと生産
  性を上げろと指摘される。

６．仕様担当者とＰＧ担当者に関する法則
ａ．仕様説明の場で「ハイ」という回数が多いＰＧ担当者ほど理解度が低い。
ｂ．ＰＧ担当者は言われた仕様の通りにプログラミングするものである。
ｃ．仕様書の行間を読み取れるＰＧ担当者は稀である。（そのような有能な人
    はＰＧ担当者でいられない）
ｄ．仕様担当者の常識とＰＧ担当者の常識は同じとは限らない。

７．協同開発の法則
ａ．協同開発の形で開発を進めると、必ず担当者のいない作業が実在する。
ｂ．その作業は誰にも見えない。そのかわり問題点として表面化する。

８．「混沌」が」好きな開発担当者の法則
ａ．ラウンドトリップ型開発手法が出てきて喜んでいる。（ウォーターフォー
    ル型では工程が戻るような作業は否とされていたが、検討モレも仕様変更
    も「プロトタイピング」で済ませられるから。）
ｂ．「あなたに任せたのだから・・・」と詳細検討したがらない。そのくせ検
    収時に「ここが駄目、違っている、こう変えたい。」と言う。再検収する
    と、また「やっぱりこう変えたい。」と言う。
ｃ．開発とは混沌の中で頑張るものだと思いこんでいる。混沌だからゆえ、所
    属長または第三者から分析／評価する対象の物がなにもなく、いつも評価
    の対象から漏れる。

９．発言の法則
ａ．「頑張ります。」と言って、行なった人ほど成果は出ない。
ｂ．「大丈夫です。完璧です。」と言って、納品してきた人の仕事ほどバグが
    多い。
ｃ．「時間がないので」と言って、正規開発手順を踏まない人ほど生産性が低
    い。また、この人の成果物は、まさにスパゲッティ状態が多い。

１０．ツールの法則
ａ．必要だと思って作ったツールは、完成と同時に不要になる。
ｂ．あれば便利と思って作ったツールは、本番環境では使用されない。

１１．快感の法則
ａ．「こうしてもうまくいきませんよ。」と言っているにも関わらず、ユーザ
    に「いいから、やれ！」と言われ、うまく行かない時が、人生最高の快感。
ｂ．もし、うまくいってしまった時は、人生最低の不快感。


［バグやテストに関する法則］

１２．朝寝坊の法則
ａ．朝寝坊をし、会社に出社すると上司に怒られるため、最近顔を出していな
    い客先に立ち寄ると、納品済みソフトウェアに故障が発生していることを
    知らされる。
ｂ．しようがないから、客先で故障の解析と修復を行い帰宅すると既に深夜と
    なっている。
ｃ．翌朝、朝寝坊のため遅刻し、結局上司に怒られる運命となる。

１３．バグ発生の法則
　品質報告会でバグの出方が少ないので、「対策をうて！」と言われたため、
  問題処理票を捏造した結果、次の品質報告会では必ず「バグの発生が異常
  なので、至急対策をうて！」と言われる運命にある。

１４．泥沼の法則
ａ．あるバグを自分のミスではないと一度言い張ってしまうと、あとで気づい
    ても謝りにくくてこっそり修正することになり、でも結局それがバレて信
    用をなくす。
ｂ．はまり具合と独り言の多さは比例する。

１５．バグの法則
ａ．バグは手抜きしたテストケースの中で眠っている。
ｂ．そのバグは、発生して一番困る状況でバグが目をさます。

１６．バグの裏と表の法則
　内部的にはかなりの件数のバグが出ているのに、客先に対しては、もっとも
  らしいバグ検出／修正の報告をする。もっともらしいバグの検出／修正報告
  は、注意が必要である。もっともらしくないバグの検出／修正報告も注意が
  必要である。ということは、バグの検出／修正報告の数はそれほど重要でな
  い？内容が重要である。

１７．バグシート循環の法則
ａ．テストで発生したバグの情報から様々な解析ができるようにするため、バ
    グシートの書式を変更した。記入項目を増やし、記入要領まで作成した。
ｂ．これで安心していると、バグシートに必要な項目が記入されていないこと
    に気づく。
ｃ．開発者に注意を促すと、とりあえず記入するようになる。これで安心して
    いると、書かれている内容に誤りを発見することになる。
ｄ．さらに悪いことに、バグ管理システムには、何も知らない担当者が忠実に
    誤ったデータを入力している。したがって、これらから解析した結果は意
    味を持たなくなってしまう。
ｅ．結局、最初の書式のバグシートを使う運命となる。

１８．「そして誰もいなくなった」の法則
ａ．作成後１年たったプログラムがバグった場合、その担当者は大体会社を辞
    めている。
ｂ．担当者がいた場合、その人は他のプロジェクトで忙しい。
ｃ．担当者が自分だった場合、仕様を忘れている。

１９．「山は必ずやってくる」の法則
　効率のよい仕様作成は、効率の悪いテスト工程をまねく。
  ^^^^

２０．電話の法則
ａ．仕事の効率は外からかかってくる電話を取る回数に反比例する。
ｂ．そのため電話に出るのをやめていると、上司から「なぜ電話を取らないの
    か」と叱られる。
ｃ．しかたなく電話を取るとバグの報告を受ける羽目になる。

２１．テストケース発見の法則
　デモを見せようとする時が、テストケースを作る絶好のチャンスである。


［見積やスケジュールに関する法則］

２２．見積り規模報告の法則
ａ．どうせ仕様追加・変更が発生するため、見積り規模を３割り増しで客先に
    報告すると、既に担当者が３割り増しで報告してきているため、全体では
    ２倍近くとなっている。
ｂ．客先もそのことを知っているため、契約額を半分に減らしてしまう。
ｃ．最後に、仕様追加・変更が発生し、結局損をしてしまう。

２３．遠隔端末不調の法則
ａ．急いで仕上げなければならないプログラムの量と、遠隔端末からエディッ
    トしていて回線障害に遭遇し、端末が使えなくなる確率は比例関係にある。
ｂ．そのとき、隣の遠隔端末で、進捗管理データを投入している上司の、ＪＵ
    ＳＴ−ＰＣの快調さと、くやしさは比例関係にある。
ｃ．夕方、進捗管理のミーティングの時、「遠隔端末が不調であったため、進
    捗が芳しくありません。」と伝えると、その上司から「お前の操作が悪い
    からだ。」と言われる運命にある。

２４．運用試験開始の法則
ａ．作業完了予定日に、実は完成していない唯一のプログラムは、翌日から開
    始される運用試験で最初に動かされる運命にある。
ｂ．しようがないから、頑張って徹夜でそのプログラムを完成させると、翌朝、
    運用スケジュールが変更となったことを聞かされる。
ｃ．どうせスケジュールが変更になると考え、そのプログラムは翌日からとり
    かかることとして帰宅し、翌朝出社すると、既に運用試験が開始され、そ
    のプログラムができていないことがバレている。

２５．納期遅延の法則
ａ．納期遅延の長さと回線障害、ツール不良など（特に自責でない）突発的ト
    ラブルの発生報告件数は比例関係にある。
ｂ．納期遅延の対策と蕎麦屋の出前は等価関係にある。
ｃ．納期遅延解消の見通し報告日と納期遅延の解消予定日とは並行関係にある。

２６．スケジュール遅延・自己満足の法則
　仕事を抱え込む人ほどスケジュール遅延する。そして悪いことではなく、し
  ようがないことだと思っている。

２７．宴会の法則
　忙しさと宴会は同じ周期でやってくる。

２８．進捗率の法則
ａ．ある作業をする場合、その作業の後半になると、９２％、９５％といった
    具合に、進捗率は急に伸びなくなる。このような場合、隠された大きな課
    題があると見てよい。
ｂ．管理体制が不十分と思われるプロジェクトにおいては、作業の進捗率から、
    進み具合を読み取る場合、一の位の数字は意味を持たないと考えるべきで
    ある。また時には、十の位の数字も意味を持たないと考えるべきである。

２９．納品の法則
　自信のないシステムほど、出来る限り早く納品すべきである。


［常識に関する法則］

３０．お客様の法則
ａ．技術レベルと顧客満足度は比例しない。
ｂ．こちらのミスをある程度正直に話すと客先に信用されるが、それを過ぎる
    と馬鹿にされる。
ｃ．裏機能が客に知れると、仲良くなるか喧嘩になる。
ｄ．部分的に心配な箇所があるとお客さんは必ずそこを突いてくる。またそれ
    はお客さんのレベルによらない。

３１．情報不可逆の法則
　顧客、生産性、品質などの情報は常にラインからスタッフにながれ、その逆
  は成り立たない。

３２．本音と建前の法則
　ソフトウェア業界では多業種から学べという人と、ソフトウェアは別物とい
  う人が、往々にして同一人物である。（かくして何も変わらない）

３３．ソフトウェア企業の法則
ａ．バブル期においては、「当社のようなソフトウェア企業は人が財産、した
    がって人材には投資を惜しまない」という経営者の発言回数と、その経営
    者自身の財産の増加は比例関係にある。
ｂ．現在においては、人材の投資は減少するが、経営者自身の財産は減少しな
    い。

３４．”今後の課題”不変の法則
　技術論文、ＱＣ活動等で発表される”今後の課題”は、次の論文、活動でも
  常に不変の課題として変わらない。

３５．ダメなプロジェクトの法則
　時間の経過とともに、窓際に並ぶ上長の机が増えてくる。ミーティングが少
  なくなり責任の所在が曖昧になる。そのうちプロジェクトマネージャーが交
  代する。しかし、交代してもあまり現状と変化がない場合が多い。最終的に
  は、担当者が苦労に苦労を重ねて納品までこぎつける。
（管理者の皆さん、仕事の進め方を明確に示してくれ、システム的な観点から
  物を見てくれ、意識の統一を図ってくれ、という担当者の意見が聞こえてき
  そうだ。）

３６．ＩＳＯ９０００シリーズ取得の法則
　ドキュメント類が必ず増大する。しかし、本当に必要となるドキュメントは
  （作り方を変えない限り）それほど多くない。そして、審査の時には「量が
  多ければよいわけでない」と小言をいわれるが、「ない」と指摘される。

３７．沈黙の法則
　本当によくわかっている人ほど喋らないものである。

３８．謝罪の法則
　謝るときの声の大きさと、客先の怒りの静まり具合は比例する。


［おわりに］

　第２分科会版マーフィーの法則（ソフトウェア編）は如何でしたでしょうか。
きっと皆さんの中にも「うん、そうだよな」とか、「そんなことってあるよな」
と感じた方もいらっしゃるのではないでしょうか。
　日頃ソフトウェア開発の中で、何も疑うことなく起こっている出来事の中に
も、ずいぶん反省・改善が必要なことがあるように感じます。皆さんも一度自
分の周りを見回してみたら如何でしょうか。輝ける未来のソフトウェア業界の
ためにも。

>Top