1440分の使い方とここ20年くらいで学んだライフスタイル
たまたま知った本が割と考え方が同じで、実際やっていることも同じだったので感想とか、自分の振り返りとか。
スケジュールを埋めることが嬉しかったとき
2010年あたりは仕事的にも前のめりというか多忙であることとプロジェクトやビジネスをリードしていると思っていた時期で、それがスケジュールが予定で埋まっていく感じがある意味、自分が求められているのだという承認要求を満たしていたかもしれないな、と思ったりしたのです。
今は逆に如何に自分の作業をする時間を確保するかの方に価値があると思っていて、会議によっては出たくない（＝会議目的がはっきりしないので出たくない）と宗教替えをしたような感じになっているのです。
我ながら面白いと思うのは自分の価値観が変わりやすい人間なんだなと。
優先順ではなく優先順位
優先順の高中低やHMLは全くの意味のないことは、それを実務で使っていて迷った経験を思い出すとそのやり方、システムに間違いがあると自ら気づければよかったけれど、実際に間違いだと気づいたのは、優先順位をつける（＝１番から順位を振る）ことに意味があると経験をしたから。
それはアジャイル開発系の本やスライドで知り、実際に例えば課題管理表などでどれからリソースを割り振るかとか着手するかとかで順位をつけないと兵站が分散し、伸びきってしまうと実感したからなのです。
今、こうして書きながらもあのときにもアジャイル開発系の本を読む前でも順位づけを無意識にしていた、つまり経験していたことが本で形式知と融合して納得感が生まれたのかもしれないなぁと、良い思い出をつなぎ合わせてみたり。
朝の価値
早朝の冬なら真っ暗な時間帯に電車に乗り、さっとソーシャルをチェックして、席に座れれば仮眠し、開店したばかりのカフェの隅に陣取り、書き物をしたりやろうと思っていたタスクをこなしたりするようになったのは、誰にも邪魔されない時間を確保することの価値を見出してから。
これが夜だとさっぱりダメで。
あ、某ブルワリーだと、パイントのクラフトビールを２杯飲みきるまでに校正をしようとか、書き始めの書き物を進めるとかはパフォーマンスは出ないけれど、腰が重くなりがちなことを始めたり、ことを終わらそうとする気付には悪くはないかな。
ToDoよりタスクカード
仕事を忘れる人が仕事を忘れないためにはToDoリストを進めることもあるけれど、いや、メモしたかを聞くくらいかな。今は。
自分のは、付箋に作業名と期限を書いて、ノートに貼っておくパターンが多い。時間をブロックすることも目的にするならスケジュールに入れてしまうのがいいのかもしれないけれど、今の所はそこまで可視化して他人がスケジュールを割り込んでくることを防止する必要性がないくらい時間をそこそこ確保できているから、ということもあるかもしれない。
また、仕事の内容が変われば、スケジュールをブロックする意味合いを持たせる必要性が生まれるかもしれない。
先延ばししない＝すぐやる
これはある時期からやっていて、特に他人から割り込んできたものは即返す＝ボールを握ったままにしないという考え方を持っている。
自分の仕事は時間を確保していればどうにでもなるが、他人のリソースを当てにするのがプロマネやマネージャの仕事でそれに慣れていると、依頼されたものは先に片付けておくとか思ったりもする。
まあ、どっちかというと今やらないと忘れてしまう危険性があって、それをやってしまうと忘れたことに気づかされてそれがどんなに価値のない作業であっても返す義務がある場合、重要な作業をしかかって中断したくなくても中断せざるを得なくなるので、すぐるやるようにしている、はず。
罪悪感なく定時に退社する
定時であろうが、中座であろうが、それをする必要があるときにはさっさと出ますね。これは定時前に出勤するようになってからするようになったけれど。
確か、その時は外部団体での活動もしていて、それの会合の都合からも早く出る必要があったから、だったからかもしれない。
今は、定時だからピンポンダッシュ、ではないけれど、定時になればシャットダウンして、机の上はほぼ何もない状態で帰る。
罪悪感なんて覚えるのは最初だけだし。
というか立場的にもマネージャは定時で帰らなければならいと思っている。もし部下が残って入れば何時までやるのかを聞いて確認するし、あとで周りに聞けば（結果的に嘘になって）長時間仕事をしていてもわかるし。もちろん、勤怠に入っていなければ指導するし。
それよりは勤務時間内に終わる作業計画を立てるように指導している。そうしないと続かないので。
ノートを取る
備忘で取る感じが多いか。今は。アイデア的にメモを取ることもある。それ、ビジネスになる鴨とか。
部下やプロジェクトチームのメンバには、いきなりスライドを作るな、と言っているのですよ。スライドにしてしまうとアイデアや何を伝えるかより、クリップアートやたくさん知っていることを書くことが目的になってしまうので。
だから、A4かA3のコピー用紙かノートに描いて、頭の中で知っていること、書きたいことを全部出し切ってから作業としてスライドに転記する様に言っている。
なかなかわかってもらえないが。
メール
Webメールになるとどうも検索でなんとかできてしまうので受信トレイに入れっぱなしになってしまう。
でも、以前はフォルダ分けしていて、処理したらフォルダに移していた。Webメールでそれもできないものは、勘弁的にタグ付けするルールを作っておくこととしかできないが、それはそれでフォルダに移すことと論理的には識別の観点で同じなのだろう。
ミーティング
基本的に自分が主催のミーティングでは連絡はほぼ皆無。リマインダ的に数分でおしまい。
あとはチームの共通の活動に全て当てる。ある意味モブミーティングであり、モブチーム活動である。
チームの目標をバラバラでやる意味はない。とは言え、集まって議論をしていても何も生まない。
チームのメンバに、チームの目標をどう仮説を作り、計画を立て、やるのかに時間を使う。
noという
いや、Yes,butだな。コンプライアンス上問題がなければ、プロのイズムと不整合がなければ。
ただ、作業の割り込みは、自分がつけた若しくは協議した優先順位があってそこに割り込むので、どうするかは決めなければならない。
その割り込みをすることは可能だが、優先順位をつけたバックログは順送りになるし、もちろんそれぞれの納期は繰り下がるが、よろしいか、と。
ここまで言い切らなければ、ただの都合の良いエンジニアでしかなく、この調整をしないエンジニアは切られる。単なるリソースの駒でしかないからだ。
パレートの法則
これまでのエントリに書いてきたとおり、20％にリソースを割かなければならない。プロジェクトも人材育成もビジネスも。
怠ける
エンジニアのある時期から、プロマネであるなら、マネージャこそ、怠けるために、楽をするためにどうしたらいいかを準備し、実践し、改良する。
まさに継続的改善の実践である。
ただし、怠けるのが妥協ではいけない。
今日のテーマ
今日何するか。これを片付けよう。朝、ベットから起きたときにそれが頭に浮かぶ。そうでなければ仕事なんてやっていられない。
ミーティングでもそうだ。
なんども繰り返し作業しない
1つの作業を何度も初めから繰り返し見直したり、手を入れたりすることが非効率的な作業の仕方だ。
このくらいでいいというのは妥協である。ここまでが慣性基準だから、ここまでとやるのが良い。
メールをビジネスで使うことがまだ多いが、尋ねるときには何度もやり取りをしない様に、尋ねたい、期待する結果を１回送信するメールで得られる様にする。でなければチャットでいい。
まあ、チャットでも聞きたいことは１回で期待する結果が得られる様にしなければならない。
メールは伝えようとしている期待値の1/10しか伝わらないことを知っておくべきだ。
不可侵時間帯
朝の価値で書いたとおり。
エネルギー
朝摂っている食事を変えた。いわゆるバターコーヒー（完全無欠）にしたら昼食まで間食を取らなくなったし、お土産のお菓子に手をつけなくなった。
お菓子を食べているエンジニアが痩せないと言っているのは自分の行為を計測で規定兄からだ。
１週間
朝起きる時間を一定にすること。週末にジムに行くこと。平日の夜は予定で産めないこと。自分のリズムを作り、一定に保つこと。
朝を変える
朝が一番価値がある。頭が冴える。夜は寝る時間だ。
この他にも50年も生きて入れば色々と実践している元になっているイムズも価値観もある。けれど、この本に書いていあることは外れてはいない。Kindleならお手頃だ。
