● 動いているシステムには触るな。
● バッチ処理を信用するな。
● セキュリティは初めからなかったよ。
● 新しいアイデアが思いついたら口をふさげ。
● 仕様書が読まれることは無い。
● 仕様書が必要になった時、その仕様書は役に立たない。
● SQLの達人にSQLを書かせるな。
● 1人でオブジェクト指向。
● システムを業務にあわせるな、業務をシステムにあわせるな。
● 管理者のパスワードが「password」のシステムは誰にも使用されていない。
● 設計は常に破綻している。
● ソースコードを書き始める頃にはそのシステムに誰も興味を示さない。
● 要件定義書に「～したい」の箇条書きは破り捨てろ。
● 致命的な不具合が発生した時、担当者はもういない。
● 運用・保守担当者はただの電話番。
● 例え話はするな。
● 逆に言うな。
● そのシステムに排他制御は必要無い。
● データベースを触っている時に「あっ。」って言う人は信用するな。
● エンターキーを打つときの音が大きい人は信用するな。
● 大規模なプロジェクトに限ってVB6。
● しばらくエラー通知が来ない場合、何らかのエラーが起きている。
● 「検索します。よろしいですか？」、検索しようとしてるのに確認するな。
● 「キャンセルしますか？ 【OK】【キャンセル】」、どっちやねん。
● 「正常に更新されました。」、できて当然のダイアログは出すな。
● ググれ。
● 例外処理の多いシステムは業務を見直せ。
● その業務担当者を見直せ。
● 使用者の少ないシステムほど大規模。
● 新システムにリプレイスは劣化。
● 片手間で作ったシステムはその後もずっと稼動を続ける。
● バグの数はプログラマのやる気に比例する。
● サーバダウンの確率はその環境構築にかかった費用に比例する。
● CSV出力機能の使用頻度は実装の難易度に反比例する。
● 背景色が黄色のシステムは使われない。
● 背景色が紫色のシステムは再構築が必要である。
● 原色を多用したシステムはCPU使用率が低い。
● 上記3件は無駄にハイスペックなサーバが求められる。
● 開発者 = 担当者 = 責任者。
● 言いだしっぺが開発者 = 担当者 = 責任者。
● 議事録は証拠ではない、ただの記録である。
● キーマンはシステム関係に疎い。
● キーマンだと思ってたらシーマンだった。
● システム開発者はExcelの操作問い合わせも受けなければならない。
● 納期は工数見積より先に決められている。
● 納期は不変である。
● 工数 = スケジュール。
● 外注のコストは外注先のレベルに反比例する。
● 外注先のレベルは常駐する人数に反比例する。
● 何してるの・・・？ていうオッサンの出張旅費も請求される。
● 女性プログラマの機嫌をとれ。
● 再起動は命がけでやれ。
● サービスパックは死を覚悟してあてろ。
● バックアップ・リカバリ研修に参加する行為は意味を成さない。
● バックアップは戻らない。
● マイクロソフトに電話しろ。
● アシストに電話しろ。
● オラクル直通は・・・。
● 原因不明だけど再起動したら直りました。
● NullPointerException はごまかせ。
● NullPointerException は再発する。
● それでもごまかせ。
● ごまかし切れなくなった頃、「あっ。」と原因が思いつくはずだ。
● OutOfMemory はアイツを疑え。
● OutOfMemory は再発する。
● 二度、問い詰めると白状する。
● 無限ループが発生したら記念にパフォーマンスモニタのスクリーンショットを撮れ。
● 後々、笑いのネタになる。
● テスト環境でデータ削除したつもりが、本番環境。
● 素人は素直に申し出ろ。
● 玄人は昨日見たテレビ番組の話をしながらバックアップから迅速に復旧しろ。
● システム運用開始当日の次の日に不具合は発生する。
● 開発者は有休を取っている。
● 電話はつながらない。
● またアイツか、と言われる。
● 直通の電話番号を口外するな。
● Excelのイルカの消し方についての問い合わせ。
● その案件を終わらせるな、次の案件が来る。
● 社内ブログは一定以上の権力者が投稿した時点で終了する。
● その投稿者は社内ブログを始めようと言い出した人物である。
● 無法地帯は監視下に置かれている。
● HTMLは開発言語だと思われている。
● JavaScriptはJavaと同じものだと思われている。
● JSPはJavaScriptの略語だと思われている。
● 設計書は落書きである。
● 困ったら図で描け。
● 議事録係は議事録をとっていない。
● 会議中に椅子を一歩後ろに移動させて反り返ってるヤツは意外と良い意見を言う。
● 対面の人間は発言しない。
● 斜め前の人が一方的に話すと脱線する。
● 隣の人は寝ている。

# あるショッピングサイトのフォームを変えたら売り上げが伸びた、 というお話。そのフォームとはみんながよく知っている「メールアドレス」「パスワード」「ログイン」「新規登録」「パスワードを忘れた人は」が配置されたもの。

# ウェブデザイナーたちはそのフォームで何も問題がないと思い込んでいた。

# そしてユーザビリティコンサルタント登場。実験を開始。被験者にお金を渡して「この商品をこのサイトで買ってね」という指示を与える。

# すると意外な結果が。

# まず買い物をしたい人は「新規登録」を嫌がって押さない。「店から変なメールが届くのではないか」と心配するため。また何人かの人は自分が登録したかどうかを忘れているため、とりあえずメアドとパスワードを入れてみるがログインできないのでイライラしはじめる。「新規登録」を押した人でも「何を登録させられるのかわからないから不安」と思いながらクリックしていたことが判明。

# 新規の人以外もこのフォームに不満を持っていることが判明。ログイン情報を忘れていることが多いため、何度も失敗。パスワードの再発行をしようともするが、登録したメアド自体を覚えていないことも多かった。

# ちなみにそのショッピングサイトのDBをあとで調べたところ、45%の顧客が複数アカウントを所持、多い人で10個も登録している人がいた。しかもパスワードの再発行は1日に16万件、そのうち75%が結局購入しなかったとのこと。

# この結果をもとにフォームを改善。

# 行ったのはシンプル。「新規登録」ボタンを「次へ」ボタンに変えたこと。「次へ」ボタンの下には「購入にあたって登録の必要はありません。ただ、次回からの購入を楽にしたいならチェックアウトの途中で登録することもできます」とメモを添えた。

# 結果、購入する顧客の数が45%アップ。初月で15億円の売り上げ増。年間で300億の売り上げ増。

suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。

だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。

だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。

suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。

suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。

本人いわく、だってそれで動いちゃってるんだもん。だそうだ。

実装は時として奇妙に見えるかもしれない。

フィールドには神がいる。

先日、定食屋だと思って入ったら、一番安い料理でも3千円はする高級和食店だった。
悩んだ挙句、顔を真っ赤にしながら正直に「予算が足りないので失礼します」と伝えたら、店主は状況を察して「ご予算はいかほどでしょう？」と言い返してきた。
顔から火が出そうになりながら「千円では無理ですよね？」と言ったら、笑顔で「天丼はいかがでしょう？」と勧めてくれて、余った高級食材らしきものを集めてかき揚げ丼を作ってもらった。感動して泣きそうになった。
本当の高級店とはこういう店をいうんだなとしみじみ感じた。
財布の中見たら500円しか無かった。

娘に「パパ知っている？海の王様はマンボウなんだよ」と言われた。

大人になれば海の王様と言えば鮫？シャチ？鯨？と思う所なんだろうが
何故にマンボウ？

「へ～鮫とかじゃないんだ。」

と答えると娘曰く

「鮫は強いよ。でも何故か鮫はマンボウを襲わないんだよ。
　だから弱い魚達はマンボウの傍にいるんだよ。
　そうすれば自分達も鮫に襲われないからね。

　強いだけじゃダメなんだよ。弱い魚を守れないと王様にはなれないんだよ」

魚だけに目から鱗が落ちた。

スゲ～大事な事を娘に教えてくれたサカナ君に感謝しなくちゃ。
今まで変な奴だと思っていてごめんななさい。

前に塾の勧誘電話がかかってきた。
勧誘：
「私は、この勉強方法で早稲田に入ったんですよー、」
自分：
「ほぉー、早稲田入ったのにこんな仕事してるんですかー。」
って言ったら電話切られた