ソフトウェアエンジニアが CIID の IDP コース（1週目）に参加して学んだことをゆるりと共有します。今週（2/24~2/28）に CIID の 2020 IDP コースがコスタリカで始まりました。今週はチームビルディングをしつつ、チームビルディングを学ぶ週でした。
I wrote this article in English as well.
Day 1: Introduction
初日は CIID や先生たちを含めて、生徒の自己紹介がメインでした。なので、まず最初に僕もここで自己紹介をしておこうと思います。
僕は現在26歳で、CIID に来る前までは東京のスタートアップで4年間 web とアプリのエンジニアをやっていました。小さいスタートアップだったので、サービスの UI/UX のデザインから、システムの設計、実装/運用を1〜3人のチームで経験することができました。その働いている間に、同じく東京にある産業技術大学院大学（AIIT）で、人間中心設計のコースを受講していました。このコースを受講したことにより「デザイン」というものに興味を持ち、今回 CIID に参加することを決意しました。学生の頃は、機械工学専攻していました。大学とは別に、南米に8ヶ月間語学留学をしていたのと、その後に8ヶ月間サンフランシスコでインターンをしていました。僕の英語のレベルは、読み書きに関しては得意ですが、話すのは今でもすごい苦手です。そして、すごいコミュ障で陰キャです。基本的にプログラミングの話と仕事の話しかできないです。
初日は自己紹介以外は、ほとんど CIID の文化の説明に終止していました。CIID は想像以上に彼らの「文化」というものを言語化して、とても丁寧にそれを説明してくれました。その文化について少しだけ深ぼろうと思います。
Prototype
まず最初に言われるのは、「とにかく、形にする」ということでした。それがどんな下手くそなスケッチだろうと、ダンボールでできた子供の図工みたいなものであろうと、「形にしてビジュアル化する」ということを教えられました。そういう文化を大事にしてるからなのか、それとも海外だからなのか分かりませんが、とにかくみんな作ったものを褒めます。信じられないくらいオーバーなリアクションをしたり、とにかく良いところを探して「ここをもっと伸ばせば良いよね！」とか「こんなアイディア思いつかなかった！」などコメントしてくれます。
日本人からすると「大の大人がそんなに諸手を挙げてみんなで褒め合うのはむしろ変じゃない？」って感じてしまいますが、後述する「Be fun」の文化と密接な関係があると思います。
Be fun
次に教えられる文化が「楽しむ」ということでした。CIID では、「学ぶことは楽しくあるべき」、「創ることは楽しくあるべき」と教わります。前述の通り、作ることをみんなが楽しめるような文化をすごく感じます。
ここでは、何かを作った人に賛辞が送られます。ここでは、何かを学んだ人に賛辞が送られます。正直、まだ慣れないところもありますが、楽しいです。そして、後述する「Team」へと繋がります。
Team
僕らは毎週3〜4人のチームに分けられて、金曜日に作ったもののプレゼンをします。このチームで作業するにあたって、CIID では「Equal Talk Time」というルールを設けています。「チームの全員が同じ時間話す」という簡単なルールです。英語が話すのが苦手な僕にも必ず話す順番が回ってきます。正直、大変だと思っていますが、「チームに話しかける」という作業が「チームになっている」と感じています。そして、「チームになる」ということが「楽しむ」という行為へとても良い影響を出していると感じました。
単純に一人で楽しむのって、自分の趣味とか好きなことじゃないと難しいと思います。でも、プレゼンの後にチームメイトとハイタッチしたり、握手したりすると、とても楽しいです。また、CIID は金曜日のプレゼントの後に「セレブレーションパーティー」というのを用意しています。ここでは、3〜4人のチームだけでなく27人が全員で各チーム良かったところを褒め合います。この時間は、27人がチームで同じお題を解決して感じがしてとても楽しいです。
Lean from each other
最後が「学び合い」です。僕らは27人のとてもグローバルなチームです。専門領域も出身国も年齢も性別もバラバラになるように選考してくれています。そんな中で違った観点やスキルを学ぶようにと教わります。
今の所、これについては僕が教えられていることが圧倒的に少ないです。また、生徒各人もこれについて実感は少ないのかなと思います。専門性を活かすようなプロトタイプはまだなく、ディスカッションに終止しています。しかし、今後、機械学習やプログラミングの授業になったら、それぞれの専門性が生かされるのだろうと感じています。
Day 2: Norm
チームとは
チームビルディングに関してのフレームワークを学びました。そのフレームワークの中では、チームは4つのフェーズがあり、そのフェーズを行き来すると学びました。その4つのフェーズが「Form」、「Norm」、「Storm」、「Perform」です。簡単に説明すると、「Form」がチームを結成したての状態。「Norm」がチームのメンバーがお互いの役割を理解した状態。「Storm」がチーム内で意見の衝突が起こっている状態。「Perform」がチームメンバーがそれぞれの役割を実行中の状態です。詳しくは下記の記事に説明を譲ります。
初めて聞いたフレームワークでしたが、今週チームでワークするにあたって、とても有用なフレームワークだったと思います。自分たちのチームがどの状態にいるのかを考えながらワークするのは、自分たちを客観的に見るのにとても役立ちました。
また、個人的には「Norm」がとても有用だなと思いました。今回の金曜日のプレゼンのお題が、「2062年のコスタリカの植物園の祝い方をデザインする」というお題でした。正直、プログラミングなどの技術的な話をするならまだしも、2062年の空想の話を英語でするのはかなり難しかったです。ただ、チームが出来て最初の「Norm」の時間に、「僕はそんなに英語で難しいことをディスカッションは出来ない」と話せたことで、チームの期待値をコントロール出来たと思います。（それにしても話さなすぎてチームに迷惑をかけたと思いますが…）
個人的には、チームとは「友達になる」ようなものだと思っていました。ただ、このフレームワークを理解すると、「どうお互いを活かすかを理解する」のがチームだと改めてちゃんと理解することが出来ました。
常にバイアスの中にいることを意識する
この日はバイアスについても深く説明されました。そして、チームで作業してバイアスの存在を意識することの大切さを学びました。チームの「Storm」、「Perform」フェーズでバイアスが自分にも他人にも出てくるのを目の当たりにしました。
「Storm」では、だいたい各個人のバイアスによって意見の衝突が起こっているように感じました。僕が「定年退職者向けに再就職先を探せるカフェをデザインするのはどうだろうか？」と提案しました。そうしたら、チームメイトは「定年退職者はもう仕事をしたくないから、それはうまくいかないと思う」と、悪意なく意見を述べてきました。そしたら、すかさず先生がやってきて、「それはまさにバイアスだ」と言ってくれました。先生は、自分の仮説や予想でアイディアを否定するのは危険な行為だと教えてくれました。これは、自分が日本で働いていたときも起きていたのだろうと思いました。また、「バイアス」という言葉を理解していたのに、こんな簡単にバイアスにハマるのかと思いました。
また、2つ目の体験は、先程の「2062年のコスタリカの植物園の祝い方をデザインする」という発表会で感じました。あるチームは、人間が火星移住を成功させたと仮定して、「火星から来た人」をターゲットにしてデザインをしていました。火星移住の可能性の大小はよく分かりませんが、彼らは課題に対して、自分たちのバイアスを外すのに成功したんだと感じまいした。そして、僕らのチームでは、「地球人」というバイアスに縛られていたのだと感じました。
バイアスは知らず識らずのうちにハマっていて、自分の思考を狭めているのだなと身を持って体感できました。また、このバイアスに気づければ、アイディアのスポットももう少し容易になるのだろうと思いました。
Day 3: Ideation
4つの役割
ディスカッションにおけるフレームワークを学びました。ディスカッションの最中は「Mover」、「Follower」、「Opposer」、「Bystander」の4つに役割が分けられて、ディスカッションの時々によってその役割が入れ替わると教わりました。簡単に説明すると、「Mover」が議論の大まかな方向性を決めて議論を前進させる人。「Follower」が Mover の意見に賛同して議論を加速させる人。「Opposer」が Mover の意見に反対して議論がワンサイドになるのを止める人。「Bystander」が議論を聞いて状況を見極め、違った観点で意見を述べる人。
このフレームワークは僕にとても心理的安全性をもたらしてくれました。このフレームワークを知る前は、チーム内での自分の役割を完全に見失っていました。しかし、ガンガン議論に加われないが、Bystander として要所で議論に違った観点をもたらすのに集中できるようになりました。ただ、本来はこの4つの役割を行き来しなければならないのだろうと思います。もっと、英語でのディスカッションに慣れてきたら自分の役割を変えて議論に参加したいと思っています。（英語の勉強をしなければ…）
こういう風にディスカッションを客観的に見れるようになったので、この人が何をしようとしているのかを理解できるようになったと思います。
“問い”に集中する
この日はブレインストーミングのワークショップも行いました。ブレインストーミングする際に、問い（お題）の抽象度のコントロールの重要性を説明されました。例えば、「CIID でのコーヒーの飲み方デザインする」という問いは、非常に抽象度が高いです。人によってはどんどんアイディアが出てくるのかもしれませんが、僕はこの問いでスケッチに落とし込むのが難しかったです。ただ、少し具体的にして「CIID のコーヒーカップをデザインする」となったら、なんとかスケッチに落とし込むことが出来ました。コーヒーカップをデザインしても良いし、コーヒーカップとコースターをセットでデザインしても良いし。しかし、更に具体的にして「CIID のコーヒーカップの取手をデザインする」となったら、1つや2つはアイディアを出せるかもしれませんが、それ以上は難しいです。
このように、自分たちがデザインしようとしている”問い”を意識することが大事だと学びました。また、この問いを具体的にするインスピレーションを得るためにインタビューを使うのだと学びました。日本にいた時には、インタビューしてから”問い”を探していました。そして、CIID でもそのようにやりました。しかし、インタビューから出てくる問いは、とても抽象的な問いでした。それに対してブレインストーミングしても、新しいアイディアというのは出しにくかったです。
その後、自分たちで”問い”を設定して、インタビューの結果からその”問い”を少し具体的にするように”問い”を修正するということを行いました。僕たちは今回「2062年のコスタリカの植物園の祝い方をデザインする」という問いを渡されて、インタビューの結果から「2062年のコスタリカの植物園の自然を感じる祝い方をデザインする」という問いに修正してブレインストーミングを行いました。すると、ブレインストーミングのしやすさは雲梯の差でした。
ブレインストーミングのやり方も色々あるようです。興味ある人は下記のリンクを見てみてください。
ちょっと余談ですが、CIID では「とにかくアイディアをスケッチする」と「短時間でたくさん出す」というスタイルを採用してます。グローバルなチームではそれぞれコンテキストが違うので、ビジュアル化して話すのはすごい有用だなと思いました。そして、短時間でたくさんアイディアを出してくると4〜5個目くらいから本当によく分からないアイディアが出てきます。それをみんなで話すのは案外面白いと思っています。
本当のデザイナーとは
ブレインストーミングして出てきたアイディアの評価はとてもむずかしいです。授業では、「人は無意識のうちに自分の考えに固執してしまう」、「リスクや投資対効果などの否定的な意見が入り込みやすい」と教えられました。
多くの人は自分の予想と仮説に基づいて評価をしていると教えられました。「予想と仮説にはバイアスが入り込みやすい」とのことです。自分が日本で働いていた時も上記のバイアスにすごい囚われていたなと思います。僕はすぐにリスクを考えてしまいます。なので、確証が持てるまで、じっくり考えてしまいます。この評価の段階で重要なことは、「客観的な根拠と自分の経験に基づいて行う」ことだと教えられました。自分のバイアスを殺した状態でアイディアを評価できる人こそ本当のデザイナーであると教わりました。
評価の仕方として、具体的なフレームワークは下記を教わりました。
Day 4: Prototype
分からないこと理解する
プロトタイプは被験者に正解を示すものではありません。プロトタイプを使って、被験者に体験してもらい、問いの答えを得るために存在していると教わりました。つまり、プロトタイプを作るには3つの要素があります。「なにを体験してもらうのか」、「自分が知りたいことはなにか」、「被験者はだれか」です。この3つの組み合わせが、プロトタイプが試している”問い”であり。”自分が本当に分からないもの”になります。
また、繰り返しになりますが CIID ではプロトタイプを作って、試すことを強調しています。下記の IDEO の創業者の言葉引用して、「とにかく被験者に体験してもらいなさい」と教わります。
You cannot experience an experience without experiencing it
Bill Moggridge
また、僕にはすごい刺さる言葉が授業中にあったので、是非紹介したいです。
It’s about minimising risk while still moving forward.
前進している間はリスクを最小化出来ているという意味です。僕はリスクを考えて、しっかり考えてから決断するタイプです。ただ、この言葉のおかげで、どんどんプロトタイプを作って、どんどん分からないことを分かりたいなと思いました。（僕がものづくりが好きというのもあるかもしれません！）
作り込み度のコントロール
プロトタイプでは製作者の説明のいらないレベルの作成が必要だと教わりました。説明があると被験者の素の意見が得られないまま、納得してしまいます。なので、被験者の素の意見が得られるレベルのプロトタイプの作り込みが必要になります。
また、逆に分かりやすくするために作り込まないという選択肢があります。要素や機能を組み込みすぎる方が複雑性が上がって、被験者の理解を妨げます。最終製品に対しても言えますが、プロトタイプの段階でも要らない要素や機能の検討はしっかり行うべきです。
作り込み度のコントロールは、アイディアのフェーズによっても異なります。アイディアの初期段階では、きれいな装飾やディテール部分の作り込みは不要です。それよりも、なんとなく理解できるぐらいのプロトタイプを作って、被験者に見てもらいます。初期段階では、プロトタイプを通してコンセプトを作って行きます。徐々に、自分が何を作るべきかが言語化できるようになり、プロトタイプを通してコンセプトの解像度を上げることが出来ます。一方、最終段階に近づくにつれて、プロトタイプの作り込み度が上がります。この段階は、コンセプトがプロトタイプを作り上げます。つまり、プロトタイプを通してコンセプトを表現するものになり、それを被験者に問う形になります。自分のコンセプトの複雑さに応じて、プロトタイプの作り込み度も上がります。
Day 5: Presentation
この日は今週のプロジェクトの発表の日でした。僕たちは「Evolve Back」をコンセプトにして、プロトタイプを作りました。「42年後の人たちに、今と変わらないコスタリカの虫の音と光を感じる」体験を作るために、テーブルに緑の毛布を掛けて、そこに光を当てた空間を作りました。音は実際にジャングルで録音した虫の音を加工して、流しました。プロトタイプの写真と発表資料を下記に載せておきます。
発表自体はうまく行ったと思います。プロトタイプもやりたかったことは形に出来て、被験者に僕たちのやりたいことを体験してもらったと思います。その後に、チームでハイタッチして、すごい楽しかったです。僕が貢献できたのは、ちょっとのアイディア出しと発表資料の作成でしたが、みんなが僕を迎えてくれたと思っています。（来週はもっと貢献したい！）
すごいローテクなプロトタイプで、僕の出る幕はほとんどなかったですが、こんな簡単なプロトタイプでも体験を作れるんだなと感じました。すでに自分の作ったものへのバイアスかもしれませんが。