仙石浩明の日記

元CTO の日記

2007年1月17日

技術者を目指す学生さんたちへ

いよいよ就職活動本番ですね。 どのような進路を選ぶにせよ、 あとで後悔することのないよう、 じっくり考えて決めたいものですよね。 でも、ただ単に考えると言っても、 一人であれこれ思い悩むのは感心しません。 「思いて学ばざれば則ち殆し」と言いますから、 ぜひいろいろ見聞きした上で考えて頂きたいと思います。

企業への就職を考える場合、まず気になるのは評価制度のことだと思いますが、 まさにこの評価制度が揺れ動いているのが、いま現在と言えるでしょう。 高度成長期以来、長年用いられてきた年功主義に基づく評価制度の綻びが 誰の目にも明らかになってきてはいるものの、 年功に代わる評価方法を模索し続けているのが 多くの企業の現状だと思います。

どこの企業も新しい人事制度を模索し、成果主義が取り入れられつつありますよね。 (同時にコスト削減という意味合いもありますが)
この成果主義という人事制度ですが、 多分どこの会社でもおおよそこんな感じなのではないでしょうか。
●年初に目標を設定(部署ごとの目標・個人の目標)
●3ヶ月か半年ごとに上司と面談
●成果をアピール
●評価の通知
一見、単なる年功序列よりは凄くまともそうなシステムに見えますよね。 でも、実際には明らかな欠点があると思います。 (評価する側の上司がそもそも年功序列組だという点は除いて)
◆短期間にアピールできるようなものにばかり心奪われるようになる
◆業績アピールに繋がらない日常の雑用や、他人の手伝いは避けるようになる
どちらも当たり前の弊害だと思うのですが、 多くの企業ではこれらの問題について見て見ぬフリをしているのではないでしょうか?

ぜひこういった疑問を、どんどん企業にぶつけていって頂きたいと思います。 就職活動というのは、いろんな企業に対して歯に衣着せぬ質問ができる 唯一と言ってもいい機会なのですから。

「評価」には二つの側面があります。 「評価される側」と「評価する側」です。 上に引用した文章は、 「評価される側」にフォーカスした疑問と言えるでしょう。 もちろん学生さんは就職したら評価される側になるので、 「評価される側」から考えたくなるのは当然だと思いますが、 なにごとにも表と裏があります。 片方の側からだけ考えていては考えを深めることはできません。 ぜひ、自分とは異なる立場の視点も持つ習慣を身につけて頂きたいと思います。

「評価」を両方の側から考えてみれば、 「短期間にアピールできるようなものにばかり心奪われるようになる」というのは 評価される側の理屈に過ぎないことは自明ですよね? つまり暗黙のうちに、 アピールがそのまま通るような「無能な上司」を前提としてしまっています。 もし、「評価する側」が 「業績アピールに繋がらない日常の雑用や、他人の手伝いは避ける」人の 評価を下げるのであれば、 このような弊害を避けることは可能でしょう。

引用した文中に「評価する側の上司がそもそも年功序列組だという点は除いて」と ありますが、 まさにこれこそが問題の本質だと思います。 「除いて」しまっていては考えが深まりません。

どのような人事制度であれ、 「評価する人」と「評価される人」の双方に、 その制度の「精神」が徹底できていなければ機能するはずがありません。 そして、 「評価される人」への徹底は、 そもそも徹底できていなければ評価が下がるので、 否が応にも徹底されるわけですが、 「評価する人」への徹底ができるかどうかは、 「評価する人」を評価する人、つまりその上の上司の責任です。

より具体的に言えば、 「短期間にアピールできるようなもの」「アピールしやすいもの」 ばかりを評価の対象としてしまって、 部下の本当の価値を評価できていない上司を、本当に降格できるのか? という問題でしょう。 年功主義では過去の功労者が上司となるケースが多いようですが、 過去に成果を上げた人が、 現在の部下の成果を評価できるのか? という問題であるとも言えますね。

製品には、どうしても長期的な投資が必要なものがあると思います。
例えば日亜化学の青色LEDだって、中村氏が個人で何年もかけて、 会社の中止命令を無視してやり遂げたと著書にありましたし。
もし青色LED開発中に、 3ヶ月ごとに面談していたらどんな評価がされるんでしょう?
失敗続きで亀のようにのろく、先が見えない実験の繰り返しでしょうから、 それらの失敗が将来大きなリターンになって返って来ることを 強く確信している人でなければ、続けられませんよね。
同ページ」から続けて引用

「技術者の成果」とは何でしょう?

技術者が作ったものから得られる売上でしょうか? もちろん、それだけではないですよね? 「青色LED」のように最終的に莫大な利益を生み出したものは、 とても分かりやすい「成果」ですが、 サーバシステムの運用などのような縁の下の力持ちの仕事だって 立派な成果ですし、 さらに、 自分自身では何も生み出さなくても、 社内の技術者を育てることや、 社内の技術をブログなどで発表して会社の知名度を上げることなども、 立派な成果と言えるでしょう。

したがって「3ヶ月ごとの面談」という制度が問題なのではなく、 きちんと技術者を評価できない上司をそのままにしておくのが問題なのです。 そしてそういう上司をそのままにしている上司の上司も問題ですし、 そのまた上の上司の上司の上司にも責任があります。

こうやって責任の連鎖を上へ上へ登っていくと、 技術者の評価制度が機能するか否かは、 技術者の評価について最終的な責任を負う人がいるのか? という点に行き着くことになります。

技術者を目指す学生のみなさんには、 ぜひこの点 ──この会社では誰が技術者の評価の最終責任を負っているのか?── を押えた就職活動をするようお勧めします。 そしてできれば、「誰が責任者か」だけでなく、 その責任者がどんな考えを持っているのか調べられるものは全て調べ、 さらに疑問点があれば直接会ってでも質問するくらいの勢いで 臨んで欲しいと思います。

KLab株式会社 取締役
兼 最高技術責任者
仙石浩明
Filed under: 元CTO の日記,技術と経営,技術者の成長 — hiroaki_sengoku @ 07:49
2006年12月14日

年功主義と実力主義 ~大企業とベンチャー~

私が大学を卒業したのはバブル (ネットバブルではなく、その前の前世紀のほう) がはじけた年でした。 当時は今ほどベンチャーは一般的ではありませんでしたし、 研究職を目指していた学生 (含む私) が就職先として大企業の研究所を選ぶのは、 ごく普通のことだったのではないかと思います。 終身雇用を信じていたわけでもありませんでしたが、 かといって自分自身が転職することになろうとは、 あまり考えてもいなかったような時代です。 今から振り返ってみれば「就職」というよりは「就社」という感覚に 近かったのだと思います。

その後の「失われた十年 (20年?)」の間に、 年功主義の綻びが誰の目にも明らかになってきて、 大企業以外の就職先を選ぶ人も増えてきましたし、 転職も一般的になってきました。 とはいえ、 就職先の選択肢が広がってきているわりには、 それぞれの企業がどんなところか実態を知ること無く、 なんとなくイメージで決めてしまっている学生さんも多いのではないでしょうか。 最近になって再び「寄らば大樹」的な傾向が復活しつつあるとも聞きます。

どのような進路を選ぶにせよ、 もっと企業の実態を知ってもらった上で決めて欲しいと 思っていたところ、 先日たまたまそういう機会を頂けたので、 学生さん相手のセミナーでお話ししてきました。

私は大企業の研究所に 8年間勤め、 その後ベンチャー (KLab(株), 当時の社名は (株)ケイ・ラボラトリー) の 立ち上げに参加し、順調に規模を拡大し、現在に至っています。 なので、

  • 大企業の研究所 (前職)
  • スタートアップ (立ち上げ当初のケイ・ラボラトリー)
  • 中規模ベンチャー (現在の KLab)

それぞれについて、実地の体験談をお話したわけです。 幸い、ベンチャーについて、もともと興味を持っていた学生さんもいて、 核心をついた (答えにくいとも言う ^^;) 質問もありました。 大企業とベンチャー、 それぞれの実態について理解を深めてもらえたと思っています。

まじめな東大生、悩みすぎ? 3割がニート不安

よく勉強する半面、将来の進路などに思い悩み、 不安や無気力に苦しむ学生が増えている-。 東大が13日公表した学生生活実態調査で、 こんな東大生の姿が浮かび上がった。
調査は昨秋、学部生約3500人を対象に実施(回収率39%)。 83%の学生が進路や生き方に悩んでおり、 自分がニートやフリーターになる恐れがあると感じている学生も28%に上った。
今朝のSankei WEBから引用

悩んでいるより、まずはいろいろな企業の実態について 見聞きしてみて、じっくり将来のことを考えて欲しいと思います。 私でよければ喜んでお話ししますので、 興味あるかたは是非ご連絡下さい。 ただし、企業の実態をできるだけ正確にお話しする、という主旨なので、 対象は (研究者・技術者を目指す) 学生さんに限定させて頂きたいと思います。

参考までに、セミナーで使ったスライドを FlashPaper で Flash 化したもの ↓ を公開します。 このスライド自体は 10ページしかありませんが、 それは「実態」は口頭でお話ししているからです ;-p。 質疑応答が盛り上がったので、2時間近くかかりました。

もっと読む...
Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 16:48
2006年12月8日

なぜ人月見積もりが優れているのか

人月見積りでは生産性が上がらない。 IPA が警告するまでもなく、 ソフトウェア技術者ならば誰しも 人月見積りに嫌悪感を持っているのではないでしょうか。 生産性を上げれば上げるほど金額が低くなってしまうし、 そもそも開発者の生産性なんて人によって大きく異なる (私の持論は、 「ピンとキリでは 1000倍の差がある」、です) のだから、 「標準的な技術者一人が一ヶ月かかる仕事」なんて基準をおいたところで 意味がありません。

人月見積もりについては、 「人月見積もり、生産性について」に いろいろな意見へのリンクがまとめられているので参考になります。 このように人月見積もりがなぜ問題なのか、 それこそ掃いて捨てるほど主張が繰り返されていますから、 いまさら同じようなことを唱えても仕方がありません。 そこで、ここでは逆にあえて肯定してみることにします。

そもそもこれだけ嫌われ者の「人月見積もり」が なぜいまだに行なわれているか、 そこには「人月見積もり」ならではの「良さ」があるからではないでしょうか?

誰にとっての「良さ」か? それはもちろん見積書を受取る「お客様」にとっての 良さです。 そもそも技術者の仕事なんてのは、 技術のことを知らない「お客様」にとってはよくわかりません。 「この仕事はすごく高度なんだぞーっ」って言われたって、 「ハイそうですか、じゃ沢山お金を払いますね」なんて言ってくれるお客様が いたらぜひお目にかかりたいものです。 ふつうは「どれだけ価値がある仕事なのか、きちんと説明してもらいたい」って 言うでしょう。

じゃ、どうやって説明しましょうか、技術者の仕事の価値を。

お客様にどう説明すれば納得してもらえるか考えるには、 お客様の立場に立つのが一番分かりやすいでしょう。 といっても、我々技術者にとっては、技術者でない人の気持ちを想像するのは ちょっと難しいですよね? こういうときの常套手段として、立場を逆にして考えてみます。 つまり我々技術者がお客で、 技術者でない相手が何かを我々に売りつけようと見積書を出している 状況を想像します。 売り付けるモノは (コモディティでなければ) 何でもいいんですが、 例えば何かの調査レポートにしましょうか。

相手は、このレポートがいかに創造的で革新的で価値があるものであるか、 必死に説明しようとしています。 が、残念ながら我々はその分野には全く疎いので、 どれだけ価値があるのやら、いまいちピンときません。 そもそも疎いからこそレポートを買おうとしているわけで、 ピンと来ないのは当たり前ですよね? さあ、どうしましょう?

そのレポートを活用することによって我々の利益がどのくらい増えるのか、 目に見えるのであれば分かりやすいのですが、 あいにくそのレポートが即、利益につながるわけではありません。 確かにそのレポートが役に立つであろうことは間違いない (だから買おうとしている) のですが、 利益増にどのくらい貢献しそうか、というと主観的に判断せざるを得ません。 でもって、主観ということになると、 どうしても他社の仕事より自社の仕事の 利益貢献度合いのほうを高く見積りたくなるものでしょう。

- o -

御社のレポートが、弊社のビジネスに大変役立つであろうことは 疑いの余地がないのですが、 もちろんレポートが直接利益を生むわけではなく、 弊社としてもいろいろコストをかけていく必要があるわけでして、 御社がこのレポート作成に多大なコストをかける必要があることは 重々承知しているのですが、 最終的な利益を御社と弊社とでどう配分すべきか、というと なかなか難しいものですね~ なにかもっとこう客観的な指標はないでしょうか。

と、いいますと?

例えば、このレポート作成に、何人の人が何ヵ月くらいかかりそうか、とか。

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

チープ教育: 「無意味にポジティブ」のススメ

KLab 社内には、社内専用の IRC サーバがあります。 IRC (Internet Relay Chat) つまり、 ネットワークリアルタイム会議システムです。 普通の IRC はインターネットに接続できれば、 誰でも使えるのですが、 KLab 社内 IRC は、KLab のイントラネットに接続できる人しか使えません (VPNワープを使って社外からもアクセスできます)。 だから社外秘な内容も流せますし、 社内ミーティングを IRC で済ませてしまうこともよくあります。

社内 IRC が真価を発揮するのは、 コンテンツ提供用の WWW サーバ システム (DSAS) の メンテナンス作業の時など、 多くの人がリアルタイムに状況 (メンテナンス作業の進捗状況) を 共有したいときです。 メンテナンス作業は、 コンテンツ提供サービスに悪影響を与えていないか確認しつつ 慎重に進める必要があるのですが、 それには実作業を行なう人と、 その作業をチェックする人、 そしてコンテンツ提供に悪影響が及んでいないか監視する人など、 沢山の人が進捗状況をリアルタイムに把握する必要があります。

関係者が全員同じフロアにいれば、 大声をあげるだけでも進行状況の「雰囲気」を共有できるでしょうが、 KLab の場合は東京、大阪、福岡のオフィスの他、 SOHO 形態で働いている人もいますし、 DSAS メンテナンスの場合はデータセンタ (東京二ヶ所と九州一ヶ所) にいる人とも 連係しなければなりません。 遠隔地の人と手軽に「雰囲気」を共有する手段として、 社内 IRC はとても便利です。

あまりに便利なので、 技術者の大半が常時 IRC サーバに「常駐」しているのですが、 こうなってくると計画的な作業の連絡用だけでなく、 技術者全員の横のつながりというか、 部署を超えて技術者同士が連係できる共有空間の役割を果たすようになります。 例えば昨晩も...

18:28 (sengoku`) チープ教育 http://cn.ce-lab.net/ja/toshi/archives/2006/08/post_75.html
18:29 (sengoku`) ↑これ、かなり本質をついてる気がするのですが、皆さんはどう思いますか?
18:30 (sengoku`) 私がはじめて出会った PC (当時の呼称はマイコン) は、とてもチープだったんで、自分で作ろう、という気が起きたけど、今の PC 見て、作ってみよう、と思う人はいないよねぇ..

チープ教育」を読んで、 ぜひみんなに紹介したいと思ったので、 とりあえず社内 IRC に投げてみたわけです。 ほどなく隣の部署の人から反応がありました。

18:34 (koura-h) 細部の作り込みに入ってしまうのって、それはそれで楽しいときもありますけど、苦痛になってしまうことも多いっす。。。
18:35 (koura-h) 制作環境における「チープさ」って、ありがたいと思うす。

続いて、協力会社の人からも...

18:39 (ktaka) ある意味、何でもそうだと
18:39 (ktaka) 思います。
18:40 (ktaka) 自動車でも、
18:40 (ktaka) 楽天のような商売でも
18:41 (ktaka) 物理学者が生物学に入っていって、DNAとかの研究が盛んになり始めた衣
18:41 (ktaka) 頃も
18:42 (ktaka) ショックレイがフェアチャイルド社(?)を始め、Intelができた頃も
18:42 (sengoku`) あはは
18:42 (ktaka) みんな始めは、
18:42 (ktaka) ある意味、やればできそうという感覚があったんでしょうね
18:43 (sengoku`) ですよね~
18:43 (sengoku`) 「へぼくても許される感」って重要ですね~

反応してない人も、この会話の流れを見てはいるわけで、 技術者同士、考え方を共有することはとても重要なことだと思います。 もちろん社内には情報共有の方法としてメーリングリストも多数あるのですが、 なんでも気楽に書込めるという敷居の低さで、 IRC のほうが勝っていると思います。

18:43 (uchikawa-) itronのコードでも弄ってみますか(秋月のボードで自力で動かすというのはやったことあります)
18:43 (sengoku`) 逆に言うと、へぼが許されないような雰囲気のとき、どうやって「無意味なポジティブさ」を学ぶか意識しないと、ってことですね。
18:44 (sengoku`) まあ、遠慮せずにどんどんやれ、ってことなんですけど、
18:44 (ktaka) 私は、そもそも、参入しないと言うのもありかな、と思っています
18:44 (sengoku`) なかなかポジティブになったことの無い人にそれをやれ、ってのは難しいのかもしれませんね。
18:45 (sengoku`) もちろん、参入しない、という選択肢があるときはそれでもいいんですが、
18:45 (ktaka) 高度に専門家されたことを大きな組織でやるよりも、
18:45 (sengoku`) コンピュータ技術者、って道を選択してしまった人に、いまさら他の道を探せ、ってのも酷でしょうから... ;-)
18:46 (ktaka) 一時代を築く可能性がある、チープなものに出会えれば。。。
18:46 (ktaka) でも
18:46 (ktaka) 一口にコンピューター技術者といっても、いろいろあって
18:47 (ktaka) 昔は、ボードの設計からできそう、だったのが、
18:48 (sengoku`) (いまでも、ちゃちな PC ならボードから設計できるんですけどね、実は)
18:48 (ktaka) 今は、Youtube見たいなの作れそう、っていうのがあるとおもいますので
18:49 (ktaka) おお、すごいですね~
18:49 (sengoku`) ようは、ポジティブになれるかどうかが、勝負を分けることになるんじゃないかと...
18:49 (ktaka) チープなフェーズにある、面白そうなものって言うのは、いろんなところにあるんではないかと
18:49 (sengoku`) まあ、そういう話は、
18:50 (katsumiD) ( つhttp://journal.mycom.co.jp/column/architecture/037/
18:50 (sengoku`) プログラマを目指すのに適した時代、適していない時代 http://www.gcd.org/blog/2006/07/83/ ってことに
18:50 (sengoku`) 続くのかな。
18:50 (katsumiD) ちなみに,
18:51 (katsumiD) 今だと CPU を作ろうと思った場合,FPGA とかで作れますが
18:51 (katsumiD) そういうことをしようと思った場合のハードルが,昔に比べて下がっている,と言うのもあるように思いますです
18:52 (ktaka) 確かにそうだと思います>適していない時代
18:52 (sengoku`) いや、あるんですが、ようはそれを自分でやろうという気持ちを起こせるかどうか、ってことだと思います。
18:52 (ktaka) 確かにそうだと思います>CPUを作るハードル
18:52 (sengoku`) 技術的な障壁は確実に下がってるんですが、心理的な障壁は、逆にあがってるかも知れませんねぇ
18:53 (katsumiD) なるほど

若干、会話が錯綜気味で読みにくくなってしまっていますが、 それが逆に、 考えがまとまっていなくてもとりあえず書いてしまえ、 という気楽さにつながっているのでしょう。 メールだと、論旨をはっきりさせて書かねば、という気持ちになりますから、 思ったことをそのままぶつけられる IRC のような場も必要だと思います。

ちなみに、会話に参加している 5人のうち、 4人は声の届く範囲にいたりする (^^;) のですが、 ひざ突き合わせて話そうとすると仕事を中断して集まらなければなりませんし、 大声を出すと会話に興味がない人に迷惑ですし、 URL を伝えるときなどは声よりチャットの方がむしろ便利ですし、 また、IRC だとログが残るので後で参照することもできます。

なお、「プログラマを目指すのに適した時代、適していない時代」に言及したのですが、 どちらかというと「ロングテール戦略が格差社会を生む: 必要は発明の母」のほうが話の流れに近かったかも知れません。 要は、不足感がないと何かをやろうという気力が出てこない、 ということが言いたかったわけです。

18:53 (uchikawa-) 昔だったら「自分で作ったほうが世の中にあるものよりいいものになる」だったですからね
18:54 (sengoku`) 世の中にもっといいものがある、からといって遠慮する必要はないんですけどねぇ、ほんとうは。
18:54 (katsumiD) でも,実は心理障壁を乗り越える人はいつの時代だって乗り越えるし,乗り越えない人はいつだって乗り越えない,というのも,
18:54 (katsumiD) http://www.chiaki.cc/Timpy/index.htm
18:54 (katsumiD) こういうサイトを見ていると思ったりもします
18:54 (katsumiD) (こういうのを見ると,むしょうに自分でも何かをしたくなり出します(^^
18:55 (sengoku`) ぜひぜひ
18:55 (katsumiD) ちなみに,今の時代だと,2足歩行ロボットとか,結構盛り上がってますよね
18:56 (katsumiD) ちょっと前は,2足歩行どころか,普通のロボットでも作る機運ってのは無かったですが
18:56 (ktaka) 私的には、やっぱり、WEBやネットワークがチープなフェーズにあるのではないかと思います
18:57 (katsumiD) 色んな製作記事とかキットが出始めたこととかもあって,アマチュアの人が一杯やってらっしゃいますね
18:57 (sengoku`) まあ、どんな分野でもいいんで、ぜひチャレンジして~と。

収拾がつかなくなってきたんで、ちょっと投げやりになっています > 私 (^^;)

18:57 (katsumiD) (^^
18:57 (ktaka) なるほど
18:57 (ktaka) >ロボット
18:57 (ktaka) 二足歩行のおもちゃ変えますもんね
18:57 (ktaka) 買えますもんね
18:58 (sengoku`) Web が普及して一番困ったことは、誰もが批評家になっちゃって、自分ではやろうとしなくなったことなのではないかと...
18:58 (ktaka) そうなんですか
18:59 (ktaka) 何でも自分でやる技術者の世界に、批評家が入り込んできたという意味ですか?
18:59 (sengoku`) なんでも web 見れば載ってるんで、
19:00 (sengoku`) 自分でやらずに、自分でやってるような気分になっちゃう
19:00 (sengoku`) 見るのとやるのとでは大違いなのに、たいてーの人は見るだけで満足しちゃうんじゃないかと...

うっかり「批評家」と言ってしまって意図が通じにくくなってしまいましたが、 誤解されてもすぐ補足説明できるのが IRC のいいところですね。 「自分で実行しないで他者の行為をあれこれ言う者」という意味で使ったのですが、 「批評家」ではなく「評論家」と表現すべきでした。

19:01 (katsumiD) あぁ,それはあるかもですねぇ・・・
19:01 (katsumiD) 変な事をしてる人は一杯いて,それをいろいろ満てるだけでお腹いっぱいになってるとか・・・
19:02 (sengoku`) そういう傾向はあるんじゃないかなぁ~
19:02 (sengoku`) すでにやってる人がいるから、わざわざ自分でやらなくても、って
19:03 (sengoku`) 思っちゃうんじゃないかなぁ
19:03 (sengoku`) やってみれば、新しい発見があるかもしれないのにね。
19:04 (koura-h) それは分かりますね>わざわざ自分で~
19:05 (koura-h) 何かしりごみするっていうのか、既に誰か手を付けてると後から追いかける意欲が薄れるというか。

ようやく思った通りの結論にたどり着きました (^^)。

19:08 (koura-h) 例えばCPANなんかで、「これ自分で作ったんだけど登録してみよー」とか思っても大抵既に誰かがのっけてたりして、そういうのに何個か当たってしまうとそのしりごみの気持ちが強まってしまうっすね。。。
19:11 (ktaka) なるほど
19:12 (ktaka) >CPAN
19:12 (koura-h) (って打ってたら仙石さんが帰られていったorz

あはは。

Filed under: 元CTO の日記,技術と経営,技術者の成長 — hiroaki_sengoku @ 09:00
2006年11月27日

作ること と 売ること (未踏集会 ESPer2006 秋の陣)

先週末、 未踏ソフトウェア創造事業の集会 ESPer2006 秋の陣 でプレゼンしました。 KLab(株)の黎明期に、いかに未踏事業の支援が助けになったか、 そして 5 人でスタートした KLab が 160人を超える会社に発展した過程を紹介しつつ、 私がそこから学んだことなどをお話ししました。 これからベンチャーを立ち上げよう、 そして発展させようとしている技術者の方々の参考になれば幸いです。

使ったスライドを公開します。 25分の持ち時間なので、スライド 21ページくらいは話せるかなと思っていたら、 調子に乗って喋りすぎ、大幅に時間を超過してしまいました。 ゴメンナサイ。 後半かなり早口になってしまい、一番言いたかった 「技術者の地位を向上させるには、 技術者以外の視点にも立ってみて、 技術者自身が視野を広げていかなければならない」 という主旨が、果たしてどこまで伝えられたかちょっと不安に思っています。

私のプレゼン手法は OHP (OverHead Projector) 時代に身につけたもので 1ページあたり 1分以上話すのが普通なのでした。 もう少し内容を絞り込めばよかったと反省しております (これでも、イイタイコトを大幅に削って 流れを単純化したつもりだったのですが... ^^;)。 でも、私の 21ページというのはかなり少ない方で、 多い人だと 100ページを超えていましたね (25分間なのに!)。 OHP 時代は、1ページ数秒しか見せないなんてことはありえなかったわけで、 いろいろなプレゼン手法があるものだと、とても参考になりました。

また懇親会や二次会 (残念ながら三次会は終電が気になってしまって参加できませんでしたが) で、沢山の方々とお話しすることができて とても有意義な時間をすごすことができました。 このような場を準備運営してくださった事務局の方々に感謝します。 ありがとうございました & お疲れ様でした。

スライドを PDF 化したものと、 FlashPaper を使って Flash 化したもの ↓ を公開します。

もっと読む...
Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 08:48
2006年10月2日

2000年、ケータイJAVA がベンチャーと技術者を結び付けた

技術をウリにする会社は、その立ち上げメンバに三種類の人種が含まれていることが必須なのだと思います」と以前書いたのですが、 「人種」が異なる人が出会う事って、 実はかなり稀な現象なのではないかという気がしています。

先日、某大学へ遊びに行く機会があったのですが、 日頃ベンチャーの中ではあまり感じることがなかった 「人種の近さ」のようなシンパシーを 感じてしまいました。 そういえば、私の大学時代の友人には、 大学に残って学究の道を進み、 教授や助教授にまで上り詰めた人が少なくありません。 大学に残らず大企業の研究所などに就職した人もいるのですが、 いつのまにか ;-) 大学に戻っていたりします。

彼らの大半は、私なんぞよりはるかに頭がよく、 その能力をベンチャー発展のために使ってもらえたら、 日本のベンチャーはもっと活気付くのにと、 つい思ってしまうのですが、 彼らの興味がベンチャーに向くことが稀なのだから仕方ありません。

つまり、大学志向の人とベンチャーを興そうという人とでは、 興味の対象が異なるのです。 日本の大学でインターネットの研究が盛んだったのは '80年代の終わりごろです。 インターネット黎明期と呼ばれる頃ですね。 日本を代表するような大企業の研究所では、 当時からインターネットに注目していましたが、 ビジネス的にはまだ海のものとも山のものとも分からず、 ましてこれから起業しようとする人たちが興味を持つような 代物ではありませんでした。

1992年ごろにインターネットの商用利用がはじまりましたが、 インターネットでベンチャーを興してみようと思う人たちが現れたのは、 1994年ころからです。翌年 1995年はインターネット元年と呼ばれていますね。 ところが大学では、 1992年ころまでにインターネットは すっかり日常生活の一部となってしまっていました。 いまさらインターネットで何をするんだ、と思ってしまっていた人も 多かったのではないでしょうか。 今となっては先見の明の無さを恥じるばかりですが、 私自身 1992年ごろには、インターネットにはもはや技術的に新しいことは 何も残ってはいないと思っていました。

ところが、みなさんもご存じの通り、ベンチャーにとってインターネットは '90年代終わりになってからが本番で、 2000年のネットバブル崩壊をものともせず、 数多くのベンチャーが果敢に挑戦を続けています。

学問的に盛り上がってしばらくして下火になる頃から、 それがビジネスの種になりベンチャーが盛り上がる、 こういう順番になるのは当たり前と言えば当たり前すぎるのですが、 こうした時間のずれが、 学問の世界の人たちと ベンチャーの世界の人たちが 出会う機会を減らしているのでしょう。

そんな中、2001年に始まったケータイJAVA は、 学問志向の人とベンチャー志向の人が同時に関心を寄せた、 数少ない例外の一つだったのではないでしょうか。 当時私はベンチャーに対しては何の興味もなかったのですが、 ケータイでユーザプログラムを動かすことができれば、 何か面白そうなことができそうだと思っていました。 一方この年は、iモードの成功が誰の目にも明確になった年で、 ケータイJAVA は iモードの可能性をさらに広げてくれるものとして、 多くのベンチャーが大変な関心を寄せました。

そうして、ベンチャー志向の人と、大学志向の人との出会いが数多く生まれました。 あれから 6年たった今、 こうした出会いを産み出す共通の関心事には何があるでしょうか?

Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 07:38
2006年8月2日

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

ピーターの法則って知ってますか? ウィキペディアから引用すると:

  1. 能力主義の階層社会に於いて、人間は能力の極限まで出世する。 すると有能な平構成員も無能な中間管理職になる。
  2. 時が経つに連れて人間は悉く出世していく。 無能な平構成員はそのまま平構成員の地位に落ち着き、 有能な平構成員は無能な中間管理職の地位に落ち着く。 その結果、各階層は無能な人間で埋め尽くされる。
  3. その組織の仕事は、まだ出世の余地のある、 無能に達していない人間によって遂行される。

確かに自分の能力を超える地位まで登ってしまうと、 能力が発揮できなくなってしまう、というのはありそうな話です。 地位が上がって無能扱いされるくらいなら、 同じ地位に留まって「有能」であり続けるほうがマシというものです。 特に、 成果主義が浸透しつつある昨今、 「無能に達する」ことは大変なリスクを伴います。 そんなリスキーな出世より、 特定の仕事を極めてスペシャリストになることを選ぶ、 という人のほうが多数派なのかもしれませんね。

しかしながら、 同じ仕事が同じ価値を持ち続けるかどうかは、 時と場合によります。 職人技が価値を生む分野であれば、 一つの「技」に一生をかける価値があるでしょう。 例えば、従来日本が得意としてきた「モノ作り」の分野ですね。 熟練工の「技」は、 機械には真似ができないという価値を持っていました。

では、我らが「ソフトウェア開発」はどうでしょうか? 「ソフトウェア開発はモノ作りではない」ので、 モノ作りのアナロジーで考えていると大きく価値判断を誤ります。 ソフトウェア開発においては、モノ作りと違って、 熟練自体は価値を生まないからです。 10年の経験を積んだプログラマが、 プログラミングを始めて 1ヶ月の新人に負かされる、などということが 起り得るのがソフトウェア開発でしょう。

一つの仕事に一生を賭けようとするなら、 自身の能力のうち普遍的な価値を持つのはどんな能力なのか? 他の人には真似ができない自分ならではの良さとは、どんなことなのか? 自問し続けることが重要だと思います。

一つの仕事に一生を賭けるのではなく、 仕事を変え、自分を変えていく、という道もあります。 単に仕事が変わる (例えば昇進する) だけでは、 ピーターの法則通り、いずれ無能に達してしまいますから、 この道を選ぶにあたっては自分を変えることが必須です。

つまり受け身の昇進ではなく、 積極的に今の仕事を捨てるべきでしょう。 部下 (or 後輩) が成長してきて、 自分の代わりがつとまるようになったら、 全てその部下に任せてしまい、 新しいことにチャレンジするわけです。 そうすれば部下も育つし、 自分を変えることができます。 運がよければ新たな成長フェーズに入れるかもしれません。

Filed under: 元CTO の日記,自己啓発 — hiroaki_sengoku @ 08:31
2006年6月20日

コンピュータ科学における体系的な知識

断片的な知識と体系的な知識」にトラックバックを頂きました。 長久さま曰く:

体系的な知識を学ぶことはある程度可能です。 但し、その分野が十分に研究されていて、体系化されているならば、 という条件が付きます。体系化は、学問化と言っても良いでしょう。 この場合、本当に良くできた教科書を読むことで、 体系的な知識を学ぶことができます。
しかし、多くの分野では、体系化まで行ってません。 コンピュータ科学においても、体系化まで進んでいる分野は、一握りです。

「体系」を辞書で引くと、 「一定の原理で組織された知識の統一的全体」(広辞苑) とあります。 私は「統一的全体」として、 かなり広範囲の学問分野を想定していたのですが、 長久さまは「コンピュータ科学においても、体系化まで進んでいる分野は、 一握りです」と 表現されていることから、 もっと狭い個々の技術分野について考えられているのでしょう。 技術分野がどんどん細分化されていく昨今、 長久さまのように、 個々の技術分野の「体系」をイメージされるかたのほうが 多数派なのかも知れませんね。

私がイメージする「体系的知識」とは、 コンピュータ科学でいえば、 例えば「オートマトン理論」のような学問体系のことです。 現在のコンピュータは全てオートマトンですから、 コンピュータ科学全体が一つの体系と言ってしまってもいいかも知れません。 この意味でコンピュータ科学は、かなり体系化されています。 コンピュータ科学という「体系」の視点から見れば、 その中の個々の技術分野の「体系」は、 他の技術分野と相互に関連づけられていない限り 「断片的知識」と言いきってしまえるかも知れません。

「コンピュータ科学 体系」で Google 検索してみると、次の本が見つかりました:

図解雑学 コンピュータ科学の基礎 河村 一樹 (著)

内容
ほとんどの情報処理試験に出題され、 もっとも難しいジャンルとされる「コンピュータ科学基礎」について 図版を豊富に使って丁寧に解説。 コンピュータ科学がいかに体系化され、 いかに研究が進んでいるかを実感できる本。

目次
1 コンピュータサイエンスと符号化理論の基礎
2 論理学の基礎
3 集合論の基礎
4 形式言語理論の基礎
5 オートマトン理論の基礎
6 グラフ理論の基礎
7 プログラミング論の基礎

検索で見つけただけの本なので内容がどうなってるのか分かりませんが(^^;)、
この目次は、コンピュータ科学の体系を俯瞰するのに丁度いいと感じました。

オートマトン理論の中には、 チューリングマシンや計算量の理論などが含まれてくるでしょう。 非決定性チューリングマシンが多項式時間で解くことができる問題のクラス NPや、 オラクル付チューリングマシンが解くことができる問題のクラス階層は、 コンピュータ科学の体系の中でも最も重要な概念の一つと言っても いいかもしれません。

# オラクルといっても DBMS でもなければ、マトリックスの母でもありません ;-p

また、グラフ理論に関連する分野として、組み合わせ理論や探索などがあります。 遺伝的アルゴリズム(GA)は、確率的探索の中の一分野に過ぎません。 GA を単に、交叉・突然変異・自然淘汰からなる探索アルゴリズムとして 理解してしまうと、 本質を見失ってしまうのではないでしょうか。

プログラミング論には、 近年急速に発展しつつあるソフトウェア工学全体が含まれてきます。 秒進分歩といってもいいくらい新しい概念が次々と提案される分野ですが、 本質さえきちんと押えておけば、 数年で廃れる流行に振り回されずに済むのもまた事実です。

同ページで長久さま曰く:

「これ読めば、探索を体系的に学べます」というオチがきたら良かったと思います。 この終わり方だと、生殺しっぽいので。 でも、探索を体系的に記した本って、タブンないと思うんですよね。 捉えるレベルがメタ過ぎて、抽象的になっちゃうと思うので。

まずはコンピュータ科学全体を俯瞰し、 「論理学」「形式言語理論」「オートマトン理論」 「グラフ理論」「組み合わせ理論」「符号化理論」などの コンピュータ科学を支える重要理論を大ざっぱに把握した上で、 特に興味がある分野(例えば探索)をより突っ込んで勉強する、という方法が いいのではないかと思っています。 重要なのは、最初のうちは枝葉末節にあまり捕らわれないようにすることでしょう。 木を一本一本見ていて森が理解できるようになるほど、 コンピュータ科学という森は小さくありません。 まずは森全体の地図を見て体系を理解しておくことが重要でしょうね。

もっと読む...
Filed under: 元CTO の日記,技術者の成長 — hiroaki_sengoku @ 06:37
2006年6月5日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実力主義・能力主義」で

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

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

Filed under: 元CTO の日記,技術者の成長 — hiroaki_sengoku @ 09:45
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年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月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