来週はバンコク出張です。前回は1月末でしたので、4ヶ月ぶりです。今回はタイでも販売している不正接続対策システムIntraGuardian2の最新ファームの提供（NTPで海外時刻に設定できなかったのを修正・・・）、タイ向け新製品の紹介、以前宮沢さんのところと共同開発した製品の現地検証、と、実質5日間と短い割に予定は盛りだくさんです。
ところが、昨日のブログでもぼやいたように、このところ私がとても忙しくて、出張の準備も今日の午後に会社にいられた数時間で慌ただしく行った状態で、何か抜けがないか心配なのですが、まあ、いざとなればインターネットもつながりますし、何とかなるでしょう。
今回は航空券が少し安くなる深夜便でバンコクに向かうことにしたのですが、いざ準備してみると面倒です（なので安いのでしょうけど）。まず、川越からのリムジンバスがそんなに遅い時間に走っていない：電車を乗り継いで羽田まで向かわねばならない、という点。それなりに荷物があるので、乗り換えは面倒なのですよねぇ。さらに、バンコク到着が早朝過ぎておそらく空港の携帯電話ショップが空いてないという点。バンコクに着いたらすぐにSIMカードをGETしないと宮沢さんに電話ができないのです。。仕方ないので、待ち合わせ場所を宮沢さんと念入りに打ち合わせしておきました。やはり素直に日中の便にすれば良かったかも・・・。
別件でもタイでのビジネスの相談があったりして、ひょっとするとまたすぐにタイに行くかもしれない感じで、海外でのビジネスも地道に盛り上げていきたいと考えています！
このところ、ProDHCPの商談が平行でたくさん（？）進んでいて、取引面での相談や、さらに、こんな使い方はできないかと相談がきていたり、高速ネットワーク向けの共同開発の仕事ではまっていたり、さらには、タイ向けの商談や、受託開発案件などなど・・・いくら何でも急がしすぎという状態です。暇よりはもちろん幸せなのですが、これでは社長業の時間がありませんし、メンバーからの相談にも冷たい対応だったり、そもそも、ちっとも会社にいなかったり。。
リーダー達から、「社長は社長にしかできない仕事があるのだから、普通のプログラミングや現地調整などは、できるだけ社長以外で回すようにしよう」と言ってもらっているのですが、そもそもメンバー達も忙しく、短気な私は結局自分でどんどん進めてしまうしかないのでした。私は自分が待つことが嫌いなので、相手を待たせることも絶対に嫌なのです。
とはいえ、すでにバッファオーバーフロー状態ですので、このままでは当然まずいのです。
私がやっているような、パケットを直に扱ったりして、普通のソケットプログラミングではできないような処理を行うプログラムを作ったり、あるいは、ISPで使われるような、超高性能＆高信頼性システムを作ったり、さらには、ネットワークで技術的に困っている現場を助けたりするような仕事をしたい方、是非とも当社へ・・・プログラミング面で物足りなさ感じさせたりすることはありませんので！
下記の本の内容が楽しいような人、ぜひチャレンジを！！
今日も、ある開発案件で、10Gイーサーでの検証を行ってきました。10Gイーサーで大変だという話題などは、先日も少し書きましたが、
・Linuxでの最大スレッド数
・チェックサム計算の高速化：情報発信すると教えてもらえるのもうれしいこと！
高性能CPUでも対応しきれないほど、通信が高速という点です。特にチェックサム計算などは、全データをなめるため、どうしても計算量が増えてしまいます。先日の記事でアドバイスいただいた方法を組み込んだりしながら、それなりに高速化して、再び確認していたのですが、もう少し性能をUPさせたいところです。まあ、実環境があるおかげで、様々な側面から観察ができますので、対応方法もいろいろと浮かんできているのでまだ良いのですが。。
普段、なかなか高性能環境をブン回す機会はないので（社内には贅沢な環境は置いてないので・・・）、ちょっとだけ雰囲気を紹介してみましょう。
これは、ある処理を行うプログラムの、スレッド数を表示させているところです。26万2千128スレッドで、ほとんど使いたくなくなるくらいサーバが重たくなりました。ちなみに、この状態で、26万×2本のTCPコネクションが張りっぱなしになっています。52万本のTCPコネクションを張る確認をするだけでも、実は簡単ではありません。クライアント側は1つのIPアドレスから65535個しかコネクションを張れませんから、普通にTCPのクライアントプログラムを作っても、そう簡単には26万本もTCPコネクションできませんし、仮想IPアドレスを使っても、一般的なクライアント環境では26万本もTCPコネクションを使わせてもらえるようにするのはかなり大変です。サーバ側も26万個も接続をしっぱなしにするのは、たとえばapacheとかを使っても大変なことです。
まあ、当社のネットワーク好きメンバーであれば、直接TCP/IPパケットを作り出して何とでもできてしまうのですが。
さて、26万スレッドと52万本のTCPコネクションがある状態で、OSの様子を見てみると・・・まだまだメモリーは空き容量の方が多いですねぇ・・・と簡単に言ってはいけません。そもそもこのサーバには28ギガバイトものRAMがあり、13ギガバイトくらい使っているのです。一昔前までは、サーバ機でもRAMは4ギガバイトくらいだった気がするのですが・・・。
このように贅沢な環境でプログラムをブン回しても、処理によっては10Gイーサーに対応しきれないのです。。普通の使い方であれば、TCPチェックサム計算はTCPオフロードでCPUには負荷をかけないようにできたりするのですが、相変わらず私が開発しているものは普通ではないもので・・・。
まだまだチャレンジは続きますが、こういう作業はノウハウもたまりますし、刺激的で楽しいのですよねぇ！
仕事をしていると、「見積」という作業が必ずあると思います。見積とは、金額・量・期間・行動を前もって概算すること、と説明されています。まあ、多くの場合、仕事を請ける際に、いくらで対応するかを提示することになります。
私は、昔から「見積」という作業が嫌いで、その背景には、「開発仕事はやってみないと分からないのに、厳密な見積などできるはずがない」ということもありますし、「提示したところで、値引き交渉があるなどして、何度も作り直しがある」ということや、「見積もっても受注につながるとは限らない」ということもあります。まあ、一言で言えば、面倒なことは嫌いなのです。ざっくりと、「いくらでやってくれ」と言われれば、それで十分という気がしているわけです。
とはいえ、そうもいかないので、今日も見積書を作ったり、内容の調整をしたりという作業をいくつか行い、他に打ち合わせが数件入っていたので、開発仕事はほとんどできなかったという感じでした。
そんな愚痴はどうでもいいのですが、見積をしたり、業績の数値を見たりしていて、自分自身の金銭感覚の変化と同じように、仕事の規模感覚の変化というものもあると感じています。
子供の頃は、1000円といえば大金で、1万円の買い物など、相当気合いを入れないとできなかったものでした。それが大学生くらいになると、アルバイトをしたりして、10万円くらいの買い物は頑張ればできるようになります。社会人になれば、20万円くらいはボーナスや、あるいは少し努力すれば買える金額となりますが、結婚すると、小遣い制になるなどして、また自由になるお金が減ったりします。いずれにしても、1000円くらいならそれほど考えずに使えるようには変化しているわけです（うーん・・・我ながら小さい人間という気もしますが・・・）。
1件あたりの見積金額も、仕事の種類によって大きく違うもので、CADシステムの開発販売をしていた頃は、500万円以上するCADを販売していましたが、出向に出たり、小さな受託仕事をしていた頃は、100万円以下の仕事が多く、その後、受託でも1案件で2000万円くらいの仕事もするようになったりして、さらに、IT製品を始めると、また数万円の製品を販売したり、あるいは数百万円のライセンスを販売したり・・・。
このように、自分自身の基準が変化するとともに、規模が大きいと感じるか、小さいと感じるかは、結構変わるものなのです。少なくとも、私がずっと関わっているIT関連の仕事であれば、製品単価が数万円というのはともかく、開発仕事で1案件が数万円というのは、はっきり言って「見積もりしたり、伝票処理をしたりするだけで、面倒なだけで、やらないか、ただで対応する方が楽」と思うことも多いわけです。開発仕事は見積自体が結構大変ですので。最低でも、1案件で100万円くらいの規模でないと、手間がかかるばかり、という印象です。そういう感覚でいると、他の分野の仕事で、数万円の見積や伝票処理をしているのを見ると、「そんなに小さな規模の仕事で手間ばかりかけて・・・」と思ってしまうのですが、そういう仕事は数で勝負していたりすることも多く、基準が違うので、素直に比較はできないものなのです。
それぞれの仕事ごとに、見積の手間、伝票処理の手間は違うもので、どのくらいの規模が割に合うかどうかというのは、仕事によって変わってくるものだと思うのですが、同じ仕事を続けているのであれば、何となく、子供から大人になったときのように、自分が対応する仕事の規模が大きくなって行ってくれている方がうれしい気がします。特に、デフレ時代の中で、単価・規模が上がっていくというのは、それなりに努力している結果ではないかと私は考えています。ということで、見積が面倒、と思うことも、悪いことではないのではないかと、自分を正当化してみたりしているのでした。
以前にも書いたのですが、当社では、毎週週初めには全社員集まっての朝礼を行っていて、そこでは全員が順番にスピーチをすることを続けています。基本的にはテーマが与えられ、日経新聞から記事を紹介する、とか、仕事で工夫していること、とか、共通のテーマに関して２〜３分程度のスピーチを行います。
目的は、
・人前でスピーチをする事に慣れる
・テーマを与えることで、調べたり考えたりするきっかけとする
・普段直接コミュニケーションが少ないメンバー同士で、何を考えているのかを共有する
という感じで、私個人としては、「人前でのスピーチの練習」という点が一番かな、と考えています。
人前でスピーチをすることは、慣れてしまえば何でもないという人も多いと思いますが、開発などの技術仕事を中心に取り組んでいるメンバーにとっては、意外と大変という人も多いようです。当社の場合は、新入社員の仕事として、事業部にかかってくる電話は率先して取る、ということや、製品の問い合わせ対応、製品デモ、あるいは、開発案件の打ち合わせなど、できるだけ技術系メンバーも社外の人と接する機会を増やすようにしてきましたので、それなりに会話には慣れているはずなのですが、それでも、大勢（というほどでもありませんが）を前にして、自分の考えを述べるのは、苦手という人も多いようです。
苦手なことは、逃げているといつまでたっても苦手なままなので、毎週の持ち回りスピーチでも、それなりに良い練習の場だと考えています。
私自身は、入社早々、CADシステムの開発担当となり、それまでは、社長が設計し、学生アルバイトが開発していたCADシステムを、正社員として担当した一人目でしたので、CADシステムのデモは全て私が担当させられました。4月に入社して6月の展示会に出展した際にも、基本的に技術的なデモや質問はほとんど私が対応したものです。おかげで内気で引っ込み思案だった私でも、お客さんとコミュニケーションを取ることは、何の抵抗感もない・・・というより、むしろ楽しいと感じられるようになったものです。
その後、出向や受託開発に方向転換した際にも、「技術的に詳しいのに、きちんと会話ができる人」として珍しがられ、すぐにたくさんのお声がけをいただけるようになったものでした。
人前でスピーチをするときの、とても大切なポイントの一つが、「明るく楽しそうに話すこと」だと思っています。やらされて嫌々話しているような状態では、聞いている方も嫌になるものです。仕事ですから、話せといわれれば、話すしかないわけで、どうせ話すなら、聞いてくれる人も明るく楽しくなれるような話し方をした方が、その場も良い雰囲気になりますし、自分の印象も良くなります。最初は緊張して引きつった顔で話してしまうものだと思いますが、何度も経験し、さらにその都度学べば、内容はともかく、明るく楽しそうに話すことくらいは、場慣れしてできるようになるものです。
そのうち、カラオケのマイクと同じで、「私に話しをさせて！」という気持ちになるものです（本当かな？）。まずは逃げずに前向きにチャレンジしてみるのがお勧めです！
昨日に続き、今日もサイクリングで峠へ・・・。
今日はいつもご一緒しているTさんと、今回初めてご一緒するHさんと、3人で。元はといえば仕事つながりですので、時代は接待ゴルフではなく、接待サイクリング（接待してませんが・・・）！？
Hさんはいくつかのヒルクライムレースに参加した経験をお持ちで、今回はHさんお勧め（？）の、成木ヒルクライムコースへ。
成木ヒルクライムレースは毎年開催されていて、ここがスタート地点だそうです。ここからしばらくはなだらかな登り坂なのですが・・・
珍しく私が走っている写真をTさんからいただきました！
途中から劇坂！白石峠どころではありません。恐ろしい坂がず〜っと続きます。なかなか汗をかかない私もさすがに汗だくです。
ぶれてますが・・・ゴールです。何とか休まずに登りきりました。白石峠と違って、自転車乗りも少ないですし、車もほとんど通らないので、蛇行運転で何とか登った感じです。。おそらく平均斜度10度を超えているでしょう。急すぎです！まあ、昨日の白石峠アタックの方が本気で頑張ったので疲れましたが、成木の方がコースとしては明らかに急です！
ゴール地点の先には、湧き水が！冷たくて美味しいお水でした。
お昼はレストランHAMAへ。おなじみステーキ丼です。卵も乗せて、カロリーもコレステロールも高そうですが、運動してますからね！
帰りは入間川CRを走破して、さらに秋ヶ瀬公園までお見送りして、帰宅しました。
走行時間：6時間2分4秒
走行距離：129.79km
平均時速：21.4km/h
最高時速：48.5km/h
獲得標高：1484m
今回はやけに写真が少ない感じですが・・・成木ですっかりノックアウトされたのと、結構休みなく走り続けたからでしょう。。いい運動になりました。Hさんともすっかり仲良しに！またご一緒しましょうね！！
今回の新兵器！
メガネのずり落ち防止。これはすばらしいです。今日はメガネを一度も上げずに走り続けられたくらい。シリコン製で耳が痛くなったりもしません。自転車はかなり前屈みになるので、メガネはずり落ちやすいのですよねぇ。
スパイベルト。ウエストポーチですね。私は毎回リュックをしょっていたのですが、峠ではリュックはかなり邪魔に感じるので、今日はリュックなしに。でも、デジカメは持っていきたいので、ウエストポーチを使いました。本当は昨日の白石峠アタックで使いたかったのですが、昨日届いたので・・・。リュックなしはとても快適でした！
一週間分の運動をたっぷりできたので、今週も安心して食事ができそうです。。
今日は本当は息子を越生のシロクマパンに連れて行く予定だったのですが、バスケットボールの練習で足を捻挫したようで、一人。それならTさんに抜かれた白石峠のタイムアタックに行くことにしました。だいぶ暑くなってきたので、7時頃出発して、涼しいうちに登ることに。
途中、コンビニで1回買い物に寄っただけで、開店前のシロクマパンも通過し、「いこいの里 大附」を超えたところの、眺めが良いところまできました。
コンビニで買ったようかんを１つ食べて栄養補給。
ここから「さいたま梨花カントリークラブ」を超えて白石峠へのショートカットルートで行きます。ショートカットと言えるかどうかは微妙で、結構登りますし、クネクネしているのでかえって距離もあるかもしれませんが、道は空いていて走りやすいのです。
今回は、Tさんのタイムを抜くために、作戦を立てました（当たるかどうかはやってみなければ分からない作戦ですが）。ショートカットルートのプチ峠で体を峠モードにして、そのまま白石峠に休まずに突入する、という作戦です。失敗すれば疲れすぎて玉砕ですが、私の考えでは、毎回、休んだ後は足が動かない気がするので・・・。
ということで、白石峠登り口で写真も撮らずに、走りながらタイマーだけスタートして登りました。今回はさらに、急でないところでは、ギアを重たくして速度を上げる、という作戦も実行します。
ひどい写真ですが、ゴール地点で撮影。38分44秒ですね！目標の40分切りを達成し、Tさんのタイムも抜けました！！いやー、疲れました。かなり暑いですし・・・。でも、作戦は見事に当たり、登りはじめから体が動きましたし、緩やかなところで休むのではなく、あえて重たいギアにしてスピードを上げる、という狙いはバッチリ！
あまりに疲れたので、休憩所で仰向けに・・・
一休みしてから、記念撮影。
登っている途中で、ビンディングペダルを使っていない人を抜いたときに「ビンディングなしですか！それは大変ですね！！」と話しかけた人がいたのですが、その方も到着したので、お話ししてみると、まだ始めたばかりで、ビンディングペダルは転ぶのが怖いから・・・と仰ってましたが、ビンディングなしで峠は辛いです。3倍くらい疲れると思います（もっとかも？）。引き足が使えないと、立ち漕ぎするくらいしかできないですものね。「ビンディングにするだけでずっと楽に登れますよ」とアドバイス差し上げました。
さて、気をよくして、このまま堂平山の山頂まで行ってみることにしました。もちろん、さらに登るのですが、タイムを気にしなくて良いなら登りも気楽なものです。
ますます良い眺めになってきます！
山頂です。876m。観測ドームがあるのですが、布団が干してあるのはちょっと・・・。そこで食事も食べられますが、帰りもプチ峠を登る予定なので、お腹には入れずにおきます。
もちろん、ちゃんとロードバイク用の自転車置き場もあります。
関東平野方面の眺め。
反対側もよく見えます。
今日は早く帰ると家族に約束してあるので、そろそろ峠を下ります。白石峠はあっさりと下り、再び梨花カントリークラブ方面へのプチ峠を逆側から登ったのですが・・・予想通りとても急です！ヒーヒーいいながら登っていたら、後ろから「こんにちは！」と声がかかり、ビックリ！「ここに来るとは、そうとうな物好きですねぇ！」と言い残して、立ち漕ぎであっという間に見えなくなりました。ふくらはぎの筋肉がすごい人でした。。
まあ、無事に登って、少し下ったところの、「いこいの里 大附」の「そば道場」で昼食に。
写真がボケてますが・・・ここはそば打ち体験ができるくらいで、そばはとても美味しいのですが、汁が私の好みの甘いタイプではないのが残念。まあ、このくらいの軽めの食事で、帰りに動きやすいようにしておきます。
家族から、シロクマパンのお土産を頼まれているので、買い物。ちょうど12時過ぎで、パンの在庫が少なかったのですが「これでもある方です」と言われました。。
ここでも休まずに、川越に戻ります。帰りはやや向かい風で、一人だと先頭交代もできず、それなりに疲れましたが、峠の後の平坦道は気分的に楽なので、スイスイ帰りました。
帰りに、サングラスを買った後に、いろいろとコースを教えていただいた、「Kaniya」さんに寄って、自転車話。可児さんの白石タイムも教わりましたが、まだまだ届きませんねぇ。。でも、「38分くらいになったということは、コツをつかんだと思うので、まだまだ伸びますよ」と、励ましていただいたので、まだまだチャレンジしますかねぇ！？
ルートラボの標高グラフを見ると、左右対称の綺麗なグラフになりました。
走行時間：4時間58分15秒
走行距離：100.98km
平均時速：20.3km/h
最高時速：57.2km/h
獲得標高：1682m
さて、今日は白石峠対策で、できるだけ荷物を軽くしようと、NEX-5ではなく、久々にこのカメラを持って行きました。掲載した写真のまともな写りのものはこれで撮影したものです。ビビットカラーモードで撮影したので、天気の良さと共に、パキッとした写りになりました。
今日は2件、ProDHCPの商談・デモなどに出かけてきました。1件目から2件目への移動は、久しぶりの「つくばエクスプレス(TX)」。秋葉原から快速に乗りました。
昼頃で社内は空いていたので、MacBookAirを取り出し、WiFiにつなぎました。とても快適です！
komata-macbook-air:Bridge komata$ ping ncad.co.jp
PING ncad.co.jp (219.101.47.162): 56 data bytes
64 bytes from 219.101.47.162: icmp_seq=0 ttl=52 time=34.382 ms
64 bytes from 219.101.47.162: icmp_seq=1 ttl=52 time=42.606 ms
64 bytes from 219.101.47.162: icmp_seq=2 ttl=52 time=31.781 ms
64 bytes from 219.101.47.162: icmp_seq=3 ttl=52 time=21.044 ms
64 bytes from 219.101.47.162: icmp_seq=4 ttl=52 time=55.171 ms
^C
--- ncad.co.jp ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.044/36.997/55.171/11.404 ms
これなら駅やお店でのWiFiと同じ感覚です。N700系のWiFiとは大違い！
Radish Network Speed Testing - Test Report
=== Radish Network Speed Testing Ver.3.2.2 - Test Report ===
測定条件
精度:低 データタイプ:標準
下り回線
速度:1.573Mbps (196.6kByte/sec) 測定品質:0.0
上り回線
速度:6.433Mbps (804.1kByte/sec) 測定品質:72.4
測定者ホスト:**********************.tokyo.ocn.ne.jp
測定サーバー:東京-WebARENA
測定時刻:2012/5/18(Fri) 13:06
------------------------------------------------------------
測定サイト http://netspeed.studio-radish.com/
スループットもまあ、移動中にこれだけ出れば十分。
気をよくして、会社にVPNで接続し、sshでログインして、出かける直前まで試行錯誤していた、TCPチェックサムの高速化の確認を始めました。実に快適！
・・・と思っていたら、北千住を過ぎたあたりから何となく動きがもたつき始めました。。
64 bytes from 219.101.47.162: icmp_seq=18 ttl=52 time=22.481 ms
64 bytes from 219.101.47.162: icmp_seq=19 ttl=52 time=37.598 ms
64 bytes from 219.101.47.162: icmp_seq=20 ttl=52 time=204.350 ms
64 bytes from 219.101.47.162: icmp_seq=21 ttl=52 time=657.771 ms
64 bytes from 219.101.47.162: icmp_seq=22 ttl=52 time=664.084 ms
64 bytes from 219.101.47.162: icmp_seq=23 ttl=52 time=275.574 ms
64 bytes from 219.101.47.162: icmp_seq=24 ttl=52 time=645.248 ms
64 bytes from 219.101.47.162: icmp_seq=25 ttl=52 time=733.211 ms
64 bytes from 219.101.47.162: icmp_seq=26 ttl=52 time=246.434 ms
64 bytes from 219.101.47.162: icmp_seq=27 ttl=52 time=21.464 ms
64 bytes from 219.101.47.162: icmp_seq=28 ttl=52 time=18.157 ms
多少RTTにばらつきが出てきました。
64 bytes from 219.101.47.162: icmp_seq=19 ttl=52 time=20.343 ms
64 bytes from 219.101.47.162: icmp_seq=20 ttl=52 time=53.939 ms
64 bytes from 219.101.47.162: icmp_seq=21 ttl=52 time=47.700 ms
64 bytes from 219.101.47.162: icmp_seq=22 ttl=52 time=138.463 ms
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
・・・
Request timeout for icmp_seq 66
Request timeout for icmp_seq 67
Request timeout for icmp_seq 68
64 bytes from 219.101.47.162: icmp_seq=69 ttl=52 time=153.573 ms
64 bytes from 219.101.47.162: icmp_seq=70 ttl=52 time=157.074 ms
64 bytes from 219.101.47.162: icmp_seq=71 ttl=52 time=156.192 ms
64 bytes from 219.101.47.162: icmp_seq=72 ttl=52 time=37.822 ms
ついに、パケロスも結構増えてきました。。まあ、TXはスピードも速いですしね。VPNは少々辛くなってきたので、作業は諦めました。もっとも、WEBやメールくらいならそれほど気にならない感じです。
N700と比べると、やはり乗客の人数の違いもありますので、あちらはかなり制限をわざとかけているのでしょうね。
しかし、秋葉原駅からつくば駅まで、1150円は高い気がしますが、スピードが速いから距離を感じないためですかねぇ？
さて、つくば駅は2回目なのですが、ここはとにかくだだっ広いですねぇ。
なんだか、ラスベガスあたりの景色と勘違いするくらい！？
このところ、ProDHCPのお問い合わせがとても多くて、ようやく製品販売っぽくなってきました（？）。よく言われるのが「わざわざ社長さん自ら・・・」という事なのですが、ProDHCPのIPv4版は私が開発したものなので、わざわざもなにも、私が一番良く知っているだけのことでして。。「プログラマー社長ですから」と説明するようにしています。
ProDHCPは冗長化を、最大で1:16まで構成できるので、遠隔地への分散構成も組みやすいという特徴もあるのですが、お客さんから「DHCP フェイルオーバー」で検索したら引っかからなくて、なかなか見つけられなかった、と教えていただきました。さっそくキーワードを入れ込んでおかないと。。
1:2での冗長化の検証環境をセットアップしながら説明し、後はご評価いただく感じで作業を終え、帰りは、TX〜武蔵野線〜東上線で帰りましたが・・・遠い。。
庭（？）のバラがたくさん咲き始めました！
朝の坂本さんが数日前に「出来るプログラマーはなぜ尖がった一匹狼的な人間になりやすいのか？」という記事を書かれていて、少し考えることがあったのですが、忙しくてようやくその話題に関して書いてみようと思います。
私は著書「プログラミングで飯が食えるか！？」をはじめとして、「得意分野で勝負しよう」ということを、個人に対しても組織に対しても言い続けてきました。プログラマーであれば、まさに「尖れ」と言ってきているのです。私自身もUNIX系（というより最近はLinuxばかり？）のC言語によるネットワークプログラミング以外はまずやらない感じで仕事をしており、WEBやDBの話題が出ても、ほとんど話しについていけない位なのですが、自分の仕事は減るどころか増え続け、昨日の社内ミーティングでも「実はプログラミングを一番忙しくやっているのは社長という状況はどうなのか？」と種田君から言われたくらいです（中小企業の社長がいわゆる社長業に専念できる会社などほとんどないと思いますので、社長が得意分野で勝負し続けているのは全く悪いことではないと考えているのですが、さすがに細かい仕上げの作業などまで社長自身がやるのは無駄で、その時間くらいは社長業に使うべき、という話しです）。
一方で、私がCADシステムの開発販売から、出向を経て、受託開発を始めた頃に、仕事でご一緒した方々から言われたことが、「小俣さんは技術に詳しいのに、話もできる。そういう人はとても珍しい。」ということでした。たまたま私の場合、CADシステムの開発販売、つまり作るだけでなく、売ることも任せられたため、デモや商談なども嫌というほどやることになり、コミュニケーションの訓練を早いうちにできたというのが良かっただけだと思うのと、もともと社内でじっと作業をするのが嫌いで、お声がかかればすぐにでも出かけたいという性格のおかげ（自分からそうなろうと思っていたという気もしますが）だと思っています。いずれにしても、「尖った技術者＝一匹狼」という傾向はあり、おかげで私は大して尖っていなくても、コミュニケーションもできることとの合わせ技で尖って見えたのかもしれません。
以前、ある会社のCTOの方とお話をした際に、「エース級の技術者は現場仕事には回しません。エース級でないと回らない状態の仕事では大きな仕事にできませんし、エース級には他のことをしてもらいたいのです。」と仰っていました。エース級の技術者は、技術的な目処をつけるまでが仕事で、それを稼ぐ状態にして回すのは他の人にやらせる、ということです。さらに、エース級の人の重要な仕事は、「情報発信」だそうで、「あの人が活躍している会社なら、一緒に仕事をしたい」と、できる人が集まるような魅力を発信することが重要な仕事なのだそうです。
当社も、種田君をはじめとして（種田君だけ実名で登場するのは同じオルタナブロガーだからというだけで深い意味はありません）、このところメンバー達は私の著書やブログを読んで興味を持ってアプローチしてきてくれた人たちです。「ルーター自作でわかるパケットの流れ」のような尖りまくった著書もつい先日書いたくらいですから、技術ネタもまだまだ発信しています。そういう意味では私は知らず知らずのうちにCTOの方が考えているような仕事の仕方をしていたとも言えますが、単に自慢好きだった、とも言えるかもしれません。技術的な目処だけつけて後は任せる、というのも、半分くらいはできている感じでしょうか。
朝の坂本さんが仰るように、協調性を持って、ビジネスをしっかり固めていく人たちもとても大事です。当社でもそのような役割で力を発揮してくれているメンバー達が製品事業や受託開発事業を支えてくれています。一方で、新しいことにチャレンジしたり、尖った情報を発信したりするようなメンバーも、当社のように「これさえあれば大丈夫」という製品がない会社にとっては大切であり、尖った一匹狼もある意味「大歓迎」なのです。それこそ私自身も「今日から新しい技術的なことは一切やらないで」と言われたら鬱になりそうですし、尖ったことにはまっているときには、不機嫌になったりしますから、尖った人の気持ちはよく分かっているつもりです！？
もっとも、不思議なことに最近は、すばらしい技術を持っている人でも、人間的にもとても立派な人が多くなった気もしていて、ある意味IT技術自体がそれほど尖っていない技術になり、意地を張らなくても認めてもらえる機会もあり、精神的に余裕がある人が増えてきたのかもしれませんね。
いずれにしても、「尖った人」も大活躍できる会社として、まだまだ当社は尖りたいと思っているのでした。
一昨日、「10Gイーサーを実際に使ってみた」 の記事で、チェックサム計算がスピードの影響している、と書いたところ、WIDEプロジェクト以来のお友達（と呼んでいいのかな？）の山本和彦さんから、
「IPチェックサムの計算は、桁数に依存しないので、4バイトごとに計算しているようなら、8バイト単位(そのハードで一番自然な単位の意味)で計算すると速くなるかもしれません。」
とコメントをいただいたので、早速実験してみました。ついでに、RFC1071に出ているソース、種田君がどこかから見つけてくれたソースも合わせて、5パターンで速度計測をしてみました。
64ビット環境
% cumulative self self total
time seconds seconds calls ms/call ms/call name
36.47 4.95 4.95 501 9.88 9.88 checksumRFC ←RFC1071に出ているソース
29.37 8.93 3.99 501 7.96 7.96 do_csum ←種田君からもらったソース
18.72 11.47 2.54 501 5.07 5.07 checksum16 ←自作16ビット単位
9.54 12.77 1.30 501 2.58 2.58 checksum32 ←自作32ビット単位
5.62 13.53 0.76 501 1.52 1.52 checksum64 ←自作64ビット単位
32ビット環境
% cumulative self self total
time seconds seconds calls ms/call ms/call name
28.39 4.59 4.59 501 9.16 9.16 checksum16
23.74 8.42 3.84 501 7.66 7.66 checksumRFC
20.76 11.78 3.36 501 6.70 6.70 do_csum
13.64 13.98 2.20 501 4.40 4.40 checksum32
13.64 16.19 2.20 501 4.40 4.40 checksum64
64ビット環境だと、断然64ビット単位で計算するものが速いですね！32ビット環境だと同じか、場合によっては32ビット単位の方が速い感じでした。条件コンパイルで使い分ける感じでいけそうです。
もともとは16ビット単位で計算していました。確かどこかで見つけたソースを流用して使っている感じだったと思いますが、実は他の製品とかでも使っているので、入れ替えると性能がUPするかもしれません（もっとも、10Gでリンクする製品は今のところ他にないので、誤差の範囲かもしれませんが）。
今回のシステムでは、64ビット単位版と、さらに差分計算を組み込んで高速化できそうです。
なお、64ビット単位で計算する場合は、それ以上大きな整数型がないので、桁あふれに注意しながら計算するようにしないと計算結果が間違えるので、自作する方は注意しましょう。
情報発信すると、誰かの役に立つこともあると同時に、こうやって教えていただけるのもうれしいことですね。
山本さん、ありがとうございます！
ストレス社会との付き合い方
「思いやり経営」のススメ
テレワークが労働者のマインドを変える
求む、クックパッド男子
37歳の常識――我々は一生学び続ける