スペクトラム東京の登壇後語り
Peel & reveal! mikan’s Design Talk
こんにちは、mikanでデザイナーをしています、三上颯太です。
同じく、mikanのデザイナーの永崎です。
この番組は、英語アプリmikanを運営するデザインチームによるポッドキャストです。
デザインやプロダクト開発、組織や働き方に関して、
ちょっと役に立ったり、役に立たなかったりするような、
よもやま話を配信します。
本日は、12月にスペクトラム東京というデザインカンファレンスに登壇してきた、
たけっちゃんを呼んで、その後語りを話していこうと思います。
たけっちゃん、12月お疲れ様でした。
お疲れ様でした。
どうでした、イベント?
人生初の登壇で、本当に緊張したんですけど。
でも、結構1ヶ月前くらいから、会社のメンバーとかにも協力してもらって、
何回かプレゼン練習を会社でやらせてもらったりとかできたので、
当日はすごい楽しめましたね。
緊張してそうでしたけど、楽しめたらよかったです。
結構、社内でも3回、4回くらい、
Zoom繋いでたけっちゃんのプレゼンを見て、みんなでコメントする回ありました。
面白かったです。
本当にありがたかったですね。
あれのおかげですごいブラッシュアップできたところはあったので、
みかんの人たちは本当にハートフルだなと、改めて思いました。
でも、タイトル変えたいとか言いながら、
タイトル変えるのは許されないから困るみたいな話もされてましたね。
そうですね。
あと、当日の話をすると、
思ったよりたくさん人が聞きに来てくださって、
すごい嬉しかったなと思っていて、
わりと私がやったステージがローカルステージっていう小さいステージだったんですけど、
席も全部埋まってて、
満席。
少し立ち見で、
そうなんですよ。
少し立ち見で聞いてくれてる人もいるぐらいの感じだったので、
それがすごい嬉しかったなと思ってます。
スクラムライクなタスク管理
結構反響ありました?
その発表した後も。
そうですね。
ちょっとSNS上はあんまり観測できてないんですけど、
結構当日とかは、
発表が終わった後にAMAセッションって言って、
聞いてくださった人たちとQ&Aする時間があって、
それも結構人が来てくださって、
時間いっぱいいっぱいまで質問があるぐらいの感じで、
足りないんでもうちょっと時間くれませんかって言って、
その後ちょっと話したりとか、
懇親会でもわざわざ質問しに来てくださったりとかする方がいらっしゃって、
皆さん熱量がすごい高いというか困ってる方が多いなって思いました。
なるほど。お疲れ様でした。
そのテーマが確か、
デザイン品質を諦めないための挑戦、
スクラブで見つけたリソースコントロールの形ってちょっと読み上げてるんですけど、
そういうテーマでしたかね?
そうですね。
結構デザインカンファレンスにしたら若干ちょっと硬いというか、
あんまりキラキラした感じのテーマじゃないなと思ったんですけど、
でも、自分がやってきたこととかを振り返った時に、
他のデザイナーさんにシェアして、どんなものが有益かなって思って、
これまでノートとかでも、
弊社のデザインチームのタスク管理方法をシェアしていて、
割と反響が多かったのが、
私たちがやってるスクラムライクなタスク管理方法の話だったんですよね。
なので、これはもしかしたら結構聞きたい人いるのかもなと思って、
公募の際にちょっと入れてみたっていう感じでした。
結構ライク付いてましたもんね、あのノートも。
そうですね。
結構なんか、特に日本だとだと思うんですけど、
あんまりデザイナーでスクラム回してる事例が少ないっていうのは結構あるんじゃないかなと思って、
私が調べたときもそんなに出てこなかったんで、
結構知りたい人が多いけど、あんまりリソースがないのかなって思いました。
リポートもソースもないわけですよね、きっとデザインチームも。
うまいこと言いましたね。
そんな、登壇時の記事もたけっちゃんはもう書いてくださっていて、
登壇の内容をスライドの写真とテキスト補足とともにノートに書かれているので、
ポッドキャストリスナーの方はぜひそちらも見ていただけたらと思っております。
そうですね。概要欄に後で貼っておきます。
概要欄に貼っておきましょう。
本日の後語りとしては、
ぜひそこの場所で出てAMAとか聞きたいニーズがあるからこそ困って質問されてたと思うので、
その内容をぜひポッドキャストリスナーももうちょっと深めに当日の内容を補足する形で説明していただいて、
いろんな方にみかんのタスク管理というかチームの動き方とかを共有できたらなと思っているんですね。
ちょっとお伺いしたいのが、実際そのAMAとかではどんな質問が多かったですか?
いくつかあったんですけど、
抜粋すると、PMチームと連携する話とかを登壇の時に話したんですけど、
それの不確実なものの洗い出しを一緒にやってますよみたいな話をしていて、
それの具体的な方法とか工夫していることを知りたいっていう話と、
あとポイントの重さの考え方ですね。
スクラム私たちもやってるんですけど、どういうふうに考えてますか?みたいな話と、
あとはもっと具体的な話になるんですけど、ポイントの単位の定義方法とかをどういうふうにやってますかっていう話を聞きました。
AMAセッションの質問と工夫
かなり詳しくですね。
確かにそこの細かい内容までは登壇時には話しきれないですもんね。
そうですね。ちょっと15分しかなかったんで。
じゃあぜひこの時間自由なポッドキャストで詳しく補足できればと思うんですけど、
まず一つ目が不確実なものの洗い出しに関して。
そうですね。
不確実なものってどういうやつですか?
なんかそもそも結構この質問の背景をちょっと補足した方がいいかなと思うんですけど、
私たちがやってるそのタスク管理の方法のめっちゃざっくり言うと、
稼働日数とポイントの重み付けを計算して、予定とその実施の差分をうまいことコントロールしていきましょうみたいなことを今スクラムライクなタスク管理方法でやってるんですけども、
絶対にアクシデントって起こるじゃないですか。
つまり、軽いタスクだなと思ってたやつが思ったほうがめっちゃ大きくなっちゃったみたいなことですよね。
そうですね。
なので、もともと考えていた前提を結構覆すような大きな方針変更が途中であったりすると、
結構そのタスクが急に膨れちゃったりとかすることもありますし、
考慮漏れがあっても膨れますし、
そういう不確実なものってあるじゃないですか。
それを全部ではないにしろ、ある程度見えないものをなるべく見えるようにするっていうことをやらないと、計画ってうまく引けないよねみたいな話が。
スクラムライクにしてなければ、単純に1個タスクもらったら、それをやるときに不確実設物というか、
情報収集してタスクの完了までの時間のイメージを持ちますけど、
スクラムライクのやり方をすると、1週間とか2週間とか前に、
次の期間でやるタスクを1週間分とか2週間分とか決めなきゃいけないので、
それぞれのタスクに対してどれくらい時間がかかりそうか、不確実なものがない状態でどれくらい時間かかりそうかっていうのをなるべく正確に見つまらないと、
1週間のプランが崩れちゃうっていうことですかね。
そうですね。
スクラムライクのやり方だから大事っていうよりは、
手戻りがないようにするために大事なことっていうところではあるんですけど、
結構そういう話で、
ちょっと回答が遅れちゃったんですけど、
これに関して不確実なものを洗い出すためにやってること、工夫してることで言うと、
結構PMチームに事前にインプットしてもらうときに、
試作のチェックリストを今だと作っていて、
もともとはデザイナーがセルフでやってたんですよ。
PMチームが持ってきてくれた資料をもとにターゲットユーザーのシーンの想定をしたり、
メインケースとかイレギュラーケースを洗い出したりとか、
デザイナーと何を決めたいのかっていうのをヒアリングするための整理みたいなことを自分たちでやって、
持ってくみたいなことをやってたんですけど、
それを最初からPMに書いてきてもらうっていう風に書いて、
デザイナーにタスク依頼するんやった。これ埋めとけってことですね。
もともとのキックオフミーティングとかって開発チームと合同でやってるんで、
開発チームにも重要な内容、もっと大きいところというか、
なぜこの試作をやるのかとか、いつ頃までにリリースしたくて、
開発はどういうところが決まってたら動けそうかみたいなところの話とかになることが多いんで、
結構この辺のターゲットユーザーの話とかまではできないことが多いんですよね。
確かに。
なんで意外とデザインの構造骨格フェーズとかに入ってから、
この辺の話をもう1回起こした時に、
あれ、実は何か試作のゴールに、
これってちゃんとたどれてる?
ちょっと引き方見せちゃった。
行きたいゴールに対して考慮が足りてなかったりとか、
綺麗に線が繋がってないとか、
っていうのが途中で発覚するってことがありますよね、確かに。
そうなんです。
っていうのを早く発見したいじゃないですか。
だからそれを再現性高くやるために、
そのチェックリストを埋めてきてもらうようにしてるよっていう話が、
まず1つ工夫してることかなという感じですね。
いいですね。
僕も同じくデザインチーム、
僕とたけいちゃんは違うチームで働いてますけど、
同じチームで同様のタスク管理したときは確かに、
僕もデザインを実際に手を動かして作り始めてから、
やっぱ分からないところとか疑問点たくさん出てきて、
PMと思うんで、予見膨らんでとか変わってっていうのは結構経験しましたね。
それがおそらく事前にある程度固まった状態で、
そうなると結構手元にもなくなるし、
ディスカバリーもちょっとシャープにできそうなので、
デザインの速度早くなりそうですね。
タスク管理の運用
普通にやるべきというか、やっていい動きができそうだなって思いました。
そうですね。
そうたさんはそれこそ今回話したような、
スクラムライクなタスク管理方法のやり始めぐらいで、
2Bのほうのチームに引っ越しちゃったので、
いい感じにノウハウが見えてきたら、
2Bチームでもやってみたり、逆にやってみたものをこっちで真似させてもらったりとかは、
やれるといいですね。
なるほど。そんな感じで不確立性を小さくして、
うまく洗い出してプランニングをされていると。
はい。
ありがとうございます。
ポイントの重み付け
次にもう1個来ていた質問としては、
ポイントの重さの考え方ですかね。
そうですね。
ポイントっていうのはそもそもどういうものですかね。
ポイントっていうのは、タスクの重み付けの単位をポイントっていうふうにしてるんですけど、
1ポイントが最小で、数が多ければ多いほど重いっていう考え方ですね。
結構、組織とかによって何ポイントまで持つかとか、
どういう段階にするかとか全然違うんですけど、
みーかんのデザインチームだと、今は1ポイント、2ポイント、3ポイント、5ポイントの4段階で。
めっちゃ重いのは5、すぐ終わるのは1。
一番重いのは5。
そうそう。っていう感じでやってますね。
この質問をくださった方は、
自分のチームでは時間で考えているんですけど、
結構難しいなと思っていて、
このタスクは4時間かかるはずで、このタスクは2時間かかるはずでを考えて、
1週間分考えるみたいな感じで押されていると。
っていう話をされていたんですけど、
どういうふうに単位考えたらいいか難しいんですよねっていうお悩みだったんですよ。
それってなんで難しいことになるんですかね。
正確なことはご本人にしかわからないかもしれないんですけど、
私が読み取る限りだと、結構その時間って、
結構そのタスクとか人によってめちゃめちゃ依存しちゃうと思うんですよね。
だから、
シミアの方は早いみたいな感じですかね。
そうそう。そういうこともあったりとか、
その人の得意不得意だったりとか、
同じようなバナー作成とかのタスクでも、
何のバナー作成かによってかかる時間がかかったりとか。
変わりそう、確かに。
そうそうそう。そういう結構依存性があるなと思っていて、
みかんだとその時間換算を禁止にしてるんですよ。
まさに理由は今のようなところで、
その依存性をなくすために禁じておりますっていう感じで。
なるほど。
そうなんですよ。だからポイントも、
ポイントはあくまでそのタスクの重さを測るものっていう風に、
その人がつけるからこのポイントの重さみたいなものもなるべくなくすようには。
なるほど。
気をつけてますね。
っていうことはイメージですと、
時間換算をしていると、
例えば単純に本当にポイントがほぼイコール時間になるので、
例えば1日のプランニングをするなら、
8時間8ポイント分をどう割り振るかみたいな考えになるかと思うんですけど、
タスクの重さベースになるなら、
単純にタスクの重さだから、
例えばまだタスクに慣れてない方だったら、
1ポイントで1日使っちゃうかもしれないし、
すごい早い人は5ポイントとか10ポイントとかを1日で消化するかもしれないし、
っていうので、
人によっては結構消化可能ポイントみたいなやつが、
ばらつきがあるけれど、
それを良しとして設計されてるって感じですね。
不確実性の管理
そうですね。
なるほどです。
他にも何か工夫してること、
工夫というか考え方ってヒントがありますか?
そうですね。
さっき言ったみたいに何個かルールは、
確かに言われてみれば作っていて、
例えば不確定なものはもうタスクに入れない。
ってことはさっきの話につながりそう。
そうなんですよ。
なので、不確実性のあるものがあったら、
それを明らかにしに行くタスクを作るっていう方が確実。
自分たちの作業量としてちゃんと換算できるものの方が良いよねっていうのがあって、
結構これ割と難しくて、
もう全然まだまだやっちゃうところもあるんですけど、
なるべくそれがないように。
不確実なものがあったら早めにキャッチして、
それをヒアリングしに行ったりするような感じにするっていう。
で、分かってからチケットにする。
分かってからタスクにするっていうことを徹底していくと、
多分より精度が上がっていくはずだと思っておりますっていう感じですね。
なるほどです。ありがとうございます。
あとは何だろう、大盛りにしない。
大盛りとは?
なんか、それこそ颯田さんとかがやってくれてた時代とかは、
もうみんなでめちゃめちゃタスクをいっぱい持ってたじゃないですか。
頑張るぞって気持ちが強すぎたときですね。
そう、これくらいなんかやっちゃいたいみたいな。
お気持ち表明みたいなのがやっぱりあると、
確かに確かに。
なんかすごいやっぱこうツメツメにしちゃうところがあって、
なんかその大盛りスタンスをやめて、
まずよそれる分だけよそって、食べ終わったらおかわりするみたいな。
ご飯のたとえ。
ご飯のたとえです。
っていう風にしようねっていう風にしてて、
なんかノートとかに書いている計算方法のシートとかは、
そのなんかいっぱい、自分が入れられるご飯いっぱい分がいくつなのかっていうのを、
数値で計算するために作ってるシートっていう感じなんですけど、
ちょっとさっき話してて思ったのは、
さっきその質問をくださった方のように、
時間単位でやってると、
プランニングの量ってすごい調整しやすいように感じるだろうなとは思ったんですが、
1日かける8時間かける5日分のタスクを決めるって形だと思うので、
ただそのポイント制になって、
タスクの重さになると、
私が1週間で何ポイント消化できるのかがわかんないはず。
それをどういうふうに計算してるのかっていうのが、
そのたけっちゃんのノートに書かれてるわけですね。
そういうことになります。
隠しても仕方がないので少しだけ話すと、
過去の実績をもとに、
私たちは何ポイント分だっていうのを見つけましょうっていう考え方でしたね。
そうですね。
可動日数と、過去3回分の実績の平均を見て、
自分が次の1週間でできるタスクの量っていくつなんだっけっていうのを出していくようなものですね。
日数が大事でしたよね。
そう、日数大事。
それこそ来週祝日ありますけど、
1週間のタスク量としては、
例えば10ポイントだと思ってたけど、
それは5日間可動での10ポイントなわけであって、
月曜日休みなんだったら、それは8ポイントになるはずだよね。
でも忘れちゃって10ポイント入れちゃうよね、よくみたいな。
そうそう、そういう感じですね。
だから、休みもそうだし、
可動ができないときは、
基本的にちょっとずつ引いていく必要があって、
例えば風邪でちょっと病院に行かなきゃいけなくなっちゃったから、
休みましてだったら、半休取るんで、
じゃあ0.5引きましょうとか、
面談とかで対応が多いから、
作業ができないなみたいな。
ってなったら、じゃあその分もちょっと引くとか、
ってことをやったりするようなことをしたりしてますね。
なるほど、それがみかんでいうポイントの考え方か。
はい。
ありがとうございます。
1ついただいてた質問はどんなことでしたか?
ポイントの単位の定義方法ですかね?
うんうん、ポイントの単位。
はい、みかんだと今は1ポイント、2ポイント、3ポイント、5ポイントで定義してますよっていう話をさっきちょっとしたと思うんですけど、
ちょっと詳細に言うと、
1ポイントがやることが決まってて作業量も少ないものにしていて、
私たちは最初のタスクの書き出しとかって、
どの施策でもあんまり変わらないから、
1ポイントかなみたいな定義にしてるんですけど、
それよりも、やることは決まってるんだけど、
作業量はあって、1ポイントよりもちょっと重いかな、みたいなやつは2ポイントになってくるイメージですね。
ポイントごとにそれぞれ定義があるんですね、言語化された。
そうなんですよ。
で、3ポイントはちょっと考えて作る必要があるもの。
単純な作業ではない。
なるほど。
あるじゃないですか、デザイナーだと。
はい、はい、もちろん。
なんかそういう叩きを作成するときに、
ラフをいくつか、何個か考えられるパターンで用意して持っていこうみたいなことをやるのは3ポイントになったりとか、
そういうようなイメージですね。
これよりも大きいのが5ポイントなんですけど、
ほとんど使ってない。
一旦置いてあるんですけど、
タスクが大きくなりすぎると、結構分解できてないっていうことになるのが多くて、
割と不確実性を少なくするっていう話で言うと、
ポイントは多分3ポイントぐらいまででチケットが分かれてる方がいいんだなっていうことに最近気づき始めたというか、
事実そうなってってるなっていう感じはありますね。
なるほど。
じゃあ一応、1、2、3、5と4段階で設計できるようにしているが、
1、2、3ポイントをいろんなタスクに割り振ったり、あるいはタスクを分割して、
大きいものを1と2に変えるとか、1と3に変えるとかっていうのをしているわけですね。
はい、そうです。
なるほど。それがみかんのポイント定義で、
その定義というか、ポイントの言語化とかとかはどうやって決めていったんですか?
決めるプロセスとかは。
そうですね。私たちはワークショップを開催して、
スクラムのワークショップ
最初にやったのが去年の5月ぐらいなんですけど、
その時は結構スクラムのやり方に詳しいバックエンドチームのメンバーの人に1人アドバイザーで入ってもらって、
一緒にワークショップしました。
ワークショップのやり方としては、
最初にそのサンプルタスクを用意して、
極小、小、中、大で分解が足りないもの、それ以外のみたいな風にスペースを作って、
最初個人ワークでやってもらうんですよ。
このサンプルタスク群がある中で、このサンプルはちっちゃいやつだ、大きいやつだっていう風に、
その各メンバーが判断するんですね。
最終的には、みんなが共通して最小単位だと思えるものを探すっていうためのワークショップなんですけど、
そのためのプロセスとして、みんなが何を共通の重さで思ってて、
何が差分なのかっていうのを把握する必要があるんで、
最初に個人ワークでやってもらって、
その後に見せ合いっこして、
共通してるものとずれを探すことをやるんですけど、
一人一人、何でこれは小にしたんですか?みたいな。
だれだれさんは同じタスク中にしてますけど、何でこれにしたんですか?みたいなことをやっていくと、
少しずつどういう風に考えて、その重さにしたかがわかってくるんで、
お互いにも、はってなるじゃないですか。
ここはちょっと確かに考えてなかったかもとか、
っていう風になるところがあるんで、そういうのを通してちょっとずつ認識を合わせていく風にしていて、
で、そこまでやったら、
第二段階で最小単位を考えるっていうのをやって、
暫定で最初、みんなが1ポイントってつけたものを集めて、
で、そのタスクよりもちっちゃいタスクがないかを一回考えるんですけど、
なるほど。
そのタスクよりちっちゃいものがあったら、それはまだ分解できるって話になるから、
めっちゃ分解しますね。
分解おばけみたいな感じですけど。
で、その最小単位、これ以上もうちっちゃくできないだろうっていう最小単位が見つかったときには、
その最小単位を1としたときに、2ポイントにしてたものと照らし合わせて、
タスクが2倍に相当するものになっているかを見るみたいな。
これを繰り返していって、2ポイントより3ポイントの方が大きいかとか、
3ポイントより5ポイントの方が大きいかとかを相対的に見て考えていくっていうのをやって、
最終的にみんなが想像できるそのポイントのモデルタスクみたいなものを作って、
これって何々と同じ重さかなみたいな話がプランニングのときとかにできるようにするっていうのをやってますね。
なるほどですね。1、2、3、5のそれぞれの重さが適切にその2倍とか3倍とかになってないとあんまり意味ないですし、
そうなるようなモデルケースを作るのか。
ちなみに、じゃあそれでみかんの今のチームだと、1ポイントってどんなタスクなんですか?
今はリファイメントって言って、その最初の見積もりを1ポイントっていう風に考えてます。
PMからもらったタスクの見積もりをするっていうタスクが一番ちっちゃい単位か。
そうです。
なんですけど、つい先日、新しいメンバーが入って、
で、人が変わると、その人が考えるポイントの単位ってやっぱ変わっていくじゃないですか。
なるほどですね。はい。
なんでもう1回ワークショップやろうかなって思って、すごい最近やったんですよ。
ワークショップ。
で、最初単位はちょっと見直してもいいかなって思ってます、今。
いいですね。そうやって進化していくんだ。
そうですね。結構チームが変わると、またやっぱり変わるもんだなって思いました。
タスク管理の進化
なるほど。いやー、詳しくはありがとうございます。
いい。
これを聞いていただくと、みかんのとようなタスク管理が始められるかもしれないですね。
なるほどな。
結構まとめるのも難しかったんじゃないですか。発表資料作るとか。
いや、めちゃめちゃ難しかったですね。
どこまでどういう…
どこまで細かく説明するか、概要を伝えて、で、とどまっていいものかとかですよね。
そうですね。なんか具体的すぎると、視聴者の人を置いてけぼりにしちゃいそうだし、
なんか抽象的すぎると当たり前すぎるし、
当たり前すぎるし、確かにちゃんと見積もり大事ですみたいなとかね。
いやー、知ってるし、みたいになるじゃないですか。
そこがめちゃめちゃ難しかったですね。
その試行錯誤、たぶん1年ほどですよね。
していて、すごくうまくワークしているなっていうのは、
僕が同じ事業のときはワークさせきれてなかったですけど、
僕が抜けてからすごくきれいにワークしているのを感じるので、
相当さんのせいとかではないですけどね。
僕のせいかもしれないけど、そういうことだなと思います。
なるほど。ありがとうございました。
結構このメカンの中でも、たけいちゃんがすごいオーナーシップを持ってくださって、
このデザインチームのいいタスク管理運用っていうのを
めちゃくちゃ試行錯誤してきた歴史があるので、
ぜひそれに悩んでいる方とかは、
Xでポッドキャストをシェアしてもらって、
感想を呟いてもらったりだとか、
たけいちゃんとか僕とかにDMいただいて、
ザクバラに議論したりとかできると嬉しいなって思いました。
はい、ぜひ。
はい、というわけで本日の内容はいかがだったでしょうか。
番組の内容が面白いと思ったら、
ぜひポッドキャストをフォローしたり、
X等で感想をシェアしていただけると嬉しいです。
それでは本日の放送はみかんのみかみと、
ながたきがお届けしました。
ありがとうございました。
