こんにちは、kdxu です。HERP でエンジニアをしています。

さて、自分を含めエンジニアが働く組織（多くの場合会社）には開発チームが存在する場合があります。この開発チームとは、エンジニア・デザイナー・マネージャーがチーム内外とやりとりをしつつ、コードを書いたりインフラを整備したりUX/UIをデザインしたりするところのことを指すことが多いのではないでしょうか。この記事を読んでいる方々のほとんどが開発チームに属していたりまたは接する機会があると思います。

HERP ではこの「開発チーム」についてある取り組みを行ったのでここで紹介します。その名前を国土強靭化基本計画と言います。ネーミングが気になるところですがそこはさておき、みなさんの業務の参考になったり、HERPの開発チームを面白いと思っていただけると幸いです。

きっかけ：いつまでも返済されない開発のチーム負債

開発チームは存在し続けていると（もしくは最初から）色々な問題を抱えがちです。責任の所在が曖昧な機能、ネグレクトされたリポジトリ、よくわからないまま approve しているプルリクエスト、スケールに耐えない設計、なかなか進まない新機能の機能策定など。

さて、みなさんはどのようにこれらの問題と向き合っていますか？同僚と話し合って解決したりしなかったり、または一人で抱え込んだりしていますか？もしかしたら、気づかないふりをしているかもしれません。

もちろん、HERPの開発チームでもそういったことがあります。特に『「こういうことが問題だよね」という会話は頻繁になされるけれども、日々の機能開発に追われて手をつけられない』、ということがよくありました。

例えるならば「家を建てているうちに工具がボロくなってきた（もしくは始めから使いにくい）けどなかなか直したり買い換える手間が取れない」という状況です。

ましてや我々はスタートアップなので、工具を直してばかりいると家が建てられず倒産してしまいます。

そしてスタートアップに限りませんが、合意をうまく形成できないまま工具の手直しに追われて期限内のタスクに取り組まずにいると、「君たちは何をごちゃごちゃやっているんだ！」と上層部に突然解雇通知を投げつけられることもあるかもしれません。

機能開発で忙しくて工具を直す時間がなかなか作れない、
でも工具を直さないといい家は建てられない――

そういった課題感が、HERPの開発チームが組織として大きくなる中で腫瘍のように膨らんできました。

そこで我々は思い切って普段の開発を1スプリント（4日間）、一旦止めてチーム全員で集まり、全てのコンポーネントの課題を出し、確実に解決に向かう時間を設けよう、という提案をしました。

「うまくいくかはわからないけど、やらないよりは良いだろう」程度の投機的なものでしたが、プロダクトオーナーと開発チームの人々は快く受け入れてくれ、協力してくれました。

開発の負債の返済で、合意形成がうまくなされずに実施されないというのもよくありますが、HERPには「やってみよう❗」というバリューがあるので、ここで大きく転ぶことはありませんでした。

我々、HERPの開発チームはこの催しを「国土強靭化基本計画※1」と名付けました。（※1 実在の国の取り組みの名前に由来しています）

負債返済計画としての「国土強靭化基本計画」

計画の概要

こんにちは、aikoです。HERP でエンジニアをしています。

「国土強靭化基本計画」は「開発を一度止めて、開発チーム全員で集まり、全てのコンポーネントの課題を出し解決に向ける」を実現するために、1スプリント（4日間）の開発を止めました。

この4日間で一体どういうことをしていたのか、どういう効果を得られたのか、みなさん気になるでしょう。

4日間の中で、以下のようなコンテンツを用意しました

• コンポーネントのプレゼン「ホワイトボード作戦」

• 課題洗い出しタイム

• 伸びしろの全体議論課題の優先順位付け

• 最終投票課題解決のためのアクション決め

HERPのコンポーネントの現状

その前にまずHERPにおいて開発の現状をざっくり説明させてもらいます。HERPの中では、コードがかなり細かく分けられています。一旦そのコード括りを「コンポーネント」と呼びましょう。

細かく分けられすぎた結果、コンポーネントの数がエンジニアの人数よりはるかに上まり（実施時点では>=29）、そして全貌を把握している人存在しない状況になってしまいました。

"ホワイトボード作戦"の実行！

開発全体やコンポーネント横断の改善をしようとしても、他のコンポーネントの詳細が知らない、関係者がわからないなど、コストがさらに跳ね上がります。その結果中長期的指定での改善やリファクタリングがしにくくなりました。

そのため、まず開発全員がざっくり全体像を把握できるように、コンポーネントを「一番詳しい人」に説明してもらう「ホワイトボード作戦」を実行しました！

ちなみにホワイトボード作戦は、プロダクションレディマイクロサービスの内容からインスピレーションを得ました。

優先度の高いコンポーネントの投票

さすがに数が多いので、事前に開発チームのみんなに優先度が高そうなコンポーネントを投票してもらい、上位10位をピックアップしました。

上位10個ではありますが、選びぬかれているだけありこれらのコンポーネントに内在する問題は多く、4日間の計画のうち約8割の時間をこれらのコンポーネントのプレゼンと議論に使うことになりました。

一番詳しい人によるコンポーネントプレゼンタイム

• なんのために何をするコンポーネント

• ほかのコンポーネントとの関係性（依存関係など）

• 設計思想、アーキテクチャ

• 細部の重要な部分

• 今後の展望

• 今一番困ってること、直面している課題

コンポーネントに一番詳しい人がを発表して、その後みんなでそのコンポーネントに対して自分が思ってる課題を出してもらいます。

コンポーネントの課題・伸びしろの全体議論

一通り説明を受け、みんなが他のコンポーネントへの理解がある程度深まりました。これでチームは全知全能です！

すべてを知ることができたのでコンポーネント横断やシステム全体など、よりスコープが大きい課題を出してもらいます。Notionにチケット化する形で起票してもらいました。なんと最終的には183個も課題が出ました！

課題の優先順位付け・最終投票

これらの課題の優先順位を並び替え、優先度が高い課題から、大まかな対応方針とマイルストーンを決めます。183も課題が出てきましたが、さすがに全てに取り組むことはできません。以下のようなプロセスで優先度をつけました。

• 重要度×緊急度マトリクスを使ったA,B,C,Dの重み付けをする

• リベンジタイムを設けて、「これは実は優先度Aじゃない？」というものを敗者復活させる

• Aの伸びしろにたいして、1人10票まで投票する

• 上位10を、アクションを取るべきものとして選抜

そして放置されないようにちゃんと各課題に対して、「ボール持つ人」を決めました。こういった責任の負債は一部のエンジニアだけが責任を持つということもありますが、HERPでは各エンジニアが1つずつ伸びしろに対して主体的に責任を負っていく形に運用していくことにしました。

国土強靭化基本計画"後"

kdxu です。ここから少し私のターンです。

さて、国土強靭化基本計画は終わりましたがこの記事は続きます。
メンバーは全知全能になりましたが、具体的に負債が返済されなければこの計画は意味をなしません。

ここからは国土強靭化基本計画"後"の話をします。この手の催しは健康診断と一緒で改善活動を実施することと予後の観測が重要です。

Slackbotで進捗状況の観測・リズムづくり

Slack bot に「進捗いかがですか」リマインダーを設定し、週一程度で責任者に対し課題(a.k.a 伸びしろ)の進捗確認を行っていました。

HERP ではよくある手法な気がします。bot にした理由として:

• 定期的継続的な活動は人間がやると忘れる

• 人間は他人にリマインドするとき少なからず負荷がかかるが bot は感情がないので気持ちが楽

• 特定の責任者に対しメンションを送るだけなので bot にも可能

などが挙げられます。

以下のようにSlack の特定のチャンネルのスレッドを見に行けばその週の進捗がわかる状態がほぼ担保されていました。リマインドが形骸化することもありませんでした。

国土強靭化実施〜後までの活動成果

この活動は2月の上旬に行いましたが、四半期続けて、主に以下のような成果が出ました。

• ライブラリのアップデート頻度の向上

  • つまりアプリケーションの品質向上

• 週一でまとめて作業する時間を入れたことによる renovate bot の運用改善

• README の加筆修正コストの削減による情報の質の改善

  • READMEを GitHub から Scrapbox に差し替える運動が着実に進んだ

• テクニカルな課題(例えばメモリリークなどの問題)の特定と解決

• レビュワーの割当て規則の見直しによるコミュニケーションコストの改善

他にもありますがHERP固有かつ具体的な話が多いのでここでは割愛します。

少なくともアプリケーションの品質は確実に向上したのではないでしょうか。これは開発者としては嬉しいです。

全体としてのスループットは計測できていないので感覚としての話になりますが、筆者も実際に仕事をしているときの悩みのタネが以前と比べて減ったように感じています。

また認識を合わせ問題意識を揃えたことで、今後新しく開発しうるものの期待負債が大幅に減少したと考えられます。

つまり今後の同一労働時間での創出価値が向上したということで、HERPという組織ひいてはサービスにとって大きくプラスになるはずです。

そして、活動に対するフィードバックを自主的に募っているメンバーもいました。

一度決めたやり方に固執することなく最適解を模索し、かつフィードバックをしやすい簡潔な仕組みを用意していて、筆者も見習いたいと感じました。

次回開催に向けて

我々（kdxu, aiko）初回実施者は計画の最後に次回開催者を挙手制で2名募りました。彼らによりこのブロで取り上げた Try や開発状況を元に、スケジューリングや仕組みを変えて第1.5回計画(短縮版)が実施されました。実はもうされています。これについては長くなるのでここでは割愛、もしくは別途記事で紹介できればと思います。

今後も四半期ごとに継続できればと思っています。
これまで開発チーム全体を巻き込んだ活動がなかったHERPの開発チームとしては、持続的に続けていける仕組みを作れたという点でも、大きな前進でした。

この取り組みを振り返って

こんにちは、再び戻ってきてaikoです。
最後に参加した開発の皆さんからリアルな声を聞いてみましょう！

社内の声

リアルそのままで修正なしです！

もちろんいいことばっかりではなく「ここはもっと改善したい〜」という声もありました！

改善すべきところはちゃんとTRYを考えて、次回に活用する予定です。

初回計画実施者の声

aiko：
はい、aikoです。ご質問ありがとうございます。

普段みんなで集めて、自分が担当するコンポネートの知見を共有したり、横断的な議論をする機会が中々なくて、今回の開催をきっかけにそれを実現できたのがかなり良かったっと思います。

正直事前にどれくらい効果あるがあるのもわからなかったし、本当に試しにやってみよう！という感じなので、少しは心配していましたが、みんなさんのフィードバックも良くてよかったです。

そして1スプリント止めて開発全員を工数を使って 「やってみよう」ができる会社はすごいと思いました。理解してくれたプロダクトオーナーも、プレゼンの準備をしてくれた、参加してくれた開発メンバーに感謝します！

kdxu：
HERPとしてこうした開発チーム全体としての改善活動を実施するのが歴史上ほぼ初めてだったのもあり、荒削りだったり遠回りとなったような面もありましたが、総体としては今後のプロダクトの価値・働きやすさの向上に確実に繋げられた良い催しだったと思います。

このような いわゆる飲み会での思いつき とも取れる（実際そういう文脈である）ラフな提案を受け入れてくれて、さらには時間を使って準備に協力してくれた社内関係者に感謝します。

さいごに

この話を読んでHERPの開発チームに興味を持った、という方はまずはこちらを参照してみてください。

プロダクト開発の求人一覧はこちらから

また、この催しについてさらに詳しく聞きたい・物申したいという方はぜび会話しましょう！下記のカジュアル面談申し込みフォームよりお願いします！

herp.careers カジュアル面談

株式会社HERP

募集要項をみる

以上、エンジニアのkdxuと、aikoでした！