初めての開発チームリーダーとしてプロジェクトを成功させるためにやったことリスト

はじめに

平下CTO@sweeepです。前に依頼されて書いた開発リーダー・プロジェクトマネジメントの記事をリメイクして載せます。

---

新卒で入社した日系の医療機器メーカーでは制御ソフトエンジニアを担当していました。
その制御ソフトチームでいずれ会社を背負って立つと言われていた優秀な先輩が2人いたのですが、1年ぐらいの間に2人とも立て続けに退職し、急にチームリーダーをしなければいけなくなりました。そのときのことを思い出しながら書いてみます。

当時チームの規模感は社内のエンジニア3名、ベンダーのエンジニア4名、テスター1名の計8名ほど、部門全体で8チーム計100名強、大型の医療機器を開発していました。その当時5年目、20代でチームリーダーとしては部門最年少でした。強いプレッシャーを感じていたのを覚えています。

組み込み系のエンジニアのため、オープンなWebの世界とは違ったり手法も古いものもあるかもしれませんが、チームリーダーになったばかりの方の参考になるところがあれば幸いです。

ビジョンや情報の共有 ー 日報は必要？

会社や部門がどこを目指していて、それをブレークダウンしてグループとしてはどんな役割、方向性を目指しているか、というビジョンの共有は大事にしていました。そのためにプロジェクトキックオフや週一の定例を実施していました。

また、チームとして周りの人はどんなことをやっているのか、情報共有するために週報を出してもらい、毎週の定例のアジェンダにまとめて共有していました。また、後述する週一の面談の材料へも活用していました。

正直日報までは必要ないかと思っています。そこまで見きれないのと、日報書かせたい人はそこまでしないとメンバーが仕事をしないんじゃないかと思っているかもしれませんが、やらない人は日報コピペするだけだし、やる人は日報書かなくてもやる人だと思います。

やっぱり1 on 1（面談） ー メンバーの困り事を把握する

週一の定例の後にそれぞれのメンバーと面談をやっていて、とても大事にしていました。今風だと1 on 1ですね。協力会社さんのベテランエンジニアの方にも協力していただいたので、その会社のリーダーの方と同席してもらう形で面談していました（準委任契約だったので）。

そして毎回ヒヤリングすることは、先週どうでした？ということと、今週はどんなことをやる予定ですか？ということ、何か困ったことありませんか？という3つです。そのときに先週の週報を参考にしていました。

また節目の半期に1回などのタイミングで、今後どんな技術を身に付けたいか？とか、どんなことをやりたいか？とヒヤリングして、組織の方向性や個人の方向性・希望がうまく一致する様なタスクを割り振ったりしていました。必ずしもピッタリ合致しているタスクがあるわけではないですが、自分でできる範囲の努力はしていました。

自分の仕事よりも優先すること ー メンバーの仕事の障害を取り除く

そしてその面談の時に聞いたメンバーの困っていることを解消する、メンバーの仕事の障害を取り除くことに関しては最優先事項としていました。そうしないとメンバーのアウトプットが出ないので、自分の仕事をいったん横に置いておいてでも取り組んでいました。

たとえば、他部門とスケジュールなど調整したり、リソースの調達など ー 人や物など実施し、リーダーとしてメンバーの出来ない障害を取り除くことに重きを置いてました。

他チームとどう連携するか ー 他チームとのInterface部分は常にリスクとチャンス

制御ソフトはユーザインターフェイス（UI）からパラメーターをもらって、それを受け取ってユーザの期待する結果を得るために、それぞれのハードウェア（HW）へ分配する、全体の制御を担っていました。

その性質上、常にUIが完成するまでとか、またはハードウェアが完成するまでその間のInterface部分ができていないため全体の流れの実装・テストの確認が遅れてしまいがちでした。

それを回避するためにUIシミュレーターやHWシミュレーターを作成しました（擬似的にパラメーターを出したり受け取ったりするもの）。そうすることで制御ソフトチームだけで実装・テストを進められました。また、このシュミレーターは他のチーム、たとえばハードウェアの動作確認とかUIのパラメーター確認とかそういったところにも使われて、結果的に開発全体のスケジュール短縮へ貢献できました。

Feasibility Study(FS) ー リスクの高いタスクからチームとして取り組む

前述した通り、他チームとのInterface部分のリスクが高いので、まずはそこをシミュレーターなり使用して全体の動作確認を通す（シーケンスを通す）ことを最初の半年位の目標に置いていました。

そのためには必要なツールとかシミュレーターを用意し、2週間とか1ヵ月単位で開発の初期にそれぞれのInterface部分や全体の流れの動作確認をする、Feasibility Study(FS) ー 実現可能性の検証を重視していました。全体の大まかな動作が確認できれば後は細かいところ作り込めば良いので、後は洗い出したタスクをコツコツやるだけの状態を作り出して進めました。

それまではUIやハードウェアなど揃って、設計→実装→テストという風にウォーターフォール的な開発をしていたんですけど、先に2週間から1ヵ月位でアジャイル的にリスクの高いところから確認しながら徐々に作り上げていく進め方で、かなりスケジュール短縮できたなと実感しています。そうでないと、いざ実装やテストなど後工程の段階で思わぬ障害が出た場合や予定していた技術が使えなかった場合など、手戻りが発生してスケジュールが大幅に遅延するリスクがあります。

スケジュール調整 - チーム内では見積の1.5倍、チーム外では見積の2倍

スケジュール調整はメンバーに見積もりをどのくらいかかりそうか？まずは確認し、大抵最短の日程を提示されるので、それ対してバッファーを1.5倍位のスケジュールでチーム内の開発スケジュールを引いていました。

なぜかと言うと必ず開発の途中では不測の事態が発生することが多く、それに対応するための工数の余裕を見るためでした。

また、他チームへ工数見積を出すときは、対外的にはメンバーの見積もりの2倍ぐらいで提示していました。スケジュールが遅れることに対しては、メンバーやチームへの評価を下げやすいからです。逆に出した見積に対し早く終わるとメンバーやチームへの信頼や評価が高まるので不確実性の高いプロジェクトほど、そうしていました。

2倍というと盛りすぎな気がしますが、たとえばエンジニアに聞いて3日でできます、と言われた場合は内部のスケジュールは5日ぐらい、対外的には2週間ぐらいで引いていました。結果的に見積が正確で遅れない、と評価されていました。また、当時はハードウェアが新しいデバイスに刷新されていたため技術的課題が多く、どうしてもバッファーを多く取る必要がありました。確実性が高ければもっとバッファーは少なくてもいいと思います。

結果として、他チームより残業少なくそれでも開発のスピードも部門をリードするぐらい早かったと思います（どうやっているの？と不思議がられていました）。

レビュー ー ソフトウェアの品質を守るために

ソフトウェアの品質を守るために、自身とメンバーのレビューをすべて実施していました。基本的に私が設計した仕様の説明・レビューを実施して、メンバーにその成果物、コードやテストケースといったものをアウトプットしてもらっていました。

レビューの方法は成果物を、作成した人自身で準備して説明するウォークスルー方式でした。コードは仕様の該当箇所を前回の差分からピックアップして説明する形です。今ではGitHubのCommitの差分などでレビューしやすいと思いますが、当時はDFソフトなど使ってフォルタとかファイルの差分を見ていました。

また、レビューアーとして手元にレビュー用のチェックリストも用意していました。たとえば、テストケースでは境界値分析や同値分割といったセオリー通りバグの多い領域を確認するケースが含まれているか、大数の法則的なテスト、既存の処理に影響与えていないか退行テストといったケースが含まれているか、等。設計仕様書・コード・テストケースの徹底的なレビューでソフトウェアの品質を守っていました。

トップダウン/ボトムアップ型リーダーシップの使い分け

開発立ち上げのころは手探り状態なので、そこは意識的にチームを引っ張る ー トップダウン的なリーダーシップを心がけていました。トップダウンという言葉のイメージがあるかもしれませんが、上から指示するというよりはグループとしての方向性を示して、具体的にメンバーのタスクまで下ろしたりやり方を示したりする ー 皆の先頭切って走るイメージです。

ある程度開発の先が見えてきて各メンバーのパフォーマンスが出るようになってきたら、メンバーのアイデア・考え、やり方を推奨・支援するスタイル ー ボトムアップのリーダーシップで進めていました。

個々のメンバーに関しても協力会社のベテランエンジニアさんには、やりたいことを開発で実現するための技術的な相談をするスタイルでした。また、3年目〜のひととおり経験した中堅エンジニアへは思い切って重要なところを任せることでさらなる成長を期待していました。一方、3年目未満のエンジニアはどういうふうに進めるか細かく指導する必要があると思います。

良かったこと ー メンバーやチームが成長する喜び

最終的に部門全体の開発をリードし、予定通りプロジェクトを終えることができました。

それよりも良かったことは1つのプロジェクトを通して各メンバーが成長し、その集合体のチームが成熟してチームとしてパフォーマンスが出ていることにリーダーとして喜びを感じました。

また、3年目〜の中堅エンジニア ー 伸びしろがあって成長曲線の入り口にある状態へ、思い切って重要な仕事を任せると思わぬ成長をするんだな、ということを学びました。

失敗したこと ー メンバーを怒ってもプロジェクトは進まない

ちょっとメンタル弱めのベテランエンジニアが体調不良で2週間ぐらい離脱したことでプロジェクトが停滞し、焦ってそのことを面談の時に咎めたことは失敗だったな、と思います。今思い返すともっと適切な対処の仕方があったんじゃないか、と今は反省しています。
開発のキーマンに属人化しない様な仕組み作りなど。たとえばコードがドキュメント化されていなければ中堅エンジニアにリバースエンジニアリングでドキュメント作成お願いするなど。メンバーを怒ってもプロジェクトは進まない、起きた問題に仕組み化して対策することこそ必要かと。

もう1つは、チームの~3年目ぐらいの新人の指導をあまりに忙しくて細くできなかったことです。当時そこまで手が回らなかったのですが、申し訳なかったな、と思います。

まとめ

ここまで色々と自分が実施した施策を話しましたが、正直な話全部がうまくいったわけではないですし、いくつかの施策（週報や面談、シミュレーターなど）は先輩がすでに作った仕組みを流用し、自分なりにアレンジした結果だったりもします。

振り返ると失敗とか辛かったことも多かったですけど、個々のメンバーが成長し、個々の力1+1=2でなくそれ以上のパフォーマンスをチームとして出せる状態というのはこんなに楽しい事なんだな、と実感しました。またメンバーの成長というのも、自分にとって嬉しいものなんだな、と思いました。

もしチームリーダーをする機会があり、引き受けようかどうか迷っている方がいましたら思い切ってやってみたらどうでしょうか？例え失敗しても得るものは大きいと思いますし（私もたくさん失敗しました）、失敗したからといって取り返しがつかなくなるとか、命を取られるほどのプロジェクトはないと思いますので。

---

終わりに

現在はWebサービスのCTOを担当していますが、手法やツールは違えど、意外と基本は変わらなかったりする印象です。以下現在のWeb開発に置き換えてみました。

• ビジョンや情報の共有　→　MVVやスプリントレビュー・定例
• 面談　→　1 on 1
• Interface部分の開発やシミュレーター　→　スキーマ駆動開発やMock
• FS・スケジュール見積　→　スクラム開発
• レビュー　→　GitHubでのレビュー（今はコードやスキーマ・設計レビューくらいでテストケースまでは見ていないです）
• その他の障害を取り除く、リーダーシップ　→　今も同じ

あと、チームとしての成果やメンバーの成長が嬉しいのは変わらないですね。

ここまで読んでいただきありがとうございました！