プロジェクトマネージャーがDrupal開発プロジェクトの前にするべき12の質問

プロジェクトマネージャーが聞くべき12の質問

あなたがプロジェクトマネージャーで、自分の机にいて、挽きたてのコーヒーを飲んでいたとします。突然新しいDrupalのプロジェクトが始まる旨を連絡受けたとします。数日後にキックオフミーティングが始まります。

SOW（作業範囲記述書）が締結された、または締結されようとしていると想像して、今後のプロジェクトに対するあらゆる憶測をしているかもしれません。

あなたは最初にどんな働きかけをしますか？物事を円滑に進めるために正しい質問をすることです。しかも迅速に。プロジェクトマネージャーとして、自分の質問が時間通りに正しく答えてもらえなかった場合、プロジェクトの成功に向かって正しく向かっていないことになります。

今から紹介するのは、そういうことに対応するためにいつも忘れないでいることになります。

1: SOWか現状の課題シートはありますか？

プロジェクト開始時にこれらの書類があることは最も重要です。両方の資料には以下のような詳細が載っているべきです。

• 機能、サードパーティー連携、クライアント研修に求められること、範囲外の事項、、前提といった作業範囲の詳細
• 契約形態：固定価格によるものなのか時間請求なのか。固定価格のプロジェクト場合は規定した時間内にプロジェクトを終えなければなりません。一方時間請求の場合は、サービス提供者として、対応した時間をクライアント様に請求しましょう。
• 予定開始日と終了日
• 仕様変更が起こった場合の管理変更プロセスについて
• クライアント様の責任
• KPI：プロジェクトの成功を図る指標例えば、「クライアント様は、我々の提案ソリューションを導入することで、既存ソリューションの1.5倍の引き合いを獲得できることを期待しています」「提案したSolr検索を導入することで全文検索を10秒早くすることです」成果指標に関する情報は、プロジェクトマネージャーとしてその成果に向かっているのかどうかにフォーカスするのに非常に役立ちます。
• クライアントの思う成果物の受渡し日など。プロジェクトプランに役立ちます。
• 保証期間。どんな保証が受けられるのか。
• プロジェクトの許容レベル。クライアントから共有を受けた基準はどんなものか。彼らの期待は？例えば、重要度の低いバグのあるアプリケーションを受け入れることは問題ないかどうか。なぜなら、ビジネスへの影響はごくわずかである可能性が高いから、など。
• クライアントは最新バージョンのDrupalでの開発を求めているのか？既存のサイトがDrupalの場合、バージョンは何か？
• 既存のCMSが他社製の場合、どのように移行をするのか？手作業か？
• クライアントに提案した内容の詳細は具体的にどんなものか
• クライアントが期待する「すごい！」という評価はどんなものか？クライアントの期待の全てはビジネス開発チームによって理解されているか？
   

2: ステークホルダーの性格は？

クライアントの性格的な特徴を理解し、コラボレーションするにあたりアドバイスを得るため、ビジネス開発チームとディスカッションをしましょう。

その際、こう行った質問をして適切に答えてもらいましょう。「クライアントはどれだけ責任感がありますか？」「テクノロジーへの理解は？」「Drupalをどれぐらい理解している？」「クライアントのチームはどれぐらい柔軟な体制？」「当社は組織としてどれぐらいクライアントの悩みに対処しているか？」「クライアントは当社の働き方（アジャイルなど）にどれぐらい理解を示しているか？」

同じクライアントと働いたことのある同僚と会話してみることもすごく役立ちますし、より内情が理解できます。

3: クライアントはあなたのプロジェクロマネジメント方法をどれだけ評価しているか

クライアントはアジャイル開発手法や、関連ツールについて知っておられますか？ご存知でなければ、手法を学ぶことに対してどれだけオープンでしょうか？プロジェクトマネージャーとして、方法論について教えるために、またその利点を伝えるために、クライアントの不安を理解するために、クライアントとこれらのことを話し合うべきです。

4: プロジェクトのためにどれだけのリソースを獲得できるか？

プロジェクトマネージャーとして、誰がこのプロジェクトに関わるのかということについて、公平なアイデアを持つべきです。そして、チームメイトのスキル以上のことを心配しないといけません。むしろチームメイトの働き方や、得手不得手、クライアントとの折衝能力、稼働している時間などを把握しておくべきです。

開発にフロントエンドのタスクも加わる場合は、適した開発者もアサインするようにしましょう。

まとめると、チーム構成はこのような形であるべきです。

• バックエンドデベロッパー
• フロントエンドデベロッパー
• （CMSへの理解がある）QAスタッフ
• しっかり監視できて、コードをレビューでき、品質を管理でき、プロジェクトをおかしな方向に導くリスクを察知し、フラグを立てることのできるシニアテクノロジーアーキテクト

Drupalに特化した質問：プロジェクトはDrupal開発になるので、プロジェクトマネージャーとして以下の質問にも明確な意見を持ちましょう。

5: クライアントは、どのようなサードパーティー製品との連携を望んでいるのか？

例えば、決済ゲートウェイはあるのか？Baaarvoiceのようなソリューションを使っているのか？提案した連携に関してどのようなリスクがあるのか？また開発するDrupalのバージョンはどれなのか？

6: サイトは多言語サイトか？

パーソナライゼーションとグローバル化の時代において、違うターゲットユーザーに向けて違うことがで情報発信されます。これは、IPアドレスをベースにしているケースもあれば、ホームページの切り替えボタンで変更する場合もあります。

多言語化に関し、プロジェクトマネージャーとして、サードパーティー連携がされているのか、そのツールは有料ツールなのか、誰が支払っているのか、などを知る必要があります。それらにまつわるリスクはどこなのかも知る必要があります。

7: サイトを計測するか？

もしするならば、どのツールを使おうとしているか？Google Analyticsを使おうとしているか、Omnitureか、その他か？何を計測しようとしているのか？など

8: サイトはレスポンシブル対応をするのか？モックアップは2種必要か？

もしそうなら、いつまでに欲しいと思っているのか？Sprint 0のために持つべきです。もしくはプロジェクトマネージャーとして赤フラグを立てなければなりません。

9: もしproof-of-concepts（概念実証）がテクニカルアーキテクトより要求されたら、ソリューションの実行に対するその人の自信を評価する

特に評価されるべきスキルを持っているかどうか

10: プロジェクトの流れ（と概算）は現実的で、適切なリソース、スキル、スタッフの休暇プランを確保しているか？

もしギャップがあるなら、修正しましょう

11: 自動テストの範囲は？

Drupalのサイトはコンテンツがたくさんあるので、QAチームの負担を減らすためにSelenium、Behatといった自動ツールを使っているかどうかを確認しましょう。

12: あなたとクライアントのセキュリティに対する期待度はどんなものか？

機能的ではない部分の要望を深掘りして、セキュリティについてクライアントが期待していることを検討しましょう。例えば銀行サイトの場合、セキュリティ専門のQAスタッフをアサインしたいと思うはずです。ソリューションの一環として、どのレベルでのセキュリティ評価方法を提供しているのか詳しく知っておきましょう。あなたの考えていることにクライアントも同意していることを確認しましょう。

結論

上記の質問に加えて、関係者の全員がプロジェクトの方向性やプロセスに同意し続けている状態を作る必要があります。あなたはどんな小さな質問にも喜んで答えないといけません。スタッフに憶測で動いてもらうのはよくないことです。

プロジェクトの成否は、プロジェクトマネージャーがクライアントやチームメイトを含む関係者全員とどれだけうまくコミュニケーションするかにかかっています。これはプロジェクトの開始当初には特に重要なポイントです。

終わりに

いかがでしたか？プロジェクトの全体像を俯瞰して見ながらも、重要なポイントでは専門家からの知見も借りながら進めていくイメージだと思います。そして何よりもコミュニケーション能力が問われるのがプロジェクトマネージャーの仕事の大事な要素だと思います。参考になれば幸いです。