ウェブディレクター・プロジェクトマネージャーとして大規模プロジェクトに関わる前に必ず実施していること。それは、ある2冊の本を読み返すこと

最近、プロジェットの難易度が上がってきている、未経験のプロジェクトが多い、規模が大きくなっている、との声をよく聞きます。
ビッグデータ、マーケティングオートメーション、システム移行、複数社連合プロジェクトなど、確かに多様化、複雑化しているように感じます。

とすると、毎回高難度のプロジェクトに未知の恐怖を持ちながら戦うのかというと、そうではないはず。
自分が新しいプロジェクトを始める前に読み返す本と、その本をどのように活用しているのかを、思いつく限りまとめてみます。

世界一わかりやすいプロジェクトマネジメント

プロジェクトマネジメントの教科書。プロジェクトマネジメントとしてやるべきとと、事例が掲載されている。

この本には「プロジェクトマネジメント成功のための十二の黄金率」って記載があります。
自分が担当することになったプロジェクトが、黄金率に当てはめるとどのような状況にあるか、ということをプロジェクト開始前に考えます。

例えば、「成果物についての合意を得る」という項目。
大体、RFP (提案依頼書) とか、提案書とかには記載があると思います。
設計書、ファイルリスト、html/css/JavaScript、画像データ、試験報告書、ガイドライン、などなど。
多くの人は、おそらくですけど、これらの項目を見て、どんなものを作るのかイメージ湧くと思います。
よかった、じゃあ、ドキュメントにも記載あるし、問題ないねって話になるかというと、そんなことはありません。
# ノリツッコミ下手でごめんなさい。

「設計書」ってなんですか？

• 画面設計書ですか、ワイヤーフレームですか、システム設計書ですか？
• 仮に、ワイヤーフレームだったとして、ワイヤーフレームってなんですか？
• ワイヤーフレームにはどのようなことが書かれているんですか？
• 出し分けパターンはすべて網羅されているんですか？する必要ありますか？
• 表示件数の制御は網羅されているんですか？する必要ありますか？
• 正常系、準正常系、異常系で使われる要素はすべて定義してますか？する必要ありますか？
• そもそも何で書くんですか？Excel、PowerPoint、InVision、Illustrator、はたまた？？
• 「弊社指定のフォーマット・ドキュメント」って前提だったとして、弊社指定で良いって確証は得ているんですか？何をみて合意したんですか？？

いくらでも疑問は湧いてきますね。

では、疑問を投げかけたところで、ひとつ問題です。
下の中から成果物として使えるワイヤーフレームは何でしょうか？

• 選択肢1 手書きのワイヤーフレーム
• 選択肢2 要素の配置だけ記載されたワイヤーフレーム
• 選択肢3 エラーのテキストなどまで盛り込まれたワイヤーフレーム
• 選択肢4 なぜその構成なのかの意図が書き込まれているワイヤーフレーム
• 選択肢5 システム的な仕様や処理が書き込まれているワイヤーフレーム

答えは、全部使えるし全部使えないです。はい、質問として不適切、ごめんなさい。

なにがいいたいかというと、「成果物」は合意が必要なんです。
プロジェクトが新たにはじまったのであれば、おそらく、相手はあなたをよく知りません。あなたの会社をよく知りません。だから、あなたの会社での決まりは知りません。
相手の会社では、ワイヤーフレームが二段階で作成されており、二段階目でシステム担当者が詳細仕様まで記載しているのかもしれません。その仕様書き込みが終わったものをワイヤーフレームと呼んでいるかもしれません。

ということを頭に置きながら、新しく参加するプロジェクトの成果物を確認します。
たとえば、最初の1ページ目をレベル感合わせに使ったり、相手の社内で使っている資料を共有してもらったり、こちらからサンプル出したり。

レベル感合わせるときには、どこまで書くのかとか、その後の影響とかを話しながらやります。
これが具体的にどのデータを使っているのかは、作るときに考えます、なのでそのときにできなかったらごめんなさい、とか。詳細仕様はおまかせするので、とりあえずUIだけ定義します、とか。UIとインタラクションは、定義しますが、数の定義はおまかせします、とか。

成果物を合意するというひとつでも、これだけ考えて状況把握しています。

これを、十二の黄金率の数だけ (だから12個) だけ実施します。

はじめよう要件定義

最近、要件定義の重要性が増している気がします。

最初の本と同様で、この本でやることは状況把握です。

特に、要件定義では何が決まっていなければいけないか、ということが書かれているので、何ができていないかが、明確にわかります。
多くのプロジェクトは、要件定義を始められる段階にないので、まずは要件定義を始める準備をします。
(この時点で、スケジュールが狂うことが非常に多い)

要件定義に取り掛かるために、終わらせて置かなければいけないことはなんでしょう。
プロジェクトの目的やゴール (これやることを要件定義と呼ぶプロジェクトも多数あることは知っていますが、本質的に作る要件定義ではない) が決まっているか、制約が明らかか、無理無駄無茶はないか (リスクは明らかで、管理されているかか)、などなど。

• 全員が共通認識としているプロジェクトですか。
• クライアント社内承認用の資料 (夢) だけで、要件定義を進めようとしていませんか。
• 周辺環境は明確になっていますか。
• 登場人物 (人だけでなく) は揃っていますか。揃っていなければ、いつ揃えますか。

言葉だけ見れば、普通のことかもしれないですが、ほとんどのプロジェクトではこの判断ができる状況にすらなっていないです。
極端な話、この書籍の最初から最後までを要件定義フェーズとして実践できれば、作りたいものは作れます。

そのために、この本をもとに、プロジェクトとしての共通認識を持てる状態まで整えます。
クライアント社内で回覧しただけの夢、もらいっぱなしの資料、提案書のままの目的、実現可否を検討していない進行計画などを、プロジェクトに組み込むための準備を最初に実施する手引きとして使っています。

筆者が活用している二冊の本

世界一わかりやすいプロジェクトマネジメント

はじめよう！ 要件定義 ～ビギナーからベテランまで