PMOに与えられた役割によっては仕様を全く理解しなくてもプロジェクトの進行は可能です。
しかし、それではただの事務職と変わらないただ会議の進行と伝達役を請け負うだけの誰でもできる仕事となってしまいます。
プロジェクトによっては、このようなPMOももちろんいます。でも、この記事をみている方はそうではありませんよね？
本記事の目的としては、開発案件のプロジェクトを担当したPMOのレベルアップを目指すことです。
仕様を理解して、プロジェクトマネージャーやエンジニアと一歩深いコミュニケーションをとっていきましょう！
仕様とは
製品、サービス、システム、プログラムなどの詳細な説明や仕組みのことを指します。
仕様を理解することは、多くの場合、専門知識や実際に動かしてみることが必要です。
まずは、一般的な理解方法を挙げてみます。
一般的な仕様の理解方法
仕様に詳しい人から説明を受ける（プロジェクト開始時）
プロジェクト参画時に、プロジェクトマネージャーやエンジニアからどのようなシステムかざっくり説明を受けることが多いです。
その場の説明だけで森羅万象全てを理解できれば、我々はこんなにも困ることはないですよね。
わからないことがあれば、プロジェクトの関係者に質問して徐々に理解していきます。
ドキュメントを読む
システムの仕様に関する文書を確認します。ユーザーの要件、要件定義書、基本設計書、外部設計書など、仕様に関連する情報が入っている文書です。
過去のプロジェクト資料にあったり、プロジェクト開始時やプロジェクト途中で作成されたりします。このドキュメントだけでおおよそ理解できる方もおりますが、読むだけでは頭に入ってこないのが現状です。
実際のコードを読む
エンジニア出身の場合、ドキュメントよりコードを読んだ方が理解が深まる方がいらっしゃいます。
実際の動きが確認できるため、良いのですが、PMO管理になりますと、中々全てを確認する時間もありません。
システムに触る
既存のシステムがあれば、結合環境などで実際に動作させてイメージを具体化するのは効果的です。ただ、0からシステムを構築する要件の場合、そううまく行かないのが現状です。
関係者との会話で学んでいく
プロジェクトマネージャー、エンジニア、お客様と会話する中で気付かされ、理解していきます。
ただ、最初全然何言っているのか分からずきつい状況から始まるの嫌ですね。
仕様を理解するために●●をしろ！と明確な指示が出されることはあまりないため、まず上記の行動になる方が多いのではないでしょうか？
というかこれを何回も繰り返していくのが常ですよね。
ということで、次は筆者の経験を元に、できるだけ早く仕様を理解していく方法を記します。
是非参考にしてください。
仕様を理解する流れ
PMOとして活躍するぞ！という方に注意して頂きたいのが、仕様の全てを理解する必要はないということです。
理由としては、管理工数に割く時間がなくなるのと、複雑で理解が難しい仕様は製造担当のエンジニアやお客様に問い合わせできるためです。
複雑な仕様こそ、理解したつもりにならず、随時関係者と認識合わせするべきです。
また、大規模なプロジェクトの場合、サブシステムの数も多く、何がどのように動いているのか理解しないままプロジェクトが進行し、何となく仕事を流してしまっている状況に陥る危険もあります。
PMOとしては、複雑な仕様を時間をかけて把握するのではなく、「仕様の流れ」に着目し、早い段階で理解していきましょう！
仕様理解サイクル
筆者のPMO経験から、どのように仕様を理解してきたか記します。
大事なのは「構造化」して理解することです。構造化とは、「事象や物事の関係を整理すること」です。
この記事をご覧になっている方々でしたら「情報を整理するのなんて当たり前だろ！」と思われるかもしれません。ですが、情報の整理方法によっては、その過程での理解度が違ってきます。ただコピペで整理しただけの資料と、自分の頭の中の知識を元に作成した資料とでは攻撃力が全く違うのです。
理解の流れ
①要件を確認する
②要件に対応する機能の仕様をざっくり確認する
③要件の範囲内のシステムの流れを確認する
④機能に使用される業務用語を確認する
⑤③④を行き来し、業務用語が出てきたらその都度調べる
★できれば社内の用語集ではなく、ネットとか自分自身で調べてみる
⑥結合環境など触れるシステムがあれば触りまくる
⑦全体がわかってきたら、Excelなどで何も見ずに図に書き起こし整理する
①〜⑥を1日15分でも繰り返せば、全体の流れが理解できてきます。
⑦で作成した図は自分にとってのシステムのマニュアルにもなり、中々に便利です。
見返した時に自分にわかるように説明文を捕捉すると、他の人に説明する時にも使えます。
また、更に時間があれば、テスト仕様書を見ないで要件に対するテストパターンを考えてみるのも効果的です。
本来はエンジニアが考え、作成すべき仕様書ですが、修行と思って裏で作成してみましょう。
いざエンジニアから仕様書が上がってきた際には、不足している観点はないかなど確認にも使えます。
こちらは私の考える仕様理解度の基準となりますので、ご参考までに。
仕様理解の基準
- 1. 機能を知らない
- 2. 機能単体の動作はわかる
- 3. 複数の機能同士の動作がわかる
- 4. 詳細な処理の中身までわかる
- 5. 全体を通して人に説明可能
PMOにとって、仕様の理解はマストではありませんが、理解すればするほど提案や要件の穴を見つけることが可能になります。
エンジニアと同じレベルで仕様を理解しているPMOなんて付加価値ありまくりですね。
是非、つよつよPMOを目指してレベルアップしていきましょう！
コメント