« 2005年1月16日 - 2005年1月22日 | トップページ | 2005年1月30日 - 2005年2月5日 »

日本のプログラマはどれぐらい優秀なのか?

「ソフトウェア企業の競争戦略」読書感想文にツッコミをもらった。「日本のプログラマは世界一だというが、定量的な根拠はあるのか?」。企業のパフォーマンスを横断的に評価することは非常に難しい。そもそもサンプリング手法からして評価する必要がある。

それでも暫定的なデータとしてこの本では次の通りに述べられている。引用もとはp.281「第4章 開発のベスト・プラクティス」の「パフォーマンスに関する地域差」だ。

顧客へのシステム導入後12ヶ月で計測した1000行ごとの不具合報告で、日本は最も高いレベルにあった。

      日本   0.020
      欧州   0.225
      米国   0.400
      インド   0.263


プログラマ一人が一ヶ月で書けるコードの行数も、日本に優位性あり。

      日本   469
      欧州   N/A
      米国   276
      インド   234

品質の良いプログラムを量産することについては、日本のプログラマは世界一イイィィー、といえる。ただし筆者は「ソフトウェアのイノベーションでは、日本やインドの会社は、真の意味で世界レベルの実績を残していないという点も忘れてはなるまい」、と釘をさしていることも付け加えておく。ここでいう「生産性」を「稼ぎ」に置き換えると、最下位なんだろうねorz

ソフトウェアファクトリーに関するパフォーマンスの調査報告の出典はこれ↓

Michael A. Cusumano and Chris Kemerer,"A Quantitative Analysis of U.S. and Japanese Practice and Performance in Software Development" Management Science 36, no.11 Novenber 1990

| | コメント (0) | トラックバック (0)

「ソフトウェア企業の競争戦略」読書感想文6(最終回)

ソフトウェア「ビジネス」で起業する人向けの話。そのアンチパターンを紹介しているのが「第6章スタートアップ10社のケーススタディ」なのだが、さすが米国だけあって、まさに死屍累々。気持ちいいぐらいの栄枯盛衰。

その10社は、それぞれオリジナルの優れた製品やサービスを有していた。ITバブル華やかなりし米国市場に参入し、人とカネを集め、「モノを作り」、売れずに落ちぶれていった(ただ1社を除く)。筆者は経営顧問や取締役会などの立場からアドバイザリーを行った。どこぞの「動かないコンピュータ」のように、記者の立場から安穏とインタビューした報告ではなく、まさに当事者の一員としてかかわっていた分、生々しい。

報告の一つ一つは、これから起業しようとする人にとっては「めぐすり草」となろう[注1]。最も重要なのが「死のくちづけ」。ベンチャーキャピタルからの資金調達に成功したことを指すのだが、これはなぜ「死」なのか? 答は明らかなのだが、状況により様々な姿をとる。

いったん資金を調達すると、約束したとおりにカネを使わなければならなくなる。ビジネスを構築していく過程で、資金の使い方に注意を払っていれば、もっとよいポジションにいることができたかもしれない

「カネを調達したら、約束どおり使わなければならない」←目論見書には小難しいことがいっぱいかいてあるが、本音はこれやろ。技術や市場の充分な下調べがないまま、経営プロのサポートがないまま起業へと踏み込むと、この「くちづけ」を受けることになる。

「くちづけ」は、製品とサービスのどちらに重心がかかっているかによって、異なる化け方をする。製品を売ることを主眼とする場合、調達した資金は、新規開発費に費やされる。何のためにVCがカネをよこすのかというと、リターンを望んでいるからだ。起業というリスクを一度負いながら新たに開発を始めてしまうということは、種銭を再ベットしてしまうことと一緒。まずいま起業したネタを売ることを考えるべきだろう。売るべきソフトウェアがあるのなら、その市場の顧客全てに売り続ける。一度作って、何度も売ることが極意。Javaの極意が"Write Once Run Anywhere" なのと同様だ。一方サービスで儲けることを目的とした起業だと、調達したカネは、豪奢なオフィスやマネージャ層の新規雇用や新たな販売拠点へと化ける。外部からの資金調達を得る理由は、内部でまかなうよりも、よりスピーディーに有望顧客や市場へ近づくためなのだ。いわばこれらは作られた富、身の丈にあっていないカネなのだろう。

実は、起業できるかと企んでいたネタがある(というか、あった)。ターゲットは「ソフトウェア開発企業」そのもので、売りものは「ソフトウェア開発ライフサイクル全般のプロセス管理スキル」を有した人。売り方はサービスプロセスの均質化と人材開発の注力による「固定価格/固定時間」、即ち時間・コストの遅れはなし(出た場合は追加コストを一切請求しない)。まとめると「ソフトウェア開発プロジェクトマネジメントを人員込みで売る」企業なり。本書でそっくり同じコンセプトの会社の顛末を読んで、あきらめたorz すでに前例があったのね…

* * * * * * * * * *

結論みたいなもの。

本書で何度も強調されてきた「製品を売って、サービスでもうける」という、ソフトウェア企業の基本戦略は、企業に限らず、社畜である私自身にもあてはまることに気づいた。企業と個人の関係で置き換えると、「製品」は「技術」であり「サービス」は「貢献」になるだろう。つまり、私は技術を会社に売って、会社への貢献でもうけることでキャリアを積んでいるのだと考える。

私が新人だったころは「COBOLさえ極めれば、一生喰っていける」あるいは「Cがちゃんとできれば、一生喰うには困らない」と言われた。しかし、かつてバリバリのコボラーや、Cのプログラマは今ではプログラミングをしていない。いや、COBOLやCのプログラミング需要が無くなったとは言っていない、メンテナンスやレガシー更改のため、まだ需要は沢山ある。しかし、COBOLやCを読み書きできるもっと安い給料の若手も沢山いることも事実。さらに、JavaやC++といった、もっと単価の安い言語(失礼!)が取って代わっていることも事実。

そんなわけで、かつてバリバリのコボラーやC使いは、製品の製造過程で身に付けたマネジメントスキルやノウハウ、あるいは特定業界の業務知識やパイプにより、管理職や営業職や指導者へクラスチェンジしている。COBOLなりCといった「技術」にしがみついているわけにはいかない。なぜなら、若手プログラマやJava技術と取替えができるから。会社としては同程度のことを安くあげることができるのなら、むろんそっちに飛びつくだろう[注2]。その代わり、取替えがききにくい「貢献」により employability を向上させることができる。

会社が欲しいのは「そのソリューションを適用して製品化できる人」であって、募集要項「要Javaスキル」はその一例に過ぎない。Javaプログラマとして入社した新人クンは、「Javaが使える人」というパッケージ「製品」としてその「技術」を買われたのであり、恒常的なサービスを提供しつづけなければ、いずれもっと安い「若手Javaプログラマ」という製品に取って代わられることになるだろう[注3]。極端に言うと、究極のプログラマは、一行もコードを書くことなく、製品を生み出すことができる人だろう。MDAが取りざたされているが、ありゃモデルのパターンや部品の数だけコードを書かなきゃいけないので、むしろ業務にロックインされたプログラミングを強いられるオチになろうかと。

COBOL→C→Java と転戦してきたが、次の技術を追いかけるのはちょっと休憩にしてみよう。そして、これまでの経験を基にし、会社の利益に対して貢献できる私なりの方法を形にしてみようと思う。会社であれこの業界であれ、私なりの方法にロックインされるようなサービスを提供できるか、(そのアイディアをカネに換える方法も含めて)考えてみよう。P.F.ドラッカー「プロフェッショナルの条件」で言っていた一節を思い出す。えらい回り道だったが、この「貢献を重視せよ」がようやく分かった気がする。

貢献を重視せよ。貢献に焦点を合わせることによって、専門分野や限定された技能に対してではなく、組織全体の成果に注意を向けるようになる。成果が存在する唯一の場所である外の世界に注意を向けるようになる。自らの専門や部下と組織全体や組織の目的や関係について、徹底的に考えざるを得なくなる。

(;゚0゚)ハッ! 本の題名が違う…が、まぁ気にしないで下さいませ。だらだらと書きなぐったこの連載をここまで読んでいただき、ありがとうございます。

(おしまい)

--
[注1] 「めぐすり草」を知らないよい子に説明しよう! めぐすり草とは、「風来のシレン」や「トルネコの不思議のダンジョン」シリーズにでてくる、「隠れていたワナが見えるようになる薬草」のことだ。転ばぬ先のめぐすり草だねっ。

[注2] もちろん一定の年齢以上になっても「プログラマ」として雇われ続けることができる人がいる。しかし彼はその世界では既にネ申のごとき存在となっている。神はそうそういない。

[注3] 話を分かりやすくするために形式知と暗黙知という要素を除いて書いているが、「開発のお作法、暗黙知があるじゃねーか!」というツッコミが入れられる人は、もう「サービス」で会社に貢献しているといえる。


| | コメント (2) | トラックバック (0)

「ソフトウェア企業の競争戦略」読書感想文5

マイクロソフトの開発スタイルの話。カネに飽かせて優秀なプログラマがわんさと集めているマイクロソフト。放っておいても凄いものができるんじゃないの? という人は、少なくともこの記事なんて読まない。良いプログラムは良いプログラマでしか書けないが、良いプログラマさえ集めれば良いプログラムになるとは限らないことを知っているから。ここでの「良い」は各人の好きな内容でどうぞ。

筆者は Windows95/NT/2000 および MS-Office シリーズの開発スタイルを分析し、一つのベスト・プラクティスを導き出している。筆者は「同期安定化プロセス」と名づけている。第4章「開発のベスト・プラクティス」でその詳細な説明があるので、開発手法やマネジメント手法にお悩みの方は読むと得るものがあるかも。

そこで問題。Windows開発プロジェクトチームのうち、最も強い「権力」を持っていたのはどれか?

  1.プログラマ
  2.テスタ
  3.ビルダ

答はマウス反転表示→「3.ビルダ」。「ええっ」と思った方もいるかもしれない(それは私)。モノ作りのメインであるプログラマこそが最も力が強いはずじゃないのか?

プログラマは、同時並行してテストを行うテスタの「相棒」と一対一の組になって開発する。そうした組が3-8人程度で一つのチームを編成し、個々の機能(ユーザが確認できる機能)を作る。それらのチームが、一つの大きな組織のように協同作業する必要が出てくるわけだ。Windows2000 の場合は15-20チームで並行作業していたという。

仕様や設計上の変動要素もある。秒針分歩の技術・ニーズをいつ実装するかという課題もある。そのためWindows の開発では詳細な仕様書を書かなかった。書いてもどうせ変更されるんだ。プログラムの変更に合わせて仕様書との一貫性を保つための作業は、捨てるかもしれない機能のための仕様書を書く作業と同様、リソースを割り当てられることはなかった。

複雑で大規模なプロジェクトを、多くの人員を投入し、同時並行で進める。しかも変更が大いに発生することは予め分かっている。マイクロソフトは同時並行して作業を進めながら、たえず同期を取るプロセスを適用することで、この問題に対処した。そのキモは、

 1.完全な製品のビルドを、毎日、決まった時間に実施する
 2.ビルドの度にテストを繰り返し実施しデバッグを行う
 3.ビルドとデバッグの時間厳守

マイクロソフトの場合は夕方5時がチェックインタイム。この時間までにソースをアップしておくことが絶対条件で、逆にいえば、それさえ守っていれば何をしててもOK。遊んでいようが、夜中だけ働いていようが、部屋から一歩も出てこなくても、何の文句もいわれない。元イスラエル軍戦車部隊の指揮官で、Windows95の品質管理責任者を担当したデーブ・マリッツのコメントを引用する。

組織構造がなければ複雑なことは何もできっこない。ただし、できるだけその体制は見えないようにし、あの気難し屋の開発連中に、何でもやりたいことをできるという幻想を抱かせなければならないのです。一日中、素足で歩き回っていても構いませんよ。オフィスの中にテディベアのぬいぐるみ、どうぞどうぞ。私にとってそんなことはどうでもよいことです。ただし、もしだれかが、夕方五時までにコードをチェック・インしていなかったとしたら、そのときは私がそいつのオフィスに入っていくときだということを、連中はよくわかっているはずです

プロジェクト・ビルド・マスターはマスター版ソースを用いて毎日「製品」をビルドし、テストする。ビルドもテストもスクリプトによる自動化が図られているため、時間的にはたいしたことはない。ただし、ビルドやテストが通らなかった場合、プログラマは「居残り」となる。イノベーションは任されているし、自由度もある。しかし好き放題にプログラミングしても「製品」は絶対に出来ない。ともすればバラバラになりがちのプロジェクトをデイリービルドで「同期」を取り、その度にテストを実施することで「安定化」を図る。これがマイクロソフトのやりかた[注1]。

マイクロソフトが作っているのは「製品」だ。デイリービルドでは部品ではなく、「製品」を作る。では「製品」とは何か。製品とはビルドとテストが通った機能群のことを指す。どんなに優れたライブラリやクラスでもビルドとテストが通っていないのであれば、それは製品とは呼ばない。それは「在庫」だ。在庫はいくら良質でも、大量にあっても、動かない(動かせない)プログラムだ。酷い言い方をしていいなら、ゴミだ。

「ファクトリー」と銘うたれた日本のソフトウェア企業はこの意識が低い。「製造業」のくせに在庫を「在庫」と思っていない。「製造業」の最たるトヨタを例に挙げる。ジャスト・イン・タイム方式と世間にもてはやされているが、あれは「在庫を道路上に放置プレイ」なんだろ。トヨタに限らず、製造業が蛇蠍のごとく嫌っているのは在庫だ。なぜなら、いかなる在庫であれ、それを保管しておく場所代、管理費(人件費)を要する。そのくせバランスシートでは「資産」として扱われる。一円にもなっていないのに!系列子会社に対し、原材料を工場へ持ち込む時間を細かく指定することで、在庫ゼロを目指しているのだから。トヨタ系列の工場を早朝に訪れてみるとよく分かる。子会社からの原材料を積んだトラックの列が長蛇を成している。それほど「在庫」は悪なのだ。

しかし、ソフトウェアの場合の「在庫」はほとんど意識されない。なにしろ場所代をとらない。コンパイルしてなければ数キロで済むテキストファイルだから。もちろん管理費も取らない。プログラムを書いたらどっかのフォルダに放り込んでおけば一丁あがり。でもやっていることは在庫を量産しているだけなんだ、そいつがビルドとテストを通らない限り

本書では一言も言ってないが、「製品」を毎日作る同期安定化プロセスは、「在庫」を極力なくそうとするジャスト・イン・タイムにだぶって見える。

また、同期安定化プロセスの説明により、マイクロソフト独自の「それは仕様です」の理由がわかる。仕様書なんて書いていないので、仕様なんてはじめから存在しないのだ。ある操作をすると必ず青画面になったりするのは、開発者が想定していなかった動作であり、そいつは「再現可能な不具合」や「認識された誤動作」と名づけられる。別名「それは仕様です」だ。その「仕様」に対しリソースが割り当てられリリース予定日が決まった時点で初めて「バグ」として認められるのだ、めでたしめでたし…ってザケンナー!

日本(やIBM)を代表とするソフトウェア・ファクトリーでは非常に詳細な仕様書を書く、と筆者は指摘する。それが柔軟な変更や素早い開発(あじゃいる?)を妨げていると断ずる。しかし、できあがったモノに対し「それはおかしい」という指摘の根拠があるわけだ。つまり仕様書にあるから仕様なのであり、無いから仕様ではない、という非常にあたりまえな話ができる。

もちろん「黒は色である」という仕様に対し「白も色である、従って、黒は白である」と展開する顧客もいる。狂っているとしか思えないが「色は黒とする」という仕様は存在する。そして通常、そうした仕様は契約条項として残る。仕様書に書いていないことを要求する理不尽な顧客に対しては「仕様書に無い機能については…」といった免責事項も可能だ。

いずれにせよ、契約による仕事を行う場合の根拠となるのが仕様書だ。これなしでビジネスをするのであれば、契約する相手もいない全く新しいモノに対し仕事をするか、あるいは顧客なんて相手にしない殿様商売の場合に限られる。ま、筆者に言わせるとこのような考え方そのものが「ファクトリー」的な発想なんだろう。はい、分かってます、私は大富豪にはなれませんな(w

(つづく)

--
[注1] このへんの打打発矢は「闘うプログラマー」が面白い。Windows-NTの開発秘話。OSの開発が非常にスリリングに物語られている。ネタとしてはよいが、プロジェクトとしては問題アリだろう。

| | コメント (0) | トラックバック (1)

« 2005年1月16日 - 2005年1月22日 | トップページ | 2005年1月30日 - 2005年2月5日 »