PM初心者が最初の案件を完走した話 〜KPTで学びを整理〜

1.はじめに

本記事は自己の振り返りと共に、これからプロジェクトマネージャー/リーダーを経験される方向けに少しでも参考になればと思い書いています。案件自体が少し前なので、記憶を頼りに書いていきます。
諸先輩方におかれましては、温かい目で見ていただけると幸いです。

2.プロジェクト概要

業界は伏せますが、フレームワーク移行がプロジェクトの目的となります。
使用技術は以下です。

移行先Framework

Spring Framework

開発言語

Java,JavaScript,CSS,jsp,SQL

DataBase

PostgreSQL

その他ツール等

a5SQL,Redmine,eclipse,azure(既に構築済みで担当外)

3.KPT

3-1.Keep（良かったこと、うまくいったこと）

1. スケジュール通りに進行できた工夫
   WBSを作成する際、メンバーのスキルに合わせてタスクを割り振れたことが成功の鍵でした。メンバーのスキルセットは事前に職務履歴書を入手していたため、過去の経験を踏まえて機能をアサインしました。
2. メンバーとのコミュニケーションで気をつけたこと
   Redmineを見れば当日の作業進捗は把握できるため、日次レベルでは進捗会を行わず、週1の開催を行いました。私自身が毎日進捗会を行うのがストレスというのもありましたが...
   在宅/出社は選択可能で、メンバーが出社した際には他愛もない世間話から直近の作業状況を対面で聞き、表情などを観察しました。
3. 要件定義で良かった取り組み
   現行機能の移行と言えど、移行先フレームワークで可能な事が多々あったので、springで実現可能な案は積極的に提案するようにしました。
4. 内部QA表の作成
   基本設計を行うにあたり、要件定義書を読み込むわけですが、業界的な専門用語や処理に関して逐一メンバーからチャットで質問が来ることを想定し、事前にプロジェクトメンバー用のQA表を作成しました。
   朝一で回答するようにし、他のメンバーからも同じ質問が飛んでこないようにしました。

3-2.Problem（課題、うまくいかなかったこと）

1. 仕様変更
   要件定義→基本設計での仕様変更は多くの方が経験されたのではないでしょうか。
   要件定義時から変更があれば普通は全て仕様変更ですが、1人日未満の変更(画面レイアウトの細部など)を割と受け入れてしまい、機能工数が膨らんでしました。
   1人日未満の仕様変更でも受け入れてしまうと、後々「あの時はタダでやってくれた。」と言われかねません。一度仕様変更を受け入れてしまいましたが、それ以降は仕様変更管理表を作成し、変更分は追加清算という形をお客様に説明し承諾いただきました。
2. 自分でタスクを抱え込む
   プロジェクトが始まる前から、上長には「自分でタスクを抱えるな、メンバーに割り振れ！」と言われていました。いざプロジェクトが始動すると管理作業に忙殺され、簡単な作業でも自分でやった方が早いと判断してしまうことが多々ありました。結果、残業時間が増え精神的・肉体的にも疲弊したことを今でも覚えています。自分でタスクを抱えず、メンバーにタスクを依頼することを学ぶいい機会になったと思います。
3. プロジェクト標準
   設計書標準に相当するドキュメントを事前に準備できていないこともあり、メンバーの記載粒度にブレが生じました。例えば、言葉尻一つにしても、私のレビューでは通ったのに、別レビュアーには指摘を受けた。逆もまた然りです。標準化を怠ったために管理側・メンバーの負担が増え、ストレスの要因になっていたと反省しています。

3-3. Try（次に試したいこと、改善策）

1. 標準化
   3-2-3で述べましたが、設計書標準ドキュメントを作成する必要があります。
   設計書テンプレートの各シートに何を記載すべきなのかを明確にすると共に、実際にサンプルがあると記載イメージが付きやすくスムーズに設計が行えると考えています。
2. 品質報告時のバグ推移表作成
   今後もタスク管理でRedmineを使用するかは不明ですが、顧客に品質報告を行う際にバグ推移表を簡単に作成できるマクロがあると便利だと感じました。
   バグ発生件数とバグ消化件数が図として可視化して閲覧できるようになっており、結果として2つの線が収束していれば品質的に問題ないと判断できるためです。
3. 要件定義フェーズでのヒアリング強化
   顧客の潜在的要求を要件定義時に引き出したいですが、やり方は模索中...ですが難しいところです。
4. コーディングレビューの自動化
   今回、コードレビューは全て目視で人力で行ったので負担が大きく、コード解析ツールを使用して管理側負担を減らす努力をしたいです。

4.まとめ

初めてでも試行錯誤し、プロジェクトを完走しました。
カリスマ性を持ったリーダーが指示を出してプロジェクトを遂行するのは、納期を遵守したという結果だけ見ればOKかもしれませんが、メンバーは考える事を放棄するため組織としては衰退していくのだと思います。
当時の自分は支援型リーダーシップを完璧に取れていたとは思っていませんが、メンバー各々が自分の機能に責任を持ち、積極的に発言してくれたおかげで完走できたと思っています。日々の何気ないコミュニケーションや私の仕事に対する姿勢に共感してくれた結果、良好な関係を築けていた自身はあるので、こちらは継続します。
最後になりますが、皆様にとって少しでも役に立つ情報があれば幸いです。（何か思い出したら追記していきます。）