未来のいつか/hyoshiokの日記 このページをアンテナに追加 RSSフィード Twitter

2006-02-25

hatenalabo

はてなラボサービスhttp://hatena.g.hatena.ne.jp/hatelabo/20060221/1140521491と言うのは何がなんだかよくわからないのだが、なんとなく面白そうという感じのものだ。だけど、ヘルプも何もついていないので使い方が正直よくわからない。

さっそくLife is beautiful (http://satoshi.blogs.com/life/)さんが噛み付いた。いわく「50%の完成度でサービスを出す」という言葉を誤解してはいけないである。(50%の完成度でサービスを出すも参照のこと。http://d.hatena.ne.jp/jkondo/20060222/1140588819もね)

おっしゃる通りである。おっしゃる通りであるが、ちと週末考えてみた。

昔、シリコンバレーにいたころわたしのソフトウェア開発に関する思いを根本的に変えたことの一つが、「ソフトウェアはそこそこでいいのよ」という書いてしまうと身もふたもない原理原則のようなものである。一応、日本に育ち、日科技連のソフトウェア品質管理のセミナー(http://www.juse.or.jp/software/index.html)なんかに参加して勉強したものである。バグゼロのソフトウェアを目指して日夜がんばるという姿である。製造業で成功した高品質を保証するプロセスを実践すると言うアプローチだ。日本にもソフトウェア産業があったかもしれない80年代

ソフトウェアの品質を「顧客満足度」だと定義すれば、「品質」をバグがないと言う風に矮小化したところに「日本的なソフトウェア品質論」の限界があったような気がする。バグがないことを保証するために、徹底的に仕様レビューし、あいまいさを一切否定する。そしてテスト項目を大量に作成し工場化したチームがそれを淡々と消化していく。このプロセスをQC(品質コントロール)の手法によって推進する。製造業で成功したこのプロセスがなぜソフトウェア産業では成功しなかったのか。

上記のプロセスウォータフォールモデルという名前で知られているが、結局のところ顧客の望んでいるものを上記のプロセスでは作成できなかったことにつきる。仕様に100%合致したソフトウェアを低コストで仮に製造できたとしても、その仕様が必ずしも顧客の望んでいるものでなかったとしたら、せっせと誰も望んでいないものを作っていたという皮肉な結果がある。

ソフトウェアバグに対する姿勢というのが、まあないほうがいいのであるが(当たり前)、それを絶対あってはならない金科玉条のものとは考えないというような、非常にアバウトな姿勢がある。誤解しないで欲しいのだが、ソフトウェアに対していいかげんな姿勢をとっているのではない。むしろ非常にまじめに取り組んでいる。その取り組む情熱の先がバグをせっせと潰すのではなく顧客の要求に真摯に向き合う姿勢である。バグはなくならないし、バグなしのものを作ると言う隘路にぽっこりはまるのではなく、その情熱を顧客の声を聞き、どんどん製品を改良していくと言うアプローチである。

ひたすらバージョンアップをしていく。製品のロードマップもアバウトなものはあるが実は市場と対話しながら作っていくと言うような感覚だ。完璧なものを目指して永遠に市場に投下できない幻を作るのではなく、ラフなコンセンサスと動くコードと言うインターネット時代(あるいはオープンソース時代)の原理原則を実践したチームが勝つ。そんな感じである。

で話をもどして、はてなラボサービスである。ヘルプもないものをサービスするな(怒)みたいなニュアンスを感じなくもないが、Web2.0の時代、利用方法を規定するのは提供者ではなく利用者側なのではないかなあ、ある部分。利用者というと言いすぎかもしれないけど、サービス提供者、参加者とともにそのサービスの価値が高まっていくというようなプロセスで、その意味で使い方を発明していくのは利用者であり、その使い方を説明するのは提供者ではなくて利用者側にイニシアティブが移るのではないかなあと妄想する。http://b.hatena.ne.jp/entry/http://wordlink.hatelabo.jp/イニシアティブというかある種の重心がより利用者側に移動しつつあるような気がする。

まあ、ベースとなるインフラとしてのスケーラビリティとか信頼性というかその手のものは確実に担保した上でサービスそのものは利用者の意見を聞きながら非常に速いスピードで開発していくと言うのが今風という感じがしている。サービス提供者によるヘルプがないと言うのはアーキテクチャ的な欠陥とはいえないなあと思う。まあ、程度問題であるというのは、わかるのだけど、はてなスタッフには生暖かくがんばってほしいと思う今日この頃である。

あ、そうそうミッションクリティカルシステムにおいては日本的な品質保証の優位性というのはあると思います。

pandorapandora 2006/02/26 04:01 初めてコメントを書きます。
「ソフトウェアはそこそこでいいのよ」辺りへのコメントです。実は、うむうむとうなずいてしまいました。2001年頃にシリコンバレーのベンチャー企業と仕事をした時、米国側のCEOと日本側のプロデューサーとの間に、「そこそこ」に差があると感ていました。米国側はサービス提供一番(品質が一定レベルをクリアーした、リリースのスピード)、日本側は完璧(バグ無し)一番、という風でした。(あれ、軸がボケているかしら?)

hyoshiokhyoshiok 2006/02/27 09:57 pandoraさま、コメントありがとうございます。この差というのは結構大きいような感じがしていますが、双方そこに差があるという認識をしていないので、話がすれ違ってしまうということが多々あるような気がしています。

snowsnow 2006/02/27 12:51 以前にアメリカでソフトを作っていた時の経験ですが、あちらの人はあまりソフトの不具合を気にしないように思います。仮にバグが残っていても「仕方ないなぁ」という顔をするだけで、日本のようにガミガミと文句を言われることは少なかった気がします。もちろん、ソフトの市場や製品の内容にもよるのでしょうけど。

hyoshiokhyoshiok 2006/02/27 21:36 snowさま、コメントありがとうございます。確かにそんな印象がなぜかありますね。なんでなんでしょう?

okushiokushi 2006/09/20 12:15 ビジネスとして見た場合、落としどころというのはもの凄く重要な判断だと思います。確かにバグゼロが理想的ですが、それで出荷が遅れてマーケットを追従するようになってしまっては元も子もないので。。見つかったバグのインパクト度(??)を正確に判断して直すものを直さないものを分けるという勇断も大事なのでは、、と。その辺の判断が出来ていなくて不必要にリリースまでの時間がかかる日本の取引先を見たことが何度もあります。具体的には、バグは全部直せー、、と言うからこっちは数を減らすために直せるものから直します。ですが、しばらくすると先方も出荷の期日があるので、release criticalなバグを直して出荷、、みたいな話をしてきます。ですが、この段階では直せるバグを優先したために難しいバグ、大抵はrelease criticalなのが残ってしまっているんですよね。最初から直さないと出荷出来ないバグと直せたらいいなぁのバグに分けて、リソースを割り振ったら期間内に終わったものなのに、、って。

hyoshiokhyoshiok 2006/09/20 12:56 okushiさま、コメントありがとうございます。古いエントリーを発掘いただいていうれしいです。
直せるバグと直さないといけないバグというのは独立の事象なんですが、人間やすきに流れますから直せるバグからせっせと直しちゃうんですよね。正しいプロジェクトマネジメントは直さなくちゃいけないバグを直させるんですけど、そーゆーのをちゃんと理解しているマネジメントが少ないのでしょうね。