アイディア生成とその影響
げんえい
2部、そんな感じですかね。始める方法が分かって、次は始めて、いろんな可能性を探求していきましょう、というところですね。
最初とかには、アイディア生成会議って書いてあって、また生成って言葉が使われてるって思いながら、また使われてるじゃないですね。生成文法からちょっと冷走しましたけど。
ブレストの話が出てきたりとか、アイディアのスケッチみたいなとこでイラストで考えるみたいな話が、地図作成ツールって言い方をしたりしてますけど、出てきたりとか。
あと名前付けみたいな話もありましたね。名前付けの話ありましたね。あとは紛争の朝廷ってやつですね。
っていうのが、第3部って感じですね。
きんじょうひでき
プロジェクトの名前はちょっと面白かったなーって思いましたけど、スーパーチョークの話出てきたのはここでしたっけ?いや、ずっと出てるんですけど。
げんえい
そう、ずっと出てる。
きんじょうひでき
これはまだか。そんなスーパーじゃなくてよかったみたいなオチがあるんだよな。
言えてただけだったみたいな。あれめちゃくちゃ好きなんですよ。
げんえい
それはそうだろうなーみたいな感じますけど。
きんじょうひでき
俺12-2、名前の影響のところは面白かったなーって思ったんですけど、アイツマンで話すのが難しいかなー。
げんえい
そうなんですよね。
きんじょうひでき
家具の設計してくださいねーみたいな。家具の設計しましょう。そのための要求定義をしてくださいっていうようなのをグループに分かれてやりましょうっていう実験というかワークショップかな。
いろんな状況あるんですけど、指示内容がグループによって一箇所だけ変わってて、一つのグループが椅子、足置き、間仕切り、コーヒーテーブル、本箱、サイドテーブルとして使うことができるっていうふうに、
すでに名前がついている家具としてこういうふうなことができるように設計、要求決めてね、要件決めてねっていうふうに書かれていて、
でもう一個のグループが腰掛けたり足を支えたり部屋を仕切ったり、本、ランプ、雑誌、細々したものを置くことができるっていう名前じゃなくて機能で記述してあるっていうようなことが書かれていて、
そういう状況を与えてグループディスカッション的なことをやらせて、なんか発表数が昨日チームは10だったのに対して名前チームは出てきたアイデアみたいな意味で、
発表数っていうのは3だったりだとか、なんか優れたアイデアっていうのも昨日のチームの方から出てきたよねとか、あとそのコミュニケーションの雰囲気もその椅子、足置きみたいな名前を与えられた方はかなり論争的だったのに対して、
昨日ですね腰掛けたり足を支えたりっていうふうな与えられ方をしたチームは不真面目って書いてあって、不真面目ってこれネガティブなニュアンスじゃないと思うんですけど、
なんか結構砕けた雰囲気でわけややいとうぐらいの話かなーという気はしていて、なんかこれ面白かったなーって思ったんですよね。
発想が凝り固まってこう、○か×かを決めるみたいな会議になってたか、その反対になんかこう、こういうものがありそうだよねって、みんな想像の世界にしかいないよねっていう前提で話してた。
結構需要的な雰囲気になったのかなーみたいな感じとかして、面白いなって思ったし、なんか安易に名前つけたりとか、名前があるすでに存在する概念として扱っちゃうと、
まあそこに参加してる人、ディスカッションの質にも雰囲気にもどんどん影響を与えそうだなーとか思ったりして、なるほどなってなってました。
げんえい
このところの、そのやっぱ腰掛けたりっていうことと、椅子っていうものから受け取るイメージって多分全然違いますよね、多分人間は。
いやそれ椅子じゃないじゃんってなっちゃうんですよね。
この中でいいと判断された回とか、発表して出てきたアイディアみたいなところとかも、なんかこれ基本的にこの本に書いてあるのすごいいいなーって思いながら、
でも本当に椅子が欲しいんだよねだったら、たぶん椅子って言った方がもしかしたら、てか別にいつもあるあのパイプ椅子でいいんだよなって思ってる人からしたら、
もしかしたら名前チームの方がしっくりくるものがパッと出てくる可能性とかもあったりするんだろうし、たぶん使い分けみたいなのは大事なんだろうなーみたいなことをちょっと思ったりもしましたね。
きんじょうひでき
我々、我々、我々、我々とはっていうすごい曖昧な言葉を使っちゃったんですけど、なんかよくあるSTLアンチャパターンの功績の一つが名前をつけたことだみたいな、そういう可能な概念にしてくれたみたいな話とかもあるし、やっぱり名前の効果すごい良いんですよねっていう気はするし、
名前があるとこうスッと入ってくるっていうことはもう何ステップも飛ばして潜入感とかすでにインストール済みの知識に働きかけるっていうことにはやっぱりなっちゃうので、いやーだからファシリテーターとかはすごいここら辺の力が問われますよね、いい感じに話をまとめるっていう能力は必要なんだけど、想像力を遮ってはいけない。
げんえい
いやーむずいですね。
きんじょうひでき
難しいですね。楽しいんですけどね。
げんえい
今これ見てて、なんかまさにExcelが欲しいんだよねってよく言われるんですよ。プロジェクト作ってるときにExcelみたいな感じでって言われるけど、そのExcelが指してる対象、Excelっていろんなことできますからね、Pythonを動かしたりもできますし。
きんじょうひでき
確かになんかロックバンドのミュージックビデオ作ってますもんね。
げんえい
そうですね、なんか一時期俺のExcelと違うみたいななんかたがつくニコニコ動画いっぱい見たなと思いながら。
ありましたけど、なのでExcelって指してるものが全然人によって本当にただのCSVをExcelって呼んでる場合もあるし、ちゃんとこのセル結合がされてなくて、このセルが書き換わると自動で合計のとこもちゃんと変わるよねみたいなことがExcelっていう人もいるし、電卓で計算した結果を打ち込んでるマス目として使ってる人もいるし、全然違うけどExcelって名前がついた瞬間にみんなあれこれ想像キュッと狭めちゃって、
おのおのが思うExcelが頭に浮かび、え、これ作るんですかみたいなことが発生しちゃうんだよなーっていうのをちょっと聞きながらすごい思いましたね。
きんじょうひでき
ちょうど最近聞いてたPodcastでなんかサーバーは売ってますかって聞かれてすごいびっくりしたって話があった気がしますけど、別のPodcastすぎるんであんまり深い話しないですけど、あれめっちゃ面白かったですね。
げんえい
そうですね。
きんじょうひでき
名々はなんか本当に諸葉の剣な感じしますねしますねっていう前提で、名前が大事なんじゃなくて名前をつけようとすることが大事なんだって言ってたのこの章じゃなかったっけ。
げんえい
この章の145ページですね。
そうだそうだ。
名前をつけようとするとなんていうかそのなんですかね。
きんじょうひでき
点が決まってそこに収束させていくぜっていう感じになりますよね。
げんえい
でその点の合ってるよねっていうことにすごく気を使うようになり、変数名とかまさにそうだと思うんですけど、なんかこの変数が表したいことってこれで合ってるよねみたいな一気に可能性をぎゅっと絞るというか。
MATSの名前重要っていうプログラマーがシルビー97ことかなにMATSの姿勢がありますけど、いい名前がつけられないときはまだ曖昧さみたいなものがすごくすくんでるから今じゃないみたいな。
無理にそれを機能として取り込もうとするとその機能名がしっくりこないときはまだ入れないみたいな話を書いてたりしたんだけど、なんかあれすごい好きでよく名前の大事さみたいなところでリンクとしてよくみんなに渡すんだけど、
名前をつけるってことはすごく大事なことなんだよっていうことを思いながら、でもプロジェクトネームとかコードネームとかつけるとだいたい後でコンテキストが失われた高生の人にその名前と機能が一致してなくてわかんなくてつらいですみたいによく言われてつらいみたいな気持ちがあるんで。
そうなんですよね。名前をつけるっていうプロセスはすごい発見的だし、この本の語彙に合わせるとすごい探検っていう行為に近いんだろうなと思うんですけど、やっぱりそのプロセスが失われちゃうとってなりますもんね。
きんじょうひでき
そうなんですよね。
そうだから名前が決まっちゃうと、やっぱりさっき点を打ってそこを目指すっていう風な言い方しましたけど、なんか点を打つのそこでいいんだっけって批判精神がなくなると思うので、なんかもう所有の条件になっちゃうというか、受け入れる対象になっちゃう気がするんですよね。
たまにね〇〇アダプターって書いてあるクラスで、全然アダプターじゃないけどみたいなあったりします。ファサードって言ってるけどファサード?本当に?みたいなね。
げんえい
はい、本当にそうですね。
きんじょうひでき
なんか知っててそう呼んでる人は全然いいんですけど。
げんえい
俺の知ってる人と違う。
きんじょうひでき
人がやっぱり見られてくると非常に困る。
げんえい
やっぱり言語を統一するっていうのはね、完全に言語統一って良くないですから。
きんじょうひでき
そうですね。
げんえい
別々の言葉を話させるためには。
きんじょうひでき
そっち側の視点で言ってる人あんまりいないな。バラバラにする側の人の価値観。
げんえい
っていうのをちょっとね、思い出しちゃったりしましたね。
きんじょうひでき
ここらへんがね、揃うと本当にいいチームワークが生まれますよね。
げんえい
そうですね。
きんじょうひでき
別々会うのコツってやつになってくるんで。
げんえい
そうなんですよね。なんかハイコンテキストの文化って一長一短なんですよね。
だからそこがパッと本当に会うんで通じるチームワークを作るためにはハイコンテキストは必要だし。
でもやっぱり人が入れ替わったりとか、外から見られることとかもっていろんな人が本当に出入りが激しいみたいな時には多分ローコンテキストじゃないと厳しいよねみたいなところとか。
この辺はやっぱりトレードオフだから意図的に設計した方がいいことなんだろうなって思ったりとかしますね。
なんとなく惰性でドキュメント作るのめんどくさいし、会話で全部詰ませてハイコンテキストにしてると、とてもとても辛いことが待っているかもしれない。
きんじょうひでき
そうですよね。最近だとTバラさんのやってるTDDでっていうのが流行ってたりします。
じゃあエリック・エヴァンスのドミニクド席はどこに行ったんだって話なんですけど。
最初から名前ついてたのに。
げんえい
おかしいですね。
でも単純なところ、そんなブレストの話今してもなーっていうのもあるし。
きんじょうひでき
うん。無双の朝廷もなー。
げんえい
っていう感じはあるから進んじゃいますか。
きんじょうひでき
そうですね。完全に出席する技術っていうのが説のタイトルはちょっと面白かったですけど。
まあでも、そうですね。第3部はそこまでかな。
存在することの重要性
げんえい
で、次が4部が明確な期待ってやつですね。
きんじょうひでき
またスーパーチョークプロジェクト出てきますね。
げんえい
出てきますね。
きんじょうひでき
これちょっと独特だしすごい重要そうだなーって思ったワードとして、
どのようなシステムにとっても第一の機能は存在することだっていうふうに書かれていて、ここら辺は一発で理解できましたか?存在することとは。
あー、なんか存在する第一。
ないものは使えないみたいな話なんですよね。
げんえい
ですよね。だからまずそこにあるっていう。
神様。
光あれしたんだけど。
そうですね。
きんじょうひでき
これをなんでわざわざ言ってきたのか。
いかにして存在するかって話になるのか。
げんえい
そうですね。
きんじょうひでき
なぜいるのかとか、どういうことができているっていうのがその機能があるということだ、存在すると言えるのかみたいな話になるのかな。
機能の分類
げんえい
あとの方で機能を見落とすとか潜在的機能を把握するみたいなところが多分出てくるんで、そことの対比というか、あるっていうこと。目視できるっていうことではないんだけど、機能があるって。
きんじょうひでき
知られてる認知できる。意識されてるみたいな。
げんえい
そういうところのためにまず存在するっていうことが大事っていうことが最初に出てきたのかなって気はしましたね。
きんじょうひでき
そうするとちょっと話進めながらの方が分かりやすそうですね。
げんえい
第4部から結構グーッと、なんて言うんですかね、専門的ではないんですけど概念的でもないんだよな、なんて言うんですかね。
そうですね。
きんじょうひでき
難しい話になってきますよね。
げんえい
ちょっと先になっちゃうけど、制約とか選考とかここで選考はプレファーですけど、ちょっとテクニカルな部分が出てきますよね。
から話していきますかね。
きんじょうひでき
明確な機体っていうこの第4部が構成としては、機能、属性、制約、選考、今言ったプレファーのやつと機体って承立になっていて、一通りさらえたいけど一通りさらうの大変かな。
げんえい
大変そうではありますね。結構盛り盛りですもんね。
きんじょうひでき
結構盛り盛りですね。一旦機能のところで言うと、さっきちらっと出てきたんで、顕在的な機能、隠された機能、飾りの機能みたいな、EHFの話していきますか。
ここでもな。ここどうでした?なんかやや難しかったんだよな。
げんえい
そうですね。言われたらわかるけどみたいな、こういう風に分類、飾りの機能みたいなところはそんな風に分類を考えたことあんまなかったなって思ったりしました。
きんじょうひでき
そうですね。知ってる概念に近そうだんだけどあんまり耳にしたことがない説明でしたね。
げんえい
そう。顕在ニーズ、潜在ニーズみたいな言い方とかはするけど、あんまり飾りの機能って何かに近いもので考えるとなかなかあんまないなーとか思って。
きんじょうひでき
これでもこの本で実験的にやってるのは、備わってる機能に対してどれが現れた機能で、どれが隠れた機能で、どれが飾りの機能ですかっていうパラメーターの値の方を書いていってるんですよね。
それによって何が生まれてくるかっていうのが変わるよねーって言ってるような話はしていて、これはちょっと面白いなーっていう気がした。
現れた機能はユーザーにとってできるだけ目に見えるように働く機能。これがメインフィーチャーみたいな感じはするかな。隠れた機能はユーザーにはできるだけ目に見えない方が良い機能。
飾りの機能はクライアントが好むものだが、費用がかかるようならなくても、あるいは他の機能と妥当したりして良いものだ。
水を沸かすケトルの例
きんじょうひでき
これはメイとかそういう感じ?
げんえい
あったらいいなっていう。
あったらいいなですよね。
一番最初に削りましょうって言われるやつ。
きんじょうひでき
なくてもいい。
例えばケトルの話が例に出ていて、水を沸騰させる、当店に達したことを知らせる、音が鳴るとか、洗剤購入、購買者にとって美しく見えるっていう3つの項目がされていて、
この3つに対してどれが現れた機能でどれが隠れた機能でどれが飾りの機能なのかっていうのを変えていったらどういう風にアウトプット変わってくると思うっていう話をしている。
げんえい
そうですね。
きんじょうひでき
最終的にはどれも隠れた機能にしてしまったら、じゃあ何ができるのかみたいな。
げんえい
面白いですよね、これ。
きんじょうひでき
でもあり得ますもんね。
水を沸騰させることもユーザーが意識しなくて良いし、まして沸騰店に達したことを知らせるっていうのも別にユーザーが意識しなくてもいいってなると、
常にお湯が沸いてるサーバーみたいなものがあれば良いのではみたいな話になったり。
もはやポッポッとみたいなもの、まぁポッと音なるけど。
げんえい
とかとかありましたね。
きんじょうひでき
この辺とかってソフトウェア開発するときにどうやって我々意識してるんだろうな。
げんえい
これプロバダクトバックログアイテムをどう並び替えるかっていうときにこれやってそうだなっていう気はしましたね。
このケトルの例でいくとお湯がまず沸くよねみたいなのを一番最初にやって、
でもユーザーこれ気づかないかもねってなるから、じゃあお湯が沸いたことに気づくようにしましょうみたいなことをやって、
最後なんかちょっと持ち手をオシャレにみたいな、握りやすくしようって言って飾りをつけるみたいな、そんな感じ。
握りやすくだと隠れた機能っぽい感じがするけど。
きんじょうひでき
あとはどんなバリエーション出していってもお湯がちゃんと沸くっていうのは必須であるってなったら、
むしろ不確実性、要するにこれが何を意味するのかって曖昧性が高い曖昧さが多分に含まれてるのが、
沸騰点に達したことを知らせる、どういうふうに知らされたいのっていうのがバリエーション推理可能性が多すぎるってなったら、
そこから最初の前半のスプリントで実験できるようにした方がいいよねとかなるかもしれないし、
げんえい
ログイン機能はどうせ絶対に必要だから最初作らなくていいやろう的な話になったりとかするのか。
安全に水を沸騰させることができることが分かっていたら、後回しでいいですもんね。
要求の明確化とコミュニケーション
げんえい
技術的な不確実性理由と、そこは実験試体験をするし、楽に言うと水なんて沸かせられて当然ですよみたいな話だったら、
きんじょうひでき
後でいいじゃないですか。
げんえい
そうですね。
きんじょうひでき
どうせディレクショナルデータベース使うんだから、最初はエステライトでやっとこうぜに近い話かなと思って。
げんえい
そうですね。
きんじょうひでき
ここら辺のユーザーにとって大事なものとか、製品にとって大事だけどユーザーが意識的に欲しいのはここじゃないよねみたいなところをやっぱりすり合わせるっていうのが一個大事なのかなっていう気はしますよね。
14章の最初の掛け出し見てもやっぱりスーパーチョークから本当に何を望んでいるかについて明確に理解してなければ彼らはトラブルの山に踏み込むことになるっていうふうに書いてあるんで。
げんえい
そうですね。そうなんだよな。何を望んでいるかを理解してないまま作るのって、なんかそれっぽいものは作れるけど実際逆に立たないものが出来上がるんだよなみたいな。
きんじょうひでき
なんか難しいんですよね。そういうことじゃなくてって言って結局手戻りみたいなのはいつまで経ってもあるんだよな。難しいですよね。
げんえい
難しい。
いやーなんかちょっとこれ横断した関心事というか、この章、この章でこの部丸ごとちょっと関心事として自分は思ってるのは、期待とか望んでいるものとかって明確に理解するっていうのは別に本当に100%何を言っても誰がどう見てもわかるみたいなものっていうのはないと思うんですけど、
絶対どこかにはその曖昧さみたいなとかズレは出るとは思ってはいるんですけど、本当にそういうものって引き出せるのか、そういうものって存在できるのかっていうのは何となくちょっと気になっていて、
つまりユーザーが欲しいものってユーザー自身が知ってるかって言ったら、よく速い馬が欲しいっていう人は車が欲しいとは言えない。
見たことないものを欲しいっていうのって多分すごく難しいことだったりするから、それって本当にできるのかなみたいなことをちょっとここの部全体読みながら思ってましたね。
きんじょうひでき
それで言うと作ったものを実際に見てみて、やっぱりこれじゃなかったほどまではいかないとしても、なんかここもうちょい大きい方がいいかもみたいな。見えることによってそれがフィードバックとなってユーザーの要求が変形するみたいなのはある気はするので。
形で言うと、要求を完全に記述するみたいなのはそんなに意味のないことなのではないかっていう気はしちゃうんですけど、ただ例えばPDMとかチームの話してる言葉、思い描いてるものっていうのがばらけちゃうと単純にユーザーに届けてどうなるか観察しようっていう実験の質が落ちちゃうので、
そこの摩擦係数というかジャップは減らした方がいいよねっていうのがあるし、それはチームの中に閉じた話ではあるし、なるべくプロダクトチーム対ユーザーっていうジャップ取り勘にいっても、なるべく100点は取りたいですよね。
100点取ってどの科目の単位ができたから次の授業受けられます、だったらいいんですけど、いや30点なんでちょっともう一回やってもらっていいですかになっちゃうと単位が取れないようなものをリリースしちゃうと辛い辛さしかない。
売り上げもないみたい、それは避けたいですよね。でもそこら辺の擦り合わせ自体の大事な際、何のためにその要求の明確な技術にこんなにこだわってるんだっけっていうのは一緒に取り組むチームとしてグランドルール化してもいいかもしれないし。
げんえい
そうですね、多分今自分の頭の中で思ってたのがゲームとかエンタメみたいなとか一発勝負のオリンピックの開会式とか、例えば見たことないものを見たい人に対して要求がクライアントがあってそれに対してどうやって打ち返すかみたいなことを考えた時にすごい難しいし、
制約条件としては多分時間とか予算とかいろいろ出てくるだろうけど、そこで機能みたいなものであるからOKみたいなことっていうのは結構満たすことっていうのは難しいんだろうなーみたいなことを思ったりとか。
きんじょうひでき
我々はその一発勝負が嫌いすぎて反復的にやろうぜってなったんじゃないですか。
げんえい
になってると思うので、あれは違うゲームなんだなーっていうのを今話しながら、擦り合わせがやっぱりできるような状態に持っていって、擦り合わせの中でやっていきましょうってなるっていうのがいいですよね。
きんじょうひでき
そうですね、無難なものしかできないじゃんっていう批判は分からなくはないなっていう気はしますね。アーティスト性、アート性は低くなるんだろうなーみたいな。
げんえい
それが求められてる場じゃなければ、むしろいらないことだから、アートスティックいらないから普通に使えるものを出してくれみたいな、スクロールを奪うんじゃないとかね。
毎回トップページ出すのに1回ローディング挟んで10秒経たないとページが出てこないとか。
きんじょうひでき
そうですね、開発チームの気まぐれナビゲーションみたいな。
ユーザー詳細ページリリースみたいなのがいつまでに出てきて。
げんえい
イースター行くぐらいはいいかもしれないけど。
そういうところが全然違うゲームだなーって思いながら、結局機能とか属性、制約とかいうことをどれだけ頑張って引き出せるのか、擦り合わせられるのかっていうのは、お互いにテクニックがいるよなって思いましたね。
発注と受注みたいな関係が仮にあったとして、受注側も自分が作ってほしいものをちゃんと伝えるっていうことが必要だし、受け取り手側も真の業機を理解するためにいろんな質問をするとか、どういう制約条件とかトレードオフがあるのかということを明らかにしていくっていうのは両方必要だよなーっていうのをちょっと読みながら思ってたっていうところありますね。
きんじょうひでき
コミュニケーションですからね、お互いにやらないといけないし、どっちかがレベル低くてもいけないし、みたいなのはありますよね。
そうっすね。
そうすると次第15章の属性っていうのが出てきますけど、なんかここめちゃくちゃ品質特性的なものを想起させるなーっていう気はしていて、なんかアーキテクティングっぽい話に超近づくなーって思ったりしながら読んでました。
げんえい
そうですね、フテアーキテクチャーの基礎とかのところとかでも、あの本の中でもなんとかビリティみたいないっぱい種類があって、それのどれを選択してどれをトレードしますかみたいな話があったりとかして、なんかちょっとそれをこうやっぱり連想するみたいな感じはありますね。
きんじょうひでき
そうっすよね。なんか信頼性なのかそれとも別の○○性なのかみたいなやつとか。
エレベーター情報装置の属性分析
げんえい
こういうような、こういうようなって言ってるのは、この本の中ではいっぱいあるんですよね。このエレベーター情報装置の属性リストで、もう本当にいっぱいあるんですよね。オプションが少ない、安い持ち運びができるとか、連続稼働とか、防水、速い応答とか、モジュラーとか、何個ぐらいあるの?50個ぐらい。
きんじょうひでき
何個あるの?
げんえい
ざっと適当に50とか60とか、いっぱい挙げられていて、こういうのをグルーピングしてリストに作っていきましょうねみたいな話があったりするんですけど、でもこういうのってやっぱり数いっぱい出さないと思いつかないものもあるだろうし。
きんじょうひでき
そうですね。本当にブレストでやってますよね。味わいやすいっていう項目があって、味わいやすいってなんだ?みたいな。良い香りがする。
げんえい
まあ確かにね。
きんじょうひでき
エレベーターにつけるハードウェアで。これ属性、そうですね。形容詞か副詞みたいな○○しやすいとか○○安さみたいな感じでバーってブレストしていきましょうっていうところからスタートですね。
ブレストでやるから属性間に矛盾があっても気にしないと。とりあえず出せ出せって感じでやって、でこれはガムウォーリストの変換だから、これに少し値みたいなものを出るのか。
げんえい
例えば長持ちする、長持ちっていう属性だったら10年間長持ちするっていう風に書いていったりとか、カラフルって言ったら256ストックだよね、総天然色らしいみたいなやつとかしていくと。
きんじょうひでき
最終的にその○○安さ属性っていうのを満たすためにどういう風に機能の群が出来上がっていけばいいのか。
げんえい
そうですね。
きんじょうひでき
でここでやっとスーパーチョークって言ってるものが何を求められてたのかっていうのがわかるわけですね。
ああそうか属性を機能に割り付ける属性を除外するっていうフェーズがあるかとかやってって。
まあオチとしてはスーパーチョークって呼ばれてたものは最近手に入りやすくなった新素材を使ってチョークを作れるようにしたい。
であってチョーク自体がスーパーなのが求められてるかみたいなことを言うといやどっちかっていうと今までの機械で互換性落ちながら作れた方がいいです素材は買えるんでみたいな。
でただマーケティング的にとか○○含めて呼び分けるためにスーパーって言ってるだけで別にチョークにそんなスーパーさはいらなくないっていうのがクライアントのお話でしたね。
この話めっちゃ好きなんだよな。
げんえい
いやーでもこんなんいっぱいあるんだから。
きんじょうひでき
そうめちゃくちゃあると思いますよね。
まあでもそれこそインセプションデッキっていうトレードオフスライダーみたいなものが応用していくとなんかこのプロダクトでは何を重んじて何は優先度を落とせるのか。
他この機能に対してはどういうところが重要視されるべきなのかっていうのがご意見取りやすくなりますしね。
げんえい
この章のまとめもね属性を明瞭に定義すれば設計者とクライアントが十分な情報に基づく知的なトレードオフ判断をすることができるようになるっていうふうに書いてあって。
きんじょうひでき
この人たちが知的って言ってるのは多分感情の対義語ですよね。
げんえい
そうですね。
まあ情報があればそれに基づいて。だからまあこっちがいいよねってなんとなくこっちがいいよねのトレードオフではなくて。
まあだいたいそういうトレードオフって全部MAXでみたいな。
きんじょうひでき
そうだからADRとか書くときもここら辺意識すると良さそうだなっていうのは。
げんえい
そうですね。
きんじょうひでき
全部さらっていってるけど。
制約。制約と選考はまとめて話してもいい気がする。
げんえい
そうですね。いけそうな気がする。制約は制約ですよね。
きんじょうひでき
無視できない条件ですよね。マストってやつですよね。
げんえい
うん。だいたいこうまあ続けたつですけどなんかじゃあ誤差は何パーセント以内とするみたいなのがあったときにそれを超えていったらダメだよとか。
きんじょうひでき
で選考っていうのはなんかどっちかっていうとどっちとかどのくらいにするみたいなやつですね。
そうだから誤差は何パーセントとするっていうのは制約だと思ってたけど実は選考でしたみたいな話とかが例ですし、この本の中でいうとスケジュールの話出てきたのってここでしたっけ。
げんえい
そうですね215いつ必要かグラフってやつかな。
きんじょうひでき
そうですねいやこのプロジェクトは7月1日かやらなきゃいけないんですってメンバーに話聞いたときには制約だと思ってたけどなんかその上の偉い人に聞いたらいやそういうことではないぞみたいな話になってた。
げんえい
そうなんですよねいやでもまあこれってまさにゲームのルールみたいなものだと思うのでなんかどこまでこうなんですかねその制約をついていいかどうかとかいうのはなんかその通りいろいろ確認した方があのなんかゲームの例の難易度は一気に変わるよなって思ったりしますね。
きんじょうひでき
ヤブヘビになるかもなーっていうのもあるしただなんかいや書かれてないことはやってみましょうで動いてもいいかもしれないし聞いてみて有利な方向に動かせばいいじゃんもあるかもしれないしまあそこはカードの切り方っていう話はあるんですけど。
げんえい
割となんか制約が厳しいなって感じたときはもういつもとりあえずこの条件ってなくせないってまず聞いてみるみたいなことを意識してやるようにしてますね自分はこれがなければもっと早く出せるんだけどとかこれがなければだいぶ作るのは簡単になるんだけどどれぐらい大事みたいなこの制約はみたいな。
きんじょうひでき
厳しいと思うんですけどあのチームとあのチームのあのチームのエース3人ともこっち引っ張ってくれませんかみたいな。
まあそれ別にイエスの方が帰ってこなくてもスケジュール見てみたら来月から意外と手空きそうだよみたいな話になったりすると制約じゃなかったってなったりする。
人どかすの難しくても持ってくるのは意外とできたりしますからね。
でもそこらへんも制約なのか先行なのかっていうのは本当に曖昧というか主観思い込みで動きがちだったりするのでここらへんはやっぱりすり合わせておきたいですよね。
そのチーム内でもそうだしステークホルダーにも要するに期待を明確にするって話だと思うので。
期待の明確化
きんじょうひでき
ここで製品開発の第0法則がまた出てきて、制約を満たす必要がなければ他のどんな要件を満たすことができると。
げんえい
この言葉すごいいっぱいあちこちで使ってるから本当に好きな言葉なんだなって。
きんじょうひでき
ここからだって8年ぐらい擦り続けるんでしょこれ。
そう。
そうなんだよな。何も作らなくてよければいつでも完成するから。
げんえい
第0法則でことが進めば誰も苦労はしないんだよな。
きんじょうひでき
制約先行があって次が期待でこの部がラストですね。
そうですね。
面白いですよね。期待っていう章のタイトルで読んでみると第1節18章期待。18章第1節期待を制限する理由って書いてあって。
げんえい
エンジニアっぽいなっていう気がしますよね。
そこだったっけな。
そう。期待みたいなものをいっぱい上げてって制限しましょうっていうのは可能PDAってやつに分類しましょうみたいなのがあって今実施するやつと後でやるってやつと後例から除くみたいな分類をしましょうみたいな話があって。
で、その時に後でやりますって言ったやつってだいたい後でやられないんだよなみたいなことを思ったりとかして。
リファクターみたいなね。
そうそうそう。この?って気がするけど定期的にそれを見るようにしましょうみたいな話がどっかに書いてあったんだよな。期待の章じゃなかったのかな。
きんじょうひでき
ありましたっけ?どこだっけな。
げんえい
もしかしたらここじゃないかもしれない。どっかに書いてある気がしたんだけどな。
できれば取り上げ用リスト、定日を書いてなかった。
なんかその後で、後の半でやる。つまりだいたいフェーズ2でやりますみたいな言い方をするんですけど。
で、そのフェーズ2は一生来ないみたいなことが往々にしてあるような気がしていて。
そういうのってどうやって立ち向かうといいのかなっていうのをちょっと思ったりしました。
しかしそれが書いてあるのは177ページって書いてあって、昨日のとこでした。
きんじょうひでき
でも後でやるリストは何ですかね。最近だとそんなものはいつでも捨ててしまえって言いますもんね。
げんえい
そうそう。方便というか、そういうのにとして使ってるのが良くないのかな。
きんじょうひでき
なんかでも合理的な気はしますけどね。後でやるってことは今やらないってことなので。
今は少なくともやる必要がないっていう言い換えができるし、ってことはやる必要が出てきた時にやればいいよねっていうのは筋は通って。
人間的側面はどこ行ったんですかっていうのはあるかもしれないんですけど、いいんじゃないかなっていう気がしますけど。
げんえい
そうするといつも私の意見は後でやるに入れられて、実装されたことはありませんみたいなことが起きると、なかなか難しいんじゃないかなって。
きんじょうひでき
それ言ってくるやつ一番嫌いだからな。いやーそうですねって。
げんえい
それこそユーザー数が少ない、使ってるユーザーが少ない部分とかはやっぱりそういう風になりがちで、でも要望の熱量が高いみたいないうのとかがあると、なかなか難しいんだよなーみたいな気持ちになりながら。
きんじょうひでき
だからといってね、めちゃくちゃ上位顧客だからちゃんと対応した方がいいかって言われると難しいところですよね。
げんえい
そうなんですよ。そうなんですよ。っていうのがまあなんかこのちょっと明確な期待みたいなところを読みながら、頭の中に制限して今実施するのと延期する。
コールから覗くってしたい。本当は今実施するものそれ以外みたいにしたいんだけど、なかなか相手は人間だったりするし、話を聞いてもらえないって思うと今後その人からフィードバックをもらうことがなかなか難しいとかいうこともあったりするんで、そこの扱いは大事にしないとなっていうのはありますね。
きんじょうひでき
ですよね。で、そっか。さっきの機能のところで、現れた機能隠れた機能みたいなところのパラメーターを変えてみると少し見え方、必要とされるもの、浮かんでくるものが変わってくるかもねって話しましたけど、
結構この期待とか期待を制限する、要するに可能延期絶対不可能っていう風にちょっと分類してみましょうっていうのを、なんか割と似たような効果を狙ってるっていう感じですかね、この本の中では。期待の割り付け方によって本質的に異なった設計解が得られそうである。
繰り返すがこのプロセスの利点はそうしなければ設計者があまくりに行ったであろう決定を明示的に行うところにあるっていうようなことが書いてある。まあその他社間でのその曖昧なまま残ってた部分っていうのを削り落としつつ、じゃあ本当にフィットするもの、必要なものってどういう風にやればいいんだっけっていう、要するに筋のいいものが出やすくするっていうような狙いですかね。
げんえい
今これを読みながら期待リストなんて作ったことあんのかなーって思います。似たようなことはきっとしてるんだろうけど。
きんじょうひでき
期待リストってバックログアイテムとは別だよな。
げんえい
バックログアイテムを作る上でその手前にあるものって感じなんですかね。
きんじょうひでき
冗談というかね、より包括的な。
げんえい
それがいろんな人からヒアリングを受けて、そう考えるとでもあるかもしれないな。
謎のスプレッドシートにまとまった要望リストみたいなのがあって、それを上げ下げしたりとか、そこにパラメータをポイント付けをしてポイントが高いものからやりましょうみたいな、そういうことは確かにやってるかもしれないな。
要求仕様の明確化
きんじょうひでき
特定の期待リスト、ユーザーにこのシステムでどんなことを最も期待しますかっていうようなのを含めて、そうした質問をしてみて、その回答を得る。
それをリスト化するっていう特定の期待リストを作るっていうところから始めて、18-2-1が特定の期待リストを作るで、18-2-3が期待リストを作るなのか。
一般化してのって言ってるけどこれ特殊なだな、スペシフィックだな。
げんえい
そうですね。
きんじょうひでき
まあちょっと抽象化して一般化してみたいなやつです。で、期待リストを作ってっていうのが第2のステップで、第3のステップがさっき言ってたPDAですね。
ポシビリティ、可能、リファード、延期、アブソリュートインポシビリティ、効力、ラマゾク、絶対、不可能っていう期待を制限して、で終わってない?4つのステップって言ってたのに。
まあそういう感じに作っていくってことですね。
げんえい
そうですね。
まあでもこういうのがあると、周りに説明するときとかにもどういうものかっていうのはすごくわかりやすくなるし、やらないことを文章化しましょうみたいな話もあったりしたんですけど、
ああこれ欲しい、でもそれはやらないことになってるんですよねとか、制限してる理由ってここでっていうのがパッと説明できるので良さそうですね。
きんじょうひでき
ああそっか。制限する理由っていうのを明確にドキュメント残しておきましょうとか、制限する理由をそもそもはっきりさせておきましょうがステップ4か。
でそうすると後話にされた理由とかどういう条件が整ったらこれが刺さりそうか必要なりそうかっていう判断が後々しやすくなるからやっておこうぜみたいな。
まあ不採択の理由書いてあると嬉しいには。それこそエイリアル的な世界観でよく知ってるぞって感じ。
げんえい
そうですねそうですね。何も言わずにそのままクローズされてるイシューとかね、分かる人がいないからしょうがないクローズしますって言ってクローズするんだけど、
後でそのイシューとかに当たった時になんでこれ閉じた、何も言わずに閉じとるみたいな気持ちになることあるからな。
きんじょうひでき
でもまあ僕のっち派だけど自動でイシュー閉じちゃっていいんじゃない派だけどな。
げんえい
いやいいんですけどなんかちゃんと分かってる人がいる間にこれはやんないってなんか意思決定したぞっていうことを決めて閉じといてくれると、
理由まで分かって後で追いかけると楽になるなって思いながら、大体放置されてるイシューを閉じるのは昔よくやってました。
きんじょうひでき
まあ必要になったら誰かが同じ場所に来るんで。
げんえい
そう、リオープンしてねって。必要になったらオープンできるからオープンしてねってよく言ってました。
きんじょうひでき
でも確かにソースコードで後でロースみたいなのはよく分からんなってなりますね。
それは私ですかみたいな。だとしたら後っていつどうやってみたいな。
そのトミットの日付を見ると5年前みたいな。後っていつが来るんだいみたいな。
まあまあでも第4部にそんなことですかね。
