ご参加くださったかたありがとうございました！
資料を公開したあと、テクノロジーを駆使したものづくり 界最強のファシリテーターでありプレイヤーである安藤幸央さんに、講演で触れた「むずかしいこと」の解決の糸口を教えていただきました。
以下ゆきおさんからのメッセージ
僕らが心がけているのは
資料を公開したあと、テクノロジーを駆使したものづくり 界最強のファシリテーターでありプレイヤーである安藤幸央さんに、講演で触れた「むずかしいこと」の解決の糸口を教えていただきました。
以下ゆきおさんからのメッセージ
僕らが心がけているのは
●ネガティブな指摘をする時は、改善案とセットでする。
その改善案がショボくてもいいので。
単に細かなミスや間違いを探して指摘するのではなく、
事の本質をとらえ、どうしようとしているのに、出来ていなくて、
何が足りないのか、指摘して「あげる」ようにする。
代替案を一緒に考えるところまでつきあう。
やの：代替案を出せよ！というだけでないのが理想的！
●ネガティブな指摘の時、人と問題は切り離して考える癖をつける（全員で）
やの：これなかなかむずかしいんですよね。人のせいにしたほうがはるかに心理的な負荷が下がるのですぐそうしたくなる。でもそれやっちゃうとチームの未来も自分のうつわもちいさくなっちゃう
●開発者が実装が簡単な方に流れたり、標準の部品や標準APIで出来る範囲でしか対応せず、逃げたがるには一理あって、実装の面倒さだけでなく、その後のメンテやバグ対応、バージョンアップの際の面倒さまで想像してしまうから。
Pros & Cons （利点／欠点）と、必要作業項目リストを書き出して、
それでもやった方がいいのかどうかを、皆で納得する。
時にはコストをかけてもやった方がいいこともあるし、
逆にそれだけのコストをかけるのが見合わない方法、後回しにした方が良いこともあり。
やの：この後先を考えた計画こそじつはサービスデザインの最適化に直結しているんですよね。そのあたりをデザイナーもちゃんと理解しないといけないと考えています
●開発者がコストを下げる事ばかり気にするのを避けるために、
実装のことを全く考慮しない「デザイン会議」と、
いかに工夫して、どう実装するのかを考える「実装会議」を
分けて実施する。その後、冷静に擦り合わせ。
デザイン会議も、実装会議も、デザイナー＆エンジニア、双方が参加する。
やの：これ大事。お互いの見識をちゃんと把握して、わからないことはしっかり質問する
●権限を振り回す人対策としては、
ドット投票（一人２票もって、好きな案に投票する。
同じ案に 2票でもバラバラでも良い）
権限を振り回すえらい人には、少し大目の 3～4票持たせて、
自分の影響力が他の人よりも強い優越感を感じさせつつも、実はけっこう民主的に良い案が生き残る方法
やの：具体的！堂々巡りになりがちな会議に決着がつきますね
●「ポニー会議」と呼ばれる、偉い人用の会議を設定し、早いうちから意見を取り入れたかのように振る舞う。
（ポニー会議：子供が子馬欲しい！とわがままを言うことから）
やの：これしらなかったです。アップルのやりかたなんですね。組織でデザインするのって「提案を通す」妙技なくして進めないので、こうした目線は必須ですね
●言った言わないの根拠のために議事録は大切だが、
実際のところ、状況は刻々と変化するので、最初に思ったことが、常に最後まで正しいとは限らない。
ある考えにこだわるのではなく、常に正しいのか検証し続ける。
意見をひるがえした人を批判しないで、ちゃんと理由を聞くようにする。
やの：デザイナーってすぐれたファシリテーターでないとつとまらないと最近強く感じています。なにかを「通す」ことにこだわらず、人の話をちゃんときいて、かといって開発を止めないスピード感をやしないたいと思いました。ありがとうございました