仙石浩明の日記

技術と経営

2006年4月17日

オープンソースにこだわる

多くの会社と同様、KLab (および KLabセキュリティ) でも、 出来る限りオープンソースを利用するようにしています。 我々がDSASと呼んでいる システムインフラは、完全にオープンソースベースとなっており、例えば 「ファイアウォール兼負荷分散器兼ルータマシン」も Linux ベースとなっております。

なぜオープンソースにこだわるのか？

佐野氏のコラムに、 オープンソースにこだわる人の理由って正しい？: 

    > オープンソースにこだわる人に理由を聞くと普通
    >
    > 　１．無料だから
    > 　２．大勢の人が使っているからバグが少ないと思われる
    > 　３．ソースコードが公開されているから安心
    >
    > という答えが返ってきます。１と２はまあその通りだと思います。
    > しかし３は個人的にちょっと疑問です。
    > オープンソースにこだわっている人で、オープンソースソフトウェアの
    > ソースコードを実際に分析したことがある人って
    > どのくらいいるのでしょうか。
      ……
    > なのでオープンソースにこだわる理由を聞かれたらかっこいいこと
    > 言わずに素直に「無料だし機能に不満もないから」くらいにしておくのが
    > よいのではないでしょうか。

という問いかけがありました。さすが佐野さん、的を射た厳しいご意見ですね。 正直な話、KLab もオープンソースを利用しているといっても、 スミからスミまで分析しているわけではありませんし、 「無料だし機能に不満もないから」という面もあることは否定しません。 しかし、お客様にサービスを提供するという立場としては、 もう少し積極的な理由も持ちたいところです。

責任あるシステム運用を実現するためのオープンソース

システムにベンダ任せのブラックスボックスな部分があると、 その部分が原因の障害への対応は遅くなりがちですし、 原因究明を完全に行なうことができなければ、 再発防止策も対症療法的なものになりがちです。 これでは自信を持ってお客様にサービスを提供することができません。

KLab も以前は箱モノの負荷分散機を利用していたのですが、 クリティカルなバグに散々悩まされました。 この箱モノは L2処理に問題があり、 通信不良が発生するケースがあったのです。 もちろんベンダへは症状を報告していたのですが、 完全な対策には至らず、なんとか運用でカバーしていました。

これでは、いつ症状が再発するか分からず 精神衛生上もよろしくありません。 そこで、LVS (Linux Virtual Server) を使って Linux ベースの負荷分散機を 構築することにしました。 むろん、LVS のソースコードの全てを完全に把握しつくし、 LVS プロジェクトに貢献できるようになるまでには、 まだまだ道程が遠いのですが、 再現可能な障害であれば問題の所在を見つけ出せる程度の レベルには達することができていると思っています。 しかも、実はこうやって自前で構築した負荷分散機の方が、 それまで使っていた箱モノよりずっと安定して運用できてしまったのです。

ベンダの都合に振り回されないためのオープンソース

プロプライエタリなソフトウェアを使っている場合は、 ベンダがサポートを停止するリスクというのも考えておかねばなりません。 ベンダがサポートを止めたことを理由に、 弊社のお客様に対するサービス提供を止める、というやり方も 無いわけではありませんが、 技術会社を標榜する KLab としては、 あまりそういう言い訳はしたくありません。

すると、 ベンダがサポートを止めたときのことまで考えておく必要がありますが、 あいにくソフトウェアの使用許諾というのは一般に不平等契約で、 ソフトウェアを使用する側には打つ手がないことが多いようです。 ベンダの都合に振り回されるよりは、 いざとなったら自前で解決できるよう、 ソースがオープンになっているソフトウェアを選ぶ方が 結果的に楽といえるのではないでしょうか。

「なんかプロプライエタリって馬鹿みたいだな」 (ここギコ！) で、 

    > プロプライエタリなソフトの方がよっぽどリスクだらけちゃうの？
    > わざわざクソ高い金払うのに、と思えてくる。

という意見も出ているように、 ベンダのサポートがアテになるケースばかりとは限りません。

自由なシステム構築を実現するためのオープンソース

どんなに柔軟性が高いソフトウェアでも、 カスタマイズで可能な範囲というのはタカが知れています。 ソースを改変することによって得られる自由とは雲泥の差でしょう。

KLab としては、 他社では行なっていないような方法で、 耐故障性を向上させたり、 性能を向上させたり、 より低コストな運用を実現したり することによって、 差別化をはかっていきたいわけで、 そうなるとベンダの製品を使うよりは、 オープンソースを使うべき、という選択になります。

実際にどのようにオープンソースを活用しているかは、 DSAS開発者の部屋などで 紹介していきたいと思っておりますし、 オープンソースを活用していく過程で我々のレベルが上がって、 オープンソース界に貢献できるようになれれば、 それは我々にとって望外の幸であり、 それを目指して研鑽を積んでいく所存です。

Filed under: システム構築・運用,技術と経営 — hiroaki_sengoku @ 06:19
2006年4月16日

交通広告: 個人情報スキャナ P-Pointer

KLabセキュリティの主力製品である、 個人情報スキャナ 「P-Pointer」 の広告を、4/14 から一ヶ月間、地下鉄に出すことにしてみました。 インターネット広告が伸びつつある今、 時代に逆行しているようですが、 交通広告という従来型の広告がどれだけ効果があるか楽しみです。

東京メトロ 地下鉄 半蔵門線 に掲載した、 P-Pointer の 窓上広告:
P-Pointer 交通広告

一般的には、窓の上の広告なんて (見上げないと見えないから) 誰も見ないだろうということで、 吊り広告などに比べると安価な窓上広告なのですが、 

      我々がリーチしたい人達はラッシュの時間帯に乗る通勤客
        ↓
      ラッシュ時間帯の田園都市線は死ぬほど混む
        ↓
      とても新聞とかを読めるような状態ではない
        ↓
      地下鉄だから景色を見るわけにもいかない
        ↓
      仕方ないんで窓の上の広告でも見るか

となるので、 混雑する通勤路線であればあるほど窓上広告は効果的だと想像した次第です。 私自身、毎朝毎晩、ラッシュの田園都市線 (渋谷から西へ伸びる東急路線です。地下鉄半蔵門線と相互乗り入れしています) で通勤していて、 窓上広告を見る機会が多かったりしますし、 沿線にはいわゆる「IT業界」の会社が多く、 「個人情報」にセンシティブな人が多いだろう、 ということで半蔵門線を選びました。

Filed under: 技術と経営 — hiroaki_sengoku @ 06:40
2006年4月11日

情報処理のキホン (1) hatena_b

KLab の開発に参加いただいている協力会社の A 社の S 社長が、

- o -

私自身は情報処理のキホンをちゃんと「教わったり習ったり」した ことはなく、その点で、至る所で「やっぱりキホンがしっかりして いる人には適わないなぁ」と感じるシーンも経験します。

で、大学や専門学校で情報処理を学んで来た人に教えて欲しいの ですが・・・・・・

Q1） 学校でどんなコース(講義/単位)がありましたか。
○○学 とか ○○技法 とかそんな感じの。
Q2） その中で、印象深かったものや、今こうやって開発の現場で仕事を
していて「学んでよかったなぁ」と思ったものを教えてください。
Q3） 今この会社の、学校でそういうことを学んでこなかった人に対して
「俺が解るように教えてやる！」というのがあるとしたら
どんな事ですか。
- o -

という質問を tech ML にしました。
みなさんならどう答えますか？

A1)
私は情報工学科だったので、論理回路からコンパイラ、ソフトウェア工学まで一 通り学びました。ついでにいうと実践的なプログラミングは、某ソフトウェアハ ウスでバイトして覚え、ネットワークは、最初の就職先のイントラ構築の手伝い をして覚えました。
A2)
専門課程で学ぶ事で一番大事なのは、「大海」を知る事ですね、きっと。 「大海」を知らない「井の中の蛙」は、決して「井」から出る事はできません。
大事なのは知識や経験を身につける事ではなくて、自分が何を知らないかを 知る事です。
大学は「開発の現場で」役にたつことを教えてくれない、と多くの人が言います が、そういうことを言う人って、ほぼ確実に自分が何を知らないか分かってない と思います。
A3)
なんでもいいです。自分では到底作り出す事ができないものについて、 完全に理解するよう努力する経験をすることができるのであれば。
言い替えれば、何か (What) を学ぶ事が重要なのではなくて、
まして、どうやって (How) を覚える事なんて重要であるはずがなく、
体得すべきは、なぜ (Why) を問い続ける習慣そのものです。

「トランザクション輪読会」(社内輪読会です) の本を、 「分かったつもり」レベルではなく、 完全に理解できるまで頑張るとかでも、もちろんいいですね。 どこまで完全に理解できたか自体は、実はあまり重要ではなくて、 理解しようと努力して、自身の限界まで力を出し切ってみることが事が 大事なのではないかと。

「輪読会」に参加した人は実感していると思いますが、何が分からないか 分からない人は、質問さえできないわけです。自分が本当に理解できているか、 常に反省する習慣を身に付けたいものです。

ちなみに私は大学生の時、隣の理学部の数学科へ出かけていって、 なんとか理解しようとさんざん苦しんだ挙げ句、 どーしても「分かったつもり」レベルから脱することができずに 自身の理解力の限界を知る経験をしました。

いちおーその単位は取ったのですが、数学者になることはあきらめて 情報工学に専念しようと思ったのでした。

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

守秘義務

取引先が秘密保持契約(NDA)のもと開示した秘密や、お客様のデータや、経営情報などについては、あからさまに「秘密」という感じがするので、それが守秘義務の範囲に含まれることは誰の目にも明らかだろう。では、ノウハウはどうだろうか？

本当に件のノウハウなんか「しゃべるな」と言われたから（＝明確に秘するべき事と定義されたから）言わないだけで、別にそれを知ったからといってPerl のディストリビューションができるわけでも、俺もディストリビューションを作ってやろうと思わせるもんでもないし、マジで「コロンブスの卵」のノウハウ程度のもの。 (秘密にすべきことは明確にされるべき)

なにを「秘するべき事と定義」するかは各社の考え次第だから、私がとやかく言うことではないが、少なくとも弊社では、アイディア自体は秘密とは考えない。

ベンチャー起業の鉄則
アイデアなんて二束三文だ
(ベンチャー起業の秘訣！無料アイデア付き)

と社長自らが言っているし、 私も以前考案したDB サーバのセキュリティ向上策をはじめとして、 実地の運用ノウハウを公開していきたいと思っている。 「アイデアは人に話すことで熟成していく」 (ベンチャー起業の秘訣！無料アイデア付き)と考えるからだ。

そもそもノウハウは、アイディア自体にあるのではなく、 そのアイディアを具現化できる「人」にこそあるのだと思う。

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

マーケティングを学ぼう

先日、KLab のエンジニアの T さんが、 KLab 社内 ML でマーケティングの本を紹介しました。

今週のマーケティング本：「マーケティング / 恩蔵直人」
私がマーケティングを学んだときの師から紹介された本。 入門書として読むのも良いですが、網羅的かつ体系的に纏められており、 マーケ脳を整理・刺激するのにも適していると思います。 電車の中でも読みやすい文庫サイズ。

さっそく買って読んでみました。 網羅的に分かりやすく説明してあるので、 マーケティングを専門としない人にもいい本ですね。 そこで、私も推薦文を tech ML (KLab 技術者 ML) に書きました:

- o -

T さんオススメのマーケ本を買いました。 この本に書いてある事くらいは、 きちんと押えておくと、 技術者以外の人と話す時に役立つのではないかと思います。

つまり、技術者、企画者、マーケター、セールス、 会社ではいろんな人が業務を分担して仕事を進めるわけですが、 共通言語を持っていないと意思疎通がうまく いかなくて仕事がスムーズに進みませんよね？

で、共通言語というかバックグラウンドを少しでも共有するために、 お互いの分野の基礎的な部分くらいは、網羅的に押えておく事が重要ですね。

なので、技術者こそ、こういうマーケティングの基礎を網羅的に解説した本を 読むべきだと思います。 後ほど本棚に置いておきますので、是非読んで下さい。

# 真っ先に読みたい、という人は私が本棚に置く前に取りに来てね。

- o -

というメールを tech ML に流した直後、 KLabセキュリティの Windows プログラミングが得意な S さんが取りに来ました。 彼は日頃、マーケティングな人達から無理難題 ;) を押しつけられて 困っているので、 マーケティングの基礎を学ぶことはきっと役にたつことでしょう。

こういう本を読んで、 マーケティングとはそもそもどんなことなのか知っておかないと、 同じプロジェクトで一緒に働いているマーケ担当な人が、 マーケタとしてどのくらい優秀な人なのか、 あるいはダメな人か分かりませんよね？

同僚が優秀なマーケタなら、 その人の言う事を信じて開発方針を決めてかまわないのですが、 そうでないマーケタの場合は、 言う事を鵜呑みにするのは危険ですよね？ 信じる者は足をすくわれてしまうでしょう。 そういう場合は、鵜呑みにせずに、 他の人の意見を聞くなり、自分で考えるなりしなくてはなりません。

あるいは立場を逆にして考えてみると分かりやすいかも知れません。

例えば、技術の事が全く分からない人が、 技術者に開発を依頼をするとき、 その技術者がどのくらい優秀な人か分からないと、 その人が○週間で開発できる、 という言葉を信じていいのか良くないのか判断できませんよね？ できる、と言ったから信じたのに～、と言っても後の祭です。

だから技術者でない人も、 相手がどのくらい優秀な技術者か判断できる程度には、 技術の基本を網羅的に押えている必要がありますし、 その逆に、マーケティングの専門家でない人も、 相手がどのくらい優秀なマーケターか判断できる程度には、 マーケティングの基本を網羅的に押えている必要がある、 ってことだと思います。

Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 18:07
« Newer Posts