仙石浩明の日記

2006年4月26日

VPN-Warp 入門編 (5)

前回は、リレーサーバへのアクセスは https なので、 stone 以外のソフトウェアも使えるというお話をしました。 一例として OpenSSL 付属の s_client を使ってみたわけですが、 https を扱うクライアントソフトウェアといえば普通は WWW ブラウザですね。 というわけで今回は WWW ブラウザでアクセスする方法を紹介します。

ブラウザで https://relay.klab.org/ をアクセスすると、 次のようなリクエストヘッダが SSL で暗号化されて、 リレーサーバ relay.klab.org へ送信されます。

GET / HTTP/1.1
Host: relay.klab.org
User-Agent: Mozilla/5.0
...
(空行)

リレーサーバは SSL クライアント認証を要求するので、 ブラウザは証明書ストアにある SSL クライアント証明書を使用して 認証を行ないます。 利用できる SSL クライアント証明書が複数ある場合は、 ブラウザが証明書の選択画面をユーザに提示し、ユーザが選ぶことになります。

リクエストヘッダを受け取ったリレーサーバは、 同じ証明書を持つ relayagent からの接続が存在すれば、 その relayagent との通信を確立させるのでした (VPN-Warp 入門編 (3)を参照してください)。

つまりリクエストヘッダに続いて送られるデータがポートフォワード先に送信され、 ポートフォワード先から返されたデータが、ブラウザに届きます。

が、ちょっと待ってください。 前回までに説明してきたポートフォワードの場合、 リクエストヘッダ (のようなもの) は stone が挿入した、 いわばダミーのリクエストヘッダでした。 ダミーですから、リクエストヘッダ (のようなもの) は ポートフォワード先に送信する必要がなかったのですが、 ブラウザを使う場合は、リクエストヘッダはホンモノです。 リクエストヘッダも込みでポートフォワード先の WWW サーバに送る必要があります。

VPN-Warp 入門編 (3)で 説明した relayagent の設定では、 「-n」オプション (relayagent をポートフォワーダとして使う、という意味) を 指定したことを覚えていますでしょうか? 実は、この「-n」オプションというのが、 relayagent にリクエストヘッダ (のようなもの) を取り除くことを指示する オプションなのです。 だから「-n」オプションを指定しなければ、 リクエストヘッダも含めてポートフォワード先 (つまり WWW サーバ) に送られます。

例えば relayagent の設定ファイルは次のような感じになります:

-k private.pem
-c cert.pem
relay.klab.org:443
intra:80

intra:80 がポートフォワード先の WWW サーバですね。 このような設定で relayagent を実行しておくことにより、 ブラウザが https://relay.klab.org/ へアクセスすると、 リクエストヘッダ込みで intra:80 へアクセスが行なわれます。

これで問題なくブラウザで intra:80 へアクセスできる...
場合もあるとは思いますが、 二点ほど注意すべき点があります。

  1. 「https」と「http」の違い
  2. ホスト名の違い

少々ややこしい問題ですので、次回まわしにしましょう。

Filed under: システム構築・運用 — hiroaki_sengoku @ 08:11
2006年4月25日

負け組の塔 vs 勝ち組の塔

一月の事件以来、すっかり影をひそめた 「勝ち組の塔」というキーワード。
六本木を遠くから眺めると、二本の塔が聳え立っている。

一方を「勝ち組の塔」
他方を「負け組の塔」

と呼んでみるのはどうだろうか。

Filed under: その他 — hiroaki_sengoku @ 11:59
2006年4月25日

面接FAQ: 何か質問はありませんか?

弊社の面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法の二回目。

面接を受けに来て、なにも質問しようとしない人がいます。 面接を受けに来た人(応募者)にとっては、 初めての会社であるわけで、 その会社については知らないことだらけなはずです。 それなのに一度も応募者の側から質問しようとしない場合は、 面接を終了する前に、 「何か質問はありませんか?」という質問をすることになります。 それでも何も質問してもらえないのは、 応募者の関心度の順に

  1. その会社に興味がない
  2. 興味はあるのだけど、当座知りたいことは分かったので満足
  3. 知りたいことはまだあるのだけど、質問できない

という理由が考えられるでしょう。 (1) は、面接官が応募者に対して会社の魅力を充分に説明できなかった、 ということなので、反省すべきは応募者ではなくて面接官(つまり私)のほうですね。 なので、ここでは (2) と (3) についてのみ考えます。

まず (2) ですが、面接はせいぜい 1時間、長くても 2時間程度なわけで、 そんな短い時間でどれだけのことが分かるというのでしょう?

蛇足ですが、私がケイ・ラボラトリー (KLab の旧社名) の立ち上げに 参加するときに受けた面接 (つまり私が応募者の立場だった最後の面接) は、 話が盛り上がって話し込み、気付いたときには 6 時間が経過していました。 ここまで長いと、非常識かも知れませんね。(^^;)

分かっていないのに分かったつもりになってしまう、 これは技術者にとって致命的なことです。 どこまでも自分が分かっていないことを自覚し、 探求し続ける習慣が無ければ、スキルアップは覚束ないでしょう。

したがって面接官としては、この応募者には「伸びしろ」がもうあまりない、 つまり現状のスキル以上のものは期待しにくいと判断せざるを得ません。 現在のスキルのままで活躍して頂けると判断する場合は採用しますし、 そうでない場合は不採用となります。

一方 (3) は、技術者としては可能性があるが、コミュニケーション能力が低い、 という場合です。 もちろんコミュニケーションというのは双方向のものなので、 質問しにくい雰囲気にしてしまった 面接官の側に非がある可能性も否めないのですが、 質問しやすい環境でないと質問できないというのも困りものです。

とはいえ、技術と違ってコミュニケーション力は歳をとってからでも習得できます。 コミュニケーション能力が皆無でも、技術者としての素質があるかたには 是非入社して頂きたいですし、 実際面接時にコミュニケーション能力がゼロだった人 (面接の時、ほとんど話すことができなかった) が 入社後大活躍している例もあります。 もちろん仕事を円滑に進めるにはコミュニケーション力が高い方が いいに決まってますので、 例えば

質問力―話し上手はここがちがう
齋藤 孝 (著)
筑摩書房 ; ISBN: 4480816267 ; (2003/03)

などを読んで「質問する力」を伸ばしていって欲しいと思っています。

Filed under: 技術者の成長 — hiroaki_sengoku @ 08:30
2006年4月24日

ブログの縁

二日前にトラックバックを打った縁で、 やねうらお様とお会いしました。
ご足労頂きありがとうございました。> やねうらお様

同席した弊社社員は、

唐突な来社だったので、 本にサインしてもらう準備できてませんでした...orz

と嘆いております。(^^;)

この GCD日記は始めてからまだ一ヶ月ほどしかたっていませんが、 ブログの縁というのもあるんですね~。

Filed under: その他 — hiroaki_sengoku @ 19:56
2006年4月23日

自分を変えよう

他人の考え方を変えさせるのは難しい。 人は誰しも自分の考えたいように考えるわけで、 正論を述べたって相手を説得できるとは限らない。 たった一人の考え方を変えさせるのさえ困難なのだから、 まして組織の方向性を変えるなんて至難の業。

だから、組織を変えようとするのではなく、 他人を変えようとするのではなく、 まず自分を変えよう。 どんなに非の打ち所が無い人でも 反省すべき点の一つや二つあるわけで、 ふつうの人ならいくらでも反省すべき点はあるだろう。

まして周囲に不満を持っている人なら その分、反省すべき点も多いはず。 まさに人のふり見て我がふり直せ。 自分の都合のよいように、自分の考えたいように、 考えていないか省みよう。

他人の考え方を変えさせるのはそれからでも遅くない。 そもそも考え方を変えて欲しいと思うのは何のため?

Filed under: 自己啓発 — hiroaki_sengoku @ 20:30
2006年4月23日

実力主義・能力主義 hatena_b

創業から 6年、KLab は大きく発展しました。5人で始めた会社がもうすぐ200人に達する勢いです。 昨年 9月には 子会社 KLabセキュリティを設立し、 セキュリティ分野への本格進出を開始しました。 でも私にとって会社の発展以上に重要なのは、 KLabグループの発展にあわせて 私自身も大きく変わることができたということであり、 また一緒に働く技術者たちも大きく成長したという点です。

もちろん、技術者が成長すればそれだけでいい、 というほど会社は単純なものではありませんが、 会社というものは、役員が3人いたら3人、5人いたら5人が皆違うタイプで、 それぞれの立場から会社のあるべき姿を提案し、 それらをミックスして一番いい会社を創るべきだと思います。 私は技術者だから技術者サイドから会社のあるべき姿をいつも考えています。

私は KLabグループを、これからももっと 「技術者の成長にとって一番役に立つ会社」 「技術者が自ら伸びていくことができる会社」にしたいと思っています。 そして、技術者達が KLabグループを踏み台にして次のステップに進むのもいいし、 KLabグループに残って、KLabグループの将来に貢献してくれてもいい。

そこに一番重きをおきたい。

その為にこだわっていることを3つご紹介します。

面白いことは許可します

「コスト的にどうかな?」と思うことでも、 新しいことであれば積極的にやっていきたいと考えています。 「トップの理解がない」「上司の説得が大変」という技術者の話をよく耳にしますが、 KLabグループでは そんなことはありえません。それは、私が上司だからです。 実際に言い出しっぺは私自身が一番多くて、 メンバーから「こんな無茶しないで下さい」と言われますが・・・。 上司を止めることはあっても、止められることはない。 技術者にとって、積極的にやりたいことがやれる、 挑戦できる環境です。

さらに、現在の業務とは直接関係ないことにもどんどん挑戦してもらうため、 勤務時間の10%以内であれば上司の許可を得ずに何をやってもいいという 「どぶろく制度」を作りました。 ある程度メドがつくまでは「こっそり」技術を仕込んでもらって、 もしうまくいったら発表してもらってみんなで事業化を考える。 モノにならなかったとしても構わない、 失敗を恐れず挑戦する意欲を大切にしたいと思います。

いかに高負荷に耐えうるサーバを作ることができるか、 いかに経済的に運用することができるか、 というクラスタリングサーバの研究開発は、 今でこそ KLab の事業の柱の一つとなっていますが、 最初はケータイJavaアプリを作る合間に「こっそり」仕込んだ技術だったのです。 業務とは直接関係ないことだったが好きだからとやってるうちに、 いつのまにか KLab のコアコンピタンスになってしまったわけで、 「どぶろく」精神の典型例と言えるでしょう。

また、セキュリティ分野への進出も、 最初のきっかけは趣味で作ったプログラムでした。 このあたりの経緯は、 「なぜケータイ・コンテンツ開発から、セキュリティへ転身したのか?」に書いています。

── KLab 本体はケータイ・コンテンツの開発会社です。なぜそこから、セキュリティ分野に転身したのでしょうか?

これは誤解されやすい所ですが、私は元々セキュリティ好きなのです。 ケータイ・コンテンツの開発に関わった方が、たまたまです。

── 「元々はセキュリティ好き」とのことですが、セキュリティというと制限、規則、監査など不自由なイメージがあります。 これが好き嫌いの対象となるのが今一つイメージが湧きにくいのですが…。

私の場合は「セキュリティを切り口にしてコンピュータを理解して楽しんでいた」、 もっと平たく言うと「OS をいじめて遊んでいた」というパターンです。
初めて UNIX に接したのは 87 年頃、まだ京大の学生だった頃でした。 その頃の UNIX はセキュリティ意識も高くなく、今と違って、つっこみどころが満載でした。 そういうつっこみどころを思考実験で探してみたり、実際につついてみたりして、 OS やネットワークについての実践的な知識を得ていました。
「KLabセキュリティ CTO、仙石浩明に聞く」 から引用

今までの事業領域は無視してもらってもかまいません。 IT 以外は微妙ですが、「技術」という名がつけば何でも OK です。 「そこはお前のやることじゃない」と言われることはありません。 私が CTO である以上、 やる気があるなら次々に新しい研究開発ができます。 そして、そこで積み重ねた技術力次第で CTO も目指せます。 それが KLab という会社なのです。

技術者の上司は技術者であるべきです

これは私のこだわりで、ずっと言い続けていることです。 技術者が「技術だけでどこまでも上っていける会社」 「自分のキャリアパスを明確に描ける会社」それが理想。 出世すると技術がなくなったり、上司がいつの間にか技術者でなくなると、 「いずれは技術を捨てなければならない」と思ってしまう。それはありえない。

事業分野の広がりにともない現在は事業部制をしいていますが、 本当に技術が好き、という人のためには、 研究部門である Kラボラトリー (旧社名を引き継いでいます) があり、 私が直轄しています。 また、KLabセキュリティは今のところセキュリティ分野に特化しているので 機能組織となっており、技術部門は私が統括しています。

さらに、上司が単に技術者であるというだけでなく、 上司が部下を技術者としての実力で評価できるということを重視しています。 これは、「彼は、このあたりの分野が優れている」などという概要評価ではなく、 例えばソースコードまで見て、優れている点を具体的に評価でき、 さらに改善ポイントもアドバイスできるということです。

一般の会社では、過去の功労者が上にいる企業が多いようですが、 でも彼らは、過去の技術に関しては優れていても、 必ずしも今の技術に関して精通しているとは言えません。 KLabグループの場合は、 これからの技術で部下を引っ張っていける人でないと上司にはしません。 上司でも、新しい考え方や新しいパラダイムに適応できない人は、 だんだん退いてもらうことになります。

世の中的には、上流工程を重要な仕事、 下流工程を単純労働と捉える見方があります。 下流は新人がやる仕事と見なされ、 プログラミングをほとんど経験していない人がプログラマーの上司だったりする。 これではマトモな評価ができるはずはありません。 下流には下流なりの難しさがあり、 下流の得意な人たちも、上流と同様に評価されるべきです。 KLabグループには、上流が得意な上長と下流が得意な上長の両方がいますので、 下流だから上流より地位が下、ということは全くありません。

KLabグループは真の実力主義・能力主義の会社です

成果主義じゃなくて実力主義・能力主義。 どれだけ能力を持っているか、ポテンシャルも含めたところで評価します。 そして能力がある人はドンドン抜擢。能力が開花した時点で、 いきなり倍の給与にしてもいい。 後から来た人が上司を追い抜くのは日常茶飯事です。

多くの会社は成果主義に走りがちです。 それは上司が技術をわかっておらず、技術者をきちんと評価出来ないからです。 部下のやっていることが技術的にどこまで凄いのかを、 評価できないから数字で出るものを信じるしかなく、 「より利益(率)の高いものをやったか?」 ということがメインの指標になってしまいます。 技術というより「いかにコストダウンするか?」 「いかに外注をいじめて安く作るか」 が注力ポイントになってしまい、 技術以外の方向にベクトルが向いてしまう。 そんな会社にはなりたくないし、したくない。

直接成果に結びつかないかもしれないが、新しい知識を貪欲に吸収し、 新しいことをドンドン考え、 自分の考えていることを積極的に発表して皆の役に立つ。 それを重視したいと考えています。 研究開発は会社の中ではコストセンター。 どのみちコストなんだから、お金で換算したくない。 その人の能力・実力で評価したい。 だからトップに技術者がいなければならないし、 技術者の立場から、他の役員と闘うことこそが CTO (最高技術責任者) の役割だと思っています。

KLab株式会社
取締役 CTO
Kラボラトリー 所長
仙石浩明

KLabセキュリティ株式会社
取締役 CTO
技術本部 本部長
仙石浩明
Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 08:33
2006年4月22日

開発環境とプログラミング能力

開発環境の進化が、 プログラマのプログラミング能力を退化させていると思う。 私は、いわゆる統合開発環境というものを使ったことがなく、 いつでも emacs を愛用している。 しかも画面サイズは 20年来 80桁x24行のままである。

プログラミングは、メモを書きながら設計したあと、一気に書く。 設計さえきちんとできていれば、途中で手が止まることはあまりない。 食事も忘れて何時間も没頭することがよくある。 そして書き終えてたらコンパイル。 タイプミスとか変数宣言し忘れとかで出たコンパイルエラーを ひとつずつ修正。

で、コンパイルに成功したら実行させる。多くの場合、これで動く。 一通り動作確認して、期待しない動作をするところがあっても、 ほとんどの場合ソースを参照するまでもなく原因に思い当たる。 たいていの場合、デバッガを使うまでもなく、 ソースを見直すだけでどう修正すべきかも分かる。

という話をすると、奇異な目で見られてしまう。(^^;)
目視だけでデバッグと題するページで、 私と同じような感覚の人を見つけて安心した。

たいていの人は、デバッガでステップ実行させて、 実行中の変数を参照したり、 値を変えてみたりしてプログラムを修正するのだという。 たしかに頭の中でプログラムの動作を追うより、 デバッガを使って実際に動かしてみるほうが楽かもしれないが、 それでプログラミングスキルが伸びるのだろうか?

まるで、将棋を指すとき対戦用の盤面とは別に、 相手の指し手の可能性を検討する盤面を脇に置いて、 次の一手を検討しているようなものではないか。 そんなことをしていたら、 次の一手を考えるのに膨大な時間がかかってしまうし、 頭が鍛えられないので上達も難しいだろう。

プログラミングも同じ事。 頭の中に仮想的にデバッガを構築して、 無意識の思考でプログラムを実行させることができなければ、 いつになってもプログラムを見通す洞察力は身につかないだろう。

Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 11:24
2006年4月22日

評価面談

この時期、KLab と KLabセキュリティは 上半期 (9月~2月) の評価面談の季節です。 私は KLab の研究部門である Kラボラトリー (旧社名をとって名付けました) と、 KLabセキュリティの技術本部を担当しています。 昨日は、私の直接の部下の中で一番若い H さんの面談を行ないました。

H さんは昨年の新卒入社なので、まだまだ学ぶべきことはたくさんあるわけですが、 人一倍技術が好きなので、私としても大変期待しています。 いまは、いろんなこと (気配りとか、会社の業績とか) を気にするより、 好きなことを自由に学び、伸び伸びと育って欲しい、と思っています。

彼に話したのはこんなことです:

一点注意してほしい点をあげるとすれば、 様々な技術に関心を持つ際に、強弱のメリハリをつけることを意識する、 という点です。 WWWで公開される情報がどんどん充実していく昨今、 どのような技術でもかなり奥深いところまで WWW で手軽に入手できるように なっています。 このこと自体は素晴らしいことなのですが、 入手が手軽に可能ということが、 分かったつもりに陥るリスクを増やしているわけで、 この罠に陥らないよう注意してください。

特に関心を持った分野、たとえばベイズ理論やオートマトン理論などは、 通りいっぺんの理解にとどまらず、とことんまで勉強してやる、 くらいの意気込みで挑戦してほしいと思っています。

WWW の普及によって、広く浅く学ぶことは格段に容易になりました。 広い視野を持つことはとても大切なことなのですが、 各分野それぞれについて自身がどのくらいのレベルまで学べたか把握していないと、 ほんの表層をかすっただけで満足してしまいかねません。

だから、どんな分野でも、どんなに狭いピンポイントでもいいから 深く深く学ぶ経験が重要だと思うのです。 深く学べば学ぶほど、その深さが基準となって、 その他の分野への理解がどのレベルまで到達したか、 より正確に把握できるものでしょう。

浅くしか学んだことがなければ、その浅さがその人の限界になります。 なにを学んだとしても、自身がどのレベルまで理解できているのか、 自身が理解できていない深淵がどれだけ深いものなのか、 永遠に知ることはないでしょう。

だから、特に若いうちは、とことんまで学んでみて欲しいのです。 H さんには短期的な目標設定として、 古典的な教科書一冊を完全理解することを勧めました:

なにかひとつでいいので、半期かけてとことん学んでみてください。 ひとつの分野をどこまでも深掘りする、ということを一度でも経験した人は、 興味の対象がいろいろ移り変わっても、 分かったつもり状態に陥りにくいものです。 WWW上での学習だと、深堀する以前に興味が発散してしまうリスクがあるので、 評価が確立した古典的な教科書を一冊、完全理解に達するまで読み込む、 といった勉強方法のほうがいいかもしれません。

どんな分野の教科書でもいいと思いますが、 一例として私が学生時代に学んだ「古典的な教科書」を紹介しました:

Switching and Finite Automata Theory
Zvi Kohavi
McGraw-Hill Education ; ISBN: 0070993874 ; (1979/03/01)

27年前の本です! 秒進分歩ともいわれる技術革新のスピードの中で、 1/4世紀以上昔の本が今でも通用するのですから、愉快じゃありませんか。

- o -

追記:
やめるまではがんばりまっせ」から引用:

なんでかというと、結局わしは、会社のためとか、自分の給料を上げるためだけに仕事しているつもりはないからなのです。自分の実力のために、今吸収できるべきことは全て吸収し、機が熟したら、どこにでも飛び出せるようにしておこう、と思っているからです。だから、今は評価がなかろうがなんだろうが、とにかくやるべきことをバシバシこなさなきゃイカンと思っているのです。

その通りですね。 若いときは若いときしかできないことをすべきだと思うのです。 会社がどうなろうと、 スキルさえ身につければ技術者は勝ち残れるのですから。

Filed under: 技術者の成長 — hiroaki_sengoku @ 10:35
2006年4月21日

同時に考えよう (4)

パケットの気持ちになって考える

むろん、パケット(といっても小包のことではなくて、IP パケットとかのことである) に 気持ちがあるわけではないが、 パケットからみたネットワークを無意識の思考で考えてみる、 という意味。

パケットの振る舞いを、意識した思考で考えていては、 あらゆる状況下での振る舞いを考えようとすると時間がかかりすぎる。 頭の中にネットワークのエミュレータを構築し、 無意識の思考でパケットをやりとりしてみればどうだろうか。

プログラムの気持ちになって考える

プログラムの視点、 ないしプログラムを実行する CPU の視点を、 無意識の思考で考えてみる。 プログラムを一ステップずつ意識した思考で追っていては、 いつになってもバグの原因に思い当たらないが、 頭の中にプログラムを思い描き、 無意識の思考で実行してみればバグの原因が「ひらめく」かもしれない。

将棋の駒の気持ちになって考える

寺尾創さまのコメントにある、 「直感で何通りか次々に解候補が無意識に浮かんでくる」というのは、 頭の中に将棋盤と駒があって、 無意識の思考で超高速に駒を動かしてあらゆる指し手を探索している、 ということなのか。 これが意識した思考だと、 あらゆる指し手を探索するには非現実的な時間がかかってしまうだろう。

Filed under: 自己啓発 — hiroaki_sengoku @ 18:37
2006年4月21日

VPN-Warp 入門編 (4)

前回は、VPN-Warp をポートフォワーダとして使う場合の、 基本的な設定方法について説明しました。 ローカルホストの 8080番ポートを、 リモートの intra:10080 へフォワードする場合に、 ローカルホストで stone を走らせる方法について説明したわけですが、 stone はもともと VPN-Warp 専用のソフトウェアというわけでは決してなく、 stone は汎用リピータです。

つまり stone を使わなくても、 https リクエストをリレーサーバに送信することができるソフトウェアなら なんでも使うことができます。

試しに OpenSSL 付属の s_client コマンドを使ってみましょう:

% s_client -cert relay,10020-cert.pem -key relay,10020-priv.pem -connect relay.klab.org:443
CONNECTED(00000003)
        ...
subject=/C=JP/postalCode=106-6122/ST=Tokyo/L=Minato-ku/streetAddress=6-10-1 Roppongi/streetAddress=Roppongi-Hills Mori-Tower 22F/O=K Laboratory Co.,Ltd/OU=HTTP/OU=InstantSSL/CN=relay.klab.org
        ...
---
GET / HTTP/1.1

HTTP/1.1 200 OK

:irc.klab.org NOTICE AUTH :*** Looking up your hostname...
:irc.klab.org NOTICE AUTH :*** Found your hostname

最初の行の s_client コマンドの実行と、 後ろの方の「GET / HTTP/1.1」および続く改行二回が手で入力した部分で、 あとは s_client コマンドの実行結果です。 クライアント認証を行なうため、s_client の引数に証明書の

公開鍵 (-cert オプション)
relay,10020-cert.pem
秘密鍵 (-key オプション)
relay,10020-priv.pem

を指定しています。s_client は SSL 接続した後、サーバ証明書の内容などが、 どばっと出力されますが、その後「---」を表示してセッションが確立します。

そして、リクエストヘッダ (のようなもの)

GET / HTTP/1.1
(空行)

を送ると、レスポンスヘッダ (のようなもの)

HTTP/1.1 200 OK
(空行)

が送られてきて、ポートフォワード先とのセッションが確立します。 この例の場合では、確立した直後にデータが送られてきていますね:

:irc.klab.org NOTICE AUTH :*** Looking up your hostname...
:irc.klab.org NOTICE AUTH :*** Found your hostname

これは、KLab 社内の IRC サーバから送られてきたデータです。 KLab では技術的な打ち合わせは IRC で済ませてしまうことも多く、 隣の席にいる人との打ち合わせでさえ、IRC で行なうケースがあります。 IRC で話しておけば文字で残りますし、 リモートにいる人も議論に参加できるので、とても便利です。

KLab 社内 IRC はあまりに常用されているので、 いつでもどこでも IRC に参加しておきたいわけで、 そういうとき VPN-Warp はとても便利です。 つまり、stone をノートPC 上で NT サービスとして走らせておくだけで、 ノートPC がインターネットにつながってさえいれば、 ダイアルアップでつながっていようと無線LAN でつながっていようと関係なく、 6667番ポートを常に社内IRC サーバへポートフォワードすることができて、 ノートPC 上の IRC クライアントで localhost:6667 へ接続して 常にチャット状態にしておける、というわけです。

Filed under: システム構築・運用 — hiroaki_sengoku @ 12:56
2006年4月20日

同時に考えよう (3)

相手の気持ちになって考える

相手のバックグランドを知る。 どういう生い立ちか、どういう環境で育ったか、何を学んだか。 バックグラウンドが分かれば、 物事をどうとらえ、どう考えるかが見えてくる。 あたかも自分の頭の中に、 相手の人格のエミュレータが動いているかのように。

意識した思考で、 相手の考えを一ステップづつシミュレートしていては遅すぎる。 あくまで相手の気持ちになりきることが重要。 無意識の思考で、相手の人格のエミュレーションができるようになれば、 無意識における相手の思考と、 意識した自分の思考をインタラクションさせることができるようになる。

無意識における相手の思考と、 現実の相手の思考との差をフィードバックさせて、 エミュレーションの精度を高めることができる。

Filed under: 自己啓発 — hiroaki_sengoku @ 15:20
2006年4月20日

面接FAQ: 高い技術力って例えばどんなことですか?

2000年に (株)ケイ・ラボラトリー (KLab の当時の社名) を創業してから 6 年、 当然ながら数限りなく採用面接を行ないました。 最近でこそ私の面接なしで採用された人達も増えてきたのですが、 一時は技術部門のほぼ全員が私の面接を経て入社した という人達だった時期もあります。

最終の役員面接というと、多くの人が通りいっぺんの面接だと思うらしく、 役員面接で技術的な突っ込みを受けて、応募者が戸惑うケースが多々ありました。 私としては、応募者に合わせてその都度、どういう面接方法が適しているか考えて、 質問する内容を変えてはいるのですが、 そうはいっても 100人以上も面接すればある程度パターンのようなものもでてきます。

比較的頻度が高い質問パターンを紹介し、 どう答えることができていたら採用になっていたか、 振り返ってみようと思います。 名付けて「面接FAQ」、面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法。

- o -

KLab にあまり興味を持っていなかったけど (転職斡旋エージェントに勧められて) とりあえず面接を受けに来ました、 という応募者に、 なんとか KLab の魅力を伝えて、入社しようという気にさせるのが 面接官の腕の見せどころだと思うのですが、 それでもやっぱり面接での話の成り行き上、 志望動機について質問することはよくあります。

すると、「KLab の高い技術力が魅力的」、とか 「そういう高い技術を学び、身につけたい」、とかおっしゃるかたが 少なからずいます。 そういうことを言われてしまうと、 私はつい (^^;)、 「高い技術力って例えばどんなことですか?」と 聞いてしまうのです。 意地悪な質問ですね (_O_)。

多くの方は、そういう質問が返ってくるとは全く予期していなかったらしく、 ここで言葉に詰まってしまいます。 志望動機が「技術を学びたい」なのに、 肝心のその技術がどういうものかイメージできていないのです。 言い換えれば自分が何をしたいのか実は分かっていない、 これはかなり問題ですよね?

技術ってなんだろう…」 ふとそんなことを考えたことが一度でもあるような人ならば、 「技術を学びたい」なんて抽象的な言い方ではなく、 もっと具体的なことが言えると思うのです。 そして自分が何をしたいか、きちんとイメージできている人は、 KLab に入社したあと、ほぼ例外無く大活躍しています。

Filed under: 技術と経営 — hiroaki_sengoku @ 07:43
2006年4月19日

情報処理のキホン (2)

KLab の開発に参加いただいている協力会社の A 社の S 社長が、 tech ML に投げた問いかけに対し、 同じく協力会社の H 社の役員である K さんが応えました。

# KLab 社内の ML なのに、KLab 社員以外で話が盛り上がる
# こともあるのが、tech ML の大きな特長です (^^;)。

~~ Kさんのメール(一部抜粋)ここから ~~

> #どなたが「専門教育」を受けられた方なのかわかりませんが^^;
> ##ぜひ土日で古い教科書などを掘り出していただきたく:-)

今でもコンピュータでの処理(方法の)限界に関してはとても興味があり

オートマトンと計算可能性 情報処理シリーズ
有川 節夫 (著), 宮野 悟 (著)

あたりはおもしろいかなと。私は特に後半の計算可能性が好きです。

~~ Kさんのメール(一部抜粋)ここまで ~~

で、私も話に加わってみました:

~~ 私のメールここから ~~

仙石です。おお、ついに tech ML で計算可能性の話題が...

K さん曰く:

> 「オートマトンと計算可能性」

このあたりの、一通り学べる本を読んでみると、 大学の専門課程で何をやってるのか知る事は、できそうですね。

# でも、知る事と理解する事は全く別物 ;-)

> あたりはおもしろいかなと。私は特に後半の計算可能性が好きです。

本当に重要なのは、この「おもしろい」という感覚かもしれませんねぇ...
計算可能性に関する「おもしろい」本としては、

決定不能の論理パズル―ゲーデルの定理と様相論理
レイモンド スマリヤン (著), 長尾 確 (翻訳), 田中 朋之 (翻訳)

あたりがおすすめ。いきなりこの本を読むと挫折するかも知れない ;) ので、
入門用としてはホフスタッターの不朽の名作:

ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版
ダグラス・R. ホフスタッター (著), Douglas R. Hofstadter (原著),
野崎 昭弘 (翻訳), 柳瀬 尚紀 (翻訳), はやし はじめ (翻訳)

があまりにも有名ですね。

# 20周年記念版が出たのか~
# ということはつまり、私が初めてこの本を読んでから 20年たった、という
# ことなのですね。う~ん歳をとったものだ...

Filed under: 技術と経営 — hiroaki_sengoku @ 19:27
2006年4月19日

PPPoE を横取りするには?

GCD LAN内で Real Player コンテンツを再生しようとしたら、 GCDゲートウェイで、外向きポート554番をブロックしていたので、 とりあえず特定の接続先だけ解除する。

これでコンテンツを見られると、思って再生ボタンを押すと、 いきなりゲートウェイがネットワークから見えなくなった。 NICごと死んだのか、IP, IPv6 ともに反応なし。 二つあるNICの両方が無反応なので、 原因はドライバより上のレベルにありそう。 あいにくゲートウェイにはディスプレイカードを入れていないので、 シリアル(RS-232C)経由でログインしてみると、 iptables のログが延々と出力されている。 大半が、root ネームサーバのポート53番から。 つまり DNS 問い合わせに対する応答パケット。 ということは、PPPoE が生きている。これはマズイ。

機能しなくなったゲートウェイが PPPoE をつかんだままでは、 MASTER に昇格したもう片方のゲートウェイが PPPoE できない。 正確に言えば、PPPoE 自体はできるのだがプロバイダがどちらの ゲートウェイへパケットを送ってくれるかは運次第。 事実、ほとんどのパケットは機能しなくなったゲートウェイ側に 届いたので、GCD からインターネットへの通信が事実上不可能になった。

冗長構成を組むとき最も難しいのが、いかにして中途半端な死に方を 回避するかだが、死んだゲートウェイに PPPoE を止めさせるのも、 なかなか難しそうだ。

  1. PPPoE している機能不全状態のゲートウェイには頼らず、
  2. PPPoE 先のプロバイダ側には手が出せない、

と仮定すると、どうすればいいだろうか。 機能不全状態のゲートウェイのNIC を LAN から切り離す仕掛けを 組み込むとかだろうか? (どうやって? ^^;)

Filed under: システム構築・運用 — hiroaki_sengoku @ 09:52
2006年4月18日

ポジティブシンキングでいこう

誰しも言うことで、なにもここで書かなくたって 誰しも百も承知だと思うが、 あまりに重要すぎるのであえて書く。

病は気から、ネガティブに考えれば必ず悪くなる。 悪くなる可能性のあることは必ず悪くなる。 ならば無理やりにでもポジティブに考えよう。 どうしてもポジティブに考えられなかったら、 まずは冷静に考えられるようになるまで考えるのをやめてしまえ。 家に帰って寝てしまえ。

冷静になって考えれば、どんな苦境に立った時だって、 大して不幸なわけじゃない。 どんなに困難な問題にぶちあたったって、 解決策が見つからなくたって、 解決策を見つけようとすれば経験値が上がる。 ポジティブに考えれば、必ずうまくいく。 失敗は成功の母、必ず次につながる。

むしろうまくいっているときほど慎重であれ。 成功は失敗の母、成功体験にとらわれれば、 いつか必ず失敗する。 勝って兜の緒を締めよ、落とし穴はいたるところにある。

Filed under: 自己啓発 — hiroaki_sengoku @ 19:02
« Newer PostsOlder Posts »