2010/07/27
主観で何が悪いのだろう
この記事自体には特に異論はないのだけれど(特に取り立てて書くようなことでもない、とも思うけど)、 それに対する反論というのが興味深かった。
以下、この事をTwitterで紹介した際にあった面接を担当しているであろう方々からの主な反論を紹介します。
- 「印象採用＝好き嫌い採用」なんて論外。採用担当者は最後まで自分の第一印象を疑って面接をするように訓練されています。可能な限り主観を排除せよと。全く逆の考え方で驚きました…
- 第一印象はあてになりません。恋人を選ぶのではなく仕事を成功に導くためのパートナーを探すのだから主観は排除するよう努めるべき
- 当社ではそういうことにならないように、明確に評価基準を定めています。その基準は社員の人事評価基準に則っています。質問項目も決まっています。こんなに大事なことを、コミュニケーション能力とか面接官の印象とか、そんな曖昧なことで判断するわけにはいきません。
これらを読んで思ったのが、ちゃんと面接官を専門に担当する人々もいるということを知りました。プロの面接官は明確な評価基準を持っていて、印象になるべく左右されないように努めているようです。
主観で面接したら何が悪いの? いや、主観を排した面接がだめだ、っていうんじゃなくて、 主観で取るかどうかというのは、面接のゴールにはあんまり関係ない話じゃないかなあ。
面接のゴールというのは、欲しいポジションにベストマッチな人を選ぶってことだけど、 それが達成できたかどうかっていうのはすぐにはわからない。長期的に一緒に働いてみて 始めてうまくいったかどうかがわかる。歴史の長い、変化の少ない組織なら、 「こういう基準で選ぶと当たりが多い」というノウハウが明文化可能かもしれないから、 そういう客観的基準で選べばいいだろう。歴史が短かったり、変化が必要な組織なら、 逆に基準なんてわかりようがないのだから、面接官のセンスという一種の主観に頼らざるを得ないだろう。
一般的に対応できる方法が無い以上、一般的に適用できるノウハウというのは メタな基準にならざるを得ない。それはつまり、この一点だ。
- 「採用担当者が、自分の判断に責任を持てる仕組みであること」
これが保証されていれば、印象で選ぼうがチェックリストで選ぼうがサイコロで選ぼうが どうでも良い。採用担当者が自分が責任を持てる方法を自分で選ぶだろう。
この議論を進めるならば、多くの職場にとって有効度が高いのは、
- その人が採用されたら一緒に働くことになるであろう人間と、 その部門のパフォーマンスに責任を持つ人間が面接をする
といことになる。同僚や直属の上司は、一緒に仕事しにくい人を選んでしまったら 後々大変だろう。一方で、部門責任者は長期的なアウトプットに責任を負わなければ ならないので、単に仕事しやすいだけの仲良しクラブになってしまうことは避けようとするだろう。 また、そのポジションに必要とされる能力というのを最も的確に判断できるのは、 その専門性を理解している人間である。その点にも、現場経験者が面接をする重要性がある。
この議論の裏返しで、最悪の面接スキームとは、
- その人が採用されても一緒に働くとは限らず、 またその部門のパフォーマンスに直接の影響を受けない立場の人間が面接をする
ということである。例えば、人事部の人間が面接をする、とかね。
(念のため、日本型雇用がどうの、って話はわかってて書いてる。 言いたいのは、将来もそれでやってけるの? ってこと。)
Tag: Career
2010/07/15
JRE hassle
Hudsonをちょっと手元 (Ubuntu 10.04) で試そうと思った。 オフィシャルページを見るとhudson.warをダウンロードして java -jar hudson.war とだけすれば良いらしい。おお、簡単ではないか。
簡単ではなかった。
- アップデートしたばかりでまずjavaを入れてなかった。とりあえずapt-getでgcj入れとく。
- hudson走らせると何かクラスが見つからないというエラーで初期化時にこける。
- ぐぐるとどうもgcjでは動かないらしい。
- apt-cache searchで探して次に目についたopenjdkで試す
- 今度はjava.io.IOException: Operation not permittedなどのwarningが出て、httpでつなぐと「ちょっと待ってくれ」という画面から進まない。
- さらにぐぐるとどうもsun-java6を使うのが無難らしい。
- https://help.ubuntu.com/community/Java を参考にするが、 universeを探してもsun-java6なんて無いぞ。
- Bug trackerの議論を追っかけて このブログに到達。partner repoを見なくてはいけないらしい。
add-apt-repository "deb http://archive.canonical.com/ lucid partner" apt-get update apt-get install sun-java6-jre sun-java6-plugin update-java-alternatives -s java-6-sun
- 再び走らせる。あれ、またjava.io.IOException: Operation not permittedだ。
- ぐぐる。今度はfirewall絡みらしい。
- こちらを参考に firestarterの設定をいじって再起動。
- 今度こそ成功。
こんなことは珍しくはないので、特定のソフトウェアに責を帰するつもりは ない (多分GaucheやCLで何か動かそうとする人も似たような苦労をしてるはず) けど、 いくつか考えのネタは得られると思う。
ランタイムの配布の問題
時々、処理系の機能として「単独の実行ファイルが作れるか」ということを問題にする人が いるのだけれど、そういう人が本当に欲しいのは大抵「ファイルひとつコピーすれば 動く」という話だったりする (Cf. WiLiKi:Gauche:StandAloneProgram)。
んで教科書的回答は「ターゲットにランタイムが入ってればいいんですよ」ってことに なるだけど、十分に主流になったJavaでさえ未だにランタイムではまることがあるって ことは、もっと深いところでの解決が必要なのかもしれない。
というか、ランタイムのことを気にしないでもアプリを配布できる言語って 今でも事実上Cくらいしかないのかなあ? それって、OSの主要コンポーネントも そのランタイムを必要としているから、という理由が大きいよね。 まああとAPIが十分に枯れてるって要素もあるけれど。
とすれば、ランタイムを気にしなくても良くなるにはその言語がOSの主要コンポーネントにも 使われて、かつAPIが十分に枯れることが必要になる。でも発展途上の言語にとっては ちょっと無理な要求だ。javaでさえ苦労してるのに。
複合した問題の切り分け
今回、firewallとの干渉があったわけだけど、 ランタイムの問題があったせいでちょっと遠回りした感がある。
複数の問題が同時に起きていることはよくあることで、 問題を切り分けてひとつづつ解決するしかないのだけれど、 そのメタ手順自体はなんだか昔から全然変わってない。 もう少し、なにか賢いサポートがあっても良いんではなかろうか。
git bisectの発想に良い筋を感じる。あれは問題そのものを解決してはくれないけれど、 問題がどこで生じるかを調べる決まりきった手順を自動化してサポートしてくれる。
複合問題の切り分けでは、関係する要素をひとつづつ変えて試す作業を 最悪で全てのパターンについて行う必要がある。ただ、ある組み合わせで うまくいったら/いかなかったら他のいくつかの組み合わせは試す必要がない、 というケースはあるので、うまくテスト方法を選べば大幅に 枝刈りできる可能性もある。
システムレベルの問題なら、変更要素は「何をインストールしたか/しなかったか」と あとは各々の設定の切り替えが主なものなので、そのへんをカバーしてくれる テストサポートツールというのはあり得るんじゃなかろうか。
Tag: System
2010/07/14
少し前から右手親指の付け根が痛んでて、 腱鞘炎になったらやだなと思ってたんで、 日本に行った時、本屋で目についたこれを購入。大当たりだった。
本書で「親指の炎症を引き起こす危険が高い」とされている、
- 親指主導の動き (橈骨を中心に手を回転させようとする / 手首が尺骨側に曲がりがちになる(尺側偏位))
- 親指をいちばん根元の関節(手根中手関節)ではなくその次の関節(中手指節関節)から動かそうとする
に見事当てはまってた。自分が弾いてるビデオを見ると、不自然な尺側偏位があることと、 手根中手関節を動かす腱が緊張しっぱなしで関節を固めてしまってることがよくわかる。 そして痛みは確かに中手指節関節を動かす腱の腱鞘にあるようだ。
尺骨から小指を軸として意識すると、確かに親指の緊張が抜けてうんと楽になる。 ただ、これまでの弾き方が習慣になってしまっているので、よっぽどゆっくり弾かないと すぐに前の形に戻ってしまう。しばらくゆっくりさらってリハビリしよう。
この本は手の使い方だけでなく、全身の骨格と筋肉を意識することを論じている のだけれど、芝居での身体の使い方と重なる話が多くて興味深かった。
Tag: Piano
2010/06/28
アセンブラをぶっとばせ
http://twitter.com/vitroid/status/17262472219
開発者の生産性を上げるために新しい言語が創られる。速けりゃいいならアセンブラで書けばいい。 RT @osiire: これは私の周りの狭い世界では逆。 > "むしろ大部分のコードは今以上の性能を求められてると言えるんじゃなかろうか。" http://bit.ly/bDlkJS
「速さが欲しいならアセンブリで書けばいいじゃない」っていうのは、 ひとつ重要な条件を見落としてるよ。仕事で開発してるなら、 開発期間っていうのはコストだから、上限がある。 従って求められているのは、「所定の時間内で速いコードを書く」っていうこと。
最適化は時間内にどれだけ色々なアプローチで「実装→計測」のサイクルを 回せるかっていうのが決め手だが、アセンブリや低レベル言語で書いてる場合、 アプローチを切り替えるコストがばか高い。別のアルゴリズムを試したい 場合や、コードに影響を与えるパラメータを変えて実験したい場合 (簡単な例では、ループのunrollingをいくつ単位でやるか、とか) に手間がかかるからね。
だから、「開発者の生産性を上げる」ことを性能低下の免罪符にする 必要は無いんだ。むしろ、 性能を上げるためには開発者の生産性を上げることが必要なんだ。
言語/処理系設計上のトレードオフとして、開発者の自由度を上げると 処理系の負担が増えて性能が低下する、ということはある。例えばいつでも 動的にコードをすげ替えられる方が開発は楽だけれど、処理系は 静的に解析できる部分が減って最適化しにくくなる。 でもそここそが処理系作成者が頑張るべきところであって、 処理系作成者が開発者の生産性を上げることを性能低下の言い訳にするのはまずい。
あ、でも勘違いしないでね。「速ければ速いほどいい」って言ってるんじゃないよ。 「要求性能を満たしたい」って言ってるだけなんで、 言語/処理系のターゲットとしている領域で必要な性能が出てるなら それ以上頑張る必要はない。
ていうかさ。必要な性能を出せなかったらどんな言語を使おうが 意味無いよね。最初からそういう話をしているんだけどなあ。
★ ★ ★
あと、今でもとりたてて頑張らなくたって性能が出てるソフトウェアは たくさんあるだろう。それはそれで全然構わない。 けれどもちょっと考えてみて欲しい。今、使えているソフトウェアっていうのは、 今ある技術で「使える」性能に達しているものだ。だから 今あるソフトウェアの世界だけを見てたら、「性能は足りてるじゃん」と思えるだろう。 でもそれが世界の全てなのか? その世界の外側にも、書かれるべきソフトウェアがあるんじゃない?
Tag: Programming
2010/06/26
性能へのアプローチ
http://twitter.com/yoriyuki/status/17071304021
Listp好きの人って、なぜLispをCやPythonやJavaとばかり比較して、HaskellとかMLとかとは比較しないんだろう。そのほうがよっぽど面白いのに。と、これを読んで思った。http://bit.ly/cnrWxy
ここでは性能の話をしていたから。性能の話なら、一応広く信じられているのが Fortran/C/C++あたりは性能が出るってことなんで、チャレンジするなら そっちを相手にせざるを得ない (Cf. As Fast As Cee)。 LispとMLで性能比較してもアピールする読者がごく限られるだろうし。 自分もこのネタは何度も書いてて飽きてるんだけどねぇ。 あとまあ、自分がそれでコードを書いて性能を追求したことのある言語が CとLispくらいだから、というのもある。 Haskellでどうやって性能を出したらいいのかわからないもの。
ただまあ、おおまかな傾向というのは言えるかも。
たぶん、HaskellにせよMLにせよ、性能へのアプローチの柱になってるのは コンパイラをとにかく賢くするってことだ。 コンパイラがうまいコードを出せるようなヒントの与え方、 ってノウハウはあるけれど、 最後の最後はやっぱりコンパイラにお任せ。 Schemeもわりとそっち寄りのところがあって、 例えばcall/ccはナイーブに実装するととても遅くなるのだけれど、 「それは実装がタコだからだろ」で済まされる。 理屈の上で速い実装が可能ならば、それをしていないのは 意識的な選択でなければ実装者の怠慢とされる。
Common Lisp陣営は逆の立場。今、ここに、目的の性能を達成できる Sufficiently Smart Compilerが無いのなら、ぐだぐだ言わず 俺に低レベルコードを触らせろ、というわけだ。 なぜって、アプリケーション特有の最適化のツボを一番知っているのは アプリケーションプログラマであって、コンパイラ作者じゃないのだから。 コンパイラ作者が一番最適化できるなんてのは幻想、あるいは傲慢。 (Naughty Dogのように、アプリケーション作者=コンパイラ作者である場合は別で、 その場合は効果が最大となるけどね)。 実際問題として、 例えば「確実に、ここからここまでは一切アロケーションを行わない」という コードは必要とされるわけですよ。コンパイラが解析を頑張って、その間に 作られるオブジェクトはどこにもリークしないってことを証明できれば アロケーション無しのコードを吐けるだろうけど、 そうでない時に「コンパイラがタコでした」では済まされないよ、と。
現実的には両者のハイブリッドで行くしなかないと思うのだけどね。 アプリケーション作者が一番ツボを知っているというのはたぶん真実だけど、 その部分のコードというのは全体の1%くらいで、残りの99%は コンパイラの一般的な最適化で頑張ってくれた方がずっと良い。
ただ、関数型言語陣営がSufficiently Smart Compilerの存在を 当てにしているのだとすると、ちょっと危うい見通しがある。 今現在、関数型言語のひとつのコンパイラ、例えばghcの開発に関わっている人間/予算と、 C++のひとつのコンパイラ、例えばiccの開発に関わっているそれとを比べると、 後者の方がかなり大きいだろう。 また、最適化というのは最適化したいアプリケーションがあって始めて 進むものなので、アプリケーションの量も多いに越したことはない。 さらに、プロセッサもまた主流の言語処理系が吐くコードのパターンを意識して作られる。
結局、理屈の上で関数型言語の方が最適化しやすいのだとしても、 性能の面で主流の言語が強くなるポジティブフィードバックループの前では、 理論上の優位点なんてのはわずかなアドバンテージでしかない。 その優位点が本当に現実の問題を解決するか、ということを証明するのは、 関数型言語プログラマに課された仕事だろう。
★ ★ ★
性能性能と言うけれど、関数型言語のアドバンテージは別にあるんじゃないの、 という意見もあるかもしれない。そりゃもちろんそうだけれど、 だからといって性能の方を妥協すべきではない。
Haskellで書いたらこんなに綺麗、型不整合のバグとも無縁でハッピー、 っていうのはプログラマにとっての大きなメリットだけど、 それが商用プログラムなら、お金を出してるお客さんにとっては 出来上がったものが期待した機能と性能を提供するかどうかが第一で、 プログラマがハッピーかどうかは二の次だ。 プログラマが楽しいと生産性が上がりますよ(=期間が短いので安くできますよ)、 ってのはアピールポイントだけど、安くても必要な性能が出なけりゃ意味が無い。
ハードが速くなってきたから性能を気にする時代じゃなくなった、 なんて言う人もいるけれど、 (世界中で求められている総計算量/世界中の総計算資源)を考えれば、 むしろ大部分のコードは今以上の性能を求められてると言えるんじゃなかろうか。 そりゃ周辺部分では性能要件は緩くなってきたけれど、 言語としてそういうニッチだけを狙うというのは目標が小さかろう。 (特定のビジネスや特定の処理系がポジションとしてニッチを狙うのはありだが。)
★ ★ ★
さてそろそろ、12億レコード喰わせるのに3時間かかってる処理を 50倍に高速化する作業に戻らねば。
Tag: Programming
Comments (0)