はじめに

プロジェクトの立ち上げや要件整理の場面で、こんな経験をしたことはありませんか？

「あれ？さっきの会議で、ちゃんと合意したよね…？」

「話してた内容と、できあがったWBSがちょっと違う気がする…」

会話の中ではスムーズに進んだのに、いざWBSなどの構造にまとめてみると、なぜか違和感が残る。

そんな経験、プロジェクトに関わっているときっと一度はあるのではないでしょうか。

この“ズレ”は、誰かの理解が浅かったり、説明が不足していたりするだけが原因ではありません。
多くの場合、「話し言葉」と「WBS（構造化された言葉）」で前提が異なることが、本当の原因です。

話し言葉には、「言わなくても伝わるだろう」という空気や行間が自然に存在します。
一方、WBSでは、すべてを明確に言葉で表現しなければなりません。
構造、粒度、順序、役割などを厳密に定める“ルール”があるのです。

このギャップこそが、“なんか違う”を生み出してしまうのです。

また、WBSを作ったときにこんな気持ちになったことはありませんか？

「作ってみたけど、これって本当に意味あるのかな？」

「粒度を揃えるのが大変すぎて、ちょっと疲れる…」

「どうせプロジェクトって予定通りにはいかないし」

たしかに、WBSは一筋縄ではいきません。
それでも私たちは、WBSはプロジェクトに欠かせないものだと考えています。

なぜなら、うまく設計されたWBSがあると、こんな変化が起きるからです。

• 「あれ、これ誰がやるんだっけ？」という迷いがなくなる
• メンバー間の認識が揃い、会話がスムーズになる
• 状況が変わっても、WBSを見れば“どこをどう見直せばいいか”がわかる

だからこそ、WBSは「ちゃんと作るのは大変」だけれど、 「ちゃんと作った先に、大きなリターンがある」と、私たちは考えています。

そこで私たちは今回、実際にプロジェクトがうまく進行したケースに注目し、関係者へのヒアリングを重ねました。
プロジェクトマネージャーやメンバーたちが、「これは使いやすかった」と感じたWBSには、どんな特徴があったのか。
どのように作られ、どんなプロセスを経て機能していたのか──

そうして複数の実例を比較・検討する中で、ある共通点にたどり着きました。

それが、

“うまく機能していたWBSには、3つの設計ステップがあった”

という発見です。

この気づきをベースにして、私たちは「WBSを通じて認識をそろえ、プロジェクトを進める」ための設計方法を整理し、
全3回の連載シリーズとしてご紹介することにしました。

本記事はその第1回。
テーマは─「話し言葉でやり取りした内容を、どう“WBSという構造”に変えていくか？」です。
そんなWBS設計の“最初の壁”に焦点をあてて、お届けしていきます。

自然な会話を、ズレのないWBSへとつなげる。
そのための“最初の壁”に焦点をあてて、本ブログをお届けします。

また、本文で触れる内容の背景や、より具体的な設計手法については、
あわせてご覧いただけるホワイトペーパーにて詳しく解説しています👇
📘 【ホワイトペーパー】WBSシリーズ第1部：「話し言葉」はなぜ構造になりにくいのか？

プロジェクトの初期、私たちはまず「話す」ことで物事を進めます。

「じゃあ、Aさんがまとめてくれます？」

「そこ、巻き取っておきますね」

「もう少しシンプルなUIにしたほうがよさそうです」

その場では「うんうん、そうだね」と話が通っていたはずなのに、いざWBSや構造に落とし込んでみると、
ふとした違和感が生まれます。

「“まとめる”って、どこまで？」

「“巻き取る”って、作業？それとも責任範囲のこと？」

「“シンプル”って…どの視点で？」

言葉は交わされたのに、WBSという構造になった途端、うまく伝わらなくなる。
これは、「誰かの理解が浅かった」「話がちゃんと聞けていなかった」といった単純な問題ではありません。

本当の理由は、

“話し言葉”と“WBS（構造化された言葉）”では、伝わるためのルールがまったく違うからなのです。

会話には、その場の前提、立場、人間関係、そして雰囲気といった“言葉以外の情報”が自然に織り込まれています。
だからこそ、少し曖昧な言葉でも「なんとなく伝わる」ことが多いのです。

しかし、WBSはそうはいきません。
言葉だけが並ぶ世界では、“なんとなく”は通用しない。

たとえば、

会話で出てきたフレーズ	WBS化するときのモヤモヤ
資料をまとめる	どこまで？資料の構成？作成？提出？
巻き取る	タスクのこと？責任のこと？
確認しておく	誰が？何を？どのレベルで？

こうした言葉は、会話の中では“意味のかたまり”として成立していても、
構造に落とすと、「どの粒度で」「誰の目線で」「どこまで」が曖昧なままになります。

だからこそ、ふわっとした言葉の意味を一度“バラして”から構造にする必要があるのです。

では、その違和感をどう扱えばいいのでしょうか？

私たちは「その違和感は、悪いものではない」と考えています。
むしろ、「なんかモヤモヤするな」と感じたときこそが、構造を見直す絶好のタイミングなのです。
違和感は、構造のどこかにまだ“言葉にしきれていない意味”が眠っているというサインなのです。

そのとき必要なのは、すぐにWBSを書き直すことではありません。
立ち止まって「問いを立てること」。

ここから、本当のズレを埋める作業が始まります。

話し言葉をWBSという構造に変えるとき、最初にやるべきことは、“問いに変えること”です。

たとえば、

投げかける問い	整理できること
これは“何をすること”？	作業と成果物の切り分けができる
誰の視点で話されている？	粒度や優先度の妥当性が見える
どうなったら完了？	判断基準を明確にできる

問いを添えるだけで、「見えているつもりで見えていなかったもの」が浮かび上がるのです。
特に、まだ構造が曖昧な初期段階でこの問いを使うと、WBSづくりが一気に進みやすくなります。

📘 この“問いによる変換”の具体例やチェックリストは、WP第1部で詳しく紹介しています。

👉 ホワイトペーパーを無料で読む

今回は、「話し言葉をWBSという構造に変える」プロセスの中で、違和感を起点に、問いを立てて構造化する流れを整理しました。

違和感は、意味の分解が追いついていないサイン。
そして、それを「問い」に変えることで、WBS設計の材料として活かすことができる、それが第1回の結論です。

ですが、さらにWBSを仕上げていくために必要な観点はもうひとつあります。

それは

「同じ構造を見ても、人によって意味がズレる」

という、“視点の違い”という問題です。

次回の【第2部】では、PM、エンジニア、クライアントなど、それぞれの立場によってWBSの意味がどうズレていくのか？
そのズレをどう設計に取り込み、伝わる構造を作るのか？
具体例を交えながら、詳しく解説していきます。

構造は作って終わりではありません。

誰がどう見るかによって、伝わり方も変わる──
そんな“視点と構造”の関係を、一緒に考えていきましょう。

※免責事項
本記事（または資料）の内容は、あくまで情報提供を目的としたものであり、すべての状況に当てはまるとは限りません。内容を参考にされた結果については、ご自身の判断と責任でお願いいたします。当方では、その内容をもとにした実践や対応によって生じたいかなる結果についても、責任を負いかねますことをご了承ください。