2005 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
2014 1 2 3 4 5 6 7 8 9 10 11 12
2015 1 2 3 4 5 6 7 8 9 10 11 12
2016 1 2 3 4 5 6 7 8 9 10 11 12
2017 1 2 3 4 5 6 7 8 9 10

ホーム

2012年01月05日

つくるを超えて」と「ソフトウェアの価値」は、自分がしゃべり
ながら見せるための資料だから、これだけ読むだけだとわかり
にくいかもしれない。ということで、ちょっと補足説明を。

自分らソフトウェア開発者は何のためにソフトウェアを作るのか?
というのがまずあって。

作るのが楽しいっていうのもあるんだけど、それだけじゃない
でしょっていう。作るのも楽しいけど、作ったものが誰かに
使われたほうがもっとうれしいでしょ、っていうのがあって。

使われるっていうのは、実用的なソフトウェアなら役に立つって
いうことだし、ゲームとかなら遊んでくれるっていうことだし。

で、顧客っていう言葉ね。アジャイルなんかでもよく出る言葉
なんだけど、これが結構やっかいで。

厳密にいえば、お金を出す人と、使う人はおんなじじゃないでしょ、
っていう。で、アジャイルなんかだと顧客を絶対視する風潮が
あるわけね。まぁ、それで間違ってるわけじゃないんだけど。

でも、自分ら開発者は、お金を稼ぐためっていうのももちろん
あるんだけど、それだけじゃなくってね。最初の話に戻るけど、
やっぱり使われるためのソフトウェアを作ってるわけでね。
お金出してもらっても、使われないソフトウェアを作ってるんじゃ、
何やってるかわかんない。そんなんだったら、空っぽのCD-ROM
でも納品してりゃいいじゃんっていう話になるし。

だから、作る側とすれば、お金を出してくれる人よりも、
使ってくれる人を大切にしたい。

もちろん、このへんも一筋縄じゃいかなくって。海賊版とか
使ってる人とかね。そういうのはもちろんカンベンしてほしいし。
あと、オープンソースとかなら、そもそも顧客なんて話を
持ち出すことさえできない。

まぁ、そんなふうにいろいろあるわけだけど、単純に、青臭く、
使われることを重要視しましょうっていう話。

で、使われること重視っていうのは、作る側にとっていろいろと
都合がいいわけ。

作る喜びっていうのは、作る人間同士でなきゃ共有できないんだけど。
でも、使われる喜びなら、ソフトウェアやそれを含むシステムを
提供する組織全体で共有できる。営業とも社長とも共有できる。

自分らはもちろん作りたいっていう思いがあって。営業のほうは
売りたいっていう思いがあって。それですれ違いが起こったりも
するんだけど、使われたいっていう思いは共通してるし、共有
できるわけね。

で、使われ方にもいろいろあるんだけど。1回しか使われない
よりも何回も使われるほうが、一人に使われるよりもたくさんの
人に使われるほうが、ソフトウェアの特性に合ってるでしょう、
ということ。

だから、単に使われるソフトウェアを作るわけじゃなくって、
長く広く使われるソフトウェアを作りましょう、という結論になる。

で、長く広く使われることを目標にするんだから、できるだけ
そこから活動を導き出したり、ある活動がその目標と矛盾しない
ことを説明しましょう、っていうことになる。

たとえば保守性。不具合が出たときに対処しやすければ、長く
使ってもらえることになるから、保守性は善ということになる。

たとえば移植性。多くの人に使ってもらえることになるんだから、
移植性は善ということになる。これなんかは顧客重視だとかなり
遠回りな説明が必要になる。

最後に「東京砂漠」の歌詞を載せてるけど。現実が砂漠だとしても、
使ってくれる人がいれば、作る人間はやっていけるよね、っていう。
使ってくれる人がいなければ、それは砂漠どころか闇の世界でしょ。

ここまでが「つくるを超えて」の補足。

--

次に「ソフトウェアの価値」の補足。こっちはそんなに説明の
必要もないんだけど。

ソフトウェアの価値の捉え方として3つくらい、オマケでもう
1つくらい考えられるんじゃないかっていう話。

* 原価
* 利用効果
* 利用時間

原価は、商売やるんなら絶対必要なことで、計算できる話。
人月がダメだ云々いっても、避けられる話じゃない。

で、利用効果なんだけど、顧客を絶対視する人たちは多分これを
ソフトウェアの価値と呼んでる。彼らが価格のことをいってないのは
明白だし、彼らがよく口にする顧客満足度という得体の知れなさは、
経済効果という得体の知れなさと共通しているところがある。

で、利用時間。これは「長く広く使われること」を言い換えただけ。
Webサービス方面だと顧客生涯価値なんていう言葉もあるけど、
そういう計測できるような生々しい話だけじゃなくってね。

* 期待価値

これは結構つっこまれる話で。それだけスキの多い話でもあるん
だけど。今自分らが作ってる製品には、まだ見ぬ次の製品への
期待が込められているという話で。

今あるユーザにある製品を満足に使ってもらえてなければ、次に
作る製品が同じユーザに選ばれて使われる可能性は低いでしょう、
っていう当たり前の話なんだけど。

で、まぁ、もちろん、品質の話もあるんだけど。あ、ここでいう
品質っていうのは計測できる類の品質。仕様を満たしているとか
そういう話ね。

で、そういう品質っていうのは、期待価値としては低いんじゃ
ないかっていうのが、この期待価値の話の本論っちゃ本論なん
だけど。

今のユーザが次の新製品を選好してくれる鍵となるのは、今の
製品がユーザの期待を上回ってることなんじゃないか?っていう
仮説ね。仮説だよ。それをサプライズという言葉で表現した。

もちろん、商品の選好の要因は他にいくつもあるし。広告とか、
口コミとか、レビューとか。ただ、そういうのは自分ら作る側の
人間には手を出せない話だし。

企画の段階とかの話もあるしね。そういうわけでツッコミ所の
多い話ではある。

--

あ、あと、なんだっけな、製造業的視点とサービス業的視点
だっけ?

ソフトウェアってのは原則的に経年劣化しないものなのね。
それがハードウェアとの大きな違い。

ソフトウェアだとバージョンアップっていうのがあるけど、
あれは経年劣化と比べたらかなり恣意的なんだよね。

だから、ソフトウェアの特性として、リリースした時点から
価値が減じないっていうのは当たり前の話なわけで。

「つくるを超えて」の中でも話したけど、ソフトウェアの
特性に合わせて活動するっていうのが大切なわけで。

その特性を前提にビジネスモデルをどう組み立てるかっていう
話だと思う。

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails