自分を含めて3人の開発チームで、業務システムの開発、社内ツールの保守、AI機能の実装、インフラの維持を回している。この規模で使っている仕組みを書く。
やっていることは多くない。朝会の進行をメンバーに任せる、Issueの優先度を3段階に絞る、ドキュメントは「なぜ」だけ書く、の3つが中心だ。どれも、うまくいかなかったやり方を直した結果としてこの形になった。
朝会：進行をメンバーに任せる
毎朝、短い朝会をやっている。確認するのは次の3点だけだ。
- プロジェクトごとの進捗
- タスク単位の動き
- 詰まっていること
この朝会の進行を、自分ではなくメンバーに任せている。WBSの管理もあわせて渡した。
理由は自分の負担を減らすことではなく、進行役という役割の性質にある。朝会を進行するには、チーム全員のタスクを把握していなければならない。自分の担当だけを見ていると進行できない。役割そのものが、全体を見ることを求める。
時間は朝一に固定している。決まった時刻があれば、準備の締め切りも自然に決まる。
渡した直後は形式的になった
進行を渡してすぐは、うまく機能しなかった。進捗の確認が形式的になり、「詰まっていることはありますか」「ないです」で終わってしまう。朝会が、チームの状態を把握する場になっていなかった。
変わってきたのは、進行役が新しく入ったメンバーへの説明も担当するようになってからだ。人に説明するには、まず自分が全体を把握していなければならない。その必要が具体的になって、朝会の確認も中身のあるものになっていった。
役割を渡せばすぐ機能するわけではなく、その役割が必要になる状況がそろって初めて回り始める、というのがここでの学びだった。
タスク：「やっておいて」をやめて、Issueを3段階にする
当初は「やっておいて」で任せることが多かった。裁量を渡せば自走するだろう、と考えていた。
実際にはタスクが予定どおりに進まなかった。原因を考えると、任せ方のほうに問題があった。進め方の方針を何も渡していなかったのだ。今は、タスクを渡すときに次の順番を踏むようにしている。
- タスクを言語化する（何を、どこまでやるか）
- 何を調査すれば前に進めるかを確認する
- それから作業に移る
管理はGitLabのIssueをベースにして、優先度は3段階だけにした。
| 優先度 | 意味 | |---|---| | 今週中 | 今週のうちに終わらせる | | このスプリント内 | 今のスプリントで終わらせる | | バックログ | いつかやる。今は着手しない |
ラベルを増やさないのは意図的だ。管理の仕組みが重くなると、小さいチームの意思決定の速さが失われる。ラベルを増やすほど、管理のための管理が生まれる。3人なら、全員に「今何をやるか」が見えていればそれで足りた。
一般に、細かい分類が必要になるのは、人数が増えて全員の状況を口頭で共有できなくなってからだと思う。3人の段階で先回りして入れる必要は感じなかった。
情報の流れ：一方向の連鎖にする
3人だと、誰が誰を見るかを単純にできる。
- 新しく入ったメンバーは、先に入ったメンバーが見る
- 先に入ったメンバーは、自分が見る
伝達も同じ向きに流す。自分が伝えたことが、順に次へ伝わる。流れが一方向なので、誰に何を伝えたかが曖昧になりにくい。自分にとっては、見る対象が絞られるぶん考慮することが減る。
ドキュメント：「なぜ」と「つまずく手順」だけ書く
全体の構成を把握しているのが自分に偏っている、という属人化は今も解消できていない。完全になくすのは難しいが、ドキュメントで緩和はできる。
ただし、全部を書こうとはしていない。書くのは次の2種類だけだ。
| 書くもの | 例 | |---|---| | なぜその設計にしたか | 開発で新しく作ったものの設計の意図 | | 初見でつまずく手順 | 初めてやる人が止まりそうな作業の手順 |
この方針になったのは、外部からシステムを引き継いだときの経験による。引き継ぎ資料には「何をするか」は書かれていたが、「なぜそうするか」は読み取れなかった。そのため、判断が必要になるたびに手が止まった。引き継ぎ全体の経緯は内製化の記録に書いている。
それ以来、新しいことを始めるときは何かを残すようにしている。開発なら設計の意図を、作業なら初見でつまずきそうな手順を。読み手は、未来の自分と、後から入ってくる人だ。
逆に、コードを読めば分かることは書かない。書く量が増えるとメンテナンスが追いつかず、古い情報が残る。古いドキュメントは読んだ人を誤った方向に連れていくので、無いより扱いに困る。
人数が増えたときのために
今の仕組みは、3人が互いの状況を把握できていることに頼っている。人数が倍になれば、同じやり方は通用しないだろう。
そのために今から少しずつ進めているのは、次の3つだ。
- 暗黙知を言葉にする
- 朝会の進行を渡す
- コードレビューの一部を委ねる
自分がいなくても回る部分を、少しずつ増やしていく。レビューを委ねていく過程は、コードレビューを3年続けた記録に書いた。
まとめ
- 朝会は進捗・タスクの動き・詰まりの3点だけ。進行をメンバーに任せると、全体を見る役割が生まれる
- 役割は渡してすぐには機能しない。その役割が必要になる状況がそろってから回り始める
- 「やっておいて」ではなく、言語化 → 調査項目の確認 → 作業、の順番を渡す
- Issueの優先度は「今週中・このスプリント内・バックログ」の3段階で足りた
- ドキュメントは「なぜその設計にしたか」と「初見でつまずく手順」だけ。コードで分かることは書かない
関連記事: