【感想】「チーム・ジャーニー」を読んでみた

今度は
チーム・ジャーニー 逆境を超える、変化に強いチームをつくりあげるまで
を読んでみたので備忘録がてらnoteに教訓を書き残しておく。

著者

市谷 聡啓 さん

書籍について

書籍では主人公がチームリーダーを任され、プロダクト開発を進めていく中で様々な課題にぶつかり、チームとは何かを学び、乗り越え成長していく姿が描かれている。
プロダクト開発を軸としてストーリーが展開されるので、アジャイル開発に関わるエンジニアに向けた書籍だが、「チームを作る」という点ではどのような会社や組織でも参考になる内容だと思う。

読もうと思った理由

新しい職場に参画することになったため。

次の職場では最初はプログラミングや設計を通してシステム構成や仕様の理解・把握に努め、ゆくゆくはチームや案件をリードする立場となる想定で参画するため、チームを作る方法や知識を得たいと思った。

また、以前にチームリーダーやサブリーダーという役割を経験したが、その役割に見合う成果を十分に出せていなかったように思う。
当時はもちろん自分なりに努力していたが、あくまで「自分なりに」であり自己流に過ぎなかった。

「チームを作る」とは何をすることなのか？を理解して実践できるようになりたい。

教訓１：チームとグループは違う

今まで自分はチームリーダーではなくグループリーダーやってたんだな、って書籍を読んで思った。

チームはミッション（目的）を掲げ、メンバー同士で担当する作業や領域を持ちつつもお互いで補完し合い、相互作用に注意を払い、業務上のルールを自分たちで決める。

グループはミッション（目的）が共有されておらず、メンバーは自身が担当する作業や領域にだけ責任を持ち、相互作用を気にしないから事後報告になり、業務上のルールはグループ外の誰かが決める。

ただ優秀なエンジニアが集まっただけではチームにはならない。
チームとなるためには、
①目的（我々はなぜここにいるのか？）を全員が認識し、
②目的を達成するためにクリアすべき目標を全員が認識し、
③お互いの得手不得手や関心など（メンバーのこと）を知り、
④仕事する上でのルールを整備する

これからは所属する集団がチームかグループか見極めよう。
グループであれば不足している①～④を実施しよう。

教訓２：見える化、場づくり、一緒にやる の３ステップでチーム間の共通理解を深める

どのようなプロジェクトでも関わっている人が多ければ多いほど、意思疎通が取れなかったり情報共有が行き届いていなかったりするのはよくある話。
情報の連携が取れていない状態を書籍では「分断」と述べられている。

例えば、バックエンドの機能改修を他チームに連携していないことで、フロントエンドに影響が出たり、
企画（ディレクター）からの仕様変更の要望がデザイナーやフロントエンドにしか伝えられていないことで、バックエンドの改修が遅れたり・・
（いずれも実際にあった苦い経験…辛かったな…）

情報共有の必要性や重要性について、頭ではわかっていても業務に追われ気付けば連携が漏れていたり忘れたりすることは度々ある。
もし、こういった分断が発生したら
①見える化
②場づくり
③一緒にやる
の3ステップを実施しよう。

まずは、誰でも閲覧できるwikiやチケットなどに漏れていた情報を整理して関係者に展開しよう・・①
ただ、見える化しても経験の浅かったり技術的な知見を持たないメンバーは見ても理解できないかもしれない。

なので、関係者間に口頭で情報連携する場を設けよう・・②
ただ、覚えることが多くて把握しきれなかったり次のアクションができるか不安がるメンバーがいるかもしれない。

なので、心配なメンバーと次のアクションを一緒にやろう・・③
結果に至るまでの過程（プロセス）を一緒に体験することでお互いの共通理解が深まる。
コーディングに心配があるなら一緒にコーディングしよう。
設計に不安があるなら一緒に設計しよう。
要件定義が曖昧なら一緒に要件定義しよう。

教訓３：「リード」という役割を持たせる

何でもかんでもリーダーが責任を負ったり、先導する必要はない。
その時の状況で誰かに「リード」という役割を与えて先導してもらうのも1つの手なんだなと思えた。

それと「リーダー」と「リード」の違いをようやく理解した。

【リーダー】
組織上の職位、地位。特定の人が担う役割。基本的に状況によって変更されない。

【リード】
ある状況下において先導する役割。状況によって担う人を変えてよい。

テクニカルリード、テストリード、性能検証リード、サポートリード、XXXリード・・
要は何とかリードなら呼び名は自由。
チームが注力したい課題とメンバーの得意分野やスキルを照らし合わせて、リードしてもらう人を決める。

リードを担うことでメンバーにとってもモチベーションアップに繋がるような気がする（人にも寄るだろうけど…）
リーダーがタスクを持ちすぎてしまう問題も解消しそう。

これからは「リード」を取り入れてメンバーの自主性を促してみよう。
あるいは自分が「リード」を担い、得意な技術や領域を伸ばそう。

教訓４：最初に仮説キャンバスを描く

仮説キャンバスは仮説を立てるために必要な情報を整理するためのフォーマットです。詳しくはこちらを参照。

普段は業務に追われて目的やビジョンを見失っているように思える。
もしくは、プロジェクトに参画した瞬間に何らかの仕事が割り振られ、目的やビジョンを考えたり見る暇もなく忙殺されることすらある。

ただ、思うに目的やビジョンは明確で認識できていた方がよい。
目的を認識していれば方針がブレない。
目的を認識していれば悩んでも迷わない。
これからは仮説キャンバスを描いて、誰かに目的やビジョンを説明できるようになろう。
雰囲気で仕事をするのはやめよう。

この仮説キャンバスを埋めるために必要なデータを収集する。
顧客へのヒアリング、現状の分析、業界構造の理解、ビジネスモデル、などなど・・
そして、仮説を立てたら検証する。
インタビュー、自分がユーザになる、プロトタイプをつくる、などなど・・
仮説と検証はセットで行おう。