実践 NEW
デザイン思考 非営利組織の問題定義ワークショップ｜NGO・NPOが陥る「使命の罠」と突破口
デザイン思考の問題定義フェーズを非営利組織・NGO・NPOに適用する実践ガイド。「使命の罠」「受益者不在の問題定義」「ドナー優先バイアス」という3つの構造的歪みを診断し、How Might Weで問いを再設定するワークショップ設計を解説する。
21分で読める
「使命感があれば問題定義はできている」——非営利組織のワークショップで最初にぶつかる思い込みが、これです。
創設の理念が明確なほど「解くべき問題はわかっている」という前提が強くなる。 しかし実際にやってみると、使命文に書かれた言葉と、受益者が実際に困っている問題の間には、驚くほど大きな溝があることが多い。使命に忠実であることと、問題を正確に定義することは、別の作業です。
デザイン思考の問題定義フェーズをNGO・NPOに適用するとき、企業とは異なる構造的な歪みが必ず登場します。本記事では、その3つのパターンを解剖し、現場で使えるワークショップ設計を提示します。
なぜ非営利組織で「問題定義」が難しいのか
「正しい問い」を立てることへの抵抗感
非営利組織の多くは、強烈な動機から生まれます。難民支援・貧困撲滅・環境保護・障害者自立——いずれも、解決すべき問題は明らかに見えます。この「明らかさ」が、逆に問題定義の精度を下げます。
「問題は決まっている、だから解決策を考えよう」というジャンプが起きる。 しかしデザイン思考が最も強調するのは「正しい問いを立てることこそが最も難しく、最も重要な作業だ」という認識です。難しい問題ほど、「なぜこの問題が起きているのか」の解像度を上げる前に解決策に飛びつく罠があります。
受益者とドナーの二重構造
企業には顧客という単一の「問題を持つ人」がいます。非営利組織には受益者（サービスを受ける人）とドナー（資金を提供する人）という二重の「関係者」が存在します。
この二重構造が問題定義を歪めます。ドナーが「見えやすい成果」を求めるプレッシャーがあるとき、組織は受益者の本質的な問題より「ドナーに報告しやすい問題」を優先的に定義してしまう。参加者からの声として頻繁に出てくるのは「支援者への報告書に書ける数値が、現場の実感とズレている」という葛藤です。
「使命の罠」——正しい理念が正確な問題定義を妨げる
非営利組織固有の現象として、使命文が問題定義の視野を狭める「使命の罠」があります。たとえば「子どもの貧困をなくす」という使命を持つ団体が、インタビューで出てきた「子どもが学校に来ない」という現象を、自動的に「経済的困難が原因」と定義するケースです。
実際に調査を掘り下げると、「親が学校に送り出せる心理的・時間的余裕がない」という別の問題が主因だったということがある。 使命文の言葉が、観察から見えてきた別の構造を「見えないもの」にしてしまう。使命への誠実さが、問題定義の精度を下げるというパラドクスです。
3つの構造的歪みの診断
歪み1：受益者不在の問題定義
非営利組織のプログラム設計が、受益者へのリサーチなしに進むことは珍しくありません。専門家・行政担当者・ドナー担当者が集まって「この地域の問題は○○だ」と定義し、プログラムを設計する。受益者当事者の声は、その後の実施段階で初めて聞かれます。
ワークショップでよく起こるのは、「受益者の声を聞いた」という認識が、実は「支援者から見た受益者像のインタビュー」に留まっているケースです。 支援者が「受益者はこう困っている」と語る内容と、受益者本人が語る内容は、しばしば異なります。
この歪みを診断するチェックリスト：
- 問題定義の会議室に、受益者本人が参加しているか
- 問題定義の根拠となるデータは、誰が収集し、誰の観点から解釈しているか
- 受益者へのインタビューで「あなたが一番困っていること」を直接聞いたことがあるか
歪み2：ドナー優先バイアス
ファンディングの言語が現場の問題定義に浸透する現象です。助成金の申請要件が「就労支援プログラムの実施」であれば、組織は現場で見えている「就労への心理的障壁」より「就労スキルの不足」を問題として定義しやすくなります。
「予算がつく問題」と「本当に解くべき問題」が乖離するとき、支援は届いているが変化が起きないという状況が生まれます。
この歪みを可視化するワーク：問題定義ステートメントを書いた後、「この問題定義は、ドナーへの報告書にそのまま使えるか」を問う。「はい」と即答できるとき、ドナーバイアスが混入している可能性が高い。ドナーに報告しにくい問題こそ、本質的な問題かもしれません。
歪み3：「解決策から遡った」問題定義
既存プログラムが先にあり、その正当化として問題定義が後付けされるパターンです。「3年間実施してきた食料支援プログラムがある。だから問題は食料へのアクセス不足だ」という順序の逆転です。
プログラムを廃止・変更することへの内部抵抗が、問題定義を固定化させます。 実際にやってみると、このパターンは最も発見しにくい。「うちは常に受益者のニーズを見ている」と自認する組織でも、既存プログラムを守るための無意識な問題定義の歪みが起きています。
発見のヒント：チームに「もし既存プログラムが存在しなかったとしたら、同じ問題定義をするか」を問う。答えが「分からない」なら、既存プログラムが問題定義を歪めている可能性があります。
問題定義ワークショップの設計
ステップ1：使命文の「括弧入れ」（30分）
ワークショップの冒頭で、使命文を一時的に「括弧に入れる」作業を行います。参加者に使命文を書き出させ、その後「今日のワークショップでは、使命文に書かれていない言葉だけを使って問題を語ってみましょう」と指示します。
この制約が、使命文の言葉への依存を意識させ、観察に立ち返るきっかけになります。 使命文の言語から離れると、現場のエピソードが出てきやすくなる。「ある受益者が言っていた言葉」「フィールドで何度も見かけた行動」が、制約を設けることで流暢に語られ始めます。
ステップ2：受益者エピソードの収集（60分）
チームメンバー全員が、受益者との実際のやり取り・観察した場面をA4用紙1枚に書き出します。解釈や分析ではなく、「誰が・いつ・どこで・何をしていたか・何を言ったか」の事実のみを記録するよう指示します。
ポイントは「なぜ」という解釈を、この段階では書かせないことです。 「なぜ」を考え始めると、既存の理解フレームが事実の記述に滑り込んでくる。まず事実を集め、そこから解釈を構築するという順序を守ることが、受益者不在バイアスを防ぐ最初の手段です。
全員のエピソードを壁に貼り出し、沈黙で30分間読み合わせます。声に出して議論するのではなく、「同じパターンを感じる場所に付箋を貼る」という非言語のアフィニティマッピングが有効です。
ステップ3：「驚き」の抽出（30分）
貼り出されたエピソードから、チームの予測・使命文の言語・既存プログラムの設計思想と「ズレていた」ものを選び出します。「驚いた」「想定と違った」エピソードこそが、問題定義の精度を上げる素材です。
選んだエピソードについて、「なぜこれが起きているのか」を3段階で掘り下げます。最初の「なぜ」は表面的な理由、2番目の「なぜ」は組織・制度的な要因、3番目の「なぜ」は文化・価値観・信念の層に届くことが多い。この3層構造の探索が、使命の罠を突破するための核心です。
ステップ4：POV文のドラフト（45分）
d.schoolが定式化したPOV文（Point of View Statement）のフォーマットを使って問題定義を言語化します。
[ユーザー]は、[ニーズ]を必要としている。なぜなら[インサイト]だから。非営利組織のワークショップでは、このフォーマットの「ユーザー」を「受益者」に、「ニーズ」を「受益者が語った言葉に最も近いもの」に置き換えることを明示的に指示します。 支援者の視点から見た「あるべきニーズ」ではなく、受益者の言葉から引き出したニーズを選ぶことが重要です。
複数のPOV文を並べ、「これはドナーへの報告書で使いやすいか」「これは使命文の言語に近いか」という2つの問いで評価します。両方「はい」のPOV文は、バイアスを含む可能性があります。「どちらも違う」と感じるPOV文が、最も本質的な問題定義に近いことが多い。
ステップ5：How Might We（HMW）の生成（30分）
POV文から、How Might We（どうすれば私たちは〜できるか）の問いを生成します。HMWは問題を「チームで解決できる挑戦」に変換する言語的な操作です。
非営利組織のHMW設計で気をつけるのは、問いが組織のリソース・権限・既存プログラムに引きずられないようにすることです。 「どうすれば私たちの予算内で〜」「どうすれば現在のスタッフで〜」という制約が最初から入ると、問いの幅が狭くなります。制約を外した「理想のHMW」を先に生成し、そこから現実的な制約を段階的に加えるという順序が有効です。
実践のポイント：ファシリテーターが抑えるべき5つの場面
場面1：「使命文を読み上げる参加者」への対応
ワークショップ中に「でも私たちの使命は○○なので」という発言が出たとき、それを否定せず「その使命に照らしたとき、今日集めたエピソードの中で最も使命から遠い場面はどれですか」と問い直す。使命文を「正解」ではなく「問い返しの道具」として使います。
場面2：「受益者はこういう人たちだ」という決めつけ
「受益者は○○なので」という発言が出たとき、「その理解は誰のどのような観察から来ていますか」を問う。「決めつけ」は、受益者についての豊かな観察から来ていることもあれば、支援者の先入観から来ていることもあります。 根拠を問うことで、どちらかが可視化されます。
場面3：解決策への早期ジャンプ
「この問題には○○が有効だと思います」という発言が出たとき、「それは素晴らしいアイデアです。一度どこかに書き留めておいて、今は問題の定義に戻りましょう」と受け流す。解決策のアイデアを完全に否定しないことが参加者の心理安全を保ちつつ、プロセスを守るコツです。
場面4：「すでに調査している」という抵抗
「アンケートで1000件のデータを取っている」「毎週レポートを集計している」という発言への対応です。データの存在を認めた上で「そのデータは受益者の言葉で記録されていますか、それとも私たちの分析カテゴリで集計されていますか」と問う。量的データと受益者の生の言語は別物です。 両方必要であることを説明します。
場面5：ドナーへの配慮が問題定義に入り込む
「でもこれを書いたら助成金が取れない」という発言は、ドナーバイアスが表面化した瞬間です。これを責めず「今日は問題を正確に把握する作業をしています。ドナーとのコミュニケーションは、正確に問題がわかってから設計しましょう」とリダイレクトします。正確な問題定義がある方が、長期的にはドナーとの関係も深まるという実態を説明することも有効です。
ワークショップ設計の全体像
| フェーズ | 時間 | 手法 | 目的 |
|---|---|---|---|
| オープニング | 15分 | 使命文の括弧入れ | 前提をいったん外す |
| エピソード収集 | 60分 | カード記述 + アフィニティ | 受益者の事実を集める |
| 驚きの抽出 | 30分 | ドット投票 + 3段のなぜ | 使命の罠を診断する |
| POV文ドラフト | 45分 | POV文フォーマット | 問題定義を言語化する |
| HMW生成 | 30分 | ブレインライティング | 問いを挑戦に変換する |
| クロージング | 15分 | 振り返りカード | 次の調査ステップを設計する |
| 合計 | 195分（3時間15分） |
参加者の最適構成
ファシリテーター1名と参加者5〜8名が理想的な規模です。必ず受益者当事者または受益者と直接接する現場スタッフを1〜2名含めること。プログラム設計者・経営層・ファンドレイザーが参加する場合、受益者視点を持つ参加者が少数になりすぎないよう構成を調整します。
参加者からの声として多いのは「受益者に来てもらうのは難しい」という点です。 代替策として、受益者が実際に話した言葉を録音・書き起こしたものを持ち込む「代理声」の手法があります。受益者本人の参加よりは情報量が減りますが、支援者の解釈が入っていない言葉を参照できる点で有効です。
問題定義の品質を上げる4つの基準
基準1：受益者の言語で書かれているか
POV文に含まれる「ニーズ」の記述が、受益者がインタビューや観察で実際に使った言語に近いかを確認します。「支援者の分析言語」（「セルフエフィカシーの低下」「社会関係資本の不足」）ではなく「受益者の生きた言語」（「どうせ自分には無理だと思っている」「頼れる人が周りにいない」）で書かれているかが判断基準です。
基準2：「なぜそうなっているか」の仮説があるか
問題の定義に留まらず、「なぜその問題が起きているか」の初期仮説を含んでいるかを確認します。インサイトのないPOV文は、次のイデエートフェーズで発散しにくくなります。 「なぜなら○○だから」の部分が、チームが一番時間をかけるべき箇所です。
基準3：解決策に依存していないか
問題定義の文章が、暗黙的に特定の解決策を前提にしていないかを確認します。「○○プログラムを受けられる環境がない」という問題定義は、既存プログラムへのバイアスが入っています。「○○が十分に得られていない」という形に変換することで、解決策への依存を取り除けます。
基準4：チームの複数メンバーが「腑に落ちる」か
技術的な正確さより、「これは確かにそういうことが起きている」というチームの共感が重要です。問題定義は、事実からの論理的な導出である同時に、チームの共同理解の結晶です。 チームの誰かが「これは実感と違う」と感じるなら、再度エピソードに戻って検討する余地があります。
よくある失敗パターンと対処法
失敗1：3時間かけて「使命文の言い換え」しか出ない
これは使命の罠が最も強く作用しているケースです。ワークショップの冒頭に「今日の目的は使命文を検証することではなく、使命文の正しさを疑ってみることです」と明示的に宣言することで、心理的な安全を先に確保します。
失敗2：受益者インタビューのデータがない状態で実施する
問題定義ワークショップは、受益者への一次調査の後に実施するのが原則です。調査なしで実施すると、参加者の「受益者についての思い込み」を整理するだけになります。最低でも受益者5〜8人へのインタビューを事前に完了させることを前提条件にすることを推奨します。
失敗3：POV文が複数できて絞り込めない
3〜5個のPOV文候補が残ったとき、「どれが正しいか」ではなく「どれを先に探索するか」という問いに変換します。問題の定義は1つに絞らなければならないルールはありません。複数の問題定義を持ったままイデエートに進み、それぞれの問題定義に対するHMWを並行して展開する方法も有効です。
失敗4：チームの中で問題定義に合意できない
合意できないこと自体が重要なデータです。「なぜ同じ情報を見て、異なる問題定義に至るのか」を問うことで、チームメンバーが持っているメンタルモデルの差異が可視化されます。この差異は、受益者と接する場面での認識の差異でもある可能性が高い。問題定義の合意より先に「認識の差異の地図を作る」ことに目的を切り替えます。
「やってみよう」：30分から始める問題定義の自己診断
フルワークショップの前に、チームで試せる30分の自己診断を紹介します。
STEP 1（10分）： チームで現在のプログラム・活動の「問題定義」を1文で書き出す。
STEP 2（10分）： 書いた1文を読み、以下を確認する。
- 受益者の言葉が入っているか
- 「なぜそうなっているか」の仮説が入っているか
- 既存プログラムの言語が前提になっていないか
- ドナーの要求する言語に近すぎないか
STEP 3（10分）： もし上の4つのうち2つ以上に「いいえ」なら、「受益者に直接聞いたとしたら、この問題定義をどう言い直すか」を書いてみる。
この30分で出てくる違和感こそが、フルワークショップに投資する価値がある場所です。 問題定義を疑うことは、使命を否定することではありません。より正確に問題を解くための、使命への誠実な向き合い方です。
関連リソース
問題定義フェーズの詳細理解には、defineフェーズの概要を参照してください。POV文の具体的な書き方はPOV文作成ガイドで詳しく解説しています。問題定義から創造フェーズへの接続についてはHow Might Weの実践手順も合わせて参照してください。受益者インタビューの設計についてはユーザーインタビューの手法が参考になります。問題定義を支える共感フェーズの全体像は共感フェーズのガイドにまとめています。組織変革としてデザイン思考を定着させる文脈では組織導入の完全ガイドも参照してください。
参考文献
- Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperBusiness. ── デザイン思考のプロセスにおける問題定義の重要性について体系的に論じた古典的著作。
- Buchanan, R. (1992). “Wicked Problems in Design Thinking.” Design Issues, 8(2), 5–21. ── デザイン思考が扱う「厄介な問題」の構造を定義した先駆的論文。非営利領域の複雑な問題定義への示唆を含む。
- Liedtka, J., & Ogilvie, T. (2011). Designing for Growth: A Design Thinking Toolkit for Managers. Columbia University Press. ── 組織の問題定義プロセスへのデザイン思考適用について実践的に論じている。
- IDEO.org (2015). The Field Guide to Human-Centered Design. IDEO. ── 非営利・社会課題領域へのデザイン思考適用に特化したガイド。受益者視点を中心に置いたフィールドワーク手法を詳述。
- Martin, R. (2009). The Design of Business: Why Design Thinking is the Next Competitive Advantage. Harvard Business School Press. ── 問題定義の「知識のファネル」概念を提示し、アブダクティブ推論の重要性を論じる。
- Nussbaum, M. (2011). Creating Capabilities: The Human Development Approach. Harvard University Press. ── 受益者中心の問題定義の倫理的基盤として、ケイパビリティアプローチの視点を提供する。