今回は「ITエンジニアに読んでほしい！技術書・ビジネス書大賞2019」1で、ビジネス書技術書ベスト10に選出された「エンジニアの知的生産術」から、個人的に面白そうなポイントを4つ選んで紹介してみます。ここで取り上げた以外にも多数のテクニックやTIPSが紹介されてるので、気になった方は本書を読んでみてください。参考になるものが少なからず見つかると思います。（私は65箇所ありました）
西尾 泰和 著
エンジニアの知的生産術 効率的に学び，整理し，アウトプットする／技術評論社
目標を立てるのは簡単ですが、有効な目標を立てるのはちょっと難しかったりします。
「来年は猫写真をたくさん撮ろう」というのは目標になりますが、具体的なことが示されていないので、これを元に年間計画を作っても「1月は正月で猫が撮れるぞ」「2月は豆まきで猫が撮れるぞ」2みたいなフワッとした計画になりがちです。何か基準のようなものが欲しいですね。
はい、こちらに用意しております。
組織が目標設定をするときの基準として考えられたものにSMARTというものがあります。
- Specific：改善を行う具体的な領域が明確である。
- Measurable：量、もしくは少なくとも進捗がわかる指標がある（計測可能）
- Assignable：誰が計画の実行をするのかが明確である
- Realistic：現実的に達成可能である、現実に必要なリソースが与えられる
- Time-related：いつ結果が得られるかが明確である
これらの基準を使って目標を考えると、このようになります。
具体的な領域を明確にする→毎日うちの猫を撮る。
計測可能な量や進捗→50枚/日 猫を撮る。
誰が実行するのか→私だ！私だ！誰にも譲らんぞ！
達成可能である→50枚だって？うちの猫の魅力なら余裕だな。
結果がいつ出るか→写真管理ツールがあるから一日毎の撮影枚数がカウントできる。
これらを踏まえて目標を立てると、こんなふうになります。
なんとなく目標：「猫をたくさん撮るぞ」
SMART基準目標：「私が毎日うちの猫を50枚撮って、写真管理ツールで枚数をカウントする」
SMART基準で考えた方が具体的になって、なんだかやれそうな気になってきましたね。
これは組織目標を作るための基準ですが、個人の計画作成でも利用できる場面は多いと思います。
関数を設計するとき、後々の利便性を考えて必要とされている最低限のものより作り込んだことが一度はあったりしませんか？こうやって同意を求める時は失敗した仲間を増やして責任分散しようとしている時です（今でしょ！）。
最低限の機能の関数より、至れり尽くせりでいろいろなことをカバーしてくれる関数の方が優れているように思えても、それは違うよというのがYAGNI原則です。
YAGNI（You Aren't Gonna Need it）原則は、エクストリームプログラミングで提案された原則の一つで、「必要になるまで機能を追加してはいけない」というものです。その理由はこのようなものです。
日常生活では何かが必要になってから用意すると、出かけて買ってきたり通販の到着を待ったり、準備を初めて作ったりする必要があるので効率の面では悪くなります。プログラミングではコード管理からソースを落としてきて必要分を書くだけなので、待ちの時間や準備の時間がそれほどかかりません。トータルでは必要になってから作る方が短時間で済みます。
これはプログラミングの場合での原則なので、日常生活にも応用してやろうと思うと、肉のないチンジャオロース3を作ってしまうかもしれません。
今日中にやらないといけないことが今日の時間以上に積み上がってしまうことは、よくあります。
いつやるの？いm・・・やってやれるか(_｀・ω・)_ﾊﾞｧﾝ!!
人間の仕様として、目標の100%が到達できないと分かると、積極的に0%を目指す人が30%以上いると言われています。
100%ではなくても何かをトレードオフして、完成にこぎつけた方がずっといい場面もあります。
そういう時に何をトレードするのかというのをまとめたものが、緊急性分解理論4です。
状況によってどれから優先して検討していくかは変わります。悪影響が少ない物から選んでいくといいでしょう。
例えば、実装チケットが山盛りで対応が追い付かない状況だったとして、緊急性分解理論からこのようなアプローチが考えられます。
しかしどうやってもダメな時だってあります。そういう時のために、このリストにはもう一つ項目があります。
(_｀・ω・)_ﾊﾞｧﾝ!!
初めて仕事に就いたのはずっと昔で今とは違う会社でしたが、「1日8時間も集中力が続かない・・・自分は社会不適合者なんだ・・・」と思いました。しかしよく見ると、先輩社員もずっと集中しているわけではなかったのです。
T氏「DVDのリージョンコードを回避するにはね（ゴニョゴニョ」
O氏「花見の場所どこにする？」
I氏「AoE5おもしろーい」
だれも仕事しとらんやん・・・。
この現場は後に数万のバグチケットを生み、私は初めてのデスマーチを経験することになるのでした。
閑話休題。
集中力が続かないのは、別に怠け者だからではなく、人間の脳がそうなっているからです。
集中力と感受性はトレードオフの関係にあります。人間が狩猟をしていた時代、獲物の痕跡を見つけるためには意識と視野を広くして、見つけた後は対象の情報をより多く得るために意識を狭くして集中します。この頃の性質が今も続いています。
人間の性質だからといってそれに振り回されるより、うまく付き合える方がずっといいですね。
集中しすぎて必要なタイミングで集中が切れるより、集中と拡散を管理することで集中を利用できないかと考えた人がいました。
それがポモドーロテクニック6です。ポモドーロテクニックのルールは次のようになります。
ノートと時計があればすぐにできますし、ポモドーロテクニックをサポートするためのソフトウェアもたくさんあるので試してみやすいと思います7。
ただし、途中で割り込みが入ると集中力が切れてしまうので、一旦休憩してまたやり直す必要があるので、ポモドーロテクニックを始める時は割り込みがおきないようなタイミングを作りましょう。割り込まれた場合は、同じ割り込みを減らしたりタイミングをずらす方法を考えてみましょう。
1セット30分なので8時間フルタイムの仕事なら16セットできるのでは？と思われるかもしれませんが、セットを繰り返していくと疲労が溜まっていって1ポモドーロ(25分)集中が持続できなくなります。発案者も1日8セットが現実的な上限と紹介していました。使いどころをを考える必要がありますね。
私は家でPC作業をするときにタイマーをかけてポモドーロテクニックを使おうとしたことがあります。
しかし、猫がﾆｬｰﾝと鳴いたりデスクに乗ってきたりすると、猫が最優先事項に繰り上げられるため上手くいきませんでした。後悔はない。ﾆｬｰﾝ。
プログラミング能力はアクセルに相当するので、身につけるほどそれを実感できますが、走らせ続けるには速度計やブレーキも必要になります。本書はその部分に役立つ情報がたくさん載っていましたので、初心者からベテラン、あるいは非技術者まで幅広く読めると思います。
注釈
