プログラマーはソフトウェアを開発する際、無駄な処理や非効率的な処理を極力排除しようとする。この意味においてプログラマーは処理の効率化の専門家であると言える。ならば私たちプログラマーはソフトウェアだけでなく、自分自身の人生についてもパフォーマンスチューニングできるはずだ。

1. 呼び出し回数の多い処理を疑う
プログラムでしばしばパフォーマンスのボトルネックになるのは、「ループの中の処理」だ。例えば10万行10列のデータを1列ずつ処理していくようなループ処理の中身を1ミリ秒速くすれば、全体で約16分の速度向上が見込める。

人生においても、実行頻度の高い処理はパフォーマンスチューニングの効果を得やすい。

例えば職種を問わず毎日2回ずつ実行される処理として、通勤がある。通勤のチューニングにより、営業日が月に20日だとして、もし通勤を片道30分短縮できれば、月20時間の時間を得ることができる。具体例として私の場合、「通勤を徒歩10分以内にする」というパフォーマンスチューニングをこの13年程実践してきており、その結果として浮いた時間をネットゲームや子育てや酒などの時間に割り当てることができている。

もっとも、通勤時間を「無駄な時間」として見るのではなく、「集中して本を読める時間」、「考え事をする時間」、逆に「何も考えずに済む時間」などとポジティブに捉えているのであれば、それは必要な処理、ということになる。プログラムで言えば「こんなログ出す必要ないでしょ」と高速化のために取ってしまって後で困る、というような話である。

他にも、例えば営業の人で顧客とのメールのやり取りが頻繁、という人であれば、シグニチャーの他に、「お世話になっております。」で始まり、「何卒よろしくお願いいたします。」で締めるテンプレートを用意しておけば、メール送信回数分のチューニング効果が得られるかもしれない。ちょっとした工夫でも、呼び出し回数の多い処理は、その頻度に比例してパフォーマンスチューニングの効果を得やすい。

2. スイッチングコストを減らす
プログラマーからよく相談を受ける悩みとして、「複数のプロジェクトを兼務していると、頭の切り替えに時間がかかって効率が上がらない」、「他部署からの問い合わせで集中が途切れてしまい、開発に集中できない」というものがある。

これらに対する最もプリミティブな対処方法は、「プロジェクトを兼務せず一度にひとつのことしかやらないようにする」、「他部署からの問い合わせを受け付ける時間を決める」というものだが、前者についてはリソース状況からなかなか実現が難しかったり、後者については部署間の心理的な壁をつくることになってしまったり、開発は集中できるようになっても、「ちょっと聞けば分かること」がすぐにわからなくなり、フロント寄りの部署の業務効率が下がってしまったりするため、スマートな解決にはならないケースが多い。

そこで、上記のような課題に対して、アプレッソ社長、HULFT CTO、MIJS製品技術委員会委員長など比較的多数の役職を兼務しつつプログラミングしている私が工夫している方法を紹介したいと思う。

その方法とは実に簡単であり、なおかつ3つだけである。

2-a. 「本日のToDo」ページ
複数の業務を行ったり来たりする際に気をつけるべきことは、実作業以外のオーバーヘッドを最小化することである。例えばプロジェクトAとプロジェクトBを兼務していたとして、Aのタスクの最中にBのタスクが入ってくると、Bに関連した未解決の諸々の課題について考え始めたり、BのToDoで漏れているものがないかを考え始めたりしてしまい、Bの作業にすぐに着手できないことがある。これはプログラムで言えば、あるライブラリを呼び出すには、その度に初期化処理を呼びださなければならないようなものであり、処理効率の観点からあまり望ましくない。

そこで私は何年か前にGoogle Docsに「本日のToDo」というページを作った。

ここには、あらゆるプロジェクトに関するToDoや解決すべき課題の中で、自分がやるべきことがすべて書き込まれている。その中で「最優先で、できれば今日やりたいこと」を一番上の「本日のToDo」に、それ以外のタスクを「今後のToDo」に書き込んでいく。ここには、忘れてはならないことはすべて書き込まれており、仕事以外にも、例えばプライベートで友達との忘年会の店の予約をするとか、そういう些細なタスクもすべて書き込まれている。もし書き忘れや新しく出てきたタスクがあれば、公私問わず、気づいた時点でPCかスマホからすぐにここに書き込むようにする。また、本日のToDoが溢れたら、その中のいくつかを今後のToDoに移す。また、優先順位付けに凝り始めると、それ自体が新たなオーバーヘッドとなるため、優先順位も時間をかけて決めたりはしないようにする。また、ToDoに書き込むよりやってしまった方が早いことはすぐに終わらせてしまうようにする。

このページを使うようになってからは、公私問わずあらゆるタスクのToDoが一箇所に書き込まれているため、タスク切り替えの際に関連する諸々のことを考え始めてしまう、という時間はかなり削減され、パフォーマンスチューニングの効果が大きかった。

2-b. インボックス50
メールの受信箱は、事実上ToDoのリストである、と言える。未分類のメールは返信が必要だったり、まだメールに関連するイベントが終わっていなかったりする。

「インボックスゼロ」は、受信箱を常にゼロにすることでタスクを終わらせていく方法だが、特に兼務している仕事が多く、それなりに多忙な場合には、現実的にはすぐに終わらせることができず、受信箱に残さざるを得ないメールも出てくる。

しかし受信箱にメールが溜まっている時にはタスクの見落としやメールの返信漏れが発生している確率が高く、忙しいからと言ってどんどんメールが溜まっていくのはやはり問題がある。

そこで私は「インボックス50」を実践している。メールをゼロにすることはできないが、会社のメールと個人のメールとそれぞれ、Gmailで受信箱が1ページに収まるよう、受信箱のメールが50通を超えないようにしている。もし超えてしまった場合には「メールの整理・返信」を「本日のToDo」に入れる。

「本日のToDo」と「インボックス50」を組み合わせることにより、自分がやるべきことはすべてこのどちらかに入っている、という安心感が生まれ、スイッチングコスト削減を加速していくことができる。

2-c. 集中して取り組むべき作業をスケジュール化する
問い合わせなどやタスクの切り替えなどでなかなか集中して開発する時間が取れず、かつあまりシステマティックに「問い合わせは何時から何時まで」と決めてしまうと軋轢が生まれることが懸念される場合、集中して取り組むべき作業を「13:00-16:00 ○○作業」というように、スケジュールに入れてしまう。このようにすることで、パッと見は何か予定が入っているように見えるため話しかけられる確率が下がることに加え、もし作業だと分かっても、「今は本当に集中が必要なんだ」と感じてもらいやすくなる。「7つの習慣」のトレーニングでは、ホテルの”Do not disturb”の札と同じような要領で、集中すべき作業が中断されないための「第一領域の作業中」の札を貼る方法が紹介されていたが、これも趣旨としては近い。

3. 選択肢を整理する
物事があまりスムーズに前に進まない場合、「取り得る選択肢が整理されていない」ことが原因であることが多々ある。例えば、あれもあるしこの方向性も考えられるしみんな意見が違うしどうしよう、というようなことを皆で悶々と考えており、その日だけでなくまた次の会議でも皆で悶々としている、というようなケースである。

様々な意見があり、方向性を決める悩ましい物事にも、「選択肢を整理する」という視点で望めば、たいていの場合いくつかの選択肢に方向性を絞り込むことができる。

選択肢を整理する際には、それぞれの選択肢のメリットとデメリットもできるだけ公平にまとめていく。

ここでは自分の案のデメリットもきちんと説明し、自分の意見と対立する案も、相手の気持ちになってメリットをきちんと強調することが重要だ。

取り得る選択肢と、それぞれの選択肢のメリットとデメリットが整理されていれば、あとはそのどれが望ましいのかを判断するだけなので、進みが早い。

一見、意見が対立していて着地点を模索するのが困難に思えるような場合にも、それぞれの立場の強調すべき点が浮き彫りになるため、選択肢を整理して議論していけば意外とあっさりと解決してしまうことも少なくない。

プログラマーは普段switch文などで条件分岐を整理することには慣れているので、自分の得意分野と思って胸を張って選択肢整理役として手を上げることをおすすめしたい。