初めに

みなさんおはこんばんにちは。パラディンこと原田典です。

長岡技大に入り早 2 年半。もう大学院一年生になってました。
今年も気づけば半年が過ぎそうですね。

そうです。時が過ぎるのはあっという間です。
ということは締切を意識して過ごしていかなければなりません！

私は早い時の流れに追いつけず、待ってくれない締切に追われていました。
そんな中である事件が起きます。

それは、「総動員法の発令」です

※総動員法とは、「他のプロジェクトのメンバーも総出で特定のプロジェクトを手伝い、完成させる」というものです。

私が PM をしているプロジェクトでは、技大祭（長岡技大の学園祭）への参加団体の申請情報を管理するアプリを開発しています。

つまり、参加団体説明会までにアプリを完成させなければなりません。
しかし、運用開始 2 週間前を過ぎても完成には程遠い状態でした。

「やばい。これ、間に合わないかも。」と思い
意を決して、局長に許可をもらい総動員法を発令しました。

この大忙しな体験と反省を書いていこうと思います。

総動員法発令までにやっていたこと

大前提、私が PM に就任したのはまだ技術力が全然足りていない時期でした。
そんな中で入学して半年の新入生をメンバーに抱え、プロジェクトをまとめていました。

初めはチームが再編成されたばかりだったので、
チームの仲を深め開発効率を上げるためにチームビルディングをしたり、
総務局にヒアリングをして機能要件や優先順位などの要件定義を定めることから始めました。

※総務局とは、参加団体を管理する局でアプリを実際に使用する局のこと。

そこから徐々に
タスクの切り分け→タスク振り→レビュ-
を繰り返して開発を進行していきました。

ここまで見たら「お、順調に進んでる？」と思うかもしれませんが、
今振り返ると、この時点でかなり危ない道を進んでいたと思います。

PM に就任してから 2 か月後の 10 月からは長岡技大の必修科目である実務訓練（長期インターンシップ）が始まり、
2 月半ばまで自分だけオンラインでの活動となりました。

この期間はオンラインで PM をすることの難しさを実感するだけでなく、
12 月末からは冬季休暇が始まり、開発速度は徐々に低下していきました。

しかし、2 月頭に開発合宿をするなどして追い上げを図ることで対応をしていました。
※開発合宿とは、1 週間などの決められた期間毎日みんなで集まり、一日 6,7 時間開発をするというもの。

実務訓練が終わり、再度ヒアリングをしていくうちに、ある重大な問題が浮かび上がってきました。

それは、最初に行ったヒアリングでは出てこなかった課題や改善点が次々に出てきたことです。
ここから急激に忙しくなったのを今でも覚えています。

ここで 1→2→3→4（3→4→3 を繰り返す）ことができたら理想ですが、
この時の自分は 1 すらまともにできていない状態で進めていました…

1. 優先順位などの要件定義をし直す
2. タスクを切り分け、GitHub の issue に書き起こす
3. メンバーに開発してもらう or 自分で開発する
4. レビューをする or レビューを誰かに振る

というのもタスクが山のようにあり、1 を決めている間にメンバーが余ってしまい
時間が無駄になることを防ぐために、以下のように進めていました。

1. 優先順位の決定
   開発メンバー分の最優先タスクが決まったら 2 へ
2. GitHub に issue 起こし & タスク振り（人数分）
   
3. 残タスクの優先順位決め
   レビューが出るまで 3 をこなす
4. レビュー
   基本的に動作確認でコードレビューは余力があったらする
   レビューが無くなったら 2 に戻る

このサイクルで幾分かは耐えていましたが、ある日のヒアリングでデータベースの大改修案件が舞い込んできて、
ついに次の技大祭に持ち越しのタスクが発生しました。

それと同時にプロジェクトメンバーでは抱えきれないことが判明し、総動員法の発令をすることになりました。

総動員法発令中にやっていたこと

総動員法が発令されても PM がやることはほとんど変わりません。
むしろ稼働人数が増えるので管理がさらに大変になります。

また、参加団体説明会が近づいてきているのでより忙しさが増すばかりです。

• 残タスクの優先順位の決定
• タスクを細分化し、GitHub の isuue に起こす
• タスクを割り振る
• レビューする or 誰かに頼む
• 発見したバグ・改善案の「優先順位決め」 or 「総務局に相談」
• ヒアリングをして要件確認
• 総務局員にテスト使用 兼 デバッグをしてもらう
• たまに自分で開発（息抜き）

この期間は起きてる時間のほとんどを開発に当ててました笑

総動員法発令が起きた原因

私は以下のことが足りていなかったと考えました。

「自分含めて、全員がプロジェクト全体を理解する & お互いに助け合える環境を作る」

1. プロジェクト全体を理解するためには、

   • 自分がやるタスクが
     • どの部分に当たるのか
     • いつまでに完成させなければいけないか
     • どのくらいでできそうか
   • 現状どんなタスクがどのくらいあるのか
   • どのくらいで全てのタスクが消化されるのか

2. お互いに助け合える環境を作るためには、

   • お互いを気にすること　 ←NUTMEG の Value の 1 つ目
   • 他の人に頼ること

これらのことをまとめると、
「締切を意識すること」
「お互いに気にすること」
を常に意識することができればプロジェクトは円滑に進み、成功すると思います。

今後の GM2

第 1 回参加団体説明会には間に合いましたが、次は第 2 回参加団体説明会に向けての開発が迫っています。
しかし、現状はバグや改善案が大量に見つかり、優先順位の決定が終わっていない状況です。

今までの反省を活かして今後は　「締切を意識すること」、「お互いに気にすること」
を大事にして、ヒアリング、優先順位決め、タスク割りをしていきたいです。

また、プロジェクト全体を把握するために、プロジェクトについてまとめた wiki や
タスクを見やすくするための施策などもしていきたいです。

まとめ

PM は忙しいです。
けど PM をすることで得られるものはかなり大きいです。
プロジェクト理解が深まり、開発力が上がることはもちろん、
周りを見る力やコミュニケーション能力など技術以外の面でも成長できます！

振り返ってみると「楽しかったなー」という思い出ばかりです。
ぜひ機会があれば一度は PM を経験することを強くお勧めします！