ストーリー
田
田中VPoE
カイゼンの思想は理解したな。次は「仕組み」だ。思想だけでは改善は始まらない。誰でも簡単に提案でき、迅速に評価され、実行に移される仕組みが必要だ
あなた
提案制度というと、「提案箱」のようなものですか？
あ
田
田中VPoE
「提案箱」は失敗する典型例だ。入れっぱなしで何も起きない。大事なのは、提案から実行、評価までの一連のフローが設計されていることだ
あなた
提案の品質も気になります。的外れな提案が大量に来たらどうするんでしょう
あ
田
田中VPoE
いい質問だ。「提案の品質」より「提案の量」が最初は大事だ。量を確保することで、自然と質も上がっていく。まずは提案しやすい仕組みを作ろう
改善提案制度の設計原則
| 原則 | 説明 | アンチパターン |
|---|---|---|
| 低い提案ハードル | 誰でも3分で提案できる | 提案書のフォーマットが5ページ |
| 迅速なレスポンス | 48時間以内にフィードバック | 提案して3ヶ月間音沙汰なし |
| 透明なプロセス | 提案の状況が誰でも見える | 提案がブラックボックスに入る |
| 実行までの速さ | Quick Winは2週間以内に実行 | 承認に6ヶ月かかる |
| フィードバックの質 | 却下の場合も理由を明確に伝える | 「検討の結果見送り」だけ |
提案フローの設計
4段階提案フロー
改善提案フロー:
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 提案 │ → │ 評価 │ → │ 実行 │ → │ 振り返り │
│ (Submit) │ │ (Assess) │ │ (Execute)│ │ (Review) │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
目標: 目標: 目標: 目標:
3分以内で 48時間以内に Quick Win 実行後2週間
提案可能 フィードバック 2週間以内 以内に効果測定提案テンプレート（軽量版）
| 項目 | 記載内容 | 例 |
|---|---|---|
| 何を改善したいか | 問題の簡潔な説明 | 「コードレビューの待ち時間が平均2日かかっている」 |
| どう改善するか | 具体的な改善案 | 「レビュー専用の時間枠を毎日30分設ける」 |
| 期待する効果 | 改善後の姿 | 「レビュー待ち時間を1日以内に短縮」 |
| 必要なリソース | 何が必要か | 「チームの合意のみ（追加コストなし）」 |
評価基準
| 基準 | 重み | 評価方法 |
|---|---|---|
| 効果の大きさ | 30% | 改善によるインパクト（時間削減、品質向上等） |
| 実現容易性 | 30% | 必要なリソース・期間・技術的難易度 |
| 影響範囲 | 20% | チーム内 / 部門 / 組織全体 |
| 整合性 | 20% | 組織の目標・方針との整合 |
提案の分類と対応
| 分類 | 基準 | 対応 | 期限 |
|---|---|---|---|
| Quick Win | 効果大 × 工数小 | 即座に承認、チームで実行 | 2週間以内 |
| プロジェクト型 | 効果大 × 工数大 | 改善プロジェクトとして計画 | 四半期単位 |
| 実験型 | 効果不明 | パイロットで検証 | 1ヶ月以内 |
| 見送り | 効果小 or リスク大 | 理由を説明して見送り | 48時間以内に通知 |
デジタル提案プラットフォーム
ツールの選定
| ツール | 特徴 | 適用場面 |
|---|---|---|
| Slack + ワークフロー | 既存ツールで軽量に実現 | 少人数組織（〜100名） |
| Jira/Linear | チケット管理と統合 | 開発チーム向け |
| 専用SaaS（Kaizen Board等） | 提案・評価・追跡を一元管理 | 大規模組織（100名〜） |
| Notion/Confluence | ドキュメント型で詳細な提案 | ナレッジ重視の組織 |
Slackを使った軽量実装例
| 要素 | 実装方法 |
|---|---|
| 提案の投稿 | /kaizen コマンドでフォーム入力 |
| 一覧の管理 | #kaizen-proposals チャンネル |
| 投票 | リアクション（賛成/反対/質問）で簡易投票 |
| ステータス管理 | スレッドで進捗更新 |
| 月次レビュー | #kaizen-review チャンネルで結果報告 |
提案制度の落とし穴と対策
| 落とし穴 | 症状 | 対策 |
|---|---|---|
| 提案疲れ | 初期の盛り上がりが3ヶ月で消える | 小さな成功を定期的に可視化する |
| 評価の停滞 | 提案が溜まって評価が追いつかない | 評価担当のローテーション制を導入 |
| 実行の先送り | 承認されたのに実行されない | 改善タスクをスプリントバックログに組み込む |
| 大物志向 | 小さな改善が軽視され、大きな提案ばかりになる | 小さな改善の積み重ねを数値で評価する |
| 形骸化 | 提案はあるが内容が薄い | 好事例の共有と表彰で質を引き上げる |
まとめ
| ポイント | 内容 |
|---|---|
| 設計原則 | 低いハードル、迅速なレスポンス、透明なプロセス |
| 提案フロー | 提案→評価→実行→振り返りの4段階 |
| 分類と対応 | Quick Win、プロジェクト型、実験型、見送り |
| ツール | 組織規模に応じたプラットフォーム選定 |
チェックリスト
- 改善提案制度の設計原則を理解した
- 4段階提案フローを把握した
- 提案の分類と対応方法を理解した
- 制度の落とし穴と対策を認識した
次のステップへ
次は「イノベーションタイムを制度化しよう」を学びます。改善活動に使える「公式な時間」をどう確保するかを探ります。
推定読了時間: 30分