はじめに
この記事は、NTTコムウェア Advent Calendar 2021 3日目の記事です。
本記事では、チームにアジャイル開発のプラクティスを導入し、**「チームにどんな"変化"をもたらしたか」**の体験談をまとめます。
前職のエピソードとなりますが、いずれも自身の描く「リーダー像」をアップデートする転機となったチームです。3チーム×3つのプラクティスを紹介しますので、プラクティスがチームにもたらす**「気づき」が、チームに「変化」を与え、「成長」の原動力になっていく**ところをお伝えできれば幸いです。
Turning Points
どんなリーダーとしてチームに関わろうか考えていた時、著書『アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント』に出会いました。
当時は「アジャイルの考え方はまだしっくりこないけど、このプラクティスは取り入れたら面白そう！」ぐらいの理解でしたが、キーワードを拾い、アジャイル開発のプラクティスを調べては、課題を解決すべくチームで「実験」をしていました。
※いずれのエピソードも、ウォーターフォール型でのWebアプリケーション開発です
EP1. リーダーは突然に
新卒2年目の春、「やりたいことを見つけた！」と目を輝かせたリーダーがチームを去りました。ゆくゆくは挑戦してみたいと思っていたけれど… **リーダーは突然に、私が！？**という、期待少し・不安ほとんどの急発進でした。
メンバー2名は、サービス立ち上げ時から開発に関わっており、テクニカルスキルに関しても折り紙付きと言われていました。「この子がリーダー？」「進捗管理とかできるんですか？」「アプリの中身全然わかってないですよね？」と、ありがたいことにノーオブラートで不安をぶつけてくれました。
どうチームを動かすか毎晩頭を悩ませた結果、リーダー就任時の挨拶は「正直に言います、みなさんを引っ張ることはできないです。ですが、メンバー全員が動き続けられるように"流れ"を整えていきたいと思ってます。このチームで走り抜きたいです、どうか力を貸してください！」でした。
(小話：この挨拶、付箋紙に書いてあって、今でも私のノートに残ってます)
**かんばん** - 情報の見える化と交通整理
試したこと：
- TODO/TODAY/DOING/DONE のレーンがあるかんばんを導入した
- → TODO： WBSを基に切った未着手のタスク、期日が近いものから順にレーンに配置
- → その週に完了させるタスクは、タスクの期日で判別
- → TODAY： 今日着手する予定のタスク、帰るときにここのレーンは空の状態を目指す
- → DOING： 進行中のタスク、メンバーにつき1つ以上置かない
- → DONE： 完了したタスク
- 週末に"TODO"をメンバー全員で見返す時間を設けた
- → タスクに抜け漏れはないか？
- → 追加タスクの着手日は決まっているか？
- → 心配事や気になることはないか？
- 客先調整や仕様変更に伴い、タスクが追加になった場合は、メンバーに共有した後に優先順位付けをした
チームの変化：
- どこにタスクの漏れがあるのかわからない 【解決】
- メンバーが今の動き・次の動きがわからない 【解決】
- タスクのステータスがわからない 【解決】
- かんばんに情報が集まり、かんばんを中心に話をするようになった
- 依存関係のあるタスクを意識して、優先順位を判断できるようになった
- プロジェクト遂行にどのようなタスクが必要か学習することができた
**デイリースクラム (通称：朝会/夕会)** - どうやってタスクを完了させるか
試したこと：
- 時間は15分×2回/日 出社直後の朝会と、定時1時間前の夕会
- かんばんを大きいモニターに映し、立って集まる
- 質問は「今週のタスクは達成できそうか？」の1つのみ
- → 話が脱線したら、お互いに↑の質問を投げかける
- かんばんの操作
- → 朝： "TODAY"に残っている前日のタスクの残件を共有、担当者を決める
- → 朝： "TODO"の中から着手するタスクを"TODAY"に移動し、担当者を決める
- → 夕： "TODAY"に残っているタスクの状況を共有する
- 朝会の後は、ちょっとした雑談をしてからタスクに取り掛かる
チームの変化：
- メンバー間で連携するタスクの認識を合わせたい 【解決】
- スケジュールに余裕があるのか、遅れる可能性があるのか、認識を合わせたい 【解決】
- 質問を決めているので、会議が脱線して長引くことが減った
- 残っているタスクに目を向けて全員に課題が共有されるので、朝会/夕会以外でも相談もしやすくなった
**ペアプロ** - 共有知を増やす
EP2. まさかの絶対王政
「EP1. リーダーは突然に」から5年程経験を重ねたある日、若手3人のメンバーと共に、納期まで3ヶ月の開発案件を受け持ちました。それまで「メンバーが自走できる・チームで解決する土壌をつくろう」と、自身のリーダー像を育ててきたのにも関わらず、まさかの絶対王政を敷いたのでした。先回りして築く要塞のような計画、全てを知り尽くさんとする中央集権型のレビュー、双方向性のない報告するだけの会議… 納期に間に合ったものの、メンバーはかなり疲弊する結果となりました。
ふりかえりでは、メンバーから忌憚のない意見が多数上がり、次の「EP3. メンバーが走っていく背中」に繋がる気づきが得られました。
後に、スクラム関連の書籍を読んでわかりましたが、このチームは多くのアンチパターンを踏み抜いていました。身をもって味わったマイナス効果のうち、ふりかえりでも議論された3つを"しくじりプラクティス"として挙げます。
**かんばん** - 終わりが見えないタスクの山
試したこと：
- TODO/DOING/DONE のレーンがあるかんばんを導入した
- → TODO： 要件定義～リリースまでの全タスク
- → プロジェクト開始時にWBSに沿ってタスクを追加、担当者割り振り済み
- → DOING： 進行中のタスク、メンバーにつき1つ以上置かない
- → DONE： 完了したタスク
- かんばんを中心に朝会を実施した
- → メンバー1人ずつ「完了したこと」「担当タスクの状況」「問題点」を共有
- → リーダーからこのタスクをやってください、と指示を出した
チームの変化：
- プロジェクト完了に必要なタスクを洗い出したい 【☠】
- → どこまで完了すれば遅延なく達成できるかの基準が見えず、ひたすら数多くこなそうとして闇雲に残業した
- 部分的なタスクでなく、タスクの関連性を意識できるようにしたい 【☠】
- → 先にタスクの関連性が示されているため、なぜこのタスクをやるのか？を考える意識が希薄になった
- かんばんは開発の中心として活用するのではなく、報告ボードと化した
**TODOリスト** - 失われたプロセス検討の機会
試したこと：
- かんばん上のタスク説明欄に、リーダーがTODOリストを記載した
- → 1項目あたり1～2時間ぐらいの作業量
- → タスクのINPUTとなる情報と、OUTPUTされる成果物を明記した
- チケットを担当するメンバーは、TODOリストを確認し、着手までに疑問点を相談するように周知した
- 朝会はTODOリストを基にどこまで進んでいるかを詳細に共有した
チームの変化：
- 完了までのプロセスを明確にし、どこまで進んでいるかを管理したい 【☠】
- → 朝会の時間は細かい報告に費やされ、時間も長くなった
- → ほかのやり方の提案が生まれなくなった
- 次は自身でプロセスを見出し、タスクを任せられるようにしたい 【☠】
- → プロセスを検討する機会を奪っているため、プロセスを考える習慣に繋がらなかった
**機能ごとのタスク分担** - となりのメンバー何やってるの？
試したこと：
- 開発する機能が複数あり、プロジェクト開始前に機能に対して専任のメンバーを決めて発表した
- 各機能に対する改修内容の説明は、リーダー⇔専任メンバー1名で実施した
- 機能に関する質問・相談はリーダーのみが受け付けた
チームの変化：
- 現行仕様やソースの把握にかかる時間を短縮したい 【解決】
- → プロジェクト開始前に、自身が担当する機能を重点的に調べる時間が確保できた
- コミュニケーションパスを少なくしたい 【☠】
- → 全体に共有されるべき情報が個人やり取りになってしまった
- → 同じ空間で仕事をしているが、隣のメンバーが何をやっているか互いにわからない
- → 進捗の遅れをカバーしようとしても、立ち上がりに時間を要する
- 複数機能を完成させ、プロジェクトとして完了させる意識が希薄になった
EP3. メンバーが走っていく背中
「EP2. まさかの絶対王政」は前向きなふりかえりと共に終わりを迎え、「自律したチームになろう」をTryに掲げて再スタートを切りました。リーダー1名、メンバー2名(継続)の一回り小さなチームです。
コミュニケーションパスが絞られたことが効を奏したのか、対話を中心にチームに一体感が生まれました。また、昨今の新型コロナウィルス対策の影響もあり、出勤/リモートのハイブリット勤務となったのも、様々な工夫を生み出すきっかけになったと感じています。
私は、メンバーを支援すべく、再び「アジャイル開発」や「スクラム」、「サーバントリーダー」をキーワードに、チーム改善のアイディアを探し、小さな実験を繰り返しました。
最終的に、このチームは「改修要求の真意は何か？」「ユーザーはどうこの機能を使うのか？」「何を解決したいのか？」「よりよい提案ができるのではないか？」を日々言葉に出して、議論できるようなチームになっていたのです。「私が先に走って引っ張るからついてきて！」を脱却し、「メンバーが走っていく背中」が見えたチームでした。
**かんばん** - 状況がわかるだけでなく、行動につながる"見える化"
試したこと：
- 未着手/今週着手/処理中/処理済/完了 のレーンがあるかんばんを導入した
- → 未着手： WBSを基に切った全タスク、期日が近いものから順にレーンに配置
- → 今週中： その週に完了するタスク
- → 週末に、全体の計画に対して翌週に完了すべきタスクを"今週中"に移動(リーダー)
- → 翌週のタスクが、プロジェクトのどの工程で、どのような目的を持つかを説明(リーダー)
- → 要求の背景、タスクの関連性、想定されるリスク、優先順位をメンバーに説明(リーダー)
- → "今週中"にあるタスクが全て達成できそうか話し合う(メンバー⇔リーダー)
- → 話し合い後は、タスクは"今週中"のレーンに着手する順に並んでいる
- → "今週中"のタスクに対し、TODOリストを作成して翌週を迎える(メンバー)
- → 朝会で、その日着手するタスクをメンバー自身で選び、TODOリストの内容を共有する
- → 朝会の最後に"今週中"のタスクが全て完了できそうか問いかる
- → 処理中： 進行中のタスク、メンバーにつき1つ以上置かない
- → 処理済： タスク内のTODOリストがすべてチェック済みのタスク
- → 完了： チームで完了したと合意したタスク
- → 朝会の冒頭で、前日に"処理済み"になったタスクを共有する
- → チームで完了したと合意したら"完了"レーンに移す
- → 残件がある場合は、朝会の後に別タスク追加 or TODOリストに項目追加
チームの変化：
- 次に何をすればいいのか、リーダーに指示を仰がなくてもわかるようにしたい 【解決】
- → メンバー自ら次の行動を判断・実行できるようになった
- 全体の計画のうち、どこの位置まで達しているか明確にしたい 【解決】
- 担当者に聞かないとタスクの状況がわからない 【解決】
- → 誰が何をしているのかがかんばんを見れば明確なので、不要な会議・状況説明のため会話が削減できた
- 全体の計画に対する状況を考えるのは週末と決め、それ以外の日は"今週中"をどう完了させるかに集中できるようになった
- 隣同士のタスクだけでなく、全体の計画の流れを踏まえてタスクを進めるようになり、発見したリスクをメンバーから発信できるようになった
**Web会議ツール** - 目の前にいないからこそ生まれる会話
試したこと：
- Web会議ツールでの画面共有
- → デュアルディスプレイ・トリプルディスプレイで共有画面を常に表示する
- ホワイトボードツールでの説明
- 常時接続・騒音が入らない限りはマイクも常時ON
- 集中したいときは「集中します！」宣言
- ↑それ以外は、ためらわずに話しかける
- ↑即回答難しいときは、次話すタイミングを決めて作業に戻る
チームの変化：
- ドキュメントやソースを中心に集まりながら検討したい 【解決】
- → 「今(共有してる)画面見れます？」の一言で話が開始できるため、メンバー間のやり取りのリズムが良くなった
- → ソースなどの細かい内容も、自身の環境で見やすい距離で確認できストレス軽減
- 相手の状況を伺って聞きたいことがすぐ聞けなかった 【解決】
- → 目の前にいないが故に空気を読めなくなるので、逆に話しかけやすくなった
- 他のメンバーが作業してる画面を見て"進め方"の良いところを発見し、チーム全員で取り入れられた
- 程よい生活音をきっかけに雑談が生じ、会話しやすい雰囲気が生じた
- ホワイトボードツールはデータ化しやすく、さっとイメージ共有した絵をチケットやWikiに保存するハードルが下がった(従来の写真を撮る→転送する→保存するはかなり手間)
**2時間スプリント** - こっそり仕掛けた小さなPDCAサイクル
試したこと：
- 1日を「午前/午後1/午後2」の3分割にした"タイムボックス"を意識して声をかける(リーダー)
- → 「さぁ、○時(約2時間後)までにどこ目指しましょうか？」(計画/実行)
- → 目標を各自宣言して作業開始・集中
- → 「進み具合どうですか？困ってることありますか？」(検査/情報共有)
- → 「よかったことある？」「改善できるかな？」(ふりかえり/改善)
- → 次のタイムボックスで作業開始前に改善内容をリマインド
- 新たに生じたタスクは、次の計画タイミングまでにかんばんに追加する
※メンバーにこうやってやります！と宣言することなく、定期的な問いかけでリズムをつくることを意識
チームの変化：
- リスクに早く気づいて軌道修正したい 【解決】
- → 形式ばった"進捗報告"ではないため、対話の中から"進捗"に関わる重要な情報が引き出せるようになった
- → どう軌道修正するかを"改善"として問いかけるので、アイディアが出やすくなった
- 自分のタスクに対する作業見積の精度を向上させたい 【解決】
- タイムボックスをオーバーする → 何か詰まっている？と見直すきっかけになった
- 1日だとぼやけていたゴールが明確になり、集中できるようになった
- 目標を宣言 → 達成！は気持ちが良い、明るくなった
- メンバー間で「困ってる？」や「助けて！」が交わされるようになった
おわりに
「EP3. メンバーが走っていく背中」の半年後、私は初めてスクラム開発に参画し、スクラムチームの立ち上げ期を、開発者の1人として経験しました。2021年10月には現職のNTTコムウェアに移り、上長からの「スクラムマスターをやってみないか？」の一言に二つ返事で飛び乗り、スクラムマスターとして日々チームと向き合っています。
開発者とスクラムマスターのロールを経験しましたが、「アジャイル開発のプラクティスを部分的にチームに導入する」のと、「スクラム開発を実践する」のとでは大違いでした。アジャイル開発の考え方、スクラムの理念、真のリーダー… これからも現場で体感しながら考えたい事柄で溢れています。
最後に、これまで苦楽を共にしたチームメンバーのみなさんに敬意と感謝の意を表し、締めくくりとさせていただきます。