「少数精鋭」という言葉は、うちのチームには当てはまらない。
今は3人だ。自分とメンバー2人。4人だった時期もあったが、優秀だった人が辞めて、問題を抱えた人が入って、また戻り、運用担当が辞めて——気づいたら3人になっていた。
「精鋭」じゃない。「少数でなんとか動かしている」というのが正確だ。
でも動いている。治験CRMのプロダクト開発、社内ツールの保守、AI機能の実装、インフラの維持。これを3人で回し続けている。
どうやって回しているかを書く。
朝会の仕切りを渡すまで
毎朝、短い朝会をやっている。プロジェクトごとの進捗、タスク単位の動き、詰まっていることの確認。それだけだ。
最近は先輩メンバーに仕切りを任せるようにした。ただ「負担を減らしたい」からではない。理由がある。
そのメンバーは、タスクの期限を守らない。遅れそうになっても報告しない。真面目で責任感は強いのに、自分のタスクしか見えていなかった。
怒っても変わらない。指示しても変わらない。ならば、嫌でも周りを見ざるを得ない役割を与えればいいと考えた。WBSを管理させて、朝会を仕切らせる。チーム全員のタスクを把握しなければ仕切れないのだから、自然と視野が広がるはずだと。
朝一の固定時間にしたのも意図がある。決まった時間があれば、それまでに準備するしかない。
本人に話すと、「やらせていただきます」と即答だった。返事だけはいい。
最初は全くダメだった
仕切りを渡してすぐ、うまくはいかなかった。
準備が甘い。進捗の確認が形式的。「詰まっていることはありますか」と聞いて「ないです」で終わる。チームの状態を把握しようとする姿勢がまだなかった。
変化が出てきたのは、後輩が入ってからだ。
後輩への指導も、これまた無理矢理やらせた。教えることで、自分がいかに言語化できていなかったか、いかに曖昧に動いていたかが見えてくる。教える側に立って初めて、自分のダメさに気づいたようだった。
朝会の仕切りも、後輩を管理する立場になってから変わり始めた。人に説明するために、自分が全体を把握しなければならないという必要性が、ようやくリアルになったのだと思う。
「無理矢理やらせたら本人が気づいた」——これは自分の中でファインプレーだったと思っている。
「やっといて」では動けない——タスク管理の失敗
属人化はほぼ避けられない。治験CRMのアーキテクチャを完全に把握しているのは自分だけで、それは今もそうだ。
だから当初は「やっといて」で任せることが多かった。裁量を与えれば自走するだろうと思っていた。
違った。
期限が守れない。なぜ守れないかを冷静に考えると——方針がないからだと気づいた。タスクを言語化して、何を調査すれば前に進めるかを確認して、それから作業に移る。このフレームを伝えずに「やっといて」と言っても、動き方がわからない。
今はGitLabのIssueをベースに、優先度を3段階で管理している。今週中、このスプリント内、バックログ。それだけだ。
シンプルにしたのは、3人という規模と、「管理の仕組みが重くなると小さいチームの意思決定の速さが死ぬ」という経験からだ。ラベルを増やせば増やすほど、管理のための管理が生まれる。全員に今何をやるかが見えていれば、それで十分だった。
3人の連鎖構造
3人だからこそ、管理の構造をシンプルに保てている。
後輩は先輩が見る。先輩は自分が見る。自分は先輩の動きに注力すれば、考慮するところが減って効率化できる。
伝達もスムーズだ。自分が先輩に伝えれば、先輩が後輩に伝える。3人の連鎖が一方向に流れているから、情報の取りこぼしが起きにくい。
ドキュメントは「なぜ」だけ書く
属人化を完全になくすことはできないが、緩和することはできる。ドキュメントを書くことだ。
ただし、全部書こうとするルールは持っていない。書くのは「なぜその設計にしたか」と「初見でつまずく手順」の2種類だけだ。
このルールになったのには背景がある。ベンダーからシステムを引き継いだとき、「あの手順はどうする、これはどうする」という問いが大量に発生した。引き継ぎで渡されたドキュメントには「何をするか」は書いてあっても、「なぜそうするか」がなかった。結果、判断を迫られるたびに手が止まった。
それ以来、新しいことを始めるときは必ず何かを残すようにしている。開発なら設計の意図を、作業なら初見でつまずきそうな手順を。未来の自分、後から入ってくる人、自分がいなくなった後のためのものだと思って書く。
コードを読めばわかることは書かない。メンテナンスが追いつかなくなって古い情報が残る。古いドキュメントは、ないよりたちが悪い。
「次のフェーズ」のことを考えるようになった
社長から「グループ全体のITをまとめる体制を作れないか」という話があった。まだ具体的な動きにはなっていないが、考えるようになったことがある。
今の3人体制は、全員の阿吽の呼吸で動いている。それが6人、8人になったとき、同じやり方は通用しない。
だから今から少しずつやっていることがある。暗黙知を言語にする。朝会の仕切りを渡す。コードレビューの一部を委ねる。「自分がいなくても回る部分」を少しずつ増やしていく。
目標は、自分が暇になること。そのためのチーム設計だ。
精鋭じゃなくていい、機能すればいい
「少数精鋭」と言えるチームを作りたいとは、あまり思っていない。
精鋭を集めることより、今いる人間が機能できる環境を作ることの方が、テックリードの仕事だと思うようになった。
朝会の仕切りを渡したら最初はダメだった。でも後輩への指導を通じて変わり始めた。「やっといて」で任せたら動けなかった。でも方針を渡したら動けるようになった。
どちらも、渡してみて初めてわかったことだ。
3人で動いている。それが今の現実だ。
この記事を読んだ方へ
PR 似た領域で実務に関わる方へ
似た領域で実務に関わる方は、定期的に外の市場感を把握しておくと判断軸が増える。今すぐ動く動かないは別として、自分のスキルがどう評価されるかを知っておく価値はある。
IT/WEB/ゲーム業界専門のエージェントならギークリーが分かりやすい。エンジニアに特化しているので、年収レンジを掴む目的だけでも使える。
関連記事: