2019/7/20に開催された、まつもとゆきひろさん(以下、Matzさんと記述)の講演会に参加しました。
Matzさん、貴重なお時間を頂き誠にありがとうございました。
そこで「できない/やらない理由は簡単に思いつくから、とりあえずアウトプットすると良い」という旨のお話があったので、内容をまとめて書いてみました。
私の場合はドキュメント作成業務が多く降ってくるため、人の目に晒す練習です。
初投稿なこともあり、拙さが目立つかとは思いますがご容赦ください。
ご指摘は甘んじて頂きます。
なお、イベント元のページはこちらをクリックしてください。
講演の概要
１．サブタイトル
「生涯エンジニア」を目指すキミに贈る”技術”と”キャリア”の向かい方
２．使用されたプレゼンツール
Rabbit…プログラマ（主にRubyist）向けのプレゼンテーションツール。
３．講演の進行 講演80分、質疑応答40分
１．若手層が抱える悩み（現状把握と課題共有を意図？）
２．人生の裏技（課題へのアプローチ）
３．生存戦術（１～３の総括も含む）
４．質疑応答
講演の詳細
概要の「３．講演の進行」をそれぞれ掘り下げていきます。
具体例は、Matzさんが挙げられたものを用いています。
上記の題目は今回まとめるにあたって、「この辺りが話の転換」と感じた部分で区切って恣意的に付けた部分があります。ご容赦ください。
１．若手層が抱える悩み
・悩み＝「思い通りに動けない」事へのストレス
・Matzさんが好きでない言葉：「若者の柔軟な発想」
◦若いことと柔軟な発想ができる事に本来、因果関係はない。
◦「柔軟な発想」を会得するには訓練が必要だが、学校教育ではその機会が提供され難い。
◦学校教育の試験で測定される事柄は、記憶力、計算力、効率性など。高評価のために「苦手を補う」アプローチが必要になる。
⇒時間や道具に制約がある点も含め、柔軟な発想を伸ばすとは考え難い。
・社会人になって学校から大きく変わるルール
◦知識を暗記せずとも、その場で調べ試行錯誤するアプローチも可能になる。
◦一芸に特化して「得意を伸ばす」方が高く評価される。
・ポイントは、「ルールが変わった」事を誰からも教えられない点。
◦上司たちもルールの変化に気付いていない可能性があるため。
◦学校のルール下での経験が長い分だけ、「慣性」が大きく簡単に治らない。
◦若手にしわ寄せが来るため、「思い通りに動けない」。
☆対策１：自分がプレイしているゲームのルールを知る・考えることの必要性。
☆対策２：ポジティブ思考。ピンチはチャンス。
◦変化を知っていることが武器になる。
◦皆はやらないが、別にやっても問題のない「裏技」を使えばいい。
２．人生の裏技
裏技① ルールの変化を認識して行動する。
・学生時代と社会人とで高評価を得るためのアプローチは変わった。
◦苦手を補って総合力で戦う ⇒ 得意を伸ばして一芸に特化する
◦一芸があれば、苦手な部分はそこは他が補完してくれる
◦自分の得意な事項を見つけて伸ばそう
◦伸ばすカギはモチベーション。各々が固有に持つので、自分で探そう。
裏技② 「Win-win関係を理解する」
・仕事のモチベーションを高める方法
・書籍『7つの習慣』より。持続可能な取引は、Win-WinとNo-Dealの2種類。
・No-Deal：片方でもLoseが発生するなら取引しないこと。
◦不景気で「失敗すると死ぬ」(失敗はコントロール不可能)価値観が広まった。
⇒「絶対に外さない」選択肢を取るが、面白くない/当たりではない。
・取引しない ＝「逃げてもいい」という発想を持とう。
◦「石の上にも3年」というが、20代の3年は長い。
・IT業界：勉強/スキルを伸ばす一定の努力をすれば死にはしない。
裏技③ パターン認識能力
・先人のロールモデルを鵜呑みにしない。
◦ビジネス書や成功談は面白いが、同じ行動をしても、再現性はない。
◦無意識の美化やバタフライエフェクトを起こした出来事は再現しえない。
・成功者の得意なことに共通点はあるのか？
◦共通しなかった事：学校の成績、国籍、IQ…
◦共通した事：パターン認識能力(＝抽象化する能力)が高い
⇒個々の戦略は、背景の違いが大きくて演繹できない。
⇒抽象化してメタ戦略、メタ思考で自分に当てはめる。
・具体的なメソッドほど寿命は短い。抽象化すると息は長くなる。
◦アプリ解説書 vs アルゴリズム教科書
◦アプリ vs 言語 vs OS
・とはいえ抽象化にもデメリットは存在する
◦抽象化の結果、現実にそぐわない状態になるケースも。
⇒具体例：アーキテクチャ宇宙飛行士 ※リンク先は英語の記事です。
◦例外的事象によって抽象化に「漏れ」があるリスク
・パターン認識のイメージ：ことわざ(故事成語)。
◦鶏口牛後(小さいグループの頭か大きいグループの末端か)
・差別化戦略
◦「大きいグループ」に所属する価値(Matzさんの体験)
⇒最初に就職した企業は同期200人でIT初心者の人が多かった。
⇒大学時代の専攻(プログラミング)を基に、面白い仕事を任せてもらえた
◦「小さいグループ」に所属するという戦略
⇒「人間として扱われる」可能性は相対的に上がる。
⇒経験則としては小さいグループだと有利な事が多い。
◦差別化戦略、メタ戦略の難しさ：「なにで差別化するか？」
⇒昔とは異なり、流れに乗って「普通の生活」を送り難い。
⇒自分の差別化できるポイントは自分で探す。これが具象化の難しさ。
⇒気付いてどう動くか、戦術まで考える必要が大いにある。
裏技④ 我慢の「価値」を意識する。
・我慢は過程であって目的ではない。
・報酬は価値の対価である。
◦理不尽な我慢の対価ではない。過程ではなく結果という合理性を。
◦「みんながやっているから」のような不合理な我慢は無駄。
⇒「無意識」に行っていることの怖さ。
◦理不尽は拒否して他の人のために理不尽を飛ばさない。断ち切る。
・(理不尽or無意味な)我慢の行き着く先
◦慣れると鈍感になる。集中→麻痺→感染のプロセス。
⇒「デキる」人に仕事が集中する
⇒仕事は残業するものだ、と(当事者の)感覚が麻痺する
⇒自分も残業しておくか、と周囲に感染する
・鈍感になると発生する恒常性バイアス。
◦大丈夫じゃない状況を「大丈夫」だと判断してしまう。
⇒東日本大震災、ブラック企業の働き方…。
・自分の限界を超える前に我慢をやめよう。
◦限界＝致死量は、感覚が麻痺しても変わらない。「ダメ、絶対」
◦致命的なダメージを受けた後の復帰に大きなコストがかかる。
・意味のある我慢(目的のために〇〇を控え△△に時間を使う、など)との区別。
・Don’t work hard, work SMART.
◦世の中、カジュアルな我慢にあふれている。
・人間の本能＝脳内プログラム。
◦自他の思い込み(≒キャッシュ)に振り回されない。
◦インバリデーションのないキャッシュを自覚的に捨てる。
・自分の「得意」なことを棚卸して考える。
・プログラマの仕事の多くは問題解決 ＝ プロセス改善。
☆対策１：社会的圧力/同調圧力を自覚して、理不尽に声を上げる。
◦理不尽と感じた事項の理由を聞いて、答えが来なかったらアウト。
☆対策２：相互リスペクトできる関係を構築する。
◦Win-Winの関係を目指す。
☆対策３：思い込みのキャッシュを、必要に応じて捨てる。
３．生存戦術
・戦略は抽象的な部分を司る。
・戦術は具体的/局所的な部分を司るので、実行させやすい。
戦術① 円滑なコミュニケーション
・特に笑顔がポイント。
◦同じ人を見ていても、表情で印象が変わる。
戦術② コントロール意識
・コントロール意識が生産性を高める。
◦「自分が何かを制御している」と感じるとモチベーションは上がる。
・自分で出来ないことを強制されると生産性は落ちる。
◦特に、叱られると生産性が60%低下するというデータも。
戦術③ モチベーションを上げる
・無くすことは簡単だが、上げることは難しい。
・モチベーションは自分で上げるもの。
◦他人の力では上げられない。
◦プログラミングのモチベーションの1つは「万能感」。
⇒コンピュータに奴隷として仕えない。コンピュータを道具として使う。
⇒アルファシンドローム
・自分の人生の主人公に名実ともになろう。
戦術④ インプットとアウトプット
・インプットは必要なので、勉強はする。
◦ブログを読む、勉強会に行く…
◦新しい技術はどんどん出てくる。
・しかし、インプットは誰でも行うので差別化戦略に至らない。
・アウトプットするかが差別化のポイント。
◦心理的障壁(羞恥心)というハードルは高いが…
◦ユーチューバーの企画など、「あんなの誰でもできる」と思っても皆やらない。
・皆がやらない事を進んでやるから、差別化が戦略として成立する。
・クオリティはとりあえず棚上げ。何かやろう。
◦知識をまとめる、ブログを書く、オープンソースでコードを上げる…。
☆戦術の総括１：人間の可塑性(変化する能力)に賭ける。
◦続けていけば楽になるから、最初の一歩を踏み出す。
☆戦術の総括２：日々を生きよう。
◦生き残るためには… Keep Moving Forward.(前へ進み続けよ)
４．質疑応答
個人的に面白かったので、メモが取れた範囲ですべての質問を載せています。
私が投げた質問も(恥ずかしいですが)載せてあります。
20代エンジニアの目標設定方法、Matzさんの目標
・自分の好きなことをやっていた。
・あえて長期的目標を積まず、目の前のタスクを重ねていく感覚。
・理想的な状況を手に入れたので、それを日々継続させる。
・仕事としてはRubyに機能を実装し続ける。
老後にしたいこと
・60歳になったら一度リタイアしてボランティアでも。
・ボランティア後に戻った後はさすがに未定。
・Rubyのアレコレはコミュニティに任せる事を検討中。
プログラミングをしていて楽しいと感じる瞬間
・「やってもできない」という挫折を忘れて感じられる万能感。
◦人によっては「オレってばすげー感」と呼んでいる。
・講演の中でも軽く触れていた内容。
20代のうちに読むと良い本は？
・多読した方がよい。雑多な知識も大事だし、それぞれに学ぶことがある。
・ネット上の文章は書き殴った感があるので、出版物の方が言葉が推敲された良さがある。
最近読んだ書籍や論文で面白かったものは？
・最近、数式が増えて書籍や論文あまり読んでいないかも
・ブログやTwitterを読んでいる。
・オンラインのコンテンツなら、Hacker Newsとredditをチェックする。
・TwitterのアカウントならMatzさんのアカウントをフォローすると色々と見られるらしい。
エンジニアとして習慣化させるべきこと
・「集中力は連続的に維持できない」という認識をもった行動の習慣化
・ポモドーロを取り入れる。ひらめきを得るためにわざと別のことを行う。
◦バグに悩んだ時は、思い切って仕事をやめてガラッと別のことをやる。
◦ただし、スマホはアイデアを思いつく上では割と強敵。
・文字を読んだり音を聞いたりせず、何も考えない状態を作る。
Rubyの推せるポイントは？
・Webアプリのバックエンド開発言語としての安定性。
・ハイプサイクルでいうと、幻滅期を過ぎて安定期に入った感覚。
・Web外だと、例えばAIやシステムアドミニストレーションならGoやPythonが優位。
◦技術的に対応する仕様にはしますが、使うかはユーザーに委ねる。
抽象化能力の上げ方
・アーキテクトを考える。プログラミングを通じて割と鍛えられる部分がある。
・世の中を仕組みを考える。
・プログラミングの説明時に「例えば〇〇」と具体例を考える。
Matzさん流の英語勉強法
・英語の勉強自体は嫌い。
・とはいえ、海外講演やカンファレンス後に質問されて実際に使う機会を積み重ねて覚えた。
・ミスを考慮せずにとりあえず構成して話して場数を踏んではどうか。
アウトプットへの心理的障壁をどう下げる？
・アウトプットするか考えない。とにかくやってしまう。
◦考え出すと、「できない/やらない理由」が簡単に思いついてブレーキになる。
・間違いを指摘されても「ありがとうございます」と対応。
◦否定されたのはアウトプットであって自分の人格ではない、という点を忘れずに。
エンジニアにとって重要かつ定量的に測れる指標は？
・個人的感覚として、定量的な目標は、言うほど役立たない。
◦定量的な数字の達成が目的にすり替わるリスクがあるため。
⇒10000歩歩くことを目標にしたら、小刻みに歩いてしまうなど。
・定量的な目標を通して達成したい目的を見失わない。
・達成して意味があるものを設定すべき。
◦毎日コードを触るなど。
◦達成基準は考えておいた方がベター。
様々な物を設計する時に類似点などを見出したりしているか
・相手がやりたいことを直感的に達成できるようなデザインの重要性。
◦言語は人間の思想を伝える手段であり、直接的にそれを伝えられるデザインを組めると「よい言語」といわれる。
◦アプリケーションはユーザーとのインタラクションだが、これもある種の言語。そのデザインが良ければ評価を得る結果になるし、面白い。
・アプリ、プラットフォーム、プログラミング言語いずれも一つ上のレイヤーに対する「言語」。
エンジニアとして、他人と円滑な関係を築くための戦術
・相手の言葉を寛容にうけとめること。
◦過剰に反応しない・怒らない、笑顔で。
◦怒っている人、地雷が埋まっている人とは話したくない人が多い。
・人間は物語が大好きなので、何かについてストーリーを語れるように。
◦成功体験を話したくなるが、人を引き付けるベターな題材は失敗談。
なぜ言語を作ろうとしたのか？
・ポケコンBasicからスタートし、「マシ」なプログラミング言語の存在を知る。
・他の開発者がコンピュータとのコミュニケーションをデザインしたくて作っていることに気付いて、自分もデザインしたいと思ったのが高校生。
・大学でCS(コンピュータサイエンス)を学んで知識を得てから作ったのがRuby。
デザイン時に実装したいと考えていたことは？
・こんな形でやりたいことを書いて実行できればいいな、というのが骨子。
空気を読まなくてよかったと思った経験は？
１．会社の窓際族だった時に言語開発を始めたこと
２．スーツ着用という暗黙のルール(＝明文化されていない)を、社内の大掃除を契機にジーンズに変えたこと。
趣味でプログラミングをする人/しないで仕事を楽しめる割合は変わるのか？
・仕事も趣味も、という人の割合が他業種より多いとは思う。
・ただ、別にそうである必要はなくて別に収入が動機だっていい。
・とりあえずモチベーションが維持できるレベルで楽しめることは必要かもしれない。
◦嫌いだと流石につらいとは思うし、得られるスキルに差が生じうることは承知していれば。
・全員がスーパースキルを持つ必要は無いし勉強をすべきだとも思わない。
エンジニアのキャリアにおいてCSの修士や博士を取る意味は？
・Matzさんの就職時はなかった。
・日本企業だと学位を評価するかしないかは分かれる。
◦普通のソフトウェア開発企業だと、差別化といえるほどの差が出るかは怪しい。
・海外の企業やGAFAでのキャリアを考えたいならば博士号が必要な場合は十分にある。
◦CSの博士号くらいないとソフトウェア開発を任せられない、と考えている人が多い国もある(アメリカなど)。
最後のメッセージ
・自分の人生を自分で決める
・自分にとってプラスになる選択肢を探そう。
・自分が幸せになって周りも幸せにしよう。
講演の所感
・Matzさんをここまで間近に拝見できた機会が貴重。圧倒的感謝。
・成果を出されている方の話を聞くと、こちらのモチベーションも容易に変わる。
・質問を当てて頂けたのに口下手な自身が歯がゆかった。
・とりあえず行動した結果がこの長文…。要点を整理する力に課題が見えたので、アウトプットはやっぱりした方が良い。
・日々これ学習なり。