プロジェクトマネージャー（以下PM）のchakiです。PMの仕事をはじめてから7年経ちます。
その間、3社に所属していますが、PMの仕事内容は会社によって異なっていました。
共通して言えるのは、どうもいつも忙しいということ。 何かしらタスクが発生し、何かしら解決に向けて取り組みしているということ。
最近のできごとを例に、PMの忙しさについて考察してみました。
最近のできごと
ビジネス側（Goodpatchはビジネス側の支援を実施）と開発パートナーが要件定義を行いました。
ビジネス側から「エラーメッセージを表示する」と要望を受けましたが、現在のフォーム画面はエラーチェックは入っていますが、エラーメッセージを表示する実装がないので、今回実装を行います。エラーメッセージを画面のどこになんと表示するか確認したいということでした。
個人情報入力フォーム画面
その場で回答ができないので、バックログを起票してもらい、後日回答することに。 バックログの担当者はビジネス側のCさんでしたが、PMとして以下の対応を取りました。
- バックログに添付されたエラーチェックの仕様を読み解き、エラーケースを把握
- フォーム画面のアクセス数と、どんなケースで発生しうるのか調査
- エラーメッセージ案を作成（サイト内で一貫した文言であるかもチェック）
- ビジネス側の関係者を集めて説明し、エラーメッセージ案をブラッシュアップし決定
これが1つのバックログ（タスク）についての対応で、これが断続的に続きます。バックログを日々ウオッチし、1人障害物競争をしているような状況です。
PMは間に落ちているボールを拾い、スケジュールに遅れがでないように目を光らせ、遅れそうならカバーに動くと思っていたので、当然と思って奮闘していました。ところが、この話を雑談がてらしていた際に聞いていた仲間から
「そもそもそれはPMが拾うボールなの？」という指摘を頂きました。
え・・ちがうの？？
「プロジェクトになにか問題が起こっているからPMがボールを拾い手を動かす状況が起こってるのでは」という指摘でした。
これが当たり前と思っていた私にとって、目から鱗の一言でした。
この考え方に沿って、できごとを要素分解してみようと思います。
できごとを要素分解
フォーム画面のあらすじはこうです。
画面遷移とエラーチェックのタイミング
フォーム画面のエラーメッセージ表示位置
エラーチェックの仕様書
エラーチェックの仕様書（実際のプロジェクトで使用された仕様書）
これらの情報は、開発パートナーの観点で見れば「正確で丁寧で正しい」のですが、ビジネス側だけでは読み解くことが難しく、ユーザーがどのような操作を行った時にエラーが表示されるのかを整理する必要がありました。
整理の一例
仕様書の説明
更新するユーザーデータのcustomer.IDとセッションのcustomer.IDが一致しているか。
想定するユースケース
ユーザーが入力完了するが登録ボタンを押下する前に画面を放置、セッション時間（48時間）が切れた後に、再度同じ画面をひらき登録ボタンを押下した場合、保存ができずにエラーとなる。
表示位置
入力フォームの上部（メッセージ表示エリアA）
エラーメッセージ
一定時間が経過したため、お客様の情報を登録することができませんでした。もう一度入力をやり直してください。
想定するユースケースは私（PM）に開発側の知見があることから推定しているものですが、本当に開発側が意図している内容と一致するのか、ものによっては確認が必要でした。
またエラーメッセージ案を提示したところ、サイト内で統一されている言い回しなのかビジネス側から質問をもらいました。
- エラー文言が一覧になっていない
- サイト内での文言統一できているのかも不明な状態
- 適切なメッセージを考えこれでよいと判断するための材料が不足している
という状況でした。
エラーチェックの仕様書は50件超え。しかもビジネス側の作成対応が終わらないと、後続スケジュールに影響がでそうだったので早々に確定させる必要がありました。
そこでPMとして、ビジネス側が判断しやすいように以下を準備し1回の会議で終わるように努めました。
MTGが1回で終わるように準備しておいたもの
- エラーの出現率を3段階で整理
- エラーチェックの仕様書（50件）に対するユースケース
- わかりにくいユースケースは画面遷移図の説明を付帯
- API連携など説明が難しいものはデータ保存の流れを説明するフローチャートを用意
- エラーメッセージを画面にはめた画像（改行位置をチェックし、読みやすいかを判断してもらうため）
- エラーメッセージの表記方針
- メッセージ表示位置に対しての方針
- メッセージの作成に対しての方針
- 最終的に開発パートナー戻せる形でエラーチェックの仕様書を更新したファイルの準備
が、MTGはタイムアップとなり1回に収めることができず、開発パートナーと追加のすり合わせをしながら5回ほど開催。
結局スケジュールを遅延させてしまいました。
スケジュールハンドリングできなかったことを反省しつつ、次回からはこの確時間を加味しておく必要があることを認識できました。
何か問題だったのか
さて。プロジェクトでどんな課題が起こっていたのか。大きくは4つあると整理できます。
１）ユースケースに落とさないとビジネス側はエラー処理を読み解けない
２）エラー文言一覧が整理されていない
３）エラーメッセージを考える担当者が曖昧
４）エラーメッセージの作成・確認をスケジュールに組み込めていない
本来であれば、これらの課題が発生していることをプロジェクトにフィードバックし、課題解消にむけて取り組むべきでした。 それをせず曖昧な部分をPMが巻き取ることでなんとか間に合わせるという選択をした結果、仕事量が増えるている状況となっていました（振り返ってみるとなんてこったです・・）。
解消にむけて
同じ苦労を繰り返さないために。課題の解消について、以下に具体的な心構えと対応を挙げます。
１）ユースケースにおとさないとビジネス側はエラー処理を読み解けない
担当者：エンジニア
対応内容：コードにかかれているエラー処理を伝えるだけではなく、ユースケースに置き換える説明を追加する。
２）エラー文言一覧は整理が必要
担当者：エンジニア
対応内容：画面毎のエラーチェック仕様とエラーメッセージをドキュメント化する。
３）エラーメッセージを考える担当者を決める
担当者：ビジネス側
対応内容：役割分担を見直し、担当を明確にする。
４）エラーメッセージ作成・確認をスケジュールに組み込む
担当者：PM
対応内容：エラーチェック仕様をエンジニアがドキュメント化する工数、ビジネス側がチェックする工数をスケジューリングする。
まとめ
個人的に手を動かすことがめっちゃ好きなので、落ちているボールを拾うこと自体に大きな支障を感じていませんでした。 しかし、今回の出来事と仲間との会話を通して「プロジェクトで起きている課題をメンバーに共有できていない」ことについて改めて考えさせられました。
今は自分がアサインされていて解消できていたとしても、将来的にメンバーが入れ替わりプロジェクトを回していくことになります。 仕様書を一元管理することや、課題が起きそうなときの解消方法をナレッジとして残したりすることも重要であると気づくことができました。
general editor：@inininin-design
