00:04
CS Harmony Radioです。
はい、よろしくお願いします。
お願いします。
今日は前回の続きで、ヤギさんからあったデザイン志向で、世の中いろんなところにあるよねっていうので、
それの中で僕らが割とストレスなく過ごせたりとか、体験できてるっていうところの話を、事例を交えながら話してきましたけど、
それを今度整理してみて、こんなとこポイントじゃないかとか、こんな応用できるんじゃないかっていう話がしたいっていう感じかなと思うんで、
どんな形で応用できそうかってところまで話していければなと。
前回、例として何個か挙げさせてもらった、航空航の手荷物受け取りの例とか、電車の手すりの例とか、
展望台の仕切りの例みたいなのをちょっとお話しさせてもらいました。
どちらかというと技術を使って、再生可能になるし、技術を使ってやるのではなくて、
少しちょっとした工夫で、ストレスなく誘導されるというか、ある程度動かされてる部分はあるのかもしれないですけど、
いい感じになるところの話かなと思います。
今回ですけど、その辺いろんな世の中、多分言われてるので、
例えばデザイン志向とかって調べると、普通に情報が得られるので、そちらを触れてもどうしようもないかなと思うので、
ちょっとポイントっぽいところだけは、これは私の視点でお話したいなと思います。
大きく言うと二つです。
一つは、さっきもちょっと言いましたけど、ある程度ユーザーを制御したいんですよね。
こうなってほしいとかっていうのがあって、ただ動かされてると思いたくない。
動かされて仕方なくやるじゃなくて、どちらかというと自然とそうなるように仕向けるというのが大事で、
多分やってることは、いい感じに制約を作ってるんだと思います。
なるほど。
例えばですけど、前回話した電車の手すりの例とかで言うと、
ただその7人掛けのところに人が座ろうとした時に手すりがあるのは邪魔なんですよ。
なんですけど、手すりが適切なところにあることによって、実は人が等間隔に座ってくれるっていう効果が生まれるっていうのが多分意味がある話で、
そこが制約になってくる。
展望台の例もそうだと思ってて、正直別に突いた手を置きたいわけじゃないし、
突いた手って何だったらない方がいいんですけど、
その突いた手が上手いこと使うことで、片方側に行かないようにするような制約がかかるんで、
前回で言うと左に回ってほしいっていう思惑があると、右側が見づらいから左に自然と動くよねっていう話をしましたけど、
03:08
そういう制約がかかってくるというのがあります。
ただどうやって制約を考えるのかってすごい難しいんですけど、
この制約をうまく作るっていうのは、ちょっと発想としてみると、
例えば一般的なエンジニアの人とかは、どっちかっていうと制約は除こうとする性質があるので、
制約ないほうがいいでしょうというフォーが多いので、発想に多分至りづらいんですよ。
前回の例で言うと、空港のバッゲージクレームの受け取りの話で言うと、
なるべく早く荷物を出すのにエネルギーをかけるっていうふうに動いてしまうんですけど、
そうじゃなくて、それがあるのはもうゼとするというか、
うまいこと制約条件をつけることで、もともとユーザー別に制約がどうこうはあんまり関係ないから、
うまいこと制約があると気持ちよくそれに従いやすいという状況が生める可能性があると。
たぶんそういうのが、ただいっちょいったんこうやればいいってもんじゃないので、
たぶんいろいろ試行錯誤が必要な分野だと思うんですけど、
制約つけすぎるとそれはそれでやりづらかったりするでしょうし、
うまい感じの制約をつけるのがすごく難しいと思うので、ある意味トライアンドエラーが必要で、
なので、たぶんデザイン試行って比較的どちらかというとユーザーテストみたいなところを注視している部分があるのは、
たぶんそういう側面なのかなと思います。というのが一個目。
もう一つは、これちょっと心理、人の心理にたぶん近いんですけど、
初動をちゃんと制御できると良いですというのが見てて思うこと。
全部じゃないです。前回出した例でも全部じゃないんですけど、
何個かは初動を制御することで全体をうまくやっている例かなと。
一番分かりやすいのが展望台で言った例ですね。
第一歩、左に行くのか右に行くのか。右を見たときに景色がちょっと遮られてそうだ、
だったら左に動かしているわけですよ。一回左に行ったら反対の方向に行ったりってあんまり普通しないじゃないですか。
目的があれば行くと思いますけど、目的が別に景色を見ることであって、
右を見たり左を見たりがないのであれば、たぶんわざわざ変える必要はないので、
基本初動をどっちに向かわせるかで、すごく重要で、そうするとみんな気持ちよく動けたりする。
手すりの例もそうですね。手すりがない状態で2人目と3人目の席の間ぐらいに座っている人が、
例えば人が増えてきたというときに、もう一人座らそうとするために
06:01
一回腰を浮かして座り直すという作業をしないと座れないと思うんですけど、
それめんどくさいねって思う人が多分いると思っていて、
そうなると最初からそうじゃなくて、初動でもう3人目のところに座ってくれれば2人目のところは座れるという状態になるので、
まず初動を決めてしまう、共同制御してしまうっていうのは多分大事みたいな話ですね。
ふうしがで、これも見た話なんですけど、列が並んでいるところに、
それをちょっと横の方で見ている人がいたときに、気づいたら後ろに別の列ができてしまうみたいな。
最初の1人みたいなのが非常に重要。その人が方向性を決めちゃってる部分があって、
最初の人を制御できるように制約を設けると、実は割とみんなそっちに動きやすい。
特に大衆を動かそうとする場合っていうのがあるので、その辺がとても応用できるのかなって思います。
もちろんデザイン志向のフレームワークを使っていけばいいと思うんですけど、
ただデザイン志向のフレームワークは比較的ふんわかしているので、
少し私の視点から見るとそういう感じかなと。制約をうまいこと作ることと、
それも初動を最初に決めてあげると割と動かしやすいので、
初動をちゃんと制御できるように制約を設けてあげる。今回のポイントはそんな感じかなと思います。
寺田 なるほどですね。制約って言ってますけど、制約っていうのは別に、
ユーザーがそこのところに制約をされて、窮屈だとか思ってるわけじゃなくて、
自然とそういう状態になっているとか、そういう状態を望むっていうことを、
見方を変えて制約を設けてるっていう言い方をしてるんですよね。
そういう設計する側の立場になったから、そういう表現をしていって、
初動を制御するみたいな話があったのも、その一環で制約の中の一つとして、
まず最初の動きっていうところのコントロールをすることによって、
設計者が望むような動きをしてくれるようにするっていうところがポイントだっていう。
ポイントはわかったんですけど、これをどういったところとかに応用したりとか、
活用できるかっていう話が、そうすると気になってくるんですけど、
八木さんがやった取り組みとか、そういうのあったりするんですか。
八木 そのものずばりじゃないんですけど、
そういう意味で言うと、ちょっと解釈広げちゃう可能性はあるんですけど、
昔やった事例ですね、業務改善の事例として、プロセス改善の事例なんですけど、
ソフトウェアのテストの改善を昔やったことがあって、
そこのソフトウェアって結構品質高いものを作んなきゃいけないところで、
09:05
テスト設計も結構ガッチリやってはいるんです。
作ってるものの品質もすごい高いもの、関差があったりするんですけど、分野として。
なんですが、実は品質を上げるために、
実際開発者が自分の手元で品質を高めるためのチェックを結構やってるってことが、
調査とかヒアリングとか業務のディスカッションの中で分かって、
そうなると実は結構属人性が高まってしまうので、
開発者によって品質が違ったりとか、最終的にはテストで抑えるんですけど、
にしても功数かかっちゃったりするので、
そうじゃなくて、もう少し前もってそういうチェック、
自分でのチェックみたいなところの品質を上げたいっていうのが最終的に出てきて、
そのために一つやり方というか手法というか、
導入しましたというのがちょっと近いかなと思います。
それがマインドマップを使って、
テストというか自分の自己チェックの観点、
こういうのをピンにしてチェックしてますっていうのを上げてもらって、
マインドマップに書いてもらって、それを同僚同士でレビューするというのをやってもらったのがちょっと近いかなと思ってます。
何が近いかっていうと、そこって結構カチカチにものを作るんですよ。
品質を高めなきゃいけないんで。
なので、ドキュメントを書くにしてもすごくハードルが高いんですよ。
きっちりしたものを書かなきゃいけないっていうハードルがあるので、
書道としてメモみたいなやつって基本書きたがるっていう心理が彼らの中にあって、
なので、そうじゃなくて、ちゃんと共有するんだよっていうのを作るために、
マインドマップだと比較的ラフで書ける部分があって、
マインドマップ自体使ってますけど、ソフトウェアなんですけど、
そういうのでまず書くんだよっていうのをやることで、
最初にそういうモチベーションを上げるみたいな活動を最初にして、
何でもいいからまず書いてくださいっていうのをワークショップとかやりながら最初教えてやってもらって、
そうするとやれるようになる、そういうのも書いてくれるようになって、
ちょっとハードル下げるというところと、
制約というイメージで言うと、マインドマップそのものは機構造でしか書けないので、
ワードみたいな形で書けるわけではないので、逆に言うとすごい端的なポイントだけが書かれる。
レビューがしやすい。それはレビューさせたいこっちの思惑としては、
12:02
ごちゃごちゃ書かれるとわからんので、簡潔にしてほしい。
そういうツールに当てはめてくれると、その人が、もちろん説明してくれないとわからない部分はあるんですけど、
全部書いてほしいわけじゃないので、こういうことをやりたいんだっていうのだけ上げてほしいので、
そういう意味ではマインドマップがちょうどうまくはまったってやったのが例かなと。
ちょっと多分この例の話の理解も話したいんですけど、
まずすごい品質を求められる開発現場でテストも厳しいですと、
だから多分テスト項目も膨大で、割と緻密に消化しなきゃいけないので、
皆さんそれを乗り越えるために自ずと自分たちで事前チェックをいろいろしてて、
テストで言われそうなことを先回りして潰そうという動きを開発者の人たちはまずしてましたっていうことなんですよね、きっとね、今の話で。
ただそれを横で見てたヤギさんプロジェクトの人たちからすると、
その動きが一定みんながやってることは、それは多分いいことだと思うんですけど、
ただ重複とか、そういうふうにナレッジ持ってんなら、
共有したほうが絶対いいじゃんっていう、そういう思惑が働きましたと。
そこに対して、自然とそういうふうにナレッジ共有させる仕掛けというところの内容をデザインするときに、
マインドマップで書き出してみようというアプローチを取ったことで、
うまくいったっていう話ですっていうところがまず理解したところなんですけど、
大枠はあってます。そしたらそれに続けて言うと、
マインドマップを使ったポイントっていうのが2つあるよっていう話があって、
まず最初のハードルを下げるっていうのは、マインドマップみたいなツールで書いていけばどんどん枝分かれしていくので、
キーワードレベルで書けばいいっていうところで書きやすかったっていう話が書き手側としてはあるし、
レビュー側も単純なキーワードとかシンプルなキーワードのほうが見やすいので、
まずそれがありがたかった。
あとマインドマップの構造上の特性から分岐していくんで、
あまりにも増えていくと管理が大変にはなると思うんですけれども、
基本的にExcelとかみたいに長文を書いていくようなことが適した表示形式がないので、
割と皆さんそこを端的にキーワードを書きやすいソフトウェアの作りになってたっていうところで、
レビューしやすかったっていうことなんですかね。
そうですね。
ちょっとその中で一点だけ気になったのは、
開発者の人がちゃんとしたドキュメントを書くのを嫌がるのはなんとなく想像ついたんですけど、
そのメモとか内容を隠してあがるっていうことをちょっとおっしゃってたじゃないですか。
15:02
それってなんでそうなのかなっていうのだけちょっと分からなかったんですけど。
それちょっと監査に関連するんですけど、
それが正式ドキュメントだというふうになってしまうと、実は監査対象に入っちゃうんですよ。
でもなんかこれ違いますって言えない感じがあるってことですか。
そこは実際は多分言えないわけじゃないんでしょうけど、
外から入ってる私からすると言えない感じになってるなって思いました。
じゃあそこは具体は正確には分からないけれども、
なんとなくドキュメント化するっていうことに対して皆さんの価が高いというか、
描きたがらない、描くにしても最後にいろいろ決まってから描くとかそういう動き方をしたってことですか。
なんか完成形を描くっていう風な文化的なものがちょっと見えてる感じ。
なるほど。
そうなった時にマインドマップの形式は受け入れられたのってなんでですかね。
その描くこと自体は同じじゃないですか。
そういう意味で言うと多分教育っぽいのをやったのは実際あります。
それ以外の今のツール適用以外の部分でのこの文脈でいうことの制約を設けるような動きをしたってことですか。
そうですね。そういう意味で言うと多分最初にこういうのを描いていいんだっていう状態にしてあげたっていうのがあって、
かつこのマインドマップを作ることそのものを正式な監査対象ドキュメントじゃないけど、
売るものだよねっていう内部資料として必要だっていう規約作ったんですよ。
なので作っていいよってちゃんと作ってねっていうものにしてあげたことによって、
要は作るものなんだって認識に変わったんで。
なるほど。そこちょっと捉え方2つあるかもしれないですけど、
作っていいよって言い方したんですけど、言い方変えると作らなきゃいけないっていうことにしました。
そこはちょっと難しいですね。
制約上は作らなきゃいけなくなったんで書き出したっていうことではあるってことですよね。
もちろん書いていいんだって思った人もいると思うんですけど、心理上は。
そのルール的な内部ルール的なものの整備とこういうふうに書くんですっていう教育的なところも一緒にやってっていう。
そういうことか。なるほどですね。これなかなか難しい話だなと思うんですけれども、
ある種組織みたいなものとか、いろんな考えを持った人たちを一つの目的に向かわせるときのアプローチとして、
この例だと制約っていうことに対しての分かれやすいものがこういうことをやってくださいっていうルールをまず敷いて、
それに適したツールを使わせるようにしたっていうことなんですよね。
ある意味そうですね。
なるほど。そういうことにすることによって設計する側の意図した動きをみんなが自発的にとか実装して取れるようにしたってことなんですよね。
18:06
そうですね。
こういう観点で言ったらいろんなとこでやってそうですね。
で、うまくいってるのもあればうまくいってないのもあるんだろうなって思って。
で、まあちょっとこの話の中で収まらないような気がしますけど、
なんかうまくいくいかないっていうところのやっぱり、
なんか製品を分ける要因はありそうな気はすごくしますよね。
そうですけど、そこまではちょっと考察できないですけど、そうですね、そうだと思います。
今後考察して何か仮説が出たらまた話したいなというテーマですけど、
全て別にルール化したらうまくいってるわけでもないし、逆にストレス溜まるようなルールが生まれてたりすることもあるよなと思うんで、
今の話ってアクションとしては分かるんですけど、
そのアクションを置くその前段の部分の方に何か重要なポイントがありそうな話なんだろうなとは思いましたね。
いろいろあるんでしょうけど、なんとなく思うのは前回の事例の話も含めてそうですけど、
やっぱりそれをやってる人たちが心地よくできるかどうかっていう観点はすごい大事なんだろうなと思いましたね。
UX的に。
そう、UX的にストレスを抱えるようなやり方しちゃうと多分定着しないしうまくいかないんだろうなっていう気はするので、
そこは少し気をつけるべきポイントとしては何かあるんだろうなっていうところが見えてるけど、
もっといろんな要因がありそうだなとは思ったんで、むちゃむちゃ興味はあるんで、またヤンキーさんが研究して出てきたら是非。
はい、何かあればまた共有します。
はい、ということですかね。
はい、以上で。
じゃあありがとうございました。
ありがとうございました。
