Dec 23, 2020
#ssmjp Advent Calendar 2020 23日目の記事です。
お話する時間は無かったので、 「チケット駆動開発がまわりはじめるまでの取り組み」では、 「誰が」「何をするか」「何をしているか」「どこまで出来ているか」が 少しずつチケットとして見えるようになってきたとだけ書きました。
今回は、チケット駆動開発を使い新たなメンバーをチームに受け入れたお話について書きました。 書いていると結構なボリュームになったので、前後編に分けることにしました。 前半は、人を受け入れることになったきっかけ、人を受け入れるために自分が何を考えたのかについて書きました。 後半では、考えたことに従い、どのように行動していき、受け入れた結果がどうであったかについて書いています。
チケット駆動開発がまわりはじめるまでの取り組み
https://speakerdeck.com/zinrai/okr-tidd-case
まずは、私の考えや S さんのことをヒアリングするためのミーティイングを実施しました。
自分の決めごと、これから取り組んでもらいたいと考えているグ具体的な業務内容を S さんに共有し、認識を合わせ、予定していた構成管理のレイヤーの下から積み上げていくことに決まりました。 具体的な業務内容は、チケット化したものをベースにそれぞれの取り組んでもらいたいことのゴールを説明しました。
「 チケット駆動開発をチームメンバーに展開する 前編 」 「 チケット駆動開発をチームメンバーに展開する 後編 」 にてチームメンバーに対して行ったチケット駆動開発のインプットを S さんにも行おうと考えていました。
「チケット駆動開発」で進めることになりますが、 Redmine や「チケット駆動開発」についてどうか聞いてみたところ、 前職にてアジャイルと Redmine を組み合わせでチケット駆動していたことがわかりました。 チームメンバーに対して行ったチケット駆動開発のインプットは、 S さんには行わず、 どのような運用ルールで Redmine を使いチケット駆動開発しているかのインプットのみ行いました。
権限は必要になったときに随時追加していけばよいという考えのもと、 S さんのアカウントに取り組んでもらう業務に最低限必要なリソースにアクセスするための権限を付与しました。
マネージャーから S さんが所属しているチームでの稼動が、 受け入れた日から 0 になるということはないと聞いていました。 S さんへのヒアリング時に週の2営業日をこちらのチームの稼動に割くことになると伝えられました。 それならば、週次で1時間、チケットをベースに状況を話し合うミーティングをまわしていきましょうと決めました。 ミーティングの中身は、チケットをベースに何の何処に着手しているのか、次にどういう動きを考えているのか、 そのほか思っていること、考えていることを話し合うという形をとることにしました。
「取り組む業務が決まったのであとはよろしく」はありえないと考えています。 ぐいぐい前のめりにチームメンバーとコミュニケーションを取れる人ばかりではありません。 話を聞くための時間は、週次のミーティング以外でも確保してもらって全く問題ないので、 気になることがあったら、いつでも私とテキスト、 口頭でコミュニケーションを取ってくださいと伝えました。
入ったばかりでは、誰が何を知っていて、 誰に何を聞けばよいのかということもわかりません。 チームメンバーのやっていることを掴めるまでは、 他のメンバーを巻き込まなければならない話は、 私に聞いてもらって全く問題ないと伝えました。
気になることをミーティング以外のタイミングで聞いてくれたり、時間を確保し話してくれました。 自分のスタンスを事前に伝えておいたことが、功を奏したように思います。
S さんは、アサインされ取り組む業務について、 どこまで見通せていて、ここは不確実な部分なので進めていくことによって確実になっていくはずだろうと、 マインドマップで要素を分解したものを見せてくれました。
自分の考えていることを何かしらの手段で相手に伝えるということは大事なスキルだと思っています。 私は、それを「チケット駆動開発」という形で表現しています。 手段は異なりますが、 S さんは私が大事だと思っていたことを地で行っていました。 今まで、こういったコミュニケーションをとってくる人がいなかったので、 認識の齟齬が少なく、とてもコミュニケーションがとりやすかったです。
S さんが、チケット駆動していた経験もあり、 チケットをベースにしたコミュニケーションで気になることはほぼありませんでした。
仕組みを構築し、関係者への共有、ドキュメンテーションまで一つ一つ確実に成果を出してくれました。 ドキュメントの内容が、構造化され、読みやすい作りになっており、 ドキュメンテーションが少ない職場を渡り歩いてきた身としては、 「ドキュメンの書き方が勉強になるなぁ」と思ったりしました。 いまの職場より以前のどこかで訓練したような形跡をドキュメントから感じました。 こういう書き方があるのだなと関心し、私はこういう書き方できていないなと思いました。
S さんを受け入れて半年後にはにチームの一員となりました。
Packer を使いクラウドサービスの仮想マシンイメージを管理することにより、 Terraform Configuration に記述する仮想マシンイメージの参照を自分達でコントールできるようになりました。
クラウドサービスにて、どのようなポリシーでローカルディスクを運用するのか決まりました。
Terraform の tfstate の管理をどうするか、 Terraform Configuration のリポジトリをどう管理するのかの運用ルールが決まりました。
Nomad UI, Consul UI 専用のサーバーを用意することで、 チームメンバーが Nomad, Consul の情報を参照できるようになりました。
メトリクス管理・監視の基盤はできましたが ( Promxy を使ったアーキテクチャ ) ダッシュボード環境が誰も手を付けられておらず整備できていませんでしたが、 S さんが取り組んでくれたことにより、 Grafana によるダッシュボード環境が運用まで含めて整備されました。
受け入れから半年ほど週次のミーティングを実施し、以降は月次のミーティングを4ヶ月ほど行い、 あとは私を含め、チームメンバーと適切にコミュニケーションをとっていけるだろうと判断し、終わりにしました。
週次、月次のミーティングは、チケット化し、そこに議事録を私が毎回書き出していました。 S さんの週次のミーティングの話しぶりから、私が議事録を書かなくても大丈夫だろうという印象を受けたので、 10ヶ月ほど実施したミーティングの後半は、議事録の作成お願いし、認識の齟齬がないかを確認する形に変更しました。 議事録のやり方を変更しても特に問題なくミーティングはまわり続けました。
マネージャーから「 S さんにお願いしたら、やり抜いてもらえそう」 という言葉がポロリと出てきたのを聞いて、 積み上げた成果がマネージャーにも伝わったことを確認できました。
今回、私が強い意思を持って人の受け入れを進めたこと、 S さんを受け入れた場合の結果でしかないため、 再現できるかと言われると難しいでしょうが、 一つの事例として、共有させていただきます。