問題を構造化して考える技術

問題解決にあたって、問題を構造化して考えるというのはごくあたりまえのことなのですが、なかなかこれが身についていないと感じています。＜昨日の日記参照。

ごく一般的な、問題解決のためのフレームワークって、こんな感じ？

1. 問題点を定義する。（言葉／文章に起こす。）
2. 問題を構成要素に分解する。（図示する。）
3. 要因を絞り込む。（重み付けする。）
4. 主要因に注力して取り組む。

言い換えれば、「あんたは何をどうしたいの？」「なんでそんなことが起きるの？」「どこがいちばんアヤシイの？」「じゃあそこからやれば。」てことです。

こういうのって知っているだけでは意味がなくて、無意識のうちにこういう思考ができるように刷り込んでおくべき「技術」なのだと思いました。

そろそろやるかな。

スケジュール管理

平鍋さんのblogで4/5に紹介されていたこの本。Amazonで買ったので読んでいます。うちの会社はメーカーなので受託開発あまり関係ないような気がしますが、受託開発であろとなかろうと学ぶことが多い本だと思います。その中から、私が苦手とするところの「スケジュール管理」について、琴線に触れたところを覚え書きしておきます。

第６章　計画とスケジュールの管理 (P.105-)より

プロジェクトで共有されるスケジュールには、スケジュール案・マスタスケジュール・進捗管理用スケジュールの３つがあり、それぞれにふさわしい表現方法があります。

私の苦手な進捗管理用のスケジュールについて。

進捗管理用のスケジュールはお客さまやプロジェクトメンバとのコミュニケーション手段でもあります。進捗会議の場ではこのスケジュール表を使って進捗を報告しますが、コミュニケーションですから、スケジュール表にもメッセージを込めなくてはいけません。(P.109)

実に実に。そして、このメッセージが伝わりやすいように表現するための４つのポイントを次のように紹介しています。

• メッセージを１行で表現
• 目立つ着目点
• 現在地点と次のマイルストーン
• マスタスケジュールへの影響の説明

こういう本を読みながら上手な人のやり方を真似て（必要なら自分流にアレンジして）、確実にスケジュールを守れるようになりたい。（今はグズグズでごめんなさい）