シェア
はてブ
渋川（@shibu_jp）です。現在はフューチャー株式会社という、一次受けでコンサルから実装から運用保守まで一気通貫に行う会社にいます。社会人になってから、特に選り好みをしたりせず、任せられる仕事はなんでもやってきました。最近多いのは、サーバーからフロントあたりの領域です。
それ以外に書籍の執筆などもしており、今年（2020年）は『Real World HTTP 第2版』が出版され、「n月刊ラムダノートVol.2 No.1」にも寄稿しました。ほかに『Goならわかるシステムプログラミング』も、増刷のタイミングで密かに12ページほどコンテンツを増やしたりしています。
キャリアや仕事の仕方について、よく周りから聞かれるのが「いつ本を書いているのか？」「なぜ書き続けているのか？」といった質問です。僕としては、どちらかというと効率マニアで、一石二鳥を狙い続けていた結果にすぎないのですが、そのあたりも交えつつ、どのようにキャリアを選択してきたのかを紹介します。
- アウトプットが仕事と別の活動だったころ
- 業務と関連したアウトプットが自分の仕事のためになる
- 自分だけでなく若手やチームのために情報を共有する
- アウトプットすることを前提とした勉強法
- みんなの成長が結果として見えるように
アウトプットが仕事と別の活動だったころ
高校までは家にインターネットもなく、本を読みつつプログラミングを学ぶのですが、何年やってもオブジェクト指向わからん、みたいな感じでした。
大学では技術系のメーリングリストにいくつか入ったりしましたが、その中でテクノロジックアートの長瀬嘉秀（yoshi.nagase）さんが呼びかけた日本XPユーザーグループ（XPJUG）の運営に応募したのが、キャリアとして最初の一歩になりました。イベント運営のかたわら、長瀬さんの持ってきてくれた書籍の企画に参加して出版を経験し、その後は雑誌にも記事を書いたりしました。
イベントなどのライトニングトークで「銅鑼を鳴らす」というのも今では当たり前になりましたが、「銅鑼みたいなものを鳴らしたい」「銅鑼がないから、うちにある中華鍋を持っていきます！」という会話があって、渋川家の中華鍋を使ったのが最初な気がします。永和システムマネジメントさんが購入されたので、本当の銅鑼の始まりはそこからですね。
その後は、新卒でホンダに入社しました。自動車も電子化が進み、ソフトウェアが重要になっていく時代だし良さそう、という考えからです。配属先は商品開発ではなく、設計者が使うCAD周りのシステム開発だったので目論見は外れましたが、これはこれで楽しく仕事していました。
仕事ではC++やPython（ぜひ使いましょうと提案した）を使っていました。社外では、趣味でPythonを書いたり、とちぎRubyの勉強会に参加したりしつつ、速読やマインドマップ、GTD（Getting Things Done）、制約理論（TOC）など、ソフトウェアではない方面の勉強会やセミナーにもよく行っていました。当時はマインドマップを仕事で活用するなど、外で学んだことを持ってくることはあっても、基本的に社外の活動と仕事は独立していました。
OSSも公開していましたが、書き物のアウトプットとしては翻訳が多かったです。原文が良いことを書いていたら、アウトプットも良いものになるはずで、無名状態から手っ取り早く世間に貢献するには効率的です。
副業禁止と言われて本の出版はできなかったのですが、そのうち転職したら出そうと、原稿は書いていました。参加していたプロジェクトのリリースが遅れて、うっかり転職前に出版されてしまったこともありましたが1。
業務と関連したアウトプットが自分の仕事のためになる
2011年にDeNAへ転職しました。仕事としては引き続き社内SE的な感じで、JavaScriptでコードが書けるゲームエンジンngCoreを長らく触りつつ、Goを仕事に投入したり（こっそり投入したら後で少しお叱りはありましたが）しました。
社内システム開発では、ユーザーが同じ社内の近くの席にいるため、気軽に要望や提案ができます。ユーザーの期待を上回るものを提供して喜んでもらえることもあり、楽しく仕事をしていました。 また、ホンダ時代と違って、社名を出した社外発表も比較的自由にできました。たまに社内の許可やレビューをもらいつつ、業務に関連した発表もしました。
このとき、社外発表したり本にしたりすると、社内でのみ発信するよりも、より社内にも情報が伝わることに気づきました。例えば、ウェブのフロントエンドのフレームワークであるMithrilの電子書籍を出版したところ、社内でもフロントエンド人材だと認知されてブランディングができ、仕事が回ってきたりしました。
また、社内で作ったGoogle Spreadsheetからマスターデータを作成するGo製のバッチプログラムは、社内でも他の案件から引き合いがありましたが、社外でも反響があったらしく、何人かの知人から「発表資料のURLが送られてきて、『これと同じツールを作ってほしい』と言われた」との証言を得ました。
一方で、外部発表にも本にもならない小さなアウトプットは、思ったより周りの人に見られてないし、認知もされないということ。そして、社内で大量のドキュメントを丁寧に書いても読まれない、ということも経験しました。前述のバッチプログラムの引き継ぎ資料はFAQとともに4択クイズを入れてみたりと意欲的なドキュメントだったのですが、引き継がれることなく塩漬けにされてそうな雰囲気を感じています。
業界のスタンダードに近い技術はインプットもアウトプットもしやすい
社内専用フレームワークが好感されないというのも、DeNAで知ったことですね。ソースコードは会計上の資産であり、会社固有のソースコードも当然資産だと考えている人は多いと思います。しかし、個人のキャリアとして見たときは、必ずしもそうではない、「ngCoreより、Unityが使いたい」と言っている人がいて、目から鱗が落ちたのを覚えています（現在はDeNAもUnityに移行してかなりの期間がたっています）。一度転職していたこともあり、社内の評価だけではなく「社外から見てどうか？」も大切ということは納得できるものでした。
これは個人のキャリアにとどまる話ではなく、組織のあり方にも通じる話です。業務のコアの知識はもちろん依然として大切ですが、実装技術や実現方法のレイヤーであれば業界のスタンダードに近づけていった方が、世の中の進歩の恩恵を受けられますし、その恩恵に対する恩返しもしやすくなります。外部から採用した人も、即戦力として活躍しやすくなります。
この時代の書き物のアウトプットは、翻訳よりもオリジナルの書き下ろしが増えました。きっかけとしては、すでにある書籍やウェブのチュートリアルでは自分のユースケースに足りなかったり、実践してみたら紹介したい知見がたまった、あるいは自分が読みたい本がなく資料をまとめているうちに企画になってしまった、などがあります。
完全に業務と関係のない趣味の中からそういった企画になることもありましたが、仕事中や社内の勉強会で学んだことが種となり、それを多くの人に役立つように汎用的な内容に育てて、企画となることも増えました。仕事をオープンな技術に寄せれば寄せるほど、このようなアウトプットの難易度は下がっていきますし、仕事中にネタもたくさん作ることができて一石二鳥です。
自分だけでなく若手やチームのために情報を共有する
社内SEは、目の前のお客さんの反応を見ながらシステムが作れるので楽しいのですが、事業会社での評価基準は「主力のビジネスで成果を出したかどうか？」になりがちです。DeNAに限った話ではありませんが、横断部門は大きくマイナス評価もされないが、プラス評価もあまりない、という話はよく聞きます。
そうであれば、社内SEと同じような楽しい仕事を本業でやっているところ、なおかつコードを自分で書いているところ、と探しているときに人づてで紹介されたのがフューチャーで、2017年に転職しました。
フューチャーでは発表をどんどん応援してくれることもあり、DeNA時代の反省から、情報はなるべく外から見えるようにしています。仕事で学んだことも、お客様に関わる情報を抜き、純粋な技術情報としてまとめつつ、社外の勉強会や、Qiita、会社の技術ブログに出すようにしています。そういった記事や資料は仕事でもよく参照しますし、他の人にリンクを送ったりといった活用もできます。
僕自身も最近は月に1つ以上のペースで技術ブログを投稿していますが、会社の他のメンバーも外部発表を活発に行う機運が高まっています。僕が最初にアイディアを出した集中連載も、編集長によってその後も続々と新しい企画が立てられて、新しく発信する人もどんどん増えています。
例えば、フューチャーに入ってすぐの案件で、社内システムだけどフロントをモダンな技術で作る仕事の担当になりました。そのとき、若手のメンバーから「研修でJavaScriptも少しやったが、jQueryぐらいだった」という話を聞き、最新のJavaScriptを学ぶよい資料がないか探したものの見つからず、社外の詳しい人にも聞きながら、QiitaでJavaScriptの記事をまとめました。
この反響は大きく、その後「Software Design」の特集にも書かせてもらったりしました。
周りを成長させることが自分の評価につながる
これまではソロだったり、片手程度の人数で仕事することが多かったのですが、フューチャーに入ってからは一回り以上若い人たちと、大きなチームを組んで仕事することが増えました。チームでの仕事は楽しいですし、若い人たちに適切なアドバイスをしてガンガン成長してくれるのを見るのも楽しいです。
フューチャーでは単純に経験を積めば管理職というわけではなく、現場でコードを書く仕事を続けることもできます。しかし、組織で仕事している以上、一人で一騎当千の結果を出すよりは、周りのメンバーを成長させて、会社を強くし、「また一緒に仕事したい」と言ってもらえることが、自分の評価につながると考えています。
『情熱プログラマー』という本の「一番下手くそでいよう」という言葉を信奉している人はこの業界に多いようです。部分的にはいいと思いますし、若いうちに考えることとしてもいいと思うんですが、30代・40代となってよりよいキャリア（お給料）を得るには、チーム目線の比重がどんどん大きくなると考えています。
社内での情報共有で心がけていること
会社には、必要な情報統制があります。前々職では、関係部署やその担当にならないと、新車の開発計画を知ることができませんでした。前職でも、特に他社のIP（知的財産、漫画やアニメの有名なキャラクター）を利用するプロジェクトが増えるにつれ、何をやっているのか情報が入ってこなくなりました。「必要な人にのみ情報を知らせる」ことは情報統制の基本であり、会社としての行動は間違っていません。
しかし、案件が進んで（もしくはリリースした後）で制約のきつい中を運用改善するくらいなら、もっと前にプロジェクト立ち上げ当初から関与したいと思うのですが、そんな機会は得られません。結局、各チームが個別にがんばるという状況を見て、歯がゆく感じていました。
もちろん社内の情報がフルオープンだったとしても、各チームが抱えている課題を細かく知ることができるかといえば、難しいでしょう。そのため、知見を技術ブログなどを通じて積極的にオープンに公開していくことで、他のチームに発見してもらいやすくすることを、前職以上に心がけています。
そして声をかけてもらったら、1を聞かれても、おせっかいだろうが10ぐらい返す。質問されたら、同じ質問であっても丁寧に何度でも答える。相手の情報を聞いて、それに合わせた回答をする。そういったことを心がけています。
知見をアウトプットし続ける方法こそがノウハウ
技術選定においても「外部の勉強会でそのまま発表しても恥ずかしくない」を基準にしています。そうすれば、社内の知見をホットな情報として社外に出せますし、社外の知見も取り入れやすくなります。
この考え方は、一緒に技術ブログを書いている仲間にも浸透してきたように思います。細かい技術的なHow Toを知っていることがノウハウなのではなく、技術的な知見を継続的に収集しアウトプットし続ける方法こそが、より大事なノウハウだと考えています。
書籍の形もインターネットとの共存の中で変わってくるはずと、フューチャーに入ってからは、ネット時代に活用してもらいやすい形を模索しています。紙の本にしかない情報が、出版社がなくなったことで広まらなくなったということを何件も目にしてきました。
また、書籍で中ヒット（何回か増刷）を出したとしても、現在のIT技術者の総人口から比べると普及度としては1桁パーセント程度でしょうし、情報の検索は検索エンジンを使うことがあたり前になってきています。日本全体の能力を底上げするには、従来の書籍という形態だけでは限界があると考えています。
そのため、一部はネットでも無料で読めるようにしたり、個別のトピックをブログで公開したり、勉強会や研修で使ってもらえるように著作権法的なコピーライトよりゆるいライセンスにしたり、時代に合わせていこうと思っています。
アウトプットすることを前提とした勉強法
エンジニアとしてのキャリアのため、オフの時間に勉強している人も多いでしょう。本来なら仕事に必要な知識や経験は仕事の中でしっかりと積むことができ、成長もアウトプットもできるようになるのが理想ですが、平均より上を目指すにはプラスアルファしていかざるを得ないかな、と思っています。
会社でやった経験を元に、会社の名前で勉強会や会社の技術ブログなどでアウトプットする分には、会社の時間を使ってよい、という会社は増えていると思います。しかし、自分が過去に持っていないかった経験をゼロから積む場合や、必ずしも仕事の担当と関係ないことをする分には、どうしても自分の時間を使うことになるでしょう。
勉強する時間をどうやって作るか？
時間に関しては、特に家族持ちの人の場合、どこで確保するかが課題です。筆者は以前、共著で勉強法に関する本を書いたときにアンケートを取ったのですが、早朝、夜、土日祝日、通勤時間、平日就業後、休み時間などの回答が多かったです。
私は通勤時間と平日の夜が中心で、平日の朝と週末は家族との時間としています。現在、この原稿を書いているタイミングでは新型コロナウイルスのこともあり、在宅ワークとなって数カ月になりますが、仮想通勤時間として30分から1時間を確保するようにしています。
もちろん家族持ちでない人も、これから家族になる人を探すことに時間を投資したり、プログラミング以外の趣味をいくつも持っている人も多いと思うので、メリハリが大切なことは変わりません。
勉強したことをアウトプットするときに心がけること
勉強の対象はそのときのモチベーションによってコロコロ変わりますが、技術ブログであったり、オープンソースの動くコードであったり、あるいはその両方をなるべく作るようにしています。何かしらアウトプットしておくと、その場で中断してもまた数カ月後、あるいは数年後でもスムーズに再開できます。
また、すでに説明したように「外から見えるアウトプット」は自分のブランティングに大切です。
アウトプットの内容については、例えばプログラミング言語を学ぶにしても、読んだ本やウェブのマニュアルをなぞるだけではなく、手を動かし、悩んで経験したことを入れてアウトプットするようにしています。自分のオリジナルコンテンツとなりますし、リアリティを伴う内容になります。
また「やってみた」レベルではなく、「次に仕事で使うなら」「隣のプロジェクトの人にも参考にしてもらえるには」という想定で、より汎用的な内容になるよう心がけています。実際、汎用的な方が多くの読者に当てはまるため、読んでもらえるでしょうし、価値も高いでしょう。
みんなの成長が結果として見えるように
書籍の執筆が仕事と完全に別物というホンダ時代を経て、手を動かし続けるために転職したDeNAでは、執筆と仕事がオーバーラップしはじめました。現在のフューチャーではオーバーラップもするし、コーディングのテクニックや知見などを積極的に外にアウトプットしつつ、チームの成長にもコミットメントする方向にシフトしてきています。
現在の状況を簡単にまとめるとこんな感じです。
- キャリアとしては、自分の成長よりも、チームの成功や成長が評価されるステージ
- チームをリードしていくため、最新情報のキャッチアップとスキルアップは必要
- 教育コンテンツや、次の作業をする情報源として、記事や本を執筆して貯めていくことは大事
- 仕事など実践的な場でアウトプットを活用し、かつフィードバックを受けることで、アウトプットの品質も向上させていく
同じ仕事をするにしても、結果として残るものが多い方が望ましいですよね。依頼されたシステム開発を期限内にきちんと仕上げるのはもちろんのこと、それにプラスして、一緒に仕事している人にもより新しい技術に触れる経験を積ませてあげられたとか、納品したコード以外に技術ブログやQiitaに記事を10本ぐらい量産できたとか、プラスアルファが効率よく増えて、ブランディングを強化できる方法を常に模索しています。
どの会社、どのプロジェクト、どのチームであっても「この分野で困ったらあの人に聞けば安心」と思ってもらうことではじめて頼ってもらえます。そのため、社外より社内向けのブランディングが重要です。 その過程におけるアウトプットが他のチームを（場合によっては他社の人も）助けたり、仕事のフィードバックを受けてアウトプットをもっと洗練させたり。最近は、仕事やキャリアとアウトプットの歯車がしっかりと噛み合って、特にアウトプットが最大化されていると実感しています。
自分が大学から始めたインラインスケートを子供たちに教えているのですが、小さい大会でメダルを獲得したり、努力が目に見える形で残るようにということは、子供と接するときにも意識しています。大学時代からの知人の奥さんに「渋川家は理想の家族」と言ってもらえたのが、ここ最近で一番うれしいできごとです。
もうしばらく、この考え方でキャリアを積み重ねていこうと思っています。
編集：はてな編集部
渋川 よしき
東京工業大学卒業後、本田技術研究所に入社。2011年1月にDeNAに転職し、サンフランシスコでngCore用のミドルウェアと開発環境用のツール開発などを経験。2017年9月からフューチャーアーキテクトに所属している。『Goならわかるシステムプログラミング』（ラムダノート）『Real World HTTP』（オライリー・ジャパン）『つまみぐい勉強法』（技術評論社、共著）『アート・オブ・コミュニティ』（オライリー・ジャパン）など、著書翻訳書多数。
