デザイナーだけどアジャイル好きで新規プロジェクトチーム発足時にいつもしてるチーミング論
どうも。@pujisiです。
株式会社ミクシィ社にデザイナーとして勤務し、直近までに2つの新規事業の立ち上げフェーズを経験しました。
新規事業の立ち上げ時はいつだって、共に闘う仲間たちと出会い、未知の市場、そしてまだ見ぬ未来へと挑戦する新たなるチームが組成されることとなります。
まだ規律も何も用意されていないチームへ参加する度に、肝心な初期フェーズに毎度提案している型のようなものがあるんですが、毎度同じようなことをチームドキュメントに起こすのもなんであるし、このnoteも見ると2018年の下書きで筆と時が止まっていたのでしっかりとアウトプットしてインターネット資産として活用できればという想いで、綴ります。吟じます。
まず、規律を整える
規律といってしまうと、その語感から個々人の自由を縛り付け奪うような感じになりますが、チーム生成初期段階で規律をインストールしておくことで、のちのちの組織課題コストを下げることができると考えています。
といいながらも、チーム個々人の才能みたいなもので行き当たりばったりで成功するチームっていうのも、実は僕大好きなんですよ。ロックバンドみたいで。が、確率論でいけばそれはきっと奇跡に近いんですよね。。再現性がなく。
規律なきチームでプロジェクトを進めると序盤は仲の良さ等で良い感じに思ていても、ある局面で立ちゆかなくなる組織課題に高確率でぶち当たる。摩擦が起きる。そして人は磨耗する。
会社組織で働くということは問題や摩擦の発生はつきものですが、できる限りそういうのは減らしたほうがいいよなぁ。と僕は思っています。
なんのため？
で、なんのために規律を整えるの？というと、以下4つの目的のためです。
❶ 透明性をあげたい
❷ 協力しあえるチームにしたい
❸ 戦略的かつ効率的にサービス開発したい
❹ 失敗を心配しなくていい安心感をつくり、失敗を学びにかえ共に成長できるチームマインドにしたい
それはなぜ？
１番の大目的を言語化するならば、次のようになります。
『チーム全員が効率よく目的へ向かい、プロジェクトの成功確率を上げるため🎉』
ということです。すべてはこの一言に尽きます。
Ⅰ. プロジェクト目的の目合わせ
何よりも先ず、チームで目指すべき目的地の設定です。ミッション・ヴィジョンのようなマインド・アイデンティティを含めてチームで目合わせをします。
僕の勤務する会社では、エンジニアも多くアジャイル志向の方やスクラムの知識を持った方が多いので、アジャイルサムライetcでも紹介されているインセプションデッキを利用して言語化することで、事前知識のインストールも最低限で済み目が合いやすい感覚があります。
以下10個の質問にステークホルダー交えてチーム全員で議論し、言語化することでインセプションデッキを構築します。
インセプションデッキ10個の質問
5つのWhy：
❶ 我われはなぜここにいるのか
❷ エレベーターピッチ
❸ パッケージデザイン
❹ やらないことリスト
❺ 「ご近所さん」を探せ
5つのhow：
❻ 解決案
❼ 夜も眠れなくなるような問題は何だろう
❽ 期間を見極める
❾ 何を諦めるのかをはっきりさせる
➓ 何がどれだけ必要なのか
最初の問いである「我々はなぜここにいるのか」で、ミッション・ヴィジョンまで言語化しちゃっておければとても良いですね。後々に苦労しません。目指すべき姿・景色を描ききりましょう。
もしそれが描けない場合は、速やかに解散した方が企業は無駄なリソースを割かずかつ失わずに済みます。
チーム発足の最初期フェーズに目的地の設定ができないまま出発すると、目指した場所に辿り着くはずもなく、苦労して到着した場所は自分たちの行きたかった場所見たかった景色であることはおそらく少ないでしょう。そして摩擦が起き、チームの疲弊がはじまります。
これが旅行であれば目的なくとも予期せぬセレンディピティとして感動を味わえることもありますが、チーム開発ではそんなことほとんど起きません。だから、目的地の設定・チームの目合わせはほんとうに大切です！
Ⅱ. 役割の定義
目的の目が合ったら次は、各チームメンバーの役割の定義です。
役割は重要です。意外と役割がふわっとしたままなんとなく進んでるチームというのもよくある話なので、はじめに定義・共有しておくことが肝心です。これはスクラムをベースに利用し、役割を定義します。
プロダクトオーナー（PO）
・プロダクト及びサービスの結果責任をとる人。
・プロジェクトに1人、必ず必要。
・プロダクトバックログの管理者、優先度の責任決定権限を持っている人。
・開発チームに相談できるが、干渉はできない。
プロダクトのみならず大きいサービスであればサービスオーナーとも呼んだりしてます僕は。
ミッションやビジョン・目的の設定を含め、目的達成の成功の鍵はこのプロダクトオーナーのリーダーシップに懸かってます。
スクラムマスター（SM）
・プロセスをうまく回るようにすることに責任をもつ人。
・チームのために支援と奉仕をし、妨害を排除する人。
・規律の教育、ファシリテート、コーチ、推進役。
専任スクラムマスターが望ましいが、人数が少なければ誰かが役割の兼務するしかないです。プロセスや業務改善に権限と責任を持つ役割を置くことが大切です。
開発チーム
・プロダクトオーナーとスクラムマスター以外のメンバー。
・エンジニアやデザイナーやセールス...etc
なるべく役割を限定しない機能横断的チームを目指そう、というマインドセットを各メンバーが持つことが大切です。
どんなタスクも目的に照らし合わせて主体的に動くことで、メンバーが自ら状況を把握するようになり、目的が自分ごと化されコミュニケーションが活性化し、心理的安全性が向上する確率も上がります。自分の頭で考えて自走しはじめるんですよね。感覚値ですけど。
重要なのは人を職能で縦に積まずに役割で横に並べること！
よくある組織構造としていきなり縦に人を積むパターンが有ります。エンジニアとデザイナーとセールスとマーケティングなど各機能毎にチームが縦に分かれてるみたいな。部長がいて課長がいて係長がいて部下がいて、みたいな。機能的意図もなくやるあれはできる限りやめた方がいいです。
なぜなら、無意識に上下関係ができ心理的安全性の障壁にもなる上に、人任せになるからです。思考停止します。誰も走り出さなくなります。職能縦割りにして人を上下に積んで幸せで成功してる組織、僕の場数不足かもしれませんが見たことがないです。
スクラムのPOやSMや開発チームはそれぞれ役割であるというだけで、基本横並びのフラットな関係を構築するものかなと思ってます。
POの意思決定権限は上下ではなく、目的に向かうためのリーダーシップとして捉えれば、POも決して上司ではありません。
職種の壁を越えてポリバレントに役割を果たそう
スタートアップ初期の段階では人的リソースも限られていることが多くあります。なので今あるリソースを最大限に活用するために、例えばエンジニアもデザインに参加するし、デザイナーがマーケティング・プランニングもする、といったようなことが大切です。これは職能を越えて目的に向かい助け合えるチームになるためです。
デザイナーである僕がなぜ開発プロセスやタスクマネジメントに主体的かつ重要視しているのかというと、職種を越えるマインドセットを持って役割の限界を取り払いたいという想いがあるためです。
面白いものでほっとくと人間という生き物は自分ができることの範囲しか基本やりません。たとえばUIデザイナーならUI部分のデザイン、UXデザイナーはUXツールの駆使、セールスなら売って終わり、等々。。変化を恐れなるべく安定したい。脳科学的にいうとホメオスタシスというやつです。
こうして目的への分断が起きます。時間という貴重な資産を割いてまで人がなぜチームにいるのかは目指す目的を達成して喜ぶためであるはずです。目的のためにできることは全てやるぞというマインドセットを構築することが目的達成への第一歩です。
Ⅲ. つくるべきものを見える化
プロダクトオーナーそしてチームの目指す目的を達成するプロダクトを、デザインプロトタイプやユーザーストーリーマッピングなどを駆使してとにかく具体化していきます。
ユーザーストーリーという言語化だけでも具体的に見えることで、欲しいものはこれじゃなかった！という認識のズレリスクを回避します。
STEP1. プロダクトバックログをつくる
チームが目指す目的を達成するために具体化が必要なプロダクトの姿を、ユーザーストーリー単位に分解して必ず全員が見えるような形に可視化します。
詳細度は高くなくてもいいですが、メンバーに言語化して伝えることが重要です。なかなかに骨が折れる作業です。
STEP2. 全プロダクトバックログ大見積もり大会をする
全プロダクトバックログ相対的数値化します。
見積もるときっと現実に打ちひしがれるけどやりきることが大切です。
STEP3. MVP（Minimum Viable Product 必要最低限製品）を定義する
見積もりとスケジュールを鑑みてリリースするプロダクトの最低限機能ラインを引きます。
全部つくる！全部大事！とかならスケジュール再検討します。スケジュールを優先するか顧客に届ける価値を小分けにするかはそのチームの方針に依存しますが、ミニマムに小分けして戦略的に届けることの方がリードタイムも短く、失敗も小さくて俄然おすすめです。
STEP4. プロダクトバックログの優先順位を決定する
可視化されたバックログの優先順位を決定する。POがその決定権限を持ちます。逆にPOが優先順位を決めなければ、優先してつくるモノは決まりません。
STEP5. 完了の定義を明確にする
タスク完了の定義・スプリントバックログ完了の定義・プロダクトバックログ完了の定義。
これらをチームで目を合わせながら定義します。この定義がないと人によって作業完了の認識がずれてたりします。忌わしき摩擦の兆候が発生します。
以上がつくるべきモノを見える化する最低限やるプロセスです。
僕の場合はデザイナーなので、STEP1. のプロダクトバックログをつくる前に、目指すべきプロダクトのデザインプロトタイプを最速で作ってしまいます。
POとコミュニケーションをとりながらある程度目の合ったプロトタイプがあれば、上記プロセスが比較的容易になります。
もちろん初期プロトタイプなので、最低限の価値が測れる仮説のひと塊でいいのです。細部は気にしない速さが最重要です。プロトタイプは開発途中で柔軟に変化させるものであることも目合わせしておくことも大切です。
Ⅳ. 会議機能の定義
これもスクラムのをベースに考えます。スプリント期間（最低限に切り分けた機能単位を作って市場に出す期間）を決めて会議などのイベントを決めます。
スプリント期間
1スプリントのタイムボックスを決めます。
だいたい1週間とか2週間です。その方が多くの仮説が絡まる助長な機能開発にならず小気味良いリズムがうまれます。
スプリント期間が決まったら、次は期間内に行う会議イベントの場と機能の定義です。
朝会
目的：
進捗状況と問題の把握
いつ：
毎朝
やること：
昨日やったこと・今日やることを共有する
問題点の告白・現在の不安を告白する
（あれば）全体で共有したいことを激白する
鉄則：
全員参加で10分以内に収める！
課題は話すが、解決するまでは話さない！
解決が必要な場合は朝会後か別ミーティングを設定する！
スプリントプランニング（計画）
目的：
今スプリントで顧客に届ける価値のスコープを決め、どのようにつくり届けるか計画
いつ：
各スプリントの開始日
やること：
POはスプリントゴールを明文化する。
POはバックログアイテムから本スプリントで欲しいスプリントバックログを決定する。
POはバックログ受け入れ条件を定義する。
開発チームはどれくらいでそれをできそうか見積もる。
開発チームはどうやってそれを実現するか話し合う。
開発チームはスプリントバックログを小さく分割してタスク化する。
開発チームはタスクを見積もる。
鉄則：
プロダクトオーナーはスプリントバックログ優先度を最新にしておく！
プロダクトオーナーはプロダクトバックログの要件定義・受け入れ条件を言語化しておく！
バックログリファインメント
目的：
状況を目合わせしながらバックログの鮮度を保ち優先度を決定
いつ：
各スプリントの中間日
やること：
POの権限を発動し、バックログの優先度を更新する。
開発チームはバックログを見積もる。
鉄則：
POはここまでにしっかりユーザーストーリーに換言してバックログ化しておく！
POはスプリントバックログの優先度を最新にしておく！
バックログ未満の小刻みなアイデアもここで相談しよう！
スプリントレビュー
目的：
スプリントで仕上がった成果物が受け入れ条件を満たしているかチェック
いつ：
各スプリントの最終日
やること：
POは受け入れ条件に照らし合わせて成果物をレビューする。
全員が成果物を実際に操作して問題点を把握する。
鉄則：
成果物を全員で触って全員で価値や課題を目撃する！
スプリントレトロスペクティヴ（振り返り）
目的：
チームプロセスの問題解決
いつ：
各スプリントの最終日レビュー後
やること：
バーンダウンチャートなどを利用してチームの開発力を計測する。
KPT（Keep Problem Try）などでふりかえる。
鉄則：
事実だけを見つめる。
忖度しない。
以上、会議についてまとめると最低限スプリント計画・振り返り・朝会の３つは必ずやった方がいいです。
それぞれの本質はコレです。
計画とは：未来から現在を変えるもの
振り返りとは：過去から現在を変えるもの
朝会とは：現在をとらえるもの
決して形だけにしてはなりません。機能させましょう。
何も機能しない会議は罪です。例えばふわっと報告するだけの定例会議。なにもアクションに繋がらない話や時間は全て無駄だと認識しましょう。
全ての人間にとって時間こそが資産。参加者を時給換算して費用対効果をみれば経営者でなくても怖くなるはずです。無駄な時間は生産と問題解決に当てましょう。とにかく会議時間は効率的に機能させてチームの目指す目的地へと近づきましょう！
そうでなければサブスク動画サービスでアニメなんかを楽しむ時間に当てた方が投資効率がいいと思います。仮に1時間の無駄な会議があるのなら、鬼滅の刃なら3話・ドラえもんなら6話・サザエさんなら9話も見進められます！それぐらい時間は貴重な価値ある資産なんです！
まとめ：なぜこんな規律や目合わせが必要なのか
ここまで長々と語ってきた規律や目合わせの本質は信頼感の醸成にあります。流行りの心理的安全性の醸成のためでもあります。
そして大切なことはギリシアの哲学者ヘラクレイトスのいうように、万物は流転します。当然の如く、チームや状況は変化していくのです。
そういう意味では「スクラムごっこ」を真面目にやってカタチだけこなし時間資産を浪費してしまうよりは、変化を許容しつつ柔軟に取り入れチームに合わせて規律をフィットさせていきましょう。きっちり教科書どおりにやろうとするだけだと、目的を達成するという本質を忘れ思考停止しまうこともあります。
そのためにチームづくりを主体的にすすめ、安心してコミュニケーションを活性化させ問題を早期に解決していくとう、まさにチーミングし続けていくということが最低限必要なことです。
目合わせの全ての目的は冒頭にも述べた、
❶ 透明性をあげたい
❷ 協力しあえるチームにしたい
❸ 戦略的かつ効率的にサービス開発したい
❹ チャレンジから起きる失敗を心配しなくていい安心感をつくり、失敗を学びにかえ共に成長できるチームマインドにしたい
ということで、それが
効率よく目的に近づき、プロジェクト成功の確率を上げるため🎉
ということになります。
新規事業というのは不確実性がとてつもなく高いもの。
多くの人的時間的リソースを割いて開発したサービスプロダクトを市場に投入できたとしても、最も大切な顧客ニーズに答えてビジネスになる目的を達成できる保証はどこにもありません。
むしろそこからが闘いが始まります。真の目的を達成するための。顧客のニーズに応えて市場をつくるための。その闘いの最低限の準備をしましょう。力を注いで闘うべきはチーム組織の摩擦や問題ではなく、プロダクトやサービスをマーケットにフィットさせるということのみです！
そして共に闘う仲間たちと目的を達成し目指したい景色を眺めて、勝って美味しい酒を飲む至上の喜びを味わうためにも、普段からチームパワーを高めていきましょう！
---------
以下、参考引用:『チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ』より
新サービス提供にあたって誰ひとりしなかった重要な問いは、「学習するためにわれわれはどのように組織をつくるべきか」だった。実行するための組織づくりという会社の姿勢のせいで、マネジャーたちは、とりわけ危機のさなかにあるときに、考え方を変えることがなかなかできなかった。新サービスをきちんと─ ─ 予定どおりに、予算内で ─ ─ 提供する責務を認識しながら、マネジャーたちはそれまでずっと、社員に答えを与え、それを実行するための訓練を受けさせ、従わなければどういう結果になるかを理解させることに意識を向け続けていたのだ。
そういう考えは、仕事が十分に理解されているときにはうまくいく。しかしこれ以上ないほどきめ細かく計画され、しっかり訓練して実行されたとしても、仕事の仕方についての知識が定まらない場合、成功が保証されることはない。
先の見えない新しい仕事に取り組もうとするすべての企業にとって、成功する秘訣は、のちに高品質な製品やサービスを大衆市場に出せるよう、早い段階での経験（小規模なものが望ましい）から学ぶことである。
この本によるとチームづくりとは「チーミング」。
動詞かつ現在進行形で成立するということです。
スクラムのようなフレームで規則を律しすることで、チーム全体として「今、起こっていること」をモニタリングし分析・学習する、これを実践することは顧客に提供するサービスの開発そのものに通ずるものがあります。
余談ですが
僕、サッカーチームの川崎フロンターレが好きなんです。
川崎フロンターレは風間八宏元監督が2012-2016の5年間、規律として「足元に蹴る」「足元で止める」技術、「受ける」技術、「フリーの定義」を全員が目合わせした上で「マークを外す」技術の向上を徹底して、「サイドのみならず中央の狭いスペースからでも攻める」というようなことを5年かけてチームに律したそうです。
風間さんはこれをよく「目を合わせる」という言葉で表現していました。とても共感しました。
結果、風間さん時代は優勝こそなりませんでしたが、その風間イズムを受け継ぎ、鬼木達現監督が守備の規律も強めてアドオンしたことで悲願のリーグ初優勝を遂げました。
だからか、好きなんですよね。チームで目を合わせるということが。浸透するのに時間はかかっても、結果が出ると物語も仕上がり、みんなで感動できるし。
以上、ご清聴ありがとうございました。