新人がプロジェクトを任された時に伝えたい事

概要

やぁ、PLとして初めてプロジェクトを任されたそこの君！！

今からプロジェクトを任された時の注意事項とやった方が良い事を書いていくよ！！

殆どが失敗から気付いた事なので、僕と同じ失敗をせずにプロジェクトを進行できるようにしよう

主に弊社の新人へ向けてです。全ての新人や会社に該当するかは怪しいです。
数年後にはここに書いた事が、自分の中で「え、当たり前じゃん」となってしまいそうなので文字として残します。

キックオフ・要件定義

さぁ！プロジェクトが始まった！・・・えっ、何したらいいの？情報何も無くない？そのうち顧客から色々情報くれるでしょ・・・

くれません

基本的に顧客からは欲しい情報は来ません。
自分で今回のプロジェクトでどういう情報が必要かを精査して、聞き出さないと行けません。

キックオフからやるべき事

• 顧客の業務の理解度を高める
  • 資料を貰っているのであれば読む
  • 不明点や気になった情報はまとめて聞き出す
    • 返答などを自分の頭の中だけではなく、プロジェクト用にまとめ直す
• システム化したい業務箇所(スコープ)を割り出す
  • システム利用を想定して業務フローを作成する（シーケンス図がおすすめ）※1
  • 何の業務が 核（力を入れる機能） になりうるかを導き出す

プロジェクト初期段階では、こちらが何も知らない状態からスタートするのはごく当然の事なので、
「分からない状態」 に対して不安を抱いたり、萎縮する必要はありません。

知れば知るほどプロジェクトに対して不安要素が増えていきますが、
初期段階では 「不安要素を見つけ出す」 フェーズでもあるので、寧ろ不安要素を見つける度にガッツポーズしましょう！！

※プロジェクト中盤などで不安要素が続々出てくるとメンタルもやられ、プロジェクトも遅延しがちです。
100%不安要素を初期段階で潰しきるのは不可能なので、
後半に楽をする為に 中盤にトラブらない為に出来るだけ見つけ出しましょう。

※1 このようなものですMermaidで作るのがオススメ

スケジュール感

大体の案件は要件定義前にスケジュールを定めるので、発見できた問題次第で「この納期だと厳しそうだな」となる可能性があります。

早い段階で分かれば、「この問題は次回に持ち越しましょう」「この機能は規模を小さめにしましょう」などの解決に繋げられます。

正直な所、最初から各課題の重要度やスケジュール感は掴めません。
問題となりそうな所（自分判断でOK）をまとめて上長に相談してみましょう

超絶注意事項🔥

• 基本的に助けは来ません、求めると来るかもしれません
• プロジェクトの進め方に正解は無い
  • (※PMですら知りません、あるのは経験と培った手札です)
  • 手札は見せてくれないので注意
• 1人で情報を抱え込まない
  • 上司や同僚に共有しつつ、ドキュメントとして書き残しましょう
  • 顧客とのやり取りの記録や、どういう経緯で仕様が決まったか。など。
• 何したら良いか分からなくなったら
  • 上司や同僚に現状を話しつつ頭を整理しましょう

モック作成

恐らくPMからモックの作成の指示が来ると思います。
システムイメージを掴んでもらうために、システムの「ガワ」だけを用意するというものです。

よく起こるのが、 「画面のサンプルを用意したら良いのかな？」 という認識でモックを作成し、
あまり役に立たないというケースが多々あります。

詳細に作りこむ必要はなく、質よりも速度と量が求められます。

PMが求めるモックというのは

• 顧客の業務に沿って動かせる各機能の画面遷移
  • この画面で○○をして××が起きる
    • そしてこの画面につながる
• サンプル画面を切り貼りしただけのものでは無い

PMの求めているモックの目的

• こちらが認識出来ていないシステムに必要な業務情報を引き出す
• システムの運用イメージを掴んでもらう
• 顧客との認識を擦り合わせる
• スコープを明確にする
  • スコープ外は仕様変更だと言える、立場が上の状態で交渉できる

開発

大体アルティメットアジャイル開発になります。

ウォーターフォールより融通が効くので開発はしやすいのですが、
何処からが改修、何処からが仕様変更なのかの区別が大変難しいので、
調整を間違えると納期に間に合いません。

なので要所要所で仕様を区切る必要があります。

超絶注意事項🔥

• 「この機能も欲しいです！」は絶対に聞き入れるな。
  • 一度許すとずるずると開発期間が延びる
  • 追加機能の実装だけでは済まない場合が多い、他機能への影響範囲も考えろ
  • 顧客の為に予算詰め詰めに作ってもクオリティが低くなるため客は満足しない
  • 次回のフェーズに持ち越せ
• 各機能の確認シートを作れ
  • 確認がされてから要望が来たら仕様変更だ
  • 無償でやるか有償でやるかはPMに判断を投げよう
  • 大事なのは 仕様変更 である事が証明出来る事。こちらの立場が全然違う。

テスト

テスト用の工数を必ず確保しましょう。

4ヶ月の開発期間の場合、4ヶ月で「開発が」終わるようにスケジュールを立てると大体死にます。

基本的にバグの無いシステムなんてありません。単体テストをしながら開発をしていても必ずどこかでバグっています。

初期流動で死なない為にテストしてバグをキッチリ取り除く工数を確保しましょう。

超絶注意事項🔥

• テストは一人でやらない方がいい、誰か同僚を巻き込もう
  • 自分が想定した通りにしか自分は動かさない為あまりテストの意味がない
  • 実際の業務を想定して、運用手順を説明しつつ誰かに動かしてもらいましょう