boyaki_a/00020
の編集
http://k.osask.jp/wiki/?boyaki_a/00020
[
リロード
] [
新規
|
編集
|
差分
|
添付
] [
トップ
|
一覧
|
単語検索
|
最終更新
|
バックアップ
|
ヘルプ
]
-- 雛形とするページ --
2012_09
ADSL
ADSL1
BarbaraDye@protonmail.com
Books
DVD-R
EPIA_series
EPM
FormatRule
FrontPage
Help
HomeBakery
HomeBakery2016
InterWikiName
InterWikiSandBox
InterWikiテクニカル
K
KHBIOS/0001
KHBIOS/0002
Lojban
MenuBar
OSA/imp060524
OSC_rule
PASS3
PASS3v1
PukiWiki
RecentDeleted
SandBox
SitePolicy
WattChecker
bank
banks
blogs
blogs2
boyaki_a
boyaki_a/00001
boyaki_a/00002
boyaki_a/00003
boyaki_a/00004
boyaki_a/00005
boyaki_a/00006
boyaki_a/00007
boyaki_a/00008
boyaki_a/00009
boyaki_a/00010
boyaki_a/00011
boyaki_a/00012
boyaki_a/00013
boyaki_a/00014
boyaki_a/00015
boyaki_a/00016
boyaki_a/00017
boyaki_a/00018
boyaki_a/00019
boyaki_a/00020
boyaki_a/00021
boyaki_a/00023
boyaki_a/00024
boyaki_a/00025
boyaki_a/00026
boyaki_a/00027
boyaki_a/00028
boyaki_a/00029
boyaki_a/00030
boyaki_a/00031
boyaki_a/00032
boyaki_a/00033
boyaki_a/00034
boyaki_a/00035
boyaki_a/00036
boyaki_a/00037
boyaki_a/00038
boyaki_a/00039
boyaki_a/00040
boyaki_a/00041
boyaki_a/00042
boyaki_a/00043
boyaki_a/00044
boyaki_a/00045
boyaki_a/00046
boyaki_a/00047
boyaki_a/00048
boyaki_a/00049
boyaki_a/00050
boyaki_a/00051
boyaki_a/00052
boyaki_a/00053
boyaki_a/00054
boyaki_a/00055
boyaki_a/00056
boyaki_a/00057
boyaki_a/00058
boyaki_a/00059
boyaki_a/00060
boyaki_a/00061
boyaki_a/00062
boyaki_a/00063
boyaki_a/00064
boyaki_a/00065
boyaki_a/00066
boyaki_a/00067
boyaki_a/00068
boyaki_a/00069
boyaki_a/00070
boyaki_a/00071
boyaki_a/00072
boyaki_a/00073
boyaki_a/00074
boyaki_a/00075
boyaki_a/00076
boyaki_a/00077
boyaki_a/00078
boyaki_a/00079
boyaki_a/00080
boyaki_a/00081
boyaki_a/00082
boyaki_a/00083
boyaki_a/00084
boyaki_a/00085
boyaki_a/00086
boyaki_a/00087
boyaki_a/00088
boyaki_a/00089
boyaki_a/00090
boyaki_a/00091
boyaki_a/00092
boyaki_a/00093
boyaki_a/00094
boyaki_a/00095
boyaki_a/00096
boyaki_a/00097
boyaki_a/00098
boyaki_a/00099
boyaki_a/00100
boyaki_a/00101
boyaki_a/00102
boyaki_a/00103
boyaki_a/00104
boyaki_a/00105
boyaki_a/00106
boyaki_a/00107
boyaki_a/00108
boyaki_a/00109
boyaki_a/00110
boyaki_a/00111
boyaki_a/00112
boyaki_a/00113
boyaki_a/00114
boyaki_a/00115
boyaki_a/00116
boyaki_a/00117
boyaki_a/00118
boyaki_a/00119
boyaki_a/00120
boyaki_a/00121
boyaki_a/00122
boyaki_a/00123
boyaki_a/00124
boyaki_a/00125
boyaki_a/00126
boyaki_a/00127
boyaki_a/00128
boyaki_a/00129
boyaki_a/00130
boyaki_a/00131
boyaki_a/00132
boyaki_a/00133
boyaki_a/00134
boyaki_a/00135
boyaki_a/00136
boyaki_a/00137
boyaki_a/00138
boyaki_a/00139
boyaki_a/00140
boyaki_a/00141
boyaki_a/00142
boyaki_a/00143
boyaki_a/00144
boyaki_a/00145
boyaki_a/00146
boyaki_a/00147
boyaki_a/00148
boyaki_a/00149
boyaki_a/00150
boyaki_a/00151
boyaki_a/00152
boyaki_a/00153
boyaki_a/00154
boyaki_a/00155
boyaki_a/00156
boyaki_a/00157
boyaki_a/00158
boyaki_a/00159
boyaki_a/00160
boyaki_a/00161
boyaki_a/00162
boyaki_a/00163
boyaki_a/00164
boyaki_a/00165
boyaki_a/0022
data/Clover
data/Clover/hrb_A
data/Clover/hrb_Clover
data/Clover/mail0000
data/Clover/mail0001
data/Clover/mail0002
data/Clover/mail0003
data/Clover/mail0004
data/Clover/mail0005
data/Clover/others
dev-j/THE-BBL/nanasi
ideas
ideas/s7st
ideas/tek3
ideas/tek5
impressions
index
isolations/osw_vga
k
k_in_TOMAMI
kclib1_0000
kclib1_0001
kclib1_0002
kclib1_0003
kclib1_0004
keng
khaba/memo001
khaba/memo002
khaba/memo003
khaba/memo004
khaba/memo005
khaba/memo006
khaba/memo007
klog
klog/comment03
klog/comment04
klog/comment05
klog/essay050
klog/essay051
klog/essay052
klog/essay053
klog/essay054
klog/essay055
klog/essay056
klog/essay057
klog/essay058
klog/essay059
klog/essay060
klog/essay061
klog/essay062
klog/essay063
klog/essay064
klog/essay065
klog/essay066
klog/essay067
klog/essay068
klog/essay069
klog/essay070
klog/essay071
klog/essay072
klog/essay073
klog/essay074
klog/essay075
klog/essay076
klog/essay077
klog/essay078
klog/essay079
klog/essay080
klog/essay081
klog/essay082
klog/essay083
klog/essay084
klog/essay085
klog/essay086
klog/essay087
klog/essay088
klog/essay089
klog/essay090
klog/essay091
klog/essay092
klog/essay093
klog/essay094
klog/essay095
klog/essay096
klog/essay097
klog/essay098
klog/essay099
klog/essay100
klog/essay101
klog/essay102
klog/essay103
klog/essay104
klog/essay105
klog/essays
klog/gfghh
klog/monologue0312
klog/monologue0401
klog/monologue0402
klog/monologue0403
klog/monologue0404
klog/monologue0405
klog/monologue0406
klog/monologue0407
klog/monologue0408
klog/monologue0409
klog/monologue0410
klog/monologue0411
klog/monologue0412
klog/monologue0501
klog/monologue0502
klog/monologue0503
klog/monologue0504
klog/monologue0505
klog/monologue0506
klog/monologue0507
klog/monologue0508
klog/monologue0509
klog/monologue0510
klog/monologue0511
klog/monologue0512
klog/monologue0601
klog/monologue0602
klog/monologue0603
klog/monologue0604
klog/monologue0605
klog/monologue0606
klog/monologue0607-12
klog/old1010
klog/oldk00
krdm0000
krdm0001
krdm0002
krdm0003
links
links/pc0000
links/prog0000
links/soft0000
math
math/00
math/01
math/02
math/03
math/04
math/05
math/06
math/07
math/08
math/09
math/10
mc
memo0001
memo0002
memo0003
memo0004
memo0005
memo0006
memo0011
memo0012
memo0013
memo0014
memo0015
memo0016
memo0017
memo0018
memo0019
memo0020
memo0020/old
memo0021
memo0022
memo0023
memo0024
memo0025
memo0026
memo0027
memo0028
memo0029
memo0030
memo0031
memo0032
memo0033
memo0034
memo0035
memo0036
memo0037
memo0038
memo0039
memo0040
memo0041
memo0042
memo0043
memo0044
memo0045
memo0046
memo0047
memo0048
memo0049
memo0050
memo0051
memo007
memo008
memo009
memo010
memo_dos
memo_opera
minimemo
miniquestions
nask/guide000
nask/guide001
notice
osalinks
osask_khb/memo001
osask_khb/memo002
oversampling
p2018
p20181020
p20181021a
p20181023a
p20181024a
p20181026a
p20181026b
p20181026c
p20181102a
p20181115a
p20181127a
p20181208a
p20181214a
p20190119a
p20190122a
p20190126a
p20190129a
p20190131a
p20190201a
p20190201b
p20190206a
p20190206b
p20190208a
p20190209b
p20190213a
p20190218a
p20190225a
p20190306a
p20190513a
p20190524a
p20190528a
p20190917a
p20191006a
p20191025a
p20191030a
p20191122a
p20191125a
p20191126a
p20191226a
p20200109a
p20200221a
p20200309a
p20200315a
p20200423a
p20200513a
p20200808a
p20200821a
p20211014a
p20211017a
p20211028a
p20211223a
p20220106a
pcmemo
physics
populars
prog/01
prog/02
prop/WaseiOs
quake
quake/jsedip
quake/jsedip/data
quake/jsedip/data05
rep_20061028
rep_OSC06_niigata
sam
sdk0000
sdk0001
sdk0002
sdk0003
sdk0004
spam/hrbwiki/rule
spam/kkiwi/boyaki_a
spam/oswiki/ASKA
spam/oswiki/VGA
spam/oswiki/qemu
spam/test
spysee
test_kor
travel
urls
videochips
ヘルプ
整形ルール
練習用ページ
20212021
* 「他人からの評価」中毒症 -(by [[K]], 2007.03.22) *** (1) 大学の心理学の授業で教わったこと -まだ小学生になるかならないかくらいの幼児(児童)にはたまに黙々とクレヨンで絵を描いている子供がいる。描けといわれて描いているのではなく、時間があるとのびのびと描いている。そしてたまにそれを母や父などの身近な人に見せる。その人はほめる「まあー、うまくかけたわねえー」。とてもほほえましい。 -このような幼児を集めて、2つのグループに分けたとする。AグループとBグループ。Aグループには、ただほめるだけではなく、そのときにその幼児の大好きなおかしを与える。ご褒美というわけだ。Bグループは今までどおり、言葉と笑顔と頭をなでるとかまあその程度止まり。 -そうするとAグループの幼児は変わる。どう変わるかというと、今までよりももっと強い熱意を持って絵を描くのである。いっぽう、Bグループは変わらない。まあ変えていないんだから変わらないのは当たり前である。 -さてここで、Aグループにさらに変化を与える。おかしをあげるのをやめて、以前どおり言葉と笑顔でほめるだけにするのである。そうするとどうなるか。Aグループの中に、絵を描くのをやめてしまう幼児が現れる。ただ以前の状態に戻っただけなのに、そして以前は誰に何も言われなくても楽しそうに描いていたのに、もう自発的には描こうとしないのだ。 ---- -このような実験が本当にあったのか、それとも別の類似の事例をモデル化したものかは分からない。またどの幼児に対してもこのような起きるというわけではないだろう。しかし傾向としてこの話は「確かにそういうことはありそうだな」と感じさせる。少なくとも僕はそう感じる。 *** (2) 他人からの評価を気にする人たち -この話から感じられることは、人は一度他人から強いプラスの評価を与えられてしまうと、本来持っていた自発的な意欲が減少し、他人の評価の得られないことはやめてしまう傾向があるということだろうと思う。あなたは似たような経験があるだろうか。もしくは周囲の人が似たような変化をしたのを見たことはないだろうか。 -最初は自発的かつ純粋な気持ちで自らの理想のOSを作っていたのに、ニーズがないからと方針を転換するというケースを見たことがある(このケースについて僕は詳しく語ることができないのでこれ以上具体的なことは言わない)。僕はその人に理想を貫いてほしいと思った。他人のニーズのためだけで開発していいのか。そんなことでまともなOSが作れるのか。ニーズに合わせていたら、ただ現状の問題を場当たり的に解決するだけのOSにしかならないのではないか。 -もちろん現状の問題の解決だって大切だから、そのことを否定するつもりはまったくない。しかし当初はより壮大な計画を持っていながら、ただ「ニーズがない」という理由だけで方針を転換してしまうのが残念なのだ。そもそも最初からニーズなんてなかったんじゃないのか。そのOSを使ってくれそうな人が現れて、その人があの機能はほしい、この機能はいらないというからそれに合わせ、気づいたら当初の目標のOSとはまったく別になっている。汎用性も損なわれ、あきらかにちっぽけで特定の問題の解決しかできないOSである。 -そして開発者当人がそんなことになってしまったことをくやんでいない。・・・これでいいのだろうか。 ---- -僕の経験では、誰かに使わせることを他よりも優先し始めたプロジェクトの半分以上はガラクタに成り下がっている(みんなで使うためのプロジェクトなんて最初からガラクタなことが多い)。ユーザなんか他にいなくていい、自分のために作ったもの、もしくは特定の知人のためだけに作ったものは、結果的によくなりやすい。それを「みんなにも使ってほしいから」と、本人には不要な機能を優先してつけたり、自分に必要な機能の優先順位を下げたりし始めると、退化が始まる。 -OS開発でよくあるのは、「新規に作っても互換性がないと普及しない。だから○○互換で作る」みたいな話である。確かに互換性はないよりあったほうがいい、それは間違いない。でももし自分ひとりで使っていくつもりならどうだろう。互換性がなくなって我慢できるのではないか。それにほかのOSを併用しちゃいけないということもないはずだ。だから既存のOSと自分のOSを併用すればいいじゃないか。既存のOSに不満を感じてなんらかの理想を打ち立てたのに、他の人に使ってもらえる見込みがないというだけの理由でその理想をあきらめていいのか。自分の信じる理想OS下で気持ちよく効率的なプログラミングをしたかったのではなかったのか。 --ちなみにOSASKの場合、僕は今もっているTOWNS用のソフトウェアなどを自作OS上でも使いたかったので、エミュレータを書くことにした。つまりこれは他人からの要求ではなく自分の内なる要求であった。 *** (3) 生計を立てていくという問題とのバランス -しかしまあ「生計を立てていく」ためには、誰かに買ってもらわなくてはいけないから、ユーザの意向を意識しなければいけないというのはやむをえない面はある。しかしそれでも、自分の理想を他人の評価にかまわずに作り上げ、それを他人がほしがるように見せびらかす、ことを夢見るべきではないのか。それで他人がほしがってくれなければ、価値観の相違だとか、時代の先を行き過ぎてしまったみたいだなと、割り切ることはできないのか。他人なんかどうせ近眼で問題の本質が見えていないのだ。そんな人に評価されないのが何だというのだ。 -生計を立てるために作るものは、最初からそれで行けばいい。それは仕方ないことだから問題はない。僕が気になるのは、猫も杓子も「ニーズ」「ニーズ」ということであって、現代の他人に使ってもらえなさそうだというだけで、自分の理想から出発した開発をためらいもなく捻じ曲げることなのである。せめて苦悩の上の決断であってほしい。・・・なんだかあまりにあっさりと他人向けに方針を変えられると、そもそもこの人はその程度の情熱で開発していたのかと興ざめしてしまう。強い信念を感じたから応援してきたのに・・・。 *** (4) 別のケース -これは未踏ユースやICTスクールでの経験に基づく話だが、デモや説明を聞く限り、「これのどこが面白いんだろうか」「そのアルゴリズムで本当にうまくいくんだろうか」みたいに疑問符がついてしまう開発にめぐり合うことがある。しかしそんなプロジェクトでも、とにかく開発者自身が強烈に面白がっていて、しかも多人数に普及しなくてもそれなりに使えるものは、聞いていて気持ちがいい。安心する。感じとしては、「おー、そこまで言い切るか。よし分かった。僕には良く分からないけどとにかく君たちにはこれが必要なんだな。信じてやろう。できたものをまた自信を持って見せてくれ。」みたいな感じだ。 -これに対して、「世間ではこういうものが求められていて、だからこれを作るといくつくらい売れて、みんなが使ってくれることでさらに理想的な効果が出て・・・」みたいな説明のときに、「うーん僕はそんなものほしくないし、その見積もりは甘い気がするなあ」みたいだと心配になる。実在しない具体的な例を言うと、できのよくないプログラマ初心者向けの学習ソフトである。どうみても学習意欲が続かなそうで、予定販売価格は高すぎで、当たり前だが本人たちはこんなもので勉強する動機がない、しかも本人の身近にこのソフトがあったら使いたいというテスターがいるわけでもない、という場合である。 -結局、上記の安心できたケースというのは、どこまでも主観的でかつ本人が使うように思えたから安心できたのだと思う。本人も使わない、他人も使いそうにない、なんてことになりそうだと不安なのだ。しかも開発者自身は他人が使ってくれるとなぜか思い込んでいて、自分に落ち度はないと思っているのだ。 *** (5) 自分以外のユーザを優先して迷走するケースその3 -これも実在しないケースだが、たとえばアイヌ語がすごく好きで研究しているアメリカ人がいたとしよう。この人が自分のために、アイヌ語の文章を入力したら自動でそれを文節に分けて、それぞれの文節をクリックするとそれが助動詞や助詞を含む場合はそれらも分割してくてくれるような、そんなソフトウェアを開発したいとしよう。 -この開発計画を世に出したとき、周囲の人とこんなやり取りをするかもしれない。「おもしろそうですね、開発動機は何ですか」「私は、アイヌ語が好きです。(ここでアイヌ文化のすばらしさを魅力いっぱいに語る。)だからもっとたくさんのアイヌ語を読んでいきたいです。でもいつも文節の区切りで混乱して苦労しています。だからこのようなソフトを作ろうと思いました」「なるほど、でもこれだけだと他の人にはアイヌ語が分かりません。開発者の○○さんは単語の意味が分かっているからいいかもしれないですが、単語の意味を英語でも表示できるようにならないでしょうか。というか文節なんかにわけた表示はアイヌ語を勉強する気がない私たちにはいりません。邪魔です。英文さえ出ればいいじゃないですか。そういうソフトにしてくれるのなら開発資金面で協力させてもらいますよ。」 -こうしてこのプロジェクトは迷走が始まる。当初の案であれば、なるほど他の人には使いにくいことこの上なかっただろうが、開発者当人にとってはそれで十分だったはずだ。それを妙に一般向けへ舵を切ってしまったために、開発が困難になり、完成しないか、もしくは開発までの道のりはかなり長くなるはずである。単語の意味を表示するというだけでも大変だ。なぜなら辞書を入力しなければいけないから。ましてそれをつなぎ合わせて英語の文章にまでするとなると、困難さはさらにあがる。 -開発者はアイヌ語の知識がそれなりにあったから、北国の動物や食物の単語の豊富さも理解して区別できていただろう。しかし表示されるのが英文だけになってしまうと、その微妙なニュアンスを楽しむことはできない。開発者にとってはこれは不満だろう。単語に切り分けてくれさえすればよかったのに、それは表示しないで、味わいを損なった英文だけが出る、と。こうして開発者当人にとっても必要のないソフトになる。 *** (6) おもしろ「そうな」という誘惑 -「おもしろそうなソフト」と「おもしろいソフト」は違う。開発前の説明がどんなに面白そうでも、できたものが面白くなるという保証はない。つまらなそうでも、つまらないとは限らない。だから面白くなさそうでも開発者当人が妙に自信を持っているのなら、それを信じて賭けてみることがあってもいいはずだ。なんといっても開発者がもっともそのソフトについて知っているのだから。 -僕たちに必要なのは、面白そうなソフトの開発を賞賛することではないはずだ、面白いソフトの開発を賞賛することなのだ。結果的に面白くないものができたときに、それを全て開発者のせいにするのはふざけていると思う。周囲の人たちが「こうしたら面白そう」とかいっていじくり回したせいじゃないか。でも周囲の人はその責任を全然とろうとしない。 -だから開発者は他人の意見を「時には」無視しなければいけないということを忘れちゃいけないと思う。時々は自分が「他人からの評価中毒症」にかかっていないかどうかを自問してほしい。他人からの要求ばかりではなく、自分の内なる衝動に応えて開発してほしい。 -そして周囲の人は自分の意見が開発者からあっさり撥ね付けられても文句は言わないでほしい。もししつこく文句をいうのなら結果を「保証」する覚悟をもってからにしてほしい。少なくとも1万ユーザ分のライセンスは買いあげるとか。 *** (7) まとめ -とにかく僕がここで言いたかったことは、当初は「自分のため、or自分の理想のため」に作っていたのに途中で方針を変えて他人向けにしようとするとたいていは失敗するということだ。そして最初から他人のために作る開発も、独り善がりな思い込みで作るととんでもない最悪のプロジェクトになりかねないよ、ということである。 -できることなら、まず自分の理想を実現して、その上で拡張や派生物として、他人向けを作ればいいのだと思う。 -そしてこの警告は、ソフトウェア開発のみならず、創作活動一般(絵画・作曲・陶芸・学術研究などなどなど)にも応用可能だと僕は信じる。 *** (8) 違うんだけど似ている話 -たとえば2人の記者がいたとする。一人は、読者の声を精力的に集めて聞き、読者の望む人へインタビューをするような記者。もう一人は、とにかく自分のセンスでたくさんの人にインタビューしてみて、これはいい!と思ったものだけを記事にする記者。・・・どちらももちろんすばらしい記者だと思う。 -でもあえてどちらがいいかといわれれば、僕はやっぱり、後者の「自分のセンス」に頼る記者がいい。そういう記事を読みたいし、そういう記者でありたい。 -読者に合わせるのは、あまり創造的ではない気がする。言い方は良くないけど、なんというか、誰にでもできるというか。まとまりもなくなりそうだ。・・・自分のセンスで推す場合、まとまりがないということは多分ないけど、記者と読者の完成がかみ合わなければ、はっきりいってぼろぼろの評価になるだろう。でもそれでいいじゃないか。 -つまり読者に合わせて記事を書くだけだと、70点くらいの記事になるんだろう。一方、自分の感性の命ずるままに、「これこそ伝えるべきだ」という基準で記事を作って行くと0点か100点かのどちらかになるんだろう。 ---- -ここまで書いて自分を振り返る。なるほど僕はプログラムや本を書くときには、この「自分の感性」でおしまくっている気がする。いや他人の声をまったく聞かないわけじゃない。でも聞いてみて僕が賛同できなければ(=その考えが僕のものにならなければ)、結局は受け入れない。平均化するよりは、どちらかに尖らせる。 *** こめんと欄 #comment
タイムスタンプを変更しない
* 「他人からの評価」中毒症 -(by [[K]], 2007.03.22) *** (1) 大学の心理学の授業で教わったこと -まだ小学生になるかならないかくらいの幼児(児童)にはたまに黙々とクレヨンで絵を描いている子供がいる。描けといわれて描いているのではなく、時間があるとのびのびと描いている。そしてたまにそれを母や父などの身近な人に見せる。その人はほめる「まあー、うまくかけたわねえー」。とてもほほえましい。 -このような幼児を集めて、2つのグループに分けたとする。AグループとBグループ。Aグループには、ただほめるだけではなく、そのときにその幼児の大好きなおかしを与える。ご褒美というわけだ。Bグループは今までどおり、言葉と笑顔と頭をなでるとかまあその程度止まり。 -そうするとAグループの幼児は変わる。どう変わるかというと、今までよりももっと強い熱意を持って絵を描くのである。いっぽう、Bグループは変わらない。まあ変えていないんだから変わらないのは当たり前である。 -さてここで、Aグループにさらに変化を与える。おかしをあげるのをやめて、以前どおり言葉と笑顔でほめるだけにするのである。そうするとどうなるか。Aグループの中に、絵を描くのをやめてしまう幼児が現れる。ただ以前の状態に戻っただけなのに、そして以前は誰に何も言われなくても楽しそうに描いていたのに、もう自発的には描こうとしないのだ。 ---- -このような実験が本当にあったのか、それとも別の類似の事例をモデル化したものかは分からない。またどの幼児に対してもこのような起きるというわけではないだろう。しかし傾向としてこの話は「確かにそういうことはありそうだな」と感じさせる。少なくとも僕はそう感じる。 *** (2) 他人からの評価を気にする人たち -この話から感じられることは、人は一度他人から強いプラスの評価を与えられてしまうと、本来持っていた自発的な意欲が減少し、他人の評価の得られないことはやめてしまう傾向があるということだろうと思う。あなたは似たような経験があるだろうか。もしくは周囲の人が似たような変化をしたのを見たことはないだろうか。 -最初は自発的かつ純粋な気持ちで自らの理想のOSを作っていたのに、ニーズがないからと方針を転換するというケースを見たことがある(このケースについて僕は詳しく語ることができないのでこれ以上具体的なことは言わない)。僕はその人に理想を貫いてほしいと思った。他人のニーズのためだけで開発していいのか。そんなことでまともなOSが作れるのか。ニーズに合わせていたら、ただ現状の問題を場当たり的に解決するだけのOSにしかならないのではないか。 -もちろん現状の問題の解決だって大切だから、そのことを否定するつもりはまったくない。しかし当初はより壮大な計画を持っていながら、ただ「ニーズがない」という理由だけで方針を転換してしまうのが残念なのだ。そもそも最初からニーズなんてなかったんじゃないのか。そのOSを使ってくれそうな人が現れて、その人があの機能はほしい、この機能はいらないというからそれに合わせ、気づいたら当初の目標のOSとはまったく別になっている。汎用性も損なわれ、あきらかにちっぽけで特定の問題の解決しかできないOSである。 -そして開発者当人がそんなことになってしまったことをくやんでいない。・・・これでいいのだろうか。 ---- -僕の経験では、誰かに使わせることを他よりも優先し始めたプロジェクトの半分以上はガラクタに成り下がっている(みんなで使うためのプロジェクトなんて最初からガラクタなことが多い)。ユーザなんか他にいなくていい、自分のために作ったもの、もしくは特定の知人のためだけに作ったものは、結果的によくなりやすい。それを「みんなにも使ってほしいから」と、本人には不要な機能を優先してつけたり、自分に必要な機能の優先順位を下げたりし始めると、退化が始まる。 -OS開発でよくあるのは、「新規に作っても互換性がないと普及しない。だから○○互換で作る」みたいな話である。確かに互換性はないよりあったほうがいい、それは間違いない。でももし自分ひとりで使っていくつもりならどうだろう。互換性がなくなって我慢できるのではないか。それにほかのOSを併用しちゃいけないということもないはずだ。だから既存のOSと自分のOSを併用すればいいじゃないか。既存のOSに不満を感じてなんらかの理想を打ち立てたのに、他の人に使ってもらえる見込みがないというだけの理由でその理想をあきらめていいのか。自分の信じる理想OS下で気持ちよく効率的なプログラミングをしたかったのではなかったのか。 --ちなみにOSASKの場合、僕は今もっているTOWNS用のソフトウェアなどを自作OS上でも使いたかったので、エミュレータを書くことにした。つまりこれは他人からの要求ではなく自分の内なる要求であった。 *** (3) 生計を立てていくという問題とのバランス -しかしまあ「生計を立てていく」ためには、誰かに買ってもらわなくてはいけないから、ユーザの意向を意識しなければいけないというのはやむをえない面はある。しかしそれでも、自分の理想を他人の評価にかまわずに作り上げ、それを他人がほしがるように見せびらかす、ことを夢見るべきではないのか。それで他人がほしがってくれなければ、価値観の相違だとか、時代の先を行き過ぎてしまったみたいだなと、割り切ることはできないのか。他人なんかどうせ近眼で問題の本質が見えていないのだ。そんな人に評価されないのが何だというのだ。 -生計を立てるために作るものは、最初からそれで行けばいい。それは仕方ないことだから問題はない。僕が気になるのは、猫も杓子も「ニーズ」「ニーズ」ということであって、現代の他人に使ってもらえなさそうだというだけで、自分の理想から出発した開発をためらいもなく捻じ曲げることなのである。せめて苦悩の上の決断であってほしい。・・・なんだかあまりにあっさりと他人向けに方針を変えられると、そもそもこの人はその程度の情熱で開発していたのかと興ざめしてしまう。強い信念を感じたから応援してきたのに・・・。 *** (4) 別のケース -これは未踏ユースやICTスクールでの経験に基づく話だが、デモや説明を聞く限り、「これのどこが面白いんだろうか」「そのアルゴリズムで本当にうまくいくんだろうか」みたいに疑問符がついてしまう開発にめぐり合うことがある。しかしそんなプロジェクトでも、とにかく開発者自身が強烈に面白がっていて、しかも多人数に普及しなくてもそれなりに使えるものは、聞いていて気持ちがいい。安心する。感じとしては、「おー、そこまで言い切るか。よし分かった。僕には良く分からないけどとにかく君たちにはこれが必要なんだな。信じてやろう。できたものをまた自信を持って見せてくれ。」みたいな感じだ。 -これに対して、「世間ではこういうものが求められていて、だからこれを作るといくつくらい売れて、みんなが使ってくれることでさらに理想的な効果が出て・・・」みたいな説明のときに、「うーん僕はそんなものほしくないし、その見積もりは甘い気がするなあ」みたいだと心配になる。実在しない具体的な例を言うと、できのよくないプログラマ初心者向けの学習ソフトである。どうみても学習意欲が続かなそうで、予定販売価格は高すぎで、当たり前だが本人たちはこんなもので勉強する動機がない、しかも本人の身近にこのソフトがあったら使いたいというテスターがいるわけでもない、という場合である。 -結局、上記の安心できたケースというのは、どこまでも主観的でかつ本人が使うように思えたから安心できたのだと思う。本人も使わない、他人も使いそうにない、なんてことになりそうだと不安なのだ。しかも開発者自身は他人が使ってくれるとなぜか思い込んでいて、自分に落ち度はないと思っているのだ。 *** (5) 自分以外のユーザを優先して迷走するケースその3 -これも実在しないケースだが、たとえばアイヌ語がすごく好きで研究しているアメリカ人がいたとしよう。この人が自分のために、アイヌ語の文章を入力したら自動でそれを文節に分けて、それぞれの文節をクリックするとそれが助動詞や助詞を含む場合はそれらも分割してくてくれるような、そんなソフトウェアを開発したいとしよう。 -この開発計画を世に出したとき、周囲の人とこんなやり取りをするかもしれない。「おもしろそうですね、開発動機は何ですか」「私は、アイヌ語が好きです。(ここでアイヌ文化のすばらしさを魅力いっぱいに語る。)だからもっとたくさんのアイヌ語を読んでいきたいです。でもいつも文節の区切りで混乱して苦労しています。だからこのようなソフトを作ろうと思いました」「なるほど、でもこれだけだと他の人にはアイヌ語が分かりません。開発者の○○さんは単語の意味が分かっているからいいかもしれないですが、単語の意味を英語でも表示できるようにならないでしょうか。というか文節なんかにわけた表示はアイヌ語を勉強する気がない私たちにはいりません。邪魔です。英文さえ出ればいいじゃないですか。そういうソフトにしてくれるのなら開発資金面で協力させてもらいますよ。」 -こうしてこのプロジェクトは迷走が始まる。当初の案であれば、なるほど他の人には使いにくいことこの上なかっただろうが、開発者当人にとってはそれで十分だったはずだ。それを妙に一般向けへ舵を切ってしまったために、開発が困難になり、完成しないか、もしくは開発までの道のりはかなり長くなるはずである。単語の意味を表示するというだけでも大変だ。なぜなら辞書を入力しなければいけないから。ましてそれをつなぎ合わせて英語の文章にまでするとなると、困難さはさらにあがる。 -開発者はアイヌ語の知識がそれなりにあったから、北国の動物や食物の単語の豊富さも理解して区別できていただろう。しかし表示されるのが英文だけになってしまうと、その微妙なニュアンスを楽しむことはできない。開発者にとってはこれは不満だろう。単語に切り分けてくれさえすればよかったのに、それは表示しないで、味わいを損なった英文だけが出る、と。こうして開発者当人にとっても必要のないソフトになる。 *** (6) おもしろ「そうな」という誘惑 -「おもしろそうなソフト」と「おもしろいソフト」は違う。開発前の説明がどんなに面白そうでも、できたものが面白くなるという保証はない。つまらなそうでも、つまらないとは限らない。だから面白くなさそうでも開発者当人が妙に自信を持っているのなら、それを信じて賭けてみることがあってもいいはずだ。なんといっても開発者がもっともそのソフトについて知っているのだから。 -僕たちに必要なのは、面白そうなソフトの開発を賞賛することではないはずだ、面白いソフトの開発を賞賛することなのだ。結果的に面白くないものができたときに、それを全て開発者のせいにするのはふざけていると思う。周囲の人たちが「こうしたら面白そう」とかいっていじくり回したせいじゃないか。でも周囲の人はその責任を全然とろうとしない。 -だから開発者は他人の意見を「時には」無視しなければいけないということを忘れちゃいけないと思う。時々は自分が「他人からの評価中毒症」にかかっていないかどうかを自問してほしい。他人からの要求ばかりではなく、自分の内なる衝動に応えて開発してほしい。 -そして周囲の人は自分の意見が開発者からあっさり撥ね付けられても文句は言わないでほしい。もししつこく文句をいうのなら結果を「保証」する覚悟をもってからにしてほしい。少なくとも1万ユーザ分のライセンスは買いあげるとか。 *** (7) まとめ -とにかく僕がここで言いたかったことは、当初は「自分のため、or自分の理想のため」に作っていたのに途中で方針を変えて他人向けにしようとするとたいていは失敗するということだ。そして最初から他人のために作る開発も、独り善がりな思い込みで作るととんでもない最悪のプロジェクトになりかねないよ、ということである。 -できることなら、まず自分の理想を実現して、その上で拡張や派生物として、他人向けを作ればいいのだと思う。 -そしてこの警告は、ソフトウェア開発のみならず、創作活動一般(絵画・作曲・陶芸・学術研究などなどなど)にも応用可能だと僕は信じる。 *** (8) 違うんだけど似ている話 -たとえば2人の記者がいたとする。一人は、読者の声を精力的に集めて聞き、読者の望む人へインタビューをするような記者。もう一人は、とにかく自分のセンスでたくさんの人にインタビューしてみて、これはいい!と思ったものだけを記事にする記者。・・・どちらももちろんすばらしい記者だと思う。 -でもあえてどちらがいいかといわれれば、僕はやっぱり、後者の「自分のセンス」に頼る記者がいい。そういう記事を読みたいし、そういう記者でありたい。 -読者に合わせるのは、あまり創造的ではない気がする。言い方は良くないけど、なんというか、誰にでもできるというか。まとまりもなくなりそうだ。・・・自分のセンスで推す場合、まとまりがないということは多分ないけど、記者と読者の完成がかみ合わなければ、はっきりいってぼろぼろの評価になるだろう。でもそれでいいじゃないか。 -つまり読者に合わせて記事を書くだけだと、70点くらいの記事になるんだろう。一方、自分の感性の命ずるままに、「これこそ伝えるべきだ」という基準で記事を作って行くと0点か100点かのどちらかになるんだろう。 ---- -ここまで書いて自分を振り返る。なるほど僕はプログラムや本を書くときには、この「自分の感性」でおしまくっている気がする。いや他人の声をまったく聞かないわけじゃない。でも聞いてみて僕が賛同できなければ(=その考えが僕のものにならなければ)、結局は受け入れない。平均化するよりは、どちらかに尖らせる。 *** こめんと欄 #comment
テキスト整形のルールを表示する