2008年04月23日母校の教壇に立ちました。
20年前に学んだ教室 (私が情報工学科で学んだのは 1987年〜1990年) で、 20歳年下の後輩に対して行なった、 私にとって初めての授業体験でした。 勉強会やセミナーで講師をしたり、 学会で発表したりは何度もあるのですが、 授業というのは、 また趣きが異なりますね。 2コマ (約三時間) 自由に話してよい、 ということだったので、 そんなに長時間は話がもたないんじゃないかなぁ、 と少々不安を感じながら臨んだのですが、 幸い多くの質問を頂けて、 気づいたら 30分ほど時間を超過していました。
聞き手の学生さん達は現在 4回生で、 そのほとんどは大学院に進学予定ということだったので、 「学生のうちに身につけて欲しい、たった一つの能力」 というテーマでお話しました。 もちろん、「たった一つ」だけだと 3時間も話を引っ張れないので (^^;)、 私が卒業してから現在までの 16年間の社会人生活で学んだことの中で、 一番重要と思うことを三つ挙げてお話したのですが、 三つもあると覚えてられないでしょうから、 ということで「たった一つ」を強調したのでした。 それは、
質問すること
です。
産業界(特に IT 業界) が大学教育に求めること、 というと「コミュニケーション能力」なんかが 筆頭に挙がってしまうことも多い今日このごろですが、 「みんなと仲良くできる」だけでいいのは小学生までで、 社会で活躍していく上で本当に必要な能力といえば、 間違いなく「考える力」でしょう。
で、どうやって考える力を伸ばしていくかですが、 教科書を読んだり問題集を解くだけで身につくわけもなく、 いろんな人の考えを見聞きしながら自分なりに考えてみて、 次第に考える力が身についていくものだと思います。 だから、 出会った人それぞれから、 どれだけその人の「考え方」を吸収できるかが、 一生の間にどれだけ考える力を身につけられるかを左右することになるでしょう。
もちろん、より多くの人に出会うように努めれば、 より多くの人の考え方を参考にできるわけで、 だからこそ「コミュニケーション能力」が重要と主張する人もいるのでしょうが、 スゴイ人に出会えても、 その人から学べなければ折角の機会も生かせません。 優れた人からどれだけ多くのものを引き出せるか、 すなわち臆せずどんどん質問できるかこそが、 考える力を伸ばす最大の原動力になるのだと思います (もちろん質問する能力も一種のコミュニケーション能力ですが、 「コミュニケーション能力が重要」と言ってしまうと範囲が広すぎて、 焦点がぼやけてしまいます)。
例えば、講演会等で、質疑応答の時間になった時、誰も質問しなくって、 大きな会場が静まり返る、という状況はよくありますよね？ その静寂を打ち破って質問できるでしょうか？ ほとんどの人は、たとえ質問したいことがあっても、 なかなか声を出せないんじゃないでしょうか？
私が個人的に尊敬している人って、 ほとんど例外なくそういう場でも臆することなく質問できる人なんですよね。 「分からない」と言える勇気を持つことと、スキルアップできること、 との間には強い相関があるように思えてなりません。
というわけで、 今日の私との「出会い」を最大限生かすべく、 講演を途中で遮っても構わないので、 (空気を読まずに) 遠慮無く質問してください、 と話してから本題へ移りました。 まあ、私との出会いが 大した足しにならなかったとしても、 恥ずかしがらずに質問する練習だけでも 2コマの授業時間を費やす価値は充分にあると思います。 「出会い」は今後もたくさんあるでしょうから。
ちなみに、「重要と思うこと三つ」の残り二つは、
技術者の地位を向上させるには、 技術者以外の視点にも立ってみて、 技術者自身が視野を広げていかなければならない
と、
これから社会に出ていく学生さん達が最優先で取組むべきことは、 会社と対等に渡り合える実力を身につけるために、 いま何をすべきか考えることでしょう。 そんな実力を身につけることは自分には永遠にムリと思う人がいるかもしれませんが、 ムリと思えば思うほど実現は遠退きます。
です。
授業で使ったスライドを PDF 化したもの と、
FlashPaper で Flash 化したもの ↓ を公開します。
2008年01月15日私自身は、 KLab 社内の技術者たちと、 いつまでも技術者同士の関係でいたいと思っているのですが、 技術者の人数が増えてくると、 仕事上の接点がほとんどない人もでてきます。 そして社員の側からすると、 私は (いちおー ;-) 取締役なので、 おいそれとは話せない恐い人などと根拠無く思い込んでるケースも、 残念ながら皆無というわけではありません。
それではいけないということで、 日頃あまり接点のない人たちを中心に、 無理矢理 (^^;) ランチに誘って話する、ということをしています。 先日も隣の部署の N さんと二人でランチへ行きました。 彼とは入社直後の社員旅行で少し話をしただけで、 その後は話す機会がほとんどなかったのです。
それまで私は知らなかったのですが、 実は彼は高専時代にず抜けた存在で、全校で表彰されたこともあったそうです。 プログラミングが大好きで、いろんなものを作っては、 学校内でアピールし注目を集めていたとか。 しかしながら KLab 社内ではどちらかといえば目立たない存在だった (目立たなかったので私も話す機会がありませんでした) ので、 高専での活躍ぶりとのギャップを感じざるを得ませんでした。
そこで、 何がきっかけで自身の成果をアピールするのを止めてしまったのか尋ねました。 すると、
新卒で就職した会社 (≠ KLab) で、 開発ではない部署に配属されてしまった。 何事も挑戦ということでしばらくは配属された部署で頑張ったが、 やっぱりプログラミングを仕事にしたいと思い、 上司に何度も自身の能力をアピールしたところ、 ことごとく却下されてしまった。 それどころかアピールすればするほど周囲の評価も下がるぐらいで、 ついにはアピールするのを止めてしまった。
という答が返ってきました。
確かにそういう人は多いのだろうなぁと思います。 日頃、アピールすることの重要性を説いている私としては残念でなりません。 そもそも誰だって、 他の人より得意なことがあれば、 それを自慢したくなるのがフツーでしょう。 だからアピールする習慣がない人って、 元々アピールするのが嫌いだったというわけではなくて、 何らかのきっかけでアピールするのを止めてしまったのだろうと思います。
きっかけにはいろいろあるでしょうが、 N さんのように、 アピールしても周囲から評価されなかったり、 それどころか怒られたり、 周囲から浮いてしまって仕事が進めにくくなったり、 そういう嫌な経験をすれば、 だんだんとアピールするのが億劫になってしまうのは仕方がないところだと思います。 N さんの話に頷きながら、 ふと一つのフレーズが頭の中に浮かんできました:
自身の能力をアピールすることは技術者として必須だが、
上司にだけアピールするのは最悪！
技術者にとって重要な能力というと、 一つは間違いなく「スキルアップする能力」でしょう。 誰だって最初は初心者です。 プログラミングの勘所が最初から分かっていたなんて人は (たぶん) 皆無で、 初めて書いたプログラムを後に読んでみると、 その稚拙さ加減にあきれてしまう、というのはよくある話です。
最初は誰しも稚拙なプログラムを書いていたのに、 どんどん能力を伸ばす人がいる一方で、 多少は「形」を覚えて「それなりの」プログラムが書けるようになるものの、 本質的には初心者と代わり映えしない人 (偽ベテラン) もいて、 いつのまにか両者の間には生産性で 3桁の差がついていた、 なんてことが起こり得ます。
技術者にとって重要な能力がもう一つあります。 それが「アピールする能力」。 言うまでもなく技術者だけではお金にはなりません。 技術者の能力をお金に換える人 ──例えば技術者が作ったものを他の誰かに売り付ける人──と、 一緒になって初めてお金が稼ぐことができるわけです。 でも、どうやってその「換金してくれる人」を探せばよいのでしょうか？
実は「換金してくれる人」も技術者を探しています。 そりゃ、売るものがなければお金を稼げませんから、 技術者の能力を換金しようと思っている人が技術者を探すのは当たり前ですね。 だからわざわざ技術者の側からアクションを起さなくても、 学校には「求人票」が貼られ、 巷には転職斡旋会社の広告が氾濫しているわけです。 テキトーな会社を選んで面接を受ければ雇ってもらえてお金をもらえます。
とはいえ、受け身の姿勢よりは自ら動いたほうが有利になるのは世の常です。 学校に貼ってある求人票に限定した就職活動や、 あるいは転職エージェントの勧めに従うばかりの転職活動よりは、 自ら主体的に会社探しをしたほうが「高く」換金してもらえる可能性が高まります。
会社に雇ってもらった場合、 配属された部署の上司が「換金してくれる人」になります。 もちろん上司が一人でお金を稼いでくるわけではありませんが、 技術者から見れば、 自身の能力に対して評価し給料を決めてくれるわけですから、 自身の能力を「換金してくれる人」と言ってもいいでしょう (正確に言えば、換金してくれる人たちの集団の窓口的存在ですね)。
ところが、ここに一つ問題があります。 技術者に得手不得手があるのと同様、 「換金してくれる人」にも得手不得手があります。 技術者からすれば、 私はこんなに優れた能力を持っているのに、 どーして換金してくれないんだと思うのと同様、 「換金してくれる人」からすれば、 私はこーいう技術ならお金に換えられるのに、 どーしてそういう技術を持っている人がいないんだと思っていたりします。
「能力を上司が正当に評価してくれない」と不満に思っている場合、 十中八九その上司は、 「求める能力を部下が持っていない」と不満に思っているはずです。 このような状況で、 部下が上司に自身の能力をアピールして事態が改善するでしょうか。 きっと上司はこう思うはずです: 「そんな能力はお金にならない」。
より正確に言えば、 その上司が換金できる分野と、 技術者である部下の得意分野とが一致していないだけなんですが、 部下が自分の得意分野以外のことに興味がないのと同様、 上司は自分が換金できない分野には興味がありません。 そんな上司に執拗にアピールすれば、 事態を改善するどころか悪化させかねません。 技術者がすべきことは、 自身の能力を上司が換金できないのであれば、 他の「換金してくれる人」を探すことです。
ところが、 前述の N さんをはじめ多くの技術者は、 逆のことをやってしまいます。 「換金してくれる人」を探すのではなく、 上司に「換金してくれ」と懇願したり、 あるいはそれが却下されると、 もう世界にはただ一人も換金してくれる人はいないと 探すのをあきらめてしまったりするのです。
冷静に考えれば、 これは全くナンセンスであることが分かりますよね? 一口に IT (情報技術) と言っても、 様々な分野があります。 ある技術者の得意分野を最もうまく換金できる人が、 たまたまその人の上司だった、 なんてことがもし起これば、 それはすごくラッキーなことだと思いますが、 そんな幸運がそうそう起こるはずはありません。
自身の技術を上司が換金してくれなかったとしても、 そんなことは確率からいえば 「よくあること」 なわけで、 決してその技術が 「お金にならない」 ことを意味しません。 自身の技術が上司に評価されないときこそ、 より積極的に、上司以外の人に向かって、 自身の技術をアピールすべきでしょう。
より多くの人にアピールすれば、 それだけ「運命の人」にめぐりあう確率は高まります。 「この分野にかけては誰にも負けない」という得意分野を持っている人は、 より多くの人へ、 部署内だけでなく社内全体へ、 社内だけでなくより広い世界に対して、 どんどんアピールしていって欲しいと思います。 探す範囲を広げていけば、 その能力を換金してくれる人がきっと見つかるはずです。
2007年12月19日あすなろ blog の CTO キャリアライフインタビューを受けました。 私は普段、 昔話はできるだけしないように気をつけていた (だって「老害!」って思われちゃいますからね) のですが、 このインタビューでは冒頭いきなり
そもそもコンピュータに興味を持ったきっかけから教えていただけますか
と聞かれてしまい、 封印していた過去が一気に吹き出してしまいました。 なんせ 30年近い昔のことですから、 最近コンピュータを始めた人にとっては 何の興味も持てないんじゃないかとちょっと心配です (インターネット元年であり Windows ブレイクの年でもある 1995年も、 私の感覚だと「つい最近」の出来事だったりします ^^;)。
そして今日は、 「Commodore 64」の生みの親、J・トラミエル氏インタビュー という記事を見つけてしまいました。
Commodore !
なにもかも懐かしい ! 昔の記憶がどんどんよみがえってきます。
パーソナルコンピュータの歴史に最も大きな影響を与えた人物について語るとき、 人はよく、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氏は、他の誰よりも強い影響力を持っていたのかもしれない。
私に最も大きな影響を与えたのは、 Apple でもなく、MS Basic でもなく、8080 CPU でもなく、 PC-8001 でもなく、Commodore でした。 CTO インタビューでは、 「なぜかはじめからコンピュータが好きだった」と答えたのですが、 中学校での PET 2001 との出会いがなければ今の私は無かったかも知れません。
中学3年生になって、だんだんBasicでゲームを作るほかに、 もっと下のレベルでプログラミングができるということがわかってきて、 機械語と呼ばれていた言語に興味を持つようになりました。
インタビューの時は忘れていたのですが、 私が機械語 (マシン語。メモリ上で即実行可能なバイナリのことです) を学ぶきっかけになったのは、 当時コモドールジャパンが発行していた小冊子「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 ページの表だったのではないかと思います。
2007年08月07日前回、 思い出したように「面接FAQ」を再開したのにはワケがあります。 Tech総研さんの「転職体験談」の取材を受けることになりまして、 それが、 あらためて私の面接のやりかたを振り返るきっかけになったのでした。 「転職体験談」というのは、 「転職を果たしたエンジニアと面接官が当時を再現」する連載企画で、 「応募者と面接官それぞれの言葉の真意や、 面接でチェックされるポイントをレポート」しようというものだそうです。
取材中は好き勝手なことを言いまくったので、 どのようなページにまとまるかと内心ドキドキしていたのですが (^^;)、 無難にまとまったようでホッとしています。 さすがはプロですね。
携帯電話関連を中心に独自技術で業界を走るKLabへ
携帯電話関連のさまざまな独自技術で知られるKLab（クラブ）は、 エンジニアに対する考え方が他社とは一味違う。 現時点での技術力や知識、担当した仕事の売り上げよりも、 ｢技術が好き｣から発する、挑戦や技術上の本質に対する継続的改善を尊ぶ。 また、技術力のみで昇格できる社内制度も設けている。
（取材・文／須田忠博 総研スタッフ／高橋マサシ）作成日：07.07.30
応募したエンジニア: 富田陽介さん（当時25歳）
企業の面接担当者: 取締役CTO 仙石浩明氏
募集職種: 技術力次第でCTOを目指せる研究開発職
Part1 転職の動機
Part2 技術志向性の強さ
Part3 現時点での関心
このような連載企画は、 応募者にとっては、 面接を受ける前にどんなことに注意すればいいかが分かるわけで、 とても参考になるのだろうと思いますが、 実は求人側の企業にとっても 面接のやり方を第三者の目で見てもらえる機会であるわけで、 とても有意義であると感じました。
求職側は、いろいろな会社の面接を受ければ、 どんな面接があるのか実地に知ることができますが、 求人側は、他社がどんな面接をしているかあまり知る機会はないですし、 まして自分達の面接が第三者の目から見るとどう映るのか、 教えてもらう機会は皆無ですから...
もちろん取材なので、忌憚のない意見を言ってもらえるわけではないのですが、 取材していただいた Tech総研の高橋マサシ様曰く:
現在の業務内容も転職の動機も重視せず、 「いかに技術が好きか」で人を見る面接。 この連載をほぼ50回続けていますが、 初めてのケースでした。 このことを仙石氏に話すと、 「えっ、他社はどんな面接なんですか？」と逆に驚いた様子。 数々の応募者ではなく、あなたが、いちばん技術が好きなんですよね。
やたらに「こんな面接は初めて見た」と強調されるので、 逆にこちらが驚いてしまいました。 面接して採用した技術者が入社後どのくらい伸びるかは、 その人がどのくらい技術が好きかにかかっているわけで、 なら「どれだけ技術が好きか」をとことん聞くべきだと思うのですが、 他社の面接はそうじゃないのですかねぇ...?
なお、 「携帯電話関連を中心に独自技術で業界を走るKLabへ」ページ末尾にある:
このレポートに関連する求人情報です
チェックしてみよう！
KLab株式会社
現在の募集職種はこちら
詳細をみる
をクリックすると、 「この企業は現在リクナビＮＥＸＴ上で募集を行っていません」などと 表示されます (^^;) が、 私のブログを読んで下さってるかたなら、 リクナビNEXT (あるいはその他の求人媒体) で募集を行なっていないからといって、 応募できないわけではない、ということは よくご理解いただけてますよね？
一応、念のために申し上げておきますと、 KLab (に限らず大多数のベンチャーも同様だと思いますが) では、 常に直接応募を受付けております。 媒体やエージェント経由でないと応募を受付けないなどということは 一切ありませんし、 どこ経由で応募したかということは選考には一切影響しません。 さらに言えば「私は KLab へ入ってこれがやりたいんだ!」と 言ってくださるかたならば、 現在の募集職種にかかわらず採用を検討します。 やりたいことが明確になっていることこそが、 技術者の成長にとって一番重要なことだと思うからです。
技術を学ぼうとするなら、その時点での実力はサテオキ、 「伝わる状態」にかけては自分が一番だと自信を持って言い張れる (つまり、その技術を学びたいという情熱にかけては誰にも負けないと言いきれる) 状態からスタートしなければならないのです技術者の成長に役立つ会社とは？(1) から引用
2007年07月10日久しぶりに「面接 FAQ」シリーズの続きを書いてみます (前回書いたのは一年以上前なのでずいぶん間が空いてしまいました)。 私の面接というと最終面接であることが多いのですが、 履歴書の備考欄に「役員との面談希望！」と書いてある場合など、 一次面接から私が面接することもあります。 (最終の) 役員面接というと、 多くの人が通りいっぺんの面接だと思うらしく、 役員面接で技術的な突っ込みを受けて、 応募者が戸惑うケースが多々ありました。
私の面接で、 比較的頻度が高い私の質問パターンを紹介し、 応募者がどう答えることができていたら採用になっていたか、 振り返ってみようというのがこの「面接 FAQ」シリーズの主旨です。 FAQ すなわち、 面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法。
「面接 FAQ」は続き物ですので、 以下のページも参照して頂けると幸いです。
(1) 高い技術力って例えばどんなことですか？
(2) 何か質問はありませんか？
(3) 前職でいくらもらっていましたか？
(4) 仮に、何をしてもいい、と言われたら、何をしますか？
(5) 「人の役に立つことをしたい」と言う技術者の卵たち
面接というと、 「採用してやる」といった態度をとる面接官がいます。 つまり、 会社が求める資質を応募者が持っているかどうかを判断するのが、 面接官の役目だと思っている人ですね。 様々なチェックポイントを次から次へと確認し、 一つでも条件を満たさなければそこで不採用と判断します。 チェックポイント以外でどんなに優れた点を持っていようとお構い無しです。
その面接官にとっては、 採用した人にやってもらう仕事が明確に決まっているから、 その仕事をする能力があるかどうかが一番の関心ごとなんでしょうけど、 もしかしたら面接官よりよっぽど優れた長所を持っているかも知れないのに、 それを見ようともせずに不採用を決めてしまうのは、 モッタイナイ話ですよね？
私は根が貧乏性なので、そんなモッタイナイことは決してできません。 応募者が優れた点を持っているのなら、 たとえそれが KLab の事業と関係なくても、 応募して頂いたのは何かの縁ですから、 是非一緒に働きたいと思ってしまうわけです。 特定の分野に優れた能力を発揮できる人に入社してもらえるなら、 その分野の事業を始めてしまってもいいとさえ思っています。
なので、どんな分野であれ、 応募者が一番得意なことについて、 根掘り葉掘り質問させてもらうことになります。 私が多少なりとも知っている分野なら、 (面接で聞くのは不適切と思われるような) 異常に細かい点、 例えば実装上の細かい工夫とかまで聞いてしまいます。
そんな細かいことまでいちいち聞いていたら、 面接時間が何時間あっても足らないんじゃないか、 と驚かれるかたもいらっしゃるのですが、 私の面接では応募者の職務経歴を一通り聞くなんてことはせず、 応募者が一番自慢したいことだけを徹底的に聞くのがメインなので、 時間が許す限り掘り下げてお聞きするわけです。
しかしながら、 もちろん私が知らない分野もたくさんありますし、 コンピュータの分野であっても私がニガテな分野もあります。 私が何も知らないような分野だと、どんどん掘り下げて質問する、 というのは無理がありますから、そんなときは開き直って、
素人にも分かるように説明してください
って聞いちゃいます。 こう聞かれたら、なんだこんなことも知らないのか、 などと呆れずに丁寧に説明して頂けると幸いです。
応募者が、ずぶの素人である面接官に丁寧に説明したところで、 所詮は素人なんだから、 応募者がその分野についてどのくらい優れているか面接官に伝わるはず無い、 って思う人はいないでしょうか？
確かに、その分野のことについては何も知らないのですから、 その分野における応募者のレベルがどのくらいなのか (例えば、国内で十指に入るのか、あるいは平均くらいなのか、とか) は分かりません。 しかし説明の仕方だけでも応募者の能力はかなりのことが分かると 私は考えています。
「素人にも分かるように説明してください」と求められたとき、 専門用語を、平易な言葉で置き換えようと四苦八苦する人がいます。 勢い余って、さほど「専門的」でない言葉すら無理矢理言い換えようとして、 却って分かりにくくなったりすることもあります。
確かに専門用語だらけの説明は素人にとって分かりにくいし、 専門家の話が分かりにくいのは専門用語の濫用にある、と 考える人が多いのも事実でしょう。 専門用語だらけのマニュアルが非難されることもありますしね。
しかし、専門用語だけの問題でしょうか？ 専門用語の全てを解説した用語辞典を引きまくれば専門書が読めるかというと、 そんなことは決してありませんよね？
専門用語の意味さえ分かれれば、どんな専門分野でも理解できるでしょうか？ こう聞けば誰でも、そんなはずはないといいますよね？ つまり、 専門用語の置き換えるだけでは、 決して「素人にも分かるように」はならないのです。
どんな専門分野でもそうだと思いますが、 その分野特有の考え方、大げさに言えば思想のようなものがあります。 その分野の専門家なら皆が共有している「思想」なので、 あらためて考えてみたりはしませんが、 同じ「思想」を共有している専門家同士だから、 スムーズな意思疏通が可能になります。
逆に言えば、背景思想を共有していない門外漢には、 専門家同士の会話は「宇宙語」に聞こえてしまいます。 たとえ使っている単語自体は平易な言葉ばかりで、 専門用語が一切含まれていなかったとしても、 背景思想を共有していない素人には、 やはり「宇宙語」に聞こえてしまうのです。
「素人にも分かるように説明してください」と求められたとき、 話題にのぼった事項の説明は一時棚上げして、 まず背景思想から説明する人、 こういう人は間違いなく頭がいい人だと思います。 相手と自分が共有している「思想」は何か、 相手が共有していない「思想」は何か、 そして相手の「思想」に何を追加すれば理解してもらえるようになるのか、 そういったことを考えながら話せる人は、 きっと優秀な人なのだと思います。
いろんな人に、いろんな分野について説明してもらったことがありますが、 実に楽しそうに説明してくださるかたもいらっしゃいます。 私が分からない点を質問すると、 よくぞ聞いてくれたと嬉々として答えてくださるので、 とても話が盛り上がります。 そういう人は、 (面接中の感想としては気が早いんですが) KLab に入社して一緒に働けるようになるのが、 とても待ち遠しく感じられます。
2007年06月18日先日、シアトルへ行ってきました。
シアトルと言えば、モノレール。
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 駅へ行くと、 ショッピング モールの建物に接していない側の軌道につながっているはずです。 両方の駅で見た軌道が互いにどのようにつながっているかは、 次図のように、 モノレールの路線に赤色の軌道と、青色の軌道を書き入れてみると一目瞭然ですね。
赤色の車両が走っている軌道は、 ショッピング モールの建物に接していないのに、 どうやって乗降するのでしょうか？ とても謎です。
2007年05月16日
技術者の成長に役立つ会社とは？(1)
以下に述べるのは、私が考える「技術者の成長に役立つ会社」の条件です。 他の人は異なった考えを持つかもしれませんし、 私自身も常に考え続けているので、 「役立つ会社」の条件が変ってくることがあるかも知れません。 しかし、 「技術者の成長にとって一番役に立つ会社を目指したい」というその思い自体は、 私が技術の責任者であり続ける限り、変らず持ち続けたいと思っています。
成長を邪魔しない会社
エラソーに「技術者の成長に役立つ会社」の条件と言っておきながら、 最初の条件が「邪魔しない」かよ、 えらく後ろ向きな条件だな、 という非難の声が聞こえてきそう (^^;) ですが、
上司は思いつきでものを言う(新書)
橋本 治 (著)
にも書かれているように、
会社は上司のピラミッドを骨格として、現場という大地の上に立っている。 「上から下へ」という命令系統で出来上がっていて、 「下から上へ」の声を反映しにくい。 部下からの建設的な提言は、 拒絶されるか、拒絶はされなくても、 上司の「思いつき回路」を作動させてしまう。
ということは、極めてありがちなのではないかと思います。 つまり、上司は体面を保つ必要がありますから、 部下に接するとき、 部下の良いところを誉めるだけではなく、 つい「粗探し」をして一言追加したくなるものだと思います。
だって、部下のことを 100% 肯定するだけでは、 上司の存在価値が危うくなりますからね〜。 なにか部下の至らない点を無理矢理にでも見つけ出して、 教訓めいたことを言って上司の威厳を保ちたくなるものでしょう。
もちろん、部下の狭量な考えを正すために、 いろんな意見を言ってやることが必要なケースもあるでしょう。 「思いつきで」言うことが全て悪いと言うつもりもありません。 しかし、 部下の短所を矯正することばかりに熱中していては、 部下が技術者として成長することを妨げることになりかねません。 例えば、
キミは技術は優れているんだが、 もうちょっと仲間とうまく仕事をやっていくよう努力してもらえんかね？ キミも社会人なんだから学生気分は早く捨てて、 チームワークを重視して仕事してもらわんと困るよ。
なんて言ってないでしょうか？ 技術が (おそらく上司よりも) 優れている部下に対し、 その得意な技術をもっと伸ばすことよりも、 その部下がニガテとしていること、 例えばコミュニケーション能力を 「人並みに」身につけることを優先するよう要求してしまうわけです。
「感情的コミュニケーション」は、 若いうち (例えば 30歳前半まで) は手を出さないようにして欲しい コミュニケーション能力である。 特に研究者や技術者を目指そうとする若い人たちには、 周りの人がどう思うかなんかは気にせず、 (「空気嫁！」などの罵倒は無視して) 我が道を進んで欲しい。
コミュニケーション能力なんて、 歳をとって頭が固くなってからでも充分身につけることができます。 そもそも技術者にとって「人並み」のコミュニケーション能力なんて、 どれほどの価値があるというのでしょう？ 技術者としての成長を考えるなら、 若いときにしか学べない「技術の本質」を身につけることこそ、 優先すべきではないでしょうか。
以上は、積極的に「成長を邪魔する」ケースですが、 以下のように、消極的に「成長を邪魔する」ケースも、 ありがちなのではないかと思います。
すなわち、 技術者の成長を第一に考えるのなら、 それぞれの技術者が自身の能力をフルに発揮して、 得意なことをとことん伸ばすことができるような 活躍の場を与えるべきだと思うのですが、 現実の会社だとそういう「適材適所」は、 なかなか難しいケースが多いかも知れません。 適切な活躍の場を与えないというのは、 成長を邪魔しようと意図しているわけではないにせよ、 結果として邪魔しています。
例えば、 新入社員がある特定の分野において素晴らしい能力を持っていたとしても、 その分野の業務に先任者がいたらどうでしょうか？ その先任者を異動させてまで、 新人にその分野の業務を任せる、 という会社は多くはないでしょう。 むしろ、 新人が何が得意か検討して配属先を決めるというよりは、 人が足らない部署への配属を優先する会社の方が 多数派であるような気がします。
さらに言えば、 配属後も新人には雑用ばかりをやらせ、 能力を発揮できる仕事を任せない、 なんてこともあるのではないでしょうか。 上司と同様、 先輩にもメンツというのがありますから、 たとえ後輩の方が能力が高かったとしても、 それを素直に認めて立場を逆転させる (つまり先輩が新人の指示に従う) よりも、 新人の至らない点を無理矢理にでも見つけ出すことに熱中し、 雑用を押し付けることに終始してしまうものなのかも知れません。
会社ってのは、 部下や後輩の技術者の成長を邪魔してしまえ、とささやく誘惑に満ちています。 私自身、そういう誘惑に負けそうになることが全く無いと言えば嘘になります。 部下や後輩の技術者の成長を邪魔していないか、 常に自省し続けることこそ、 「技術者の成長に役立つ会社」の第一の条件と言えるのではないでしょうか。
技術者を「技術そのもの」で評価する会社
技術者が邪魔されずに成長できたとしても、 その成長を「技術そのもの」できちんと評価してあげられなければ、 片手落ちです。 技術的に成長したら成長したぶんだけ、 きちんと評価されて給料が上がる、 こうしてはじめて、 技術的に成長しようという意欲が継続するのだと思います。
こういう話をすると、 なぜ技術的に成長したからといって給料を上げる必要があるのか、 と思う人がいるかも知れません。 会社は技術者養成機関ではありませんから、 能力ではなく成果に対して報酬を支払いたい、 と思う人が出てくるのは当然でしょう。 では、「技術者の成果」とは何でしょうか？
「技術者の成果」とは何でしょう？
技術者が作ったものから得られる売上でしょうか？ もちろん、それだけではないですよね？ 「青色LED」のように最終的に莫大な利益を生み出したものは、 とても分かりやすい「成果」ですが、 サーバシステムの運用などのような縁の下の力持ちの仕事だって立派な成果ですし、 さらに、自分自身では何も生み出さなくても、 社内の技術者を育てることや、 社内の技術をブログなどで発表して会社の知名度を上げることなども、 立派な成果と言えるでしょう。技術者を目指す学生さんたちへ から引用
技術者という人材を「人財」すなわち会社の資産と考えるのであれば、 技術者の成長とは、「人財」の価値の増加、 すなわち会社の資産の増加を意味します。 売上は単にそのとき限りのフローに過ぎませんが、 技術者の成長はストックとなるわけです。 会計数字には現われにくいので見落とされがちなのですが、 技術者自身の成長こそ、 本来は最も評価されるべき「成果」と言えるのではないでしょうか。
しかしながら、 技術者の成長を「技術そのもの」で正当に評価することは、 容易ではありません。 「技術そのもの」で評価しようとすれば、 その技術分野の概要を理解している程度では全くダメで、 いざとなったら部下の仕事を代行できるくらいの技術力が、 評価する側に求められます。
もちろん、 いろんな得意分野を持つ部下たち全員において、 その仕事を完全に代行できることを上司に求めるのは無理な話でしょう。 部下全員の技術力のスーパーセットの技術力を上司の条件にしていては、 上司のなり手がいなくなってしまいます。
かといって、 半期ないし一年における部下の技術面での成長が、 どのくらい優れたものといえるのか評価できなければ、 つまり毎回「よくできました」「もっとがんばりましょう」などの 概要評価ばかりでは、 部下のモチベーションが下がってしまうことでしょう。 まして、技術面で部下の能力を評価するのを放棄して、 部下の関わったプロジェクトの売上高をそのまま部下の評価としていては、 技術的に成長しようというモチベーションを持続させることは不可能でしょう。
給料の一部が売上 (ないし利益等) に連動する、 ということはあってもいいとは思いますが、 技術力に連動する部分もあるべきで、 技術的に大きく成長したときはきちんと給料に反映させ、 あまり成長できなかったときは何が足らないのか、 きちんと指摘してあげるべきだと思うのです。
それには、 部下それぞれの得意分野について、 パフォーマンスの観点では部下に劣ることがあったとしても、 少なくとも技術内容の理解の観点では勝るとも劣らないことが 重要ではないでしょうか。
もちろん、これとて容易なことではありません。 部下が極めて優秀な場合、 その技術的背景をマトモに理解するには大変な労力が必要となるかも知れません。 つい、技術で評価するのを放棄して、 技術とは関係ない点を持ち出したくなるものだと思います。 しかし、 いくら大変でも、いくら時間がかかっても、 部下の技術を一生懸命理解しようとすることが重要だし、 理解しようと努力し続けてはじめて、 「技術力ではないところで部下を評価してしまえ」という誘惑に 打ち克つことができるのではないでしょうか。
得意分野を見つける余裕がある会社
現在の仕事が自身の得意分野に一致していて、 かつその仕事が好きであれば、 技術者にとってそれは理想的な仕事と言えるでしょう。
一生の時間のうちのかなりの時間を仕事に費やすのですから、 一生かけて取り組みたいと思うようなことをすべきだと思うのです。 好きなことをやっててお金がもらえれば苦労はしない、 と多くの人は言うでしょう。 でも、本当に一生かけてもやりたいほど好きなことってありますか？面接 FAQ (4) から引用
しかし、 「やりたいこと」そのものズバリを、 最初に就職したときから仕事として やり続けてきた、 という人は少数派でしょう。 (私を含めて) 多くの人は、 いろんなことをやっているうちに、 「これだ」という仕事に出会い、 それにのめり込んでいくものなのではないかと思います。
あるいは、 今の仕事が一番自分に向いていると思っていたとしても、 なにかのきっかけで他の分野のことをやってみたら、 その分野のほうが魅力的であると感じ、 どんどん引き込まれてやっているうちに、 そっちのほうが自分に向いていることに気づく、 なんてこともあるかも知れません。
だから、 本業以外にも、 業務と関係ないことでも、いろいろ挑戦して欲しいと思っています。 ふとしたきっかけで始めたことが、 もしかすると自身の隠れた才能が開花することに 繋がるかも知れないのですから。
本業以外に熱中できる新分野を見つけた部下に対し、 「新分野を頑張るのはいいけど本業も忘れずにね」という忠告はするけど、 その新分野への取組みも大いに応援する、 KLab(株)はそんな会社でありたいと思っています。 勤務時間の 10% は本業以外のことを好き勝手にやっていい、 もし見込みが出てきて周囲から認められるレベルになったら、 それを本業にしてしまってもいい、 という「どぶろく制度」を作ったのも、 熱中できることを見つけるチャンスを逃して欲しくない、という思いからです。
本業の完璧な遂行もいいのですが、 自身の能力を最も発揮できる分野は一体何なのか考える余裕は持って欲しいですし、 技術者それぞれが最も自分に向いている仕事に出会えるように手助けすることこそが、 技術者のための技術会社の存在意義なのではないかと思います。
2007年05月01日ひろのぶさん、けいこさん、ご結婚おめでとうございます。
ご両家、ご親族の皆様、本日はまことにおめでとうございます。
どうぞ、おかけになって下さい。
私はひろのぶさんの勤務先であるKLab株式会社で 技術の責任者を勤めている仙石と申します。
ひろのぶさんは、 KLab株式会社で技術者として働いているわけですが、 技術者と言っても当然いろいろな職種があるわけで、 ひろのぶさんはシステム管理者と呼ばれる役割を担っています。
普通の方々にとっては、 「システム管理者」というのは馴染みのない言葉かも知れません。 「管理者」というと管理職のことを思い浮かべるかたも多いかもしれませんが、 管理する対象は人間ではなくてコンピュータのシステムということになります。 平たく言えば、たくさんのコンピュータがきちんと動くよう見張る仕事です。
縁の下の力持ち的な仕事で、ある意味とても地味な仕事といってもよいでしょう。 コンピュータが正常に動いている限り、システム管理者とは空気のような存在で、 ともすると存在を忘れられがちになります。
そしてシステム管理者に注目が集まるのは、 コンピュータにトラブルが起きたときです。 何やってんだ、早よ直せ！そういう罵倒がシステム管理者に向けられます。 仕事がうまくいってコンピュータがきちんと動いているときは空気のように忘れられ、 失敗してコンピュータにトラブルが起きたときは非難の矢面にさらされる、 なんとも損な役回りであります。
だから、システム管理者を目指そうとする人は、 世間一般で言うと、そんなに多くはない。 さらに、技術を磨いてより高いレベルのシステム管理者を目指そうという人は、 よほどの変わり者といってもいいかもしれません。
でも、逆に言うと、レベルの高いシステム管理者というのはとても貴重な存在、 ということになります。 私の感覚で言うと、一人前のシステム管理者は、おそらく全国に 1000人もいない。 何十万人もいるコンピュータ技術者の中で、たった 1000人です。 割合で言うと 1% よりもずっと少ない。 そういう稀有な人材の一人が、ひろのぶさんというわけです。
そういう貴重な人材だからこそ、 もっとシステム管理者の地位を向上させたい、 トラブルが起きたときだけでなく、システム管理者がいい仕事をしたとき —つまりコンピュータがいつもどおり動いているということなので、 あまり華々しさはないのですが— そういうときにも、 システム管理者がきちんと評価されるような、 そういった会社でありたいと思っています。
コンピュータが順調に動いているとき、 システム管理者は 一見、なにもしていないようにも見えてしまうのですが、 実際には、トラブルを未然に回避すべく、 いろんな創意工夫をシステムに盛り込もうとしています。 あるいはシステムに普段と違う様子がないか コンピュータの動作を常に気にかけています。 少しでも違った気配があったりすると、 とても心配して、気が気でなかったりします。
これはもう「愛情」と言ってしまってもいいかもしれません。
コンピュータのような無機物を「愛する」なんて言うと、 変人扱いされてしまいかねない今日このごろなのですが、 モノに対する愛を変なものと考える昨今の風潮は、 いかがなものかと思います。
古来から日本人は万物に霊が宿っていると考え、 様々なものを愛でてきました。 命あるものだけでなく、 そのあたりの石ころや、あるいや刀や兜など、 そういったものにも魂が宿っていると考え、 愛してきたのです。
そういうモノに対する愛が、 工芸品などの高い技術をはぐくんできたのだと思います。 現在、コンピュータに関する技術で日本は米国など諸外国に 大きく遅れをとっているわけですが、 その原因の一つは、 そういったモノに対する愛を忘れてしまったからなのかもしれません。 コンピュータだってソフトウェアだってもっと愛すべきだと思いますし、 そういう心が高い技術を生み出すのだと私は思います。
まとめますと、システム管理者の仕事というのは、 日ごろからコンピュータの具合に気を配り、 愛情を持って接し、 平穏な日常を最大の目標としつつ、 創意工夫を盛り込むことを忘れない、 そういう仕事です。
こうしてみると、システム管理ってのは、 円満な家庭を築くのと驚くほど共通点が多いのではないかと思います。
そういえば、 弊社においてもシステム管理者ってのは愛妻家が多いような気がします。
あ、もちろん、他の職種の人の家庭が円満ではない、と 言っているわけではないです、念のため。
優秀なシステム管理者であるひろのぶさんなら、 きっと素晴らしく円満かつ幸せな家庭を築いていける、、 そんな気がします。
というわけで、 なんとか無事、 お話が結婚のお話に結びついたところで、 お祝いの言葉とさせていただきます。
本日は誠におめでとうございます。
2007年04月24日ここ何ヵ月か、就職活動中の多くの学生さん達と話す機会を得ました。 いろんな方々と話しているうちに、 会社選びをしているはずの当の学生さん達の多くが、 いい会社の条件について確固たる基準を持っているわけではない、 という思いをますます強くしました。
「安定している会社」「福利厚生が充実している会社」「技術を教えてくれる会社」 などなど、 なんとなく「いい会社」のイメージを思い描いているだけで、 それが自身の人生にどう役に立つか、 筋道だった考えを持っているわけではないことに 改めて驚かされます。
安定している会社
「いい会社」のイメージとして、多くの学生さんがいだくものの筆頭は、 「安定している会社」「儲かってる会社」「勝ち組企業」でしょう。
先月 4/14 19:30 NHK で、 特報首都圏「就職戦線異状あり・格差社会の不安」と題する番組があった。 新卒の学生さん達が「勝ち組になる」ことを目指して 就職活動を行なっているのだという。
そりゃ、勝てるものなら勝ちたいと思うのは人の常なので、 これから社会に出ていこうとする学生さん達が、 将来勝ち組になれるような就職先を選ぼうとするのは至極当然のことだと思う。
ところが
学生さん達曰く、「勝ち組になるため、儲かっている会社に就職したい」。勝ち組になるには から引用
ここんところ選挙などもあったからか、 「格差是正」を訴える声を聞くことが多かったのですが、 そもそも「格差」ってのは、 誰と誰との間の格差なんでしょうか？ 「儲かっている会社に勤めている人」と、 そういう「いい会社」に雇ってもらえない人との間の格差なんでしょうか？ 自身の実力は関係なくて、 「いい雇い主」に雇ってもらえるか否かが重要なんでしょうか？ こういう発想には、まるで 「いい家柄」の出身かどうかを気にする階級主義者や 「血筋」を気にする人種差別主義者と似たニオイを感じてしまうのです。
「儲かってる会社」に勤めていて、高い給料をもらっていたとしても、 その能力は会社の中だけでしか通用しないものかも知れず、 逆に、儲かってない会社に勤めていたとしても、 自身の能力を磨くことを怠らなければ、 会社を飛び出して活躍できるようになるかも知れないってのは、 誰もが思っていることですよね？ 昔は儲かっていたけど、 今では会社が傾いて、ついにはリストラされてしまった、 ってのもよく聞く話です。 「最後に頼れるのは己れの実力だけ」って 誰もがよく口にするわりには、 こと「格差」を考えるときに限っては、 「実力」より「どんな会社に勤めているか」のほうが先に出てくるのは なぜなんでしょうか？
「実力を磨きたいのは山々なれど、 実力を磨かせてくれるいい会社がない」とか、 「実力うんぬん以前に、 まず先立つモノ (給料) がないと」とか、 「実力はあるつもりだが、 それを正当に評価してくれる会社がない」とか、 そういった声が聞こえてきそうです。
確かに、ほとんどの会社は 実力を磨かせるより、コキ使うほうを優先するかも知れませんし、 実力をきちんと評価してくれない会社が圧倒的多数なのかも知れません。 しかしながら、世の中の 99.9% までそういう会社だったとしても、 実際に勤める会社は (当たり前ですが) たった一社でいいんです。 圧倒的多数の会社が社員の能力を伸ばすことに非協力的だったとしても、 そんなことはどーでもいいじゃないですか。 重要なのは自分が実際に就職する会社がどんな会社であるかであって、 世の中の会社の平均がどんな状況かではないのですから。
福利厚生が充実している会社
「安定している会社」を求める以上に不可解なのが、 「福利厚生の充実度」を気にする学生さん達です。 いったい会社に行って何をするつもりなんでしょうか？
自身の実力で会社に利益をもたらし、 その見返りに報酬を得る、というのなら筋が通っていますが、 それなら「福利厚生」みたいな中途半端なものを求めるまでもなく、 ストレートに自身の貢献に見合う「お金」を要求すればよい話です。 「お金」を求める自信も度胸もないからこそ、 「制度」としての「福利厚生」を求めるのでしょうが、 実力が足らないのを自覚しているのなら、 「福利厚生」を享受するなんて余裕をかましている場合じゃないでしょう？
これから社会に出ていく学生さん達が最優先で取組むべきことは、 会社と対等に渡り合える実力を身につけるために、 いま何をすべきか考えることでしょう。 そんな実力を身につけることは自分には永遠にムリと思う人がいるかもしれませんが、 ムリと思えば思うほど実現は遠退きます。 世の中にはいろんな会社があるのですから、 自身の能力を磨くのに適した会社は、 見つけようとしさえすれば、きっと見つかるはずです。
「20:80 の法則」 (パレートの法則) というものがある。 「売上の8割は、全従業員のうちの2割で生み出している」などの経験則が知られるが、 じゃ、その 2割の従業員だけでドリームチームを作れば、 すごい会社が作れるかというと残念ながらそうは問屋がおろさない。 「2割の従業員」がふたたび「20:80」に分かれてしまうのである。 精鋭チームを作ったつもりが、 そのチームの中の多数 (8割) は売上にあまり貢献しなくなってしまう。 逆に、ダメな従業員だけを集めたダメダメチームを作っても、 その中の 2割ほどは頭角を現し、チームを率いるようになる。
つまり能力を向上させる最良の方法は、自分が上位 20% に入ることを目指せるような集団に属することである。 まさに「寧ろ鶏口となるも牛後となるなかれ」。 上位20% に入ることがどうしても無理なら、 それはその集団が向いていないということである。 牛後に甘んじるよりは思い切って飛び出すべきだろう。
会社をイメージで選ぶのではなく、 どんな会社が自分にとって「いい会社」なのか、 考えることから始めるべきではないでしょうか。
技術を教えてくれる会社
「安定している会社」や「福利厚生」を求めるのに比べれば、 まだマシなのが「技術を教えてくれる会社」を求める学生さん達です。 少なくとも自分の能力を向上させようという意欲は持っているのですから。 しかしながら、 「受け身」の姿勢であるという点では、 大差ないのかも知れません。
「技術を教えてもらう」という態度では、 おそらく永久に上位 20% に入ることはできないでしょう。 「技術は伝えるものではなく伝わるもの」なのですから、 教える側に「充実した伝える方法」(例えば完備された指導マニュアル) を 求めている限り、 決して師匠に追い付くことはできません。 技術の習得に関して誰よりも貪欲であり続けなければ、 上位 20% を目指すどころか、 平均的な先輩たちを追い越すことすら覚束ないことでしょう。
つまり、技術を学ぼうとするなら、 その時点での実力はサテオキ、 「伝わる状態」にかけては自分が一番だと自信を持って言い張れる (つまり、その技術を学びたいという情熱にかけては誰にも負けないと言いきれる) 状態からスタートしなければならないのです。
「技術力のある会社に就職すれば、 そこそこの技術を身につけることができる」 そう考える人が多いのかも知れませんが、 これは二重の意味で間違っています。 すなわち、 「伝わる状態」ができていなければ学べないという意味で間違っているだけでなく、 仮に技術を身につけることができたとしても、 「そこそこの技術」では役に立たないという意味でも間違っています。
インターネットなどの普及によって技術に関する情報が巷に溢れる昨今、 「そこそこの技術」であれば、 会社に勤めなくてもいくらでも身につけることができます。 いやむしろ、 会社に勤めることよりも学ぶ意欲のほうがよほど重要でしょう。 技術力のある会社に就職したから技術が身につく、 なんて甘い考えでいる限り、 できることといえば「技術に慣れる」ことどまりでしょう。
長年やっていれば、誰でもそれなりの技術を習得できます。 極端なことを言うと、 どんなに能力がない人でもそのときの自分の状態にあった程度のことを 実践していけば、 その積み重ねの中でやがてはなんらかの技術を習得することができます。
しかし、このようなものは本来、技術の伝達とはいえません。 これを技術の習得というのも不適切で、 ただ単に技術に慣れただけというのが正確な言い方でしょう。
じつはこのように、 経験と慣れだけで技術を獲得してきた人は世の中にたくさんいます。 私はこういう人を「偽ベテラン」と呼んでいます組織を強くする技術の伝え方 (畑村 洋太郎 著) から引用
「偽ベテラン」レベルの能力では、 「会社と対等に渡り合える」わけもなく、 そんな「使えない」能力を身につけるくらいなら、 別の分野を目指すべきだった、ということになってしまうかも知れません。
だから、高い技術力を持つから「いい会社」なのではなく、 その技術が自分自身が本当に身につけたいと心の底から思えるような 技術か否かのほうが重要だと思いますし、 技術の高さ低さよりは、 自身が技術を身につけていこうとする際に、 「役に立つ」会社か否かを見極めることのほうが重要だと思います。
では、どんな会社が技術者の成長に役立つ会社なのでしょうか？
続きは次回に...
2007年03月19日「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つくりませんか？」
2007年02月19日私は「やりたいことを仕事にすべき」と常日頃から主張しているのですが、 自分自身のことを振返ると、 必ずしも「やりたいこと」そのものズバリを 最初からやっていたわけではないことに気づきます。
「鶏がさきか、卵がさきかの議論になっちゃうんだけど」なんて枕詞があるが、 こと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 ないし負数であるブロックは、 コントロール用のブロックで、 以下の意味を持っています:
| データ長 | 意味 | 内容 |
|---|---|---|
| 0 | EOF | Webセッションの終了を要求 |
| -1 | Error | Webセッションの異常終了を要求 |
| -2 | Keep Alive | 無通信状態が続いたときに送信 |
| -3 | X OFF | Webセッションのデータ送信の一時停止を要求 |
| -4 | X ON | Webセッションのデータ送信の再開を要求 |
ブラウザ送ったリクエストを 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 以外のプロトコルを通す機能などがない点や、 高負荷時の性能の検証が充分行なえていない点など、 そのまま実運用に使用するには難しい点もありそうですが、 少なくとも プロトタイピングなどの目的 (あるいは教育などの目的) ならば 充分使えそうです。
2007年01月17日いよいよ就職活動本番ですね。 どのような進路を選ぶにせよ、 あとで後悔することのないよう、 じっくり考えて決めたいものですよね。 でも、ただ単に考えると言っても、 一人であれこれ思い悩むのは感心しません。 「思いて学ばざれば則ち殆し」と言いますから、 ぜひいろいろ見聞きした上で考えて頂きたいと思います。
企業への就職を考える場合、まず気になるのは評価制度のことだと思いますが、 まさにこの評価制度が揺れ動いているのが、いま現在と言えるでしょう。 高度成長期以来、長年用いられてきた年功主義に基づく評価制度の綻びが 誰の目にも明らかになってきてはいるものの、 年功に代わる評価方法を模索し続けているのが 多くの企業の現状だと思います。
どこの企業も新しい人事制度を模索し、成果主義が取り入れられつつありますよね。 （同時にコスト削減という意味合いもありますが）
この成果主義という人事制度ですが、 多分どこの会社でもおおよそこんな感じなのではないでしょうか。
●年初に目標を設定（部署ごとの目標・個人の目標）
●3ヶ月か半年ごとに上司と面談
●成果をアピール
●評価の通知
一見、単なる年功序列よりは凄くまともそうなシステムに見えますよね。 でも、実際には明らかな欠点があると思います。 （評価する側の上司がそもそも年功序列組だという点は除いて）
◆短期間にアピールできるようなものにばかり心奪われるようになる
◆業績アピールに繋がらない日常の雑用や、他人の手伝いは避けるようになる
どちらも当たり前の弊害だと思うのですが、 多くの企業ではこれらの問題について見て見ぬフリをしているのではないでしょうか？「成果主義と生産性のゆくえ」から引用
ぜひこういった疑問を、どんどん企業にぶつけていって頂きたいと思います。 就職活動というのは、いろんな企業に対して歯に衣着せぬ質問ができる 唯一と言ってもいい機会なのですから。
「評価」には二つの側面があります。 「評価される側」と「評価する側」です。 上に引用した文章は、 「評価される側」にフォーカスした疑問と言えるでしょう。 もちろん学生さんは就職したら評価される側になるので、 「評価される側」から考えたくなるのは当然だと思いますが、 なにごとにも表と裏があります。 片方の側からだけ考えていては考えを深めることはできません。 ぜひ、自分とは異なる立場の視点も持つ習慣を身につけて頂きたいと思います。
「評価」を両方の側から考えてみれば、 「短期間にアピールできるようなものにばかり心奪われるようになる」というのは 評価される側の理屈に過ぎないことは自明ですよね？ つまり暗黙のうちに、 アピールがそのまま通るような「無能な上司」を前提としてしまっています。 もし、「評価する側」が 「業績アピールに繋がらない日常の雑用や、他人の手伝いは避ける」人の 評価を下げるのであれば、 このような弊害を避けることは可能でしょう。
引用した文中に「評価する側の上司がそもそも年功序列組だという点は除いて」と ありますが、 まさにこれこそが問題の本質だと思います。 「除いて」しまっていては考えが深まりません。
どのような人事制度であれ、 「評価する人」と「評価される人」の双方に、 その制度の「精神」が徹底できていなければ機能するはずがありません。 そして、 「評価される人」への徹底は、 そもそも徹底できていなければ評価が下がるので、 否が応にも徹底されるわけですが、 「評価する人」への徹底ができるかどうかは、 「評価する人」を評価する人、つまりその上の上司の責任です。
より具体的に言えば、 「短期間にアピールできるようなもの」「アピールしやすいもの」 ばかりを評価の対象としてしまって、 部下の本当の価値を評価できていない上司を、本当に降格できるのか？ という問題でしょう。 年功主義では過去の功労者が上司となるケースが多いようですが、 過去に成果を上げた人が、 現在の部下の成果を評価できるのか？ という問題であるとも言えますね。
製品には、どうしても長期的な投資が必要なものがあると思います。
例えば日亜化学の青色LEDだって、中村氏が個人で何年もかけて、 会社の中止命令を無視してやり遂げたと著書にありましたし。
もし青色LED開発中に、 3ヶ月ごとに面談していたらどんな評価がされるんでしょう？
失敗続きで亀のようにのろく、先が見えない実験の繰り返しでしょうから、 それらの失敗が将来大きなリターンになって返って来ることを 強く確信している人でなければ、続けられませんよね。「同ページ」から続けて引用
「技術者の成果」とは何でしょう？
技術者が作ったものから得られる売上でしょうか？ もちろん、それだけではないですよね？ 「青色LED」のように最終的に莫大な利益を生み出したものは、 とても分かりやすい「成果」ですが、 サーバシステムの運用などのような縁の下の力持ちの仕事だって 立派な成果ですし、 さらに、 自分自身では何も生み出さなくても、 社内の技術者を育てることや、 社内の技術をブログなどで発表して会社の知名度を上げることなども、 立派な成果と言えるでしょう。
したがって「3ヶ月ごとの面談」という制度が問題なのではなく、 きちんと技術者を評価できない上司をそのままにしておくのが問題なのです。 そしてそういう上司をそのままにしている上司の上司も問題ですし、 そのまた上の上司の上司の上司にも責任があります。
こうやって責任の連鎖を上へ上へ登っていくと、 技術者の評価制度が機能するか否かは、 技術者の評価について最終的な責任を負う人がいるのか？ という点に行き着くことになります。
技術者を目指す学生のみなさんには、 ぜひこの点 ──この会社では誰が技術者の評価の最終責任を負っているのか？── を押えた就職活動をするようお勧めします。 そしてできれば、「誰が責任者か」だけでなく、 その責任者がどんな考えを持っているのか調べられるものは全て調べ、 さらに疑問点があれば直接会ってでも質問するくらいの勢いで 臨んで欲しいと思います。
兼 最高技術責任者
仙石浩明
2007年01月15日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 ディレクトリへコピーしてください。 以下の実行例で�