周回遅れで『SOFT SKILLS』を読んだ
今更ながら、少し前に話題になった「SOFT SKILLS」という本を読みました。もはや本を買うまでもないくらいネット上に書評等の記事が出回っていますが、記録のために書き残しておきます。
著者
John Z. Sonmezという方が執筆されています。この本自体が有名なのでググればすぐ出てきますが、33歳でアーリーリタイアするほど成功した人です。.NET系の開発者だったそうで、「SOFT SKILLS」執筆後のインタビュー記事も見つかりました。
「Clean Architecture」などで有名なRobert C. Martinが序文を書いてるところも地味にすごいです。ソフトウェア開発者としてどれくらい優秀なのかは（少なくともこの本には書いていないので）わかりませんが、まさしく自分や自分の環境をハックするためのSOFT SKILLの鬼といったところでしょうか。
本の概要
この本に書かれていることは非常に多岐に渡ります。一言で言えば「自己啓発の欲張りセット」みたいな内容です。ソフトウェア開発者に向けて書いている部分もありますが、基本的にはすべての人に適応できる内容だと思います。この本を読んだ上で、特に気になる部分の関連書籍を読んで理解を深めるのも良いと思います。
ざっくりと書くと、全体的に以下のような構成となっています。
- 第一部 キャリアを築こう
第二部 自分を売り込め！
第三部 学ぶことを学ぼう
- 優秀な開発者になるためには、独学の方法を学ぶことが必須である
- 好奇心に従い、能動的に行動を起こしたとき（本書では"遊ぶとき"と表現）に最もよく学べ、他人に教えると理解が深まる
- 学習する前にトピックのスコープを定め、成功の基準を明確にしておく
- メンターを探す、または自分がメンターになると、自分の知識や理解の穴を見つけやすい
- 第四部 生産性を高めよう
- 集中状態に至るためには最初の5~10分を耐える
- 四半期、月次、週次、日次の計画を立てる
- ルーチン化することで、自分に責任を取らせるような内発的モチベーションを保ち、時間の浪費を防ぐ
- 燃え尽き症候群に陥らないために、達成後に何があるかを常に意識する
- 行動しなかった時に何が起こるかを考えながら、まず行動を起こす習慣をつける
- 第五部 お金に強くなろう
- 自分の資産がどれほどあり、負債への浪費にどれほど使っているかを把握するのが第一歩
- 月々の出費を減らすことは、資産と負債の両面で効果的
- 第六部 やっぱり、体が大事
- 健康であることは単に寿命が長くなるというだけでなく、自身から成功を呼び込むことにつながる
- 明確な目標を持ってとにかくやれ
- モチベーション維持のための策をできるだけ講じる
- 第七部 負けない心を鍛えよう
- （非論理的であることは認めた上で）思考が現実に影響を与え、未来を変えることが多々ある
- 状況はあくまで事実であり、捉え方次第でプラス思考になれる
- 理想的な心理状態を思い出せる言葉やイメージを見つけ、一日の中で信じ続けることで思考を変える
- 失敗を恐れず、成功したければ確実に失敗することが保証されているような状況に身を置く
要点
内容が多すぎるので、自分が参考になった部分のみ取り上げます。
アウトプットの重要性
本書ではしきりにブログや講演等によるアウトプットを推してきますが、主に以下の利点が挙げられています。
- 自己ブランディングになる。同じ能力でアウトプットしていない人と比較すると、選ばれるチャンスが増える。
- 学習のための深い理解につながる。知識を構造化して他人に伝えることで、自分の理解不足やさらなる問いが見つかる。
- 資産になる。ブログや教材などが軌道に乗ればアフィリエイトによる受動収入源になりえる。
三つ目に関してはそれなりのクオリティを求められそうですが、基本的にメリットしかありません。アウトプットの中でもブログは最も手軽に始められる手段なので、ソフトウェア開発者なら全員やっておくべきといっても過言ではないのでしょう。「100人に自分のブログを持っているかを聞いたときに、継続して更新しているのは5,6人しかいない」と述べていたので、やるだけで既に上位10%に入れるわけです。（アウトプットしていない人の中にも優秀な人はいるはずですが、アウトプットしておけばより評価される機会が増えることは間違い無いでしょう）
成功基準を設けて学習する
何かを学習する手順として、本書では10ステップに分けた学習法を提案しています。その中でも最初の3ステップで
- 学習対象の全体像を掴む
- 学習するスコープを決める
- 成功の基準を決める
ということをしています。多くの場合、その分野全体を理解するのは現実的に不可能であるため、「Linuxについて詳しくなる」のような曖昧な目標ではなく「Linuxのインストールとセットアップができ、コマンドを使用して特定の開発環境を構築できる」のように基準を明確に定義しておきます。これは成功体験が得られるだけでなく、目的と異なる周辺知識についてだらだら調査するような時間を削減できます（自分もよくやりがち）。
生産性向上のためのポモドーロテクニック
第四部の中で挙げられたテクニックです。これ自体は有名であり、他の書籍でもよく紹介されています。
25分集中して作業＋5分休憩 という1セット（1ポモドーロと呼ぶ）でタスクを消化していくという単純なものですが、本書では特に「作業量の見積もり・トラッキング」で使用すると効果的であると述べています。
- あるタスクの作業をポモドーロテクニックで実施する
- 1日に何ポモドーロ実行できたかを計測する
- これを参考に1週間のタスクをポモドーロ単位で分割して見積もり、実行していく
これにより「仕事の進捗を実感し、十分仕事ができていないように感じることがなくなる」そうです。
実践
既に本の内容が実践レベルで書いてあるので蛇足感はありますが、これだけはやっていきたいところ。
継続的なアウトプット
これに関してはもはや言及するまでもないですが、継続するのは大変です。せっかくアウトプットしても半年に1回とかだと効果が薄そうですね…
せめて1週間に1回、月に4回程度は何らかのアウトプットが出せるようにしてみます。ブログだとよくネタに困る時があるので、
- ネタにできそうなことを見つけたら逐一メモする
- メモした内容について、ネット記事や書籍で知識を得る（可能であれば実践する）
- 土日で記事を書く
というサイクルで実践していきたいです。継続に関しては「最初の10分を耐え切る」という心がけで習慣化していこうと思います。
ポモドーロ基準での見積もり
何らかのタスクの工数を見積もる時、今までは「類似タスクにどれくらい時間がかかったか」を参考にしていましたが、
- いつも複数タスクを抱えているため、単一タスクの工数実績が記録にない
- 類似と言っても全く同じことをするわけではないので、参考にならないことも多い
と言った理由で、見積もりから外れることがありました。そこでポモドーロを導入し、「タスクにかかる時間ではなく、単位時間（1ポモドーロ）で進められる作業量を把握し、タスクの大きさから逆算する」ことを実践しようと思います。
会社で働く以上は何らかの割り込みが発生しやすい（特に不具合調査とか）ため、本来のポモドーロテクニックがどれほど生かせるかは不明ですが、少しでも見積もり精度が上げたいので。
まとめ
当たり前ですが、こう言った自己啓発関連の助言は銀の弾丸にはなりえません。著者も様々な誘惑に耐えて今に至るそうなので、完璧な人間はいないしすぐに成果が出せる方法はないのでしょう。何事も気長に、楽しみながら継続してやるのが一番なのかもしれません。
昔は「自己啓発書は少しの間しかやる気がもたない、だからあまり読まない」と個人的に思っていましたが、逆に言えば「継続して読んでいれば半永久的にやる気を出せる」ような気がするので、また暇なときに読み返してみます。
