この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  最初に、自己紹介をやり直させてください。私は長らく「私設・日本式アジャイルを撲滅する会」の会長を務めています。会員数は非公開（というより、数えたことがありません）。会費はなく、会則と設立の経緯は、本稿の最後に載せます。  表向きはおふざけです。でも、中身は大真面目です。そして実際に良く訊かれます。  今回は、豆蔵のアルバイトとしてではなく、この怪しげな会の会長として、なぜこれを撲滅したいのかを書いておきます。 質問 #  取引先から「日本式アジャイル（ハイブリッドアジャイル）」という進め方を提案されました。要件定義まではしっかり固めて予算を確定し、開発は2週間ごとの反復で進め、最後にまとめて総合テストをするそうです。予算が確定するので社内の稟議も通しやすく、うちの会社に合っていると思うのですが、何か問題はあるでしょうか？ 回答 #  進め方そのものは、過渡期の形としてはありえます。問題は名前です。要件と予算を先に確定するなら、その後に変更できる量は、ウォーターフォールの変更管理とほとんど変わりません。それを「アジャイル」と呼ぶと、発注側は手に入らない柔軟性を期待してしまいます。 アジャイルの自由度が得られないなら、「ハイブリッドウォーターフォール」と呼ぶほうが誠実 です。  そして、総予算を先に知りたいという要望は、実はアジャイルと矛盾しません。確定させるべきは、要件の一覧ではなく、予算と目的です。 撲滅したいのは「やり方」ではなく「売り方」 #  まず、何を撲滅したいのかをはっきりさせておきます。  要件定義までをウォーターフォールで進め、構築だけを反復し、最後にテストをまとめて行う。この形には「ウォータースクラムフォール」という名前があります。調査会社ForresterのDave Westが、多くの組織におけるアジャイルの現実の姿として名付けたものだと言われています。前の工程（要件と予算の承認）と後ろの工程（テストとリリース）が従来のまま残り、真ん中だけが反復になる。アジャイルへの移行の途中で、多くの組織が一度は通る姿です。  だから、この段階にいること自体を責めるつもりはありません。番外編「正論が通らないとき」で書いたとおり、組織の前提が動かないなかで、できるところから始めるのは正しい戦い方です。  当会が撲滅したいのは、この過渡期の姿を「日本の組織に合ったアジャイル」と呼び、到達点として売る言説のほうです。到達点として売られると、移行（この移行とは言い換えれば進化です）はそこで止まります。 なぜ「日本式」は売れるのか #  この売り方が一定の訴求力を持つ理由は、よく分かります。  発注側は、総予算を早く知りたい。稟議を通すには金額が要ります。受注側は、金額を出せなければ受注できない。かといって、いい加減な数字で契約するわけにもいかない。だから、要件定義をしっかりやって、予算を確定させようとする。ここまでは、どちらの立場から見ても合理的です。誰も悪いことはしていません。  問題は、その次です。 変更できる量は、変わらない #  要件を確定して予算を確定するということは、その後の変更は「予算の枠の中での変更」になる、ということです。枠を超える変更は、変更依頼を出し、影響を見積り、承認を取る。これはウォーターフォールの変更管理プロセスそのものです。反復の単位が2週間になっても、総量で見ると変更できる量はほとんど変わりません。  それなのに、「アジャイル」という言葉には「柔軟に変更できる」というイメージがついています。発注者はそのイメージで契約し、後になって「アジャイルなのに、なぜ変更のたびに見積りが出てくるのか」と首をかしげる。  当会ではこれを、 親しみを込めて看板詐欺 と呼んでいます。  ……と言うと角が立つので、本文ではもう少し正確に書きます。売る側が意図して騙しているとは限りません。むしろ多くの場合、売る側も、自分たちはアジャイルをやっていると 信じています 。ただ結果として、 発注者は手に入らない柔軟性を期待させられている 。  看板と中身が一致していない、ということです。 看板と中身がずれると、何を失うか #  名前の問題だけなら、目くじらを立てるほどではないかもしれません。しかし、このずれは実害を生みます。連載で扱ってきた問題の多くが、この形では構造として組み込まれてしまうからです。 学習が成果物に届かない : 要件が確定しているので、スプリントレビューで「こうではなかった」と分かっても、作るものは変えられません。第8回で見た、誰の意思決定にも影響しないレビューが、例外ではなく標準になります。 間違いに気づくのが最後になる : テストを最後にまとめるので、スプリントで「完成」したものは、実際には未検証です。第11回のテスト先送り型が、公式の工程になります。早く間違いに気づくというアジャイルの最大の効能が、そこで消えます。 手間は両方の合計になる : ウォーターフォールの文書と承認はそのまま残り、そこにスクラムのイベントが加わります。現場には「アジャイルにしたら会議が増えた」という記憶だけが残ります。 足腰を鍛える理由がなくなる : 最後に人手でまとめてテストするなら、テスト自動化もCIも要りません。業務系の現場で長年見送られてきたこの投資は、この形では永久に正当化されません。 POが検収係に戻る : 要件が先に確定しているので、POは方向を決める人ではなく、仕様どおりかを確かめる人になります。第8回で見た「社内外注」の構図が、そのまま温存されます。  そして、いちばん大きい害は、これらの結果として組織に残る結論です。コストは増え、品質も納期も変わらず、学習も起きない。それが「アジャイル」の名前で行われるので、組織には「アジャイルを試したが、うちには合わなかった」という経験則が残ります。次に本物を試そうとする人の前に立ちはだかるのは、前例主義が多い中でこの失敗の記憶です。番外編「正論」で、過去にカタカナの流行りもので痛い目を見た組織は看板を見ただけで身構える、と書きました。その種を撒いているのが、この売り方なのです。 総額は、先に出せる #  では、発注側の「総予算を早く知りたい」にどう応えればいいのか。実は、アジャイルはこの要望と矛盾しません。  期間とチームの規模を決めれば、総額は先に確定できます。そのかわり、中身は固定しません。優先順位の高いものから作り、届けて、結果を見て、残りの順番を入れ替える。予算と目的を固定し、スコープを動かす。第4回で扱った、全機能を確定せずに見積りを出す話も、この考え方の上にあります。  つまり、発注側が本当に知りたいのは総額であって、全要件の確定ではありません。日本式アジャイルは、総額を出すという名目で要件まで確定し、そのうえで「アジャイルだから柔軟です」と言っている。ずれているのは、ここです。  自分の案件がどちらなのかを見分けるには、一つの問いで足ります。 契約で確定しているのは、要件の一覧か。それとも、予算と目的か。  要件の一覧が確定しているなら、反復をしていても、中身はウォーターフォールです。予算と目的が確定していて、中身が優先順位付きの候補一覧として扱われているなら、アジャイルの自由度は実際に手に入っています。変更依頼の書類を出さずに、項目の入れ替えができるかどうか。実地の判定は、それで十分です。  もちろん、契約の形を変えるのは簡単ではありません。一括請負、社内の開発標準、監査の要件——動かせない前提はいくらでもあります。だからこそ、動かせないうちは、正直な名前で呼んでください。 ハイブリッドウォーターフォール 。この名前なら、発注者は正しい期待値を持てますし、受注側も約束していない柔軟性で責められずに済みます。  番外編「正論」の第三原則は「中身があるなら、看板にこだわるな」でした。今回はその裏返しで、 中身がないなら、看板を掲げるな です。 AI時代の、新しい看板 #  ついでに、これから現れそうな新しい看板にも、会長として注意報を出しておきます。  生成AIを開発の中心に据える「AI駆動開発」や、仕様を先に書いてAIにコードを生成させる「仕様駆動開発（SDD: Spec-Driven Development）」が注目されています。表面だけ見ると、どちらも「先に仕様をきちんと書き、構築はAIで速く回す」形をしています。日本式アジャイルの「要件定義をしっかり固め、構築だけ反復する」と、驚くほどよく似ています。「AI時代こそ上流が大事。やはり要件定義を固めてから作るやり方は正しかった」——そんな売り文句が出てくるのは、時間の問題だと思っています（いや、すでにもう出ているかも…）。  しかし、論理は逆を向いています。SDDの肝は、仕様が先にあることではありません。 仕様を直して作り直すコストが、ほとんどゼロになること です。仕様は機能や増分の単位で小さく書き、動くものを見て学んだら、仕様を直して作り直す。仕様は契約書の付属書ではなく、リポジトリの中のファイルとして生き続けます。  かつて、前工程で大きく設計しておく根拠は「後で変えると高くつく」でした。XPがテストとリファクタリングで崩そうとしたこの前提を、AIはさらに崩します。 後で変えるのが安く済むなら、前で全部を確定しておく理由は、むしろ弱くなる のです。  危ないのは、SDDの形だけを借りて、システム全体の仕様を前工程で確定し、契約で凍結する組み合わせです。それは「AIで速く打鍵するウォーターフォール」であり、間違った仕様から、間違ったものを、今までより速く大量に作る仕組みです（そして人はおそらくそれをレビューしきれない）。  第1回で書いた AIいいなり開発の組織ぐるみ版の完成 と言ってもいいでしょう。  公平のために付け加えると、AIによって「意図を先に、はっきり言葉にする」ことの価値が上がったのは事実です。先に書くこと自体は、アジャイルと矛盾しません。アジャイル宣言が言っているのは「よりも」であって、「書くな」ではありません。アジャイルに反するのは、先に書くことではなく、大きな単位で書いて凍結することです。  だから、先ほどの問いは、AI時代にはこう言い換えられます。 その仕様書は、契約の付属書か。それとも、リポジトリの中のファイルか。  直すたびに変更依頼書が要るなら、AIが何を生成しようと、それはハイブリッドウォーターフォールです。 「日本式」という名前の皮肉 #  最後に、会長として、どうしても言っておきたいことがあります。「日本式」という名前のことです。  「スクラム」の出どころを辿ると、竹内弘高・野中郁次郎の両氏が1986年に発表した論文「The New New Product Development Game」に行き着くことは、多くの方がご存知の通りです。この論文は、工程を順番に引き継いでいく開発をリレー競走に、工程を重ねて全員で一緒に前進する開発をラグビーにたとえ、日本の優れたメーカーの強みは後者にあると論じました。スクラムという名前は、ここから来ています。  ウォータースクラムフォールは、リレー競走の真ん中に、スクラムを一つ挟んだ形です。日本の現場の強みとして世界に紹介されたものの、ちょうど逆をやって「日本式」と名乗っている。  本当の日本式は、とっくに海を渡り、スクラムという名前で逆輸入されているのです。 会則 #  というわけで、当会の会則を参考までに載せておきます。入会も退会も自由です（←冗談だからね。募集してないよ）。 第一条: 看板に偽りなし  アジャイルの自由度が得られない進め方を、アジャイルと呼ばない。要件と予算を先に確定するなら、ハイブリッドウォーターフォールと呼ぶ。 中身がないなら看板を掲げるな 第二条: 過渡期は歓迎、到達点にはしない  ウォータースクラムフォールにいることは恥ではない。ただし、次にどこを崩すかを決めておく。テストを前に寄せる、要件を確定する範囲を小さくする、途中でリリースを挟む。どれか一つでいい。 第三条: 契約を確かめる  「アジャイルで進めます」と言われたら、契約で確定しているのが要件の一覧か、予算と目的かを確かめる。 第四条: 変更は、入れ替えで  変更を歓迎するなら、入れ替えのルールを先に合意しておく。何かを入れるときは、何かを外す。その判断を誰がするかも決めておく。 なぜこんな会があるのか #  会長を名乗るようになったのは、同じ看板の下で、正反対の二つの混乱を何度も見てきたからです。  一つ目は、柔軟性がまったくない現場です。要件定義で決めた機能リストを、スプリントごとに順番に消化していく。私はこれを、 分割払い と呼んでいます。買うものも総額も、契約の時点で決まっている。スプリントは、その支払いを何回に分けるかを決めているだけです。途中で「やっぱりこれは要らなかった」と分かっても、残債は払い続けるしかない。スプリントレビューで利用者の反応を見ても、次のスプリントで作るものは、もう決まっています。反復はしているのに、学習が入り込む隙間がないのです。  二つ目は、その逆です。発注側が「アジャイルだから変更は自由」という看板を真に受けて、変更をどんどん出してくる。ところが予算と要件は確定済みなので、受注側には、その変更を吸収する枠がありません。最初は無理をして受け入れ、残業と品質の低下で吸収し、限界が来たところで変更管理が復活する。発注側からは「アジャイルと言ったじゃないか」、受注側からは「予算の中でと言ったじゃないか」。どちらも、嘘はついていません。  この二つは、同じ看板の表と裏です。一つ目は、受注側が中身をウォーターフォールのまま守った結果。二つ目は、発注側が看板のほうを信じた結果。そして、どちらの現場にも欠けていたものは同じでした。本来のアジャイルで変更が歓迎されるのは、予算と期間という枠の中で、 新しく入れるものの代わりに、優先順位の低いものを外す からです。変更とは追加ではなく、入れ替えのことです。この入れ替えのルールを、誰も契約にも合意にも書いていなかった。分割払いの現場では入れ替えが許されず、変更が殺到した現場では入れ替えが求められなかった。  日本式アジャイルという看板は、このいちばん大事な一行を、どちらの側からも見えなくしてしまうのです。  撲滅と言いながら、当会の目標は会の解散です。「日本式アジャイル」という言葉が使われなくなり、過渡期が過渡期として、正直な名前で呼ばれるようになったら、その時晴れがましい心持ちで当会は解散する事ができるでしょう。 本編の連載一覧は第1回をご覧ください。

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。今回も、予告なしの番外編をお届けします。  第8回の最後に、「ステークホルダー側がどうしても動いてくれない環境での戦い方も、いずれこの連載のどこかで」と書きましたが、今回がその「いずれ」です。  と言いつつも、「上が理解しないからアジャイルができない？ごちゃごちゃ言ってないでやれよ」という、みもふたもない話ではあるのですが。 質問 #  この連載の処方は参考になるのですが、その多くが最後は「発注側と交渉する」「組織に提起する」に行き着きます。うちの発注側・経営層は、はっきり言って聞く耳を持ちません。「現行通りやれ」「で、何人日？」「アジャイル？　流行りものはいい」で会話が終わります。正論（全てとは言いませんが、私には多くが正論のように思えます）が通らない環境では、結局アジャイルは無理なのでしょうか？ 回答 #  無理ではありません。ただし、順序を変える必要があります。この連載の処方を「交渉に勝ってから実践する」と読んだなら、それは逆です。実践できるところを先にやり、実績を作り、実績を持って交渉する。 交渉とは最初の関門ではなく、最後の仕上げ です。  そして覚えておいてほしいのは、この連載の処方のうち、 誰の許可も要らないものが思いのほか多い ということです。 まず、相手の「聞く耳のなさ」を分解する #  腹立たしい話から入る前に、一度冷静に相手を観察します。聞く耳を持たない側にも、たいてい構造的な理由があります。 実績のない提案はリスクにしか見えない : あなたにとってアジャイルは合理的な提案でも、相手にとっては「よく知らないやり方に、自分の責任を賭けろ」という要求です。断るのは、その人の立場ではむしろ誠実な判断です。 変えないことが最適解になる評価構造 : 現状維持で誰も罰されない組織では、変更の提案は「うまくいって当然、失敗すれば提案者の責任」という非対称な賭けになります。 過去に「カタカナの流行りもの」で失敗している : 何年か前の別の三文字略語で痛い目を見た組織は、看板を見ただけで身構えます。  つまり相手は、あなたの論理に反対しているのではなく、あなたの提案に含まれる不確実性に反対していることが多いのです。だとすれば、打ち手は「もっと正しく説明する」ではありません。不確実性を下げること——つまり、小さな実績です。第5回で、正論で押すと相手には「べき論の押し付け」と映り、かえってブレーキになると書きました。「正しく説明したのに通らない」で止まっているなら、それは同じ罠に囚われているのです。 生存戦略 #  今回はいつもの「処方」ではありません。 原則 です。 第一原則: 許可の要らない領域から始める  この連載の処方を「許可が要るか」で仕分けし直してみてください。割り込みの記録（第12回）、レトロの冒頭で前回Tryを確認する（第7回）、ボードの右端から歩く（第6回）、そして今後の回で採り上げていく予定の、決定事項の棚卸し、改修リードタイムの記録、ADR（意思決定の記録）を10行書く…これらは全部、誰の許可も要りません。チームの内側で完結する改善と、記録・計測は、今日から始められます。  暴論にならないように申し添えておくと、監査や契約で作成が義務付けられた文書の扱いだけは裁量の外です。同様に、社内の開発標準が適用される案件で進め方そのものを変えるなら、それは標準の適用除外の手続きに乗せる事項であり、「許可の要らない領域」ではありません。  落ち着いて見直してみましょう。「上が動かないから何もできない」は、たいてい事実ではありません。 第二原則: 実績を先に、交渉を後に  小さく始めて、数字を持ってから話しに行きます。「アジャイルを導入させてください」ではなく、「この3ヶ月、割り込みを記録したらキャパシティの4割を食っていました。来月から受付を一本化させてください」。前者は 思想の議論 になり、後者は 事実の議論 になります。思想は好みで却下できますが、事実は却下しにくい。この連載が繰り返し「まず測れ」と言ってきたのは、計測が改善の道具であると同時に、 権限のない者の交渉力の源泉だから です。 第三原則: 看板を下ろして、中身を通す  「スクラム」「アジャイル」という言葉が扉を閉ざすなら、言葉を使わなければいいのです（正直に吐露しますが、私には「出来ないヤツほど手法の名前を前面に出す」という偏見があります）。スプリントと呼ばずに「2週間ごとの区切りで確認会をやります」。レトロと呼ばずに「月次の業務改善ミーティングです」。バックログと呼ばずに「優先順位付きの課題一覧です」。中身が回り始めて成果が出たころには、名前はどうでもよくなっています。看板への忠誠より、中身の実践です。  誤解のないように付け加えると、これは決められた手続きを黙って迂回する話ではありません。自分たちに認められた裁量の範囲で、呼び名を相手の言葉に合わせるだけです。だから… 直属の上司には「呼び名を変えて運用している」と伝えておくこと 提案書や契約書に開発方法論が明記されているなら、その文言との整合を先に確認すること 開発標準の成果物名で報告が求められるなら、チームの呼び名との対応表を1枚作っておくこと  この3つを外すと、迂回と区別がつかなくなります。むしろ、 名前を使わずに説明できるかどうかは、自分が中身を理解しているかのテスト にもなります。 第四原則: 負けた交渉は、記録して再挑戦の弾にする  提案が却下されたら、却下された事実と、その後に起きたこと（予測していたリスクが実際に起きたか）を淡々と記録します。置き場は個人メモではなく、チームの課題管理表やインペディメントリスト（チームの障害物を一覧化した公式の記録）のような公式な場所に。感情を挟まず、恨み節にせず、事実だけ。「4月に受付一本化を提案し見送りとなった。5〜7月の割り込みは月平均◯件で、うち◯件が納期遅延に直結した」。この記録が2〜3回分たまったとき、同じ提案の通る確率は大きく変わっています。  組織はしばしば、最初の提案は退けるが、事実の蓄積には折れるものです。それは組織の側の生存戦略としては合理的です。それを前提に備えておきましょう。 第五原則: それでも動かないなら、持ち出せる資産に投資する  すべてを尽くしても動かない組織は、残念ながら存在します。そのときに覚えておいてほしいのは、ここまでの実践——計測の習慣、記録の規律、小さく完成させる技術、看板なしで本質を説明する言葉——は、すべてあなたとチームに蓄積される資産だということです。組織に残っても積み上がり続けますし、どの環境に行っても持ち出せます。組織を変えられなくても、自分の実力と市場価値は確実に変わっています。  これは転職の勧めではなく、投資先の選択の話です。 組織が動くかどうかはコントロールできませんが、自分が何を学ぶかはコントロールできます 。 なぜこの状況は30年繰り返されるのか #  権限のない者が現場から組織を変えようとする、という構図自体が、ソフトウェア開発の歴史そのものだからです。思い出してほしいのですが、アジャイルは経営層のトップダウンで生まれた方法論ではありません。重量プロセスに苦しむ現場の実践者たちが、権限のないところから小さく実践し、実績を持ち寄り、言葉を与え、やがて業界を動かした——草の根の運動でした。  つまり「聞く耳を持たない相手の前で、それでも小さく始める」のは、アジャイルにとって例外状況ではなく、出生時の姿です。あなたが今いる場所は、30年前（あるいはもっと前）に先人たちがいた場所と同じです。そして彼らの武器も、今のあなたと同じでした。  小さな実践と、記録された事実。  それで十分に、始められるはずです。 次回: 「POが多忙でチームに来ません」／本編の連載一覧は第1回をご覧ください。

こんにちは。QAコンサルタントのテストのひろさんです。 本記事では、テスト進捗自体は順調なものの、現場の役割にミスマッチが生じていたプロジェクトの改善事例を紹介します。当時テストPMだった私が、JSTQB AL-TM v3.0Jシラバスなどの知見を活用し、どのように体制再構築と再発防止に取り組んだのかをお伝えします。 現場の運用に課題を感じている方の気づきや、参考になれば幸いです。 対象プロジェクトの概要 当時のテストプロジェクトの基本情報は以下の通りです。 テストレベル: システムテスト 期間: 2か月 テスト環境: オンサイト プロジェクト計画: システムテストの後に、機能追加に対するシステムテストを計画 チーム構成: PM（私）1名、テストリーダー（TL）1名、ビジネスパートナー（BP）リーダー1名、BPテスター3名 役割分担: BPリーダー: 日々の進捗報告（TL宛）、QA・タスクリストの更新、ハンズオンでのテスト実施。進捗フォーマットやステータス管理手法はトレーニング済み。 BPテスター: テスト実行全般。 TL: 進捗管理、探索的テスト実施、機能追加のテスト設計、QA・タスクリストのチェックや回答。 PM: 複数テストプロジェクトの統括。 立ち上げ時、TLの業務負荷が潜在的なリスクとして見受けられました。しかし、以下の理由からそのような計画で進行することを決定しました。 システムテストの一次報告はBPリーダーが実施すること 機能追加に伴うテスト設計の規模が限定的であること 探索的テストの工数や時期を調整可能であること 具体的には、最初の2週間は進捗管理とQA対応に注力し、3週間目から機能追加のテスト設計および探索的テストを開始するスケジュールを設定しました。 進捗の裏側に生じていた問題 システムテスト開始後、BPリーダーからは予定を前倒しで進めていると報告を受けていました。しかし、詳細を確認していくと以下の状況でした。 テスト進捗は専用のツールで算出するのですが、私が改めて算出し直した進捗数と、実際に報告されている進捗数が異なっていました。また、課題管理表の内容とTLから報告されている内容が一致していなかったり、課題管理表そのものに記載が漏れている等の状況に気づきました。 起きていたことをまとめると以下の状況です。 実際の進捗数と報告された進捗数の不一致 タスク管理表と実際の作業状況のズレ、および記載漏れ TLはBPリーダーへ是正を何度か依頼しましたが改善されず、事実確認などの対応に追われることになります。結果としてTLの工数が圧迫され、予定していた機能追加のテスト設計や探索的テストに入れない状況が発生しました。 この時、現場では以下のような心理的・運用的課題が生じていたのです。 TLの心理: テスト設計も探索テストも進まず、進捗もまとまらないという状況から、自身の評価への懸念が生まれ、PMに相談できず一人で抱え込んでいた。 BPリーダーの心理: 上手く進捗報告ができていないという認識はあるものの、具体的な改善方法が見出せず困惑していた。 双方ともに悩んでいる状態でした。ここで少し私の考えを挟むと、悩むとは問題を認識して試行錯誤しているが出口が見えない状態であり、考えるとはゴールが見えていて、そこに向かっていく状態だと捉えています。当時の現場は、まさに前者の出口が見えない状態に陥っていました。 さらに、この是正がうまくいかない日々が続いたことで、テストリーダーとBPチームの間にも徐々に不穏な空気が流れ始め、コミュニケーションが膠着する二次災害も起き始めていました。 1. 捉え方の転換：個人の問題ではなく構造の問題 この状況に直面した際、私は起きている問題を個人の資質や特性に起因させないことが重要であると考えました。 一見すると報告が不正確なリーダー、抱え込んでしまうTLのスキル問題に見えますが、本質は違います。これは、現場の状況変化に対してプロジェクトの初期枠組みが適合しなくなったことによる構造的な問題であると捉えました。 ここでベースにしたのは、人を責めず、仕組みを改善するという方針です。書籍「スクラム」などにある「プレイヤーを憎むな、ゲームを憎め」という言葉の通り、個人を責めても本質的な解決にはならないと私は考えています。 JSTQB AL-TM v3.0J には、以下のような記述があります。 「テストチームは、プロジェクト開始時に、必要なスキルをすべて持っているとは限らない。完璧な人材がそろうとは限らないが、強力なチームであれば、個人の長所と短所のバランスを取ることができる。」 最初から完璧な人材がそろうチームは難しいことがあるため、個人のせいにせず、仕組みや役割によってバランスを取るという考え方から、システムテストの進行途中で以下のように役割と環境の再配置を行いました。 役割の再定義 BPリーダー: 進捗報告・管理業務から一旦離し、ハンズオンテストの割り当てを80%に増加。タスク管理の不備がスキルの問題なのか業務過多によるものなのかを切り分けるとともに、テスト実行の推進に集中するようにしました。残りの20%はPMやメンバーとのコミュニケーションに充てる割合に変更しました。 テストリーダー（TL）: テスト管理やBPチームとのコミュニケーションをタスクから切り離し、本来のミッションである探索的テストの実施と機能追加のテスト設計」に専念できる工数を確保しました。 PM（私）: このシステムテストの進捗管理を巻き取りました。BPリーダーとのコミュニケーションは、時間を固定して1日2回（各10分）の状況確認を実施する運用へ変更しました。 物理環境の変更（座席位置の調整） また、TLとBPチームの間で関係性の悪化（コミュニケーションの膠着）が見られたため、オフィスの座席配置を変更して物理的な距離を置きました。これにより、TLによるBPチームへの細かな確認や介入を構造的に抑制し、TLもBPチームも自分たちのタスクに集中できる環境を整備しました。 ガバナンスの再構築 正確な情報を把握するため、これまでチャットベースで済ませていた報告を「対面での同期」に切り替えました。これは指示命令を強化するためではなく、事実（ファクト）と報告の同期を目的としたものです。情報の透明性を確保することで、プロジェクトの正確な現状がステークホルダーやチーム全体に共有される仕組みへと変更しました。 2. 心理的安全性と規律の両立：1on1における対話 役割変更と並行して、TLとの1on1を実施しました。目的は、心理的安全性を確保した上で役割変更の背景を納得してもらい、機能追加テスト設計、探索的テストに集中してもらうことです。1on1では、特に以下の3つの軸を意識して対話を行いました。 評価の切り分け（安心感の醸成）: 今回の介入はあくまで、体制上の判断による役割の変更であり、TL個人の評価を下げるものではないことを明言しました。テスト期間中であり、最終的な品質やゴールに対する結果はまだ出ていないためです。 ティーチングの選択: 通常であれば自律的な成長を促すコーチングを採用しますが、今回は納期が迫る緊急時であったため、私のやり方を直接伝えるティーチングへと戦略的にシフトしました。山本五十六の「やってみせ、言って聞かせ、させてみせ、ほめてやらねば、人は育たず」の方針のもと、並走しながらサポートしました。 コミュニケーションの原則（アサーション）: 強い言葉で行動を縛るのではなく、仕組みで解決を図る姿勢（アサーションの原則）を大切にしたい旨をTLに伝え、目線を合わせました。 3. 再発防止：根本原因の特定と仕組みのアップデート プロジェクト完了後、次フェーズである機能追加テストに向けて、今回の問題の根本原因の特定と仕組みのアップデートを行いました。 根本原因：正しいデータが報告に繋がらない集計・出力構造 そもそも、なぜ進捗報告と実態の乖離が起きていたのか。仕組みとしてExcel上で予定と実績が10%以上乖離するとセルが赤字になるというアラートのルール自体は存在しており、Excel内の関数やシステム側の元データも正常でした。 しかし、最終的に算出されたデータを、報告用にアウトプットする（テキスト化する）段階で人為的なミスが発生していたことが根本原因でした。 当時の集計・報告フローは以下の通りです。 テスト管理システムから正しい実績データをCSVでダウンロードする 集計用のExcelへコピー＆ペーストする（Excel上の関数・アラート自体は正常に機能） Excelで算出された数値を、手作業で報告用のテキストに書き起こす（ここで転記ミスが発生） 最終的な報告テキストを作成するまでに手作業のプロセスが多く、結果としてExcel上ではアラート（赤字）が出ていても、報告段階でそれが消えてしまうという、人為的ミスを誘発しやすい構造になっていました。BPリーダー個人を責めるのではなく、ミスが起きる構造を変える必要がありました。 対策：集計・出力の自動化 手作業によるリスクを排除するため、CSVダウンロード後のデータ集約から、Excelでの集計、そして最終的な「報告用テキストの出力」までをワンクリックで行うVBAマクロを導入しました。 これにより、データの信頼性を担保した上で、PMやステークホルダーが日々のモニタリングで客観的な事実（定量データ）をそのまま受け取り、早期に異常（アラート）を検知できる仕組みへとアップデートしました。 4. 再発防止の効果：定量的・定性的アプローチ アップデートした仕組みの効果を現場の感覚で終わらせないために、JSTQB AL-TM v3.0Jのシラバスに記されている以下の格言を指針としました。 「マネジメントには『測定できるものは達成できる』という格言がある。同様に、測定されないものは、無視されやすいので、達成されることはないだろう。したがって、テストを含め、どのような取り組みに対しても、適切なメトリクスを確立することが重要である。」 この考えに基づき、定量的なメトリクス評価と定性的なアプローチ（心理的安全性の確保）の両面から効果を測定しました。 ① 定量的なアプローチ プロジェクトメトリクス: テスト実行数、実行率、ステータス（OK/NG/Block）の推移。自動集計化により、10%の乖離アラートが正しく機能するようになり、進捗の透明性が確保された。 プロダクトメトリクス: BPリーダーのテスト比率を上げたことによる進捗の加速、TLの探索的テストによる、欠陥検出数と修正数の推移。想定していた計画値と実績を比較することで、品質リスクの低減に繋がった。 プロセスメトリクス: 集計作業工数そのものが削減されたことによる相乗効果で、チーム全体の生産性が向上した。 ② 定性的なアプローチ（1on1による内面サポート） 一方で、数字には表すことが出来ないメンバーの悩みや心理的状況は、定性的にしか捉えることができません。ここでは1on1などの直接的な対話によるサポートが不可欠です。 ちなみに、JSTQB AL-TM v3.0Jのシラバスには「方法論的、社会的、個人の能力はテストに特化したものではないため、専門的能力の開発に重点を置く」といった旨も述べられています。つまり、1on1やアサーティブなコミュニケーションといったスキルもまた、マネジメント知識として意識的な習得やトレーニングが必要な領域です。トレーニングや考え方などについては「ヤフーの1on1」「成長マインドセット」などの書籍を参考にしています。 1on1を継続した結果、TLが問題を一人で抱え込まずに早めのアラートを出せる関係性が構築され、BPリーダーも何に困っているかを素直に共有してくれる環境へと変化しました。 おわりに 今回の取り組みを通じて、データの信頼性とアラートの定量化、心理的安全性の確保によって、仕事の側面と人の側面をマネジメントすることの重要さを実感しました。 人が間違えるのは、仕組みに問題があると捉えて、変化の激しいテストプロジェクトを計画したゴールへ導くことが、マネジメントの本質ではないでしょうか。 この記事が、現場の体制構築や運用に悩むエンジニア・マネージャーの皆さまにとって、少しでも新しい視点や気づきのきっかけになれば幸いです。 最後までお読みいただき、ありがとうございました。 （参考文献） JSTQB JSTQB-Syllabus.Advanced_TM_VersionV3.0.J02 スクラム 仕事が4倍速くなる世界標準のチーム戦術（ジェフサザーランド 著、石垣 賀子 訳） ヤフーの1on1 部下を成長させるコミュニケーションの技法（本間 浩輔 著） 成長マインドセット 心のブレーキの外し方（吉田 行宏 著） The post 心理的安全性とガバナンスを両立させるテストチームの改善事例 first appeared on Sqripts .