成功を導く「プロジェクト計画」の実践ガイド

社内システムやツールなどのUIデザイン制作を行うときは、初めにプロジェクトの計画を行います。プロジェクトの目的、範囲、タスク、リソース、スケジュール、リスクなどを明確にする工程です。

これをいかに設計・計画するかがプロジェクト成功のカギを握っています。適切な設計されていないと、スコープの不一致やスケジュールの遅延など、問題の生じるリスクが高まるからです。

ベイジはクライアントからの依頼をもとに、サービスやプロダクトのUI改善プロジェクトを数多く実施してきました。そこでの成功体験と失敗体験から学んだ、実践的なプロジェクト計画のコツを皆さんに伝授します。受託会社がプロジェクトをどのように設計しているのか、一例として読んでいただけると幸いです。

プロジェクト設計の流れ

1. 契約前ミーティング
2. プロジェクトチーム編成
3. WBS作成
4. プロジェクト管理ツールの準備
5. 開発環境の準備
6. プロジェクト定義書の作成
7. キックオフミーティング

契約前ミーティング

プロジェクトが始まってからのトラブル発生を防ぐために、プロジェクトに関する重要な情報について、事前にお客さまやプロジェクトメンバーと認識を合わせておきます。この時点で握っておくべき情報には以下のものがあります。

見積もり内容の認識合わせ

重要事項を見積書に記載していても、お客さまは見積書の端から端まで読んでいるとは限りません。経験が浅いお客さまの場合は記載事項への理解が不十分なことがあり、プロジェクト開始後に認識のズレが見つかることもあり得ます。とくに互いのスコープや何を納品物とするかなどは、お客さまとの解釈がずれることがあるため要注意です。

プロジェクトマネジメントの知識を体系化したPMBOK（Project Management Body of Knowledge）では、スコープ管理というプロセスで作業範囲や成果物を明確に定義する、としています。発注いただく前に、必ず認識を合わせる場を設けましょう。

お客さまのプロジェクト体制

プロジェクトに多くの関係者（ステークホルダー）が存在する場合は、スケジュールの作成に注意を払いましょう。関係する人や部署が多くなると意志決定や社内の合意形成に時間がかかるため、そこを考慮したスケジュールが必要です。

意志決定者をおさえておくことも重要です。プロジェクトメンバー以外に上位の意志決定者が存在する場合は、あらかじめどのステップで意志決定が必要になるかを伝え、早めに意志決定者のスケジュールをおさえましょう。

PMBOKではステークホルダーの定義を「『プロジェクトの任意の局面に利害関係を持つ』『影響を及ぼす』『影響される』『影響されると自覚する』人または組織」としています。そしてステークホルダーを洗い出し、プロジェクトへの権限、影響度、関心に関する分析や要求事項を文書化しておくことを、プロジェクトマネジメントのプロセスのひとつとしています。

プロジェクトチーム編成

スケジュールやメンバーの適性・希望などを考慮し、社内のプロジェクトチームを編成します。メンバーのプロジェクトへの適性は、おもに案件の難易度（レベル）とメンバーのスキルセットで判断します。経験の浅いメンバーにはベテランのサポートをつけるなどの配慮をしましょう。

以下のような案件は一般的に難易度が高くなります。

• 画面数が多い
• ドメイン知識の獲得が難しい
• お客さまとのカルチャーギャップ
• お客さまの承認フローが長い
• ステークホルダーが多い
• 機能の数が多く要件が複雑

ひとつのプロジェクトが終了した後は、必ず一定期間のバッファを設けます。いくら準備を入念にしていても、予想外のことが起きてプロジェクトが遅延することがあるからです。アクシデントが発生したときの対応期間を考慮し、ベイジでは1〜2週間ほどバッファを入れるようにしています。

またメンバーをアサインする際には、育成の観点からも検討することをおすすめします。メンバーの経験値を上げればチームのケイパビリティ向上につながり、業務の属人化も防げます。

WBS作成

プロジェクトにおける最小単位のアクティビティ（作業）を把握するためにWBS（Work Breakdown Structure）を作成します。各作業にかかる工数を算出してガントチャート化すれば、スケジュールを見える化できます。細かい作業に分解したWBSをもとにお客さまと進め方のイメージを共有し、認識齟齬を防ぎましょう。

ベイジではMicrosoft Office ProjectでWBSを作成していますが、他にもBacklogやBrabio、Excelなどさまざまなツールがあります。社内にテンプレートを用意しておけば、30分〜1時間程度でWBSが完成します。テンプレートはワークフローを網羅したフルラインナップのものにするのがおすすめです。プロジェクトに応じて、不要な作業をテンプレートから削っていくと楽に作成できるからです。

WBSを作成する際には、以下の点に気をつけます。

作業を細かく分解し必要なタスクを洗い出す

作業の粒度が大きいと実際のタスクにぬけもれが発生します。目安としてひとつの作業が8〜80時間以内の具体的なタスクを書き出します。

お客さま側の作業も定義する

お客さまの作業内容と工数を伝えた上で、相手の予定も考慮に入れたスケジュールを作成します。このステップが欠けていると、スケジュールの遅れが発生しやすくなります。

互いのゴールを達成できるスケジュールを引く

それぞれの役割と作業内容を明確にし、それを実現できるスケジュールを作ります。しかしスケジュールを作りっぱなしでは不十分です。スケジュールを丁寧に説明し、双方で理解を深め納得できるようにしましょう。

プロジェクト管理ツールの準備

WBSが決まったらプロジェクトを管理するためのツールを準備します。プロジェクトの実行と監視に最低限必要なのは、進捗管理、タスク管理、コミュニケーションの3つです。参考までに、ベイジでは以下のツールを使用しています。

• プロジェクト管理シート（スプレッドシート）：全体の進捗状況の把握
• Backlog（プロジェクト管理ツール）：細かなタスクの管理
• Slack（チャット）：お客さまとのコミュニケーション

基本的にはお客さまの要望に応じてツールを決め、アカウントの準備やツールへの招待などを進めます。ファイルの受け渡しはプロジェクト管理ツールやチャットツールなどでも可能ですが、Googleワークスペースなどのクラウド環境を介して行うと、大容量のファイルの受け渡しも手間なくできるのでおすすめです。

プロジェクト管理には鳥の目（全体を見る）と虫の目（細部を見る）の両方が求められます。管理ツールを活用して、フェーズごとの進捗やプロジェクト全体の進捗（鳥の目）と各作業ごとの進捗管理（虫の目）を同時に行えば、大きな失敗や炎上を防げます。

そしてプロジェクトの進捗状況を常にオープンにしておけば、お客さまに余計な不安を抱かせません。そのためにゴールに対しての進捗度合い（%）がわかるツールやシートなどを準備し、プロジェクトメンバーが定期的に更新します。さらに週1程度でプロジェクトミーティングを実施し、各メンバーがタスクと進捗をチェックします。

開発環境の準備

使用技術の選定

プロジェクトの要件に合わせて、使用する言語、フレームワーク、ライブラリなど、どのような技術スタックを使用するのかを策定します。

コーディング規約の策定

開発者間でコードの一貫性を保つためにルールやガイドラインを策定します。

ツールの選定

開発で使用するツールの選定を行います。以下のツールがよく使用されます。

• バージョン管理：Git, GitHub, GitLab, Bitbucket など
  コードのバージョン管理を行います。
• CI/CDツール：Jenkinsなど
  継続的インテグレーションや継続的デリバリーを実現します。
• コードレビューツール：Pull Requestの機能やCode Reviewツール
  コードの品質を保ちます。
• UI コンポーネント 管理ツール：Storybookなど
  作成したUIコンポーネントを分かりやすく管理・共有します。
• アクセシビリティチェックツール：miChecker、axe-coreなど
  アクセシビリティの問題を検出します。

開発環境のセットアップ

開発者のPC上で動作するローカル開発環境をセットアップします。エディタの設定、必要なライブラリのインストール、使用する場合はDockerなどのセットアップを行います。

テスト環境の構築

テスト環境としてサーバーをセットアップします。デザインの社内チェックや、クライアントが表示や挙動の確認などを行います。

設計

ディレクトリ構造の設計、コンポーネント設計、ステート管理設計、ルーティング設計など、開発に必要な設計を行います。

ドキュメンテーションの用意

APIの仕様、開発環境のセットアップ手順、アーキテクチャの説明、開発後にチェックすべき項目など、開発に関連する情報を文書化します。

セキュリティ対策

開発環境やコードに関するセキュリティ対策を行います。セキュリティの方針や基本的なツールの選定、セキュアなコーディングのベストプラクティスの策定などが含まれます。これにより、開発段階でセキュリティ脆弱性を持つコードを書くリスクを低減できます。

これらのステップや要素は、プロジェクトの規模や目的、使用する技術スタック、環境に応じてカスタマイズされることが多いです。

プロジェクト定義書の作成

社内でのプロジェクト準備がひととおり完了したら、プロジェクトを定義するドキュメントを作成します。一般的には「プロジェクト憲章」や「プロジェクトチャーター」と呼ばれており、ベイジ社内では「プロジェクト定義書」としています。

プロジェクト定義書では、プロジェクトの目的、スコープ、成果物、メンバー、セキュリティ関連情報、コミュニケーションルール、リスクや補足事項などをまとめます。

プロジェクトの大きなリスクには、スケジュールの遅れと追加費用の発生があります。これらを防ぐために、納品物、納期、スコープを明確にしておくのです。「こういうことが起きるとスケジュールが遅れます」「こういう作業には追加費用が発生します」とあらかじめ共有します。

またプロジェクト定義書には必要な情報を集約したガイドラインという役割もあります。テスト環境のURLやアクセス情報（ID/PASS）、緊急時の連絡先などもまとめておき、「これを見ればわかる」という状態にしておきます。

このプロジェクト定義書は次のステップ「キックオフミーティング」で使用します。

キックオフミーティング

契約締結後にお客さまと行う最初のミーティングです。目的は関係者の顔合わせ、認識ズレによるトラブルを防ぐこと、プロジェクト前の懸念や心配をなくすことです。

具体的にはプロジェクト定義書とWBSを中心に、プロジェクトの前提条件やスケジュールを説明し、目的を共有します。安心してプロジェクトをお任せいただくために、事前の認識合わせやリスク共有は丁寧に実施しましょう。連絡方法、担当窓口、議事録の送付タイミングなどの細かいこともここで決めておきます。

最近はベイジでもキックオフミーティングをオフラインで実施することが増えてきています。リアルで顔を合わせる場を設けておくと、その後のオンラインでのコミュニケーションがやりやすくなるなど、一定の効果を感じています。

最後に

プロジェクトでは常に予測できないことが発生します。リスクをゼロにすることは難しいでしょう。しかし、プロジェクトの目標やスコープ、スケジュール管理、コミュニケーション方法などを明確化してプロジェクトを設計すれば、リスクを減らし状況の変化に対応しやすくなります。紹介したノウハウが、プロジェクト設計をスムーズに進める助けとなれば幸いです。