仙石浩明CTO の日記

先週参加した社外の飲み会 (私は飲めないので専らウーロン茶でしたが) で、 Linux ディストリビューションの開発や、 カーネル技術を売りにしたコンサルティングで有名な某社の カーネル技術者とお会いしました。 彼はいま伸び盛りの若手カーネル・ハッカーなのですが、 オープン・ソース・ソフトウェア (以下 OSS と略記) ビジネスについて熱く語ったり、 ディストリビューションをサポートし続ける使命感に燃えていたのが、 わたし的にはちょっと気になりまして、 ひとこと言いたくなってしまいました(お節介ですね ^^;)。

ディストリビューションのサポート体制 (カーネルのバグにも的確に即応できる体制) を維持し続けることによって、 多くの企業で Linux を安心して使ってもらうことができて、 それが OSS の発展につながるし、 それこそが自分の使命だと彼は考えているようでした。 それはそれで意義あることだとは思うのですが、 彼のような優秀な技術者には、 「サポート」という目的だけに捕らわれず、 もっと自由に興味の赴くまま学び、 自らのスキルを伸ばしていって欲しいと思ったのです。

OSS 関連のビジネスというと、 すぐ、 サポートでお金を稼ぐとか、 OSS 活用のコンサルティング事業とかの発想をする人が多いのですが、 誰もが思いつく事業だけに、 ビジネスモデルとしては稚拙な部類と言わざるを得ません。 高い技術力がそのまま売りにつながった前世紀ならいざ知らず、 競争が激化してビジネスモデルの巧拙が事業の成否を大きく左右する昨今、 いまだに何の「ひねり」もない「OSS サポート」に固執するのは、 いかがなものかと思うのです。

技術コンサルティング事業というと聞えはいいのですが、 要は「人月ビジネス」です。 どんなに優秀な技術者 (「ピンからキリまで」 の「ピン」ですね) であっても、 一人月 1000万円払ってくれるお客がいるはずはなく、 素人技術者 (以下「キリ」と略記) の 5〜6倍の人月単価を稼げば御の字というのが実状ではないでしょうか。 だからコンサルティング事業といいつつ、 高額のソフトウェアを売り付けてライセンス料を稼ぐことのほうが、 メインの目的だったりする会社もあるわけです。

ただあいにく OSS の場合は高額のライセス料を請求するのは無理があります。 せいぜい保守料と称してわずかばかりの費用を請求するのが関の山でしょう。 だから OSS のコンサルティングというのはあまりよいビジネスモデルとは言えません。 ものすごい労力とコストをかけてピンをそろえて (お客に高いね〜と言われつつ) 5倍の人月単価を設定するくらいなら、 コストをかけずにキリを大量に集めて格安な人月単価で売りさばく (いわゆる派遣ビジネス) 方が、 経済合理性にかなうというものです。

キリに成長の機会も与えずに 「若いだけが取り柄の労働力」 として派遣して使い捨てにする事業は当然非難されるべきですが、 労働時間では測りしれない価値を持つはずのピンを人月換算してしまう事業もまた、 非難されるべきではないでしょうか？ 人月ビジネスでは売上を増やすには人員を増やさざるを得ず、 売上が拡大しても決して余裕は生まれません。 いやそれどころか、 どんどん仕事を片付けてくれる優秀な技術者にどんどん仕事が集中して、 優秀な技術者ほど疲弊する、 という理不尽なことも起り得ます。

頼りにされるあまり、多くの仕事がその人に任されることになる。 できる人に、仕事が集中するのは、よくある話で、 その人は、回りの期待にこたえようとして、遅くまで残業して、 休日も出社したりする。 この状態が、一過性のものだったら良いんだけど、 慢性的なものになると、肉体も精神もぼろぼろになっていく。

会社から「頼りにされる」危険性 から引用

ピンとキリでは生産性で何十倍〜何百倍 (私は 3桁の差があると日頃から主張していますが) もの差があるのに、 わずか 5〜6倍の売上の差しか出せないのは、 「儲ける仕掛け」が無いからです。 ピンの労働時間を人月換算するのではなく、 ピンの技術なしには実現できないような (つまり競合他社には構築不可能な) 儲ける仕掛けを編み出して売上を増幅し、 それによって生じた余裕でピンの仕事量を思いきって抑えることによってこそ、 その優秀さに報いることができるのだと思います。

そうすれば仕事の負荷が軽くなったピンは、 ピンならではの新しい価値を産み出すことに注力できます。 新しい事業のシーズを産み出す研究開発でもいいですし、 あるいは OSS から恩恵を受けている企業であれば、 ピンの人が (勤務時間中も) OSS コミュニティで活躍することを奨励することによって、 OSS の世界に「恩返し」することもできます。

前世紀は技術力が高ければ儲ける仕掛けを誰でも作ることができた時代でした。 つまり優れたソフトウェアなら結構な値段で売ることができたのです。 マーケティングがしっかりしていれば、 開発費を大幅に上回る売上も達成できました。 典型例はマイクロソフトですね。 ピンが作ったソフトウェアを何億本も売ったわけで、 ピンの労働力が人月単価の何万倍もの価値を生んだことになります。 その後 OSS の発展と普及により、 ソフトウェアを売るだけというビジネスモデルは行き詰まりました。 今ほど新しいビジネスモデルが重要となった時代はないと言えるでしょう。

さらにいうと、 技術者が優秀であればあるほど、 その「シーズ」は一般人の「ニーズ」からかけ離れていく、 という難しさもあります。 例えば、 優れたカーネル・ハッカーの技術を、 真に必要とする人が世の中にどれだけいるのか？という問題です。 技術の素人である大多数の消費者にとっては、 小難しい技術のことなんか全く分からないし興味もありません。 高い技術力が売れるどころか、 逆にその高度さが「需要」を減らしてしまう原因となりかねません。

高度な「シーズ」と一般の「ニーズ」を結び付けるには、 高度なビジネスモデルが求められるわけで、 技術者がハッキングの合間に思いつくようなビジネスモデルではお話になりません。 優れたカーネル・ハッカーが、 四六時中寝る間も惜しんでカーネル・ソースのことばかり考えているのと同様、 優れたビジネスモデルを考え出すビジネスの戦略家 (以下、戦略家と略記) は、 四六時中寝る間も惜しんで儲ける仕掛けのことばかり考えています。 素人考えのビジネスモデルが通用すると思うのは、 C言語を覚えたばかりの素人技術者が、 カーネル・デバッグに挑もうとするくらい無謀なことでしょう。

当たり前のことですが餅は餅屋であり、 技術のことは技術者に任せるべきですし、 儲ける仕掛けのことは戦略家に任せるべきです。 優秀な技術者は、優秀であればあるほど、 優秀な戦略家と組むべきなのです。 ところが世の中の大半の会社はそうなっていません。

超優秀なハッカーは互いに認め合う技術者同士ばかりで集まり、 ビジネスモデルの重要性を軽視してしまいます。 ビジネスモデルなんて自分たちだけでも考え出せると思ってしまい、 社員のほとんどが技術者、なんて会社になってしまいます。 実地に売り歩く営業の必要性にはさすがに気付いて営業担当者を数人雇ったり、 あるいは社長が自ら売り歩いたりするようになるものの、 儲ける仕掛けの構築には無頓着で、 旧態依然としたビジネスモデルのままだったりします。 そのため事業を拡大しても余裕が生まれず、 ちょっとした外部環境の変化でたちまち立ち行かなくなる恐れがあります。

逆に、優れた儲ける仕掛けを生み出すことができる有能な戦略家は、 一日24時間、儲ける仕掛けを考え出すことばかりに夢中で、 その仕掛けを下支えする高度な技術のことは軽視してしまいます。 技術なんて下請けをいじめればなんとでもなると考えてしまい、 決して技術者をパートナーとは考えません。 技術者を、売るものを作ってくれる便利な人と考えてくれればまだマシなほうで、 下手するとコストばかりかかる必要悪くらいの勢いで、 原価削減の手法をあれこれ考え始めたりします。 しかし技術を軽視したツケは、いろいろな形で払うことになるでしょう。 事業を下支えする技術が脆弱であれば事業の継続性が危ぶまれますし、 技術面で他社との差別化が行なえずに他社の参入を許してしまうかも知れません。

これでは技術者と戦略家の利害はどんどん対立してしまいます。 この悪循環をくい止める唯一の方法は、 技術者が ──特に、優秀であればあるほど── ビジネスモデルの良し悪しを嗅ぎ分ける嗅覚を持つことです。 誰が優れた「儲ける仕掛け」を生み出すことができるのか、 技術者が判断できるようになれば、 人月ビジネスから抜け出す見込みのない会社を見限ることが できるようになるでしょう。

対称性を考慮すれば、 戦略家が技術の優劣を嗅ぎ分ける嗅覚を持つことによっても、 利害対立の悪循環をくい止めることが (理論上は) 可能ですが、 高度に専門化・細分化してしまった技術を、 技術者ではない戦略家に (優劣を判断できるほどに) 理解してもらうことは現実的とは思えません。 戦略家と技術者が協力しあうには、 まず技術者の側が相手を理解する必要があるのです。

そうすれば、 より優れた戦略家のもとに優秀な技術者が集まるようになり、 戦略家と技術者の利害が一致する方向へ淘汰圧が働きます。 すなわち、 戦略家が優秀な技術者と組むことにより、 技術者には (従来想像していた以上に) 優劣の差があって、 どのレベルの技術者と組むかが事業の成否を大きく左右する、 ということが明らかになってくるはずです。

優秀な技術者が事業にどれだけ貢献し得るか実感できれば、 優秀な技術者に対して、その能力に見合った待遇 ──報酬はもちろんですが、 仕事量を減らして OSS コミュニティへの貢献を推奨するなど── を提供すれば優秀な技術者が集めやすくなる、 ということも実感できるようになることでしょう。

技術者の側からすると信じられないことだとは思いますが、 ピンもキリもそんなに大した差ではない (せいぜい 5〜6倍) と、 技術者でない人の大半は感じています。 縁遠い技術になればなるほどこの傾向は強まるようで、 例えばカーネル技術者の中でもメンテナとデバイス・ドライバの開発者とでは、 (技術者の目から見れば) だいぶレベルの差がありますが、 (技術者以外の人で) その能力差を実感できる人は皆無でしょう。

技術者の待遇向上の鍵は、 技術者がビジネスモデルの良し悪しにもっと敏感になること、 すなわち会社における技術職以外の職種の役割についてもっと理解し、 技術職以外の人達についても、 その能力の優劣を見分けられるようになることにこそ、 あるのだと思います。

母校の教壇に立ちました。

20年前に学んだ教室 (私が情報工学科で学んだのは 1987年〜1990年) で、 20歳年下の後輩に対して行なった、 私にとって初めての授業体験でした。 勉強会やセミナーで講師をしたり、 学会で発表したりは何度もあるのですが、 授業というのは、 また趣きが異なりますね。 2コマ (約三時間) 自由に話してよい、 ということだったので、 そんなに長時間は話がもたないんじゃないかなぁ、 と少々不安を感じながら臨んだのですが、 幸い多くの質問を頂けて、 気づいたら 30分ほど時間を超過していました。

聞き手の学生さん達は現在 4回生で、 そのほとんどは大学院に進学予定ということだったので、 「学生のうちに身につけて欲しい、たった一つの能力」 というテーマでお話しました。 もちろん、「たった一つ」だけだと 3時間も話を引っ張れないので (^^;)、 私が卒業してから現在までの 16年間の社会人生活で学んだことの中で、 一番重要と思うことを三つ挙げてお話したのですが、 三つもあると覚えてられないでしょうから、 ということで「たった一つ」を強調したのでした。 それは、

質問すること

です。

産業界(特に IT 業界) が大学教育に求めること、 というと「コミュニケーション能力」なんかが 筆頭に挙がってしまうことも多い今日このごろですが、 「みんなと仲良くできる」だけでいいのは小学生までで、 社会で活躍していく上で本当に必要な能力といえば、 間違いなく「考える力」でしょう。

で、どうやって考える力を伸ばしていくかですが、 教科書を読んだり問題集を解くだけで身につくわけもなく、 いろんな人の考えを見聞きしながら自分なりに考えてみて、 次第に考える力が身についていくものだと思います。 だから、 出会った人それぞれから、 どれだけその人の「考え方」を吸収できるかが、 一生の間にどれだけ考える力を身につけられるかを左右することになるでしょう。

もちろん、より多くの人に出会うように努めれば、 より多くの人の考え方を参考にできるわけで、 だからこそ「コミュニケーション能力」が重要と主張する人もいるのでしょうが、 スゴイ人に出会えても、 その人から学べなければ折角の機会も生かせません。 優れた人からどれだけ多くのものを引き出せるか、 すなわち臆せずどんどん質問できるかこそが、 考える力を伸ばす最大の原動力になるのだと思います (もちろん質問する能力も一種のコミュニケーション能力ですが、 「コミュニケーション能力が重要」と言ってしまうと範囲が広すぎて、 焦点がぼやけてしまいます)。

例えば、講演会等で、質疑応答の時間になった時、誰も質問しなくって、 大きな会場が静まり返る、という状況はよくありますよね？ その静寂を打ち破って質問できるでしょうか？ ほとんどの人は、たとえ質問したいことがあっても、 なかなか声を出せないんじゃないでしょうか？
私が個人的に尊敬している人って、 ほとんど例外なくそういう場でも臆することなく質問できる人なんですよね。 「分からない」と言える勇気を持つことと、スキルアップできること、 との間には強い相関があるように思えてなりません。

分からない時は、『分からない』と言おう (2)

というわけで、 今日の私との「出会い」を最大限生かすべく、 講演を途中で遮っても構わないので、 (空気を読まずに) 遠慮無く質問してください、 と話してから本題へ移りました。 まあ、私との出会いが 大した足しにならなかったとしても、 恥ずかしがらずに質問する練習だけでも 2コマの授業時間を費やす価値は充分にあると思います。 「出会い」は今後もたくさんあるでしょうから。

ちなみに、「重要と思うこと三つ」の残り二つは、

技術者の地位を向上させるには、 技術者以外の視点にも立ってみて、 技術者自身が視野を広げていかなければならない

作ること と 売ること (未踏集会 ESPer2006 秋の陣)

と、

これから社会に出ていく学生さん達が最優先で取組むべきことは、 会社と対等に渡り合える実力を身につけるために、 いま何をすべきか考えることでしょう。 そんな実力を身につけることは自分には永遠にムリと思う人がいるかもしれませんが、 ムリと思えば思うほど実現は遠退きます。

技術者の成長に役立つ会社とは？(1)

です。

授業で使ったスライドを PDF 化したもの と、
FlashPaper で Flash 化したもの ↓ を公開します。

私自身は、 KLab 社内の技術者たちと、 いつまでも技術者同士の関係でいたいと思っているのですが、 技術者の人数が増えてくると、 仕事上の接点がほとんどない人もでてきます。 そして社員の側からすると、 私は (いちおー ;-) 取締役なので、 おいそれとは話せない恐い人などと根拠無く思い込んでるケースも、 残念ながら皆無というわけではありません。

それではいけないということで、 日頃あまり接点のない人たちを中心に、 無理矢理 (^^;) ランチに誘って話する、ということをしています。 先日も隣の部署の N さんと二人でランチへ行きました。 彼とは入社直後の社員旅行で少し話をしただけで、 その後は話す機会がほとんどなかったのです。

それまで私は知らなかったのですが、 実は彼は高専時代にず抜けた存在で、全校で表彰されたこともあったそうです。 プログラミングが大好きで、いろんなものを作っては、 学校内でアピールし注目を集めていたとか。 しかしながら KLab 社内ではどちらかといえば目立たない存在だった (目立たなかったので私も話す機会がありませんでした) ので、 高専での活躍ぶりとのギャップを感じざるを得ませんでした。

そこで、 何がきっかけで自身の成果をアピールするのを止めてしまったのか尋ねました。 すると、

新卒で就職した会社 (≠ KLab) で、 開発ではない部署に配属されてしまった。 何事も挑戦ということでしばらくは配属された部署で頑張ったが、 やっぱりプログラミングを仕事にしたいと思い、 上司に何度も自身の能力をアピールしたところ、 ことごとく却下されてしまった。 それどころかアピールすればするほど周囲の評価も下がるぐらいで、 ついにはアピールするのを止めてしまった。

という答が返ってきました。

確かにそういう人は多いのだろうなぁと思います。 日頃、アピールすることの重要性を説いている私としては残念でなりません。 そもそも誰だって、 他の人より得意なことがあれば、 それを自慢したくなるのがフツーでしょう。 だからアピールする習慣がない人って、 元々アピールするのが嫌いだったというわけではなくて、 何らかのきっかけでアピールするのを止めてしまったのだろうと思います。

きっかけにはいろいろあるでしょうが、 N さんのように、 アピールしても周囲から評価されなかったり、 それどころか怒られたり、 周囲から浮いてしまって仕事が進めにくくなったり、 そういう嫌な経験をすれば、 だんだんとアピールするのが億劫になってしまうのは仕方がないところだと思います。 N さんの話に頷きながら、 ふと一つのフレーズが頭の中に浮かんできました:

自身の能力をアピールすることは技術者として必須だが、
上司にだけアピールするのは最悪！

技術者にとって重要な能力というと、 一つは間違いなく「スキルアップする能力」でしょう。 誰だって最初は初心者です。 プログラミングの勘所が最初から分かっていたなんて人は (たぶん) 皆無で、 初めて書いたプログラムを後に読んでみると、 その稚拙さ加減にあきれてしまう、というのはよくある話です。

最初は誰しも稚拙なプログラムを書いていたのに、 どんどん能力を伸ばす人がいる一方で、 多少は「形」を覚えて「それなりの」プログラムが書けるようになるものの、 本質的には初心者と代わり映えしない人 (偽ベテラン) もいて、 いつのまにか両者の間には生産性で 3桁の差がついていた、 なんてことが起こり得ます。

技術者にとって重要な能力がもう一つあります。 それが「アピールする能力」。 言うまでもなく技術者だけではお金にはなりません。 技術者の能力をお金に換える人 ──例えば技術者が作ったものを他の誰かに売り付ける人──と、 一緒になって初めてお金が稼ぐことができるわけです。 でも、どうやってその「換金してくれる人」を探せばよいのでしょうか？

実は「換金してくれる人」も技術者を探しています。 そりゃ、売るものがなければお金を稼げませんから、 技術者の能力を換金しようと思っている人が技術者を探すのは当たり前ですね。 だからわざわざ技術者の側からアクションを起さなくても、 学校には「求人票」が貼られ、 巷には転職斡旋会社の広告が氾濫しているわけです。 テキトーな会社を選んで面接を受ければ雇ってもらえてお金をもらえます。

とはいえ、受け身の姿勢よりは自ら動いたほうが有利になるのは世の常です。 学校に貼ってある求人票に限定した就職活動や、 あるいは転職エージェントの勧めに従うばかりの転職活動よりは、 自ら主体的に会社探しをしたほうが「高く」換金してもらえる可能性が高まります。

会社に雇ってもらった場合、 配属された部署の上司が「換金してくれる人」になります。 もちろん上司が一人でお金を稼いでくるわけではありませんが、 技術者から見れば、 自身の能力に対して評価し給料を決めてくれるわけですから、 自身の能力を「換金してくれる人」と言ってもいいでしょう (正確に言えば、換金してくれる人たちの集団の窓口的存在ですね)。

ところが、ここに一つ問題があります。 技術者に得手不得手があるのと同様、 「換金してくれる人」にも得手不得手があります。 技術者からすれば、 私はこんなに優れた能力を持っているのに、 どーして換金してくれないんだと思うのと同様、 「換金してくれる人」からすれば、 私はこーいう技術ならお金に換えられるのに、 どーしてそういう技術を持っている人がいないんだと思っていたりします。

「能力を上司が正当に評価してくれない」と不満に思っている場合、 十中八九その上司は、 「求める能力を部下が持っていない」と不満に思っているはずです。 このような状況で、 部下が上司に自身の能力をアピールして事態が改善するでしょうか。 きっと上司はこう思うはずです: 「そんな能力はお金にならない」。

より正確に言えば、 その上司が換金できる分野と、 技術者である部下の得意分野とが一致していないだけなんですが、 部下が自分の得意分野以外のことに興味がないのと同様、 上司は自分が換金できない分野には興味がありません。 そんな上司に執拗にアピールすれば、 事態を改善するどころか悪化させかねません。 技術者がすべきことは、 自身の能力を上司が換金できないのであれば、 他の「換金してくれる人」を探すことです。

ところが、 前述の N さんをはじめ多くの技術者は、 逆のことをやってしまいます。 「換金してくれる人」を探すのではなく、 上司に「換金してくれ」と懇願したり、 あるいはそれが却下されると、 もう世界にはただ一人も換金してくれる人はいないと 探すのをあきらめてしまったりするのです。

冷静に考えれば、 これは全くナンセンスであることが分かりますよね? 一口に IT (情報技術) と言っても、 様々な分野があります。 ある技術者の得意分野を最もうまく換金できる人が、 たまたまその人の上司だった、 なんてことがもし起これば、 それはすごくラッキーなことだと思いますが、 そんな幸運がそうそう起こるはずはありません。

自身の技術を上司が換金してくれなかったとしても、 そんなことは確率からいえば 「よくあること」 なわけで、 決してその技術が 「お金にならない」 ことを意味しません。 自身の技術が上司に評価されないときこそ、 より積極的に、上司以外の人に向かって、 自身の技術をアピールすべきでしょう。

より多くの人にアピールすれば、 それだけ「運命の人」にめぐりあう確率は高まります。 「この分野にかけては誰にも負けない」という得意分野を持っている人は、 より多くの人へ、 部署内だけでなく社内全体へ、 社内だけでなくより広い世界に対して、 どんどんアピールしていって欲しいと思います。 探す範囲を広げていけば、 その能力を換金してくれる人がきっと見つかるはずです。

あすなろ blog の CTO キャリアライフインタビューを受けました。 私は普段、 昔話はできるだけしないように気をつけていた (だって「老害!」って思われちゃいますからね) のですが、 このインタビューでは冒頭いきなり

そもそもコンピュータに興味を持ったきっかけから教えていただけますか

と聞かれてしまい、 封印していた過去が一気に吹き出してしまいました。 なんせ 30年近い昔のことですから、 最近コンピュータを始めた人にとっては 何の興味も持てないんじゃないかとちょっと心配です (インターネット元年であり Windows ブレイクの年でもある 1995年も、 私の感覚だと「つい最近」の出来事だったりします ^^;)。

そして今日は、 「Commodore 64」の生みの親、J・トラミエル氏インタビュー という記事を見つけてしまいました。

Commodore !

Commodore PET 2001 !

Commodore VIC-1001 !

なにもかも懐かしい ! 昔の記憶がどんどんよみがえってきます。

パーソナルコンピュータの歴史に最も大きな影響を与えた人物について語るとき、 人はよく、Steve Jobs氏、Steve Wozniak氏、Bill Gates氏、Paul Allen氏、 Gordon Moore氏、Andy Grove氏などの名前を挙げる。
だが、確実に彼らと同じグループに属する人がもう1人いる。 Commodoreの創業者で、後にAtariの最高経営責任者（CEO）を務めた Jack Tramiel氏だ。 「Commodore PET」や「Commodore VIC-20」、 さらに、パーソナルコンピュータ史上最も販売台数が多いとされる 「Commodore 64」（C64）を世に送り出した人物として、 Tramiel氏は、他の誰よりも強い影響力を持っていたのかもしれない。

「Commodore 64」の生みの親、J・トラミエル氏インタビュー から引用

私に最も大きな影響を与えたのは、 Apple でもなく、MS Basic でもなく、8080 CPU でもなく、 PC-8001 でもなく、Commodore でした。 CTO インタビューでは、 「なぜかはじめからコンピュータが好きだった」と答えたのですが、 中学校での PET 2001 との出会いがなければ今の私は無かったかも知れません。

中学3年生になって、だんだんBasicでゲームを作るほかに、 もっと下のレベルでプログラミングができるということがわかってきて、 機械語と呼ばれていた言語に興味を持つようになりました。

CTO キャリアライフインタビューから引用

インタビューの時は忘れていたのですが、 私が機械語 (マシン語。メモリ上で即実行可能なバイナリのことです) を学ぶきっかけになったのは、 当時コモドールジャパンが発行していた小冊子「VIC!」でした。 この小冊子のコラムに、 機械語の簡単な紹介があって、 EA (16進コード) も機械語の命令の一つ、といったことが書かれていたのでした。 0xEA は 6502 CPU では NOP 命令なのですが、 そのコラムは、 「NOP は何もしない、という命令ですが、 読者の皆さんは何もしないのではなく、 VIC をきっかけにコンピュータを学んでいって欲しい」といった主旨の言葉で しめくくられていました。

このコラムがきっかけとなって、 なんとかして EA 以外の命令も知りたいと思うようになりました。 今と違ってインターネットも検索エンジンもありませんから、 当時中学生だった私が 6502 の命令セットを見つけ出すことは難しく、 それだけに一層「切望感」がつのったのでした。

私が初めてコンピュータに触れたのは、中学一年生の終わり頃である。 「マイコン部」なるものがあって、 3台のCommodore PET 2001を 20人以上の部員で使っていた。 しかも「部活動」は週一回 50分ほどだったと記憶しているので、 PET 2001 に触れるのは、二週間に一度、25分だけ、 しかも二人で一台を使う形だった。 最初のうちは BASIC を使って簡単なゲームなどを書いていたが、 6502 のインストラクションセットをどこからか見つけてきて (どこで見つけたのだろう？ 当時はその手の資料を中学生が見つけることは、かなり難しかったはず)、 ハンドアセンブルしたコードを BASIC の poke 文でメモリに書いて 実行させて遊んだりした。

断片的な知識と体系的な知識 から引用

いまさらですが、 現代は便利な世の中ですねぇ... the 6502 microprocessor resource なんてページが簡単に見つかるのですから... こんなページを中学生時代の私が見たら、 「宝の山」を発見した感激で卒倒したことでしょう。 当時の私が苦労の末ついに見つけたのは、 65CE02 Microprocessor の 10, 11 ページの表だったのではないかと思います。

前回、 思い出したように「面接FAQ」を再開したのにはワケがあります。 Tech総研さんの「転職体験談」の取材を受けることになりまして、 それが、 あらためて私の面接のやりかたを振り返るきっかけになったのでした。 「転職体験談」というのは、 「転職を果たしたエンジニアと面接官が当時を再現」する連載企画で、 「応募者と面接官それぞれの言葉の真意や、 面接でチェックされるポイントをレポート」しようというものだそうです。

取材中は好き勝手なことを言いまくったので、 どのようなページにまとまるかと内心ドキドキしていたのですが (^^;)、 無難にまとまったようでホッとしています。 さすがはプロですね。

携帯電話関連を中心に独自技術で業界を走るKLabへ

携帯電話関連のさまざまな独自技術で知られるKLab（クラブ）は、 エンジニアに対する考え方が他社とは一味違う。 現時点での技術力や知識、担当した仕事の売り上げよりも、 ｢技術が好き｣から発する、挑戦や技術上の本質に対する継続的改善を尊ぶ。 また、技術力のみで昇格できる社内制度も設けている。

（取材・文／須田忠博　総研スタッフ／高橋マサシ）作成日：07.07.30

応募したエンジニア: 富田陽介さん（当時25歳）
企業の面接担当者: 取締役CTO 仙石浩明氏
募集職種: 技術力次第でCTOを目指せる研究開発職

Part1 転職の動機
Part2 技術志向性の強さ
Part3 現時点での関心

このような連載企画は、 応募者にとっては、 面接を受ける前にどんなことに注意すればいいかが分かるわけで、 とても参考になるのだろうと思いますが、 実は求人側の企業にとっても 面接のやり方を第三者の目で見てもらえる機会であるわけで、 とても有意義であると感じました。

求職側は、いろいろな会社の面接を受ければ、 どんな面接があるのか実地に知ることができますが、 求人側は、他社がどんな面接をしているかあまり知る機会はないですし、 まして自分達の面接が第三者の目から見るとどう映るのか、 教えてもらう機会は皆無ですから...

もちろん取材なので、忌憚のない意見を言ってもらえるわけではないのですが、 取材していただいた Tech総研の高橋マサシ様曰く:

現在の業務内容も転職の動機も重視せず、 「いかに技術が好きか」で人を見る面接。 この連載をほぼ50回続けていますが、 初めてのケースでした。 このことを仙石氏に話すと、 「えっ、他社はどんな面接なんですか？」と逆に驚いた様子。 数々の応募者ではなく、あなたが、いちばん技術が好きなんですよね。

転職体験談: 携帯電話関連を中心に独自技術で業界を走るKLabへ から引用

やたらに「こんな面接は初めて見た」と強調されるので、 逆にこちらが驚いてしまいました。 面接して採用した技術者が入社後どのくらい伸びるかは、 その人がどのくらい技術が好きかにかかっているわけで、 なら「どれだけ技術が好きか」をとことん聞くべきだと思うのですが、 他社の面接はそうじゃないのですかねぇ...?

なお、 「携帯電話関連を中心に独自技術で業界を走るKLabへ」ページ末尾にある:

このレポートに関連する求人情報です
チェックしてみよう！

KLab株式会社
現在の募集職種はこちら
詳細をみる

をクリックすると、 「この企業は現在リクナビＮＥＸＴ上で募集を行っていません」などと 表示されます (^^;) が、 私のブログを読んで下さってるかたなら、 リクナビNEXT (あるいはその他の求人媒体) で募集を行なっていないからといって、 応募できないわけではない、ということは よくご理解いただけてますよね？

一応、念のために申し上げておきますと、 KLab (に限らず大多数のベンチャーも同様だと思いますが) では、 常に直接応募を受付けております。 媒体やエージェント経由でないと応募を受付けないなどということは 一切ありませんし、 どこ経由で応募したかということは選考には一切影響しません。 さらに言えば「私は KLab へ入ってこれがやりたいんだ!」と 言ってくださるかたならば、 現在の募集職種にかかわらず採用を検討します。 やりたいことが明確になっていることこそが、 技術者の成長にとって一番重要なことだと思うからです。

技術を学ぼうとするなら、その時点での実力はサテオキ、 「伝わる状態」にかけては自分が一番だと自信を持って言い張れる (つまり、その技術を学びたいという情熱にかけては誰にも負けないと言いきれる) 状態からスタートしなければならないのです

技術者の成長に役立つ会社とは？(1) から引用

久しぶりに「面接 FAQ」シリーズの続きを書いてみます (前回書いたのは一年以上前なのでずいぶん間が空いてしまいました)。 私の面接というと最終面接であることが多いのですが、 履歴書の備考欄に「役員との面談希望！」と書いてある場合など、 一次面接から私が面接することもあります。 (最終の) 役員面接というと、 多くの人が通りいっぺんの面接だと思うらしく、 役員面接で技術的な突っ込みを受けて、 応募者が戸惑うケースが多々ありました。

私の面接で、 比較的頻度が高い私の質問パターンを紹介し、 応募者がどう答えることができていたら採用になっていたか、 振り返ってみようというのがこの「面接 FAQ」シリーズの主旨です。 FAQ すなわち、 面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法。

「面接 FAQ」は続き物ですので、 以下のページも参照して頂けると幸いです。

(1) 高い技術力って例えばどんなことですか？
(2) 何か質問はありませんか？
(3) 前職でいくらもらっていましたか？
(4) 仮に、何をしてもいい、と言われたら、何をしますか？
(5) 「人の役に立つことをしたい」と言う技術者の卵たち

面接というと、 「採用してやる」といった態度をとる面接官がいます。 つまり、 会社が求める資質を応募者が持っているかどうかを判断するのが、 面接官の役目だと思っている人ですね。 様々なチェックポイントを次から次へと確認し、 一つでも条件を満たさなければそこで不採用と判断します。 チェックポイント以外でどんなに優れた点を持っていようとお構い無しです。

その面接官にとっては、 採用した人にやってもらう仕事が明確に決まっているから、 その仕事をする能力があるかどうかが一番の関心ごとなんでしょうけど、 もしかしたら面接官よりよっぽど優れた長所を持っているかも知れないのに、 それを見ようともせずに不採用を決めてしまうのは、 モッタイナイ話ですよね？

私は根が貧乏性なので、そんなモッタイナイことは決してできません。 応募者が優れた点を持っているのなら、 たとえそれが KLab の事業と関係なくても、 応募して頂いたのは何かの縁ですから、 是非一緒に働きたいと思ってしまうわけです。 特定の分野に優れた能力を発揮できる人に入社してもらえるなら、 その分野の事業を始めてしまってもいいとさえ思っています。

なので、どんな分野であれ、 応募者が一番得意なことについて、 根掘り葉掘り質問させてもらうことになります。 私が多少なりとも知っている分野なら、 (面接で聞くのは不適切と思われるような) 異常に細かい点、 例えば実装上の細かい工夫とかまで聞いてしまいます。

そんな細かいことまでいちいち聞いていたら、 面接時間が何時間あっても足らないんじゃないか、 と驚かれるかたもいらっしゃるのですが、 私の面接では応募者の職務経歴を一通り聞くなんてことはせず、 応募者が一番自慢したいことだけを徹底的に聞くのがメインなので、 時間が許す限り掘り下げてお聞きするわけです。

しかしながら、 もちろん私が知らない分野もたくさんありますし、 コンピュータの分野であっても私がニガテな分野もあります。 私が何も知らないような分野だと、どんどん掘り下げて質問する、 というのは無理がありますから、そんなときは開き直って、

素人にも分かるように説明してください

って聞いちゃいます。 こう聞かれたら、なんだこんなことも知らないのか、 などと呆れずに丁寧に説明して頂けると幸いです。

応募者が、ずぶの素人である面接官に丁寧に説明したところで、 所詮は素人なんだから、 応募者がその分野についてどのくらい優れているか面接官に伝わるはず無い、 って思う人はいないでしょうか？

確かに、その分野のことについては何も知らないのですから、 その分野における応募者のレベルがどのくらいなのか (例えば、国内で十指に入るのか、あるいは平均くらいなのか、とか) は分かりません。 しかし説明の仕方だけでも応募者の能力はかなりのことが分かると 私は考えています。

「素人にも分かるように説明してください」と求められたとき、 専門用語を、平易な言葉で置き換えようと四苦八苦する人がいます。 勢い余って、さほど「専門的」でない言葉すら無理矢理言い換えようとして、 却って分かりにくくなったりすることもあります。

確かに専門用語だらけの説明は素人にとって分かりにくいし、 専門家の話が分かりにくいのは専門用語の濫用にある、と 考える人が多いのも事実でしょう。 専門用語だらけのマニュアルが非難されることもありますしね。

しかし、専門用語だけの問題でしょうか？ 専門用語の全てを解説した用語辞典を引きまくれば専門書が読めるかというと、 そんなことは決してありませんよね？

専門用語の意味さえ分かれれば、どんな専門分野でも理解できるでしょうか？ こう聞けば誰でも、そんなはずはないといいますよね？ つまり、 専門用語の置き換えるだけでは、 決して「素人にも分かるように」はならないのです。

どんな専門分野でもそうだと思いますが、 その分野特有の考え方、大げさに言えば思想のようなものがあります。 その分野の専門家なら皆が共有している「思想」なので、 あらためて考えてみたりはしませんが、 同じ「思想」を共有している専門家同士だから、 スムーズな意思疏通が可能になります。

逆に言えば、背景思想を共有していない門外漢には、 専門家同士の会話は「宇宙語」に聞こえてしまいます。 たとえ使っている単語自体は平易な言葉ばかりで、 専門用語が一切含まれていなかったとしても、 背景思想を共有していない素人には、 やはり「宇宙語」に聞こえてしまうのです。

「素人にも分かるように説明してください」と求められたとき、 話題にのぼった事項の説明は一時棚上げして、 まず背景思想から説明する人、 こういう人は間違いなく頭がいい人だと思います。 相手と自分が共有している「思想」は何か、 相手が共有していない「思想」は何か、 そして相手の「思想」に何を追加すれば理解してもらえるようになるのか、 そういったことを考えながら話せる人は、 きっと優秀な人なのだと思います。

いろんな人に、いろんな分野について説明してもらったことがありますが、 実に楽しそうに説明してくださるかたもいらっしゃいます。 私が分からない点を質問すると、 よくぞ聞いてくれたと嬉々として答えてくださるので、 とても話が盛り上がります。 そういう人は、 (面接中の感想としては気が早いんですが) KLab に入社して一緒に働けるようになるのが、 とても待ち遠しく感じられます。

先日、シアトルへ行ってきました。

シアトルと言えば、モノレール。

Westlake Center Mall 駅 (次の写真) と Seattle Center 駅を結んでいます。 シアトル万博 (1962年) の時に開業したそうです。

上の写真だと分かりにくいかも知れませんが、 モノレールの軌道が二本あります。 向かって左側の軌道に青色の車両が停車していますね。

同じ場所の軌道の部分を反対側から見ると、
↓ こんな感じ。

初めてこの Westlake Center Mall 駅を見たとき (2007年5月)、 とても強い違和感を感じてしまいました。 そもそも軌道が二本あるのに、 プラットホームが片側にしかないのがとても不自然でしたし、 ↑ の写真を見れば多くの方に同意して頂けるのではないかと思いますが、 二本の軌道が異常に接近しています。 こんなんで本当にすれ違えるのか？と、 誰もが疑問に思うのではないでしょうか。

Westlake Center Mall 駅と Seattle Center 駅とは 1.6km ほどしか離れておらず、 途中に駅がないのはもちろん、 二つの軌道を乗り換えるためのポイント (転轍機) もありません。 つまり、一方の軌道を走る車両は、決して、 もう片方の軌道を走ることはできません。

しかし、冒頭の Westlake Center Mall 駅の写真を見ると、 向かって左側の軌道は、 横のショッピング モールの建物と接していて乗降できそう (実際、モール 3階にモノレール乗り場があります) ですが、 向かって右側の軌道には、 乗降のためのプラットホームが見当たりません。 私はてっきり、右側の軌道は現在は使用されていないのだと思っていました。

ところが、別の日に反対側の Seattle Center 駅を訪れてみると、 Westlake Center Mall 駅で見た青色の車両の他に、 赤色の車両がありました。 下の写真だとちょっと分かりにくいかも知れませんが、 向かって右側の軌道に青色の車両が停っていて、 向かって左側の軌道に赤色の車両が走っています (ちょうどこの駅に入ってきたところです)。

トポロジー的に考えて、 赤色の車両が走っている軌道は、 Westlake Center Mall 駅へ行くと、 ショッピング モールの建物に接していない側の軌道につながっているはずです。 両方の駅で見た軌道が互いにどのようにつながっているかは、 次図のように、 モノレールの路線に赤色の軌道と、青色の軌道を書き入れてみると一目瞭然ですね。

赤色の車両が走っている軌道は、 ショッピング モールの建物に接していないのに、 どうやって乗降するのでしょうか？ とても謎です。

答はこちら。

技術者の成長に役立つ会社とは？(1) をとても多くの方々に読んで頂けました。 頂いたコメントや、 はてなブックマークに頂いたコメントを見ると、 賛同/批判 両方の立場から様々なご意見がありますね。 拙文が多くの方々の考えるきっかけになったのだとすれば、 書いた甲斐があるというものです。 特に学生さんにとっては、これから自身の人生を切り拓いていくのですから、 いま自分の将来について考えることは、 必ず後の人生にとってプラスになることでしょう。

以下に述べるのは、私が考える「技術者の成長に役立つ会社」の条件です。 他の人は異なった考えを持つかもしれませんし、 私自身も常に考え続けているので、 「役立つ会社」の条件が変ってくることがあるかも知れません。 しかし、 「技術者の成長にとって一番役に立つ会社を目指したい」というその思い自体は、 私が技術の責任者であり続ける限り、変らず持ち続けたいと思っています。

成長を邪魔しない会社

エラソーに「技術者の成長に役立つ会社」の条件と言っておきながら、 最初の条件が「邪魔しない」かよ、 えらく後ろ向きな条件だな、 という非難の声が聞こえてきそう (^^;) ですが、

上司は思いつきでものを言う(新書)
橋本 治 (著)

にも書かれているように、

会社は上司のピラミッドを骨格として、現場という大地の上に立っている。 「上から下へ」という命令系統で出来上がっていて、 「下から上へ」の声を反映しにくい。 部下からの建設的な提言は、 拒絶されるか、拒絶はされなくても、 上司の「思いつき回路」を作動させてしまう。

ということは、極めてありがちなのではないかと思います。 つまり、上司は体面を保つ必要がありますから、 部下に接するとき、 部下の良いところを誉めるだけではなく、 つい「粗探し」をして一言追加したくなるものだと思います。

だって、部下のことを 100% 肯定するだけでは、 上司の存在価値が危うくなりますからね〜。 なにか部下の至らない点を無理矢理にでも見つけ出して、 教訓めいたことを言って上司の威厳を保ちたくなるものでしょう。

もちろん、部下の狭量な考えを正すために、 いろんな意見を言ってやることが必要なケースもあるでしょう。 「思いつきで」言うことが全て悪いと言うつもりもありません。 しかし、 部下の短所を矯正することばかりに熱中していては、 部下が技術者として成長することを妨げることになりかねません。 例えば、

キミは技術は優れているんだが、 もうちょっと仲間とうまく仕事をやっていくよう努力してもらえんかね？ キミも社会人なんだから学生気分は早く捨てて、 チームワークを重視して仕事してもらわんと困るよ。

なんて言ってないでしょうか？ 技術が (おそらく上司よりも) 優れている部下に対し、 その得意な技術をもっと伸ばすことよりも、 その部下がニガテとしていること、 例えばコミュニケーション能力を 「人並みに」身につけることを優先するよう要求してしまうわけです。

「感情的コミュニケーション」は、 若いうち (例えば 30歳前半まで) は手を出さないようにして欲しい コミュニケーション能力である。 特に研究者や技術者を目指そうとする若い人たちには、 周りの人がどう思うかなんかは気にせず、 (「空気嫁！」などの罵倒は無視して) 我が道を進んで欲しい。

「人を動かす」感情的コミュニケーション能力と
「モノを動かす」論理的コミュニケーション能力
から引用

コミュニケーション能力なんて、 歳をとって頭が固くなってからでも充分身につけることができます。 そもそも技術者にとって「人並み」のコミュニケーション能力なんて、 どれほどの価値があるというのでしょう？ 技術者としての成長を考えるなら、 若いときにしか学べない「技術の本質」を身につけることこそ、 優先すべきではないでしょうか。

以上は、積極的に「成長を邪魔する」ケースですが、 以下のように、消極的に「成長を邪魔する」ケースも、 ありがちなのではないかと思います。

すなわち、 技術者の成長を第一に考えるのなら、 それぞれの技術者が自身の能力をフルに発揮して、 得意なことをとことん伸ばすことができるような 活躍の場を与えるべきだと思うのですが、 現実の会社だとそういう「適材適所」は、 なかなか難しいケースが多いかも知れません。 適切な活躍の場を与えないというのは、 成長を邪魔しようと意図しているわけではないにせよ、 結果として邪魔しています。

例えば、 新入社員がある特定の分野において素晴らしい能力を持っていたとしても、 その分野の業務に先任者がいたらどうでしょうか？ その先任者を異動させてまで、 新人にその分野の業務を任せる、 という会社は多くはないでしょう。 むしろ、 新人が何が得意か検討して配属先を決めるというよりは、 人が足らない部署への配属を優先する会社の方が 多数派であるような気がします。

さらに言えば、 配属後も新人には雑用ばかりをやらせ、 能力を発揮できる仕事を任せない、 なんてこともあるのではないでしょうか。 上司と同様、 先輩にもメンツというのがありますから、 たとえ後輩の方が能力が高かったとしても、 それを素直に認めて立場を逆転させる (つまり先輩が新人の指示に従う) よりも、 新人の至らない点を無理矢理にでも見つけ出すことに熱中し、 雑用を押し付けることに終始してしまうものなのかも知れません。

会社ってのは、 部下や後輩の技術者の成長を邪魔してしまえ、とささやく誘惑に満ちています。 私自身、そういう誘惑に負けそうになることが全く無いと言えば嘘になります。 部下や後輩の技術者の成長を邪魔していないか、 常に自省し続けることこそ、 「技術者の成長に役立つ会社」の第一の条件と言えるのではないでしょうか。

技術者を「技術そのもの」で評価する会社

技術者が邪魔されずに成長できたとしても、 その成長を「技術そのもの」できちんと評価してあげられなければ、 片手落ちです。 技術的に成長したら成長したぶんだけ、 きちんと評価されて給料が上がる、 こうしてはじめて、 技術的に成長しようという意欲が継続するのだと思います。

こういう話をすると、 なぜ技術的に成長したからといって給料を上げる必要があるのか、 と思う人がいるかも知れません。 会社は技術者養成機関ではありませんから、 能力ではなく成果に対して報酬を支払いたい、 と思う人が出てくるのは当然でしょう。 では、「技術者の成果」とは何でしょうか？

「技術者の成果」とは何でしょう？
技術者が作ったものから得られる売上でしょうか？ もちろん、それだけではないですよね？ 「青色LED」のように最終的に莫大な利益を生み出したものは、 とても分かりやすい「成果」ですが、 サーバシステムの運用などのような縁の下の力持ちの仕事だって立派な成果ですし、 さらに、自分自身では何も生み出さなくても、 社内の技術者を育てることや、 社内の技術をブログなどで発表して会社の知名度を上げることなども、 立派な成果と言えるでしょう。

技術者を目指す学生さんたちへ から引用

技術者という人材を「人財」すなわち会社の資産と考えるのであれば、 技術者の成長とは、「人財」の価値の増加、 すなわち会社の資産の増加を意味します。 売上は単にそのとき限りのフローに過ぎませんが、 技術者の成長はストックとなるわけです。 会計数字には現われにくいので見落とされがちなのですが、 技術者自身の成長こそ、 本来は最も評価されるべき「成果」と言えるのではないでしょうか。

しかしながら、 技術者の成長を「技術そのもの」で正当に評価することは、 容易ではありません。 「技術そのもの」で評価しようとすれば、 その技術分野の概要を理解している程度では全くダメで、 いざとなったら部下の仕事を代行できるくらいの技術力が、 評価する側に求められます。

もちろん、 いろんな得意分野を持つ部下たち全員において、 その仕事を完全に代行できることを上司に求めるのは無理な話でしょう。 部下全員の技術力のスーパーセットの技術力を上司の条件にしていては、 上司のなり手がいなくなってしまいます。

かといって、 半期ないし一年における部下の技術面での成長が、 どのくらい優れたものといえるのか評価できなければ、 つまり毎回「よくできました」「もっとがんばりましょう」などの 概要評価ばかりでは、 部下のモチベーションが下がってしまうことでしょう。 まして、技術面で部下の能力を評価するのを放棄して、 部下の関わったプロジェクトの売上高をそのまま部下の評価としていては、 技術的に成長しようというモチベーションを持続させることは不可能でしょう。

給料の一部が売上 (ないし利益等) に連動する、 ということはあってもいいとは思いますが、 技術力に連動する部分もあるべきで、 技術的に大きく成長したときはきちんと給料に反映させ、 あまり成長できなかったときは何が足らないのか、 きちんと指摘してあげるべきだと思うのです。

それには、 部下それぞれの得意分野について、 パフォーマンスの観点では部下に劣ることがあったとしても、 少なくとも技術内容の理解の観点では勝るとも劣らないことが 重要ではないでしょうか。

もちろん、これとて容易なことではありません。 部下が極めて優秀な場合、 その技術的背景をマトモに理解するには大変な労力が必要となるかも知れません。 つい、技術で評価するのを放棄して、 技術とは関係ない点を持ち出したくなるものだと思います。 しかし、 いくら大変でも、いくら時間がかかっても、 部下の技術を一生懸命理解しようとすることが重要だし、 理解しようと努力し続けてはじめて、 「技術力ではないところで部下を評価してしまえ」という誘惑に 打ち克つことができるのではないでしょうか。

得意分野を見つける余裕がある会社

現在の仕事が自身の得意分野に一致していて、 かつその仕事が好きであれば、 技術者にとってそれは理想的な仕事と言えるでしょう。

一生の時間のうちのかなりの時間を仕事に費やすのですから、 一生かけて取り組みたいと思うようなことをすべきだと思うのです。 好きなことをやっててお金がもらえれば苦労はしない、 と多くの人は言うでしょう。 でも、本当に一生かけてもやりたいほど好きなことってありますか？

面接 FAQ (4) から引用

しかし、 「やりたいこと」そのものズバリを、 最初に就職したときから仕事として やり続けてきた、 という人は少数派でしょう。 (私を含めて) 多くの人は、 いろんなことをやっているうちに、 「これだ」という仕事に出会い、 それにのめり込んでいくものなのではないかと思います。

あるいは、 今の仕事が一番自分に向いていると思っていたとしても、 なにかのきっかけで他の分野のことをやってみたら、 その分野のほうが魅力的であると感じ、 どんどん引き込まれてやっているうちに、 そっちのほうが自分に向いていることに気づく、 なんてこともあるかも知れません。

だから、 本業以外にも、 業務と関係ないことでも、いろいろ挑戦して欲しいと思っています。 ふとしたきっかけで始めたことが、 もしかすると自身の隠れた才能が開花することに 繋がるかも知れないのですから。

本業以外に熱中できる新分野を見つけた部下に対し、 「新分野を頑張るのはいいけど本業も忘れずにね」という忠告はするけど、 その新分野への取組みも大いに応援する、 KLab(株)はそんな会社でありたいと思っています。 勤務時間の 10% は本業以外のことを好き勝手にやっていい、 もし見込みが出てきて周囲から認められるレベルになったら、 それを本業にしてしまってもいい、 という「どぶろく制度」を作ったのも、 熱中できることを見つけるチャンスを逃して欲しくない、という思いからです。

キャリアにおける「鶏と卵」 ── 「卵」を後回しにして欲しくない から引用

本業の完璧な遂行もいいのですが、 自身の能力を最も発揮できる分野は一体何なのか考える余裕は持って欲しいですし、 技術者それぞれが最も自分に向いている仕事に出会えるように手助けすることこそが、 技術者のための技術会社の存在意義なのではないかと思います。

ひろのぶさん、けいこさん、ご結婚おめでとうございます。

ご両家、ご親族の皆様、本日はまことにおめでとうございます。

どうぞ、おかけになって下さい。

私はひろのぶさんの勤務先であるKLab株式会社で 技術の責任者を勤めている仙石と申します。

ひろのぶさんは、 KLab株式会社で技術者として働いているわけですが、 技術者と言っても当然いろいろな職種があるわけで、 ひろのぶさんはシステム管理者と呼ばれる役割を担っています。

普通の方々にとっては、 「システム管理者」というのは馴染みのない言葉かも知れません。 「管理者」というと管理職のことを思い浮かべるかたも多いかもしれませんが、 管理する対象は人間ではなくてコンピュータのシステムということになります。 平たく言えば、たくさんのコンピュータがきちんと動くよう見張る仕事です。

縁の下の力持ち的な仕事で、ある意味とても地味な仕事といってもよいでしょう。 コンピュータが正常に動いている限り、システム管理者とは空気のような存在で、 ともすると存在を忘れられがちになります。

そしてシステム管理者に注目が集まるのは、 コンピュータにトラブルが起きたときです。 何やってんだ、早よ直せ！そういう罵倒がシステム管理者に向けられます。 仕事がうまくいってコンピュータがきちんと動いているときは空気のように忘れられ、 失敗してコンピュータにトラブルが起きたときは非難の矢面にさらされる、 なんとも損な役回りであります。

だから、システム管理者を目指そうとする人は、 世間一般で言うと、そんなに多くはない。 さらに、技術を磨いてより高いレベルのシステム管理者を目指そうという人は、 よほどの変わり者といってもいいかもしれません。

でも、逆に言うと、レベルの高いシステム管理者というのはとても貴重な存在、 ということになります。 私の感覚で言うと、一人前のシステム管理者は、おそらく全国に 1000人もいない。 何十万人もいるコンピュータ技術者の中で、たった 1000人です。 割合で言うと 1% よりもずっと少ない。 そういう稀有な人材の一人が、ひろのぶさんというわけです。

そういう貴重な人材だからこそ、 もっとシステム管理者の地位を向上させたい、 トラブルが起きたときだけでなく、システム管理者がいい仕事をしたとき —つまりコンピュータがいつもどおり動いているということなので、 あまり華々しさはないのですが— そういうときにも、 システム管理者がきちんと評価されるような、 そういった会社でありたいと思っています。

コンピュータが順調に動いているとき、 システム管理者は 一見、なにもしていないようにも見えてしまうのですが、 実際には、トラブルを未然に回避すべく、 いろんな創意工夫をシステムに盛り込もうとしています。 あるいはシステムに普段と違う様子がないか コンピュータの動作を常に気にかけています。 少しでも違った気配があったりすると、 とても心配して、気が気でなかったりします。

これはもう「愛情」と言ってしまってもいいかもしれません。

コンピュータのような無機物を「愛する」なんて言うと、 変人扱いされてしまいかねない今日このごろなのですが、 モノに対する愛を変なものと考える昨今の風潮は、 いかがなものかと思います。

古来から日本人は万物に霊が宿っていると考え、 様々なものを愛でてきました。 命あるものだけでなく、 そのあたりの石ころや、あるいや刀や兜など、 そういったものにも魂が宿っていると考え、 愛してきたのです。

そういうモノに対する愛が、 工芸品などの高い技術をはぐくんできたのだと思います。 現在、コンピュータに関する技術で日本は米国など諸外国に 大きく遅れをとっているわけですが、 その原因の一つは、 そういったモノに対する愛を忘れてしまったからなのかもしれません。 コンピュータだってソフトウェアだってもっと愛すべきだと思いますし、 そういう心が高い技術を生み出すのだと私は思います。

まとめますと、システム管理者の仕事というのは、 日ごろからコンピュータの具合に気を配り、 愛情を持って接し、 平穏な日常を最大の目標としつつ、 創意工夫を盛り込むことを忘れない、 そういう仕事です。

こうしてみると、システム管理ってのは、 円満な家庭を築くのと驚くほど共通点が多いのではないかと思います。

そういえば、 弊社においてもシステム管理者ってのは愛妻家が多いような気がします。

あ、もちろん、他の職種の人の家庭が円満ではない、と 言っているわけではないです、念のため。

優秀なシステム管理者であるひろのぶさんなら、 きっと素晴らしく円満かつ幸せな家庭を築いていける、、 そんな気がします。

というわけで、 なんとか無事、 お話が結婚のお話に結びついたところで、 お祝いの言葉とさせていただきます。

本日は誠におめでとうございます。

ここ何ヵ月か、就職活動中の多くの学生さん達と話す機会を得ました。 いろんな方々と話しているうちに、 会社選びをしているはずの当の学生さん達の多くが、 いい会社の条件について確固たる基準を持っているわけではない、 という思いをますます強くしました。

「安定している会社」「福利厚生が充実している会社」「技術を教えてくれる会社」 などなど、 なんとなく「いい会社」のイメージを思い描いているだけで、 それが自身の人生にどう役に立つか、 筋道だった考えを持っているわけではないことに 改めて驚かされます。

安定している会社

「いい会社」のイメージとして、多くの学生さんがいだくものの筆頭は、 「安定している会社」「儲かってる会社」「勝ち組企業」でしょう。

先月 4/14 19:30 NHK で、 特報首都圏「就職戦線異状あり・格差社会の不安」と題する番組があった。 新卒の学生さん達が「勝ち組になる」ことを目指して 就職活動を行なっているのだという。
そりゃ、勝てるものなら勝ちたいと思うのは人の常なので、 これから社会に出ていこうとする学生さん達が、 将来勝ち組になれるような就職先を選ぼうとするのは至極当然のことだと思う。
ところが
学生さん達曰く、「勝ち組になるため、儲かっている会社に就職したい」。

勝ち組になるには から引用

ここんところ選挙などもあったからか、 「格差是正」を訴える声を聞くことが多かったのですが、 そもそも「格差」ってのは、 誰と誰との間の格差なんでしょうか？ 「儲かっている会社に勤めている人」と、 そういう「いい会社」に雇ってもらえない人との間の格差なんでしょうか？ 自身の実力は関係なくて、 「いい雇い主」に雇ってもらえるか否かが重要なんでしょうか？ こういう発想には、まるで 「いい家柄」の出身かどうかを気にする階級主義者や 「血筋」を気にする人種差別主義者と似たニオイを感じてしまうのです。

「儲かってる会社」に勤めていて、高い給料をもらっていたとしても、 その能力は会社の中だけでしか通用しないものかも知れず、 逆に、儲かってない会社に勤めていたとしても、 自身の能力を磨くことを怠らなければ、 会社を飛び出して活躍できるようになるかも知れないってのは、 誰もが思っていることですよね？ 昔は儲かっていたけど、 今では会社が傾いて、ついにはリストラされてしまった、 ってのもよく聞く話です。 「最後に頼れるのは己れの実力だけ」って 誰もがよく口にするわりには、 こと「格差」を考えるときに限っては、 「実力」より「どんな会社に勤めているか」のほうが先に出てくるのは なぜなんでしょうか？

「実力を磨きたいのは山々なれど、 実力を磨かせてくれるいい会社がない」とか、 「実力うんぬん以前に、 まず先立つモノ (給料) がないと」とか、 「実力はあるつもりだが、 それを正当に評価してくれる会社がない」とか、 そういった声が聞こえてきそうです。

確かに、ほとんどの会社は 実力を磨かせるより、コキ使うほうを優先するかも知れませんし、 実力をきちんと評価してくれない会社が圧倒的多数なのかも知れません。 しかしながら、世の中の 99.9% までそういう会社だったとしても、 実際に勤める会社は (当たり前ですが) たった一社でいいんです。 圧倒的多数の会社が社員の能力を伸ばすことに非協力的だったとしても、 そんなことはどーでもいいじゃないですか。 重要なのは自分が実際に就職する会社がどんな会社であるかであって、 世の中の会社の平均がどんな状況かではないのですから。

福利厚生が充実している会社

「安定している会社」を求める以上に不可解なのが、 「福利厚生の充実度」を気にする学生さん達です。 いったい会社に行って何をするつもりなんでしょうか？

自身の実力で会社に利益をもたらし、 その見返りに報酬を得る、というのなら筋が通っていますが、 それなら「福利厚生」みたいな中途半端なものを求めるまでもなく、 ストレートに自身の貢献に見合う「お金」を要求すればよい話です。 「お金」を求める自信も度胸もないからこそ、 「制度」としての「福利厚生」を求めるのでしょうが、 実力が足らないのを自覚しているのなら、 「福利厚生」を享受するなんて余裕をかましている場合じゃないでしょう？

これから社会に出ていく学生さん達が最優先で取組むべきことは、 会社と対等に渡り合える実力を身につけるために、 いま何をすべきか考えることでしょう。 そんな実力を身につけることは自分には永遠にムリと思う人がいるかもしれませんが、 ムリと思えば思うほど実現は遠退きます。 世の中にはいろんな会社があるのですから、 自身の能力を磨くのに適した会社は、 見つけようとしさえすれば、きっと見つかるはずです。

「20:80 の法則」 (パレートの法則) というものがある。 「売上の8割は、全従業員のうちの2割で生み出している」などの経験則が知られるが、 じゃ、その 2割の従業員だけでドリームチームを作れば、 すごい会社が作れるかというと残念ながらそうは問屋がおろさない。 「2割の従業員」がふたたび「20:80」に分かれてしまうのである。 精鋭チームを作ったつもりが、 そのチームの中の多数 (8割) は売上にあまり貢献しなくなってしまう。 逆に、ダメな従業員だけを集めたダメダメチームを作っても、 その中の 2割ほどは頭角を現し、チームを率いるようになる。
つまり能力を向上させる最良の方法は、自分が上位 20% に入ることを目指せるような集団に属することである。 まさに「寧ろ鶏口となるも牛後となるなかれ」。 上位20% に入ることがどうしても無理なら、 それはその集団が向いていないということである。 牛後に甘んじるよりは思い切って飛び出すべきだろう。

ロングテール戦略が格差社会を生む: 機会均等 から引用

会社をイメージで選ぶのではなく、 どんな会社が自分にとって「いい会社」なのか、 考えることから始めるべきではないでしょうか。

技術を教えてくれる会社

「安定している会社」や「福利厚生」を求めるのに比べれば、 まだマシなのが「技術を教えてくれる会社」を求める学生さん達です。 少なくとも自分の能力を向上させようという意欲は持っているのですから。 しかしながら、 「受け身」の姿勢であるという点では、 大差ないのかも知れません。

「技術を教えてもらう」という態度では、 おそらく永久に上位 20% に入ることはできないでしょう。 「技術は伝えるものではなく伝わるもの」なのですから、 教える側に「充実した伝える方法」(例えば完備された指導マニュアル) を 求めている限り、 決して師匠に追い付くことはできません。 技術の習得に関して誰よりも貪欲であり続けなければ、 上位 20% を目指すどころか、 平均的な先輩たちを追い越すことすら覚束ないことでしょう。

つまり、技術を学ぼうとするなら、 その時点での実力はサテオキ、 「伝わる状態」にかけては自分が一番だと自信を持って言い張れる (つまり、その技術を学びたいという情熱にかけては誰にも負けないと言いきれる) 状態からスタートしなければならないのです。

「技術力のある会社に就職すれば、 そこそこの技術を身につけることができる」 そう考える人が多いのかも知れませんが、 これは二重の意味で間違っています。 すなわち、 「伝わる状態」ができていなければ学べないという意味で間違っているだけでなく、 仮に技術を身につけることができたとしても、 「そこそこの技術」では役に立たないという意味でも間違っています。

インターネットなどの普及によって技術に関する情報が巷に溢れる昨今、 「そこそこの技術」であれば、 会社に勤めなくてもいくらでも身につけることができます。 いやむしろ、 会社に勤めることよりも学ぶ意欲のほうがよほど重要でしょう。 技術力のある会社に就職したから技術が身につく、 なんて甘い考えでいる限り、 できることといえば「技術に慣れる」ことどまりでしょう。

長年やっていれば、誰でもそれなりの技術を習得できます。 極端なことを言うと、 どんなに能力がない人でもそのときの自分の状態にあった程度のことを 実践していけば、 その積み重ねの中でやがてはなんらかの技術を習得することができます。
しかし、このようなものは本来、技術の伝達とはいえません。 これを技術の習得というのも不適切で、 ただ単に技術に慣れただけというのが正確な言い方でしょう。
じつはこのように、 経験と慣れだけで技術を獲得してきた人は世の中にたくさんいます。 私はこういう人を「偽ベテラン」と呼んでいます

組織を強くする技術の伝え方 (畑村 洋太郎 著) から引用

「偽ベテラン」レベルの能力では、 「会社と対等に渡り合える」わけもなく、 そんな「使えない」能力を身につけるくらいなら、 別の分野を目指すべきだった、ということになってしまうかも知れません。

だから、高い技術力を持つから「いい会社」なのではなく、 その技術が自分自身が本当に身につけたいと心の底から思えるような 技術か否かのほうが重要だと思いますし、 技術の高さ低さよりは、 自身が技術を身につけていこうとする際に、 「役に立つ」会社か否かを見極めることのほうが重要だと思います。

では、どんな会社が技術者の成長に役立つ会社なのでしょうか？
続きは次回に...

「Perl の非同期I/Oモジュール POE を使って VPN-Warp relayagent を書いてみました」に 続いて、 同じく POE を使って VPN-Warp リレー サーバも書いてみました。 これで、オープンソースだけを使って VPN-Warp を実現することができます。

今までも、 BIGLOBE の VPN ワープのページから証明書を取得すれば、 月額 525円で VPN-Warp を試してみることはできたわけですが、 ちょっと試してみたい場合など、 有料であることがネックである感は否めませんでした。 特に、 常日頃からオープンソースを使いこなしている方々だと、 ちょっと使ってみたいだけなのにお金を払うのはねぇ、 と思ってしまうのではないでしょうか。 かくいう私も、 無料「お試し版」のサービスやソフトウェアに慣れきってしまっているので、 試しに使ってみようとする場合に、 それが有料だったりすると、 いきなり億劫になってしまう今日このごろだったりします (^^;)。

というわけで、 オープンソース版 VPN-Warp です。 使い方はあまりフレンドリーではありませんが、 なんたって全て公開してしまっているので、 興味あるかたは、 とことんいじってみてはいかがでしょうか。

relayagent.pl と同様、 今回公開する relayserver.pl も SSL 暗号化/復号の機能を含んでいません。 したがってリレー サーバへの https アクセスを stone などを 通して SSL 復号する必要があります。 例えば stone を

stone -z cert=cert.pem -z key=priv.pem \
      localhost:12345 443/ssl &

などと実行しておき、 relayserver.pl を

relayserver.pl 12345

と実行します。これだけで 443番ポートはリレー サーバとして利用できます。 つまり、relayagent とブラウザからの https 接続を受付けると、 リレー サーバが両セッションを中継し 「ブラウザ → リレー サーバ → relayagent → Webサーバ」 という経路で通信できます。

                      リレー            イントラ         イントラ
ブラウザ ─────→ サーバ ←──── relayagent──→ Webサーバ
            https     443番ポート                        80番ポート

見かけは極めて tiny ですが、 通信プロトコルは本物(?)の VPN-Warp と互換性があるので、 「VPN-Warp relayagent フリー ダウンロード」から ダウンロードできる VPN-Warp relayagent を使うこともできます。

そもそも論で言えば、 リレー サーバの役目は単にデータを右から左へ渡すだけなので、 以下に示すようにその中核の部分は極めてシンプルです。 しかしながら、もちろんこれは KLab(株) で運用しているリレー サーバが単純であることを意味しません。 機能がシンプルでも、大量の同時接続 & 大量データを受付ける耐高負荷性能や、 機器の一部に故障が起きてもサービスが影響を受けない高可用性を実現するために、 様々な工夫を盛り込んでいます。

では、relayserver.pl の中身を順に見ていきましょう。

#!/usr/bin/perl
use POE qw(Component::Server::TCP Filter::Stream);
my $Port = shift;
my $PollID;
my $PollHeap;
my $PollBuf;
my $PollHeader;
my %SID;
my %Heap;
my %Buf;
my $NextSID = 0;

POE::Component::Server::TCP->new
    (
     Port => $Port,
     ClientInput => sub {
	 my ($heap, $input, $id) = @_[HEAP, ARG0, ARG1];
	 if (defined $PollID && $id == $PollID) {
	     $PollHeap = $heap;
	     $PollBuf .= $input;
	     &doPoll;
	 } elsif (defined $SID{$id}) {
	     my $sid = $SID{$id};
	     $Heap{$sid} = $heap;
	     $Buf{$sid} .= $input;
	     &doSession($sid);
	 } elsif ($input =~ m@^GET /KLAB/poll @) {
	     if (defined $PollID) {
		 $heap->{client}->
		     put("HTTP/1.1 503 Service Unavailable\r\n\r\n");
		 $heap->{client}->shutdown_output;
		 return;
	     }
	     $PollID = $id;
	     $PollHeap = $heap;
	     $PollBuf = $input;
	     &doPoll;
	 } else {
	     $SID{$id} = $NextSID;
	     $NextSID = ($NextSID + 1) & 0xFFFF;
	     my $sid = $SID{$id};
	     $Heap{$sid} = $heap;
	     $Buf{$sid} = $input;
	     &doSession($sid);
	 }
     },
     ClientDisconnected => sub {
	 my $heap = $_[HEAP];
	 my $id = $heap->{client}->ID;
	 if (defined $PollID && $id == $PollID) {
	     undef $PollHeap;
	     undef $PollBuf;
	     undef $PollHeader;
	     undef $PollID;
	 } elsif (defined $SID{$id}) {
	     my $sid = $SID{$id};
	     undef $SID{$id};
	     undef $Heap{$sid};
	     undef $Buf{$sid};
	 }
     },
     ClientFilter => POE::Filter::Stream->new(),
    );
POE::Kernel->run;

わずか 70行にも満たないコードですが、 リレー サーバの中核の部分は、ほとんどこれで全てです。 いかに POE (Perl Object Environment) の 記述性が高いか分かりますね。

私は常日頃から プログラマの生産性は、ピンとキリでは 3桁の違いがある と主張しています。 この主張をもう少し詳しく言うと、 その 3桁のうち、プログラマの腕に純粋に依存する部分は 2桁ほどの違いで、 残り 1桁ぶんは解決すべき問題に応じていかに最適な道具を使うかの違い、 ということになります。 最適な道具を使いこなせるもの腕のうち、 ということもできますね。

上記 70行にも満たないコードですが、 実は命令文としてみると、 わずかに 2 つの命令文であることが分かります。 すなわち、

POE::Component::Server::TCP->new(...中略...);
POE::Kernel->run;

ですね。実質「POE::Component::Server::TCP->new(...中略...);」 だけと言ってもいいでしょう。 この命令文は、

POE::Component::Server::TCP->new
    (
     Port => $Port,
     ClientInput => sub {
	 ... クライアントから受信したデータの処理 ...
     },
     ClientDisconnected => sub {
         ... クライアントとの接続が切れたときの処理 ...
     },
     ClientFilter => POE::Filter::Stream->new(),
    );

という構造になっています。 つまり、クライアントからデータが送られて来たときに呼び出されるルーチンと、 クライアントとの接続が切れたときに呼び出されるルーチンを指定しておけば、 あとは POE がうまくやってくれる、というわけです。簡単でしょう？

リレー サーバにとって「クライアント」というと、 ブラウザか relayagent になります。 クライアントからの TCP/IPセッション一本一本に対して POE が ID を割り振っていて、 この ID を見ればどの TCP/IPセッションで送られて来たデータか分かります。

「Perl の非同期I/Oモジュール POE を使って VPN-Warp relayagent を書いてみました」で 解説したように、 クライアントから送られて来た最初のデータが 「GET /KLAB/poll 」で始まっていれば、 そのクライアントは relayagent ですから、 以下のようにその ID ($id) を $PollID に代入しておきます。

	 elsif ($input =~ m@^GET /KLAB/poll @) {
	     if (defined $PollID) {
		 $heap->{client}->
		     put("HTTP/1.1 503 Service Unavailable\r\n\r\n");
		 $heap->{client}->shutdown_output;
		 return;
	     }
	     $PollID = $id;
	     $PollHeap = $heap;
	     $PollBuf = $input;
	     &doPoll;
	 }

同じ TCP/IPセッション (つまり $id == $PollID) で 続いて送られてきたデータは、 以下の部分で処理されます。

	 if (defined $PollID && $id == $PollID) {
	     $PollHeap = $heap;
	     $PollBuf .= $input;
	     &doPoll;
	 }

いずれの場合も、受信したデータはいったん $PollBuf に蓄えた上で、 「doPoll」ルーチンを呼び出します。

一方、ブラウザから送られてきたデータの場合は、 以下のようにセッションID ($SID{$id}) を順に割当てていきます。 「セッション」という単語が何度も出てきてややこしいのですが、 $id が POE が各 TCP/IPセッションに割当てた ID で、 各 TCP/IPセッションそれぞれに、 リレー サーバが 16bit の番号を割当てたのが VPN-Warp で言うところのセッションID ($sid = $SID{$id}) です。

	 else {
	     $SID{$id} = $NextSID;
	     $NextSID = ($NextSID + 1) & 0xFFFF;
	     my $sid = $SID{$id};
	     $Heap{$sid} = $heap;
	     $Buf{$sid} = $input;
	     &doSession($sid);
	 }

同じ TCP/IPセッション (つまりセッションID $sid が $SID{$id}) を通して 続いて送られてきたデータは、 以下の部分で処理されます。

	 elsif (defined $SID{$id}) {
	     my $sid = $SID{$id};
	     $Heap{$sid} = $heap;
	     $Buf{$sid} .= $input;
	     &doSession($sid);
	 }

いずれの場合も、受信したデータはいったん $Buf{$sid} に蓄えた上で、 「doSession」ルーチンを呼び出します。

つまり、relayagent から受信したデータは doPoll ルーチンで、 ブラウザから受信したデータは doSession ルーチンで、 それぞれ処理する、というわけです。 以下の図に示すように、 リレー サーバの役割は、 relayagent から受信した (ブロック化された) データを、 (ブロックを開梱しつつ) ブラウザへ送信し、 またブラウザから受信したデータを、 ブロック化して relayagent へ送ることですから、 doPoll および doSession が何をするためのルーチンか予想できますよね？

まず doPoll を見ていきましょう。

sub doPoll {
    do {
	if (! defined $PollHeader) {
	    if ($PollBuf =~ /\r\n\r\n/) {
		$PollHeader = `;
		$PollBuf = ';
		$PollHeap->{client}->put("HTTP/1.1 200 OK\r\n\r\n");
	    }
	}
	return unless defined $PollHeader;

リクエストヘッダを全て読み込んでいない場合 (つまり $PollBuff に空行 \r\n\r\n が含まれていない場合) は、ここで終わりです。
$PollBuf に受信データが追加されて、ふたたび doPoll が呼ばれるまで待ちます。

リクエストヘッダを全て読み込んだ場合は、 $PollBuf からリクエストヘッダ部分を削除した上で、 次に進みます。

	my ($sid, $len, $data) = unpack("nna*", $PollBuf);
	return unless defined $sid && defined $len && $len ne "";

ブロック全体を読み込めていない場合は、ここで終わりです。 $PollBuf に受信データが追加されて、ふたたび doPoll が呼ばれるまで待ちます。 「ブロック」というのは VPN-Warp 用語で、 relayagent とリレーサーバとの通信は、 基本的にこの「ブロック」を単位にして行ないます。 ブロックは次のような可変長のデータです。

    ┌───┬───┬───┬───┬───┬─≪─┬───┐
    │セッションＩＤ│　データ長　　│　　可変長データ　　　│
    └───┴───┴───┴───┴───┴─≫─┴───┘
          2バイト         2バイト      「データ長」バイト

「セッションID」および「データ長」は、ビッグエンディアンです。 つまり上位バイトが先に来ます。 したがって、上記コードによって $sid, $len, $data にそれぞれ 「セッションID」「データ長」「可変長データ」が代入されます。

なお、データ長が 0 ないし負数の場合は、 「可変長データ」の部分は 0 バイトになります。 このような「可変長データ」がないブロックは、 コントロール用のブロックで、 EOF や Error などのイベントを伝えます。

	if ($len > 32767) {
	    $len -= 65536;
	    $PollBuf = $data;
	    if ($len == -1) {
		&doShutdown($sid);
	    }
	}

$len == -1 のときは、Error を伝えるコントロール ブロックなので、 「doShutdown」ルーチンを呼び出しています。

	elsif ($len > 0) {
	    return unless defined $data && length($data) >= $len;
	    ($data, $PollBuf) = unpack "a${len}a*", $data;
	    if (defined $Heap{$sid}) {
		$Heap{$sid}->{client}->put($data);
	    }
	}

$len > 0 のときは、 $sid で示されるブラウザに対して $data を送信します。 $len == 0 のときは、 EOF を伝えるコントロール ブロックなので、 「doShutdown」ルーチンを呼び出しています。

	else {	# len == 0
	    $PollBuf = $data;
	    &doShutdown($sid);
	}
    } while ($PollBuf ne "");
}

以上を、$PollBuf が空になるまで続けます。

doShutdown はブラウザとの TCP/IPセッションを shutdown するためのルーチンです。

sub doShutdown {
    my ($sid) = @_;
    if (defined $Heap{$sid}) {
	$Heap{$sid}->{client}->shutdown_input;
    }
}

次に doSession です。

sub doSession {
    my ($sid) = @_;
    if (defined $PollHeap) {
	my $req = $Buf{$sid};
	$Buf{$sid} = "";
	for my $block (unpack "(a2048)*", $req) {
	    $PollHeap->{client}->
		put(pack("nna*", $sid, length($block), $block));
	}
    }
}

ブラウザから送られてきたデータを、 2048 バイトずつ区切って「セッションID」「データ長」を 前につけることによってブロック化して、 relayagent に送信しています。

オリジナルの VPN-Warp を使ったことがある方は既にお気付きかも知れませんが、 上記 relayserver.pl は説明を簡単にするために機能をいくつか省いています。 例えば、オリジナルのリレー サーバは、 接続する際はクライアント認証が必須で、 同じクライアント証明書を提示した relayagent とブラウザを 結び付ける機能があるのですが、 上記 relayserver.pl はクライアント認証を行なわないので、 任意のブラウザから接続可能ですし、 同時接続が可能な relayagent は一つだけです。

腕に覚えのあるかたは、 オリジナルの VPN-Warp と同等の機能を実現するには どのような修正を加えればよいか、 考えてみてはいかがでしょうか？ そして、 こういうことを考えることが好きなかた、 「いっしょにDSASつくりませんか？」

私は「やりたいことを仕事にすべき」と常日頃から主張しているのですが、 自分自身のことを振返ると、 必ずしも「やりたいこと」そのものズバリを 最初からやっていたわけではないことに気づきます。

「鶏がさきか、卵がさきかの議論になっちゃうんだけど」なんて枕詞があるが、 こと20代のキャリアにおいては 「まず目の前の仕事で最高の成果をだすことが"さき"で、 自分がやりたいと思う仕事をおっかけるのは"あと"」というのは 私の中では確信に近い。

「20代のキャリアにおける『鶏と卵』」から引用

確かに、何をやるにしても最初は素人であるはずで、 ずぶの素人が「この仕事をやりたい」と言ったところで、 任せてもらえることはレアケースでしょう。 仮に任せてもらえたとしても、 初めてやる仕事で成果を出せるとは限りません。

私は学校を卒業後、某大企業の研究所に就職し、 遺伝的アルゴリズムの研究に取組みました。 当時は (今も?) 大企業の研究所というのは人気職種で、 今から思えば「やりたいこと」というよりは 「人気の職種だから」やってみたいという思いの方が 強かったような気がします。

もちろん嫌々仕事 (研究) をしていたわけではないのですが、 仕事の合間を見つけては、 本業そっちのけで職場のイントラネット環境の整備に没頭してしまいました。 当時はまだ「イントラネット」という言葉すら生まれていない時代で、 何をするにもいちいち不便なネットワーク環境だったので、 いろいろ改善しようと思ったわけですが、 次第にネットワークの方が面白く感じるようになってしまいました。

入社当時に配属された部署というのは正直私があまり関心がある仕事ではなかったが、 当時はまだ"ひよっこ"という意識が強かったので、 とにかく結果をだすことに専念をした。
(中略)
どちらかというと目の前にある仕事をこなし、 そこで結果をだすのが精一杯で、 自分の関心が本当にどこにあるのかということを真剣に考える余裕も正直なく、 とにかくアサインされたプロジェクトで結果をだすことにがむしゃらになった。

同ページから引用

私の場合、配属された部署というのは関心がある仕事だったのですが、 もっと関心のある分野を見つけてしまったため、 本業 (目の前にある仕事) がおろそかになった、という感じでしょうか。 もしあのとき、 「アサインされた仕事で結果をだすことにがむしゃらになって」いたら、 本当に自分に向いていることを見つけ損なっていたのかも知れません。

確かに、他に熱中できることがなければ、 目の前の「本業」にがむしゃらになって取組むことも重要だとは思うのですが、 自分が本当は何に向いているのか、 いろいろ「かじってみる」余裕は持っていて欲しいと思うのです。

プロ野球選手を目指す子供に対して、 「野球を頑張るのはいいけど勉強も忘れずにね」というような忠告なら有用だと思う。 だけど、「プロ野球選手が本当の自分のゴールかどうかなんてわからないんだから、 まずは（アサインされた）目の前のテストで100点を取りなさい。 野球をするのはそれからだ」とは言わないでしょう？

「自分がやりたいと思う仕事をおっかけるのを"あと"にはしたくない」から引用

本業以外に熱中できる新分野を見つけた部下に対し、 「新分野を頑張るのはいいけど本業も忘れずにね」という忠告はするけど、 その新分野への取組みも大いに応援する、 KLab(株)はそんな会社でありたいと思っています。 勤務時間の 10% は本業以外のことを好き勝手にやっていい、 もし見込みが出てきて周囲から認められるレベルになったら、 それを本業にしてしまってもいい、という「どぶろく制度」を作ったのも、 熱中できることを見つけるチャンスを逃して欲しくない、という思いからです。

キャリアは偶然によって作られるものだと私も思う。 なので、その偶然をどう活かすかというのは非常に大切になってくる。 でも「偶然のレベル」と「自分のレベル」は等価なので、 偶然を活かす良いスパイラルを生み出すためには、 まず自分のレベルを上げないと始まらない。 なので、今ある仕事の中で自分のレベルを上げることを第一に考えるべきです。

「キャリアと上手に付き合うために」から引用

確かにその通りなのですが、 「偶然のレベル」を引き上げることは、 個人一人一人が自身のレベルを引き上げることによってだけでなく、 「偶然」を起りやすくする環境を会社が整えることによっても可能だと思いますし、 それこそが技術者のための技術会社の存在意義なのではないかと思います。

多数の TCP/IP セッションを同時に維持する必要性などから、 非同期I/O が最近流行りのようです。 何をいまさら、という気もするのですが、 いわゆる「最新技術」の多くが 30年前の技術の焼き直しに過ぎない今日このごろなので、 非同期I/O 技術が「再発見」されるのも、 「歴史は繰り返す」の一環なのでしょう。 スレッドが当たり前の時代になってからコンピュータ技術を学んだ人にとっては、 (古めかしい) 非同期I/O が新鮮に映るのかも知れず、 なんだか「ファッションのリバイバル」に似ていますね。

Perl で非同期I/O 処理を手軽に行なうための枠組みとして、 POE: Perl Object Environment というものが あるようです。 POE を使うと、 あたかもスレッドを使っているような手軽さでプログラミングできます。 試しに VPN-Warp の relayagent を POE を使って書いてみました。 オリジナルの relayagent は C 言語で記述した 4000 行を超える プログラムなのですが、 Perl だと 200 行以下で一通り動くものが書けてしまいました (もちろん C 版の機能を全て実装したわけではありません)。

POE を触るのは今回が初めてだったので、 マニュアルをいちいち参照しながら書いたのですが、 なにせわずか 200 行ですから、 開発はデバッグ込みで 1 日かかりませんでした。 改めて Perl の記述性の良さと開発効率の高さに感動したのですが、 これだけ簡潔に書けてしまうと、 relayagent の機能を解説するときの教材としても使えそうです。

というわけで、 今までブラックボックスだった relayagent の中身の解説を試みたいと思います。 これから POE を使ってみようとする人の参考にもなれば幸いです。

VPN-Warp の relayagent とは、 以下の図のようにリレーサーバと Webサーバの両方へ接続して、 リレーサーバから受取ったリクエストを Webサーバへ中継するプログラムです。 http リクエストを受取ってサービスを行なうのですから、 サーバの一種と言えますが、 外部から接続を受付けるわけではなく、 リレーサーバと Webサーバの両方に対してクライアントとして振る舞う点が ユニークと言えるでしょう。

                      リレー            イントラ         イントラ
ブラウザ ─────→ サーバ ←──── relayagent──→ Webサーバ
            https     443番ポート                        80番ポート

http リクエストを受取って Webサーバへ中継するプログラムというと、 proxy サーバを思い浮かべるかも知れません。 proxy サーバはその名の通り、 ブラウザに対してはサーバとして振る舞います:

                                        proxy            イントラ
ブラウザ ──────────────→ サーバ────→ Webサーバ
                                        8080番ポート     80番ポート

proxy サーバが、ブラウザからの接続を受付けて、 それを Webサーバに中継するのに対し、 relayagent は自身では接続を受付けずに中継する、 という違いがお分かりでしょうか？ relayagent は接続を受ける必要がないため、 ファイアウォールの内側など、 外部からアクセスできない場所で使うことが可能になっています。

なお、C 版の relayagent はリレーサーバに対して https で接続するのですが、 Perl 版 relayagent (以下 relayagent.pl) は、 説明の都合上 SSL 暗号化の機能を含んでいません。 実際に使うときは、 stone などで SSL 暗号化して リレーサーバに接続する必要があります。

         リレー                         イントラ         イントラ
         サーバ ←──── stone ←── relayagent──→ Webサーバ
         443番ポート       SSL化        Perl 版          80番ポート

例えば stone を

stone -q pfx=relay,5000005.pfx \
      -q passfile=relay,5000005-pass.txt \
      warp.klab.org:443/ssl localhost:12345 &

などと実行しておき、 relayagent.pl はリレーサーバに接続する代わりに、 localhost の 12345 番に接続します。

では、relayagent.pl を順に見ていきましょう。

#!/usr/bin/perl
use POE qw(Component::Client::TCP Filter::Stream);
my $IdleTimerMax = 6;	# 60 sec
&help unless @ARGV == 2;
&help unless shift =~ m/^(\w+):(\d+)$/;
my ($RelayHost, $RelayPort) = ($1, $2);
&help unless shift =~ m/^(\w+):(\d+)$/;
my ($WebHost, $WebPort) = ($1, $2);
my %WebHeap;
my $PollBuf;
my $PollHeap;
my $PollHeader;
my $IdleTimer;
my $DisconectTime = 0;

$RelayHost, $RelayPort は、 リレーサーバのホスト名とポート番号ですが、
前述したように stone 経由でリレーサーバにつなぐために、
$RelayHost = "localhost", $RelayPort = 12345 などとなります。また、 $WebHost, $WebPort は、 中継先となる (イントラの) Webサーバのホスト名とポート番号です。

続いて、リレーサーバへ接続する (直接の接続先は SSL 化を行なう stone ですが、 煩雑になるので以下 「リレーサーバ」 と略記します) ためのコードです:

POE::Component::Client::TCP->new
    ( RemoteAddress => $RelayHost,
      RemotePort    => $RelayPort,
      Connected     => sub {
	  $PollHeap = $_[HEAP];
	  undef $PollHeader;
	  $PollBuf = "";
	  $IdleTimer = $IdleTimerMax;
	  $PollHeap->{server}->
	      put("GET /KLAB/poll HTTP/1.1\r\nX-Ver: realyagent.pl 0.01\r\n\r\n");
      },
      ServerInput   => sub {
	  $PollHeap = $_[HEAP];
	  $PollBuf .= $_[ARG0];
	  &doPoll;
      },
      Filter        => POE::Filter::Stream->new(),
      Disconnected  => \&reconnectPoll,
    );

POE では、非同期に動く処理を、 処理ごとに分けて書くことができます。 各処理のことを「POEセッション」と呼びます。

上記は、リレーサーバへ接続する POEセッションの生成です。 接続先ホストおよびポートを、 それぞれ $RelayHost と $RelayPort に設定しています。

「Connected => sub {」から始まる部分が、 接続に成功したときに実行するコードです。 細かいところはさておき、 接続したら以下のリクエストをリレーサーバに送る、 という点は読み取れるのではないでしょうか。

GET /KLAB/poll HTTP/1.1
X-Ver: realyagent.pl 0.01

同様に、 「ServerInput => sub {」から始まる部分が、 通信相手 (リレーサーバ) からデータを受信したときに実行するコードです。 受信したデータは、 いったん変数 $PollBuf に溜めておいて、 続いて呼び出す doPoll の中で処理を行ないます。

以上からお分かりのように、 リレーサーバへデータを送るときは、
「$PollHeap->{server}->put(送るべきデータ);」を実行し、 リレーサーバからデータが送られてきた時は、 doPoll で受取ります。 とても見通しが良いですね。

各 POEセッションは、スレッドと同様、同一メモリ空間を共有しているので、 他の POEセッションが変更した変数の値を参照できます。 したがってどの POEセッションでもリレーサーバへデータを送ることができますし、 リレーサーバから受信したデータはどの POEセッションでも読むことができます。

続いて、もう一つ POEセッションを作ります。

POE::Session->create
    ( inline_states =>
      { _start => sub {
	  $_[KERNEL]->delay( tick => 10 );
        },
        tick => sub {
	    if ($IdleTimer > 0) {
		if (--$IdleTimer <= 0) {
		    &sendControl(0, -2);	# keep alive
		}
	    }
            $_[KERNEL]->delay( tick => 10 );
        },
      },
    );
$poe_kernel->run;
exit;

この POEセッションは 10秒に一回、 「tick => sub {」から始まる部分を実行します。 見ての通り、$IdleTimer の値を減らしていって、 0 になったら sendControl を実行します。 $IdleTimer は最初 6 ($IdleTimerMax) に設定されるので、 1 分ごとに sendControl を実行する、という意味ですね。

以上 2つの POEセッションは作成しただけで、まだ走り出していません。
その次の「$poe_kernel->run;」が各 POEセッションを走らせるための呼び出しです。 このルーチンは全ての POEセッションが終了するまで返ってきません。

さて、relayagent はリレーサーバとの接続を常時維持していますが、 無通信時間が続くと (通信経路中にあるファイアウォールなどに) 切られてしまう恐れがあるので、 keep alive ブロックを送信しています。 通信が行なわれていない時間を測るためのカウンタが $IdleTimer というわけです。

通信が行なわれない限り $IdleTimer は減り続け、 1 分経過すると sendControl(0, -2) を呼び出して keep alive ブロックを送信します。 sendControl はこんな感じ:

sub sendControl {
    my ($id, $control) = @_;
    $control += 65536 if $control < 0;
    $IdleTimer = $IdleTimerMax;
    if (defined $PollHeap && $PollHeap->{connected}) {
	$PollHeap->{server}->put(pack("nn", $id, $control));
    }
}

既に説明したように「$PollHeap->{server}->put(データ)」は、 リレーサーバにデータを送る呼び出しですから、 「pack("nn", 0, 65534)」が keep alive ブロックであることが分かります。

「ブロック」というのは VPN-Warp 用語でして、 relayagent とリレーサーバとの通信は、 基本的にこの「ブロック」を単位にして行ないます。 ブロックは次のような可変長のデータです。

    ┌───┬───┬───┬───┬───┬─≪─┬───┐
    │セッションＩＤ│　データ長　　│　　可変長データ　　　│
    └───┴───┴───┴───┴───┴─≫─┴───┘
          2バイト         2バイト      「データ長」バイト

「セッションID」および「データ長」は、ビッグエンディアンです。 つまり上位バイトが先に来ます。 データ長が 0 ないし負数の場合は、 「可変長データ」の部分は 0 バイトになります。

データ長が 0 ないし負数であるブロックは、 コントロール用のブロックで、 以下の意味を持っています:

ブラウザ送ったリクエストを Webサーバに届け、 Webサーバのレスポンスをブラウザに返す一連の通信のことを、 ここでは「Webセッション」と呼ぶことにします。 つまり、 VPN-Warp が提供する仮想的な通信路 (トンネル) 上のセッションです。

ブラウザがリレーサーバと通信するときの TCP/IPセッションと、 relayagent と Webサーバが通信するときの TCP/IPセッションを対応づけるのが、 セッションID です。 「セッション」という言葉が何度も出てきてややこしいですが、 「セッションID」の「セッション」は、 「Webセッション」の意味です。

リレーサーバと relayagent との間は、 複数の Webセッションを一本の TCP/IPセッションに相乗りさせるので、 そのとき各 Webセッションがこんがらないようにするために ブロックにはセッションID がつけられている、というわけです。

では、次はいよいよ relayagent の中核ルーチンである doPoll です:

sub doPoll {
    do {
	if (! defined $PollHeader) {
	    if ($PollBuf =~ /\r\n\r\n/) {
		$PollHeader = $`;
		$PollBuf = $';
	    }
	}
	return unless defined $PollHeader;
	my ($id, $len, $data) = unpack("nna*", $PollBuf);
	return unless defined $id && defined $len && $len ne "";
	if ($len > 32767) {
	    $len -= 65536;
	    $PollBuf = $data;
	    if ($len == -1) {
		&closeWeb($id);
	    }
	} elsif ($len > 0) {
	    return unless defined $data && length($data) >= $len;
	    ($data, $PollBuf) = unpack "a${len}a*", $data;
	    &reqWeb($id, $data);
	} else {	# len == 0
	    $PollBuf = $data;
	    &closeWeb($id);
	}
    } while ($PollBuf);
}

前述したように、relayagent はリレーサーバに接続したとき、 まず
「GET /KLAB/poll HTTP/1.1」から始まるリクエストヘッダを送ります。 するとリレーサーバは、 次のようなレスポンスを返します:

HTTP/1.1 200 OK
X-Customer: nusers=5&type=1&expire=1169696110&digest=3f6977eceb8c2c43e28e6026b08ba900

そしてこの後 (doPoll において「defined $PollHeader」が真のとき)、 リレーサーバと relayagent は、 前述したブロックを送受信することになります。

「my ($id, $len, $data) = unpack("nna*", $PollBuf);」の部分が、
リレーサーバから受信したブロックを、
「セッションID ($id)」 「データ長 ($len)」 「可変長データ ($data)」 に分解している処理ですね。 続いてブロックの処理が行なわれますが、 コントロールブロックに関する処理は割愛して、 可変長データが付いているブロックの処理を見ていきましょう。 ここで受信した可変長データは、 ブラウザが送信した http リクエストを 2048バイトごとに分割したものです。

つまりリレーサーバは、 ブラウザから https リクエストを受取るたびに「セッションID」を割り振ります。 そして、リクエストをブロックに分割して relayagent へ送信し、 逆に relayagent から受取ったブロックを 同じセッションID ごとに連結して、 http レスポンスとしてブラウザへ送信します。

したがって、 relayagent はリレーサーバから受取ったブロックを 同じセッションID ごとに連結して Webサーバへ中継し、 そのレスポンスをブロックに分割してリレーサーバへ送信すればよいことになります。

同じセッションID ごとに連結して Webサーバへ送信する処理が、 reqWeb です:

sub reqWeb {
    my ($id, $req) = @_;
    if (defined $WebHeap{$id} && $WebHeap{$id}->{connected}) {
	$WebHeap{$id}->{server}->put($req);
    } else {
	POE::Component::Client::TCP->new
	    ( RemoteAddress => $WebHost,
	      RemotePort    => $WebPort,
	      Connected     => sub {
		  $WebHeap{$id} = $_[HEAP];
		  $WebHeap{$id}->{server}->put($req);
	      },
	      ServerInput   => sub {
		  $WebHeap{$id} = $_[HEAP];
		  &sendRes($id, $_[ARG0]);
	      },
	      Filter        => POE::Filter::Stream->new(),
	      Disconnected  => sub {
		  &sendControl($id, 0);
	      },
	    );
    }
}

「POE::Component::Client::TCP->new」によって、 Webサーバと通信するための POEセッションを生成しています。 この reqWeb を実行しているのは、 リレーサーバとの通信を受け持つ POEセッションでしたが、 この POEセッションが新たに POEセッションを生成している点に注意してください。

新しく生成した POEセッションは、Webサーバと接続したとき (Connected)、
「$WebHeap{$id}->{server}->put($req);」を実行して リクエスト ($req) を Webサーバに送信します。 そして Webサーバからレスポンスを受信したとき (ServerInput)、 sendRes を実行します。

sub sendRes {
    my ($id, $res) = @_;
    $IdleTimer = $IdleTimerMax;
    if (defined $PollHeap && $PollHeap->{connected}) {
	for my $block (unpack "(a2048)*", $res) {
	    $PollHeap->{server}->
		put(pack("nna*", $id, length($block), $block));
	}
    }
}

sendRes は Webサーバからのレスポンス ($res) を 2048バイトごとに分割し、 セッションID ($id) とデータ長 (length($block)) を付加した ブロックとしてリレーサーバに送信します。

以上をまとめたのが、relayagent スクリプト です。 ここで解説した機能の他、 http リクエストヘッダの Host: フィールドを書き換える機能も追加しています。

C 版の relayagent に比べると、 http レスポンスの書き換え機能や、 http 以外のプロトコルを通す機能などがない点や、 高負荷時の性能の検証が充分行なえていない点など、 そのまま実運用に使用するには難しい点もありそうですが、 少なくとも プロトタイピングなどの目的 (あるいは教育などの目的) ならば 充分使えそうです。

いよいよ就職活動本番ですね。 どのような進路を選ぶにせよ、 あとで後悔することのないよう、 じっくり考えて決めたいものですよね。 でも、ただ単に考えると言っても、 一人であれこれ思い悩むのは感心しません。 「思いて学ばざれば則ち殆し」と言いますから、 ぜひいろいろ見聞きした上で考えて頂きたいと思います。

企業への就職を考える場合、まず気になるのは評価制度のことだと思いますが、 まさにこの評価制度が揺れ動いているのが、いま現在と言えるでしょう。 高度成長期以来、長年用いられてきた年功主義に基づく評価制度の綻びが 誰の目にも明らかになってきてはいるものの、 年功に代わる評価方法を模索し続けているのが 多くの企業の現状だと思います。

どこの企業も新しい人事制度を模索し、成果主義が取り入れられつつありますよね。 （同時にコスト削減という意味合いもありますが）
この成果主義という人事制度ですが、 多分どこの会社でもおおよそこんな感じなのではないでしょうか。
●年初に目標を設定（部署ごとの目標・個人の目標）
●3ヶ月か半年ごとに上司と面談
●成果をアピール
●評価の通知
一見、単なる年功序列よりは凄くまともそうなシステムに見えますよね。 でも、実際には明らかな欠点があると思います。 （評価する側の上司がそもそも年功序列組だという点は除いて）
◆短期間にアピールできるようなものにばかり心奪われるようになる
◆業績アピールに繋がらない日常の雑用や、他人の手伝いは避けるようになる
どちらも当たり前の弊害だと思うのですが、 多くの企業ではこれらの問題について見て見ぬフリをしているのではないでしょうか？

「成果主義と生産性のゆくえ」から引用

ぜひこういった疑問を、どんどん企業にぶつけていって頂きたいと思います。 就職活動というのは、いろんな企業に対して歯に衣着せぬ質問ができる 唯一と言ってもいい機会なのですから。

「評価」には二つの側面があります。 「評価される側」と「評価する側」です。 上に引用した文章は、 「評価される側」にフォーカスした疑問と言えるでしょう。 もちろん学生さんは就職したら評価される側になるので、 「評価される側」から考えたくなるのは当然だと思いますが、 なにごとにも表と裏があります。 片方の側からだけ考えていては考えを深めることはできません。 ぜひ、自分とは異なる立場の視点も持つ習慣を身につけて頂きたいと思います。

「評価」を両方の側から考えてみれば、 「短期間にアピールできるようなものにばかり心奪われるようになる」というのは 評価される側の理屈に過ぎないことは自明ですよね？ つまり暗黙のうちに、 アピールがそのまま通るような「無能な上司」を前提としてしまっています。 もし、「評価する側」が 「業績アピールに繋がらない日常の雑用や、他人の手伝いは避ける」人の 評価を下げるのであれば、 このような弊害を避けることは可能でしょう。

引用した文中に「評価する側の上司がそもそも年功序列組だという点は除いて」と ありますが、 まさにこれこそが問題の本質だと思います。 「除いて」しまっていては考えが深まりません。

どのような人事制度であれ、 「評価する人」と「評価される人」の双方に、 その制度の「精神」が徹底できていなければ機能するはずがありません。 そして、 「評価される人」への徹底は、 そもそも徹底できていなければ評価が下がるので、 否が応にも徹底されるわけですが、 「評価する人」への徹底ができるかどうかは、 「評価する人」を評価する人、つまりその上の上司の責任です。

より具体的に言えば、 「短期間にアピールできるようなもの」「アピールしやすいもの」 ばかりを評価の対象としてしまって、 部下の本当の価値を評価できていない上司を、本当に降格できるのか？ という問題でしょう。 年功主義では過去の功労者が上司となるケースが多いようですが、 過去に成果を上げた人が、 現在の部下の成果を評価できるのか？ という問題であるとも言えますね。

製品には、どうしても長期的な投資が必要なものがあると思います。
例えば日亜化学の青色LEDだって、中村氏が個人で何年もかけて、 会社の中止命令を無視してやり遂げたと著書にありましたし。
もし青色LED開発中に、 3ヶ月ごとに面談していたらどんな評価がされるんでしょう？
失敗続きで亀のようにのろく、先が見えない実験の繰り返しでしょうから、 それらの失敗が将来大きなリターンになって返って来ることを 強く確信している人でなければ、続けられませんよね。

「同ページ」から続けて引用

「技術者の成果」とは何でしょう？

技術者が作ったものから得られる売上でしょうか？ もちろん、それだけではないですよね？ 「青色LED」のように最終的に莫大な利益を生み出したものは、 とても分かりやすい「成果」ですが、 サーバシステムの運用などのような縁の下の力持ちの仕事だって 立派な成果ですし、 さらに、 自分自身では何も生み出さなくても、 社内の技術者を育てることや、 社内の技術をブログなどで発表して会社の知名度を上げることなども、 立派な成果と言えるでしょう。

したがって「3ヶ月ごとの面談」という制度が問題なのではなく、 きちんと技術者を評価できない上司をそのままにしておくのが問題なのです。 そしてそういう上司をそのままにしている上司の上司も問題ですし、 そのまた上の上司の上司の上司にも責任があります。

こうやって責任の連鎖を上へ上へ登っていくと、 技術者の評価制度が機能するか否かは、 技術者の評価について最終的な責任を負う人がいるのか？ という点に行き着くことになります。

技術者を目指す学生のみなさんには、 ぜひこの点 ──この会社では誰が技術者の評価の最終責任を負っているのか？── を押えた就職活動をするようお勧めします。 そしてできれば、「誰が責任者か」だけでなく、 その責任者がどんな考えを持っているのか調べられるものは全て調べ、 さらに疑問点があれば直接会ってでも質問するくらいの勢いで 臨んで欲しいと思います。

La Fonera (FON ソーシャルルータ) って知っていますか？

FONは世界最大のWiFiコミュニティです。 誰もが「世界中どこからでもインターネットに無料で接続したい！」という 望みを持っているはずです。 そのようなメンバーが助け合ってWiFiを広めて行こう！ということを コンセプトに私たちは活動しています。 元々簡単なアイディアで始まったFONコミュニティ。 メンバーが作るWiFiインフラを用いて、 WiFiを世界中のどこからでも楽しめるようにしましょう！。
参加は簡単！FON取り扱い店でLa Foneraを購入して接続してスタートするだけ!

FON 公式ページから引用

La Fonera は、FON のアクセスポイントであると同時に、 普通の (プライベートな) 無線LAN アクセスポイントとしても利用できます。 自宅などで無線LAN アクセスポイントを設置している人は多いと思いますが、 おそらくそのまま La Fonera で置き換えることが可能でしょう。

実際、私はそれまで使ってた 無線LAN ルータ WN-G54/R2 を La Fonera で置き換えてしまいました。 La Fonera が提供する二つのアクセスポイントのうち、 プライベート側を使えば、 自宅LAN に普通にアクセスできて、 いままで使っていた無線LAN ルータに比べて全く遜色ありません。 もちろん WPA2 (Wi-Fi Protected Access 2) 暗号化方式が使えます。

より正確に言うと、 La Fonera のプライベート側アクセスポイント (MyPlace) は、 自宅LAN とは異なるセグメントになります。 有線LAN と無線LAN 相互で自由に通信するためには、 多少の設定変更 (/etc/firewall.user に 2行ほど追加) が必要になります。

私の場合 WPA に対応していない古い無線LAN 端末 (Windows98マシン^^;) も 持っていて、 自宅の無線LAN を WEP から WPA2 に変更した (自宅LAN といえど、WEP を使うのはちょっと抵抗がありますよね？) 時点で、 お蔵入りにしていました。 La Fonera が提供するもう一つのアクセスポイント (パブリック側) を使えば、 直接自宅LAN へはアクセスできないもののインターネットへは接続できるし、 インターネット経由で自宅LAN に戻ってくる (もちろんインターネットからアクセス可能な部分に限定されますが) ことも可能なので、 La Fonera の導入によって古い無線LAN 端末も再び利用できるようになった、 というオマケがつきました。

さて、 この La Fonera で VPN-Warp が利用可能になったらどうなるでしょうか？ 無線LAN ルータが VPN ゲートウェイの機能も持つわけです。 つまりインターネットに接続できる環境ならどこからでも、 自宅LAN へ手軽にアクセスできるようになります。

ここで La Fonera は固定 IP アドレスを持つ必要がないばかりか、 そもそもグローバルアドレスを持つ必要性すらない、 という点がミソです。 必要なことは、La Fonera からインターネットへ接続可能、ということだけです。 La Fonera をどこに設置しようと、 その設置した LAN に外部からアクセスすることができます。

以下は、La Fonera で VPN-Warp を使うようにするための手順です。 現状は多少の Linux の知識が必要となってしまうのですが、 要は relayagent プログラムを La Fonera にインストールするだけのことなので、 適切なインストーラさえ作ればいくらでも簡単な手順になることでしょう。 なので、難しそうだとあきらめるのではなく、 関心がある方はご連絡頂ければと思います。

まず La Fonera に ssh あるいはシリアルコンソールで ログインすることが必要となります。 おそらくこれが最大の難関でしょう (^^;)。

senri:/home/sengoku % ssh fonera
root@fonera's password:


BusyBox v1.1.3 (2006.11.21-19:49+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

 _______  _______  _______
|   ____||       ||   _   |
|   ____||   -   ||  | |  |
|   |    |_______||__| |__|
|___|

 Fonera Firmware (Version 0.7.1 rev 2) -------------
  *
  * Based on OpenWrt - http://openwrt.org
  * Powered by FON - http://www.fon.com
 ---------------------------------------------------
root@OpenWrt:~#

ログインさえ可能なら、あとはさほど難しくはありません。 まずネットワーク経由で La Fonera に relayagent を インストールするための準備をします。 具体的には、 以下のように /etc/ipkg.conf に「src gcd http://www.gcd.org/fonera」 を追加し、 「ipkg update」 を実行します。

root@OpenWrt:~# echo "src gcd http://www.gcd.org/fonera" >> /etc/ipkg.conf
root@OpenWrt:~# ipkg update
Downloading http://download.fon.com/release/fonera/0.7/packages/Packages
Updated list of available packages in /usr/lib/ipkg/lists/fon
Downloading http://www.gcd.org/fonera/Packages
Updated list of available packages in /usr/lib/ipkg/lists/gcd
Done.
root@OpenWrt:~#

http://www.gcd.org/fonera というのは、 私が最近始めた La Fonera 用の ipkg feed です。 つまり、上記のような設定をしておくと、 La Fonera にいろいろなソフトウェアを ネットワーク経由でインストールすることができるようになります。 もちろん ;-) VPN-Warp の relayagent も、 ここからインストールできます。 インストールに必要なコマンドは、 「ipkg install relayagent」だけです。 このコマンドを打ち込むだけで、 relayagent の実行に必要な OpenSSL ライブラリ等が 自動的にインストールされます。

root@OpenWrt:~# ipkg install relayagent
Installing relayagent (1.0.7) to root...
Downloading http://www.gcd.org/fonera/relayagent_1.0.7_mips.ipk
Installing libopenssl (0.9.8d-1) to root...
Downloading http://www.gcd.org/fonera/libopenssl_0.9.8d-1_mips.ipk
Installing zlib (1.2.3-3) to root...
Downloading http://www.gcd.org/fonera/zlib_1.2.3-3_mips.ipk
Configuring libopenssl
Configuring relayagent
Configuring zlib
Done.
root@OpenWrt:~#

次に、VPN-Warp の証明書をインストールします。 BIGLOBE の VPN ワープのページ などから入手した証明書とそのパスワードを記したファイルを、 La Fonera の /etc/warp ディレクトリへコピーしてください。 以下の実行例では relay,5000005.pfx が証明書のファイル、 relay,5000005-pass.txt がパスワードを記したファイルです。 5000005 というのは私が使用している証明書の番号なので、 実際に取得した証明書の番号で読み替えてください。

senri:/home/sengoku % echo "パスワード" > relay,5000005-pass.txt
senri:/home/sengoku % scp -p relay,5000005.pfx relay,5000005-pass.txt fonera:/etc/warp/
root@fonera's password: 
relay,5000005.pfx                             100% 4856     4.7KB/s   00:00
relay,5000005-pass.txt                        100%    9     0.0KB/s   00:00

次が最後の難関で、 VPN-Warp の設定ファイルを作成します。 /etc/warp/relayagent.cfg.sample に設定ファイルのサンプルがあるので、 これを /etc/warp/relayagent.cfg へコピーして、 vi エディタで編集します。

root@OpenWrt:~# cd /etc/warp/
root@OpenWrt:/etc/warp# ls -l
-rw-------    1 root     root            9 Jan  9 04:09 relay,5000005-pass.txt
-rw-------    1 root     root         4856 Jan  9 04:09 relay,5000005.pfx
-rw-r--r--    1 root     root         3290 Jan  9 07:47 relayagent.cfg.sample
root@OpenWrt:/etc/warp# cp relayagent.cfg.sample relayagent.cfg
root@OpenWrt:/etc/warp# vi relayagent.cfg

設定ファイル relayagent.cfg の中に、以下のような部分があるので、
「relay,0000000」の数字の部分を実際に取得した証明書
(私の場合は「relay,5000005」) の番号で置き換えます。

#--------------------------------------------------------------------
#
# -x  PFX 形式 クライアント証明書を指定
# -X  同パスワードファイルを指定
#
#--------------------------------------------------------------------

-x "/etc/warp/relay,0000000.pfx"
-X "/etc/warp/relay,0000000-pass.txt"

以上で設定ファイルの作成が完了しました。 あとは La Fonera を再起動する (裏面のリセットスイッチを押す) だけです。 再起動する代わりに、起動スクリプトを実行することによって relayagent を起動することもできます。

root@OpenWrt:~# /etc/init.d/N50relayagent start
root@OpenWrt:~#

では、ブラウザで https://warp.klab.org へアクセスしてみましょう。 La Fonera にインストールした証明書と同じ証明書、あるいは その子証明書を使ってアクセスしてください。 La Fonera の Web 設定ページが表示されたら成功です。

Web 設定ページが表示されるのは、 先ほど作成した設定ファイル /etc/warp/relayagent.cfg に、

#--------------------------------------------------------------------
#
# <relay サーバ名:ポート番号>  <転送先ホスト名:ポート番号>
#
# ※-p オプション指定時は下記の意味となる
#
# <プロキシサーバ名:ポート番号>　<転送先ホスト名:ポート番号>
#
#--------------------------------------------------------------------

warp.klab.org:443 localhost:80

と書いてあるからです。 「localhost:80」だから La Fonera 内蔵の WWW サーバ (つまり設定ページ) ですね。 「localhost:80」の部分を、 自宅LAN 内の適当なサーバの「アドレス:ポート」で置き換えれば、 そのサーバにアクセスできますし、 通常の VPN-Warp と全く同様に、 任意のサーバに接続するように設定することもできます。

私が大学を卒業したのはバブル (ネットバブルではなく、その前の前世紀のほう) がはじけた年でした。 当時は今ほどベンチャーは一般的ではありませんでしたし、 研究職を目指していた学生 (含む私) が就職先として大企業の研究所を選ぶのは、 ごく普通のことだったのではないかと思います。 終身雇用を信じていたわけでもありませんでしたが、 かといって自分自身が転職することになろうとは、 あまり考えてもいなかったような時代です。 今から振り返ってみれば「就職」というよりは「就社」という感覚に 近かったのだと思います。

その後の「失われた十年 (20年?)」の間に、 年功主義の綻びが誰の目にも明らかになってきて、 大企業以外の就職先を選ぶ人も増えてきましたし、 転職も一般的になってきました。 とはいえ、 就職先の選択肢が広がってきているわりには、 それぞれの企業がどんなところか実態を知ること無く、 なんとなくイメージで決めてしまっている学生さんも多いのではないでしょうか。 最近になって再び「寄らば大樹」的な傾向が復活しつつあるとも聞きます。

どのような進路を選ぶにせよ、 もっと企業の実態を知ってもらった上で決めて欲しいと 思っていたところ、 先日たまたまそういう機会を頂けたので、 学生さん相手のセミナーでお話ししてきました。

私は大企業の研究所に 8年間勤め、 その後ベンチャー (KLab(株), 当時の社名は (株)ケイ・ラボラトリー) の 立ち上げに参加し、順調に規模を拡大し、現在に至っています。 なので、

• 大企業の研究所 (前職)
• スタートアップ (立ち上げ当初のケイ・ラボラトリー)
• 中規模ベンチャー (現在の KLab)

それぞれについて、実地の体験談をお話したわけです。 幸い、ベンチャーについて、もともと興味を持っていた学生さんもいて、 核心をついた (答えにくいとも言う ^^;) 質問もありました。 大企業とベンチャー、 それぞれの実態について理解を深めてもらえたと思っています。

まじめな東大生、悩みすぎ？　３割がニート不安

よく勉強する半面、将来の進路などに思い悩み、 不安や無気力に苦しむ学生が増えている−。 東大が１３日公表した学生生活実態調査で、 こんな東大生の姿が浮かび上がった。
調査は昨秋、学部生約３５００人を対象に実施（回収率３９％）。 ８３％の学生が進路や生き方に悩んでおり、 自分がニートやフリーターになる恐れがあると感じている学生も２８％に上った。

今朝のSankei WEBから引用

悩んでいるより、まずはいろいろな企業の実態について 見聞きしてみて、じっくり将来のことを考えて欲しいと思います。 私でよければ喜んでお話ししますので、 興味あるかたは是非ご連絡下さい。 ただし、企業の実態をできるだけ正確にお話しする、という主旨なので、 対象は (研究者・技術者を目指す) 学生さんに限定させて頂きたいと思います。

参考までに、セミナーで使ったスライドを FlashPaper で Flash 化したもの ↓ を公開します。 このスライド自体は 10ページしかありませんが、 それは「実態」は口頭でお話ししているからです ;-p。 質疑応答が盛り上がったので、2時間近くかかりました。

人月見積りでは生産性が上がらない。 IPA が警告するまでもなく、 ソフトウェア技術者ならば誰しも 人月見積りに嫌悪感を持っているのではないでしょうか。 生産性を上げれば上げるほど金額が低くなってしまうし、 そもそも開発者の生産性なんて人によって大きく異なる (私の持論は、 「ピンとキリでは 1000倍の差がある」、です) のだから、 「標準的な技術者一人が一ヶ月かかる仕事」なんて基準をおいたところで 意味がありません。

人月見積もりについては、 「人月見積もり、生産性について」に いろいろな意見へのリンクがまとめられているので参考になります。 このように人月見積もりがなぜ問題なのか、 それこそ掃いて捨てるほど主張が繰り返されていますから、 いまさら同じようなことを唱えても仕方がありません。 そこで、ここでは逆にあえて肯定してみることにします。

そもそもこれだけ嫌われ者の「人月見積もり」が なぜいまだに行なわれているか、 そこには「人月見積もり」ならではの「良さ」があるからではないでしょうか？

誰にとっての「良さ」か？ それはもちろん見積書を受取る「お客様」にとっての 良さです。 そもそも技術者の仕事なんてのは、 技術のことを知らない「お客様」にとってはよくわかりません。 「この仕事はすごく高度なんだぞーっ」って言われたって、 「ハイそうですか、じゃ沢山お金を払いますね」なんて言ってくれるお客様が いたらぜひお目にかかりたいものです。 ふつうは「どれだけ価値がある仕事なのか、きちんと説明してもらいたい」って 言うでしょう。

じゃ、どうやって説明しましょうか、技術者の仕事の価値を。

お客様にどう説明すれば納得してもらえるか考えるには、 お客様の立場に立つのが一番分かりやすいでしょう。 といっても、我々技術者にとっては、技術者でない人の気持ちを想像するのは ちょっと難しいですよね？ こういうときの常套手段として、立場を逆にして考えてみます。 つまり我々技術者がお客で、 技術者でない相手が何かを我々に売りつけようと見積書を出している 状況を想像します。 売り付けるモノは (コモディティでなければ) 何でもいいんですが、 例えば何かの調査レポートにしましょうか。

相手は、このレポートがいかに創造的で革新的で価値があるものであるか、 必死に説明しようとしています。 が、残念ながら我々はその分野には全く疎いので、 どれだけ価値があるのやら、いまいちピンときません。 そもそも疎いからこそレポートを買おうとしているわけで、 ピンと来ないのは当たり前ですよね？ さあ、どうしましょう？

そのレポートを活用することによって我々の利益がどのくらい増えるのか、 目に見えるのであれば分かりやすいのですが、 あいにくそのレポートが即、利益につながるわけではありません。 確かにそのレポートが役に立つであろうことは間違いない (だから買おうとしている) のですが、 利益増にどのくらい貢献しそうか、というと主観的に判断せざるを得ません。 でもって、主観ということになると、 どうしても他社の仕事より自社の仕事の 利益貢献度合いのほうを高く見積りたくなるものでしょう。

御社のレポートが、弊社のビジネスに大変役立つであろうことは 疑いの余地がないのですが、 もちろんレポートが直接利益を生むわけではなく、 弊社としてもいろいろコストをかけていく必要があるわけでして、 御社がこのレポート作成に多大なコストをかける必要があることは 重々承知しているのですが、 最終的な利益を御社と弊社とでどう配分すべきか、というと なかなか難しいものですね〜 なにかもっとこう客観的な指標はないでしょうか。

と、いいますと？

例えば、このレポート作成に、何人の人が何ヵ月くらいかかりそうか、とか。

KLab 社内には、社内専用の IRC サーバがあります。 IRC (Internet Relay Chat) つまり、 ネットワークリアルタイム会議システムです。 普通の IRC はインターネットに接続できれば、 誰でも使えるのですが、 KLab 社内 IRC は、KLab のイントラネットに接続できる人しか使えません (VPNワープを使って社外からもアクセスできます)。 だから社外秘な内容も流せますし、 社内ミーティングを IRC で済ませてしまうこともよくあります。

社内 IRC が真価を発揮するのは、 コンテンツ提供用の WWW サーバ システム (DSAS) の メンテナンス作業の時など、 多くの人がリアルタイムに状況 (メンテナンス作業の進捗状況) を 共有したいときです。 メンテナンス作業は、 コンテンツ提供サービスに悪影響を与えていないか確認しつつ 慎重に進める必要があるのですが、 それには実作業を行なう人と、 その作業をチェックする人、 そしてコンテンツ提供に悪影響が及んでいないか監視する人など、 沢山の人が進捗状況をリアルタイムに把握する必要があります。

関係者が全員同じフロアにいれば、 大声をあげるだけでも進行状況の「雰囲気」を共有できるでしょうが、 KLab の場合は東京、大阪、福岡のオフィスの他、 SOHO 形態で働いている人もいますし、 DSAS メンテナンスの場合はデータセンタ (東京二ヶ所と九州一ヶ所) にいる人とも 連係しなければなりません。 遠隔地の人と手軽に「雰囲気」を共有する手段として、 社内 IRC はとても便利です。

あまりに便利なので、 技術者の大半が常時 IRC サーバに「常駐」しているのですが、 こうなってくると計画的な作業の連絡用だけでなく、 技術者全員の横のつながりというか、 部署を超えて技術者同士が連係できる共有空間の役割を果たすようになります。 例えば昨晩も...

18:28 (sengoku`) チープ教育 http://cn.ce-lab.net/ja/toshi/archives/2006/08/post_75.html
18:29 (sengoku`) ↑これ、かなり本質をついてる気がするのですが、皆さんはどう思いますか？
18:30 (sengoku`) 私がはじめて出会った PC (当時の呼称はマイコン) は、とてもチープだったんで、自分で作ろう、という気が起きたけど、今の PC 見て、作ってみよう、と思う人はいないよねぇ..

「チープ教育」を読んで、 ぜひみんなに紹介したいと思ったので、 とりあえず社内 IRC に投げてみたわけです。 ほどなく隣の部署の人から反応がありました。

18:34 (koura-h) 細部の作り込みに入ってしまうのって、それはそれで楽しいときもありますけど、苦痛になってしまうことも多いっす。。。
18:35 (koura-h) 制作環境における「チープさ」って、ありがたいと思うす。

続いて、協力会社の人からも...

18:39 (ktaka) ある意味、何でもそうだと
18:39 (ktaka) 思います。
18:40 (ktaka) 自動車でも、
18:40 (ktaka) 楽天のような商売でも
18:41 (ktaka) 物理学者が生物学に入っていって、DNAとかの研究が盛んになり始めた衣
18:41 (ktaka) 頃も
18:42 (ktaka) ショックレイがフェアチャイルド社(?)を始め、Intelができた頃も
18:42 (sengoku`) あはは
18:42 (ktaka) みんな始めは、
18:42 (ktaka) ある意味、やればできそうという感覚があったんでしょうね
18:43 (sengoku`) ですよね〜
18:43 (sengoku`) 「へぼくても許される感」って重要ですね〜

反応してない人も、この会話の流れを見てはいるわけで、 技術者同士、考え方を共有することはとても重要なことだと思います。 もちろん社内には情報共有の方法としてメーリングリストも多数あるのですが、 なんでも気楽に書込めるという敷居の低さで、 IRC のほうが勝っていると思います。

18:43 (uchikawa-) itronのコードでも弄ってみますか(秋月のボードで自力で動かすというのはやったことあります)
18:43 (sengoku`) 逆に言うと、へぼが許されないような雰囲気のとき、どうやって「無意味なポジティブさ」を学ぶか意識しないと、ってことですね。
18:44 (sengoku`) まあ、遠慮せずにどんどんやれ、ってことなんですけど、
18:44 (ktaka) 私は、そもそも、参入しないと言うのもありかな、と思っています
18:44 (sengoku`) なかなかポジティブになったことの無い人にそれをやれ、ってのは難しいのかもしれませんね。
18:45 (sengoku`) もちろん、参入しない、という選択肢があるときはそれでもいいんですが、
18:45 (ktaka) 高度に専門家されたことを大きな組織でやるよりも、
18:45 (sengoku`) コンピュータ技術者、って道を選択してしまった人に、いまさら他の道を探せ、ってのも酷でしょうから... ;-)
18:46 (ktaka) 一時代を築く可能性がある、チープなものに出会えれば。。。
18:46 (ktaka) でも
18:46 (ktaka) 一口にコンピューター技術者といっても、いろいろあって
18:47 (ktaka) 昔は、ボードの設計からできそう、だったのが、
18:48 (sengoku`) (いまでも、ちゃちな PC ならボードから設計できるんですけどね、実は)
18:48 (ktaka) 今は、Youtube見たいなの作れそう、っていうのがあるとおもいますので
18:49 (ktaka) おお、すごいですね〜
18:49 (sengoku`) ようは、ポジティブになれるかどうかが、勝負を分けることになるんじゃないかと...
18:49 (ktaka) チープなフェーズにある、面白そうなものって言うのは、いろんなところにあるんではないかと
18:49 (sengoku`) まあ、そういう話は、
18:50 (katsumiD) ( つhttp://journal.mycom.co.jp/column/architecture/037/
18:50 (sengoku`) プログラマを目指すのに適した時代、適していない時代 http://blog.gcd.org/archives/50546204.html ってことに
18:50 (sengoku`) 続くのかな。
18:50 (katsumiD) ちなみに，
18:51 (katsumiD) 今だと CPU を作ろうと思った場合，FPGA とかで作れますが
18:51 (katsumiD) そういうことをしようと思った場合のハードルが，昔に比べて下がっている，と言うのもあるように思いますです
18:52 (ktaka) 確かにそうだと思います>適していない時代
18:52 (sengoku`) いや、あるんですが、ようはそれを自分でやろうという気持ちを起こせるかどうか、ってことだと思います。
18:52 (ktaka) 確かにそうだと思います>CPUを作るハードル
18:52 (sengoku`) 技術的な障壁は確実に下がってるんですが、心理的な障壁は、逆にあがってるかも知れませんねぇ
18:53 (katsumiD) なるほど

若干、会話が錯綜気味で読みにくくなってしまっていますが、 それが逆に、 考えがまとまっていなくてもとりあえず書いてしまえ、 という気楽さにつながっているのでしょう。 メールだと、論旨をはっきりさせて書かねば、という気持ちになりますから、 思ったことをそのままぶつけられる IRC のような場も必要だと思います。

ちなみに、会話に参加している 5人のうち、 4人は声の届く範囲にいたりする (^^;) のですが、 ひざ突き合わせて話そうとすると仕事を中断して集まらなければなりませんし、 大声を出すと会話に興味がない人に迷惑ですし、 URL を伝えるときなどは声よりチャットの方がむしろ便利ですし、 また、IRC だとログが残るので後で参照することもできます。

なお、「プログラマを目指すのに適した時代、適していない時代」に言及したのですが、 どちらかというと「ロングテール戦略が格差社会を生む: 必要は発明の母」のほうが話の流れに近かったかも知れません。 要は、不足感がないと何かをやろうという気力が出てこない、 ということが言いたかったわけです。

18:53 (uchikawa-) 昔だったら「自分で作ったほうが世の中にあるものよりいいものになる」だったですからね
18:54 (sengoku`) 世の中にもっといいものがある、からといって遠慮する必要はないんですけどねぇ、ほんとうは。
18:54 (katsumiD) でも，実は心理障壁を乗り越える人はいつの時代だって乗り越えるし，乗り越えない人はいつだって乗り越えない，というのも，
18:54 (katsumiD) http://www.chiaki.cc/Timpy/index.htm
18:54 (katsumiD) こういうサイトを見ていると思ったりもします
18:54 (katsumiD) (こういうのを見ると，むしょうに自分でも何かをしたくなり出します(^^
18:55 (sengoku`) ぜひぜひ
18:55 (katsumiD) ちなみに，今の時代だと，2足歩行ロボットとか，結構盛り上がってますよね
18:56 (katsumiD) ちょっと前は，2足歩行どころか，普通のロボットでも作る機運ってのは無かったですが
18:56 (ktaka) 私的には、やっぱり、WEBやネットワークがチープなフェーズにあるのではないかと思います
18:57 (katsumiD) 色んな製作記事とかキットが出始めたこととかもあって，アマチュアの人が一杯やってらっしゃいますね
18:57 (sengoku`) まあ、どんな分野でもいいんで、ぜひチャレンジして〜と。

収拾がつかなくなってきたんで、ちょっと投げやりになっています ＞ 私 (^^;)

18:57 (katsumiD) (^^
18:57 (ktaka) なるほど
18:57 (ktaka) >ロボット
18:57 (ktaka) 二足歩行のおもちゃ変えますもんね
18:57 (ktaka) 買えますもんね
18:58 (sengoku`) Web が普及して一番困ったことは、誰もが批評家になっちゃって、自分ではやろうとしなくなったことなのではないかと...
18:58 (ktaka) そうなんですか
18:59 (ktaka) 何でも自分でやる技術者の世界に、批評家が入り込んできたという意味ですか？
18:59 (sengoku`) なんでも web 見れば載ってるんで、
19:00 (sengoku`) 自分でやらずに、自分でやってるような気分になっちゃう
19:00 (sengoku`) 見るのとやるのとでは大違いなのに、たいてーの人は見るだけで満足しちゃうんじゃないかと...

うっかり「批評家」と言ってしまって意図が通じにくくなってしまいましたが、 誤解されてもすぐ補足説明できるのが IRC のいいところですね。 「自分で実行しないで他者の行為をあれこれ言う者」という意味で使ったのですが、 「批評家」ではなく「評論家」と表現すべきでした。

19:01 (katsumiD) あぁ，それはあるかもですねぇ・・・
19:01 (katsumiD) 変な事をしてる人は一杯いて，それをいろいろ満てるだけでお腹いっぱいになってるとか・・・
19:02 (sengoku`) そういう傾向はあるんじゃないかなぁ〜
19:02 (sengoku`) すでにやってる人がいるから、わざわざ自分でやらなくても、って
19:03 (sengoku`) 思っちゃうんじゃないかなぁ
19:03 (sengoku`) やってみれば、新しい発見があるかもしれないのにね。
19:04 (koura-h) それは分かりますね＞わざわざ自分で〜
19:05 (koura-h) 何かしりごみするっていうのか、既に誰か手を付けてると後から追いかける意欲が薄れるというか。

ようやく思った通りの結論にたどり着きました (^^)。

19:08 (koura-h) 例えばCPANなんかで、「これ自分で作ったんだけど登録してみよー」とか思っても大抵既に誰かがのっけてたりして、そういうのに何個か当たってしまうとそのしりごみの気持ちが強まってしまうっすね。。。
19:11 (ktaka) なるほど
19:12 (ktaka) >CPAN
19:12 (koura-h) (って打ってたら仙石さんが帰られていったorz

あはは。

先週末、 未踏ソフトウェア創造事業の集会 ESPer2006 秋の陣 でプレゼンしました。 KLab(株)の黎明期に、いかに未踏事業の支援が助けになったか、 そして 5 人でスタートした KLab が 160人を超える会社に発展した過程を紹介しつつ、 私がそこから学んだことなどをお話ししました。 これからベンチャーを立ち上げよう、 そして発展させようとしている技術者の方々の参考になれば幸いです。

使ったスライドを公開します。 25分の持ち時間なので、スライド 21ページくらいは話せるかなと思っていたら、 調子に乗って喋りすぎ、大幅に時間を超過してしまいました。 ゴメンナサイ。 後半かなり早口になってしまい、一番言いたかった 「技術者の地位を向上させるには、 技術者以外の視点にも立ってみて、 技術者自身が視野を広げていかなければならない」 という主旨が、果たしてどこまで伝えられたかちょっと不安に思っています。

私のプレゼン手法は OHP (OverHead Projector) 時代に身につけたもので 1ページあたり 1分以上話すのが普通なのでした。 もう少し内容を絞り込めばよかったと反省しております (これでも、イイタイコトを大幅に削って 流れを単純化したつもりだったのですが... ^^;)。 でも、私の 21ページというのはかなり少ない方で、 多い人だと 100ページを超えていましたね (25分間なのに!)。 OHP 時代は、1ページ数秒しか見せないなんてことはありえなかったわけで、 いろいろなプレゼン手法があるものだと、とても参考になりました。

また懇親会や二次会 (残念ながら三次会は終電が気になってしまって参加できませんでしたが) で、沢山の方々とお話しすることができて とても有意義な時間をすごすことができました。 このような場を準備運営してくださった事務局の方々に感謝します。 ありがとうございました & お疲れ様でした。

スライドを PDF 化したものと、 FlashPaper を使って Flash 化したもの ↓ を公開します。

ご存じの方も多いと思いますが、 情報処理推進機構(IPA)が実施している個人支援事業に、 未踏ソフトウェア創造事業 (Exploratory Software Project) があります。 私自身、第一回め(2000年)に 「携帯電話用アプレット開発ツール」を採択いただき、 超優秀な学生さん二人と共に、 Java と文法レベルで互換のコンパイラ&VM (Virtual Machine) を開発しました。 テーマ概要から引用:

携帯電話上で走らせるJavaプログラムは， サイズが小さいことが第一の条件である． しかし，Javaは元々 PCなど比較的リソース制限が緩いコンピュータ上で走らせることを想定していたため， 小さいプログラムを書くには特殊なテクニックが必要となる． つまり，一般のプログラマには敷居が高すぎ， このままでは携帯電話のJavaコンテンツの発展を阻害する恐れがある．

そこで，携帯電話上で動作するプログラムを開発するための コンパイラなどの開発を提案する． このコンパイラが生成するプログラムは， 同機能を持つ携帯電話上の通常のJavaプログラムの 1/10以下のサイズ (目標値) であり， 現状の携帯電話網においても無理なくダウンロードすることができる．

携帯電話がどんどん高機能化し、 当時のPC よりよほどパワフルになってしまった現在から見ると、 遠い昔の話のようです(^^;)。 採択・支援いただいた PM (プロジェクトマネージャ) の指摘:

現地ヒアリングのときに聞いた携帯電話上のJavaリソース制限の 技術的あるいは政策的な厳しさ (例えば，一つのiアプリのコードは10Kバイト以下に抑えないといけない) は， マウスイヤーの今日どれくらいの期間意味をもつのだろうか． このプロジェクトはこういったことに若干振り回されてしまったような印象もあるが， 得られたKamiyaシリーズの技術自体は， 携帯電話のモデルチェンジ周期より長い生命をもつであろう． 特にダイナミックリンクが要らないという見切りは 典型的なアプリケーションに対してある程度の汎用性があると思われる．

は、実に的確でした。 携帯電話があっという間に高機能化してしまって 成果物の製品化は実現しなかったのですが、 KLab株式会社 (当時の社名は、株式会社ケイ・ラボラトリー) の 創業期に技術会社としての基礎をどう築くか模索していた私にとって、 この開発プロジェクトは大きな意味を持ちました。

そんなわけで、KLab株式会社の黎明期に、 いかに未踏事業の支援が助けになったか、 機会あれば発表したいと思っていたところ、 「未踏」集会 ESPer2006 秋の陣 で 何かプレゼンしないか、とお誘い頂き、 一も二もなく引き受けました。

ESPer2006 秋の陣

日時　2006年11月25日（土）
　　　13：00開場、13：20開始、18：00頃まで
　　　その後 懇親会を行いますので、是非ご参加ください
会場　神戸国際会議場　国際会議室

定員　最大240名まで

プログラム・企画と登壇者
　　　　IPAより、事業の紹介等
　　　　ＰＭ談議（仮称）
　　　　仙石 浩明氏
　　　　尾藤 正人氏
　　　　平林 幹雄氏
　　　　森 悠紀氏
　　　　油井 誠氏

2000年8月に 5人でスタートしたベンチャーが、 160人を超える会社 (2006年11月現在) に成長した、 その発展秘話(?) を、 未踏事業に採択された一技術者 (つまり私) の視点からお話ししたいと思います。 経営者の視点で書かれた会社発展物語はあまたあれど、 技術者の視点というのは、そんなに多くはないと思います (ってまだどんな話にまとめようか、まとめきっていませんが... 25日までに間に合うかな ^^;)。 自身の技術を起業につなげたい、 それも、十数人の規模ではなく、 100人あるいはそれを超える規模を目指したい、 と思っている方々の参考になれば幸いです。

会場にはまだ余裕があるようですから、 興味あるかたは 予約申込み の上、 ご参集下さい。 懇親会もあるようですから、読者の皆様とお会いするのを楽しみにしております。

何をいまさら、という声が聞こえてきそうですが、 社内からの情報漏洩が問題となっている今だからこそ、 あらためて社内情報を扱うサーバを、 社内LAN に置くことの重要性を訴えたいと思います。

もともと、グループウェアといえば社内のサーバに置くのが当たり前だったのですが、 いろいろな情報がグループウェアに蓄積されるにつれ、 社内からだけでなく、社外にいるときもグループウェアにアクセスしたい、 というニーズが高まってきました。

グループウェアを社外からも利用するには、 サーバをどこに置くかで分類すると、 次の 3 通りの方法があります。

1. 社内LAN に置く
   ファイアウォールに穴をあけて社内のサーバへアクセスできるようにするか、 あるいは VPN などの方法で社内からのアクセスを社内へ導く方法です。 正規のアクセス以外の、招かざる客を確実に排除できなければなりません。
2. DMZ 上に置く
   社外からもアクセスできる非武装地帯 (DMZ) にサーバを置く方法です。 ファイアウォールで守られない場所に置くのですから、 サーバは自分自身を守ることができなければなりません。
3. 社外に置く
   他社が提供するグループウェアASP サービスを利用する方法です。 情報管理を他人任せにできるので一番手間がかかりませんが、 万一情報漏洩が起きたときに誰が責任をどうやって取るのか、 契約等ではっきり決めておかないとトラブルの種となるでしょう。

いずれも一長一短があるので、いちがいにどれがいいとは言えませんが、 それぞれどのようなリスクがあるかきちんと把握した上で利用することが重要ですね。

手軽さだけで言えば、もちろん 方法3 が一番簡単なのですが、 手軽なだけにリスク管理が出来ていない人が利用すると、 情報のダダ漏れが起きます。

【警告】Googleカレンダーで情報流出？ から引用:

無防備な人が多いには驚きます。 Googleカレンダーで、 まるでソーシャルブックマークみたいに公開設定をしている人が何人もいます。 実に詳細な仕事のスケジュールが公の場にさらされており

ということも実際に起きているようです。

じゃ、公開設定しなければ安心か、というとそうとも言えません。 別に ASP サービスを提供している会社を信用しないわけではないのですが、 サーバに情報をため込めば、サーバの運用管理を行なう過程で、 どうしたってその情報が漏れるリスクはあります。 万一漏れたときに ASP サービス提供会社がどう責任をとってくれるのか、 確認しておきたいところです。

他人任せにするのは、どうも気持ち悪い、という場合は 方法1 あるいは 方法2 を選択することになります。 方法2 は、ASP サービス提供会社が行なっているのと同等のことを 自社で行なうイメージですね。 自社で運用するので、情報漏洩が起きたときの責任の所在ははっきりしていて いいのですが、 どうやって外部からの攻撃を防ぐかが問題となります。

インターネット上でサーバを安全に運用することが困難だからこそ、 各種 ASP サービスが提供されているわけで、 きちんとしたサーバ運用管理体制を整えずに運用したりすると、 あらゆる攻撃を受けて侵入されてしまうかも知れません。 また、サーバそのものは運用できていても、 グループウェアの側に脆弱性があって、漏洩事故が起きてしまうケースもあります。 そもそも、きちんとサーバを運用できるだけの体制を整えられるのなら、 ASP サービスの提供側になったほうがよさそうです。

と、いうわけで結論は、方法1 の「グループウェア・サーバを社内に置こう！」です。 この方法のいいところは、社内で使っているグループウェア・サーバを、 変更なしにそのまま使えるという点で、 気をつけなければならないのは、正規のアクセス以外の不正侵入を どうやって確実に排除するか、という点です。

社内で使っているグループウェア・サーバをそのまま使うわけですから、 何らかの脆弱性があることを前提としなければなりません。 脆弱性がないなら DMZ に出しておけるわけで、 社内に置く最大のメリットは、多少の脆弱性は許容できるという点にあります。 だから、 正規ユーザ以外からのアクセスは決して、 社内サーバに到達できないようにしなければなりません。

では、どうやって不正アクセスを排除すればいいのでしょうか？ ファイアウォールに穴を開ける方法にせよ、 VPN を使う方法にせよ、 何らかの「入口」を設置して、 そこで正規アクセスと不正アクセスを選別することになりますが、 この「入口」を適切に運用管理することは結構大変です。 不正アクセスを試みる人は、なんとかこの「入口」をだまして 通ろうとするわけで、 「入口」をきちんと運用管理する体制を整えなければなりません。

あれ？ 結局これでは 方法2 と同じですね？

そこで、「VPNワープ」です (我田引水... ^^;)。 VPNワープは、この「入口」を提供する ASP サービスなんです。 グループウェア・サーバ自体は社内に置いて情報漏洩のリスクを抑えつつ (方法1 の長所)、 「入口」の運用管理だけ他社 (つまり KLab) 任せにして手軽さも確保する (方法3 の長所)、 方法1 と 方法3 のいいとこどりの「入口ASP」、それが VPNワープです。

今月末まで無料スタートキャンペーン中ですので、 ぜひこの「入口ASP」をお試し下さい。 BIGLOBE会員のかたは、「エージェント」と「SSL証明書」を ダウンロードするだけで利用できますし、 BIGLOBE会員でないかたも、 初期費用・月額費用が無料の 「コンテンツ」コースに入会すれば、 すぐ VPNワープをお試し頂くことが可能です。

「技術をウリにする会社は、その立ち上げメンバに三種類の人種が含まれていることが必須なのだと思います」と以前書いたのですが、 「人種」が異なる人が出会う事って、 実はかなり稀な現象なのではないかという気がしています。

先日、某大学へ遊びに行く機会があったのですが、 日頃ベンチャーの中ではあまり感じることがなかった 「人種の近さ」のようなシンパシーを 感じてしまいました。 そういえば、私の大学時代の友人には、 大学に残って学究の道を進み、 教授や助教授にまで上り詰めた人が少なくありません。 大学に残らず大企業の研究所などに就職した人もいるのですが、 いつのまにか ;-) 大学に戻っていたりします。

彼らの大半は、私なんぞよりはるかに頭がよく、 その能力をベンチャー発展のために使ってもらえたら、 日本のベンチャーはもっと活気付くのにと、 つい思ってしまうのですが、 彼らの興味がベンチャーに向くことが稀なのだから仕方ありません。

つまり、大学志向の人とベンチャーを興そうという人とでは、 興味の対象が異なるのです。 日本の大学でインターネットの研究が盛んだったのは '80年代の終わりごろです。 インターネット黎明期と呼ばれる頃ですね。 日本を代表するような大企業の研究所では、 当時からインターネットに注目していましたが、 ビジネス的にはまだ海のものとも山のものとも分からず、 ましてこれから起業しようとする人たちが興味を持つような 代物ではありませんでした。

1992年ごろにインターネットの商用利用がはじまりましたが、 インターネットでベンチャーを興してみようと思う人たちが現れたのは、 1994年ころからです。翌年 1995年はインターネット元年と呼ばれていますね。 ところが大学では、 1992年ころまでにインターネットは すっかり日常生活の一部となってしまっていました。 いまさらインターネットで何をするんだ、と思ってしまっていた人も 多かったのではないでしょうか。 今となっては先見の明の無さを恥じるばかりですが、 私自身 1992年ごろには、インターネットにはもはや技術的に新しいことは 何も残ってはいないと思っていました。

ところが、みなさんもご存じの通り、ベンチャーにとってインターネットは '90年代終わりになってからが本番で、 2000年のネットバブル崩壊をものともせず、 数多くのベンチャーが果敢に挑戦を続けています。

学問的に盛り上がってしばらくして下火になる頃から、 それがビジネスの種になりベンチャーが盛り上がる、 こういう順番になるのは当たり前と言えば当たり前すぎるのですが、 こうした時間のずれが、 学問の世界の人たちと ベンチャーの世界の人たちが 出会う機会を減らしているのでしょう。

そんな中、2001年に始まったケータイJAVA は、 学問志向の人とベンチャー志向の人が同時に関心を寄せた、 数少ない例外の一つだったのではないでしょうか。 当時私はベンチャーに対しては何の興味もなかったのですが、 ケータイでユーザプログラムを動かすことができれば、 何か面白そうなことができそうだと思っていました。 一方この年は、iモードの成功が誰の目にも明確になった年で、 ケータイJAVA は iモードの可能性をさらに広げてくれるものとして、 多くのベンチャーが大変な関心を寄せました。

そうして、ベンチャー志向の人と、大学志向の人との出会いが数多く生まれました。 あれから 6年たった今、 こうした出会いを産み出す共通の関心事には何があるでしょうか？

昨日、NECビッグローブ株式会社と 共同で、BIGLOBE法人会員および個人会員向けに 「VPNワープ」の提供を 開始しました。 これまで VPN-Warp 入門編 6回、応用編 3回を書き綴ってきましたが、 「VPNワープ」サービス 開始により、 より多くの方に手軽に VPN-Warp を使って頂けるようになったと思います。

なお BIGLOBE会員でないかたも 初期費用・月額費用が無料の 「コンテンツ」コースに入会すれば、 VPNワープをご利用頂くことが可能です。

「設定10分ですぐ使える SSL VPN」を目指して、 「VPNワープ」で提供するリレー・エージェントは、 relayagent フリーダウンロード で公開しているものより、 さらに簡単な「簡易インストール方式」を採用しています。 10分で設定できるかは、もちろん個人差があるとは思いますが (^^;)、

1. VPNワープのページの 管理者メニューの「購入」を選ぶ
   (現在、無料スタートキャンペーン実施中につき、10月末まで無料)
   指示にしたがって進んでいくと、 証明書 relay,4000017.pfx (数字の部分はユーザごとに異なります) が ダウンロードできるので、これをダブルクリックしてインポートする
2. 「リレー・エージェント」インストール用プログラムをダウンロード
   このプログラム VPN-Warp_RelayAgent_Setup_Biglobe.exe をダブルクリックすると 「VPN ワープ relay エージェント(Biglobe版)」ウィザードが開くので、 以下のように、ウィザードの指示に従って必要項目を入力していく
   • イントラネットの Web サーバをアクセスするときの URL のサーバ名部分 (例えばトップページのURLが「http://intra/index.html」であれば「intra」) を入力
   • 証明書ストア内の証明書の一覧が表示されるので、 その中から 1. でインポートした証明書 (上述の例では relay,4000017) を 選択する
   • Windows にログオンするときのパスワードを入力 (リレー・エージェントが証明書ストアにアクセスする際、 ユーザ権限で Windows にログオンする必要があるため)
   • 「インストール」ボタンを押すと、インストールが行なわれ、 「relay エージェントサービスを開始しますか?」という 問合わせが表示されるので「はい」を押す

これだけで、証明書をインポートずみの PC であれば、ブラウザから
「https://biglobe.klab.org/」へアクセスするだけで
イントラネットの Web サーバにアクセスすることができるようになります。

「VPNワープ」で提供するリレー・エージェントも、 本ブログ上で公開している relay agent も、 相互に互換性がありますので、 「VPN ワープ」にて本ブログ上で公開している relay agent を使うことも可能です。 ただしこの場合、BIGLOBE への問い合わせはご遠慮下さい。 本 VPN-Warp ブログで公開している relay agent は、 本ブログの読者のかた限定で公開しているものであり、 この relay agent を使った際に生じた問題等は、 本ブログに対するコメント等で問い合わせて頂きたいと思います。

• 入門編 (1) VPN-Warp の特長: ふつうの SSL VPN と比べて
• 入門編 (2) VPN-Warp の特長: ssh のポートフォワードと比べて
• 入門編 (3) stone & relayagent の設定方法
• 入門編 (4) stone の代わりに OpenSSL の s_client を使ってみる
• 入門編 (5) stone の代わりに普通の WWW ブラウザを使ってみる
• 入門編 (6) WWW ブラウザを使う場合の注意点

• VPN-Warp relayagent フリー ダウンロード
• 応用編 (1) VPN-Warp 試用ライセンス提供開始のお知らせ
• 応用編 (2) 盗まれたノートPC を外部から操作する方法
• 応用編 (3) イントラの「ファイル共有」を社外からアクセスする方法

ピーターの法則って知ってますか？ ウィキペディアから引用すると:

1. 能力主義の階層社会に於いて、人間は能力の極限まで出世する。 すると有能な平構成員も無能な中間管理職になる。
2. 時が経つに連れて人間は悉く出世していく。 無能な平構成員はそのまま平構成員の地位に落ち着き、 有能な平構成員は無能な中間管理職の地位に落ち着く。 その結果、各階層は無能な人間で埋め尽くされる。
3. その組織の仕事は、まだ出世の余地のある、 無能に達していない人間によって遂行される。

確かに自分の能力を超える地位まで登ってしまうと、 能力が発揮できなくなってしまう、というのはありそうな話です。 地位が上がって無能扱いされるくらいなら、 同じ地位に留まって「有能」であり続けるほうがマシというものです。 特に、 成果主義が浸透しつつある昨今、 「無能に達する」ことは大変なリスクを伴います。 そんなリスキーな出世より、 特定の仕事を極めてスペシャリストになることを選ぶ、 という人のほうが多数派なのかもしれませんね。

しかしながら、 同じ仕事が同じ価値を持ち続けるかどうかは、 時と場合によります。 職人技が価値を生む分野であれば、 一つの「技」に一生をかける価値があるでしょう。 例えば、従来日本が得意としてきた「モノ作り」の分野ですね。 熟練工の「技」は、 機械には真似ができないという価値を持っていました。

では、我らが「ソフトウェア開発」はどうでしょうか？ 「ソフトウェア開発はモノ作りではない」ので、 モノ作りのアナロジーで考えていると大きく価値判断を誤ります。 ソフトウェア開発においては、モノ作りと違って、 熟練自体は価値を生まないからです。 10年の経験を積んだプログラマが、 プログラミングを始めて 1ヶ月の新人に負かされる、などということが 起り得るのがソフトウェア開発でしょう。

一つの仕事に一生を賭けようとするなら、 自身の能力のうち普遍的な価値を持つのはどんな能力なのか？ 他の人には真似ができない自分ならではの良さとは、どんなことなのか？ 自問し続けることが重要だと思います。

一つの仕事に一生を賭けるのではなく、 仕事を変え、自分を変えていく、という道もあります。 単に仕事が変わる (例えば昇進する) だけでは、 ピーターの法則通り、いずれ無能に達してしまいますから、 この道を選ぶにあたっては自分を変えることが必須です。

つまり受け身の昇進ではなく、 積極的に今の仕事を捨てるべきでしょう。 部下 (or 後輩) が成長してきて、 自分の代わりがつとまるようになったら、 全てその部下に任せてしまい、 新しいことにチャレンジするわけです。 そうすれば部下も育つし、 自分を変えることができます。 運がよければ新たな成長フェーズに入れるかもしれません。

だいぶ間があいてしまいました (^^;) が、 VPN-Warp の応用例の第二回目を、お送りします。 前回は、「盗まれたノートPC を外部から操作する方法」という、 やや特殊な例だったので、 今回は、とてもオーソドックスに、 イントラの Windows マシンの「ファイル共有」を、 社外から利用できるようにする方法の紹介です。

その前に... そもそも Windows のファイル共有とは何なのか？を、 おさえておく必要があります。 といっても「Microsoft ネットワーク」は 仕様が完全に公開されているわけではありませんし、 過去のしがらみで無暗に複雑になってしまっているプロトコルなので、 深入りはしません (^^;)。 詳しく知りたい方は、

アンドキュメンテッドMicrosoftネットワーク
誰も知らなかった「ネットワークコンピュータ」の秘密
高橋基信 著, 翔泳社 (2002/06)

などを参照してください。

CIFS (Common Internet File System)

当初は TCP/IP とは似ても似つかない独自プロトコルとして始まった Microsoft ネットワークも、 TCP/IP がネットワークの事実上の標準になるに従って、 しだいに TCP/IP に適合するように変化してきました。 まず NetBIOS が TCP/IP の上で動くようになり (NetBIOS over TCP/IP, 略して NBT と呼ばれる)、 さらに TCP/IP に馴染まない点を整理して、 フツーの TCP/IP 上のプロトコルっぽくなったのが CIFS (Common Internet File System) です。

CIFS は NetBIOS名でコンピュータが指定できるなど、 TCP/IP の世界とは相容れない点がまだ残っているものの、 NetBIOS名を使わずに 「ホスト名」や「IP アドレス」でコンピュータを 指定することもできるので、だいぶ使いやすくなりました。 「ネットワーク コンピュータ」でコンピュータ名が表示されない (ブラウズ リストに含まれていない) コンピュータでも、 「\\192.168.1.1」などと指定してアクセスすることができるように なったわけです。

NetBIOS名の名前解決 (つまり、コンピュータ名からマシンを特定する方法ですね) には UDP/TCP 137番および UDP/TCP 138番が使われますが、 これを省略して、ファイル共有サーバの TCP 139番ポートへアクセスするだけでも、 ファイル共有を行なうことができます。 この TCP 139番ポートへのアクセスは、 SMB (Server Message Block) セッションと呼ばれます。

「VPN-Warp 入門編 (3)」で説明したのと全く同様の方法で、 ローカルホストの 139番ポートを、 リモートホストの 139番ポートへ転送するようにしておけば、 ローカルホストの 139番ポートへ接続するだけで、 リモートホストへ SMB セッションを確立することができて、 ファイル共有が可能になる、というわけです。

ローカルホスト         リレー           リモートホスト
    stone ─────→ サーバ ←──── relayagent─→ ネットワーク アダプタ
   139番ポート …………………………………………………→ 139番ポート

転送先の「ネットワーク アダプタ」は、 ファイル共有サービスを行なっている IP アドレスを指定します。 後述するように 139番ポートのサービスは、 アダプタごとに有効/無効を指定できるので、 有効になっているアダプタを指定する必要があります。

Direct Hosting of SMB (Server Message Block)

Windows 2000 以降だと、 NetBIOS 名の解決を行なわない 「Direct Hosting of SMB」 というプロトコルも使えます。 TCP/IP で名前解決 (つまり、ホスト名から IPアドレスを求める方法) を行ない、 ファイル共有サーバの TCP 445番ポートへ接続して 即 SMB セッションを確立します。

「Microsoft ネットワーク」が理解しにくいプロトコルであった一因は NetBIOS と SMB が一体化していたことにあったわけで、 NetBIOS を必要としない SMB の登場は、 SMB が何であったかを明確化する意味も持っていたように思います。

話が脱線しますが、ふつう何かの複雑なシステムを作るときは、 単純なものから始めて、それらを一般化して標準技術として確立した上で、 それらを組合わせて複雑なシステムを構築していくものだと思いますし、 インターネットはそのようにして発展してきました。 「Microsoft ネットワーク」は逆の方向に発展 (つまり退化？ ;) したのでしょうか？ このような最初に唐突に複雑なものが登場する傾向は、 Windows に限らず他のプロプライエタリなソフトウェアに共通してみられる 傾向のようにも思われます。

「NetBIOS over TCP/IP を無効にする」設定

Windows XP 等で、 「ネットワーク接続」の各アダプタのプロパティの中の、 「インターネット プロトコル (TCP/IP)」のプロパティにて、 「詳細設定」を選択すると、 WINS タブの中に、 この「NetBIOS over TCP/IP を無効にする」という設定があります。

この設定 (以下、「NBT を無効にする」と略記) はどういう意味でしょうか？ 実は、 「このアダプタにおいて『NetBIOS 付 SMB』サービスを行なわない」 という意味です。 「NetBIOS over TCP/IP」という表現で「SMBサービス」を指すのは 分かりにくいと思うのですが、それはサテオキ この設定を行なうと、 「NetBIOS 付 SMB」すなわち 137, 138番ポートと TCP 139番ポートを 使用しなくなります (つまり listen しなくなる)。

VPN-Warp で 139番ポートを転送するには、 139番ポートを空けておかねばなりませんから、 いずれかのアダプタでこの「NBTを無効にする」設定を行なう必要があります。 ファイル共有サービスを外部へ提供しない PC (ノートPC などでは安全のためにも共有サービスは提供すべきではないでしょう) ならば、 どのアダプタの NBTを無効にしても問題なさそうに見えますが、 「メイン」のアダプタ (正確に言えばデフォルトルートになっているアダプタ) の NBT を無効にすると、 SMB サービスへアクセスするクライアント機能まで無効にされてしまうので 注意が必要です。

「Microsoft ネットワーク」が分かりにくい理由の一つに、 「クライアント」と「サーバ」の機能がきちんと区別されていない、 という点もあるのではないかと思います。 「NBTを無効にする」という表現では、 SMB サービスを利用するクライアント機能を無効にするのか、 SMB サービスを提供するサーバ機能を無効にするのか判然としませんよね？ 実際には「クライアント機能」も「サーバ機能」も 同時に無効にされてしまうので、 確かに表現としては間違いではないのですが...

クライアント機能まで無効にされては、 なんのために VPN-Warp で 139番をポートフォワードするのか分からなくなるので、 NBT を無効にする専用のアダプタを (メインのアダプタとは別に) 追加するのがよいでしょう。

まず 「コントロールパネル」から「ハードウェアの追加」を選び、 「新しいハードウェア デバイスの追加」をクリックして、 「一覧から選択したハードウェアをインストール」を選びます。

そして「ネットワーク アダプタ」の中から、 「Microsoft Loopback Adapter」を追加インストールします。 インストールした Loopback Adapter の「TCP/IP 詳細設定」を開くと、 「IP アドレスを自動的に取得する」がデフォルトになっていますが、 ループバックに DHCP サーバを走らせても仕方がないので、 「次の IP アドレスを使う」を選択して、 適当な IP アドレス、例えば「192.168.168.1」を設定します。 そしてもちろん、 WINS タブの中の「NetBIOS over TCP/IP を無効にする」を設定します。

「NetBios over Tcpip」ドライバを使わない設定

前述したように「NetBIOS 付 SMB」はアダプタごとに 無効にすることができるのですが、 「Direct Hosting of SMB」すなわち「NetBIOS 無し SMB」は 全てのアダプタをまとめて無効にすることしかできません。 しかも Microsoft 流 (?) に、 クライアント機能とサーバ機能の区別がついてませんから、 サーバ機能だけ無効にするということができないようです。

「コンピュータの管理」の「デバイス マネージャ」で、 「プラグ アンド プレイではないドライバ」 (「表示」メニューにて「非表示のデバイスの表示」を選択すると表示されます) の中から「NetBios over Tcpip」を選んで 「このデバイスを使わない(無効)」設定にすれば、 「NetBIOS 無し SMB」を無効にできますが、 これを設定してしまうと SMB に関する全ての機能が利用できなくなってしまうので 現実的ではありません。

繰り返しになりますが (くどい？ ^^;)、 「NetBIOS 無し SMB」を有効/無効するための設定が、 「NetBios over Tcpip」ドライバを使う/使わない、という名称なのは、 なんとかならないのでしょうかねぇ？ なんだかわざと分かりにくくしようとしているんじゃないかと 勘繰りたくなります。

したがって、 Windows PC の 445番ポートを転送させることは現実的ではありません。 私は Windows なノート PC 上で coLinux を走らせているので、 この Linux 上の 445番ポートを VPN-Warp でポートフォワードしたりしていますが、 まあそこまでやらなくても、139番をポートフォワードするほうがよいでしょうね。

VPN-Warp の設定

長々と Microsoft ネットワークについて説明してしまいましたが、 要約すれば Windows PC の Loopback Adapter の 139番ポートを VPN-Warp を使ってファイル共有サーバの 139番ポートへ転送すればよい、 ということになります。

そして (いままでの説明が長かったこととは裏腹に ;-)、 VPN-Warp 自体の設定はとても簡単です。 まずファイル共有サーバ側で走らせる relayagent の設定は次の通りです:

-c "C:/Program Files/KLab Security/VPNワープ relayエージェント/user.pem"
-k "C:/Program Files/KLab Security/VPNワープ relayエージェント/user.pem"
-n
relay.klab.org:443 192.168.1.129:139

フォワード先が 192.168.1.129 (この IP アドレスは私の PC の場合の例です) の 139番ポートになっている他は、 前回の「盗まれたノートPC を外部から操作する方法」と同様ですね。 「192.168.1.129」は、 「NetBIOS 付 SMB」サービスを行なっているアダプタの IP アドレスで 読み替えてください。 一般的には「ローカル エリア接続」などの名称になっているアダプタでしょう。

次に、ローカルホスト側、 つまりファイル共有サーバを利用するクライアント側 (ノートPC など) は、 stone を以下の設定で動かすだけです:

-q cert=user.pem
-q key=user.pem
relay.klab.org:443/ssl,http 192.168.168.1:139 "GET / HTTP/1.1"

これも、前回と異なるのは転送元の指定である「192.168.168.1:139」の 部分だけですね。 Loopback Adapter の IP アドレス (この例では 192.168.168.1) と、 139番ポートを指定します。

日記の更新が滞ってしまっています (_O_)。 いろいろ考えていることはあるのですが、 考えがまとまるまでは個人の日記の ほうへ書くということにしていたら、 こちらの日記の更新が止まってしまいました (^^;)。 二つの日記を書き分けるというのは、なかなか難しいものですね。

この三連休は、どーせ梅雨で雨だろうと思っていて 特にどこへも行く予定を立てていなかったので、 家でのんびりしております。 時間を持て余し気味だったので、 連休の中日に散髪に行ってきました。

自宅の近くにいくらでも散髪屋があるのに、 私はわざわざ電車に乗って、 たまプラーザ駅(東急田園都市線)の近くの散髪屋へ行っています。 なぜ、たまプラーザかといえば、以前その近くに住んでいたからで、 引越ししてもう 6年以上にもなるのに同じ散髪屋に行き続けています。 いつも同じ担当者に散髪してもらえれば、 いちいち髪型を指定する必要もなく楽だから、 ずーっと同じ散髪屋、同じ担当者に散髪してもらっている、というわけです。 そういう人って多いと思うのですが、 引越しして生活圏が変わってもわざわざ以前の店に通い続ける、 というのは少数派かも知れませんね。

近くの初めての店に行くか、遠くのなじみの店に行くか、 みなさんならどちらを選ぶでしょうか？ どのくらい「なじみ」になるかにもよると思いますが、 顧客ロイヤリティをいかに高めるかがとても重要な業種の一つであることは まちがいなさそうです。

私が行き付けのこのお店、 最初の頃 (今から 14年ほど前になるでしょうか) は、 顧客管理を担当者の記憶だけに頼っていたようですが、 そのうち顧客一人一人の好みの髪型や留意点を書き留めた カルテを管理するようになり、 そして最近ついに、 Web ページを公開しました。 スタッフのブログまであるようです (せっかくの機会なのでトラックバックを打ってみます)。 昔からワン・トゥ・ワン・マーケティングを実践してきたお店が、 今後どのようにインターネットを活用していくのか、 とても興味深いところです。

ちなみに、私がそもそもこのお店に行くようになったきっかけは、 大学を卒業して東京に出てきたとき、 街をうろうろしていたら、 たまたま私の名前 (SENGOKU) と同じ名前の散髪屋を見つけて、 「何かの縁」と思って入ってみた、という単純なものです (「センゴク」といっても地名の「千石」のようですが)。 こういう「気まぐれ」で入ってきたお客をいかに固定化するか、 そのノウハウは非常に重要なものなのでしょうね。

「jabber.jp が Google Talk と 相互接続できないのが某所で問題になっている。」 昨日、そんな声が社内から聞こえてきました。 jabber.jp というのは 2001年6月のサービス開始以来、 KLab で運用している jabber (通信に XMLプロトコル XMPP を使う、 インスタント メッセージング サービス) サーバです。 KLab 社内公式 IM (インスタント メッセンジャー) として大いに活用していますが、 社外のかたにも開放しています。

その時は、 「え？ Google ? あそこって他サイトとの相互接続ってやってなかったんでは？」 と、思わず答えてしまいましたが、 いつのまにか 相互接続を開始していたんですね。 知らなかった... orz
jabber.org などとは 相互接続できていたので、 Google Talk と接続できないのはアチラの問題、と思い込んでいました (_O_)。

多くの方々に利用して頂いている jabber.jp で調査を行なうよりは、 (落ちても誰も文句言わない ;) 自宅サイト gcd.org も Google Talk と接続できないという 問題をかかえていたので、gcd.org で調査を始めました。

通信できないときに最初にすべきことと言えば、 まずはパケットが届いているか調べることですね。 tcpdump でパケットダンプを取りつつ、 Google Talk (gmail.com) に jabber クライアントでログインして GCD (jabber.gcd.org) へチャットしてみました。

senri:/home/sengoku # tcpdump -i ppp0 port 5269
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
07:07:11.672591 IP iproxy.google.com.32489 > gcd.org.5269: S 2133894537:2133894537(0) win 5720 <mss 1430,sackOK,timestamp 379820136 0,nop,wscale 0>
07:07:13.004593 IP gcd.org.5269 > iproxy.google.com.32489: S 1097254147:1097254147(0) ack 2133894538 win 5608 <mss 1414,sackOK,timestamp 401538947 379820136,nop,wscale 2>
07:07:11.837330 IP iproxy.google.com.32489 > gcd.org.5269: . ack 1 win 5720 <nop,nop,timestamp 379820153 401538947>
07:07:11.837527 IP iproxy.google.com.32489 > gcd.org.5269: P 1:142(141) ack 1 win 5720 <nop,nop,timestamp 379820153 401538947>
07:07:11.837574 IP gcd.org.5269 > iproxy.google.com.32489: . ack 142 win 1670 <nop,nop,timestamp 401538988 379820153>
07:07:11.837762 IP gcd.org.5269 > iproxy.google.com.32489: P 1:187(186) ack 142 win 1670 <nop,nop,timestamp 401538988 379820153>
07:07:12.002559 IP iproxy.google.com.32489 > gcd.org.5269: . ack 187 win 5720 <nop,nop,timestamp 379820169 401538988>
07:07:12.003738 IP iproxy.google.com.32489 > gcd.org.5269: P 142:242(100) ack 187 win 5720 <nop,nop,timestamp 379820170 401538988>
07:07:12.046764 IP gcd.org.5269 > iproxy.google.com.32489: . ack 242 win 1670 <nop,nop,timestamp 401539040 379820170>
07:07:13.486820 IP gcd.org.41294 > 216.239.57.83.5269: S 1003009747:1003009747(0) win 5656 <mss 1414,sackOK,timestamp 401539400 0,nop,wscale 2>

最初 Google 側から GCD の 5269番ポートへ接続があって、 それに答えて GCD から Google へ dialback 接続を行なう... ところが、それに対する応答が無い。 実際、netstat で調べてみると SYN_SENT のままです。

senri:/home/sengoku # netstat -nap | grep s2s
tcp        0      0 0.0.0.0:5269            0.0.0.0:*               LISTEN      14525/s2s
tcp        0      1 60.32.85.216:41294      216.239.57.83:5269      SYN_SENT    14525/s2s
...

見るからに、216.239.57.83 へ接続を試みていることが間違いのようです。 216.239.57.83 というのは gmail.com の A レコードの一つですね。

senri:/home/sengoku % host gmail.com.
gmail.com has address 64.233.161.83
gmail.com has address 216.239.57.83	←コレ
gmail.com has address 64.233.171.83
gmail.com mail is handled by 50 gsmtp163.google.com.
gmail.com mail is handled by 50 gsmtp183.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.

では、jabber サーバ間の通信では接続先をどのように探せばよいのだっけ、と 調べてみると、 SRV レコードに サーバのホスト名とポート番号を 登録しておくことになっているようです。 以前は A レコードを使っていたような気がするのですが、 A レコードを直接使ってしまうと、 jabber ID (JID) のドメイン名と jabber サーバのホスト名を一致させる必要があって 柔軟性を欠くから、 SRV レコードに変更したということなのでしょう。

私の自宅サイトのような小規模サイトなら jabber.gcd.org というホスト名で jabber サーバを立ち上げることはさほど問題ではありませんが、 Google のような大規模サイトだと、gmail.com というホスト名で jabber サーバを立ち上げてしまうと運用が面倒なことになりそうです。 gmail.com の SRV レコードを引いてみると、 xmpp-server.l.google.com という応答が返ってきました。 つまり (JID のドメイン名である) gmail.com とは 異なるサーバ xmpp-server.l.google.com で jabber サーバを動かしているということです。

senri:/home/sengoku % host -t srv _xmpp-server._tcp.gmail.com.
_xmpp-server._tcp.gmail.com has SRV record 5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server1.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server2.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server3.l.google.com.
_xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server4.l.google.com.
% host -t a xmpp-server.l.google.com.
xmpp-server.l.google.com has address 64.233.167.125

というわけで通信できない原因が分かったので、 あとは GCD の jabber サーバに SRV レコードを参照させればいいだけですが、 幸い現在使っている jabberd2 サーバは SRV レコードを参照する機能を持っていました。 なので設定ファイル resolver.xml に次の行を追加するだけです:

  <lookup>
    <srv>_xmpp-server._tcp</srv>
    <srv>_jabber._tcp</srv>
  </lookup>

また、SRV レコードを参照する jabber サーバ＆クライアントのために、 ネームサーバに SRV レコードを登録しておいたほうがいいでしょう。 GCD ではネームサーバとして djbdns を使っているので、 次の行を tinydns のレコードファイルに追加します:

:_jabber._tcp.jabber.gcd.org:33:\000\012\000\000\024\225\006jabber\003gcd\003org\000
:_xmpp-server._tcp.jabber.gcd.org:33:\000\012\000\000\024\225\006jabber\003gcd\003org\000
:_xmpp-client._tcp.jabber.gcd.org:33:\000\012\000\000\024\146\006jabber\003gcd\003org\000

以上の修正を行なった上で、 GCD と Google Talk それぞれに jabber クライアントでログインして、 チャットしてみると、あっさりつながりました。 続いて同様の修正を jabber.jp に対しても行ないました。

というわけで、約5ヶ月の間ご迷惑をおかけしましたが、 jabber.jp と Google Talk は、 ようやく本日より相互接続できるようになりました。

「断片的な知識と体系的な知識」にトラックバックを頂きました。 長久さま曰く:

体系的な知識を学ぶことはある程度可能です。 但し、その分野が十分に研究されていて、体系化されているならば、 という条件が付きます。体系化は、学問化と言っても良いでしょう。 この場合、本当に良くできた教科書を読むことで、 体系的な知識を学ぶことができます。
しかし、多くの分野では、体系化まで行ってません。 コンピュータ科学においても、体系化まで進んでいる分野は、一握りです。

「体系」を辞書で引くと、 「一定の原理で組織された知識の統一的全体」(広辞苑) とあります。 私は「統一的全体」として、 かなり広範囲の学問分野を想定していたのですが、 長久さまは「コンピュータ科学においても、体系化まで進んでいる分野は、 一握りです」と 表現されていることから、 もっと狭い個々の技術分野について考えられているのでしょう。 技術分野がどんどん細分化されていく昨今、 長久さまのように、 個々の技術分野の「体系」をイメージされるかたのほうが 多数派なのかも知れませんね。

私がイメージする「体系的知識」とは、 コンピュータ科学でいえば、 例えば「オートマトン理論」のような学問体系のことです。 現在のコンピュータは全てオートマトンですから、 コンピュータ科学全体が一つの体系と言ってしまってもいいかも知れません。 この意味でコンピュータ科学は、かなり体系化されています。 コンピュータ科学という「体系」の視点から見れば、 その中の個々の技術分野の「体系」は、 他の技術分野と相互に関連づけられていない限り 「断片的知識」と言いきってしまえるかも知れません。

「コンピュータ科学 体系」で Google 検索してみると、次の本が見つかりました:

図解雑学 コンピュータ科学の基礎 河村 一樹 (著)

内容
ほとんどの情報処理試験に出題され、 もっとも難しいジャンルとされる「コンピュータ科学基礎」について 図版を豊富に使って丁寧に解説。 コンピュータ科学がいかに体系化され、 いかに研究が進んでいるかを実感できる本。

目次
1 コンピュータサイエンスと符号化理論の基礎
2 論理学の基礎
3 集合論の基礎
4 形式言語理論の基礎
5 オートマトン理論の基礎
6 グラフ理論の基礎
7 プログラミング論の基礎

検索で見つけただけの本なので内容がどうなってるのか分かりませんが(^^;)、
この目次は、コンピュータ科学の体系を俯瞰するのに丁度いいと感じました。

オートマトン理論の中には、 チューリングマシンや計算量の理論などが含まれてくるでしょう。 非決定性チューリングマシンが多項式時間で解くことができる問題のクラス NPや、 オラクル付チューリングマシンが解くことができる問題のクラス階層は、 コンピュータ科学の体系の中でも最も重要な概念の一つと言っても いいかもしれません。

# オラクルといっても DBMS でもなければ、マトリックスの母でもありません ;-p

また、グラフ理論に関連する分野として、組み合わせ理論や探索などがあります。 遺伝的アルゴリズム(GA)は、確率的探索の中の一分野に過ぎません。 GA を単に、交叉・突然変異・自然淘汰からなる探索アルゴリズムとして 理解してしまうと、 本質を見失ってしまうのではないでしょうか。

プログラミング論には、 近年急速に発展しつつあるソフトウェア工学全体が含まれてきます。 秒進分歩といってもいいくらい新しい概念が次々と提案される分野ですが、 本質さえきちんと押えておけば、 数年で廃れる流行に振り回されずに済むのもまた事実です。

同ページで長久さま曰く:

「これ読めば、探索を体系的に学べます」というオチがきたら良かったと思います。 この終わり方だと、生殺しっぽいので。 でも、探索を体系的に記した本って、タブンないと思うんですよね。 捉えるレベルがメタ過ぎて、抽象的になっちゃうと思うので。

まずはコンピュータ科学全体を俯瞰し、 「論理学」「形式言語理論」「オートマトン理論」 「グラフ理論」「組み合わせ理論」「符号化理論」などの コンピュータ科学を支える重要理論を大ざっぱに把握した上で、 特に興味がある分野(例えば探索)をより突っ込んで勉強する、という方法が いいのではないかと思っています。 重要なのは、最初のうちは枝葉末節にあまり捕らわれないようにすることでしょう。 木を一本一本見ていて森が理解できるようになるほど、 コンピュータ科学という森は小さくありません。 まずは森全体の地図を見て体系を理解しておくことが重要でしょうね。

タイトルで言いたいことを言い尽くしてしまっている (^^;) のですが、 技術をウリにする会社は、 その立ち上げメンバに三種類の人種が含まれていることが必須なのだと思います。 すなわち、

1. 湯水のように新しい事業アイディアを思いつくアイディアマン
2. アイディアを実際の製品として実現する技術者
3. 完成した製品を売る戦略を立案し実行するマーケッタ

会社の立ち上げというと、 ともすると同じような人種が集まりがちです。 例えば、 技術出身者ばかりで立ち上げた会社や、 その逆にアイディアマンばかりで立ち上げた会社です。 前者は技術出身だけど営業のことをある程度知っている人が営業担当になり、 後者は技術者ではないけれど仲間内では技術に詳しいと一目置かれる人が 技術担当になったりします。

しかしいくら人当たりが良くても技術者は技術者ですから、 どうしても製品への思い入れが強くなってしまい、 肝心の売るための戦略がおろそかになって 場当たり的な営業になってしまいます。 また、ある程度会社の規模が大きくなってくると、 営業チームを作って組織的な営業が必要となりますが、 セールスパーソン一人一人の心を理解している人でなければ リーダシップをとることは難しそうです。 私自身は技術者ですから、 優秀なセールスパーソンは無条件に尊敬するものの、 どうすれば営業チームを育て、機能させていくことができるのか、 (いろいろ営業ハウツー本を読んで勉強したりはしているのですが ^^;) 根本的なところは理解の範囲外にあるような気がしています。

同様に、技術者でない人が技術者チームを率いようとしても、 技術者一人一人の技術力の差がどこにあるのか、 きちんと理解することは難しいでしょう。 たまたま優秀な技術者が運良く入社してきたとしても、 その人の真の実力を理解して評価することができなければ、 早晩その人はもっと評価される場、 あるいはもっと自身を磨ける場を求めて去ってしまうはずです。 優秀な技術者にとって一番の屈辱は、 レベルの低い技術者と同列に扱われることなのですから。 自分は技術者に対する尊敬の念を持っているから技術者がついてくる、 なんて言う人にかぎって、 ピンもキリもいっしょくたに「尊敬」したりするので、 余計にタチが悪かったりするものです。

VPN-Warp relayagent を、この日記の読者のみなさま限定で公開します。
下記リンクからダウンロードできます。

• relayagent 1.0.4 Windows 版
• relayagent 1.0.4 Linux 版

上記パッケージは、VPN-Warp を読者のみなさまに評価して頂くことを 目的としておりますので、 使用した結果の影響につきましては責任を負いかねます。 以下の入門編、応用編をよくお読みの上、 万一の事態を想定したご利用をお願いします。

...とは言っても、もちろん (^^;)、 内容については万全を期して作成しております。 なにかお気付きの点がありましたら遠慮無くご指摘下さい。

• 入門編 (1) VPN-Warp の特長: ふつうの SSL VPN と比べて
• 入門編 (2) VPN-Warp の特長: ssh のポートフォワードと比べて
• 入門編 (3) stone & relayagent の設定方法
• 入門編 (4) stone の代わりに OpenSSL の s_client を使ってみる
• 入門編 (5) stone の代わりに普通の WWW ブラウザを使ってみる
• 入門編 (6) WWW ブラウザを使う場合の注意点

• 応用編 (1) VPN-Warp 試用ライセンス提供開始のお知らせ
• 応用編 (2) 盗まれたノートPC を外部から操作する方法

VPN-Warp を利用する際に必要となる SSL 証明書に関しては、 上記「応用編 (1) VPN-Warp 試用ライセンス提供開始のお知らせ」を参照願います。