Diary?::2008-07
2008-07-01
Tue
(22:29)
今日から完全未経験の新人が入ってきたので、先週までは超余裕というか半ば放置しても OK だった研修がちと大変になりそうだ。なにせ「コマンドプロンプトって何ですか」というあたりから答える必要があるからなあ。
2008-07-02
Wed
(20:54)
ここ一ヶ月ほど (いや、もっとかも) 自転車を使わずに駅まで歩いて通勤してるんだけど、やっぱこっちの方が消耗するわー。そして何より時間がかかるので、それまでよりも早めに起きるようになった。といっても 07:30 に起きれば間に合うので、早起きでも何でもないんだけどな。
ちなみに自転車を使ってない理由は、パンクしたのを直すのがかったるくて数日放置してたら自転車のない生活にすっかり慣れてしまったから。いやー、道路事情がえらいことわるいから、自転車に乗ってもいいことばかりじゃねえのよ。既に何回か事故ってるし。
2008-07-03
Thu
(21:43)
Hydrogen っつークロスプラットフォームかつフリーなドラムマシンソフトでリズムパターン作ってたんだけど、お前これ曲の途中でテンポチェンジが出来ないじゃねえか。これは計算外だ。ってかどうすっかなー。一旦こいつで打ち込んだ後に Rosegarden からインポートしてそこでテンポチェンジさせるか。
(23:35)
えーと、実名を出すとちょっと面倒な事になるのでそこは抜きで書くけど、
- 社長がブチ切れてディスプレイとか投げる
- 退職しようか迷っていると伝えると暴力をふるわれる
- 社長が「俺は絶対に間違いを犯さない」と思っている
- 退職者の 99% が半ば失踪の形で辞めている
- 当然ながら労働基準法をガン無視
という企業は実際に存在するので、なかなか内定が出ないからってブラック企業でもいいやと思って就職するのはやめとけ。
2008-07-04
Fri
(22:01)
最悪。
まあそんなことはどうでもいい。それよか今週の頭に買った "Call of Duty 4: Modern Warfare" だけど、結局なんだかんだいってクリアできてしまったなあ。とりあえず感想をつらつらと箇条書きにて。
- タッチペンでの照準合わせ (Aim と呼ばれる) が思いのほか快適
- 手足や体は 10 発以上撃ち込まないと倒せないが、頭を撃ち抜けば一撃なので、 Aim 超重要
- かといってアタリを付けてのバラ撒きも無意味ではなく、逃げたりポジション取りしながらの牽制に使える
- 画面をダブルクリックすると ADS モードという照準合わせ専用モードになる。移動力が激減するので確実に頭をぶち抜いて倒す必要あり
- ちょっと調べたら「ADS モードが暴発しまくり」って意見が結構あったけど、俺は全然しなかったぞ。タッチペンの感度設定あるし、どうにでもなるんじゃない?
- 手榴弾は使いにくいが、嫌な地形や固まってる敵の殲滅には効果的
- 催涙弾はいっぺんも使わなかった
- 死ぬとチェックポイントまで戻されるのはいいとして、武器がリセットされるのは良し悪しだな
- 初期装備のアサルトライフル (?) が強いので、手詰まりにはならない
- 半面、現地調達できる武器のアイデンティティが微妙
- やたら手に入るカラシニコフ (?) はあまり強くないが、同じく初期装備のハンドガンよりはマシ
- サブマシンガンは複数種類あるようだが、どれも一緒
- ショットガンは強い。一ヶ所に固まってる敵を二人以上一発で倒すこともある。ただし、手に入りにくい
- スナイパーライフルは驚異的な Aim 性能なのだが、ショットガン以上に出てこない
- 爆弾解体のミニゲームなんかは蛇足だったかも
- グラフィックは特に美麗じゃないが、別にそこはどうでもいい
- ちなみに対戦はやってない
俺は結構楽しめたけど、他の機種で出てる奴は一切やってないからなあ。他の機種でも遊んでる人が DS 版をどう思うかはわからん。
2008-07-05
Sat
(22:28)
「魔人探偵脳噛ネウロ」 17 巻を購入。よくよく考えたら今のシックス編っていわゆるバトル漫画的展開なんだけど、全然違和感無く切り替わってるのは結構凄いことなんじゃないかなあ。冒頭のバレンタインの話でのギャグエピソードから普段のエピソードへの展開もそうだけど、相変わらず話の転がし方が実に上手い。よく週刊連載でこんだけできるもんだと毎回感心するよ。
ところでバトル漫画としてみるとネウロって
- ネウロを磨り潰すのに敵が中長期的なスパンで襲ってくる
- 拳銃とかの普通の武器が有効で、 X も今回の敵も拳銃で足止め可能
- 普通は主人公側が敵を倒しにいくが、ネウロたちはむしろ狙われる側
- 単純な戦闘力とかを考えると、むしろネウロがラスボス
とまあ、ジャンプ的にというか少年漫画的にかなり異常なんじゃないかな。だからこそ単行本を買ってるという事でもあるんだけど。
2008-07-06
Sun
(16:20)
ほんの数日前まではそんなに暑くなかったのに、一昨日辺りからいきなり蒸し暑くなってきたな。何というか、汗と一緒に生きる活力が流れ出ていくようだ。
2008-07-07
Mon
(00:02)
「ノーカロリー コカ・コーラ プラスビタミン」とかいうものが売ってたので、どうせダイエットコーラたいして変わらんだろうと思いつつも、「そういや Zero の方はダイエットコーラよりは美味かったな」とおもい、ちょっとだけ期待して飲んでみた。
……うん、ダイエットコーラだこれは。
(06:04)
漫画みたいな「ピッシャアァァァ」という雷鳴い驚いて目を覚ましたんだが、次の記事でさらに驚いた。ってか呆れた。
……要らなそうな道路予算をいくつか削れよバカ。流石にどうにか予算を取り付けてくるとは思うけど、こんなニュースが流れる時点でいろいろアウトっぽいよな。
(20:59)
何ヶ月かぶりにお金を稼ぐ仕事にアサインされた。それにしてもオフショア相手のダンピング合戦は不毛極まりないな。ってかオフショアってそこまで安いか? オフショアに出せる分量がそれなりにあるんなら違うだろうけど、なんか最終的にはそこまで安くならんような気もするが（コミュニケーションとか環境整備のコストがバカにならんし）。
あと今回の仕事で始めてスケジュールを立てるのに Excel を使わなかった。代わりに Project っていうツールを使ったんだが、これは明らかに Excel よりもまともだ。値段が 10 万円近くするのでプロジェクト全体へ導入されることは殆どないらしいがな。それでも Excel を使ったクソみたいな作業よりはずっとまし。
あといい加減に開発者向けの文書をバイナリフォーマットで作るのは止めよう。検索性能が著しく低くて仕方がない。最初に Word や Excel を使い始めた奴は単なるアホだな。
2008-07-08
Tue
(20:51)
くっそー、何で俺に全員分の工数の見積りなんてものが回ってくるんじゃー。本来なら上司の仕事だと思うが、そっちはそっちで別の作業が結構あるんで、それで俺に回さざるを得ないという事情はわかるんだが……。
そもそもどんな作業が待ち受けているのか、それぞれの作業にどれだけかかるかが不透明な部分があるので、これはもう勘でやるしかない。締切りのラインとにらめっこして、一番安全そうなラインで引いてはおいたけど、裏目に出たらシャレにならんぞこれ。俺がどんぶり勘定を越えた釣り鐘勘定だってことぐらい、みんなわかってると思うんだけどなあ。
2008-07-09
Wed
(19:35)
そういや一時期騒がれていたような「工事進行基準」だけど、実は今のプロジェクトでは既に実施してるんだよな。まあそれで大勢に影響があったかというと、当然ながらなかったわけだが。
2008-07-10
Thu
(20:50)
昨日「工事進行基準が適用されても前と変わってねーな」と書いて、実際そう思ってるんだけど、どうも周囲では「いやいや、ずっと締め付けが厳しくなった」という声が結構ある。というか、俺が前までいた現場は素で工事進行基準を満たしてしまうような運営がされていて、つまり俺は感覚が麻痺してるということか。これはヤバいな。
そういや今日は完全未経験の新人が先週に続いて入ってきたんだけど、本来の仕事をしつつ新人二人の面倒を見るってのはなかなかキツいもんがある。何せ俺はスケジュールの管理やあがってきた設計書のチェックやら、そういうのまでやらないといけないからな（最終的には上司もチェックするので、ものすごい負荷がかかっている訳ではないけど）。素人相手に一から説明しながら巨大なフレームワークの拡張とかやってると脳味噌が煮えてくる。
それにしても、未経験者相手の研修は疲れる。何しろ相手はプログラミングのことを何一つ知らないわけで、ある程度何か書けるようになるまでは数ヶ月かかる。そしてこの数ヶ月という先行投資期間は長すぎるとしか言えない。前にもちょろっと書いた気もするけど、この投資分を回収できる前に転職とかされるとすげー困る。「プログラマの値段（派遣編）」ベースにすげー大雑把に計算すると（ちなみにうちはリンク先で提示されてるよりも酷い条件で仕事をしてる）、最初の三ヶ月は純粋に金がかかるだけ、その後九ヶ月はよくてトントン、普通は赤字な額で現場に出されて、二年目あたりは多分月あたり 30,000 円の収益があるかどうかってところで、本格的に稼ぎ出すのは三年目以降。いや、俺は他の連中の単価はあんまり知らないけどさ。なので、三年目の途中とかで辞められるとマジで困る。
ちなみに中途採用した経験者二人は当たり前だけどきちんと戦力になっていて、今回は当初の予定じゃ俺と上司だけの仕事で限りなく死の匂いがしていたので、あらゆる意味で助かってる。二人とも頭は回るし、人当たりもいいし、採用して大正解。でもそういう人でも「若い」という理由でションベンみたいな単価で出さないといけないんだから、やっぱこの国は間違ってるよ。できる奴にきちんと払いさえすれば、いわゆる人月計算でも別にいいんだけどなあ。
(22:42)
さっき書いた奴の補足。大体未経験の新人は一年目では 200,000 円/月とかいうケースもあるので、マジで一年目は赤字と見た方がいい。スキルが低いと二年目でも単価が 500,000 には全然届かない（具体的な数値は知らん）。俺は情報系の大学を出ていた事もあり一年目から普通に単価を取ってこれたが、それ以外の連中はこういう単価で仕事してるわけだ。
そして俺に課されたミッションというのは三ヶ月の研修でまったくもってダメな奴を斬り捨て御免することで、それはその先の九ヶ月の赤字とまるでダメな奴が現場に与える損害を回避するためだ。三月か四月あたりに結局一年かそこらで辞めちまった奴の事を少し書いたと思うが、俺はそいつの尻拭いで徹夜したりしてたからな。ただでさえ締め付けが強まる一方の現場に変な奴は送り込めんよ。
2008-07-11
Fri
(23:14)
今月頭から入った新人にどうもやる気が見られなくてちとガッカリ。確かに課題は素人に出すには少し難しいし、プログラミングを始めたばかりで何して良いかわからない事も多いと思う。でもだったらちゃんと俺んとこに聞きにこいとか、試行錯誤でいいから何か書いてみろとか思う。最初できないのは当たり前だから俺はそんなことは全然責めないけど、やる気がないとか研修担当ときちんとコミュニケートできないのは大問題で、このままやる気が見られないままだったら来週中に肩を叩く羽目になる。
どの業界もそうだろうけど、採用には思ってるよりもコストがかかるんだよ。特にうちみたいな小さい会社の場合、広告打ったり就職・転職サイトに載せてもらったりするための費用がバカにならない。それに面接担当は面接が続くと本来の業務が遅れるわけで、そこをカバーする人材が小さい会社の場合はいないことが多い（なので今回はそれを踏まえてスケジュールを組む必要があった）。かくいう俺も就職サイトの取材に応じたりすることがあって、研修風景を動画に撮られたりもしてる。どこの会社も金とか羞恥心とかいろんなものを切り売りして人材を探してるわけで、採用取り消しというのは本当にやりたくないことだ。
それでもスキル以前に人格的にもダメダメな奴が現場に出ることで被る被害とかを考えると、本当にダメな奴はさっさと切り飛ばすしかない。多少現場がグダグダだったりしても、モチベーションの維持で失敗しない限りはどうにかなるもんなんだよ（ちなみにリーダー・マネジャーといった役割の奴の一番重要な仕事がこれだ）。実際に巻き添え食えばわかるけど、本当にやる気もスキルもない奴ってのは周囲のモチベーションをガタ落ちさせる。
ところで話は変わるけど、今日はダメっぽい新人をどうするか以外に嫌な話があって、それは他の社員の単価の決定。前に同じ現場にいた連中について各種のスキルを元に妥当な単価を決定していくんだけど、最大でも 700,000 円/月行かないのかとか、能力を間違いなく下回る単価で売りさばかにゃならんのかとか、この単価だったら確かにもっと人を増やさないと利益は上がらんよなとか、何か奴隷商人の気分になってきた。特に「あんまり単価を上げると仕事を取りにくくなる」とか「経験年数の割に能力は凄く高いけど、その経験年数がネック」とか、そういう理由で安く売っ払われる人に対しては俺のせいじゃないけど何か申し訳なくなってきた。
2008-07-12
Sat
(22:25)
いろいろ試してみた結果、やっぱ俺には Elixir の弦が一番らしい。とにかく弦の寿命が全然違う。それに特殊なコーティングのおかげか、スライドもやり易いように感じる。ピックスクラッチが綺麗にでないとか言われてるけど、俺はスクラッチはまずやらないので関係ない。
そういや前から「ロック式は弦交換がたるい」とか書いてたけど、その理由がこのワーミーバー。わざわざこうして固定してやらないと、弦を緩めたときにサドルが下がってさらに面倒になる。もっとも、一旦チューニングを合わせてしまえばあとは楽なんだが。
あと最近、 John Petrucci が昔やってたような弦の巻き方をやるようになった。ちとわかりにくいかもしれないけど、ペグから弦を通してボールエンドをペグのところで固定するようにして、弦を巻くのに必要な最低限の部分を残して弦の先の方を切ってしまう。こうするとボールエンドを切るよりも少ない手間で巻くことができる。ロック式でないギターじゃ弦の巻き数でテンションが変わるのでこんなことはまずやらないだろうけど、ロック式の場合はまず影響を受けないのでこういう事ができるんだな。
2008-07-13
Sun
(14:55)
いや、記事の内容はすさまじくどーでもいいんだけど、記事の最後にあるナベツネのコメントがやたら面白いんで。本当、ここまでわかりやすいアレだとこっちは安心して突っ込めるよなあ。
それはともかく、いい加減にスポーツ選手とかを聖人君子に仕立て上げるのはやめないか? 実態とかけ離れすぎだろ。古い話だけど L'Arc～en～Ciel がテレビに出たときタバコをふかしながら演奏してたのに苦情が出たなんてこともあったけどさ、もうそういうので「子供に悪影響が」とか言い出すのはやめようや。そんことで影響受ける奴なんざどうせ一握りだし、それにしたって大抵は若気の至りで済むだろ。そんなことよか、親が子供の前でタバコ吸ってる方がずっと影響はデカいだろうに（副流煙の被害もあるしな）。
(17:53)
シーフード味のじゃがりこが発売されてたんで食ってみたけど、かっぱえびせんじゃねえかこれ。
2008-07-14
Mon
(23:47)
本格的に引越したくなってきたので、殆ど使ってない家具とか食器とかを片っ端から処分中。燃えないゴミとして捨てられる奴はいいけど、いちいち業者に引き取ってもらわないとダメな奴が面倒だなあ。あと HDD とかのパーツ取りしてグチャグチャになったノート PC 、これメーカー側でちゃんと引き取ってもらえんのかね。あんまりそこら辺の言及がメーカーのページにないんで、ちと不安だ。
あとは弾かなくなった安物のギターと、既に用済みのアンプだな。欲しい人がいたらゆずろうとか思ってたけど、流石に Photo Genic のギターなんぞいらんだろう。処分だな。
2008-07-15
Tue
(21:41)
新人に教えるときに毎度のように
- わかんねー事があったら聞け
- でも聞く前に考えろ
- それから聞く前に実行しろ
という事を言ってるんだけど、なかなかやってくれなくて困る。例えば今日何かは次のようなコードを見せられて「これでいいんですか?」とか聞かれた。
if (x.equals("foo" || "bar" || "buz")) {
...
}だーかーらー、そういう事を聞く前にコンパイルして実行だっての。それでエラーになったり予期しない動作になって、それでわかんなくなってから聞けっての。プログラミングに限らず何でもそうだけど、まず失敗してから失敗した事について真剣に考えないと上達しないよ。
何かしら実行する前に聞くってのは失敗したくないっていう心理が働いてるんだろうけど、今は研修中なんだからそんな事考えるなって。別に妙なコードを書いたから採用取り消しってわけじゃないんだからさ。
2008-07-16
Wed
(23:32)
システム開発の下請けの会社が業績アップを計るなら、ぶっちゃけた話
- 大量の開発を請け負う
という事を考えれば良い。じゃあどうすれば現状以上の仕事を請け負えるかというと、
- とにかく人を採って社員を増やす
- スキルを上げて（=単価を上げて）プロジェクトあたりの人員を減らす
の二つがあって、今の会社じゃその両方をやろうとしているわけだ。人を増やすのは多分どうにかなっているが、問題はスキルアップだ。うちに限った話じゃねえが、スキルアップしようとしない技術者はマジでスキルアップしようとしないからな。今までもいろいろ試してはみたらしいが、どれも良い結果にはならなかったそうだ。
俺は自発的に学習しようとしない奴に何を言っても無駄だと思っているのだが、会社の戦略として「スキルアップ=単価アップ=収益」がある以上、何かしらの策を練る必要がある。しかもこんな条件でだ。
- 平日に行う場合、本来の業務時間に食い込みすぎると減収になる
- 社員が様々な拠点に分散しているので、そこに出かける必要がある
- 休日に集めるという手もあるが、本社がそれほど広くないので全社員を一同に集めるのは無茶
- 目的がスキルの底上げなので、新人を除いての最低ランクにあわせる
というわけで、平日に対象の拠点にのこのこ出かけて一時間かそこらのレクチャーを計四回程度の時間しか取れなさそうで、こんな程度で一体何を教えればいいんじゃヴォケ。いや、他の社員が勉強を始めるきっかけを作るのが最大の目的だとは聞いているんだが、それにしたってできることが限られ過ぎだ。
一回の時間を長く取りたいなら休日にやるしかないが、これはまず何より俺がやりたくない。やる気のある奴らで勉強会を開くってんなら全然話は別だけど、そもそもの目的が「イマイチやる気のない奴をどうにかする」だからな。まず俺のモチベーションが維持できん。
というわけで今のところ打つ手なし。なんつーかもう、本人が一山いくらの技術者で満足してるんなら別にそれで良くないか。別にみんながみんな高いスキルじゃないといけないわけじゃねえだろうし、うまく微妙な単価の隙間調整ができるような程々の技術者も必要なんだって。というかそういうことにしてくれ。俺の仕事をこれ以上増やすな（開発と新人教育の平行作業だけでも結構大変なのに）。
2008-07-17
Thu
(20:27)
それにしても「知識は勉強、技術は盗め、人材だけは天の運」というのは本当なんだな。先月から入った中途採用者二名はかなりの大当たりで、今年の二月あたりから五月あたりまで面倒みてた未経験の第二新卒だった奴らも、結果的にはなかなか筋のいい方だったかなという評価だ。それに対してうーんこれはなあという人も入ってきてしまうわけで、採用ってのは結構ギャンブルだ。履歴書や面接だけじゃわからんことが多すぎる。
俺としては入社するまでの期間にこの業界というかプログラミングについて何一つ勉強してこない奴は願い下げだったりするんだが、中小の下請けソフトウェアハウスなんぞ情報工学部出身の新卒とかそれなりに経験のあるプログラマがわざわざやってくる可能性はあんまりない。
結局全然別の分野の新卒とか未経験の第二新卒とかを採用せざるをえないわけで、なんつーかいい加減俺も諦め気味だ。
(22:28)
俺はいわゆるマネジャーの仕事をやってるわけじゃないんだけど、それでも多少はチームの管理ワークはやっている。そしてその管理ワークの工数ってのがバカにならないんだよな。たいしたことやってなくてこれなら、大規模プロジェクトの管理ワークはとても俺にはできないだろうな（少なくとも実装作業は絶対にできなくなる）。
その管理ワークに使うツールにクソのような VBA の嵐の Excel とか泥沼もいいところな Access とかを採用してるのが問題の一端だってことが前の現場でわかってるので、次に出される現場じゃそこら辺から戦う必要がある。というか俺が今の会社に残ってる理由の一つが、現上司を含む上層部の中にこういった面で共同戦線を張れる人がいるからなんだが。
とりあえず金を出してくれる人とかは Excel 大好きなのは仕方がないので、逆に最後が Excel なら別に良いだろという方向性でどうにかするのが現時点での戦略。
2008-07-18
Fri
(01:02)
新人の頃はみんな今よりも学習意欲はずっと高かったんだけど、段々と意欲が減衰していって、それで成長が止まっちゃうんだよな。そうなると技術的に難しいところ（=一番面白みを感じ易いところ）を全部俺がもっていく形になっちゃうわけで、ますます技術格差が開いていく。前にもちょっと書いたけど、本当にこれは良くないよ。
じゃあ何で学習意欲がなくなるのかというと、そりゃあ原因は人それぞれで尚且つ複合的なものだろうけど、その一つに仕事を面白がる能力がないってのがあるのかもしれない。面白くないんだからモチベーションが上がらず、特にいわゆるデスマーチとか泥仕事だと全然上がらない。恐らく一番致命的な違いがここなんだろうと思う。
じゃあお前はどうなんだというと、実際のところ酷い仕事、たいしたことのない仕事でもそれなりの楽しみは見出している。例えば去年の仕事はどこに出しても恥ずかしくないヘドロプロジェクトだったけど、それでも楽しみは見出せていたわけで、それは一体どうしてなんだろうと思ったら一つの仮説に達した。物語を作れるかがこの差異を生み出しているんじゃねえか。
テンションに任せて俺の場合の例を適当に書くけど、
クソなプロジェクトの管理体制の目をかいくぐり、ゲリラ的に作業環境の改善策となる奇策を捻り出そうとする Kuwata。
しかし現場の環境はあまりにも貧弱、ツールを作ろうにも Java とバッチファイルと Excel の VBA しか使えそうなものがない。
そして藁にもすがる思いで探したディレクトリの中に光る "jython.jar" の文字。乾坤一擲の一撃なるか?
最大のネックである「誰も Python/Jython なんて知らない」という問題に目を瞑り、やってる事は管理者側的には完全にサボリ。
気をつけろ、うるさ型にバレたらどうなるかわからんぞ。あと職場で「死ねこの知恵遅れ」とか言うのはやめとけ。
とか、
既に現場のモチベーションは最悪な状態、ゴミのような作業と長時間の残業で心身に影響の出ているメンバーも少なくない。
Kuwata 本人も既に限界が近く、昨日も「心に風邪をひいた」とかいって突発的に休んだばかり。
そんな中で本社から「現状で負荷の高まっている社員へのヒアリングを個別に行いたい」との通達が。
ここで自分のクビをカードに自社の上層部を交渉の席に引きずり出すことを画策する Kuwata。
既に撤退の言葉も囁かれる最悪の状況のプロジェクト、さあ詰むや詰まざるや?
とか、
ギリギリの交渉が功を奏してようやく残業時間がマシになりつつある中、チームに激震が走る。
「Javadoc の体裁に関する規約の正式版が作られたので、過去に作ったものをすべてそれに合わせてください」
その性質上先行で開発を開始していた Kuwata チームには完全な死刑宣告。
何しろ予定している全成果物の 90% を既に作っているのだ。それを全て今すぐ修正?
「ここでこいつら殺せば確実にクビになって解放される」という不穏な考えをなだめつつ、
できれば最後であってほしい交渉のテーブルに付く Kuwata。流石に年貢の納め時か?
とかこんな感じで、つまり自分がそのプロジェクトという物語の登場人物だと思えるかどうか、そして登場人物である以上はそれらしい働きをしないとダメだと思えるかどうか。何か幼稚な話かもしれないけど、でも俺は仕事を楽しめるかどうかという事と自分なりの物語を自然と作り出せるかってことは密接に関わっているんじゃないかと思ってる。
いやまあ、流石にここまで妄想逞しくして仕事してるわけでは全然なくて、「今思えばこういう心持ちで仕事してたな」って感じで後付けで書いてる部分も少なくないけど。それでもその仕事にはどんな役割が必要で、自分に与えられた役割は何で、そして自分はその役割をどうやって演じればいいのかって事は割と考えてる気がする。
それで学習しようとしない奴の話に戻ると、多分奴らは自分の役割がわかってないんだ。これはかなり俺個人の価値観だけど、自分が果たすべき役割がわかってしまえばその役が最大限格好良くなるように振る舞うものじゃない? というか俺の価値観は「格好いい/悪い」「面白い/詰まらない」という軸なんで、例えば同僚に尻拭いばっかさせてるのは確実に死ぬほど格好悪い。で、ずっと格好悪いままでいいの?
そしてここまで長々と書いてきてふと最悪の可能性に気がついた。奴らは自分の役割に気がついてないんじゃなくて、そんな物語の行方を左右するような役割は後免だ、なんつーかもう背景のオブジェで良いやと考えているのかもしれない。もしそうだとしたら、俺には本当に打つ手がない。だって背景のオブジェは全然悪くないからな。単なる交換可能な作業者としてただ淡々と仕事して給料もらうだけっていうのは、俺にとってはまったく理解できない生き方なんだけど、それが悪いかというと悪くない。悪くない以上はとやかく言われる筋合いはないだろうしな。
やっぱいらんお節介なのかね、社員への教育制度とかって。
(22:15)
本当にコードを書いて生活したかったら、 SIer じゃなくて下請けのソフトウェアハウスに行けって話なんだよ。
- オフショアとの苛烈なダンピング合戦
- 自称「上流工程専門」が作るスパゲティ仕様書との格闘
- 要件定義レベルからの事実上の丸投げ
- 異常極まりない締め付け管理、あるいは行き過ぎた丸投げ放置
- 明らかに足手まといな奴でも切り捨てられない日本型の雇用習慣
- 技術力よりも年齢で重み付けされる単価
その他諸々のクソな現実に対して「俺が世界を変えてやる」ぐらいの意気込みがあれば、下請けのソフトウェアハウスで生きるのも悪い選択肢じゃない。ただし、それなりに充実した仕事をしたいなら、それなりの修行はすること。
もっとも俺がこんな事を書けるのは、うちが二次請けより先の多重下請け構造に組み込まれていないからって気もする。三次請け四次請けとなるにつれ、指数関数的に仕事がクソになっていくんだろう。だってもしもそういったところに振れる仕事は何かって聞かれたら、俺だって「ションベンみたいな仕事」としか答えられない。
2008-07-19
Sat
(13:40)
いくら何でもこれは……
酷い。本当に酷い。何が酷いって、 IT 業界というか SI と下請けの世界の問題点って賃金でも労働時間でもないのに、そこを意図的にかどうか知らないけど「賃金面ではむしろ良い方」「平均残業時間は月 40 時間程度（いや、平均 40 は絶対におかしいんんだが）」なんて風に問題のすり替えと矮小化をしてるんだから（統計の怪しさ以前の問題）。じゃあ何が問題点かというと、例えばこんな仕事について想像してくれ。
- たらいをいくつか用意して、そのうちの一つに水を張る
- ひしゃくを使ってたらいからたらいへ水を移しかえる
- これを一日繰り返す
- その作業の意味は知らされない
さあ、これで発狂する奴と発狂しない奴、どっちが多いと思う? つまりはそういうことだ。多重下請け構造や締め付け管理により現場に降ってくる作業が大変なクソになり、そしてそれに対する抵抗は殆ど許されない（休職・退職・自殺という選択肢はある）。上記の例でいうと、
- 「こんな作業はやる意味がないから省略させてくれ」といっても通じない。それが規則だからだ
- 実際に作る意味のなくなったモジュールを作らされたことがある
- 「せめてひしゃくを使わず、たらいから直接移させるなどの効率化を認めてくれ」というのもダメだ。規則でひしゃくを使うように定められている
- たとえツールでやった方が良い事でも、バカみたいに手動で行うことがルールとして決まっていた
- 「じゃあせめて、なぜこんな作業をする必要があるのか教えてくれ」といっても現実には無理。その背景と指揮系統が複雑過ぎ
- ちなみに具体的な背景がバカらしすぎて他の面子のモチベーションに悪影響を及ぼすと思い、あえて黙っていた事がある
- まれに本人が不勉強過ぎて何一つ理解できないってこともある
ということで、労働時間とか下請け企業の低賃金とかは副次的な問題に過ぎないんだよ。そもそも月の残業時間が 100 越えても仕事が面白すぎて全然心が折れないってケースもあれば、残業 0 でも精神を病むこともあるんだって。そしてストレスの原因というのは先に述べたように現場がクソになる事であり、クソな現場というのは
- ルールを守ること自体の目的化による締め付け
- 素人を騙して連れてくる採用戦略
- OJT という名目の雑用による作業の過剰な断片化と意味の喪失
- 正常な権限の委譲が行われない組織体制
などの問題が絡み合った結果なわけだ。なので、無量大数歩譲って先の記事で出ていた統計データがすべて正しかったとしても、 IT 業界はそんなに悪くないという結論にはならない。少なくとも、多重下請け構造の特に下の方は紛う事なきクソだという予測を立てても良い。というか、うちの会社がどうにかしようとしてるのがそこら辺だ（まだ確たる手法や成果はないんだけど）。
しかし「もっと不幸な奴らがいるから愚痴るな」というのは、まるで士農工商の下にエタ・非人を設置するような発想だなあ。もう 21 世紀なんだから、江戸時代の社会制度を復活させるような物言いは止めようぜ。
ところで賃金の話だけど、俺は新卒で入って今年が三年目で、月給は手取りで 19 万ぐらいで夏のボーナスは 28 万だった。うちの会社は基本的に二次請けで、 Java もしくは C# での業務用システム開発で生計を立ててる。これが安いか高いかは知らねーし興味もねー（生活に困窮しない限りは興味ない）。まあ、再来年に妹二号の進学が控えていて、俺も学費なりヤサなりを提供する必要があるんでそうなると少し厳しいかも知れんが。
2008-07-20
Sun
(11:33)
プログラマには数学的センスが必要だという話の例を一つ（センスの問題なんで、数学の知識量とか暗算の速さとかじゃないよ）。
うちの会社の新人教育の課題に次のような問題がある。
String str = "FOOBAR[ABC(DEF)][GHI(JKL)]FIZZBUZZ[MNO(PQR)]";
String[][] pairs = new String[3][2];
pairs[0][0] = "ABC";
pairs[1][0] = "GHI";
pairs[2][0] = "MNO";
/*
pairs の中身が
pairs[0][0] => "ABC"
pairs[0][1] => "DEF"
pairs[1][0] => "GHI"
pairs[1][1] => "JKL"
pairs[2][0] => "MNO"
pairs[2][1] => "PQR"
となるような処理を書け
*/要するに [] 内部の文字列に対して対応関係を作っていけという問題なんだけど、ここで次のような質問を受けることがある。
「"ABC" とかって何の意味があるんですか?」※実際には ABC とかよりもちょっとは意味ありげな文字列を使ってる
確かにそういう疑問を持つ気持ちもわからんでもないけど、でもその意味がなんだろうと問題の中身には一切影響がないということを理解してもらいたいもんだ。いや、もちろんそういった疑問を持つことは全然悪いことじゃないけど、それがわからないからって先に進めないというのは困る。
数学的センスというのは突き詰めれば抽象化能力の事で、先の問題でいうと
- 問題の文字列にはパターンの繰り返しが出てくる
- 問題を解くためには [] 内部だけ見れば良い
- FOOBAR とかはノイズ
- ABC が何なのかは問題を解くのに必要ない
というところに問題を落とし込めるかどうかの能力だ。実際に業務システムを作ることになると、例えば業務電文の変換処理を書く場合、やってくる電文のフォーマットだけを考えて具体的な項目毎の意味は一旦忘れてしまった方がいい。電文の意味を知っておかないといけないのは大抵別の奴で、同一人物が変換から業務処理までやる場合でも、あくまでもパターンはパターン、フォーマットはフォーマットと問題を切り分け、一度に考えることを少なくした方がミスは少ない。
さらにこれはプログラミング言語そのものにも関わる話で、最近の言語はコンパイラ型だろうがインタープリタ型だろうが、一旦ソースファイルを別形式に変換してそれから実行というプロセスを経ている。
まあ、最大の問題はこういう説明をしてもチンプンカンプンで、いやチンプンカンプンなのは別にしょうがないんでそこは全然良くて、自分の知識を総動員して理解してやろうとか、さっぱりワケワカだからもっと精進しないとなーとか、そういう風に思う気概がゼロで適当に受け答えしながら流す奴なんだけど。
俺も新人研修だけやってりゃ良い身分ではないので、本人が自発的に学習してくれないと余計に厳しいんだって。大体、いちいち俺が様子を見にいかないと全然質問をぶつけに来ないとかふざけてるだろ。それに箸の上げ下げから教えてると全然時間が足りないから、多少は説明内容のレベルを上げて、そこから質問を受けて相手のレベルを推し量っていかないと研修期間中にろくな事が教えられないんだって。
2008-07-21
Mon
(01:37)
Haskell の学習をやり直しているうちに、何か print と putStr の動作の違いが気になった。次のコードは「ふつうの Haskell プログラミング」の例を、試しに print で実装してみたコード。
main = do cs <- getContents
print $ map swapa cs
swapa 'a' = 'A'
swapa 'A' = 'a'
swapa c = cputStr は即座に出力がされるのだけど、 print は EOF が来るまで何も出力されない。この差異はどこから来るのか?
GHC のソースを読むと、 print は実際には show と putStr の組み合わせで、次のコードと等価だ。
putStrLn $ show $ map swapa csその show の定義は GHC.Show で行われていて、 GHC.Show のコードは追っていると頭痛がしてくるが、定義を追っていくと Show 型では
- show
- shows
- showsPrec
- showList
などを定義しており、このうち showList の評価は引数の評価が終わるまで開始しないので、 getContents が全部終わってから評価が始まる。それでその処理内容だけど、どこでなにやってんのかさっぱりわからん。具体的には、処理の終わりが見えない。
何かむかついたので入力終了へのパターンマッチをしてるところを探したら、おそらく showList__ という showList の下請け関数でやってるという結論に達した。ただし、文字列の場合は showList を再定義して、そこで終了条件へのパターンマッチもしているようだ。
他の場合は showList__ から型に応じた showsPrec が呼ばれる。このとき、例えば Int 型なら showsPrec に showSignedInt が使われる。なんかいろんなところでダミー変数っぽい s が共通して使われているが、この s には初っ端のエントリポイントの show で空文字列が渡されていて、多分それだ。
とまあ一通りソースを追ってみたんだが、どうも show は普通に常識的な事をやっていて、むしろ妙なのは putStr に思えてきた。
実は俺はここまで手続き型脳で考えているので、 getContents で一行読んで次の処理が走ってというモデルを脳みそに構築している。でも考えてみれば、入力が全部終わってないのに出力のある putStr の方が本当なら注意が行かないとダメだよな。
というわけで、 IO と GHC.IO のソースを読んでみたのだが、件の putStr の実体といっていい hPutStr の定義がこれ。
hPutStr handle str = do
buffer_mode <- wantWritableHandle "hPutStr" handle
(\ handle_ -> do getSpareBuffer handle_)
case buffer_mode of
(NoBuffering, _) -> do
hPutChars handle str -- v. slow, but we don't care
(LineBuffering, buf) -> do
writeLines handle buf str
(BlockBuffering _, buf) -> do
writeBlocks handle buf strやっぱ犯人はお前か! バッファリングの状態を調べて、それで逐次的に出力をしているわけか。ったく、これだから Haskell は……。いや、やっぱ手続き型脳の俺が悪いんだけど。
(20:41)
「コンピュータはなぜ動くのか 」を買ってきた。どうも今回の新人は基礎的な知識に絶望的に欠けてるようだから（さらに自力で調べもしねえし）、研修の足しになるかと思って。やっぱねえ、コンピュータの仕組みとかの基礎を押さえておいた方がその先を学びやすいと思うわけだよ。
それでパラパラと読んでみたんだけど、もしかするとこれはちょっと失敗だったかなあ。回路図の話あたりから始まるのはいいと思うんだけど、そっから OOP やら XML までってのは風呂敷を広げ過ぎに思える。まあ、一通り読んでから最終的な判断は下すことにする。
追記@21:10
第2章まで読み終わった。「.NET の説明それでいいの?」「DOS と Windows は説明して Unix とか Mac とかメインフレームは放置かよ」「ってかコンピュータの5大装置ぐらい教えろよ」とか突っ込みたくなるが、まあそこは適当にフォロー入れればいいか。それよかマイコン作成のところは実機がないとダメっぽいなあ。もうちっと座学っぽいっぽいものを期待してたんだけど、全然違った。
あと CPU の仕組みとか、ハードウェア内部の話が出てこないのはどうなんだろ。そこをブラックボックスにしちゃったら、この本の存在意義って?
追記@21:20
第3章はハンドアセンブルの話。さっきの章で出で来なかった CPU 内部のレジスタ構造がちょっとだけ出てきたが、詳しいものじゃなかったな。俺は不満だ。
「変換表とにらめっこしろ」で終わる話なので、全体的に薄味。
追記@21:40
第4章はフローチャートをメインにプログラムの処理の流れについての話なんだが……。
サンプルコードを VBScript で書くな!
何でいきなりウィンドウが出てくるようなコードを出すんじゃヴォケ。そもそもウィンドウが出てくるってことは、何かしらの形でイベントに触れないといけないはずなんだが、なぜかその後で WinAPI のちょろとした説明でお茶を濁してるし。それにさあ、今までアセンブリとかマシン語を見せていていきなりノー説明で VBScript はねぇだろ。
大体フローチャートってのはアセンブリ言語レベルの低水準言語の動作を説明するためのもので、それ以上の高水準言語になると、むしろフローチャートの方が記述水準が低くなってしまうんだが。
あと途中で出てきたダイクストラの構造化プログラミングについて一言。確かオリジナルのダイクストラの論文の趣旨は「恣意的なジャンプ命令（goto）を避けるための方法と言語の進化」みたいな感じだったはずで（うろ覚え。違うかも）、実際のところ近代的なプログラミング言語でもループからの break や関数からの return、そして例外処理といった「飼い慣らされた goto」を採用しているものが殆どで（手続きスタイルの言語は全部そうじゃない?）、屁理屈に聞こえるかもしれないけど goto はそこらに散らばってるんだよ。だから goto を使わなければいいというものじゃないの。
割り込み処理を通常のフローとの対比に持ってきてるのも変といえば変で、これはポーリングとの比較で使うべきだろう。せっかくハードウェアレベルの事まで書いてるんだから、ポーリングの説明も欲しかったところだ。
なんかやる気がなくなってきたけど頑張って読もう。
追記@22:26
アルゴリズムの章とデータ構造の章は、特に書くことなし。まあ、教養程度の内容ならこれでいいのかな。
しかし C のプログラムで変数も関数も ObjectName みたいな名前にしてんのは心の底からどうかと思った。これ刊行されたの 2003 年だろ? 俺が大学二年の時だ。そんときゃもうこんなネーミング規約は廃れていたような気がしなくもないが。
追記@22:41
あれ、 2003 年あたりって OOP の説明ってこんなんで良かったんだっけ。俺はもうちっとまともなものを習った覚えがあるぞ。
それで残りも一通り読んだけど、まあ結論としては素人に読ませるにしてもこれはないな。散漫な上に偏りすぎ。なんとなく予想はしてたけど、他人に物事を教えるときには咀嚼済みの本を使っちゃダメで、なるたけ堅い本を教える側が相手に合わせて咀嚼して説明しないとダメだ。
しかしそんな事やってる時間があるかっつーと、まあ無理なんだな。プログラミング研修だけでも大変だってのに、そこに計算機科学の基礎をきちんと教えてる時間が取れるかというと、まず取れない。いや、俺が研修だけやってりゃいいってんならまだどうにかなるけど、他の仕事もあるからなあ。
あと俺の持ってる本は上司曰く「堅すぎて他の社員も付いてこれない」そうなので、やっぱ結城先生の本に頼るしかないのか。ってか実際に「Java言語プログラミングレッスン」を研修で使ってるし。
2008-07-22
Tue
2008-07-23
Wed
(21:46)
「1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分、合計3万5000Kバイト確保するよう記述しなければならない。だが、1銘柄当たりのメモリー領域を誤って4バイトとしてしまった」ってことは、もしかしてこういう事?
foo(struct bar* buz) {
sizeof (*buz); <- struct bar のサイズが取得される
...
}を間違えて
foo(struct bar* buz) {
sizeof (buz); <- struct bar へのポインタのサイズが取得される
...
}とやってしまった……としか思えないなー。いや、実は違うのかもしれないけど、この 4 バイトというのは情況証拠として扱ってもいいような。だってねえ、本来のメモリ量が銘柄あたり 1280 バイトで、実際には 4 バイトだっていうのはねえ。
2008-07-24
Thu
(23:16)
今月入った新人を見てると、何ていうか決して埋められない知能レベルの溝というものがあるんじゃないかと思える。もしかしたら、採用戦略を切り替えてから始めてクビ宣告をしないといけないかもしれない（既に本人にはもう後はないと上司が伝えている。俺より先に痺れを切らせたらしい）。前にも書いたとおり、そういう事はなるたけやりたくないんだが……。それでも、どんなに自分の中の閾値を下げてもアウト判定せざるを得なくなってきた。
数日前に研修課題の一部を載せたが、あの問題なんぞ実際にどうやってコーディングするかなんていう前に、文字列がある規則に則ってパターン化されており、実際に解かなければならない部分はすべてそのパターンの中にあるということが直観的にわかってもらわないと困る。ってか具体的な手順が思いつかなくても、「パターン」の存在程度には気がついてほしい。ぶっちゃけ、パターンの存在に気がついて、そこに筋道立ててアプローチできればほぼ合格だ。
ところが実際に解かせると、パターンの存在にまったく気がつかないのだ。マジで俺が言ってやるまで気がつかず、思いっきり的外れな事を考えていて、そして俺には全然相談に来ない。見かねた俺が声をかけると、一体何の意図があって書いたのかわからんコードを指さして「こうじゃダメなんですか?」と聞いてくる始末だ。
聞く前にコンパイルして実行しろよ。まあ妙なコードを書くのは仕方がない。本当の問題は相手の思考の過程にあるんだから、俺は必ず相手に「なぜそういうコードを書いたのか」を正解だろうと不正解だろうと説明させることにしている。これは大学でプログラミング演習の手伝いをしていたときからのスタイルで、師匠が俺に対してやったことでもある（程なくして「相手に説明させる」事が非常に普遍的な問題解決法だと知った）。
ちなみに今日出てきたコードというのは、まあなんていうかこんな感じ。
int point = str.indexOf("foo", "bar", "buz"); //str は String 型変数ねうん、まあ、やりたいことはわかる。そしてその後のやりとりがこんな感じ。
- 俺
- 「コンパイルエラーが出ているけど、それは置いといてこのコードでやりたい事を説明してくれ」
- 新人
- 「"foo" と "bar" と "buz" の位置を調べようと……」
- 俺
- 「OK、わかった。 indexOf というのは着眼点として正しい。それじゃ、 point にはどんな値が入る?」
- 新人
- 「"foo" の位置が入ると思います」
- 俺
- 「じゃ、 "bar" の位置はどうなるのかな?」
- 新人
- 「……やっぱこの書き方じゃダメなんですか?」
- 俺
- 「質問に質問で返すな」
いや、マジで質問に質問で返されるとムカつくぜ。そもそも Javadoc に String 型の引数は一個しか取らない事が書かれているのに、複数の値を渡そうとする意図がよくわからん。そして何でそんな勘違いをしたのかは結局わからずじまいだった。そこがわからんと適切な指導もへったくれもないんだが、先に俺の心が折れた。
今日起こった事例を全部書いていくと俺の精神がもたないのでここでやめとくが、とにかく一事が万事こんな調子で、しかも上記の例はまだぐんにょり感の低い方なんだよ。もっとトホホな事が実際に起こっているんだからやってらんねえ。これを開発業務の合間にやってるんだから、かなりのストレスになる。あと他のメンバーの進捗管理と本体チームへの報告などの管理ワークもあるからなあ。
あとサンプルがちと少ないけど、できの良い奴と悪い奴の間で見られる傾向の違いってのがあって、
- できの良い奴
- 相手の話の重要っぽいところはメモをきちんと取る
- 自分の書いたプログラムを説明する時に下手でもなんでも図を書こうとする
- 教えている内容以上のことを調べて質問してくる
- 会社に置いてある専門書を手に取る
- 自腹で本を買う
- 出来の悪い奴
- 上に書いてある事を全部やらない・できない
あと「抽象的に物事を考えられない」のが大学の落ちこぼれと新人研修の落ちこぼれに共通する特徴で、これできない奴は全然できないんだよなあ。これは教えようと思っても教えられるわけじゃなく、本人が本気でプログラミングに取り組まないと絶対に身につかない。
書いていて思ったんだが、まさか研修を受けていればプログラミングができるようになると思っているのか? いや、なんつーかそれはないよ。そもそも研修なんてのは、地図も方位磁石も持ってない状態の奴にそれらを渡す程度の意味合いしかないんだって。つまり、自力で目的地まで辿り着く必要があるわけだ。世の中にはやる気はあるけど最初の取っ掛かりが掴めないって人もいて、そういう人はポイントポイントでアドバイスしておけば、勝手にレベルアップしてくれる。それこそ上の方で書いたように、自分で本を買ったりしてくれるんだよ（先々月まで指導してた奴らがそうだった。何だかんだいってそういうのは伸びるよ）。
相変わらずグダグダと書き連ねちまったが、とにかく研修の担当官は自分の指導というか切り捨てるかどうかのジャッジのタイミング次第で会社に損害が出るんで、これ結構厳しい立場なんだよ。それにクビ宣告って、他の社員のモチベーションに影響するわけだろ。お願いだからもっと本気で取り組んで、俺に「クビ」という判断をさせないでくれと思う。会社の採用方針が「未経験可」であり、そして俺に面接担当の権限がない以上、俺にいえるのはこれぐらいだ。
2008-07-25
Fri
(00:25)
最近全然定時で帰れてねー。もう残業代とかホントどーでもいいから定時で帰らせてくれと思うけど、立場上他のメンバーの成果物とかいろいろチェックして、そっから進捗状況書いて送ってとかいう作業があるからな。
こんだけ小規模でも管理作業ってめちゃくちゃタルいわけで、やっぱ俺は大規模開発じゃ管理者側には絶対に回りたくねーな。まあ、そういう役割をあてたら辞めるとは伝えてあるので、さすがにそれはないだろうが。
(08:58)
何が原因かさっぱりわからんが、どうにも食中りっぽい。こりゃダメだ。
(20:53)
とりあえず昼から出社したが、おかげで今日の分の仕事が全部終わらなかったな。まあ、元から全体的にスケジュール前倒しだから、まだ大丈夫ではあるんだが。やっぱ研修にかかる時間はボディブローのように効いてくるな。
2008-07-26
Sat
(16:54)
アクセスログを見てみたら http://twitter.com/home とか http://www.tumbler.com/dashboard とかのアドレスがリファラに残ってたんだけど、これはつまりログインした後にユーザ固有のアドレスにリダイレクトさせずに使わせているってことか? 俺はどっちのサービスも使ってないし使う気もないんでわからんが。
俺は意図してこういう URI 設計をしでかす奴はバカだと思うが、何となくこれはフレームワークとかそっち側の問題にも思える。サーバサイド Java とかでもリクエストをフォワードすると本来の URI と一つずれる問題というのがあって、例えば example.com/login でログインした後、 example.com/main へフォワードするとブラウザのアドレスバーには example.com/login のままになるとか。かといってリダイレクトをかけると、余計なパラメータやセッション情報の引き継ぎが出てくるんで、やっぱり話は単純じゃないんだけど。
特に最近は Ajax やらなんやらのおかげで、アドレスバーの情報が当てにならんことが多そうだよな。まったく住み難い世の中になったもんだ。
(23:30)
ギターピックの整理をしようと思って使わなくなったピック入れを開けてみたら、出るわ出るわ役目を終えたピックが。一応どれも多少は使ったんで、流石に全部は無理だけど使用感の簡単なレビューでも。ちなみにこんだけいろいろ試してる理由は、自分の下手さを機材でカバーしようという魂胆があってのことだ。俺は弘法じゃないんだ、筆ぐらい選ばせてくれ!
History の出してるウルテムを使ったピック。何か人間の爪に近い素材とか言ってた気がする。いや、それは違う素材か? 弾き心地はまあまあ良かった。ただ、あんま速いフレーズには向いてなかった気もする。極めて硬いので寿命は結構長い。
PickBoy の金属製ピックシリーズはいろいろな素材の奴が出てるが、チタン製の奴をチョイス。他にも銅とかアルミとかニッケルとか出てるけど、まあどれも金属だから基本一緒だ。つまり、やたらと硬くて寿命が超長い。
何となく持ったときの感触とかは違うけど、ヘタクソなので音のニュアンスに変更が出るかどうかまで確認できず。結構気に入っていたけど、ピックングハーモニクスを出すと指に金属粉が付くという極めてウザい欠点があったので封印。
ちなみにこういう、極薄のメッシュ型にしてしなりを持たせたピックも出てる。弾き心地はあまり良くなかった。まあ、金属自体が好き嫌いの分かれすぎる素材か。
これは Paul Gilbert のシグネイチャーピック……なのか? 弾き心地は良かったけど、いくらなんでも削れ易すぎな気がするな。弾き方が乱暴な俺にはあまり合わなかったような。
一般的なセルロイド製のピックは実はあんまり使ってない。このピックも実際にはベースを弾くのに買ってみたという代物。ちと反発が強すぎて指が負けそうになるんで、結局封印した。
我らがギターキチガイ、インギ様のシグネイチャーピックらしい。ってかインギ様はこんなの使って弾いてるの? 嘘だろ。分厚くて丸っこいので、とにかく違和感がバリバリ。俺にはまったく使いこなせなかった。
日本じゃ Music Man の方が通りがいいかもしれない、 Ernie Ball のニトロセルロース製のピック。厚さは Medium の他に Heavy も試した。弾き心地はそれなりだけど、これも削れ易すぎ。あとピックにペイントされたロゴが溶け易すぎ。
よくわからんピック。削れ易すぎな上に嫌な削れ方をするので速攻封印。
こっから先は今現在使っているピック。
通称マリファナピック。カーボングラファイトとナイロンの混合素材で、弾き心地はとても良い。非常に硬く、先端がジャズ型並に尖っているので速いフレーズにも対応できそう。何よりパワーコードとかをバキバキとダウンピッキングで弾くのがとても気持ちよく、ピックの横あたりを押し付けるようなピッキングをすると面白いニュアンスが出る。
なので結構気に入っているのだけど、削れてくるに従って他のピック以上に音と弾き心地が急速に劣化してくるように思える。というわけで、最近は次のピックに浮気ぎみ。
こいつは Dunlop のトーテックス製ジャズ型ピック。とにかくこいつも硬い。弾き心地は非常によく、パチンと弾ける感じがする。あとジャズ型が販売されてるのが非常に大きい。俺の腕じゃティアドロップ型だとキツいフレーズも、ジャズ型だと追いつけたりするんだよな。それにピッキングハーモニクスも出し易いしね。
ちなみに最近はベースを弾くのにセルロイド製の Medium を、ギターのコードカッティング系のフレーズの練習に同 Thin を使うようになった。
そして今まで試したピックの中には「あ、こりゃダメだ」となって速攻ゴミ箱送りになった奴ってのが実は結構な数あって、それと今回面倒で言及しなかったものを含めるとさらに倍ぐらいのピックを試してる気がする。まあ、とりあえず最後に挙げた四種類で今後は回していくと思うが（でもベースは全然練習量が足りないので、今後はベース用のピックは変わるかも）。
2008-07-27
Sun
(20:41)
何日か前に「コンピュータはなぜ動くのか」に対して厳しい評価を下したが、実際のところあれよりも酷い地雷本が存在するからな。内容がアレな上に巻末に著者達によるポエムが載っているとか。
いや、マジでそういう本があったんだって。タイトル思い出せないけど。
2008-07-29
Tue
(22:43)
昨日は家帰ってすぐにダウンしてしまったので日記が書けんかった。時々こういうことがあるんだよなー。
それはともかくとして、今月入った新人の研修なのだが。進みが結構遅い部類なので、俺は何か手を打たねばならん。社長からは「1日あたり1時間でいいから何か講義でもやったらどうだ」というような事を言われたが、それはつまり開発仕事しながら講義のカリキュラムを作れというのか。俺は大学の教員じゃねえって。
でも確かに何かしらやんねーとマズいっぽいのも事実なんだよな。また未経験の新人が入ってくるし、そもそもさらに人を採る予定らしいし。
ところで先週の土曜に久しぶりに親戚と会ってきたんだけど、未経験でもバンバカ採用というのが IT 業界で横行しているという話をしたら、まあなんていうかかなり驚かれた。気持ちはわかるけど、それが事実なんだから仕方がない。それにまあ、別に専門教育受けなくてもプログラミングはできるようになるっちゃなるし、そこまで高度な技能が必要ないケースというのも多いし。
……それでもアウトな連中はゴロゴロしてるんだけどな。
2008-07-30
Wed
(01:46)
風邪ひいたってわけでもないのに、やたらめったら咳が出るんだけど、一体何が原因なんだか皆目検討が付かない。ってか既にこの症状になって結構経つんで、いい加減医者に行こう。
追記:そういや、本社は去年までの現場に比べて空調の効きがキツめだから、もしかしたらそれでノドをやられてんのかも。でもここまで酷くなるかなという気もするが。
(21:51)
「ホーリーランド」の最終巻を購入。内容的には「ありがとう神代ユウ。そして伝説へ……」という、ぶっちゃけこの時代にこれをもってくるかあなたはという代物だったが、「普通やらねえよそれ」って事をやる漫画だったので、この幕引きはある意味で大変正しい。多分。
それにしてもラスボスを少林寺拳法使いにした理由が凄いよな。だって作者が実際に立ち会って全然歯が立たなかった武術が理由なんだから。ここら辺はまんが☆天国のインタビューに載ってた。「路上で柔道はマジヤバい」も実体験がベースになっているとか、漫画以上に本人の方がガチってどういうこった。
あと作中の格闘技描写が物議を醸したりもしてるけど、まあなんていうか漫画の表現にそこまで熱くなるなよって感じだよな。これがアウトならバキとか餓狼伝とか全部アウトじゃん。
2008-07-31
Thu
(23:05)
今回の新人にまず教えなきゃならんことは何かと考えてみたら、俺をイラつかせない質問の仕方と態度という結論に達した。いや、半分以上マジで。
それにしても高等教育、それも俺の出身大学よりも遥に高いランクの大学を出ていて、それでこの程度というのは如何に日本の教育が形骸化しているのかというささやかな証拠になるな。とりあえず今日あったトホホな事例を一つあげてみよう。
まずは次のようなコードがある。
class Foo {
static int x;
static int y;
static void someMethod() {
...
}
public static void main (String[] args) {
...
}
}中身は適当に想像してくれ。とりあえず static 変数と static メソッドだけで何かやってると思えばいい。実際にはコマンドラインから単純な数式を受け取るプログラムで、まあそれにも結構難儀したんだがその話はどうでもいいや。それでまあ main メソッドの中で自身をインスタンス化してインスタンスメソッドとインスタンスフィールドを使って処理をするように書き換えさせたんだが、まさかというところで何度も引っかかった。
まずは俺が雛形として書いたのが次のコード。
class Foo {
private int x;
private int y;
private void someMethod() {
...
}
private void exec(String[] args) {}
public static void main (String[] args) {
...
}
}ぶっちゃけ main の中身を exec にコピペすればほぼ終了なんだが、とりあえず自分の作ったクラスをインスタンス化するというのを体感してもらえればそれでいいや程度の話なんでな。それで「main では Foo のインスタンスを作って exec を呼ぶだけにしろ」というように指示を出しておいた。
ところがどうも勘違いをされたらしい。出来上がって来たのが次のコード。
class Foo {
private int x;
private int y;
private void someMethod() {
...
}
private void exec(String[] args) {
//public static void main (String[] args) {
...
}
}なんで俺の書いたテンプレをぶっ壊すんだよ。それで書いた本人からは「何でこれ動かないんですか?」とかすっとぼけた反応が返ってきたが、そりゃそうだろう。 main メソッドがないんだから。あと俺 main で Foo のインスタンスを作って exec を呼べって言ったよな。全然違うっつーの。
というわけで書き直しをさせた結果が次。
class Foo {
private void exec(String[] args) {
private int x;
private int y;
private void someMethod() {
...
}
}
public static void main (String[] args) {
...
}
}俺こんな指示出してねえよ。俺が出したのは「main 相当の処理は exec に書け」「main では Foo のインスタンスを作って exec を呼び出すだけにしろ」って指示なんだけど、全然違うじゃねえか。それで「コンパイルが通りません」って、お前それ以前の問題だって。
それでまあ、仕方がないから壊滅的に間違ってる部分とかを指摘しつつ、まずは main の処理をインスタンスを作ってメソッドを呼ぶだけの形にさせてみた。
public static void main (String[] args) {
Foo foo = new Foo();
...
}うん、そういうことだ。じゃあ exec を呼び出してみようか。
public static void main (String[] args) {
Foo exec = new Foo();
...
}だからなんでそうなる? それ変数名変えただけだろ。っていうかお前、下の方で args[0].indexOf(...) とかいうコード書いてるだろ。それがメソッド呼び出しだって教えただろ。それと同じだっつってんだろ。何でそっから普通に類推出来んのじゃ。下手な鉄砲も数撃ちゃ当たるかもしれんが、その前に仏の顔も三度という言葉を覚えとけ。
俺はここ最近やたら咳が出るようになって喋るのが結構しんどくて、ぶっちゃけくだらんことを延々と説明させるなと思いつつ、可能な限り噛み砕いて説明してからしばらく放置して書き上がったのが次のコード。
class Foo {
private void exec(String[] args) {
private int x;
private int y;
private void someMethod() {
...
}
}
public static void main (String[] args) {
Foo foo = new Foo();
foo.exec(x, y);
}
}お前、俺の話聞いてないだろ。というか渡した本はちゃんと読んでるか? もう一ヶ月ほど経つんだから、いい加減この辺の基本的なヘマで俺を呼びつけるとか勘弁してほしいぞ。そもそもさっきダメ出ししたコードをそのままにして、そのダメなコードを元に適当ぶっこいてるんじゃねえよ。
かといって一から十まで説明しすぎるのもよくねえから、そこは我慢しつつやってるけどよ。でもこれ、本当に学習してるのかかなり怪しいぞ。何か適当に総当たり戦術で書けそうなコードを書いて、それでまぐれ当たりのコードを何も考えずに動かしてるだけって気がしなくもない。
もう一人の研修生も強烈なものがあるが、そっちまで書いてると本気で明日会社に行きたくなくなるからやめておく。
ってか俺、何のためにこの会社入ったんだっけ……