チーム構成と権限委譲
簡単に言うと、チーム構成と権限委譲は「サッカーチームのフォーメーションと選手の自主性」のようなものです。サッカーでは、フィールド上の11人がそれぞれの役割を理解し、監督の指示を待たずに状況に応じて判断できるチームが強いですよね。フォワード、ミッドフィルダー、ディフェンダーが適切に配置され、それぞれが自分の判断でプレイできる権限を持っているからこそ、チーム全体で素早く連携して勝利を掴むことができるのです。開発チームも同じで、必要なスキルを持つメンバーが適切に配置され、現場で迅速に判断できる権限があってこそ、価値のあるソフトウェアを効率的に作ることができるのです。
カテゴリ解説を読むシステムを開発する1チームの構成人数は、3人以上10人以下か。(ピザ2枚ルール)
TEAM-1-2学習と改善ある特定の人物に属人化した仕事を洗い出し、減らしていく仕組みがチームにあるか。
TEAM-1-3プラクティスチームとチームメンバーの権限について、RACI図やデリゲーションポーカーなどによって、可視化され共有されているか。
TEAM-1-4プラクティスチームは価値提供をするのに必要な全職能のメンバーで構成されているか。(フィーチャーチーム)
TEAM-1-5プラクティスチームおよびチームリーダーは、チームのミッションのために必要な外部のリソースを調達するための予算や権限をもっているか。
TEAM-1-6アンチパターンチームという単位は存在するが、メンバーのそれぞれのやっている仕事の内容をよく知らないし、代わりにやることもできない。
TEAM-1-7アンチパターンチームリーダーが複数のチームやプロジェクトを兼務しており、自チームのためにすべての時間を使うことができない。
TEAM-1-8アンチパターンチームリーダーがメンバーに権限委譲できておらず、ボトルネックになっている。
チームビルディング
簡単に言うと、チームビルディングは「サッカーチームのコンビネーション練習」のようなものです。どんなにドリブルが上手な選手やシュートが得意な選手を集めても、お互いの動きや癖を知らずに個人プレーで試合に挑んでも勝てませんよね。パス交換、ポジションチェンジ、守備の連携などを何度も練習して、「あの選手がここにボールを出したら自分はこう動く」という阿吽の呼吸ができるようになって初めて強いチームになるのです。開発チームも同じで、個々のスキルがいくら高くても、チームとして連携しなければ本当に価値のあるソフトウェアは作れません。
カテゴリ解説を読むチームは少なくとも半年以上継続して存在しているか。
TEAM-2-2学習と改善チームは月に一度以上の頻度で仕事のふりかえりをおこなっており、その際にプロジェクト憲章またはインセプションデッキを見返して目的を再確認しているか。
TEAM-2-3プラクティスインセプションデッキまたはプロジェクト憲章などを作成し、チームの存在理由についてチーム全員が把握しているか。
TEAM-2-4プラクティス新しくチームに参画するメンバー用のオンボーディング・デック(チームの一員として働き始めるための、価値観・実務・スキル・相互理解のための明文化されたドキュメント集)などが存在するか。
TEAM-2-5プラクティスチームメンバー全員で定期的にカジュアルにコミュニケーションをとる場がある(ランチ、ディナー、レクレーション等)
TEAM-2-6アンチパターンオンボーディングプログラムが、文章を読むだけのものになっており、ハンズオンやミッション理解の伴わない形骸化したものになっている。
TEAM-2-7アンチパターン1年以上チームのやることがルーチン化しているなど変わっておらず、チームメンバーも固定されている。
TEAM-2-8アンチパターンチーム内でチームミッションの改善に関係する議論がどんな理由であれ発生していない。
心理的安全性
簡単に言うと、心理的安全性は「サッカーチームのハーフタイムでの会話」のような状態です。試合中でも「今のパスはこうした方が良かった」「次はこの戦術で行こう」と選手同士が遠慮なく意見を言い合えて、ミスをした選手も「次は決めるぞ!」と励まし合えるチームが強いですよね。監督が怖くて何も言えなかったり、失敗を責められるのが怖くて消極的なプレイになったりするチームでは、選手が本来の力を発揮できません。開発チームも同じで、メンバーが「何を言っても大丈夫、失敗しても支え合える」と感じられる環境でこそ、本当にクリエイティブで価値のある仕事ができるようになります。
カテゴリ解説を読むチームの心理的安全性を測る指標があり、定期的に計測しているか。
TEAM-3-2学習と改善1on1や、落ち着いた場面でのカジュアルな雑談を含む直接業務に関わらないキャリアやタスクの壁打ちを、月に1度程度は実施しているか。
TEAM-3-3プラクティスチームメンバーの行動/発言を明示的に承認行為をおこなう習慣があるか。(成果ではなく行動したこと自体に対して、拍手する・感謝を述べるなど)
TEAM-3-4プラクティスチームメンバー間で挨拶をしたり、雑談をする習慣はあるか。
TEAM-3-5プラクティスチームの不安や不満などを可視化し、吸い上げるための仕組みを持っているか。
TEAM-3-6アンチパターンミッションや共通のゴール設定をしないまま意見を集め、課題のためというよりも個人のための意見しか出てこない状況になっている。
TEAM-3-7アンチパターン心理的安全性を仲の良さと捉えて、事業のための意見ではなく、仲良くすることが目的化しているため、意見を封殺してしまう。
TEAM-3-8アンチパターン事業目標や納期目標に対して、威圧的なマネジメントや権威的な命令を繰り返したことで、意見が出てこない状況になっている。
タスクマネジメント
タスクマネジメントは作業内容とステータスを体系的に明文化・可視化し、チーム全体の生産性と品質を最適化する管理手法です。現代のソフトウェア開発では市場変化への迅速な対応と高速な仮説検証が競争力の源泉となっており、不透明で非効率なタスク管理はプロジェクト遅延と品質劣化に直結します。体系的なタスクマネジメントにより、優先順位の適切な設定、作業の透明性確保、責任範囲の明確化を実現し、組織全体のアジリティを向上させることが可能になります。
カテゴリ解説を読むアイデアレベルの要望や構想から、要件に落ちるまでのリードタイムは計測されているか。
TEAM-4-2学習と改善仕事を始めるための定義と、完了するための定義はチームやステークホルダーで定期的に見直されているか。
TEAM-4-3プラクティス上長やステークホルダーを含め、共通のタスク管理ツールを利用しており、プロジェクトの状況を可視化したダッシュボードに常にアクセス可能か。
TEAM-4-4プラクティスチームが仕事を始めるために必要な課題やタスクの粒度について、明文化されたフォーマットが存在するか。
TEAM-4-5プラクティスチームのタスクに関して、「完成(完了)の定義(Definition of DONE)」などが存在し、自律的に管理できているか。
TEAM-4-6アンチパターン他部署からの依頼が明確なタスクツールではなく、担当者へのダイレクトメール/メッセージ/口頭など透明性のない形で行われている。
TEAM-4-7アンチパターンどのチームタスクであるかが曖昧なとき、ボールが落ちないようにするための仕組みや文化が存在しない。
TEAM-4-8アンチパターンどのチームタスクであるか曖昧な仕事が発生したあとに、事後検証(ポストモーテム)が行われず都度話し合いで解決している。
透明性ある目標管理
簡単に言うと、透明性ある目標管理は「サッカーチームのサイン・コール」のようなものです。サッカーでは試合中、フィールド上で選手同士がサインやコールを出し合いますよね。「カバーリング」「スイッチ」「プレス」といった指示で戦術変更を伝え、ゴールまでの距離や残り時間、現在のスコアといった状況をチーム全員が把握しています。この意思疎通があるからこそ、状況に応じた的確な動きができ、連携したプレーでゴールを目指せるのです。開発チームも同じで、目指すゴールとその進み具合をみんなが見えていてこそ、各メンバーが自律的に判断して、効率的に価値を生み出せるようになるのです。
カテゴリ解説を読む1年後などのチームとプロダクトの目指す姿が、言語化され、いくつかの計測可能な指標により明晰化されているか。
TEAM-5-2学習と改善目標に対して、うまくいかなかった際にチームとして「学んだこと」を言語化・他チームへ公開・学習しているか。
TEAM-5-3プラクティス四半期にフォーカスすべき目標が言語化され、いくつかの計測可能な指標によって明晰化されているか。
TEAM-5-4プラクティスフォーカスすべき目標に対して、どのようにアプローチするのかの計画をチームで共有しているか。
TEAM-5-5プラクティスビジネス上、重要なマイルストーンとそのスケジュールをチームで常に共有し、その進捗を確認しているか。
TEAM-5-6アンチパターン目標管理が強く評価制度に結びついているため、ストレッチしたゴール設定をすることが難しくなっている。
TEAM-5-7アンチパターン目標項目の一部に、その達成手段が健全に行われているかをチェックするための目標(健全化指標)を立てていない。
TEAM-5-8アンチパターン定量目標が無く、客観的に達成度合いが不明確なものになっている。
経験主義的な見積りと計画
簡単に言うと、経験主義的な見積りと計画は「サッカーチームの試合分析」のようなものです。サッカーチームは試合後に必ずビデオ分析をしますよね。パス成功率、シュート本数、走行距離といった実績データを見ながら、「この選手のスタミナはこれくらい」「この戦術だと平均何点取れる」という過去の実績を元に、次の試合に向けた練習メニューと試合戦術を組み立てます。「気合いで頑張れば勝てる」という精神論ではなく、個人とチーム全体の実績データを元に現実的な目標と計画を立てるからこそ、着実に強くなれるのです。開発チームも同じで、過去のベロシティやリードタイムといった実績データを元に計画を立てることで、達成可能で信頼性の高いプロジェクト遂行ができるようになります。
カテゴリ解説を読むチームのベロシティを把握しており、変化を計測し安定しているかどうかを確認できているか。
TEAM-6-2学習と改善相対見積もりの基準となるタスクが存在し、定期的にアップデートの判断をしているか。
TEAM-6-3プラクティス見積りは、実際にその仕事を行う本人を含むチームの複数人で行われているか。
TEAM-6-4プラクティススケジュールがクリティカルな場合には当初から精密に、仮説検証や価値がクリティカルな場合には荒い粒度から段階的に詳細化するなどして、状況に応じて見積りや計画の方法を変えているか。
TEAM-6-5プラクティス相対見積もりの基準となる要件(ユーザーストーリー)が存在し、定期的にアップデートしているか。
TEAM-6-6アンチパターンスケジュールのバッファ(緩衝期間)が全体計画に対して1/4以下しかもうけていない。
TEAM-6-7アンチパターン機能要件のバッファ(緩衝機能)を全体計画に対して設けられていない。(「必須な機能」と「あったらよい機能」が分類されず、曖昧になっている。)
TEAM-6-8アンチパターンベロシティをチームの安定性を測る指標にするのではなく、生産性の指標にしている。
ふりかえり習慣
簡単に言うと、ふりかえり習慣は「サッカーチームの成績管理」のようなものです。サッカーチームは試合後に必ず振り返りを行いますよね。個人のパス成功率、シュート本数、走行距離といった個人スタッツと、チーム全体のポゼッション率や得点パターンを分析して、「この場面の判断は良かった」「ここでポジションを上げるべきだった」「次はこの戦術を試そう」と具体的に振り返ります。ただ「もっと頑張る」で終わらせず、データと実感を元に個人目標とチーム目標の両方を意識しながら、次の練習と試合に反映させるからこそ継続的に強くなれるのです。開発チームも同じで、スプリントやプロジェクトを振り返って具体的な改善点を見つけ、次に活かすことで、チーム全体が継続的に成長していけるようになります。
カテゴリ解説を読むふりかえりのテーマごとに数字を集めたり計測するなどして、ファクトベースで議論できるようにしているか。
TEAM-7-2学習と改善チームのメンバーは、チームで合意した1カ月以内のサイクルでふりかえりを実施しているか。
TEAM-7-3プラクティスふりかえりの場はチーム全員が参加しているか。
TEAM-7-4プラクティスふりかえりはテーマを定め、議論を行い次回のふりかえりまでに実行可能なタスクが切り出されているか
TEAM-7-5プラクティスふりかえりにおいて前回のふりかえりで改善するために起案したタスクが実行されたか検証しているか
TEAM-7-6アンチパターンふりかえりをしていたが、しばしば意見が出なかったため、ふりかえり自体をやめた。
TEAM-7-7アンチパターンふりかえるべきテーマに関しての、起きた出来事を時系列に事実関係を整理するなどの準備をせずにふりかえりをすすめている。
TEAM-7-8アンチパターンふりかえりに適切なファシリテーターがいない。
バリューストリーム最適化
簡単に言うと、バリューストリーム最適化は「サッカーチームの攻撃の組み立て」のようなものです。サッカーチームでは、ゴールキーパーからディフェンダー、ミッドフィルダー、フォワードまで、ボールが渡ってゴールに至るまでの一連の流れがありますよね。どこかでパスが遅れたり、無駄なバックパスが多かったりすると、攻撃のテンポが崩れてシュートチャンスを逃してしまいます。強いチームはパスワークの無駄を徹底的に省き、最短ルートでゴールを目指します。開発チームも同じで、顧客が欲しいと思ってから価値が届くまでの全プロセスを見直して、無駄を減らし最適化することで、より早く良いものを提供できるようになります。
カテゴリ解説を読む

