エンジニアとしての個人的バイブルを語る (ソフトスキル編)

金澤
「私は 2 部の “自分を売り込め !” と 3 部の “学ぶことを学ぼう” のあたりが好きですね。“自分を売り込め !” は自分のやっていることをアウトプットしていこうという話なので、きっと吉田さんも好きですよね ?」

吉田
「好きですねー。」

金澤
「過度にアピールする必要はないと思いますが、普段勉強していることをブログで発信する、整理して登壇する、といったアウトプットの習慣はエンジニアとしてとても重要なことだと思っています。」

吉田
「発信することで自分の学んだことの整理にもなりますし、周りの人からフィードバックが貰えるので更にその分野に詳しくなる、そんな好循環が生まれますよね。」

金澤
「その通りですね。私は忘れっぽいので、数ヶ月後に自分の記事に助けられるいうこともよくあります。それと、アウトプットを継続していると、社内でも “xx やっている人” として見てもらえることないですか ? 結果として自分がやりたい仕事にアサインしてもらえる可能性も高くなるということを前職時代に経験しました。」

吉田
「3 部の “学ぶことを学ぼう” は我々は “教える” を仕事にしている / していたこともあり（※ぜひ前回の記事をご覧ください ）、とても興味深い内容ですよね。」

金澤
「“メンターを探す” とか、逆に “弟子を取る” といった内容は勉強になりました。実際に私は仮想メンターな方に定期的に連絡を取り続けています。同じ 3 部に書いてある “学び方を学ぶ” も好きですね。何かを学ぶときに “独学” できるかはエンジニアとして重要な能力のひとつだと思うのですが、その方法論が言語化されています。エンジニアになりたての方には、特に参考になると思います。吉田さんは『SOFT SKILLS』で他に好き内容はありますか？」

吉田
「私は自分の Productivity をいかに上げるかを常に考えているので、4 部の “生産性を高めよう” の話が好きですね。」

金澤
「意識高いですね。」

吉田
「よく言われます。この 4 部に出てくるポモドーロテクニックの話や、習慣の話、マルチタスクの話は別の本でオススメがあるので、その紹介に移ってもいいですかね ?」

金澤
「ぜひぜひ。」

吉田
「ではまず『ポモドーロテクニック入門』を紹介しましょう。金澤さんポモドーロテクニック知ってます ?」

金澤
「はい ! 私は『SOFT SKILLS』で知ったのですが、普段の仕事でもポモドーロしてますよ。(※ 実際にこの記事もポモドーロテクニックを使って書いています。)」

吉田
「いいですね。ポモドーロテクニックはざっくり言うと、“25 分仕事して、5 分休憩する” を繰り返しながらタスクを進めていくというテクニックです。トマトの形をしたキッチンタイマーを 25 分ひねってタスクを始めるので “ポモドーロ” という名前が付いたそうです。」

金澤
「たしか吉田さんは随分前からポモドーロテクニックを使ってるんですよね？」

吉田
「はい、かれこれ 5 年以上ですかね ! この『ポモドーロテクニック入門』はかなり前 (2010 年) に出版された本なんですが、それ以来ポモドーロテクニックがないと仕事ができない体になっています。」

金澤
「どんな流れでポモドーロを進めてます？」

吉田
「まず朝イチでタスクを洗い出します。なるべく小さな粒度のタスクにして、1 ポモドーロ、つまり 25 分くらいで終わるような細かいタスクにします。私はアナログな人間なので紙にタスクを書いているのですが、終わったときに線を引くのが快感なんですよねー。『ポモドーロテクニック入門』では毎日のポモドーロ数のトラッキングをオススメされているのですが、私はそれはしていませんね。」

金澤
「本をベースに、アレンジされてるということですね。それ以外に何か工夫されてることはありますか ?」

吉田
「はい。私はコンテキストスイッチをあえて起こすようにしてます。つまり、なにか資料を作らないといけないときに、それが 4 ポモドーロ (25 分 x 4 分) のタスクになったとするじゃないですか ? 金澤さんはこのタスクどう進めます ?」

金澤
「私はガッと 2 時間で終わらせにかかりますね。」

吉田
「なるほど。私は逆で、1 ポモ分の資料作成タスクをやったら、次のポモでは違うタスクをやります。調べ物したり、コードを書いたり。その後、再び資料作成タスクに戻ってくる、という進め方です。このやり方だと、“ちょっとやりたくないな” というタスクを後ろ回しにしないで済むんですよ。重めのタスクを 4 ポモ分も連続して取り組むのって大変じゃないですか。」

金澤
「あー、たしかに。予定してたポモドーロ数を回せなかったときに、残るタスクは重いタスクや “緊急じゃないけど重要” なタスクになりがちですね。」

吉田
「そうなんですよ。細切れにタスクを進めることで、後ろ回し症候群を回避できるという狙いで “コンテキストスイッチをあえて起こす” やり方にしています。とは言え、私のやり方を真似する必要はないので、『ポモドーロテクニック入門』をベースにしつつ、業務に合わせて “俺俺ポモドーロ” に微修正していくのがいいかなと。集中力が続かない人、時間はたっぷりあるはずなのに成果がでなくて悩んでいる人、細切れの時間を無駄にしていると感じる人にはポモドーロテクニックはとてもおすすめです。」

金澤
「ありがとうございます。では次は自分が本を紹介しても・・・。」

吉田
「あ ! この流れでもうひとつ紹介したい本が ! いいですよね ?」

金澤
「ぜ、ぜひ。」

吉田
「あ、違うな。ふたつです。ふたつ紹介しますね。『小さな習慣』と『カンバン仕事術』を紹介したいです。まず『小さな習慣』ですが、金澤さん読んだことあります ?」

金澤
「いやーないですね。」

金澤
「なるほど。これなら余裕でこなせそうですね。エンジニアの “小さなタスク” ってどんなイメージですか ?」

吉田
「私がよくやるのは、資料作りのときは “ファイルを作る” だけにするとかですね。もう少し大きくするなら “ファイルを作って表紙だけ作る” とか。コーディングタスクであれば、“メソッドの枠組みだけでも作る” とか “ユニットテストが落ちるようにする” といった形でしょうか。」

金澤
「不確実性が小さく、現実的に達成できそうな粒度ですね。」

吉田
「です。あとは目標を立てるときもコツがあって “毎日○○する” という目標にしてしまうとイレギュラーに対応しづらいと思うので、週次くらいにするのがおすすめです。“毎週ブログを書く” とかだと余裕ですよね ?」

金澤
「(全然余裕じゃない・・・。) 小さいタスクを切る練習にはもってこいな本ということですね ! 読んでみよう。」

吉田
「金澤さんそれ 2 ヶ月前にも言ってましたよ ! “本を買う” とか失敗しようがないタスクに落とし込んでくださいよ !」

金澤
「・・・。」

吉田
「続いて『カンバン仕事術』なんですが、こちらも有名な本ですよね。仕掛り中の作業のことを Work In Progress (以下、WIP) と呼ぶのですが、この WIP を増やしすぎないようにしようという “WIP 制限” の話が特におすすめです。最近エンジニアになられた方にはぜひ読んでもらいたいですね。」

金澤
「マルチタスクな状態になると生産性落ちるよね、という話ですかね。ただ、先ほどの “表紙だけ作る” ってある意味 WIP を増やすことになっちゃってません ?」

吉田
「大きい成果物全体を見るとそうかも知れませんが、僕の中では “タイトルを作る” というタスクは Done なので WIP ではないのかなと。」

金澤
「なるほど。ここでもタスクの粒度の話が効いてくるわけですね。」

吉田
「そうです、私が紹介した 3 つの本は全部絡んでるんです。“WIP 制限” と “ポモドーロのコンテキストスイッチ” の話を組み合わせて、常時 3 つくらいの大きいタスクを持っていて、ポモドーロごとに飽きたら変えていくという進め方をしています。だいたい 1 日に 3 つくらいは大きい粒度のタスクを完了できるかな、という感覚で普段仕事していますね。」

金澤
「私もとても勉強になりました。ありがとうございます。そろそろ私のもうひとつ紹介したい本の話をしてもいいですかね ? 私のオススメしたい本は『仕掛学』という本です。この本は前職時代に後輩に紹介してもらった本なのですが、今でも定期的に読み返してます。」

吉田
「なるほど・・・。おもしろそうな本ですが、“Developer” としてはどういう学びがあるんですか ?」

金澤
「はい、開発者として “ユーザー体験” を考えるきっかけになったと思っています。私は前職の頃にお客さんと一緒に新規事業を作るエンジニアをやっていたのですが、作りたいものを作れば使ってもらえる ! なんてことはないんです。当たり前ですけど。世の中の真の課題を理解して、それを真に解決できるプロダクトになっているかが大事だと思っています。企画をする人だけではなく、エンジニアもその理念を分かっているチームの方が強いと思うんですよね。」

吉田
「たしかにそれはその通りですね。」

金澤
「そういう点でこの “仕掛学” の考え方を知っておくのはよいと思っています。何かものづくりをしたいときに、直接的なアプローチだけでなく、間接的な、と言うと語弊があるかもしれませんが、そういう引き出しを作るのにこの “仕掛学” はオススメです。“作る楽しさ” にプラスして “課題を解決する楽しさ” に繋がればと思って紹介させてもらいました !」

吉田
「・・・熱いですね。」

金澤
「この本のこと話すといつも熱くなっちゃう。おすすめの本ですね。」

吉田
「読んでみようかな。」

金澤
「まずは買うところからですよ。時間が迫ってきましたので、そろそろお開きにしましょうか ! 実は他にも本を持ってきたのですが、またいつかということで。吉田さん何か最後に言いたいことありますか ?」

吉田
「本を読んだらちゃんとアウトプットしましょうねー ! さようならー !」

金澤
「(最後まで厳しい・・・。) さようなら !」

というわけで、最後までお付き合いいただきありがとうございました ! “個人的なバイブル” というテーマで、これまでに影響を受けたソフトスキル的な本を紹介させていただきました。

「ポモドーロテクニック」という話が出てきましたが、実は私も 3 年前にトライしたことがありました。ただ、そのときは小さいチームでコミュニケーション (= 割り込み) が頻繁に発生する環境だったこともあり、うまく合わずにやめてしまった過去があります。ただ、現職についてからは、チームのコミュニケーションと個人ワークを分けやすくなったこともあり、最近になってポモドーロテクニックを再開したという経緯があります。

本も同じで、そのときのロールや環境によっては気付きがあったりなかったりするんじゃないかと思います。そういう意味でも、そのときに学んだことを記録したり、ある程度経ったあとに読み返したりすることも大切なのかなと考えています。『SOFT SKILLS』の話にも出ましたし、最後に改めて吉田さんが言っていますが、“学んだことをアウトプットする” ことはとても重要です。読んだら読みっぱなしではなく、“何を学んだか” や “Next Action として何をやるか” だけでも書き留めておくとよいのではないでしょうか。（と言いながら私も読みっぱなしの本があるので、アウトプット頑張ります。）

この記事が少しでも “How to be a Developer” な皆様のお役に立てれば幸いです。また別の記事でお会いしましょう ! それでは !

※本記事の対談は 3 月に実施しました