チケット駆動開発を使った人の受け入れ前編

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

お話する時間は無かったので、「チケット駆動開発がまわりはじめるまでの取り組み」では、「誰が」「何をするか」「何をしているか」「どこまで出来ているか」が少しずつチケットとして見えるようになってきたとだけ書きました。

今回は、チケット駆動開発を使い新たなメンバーをチームに受け入れたお話について書きました。書いていると結構なボリュームになったので、前後編に分けることにしました。前半は、人を受け入れることになったきっかけ、人を受け入れるために自分が何を考えたのかについて書いています。

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

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

きっかけ

チケット駆動開発をチームメンバーに展開する前編の区切りに差し掛かっていたタイミングでのある日のチームミーティングにて、マネージャーから「チームに人を受け入れる話が上がっている」という話を共有されました。

詳細を聞いてみると以下のようなことが聞き取れました。

マネージャーが集うミーティングにて、他チームのメンバーでスキルのミスマッチが起きていることを共有された
チームにハマっていないだけかもしれないため、他のチームでの活躍を模索してもらえないかと言われた
そうは言われても、忙しくて人を受け入れている余裕はない

入社してから、ここまで9ヶ月、どのタイミングを切り取っても「忙しい」を耳にしていました。人を受け入れることが難しい状況の解像度をもっと上げていかなければ、「忙しい」で思考停止している状態が続いていくのだろうなと感じました。

「チケット駆動開発」を使った人の受け入れ方の実績を作り、「忙しい」で思考停止して周りもそれに同調するような雰囲気を打開していきたいと考えました。

「チケット駆動開発」との出会いにて書いたように、自分自身、何年もくすぶっていましたが、縁や機会に恵まれここまできています。弊社の面接を突破してきた人が、スキルのミスマッチなどと言われ、くすぶっていて、それを打開するきっかけになりそうな場を用意してもらえないのはおかしいと考えました。

これまで縁や機会を作ってきてもらい助けれらた身として、今度は私が、誰かに縁や機会を提供する番になったのだと考え、行動しなければという使命感にかられました。

チームメンバーの「誰が」「何を」をやっているのか見えないことによって、「試しに ○○ さんのこれやってみてもったら」というようなコミュニケーションがチームに生まれないというところも、人を受け入れることが難しい要因の一つなのではないかと思っていました。

チケット駆動開発に対する自身の考え前編より、自分が取り組んでいることはもちろん記憶に留めておきたくないので、もちろん「チケット駆動開発」しています。自分が取り組まなければと考えていることも記憶に留めておきたくないので、全てチケット化していました。

「私は、取り組まなければと考えていることも全てチケットにしています。これらのチケットをネタにして、私が人を受け入れを主導します。」とマネージャーに宣言し、「チケット駆動開発」を使った人の受け入れがはじまりました。

( チームに受け入れた方は、以降 S さんと呼びます。 )

自身の決めごと

チームに人を受け入れることを主導していくにあたり、自分の中でどのように進めていくのかとうことを整理しました。

前評判はどうでもよい

このままやり続けるの辛いが原動力になり、私のように行動していく人ばかりではないと思います。チームの雰囲気に馴染めなかっただけかもしれないです。オンボーディングに失敗している可能性も考えられます。その評価を受けることになった要因などいくらでも思い付きます。

私は、仕事で Web アプリケーションを開発していたときは散々な評価でした。インフラエンジニアをやるようになってからは、なんとかやれているのでないかと思っています。

いまのチームにスキルがマッチしていないという評価が、受け入れ先でも同じ結果になるかどうかはわかりません。環境、やることが変われば評価も変わることがあるという体験があるため、受け入れた人がどうであったかを判断するのは、実際に一緒にやってみたときであると考えています。

立ち位置を確立できるような業務をやってもらう

ISP にいきつくまで、期待された成果が出せないために、チームの中で自分の立ち位置を確立することができずにクビになり続けていました。

ISP にいきついてからは、サービスのリプレイス、サービスのサーバーインフラを整備するなどの成果を出し、現職では、アプリケーションをコンテナで実行する基盤、メトリクスを管理・監視する基盤を整備するという成果を出し、この人ならば、こういったことを進めてくれるだろうというような立ち位置を確立できたのかなと思っています。

自身の体験から、必要だが誰も手を付けていない、必要だがやり抜かれていない業務を進めてもらい、「このことは、この人に聞くのが一番」というような立ち位置を提供できたらと考えました。

一つずつ確実に成果を積み上げていってもらう

チームに入ってきたばかりの段階では、何ができて、どういった成果を出していける人なのかわかりません。

一つ一つの取り組んでいくことに対して、検証、実装、ドキュメンテーション、情報共有までのサイクルを成果として積み上げることで、この人は、こういった成果を出していける人なのだということを印象付け、それがチームメンバーの信頼を得ていくことに繋がると考えました。

一つ一つの業務に対して目に見える成果を確実に積み上げてもらい、最終的にチームメンバーからの信頼を勝ち得て欲しいと思いました。

自律的に動けるようになるためのインプットを行う

サーバーの払出しは Terraform 、ミドルウェアのセットアップは Ansible 、アプリケーションの実行は Nomad といったように構成管理するレイヤーを分けた構成を私が整備しました。

それぞれの構成管理のレイヤーにて、手が付けられていないこと残っていました。下のレイヤーから、手が付けられていないことを一つ一つ解決していってもらうことにより、チームでどのようにサーバーをセットアップしたり、アプリケーションをデプロイしているのか理解し、さらにその先にある業務に対して、自律的に手を動かせるようになってもらえたらと考えました。

きっかけ、自分の考えから具体的にどう行動し、結果どうであったかは後半に続きます。

チケット駆動開発を使った人の受け入れ 前編