エンジニアがプロジェクトを牽引する上でやったほうが良いこと

3月から、久しぶりに受託開発の会社でお手伝いしている田畑です😎

その会社では、リードエンジニアとして個々のプロジェクトにおける
・仕様の取りまとめ
・iOSアプリの設計 / 実装
・メンバーのコーチング
をメインで行っています。

先日、社のSlackで👇のように頼っていただいたので、

サクッと答えられる範囲で回答したのですが、問いを

エンジニアとして参加したプロジェクトをうまく回すためには？

と設定し直すと、答えた以上に色々やっており、やっている内容は受託開発以外にも使える内容だったので、noteにまとめてみました。

まあ、あくまで「私がやっていること」なので得意不得意や、興味関心によって他にもやり方はあると思います。

仕様に関すること

> ユーザーのインセンティブ・モチベーションを確認

仕様を確認していると、「やりたい理由はわかるんだけど、ユーザーがこれをやるインセンティブ・メリットなくない？」というものがたまにあります。

こういった違和感を放置して手だけ動かすのは精神衛生上良くないですし、結局作り直しになることも少なくないので、仕様の違和感は積極的にフィードバックするようにしています。

炎上防止、実作業の段取り

仕様がコロコロ変わることもなく、仕様書も全員が同じものを見ているなら、プロジェクトはそこまで炎上しないはずです。

ただ、そうは言っても小さな炎上や手戻りを発生させうる火種はあちこちに潜んでいます。
それらを早めに検知して、チームが実作業に入る前に解決しておくことも、リードエンジニアがやっておいたほうが良いことかなと思います。

> フィージビリティスタディ > 技術的な実現可能性

仕様やデザインに対して、技術的な実現可能性をレビューしておかないと、クライアントやチームと合意し、いざ実装！というタイミングで「そもそもこれ実現できないのでは？」ということが起こりかねないですし、そこからの仕様再検討/合意にまた長い時間がかかってしまいます。

なので仕様やデザインの段階から首を突っ込み、実現不可能 / または著しく困難なものがないか確認し、あればリスクとして全体に共有します。
よくあるのは以下の3つ👇です。
・やろうとしていることがそもそも技術的に実現できない
・実現できたとしても工数が非常にかかる
・実現できたとしても保守性が非常に悪くなる

> フィージビリティスタディ > 対プラットフォーマー確認

仕様に「これ、ちょっとAppleのレビュー通らないだろうな...」というものがないかチェックし、懸念点を共有します。
(「アカウント作成時の性別 / 生年月日が必須」などはその典型)

Apple Store Reviewガイドラインなどのガイドラインを参照しながら、プラットフォーマーが許容しない仕様を早期に検知し、リスクとして共有することもリードエンジニアがやるべきことかと思います。

> 仕様 / デザイン / APIレスポンスの整合性確認

モバイルエンジニアは、仕様 / デザイン / APIレスポンスを頭の中で突き合わせながら、画面や機能を実装していきます。

この時、全ての資料で整合性が取れていれば良いのですが、「モバイルエンジニアが実装時に確認するレベルの解像度」で整合性を確認できるプロジェクトマネージャー/ディレクターは多くないので、資料が揃った段階で、これらの整合性を確認し、必要があれば関係者に声を掛けてそのあたりの認識合わせを行います(多いのは、デザイン要素とAPIレスポンスの不整合)

> デザインの網羅性確認

👆のタスクと近いですが、エラー表示が起きうる画面において正常系のデザインしか用意されていないことも多いです。

そういった場合、👇のnoteを紹介して正常系以外の状態を意識してもらい、モバイルエンジニアが作業に入る前にデザインが揃った状態にしてもらうようにしています。

開発に関すること

> 開発環境の整備

プロジェクトが始まった時点で、
・CI/CD環境の構築
・Lintの導入
・アーキテクチャ、実装指針の決定

などを行い、プロジェクトのメンバーが、アーキテクチャに従って実装だけしておけば良いようにプロジェクトのセットアップをしておきます。

> ドキュメント整備

2つ以上のプロジェクトにアサインされている場合、👆で決定した内容をいつでもメンバーに共有・教えられるわけではないので、詳細にドキュメント化し、ドキュメントを参照すれば、ある程度作業が進められたり、方向性を確認できるようにしておきます。

また、メンバーがプロジェクトで使う要素技術に疎い場合に備えて、Qiitaの良さそうな入門記事なども見繕い、補助資料として作成しておきます。

> 実装、レビュー、タスクの巻き取り

実装とレビューは、だいたいどこでもやっていることかと思います。

あとは、若い子に設計がなぜ重要かを教えるために
・1回、現状の知識でコードを書いてもらう
・PRレビューで対応できないユースケースを指摘する
・スケジュール内に終わるようならそのPRを採用、終わらないなら巻き取る

として、安定したプロジェクト管理と技術指導の両立できないか色々試しています。

メンバーに関すること

> 技術的な指導

基本的には、PRレビューのフィードバックで行っています。
また、今お手伝いしている会社のSlackでは各々がtimesチャンネルを持っているので、そこを定期的に巡回し、技術的に詰まっていそうであれば、ヒントになりそうなQiitaの記事や公式ドキュメントのリンクなどを貼り、解決を促すようにしています。

> メンタリング

若いエンジニアが、timesチャンネルで自身のエンジニアとしての成長やプロジェクトにおける役割で悩んでいる時は、他のリードエンジニア・テックリードと一緒にアドバイスを行うようにしています。

自己効力感(自分が実際にある物事を遂行/処理することができる、ということに対する自信)の高低がモチベーションやパフォーマンスに大きく影響を与えるということが心理学の研究からわかってきているので、👇の書籍を読み終わったら、メンタリングにも取り入れようかと考えています。

人と組織を変える自己効力

まとめ

リードエンジニアとして、プロジェクトの円滑な運営 / 若いエンジニアの育成を両立させる上で考えていること、気をつけていることをまとめてみました。

何かより良い方法などの知見があれば、教えていただけると幸いです。