ビジネスとしてのソフトウェア開発
「わたしが知らないスゴ本は、きっとあなたが読んでいる」 さんの「「ソフトウェア企業の競争戦略」読書感想文」シリーズが面白い。
後でもう一度まとめて読むために気になった箇所をメモしておく。
ビジネスとしてのソフトウェア開発
「わたしが知らないスゴ本は、きっとあなたが読んでいる」 さんの「「ソフトウェア企業の競争戦略」読書感想文」シリーズが面白い。
後でもう一度まとめて読むために気になった箇所をメモしておく。
「例えば欧州企業にとってソフトウェアは「科学」として扱われる。コンピュータサイエンスとしての「ソフトウェア・ビジネス」であるがゆえに、形式的手法やオブジェクト指向分析・設計手法が重視される。また、米国企業にとってソフトウェアは「ビジネス」そのものとして扱われる。会社をつくって「まぁまぁ良質」の製品を作り、業界標準を打ち立て、その過程で大儲けしようとたくらむ。
しかし、日本企業にとってソフトウェアとは「工場出荷製品」そのもの。文字通り「ソフトウェア・ファクトリー」を目指している。標準化された設計開発工程に則り、仕様からほとんどブレない製品を粛々と出荷することを随一としている。「良いものを作れば必ず売れる」信者の松下イズムが蔓延しているため、ソフトウェア・ビジネスの最もメジャーな課題「何が欲しいのか分かっていない顧客に売る」ビジネス視点が抜けている。」
「製品でシェアを確保し、サービスで恒常的に利益をうみだすビジネスモデル。これ最強（というか、これしかない）。「製品だけ」あるいは「サービスだけ」に注力する場合、ビジネスとして継続的に続くことは、ない。
言い換えると、スゴい製品を開発し、市場で大ヒットしただけでは、大もうけするかもしれないが、恒常的な利益を得ることはできない。また、スゴい技術を持っていて、そのサービスが大いに期待されているだけでは、利益を全く得られないまま風化するリスクは多々ある。いずれの場合も、ビジネスとして成立させるためには不十分。」
CNETの記事「「iPodは単なる流行りモノ」--デルCEO、アップルをこきおろす」にあった、「一発屋はブームを巻き起こしては消えていく。必要なのは持続性のあるビジネスモデルであり、持続性のある戦略だ」という言葉を思い出した。
「日立、富士通、NEC、東芝、NTTのようなメジャーなソフトウェア企業は、主にハードウェアやサービスを販売するためにソフトウェアを書いているのであり、これはIBMが数十年にわたりたどってきた道にほかならない。」
「その結果、ソフトウェア開発は主に製品製造過程での課題の一つとして扱われるようになった。いくつかの例外を除くと、筆者がよく知っている日本の大企業は、経験則、プロセス上の統制、いくばくかの資本、そしてマンパワーによって、大規模システムに取り組んできた。文字通りの「ソフトウェア・ファクトリー」なのである。」
「利益を意識して仕事をする人がいない
問題はここにある。なんちゃってSEや駄目プログラマや能書きマネージャが問題なのではない。そんな奴ぁ日本に限ったことではない（ディルバートを見よ！）。一部のグズが全体の足を引っ張っているなんて、ソフトウェア産業に限ったことですらない。
ソフトウェア「ビジネス」として成立させるための努力を措いといて、「コスト」「品質」「納期」の徹底さえできれば良しと考えている経営が真の原因なり。もちろんそれらは重要だが、ビジネスとして必要なのは、利益を出す、しかも出しつづけること。先に述べた「製品を売って、サービスで稼ぐ」しくみを続けていくこと。」
「筆者は Windows95/NT/2000 および MS-Office シリーズの開発スタイルを分析し、一つのベスト・プラクティスを導き出している。筆者は「同期安定化プロセス」と名づけている。第4章「開発のベスト・プラクティス」でその詳細な説明があるので、開発手法やマネジメント手法にお悩みの方は読むと得るものがあるかも。」
「複雑で大規模なプロジェクトを、多くの人員を投入し、同時並行で進める。しかも変更が大いに発生することは予め分かっている。マイクロソフトは同時並行して作業を進めながら、たえず同期を取るプロセスを適用することで、この問題に対処した。」
「日本（やIBM）を代表とするソフトウェア・ファクトリーでは非常に詳細な仕様書を書く、と筆者は指摘する。それが柔軟な変更や素早い開発（あじゃいる?）を妨げていると断ずる。」
プログラマだってSEだって食い扶持稼ぐためにやっている以上は、ビジネス・・・というか、「儲けありき」という姿勢であるべきというのがここで語られている方向性だろうか。
# 引用元のDain氏から指摘があったので、下記に訂正。
「ソフトウェアに限らずビジネスとして成立させるには、持続的な儲けをつくる仕組みが必要」という主旨とのこと。
# 2005/3/22 *** 追記 ***
この感想文6についてはDainさんのところで発表された直後に引用しようとしたのだが、個人のキャリア話に意識が120%引っ張られ、話をまとめ上げきれなかった。そのまま、保留（という名の逃亡）をしてしまっていたので、追記する。
「何のためにVCがカネをよこすのかというと、リターンを望んでいるからだ。起業というリスクを一度負いながら新たに開発を始めてしまうということは、種銭を再ベットしてしまうことと一緒。まずいま起業したネタを売ることを考えるべきだろう。売るべきソフトウェアがあるのなら、その市場の顧客全てに売り続ける。一度作って、何度も売ることが極意。Javaの極意が"Write Once Run Anywhere" なのと同様だ。一方サービスで儲けることを目的とした起業だと、調達したカネは、豪奢なオフィスやマネージャ層の新規雇用や新たな販売拠点へと化ける。外部からの資金調達を得る理由は、内部でまかなうよりも、よりスピーディーに有望顧客や市場へ近づくためなのだ。いわばこれらは作られた富、身の丈にあっていないカネなのだろう。」
この話は、そのまま納得できる人は納得してもらうとして、納得できない人には「会社にお金が残らない本当の理由」をオススメする。岡本吏郎氏の本で、まさに「身の丈にあった経営の仕方」が書いてある。
以下、Dain氏の読書感想文へのまとめとして。
たしかに「製品でシェアを確保し、サービスで恒常的に利益をうみだすビジネスモデル。」は常に追求すべき真実だ。実際、Webベースの世界へ移っても同様の事象が見られる。
その点、Googleなんかはわかりやすい。まずはサービスでもって客をつかむ事。つかんだ所で、その集めたネットワークがお金を生み出すようなシステムを作っていく。
これは、「オープンソースに賭けるサン」というエントリで私が書いたGoogleのビジネスモデルだ。検索サービスという製品でシェアを確保し、その利用者への広告という利益を得る仕組みを作り上げることで、継続的な利益確保のモデルとした。
Webベースの世界の場合、Tim O'Reillyの"Open Source Paradigm Shift"で指摘されている、「シェアを握ることで利用者のデータが得られる」というメリットがあり、製品によるシェア確保の争いはより激しいものとなっている。
「製品」は無料で提供しシェアを握ることに集中する。そして、「恒常的に利益を生み出すモデル」の重要性はこれまで以上に高まるというわけだ。
これは、非常に重要な視点だ。まず、製品を提供する時点で最も重視すべきはシェアを獲得することだということ。そして、得たシェアを”継続的な”利益につなげるような仕組みを作り出す必要があること。
『「ソフトウェア企業の競争戦略」読書感想文2』で述べられている製品とサービスのハイブリッド形態とは、やや様相は異なるが本質的には同じである。この視点でビジネスを見直すと、色々と縛りとなっていたものが見え、非常に興味深い。
# 2005/3/22 *** 追記ここまで ***
クラフトマンシップ
一方で、ずっと気になってこっそりWatchしているのが、よしおか氏の「未来のいつか/hyoshiokの日記」にたまに現れる文章。
「プログラムは人が書く。いいプログラムは優秀なプログラマにしか書けない。人が全てである。そして優秀なプログラマが最も貴重な資源であるということについて、もう少し議論があってもいいと思う。価値を創造するのは機械ではない。生身の人間なのである。」
「開発者はいつの時代も不足している。そこそこの開発者はそこそこいるが優秀な開発者は常に不足している。
プログラムは機械が作るのではなくて人間が作る。」
「そこでいろいろ議論をさせていただいた。LPI事務局から与えられたお題は「今求められるオープンソース人材像」である。あ、そこのあなた、引かないでください。
- プロフェッショナル／コスモポリタン／チャレンジャー
- ソースコードレベルでの解析、コアダンプ解析
- 高いコミュニケーション能力
- コミュニティでの存在感
やはり高い技術力をもっていなければ話にならない。プロフェッショナルであることは最低必要条件である。技術に対するコミットメント、ロイヤリティ、真面目さが必要だ。広い視野で物事を考えるためにコスモポリタンであること。やはり地球規模での最適化を考えられないとね。何事にも挑戦する心を持って欲しい。
オープンソース開発者は当然ソースコードを解読できるしコアダンプのイロハも知っている。ダンプを読めない人は読めるように訓練を積もう。
オープンソースソフトウェアは多人数で開発する事が常なのでコミュニケーション能力も必須だ。仙人で人と没交渉で大規模ソフトウェアは開発できない。
そしてコミュニティで影響力を持ちたければ、そこでの存在感というのが必要になる。存在感って何だ？コミュニティメンバーからのrespectである。尊敬をどれだけ受けられるかという、人間力である。」
「日本の企業は、人材についてシステマティックに育てようと言う意図はないのではないか。ある程度社員をかかえて、状況が変わると手持ちの人材の中からその状況に向いていそうな人材をアサインする。そういう感じにすぎない。プロのいない世界だ。逆にプロになると潰しが利かないので定期的に異動があったりする。どちらかというと社内の業務を全般に把握しているジェネラリストを育てる体制だ。なので社内の調整はうまくいくようになる。働く側もプロになりすぎると潰しが利かないということを考える。
という御指摘は多分あたっているとは思うが、それが正しい姿だとはわたしは思わない。プロのいない組織は競争力がないから結果として市場から淘汰される。いや別にいいのだけど。」
「日本はいつの間にかにOSの開発者もいない、コンパイラの製作者もいない、RDBMS開発者もいない社会になってしまったのか？
日本のメインフレーマは、OS開発者やコンパイラ開発者やRDBMS開発者の雇用をほとんどできなくなって、その技術者達をSIの現場や営業やらに配置したが、技術立国たる日本はそれでいーのか？
そーゆー話である。
NECがスーパーコンピュータを歯をくいしばって作っているが、そーゆー技術の継承という観点から、技術開発をとらえられないか。そーゆー話である。儲からないからやらない、というだけでいいのか？そーゆー話である。
なんでもかんでも米国の技術に依存して自分で物を作る事をあきらめて、それでいいのか？そーゆー話である。」
ビジネスありきの考え方は当然だ。しかし、よしおか氏のような視点を軽視すべきはないとも思う。ケース・バイ・ケースと言ってしまえばそれまでで、技術の高さを重視するかどうかもビジネス判断の一変数だと言ってしまえば、たしかにそうだろう。
エンジニアとして、ビジネスマンとしての自分の姿勢というものは、どうあるべきなのか？特にここで結論めいたものがあるわけではない。どちらが良い、悪いという評価をするつもりもない。ただ、考え続けることだけは継続しようと思う。
