仙石浩明の日記

2006 : April

2006年4月30日

勤労の義務

「勤労の義務」は、 言うまでもなく日本国憲法第27条に規定されている、 日本国民の3大義務の一つであるが、 そのそろこの勤労に対する固定観念をかえていくべきなのではないか? 来るべき共産社会へのビジョンは、 Web2.0 で初めて見えてきたわけでは決してなく、 何十年も前から様々な形で繰り返し描かれてきた。 例えば、

断絶への航海 ハヤカワ文庫 SF (586)
ジェイムズ・P・ホーガン (著), 小隅 黎

などの近未来小説などの形でも。 SF においては、StarTrek を引き合いに出すまでも無く、 未来には貨幣経済が存在しないという設定のほうが、 むしろ普通となっている。

にもかかわらず、いまだに資本主義以前の ナイーブな勤労観がはびこっているのは、 憲法に基づく洗脳教育のたまものなのだろうか?

人力検索はてな から引用:

「年収300万の自分にとって最高に面白い仕事」か「年収1000万の自分にとって最高に面白くない仕事」どちらかを一生しなくてはならないとしたらあなたはどちらを選びますか?その理由は?

この質問者にとっては、面白くても、面白くなくても、 仕事は仕事なのだろう。 そこにはストックという概念すら存在せず、 ただフローを得るための勤労という思い込みに囚われている。

まずバランスシートを義務教育で教えるべきなのだろうか?
それとも、貨幣経済を飛び越して Web2.0 を教えるべきなのだろうか?

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

livedoor blog 生ログ取得スクリプト (1)

すでに誰かが絶対に書いているはずとは思ったのですが、 探すよりも書いた方が早そうだったので、 livedoor ブログの生ログを取得する perl スクリプトを 書いてみました。 ついでに、デザインをカスタマイズしたときの、 スタイルシート(CSS)やHTMLのテンプレートも取得できます。 例えば、

livedoor.pl gcd raw_log 10 log.csv

などと実行すれば、10 ページ分 (200行) の生ログを、 CSV 形式でファイル「log.csv」に保存できます。 また、

livedoor.pl gcd index_tmpl index.html

などと実行すれば、インデックスページのHTMLテンプレートを、 ファイル「index.html」に保存できます。 第一引数「gcd」の部分には、 ブログのアカウント名 (スクリプトの先頭部分で定義しています) を 指定してください。 私の場合、 「GCD 日記」と 「仙石浩明CTO の日記」の 二つのブログアカウントがあるので、 それぞれ「gcd」と「klab」という名前で定義しています。

余談ですが、二つのブログを書いているのは、 個人用と会社用とを区別しようというわけではありません。 もともと私のなかでは趣味と仕事の境界線が曖昧なので、 個人と会社でブログを区別しようとしても混ざってしまうでしょうから、 区別することに意味があるとは思えません。 じゃ、なぜ二つのブログなのかと言えば、 「GCD 日記」のほうが よりメモ的でネタを蓄えておき、ある程度考えがまとまったものを 「仙石浩明CTO の日記」へ 書こう、というのが そもそもの意図でした。

やっつけ仕事なので、突っ込みどころ満載(^^;) のスクリプトだとは思いますが、 livedoorブログをお使いの方はご利用頂ければ幸いです。 もちろん、ご利用の際は先頭部分のユーザID & パスワード等を 適宜修正してください。 また、スクリプト中で日本語を使っているので、 このスクリプトは EUC-JP で保存する必要があります。

livedoor.pl (livedoor blog 生ログ & CSS/テンプレート 取得スクリプト)

#!/usr/bin/perl
use LWP::UserAgent;
use HTTP::Request::Common;
use CGI qw/unescapeHTML/;

%blogs = (
    "gcd" => {
        "User"   => "hiroaki_sengoku",
        "Pass"   => "xxxxxxxx",
        "BlogID" => 1600549,
        "ID"     => 11111,
        "PageID" => 22222,
    },
    "klab" => {
        "User"   => "klab_sengoku",
        "Pass"   => "yyyyyyyy",
        "BlogID" => 1631449,
        "ID"     => 33333,
        "PageID" => 44444,
    },
);

&help unless $_ = shift;
if (my $blog = $blogs{$_}) {
    $User =   $$blog{"User"};
    $Pass =   $$blog{"Pass"};
    $BlogID = $$blog{"BlogID"};
    $ID =     $$blog{"ID"};
    $PageID = $$blog{"PageID"};
} else {
    &help;
}

$ua = new LWP::UserAgent;
$ua->agent("Mozilla/5.0 (Windows; U; Windows NT 5.1; ja)");
$ua->env_proxy();
$ua->cookie_jar( {} );
my $res = $ua->request(POST "http://member.livedoor.com/login/index",
                       [ "livedoor_id" => $User, "PASSWORD" => $Pass,
                         ".next" => "", ".sv" => "" ]);
while (my $type = shift) {
    if ($type eq "css" || $type eq "index_tmpl" || $type eq "article_tmpl" ||
        $type eq "category_tmpl" || $type eq "monthly_tmpl") {
        my $file = shift;
        open(OUT, ">$file") || die;
        my $url = "http://cms.blog.livedoor.com/cms/design/edit"
            . "?tmpl=$type&blog_id=$BlogID&id=$ID";
        my $req = new HTTP::Request GET => $url;
        my $res = $ua->request($req);
        if ($res->content =~
            /\<textarea .*name=\"content\" [^\>]*\>([^\<]+)\<\/textarea\>/) {
            my $content = unescapeHTML($1);
            $content =~ s/\r\n/\n/g;
            print OUT $content, "\n";
        }
        close(OUT);
    } elsif ($type eq "raw_log") {
        my $npage = shift;
        ($npage =~ m/^\d+$/ && $npage >= 1) || &help;
        my $file = shift;
        open(OUT, ">$file") || die;
        my $url = "http://analyzer.livedoor.com/log/raw?page_id=$PageID";
        my $prepat = '\<td\b[^\>]*\>\<strong\>\<small\>';
        my $postpat = '\<\/small\>\<\/strong\>\<\/td\b[^\>]*\>';
        for (my $i=1; $i <= $npage; $i++) {
            my $req = new HTTP::Request GET => "$url&p=$i";
            my $res = $ua->request($req);
            my $datepat = '\d\d\d\d\-\d\d\-\d\d \d\d\:\d\d\:\d\d';
            my $date;
            for (split(/(\<small\>$datepat\<\/small\>)/, $res->content)) {
                if (/^\<small\>($datepat)\<\/small\>$/) {
                    $date = $1;
                } elsif (/^\<\/th\>\s*\<\/tr\>\s*/) {
                    my @record;
                    for (split(/\<\/tr\>\s*/, $')) {
                        my $column;
                        if (/$prepat(.*)$postpat/o) {
                            if ($1 eq 'URL') {
                                $column = 0;
                            } elsif ($1 eq 'リファラ') {
                                $column = 1;
                            } elsif ($1 eq 'ブラウザ') {
                                $column = 2;
                            } elsif ($1 eq 'リモートホスト') {
                                $column = 3;
                            } else {
                                die "Unknown column: $_\n";
                            }
                        }
                        if (/\<td\b[^\>]*\>\<small\>(.*)\<\/small\>\<\/td\b[^\>]*\>/){
                            $_ = $1;
                            s/\<\/?a\b[^\>]*\>//g;
                            if (/,/) {
                                s/\"/\"\"/g;
                                $_ = "\"$_\"";
                            }
                            $record[$column] = $_;
                        } elsif (/^\<\/table\>/) {
                            last;
                        } elsif (! /^\<tr\>\s*\<th\b[^\>]*\>/) {
                            die "Unknown format: $_\n";
                        }
                    }
                    print OUT $date, ",", join(',', @record), "\r\n";
                }
            }
        }
        close(OUT);
    } else {
        &help;
    }
}
exit 0;

sub help {
    print "Usage livedoor <blog> <opt>...\nblog: ",
    join("\n      ", keys %blogs), "\n",
    'opt:  css <file>
      index_tmpl <file>
      article_tmpl <file>
      category_tmpl <file>
      monthly_tmpl <file>
      raw_log <n> <file>
';
    exit 1;
}
Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 09:07
2006年4月29日

面接FAQ: 仮に、何をしてもいい、と言われたら、何をしますか? hatena_b

弊社の面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法。 今までお話ししてきたことをいったんまとめてみます。

(1) 高い技術力って例えばどんなことですか?
志望動機が「技術を学びたい」なのに、 肝心のその技術がどういうものかイメージできていない、 言い換えれば自分が何をしたいのか実は分かっていない、 これはかなり問題ですよね?
(2) 何か質問はありませんか?
面接を受けに来て、なにも質問しようとしない人がいます。 分かっていないのに分かったつもりになってしまう、 これは技術者にとって致命的なことです。 どこまでも自分が分かっていないことを自覚し、 探求し続ける習慣が無ければ、スキルアップは覚束ないでしょう。
(3) 前職でいくらもらっていましたか?
前職給に基づいて給与を決めるため、というわけでは決してなく、 KLab の給与体系にスムーズに移行できるか判断するためです。

今回の質問は、

生活するために働かねばならない、ということが仮になかったとしたら、
仮に、一週間何をしてもいい、と言われたら、何をしますか?

なぜこんな質問をするかと言えば、自分は本当は何をしたいのか 考えてもらいたいからです。

自分が何をしたいか? そんなことは分かっているに決まっているじゃないか、 お金に困らないなら好きなことをするさ、と多くの人は言うでしょう。

じゃ、好きなことって何ですか?

仕事しなくてもいいのなら、あれもしたい、これもしたい、...

その中で一番やりたいのは何ですか?

一日中、寝続けたい。
浴びるほど酒を飲みたい。
何も考えずにぼーっとしていたい。
...

まあ好きにやっててください。(^^;)
もちろん気分転換は必要なので、 時にはハメを外すことも必要でしょう。 でも、何かをやっているからこその気分転換ですよね。 年がら年中、気分転換し続けるわけにはいきませんよね。

だから~、普段は嫌な仕事をやってて、 おまけに残業続きで忙しくて忙しくて、 たまに休日があっても疲れているから何もする気が起きず、 あ~ 仕事しなくてもいいなら好きなことができるのに~

いえ、だからその「好きなこと」ってなんでしょう?
というのが質問なのですが... (-_-;)

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

もしあるなら、その「好きなこと」をやってても生活できない と判断するのはなぜでしょう? 一生かける覚悟があるなら、大抵のことは成し遂げられるでしょう。 嫌々仕事をしたって、好きでやってる人に勝てるはずはありません。 鶏口となるも牛後となるなかれ、 好きなことをしよう

もしそれほど「好きなこと」がないのなら、なぜ探さないのでしょう?
一生かけて嫌々仕事をするのでしょうか。何のために?
生活のため、というのは自分自身への いいわけ なのでは?

- o -

今日から五月連休ですね。 会社によっては 9 連休のところもあるとか。
あなたは何をしますか?

More...
Filed under: 自己啓発 — hiroaki_sengoku @ 09:41
2006年4月29日

SSL_connect に時間がかかる場合の挙動

epoll版 stone のバグを長いこと放置していた... orz
(1) getident
(2) SSL_connect に時間がかかる場合の挙動

(1) のバグは、sd = socket() するまえに epoll_ctl(epfd, EPOLL_CTL_ADD, sd, &ev) していた、という単純バグ。なぜ epoll_ctl が失敗しなかったというと sd を初期化していなかったので、たまたま有効なディスクリプタだったのだろう。これは順序を入れ替えるだけで fix.

(2) は、少し複雑。stone は中継先に connect する際、どのタイミングで接続が確立するかで処理のパスが変わる。たとえば connect が EINPROGRESS を返すと epoll/select 待ちするが、connect を呼び出した時点で接続が確立すれば、直接 readWrite ループへ遷移する。

SSL がからむともっと複雑になる。SSL_accept が完了するまで中継先が決まらない場合もあるし、TCP接続が確立しても SSL接続がなかなか確立しない場合もある。SSLハンドシェークに時間がかかる場合、SSL_accept / SSL_connect は readWrite ループで呼び出されることになる。

SSL_connect が完了する前に中継元からの入出力が行われてはまずいので、readWrite ループ内の epoll/select 待ちでは中継元側のディスクリプタは監視対象からはずしているわけだが、SSL_connect が成功した時点で監視対象に含めなければならない。select 版では正常に動作するのだが、epoll 版では監視対象に含め損なっていた。

     ret = SSL_connect(ssl);
     if (ret > 0) {     /* success */
+       Pair *p = pair->pair;
        /* pair & dst is connected */
        pair->proto |= (proto_connect | proto_dirty);
+       if (p) p->proto |= proto_dirty; /* src */

接続元側 Pair の proto に、proto_dirty フラグを設定することにより、epoll でも監視対象に含めるようになる。 これで epoll 版も正常に動くようになったはず。
現在 senri で動作検証中...

$Id: stone.c,v 2.2.2.20 2006/04/28 21:50:24 hiroaki_sengoku Exp $

Filed under: stone 開発日記 — hiroaki_sengoku @ 07:44
2006年4月28日

Haskell

遅ればせながら Haskell で遊んでいます。 KLab の技術者の中にも、手続き型言語の世界に どっぷりつかっていて他の世界を知らない人は いるので、 tech ML (技術者向の KLab 社内メーリングリスト) で Haskell の紹介をしてみました。

~~ tech ML に投げたメールここから ~~
Subject: [tech:8480] Haskell

仙石です。

唐突ですが、Haskell って知ってますか?

私は面接した人に教えてもらった ;) のですが、最近流行りの関数型言語です。
ブログを見てると、あちこちで話題になっていますね。
入門用のページ:

  やさしい Haskell 入門 (バージョン98)
  http://www.sampou.org/haskell/tutorial-j/index.html

「やさしい」と書いてますが、関数型言語を初めて学ぼうとする人には敷居が
高いかも知れません。まずは簡単な Haskell プログラムを見てみましょう。

------------------------------------------------------------------------
guusuu x
  | x `mod` 2 == 0  =  True
  | otherwise       =  False
------------------------------------------------------------------------

これは guusuu(x) という関数の定義です。

  x を 2 で割った余りが 0 ならば、guusuu(x) = True
  それ以外ならば、                guusuu(x) = False

と読みます。簡単ですね? ;)
早速実行してみましょう。
上記プログラムを test.hs というファイル名で保存しておいて、
Haskell 処理系である ghci コマンドを実行します。

------------------------------------------------------------------------
senri:/home/sengoku/tmp % ghci
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version 6.4.2, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base-1.0 ... linking ... done.
Prelude> :load test.hs
Compiling Main             ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> guusuu 2
True
*Main> guusuu 7
False
*Main>
------------------------------------------------------------------------

「:load test.hs」というのが「test.hs」を読み込むためのコマンドです。
「guusuu 2」を実行すると、guusuu(2) の値である True が出力されていますね。
これだけだと、あまり能がないので、偶数列を表示させてみましょうか。

------------------------------------------------------------------------
*Main> take 10 [1,2..]
[1,2,3,4,5,6,7,8,9,10]
*Main> take 10 [x|x <- [1,2..], guusuu x]
[2,4,6,8,10,12,14,16,18,20]
------------------------------------------------------------------------

「take 10」というのはその後ろのリストの先頭 10 個の要素を取り出す関数で
す。「[1,2..]」というのは自然数列のリストですね。take を使わずに [1,2..]
を表示させようとすると、無限に自然数列を表示します。

------------------------------------------------------------------------
*Main> [1,2..]
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, ...無限に続く...
------------------------------------------------------------------------

途中で止めるには control-C を押します。
さて、

  [x|x <- [1,2..], guusuu x]

という書き方は、グラフ理論の輪講に参加している人や、述語論理を学んだこと
のある人にはおなじみの書き方じゃないでしょうか。自然数列の中で、
述語 guusuu(x) が True であるような x のみ取り出したリスト、という意味です。

じゃ、このプログラムはどうでしょう?

------------------------------------------------------------------------
hurui [] = []
hurui (top:rest) = top:(hurui [x|x <- rest, x `mod` top /= 0])
------------------------------------------------------------------------

関数 hurui は引数としてリストをとります。「[]」は空リストです。つまり要
素が何もないリストですね。引数が空リストならば hurui [] の値も [] です。

引数が [] でない場合は、引数のリストを、先頭 top と残り rest に分解します。
例えば hurui [3,5,9,11,13] の場合、top が 3 で rest が [5,9,11,13] です。

# このあたり、lisp を知っている人にはおなじみの概念ですね

次に top と (hurui [x|x <- rest, x `mod` top /= 0]) をつなげたリストを、
hurui の値として返します。「:」がリストを作るための演算子です。

# lisp で言うところの cons と言えば lisp を知っている人には簡単ですね

では (hurui [x|x <- rest, x `mod` top /= 0]) とは何でしょう?

「/=」というのは等しくない、という演算子です。C で言うところの「!=」です
ね。つまり、rest の中で「x `mod` top /= 0」が True になるものを取り出し
たリストを求め、これを引数として hurui を再帰呼出しして求めたリスト、と
いうことになります。

top が 3 で rest が [5,9,11,13] でしたから、3 で割って余りが 0 でない
(つまり 3 で割り切れない) もののリスト、ということになります。9 以外は 3
で割り切れないので [5,11,13] ですね。これを引数として hurui に与えます。
つまり、3 (top の値) と hurui [5,11,13] の値をつなげたリストが答になりま
す。

同様に hurui [5,11,13] の値は、5 と hurui [11,13] (11 も 13 も 5 では割
り切れないから) の値をつなげたリストですね。というのをどんどん再帰的に繰
り返すと、hurui [3,5,9,11,13] の値は [3,5,11,13] になります。実際に試し
てみましょう:

------------------------------------------------------------------------
*Main> hurui [3,5,9,11,13]
[3,5,11,13]
------------------------------------------------------------------------

スルドイ人はすでに分かっていると思いますが、
この関数は「エラトステネスの篩」です。したがって、

------------------------------------------------------------------------
*Main> take 20 (2:hurui [3,5..])
[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]
------------------------------------------------------------------------

などと実行することにより、20個の素数を列挙することができました。

どうです? 面白いでしょう?

関数型言語を知っている人は、たぶん Haskell もすぐ使いこなすことができる
と思いますし、関数型言語を知らない人は、ぜひこの機会に知ることをオススメ
します。なぜなら関数型言語を知らないプログラマってプログラミング言語の世
界の半分しか知らないわけで、Haskell を学ぶことにより世界が大きく広がると
思うからです。

関数型言語を初めて学ぶ人は、まずは

  入門Haskell―はじめて学ぶ関数型言語
  向井 淳 (著)

あたりを読むのがいいかも知れません。私の机の上に置いておくので、興味ある
かたはどーぞ (先着一名様限定)。

この本は、副題にもあるように関数型言語を初めて学ぶ人向けに書かれているの
で、イマイチ本質を外しているんですよねぇ... だから本音ではオススメな本で
はない ;-) のですが、関数型言語へのとっかかりとしてはよいのかも知れません。

#13425                                                          仙石 浩明
https://www.gcd.org/sengoku/             Hiroaki Sengoku <sengoku@gcd.org>
~~ tech ML に投げたメールここまで ~~

このメールに一番早く反応したのは、KLab の開発に参加いただいている 協力会社 H 社の CTO の T さんでした。 T さんとはご無沙汰していたのですが、 彼も私と同様に Haskell で遊んでいたことが分かって、 さすがと思った次第。

# 協力会社さんに負けずに頑張ってね > KLab 社員

~~ T さんのメール(一部抜粋)ここから ~~
ご無沙汰しております。
H 社の T です。

Hiroaki Sengoku wrote:
> 唐突ですが、Haskell って知ってますか?

なぜか私も、今月の頭ぐらいにとあるブログで知って(YAPC::Asia 2006のPugs関連
のエントリだったような…)

>   入門Haskell―はじめて学ぶ関数型言語
>   向井 淳 (著)

を購入して、ひそやかに楽しんでおりました。
そして、いやあ、これは、自分だけ楽しんでいるには余りにももったいないので、
(H社内の)勉強会のネタにしようと宣言していた矢先に、投稿を拝見しまして、
つい反応してしまいました。
~~ T さんのメール(一部抜粋)ここまで ~~

KLab でも Haskell 勉強会やりましょう!

Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 06:32
2006年4月27日

新卒採用 (2)

先日紹介した学生さんを対象とした会社説明会

KLab(株) CTO 仙石 (KLabセキュリティ(株) CTO を兼務) と語る、
「技術者の成長にとって一番役に立つ会社」
「技術者が自ら伸びていくことができる会社」とは?

日時: 5/9(火) 13:30~15:00
場所: KLab(株) 本社会議室 (六本木ヒルズ森タワー 20F)

が、おかげさまで満席につき二回目が実施されるそうです。

日時: 5/15(月) 13:30~15:00
場所: KLab(株) 本社会議室 (六本木ヒルズ森タワー 20F)

会社説明会といいつつ、要は私といろんな話題についてお話しましょう、
というノリですので、私の日記 (CTO日記もよろしく) を見て、
波長が合いそうだと思ったかた、ぜひ登録をお願いします。

5/8 追記: 上記説明会は満席につき、現在は 5/30実施の説明会への登録を受付中です

Filed under: 技術者の成長 — hiroaki_sengoku @ 15:40
2006年4月27日

面接FAQ: 前職でいくらもらっていましたか? hatena_b

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

多くの企業同様、KLab の面接でも「前職でいくらもらっていたか」は 当然のように質問します。 が、それは前職給に基づいて給与を決めるため、というわけでは決してなく、 KLab の給与体系にスムーズに移行できるか判断するためです。

世間一般的には、まだまだ年功序列の給与体系のようで、 年齢が高くなるとどうしても給料が高くなる傾向にあります。 例えば先日面接した人は、 5年前から成長が止まっているように見受けられました。 5年間さしたる進歩もないのに、 給料のみが上がってしまっている、 いまさら 5年前の給料で雇うのも無理な話ですし、 5年間成長が止まっていた人が転職で突然伸び始める可能性は 低いと判断せざるを得なかったので 不採用となりました。

もちろん「成長が止まっていた」というのは私から見た主観であって、 当人からすれば 5年間の間にいろいろ経験を積んできたと思っているのでしょう。 実際、職務経歴書にはいろいろなプロジェクトが列挙してありました。 しかし、どのプロジェクトについても別段思い入れがあったわけでもないようで、 「印象深かったプロジェクトを、一つだけでいいので事細かに詳しく説明して下さい」と お願いしても、どういう製品を開発したのか説明するだけだったのです。 私としては、どう言う点を困難と感じ、どのように工夫し、何を学んだか等々を 聞きたかったのですが、 ついにそういう話は聞けずじまいでした。

給与の経路依存性と二極化」から引用:

キャリアって「何をやったことがあるか」もあるけど 「前職でいくらもらっていたか」というのも大きいんだよね. 誰も絶対的な給与水準の感覚なんてないから, どうしても「前職でいくらもらってましたか?」というのが重要な基準となる.

そうでしょうか? KLab には KLab の「絶対的な給与水準の感覚」があります。 もちろん面接の短い時間で、 どのくらいの能力を持っている人か正確に把握することは困難ですが、 実際に 3ヶ月~半年も一緒に働けば、 同じ職種の誰より上で誰より下の実力、 なんてのは誰の目にも明らかになるものだと思います。 だから KLab で前職給を聞くのは、 給与を決める際の基準にしようというわけでは決してなく、 KLab の給与体系にソフトランディングさせることが可能か判断するためです。

同ページから再度引用:

人事がまともなら移行期間は前職の給与だけど, だんだんと企業内部の給与水準に収束させる訳だけど, 誰かの給与を下げるためには結構まじめに説明可能な管理をする必要があって, なかなか大変だったりする. そうやって経路依存的な問題で所得が二極化しているのに, それを実力主義だとか抜かしたら大きな間違いだ.

給与を下げるのは実際大変です。しかし、 実力主義を標榜する以上、 成長にともなって給料が大幅に上がる人が出てくる一方で、 変化に適応できずに給料が下がる人が出てくることは避けられないことです。 「結構まじめに」どころか大変な労力をかけて話し合い、 お互い納得した上で降格を実施しています。

確かに面接では把握し切れなかった能力の低さが入社後に発覚し、 実力と給与のミスマッチが生じるケースも無いわけではありませんが、 不幸にもそういうケースが起きてしまったときは誠心誠意全力で対応し 是正するよう努めています。 お互い納得しあうまで何時間も話し込むこともあるわけですが、 それは実力主義を維持するために当然払うべきコストだと思っています。

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

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

CTO日記に書いた、 「実力主義・能力主義」が (思いの外 ;) 多くの方々に読んで頂けているようだ。 私がこだわっていることから 3つ紹介しているのであるが、 ほとんどのかたが、「技術者の上司は技術者であるべきです」に 注目しているのが興味深い。 勤務時間の10%以内であれば上司の許可を得ずに何をやってもいいという「どぶろく制度」 よりも上司が技術者であることのほうが関心が高い、というのは 現在の上司が理解がないと感じている人が多い、 ということを反映しているのだろう。

上司に自分の能力を正しく評価して欲しい、と 思うのは技術者として自然な感覚だとは思うのだが、 注意すべき点が二つほどあるように思う。

一つめは、視野狭窄に陥らないという点。
もう一つは、 現実問題としては、上司が技術者でない人が存在する、という点。

まず一つめの点であるが、 「上司に自分の能力を正しく評価して欲しい」と思うとき、 上司と自分との関係しか見ておらず、 しかもそれは自分からの視点のみであって、 相手がどう思っているかという視点が欠けているのではないか? 会社という運命共同体の中で自分がどのような位置にあり、 自分としてはどのような役割を果たすのか明確になっているだろうか? また、 上司はどのような考えで自分を評価しているのか、 その評価にはどのくらい妥当性があるのだろうか? そういう視点からみたとき、 見え方が変わってこないか自省すべきだろう。

もう一つの点、上司が技術者でない人の存在について考えてみる。 まっさきに CTO が思い浮かぶ。 確かに CTO の上司は社長であり、多くの会社で社長は技術者ではない。 しかし、よほど小さい会社でもない限り、 CTO 以外にも上司が技術者でない人は沢山いる。 そのような人達は、技術者以外の視点も持って、 上司や職位が同じレベルの他部門の人達と調整を行なわなければならない。 そういう調整能力と、部下を正しく評価し育成できる能力と、 両方兼ね備えた人材が豊富にいるのであれば問題無いが、 一般的にはかなり困難だろう。

だから、そういうポジションに技術者を登用する場合に、 調整能力を重視するのか、部下の育成能力を重視するのか、 考えなければならない。 この育成能力というのは、技術が分かっていることとはまた 別の次元だったりするので、さらに話は難しい。

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

VPN-Warp 入門編 (5)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

負け組の塔 vs 勝ち組の塔

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ブログの縁

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

同席した弊社社員は、

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

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

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

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

自分を変えよう

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

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

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

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

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

実力主義・能力主義 hatena_b

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

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

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

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

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

面白いことは許可します

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 11:24
Older Posts »