nDiki : コミュニケーション

メール 意思決定 GTD ポイント 問題解決 Life Hacks プレゼンテーション ソフトウェア Blog 開発 Naney 日本語 仕様 ミーティング 会議 思考法 仕事術 アウトプット主義 計画 発想法 情報発信 メモ術 リーダーシップ 検索 ノウハウ トリンプ 電子メール アイデア メーリングリスト ソフトウェアプロジェクトマネジメント

■ リリース版完成後の事後評価

前回とは違うプロジェクトで事後評価セッションを提案。 地理的に遠い2個所にスタッフが分散しているので、今回は

• 「成功点、失敗点」をメールで自分のところまで送ってもらる
• とりまとめてメーリングリストに投稿
• その後適宜コメントをつけてもらう

というスタイルにしてみた。

バグトラッキングシステム導入はかなり好評。 問題点は、いつも通りコミュニケーション不足に関するもの。

経営・マネージャークラスにも意見をつのっているのだが、積極的ではないのは残念。 長期的な視点では事後評価セッションは重要なのに。

• メールによる社内コミュニケーションの問題 (2006-04-12)
• GnuPG の布教失敗 (2005-02-02)
• 「プロジェクトマネジメント」はどうやって勉強すれば良いですか? (2006-11-22)
• [ Debian ] woody + qmail + vpopmail +... (2004-01-08)
• Gmail へのメールボックス移行で spam 誤判定と転送問題にぶつかる (2007-08-11)

■ お手玉使いの曲芸師を雇う

本日面接。 ピープルウェア 第2版 第15章 「お手玉使いの曲芸師を雇う」を参考に「新採用者の同僚となるはずの人たちで聴衆グループを編成する」を実践してみた。

今回は事前に応募者にプレゼンテーション依頼をしていなかったので、同席したスタッフは一緒に話を聞くという程度(応募時に自己アピールとして成果物(プログラム)を送ってくださったので、それの簡単なデモをしてもらった)。

まずは少しづつでもそういう事をはじめて、組織として人(チーム、コミュニケーション)重視の雰囲気を作っていけたらいいかなと思う。

• 面接 (2004-10-19)
• 「プロジェクトマネジメント」はどうやって勉強すれば良いですか? (2006-11-22)
• 面接 (2004-10-05)
• 新幹線でウェブ進化論を読み終えた (2006-05-25)
• 早朝会議革命 - 元気企業トリンプの「即断即決」経営 (2005-07-16)

■ el patine MONOCHROME A4パイプファイル (3cm) PAM-1473BK

最近プロジェクトのミッションドキュメントを書くようにしている。 文書化することでプロジェクトの見通しが良くなり、チーム内でミッションの共有やチーム外の人とのコミュニケーションのツールとしても役立っている。

で、何だかんだいって印刷しておいた方が便利。そうこうしている間に整理していなかった、紙の資料とあわせてごちゃごちゃしてきたので、ちょっとファイリングしてみることにした。 保存資料やらとかは会社にあるパイプフォルダでいいが、アクティブなプロジェクトのものは、どうせなら洒落たものがいい。

ということで、手始めに1冊ファイルを買ってみた。 出勤前に、秋葉原の昭和通り沿いにあるこじんまりした(メッセージカードなどが充実している)文具屋で、エル・クラッセのモノクロームシリーズファイルを購入。

株式会社エル・クラッセは 2001年に KING JIM 関連企業と設立されたが、2003年10月21日付けで株式会社合同と合併し、現在株式会社Gクラッセとなっている。

商品についていたシールはエル・クラッセのものだったので、このお店では入荷したっきり売れてなかったのかな?

金具は KING JIM 製。左右どちらからでも開くことができるので、一般的なパイプフォルダより書類の出し入れがしやすいのが特徴。

• アサヒヤ紙文具店

[ 製品レポート ]

• フィルムスキャンできるインクジェットプリンタ PIXUS MP980 (2008-11-03)
• ステーショナリーに手を出した - 私的10大ニュース2005 [ misc ] (2005-12-31)
• 今日のさえずり - 鼻をすする音が、ケータイカメラのシャッター音に似ている (2008-10-02)
• JR 秋葉原駅 中央改札口オープン (2005-08-18)
• 今日のさえずり - 上げ潮特大号 (2008-09-18)

■ 早朝会議革命 - 元気企業トリンプの「即断即決」経営

トリンプの吉越浩一郎社長による「会議を通したスピード経営」についてを、会議出席や社員へのインタビューを通して著者がまとめあげた1冊。

会議を中心とした内容であるが、「すごい会議」と同様ただ単に会議手法を述べた本ではない。 会議を通した経営についてが述べられている。

同社のMS会議 (Marketing and Sales 会議) は吉越社長が自部門の改革として始め、粘り強く改善・継続して全社的なものになったもので、そう簡単に真似ることができるものではないが、そのエッセンスには学ぶものが多い。

@ 朝開催

• 多くの人間が集まる時間帯。
• 集中できる時間。
• 同日に即行動に移せる。

特に最後のは魅力的。やる気がみなぎっている間に行動に移せる。 しかし、自分はオフピーク通勤が気にいっているからなぁ……。

@ 毎朝開催

当然週1回よりスピードがある。

回数は多いが、きちんと問題について意思決定しコミットメントに落としていくので無駄がない。

@ トップダウン

ただし民主的、フラット。

@ 「決める」会議

• 「誰が、何を、いつまでに」

ここら辺はすごい会議と通じる。

@ デッドライン

• ドイツ系の会社から。
• 厳しく。でないとみんな逃げる。
• 最大限で1週間。それ以上はスケジュール化。
• 稚拙でもいいから速く。

毎朝会議が開催され議論されることで、1週間でまわしていける。

@ プレゼンテーション

• プレゼンテーション自体を目的にしない。無駄に準備に時間をかけない。

@ コミュニケーションの場・情報共有の場

• 「和」を形成。
• 共通認識が広がる。
• 判断・決断までのプロセスを共有。プロセスから参加することに意味がある。
  • 意思決定に変化があっても理解できる。
  • 教育の場
    • 技は盗むもの。「教育なんてほんとはできっこない」。
• オープン、フェアネス。

見習いたい。 どのようにすれば我社で判断・決断プロセスから共有していけるようになるだろうか。

@ 継続

• 継続はトップの責任
• 改善こそ継続の母
• 成功するまでやれば、成功する。p.207

@ 結論から言え

• 言いにくくても、結論から言え。p.207

@ 感想

「決める会議」、「誰が、何を、いつまでに」という方針のメリットを再確認。

• 早朝会議革命 - 元気企業トリンプの「即断即決」経営

[ 書評 ] [ お薦めの本 ]

• すごい考え方 (2005-12-10)
• すごい会議の正しい手順 (2005-07-04)
• すごくない会議 (2005-06-29)
• TQ - 心の安らぎを発見する時間管理の探究 (2005-06-16)
• このやり方でやると「すごいこと」が起きる。 (2005-06-08)

■ ナノパーセント日

ミーティングで、あるプロジェクトのスケジュール遅れが議題になった(参加していないプロジェクト)。

リクエスト側と開発側で、仕様の誤解による手戻りが大きな原因のようである。

• リクエスト側と開発側が物理的に離れていたため、顔を合わせたキックオフミーティングを行わなかった。
• その後のコミュニケーションも不足であった。

あたりが問題か。 物理的な距離の壁はデカイ。

それから、β版リリース日がナノパーセント日(あるいはそれよりも前)であった可能性も高いように思えるが、その点はどうか。

(Naney注:リスク図の)曲線の左側が水平になる地点が、「確率がゼロではない最初の日」である。しかし、限りなくゼロに近い。この日までに完成する確率は1ナノパーセント程度なので、この地点をN(ナノパーセント日)と呼ぶ。-- 熊とワルツを, p.65

自分も「これどれぐらいでできる?」と言われると、つい奇跡的最短期間を口にしがちである。 気をつけねば (もっとも、見積もりとは関係なく期日がセットされていて内容で調整ということも多いが)。

[ ソフトウェアプロジェクトマネジメント ]

• Joel on Software - 必読書 (2008-08-14)
• 開発スタッフ怪我をして入院 (2004-10-26)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスク... (2008-06-14)
• どうみても、そのままでは失敗しそうなプロジェクト (2005-05-16)

■ 一緒に仕事をしたい人のタイプ

日経ビジネスアソシエの臨時増刊号として「仕事の手本」という雑誌が出ている。 以前読んだ「早朝会議革命 - 元気企業トリンプの「即断即決」経営」の吉越浩一郎社長 (トリンプ)を含む、11人の経営のプロへのインタビューをまとめた仕事術誌である。

インタビューの中での「一緒に働きたい人/採用したい人」という質問に対する各氏の回答が興味深い。

最初のページから順番に見ていると「あれ? さっきも同じような事を読んだような」と何度も感じるぐらい、求められている人材は共通している。 (ある程度あることは当然の前提であるにせよ)スキルや知識というものよりもまず、

• コミュニケーション能力があること
• ポジティブであること
• うそをつかないこと
• 問題解決力があること

が求められている。 経営者は、そういう視点で見ているということだ。

どれも良く目にするポイントだがそれらが重視されているということは、やはりそれらを身につけるているものが少ないということかもしれない。

日々精進ですな。

• 日経ビジネスAssocie Online

• 早朝会議革命 - 元気企業トリンプの「即断即決」経営 (2005-07-16)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• 事業方針を「どのようにすれば〜」化すれば何かが見えてくる (2006-01-05)
• キックオフミーティング1日目 (2004-10-25)
• すごくない会議 (2005-06-29)

■ ソフトウェアかんばん「見えない化」

チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。

興味深いポイントについて:

@ ソフトウェアかんばんが見えない

今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。

先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。

ぐらさん言わく「見えない化」

@ issue tracking

開発中に発生する

• モジュール間のインタフェースの問題点(あるいは不明点・疑問点)などの確認/議論の必要なもの
• ライセンス関連の問題など意思決定を要するもの

などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。

後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。

やはり基本は顔合わせということを実感。

またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。

どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。

できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。

(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)

@ インタフェースを変更するなら、古いのも deprecated 扱いで残して

複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。

通常開発中のコード内でのこのようなインタフェース変更については

1. インタフェースを変更する人が、同時に呼出し側のコードも修正してコミットする
2. しばらくは古いインタフェースを @deprecated で残しつつ、新しいインタフェースを提供する

のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。

ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。

@ 止まらないプログラミング

変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。

• 30分ルール

「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。

関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。

チームのトータルのスループットを最大にするようにコミュニケーションしよう。

• ソフトウェアかんばん (2005-10-28)
• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• すごいKPT事後評価セッション (2005-10-07)
• 京大式カード (2005-10-26)
• ビジネスメールガイドライン案 (2006-05-05)

■ メールによる社内コミュニケーションの問題

以前から何度も議題になる(けれども改善されない/しない)問題として、本社/東京オフィス間のコミュニケーション問題がある。 うまく情報共有ができていなかったり、共通認識になっていない背景にもとづいてのコミュニケーションによってうまく意思が伝わっていなかったりするという問題である。 特に電子メールによるコミュニケーションに多発気味のようである。

しかしなにもこれは本社/東京オフィス間だけの問題ではない。 電子メールをその特性を意識せずに使用することによって、コミュニケーションしていると思いながらも「実は一方通行」でしかなかったり、あるいは「その一方通行さえうまくできていな」かったりすることがままあるのである(もちろん自分も含めて)。

そこでまずは電子メールを含むコミュニケーションツールの利用方法について検討し、ガイドラインを決めていこうということになった。 もちろんガイドラインはシンプルかつ効果的なものにしたい。

まずは電子メールについて現状としての雑感を(特に自分の場合について)。

@ メーリングリスト

「ま、返事しなくてもいっか」と思わせるメールの筆頭は、メーリングリスト宛のもの。 以下のものは無視してしまう(あるいは先送りしているうちに忘れてしまう)事が多いタイプ。

• 宛先不明のもの/「○○各位」宛のもの
  • 10人が参加しているメーリングリストでは、送信者から届くパワーは通常のメールの1/10以下である。
• 「ご意見があればお願いします」
  • (誰かが意見するだろう)
• 「ご意見があればお願いします」
  • (メーリングリストに? 個人宛に? まいっか)
• 「どちらが良いと思いますか?」
  • (メールを出した貴方はどう思っているの?)
• 誰か一人(か二人)がメーリングリストに返事した
  • (話が進んでしまっているようだし、出遅れたな。もういっか)

@ 「ご検討ください」

「検討しなければならないなぁ(そのうち)」->「しばらくたっちゃたなぁ」->(リファイル)

@ 「ご意見ください」

「意見を考えなければならないなぁ」->「しばらくたっちゃたなぁ」->(リファイル)

@ 「○○してください」

○○した -> (完了報告なし) -> (リファイル)

@ 「した方が良いと思います」

(そうですね) -> (リファイル)

@ 形式的な不備

• 無関係なメールへの返信によって作成された新規メール
  • (一応読むけど)
• 何を言いたいのかよくわからないメール
  • (ぱっと見るけど)
• typo
  • (人間誤ちがあるからあまり咎めはしないけれど、それに気をとられて本文に対する集中度ダウン)
• (いわゆる)全角文字と半角文字が混在
  • 内容の評価までダウン
• 文章に句読点が無い
  • (日本語?)
  • 適当にメールを送ってきている? ではこっちも。
• 長～～～～い全文引用(の全文引用の全文引用の……)
  • で、本文は2行ですか?

@ 添付資料が MS Word 形式

「○○について問題があればご指摘ください」-> 読めん (Mew が wvHtml で変換して表示してくれるからちょびっとだけ見るけれど)。

@ 添付資料が MS Excel 形式

「○○について問題があればご指摘ください」-> 読めん (Mew が xlhtml で変換して表示してくれるからちょびっとだけ見るけれど)。

@ 予定の日時を間違えている

ヤバ。間違える(自分)。送信前に読み返しても、なぜか気がつかない。

@ 内容がムカつく

まぁそういう場合もあるので、差し引いて読まないといかん。

@ 時候の挨拶つき

いいね! 非常にいい。ほっとする。嬉しい。いい気分。

自分ではほとんど書かないんだけれど。

@ 結局のところ

「誰に」「何を」「いつまでに」「どの品質で」して欲しいのかが不明確というのが問題の大部分を占めていると思う。 会話におけるリクエストでもこれを明確にできていないのだから、メールではなおさらな状態である。

逆に言うとこれらがはっきりしていて約束がかわされたならば、、添付ファイルフォーマットの問題などは些細な問題で(いや、面倒ではあるけれども)、相応に努力してしかるべきアクションをとっていくであろう。

それから、リクエストメールに対してはどうするにせよ「受ける」「断わる」「別の提案をする」というレスポンスをリクエストした者に返すべきだけれど、メールだとこれがないがしろになってしまう事も多い。 これも大きな課題であるな。

まずは、メッセージのタイプ(指示/命令? リクエスト? 情報? ……)を分析して、どのようにすれば効果的なコミュニケーションがなされるようになるか検討してみよう。

• 研究結果「メールの意図が正しく伝わる確率は5割」
• 各種コミュニケーション・ツールの強みと弱み － 1/2 － ＠IT情報マネジメント

[ ビジネスメール ]

• ビジネスメールガイドライン案 (2006-05-05)
• 日本語ファイル名どんとこい (2005-03-07)
• Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
• [ Java ] Unicode (UCS) -> 別の charset (2003-12-12)
• GnuPG の布教失敗 (2005-02-02)

■ ビジネスメールガイドライン案

以前メールによる社内コミュニケーションの問題について書いて以来、いろいろと考えてみている。

そんな中、東洋経済新報社の「Think! SPRING 2006 No.17 超ロジカルシンキング」の中に参考になる記事を発見。 照屋華子氏の「ロジカル・ライティング - 論理的に考え、伝えるための3つの鍵を身につける」という記事だ。

すべてのビジネス・コミュニケーションは「伝え手」「受け手」「テーマ」「答え」「期待する反応」という5つの基本要素で成り立っている。-- Think! SPRING 2006 No.17 p.43

おお、ちょうどこういう切り口を探していたところだったんだ。 電子メールによるコミュニケーションも全く同じ枠組みである。 記事の中ではロジカル・シンキングをコミュニケーションで生かすという話題を中心に展開しているが、十分メールの書き方に通じるものがある。

この記事と、さらにちょっと前に買った「SEの実力を磨く究極仕事術」のメール術の章を参考にガイドライン案のスケルトンを作ってみた。

感情論は今回は置いておいて、情報共有・課題共有・リクエストの明確化・処理促進をポイントに列挙。 それから署名その他、一般的な話もいまのところ省略。

ポイントを列挙しただけなので、他人にもわかる形にはなっていない。

まずは自分自身に適用して、整理していってみることにする。

@ 1. 考える

• 【伝え手】伝え手は誰? (自分)
• 【受け手】受け手は誰?
• 【テーマ】テーマは何? 問いの形で。メールのテーマは1つに絞られているか?
• 【答え】 テーマに対する答え(テーマに対する説明)は何?
• 【期待する反応】受け手に期待する反応は何?
  • 誰に、いつまでに、何をどうして欲しい?
• コミュニケーション手段としてメールは適切?

@ 2. メールを書く

 ○○様へ                     # 受け手

 △△の××(自分)です。       # 伝え手

 テーマ
 ******
 コミュニケーション設定

 ○○の結論                   # 答え (結論)
 ==========
 ...

 (ここまででポイントを言いきる。)

 具体的な内容                 # 答え (詳細)
 ============

 項目1
 -----
 ....

 - リスト項目
 - リスト項目

 項目2
 -----
 ...

 - リスト項目
 - リスト項目

@ サブジェクトを書く

• 見ただけでわかるようにする
  • □ 具体的に書く

@ 導入部を書く

コミュニケーション設定を行う。

• □ 冒頭に宛先【受け手】を明記する。(誰に読んで欲しいのか? 他に誰に送られているのか?)
• □ 次に発信者【伝え手】を明記する。(From: フィールドに頼らず書く → 印刷・コピー用)
• □ 【テーマ】を書く。
• □ (オプション)【テーマ】の経緯・背景を書く。(「なぜこのテーマのメールがくるの?」)
• □ (オプション)なぜこの【伝え手】からなのかを書く。(←「なぜあなたからリクエストされるの?」)
• □ 【期待する反応】を明記する。
  • □ 「誰が」「何を」「いつまでに」「どのような品質で」して欲しいのかを書く? (← 「で何をして欲しいの?」)
  • □ 反応のメリットを書く (←「なぜこの反応をとらなければならないの?」)
  • NG 「ご意見があればお願いします」 → ない場合は?
  • NG 「どちらが良いと思いますか?」 → 意見として? 決定として?
  • NG 「ご検討ください」→ 検討した後どうして欲しいのか?
• □ (オプション)なぜこの【受け手】に読んでもらいたいのかを書く (←「何で自分なの?」)
• □ 特記事項があれば書く
  • □ 答えの情報源など

@ 答え (結論)

結論を書く。

• □ 詳細まで読まなくても済むようにする。
  • NG 「以下のように……」 → 要旨を書く
  • NG 「添付ファイルの通り」 → 要旨を書く

@ 答え (詳細)

根拠・資料などを書く。

• □ 受け手から見て必要十分な情報を書く
  • NG 「添付ファイルの通り」 → 要旨を書く
• □ 受け手が読みやすいように書く
  • □ リスト化する

@ 全般

• □ 具体的に
  • NG 「来週までに……」 → 「×月×日までに……」
  • NG 「先日の……」 → 「×月×日の……」
  • NG 「この間の……」 → 「×月×日の……」
  • 説明は肯定形で書く (否定形だと具体的に何なのかわからない)
• □ 論理的に
  • □ 構造化する
  • □ リスト化する (箇条書き化する)
• □ 受け手が読みやすいように
  • □ フォーマットを工夫する (ソフトウェア技術者間なら reStructuredText がお薦め)

@ 3. 送信する

• □ 送信する前に見直す
  • □ typo チェック
  • □ スペルチェッカ通す

@ A. メールを受信した時

@ まず返信する

どれか

• リクエストを「受ける」 / 返信で処理する (意思決定を返すなど)
• リクエストを「断わる」
• 「別の提案をする」
• 明確化の質問をする

メールでは不適当と思ったらコミュニケーション手段を 直接 / 電話に切り換える。

@ B. 返信する時

@ サブジェクト

• □ テーマが変わったら書き換える

• メールによる社内コミュニケーションの問題 (2006-04-12)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 今日のさえずり - インデント幅4をインデント幅2に改宗させた (2008-09-03)
• 「プロジェクトマネジメント」はどうやって勉強すれば良いですか? (2006-11-22)
• 私的10大ニュース2005 [ comp ] (2005-12-31)

■ GTD アクション確保のための時間割

複数の提案書レビューをショートサイクルで繰り返すというスタイルのフローをいま実践中で、そのため最近はスケジュールにミーティング時間がどんどん書き込まれるという状態である。

自分の中でルールを確立していないため、ミーティング時刻の設定はなんとなく。 何も考えずにこのまま続けていくと、スケジュールがミーティングで埋まってしまいそうだ。 しかしそうなるとその他のアクションが実行されず、責任ある仕事ができなくなってしまう。

いい機会なので、GTD にある次の行動リストの項目を実行するための時間帯とミーティング時間帯をある程度分けて決めてみてしまうことにした。 生理的な「はかどる時間帯」等も考慮してタイムテーブルを考えてみた。

• *1 金曜日は GTD 週次レビュー時間
• *2 単調作業 / 事務処理 / 整理等

論理的な仕事に向いている午前中には社内ミーティングを入れずに、頭を使うアクション(計画や提案立案など)を実行したい。

14:00 - 15:00 は眠くなる時間帯のようなので、待つリストをチェックして他の人に状況を確認するなど、コミュニケーション用時間とする。

社内ミーティングは原則 15:00 - 17:00。場合によっては前後 1時間もミーティング設定可。この時間帯にミーティングがない場合は、単調作業があればこなすようにする (貴重な午前中にやらないように)。この時間帯は繰り返し作業などに向いているらしい。

そういえば社内ミーティング 13:30 開始っていうのがあるのだが、これは準備する側の時には楽だけれど、そうではない側の時はその30分が中途半端であまり効率が良くないというのが最近の印象だ (その隙間時間を活用するのが GTD の極意ではあるのだが)。

最後の1時間は日によって無かったりする可能性があるので、バッファ的な時間としておく。in-box もここで処理しておく。

まずはこれでトライ。

[ 時間管理 ]

• なぜか、「仕事がうまくいく人」の習慣 (2007-04-15)
• 2008年夏の GTD 運用ツール (2008-07-23)
• Task Coach で GTD (2008-06-23)
• そうか、備忘録ファイルがあればいいのか (2006-03-30)
• GTD Next Actions リスト用ノートをやめる (2007-07-25)