Zoom、Discord、Slackの特性とは？　エンジニアとデザイナーの最適なコミュニケーション方法について考える

クライアントとエンジニアの付き合い方

五ヶ市壮央（ごかちん）氏（以下、五ヶ市）：次はこちらいきましょう。

Michiko Sugai氏（以下、Sugai）：今チャットのほうで、Zoomのチャットである。こちらですかね。「クライアントと一緒に……」。

五ヶ市：「クライアントと一緒に作業というお話がありましたが、具体的にどんな作業をされているのでしょうか？　エンジニアとも一緒に作業されますか？ エンジニアとデザイナーのコミュニケーションが減っているので、一緒に作業してみたいです」。

これはいろんなパターンがあります。まずクライアントというところで分けていきましょうか。

プロジェクトの初期だと、まずは私たちクライアントのことをデザインパートナーと呼んでいます。、パートナーさんのほうが、ユーザーのことも企業のことや、その組織でのうまいやり方みたいなところも知っていることが多いです。なので、大量にインプットをもらったり、このmiroを使ってヒアリングをしていくみたいなところで、パートナーのみなさまにはご協力いただくことが多いかなと思います。

プロトタイピングみたいなのも、この付箋レベルで「こういう機能をこのタイミングでこうやって使いたい」みたいなのをガンガン出していくような感じで一緒にワークしていきますね。

ちょっとデザインが作れる方とかワイヤーフレームを書いたことがある方みたいなパートナーさんが参加いただいたときには、もうワイヤーフレームをその場で一緒に作ることもあります。他にも、miroやFigmaでデザインデータを一緒にいじるみたいこともやっていきますね。 文言 レベルであれば、もうそのままいじっていただきながら「こっちがいいんじゃね？」みたいな話をすることはよくあるかなと思います。

次の質問は「エンジニアの方とのコミュニケーションが減っている」。ここに関しては、私はどちらかというとエンジニアの方がいてくれたらめっちゃハッピーと思っていることが多いです。まず参加していただくだけで「あれを聞きたい」「これを聞きたい」という欲求が大量に出てくるので、まずは減るというシチュエーションがあまりないかなとは思います。

作業の状況としては、初期であれば、情報設計みたいなところでエンジニアの方にお手伝いしていただくことが多いです。後半であればどの組み合わせで……あっ、みっちーさんいるじゃないですか。みっちーさん！

Sugai：はい。

五ヶ市：みっちーさん、このあたりって何か回答できそうなことありますか？

Sugai：今、作業に集中してた……どうしよう（笑）。

五ヶ市：そうですね（笑）。エンジニアとデザイナーのコミュニケーションが減っているのかという質問です。

Sugai：あーはいはい。それで言うと、とにかく一緒に作業、さっきのDiscordのみんなで作業するみたいなのもあったんですけど、これはけっこう誘っていました。なので、「この時間エンジニアいるから来てね！」みたいなことを言ったりしていましたね。

あとは、私がもともとシステム寄りなので、「システムの人たちはこういうこと言っているよ」みたいなことをデザインの人に言って、PMとしてあっち行ったりこっち行ったりしながら、とりあえずコミュニケーション量というか、情報を流すことをとても意識していました。

五ヶ市：ありがとうございます。

Discordを使ったコミュニケーション

齋藤恵太氏（以下、齋藤）：いいですか？　

五ヶ市：あ、どうぞどうぞ。

齋藤：「やばいときこそDiscord」みたいなところはけっこうあるかなと思っていてます。何かトラブルが起きて、仕様ひっくり返りましたみたいな感じで「パー」とか

「ワー」ってなっているときって、やっぱりみんな不安になるんですよね。チーム内での不安が高まってくるであったりとか、それを個人で抱え出すみたいなこともあるので。

「とりあえず1回集まって話し合おう」って言って声をかけるだけで安心するみたいなところもあったりします。その状態をなるべく早く解消するみたいなところで、緊急避難的にもDiscordに集まったりZoomで話をするみたいなのは大事かなと思います。

五ヶ市：うんうん。

Sugai：とにかくやっぱり、出てきてたと思うんですけど、頻度というか、とにかくちょっと「ん？」と思ったらすぐにDiscordに集まる。

Zoomだと、じゃあ発行したから「じゃあここ来ようね」みたいな手間が発生するので、ちょっと障壁があります。でも、Discordだと「今スタバ（チャンネル名）にいるね」とか「タリーズ（チャンネル名）にいるから来てね」みたいな感じで、つなぎっぱなしにして相手を待ってていい。相手が時間のあるときに来るみたいな感じで、わりとお互いの作業をしながらお互いを待つ的なこともできた気がします。

齋藤：声をかけられて、答えたくなければ返さなければいいので、発言するハードルとかコストみたいなものをいかにゼロにできるかというところだけを考えるみたいなのが大事かなと思います。Discordをちゃんと使えばわかるんだけど、これがめっちゃ低い。Slackよりもぜんぜん低い感じです。

五ヶ市：隣に行きますか。「不安定を克服するのではなく連れ添う……ということでしょうか」。

不安定さに関しては、なんとなくですが克服する、連れ添うというよりも、この不安定さによる肉体的や脳みそ、心のリソースも、いかに軽くしていって爆速で本質的なところにリソースを集中させるかみたいな考え方です。なので、不安定を極力軽くするとか、その壁を減らして最速に本質に届くみたいな感覚が近いかなと思います。

なので、極力連れ添いたくない。手放してはいきたいですね。

Sugai：（笑）。

五ヶ市：とはいえね、無理なんですよね。だいたい隣にいるので、うまく付き合っていくみたいな感じですかね。

私たちあれですね、カヤックさんはすごく正しいタイムスタンプでやっていただきましたが、私たちは全力でぶちぎりましたね。じゃあちょっといったん恵太さんに返しますね。

齋藤：はい。いったん切りましょう。ありがとうございます。

（一同拍手）

勉強会の学び

齋藤：じゃあ、どうしていきましょうかね。とりあえずこのあとディスカッションみたいな感じになりますが、カヌーさんと五ヶ市さんでお互いのプレゼン見てどう思ったか。とりあえず感想交換からいきましょう。

五ヶ市：ああ、なるほどー。

高田一史氏（以下、高田）：実は今、我々の社内Slackも同時に裏で盛り上がりを見せておりました。なんていう……目からずっと鱗が落ちていましたね。

齋藤：（笑）。

高田：一番やっぱりすごくいいなと思ったのが、カヤックは鎌倉という場所で、いろんな得意技を持ったクリエイターが一緒に集まって一緒に作ることをすごく大事にはしているんですよ。それがなぜ大事なのかということが非常に言語化されて整理された感じがします。

話を聞くなかで「このプロジェクトでこうやって使えるんじゃないか」とか「今のPMチームのメンバーにこういうアクションしてほしいな」というアイデアがどんどん生まれてきました。そういう意味で非常に楽しかったし、勉強になる内容でした。

齋藤：ありがとうございます。ありがたいのでもうちょっと話聞きたいなと思うんですけど、カヤックチームの方々からそのあたりについて、何かコメントとかあったりしますか。

高田：松田さんどうです？　

松田氏（以下、松田）：しゃべれます。聞こえますか。

齋藤：聞こえてます！

松田：発表ありがとうございます。とても感銘を受けました。とくに、我々は、コロナの影響で本格的にオンラインの働き方が始まってまだ1ヶ月経っていないぐらいです。この観点からもすごく新しい知見を得られました。

すごいこれリアクションがわからないから、ずっと喋り続けていいのかわからない（笑）。

高田：ありがとうございます。

齋藤：ありがとうございます。じゃあ、ういっちさんいけますか？

渡邉宇一朗（ういっち）氏（以下、ういっち）：やばい。油断してた。

そうですね、聞いてて、さっき松田も話したんですけど、オンラインはやっぱコミュニケーションの面でやりにくい部分があるのかなという固定概念がまずあると思います。そこが今回コロナの件で強制的に取っ払われたという状況です。

今うちもけっこうオンラインを取り入れながらやっています。その中で「あれ、案外できるな」と今思っていて。もっと工夫していく面もあるなというのは以前から感じていました。今日聞けて参考になることがいっぱいあったので、うまくいくかはわからないですけど、いろいろ取り入れてみたいなというのはすごく思いました。ありがとうございます。

コミュニケーションを盛り上げていく

齋藤：そうですよね。ありがとうございます。オンラインでやることによって、全部デジタルに乗っかるから記録できるような利便性もあるし。

あと、さっきのじゃあ裏のSlackで盛り上がってます、みたいな感じで、Zoomがメインラインで走りながらSlackでどんどん盛り上げるとか。うちだとScrapboxの議事録で盛り上がるみたいな感じで、1個のことをやっていてもマルチスレッドになれると考えています。

「逆に現実を超えてくる」みたいなところを見つけて楽しんで、「もっとやりたい」みたいな感じに盛り上がるんじゃないかなと最近思ってたりします。

ういっち：あと、今日気づきがあったのは、若い人とかは逆に対面よりオンラインのほうが実は言いやすかったりコミュニケーションを活性化する可能性あると考えていて。やっぱmiroみたいなおもしろいツールなどを使って発言し易い環境を作るというのは、すごくいいアイデアとしてうちもやってみたいなとは思いました。miroでブレストするとかってときに付箋出せるじゃないですか。

ういっち：うんうん。

齋藤：さっきの質問みたいな感じで。あそこに書く内容って、本当に属人化した情報が削ぎ落とされるんですよね。誰が言っているかわからなくなるとか。

貼っている人とかも見えないし、字がきれいとかそういうのも関係なくなります。そういうところで、現実世界でのヒエラルキーみたいなところを排除して本質的にブレストができるみたいなのは、こういうところなんじゃないかなと感じたりします。

ういっち：確かに。

齋藤：だいたいなにやってもmiro全押しみたいな感じになって、ちょっとキモいんですけど（笑）。

僕はちょっと大仏のほうの北川さんがすごい気になっているんですけど。先ほどからめっちゃ考えられているような感じなので。

北川尚宏（オペロン）氏（以下、北川）：ありがとうございます。いや、めちゃめちゃおもしろかったです。

僕が一番いいなと思ったのは、なにか問題が起きたときに、クリティカルに何か打ち手をやってダメでも諦めずにいろいろやる姿勢がすごくいいなと思いました。

やっぱりなにか1個の問題ができたときに、いきなり解決できるというスタンスでなく、うまくいかなかったものはうまくいくようにやる。うまくいったものは継続してやっていくみたいな、そこは見習いたいなと思った次第です。

齋藤：そうですね。そのへんについては僕らの考え方のけっこう根幹的なところみたいなのが「この超不確実で難しい時代に正解ってないよね」みたいな。

その中で僕たちは新しい事業であったり、その中で一番確からしいデザインをしなくてはいけないと考えています。そもそも考え方として「正解を知らないよね。だからやってみなきゃいけないよね」みたいなところについては、わりかしメンバーとも共有できているのかなと思っていたりします。僕らの仕事がすべてその前提に乗っかっているみたいな。

北川：カルチャーとしていいなと思いました。

齋藤：ありがとうございます。じゃあ、逆に五ヶ市さんからいくらか感想をお返ししていこうかという感じですか。

五ヶ市：そうですね。ちょうど今の文脈で不確実性との戦いみたいなところをGoodpatch Anywhereはかなり意識しているところです。当然お話の途中で「そうは言ってもプロジェクトのやり方って状況によって毎回変わるじゃん」みたいな、「毎回違うんだよね」というお話をしたと思います。

最初から全部違う前提で変なことばっかりやっているかというと、決してそうではないです。序破離じゃないですけれども、ちゃんと体系的なものがありつつ、どう崩していこうかなというところの起点みたいなのとかあったりしますと。

今回の話で、起死回生の武器がPMBOKだよというところで、PMBOKを採用されたところのその先に議論にあった、「チーム全体で1つのことに取り組んだので」といったところや「客観的に体系化された知識によって共通認識が生まれた」で、プロジェクト全体を俯瞰できる状況を作ったのと、きっとさらにそこから崩していったりされますよね。現実に落としていくにあたって。

やっぱり型があった上で、全体が俯瞰できる気持ちの余裕や作戦を立てられる状況にしておくことがすごく大事だと勉強させてもらいました。

このPMBOKというところに行き着いたのも、けっこうクラシックな方法ですもんね。そこもまた興味深いんですけど。ここPMBOKにしたところはなぜかや、ほかに何を取り入れようかなって検討されたかなというのも気になります。

高田：PMBOKを選んだ理由はめちゃくちゃ吟味をしたわけではないです。ただ「最も古典だからこそ最も基礎的であるかな」という部分は思いとしてあります。

というと、やはりロフトワークさんが、同じようなシチュエーションを経験する中であの本をまとめられたと思います。その状況がたぶん弊社に非常に近かったことがテキストを採用した大きな理由かなと思います。