🐣

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

2022/02/19に公開約5,900字5件のコメント

はじめに

平下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でのレビュー(今はコードやスキーマ・設計レビューくらいでテストケースまでは見ていないです)
  • その他の障害を取り除く、リーダーシップ → 今も同じ

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

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

弊社ではフロントエンド・バックエンド・CoreAI機能開発のエンジニアを積極的に採用しています。ご興味のある方は下記リンクよりご応募お待ちしております!

https://www.wantedly.com/companies/sweeep/projects

または、まずは開発スタイルなどカジュアルにお話してみたい、という方は下記リンクよりお申し込みください!

https://meety.net/matches/rbuHdLyNfcJc
GitHubで編集を提案

Discussion

この手の話はなかなかお聞きできないので勉強になります。
それで、いくつかお聞きしたいことがありますので、ご返信頂けましたら幸いです。

  1. 半期に1回メンバーにヒヤリングされていたということですが、協力会社の方もですか?
    どうしても協力会社の方にはこの作業をしてもらえればいいという認識でいるため、なかなかそこまで踏み込んで話をすることはありません。

  2. 振り返りなんかはいかがされていましたでしょうか?
    実施されていましたら、いつどんなに形でされていましたでしょか

うちではプロジェクトが終了したら振り返りという形で、よかったこと悪かったことを挙げて次の打ち手を模索する形でやっています。

  1. 見積もりに関してなのですが、見積もりを出す時点ではリリースする日付は決まっていないということでしょうか?
    リリース日が決まっていて見積もり日数が入らない場合は、如何されていましたでしょうか

長文長々とすいません。

コメントありがとうございます!

  1. 当時は人数も少なかった、長年フルコミットしていただいて半分社員のような方々だったこともあり、1on1は業務委託の方も実施していました(毎週していました)。
    現在は人数が多いのと週2や副業コミットの方もいるので社員以外は実施していません。個別に1on1した方がいいな、と思ったときに業務委託の方ともオンデマンドで実施している感じです。

  2. 当時はプロジェクトの振り返りを実施していませんでした。
    現在は隔週でKPT実施しています。現在のKPTの取り組みもそのうち記事化しようと思っています。

  3. 当時リリース日はトップダウンで下りてきていました。工数積み上げて、というよりは事業部長から1年で開発して、みたいなあまり根拠のないもので納得はしていませんでしたが、それでもいかに達成しようか取り組みました(トップダウンだったので調整の余地はあまりなかったです)。
    現在の開発はCEOが大まかな日程を出してきて(リリース希望日で割と現実的)、私がそれに対しスケジュールや仕様の調整(MustとNiceToHaveへわけたり)しているのでやりやすいです。

返信ありがとうございます😊
いろいろ試行錯誤されているみたいで、お聞きするだけで勉強になります。
1on1については、メンバーの成長を考えまして取り入れてみようかと思います。とりあず社員から始めてみます。

根拠のない納期というものは辛いものですね。うちのお客様がコロコロとスケジュールを変えてくるのでなかなか苦心しています。無茶は言って来ないので何とかなっていますがメンバーのモチベーション維持を第一に工夫して行きたいと思います。

KPTの記事が載りましたら読ませて頂きます。

返信ありがとうございます!励みになります!

すでにご存知かもしれませんが、yahooの1on1有名です。こちらに書いてある「聞くに徹する」なかなかできないのですが。。

https://amazon.co.jp/dp/4478069786

クライアントワークでスケジュールコロコロ変わるの辛いですね。心中お察しします。メンバーが開発に集中できるよう苦心されてるのですね。

tech記事も書いていこうと思っていますが、そのうちKPTの記事も書きますねー!

yahooのものは知りませんでした。早速見させて頂きます。
またよろしくお願いします。

ログインするとコメントできます