チームの成長には段階がある
うまくいかない理由を他責にしても始まらない。
- フォーミング
- ストーミング
- ノーミング
- トランスフォーミング
・フォーミング（形成期）
チームの結成・様子見
・ストーミング（混乱期）
意見のぶつかり合い・個人の主張
・ノーミング（標準期）
個人の役割とチームの決まり事の明確化
・トランスフォーミング（達成期）
能力の発揮と成果達成
組織課題は、「Do（やり方）」と「Be（あり方）」の分類できる
・Do（やり方）
スケジュール管理方法がよろしくない
情報共有の方法がない
会議体が機能していない
・Be（あり方）
安全な場所がない（仕事で相談できる人がいない）
チームに仕事に対する自信がない
当事者意識がない
実は、形成期・混乱期には、「Do」よりも「Be」に関するものがほとんどである
・そもそも、自らのチームが「形成期」「混乱期」にあることを認識できておらず、
スケジュール管理手法といった「Do:やり方」を実践してしまう。
・これらのフェーズではチームメンバー同士で意見交換を行い、
「なんでも言い合える場」を作ることが仕事のパフォーマンスをあげるうえで大切
意見交換の具体例：
リーダーとメンバーそれぞれに意見を求める
「納期に間に合わないのはスキルの問題か？それともモチベーションの問題か？」
「納期を守るために最も重要なことは何だと思うか？」
「リーダーは、メンバーひとりひとりを大切な仲間と考えているか？」
「チームには信頼関係があるか？」
「なんでも話し合える場があるか？」
「メンバーの相談をないがしろにしていないか？」
感想
成果につながっていない問題が発生したときには、
まずチーム全体としてどのような位置づけになるのかを考えるべきだと理解した。
各々のスキルには全く問題がないにも関わらず、あり方「Be」に対する課題に対処していないために
ゴール地点まで到達する際に様々な障壁が発生してしまうのだと思う。
個人的には「チーム」という単位だと、全員が同じ仕事に取り組んでいるイメージがないので、
「プロジェクト」に読み替えることにした。（自分の勤務先が独特なのかもしれないが）
昨年度、小規模案件のプロジェクトマネージャを経験することがあった。
その際のチーム（プロジェクト）の状態がどのような形だったかを振り返り、以下にポイントをまとめる。
- 知見のある担当者が不在の中でのシステムマイグレーションプロジェクト
・急に渡された案件
・なにそれ知らんがな状態
・担当者休職してるし設計書も何もないし
・チームの問題というよりは、従来の体制（資料整備等）がダメなんじゃねーかこれ
おっと、他責にしても始まらないんだった。
・ソースコードから追うしかない
・メンバーに作業の割り当てをする瞬間は、非常に残酷なことをしているように思えた
・今後同じ悲しみが起きないように資料整備することを心に決めた
チームのあり方（Be）以前の問題であった。
