« 2005年1月9日 - 2005年1月15日 | トップページ | 2005年1月23日 - 2005年1月29日 »

日本経済新聞は信用できるか

挑発的なのは題名まで。これが「朝日新聞」なら読人は激減するだろう。この本は1997-2004までの日経を読み解いて、その見識の浅さ、煽リスト具合、首尾不一貫性、勉強不足、紋切型、逃口上を淡々と検証している。

例えばバブル経済。日経連載「犯意なき過ち」は興味深く読ませてもらった(かつ面白かった)が、そのツッコミは2chなら一コマで済む↓

   ∧_∧   / ̄ ̄ ̄ ̄ ̄
  ( ´∀`)< オマエモナー
  (    ) \_____
   | | |
  (__)_)

バブルを煽った日経がそう言うなと。「バブル崩壊は予測不可能の事態で、みんな踊らされたのです」論調は、そいつを煽りまくった自戒は一切無し。だいたい同一日の紙面で円高善玉論と悪玉論を仲良く併記できるなんて、節操もないというか日和ん[注1]だねッ

…という訳で米国御用聞カタログレベルの日経について、ここまでホンキで読み解いている著者にある意味感動。そしてamazonレビューイたちも同様↓

おまいら、新聞をそこまで信じて読んでるんだね (つД`)
新聞で最も信用できるのは天気予報だけだって。
--
[注1] 「ひよりん」と読む。日和見主義のこと。「ひよったな!」は団塊ネタ。「るんらら~」は水色ヲタ。

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

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

日本のプログラマは優秀だ。コスト意識が高く優れた品質のソフトウェアを作ろうとしている。しかし、そんな優秀なプログラマがいる日本企業が世界を変えたり、誰かが大富豪になったりしない理由はカンタン↓

コスト意識はあるかもしれないが、ベネフィット(利益)意識をもつ人はいない

コストを削減し生産性を上げることは非常に重要。しかし、それで莫大な利益をもたらしたり会社が安泰になったりすることは、ぶっちゃけありえない。「生産性の向上で○%のコスト削減!」は耳タコだが、「このテストが今週中に通って出荷できれば○千万円の利益が見込めるが、来月までズレこめば○千万円の損だ」なんて聞いたことがあるかだろうか?

「それはプログラマの仕事じゃない!」という反論は、そのとーり。ワタシも激しく同意。その仕事はプログラマの仕事じゃないことは認めるとしても、ビジネスとして会社をやっていくのであれば、会社の誰かがやっている仕事、だよね?

その仕事をプログラマが引き受けてしまった場合、悲劇がうまれる。

この本には、エクスプローラとネットスケープのブラウザ戦争の話が出てくる(以下IEとNN)。モザイクやネットスケープが普及し、IEが参入した頃の話だ。Windowsにバインドさせるマイクソロフトの販売戦略により、最終的にネスケが敗れ去ったと記憶しているが、著者は別の観点から分析している。

マイクソロフトが当初リリースしたIEは酷いものだった。非常に不安定なしろもので、ブラウザがフリーズするならまだしも、青画面まで引き起こすようなものだった。機能も貧弱で、NNと比較するのが気の毒なぐらいだった。

初期のIEを開発したプログラマは、その出来栄えに充分満足して出荷OKをしたわけではないことはわざわざ言うまでもあるまい。むしろ出荷判定にかかわっていないまま「知らないうちに」リリースされていいたんじゃないかと勘ぐる。

酷かろうがなんだろうが、あのタイミングでブラウザ市場に参入できていなかったならば、マイクソロフトは永久に「ブラウザ」を出荷することはなかっただろう。バグだらけで不安定だったとしても、リリースするタイミングは純粋にソフトウェア「ビジネス」として下されたと確信する。品質やコストを重視するのは大切だが、「ビジネス」ではシェアを奪らなければ意味が無い。市場参入のタイミングや、OSにバインドする売り方は、プログラマからすれば正気の沙汰とは思えないが、その決定はソフトウェアの品質やコストとは別の次元で決定されていた筈だ、間違いなく「プログラマ」ではない人によって。

一方でネスケのNN開発はどうだったか? 著者によると、アーキテクチャのモジュール化をほとんど考慮する間もなく、1994-96にかけてコードベースを10万ステップ→300万ステップに拡大したという。その原因は「市場の圧力」即ち「より多くの機能を!」に応えた結果だ。より多くのプラグインを、より便利なショートカットを、よりグラフィカルにetc… 

結局のところ、規模がある臨界点を越えたときから、開発チームは200人全員で二人三脚レースをしているようになってしまった。本当に速いスプリンターがいたとしても、全員の足がつながっているため、最も足が遅い人のスピードで走らざるを得なくなっていた。誰かが失敗したわけでもないのに、チーム全体がつまずいたり、遅くなったりするのがあたりまえの状況となっていた。誰かが「もういい、ここでいったん切り離そう」と言わない限り、200人201脚は離れなくなってしまっていたのだ。

マイクソロフトはソフトウェア「ビジネス」を追求した。彼らはビジネスとして利益を追求するための判断をした。たとえそこに、ユーザーやプログラマの意思が除外されていたとしても、ソフトウェア「ビジネス」としては正しい判断だったのだ。

「ビジネス」の視線を最も端的に表現した発言を引用する。マイクロソフト副社長、クリス・ピーターズの発言だ。太字化は私。自分のblogはときどき読み返すが、この引用文は頻繁に読み返す必要がある、この単純極まりない事実をよく忘れるので。

マイクロソフト事業部門のメンバーの職務は、全員が全く同じです。それは製品を出荷することです。コードを書くことでも、テストをすることでも、仕様書を書くことでもありません。製品を出荷することが仕事なのです。コードを書こうなどと考えることすら避けるべきでしょう。コードを書かずに稼げるのであれば、是非そうしたいものであります。

問題へ戻る。

利益を意識して仕事をする人がいない

問題はここにある。なんちゃってSEや駄目プログラマや能書きマネージャが問題なのではない。そんな奴ぁ日本に限ったことではない(ディルバートを見よ!)。一部のグズが全体の足を引っ張っているなんて、ソフトウェア産業に限ったことですらない。

ソフトウェア「ビジネス」として成立させるための努力を措いといて、「コスト」「品質」「納期」の徹底さえできれば良しと考えている経営が真の原因なり。もちろんそれらは重要だが、ビジネスとして必要なのは、利益を出す、しかも出しつづけること。先に述べた「製品を売って、サービスで稼ぐ」しくみを続けていくこと。やりかたはここで書くのが恥ずかしいぐらいあたりまえだが…

  1. 市場を見極め、必要な技術、人材、資金を集める。銀行ごと買ってもOK
  2. 製品を作る。作らなくてもヨソから買ってきても可だし、製造会社ごと買ってもOK
  3. 製品を売る。販売部隊を買ってきても可だし、営業会社ごと勝手もOK
  4. シェアを奪う、あるいは開拓する。「売」らなくても可。シェアを奪るためであればタダでも可
  5. サービスで継続的に稼ぐ(バージョンアップなどそのサービスを受けつづけざるをえない状況を作る)
  6. ↑のやり方を「業界標準」化することで、自社と業界そのものをバインドさせる
  7. ↑で得た自社株やブランドを元手に1へ戻る

あれ? どこかでこのやり方を目にしたような…なんのことははい、孫正義氏がやっているやり方ではないか。毀誉褒貶が激しい人物だが、彼がやっていることは「ビジネス」なんだと思う。日立や富士通と比較した場合、「人材」レベルでは雲泥の差のソフトバンクが(失礼!)そうした大企業と伍している(ように見える)のは、ソフトウェア「ビジネス」とソフトウェア「ファクトリー」の差なんだろうねッ。

近い将来、孫氏は大富豪になるかもしれないが、大企業のあるマネージャが大富豪になる可能性は、ずっと低いだろう。孫氏が世界標準となる技術を手にする(開発する、ではないよ)可能性はあるかもしれないが、大企業のあるマネージャがそうなる可能性は、ずっと低いだろう。

(つづく)


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

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

我が日本のプログラマはァァァァ世界一ィィィィィ(シュトロハイム風)の話。ここでは、そんな優秀なプログラマを抱える日本企業が、海外雄飛できない理由を書く。

バカな!? 自動車を代表とするメイド・イン・ジャパンは世界に通用するはずなのに、ソフトウェアビジネスでは例外なのか?

日本のソフトウェア企業が優れたアプリケーションプログラムを書いたり、極めて高度な統合システムを構築する技術・能力を有することは明白だろう。それは、メガバンク金融システムや新幹線の制御システム、テレビゲームに至るまで、さまざまな事例が証明している。

しかしこうしたシステムの多くは、特定の顧客専用に作られたものであり、設計上のイノベーションといえるようなものはほとんどない、と著者はいう。

日立、富士通、NEC、東芝、NTTのようなメジャーなソフトウェア企業は、主にハードウェアやサービスを販売するためにソフトウェアを書いているのであり、これはIBMが数十年にわたりたどってきた道にほかならない

太字化はワタシ。営々とやってきたことはIBMのものまね師[注1]なわけね。ぐぅの音も出ないまま「TRONなら…」とチラと考えたが、読み進むに従ってその未来が見えてきた(数ある未来の一つと思いたい)。著者は、日本では基礎研究や大学教育に対し充分な教育を行っていないと指摘する。コンピュータや情報システムに関して、貧弱な教育しか行ってこなかった結果、日本のソフトウェア企業は、従業員の大部分をOJTで教育していると指摘する。

その結果、ソフトウェア開発は主に製品製造過程での課題の一つとして扱われるようになった。いくつかの例外を除くと、筆者がよく知っている日本の大企業は、経験則、プロセス上の統制、いくばくかの資本、そしてマンパワーによって、大規模システムに取り組んできた。文字通りの「ソフトウェア・ファクトリー」なのである。

ソフトウェア・ファクトリーという製造方式は、標準化された設計パターンに従い、元の条件からはほとんど変更しないカスタムアプリケーションを複数バージョンや、その亜流を大量生産することに向いている。一言でいうと「製造業」やね。与えられた「コスト」「納期」「品質」の中で、コストをいかに削減し、納期をいかに短縮し、品質をいかに高めていくかを追求することが至上命題というワケ。

「そんなことアタリマエじゃねーか!」というツッコミ上等。ワタシ自身もそう思ったから。しかし、そこには「ビジネス」という観点が抜け落ちている。ビジネスというと語弊があるなら商売といいかえてもよい。次の例で考えてみよう。

【例題】サービス開始直前に機能の追加を要求する顧客がいる。当然のことながら当初の仕様書にないことを要求してくる。

【解答?】ビジネスとしての視点があるなら、その機能が(サービス開始直後に)無いことで、何ドルの損失があるのか、サービス開始に間に合うことで何ドルの利益をもたらすか、という問いかけをするだろう。そして、理不尽な要求(?)をする顧客もいくらいくらであると回答しようとするだろう。

日本でもちょっと商売っ気のあるSE・プログラマだとこんな話のもって行き方をするが、おそらく良くてプライオリティ付や裏取引、悪ければ感情論や根性論に陥る。仕様書にない要求を直前になって言い出す客がいるのは米国も日本も同じ。その対応の差がソフトウェア「ビジネス」とソフトウェア「ファクトリー」の差だ。

日本には、良いもの(優れたもの・効率よく・高品質なもの)を作ろうと心がけて仕事をするプログラマは沢山いる。しかし、儲かるものを作ろうと考えながら仕事をするプログラマは皆無だろう。「このプログラムで大もうけしてやろう」とニヤニヤしながらビルドする奴がいたらちょっと不気味だが、その数は米国の方がはるかに多いに違いない。

(つづく)

--
[注1] 「ものまね師」を知らないよいこに説明しよう! 「ものまね師」とはファイナルファンタジーVのジョブ(職種)の一つ。転職はかなり大変だがものまね師は、前のキャラの動作をそっくり真似をする特殊技能「ものまね」を持つ。これが重宝するんだな…って、もう古典だねっ>FFV

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

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

ソフトウェア企業の競争戦略の原則は製品を売ってサービスで儲けることに尽きるよ、という話。とてもあたりまえなことなのだが、意外と見落とされている古くて新しい視線。

これは「ソフトウェア企業の競争戦略」でガツンと思い知らされた。本書によると、生き残るソフトウェア企業はすべからく「製品→サービス」へ変遷をとげているが、完全にサービスに移行するわけではないという。製品とサービスが半々のハイブリッド形態を呈する。「製品」と「サービス」の違いとは、

製品サービス
一過性
「パッケージ」というオブジェクトで提供
コピーしやすい
規模の経済が適用できる
新規に市場に参入しやすい
あたればでかいが、なかなかあたらないのが現実
持続性
形(オブジェクト)を持たない
コピー困難
顧客増→コスト増
市場参入に一定の評価(ブランドともいう)が必要

たとえばネットゲームの例。かつてゲームメーカーは「メーカー」の名の示す通りパッケージ製品を開発し、世に送り出していた。現在ではパッケージの名を持つオンラインゲームサービスを提供している。ファイナルファンタジー・オンライン(FFXI)やウルティマ・オンライン(UO)などが有名。

パッケージ製品には、規模の経済を適用することができる。ゲーム一本の開発費に莫大な資源を投じても、いったん「製品」ができあがれば、そのコピーを作るのは容易。ソフトウェアは目に見えないが、「パッケージ」というモノとして切り取られた形なので、売るほうも買うほうも扱いやすい。言い換えると模倣もコピーも容易のため、亜流や海賊版に悩まされることになる。

一方、オンラインゲームサービスは、提供しつづけていく必要がある。作って売ったらお終いではない。「製品」のコピーにかかる費用は、作れば作るほどゼロに近づくが、「サービス」は提供先が増えれば増えるほど、その費用は増大する[注1]。ソフトウェアは目に見えない上、サービスもさらに目に見えない(モノとして存在しない)。サービスを評価するためには一定の期間が必要で、良し悪しの判断は難しい。製品同様、ヒット作の亜流は存在するが、その「サービス」までもコピーすることは不可能。

「ファイナルファンタジー」というゲームに着目してみる。昔はパッケージ(カートリッジやCDのROM)形態で売り出されていた。「大作主義」と呼ばれ、美麗なグラフィックやムービーに莫大な費用をかけていた。一本一本のコストがでかい分、外れた時のリスクが大きく、社としての屋台骨をゆるがすほどだったらしいく[注2]。

現在では FFXI という名でネットゲームサービスが提供されている。作っては売り、作っては売りするのではなく、ネットを通じてひとつのゲーム世界をレンタルする。不具合や世界の広がりは、パッケージのバージョンアップではなく、メンテナンスにより実現する。

もちろんインターネット環境の整備やリッチクライアントの普及に負うところが大きいが、製作元の利益を得る方式の転換と見たほうがよいだろう。一本のゲーム(=プロジェクト)にコストとリスクを積み上げるよりも、「ファイナルファンタジー」というサービスブランドで長く売っていく方が得策だと判断したに違いない。

本書では、ゲームメーカーをリサーチの対象外としている。「ソフトウェアビジネスモデル」にはそぐわないらしい…が、同様のことは Oracle や Microsoft にも言える。両社はその看板製品のバージョンアップを繰り返しつづける一方で、その製品を元としたサービスを長く売っていこうとするだろう。単なるDBやOSではなく、継続的なサポート/サービスを必要とするアプリケーションサーバを販売の中核に据えていることがその証左といえる。

製品でシェアを確保し、サービスで恒常的に利益をうみだすビジネスモデル。これ最強(というか、これしかない)。「製品だけ」あるいは「サービスだけ」に注力する場合、ビジネスとして継続的に続くことは、ない。

言い換えると、スゴい製品を開発し、市場で大ヒットしただけでは、大もうけするかもしれないが、恒常的な利益を得ることはできない。また、スゴい技術を持っていて、そのサービスが大いに期待されているだけでは、利益を全く得られないまま風化するリスクは多々ある。いずれの場合も、ビジネスとして成立させるためには不十分。片方だけを引っさげて颯爽と参入するベンチャーは多々あれど、ビジネスとして成立しないまま上場資金を食いつぶして消えてゆく。

ベンチャーの流れは絶えずしてしかももとの社名にあらず
IPOに浮かぶボロ株はかつ消えかつ結びて久しくとどまりたるためしなし

(つづく)

--
[注1] もちろんオンラインゲームもパッケージ「製品」という形で有償/無償問わず頒布していることは合点承知。しかし、その「製品」単品だけでは充分遊べないことも事実。

[注2] 大作主義 … 死語なのだが、もはや死語ですらないかも。某社の「シェンムー」のように一本のゲームに社運を賭けるのは無謀かと。

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

正しいorz

ここを見てキミも正しいorzをマスターしよう。ポーズとっている女性がなんかエロい。

  1. ハダシになる
  2. 両手とひざで体を支える。このとき、肩の真下に手が、腰の真下にひざがくるようにする。肩甲骨-背骨-腰が一直線になるようにイメージする
  3. そのまま息を吸い込みながら、床を押す感じで、背中をぐっと反る(牛のポーズ
  4. 次に息を吐きながら、頭を落として背中を丸める。お尻を落とす感じで(猫のポーズ
  5. 呼吸を整えながら牛のポーズと猫のポーズを繰り返す

コツは尾骨にシッポがあることをイメージしながらシッポから動き始めると良いらしい。やってみると、腰がスゴく楽になるるる~ 腰でお悩みの方はぜひお試しあれ。

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

委譲できるのは権限までであり、責任は分担できない

PMの孤独感とは、プロジェクトマネジメントの成功・失敗の責任を負うのは自分だけなのだという認識からくる。仕事量を減らすため、マネジメント対象(スコープ・スケジュール・コスト・リスク・人材)ごとに担当を割当て、権限を委譲すればよいとアドバイスされるが、委譲するのは権限だけであって、責任まで分担することはできない

たとえば extends を使ってスーパークラスの性質を継承させることができる。サブクラスに振る舞いを「委譲」しているわけだ[注1]。振る舞いが問題ないことはスーパークラスが保証する。この場合、責任はスーパークラスが負っている。

あるいはアサーションを使って契約によるプログラムを徹底させる。事前/事後条件(の完全さ)をプログラムに組み込むことで、責任を外出しにすることができる。この場合、責任はそのクラスを使う側が負っているといえる。

しかし、マネジメントについて言えば、事前条件も事後条件も最終チェックするのは責任者であるあなただ。たとえ成果物をチェックする機構を取り入れるとしても、その機構の妥当性そのものを確認したり、そこでチェックOKとなった成果物を受け入れるか否かの最終判断を下すのは、やっぱり責任者であるあなただ。

権限を担当に割当て、担当を人に割当てることで、「その担当としての責任」があるじゃないか、という反論は可能。ただ、誰にどの権限をどこまで割当てるかもPMの仕事になっているため、人材と担当のミスマッチによる失敗もPMの責任と化す。担当としての最後の言い逃れは「指示どおりにやったのですが…」だが、PMには使えない。

ここで誤解されるのが「責任者」。責任者は責任をとるために存在するのであって、それ以外の何者でもない。いかなる前提の下であれ、サインしたのなら責任を取れ。逃げるな。責任を取ることがどういうことなのか分からないのであればサインする資格なんて無い。仕事割りやダンドリが得意なだけでPM目指してるそこのアンタ! …というのは実はワタシだったりする。

理論も実践も精進が必要。「がんばれ受験生」の季節になると思い出す。むかし「大人はいいなー勉強しなくてもいいから」などとほざいていたが、オッサンになった今の方が勉強している。勉強だけで「責任を引き受けられる人」になれるとは、これっぽっちも思ってないが、「勉強してない責任者」ほど恐ろしいものはない。

頑張れ俺、もっと頑張れ

--
[注1] 本来の意味での委譲(Delegation)は継承と異なることは合点承知之介

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

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

この企業の社畜として、自己の立ち位置を再確認するために読んだのだが、結局のところ、ど真ん中の一冊になった。「ソフトウェア企業の競争戦略」を紹介していただいたこの記事に感謝。好川さん、ありがとうございます。ソフトウェアでメシを食べている人は必読だろうなぁ…。理由は次の通り。

ソフトウェア・ビジネスが一般のビジネスと違いが無いのであれば、本など書く必要がない。この本は「ビジネス」としてみた場合の「ソフトウェア企業」を冷徹な視線で語っている。ソフトウェア・ビジネスとして成立させるために必要なことは「製品とサービスのハイブリット形態」なり。製品は市場に参入し、シェアを確保するため、サービスは恒常的な収入を得て、好不況の波を越えていくために必要。マイクロソフト、IBM、オラクル、SAP、シーベル、i2テクノロジーズの例を挙げて、その必要性を詳細に語っている。

世界と比較して、日本のプログラマは優秀か? 答えはYes[注1]。日本のプログラマの品質は、世界最高の水準か、それ以上だという。プログラマは優秀なのに、日本のソフトウェアビジネスがパっとしない理由も書いてある。それは品質重視の工場型モデルを(相も変わらず)採用しているからにほかならない。「良いものを作れば売れる」主義を信奉するあまり、ビジネスの本質から離れてしまっているらしい。

例えば欧州企業にとってソフトウェアは「科学」として扱われる。コンピュータサイエンスとしての「ソフトウェア・ビジネス」であるがゆえに、形式的手法やオブジェクト指向分析・設計手法が重視される。また、米国企業にとってソフトウェアは「ビジネス」そのものとして扱われる。会社をつくって「まぁまぁ良質」の製品を作り、業界標準を打ち立て、その過程で大儲けしようとたくらむ。

しかし、日本企業にとってソフトウェアとは「工場出荷製品」そのもの。文字通り「ソフトウェア・ファクトリー」を目指している。標準化された設計開発工程に則り、仕様からほとんどブレない製品を粛々と出荷することを随一としている。「良いものを作れば必ず売れる」信者の松下イズムが蔓延しているため、ソフトウェア・ビジネスの最もメジャーな課題「何が欲しいのか分かっていない顧客に売る」ビジネス視点が抜けている。

「ソフトウェア企業を創って世界のルールを変えてやろう、その過程で大儲けしてやろう」ことがヤれるのは、米国だけなり。でも、沸騰しまくっている米国でヤっていけるのかも、やっぱり書いてある(つづく)

--

[注1]なにを根拠に「世界」というか? 筆者の研究(っつーかフィールドワーク)は以下の企業を対象としたらしい。日本、米国、欧州、インドの主なソフトウェア企業だろう(もちろん漏れているのも多々ある)。


 マイクロソフト
 IBM
 NEC
 富士通
 日立
 オラクル
 SAP
 シーベル
 i2テクノロジーズ
 ビジネスオブジェクツ
 タタ


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

« 2005年1月9日 - 2005年1月15日 | トップページ | 2005年1月23日 - 2005年1月29日 »