この記事を書く目的と背景
筆者はSIerで働く、新卒3年目のSEになります。昨年度（新卒2年目）から社内アプリ開発PJのPLとして働いていたので学んだことをこれから初めてマネジメントを行うような方に向けて、また個人的な備忘としてまとめます。
PJ概要
先にPJの概要について軽く説明します。
PJの時系列
PJの時系列は以下になります。
小規模アプリのため、要件定義・基本設計は２週間程度で終え、詳細設計と製造に入りました。この時はPJメンバーが私だけだったということもあり、詳細設計と製造は同時並行で行いました。その後、単体テストから後輩（新卒1年目）がアサインされ、単体テスト・結合テスト、総合テストは3人で進めました。
PJ体制
まず、私の上には上司がいますが、上司はめちゃめちゃ忙しいので、基本的には自分で全て考えることになります。週1で進捗報告を行うことと、たまに技術選定などでアドバイスをもらうだけです。
私のスペックとしては、新卒2年目でもちろん今までリーダ経験はありません。当時は開発経験も学生時代のエンジニアインターンの経験と個人開発くらいしかありませんでした。（1年目の時は、ずっとテストの打鍵ばっかやらされてた
）ただ、個人で作ったアプリを上司に評価され、PLに任命されました。
単体テストからアサインされた後輩2人は非情報系出身で新卒1年目、入社してから初めてプログラミングをしたというタイプです。ただ、すでに１案件を経験したので軽いフロントエンドの経験があるのとGitについても基本的なコマンドは使用できるとのことで助かりました。
各工程で行ったこと
要件定義・基本設計
最初は「こんなアプリ作って欲しい」くらいの軽いノリだったので、要件についてヒヤリングしながらアプリの機能の洗い出しと画面モックを作成しました。機能一覧と完成イメージを上司に見せて、指摘をもらい修正してはレビューしてもらうという流れでした。機能自体もそこまで多くなかったのでここは２週間弱でとっとと終えました。社内のPJということもあり、きっちりしたドキュメントなどの作成も求められず、設計書といった設計書は作成していませんでした。今思い返すとやはりこの部分をもう少し丁寧にしておくべきでした。
詳細設計〜製造
この時はまだ私しかPJメンバーがいなかったので、詳細設計と製造については同時並行で進めました。
技術選定
このPJに関することは全て任せられていたので、技術選定も経験することができました。フロントエンドはAngularとAngularMaterialを使用しました。AngualarMaterialは最初からリッチなデザインが準備されており、デザインを考える上でとても良かったです。
APIについては実行環境をNode.jsでフレームワークはExpressを選定しました。DBはPostgreSQLを使用しました。
将来的なDevopsの観点から、Dockerを使ってコンテナ化しようかとも思いましたが、Dockerを使用するにはDockerDesktopが必要で、これが一定規模以上の会社で使用するとなると有償とのことで諦めました。
もちろん代替策でPodman等のサービスを検討しましたが、導入に思ったより工数がかかりそうだったのでやめました。
製造
バックエンドの開発経験は多少ありましたが、フロントエンドを触るのは初めてで最初はとても苦戦しました。Angularを勉強する中で詰まったポイントはまた別途記事を執筆したいですが、特にngOnInitとかngOnChangesといったライフサイクル周りとRxJSですね〜
ここら辺の記事を大変参考にさせていただきました
また、今まで個人開発では「とりあえず形になればいい」「動けばいい」ぐらいのクォリティでしたが、もちろん企業で使用するアプリとなるとそういうわけにはいかないので、みっちり勉強して実際に開発して勉強になりました。具体的には以下のような観点です。
実装する際にめっちゃ考えたこと
- アーキテクチャ
- 認証関連
- ログ管理
などなど
運用のことも考えてどんなアーキテクチャを採用して開発を進めていくのか、認証の仕組みはどうするのか、認証キーはどこに保管するのか、ログにはどんな情報を含めるのか、何日保管するのかなどなどあげればキリがありませんが運用面も考慮していろんなことを設計することはとても楽しかったし、勉強になりました。ここら辺は再度別の記事でまとめようと思います。
テスト
単体テストから、後輩2人がアサインされ、やっとPJっぽくなってきました。特にフロントエンドの単体・結合テストに関しては、色々と試行錯誤しましたのを下の記事にまとめてますので興味あれば見ていただけると嬉しいです！
振り返り
前置きが長くなってしまいましたがここからは私が初めてPJを経験して学んだことを共有できればと思います。
良かったこと
（当たり前だけど）PJをよくするための試行錯誤をめっちゃするそれを実現するためには常に勉強する
一応私の上に上司はいましたが、上司はめちゃめちゃ忙しくて、逐一私にかまってられないので基本的には自走することが求められました。そこで、当事者意識を持って、未経験の領域でもGoogle、ChatGPT、X、Youtube、社外の勉強会への参加等あらゆる手段をフル活用して基本的に全て自分で調べて実現できたことは上司からもとても評価していただけました。またこれを実現するためにはもちろん業務内だけでは時間が足りないので終業後土日も関係なくキャッチアップしました。（本当は業務内で完結できるようになればいいんですけどね 
）具体的に何をやったのかをここで共有できればと思います。
未経験の領域でも自分なりに調べて自走できた
具体的な取り組みの前に、まずは「なんでもビビらずに挑戦して自分で解決するスタンス」が良かったかなと思います。例えば今回初めて経験したことはこんなにあります。
今回初めて経験したこと
- 要件定義~リリースまで
- 技術選定
- アーキテクチャ設計
- フロントエンド開発
- （ちゃんとした）API設計、開発
- セキュリティ面の考慮
- インフラ構築
- テストの全体設計（フロントとAPI）
- テスト自動化
- リリース
- 運用ルール策定
などなどあげればキリがありませんが一つのサービスを企画してリリースするまでに必要なことは全て経験しました。自分で勉強して、調査して、実践して、相談してを繰り返してなんとか形にすることができました。
特に途中からメンバーが追加されてからは私の指揮次第でチームのパフォーマンスが全然変わるので常に「何か改善できることはないか」と考えていました。ここでは私が取り組んだ中でも効果が高かったTipsを共有できればと思います。
コーディング規約の作成
運用面を意識して、「できるだけ綺麗に書こう」と意識していたので、それを文書化して共有しました。結果として、コードレビューでそこまで指摘しなくてよく工数の削減につながりました。
プルリクフォーマットの活用
コードレビューをする際に書き方が統一されていなければレビューがやりづらかったのでプルリクフォーマットを導入しました。
テストの進捗改善
具体的な取り組みについては以下の記事に書いていますので見ていただきたいです。
フロントエンドテストの進め方について1から勉強して、フロントエンドテストの進捗が悪い時に、どこにボトルネックがあるのかを常に考えて「どうすればテストの進捗が上がるか、テストがやりやすくなるか」を常に考えて続けていました。
タスクや情報の管理を一元化
Gitでイシューを管理していましたが、Teamsで資料等は管理していたので、全部Teamsで一元管理しました。
新人教育
新卒1年目の後輩が単体テストからアサインされたので教育をすることを心がけました。後輩が以前所属していたPJのリーダーに、「どんなところでつまりやすいか」「どれくらい自走できるか」「コミュニケーションの取り方」など後輩の仕事ぶりの話を聞いて、できるかぎり仕事がしやすい環境を作るように心がけました。私が1年目だった時に、上司に「こうして欲しいな」と思ったことを全部実践できたかなと思います。具体的に行ったことは以下です。
PJ初期には資料を展開
私もAngularについては今回初めて勉強したので、参考になった記事やわかりやすい動画教材などは自分なりにまとめていましたので、展開しました。またエラーに詰まった時に解決方法をナレッジ化しているのでそれを横展開することでエラーなどで悩む時間を減らすことができました。意識的に自分の持っている知識は全て共有することを心がけました。
聞きやすい雰囲気作り
PJが遅れてもメンバーには険悪な雰囲気を出さずに、いつでも聞いてねスタンスでいることを心がけました。こちらは良かったようで、後輩からも「質問する時のハードルが低く聞きやすかった」と言われたのが嬉しかったです。また、この雰囲気作りによって後輩からも「こうした方がいいのでは」という意見が出てきて結果としてPJ全体が好循環になりました
コードレビュー
基本的には全てのコードに関してコードレビューを行いました。私もまだまだ勉強中の身ですが、後輩からも「勉強になった」と好評でした。
初期は教育コストがかかりますが、初期にまとまった時間を確保すれば（タイプや能力にもよりますが）ある程度は自走してくれるようになります。そうすれば自分のタスクをメンバーに任せることもできて、自分も楽になりますし、自分にしかできない仕事に集中することができます。しっかりコードレビューを行えばバグを生み出すリスクも最小限ですみます。また、自分が教えることで自分の理解も深まると教育をするのはいいことしかないので、教育はこれからも意識的に行っていこうと思いました！
PJ初期のマイクロマネジメントの実施
マイクロマネジメントというワード自体はあまりいい文脈で語られることはないように感じてますが、「メンバーのタイプ」と「どの段階で実施するか」によってはそこまで悪くもないと思ったので共有します。ちなみにマイクロマネジメントとは以下のようなものです。
私が行ったマイクロマネジメントは以下になります。
PJ初期
- 毎日午前中と午後で1回ずつは絶対進捗をする機会を設ける
- 時折、こちらから状況確認のチャットを投げる
- タスクの抱え込みを防ぐために質問するタイミング(ググって〇時間わからなかったら聞いてね) を指示する
PJ中期
- 進捗状況をグラフ化した。また1日あたりのテスト消化件数のノルマを設定
PJ中盤〜後半
・ほとんど進捗確認は行わずにテストの実施件数と発生したバグだけを確認
このようにPJの初期のみマイクロマネジメントを実施しました。誰でも経験があると思いますが、PJ初期は環境構築で詰まったり、既存ソースの読み込みをする際にどこを読めばいいかわからなかったりすることが多々あると思います。それもあってPJの初期段階では記載の通りのマイクロマネジメントを実施しました。PJ終了のタイミングで「どうだった？？」と後輩に聞きましたが、逆に質問しやすかったり、タスクが全然進まないみたいなことがなくて良かった』との声をもらえました
（気を使われているのかもしれませんが。。）
逆にPJ中期以降はほとんど行わずに、後輩の自主性に任せて、進捗報告だけ確認するような形になり、こちらとしても工数削減になりました。
改善点
次に次回は絶対改善したいことを共有します。
面倒なことを後回しにした
PJを進めていく中で後回しにしたいことはたくさん出てくると思います。例えば、「このようなアプリ構成にしたいが今扱ってるシステムで実現できるかわからない」「他部署との調整が必要だが、一旦保留にしよう」などです。もちろん後々それらを対処する方が効率が良いこともありますが、あまりに先送りにしてしまうと面倒なことになることもあります。今回の私の例で行くと以下のようなことがありました。
後回しにしたこと
- ネットワーク関係、セキュリティ関係でタブレットの準備にいろんな審査を通す必要があるので一旦後回しにした
- 他部署との連携が必要な実装箇所を後回しにした
今回開発したシステムはタブレットを使用するのですが、タブレットを準備するとなると、色々な審査を通さなければなりません。ただ、これを後回しにしたことで少々面倒なことになりました。
また、メール送信機能の実装で他部署との連携が必要な箇所がありましたが、後回しにして、それ以外の機能の実装が終わったタイミングで連携しました。結果、色々アドバイスもらえてもっと早い段階で聞けば良かったなあと後悔しました。
仕様書がほぼなかった
今回のPJは
- 納期まで期間がない
- 途中からメンバーが追加される予定がなかった
という理由より、製造〜テスト段階では、ほとんど仕様書を作成していませんでした。その結果起きた問題は以下のようなものです。
起きた問題
- 仕様をきっちり詰めきれてなかったので、後々仕様が追加される
- メンバーが入ってきた時に、仕様書をみて理解することができないので毎回説明しないといけない、もしくはソースコードを読んで理解してもらう必要がある
- フロントとAPIでの連携がうまく取れない箇所が多々あった
要件定義段階で完成イメージについては共有できていたものの細かい仕様が詰めきれていない部分があり、「これも追加してほしい」という現象が多々ありました。仕様書を作成していれば細かい部分を上司に確認してもらえたので、これは仕様書を作成していなかった私の問題です。
また、一番の問題は追加メンバーがアサインされた時に仕様書がないので、毎回「この機能はこんな機能です」という説明を20分程度する必要がありました。これが仕様書を作成しないことによる問題で一番工数がかかった箇所になります。
また、製造はほとんど私の方で行いましたが、小さな機能の追加はメンバーに任せることもあり、その際にフロントとAPIの分業体制で行なっていたため、フロントとAPIの連携がうまくいかない箇所が多々ありました。この当時は詳しく知りませんでしたが、OpenAPI形式で仕様書を作成しておけばこの問題は防げたかなと思います。
状況に応じたテスト戦略がたてられていなかった
詳細はこちらの記事を執筆していますのでみていただきたいです。
テスト実施者のスキルレベルや開発とテストの実施状況に応じたテストを実施するべきだと学びました。
タスクを開示しなかった
プロジェクトに関するタスクは個人で管理をして、それをチームに開示していませんでした。メンバーにタスクを振って、終わり次第、私が個人的に管理しているタスクの中から、次のタスクを選んで振るという流れで進めていました。ただ、この方法だとメンバーから「あとどれくらい作業が残っているのかという全体像が見えづらい」との声を聞きました。こちらが作業を振るのではなく、タスクを開示して自らタスクを選んでもらうという方法でもメンバーのモチベーションの観点から良かったかなとも思いました。
まとめ
今回初めてPLをやってみて想像以上に難しく楽しかったです。個人的には私の指揮次第でこんなにもチーム全体の生産性が変わるのかというのが体験できて、これからどんどんリーダ経験を積んでいきたいと思ういい機会になりました。社内PJでたくさん失敗体験が積めてほんとに良かったなと思います。今年は3年目でリーダ経験もたくさん積めると思うので、今回のことを次に活かしてつよつよエンジニアになっていきたいです！！最後まで読んでいただきありがとうございました！