はじめに
こんにちは。ソフトウェアエンジニアの @blue32a です。Webアプリケーションの開発に携わり、開発を持続可能なものにするため、設計やテストを中心にエンジニアリングの改善に注力しています。
これまで、開発者として実装や設計に取り組むだけでなく、開発チームのリーダーを務める機会もありました。
本記事では、これまでの経験を踏まえ、開発チームのリーダーとして重視していることを整理していきたいと思います。特に、チーム全体のパフォーマンスや開発生産性を高めるための考え方やアプローチに焦点を当てます。
※ 主に小規模なWebアプリケーション開発の経験が元になっています。
チーム全体の開発を停滞させない
開発チームのリーダーであっても、プレイヤーとしての貢献が必要な状況もあります。そうした状況においても、自分自身のアウトプットだけでなく、チーム全体の開発が滞りなく進むようにする必要があります。
自分自身が開発者として成果を出すことも重要ですが、一人で発揮できるパフォーマンスには限界があります。チームリーダーである自分の対応を待っているメンバーがいれば、その待ち時間はチーム全体の生産性に影響します。
そのため、開発を停滞させる要因をなるべく取り除き、チーム全体の作業が円滑に進む状態を作ることを意識しています。
素早いレスポンスを優先する
リーダーというポジションに関わらず、基本的に、他者との連携が必要な部分は優先して対応するようにしています。これは、他者との連携では返答を待つ時間が発生する一方、自分の作業は比較的順序を調整しやすいと考えているからです。チームリーダーになるとメンバーとの連携も増えるため、他者の作業を停滞させないよう、自分の作業との優先順位を判断しています。
ただし、すべての依頼に即座に対応することが最適とは限りません。頻繁な割り込みは、自分自身の作業効率を低下させる要因にもなります。依頼の緊急度や他者への影響を踏まえ、優先順位を判断することも必要だと考えています。また、すぐに返答できない場合は目安を伝えるのも効果的だと考えています。
同期的なコミュニケーションを活用する
ソフトウェア開発では、チャットやIssue、PRなど、テキストベースの非同期コミュニケーションが中心になりがちです。非同期コミュニケーションは各自の都合に合わせて情報を確認・共有できる一方で、それだけでは効率が悪い場面もあると考えています。
例えば、複雑な問題についてテキストで何度もやり取りするよりも、直接会話した方が早く解決できることがあります。また、テキスト上のやり取りだけでは、チームの状況やメンバーが抱えている問題を十分に把握できない場合もあります。
そのため、定期的なショートMTGなど、同期的にコミュニケーションを取る機会も意識的に設けたいと考えています。単なる進捗確認だけでなく、困っていることや気になっていることを共有することで、問題の早期発見や認識のすり合わせにつなげることが狙いです。
各自の集中時間を尊重しながら、非同期と同期のコミュニケーションを適切に使い分けることが重要だと考えています。
メンバーが自走できる環境を作る
チーム全体のパフォーマンスを高めるためには、個々のメンバーが自律的に開発を進められる状態を作ることも重要だと考えています。
リーダーがすべての技術的な問題を解決したり、都度判断したりする状態では、リーダー自身がボトルネックになりかねません。また、メンバーが問題に直面するたびに作業が停滞してしまうことも避けたいところです。
そのため、個々のメンバーへの技術支援に加えて、チームとして自走できるような仕組みづくりも意識しています。
自己解決につながる技術支援
技術的な側面でフォローの必要性を感じた場合は、単に答えや解決方法を提示するだけでなく、メンバー自身が問題を解決できるようになることを意識しています。
例えば、実装や設計についてアドバイスする際には、結論だけでなく、その背景や判断の根拠も伝えるようにします。また、必要に応じて参考となるドキュメントや学習コンテンツを提供することで、関連する知識を自分でキャッチアップできるように支援します。
もちろん、状況によっては直接解決方法を提示した方がよい場合もあります。メンバーの習熟度や問題の緊急度を踏まえながら、適切な支援の仕方を考える必要があると思っています。
自走できる仕組みづくり
個々のメンバーへの支援だけでなく、チーム全体で活用できる仕組みを整えることも大切だと考えています。
例えば、開発環境の構築手順や開発ガイドライン、ワークフローなどをドキュメントとして整備することで、特定の人に質問しなくても必要な情報を得られるようになります。また、繰り返し発生する質問や問題については、個別に対応し続けるのではなく、仕組みとして解決できないかを検討したいところです。
こうした取り組みは、メンバーのキャッチアップを助けるだけでなく、知識の属人化やコミュニケーションに伴うコストの削減にもつながります。
また、仕組みやドキュメントは作って終わりではなく、実際の開発状況に合わせて継続的に改善していくことが重要だと考えています。
エンジニアリングを通じて開発生産性を高める
チームの開発生産性を高めるためには、日々の開発を妨げる技術的な問題にも継続的に目を向ける必要があると考えています。
目の前の機能開発だけでなく、開発環境やワークフロー、品質を支える仕組みを改善していくことも、技術的な側面からチームをリードするうえで重要な取り組みだと考えています。
開発を妨げる小さな問題を放置しない
日々の開発では、一つひとつは小さくても、積み重なることで開発生産性を低下させる問題があります。
例えば、次のようなものです。
- 実態に合わない開発規約やワークフロー
- CI/CDのエラーや実行時間の増大
- 不安定なテスト（flaky test）によるパイプラインの失敗
こうした問題は対応が後回しになりがちですが、放置することで継続的に開発の負担となります。
特に、CI/CDや自動テストは日常的な開発ワークフローを支える重要な仕組みです。不安定なテストによって不要な再実行や原因調査が発生するだけでなく、テスト結果そのものに対する信頼性が低下してしまうことも避けたいところです。
もちろん、機能開発との優先順位を考える必要はありますが、こうした問題に対して継続的に改善の時間を割き、開発を妨げる要因を取り除いていくことを意識しています。
コードレビューにおける品質と生産性のバランス
コードレビューも、チーム全体の品質や開発生産性に大きく関わる活動だと考えています。
コードレビューでは、品質を確保することはもちろんですが、過度な指摘によって開発を停滞させないことも重要です。
特に意識したいのは、レビュイーの考えやアプローチを尊重することです。自分の考えと異なる実装であっても、それだけを理由に修正を求めるのではなく、設計上の問題や品質への影響を踏まえて判断する必要があります。
また、レビューコメントでは、指摘の背景や根拠、期待するアクションを明確にすることも心がけています。単なる質問なのか、改善の提案なのか、修正が必要な指摘なのかを区別することで、不要なコミュニケーションの往復を減らすことにもつながります。
一方で、どこまでの品質を求めるべきかという判断には難しさも感じています。その場で改善を求めるのか、別の課題として扱うのか、あるいはアプローチの違いとして受け入れるのか。状況に応じて適切に判断できる力は、今後も高めていきたいと考えています。
不確実性を前提に計画・判断する
ソフトウェア開発では、仕様や既存実装への理解、技術的な課題、チームとしての開発速度など、さまざまな不確実性が存在します。
そのため、最初から精度の高い計画を立てることよりも、不確実性があることを前提として、状況を把握し、必要に応じて計画を調整できる状態を作ることが重要だと考えています。
不確実性を早めに減らす
開発を安定して進めるためには、不確実性の高い部分を早期に把握し、優先的に減らしていくことが重要だと考えています。
確実性の高いタスクから着手すれば進捗は出しやすいものの、重要な不確実性を後回しにすると、後半になって計画の見直しが必要になる可能性があります。そのため、不確実性の高いタスクは調査や検証ができる単位に分割するなど、早い段階で懸念を減らすことを意識しています。
プロジェクトの状況を見える化する
不確実性の高い状況でも、関係者との調整や開発をコントロールするために、状況を把握しておく必要があります。
そのために、プロジェクト管理ツールの機能を活用し、必要なときに集計できるようなアプローチを検討します。例えば、Tシャツサイズ見積りでIssueごとにS/M/Lなどをラベル付けしていき、サイズに応じた重み付けをもとに、おおまかな作業規模を定量化することで、素早く状況を把握し、関係者との認識合わせに活用します。
ただし、Tシャツサイズ見積りは大雑把な把握になるので、状況に合わせた見積り手法を選択できるようにしていきたいと考えています。
状況に応じてスコープを調整する
リリース時期や人員に制約があり、品質も疎かにできない場合には、スコープの調整が重要な選択肢になると考えています。
そのため、開発する機能の優先度や、スコープを調整できるポイントについて、あらかじめ関係者と認識を合わせておくことが有効です。開発が想定どおりに進まない場合でも、状況を適切に把握できていれば、何を優先し、何を後回しにするのかといった判断につなげられます。
状況に応じて柔軟に対応できるよう、計画の段階から調整可能な範囲を意識し、選択肢を残しておくことが重要だと考えています。
リーダーとプレイヤーのバランスを考える
これまで、プレイングマネージャーとして、実装や設計などの開発業務と並行してチームをリードする役割を担うこともありました。そこで、チームリーダーとプレイヤーの両立について、私の考えを整理してみます。
両立することの難しさ
プレイングマネージャーといっても、求められる役割や責務は組織や状況によって異なると思います。ですが、個人的な経験としては、プレイヤーとリーダーを両立することには、大きな負荷が伴うと感じています。
プレイヤーとして実装や設計に集中する時間が必要な一方で、リーダーとしては技術的な相談やレビュー、状況把握、関係者との調整などにも対応する必要があります。両方の役割を十分に果たそうとすると、体感として一人分を大きく超える業務量となり、心身の消耗を感じることもありました。短期的には必要な局面があると思いますが、長期的に継続していくことは困難であると考えています。
そのため、単に両方の役割を引き受けるのではなく、自分に求められる責務や、どのような形で価値を発揮するのかを考える必要があると感じています。
技術者としての軸を持ちながら、視野を広げる
私自身は、テクニカルなアプローチを通して価値を発揮することを重視しており、今後もプレイヤーとして技術に直接関わる機会を大切にしたいと考えています。同時に、エンジニアリングを改善し、チームとして自信を持ってリリースできるような製品開発を実現していきたいと考えています。
そのためには、個人の技術力だけでなく、チームや組織として品質や開発プロセスの改善に取り組む必要があります。また、そうした活動を通じて視野を広げ、より俯瞰的な視点からエンジニアリングに向き合うことは、自分自身の技術者としての成長にもつながると考えています。
そもそも、マネジメントといっても、その対象は人だけではなく、設計や品質、開発プロセスなど多岐にわたります。技術指向のキャリアを考えるうえでは、マネジメントをする・しないという二分法ではなく、何を対象に、どのような価値を発揮するのか、解像度を上げて考えていきたいところです。
プレイヤーとしての専門性を深めることと、チームや組織への貢献を通じて視野を広げること。その両方を持続可能な形で実現できるよう、今後も自身の役割や関わり方を模索していきたいと考えています。
今後取り組んでいきたいこと
ここまで、開発チームのリーダーとして重視していることを整理してきましたが、自身の課題として感じている部分もあります。今後は、特に次のような観点から知識や経験を深め、チーム全体の開発生産性や品質の向上につなげていきたいと考えています。
品質に対する判断力を高める
特に課題を感じているのは、コードレビューなどにおける品質の判断です。
改善できる部分があったとしても、その場で修正を求めるのか、別の課題として扱うのか、あるいは許容できるものなのか、状況に応じた判断が求められます。
こうした判断を適切に行うために、設計やテストに関する知見を深めるとともに、チームとして求める品質基準やレビューの方針についても整理していきたいと考えています。
開発ワークフロー全体の生産性を高める
個別の技術的な問題への対処だけでなく、開発ワークフロー全体を俯瞰した改善にも取り組んでいきたいと考えています。
実装、Gitによる変更管理、テスト、コードレビューなどは独立したものではなく、それぞれが開発全体の品質や生産性に影響します。
例えば、理解しやすいコードや適切に整理されたコミット履歴はレビューの負担を減らしますし、整備された自動テストは変更に対するフィードバックを得やすくします。
こうした一連の開発プロセスを捉え、部分的な最適化にとどまらず、チーム全体として品質と生産性を高められるようなアプローチを模索していきたいと考えています。
見積りやメトリクスについて知識を深める
開発の状況を適切に把握し、判断につなげるために、見積りやメトリクスについても知識を深めたいと考えています。
不確実性の高いソフトウェア開発において、正確な見積りを行うことには限界があります。一方で、開発状況を客観的に捉え、関係者との認識を合わせるためには、定量的な情報も有用だと考えています。
見積りの精度を高めることだけを目的とせず、開発の状況把握や継続的な改善に役立つプラクティスを模索していきたいと思います。
おわりに
本記事では、これまでの経験を踏まえ、開発チームのリーダーとして重視している考え方やアプローチについて整理しました。
自分自身が開発者として成果を出すことはもちろんですが、チーム全体が円滑に開発を進められるよう、技術的な支援や仕組みづくり、開発プロセスの改善などに目を向けることも重要だと考えています。
私自身は、今後も実装や設計といった技術的な専門性を深めながら、チームや組織への貢献を通じて、より広い視点からエンジニアリングに向き合っていきたいと思います。そして、継続的なエンジニアリングの改善を通じて、チームとして自信を持ってリリースできるような製品開発を実現していきたいと考えています。