![図解とマンガでわかる プロジェクトを成功させる技術[ハンディ版]](https://m.media-amazon.com/images/I/51AmpvbpW1L._SL160_.jpg "図解とマンガでわかる プロジェクトを成功させる技術[ハンディ版]")
今回は、担当者の課題の対処
管理者のではない。
プロジェクトにおいて課題とはなんだろうか？
それぞれの立場、環境などで考えてほしい。
私は、１年1億円程度の一般的に小規模？中規模のプロジェクトだが1プロジェクトのリーダーの経験した。
また、ワンフロア100人規模で数年のプロジェクトも参加した事がある。
こちらはパートナーとして参加しツールの設計と製造と、インフラの構築を行った。
た・て・も・の・ケ・アーとかいうメーカーHのシステム基盤とか。
大阪のスポーツ用品の基盤とか。
私は自ら立ち上げたプロジェクトでデスマーチは起こしたことない。
私のメンバーか優秀だったといえばそうかもしれない。
しかし、私プロジェクトでは人の能力は問わなかった。
社内てマイナスと思われた社員も面倒見てほいなどよくいわれていた。
それは先輩であろうとズバッというところもあるかもしれないが
それは今回のテーマとは関係ない。
人がどうであろうと、疑問と思って上がった課題が重要というはなし。
今回のテーマは『プロジェクト管理』の「課題管理」に当たる。
『課題管理』は『プロジェクト管理』の要素としてはメインキーとなるほど重要だ。
過去のテーマでも話したかもしれないが、
私は２０代後半頃プロジェクトマネジメントやPIMBOKなど独学で理解をすすめた。
指標としては、国家試験のプロジェクトマネジメントをギリギリ落ちるぐらいだ。
わかりやすくいうとプロジェクトマネジメントの基礎は身についているというぐらいだろう。参考までに。
プロジェクトマネジメントの基礎って本当に仕事に役に立つ！
というか人生に役に立つ！
『私はプロジェクトは生き物と考えてています。』
ドラッカーみたいなこといってすいません。
その時、その時でちがうが、
当たり前のことを当たり前にやれない現場は多い。
このプロジェクトマネジメントの一つの要素となる
課題をどう管理するかについてです。
ここで私から一言
プロジェクトとは課題消化の上でなりたつ
極端なこと言えば、
『課題の消化してしまえばプロジェクトが完了』
といって過言ではない。
それほど課題は重要だということだ。
私のプロジェクトでは、
課題は一般的な課題表で管理する。
あたまえじゃって？
当たり前を当たり前ににやることがマネジメント
当たり前のことをやってないのは怠慢ですよ。そこのあなた！
そうそこにもぞもぞ何か言おうとしているメンバの声を聞き
課題表にいれてみなさい！きっとあなたに有意義な時間が訪れることだろう！
課題表の作り方
それでは、野菜を洗い適度な大きさに切っていきましょう・・・
ちがうか・・・
ではちゃんポイントごとに
①体裁は気にしないで羅列
体裁などどうでもいいのだ。
上がる課題をメモ書き程度に羅列すればいいのだ。
②忘れる前に書く
課題を忘れるというのが一番の問題、
気づいた時にすぐに課題に書く癖をつけよう。
③聞きたいことやわからないものを書く！
とりあえず誰に聞くかわからないものでも書く。
「疑問」や「不安」
④表現がわからないものも表現のわからないまま書く。
⑤書くのをためらわない！
・・・なんだけど大丈夫か・・・
大丈夫なら大丈夫なことを書く
書くと無限大にでてくるので！
とりあえずなんでもいいから関係することをすべて書いてください。
さーたまってきましたね。
たまってきたらやること！
①ヘッダーをつける
これ基本です。たまった課題にヘッダーをつけましょう。
表の項目名ね！
左から
番号/ 分類大/分類中/分類小/課題の状態/課題の内容/対応方法/起票者/起票日
これ基本、基本なのでつゆだくなり、ねぎだくなりしてください。
ただし、基本をなくした肉なしはやめた方がいいですね。
②類似性をまとめる
さてさて課題をみてみると同じような種類や同じようなタイプなどわかれてきますね。
それを分類小に簡単にタイトル入れていきましょう。
分類小のなかでまたまとまるなら分類中 そして 分類大へ
似たようなニュアンスのものを勝手に削除しないようにしよう。
起票者にきちんと内容を確認して間違いなく類似のものは削除してもよい。
できれば、非表示がのぞましい・・・なんでって？検索キーとして使えるから
③重要度や優先度を判断する
こちらは、先々の見通しまでできないので簡易的なものでいいです。
わからないものは空でもいい。
④人の関連をつけていきましょう
担当者（できれば1人） 複数人はやめましょう 複数人でやるなら
グループ長などつくって長の名前としてその長が責任者としましょう
⑤ボリュームを想定する
どれぐらいの期間と人が必要となるかなどざっくり工数をいれる
⑥必要・不要・わからない
精査しましょう！
今一度、
グループ化、優先度、分類分など整理しましょう。
なんどがくりかえすと精度があがってきます。
さてさて、課題がたまってきたところ、
具体的にスケージュールしていきましょう。
重要で優先度が高いものからタスクに落としてWBSを作成していきましょう。
基本的にWBSも課題表ににたプロセスでやっていきますが、
WBSの場合は課題と違って骨組に肉付けしていく形です。
ここから先はちょっとテーマが違うのでWBSは今度話しますね。
特許にしたくなるWBS！のつくりかた なーんてな！
ざっくりと話をしましたが、課題の整理の仕方はこんな形でしょうか？
課題表を作った進め方、
課題表は、早期はたくさんの課題があがり、上げていけばいいという
状態になりますが、日々ブラッシュアップしていく必要があります。
１か月たってもコメントが変わらないなどあれば、
それ？そもそもいるのとか判断して？１か月に１回は見直しをかけます。
当然、プロジェクトの上流に比べ下流はその課題が問題と変わる可能性があるので
きめ細やかにすべての課題を整理し、方針やルールなど他のドキュメントに落とせるものは整理していく必要があります。
終わったタスクは、状態を変えセルを灰色にします。
そのあたりはひとつベースとなるEXCELを作っておけばいいですね。
私は、ベースをつくってるかって？
意外とつかってないですよ！どこでもEXCELでつくれるじゃないですか？
まーなれているのであっという間に課題表はつくります。５分ぐらい？
もしくは、プロジェクト上に転がっているものを少しかえて作り替えたりもします。
課題の管理は多種多様いろいろありますが、
課題は腐らせてはだめ！
課題には鮮度があります！
気を付けて管理しましょう。
そうそう冷蔵こと一緒ですよ！
きちんと整理しないと腐ったものでてきますよね。
おいしいものはおいしいうちにってね！
これまでは、課題表の重要性と私なりの課題表の管理方法を伝えてきましたが、
今回は担当者の課題管理。
担当者？で課題管理する必要があるの？
そうですね、担当者の課題は私の考えるところの普通は、
管理者、リーダーが整理し管理し方針を上がて行くのが当たり前なのです。
当たり前じゃない人もいます。わたしにとって困ったちゃんです。
課題を管理せずに進むのかというと、
フェーズは進んでいきます。すかすかの骨組みですかすかのものができあがっていればいいですが、すかすかすぎて水に浮かべたら沈みそうなプロジェクトは本当に多いです。私から見たらなんでだろう？
私は以前は、ベンダーリーダーでしたが、
いろいろすったもんだあり、派遣系の１万にぐらいいる会社の正社員です。
といってもほぼ一人で働くので、いろんなことが保証されている。給料安い自営業といったところでしょうか。
パートナーとして入るので、基本管理面は行いません。
すると、整理されていないプロジェクトに出くわします。
これすすんですか？あれすすですか？とあれこれ聞かないといけない。
いったいわないの話もでてきます。
そんな場合私は、課題表をポンと作ります。
そしたらそれを主軸に進んでいきます。
私もリーダーを長年やってきたのと、火消しとしてプロジェクトに参加したことが
なんどかあるので、燃える要素や直感はたいてい当たります。
リーダーの時もこの直観で先に手をうったり、上司に相談するなどで
根回しするので基本問題となる前に課題として消化されます。
問題って先に課題で上げておけば、何にも怒られないですよ。
長年放置して、戸棚の裏とか、みえるのに見えないふりしているから、
いつのまにか全体がカビカビになってるですよね。
カビが生えた課題って、相当な問題ですからね
なんでいわなかったのか？どうして？いつわかったのか？
解決策は？とりかえしつかないじゃないか？など・・
あのプロジェクト失敗してないのに何でそんなこと知ってるのって？
火消しやってきたので！専門性の強いことやっていました。
汎用機や、オフコンなどをWIndowsサーバとOracleRDBに移行するやつです。
COBOLをわかってても、オープン系受け付けないと難しいですよね。
かといって汎用機の概念をわかってないと、どうやってオープンにするかわからないですよ。データベースの構造が一番違うし、それぞれの機種で違ったデータ構造もっています。日本一のCOBOL会社とおもっている企業とタッグ組んでやっていましたが、
ベンダーが食っていけるほど、今は案件がないでしょうね。
その時は、あれでしたね、すべて誰も使ったことがないツールばかりで、
マニュアルとかあればいいですが、ネットにも情報がなく、手探りですよ。
手探りで暗中模索を繰り返し。自分なりの仕事の進め方を隔離できましたね。
正直プログラム技術より貴重な財産です。
プログラム技術なんていつでも変わるし、理解の仕方さえおぼえれば、
右から左に言語変えていけばいいだけだから。
ほんとできないことないじゃないかなって思うことあります。
あしたコロナのプロジェクト管理してくれっていわれたら、
やりますね。とりあえずまず有識者から情報集めますね。
聞いたうえで、感覚でこの人に任され売位みたいな専門家に権限を与える。
それをいくつかのグループにわけ課題を管理し、
国家規模であれば、課題の整理が得意なひとに最短で整理させる。
なんとなくできるような気がしてきましたね。
そう！
きっとあなたの近くでまごまごしていたメンバーはその重要な課題を
つたない会話で伝えようとしてたと思いますよ。
拾えない人は拾えないです。
だって失敗してても失敗と思ってなかったり失敗と認識してなければ
成功？ いや成功も意識しないでただ毎日にただただ、
新しい技術には、拒否反応を起こしている。
そんなの身近にないですか？
損してますよ。どんな人でも味方につければ強いですよ！
プラスを２倍３倍にするのって難しいですよ。
でもマイナスをプラスにかえれればほぼ無敵ですよ。
管理者の対応として一番無駄な行動は、言い負かす事。
で？課題をもってきました？言い負かします？で？
彼は、なんのためにいいにいきたでしょうか？
彼の問題は解決しないままです！そんな人いますよね？
質問しに来たのに、その質問の解決しない人！
はっきり言いますね！
その人にイラついたりするのって無駄ですよ！
無駄無駄、時間の無駄！
消化できない人は一生消化できないです。
課題表があったとして、課題表をみても意味わからないといて、
平気で行削除するんだから、そして出来上がったのがすかすかの仕様書。
これって次のインプットに有効なんだろうかレベル。
今日ふとおもったですよ。
この記事を書こうと思ったのそれが理由なんですが、
課題を整理できない。問題を吸収できない。アラート上げても気づかない人に
どうしたらいいか。
残念ながら自分の範囲内でしか解決しないのですが、
伝えた課題や問題は、自分用の課題表を整理し、先ほどのヘッダーに
いった日、直接言った内容と反応を記しておいたらいいですよ。
あとは、適宜自分の上司にレポートとして提出してもいい。
そうやってレポートをもっていたら、
いざ責任転嫁されたときにそのレポートがあれば、
無敵です。どんな責任者も数字には負けますから。
ましてや、日付もついて、きちんとレポートを報告しておけば、
聞かなかったお前の実力不足となります。
とりあえず今回のテーマ担当者の課題管理は非常に重要です。
私の場合なら、その担当者の課題ほしいですね。
担当者の課題はプロジェクトの宝！
光っている（戸惑っている）課題に目を向けよう！
そこにあなたの壁を超えるなにかがあるかもしれない！
