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

2020-05-11
How to be a Developer

Author : 金澤 圭 (話者 : 吉田 慶章) 

テクニカルソリューションアーキテクトの金澤 (@ketancho) です。5 月になりましたね。春からエンジニアになりました ! という方は少しずつ日々の業務にも慣れてきた頃でしょうか。エンジン全開で走ってきた方の中にはいわゆる「5 月病」に陥ってしまう方もいるかもしれません。

私も過去に何度もこの時期に息切れしてしまっていたのですが、この記事を書いていてその解決策になりそうなアイデアを見つけました。それは “学びをゼロにしない” ことです。今まで 100 頑張ってきたのに 0 になってしまった方は、「それを 1 にするだけでいいや」くらいの気持ちでやるのがいいのかなと思いました。毎日 “1” を積み上げるのがよさそうだと私が思った理由については、ぜひこの後の本編でご確認ください。

さて、先日 “エンジニアとしての個人的バイブルを語る (技術書編)” という記事を builders.flash に寄稿しました。多くの方に読んでいただけたようで、大変ありがたい限りです。「私は○○ !」「僕は xx ですねー !」というフィードバックも多く頂戴でき、私にとっても学びが多い記事になりました。

この記事ではその続きとして「ソフトスキル編」を書いていきます。ここでの「ソフトスキル」は、IT エンジニアとしてのハードスキル(例:Java が書ける、DNS の仕組みが分かるなど) *以外* を指します。技術書以外の本でエンジニアとしての学びに繋がったものであれば何でも OK という形で、血となり肉となった個人的なバイブルを紹介していきます。前回に続いて、テクニカルトレーナーの吉田さんを招き、対談形式で記事を進めていきたいと思います。それではお楽しみください !

金澤
「というわけで、前回の続きをやっていきましょう ! 今回はソフトスキル的な本という縛りでやっていきたいと思います。」

吉田
「よろしくお願いします ! 紙袋いっぱいになるくらい持ってきましたよ ! (付箋がビッシリ付いている本をたくさん出しながら)」

金澤
「(また私が喋る時間がなくなりそうだから先に喋ろう。) このテーマですし、『SOFT SKILLS』から話し始めましょうか !」

吉田
「名著ですよね。私も大好きな本です。金澤さんはどのあたりが好きですか ?」

img_mytech_bible_202005_01

お互い好きな『SOFT SKILLS』の目次を眺める金澤と吉田。この本は全 7 部、71 章からなる本です。

金澤
「私は 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 ポモ分も連続して取り組むのって大変じゃないですか。」

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

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

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

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

金澤
「ぜ、ぜひ。」

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

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

吉田
「え ? 前に紹介したじゃないですか ! あんなにオススメしたのに・・・。ポモドーロテクニックの話の中で “なるべく小さな粒度” のタスクを作るという話をしましたが、これって結構難しいスキルだと思うんです。特にこの “How to be a Developer” カテゴリを読んでいただいている方は、最近エンジニアになられた方も多いと思うので。」

金澤
「たしかに難しいですよね。」

吉田
「そんなときにこの『小さな習慣』が参考になるかなと思って持ってきました。失敗しようがない、失敗する方が難しいぐらいの粒度でタスクを作るのがいいよ、という本です。人間の心理として、スタートを切るのが一番難しいので、まずその一歩を踏み出しやすい形にできます。例えば “運動する” ではなく、“運動できる格好に着替える” とか “腕立て伏せを 1 回やる” とか。このタスクであれば失敗しようがないじゃないですか。」

img_my-bible-softskill_02

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

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

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

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

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

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

金澤
「・・・。」

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

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

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

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

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

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

吉田
「金澤さん、ことあるごとに “仕掛学が〜” と言ってますよね。」

金澤
「そうですね (笑) とても気に入ってる本のひとつです。内容としては、相手に “xx してほしい” という希望があったときに直接的に相手にそれを伝えるのではなく、相手がついしたくなるような “仕掛け” を考えよう、という本です。例えば “本棚に漫画本を順番通りに並べてほしい” という希望があったとするじゃないですか ? カックさんだったらお子さんになんて言います ?」

吉田
「ちゃんとして ! でよくないですか ?」

金澤
「まぁそうなんですけど・・・。直接それを言わないでやるのが “仕掛学” なんです。この本では “漫画本をちゃんと順番に並べると背表紙が絵になる” という仕掛けを作っておくことで、相手は知らず知らずのうちに順番に並べてしまう、といった例が紹介されています。仕掛けた方と仕掛けられた方のモチベーションが違うのが特徴ですね。」

img_my-bible-softskill_03

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

photo_kanazawa_kei

話者および筆者について

金澤 圭 (@ketancho)
アマゾン ウェブ サービス ジャパン株式会社
技術統括本部 ソリューションアーキテクト

サーバーレスが好きなテクニカルソリューションアーキテクト。業種業界問わず、お客様のプロダクト開発をサポートさせていただいています。「AWS Hands-on for Beginners」というオンデマンドで視聴できるハンズオンも企画・推進しており、楽しく学べるコンテンツを日々考えています。好きなサービスは AWS Lambda と AWS Amplify で、好きな休日の過ごし方は娘ふたりと川の字になって昼寝です👧👧

photo_yoshida_yoshiaki

話者について

吉田 慶章
アマゾン ウェブ サービス ジャパン株式会社
トレーニングサービス本部 テクニカルトレーナー

ウェブエンジニア/プログラミング講師などの経験から AWS テクニカルトレーナーに。教えることを本職とし、効果的な学習メソッドを考え続けている。教えることは最高の学習である。Keep on Learning 👍

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
フィルタ
フィルタ
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する