開発部の「相談会」がどのようなものか、その歴史と狙い、現在の取り組みの一例を見ていく。
# はじめに
ここで紹介する取組みは、開発部における取組みのうち、2019 年から自然発生的に始まったコミュニケーションを用いた一連の流れに関する話である。
なお、本記事で記述される内容については、奇抜さはない。『エンジニアリングマネージャーのしごと』、『Team Topology』、『ユニコーン企業のひみつ』といった良書が翻訳・出版された今になって振り返ってみると、ある種のギルドを作り、運営してきたと考えることもできる。
上記のような良書を取り上げたが、しかしながら、書籍に取り上げられているような特別なことをやっているわけではなく、一つずつに取り組んでいった。そのため、書籍の内容を知っている方に伝えておくと、すぐ応用可能だったり、すごく有用な知見があるわけではないことについては、ご了承いただきたい。
# 2019 年からの一連の取り組み
# 相談会
アフタヌーンティーやシエスタといったものについて、一定の憧れを持っている人が多いではないだろうか。私もその 1 人である。
開発部では、そのような時間を相談会として、平日の営業日には毎日午後 3 時から実施している。もちろんただ横になったりお茶を飲んだりしているわけではない。この相談会では、技術的な相談や発表だったり、歓迎会など開発部内で決めるべきことがある際の相談の時間として設定している。また、相談事項や発表などがなければ、雑談なども行っている。
相談会の狙いはいくつかある。
- 技術的な相談を誰かにしたいけれど、誰に相談すればいいかわからないところで相談できるようにしたい。
- また、相談したことのログがあれば、同じような悩みに突き当たったときにどう解決したのかを質問しにいけるようになる。
- 開発部の成長する機会を得るために、勉強したことの発表の機会の提供と、興味関心の涵養。
- 非同期コミュニケーションで生まれる課題の緩和。
- 同期コミュニケーションをすることにはしているが、ここでは音声情報のあるコミュニケーションを取る時間とした。カメラや表情はいらない。
どうやって導入したのか
2019 年時点から、「相談会」自体はあった。（明確な開催時期は記憶が曖昧である）
当初は相談ごとがあったら集まろうという状態だったが、次に、発表もやろうとなっていった。この時点では、誰かが相談したいことや発表したいことがあったら、チャンネルに投稿しておいて、コアタイム内でみんなが集まっている時間にちょっとやる、という感じで、定期的ではなかった。
開催頻度の変化が起きたのはコロナの時期だった。コロナの時期で全員がフルリモートとなり、非同期にテキストでのコミュニケーションとなった時期は、言葉使いなどが強い表現と受け取られてしまうなど、チーム内でのコミュニケーションに課題が発生していた。非同期コミュニケーションの課題の緩和策として、相談会を定期的にやるようにすることを決定した。
この狙いを共有し、合意し、そして運用していくのに当たってやったことは明文化と運用だった。明文化については、GitHub の開発部のルールをまとめたレポジトリがあるので、そこに Issue を立てた。そして、毎日午後 3 時からと時間を決めて、みんなのカレンダーを抑えて、全員が集まるようにした。相談会の当初はどうするか、どうやっていくか、という課題があったが、それについても開発部全体で相談し、実践し、形にしていった。
毎日なのはなぜ？
毎日行うことにはメリットがある。日によっては相談事項がなかったりする。直前になって思いついたけれど投稿するのをやめた人がいても、誰も話さないんだったらせっかくだったらということになる。本当に話すことがなかったら、途中で終わらせれば良い。
しかしながら、チームの時間を 1 時間いただくのは、怖い、と思った。今でも思っている。
しかし、期待値以上のことができているから良い、というのが現時点の私の判断である。期待値を超えられていると言えるのは、相談会の最初の狙いの、相談事項、発表、学習、コミュニケーション、これらが得られていることはもちろんである。さらに、後述の新たな取り組みもここから発生したからである。ここでは「業務改善アイディア会」と「リファクタ&負債解消祭り」を取り上げる。
# 業務改善アイディア会
相談会から生まれた取組みとして、「業務改善アイディア会」がある。
みんなが成長すれば技術やプロダクトに相談する事は慣れていくと減る。
発表する事柄も学習の時間が十分に取れていないとあまり蓄積されない。たとえ、開発部のルールとして毎日の業務時間のうち 1 時間は勉強時間に使って良いというルールがあったとしても、時間を取り、発表するだけの十分な調査や思考の時間が得られないことがある。
雑談も無理にやろうとすると、話す人が固定化されたり、話題選びに苦労が伴う。チームを分割することも行っているが、難しさは消えない。
これらの課題が出てきたうちに、余った時間の活用として雑談以外にも、もっとアクティブなことをやりたいと感じるようになってきた。そしてタイミングよく、相談会やそれ以外の時間でも、業務の改善事項について話すことが多くなっていた。そのための時間として「業務改善アイディア会」を開いてみよう、という話になった。
「業務改善アイディア会」では、ソフトウェアやコードに関する技術的なこと、組織やマネジメントに関する組織的なこと、技術にも組織にも限定されない広く改善するためのアイディア、これらを集めるようにした。
開催頻度としては、毎日課題が出るわけではないから、蓄積しておいて、隔週でやっていくこととなった。
アイディアの蓄積や管理については、通常のバグ報告に対する対処と同じようなカンバンを使ったものにすることにした。カンバン形式にした理由は、スラックのチャンネルだと、業務に関する改善事項を投稿しても、流れてしまう。Notion に新たなページを追加し、そこに溜めていくようになった。
集めたアイディアの管理については、アクションを起こすことが決まった課題については、ソフトウェアやコードに関するものは GitHub の Issue にしたり、取り組みの終了条件を書いたりして、記録を残すようにした。各アイディアについて、取り組んでいるところか、まだ議論を要求する段階か、といった状態を追跡できるようにするため、Notion で Status を追加した。
「業務改善アイディア会」経由で生まれた取り組みのうち、いくつか例を上げると以下のようなものがある：
- リリースノートを蓄積するようにしたい。
- 業務に関する実績解除が欲しい。
- 本棚を買いたい。書籍貸出の管理をしたい。
# 祭
「業務改善アイディア会」から生まれた取組みとして、「リファクタ&負債解消祭り」、通称「祭」というのがある。
リファクタや技術的負債というのは、それの解消をするのは一人の力でなせるようなものではなく、みんなで一斉にやったほうがよいケースがある。
なお、リファクタや負債解消といったこと以外にも、ドキュメント整備やリンク集を作ったりなどの取り組みもこの祭の一環として行われている。
「リファクタ&負債解消祭り」の例を取り上げると次のようなものがある：
- React 18 アップグレード祭、
- merrors ラップ祭り、
- merrors というのは弊社のサービスで使っている Go のエラーラッパーである。
- ドキュメント整備。
補足: リファクタや技術的負債の解消は開発レベルの判断であるべきか
この「祭」を、他の企業や組織に対して、同じことをやりましょう、といった提案を私はしない。
matsuri の開発部は、自由と裁量を渡し、オーナーシップを持ってプロダクト開発に取り組んでいる。また、会社も開発部に信頼を置いてくれている。そのため、リファクタや技術的負債の解消と呼ばれるものについても、自分ごととして取り組んでいる。
しかし、書籍や他社の取り組みを見ていると、この手のリファクタや技術的負債の解消というのは、実際のところは経営レベルの判断として考えるべきであり、そのように判断と実行がされているということが伺える。
一方、弊社の開発部はやろうというときに開発部みんなでやれており、開発レベルが判断し、実施までしている。これは、もしかしたら特殊な事例なのかもしれない。
なので、もし類似のことをしたいと考える方がおられる場合は、まずは、解決したい課題はなにか、状況はどうか、使える道具はないか、その判断は経営レベルか開発部レベルのいずれのレベルで行うべきか、といったことを考えてほしいし、チームの特性と文化を大事にしてほしい。
# まとめ
開発部の取組みは、自然発生によって生まれた。人々が興味を持っていることに自主的に参加し、取り組み、共有し、といったことは、部署やチームの全員が共通して参加している点でギルドとは違うが、ギルドに近いものを感じる要素が所々にある。では、スタート時点でギルドを知っていたら、もっとギルドらしいことを最初からやるために別の手順やルートをとっていただろうかと問われると、そうはならなかったと思うと答えるだろう。というのも、その時の課題と現状に向き合い、改めて、その時に取り得る中で最適なものを選択するとなると同じルートを通っていたことになるだろうから。
大事なのは、その時のチームと文化、そして解決すべき課題へのフォーカスである。自由と裁量をもとに、最も嘉みとされる仕事を行っている我々は、漸近的で自然発生的な文化の醸成をこれまで行ってきた。そして、今も新たな取組みや試みを生み出している。現時点では、開発部が 10 名程度と小規模なので、全員が参加し、また全員が興味を持って取り組むことになっているが、いずれ開発部の規模が大きくなっていった場合は、また別の形式・形態を採用することになるだろう。その時も、我々は良い取組みにトライしていくだろう。
# 参考文献
- James Stanier(2020) "Become an Effective Software Engineering Mnager" the Pragmatic Programmers(James Stanier(著), 吉羽 龍太郎・永瀬 美穂・原田 騎郎・竹葉美沙(訳)(2022)『エンジニアリングマネージャーのしごと』オライリー・ジャパン)
- Jonathan Ramusson(2020) "Competing with Unicorns", the Pragmatic Programmers(Jonathan Ramusson(著), 島田浩二・角谷信太郎(訳)(2021)『ユニコーン企業のひみつ』オライリー・ジャパン)
- Matthew Skelton et Manuel Pais(2019)"Team Topologies" It Revolution Press(マシュー・スケルトン & マニュエル・パイス(著)、原田 騎郎・永瀬 美穂・吉羽 龍太郎(訳)(2021)『Team Topologies』日本能率協会マネジメントセンター)