「人類、何年チャット作ってんだろ」 ベンチャー企業のエンジニアが若者の質問に応えて語る

デベロッパーとして好きなエディタは？

質問者2：論争を起こしたいわけじゃないんですけど、デベロッパーとして、好きなエディタは何ですか？

藤本真樹氏（以下、藤本）：これ、またオッサンっぽい話に……。

高場大樹氏（以下、高場）：じゃあ、ベテランから。

藤本：僕はあんまこだわりないです。でも、ターミナルだとvi使うし、iOSのアプリを作る時はXcodeだし、Windowsの時はVisual Studioだったし。何がいいというよりも、その言語とか環境に合ったやつを使う感じがしますね。ただ、やっぱり、XcodeもViモードです。カーソルキーとか使いたくないっす。

で、なぜviかと言うと、これまたオッサントークですけど、大学1年の時にバイトしてて、Solarisがあったんですけど。大学だと「Emacs使え」って言うじゃないですか。それでEmacs立ち上げてたら、10歳ぐらい20歳上の先輩たちに「そんなんでメモリ使うな！」と言われてプロセス切られて。「vi使え、vi」と言われて、それからviになってます。

あと中学の時は、エディタは「MIFES」使ってました。「MIFES」まだあります？　何の参考にもならない話ですが、そんな感じです。

桂大介氏（以下、桂）：僕も普段はVimですね。Vimが基本で。最初は何から始めたかな？　わかんない。ホントに「メモ帳」とか「秀丸」とかから始めたんじゃないかなって気がしますね。

澤田翔氏（以下、澤田）：今はやはりVimが多いです。Emacs派の人がいたら「ごめんなさい」という感じですが。とは言え、僕もIDEをちゃんと使うようにするというのはやっぱりありますね。今のプログラムはやはりIDEを実装するとかなりいろんなことができるので。

もちろんVimスクリプトをバンバン入れている人もたくさんいらっしゃるとは思うんですけど、わりとちゃんとIDEは使いましょうという気はしています。

桂：あと、こういう人に聞くと、みんなVimとか言いますけど、ぜんぜんAtomでいいと思うんですね。それは言っておきたい。そんなところでハードルを上げる必要はないし。

高場：ちなみに自分はまったくこだわりないので、iOSだったらXcodeだし、Eclipseも使いますし、Vimも使いますけど。EmacsかVimかというのはまったく気にしていない。

桂：こだわりはない？

高場：作るもの側にこだわりがある感じですね。

藤本：とりあえずIDE最強はVisual Studioですね。早くmac版出して欲しい。

澤田：僕はRubyMineとかが好きなんですけど。たぶん誰の役にも立たないことを言うと、僕が最初に使ったエディタはVZ Editorです。

プロジェクト管理の中で感じる課題

高場：はい、ありがとうございます。次の質問。

質問者3：新規事業の立ち上げをしています。プロジェクト管理とかタスク管理ツールを作りたいなと思っていて、CheddarとかBacklogのようなイメージなんですけど。

今開発プロジェクトの中でマネージャー的な立場で携わられているかと思うんですけど、その中で感じている課題があったら教えていただけないかなと。

高場：それは開発で感じている課題？

質問者3：開発以外でも何かありましたら教えていただきたいです。

高場：じゃあ、澤田さんからお願いします。

澤田：今Supershipという会社が立ち上がったばかりで、総務とかすごいゴチャゴチャしてるんですけど、我々の立場からすると「なんでエンジニアがやっているような管理ができないのかな」と思って。

試しに、総務セクションにGitHubを入れて、「現場でイシューを作って管理してください」と言ったら、なぜかスムーズに（業務が）回るようになって。だから、エンジニアのツールをエンジニアでない人が使うようになるとおもしろいのかなと思っています。

もちろん、GitHubそのものを使うよりは、ソースコードの関係（の機能）は一切使わず、イシューだけ使ってもらっているんですけども。

例えば、法務文書って普通にワード4ページぐらいですけども、僕らが手がけると1万ページぐらいのソースコードを毎日1行単位でレビューしているような世界なので、そういうエンジニアがやり取りしてきたツールを使うと実はおもしろくなるのかなと思っていて。

わりと今、エンジニアの知見を他の仕事に生かせないのかという方向で、タスク管理とかインテグレーションを考えています。

質問者3：昔、GitHubのバージョン管理を契約書の管理で使えないかというプロジェクトをやってたんですけど潰れました（笑）。

澤田：フロントエンドをちょっと工夫するだけでいけるかも知れませんよね。なんか（Wordっぽく）タイトルバーを青くしとくだけでとりあえず安心するかもしれないので。

人類はいつまでチャットツールを作り続けるのか

質問者3：というのをやろうとしたのって、エンジニア以外のディレクターやプロデューサーが何か問題を感じているからということですか？

澤田：いや、「最新版2015○○日タスク表.xls」みたいなファイルが延々と送られてくるのを見て僕が怒っただけです（笑）。「どれが、最新や」みたいな。

高場：あるあるですね。桂さんは？

桂：だいたい答え出たかなと思って。プロジェクト管理からしたらツール変わるんだよね。もちろん僕らもRedmine使ってたのがJIRAに変わったりとかあるんだけど。結局、人間の間の問題のほうがはるかに大きいから、そこらへんは流行りをつかまえていけば別にいいかなと思っていて。

とはいえ問題がまったくないかと言ったら、さっき言ったようにエンジニアの外とかではあると思うし、人間的なコミュニケーションを支援する何かはまだまだあるかなという気はするけど、（それが）出たからといってそこに頼って、一気に問題解決するということも望んでいないというか。

藤本：なんかツールが出ては消え、出ては消えしてる。

質問者3：最近チャットツールみたいなの増えてますけど、チャット自体は昔からあったものですよね。

藤本：本当にチャットも「人類何年チャット作ってんだろ」ってすごい思うよね。

桂：「何回移行するんだ」「何回bot作り直すんだ」みたいな。

藤本：CtoCのやつも普通にそうだよね。LINEも日本ではすごい広まって成熟期にはいってるんで、だいたい5年ぐらいで何か次のが出てきたりするよね。

MSN Messengerがきて、Skypeがきて、LINEが今ここみたいな。Gitでいえば、僕はGitHubのラージ・オブジェクトのサポートがもうちょっとちゃんとあったら超うれしい。3Dゲームとかだと、1リポジトリで数十、数百ギガとか普通にいくんで。普通にGitの使い方してると辛いですね。

高場：僕が感じているのは、一番の根底にあるのは人間のコミュニケーションがあり、それを助けるためのツールって、トレンドや仕事の仕方によって移り変わりがあるので、どんどん変わっていくのかなと思うんですけど。そのツールとかに引っ張られている感がやっぱりあるなあと思ってて。

「一番何をやりたいんだっけ？」と考えると、やっぱりアウトプットが一番重要で、それを交通整理するためのツールがあるんだけど、それを使ってて気持ちいいとなり過ぎちゃうのが怖いと思ってます。

最近では、SlackもいろんなAPIと連携して、いいツールだと思うんですけど、それを使ってチャットしてたらなんか仕事した気になっちゃうのが課題点かなと。そんなところでよろしいでしょうか？

仕事に打ち込みすぎるのもよくない？

高場：ありがとうございます。それでは、最後の質問ですかね。

質問者4：今日、話を聞いている人たちは20歳前後の人が多いと思うんですけど、僕がまさに22歳なんで質問したいです。

まだ仕事を始めたばかりの人たちに向けて、自分がそれぐらいの歳を振り返った上で、今でもいいんですけど、「こういうマインドで仕事に打ち込んできてよかった」とか、そういうものがあれば教えていただきたいなと思っています。

高場：桂さんは、学生の頃から創業されてって感じですよね。

桂：何だろうなぁ。あんまり打ち込み過ぎなくていいかなと思ってて。

たぶん経営者に話聞くと、100パーセントみんな「仕事に打ち込むと何か得られるよ」って言うんだけども、僕はむしろ「ちゃんと勉強して欲しいな」と思っていて、なんかもうそれに尽きますかね。

そういう意味では、ものすごく勉強して欲しい。なんかWebの技術も複雑化して、どんどん進んでいて、上から下まで知っているベテランが上にいる中で、どんどんキャッチアップが難しくなっていると思ってます。もちろん、別に1年や2年でキャッチアップできるって有り得ると思うんだけど。

たまたまその仕事がつながったらいいんですよ。仕事やってたら成長できる時と、今の状態だと成長できない時って、わりとエンジニアだとわかりやすくあると思うので。

なので、ちゃんとそういう見極め、この仕事だったら自分も成長できるし、100パーセント打ち込んで残業しまくって成長するでもいいし、この仕事はもうあんまり成長見込めないのなら、流して自分の勉強しっかりやるとか、なんかそういうしたたかさを持って欲しいなというぐらいでしょうかね。

藤本：何かあるかな？　僕は人間がけっこう好きじゃなくて、しゃべるのもそんな好きじゃねえし、だから機械が好きなんですけど。それが故に、人にすげえよく思われたいと思い続けているんですよ。人付き合いというか、距離のとり方が苦手な故に、揉めるとすごい自分にコストがかかるんで。

なので、僕はただひたすらにみんなに褒められたいとか、周りの人によく思われたいと思って、そのために、仕事でも他の何でもいいけど、なんかすげえいい人風に頑張るみたいなことをしてきたけど。

そうすると、「なんかコイツ、いろいろできるね」とか、「ウチに来ない？」とか、「こういうのあるよ」とか、いろんな話が転がってくるんで。当然それには実力も大事だったりするけど、なんかいい人っぽく頑張るといいんじゃないですか？

若いうちは時間の濃度を上げるべし

澤田：僕も20歳ぐらいから会社を立ち上げていて、一番思ったことは、自分の時間をちゃんと作ることをもっと頑張ればよかったなと思っていて。

例えば、1日16時間働いて、8時間寝るということはわりとイージーなんですけど、16時間の仕事を8時間に圧縮して同じ成果を維持したまま、8時間分の自分の時間を作るということはより高度であり、本来はそれをしないといけないはずなんですよね。

やはり、若いころは無理が利くので、16時間働いて8時間寝るでも人間とりあえずどうにかなっちゃうんですけど、そうすると「あの時間に他の体験ができなかった」ということが後々響くかもしれない。

あるいは、本当に8時間しか働けない身体になった時に、8時間で仕事が終わらなくなってしまうということが起きると思っていて。やっぱり若いうちにやるべきことは時間をすごく濃くする、濃度を上げるということをすごいやったほうがいいかなと感じてます。

藤本：みんな、とりあえず言ってることがバラバラってことで！

（会場笑）

高場：自分に関しては、なるべく濃い時間を永遠に続けるということをやってましたね。社会人1年目から今日に至るまで死ぬほど働くということをやってました。

なので、皆さんとは違ってちょっとブラックな感じではあるんですけど、僕は、可能な限り働き続ける。ちゃんと自分でここにいれば成長できるという環境で、可能な限りやり続ける。特に目標を何も設定せず、高みだけを、今よりいいという前進だけをこれまでやり続けて来ましたね。

でも会社を作るという目標が一番根底にあって、大きな会社を作りたいみたいな願いがあったので、あんまり「ここまでやったらいい」とかなくて、ひたすらやり続けてきたという感じです。ちょっとブラックな感じですけど。

藤本：ブラックだねぇ。

澤田：たぶん僕がそれやったら、飽きそうな気がする（笑）。まあ考え方はいろいろあります。

CTOは手段であってゴールではない

高場：引き続き質問があれば。

質問者5：皆さん、CTO？

藤本：わりとそうですね。

桂：CTOではないですが、そういう役割は一部やっています。

藤本：桂さん、元々はCTOですか？

桂：僕は違うのよ。うちの会社はCXOがいないので。

質問者5：キャリアプランとしてCTOになるのはすごい難しいと思っていて、だったらスペシャリスト目指したほうがいいのかなって。

藤本：あー、おもしろい。1個あるのは、あんまりCTOを目指してもしょうがないと思う。誰かに「やれ」って言われた時に考えればいいと思う。

桂：ほぼ一緒ですね。ただ、スタートアップだとCTOにまず求められるのは技術力なので、普通のエンジニアとして成長していくのであれば、そういう（CTOになる）機会があればいいし、なければないでいいだろうし。

ただ、自分で創業を目指すのであれば、自分がエンジニアとして、会社の中で従業員としての限界を知り、会社そのものを変えるアクションを持った上で、さらに高みを目指すとか。そういうことができるかどうかが（CTOを目指すかどうかの）1つの判断材料となっていて。

そこも含めてやりたいならCTOを目指せばいい。CTOはぶっちゃけ面倒くさいので、そうでなければ今の会社の中でスペシャリストを目指したほうがいいと思う。

ただ、スペシャリストとしていこうとしても、会社の事業がここまでしかいってなくて、事業が大変な時に自分のスキルがこれ以上上がらないとか。

例えば、アプリを作っているんだけど、アプリを1000人しか使ってくれなくて、100万人規模で使われるアプリのエンジニアリングを学びたいと言っても、スキルを磨いたところで（ユーザーは）100万人にはならないだろうと。

そこで転職するのか、CTOとして（サービスを）そこまで押し上げるのかという判断をしてもいいと思います。会社が好きかどうかですね。

藤本：CTOってだいたい創業した時にエンジニアの1番目だから「CTOね」みたいな。そもそもCTOって何なのかってところもあるし、企業の中のこともあるから。その話はすごい長いんで、興味がある方はまた後ほどまた。

今言われているCTOは本当の意味のCTOじゃなくて、だいたい（他の）エンジニアのマネージャーとエンジニアとしてのスペシャリストを兼ねていて、CTOの仕事には、本来そのどっちでもないんですよ。経営者なんです。

桂：CTOなりたいって人、聞いたことないですか？

藤本：たまにいるけど、「それは手段でゴールじゃない、ってことは理解して」っていうのは思う（笑）。そこじゃねえから！

（会場笑）

「作るファースト」で考える

高場：はい、次の質問にいきましょうか。他に質問ある人。

質問者6：僕は皆さんと違って、大学に入ってからプログラミングを勉強してて、経験も浅いんですけど。これから勉強する上で、ガンガンコードを書いて後から作り直したほうがいいのか、フレームワークを重ねて設計書通りに作ったほうがいいのか、どっちに力を割けばいいのかなと思って。

うまく力をつけて、プログラマーとしてスキルを身につけるためにはどうしたらいいんでしょうか？

藤本：これは明確に両方必要です。どっちが先かは、人によって好みが分かれますけど。最初にある程度セオリー学んで試してみるのが向く人もいれば、俺の場合はそういうのが向かなくて、とりあえずやってみて、「なんとなくわかってきたかな」というところでセオリーを学ぶと、「このために、こういう面倒くさいことしてんのね」みたいな話がスッと入ってきたりするし。なので、両方やりましょう。

ただ、順番がどっちが先かは趣味で決めればいいんじゃないの？　それはここからの勉強全般そうですね。設計もそうだし、アルゴリズミックな話もそうだし。これからマジメに勉強する話と、試してみるという話が両方出ると思うんですけど、どっちも必要ですね。僕はとりあえず試してから勉強する派です。

桂：僕もほぼ一緒ですね。強いて言えば、方法だけを長期間学んでもそんなに身につかないかなと思う。例えば開発手法にしても、本で学ぶのと実際にやってみるのとでは雲泥の差があるので。やっぱり、やってみないと身につかないものが多いとは思うので。

ただ逆に、「やってみろ」と言われた時に、方法の勉強を一切しないで何も考えずにやるかというと、それはそれで学びがないと感じるのね。だから両方の順番がありつつ、それがスパイラルになっていくという感じなんじゃないですかね。

澤田：なんか体系的な勉強をしてすごい頑張って、「じゃあ、何か作りましょう」ってことはもちろんできなくはないんですけど、わりとプログラミングって他の業界と違って、作るのを失敗しても人が死なないんですよね。家とか間違えて作ると、崩れたりして住んでいる人が死んじゃうかもしれませんけど。

なので、とりあえず作ってみるのが重要かなと思います。テンションが上がる方法で作っていくと、いつかテンションが上がるフレームワークが必要になるので、そのとき覚えるはずです。まずは、何かテンションが上がるようにモノを作ったほうがいいと思います。

高場：ちなみに、自分の場合も皆さんと同じく両方大切だと思うんですけど、「Brain Wars」と「Brain Dots」の2つを開発した経緯からすると、作りながら考える、「作るファースト」で考える（ことが重要かなと）。試して壊してということをやりながら、（最終的に）綺麗に整えながら作るということです。なので、ちょっと作るファーストかなと思います。

というところで、以上です。

そろそろ、時間的にも終わりというところで、皆さん4人が個別に分かれて話をうかがう時間にしたいと思います。