
メンテナンス部門のリーダーと話したとき、こんな言葉を聞いた。
「ヒアリングは30件以上やりました。でも、何を課題として書けばいいのか、全然わからないんです。」
ホワイトボードには付箋が溢れていた。「情報を探すのに時間がかかる」「あの部署の返信が遅い」「ベテランが教えてくれない」——どれも現場の本音だ。
でも、そのまま提案書の課題欄に書こうとすると、手が止まる。
なぜ課題なのか、説明できない。部長が何を見て判断するのかもわからない。30件のうち何を選べばいいのかも、わからない。数字を入れ、フレームワークを使い、客観的に書いても、上司からは「なんか違う」「本当にこの内容?」と返される。
このリーダーがダメなのではない。課題の「整理の仕方」を教わっていなかっただけだ。そして整理の軸がなければ、どれだけヒアリングしても答えは出ない。
実際に僕がコンサルとして関わったとき、ヒアリング結果をそのまま課題にしようとすると「なぜ課題なのか説明できないもの」が半数以上あった。それを使える課題に変換するには、整理のフレームが必要になる。
この記事では、まず課題欄でよくある5つのNG書き方と、それが通らない理由を示す。そのうえで、QCD(品質・コスト・納期)とルール視点を使って、ヒアリング結果を提案書に載せられる課題に変換する手順を、NG→OKの対比サンプルつきで解説する。
- As-Is/To-Be型・数字だけの定量化・3M/QCDの分類止まり・なぜなぜ分析・抽象的な客観化の5つは、目的を理解せずに使うと「なんか違う」と返されるNG書き方になる
- 「課題」の目的は部長との合意(縦)と関係者の共通認識(横)の2つ。NG書き方はどれも「事実の記述」で止まり、この目的を満たせていない
- QCD(品質・コスト・納期)とルール視点(決まっていない/守れない/ボトルネック)の2軸で整理し、属人・他部門・方法論・解決不能の4つを除外すれば、承認される課題に変換できる
業務改善提案書の「課題」を書く前に知っておくべき原理:目的と2ステップの全体像

まず前提として、「課題」は何のために書くのかを整理しておきたい。
目的は2つだけだ。
1つ目は、部長と課題を合意すること(縦・承認)。「この課題に取り組む価値がある」と上位者に認識してもらうためだ。
2つ目は、関係者と課題を共通認識すること(横・実務)。現場の担当者が「自分たちの仕事にどう関係するか」を理解するためだ。
ここで重要なのは、この段階は「投資判断」ではないという点だ。費用の話、ROIの話は後続の「解決策」と「費用対効果」のセクションで行う。課題のフェーズで「このシステムを導入すると〇〇万円かかります」という話を持ち込むと、承認の目的がズレる。部長はまず「この課題は本当に存在するのか」を確認したいのだ。
この目的を理解したうえで、課題設定は2ステップで進める。
ステップ1:ヒアリング(否定しない・全部聞く)
ステップ2:QCDとルール視点での整理
ステップ1は発散フェーズ、ステップ2は収束フェーズだ。この順番を逆にしてはいけない。
よくある失敗は、あらかじめ「この課題にしよう」と決めてからヒアリングする形だ。すると担当者の話を都合よく解釈してしまい、核心的な課題が見えなくなる。
メンテナンス部門での実例を話すと、最初に「まず全部聞こう」と判断して否定せずにヒアリングを進めた。その結果、後半になって担当者から「フィールドエンジニアからの問い合わせ先がメンテナンスサポートに決まっているのに、誰も守っていない」という話が出てきた。これが納期課題の核心だったが、最初から絞り込んでいたら見落としていた可能性が高い。
この記事は業務改善提案書の「課題」セクションに特化した解説です。提案書全体の構成については、業務改善提案書の書き方【構成と通し方を完全解説】で解説しています。
業務改善提案書の「課題」でよくある5つのNG書き方
As-Is/To-Be型のギャップ分析、数字での定量化、3M・QCDによる分類、なぜなぜ分析、客観性の確保。課題の書き方として広く勧められている手法だが、どれも「間違い」ではない。目的を理解せずに使うとNGになるのだ。
NGパターン①:As-Is/To-Be型のギャップ記述
現状と理想のギャップを、そのまま課題として書くパターンだ。
NGサンプル:「現状:情報管理は個人任せで共有されていない。理想:全情報が一元管理される状態。課題:情報管理システムが整備されていないこと」
「システムが整備されていない」は手段の欠如であり、それによってQCD上の何が起きているのかが書かれていない。部長は「だから何が問題なの?」と感じる。
NGパターン②:数字だけの定量化
「残業が多い」を数字に変えれば通ると考えるパターンだ。
NGサンプル:「月間残業時間:チーム合計120時間。ミス発生件数:月15件」
数字があっても、なぜその状態になっているのか(原因)が書かれていなければ課題にならない。さらに体感と事実のズレもある。メンテナンス部門で実際に計測したところ、担当者が「大体3時間」と言った工程は5時間半かかっていた。管理職へのヒアリングだけで集めた体感値は「事実の数字」ではない。
NGパターン③:3M・QCDで分類して終わる
ヒアリング結果をムリ・ムダ・ムラやQCDの箱に仕分けして、それを課題とするパターンだ。
NGサンプル:「ムダ:情報検索に時間がかかっている(QCD:コスト)。ムラ:担当者によって対応品質が異なる(QCD:品質)」
分類は「整理」であって、原因の特定ではない。仕分けた箱の中に「解決すべき障壁」はまだ入っていない。後で説明するとおり、QCDは影響範囲を決める1つ目の軸にすぎず、原因はルール視点で診断する必要がある。
NGパターン④:なぜなぜ分析の答えをそのまま書く
「なぜ?」を5回繰り返して出てきた答えを、そのまま課題として書くパターンだ。
NGサンプル:「なぜなぜ分析の結果、根本原因は担当者の意識不足と教育体制の未整備であることが判明した」
掘り下げた先が「個人の意識・能力」「他部門の協力不足」「少子化による人材不足」に行き着くことが多い。どれも自部門がコントロールできないため、提案書の課題として機能しない。
NGパターン⑤:客観性を意識しすぎた抽象表現
「〇〇さんが遅い」「開発部門が協力しない」を避けようとして、抽象的な記述になるパターンだ。
NGサンプル:「対応プロセスにおいて情報の流通が最適化されていない部分がある」
客観的ではあるが、何も言っていない。属人的な表現を避けた結果、課題の輪郭まで消えている。
5つに共通するのは、どれも「事実の記述」で止まっていることだ。先に見た課題の目的に照らすと、部長が「この課題に取り組む価値がある」と判断できる根拠、つまりなぜその状態になっているのかが書かれていない(縦が満たせない)。現場の担当者が「自分たちの仕事のどこに関係するのか」も読み取れない(横が満たせない)。
横が取れていないと、「一旦これで進めよう」と言われたのに、予算の段階で他のプロジェクトに優先を奪われることがある。現場が「自分たちに関係のある課題」と受け止めていないので、承認の場面で後押しが来ないからだ。自部署だけを楽にして他部署に負荷を移す課題設定も、全体最適の視点が欠けているとして通らない。
では、「なぜ」の層をどう書き足すのか。それが次のQCDとルール視点の2軸だ。
QCDとルール視点で課題を整理する:シーン別の適用手順

課題の整理に使う軸は「QCDとルール視点の2軸」だ。品質・コスト・納期のどこに問題があるかを特定し、さらにルールの状態(決まっていない/守れない/ボトルネック)で「なぜそうなっているか」を診断する。この2軸の組み合わせが、ヒアリング結果を承認される課題へ変換する最短経路になる。
ヒアリングが終わったら、いよいよ整理に入る。
QCDで整理する
「課題」は「問題」の原因となっている障壁のことだ。業務改善提案書の「問題」セクションでQCD上の問題(品質が低い、コストが高い、納期が長い)を先に特定しているはずなので、それを前提に「なぜそうなっているか」を書く。
整理の問いはこうなる。
- 品質を向上できない理由は何か → 業務フローのルールの問題が多い
- コストを低減できない理由は何か → 情報システムや業務環境の問題が多い
- 納期を短縮できない理由は何か → 業務フローのルールの問題が多い
メンテナンス部門の実例で見てみよう。
品質:複数の工場・設備で同じ問題が発生しているが、知識が共有されず属人化している。同じ問題に各担当者が1から調査して対処しており、対応のヌケモレがトラブルの再発につながっている。業務フローのルールの問題だ。
コスト:準備時に顧客・設備・技術情報を集めるが、情報を探すのに時間がかかり、必要な情報を揃えられていない。現地でわからないことが多く、問い合わせが多数発生する。フィールドエンジニアとメンテナンスサポートの情報管理は個人任せで、組織内での再活用が難しい。情報システムの課題だ。
納期:フィールドエンジニアからの問い合わせ先はメンテナンスサポートのみと決められているが徹底されていない。返信が少し遅いと、各コネで営業部門や開発部門に直接問い合わせてしまう。業務フローのルールの問題だ。
自分の職場のヒアリング結果を、このQCDの軸に当てはめてみると、どこに分類されるかが見えてくる。
ルール視点で整理する
QCDで分類したあと、さらに「なぜそうなっているか」をルール視点で診断する。
ルールの状態は、次の3パターンに分けられる。
- ルールが決まっていない → 課題:「ルールを決める必要がある」
- ルールは決まっているが守れていない → 課題:「ルールにムリがあり修正が必要」
- ルールは守れているがボトルネックが発生している → 課題:「ルールを改善する必要がある」
先ほどの納期課題(問い合わせ先ルールの未徹底)は「ルールは決まっているが守れていない」パターンだ。ではなぜ守れていないのか。掘り下げると「メンテナンスサポートの返信スピードにムリがある」という別の課題が見えてくる。ルール視点を使うと、表面的な課題の裏にある構造的な問題まで辿り着ける。
できる人とできない人の差で整理する
もう一つの軸として、「できている人とできていない人の違いは何か」を確認する方法がある。
- 資料があればできる → 技術情報・知識の問題(ナレッジ共有・マニュアル整備が課題)
- 練習が必要 → 技能の問題(教育・OJTが課題)
- ルールを守るメリット・守らないデメリットを知らない → 動機づけの問題(周知・フォローが課題)
属人化の課題(品質)は典型的な「資料があればできる」ケースだ。ということは、解決の方向はナレッジ共有の仕組み化になる。課題の根っこが「知識の問題なのか、技能の問題なのか、動機の問題なのか」を特定できると、後の解決策の立案が格段に楽になる。
やってはいけない4つのパターン
ここまでの整理の軸を理解したうえで、課題設定のアンチパターンを確認しておこう。
①属人的にしない:「あの人の仕事が遅い」→ 仕事が遅い理由はなにか。人の親切心や個人の性格に頼らず解決できる方法を考える。
②他部門を課題にしない:「開発部門の回答が遅い」→ 開発部門に問い合わせる前に事前に情報をもらえていない理由はなにか。自部門でできることを探す。
③方法論を課題にしない:「AIが導入されていないから」「DXが進んでいないから」→ AI・DXがあれば改善するという根拠はなにか。ツールは解決策であり、課題ではない。
④解決できないことを課題にしない:「少子化でフィールドエンジニアの数が少ない」→ 自社が採用できない問題はなにか。外部環境は課題の対象にならない。
自分が書こうとしていた課題が、このアンチパターンに当てはまっていないか確認してほしい。当てはまるものがあれば「なぜそうなっているのか」を掘り下げるところから始める。
NGをOKに書き直す:対比サンプル

ステップ2の整理は、①QCDで影響範囲を決める、②ルール視点で原因を診断する、③4つのアンチパターンを除外する、の順に進める。先ほどの納期課題で、書き直しの前後を比べてみよう。
NGサンプル:「問い合わせ先のルールが守られていない(QCD:納期)」
これは事実の記述だ。なぜルールが守られないのかが書かれていない。
OKサンプル:「問い合わせ先一本化ルールは決まっているが、メンテナンスサポートの返信スピードにムリがあるため、担当者がコネを使って他部門に直接問い合わせる行動が常態化している(ルールは決まっているが守れないパターン)。ルールの修正が必要な状態」
OKサンプルには「なぜ守れないのか」まで書かれているので、解決の方向が見える。部長は「対処すべき構造的な問題がある」と判断できる。品質・コスト・納期の3つで並べると、次のようになる。
| 項目 | NGサンプル | OKサンプル |
|---|---|---|
| 品質課題 | 「対応品質にムラがある」 | 「複数設備で同じトラブルが発生しているが、知識共有のルールがなく個人任せになっている(ルール未設定)。対応ノウハウを組織として再利用できていないため、再発率が高止まりしている」 |
| コスト課題 | 「情報検索に時間がかかっている」 | 「準備段階で顧客・設備・技術情報を個人管理しており、組織内での再活用ルールがない(ルール未設定)。現地での問い合わせが多発し、1件あたり平均2時間の追加工数が発生している」 |
| 納期課題 | 「問い合わせ対応が遅い」 | 「問い合わせ先一本化ルールは決まっているが、返信スピードにムリがあるため担当者がコネを使って他部門に直接問い合わせる(ルールは決まっているが守れないパターン)。結果として解決時間がばらつく」 |
「問題」と「課題」の違い、またQCDによる問題の数値化については、業務改善提案書「問題点」の書き方|NG5パターンとQCDで損失額を数値化する5ステップでも詳しく解説しているので、合わせて参照してほしい。
業務改善提案書の課題の書き方チェックリスト:提出前に確認すること

課題が承認者に通るかどうかは、提出前のセルフレビューで決まる。6項目のチェックを通過することで、属人化・他部門への責任転嫁・方法論の混入・解決不能な事象の混入という典型的なミスを排除できる。
課題を書き終えたら、提出前に以下の6項目でセルフレビューをかけてほしい。これをやるだけで、承認者(部長)に通りやすい課題になる。
- [ ] QCD(品質・コスト・納期)のどれに関連するか明記されているか
- [ ] 課題はルール(決まっていない/守れない/ボトルネック)の視点で分類されているか
- [ ] 人の名前・役職名で課題を記述していないか(属人的でないか)
- [ ] 他部門への責任転嫁になっていないか
- [ ] 解決策(ツール・方法論)が課題の文章に混入していないか
- [ ] 少子化・業界全体の問題など、自社でコントロールできないことを課題にしていないか
6項目すべてにチェックが入れば、課題の書き方として及第点だ。
業務改善提案書のほかの項目については、業務改善提案書「現状の業務フロー」の書き方|よくある4つのNGと課題が伝わる3つの図解ルールでも解説しています。提案書全体を仕上げる際の参考にしてほしい。
まとめ:課題欄は「なぜその状態なのか」まで書く
課題欄が「なんか違う」と返されるのは、努力やヒアリングの量が足りないからではない。As-Is/To-Be、定量化、分類、なぜなぜ分析、客観化といった手法を、課題の目的(縦の承認合意・横の共通認識)を意識せずに使い、事実の記述で止めてしまっているからだ。
QCDで影響範囲を決め、ルール視点で「なぜその状態なのか」を診断し、4つのアンチパターンを除外する。最後に6項目のチェックリストを通せば、部長が判断でき、現場も自分ごととして受け止められる課題になる。
提案書全体の構成は業務改善提案書の書き方【構成と通し方を完全解説】で解説している。課題の次に書く「解決策」は業務改善提案書「解決策」の書き方を参照してほしい。