見出し画像
Photo by tnnamm

ep2. フルリモートで働くフリーランスエンジニア (ゲスト: @takemikami)

きのこるエフエム公式

※この記事は2019/05/03収録の「フルリモートで働くフリーランスエンジニア」の文字書き起こしです。一部、編集を入れています。

オープニング(00:00〜)

treby & banjun：きのこるエフエムは技術分野、キャリア属性の異なる私たちパーソナリティーがこの先、生きのこる上でキャリア戦略について話すことで、シニアのソフトウェアエンジニアのみなさんのキャリア、人生設計に貢献することを目的にしたPodcastです。

番組はマネジメントに攻めるRubyistのtrebyとスペシャリストになりたい、いちご好きなiOSデベロッパー、banjunの二人でお送りします。よろしくお願いします。

ゲストの自己紹介

treby：そしてなんとですね、今日はゲストにお越しいただいてるんですね。

banjun：お。

treby：ゲストの……みかみんさん！

一同：……(無言)

takemikami：……紹介いただきました、みかみんです。

treby：めっちゃ緊張してる(笑)

banjun：みかみん？

treby：みかみん。

banjun：みかみんさん、もしかすると知らない人もいるかもしれないので。

takemikami：大体知らないと思いますけど。

banjun：ざっくり自己紹介、TwitterのIDとかから言っていただければと思います。

takemikami：TwitterのIDは「@takemikami」でやっていてTwitterのほうのプロフィールとかでは、確かデータエンジニア、データサイエンティストとか書いてると思いますけど、今結構はやってる分野かなと思う機械学習とかそういったのを仕事にしているフリーランスのエンジニアです。

banjunさん、trebyさんとは、やってる分野は違うかなと思ってて、結構技術軸で集まると普段は顔合わせないメンバーかなと思っていて、面白い話ができるかなという気持ちで安請け合いしてきました。

banjun：確かにそう言われるとね、技術によった勉強会とかで会うことはまずないね。

treby：みかみんさんの最近の状況どうですか？とうか、そもそも何でわれわれとみかみんさんがつながってるのかっていう話をちょっとしたほうがいいのか。

banjun：そうですね。

treby：って言うと、まあ都度都度、きのこるエフエムとか言いながらちょいちょい出てくるアイドルマスターというコンテンツがございましてですね、アイマス×エンジニアの勉強会をやっておるわけですよ。

banjunさんと私、trebyもそのつながりで出会ったわけですけれども。みかみんさんも愉快な仲間たちのうちの一人ということでいろいろやらせてもらってて。

ただその技術分野全然分かんないんだけど、なんかすごそうみたいなのをやってらっしゃるっていうこととかで、最近仲良くしてて。いつかは呼びたいよねって言ってたんですけども。

何でこのタイミングになったかって言うと、この収録してる1週間前？2週間前ぐらいに、アイマスハッカソン名古屋っていって、名古屋の若者がハッカソンをやるよっていうのでひょいひょいついていった東京勢3人が行ったときに、最近Podcastを始めたんですよと、みかみさんに話してて……そしたら、どういう流れだったんですか？あれ。banjunさんが誘った？

banjun：誘った気がするけど流れはどうだったけな？

takemikami：流れはエンジニアリングマネージャーMeetupの資料を確かbanjunさんがシェアしてて、それ見て「あ、Podcastやってるんだ」みたいなつぶやきをしたら「おいで」的なのが来たんで、じゃあそれでみたいな。

banjun：なんかクソリプみたいなのが。

treby：きっかけはクソリプっていう。そういう感じの運用でお送りしております。

banjun：だからPodcastを出してtrebyがEM Meetupでしゃべったときのスライドをシェアしたのを僕がシェアして、そしたらみかみんが「Podcastやってたんだ」って言ってるところにクソリプで「来る？」って話をしたっていう。それで今日来ていただいたというわけですね。

treby：っていうことなんで、結構みかみんさんに関しては私たちも知らないこと多いんじゃないかなってことで、結構今から聞いていけたらいいかなっていうふうに思ってて。そもそもエンジニアになったきっかけとかってどういうところだったりするんですか？

takemikami：エンジニアになったきっかけっていうと、多分子どもの頃からパソコンいじってた人間なので自然な流れでそうなったっていう感じはするかなと思いますね。

banjun：子どもの頃っていうのはいつ頃で、その頃のパソコンって何なんですか？

takemikami：小学生の頃ですね。小学生の頃に富士通のFM7っていう。

banjun：FM7？僕もFM7から入ってるんですけど、まあいいか。

treby：そもそも何年世代何ですか？その辺？

takemikami：昭和40年代から50年代じゃない？

treby：それぐらいの世代？

treby：PC98とかいうのは結構よく聞きますけどね。それよりも新しい？古い？

takemikami & banjun：古い。

treby：古いんですね。

banjun：8ビット。8メガヘルツみたいなCPU。性能だよね。

takemikami：CPU的にはファミコンと同じぐらいのレベルのCPUですね。

treby：ファミコンね、アポロ何号かが月に行ったのもファミコンっていう話とかあります。

banjun：あれも8ビットだっていうね。

「データ分析」の仕事内容

treby：なんかしっぽりしてますけど、なんか最初に自己紹介コーナー終わらせましょうか。今フリーランスで、フルリモートでお仕事をされてるっていうことなんですけども。

takemikami：そうですね。フルリモートで。

treby：お仕事内容としてはどういうことを？開発業務されてるんですか？

takemikami：仕事内容は、今は開発というよりはデータ分析って言えば、データ分析なんですけど。

機械学習のモデルとかを作るフローとかを書いて検証して、よりよいモデルを作るためにいろいろデータを評価指標とか、評価指標とかの設計をして、それを測って良くなりました見たいなのをちゃんとレポーティングしてお客さんに出すみたいな、そういうところをやってます。

treby：それは1社からから受けてるんですか？複数社から受けてるんですか？

takemikami：今は1社でやってます。

treby：週5ってことですか？

takemikami：そうですね。

treby：同じ会社でってこと？

takemikami：同じ会社ですね。

treby：働いてる時間は？基本的にデイタイムというか朝から夕方ぐらいから夜か分からないですけど。

takemikami：特に何時から何時までやんなきゃいけないみたいな契約はしていないので、ノッてるときは夜までやるしみたいな。

treby：Slackか何かのチャットツールで連絡が来たら受け答えしてって？

takemikami：そうですね。

treby：その働き方にされたのはここ何年ぐらいというか、どれくらいされてるんですか？

takemikami：フルリモートでやりだしたのは去年の秋からですね。

treby：そうなんですね。意外と最近。

takemikami：割と最近ですね。それまでは客先に行って、実際にデータを見てみたいなとか。基本的にデータ分析の仕事ってあんまり外に持っていけないので。セキュリティとかいろいろ、機密とかあるんで。あんまりリモートでやってる人ってこの分野は少ないと思いますけど。

treby：そうですね。確かに。

takemikami：なので、今後もずっとフルリモートかって言うとそれは分かんって感じですね、正直。

treby：じゃあ今はたまたまやってるけど、どこまで続くかっていうのは分からないっていうか。

takemikami：そうですね。

treby：でも秋からですと半年ぐらい経つ。

takemikami：そうですね。もうそれぐらい経ちますね。

treby：特にそろそろフルリモートじゃなくなるかもっていう気配がないのであれば全然いけそうな感じも、勝手な肌感ですけどあります？まだ分かんない？

takemikami：フルリモートになってから同じ会社としか付き合ってないので、そういう付き合い方ができる会社が世の中にどれぐらいあるかっていうのもあると思いますけどね。

treby：それは結構ずっと自分が分かってない部分はあるかもしれないですけど、機械学習のときとかはスポットでお願いすることが多いってことですか？継続的に顧問的にやるより。

takemikami：ケースバイケースだと思いますけどね。今やってるのは結構継続的にやってますね。

treby：じゃあそれまでもフリーランスはされてたっていうこと？

takemikami：もう多分5年ぐらいやってるのかな。

treby：フリーランス自体5年ぐらい。そのフリーランスをやり始めたときから去年の秋までずっと客先常駐って感じで？

takemikami：そうですね。

treby：それはずっと機械学習みたいなことをやってるのか、開発業務をやってたのとか。

takemikami：どっちもやってましたね。時と場合によってみたいな感じで。開発って言っても、割とデータ分析の仕組みづくりとかデータに近いところの開発を基本的にはやってます。

treby：データっていうのと開発っていう。似て非なるというか、分析というか

takemikami：データに対してからむエンジニアと言っていいのか分かんないですけど、エンジニアリング的な立場でからむっていうのと、そのサイエンス的な観点でからむみたいなのがあって。

どっちもある程度押さえて、どっちが強いときが、ケースバイケースでどっちが強いみたいなのが時と場合によって違うみたいな、その辺りで仕事してる感じですかね。

フリーランスになった経緯

treby：ちなみにそれまでは会社勤めされてたと思うんですけども、フリーになったきっかけとかってあったりするんですか？

takemikami：フリーになったきっかけはですね、これが結構面白いというか、あんまり笑える話でもないんですけど。

その頃働いていたスタートアップの会社が給料払えないって言って、本当に金がなくて。これ就職活動する時間がないなと思って、それやったら本当に家賃払えなくなるなっていう状態になって、就活できないな、すぐに仕事を探さなきゃっていうので、フリーで仕事を取ったっていうのが始まりですね。

treby：じゃあ割と笑えないですね。笑えないけどすごい。

takemikami：笑えないけど、まあ面白いっちゃ面白い。

treby：必要に迫られて、こう。

takemikami：フリーにならざるを得なかったみたいな。

banjun：就職活動してる暇もないほど切羽詰まっている。

takemikami：だからすぐにお金がほしいってなると、普通に就職活動して面接してってやったら何ヶ月とかかかるじゃないですか。そのスパンでお金が入ってくると何ヶ月先とかにやると、家賃払えなくなる、やべえってなって。

じゃあフリーランスで明日から働かせてくださいってやれば次の月の終わりにはお金が入ってくるから、それだったら。家賃だけじゃないですけどね。もともとちゃんと稼いでたんで住民税とかも高いし、これ本当に払えなくなるだろうなと思って、すぐ金いるって思って。

treby：そこでフリーっていう選択肢が出てきたのがすごいですね。普通の考え方だと早く就職活動してる、面談先の企業とかに、早く雇ってくださいっていうふうにあったと思うんですけど。

takemikami：それはもう時間かかるわと思って。

treby：まどろっこしいなみたいな。

takemikami：明日から働かせてくださいみたいな。

treby：それぐらいのスピード感っでってなったらフリーが良かったっていう。その5年前にフリーになったんですけど、それまではどれくらいの間会社勤めやられてたんですか？10年以上？

takemikami：14年か15年ぐらいやってたのかな。

treby：じゃあ社会人人生のうちの今4分の1ぐらいをフリーランスになってきるっていう感じですか。

takemikami：なってきてますね。

フリーランスが会社のデータにアクセスすることについて

banjun：みかみんの場合はさっきデータの部分って外に出せないみたいな傾向があるという話だったけれども、フリーランスで入ったときはそれはクリアしてたんですか？徐々にクリアされたんですか？

takemikami：フリーランスで最初にやったときは、その会社がデータを持ってる会社じゃなかったので、お客さんからデータを預かって分析する基盤づくりをするような会社だったので。

あまり直接データを触ってどうこうっていう場面じゃなかったんで、割とセキュリティ的な話はあんまり関係なく。実際のデータをいじるというのはデータの基盤をつくるみたいなところから入ってますね、最初は。

treby：データがなければ、そうですね。守るものもまだない状態なので。

takemikami：これからデータを集めるので集めるための仕組みを作ろう的なノリですね。どっちかと言うと。

treby：今も普通にデータもらってるんですか？そういうの。フルリモートになって。

takemikami：今のところはデータはアクセスさせてもらってますね。当然個人情報とかはそういうのは見えないようにちゃんとされてますけど、結構ここ数年でそういう基板とかを整えられる会社が増えてきたんじゃないかなという気もしてます。

banjun：どんな外の人でも外からつないで働けるようにっていう基盤ってことですか？

takemikami：そこまで考えてるところはなかなかないかなと思いますけど、単純に個人情報とかにアクセスできる人って最小限にしなきゃいけないって今当たり前の話があって。

でも分析はしたいみたいなところで、そういうのをちゃんとフィルタリングして分析用に問題がない形に変換したデータっていうのを持ってるっていう会社が増えてきたんじゃないかなっていう。

会社勤めのメリット・デメリット(13:40〜)

treby：ここでふつおたのコーナーをしていきたいと思います。ふつおたは、みかみんさんにふつおたを頂いております。

一つ目、東京都在住ペンネームtrebyさんから。「いつも楽しく聞かせていただいております。みかみんさんは過去に長く会社勤めをされていたと思うのですが、よかったところ、逆にここは駄目だったなって思うところはありますでしょうか？教えてください」

takemikami：会社勤め、どうなんでしょうね。いい、悪いというか、単純に合う、合わないの世界かなっていう気はするんですけどね、会社勤めとフリーランスの違いって。

私は割と会社勤めができないわけじゃないんですけど、あんまり得意じゃないというか。社内でちゃんと人間関係を作って根回しとかしてみたいな、そういう世界が結構面倒くさいなって思う人間だったんで、それはちゃんと契約で決めてできるフリーランスのほうが肌に合ってるなっていうのが。

treby：そもそも会社勤めかフリーランスかでも、合う合わないはありますね。私はフリーのほうに合わなかった側になるのかもしれないのは、やってみたら意外と今できるのかもしれないですけど。ちなみに会社勤め14年間ぐらいされてたと思うんですけど、

takemikami：そうですね。

treby：その間は何回か転職はされて？

takemikami：転職は1回しただけかな。

treby：差し支えなければどういう業種の会社から行った？

takemikami：最初はSIerですね。そこが10年ぐらいかな。そのあとはDeNAですね。

treby：DeNA。みんなが知る。

takemikami：そこでデータ分析というほど深いことはしてなかったですけど、簡単なレコメンドエンジン作ったりとかしてましたね。

treby：それがそのフリーランスの基盤というか、土壌じゃないですけど。

takemikami：そうですね。単純にエンジニアとしての経験っていうのは10年ぐらい。1社目SIerで割と癖のないというか、SIerだからお客さん向けにやるんで、基本的に普通のやり方をするので。基本的な開発のやり方っていうのはそこで身に着けたのかなと思ってます。

treby：それで言うとbanjunさんも、私もSIerっていうか、お客さんのところのを作るっていうのはやったことないんじゃ。自社のをずっとやってきた感じがするけど。

banjun：どうなんだろ。いわゆるSIみたいなのはやったことないですけどね。僕は確かにメーカーの中のソフトウェア。中って言ってももちろんエンドユーザー向けの。

あるいはソフトウェアだけど自社製品とか、あるいはBtoBにいたときも自社製品だったんだけど。そBtoBのときはもちろん受託もあったんで、そういう意味ではお客さん向けのっていうのもやってはいるけど、SIer的なものではないですね。ただの受託っていう。

takemikami：trebyさんの今のところ(Repro)もお客さんに合わせて動くSI的な動きをすることが多そうなイメージがありますけど。

treby：今から増えていくかな、っていうところですね。

まさに自分が今立ち上げてるソリューションアーキテクトとかは、そういう側面もあるのかなって思ってますけど。これまでは自社でサービス持ってるんでちょっと不便みたいななのがあっても我慢してもらうみたいなのが多かったのかな。

確かにSIerとtoBビジネスっていうのは近いところもあるのかなっていうのはそういうところです。お客さんがありきで。やっぱり大きいお客さんとかだったら、こういう機能ほしいていうのは、なんとしてでも達成したいよねっていう流れとかになったりしますね。

Repro社が初めての私のtoB経験なので、勉強させてもらってますねっていう。……何目線か分からないですけど。

BtoBとBtoCのプロダクト開発の違い

takemikami：なんかtoBとtoCの違いも結構面白いですよね、仕事やってて。

treby：その話いきます？いや、全然語れますよ。

takemikami：なんかtoBを結構やってると、もうちょっとダイレクトにお客さんと接するイメージがtoC側に持っちゃうんですよね。

toCって本当にお客さんがまさに使うものをそのまま作っているっていう、エンドユーザーと向かい合ってる感じがするんですけど、いざtoCに行ってみるとお客さんってすごい遠いところにいて全然分かんないんですよ、お客さんが。

banjun：めっちゃ分かりますよ。その気持ち。

takemikami：だから意外とお客さんの反応ってtoBのほうがしっかり見えて、思ってたのとちょっとイメージが違うなtoCみたいなのはDeNAに行ったときすごい思いましたね。おお客さん遠いって。

banjun：分かります、分かります。

treby：私はむしろキャリアのスタートがtoC、グリーだったので。そこからtoBに行ったときに、「こんなにお客さんの声っていうのを聞くところがあるんやみたいな」、っていうのも。

自分は別にtoCのほうが個人的には好きだと思ってるんですよ。なんでかって言うと、自分自身が作っているものをドッグフーディングできるから。toBのってできないんですよね。

banjun：日常的に使うってことがありえないから。

treby：そうなんですよ。なので、気持ちになりきれないところがあって、これは絶対にいいみたいなのは分かんないんですよ。いいだろうみたいな。

でもだからといってお客さんが言ってるものを多分そのまま作るのも駄目で、っていう難しさがあるなってのは結構3年ぐらいのRepro歴の中でしみじみ感じているところで。

じゃあtoCのほうがいいかって言うと、それはそれで。最近ちょっと考えが変わってきてるところがあるんですね、自分。最近toBもいいなというか。結構BtoB SaaSいいなみたいな感じで思ってきてるところがちょっとあると思うんですけど。

それがそのさっきのみかみんさんが言ってた、反応が近くに見えるっていうところに近いかもしれないんですけど。お客さんと直接会話をしてるので作ったもののフィードバックが直接もらえるんですよね。

例えばtoCの場合とかって、典型的には私ゲームを作ってたんですけども釣りスタっていうですね、のを作ってたんですけども、当時は本当にいちエンジニアだったんでディレクターの人が別にいて、こういうの作ろうって言って作ってやるんですけど。

思ったのはこういうのが刺さるだろうってやってもその反応が良かったか悪かったかってやっぱり数字でしか見えなくて。それは本当に個々人で聞いたら確かに良かった悪かったっていうのはあるんですけど、賛否両論なんですよね。直接は分からないんだろうなっていう。

それが良かったじかどうかっていうのを判断するっていうのも、なんかふわっとしてるっていう言い方がいいのかどうか分かんないですけど、ユーザー数が多いがゆえに一人のお客さんが良かった悪かったっていうのは確かにフィードバックとしてあるんですけども。

全体として良かった悪かったっていうのは、結果で見るしかないよねっていうところの感覚で合ってます？

takemikami：単純に話せないっていうのが一番分かりやすいですよね。

treby：話せない？

banjun：直接お客さんとミーティングして物事を決めるっていうことがtoCではないですね。

treby：ファンミーティングとかやってたんですけど、そういうのではないってことですね。

banjun：対等な立場ではないというか、別にお客さんと開発者なんでそもそも対等ではないにしても、そもそも(ファン)ミーティングとかだと数からしても対等かどうかって。

takemikami：基本的にtoCって気に入らなかったら離れればいいだけなんで、お客さん。本当に不満がある人は逆に多分言わないですもんね、toCの場合。

banjun：toCのお客さんの声直接聞いて何かを作るっていうことはまずないですね。言い方悪いかもしれないですけど。

お客さんの気持ちを推測してそれに合わせて要件を作るだけの話で、お客さんがこう言ってたからっていう具体的な声に真摯に向き合って、みたいなことは実際にはないですね。

treby：結構その感覚で分かんないかもしれない。意外と。toCのほうは素直っちゃ素直なんじゃないかなって思ったんですけどそうでも、まあ感じ方か。

banjun：僕最初にtoCに入ってtoBに転職したときは、そういうのも動機一つとしてはあって、toCはお客さんの具体例が見えないからtoBでお客さんがほしいと思うものをズバリ作るのはどうかっていう観点はやっぱりあったんですね。

treby：toCからあえてtoBに行った組か、banjunさん？

banjun：そうですね。今またtoCに戻ってきましたって感じですね。

treby：おかえりなさい。確かにtoB、toCの違いとか話し始めるといろんな観点とかありそうで面白いですね。

takemikami：幸いみんなどっちもやったことがあったんで。

treby：確かに。toCやってたときはまだ自分の経験値が低いから、今やってみるとまた違うtoCの側面が見えるのかもしれないって今話してて思いました。

banjun：より戻しでtoCやったりtoBやったりtoCやったりっていう、それも一つ楽しみなのでは。

みかみんさんの仕事に対するモチベーション(23:12〜)

takemikami：意外としゃべってみると話題が出てきますね。

treby：そう。話も盛り上がってきましたところでですね、二つ目のふつおたいきたいと思います。

ペンネームmomenさんから。「こんにちは構成作家のmomenです。初ゲストのみかみんさんにお聞きしたいです。私は去年フリーランスから会社員になって最近仕事が楽しくなってきました。みかみんさんの仕事に対するモチベーションはどこにありますか？波があるとは思いますが教えてください。」とのことです。

banjun：どうなんですか？実際。

takemikami：モチベーションってどこにあるんだろうな。聞かれても分かんないな。何だろう。時と場合によって違うと思うんだけど、でも今単純にやってる作業が面白いかどうかが一番モチベーションになってる気がするけどな。

富裕層が金曜夜にスマホをいじらないのはなぜ？

データとか見てると結構発見とかがあったりするので、そういう発見を見つけたときとか、アハ体験ではないですけど。あ、なるほどなみたいな、そういうのと出会うのは面白いかなって最近は思います。

treby：差し支えなければこういう話があったよみたいなのって。

takemikami：何だろうな、話せるやつあるかな。

treby：抽象化した感じで。

takemikami：一個結構面白かったのが、ウェブサイトにアクセスしてくるユーザーのデータを分析してて、年収との関連性を比較してたんです。年収が高い人はどういうふうにウェブを見るのかみたいな。

treby：そんなんできるんですね。

takemikami：だから年収高い人、年収低い人みたいな会員の情報とかで分けて、年収高い人はどういうふうにウェブ見てるのか、年収低い人だとどういうふうにウェブ見てるのかみたいな分析をしてて、ああなるほどなって思ったのが金曜日の夕方に金持ちはスマホを使わない。っていうのが出てきて。

何でだろうなと考えてて。多分こうだろうっていう推測が、多分会食してるんだろう、金持ちはと。だから金曜の夜はスマホ使わないんだ。でも貧乏人には多分会食してなくて、多分家で一人できっとスマホいじりながら弁当食ってるんだろうなみたいな。そういうのが結構データにも出てくるんだな。

treby：それは別に裏付けがあったわけじゃなくて、あくまで仮説として？

takemikami：仮説として、そうです。

treby：ファクトは金曜日の夕方は年収が高い層が

takemikami：高い層がなんかスマホを急に使わなくなる時間帯があるって。

banjun：それは代わりにPCを使ってるとかそういう話ではなくて、単純にスマホからのアクセスが減っている。

takemikami：代わりにPCを使ってるのかもしれないですね。ひょっとしたら。ただ年収が低い人は別にそこへこまないんですよ。

treby：じゃあ谷になってるって感じですか？

takemikami：そう。その金曜の夕方はお金持ちはスマホの利用率がガクって下がるみたいなデータがあって。

banjun：まじか。結構使いそうだな。自分を見るとね。

treby：自分とかやったらそう。年収が高いかどうか分かんないですけど、会食行ってもなんかいじってそうだなって。

banjun：そう。食べに行っても触っちゃうし。

treby：そういう系の会食じゃないですよね。本当ガチ会食のやつですよね。

banjun：そうそう。それが失礼にあたるような。

takemikami：企業の役員とかがやるような会食です。

treby：そういうのはね、いじれないですね、さすがに。呼ばれたこと今のところないですけど。

banjun：われわれはすぐ「華金フライデー」とかって書き込んで、ワーってやってる。

takemikami：だからそういう会食じゃなくて仕事として会食をしてるんですよね、多分。高い基準っていうのが年収いくら以上とかありますけど。

treby：でもそれで言うと別に金曜日に限らず平日全部下がってそうですけど、そういうのは見られなかったんですか？

takemikami：多分ある程度下がってたんでしょうけど金曜日が突出して下がってたんで、明らかに変だなっていうぐらい下がってたんで。

treby：ほかの曜日に比べてセッティングしやすいっていうことなんですかね。

takemikami：なんでしょうね、きっと。

treby：スマホを触ってるどころじゃない何かがあるわけですね。

takemikami：そうですね、きっと。

使い捨てるソースコードの綺麗さ、どうする？(27:44〜)

treby：じゃあちょと次のコーナー行きたいと思います。「私はこっち派のコーナー」ってら書いてありますね。

これはきのこるエフエムのパーソナリティが、奇しくもスペシャリスト、ジェネラリストっていうふうになってるんで、「きのこ」「たけのこ」みたいな感じで、ある一つのテーマに対してどっちがいいのかっていうのを決めて議論するっていうことでですね。

banjun：「きのこる」だけに「きのこ」「たけのこ」って言ったの？

takemikami：「きのこ・たけのこコーナー」でいいんじゃない？(笑)

treby：確かにね。ちょっと題名はね。

banjun：グレーやけど。まあいいか。

treby：ブラッシュアップの余地があるんで(笑)

今回のテーマですね。なんかツイートが貼ってありまして、こちらは多分ディスクリプションとかにも貼られるとは思いますけども、読み上げますね。

「どうせ使い捨てるコードだし、永遠と使われる。ここでしか使われないからいつの間にかありとあらゆる場所で使われる。何かあったら自分ですぐ直すから、お前がいつもいつまでも現場にいると思うなよ。以上の理由で業務でもソースコードは常に分かりやすくきれいに」っていうツイート。

ここから得られる示唆というか。お題がこちらで、「コードはいかなる場合でもきれいに書くべき？ or 業務遂行のため状況により、コードはきれいじゃなくても良い？」

banjun：難しいね。

treby：難しいの？これなんか後者一択じゃねえ？後者一択っていうかそのケースが本当に見えてこないと割と判断がつかない系だと俺は思ってたんだけど。きれいとか汚いもレベル感があるからな。

banjun：「状況によりコードはきれいじゃなくても良い」難しいね。この瞬間の判断としてはどっちもあるんだけど、後片付けのタスクとセットにしないと後者は選べないなっていうのがある。

treby：後者っていうのは業務遂行のために状況によりコードはきれいじゃなくても。きれいじゃなくても、確かにきれいじゃなくてもの度合いによりますね。

banjun：これは言い方も問題だけど、きれいに書くべきっていうのときれいじゃなくて良いっていう、その言い方の問題で言うときれいに書くべき派かなと僕は思いますね。

treby：それを言うとそうですね。きれいに書きたい。こだわりは強いほうだと思います。

banjun：ただその例外的な事項っていうのは当然あると思っていて、業務遂行のため状況によりっていうのは当然ある。

treby：過去に二者の選択に迫られたこととかお二人はあったりするんですか？

banjun：選択を迫られるとか、そういうことを言っている場面に遭遇することはそこそこありますよね。

takemikami：私はめちゃくちゃなスケジュールで後者を選ばざるを得なくなるケースは多々遭遇してますね。

treby：つらいやつですね。一番つらいやつね。やっぱりtoCのときに多いよね、こういう場合っていうのは。

toBは比較的なんか締め切りってのが、うちの場合なのかもしれないですけど、そこまで(きつくない)。toBなのかうちの会社なのか分かんないですけど。すげえきついぐらいきついっていうことはそんなになかった、まあ何回かありましたけど。そんなになかったイメージがあって。

つまりどういうことかって言うと、ちゃんとメンテしやすいコードを書いていくよねっていう文化があるので、汚くてもすぐに出すっていうのはなかったですね。今の会社に関して言うと。

過去の2社(どちらもtoC)に関しては、やっぱり状況によりけりなんですけどもパッと出さなければいけない場面っていうのがあって。

1社目のグリーのときはゲームやってたときは顕著ですけど、どっちかって言うとこの雰囲気好きですよ、好きだっていう前提で話しますけども。

当時ってQAとかも立ち上がりたてのフェーズだったんで、とりあえず頑張って作るんですよ。月1回のペースでイベントを回して5種類ぐらいイベントあるんですけども、月1のペースで5種類のイベント回すから大体1週間に1本ぐらいはイベントをリリースしていくわけですよね。ソーシャルゲームのライフサイクルというか、ルーチンとして。

で、やってるとたまに検証が十分じゃないままというか、何ならQAのときも開発してたりとかしてたんですけど、まま出すこととかがあったりして、何が起こるかって言うと、出してみると急にアラートがボボボって流れ始めたりすることがあるんですね。てんやわんやになるんですけど。

てんやわんやでね、すげえ笑いごとではないんですけども、一方ですげえみんな顔が輝いてくるんですね。何のにおい？何があったの？みたいな。ゾロゾロエンジニアが集まってくるわけですよ。

そのとき起こることっていうのは大体、微妙なんですけども、ちゃんとそもそもよく分かんないけどアラートが上がってるって事象に対して、アラートが上がってないっていう正常な状態に行くまでのスピード感は一番半端ないなと思ってて。

そういうときとかはとりあえずまずはコード出して、アラートを直す、治めることが先決やみたいなのはあるなと思いましたね。

なので、いついかなるときでもきれいに書かなきゃいけないよとか言ってても、それでアラートが1日中出てましたとかなっちゃうと、本当にそれはサービスが継続できないレベルとかだったら、多分まずはアラートをつぶすことが先決だよねって話になると思うんですよね。

takemikami：結構そういういろんなケースがあって、やむを得ず汚くなってしまっていうのは現実問題として避けられないかなと思っていて。

割とbanjunさんが最初に言ったのが割と本質的かなと俺は思っていて、結局汚いコードが入ってしまうはやむを得ないとして、それちゃんとマネジメントしとけよっていう話が結論なのかなと個人的に思っていて。

treby：マネジメント、ですか？

takemikami：汚いコードが入ってしまいました、入っている状態だっていうことが可視化されているっていう。これは応急処置のバッジなんですよっていうのが可視化されていないと、それを正としてコピーしてみんなが使いまわしだすっていう。

banjun：なんかまさにここに書いてあるこのツイートそのものからそれを僕は読み取るんですけど。

takemikami：本当にマネジメントできてないだけでしょ？っていう。

banjun：マネジメントできていない状態がこのツイートの文言では合っている気がするかな。

takemikami：きれいとか汚いとか、個人にそこを押し付けてしまうと絶対に破綻するよっていう。ちゃんとマネジメントしとかなきゃ駄目だよっていう。

treby：マネジメントっていうのはコードベースに対するマネジメントっていう話ですか？

banjun：そうそう。

takemikami：だから急ぎでもないやつで汚いコードだったらちゃんと直してから出そうねって言えるようなレビュープロセスがなかったら、汚いコードがどんどん入ってくるしみたいな。そういう仕組みづくりをちゃんと、というかそこをやるべきなんですよね、このシニアエンジニアっていうのはね。

banjun：シニアエンジニアの役割。

takemikami：シニアエンジニア的な視点でこのレベルで議論に参加しちゃったら駄目なのかなっていう。

treby：これは部分でしかないっていうことなんですね。個人に落ちてるから。そうじゃなくてチームプレーとしてどう考えるかっていうところで考えたい。

takemikami：っていう視点に移らないとシニアエンジニアにはなれないなって。

treby：いいですね。すごいシニアエンジニア感出てきた。

「とりあえず」なコードのマネジメント(35:34〜)

takemikami：この議論で低レベルな個人の、あの人のコードきれい、あの人のコード汚いみたいな議論に入っちゃうと、ちょっとそれはシニアエンジニアの立ち回りとしておかしくない？っていう。

banjun：例えばここでしか使わないからって言っていることがあった場合、その発言主が誰かっていう、やっぱり個人を見たほうがいいのは、それはその通りで。

要するに単純にスキルは足りてなくてこれを言い訳にしてるパターンって結構あると思うんですよね。何かあったら自分ですぐ直すって言ってる人が直せそうかどうかっていうのもよく見たほうがいいと僕はマジで思っていて。

treby：それは何か痛い目にあったってことですか？

banjun：まああんまり具体例は出せないですけど、よくある話だと思っていて。これを言い訳に使われると結構開発としては破綻していくかなっていうのがあるので。

言い訳じゃなくてまじで緊急でこの人は来月頼めばやってくれるという確信があれば通せますけどっていう、そういう感じかなっていう。

treby：それ難しいね。そもそもチームメンバーに誰を入れるかみたいな話まで発展しそうな感じがするじゃない。今のbanjunさんの話的に。

banjun：なんかあんまりこれを言うとさ、banjunさんの前で変なコード書くと殴られるとか。

treby：今ね、現職で危ない人として見られてでしょ？

banjun：何もないね、根拠のない噂が立ったりするんだけどね。

treby：マサカリが飛んでくる人でしょ？(笑)

banjun：そうそうそう。

treby：話してみると思いのほか優しかったです、banjunさんって。

banjun：そうそう。なんかそういう話があったから、いやいや怖いことは言わない。

だから最終的にあなたにはスキルがないでしょと言うのはさすがにひどすぎるんだけど、実際にスキルがあるかないかっていうのは事実としてあると思うんで。

それは誰がどれぐらいのスキルを持って、あるいは後ろにどれだけのスケジュールがある状態でそれ言ってるんだなっていうのは確認しないと、ただの無法地帯になる。というふうに思いますね。

treby：それそうですね。対人なのか個人なのかチームなのかみたいな話を結構ごっちゃになって話を今されているような気がしてて、このツイートは多分これ個人の話で。個人の話ですよね。

個人の意識の話としては業務でもソースコードは常に分かりやすくきれいにって。それはある意味当然の話だと俺は思ってるんですよね。エンジニアだったらきれいに書くっていう。

今みかみんさんが言ってるのは、そもそも汚いとかきれいとかいうのはケースバイケースとかだから、ちゃんと汚いのを入れたら汚いのを入れたで分かってるような状態なってて、ハンドルされればいいっていうのがみかみんさんの話で。

ただbanjunさんが言ってたのは、そもそもあとで直すからとか言って、その人が信頼がない場合とかっていうのはチームがそういうことになるんで、それは何とかせないかんっていう割とメンタリングっていうのか、育成っていうのか分かんないですけど、そういった類の話な気がしますね。

つまりエンジニアの技術力っていうところで言うところのレベル感が合ってないときでもどうするかっていう話とかですか。確かにそれはレビューで通してはいけないっていうような。

takemikami：ちゃんとレビューする仕組みがあれば本番には入らないから、基本的に仕組みとしてはオッケーだと思うんですよね。

banjun：レビューさえあればっていうこと？

takemikami：レビューがあってちゃんとそれが、そのフローが回ってれば、レビューする人が忙しすぎてもう見れないとか言ってるようなレビュープロセスが回ってる会社あるじゃないですか。

treby：別にディスとかじゃないんですけど、それを何とかしたいんですよ。前向きにしたいけどもどうすればいいか分からないっていう。俺基本的にめちゃくちゃコードきれいに書きたい派やで。

takemikami：汚いコード書きたいエンジニア基本いないと思っていて。

treby：それで言うとエンジニアの定義とはみたいな話になりません？

takemikami：確かにそれはね。コピペして動いてワーイって言う人もいるちゃっちゃいるから。

treby：そう。っていうところとかもあるし。

takemikami：それで苦労した話はいくらでもありますね。基本的にはおまじない行がゼロ行になるレベルには達してほしいですね。

treby：そうですね。全部説明可能っていうことですね。

banjun：おまじないだから。

takemikami：その行はコピペ元にあったからみたいな行が一行でもあったら駄目ですよね。

treby：それはちょっとね、それは良くないけれども。どっちかって言うとそれ高専でチューターというか、自分が高学年になったときに低学年教える役とかやってたんですけど、というときによく見たパターンですね。

それはもう単位として取らなければいけないやつだったんで、その気持ちも分かるよ、分かるがっていうのをやったのも覚えてます。なので、結構幅がありますよね。どこのところに前提条件を置くかっていうところですね。

多分何でもいわゆるエンジニアと呼ばれる人だけで言うと、それこそ本当のつらい感じのコードを書く人ととってなるだろうし。

takemikami：初めは仕方ないですけどね。コピペしてパラメータいじって、覚えていくのが最初なんでしゃーないけど、それは業務では通用しないんで。

treby：このPodcastはシニアエンジニアの方しか聞いてないっていう一応前提を引いてあるんで。

ここでは少なくとも普通にエンジニアがコード書くって言ったら、メンテナンス可能なというか少なくともOSSにパッチを投げるレベル、OSSにパッチを投げるって言ったときにOSSもピンからキリまであるなって今頭の中に思い浮かんでしまったんですけど。

banjun：レベルっていうか軸があって。

treby：そうそう。割と多くの人に使われているOSSっていうふうに言ってみますかね。それもピンからキリあるな。割といろんなものが入ってる。

takemikami：OSSも文化が違うからな。

treby：場所によってね、っていうのありますね。自分が想像してたのはRailsとか、あっちのほうとかも比較的にゆっくり目で固いほうですね。枯れたって言うと、いい意味で枯れたOSSですね。

Mastodonとかはすげえ早かったですよね。最初のほうちょっとプルリク投げて取り込んでもらったりしてたんですよね。あそこは割と速かった。プロダクト開発ですけども。今どういう感じになってるか分からんいですけど、っていう前提のもとで話したときにどうしていくのがいいのかってところで。

結論としてはちゃんとチームとしてその辺のハンドルじゃないですけども、きれいに書くか、素早くパパってやるけどもあとでやるか。素早くパパってやるけどもあとでやる派は、多分やらないというのが自分の自論なんですね、基本的に。

一回動いてるものを直さないみたいなのは人間の本能的なところであるような気がしてて。暫定対処ですよっていうのが大体数年間残ってたりとか。

何ならそれがそのままToDoかフィックスにか分かんないんですけどコードコメントは入ってるんですけども、それ書いた本人はもういないとかあるような気がしてるので、仕組みなりなんなりでやるようにしときたいし、やらないとむしろいけないような仕組みにしとかないといけないし。

何なら、かといってそれが強制じゃなくて喜んでやるみたいな感じになっててほしいですね。ボーイスカウトルールみたいな話になっちゃうのかもしれないですけど。

banjun：リリースしたあとに直せるかどうかっていうのは結構厳しい面もあると思ってて、直すチャンスがないプロダクトもあると思うんですよね。それをどう見るか。

takemikami：それ悩ましいところで。エンジニアの間であったら割と納得感あるんですけど、あまりにも汚いコードで今後のことを考えて、きれいにするために直しましたっていうものをリリースしたときに、トラブルが起こったときにエンジニアじゃない人に説明できないんですよ。

なんで大丈夫だったものをわざわざ直して、不具合を起こしたのって、そういうところとかも結構あって、なかなか難しいだろうなっていう感覚はありますよね、その辺。

treby：きれいにしていくっていうのはあとからすることの難しさですよね。

takemikami：政治的な。

treby：そうそうそう。ちゃんと期待したコントロールとしてね。

takemikami：予算を取らなきゃいけないし、それをやったことによってトラブルが起こったときにどう説明するかって。それでもやるべきなんだよっていうことをちゃんと説明できるのかって。

treby：会社がエンジニアリングに理解あるかどうかって結構大事ですね。会社なのか組織なのか現場ですね。

banjun：あとは、あとからコードをきれいにするだけの変更を入れたとして、そこでバグが混入してないことを確認できるスキルというかその辺もありますね。

treby：品質保証。

banjun：そう。例えばそれは単体のテストとかでもいいんだけど。QAチームがその辺のリグレッションに長けていればやれるわけですね。そんなQAチームがそんなことのリグレッションに時間使えるわけないんですけど、っていうところだったらできないし。

takemikami：よくテストコードがないから直せないっていうケースはよくありますけど、大体直さないといけないぐらいやばいところはテストコードないんですよね。

treby：その辺になってくると本当に個人の意識な話から、本当に組織みたいな話まで。

takemikami：多分今、世の中的にそれがちゃんとできてるところってほとんどないのか、ないような気がするんですけど。それをちゃんと数字にできれば経営層を説得できるはずなんですけどね。

treby：そうね。

takemikami：だからリファクタリングをすることによって今後の開発コストが何％下がって、だから今リスクを取ってやったほうが絶対に得なんだっていうのを数字で説明できればいいんですけどね。

そういう意味でこういう使い捨てコードみたいなのが今のプロダクトの何％ぐらい占めているのかみたいなのは、ちゃんと定量的に見えるような管理ができていればいろいろ立ち回りできるんだろうなっていう気はしますね。

(※編集注：後日、takemikamiさんが下記のような記事をポストしていました)

変わらないコードは読みづらくても良い？(45:54〜)

treby：使い捨てコードをそういうニュアンスで使ってるか分かんないんですけれども、二度とそこに変更が入らないコードであれば、読みづらくても何でもいいような気がするんですよね、っていう感覚ないですか？

要するにコードが汚くてつらいのって、未来の自分かもしれないですけども、書いてるときの自分以外の誰かが読むときに「手が入れられないぞこれはどうなってるんだ」っていう時だと思ってて。

つまりそういうケースが起こり得ないのであればブラックボックスで何も支障もないって思ってるんですよ。ない？その感覚。

banjun：前提が結構強いなって感じなんですけど、それはそうじゃないかな。同意はしてますけど。

takemikami：それもそこに絶対不具合がないっていう前提がないと。

treby：そうそう。もちろん。

takemikami：そこに絶対の不具合がないことは多分保証できないから。

treby：バグはね、そうね。

takemikami：その周辺にバグがあったときに、そこじゃないって絶対に言えるのかってなったときに、そこはやっぱり調べざるを得なくなるから。

banjun：例えば僕の立場上だとiOSエンジニアなんですけど、Swiftが変わりましたとか、iOSのSDKでそのAPI使えなくなりましたとかあることを考えると、結構高い確率でどのコードも変更され得ると思って動かなきゃいけないんですよね。

そのときにガチなブラックボックスとして変更に耐えるかっていうのは、かなり期待値は低いので。ある程度周辺のコード読んで理解しつつ、変換していかなきゃいけない。となると割と高い確率できれいじゃないコードと向き合って変更するっていうことに遭遇するんで、っていうのありますね。

treby：そういうことか。つまり機能開発する上では変更しないんだけれども、言語仕様そのものが変わったときに、変更というか手を加える可能性があるっていう。

banjun：そうそう。言語仕様とかiOSのAPIだとか。要するにどのコードもだけど基本的に何かのプラットフォームの上で動いていて、マーケットのユーザーとインタラクトしているわけで。

コード自体、あるいはプロダクトの機能が変わらなくても周りの変更、周りの環境の変更によって、そのコードの立ち位置が揺らぐっていうことはよくあると思っていて、特にiOSアプリのソースコードっていうのはよくそれにさらされるなという感じですね。

treby：そうか。iOSと言うかSwiftという言語が割と後方互換を崩しまくるやつとか。

banjun：崩しまくった実績があるし。

takemikami：なんかAPIとかで何かとつながってるとそれは避けられないですよね。とかなんかのミドルウェア使ってたりすると。

treby：Rubyって言語がそうですね。割と互換性保って(バージョンアップを)やってくれるからその辺は感じづらいのかもしれないなって今言ってて思ったけれども。

確かにあと今感じたのは、すごいブラックボックスでいいって言ったんですけども、やっぱり自分が扱う可能性があるスコープの範囲内はブラックボックスじゃいかんですね。

ぴょこってメンテできるようにしておかないと自分たちのコードなので。だからブラックボックスでいいのはOSSもなんかケースバイケースだから難しいんですけど、自分たちのスコープの一応外にあるっていうようなところはそうあっても何とかなることが多いのかなっていう感じはします。

ただ結局OSSとかになってくると結局自分も貢献していくことを視野に入れてやらないといけないので、程度だというか、ケースバイケースっていうところには落ち着くと思うんですけど。

banjun：OSSは大体メンテナーがいるのでメンテナンスの責任みたいなのはただのコントリビューターあるいは、ただのデベロッパーは思ってないですよね。

treby：そうね。最終的にそこは絶対いじらんだろうって思ってても、いじることがあるよねっていう反応を頂いたっていう認識なんで。確かにそれはそうだなっていうことは。

banjun：いじらんなら確かにいいんだけど、多分いじるし、特にiOSとかは結構いじるよっていう話ですね。

treby：なんか何ちゃらの法則とか名前がついてそうですね。いじらないと思ってるところは実はめっちゃいじるみたいな。

takemikami：性能と戦ったりするとどこでもいじりますからね。

banjun：うん。性能っていうのは確かにそうですよね。

treby：それで言うと実は言語として優秀というか、環境として優秀なのってそういう変化とかでもいじらなくてもなんとか動くっていうことも入ってくるのかもしれないなっていうふうに思いましたね。

banjun：それだけ見ると例えばSwift とよりObjective-Cのほうがロバストで優秀ですっていう話になってきて。例えば今でもiOSでもSDKの界隈とかObjective-Cなり、Cなりで書くっていうのは割とある話だと思いますね。

treby：ただそのかけるそもそも人員が少ないみたいな話になってくる。

banjun：そうすると当然開発コストも高いし、どうするの？っていう話に。トレードオフで。

treby：COBOLエンジニアとかその辺とかよりも数字でいきそうな感じがしますね。枯れてるところはいじれないけど、今度はいじる人が少なくなっていくみたいな。

takemikami：昔ガラケーの開発とかでUNIX系を結構できるエンジニアが急に必要になって、歳いった人が駆り出されてましたね。

一時期、90年代とか2000年代頭ぐらいってWindows全盛時代で、Windows系のエンジニアばっかりになってしまって、携帯の開発でUNIX分かるやつが大量に、若いやつでUNIX分かんねえってなって。

banjun：逆に、時代をさかのぼればいたわけなんですね。

takemikami：そうですね。結構割とシニアなのかな、クラスのエンジニアとかをかき集めて開発とかしてた時期がありますね。

treby：あるみたいですよね。瞬間的にはお仕事がなくなったように見えるかもしれないですけども、競争相手も同時にどんどんいなくなっていくので同じ技術を伝えることによって、需要はそれはそれで生まれてくることがあるのではっていうのは思います。ちょっとFlashとかは分かんないですけどね。

banjun：確かにFlashエンジニア？

treby：FlashはAppleにやられた感じがするので、あれはちょっとかわいそうな感じがしますけど。それがどこかで使われている限りは。toC向けのFlashは死んだかもしれないですけど、実はtoB向けのFlashというか、密密でもう変更されないFlashの何かをメンテしてるところでは需要がありそうですよね。

banjun：すごいの作っちゃってもうそのメンテし続けるしかないみたいなのはあるかもしれない。

treby：需要と供給なんですね、そこはね。

takemikami：Flashはね、toCのサイトで見れなくなってるサイトが、昔のサイトがいっぱいあって悲しいですけどね。

banjun：悲しさはありますね。

treby：2000年代前半を生きたわれわれとしてはもうFlashとね、ミームとうか文化とは切っても切り離せない世代です。楽しかったですけどね。

banjun：ミーム大好きすぎてバイナリーとか解析始める。

treby：そんなのやってたの？すげえ。めっちゃガチ勢や。フリーエンジニアって割とFlashやってた人多い気がする。

banjun：Flash、僕はコンテンツ作れないですけどね。パースはできるんですけどね。

treby：いろいろやってますね。

ちょっと前の私に伝えたい：「お金は大事だよ」(53:37〜)

treby：よし、じゃあ次のコーナー。

banjun：次のコーナー？

treby：みかみんさんにですね、ちょっと聞きたいコーナーですね。「ちょっと前の私に伝えたいコーナー」。ということで、このコーナーの趣旨としては、ちょっとテーマガラッと変えまして。

みかみんさんが、近況……最近あった話に関連付けてでもいいんですけども。例えば3ヶ月、半年。3年、5年とかいうスパンでもいいんですけども、そのスパンで前の自分に、こういうことはしておけばよかったなっていう学びみたいなのはないかなってことをお伺いするコーナーでございます。

takemikami：でもこれ本当、さっきのフリーランスになったきっかけの話なんですけど、お金は大事だよっていうことですよね。

treby：実際お金に余裕があったらフリーランスになってなかったとかっていう道はあるんですか？

takemikami：なってなかったかもしれないですね。

treby：結果的にはなってよかったんですよね。肌が合う。

takemikami：そうでうね。まあifの話をしだすと分からないんで何とも言えないですけど。別に悪い選択だったとは思ってないです。

treby：ということはお金はなくて良かった？

takemikami：いや、つらいですよ。なんか通帳見ながら家賃とか税金とか引き落とす学計算して、やべえ足りるかなって見ながら生きていくのは。

banjun：みかみんにもそんな頃があったとはっていう。ちなみにさっきDeNAにいた話してましたけど、お金払えなくなったのってDeNA？

takemikami：の次ですね。

banjun：流れ上DeNAがランアウトしたのかと思ってちょっとドキッとしちゃったけど、そんな事実はないですね？

takemikami：してない気がしますね。私の知る限りは。元気にやってると思います。DeNAさん。

banjun：その時点で蓄えがあったらフリーランスにならず、フリーランスの良さに気付くこともなくっていう。

takemikami：正直蓄えが全くなかったわけではないんですけど、ちょっと崩しづらい形で持っていたので。

treby：何か金融資産に換えてたって感じですかね。

takemikami：現金化しやすい形で持っていなかったっていうことですね。

treby：しなかったから、今すぐ現金がほしいっていうことで。

takemikami：そう。ある程度現金持っておかないといかんなと。

treby：実際それは建前じゃなくて本当にそんな感じ？本当にそんな感じだったんでしょうけど。

takemikami：いや、本当にそんな感じでしたね。9万円引かれるのに、通帳したら10万しか入ってないっていう。

treby：おお、熱い。定期預金というかそういう現金化しやすいもので持ってたみたいなのはなかった？

takemikami：そのときはちょっとタイミングが悪かったのもあって。ちょっとまとまったお金を使ったあとだったんで。

treby：じゃあガバッって出ていったあとにさらに引かれ始めるみたいな。

takemikami：で、入ってこないみたいな状態になり、通帳見て、あ、やべえ足りねえと思って。なんかポイントで一生懸命携帯代払ったりとかして、これで足りるかな？って言って。家にあるモニタ売りに行ったりとかして、これで家賃払えるわって言って。

treby：じゃあお金は大事だよっていうのは当時の自分に伝えたいっていうこと。

takemikami：そうそう。現金化ができる金は持っておかないといけないなっていうのと。逆に良かったのが本当エンジニアで良かったなっていう気がする。

treby：多分エンジニアじゃなかったらあんなすぐ仕事見つからなかったなって。確かに5年ぐらい前っていうことは2014年？

banjun：14年？

treby：全然エンジニア加熱してますね。

takemikami：でも実は同じ頃に似たような境遇の知り合いがいて、彼と二人でよく「いや、エンジニアで良かった」って「エンジニアじゃなかったら死んでたわ」って。

treby：いい話じゃないですか。リスナーの皆さんもね、エンジニアだと思いますので、エンジニアで良かったですね。他人事みたいに言ってますけど。

banjun：いやいや、本当に良かったな。

takemikami：明日から働こうと思えば働けますからね。

昨今のエンジニア職の市場価値

treby：いや、でも分かんないよ。そう思ってたらさ、エンジニアであることに価値がない時代がやってくるかもしれないんやで。

banjun：うん、あるかもしれないけど。

treby：シンギュラリティ、シンギュラリティ。雑に言ってますけど。

banjun：ここまでエンジニア持ち上がっちゃうと、本当にそんなことあんのかなって。

treby：いや、危ないやろう。持ち上がってるからこそ俺危ないと思うけどね。持ち上げられすぎな気がしてるけど程度が分かんない。

ビットコインの今がてっぺんだと思ったらさらに上があったみたいな、そういう話と近いような気がしてて。ただ加熱してることだけは確かみたいな。じゃあどこの相場が普通なんだみたいな。

不動産相場とかも近いかもしれないですけど。どこまで上がるんだみたいな。チキチキレースやってるみたいな怖さはありますよね。やってると。

takemikami：どうなんでしょうね。でも日本とか東京のエンジニアのレベル感だとそんなに加熱してる感はないかなっていう感覚は私ありますけど。

treby：そうなんですか。どこと比較してとか？

takemikami：シリコンバレーとかはちょっと加熱してるかなって思うけど、東京はそんなでもないんじゃないかな。

treby：かわいい？

takemikami：割と適正に。数年前とかが適正じゃなさすぎたかなっていう。適正に近づいて、それよりひょっとしたら上振れてるかもしれないけど、ぐらいかなっていう。

treby：じゃあ順当にお給料とかも上がってきてるっていう流れの許容範囲に収まってっていう。

takemikami：かなとは思いますけどね。別に東京で高いから中国に出してみたいなでやっても、別にそんなに中国もう安くない。

treby：安くない。

takemikami：うん。

treby：むしろ高いんじゃないですか。東京より。

takemikami：とか、そういうこと考えると。別にそんなに高騰している世界レベルで見たとき、感じはないのかなっていう気はするけどね。

treby：結構いいですね。でもその視野。グローバルに見たときの視野っていうのはね。やっぱり国内、東京なのか日本国内なのか分かんないですけど、で見たときにはやっぱり非エンジニア職に比べて少し色がついてる気はするんですよね。肌感で。

takemikami：それは確かに。

treby：それが別に市場原理としてそういうもんやっていうふうなのもあるのかもしれないんですけども。でも非エンジニアの職種の人からしたら、理不尽なもととかになって、感情の話として。

本当に大元にあるのはただの市場原理だと思うんですけども、なんか能力のできる、できないとかにやっぱり給料っていうのは紐づきがちじゃないですか、っていうのがまあ難しいなっていうのは、最近自分の関心っていうか、どう説明すればいいんだろうというか。

さっきの時給うん千円とかいう話とかでいって、エンジニア的にはそれは普通だよねっていうか、むしろまだもらえるでしょみたいな話とかしてるんだけど一般のお話で言うと、いや、どうやらそうじゃないらしいみたいな。

banjun：エンジニアの時給は一般と比べたら高い。

treby：っていうのがあったりとかすると。

banjun：エンジニアの間では普通だよねで通せるのかもしれないけど、それでいいんだっけっていう話も。

takemikami：さっきの話で言うと、相場としては別に特段突き抜けて高いわけじゃないですけども、自分の意識してとしては謙虚でやっぱりいたいなというか、常にそれ以上の価値を出すっていうのは意識していきたいなっていうのは改めて思ったり、思わなかったりしたわけですけど。

banjun：エンジニアが結構、非エンジニアと比べてちょっと変わってる、給料レベルに関しても生き方に関しても。違和感じゃないですけど、違いがあるっていうのがいつまでつづくのかっていうのはありますね。

treby：結構難しいですね。その辺の話もしていきたいですけどね。結局同じ会社なり何なりプロジェクトなりで働いてるってことは同じ方向向いてるはずなんですよ。

¥なんですけども、よく言われるbizサイド/devサイドみたいな使い分け方をされたりとか、開発はこうだからとか、エンジニアはこういう生き物だからみたいな。まるでエンジニアは人間じゃないみたいな感じで使われることもあったりするわけなので、そこは深掘りしていく回があったらしていきたいですね。

でもみかみんさんの3年前の自分に言いたい、5年前の自分に言いたいこととしてはエンジニアで良かった、お金は大事というところですね。

じゃあこの流れで聞いちゃいますけど、リスナーのみなさま、シニアエンジニアのみなさまに自分から自分の哲学がこうだ、みたいなのがもし、みかみんさんのほうでありましたら。

takemikami：哲学、漠然とまた。

何だろうな。あんまり肩肘張って仕事したくないなって最近割と思っていて。割と自分のペースで楽しくできることが一番大事かなっていうのが割と心情ですね、最近。「何生易しいことを言っているんだ？」と言われそうですけど。

treby：いや、俺もそれわかりますけどね、ここ半月の結論で言うと。というか逆にそうじゃないよっていうふうな意見とかも聞こえてくると思ってるんですけども。

そう思ってる方にどういうふうに自分はマインドセットが変わったかとか、最近そう思ってるっていうことは前はそう思ってなかったっていう前提があると思ってたんですけど、みかみんさん的にはどう？

takemikami：最近、そうだな。昔は結構野心的というか成長したい的な気持ちが若いときはあったので。最初SIerとかにいたからちゃんとコンサルレベルのことができるなりたいみたいなそういうのはあって、結構ビジネス書的な本とかもエンジニアリングの本以外もすごい読んだりとかはしてたんですけど、最近は自分が面白いと思える本を読めばいいやっていう感じに変わってきてますね。

treby：肌感的にどれぐらいの年齢ぐらいから変わってくるかとか。年齢なのか周囲の環境なのか分かんないですけど。

takemikami：フリーランスになってからかな、特に思ったのも。

treby：5年前ぐらい。フリーランスっていうのも一つ、みかみんの人生においても切り替えてるっていうか。

takemikami：もあるし、会社員で自分のスキルをいくら上げても結局社内政治みたいなのをちゃんと回さないとどうしようもないみたいなところもあって。別に社内政治に強い人間になりたいって気持ちが全くないので。そんな勉強したくないしっていう気持ちもあって、フリーになってそれはもう僕はしなくていいな。

自分がなんか面白い興味があること。多分なんか面白いと思えることって多分みんなもきっと面白いと思うようなことで、多分今後はやることだと思ってるので、自分の感覚で好きなことやってればきっと生きていけるや、みたいな割と軽い感じで肩凝らないように生きて行こうかなみたいな。

treby：思想がすごいフリーランスっぽいっていう表現が合ってるか分からないですけど、向いてるんだなって思いました。その境地に行くことあるかな？これから先分かんないですからね。

banjun：分かんないですね。

treby：自分の。

takemikami：なんか会社員やってて疲れたっていうことですよ、きっと。

treby：そういう人生の先輩なんで。エンジニアの先輩でもある。今から楽しみだなっていうか。われわれも肩肘張らずに。このPodcastに関しては本当にただの趣味ですから、っていう感じで今後もやっていけたらと思います。

banjun：はい。

クロージング(1:05:42〜)

treby：ではちょっとですね、宴もたけなわとうか、話も盛り上がってきましたところで締めに入りたいと思います。今日はゲストにみかみんさんをお呼びしてお送りしてきました。みかみんさんありがとうございます。

takemikami：ありがとうございました。

banjun：ありがとうございました。

treby：きのこるエフエムでは皆様のお便りをお待ちしております。

banjun：お便りご感想につきましてはTwitterで「#きのこる」ひらがなで「きのこる」でお願いします。

treby：次回は2週間後ぐらいにまた公開したいと思います。もし、ゲストにいらっしゃりたい方という奇特な方がいらっしゃいましたら、私trebyかbanjunさんのほうにTwitterなどでメンションいただけますと幸いです。

それではみかみんさん今日は長い間ありがとうございました。

takemikami：ありがとうございました。

banjun：ありがとうございました。

treby：ではまた次回お会いしましょう。

この記事が気に入ったらサポートをしてみませんか？