【課題管理表 編】 ～開発設計者が日々考えていること～
ネット上を見てみると、専門家の方々が いろいろなノウハウの情報を提供してくださっています。
でも、実際のところ、開発設計でどんなツールを採用して、それを使っている人はどんな体験をしているかは、あまり知られていないのかも...と思っています。
また、企業の開発設計者が、
・どんなことを考えたり、思案したりして製品を完成させてきたか？
・どんな苦労があって、製品が信頼性の高いモノになっているのか？
ということも、あまり知られていないのかも？と思いました。
それで、開発設計をしている人が日々どんなことを考えているのか？を知りたい人や、これから開発設計を始める方々、開発設計に興味のある方々のために、公開できる範囲内で、情報を紹介できたら... という思いでブログを始めました。
思考をカタチにしていく上で役立った（今も役立っている）手法を、参考にしていただけると幸いです。
今回は、課題管理表 編です。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
課題管理表とは？その書き方は？
このページで扱うのは、「課題管理表」です。
課題管理表とは何で、何ができて、書き方はどうすればいいか？を扱います。
この手法を使うと、思考がクリアになってくることと、プロジェクトをすごい力で牽引するような、もしくは、背中を強力に押してくれるような感覚があります。
私はこの方法を知ってから、開発設計に対する尻込みとか怖さ、不安や心配がなくなって、課題に立ち向かうことが面白くなりました。
みなさんもこれを活用して、”あいつに任せたら絶対完成できる” と言ってもらえる 開発設計者になってください!!
<目次>
課題管理表で 何ができる？
「課題管理表」は何を実現してくれるのでしょうか？
大きな点を挙げると、
- 問題点（課題）の明確化
- 解決（対策）方法の明確化
- 解決期限の明確化
- 解決を担当する人の明確化
- 問題解決ToDoリストの役割
- 進捗の見える化
- 解決までに要した時間/日数が明確になる → 今後の工数割り出しに役立つ
- 表を工夫することで、複数人に関わってもらったり、上司の承認を得たり、状況を知ってもらいながら進めることができる。
（チームで使ったり、他社との共同開発で相互書き込みで使えます。） - 開発設計者の不安・心配（ストレス）解消
（問題点を書き出すことで頭がスッキリする） - 問題が多くあっても余裕を感じる（←人の性格差が関係します）
です。
結構すごいことができますね。
私は、いつも使っています。というのは、
- 頭の中に記憶として残さないといけない..というプレッシャーから解放される。
- 細かく内容を書いておけば、他の思考へ移って戻ってきたとき、すぐ再始動できる。
- 内容を忘れかけてしまっても、この管理表を見ればいいという安心感がある。
など、 開発・設計者が日常的に「思考を繰り返す」うえで、とても助かるツールと思っています。
思考に没頭するのを助けてくれる..という感じです。
課題管理表の書き方は どうやればいい？
課題管理表の書き方はどうやればいいのでしょうか？
この表は、問題点もしくは課題が起点になります。
下の「課題管理表のフォーマット例」をもとに、説明します。
- 表の左側の列に「項番」を書き、
- その右隣の列に「問題・課題」と「分類」、「指摘日」「指摘者」、
- さらに、その右隣に「対策案」と「対策検討予定日」、
- そして、その右隣に「対策結果」と「対策者」、
- その右隣りに、「現在状況」、「対策完了予定日」、実際の「対策完了日」、
- もし、第三者確認が必要であれば、「完了確認者」欄を右端に設けます。
- 複数人でプロジェクトを行なっているのであれば、それぞれの項目に担当者欄を設けたほうが良いです。
（一人プロジェクトであれば、担当者欄はなしでもいいと思います。）
表は意外と簡単に完成します。
思考と行動を繰り返しながら、欄を埋めていきます。
該当なしのところは「—」などにします。
重要なことがあります。
それは、プロジェクトが終了するまで、継続して使い続けることです。
課題管理表が持つ 推進力を生む仕掛けとは？
課題管理表はToDoリストと似ていると思うかもしれません。
ちょっとどころか、大きく違います。
その違いは何でしょうか？
課題管理表にはプロジェクトを推進する駆動力を生む仕掛けがあることです。
この表は、課題・問題点を最初の列に書く→その横に解決策を書く→期限を書く→解決策を実行した結果を書きます。
問題に対する解決策を書くには、思考を働かせて案を抽出する必要があります。
また、解決策を実行した結果を書くには、抽出した案を実行に移し モノを作って実験したりデータ分析するなどして 行動と思考を働かせる必要があります。
このように、課題管理表は「思考プロセス」と「行動プロセス」を踏まないと、表の空欄を埋めていくことができなくなっているのです。
ToDoリストは「やること」が既に抽出されていて、それを「やった」か「やってない」かをチェックするリストです。
ToDoリストを見ながら「どうしたらいいか？」という思考を働かせることはほとんどないと思います。
私は、課題管理表が思考プロセスと行動プロセスを併せ持っていることが、プロジェクトの推進力・駆動力を生んでいるのではないか と考えています。
わたしが使っている課題管理表は、上にある例と同じですので、参考にしてみてください。
なぜ、課題管理表を使うことがお薦めなのか？
開発設計者が抱える問題・課題は1つだけ ということはまれで、いくつもの問題・課題を同時並行で考えることが普通です。（時間差で思考ですけどね..。）
開発設計者は、問題・課題が見つかると、その解決法ばかり考えてしまいます。
そうするうちに次の問題が起きて..となって、頭の中がもうグチャグチャ、不安や心配もどんどん増えてストレスが大きくなってきます。
たぶん人は、同時に一つのことしか考えることができないのだと思います。
実は、私はそれに起因したストレスが原因で、身体を壊してしまいました。（内臓に支障が出ました。）
その後何年か経ってから、この課題管理表の手法を知り、もっと早く教えてほしかったと思ったと同時に、これを使って開発設計を行っていくと、今まで感じていた怖さとか不安・心配がなくなっている自分に気付きました。
そして、この表を活用することで、頭の中がスッキリすることが多くなりました。
開発設計をしている大勢の人たちも同じように、怖さや不安や心配を感じているのではないか？と思ったので、多くの方々にこの方法を活用してもらえたらと考えています。
是非一度、試してみてくださいね。
おすすめの本
おすすめの本があります。
ここをクリックするとブログの続き（本を解説した箇所）へ移動します。
