時間	内容
10:30 - 11:30	情報共有
11:30 - 16:00	作業時間 & イベント & 交流
13:00 - 14:00	イベント①
14:00 - 15:00	イベント②
16:00 - 17:30	LT大会
17:30 -	懇親会

この日に関してはリリースの開発工数日に含まないように事前スケジュールし、
普段の仕事中にやれていない対応、作業の整理やコミュニケーションを行なう日としています。

社内イベントは、Gather.Townを使用して運用しています。

https://app.gather.town/app

メリット / デメリット

メリット
- エンジニアチーム全体に情報を共有するの提供
- 仕事以外の会話の場が増えた
デメリット
- 運用コスト
  - 特に組織にマッチさせて、継続的に実施できるフォーマットが決まるまでのコストがかかる
  - ある程度繰り返し実施するとフォーマットが確定するのでコストは下がっていく

☕ Coffee Chat

内容

社内イベントで大人数で集まるコミュニケーションの場を設けることはできたが、
リモートで大人数集まっても同時に喋れるのは3〜4人程度ということも、何回か実施して分かってきました。

そこで以下のスライドで紹介されていた、Coffee Chatを取り入れてみました。

以下で運用しています。

Coffee Chatの参加の希望者をスプレットシートで募集
希望者からランダムで抽選してペアを作成し自動でGoogleカレンダーにCoffee Chatのイベントが登録される
Googleカレンダーの登録されている時間になったら、イベントのGoogle Meetに入って、1 on 1で30分間の雑談を行なう

メリット / デメリット

メリット
- 定期的な会話の場が設けられた
- 同期的コミュニュケーションの場を設けることで、非同期のコミュニケーションもスムーズに行く機会が増えた
- 希望者のみの参加なので気軽に実施できる
デメリット
- 希望者が奇数だと1人ペアが組めなくなるので運用でカバーする必要がある（現状だと奇数だとスクリプトで自動で自分が外されるようにしています 🙀）

📝 Tech Blogの運用

内容

組織を大きくしていくためにはメンバーを増やすことも重要。
応募する人も、どんな人が働いているのか分からないと不安になるので、シェアフルでは以下の2つのTech Blogを作成して、どんな組織か理解できるようする運用を開始しました。

①. エンジニアチームのブログのHubサイト

以下の記事で紹介していた、team-blog-hubを元にエンジニアチームのブログのハブサイトを運用しています。

サイトは、こちら。
https://techblog.sharefull.com/

②. ZennにシェアフルのTech Blogアカウントを作成

以下の記事を参考にZennの投稿環境を構築。

Zenn CLI経由で記事を管理すれば、アカウント自体は全体に共有せず、リポジトリで記事の投稿/更新を管理ができます。

メリット / デメリット

メリット
- 社内の情報を外部に発信できるようになった
- どんなメンバーがいるか分かるようになった
デメリット
- ブログ運用コストがかかる

📄 機能の仕様ドキュメントをGitで管理

内容

シェアフルは運用開始してから4年目のプロジェクトです。
長期間の開発になると機能の複雑さ、内容のハイコンテクスト化、保守されないドキュメントが発生し、正確な仕様の判別ができなくなり開発の精度が落ちてしまいます。

そこで以下のGitLabのHandbookの思想を取り入れて、機能の仕様ドキュメントをGitで管理するチャレンジを開始しました。

運用

docsifyを使用して、機能の仕様ドキュメント管理
Gitで管理している機能の仕様ドキュメントのみを唯一の正確な仕様書として扱い、その他の資料は開発期間中のみ有効な一時的な資料として扱う。
新規機能は、リリースまでにドキュメントを作成してリポジトリにマージ
既存機能は、依頼ベースのフローを構築

メリット/デメリット

メリット
- 新しく入ったメンバーでも仕様のキャッチアップがしやすい
- 過去に実装した機能の仕様や実装した目的を確認できる
デメリット
- エンジニアチーム以外にGitの使い方を教えるコストがかかる
  - 現状はエンジニアチーム以外はWeb上で操作する形式を推奨して運用している

🧃 投書箱開封ミーティング

内容

フルリモートになり、オフラインで働いてころのように気軽な提案や議論の場が少なくなったので、定期ミーティングを設けることにしました。

運用

投書箱（Googleフォーム） を設置
メンバーには、投書箱に要望、議論したい内容、質問、不満に思っていること などを自由に投稿して貰う
月1でチームごとに開封のミーティングを行い、投稿された内容について話し合う
話し合った内容を議事録に記載して共有する

メリット / デメリット

メリット
- 定期的な質問/提案の場を設けられた
デメリット
- なし

💻 週1でモブプロ

内容

週1でモブプロの実施しています。
モブプロのホストが前日に対応するissueを共有して希望者は自由に参加してOKの流れで運用。
現在は、Visual Studio Live ShareとAroundの組み合わせで行っています。

メリット / デメリット

メリット
- 新しく入ったメンバーでも技術のキャッチアップがしやすい
デメリット
- Visual Studio Live Shareに頼っているので言語によっては効率よく作業できない
- 別のエディターを普段使いしている場合に、参加しづらい

📈 キャリアパス

内容

組織の人数が増えると、チームメンバー全員の要望のキャッチアップが難しくなる。
そこでキャリアパスを作成し、定期的にエンジニア側の要望とマッチングを行なう運用をしている。細かな運用は以下の通り。

各エンジニアチームごとに、以下のようなキャリアパスを作成

## ○○チーム

### チームリーダー
 - 仕事の内容: ***
 - 求められるスキル: ***

### スペシャリスト
 - 仕事の内容: ***
 - 求められるスキル: ***

### システム品質の向上
 - 仕事の内容: ***
 - 求められるスキル: ***

### ドキュメントライター
 - 仕事の内容: ***
 - 求められるスキル: ***

3ヶ月ごとにキャリパスのアンケートを出力し、各エンジニアが回答
上記の情報を参考に今後のissueのアサインや、チームビルディングを行なう

メリット / デメリット

メリット
- メンバーの希望をキャッチアップできる
デメリット
- 特に無し

🚚 アサイン募集中の仕組み

内容

組織の人数が増えると、issueのアサインのコストが大きく発生するようになりました。
アサインをする側/される側共に、issueの内容の好み、空き度、対応できる能力など、自然と考慮してしまい期待値の調整にコストが発生していると気づきました。
なので、個々に負担を掛けずに、メンバーには理想的な形で自走できるようにissueのアサイン募集のフローを作成して運用しています。

モンスターハンターのクエストボードみたいなイメージで運用しています。

issueにアサイン募集中のラベルを設定
定期的に上記を自動集計してアサイン募集中のissue一覧の記事を更新
上記で募集しているissueは自由に自身にアサインしてOK 👌
アサイン募集中のissueに関しては、別チームのissueも自身にアサインしてOK 👌

この運用をすることで、スケジュールの伴わないissueに関してはissue作成して、アサイン募集中のラベルを設定して放置。エンジニアはアサイン募集中の記事を見てやりたい場合は、自身にアサインして対応の流れで運用しています。

メリット / デメリット

メリット
- メンバーが自身の興味のあるissueを対応できる
- アサインのコストを軽減できる
デメリット
- issueの書き方に工夫が必要になる
  - 内容が難しい/アバウト/面倒などの理由で誰もアサインしてくれないissueが発生する可能性がある

🔨 最適なチーム人数 & 所属チームの役割を定義

内容

1時期、あるチームは人数が増えすぎてリーダーの負担が大きくなりやりづらい、あるチームは人数が少なくなり過ぎてやりたいことがやれないという事象が同時に発生しました。
その問題に関してはチームトポロジーのChapter3を参考に最適なチーム人数を定義しました。

最適なチーム人数

フルタイム: 5人
副業: 1〜2人

チーム人数を制御すると、必然的に所属チームの移動する可能性も高まるので所属チームの役割を明確に定義しました。

所属チームの役割

所属するチームの定期リリースのissueがアサインされる
所属するチームの定例ミーティングに参加する（フルタイム稼働のみ）
上記以外は、アサイン募集中の仕組みに乗っ取りタスクを消化する

チームの移動に、キャリアパスアンケートなどを参考にして、本人に確認を取り、お互いに同意が取れた場合のみチームの移動が発生する運用にしています。

メリット / デメリット

メリット
- チーム作業の効率が向上
- エンジニアの新規採用の際の基準となる数値を設けられた
デメリット
- なし

🛏️ 生産性を上げすぎない仕組み作り

内容

1時期、あるチームの機能開発タスク^[1]の生産を上げすぎてしまい、メリットがデメリットを超えてしまう自体が発生しました。

生産性を上げすぎた際の主なデメリット

対応できる件数が増えると質問が発生する件数が増え、チームリーダーへの負荷が高まる
チームリーダーへの負荷が高まると、本来やりたかった改善の施策が滞る
生産性を上げることでエンジニアの忙しさが解消されるのが好ましいが、単純に生産性向上を目標にしてしまうと 生産性を上げれば、上げるほど全体が忙しくなる構成になってしまう
また、機能開発自体は終わりの存在しないものなので、必要以上に生産性を上げ続けるメリットが少ない

対応内容

上記の対策のため、各リリースでの対応数の基準値を設けることにして生産性の調整を行なう運用に変更しました。

計算の例: ○○チームは作業日数1日で平均XX個の対応ができるので、今回のリリースの作業日数は5日なので、△△できる想定（※詳しい計算方法は業務に関わってしまうのでイメージ的な計算式を記載しています）

リリースの開発期間に、チームで△△の数値以上に機能開発タスクを消化しないルールに変更しました。リリースの開発期間中に△△の対応が完了してリソースが余った場合は、上記記載のアサイン募集中の仕組みに乗っ取りタスクを消化するようにしています。（または自身でリファクタリングissueを立てて対応してもOK 👌）