システムの開発チームが素早く仮説検証するためには、十分に権限委譲された小さなチームであることが重要です。 また、経験主義的・仮説検証的に不確実な世界と向き合っていく文化を持つことがとても重要になります。 問題や課題を相互に言いやすく、解決していけるという確信が持てる人間関係の構築と事実に基づいた観察とふりかえりが強い開発チームを作り出します。
1.チーム構成と権限委譲
なぜ重要か
メンバーが多すぎたり、少なすぎたりすると管理を複雑にするばかりでなく、生産性を悪化させてしまうことが知られています。
また、高速に仮説検証を行うためには予算・意思決定・実行能力を1つのチームで保つ必要があります。
Name | PointOfView | Criterion |
---|---|---|
TEAM-1-1 | メトリクスの計測 | システムを開発する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 | アンチパターン | チームリーダーがメンバーに権限委譲できておらず、ボトルネックになっている。 |
2.チームビルディング
なぜ重要か
システムを改善するチームは、組成してからパフォーマンスするまでに時間がかかります。 多くの場合、同じメンバーで継続的に1つのシステムを改善すると学習が進み、開発を高速に行えます。一方、あまりに長い期間同じメンバーが継続しすぎると属人化や改善のサイクルが止まってしまいます。
Name | PointOfView | Criterion |
---|---|---|
TEAM-2-1 | メトリクスの計測 | チームは少なくとも半年以上継続して存在しているか。 |
TEAM-2-2 | 学習と改善 | チームは月に一度以上の頻度で仕事のふりかえりをおこなっており、その際にプロジェクト憲章またはインセプションデッキを見返して目的を再確認しているか。 |
TEAM-2-3 | プラクティス | インセプションデッキまたはプロジェクト憲章を作成し、チームの存在理由についてチーム全員が把握しているか。 |
TEAM-2-4 | プラクティス | 新しくチームに参画するメンバー用のオンボーディング・デック(チームの一員として働き始めるための、価値観・実務・スキル・相互理解のための明文化されたドキュメント集)が存在するか。 |
TEAM-2-5 | プラクティス | チームメンバー全員で定期的にカジュアルにコミュニケーションをとる場がある(ランチ、ディナー、レクレーション等) |
TEAM-2-6 | アンチパターン | オンボーディングプログラムが、文章を読むだけのものになっており、ハンズオンやミッション理解の伴わない形骸化したものになっている。 |
TEAM-2-7 | アンチパターン | 1年以上チームのやることが変わっておらず、チームメンバーも固定されている。 |
TEAM-2-8 | アンチパターン | チーム内でチームミッションの改善に関係する議論がどんな理由であれ発生していない。 |
3.心理的安全性
なぜ重要か
チームメンバーが相互に自分の意見を言ったとしても、不利益を受けることがないという環境がソフトウェア開発の生産性につながることが知られています。 このような状態を心理的安全といいます。心理的安全性についての継続的な投資はチームの生産性につながります。
Name | PointOfView | Criterion |
---|---|---|
TEAM-3-1 | メトリクスの計測 | チームメンバーの心理的安全性を測る指標があり、定期的に計測しているか。 |
TEAM-3-2 | 学習と改善 | 1on1や、落ち着いた場面でのカジュアルな雑談を含む直接業務に関わらないキャリアやタスクの壁打ちを、月に1度程度は実施しているか。 |
TEAM-3-3 | プラクティス | チームメンバーの行動/発言を明示的に承認行為をおこなう習慣があるか。(成果ではなく行動したこと自体に対して、拍手する・感謝を述べるなど) |
TEAM-3-4 | プラクティス | チームメンバー間で挨拶をしたり、雑談をする習慣はあるか。 |
TEAM-3-5 | プラクティス | チームの不安や不満などを可視化し、吸い上げるための仕組みを持っているか。 |
TEAM-3-6 | アンチパターン | ミッションや共通のゴール設定をしないまま意見を集め、課題のためというよりも個人のための意見しか出てこない状況になっている。 |
TEAM-3-7 | アンチパターン | 心理的安全性を仲の良さと捉えて、事業のための意見ではなく、仲良くすることが目的化しているため、意見を封殺してしまう。 |
TEAM-3-8 | アンチパターン | 事業目標や納期目標に対して、威圧的なマネジメントや権威的な命令を繰り返したことで、意見が出てこない状況になっている。 |
4.タスクマネジメント
なぜ、重要か。
チーム全体で、タスクが明文化されないまま口頭などでのやり取りが多かったり、曖昧な要求が多いとそれだけ手戻りの手間が生じてしまいます。 明文化しきれないことも多々ありますが、継続的に基準をアップデートすることで、ムラのない仕事のスピードを得ることができます。
Name | PointOfView | Criterion |
---|---|---|
TEAM-4-1 | メトリクスの計測 | アイデアレベルの要望や構想から、要件に落ちるまでのリードタイムは計測されているか。 |
TEAM-4-2 | 学習と改善 | 仕事を始めるための定義と、完了するための定義はチームやステークホルダーで定期的に見直されているか。 |
TEAM-4-3 | プラクティス | 上長やステークホルダーを含め、共通のタスク管理ツールを利用しており、プロジェクトの状況を可視化したダッシュボードに常にアクセス可能か。 |
TEAM-4-4 | プラクティス | チームが仕事を始めるために必要な課題やタスクの粒度について、明文化されたフォーマットが存在するか。 |
TEAM-4-5 | プラクティス | チームのタスクに関して、「完成(完了)の定義(Definition of DONE)」が存在するか。 |
TEAM-4-6 | アンチパターン | 他部署からの依頼が明確なタスクツールではなく、担当者へのダイレクトメール/メッセージ/口頭など透明性のない形で行われている。 |
TEAM-4-7 | アンチパターン | どのチームタスクであるかが曖昧なとき、ボールが落ちないようにするための仕組みや文化が存在しない。 |
TEAM-4-8 | アンチパターン | どのチームタスクであるか曖昧な仕事が発生したあとに、事後検証(ポストモーテム)が行われず都度話し合いで解決している。 |
5.透明性ある目標管理
なぜ、重要か。
強いチームを支えるのは明確な目標管理です。たとえば、OKRはそれを支えるツールになりえます。 目標はノルマではなく創造性を生み出すためのツールです。そのため、天下り的な数字のブレイクダウンではなく、仮説とフォーカスをはっきりさせる必要があります。
Name | PointOfView | Criterion |
---|---|---|
TEAM-5-1 | メトリクスの計測 | 1年後などのチームとプロダクトの目指す姿が、言語化され、いくつかの計測可能な指標により明晰化されているか。 |
TEAM-5-2 | 学習と改善 | 仮説的な目標に対して、うまくいかなかった際にチームとして「学んだこと」を言語化・他チームへ公開・学習しているか。 |
TEAM-5-3 | プラクティス | 四半期にフォーカスすべき目標が言語化され、いくつかの計測可能な指標によって明晰化されているか。 |
TEAM-5-4 | プラクティス | フォーカスすべき目標に対して、どのようにアプローチするのかの計画をチームで共有しているか。 |
TEAM-5-5 | プラクティス | ビジネス上、重要なマイルストーンとそのスケジュールをチームで常に共有し、その進捗を確認しているか。 |
TEAM-5-6 | アンチパターン | 目標管理が強く評価制度に結びついているため、ストレッチしたゴール設定をすることが難しくなっている。 |
TEAM-5-7 | アンチパターン | 目標項目の一部に、その達成手段が健全に行われているかをチェックするための目標(健全化指標)を立てていない。 |
TEAM-5-8 | アンチパターン | 目標が定量的でなく、第三者からみて達成度合いが不明確なものになっている。 |
6.経験主義的な見積りと計画
なぜ、重要か。
アジャイルプロセスにおいては、計画や見積りを行わないという誤解を持っていることがあります。 本来は実験を繰り返すことで精度を高めながら、プロジェクト予測の正確性をたかめていくための計画管理を行うことが多いのです。ミッションに応じて適切な手法を選べる能力があるかを調査します。
Name | PointOfView | Criterion |
---|---|---|
TEAM-6-1 | メトリクスの計測 | チームのベロシティを把握しており、その分散値の変化を計測しているか。 |
TEAM-6-2 | 学習と改善 | 見積りと実績の履歴を元に、見積りの精度を向上させるための方法について定期的な学習/ふりかえりを行なっているか。 |
TEAM-6-3 | プラクティス | 見積りは、実際にその仕事を行う本人を含むチームの複数人で行われているか。 |
TEAM-6-4 | プラクティス | スケジュールがクリティカルな場合には当初から精密に、仮説検証や価値がクリティカルな場合には荒い粒度から段階的に詳細化するなどして、状況に応じて見積りや計画の方法を変えているか。 |
TEAM-6-5 | プラクティス | 相対見積もりの基準となる要件(ユーザーストーリー)が存在し、定期的にアップデートしているか。 |
TEAM-6-6 | アンチパターン | スケジュールのバッファ(緩衝期間)が全体計画に対して1/4以下しかもうけていない。 |
TEAM-6-7 | アンチパターン | 機能要件のバッファ(緩衝機能)を全体計画に対して設けられていない。(「必須な機能」と「あったらよい機能」が分類されず、曖昧になっている。) |
TEAM-6-8 | アンチパターン | 相対見積もりによって得られたベロシティの数値自体を、生産性の指標にしており、数値的なコミットメントや改善が要求されている。 |
7.ふりかえり習慣
なぜ、重要か。
チーム活動において、ふりかえりは最も基礎的で最も重要な習慣です。 一方で当たり前すぎるために議論が発散したり、マンネリ化を招いてしまうことがあります。 テーマを決めて事実に基づいたふりかえりを行う習慣があるかを検査します。
Name | PointOfView | Criterion |
---|---|---|
TEAM-7-1 | メトリクスの計測 | ふりかえりのテーマごとに数字を集めたり計測するなどして、ファクトベースで議論できるようにしているか。 |
TEAM-7-2 | 学習と改善 | チームのメンバーは、チームで合意した1カ月以内のサイクルでふりかえりを実施しているか。 |
TEAM-7-3 | プラクティス | ふりかえりの場はチーム全員が参加しているか。 |
TEAM-7-4 | プラクティス | ふりかえりはテーマを定め、議論を行い次回のふりかえりまでに実行可能なタスクが切り出されているか |
TEAM-7-5 | プラクティス | ふりかえりにおいて前回のふりかえりで改善するために起案したタスクが実行されたか検証しているか |
TEAM-7-6 | アンチパターン | ふりかえりをしていたが、しばしば意見が出なかったため、ふりかえり自体をやめた。 |
TEAM-7-7 | アンチパターン | ふりかえるべきテーマに関しての、起きた出来事を時系列に事実関係を整理するなどの準備をせずにふりかえりをすすめている。 |
TEAM-7-8 | アンチパターン | ふりかえりに適切なファシリテーターがいない。 |
8.バリューストリーム最適化
なぜ、重要か。
高速な仮説検証サイクルを行うチームのマネジメントは、短期的なプロジェクト計画の効率性よりも継続的にすばやく機能をリリースできるのかというバリューストリームの効率性を重視します。そのため、各工程でのサイクルタイムやリードタイムを計測し、それらを短くするように活動します。
Name | PointOfView | Criterion |
---|---|---|
TEAM-8-1 | メトリクスの計測 | チームのリードタイム、フロー効率性および各工程のサイクルタイムを継続的に計測しているか。(またはエンジニアリングインテリジェンスのサービスを利用している) |
TEAM-8-2 | 学習と改善 | チームのバリューストリームマッピングを作成し、繰り返しボトルネックを把握しながら自動化と学習を繰り返しているか。 |
TEAM-8-3 | プラクティス | バリューストリーム改善のために、開発リソースの10%以上を継続的に確保しているか。 |
TEAM-8-4 | プラクティス | 設定ファイルや一部のソースコードに対して、エンジニアでなくても必要に応じて修正のためのPull Request(Merge Request)を投げることがあるか。 |
TEAM-8-5 | プラクティス | ペアプログラミング/モブプログラミングを実施しているか。 |
TEAM-8-6 | アンチパターン | 属人的なタスクがある状態を効率的だと解釈して改善をしない。 |
TEAM-8-7 | アンチパターン | フロー効率性などの数値指標に囚われすぎて、全体の効率が悪化するなど価値提供に結びつかない状態である。 |
TEAM-8-8 | アンチパターン | 数値改善のために簡単で予測可能な仕事ばかりを引き受け、難しめのタスクを引き受けない。 |