ID:74564さん

## プロジェクトの概要 健康増進を目的としたWebアプリケーションの受託開発プロジェクトでした。 既存のWebアプリケーションがあり、それをLaraverlで作り直すプロジェクト。 開発メンバーは25名。 要件定義から保守運用まで行いました。 ## 自身の役割 開発チームのリーダーを担当しておりました。 チームの規模は私を含めて6名。 日々の進捗管理、コードレビュー、メンバーフォローなどを行なっておりました。 ## 自身が発揮したバリュー この案件が初めてのリーダー業務だったこともあり、あまりバリューを発揮できなかった案件でした。 しかし、この失敗からさまざまなことを学ぶことができました。 ### 進捗管理 この案件時の私は「進捗管理」ではなく「進捗確認」しかできていなかった、と今は感じます。 進捗を管理しているわけではなく、毎日夕方にメンバーの進捗を「確認」するだけでした。 何が問題だったかというと、メンバーそれぞれが自分の尺度で進捗を報告しているので 進捗率が正確でなく、タスクの期限日ギリギリになって遅延が発覚するようなことがよくありました。 解決策としては、「定量的な報告を義務付ける」ことだと考えています。 例えば実装であれば「実像すべき処理が⚫︎個あり、そのうちの▲個完了したので、進捗は◻️%」のように報告してもらいます。 これによって作業者も作業の全量がわかり、また作業の全量をリーダーとメンバーですり合わせができるので タスク漏れなども減らすことができます。 この経験から、自分自身がメンバーとして参画する際も、「管理されやすさ」を意識できるようになったと感じます。 ### 要件定義 リプレース案件だったこともあり、顧客からの要求が「現行踏襲」であることが多い案件でした。 要件定義のタイミングでは、過去の要件資料を確認しながら現行踏襲するように要件定義を行っておりましたが 設計フェーズでお客様に基本設計書をレビューしていただいたら、知らない仕様がいくつも出てきて 大幅に設計フェーズが遅延してしまいました。 この時は、現行のソースコードから仕様をリバースすることにしたのですが 本来であれば、お客様から運用フローを頂いて、それに合わせて要件を決め直すことが正しかったと考えております。 現行踏襲は要件ではない。 ### マネージャーへのエスカレーション 遅延や問題が発生した際に、エスカレーションが遅く、余計に問題が発生することが多々ありました。 リーダーとして、自分で問題を解決しなければいけない、という意識が強すぎたのが原因だと考えています。 少しでも問題が発生したら声を上げる。 これによって、素早くリカバリもできますし、同じような問題で困っている他チームにも共有できるので 「早く騒ぎを大きくする」ことの重要さを感じました。