Oct - 7th
企業における差別
Posted at 12:24 am | Filed Under Education, Work
ここギコを読みながら思い出したのだが。
先日、社内ミーティングで、会社の主力製品のコーディング作業にプロパーの社員だけでは手が足りないため、現在業務委託で社内に常駐してもらっているメンバーから誰を追加でアサインするかが議題になった。開発のマネージャたちが集まり、コーディング担当者の力量や経験を加味しながら誰が適任か議論していたのだが、だいたい３人くらいに候補が絞られてきた頃、出席者のひとりであるXXマネージャが突然「Aさんはダメですよ、リスクが高いです」と言い出した。あまり技術的な知識がなく、特にPHPのウェブアプリケーションについてはほとんど経験がない人で、開発に絡んでもいないだけに、なぜそんな頭ごなしに否定するのか驚いた他の出席者が理由を聞くと、いたって簡単、そのAさんが中国人だからなのだそうな。曰く、中国は著作権についての意識が日本とは違うから、ソースコードを持ち出されるリスクが高くて云々。一同ギョッとしていると、XXマネージャは今度は「そういえばBさんって結婚してますよね？」と質問して、「だったら滅多なことはしないという抑止力も働くか…」とひとりごちていた。
ごくありふれたミーティングが、国籍または人種による差別、結婚の有無による差別の現場となった瞬間である。
同類と思われるのも嫌なので、XXマネージャにそのことをたしなめると、もちろんそういう意見が差別といわれてしまうかもしれないことは知っているという。しかし、ビジネスの厳しい世界では現実的な対処が必要であり、決して差別を助長したりするつもりはないとかなんとかごちょごちょつぶやいてひとりごちていた。基本的に他人の話を聞かない人なのだ。
で、まあ、言い訳としては、そりゃそうだろう。この手の差別というのは、露骨な他人への嫌悪感の表明としてよりは、現実社会の問題をかんがみると致し方がないリアリスティックな対応なんだよ、仕方がないんだよ、という世間知として、「野暮は承知で」表明されることの方が多いかもしれないくらいだ。あるいは、ときには他人への気遣い（「左翼の宣伝に騙されてあの劣等な連中に付き合わされてるキミはかわいそうな人だよ」）として、またあるときには科学的な知識の一端として語られることもあるかもしれない。
だが、バカがおのれのバカを認めてもバカがなおらないように、差別を差別と認めても、差別がその心から消えるわけではない。もし仮に、いやこれはあくまで仮にだが、致し方なくしてしまっている差別というものがあるとして、それが間違った知識の上に成り立った単なる偏見でしかなかったら、それでも致し方なくしてしまっている差別といえるだろうか。
なんでも政治的に正しいのがいいのかというと、まあそうでもないんだろうが、しかし世間知やおせっかいな気遣い、似非科学でわれわれが判断を誤らなければならない理由はどこにもない。ソースコードの持ち出しリスクはどこの現場にもきっと常に一定して存在しているのだが、では社内の中国人のメンバーがもし持ち出しをするとしたら、それは彼が中国人であることに原因があるのだろうか。彼女が結婚していないことにその原因があるのか。本当にそうか？管理者のはしくれとしていわせてもらえば、そんなのは管理者の言い訳をおのれの差別的意識で塗り替えただけの戯言でしかない。じゃあ聞くが、中国の地方出身者である彼がコンビニでバイトしたとして、その金を仕送りにしたら彼の家族は裕福な暮らしが出来るかどうか、あなたは知っているだろうか。今の仕事がなくなった時、彼は国に帰ってすぐに仕事にありつけるのかどうか知っているのだろうか。彼の日本でもらっている給料が、中国で同じような仕事をしたときにもらえる給料と比べてどれだけ違うというのか。じゃあ中国についてそんなに詳しいってんなら、ワルシャワの物価がどれくらいか、ベッドルームが１つのアパートの家賃がどれだけ高いのか知っているだろうか。ちょっとくらい金持ちがいっぱい住んでる国で生まれ育ったくらいで、相手のことをほとんど何も知らないくせに、どっかの負け犬経営者がおのれの無能と向き合うのが嫌で言いふらした宣伝に乗せられて、他の国のことを見下して知ったようなことばっかりいってんじゃねえぞおっさん。
と、いいたいことはたくさんあるのだが、でも結局自分はXXマネージャの親でも親戚でもなんでもないし、彼がそんな世界観を抱いて周囲を見渡して脂ぎった雑念で魂の芯まで汚れきっていたとしても、はっきりいって手助けする義務も義理もないのでどうでもいいのだが、先に書いたように自分も同じような人間のクズだと思われたくなかったので、会議では思わず声を荒げてしまった。
Jul - 22nd
仕様書について振り返る
Posted at 10:14 pm | Filed Under Work
以前、仕様書についてこんなことを書いていたのだが、結局プロジェクトが終わってみて、当時とはまた別の考え方をするに至ったので書き残しておく。
あのとき、仕様書についてこんな三カ条を掲げていた：
（１）実装の詳細は書かない
（２）全ての機能と機能のフローを記載する
（３）レビューの目的と期日、目的を明確にして通知する
一見、何の問題もないように思われるが、今では少し修正した方がいい気がしている。
まず（１）だが、当時は機能仕様書に実装の詳細は書くべきではないと思っていた。まあ、今でもそれはそうなのだが、しかし大事なことを付け加えるとしたら、結局それは書くことになる。なぜなら、納品されたドキュメントをチェックするだけの担当者がいれば、ツッコミを入れるとすればまずそこだからだ。やつらはとにかく足りないと言い立てるのが仕事なのだ。
（２）については、フローなんか頑張って書いても結局誰もがもっと詳細な情報を出せと言い出すに決まっているので、クラス図だのリレーション図だのああだこうだと作る羽目になり、フロー図なんてドキュメントの表紙の次にちょこっと載ってるだけの誰も見ない片隅の飾りにしかならなくなる。
（３）については、どんなに説明しようと、後になって「このプログラムの仕様はここが悪い」「あそこの作りこみが甘い」などなど、言いたい放題の後だしじゃんけんをされるに決まっているので、「だってあの時はみんなこれでいこうってOK出したよな？」と思っても、まあいい人ならそうだよねと認めてくれるかもしれないが、そうでなければ仕様の欠陥を見つけては鬼の首でも取ったように自分の手柄にしてしまうやつらの餌食にされる。
最初の打ち合わせの時に、期日までにレビューを完了してリクエストを返さない限り、希望する機能が他にあったとしても、そしてそれが自分の業務に欠かすことの出来ないものであっても、絶対に組み込まれない旨を想定読者全員に通知する。もちろん、本当にそうするつもりだ。何か機能を組み込み忘れたせいで製品が売れなかったら、それはリクエストしなかった人の責任になる。
実際にこのように通達していても、一ヶ月もしない内に手のひらを返したように、自分ならもっとうまくやれたと騒ぎ立てる輩が必ず現れる。もちろん、全て自分も承認し、何もリクエストしなかったことなどきれいさっぱり忘れている。
うちの会社にはそんな意地悪な馬鹿野郎はいないよ、という方は、それでいい。自分の職場に誇りをもつべきだし、明日からは周囲の人たちにもっと親切にした方がいい。
というわけで、上記の三カ条を修正するなら、
（１）奴らにフォーマットを作らせろ
まず、フォーマットにケチをつける奴がいるので、そいつを封じ込めないと後で余計な作業が増える。雛形がないと作業できない、と本気で訴えるべきだ。もちろん、雛形を作る担当は、ケチをつけてくる奴を指名する。もし雛形を作ってもらえないなら、フォーマットについては絶対に意見を受け付けられないと明言するか、先にフォーマットだけ作ってこれで作成すると承認を取っておく。
（２）後だしジャンケンには絶対に喰らいつけ
物事は最初にゼロから作る方が絶対に大変なのであって、後からそれを元にああだこうだと意見するのは馬鹿でもできる。それなのに後だしジャンケンしてるやつらの方が優位に立つなんて状態を作らせてはいけない。「だったらあなたが自分でこの仕様を承認する前にそういえばよかったじゃないですか」と遠慮なく言うべきだ。プログラムが完成しテストが進む頃に「改善要望一覧」をちゃちゃっとまとめておくのも効果的だ。どうせみんな真剣に仕様を検討するのはプログラムが出来上がってきて実際に動くものを見てからなので、そのときにあがってくる意見を適当な一覧表にみんなまとめておけば、嫌な意見もみんな「改善要望に追加しておきます」で一発回答できるし、後からゆっくり優先順位を決めるミーティングでも開催してスケジュールも余裕をもって調整できる。それに、もっと大事なことに、もし現状の仕様でリリースできないという事態になれば、必ず裏から上司に手を回して、自分はこんな問題を見つけた、あいつが担当ではこのプロジェクトはうまくいかないとこそこそ報告しまくる奴が暗躍するので、そんなのは改善要望で吸収していくと明言して、問題点の報告を自分に向けて一本化することでそういうチャンネルを潰すことができる。上司だってそんな面倒くさい奴なんか相手したくはないはずだ。そこで、自分に向かってきた非難については、遠慮なくさっきのせりふ「だったらあなたが自分でこの仕様を承認する前にそういえばよかったじゃないですか」を面と向かって向かって言ってやろう。これは決して自分だけの責任ではないし、自分が一番大きな責任を負っているわけではないと自分を納得させることが大事だ。
というような、政治的に大人な対応が必要になるケースもあると学んだので追記しておく。
Jun - 26th
社内BTSへの回答
Posted at 7:47 pm | Filed Under Work
前の書き込みから4ヶ月経ってるな。
なんかさあ、社長までいちいちC.C.に入れて、俺が社内の開発規則に反する禁止事項をやっているとかさあ、犯罪者みたいな扱いでギャーギャー騒いでんのにさあ、こっちがまじめくさって答えてやりゃあ何ヶ月も放置してるってのはどういうわけよ。人のことをそこまで言い立てるのはさ、小学生ならまだいいよ。「せんせい、○○くんが〜」とか騒いでも、まあ餓鬼のやることだし。だけどさ、社会人ならさ、それは俺に対する評価にも繋がることだし、その評価っていうのは俺や俺の家族にも直結する問題になるわけ。だから、それなりの覚悟と取り組みでやらないんなら、はっきりいって迷惑とかいう次元じゃない、最低のハラスメントなんだよ。わかる？
わからねえだろうな。俺より長く生きててこの現状だもん。
まあ、いずれにせよもう新しいリリース用ファイルセットにはこのモジュールは組込み済みだから。いちいちコードを別にしても誰も管理できないでしょ。言い出しっぺのあんたもやらないし。あんたの適当な提案のおかげでレポジトリがどんだけぐちゃぐちゃになったと思ってんだよ。こないだざっと計算したら、回復するには最低9人月必要だよ。まったく呆れるね。あれから俺たちもちっとは賢くなったから、もうあんたの口先だけの提案じゃ動かないくらいの知恵は身につけたけどな。
あと、あんたのいうとおり例のJavaScriptライブラリのバージョン上げたら動かなくなったからそれも直したよ。知ってた？っつーかこれほんとに脆弱性あったの？あんた一度もエビデンス提出できなかったよな。俺が見つけてきたやつだと、全部攻撃は未然に防ぐことが出来るか、そもそもライブラリの問題じゃなかったんだが。
この案件だけに限らないけど、あれこれひっかきまわすだけで放置ばっかだと正直迷惑なんだよね。かんべんしてくれよ。俺、他人の足を引っ張って喜ぶバカなんてまさかこのちっちゃい会社の中には存在しないと思ってたけど、あんたを見てるとそうでもないみたいだな。
まあいいや。俺は技術者だし、動かないなら動くようにする、問題があるなら直すだけで、あんたみたいなつまらない政治的な動きだけやって自己満足してコードの1行も書けない偽物エンジニアの相手してる趣味もないから、この件はクローズにしといてやるよ。どうせ見ちゃいないだろうし、いいよな？
P.S. 明日も遅刻すんなよ。
May - 8th
JavaとPHP、自動化ツール、不毛な争い
Posted at 12:23 am | Filed Under PHP, Work
久しぶりに不毛なJava対PHPの議論を耳にした。
趣旨としては、PHPの開発ツールの乏しさ（Javaと比較して）をブチ上げて、カイシャの発展のために今後はJavaで開発すべきだ、というもの。
あのさあ。
まず第一に、これまでのPHPでの開発実績をポンと捨てることにどんだけの意味があるのかね。人的資源は無尽蔵にあるとでも思ってるんだろうか。品質向上のために自動化のためのツールがほしい、という話だけど、Javaで例えば品質管理の現場でツールを使ってあれやこれを自動化するとしても、それでいったいどれだけのことが出来ているか知っているのかね。というか、自分がPHPで適切な環境整備が出来ないのを言語のせいにしとるだけちゃうんかと。
Java向けのコーディングルールのチェックツールがあるとする。でも、それで検知される内容って結局誰かが確認しないと、警告だのなんだのが出ても無視する奴は無視するわけで、だからまじめに運用しようとするとSEが人力でチェックを入れて徹夜したりしている。ちょっと極端な話だけど、ツールなんてそんなもんじゃないのか。
開発環境ひとつとっても、別にそんなに大仰なことが必要なケースって少ないんじゃないだろうか。Amazonのシステム丸ごとリプレースならいざ知らず、たかだかユーザ数５０万や１００万程度の携帯サイトだったら、リモートデバッグなんてややこしいツールなんかなくても、今だってサーバにログインしてそれなりにファイルを編集したりコマンドを実行したりする権限はみんな持っているんだから、Xdebugでもなんても使えればいい。テストの自動化だったらSeleniumでもなんでも使えればそれでいいじゃん。っていうかだったら携帯端末の挙動を模するエミュレータかプロクシの開発でも進めればいいんじゃないか。
以前習ったことだけれども、本当は言語自体がソフトウェア開発に関連するハウスキーピング作業をやってくれるのが一番理想的で、それがダメならツールがやってくれるのがいいことで、それでもダメなら慣習でそれが実践されるようにするのがいい、という尺度がある。つまり、どう足掻いてもツールのレベルにとどまるのであれば、言語を取り替えても効果はたかが知れているのだ。
品質管理の連中が言語を変えたいといってきたら要注意だ。開発チームからそんな声が聞こえてきたら、それはまた別の意味で要注意（やった方がいい）なのだけれども。
そうそう。プログラムにコメントなんて本当に必要なんだろうか。仕様書を更新する人はいても、コメントを更新する人なんていないんだし、結局最後は当てにならないんじゃないか。だから、個人的には、コーディングのルールでコメントの付け方までいちいち縛るのはあんまり意味がないし効果も薄いと思っている。別にコメント自体には反対はしないけど、何かの保守業務でコメントを読んだことなんかないし、自動的に出力したドキュメントなんて、ソースコードを読むより苦痛になることの方が多い。
Apr - 21st
Those were the days
Posted at 8:20 pm | Filed Under PHP, Work
reddit経由で読んだが、antirez blogに掲載された「What we lost (now that web programming is mainstream)」は新たな「本物のプログラマ」シリーズのバリエーションだ。
本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。
という一節を思い起こせば、
I had a background in system programming, very high level programming languages and algorithms and most of my work was with C, Scheme and Tcl at the time (now I use C and Ruby instead): to switch to web programming and PHP was like shooting my technical-self
これが基本的にはまったく同じことをいっているのがわかる。どこかで同じようなことを読んだなあ、と思ったらちょっと前にメモしておいたのがあった。
“This is exactly what makes Rails a ghetto. A bunch of half-trained former PHP morons who never bother to sit down and really learn the computer science they were too good to study in college.”
これも同工異曲といったところ。
皮肉なことに、いわゆる本物のプログラマたる人々が仕事として取り組めるプログラムにも限りがあるので、その手の人たちの中にはプログラミング言語を開発したり、フレームワークを開発していたりすることも少なくない。
件のブログでは
The most interesting thing remains to write a framework
(this is why there are so many frameworks around, people like to write them more than actual applications) unless you are lucky enough to deal with an application where the web part is just the interface to the user, take Google for example, but this is of course a very little percentage of all web applications, including the ones having success.
なんて書かれている。確かに、ある程度以上の技量を持ったウェブアプリケーションのプログラマなら、フレームワークを書いてみたいと思う人はたくさんいる。
しかし、皮肉なことに、フレームワークは結局のところ、開発者が低レベルな部分を面倒みなくてもいいようにするものになってしまうので、ウェブアプリケーションからいわゆる本物のプログラマと分類される人たちの面白がる部分をますます無用のものとすることに貢献してしまう。
結局、この手の話はもう何十年も繰り返されていることなので、誰もがある程度のところであきらめるしかないと思うのだが、どうだろうか。
Apr - 11th
マシンが壊れた
Posted at 12:05 am | Filed Under Work
会社から支給されていたマシンが壊れた。Windows XPのノートPCなのだが、HDDを正常に認識しなくなってしまった。
とりあえず修理だ。しばらく家のMacBookでも持ち込んで快適に仕事をしよう。
この壊れたマシンをどれだけ愛していたかは前に書いた。
Feb - 7th
逆に悲しい
Posted at 10:36 pm | Filed Under Work
テキストデータとバイナリデータ（GIFファイル）が混在するマルチパートで配信するファイルが２つあって、全く同じサイズなのだが片方が動作しない。当然ながら、目で見てもぜんぜん違いがわからない。
とりあえずスクリプトで10バイトずつ読み込んでは16進数に変換して、お互いのデータを比較してみた。
2バイトだけ違っていた。さっきまではどうしても知りたいと思っていたのに、知ってしまうと逆に悲しくなった。
しかも、目で見てわかるはずの箇所だった。
Jan - 25th
Internet Explorer 7への自動更新
Posted at 5:20 pm | Filed Under Work
Twitter経由で知ったのだが、InternetExplorer6のユーザがWindows Updateを自動更新、自動承認に設定している場合、InternetExplorer7に自動的にアップグレードされてしまうと報道されていた。
超難解な構成のMicrosoftのサイトをあちこち見て回ったが、なかなかそれらしい情報が見つからない。以前は正規品かどうかのチェックが完了しないとインストールできなかったInternetExplorer7がそのチェックが不要になったとか、2008年にはWindows Updateで更新できるようになるとか、そんな程度のことしか書かれていない。
で、上のニュース記事の原文を読む限りでは、微妙なのでわかりにくいが、「WSUS経由で」IE7への更新がリリースされる、となっている。
そこであちこち探し回ってみると、このWSUS(Windows Server Update Services)とやらの開発者ブログが見つかった。WSUSというのは、規模の大きな企業などで社内のクライアントのソフトウェアパッケージの更新を一括管理するためのシステムのようで、いわく
I wanted to bring to your attention that on February 12, Microsoft will release the IE7 Installation and Availability update to WSUS marked as an Update Rollup package. What this means is that this update will automatically flow only to clients of WSUS severs that have been configured to auto-approve update rollups, which as you know, is not the default or commonly used WSUS configuration.
WSUSのクライアントで更新の自動承認をオンにしているユーザのみ影響があるとのこと。
Webアプリケーションの開発者としては非常に驚かされた報道だったが、ふたを開けてみると、まあこんなものかという程度で、ちょっと肩透かしを食らった感じだ。どっちにしろ、IE7対応はそろそろ終わらせてIE8を調べておかないといけないんだけど。
Jan - 23rd
Unfathomable!
Posted at 11:08 am | Filed Under PHP, Work
「RSSをC++でパースする？ 退屈だね。インメモリのサーチインデックスをPHPで構築する？ 理解を超える！」
Parsing RSS in C++? Sounds tedious. Building an in-memory search index in PHP? Unfathomable!
今日PHPでインメモリのデータを扱うようにしてI/O負荷を軽減できないか（開発期間は一日）と、一時間ほどあれこれどやされたとき、上の文章を思い出した。
せめて共有メモリなら、とも思ったが、いまどきmemcachedも入れないシステム構成が悪いということで、相手がやけくそになるまで待って、断った。いちおう、マニュアルくらいは読んだけど。
Dec - 18th
Young risk taker.: IPOから学んだ事柄
Posted at 12:13 am | Filed Under Work, life
証券会社ってこんな雰囲気じゃね？
Young risk taker.: IPOから学んだ事柄:
大和証券では新卒社員が５分遅刻した際に、上長がブチきれ机を蹴飛ばしその社員の胸ぐらをつかみかかり罵倒し、その後見せしめとしてその日一日中新卒社員で「遅刻に対して」というお題でMTGが開かれた話を友達から聞いた。新卒社員に対してこの上長が取った行動は正しかったと思う。
あの業界って、よくトイレで絶叫したりしてるじゃん。
keep looking »