コストと価値の関係
そんなところで、まだ第二部。コストと価値を計測する。コストと価値違いよねって話をしてるんですけど、コストと価値が入れ替わるなんてことがあるんですかっていうと、たまにそういう人いるよねって言ってましたね、確か。
マックスがそんなこと言ってました。労働価値説の話をしてます?これ。そういうことではない。
早くリリースするべきだ。急げ。品質は後回しだっていうのは、コストと価値を吐き違えてるなっていう気がしますよね。
確かに早く出して、価値を積分値にしたいというか、あの絵を見せれば一発でわかるみたいな感じになるんですけど、全部が揃ってから出すよりも早く出した方がいいよねっていうのはあったりするのはあるけども、そこで価値がそもそもないようなものを出すじゃないですか。
あとあれかな、この本をワインバグ的に言ったこととしては、品質を手に入れるには代償を払わなければならないっていうことですね。コストと価値がある程度はトレードオフというか、品質を作り込まないと価値が上がらない。品質を作り込むってことはコストは相にかけるべきだ的な話もあるはず。
まあいっぱいお金を払ったらいいソフトウェアができるかって言われたら、そんなことないですからね。 そうですね。
10年かけて作ったんで、いいものですって。まあ多分高齢コストってお金もそうだと思うけど、時間とかもそうだろうしって考えると、10年かけて作りましたって言っても、10年の間に市場が変わってたら一体これはみたいな。
そうですよね。10年前の製品が今発売されたら欲しいですかって言われると、いやお前が読んでる本は何年前の本だって話ですけど。だって2015年でしょ。まあまあ買わないものが多いだろうな。
そうだね。 この章でも品質の直接計測間接計測っていう話は出てきてますね。
生きてるけど、まあいいか。 うん。なんかあんまり。
この章は何か触れておきたいことありそうですか?いろんなことは書いてあるけど、読み飛ばしても大丈夫な章だった気がする。123ページ。123ページないななそうしたら。
でも読んでてあれですね。ソフトウェアが高くつきすぎるっていう話、なんか以前結構友田丸子の本読んでた中で出てきたりしましたけど、そこもちょっと触れたりとかもしていて、結局やっぱ価値とコストみたいなところの認識みたいなものが今もずれてるのはあると思うけど、
昔はもっとソフトウェアってなんでこんな高いのみたいなところとかはコストと価値をもしかしたら混同しちゃった結果なのかなっていうのはありますね。
難しいですよね。利益って話だと減価とかコストも返ってきますからね。
感情的意義づけの計測
自動化するためにすごいコストかけてソフトウェア作ったけど人気比よりも高かったみたいな話になったらちょっと悲しいしね。しかもそれからまともに動きませんとかなったらもっともっと悲しいことになりますからね。なんだ人間の方が優秀じゃないかみたいな。
いやでも笑えないですよね。エアエージェントの方が人気高くなったら、プログラミングは人間の仕事になっていっちゃうんで。 そうですね。
まあでもそんな感じで、そんな感じってこともないけど、第3部進みますか。第3部が異議論ですね。
日付段階のキーワードは関連性である。実世界の複雑さを私たちの頭脳が扱う大きさに変えるフィルターを用意することである。
ノーマンが言ってたマインドモデルでしたっけ。ノーマンに言うと。マインド性のモデルの話ですね。
メンタルモデル?
メンタルモデルか。3回に2回ぐらい間違えた気がする。メンタルモデルか。
確かにさっきまでが最初が取り込みで、その後が意味で。意味の中では現実と頭の中を極力一致させるのは大事って言ってたけど、今度多分それを全部取り込んでいくと扱えないサイズになってくるんで、フィルターを用意する必要もありますっていう感じですかね。
というか若干的な正しさ的な段階までしか意味付け、第二部までの話だと進まない気がしていて、それでじゃあ嬉しいんだっけっていうと一定嬉しさはあるんですけど、
認識を図る唯一の尺度は固着の感情である、満足度であるみたいな話をしてた人が、客観的な正しさって言ってるだけの世界で満足するわけないじゃんっていう気も、個人的にはしてるので、ここからが本当の価値とか文化、想像していくっていう段階に近づいていってるのかなーなんてことも個人的には思いながら読んでました。
そうなんですよ。ちょっと意義付けっていうのがどういうことなんだろうなっていうのが、ちょっとあんまり自分はわかったようでわからないなみたいな感じがすごい読んでて、もやもやしてたんですよね。
感情論ですよね、ここ。
感情的意義付けを計測するっていう、そもそもショーのタイトルがそうですよね。
俺にとってそれは本当に嬉しいのかい、好きって言えるのかいみたいな話だなーと思ってて。
で、そんなペラッペラなもので本当にええんかっていうところは感じるかもしれないんですけど、生きる意味みたいなところに引っかからないと、世の中のあらゆるものは存在していても無価値じゃないですか。
言うとついでに怖いんですけど、でも定直そういうところだと思うんですよね。
例えばめちゃくちゃ美味しい明太子スパゲティのレシピを覚えつきましたっていうのはそれは意味としては正しいかもしれないんですけど、
2Bで評価システム作ってるうちの会社がそれやる意味あんのみたいな、そこは多分意義違うじゃないですか、ミッションと連れてるっていう話でもあるし。
そういう自分にとっての価値判断っていうのが感情的意義付けに近いのかなとかっていう解釈でいます、私は。
なるほど。
前回もすげえ壮大に外したからまた違うかもしれないけど。
いやでも、感情っていう部分にフォーカスするんだよねっていうのはすごくわかるわかるわかるそうだと思って思いながら。
面白いですよね。その後に故障費用をどう計算するかみたいな話をしてますからね。
その辺で無しとして。
ここでも第3部9章から始まりますけど、9章は感情っていうところを扱ってるっていうのもあって、あんまり今まで読んでたワインバーグっぽい話とは少し色が違いますよね。
そうですね。
より心理的な動きとかそういう感じがあって。
うん。
そうだよな。思考と感情と区別できないならばっていう言い回しをしてたりするんで。
うん。
まあ理性と感情でいうところの感情っていう気もするし。
この辺で面白いなと思ったのが、間的インパクト法っていうのが161ページの最後のところから始まってて。
はいはい。
こんなものがあるのかと思いながら初めて見てへーって思ったんですけど、どういうのかっていうと、ABCDEっていう顧客がいて、ソフトウェア品質を絶えず低く評価してるよっていうのが。
で、ソフトウェア開発は不愉快な横浪機をモーター出すものだと見なされたっていうような期待は膨らまされるが、約束されたものの成果物は絶対合ってないんだよとかいう状態で。
主観的インパクト法っていうのは顧客に重要なもの何かを観察するプロセスであるっていうのがあって、ここでも顧客に直接聞くという意味ではないですけど、やっぱり顧客と協調をして何が重要なのかっていうことをひたすら探っていくんだなみたいなのがあって。
なんかもうずっとそのやっぱ顧客っていうことと品質ってことの大事さみたいなのをここでも言ってるなーみたいなちょっと見ながら思ってましたね。
そうですね。聞くって言ってるのも観察してみるとかリサーチするみたいなところも含めての聞くって感じです。
そうそう。
顧客の真なる声を聞く的なニュアンスに近い気もする。
そうそう。何が欲しいですかって聞くんじゃなくて普段どういうことをやってるんですか?それはどういうプロセスで業務が発生しますか?とか状態を聞いて本当に困ってる。
本質的な課題ってのは何なのかみたいな。で、それがそうしてあることによってどうハッピーになるかみたいな。
いうようなところにつながっていくんだよなと思いながら。
なんかこの主観的インパクト法っていう単語を聞いたときにちょっとちらっと想起したのが追得の質問ってあるじゃないですか。
このプロダクトやサービスを知人に勧めたいと思いますかってやつ。なんかあれに近いなーっていう気もして。
あれ全然なんか主観にしか聞いてない。直接的な質問なんでここで言ってる顧客の声を聞くっていうのとは少しずれますけど。
なんか主観でいいじゃんみたいなところはすごい通ずるものがあるなーと思ってて。
感情が唯一の事実であるみたいな話してたのこの章でしたっけ?
あ、2の4か。唯一のとは言ってないわ。感情は事実であるっていう話があって。
曖昧でないものとして扱われがちじゃないですか感情って。なんでそんな起こってんだみたいな。
なんですけどその反応が起きた。もしくは反応を起こさせられたっていうのは間違いなく。
どうか外的なトリガーはあるしそれを引っ掛けたフィルターもあるし。
で少なくともその感情が起きたよね動かされたよねっていうのはちゃんとそこにあるものとして認めなきゃいけないよねっていうのはあると思ってて。
それを否定するとすごいアンガーマネジメント開拓するのは常に不機嫌な人みたいになっちゃうなーとか。
あると思ってて。一旦認めるべきっていうのはあると思うんですけど。
そうですね。
でもなんか。
うちの製品どうでしたってユーザーに聞いてみてああうんみたいなこと言ってて使いづらかったってことですか。
じゃあ改善した方がいい点教えてくださいって多分うまく説明できなかった。
って言った時にうまく説明できてない言語化できないようなものはじゃなかったって思っちゃっていいかって思うか。
この人の反応として使いづらそうにしてた。なんか不愉快だったっていうのは実際あるよね。どうして扱うかでかなり違ってくるよねっていう気はしていて。
そこら辺を綺麗に語ってるなぁとか思いましたね。
難しいですよね。その感情を結局計測するっていうことが定量的に扱うことができないと。
じゃあ一人一人聞いていくんですかとか。プロダクトを触ってる時の顔の感情を録画しとくんですかみたいなことになったりとかするととてもとても難しいことになってしまうけど。
でもそこを無視していいのかどうかみたいなところは実際無視しちゃダメだよねっていうのはあるし。
なんか桃鉄の全然関係ない話し始めたなこいつってないのですけど、桃太郎伝鉄の作ってる佐久間さんの昔インタビューを何かの本で読んで、
ゲームを作ってる時にそのゲームの中のシステムの設計をしているってよりも、このゲームを遊んでる人たちはどういう顔しながら遊んでるのかってことを常に考えてますみたいなことを言っていて。
なんかそのゲームの中のシステムが画期的、グラフィックが綺麗とかよりも、その画面の向こう側でどういう風な顔をして、こいつ嫌な奴だなとか、おいふざけんなよって言いながら友達と一緒にプレイしてる姿みたいなことを考えながら、どういうものがあったら楽しく遊んでもらえるだろうかみたいなことを考えてますみたいなことを言ってて。
すごいそれいいなと思って、それを見てからプロダクトを作ってる時に、その画面を触ってるユーザーはどういう顔しながらこの操作をしてるんだろうかみたいなことを思い浮かべながら、実際食ってるものを触ってみたりとか、そういう問いかけをしてみる、チームメンバーに問いかけをしてみるみたいなことをすごい意識的にやるようになって。
それって結構感情の部分大事にしてたのかなーみたいなことをちょっと今話をしながら思ったりしましたね。
そうなんですよね。使ってる人の体験的な満足感とかっていうのがないがしろにされるんだとしたら、あれ何をもっていいもの作ってますって言えるんだっけみたいな話になっちゃいますからね。
そうそう。
でもあれだな、今の佐久間さんの話聞いてて思ったのが、そんなことを思いながらこのボンビーとかいうやつを設計してるかとか、絶対に喧嘩になるゲームランキングトップに入る大太郎伝説をそういうマインドで作ってるのって思ってちょっと面白いですね。
多分そこの人間関係を悪化させようというかその決定的な断裂を起きるようにということではないと思うけど、何かしら対立が生まれるとか、それがコミュニケーションの促進させるようなものになるんだみたいなところで、ボンビー作ったらいいんじゃないって思ったのかもしれないなって勝手に想像してます。
逆転ができなくなっちゃうと嫌ですもんね。
そうそうそう。
不適合な行動
まあでも感情的意義づけを計測するの第9章は、不適合の話もなあ、よかったってメモしてあるな。不適合9章だっけ?
6.2かな。
6.2ですね。不適合って何かっていうと、多分これのもうちょい前に説明してたんだよな。
全然前じゃなかった。人々の行動が彼らが価値があるという原名と論理的に一致しないとき、私たちは彼らの行動を不適合と呼ぶ。不適合な行動は変質の一番の敵である。なぜなら人々が本当に尊重する何かを隠すからであるってやつですね。
マックでインタビュー取ったらサラダが絶対読みに行かされてる。
すごいですよね、あれ。しかも今面白いのが、マクドナルドのサイトに行くとカロリー計算とかの脂質とかのタンパク質とかの計算ができる機能がついてるんですよね、マックのサイトに。
でも確かに欲しいって言われたらつけそうだなって気がするけど、でも結局マックに行くときってそういうことを気にせずジャンクなものが食べたいっていうときな気がするから。
その気にもひらないんじゃないってすごい思いながら、これもしかして不適合を観察するの事例ですかね。
でもマックだとマーケティング的にちっちゃい子供に狙いたいって話はよく聞くんで。
なるほど。
親が使うこともあるかもしれないですね。
じゃあ毎日はダメだけど週に1回ぐらいだったらこれは許容できるでしょうということを判断する上で必要みたいな。
今日はカロリー4000キロまでに抑えたいんだよなみたいな。
4000キロはすごいですね。
すごいですね。成人男性2日分ぐらい。
でも次行きますか。僕はここら辺からちょっとメモが薄くなっていってる気はする。
意義になって自分はやっぱりちょっとわかんねえっていうことがちょっと増えたような気もしてますね。
ふわふわとはしてますよね。なんかメモ薄いだけで面白くは読んでるんですけど。
そうそうそう。
好きなフィールドというかカテゴリーの話であるなあとか思いながら。
とはいえ10章4つのFの話とかありましたね。4つのFって言い方してない気がするけど。
F4。
10章が故障、これどっちだフォルトに関する話をしていて。
故障発生源の意義づけを理解するっていう話なんですよね。
さっき言ってたノーマンのエラーの話とかかかってくると思うんですけど。
故障を予防するために私たちは故障を生み出す条件を観察すべきである。
故障の温床となる条件を探り出すと故障が次の8つのFに由来するだろうと考えるのが有効であるようだ。
8つあるっけ、8つあるのか。
8つあるな。
すごい。
脆さ、愚かさ、間抜け、楽しみ、ごまかし、狂信。狂信って狂って信じるの方ですね。
と故障運ですって。
これ多分頭文字Fに揃えるためにちょっと無理したって書いてあった気がするんですけど。
最後運っていうのがまた何とも。最後はそうよねみたいな。
事例と予防策
そうですね。
まあヒューマンエラーはなぜ起こるのか的な話になって言ってる気はするけどな、ここら辺は。
これ別にそうだよねって思いながらなんですけど、この4つ目、楽しみの1のところはちょっとなるほどって思ってて。
楽しみって言ってるけど、誘惑に勝てないとか何に誘惑されるかっていうような話でいいと思うんだよな。
他人が何を楽しみと考えているかは誰にも予測できないっていうような言い方をされていて。
いやでも酷いんだよな。
事例がね。
事例が減る。
メインフレームコンソールの上の照明を一斉に20秒間パッと光らせ、それから稼働している全システムを止めるサブルーチを作った。
その作業者の念望よりもはるかに高くの費用がかかる結果になったみたいな。何を言ってるんだっていう。
まあなんか濃い機能作ったけど、それを動かすためにはめちゃくちゃマシンリソースを食うし、それによっていろんなことができなくなったり、電気代がいっぱいかかったりっていうことですよね。
まあなんかこれはもうちょい客観的に、というか同情的な描写はできるんじゃないかなという気はしてますけど、でプラス後付けバイアスというか、僕らはもうこれが失敗した事例、面白い事例として紹介されてるよねっていう前提で読んでるから、
なあはははなんだこいつって思ってますけど、なんかそのぐらい人って時に予測不可能だし、それによって起こされるアクションってこっちの想像とか常識の範疇を超えてくるよねっていう話が時に故障をもたらすっていうようなことを言っているなと思ってて、それを楽しみっていう号を当てたのはなんかオシャレでいいなと思いました。
確かに。 憎めなくなるじゃないですか。その前おろかって言ってたじゃないですか。
そう、おろかさっていうのがデカいであるから、なんかそこに吸収しちゃっても良さそうじゃあ事例だけど、なんかちょっと違うってことですよね。わざわざここで判定ものを入れたっていう。
そうっすね、なんかおろかさはただの無能能力不足だし、まぬけはなんていうかサボりたいだみたいな雰囲気がありますよね。で楽しみって積極的にやる気を持ってバカをしているので、っていう分類なんだろうなーって気がします。良かれと思って。
そうね。でなんかまあ、なんか無能ではないんだなみたいな。まあでも。 そうでしょうね、照明を光らせようとしたら右に出る人はいないかもしれないですから。
まあでもなんかこう技術に、技術駆動で開発しちゃうとかっていうのはちょっとここに近いのかもしれないなみたいなことを思って若干心が痛くなりました。なんかあれ試したいんだよなみたいな、新しいツールちょっと試したいんだよなとかって思って入れてみようと思って入れた結果後でその運用コストがめちゃくちゃかかるみたいな。
俺のデザインパターン食らえみたいなやつとかね。ありますからね。 そうそうそう。でもちょっと汗が止まらないみたいな。心当たりしかなくなってきたな。
この章で言うとようやくいい表現してるなと思ってて。謝りの直接観察はどんな意義も持たないがどのように謝りにそらえるかというメタ観察には意義づきがあるっていう。これなんか本当にポストモーテルとかで大事にしたい精神。
そうですね。 お前はなんて愚かで楽しみ屋さんなんだっていうのはあまり意味ないですけど、そっかそんな誘惑があるのかっていうのを知っておくと何か建設的なアクションってながらかもしれない。
20秒も動いてるプロセスはキルするみたいなね。どこだったっけな。この章の中に何かその予防、事前の予防が一番安くつくってよねみたいな話が書いてあって、まあ確かにそれはそうなんだよなみたいな気持ちになったのはあったんだよな。
システム思考の重要性
10の2あたり。予防が一番安くなるはあれですもんね。前のシステム思考法でも結構ページサイト語ってましたもんね。
そうそう。なのでやっぱそこは交通するところでもあるよなーって言ったし、現代の我々でも早めにエラーを検出できた方がいいっていうのはずっと言われ続けてるから、それはずっと変わってないよなーっていうことを思いながら読んでて、
そのちょっとした変更とかで壊れるってことは早期に発見できるようにユニットテストを書いてるとかいうのもあったりするよなーみたいなことを。だからこの辺の事前に故障を計測するっていうところっていうのは、現代までずっと続いてるなーっていうのは読んでましたね。
システム内部的な故障よりも視野を広げて話すんであれば、完璧なものをドーンって出すよりはまず使ってもらえるものを出してフィールバックをもらおうぜー、もうそれですもんね。
そうですね。早く失敗して早く学習するみたいな、いう話とかもそうですね。そう思うとやっぱ40年ソフトウェア開発やってきた人が見つけたものっていうのは結局今でも続けるし、実際本当はこの話ってソフトウェア開発に限らずなんでしょうけどね、きっと。
そうでしょうね。特にこの章はあんまりソフトウェア的な文脈、章というかもしかしたら部全体かもしれないですけど、いけそうな気がするな。
でもそうだよな、結局故障っていうものっていうのは、車だってもそうだし工場でもそうだし、いろんなところで多分研究、その故障率を下げたりとか、その故障によっていろんな被害が広がるっていうことを避けるためにどういうことをやるべきかとか、フェールセーフの考え方とか、多分いっぱいいろんな研究がされていて、
この辺はもう本当にあちこちでいろんな知見があるんだろうなっていう気がしますね。
そうですね、そうですね。じゃあ次行きますか。
