プロジェクトの成否を左右するのは、不確実性を乗り越えるチームの共通認識です。未来を語る英語の時制と助動詞を適切に使い分けることで、リスクを見える化し、確実な合意形成を導くことができます。
不確実なプロジェクトの議論で起きる3つの言語的課題
プロジェクトの初期段階では、目標や期限、リソースなど多くの要素が流動的です。この混沌とした状況下での議論では、単なる情報共有以上の「認識のすり合わせ」が求められます。しかし、英語でのコミュニケーションにおいて、時制や助動詞の微妙なニュアンスを意識せずに発言すると、認識齟齬の種がまかれ、後のトラブルにつながります。システム開発における認識齟齬の原因を調査したある資料では、曖昧な要件や仕様の記述が食い違いを生む主な要因の一つと指摘されています。これは言語の使い方に起因する課題でもあるのです。
特に、次の3つの言語的課題が、プロジェクトの共通理解を妨げる壁として立ちはだかります。
『可能性』と『確約』が混在する混乱
プロジェクトのキックオフミーティングで、次のような発言が飛び交うことはありませんか。
- 「We will launch the new feature in Q3.」（新機能は第3四半期に確実にリリースします。）
- 「We might need additional budget for the API integration.」（API連携には追加予算が必要になるかもしれません。）
- 「The vendor should deliver the module by next Friday.」（ベンダーは来週金曜までにモジュールを納品するはずです。）
ここで使われている助動詞「will」「might」「should」は、それぞれ確信度が大きく異なります。「will」は強い意志や確約、「might」は低い可能性、「should」は期待や推測を表します。これらが無秩序に混ざると、チームメンバーは「どの発言が確約で、どれが単なる可能性なのか」を見分けられなくなり、計画の土台が脆弱になります。認識齟齬について論じたある資料では、認識の不一致は「起こさせる側」に責任があると述べられています。発言者が意図を明確に言語化しないことが、混乱の源となるのです。
リスクの所在が見えにくい『ぼやけた未来』
次に問題となるのは、未来のアクションに対する「条件」や「依存関係」が言語化されないことです。例えば、「We can start the user testing.」（ユーザーテストを開始できます）という発言は、一見前向きに聞こえます。しかし、これには重要な前提が抜け落ちている可能性があります。
この課題は、単に「曖昧な表現」というレベルを超えています。システム開発の現場では、専門用語や業界用語の解釈の違いも認識齟齬の原因となることが指摘されています。未来を語る英語表現も、チーム内で解釈が統一されていない「隠れた専門用語」となり得るのです。
文化間で異なる確信度の表現が招く誤解
多国籍チームでのコミュニケーションでは、さらに複雑な課題が加わります。英語ネイティブスピーカーと非ネイティブスピーカーでは、助動詞が持つニュアンスの受け取り方に差があるからです。
日本人が「It could be difficult.」（難しいかもしれません）と控えめに発言した場合、ネイティブスピーカーは「かなり高い確率で困難である」と受け取る傾向があります。一方、ネイティブが「We may have a delay.」（遅延があるかも）と軽く言ったことを、非ネイティブが「ほぼ確実に遅延する重大な報告」と深刻に受け取ってしまうこともあります。この微妙な感覚のズレが、計画の前提を大きく揺るがす誤解を生むのです。
このように、未来を語る表現の選択は、単なる文法問題ではなく、プロジェクトのリスクマネジメントやチームビルディングに直結する重要なファシリテーションスキルです。次のセクションでは、これらの課題を解決する具体的な時制と助動詞の使い分け術を詳しく見ていきましょう。
未来シミュレーションのための「予測可能性マトリクス」を導入する
複雑なプロジェクトを前に、チームメンバーが一様に「これはどうなるんだろう」と不安に思うのは自然なことです。このセクションでは、その漠然とした不安を「確信度」と「コントロール可能性」という2つの軸で整理し、未来への言語表現を体系化するフレームワークを紹介します。プロジェクトマネジメントの分野では、リスクを「発生確率」と「影響度」で分析する手法が知られています。この考え方を応用し、不確実な要素を可視化して議論の質を高める方法を学びましょう。
確信度とコントロール可能性の2軸で未来を分類する
プロジェクトにおいて、すべての要素が同じように不確実というわけではありません。ある部分はほぼ確実で、ある部分はまったく予測がつかない。また、チームが積極的に介入できる要素もあれば、外部要因に左右されて手出しが難しい要素もあります。この違いを無視して一律に「willで話す」と、認識のズレが生じます。
「予測可能性マトリクス」は、プロジェクトの要素を2つの尺度で4つの象限に分ける思考の地図です。
- 確信度 (Certainty): その事柄が将来実現する確かさを表します。過去のデータ、確立されたプロセス、法的な確約などに基づいて判断します。
- コントロール可能性 (Controllability): チームがその事柄の結果に影響を与え、方向づけられる度合いを表します。内部リソースで対応できるか、外部の承認や市場動向に依存するかで決まります。
この2軸を縦横に取り、4つの領域を作ります。プロジェクトのタスク、リスク、前提条件、目標などを一つひとつこのマトリクス上に「プロット」してみてください。チーム内で「この要素は確信度が高いけど、我々のコントロールは及ばないね」といった共通認識が生まれ、議論が具体性を増します。
このマトリクスの考え方は、プロジェクトマネジメントの国際標準であるPMBOKで紹介されている「発生確率・影響度マトリクス」にヒントを得ています。リスクを定性的に評価・優先順位付けするためのツールとして知られています。
各象限に配置すべき助動詞と時制の組み合わせ
マトリクスで状況を整理できたら、次はそれぞれの象限にふさわしい英語表現を当てはめます。これが、このフレームワークの真髄です。状況に応じた適切な表現を使うことで、発言の意図が明確になり、チームの期待値を現実的に調整できます。
| 象限 | 特徴 | 最適な英語表現 | 使用例 |
|---|---|---|---|
| 確信度高 コントロール可能性高 | 計画や決定済みの事柄。チームが主体的に実行する。 | be going to / 現在形 (スケジュール) | “We are going to launch the beta version next Monday.” (計画) “The meeting starts at 3 PM.” (確定スケジュール) |
| 確信度低 コントロール可能性高 | 結果は不確実だが、チームの行動次第で変えられる。 | will (意思・予測) / may, might, could | “We will try to negotiate for a better deal.” (意思) “This approach might reduce the error rate.” (可能性の予測) |
| 確信度高 コントロール可能性低 | 外部要因で決まることがほぼ確実。チームは受け身。 | will (単純未来) / be likely to | “The regulator will announce the results in October.” (外部スケジュール) “Interest rates are likely to rise.” (高い確信度の予測) |
| 確信度低 コントロール可能性低 | 不確実性が最も高く、チームの影響力も限定的。 | may, might, could / would (仮定) | “The new policy could affect our supply chain.” (不確定な可能性) “If the market crashes, we would need a contingency plan.” (仮定の話) |
表にあるように、「確信度」と「コントロール可能性」の組み合わせで、使うべき助動詞が自然と決まってきます。例えば、自社で完全にコントロールできる開発作業（確信度高・コントロール可能性高）について「It might be completed tomorrow.」と言うと、根拠のない不安や自信のなさを伝えてしまいます。逆に、法律改正のような外部要因（確信度高・コントロール可能性低）を「We are going to change the law.」と表現するのは現実的ではありません。
ホワイトボードや共有ドキュメントに4象限のマトリクスを描きます。プロジェクトの主要な要素を付箋などで各象限に貼り付け、チームで配置を確認しましょう。
各要素について、表を参照しながら「では、これは『will』で話すべきか、『be going to』か」と確認します。このプロセス自体が、不確実性への共通理解を深めます。
あるメンバーが「確信度低」の象限にある要素を「will」（確定的）で説明していたら、それは認識のズレのサインです。なぜその表現を選んだのか、根拠を話し合うきっかけになります。
次回のプロジェクトキックオフや定例会議で、この「予測可能性マトリクス」を試してみてください。混沌とした未来への対話が、構造化され、生産的なものに変わるはずです。
確信度を操る：『will』『be going to』『現在形』の戦略的使い分け
プロジェクトの未来を語る際、どの表現を使うかは単なる文法の選択ではありません。それは、チームメンバーに対して「この未来は、どのくらい確かなのか」「どの程度コントロールできるのか」というメタメッセージを送る行為です。英語の未来表現には明瞭なニュアンスの違いがあり、これを戦略的に使い分けることで、議論の精度と合意形成の質を飛躍的に高められます。
確約と予測の「will」、計画と兆候の「be going to」
まず、最もよく使われる二つの表現を比較しましょう。多くの学習者が混同しがちですが、その違いは「判断の根拠」にあります。
| 表現 | 核となる意味 | 判断の根拠 | プロジェクトでの使用場面 |
|---|---|---|---|
| will | 瞬間的な意志・確約 客観的な予測 | 話し手のその場の判断 一般的な知識・経験 | 新たな約束をする リスクを予測する 即決を表明する |
| be going to | 既存の計画・意図 兆候に基づく予測 | 事前の計画・準備 現在見える兆候・根拠 | 既に決まっている計画を共有 進行中のタスクの完了を宣言 顕在化したリスクを示唆 |
「will」は未来への意志をその場で新たに生み出す表現、「be going to」はすでに進行中の動きや計画の延長線上にある未来を示す表現です。
具体的な場面で考えてみましょう。ミーティング中、新たな課題が発覚したとします。
- 「I will look into this issue and get back to you by tomorrow.」
（この問題を調査し、明日までにご連絡します。）
これはその場での新たな意志表明であり、確約です。一方、すでに着手しているタスクについて話すときは、
- 「We are going to deploy the new feature next Monday as planned.」
（計画通り、来週の月曜日に新機能をリリースする予定です。）
これは「計画」という既存の根拠に基づく未来を示します。また、現在の状況からほぼ確実に起こると予測されることにも「be going to」を使います。「The server load is critically high; it is going to crash if we don’t act now.」（サーバー負荷が危険な水準です。今すぐ対策をしなければクラッシュするでしょう。）というように、現在の兆候が未来を指し示しているのです。
「will」と「be going to」を使い分けることで、「これは約束（will）」なのか「これは計画（be going to）」なのかをチームに明示できます。この違いが、プロジェクト内での「確信度のグラデーション」を生み出します。意志による約束は状況次第で変わりうる一方、計画や兆候に基づく未来はより確固たる土台の上にあります。
確固たるスケジュールと依存関係を示す「現在形」の未来用法
未来を表す最も確信度の高い表現が、「現在形」の未来用法です。これは、変えようのない確固たる予定や、不変のスケジュールを述べるときに用います。主に時刻表やカレンダーに基づく事柄に使われます。
- The project kick-off meeting starts at 10:00 AM sharp tomorrow.
（プロジェクトキックオフ会議は明日の午前10時ちょうどに始まります。） - The contract with the vendor expires at the end of this quarter.
（ベンダーとの契約は今四半期末で失効します。） - If the budget approval is delayed, the entire phase 2 gets postponed.
（予算承認が遅れれば、フェーズ2全体が延期されることになります。）
三つ目の例は、条件節（If節）の中でも現在形が使われる典型的なケースです。「もしAが起これば、Bという結果が（必然的に）起こる」という、依存関係や因果関係を示す不変のルールを表現しています。これはプロジェクトマネジメントにおいて極めて重要です。
この使い分けを明確に意識することで、チーム内でのコミュニケーションは次のように進化します。例えば、あるマイルストーンについて「We will complete the design by Friday.」と言えば、それは「（我々が）金曜日までに終わらせるという意志がある」という約束です。しかし、「The design phase ends on Friday.」と現在形で言い切れば、それは「金曜日にデザインフェーズが終了する」というプロジェクトスケジュール上の絶対的な事実として伝わります。後者は、議論の余地のない前提となり、他の全てのタスクの計画を立てるための確固たる土台を提供するのです。
未来を語る三つの表現を、確信度とコントロール可能性の軸で整理すれば、プロジェクトの不確実な要素を言語的に分解し、それぞれに適した対話を導くことが可能になります。意志と約束には「will」を、計画と兆候には「be going to」を、不変の前提には「現在形」を。この戦略的な選択が、混沌とした未来を、認識可能で管理可能なパーツへと変えていく第一歩です。
仮定性とリスクを可視化する：『would』『could』『might』のファシリテーション力
前のセクションでは、未来を「確信度」と「コントロール可能性」で整理するマトリクスと、それに沿った未来表現の使い分けを学びました。ここからは、より不確実でリスクの高い領域、つまり「もしも」の世界を言語化する技法に踏み込みます。プロジェクトの成功には、楽観的な計画だけではなく、起こりうる障害や条件付きのシナリオをチームで共有し、議論することが欠かせません。この「もしも」の議論を豊かにし、リスクを明確に可視化するのが、助動詞『would』『could』『might』の力です。
条件付きシナリオを構築する「would」の仮定法パワー
『would』は、仮定法過去の中心的な助動詞です。文法書では「現在の事実に反することを表す」と説明されますが、ビジネスの現場では、「明確な条件が満たされた場合に、こうなるだろう」という代替シナリオを議論に導入するための強力なツールとして機能します。
例えば、リソース不足が懸念されるプロジェクトで、「もし、もう2名のエンジニアが追加できれば、納期を2週間前倒しできるだろう」と議論したい場合。ここで単に「エンジニアを増やせば早くなる」と言うのと、『would』を使って「If we had two more engineers, we would be able to move the deadline forward by two weeks.」と表現するのでは、伝わるニュアンスが大きく異なります。
「現在の計画では厳しいですが、もし予算が10%増額できた場合（If we had a 10% budget increase）、マーケティングキャンペーンの規模を拡大し、より大きなインパクトを生み出すことができるでしょう（we would be able to generate a greater impact）。このシナリオについて、どのようなご意見がありますか？」
この発言は、単なる願望を超えて、具体的な条件（予算増額）とその結果（キャンペーン拡大）をセットで提示しています。『would』を使うことで、現状（予算不足）との距離感、つまり「まだ実現していないが、条件次第では可能な未来」を明確に示し、チームの議論を現実的な「条件付き計画」の検討へと導くのです。
可能性の幅を探る「could」と「might」の微妙な違い
『could』と『might』は、どちらも「かもしれない」と訳されることが多く混同されがちです。しかし、この2つを意識的に使い分けることで、リスクの性質をより精緻に言語化できます。
『could』は「能力的可能性」を、『might』は「状況的可能性」を主に表すとされています。つまり、『could』は「（能力・手段・リソースさえあれば）できるかもしれない」というニュアンスが強く、『might』は「（外的な状況・環境次第で）起こるかもしれない」というニュアンスが強いのです。
| 助動詞 | 核心のニュアンス | ビジネスでのリスク分類例 |
|---|---|---|
| could | 能力的可能性 （〜できるかもしれない） | 技術的な実現可能性、チームのスキル不足、内部リソースの制約 |
| might | 状況的可能性 （〜起こるかもしれない） | 市場環境の急変、競合他社の動向、規制変更、天候などの外部要因 |
この違いを活用すれば、リスク分析の質が上がります。例えば、新製品のローンチ日程について、「サプライヤーの納品が遅れる可能性がある（could be delayed）」と言う場合、それはサプライヤー側の生産能力や内部事情に起因するリスクを示唆しています。一方、「経済情勢の悪化で需要が想定より低くなるかもしれない（might be lower）」と言う場合、それは自社ではコントロールしにくい外部環境のリスクを指しています。
ファシリテーターは、「もしも（What if）」で始まる質問を投げかけ、チームの創造的思考を活性化させます。「What if our key partner withdraws?（主要パートナーが離脱したらどうなる？）」
チームから出た懸念事項を、『could』と『might』で整理します。「パートナーの内部事情なら『could』、業界全体の再編なら『might』が適切だ」と議論することで、リスクの根源を探ります。
特定のリスクが現実化した場合の対応策を、『would』を使って条件付きで提案します。「If that happened, we would accelerate talks with our backup partner.（もしそれが起これば、代替パートナーとの交渉を加速させるだろう）」
この一連のプロセスは、漠然とした不安を「言語化可能なリスク」に変え、さらに「実行可能な対応策」へと結びつけます。『would』『could』『might』という助動詞は、単なる文法項目ではなく、不確実性を可視化し、チームの知恵を結集して未来をシミュレーションするための、最も実践的なファシリテーションツールなのです。
実践ワーク：プロジェクトキックオフ会議を言語ファシリテーションでリードする
ここまで、未来表現と助動詞のニュアンスを学んできました。では、実際の会議の場でどのように使えば良いのでしょうか。このセクションでは、架空のプロジェクトケーススタディを通じて、言語ファシリテーションの一連の流れを実演します。具体的には、不確実な要素が多い新規サービスの立ち上げプロジェクトを題材に、メンバーの知恵を引き出し、リスクを可視化し、確かな合意へ導くまでのプロセスを見ていきます。
「予測可能性マトリクス」を使ったブレインストーミングの進め方
まず、プロジェクトの成功に必要な要素と、それに関連する不確実性を可視化するツールを用意します。会議のファシリテーターとしての第一歩は、参加メンバーの「腹落ち感」を生み出すための場づくりです。発言しやすい雰囲気を作り、議論の出発点と到達点を明確に共有することが大切です。
プロジェクト概要：多言語対応の語学学習アプリを、6か月後にリリースする計画。チームは開発、マーケティング、コンテンツ制作の各担当者で構成されています。
会議の出発点：プロジェクトの成功要因とリスク要因を洗い出す。
会議の到達点：洗い出した要素を「予測可能性マトリクス」に整理し、優先度の高い不確実性について合意する。
ブレインストーミングでは、以下のマトリクスをホワイトボードやオンラインボードに用意し、メンバーの意見を書き込んでいきます。
| 確実性 / コントロール可能性 | 高い (Controllable) | 低い (Uncontrollable) |
|---|---|---|
| 高い (Certain) | 四半期1: 内部リソース 四半期2: 既存技術の活用 | 四半期3: 法規制の基本要件 四半期4: 市場の基本的な需要 |
| 低い (Uncertain) | 四半期2: 主要機能の開発スピード 四半期3: コンテンツの品質 | 四半期1: 競合サービスの動向 四半期4: ユーザーの定着率 |
ファシリテーターは、メンバーの発言を促しながら、適切なマトリクスの四半期に要素を貼り付けていきます。この時、発言を「未来表現」で言語化するよう促すのがポイントです。
- 「この機能の開発は、確実に予定通り進みますか？『will meet the deadline』と言えますか、それとも『should』や『could』の方が適切ですか？」
- 「競合の動向は、私たちがコントロールできない分野ですね。彼らが新機能を出す『可能性』はどのくらいだと思いますか？『might launch』ですか、『could launch』ですか？」
こうした問いかけにより、メンバーは単に事実を列挙するのではなく、その事象の確からしさと自らの影響力を評価する思考が促されます。結果として、マトリクスは単なる要素の羅列ではなく、プロジェクトのリスク地図として機能し始めます。
合意形成のプロセスを助動詞でナビゲートする
要素がマトリクスに整理されたら、次は優先度の高い不確実性について議論を深め、合意形成を目指します。ここで意見が対立したり、ニュアンスの違いが生まれた際に、助動詞が強力なナビゲーション役を果たします。
ファシリテーターは多様な意見を瞬時に理解・整理し、重要なポイントを引き出しながら、議論を広げ、最後には収束させて合意形成をサポートします。話が脱線したり論点がずれた際には、目的を再確認して適宜軌道修正することも重要な役割です。
例えば、コンテンツ制作の遅延リスクについて、開発担当者とコンテンツ担当者で見解が分かれたとします。
- 開発担当者A: 「コンテンツの納品が遅れると、統合テストの期間が圧迫されます。スケジュールに確実に（will）影響が出るでしょう。」
- コンテンツ担当者B: 「現在の進捗では、多少の遅れが出る可能性（might）はありますが、追加リソースを投入すれば挽回できるかもしれません（could mitigate）。」
この対立を、ファシリテーターは助動詞を使って整理し、建設的な議論へと導きます。
「なるほど、Aさんは遅れがwill（確実に）影響するとお考えで、Bさんはmight（可能性はあるが確実ではない）と捉え、さらにcould（条件次第で可能）という解決策の芽を示されていますね。つまり、『So, what you’re saying is we might face a delay, but we could mitigate it by allocating additional resources?（つまり、遅延の可能性はあるが、追加リソースの投入で軽減できるかもしれない、ということですね）』と整理できますか？」
このファシリテーションにより、議論は「遅れるか、遅れないか」という二者択一から、「遅れる可能性」と「その対策」という具体的な検討段階へとシフトします。助動詞が、異なる確信度の意見を並列に比較可能な形に「翻訳」したのです。
- 意見の要約と反映：対立する意見を、助動詞の違いを明確にしながら言い換える。「Aさんはwill、Bさんはmightと考えている」。
- 共通認識の確認：両者の発言に共通する要素や、前提を探る。「どちらも『遅れ』をリスク要因と認識している点は一致していますね」。
- 選択肢への収束：条件付きの未来（would/could）を使って、合意可能な選択肢を提示する。「追加リソースが投入できれば（could）、影響は最小限に抑えられるでしょう（would）。では、そのリソース確保の方法について話し合いませんか？」。
最終的に、会議の成果はマトリクスと、そこから導き出された「キーフレーズ」として記録します。例えば、「主要機能開発：will be completed on schedule」、「競合動向：Need to monitor as they could launch a similar feature」といった形です。これらのフレーズは、単なるメモではなく、確信度と前提条件が明確化された行動指針となります。次の計画策定会議では、この記録を基に、「would」や「could」で示された条件付きのシナリオについて、具体的なアクションプラン（誰が、いつまでに、何をするか）を詰めていくことができるのです。
言語ファシリテーションの真髄は、文法を正しく使うこと以上に、言葉のわずかなニュアンスの違いを議論の道具として活用し、チームの集合知を引き出し、形にすることにあります。不確実性に直面した時こそ、未来を語る言葉を丁寧に選ぶことが、プロジェクトを成功へ導く確かな一歩となります。
