プログラマー社長のblog

過去のデータはこのままここに残します。

新しいサイトのブログでもよろしくお願いいたします。

今日は稲川さんのMBAで、５Forceの勉強と、ケーススタディに取り組みました。マーケティングでは3C,4Pと共に5Fも有名だそうですが、個人的には3C,4Pは英語表記での頭文字が揃っているのに、5FはFで始まるわけではないのが少々不満な気もしますが、まあ、本質には関係ないことですね。

ケーススタディは10ページくらいのある会社の実話を読み、議論のテーマに対してメンバーで議論してみる、というもので、あくまでも書いてある内容をベースに議論することがルールです。今回のケースは1996年から2003年くらいまでの話題で、頭も当時に置き換えて考える必要がありました。

1996年というと、まだまだ日本ではインターネットが一般に広まる前の時代で、私がIIJで個人アカウントを取得してホームページの公開をはじめたのが1998年3月4日ですから、たった12年前とは言えどもかなり今とは違う時代です。今でも1998年からのメールは大体取ってあるのですが、当時のメールを読み直すと大昔と言いたくなるくらい、時代の変化は早いものです。私がホームページの公開やEメールを使い始めてからたったの10年しかたたないうちにインターネットはプライベートでもビジネスでもなくてはならないものになり、その間に多くのビジネスモデルが登場しては消えという繰り返しがあったのです。

実は当社のIT事業部の前身であるPLASMA事業部がはじめて黒字になったのが1996年だと思います。それから12年間ほぼ黒字を続けてきたのは、変化の激しいIT業界で立派とも言えますが、チャレンジが少なかったという見方もできるでしょう。そういえば1冊目の著書を書いたのは2000年でした。年を取ると1年があっという間になってきます。そんな話題も含めて盛り上がったMBAでした。

今日は午前中、お客さんにネットワークのプログラミングで面白いテーマがあるということでお声がけいただき、ミーティングしてきました。3万コネクションのTCP接続・高スループットでの通信など、なかなかの難易度で、お客さんもまだ受注が決まっていないものの、性能要求を満たせるかどうか検討をしているところだそうで、興味あれば相談にのって欲しいという感じでしたが、私としてもできるかどうか、まずはプロトタイプで実験してみたいということで、持ち帰りました。とりあえず当社ネットワークチームのメンバーで誰が一番高性能なものを作れるか、競争してみようという感じで、取り組んでみることにしました。いつものごとく、仕事になるかどうかはともかく、技術的にチャレンジすることが楽しそうであればどんどんやってみるメンバーの特性をお客さんにも読まれているのですが、やりがいのあるテーマは自分で見つけるより相談いただいたものの方が楽しい場合が多いので、とてもありがたいことです。

午後はアイティメディアさんを訪問し、今度オルタナティブ・ブログにこのブログを移行しようということで、打ち合わせをしてきました。もっとも、打ち合わせというより同世代の方との雑談で盛り上がってしまい、SONYのNEWSの頃は面白かったね、とか、CISC,RISCなどの年代がばれてしまう話題で盛り上がりました。

ちょうど今日はiPhoneの発売日ということもあり、ビックカメラ有楽町店は行列とテレビ中継で大変な状態でしたが、人混みが嫌いな私としては有名人がいようが何だろうが、とっとと通り過ぎてきました。Mac派の私としてはiPhoneは興味津々ですが、いくら何でも毎月8千円は厳しいですね。1年で10万円くらいになってしまうと考えるとすごいですよね。ソフトバンクの携帯も家族向けに使っていますが、S!メールが使えないなど、家族にはあまり喜ばれそうもなく、しかも今使っているX02HTはまだ７ヶ月ちょっとしか使っていないので買い換えると大変なことになりますから、諦めます。アップルストアでは見本が置いてあるのみで、販売はしていないのでごく普通に触ることができました。iPodTouchでも良いのですが、それも80GBのを昨年買ったばかりなのですよねぇ。まあ、お金もないのでおとなしくしていましょう。

今日はSMTP関連で２つ取り組んでいました。一つは私が自分で作り、社内用・社外提供用に使っているSMTPプロキシの改良です。メール配信は再送の仕組みなどで非常に複雑になるという話題は以前書きましたが、プロセス数をある程度で制限したいというご希望をいただき、変更していました。並列処理を実現するにはざっくりとマルチプロセス・マルチスレッド・多重化の3種類がありますが、SMTPプロキシはマルチプロセスで作ってあります。理由はいろいろあるのですが、試行錯誤しながら使うことを前提に、とにかく全体がダウンすることを避けたかったという点がポイントでした。マルチプロセスは全体がダウンしにくい反面、データの共有が面倒で、全体のプロセス数というのは意外と管理しにくい状態だったのですが、何とかアイディアが浮かび、対応できました。

もう一つ行っていたのが、Postfixの性能測定で、これがどうしても良い性能が出ないのです。telnetでSMTPポートに接続して手動でSMTPコマンドを送りながら様子を見ると、基本的に宛先の信頼性をチェックするのに時間がかかっているようで、高負荷状態にするとRCPT TOの応答がかなり遅くなります。DNSを調整したり、DNSを使わないような設定にしたりしながら検討したのですが、結局望みの性能にはほど遠い状態です。Postfixはオープンソースなのでソースまで見て検討すれば何とかなるのだろうとは思うのですが、それほどの時間は使えません。

私は以前より「使いこなす」より「作る」方が好きなのですが、理由は実はこのあたりです。自分で作るのはシステムの規模によっては大変なのですが、後で何か困ったことになっても、調査・対策ともに比較的すぐに行えます。他人が作ったものを使いこなすのは簡単そうですが、何か困るとかなり大変なのです。自分で使うものもそうですが、お客さんに提供するものはさらにそうです。障害発生時や相談が来た際にすぐに対処するのがなかなか大変です。オープンソースは自分でソースを調べたり、コミュニティに相談することができますが、ソースが非公開の製品はさらに大変です。

もちろん、作るといってもOSからとかコンパイラも作るのか、と言われるとそこまでやる時間は取れませんが、何でもかんでも出来合いのもので何とかしようと考えるのもどうかと思います。自らプログラムを作れる人はできる範囲で自作するという考えもむしろ大事なのではないかと考えています。そうすることにより使いこなしとは別の次元のノウハウもつかめるはずです。もっともの作りを楽しむくらいの心意気があっても良いのではないでしょうか。

岩国といっても知らない人にはなんだかわからないと思いますが、当社メンバーが2回に渡り岩国のある工場のシステム開発の仕事を行い、先日無事に稼働を開始し、戻ってきたので、その成功祝いを行ったということです。

岩国の前に苫小牧でも同じような工場のシステムを手がけ、そのときには私も一夏で何往復したのかというくらい東京と苫小牧を往復しましたが、そのときの若手メンバーであった青木君がリーダーとなり、さらに二人のメンバーと共に合計約1年半の仕事をやり遂げました。岩国の仕事は開始当時は私も工場に打ち合わせや接続テストに行きましたが、途中からは青木君を中心にしっかり進め、年末年始と先日の2回に渡るリリースを、ほぼノートラブルで行いました。

工場での作業は日夜を問わず、さらに騒音や室温など様々な環境下での作業ということもあり、非常に疲れる仕事で、さらにシステムに障害が発生すると工場のラインが停止してしまい、大損害につながるというプレッシャーから非常に精神的にも辛い仕事です。

苫小牧では元請けさんと共に大問題となり、大変な対応を行いましたが、その経験を活かし、岩国ではかなりスムーズに仕上げることができたのは青木リーダーと、共に仕事をした種田君、楊箸君のすばらしい成果です。彼らの今後にとってもすばらしい経験となったことでしょう。

この一連のシステム以外でももちろん仕事ごとに固有の苦労があり、乗り越えるために体も心もつぎ込みながらシステム開発は進めます。苦労も多いものですが、同時に達成感も大きなものがあり、システム開発の醍醐味と言えるでしょう。

私としては、プロ野球などで優勝祝賀会を行うときのようにハメを外して祝いたいところなのですが、社内では様々な仕事が常に進行しており、なかなかそうもいかないのが歯がゆいところですが、区切り区切りで成果を喜び、また次に向けてがんばるきっかけとして、お互いにたたえ合う機会を大事にしたいと考えているところです。

今日は久しぶりに1日会社で、比較的自分の作業を進めることができた感じです。あるお客さんから依頼されているSMTPプロキシの変更・テストなどを行いました。このSMTPプロキシはもともとは私の3冊目の著書「C言語によるTCP/IPセキュリティプログラミング」（2002年秋）で紹介した、メール・ファイアーウォールが原点で、その後改良しながら自社のメール・ファイアーウォールとして使い続けており、途中、数社からの依頼でカスタム版を提供したりしてきました。基本的にはMTAで、ローカルメールボックスに保存できないことを除けばSMTPの解釈・MXレコードの検索・配信・再送制御などフルスペックで、さらに、外部プログラムを中継させることにより、メールの安全化や全文保存、添付ファイル切り出しなどの機能追加ができ、スパム対策でグレイリストやターピッティングもできるという、まさに盛りだくさんなプログラムなのですが、もともと再送制御を中心に複雑なプログラムで、さらに度重なる改良により、プログラムソースはひどい状況で、今回もカスタム提供版に最新版の一部の機能を組み込むだけでかなり苦労しました。今ならこのような作りにはしないのですが、作り直す時間も取れそうもありませんし、ずるずると使い続けている感じです。PostFixなどを使えば同様のことはできるのですが、やはり全体を把握しているプログラムは応用しやすく、なかなか手放せない状態です。

また、このところ実績も出始めたアルマジロを使った製品ですが、IntraGuardianの最終機能向上とテストを行いながら、これまで貸し出し評価で得られた問題点・ご要望などに対応しているのですが、ある機能をやっぱりもう少し向上させようと、メンバーから相談があり、今のプログラムに機能追加するか、別プログラムを組み合わせるかという選択を検討しましたが、やっぱりできるだけシンプルなモジュール・プログラムの組み合わせで構成すべきということで、後者を選択しました。

長年プログラミングをやっていると、自分で作ったものはもちろん、他人のプログラムのメンテナンスなどを行い、その結果として、メンテナンス性はシンプルさと比例すると痛感しています。最悪なパターンが画面と機能を1プログラムで作り上げてしまったケースで、GUIと機能を一つにすると多くの場合非常に複雑なソースになり、さらにGUIのイベントループとバックグラウンド処理などの並列化でひどく苦労することが多いものです。ハードの性能が低い頃は性能優先で1プログラムで作らざるを得ない状況でしたが、今では性能より機能・使い勝手を求められるほどハードも進歩し、機能ごとに分割しないとまともに動く状態にするだけで大変な思いをする時代だと思います。

迷ったときはとにかくシンプルに、これが9割は当てはまると思います。

今日は稲川さんのMBAワークショップの2回目として、Negotiationをテーマに講義・実演を行いました。Negotiation：交渉はビジネスでも日常でも頻繁に使うもので、特にビジネスにおいては社内外の関係や仕事の分担・費用などの調整で欠かすことはできず、結果を大きく左右するテクニックと言えるでしょう。

細かいテクニックはいくらでも本などに紹介されていると思いますので、ここであえて書きませんが、交渉の上手い下手はいったい何から差が出るのでしょうか。

私自身を振り返ると、子供の頃から気が弱く、いじめられ子で交渉ごとはことごとく自分が譲る側になっていたと思います。社会人になった時点で考えても、基本的にのんびりした性格で交渉ごとはできれば避けたいような性格でした。ところが、自分で事業部を作り、メンバーの分まで含めて責任を負わねばならないような立場になるにつれ、交渉しなければなにひとつ有利な状況に立てないということを味わい、徐々に交渉をせねばならない状況になっていったというところでしょう。もちろんプライベートでも一人暮らしをはじめたり、結婚したりするうちに様々な交渉が必要になります。

交渉の上手い下手は場数の多さではないかと思うのですが、同時に責任の重さがポイントだと感じています。交渉が不利な結果に終わっても影響が対してない場面をいくら経験しても、大して上手くはならないのではないかと思います。

交渉のポイントは基本的には双方にとってハッピーな結果を目指すことでしょう。特にビジネスにおいては片方だけに偏った結果は長続きせず、長期的にはマイナスになることが多いものです。自分だけ良ければ、という考えで交渉に臨むと大抵は失敗につながるということですし、それ故企業のスタンスとして「公」の立場が重要なのです。もちろん企業なので利益を上げねばなりませんが、相手にとってもメリットがある仕事をしなければ続きませんし、それがわかりやすく言うと「社会貢献」という言い方になるのだと思います。

お客さんと共にWin-Winの関係を目指して行動するようなメンバーが育っていくことを願っています。

今日は品川でLBIサロンを開催し、私も参加してきました。今回は「いまさらLinuxデスクトップ」というテーマで、OpenOffice関連、Mozilla関連、TurboLinux関連それぞれの講演者をお招きして、非常に楽しい話題で盛り上がりました。このテーマは自分にはあまり関係ないかな、と思って参加しても、それぞれの分野のスペシャリストのお話はとてもおもしろく、毎回とても楽しみにしています。

もちろん夜には懇親会を開催し、講演者の方々はもちろん、LBIメンバーをはじめとした皆様と歓談を楽しみました。普段なかなか知り合う機会のない方々との交流の場としてもLBIをはじめとして集まりはとても大切な場で、ビジネスにつながるかどうかなど抜きにした交流が毎回広がっています。

LBIサロンは参加無料ですし、LBIに加盟しても年会費は2万4千円（このところさらに半額）と、格安ですので、是非Linuxをはじめとしたオープンソース関連に興味のある方は参加してみてください。私もまだ加盟して2年程度ですが今年は副会長ということからして、上下関係も何もない集まりだということがおわかりいただけると思います。

今日はアイティメディアの上島さんのご紹介で、ビーコミの加藤さんとの場を設けていただき、当社山本君と共に、製品PRについてご相談させていただきました。上島さんは前にも書きましたが、私の最初の3冊の著書の編集を担当してくださった恩人です。PRの方法に関して加藤さんは惜しげもなくどんどんアドバイスをしてくださり、我々PRの素人では全く思いつきもしないやり方をたっぷり教えていただけました。今後我々の方でもう少し整理して、具体的にお仕事としてご相談させていただきたいと考えています。

山本君のカタログのデザインセンスなどをプロの目からお褒めいただいたのはだいぶ自信になったことでしょう。

加藤さんはアイティメディア内でもかなり顔が広いらしく、次々とお声がかかり、我々もブログ関連の方にご紹介いただいたりし、上島さんが「俺より顔が広いかも・・・」とおっしゃるくらいでした。初対面の我々に対しても親切にたくさんのアドバイスをくださるような姿勢がどんどんファンを作っているのでしょう。

最近のオープンソースの人気と同様、このところ何回か書いたリクルートさんのやり方も同じですが、まずはどんどん情報をサービスし、頼られる存在になることで、情報が集まり、結果として良いもの、良い仕事につながるのだと感じています。私も当社のメンバーもオープンさには自信がありますので、ますます自信を持って情報を発信していく気になっているところです。

いずれにしても今後のPRのヒントをたくさんいただきましたので、是非それを活かして、メンバーと共に広く社会貢献できるようがんばりたいと思います。

また、毎回思うことですが、すてきな方々と出会える運の良さは私の宝物です。

今日から再び稲川さんによるMini Business Administration（MBA）の第2期が始まりました。今回はIT事業部向けで、参加者ができるだけ口や頭を動かすことをポイントに、ビジネスに必要な知識の勉強・練習を行うことにしました。

今日はまず「伝え方」ということで、紙に描かれたものを、説明者一名が口頭のみで伝え、他の参加者が紙に描く、ということを2通りやりました。同じ説明を2回してはならないという条件付きです。意外と言葉だけで図を説明するのは難しく、特に2問目の立体図形は正解率がかなり低い結果になりました。伝えるポイントとしては、「最初に全体像を伝える」「何度もくどく説明するとかえってわからない」というあたりでしょう。NASAなどでもこのような取り組みは行われているようで、宇宙などで緊急事態が発生した際に言葉だけでどれだけ的確な情報交換ができるかなどの訓練にもなるそうです。ビジネスでもプレゼンテーションやミーティングの場面などで、的確な伝え方などの面で非常に役立つことでしょう。

続いて、リーダーシップの局面からの性格判断テストのようなものを参加者で実行してみて、それぞれ自分で思っている自分自身の性格を調べてみました。おおむね皆が当たっているということでした。それをふまえて、たとえばセールスマンというのは先天的な性格によって向き不向きが決まるのか、あるいは環境など後天的なもので育てることが可能なのかという議論を行い、基本的には行動やふるまいは、「先天的なもの」「環境」さらに「先天的なものと環境の相互作用」で決まるという説明があり、たとえば彼はこういう性格だからこういう役割には不向き、などとリーダーがその人の範囲を限定してしまうような扱い方をするのは良くないという話題などにふれました。私自身は著書などで何度も書いていますが、根本的な部分以外の性格は自分の意志や環境で変えられると考え続けており、実際私も小学校の頃は引っ込み思案でいじめられっ子だったのが嫌になり、自分で性格を変えると考えて、毎晩マラソンをして運動神経と忍耐力を鍛えたり、友達に自分は変わるから、と話をしてみたりして、性格をかなり変えることができました。さらに超進学校に高校で通うことにより落ちこぼれを体験し、挫折はあまり感じなかったものの、劣等感や開き直りを身につけ、それと共に他人と同じことはやりたくないという思いを持つようになりました。自分や環境によって性格や考え方はかなり変えることができるのを身をもって証明できるのです。おそらく小学校時代の同級生に今会うと、当時とは全く性格が違うことにビックリすることでしょう。もちろん深層心理の一部はいまだに弱い部分を引きずっている部分もありますが、少なくともビジネスの場においてそれが影響することはないくらいの状態には自分の意志でできているのです。

メンバー一人一人の個性を理解しつつも可能性をリーダーが自ら狭めてしまうようなことはせず、機会を与えながら育ってもらうことが、結果としてチームのレベルアップにつながるということは、とても重要なポイントだと思います。