仙石浩明の日記 » 技術と経営 http://www.gcd.org/blog CTO兼プログラマ兼システム管理者の視点から Mon, 08 Mar 2010 00:25:06 +0000 http://wordpress.org/?v=2.9.2 ja hourly 1 技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき http://www.gcd.org/blog/2008/07/399/ http://www.gcd.org/blog/2008/07/399/#comments Mon, 21 Jul 2008 22:46:04 +0000 hiroaki_sengoku http://www.gcd.org/blog/2008/07/399/ 先週参加した社外の飲み会 (私は飲めないので専らウーロン茶でしたが) で、 Linux ディストリビューションの開発や、 カーネル技術を売りにしたコンサルティングで有名な某社の カーネル技術者とお会いしました。 彼はいま伸び盛りの若手カーネル・ハッカーなのですが、 オープン・ソース・ソフトウェア (以下 OSS と略記) ビジネスについて熱く語ったり、 ディストリビューションをサポートし続ける使命感に燃えていたのが、 わたし的にはちょっと気になりまして、 ひとこと言いたくなってしまいました(お節介ですね ^^;)。

ディストリビューションのサポート体制 (カーネルのバグにも的確に即応できる体制) を維持し続けることによって、 多くの企業で Linux を安心して使ってもらうことができて、 それが OSS の発展につながるし、 それこそが自分の使命だと彼は考えているようでした。 それはそれで意義あることだとは思うのですが、 彼のような優秀な技術者には、 「サポート」という目的だけに捕らわれず、 もっと自由に興味の赴くまま学び、 自らのスキルを伸ばしていって欲しいと思ったのです。

OSS 関連のビジネスというと、 すぐ、 サポートでお金を稼ぐとか、 OSS 活用のコンサルティング事業とかの発想をする人が多いのですが、 誰もが思いつく事業だけに、 ビジネスモデルとしては稚拙な部類と言わざるを得ません。 高い技術力がそのまま売りにつながった前世紀ならいざ知らず、 競争が激化してビジネスモデルの巧拙が事業の成否を大きく左右する昨今、 いまだに何の「ひねり」もない「OSS サポート」に固執するのは、 いかがなものかと思うのです。

技術コンサルティング事業というと聞えはいいのですが、 要は「人月ビジネス」です。 どんなに優秀な技術者 (「ピンからキリまで」 の「ピン」ですね) であっても、 一人月 1000万円払ってくれるお客がいるはずはなく、 素人技術者 (以下「キリ」と略記) の 5～6倍の人月単価を稼げば御の字というのが実状ではないでしょうか。 だからコンサルティング事業といいつつ、 高額のソフトウェアを売り付けてライセンス料を稼ぐことのほうが、 メインの目的だったりする会社もあるわけです。

ただあいにく OSS の場合は高額のライセス料を請求するのは無理があります。 せいぜい保守料と称してわずかばかりの費用を請求するのが関の山でしょう。 だから OSS のコンサルティングというのはあまりよいビジネスモデルとは言えません。 ものすごい労力とコストをかけてピンをそろえて (お客に高いね～と言われつつ) 5倍の人月単価を設定するくらいなら、 コストをかけずにキリを大量に集めて格安な人月単価で売りさばく (いわゆる派遣ビジネス) 方が、 経済合理性にかなうというものです。

キリに成長の機会も与えずに 「若いだけが取り柄の労働力」 として派遣して使い捨てにする事業は当然非難されるべきですが、 労働時間では測りしれない価値を持つはずのピンを人月換算してしまう事業もまた、 非難されるべきではないでしょうか？ 人月ビジネスでは売上を増やすには人員を増やさざるを得ず、 売上が拡大しても決して余裕は生まれません。 いやそれどころか、 どんどん仕事を片付けてくれる優秀な技術者にどんどん仕事が集中して、 優秀な技術者ほど疲弊する、 という理不尽なことも起り得ます。

頼りにされるあまり、多くの仕事がその人に任されることになる。 できる人に、仕事が集中するのは、よくある話で、 その人は、回りの期待にこたえようとして、遅くまで残業して、 休日も出社したりする。 この状態が、一過性のものだったら良いんだけど、 慢性的なものになると、肉体も精神もぼろぼろになっていく。

ピンとキリでは生産性で何十倍～何百倍 (私は 3桁の差があると日頃から主張していますが) もの差があるのに、 わずか 5～6倍の売上の差しか出せないのは、 「儲ける仕掛け」が無いからです。 ピンの労働時間を人月換算するのではなく、 ピンの技術なしには実現できないような (つまり競合他社には構築不可能な) 儲ける仕掛けを編み出して売上を増幅し、 それによって生じた余裕でピンの仕事量を思いきって抑えることによってこそ、 その優秀さに報いることができるのだと思います。

そうすれば仕事の負荷が軽くなったピンは、 ピンならではの新しい価値を産み出すことに注力できます。 新しい事業のシーズを産み出す研究開発でもいいですし、 あるいは OSS から恩恵を受けている企業であれば、 ピンの人が (勤務時間中も) OSS コミュニティで活躍することを奨励することによって、 OSS の世界に「恩返し」することもできます。

前世紀は技術力が高ければ儲ける仕掛けを誰でも作ることができた時代でした。 つまり優れたソフトウェアなら結構な値段で売ることができたのです。 マーケティングがしっかりしていれば、 開発費を大幅に上回る売上も達成できました。 典型例はマイクロソフトですね。 ピンが作ったソフトウェアを何億本も売ったわけで、 ピンの労働力が人月単価の何万倍もの価値を生んだことになります。 その後 OSS の発展と普及により、 ソフトウェアを売るだけというビジネスモデルは行き詰まりました。 今ほど新しいビジネスモデルが重要となった時代はないと言えるでしょう。

さらにいうと、 技術者が優秀であればあるほど、 その「シーズ」は一般人の「ニーズ」からかけ離れていく、 という難しさもあります。 例えば、 優れたカーネル・ハッカーの技術を、 真に必要とする人が世の中にどれだけいるのか？という問題です。 技術の素人である大多数の消費者にとっては、 小難しい技術のことなんか全く分からないし興味もありません。 高い技術力が売れるどころか、 逆にその高度さが「需要」を減らしてしまう原因となりかねません。

高度な「シーズ」と一般の「ニーズ」を結び付けるには、 高度なビジネスモデルが求められるわけで、 技術者がハッキングの合間に思いつくようなビジネスモデルではお話になりません。 優れたカーネル・ハッカーが、 四六時中寝る間も惜しんでカーネル・ソースのことばかり考えているのと同様、 優れたビジネスモデルを考え出すビジネスの戦略家 (以下、戦略家と略記) は、 四六時中寝る間も惜しんで儲ける仕掛けのことばかり考えています。 素人考えのビジネスモデルが通用すると思うのは、 C言語を覚えたばかりの素人技術者が、 カーネル・デバッグに挑もうとするくらい無謀なことでしょう。

当たり前のことですが餅は餅屋であり、 技術のことは技術者に任せるべきですし、 儲ける仕掛けのことは戦略家に任せるべきです。 優秀な技術者は、優秀であればあるほど、 優秀な戦略家と組むべきなのです。 ところが世の中の大半の会社はそうなっていません。

超優秀なハッカーは互いに認め合う技術者同士ばかりで集まり、 ビジネスモデルの重要性を軽視してしまいます。 ビジネスモデルなんて自分たちだけでも考え出せると思ってしまい、 社員のほとんどが技術者、なんて会社になってしまいます。 実地に売り歩く営業の必要性にはさすがに気付いて営業担当者を数人雇ったり、 あるいは社長が自ら売り歩いたりするようになるものの、 儲ける仕掛けの構築には無頓着で、 旧態依然としたビジネスモデルのままだったりします。 そのため事業を拡大しても余裕が生まれず、 ちょっとした外部環境の変化でたちまち立ち行かなくなる恐れがあります。

逆に、優れた儲ける仕掛けを生み出すことができる有能な戦略家は、 一日24時間、儲ける仕掛けを考え出すことばかりに夢中で、 その仕掛けを下支えする高度な技術のことは軽視してしまいます。 技術なんて下請けをいじめればなんとでもなると考えてしまい、 決して技術者をパートナーとは考えません。 技術者を、売るものを作ってくれる便利な人と考えてくれればまだマシなほうで、 下手するとコストばかりかかる必要悪くらいの勢いで、 原価削減の手法をあれこれ考え始めたりします。 しかし技術を軽視したツケは、いろいろな形で払うことになるでしょう。 事業を下支えする技術が脆弱であれば事業の継続性が危ぶまれますし、 技術面で他社との差別化が行なえずに他社の参入を許してしまうかも知れません。

これでは技術者と戦略家の利害はどんどん対立してしまいます。 この悪循環をくい止める唯一の方法は、 技術者が ──特に、優秀であればあるほど── ビジネスモデルの良し悪しを嗅ぎ分ける嗅覚を持つことです。 誰が優れた「儲ける仕掛け」を生み出すことができるのか、 技術者が判断できるようになれば、 人月ビジネスから抜け出す見込みのない会社を見限ることが できるようになるでしょう。

対称性を考慮すれば、 戦略家が技術の優劣を嗅ぎ分ける嗅覚を持つことによっても、 利害対立の悪循環をくい止めることが (理論上は) 可能ですが、 高度に専門化・細分化してしまった技術を、 技術者ではない戦略家に (優劣を判断できるほどに) 理解してもらうことは現実的とは思えません。 戦略家と技術者が協力しあうには、 まず技術者の側が相手を理解する必要があるのです。

そうすれば、 より優れた戦略家のもとに優秀な技術者が集まるようになり、 戦略家と技術者の利害が一致する方向へ淘汰圧が働きます。 すなわち、 戦略家が優秀な技術者と組むことにより、 技術者には (従来想像していた以上に) 優劣の差があって、 どのレベルの技術者と組むかが事業の成否を大きく左右する、 ということが明らかになってくるはずです。

優秀な技術者が事業にどれだけ貢献し得るか実感できれば、 優秀な技術者に対して、その能力に見合った待遇 ──報酬はもちろんですが、 仕事量を減らして OSS コミュニティへの貢献を推奨するなど── を提供すれば優秀な技術者が集めやすくなる、 ということも実感できるようになることでしょう。

技術者の側からすると信じられないことだとは思いますが、 ピンもキリもそんなに大した差ではない (せいぜい 5～6倍) と、 技術者でない人の大半は感じています。 縁遠い技術になればなるほどこの傾向は強まるようで、 例えばカーネル技術者の中でもメンテナとデバイス・ドライバの開発者とでは、 (技術者の目から見れば) だいぶレベルの差がありますが、 (技術者以外の人で) その能力差を実感できる人は皆無でしょう。

技術者の待遇向上の鍵は、 技術者がビジネスモデルの良し悪しにもっと敏感になること、 すなわち会社における技術職以外の職種の役割についてもっと理解し、 技術職以外の人達についても、 その能力の優劣を見分けられるようになることにこそ、 あるのだと思います。

]]> http://www.gcd.org/blog/2008/07/399/feed/ 5 自身の能力をアピールすることは技術者として必須だが、上司にだけアピールするのは最悪！ http://www.gcd.org/blog/2008/01/397/ http://www.gcd.org/blog/2008/01/397/#comments Tue, 15 Jan 2008 02:15:53 +0000 hiroaki_sengoku http://www.gcd.org/blog/2008/01/397/ 私自身は、 KLab 社内の技術者たちと、 いつまでも技術者同士の関係でいたいと思っているのですが、 技術者の人数が増えてくると、 仕事上の接点がほとんどない人もでてきます。 そして社員の側からすると、 私は (いちおー ;-) 取締役なので、 おいそれとは話せない恐い人などと根拠無く思い込んでるケースも、 残念ながら皆無というわけではありません。

それではいけないということで、 日頃あまり接点のない人たちを中心に、 無理矢理 (^^;) ランチに誘って話する、ということをしています。 先日も隣の部署の N さんと二人でランチへ行きました。 彼とは入社直後の社員旅行で少し話をしただけで、 その後は話す機会がほとんどなかったのです。

それまで私は知らなかったのですが、 実は彼は高専時代にず抜けた存在で、全校で表彰されたこともあったそうです。 プログラミングが大好きで、いろんなものを作っては、 学校内でアピールし注目を集めていたとか。 しかしながら KLab 社内ではどちらかといえば目立たない存在だった (目立たなかったので私も話す機会がありませんでした) ので、 高専での活躍ぶりとのギャップを感じざるを得ませんでした。

そこで、 何がきっかけで自身の成果をアピールするのを止めてしまったのか尋ねました。 すると、

新卒で就職した会社 (≠ KLab) で、 開発ではない部署に配属されてしまった。 何事も挑戦ということでしばらくは配属された部署で頑張ったが、 やっぱりプログラミングを仕事にしたいと思い、 上司に何度も自身の能力をアピールしたところ、 ことごとく却下されてしまった。 それどころかアピールすればするほど周囲の評価も下がるぐらいで、 ついにはアピールするのを止めてしまった。

という答が返ってきました。

確かにそういう人は多いのだろうなぁと思います。 日頃、アピールすることの重要性を説いている私としては残念でなりません。 そもそも誰だって、 他の人より得意なことがあれば、 それを自慢したくなるのがフツーでしょう。 だからアピールする習慣がない人って、 元々アピールするのが嫌いだったというわけではなくて、 何らかのきっかけでアピールするのを止めてしまったのだろうと思います。

きっかけにはいろいろあるでしょうが、 N さんのように、 アピールしても周囲から評価されなかったり、 それどころか怒られたり、 周囲から浮いてしまって仕事が進めにくくなったり、 そういう嫌な経験をすれば、 だんだんとアピールするのが億劫になってしまうのは仕方がないところだと思います。 N さんの話に頷きながら、 ふと一つのフレーズが頭の中に浮かんできました:

自身の能力をアピールすることは技術者として必須だが、
上司にだけアピールするのは最悪！

技術者にとって重要な能力というと、 一つは間違いなく「スキルアップする能力」でしょう。 誰だって最初は初心者です。 プログラミングの勘所が最初から分かっていたなんて人は (たぶん) 皆無で、 初めて書いたプログラムを後に読んでみると、 その稚拙さ加減にあきれてしまう、というのはよくある話です。

最初は誰しも稚拙なプログラムを書いていたのに、 どんどん能力を伸ばす人がいる一方で、 多少は「形」を覚えて「それなりの」プログラムが書けるようになるものの、 本質的には初心者と代わり映えしない人 (偽ベテラン) もいて、 いつのまにか両者の間には生産性で 3桁の差がついていた、 なんてことが起こり得ます。

技術者にとって重要な能力がもう一つあります。 それが「アピールする能力」。 言うまでもなく技術者だけではお金にはなりません。 技術者の能力をお金に換える人 ──例えば技術者が作ったものを他の誰かに売り付ける人──と、 一緒になって初めてお金が稼ぐことができるわけです。 でも、どうやってその「換金してくれる人」を探せばよいのでしょうか？

実は「換金してくれる人」も技術者を探しています。 そりゃ、売るものがなければお金を稼げませんから、 技術者の能力を換金しようと思っている人が技術者を探すのは当たり前ですね。 だからわざわざ技術者の側からアクションを起さなくても、 学校には「求人票」が貼られ、 巷には転職斡旋会社の広告が氾濫しているわけです。 テキトーな会社を選んで面接を受ければ雇ってもらえてお金をもらえます。

とはいえ、受け身の姿勢よりは自ら動いたほうが有利になるのは世の常です。 学校に貼ってある求人票に限定した就職活動や、 あるいは転職エージェントの勧めに従うばかりの転職活動よりは、 自ら主体的に会社探しをしたほうが「高く」換金してもらえる可能性が高まります。

会社に雇ってもらった場合、 配属された部署の上司が「換金してくれる人」になります。 もちろん上司が一人でお金を稼いでくるわけではありませんが、 技術者から見れば、 自身の能力に対して評価し給料を決めてくれるわけですから、 自身の能力を「換金してくれる人」と言ってもいいでしょう (正確に言えば、換金してくれる人たちの集団の窓口的存在ですね)。

ところが、ここに一つ問題があります。 技術者に得手不得手があるのと同様、 「換金してくれる人」にも得手不得手があります。 技術者からすれば、 私はこんなに優れた能力を持っているのに、 どーして換金してくれないんだと思うのと同様、 「換金してくれる人」からすれば、 私はこーいう技術ならお金に換えられるのに、 どーしてそういう技術を持っている人がいないんだと思っていたりします。

「能力を上司が正当に評価してくれない」と不満に思っている場合、 十中八九その上司は、 「求める能力を部下が持っていない」と不満に思っているはずです。 このような状況で、 部下が上司に自身の能力をアピールして事態が改善するでしょうか。 きっと上司はこう思うはずです: 「そんな能力はお金にならない」。

より正確に言えば、 その上司が換金できる分野と、 技術者である部下の得意分野とが一致していないだけなんですが、 部下が自分の得意分野以外のことに興味がないのと同様、 上司は自分が換金できない分野には興味がありません。 そんな上司に執拗にアピールすれば、 事態を改善するどころか悪化させかねません。 技術者がすべきことは、 自身の能力を上司が換金できないのであれば、 他の「換金してくれる人」を探すことです。

ところが、 前述の N さんをはじめ多くの技術者は、 逆のことをやってしまいます。 「換金してくれる人」を探すのではなく、 上司に「換金してくれ」と懇願したり、 あるいはそれが却下されると、 もう世界にはただ一人も換金してくれる人はいないと 探すのをあきらめてしまったりするのです。

冷静に考えれば、 これは全くナンセンスであることが分かりますよね? 一口に IT (情報技術) と言っても、 様々な分野があります。 ある技術者の得意分野を最もうまく換金できる人が、 たまたまその人の上司だった、 なんてことがもし起これば、 それはすごくラッキーなことだと思いますが、 そんな幸運がそうそう起こるはずはありません。

自身の技術を上司が換金してくれなかったとしても、 そんなことは確率からいえば 「よくあること」 なわけで、 決してその技術が 「お金にならない」 ことを意味しません。 自身の技術が上司に評価されないときこそ、 より積極的に、上司以外の人に向かって、 自身の技術をアピールすべきでしょう。

より多くの人にアピールすれば、 それだけ「運命の人」にめぐりあう確率は高まります。 「この分野にかけては誰にも負けない」という得意分野を持っている人は、 より多くの人へ、 部署内だけでなく社内全体へ、 社内だけでなくより広い世界に対して、 どんどんアピールしていって欲しいと思います。 探す範囲を広げていけば、 その能力を換金してくれる人がきっと見つかるはずです。

]]> http://www.gcd.org/blog/2008/01/397/feed/ 1 面接FAQ: Tech総研「転職体験談」の取材を受けました http://www.gcd.org/blog/2007/08/395/ http://www.gcd.org/blog/2007/08/395/#comments Mon, 06 Aug 2007 22:04:57 +0000 hiroaki_sengoku http://www.gcd.org/blog/2007/08/395/ 前回、 思い出したように「面接FAQ」を再開したのにはワケがあります。 Tech総研さんの「転職体験談」の取材を受けることになりまして、 それが、 あらためて私の面接のやりかたを振り返るきっかけになったのでした。 「転職体験談」というのは、 「転職を果たしたエンジニアと面接官が当時を再現」する連載企画で、 「応募者と面接官それぞれの言葉の真意や、 面接でチェックされるポイントをレポート」しようというものだそうです。

取材中は好き勝手なことを言いまくったので、 どのようなページにまとまるかと内心ドキドキしていたのですが (^^;)、 無難にまとまったようでホッとしています。 さすがはプロですね。

携帯電話関連を中心に独自技術で業界を走るKLabへ

携帯電話関連のさまざまな独自技術で知られるKLab（クラブ）は、 エンジニアに対する考え方が他社とは一味違う。 現時点での技術力や知識、担当した仕事の売り上げよりも、 ｢技術が好き｣から発する、挑戦や技術上の本質に対する継続的改善を尊ぶ。 また、技術力のみで昇格できる社内制度も設けている。
（取材・文／須田忠博　総研スタッフ／高橋マサシ）作成日：07.07.30

応募したエンジニア: 富田陽介さん（当時25歳）
企業の面接担当者: 取締役CTO 仙石浩明氏
募集職種: 技術力次第でCTOを目指せる研究開発職

Part1 転職の動機
Part2 技術志向性の強さ
Part3 現時点での関心

このような連載企画は、 応募者にとっては、 面接を受ける前にどんなことに注意すればいいかが分かるわけで、 とても参考になるのだろうと思いますが、 実は求人側の企業にとっても 面接のやり方を第三者の目で見てもらえる機会であるわけで、 とても有意義であると感じました。

求職側は、いろいろな会社の面接を受ければ、 どんな面接があるのか実地に知ることができますが、 求人側は、他社がどんな面接をしているかあまり知る機会はないですし、 まして自分達の面接が第三者の目から見るとどう映るのか、 教えてもらう機会は皆無ですから…

もちろん取材なので、忌憚のない意見を言ってもらえるわけではないのですが、 取材していただいた Tech総研の高橋マサシ様曰く:

現在の業務内容も転職の動機も重視せず、 「いかに技術が好きか」で人を見る面接。 この連載をほぼ50回続けていますが、 初めてのケースでした。 このことを仙石氏に話すと、 「えっ、他社はどんな面接なんですか？」と逆に驚いた様子。 数々の応募者ではなく、あなたが、いちばん技術が好きなんですよね。

やたらに「こんな面接は初めて見た」と強調されるので、 逆にこちらが驚いてしまいました。 面接して採用した技術者が入社後どのくらい伸びるかは、 その人がどのくらい技術が好きかにかかっているわけで、 なら「どれだけ技術が好きか」をとことん聞くべきだと思うのですが、 他社の面接はそうじゃないのですかねぇ…?

なお、 「携帯電話関連を中心に独自技術で業界を走るKLabへ」ページ末尾にある:

このレポートに関連する求人情報です
チェックしてみよう！
KLab株式会社
現在の募集職種はこちら
詳細をみる

をクリックすると、 「この企業は現在リクナビＮＥＸＴ上で募集を行っていません」などと 表示されます (^^;) が、 私のブログを読んで下さってるかたなら、 リクナビNEXT (あるいはその他の求人媒体) で募集を行なっていないからといって、 応募できないわけではない、ということは よくご理解いただけてますよね？

一応、念のために申し上げておきますと、 KLab (に限らず大多数のベンチャーも同様だと思いますが) では、 常に直接応募を受付けております。 媒体やエージェント経由でないと応募を受付けないなどということは 一切ありませんし、 どこ経由で応募したかということは選考には一切影響しません。 さらに言えば「私は KLab へ入ってこれがやりたいんだ!」と 言ってくださるかたならば、 現在の募集職種にかかわらず採用を検討します。 やりたいことが明確になっていることこそが、 技術者の成長にとって一番重要なことだと思うからです。

技術を学ぼうとするなら、その時点での実力はサテオキ、 「伝わる状態」にかけては自分が一番だと自信を持って言い張れる (つまり、その技術を学びたいという情熱にかけては誰にも負けないと言いきれる) 状態からスタートしなければならないのです
]]> http://www.gcd.org/blog/2007/08/395/feed/ 1 転職エージェントは、誰の「エージェント」なのか？ http://www.gcd.org/blog/2007/05/120/ http://www.gcd.org/blog/2007/05/120/#comments Fri, 25 May 2007 10:37:39 +0000 hiroaki_sengoku http://www.gcd.org/blog/2007/05/120/ 転職エージェントとは、 求職側と求人側のマッチングを行なう人材紹介会社のこと:

正式には「有料職業紹介事業所」と呼ばれ、 厚生労働大臣の認可を受けた民間の職業紹介・あっせん会社のことです。 転職を希望する方と、正社員などを募集している企業とを 「人の手」でつなぐサービスを行っています。 転職エージェントが集めた求人情報は、 企業の人事担当者から直接仕入れた生の情報です。 そのため、企業の求める人物像を的確に把握した上で、 マッチングを行うことができます。

転職の際、お世話になった人も多いだろうし、 かくいう私自身、KLab(株) 創業メンバに加わるきっかけは、 転職エージェント (もちろん、上記引用先エージェント会社とは異なる会社である) に紹介されたからだった。

当時 (2000年3月)、連載記事を書いていた日経Linux の巻末「ライターから」に、

転職には全く無関心だった (転職雑誌は一度も読んだことがありませんでした) 私が なぜ転職することになったのか、話は半年以上前に遡ります。 昨年の夏、突然職場に外国人から電話がかかってきました。 慣れない英語で必死に聞いていると、 どうやら就職斡旋会社の人 (かっこよく言うとヘッドハンタですが ;-) のようです。 胡散臭いと思いつつも何度か英語のメールをやり取り (もちろん職場のアドレスを使うのは避けました) すると、 真っ当な斡旋会社であることが分かったので、一度会ってみることにしました。

と、書いたように、 ある日突然電話がかかってきて、誘われるままに企業を紹介されただけだったので、 転職エージェントがなぜ無料なのかも理解していなかった。 転職希望者から見ると無料だが、 実際は求人企業が「コンサルティングフィー」を負担しているから無料、 というだけのこと。

転職エージェントは、 転職希望者に相談料やサービス料を求めることは一切ありません。 それは、企業の採用を支援することにより、 求人企業からコンサルティングフィーを受け取っているからです。
転職エージェントとは から続けて引用

私を採用するときに支払ったこの「コンサルティングフィー」が いかに高額であったかを、 後になって愚痴っぽく聞かされたものだが、 あれから 7 年、KLab(株) は順調に発展しているわけであるし、 負担させてしまった「コンサルティングフィー」に見合う働きは できたのではないかと自負している。

求人企業が支払った「コンサルティングフィー」が、 「コンサルティング」を受けたことによって 求人企業と求職者とが得た「利益」に見合えば、 転職エージェント、求人企業、求職者の三者ともハッピーであるわけだし、 (私自身の事例も含めて) そういう転職事例も多いとは思う。

しかしながら、求人企業と求職者が得た利益の合計が 「フィー」を下回る場合はどうだろう？ 三者のうち、 一者 (求職者) がこの「フィー」の額を知らされないという点に、 この転職斡旋の仕組みの問題があるように思う。 すなわち、求職者にとって転職エージェントは キャリアアドバイスを受けられたり、求人企業との交渉を代行してくれたりと、 とても「心強いパートナー」なのであるが、 このサービスが実際に支払われる「フィー」に見合うか否かの判断は、 「フィー」の額を知らなければ不可能だと思う。

さらに言えば、求職者が転職エージェントから受けるサービスは、 どんなに親身なキャリアアドバイスであったとしても、 どんなに高く見積ったとしても、 数十万円以上の価値を認める求職者は極めて稀なはず。 もし仮に求職者自身がサービスの対価を支払うのであれば、 もっと低い額になってしまうかも知れない。 つまり求職者側の感覚からすれば、 一般的なコンサルティングフィーは、文字通り桁違いに高額である。

だから、コンサルティングフィーは、 求職者に対するサービスというよりは、 求人企業に対するサービス (つまり求職者を探しだし、紹介すること) の 対価ということになる。 希少な人材であればあるほど (探し出すにはコストがかかるから) サービスを受けることによって求人企業が得られると感じる利益は大きくなるわけで、 得られる利益がフィーより大きいと考えれば、 紹介してもらった人を喜んで採用することになるし、 得られる利益がフィーより小さい、 すなわちあまり希少性が高くない人材と判断すれば、 たとえ採用基準を満たしたとしていても、 不採用になるだろう。

求職者にとっての転職エージェントを、 「プロスポーツ選手のエージェント」に喩えることがあるようだが、 この喩えは次の理由で不適切と言わざるを得ない。 すなわち、「プロスポーツ選手のエージェント」は、 選手の代理人として、 選手の利益を最大化することを目的として行動するのに対し、 転職エージェントのサービスは前述したように主に求人企業に向けられている。 プロスポーツの選手は当然、エージェントの成功報酬額を知っていて、 エージェントが報酬額に見合う働きをしていないと思えば、 その契約を解消して別のエージェントと契約するだろう。 一方、転職エージェントの場合は、 求職者が成功報酬額を知らないばかりか、 エージェントとの契約が簡易な「登録」で済まされてしまうことも多い。

つまり、「転職エージェントは、誰の『エージェント』なのか？」といえば、 求人企業に代わって求職者を探してくれる、 求人企業のエージェント (代理人) なのである。 このことは秘密でも何でもなく、多くの人が知っている事実だと思うのだが、 問題は当事者である求職者が、この事実を知らされていない、 あるいは「求職者のエージェント」であると誤解するのを放置している、 あるいは (派手な広告宣伝などによって) 誤解を助長していることにあるのだと思う。

求職者にもコンサルティングフィーの額を開示する、 あるいはキャリアアドバイス (and/or 求人企業との交渉の代行) と就職斡旋を分離する、 というのは非現実的かも知れないが、 転職エージェント業界がより健全に発展するために 必要な思考実験のようにも思われるのだが、 どうだろうか。

- o -

なぜこんな話をするかと言えば、 数年来の知人を転職エージェントに紹介されてしまう、 というハプニングに最近見舞われたからだ。 求人企業と転職希望者が勝手に直接意思疏通しては、 転職エージェントが「フィー」を請求できなくなってしまう。 そこで転職エージェントは求人企業と契約を結んで、 このような意思疏通を制限するのが一般的だが、 おかげで知人なのに話せない、というとても苦しい立場に追い込まれてしまった。

不条理を感じつつも、契約は契約なので仕方がない。 その知人がメールで、

転職エージェント A社さんの件で すが A社さんと連絡をとった所、説得されてしまいまして
(^.^;)このまま A社さん経由で手続きさせていただきたいん ですがよろしいでしょうか?
仙石さんからしてみたら回りくどいことをとお思いかもしれません が、どうか宜しくお願いします。
A社さん自体はいいエージェントさんだと(私は)判断してま すので、宜しくお願いします。

と連絡してきた時点で万事休すである。 私にできることといえば、 転職エージェント経由で送られて来た知人のレジメを読んで、 書類選考の結果を転職エージェント経由で返すことだけである。 知人にとっては、転職エージェントを利用するメリット/デメリットは、

メリット:
A社が応募書類の送付などの手続きを代行してくれるから楽。
他にも数社に応募していて、そこら辺のスケジューリングとか交渉が楽になる。
デメリット:
「回りくどい」と私に思われる

であって、 メリットの方が大きいと判断したのだろう。 よもや、 (転職が成立した暁には) 「手続きとかスケジューリングとか交渉が楽になる」なんてメリットが 消し飛ぶくらい高額のフィーが転職エージェントに支払われることになろうとは 夢にも思っていないはずである。

いくら高額でも自分で払うわけじゃないから気にならない、 と考える人がいるかも知れないが、 フィーの額が採否を左右するとしたらどうだろう？ 求人企業側にとってはフィーを払う以上、 そのフィーに見合う人材かどうかが採否の判断基準になるのは当然のこと。 だとすれば不当に (?) 高い値段が自分につけられていないか、 気になるのではないだろうか？

この知人のケースでは、 能力的には KLab(株) の採用基準を満たしていそうな気もした (面接は行なっていないので定かではない) のだが、 フィーに見合うほど希少性が高いとは言いきれなかった。 そこで不採用の旨を転職エージェント A社に伝えた。

- o -

求人企業側として転職エージェントと取引することが多いのだが、 どういうわけか転職エージェントに求職者側として扱われることもある。 つまり転職エージェントから転職の誘いが来る。 ほとんどは下手な鉄砲数打ちゃ当る式に勧誘しているだけだろうから 無視しているのだが、 中には私のブログなどにも目を通して狙い撃ちしてくる転職エージェント (エグゼクティブ サーチと呼ばれる場合が多いかも) もある。 しかも特定の企業から依頼を受けて連絡したことを匂わせていたりする。

私の場合、コンサルティングフィーの世間相場もだいたい理解しているつもりだし、 (もちろん転職する意志はないが) 仮に誘いにのって転職するとすれば、 そのフィーの額を上回る価値を転職先企業に提供できる自信もある。 しかし私の名前を指定して転職エージェントに依頼するほど 私の能力を買ってくださる企業ならば、 なぜ転職エージェントなどを介さず直接連絡してこないのだろうか、とも思う。

(続きを読む…)]]> http://www.gcd.org/blog/2007/05/120/feed/ 2 技術者を目指す学生さんたちへ http://www.gcd.org/blog/2007/01/386/ http://www.gcd.org/blog/2007/01/386/#comments Tue, 16 Jan 2007 22:49:01 +0000 hiroaki_sengoku http://www.gcd.org/blog/2007/01/386/ いよいよ就職活動本番ですね。 どのような進路を選ぶにせよ、 あとで後悔することのないよう、 じっくり考えて決めたいものですよね。 でも、ただ単に考えると言っても、 一人であれこれ思い悩むのは感心しません。 「思いて学ばざれば則ち殆し」と言いますから、 ぜひいろいろ見聞きした上で考えて頂きたいと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

KLab株式会社 取締役
兼 最高技術責任者
仙石浩明
]]> http://www.gcd.org/blog/2007/01/386/feed/ 1 年功主義と実力主義 ～大企業とベンチャー～ http://www.gcd.org/blog/2006/12/384/ http://www.gcd.org/blog/2006/12/384/#comments Thu, 14 Dec 2006 07:48:04 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/12/384/ 私が大学を卒業したのはバブル (ネットバブルではなく、その前の前世紀のほう) がはじけた年でした。 当時は今ほどベンチャーは一般的ではありませんでしたし、 研究職を目指していた学生 (含む私) が就職先として大企業の研究所を選ぶのは、 ごく普通のことだったのではないかと思います。 終身雇用を信じていたわけでもありませんでしたが、 かといって自分自身が転職することになろうとは、 あまり考えてもいなかったような時代です。 今から振り返ってみれば「就職」というよりは「就社」という感覚に 近かったのだと思います。

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

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

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

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

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

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

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

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

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

(続きを読む…)]]> http://www.gcd.org/blog/2006/12/384/feed/ 2 なぜ人月見積もりが優れているのか http://www.gcd.org/blog/2006/12/383/ http://www.gcd.org/blog/2006/12/383/#comments Fri, 08 Dec 2006 08:40:02 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/12/383/ 人月見積りでは生産性が上がらない。 IPA が警告するまでもなく、 ソフトウェア技術者ならば誰しも 人月見積りに嫌悪感を持っているのではないでしょうか。 生産性を上げれば上げるほど金額が低くなってしまうし、 そもそも開発者の生産性なんて人によって大きく異なる (私の持論は、 「ピンとキリでは 1000倍の差がある」、です) のだから、 「標準的な技術者一人が一ヶ月かかる仕事」なんて基準をおいたところで 意味がありません。

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

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

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

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

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

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

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

- o -

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

と、いいますと？

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

]]> http://www.gcd.org/blog/2006/12/383/feed/ 2 ソフトウェア産業の究極の振興策 http://www.gcd.org/blog/2006/12/108/ http://www.gcd.org/blog/2006/12/108/#comments Fri, 08 Dec 2006 04:18:59 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/12/108/ IPA (情報処理推進機構) のかたとお話しした。 優秀なソフトウェア技術者の成果をビジネスにつなげるための支援をするには、 どうしたらいいかヒアリングしたいとのこと。

ああ、この人もソフトウェアをモノと誤解している人なんだ。

ソフトウェア以外の分野、 たとえばバイオや新素材などでは 優れた発明・発見がビジネスに直結する。 真に有効なモノ (例えば新薬や新素材) の真に有効な製造方法が発明されれば、 あとは製造工場を建設するのに必要なカネがあればよい。 だから、資金援助を行なうことが即、その産業の振興につながる。

しかしながらソフトウェアはモノではない。 ソフトウェアには特殊な製造方法などなにもない。 あるソフトウェアを作るのに特殊な「知的財産」が必要、 などということはないのである。

確かに、ソフトウェアの分野にも一応「発明」と称するのものがあるが、 その「発明」が公開されなければ製造できないソフトウェアが果たしてあるだろうか？ 「ソフトウェア特許」を認めるべきか否かについては様々な議論があるが、 ソフトウェアを他の分野と同列に扱うことはできない、 ということだけは確かであろう。

では、ソフトウェア産業の振興には何が必要なのか？ なぜ日本のソフトウェア業界には (例えば Google のような) 破壊的なイノベーションが生まれないのか？

簡単である、ソフトウェアを作る優秀な技術者が足らないからである。 だから振興策も簡単で、 技術者をビジネスの現場に引き合わせればよい。

と言ったら、IPA でも 未踏ソフトウェア創造事業で発掘した人材を、 ソフトウェアの販売会社と引き合わせている、 という答が返ってきた。

そんなことを言っているのではない！

未踏事業で開発したソフトウェアを販売会社に紹介すれば、 確かに興味を持つ会社は出てくるだろう。 実際に販売してくれるところも出てくるかも知れない。 でもそんなことをして高々数千本ソフトウェアを売ったところで何になる？ せいぜい (すごくうまくいったとしても) 数憶円の売上にしかならないだろうし、 数千本といえど売れば開発者はサポートに忙殺されてしまう。 せっかく発掘した貴重な人材の使い道としては、 あまりにモッタイナイ使い方ではないか。

優秀な技術者をソフトウェア販売会社に引き合わせたって意味はない。
優秀な技術者を「ビジネスの現場」に引き合わせなければならない。
つまり、優秀な技術者がその能力を存分に発揮し、 その能力に見合う報酬を喜んで支払う「事業家」に引き合わせなければならない。

日本のソフトウェア産業がアメリカに負けっぱなしなのは、 優秀な技術者が日本にいないからだろうか？

否！！

優秀な技術者と、優秀な事業家が、出会っていないだけである。 日本にも、勢いのある IT ベンチャーは数多い。 ところがそうしたベンチャーに入社しようと思う優秀な技術者がどれだけいるのか？ ほとんど全ての IT ベンチャーは優秀な技術者を渇望している。 その一方で、大企業の研究所には優秀な技術者がゴロゴロしている。 私は日立製作所の研究所に 8年間勤めたので痛感しているのだが、 私よりよっぽど優秀な人が、特に活躍するわけでもなくゴロゴロしている。 つまり凡人でもできるような仕事をして、 凡人と同レベルの給料をもらって満足しているのである。

もちろんお金が全てではないし、 優秀な人はすべからくその能力をフルに発揮して活躍しなければならない、 というものでもない。 自らの能力を披露することなく静かに暮すのも一つの生き方であろう。

しかし、優秀な技術者の大半が、大企業の奥底で眠っているのだとしたら…?
そして日本のソフトウェア産業を振興させたいと思うのなら…?
それなら有効な振興策は一つしかない。 唯一にして最も効果的な究極の振興策、それは…

大企業の一つをつぶして、死蔵していた優秀な人材を放出させることである。

]]> http://www.gcd.org/blog/2006/12/108/feed/ 15 チープ教育: 「無意味にポジティブ」のススメ http://www.gcd.org/blog/2006/12/382/ http://www.gcd.org/blog/2006/12/382/#comments Tue, 05 Dec 2006 00:00:59 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/12/382/ 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

あはは。

]]> http://www.gcd.org/blog/2006/12/382/feed/ 1 作ること と 売ること (未踏集会 ESPer2006 秋の陣) http://www.gcd.org/blog/2006/11/381/ http://www.gcd.org/blog/2006/11/381/#comments Sun, 26 Nov 2006 23:48:21 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/11/381/ 先週末、 未踏ソフトウェア創造事業の集会 ESPer2006 秋の陣 でプレゼンしました。 KLab(株)の黎明期に、いかに未踏事業の支援が助けになったか、 そして 5 人でスタートした KLab が 160人を超える会社に発展した過程を紹介しつつ、 私がそこから学んだことなどをお話ししました。 これからベンチャーを立ち上げよう、 そして発展させようとしている技術者の方々の参考になれば幸いです。

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

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

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

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

(続きを読む…)]]> http://www.gcd.org/blog/2006/11/381/feed/ 1 未踏ソフトウェア創造事業の集会 ESPer2006 秋の陣 でプレゼンします http://www.gcd.org/blog/2006/11/380/ http://www.gcd.org/blog/2006/11/380/#comments Mon, 13 Nov 2006 22:20:26 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/11/380/ ご存じの方も多いと思いますが、 情報処理推進機構(IPA)が実施している個人支援事業に、 未踏ソフトウェア創造事業 (Exploratory Software Project) があります。 私自身、第一回め(2000年)に 「携帯電話用アプレット開発ツール」を採択いただき、 超優秀な学生さん二人と共に、 Java と文法レベルで互換のコンパイラ&VM (Virtual Machine) を開発しました。 テーマ概要から引用:

携帯電話上で走らせるJavaプログラムは， サイズが小さいことが第一の条件である． しかし，Javaは元々 PCなど比較的リソース制限が緩いコンピュータ上で走らせることを想定していたため， 小さいプログラムを書くには特殊なテクニックが必要となる． つまり，一般のプログラマには敷居が高すぎ， このままでは携帯電話のJavaコンテンツの発展を阻害する恐れがある．

そこで，携帯電話上で動作するプログラムを開発するための コンパイラなどの開発を提案する． このコンパイラが生成するプログラムは， 同機能を持つ携帯電話上の通常のJavaプログラムの 1/10以下のサイズ (目標値) であり， 現状の携帯電話網においても無理なくダウンロードすることができる．

携帯電話がどんどん高機能化し、 当時のPC よりよほどパワフルになってしまった現在から見ると、 遠い昔の話のようです(^^;)。 採択・支援いただいた PM (プロジェクトマネージャ) の指摘:

現地ヒアリングのときに聞いた携帯電話上のJavaリソース制限の 技術的あるいは政策的な厳しさ (例えば，一つのiアプリのコードは10Kバイト以下に抑えないといけない) は， マウスイヤーの今日どれくらいの期間意味をもつのだろうか． このプロジェクトはこういったことに若干振り回されてしまったような印象もあるが， 得られたKamiyaシリーズの技術自体は， 携帯電話のモデルチェンジ周期より長い生命をもつであろう． 特にダイナミックリンクが要らないという見切りは 典型的なアプリケーションに対してある程度の汎用性があると思われる．

は、実に的確でした。 携帯電話があっという間に高機能化してしまって 成果物の製品化は実現しなかったのですが、 KLab株式会社 (当時の社名は、株式会社ケイ・ラボラトリー) の 創業期に技術会社としての基礎をどう築くか模索していた私にとって、 この開発プロジェクトは大きな意味を持ちました。

そんなわけで、KLab株式会社の黎明期に、 いかに未踏事業の支援が助けになったか、 機会あれば発表したいと思っていたところ、 「未踏」集会 ESPer2006 秋の陣 で 何かプレゼンしないか、とお誘い頂き、 一も二もなく引き受けました。

ESPer2006 秋の陣

日時　2006年11月25日（土）
　　　13：00開場、13：20開始、18：00頃まで
　　　その後 懇親会を行いますので、是非ご参加ください
会場　神戸国際会議場　国際会議室

定員　最大240名まで

プログラム・企画と登壇者
　　　　IPAより、事業の紹介等
　　　　ＰＭ談議（仮称）
　　　　仙石 浩明氏
　　　　尾藤 正人氏
　　　　平林 幹雄氏
　　　　森 悠紀氏
　　　　油井 誠氏

2000年8月に 5人でスタートしたベンチャーが、 160人を超える会社 (2006年11月現在) に成長した、 その発展秘話(?) を、 未踏事業に採択された一技術者 (つまり私) の視点からお話ししたいと思います。 経営者の視点で書かれた会社発展物語はあまたあれど、 技術者の視点というのは、そんなに多くはないと思います (ってまだどんな話にまとめようか、まとめきっていませんが… 25日までに間に合うかな ^^;)。 自身の技術を起業につなげたい、 それも、十数人の規模ではなく、 100人あるいはそれを超える規模を目指したい、 と思っている方々の参考になれば幸いです。

会場にはまだ余裕があるようですから、 興味あるかたは 予約申込み の上、 ご参集下さい。 懇親会もあるようですから、読者の皆様とお会いするのを楽しみにしております。

]]> http://www.gcd.org/blog/2006/11/380/feed/ 0 2000年、ケータイJAVA がベンチャーと技術者を結び付けた http://www.gcd.org/blog/2006/10/378/ http://www.gcd.org/blog/2006/10/378/#comments Sun, 01 Oct 2006 22:38:15 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/10/378/ 「技術をウリにする会社は、その立ち上げメンバに三種類の人種が含まれていることが必須なのだと思います」と以前書いたのですが、 「人種」が異なる人が出会う事って、 実はかなり稀な現象なのではないかという気がしています。

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

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

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

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

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

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

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

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

]]> http://www.gcd.org/blog/2006/10/378/feed/ 1 「ソフトウェア開発」は「モノ作り」ではない (2) http://www.gcd.org/blog/2006/07/92/ http://www.gcd.org/blog/2006/07/92/#comments Fri, 28 Jul 2006 22:54:33 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/07/92/ 「「ソフトウェア開発」は「モノ作り」ではない」を とても多くの方々に読んで頂けた。 コメント/トラックバックを頂いた方々、 はてなブックマーク して頂いた方々に 感謝申し上げる。

これだけ多くの方々に読んで頂くと、 誤解するかたも少なくないようだ。 まあ、私の文章力が至らないのだから仕方ないが、 誤解したかたも、もう少し説明を補足すれば理解し合えるのかも知れず、 もう少し書いてみようと思う。

一番の失敗は、 日経ビジネス online の記事を引用してしまったために、 この谷島氏の記事「ITの常識は世間の非常識」の主張が、 私の主張 (の一部) と思われてしまった点だ。 谷島氏の記事では、

「そもそも情報システムと自動車を同一視することもいかがなものかと。 情報システムを何か出来合いの産業機器のように受け止めているわけですよね。 やはり、顧客の意思が反映されるソフトウエアというものをお分かりではない、 ということでは」

ということにまで言及しているが、 私が主張したかったのは「ソフトウェア開発とは何か？」ということであって、 私が言う「開発」とは狭義の開発であり、 谷島氏のメインの主張である要件定義の話まで踏み込むつもりはない。

言うまでもなく要件定義はシステム開発を請け負うにあたって 最重要なステップであり、 要件定義の良し悪しがプロジェクトの成否を分けると言っても過言ではない。 しかし、だからといって他のステップを 無視してしまっていいというわけでもないだろう。

「システムを開発する技術者は、コンサルタントを目指すべし」くらいの勢いで 主張されるかたも多いし、 日経BP 等の Web ページを見ていると、 技術者にとって必要なスキルはコミュニケーション能力だ、 という主張ばかりが目立つ。 確かにコミュニケーション能力は重要ではあるが、 技術者の本分はあくまで「技術力」であって、 それをないがしろにしていいわけがない。

なので、私が主張したいのはあくまで、 技術者がどうすれば技術力を磨くことができるか、 という点にある。 そして、技術力を磨く上で最大の障害になっていると私が感じるのが、 ソフトウェア開発が何であるか、 技術者をとりまく人たち (特に経営側) が分かっていないことが多いし、 いやそれどころか当の技術者さえ、きちんと理解できていないことがある、 という点なのである。

ソフトウェア開発が何であるかが分かっていなければ、 すなわちソフトウェア開発を「モノ作り」と考えていては、 技術者を育てようとしても、 あるいは技術者自身がスキルアップを目指していろいろ勉強しても、 本質を外して徒労に終わるリスクが高い。 せっかく勉強するなら、きちんと本質をとらえて、 「技術力」を確実に伸ばしていって欲しい。

]]> http://www.gcd.org/blog/2006/07/92/feed/ 6 「ソフトウェア開発」は「モノ作り」ではない http://www.gcd.org/blog/2006/07/91/ http://www.gcd.org/blog/2006/07/91/#comments Thu, 27 Jul 2006 23:22:06 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/07/91/ いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。

日経ビジネス online の記事に次のようなくだりがあった:

「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」

IT業界は 100億円かけても使えるものが作れない非常識な世界、というわけである。 まあよく聞く批判で、そう言いたくなる気持ちも理解できるのであるが、 100億円が高いとする根拠がいただけない。 同じ記事中に続けてこういう話が出てくる:

「例えば、自動車を買うとします。 希望の車種と色調を言えば、その通りの車が期限通りに納車される。 万一、色が違っていればすぐ取り替えてくれるし、 その車が動かないなんてことはまずない。 欠陥があった場合、リコールがある。 しかし、コンピューターの場合、自動車ではありえないことが四六時中起きる。 経営トップとしては何とも理解し難いわけです」

つまり、ソフトウェア開発を自動車の製造と比較しているのである。 自動車は、「わずか」数百万円なのに「使える」製品が買える。 自動車と同程度に複雑なソフトウェアを開発しようと思ったら、 少なくとも数億円から数十億円はかかるだろうし、 数十億円かけたところで、 現在の工業製品としての自動車のレベルの品質は望むべくもない。

このような批判は、 「ソフトウェア」を「モノ」と同一視したためにおこる誤解が元となっている。 ソフトウェア開発という「家内制手工業」をせめて「工場制手工業」へ発展させ、 ゆくゆくは「機械制大工業」に進化させようという試みの多くも、 同様の誤解がベースになっているわけで、 「ソフトウェア開発」を「モノ作り」と見なす誤解は、 広く蔓延してしまっているのかもしれない。

問: 「ソフトウェア開発」が「モノ作り」でないなら、何なのだ？

答: 「設計」である。

自動車とソフトウェアを比較するなら、 「自動車の設計図」が、 「ソフトウェア」(より正確に言えばソースコード) に相当する。 「自動車の製造」に相当するのは、 ソフトウェアを出荷するときに行なう「ビルド」「コピー」「パッケージング」 であろう。

「自動車の製造」には例えば一台あたり百万円を超えるようなコストがかかり、 1万台生産しようとすれば 100億円を超えるコストがかかる。 大量生産すればするほど「製造コスト」が支配的になるから忘れがちであるが、 自動車の設計にも結構なコストがかかっている。 設計図を引くコストだけでなく、その前提となる研究開発も必要だし、 エンジンや制御用コンピュータなどの部品の設計も含めれば、 ゼロから一台の車を設計するコストは、かなりの額 (よく分からないが数億円で済むとはとても思えない) になるだろう。 完全「特注」の自動車を設計してもらうとしたら、 いったいどのくらいかかるのだろう？

一方、ソフトウェアの開発においては、 「製造コスト」は無視できる。 1万本生産するとしても、パッケージングコストは 1 本あたりせいぜい数百円程度だろうから、数百万円程度で済んでしまう。 ダウンロード販売なら何万本生産 (つまりコピー) しても原価は 0 円である (もちろん、ダウンロード サイトの運用などには費用がかかるが、 それは原価ではなく「販管費」である)。

ソフトウェアの設計というと、 要件定義、外部仕様、詳細仕様、等々を作ることを指すことが多いのでややこしいが、 製造業においても、図面を引く前には仕様を詳細につめているはずなので、 自動車の設計図を書く工程を「設計」と呼ぶのであれば、 ソフトウェアのコーディングも「設計」と見なすべきだろう。 コーディングの「家内制手工業」ぶりを批判したいのであれば、 比較対象は設計図を書く工程であるべきであって、 組み立て工程ではない。 ソフトウェア開発の近代化は重要な課題であるが、 そのお手本を「機械制大工業」における「製造工程」に求めてしまっては、 大きく道を誤る。

(つづく)

]]> http://www.gcd.org/blog/2006/07/91/feed/ 43 生活水準の「中流」と能力の「中流」 http://www.gcd.org/blog/2006/07/90/ http://www.gcd.org/blog/2006/07/90/#comments Mon, 24 Jul 2006 00:11:36 +0000 hiroaki_sengoku http://www.gcd.org/blog/2006/07/90/ 昨日放送された NHK スペシャル (21:00～):

「ワーキングプアー・働いても働いても豊かになれない」
低所得者層の拡大
定職につけない“住所不定無職”の若者
基幹産業の不振ほか

で、「働いても豊かになれない」若者が、 自分だって普通の人と同じくらい、「中の上」くらいの能力はある、 と言っていたのが妙に印象的だった。

ソフトウェアの開発業界では、 「中の上」の人 10人より、 「上」の人 1人のほうが力になる、 というのが常識として浸透しつつあると思う。 「人員を投入すればするほど、かえって工期は長引く」とか、 「少数のプログラマで開発する方が短期間で品質の高いものが作れる」 とかの事例は広く知られるようになった。 しかし世間一般では、 まだまだ「大勢の普通の人」の方が 「少数の優秀な人」より役に立つ、 という感覚なのかも知れない。

高度成長期のころ、能力の「中流」は、生活水準の「中流」につながった。 情報革命が進行しつつある現在、 「中流」の能力を持つ労働者に「中流」の待遇を提供できないのを、 企業の責任と言いきってしまって良いのだろうか？ 「中流」の能力が以前ほど重要視されない原因を、 「規制緩和」に求めるべきなのだろうか？

]]> http://www.gcd.org/blog/2006/07/90/feed/ 1