「コピー用紙の裏は使うな」

冬休みなので、本を集中して読みたいと思うが、あまり読めていない。

まあいくつか読んでいて、「コピー用紙の裏は使うな」でおもしろい文言を。

「やりたいのはやまやまだが、削減努力をこれ以上現場に指示できない。うちの現場は”いっぱいいっぱいで”．．．」

なんかこういうのよく聞くな、特に企業のお偉いさんとか。

「品質の向上をやりたいのはやまやまだが、これ以上現場に指示できない。”うちの現場はコーディングとバグ修正でいっぱいいっぱいで”．．．」

どうしてプログラマに・・・プログラムが書けないのか?

http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm

という記事をなぜか読んだ。日本ってコードを書くスキルに対してアメリカよりルーズである。入社試験（それもソフトウェア開発者としての）にさえプログラムの試験をしない。試験する側もそれほどプログラムが得意ではないからであろう。

建築関連の仕事に従事する人は当然、設計図面がかけると思うが、ソフトウェア開発に従事する人が、Cの文法でさえあやふやであったりする。
開発エンジニアの人の中にはいつも設計とか上流とかの話を偉そうにする人がいる、でもたいていそんな人に限ってコードをちゃんと書けない人が多い。

Googleねた

http://itpro.nikkeibp.co.jp/article/NEWS/20060314/232488/?ST=oss

Googleねたもうひとつ。
ソースコード見せてよ
１０人以下

というのがキーワードですね。
自分がテストする製品のソースコードは必ず見るようにしている。なんかソースコード見ないでテストする人もいるようだが、わたして的には必ず見るようにしている。ソースコードを見ているとこのチームやる気、スキル、諸々全てわかる気がする。細木ｘｘｘじゃないけど。

それが言いか悪いかはなかなかいえないが、コードを見ているとこのチームがんばってるなー、ちゃんとテストしてあげなきゃ！と思うこともあるし。このチームやる気ねーな、レビューもやってないんだろうと思い、どうせバグばっかりだからテストも手を抜こうとちょっとおもったりすることもある。

生産性

http://itpro.nikkeibp.co.jp/article/NEWS/20070910/281542/

という記事を読んだ。生産性については、結構興味がある。個人的にはなるべく優秀な人を優遇したgoogleなりmicrosoft方式が気にっている。ソフトウェアプロセスも重要だと思うけど、優秀な人はCMMIがなんだかんだ言う前に日々現実的な作業改善をしている。

なんかペアプロよりこコードレビューのほうがいいというのも共感する。

”　開発もなるべく小さな単位で行う。「設計しつつ実装，こまめにマイルストーンを設定する。小さい単位で動くものを作る。作る順序は後で使うものから。テストしやすさ，デバッグしやすさのために重要」（鵜飼氏）。”

うんすごいなんか幼稚な言い方だが、すごくいい。

ASTA conference

Asia Software Testing Alliance ConferenceというのをJaSSTのjoint conferenceとしてやる。ベトナム＆中国＆韓国＆マレーシアから偉いテストな人がきて話をするので、是非参加してほしい。こういう機会はめったにないし。

http://www.jasst.jp/archives/jasst08e/session.html#f2

「椅子とパソコンをなくせば会社は伸びる！」

を読んだ。

とっても役にたった。会議室からは椅子をなくすべきだと思う、ムダな会議はなくすより会議自体を短くする方向に労力を使うほうがいいかもしれない。

会議で発言しない人は呼ばない（議事録みればいいんだから）
会議でステータスの報告はしない（ステータスリポート書けばいいんだから）
目的のない会議はしない

という方針に今後はしたいなーと個人的に思っている。

メールについても書いてあって、メールするよりは直接話したほうがいい場合が多い。「同じフロアーメール禁止なんていうのもいい」。メール便利だけど、これだけメールが多いと到底全部処理できない。どうも周りを見ていると、メールを処理するのが仕事だと思ってる人が多い。「君の仕事は、いい製品を早く出すことなのだよ。なのでメールをしかとしてもいいんだよ」と言うときがある。

あとネットブランジングについても書いてあった、その通りだ。かなりの人がブラウザーで遊んでいるのは確かだ。そんなことに残業代を払いたくない。

早く家に帰って、プログラムの本でもちゃんと読んでほしい。ソフトウェアのことはgoogleで検索すれば情報はいくらでも入る、しかし系統だった情報は本を読まないと入ってこないのである。

日本の実力

http://ascii.jp/elem/000/000/094/94204/index-2.html

「今の日本は「格差が広がっている」ことよりも、「成長していない」ことを問題にしなければなりません。90年代以降の名目成長率は平均してゼロに近い。一人当たりのGDPは1993年には1位だったのが、2006年の統計では20位に下落してます。 」

というふうに書いてある、まったくもってその通りである。ことソフトウェアの実力に関しては２０位より下であることに間違いない。「トヨタとかはいい車作って日本の技術力が優位である」というのをソフトウェアの世界で同様だと勘違いしている人がごまんといる。

あきらかにヨーロッパのどの国よりも、日本のソフトウェアの実力は下なのだ。

日本信号のトラブル

今日は執筆モードなので、過去のバグを調査中

日本信号のをちょっと調べてみたら、おもしろい。自分のバグはつらいが、人が出したバグはおもしろい、人の不幸は．．．

http://it.nikkei.co.jp/business/news/index.aspx?n=MMIT0z000016102007
http://www.gartner.co.jp/news_analysis/documents/NA00116.html

webを見るとガートナーが一番的確に状況を説明しているのが驚く（ちょっと用語の使い方がおかしいが）。

「今回の障害では、データがあるバイト数 (割るとあまりが0) に一致した場合、別のロジックに入ったと想定された」

と書いてある、たぶん「割るとあまりが０」ではなく、「divided by 0をチェックするルーチン」のほうじゃないかなー。
想定されるストーリーとしては、プログラマーがまず先入観で絶対０になるような値はサブルーチンに入ってくるはずはないと思ったが、一応０が入ってきたらまずいから、エラー処理は入れておこうと思ったのではないか。それなら日本信号はソフト作る会社としてはまずまずである、まあ今回の問題は運が悪いとも言える。だって割り算する前にかならずそれがdivided by 0にならないようにチェックしない会社いっぱいあるし。

しかしガートナーの言うように「今回の障害では、データがあるバイト数 (割るとあまりが0) に一致した場合」となると話は別である。かなりマヌケである。
単体テストをしていない、要求管理に対するテストケースがまったくないということになる。そうなると日本信号の作る自動改札はバグを出し続ける。

開発者の気持ち

最近テストより、開発の仕事が多い。

そうすると開発者の気持ちがよくわかるようになる、いつもは「ちゃんとrequirement書かないとテストできません」「requiremntは正確であり、検証可能なものでなければなりません」などど言っているのだが、いざ自分が書いてみるとうまく書けない（ナイショだけど）。

やはり開発者は数年間テストの仕事をすべきだし、テスト屋さんも数年間は開発の仕事をするべきだと思う。

じじーになることについて

歳をとると能力が落ちる。運動能力もそうだし、いろいろからだの障害が．．．

学力というか知力も落ちているのだろうと思ったが、この前１０年前に読んでも理解できないIEEE　Trans.の論文を再度読み返したらなんと理解できた。個人的には大学院の修士の時代が一番頭が冴えていたように思えたが、そのとき理解できない論文が１０年後に理解できたのは自分ですごいと思った。

数学などの研究は３０代で終わりだけど、テストとかは少しは歳をとってもオーケーなのかなーと思った昨今であった。