会議についても「割り込み禁止状態」を確保する
4. それぞれのマイクロタスクは「割り込み禁止状態」でこなす 大切なことはマイクロタスク一つ一つを「決して他の仕事を間に挟んでは出来ない仕事」と覚悟して、全力疾走でこなすこと。その間はメールのチェックはしないのはもちろん、電話がかかって来ても取らない。トイレにも行かないし、席から立ち上がりもしない。誰かが机に来ても、「今はだめ」という。脳を１００％そのマイクロタスクに集中し、一気に書き上げる。つまり、マイクロタスクを処理している時にコンテキスト・スイッチをしてはいけないのだ（割り込み禁止状態）。
会議についても「割り込み禁止状態」を確保することが重要だなぁ、とは思う。
オープンにアクセス可能な会議であるということは容易に外部からの割り込み可能ということを意味する。
会議参加者への確認事項が発生して、それがどんなに軽度なもの・・・たとえばスケジュールの確認とかあまり緊急性を要しないこととかも・・・でもすぐに声をかけて会議を中断させてしまうことができるのはどうかと思う。
まぁ「確認するから後で」の一言がいえればそれで済むという話もあるが。
オープンなコミュニケーションスペースを設けるのはそれはそれで別の意味があるのだろう。
というか、「今ちょっといい？」と言って気楽に行うもの（いつ中断されてそのまま終ってもいいようなもの）とあらかじめ時間を設定して行うものは手段を分けるべきかもしれない。
あともう一点会議について。
以前勤めていた会社では、とあるGroupWareを共有スケジュールとして利用していて、その際の利点として、会議の参加者の時間調整の手間暇が殆どかからないというのがあった。
会議を開きたい人が全員の空いている時間を適当に選んでスケジュールを設定すればいいだけだから。
（「入れたよ」という声掛けは必要。常にスケジュールを確認しているとは限らないし）
あと、「この日は残業したくないなぁ」という日も予定を入れてしまえばそれが会議などで潰れるということはほぼない。
が、反面、余りに簡単に会議を設定できるということもあり、やたらと会議ばかりで時間を消費するという現象もあってそれは欠点なのでそれは注意したほうがいいかと思う。
プログラミングの話。
これを読んでも分かるように、私のプログラミング・スタイルには、ソースコードのバージョン管理をしてくれるシステムが必須。
自分も「たとえ一人でも」バージョン管理システムを使うようにしている。
過剰な修正履歴を入れることがほぼなくなり、そうすることでソースコードの視認性が高まるのはラクでいいなぁ、と思う。
コメント欄から。
>大切なことは、この「割り込み禁止状態」と >「割り込み可能状態」をはっきりと区別して一日を過ごすこと。 外資系のIT企業のように1人のプログラマにワンルーム与えてたり、そうでなくてもパーティションで区切られたワークスペースでないと無理ですね。
一日中、後ろを人が行ったり来たりしたり、すぐ横で全然別の企画会議をしているような場所で働いたこともあるけど、ヘッドホンさえあればとりあえず集中できる。
もう一つコメント欄から。
私は、自動車業界のシステム開発を担当していますが、この業界では、ゼロからのやり直しよりも、 「なぜ動かなくなったか」を解析し、何が真因かを突き詰めるまで、何時までも時間をかけます。 これは、「失敗した原因がわからないとまた同じ過ちを繰り返す」、というトヨタ理論によります。 とっても面倒で要らないと思うのですが、この業界では、成功した要因も失敗した真因も突き止めるまで 仕事をとめます。この原因を抑えておけば次回の開発ではよりやり直し業務が減り、効率が上がるらしいですが。
テトリスに例えると、普段は四角いブロック・・・想定内のこと・・・が降ってくるのだが、たまに三角形とか五角形のブロックが降ってきて、「一度積み上げたブロックを壊すべきか」「このままブロックを積むか」の判断が要求される世界だからなのか。
それとシステムの寿命にも関係するけど今の最善手があっという間に悪手になりうる世界。・・・原因が判明したとしてもその上のレベルで物事が変化してしまう。
あとタスクの抽象度が上がるにつれて、解決手法が「時間」「金」「人手」に集約されていくのではないかと思う。
