エンジニアが「優れたアウトプット」をするために必要なこと

学び続ける努力

山下和彦氏：こんばんは。今日、僕から話したいテーマは「学び続ける努力」です。なんとなくの雰囲気で（テーマを）出したのですが、社内の広報に出したときに、「イベントの趣旨とタイトルが合っていないですけど、大丈夫ですか？」とツッコまれて、10分ぐらい無駄な時間を浪費しました。

（会場笑）

（今日は）仕方なく取ったお酒がアルコール9パーセントだったので、おそらくしゃべりながら酩酊していく感じです。

（会場笑）

今日初めてお会いする方もいらっしゃると思うので、簡単に自己紹介をさせていただきます。

僕はいま、GMOペパボという会社で、「ロリポップ！」「ヘテムル」「ムームードメイン」といったホスティング事業を提供している事業部のテクニカルリードをやっています。

Twitterは@pyama86というアカウントで、GitHubも全部これでやっています。

簡単に我々の会社のことを紹介させていただきます。僕が所属するホスティング事業部のほかに、EC事業、ハンドメイド事業を展開しています。

ホスティング事業部には、いまご紹介したサービスがあるのですが、EC事業は「カラーミーショップ」や「SUZURI」といったサービスに力を入れています。ハンドメイドでは「minne」というサービスをやっており、もしかしたらCMを見られたことがあるかもしれません。こんな感じで、大きく3つの事業をやってます。

個人的には「STNS」というプロダクトを持っていて、これはLinuxの名前解決を提供するサービスです。旧来、LDAPで提供されていたLinuxを、いま風のHTTPインターフェースで、JSONインターフェースを構えて、名前解決をするプロダクトです。

継続的なアウトプットについて

ここから、今日の本題に入ります。「継続的なアウトプット」というところですね。僕らの会社では、「みんなと仲良くすること」「ファンを増やすこと」「アウトプットすること」というパートナー（ペパボでは社員のことをパートナーと呼んでいます）が大切にしている3つのことがあります。

では「アウトプットとはなんなんだ？」という話を先にして、みなさんと認識を合わせておきます。「アウトプット」の定義は、エンジニアによっていくつかあると思いますので、簡単に3つほど挙げます。

1つはブログを書くことです。「今日のブログ」「○○に参加しました」といったブログを書いてもいいでしょう。そして、コードを書いてGitHubで公開してみたり、自分の仕事でコードを書いたり。また、その内容をカンファレンスに登壇（して発表）したり、こうした勉強会で登壇してもいいですね。

アウトプットについては「ただやった、じゃダメだよね」というお話もあります。僕らは昔、会社で日報を書く文化がありました。

（このスライドには）3、4年ぐらい前に執行役員の柴田が日報に書いたアウトプットの話を引用していますが、これは通称「hsbt文書」といっています。

（会場笑）

この部分をボールドにしているんですが、「優れたアウトプットというのは、出すだけじゃなく、アウトプットによって人に行動を促したり、人の行動を引き起こすことが、優れたアウトプットだ」ということを述べています。

では、「人の行動を引き起こすアウトプットってなんなんだ？」というところですね。

さっきの例でいくと、ブログを書くだけというのはけっこう簡単ですが、それがはてブなどでブックマークされるとか、もしくは誰かに引用されたりとか、書いた内容が誰かに実践されるということですね。

「コードを書く」でいうと、単純に公開されたコードが利用されたり、誰かからプルリクエストをもらったり、Issueに報告があるといったかたちです。

「登壇」でいえば、質問されるのが一番簡単ですけど、ブログを書いてもらったり、ちゃんと自分のセッションに人が来てくれることですね。もともと優れたアウトプットができてないといけないので、これも大事なことかなと思っています。

アウトプットを継続するためにはどうするか？

これらがアウトプットで、ここからは「優れたアウトプットを継続するためにはどうしましょうか？」という話をしようと思います。

シンプルに考えると、継続的に優れたアウトプットを出すためには、インプットがないといけません。なので「継続的にインプットしていきましょう」というお話をします。

たぶん、僕は継続的なインプットができていると思うんですけど、「どうしてできているんだっけ？」というところが、僕自身もいまいちわからないんですね。そんな中で、今回こういった（登壇の）お話をいただいたので、僕の例を軽く整理してスライドにしてきました。

これまでの職歴です。いまはもうありませんが、パイオニアの「プラズマディスプレイ」を作る工場にいました。10年ぐらい前は、「液晶かプラズマか」みたいな時代があったんですね。いまのテレビは全部が液晶になっていますが、その当時はプラズマディスプレイを作っていました。

みなさんも九州だからご存じだと思いますが、その後、BBIQというの光（インターネット）サービスを提供している会社に5年ほどおりました。そして、いまのGMOペパボに入ってちょうど5年目です。このままでいくと、「僕、退職するのか」みたいな感じなんですけど（笑）。

（会場笑）

そんなことないですよ。いや、これを書きながら、会社の人間に誤解されそうだなと思って（笑）。

PPDへ入社し、資格取得のためにひたすら暗記

（スライドを指して）これはちょうど10年ぐらい前に友達と関西に行った時の写真です。高卒で働き始めて、18歳から23歳の間、パイオニアプラズマディスプレイ（の仕事）で、テレビの生産工場で社内SEをやっていました。

例えば、50代ぐらいの部長さんの「Excelの使い方がわからん」（といった場合のレクチャー）や、生産工場の生産設備には「シーケンサー」という小さいコンピューターが入っているのですが、それとサーバーを通信させて製造工程をちゃんと動かす管理などをやっていました。

ご存じの方もいると思いますが、当時はひたすら、「CCNA」や「ORACLE MASTER」といった資格を取っていました。

僕がいたのは鹿児島県出水市という所で、マクドナルドができたのが高校生の時という、かなりの田舎でした。やることもなくて、仕事が終わってから1、2時間はひたすら勉強して、休みの日はパチンコをしたりといった毎日でしたね。とにかく勉強していました。

そのときは、あまりプロダクティビティのあるようなことはやっていなくて、ひたすら資格の勉強として、本屋に置いてある本の正答例などを全部ひたすら暗記して、資格を取っていました。

会社の倒産とともにQTnetへ

そして、パイオニアプラズマディスプレイが倒産しまして、「鹿児島は仕事がないから福岡に行くか」ということで、QTnetに入社しました。そのとき23歳で、職務としてはFTTHという、家庭用の光回線（に関する業務）に加えて、企業をVLANで結ぶといったサービスや、ネットワーク管理やサーバーの構築などをやっていた感じです。

また、23歳ぐらいのときから大学に行き始めました。一社目のパイオニアに所属しているときもそれなりに大きい大学の出身者が多く、そのなかで高卒がコンプレックスだったんですが、それを解消するために大学に行きました。

先ほどの資格の話にもつながるんですけど、自分が興味のあることは、すごく楽しいからめちゃくちゃ勉強するんですね。一方で、「経営学」「簿記」など、あんまり好きじゃない教科は、意図的に自分に（授業を）浴びせないと勉強しないと思って、大学に通いました。そこで、マネジメントや心理学などをいろいろ勉強して、いま、結果的に活きているのでよかったなと思っています。

資格の勉強も継続していて、「MCP」「MCDST」や、「LPIC」より上位のレベルのものを取ったりもしていましたね。

最大の違いだったなと思ったんですけど、僕が鹿児島の出水にいるときは本当にやることがなく、遊ぶということがどういうことなのかがわかりませんでした。それが、福岡に出てきたら、毎日合コンしたりと最高に楽しくて。

（会場笑）

例えば、福岡だと「警固公園」というナンパのメッカみたいなところがあって、そこでひたすらナンパをしたり。

（会場笑）

あとは、福岡の大名周辺、中洲などで食べ歩きをしたり、毎年友達と好きなところに旅行に行きました。北海道に行ったりしましたが、この時期はスノボもいいですね。

そうした「遊ぶこと」「遊び方」みたいなものを知ったこの時期が、すごく楽しかったです。パイオニアにいたときは、ひたすら資格の勉強をやるぐらいで、勉強マシーンみたいな感じだったのが、「人生、こんなに楽しいんだ」と思いましたね。

プログラマーになりたくてGMOペパボへ入社

その後、ペパボに入社したのが28歳。大学は23から行き始めたので、ちょうど5年で卒業したんです。区切りがついたってことで（笑）。

当時、インフラエンジニアという領域で仕事をしていたんですけど、「もうちょっとコードを書きたいな」という思いがあって、プログラマーになりたくて入社しました。ペパボに入ったと同時に、資格の勉強は一切やらなくなりました。

ペパボの特徴としては、オープンソースへのコミットや、「オープンソースをどんどん作っていくぞ」といった文化があります。周囲のエンジニアも、とにかくコードを書きまくって公開していたのですが、そのなかで2つ壁が出てきました。

1つは、「良いコードが書けない」、もう1つが「書いて公開するんだけど、まったく使われない」という問題があって、その壁で1年ぐらい悩みました。

「良いコードが書けない問題」の前に、「良いコードってなんだっけ？」というのを先に説明します。

例えば、「Don't repeat yourself」というDRY原則に則ったり、あとは再利用性が高い、オブジェクト指向のコードを書けるとかですね。

また、僕が書いたコードはとにかく汚いというイメージがつくぐらい、可読性が高いコードが書けなかったんです。あとは、テストが書きやすいコードを書けなかった。いままでの経験は、ひたすら本を読んだり、資格を取ったりという勉強スタイルだったため、ぜんぜん（実務では）ハマらなくて、一向にいいコードを書けないし、可読性も低いままというのがずっと悩みでした。

そのときに、なにを思ったのか、同僚がGitHubで公開しているコードをひたすら写経するみたいなことをやり始めました。それがハマって、人のコードをなぞることで自分の身に入っていくみたいな感覚がありました。それができたがゆえに、オブジェクト指向の本を読んでも、「あ、こういうことか」と理解できるようになったんです。

「とりあえず、騙されたと思ってGitHubのコードを読んだり、似た実装のライブラリを探して、模倣してみたらいいんじゃない？」という話で、これも僕の人生のなかで初めての体験でした。自分と同じようなことをやりたいコードを真似するだけで、その型みたいなものがけっこう自分の中に入ってきて、とてもいい方法だと思っています。

書いたコードがまったく使われない

次に、「まったく使われない問題」ですね。

僕が最初に作ったオープンソースはいまでも覚えています。「エイリアスマネージャー」という、OSのエイリアスを管理するようなコードを作って公開したのですが、これがまったく使われませんでした。また、業務で自分がハマったことをオープンソースにして公開したんですけど、それもまったく使われなかったです。

ここで、2個ほど「人生で分岐点になったな」というプロダクトについて紹介します。「Pec」という、いわゆるOpenStackで、いまでいうTerraformが提供するような部分の機能ですね。それを自分自身でRubyで開発して公開したんですけど、それがペパボ全体で使われるようになったりしました。

なんで使われたのかというと、自分だけの課題ではなく、会社全体で課題になった問題をソフトウェアで解決できたからです。

次に、最初にご紹介した「STNS」というプロダクトです。LDAPやMySQLのユーザー管理は「もう面倒くさいな」と思っている人はけっこういると思っていたんです。そういった人の課題を解決できたため、わりと日本や世界で使われるプロダクトになったのかなと思っています。

今日は、この感じをお伝えしたかったんです。もともとの問題として、自分だけの課題ではなく、人の課題を解決できるように抽象化したプロダクトが作れなかったというところがあって、それを解決できたから、こうして使われるようになったということです。

加えて、「Pec」はRubyのgemですし、「STNS」はGolangのプロダクトですが、僕はひたすらRubyでコードを書いていましたし、Golangもキャッチアップしていたんですね。なので、目の前で課題が生まれたときに、僕が解決する手段を持っていたというのが、とても大事だったなと思っています。

「体系的な学習」が良いアウトプットの根源になる

ここまで、ざっくりとお話をしてきた内容をまとめると、パイオニアにいるときは資格取得を目的として、体系的な学習をやっていたなと思います。QTnetにいるときは、大学に行って興味のない領域も学びつつ、遊ぶ感覚や余暇を作るといった点を得られたなと思っています。いまでもけっこう本を読むんですけど、ペパボでは、体系的な学習に加えて、人から模倣することを覚えたなという感じです。

僕の経験をまとめると、いろいろな「点」があって、それを「線」でつなげると、一番大事だなと思ったのが、「体系的な学習」です。

体系的な学習は、本を読んだり論文を読んだりといった話です。それを継続するにはすごいパワーがいるため、やる気がない自分を受け入れられないと継続できないなと思っています。

よって、適度に遊ぶなり、映画を観るなり、そういったことがとても大事だなと思っています。

また、いまは福岡でエンジニアが増え、いいアウトプットをしてくれる人たちが増えてきていると思います。まずはそういった人を模倣するだけで、局所的な学習がだいぶはかどります。まずは模倣から始めたらいいと思っています。

そして、ツールの話です。今日のテーマの趣旨は、「アウトプットを継続するために使っているツールを紹介してほしい」みたいなものだと思ったので、それについて考えたんですけど、一切ツールを使っていなくて。

（会場笑）

なので、最後に思想信条の話をして、今日のまとめにしようと思っています（笑）。

「競争意識」と「時間」

ここから先は僕個人がハマったやり方みたいな話なので、参考になるかどうかわかりませんが、僕が大事にしてることの1つが「競争意識を持つこと」です。

「技術は勝ち負けじゃない」みたいな話を（誰かが）たまにTwitterでいっていて、それは「気が合わないな」と思っています。

（会場笑）

どちらかというと、僕は勝ち負けを意識しています。同僚とかがすごいプロダクトを生むと悔しいですし、Twitterとかですごいプロダクトを見ても悔しいです。自分の領域に近ければ近いほど、すごい悔しさを感じるので、負けないように自分もがんばるといったことを大事にしています。

また、プロダクトを見たときもそうなんですけど、「興味がない」と「興味がないふりをする」を混ぜたら絶対にダメだなと思っています。でかい話のほうがわかりやすいので、大きな話にします。

最近だと例えば「Kubernetes」ってありますよね？　それを自分が作れないということを、興味がないふりでごまかさないみたいなところは、すごく大事だなと思っています。自分ができない、負けていることを、「俺は興味がないからやらないだけだ」みたいなことで自分を騙すのは、絶対にやめたほうがいいなと思っています。

最後になりますが、時間はすごく平等だなと思っています。たまにすごい天才みたいな人がいるんですけど、9割ぐらいは普通の人ですよね。じゃあ、普通の人と普通の人を比べたときに、どこで勝ち負けが決まるかといったら、やっぱりかけた時間が一番大きいと思うんですよ。

さきほど、自分よりも優れたエンジニアの模倣から始めるという話をしましたけど、自分よりも優れた人がいるなら、その人と同じ（勉強）時間では絶対に勝てないから、なるべく時間をかけるように……インプットなりアウトプットなりしていくことで勝てるようにしていくのがいいのかなと思っています。

以上です。ありがとうございました。

（会場拍手）