エクサウィザーズのPMが考える最高のチームマネジメントプロセス / AIプロダクト事業部 宮田大督
こんにちは。ExaWizards でPM(プロダクトマネージャー)をしている宮田(twitterアカウントは@miyattiです)です。
前の記事でエクサでやっているプロダクト開発のプロセスの全体の流れを説明させていただきました。
あれは実は前振りなところがあって、今回はここ1年もっとも重要視してきたチームマネジメントをどうしてきたのか?というところを書きたいと思っています。
正直プロダクトをあてるのはどんだけがんばっても成功率1、2割の世界なんていわれたりします。その中で、結局大事になってくるのは1回のプロダクトの成功確率を限界にむりやりあげることよりも、3割バッターだらけのチームを育てて運営していくことかなと思ったりします。
そういうチームができあがれば、一度失敗したとしても、いつかは当たるわけです。しかもナレッジはチームにどんどんたまっていくのでどんどん成長していく。そんな3割、4割バッターが打席に立ちまる機会をあたえられれば、必ず点数をとることが期待できます。
そんなチームをPMとしてメンバーと一緒に作れればなと思ってやってきてます。結果どんな仕組みのチームになっているかというのを今回はお伝えしたいと思います。
「CareWiz 話すと記録」のご紹介
前回の記事でうちのチームがやっているプロダクトについては簡単に紹介しているので、そちらをご確認いただければ!
音声入力で介護記録ができるiPhoneアプリです。この開発を1年ちょっと前からやっています。チーム構成は時期によって違うのですが、PM(私)が一人、エンジニアが2−3人、デザイナが1人、ドメインスペシャリストが1−2人、BIZ(プロダクト責任者含む)が2−3人といった形で、大体10人前後。そして開始時点ではギリギリ違いましたが、基本的にずっとリモートでやりとりをしてきています。リモートについては、いろいろ大変なこともありますが、ただ今回のようなスタイルのマネジメントはリモートだからこそできた部分も多かったなと振り返ると思います。
そんなチームでどんなチームコミュニケーションの仕組みをやってきてるか?ご紹介させていただきます!
基本のマインドセット
チームマネジメントは、別にチームのルールを決めたり会議の時間を決めたりコミュニケーションツールをいろいろ悩んで選ぶことが根本ではなく、一番大事なのはチームメンバーに以下のようなマインドセットを持ってもらうことだと思います。
基本1 すべての仕事は仮説検証であるという認識をもつ
まず第一に大事なのは「すべて仕事は、ただ作業をしてアウトプットすることではなく、思い描くビジョンにちかづくためにどうやってアウトカム を達成するか?そのための仮説検証の作業をすることである。そのためには職種や役職に関係なくやれることは何をやっても良い」ということ。
前の記事でもかいたように、特にプロダクトがPMFを達成して、勝手に物が売れる状態になるまではすべての瞬間、すべての仕事が広い意味での仮説検証です。そしてそれが究極やることだから、他のチームメンバーがどうとか関係ないし、どうコミュニケーションをとろうが好きにすれば良いと思うのです。
一見チームをつくるとは真逆の個人プレイへの煽りのような感じありますが、いろいろチームで仕事をして傷を舐め合うような関係をきづいたり無駄に依存しあって攻撃し合ったり関係ないやと無責任なチームになるぐらいなら、スタンドプレイだけでなりたつ個の集まりのほうがマシだと考えています。
基本2 チーム全員がPMでありPOである(ぐらいの意識をもつ)
ということで、チーム関係なさそうな話がつづきますが、基本2として、全員がプロダクトを自分が作っているのだという意識をもつこと。
仮説検証をやる頭脳的な人がチームにひとりいて、それ以外のメンバーはそれをヘルプする作業者である、というチームはどうでしょう?
確かにビジネスの不確実性が低ければ、あらかじめ綿密に立てた計画のもと、チームは役割分担を明確にし、上下を明確にし、軍隊のように命令を遵守するかたちで動いていくのがいいと思います。しかし、不確実性が高い状況であれば?その真逆ですね。何が起きるかわらかない状態では、小さいチーム構成で、刻々と変わる状況のなか、ひとりひとりが毎日状況判断をし、仕事をするのがいいはずです。
状況変化に一人だけでは対応できず、そのヘッドがボトルネックとなってスピードがおちます。またすべての広範囲な知識をそのヘッドだけが持つと言うのは難しい。
極論ひとりひとりがPOである意識でものごとにのぞんでいく。チーム全体がプロダクトの説明責任をもつようにメンバーに意識をもってもらう。ここも大事です。
基本3 チームメンバー間で、お互いに足りない知識を補い合う
ここではじめてチームマネジメントっぽい話になります。
完璧な一人がヘッドにいない、と言う状況でみんなそれぞれがPOであるとすると。ただ問題なのは、やはりデザイナーはやっぱり技術の知識はたりないし、エンジニアはデザインの知識がたりない。
その状況下では、いくらひとりひとりが責任者としてふるまえといっても間違った判断をしがちなのは間違い無い。なので、そこを補うためには、ある意味しょうがなく、チームメンバーどうしで徹底した情報のオープン化が必要で、ここではじめてチームというものの意味がでてきます。
ふわっとした思いつきの議論段階から周囲に共有し間違いや改善点の指摘をもらう、作業しはじめても常に相談し、不安なことがあれば相談する。そうすれば、一人一人が完璧でなくても責任をもった意思決定ができていきます。
これが実現されるためには圧倒的な心理的安全性が重要。そしてお互いに阿呆になれる空気感。かっこつけようとか、チーム内で一人有意にたとうとかおもったら、崩れます。だから心理的安全性が大事という話です。道徳的な意味で心理的安全性が大事なわけではないです。
基本4 これは民主主義ではない。衆愚性にならない。
最後は基本というか、注意するべきこと。いくら情報を共有し、相談しながらすすめるといっても、それはみんなが賛成しないと先に進めないとかそう言う状況を作ることではないです。
ひとりひとりが責任者。どんだけ反対されたとしてもそのひとがいけるという仮説をもっているなら、さきにすすめるべきです。お互いが足を引っ張って進行を遅くしてはいけません。とはいえ、本当に後戻りできない施策に関しては、本当の意味での責任者や民主主義で判断するのはありです。
ただ前の記事で示してきたように、仮説検証はステップ性で不確実な状況をリスク少ない形で仮説検証をするしくみをとるべきです。そうすれば、後戻りができない意思決定というのは比較的少なくなるはず。その状況下ではどんどんアグレッシブにやったらいいはず。
というようなことをチームメンバーには繰り返し繰り返し伝えるのが大事と考えています。しかしながらこれを伝えたらはいそうですかとなるものではないです。やはり仕組みでマインドセットが勝手に納得感とともに伝わるというのが良いのかなと考えており、そんな感じでやってきました。以下の話はそう言ったチームマネジメントプロセスの話になります。
チームマネジメントプロセス 基本編
どうしたら、(1)すべての仕事は仮説検証である (2)全員がプロダクトの責任者である (3)お互いに情報を補足し合う (4)衆愚性にならない というようなマインドセットをもってもらえるようになるか?
マインドコントロール?ってそんなのできるわけない。社内で啓蒙活動で講義する?なるほどなーときいて納得しておわっちゃいます。
一番は、日常的なミーティングで自然とそういうマインドセットをもつようになるようなルールでMTGをすること。それが「リーンコーヒー」というMTGです。私もいろいろ調べているうちにこの手法を知り試してみたらこれはいいなとおもって、ずっとやりつづけています。とはいえ、本家のやり方そのままという感じではなくて、いろいろ応用しているため、本家を知っている人からするとそれはリーンコーヒーでは無い、という感じかもしれませんがご容赦を。(本家のやりかたはこちらのスライドなど参照ください)
リーンコーヒー形式とは?アジェンダがいらないMTG形式といわれるもので、参加者が冒頭10分で話したいことを付箋で書き出して即興アジェンダをつくってから、議論を始める形式のものです
話すとチームでもこの形式のMTGを朝と夕方に30分ずつ実施して、ほぼ毎日1年以上続けていて数えたら全部でだいたい800回ぐらいやってました…(定常以外の特別開催含む)。それぐらい日常的にやっているものですが、一旦やり方を下記に記します。
ステップ1
話すテーマは「今この瞬間どうしたらビジョンに近づけるか?アウトカム を出す施策の仮説について」「アイディアでも検証中の進捗状況でも結果の報告でもOK」「といいつつ関係ない話でもOK」「仕事してる風のアリバイ報告はいらない」とする。
ステップ2
各々がはなしたいことを付箋(テキストボックス)に書いて場に共有する(スライドにはりつける)。だいたい10分以内。その間黙って作業。はる場所は自分で重要とおもうなら左上に、どうでも良い雑談なら右下にはって、どんだけ話したいか意思表示。
ステップ3
書き終わったら、5分ぐらいでいったんどんなネタがあるか、みんなで確認する。時間あるときは1枚30秒ずつぐらいで書いた人にいったん説明してもらう。気になるネタには、それぞれ🔴で「あとではなす」目印をつけておく。あと顔文字でリアクションをつけたりもする。(最近はこのステップをとばすようになってきている)
ステップ4
残り20分ぐらいで、基本的には左上から(本人が重要と思っている話から)ファシリテーターが付箋をえらんで、「これかいたいひとだれですかー」と話しをふっていく。(ファシリテーターはいなくてもOK。その場合は自己申告で。)時間がなくなればそこまでで。左上の重要と思っているやつから話すから右下までいかなくても最悪OK。残り時間少なくなったら、赤ポチがついているやつだけピックアップしたりもする。
なぜこれが伝えたいマインドセットをうまくチームメンバーに伝える効果があるのか?っていうのを考えてみると以下の通り
(1) すべての仕事は仮説検証である
これはステップ0でテーマ設定としてそうしている。
通常朝会とかそういうものは、昨日やったこと、今日やったこととかを淡々と伝える場。もしくはアジェンダで事前にファシリテーターがきまった道筋で一方的に話をしていく場とかになりがち。そうではなく、一人一人順番に仕事のことを話すのでもなく、いまここでおもいついたこと、まえからきになってたことをゼロベースで考えて書いてくださいと設定することで、半分アイディエーションの場となる。
なお、この作業はたんたんと仕事のことをいうだけのミーティングと比べると楽しいのでつづきやすい(重要)あ、あと重要なルールとして任意であるということ。本当に役に立つとおもわなければこなくてよい。相談したいことがあるひとだけくるということにすることで、形骸感をなくす。
(2)全員がプロダクト責任者である(ような気持ちをもつ)。
これは、つまりアジェンダを誰かが設定してそのとおりにやるわけでもないし、あと自由に発言してくださいといってありがちな(自分がそうですが)声が大きい人だけがひたすらしゃべるみたいなこともおきない。
事前に10分間だまってかきたいことを平等にかくので、マネージャーだろうと社員だろうとうるさい人だろうと静かな人だろうと平等に発言できるチャンスがあります。ポイントとして、誰がかいたかってのもわからないようにしてます。それがわかるとあー今日もあの人の発言がおおいなーとかになってなえる。匿名性による平等性みたいな雰囲気重要。
(3)お互いに情報を補足し合う。
これは思っていることをひとりかかえてもんもんとするのではなく、毎日定例で少しずつ時間をとることで、早めに形になってない段階での情報共有がおこなわれるようになる。まぁ実際は1日30分から1時間ではかぎりがあるので、議論が白熱しそうだったら、あとは別MTGでやりましょうとか、チャットでやりましょうってなるけど、そのきっかけとして良い感じに使えます。
(4)衆愚性にならない。
別にこれはこの場で何か意思決定をするプロセスではない。あくまでもお互いにこうですよーとみせあって、話すだけ。もちろんそこで多数決とって意思決定として使いたい人は使えば良いけど、それは結局その人の責任でやること。反論されてもやりたきゃやれば良いと言うスタンスにはなる。ネクストアクションもマストではきめない。生産性を求めすぎないのがポイント。
ということでずっとやってるリーンコーヒー。自分がやりはじめて自分がファシリする時期がながかったですが、半年前ぐらいからファシリは他のメンバーにまかせたり、私が参加しないタイミングもふえてきたりしてますが(別チームを手伝うようになったりしていて)それでもつづいています。
もはや話すとチームにとっての呼吸みたいなもので、他のMTGはなくてもこのMTGがあれば基本は情報を共有しあえ、雑談を行って心理的安全性の確保もできるチームコミュニケーションの基本となってます。
ツールも別にmiroとか特別なものではなgoogle slideでやってます。みんなが簡単にアクセスできてだれもがすぐスタートできるツールということでgoogle slideを利用することに。
ということで、極端な話これだけやってれば、チームコミュニケーションはうまくいくきもしていて、仮説検証プロセスもうまくまわるきもしたりするぐらいです。今日の記事でもミニマムここだけ参考にしていただくのもありかもと思います。
ですが、ここに書いたことを実際は忘れてしまったり、また発想の場としては流石に時間が足りなかったりいろいろ課題もあるので、応用編が続きます。
ただ、以下の応用編は相当ややこしく、ぶっちゃけここまでやる必要は普通はあまりないと思います!なので実践としてはここまでの話だけでも参考にしていただき、あとは企画のアジャイルプロセスに興味があるとか、よいチケット管理の仕組みを考えてみたいとか、マニアックな興味がある人だけ読んでいただければ良いかなと思っております…。
チームマネジメントプロセス 応用編
応用編としては、リーンコーヒー以外にもいろんなコミュニケーションを、プロダクトマネジメントのフェーズによって変えながらやっていく話になります。その大まかな全体像を表したのが上の図です。
縦軸は、仮説検証のタスクが段階的にいい感じになって終了するまでの流れをあらわしてます。
仮説検証タスクをチームでコミュニケーションとりながらやっていくわけですが、リーンコーヒーだけがそのディスカッションの場にふさわしいわけではありません。
まずはリーンコーヒー前にもっとふわっとチームで話してから、リーンコーヒーにのぞみます。リーンコーヒーよりもアイディアが出やすい形で雑談します。
で、リーンコーヒーの後はタスク化してそのタスクをアジェンダとしてリーンコーヒー形式ではないMTGでがっつり進捗をおいながら、議論も深堀しながら、そしてそのログを書き記しながらすすめていきます。ずっとリーンコーヒーだとふわふわしちゃうところがあります。
で、一度仮説検証タスクが完了してログまで残したら、こんどはその確認した仮説から新たな精度の高い仮説に移行します。例えば、音声入力の方式をこうかえたらいいかも?っていう仮説を検証して、お客様に聞いたらいい感じだったとして、その調査内容をいちどまとめる。そして、次の段階として、実際の細かい仕様を考えて実装するフェーズがはじまるといったかんじです。(前回の記事参照)
横軸はそういった、仮説検証の不確実性低減するなかでフェーズが上がっていくプロセスです。仮説が怪しい段階の検討MTGと実際に実装する議論MTGは別のMTGを設定していることあらわしてます。
仮説が怪しいDiscoveryフェーズにあるアイディアと確からしいDeliveryフェーズにある開発の議論を一つのMTGでまぜると混乱しがちなので、ひとつのMTGで話さずにあえてわけてMTGを設定したりします。
そのようにして、ディスカバリーでもデリバリーでもそれぞれのフェーズで、それぞれのゴールにむかって、アイディア出しから検証まで、ふわっとした段階から仕様を確定して実装させるまでのプロセスを行うのが良いと考えてます。
応用編では、基本編のようにただただリーンコーヒーを繰り返す形ではなく、そういうスパイラルなやりかたで形式をかえながら、議論の粒度をかえながらすすめていくやり方になります(そしてそれを実践しています)。
という話は若干わかりづらいきがするので詳細は以下のセクションでかいていきます。
縦軸の流れ 仮説検証タスクの完了プロセス
まず、仮説検証タスクを一つ一つ確実に終わらせていくチームコミュニケーションフローについてです。上の図では下に行くほど仮説検証タスクが完了に向かって言ってます。また扱う情報の種類もフロー情報(コミュニケーションのためだけにやりとりされ、ログとしては残さないでいいもの)からストック情報(確定情報としてチームの共通認識をもつために残していく情報)に変わっていきます。
Step1 チャットツールでの雑談(Slack,Teamsなど)
チャットツールで普段からふわっとコミュニケーションをとる。この段階のポイントは、何かメールのように確定された情報じゃないと発信できないとか、空気を読みまくる場にしないということ。思ったことを思った瞬間につぶやく。何か面白い情報があったら深く考えずに送る。あ、なんかふとこの話こわいきがするなーと仕様の不安をかんじたら、いちはやくとりあえずチャットに送る。
話すと記録だと「音声入力のスタートの仕方、やっぱりいろいろ考えたけどこっちのやり方にかえたほうがよくない?」みたいなつぶやきをしてみたりして、一回決まった方針を変えちゃうようなめんどくさい話をとりあず観測気球としてチャットに打ち出したりしたことあります(自分の話)
あくまで文字情報ですし、議論には不向きですが、リーンコーヒーなど直接のMTGではちょっとハードルあるなーと思うことも、チャットツールにはつぶやく感じにしていく。
ちなみにやはりこれがやりやすいのはSlackです。Teamsもチャットはいいですが、チャンネルとかのスレッド形式はだめです。あれはメールの代替で、あらかじめ決まった内容をしっかり考えて発信する設計になってるので…。
あ、もちろんこの段階はチャットじゃなくても、リアル雑談でも1on1のMTGでもいいです。ふわっとした話をどんどんログ残すこと意識せずにコミュニケーションすることで、すぐれたアイディアの仮説がでてくるものだとおもってます。ここを意識して大事にするのがよいです。
Step2 リーンコーヒー(Google slide、miro など)
で、リーンコーヒーMTGです。普段のフロー情報で意識をあっためてるので、リーンコーヒーなどの定例である程度これはなそうというネタが出てくる状態になる。そして話して、人からの意見をきいているうちにこの仮説をどうしたらいいかという追加アイディアがでてきたりします。
そして、いよいよちゃんと仮説検証としてやっていかなきゃいけないなという感じになったら、タスクチケットを作る。というメモをリーンコーヒー中にメモでのこしておく(オレンジ色の付箋をつかってます。応用編としてはgoogle slideをつかってるばあい、右クリックでgoogle keepに1クリックでメモを送ることができるのでいったんそこにおくって、あとでkeepをみて必要なチケットをつくるという技もやってたりします)
リーンコーヒーで話し合われる話としては例えば「XXっていうアイディアおもいついた」「XXの値がのびてるけど、これは先週やったXXのアクションがよかったりしたからだろうか?」「XXを今日もやる」「XXの件ってどうなってますっけ?すすんでます?」とかとか。
思いついた系の話であればチケット作成。追加検証したいという話があってもチケット作成します。
Step3 チケット管理ツールでの議論(JIRA など)
ということで、いろいろ思いついたりやんなきゃいけないなーとおもって進捗管理したいものがあればチケット作成します。あれ、チケットって開発系だけじゃないの?とそもそも思う方もいますが、話すとチームでは、モックを作るチケットや調査するチケットアイディアとして考えるチケットなど様々なパターンでつくってます。
いわゆるTODOリストのようなかんじに使います。仮説検証タスクのToDoリスト。ここにチケットがつくられたら、週に1回の定例MTG(リーンコーヒーとは別)で今週どのチケットにてをつけるかという相談をし、進捗状況をデイリーのチェックインアウトなどではなし、スプリントレビューというMTG(とはいえ、プランニングと同じタイミングでやることが多い)でどれくらい進んだかなどを共有したりします。(この辺の詳細はこの後のセクションで)
やってる最中に、当初たててた計画とは違う中身になったりします。たとえば開発チケットだと、開発当初にこういうことやろうとおもってかいてある仕様とは別の実装をしたりします。
そのときにいちいちやってる最中は、丁寧に書く必要ないです。なんなら口頭でやりとりしたら、チケットに反映してなくても最悪かまわわないとおもってます。(やったほうがいいけど)ただ、そのタスクが完了したら、あとでそのやった内容を知りたい人向けに、丁寧にドキュメント化するのを忘れないようにします。
Step4 Wiki化して今後の議論に備える(Confluence, Jiraなど)
タスクが完了したら、閉じるわけですが、それを閉じるタイミングで、別途confluenceなどのwikiなどにかきうつします。
うちでやってる工夫としては、チケットを完全に閉じる前のチケットのステータスをつくっていて(JIRAでの話)その状態のチケットだけをみることができるフィルターをつくってます。それでそのフィルターで、業務は完了してるけど、まだドキュメント化されてないチケットを確認。仕様として残しておいたほうがいいものだけをピックアップしてWiki化します。
ちょっと特殊なことしてるのは、だんだん書き写すのがめんどうになってきたので、JIRAのチケットの中身を清書し仕様として見える状態にして、ステータスを本当に清書までしましたという状態にします。それでその状態のチケットだけをフィルターで表示できるようにして、そのフィルターの検索結果を仕様としていたりします。
(上記二つともワークフローをいじることができるJIRAのようなツールでしか使えないテクニックですが)
と様々なツールをつかって、仮説検証をすすめます。注意すべきなのはここで進めているプロセスは、仮説検証の作業自体の進行プロセスです。このプロセスが完了したとしても、まだアイディア段階の仮説の調査タスクがおわっただけれあれば、当然仮説検証全体のプロセスはおわっておらず、ようやく次の開発(Respond)系の仮説検証タスクにとりくめるようになるというだけです。その流れは前回の記事で紹介した流れになっています。
では、今度は仮説の不確実性低減させていくDiscoveryからDeliveryの間で、どんなチームコミュニケーションマネジメントをおこなってるかの詳細を次のセクションで紹介したいと思います。
横軸 仮説の不確実性低減プロセス
前回の記事のレイヤー2とレイヤー3の組み合わせの図です。アイディア段階のモック作成を行うために(Discovery)、お客様の理解をし(Sense)実際にモックを作る(Respond)。その後その調査結果をもとに開発段階のプロダクト作成をおこなう(Delivery)ために、再度詳細な技術調査や仕様調査をおこない(Sense)、実際に開発してリリースして使ってもらうことで検証する(Respond)。そうやって仮説は確実になっていきます。
では、まずその低減プロセスのなかで、コミュニケーションでやりとりする情報の大きさ、種類がどう変わっていくのかということを書きます。仮説にもいろいろ種類があるので意識して別のものとして扱うことが大事。また、仮説単体に対してずっと向き合うのではなく、いったん仮説の塊、まとまりのようなものの話からだんだんと小さくしていって詳細な仮説の話にしていくという流れになります。
仮説はいきなりピンポイントにひとつ思いついて、それの検証をはじめるものではないです。まずはおおざっぱに「音声チャット機能」とかもっとひろめに「お客様が何度もアプリをたちげる方法」とかさらに一番ひろいと「プロダクト案」みたいな形からはじまります。
そのレベルのものをいったん、ユーザー調査とかデータで調査しながら、イメージを膨らませてジャーニーとかユーザーストーリーマップとかにしたてていきます。
step1 ユーザーストーリーマップ
ここで重要なのは2次元に自由に考えるということです。いきなり考えたアイディアをリスト化しちゃうと、それぞれのアイディアの関係性がよくわからなくなったりするのでこの段階では自由に、みた人がぱっとあーこういうことやりたいのねってわかりやすいようなまとめかたをします。なので、別にジャーニーっぽくする必要もないとおもっていて、単純に機能のグルーピングとかでもいいとおもいます。で、みんなが議論しやすい状態にしておくのが重要。
であ、ある程度アイディアがでたらそれを今度はリストで並べていきます。
step2 バックログ
バックログはToDoリストみたいなものです。ここは逆に1次元のリストにするのが重要。チームでなにからてをつけるか?というのを議論したり決めたりするのに役立たせる。なので、ジャーニーみたいに複雑な絵だと意思決定がしづらいのです。全体の理解とかは前段階でおこない、その後普段のタスクの管理はこのようなリスト形式でやるのがよいと思っています。
ここにアイディアや開発チケットをならべ、優先順位にならびかえておきます。
マニアックなtipsとしては、 ステップ1をmiroでつくり、ステップ2をjiraでやっている場合、miroのマップの一つ一つのアイテムをjiraのチケットと連携させる形でつくる(miro-jira連携プラグインを使う)。そして作られたチケットをjiraでバックログ管理する。こうすると、二重管理にならないので便利なのでおためしください。
step3 ストーリー(チケット)
で、やるぞとなったタスクは、ステータスを着手の段階に変えます。ここのチケットの書き方に制約はあまりきめてなくて、各アサインされたひとが、理解しやすいように書いとけば良いんじゃないかなと思ってます。あまり厳格にルールをきめるとまもられなくなるし、一度守られなくなると(すべてにいえることですが)他の最低限のルールも守るの面倒くさくなってあっという間に仕組みが崩壊していったりします。なのでなるべく、無理なルールはなくして自由な状態にしておくのがいい。
手をつけたり、そして作業が完了したらステータスを変えて、終わったことを明確にするのが大事です。
この塊から個別へというタスク分解の流れは、その不確実性の大きさの違い、それによるアウトプットの種類の違いで、繰り返し行われるかたちになります。
作るタスクチケットも仮説の不確実性がかわっていくなかで変化していくとおもっています。こういうふうに違うものだとすることで、「あーこのチケットはアイディアチケットだからまだ実装するとかの話ではないのね、これ実装するとなったらめちゃくちゃ重いからびっくりした」とかをさけることができます。
おおまかにわけるとDiscovery段階でのモック作成系のチケットは種別を「アイディア」という名前のチケットにしてます。これが作られて、モックが作られて、検証が完了したら、このチケットを変換して「ストーリー」チケットにします。
JIRAでは変換機能をつかってやりますが、別に一旦アイディアチケットとは別にストーリーチケット作っても良いです。このストーリーチケットはいわゆる開発チケットで、今度はこれを使って開発進捗させ、終わったら完了させます。
チケットは細かくわけるとこんな感じになります。
Type1 アイディアチケット(Discovery-respondフェーズ)
開発には入れない怪しいアイディア。このチケットでモックを作ったり調査したりもする。
Type2 UX調査チケット(Discovery-senseフェーズ)
モックとかを使ったやつではない課題インタビューなどのユーザー調査とかのタスク。
Type3 戦略検討チケット(Discovery-senseフェーズ)
調査とかうけての検討や、単純にビジネス戦略を考える調査系のチケットだったり。
Type4 開発チケット(Delivery-respondフェーズ)
Discoveryフェーズをへてやることがきまったアイディア。
Type5 ビジネスタスクチケット(Delivery-respondフェーズ)
Discoveryフェーズをへてやることがきまったアイディアのうち、エンジニア以外がやるタスク。運用フローを考えたりとか。問い合わせ窓口の仕組みを作ったりとか。
Type6 開発調査チケット(Delivery-senseフェーズ)
技術調査だったり方針決めのチケットだったり。
まぁいろいろありますが、ぶっちゃけどれもタスクです。うちのチームでもぜんぶをJIRAで違う種類にしてるわけではなくて123あたりは全部アイディアチケットという形になってます。
ただ、うちはDiscoveryとDeliveryのチケットの種類で、ボードをふたつわけてます。ボードというのは、特定のチケットだけがフィルタリングされて表示されるページのことです。
Discovery・Deliveryなデュアルトラックアジャイルなやり方をやってる会社では多分会社やチームによっては一つにまとめてるところあると思いますし、そっちのほうが正統派なきはするのですが、あえてわけてます。やっぱりデリバリー系のいろいろあるけどいうて絶対やっていくぞというものが見えるボードのなかに、ふわっとやるかやらないかわからないアイディア系のチケットがはいってるのは、個人的にはやりづらい。
デリバリー側がすすめるうえでも、ノイズになってきて、だんだんボードをみるのがいやになってきたりする。やることが明確に終わったらそのまとめページはすっきりしていくというUIUXが大事だとおもっている。Discovery側からしても、そう。
一緒にすることで、Discovery側もデリバリー側もお互いに何やってるかわかるみたいな話がありますが、その話であれば、このボードをひとつにしなくても、普段のデイリーチェックイン系のMTGでお互いが意識できてれば問題ないと思っています。ボードはあくまでもツールなので、見やすいのが一番かなとか。
と、細かい話はさておき、このボードで日々、検証・開発を前にすすめていきます。
ということで、ここまで、横軸の、仮説の不確実性を低減させるプロセスのなかで、どうあつかうコミュニケーションでやりとりする情報の種類が変わってくるのかということを書いてきました。
最後に、その情報をどんなMTG・コミュニケーションでやりとりする、そのスタイルがどう変化するのかということを書きます。
情報の種類が違えば、それぞれMTGも別々にしたほうがいい。まぜると、いろんな情報がまざってしまって、このチーム全体的に今何しようとしてるんだっけ?とわからなくなったりします。また、あまりロールを意識するのは微妙なのは間違いないとおもいつつ、現実的に忙しいエンジニアは企画系アイディア系のMTGに出てる場合じゃないからこれでなくていいや、とか工夫できます。
最初にいったように、やりながら困ったこととかは基本はデイリーチェックインで話します。まだ不確実性が高いディスカバリーフェーズのMTGと、やることがほぼ決まっているデリバリーフェーズの施策のMTGは、わけています。
ディスカバリーMTGでは「こんなアイディアいいんじゃない?」「プロダクトのはねかたはこういう方向性がいいかも」みたいな話をしてデリバリーMTGでは「この開発の方針大丈夫かな?」「XXの会社と話してきたけどなかなか難しい」みたいな具体的な作業の話をします。
また、一応週に1回程度セレモニーとよばれる特定のことに集中して時間をさくMTGをそれぞれのフェーズに合わせて開催してます
Type1 スプリントプランニング&レビュー系(ディスカバリー・DEV系デリバリー・BIZ系デリバリーでそれぞれ)
週に1回今週やるタスクはどれなのか、どうやってすすめるのかなどを話し合うMTGを週に1度とっています。また、先週やったタスクはどうだったかというのを確認するMTGも。
ただぶっちゃけこれを今はセットでそれぞれやってます。わけてるのは、ディスカバリーとデリバリーで別々のMTGにしてるのと、開発とビジネス側のタスクでわけてやってるところです。また、ビジネスタスクMTGはぶっちゃけビジネス側にあまりこのやり方を完全に浸透させるところまでいってないので 笑、あまり開催されたりされなかったりです。ただ、TODOリストとしてBIZのデリバリーチケットは活用されてるのは事実です。
Type2 リファインメントMTG
週に1度、PM,UX,BIZ、DEVからリーダーが一人ずつあつまって、いまやっているバックログをながめながら、どのチケットを優先的にやるかというのを話し合ったりしてます。
理想的にはここでバックログの整理をして優先度きめるとかしたいところ。実際にはそこまでやってなくて、それぞれのバックログを一番理解している人が今週の状況を他の人に伝えて相談し、並び替えとかは個別にMTG外でやってたりします。ここでチームの認識をむりやり最低限あわせるという時間にしてます。
Type3 その他
ふわっとした段階、アイディア出しの段階だったり、いろいろ技術的な下調べのタイミングでは必要に応じてMTGをセットしたりしています。
応用編のまとめ
こんなかんじにまとまります。一見複雑な仕組みですが、大事なのはMTGにバリエーションを作ることで、そのMTGのコミュニケーションの質をあげること。
リーンコーヒーのカオスさも非常に魅力的なのですが、カオスなだけだとずっとおなじことをうろちょろしてるだけな感じもしてきて、果たしてこのチームのコミュニケーションはうまくいってるんだろうか?という疑念がメンバーにうまれてしまいます。
かといって、完全に計画通り、アジェンダ通りMTGをやるとなっても、新しいアイディアがうまれない、クリエイティブな作業にならない。
コントロールされたカオスを生み出すために、前提となるMTGの種類、ルール、扱う情報をPMが整理しておくのが良いと思っています。
メンバーは、そこまでこの仕組みの流れを意識する必要はないです。PMが設定したルールをその場その場でつたえて、そのなかで全力をつくしてもらう。応用編をやっていく場合この辺が重要になってきます。
チームコミュニケーションプロセスのまとめ
とまぁいろいろ書いてきましたが、応用編はかなりマニアックなのでまずは基本編のマインドセットとリーンコーヒーMTGだけでも参考にしていただけるのがいいかなと思っております。
実際応用編でやっているような一見複雑な流れは、チーム組成のタイミングではまったくやってませんでした。最初は本当にリーンコーヒーだけ、といったかたちでやりはじめ、だんだんと議論しながらここまで育ってきたという感じです。
応用編で書いたような話は、状況に合わせて細かくよりやりやすいようにカスタマイズしていった結果うまれてきたようなもので最初はシンプルだったんです。
最初からなんか複雑なやり方をチームに導入しても、メンバーてきにはなにそれ、としらけます。わかりました、というかもしれないですが、内心めんどうくさいなーとおもったりします。そうならないように、みんなが納得しやすいようなところから始めるのが一番です。
このへんがチームマネジメントをうまくいかせる一番大事なコツかもとおもってます。こっそりさりげなく無理ない範囲でPMは工夫をしてく。自分がリーダーだ、俺についてこいみたいな感じにならない。
そして導入したら、チームの反応をみながら柔軟にどんどんかえていく。うちもどんどんかえてます。
逆にDiscoveryMTGはいまけっこうDeliveryMTGとマージしてやってたりしているので、単体でのMTGはやめつつあったりもしています。
また、これからもきっとどんどん進化させることもあるとおもいます。実際今、ユーザー調査系のチケットはアイディアチケットから分離させてSenseという種類のチケットにしようかと考えていて、それだけをあつめたボードを作って運用をはじめたりもしています。
これもやるときは、周囲に相談しつつ大胆に試してみたりと工夫しながら、メンバーがしらけないようにやっていってます。
是非、今回の話を一例として、皆さんのチームでもチームマネジメントプロセスを意識して工夫してみて、3割打者、4割打者、5割打者だらけのチームを作り、勝率80%のチームを作って行っていただければ幸いです。