【事例】密かにアジャイルに近づくための一歩

まとめ

「アジャイルにしようぜ！」と言わずに
(主にスクラムの) プラクティスを少しずつ持ち込んでいった
私の小手先な工夫をご紹介する記事です。

組織標準プロセスの皮を被らざるを得ない人には参考になるかも。

前書き

拝啓 & 背景

こんにちは、職歴がもうすぐ20年になる (IT老人会に入りつつある) JTC¹ に勤務するペーペーです。

RSGT2023のOSTで、JTCにお勤めという若人が「Scrumでやりたいと言っても『うまくいく保証がないからダメだ』²とウォーターフォール³を強制される」と嘆いておられて、
私が以前に実行した姑息な工夫をご紹介したところウケまして。

ひょっとして、真っ向勝負で玉砕して諦めてしまった人が他にもいるかなと思いまして。

真っ向勝負なんかしたことがない私の手持ちをお裾分けしたら、
諦めずに済むかなと思った次第です。

前提となる考え方

JTCでは、まわり全員を「変えたくない」人だと思っておきましょう。
どの工夫から手をつけても良いのですが、必ず「見慣れないものは1つだけ」にしましょう。

ときどき、特定のプラクティスを導入しようとして協力が得られなかった話を聞きますが、
プラクティス1個だと、まだ 変化が大きすぎ ます。

例えば

営業やマーケ、サポートからの依頼がてんでバラバラにメールで届く現状から、案件をProduct Backlogで管理したいとき。

いきなり「JIRAやBacklog等のツールでプロダクトバックログを作ります！」とやると、「なんかわかんなーい」と理解する努力 (という協力) が得られません。

次のように細分化して「見慣れないものは1つだけ」を維持すると反発が少ないです。
（みんなが慣れるまで、次のステップにいかないこと）

1. 「一元管理」を導入

• 新しいこと：
  開発にインプットされる要求等を一箇所にまとめる（リスト化する）。
• 変えないこと：
  • ツールは営業やマーケ等、ステークホルダーみんなが見慣れたものを使う。Excelがオススメ。
    自分達のマスターはJIRA等でも良いが、みんなに共有する際にはExcelにexportして整形したものにする。
  • 開発へのインプット方法は今までどおり (メールなり何なり)。
    リストをメンテするコストは変更したい自分(達)が負う。
  • リストに書く案件等の記載は今までどおりの言葉を使う。
    (メールのタイトルなり抜粋なり)
    断じて、いきなりユーザーストーリーに変更しない。

2. 「優先順位」を導入

• 新しいこと：
  案件に (重複しない) 優先順位をつける。
  優先順位に慣れていない人が多い場合は、高中低といった優先度を導入して慣れてもらってから優先順位に変える。
• 変えないこと：
  • 開発へのインプット方法は今までどおり (メールとか)。
    これに優先度や優先順位の追記を求めない。
  • リストのメンテナンスは自分達でやる。
    優先順位も自分達が決めて「これで良い？」と確認を取る。
    このとき、全員集めて「全部見てね！」とはやらないこと！
    必ず個別に「あなたの持ち込んだこの要求は、こっちの要求が終わったらやります」的に確認する。
    ステークホルダー個人が意識するのは「自分が持ち込んだ案件のみ」のままにする。
  • 面倒なのはわかるが、まだツールは変えない。

3. 「他の人がわかる記載」に変更 & 同じ案件のマージ

• 新しいこと：
  「誰某が持ち込んだ案件」から「こんな機能追加(他)」に変更する。
  ようやくプロジェクトの全体像をステークホルダーみんなで共有する雰囲気を出す。
  同じ案件として扱えるものはマージして ただし 要求者の名前は必ず残す。
  (「俺の要求はどうなった？」は自分で確認できる状態を維持する)
• 変えないこと：
  • 相変わらず、案件はメールで受け取って、リストへの転記等のメンテは自分達でやる。
    ただし「メール出すの面倒」と言い出した人だけはファイルを編集しても良い。
  • まだ優先順位も求めない。が、書いてきた人の言い分は参考にする。
  • まだストーリーにもしない。
    メール等に書かれた「こういうことしたい」をコピる程度。
  • まだまだツールは変えない。

4. ツールを変える

• 新しいこと：
  使うツール だけ 自分達が使いたいものに置き換える。
• 変えないこと：
  • Excelで見ていたものと同じ形式の表viewを用意する。
    もし使いたいツールでExcelと同じ形式の表が作れないなら、作れるようになるまでツール変更は後回し。
  • まだインプット方法はメールをデフォルトにしておくが、新しいツールを使える人には使わせる。
  • まだストーリーにもしない。

5. 優先順位の調整を個別→全体で

• 新しいこと：
  「この表を見れば、どの順で案件に着手するかわかります！順番変えたいところがあったら連絡してね！みんなで話し合いましょう！」
  可能であれば、週1ぐらいの定例ミーティングで表を確認する習慣を導入できると尚良し
• 変えないこと：
  • 表の形式(見た目)、開発チームへのインプット方法、案件の記載(ストーリーにしない)

6. 表の見た目をプロダクトバックログっぽくする

• 新しいこと：
  ストーリーポイントやスプリント等を記載する項目の運用開始。
  ただし、それらの情報は「開発チーム側の補助情報なので、皆さんは気にしなくても良いです～」と連絡しておく。
  ついでに不便だった箇所も変更して良い。「ちょっと見た目変わったけれど、内容は変わらないですよ」に納得してもらう程度に。
• 変えないこと：
  • その他の運用ルール。
  • まだユーザーストーリーにしない。

6. インプット方法を変える

• 新しいこと：
  「これからはメールじゃなくて、このツールに直接書いてね！」
  ただし、ここまでのステップで「このステークホルダーに書かせるのは無理だな」と思ったら、このステップは実行しない。
• 変えないこと：
  • まだ、ストーリーにしない。

7. ユーザーストーリーっぽくする

• 新しいこと：
  「こんな機能追加(他)」の書き方テンプレートを作って、案件の内容を価値やDoDがわかるような書き方にする。
  ここまでのステップで「このステークホルダーにユーザーストーリーを書かせるのは無理だな」と思ったら、別項目として自分達がユーザーストーリーを書く。
• 変えないこと：
  • 呼び方。
    断じて「プロダクトバックログ」や「ユーザーストーリー」と呼ばない。
    ここまでの変換はすべて「既存ルール内に収まる工夫」なのであーる。

本文

以下に、姑息な小手先の工夫 (事例) を列挙します。

プロダクトバックログ 関連

• [前書き]-[前提となる考え方]-[例えば] に書いたあれこれ

• PBIを「顧客要求」として、バグ管理システムに突っ込んで一元管理
  (もちろんプロダクトバックログなんて呼ばない)

• 要件変更管理リストの優先度を優先順位に変更

スプリント 関連

• 「年1回正式リリース、無計画に顧客対応版リリース」の後者の実績を整理して
  「年1回(3月)正式リリース、数ヶ月に1回ベータ版リリース」に誘導

  • 管理が大変だから、似た要望も多いから、複数の顧客要求をまとめてリリースしましょ！と説得
  • テストを顧客にさせていたのを、ハッピーパスぐらいはテストしてからリリースするよう変更

• そこからの、バージョン付けルールを導入して
  「6, 9, 12月にマイナーバージョンアップ, 3月にメジャーバージョンアップ」に誘導

  • JTCならではの儀式はメジャーバージョンアップのみで実施しつつ
    マイナーバージョンアップでも一通りの開発テストは実施
  • マイナーバージョンアップは機能追加 (多少buggyでもOK)、
    メジャーバージョンアップはバグ修正と性能向上　と役割を分けた

• そこからの、1ヶ月ごとに「これとこれを対応しよう」と決めて実装 ※4～12月のみ
  (実質的に期間1ヶ月のスプリント)

  • 機能追加要求の一元管理と優先順位付けは実施済みだったので、
    上から順に「今月できるのはここまで！」とやっていた
  • ちゃんと仕様定義～テスト環境でのテストまでやった (本番環境への移行は3ヶ月ごとのまま)
  • メジャーバージョンアップは儀式の準備が重たすぎて＋関連部門が多すぎて
    1～3月をスプリント風にするのは無理だった

• そこからの、機能追加1個ずつ実装

  • アイテムのサイズによってスプリント期間はバラつく (タイムボックスの導入はできず)
  • Swarmingと 「2～3週間で動くものを作る」には慣れていった

スプリントプランニング 関連

• 「次のバージョンの計画をレビューしよう！」とメンバーを集め、みんなで計画を立てることを普通にした
  (それまではリーダーが各人の担当範囲を決め、作業時間を見積り、担当者に「これで良い？」と聞いていた)

• 「UI検討に必要な情報だから」と、追加する機能の想定ユーザやシナリオを計画立ての打ち合わせで説明した
  → 慣れてきたメンバーは質問や異論反論を出すようになったので、そこで議論して、みんなでユーザーストーリーっぽいのを作った

• 「今月の残業時間レース」と題して、毎週金曜日に残業時間の多い順に3人の名前を公表して
  負荷の偏りをチームが認識するようにした ＆ 早く帰る意識付けを強くした
  → 「Aサン、レースでぶっちぎりじゃないですか、手伝いますよ」と言い出すメンバ続出

• その上で、今月の計画を立てるときに「洗い出した作業の担当者はデフォルト未定で！」とした。
  ＝「この人でないと無理」というものを明確にして指名する制度にした

スプリントレビュー 関連

• 対応案件を要求してきた営業/マーケ個人を呼んで。
  • step1) リリース直 前 に「お客様に説明するために！」と実機デモを見てもらう。
    ＝リリースする前にモノを見ることに慣れてもらう。
  • step2) テスト中に「こんな感じになります」とテスト機で画面や操作方法等を見てもらう。
    ＝未だ修正が利く段階でモノを見て意見を求められることに慣れてもらう。
  • step3) 仕様fix 前に「あなたの要求するコレと、別の人の要求との兼ね合いがありまして」と
    相談する体で、製品全体を見ることに慣れてもらう。
• 「新機能説明会」みたいな形でステークホルダー全員を集めて、リリースする部分に集中する場を設定。
  • はじめは「何が変わったか」をスライド等で説明→実機あるので使ってみてください。質問はいつでもどうぞ。の形。
  • はじめは誰も質問しないし実機も使わないと思うが、それでも「実機操作できる」を用意するの大事。
  • はじめはチームの中でも参加したがらない人がいるが「トラブったり質問されたりのときに手伝ってほしい！」と引っ張る
  • 慣れてくると、説明聞くより自分で操作したい人（「どーぞどーぞ！」）や、
    使い勝手をあーだこーだ言い出す人や、
    今後予定されている機能との兼ね合いを質問する人や、
    今後予定されている機能の優先順位を変えたいと言い出す人が出てくる。
    こうなると「チームメンバー総出じゃないとむり」と言い出しやすいのでチーム全員で参加。
    (リリース後だけれど、スプリントレビューでやりたいことに近づいていく)
• ↑の状態になったら、その会合をスプリントの内側に移動。
  (ぶっちゃけ、営業/マーケから見たら何も変わらない)

ふりかえり 関連

前提 (最初の1回だけ読んでください)

弊JTCでは

• 製品出荷後、プロジェクト終了時に「ふりかえり」の実施が義務づけられています。
  • 議事録を作成して管理職の審査承認が必要です。
  • その議事録はたまに部課長で回覧されるようです。
• モノをリリースした後なので、
  • (1) 下手をするとチームは解散しています。
  • (2) 次のプロジェクトは開始しています。
• (1)+(2)＝
  • スケジュール調整が難航して、たいていはリリースから1～数ヶ月後に実施されます。
  • ふりかえりのアウトプットを活かす機会が殆どありません。
    →参加者も何だかナァナァです。
• 規程にはどこにも書いていないのですが、何故かKPTであることが求められます。
  (KPT以外の議事録を提出すると「KPTに直して」と言われます⁴)
• KPTの議事録は何故かExcelで
  A列が[K][P][T]の選択肢、B列は自由テキスト欄、C列は発言者名という縦の表です⁵。

---

• 年1回の儀式化している「振り返り」は、チーム外の課題を吐き出す場にした

  • 部課長が議事録を見るらしい、という情報を添えることで
    「どうせ言っても何も変わらない」が「ひょっとしたら変わるかも」になる
    → 時間を使う意味を少しでも持たせる
  • Keepとか出そうとすると「事前に時間をくれ」と言われるが
    「日頃の恨み辛みを吐き出してください」なら、その場でポンポン意見が出てくる
    • ポンポン出てきた理由としては、以下があると考えています
      • 部課長に出す議事録は後日まとめる＋匿名化する約束
      • そもそも部課長が振り返りに興味を持つ素振りが皆無
        ＋今まで何を言っても変わらなかった＝逆に何を言っても大丈夫でしょという開き直り
      • ファシリテーターである私の日頃の行い
        (日常的にマネージメントへの不平不満を口にしたり
        ここに書いような、マネージメントの目を掻い潜る行動)
  • 腹に溜まったものを吐き出してスッキリ
  • 同じ不満を持ってたんだねと仲間意識向上
  • 「仕事は大変だったけれど、メンバーはまあ良いチームだったよ」と記憶を美化
    → そこまで行った姑息な小細工が「良い工夫」として記憶され、展開される可能性UP
  • (チーム内の「ふりかえり」が定着した後だと)
    普段の「ふりかえり」ではスコープ外としていた課題にフォーカスできる
  • テーマや技法が異なる「ふりかえり」を経験することで
    「ふりかえりってKPTじゃないんだ」「そもそもふりかえりって？」という気づきを促す
  • 後から「象、死んだ魚、嘔吐という技法がありまして。コレってほぼほぼそれです」と伝えると
    「ふりかえりって(以下略)」の気づきに繋がる

• チーム外の課題 (P) がたくさんで「部課長を説得する」「課長経由で他部門に交渉してもらう」という
  Tryが多い議事録を突きつけることで、すごく「やりにくい」現状を認知してもらう

  • 実際「P: 新社屋はホワイトボードすらなくて不便」「T: ホワイトボードを買ってもらう」は
    こちらが交渉する前に議事録を読んだ部長が対応してくれた

• 大きな市場バグ対応、綱渡りだったマイナーバージョンアップの後に
  「何が悪かったのか、みんなで議論しよう」とチームの打ち合わせを設定

  • まだ「ふりかえり」とは呼ばない。
  • テーマがあるふりかえり、Next actionを出すことに慣れてもらう。
  • 原因究明からの予防策 (＝next action) を出すのに向いた技法をアレコレ試す。
    KPTは使わない。KPTじゃないことに慣れてもらう。

• どんなときも1つくらい「まずった」点があるので、事実上「リリースしたらふりかえり」の定着

• 偶にうまくいったときも「うまくいったけど、じゃあ何が良かったのか も 議論しよう」と
  ふりかえりを設定 → 「リリースしたらふりかえり」100%実施

• 「リリースしたらふりかえり」をチームのルール化するときに、ようやく「ふりかえり」と呼ぶ。
  今までやってたのも「ふりかえり」だと伝え「ふりかえりって(以下略)」

  • 上の儀式を「振り返り」チームで実施しているのを「ふりかえり」と
    書き分けることで、アレとコレは別物だと認識してもらう。

• チームが「ふりかえり」に慣れたらKTPもやってみる。
  自分はファシリに専念し、儀式にならないよう誘導する。

  • 特にKeepを出すよう促してみる。今までのKPTはKPTじゃないんだと気づいてもらう。
  • すごーく些細なKeepでも褒めまくる。
  • dotシール等を使って「PやTは全部やらないといけない」の思い込みを打ち破る。
  • チームが大事と決めたTについては、ちゃんとnext actionが出るまでファシリする。
    → 次スプリント(の類い)でちゃんと実行する。ように誘導・準備する。
    改善ループが回るまでがお仕事。

デイリースクラム 関連

• (チーム全員で状況を共有することができていなければ)
  JTCあるあるの「日報」「週報」を理由にして、チームメンバから「進捗と課題」をメールで出してもらう。
  チームメンバ全員が見える形で出してもらうのが大事。
  • 全員で状況を共有することに慣れる
  • 課題があったら「A君のそれ、B君が詳しいからフォローお願い」的な反応をする (全員が見える形で)。
  • 進捗で気になることがあれば、全員が見える形で、反応をする。
  • ネガティブなことだけでなく、ポジティブなものにも反応する。
  • メンバが気軽に反応するようになるまで、毎日必ず何かに反応する。
  • メールが出てこない人は、対面で、直接、メール出してもらうよう頼む。
• 状況を全員で共有することに慣れたら「毎日メールするの面倒じゃない？」と、いわゆる「朝会」に持ち込む。
  • 朝会がはじめて＋進捗報告を共有するJIRA等のツールを使っていない場合は、取り敢えず口頭報告のみでOK。
• 朝会はあるけど口頭報告のみで、昨日との差分がわからん！とチーム全員が体験したら、カンバン等の何らかのツールを導入。
  • まずは「見える化」に慣れるのが目的。なので、TODO、DOING、DONEだけのカンバン1つでOK。
    ダッシュボード的に一度にアレコレ持ち込まない。
  • 「なんかコレずっとDOINGだね」みたいなツッコミがチームから上がってきたら、それに向いたグラフやら何やらを導入していく。
• はじめは「別件が」を許容する。
  • 全員が参加しやすい時間に変更する、を何度も繰り返すと「あ、全員出てほしいんだな」と伝わる。
  • 参加できなかった人は、同日別のタイミングでみんなを集めて報告してもらう。
    (その別枠に参加できなかった人には、さらに別のタイミングで報告してもらう)
    別件入れると面倒なことになる、と思ってくれると予定調整してくれる。
• 朝会にみんなが揃って進捗報告するのに慣れたら、単純な報告(ボード等を見ればわかること)ではなく
  課題共有やノウハウ共有等に主眼を切り替える。同時にタイムボックスを設定する。
  (実質デイリースクラム化)

ペア/モブ　プロ/ワーク 関連

• ピアレビューの打ち合わせで「いま直しちゃいましょう！」とモブワークに雪崩れ込む。

• 「今月の残業時間レース」(上述) で分担するのに慣れた後
  経験の浅いメンバのフォローと称して「慣れるまで一緒に作業しよう！」とペアワークに持ち込む。
  (例えば、初めて画面設計するA君が作業を始めると宣言したときに、
  　「既存の画面設計書がどういう構成になっているとか、設計方針とかポイントとかがわからないだろうから
  　　その辺説明したり、作業順とか教えてあげる形で、
  　　大雑把なところができるまで一緒に進めよう！」みたいに)

• 同じく分担するのに慣れた後
  「同じモノを二つに分けるのって難しくない？二人で作りながらレビューしてみたら？」とペアワークに持ち込む。
  　(ピアレビューの直しをモブワークでやるのに慣れていたほうが良い)

• 1つのバグ対応を「ちょっと面倒そうだから」と二人以上にアサインする。
  バグの原因調査を二人がかりでやると、どう直すという設計部分や修正確認も二人がかりでやる流れになりやすい。

スクラム導入

上記の小手先をいくつも重ねた結果
「アジャイル/スクラムってこうなんですけれど
　......今までやってたことと変わんないですよね！ね！」
と押し切れるようになったら
いよいよ呼び方を変えて「スクラムチーム」を名乗りましょう。

変更来歴

取り敢えず、現状思い出せたものを書き連ねました。
わかりにくいところは質問してください。
何か思いついたら書き足します。

改善箇所は以下に記録していこうかなと...。

• 初版 (2023/01/19)
• ふりかえりの「恨み辛みなら出てくる」ところに補足を追加 (2023/01/23)

1. Japan Traditional Company: この文脈では頑なにアジャイルな諸々を拒む文化・風潮・規程等が存在する会社のこと。 ↩

2. プロジェクトがうまくいく保証なんて, どうやったって無理だろうという話はおいておく。 ↩

3. それ本当にウォーターフォール？という話もおいておく。RSGT2023のTommyさんの発表を参照のこと。 ↩

4. 意味がわからない？ 私も意味がわかりません。 ↩

5. それはもはやKPTではないのでは...と思ったあなたとはお友達になれる気がします。 ↩