仙石浩明の日記

2006年6月5日

アイディアを出す人、その実現を技術で支える人、作ったものを売る人 hatena_b

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

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

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

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

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

Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 08:06
2006年6月4日

Wチューナ&ビデオキャプチャ カード GV-MVP/RX2W を使って Linux でテレビ録画

Linuxでテレビ録画を行なう方法は、多くの Web ページで紹介されているが、 ビデオキャプチャ カードによっては、 Linux カーネルのバージョンが変わると一筋縄にはいかなかったりするので、 現時点での Linux カーネル安定版の最新バージョン 2.6.16.19 で、 I-O DATA 製 ハードウェア MPEG-2 エンコーダ搭載TVキャプチャボード GV-MVP/RX2Wを使う方法をメモ (2.6.24.4 で使う方法)。

まず、 LinuxTVプロジェクトから V4L ドライバの最新版を取得する。 Mercurial (a fast, lightweight Source Control Management system) が インストール済であれば、

hg clone http://linuxtv.org/hg/v4l-dvb

を実行する。Mercurial が無い場合は、 MASTER v4l-dvb development repository から最新版を選んで「tree」をクリックし、 「gz」ないし「bz2」をクリックして tar ball をダウンロード。

そのまま make install してインストールしてもよいが、 make release VER=2.6.16.19 などと実行して、 現在使っているカーネルとは別のカーネルへインストールすることもできるし、 make menuconfig を実行して インストールするモジュールを選択してもよい。

私は、以下のモジュールのみ make した:

Multimedia devices  --->
  Video Capture Adapters  --->
    V4L USB devices  --->
      Hauppauge WinTV-PVR USB2 support

# Hauppauge 以外でも tveeprom.ko を用いるドライバであれば何でもよい

次に、ぱ研「LinuxでITVC16-STVLP」の ページに登録されている 0.6_svn3233-paken060421.tar.gz をダウンロード。 これをそのまま make すると version_check でひっかかるので、 Makefile の一行目を、

all clean install: version_check

となっているのを

all clean install:

に変更して make install する。 make KVER=2.6.16.19 install などと実行して、 現在使っているカーネルとは別のカーネルへインストールすることもできる。

/etc/modprobe.conf に以下の行を追加:

alias char-major-81 videodev
alias char-major-81-0 ivtv
alias char-major-81-1 ivtv
options ivtv ntsc=j tuner=46,46

チューナの video standard の設定を変更すると、 正しい選局ができなくなるようなので、 チャンネルを設定するプログラム等で video standard の設定を行なわないようにしておく必要がありそう。

私は録画 perl スクリプトを 自作して使っている (Video::ivtv & Video::Frequencies が必要)。

senri:/home/sengoku % tv -h
Unknown option: h
Usage: tv <opt>
opt:   -x               ; xine
       -X               ; mplayer YUV
       -u               ; ptune-ui
       -P <port>        ; TV server (http)
       -U <host>:<port> ;           (udp)
       -c <channel>     ; change channel
       -f <freq>        ; chage frequency
       -l               ; input from S-Video
       -r <sec>         ; mpeg to stdout
       -o <file>        ;      to file
       -t <time>        ; record at <time>
       -j               ; start at 0 sec
       -0               ; use video0
       -1               ; use video1
       -v               ; verbose

このスクリプトは予約録画 (-t オプション) もサポートしている他、 tv -P 1234 などと実行すると、 TVサーバとして利用することもできる。 つまり LAN 内の任意のマシンで、 VLC media playerを使って http://senri:1234/?c=1 などとチャンネル指定付で tv サーバへ接続し、 TVを視聴できる。

(ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画)

Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 12:45
2006年6月2日

SSL_pending

SSL_pending をマニュアルで調べると、

SSL_pending - obtain number of readable bytes buffered in an SSL object

SSL_pending() returns the number of bytes which are available inside ssl for immediate read.

と書いてある。つまり OpenSSL ライブラリ内に受信可能データがある場合、 そのデータバイト数を返す関数である。

なぜこんな関数が必要かというと、 データを送信しようとして SSL_write を呼び出したときも、 TCP/IP レベルでは送信だけでなく、受信も行なわれるからだ。 SSL のような暗号通信の場合、 送信は「垂れ流し」では済まず、ハンドシェークを行なう必要があるからだが、 この時、受信しようと思っていなかったデータ、 つまり通信相手が送信したデータまで読み込んでしまう場合がある。

すると、SSL_write を呼んでいるのに、 OpenSSL の受信バッファに、意図せずデータが溜まってしまう。 こうなってしまうと、select(2) や epoll(2) では検知できない。 select(2) や epoll(2) は、 I/O レベルでの受信データの有無を調べるシステムコールであり、 それより上のレベルである OpenSSL ライブラリの受信バッファのことは 関知しないからだ。

stone では、SSL_write で全てのデータを送り終わったとき、 SSL_pending を呼び出して受信すべきデータがないか確認している。 これを行なっているのが、 中継元/中継先との送受信を行なう stone の中核関数 doReadWritePair である。

select 版 stone の場合、 doReadWritePair を呼び出すのは doReadWrite である。 この関数は、 中継元/中継先との通信を行なうソケットディスクリプタのみを監視する select ループである。 epoll 版と異なり、select 版では、 select で監視するソケットの数が増えるとパフォーマンスが落ちるので、 送受信が継続しているときはメインの select ループとは別のスレッドを作成して、 パフォーマンスの低下を回避している。 送受信が途絶える (0.1 秒以上送受信が行なわれない) と、 この doReadWrite select ループを抜け、スレッドを終了して、 メイン select ループでソケットを監視する状態に戻る。

stone 2.3a (正確に言うと、stone.c 2.2.2.6 ~ 2.2.2.23) では、 SSL_pending で受信すべきデータを検知したとき、 SSL_read を行なってデータを受信した直後に、 この doReadWrite select ループを抜けてしまっていた。 本来なら、データを受信したのだから 直ちにそれを中継するために送信しなければならないのであるが、 ループを抜けてしまったために、いったんスレッドを終了し、 メイン select ループで送信可能か確認し、 再びスレッドを生成して doReadWrite select ループに入る、 という無駄が生じてしまっていた。

したがって、SSL_pending でデータが検知されることが多発するような場合は、 転送速度が著しく遅くなる。 例えば、stone の受信バッファを意図的に小さくすることによって OpenSSL 内のバッファに受信データが残りやすくして SSL 通信を受信してみる:

-X 512
-z key=key.pem
-z cert=cert.pem
localhost:22 localhost:12346/ssl --

「-X 512」オプションによって、受信バッファのサイズを 512 バイト (デフォルトは 2048 バイト) にしている。 12346番ポートで SSL 接続を受付け、 それを復号した上で、22番ポートへ中継する設定である。 続いて、

localhost:12346/ssl localhost:12347 --

という設定で stone を走らせて、12347番ポートで受付けた接続を、 SSL で暗号化した上で 12346番ポートへ転送するようにする。 上記二つの stone を実行することによって、 12347番ポートへ接続すると、 後者の stone によっていったん SSL で暗号化された上で、 前者の stone で復号されて 22番ポートへつながる。 つまり 12347番ポートで ssh 通信が行なえる。

前者の stone として stone 2.3a select 版を使うと、 ssh 転送が異様に遅くなる。

% scp -P 12347 /boot/linuz-2.6.16.18 localhost:/tmp/
...
linuz-2.6.16.18   100% 1211KB  11.3KB/s  01:47

延々 2 分近くかかってしまうが、 最新の stone.c 2.2.2.25 を使って select 版を作ると、 1 秒以内に転送が終わる。 また、stone 2.3a select 版であっても「-X 512」オプションを指定しなければ、 SSL_pending でデータが検知されるケースがほとんどなくなるので、 1 秒以内に転送が終わる。 なお、stone 2.3a epoll 版には、doReadWrite ループがなく、 全てメインループで処理を行なうので、 このような問題はない。

Filed under: stone 開発日記 — hiroaki_sengoku @ 18:51
2006年5月29日

ウォッチドッグ タイマ hatena_b

一週間ほど休暇で自宅を留守にしていたら、 運悪くちょうど半ばあたりで自宅の Linux サーバ (二台ある GCD ゲートウェイのうちの片方) がハングしてしまった。 きっかけは毎晩ハードディスの内容をバックアップするために動かしている rsync だったので、 メモリ不足 ? かなにかの原因でカーネルのバグを引き当ててしまったのか?

安定版でないカーネルを使っていて再びハングする危険もあるので、 早急にバージョンアップが必要なのだが、 その前に新しいカーネルで GV-MVP/RX2W を動かせるようにしないと... (^^;)
# ぱ研を参考にさせてもらっています (_O_)

GCD のゲートウェイは VRRP で二重化してあるので、 片方がハングしても問題無いのではあるが、 手動リセットするまでハングしっぱなしというのでは、 留守の期間が長いと二台ともハングする可能性を否定できない。
# UUCP スプールなど二重化されていないものもあるので、 全く問題が無いというわけでもない

そこでハングしてもなるべく自動的に復帰できるように ウォッチドッグ タイマ (Watchdog Timer) を仕掛けることにした。 つまり一定期間内にタイマがリセットされなければ、 ハングしたと見なして問答無用でカーネルを落とす仕掛けである。

ソフトウェアにどんなトラブルが起きても確実に再起動を行なわせるには、 ハードウェアで物理的にリセット スイッチを押すハードウェアを用いるのが 一番であるが、まずはお手軽にソフトウェア版を利用してみることにした。 ソフトウェアによるウォッチドッグ タイマの場合、 カーネル パニックが起きると当然機能しなくなるわけだから、 パニック時は自動的に再起動するように設定しておく必要がある。 rc.local 等で、

echo 60 > /proc/sys/kernel/panic
echo 1 > /proc/sys/kernel/panic_on_oops

を行なっておけば、パニック時は 60秒で再起動するようになる。

次に、ソフトウェア版ウォッチドッグ モジュール (softdog) をインストールする。 softdog.ko を /lib/modules/current 以下に置き、 /etc/modprobe.conf に以下の行を追加するだけ。

alias char-major-10-130 softdog
options softdog soft_margin=3600

ウォッチドッグ タイマというと、 普通は 60秒くらいに設定しておくものだとは思うが、 自宅サーバの場合、一時間くらいハング状態が続いてもそんなに困らない ;) のと、 あまりタイマの間隔が短すぎると、不用意に再起動してしまう恐れもあるので、 3600秒 (一時間) に設定している。 つまり一時間以内にタイマをリセットしないと、自動再起動が行なわれる。

後は適当な方法で、 /dev/watchdog に適当な文字 (ただし「V」を除く) を書込むだけである。 例えば、定期的に実行される sh スクリプトに、

echo "@" > /dev/watchdog

という行を追加しておくだけでよい。

Linux カーネルのドキュメント: linux/Documentation/watchdog/watchdog.txt には、

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>

int main(int argc, const char *argv[])
{
        int fd=open("/dev/watchdog",O_WRONLY);
        if(fd==-1)
        {
                perror("watchdog");
                exit(1);
        }
        while(1)
        {
                write(fd,"\0",1);
                fsync(fd);
                sleep(10);
        }
}

というサンプルが載っているが、タイマをリセットするプログラムを 動かしっぱなしにする方法だと、 ハングの仕方によってはこのプログラムが動き続ける (つまり自動再起動が行なわれない) 危険がある。 私の自宅サーバの場合は、たとえカーネルが生きていても、 リモートから ssh ログイン出来ない状態なら使い物にならないわけで、 外部から ssh ログイン出来る場合のみタイマのリセットが行なわれるようにした。 つまり、外部から

ssh server "echo @ > /dev/watchdog"

に相当することを定期的に (一時間以内の間隔で) 行なえばよい。 この場合、/dev/watchdog に文字を出力する都度、 /dev/watchdog をクローズすることになり、

SoftDog: Unexpected close, not stopping watchdog!

というメッセージが syslog に出力されるので、 果たしてきちんとタイマのリセットが行なわれているのか不安になるが、 softdog モジュールのソースを見ると、 このメッセージが出力される場合は常に 「softdog_keepalive()」呼び出しが行なわれているので問題ない。

Filed under: システム構築・運用 — hiroaki_sengoku @ 07:51
2006年5月22日

ストックが増える積み重ねと、増えない積み重ね

成長する秘訣は、 今の仕事を捨てて自分を変えること」に トラックバックを頂いた。 曰く:

ものの考え方にはストック…積み重ねにより大きな利益を得るっていうのもあって、 ストック、フローのどちらをよしとするかはケースバイケースなのでしょうが、 今の時代はフロー的なことが求められるのですかね。
...
ただ、エンジニア稼業というのはスキルの蓄積が実績として重要視される ストックな生き方を要求されることも多いかな。

蓄積には、ストックが増える積み重ねと、 増えない積み重ねがあるような気がしている。 ストックが増えるのであれば蓄積は重要だが、 ストックが増えなくなってきた仕事は捨てることも検討すべきだと思う。

そうでないと、 「これだけいろいろ経験を積んでスキルも蓄えたのだから、 当然評価されてしかるべきだ」という思考停止状態に陥ってしまう。 事実、面接で長大な職務経歴書を提示して、 一つ一つ説明して下さるかたがいらっしゃるが、 そんなものよりたった一つの深い経験の方が重要なこともあるのだ。

「ストック、フローのどちらをよしとするか」という話にしてしまうと、 当然重要なのはストックで、フローはそのオマケに過ぎない、 ということになってしまうが、 そういう問題ではない気がする。 ストックが大事なのは「エンジニア稼業」に限らず、 どんな職種でも同じなのではなかろうか。

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

VPN-Warp relayagent フリー ダウンロード hatena_b

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

上記パッケージは、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 試用ライセンス提供開始のお知らせ」を参照願います。

Filed under: システム構築・運用 — hiroaki_sengoku @ 07:17
2006年5月18日

休暇でサンフランシスコへ行きます

明日から休暇です。 ここ 10年ほど、年2回のペースで、休暇をとって海外に行っています。 この 10年間の間に(株)ケイ・ラボラトリー (当時の社名) の設立があったり、 その他もろもろ超忙しい時期もあったのですが、 この年2回の休暇だけは欠かさず続けられています。 周囲の方々の理解があればこそと、感謝しております (_O_)。

今回はサンフランシスコに行きます。 ちょうど 6年前、ケイ・ラボラトリー設立直前に、 JavaOne に行くためにサンフランシスコへ行ったので、 それ以来のサンフランシスコです。 当時書いた日経Linux の連載の注釈から引用:

おまけに,この原稿の締め切り直前に海外出張の予定が入っています。 これは飛行機の中で書けっていうことでしょうか。 幸い,ビジネス・クラスなので, (その気になれば)原稿の1本や2本,余裕で書けることでしょう... と思っていたら飛行機がやたらに揺れて, 原稿を書いていると酔いそうになったので, 早々にノートPCの電源を切って寝てしまいました。

今回は休暇なので JavaOne のことは全く念頭になかったのですが、 ナニゲなくJavaOne のページを 見ると、今年は 5/16 ~ 5/19 なのですね。 明日 5/19 出発すると、到着するのは (日付変更線を越えるので前日になるから) 5/19 の朝になり、JavaOne を見に行けてしまうようです (もちろん行きませんが ^^;)。

Filed under: その他 — hiroaki_sengoku @ 08:32
2006年5月17日

断片的な知識と体系的な知識

CTO日記に書いた 「断片的な知識と体系的な知識」を、沢山の方々に読んで頂けた。

この季節、新卒(見込み)の学生さんを数多く面接してきたのですが、 新卒の段階で既に とてつもなく大きな差がついていることに改めて驚かされました。
今後大きく成長する可能性が感じられる人と、 早くも既に成長の限界が見えてしまっていて、 可能性がほとんど感じられない人、という点では、 もう既に逆転不可能とさえ思えるような大差がついてしまっています。
可能性が感じられる人、というのはつまり、 自分が何をしたいか明確に分かっていて、 かつその分野の体系的な知識を身につけている人たちです。 現時点ではそんなに多くを習得しているわけではないにせよ、 体系全体を理解していますから、自分がどこまで知っていて、 未知の領域がどのくらいあるか、感覚でつかんでいます。

じゃ、オマエは学生の時どうだったんだ、という声が聞こえてきそうなので、 私の学生生活を振り返ってみる。 コンピュータの分野が好きだと思ったのは中学一年の時で、 体系的な知識を学んだのは大学の専門課程に進んでからである。

- o -

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

初めて BASIC の入門書を読んだとき、 将来プログラミングを仕事にできたらどんなにいいだろう、 と思ったのを今でもはっきり覚えている。 今からは想像もつかないが、 1978年当時の中学生にとって、 一人一台マイコン (当時の呼び方 ;) を占有できるなんてことは、 とうていかなわない夢だった。

高校になってようやく MZ-80K2E を購入した。 日経Linuxに執筆した連載の枕から引用:

私が最初に購入したコンピュータは, シャープのMZ-80Kシリーズの最後の機種K2Eでした。 RAMは32Kバイト,CPUはZilog Z-80 2MHzで, BASICインタプリタをROMではなく, カセット・テープから読み込む方式であるため, BASIC以外の言語への対応が容易という, 当時としては画期的なパソコンでした。 BASICライクなアセンブラBASE-80を使って, ゲームやモニターを作っていたことを思い出します。 その後,CP/Mを移植するためにBIOSを記述する際にも, BASE-80を使いました。

高校時代は、マイコンのハードウェアに興味を持ち、 MZ-80K2Eのプリント基板の配線を目で追って回路図を起こし、 それをもとに Programmable Character Generator や Z80 DMA を追加するなどの改造を行なった。 また、 コンピュータ以外の分野では、 物理や哲学に興味を持ち、 1年に百冊以上読む、という目標を立てて 手当たり次第に読書したこともある。

コンピュータにのめり込んだ高校時代だったため、 大学に進むとき、物理, 数学, 哲学などの道に進むことも (一瞬 ;) 考えたのであるが、 コンピュータを学んだといっても所詮は独学に過ぎず、 まだまだ学ぶことがあるはずと思い直し、情報工学科に入学した。

1回生のときは、Z-80 を使ったコンピュータの手作りに熱中した。 ユニバーサル基板を何枚か使って、 それぞれ CPU ボード、I/O ボード、DRAM ボード、などを順に作り、 MZ-80K2E をキャラクタ端末にして CP/M を走らせた。 2回生のとき、ソフトウェアハウスでアルバイトするようになり、 MacVJE などを開発した。 私にとって初めての、 まとまった量のプログラミング (C 言語で 5万行くらい) 体験だった。

このあたりまではあくまで独学であり、 断片的な知識の寄せ集めである。 もっとも、現在のようなインターネットなどなかったから、 全て (数少ない) 専門書を読みあさって仕入れた知識であり、 Web ページで得られる知識よりは、マシだったかもしれない。 当時のコンピュータ関係の専門書は、 大型書店 (大阪梅田の紀伊國屋や旭屋など) にしかなく、 それも数えるほどしかなかった代わり、 ほとんどがマトモな本だった。

3回生になって初めて情報処理の基礎を学んだ。 今まで経験則で回路図を設計していたのが、 カルノー図を使うとシステマチックに最適な回路を設計できる、 ということを学んで感動し、 独学の限界を思い知った。 なにせ、それまではコンピュータの設計というと 数週間かけて行なうものだと思っていたのに、 教科書で説明されている方法だと数時間しかかからないのだ。 私が初めて大海を垣間見た瞬間かもしれない。 そのとき読んだ教科書がこれ:

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

ボロボロになるまで読んだ (まあ、もともと製本が粗末というのもあるが ;)。

Filed under: 技術者の成長 — hiroaki_sengoku @ 13:55
2006年5月17日

無料セミナ: 内部統制を巡る国内外の動向と IT 統制に係るクリティカルサクセスファクター

この日記を読んで頂いているみなさまにとっても、 個人情報漏洩対策や内部統制の整備は切実な問題だと思うので、 弊社 (KLabセキュリティ) 主催のセミナのご紹介を... 無料ですので、関心のある方は参加されてはいかがでしょうか (定員 40名なので、〆切られちゃったらごめんなさい)。

# 業務連絡。その1
# こーいうセミナを開催するなら私にも教えておいてください > マーケ本部

内部統制を巡る国内外の動向と IT 統制に係るクリティカルサクセスファクター
日時: 2006 年 5 月 30 日 (火) 13:30 ~ 16:10
会場: 株式会社アズジェント 1F ソリューションショールーム
東京都中央区日本橋小網町19-7 (最寄り駅/地図)

# 「クリティカルサクセスファクター」って何?という質問は私にしないで...(^^;)

以下、 申し込みページより引用:

個人情報保護法が 2005 年 4 月に施行され、個人情報に限らず、 重要な「情報」に対する資産価値としての認識が高まる一方、 情報漏えいや様々な企業の不祥事が頻発しています。 そうした中、2006 年 5 月には、新会社法が施行され、 また、2008 年に導入が予定される [日本版 SOX 法] など、 企業の内部統制の強化が要請されています。 業務が IT に大きく依存している現在においては、 内部統制の目的を達成するために、 IT 統制が不可欠な要素となります。 内部統制、IT 統制に求められているのは、 「アクセス制御」「暗号化」「ログ管理・分析」等の技術的対策のみならず、 業務リスクを睨んだ業務システムの設計や「監査」に対応するための仕組みです。

本セミナーでは、内部統制強化の動向や情報セキュリティ、 コンプライアンスなどの対策に必要なリスク管理を紹介します。

また、セキュリティポリシー遵守のための従業員への「牽制・抑止」効果と、 各部門への「指導・警告」、 および企業努力として監査の記録を残し、 経営層、Public に進捗をレポートできるツールとして 「個人情報スキャナー P-Pointer」のご紹介と、 導入事例をご紹介します。

Filed under: 技術と経営 — hiroaki_sengoku @ 06:26
2006年5月16日

断片的な知識と体系的な知識 hatena_b

この季節、新卒(見込み)の学生さんを数多く面接してきたのですが、 新卒の段階で既にとてつもなく大きな差がついていることに改めて驚かされました。

中途採用の候補者の方々は、 前職でいろいろ学び経験してきたので、 多くを学んだ人とそうでない人とは大きな差がつくのは、 まあ当然と言えるでしょう。 それに対し、 新卒の学生さんは、これから職業生活のスタートを切るわけで、 差があったとしてもまだその差は小さいと思いがちです。

もちろん、学生さんたちを、 仕事を遂行する能力という点で比較すれば、 優秀な人もそうでない人も、そんなに大差ないでしょう。 この人はスゴイ、と思うような人でも、 入社直後にバリバリ即戦力として働けるか、というと おそらくそんなことはないと思います。

しかしながら、今後大きく成長する可能性が感じられる人と、 早くも既に成長の限界が見えてしまっていて、可能性がほとんど感じられない人、 という点では、 もう既に逆転不可能とさえ思えるような大差がついてしまっています。

可能性が感じられる人、というのはつまり、 自分が何をしたいか明確に分かっていて、 かつその分野の体系的な知識を身につけている人たちです。 現時点ではそんなに多くを習得しているわけではないにせよ、 体系全体を理解していますから、 自分がどこまで知っていて、未知の領域がどのくらいあるか、 感覚でつかんでいます。

一方、あまり可能性を感じられない人、というのはつまり、 自分が何をしたいのか、まだつかみきれていない人、 あるいは、 何をしたいかは分かっているのだけど、 断片的知識の寄せ集めしか身につけておらず、 その分野の体系の全体像をつかめていないので、 自分が何を知らないのか分からず、 井の中の蛙になってしまっている人たちです。

何をしたいかすら分かっていない人については、 先日「人の役に立つことをしたい」と言う技術者の卵たちで書きましたので、ここでは割愛します。

井の中の蛙とはいえ、自分が何が好きかは分かっている人は、 どんどん自発的に新しいことを学んでいけるので、 短期的には活躍できるでしょう。 しかし雑多な断片的知識はどこまで集めても体系にはなり得ません。 井戸の中しか知らない蛙は永遠に大海を知ることはないのです。 しかも、インターネットが普及した昨今、 断片的知識を得ることは限りなく容易になってしまい、 体系的知識を学ぶことが相対的に困難になってしまっています。

つまり、 今も昔も、 体系的知識を学ぶこと自体の難易度は変わっていないと思うのですが、 断片的知識がインターネット等であまりに容易に 見つけられる (なんせ google 一発ですもんね) ようになってしまったので、 体系的知識、すなわち IT業界で言えば 「情報処理のキホン」を学ぶ機会が減ってしまったと思うのです。 「情報処理技術の基礎を知らない情報技術(IT)業界の技術者」というのは こうやって文字面をみるだけでも頼りない感じがしますよね? (^^;)

そこで KLab(株) ではそういう機会を少しでも提供したいという思いから、 輪読会を実施しています。 現在進行中の輪読会では、

コンピュータサイエンスのための離散数学
Information & computing (61)
守屋 悦朗 (著)

をテキストとして使っています。 ぶっちゃけこの本は説明が簡潔すぎてイマイチなのですが、 あまり分厚い本だと読む前にメゲてしまいますし、 この本で端折っている部分は、 数学科出身のアーキテクトに補足説明してもらっているので、 なんとかなりそうです(反面、1ページ読み進むのに何時間もかかったりしますが ^^;)。

実力主義・能力主義」で

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

と書きましたが、 「技術だけでどこまでも上っていく」には、 技術体系全体を俯瞰して、 自身の現在位置が把握できていることこそ必要だと思うのです。

Filed under: 元CTO の日記,技術者の成長 — hiroaki_sengoku @ 09:45
2006年5月15日

「知らないこと」と「分からないこと」

CTO日記のほうに、 興味深いコメントを頂いた。 質問者のかたは、 こちらの日記も読んで頂いているようなので、 こちらで続きを書こうと思う。 「分からない時は、『分からない』と言おう」で書いた、 技術者がスキルアップするには、 分からないことがあるときは臆せず質問できる度胸こそ必要、という 私の考えに対するコメントであるが、曰く、

ここで言われている『分からない』という言葉の中には 「知らない」と「理解できない」の二つの意味が含まれているということです。
「知らない」ことについては、(自分を含めて)みんなが知らないことなのか、 自分だけが知らないのかすら判断できないから なかなか質問ができないのだと思います。 聞いた内容によっては(たとえ説明したとしても) そもそもその場で話している内容はまったく分かってないんだな、 と思われたりします。聞くのは危険だと思います。
「理解できない」ことについては聞いた内容について 自分の中で消化できないわけなので、 恥ずかしがらずに質問できるような人になれたり、 環境ができればいいと思います。

「知らない」ということと「理解できない」ということは確かに違う。 私が書いたのは、「理解できない」ということについてであって、 「知らない」ということについては言及していなかった。 「理解できない」ことについては、「恥ずかしがらずに質問できるような人」に なれたらいい、と書かれているので、私と同意見のようだ。

ところが、「知らない」ことに対する考え方は私と全く違うようだ。 この質問者のかたは、「理解できない」より「知らない」ことの方が恥ずかしい、 という感覚のようだが、 私の感覚は全く逆である。 つまり、「知らない」ことは全く恥ずかしいことではない、と私は思う。 だからこそ、「知らない」ことについてはあえて言及していなかった。

「知らない」ということは、たまたまそのことについて 知る機会がなかった、というだけのことである。 誰でも最初は初めてである。 今がその初めての機会であるなら、さくっと質問して 知ればいいだけのことであろう。 どうして今まで知る機会がなかったことが恥ずかしいのであろうか?

「当然知っておくべきこと」だから? では、なぜそれを「当然」と思うのか?
あたかも、どこかの誰かが決めた、 「技術者ならば常識」というのがあって、
それを知らないのは技術者として失格、とでも言いたいのだろうか?

全くもって馬鹿げている。 たとえその人が「常識」を知らなかったとしても、 素晴らしい能力を持っているかもしれないではないか。 知識の多寡で技術者の能力を推し量ることなど無意味である。 仮に、「常識」を知らないことを理由に馬鹿にする人がいるのであれば、 所詮そのレベルの技術者なのであろう、相手にする必要はない。

一方で、「理解できない」ということは、場合によっては恥ずかしいことである。 もしかすると、質問したことによって、 自身の理解の限界、あるいは自身の理解の速度の遅さを 思い知ることになるかもしれない。 その限界があまり高いレベルでない場合は、 つまり平均的な技術者がすぐ理解できることが、 自分にはすぐには理解できないのだとしたら、 その分野は自分には向いていないということになるだろう。

いままでそのことに気付かなかったのは恥ずかしいことであるが、 なにごとも遅すぎるということはない、 その分野はあきらめて、自分の得意な分野に集中すれば良いだけである。

Filed under: 技術者の成長 — hiroaki_sengoku @ 08:03
2006年5月14日

「迷惑メール」を「有害メール」と呼ぶべきか?

「頼んでもいないのに送られてくる厄介で迷惑なメール」を、 なぜ「スパム」や「有害メール」でなく、 「迷惑メール」と呼ぶのか、 今のスパムは「迷惑」という域を越えているのではないか、 という趣旨の問題提起を、 (株)サードウェア社長の久保様が 「オープンソースでいこう」で 書かれました。 コメントを書いていたら長くなりそうだったので、 トラックバックの形で書かせて頂きます。

スパムというのは、もとはといえば NetNews の迷惑な記事に対して使われた用語です。 このあたりの話は、 日経Linuxに連載した拙文でも解説しております。 歴史上初めて大問題となったスパムも引用しておりますので、 参考にしていただければ幸いです。

で、迷惑メールのことをスパムと呼ぶ人が現れ始めてきたころから、 私は「スパムってのは NetNews の記事についての用語であって、 メールについてスパムと呼ぶのは誤用だ」という主張も込めて、 「迷惑メール」と呼ぶようにしていました。 その後、迷惑メールという呼び方が広まったので 変な用語が広まらなくてよかった、と感じたのを覚えています。

なので、私は「スパム」と呼ぶより「迷惑メール」と呼ぶほうが適切と 思っております。 「頼んでもいないのに送られてくる厄介で迷惑なメール」は、 UBE とか UCE とか呼ばれていますし、 「フィッシング(詐欺)メール」については、 そのまま「詐欺メール」と呼ぶのが適切だと思います。 また、「メールボックスを埋めつくすほど届く」メールは、 メール爆弾と呼ばれていますね。

久保様曰く:

「迷惑」という語感が気になっているわけなんですが、 このことについて仙石様はじめ皆様はどう感じておられるのでしょうか。 我慢してやりすごせばいい、というニュアンスではなく、 極力工夫して積極的に排除すべき対象、 ということを強く主張すべきだと思うので、 見直すべき時期なんじゃないかということなんです。

私としては、「迷惑」という言葉に、久保様がおっしゃるように、

「迷惑」だったら我慢してやりすごしておけばいい、というイメージがあります。 電車の中でわめく人に対する対応みたいな感じですね。

というイメージがあるからこそ、 「迷惑メール」という呼び方が適切だと思っています。 迷惑か否かは、あくまで受け手の主観、というイメージですね。 「有害メール」という名前を仮につけたとすると、 「誰が有害と判断し規制するのか」という問題が出てきてしまうと思います。

ご存知の通りインターネット全体の管理者はいません。 あるメールが迷惑か否かは、 そのメールを受け取る(あるいは送信する)各サイトの 組織の判断にゆだねられるべきであって、 第三者がとやかく言うべき問題ではないと思うのです。 気軽に「有害」と言ってしまうと、 暗黙のうちに「有害認定し規制する」権威を認めることになりかねない、 という危うさを感じます。 条例で定められている「有害図書」の場合と比較してみるといいかもしれません。

もちろん、ネットは現実社会の一部ですから、 ネットの外で犯罪であれば、ネットの中でも犯罪です。 だから法律に照らし合わせて「詐欺」に該当するなら 「詐欺メール」と呼ぶべきですし、 その他の犯罪に該当する場合も同様でしょう。 ただし、犯罪か否かを判断する際に拡大解釈は許されませんから、 犯罪と認定するだけの十分な法的根拠が必ず必要だと思います。 「有害図書」の場合は、 「青少年の人格形成に有害である可能性がある」という趣旨の定義が 各都道府県の条例で定められていますね。

Filed under: その他 — hiroaki_sengoku @ 08:01
2006年5月13日

成長する秘訣は、今の仕事を捨てて自分を変えること hatena_b

今までの自分を振り返ってみると、 ずいぶんいろんな仕事を捨ててきた。 一番大きかったのはもちろん大企業の研究所での研究生活を辞めて、 (株)ケイ・ラボラトリー (KLab の当時の社名) の創業に参加したことだが、 その後も、

  • ケータイ上の Javaアプリの開発
  • サーバ側の Webアプリケーションの開発
  • クラスタリングサーバの構築・運用 (後の DSAS)
  • そして KLabセキュリティ(株) への注力

と、どんどん仕事を替えてきた。 部下が成長してきて、私の代わりがつとまるようになったら、 私はもうその仕事はやらない。全てその部下に任せてしまう。 なかなか思う通りにいかないことも多いが、 他の人ができる仕事は自分ではやらない、という原則を自身に課してきた。

同じ仕事をやり続ければ次第に要領が分かってきて、 よりスマートにこなすことができるようになるが、 しだいに成長の度合いは鈍るだろうし、 なにより部下が育たない。 ある段階まで来たら仕事は部下に譲って、 自分は違うことをすべきだろう。 そうすれば新しいチャレンジができるし、 自分を大きく成長させることもできる。

今日、本屋で他に読みたいと思う本がなかったので仕方なく手に取った本:

千円札は拾うな。
安田 佳生 (著)

をパラパラと見たら、 まさに私が考えていたようなことが書いてある。 引き込まれて思わず一気に読んでしまった (私がいきなり本に没頭し始めたので、一緒にいた妻が不機嫌になってしまったが)。

久々に、いい本に出会えた感じがした。 さっそく私の参考文献リストに追加した。 それにしても、この本のタイトルはいただけない。 以前からこの本が平積みになっていたのは知っていたのだが、 タイトルからは食指が動かなかった。 そもそも、「お金を拾うな」というのは当たり前ではないか、 と思ったからだ。たとえ一万円札だろうと、 何か高価そうな品物だろうと、私は拾わない。

私の参考文献リストに加えていて気付いたのだが、 安田氏の著作はすでにリストにあった:

採用の超プロが教えるできる人できない人
安田 佳生 (著)

この本もオススメである。私の面接のやり方は、 この本に影響を受けた面がたぶんにある。

Filed under: 技術者の成長 — hiroaki_sengoku @ 21:16
2006年5月13日

情報漏洩対策は、一人一人のセキュリティ意識向上から

相変わらず情報流出事件があとをたたないですね。 この日記を読んでる人は技術者のかたが多いと思うのですが、 みなさんはどう感じていますでしょうか?

Winny なんて使ってるからだ、とか
トロイの木馬に引っ掛かるからだ、とか思いますね、ふつう (^^;)。

確かにこれだけ社会問題化しているのに、 いまだに Winny を使い続けるのはどうかと思いますが、 情報漏洩の観点から見れば Winny は単に経路の一つに過ぎないわけで、 トロイの木馬に引っ掛るのであれば、あらゆる経路が利用可能でしょう。

そして、トロイの木馬は、いくらでも巧妙化できるので、 騙される人はあとをたたないでしょう。 「振込め詐欺」があとをたたないのと同じです。 よっぽど人数が少ない会社でない限り、 従業員の全てに「絶対に騙されない」よう求めるのは非現実的かも知れません。

ウチの会社は Winny を禁止しているから大丈夫、なんて思っていると、 ある日突然、社外秘のはずの情報が某掲示板などで晒されて大慌て、 などということになるかも知れません。 なにせ、たった一人の従業員が騙されてトロイの木馬を実行するだけで、 漏洩は起こり得るのですから。

かといって漏洩経路の大元であるインターネットとの接続を断つ、 というのはインターネットがこれだけ便利なものになってしまった昨今、 なかなか難しいものがあります。 今や何をするにも、まずちょっと google で調べてから、というのが 習慣化している人も多いのではないでしょうか。 そもそもセキュリティってのは利便性とのトレードオフであって、 漏洩を防ぐためにインターネットを使わないというのは、 漏洩が恐いから社外秘の情報は全て金庫にしまっておく、と 言ってるのと大差ないわけです。

では、どうすればいいのか?

セキュリティの基本、すなわち「教育」に立ち戻るべきでしょう。 セキュリティというと、ファイアウォール、IDS、シンクライアント、 暗号化、セキュリティトークン、USB の無効化、... 等々、 ありとあらゆる仕掛けが雨後の竹の子のように提案されていますが、 シンクライアント化を押し進めていたはずの某巨大企業グループでも 情報漏洩事件が起きたように、 仕掛けだけでは自ずと限界があります。

従業員のセキュリティ意識向上」抜きには、 どんな仕掛けも「仏作って魂入れず」になってしまいます。 まずは、従業員一人一人が、
自分のPC の中にどんな情報が入っているか把握すること、
自分のPC が漏洩元になるかもしれない、という意識を常に持つこと、
こそが情報漏洩対策の第一歩だと私は思います。

とても小さい一歩のようにも見えますが、 もし従業員一人一人が、自身の問題として、 自分の PC 内の情報の把握することの必要性を実感した上で行なうのであれば、 把握するだけでも大きな効果を発揮することでしょう。

まずはできるところから、一人一人が自分の PC をスキャンして、 どんなファイルがハードディスクの中に入っているか確認するだけでも、 それが自発的な行動であるなら、 漏洩防止に向かって大きな一歩を踏み出すことになります。 大掛かりな仕掛けより、一人一人の意識改革が重要、そんな思いから 個人情報スキャナ P-Pointer を開発しています。 無料体験版をダウンロードしてお試し頂けます。

Filed under: 技術と経営 — hiroaki_sengoku @ 09:06
2006年5月12日

資産を増やそう! 技術者にとっての資産とは?

資産とは、お金を入ってくる源泉。 お金が出ていくほうは負債。 持ち家を資産と思っている人も多いが、 持ち家に自分で住んでしまえば、 修繕費などでお金が出ていくことはあっても、 お金が入ってくることはない。だから負債。

金持ち父さん貧乏父さん
ロバート キヨサキ (著), 白根 美保子 (翻訳)

で述べられているように、 お金のしくみはいたって単純である。 少なくとも普段、技術者たちが相手にしている高度な技術に比べたら、 遥かに遥かに単純である。 負債を減らして資産を増やせば、 入ってくるお金が増える。 ただ、それだけ。

こんなに単純な理屈なのに、 多くの人は、 資産を増やすためにお金を使うより、 むしろ負債を増やすことにお金を使ってしまう。 例えばローンを組んで持ち家を買ったりする。 どうみても世間一般の人より遥かに頭がいいように思われる技術者たちが、 ことお金に関しては全くといっていいほど 頭を使おうとしないのはなぜなのか。

しかも、技術者の多くは、 他の人達が望むべくもない資産を持っている。

それは「スキル」。

しかも、わずかな投資(努力)で大幅に増やすことができる特異な資産である。 なぜ、この資産をもっと効果的に増やそうとしないのか。 なぜ、目先のキャッシュフロー (安月給) に目を奪われて、 自身の資産形成をおろそかにするのか。

Filed under: 技術者の成長,経済・投資・納税 — hiroaki_sengoku @ 23:55
« Newer PostsOlder Posts »