「エンジニアの未来サミット 0905」私的不完全議事録
5/23 に秋葉原で行われた、「エンジニアの未来サミット 0905 エンジニア・サバイバル」の私的な議事録です。前回同様、パネラーの発言と会場からの質問をできるだけ記録しました。ただし、言い回しは完全に再現していませんし、後から記憶で補完した発言、拾えなかった発言もあります。もし明らかな間違いにお気づきの方は、コメント欄かブクマコメントでお知らせください。
【第一部】おしえて! アルファギーク─エンジニアが幸せになる方法
吉岡 自己紹介と人生の転機をお話しいただきたいと思います。まず私から。今年で 51 歳。(会場に)25 歳以下の人?──1/3 くらい? 30 以下は? いや、10 進法で(会場笑い)。エンジニアの方は? ──やっぱりほとんどですね。パネラーの方、こうひう人たちに向かってお話しいただければ。
私は最年長で、IT 産業のパラダイムシフトを実体験として見てきたので、そういうスタンスでお話しできれば。私の最初の会社は DEC でした。大学ではソフトウェアを勉強していたので、ソフトを作りたかった。就職先を探していたときにたまたま米国の DEC を見つけ、そこへ入った。当時ソフトを作りたければハードベンダに入るのが王道だった。MS も小さかったし、日本法人もなかった(ASCII が代理店)。94 年にオラクルに転職した。90 年代は MS もオラクルも大きくなり、ソフトを作りたい学生はハードベンダではなく外資系のソフトベンダに行く人も増えてきた。98 年だったかにネットスケープがソースを公開した頃からオープンソースが流行ってきた。2000 年にミラクルリナックスを設立し、それ以降オープンソースの世界に関わってきています。オープンソースのことも今日触れて行ければと思う。
谷口 ライブドアの谷口です。ネット上では「にぽたん」。前回はスーツ姿に学生さんがウケていたので、今日はスーツコスプレで。よしおかさんは言うなれば王道をたどって来た方だが、私は「パソコンってなぁに」っていう業界で働いてきた。今後 IT が流行るんじゃないかと思ってこっちに来た。ちょっと毛色の違う、茨の道をたどってきた人として話します。
楠 ここでは一人だけコードを書く仕事ではない人かな。ライターをやっていたが、食えないと思った。IT が面白そうだと思ってこっちに来た。ビクターの子会社で働いてきたときに MS の人に「受けたいんですけど」と相談したら「中途で受けたほうがいい」と言われ、26 で MS に入った。
ひが 会社のプロダクトを作るためにコードを書いているのではなく、好きなことをやっていいよと言われてコードを書いている。Google の 20% ルールは有名だが、私は 100% 好きなことをやっていいという恵まれた立場。と言っても入社時からそうだったわけではない。SIer というネガティブに見られるところに入社時からいる。よい面も負の面も知っている。SIer では管理職だが、私は管理は苦手でうだつの上がらない人間だった。数年前にオープンソースを始めて自分の進む道だと思った。
吉岡 全員違う歩み方をしていると思う。会場から事前に質問を受けたのだが、人生に正解はないので、正解を期待してもらっては困る。ひとつひとつの事例を参考に、すてきだと思ったら真似してみてほしい。弾さんを真似しようと思っても真似できっこない。事例を積み上げるという意味でお話しいただければ。
私は基盤系(OS や RDBMS)などをやってきた。入社後初めてのプロジェクトが、日本語 COBOL プリプロセッサの開発だった。その時エンジニアやプログラマのイロハを会社で教えてもらった。COBOL のスペックが電話帳くらいの厚みの本で、それを見てひとつひとつ作って行った。その中でバグ潰しやコードビルドシステム、テストなどのベストプラクティスを最初から叩き込まれた。ハードベンダから転職するきっかけは、DEC が 90 年代になって時代の波に乗り遅れて大赤字を出して、会社が左前になり、たまたまオラクルに友達がいて、飲みに行ったら「ウチに来ない?」と言われて転職した。たまたま行ったところ、米国本社で RDBMS エンジンを書く仕事を募集していてそこへ行った。ネットスケープが「ソースを公開する」というクレイジーな革命をやった。その後、もう一波来て、Linux、Apache、MySQL など、基盤コンポーネントは全部と言っていいほどオープンソースになった。その意味で言うと、基盤のソフトを開発したければ、今では家で、自分の意思さえあればできる。コードを読み、パッチを作り、メーリングリストに投げ……とできる。シリコンバレーに出稼ぎに行かなければできなかったことが、今は自分の意思さえあればできる。これはすごいこと。履歴書に「Perl のモジュールを作った」と自分の意志で書ける。Ruby のメーリングリストなんて日々日本語でやりとりされているので、英語が読めなくても自分の意思さえあれば自分のパソコンでパッチを作ることができる。そういう観点から、自分のキャリアを自分で設計できる。
その辺の話、人生の転機について、それぞれお話しいただければ。
ひが よしおかさんに聞きたいのだが、王道を歩まれたよしおかさんのようなエンジニアから見て、当時と今のエンジニアライフはどちらが幸せに見えるか。
吉岡 比較はできない。私が今 25 くらいで観客席にいたら、間違いなくオープンソースを選ぶ。
ひが チャンスという意味では。
吉岡 オープンソースのほうがチャンスがある。例えば VAX というミニコンがあって、設計者は社内にいる。憧れの技術者像はみんな社内にある。垂直統合型のビジネスモデルから水平統合型に変わって、オープンソースの世界になると世界中にいるようになった。その世界中の人たちにアクセスできる。DEC のエンジニアにアクセスするには DEC に行くしかなかった。いい時代になったと思う。
ひが ライブドアにもスターがいるが、実際に働いていてどんな感じ?
谷口 よしおかさんが現役バリバリの時代のように社内に全員すごい人が揃っているという時代ではない。ライブドアは自社でデータセンターを抱えていたし、かつての弾さんのように優秀な人材が集まってくる環境があるので、社内に目指すべき人がたくさんいたし、今でもいる。今そういう環境に自分たちがいるが、最初は社外の人ですごい人は誰かと考えたときに、当時は Google がなかったのでロボット型のサーチエンジンを使って調べていくうちに Shibuya.pm というハッカーの集まりが……2001 年くらいに参加して、代々木で 30 人くらいで集まったのだが、オン・ザ・エッヂのエンジニアが盛んに活動をしていた。小さい会社で地道に働いていた自分はそういう世界を知らなかった。オン・ザ・エッヂの人はすごい、こういう人と働きたいと思ったのが入社のきっかけ。でも実力が伴わない。例えば宮川(達彦)さんと話していて、「この人すごいな」と思う。自分がステップアップして行くためのロールモデルが宮川さんだった。CPAN のモジュールを宮川さんはたくさん登録しているので、自分も CPAN のモジュールを作った。
吉岡 (宮川さんが) Six Apart に転職するときに CPAN モジュールのリストを見せたら次の日に声を掛けられたという伝説(suno88 注: 「ITpro Challenge! 2008 (+ 非公式懇親会) 雑感」参照)があるが。
谷口 宮川さんみたいになりたいと思った。こんな茨の道をたどってきた人間でも偉くはなれる。そういう意味でライブドアは恵まれている。今は自社に目指すべき人がいないというのがほとんどだと思う。私が Shibuya.pm に参加したときは勉強会がほとんどなかったが、今では勉強会の勉強会があるほど機会がある。若い人にはチャンスがたくさんある。
楠 僕はもともとオープンソース自体をやっていたのは 98 年くらい。IPv6 を使えるように RedHat を上書きするパッチを書いていた。当時 IPv6 を流行らせようとは思っていたが、どうしても IPv6 でないと、というのがなかった。IP モビリティとアドホックネットワークがバラバラだったので、ちゃんとした仕組みを作れないかと思ってプロジェクトを立ち上げた。でも調べるとコードで解決する問題ではなく、無線 LAN の周波数が足りないということが分かった。転職した理由は、2005 年くらいは MS もオープンソースコミュニティとの関りを変えて行く時期だったので、そこが興味深くて飛び込んで行った。ここ 5 年はどうやってオープンな世界でキャッチアップしてゆくかという点で面白かった。
吉岡 デジュール標準はネクタイを締めた人が会議室で作る。オープンソースの標準は、メーリングリストなどでコンセンサスを作って RFC になる。いい RFC は複数の実装ができる。標準を作るのもさっきのハードベンダの話に似ていて、世界中で使われている標準は RFC で規定していたり、メールの RFC は 90 年代に村井(純)さんが作ったのがいまだに使われている。使わなければならないという強制力はないが、みんな使っている。組織のあり方も相対的に変わってきているのかな、と。でも電波の割り当てなどは国が握っているので、組織の力も必要。──こんな話でいいんですかね。会場がシーンとしているけど。
こういう話が人生の役に立つかというと立たないんだけど、組織と個人、組織と社会の関わりを考えてほしい。
(会場に向かって)ブログを持っている人? ──ほとんど持ってますね。25 年前では考えられない。じゃあ、勉強会に行ったことのある人? ──いっぱいいますね。じゃあ、ブログと勉強会で 2 つの武器を手に入れてるね。
じゃあ、「ひがやすを飲み会」に参加したことある人? ──さすがにこれは少ないね。ブログの話を、ひがさん?
ひが 私はブログを書くのはキライです。(会場に向かって)私が好きでブログを書いていると思う人? ──結構いますね。でも本や文章を書くのが昔から苦手で、本を書いたあとは「二度と書くもんか」と思う。書いているときはつらいけれど、書いた後に「面白かった」「ためになった」と言われると、また書こうと思う。
吉岡 オープンソースもいやいややってる?
ひが コードを書くのも好きじゃない。人のためにやっている。Seasar を 2003 年からやっているが、作りたくて作ったのではなく、(スターロジックの)羽生さんに「軽いアプリケーションサーバを作ってよ」と言われて書いた。
谷口 僕は月に一本書くか書かないか。ブックマークされるネタしか書かない主義(会場笑い)。
楠 去年くらいまでブログと仕事を分けていたのだが、最近名前を明かした。よいことは、情報を発信すると、間違いを直してくれる人がいる。間違えた認識のままでいるほうが恐い。去年で言うとインターネット規制のような話になったときに、早くブログに書けば、自分が書いた点が取り上げられていつの間にか直っているということもある。
吉岡 法律も、我々は書けるといえば書ける。書き方も通し方も知らないけど。そういう考え方があるというのはすごい。条文ひとつひとつに魂があり、誰かが作っている。私と同じ、人が作っている。楠さんのブログでそういう発見があって、そういうブログの使い方があるのか、と。ある意味でハック。コードは書いていないけれどハッキングしている。
楠 ソフト開発の現場で起こっていることも社会で起こっていることも似ている。どうやってズレを擦り合わせながら解いて行くのか、ソフト開発で直面した矛盾、乗り越え方は、社会や政治の世界でも生かされる。ソフトの世界のバグデータベースのようなものがない世界。C のコーディングスタイルのような本のように、法律の書き方の本というものもあり、本屋や役所の地下で買える。
吉岡 法律は究極のオープンソースですよね。コピーしてもいいし、ブログに上げてもいい。実装も社会で実装しているし、直したければ直せる。
楠 ひとつ違うのは、Linux カーネルであれば Git で履歴をたどったり、メーリングリストのログを見たりして「どうやって決まったのか」は分かるが、法律は国会の議事録を読んでも分からない。まだオープン化されていない部分もたくさんある。アメリカではオバマ大統領がいろいろオープンにしようといろいろ仕組みを作っているので、IT の世界で 10 年かけてやってきたことが法律の世界で起こるかも。
吉岡 議員もブログを持っていて「○○委員会に出た」とか情報発信をしている。プロセスを公開しているという面では素敵な話。──なんでこんな話になったんですかね。
いちおう一巡して……。
ひが 私はあまりしゃべっていない気が(会場笑い)。伝えたいメッセージがあって……最初 SIer に行ったときには評価されなかった。上に上がる局面があって、98 年くらいに 7 割が上がれるという時に私は上がれなかった。下 3 割だった。自分の評価は気にしなかったのだが、実際に上司の評価が分かる局面では下 30% の評価しかなかったと愕然とした。それからは、自分に合っていることをしないと認められないと思った。このままでは評価されないと思い、Seasar を作ってみて、それがうまくいった。その後、作ったものをオープンソースとして公開したのが Seasar 1。外の人とやったり、自分の作ったものを人に使ってもらうのが合っていた。それで 100% ルールという恵まれた立場になったが、これはスキルとのマッチングだと思う。仕事では得意な所を生かして行かないといけない。自分に何が向いているか分からない人は、いろんなチャンスがあるんだと思ってトライすると、自分にあったことができるんじゃないかと思う。
吉岡 自分の人生の転機は?
谷口 転機は意識したことがない。ドラスティックに自分の人生が変わったことは意識してないが、ライブドア入社や Shibuya.pm など。SI でも何でもない他業界の社内システムをやっていたが、すごくゆるゆるの会社だった。ぬるま湯だった。居心地はよかった。給料も悪くないし。でも自分に合っているのってこれじゃないと思った。アルファギークのブログを読んでもサッパリだった。今でも memcached の記事にはブクマがつくが、そういうことをやりたい、そういう環境に身を置きたいと思っている人が多いのだろう。転職先で提示された月給が現職から 11 万減だったが、やりたかったので転職した。そしたら毎日終電間際や途中の駅までしか帰れない、でもタクシーには乗れないので歩いて帰るとか。でも楽しくてしょうがなかった。風呂に入れず臭かったし、カッコイイとは思わなかったが、楽しいからやれた。
吉岡 情報発信している人に吸い寄せられるということはあるね。
谷口 知らない人のところへ行きたいとは思わない。
吉岡 情報発信はいいことだね。学生の就職活動だけではないいろいろな方法があるのはいい。ネットでブラックな所は分かる。インターネットのおかげでいい面も悪い面も分かる。情報が非対称的になってきた。
会場から質問を──。
谷口 質問しないと、よしおかさんに「質問力がない」って言われますよ。
質問者 1 エンジニアとしては会社に依存するより個人の価値観や技術を磨いてゆくという話がメインとなっているが、会社に所属して働いている人のほうが多いと思う。正解がないのは承知の上で、これから業界がどうなっていくか聞きたい。(1)私はトム・デマルコの信者で、『ピープルウェア』が 20 年前の古典になったが、現状はまだ追いついていない。労働環境はどうなっていくのか。(2)偽装請負、サービス残業などのコンプライアンスの問題は。特に中小企業は。(3)SIer の上流と下流の格差はどうなる。(4)鬱を始めとするメンタルヘルスの問題、IT になぜ多いのか。これからはどうなるのか。
吉岡 具体的で難しい質問。
ひが SIer の話。上流・下流どちらかだけの人はダメだと思う。どっちも重要で、偉い偉くないというのはないが、上流だけの人は実装がイメージできないので、作っているときにあやふやなことがあっても「いいや、実装で考えれば」と先延ばしにする。実装を知らない人の設計書はダメ。逆もまた然り。どういう意図でこういう設計なのかを分からずに作ると、お客さまの欲しかったものとは違うものができる。両方やるのがいいと思う。上流と下流と分かれているのが効率が悪い。部分的なところしか見ない。だいたいが結合テストで動かず、大量に人を投入して動くようにするが、それは分業しているから。上流から下流まで全部ひとつの会社でできるほうがコストも低く、いいものが作れる。下請けに丸投げという SIer は今後苦しくなるだろう。
吉岡 受託開発は SI 的だと思うけれど、製品・サービスは上流も下流もない。実装する人がスペックを書き、スペックを書く人がテストする。
楠 5 年くらい前だと 7・8 次請けなんてのもあったが、最近は減っている。コンプライアンス遵守で契約を変えている。また最近は(悪い)内部情報が出ていっていい人を取りづらくなるので、改善されていると思う。
吉岡 ブラックな情報もホワイトな情報も流れることで、淘汰が始まると思う。
谷口 メンタルヘルスが問題だと思う。4 つの質問は何かしら関連がある。自分も一時期ヤバいんじゃないかと思って、utsu.jp で自己診断したら「どう見ても鬱です。本当に(ry」ということもあった。受託で二次請けになると、要件に合わせるために生活や人間を犠牲にしないといけない。そういう部署で働くのがイヤで「辞めます」と言ったら異動できた。この業界はサービス残業している人が多いと思うが、自分で動き出せない、空気を読んじゃうのは国民性か。その国民性をいいように利用している会社がほとんどではないか。近い将来、変わって行かないといけない。自分も部下を持っていると、落ち込んで悩んで自分でコントロールできない。マネジメント層が精神を病んでいる人の扱いを知らない。業界が変わるか、マネジメント層がうまくできるようになるか、自分が逃れるか、どれかしかない。メンタルヘルスカンファレンスみたいなものをやりたい。
吉岡 マネジメントの人は今日はあまりいないようだが、プログラムとマネジメントは違う技術がある。経営もまさにそう。人間をどうやって管理するかという点が形式知として流通していないのが問題。『ピープルウェア』などを 20 年くらい前に読んで、ソフト産業はまさにピープルウェアだと思った。北風と太陽では太陽が人を動かすと思う。『Debug Hacks』という本のプロジェクトが面白かった。ミラクルリナックスのエンジニア 5 人で書いたのだが、週に一回原稿を持ち寄って議論した。去年 6 月に出版社が決まって、7 月に契約が決まって、とスケジュール管理があり、少しずつ原稿を溜めていく。ソースは Git で管理。そういうところで何をモチベーションにするかと言うと、人のやる気をキープして行く。波の中でコントロールして行く必要があるのかなと思った。
繰り返しになるが、会社として意識して人をこき使うというのはあまりないと思う。結果として、上司がうまくないとか、部署がうまくいってないというのはあるが、うまくいかないことを設計してそうなることはないはず。
楠 確率論的に見積もりは間違うものだと思う。発注者と受注者で不確定性を共有できないといけない。人の生活を大事にして行けるような仕事のやり方や商慣行が広まって行ければいいと思う。
吉岡 プロジェクト開始時に全部明文化できるかというと、そうではない。
楠 プロジェクトを variable とするか、人の生活を variable とするか。現状は後者だ。
吉岡 サービスは自分の意志でコントロールできる範囲が広いが、SI はお客さんの部分は変えられないのがアレかなぁ。
そろそろ、エンジニアの未来、IT の未来という話を。さっきの質問にもあったが、今後どういう業界になっていくか。
ひが 未来は分からないが、近い未来はある程度の想定はできる。クラウドは Google や Amazon が頑張ってきて、バズワードからビジネスの世界に近づいてきた。すると、SIer みたいなところが非効率なやり方で何かを作るのが向かなくなる。サクッと作って客がついてきたらスケールする。クラウドの世界が広がるにつれ、受託開発が減ってゆく。
楠 クラウドはバズワードではなくなってきていると思う。
吉岡 霞ヶ関あたりではバズワード。クラウドとグリーン IT で何十億円、みたいな。
楠 私も研究会にいるので話しづらいが(会場笑い)、自治体では古いコンピュータがたくさん残っている。自治体が変わると情報交換できないとか。そこへクラウドが入って行くと、独自規格がオープンになっていく。悪い話ではない。
吉岡 ハードにいくら予算を使うとか、悪い話になっていきがち。政治レイヤを見て行かないといけない。
楠 国が作ったからみんなが使わなければいけないという話ではない。どうやってプライバシーを確保するか、犯罪が起こったときに踏み込めるのか、という話を考えて行かないといけない。
クラウドの議論では「SI はなくなるのか」という話が出るが、SI も受託もなくならないと思う。人と会社、組織とシステムの仲立ちをする仕事はなくならない。受託は、プログラマのキャリアパスの問題を解決してゆかない限り、そう簡単にはなくならないだろう。
吉岡 ほとんどの業務がパッケージでできて、ある種のカスタマイズは残るが、経営のベストプラクティスが確立してゆけば受託は減っていくと思うが。
楠 自社でも ERP の SAP を使っているが、日米でパッケージの受け入れられ方が違う。基幹システムと業務を連携させるには周辺ツールがたくさんいる。パッケージがカバーしている部分と実際の業務のグルーはたくさんあり、それらを作ることで業務の効率化はできる。そういう受託開発は残る。でも昔のように一から手組みするのは減ると思う。
吉岡 大きな会社は IT 部門があるのでそうだと思うが、小さな会社ではそうではないし、高いお金を出して自社開発するのも難しいし、パッケージを買って経理を回したりするのかなぁと思う。
谷口 そんなに急激に業界が変わるとは思わないが、心を病んでまで働く業界なのかなぁと。ある程度淘汰されてゆく気はする。ブラックと呼ばれているところでは何がモチベーションなのか、未来はあるのか。ないと思う。会社に未来がなくても、エンジニアには未来がある。働きにくい環境が淘汰され、統廃合が起こるのでは。最初に Shibuya.pm に出たときは 1 ヶ月でようやく 30 人の枠が埋まったが、今では 200 人が 1 日で埋まる。エンジニアは増えてきている。IT 業界サバイバルが始まっている気がする。名前も知らなかった会社がポッと出てすごくなることもある。面白そうなサービスを出せば、1 日で数千万ページビューも。そういうノウハウがなかった頃、手探りのノウハウを公開したから現状がある。イニシャルの加速性がいいので、今後ポンと会社が出たり、今まで持っていた会社が消えて行くことがある。
吉岡 私は基盤の下のほうが好き。ライブドアもそうだが、基盤をやる会社が東京にはある。カーネル読書会も最初は 30 人くらい、今では 50 人くらいが 1 日で来る。カーネルなんて読んで面白いか、と思うのだが、やってみると、仕事でないのに楽しみで来る人がいる。
ミクシィのバタラさんの話を聞いて「ありえねぇだろう」と思った。RDBMS の使い方としては言語道断だ、と思う。ミクシィも気がつけば 10 万ユーザ、SQL ではいつまで経っても終わらない、なので MySQL のテーブルを分割してみたりと苦労していると、全然関係ない人が memcached を教えてくれる。気がつけば全部 OSS で回している。それを回しているのは基盤系の技術で、その会社の強みになっている。OSS のハッカーは社外にいる。MySQL の神、Perl の神は外にいる。でもそれを自社サービスの根幹に据えているというのは、20 年前の垂直統合とは違う。外側にロールモデルがある。MySQL や PostgreSQL の神の姿を見ながらコードを書く。技術は会社のものではなくコミュニティのものだと思えればブルーオーシャンだ。「ウチの OS」「ウチの RDBMS」は、会社がなくなったら全部消える。オープンソースなら、会社で培った技術はポータブル。クラウドというバズワードだったとしても、ほかで使える技術基盤だと思う。例えば RDBMS は 30 年前に IBM で研究されて数兆円産業になったが、そこで使われている技術はそんなに変わっていない。トランザクションという概念のベースも、OS やコンパイラの作りも変わっていない。ある程度必死にやっていれば、その分野の第一人者にはなれる。
ひが 今はチャンスが起きている。RDBMS は 30 年くらい同じ技術が使われていて成熟しているが、クラウドの Key-Value の考えは上の人たちにノウハウはない。皆一直線上に並んでいる。非常にチャンス。上の人がつかえていて第一人者を超えられないことは多いが、今の Key-Value ストア系の技術は誰もノウハウがないので、自分がノウハウを溜めれば自分がトップになれるかもしれない。若い人であればあるほど捨てるものがないのだから、新しいもので勝負するのも面白いと思う。
谷口 元ミクシィのバタラさんがカーネル読書会で発表していたときに私もいた。Gree の藤本さんもいた。「ああ、みんなやってることは同じなんだな」と思った。技術評論社の「Web+DB Press」で memcached の動くコードが誌面に載ったが、今ではすでに陳腐化している。ちょっと前まで最先端だった人がすぐに追い抜かれる。自分は後追いだというネガティブな気持ちは持たないでほしい。第一人者になるのが比較的容易になってきた。
吉岡 個別のサービスを作っている会社が東京にたくさんある。そういう人たちと飲みに行くが、みな真面目。酒を飲みながら議論が始まったり。
質問者 2 今日の話は現実に即しているが、この会場の中から 10 年後、20 年後にこんな技術者が出てきてほしい、そのためには何をすればいいのかという話を。
谷口 世界に名だたる「スーパーハッカーカッコワライ」みたいな人を望む。技術的に抜かれる人の恐怖は昔はあったが、今は利用する側として面白いと思う。東京は技術力が集約した街。どんどんいろんなことに挑戦して行ってほしい。
楠 幸せなエンジニアが増えて、ロールモデルになっていくと、周囲に幸せを分けてゆける。うらやましがられるエンジニアになってほしい。これから人口も減るし、景気も悪いが、大きな変化は見通しの悪い時代に出てくる。方向を見失っている部分もある時代なので、切り開いて行ってほしい。
ひが 「もう日本は立ち直れない、だからシリコンバレーに行くべきだ」ということを海外から言う人をギャフンと言わせるようなエンジニアになってほしい(会場笑い)。
吉岡 あれ、ちょっとイラッときたよね。
ひが 日本も世界に発信できるんだよという人になってほしい。
吉岡 あの人の周りにはダメな人が多いんだよ。日本に帰ってきたときには(彼女の周囲の人が)景気の悪いことを言うんだよ。すごい人はいっぱいいるんだけど、そういう人にリーチできてない。しょうがないんだけど、半径 5m 以内に景気のいい人がいない。東京はすごい。そういう人たちと日本語で会話できれば嬉しい。輸入するんじゃなくて、自分たちで作るんだ、みたいな社会になれば嬉しいなと思っていたが、そうなっちゃった。今の東京はそういう場所。
楠 おっしゃるとおりで、東京にいるメリットは大きい。シリコンバレーはベンチャーしかない街。東京は文化も政治もある。かつて Blaster ウィルスが流行って、100 万台被害が出た。パッチ CD を作るという決断を MS 日本法人は数日でできた。Redmont ではワシントンもニューヨークも遠いので、決断が遅い。東京の俊敏さは武器になるし、それを価値にして打って出ることを考えてよい。
どっしり腰を据えて考えるのは、ノイズが多い東京より地方のほうがいい。シリコンバレーはインドや中国とやりあっているが、日本は日本に閉じこもっているので出遅れてしまうのではと思う。
吉岡 実は地方も始まっている。札幌や福岡、島根も元気だけど、中核都市に勉強会ができてきている。人口規模は東京の 1/10 くらいだけど、彼らもアツいことをやっている。人数が少ない分、横串の通し方が小都市だと東京と違う。そういう中心となっている人は足腰が軽いので東京に出てきたり、勉強会ネットワークができている。
質問者 3 日本電子専門学校の学生で、来年は SIer に就職することになっている。ここ 2 年ほど、IPA フォーラムを感じて、学生とパネラーの間のすれ違いがある。今自分が学んでいるのは何のためと聞いて、パネラーが「資格手当をもらえるよ」とか言って(会場笑い)。この二極化された状況はなぜか、今後変わって行くのか。それと、情報系の学校の存在意義や、学生は何をすべきなのか。
吉岡 日本の大手でエラくなっちゃう人は、失敗をしない人。会社の構造があるんじゃないかな。こういう所に来ている感度の高い人は、そういう言葉にダマされないよね。生の情報をいっぱい仕入れて、SI も変わるんだって分かれば、じゃあ準備できるじゃない。一方で、社会制度として資格が必要であるのは事実。今後、大企業で SI で、というのもある。Suica をベンチャーが作れるかというと、それはできない。基盤システムは残るし必要。送電システムはベンチャーには作れない。そういう社会基盤を作る会社も必要だし、ベンチャーがステキな Web システムを作るのも必要。
谷口 IPA フォーラムの雰囲気は知らないが、資格はあまり気にしなくてもいいのでは。面接者の中には資格マニアみたいな人もいるが、参考程度にしかしない。専門学校や高専を出た人で、社会に出た途端に伸びる人もいるので、私は評価している。
楠 資格はなくてもいいんじゃないとも思うが、大学で教えている立場として、何を目指せばいい、どう頑張ればいいというのを教えるのが大切。何を目指すかを考える材料が少な過ぎる。業界は広いので、資格で足切りしていかないと技術のミスマッチが起こる。そういう世界があるのは知っておいたほうがいい。自分が行こうとしている世界に興味を持って、生の情報に触れ、自分が何を信じて行くかを考えていくといい。
ひが IPA のフォーラムは、老害はどういうものかを知る場所(会場笑い)。
吉岡 今日のまとめをブログに書いてほしい。よしおかさんばかりしゃべってたー、とか。感想を書いて行けば、それがゆるい輪っかになっていける。自分ができることをやって行けば未来は明るい。ブログに感想をいっぱい書いてくれれば私は絶対に読みます。
谷口 前回全然しゃべれなかったのもあるし(会場笑い)、マッチョっぽい話題についていけなかったのを「残糞感」と表現したが、今日はちゃんと出し切れた。私もまだ学ぶ立場だと思うので、感想をよろしくお願いします。
楠 この 2 時間の議論はきっかけにすぎない。IT は数年で技術が移り変わってゆくし、会社はひとりの人生を面倒見るようにはなっていない。5 年もすれば景気も変わる。ひとつは生のものを見ること、何がconfortable なのか自分を知ることで、自分を模索していってほしい。
ひが モデレータになるとみんなマイクを離さないんだなぁと(会場笑い)。自分が伝えたかったことが伝わったか、ブログに書いてほしい。
吉岡 結論はないんですが、楽しんでいただけたでしょうか。何かのヒントになれば。今日はこんなに集まっていただき、ありがとうございました。
第一部終了後の休憩中
前回は上京して参加したけれど、今回は諸般の事情により上京できなかったので、長野の自宅から Ustream で見ました。
【第二部】弾 vs. 個性派エンジニア ─サバイバル討論
馮 自己紹介を。
山崎 第一部は高尚というか真面目というか。第一部はフォーマル、第二部はカジュアルという感じで。プログラマは 5 年で、サーバエンジニアのほうが長い。トラブル対応のほうが楽しい。
高井 今 30 歳。ウェブ系の開発をやってて、Ruby や Java を細々やってます。
閑歳 ちっちゃいベンチャーで働いてます。出版社に 3 年いました。ウェブサービスを作るのが好きで、友人に誘われてこの業界へ。ディレクションから開発に移ってきた。変わった経歴が参考になればと思います。
井上 ミクシィから来ました。広島出身、1985 年生まれの 23 歳、去年新卒でミクシィへ。津山高専出身。未踏ユースを受けて、そのご縁でミクシィへ。ハードとソフトの融合なども好きで、萌えるコーヒーメーカーとか。
米林 コンピュータ業界の勉強をしてこの業界に入ったのではなく、別業界から来る人にメッセージを送れたら。
小飼 ぐぐるか Wikipedia を見て。目の前にあるものには何でも興味を持っちゃう。
馮 最初のテーマは「エンジニアのスキルとは」。
井上 面白いと思うのは、自分でプロモーションするエンジニア。面白いなと思うものを勉強会でエンターテインメントとして伝えるエンジニア。これから求められていると思う。
小飼 えがいひと?
井上 えがいのはどうかと思いますが……。
高井 売名行為も重要だと思う。アウトプットだから。
山崎 ポリシーは人それぞれでいい。発言力、影響力は、ないよりあったほうがいい。自分の正しいことをやるためにはそれなりの力はあったほうがいい。交渉力、コミュニケーション力があったほうが信念を守りやすい。
井上 面白いものは誰かに伝わってこそ。
馮 自分で作ったことを見せるときに気にしていることは。
閑歳 完成させてフツーの人に使ってもらえるレベルにはしようと思う。一般人でも楽しんでもらえるものを作れば利用者が増える。見た目重要。デザインを誉められることが多い。使い勝手とか。
井上 弾さんの言う「キモさ」(一人で作って誰にも見せずにニヤニヤ笑って自己満足)がなくてもできればいいと思う。コミュニケーションが取れるエンジニアが重要だと思う。自分で満足しているエンジニアにはあまり価値がないかな。
小飼 誰に作っているか。一般の人に使ってもらうのか、エンジニアに使ってもらうのか。僕のプロダクトは 8 割後者。
山崎 トラブルを解決して助かったと言われるのもカタルシス。日々正常に保つことに賭けている人もいるはず。
高井 会場で運用系の人? ──少ないね。ウェブ系の人──は半々くらい。
井上 学生のときは受託で書いてた。学生のほうが儲かってた(笑)。
馮 技術力はどうやって身につけたか。時代の変遷もあるが。勉強会は?
山崎 勉強会がたくさんあるのを先週まで知らなかった。僕はトラブルのときが一番経験値がつくと思う。トラブル時の 1 分は平時の 1 ヶ月に匹敵する。リリース後にバグが見つかったときに 10 分で解決したが、平時なら 1 日分、2 日分の線を引かれるだろう。
高井 のめり込む時間は重要。寝食忘れるって言うけど、そういうのは大事。
馮 勉強会のメリットは。
井上 発表を聞くのも楽しみだが、情報を整理したりネタを用意したりすることで経験値が上がる。アウトプットの場だと思う。
山崎 トラブルと通じるものがある。
小飼 勉強会に出るのを会社に差し止められてるという愚痴をブログでよく見る。
井上 ウチの会社に関しては「行け行け」と言ってくれるが、他の会社では……。
高井 逆に会社だからこそできることもある。すごく高いマシンを触れるとか、ベンダー系教育の機会とか。
閑歳 大学 1 年のときにお金がなくて、アルバイト情報誌で Perl を教える仕事に応募した。そこからプログラムを 1 週間で学んだ。乗り越えたのはそこだと思う。仕事をするようになってからは、HTML や CSS をいじるところから入った。社内のできるエンジニアのソースを読んで覚えていった。あとはトラブルのときに最初は部下の作業を見守っていたのだが、自分でやるのが早いということでやるようになった。
山崎 責任感が強い、逃げない人は身につく。
高井 マッチョになってきましたね(笑)。
閑歳 ウソでもいいから「できます」と言うと、できるようになっちゃう。
山崎 社内で「こんなんできました」と言い続けていると「この人すごいんだ」となって期待が高まる。
高井 基礎体力(プロトコルの理解など)は避けちゃダメ。
馮 基礎体力はどうやって身につけたか。
米林 バスケットボールですね。冗談ですが、一週間で Perl を覚えるなんて、私はムリだと思う。地頭の違い。私はバカだったので、ひたすら本を読んで手を動かした。私は継続が大事だと思う。勉強の過程をブログに書いても、1 年 2 年できる人はすくないと思う。
小飼 バスケもそれでうまくなった?
米林 16 年くらいやったけど、あんまりうまくない。
馮 本を読む? ネット? 人に聞く?
高井 技術評論社の本とか……(会場笑いと拍手)。でも書籍は大切。体系的だから。
山崎 本を読む能力ってある。早く基礎体力として身につけるほうがいい。
井上 自分は勉強した後に自分で書かないと気が済まない。
小飼 なぜ読むのかというと、いつでも人に聞けるとは限らないから。やたら人に聞くのは基礎体力づくりではダメ。
山崎 チュートリアルはいい人に聞ければ効率的。理解の過程を経ている人に聞けばすぐ身に入る。
高井 井上さんに言っておきたい。「人間 26 歳が一番」説があって……。
小飼 君だからじゃないのか。
馮 （会場の後ろのほうに座っているヨシオリ氏に) java-ja などをやられているが、勉強はどうやって。
ヨシオリ 写経する。その後は簡単なアプリを書いて、その後飽きてやめちゃう。書くのが一番。
高井 自分にあったメソッドが必要。早めに確立する。
小飼 (会場に向かって) 3 年前より頭が悪くなったと思う人? ──結構いますね。
山崎 みな目的があって技術を手段にしている。僕の場合はカタルシスを得たい。理由があって技術が必要だから、そのためにはコミュニケーション力が必要で、という風に目的があるはず。(会場に向かって)技術が目的になっている人がいると思うが、そういう人は? いい指標があれば身につくと思う。
馮 その逆は?
井上 オンライン家電を作りたいので勉強したとか、高専のプロコンで発表会までに用意したり。コンテスト好き。スパンを区切ってやるのは楽しい。
米林 こういう話は違和感がある。学生時代にコンピュータに興味がなかった。バスケしてればいいみたいな。みんなすごいなと思う。
山崎 大学の研究室に入って初めてパソコンを触った。
小飼 最初に触れたネットワークが TCP/IP。日本に帰ってパソコン通信をやって、金を取られてショックだった。
井上 中学生のときにパソコンがどうしても欲しくて、Aptiva E27 を買ってもらった。
米林 特殊なパターンだと思う。
井上 高専には一杯いる。(「最初に買った CD は? ジェネレーションを知るために教えて」と他のパネラーから聞かれ)広瀬香美の「ロマンスの神様」が最初に買った CD。
一同 若いなぁ。
馮 東京に比べて地方は情報量に差があるか。
井上 ある。地方に行くと機会が少ない。場所に縛られないウェブにしても、東京前提のシステムだと思う。
山崎 地方は勉強会の需要がないので、地域格差がある。需要があったほうが身につきやすい。
井上 地方にはウェブで食える仕事は少ない。
小飼 エンジニアは大道芸人じみたところがあるので、人がたくさんいた所でやったほうが儲かる。でもウェブ的にはできないの?
井上 場所に縛られないプラットフォームを作って、早く田舎へ引っ込みたい。
高井 テレワークは前から言われているが、フェイス to フェイスは大切。
山崎 この業界は成熟してないし、需要はいっぱいある。だからこそ、まだまだ新規参入や改革の余地がある。
井上 東京で年間数千万円のシステムを開発するのは価値があることか。
高井 それは手段に過ぎないから、良し悪しとは別。
山崎 密度は大事。それが何千万の椅子かどうかはどうでもいい。
閑歳 営業と我々がコミュニケーションを取らないといけない場合、営業が東京でエンジニアが北海道だと温度差が生じる。
小飼 今自分がやっていることで、東京にいないとできないことはない。なのになぜあんなバカ高い所に住んでいるのかと思う。
山崎 楠さんが言っていたが、東京は集まってて便利だが、一ヶ所しかないデメリットもある。
小飼 東京のバックアップがないのは気になる。危機感まで行かないけれど、いざ火がついたときに間に合うのか。
山崎 はてなの京都、カヤックの鎌倉などはいいなと思うが、普遍的にできるかというとつらい。
質問者 1 東京に別に住まなくてもいいってのは、この会場もスカイプで、とか、ビデオでコミュニケーションとかもいいと思うのだが、弊害は何か。
山崎 ノンバーバルなコミュニケーションというものがある。ライブ感は犠牲になるか。また、技術力を伸ばしたいという面ではデメリットになるかな。
米林 勉強会ならそれでもいいと思うが、日本ではアウトプットさえ出せば給料を払うというのは認められにくいのでは。
井上 技術力をつけるには東京にいることはアドバンテージ。
小飼 何事もメッカには一度は行かないと。ソフトウェアエンジニアリングにとってはそれは東京。
米林 話題を変えようかな。個人的に知りたいのは、ホントに効率の悪い勉強をしてたなって経験は? 私は C の本を写経(手書き)していた。今考えると非効率だった。
閑歳 初めに本を読むとダメなタイプ。他人のコードをカスタマイズするのから始めるのがいい。
高井 サンプルを動かしてみれば分かるかも、と思ってやってみても、やっぱり分からない。
山崎 1 個の情報に依存して突き進むと失敗する。2 個、3 個の情報から多面的に学ぶのがいい。
小飼 やらないでダメと決めつけるのがダメな勉強法。やってみてダメだったというのならいいけど。
高井 変化球を求めるのもダメ。ストレートで勝負しないと。
井上 トラブル対応が効率的なのは、学んで実践するというサイクルが短いから。
山崎 それはアドレナリンが出てるからです。
高井 朝すっきりしてるときにやるとか。
井上 これから勉強するぞと決めて、テスト勉強みたいにやるのは効率悪い。
山崎 とりあえず動くものを形にするというのはみんなに共通してるのかな。
高井 それだけだと何か足りない。本質的な部分が分からない。
山崎 人によって快感の得方は違う。動くものをとりあえず作ると気分がのってくる人が多い。
高井 メソッドを確立して、「これがスイッチ」というのを早く作る。
井上 スイッチの入れ方を知るのは大切。
馮 次のテーマに移りましょう。エンジニアの未来についてお聞きしたい。エンジニアとしてよかったこと、印象に残っていることは。
山崎 思い出深かったのは、データセンターの運用時、あるお客さんを他社から引き受けた。でもお客さんが前の会社に機材の代金を払っていなかった。その業者さんが 17 台中 14 台を差し押さえた。その時調べた所、3 台で運用できることが分かった。「何とかなる」という経験をすると、「あの時何とかなったんだから」という考えになる。
生き方と言うと、部下を持つことが大切。自分は自分がやりたいことをやり、それを部下に与えて、手が空いたら自分が次にやりたいことをやるというスパイラル。
高井 作っている瞬間が一番気持ちいい。世の中を見ていると、ポッカリと空いている部分がある。そこを埋めるものを作ると面白い。見つけた瞬間が楽しい。
閑歳 20 代後半になって「さてこれからどうしよう」と考えた。マネージャーになるか、エンジニアになるか悩んだ。ニート気味の時期にサービスを出して使ってもらったら、知り合いが増えた。個人で出すことによって「この人はこういう物を作りたい人なんだ」ということを認知してもらって話が進んだ。アウトプットが大事。あと、自分のサービスで本当に人が喜んでくれるのは励みになる。
井上 抜けた髪が生えたのが嬉しかった。ミクシィに入ってからストレス性の円形脱毛症になった。その後、思い直して、自発的にならないといけないと思い、オンラインコーヒーメーカー「萌香(もか)」などを作った。縛りがあると思っても、自分でそう思い込んでるだけかもしれない。
米林 よかったのは、この業界に入らなければ出会わなかった人と出会えたこと。ブログなどで知見を広げられる。
小飼 逆説的だが、周囲がロクでもなかったこと。実家が丸焼けになったのがこの業界に入ったきっかけ。実家を立て直しながらなので、フルタイムでどこかへ就職することはできなかった。自分が何とかできると思ったのは、自分しか動かせる駒がなかったから。最後に残っているのは自分だけ。早めにそういう悪運に恵まれておくのはいいかな。悪運を幸運に変えられるのは 26 歳くらいまでか。30 代になった今では無理だと自分でも思う。
山崎 こういうエンジニアだとダメだってのを聞いてみたい。僕は、すぐにできない理由を考えるエンジニアだと思う。
高井 「○○やりたいんですよね〜」。やればいいじゃん、タダなんだし。
閑歳 エンジニア以外の人の気持ちになってできる人じゃないとキツいかな。技術力は大事だけど。
井上 山崎さんや高井さんに同意。「いつかはやりたい」は「絶対やらない」。
米林 エンジニアじゃない人を否定的に捉える人。営業や管理職に対していい当たり方をしない人。技術を分からない人に対して上から目線になる人。
小飼 第一部で吉岡さんが「失敗しない人が出世する」って言っていた。失敗した人を出世させない人は長い目で見てダメだと思う。
馮 失敗談を聞きたい。
小飼 次の失敗のほうがもっとすごい失敗にしたいと思っているので、失敗談と言われると生まれたこと、生き残ったこと。そういう意味で、100% 失敗とみなされる行為をしたことがありません。
米林 後輩に rsync を教えてて、「何だお前、rsync も知らないのか」と言いながらやって見せたら、間違えて消しちゃった(笑)。
井上 最初のコンテストで賞を取って天狗になり、次の回に大失敗してチームはバラバラ、賞ももらえず。学生のコンテストだから失うものはなかったが勉強になった。
閑歳 サービスを作ったときに、最初に作った人は思い入れがある。でも子離れする時期が来る。次の人にうまく伝えて同じ気持ちで育ててほしいが、難しい。
高井 失敗って封印しているので、夜中に「あ〜」って叫んだりするけど、あまり失敗とは考えない。マズかったかなと思うのは、就職活動をちゃんとしなかったこと、社会人のときにもう少し大きい会社に入ったほうが安定してよかったかな、それと給料の話を若いうちにしてればよかったかな。
山崎 ソネットで DNS サーバのメンテをしてるとき、エンジニアがちゃんとコミットしてなくて Emacs のバックアップファイルがたくさんあった。(ファイル名末尾の) ~ の前にスペースを入れてしまい、バックアップを破壊した。「init 6」と打つ所を「init 0」と打ったり。
後は自分の失敗ではないが、電話であるラックを初期化してくれと指示したら、隣のラックを初期化されてしまった。そこはいかに復旧させるか、バレる範囲を狭くするかですよ(会場笑い)。それで経験値が身につく。
馮 Ustream に「給料の話を聞いてみたい」というのがあったが。
山崎 評価方法は専門技能 10、責任感 10、向上心 6〜7、交渉能力 3〜4 の 30 点満点でつける。あとはランキングをつける。それを週一でやる。そのスコアは実務フローに密接に結びついている(6 以下は指示を出せないとか)。自分は 28 歳くらいまではお金のことを気にしなかったが、管理職になってから気になるようになった。
米林 お金のことを考えられる人を評価したい。「いいコードを書いているのに給料が上がらない」には2 つ問題がある。交渉力の問題、それに自分のコードの価値について理解が足りない。10 万でバッチを作る仕事に半年かけていいコードを書いても本末転倒。
閑歳 前の会社では上司が数字の部分を言ってくれる人だった。いくら稼がないと赤字です、というのを週単位で教えてくれた。それを聞いて「自分はちゃんと稼がなきゃ」と思うようになった。そういう情報をオープンにしたほうがいい。
小飼 エンジニアはアピールしにくい。本来作る仕事であって、営業が売る仕事だろうと。作るのは一人でもできるが、働くのは一人ではできない。人がいるからお金に価値がある。お金のことを考えるのは人のことを考えるということ。そういう風にお金を捉えてほしい。
井上 これから社会に出る人、若手の人に、この金銭感覚は身につけておけというのがあれば。
高井 家族、生活の計画を。住宅ローンは年収の 5 倍くらい借りられる。そうやって考えて行くと、「このくらいもらえないと東京に住めないんだ」と分かる。いきなり経営のお金を考える前に、家族のことから積み上げて行くのもあり。
山崎 営業を最初にやったほうがいい。2 年くらい、「営業が見えた!」ってなるまで。営業→技術は難しいが、営業の経験はプラスになる。選択肢がある人は、一度やったら技術に行くのは難しいかもというリスクを考えた上で、経験してほしい。
小飼 その経験は、会社に対してバーゲニングパワーがつく。社長より強いのは客。
高井 お客さんとのリレーションも大事。
質問者 2 皆ポジティブで明るくていいなと思う。それでも人生には波があり、落ちることもある。そういうときに盛り返す方法としてこういうことをやってるよ、というのがあれば教えてほしい。
小飼 どこまで落ちても、というゲームにしちゃう。
米林 友達を大切に。落ち込んだら友達を誘う。自分をよく理解してくれる誰かを見つける。
井上 同期は強い。職場の同僚とは違い、同じ志を持って集まっている人は大切。会社を変わっても重要。
小飼 うらやましい。友達ができるようになったのは大人になってから。妻は同窓会に行くが、自分には同窓というのが分からんのですよ。
閑歳 3 年に一度くらい落ちることがある。法則になっているくらい。そういうときは長期戦で、考え続ける。ある日突然晴れるときがあるので、それを待ち続ける。それを乗り越えると変わる。
高井 道に迷ったときは分かる所まで戻ればいい。今まで自分が何を積み上げてきたのかを振り返られるので、自信を取り戻せる。
山崎 すごく寝るとか、すごく食べるとか、女性と食事に行くとか。それを意識してやる。それでもダメなときは、きっとこの先いいことがあるよって思う。考えても何も変わらないよ、気にしない。
小飼 悪くなるときは痛いくらい悪くなってほしい。最悪なのは「痒い」とき。
質問者 3 エンジニアとしてやっていくためのモチベーション、エピソードがあれば。
山崎 カタルシスというか、人に喜ばれるのが一番。個人的には技術への欲求はあまりない。営業や仲間、お客さんに喜ばれるのが気持ちいい。
高井 いい子にならなくていいと思う。サラリーマンは座っているだけ給料がもらえるので、本当にダメなときはわがままになってもいい。まずは自分のことを考えて乗り越える。ゆるさをもったほうがいい。
山崎 こういうときはエンジニア冥利に尽きる、ってのは?
小飼 僕……。
山崎 弾さんじゃなくて(会場笑い)。
高井 ひらめきですね、ピカーンって。
閑歳 サービスを作った後に、自分が知らない人が使ってくれて、その人の人生が変わるくらい便利なものを作れたらいいな、ってのがモチベーション。作る前の何もないときのモチベーションは、絵を描いてイメトレ。
井上 第三者に自分が作ったものが「面白い」と言われたとき。モノを作ってプレゼンしてバカウケすると嬉しい。
米林 質問者は自分のモチベーションのゴールが見えている。僕はお客さんに名指しで誉められるというか、「米林という人に頼んでよかった」と言われると快感。
小飼 逆に問いたいのだが、人に誉められないとモチベーションは保てない?
米林 下がりはしない。
山崎 あれば 10 倍ボーナスくらいにはなる。
馮 最後にまとめの一言をホワイトボードに。エンジニアの未来というテーマなので、この先のエンジニアの未来はどう思うかまとめてください。
高井 (ホワイトボードに「好きこそものの上手なれ」)好きじゃないとダメかな。やっぱり好きになる。好きな所を見つける。そうするとうまくできるようになる。
山崎 (ホワイトボードに「一回きりだし必死に頑張りましょう。そうしたら何とかなるし」)ダラダラやってもしょうがない。必死にやってもうまくいくとは限らないけど、うまくいくときは必死にやったとき。もっと日本を明るくしようよ。
閑歳 (ホワイトボードに「先が見えないことを楽しむ」)28 くらいになってくると、自分のキャリアパスを考えるが、いくら考えても分からない、ムダだと思った。分からないんだったら、自分の好きなことをやるのが一番。好きなことをやっていればそういう人に出会えたりする。
井上 (ホワイトボードに「自重しろｗｗｗを目指す」)自重は誉め言葉だと思う。予想外のことをやって結果を出すのはイノベーション。やらないのはもったいない。「自重しろｗ」と言われるくらいにやってほしい。
米林 (ホワイトボードに「愛札」)体育会系なので挨拶は大事だと思っている。「愛」は恋人や家族もエンジニアは大事にしてほしい。「札」はお金。自分がやっていることをどれだけの価値があるか、エンジニアにも理解してほしい。あとは「挨拶」。おはようございます、と言われても無視してコードを書いていてはいけない。
小飼 (ホワイトボードに「Make & Make Sense」)こういうイベントをやると「好き」という言葉がキーワードに出るが、嫌いであってもやってなお嫌いなものはないと思う。まずはやってみる。
