企業の現場で「決めたのに動かない」をなくすには、女性リーダーが“動きが見えるToDo”を設計することが要です。まずIDS（Identify・Discuss・Solve）の全体像をおさえ、次にSolve(解決)で「誰が・何を・いつまでに・どう検証するか」を決め切ります。さらに、他部署の時間を使う依存タスクまで合意し、実行率を引き上げましょう。
IDSとは？｜企業の会議を前進させる3ステップ
IDSはEOS（起業家型組織運営システム）の課題解決フレームです。まずIdentify（原因を特定）、次にDiscuss（議論）、最後にSolve（解決）。この順番で会議を進めると、結論が実行に直結します。詳しくは先行記事も参照ください：I＝Identify ／ D＝Discuss
Solve(解決)の目的｜“決め切り”で実行率を上げる
決め切りの5要素（Owner／Outcome／Due／Evidence／DoD）
- Owner（誰が）：フルネーム＋役割で唯一人。部門名ではなく個人名にします。
- Outcome（何を）：成果物or状態を具体化（例：返品フロー案を3案作成し承認依頼）。
- Due（いつまでに）：日付・時刻まで固定。遅延時の代替手順も合意。
- Evidence（どう検証）：提出物・テスト方法・承認者を明記。
- DoD＝Definition of Done（完了の定義）：「ここまでできたら完了」を一文で固定。
依存タスクの合意（他部署・外部の時間を使う場合）
他部署レビュー、情報システムの改修、法務チェック、仕入れ調整など、他者の時間を使うToDoはSolve(解決)の場で合意をとります。つまり、「誰のどれくらいの時間が必要か」を先に確定させます。
- 依存先Owner（部署・氏名）／代替Owner
- 受付条件（必要情報・フォーマット・締切）
- 所要時間（リードタイム）の見積り
- 合意方法（L10で口頭／Slack承認／メール同意）
企業で起きがちな失敗と対策
責任者あいまい／期限あいまい／抽象ToDo
「担当：◯◯部」「来週中」「対応する」――これでは動きません。まず、所有者が分散します。次に、期限が解釈依存になります。さらに、成果が測れません。したがって、Owner・Outcome・Due・Evidence・DoDを必ず明文化します。
人の手を借りるToDoは、合意がないと止まります
レビュー依頼が「投げっぱなし」だと会議後に止まります。
しかも、受け手は自分のタスクやToDoがぎっしりの中、内容を十分に理解しないまま期限付きで届くと驚きと強いプレッシャーを感じます。
とりわけ依頼者が上位者だと、「自分の作業を捨ててでもやらねば」という圧力が生まれ、現場の優先順位が崩れがちです。
だからこそ、Solve(解決)の場で受付条件・所要時間・承認者に加えて、受け手が何を止める（トレードオフ）かまで合意しましょう。女性リーダーがここを丁寧に設計すると、合意形成のストレスが減り、結果として全体のスループットが上がります。
- 背景と目的を一文で（なぜ今それが必要か）。
- 所要時間の目安（例：レビュー60分）と柔軟な期限の提案。
- トレードオフの明示（「Aタスクを一時停止でOK？」など）。
- 承認者と受付条件（フォーマット・判断基準）を最初に共有。
良いSolve／悪いSolveの比較表（企業・女性リーダー向け）
| 項目 | 悪いSolve（決め切れていない） | 良いSolve（実行につながる） |
|---|---|---|
| ToDo | 「対応する」「検討する」など抽象的で成果が不明。 | 成果物・状態が明確（例：新フロー案3案を作成しA氏へ提出）。 |
| 責任者 | 「みんなで」「◯◯部」など分散。 | 唯一人のフルネーム＋役割で固定。 |
| 期限 | 「来週中」「月内」など解釈の余地が大きい。 | YYYY/MM/DD hh:mmまで特定。遅延時の代替手順も合意。 |
| 検証 | 次回確認なしでうやむや。 | L10(10点満点ミーティング)でEvidenceを確認。完了率をスコアカードで追跡。 |
| 依存タスク | 他部署の時間を見積らず途中で停滞。 | 依存先Owner／受付条件／所要時間／合意方法をSolveで確定。 |
| 再発防止 | 属人的で同じ課題が再燃。 | 決定を手順化し、アカウンタビリティチャートに反映。 |
“動きが見えるToDo”設計フレーム
先に確認：「始める条件」と「止まりそうな壁」
まず、開始に必要な準備（データ・権限・予算）をそろえます。次に、止まりそうな要因（繁忙期・システム制約・承認待ち）を特定し、解除手順まで決めておきましょう。
受入基準（DoD）とハンドオフ
完了時に「どの状態ならOKか」を一文で固定。次の担当へのハンドオフ先・フォーマット・期限もSolve(解決)時に決めます。つまり、終わり方まで設計します。
リスクへの備え（代替案・バッファ）
万一の遅延に備えて、代替Ownerや暫定策を事前合意。さらに、バッファをDueに含めると現実的なスケジュールになります。
コピー用テンプレ｜ToDo記入フォーマット
- ToDo：（成果物／状態を具体的に）
- Owner：（フルネーム＋役割）
- Due：（YYYY/MM/DD hh:mm）
- Evidence：（提出物／確認方法／承認者）
- DoD：（完了の定義を一文で）
- Dependencies：（依存先Owner／受付条件／所要時間／合意方法）
- Risks & Blockers：（想定リスクと解除手順）
L10(10点満点ミーティング)で回す｜“決める→やる→検証”の運用
ToDo完了率をスコアカードで追う（目標90％）
スコアカードに「ToDo完了率（直近1週間）」を追加。未完了が積み上がる場合は、そのまま今週のIDSに再掲し、真因を再特定します。
アカウンタビリティチャートで役割を固定
Solve(解決)で決めた役割が継続タスクなら、アカウンタビリティチャートへ反映。属人化を避け、再現性を高めます。女性リーダーはここを徹底すると、組織学習が加速します。
未完ToDoの扱い（持ち越さない）
未完了は「忘れ物」ではありません。したがって、Discuss(議論する)に戻して障害を解消し、Solve(解決)で再度「誰・何・いつ・どう検証」を決め直します。
まとめ｜Solve(解決)は“締め”ではなく“スタート”
会議の価値は、決定が動くかどうかで決まります。だからこそ、SolveではOwner・Outcome・Due・Evidence・DoD・Dependenciesまで決め切る。さらに、L10とスコアカードで検証し、手順化して再発を防ぐ。これが、企業の現場で“動きが見えるToDo”を実装する方法です。
あわせて読む｜IDS三部作
I＝Identify｜真因を一行で定義する
D＝Discuss｜最善策を選ぶ建設的な議論法
参考書籍『TRACTION』の活用ポイント
本記事で紹介したSolveは、EOS（起業家型組織運営システム）の公式ガイドブック『TRACTION』で体系的に解説されています。著者ジーノ・ウィックマンは、まず真因を見極め（Identify）、次に建設的に議論し（Discuss）、最後に“決め切って実行”へつなぐ（Solve）重要性を強調します。
とくに本稿のテーマに直結するポイントは次のとおりです。つまり、会議の決定を“動くToDo”へ変える具体策です。
- Solveの要件を明文化：Owner／Outcome／Due／Evidence／DoDをその場で確定する。
- 依存タスクの合意：他部署の時間を使う場合は、受付条件・所要時間・承認者・合意方法まで決める。
- L10で検証を習慣化：ToDo完了率と提出物で翌週チェック。未完は再びIDSへ。
- 仕組み化で再発防止：決定事項は手順化し、アカウンタビリティチャートとスコアカードに反映。
さらに、『TRACTION』は「当事者が揃わない場では結論を出さない」「雑談は課題リストへ移してIDSで扱う」といった運用原則も示します。したがって、女性リーダーは場を整え、合意形成のストレスを減らしながら、組織全体の実行率を高められます。
会議の空回りを減らし、決定を着実に前進させたい経営者・リーダーにとって、『TRACTION』は必携の一冊です。
▶ 『TRACTION』 ビジネスの手綱を握りなおす 中小企業のシンプルイノベーション
ジーノ・ウィックマン 著
