プロジェクトリーダーがプロジェクトを成功させるための「成果物の可視化」の実践方法

:::note info
LITALICOのプロダクトエンジニアリング部でエンジニアとして働いている @bashiiko （バシコ） です。LITALICOには2021年に新卒入社し、今年で4年目になります。最近はコーディングよりも、要求要件整理・開発計画立て・工程管理・他組織との連携をメインミッションとしており、プロジェクトマネジメントに片足を突っ込んだような仕事に挑戦しています。

この記事は [LITALICO Engineers Advent Calendar 2024](https://qiita.com/advent-calendar/2024/litalico) の20日目の記事です :santa_tone1::christmas_tree:
:::

# 概要
本記事では、私の実務経験を通じて、プロジェクトマネジメントにおける「可視化」の重要性を実践的な方法とツールを交えて解説します。

プロジェクトを進める際にまず重要なことは、**顧客や関係者との共通認識を作ること**だと思っています。成果物がどのようなものになるのか、どのように使われるのかを可視化し、関係者全員がその理解を共有することで、プロジェクトの成功に近づけることができます。

- 想定読者：プロジェクトマネジメントやそれに類似した業務に携わる方
- ゴール：プロジェクトマネジメントにおいて「可視化」がなぜ重要なのか・作図の際のポイントがわかる

# そもそもプロジェクトが失敗する（炎上する）のはなぜか？
プロジェクトが失敗する原因の一つに、期待値のズレがあります。プロジェクトの失敗要因については、[LITALICO Engineers Advent Calendar 2024](https://qiita.com/advent-calendar/2024/litalico) の8日目の記事の [中期開発PJTの失敗を防ぎ、成功へ導くレビュー戦略 > レビューが必要となる問題の原因](https://qiita.com/kamesennin/items/b766e04ecdee49f935f6#%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%8C%E5%BF%85%E8%A6%81%E3%81%A8%E3%81%AA%E3%82%8B%E5%95%8F%E9%A1%8C%E3%81%AE%E5%8E%9F%E5%9B%A0) で包括的に整理されているので、ぜひ読んでみてください。
顧客やユーザー、開発チームが「何を作るのか」「それがどのように機能するのか」を正確に理解していないと、完成後に「思っていたのと違う」となり、手戻りや遅延が発生します。

実際、私が関わったプロジェクトでは、開発途中でユーザから「やっぱりこの仕様だと体験的に微妙かも」「今のままだと業務負荷が高く回らなそう」とフィードバックを受け、仕様変更や再設計が発生し、スケジュールが遅れたことがありました。

これらの問題が起こる理由は主に2つだと考えています。

- 顧客/ユーザー自身が期待しているものの解像度が低く、言語化できていない（まだ存在しないものについて語るには限界がある）
- 期待値が合っているのかズレているのかが分からない（形になるまで気づけない）

# 期待値ズレを防ぐための可視化の重要性
可視化を行うことで、以下の2点が解決できます。
- 顧客やユーザー自身が成果物の期待値を明確にし、その解像度を上げる
- 現在の成果物の状態を明確にし、期待値とのズレを把握できるようにする

成果物の全体像や関連する体験、業務の流れを整理することで、「いつ」「誰が」「どのように使うのか」といった具体的なシナリオを描きやすくなります。言葉だけや文章では捉えきれないニュアンスが、図を通じて視覚化されることで、関係者全員が具体的なイメージを持つことができます。

※ 今回は記事の「可視化」というテーマにかなり寄せて書いていますが、実際にはこれだけで全ての問題が解決することはなく、さまざまな観点での分析と対策が必要です。例えば期待値ズレの話でも、生じてしまった期待値のズレに早く気づいて修正する、という観点で開発プロセスやレビューサイクルでの工夫も検討できると良いと思います。

# 何を可視化すると良いのか？
成果物とその周辺の解像度を上げるために、以下は必須で整理すると良いです。
- **体験フロー図**
   - ユーザーの体験を時系列で整理するものです
   - ユーザーがどのような体験をするのか、どのタイミングでどのようなアクションが必要かが明確になります
- **業務フロー図**
   - 社内での業務やプロセスの流れを視覚化したものです
   - 関係者間の役割分担や情報のやり取りのタイミングを整理するために有効です

例えば、「ユーザーからの問い合わせをフォームで受け付け、社内の問い合わせチームがそれを検知して返答できるようにしたい」というシンプルな要求を考えてみましょう。文字で見てみるとなんら難しいことはなく問い合わせフォームの項目などの仕様だけ詰めれば良さそうな気がしてしまいます。が、図に起こしてみると以下のようなフローになり、「これはここで矢印が止まっていていいんだろうか
」「この矢印って具体的にはどうやって実現されるのか？」などが気になってきます。こういった図を開発者だけではなく顧客/ユーザ、デザイナーなど関係者全員で眺めながら議論することで、図が共通言語になってくれて認識を合わせつつ具体化していくことができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/423220/5c7278b8-1c07-e596-b199-2920158ef632.png)


# 「体験フロー / 業務フロー」の可視化時のポイント
## １.  何のために作る図で、誰に見せるものなのかを明確にする
これは図に限らず資料を作る時には常に意識すべき点です。
目的と対象者に応じて、作成する図は変わります。
例えばエンジニア向けにはUMLを使うと分かりやすく、またMermaidなどのツールで作成すれば更新も簡単にできます。しかし、非エンジニア向けにはUMLは理解が難しく、適切でない場合もあります。

## ２.  図の正しさよりもわかりやすさを重視する
図を作成する際には、図の「正しさ」よりも、**「わかりやすさ」を重視する**ことが最も重要だと考えています。特に初期の段階では、完全に正確でなくても、関係者全員が共通の理解を持つことの方が価値があります。例えば、関係者が図に描かれている内容を見て、「この部分の業務のパスは手運用で回るのか？」と質問が出ることで、より具体的な議論が生まれ、最終的にプロジェクトの方向性が明確になります。

場合によっては有効な小ネタをいくつか紹介します。
- **複数の異なる種類の情報を1つの図にまとめる**（例：業務フローと状態遷移と議論コメントを1つの図にまとめる）
   - 状態遷移図は別途整理し、議論の議事録は別途取っているとしても、1つの図に整理することで得られるメリットもあります（やり過ぎるとごちゃごちゃになってカオスになるので限度はありますが…）
   - 例えば、「状態」をシステム上でも「ステータス」として管理/表示しよう、としている場合など、「どのタイミングで状態が切り替わるのか？」が明らかになると違和感に気づける場合があります

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/423220/3e57aec4-3777-5185-b1d6-74824a0c02b8.png)

- **特にレーンを跨ぐ流れの場合、コミュニケーション媒体を図に書き込む**
   - 今回の例だと「ユーザ」「社内」の2者のみなので漏れにくいですが、特に社内の組織で複数チーム/部署が関わってくる場合、注意が必要です。チームを跨ぐ場合、そこの受け渡しは「メール」「電話」「口頭」「Slack」「システム」…etcの何で行われるものなのかを確認します。
      - 情報システムは「記録」するものなので、 情報の入出力のイベントが漏れていないか注意して洗い出す目的です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/423220/7042913d-c74c-ba27-4df8-566588e84884.png)

## ３. 作成した図はできる限り一緒に読み合わせる
非同期で見てもらうことももちろん有用ですが、少なくとも1回は集まって読み合わせることで以下のような効果が得られるのでお勧めします。

- 認識のズレや見落としを防ぐ
   - 例えば、図を作成した本人も、説明しながら気づかなかった矛盾や誤解を発見することがあります
- 業務担当者の視点を取り入れる
   - 開発チームだけでなく、業務の現場で頻繁に使われる用語やプロセスに関する知識を直接聞いておくことで、後々のシステム設計において重要なポイントを早期に把握できます
- チームの一体感を作る
   - 読み合わせやディスカッションを通じて、チームメンバーとの信頼関係を深め、プロジェクトを一丸となって進めるための土台が築けます

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/423220/8cec152d-db59-641e-e6c3-4c7071260cd6.png)

## ４. 作図ツールを適切に選定する
以下のポイントを考慮しながら、最適なツールを選びましょう。
- **チーム全員が簡単にアクセスできること。逆に社外からはアクセス不可にできる**
   - 更新や修正を容易にすることで、プロジェクト進行中に常に最新の情報を共有できます
   - プロジェクト外からもFBをもらうため、「誰でも見ようと思えば見れる」場所に置いておくのが重要です（※ 機密性がないPJTの場合）
- **無制限のキャンバス**
   - 複雑な業務フローを整理する場合、縦横に無限に広がるキャンバスが便利です
   - 制限がある場合、適切に表現できない可能性があります

これまで利用したことがあるツールを以下で紹介します。最近は [draw.io](https://app.diagrams.net/) を使うことが多いです。
- ⭐️ [draw.io](https://app.diagrams.net/)
   - 慣れないと使いづらい点はありますが、Googleアカウントさえあれば無料で利用可能で、図をチームで共有しやすいです
      - drawioの使い方は、[【動画付き】 draw.io 使い方まとめ 〜エンジニアでなくても使えるTips集〜](https://qiita.com/G-awa/items/8fd414700b68b2bcafcc) がわかりやすくておすすめです。drawioでストレスを溜めている方はぜひ読んでみてください
   - おすすめの使い方：特に初期段階でのフロー図や仕様の整理。シーケンス図なども簡単に作成できるので、開発の設計段階でも利用できます
- [Figma](https://www.figma.com/ja-jp/design/)
   - デザインツールなだけあって綺麗な図が作れます
   - プロジェクト全体で使う場合、アクセス権や共有設定に少し手間やコストがかかる場合があります
   - おすすめの使い方：UI/UXデザインやビジュアル的な要素の整理
- [Figjam](https://www.figma.com/ja-jp/figjam/)
   - 直感的に使えるホワイトボードツールで、デザインに特化したFigmaに比べ、作図ツールとして使いやすいです。個人駅には可愛いスタンプが貼れるのがアガりました
   - Figmaと同じく適切なアクセス権や共有設定に注意が必要です
   - おすすめの使い方：特に初期段階でのフロー図や仕様の整理。UI/UXデザインには不向き
- Google図形描画ツール
   - Googleアカウントがあれば誰でも使える、という点ではdrawioと同じく良いです
   - シンプルで便利ですが、フローチャートの作成には向いていません
   - おすすめの使い方：簡単なモックアップやシンプルな図の作成

# まとめ： 可視化を通じてプロジェクトの成功を導く
可視化を行うことで、関係者全員が「何を作るのか」「その目的は何か」を共有し、認識のズレを減らすことができます。可視化を適切に活用すれば、プロジェクトの進行をスムーズにし、成果物の質も向上します。プロジェクトが進行する中での期待値のズレを最小化し、納期や予算内での成功を目指しましょう:v: