TypeError:

チケット駆動開発をチームメンバーに展開する 後編

#ssmjp Advent Calendar 2020 15日目の記事です。

お話する時間は無かったので、 「チケット駆動開発がまわりはじめるまでの取り組み」では、 チケット駆動開発の導入にて取り組んだことについて、 「こんな流れで進めていきました」くらいで終わってしまいました。

それぞれの取り組みについて、どのように考え、 どう進めていったかについて書いていると結構なボリュームになりそうな気がしたため、 前後編に分けることにしました。 今日は、「チケット駆動開発」の導入のため取り組んだ後半の内容について書きました。

チケット駆動開発がまわりはじめるまでの取り組み

https://speakerdeck.com/zinrai/okr-tidd-case

Redmine の運用ルールの整備

「 なぜ「チケット駆動開発」を導入できそうと思ったのか 」にて、 タスク管理の運用ルールや目的が無いまま進めてしまい、 やらなくなるを繰り返しているという話をチームメンバーから聞きました。

Redmine にてチケットの担当者になったとして、 Redmine を使ったことの無い人には、 何をどのように操作すればよいのかわかりません。 ( 私も Redmine を使いはじめた当初はそうでした。 )

Redmine に慣れ親しんでいたとしても、 いきなりチケットの担当者にされ、 チケットを進めてくださいと言われても、 「Redmine の使い方はわかりますが、 ステータスはどのように動かしていけばよいのですか」 などの疑問が絶対に出てくるはずです。

チームメンバーを巻き込んで、 Redmine を使ってチケット駆動開発していくためには、 一人チケット駆動開発のときには無かった、 運用ルールの明文化と共有が必要になってきます。

Redmine でチケットを割り当てられたら、どのように操作するのか、 Redmine でチケットを作成する場合は、 どの項目をどのように埋めてチケットを作成する必要があるのかなどの明文化からはじめました。

チケットを作るときに埋める項目が多いと負担になり、 チケットが作られない可能性があるため、 まずは埋めてもらう項目として、 トラッカー、題名、説明欄、ステータス、担当者、進捗率に絞って明文化しました。

Redmine の運用ルールの展開

チームメンバーを集め Redmine を使ったチケット駆動開発の運用ルールを共有しました。

トラッカー

「 チケット駆動開発をチームメンバーに展開する 前編 」 にて実施したハンズオンでのタスクの親子、親子孫を表現するトラッカーを設定していることを説明しました。

ステータス

どのステータスを利用し、 それぞれのスーテータスにどのような意味を持たせているかについて説明しました。

チケットの作成者と担当者

チケットの作成者と担当者で、 利用するステータスをどのように遷移させるのかについて説明しました。

説明欄

何が終わったらチケットをクローズできるのかの条件を書いてくださいと説明しました。

進捗率

進捗率をこまめに動かしてもらうようなことはしない、 チケットをクローズするときに 100 にしてくださいと説明しました。

自身の業務をチケット化することに慣れる

「 なぜ「チケット駆動開発」を導入しようと思ったのか 」 のような現状をチケット駆動開発を使いなんとかしていきたいと考えており、 「誰が何をやっているのか、やろうとしているのかチケットによって見えるようになり、 チケットをベースにメンバーが協力し合える環境になっていくことを目指していきたい」 ということをチケット駆動開発に参加したメンバーに伝えました。

はじめの一歩として、「自身の業務をチケット化することに慣れる」を目標に、 下記の3つを意識しながら、週次でチケット棚卸しの会議体を実施することを伝え合意を得ました。 ダラダラと続ける気はなく、3ヶ月を区切りに、 その時の状況を見て、次のアクションを決めたいと考えていることも伝えました。

  • 自身の業務をチケット化する習慣をつける
  • チケットと自身の行動を一致させる
  • 取り組むチケットに対するゴールを意識する

「 入門 組織開発 」 という本を読んだときに、「自分たちで解決策を決めていないことは実行される可能性が低い」という文言を目にして、 自分で試行錯誤しながら「チケット駆動開発」が腹落ちしていったよなということを思い出しました。

当事者が主体的に問題に気づき、自ら解決策を考えないと、その解決策が実際には実行されない

受け身で与えられた解決策は実行が伴わない

他者から言われただけでは人はなかなか動かない、自分で問題に気づき、自分で解決策を決めることが大切

参加者の考えていることを引き出し、 考えていることに対してどのようなアクションを取るのかを自分で宣言してもらう形をとることで、 受け身にならず、自分で問題に気付き、自分で解決策を決め、参加者が主体的に動いてもらえたらと考え、 下記の議題を用意し、週次の棚卸しを行っていました。

  • 3つの意識してもらいたいことを確認する
  • 自分ができていると考えることを話す
  • 自分が課題だと考えていることを話す
  • 自分の課題にどう対応するかのアクションを宣言する
  • 前回、宣言してもらったアクションを実施した結果どうであったか自分で評価する
  • 仕組みによる課題だと感じるところを話す
    • 私の作った仕組みによる「やりにくさ」もあるかもしれないと考え、参加者に話してもらう項目とした
  • この一週間で進めたチケットについて説明する
  • この一週間で進めたチケットを一つピックアップし、そのチケットに対しての自分の行動を説明する
    • 他の参加者の「チケット駆動開発」のヒントになるかもしれないので、考え方が個人に閉じてしまうのは勿体無いと考えた
  • この一週間で新たに積んだチケットについて説明してもらう
    • チケットを進めている中で、見えてなかったタスクの存在に気が付けたか、チケットを作成するという思考を挟めているかを観測する
  • 次の一週間で進めようと考えていることをチケットをベースに説明する

チケットをベースにチームメンバーと協力しながら作業を進める

区切りとしていた三ヶ月が近づいてきたので、 これからどうしていくかについて考えました。

3,4 名くらいからはじめようと考えていましたが、 結果的には6名に対して「チケット駆動開発」を推進する形となっていました。

前職にて、「チケット駆動開発」をインプットした方々が、 皆同じ期間で「チケット駆動開発」するようになっていたかと言われると、 そんなことは全くありません。

参加している6名全員の足並みが揃うことは期待していません。 参加メンバーの半分が、前向きに取り組んでいる状態であれば、 次のフェーズに移行しようと考えていました。

「チケット駆動開発」を推進する前から、 前向きは反応を見せてくれていた C さんは、 どのようにチケットを構成するとよいかなどの質問を頻繁にしていただき、 FAQ の作成が捗りました。

「チケット駆動開発」との相性が良さそうだなと感じていた B さんは、 「今まで数日くらいの見通ししか立っていなかった業務が、とても先まで見通せるようになりました」 「毎日、仕事のことを考えている状態でしたが、チケット化することによって忘れられるようになり、 自分の中での負荷が減りました」などの反応をいただきました。

新卒の D さんは、「 Github のチェックリストではプロセスが記録できなくて、 例えば、自分のコードを読んでいるときに、 あのとき自分が何を考えそうしたのかなどを辿れなくて不便だなと感じていました。 Redmine を使うようになってからは、自分がこれからやることに加えて、 プロセスを記録できるようになり良い仕組みだなと思って使っています」 という反応をいただきました。

接点が無かった E さんは、 「 zinrai さんも、かつてはタスクが管理するような思考や行動ができていたわけではないということを聞き、 これまでタスク管理的なことをしてこなかったが、自分も頑張ってみようと思っている」という反応と、 実際に前向きに「チケット駆動開発」に取り組んでいることが週次の棚卸しから見えました。

F さんは、なんだか忙しそうです。

A さんは、チケット駆動開発の推進前と状況は変わっていません。 試行錯誤の様子も観測できませんでした。

前向きにやっていけそうかなと感じていた参加者に対しては、効果があったのかなという感触を得ました。 一筋縄ではいかないと思っていた参加者は、思っていた通りの結果になったという感覚でした。 三ヶ月やってみて、どのような状況になっているかについてはマネージャーに報告しました。

マネージャーは「自分もイメージしていた結果になったと感じています。 感触の無い方々に対しては、これから一緒にどうしていくか考えていきましょう」 というような反応で、引き続き「チケット駆動開発」を進めていけそうだなと思いました。

6名の参加者うち4名は、 チケット駆動開発に前向きに取り組んでくれているので、 次のフェーズに移行することに決めました。

「自身の業務をチケット化することに慣れる」ということで、 三ヶ月「チケット駆動開発」に取り組んでもらいました。 業務が自分一人で完結することは少なく、チームという体になっているからには、 それぞれの専門性を生かし、協力しながら成果を出していくものであると考えています。 それが無いのであれば、チームという体である必要はないと思っています。 「チケットをベースにチームメンバーと協力しながら作業を進めていけるようになる」を 次の目標としてきたいという考をチームメンバーに共有し、認識を合わせました。

チームメンバーに依頼するチケットの作り方を明文化し、 チームメンバーに共有してから、前回と同様に議題を用意し、週次での棚卸しを行いました。

「自身の業務をチケット化することに慣れる」では、 ヒアリング形式で進めていたのですが、 時間が掛かり、自分への負担も大きかったのでやめ、 参加者に議題の内容を事前にテキスト化してもらう形をとることにしました。 私が聞き取ってテキスト化する間で意図しない変換が起きる可能性を排除でき、 齟齬なく会議体を運営できたなと個人的には思っています。

「自身の業務をチケット化することに慣れる」に三ヶ月取り組んでみて、 チケット化することは、ぼちぼち出来ているという感触でしたが、 チケットをクローズまで持っていくという部分が少し弱いなという印象がありました。 現状とこのフェーズでの目標から棚卸しの議題としては、 「チケットをクローズまで持っていく」「依頼した、依頼されたチケットの進める」 に注力するという形で、週次の棚卸しを行っていました。

週次の棚卸しの議題としては以下のようなことを行っていました。

  • 前回の棚卸し以降に取り組んだチケット
    • クローズしたもの
    • 着手しているもの
  • 次回の棚卸しまでに取り組む予定のチケット
  • 依頼した、依頼されたチケット
    • クローズしたもの
    • 着手しているもの
  • 思っていること、考えていること、困りごと