生産性を高めよう ブレイクダウン：先延ばしを克服する方法

『SOFT SKILLS』より　生産性を高めよう

大きいことが必ずしもよくないのはなぜか

　タスクは、大きければ大きいほど威圧的に見えるようになる。ソフトウェアアプリケーション全体を書くのは難しい。しかし、コードを１行書くのは簡単だ。ソフトウェア開発の分野では、タスクやプロジェクトは小さいものよりも大きいものの方が増えてきている。

　しかし、私たちはずっと先の将来を見通すことができないので、こういった大きなタスク、プロジェクトは、私たちの生産性を低下させがちである。大きなタスクを全体として見てしまうと、ほとんど実現不可能なもののように見えてしまう。摩天楼や数kmも続く橋を構築するという、とてっもなく大きな仕事について考えてみよう。多くの摩天楼や橋が建築されてきたので、実現可能なことはわかっている。にもかかわらず、この種のプロジェクトを全体の形で見ると、誰もそんなことは実現できないように感じてしまう。

　私は、長年に渡ってゼロからアプリケーションを構築するような巨大プロジェクトに関わってきた。私は様々なアプリケーションを手がけたが、物事をブレイクダウンすることを学ぶまでは、どれひとつとして完成にたどり着けなかった。いつも最初はプロジェクトに情熱を注いでいるのに、すぐに細部に埋没しているような感じになった。私は、あとどれだけの仕事が残されているかを考えることに囚われていて、完成地点まで作り上げることができなかった。プロジェクトが大きければ大きいほど、失敗する傾向があったのだ。

　しかし、同じ問題を抱えるのは私だけではないようだ。ソフトウェア開発分野の様々な職務のなかでほかの開発者に仕事を任せてきたが、決まって夕スクの大きさがプロジェクトの成否の大きな指標になることを感じたのである。任せるタスクが大きければ大きいほど、彼らがそのタスクをこなせなくなる可能性が高くなるのだ。

　なぜこうなるかの理由のひとつはすでに述べた。大きなタスクの心理的な負担である。大きな問題に直面すると、私たちは問題解決の手順を進めることより、問題そのものについて考えることのために時間を費やしてしまう傾向がある。人は、もっとも抵抗の低い道を選ぶ傾向にある。大きなタスクに直面すると、ほとんど必ずメールをチェックしたり、コーヒーをもう一杯飲んだりすることの方が楽そうに見えてしまい、先延ばしが起きてしまう。

　しかし、大きなタスクがよくない理由は、先延ばしが起きることだけではない。タスクが大きければ大きいほど、しっかりと定義されていない傾向がある。店に行って卵、牛乳、パンを買ってきてほしいと頼む場合、タスクは明確に定義されており、あなたは何をすべきか正確にわかる。そのような夕スクは簡単に実行でき、あなたが正しくミッションをクリアする可能性は高い。

　それに対し、私のためにウェブサイトを作ってくれと頼むと、このタスクは先はどの例よりも相当大きい上に定義が明確でない。どこから始めるのかなど、答えられていない疑問がたくさんある。仕事を完成させるために何をしたらいいかが正確にわかる可能性は低い。私にとってウェブサイトの作成とは正確にどういう意昧なのか、私が何を期待しているのかの説明を書くことはできるが、そこまで詳しく説明すると、読んで理解するために時間がかかるし、エラーが起きる可能性が非常に高くなる。

　大きなタスクは、見積もりも非常に難しくなることが多い。リストのなかからもっとも大きい要素を見つけるアルゴリズムを書くためにどれくらいかかるかと尋ねられれば、たいていの人がかなり正確な見積もりを出せるだろう。しかし、ウェブサイトのショッピングカート機能を実装するためにどれくらい時間がかかるかと尋ねられても、出せる見積もりはほとんど当てずっぽうになってしまうはずだ。

　つまり、大きなタスクは小さなタスクと比べて精神的に負担になり、日程が遅れがちになり、一般に説明が曖昧になってエラーが起きやすく見積もりが難しくなる。

ブレイクダウンの効用

　しかし、希望を失ってはならない。解決方法はある。大きなタスクのほとんどは、小さなタスクに分解できることがわかっている。実際、ほぼすべての大きなタスクは、ほとんど無限ともいえる個数の簡単で小さなタスクに分解できるのである。

　大きなタスクを小さなタスクに分割することは、できる仕事量を増やすとともに、自分か仕事をしたときにかかる時間をより正確に見積もるために、私がいつも使っている常套手段のひとつである。

　実際、この本の構成との一致は偶然ではない。読者は、この本にはなぜ、こんなにたくさんの章があるのだろうと思われたかもしれない。本書の執筆に取り掛かったとき、少数の大きな章を書くのではなく、多くの小さな章を書き、それをいくつかの部にまとめるという方法を意図的に選んだ。これにはふたつの理由がある。

　まず第１に、この方が、読者が内容を消化しやすいだろうということである。私の場合、長い章を含む本は、章全体を読むだけの時間がない限り、取り出して読むのを避ける傾向がある。長い章を持つ本は、そうでない本よりも威圧感があるので、私はそうならないようにした。読者から見ても、千から二千ワードの章の方が､細かく分けられていない大きな章を持つ本よりも、読みやすく、威圧的に感じないのではないだろうか。

　第２に、この方が私にとって楽だからだ。私は、ほとんどの人がデスクの前に座って本を書き始めたものの、書き上げられないで終わることを知っている。私も何度か自分で本を書こうとして完成させられなかった経験がある。各章を長いブログポストくらいの小さなものにしておけば、本を書くという仕事は、はるかに管理しやすくなる。大作を書くというひとつの大きなタスクではなく、小さな章を書くという80個程度の小さなタスクに立ち向かうことにしたのである。

　タスクを小さく分割するとき、それらのタスクは取り組みやすくなり、夕スクを終わらせるために必要な時間の見積もりはずっと正確になり、正しく仕事ができる可能性が高くなる。小さなタスクで仕事を間違えても、大きなプロジェクトに深入りしたり取り掛かったりする前に修正するチャンスが見つかることが多い。私は、ほとんどの場合で、大きなタスクを小さなタスクに分割するのは正しいと考えるようになった。

どのようにして分解するか

　大きなものを分解するのはそれほど難しいことではない。ほとんどのタスクにに度に１ステップずつ進むようにすれば、簡単に小さなタスクに分解できる。象の食べ方の引用は、まさに真実だ。象を食べられる方法があるとすれば、一口ずつ食べること以外に考えられない。ほとんどすべての大規模な仕事でも同じことが当てはまる。大きなタスクを意図的に分割しなかったとしても、線形に進む時間の制約を受ける。あることを終わらせなければ、ほかのことを終わらせられない。それが延々と続くのである。

　大きなタスクがあるときに、その威圧感を抑えたいなら、まずそのタスクを完成させるために、どのようなステップを踏んでいかなければならないかを明らかにする必要がある。大きなタスクを任されたとき、私がまずしてみることは、タスクを小さい連続的な部品に分解できるかどうかを明らかにすることだ。

　最近、クライアントが持つ継続的インテグレーションシステムとデプロイの手順をクライアントのコードににとって有効なものにするというプロジェクトに取り組んだ。これはとても大きなタスクだった。当初、このタスクは圧倒的で、難しく感じたが、頭からぶつかっていくのではなく、タスクを小さなタスクに分割するところから始めた。

　最初は、コマンドラインからそのコードをビルド、コンパイルすることから始めることにした。自動ビルドを作るためには、まずこの作業が必要なのである。次のタスクとしては、ビルドサーバーにコードをチェックアウトできるようにすることが妥当なところだ。すると、ふたつのタスクを結合する新しいタスクを作れる。つまり、ビルドサーバーにコードをチェックアウトして、コマンドラインスクリプトでコードをコンパイルするというものである。

　私は、このような形でプロジェクト全体を小さなタスクに分解していった。すると、とても太刀打ちできない猛獣が小さなネズミのように見えてきた。プロジェクト全体は非常に難しい問題のように見えたが、個々の小さなタスクはばかばかしいほど単純に見えたのである。

　大きなタスクを多数の小さなタスクに分割しようとすると、自分に何をしてほしいのかについての十分かつ正確な情報が与えられていないことがわかる。大きなタスクは小さなタスクよりもしっかりと定義されていないという指摘を思い出そう。小さくて明快に定義されたタスクを作るのを防いでいる情報の欠如を明らかにすることは、大きなタスクを小さなタスクに分割するときのきわめて重要なステップのひとっだ。大きなタスクを小さなタスクに分割するために苦労しているなら、それは情報の欠如によるものかもしれない。

　しかし、これは悪いことではない。情報が足りないことがプロジェクトを始めてかなりしてからわかるくらいなら、プロジェクトの初期の段階でわかる方がはるかにいい。大きなタスクを小さなタスクに分割するときには、小さなタスクが明確な目標を持つようにしよう。そのような目標を明らかにしようとすると、本来なら、なければならない重要な情報が足りないことが明らかになることがよくある。

　アジャイルチームで仕事をするときには、私はこのテクニックを使って顧客から適切な情報を引き出そうとすることが多い。顧客は、サイトにショッピングカートを追加するなどの大きなタスクを依頼するときに、自分が望んでいることをあなたに正確に言えない場合がある。しかし、あなたが大きなタスクを小さなタスクに分割できるなら、彼らがしたいことをあなたに伝えやすくなるようにすることができる。

分解の問題点

　ブレイクダウン：分解というアプローチは、コードや問題解決にも直接応用できる。新人開発者の多くは、書くのが難しいコードとか解決するのが難しい問題と感じてしまうものを解決しようとして､問題に圧倒されてしまう。それは一度に解こうとするには大きすぎる問題にぶつかっていってしまうからだ。彼らは分解の方法を知らないのである（私自身、まだたびたびそうなるという点では同じだということを認めなければならない）。

　私たちは、自分が書くコードの複雑さを管理するために、自然のうちに分解というアプローチを部分的に行っている。私たちがすべてのコードを収めたひとつの巨大なメソッドを書かないのはそのためだ。私たちは、自分のコードをメソッド、関数、変数、クラスなどの構造に分解して、コードを単純にしている。

　プログラミングするために与えられた課題は、いかに複雑でも、必ず小さな部品に分解していくことができる。複雑なアルゴリズムを書こうとしている場合には、しゃにむに前進してコードを書こうとするより、独立に逐次的に解決できる小さな部品に問題を分割するといい。アプリケーションがいかに大きくて複雑でも､必ずコード行に煮詰めることができる。1行のコードは、どんなプログラマでも理解でき､書くことができる複雑度を決して越えない。だから、問題を十分細かく分解するつもりがあれば、わずか１行のコードを書くだけの能力だけでどんなアプリケーションだって書けるのである。

生産性を高めよう すべては集中から始まる

『SOFT SKILLS』より　生産性を高めよう

集中とは何か

　単純に言えば、集中は散漫の逆である。問題は、私たちの住む世界が注意を逸らすものに満ちていて、本物の集中とはどんなものかを知らない人が多いということだ。一日じゅう働いても集中できなかったということは簡単に起きる。メール、電話、テキストメッセージ、気晴らし、割り込みといったものが絶えず襲ってきて、集中力を奪い、ついには集中とはどういうものかすら、わからなくなってしまう。最後に集中したときのことを思い出すのに苦労している読者のために､本物の集中というものを思い出していただこう。

　最近のできごとで、本当に難しい問題に取り組んでいたのはいつだづたろうか。おそらく、何らかのバグをフィックスしようとしていたとき、あるいは、自分のコードが動かない理由を調べていたときだろう。そのときは、仕事に必死で立ち向かっていて、寝食を忘れ、時間は飛ぶように過ぎていったはずだ。あなたの気持ちをあえて逸らそうとした人々はあなたに怒嗚られるほどだっただろう。あなたはすべての注意をひとつの仕事に注ぎ込んでいたのである。

　これが集中だ。私たちは時々このような状態を感じている。しかし、問題は、ほとんどの時間では集中していないことだ。ほとんどの時間、私たちはまったく集中とは逆のモードで仕事に向かっている。簡単に気が散って、しなければいけないことがわかっている仕事に入り込めない状態になる。集中は、人生の多くのことと同じように、勢いの問題だ。一度集中した状態に達してしまえば、集中し続けることは、集中することよりも簡単である。

集中の不思議

　私は普段、魔法の薬などを信じないが、集中が生産性向上に効く魔法の薬だということは認める。集中が買えるなら、クレジットカードの上限を使い切ってもかまわない。投資の元が取れることは、ほとんど保証されたも同然だとわかっている。集中はそれくらい大切だ。

　問題は、集中を欠くと、仕事が終わるまで非常に時間がかかってしまうことである。私たちの集中を破る（あるいは集中に達するのを邪魔する）誘惑は、実際にそれのためにかかった時間よりも、多くのコストを奪っていく。複数の仕事を並行して行うマルチタスキングを取り上げる第41章で詳しく説明するように、私たちが行う仕事の多くには、コンテキストスイッチのコストがかかる。ある仕事から別の仕事に移るときには、失った土地を奪い返すようなコストをかけなければ、新たな仕事を始めることはできない。

　集中は仕事に立ち向かおうとするときに、繰り返し繰り返し基礎を作らなくても済むようにしてくれる。そういう意味で、集中はきわめて重要だ。集中は、車を高速走行状態にするものだと言えるだろう。車が高速走行を維持するためには、それまでに何度かシフトチェンジをしなければならない。絶えず停止や発車をしなければならないとしたら、全体を通じてはるかに遅いスピードで進まざるを得ないだろう。５速にシフトアップして再び高速走行状態に達するには、かなりの時間がかかる。しかし、１度達してしまえば、ほとんど苦労せずにクルージング走行ができる。

　あなたも、とても一所懸命に働くことができたのに、それほど苦労しなかった経験があるだろう。集中した状態に達するまでには多少の時間がかかるものの、ひとたび集中状態に達してしまえば、短時間のうちに多くの仕事をこなせるのだ（捕まえどころのないバグと追いかけっこをしている場合は別だが）。

集中している時間を増やす

　集中がいかに大切かをこれ以上説明する必要はないだろう。あなたは、どうすれば集中している時間をもっと増やせるのかと考えているのではないだろうか（申し訳ないが、薬で集中を手に入れる方法はまだ私にもわかっていない。もしわかったら、あなたにもきっとお知らせしよ引。実際、集中した状態に持っていく方法を身に付けることはきわめて重要だ。集中状態になれなければ、第４部のここからの章はほとんど役に立たないだろう。私はあなたに世界じゅうに存在する生産性向上策を教えられるが、あなたが座って仕事に集中することができなければ､それらのテクニックはほとんど無力だ。

　集中する方法を実際に試すなら、今が絶好のときだ。今すぐ15～30分ほどかかる仕事を用意できるだろうか。この本には栞を挟んでおいて、すぐにやってみよう。しかし、完全に集中してその仕事に全力を注がなければならない。ほかのことは一切考えずに、仕事に向かおう。そのときに、どんな感しかするだろうか。

　先はども触れたように、集中には独特の勢いがある。集中モードに入りたいのなら、パチンと瞬間的に入るスイッチはないことを認識しよう。瞬間的に集中モードに入れるなら、あなたはちょっとした変人だ。あなたがコンピューターの前に座るやいなや、目をどんより曇らせながら一心不乱にタイピングを始めたら、人々はあなたを怖がるだろう。

　集中モードに入るためには、ひとつの仕事に向かうように頭をコントロールするという、最初の苦痛に耐え抜く必要がある。そして、その仕事があなたにとってとても楽しいものでないなら、最初のうちはかなり苦痛だ。しかし、ここがポイントである。苦痛と不快は一時的なものに過ぎず、それほど長い間続かないことを認識しよう。

　私がこの章を書くために初めて座ったとき、私はメールを見たい、トイレで小用を足したい、コーヒーを飲みたい、という燃えるような欲望を全部同時に感じた。しかし、私はもうコーヒーさえ飲んでいない。私の脳は、私が集中するのを妨げるためにあらゆる攻撃をしかけてきた。私はそれを鎮めて指に無理やりダイビングを始めさせなければならなかった。今の私は、何時間でもタイピングし続けられるようなゾーンに入っている（30分で終わるかもしれないが）。集中モードに入るためのポイントは、無理やり自分をその方向に進ませるということだ。

　私が生産性を上げるために使っているテクニックの大半は、集中モードに入るというこのバックボーンに支えられている。第38章では、あなたを強制的に椅子に座らせ、十分に長い間仕事に打ち込ませて、集中のゾーンに突入する勢いを作る「ポモドーロテクニック」について説明しよう。

話に聞くほど簡単ではない

　私の説明を読んだ読者は、集中モードヘの突入を実際よりも少し簡単に感じてしまったかもしれない。集中モードヘの突入は、キーボードの前に座ってダイビングを始めるだけで済むほど単純なものではない。シフトアップしてクルニジング走行に入るまでは、あなたに降り掛かってくる様々な誘惑と必死で戦わなければならない。誘惑と戦うためには、ちょっとした準備が必要だ。

　仕事を始める前に、あなたの内外からやってくる割り込みから自分を守るためにできることをすべてしておくようにしよう。スマホをサイレントモードに変え、気が散る元になるブラウザーウィンドウを閉じ、ホップアップを無効にし、ドアやキューピクルの入口に仕事中の札を吊るすことまで考えた方がいいかもしれない。札を吊るすという部分は冗談だろうと思われるかもしれないが、私は本気だ。同僚や上司は、最初のうちは少し抵抗するかもしれないが､あなたが一心不乱にコードを書き出したら理解してくれるはずだ。それどころか、彼らもあなたの魔法の薬を買いたいと思うかもしれない。

　これで仕事を始める準備が整った。コンピューターの前に座ってタイピングを始めよう。気が散るものは視野にはない。……ちょっと待て。誰かがあなたのFacebookに「いいね！」をしたかどうかを見なくちゃ。いやいや、こういうことは考えてはいけない。ここで仕事にしがみついていられるかどうかは、自分の意志の力を使えるかどうかにかかっている。最初のうちは強制しなければ集中できないが、いずれ弾みがついて自然に集中できるようになる。目標は、最初の５分か10分を耐えることだ。そこを過ぎれば、ちょっとした誘惑が襲ってきても、あなたの集中は破れないだろう。

極右は全体を表していない

EUという超国家

　EUはグローバリゼーションとして、一律的な内部を求めた。これが答えにはなっては居ない。その中は国家である必要はないけど、それぞれの事情で異なるもの、分化して居るものになっていかないと統合できない。

　統合するメリットがない。全体の国家を作るだけではムリです。超国家は国家よりももっと小さな単位の上に成り立つものです。

　国家という単位は曖昧なものです。フランス人に対して，フランスはあるけど、フランスは多様なものを含んでいる。彼らを満足するためには行き来できるものが前提になる。国家という教会が邪魔になります。小さな単位にしない限り、全体主義になってしまう。

極右は全体を表していない

　国家に対して、政党というカタチで極右が出てくる。個々が小さくても、国でまとまれば大きくなる.そして、ナチのように国を乗っ取ろうとする。

　それぞれは単位の中の悩みであって、その中では小さい。個人的な要望の方が大きい。にもかかわらず、民族という単位でまとまるとお化けになっていく。

　ペテルスブルグの反乱であるものが、ロシア全体の生態が変わる。その結果、ウクライナのように，それぞれのバランスで生きてみたものが崩れる。これがクローバリズムを間違って、使ったやり方です。答えにはなっていません。

　スロヴァキアではないけど、多くの民族を抱えながら，ヨーロッパは生きてきた経験を持っている以上、それぞれが異なる単位として、一番上にEUを置けばいい。国家という縛りは生活に関係ない。

神宮の先にあるもの

　神宮三日間。台風を超えられるか！　その先にあるものは何か。

　松村のバースデー集合写真のなかにキャップテンを発見、出られるんだ！　一ヶ月の体調不良から戻った?　それにしても全員がカッパ姿。やり抜く意志にあふれている。

　集合写真をよく見ると、生駒らしき女性がFOXサインをしている。もしかすると、すぅの姉貴のひめたん？