前職エムスリー時代の同僚であり上司でもあった現Sansan VPoE 西場（@m_nishiba）と最近イベントに登壇した。

イベント内のディスカッションで、実は現職のCADDiでやってる内容の殆どがエムスリーで学んだいくつかのトピックなんだよなと思う所があり、4つのトピックに絞って言語化しておこうと思う。

共通言語としてビジネス書を読む

私自身、Sansan、Yahooの頃はビジネス書は技術に関連していたり、プロジェクトマネジメントやヒューマンマネジメントに関するものでない限り読まなかった。

そもそもビジネス書の大半は、エンジニアにとって読みにくいものである。
技術書のように一定の決まったフォーマットがなく、経験則で確実な再現性がなく、体育会系のストーリーが背景にある場合も多い。文献引用もなく、出てくる数値やデータは信頼しても良いものかすら分からない。実際誤訳や妄想も多く、嘘統計や嘘グラフなど、苦笑するしかない書籍もある。

実際に私が尊敬する業界トップレベルのソフトウェアエンジニアの中にも、「ビジネス書は苦手である」という人は多い。なので、ソフトウェアエンジニアとして生きていく上で必須ではないだろう、という所だけ前提に置いておく。

一方エムスリーでは、この@m_nishibaという人がビジネス書を大量に読んでいた。イベント内でも言ったのだが、一時期、彼と毎日1on1してスパルタ教育してもらっていた時期があった。

最初の数週間は視点が合わない事が多かった。今になって思えば、プロダクトや人、チーム、技術に対する共通言語が無かったのだなと思う。どうしても噛み合わない@m_nishibaを理解すべく、彼からオススメされたビジネス書を数冊読んだのが、私の最初のビジネス書への入り口だった。

特に「採用基準」を読んだ前後では、見方が変わった。

ちきりん氏の書籍でCADDiでも適切そうな人にはオススメしている。
ビジネスパーソンが持べきリーダーシップとはなんたるか、それらが自分にどう巡り巡って得になるかが書いてある良書である。
（余談だがちきりん氏には何故かTwitterでブロックされている。言及したことないし夫婦でVoicyとかも良いと思ってるんだがどうして…）

この本を読んだ後、@m_nishibaとのコミュニケーションは驚く程スムーズになった。表現するなら「お互いハンターハンターを読み込んでおり日常会話でハンターハンターネタを言い合える学生時代の友人」のような感覚だ。

@m_nishibaの発言、特に「ビジネスパーソン」に対する言及は、実はこの書籍に書いてあった事をフラッシュアップし、眼の前の物事と対比して自分の中に落とし込み、行動に移した物だった。

この抽象度の高い何かは、その場でゼロから互いに形成していくよりも「ハンターハンターを1回読んでくれ」と言った方が圧倒的に早い。ハンターハンターを読んでない人に「それ俺じゃなきゃ見逃しちゃうね」と言えるようになるまでの時間を考えると当然である。

そして、多くの強いビジネスパーソンは、これらを習慣化している事も分かった。CEOもVPoEもプロダクトマネージャもビジネス書を前提の共通言語として話しているし、それらを読んでいるだけで経営層やプロダクトマネージャが使う言葉をより俯瞰で捉えて聞くことができる。

最初ビジネスパーソンは何でこんなビジネス書たる何かを共通言語にしているんだ、とも思ったが、実態は「良いビジネス書のような形で高いレベルで"経験"を言語化してまとめられる才のある人は少ない」という事で私の中では落ち着いた。冨樫先生でないとハンターハンターという共通言語になるレベルの良作が書けないのと同じだ。

これらは、一定の読みにくさや技術書との違いをスルーさえすれば、共通言語として強い価値を提供してくれる。そう、ハンターハンターと同じだ。ハンターハンターという強力で魅力的な共通言語が無ければ、あの学生時代の学友との青春の日々は得られなかったと言っても過言ではないだろう。

そして同じ"経験"を書籍で共有した人達で組むチームは頑強だ。これは会社の中でもそうだし、外に対しても言える。なので良いビジネスパーソンは良いビジネスパーソンとの共通言語を持つためにハンターハンターではなくビジネス書を読んでいるのだ、と私は捉えている。

これが私のソフトウェアと日本語以外のビジネス上の共通言語を持てた瞬間でもあり、ビジネス書を読めるようになったきっかけでもある。

もし、経営層やプロダクトマネージャが何言ってるかよくわからん、というソフトウェアエンジニアが居たならば、その人が紹介するビジネス書を一度我慢してでも読んでみる、というのをオススメしている。

より深い効能はさておき、あくまで共通言語として、という入りはビジネス書に対する偏見と敷居を下げてくれると思う。

ちなみにビジネス書が苦手だった私がCADDiに入って一番最初にやった仕事は、CEOがオススメするビジネス書という社内メモに書いてある本を共有本棚から取って全部読む仕事である。

本気でぶつかっても大丈夫な人と仕事する

イベント内で私は@m_nishibaを「本気で叩いても壊れないオモチャ」と評した。文章ではニュアンスが伝わらないかもしれないが、当然良い意味でである。

「ソフトスキルは大事」というのは普遍的なエンジニア成長論でも語られるが、その中でソフトスキルの成長論については省かれている事が多い。

多分Team Geekが一番言いたい事に近いが、じゃあどうやってその強いソフトスキルを得るんだという話だ。

これらの成長方法について触れられにくい理由として私が考えているのは、パーソナリティに触れる必要がある点だ。

近年の流れとしても、私個人の考えとしても、他人のパーソナルな部分に踏み込まず仕事をする事は非常に重要で無闇矢鱈に触れて良いものではないが、ソフトスキルともコミュニケーション、素直さ、謙虚などとも呼ばれる"ビジネスパーソンとしてソフトウェアエンジニアに求められている必要な何か"の成長にはパーソナルな部分が密接に関係している。

強くソフトスキルを発揮できる人というのは、パーソナルな部分からビジネス上で起こる全ての物事の捉え方が違っているため、表面的に取り繕うだけでは、そのスピードに追いつけない。

そして、実際パーソナルな部分を晒して「本当は過去の体験からこう思い、こうしている」「私はこの作業や人に得意/苦手意識がある」「こういう物事に高揚感/劣等感を感じる」をぶつけ、それらをより良い捉え方に変える作業というのは非常に熱量と長い対話と努力が、話す側にも話される側にも必要になる。これがもう超ハードだし出来る人がそもそも多くない。

そんなハードな壁打ちに並走してくれるバケモノが@m_nishibaだった。

パーソナルな部分をぶつけ合っても、多くを受け止めた上で、小さく指摘することもあれば、先の書籍のように適切な物や人に置き換え、より汲み取りやすく変換してくれる。また、短い時間で考える量も多く、自分がぶつけた数日後には複数の回答を用意してくれる。

こういった事が出来る人と仕事すると、単にソフトスキルが向上するだけでなく、自分のパーソナリティを汲み取った上でプロダクトチームや技術力向上に必要な物事を揃えて貰える。かなり仕事やりやすかった。

誰にでも出せば良いというものではないが、一定本気でパーソナルな部分を含めてぶつかっても良い人を探し、そういった人と協業すると、自身の仕事や成長が回り始める事を理解出来たのは@m_nishiba壁打ちの一番の効能だったと言える。

といいつつ私もソフトスキルについては苦手な方で、ソフトウェアエンジニアとして取り繕って話す癖が今でも出る時があるが、かなり改善しつつある方だとも思う。

苦手だった私でさえも、CADDiに入って最初の週にあったCEOに「CADDiで1on1すべき人」を挙げてもらい、その全員に1on1をお願いするなどしているのだ。その中ではアイデアや意見を実直にぶつけ、何人かとは継続して1on1をしてもらっている。CADDiにも本気でやっても壊れない人が多そうでむしろ楽しみなくらいだ。

今後は、周囲の人が私に本気でぶつかってきても良いように、無垢な子供が純粋な気持ちで「こうしたい！」をぶつけても壊れない頑丈なオモチャのように、私もなりたいと思う。

アイデアを100個出す

これは、イベント中にも@m_nishibaが言っていて、エムスリーの時に私に課してきた大きな宿題の1つ。

イベント内でも言われたが、私は「これは難しい」と言ってすぐに思考をやめる癖がある。でもこれは一定専門を収めた人には、ありがちな行為だと思ってもいる。実際プロダクトの無理難題を一定妥協して開発するのが専門職であるソフトウェアエンジニアであり、あり得ない道を早く損切りして現状で最も良い道を選ぶ事は開発者として重要なスキルの1つでもある。

アイデアを100個出す、というのは数が大事なのではなく、その「あり得ない道」について熟考したか？という所を問われる宿題である。なんせ100個出そうとすると、正当な道に絞って出しても大体の場合数が達成できない。

これは、私が得意としている素早く良いものを作る思想とは一見反するように見えるが、考える時間が多い程実際は素早く良いものが作れる。その思考が苦手で、すぐ手を動かしてしまう私のような人でも、簡単に思考の時間と広さ、深さを伸ばせるのがこの100個考えるフレームワークである。
フレームワークis便利。

今では、プロダクト作りや開発においてこのフレームワークを自分でも実践しながら、PdMにも強制する側になっている。

このあと@imaimai0は何だかんだで100個出してきて、100個全て私が技術的なレビューをして、次はどれをやろうかという話になっている。@imaimai0もまた怪物みたいな人だ。おかげで日々CADDiへの解像度が上がっている。

プロダクトと人について考える

プロダクトについて考えるのはエムスリーエンジニアリンググループの特徴の一つだ。開発者の誰もがこれらについて考えており、いつの間にか私もそう思うようになった。

何となくだが「エンジニアもプロダクトについて考えるべき」というべき論ではなく、「プロダクトや人について考えていた方が良いものが作れる場合が多い」という話だと理解出来たのはエムスリーに居て良かった事の1つ。

こと営利企業においては、開発シーンで語られる"不確実性"の多くが人やプロダクト、ユーザ、時勢に基づいて発生するため、これらを抑制するには自らハンドリングしていくと多少不確実性が減るというシンプルなロジックでそれ以上は何もないという理解でエンジニアには十分だと感じる。

プロダクトをコントロールするにはプロダクトマネージャやユーザと話してデータを見ればいいし、どんな人と働くかをコントロールするには意見のぶつけ合いや採用に参加すれば良い。そしてそのコントロールが「ソフトウェアエンジニアとして良い物を開発する」ことに繋がる可能性がある。

この話が面倒なのは、可能性があるだけで無い場合もあるところ。
実際やらなくても良い事も多いし、分業という考え方もあるだろう。

実際やらなくても素晴らしい成果を残すソフトウェアエンジニアは居るには居るので、その場の誰も課題に感じてなければ良いんじゃないかとも思う。

私は、この確率や課題性について考えるのが面倒なので「数を打つ」事で分母を増やして発生回数を上げるという方法を取っている。端的には「何でもやります」といつも宣言している。

プロダクトでは本当に何でも作るし、何でも要望聞いて意見するからMTG入れてねと言っている。思い出深いトピックはいくつかあるが、Kotlinの開発への参加、採用への参加、エムスリー公式Twitterの中の人を一時期やらせてもらったりしたことだ。

私はめちゃくちゃTwitterが好きだが、宣言して歩き回っていたらまさか仕事になるとは思わなかった。

実際こういった活動をきっかけにエムスリーを知った素晴らしいメンバーがエムスリーに入り、その人と働き良いプロダクトが出来上がるという事象も経験して、全てがプロダクトのためになっている実感を得られた。

「プロダクトについて考える」とは、それらに関連する技術、人、チーム、会社の全てを作り上げるための施策を考える事なのだと思い知らされた。

こういった「プロダクトや人について考える」事をして実践する作業は、当たらない事も多いが、たまに当たって面白いなくらいの感覚で私は良いと思っている。開発の片手間としてガチャやる感覚だと面白い、と表現して色んな人にオススメしている。もちろん仕事でやる以上は一定本気使うけども。

今でも@m3_engineeringがしっかり拡散されてるか見に行ってしまう

CADDi Techもいいぞ。どっちもフォローよろしくね。

ちなみに私は定量評価オタクを公言して働いており、フォロワー数もRT数も数として必ず見ている。もちろんそれだけじゃないけど。

見ているぞ。

見ているからな。

おわりに

これらが言語化出来るようになったというだけで、ほんの少し成長している気がする。打倒西場には程遠いので、まだまだこれから。

イベントの対談相手だった当の西場さんは、これまたエムスリーで私が尊敬する人の一人である山崎さんと対談イベントをやるらしい。​

新卒でSansanに入社して、転職したエムスリーの上司がSansanに行き活躍し、古巣とイベントをしている。Yahoo!時代に一緒にサンフランシスコに行った人達が広く活躍している話も最近連続して聞いている。

関わった人の活躍からは刺激も受けるし、活躍の仕方で学ぶ事も多い。

みんな頑張ってこ。