WICAD Step 1｜Intent（意図を正確に伝える）


伝達とは一律ではなく、“調律”である。

 〜「伝えたつもり」から脱却するマネジメント設計論〜

 

 

 

 

1. はじめに：なぜ意図から始めるのか


■ マネジメントの第一歩は「任せること」ではない

多くの新任マネージャーが最初にぶつかる壁は、
「仕事を渡したのに、うまくいかない」「何度言っても伝わらない」という現場のズレです。

任せたつもりが、なぜ伝わらないのか？
どうして部下は動けないのか？
これは、「指示を出す」＝「伝えた」と思い込んでいる構造的な錯覚に原因があります。




■ 始まりは「意図」である

チームを動かすマネジメントの本質は、
「作業を割り振ること」ではなく、「なぜやるのか」を共有することです。

上司が「やってほしいこと」だけを伝えても、
それが何のためなのか、どのような価値を生むのかが伝わっていなければ、部下は“考えずに動く作業者”になってしまいます。

一方で、「この業務はこういう意図で必要なんだ」と伝わっていれば、
仮にやり方が多少違っても、目的に向かって自走する力が生まれます。




■ なぜ多くのマネージャーは「意図」を飛ばしてしまうのか？

結果として、
意図が不在のまま業務が渡され、誤解と非効率が積み重なっていきます。




■ WICADにおける「Intent（意図）」の位置づけ

WICADは、業務委譲を仕組み化するための5ステップフレームです。

このうちの 「I」＝意図 は、すべての起点です。
ここが曖昧だと、他のすべてのステップがブレます。




■ このセクションでお伝えしたいこと




2. よくある誤解と現場の言い訳集

なぜ“伝えたつもり”になるのか？


■ 「伝えたのに伝わっていない」マネジメントの典型

業務を任せたあとに、次のような状況に出くわしたことはありませんか？

そのたびに、こう思ってしまう——
「ちゃんと伝えたはずなのに、なぜわからない？」

しかし、ここに**“伝えたつもり”という危険な思い込み**が潜んでいます。




■ 初心者マネージャーが抱えがちな“言い訳リスト”

以下は、現場でよく聞かれるフレーズです。
どれも一見もっともらしく聞こえますが、その裏には構造的な設計ミスが隠れています。



■ なぜこうしたズレが起きるのか？ 3つの深層構造

1. 語彙と理解の非対称

同じ「報告」「提案」「レポート」という言葉でも、上司と部下でイメージする内容が異なる。

→ “言葉が通じている”＝“意味が通じている”とは限らない




2. 判断基準の欠如

やっていいこと・ダメなこと、作業分岐の判断ラインが共有されていない。

→ 部下は「これでいいのか？」と迷い、止まる／過剰確認が発生する




3. 伝え方の構造がない

相手のスキル・経験に応じた伝達手段が設計されていない（口頭だけ／手順書だけ等）

→ 情報は渡しても、理解は届いていない




■ 本質的な転換：理解の“責任”は伝える側にある

❌ 「理解できなかった相手が悪い」
✅ 「伝わるように設計しなかった自分に責任がある」

「伝えたかどうか」ではなく、「相手が理解し、行動できる状態まで持っていけたか？」を問うのが、設計者としてのマネジメントです。




■ このセクションでお伝えしたいこと

 

 

3. 意図を伝えるとはどういうことか？

“目的”ではなく“理解の設計”



■ 「意図を伝える＝目的を言えばいい」ではない

「意図を伝えろ」と言われて、
「この業務は大事だからよろしく」
「前月の売上を報告してほしい」
とだけ伝えてしまうケースは少なくありません。

しかし、それは「背景を語ること」に過ぎず、本質的な“意図伝達”にはなっていません。




■ 意図とは、“行動の判断基準を含む前提構造”である

真に意図を伝えるというのは、

までを、一貫した構造として伝えることです。




🎯 意図を伝えることの目的は「判断の再現性」を作ること

業務を任せた部下が自ら考えて判断し、行動できる状態にするには、
その判断の“軸”となる情報が必要です。

その軸こそが、「意図」＝前提＋目的＋判断基準 なのです。




■ 「目的」だけでは足りない3つの理由



■ 意図伝達に必要な3つの要素

1. 目的（Why）

2. 背景と前提

3. 判断基準




✅ 意図を伝えるとは、「行動可能な理解」をデザインすること

情報は“伝達”されるが、
意図は“構造として設計”されなければ、伝わらない。


マネージャーの役割は、「考えさせる」ことではありません。
「考えられる前提を提供すること」です。

 

 

 

 

4. 人によって伝え方は変えるもの（設計論

意図は“出し分け”されるべきである



■ 「同じように伝える」ことが公平ではない

多くのマネージャーが、「全員に同じように伝えることが平等だ」と考えてしまいます。
しかし、これは大きな誤解です。

人は経験もスキルも、理解スピードも異なります。
同じ言葉でも、受け取り方はバラバラです。

だからこそ、伝えるべきは同じ“構造”でも、「伝え方」は人に応じて変えなければいけないのです。




■ 伝達の設計は、「人材タイプ × 業務レベル」で決まる

業務を渡すとき、マネージャーがまず判断すべきなのは
「この相手には、どのくらい構造化された情報をどの手段で渡すか？」という伝達設計です。



✅ 人材タイプ別：伝え方と設計の深さ



■ 業務のタイプ別にも設計レベルを変える



🎯 ワークフローを「作らせるか／渡すか」は設計者の判断

WICADでは「部下にワークフローを作らせる」ことを推奨していますが、それが常に正解ではありません。“誰がフローを作るか”もまた、委譲設計の一部なのです。



🔧 補足定義：「ワークフローを作る」の2つの側面


「ワークフローを作る」という言葉の定義にはワークフロー自体を設計する、という意味と、すでに構造化されたフローを、描画ツールに落とし込むという2つの側面があります。実行型、反復型の人材にはすでに設計されたワークフローを描画ツールに落とし込んだ状態で渡す必要があります。

理解型には、5W1Hを整理した状態で、意図と判断基準を動画で渡し、描画ツールに落とし込んでもらうことで相手の理解度を確認する。という側面があります。

 


✅ 1. 構造設計（構造的ワークフロー）

✅ 2. 描画作業（ビジュアルワークフロー）




🎯 人材タイプごとの適切な扱い方




✍ 具体的な運用イメージ




■ 設計者＝マネージャーは、伝達の“翻訳者”でもある




✅ このセクションで伝えたいこと

 

 

 

5. 具体的な伝え方と手段の使い分け

相手と業務に応じて“伝達手段”を設計する



■ 伝え方を選ぶのではなく、“設計する”という視点へ

伝えるべき内容をどれだけ整理しても、
伝える手段が適切でなければ、理解・再現・行動にはつながりません。

「口で説明したから伝わった」
「資料を送ったから理解しているはず」
そう思い込んでいる時点で、マネジメントは失敗しています。

“何を伝えるか”と同じくらい、“どう伝えるか”が重要です。




■ 組織における「伝え方」は、文化と道具に基づいて進化すべき

一般的な「伝達手段論」ではなく、自社の運用実態と目的に合った伝達設計が必要です。
以下に、実際の運用に合わせて伝達手段を再定義します。



主要伝達手段と特徴


動画説明：Google Vids 



🎯 相手と業務のタイプで「伝え方」を選ぶマトリクス



🧩 選び方の視点は「伝えるため」ではなく「伝わるため」

伝達手段は、“発信者側の都合”で選んではいけません。
相手がどう受け取り、どれだけ理解し、どこまで自律的に動けるか？
それを前提に手段を設計する必要があります。




✅ 伝え方を設計するときのチェックリスト




伝え方を間違えると、意図も構造もすべて無駄になる

いかに明確な目的があり、5W1Hで整理されていても、
伝え方が雑であれば、意図は届きません。

WICADにおける意図伝達とは、「どう伝えるか」まで含めて設計することです。
情報ではなく、“理解の状態”を渡す。
そのための伝達手段は、相手の状態に応じて最適化すべきなのです。




口頭で伝えないからこそ、業務は仕組みとして残る


■ 伝達は「やりとり」ではなく、「再現性の設計」である

多くのマネージャーが、業務を依頼する際に「とりあえず口頭で話す」ことを選びがちです。
しかし、そこに明確な構造と目的がなければ、その伝達は属人化し、再現性を持ちません。

つまり、“その場だけの口頭伝達”には継承性も可視性もありません。




✅ 最初に使うべきは「口頭」ではない

業務依頼の最初に使うべき手段は、
チャット・テキスト・動画など“残る手段”であるべきです。

これらを先に整えることで、業務は一度きりの説明で「資産化」され、
誰が見ても再現できる“業務構造”になります。




🚫 口頭で依頼することの非合理性

口頭で伝えるという行為は、
・ログが残らない
・伝達内容がブレやすい
・受け手の理解度に左右されやすい

という性質を持ちながら、実は**依頼内容のほとんどが「確定事項」**であることが多い。



では、なぜ「確定した業務依頼」を口頭でやりとりするのか？

それなのに**「対話形式」にすること自体が非合理**です。
それはもはや、「相談」ではなく、単なる“情報通知”であり、ならば他の手段でよいはずです。




🧩 口頭説明は「信頼構築」ではない

“設計の確認・受け取りのレビュー”として使うべき

口頭説明には、相手の反応が見える・柔軟に補足できるというメリットがありますが、
「初回の重要説明」「信頼関係づくり」として使うべきではありません。




❌ 一般論的な“口頭の価値”の誤解



✅ 真の信頼とは、こう築かれる



✅ では、口頭でしかできないこととは何か？

口頭でしか果たせないのは、“構造に乗らない何か”へのアクセスである。



口頭の価値は、不安の解消と、見えないものの発見にあります。

つまり、口頭の出番は「最後」であり、「回収と発見」のためなのです。




🧭 設計された業務依頼の正しい順序（おすすめ）




設計者の信頼は「情報の整理力」と「構造の責任」で決まる

信頼は、仲良しトークではなく、

によって、積み上げられていくものです。




笑顔では信頼されない。
業務の構造が信頼をつくる。
そして、最後の「声かけ」が、次の改善と信頼の更新になる。





補足 : 🔍 なぜ「伝え方の設計」は見落とされるのか？


「伝え方の設計」という視点は、多くの組織で“驚くほど見落とされている”重要ポイントです。特に以下のような理由から、それが抜け落ちやすくなっています：




①「伝える＝話す or 書く」という思い込み

多くの人は「伝える」＝「口で説明する or メールで送る」という固定観念を持っています。そのため、“手段を選ぶ”発想にとどまり、“設計する”という視点に至らないのです。


② 発信者の視点に偏りがち

「自分は言った」「資料は送った」＝伝わった、と**“発信側の完了”をもって伝達が終わったと錯覚する構造**が多くの現場に根強くあります。


③ 忙しさゆえに「とりあえず口頭」文化

時間がない、手間をかけたくない、スピード感重視──そういった環境では、構造設計より“即席コミュニケーション”が優先されやすくなります。


④ ツール導入≠設計導入

Asana、Slack、Notionなどの導入で「業務は整った」と思い込む組織も多いですが、それらのツールも“使い方（設計）”がなければ効果を発揮しません。





💡 一方で、伝え方を「設計」できる組織は…

こうしたメリットを得ることができ、結果としてスケーラブルで健全な組織文化が根づいていきます。



ですので、「伝え方を設計する」という視点は、これからのチームやマネジメントにおける“当たり前の基礎”になるべき概念だと、私は本気で思っています。

 

 

 

6. 5W1Hによる意図伝達の実践｜判断と行動の“起点”を構造で渡す



■ なぜ5W1Hが必要なのか？

業務の委譲において、目的（Why）だけを伝えても、部下は自律的に動くことができません。
意図を伝えるとは、「なぜやるか」を語ることではなく、“どう判断して、どう動くか”までを相手に再現可能な形で渡すことです。

そのためには、**5W1H（Why / What / Who / When / Where / How）**のフレームを使い、
業務を判断可能な単位にまで分解して伝える必要があります。




✅ 5W1Hの実践定義と記述ポイント


📝 実際の記述例（社内レポート業務）

Why： チーム内で数字の状況を共有し、施策判断のベースとするため
What： 月次レポート（売上・在庫・実施施策・所感）をスライドで1枚にまとめる
Who： 経営陣とチームメンバーが閲覧・参考にする
When： 毎月第1営業日中に作成し、翌日10時までに投稿
Where： Slackの #report チャンネルへ投稿
How： フォーマットに沿って記入／過去2ヶ月との比較・数値の補足コメントをつける

→ このレベルで情報が整っていれば、判断を迷わず、再現可能な行動が成立します。




📌 注意点：書くことが目的ではない




🧠 使いどころ：誰に渡す業務に使うべきか？




✅ まとめ：5W1Hとは「行動と判断の設計書」である

5W1Hは、「丁寧に伝えるためのツール」ではありません。
それは、**“部下が迷わず動ける状態をつくるための構造”**です。

伝える、ではなく、**“再現できるように設計して渡す”**という視点を持つこと。
それがWICADにおける、意図伝達の実践です。

 

 

 

 

7. 伝わらないのは受け手の問題ではなく、“設計ミス”である

― マネジメントの誤解と、設計者としての責任 ―




■ 現場でよく聞く“言い訳”とその誤解

こうした言葉は、現場においては“よくある反応”ですが、
WICADの思想においては、これらの思考は誤りです。

それは、問題の本質を**“受け手の個性”に帰属させ、設計の失敗を見逃している**からです。




✅ 原則：伝わらない責任は“伝え手”が持つべきである

伝わっていないのは、「伝えていない」のと同じ。

なぜなら、伝えるとは
**「理解可能な形に情報を設計し、再現できる構造として渡す」**ことだからです。

つまり、「伝える」という行為は、
**受け手の能力や背景を踏まえた“構造的な調整行為”**であり、
一方的な発信や指示とはまったく異なります。




■ 設計ミスでよくある4つのパターン


✅ 設計責任を負うとはどういうことか？

これが、設計者としてのマネジメント行動です。




🧠 “理解力のせい”にしてはいけない理由

その状態で「なぜわからないのか」と言うのは、
「地図を渡さずに、なぜ目的地に着かないのか」と言っているのと同じです。




🔁 責任の所在を「人」から「構造」へ




マネジメントは“設計責任”であり、“説明責任”ではない

「伝える」ではなく「伝わるように設計する」
「できなかった理由」を探すのではなく、「設計に足りなかった要素」を振り返る

この視点に立てた時、
マネージャーは裁く人ではなく、設計する人になります。

 

 

8. まとめ｜意図の伝達こそが、委譲と育成の起点である



■ 「仕事を任せる」とは、意図を設計して渡すことである

マネジメントにおける「委譲」とは、
単に作業を振ることでも、手順を教えることでもありません。

それは、「判断と行動の起点」を構造として相手に渡すこと。
つまり、“意図を伝える”ことが、業務のスタート地点であり、育成の始点となります。




✅ WICADにおける「I：Intent」は、すべての起点である

すべての委譲は、「なぜやるのか」の明確な共有から始まります。
だからこそ、このStep 1：Intentが甘ければ、以降のすべてが崩れます。




■ 5W1Hで構造化するということは、設計責任を果たすということ

意図を伝えるとは、

その一つひとつが、マネージャーとしての設計責任であり、
それこそが“任せられる組織”を作る唯一の方法です。




📌 管理職・リーダーに向けた問いかけ




✅ WICADの次ステップへ進む前に

Step 1：Intent を設計できるようになったあなたは、
ようやく「仕組みで任せる」ための入口に立ちました。

ここから、

というWICADの本領が発揮されていきます。




意図の設計ができる者だけが、任せられる。
任せられる者だけが、人を育てることができる。

その第一歩が、この「Intent」の設計です。




次回以降、Step 2：Workflow｜業務フローの設計と合意形成へと進みます。

ここでは、意図を受けて“流れ”を作るフェーズに入っていきます。