要求仕様の課題
2部に行って、その曖昧さをどうやって向き合っていけばいいのか、どうやって始めたらいいかっていう話に行きますか。
始める方法をですね、第2部。
最初のスーパーチョークって何やねんみたいなことをちょっと思ったりするんですけど。
スーパーチョークでは最後の方まで出てきますよね。
そうなんですよね。
で、もう脱線するけど、コンサートアレス札幌にスーパーチョークっていう選手がいて、ずっと読みながら最初、スーパーチョークってあの選手と何か関係あるのかなとかって見てたら、
自分の認識が観察がだいぶ曖昧だったっていうことが、よく欲しがったというのがありました。
スーパーチョークにはスーパーグローブを売り出すこともできますよとかっていう文章が出てきたりしてますね。
あれですね、チョークですね。
これは架空の事例エピソードみたいな話で、新製品作ります、それをスーパーチョークと呼んでますっていうところから始まって、
いろんな人がうまくいかずにずっとこうコンフリクトし続けるみたいな話が起きてますね。
チョークだから、笑い話でこんなことないでしょって言うけど、アプリケーションだったら全然あり得るんじゃないかって気がしますよね。
うちはスーパーアプリを作るんやつって。このアプリ一個でつぶやきもできて、ファンコミュニティもできて、サブスクもできて。
動画も短いでしょ、見れたら。
あとリアルタイムでみんなで音声会話ができたりとか、決済プラットフォームに目指しましょうみたいな。
っていうのって、割とアプリケーションの世界だったら全然ある話じゃある話ですよねってちょっと思ったりしますね。
そうですね。そうですねって言いつつ。
確かにな、そこまでぶっ飛んだ人にはあんまり一緒に働く中で出会わないから、なんか一つ恵まれてはいるのかなっていう気は。
世の中にはそういうぶっ飛んだ人とお仕事する方がテック器用って感じがして楽しいと思う人もいるんでね。
なかなか難しいですね。
逆もあると思ってて、逆というか話ちょっと変わっちゃいますけど、この○○っていうサービスとAPIつないで連携する何かを作りましょうって言ったときに、
当然このぐらいできるだろうなと思って、プロダクトの要求とか思い始めていって、
技術的なスパイク打ってみたら、なんかAPIないんですけどみたいなやつとかあったりしますからね。
ネイトリミットが厳しくて使い物になりませんとか、曖昧さというか思い込みみたいな。
見落としがある解釈。
じゃあそういうこと、そういうものは色々ありますけど、どうやって立ち向かっていきますかねっていうところで話が進んでいくんですけど、
質問の重要性
まず一番最初の方に出てくる話が、様々な出発点を、一般的な出発点って話が出てくるんですけど、
結局問題とは、解決したい問題を定義する、問題とは次のように定義することができるって書いてあって、認知されたものと望まれているものとの差異っていう風に書いてあって、
なんかこれ前、As is to be modelの話を前回のポッドキャストでしたような気がするなと思って、結局ここでもやっぱそうなのかっていう気持ちになりましたね。
認知されたものと望まれているものとの差異ってどういうことなんでしたっけ?認知されているものと望まれている。
そういうのが欲しいんですよねって言った人の頭の中にあるものと、分かれました、じゃあそれ作りますって受け取った人が認知しているものの差ですか。
自分は欲しいと思った人が今こうで望んでいるものはこうです。で、その最後埋めましょうっていう話かなと思って読んでましたね。
価値の高いプロダクトみたいなニュアンスの話ですかね、そうすると。
そうですね、だから今じゃああるものに決済機能をつけたいです。で、決済機能をつけるために望んでいるものって決済機能で現状ないっていうことで、そこの差が問題だよねって言ってるってことかなって思ってましたね。
なるほどなるほど、確かにあらゆる設計プロジェクトは何らかの問題を解決する試みだとみなして的なことが書いてあるから、そうかそういうことか。
いずれにせよ要するにこういうものを作りたいんですよねっていう目線を揃えられるように頑張ろうぜが出発点ではあります。
そうですね、でまぁちょっとその次のページとかに何が認知されているか何が望まれているかみたいな技術があるんで、そこも受け取り手側、ゴールはあってそのゴールとのギャップに対して技術的にこういう障害があるとか、
人によってはそれがいつまでにできるかとか、なんかそうこのギャップみたいなところは人によって問題の捉え方が違うっていうことはあるかもしれないですね。
うん、でなんかそういうところを考えないでどうやって解けばいいんだっけっていうところから出発するのがおそらく最も一般的に行われているがそれは間違いであるみたいな話になってますね。
そうですね。
ハウをよこさないでくださいってやつです。
そうそうそうそう、あとハウをよこさないでくださいもそうだし逆に言われた問題をそのまま解こうとするっていうのが多分本当はその問題の捉え方がもうちょっと変えればうまく落とし込めるとか、
簡単な解決策に落とし込めるとかっていう話もあると思うから両方大事みたいな感じはありますよね。
あーでも本当にあれですね、なんかご宅が欲しがってるのはドリルじゃなくて穴なんだ的な。
あーそうそうそう。
穴の字でよく言われるやつ。
うん、もう現代だと一発でそれですね。
便利ですね。
みんな知ってるやろみたいな感じでどこでも言及されるあれです。
でもこれ、この本に出てくるのが例え話というかエピソードのなんか結構面白いですよね今回。なんかいい感じに皮肉も効いてる気もするし。
そうっすね。
なんかこの章で言ってるのが大学の学部長がもっと多くの学生を惹きつける方法が必要だっていう風に言ってたのでみんなでもっと多くの学生を惹きつけるとはみたいな。
そもそも多くの学生って言ってるスコープも分からないし、で惹きつける方法っていうのは一体何を求めてそんなこと言ってるんだっていうのも分かってないけどいろいろあいだらしてなんかすごい優秀な学生に刺さるように何かしようとか。
そんなに多くの学生欲しいってことは何だろう、学生量が空いてて困ってるのかなみたいないろいろ考えるけど、そうっすね。
教授たちは学部長が本当に望んでいることを知った。それは志望者の合格率を下げることによって大学が質の高い教育をしているという印象を衆議会に与えることだったっていう風に書いてある。
まあ楽ですもんね。合格者を多くの学生を惹きつけるっていう命題に対してアンサーが合格者を減らすみたいな。はい、はいって感じ。でも確かにこれで偏差値上げたんじゃないかって言われてる大学日本にも少々ありますからね。
そうですね。人気を作れると。そう、でも結局蓋を開けてみたらなんだそんなことかっていうような話かもしれないけど、でもそれにどうやったら早く気づけるかっていうのって難しいですからね本当に。
難しいですね。なんかコペルニクス的展開ですよね。人気を高めたいなら投注を減らせばいいんじゃないかみたいな。
でもこういうの読んでると、いやまさにこうライトついてますかっていう本を書いた2人で思うと納得って感じもすごいしますよね。
確かにな。頭がいいというか頭柔らかいんだよな、この人たち。忘れてたけど。
確かに確かに。で、やっぱ問題の定義をどうするかみたいなところは大事ですよねっていうのがやっぱ出てきてますね。
そうですねそうですね。いやそうだな確かにゲインさんが言ってたようになんかみんなでその2Bみたいなところを共有しようぜっていうところが最初の取っ掛かりとしてあるよねっていうのはなんか改めて読んでみて確かになっていう気がしますね。
そうしてじゃあ次、別に1個ずつ進む必要はないんだけども、私ちょっと自分が次進みたいなと思ってたのが、この本始める方法っていうところはそこを規定しましょうって言って。
で、そうしたら次どんなことしたらいいかなみたいなところで、文脈自由な質問っていう章が6章なんですけど。
この章良かったですね。
なんか文脈自由なとかっていろいろ書いてあるんですけど、質問ですよ質問。
はい質問です。
いっぱい質問しましょうっていう風になってて、ちゃんと話を聞きに行きましょうっていう何ていうか当たり前なんだけど、でもその当たり前に何ていうか当たり前をできるってことが大事だったりとか、
どういう質問をすればいいのかなっていうところもそうなんだけど、質問できる相手がそもそも近くにいるのかどうかっていうのって、なんかとても大事なことだなっていうのをすごく感じたんですよね。
で、なんでそれをすごく感じたかっていうと、今仕事から人事の人にインタビューに行くみたいなことあるんですけど、
社内の人事は全然聞けるんですけど、お客さん、その自分のサービスを使ってくれてる人に話を聞きに行くって、やっぱ結構何ていうか大変さがあるなって思ったりしているっていうのもあるし、
あと多分この本が書かれた当時と全然状況が違うっていうことの一個としては、インターネットによっていろんな世界中の人を相手に商売できるようになった中で、
質問できる相手として正しいかどうかわかんないですけど、例えばFacebookだったら何億人を相手に商売しているっていう中で質問をするっていうことの難しさみたいなところは現在では起きてるんじゃないかなみたいなところをちょっと思ったりしましたね。
この章はそうですね、なんか結構具体よりですね、こういう質問を実際にしてみてくださいみたいな、ユーザーインタビューのプスみたいなぐらいの雰囲気もありますね。
文脈自由な質問
そうですね。
これ全然書けない。文脈自由っていうとなんか生成文法的な話かなと思ったけど、あんまり書けてないかな。
そう、だからこれただになんか。
ダジャレなんだろうな。
ダジャレかもしくは役者が、まあその役者ってよくわかんないことになってるだけなのかな。
まあまあまあ、あんまり絡めないで。
うん。
良さそう。
めっちゃチョム好きとかって書いてるもんね。
めっちゃチョム好きって思ったしっていう。
コンテキストフリー。
コンテキストフリーですよね。
まあだから、思い込みとか先入観っていうのに縛られすぎずに素朴な質問ダジャレを的なぐらいの文脈から、文脈って要するになんかすでに与えられた条件とか、
インタビューの重要性
こういうことを望んでそうだ、こういう制約がありそうだっていうところを一旦外して何でも聞いてみようぜ、もっともっとプリミティブなところ突っ込んでいこうぜ的な雰囲気を。
僕は感じてましたね。
そうですね。意外とやっぱりそういう質問ってすごく何ですかね。
ユーザーインタビューとかそうなんだけど、一番最初ってやっぱ自分たちのプロダクトのことを、この機能欲しいですかとかこれ使いそうですかみたいな一番そこに気になっちゃうからそれを聞きに行きたいっていうのはわかるけど、
でも結局じゃあその答えてくれた人がどういう人なのかってこと何も考えずにそこを剥ぎ取って無視して答えてもらって、
それって誰が言ったのって言って人事の人が言ってたのって聞いたら、いや人事の人じゃなかったのかなとか。
下手すると起きると思うんですよね。やっぱりどういう人が答えてくれたかどういう立場の人、人事部長なのか人事のその人事部のただの一メンバーなのかっていう全然多分見てる視点は違うし、
だからその人は普段どういう風な仕事をしていてどういう人と関わっていてとか、何でそういうことをやりたいと思ってるのかとかいうところも一緒に掘り下げないと、
なんかあの人欲しいって言ってましたよみたいなことだけボンとインタビューの結果が来ても、なんかこれはお世辞で言ってくれたのかもしれないねって言って何も情報が得られないまま終わっちゃったりするんで。
そこら辺の質問もね、6-4のメタ質問っていうところで同じ章の中に出てきたりはしてますね、確かどこだっけ。
これか、あなたはこの質問に答える責任者ですか、あなたの回答は公式なものと考えてよろしいですか的な話とか、他に誰か私に役立つ答えをいただける人いませんかって聞いてみましょうとか、
っていうなんか本当に具体的な質問例というかこういうことを聞いてみよう的な紹介がされてますよね。
だからこういうこと聞いていいんだみたいなところが知れると引き出しが増えて、なんかもうちょっとこうGAになれそうな感じがありますよね。
この製品にはどれくらいの精度が必要ですか、あるいは望ましいのですかとかもね、まさに聞いちゃっていいんだ系ですよね。
そうそう。まあでもね、だいたいどれくらい精度が必要ですかって言ったら、いやもうせっかくであればほどいいですよとか言われてね。
聞き方はね、どのくらいの感覚でデータ更新されてほしいですかって言ったら、いやなるべく最新のデータはすぐに見たいですって、朝9時しか見てねえじゃねえかって。
リアルタイムにお願いしますって言われて、ああリアルタイムかとかっていろいろ考えたら、そう起きが朝9時で、まあ1日ぐらいっていうのはその人にとっては全然リアルタイムだよっていう、
今の作業が1週間ずれてデータ見てるのが、まあ1日で見れたらリアルタイムだね、みたいなことがあって、全然ある話なんで、やっぱそういう曖昧さみたいな。
そう曖昧さね。
あるんですよね。
そうだ第一部でもありましたもんね。
うん。
なんか少人数って言った時にそれを作ってるのかなんかスポーツのドーム作り来ろとしてる人なら、5000人とか1万人も少人数であるみたいな。
そうなんですよね。じゃあ定量的に言えたらいいのかって言ったら、まあまたね、じゃあミリセックぐらいまで求めますからみたいな話だね。
オンラインでみたいな。
そうそうそう。
でもそうですよね、あなたのこのシステムを使いそうな部署は何個ありますかって聞くと、あなたの会社は何人ぐらいいるんですかって聞くと、
ああなるほど、この人が言ってるたくさんの人がっていうのは5人ぐらいのことかみたいな。
そうそうそう。
ありますからね。
ありますね。
なんか50人?100人いる部署の5人だったら多くないかもしれないけど、なんか部署がそもそも3つしかない会社で、でどの部署でも使ってますって言うと、なんかたくさんの人だなとか、全然変わってきますもんね。
そうそう。まあなんでやっぱりいっぱいそうやって接点持っていろんな人の話を聞くっていうのって、なんかやっぱプロダクト作る上でめっちゃめっちゃ大事だなっていうのを感じてるので、なんかこう出発点、始める方法で出発して最初に出てくるのが質問っていうのはなんかめちゃくちゃいいなって思いました。
なんというか自分の頭の中で決めようとするとやっぱりこうなんというか曖昧さに対するフィードバックがないままで進んじゃいますもんね、よからの方向に。
そう。きっとこれはこう大事なんじゃないかみたいなこと言いながら作ってて、で後戻りできないとこまで来てしまって、蓋開けたらあれ?どうでもよかったじゃんみたいなこととかなると、もうこれ全部作り直すんですかみたいな。アンケコスト考えるともう無理ですみたいな。もう一回やるんですかみたいなことになったりとかして。
鉄道のパラドックス
なんかでも登壇資料とか作ってる時とかもありますよね。資料作りながら一生懸命調べて、すごい自分的には面白かったしコストもかけたから、ぜひぜひこの話をしたいなーって思って盛り込んで、ちょっと知り合い捕まえて素振りというか壁打ちしてみたら、なんかそこの話だけちょっとつながってなくてよくわかんなかったですって言われて。
キューって思いながら一晩寝て、まあ確かにいらないか全部削るかって言ったら、すげー話しやすくなるし、通りも良くなるしみたいな。ありますからね。
もしかしてその結果がこの間の登壇って。
僕はだいたいあれですから。
とりあえず最初飛ばしますねって言ってすごい勢いでスライドが飛ばされるのをなんか目撃したな最近って思ったりしました。
最初に飛ばすか最後に飛ばすかの違いですね。そこの話触れなくてもすじ道通るようにはしてあるんで、そこだけ言い訳をしますけど。
あとあれです、今回飛ばしたところについてはあれなんで、一昨年か3年前ぐらいの同じカンファレスで喋ってるから、まあそんな目新しいやつじゃないんで。
なるほど。
いろんな言い訳があるんで。
文脈自由な質問はそんなところですかね。
うん。とはと触れたいなと思ってたのはあれですね。なんか2人とも同じとこをマークしてて。
スーパーチョーク。鉄道のパラドックスですか。
そうですそうです。
これいい話ですよね。
これめっちゃいい話ですよね。この話があるところはどういう章かっていうと、
適任者の三角っていうところで、ユーザーを巻き込みましょうみたいな、ざっくり言うとそんな感じ。
ユーザー以外も多分適任者って言った時にはステークホルダーいっぱいいると思うんですけど、関係者を巻き込みましょうというようなところの中で出てきますよと。
ちょっと面白い逸話というか話として、鉄道のパラドックスっていうのがありますよと。
これは何かっていうと、ある駅に停車する回数を増やしてほしいと要求された時、鉄道会社はまず要件調査を実施しましたと。
で、指定された時間に駅に人をやって誰か列車を待っているかどうかを調べると。
で、もちろん時刻表に載ってないのだから誰もいるわけがなくて、需要がないっていうことによってその本数を増やしてほしいって言ったことを却下しましたと。
なので、そうすると結局一生本数は増えること、停車する回数は増えることはなく、ニーズがないっていうふうに判断されますよっていうのがあって、
なので、もうちょっと本当に乗りそうな人を巻き込んで、なんでそれが必要なのかとかっていう話を聞きましょうねというふうなところですかね。
そうですよね。10時半に電車が止まるようにしてくださいって要求を受けた時点で10時半に電車が来てないのに、
どれどれその10時半というのを見てみようかって言って調査しに行ったら、誰もいないじゃねえか。こんなの電車増やさないよって。
いたらどうするんだよって話がある。
そうですね。いたら単純に本数増やすってことになるだけだから。
怖くないですか?電車が走ってない時間になぜか集まる人々がいる駅。
いや、まああれですよ。駅前に時間を潰すところはないからとりあえず駅のホームの椅子に座って待ってよみたいな、そういう世界ですよ。
実家の最寄りであったな。30人ぐらい座ってるやつ。だから生存分野済みの戦闘機の話もちょっと近いんですよね。
そうですね。
結果的に取れてるデータっていうのと、いやそうじゃなくてその裏に何があるかっていうのが大事なんじゃないのみたいな。
あとデータの取り方みたいなところもやっぱ大事ってことですよね。これとかだったら実際に街中その模型引きに住んでる人にいろいろインタビューするとかってやったらまた全然結果は違っただろうし。
そうですね。しかもこれに関して言うと鉄道の本数を増やすっていうコストをかけないで、今走ってるこの便をこっちの時間にしようとかでも、もしかしたらいけたかもしれないのでっていうのも考えると、いやーって感じですよね。
これってパラドックスだったりとか悪魔の証明みたいな感じがちょっとあるなと思ってて。製品は不満足であって、不満足だから使わない。
機能の必要性
使わないから本当は改善したほうがいいんだけど、提供してる側からしたら、なんだ全然欲しいって言ったり使ってないじゃん、機能消そうみたいな。
いうふうに繋がりが出ないなみたいな気がしていて、割と自分はよく使ってない機能は消したい、メンテコストがどんどん上がるし、使ってない機能は消したいなっていうことをよく言うんですけど、
使ってないっていうことだけを見て消すっていうことを判断するって、すげー危ないなっていう気持ちにもなりました。
そうですね。僕も確定申告の機能とか年に1回しか使ってないですからね。
そうですね。そこから見れば確かに5月とかアクセスないし、この機能いらないんじゃないみたいな。
あとなんか、そうですね。世界で一番売れてる飲み物が一番おいしい飲み物だみたいな。
そうですね。
エンジニアっぽく言うとよく叩かれているこのスラヘルスっていうエンドポイントが一番大事だみたいな。いやまあ大事なんですけど、ヘルスってエンドポイント。そうじゃねえかと。
そう。そうなんですよね。
そんなに大事なら多少聞かせようって言ってね。ロードバランサーから返せばいいんじゃない。
ずっと生きてますってこう返ってくるみたいな。
すごい。いいですね。
便利っていう。
会話性能が上がりました。めでたしめでたし。
ユーザーとコタクの関係
あとあれかな。ユーザー。このショーで言うと、コタク。コタクとユーザーっていうのがいるよね。これはこそこ言われてる話だと思うんですけど。
例えばね、おもちゃのユーザーは子供だけど、子供はコタクではなかったから、子供に人気のおもちゃを作ったけど、親のハートを捕まえられなければ売上が立たんみたいな話とか。
あとは、7-1-5、損をする人、ルーザーっていうルビーが振られてますけど、ルーザーもユーザーかみたいな話もちょっと面白かったですね。
その機能、サービスとか機能とか、この本も時代に即した形でプロダクトとか製品になると思うんですけど、その製品、そのやり方によって損する人っていうのもいますよね。
っていうのを考えた方がいいよね、的な話になる。
そうですね。これ、むずいですね。
むずいですね。
絶対機能消そうって働きかけると、使ってる熱心なユーザーが実はやっぱりいて、消した瞬間に声が来て、あれ無くなったんですか?みたいないう話があったりするんだけど、
でもそれによって、この画面の領域をすごく場所を取っていて、困ってんだよな、他にもっといいものを提供できる可能性を奪ってんだよな、みたいなところをどうトレードしていくかとか、
どう天秤にかけるかとか、結局これをやるっていうのは、例えば10人ユーザーを失うかもしれないけど、新しい100人のユーザーを取りに行くために施策をしてるんだ、みたいな。
そういう運営的な視点みたいなのもあるし、ただ1ユーザーからすると、愛用してた機能がなくなった、解約なんでやめます、みたいな話にもつながるし、
いわゆるお金を払っているとなるとまた変わってくるし。
なんかね、そこら辺になると非常に、じゃあ誰のためにやってるんだっけっていうのを見つめ直す視聴がやっぱり出てくるなっていう感じもしますけど、なんて言うんですかね。
権限と機能のデザイン
この本の中で言われているのは、例えばうちのシステムにログインする人にとっては、全員が便利な方がいいから、よし、じゃあアカウント全てルート権限だ、みたいな。
そうするとみんな好きな操作できて、はい、全員幸せになりましたかっていうと、そうじゃなくて、本当に果たしたい、提供したい世界っていうのを踏まえてデザインしたときに、
機能を制限するとか、不便にさせるとか、誰に何を提供するかっていうのをちゃんと見分けておく必要あるよね、的な話かなという感じはしますね。
そうですね、そうですね。権限ね、権限とか大変ですからね。
権限大変ですからね。
本当にSaaSの権限って大変なんだなっていうことを見に沁みてますね。
いや、結局IAMみたいなものを作る、使いたくはなる、作りたくはないみたいな。
そうそうそうそう、本当にそうなんです。
でもそう、それで属性っていう言い方していいのかな、微妙な気もしますけど、じゃあどういう人が関わるんだっけっていうのをブレスト的にまずバーって出してみようぜ的な話、
いや、このようなユーザーリストをブレインストーミングで設計プロセスの初期での独立した活動として作成するって書いてあるから、ブレスト的なっていうかブレストしろって言ってますね。
そうですね、そうですね。
面白いですね。これなんか食料的な属性が出てきたりとか、年齢とかジェンダーみたいな話とかいろいろありますね。
外国人、主婦、機械工、医者、犬って書いてありますからね。
犬。
ちょっと違うけど、お隣さんを探せになんとなく、今のプロジェクトに関わる人って誰だっけっていうところで、じゃあ実際提供したいお客さんってどんな人がいるんだっけみたいな、なんかちょっと近いなーって思ったり読みながらしてましたね。
僕もめちゃくちゃなんかここに限らずなんですけど、ちょいちょいやっぱりインセプションデッキってすごい練られたフレームワークなんだなっていうのを感じるのがありましたね。ブシブシでそれを感じたっていう気がします。
そうですね、そうですね。やっぱあんだけいろんな人が歴史を積み重ねてきたものをいい感じに上流するとあれが出来上がって、なるほどーみたいな気持ちになりますね。
本気で困らせてやろうぜって言って考えたやつですからね、あれ。生ハンカーに答えられないようなのをやろうぜ。
結果全部やらずに1個2個だけやって終わって、あれなんだったんだろうねっていうチームが。
そうですね、ブレストでこういう属性の人がいそうだよねっていうユーザーリストを出してみて、ある程度グルーピングしたりとか、当然ブレストで出したものなんで、ミーシーとかではないので重複したりとか、
同時にその2つの属性を被るところはあると思うので、そこら辺も諸々考慮しつつ、分類してみようって書いてあるんですよね。
そうですね。
このユーザーリストっていう1つの属性をガップして、フレンドリーに扱うのか、無視する関係ですよねって言って扱うのか、
もしくは非有効的、アンフレンドリーな対象として扱おうねみたいなことを1個1個つけていくと、
どういうターゲットがいるんだっけ、どういう人にどういう満足を届けるべきなんだっけっていうのが浮かび上がってくるんじゃないかと。
いいですね。これやると一気に自分たちが届けようとしてる相手って誰なんだっけって分かりやすくなって、話も聞きに行きやすくなりそうだなっていうような気がしますね。
いきなりペルソナ作るぞっていうよりかは、最初の0.1歩みたいな感じにできそうですよね。
そういう、でもこういうのも結局やれば、それはやった方がいいよねってなるけど、やらなかったら、やったことなかったりすると、
マジで何やっていいか分からんってなってる中で、これを思いつきましょうって言われても、パッとこれをっていうのは、
要はユーザーをリストアップしてみて、みんなリストアップしてこれを分離してみようみたいなのって思いつこうと思ってもなかなか思いつけない気がするんだよな。
そうですね。この本の中で言うと、エレベーターを設計せよっていう中で話してるんで、このエレベーターでもないのか、
エレベーターなるものに乗りそうな人、使えそうな人、その空間にいそうな人っていうのは、どういう人たちなんだろうかっていう感じのブレストですかね。
っていうか、エレベーター好きだな、この人たち。
そう、エレベーターの話めっちゃずっと出てるんだよな。ライトついてますかもエレベーターの話だとなって思いながら読んでたんだよな。
すごいな。わけわかんないですよね。でもそのブレストで出してみましょうね、ユーザーリストに。
エレベーター音楽の納得かっていうのがいますね。いい雰囲気のブレストができたんだろうな。
なんか日本だとエレベーターって音楽鳴ってることないですよね。
そういうこと?BGM的なのが本当にある職業なんですね。
たぶん本当にある職業で、まさに今AIに仕事を奪われてそうな人です。
そういうことか。後のリストで最終的にフレンドリーに扱う人として想定したみたいな。これを選びましたね。
エレベーター音楽の納得かが載ってた気がして、どういう想定してんのって思ったんですけど。
エレベーターの設計と会議
たぶんアメリカ行ったことない。アメリカ行ったことないっていうか、俺海外行ったことないけど。
一応なんかエレベーターミュージックみたいな、つまりただ流れてればいいというか、そこにこじゃれた曲が流れてる必要はないんだけど、無音でなければいいっていうようなところっていう話はたぶん聞いたことがあって、
まさに生成AIとかで、著作権とか気にせずに、気にせずにっていう言い方をするとちょっと広いけど、
自分でなんとなく音が作れて、それが流せるぐらいだったら、別にわざわざ著作権、ライセンスのあるものを買ってきて流す必要はないよねみたいな話をしているのは聞いたことがありますね。
なるほど。確かに密室で圧迫的な空間だから、それを和らげるみたいなのはありそうな気もする。
こういうようなところがあれですかね、二部の始める方法で人を巻き込んでいきましょうという感じで。
みんなのための会議も一応二部ですけど。
そうですね。
これはまあいいんじゃないかな。
うん、なんかまあ。
これすげえ嫌な会議の話をされましたね。
読んでてなんかうーんって気持ちになりながら、多分これやられたらブチギレるなって思ったことがいっぱいあって、会議の仕方って学ぶチャンスがどこであるかって言われるとまあ確かになーみたいな気持ちになりながら、こういうとこで準備しっかりしましょうねみたいなとか。
でも会議がひどいものならプロセス自体が病んでいるっていうことがわかるって書いてます。
ここで言ってるプロセスってのは要件プロセスのプロセスですね。
だから嫌がらせする人を追放しましょうとか、時間を守りましょうとか、あと喋りすぎな人に時間奪われないようにしましょうとか、時間通りに終わらせましょうとかっていうことが書いてます。
まあ当たり前。
なんでわざわざこれを書かなきゃいけなかったんだろうなっていうのがすごい透明深いんですけど、まあいいでしょう。
そっちが気になっちゃうよねって。
気になりますよね。
言わなくてもいいでしょうって思うけど、まあそういう時代だったのかな。
曖昧さの削減はどうでした?通称はなんかメモったっけな。
まあ自分がそのいろんな解釈ができるよみたいな話があったなあって思いながら。
そっかそっか、メリーさんのご羊体験学習これか。
これでもちょっと面白いですよね、そのワークショップ的にメリーさんのご羊、これメリーさんの羊ですか日本で言うと。
うん、だと思ってますね自分は。
これをなんか文学部ですかっていうぐらい、一単語一単語、これはこういう意味を用いる、これはこういうことではないっていうのをみんなで咀嚼していくと、
普段何気なく使ってる言語、日本語だと思いますけど我々の場合は、自然な会話とか自然文での記述っていうところに、
なんかどれだけ曖昧さっていうのが忍び込み得るかみたいな、なんかそういう想像力を養うためのワークショップとして非常に面白いなあっていう気がしましたね。
うん、なんか自分はこれを見ながら、頭が赤い魚を食べる猫っていういっぱいいろんな解釈ができる文章を思い出しながら、
自然言語処理でこう解釈するの大変だったなっていうのを思い出してました。
これまたなんか生成文法の話とかから引っ張られてますか?大丈夫ですか?
確かに。
要求仕様の曖昧さ
まあでもそんな、そんなとこですね。だからやっぱ文章を書くときにこう取られるかもみたいな、ちょっと気にしましょうねみたいなのは、
まあその本当に一位にするっていうのは多分難しいと思うけど、できるだけ減るように意識するみたいなのはやっぱ大事だなっていう気がしますね。
なんかね、ちょっと昔に書かれたイシューとかチケット、まあユーザーストーリーとか引っ張ってきて、
なんか意地悪さをマックスにして、成り立たなくはないけどギリギリ、ギリギリ成り立つというか、
普通に考えたらそうはならんやろ、でもまあ確かに全く間違ってるわけではないみたいなそのギリギリのところまで突き詰めてみんなで曲解してみるみたいな話をすると、
面白そうかなあっていう気はしますね。
まあでももしかしたらそこから新しいソリューションが生まれるかもしれない。
だとこれメリーハドアリトルラム、メリーさんが子羊一匹連れていますみたいな英語の文が最終的にこれ、
メリーはカブヤをペテンにかけたっていう解釈に落ち着いてるわけですもんね、この本の中だと。
何を言ってるんだっていう感じしかしないですけどね。
ちょっと面白いなあっていう、すごい気づきはありそうだなっていうふうな気がします。
そうですね。
この9章はね、なぜか右上の今この章は何のタイトルがついてるかっていうところが、
曖昧さの発生源ってずっとついてて、本当は曖昧さの削減なんですけどね。
あ、本当だ。
誤食があったっていうのをつけました。
これわかんないです。曖昧さの削減が間違ってる可能性ありますからね。
また、いやでも、あ、そうか。そっちが間違ってるわ確かに。
いやでもこれ曖昧さの発生源っていうのが前の章にあったから、たぶん。
ただこの章、曖昧さ削減してなくないっていう気はして。
確かに。確かに。あれ?いや削減しましょうってことかな、削減。
この章では技術の中に潜んでいる曖昧さを確定するこのような道具、あるいは体験学習を展開することにしようって書かれてるから、
発見するツールを提供したっていう意味で削減につながるんじゃないかと。
はい。じゃあ2章、2部そんな感じですかね。
