開発チームのBeforeとAfter 2020年〜2021年

はじめに

HitoHana中長期計画の実行初期段階、特に大きく改善を実感している部分に関する記事を書きたいと思います。
現在はマネジメント改善、システム基盤抜本改善、サービス開発の３軸で動いている開発チームですが「マネジメント改善」の部分の話です。
大きく改善を感じている点や、採用観点でチーム開発が刺さる層がいる（下心満載で）ということに気づいたため、このトピックを選択しました。
誤解がありそうなので前もって言っておくと、マネジメントの改善だけでチームがいい雰囲気になっているわけではなく、計画や実績が伴っているのでいい感じになってきているという注意点だけ、先に伝えさせていただきます。
マネージャーレイヤーの僕目線と、メンバーレイヤーの岡部さん目線で書いてみました。両者の違いを楽しみながら読んでいただきたいと思います。

前提

2020年初期のチーム組成時と、2021年初期のマネジメント改善後でどういう風に変わったのかを書きなぐります。
前提条件として記しておくと、僕たちは「リモートチーム」「少人数（６名）」「Railsのエンジニアチーム」という属性があります。

2020年初期のチーム組成しはじめ〜半年くらい（Before）

新原

開発チームが３名→１名になって半年ほど経った 2019年10月3日から、採用が進んでメンバーが少しずつ増えていきました。
この頃は、個々人でいい感じの仕事を進めていました。メンバーは僕に承認を取りに来て、僕が了承をするというスタイルで、個人対チームリーダーという構造ができていました。チームワークという感じはあまりなく、グループワークみたいな状態でした。
この頃の最大の問題点としてオンボーディングの難易度が高いというものがあり、数名のエンジニアが入ってきてはすぐに離脱してしまうということがありました。
技術的負債の量が計り知れなく先行きに対する不安からくる離脱であったり、全体を理解してから進めようとしたときの果てしなさにモチベーションを落としてしまった離脱であったりしました。
その中で残ってくれたメンバーが今のHitoHanaチームを作っているというのもありますが、マネジメント改善がされるまでは先程申し上げたとおりのグループワークをしていました。
と、いうのが改善前の状態です。

岡部

私は2019年11月にHitoHanaの開発チームに参加しました。この時点での私の状態は、予想以上のシステムの複雑さについていくのが精一杯で、全く余裕がないなぁといった感じでした。今思えば毎日消耗していましたね。
基本的にこのチームにおいて、質問やヘルプを出す事は良しとされるカルチャーだと捉えていましたが、頭でわかっていても中々言い出しづらかった事を覚えています。
まだ個々人で仕事をしているような空気感があった事と、それぞれに余裕がなかった事で、私も必要以上に消極的になっていました。
また、この時は参画したメンバーが次々に離脱してしまうのを見て、進んでは戻るを繰り返すような、ネガティブな印象を受けていたと思います。私は最初から離脱という選択肢は捨てていたのですが、悲しくなりました。
負債の解消などの話はありましたが、開発チームとしての大きな指針が固まっていなかった事も、そう思わせる要因だったように思います。

2021年初期のマネジメント改善後（After）

新原

マネジメント改善後ですが、とりあえず僕が楽しいです。
グループワークからチームワークとなり、メンバー同士が助け合い、生産性も少しずつ上っています。
コミュニケーションの頻度が増え、議論が活発となり、お互いがお互いのプルリクについて仕様のレビューもできるようになりつつあると思います。
「仲良しです！」という感じじゃないんですが、メンバーが意見を押し殺したりするような状態ではないし、失敗にビクビクするような状態でもないと思っています。
つらい状況でも残ってくれるようなメンバー同士だからなのかもしれないですが、僕はマネジメント改善として行ってきたことが（八木田さんが行ってくれたことが）大きい効果をもたらしたと信じております。
なので、他の開発チームでも役に立てば良いなと思いこのストーリーを書いていますし、具体的な活動を書き起こすことで、なぜ雰囲気がよいのかを伝えることができると思っております。

岡部

今はとにかくメンバーがやりとりしている印象です！ちょっと疑問に思ったら、すぐ話しかけてしまおうという思考になっています。（迷惑かもしれないですが。）参加メンバーがそれぞれ面白いバックグラウンドでエンジニアをやってきているので、エンジニア歴が浅い私には、非常に学びになっていますね。
意見も気軽に言える空気感に変わりました。失敗を責めるような雰囲気もなく、お互い自然にフォローしあっていると思いますし、そこから今後はどう改善するかという話になっているのが本当に良い状態だと感じています。チームとして進歩していると感じられていて、とても気持ち良いです。
私自身としては何より開発していて楽しいですね。あと新原さんも楽しそうです。

チームの改善のために実行したこと（たくさん）

中長期計画の提示

新原

マネジメント改善を含め、開発チームをどのようにしていくのかという中長期計画を八木田さんが作ってくれたおかげで、みんなの目線が揃ったと思います。
この状態はいつ、どういう方向性をもって解消していくのかというところが可視化されたことが大きいと思っています。
以前も技術的負債を解消していこうという話はしていましたが、技術負債のことについてのみ言及していたり、忙しくなったら途中で離散してしまったりしていました。
マネジメント改善、システム基盤改善、サービス開発の３つという形で、それぞれのおおざっぱなガントチャートと優先順位を決めて経営と合意を取った上でメンバーに共有していったことがとてもよかったと思っています。

岡部

これは私にとって非常にモチベーションを引き上げる要因になりました。「山を登っている事は理解しているが、これは何という山で何メートル級なの？毎日息切れしてるから不安だな。」という気持ちがどこかにありましたが、「これは磐梯山という山なんだ。頂上まではこれぐらいで着くんだな。」という事がわかった事で、山登りを楽しむ余裕が生まれました。
エンジニアとしても、この時点でこのスキルを身につけていれば貢献できそうだといったふうに、逆算する事ができるのでとてもありがたいです。

朝会の改善

新原

Beforeでも朝会をやっていましたが、全社としてやっていたスタイルを踏襲したので、毎朝「ビジョン・ミッションの読み上げ」「ユーザーレビューの読み上げ」「売上数字の読み上げ」「全体共有事項」という感じでやっていました。
スクラムで提唱されているような「やったこと」「やること」「困ってること」を拾い集めるようにしました。また、前途のスタイルだと僕も「あんまり意味ないよな〜」とか思いつつ実施していたので参加任意にしていました。スタイルを変更してからしばらくして参加必須にするように変更して、メンバー全員が参加するようになり、みんなの目線が揃い始めた感があります。

岡部

全社としてやっていたスタイルは別に嫌いではなかったのですが、ビジョンの浸透意外に何か効果があるかというと微妙だと感じていました。
「やったこと」「やること」「困ってること」を全員があげるのは、勿論マネジメント的には良いと思うのですが、メンバー間でも相互理解に繋がっていて良いと思っています。困っているメンバーを自身の引き出しで助けよう、そんなふうに思う機会になっているのではないでしょうか。結果的にマネジメントコストが下がっているんじゃないかなと感じています。

振り返り

新原

「まずはスクラムの基本イベントを回しましょう」というところから振り返りをちゃんとやるようにしました。
振り返りをやるのは簡単ですが、効果を出し続けるのが結構難しいと思っており、問題があればその場で報告してもらって、その場で解決したほうがいいよねというスタンスだったので意図的に開催しなかったところもありますが、今の所は効果が出続けています。
振り返りの頻度を適切に設定することや、振り返りの結果を業務に活かして改善していくことをメンバーに実感してもらうことが大事で、振り返りでみんなで決めたことはNext Actionsとして無駄にならないようにしています。
ボトムアップでの改善が進んでいることや、議論をすることで心理的安全性が上がっているように思えます。

岡部

開始当初はどういった効果があるのか不安でした。実際やっている中で感じる事は、毎回振り返りに対してNext Actionsを設定しているのがとても良いと思います。Next Actionsは絶対でなく、程よい粒度感で設定しているので、丁度良い努力目標になっており、今のモチベーションの高い状態だと効果が出やすいように感じています。実際にここから生まれた施策でチームの状態を改善できていると思います。（雑談部屋などはまさにここから生まれました。）

雑談部屋

新原

HitoHanaの開発チームは完全にリモートになっており、ちょっとした疑問があったときにSlackで質問したりとか、meetやzoomを使ってオンラインミーティングして会話するというスタイルになっていました。
振り返りの場で「みんなに相談しずらい！」みたいなことがでてきて、八木田さんがTandemに作った雑談部屋に常駐するようなTRYをはじめました。ここがきっかけで、口頭で疑問や問題をすぐに解決するというようなことが発生しまくるようになりました。
何かあったらすぐ話しかけるという、リアルで働いていたときは結構当たり前に行われていたコミュニケーションがリモートでも発生するようになりました。

岡部

八木田さんがTandemに作った雑談部屋ですが、はじめた頃はかなり頻繁に出入りしていました。バグ対応は全部雑談部屋にでやるとかも決めたりしていましたね。（私が軽口で常駐してくださいと言ったら、本当に常駐していただけたという背景もあります。）
とてもコミュニケーションが活発化され、以前にあった心理的障壁は完全に無くなったなと思っています。
現在では部屋に入る事を飛ばして、ダイレクトに話しかけるという感じにまでなっています。

夕会の導入

新原

朝会をやっていても、雑談部屋をやっていても、「困っていること」を相談しずらいみたいな雰囲気が読み取れた振り返り会のときに発案された夕会が発生しました。業務終了の１時間前に夕会をやって、その日に仕事していて困ったことを共有する会をはじめました。これも結構良くて、夕会をはじめたその日から、メンバーが行き詰って困ってることを教えてくれて、その場で解決するようになりました。業務終了１時間前というのが良くて、夕会で報告してその後すぐに解決できるというような形になったと思います。
もし、終了１０分前にすると「これは困ってるけど仕事終わりにしたいから明日報告すればいいや」という感じになってしまっていたんじゃないかなぁと思います。

岡部

人によっては手間に思ってしまうかもしれない夕会ですが、上記の使い方で非常に効果を発揮していると思います。また私の場合は、今日あまり進まなかったなぁというエンジニアにありがちな罪悪感を、その日のうちに告白するという形で使っています。こういった気持ちを抱えておくと、モチベーションを下げたり自分の箱に入ったりしてしまうので、非常に助かっています。

DX Criteria

新原

別途記事を作りたいと思っているところですが、半年前、マネジメント改善を進める前に八木田さんがDXCriteriaを実施してくれて数値を出してくれました。
マネジメント改善後の数値を図るために、こんどはチーム全員でDXCriteriaを実施しています。
数字がめちゃくちゃ改善していそうなのですが、今回伝えたいポイントは改善した数値ではなく、実施の方法です。
チームメンバー全員でDX Criteriaを実施することでメンバーの目線が揃い、議論が生まれ、チームとして目指すべき「よい方向」が揃ってきました。
参加したメンバーは「疲れたけど楽しかったです！」という形で、誰か一人が実施するのではなくてチームメンバー全員で実施することに価値がある取り組みだなと思いました。
結果の数値も大事だと思うし、実施の時間も結構かかるのでめちゃくちゃ大変ですけどね。
これからも定期的に開催していきたいと思っております！

岡部

チームの状態を俯瞰して見る事ができるので、とても意味があると感じています。こういった指標一つ一つが前述のようにモチベーションに繋がっていくと思います。
新原さんも書いてくださっていますが、議論をしながら客観的にチームの状態を知る事で、メンバーの目線が揃うことに貢献しています。
全員揃って長時間かけて実施するのはとても大変ですが、それだけの価値があります。

定期リリース→随時リリース

新原

以前は１スプリント＝１リリースとして、スプリントレビューをしてからリリースというワークフローにしていました。
このときはスプリントレビューで一つでも指摘事項があったときに他の全ての案件がリリースできなくなったりしていました。
定期リリースにしていた理由は２つあり、「リリース前テストの工数を削減したい」と「ビジネスサイドがチェックする日の予定を明けておく」でしたが、２つとも怪しい理由でした。
「リリース前テストの工数を削減したい」については、たしかに昔は手動でやっていたので時間がかかっていましたが今は自動化されています。従って理由がなくなっています。
「ビジネスサイドがチェックする日の予定を明けておく」については、スプリントレビューの指摘と修正を繰り返していると、大体毎日ビジネスサイドがリリース前のプロダクトをチェックしているような状態になっていました。こちらも理由自体無くなっているようなものだと思いました。

定期リリースから随時リリースに変更したことで、開発メンバーがビジネスサイドにリリース前確認を各自で取りに行くようになり、チーム外とのコミュニケーションが発生するようになりました。
また、git-flowからGithub Flowに変更したことで、コンフリクトの解消にかかる工数が減ったり、リリースできなくてハラハラするということが起こらなくなりました。
僕的にはとても良かったと思ってます。

岡部

Hitohanaのチームはメンバーによって週５日であったり週２日だったりと、稼働する日数がバラバラであったりします。なので定期リリースを行っていた時は、人によって、余裕を持ったリリースやビジネスサイドからの指摘への対応ができないという状態でした。随時リリースによってこれが解消できたのは、チーム特性的に非常に良かった事だと思います。
また定期リリース時は、リリース担当者が一人おり、全てのリリース案件を把握していた事がなかなか負担になっていました。現在は個々人に分散しており、とても良いと思います。
随時リリースにした事で、柔軟になったと感じています。

これから

これからもマネジメント改善としてできることは、やっていきたいと思っています。
何が一番効いたのかはわからないんですが、一つ一つの積み重ねがチームを運営する上で大事なんだなという実感をしました。
マネジメント改善後はまだ新メンバーが入っていないので、オンボーディングの課題がなくなっているかどうかは分かっていません。ただ、チームとして雰囲気が良い状態なのでオンボーディングに転んでも他のメンバーが助けやすい状況になっているんではないかと思います。朝会、夕会、雑談部屋などの仕組みもあり、良いメンバーが揃っています。
ここまで読んでいただきありがとうございます！
技術負債は多いが雰囲気がよいというレアなチームで働いてみたいと思えた方がいらっしゃいましたら、ぜひとも一度お話しましょう！

よろしくお願いいたします！