プロジェクトを炎上させないためのリードエンジニアの存在

はじめに

株式会社Relicでバックエンドエンジニアをしております臺 健太郎(だい けんたろう)です。

株式会社Relicでは、新規事業開発に取り組む機会が多くあり、自分もこれまで多くの新規プロジェクトの立ち上げに参画してきました。

その際に、いわゆるリードエンジニアのポジションとして参画させていただくことが多くあり、自分が果たすべき役割や職責についてずっと、深く考えてきました。

今回は、主に、自分自身が開発初期、もしくは、リリースしてグロースを目指すというフェーズにあるプロジェクトにアサインされた経験から、そのフェーズにあるリードエンジニアがどういうことを意識すればいいのか考えたことを発信します。（あくまで自分自身が理想的に立ち回れているかは無視しています。また、大企業が扱う有名プロジェクトや、グロースしきったビックプロジェクトのリードエンジニアとはまた役割が違うかもしれないのでご了承ください。）

それでは書いていきます！！

リードエンジニアとは

この記事では、リードエンジニアとは、ある一つのプロジェクトのエンジニアチームのリーダー的な役割を果たす人間として定義します。

チーム内のリードエンジニアは誰なのかを明確に設定する

いきなり当たり前の前提の話にはなるのですが、リードエンジニアは誰なのかチーム内で指名することが大事です。

実際、PO、PjM、マーケティング担当などは役割としては、はっきりしていることが多いですが、エンジニアチーム内のリードエンジニアというポジションが不明確なこともあったりしました。

特に少数精鋭のチームでは、プロジェクト立ち上げの中でエンジニアチーム内での役割が雰囲気で決まってしまって最終的な責任を誰が追うのか不明瞭だったり、方針の決定者が曖昧になったままスタートしたり、チーム内のメンバーの入れ替わりにより責務が曖昧になったりと言ったことが初期フェーズでは起きてしまいがちです。

曖昧になってしまうと、お見合いタスクが増え、悲惨なことになります。

なのであえて、書いていますが、きちんと、どんな小規模プロジェクトでもリードエンジニアは誰なのか明確に決めましょう。

プロジェクトを炎上しないための具体的なリードエンジニア像

一般的に認識されているリードエンジニアのタスクは以下の感じなのかなと思っています。

• エンジニアチームのメンバーエンジニアが書くコードの品質担保についてコードレビューなどを行い責任を負う

• システムの設計やアーキテクトの最終的な決定をする

• タスクの進捗についてのスケジュール管理を行う

では、それ以外に何をすれば良いのかを具体的に書いていきます。

• 担当領域以外の部分も基本的なことはある程度カバーできる存在

  • 例えば、担当領域は、サーバーサイドエンジニアだけど、インフラ領域・フロント領域や、その他境界タスク(繋ぎ込みなど)は調整して自走できるなど、自分の担当領域以外でのトラブル発生時なども問題の切り分けをして対応できると理想的

  • リードエンジニアはプロジェクト全体の技術的な部分を網羅的に把握し、全ての領域について調査してある程度自走できると良さそう

• 実装方針（設計含む）を決めタスクを振る

  • 自らは一番ややこしい実装や、職務領域をまたがる実装を率先して担当（面倒くさそうなタスクやこぼれやすそうなタスクも全て拾う）

• タスクの優先順位を明確に決める

  • クライアントからの要求仕様などをタスクに落とし込み、システム安定性の観点から適切に優先順位づけ

  • スプリントの途中で優先順位がコロコロ変わらないようにしなければならない

  • 誰がいつまでに何をどのようにやれば良いのかを明確にしなければならない

• 時折来るクライアントからの無理な要求タスクを適切に捌く

  • 要求された仕様が無茶な要件だった場合などに、要求仕様をシステム安定性の観点から適切に断ったり代案を提案したりする

  • 常に「その機能本当に要ります？？」という姿勢で考えることが大事

• タスクの工数見積もりを適切に行う

  • 工数見積もりを体感の1.5倍程度で見積もることができ、安易に請け合うことはしない

  • 安直にできますよと言って遅れたりできなかったりした方が信頼を損なうことに

• 低レイヤーで無理なことをしない設計を常に意識する

  • なるべくアプリケーション側やフレームワークに沿った実装を基調とし、無理に低レイヤーでハイリスクなトリッキーなことをしないようにし、そう進みそうなら食い止めることが必要

  • ここでしくると、巻き返しがむずかしく炎上必至へ

• 適切なDevOps構築を主導

  • CI/CDの構築

  • 本番リリース前にバグに気づくことができるような手動テスト体制を構築

• ブランチ管理を適正にリード

  • CI/CDと紐付けてブランチ運用のスキームを決める

  • シンプルでいいがドキュメントにしてルール化しておくと良いかも

• コーディングルールの大枠は定めておく

  • レビューで変に軋轢を生まないようにある程度決めておきたい

炎上しないチーム作りについて

リードエンジニアとしてアサインされた人がエンジニアチーム作りをしていく上で抑えておくべきポイント

• メンバー内のコミュニケーションコストはできるだけ低くくする

  • 特に,フロントエンドとバックエンドとデザインのコミュニケーションコスト、リードエンジニアとPjMのコミュニケーションコストが低いことは最重要

    • 例)

      • open apiをモックとして使えるよう共通ドキュメントにする

      • ハドルMTGなどを活用した「ちょっといいですか？」コミュニケーションetc

PjMとの業務領域を明確にすることについて

• 小さいプロジェクトだと特に、PjMとリードエンジニアの境界が曖昧になりがち

  • PjM寄りっぽいリードエンジニア、テックよりのリードエンジニアの2パターンが存在しがち

  • PjMなのかリードエンジニアなのか役割は明確にしないと、PjM的な動きもエンジニアリングもするというかなりきつい状況になってしまう

最後に

自分のイメージでは、リードエンジニアになるといろんなタスクが増えて、コードが書けないとか、技術を追求する時間がなくなるとか、よく人そう言った話を見聞きしたりしますが、経験としてチームを率いる体験というのは、やっていて損はないなと思っていたりします。

かく言う自分も、技術は好きなので、なんとか時間を作ってゆっくりのペースですが、常に知見の積み上げを頑張っているので、ぜひ、思い切って実装だけではない色々な経験に舵を切るエンジニアが増えてくれればと願っています！（頑張ってQiita記事も書いてます。https://qiita.com/Dai_Kentaro）

ps. 偉そうに色々講釈垂れましたが、未経験から入った実務経験2年のひよっこエンジニアなので悪しからず。。