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

まず前提として、「課題」は何のために書くのかを整理しておきたい。
目的は2つだけだ。
1つ目は、部長と課題を合意すること(縦・承認)。「この課題に取り組む価値がある」と上位者に認識してもらうためだ。
2つ目は、関係者と課題を共通認識すること(横・実務)。現場の担当者が「自分たちの仕事にどう関係するか」を理解するためだ。
ここで重要なのは、この段階は「投資判断」ではないという点だ。費用の話、ROIの話は後続の「解決策」と「費用対効果」のセクションで行う。課題のフェーズで「このシステムを導入すると〇〇万円かかります」という話を持ち込むと、承認の目的がズレる。部長はまず「この課題は本当に存在するのか」を確認したいのだ。
この目的を理解したうえで、課題設定は2ステップで進める。
ステップ1:ヒアリング(否定しない・全部聞く)
ステップ2:QCDとルール視点での整理
ステップ1は発散フェーズ、ステップ2は収束フェーズだ。この順番を逆にしてはいけない。
よくある失敗は、あらかじめ「この課題にしよう」と決めてからヒアリングする形だ。すると担当者の話を都合よく解釈してしまい、核心的な課題が見えなくなる。
メンテナンス部門での実例を話すと、最初に「まず全部聞こう」と判断して否定せずにヒアリングを進めた。その結果、後半になって担当者から「フィールドエンジニアからの問い合わせ先がメンテナンスサポートに決まっているのに、誰も守っていない」という話が出てきた。これが納期課題の核心だったが、最初から絞り込んでいたら見落としていた可能性が高い。
この記事は業務改善提案書の「課題」セクションに特化した解説です。提案書全体の構成については、業務改善提案書の書き方【構成と通し方を完全解説】で解説しています。
QCDとルール視点で課題を整理する:シーン別の適用手順

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

課題が承認者に通るかどうかは、提出前のセルフレビューで決まる。6項目のチェックを通過することで、属人化・他部門への責任転嫁・方法論の混入・解決不能な事象の混入という典型的なミスを排除できる。
課題を書き終えたら、提出前に以下の6項目でセルフレビューをかけてほしい。これをやるだけで、承認者(部長)に通りやすい課題になる。
- [ ] QCD(品質・コスト・納期)のどれに関連するか明記されているか
- [ ] 課題はルール(決まっていない/守れない/ボトルネック)の視点で分類されているか
- [ ] 人の名前・役職名で課題を記述していないか(属人的でないか)
- [ ] 他部門への責任転嫁になっていないか
- [ ] 解決策(ツール・方法論)が課題の文章に混入していないか
- [ ] 少子化・業界全体の問題など、自社でコントロールできないことを課題にしていないか
6項目すべてにチェックが入れば、課題の書き方として及第点だ。
業務改善提案書のほかの項目については、業務改善提案書「現状の業務フロー」で押さえるべき3つの目的と図解のルールでも解説しています。提案書全体を仕上げる際の参考にしてほしい。
