「タイムマネジメント」が上手くなりたい？～第4回「本を語る会」で取りあげる本（予定）
こんばんは。仕事のローテの関係で、珍しく夜に書いています。
さて、イーパテントの野崎さんと一緒に開催している
「本を語る会」
次回は4月です。
まだまだ先の話ですが、もともとオンライン参加も可能ですので、随時お申し込みください。
さて、今回のテーマは、野崎さんのご発案で
「タイムマネジメント」
で行こうか、という話になっております。
もうちょいわかりやすく言うと
「締め切りまでに、成果を出す技術」
って感じでしょうか。
ここでいう成果は
「論文」
「発明」
「企画書」
「プロジェクトの成果」
ぐらいのイメージです。技術開発や製品開発（ものづくり）とか入れ始めると、不確実性のマネジメントみたいな話がメインになるので、今回はやめておきます。
(お話したいことは、いろいろありますが）
一応、語る前に、テーマについてザックリ整理しておくと、今回は、以下のような感じになりそうです。
① タスク、つまり、個人レベルの話、例えば、時間管理のTipsなど
② アウトプットやプロダクトの話、例えば、仕様の決め方など
③ プロジェクトや組織の話、例えば、チームマネジメント法など
僕が今回、主に取り上げるのは、個人の裁量の領域に入る部分が大きい、① と ②の一部 にします。③ については、野崎さんが参考図書を挙げられる予定です。
本を語る会、ですので、本を挙げながら、話す予定のことを書いておきます。当日、同じことは話さないと思いますが、まぁ、備忘録的なものです。
（思いついたことは、とりあえずすべてメモしておく、というのが楠浦流です）
●「すごい実行力」～3日で結果を出す技術
最初は、この本です。
書いてあることは、
「行動科学」
的には当たり前のことばかりです。
（行動科学の本です）
僕が実践していることを、紹介しておきます
「目標を、小刻みに立てる（できれば15分で終わる作業に分解）」
「まず一つ、上手くいっている人の何かを真似てみる（丸ごと真似ない）」
「一日単位で、成果を測定し、見える化する（例：日記）」
「結果目標（売り上げetc）ではなく、プロセス目標（アポ件数etc）を立てる」
終わらないので、これぐらいにしておきます（笑
ちなみに、日記はかなり有効な手法だと、僕は感じています。
●「小さなチーム、大きな仕事」～Leanな進め方
次は、これです。
今回のテーマに関する内容としては、P112 - P115 あたりが参考になるかと。
「タイマーをセットする」
「具体的な問題（タスク）から始める」
「小さな勝利を手に入れる」
「会議はしない」
「そこそこの結果をまず出し、徐々に仕上げていく」
僕が心がけているのは、上記です。結局のところ、同じことを、違う表現にしているだけだとわかります。
タイマーをセットするのは、仕事を細分化することと同じですし、小さな勝利の話です。そこそこの結果をまず出して、徐々に仕上げることにもつながります。
具体的なタスクから始めるというのは、結果目標だけ立てて終わらないということと同じです。
この本も、まずは、これぐらいで。
●「仕様書の書き方」～段取りとは「仕様」
この本を読んでくださいというわけではないのですが、僕が意識していることが書かれている本として、紹介します。
仕事していて思うことは、仕様書をピシッと書ければ、あとはやるだけですから、仕事は８割終わったようなものです。
これが書けないと、右往左往することになります。
見通しが立ってないからです。
こういう人と一緒に仕事をすると、なかなか疲れます（笑
（僕は、根本が設計者なので、仕様書がない世界は考えられない・・・）
結局、設計図の話と同じで、
「見通し無く、仕事に着手すると、終わらない」
というだけの話です。
愚痴っぽくなりそうなので、この辺で（笑
●その他、参考図書
企画書、提案書、論文、などの
「ドキュメントワーク」
については、以下のような、
「パターン」
に当てはめていって、どんどんアウトプットして、後で整理したりブラッシュアップしたりするのが、僕のやり方です。
「やる気」
が出るまで待つ、とかいう方法だと、終わらないからです（笑
一旦、箱を決めておいて、そこにどんどん出していって、後で整理する。
これも、
「仕事の細分化」
であり
「プロセス管理」
ですね。
楠浦が常に気を付けている点として
「いつ、打ち切られても、結果が出ているようにする」
があります。
いつでも引き継げるようにしておく、ということも兼ねています。
こうしておくと、途中で誰かにサポートを頼む、など、柔軟な対応が可能になります。たまに、仕事の進捗をまったく可視化しない人がいますが、その人は
「手伝ってほしくないんだな」
「全部ひとりで責任もってやりたいんだな」
と思えてしまいます・・・冗談です（笑
まぁ、実際には、いっぱいいっぱいでそこまで頭が回らない、ということのようですが、僕からすると
「そういうやり方だから、いつまでたっても改善されない」
のだ、と思えてなりません。
（手伝えませんし、アドバイスもできませんから、いつまでたっても、少しも進歩・成長しませんね）
ちなみに、仕事の進捗を常に可視化、共有する、というのも設計者時代の習慣で、
「数名の設計者が、同時並行で、1つの装置を設計していく」
のが当たり前のオートバイ開発では、設計データは常に
「共有スペース」
においてあって、重要な変更はすぐに知らせ、周辺の部品や機構設計にも即時反映してもらう、というのが当たり前でした。
「３つ子の魂、百まで」
ですね。
楠浦 拝
P.S. メルマガ（無料）も、よろしくお願いします。
この記事が気に入ったらサポートをしてみませんか？