Kakugen.scala

import scala.util.Random

object Kakugen extends App {
  val arigataiKakugen = Array(
    "格言１ 一日は２４時間ある。 今日中という意味は明日の朝までという意味である。",
    "格言２ プログラムは思った通りに動かない。書いた通りに動く。",
    "格言３ 要求仕様はプログラム完成後に完結する。 基本仕様は完成品を顧客が見てから決定される。 詳細仕様は使用者がプログラムを動かしてから固まる。",
    "格言４ 私は、ソフトウェア設計には 二つの方法があるという結論に達した。 一つは、欠陥がないことが明らかなほど単純にする方法である。 もう一つは、明らかな欠陥がないほど複雑にする方法である。 　c.a.r.hoare",
    "格言５ コードは開発現場で書くんじゃない！　納品先で書くんだ！ デバグは納期前にするんじゃない！　運用後にするんだ！！",
    "格言６ 画面は青かった 。 （通信用語の基礎知識 より）",
    "格言７ 「無理です！」は言ったもん勝ち",
    "格言８ 文句があるならお前がやれ",
    "格言９ プログラマー殺すに刃物はいらぬ、仕様を三回変えれば良い",
    "格言１０ まず、他人を疑え、疑われた人が解決してくれるかもしれない。 （注　「まず自分を疑え」の方が一般的）",
    "格言１１ 開発に終わりはない。リリースがあるだけだ。",
    "格言１２ 仕様確定がどんなに遅れても納期は変わらない。 これを「納期不変の法則」という。",
    "格言１３ 顧客は水と仕様追加はタダだと思ってる。",
    "格言１４ 金払いの悪い客ほど口うるさい。",
    "格言１５ 開発スケジュールは小学生でもできる算数を無視して作られる。 営業とは１＋１が２であることを理解できない人の集まりである。",
    "格言１６ 一人倒れればみんな倒れる。",
    "格言１７ バグは夜更け過ぎに仕様に変わるだろう。",
    "格言１８ 良い仕様は一人の天才よりも三人の凡人を求める。 悪い仕様は百人の凡人よりも一人の天才を求める。",
    "格言１９ オーダーメイドのソフト料金の３０％は仕様の確認に当てられる。 ３０％は仕様の変更のためである。 ３０％はバグの検出のためにある。 初期仕様による作成に関わる料金の割合は結果として１０％しか残されていない。",
    "格言２０ 顧客にとってｓｅは部下であり、プログラマーは家畜である。 ｓｅにとって顧客は金であり、プログラマーにとって顧客は姿の見えない悪性のウィルスである。 駆除はｐｇを完成させる以外には困難である。",
    "格言２１ 顧客がｓｅに好かれる方法は、システム開発には時間と金がかかることを認識し、早めに仕様を完全に確定させることである。 ｓｅが顧客に好かれる方法はプログラマーに嫌われることである。",
    "格言２２ 金と時間があれば、どんなシステムでも作ってやると密かに考えているｓｅとプログラマーは数多い。 しかし、その機会が与えられることはない。",
    "格言２３ 品質は仕様変更の数と規模により、どれだけ劣化するかが決定される。",
    "格言２４ 営業とは空想が実現すると考える夢想家である。 ｓｅとは越えられない壁はないと信じる冒険家である。 プログラマーとは夢想家と冒険家によって漆黒の海に投げ出された漂流者である。",
    "格言２５ 有能なプログラマーが詳細設計を貰って最初にすることは、プログラムの目的を理解することである。 次にすることは、指定された方法と工数では目的を果たせないと言うことをｓｅに理解させることである。",
    "格言２６ プログラムとは運と勘によって作成される奇蹟である。 その両者がなければ、その工数でその仕様が実現できるわけがない。 仕様変更とは奇蹟にいちゃもんをつける罰当たりな行為である。 仕様追加は奇跡が二度起こると信じる無謀な行為である。",
    "格言２７ 自分が顧客なったつもりになれ、と言われてプログラマーが想像する。夢のようだ。",
    "格言２８ 趣味でプログラムを作成する人にとって技術とはプログラム言語スキルのことである。 職業でプログラムを作成する人にとって技術とはロジカル思考スキルとヒューマンスキルのことである。言語などマニュアルとヘルプを見ながらでも言うことをきくが、顧客はそうでもない。",
    "格言２９ システムは納品までの間、縮小を続ける。 要件定義で、社長を喜ばせる。 概算見積もりで、部長が現実的な案で妥協する。 運用打ち合わせで、課長が責任範囲を狭めようとする。 詳細打ち合わせで、担当者が覚えられる範囲に絞り込む。",
    "格言３０ ｓｅは持久力、プログラマーは瞬発力。",
    "格言３１ 定時に職場を出ると、仕事が増える。",
    "格言３２ 完璧なプログラムは完璧な時間と金が必要になる。 アメリカの国家予算使い放題のｎａｓａさえも、まだ時間と金が足りないらしい。",
    "格言３３ 詳細設計はソース内のコメントにて完結する。 コメントだけが唯一の自衛手段であるから、少なくとも本人が理解できるように書かれている。",
    "格言３４ 目で追う暇があるなら動かせ。脳細胞よりもｃｐｕのほうが解析が速い。そして、その間、休める。",
    "格言３５ 不具合をバグと呼ぶか仕様上の制限事項と呼ぶかは残された工数と納期によって決定される。",
    "格言３６ カジュアルデーは、世間では休日とか祝祭日とか呼ばれているらしい",
    "格言３７ 修羅場が続くと、殺気立ち怒鳴り声が多くなる。 さらに続くと、口数が少なくなり愚痴が多くなり、どんよりとした空気に包まれる。 もっと続くと、やたらと陽気になり、元気な声が響き渡るようになる。この状態を「プログラマーズ・ハイ」と呼ぶ。倒れる人が出てくるのはこの辺りからだ。",
    "格言３８ 遠くの火事は必ず燃え移ってくる。",
    "格言３９ 祈れ、そして働け。（修道院のスローガンより）",
    "格言４０ プログラムは頭で覚えるんじゃない、体で覚えるんだ。",
    "格言４１ 明日休めるのなら死んでもいい。",
    "格言４２ 外は雨だったんだ。昨日から降っていたのかな？",
    "格言４３ 心が荒まなければ、体が荒む。 非情にならなければ、自分が殺される。",
    "格言４４ 顧客は嘘を付く。営業は夢を語る。ｓｅは空想を話す。 プログラマーは無口になる。（独り言は多くなる）",
    "格言４５ ｓｅは「無理はするな」と無茶を言う、 営業は「無茶」と言うなと無理を言う。",
    "格言４６ 仕様書とは海図のようなもので、顧客とは海流のようなものだ。海流はよく変わり、海図は紙屑になる。プログラマーは海図のない海の上で自力で陸に辿り着かなければならない。",
    "格言４７ ぐだぐだ言うと金がかかるぞ。",
    "格言４８ 「はい、できます」と言いそうになったら１０秒数えろ。",
    "格言４９ 人はおよそ他人の失敗から学ぶことのできない動物だ。 値切る、変える、増やす、急かす、誰もみずほの失敗を教訓にしようとしない。",
    "格言５０ ベテランが気力を取り戻すための魔法の言葉 「それでも、昔に比べれば・・・」 新人がやる気を出すための魔法の言葉 「この仕事が終われば・・・」　彼らは、仕事の谷間など無いことをまだ知らない。",
    "格言５1 納期とは開発現場を会社から顧客先に変更する日である。",
    "格言５２ プログラマー・ｓｅ・マネージャーなどは職種ではない。役職だ。",
    "格言５３ 営業は最もやっかいな顧客である。",
    "格言５４ 問題に対してすぐさま解決法を決めつけるプログラマが多すぎる。 彼らは 1分考えて、1日をコーディングに費やす。 1時間考えて 1時間でコーディングする代わりに。  jon bentley",
    "格言５５ 綺麗な仕様では、バグが出ないとわかったの。汚れているのは、 設計なんです。何故こんなことに・・・",
    "格言５６ 運用後のデバグはバグを呼ぶ。",
    "格言５７ 追加要求を確定すると納期は確定できない。納期を確定すると追加要求を確定できない。これを納期と追加要求の不確定定理と呼ぶ。",
    "格言５８ 三つのデバグは一つのバグを産む。これをバグのエンドレスループという。",
    "格言５９ いやな予感は必ず当たる。 しかしプログラマーは、その悪い予感に対応しようとはしない。それはｓｅの仕事だ。",
    "格言６０ 修羅場を解決できる方法は、唯一、顧客が金を出してくれることだけだ。",
    "格言６１ 素人のオペレーターはバグを発見する天才である。再現不能。",
    "格言６２ 打ち合わせのたびに仕様が変わる顧客の操作マニュアルは、できあがったｐｇを操作しながら作成される。",
    "格言６３ 分からないときはｉｎｔｅｇｅｒよりｃｕｒｒｅｎｃｙ。ｃｕｒｒｅｎｃｙよりｖａｒｉａｎｔ。安全第一。（ｖｂプログラマーより）",
    "格言６４ ああ、それはマイクロソフトの仕様です。",
    "格言６５ プログラマーが不満に思う仕様は顧客も必ず不満に思う。",
    "格言６６ プログラマーに必要なスキルは、交渉・スケジュール管理・業務分析・提案・設計・言語・構築・保守・運用。 ｓｅに必要な能力は、これから言語・構築・保守・運用を引く。 マネージャーに必要な能力は、さらに業務分析・提案・設計を引く。 営業に必要な能力は、さらにスケジュール管理を引く。",
    "格言６７ 健康だからこそ、不健康なことができるんじゃないか。",
    "格言６８ し、仕様よ、仕様。でも、ちょっとだけ仕様じゃないの。 （fortune (back number)より）",
    "格言６９ それは、あなたが言った仕様ですよ。",
    "格言７０ 開発室の窓は開かない。その理由は昔・・・",
    "格言７１ 腐っても仕様。（fortune (back number)より）",
    "格言７２ se: 　しようがないな。 pg: 　コメント もありません。 （作り人知らずのｐｇの問い合わせに行き詰まった状態）",
    "格言７３ どうして、こんなことちょいちょいとできないんだ。 ちょいちょいとできたものに、あなたがちょいちょいと品質確認の印をついてくれるのでしたら。",
    "格言７４ 動かねぇバグは、ただのバグだ。（動くバグは仕様にできる）",
    "格言７５ 今日の害虫駆除でバグも死んでくれないかな。 え、ｗｉｎｄｏｗｓも死んでしまいますよ。",
    "格言７６ 顧客は最悪を考えず、最悪に対応しようとするのを悪質な費用のぼったくりだと思う。 ｓｅは最悪に備え、最悪に対応しようとする。 ｐｇは最悪を誰よりも予想し、最悪を無視する。",
    "格言７７ バグを起こさない唯一の方法は プログラムをくまないことだ。 次善の方法は、スケジュールと人員を定めた後は仕様の変更や追加の度にプロジェクトを見直すことだ。",
    "格言７８ 共同責任はプログラマーの責任。管理職？　何それ？　おいしいの？　食ったこたねぇなぁ。",
    "格言７９ もし転職するとしたら、定時で帰ることを「逃げる」と呼ばない職業がいいですね。",
    "格言８０ 職業プログラマーにとって美しいプログラムとは、単純で素朴なロジック、簡単で基本的なコマンド、豊富なコメント、つまり新人に近いプログラマーが初めて見ても直ぐに修正できるようなプログラムである。 そのためには単純で簡単な美しい仕様が必要である。しかし残念ながら顧客は素人だ。何故か凝りたがる。",
    "格言８１ 設計者が、設計以上のものを 製造者に求める分野なんてあるはずがないじゃないか。",
    "格言８２ 仕様書に書かれていないことをしても、また、仕様書に書かれていることだけしてもｓｅはプログラマーに文句を言うものだ。だからプログラマーは仕様書に書かれていることだけしかしない。",
    "格言８３ ｓｅがプログラマーに言う「常識」は、三時間毎に変化する。",
    "格言８４ 自分の仕様書を読んでください。動かないのが仕様です。",
    "格言８５ 無理ですというのは一日を何時間で計算しているんだ。一日は ３人日、一ヶ月は４．５人月あるんだぞ。",
    "格言８６ 工数は半分、単体テストを引き、システムテストを半分しにて、 納期は運用後二ヶ月を足して計算しています。",
    "格言８７ 金がもらえる仕様変更は受注要件だが、金が付かない仕様変更はｓｅの仕様の確認ミス 、とプログラマーからは見なされる。",
    "格言８８ もう疲れたよ。なんだかとっても眠いんだ。帰っていいかな。 （疲れただろ、僕も疲れたよ。なんだかとっても眠いんだ。仕様でいいよ、もう）")
  print(arigataiKakugen(Random.nextInt(arigataiKakugen.size)))
}

http://www.bsddiary.net/doc/misc.html#tetsuya