デザインの始まりと背景
s-umemoto
デザインの味付け。
はい、始まりました。デザインの味付け。
この番組は株式会社ajike代表の梅本と、その仲間たちがデザインについて、雑談を交えながら話す番組です。
今日のお相手は、神田さんです。
神田さん、よろしくお願いします。
スピーカー
神田です。よろしくお願いします。
s-umemoto
昨日、プライベートで話しましたけど、夏休みはまだ取られてないんですよね。
スピーカー
そうですね。まだ取ってないですね。
なんか、タンプとかには近場で行きましたけど。
s-umemoto
そうなんだ。いつもは相模湖の方に行かれてますけど。
スピーカー
そうですね。はいはい。
また、近いっちゃ近いんですけども、丹沢湖。
s-umemoto
えー、いいな。
スピーカー
あの、あれしましたよ。虹松釣り。
s-umemoto
えー。めちゃくちゃいいじゃないですか。
スピーカー
あれですよ。釣り堀ですよ。
キャンプ場で設置されてる釣り堀で、子供も一緒にできるみたいな。
s-umemoto
そうね。ほんまの釣りやったら、やっぱり1時間とか座ってじっくりやろうとかってなるけど、子供ったら無理よね。
スピーカー
いやー、川釣りってたぶんだいぶ難易度高いですよね。
自分全然詳しくないんですけども、キャンプ行ったら川で釣りされてる人いるじゃないですか。
s-umemoto
いますね。
スピーカー
釣れてるところ見たことないんで。
かなりの忍耐と時間が必要だよな。
s-umemoto
ね。私も奈良県出身なんで、川遊びよくやったんですけど、
釣れたことないです。
難しいですよね、あれは。
スピーカー
ああいう釣りの解禁の時期になると、ああいう釣り人たちがよく現れるんだけど、釣れるなと思って。
釣ったらめちゃくちゃ面白いんでしょうけどね。初心者にはだいぶハードル高いですよね、あれ。
s-umemoto
そうね。でも虹ます釣り、お子さんは喜んでましたか。
スピーカー
めっちゃ喜んでて、焼いて食べてましたね。
s-umemoto
いいですね。そういう時味は二の次かもしれないですね。
スピーカー
そうですね。雰囲気がもううまいっていう、そんな感じでしたね。
s-umemoto
いい経験ですね。
スピーカー
ちょっと次回夏休みをしっかりとられるときもまたそういう経験していただければと思います。
コンウェイの法則の解説
s-umemoto
今日のテーマは何でしょうか。
今日のテーマはですね、コンウェイの法則とUXデザインというテーマで話したいと思います。
スピーカー
なぜ持ってこられたんですか。
ポッドキャストを聞いていただいてる方からコメントをいただきまして。
s-umemoto
ありがとうございます。
スピーカー
嬉しいですね。
どういうコメントだったんですか。
コンウェイの法則、逆コンウェイの法則について思うところがあればお話し聞いてみたいですっていうコメントをいただきました。
s-umemoto
ありがとうございます。
お名前は本名っぽいんで一回伏せておいて、TKさんからですね。
コメントをいただきました。ありがとうございます。
スピーカー
ありがとうございます。
3回ぐらい前に、3,4回ぐらい前のこのポッドキャストで、
何々の法則思考みたいな自分が気に入ってるやつとかを紹介した回があったんで、
それについてコメントをいただいてすごい嬉しいですね。
s-umemoto
嬉しいですね。神田さんの企画やったからね。
スピーカー
そうですね。自分が好きな法則とかを紹介したっていう、そういう回でしたけど。
s-umemoto
一番好きな法則は何でしたか。
スピーカー
一番好きな法則はエントロピー増大の法則です。
s-umemoto
ちゃんとプロジェクトヘイルメアリーは読んだんですか。
スピーカー
それ読んでないですね。
s-umemoto
本当に信じられない。
スピーカー
それ出されると思ってもびびってたんですけども、出されてしまいました。
s-umemoto
びびってた。
スピーカー
出されたらどうしよう。
s-umemoto
すいません。これも俗にいうハラスメントってやつですね。
スピーカー
はい。
s-umemoto
失礼しました。
そうしましたら、コンウェイの法則とUXデザインについて今日はお話ということで、
まずコンウェイの法則っていうのは何なんでしょうか。
スピーカー
はい。コンウェイの法則の定義なんですけども、
s-umemoto
システム設計する組織はそのコミュニケーション構造をそっくり真似た構造の設計を生み出してしまうという法則です。
スピーカー
いいですね。いいですねってコメントがなかったみたいなコメントでしたけど。
どういうことかというと、かなり昔調べ直したんですけども、
1960年代とかにこの法則が提唱されていたみたいなんで、
めちゃくちゃ昔、50年以上前にこのシステム設計する組織は、
このコミュニケーション構造をそっくり真似た構造の設計をしてしまうということなんですけども、
チームとか何か一つのシステムを作っていくときに、
チームが分かれていたりとか部署が分かれていたりとか、そういうことって当然あると思うんですけども、
そうするとチーム構造とか組織構造に合わせたようなシステムを設計しちゃうということで、
つまりチーム内部でいろいろ話していて、他のチームとのコミュニケーションがあまり取れていなかったりとか、
チームの中だけでどういうシステムを作ろうかみたいなのを考えて最終的に合わせてしまうと、
そのチームごとの機能みたいなのが出来上がってしまったりとか、
そういう考えたら確かにそうやろうなというふうに分かるんですけども、
本当にそういうような法則、確かにこれは面白いなと思いますね。
自分はメルヴィン・コンウェイさんが提唱した法則だと思うんですけど、
s-umemoto
これ知ったのが3,4年前に流行った本で、チームトポロジーっていう本が流行ったんですよ。
ソフトウェア設計関連や組織関連の話だったかな。
エンジニアの組織系の本だったと思うんですけど。
ただ読んだときに、たぶん2回ぐらい読んだんです。
ちょっと難しくて、自分にとっては。
ただ今回このお便りをいただいて久しぶりに思い出しまして。
スピーカー
今神田さんが話してくれたエッセンスしか覚えてなかったです。
いや難しいわけですね。
深く知ろうと思うと。
自分もそんなに深く詳細まで理解できてるわけではないんですけれども、
このシステム設計っていうところに関しては、
UIやデザインとか、サービス設計のデザインとか、
そこに置き換えても同じことが言えるなというふうに思ったんで。
ちょっとこのデザイナー視点でコンウェイの法則っていうのを紹介したいなと思ってます。
s-umemoto
じゃあ言えるっていうのはどういうことなんですか。
スピーカー
いろんなプロダクトとかサービスを作るのに関わってますけれども、
出来上がりを見たときとか、例えばリニューアルの相談をいただいたときとかに、
現状のシステムを見たりすると、
サービスの構造とかがですね、
本当に組織の構造そのままで作られているっていうのを見ることもしばしばありまして、
部署の内容とかチームの内容みたいなのがそのままナビゲーション構造に反映されてるとかですね。
中身を見ると、このナビゲーションの中にはそのチームがやっている業務内容とか仕事に最適化されてるし、
他のナビゲーションの中身を見ると全然違う形で、
部署の仕事内容とかに全く最適化されてたり、
そういうのを見たりするので、まさにConwayの法則だなと思ってます。
s-umemoto
今の話は多分言える範囲だと思うんですけど、
イントラのサービス設計の話ですよね。
スピーカー
そうですね。イントラとかってすごいわかりやすいですね。
本当に部署の人はそのナビゲーションの中しか見ないとか、
その部署に合う形でデータベースが設計されてるとか、
そういうふうに思っていることが多いので。
s-umemoto
確かにイントラの場合だと非常にサービス設計というか、
情報設計と密接に考えやすいようなテーマかもしれないですね。
スピーカー
そうですね。やっぱりそれを、今ちょっと例に挙げていただいたので、
部署イントラのサービスとかを考えると、
部署分だけナビゲーションできてしまったりとか、
そういうことにもなりかねないというか、なってしまうんで、
一般的に客観的に見ると、
それってそんなにいいサービス構造ではないじゃないかなというふうに思うんですけれども、
ただこれをこうなってしまっていることを単純に否定することっていうのもやっぱり難しいなと思っていて、
ある意味、仕方のない部分でもあるんじゃないかなと思ってます。
何でかというと、やっぱりサービス設計とかでナビゲーションとかをこういうふうに変えましょうって言っても、
組織構造が影響する、そういうようなサービスになってしまうと、
そのレイヤーに関われる人って企業の中でもかなり限られているじゃないですか。
なので、こういうようなナビゲーションの構造にしましょうとか、
そういうふうに提案したとしても、
それって組織を変えるということなのかとか、ワークフローを変えることなのかとか、
そういうふうな話になってしまうと、やっぱり跳ね返されてしまいますし、
そのレイヤーの話をしてもあんまり意味がないとか、
そういうような場面も往々にしてあるんで、
単純に否定はできないなと思ってます。
s-umemoto
なるほど。
このコンメの法則は、プロダクトをデザインするときの法則の考え方と、
紹介されているというか、文脈だと思うんですけど、
サービス設計における影響
s-umemoto
昔、このラジオでも会社の組織設計とか組織図を作るときは、
組織設計とコンウェイの法則
s-umemoto
ミッションとかに対してやっぱり組織設計していかないといけないよね、
みたいな話をしてたじゃないですか。
スピーカー
はい、そうですね。
s-umemoto
それとちょっと似てますよね。
スピーカー
いや、めちゃくちゃ似てますね。
やっぱり理想で言うと、ミッションだったりとか、
お客さんとかから起点に、
こういう形が組織としても最適であるとか、
結構考えられると思うんですけども、
やっぱりそれをするにはパワーがいりますし、
現状のことを考えるとそこまでできないとか、
そういうこともよくあるし、経験もしてきたんで、
過去のことを思い出してつらくなるみたいな。
つらくなる。
s-umemoto
ちなみにつらくなったり過去を振り返るのは人間だけっていう、
仏教のあいまい、ラジオを聞いてたんですけど。
スピーカー
未来のことを余計に心配したりとか。
s-umemoto
未来のことを心配するのも人間だけって話を聞いてたんですけど。
それは別の話ですかね。
スピーカー
それは全然別の話です。
s-umemoto
またの機会でお願いします。
失礼しました。すぐ横道それちゃいますけど。
組織を作るときにしっかりやろうとしたことと組織を合わせて、
いろいろ設計していたな、つらかったなみたいな話ですよね、今の話はね。
スピーカー
そうですね。本当難易度が高いことだなというふうに思ってるんですけども、
それをこの婚姻の法則っていうのを逆手にとって、
組織作りをしている企業っていうのもいくつかあって、
これがまさにこの逆婚姻の法則っていうふうに言われてるんですけども、
代表的な企業として挙げられるのがAmazonらしくて、
Amazonはプロダクトの形をこのようにしたいから、
逆に考えて組織図っていうのはこういう形にしようというふうに
s-umemoto
設計されているみたいです。
スピーカー
なのでAmazonとかは実際ちょっと具体的にどういう組織図なのかとか、
具体的に詳しいところまではもちろん知らないんですけども、
ユーザー圏で組織を考える。
これは本当に逆算してそういう組織作りしてるっていうのは本当にすごいし、
まさに婚姻の法則っていうのを逆手にとって、
いい組織を作るっていうふうにしているところがすごいなと思います。
デザイナーの挑戦
s-umemoto
すごいですね。
言うは簡単というか、
顧客志向でサービスを開発しましょうとかって言うことはできるけど、
それがつまりどういうことで、それに対してどういう体制をとって、
どういうコミュニケーションをとってもらえればそういうプロダクトになるかって、
逆算たまものというか難しいよね、めちゃくちゃ。
スピーカー
難しいですし、組織が大きくなればなるほどの難易度が上がると思うんで。
一筋縄にはいかないというか、この法則自体はもちろん理解できるんですけども、
自分の理想みたいなところにちゃんとそれを合わせていくっていうのは本当に難易度高いと思いますね。
s-umemoto
面白いなと思うのは、
昔MBAとかで、自分はMBAも出ないんですけど、
MBAとかで学ばれがちな内容で組織設計みたいなところに、
欧米は機能型の組織作りだみたいな。
日本は何かこう人型というか、何を言ってるかというと、
よく言われると思うんですけど、欧米の場合は機能を最初に定義して、
そこに対して人を採用していくみたいな。
ジョブ型みたいな話だと思うんですけど。
一方、日本は人がいてその人をどう生かしていくかみたいなことをチューニングしていくみたいな。
それどっちがいいのかみたいな話は、いろいろ研究で出てたりはしますけど、
欧米の法則で面白いのは、機能別に対してもう一つ面白いのは、
コミュニケーションがあるっていうことが面白いですよね。
スピーカー
その組織のコミュニケーション構造に従うっていう感じだと思うんで。
配置だけじゃなくて、心理的安全性じゃないけど話しやすいのかとか。
確かに。物理的に距離が近いのかとか、そういうのが影響しますよね。
s-umemoto
そう思うと確かに、今LINEやHOOさんで出社回帰みたいなのが、
スピーカー
日経とかでも取り上げられてますけど、
s-umemoto
これもコミュニケーションの方法だと思うんで、
もしかしたらコンウェイの法則に沿うと、
こういうプロダクト作るからこういう出社してくださいみたいな理屈があっても、
スピーカー
もしかしたら納得度が高まるのかもしれないなとか今思いましたね。
でもまさに紹介されていたところで言うと、
昔って提唱されたときはもちろんネットとかも全然ないですし、
なので物理的なコミュニケーション取る距離とか、
オフィスの場所とか、そういうのが影響するって書かれていたんですけども、
今はオンラインでいくらでも話せるっていうのはありつつも、
やっぱり同じフロアで隣のデスクに違う部署の人がいるとか、
階が違うから何してるかわからないし、
話しかけに行くのも物理的にはなかなかいけないとか、
そういうのが結構影響する部分はあると思うんで、
オフィス作りは結構影響度としてはあるような気もしますし、
そこらへんを突き詰めていくと、
s-umemoto
すごい面白い、難しくて面白いっていう感じかなと思います。
スピーカー
うまいね。
s-umemoto
このラジオはもしかしたらUIデザイナー、UXデザイナーが聞いてくれていると思うんですけども、
そういったデザイナーさんたちがConwayの法則を取り入れるときに
気をつけるポイントとかなんかあるんですかね。
スピーカー
そうですね。
まずこの、結構この仕事としてUXデザイン、UIデザインっていうところで言うと、
業務プロダクトをリニューアルしようとか、サービスをリニューアルしようとか、
そういうプロジェクトがいっぱいあると思うんですね。
そのときにデザイナー、UXデザイナーとかって、
まず理想のワークフローとかストーリー確保じゃないですか。
あるあるの失敗体験として、書いたはいいんだけれども、
どうやって実現するのみたいな話になったりとか、
書くことにすごい労力と時間をかけたんだけれども、
結局は現状のプロダクトのプチリニューアルみたいなところに収まってしまったとか、
そういうのってよくあると思うんですね。
それはなぜかというと、さっきのConwayの法則とかで考えると、
やっぱ組織構造とかがプロダクトに反映されたり、
ワークフローの仕組みとかがプロダクトに反映されたりっていうのがあるんで、
そこにアプローチできる、そこを変えられる権限があるのかないのかとか、
プロマネの人がそこまで踏み込んで考えてよいのかダメなのかとか、
そういう部分っていうのは結構影響するんで、
そういう観点からどこまでの2Bを描くかみたいなのも考えたらいいんじゃないかなと思います。
s-umemoto
なるほど。その枠組みをどこに持っていって、そういう設計をするかみたいな話ですかね。
スピーカー
そうですね。結局なんか業務プロセスとかはやっぱりちょっと変えるの難しいよねっていうふうに、
最初から分かっているのであれば、やっぱりUI、現状のUIをどのように見やすくするかとか、
もう少し小さい範囲でアップデート、細かくアップデートしていくとか、
そういうふうにアクションをシフトすればいいと思うんですけども、
大きな理想を描いたはいいけれども、これ自分実際どうやって実現すんだっけみたいな話だったら、
やっぱりその前の労力っていうのはちょっと無駄になってしまう可能性があると思うんで、
そういう部分は気をつけるべきポイントかなと思います。
日本企業の特徴
s-umemoto
どうしたらいいんですか。
スピーカー
なんで、自分の理想みたいなものを突き詰めたければ、やっぱりまずは偉くなるっていうことかな。
s-umemoto
それだけ権限を持てる人になってから、正義を貫く。
何だっけ、なんとか操作船のイカリア・チョウスケの枠さんのコメントですね。
コメントが天から降り注いできますよね。
青島!権限が欲しければ偉くなれみたいな話でしたっけ。
みたいな、そういう話でした。
今の話はやっぱり組織を動かすっていう話になるんで、それは当たり前だよなと。
偉くならないとできないかもなというのは思いましたね。
スピーカー
そうですね。
s-umemoto
なんでどこまで手をつけるかとか、どこまで範囲を広げて考えるかみたいなのを最初に絞るのはすごい重要だなと思います。
あとなんかありますか、ちなみに。
スピーカー
そうですね。さっきもちょっと出た話なんですけども、
やっぱりこの組織起点とかヒット起点で日本の企業と組織をつくっていくみたいなのは特徴としてあるのかなと思うんですけども、
プロダクトとかサービスを起点に組織を考えるっていうのは結構重要性もあるよなと思うんで、
s-umemoto
そこらへんも梅坊さんどう思いますかっていうのを話してみたかったんです。
要は逆混為の話ですよね。
そうですね。逆混為、重要ですよね。
コンウェイの法則の重要性
スピーカー
いやめちゃくちゃ重要と申し上げれば、経営者とかの人はみんな自然と法則とかそういう話じゃなくて考えてはるんじゃないかなと思いますね。
そうですよね。どういう形が最適なのかみたいなのは常に考えていると思いますし、
一番やっぱり会社として理想は、価値を最大化して利益も上げるみたいなことだと思うんで、
価値を最大化するためには顧客点から考えるみたいなのは理屈としてはわかるんですけども、難しい。
でも梅坊さんはそっちの考え方が強いというか、そういうような印象もあるんですけども。
s-umemoto
どういうことですか。
スピーカー
何なんですかね。現状の業務に合わせてサービス内容とか考えると、それは実現できないとか、そういう話にすぐになってしまうことが多いと思うんですけども、
世に落ちているプロダクトとか、いろんな便利なサービスとか、そういうのをワークフローで組み合わせて、それに合わせて業務を変えたらいいんじゃないかとか、
s-umemoto
こういうことを言ってることが多いんじゃないかなって思うんです。
まあ確かに言ってるかもしれないですね。
それって世の中はわかってない。若者の意見やなと思いません?自分は若者じゃないですけど。
スピーカー
どうですか。
s-umemoto
柔軟性みたいなのは結構あるなと思うんですね。
自分一人だったらそっちの方が早いみたいな意見をすぐ言いがちですね。自分一人だったって思ってないですけど。
こうやったらすぐできるんじゃないかと思うんやけど。それをやっぱり全体で大きく、みんなで遠くに行くっていうようなことはあったじゃないけど。
アイデアになってくると急激に弱くなるっていうタイプだと思いますけどね。
ジレンマですね。
何がいいのかわかんないですけど、
例を出してくれたAmazonのような組織設計とかは自分は当然出てきてないと思いますし、
そうやってプロダクトを作っていくっていうのは、主法というよりもどっちかというと考え方だと思うんですけど、
考え方として持っておくともしかしたら救われるデザインマネージャーの方とかいらっしゃるような気がしますよね。
そうですね。結構それを意識することで、こういうふうにやってみようかなっていうふうにも考えることができると思うんで、役立つと思いますね。
これはあるべき姿を今までと違う形で作って、それに対して組織とか自分たちのフローを合わせていこうっていうことだと思うんで、
ほんとかなり逆算思考の考え方やなと思いました。
そうですね。
そんなところでしょうかね。25分ぐらいで話しました。
じゃあ今日のまとめというか今日のテーマは、コンウェイの法則とUXデザインということで、
価値創造の可能性
s-umemoto
まあまあ難しい内容でしたけど、いろいろ思うことを好き勝手に話させてもらいました。
今日も聞いていただきましてありがとうございました。
スピーカー
ありがとうございました。
s-umemoto
編集後期、お疲れ様でした。
お疲れ様でした。
スピーカー
私の頭の中の関心はプロジェクトヘイルメアリーを呼んでなかったっていうことが。
s-umemoto
あれ?残ってました?
冗談です冗談です。
なんとかの法則って面白いね。いろいろあるもんね。
スピーカー
いろいろありますね。やっぱり前も紹介してしまったんですけど。
自分の中ですごく刺さる考え方とか法則とか。
ちょこちょこあるんで。
なるほどーみたいな。こういうことかーって思いますね、それを知ったときは。
s-umemoto
そうね。なるほどってなる瞬間って自分は勝手な頭のイメージなんですけど、
孫悟空の話を思い出しますね。
スピーカー
孫悟空?
s-umemoto
お釈迦様との出会いのタイミングでビューンって逃げるけど、
山越えて印を打っても指に印を打ってたみたいな。
手から逃れてなかったみたいなのあるじゃないですか。
ありますね。
あれって、いろいろやってトライしてみたけど、
スピーカー
これこういう法則やったんか結局みたいな。
なるほど。お釈迦様の手のひらに踊らされてただけかって。
そうそう。みんな知ってたんやみたいな。
なるほどー。
s-umemoto
自分がこういう状況で苦しんでたけど、前の人ってもうすでにこれもう分かってたんですね。
スピーカー
早よ言うてよと思うけど、言うてくれてるんでやるけど。
気づいてないだけで。
s-umemoto
ありますね、それは。
法則ってそういうイメージを持ってますね。
確かに確かに。すごいいい話ですね、それは。
スピーカー
そんなところで編集攻撃、楽しく話せましたということで、ぜひまたお便りやコメントあればお願いいたします。
s-umemoto
はい、今日もありがとうございました。
スピーカー
ありがとうございました。
