仙石浩明の日記

技術と経営

2006年7月12日

判断の理由 ~成功は失敗の元~

人は様々な判断をする。 経営上の決断だったり、 設計方針の決定だったり、 あるいはキャリアパスの選択だったりする。

あらゆる「判断」には、 その判断をするという「結果」をもたらした「原因」がある。 理詰めで行なった判断であれば、 どのような思考過程でそのような結論に至ったか、 明確にすることは比較的容易かも知れない。

しかし全ての思考過程が白日の下にさらされることは稀だろう。 理詰めの判断だと思っていても、 その一部が直感に頼っている場合もあるかもしれないし、 思い込みに捕らわれた論理の飛躍があるかもしれない。

直感といっても天から降ってくるはずはなく、 無意識の思考の結果だろう。 常にその思考の源泉があるはずである。 無意識の思考をかきわけ、 その直感がもたらされた真の原因を突き止めるべきだと思う。 無意識の思考をたどっていくうちに、 演繹の連鎖の中に、 思い込みや嗜好が関係していることがあるかもしれない。

もっとも危険なのは、 無意識のうちに過去の成功体験の事例を踏襲してしまっているケースだろう。 成功事例は、その前提条件が現在も成り立つときに限り有効であり、 前提条件を無視して無理矢理過去の事例を適用しようとすれば、 成功は失敗の元となる。

しかも、変化の早い現代においては、 以前の前提がそのまま成り立つことは、ほとんど有り得ない。 過去のやり方を真似ようとするときは、よりいっそう慎重にならなければならない。

過去と現在との条件の違いを明確にした上で、 過去の経験を活かすのであればよい。 過去の経験は資産になるだろう。

しかし、 無意識の思考で過去の経験を採用してしまうと、 本当にその前提条件が成り立つのか「意識」することなく 無意識に思考が進んでしまいかねない。 「判断」という結果を出すまでに、 その誤謬を正すことができるだろうか?

無意識の思考で発生した前提条件の齟齬が、 アラートとして意識に上ってくる場合もあるだろう。 上がってこない場合は、無意識の思考の過程を洗い出さなければならない。 無意識の思考は意識で想像するより深く入り組んでいる場合もある。 何が判断に影響を与えたのか、 常日頃から思考を遡って無意識の思考を監視する習慣が大切だろう。

その一つのきっかけとなりうるのが、 判断が結果的に間違っていたと思ったときに行なう反省、 すなわち「失敗から学ぶ」ことである。 失敗は、無意識の思考からアラートが上がってこない場合に、 外部から与えられるアラートである。

無意識の思考のアラートを次回こそは機能させるためにも、 失敗の原因をとことん追求すべきである。 ゆめゆめ失敗の原因を外部要因に転嫁して、 自己の思考を正当化してしまうことのないようにしたい。 そんなことをすれば、 追求が途中で頓挫してしまい、 失敗が次に活かされない。 「思い込み」が放置され、 無意識の思考に対する監視機能が働かないままになる。

そもそも言い訳など無意味である。 思考は全て自分のものであるのだから、 間違った思考の責任は全て自分にある。 自分自身に言い訳をして、 自分自身を欺くことの無いようにしたい。

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

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

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

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

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

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

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

Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 08:06
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月13日

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

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

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

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

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

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

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

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

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

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

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

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

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

IT企業には技術者と経営者の両方と話せるバイリンガルが必要

今日は昨日の続きで情報漏洩防止ネタを書こうと思っていたのですが、 トンデモない文章を見つけてしまったので、 急遽予定を変更...

この日記の副題にもあるように、 私は「プログラマ兼システム管理者」なのですが、 いちおー (^^;) 取締役でもあるので、 著名な経営者の方々のブログも読んでおります。 で、今朝起きて読んだ日記がコレ↓

渋谷ではたらく社長のblog」から引用:

本日の決算説明会。参加者からの質問・・・
「アメーバの進捗が遅れているボトルネックは何ですか?」

「スピードが遅れている理由はいくつか組織に存在しますが・・」
「一番は技術者の頭数が明らかに不足していることです」

うわっ、「頭数」なんて表現使ってる...

優秀な技術者であればあるほど、 「人月」という考え方には反発するものだし、 優秀な技術者は、 平凡な技術者の何倍、いや何十倍のパフォーマンスを発揮できる (私は技術者の生産性は、ピンとキリでは 3桁の違いがあると常々主張してるのですが) わけで、 「頭数」なんかで数えられたらたまらない、 というのが、優秀な技術者の感覚だと思います。

オソロシイことに、まだ続きがあって

さらってきてでも、拉致してきてでも・・・必ずや採用します。
それは冗談ですが、思いつく限りの採用強化策を考えています。

こういう冗談が口から出ること自体に違和感を感じてしまいます。
技術者をモノとしてしかとらえてないというか...

で、さらに続いて...

当社の技術陣の意見も参考に考えました。↓

・技術者のいるフロアをリニューアル。 空間デザイナーを入れて開発に集中できる環境に改善します。
・技術者のオフィス家具を総入れ替え。ひとり当たりのスペースをひろげます。
・最終面接では私もお会いして、今後の方針などを直接説明します。 (6月末まで)
・給与面を含む待遇面を見直し、優遇します。
・マッサージを入れます。

まあ、労働環境を改善して頂けるのは、 そこで働く技術者の方々にとっては望ましいことですが...

いろんな経営者の方々のお考えを見聞きするたびに、 経営者と技術者との間には、 深い深い溝があるなあ、という思いが深まりますが、 今日読んだこの「渋谷ではたらく社長のblog」には、 その断絶が極端な形で表現されているように思いましたので、 あえて引用させて頂きました。

この断絶はあまりに根本的なので、 経営者と技術者が互いに力を合わせることなぞ、 所詮不可能なのではないか、という絶望感に おそわれることもないわけではないのですが、 とは言っても、 「IT業界」で事業を推進し、かつ技術革新を進めていくには、 両者の協力が必要不可欠であることもまた事実です。

経営者と技術者が反発しあうのではなく協力するために、 技術者と経営者の双方と会話ができる「バイリンガル」こそ重要である、 という思いを新たにした今朝の事件でした。

Filed under: 技術と経営 — hiroaki_sengoku @ 08:21
2006年5月10日

PC からの情報漏洩を防ぐには?

昨日は、ノートPC が盗まれても VPN-Warp の relayagent をインストールしておけば、 そのノートPC がどこにあっても外部から操作して、 いろいろ (?) 対抗策を打てる、というお話をしました。

でも、これはあくまで「最後の手段」、 どうにもならないときの「自爆ボタン」という位置づけにしておいて、 できれば押さなくても済むようにしておきたいものです。

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

まず最初にやるべきことは、 ノートPC にどんな情報が入っているか把握することでしょう。

え? そんなの当たり前だって?

でも、みなさんは自分の PC の中にどんなファイルがあるか、 全て把握できていますか? 自宅で仕事をやろうと思って社外秘な機密文書をノートPC に入れて 持ち帰ったことはありませんか?

一時的にノートPC に仕事関連のファイルをコピーする、 などということはありがちで、 用が済み次第きちんと消せばまあいいんでしょうけど、 悲しいかな人間は忘れる動物です。 このファイルは取扱い注意と思っていても、 仕事が一段落して落ち着いた瞬間に忘れてしまい、以後そのまんま、 なんてことはよくあることなのではないでしょうか。

じゃ、定期的にノートPC の中の全ファイルを調べて、 不要になったファイルを消して、と...

ちょっと待ってください。 いまノートPC にどれだけ沢山のファイルがあります? 全てのファイルをリストアップするだけでも日が暮れてしまいませんか? おまけに、ファイル名からだけでは、どれだけクリティカルなファイルか、 分からないケースも多いですよね? 全てのファイルをいちいち開いて中身を確認するんでしょうか? ファイルを一つ一つ中身を確認するなんて単純作業は、 PC に任せてしまいところです。

解決すべき課題は二つあるように思われます。

各種フォーマットのファイルの中身をどうやって参照するか
PC の中には Word 文書あり、Excel ファイルあり、 その他さまざまなフォーマットの文書やデータがあって、 中身を参照するといっても一筋縄にはいきません。
中身が参照できたとして、 クリティカルなファイルか否かをどうやって判断するか
ある特定の単語を検索するだけなら方法はいくつかあります。 例えば Microsoft Office にも、 指定したディレクトリ内の文書全ての中から 特定の文字列を検索する機能があります。 しかし、「クリティカル」なファイルというのは、 単にある文字列があるか無いかで判断できるようなものではないですね。

続きは次回に...

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

面接FAQ: 「人の役に立つことをしたい」と言う技術者の卵たち

これまで 「弊社の面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法」を、 「面接 FAQ」シリーズで書いてきたのですが、 タイトルでは内容が分かりにくかったのではないかと反省する今日このごろなので、 今回から より内容を表わすタイトルに変えてみます (2007/7/12追記: 以前のページのタイトルも修正しました)。

内容自体は、「面接 FAQ」シリーズの続き物ですので、 以下のページも参照して頂けると幸いです。

(1) 高い技術力って例えばどんなことですか?
(2) 何か質問はありませんか?
(3) 前職でいくらもらっていましたか?
(4) 仮に、何をしてもいい、と言われたら、何をしますか?

続く 5 回目となる今回は前回の続きで、 「何をしたいか」と質問したときの、 応募者 (つまり面接を受けに来た人) の答についてです。

一生の時間のうちのかなりの時間を仕事に費やすのですから、 一生かけて取り組みたいと思うようなことをすべきだと私は思います。 嫌々仕事をしたって、好きでやってる人に勝てるはずはありません。 転職 (新卒の学生さんにとっては就職) を成功させる第一歩は、 自分が本当は何をやりたいか自覚することから始まるのだと思います。 だからこそ、私は面接で「何をしたいか」をしつこいくらい聞くのですが...

私にとっては意外なことに、 「人の役に立つことをしたい」 と
答える人が少なからずいます。

もちろん、「人の役に立つこと」という目的は崇高なものです。 NHK の番組「プロジェクトX」を引き合いに出すまでもなく、 人のために自らを投げうって技術革新に取り組む技術者たちの姿は 人の心を打つことでしょう。

でもそれって、平たく言えば、 技術者でない人 (視聴者) に技術者の人生が分かったような気にさせるための、 技術者でない人 (番組制作者) が考えたストーリーに他ならないわけです。 つまり、技術者の(技術者を描いた)、非技術者による、非技術者のための番組なわけで、 これから技術者としてスキルアップしていこうとする人が、 そんなマスコミの「嘘」を信じちゃいけません。

13歳のハローワーク 公式サイト では、 「人の役に立つのが好き」な人に勧める職業として、

  • 政治家, 公務員 などの行政職
  • 弁護士, 裁判官 などの司法職
  • 保育士, 小中学校教師 などの教育職
  • 警察官, レスキュー隊員 などの安全に関する職種
  • ソーシャルワーカー, ホームヘルパー などの福祉関係の職種

があげられています。 「人の役に立つ」のを第一の目標とするなら、 まず技術を身につけて、その技術で人の役に立つ、なんて 回りくどいことをせずに、 もっとストレートにこういった職業を目指すべきでしょう。 技術を身につける、なんてサブ・ゴール (sub goal) を設定していては、 ゴールを目指す前に人生終わっちゃいます。

「技術」をあくまで目的を達成するための一手段としてとらえるのなら、 自分で技術を習得するなんて遠回りをするより、 技術者を雇うなりアウトソースするなりして技術面は他の人に任せ、 自分は自分の目標に邁進すべきなのです。 「技術」と「人の役に立つこと」両方を追い求めるには人生は短すぎます。

技術者としての人生を歩もうとするなら、 まず自分がどれだけ技術が好きか、 とことん自分の気持ちを確認してみるべきだ、 と私は思います。

- o -

連休初日に、 「今日から五月連休ですね。会社によっては 9 連休のところもあるとか。あなたは何をしますか?」という問いかけをしました。 連休最終日の今日、連休を振り返ってみていかがでしょうか? 好きなことができましたか?

Filed under: 元CTO の日記,技術と経営,自己啓発 — hiroaki_sengoku @ 09:27
2006年5月4日

プログラマ 35歳 定年説

「プログラマ 35歳 定年説」、みなさんも一度は 聞いたことがあるのではないかと思います。 35歳ぐらいになったらプログラミングなんて仕事は若い人に譲って、 マネジメントをやりなさい、 という趣旨ですね。

その理由として、体力的な面だとか、 歳をとってくると新技術を覚えられないとかが、 あげられるようです。 実際、多くの企業でプログラミングは新人ないし外注の人 (最近はオフショアも増えてきました) の仕事とされ、 中堅社員はマネジメントや上流行程を担当することが多いようです。

そして、この定年説に真っ向から異を唱える主張が、 ここ 10年くらいずーっと続いています。 よくもまあ、こんなに長い間、 アンチ定年説が唱え続けられるものだと感心してしまいますが、 やはりこれは定年説に異を唱える人が多いにもかかわらず、 世間一般では 35歳を越えるあたりで、プログラマ人口が減るからなのでしょう。 寄る年波には勝てず、とか上司の強い勧め、とかで 泣く泣く (?) プログラミングの現場から離れる人が多いのでしょう。

というわけで、よくあるアンチ定年説を今さら唱えても仕方がないので、 ここでは逆に、あえて肯定してみることにします。

高度な知的労働は、歳をとってもできる傾向があるようです。 長年の経験が役に立つから、 老化する部分を補える というわけですね。 医師や弁護士、芸術家に音楽家、棋士や料理人などなど。 この伝でいけば、プログラマも仲間に入れてもらえそうな感じがしますし、 実際 35歳を越えても若い人を圧倒するパフォーマンスで コーディングしている人も大勢います。 だからこそ「プログラマ 35歳 定年説」は間違いだ、 と声高々にみなさん主張されるのでしょう。

しかし、もし他の「高度な知的労働」においても「定年」が存在したとしたら?
プログラマにも定年があってもおかしくはないのではないでしょうか?

そんなバカな。外科医とかだと手元が狂うと危ないから、 自主的な引退はあるかも知れないけれど、 弁護士や芸術家に定年があるなんて聞いたことがないぞ。

確かにその通りなのですが、 医師や弁護士は国家試験に合格しなければなることができません。 国家試験に合格できずに医師や弁護士になるのをあきらめる人も沢山います。 将棋の棋士はもっと厳しくて、23歳までに初段になれないと 奨励会を退会しなければなりません。 芸術家や料理人は、腕を認められなければ食べるのにも困ってしまうかも知れません。

それが何か? 定年のあるなしと関係あるの?

いえ、ですからプログラマの 35歳というのは、 医師や弁護士にとっての国家試験であり、 奨励会の棋士にとっての 23歳であり、 芸術家や料理人にとっては、師匠に認められるか否か、 ということなのではないでしょうか? つまり、他の「高度な知的労働」の職種では、 定年うんぬん以前に、そもそもその職業につくこと自体に壁があります。 どんなにその職業に従事したいと思っても、 国家試験に合格できなかったり、 初段になれなかったり、 師匠に認められて弟子にしてもらえなかったりすれば、 35歳よりもっと早い段階でその道をあきらめることが多いのではないでしょうか。

確かにプログラマってのは、ピンからキリまでいて、 キリのほうは際限がないなぁ。 本当は 35歳といわず、もっと早い段階でプログラマには向いてないことを 自覚したほうが幸せなのではないか、と思うような人もいるよなぁ。

ですよね? こういっちゃミもフタもないんですが、 いくらプログラミングの才能がない人でも、 体力さえあればそれなりに役にたっちゃうことも多いんですよね。 ぶっちゃけ、レベルが低いプログラムでもいいなら、 プログラミング言語の文法を一通り知ってさえいれば誰でも書けちゃいますし、 デバッグ環境さえ整っていれば、デバッグもなんとかなる。 もちろん時間は優秀なプログラマの何倍、何十倍もかかりますけどね。 そもそもこの業界、慢性的な人手不足ですから、 猫の手でもいいから借りたい。 何十倍も仕事が遅くてもいいから手を借りたい。 ただ、あくまで「猫」なんで、デスマーチに耐えられる体力はないと困る。

なるほど。そういえば「アンチ・プログラマ35歳定年説」を唱える人って、 優秀なプログラマが多いような気がする。 優秀ならばパフォーマンスは体力とは関係ないから、 35歳なんて関係ないと言い切れる。 そもそもプログラマに向いている人と、まるで向いてない人が、 いっしょくたに「プログラマ」と呼ばれているのが問題なのか。

そういうことなんだと思います。 プログラマに向いているか向いていないか判断できない人が、 プログラマの上司をやってる、 というのも一因でしょうね。 医師, 弁護士, 棋士などには、足切りのための絶対的な評価基準がありますし、 芸術家や料理人などには、師匠がいて、能力の有無をきちんと判断してくれる。 プログラマだけが基準なしに、ただ若いというだけで、 いっぱしのプログラマ気取りになってしまう。 師匠がいれば、「プログラマを気取るのは百万年早い!」って 怒鳴ってくれるんでしょうけどね。

まとめると、 プログラマには少なくとも二種類あって、 他の「高度な知的労働」の職種と同様に定年がない「優秀なプログラマ」と、 若いだけが取りえの「見習いプログラマ」とを、 きちんと区別する必要があると。 で、「見習いプログラマ」は 35歳といわず、もっと早い段階で、 プログラミングに向いてないことを自覚し、 もっと自分に向いている仕事を見つけるべきだ、ということですね。

そして「優秀なプログラマ」には、 きちんとその能力を評価し、育てていく環境を整えるべきでしょう。 私の感覚では、本当にプログラミングに向いている人って、 20人に一人くらいしかいないように思えるんですよ。 だからこそ、そういう希有な人材には最高の環境を提供してあげたい、と思います。

Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 17:06
2006年5月3日

勝ち組になるには

先月 4/14 19:30 NHK で、特報首都圏「就職戦線異状あり・格差社会の不安」と 題する番組があった。 新卒の学生さん達が「勝ち組になる」ことを目指して 就職活動を行なっているのだという。

そりゃ、勝てるものなら勝ちたいと思うのは人の常なので、 これから社会に出ていこうとする学生さん達が、 将来勝ち組になれるような就職先を選ぼうとするのは至極当然のことだと思う。

ところが

学生さん達曰く、「勝ち組になるため、儲かっている会社に就職したい」。

オイ、それは根本的に間違ってるぞ、と言いたくなる。 儲かっている会社、それはお金を産み出す仕掛けが確立している会社である。 つまりできるだけ属人性を排した、回り続ける仕掛けが確立している会社である。 このような会社が新卒採用を行なうのは、 仕掛けを維持するために「歯車」の補充を行なうためである。

すでに出来上がっている仕掛けは、それが陳腐化するまでは、動き続けるだろう。 動き続けるには若い人を採用し育てることが必須だから、 そういうことまでも含んだ仕掛けである。 このような仕掛けに参加すれば、 仕掛けの中で活躍できるレベルまで育ててもらえるし、 仕掛けが動き続ける限りは安泰である。

しかしそれは「勝ち組」ではない。 勝ち組なのは、放っておいても回り続けるその仕掛けを作り上げた人であって、 いったん仕掛けが回りはじめたとき、 その人はその仕掛けの中にはいないはずである。 それが「属人性を排する」という意味である。 「属人性を排する」すなわち「置き換え可能」な人材で 仕掛けを回すことであり、 置き換え可能な人材は「勝ち組」では有り得ない。

したがって、勝ち組になるには、 出来上がって回りはじめた仕掛けに歯車として参加するのではなく、 そういう仕掛けが無いところに参加し、 仕掛けを作る側にまわらなければならない。

もちろんどうやって仕掛けを作るべきか最初は分からないだろう。 当然、失敗することもある。 しかしそうやって無から有を作り出す経験を積んだ人材は決して、 置き換え可能ではない。 仕掛けを作り上げようと悪戦苦闘する組織は、属人性のカタマリである。 将来の勝ち組になるには、 そういった組織の中に身を置かねばならない。

More...
Filed under: 技術と経営 — hiroaki_sengoku @ 07:52
2006年5月2日

健全なニート

人は働かねばならない、と誰が決めたんだろう?
働かなくても生活できるなら、働く必要はないわけで、
ただ単に、勤労は国民の義務だ、なんて言っても意味がない。

[技術]Agdaの紹介Flashから引用:

定理証明ツールが動いているところ、生まれて初めて見た。感動。自分もつかってみたいが、ドカタSEなのでそれよりやらないといけないことがあるのが悲しいところ。資産が50億ぐらいあったらニートになって毎日こんなことばっかりしたいな。これ、俺の夢(←駄目人間)。

50億もなくても生活できると思うが、 まったくお金を稼がずに生活しようと思うと、 数億は必要だと思われるので、 なかなか簡単ではない。

しかしながら、 技術者の生産性には人によって 3桁の差があるわけで、 並みの技術者の数倍の生産性がある人なら 大勢いるだろう。 そういう人たちにたとえば一日3~4時間だけ 会社の利益に直結することをしてもらって、 一日の大半の時間は好きなことをやってもらう。 もともと生産性が高い人なら、3~4時間の労働だけでも、 生活に困らないくらいの給料を出すことができる。

ほとんどの時間、 引きこもって好きなことをしているように見えるわけで、 まあニートみたいに見えるかもしれないが、 向いてない仕事を嫌々やるより、 好きなことをとことん突き詰めるほうが、 よほど健全だと思うし、 実は社会への貢献度合いも高くなる可能性が高い と思うのだが、どうだろうか。

Filed under: 技術と経営 — hiroaki_sengoku @ 12:08
2006年4月27日

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

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

多くの企業同様、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月23日

実力主義・能力主義

創業から 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月20日

面接FAQ: 高い技術力って例えばどんなことですか?

2000年に (株)ケイ・ラボラトリー (KLab の当時の社名) を創業してから 6 年、 当然ながら数限りなく採用面接を行ないました。 最近でこそ私の面接なしで採用された人達も増えてきたのですが、 一時は技術部門のほぼ全員が私の面接を経て入社した という人達だった時期もあります。

最終の役員面接というと、多くの人が通りいっぺんの面接だと思うらしく、 役員面接で技術的な突っ込みを受けて、応募者が戸惑うケースが多々ありました。 私としては、応募者に合わせてその都度、どういう面接方法が適しているか考えて、 質問する内容を変えてはいるのですが、 そうはいっても 100人以上も面接すればある程度パターンのようなものもでてきます。

比較的頻度が高い質問パターンを紹介し、 どう答えることができていたら採用になっていたか、 振り返ってみようと思います。 名付けて「面接FAQ」、面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法。

- o -

KLab にあまり興味を持っていなかったけど (転職斡旋エージェントに勧められて) とりあえず面接を受けに来ました、 という応募者に、 なんとか KLab の魅力を伝えて、入社しようという気にさせるのが 面接官の腕の見せどころだと思うのですが、 それでもやっぱり面接での話の成り行き上、 志望動機について質問することはよくあります。

すると、「KLab の高い技術力が魅力的」、とか 「そういう高い技術を学び、身につけたい」、とかおっしゃるかたが 少なからずいます。 そういうことを言われてしまうと、 私はつい (^^;)、 「高い技術力って例えばどんなことですか?」と 聞いてしまうのです。 意地悪な質問ですね (_O_)。

多くの方は、そういう質問が返ってくるとは全く予期していなかったらしく、 ここで言葉に詰まってしまいます。 志望動機が「技術を学びたい」なのに、 肝心のその技術がどういうものかイメージできていないのです。 言い換えれば自分が何をしたいのか実は分かっていない、 これはかなり問題ですよね?

技術ってなんだろう…」 ふとそんなことを考えたことが一度でもあるような人ならば、 「技術を学びたい」なんて抽象的な言い方ではなく、 もっと具体的なことが言えると思うのです。 そして自分が何をしたいか、きちんとイメージできている人は、 KLab に入社したあと、ほぼ例外無く大活躍しています。

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

情報処理のキホン (2)

KLab の開発に参加いただいている協力会社の A 社の S 社長が、 tech ML に投げた問いかけに対し、 同じく協力会社の H 社の役員である K さんが応えました。

# KLab 社内の ML なのに、KLab 社員以外で話が盛り上がる
# こともあるのが、tech ML の大きな特長です (^^;)。

~~ Kさんのメール(一部抜粋)ここから ~~

> #どなたが「専門教育」を受けられた方なのかわかりませんが^^;
> ##ぜひ土日で古い教科書などを掘り出していただきたく:-)

今でもコンピュータでの処理(方法の)限界に関してはとても興味があり

オートマトンと計算可能性 情報処理シリーズ
有川 節夫 (著), 宮野 悟 (著)

あたりはおもしろいかなと。私は特に後半の計算可能性が好きです。

~~ Kさんのメール(一部抜粋)ここまで ~~

で、私も話に加わってみました:

~~ 私のメールここから ~~

仙石です。おお、ついに tech ML で計算可能性の話題が...

K さん曰く:

> 「オートマトンと計算可能性」

このあたりの、一通り学べる本を読んでみると、 大学の専門課程で何をやってるのか知る事は、できそうですね。

# でも、知る事と理解する事は全く別物 ;-)

> あたりはおもしろいかなと。私は特に後半の計算可能性が好きです。

本当に重要なのは、この「おもしろい」という感覚かもしれませんねぇ...
計算可能性に関する「おもしろい」本としては、

決定不能の論理パズル―ゲーデルの定理と様相論理
レイモンド スマリヤン (著), 長尾 確 (翻訳), 田中 朋之 (翻訳)

あたりがおすすめ。いきなりこの本を読むと挫折するかも知れない ;) ので、
入門用としてはホフスタッターの不朽の名作:

ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版
ダグラス・R. ホフスタッター (著), Douglas R. Hofstadter (原著),
野崎 昭弘 (翻訳), 柳瀬 尚紀 (翻訳), はやし はじめ (翻訳)

があまりにも有名ですね。

# 20周年記念版が出たのか~
# ということはつまり、私が初めてこの本を読んでから 20年たった、という
# ことなのですね。う~ん歳をとったものだ...

Filed under: 技術と経営 — hiroaki_sengoku @ 19:27
« Newer PostsOlder Posts »