この記事は、Bill One 開発 Unit ブログリレー 2025の第 16 弾です。
はじめまして
こんにちは。Bill Oneエンジニアの柳瀬です。
普段はBill Oneの受領（AP）領域のエンジニアとして新規機能開発を行いつつ、2025年6月から同領域のチームリーダーとして働いています。
経歴を紹介すると、文系大学を卒業後、新卒で自動車系SIerに入社しSEとして約5年間従事しました。その後2024年8月にSansanに入社しています。
察した方もいるかもしれませんが、今回の転職で開発に対する価値観・ビジネスモデル・開発に求められるスキルやスピード感、これまでの仕事に対する常識が一気に変わりました。そうしたギャップに打ちのめされている間にリーダーという役割を任されました。
このブログは、ギャップに揉まれながらチームの成果をどう最大化するかを考え続けた、新米リーダーの半年間の試行錯誤をまとめたものです。
半年間の成果
最初にこの半年間で私のチームが出した成果を共有します。
私たちのチームは期日コミット必達のPBIを3つ、全てステークホルダーと握った期限内にリリースしました。そしてリリース後のインシデントも0件です。
各PBIの規模感は中程度のものであり、難易度が高いわけではありませんが、決して簡単なものではありませんでした。
現在は、より一層大規模で複雑度が高く、事業インパクトも大きいPBIを二つ並行開発しています。自組織、チーム共に、信頼してPBIを任せてもらえる関係性を構築できたのではと考えています。
リーダーとして取り組んだこと
ここから本題の、チーム成果最大化のために実践したことをお話しします。
私のリーダー業の方針は個よりもまずチームを強くすることです。三人寄れば文殊の知恵、という言葉の通り、個々の能力以上に、チームとしてうまく機能することが成果につながると考えていました。
1. 「自分が頑張ればいいは」、意外とチームを苦しめる
リーダーになって最初にやりがちだったのは、「自分が頑張れば何とかなる」という振る舞いでした。
• 自分が誰よりも働く
• 仕様も決めて、設計もして、レビューも全部見る
• 問題はすべて自分が何とかするというスタンス
一見するとストイックで、責任感もあるように見えます。しかし、実際にやってみると、徐々に歪みが出てきました。自分のタスクは詰まり、メンバーからの相談に十分な時間を割けなくなります。そしてレビューは滞り、チーム全体の流れが少しずつ詰まっていきました。さらに怖かったのは、無意識のうちに自分と同じハードワークをメンバーにも求めてしまっていたことです。
つまり、自分の稼働は上がっても、チームのスループットは上がらないという状態です。
この違和感から、自分が成果を出すのではなく、メンバー全員が成果を出しやすくなるように障害を取り除くことが、リーダーの役割なのではないかと考えるようになりました。
それ以降、自分の担当タスクよりも、どこが詰まっていそうか、誰が困っていそうかを見るようになりました。その一環として導入したのが夕会です。朝会で確認した進捗や負荷状況を、もう一度軽く確認する時間を設けました。
予想以上に仕事の透明性は低いものです。ヘルプを出したときには、もう手遅れ、ということも珍しくありません。
観測の粒度と頻度を上げたことで、アサイン調整やヘルプの追加が早めにできるようになり、進捗の遅れを早期に解消できるようになりました。この体験は、状況を整理することでチームのスループットを上げることができた最初の成功体験です。（マイクロマネジメントになりすぎないよう注意は払っています）
2. 決定を遅らせる、走りながら考える
次に直面したのは、決めすぎてしまう問題でした。
リーダーになりたての頃、仕様や設計を最初に決め切ろうとしすぎていました。開発では前提が変わるのが当たり前なのに、「最初に決めた通りに進めよう」としてしまい、変更のたびに判断が止まり、チームのスピードを落としてしまっていたのです。
この経験から、仕様や設計は変わって当然という前提に立つようになりました。大事なのは変えないことではなく、変わった時にどう進めるかを決めておくことです。
同時に、仕様をすべて書き切ることもやめました。すべてを書こうとすると、変更時のメンテナンスコストが高くなり、古い情報が誤解を生む原因になります。
今は、変わると困るものだけを先に決めています。受け入れ条件やデータフローのように、ここが曖昧だと全体が成り立たない部分です。一方で、APIの細部のように変わりやすいものは、走りながら考え、後で直せる前提にしています。このバランスが取れるようになってから、走りながら考えることがチームの共通認識になりました。
3. 心理的安全性を意識したら、サーバントリーダーシップが育った
チームで成果を出すには、本音が出るかどうかがとても重要です。
この仕組みは変えた方がいいかもしれない、ここは少し相談したい、正直このやり方はしんどい。こうした声が出ないチームは、一見すると静かですが、リスクが水面下で溜まり続けます。そこで、気軽に声を出せる仕組みとして意見箱を導入し、朝会で全員で確認する運用を始めました。
その結果、小さな違和感や改善アイデアが自然と集まるようになり、ミーティングを待たずに困りごとを拾えるようになりました。さらに得た気づきとしては、課題を挙げた人はその課題を一番強く感じている人だということです。だからこそ、その人が改善の主体になりやすく、実際にメンバー発信でチームの運用や開発体験が改善された事例がいくつも生まれました。
声を拾いやすい仕組みを作ることが、結果的にサーバントリーダーシップの土台になり、チーム成果の底上げにつながったと感じています。
4. リスクは気づくものではなく見えるようにするもの
私たちのチームでは、カンバンでタスク管理をしています。
進行中タスクがどれだけ早くDoneになるかが重要で、遅れは後続タスクにドミノのように影響します。
以前は、何日も止まっているタスクに誰も気づかなかったり、依存関係が見えずに手が空くメンバーが出たり、遅れに気づくのがスプリント終盤になることがありました。そこで、リードタイムに応じたアラートを赤や黄という色でカンバン上で可視化する仕組みを導入しました。
結果として、導入 2 週間後にはタスクの平均リードタイムが約半分になり、導入から1か月後の現在も改善効果が継続しています。
人の集中力や調子には波があります。「気づいてくれるはず」に頼るより、誰が見ても分かる状態を作ることが、成果最大化の近道でした。
5. レトロスペクティブは反省会ではなく実験設計会
レトロスペクティブはアジャイルの定番ですが、最初は正直つらいものでした。毎回同じ話題が出て、「気をつけます」で終わり、問題が再発する。完全に反省会になっていました。
そこで、レトロは次のスプリントで試す実験を決める場だと捉え直しました。この視点に切り替えてから、ペアレビューを固定で試したり、PR コメントを全員で眺める時間を取ったりと、小さな実験が自然に出てくるようになりました。改善が義務ではなく試行になり、改善し続ける文化が少しずつ根付いてきたと感じています。
おわりに：リーダーは学習を続ける人
新米リーダーとしてしばらくやってみて、今の答えはこうです。
- 自分が一番頑張るより、みんなが頑張りやすい環境を作る
- 正解を教えるより、答えに近づくプロセスを支える
- 完璧を目指すより、毎スプリントを少しずつ改善する
リーダーに求められているのは、チームと一緒に成長し続けること、学習しやすい場を整え続けることなのだと思います。
最後に、リーダー業に携わる中で多くの示唆をもらった書籍を紹介します。
Sansan 技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
