マインドセットに至るまでの話

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

「チケット駆動開発がまわりはじめるまでの取り組み」にて、「私は、このようなマインドセットです」とは話しました。発表には含めなかった、「何故そのマインドセットに至っているのか」といういう部分を前職のお話と絡めてテキスト化しました。

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

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

いろいろあり ISP の社員として働くことになり、配属となった部門で「チケット駆動開発」に出会ったというだけで、「自分の持っている技術を使い期待されている結果を出す」ということができるようになったわけではありません。

「チケットを分解する」と言われてもよくわかっていません。一つのチケットで何十時間も作業したり、チケット化せずに作業を進めたり、なんとなく他の人に言われた通りにチケットを分割してみるといような考えなしな感じで漫然と働いていました。上司は2,3ヶ月で完了するだろうと考え割り振ったサービスのリプレイスも半年ほど掛かり、最後は「いつまでやっているつもりだ」と尻を叩かれリプレイスをやり抜くというような散々な結果でした。

いままで働いていた会社とは異なりそう簡単にはクビになりませんが、半期ごとの評価はもちろんよくはありませんでした。クビになっていないだけで、状況はここより以前にいたところと全く変わっていません。「自分の持っている技術を使い期待されている結果を出す」ことができなくても、クビにはならないが、もちろん評価は低いという状況でした。

今までは評価が付いた時点でクビでしたが、ここでは評価が付いてもクビにはならないというところに挽回のチャンスがありました。

2014年下期の低い評価が返ってきた2015年4月頃には、既存の認証基盤を Haskell で書かれた内製の認証基盤にリプレイスしていくという話が進んでおり、サーバーインフラの構築や監視を私が担当するということが決まりました。

自分の現状をなんとかしていきたいという思いから、まずはチームメンバーがチケットをベースにどのように動いているのかを真似ながら作業を進めていくことにしました。あれもこれも一つのチケットの中で進めない、一つのチケットでは一つのことだけに集中する、チケットを進めていく中でわかったこと決まったことなどは都度チケットにコメントとして追記していっているということがわかりました。自分が理解したとを自分なりに考え見様見真似でチケット駆動し、サーバーインフラの構築や監視をやり抜いたところ、 2015年度上期の評価は、2014年度下期の評価に比べて上がっていました。

それまでは上司から「いま何をやっているのか」というような質問を受けることがほとんどでしたが、見様見真似でチケット駆動しはじめてからは、「チケット番号いくつの件、こんなことがコメントされているけれど、どんな状況」と質問されたり、チケットに直接コメントがあったりとコミュニケーションの変化を感じました。「何を」「どのように」「どこまで出来ているのか」チケットを通してオープンにすることで、非同期にコミュニケーションをとることが可能になるのだなという気付きを得たことによって、チケット駆動が自分の中で腹落ちした瞬間でした。

2015年10月からは、2年半ほど掛けて老朽化したメールサービスのコンポーネントを運用まわりの仕組みから整備し直しリプレイスしていくことを経験しました。この経験が、自ら課題を見付け、そのためにやっていくことをチケットとして積み上げ解決していき、結果を出していくというプロセスを自分の中に作り上げています。最終的な結果を出すのに何年も掛かる大きな仕事というものを小さな単位にバラし、少しずつ片付けていくということも、このタイミングで学びました。

2016年4月に最初のメールサービスのコンポーネントをリプレイスしたとき、はじめて「自分なりに困難をチケットで分解していきながらリプレイスという結果を出すことができた」と手応えを感じました。ここが自分のブレイクスルーだったなということをハッキリと覚えています。 2015年度下期からは露骨に評価とお賃金が上がり続けました。

2017年からは新しいサービスのサーバーインフラを整備したり、運用部門から受け入れた人をオンボーディングしたり、新卒研修を主導したりと、入社当時の自分では考えられなかったようなことをやるようになり、自身の成長を感じました。

2018年11月に自身が主導している業務がほぼ待ちの状態になったので、次に進めようと考えていた業務の上司に相談したところ、「すでに2人アサインして動いもらっているストレージ移行の業務を手伝ってもらえないか」と言われ、「わかりました」と返事をしてこの件に着手し、徹底的にタスクをバラしていってストレージ移行を軌道に乗せたことが、私のここでの最後の仕事になりました。燃え尽きたお話はまた別の機会にできたらと思います。

「ストレージ移行」の現状を確認するためにすでにあるチケットを眺めてみることにしました。「ストレージを移行する」というようなゴールが説明に書かれた親チケットに子チケットが数個ぶら下がっていて、どうやら半年以上前から動きはじめているというような情報は得ることができました。チケットだけでは状況が掴めなかったので、この件を主導している担当者にお話しを聞いてみると「手伝ってもらうための人員を外注していて来週から来る」「手伝ってもらう内容はまだ決まっていない」「ストレージの移行は来年1月までの完了を予定している」という情報が出てきました。

上司から「手伝ってもらえないか」と言われたのが木曜日の昼前で、担当者にヒアリングしたのが昼過ぎ、私は金曜日に有給を入れていて、来週の月曜日から外注の方々が来るという切羽詰っている状況であることを理解しました。やることの全体像や規模感が全然見えないので、担当者に「午後から、やることの全体像と規模感をチケットで見えるようにしていきましょう」と伝え、ゴールの認識合わせ、やっていかなければならないタスクをチケットに洗い出していくことにしました。

「ストレージ移行」は、ユーザー向け、業務システム用に動いている仮想サーバーのディスク、仮想サーバーに提供している NFS 領域、ユーザーに提供しているサービスのデータを保存しているストレージを新たなストレージに移行していくという内容であることがわかりました。

午後から担当者と4時間くらい話し合い、その日の終わりには、その時点で 1700くらいのタスクがありそうだということが見えてきました。担当者とアサインされていたもう一人だけでなく、上司も含めたチーム全員で取り組まなければならない業務であることも見えてきました。

チームでは毎日、朝のスタンドアップミーティングが15分行われており、次の週の月曜日に「ストレージ移行」の全体像と規模感をチームメンバーに共有し、ようやくどういった状況であるかということの認識を合わせることができました。そこから二週間ど掛け「ストレージ移行」について、上司を含めチームメンバーの協力が必要なタスクをチケットをベースに調整していきました。この時点で 2500 くらいのタスクになっていた記憶があります。

私は、2019年1月半ばが最終出社だったので、その後どうなったかはわかりません。

ただ、ゴールを明文化し、全体像・規模感を見通し、「誰が」「どこまで」「何を」するのかの明確化し、チームで同じゴールを目指して進めていくということに対して、チケット駆動開発が非常に強力なツールであることを最後に改めて実感しました。