フロントエンドリーダーを任されて開発に対する意識が変わった

はじめに

• フロントリーダーをやってみて学んだことを忘れないように備忘録として書いておく
  • あわよくば誰かの役に立てば良いな…
  • ちなみに今は別のチームと合併したことで合併先のリーダーがマネジメントをすることになり、マネジメントからは外れてサブリーダー的なポジションに落ち着いている
    • その中で振り返りは今がベストかなと思っている
• 初めてのリーダー案件がめちゃめちゃ学びだったので振り返っていくが良かったので自分も書いてみたくなった

プロジェクトの状況

• スクラム開発で 2 週間で 1 スプリント
  • スクラムと言いつつ納期が決まっている開発が多々あり
  • PO からは新規機能開発優先の意向が…
• 各モジュール(バックエンドやアプリ、自動 E2E など)が分かれている
  • 各モジュールにリーダーがいてモジュールごとにスプリント計画を立てる
• 自分が参画したのは正式リリース直前。参画時点でレガシーコード気味
  • 正式リリースから半年後、フロントリーダーが産休により自分がリーダー担った
• フロントメンバーは人数は上下したが、自分を含め経験者は 2~4 名で若手エンジニアが 2 名

実施したこと・意識したこと

他のメンバーがスムーズに開発できるようにサポートする

心理的安全性を高めて困りごとを聞き出す

• Slack で困りごとがつぶやきやすいようにする
  • 自分から積極的に使い他メンバーの呟くハードルを下げるよう意識した
    • 例えば分報や気になることの呟きなど
• Slack で困りごとを呟いていれば助ける
  • 解決策を提示したりハドルで話を聞く
    • 内容によってはペアプロも良い
  • 逆に自分が呟いていることで他のメンバーからも助けてもらえることもある◎
• レトロスペクティブでも積極的に取り組む
  • 振り返りが出にくくなったら振り返り方法を変えてみる
    • KPT が振り返りにくいという話が出た時は Sailboat Retrospective を提案
• アンケートを実施して不満を聞き出す
  • 開発で時間がかかっていることをアンケートして改善タスクの優先度の参考にした

タスク開始時に他メンバーがつまづかない工夫をする

• スプリント計画に不安なことを聞いておく
  • プランニングポーカーをする時にタスクを始める時に分からなくて手が止まることは聞いて欲しいと促した
    • 例えばデザインの話や例外系テストパターンの相談などが話に上がった
      • 見積もりで困る内容はその場で議論して、タスク実施に詳細が分かれば良い事はタスク実施時に相談するようにして、と分けて対応する

納期を意識して全体を俯瞰しておく

• スプリント計画
  • ユーザーストーリーで仕様や納期感など不明点があれば計画前にあらかじめ関係者に聞いておく
  • 上記にも記載したようにタスク開始時に他メンバーがつまづかない工夫をする
• リリース計画
  • リリース計画ではテストでバグが起きたことも含めて納期感を伝えて達成できる
    • 納期リリースが一番優先度高いという意識をチームで持つよう話しかけた
      • 評価時のバグで重めなものは他メンバーと一致団結し協力して問題に取り組んでリリースに間に合わせたこともある
  • リリース計画では他モジュールにも気を配る
    • 他モジュールとの結合確認や同時リリースなどあれば他のモジュールも加味して計画する
    • (全体で音頭を取るメンバーがいなかったように思うので自分が意識的にやっていた)
  • 納期が厳しい場合はスコープを絞る提案をして絶対にリリースできるようにする
    • 小さく作って試すことで顧客に本当に必要か見極めるのが良いという話を出して納得してもらう方法で調整した
      • ただその判断には顧客の要望を聞いて削っても良いかの判断が大事

学んだこと

視座を高くもてるようになった

• チームとしての成果を高めるには何をしたら良いか考えて動くようになった
  • 一人の開発スピードは高が知れている。チーム全体の成果が高いことが大事
• サービスが売れるために何を優先させるか、QCDのどれを諦めるか調整の大切さを知った

心理的安全性を高いことの大事さを痛感した

• チームがスムーズに開発を進めるには困りごとを解決するのが大事だが、そもそも困りごとがわからないと辛い
• 困りごとを吐き出しやすい環境は大事
  • レトロスペクティブや Slack で自分の話を出すことで自分も話していいのかなと思ってもらえるようにしたのは良かった
• 静かなメンバーも多かったのでアンケートなど答えやすい仕組みを作るのも有効だった

他メンバーができることを把握することが大事

• 把握しておけば誰かにフォローを頼める
  • 開発もマネジメントも両立させていたためメンションがたくさん来て答えるのが遅くなる場面が多かった
  • 答えられそうなメンションは他のメンバーにお願いした

分からないことに対して調査する方法を把握しておく

• 他メンバーもわからない場合も多かったので調べる事は多かった…
• 調べ方を模索した
  • 最近は ChatGPT や copilot などAIでとっかかりを得ることも良い。ただ鵜呑みにせず裏付けを調べることも大事
  • 別テーマにいるエンジニアに聞いたり、社外のイベントを見たり一般的な技術質問は社外に質問したり、手札を使えるだけつかった
• 見積もりとして調査タスクをもらうことも忘れずに

反省

• リファクタや改善より機能リリース優先にしてしまった
  • POの要望もあって機能リリース優先で動いてしまい、レガシーコード解消がなかなか進まなかった
    • 改善を毎スプリント 10~20% とっていたが、リリース前になるとスキップしてしまった
  • 全体の対応優先度を冷静に俯瞰で確認すべきだった
    • 10~20% で収まるタスクをとってしまいがちになっていた
    • 今もレガシーコードで苦しんでいるので、もっと上手く進められたのではと後悔
• マネジメントや他メンバーフォローに工数が取られて開発工数の確保が厳しかった
  • 調査や調整など面倒ごとは引き受けて他メンバーに開発に集中してもらうようにしていた
  • 学習も兼ねて他メンバーへ調査から実施するようタスクを振っても良かったのかも
    • 時間はかかるので調整が必要
• 属人化解消を後回しにしてしまった
  • 今メンバーが抜けてしまい苦しい状態になってしまった
  • メンバーの増減は早めにしれるのが理想だが、開発と並行して属人化解消は徐々に行うがベスト
• フロント開発以外のタスクを取りすぎてしまった
  • 自動E2Eの環境構築や問い合わせの改善対応などもやっていた
    • 特に問い合わせ対応改善は自分の工数 10~20% でも掛け持ちしていたがなかなか進められていなかった
  • 新しいことを学ぶのが好きだったので苦ではなかったがフロントの人数が減ったこともあり自分に属人化してしまい手が回らなくなってしまった
  • 開発はモジュールで分かれているので役割と離れている内容は委譲する
    • 自動E2Eの環境構築は自動E2Eチームあったので別チームに任せても良かったなと反省
• 自分の実力を見極めて有識者にヘルプを出せば良かった
  • 調査すればできるが時間がかかってしまったり有識者よりは質が落ちてしまう
  • 重要度に高い機能は特に有識者にレビューでも良いから入って貰えば良かった

感想

• リーダーを経験したことでチームとして最大の成果を出すことの大切さを痛感
  • チームとしての成果を高めるにはどうしたら良いか自分なりに考えて動いたつもりですが、まだまだできる事はあったかなと思う
• ただリーダーになったからこそ意識を変えることができたので経験できたことに感謝