背景

未経験入社後1年5ヶ月経過したタイミングでありがたい事に、ある予約システムのプロジェクトリーダー（PL）を経験させてもらえる事になり、約6ヶ月の開発期間を経て、先日リリースを迎えました。
その過程の中で、プロジェクト開始〜リリースまで進めていくに当たり、リスクが多く潜んでいると感じました。

仕様が決まっていない
素材が来ていない
メンバーの突然の体調不良
タスクの遅延

これらの項目は、考えてみると当然っちゃ当然なんですが、
自分が感じたリスクとは、これらも含めて、

後で工数が発生するかもしれない状況が存在すること

だと感じました。
PLとして開発スケジュールを管理する上で、見積る事ができない工数はできるだけ減らしたいです。工数が膨れ上がると計画が崩れますし、いくらバッファを設けていても、これで足りるのか？という気持ちになります。
なので自分の中では、後で工数が発生し得る状況をリスクとして考える事にします。

これから、上記以外で実際に起こった追加の工数と、それをできるだけ避けるための策
を記載していきます。

※補足
LINE MessagingAPIという語句がでてきますが、
詳細はリンクから確認ください。

実際に発生した追加の工数

テストアップのタイミングでクライアントにシステムを展開し、一部のFBは来たが、本当に隅々まで確認してもらったかわからず、結局リリース後に修正依頼が来た

リリースしたタイミングですぐに修正する事自体ミスを発生しやすくする要因です。
また、デプロイ前の修正内容の確認、デプロイ作業・デプロイ後の反映内容の確認を実施するのに工数が必要となるので、追加工数が発生したと考えます。

LINE MessagingAPIにはリクエスト上限数（2000リクエスト/秒）があるが、一気にこの制限数を超える人数へメッセージを送信したいという緊急要望がリリース後に来た

リリース後であったためすぐには対応できず、現状の機能で実施する形となり、この制限数を超えないよう人数を分割してメッセージを送信する、という本来不必要なオペレーションが発生しました。
同時に、機能追加修正工数が発生しました。

ローカル環境では動くけどテスト環境では動かない、という事象に遭遇した

画像の保存に関しては、RailsのActiveStorageを利用していたのですが、
画像ファイルへのパスのドメイン ≠ ブラウザ画面のドメインのため、
html aタグのdownload属性の仕様でダウンロードが機能しない事が発覚しました。
ダウンロードボタンを一つの機能としてクライアントFIXしているため、ひと工夫してダウンロードできるようにする必要があります。これに関してはテスト環境で早めに試さなかった事が敗因です。追加工数の発生と考えます。

テストパターンの洗い出しが不足していたため、プログラム修正後に再度のテスト工数が必要となった

これはそのままの通りでテストパターンの洗い出しが不足していました。修正工数と再度のテスト工数が追加で必要となりました。（テストコードによるテスト自動化の際のテストパターン洗い出しが不足していた問題でもあります）

外部ツールの設定方法について、メンバーに１から設定方法をレクチャーするための工数が発生した

今回で言うと、LINE APIとの疎通がうまくいかないとメンバーから質問を受ける機会が多かったです。
途中でチームに加わったメンバーに最初にLINEの設定関連をざっと説明しても、設定方法なんてものは当然一発で覚えることはできないので、動くようにするために工数が必要となりました。

できるだけ避けるための策

少し大袈裟な書き方ではありましたが、追加工数が発生した部分を分析してみました。
予期せぬ追加工数を完全に無くす事は難しいと思いますが、
できるだけ避けるための策を講じる事はできると思いますので、考えてみます。

外部APIを使用する場合、それはリスクとして考える

LINE MessagingAPIにはリクエスト上限数（2000リクエスト/秒）があるが、一気にこの制限数を超える人数へメッセージを送信したいという緊急要望がリリース後に来た

外部APIには何かの制限があると思いますので、必ずチェックし、その制限が起こり得るケースなのかどうか考え、予め対策を講じて置くのが良いと考えます。通信が失敗した場合の処理についても考えておくのが良いと感じました。

指摘が来そうと感じる仕様に関しては、クライアントに時間を頂戴してでもこちらから先に動作説明し、動作を認識してもらう

テストアップのタイミングでクライアントにシステムを展開し、一部のFBは来たが、本当に隅々まで確認してもらったかわからず、結局リリース後に修正依頼が来た

時間を取る事が難しい場合、対象箇所の動画を送付するでも良いと思います。動くものを確認いただく事で早めにFBをもらう事が目的です。

本番に近い構成のテスト環境を開発初期の段階から用意し、確認するフェーズを設ける

ローカル環境では動くけどテスト環境では動かない、という事象に遭遇した

ローカル環境では動くけどテスト環境では動かない、という事象を早めに認識するためです。

機能開発の際は、テストパターン洗い出しを行い、バグ発覚による修正を最小限にとどめる

テストパターンの洗い出しが不足していたため、プログラム修正後に再度のテスト工数が必要となった

テストパターンの洗い出しは時間がかかると思います。
また、テストコードを書くのももちろん時間はかかり、進捗が出なくて辛いかもしれません。

しかし、テストコードを書くという事は、テストコードが書けるように本実装のコードを書かないといけなくなるため、コードの品質が良くなるのと同時に、後でかかるであろう修正工数＆テスト工数を削減できるので、結果として最初にかかる工数がペイできると、今では本当に感じます。

設定関係は、簡易的でも良いのでドキュメント化する

外部ツールの設定方法について、メンバーに１から設定方法をレクチャーするための工数が発生した

最悪手順をまとめている記事を引用するでも何でも良いのですが、ドキュメントを見てやってね〜、わからん部分は聞いて！の形に持っていくのが良いと感じました。READMEに記載はしていたものの、文字しか無くてわかりにくかったので、もう少し画像付きでちゃんとしたものを用意しておけば良かったと思います。backlogをうまく活用したい。

まとめ

リスク管理と一言で言っても色々とある中で、今回自分は

後で工数が発生するかもしれない状況が存在すること

にフォーカスしてリスクを定義し、振り返りを行いました。
次の案件で実践してみて、また振り返りを行いつつ、自分で良いと思えるプロジェクト進行のスタイルを身につけていきたいと考えています。