課題管理表を止めない。「対応中」を減らす書き方と運用
課題管理表が数週間で「対応中」だらけになるのはなぜか。外から参画する立場で、次の一手の書き方、定例での扱い方、客先へのひと声まで、表を動かし続ける運用を書きます。
上流のプロジェクトに参画すると、早い段階で課題管理表を任されることがよくあります。PMOとして入ればもちろんですが、要件定義の担当として入っても、自分の領域の課題は自分で管理することになります。
立ち上げのころは、表はよく回ります。ところが数週間たつと、行が増えていきます。状態の欄には「対応中」が並びます。定例会議では上から読み上げて、「引き続き確認します」で終わるようになります。誰も困っていないように見えます。でも実際には、決めるべきことが少しずつ後ろにずれていきます。
この記事では、客先のプロジェクトに外から入る立場で、課題管理表を止めずに動かし続ける運用を書きます。表の項目より、書き方と、会議での扱い方と、人への声のかけ方が中心です。
止まった表には「次の一手」が書かれていない
止まっている課題管理表には、共通点があります。状態しか書かれていないことです。「対応中」「確認中」は、誰かが何かをしている、という意味でしかありません。次に誰が何をするのかが書かれていないので、定例で毎回聞くしかなくなります。
たとえば、定例でPMOが「マスタのコード体系の件、どうなっていますか」と聞く場面です。担当者は「情シスさんに確認中です」と答えます。翌週も同じやり取りになります。情シスの誰に、何を、いつまでに聞いたのか。表のどこにも書かれていません。聞いた側も、それ以上は踏み込みにくいものです。
そこで、状態の欄とは別に「次の一手」を書く欄を作ります。書き方は「誰が・何を・いつまでに」の一文です。たとえば「情シスの担当者が、現行のコード採番ルールの資料を、金曜までに共有する」と書きます。この一文があれば、定例で聞くことは「資料は共有されましたか」に変わります。答えは「はい」か「いいえ」です。いいえなら、何が止めているのかをその場で聞けます。
気をつけたいのは、次の一手を課題が閉じるまでの全部にしないことです。直近の一つで十分です。全部を書こうとすると、先が見えない課題ほど書けなくなり、欄が空いたままになります。一つ書いて、それが終わったら次の一つに書き換える。この繰り返しで、表は少しずつ前に進みます。
起票の時点で、課題と作業と未決事項を分ける
表が膨らむ原因の多くは、性質の違うものが一つの表に入っていることです。中身を見ると、だいたい次の三つが混ざっています。
- 課題:このままでは進められない、または結果に影響が出る問題。解き方がまだ見えていないもの。
- 作業:やることは決まっていて、手を動かせば終わるもの。
- 未決事項:選択肢は見えていて、誰かが選べば終わるもの。
「レビュー資料を配る」「会議室を押さえる」が課題表に入っていると、重い課題がその間に埋もれます。逆に、「受注の締め時刻を今のままにするか、変えるか」は、悩ましく見えても未決事項です。決める人と期日がはっきりすれば閉じられます。これを課題として抱えたままにすると、誰がいつ決めるのかが曖昧なまま、いつまでも「検討中」になります。
やり方としては、起票されたときにPMOが分類を整えます。「これは作業なので、タスク一覧の方に移しておきますね」と、ひと言添えて移します。作業はWBSやタスク一覧へ。未決事項は、課題表の中に区分の列を設けて分けておくだけでも見通しがよくなります。
ただし、分けすぎると今度はどこを見ればいいのかわからなくなります。表が三つも四つもあると、誰も全部は見ません。客先が既に使っている表があるなら、それを壊さないことです。区分の列を一つ足す程度から始めるのが無難です。参画したばかりで表の作り直しを提案すると、前任者や客先の担当者のやり方を否定するように聞こえることがあります。まずは今の表のまま、自分の担当分の行を整えて見せる方が、話は通りやすくなります。
「何が決まれば閉じるか」を最初に書く
閉じない課題のもう一つの原因は、完了の条件が書かれていないことです。人によって「終わり」の位置が違うので、片方は終わったと思い、片方はまだだと思っています。
たとえば「帳票の出力形式が決まっていない」という課題があるとします。何をもって決まったとするのか。PDFかExcelかを選ぶことなのか。レイアウトまで固めることなのか。開発側はレイアウトまでと考え、業務部門は形式だけ選べばいいと考えている。この差があると、定例で「もう決めましたよね」「いえ、まだです」という噛み合わないやり取りが起きます。
これを防ぐには、起票の時点で完了条件を一文で書きます。「業務部門の課長が、PDFとExcelのどちらで出すかを選び、定例で確認できたら閉じる」。レイアウトの話は、別の行に分けて起票します。一つの行に一つの決めごと、が基本です。
一行に入れておきたい項目を挙げると、次のようになります。
- 何が問題か(感想でなく事実で書く)
- 放置すると何が起きるか
- 何が決まれば閉じるか
- 決める人
- 次の一手と期日
このうち「放置すると何が起きるか」は、優先度の根拠になります。「優先度:高」とだけ書いてあっても、人はあまり動きません。「月末の基本設計レビューに、この画面の設計が出せない」と書いてあれば、読んだ人が自分で重さを判断できます。ここは大げさに書かないことです。毎回「全体が遅れる」と書くと、そのうち誰も読まなくなります。何の、どの工程に、どう響くのか。そこまで具体的に書けば十分です。
客先の人を担当者にするときは、先にひと声かける
外から参画すると、課題の多くは客先の誰かが決めないと閉じません。担当者の欄に、客先の人の名前を書くことになります。ここで気をつけたいのは、表に名前を書いただけでは、本人が知らないことがあるという点です。
たとえば、定例で画面に課題表を映したとき、業務部門の担当者が自分の名前を見つけて「これ、私なんですか」と言う場面です。悪気はなくても、場の空気が少し硬くなります。その人は次から、課題表を警戒しながら見るようになります。協力してほしい相手との距離が、表一枚で開いてしまいます。
名前を入れる前に、チャットか短いメールで一度伝えておきます。文面はたとえば次のようなものです。
「出力形式の件、課題表で担当をお願いしたいと考えています。来週の定例までに、PDFとExcelのどちらにするか、ご判断をいただけると助かります。比較の資料はこちらで用意して、明日お送りします。」
ここで押さえているのは三つです。決めてほしいことを一つに絞ること。期日を添えること。こちらが何をするかを書くこと。相手に頼むときは、こちらの手間を先に見せると、引き受けてもらいやすくなります。
相手の上司や部門長の名前を担当者に書くときは、さらに注意が必要です。窓口の人を通さずに直接書くと、窓口の頭越しになります。窓口の人に「この件は部長のご判断が必要だと思うのですが、どうお願いするのがよいでしょうか」と相談するところから始めます。PMOの役割は、決める人が決めやすい状態をつくることです。表で決める人を追い詰めることではありません。
定例では全件を読まない。見る順番を決めておく
上から順に読み上げる定例は、件数が増えると必ず時間切れになります。後ろの方の課題は、いつまでも話題に上がりません。しかも、読み上げられる側は「確認中です」と答えるだけなので、会議が終わっても何も変わっていません。
そこで、定例で見る順番を先に決めておきます。
- 期日を過ぎたもの
- 今週中に決めないと、次の工程に響くもの
- 前回の定例から新しく上がったもの
それ以外の行は、前日までに表を共有しておき、「気になる行があれば、この場で聞いてください」とします。会議の冒頭では、たとえば「今日は期日を過ぎたものが二件、今週判断が必要なものが一件あります。この三件を先にやります」と伝えます。残った時間で新しい起票を確認します。これだけで、会議の中身が報告から判断に寄っていきます。
定例の場で課題を解こうとしないことも大切です。議論が始まると、関係のない参加者を待たせることになります。話が深くなったら「これは関係する方だけで、別に三十分取りましょう」と切り出します。そして、その場で次の一手を表に書きます。誰が会議を設定するか、いつまでにか、です。
もう一つ、進め方を変えるときの順番があります。定例の主催者が客先のPMであれば、いきなり当日に進め方を変えないことです。事前に「件数が増えてきたので、期日超過と今週判断のものから見る形にしてもよいでしょうか」と相談しておきます。外から来た人が会議の形を勝手に変えると、主催者の立場を軽く扱ったように見えます。中身が正しくても、そこでつまずくのはもったいないことです。
長く閉じない課題は「保留」として扱い直す
どのプロジェクトにも、すぐには閉じられない課題があります。他部門の方針待ち。別のプロジェクトの結論待ち。組織の変更が固まるまで動けないもの。これを「対応中」のまま置いておくと、毎週同じ行を見て、誰も何もできない時間が続きます。表全体が止まって見える原因にもなります。
こうした行は、状態を「保留」に変えて、再開の条件を書きます。「別プロジェクトの方式検討の結論が出たら再開」「新しい組織の担当部署が決まったら再開」といった具合です。保留にしたことは、定例で一度だけ共有しておきます。黙って状態を変えると、担当者が外されたように感じることがあるからです。
あわせて書いておきたいのが、保留の間に今の作業をどう進めるかです。結論が出るまでの仮置きの前提を、行の中に書いておくことです。たとえば「結論が出るまで、該当画面は現行の項目のまま設計を進める」と書きます。こう書いておけば、保留中でも手は止まりません。結論が出たときに、どこを直せばいいかもすぐわかります。
ただし、保留は見なくていい箱ではありません。月に一度など、保留の一覧だけを見直す時間を決めておきます。再開の条件を満たしていないか。仮置きの前提が、今も通用するか。保留が長引いて工程に響きそうになったら、そこからはエスカレーションとして扱います。
閉じた課題も、消さずに残しておきます。何が、誰の判断で、どう決まったのか。後になって「なぜこの仕様になったのか」と聞かれることは、上流ではよくあります。そのとき、閉じた行が答えになります。閉じるときに、決まった内容を一文で書き添えておく。この手間が、数か月後の自分と後から来る人を助けます。
最後に、明日の朝にできること
課題管理表を立て直そうとすると、項目の見直しや、表の作り直しから考えがちです。でも、表の形を変えなくても、書き方が変われば表は動き始めます。
明日、課題管理表を開いたら、「対応中」のまま二週間以上動いていない行を一つ選んでください。その行に、次の一手を「誰が・何を・いつまでに」の一文で書き足す。決める人が客先の人なら、書く前にひと声かける。やることはそれだけです。
一つの行が動くと、定例でのやり取りが変わります。それを見た周りの人が、自分の行も同じ形で書くようになります。外から入った人が客先で信頼されるのは、大きな改善提案をしたときより、こうした小さな変化を毎週積み重ねたときです。
Partners
ITコンサルティング会社 株式会社ディシェアー の編集部です。大手メーカーなどのITプロジェクトに上流から参画してきたコンサルタントの知見をもとに、記事をお届けしています。

