00:06
はい、9月12日、月曜日ですね。 時刻は朝9時を回りました。
はい、今日からまた月曜日ですね。 頑張っていきましょう。
keethこそくわからぬです。
では本日も朝活を始めていきたいと思います。
で、本日はですが、何を読むかなんて、 ちょっといろいろ記事を探ってたんですけど、
ちょっと全然抽象的というか、 全然技術の話ではないんですけども、
前からずっと、これはマストリーズだなって 思ってたものの一つですね、
を読んでみたくなったので、
その記事を読んでいきたいと思います。 バンク氏ですね、
バンク氏王さんのM3で学んだことを言語化する っていうところの記事を読んでいこうと思います。
はい、では、タスクを書いていきましょう。
前職M3時代の同僚であり、上司でもあった 現33VPOEの西場さんと最近イベントに登壇したと。
最近というよりもこのイベント自体は、 2月8日なのでだいぶ前ですけどね。
イベント内のディスカッションで、 実は現職のキャディでやっている内容のほとんどが
M3で学んだいくつかのトピックなんだよな と思うところがあって、
その4つのトピックに絞って、 言語化しておこうと思うということでした。
はい、では行きましょう。
共通言語としてビジネス書を読む。
私自身、33、ヤフーの頃はビジネス書は 技術に関連していたり、
プロジェクトマネジメントやヒューマンマネジメントに 関するものでない限り読まなかったと。
そもそもビジネス書の大半は、 エンジニアにとって読みにくいものである。
技術書のように一定の定まった、 決まったフォーマットがなく、
経験則で確実な再現性がなく、
大会系のストーリーが背景にあった場合も多い。
文献引用もなく、出てくる数値やデータは 信頼しても良いものかすらわからない。
実際、誤訳や妄想も多く、
嘘統計や嘘グラフなど、 苦笑するしかない書籍もある。
実際に私が尊敬する業界トップレベルの ソフトウェアエンジニアの中にも、
ビジネス書は苦手であるという人は多い。
なので、ソフトウェアエンジニアとして生きていく上で 必須ではないだろうというところだけ前提においておくと。
はい。
一方、M3では、この西場さんという人が ビジネス書を大量に読んでいた。
へぇー。
イベント内でも言ったのが、
一時期彼と毎日ワンオンして スパルタ教育してもらっていた時期があった。
そりゃすげえ羨ましいですね。
はい。
で、最初の数週間は視点が合わないことが多かった。
今になって思えば、
プロダクトや人、チーム、技術に関する 共通言語はなかったんだろうなぁという風に思ってますと。
どうしても噛み合わない西場さんを理解すべく、 彼からお勧めされたビジネス書を数冊読んだのが、
私の最初のビジネス書への入り口だった。
特に採用基準を読んだ前後では見方が変わった。
チキリン氏の書籍で、 キャディでも適切そうな人にはお勧めしていると。
うーん。
ちょっとまだ読んだことないですね、採用基準。 ちょっと僕読んでみようと思いました。
はい。で、ビジネスパーソンが持つべきリーダーシップとは何とあるか。
それが自分にとってどう巡り巡って得になるか なのが書いてある両章である。
余談だがチキリン氏にはなぜかツイッターでブロックされている。
言及したことないし、夫婦でボイシーとかも良いと思っているんだがどうして…って書いてます。
03:01
面白いですね。
この本を読んだ後、西場さんとのコミュニケーションは驚くほどスムーズになった。
表現するならお互いハンター×ハンターを読み込んでおり、
日常会話でハンター×ハンターネタを言い合える学生時代の友人のような感覚だ。
まあ分かりやすいですね。いわゆる共通言語できたなということですね。
西場さんの発言。
特にビジネスパーソンに対する言及というのは、 実はこの書籍に書いてあったことをフラッシュアップし、
目の前の物事と対比して自分の中に落とし込み、行動に移したものだったと。
なるほどですね。
この抽象度の高い何かは、その場でゼロから互いに形成していくよりも、
ハンター×ハンターを一回読んでくれ、と言った方が圧倒的に早い。
ハンター×ハンターを読んでいない人に、それを俺じゃなきゃ見逃しちゃうね、
と言えるようになるまでの時間を考えると当然である。
まあまあ、そうね。
そのネタを知らない人は、うーん…っていう感じですね。
それはわかります。
そして多くの強いビジネスパーソンというのは、これらを習慣化していることもわかった。
CEOもVPOEもプロダクトマネージャーもビジネス書を前提の共通言語として話しているし、
それらを読んでいるだけで経営層やプロダクトマネージャーが使う言葉をより俯瞰でトライできることができる。
これは僕が足りなかったことかもしれないですね。
僕がこの2年半、役員をやらせていただいたんですけども、
僕に足りなかったのは確かにビジネス書をたくさん読むということかもしれないです。
なので取締役会とか経営会議とかでも、一応専門用語だったり、
今まで聞いたことのないワードが飛び交っていて、
それを逐一メモって後でググるみたいにやったんですけど、
結果ググってふーんってなっても、なかなか自分に落とし込めていなかったりもしたので、
結局は忘れてしまって、また次回に行って、
ああそれなんだっけ、またググるっていう不毛な時間を過ごしましたね。
一応ノートで俺的取締役言語集とか、
そういう感じのノート記事を書いてたと思うんで、
それ結局毎回毎回見直してましたけどね。
余談でした。
最初はビジネスパーソンは何でこんなビジネス書たる何かを共通言語にしてるんだとも思いましたが、
実体は良いビジネス書のような形で高いレベルで経験を言語化してまとめられる際のある人は少ないということで、
私の中では落ち着いた。
トガス先生でないとハンターハンターという共通言語になるレベルの良作が書けないのと同じだと言ってます。
はい、これは本当そうだと思いますね。
今この言葉は僕に刺さるというか、ぶん殴られてる感じですね。
はい、ちゃんと読みます。
これらは一定の読みにくさや技術書との違いをスルーさえすれば、
共通言語として強い価値を提供してくれる。
そう、ハンターハンターと同じだ。
ハンターハンターという強力で魅力的な共通言語がなければ、
あの学生時代の学友との青春の日々は得られなかったと言っても過言ではないだろうと。
そして、同じ経験を書籍で共有した人たちで組むチームというのが眼鏡であると。
これは会社の中でもそうだし、外の人たちにも言える。
なので、良いビジネスパーソンは良いビジネスパーソンとの共通言語を持つために、
ハンターハンターではなくビジネス書を読んでいるのだと私は捉えていると。
書籍の一番の強みというのは、
06:00
そういう執筆者の方がいろいろ調べたり経験したことというのを言語化して、
その経験値を他の人にも同じ経験をさせずにインストールさせることができるというのがかなり強いですよね、書籍というのは。
だからこそしっかり冒頭でバンクシーさんが述べた通り、
データとか引用とか文献のリンクとかというのがないと信用ならないよねというのはそれだと思いますね。
これが私のソフトウェアと日本語以外のビジネス書の共通言語を持てた瞬間でもあり、
ビジネス書を読めるようになったきっかけでもあります。
もし経営層やプロダクトマネージャーが何言ってるかよくわからないみたいなソフトエンジニアがいたならば、
その人が紹介するビジネス書を一度我慢してでも読んでみるというのをお勧めしている。
より深い効能はさておき、あくまで共通言語としてという入りはビジネス書に対する偏見と敷居を避けてくれると思う。
ちなみにビジネス書が苦手だった。
私がキャリーに入って一番最初にやった仕事は、
CEOがお勧めするビジネス書という社内メモに書いてある本を共有本棚から取って全部読む仕事であると。
はー、なるほどですね。
ただその社内にそういう共有本棚というのがあって、
CEOがお勧めするビジネス書という一覧があるのはすごくありがたいな。
俺も欲しいよ。
ちょっとこの後社内スラックで代表にぶち投げてみようと思います。
本気でぶつかっても大丈夫な人と仕事をする。
イベント内では私は西場さんを本気で叩いても壊れないオモチャと投票した。
面白すぎるな。かつては上司ですよね。
文章ではニュアンスが伝わらないかもしれないが、当然良い意味である。
ソフトスキルは大事というような普遍的なエンジニア成長論でも語られるが、
その中でもソフトスキルの成長論については省かれていることが多い。
いくつかの書籍にはリンクが貼っています。
1冊目がチームギークですね。
グーグルのギークたちはいかにしてチームを作るのか。
2冊目はソフトスキルズ。ソフトウェア開発者の人生マニュアルという書籍ですね。
どっちも超有名な書籍ですね。
僕は全社、チームギークはまだ読んだことないんですけど、TUDに入っています。
もう一個ソフトスキルズ、後社の方ですね。
こっちは現在読み中ですけど、かなり長いんですけど、
1個1個は章立てになっていて何十章と分かれているので、1個1個の章はかなり読みやすいです。
かつサクサク読めるのでこれはおすすめですね。
ソフトスキル全部読み切っていなくて、僕は3分の1しか読んでいないんですけど、
その時点でこれはもう名著だなというのを確信して今もずっと読んでいますね。
もし読んでいない方いたらおすすめします。めちゃめちゃいい書籍です。
はい、やっと戻りまして。
たぶんチームギークが一番言いたいことに近いが、
じゃあどうやってその強いソフトスキルを得るんだという話がありますと。
これらの成長方法について触れられにくい理由として、
私は考えているのはパーソナリティに触れる必要がある点だ。
近年の流れとしても、私個人の考えとしても、他人のパーソナルな部分に踏み込まず仕事をすることは非常に重要で、
むやみやたらに触れていいものではないが、ソフトスキルともコミュニケーション、
素直さ、謙虚などとも呼ばれるビジネスパーソンとしてソフトウェアエンジニアに求められている必要な何かの成長には、
09:02
やはりパーソナルな部分が密接に関係していると。
強くソフトスキルを発揮できるという人は、
パーソナルな部分からビジネス上で起こるすべての物事の捉え方が違っているため、
表面的に取り繕うだけでは、そのスピードには追いつけないと言っていますね。
はー、そりゃそうですよね。
そして、実際パーソナルな部分を晒して、
本当は過去の体験からこう思い、こうしている、私はこの作業や人に得意・苦手意識がある、
こういう物事に高揚感・劣等感を感じるということをぶつけ、
それらをより良い捉え方に変える作業というのは、
非常に熱量と長い対話と努力が話す側にも話される側にも必要になる。
これがもう超ハードだし、できる人がそもそも多くないと。
僕、これ楽しいと思うんだけどな。
その代わり僕は技術に関して熱量がなくなってしまったという弊害はありますけど。
そんなハードな壁打ちに並走してくれる化け物が西場さんという方だったそうですね。
パーソナル部分をぶつけ合っても多く受け止めた上で小さく指摘することもあれば、
さっきの書籍のように適切なものや人に置き換え、より汲み取りやすく変化してくれる。
また短い時間で考える量も多く、自分がぶつけた数日後には複数の回答を用意してくれる。
こういったことができる人と仕事をすると単にソフトスキルが向上するだけでなく、
自分のパーソナリティを汲み取った上でプロダクトチームや技術力向上に必要な物事を揃えてもらえる。
かなり仕事をやりやすかったそうです。
誰にでも出せば良いというものではないが、一時上本気でパーソナル部分を含めてぶつかっても良い人を探し、
そういった人と協業すると自身の仕事や成長が回り始めることを理解できたのは、
西場さんという壁打ちの一番の行動だったと言えます。
と言いつつも、私もソフトスキルについては苦手な方で、
ソフトエンジニアとして取り繕って話す癖が今でも出る時があるが、かなり改善しつつある方だと思う。
苦手だった私でさえも、キャディに入って最初の週にあったCEOにキャディでワンワンすべき人を挙げてもらい、
その全員にワンワンをお願いするなどしているのだ。
その中でアイデアや意見を素直にぶつけ、何人かとは継続してワンワンをしてもらっている。
キャディにも本気でやっても壊れない人が多そうで、むしろ楽しみなくらいだ。
これは素晴らしいですね。
壊れない人という表現はあれですが、
壊れない壁としてぶつかり続けられる人がいるのは正直羨ましいですね。
今後は周囲の人が私に本気でぶつかってきてもいいように、
無垢な子供が純粋な気持ちでこうしたいみたいなのをぶつけても壊れない頑丈なオモチャのように私もなりたいと思う。
続きましてアイデアを100個出す。
これはイベント中にも西場さんがおっしゃっていて、
M3の時に私に貸してきた大きな宿題の一つだそうですが、
イベント内で言われたが、私はこれは難しいと言ってすぐに思考をやめる癖がある。
でもこれは一条専門を収めた人にはありがちな行為だと思っている。
12:00
実際プロダクトの無理難題を一条妥協して開発するのが専門職であるソフトエンジニアであり、
ありえない道を早く損切りして現状で最も良い道を選ぶことは開発者として重要なスキルの一つでもある。
これは本当わかります。すごくわかります。
かといってもビジネスとかいろんなものを加味すると、
パッと切って次に行くみたいなのを良しとしない人たちもいるし、
良しとならない場合もあるので、ここが難しいですよね。
だからこそビジネスは思ったようにいかないからこそ面白かったりチャンスがあったりするんですけども、
とはいえリーダー側とかステッドホルダーからするとちょっとおいおいとなるかもしれないですね。
はい、戻ります。
アイデアを100個出すというのは数が大事なのではなく、
そのありえない道について熟考したかということを問われる宿題である。
これめちゃめちゃいい問いですね。西場さん素晴らしすぎるな。
こういう上司欲しいですね。
まあでも僕は年齢的にそういう上司にならなきゃいけないという、
うーんとちょっと頭を変えますけど。
そうなんですよね。ありえないって切った瞬間、
切ることは別に構わないんですけど、
これエンジニアの人にもちょっと僕をオススメというか、
最近僕の中で考えているというか促したいことの一つとして、
使わないでもちょっと前に話題になったんですけど、
例えばとあるプロジェクトで使う技術、
技術選定を多分最初にすると思うんですけど、
その技術選定をするときに使わないよね、
これを使う代わりに使わなくなったら捨てたっていうの、
技術って絶対あると思うんですよ。
僕はちょっと例えばフロントエンドエンジニアなんですけど、
今回のプロジェクトはとりあえずいつも通り、
まあネクストタイプスクリプトホゲホゲでやりましょうみたいな、
決まったとするじゃないですか。
その代わり使わなくなった、
でもテーブルに本当上げてもいいような技術、
例えばNuxt、今だったら3がもうほぼほぼRC版まで来たので、
使えるでしょうみたいなとかもあるし、
他のフレームワークかもしれないし、
別にVue2、Nuxt2行くんだったらそれでもいいかもしれないし、
ところが今回別にチームの中で、
がっつりGoogleのアンギュラを使ってみたいって人が
いてるかもしれないし、
とか、あと最近モダンでかつやっぱり、
仮想ドームを使わなくてスピーディーに開発できる
スベルトとかがいいんじゃないのみたいな話が、
本当は裏であったかもしれないし、
テーブルに上げたかもしれなくて、
でも結果的にNuxtを選んだけど、
なぜそれを使わなかったかっていう、
選定しなかった理由ですねっていうのも、
それは一つの知見になるんですよね。
その考慮した点とか、
今回のビジネスにはまらなかったポイントみたいなところを
どんどんどんどん社内とかにも、
他チームに展開したりとか蓄積することで、
よりチームとか社内全体の底上げにもなったりするので、
なぜ使わなかったかっていうところの理由づけとか、
そこに関する深掘りっていうのも、
たまにはした方がいいんじゃないかっていう風に
僕は最近思ってるんですよね。
そういう記事がどっかで見た気がしてて、
それをさらに深めたいなと思ってますと。
今読んだこれがその点とかなり似てるなっていうので、
ちょっとその辺出してみたくなりました。
はい、戻りますね。
そのありえないっていう道について熟行したかっていうことを
問われる宿題であると。
これ本当大事なんですよね。
15:02
やらなかった理由って絶対学びがあるはずなんだよね。
なんせ100個出そうとすると、
正当な道に絞って出しても大体の場合数が達成できないと。
これは私が得意としている
素早く良いものを作るという思想とは一見反するように見えるが、
考える時間が多いほど実際は素早く良いものが作れると。
その思考が苦手ですぐ手を動かしてしまう私のような人でも
簡単に思考の時間と広さ、深さを伸ばせるのが
この100個考えるフレームワークである。
フレームワーク is 便利。
まあそうね。
今ではプロダクト作りや開発において
このフレームワークを自分でも実践しながら
PDMにも共生する側になっていると。
この後、いまいさんですかねこれは。
なんだかんだで100個出してきて、
100個全て私が技術的なレビューをして
次はどれをやろうかという話になっていると。
この彼もまた怪物みたいな人だと。
おかげで日々Caddyへの改造度も上がっているということだそうです。
でもいいな、100個考えるわ。
でも確かにそうですね。
いや100個って結構大変なんですよね。
僕も今年の初め、1月に
今年やること100個とか
今叶えたい願望欲望みたいなところ
全て100個出してみようと書き出そうとしているんですけど
毎年その
今年叶えたい100個の欲望みたいなのを書き出しても
5、60個で止まるんですよね。
もうそこからほんと出てこなくて
よくねえな俺って毎回こう思っています。
今も継続的に
1年以内に100個埋めようみたいなことをやっているんですけど
今現時点で確か僕は60ちょっとだった気がするんですよ。
今年も。
いやほんとね年々欲がなくなってきて
これはちょっと有識時代というか
熱量自体が下がっているということがわからないので
もしこういう状況になったとしたら
何か手小売れしなきゃいけないというのを
僕は最近ひいひいしと感じていますので
皆さんどうでしょうかというのがありますけど
はい、余談また、余談ですいません。戻ります。
で、プロダクトと人について考えるという章ですね。次は。
はい、プロダクトについて考えるのは
M3エンジニアリンググループの特徴の一つであります。
開発者の誰もがこれらについて考えており
いつの間にか私もそう思うようになったと。
なんとなくだが
エンジニアもプロダクトについて考えるべき
というべき論ではなく
プロダクトや人について考えていた方が
良いものが作れる場合が多いという話だと理解できたのは
M3にてよかったことに一つですと。
いやーほんとこの記事名言多いな。
プロダクトや人について考えていた方が
良いものが作れる場合が多い。
その良いの定義をどこに置くかというところがすごく重要で
結局その良いっていうのを評価するのもやっぱり人ですし
良いと言うのも人なんですよね。
だからその人に対して良いものを作らなきゃいけない。
その人っていうのはやっぱり複雑系の塊ではありますし
ソフトスキルの塊が人ではあるので
そういう人について考えるっていうのがやっぱり重要ですよね。
それでそれをプロダクトに落とし込むっていうところが
良いプロダクトっていうところになってくると思うので
これほんと大事ですよね。
ことA企業においては開発心で語られる
いわゆる不確実性の多くが
人やプロダクト、ユーザー、時勢に基づいて発生するため
18:02
これらを抑制するには自らハンドリングしていくという
多少不確実性が減るというシンプルなロジックで
それ以上は何もないという理解でエンジニアは十分だと感じると。
エンジニアについてはそうじゃないですかね。
マネージャーとか上の人が他のところを考えれば良いというわけで。
プロダクトをコントロールするには
マネージャーやユーザーと話してデータを見れば良いし
どんな人と働くかをコントロールするには
意見のぶつけ合いや採用に参加すれば良いと。
そしてそのコントロールがソフトウェアエンジニアとして良いものを発見することに繋がる可能性がありますと。
この話が面倒なのは可能性があるだけでない場合もあるところ
実際やらなくても良いことも多いし
分業という考え方もあるでしょうと。
実際やらなくても素晴らしい成果を残すソフトウェアエンジニアはいるにはいるので
その場の誰も課題に感じなければ良いんじゃないかとも思っています。
うーん、まあまあまあ
なんか引っかかる感じはしますけど
言語化できないので飛ばします。
私はこの確率や課題性について考えるのが面倒なので
数を打つことで分母を増やして発生回数を上げるという方法を取っています。
端的には何でもやりますといつも宣言している。
これは強いね。はあ。
プロダクトでは本当に何でも作るし何でも要望を聞いて意見するから
思い出深いトピックはいくつかありますが
私はめちゃくちゃツイッターが好きだが宣言してある決まっていたら
まさか仕事になるとは思わなかった。
ツイッターの仕事は僕も今回なるかもしれないですね。
時間の問題ですけど後ほど発表しますが
自分のキャリアについてまた別途
ツイッターで発表すると思います。
このきっかけにM3を知った素晴らしいメンバーがM3に入り
その人と働き良いプロダクトにできあがるみたいな事象も影響して
全てがプロダクトのためになっているという実感を得られた。
これいい話だな。
とても良い話ですね。
プロダクトについて考えるとはそれらに関連する技術
人、チーム、会社の全てを作り上げるために施策を考えることなどを思い知らされた。
こういったプロダクトや人について考えるということをして
実践する作業は当たらないことも多いですけど
M3に当たって面白いなあくらいの感覚で私はいいと思っています。
開発の片手間としてガチャやる感覚だと面白いと表現して
いろんな人にもお勧めしている。
もちろん仕事でやる以上は一生本気でやりますけどね。
最後ですかね。
今でもM3エンジニアリングがしっかり拡散されているか見に行っていくと
M3エンジニアリングという
M3さんの公式ツイッターアカウントが
発表しているツイートとかをちょいちょい見に行ってしまったりするそうですね。
あとは
キャディテックもいいぞどっちもフォローよろしくねということで
キャディさんの公式のツイッターアカウントの方もあるので
こっちもフォローしてねということでした。
ちなみに私は定量評価オタクを公言して働いており
フォロワー数もリツイート数も数として必ず見ている。
もちろんそれだけじゃないけど見ているぞ見ているからなというところでした。
定量評価はね
人に対する定量評価はほぼほぼ無理だと思うので
定量評価というのが各社評価制度というところが課題になるので
21:02
僕結構カジュアル面談とかもさせていただくときは
必ず評価制度のところと今どういう課題を持っているかというのと
その評価制度に対してどれだけの熱量を持っているかというのを
僕結構聞くようにしてますね。
じゃなきゃ会社として人の成長をどれだけ見ているかというのが
測れないのでそこを結構僕は聞くようにしてます。
割といろんなものが出てきて面白いですし
お決まりのようなテーブル評価しかしないみたいな会社も全然あると思うので
仕方ないと思います。その定量評価が難しいので。
難しいんですけど今は現状そうするしかないみたいな
言い方をしつつどうしていきたいとかでもこういうところが
やっぱ重要だよねみたいなところを語ってくれる人がいる
そういう方だったのであれば
僕としてはポイント高いなという感じですね。
完全にちょっと上から目線で申し訳ないです。
じゃあ終わりにというところですけど
これらが言語化できるようになったというだけでほんの少し成長している気がします。
全然ほんの少しじゃないでしょうと思いますけど。
打倒西場には程遠いのでまだまだこれからとおっしゃってますね。
めちゃめちゃレベル高いと思いますけどね。
イベントの対談相手だった東野西場さんは
これまたM3で私が尊敬する人の一人である
山崎さんと対談イベントやるらしい。やってましたよね確かに。
今年の2月28日なのでもうだいぶ前ですけど
山崎さんもめちゃめちゃすごい人ですよ。
M3の。今もVPOEかな。
他のもめっちゃレベル高くてエンジニアとしてもすごいし
頭の回転がめちゃくちゃ速かったですね。
3次面接か2次面接か3次面接で関わらせていただいたんですけど
まぁちょっとすごかったですね。
こんな社会人エンジニアになりたいなっていうもう僕の理想像の一人ですね。
はい。
新卒で33に入社して転職したM3の上司が33に行き活躍しフルストイベントをしている。
Yahoo!時代に一緒にサンフランシスコに行った人たちが
広く活躍している話も最近連絡して聞いている。
関わった人の活躍からは刺激も受けるし
活躍の仕方でもなかったことも多い。
みんな頑張っていこうというところでこの記事は締められております。
とっても読み応えがあったし
僕には刺激をたくさんいただいた記事で
今いいね数218とかあるんですけど
いい記事でしたね。
皆さんがどう感じるかわかるんですけど
改めて皆さんの方でも実際読んでいただいて
ノートに書いたりとか
思うところがあったらいいなと思っております。
僕としてはかなり刺激になったのでとてもありがたい記事だったなと思います。
時間も30分きましたので
今日の朝活動は以上にしたいなと思います。
毎回のように来ていただきありがとうございます。
めちゃくちゃ嬉しいんですよ。
たった一人だけだとしても。
今日は月曜日ですね。
来週はシェルバーウィークと言われたりするので
休みも多いので今週一週間なんとか乗り切っていけたらなと思います。
では終了します。お疲れ様でした。
