ホントに「メモ帳」とか「秀丸」とかから始めたんじゃないかなって気がしますね。澤田翔氏(以下、澤田):今はやはりVimが多いです。Emacs派の人がいたら「ごめんなさい」という感じですが。言え、僕もIDEをちゃんと使うようにするというのはやっぱりありますね。今のプログラムはやはりIDEを実装するとかなりいろんなことができるので。Vimスクリプトをバンバン入れている人もたくさんいらっしゃるとは思うんですけど、わりとちゃんとIDEは使いましょうという気はしています。桂:あと、こういう人に聞くと、みんなVimとか言いますけど、ぜんぜんAtomでいいと思うんですね。それは言っておきたい。そんなところでハードルを上げる必要はないし。高場:ちなみに自分はまったくこだわりないので、iOSだったらXcodeだし、Eclipseも使いますし、Vimも使いますけど。EmacsかVimかというのはまったく気にしていない。桂:こだわりはない?高場:作るもの側にこだわりがある感じですね。早くmac版出して欲しい。澤田:僕はRubyMineとかが好きなんですけど。高場:はい、ありがとうございます。質問者3:新規事業の立ち上げをしています。プロジェクト管理とかタスク管理ツールを作りたいなと思っていて、CheddarとかBacklogのようなイメージなんですけど。今開発プロジェクトの中でマネージャー的な立場で携わられているかと思うんですけど、その中で感じている課題があったら教えていただけないかなと。高場:それは開発で感じている課題?質問者3:開発以外でも何かありましたら教えていただきたいです。高場:じゃあ、澤田さんからお願いします。澤田:今Supershipという会社が立ち上がったばかりで、総務とかすごいゴチャゴチャしてるんですけど、我々の立場からすると「なんでエンジニアがやっているような管理ができないのかな」と思って。試しに、総務セクションにGitHubを入れて、「現場でイシューを作って管理してください」と言ったら、なぜかスムーズに(業務が)回るようになって。エンジニアのツールをエンジニアでない人が使うようになるとおもしろいのかなと思っています。GitHubそのものを使うよりは、ソースコードの関係(の機能)は一切使わず、イシューだけ使ってもらっているんですけども。法務文書って普通にワード4ページぐらいですけども、僕らが手がけると1万ページぐらいのソースコードを毎日1行単位でレビューしているような世界なので、そういうエンジニアがやり取りしてきたツールを使うと実はおもしろくなるのかなと思っていて。今、エンジニアの知見を他の仕事に生かせないのかという方向で、タスク管理とかインテグレーションを考えています。質問者3:昔、GitHubのバージョン管理を契約書の管理で使えないかというプロジェクトをやってたんですけど潰れました(笑)。澤田:フロントエンドをちょっと工夫するだけでいけるかも知れませんよね。なんか(Wordっぽく)タイトルバーを青くしとくだけでとりあえず安心するかもしれないので。人類はいつまでチャットツールを作り続けるのか質問者3:というのをやろうとしたのって、エンジニア以外のディレクターやプロデューサーが何か問題を感じているからということですか?澤田:いや、「最新版2015○○日タスク表.xls」みたいなファイルが延々と送られてくるのを見て僕が怒っただけです(笑)。「どれが、最新や」みたいな。高場:あるあるですね。桂さんは?桂:だいたい答え出たかなと思って。プロジェクト管理からしたらツール変わるんだよね。僕らもRedmine使ってたのがJIRAに変わったりとかあるんだけど。結局、人間の間の問題のほうがはるかに大きいから、そこらへんは流行りをつかまえていけば別にいいかなと思っていて。いえ問題がまったくないかと言ったら、さっき言ったようにエンジニアの外とかではあると思うし、人間的なコミュニケーションを支援する何かはまだまだあるかなという気はするけど、(それが)出たからといってそこに頼って、一気に問題解決するということも望んでいないというか。藤本:なんかツールが出ては消え、出ては消えしてる。質問者3:最近チャットツールみたいなの増えてますけど、チャット自体は昔からあったものですよね。藤本:本当にチャットも「人類何年チャット作ってんだろ」ってすごい思うよね。桂:「何回移行するんだ」「何回bot作り直すんだ」みたいな。藤本:CtoCのやつも普通にそうだよね。LINEも日本ではすごい広まって成熟期にはいってるんで、だいたい5年ぐらいで何か次のが出てきたりするよね。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:僕は皆さんと違って、大学に入ってからプログラミングを勉強してて、経験も浅いんですけど。これから勉強する上で、ガンガンコードを書いて後から作り直したほうがいいのか、フレームワークを重ねて設計書通りに作ったほうがいいのか、どっちに力を割けばいいのかなと思って。うまく力をつけて、プログラマーとしてスキルを身につけるためにはどうしたらいいんでしょうか?藤本:これは明確に両方必要です。どっちが先かは、人によって好みが分かれますけど。最初にある程度セオリー学んで試してみるのが向く人もいれば、俺の場合はそういうのが向かなくて、とりあえずやってみて、「なんとなくわかってきたかな」というところでセオリーを学ぶと、「このために、こういう面倒くさいことしてんのね」みたいな話がスッと入ってきたりするし。それはここからの勉強全般そうですね。設計もそうだし、アルゴリズミックな話もそうだし。これからマジメに勉強する話と、試してみるという話が両方出ると思うんですけど、どっちも必要ですね。僕はとりあえず試してから勉強する派です。桂:僕もほぼ一緒ですね。言えば、方法だけを長期間学んでもそんなに身につかないかなと思う。開発手法にしても、本で学ぶのと実際にやってみるのとでは雲泥の差があるので。やってみないと身につかないものが多いとは思うので。逆に、「やってみろ」と言われた時に、方法の勉強を一切しないで何も考えずにやるかというと、それはそれで学びがないと感じるのね。両方の順番がありつつ、それがスパイラルになっていくという感じなんじゃないですかね。澤田:なんか体系的な勉強をしてすごい頑張って、「じゃあ、何か作りましょう」ってことはもちろんできなくはないんですけど、わりとプログラミングって他の業界と違って、作るのを失敗しても人が死なないんですよね。家とか間違えて作ると、崩れたりして住んでいる人が死んじゃうかもしれませんけど。作ってみるのが重要かなと思います。テンションが上がる方法で作っていくと、いつかテンションが上がるフレームワークが必要になるので、そのとき覚えるはずです。何かテンションが上がるようにモノを作ったほうがいいと思います。Dots」の2つを開発した経緯からすると、作りながら考える、「作るファースト」で考える(ことが重要かなと)。試して壊してということをやりながら、(最終的に)綺麗に整えながら作るということです。作るファーストかなと思います。いうところで、以上です。時間的にも終わりというところで、皆さん4人が個別に分かれて話をうかがう時間にしたいと思います。BEATSに関する記事をまとめています。BEATSに関する新着記事が公開された際に、通知を受け取ることができます。