ep8. 設計するということ / 仕事と学びのバランス (ゲスト: @takasek)
※この記事は2019/09/01収録の「設計するということ / 仕事と学びのバランス」の文字書き起こしです。一部、編集を入れています。
オープニング(00:00〜)
banjun & treby： きのこるエフエムは技術分野、キャリア属性の異なる私たちパーソナリティーがこの先生き残る上でのキャリア戦略を共有したり議論することで、シニアのソフトウェアエンジニアのみなさんのキャリア、人生設計に貢献することを目的にしたPodcastです。番組はマネジメントに攻めるRubyistのtrebyとスペシャリストになりたい iOS Developer、banjunがお送りします。よろしくお願いします。
treby：なんか前回から間空きましたね。
banjun：ちょっと空きましたね。
treby：ひと月半ぐらい。
スカウトメールと一位指名
banjun：何かありましたか？最近、話題としては。
treby：何だろうな。スカウトってあるじゃないですか？
banjun：スカウト？
treby：うん。Forkwellとか。
banjun：はいはい。
treby：いつも見ないんですけどメールが来てですね。「一番会いたいエンジニア」だっていうので、おってなったんですよ。
banjun：一番会いたいエンジニア。
treby：それが見てみたら、求めてる技術分野がPythonとかPHPとかで。
なんで会いたいって思ったんやろうって思ってちょっとがっかりした体験が最近のハイライトです。こんにちは。
banjun：あれですよね。今週一番会いたいエンジニアっていうやつですよね。
treby：そうそう。一応タイムスコープがあるというか、1週間ぐらいの単位なんですね。
banjun：なかなか言い方が良いと思っていて。そう言われるとちょっと気になる。何だろう、やっぱり需要がある感って結構大事かなと思っていて、会いたくないのにこっちから売り込みにいくことも、それはできるけど、今週一番会いたいって言われると、そこまで言うならっていう感じはありますよね。
banjun：そうそう。あの転職ドラフトにも1位指名っていう属性あるって知ってます？
treby：知ってますよ。
banjun：なんかそれついてるとちょっと、おってなるじゃないですか。
treby：なりますね。転職ドラフトはまだ確度が高い気がしますね。
banjun：ふんふん。
ゲスト紹介(02:18〜)
treby：本日もゲストにお越しいただいておりますと。
banjun：はい。今回のゲストはtakasekさんです。
takasek：どうもtakasekです。よろしくお願いします。
treby：じゃあ早速ですがtakasekさん、自己紹介を簡単にしていただけますでしょうか。
takasek：はい。takasek(たかせっく)と申します。8年ぐらいiOSをやっています。Objective-Cの時代からやっていて、Swiftに入ってSwiftの良さとかを楽しみつつiOSをやっています。
フリーランスでやっているんですけれど、メインではFiNCさんという会社をお手伝いさせていただきつつ、ちょっととかのところを手伝わせてもらったりとか、自分の勉強にあてたりとかはしています。
文系出身でして、あと昔エンジニアの最初がCOBOLとかやってたんですけれど、しっかりしたコンピューターサイエンスみたいなのが分からないところから入ってるコンプレックスで。
なので、最近はその勉強をしているうちに勉強の楽しさっていうものにどんどん目覚めていますかね。そんな感じです。よろしくお願いします。
banjun：よろしくお願いします。
パーソナリティとの繋がり
treby：takasekさんはbanjunさんとは長いんですか？
banjun：長いかって言うと、そうめちゃくちゃ長いわけではないですけどね。
takasek：2016年、17年どっちでしたっけ？
banjun：16年か17年。17年かな？多分。
takasek：17年のtry! Swift。
banjun：try! Swiftですね。
takasek：try! SwiftってSwiftの国際的カンファレンスで東京で2月でしたっけ？やっているやつ。
banjun：2月か3月かそのぐらいにやってますね。
takasek：そのときに隣の人に話しかけたら、そしたらその人がbanjunさんだった。
banjun：そうでしたね。僕もあんまりそういうtry! Swiftとか大きなカンファレンスもまだあんまり行ってない時期だったんで、そんなにめっちゃ知り合いがいるわけでもなく。
カンファレンス行ってみるかみたいなノリで座ってたところに隣にtakasekさんがいたという感じですね。
takasek：確かObjective-Cの話をしたんですね。
banjun：そうでしたっけ？
takasek：Swiftの前Objective-Cやってましたみたいな話で、何でObjective-Cを最初やったのかみたいな話とかしてた気がする。
「意外とこの人めちゃくちゃ深いところからやってるぞ」みたいなので、ちょっとビビり散らして。あとIMEの話とかをした気がする。
banjun：AquaSKKとか？
takasek：そうそう。
banjun：そんな話したんだ。
treby：記憶抜けやすい感じってなってますけど(笑)
banjun：記憶力悪いほうじゃないと思うんですけどね。意外としゃべってみるといろんなこと忘れてるんですね。
takasek：でも僕も記憶力はすごく悪くて、人の顔と名前が覚えられないのでカンファレンスとか勉強会とか人と会うたびに、この人と前に話したことを忘れていると失礼だなって思いながら怖くなって話せなくなるタイプ。
banjun：分かりますね。
treby：あるある。
banjun：僕も顔分かんないですね。何回か会えば分かるんだけど、それまでがね。だから2回目は困りますよね。
takasek：分かります！最初の人よりもむしろ2回目の人のほうがしゃべりづらい。
banjun：そうそう。毎回名乗ってほしいですね。
treby：見たことはあるんだけどぐらいの人がね、一番(悩みます)ね。
takasek：ジャンプの『デスノート』読んでて、一番うらやましかったのがノートじゃなくて「死神の目」なんですよ。
死神の目って手に入れると寿命が半分になるんですけれど、その代わり人を見るとその人の名前と寿命が頭の上に浮かぶっていう。寿命はどうでもいいんですけれど名前が浮かぶっていうのがマジすげえいいなと思って。
treby：名前が分かると話しかけやすいですよね。
takasek：そうですね。だけどそれがエンジニア界隈そんなに本名じゃない人も多いじゃないですか。そうするとbanjunさんの頭の上に「伴 潤」って出てるとこの人誰だ？って。
banjun：なりますよね。
treby：本名ですけどね(笑)
banjun：本名とハンドルネームは一緒ですっていう情報がない限り分かんないですよね。
takasek：そうですよね。
treby：banjunさんネタよく出てきますね。
banjun：でも大きい名札はほしいですよね、常に。分かるように。
takasek：ほしいですね。カンファレンスで名札のところにアイコンがあるやつ、あれ本当にいい試みですよね。
banjun：すごくいい。
takasek：この週末にbuildersconに初めて行ったんですけれど、そこも名札の作りがすごい良かったなと思います。
treby：あらかじめアイコンと名前を印刷したの用意してるんですよね。
banjun：buildersconってなんかいろんな界隈の人たちいるんですね。多分。
treby：そうなんです。満遍なくいましたね。私が観測した範囲では。
banjun：なんか名札とかでどの界隈みたいな主張できるんですか？
treby：そういう仕組みはないですね。基本的にはアイコンと表示名とTwitterアカウント。
takasek：でも属性あるとちょっとうれしいですね。
treby：何の話ができるんだろうっていう。
banjun：そうそう。Swiftの話は通じるのか、全然違うのかとかね。
takasek：今回buildersconに行ってちょっと失敗したなと思うのが、自分の守備範囲の話をたくさん聞いちゃったんですけれど、本来だったら全然知らない話をたくさん聞くべきだったんだろうなっていうのは思います。
treby：そういう良さはありますよ。レベル感高すぎたら本当に置いてかれたまま終わっちゃうんですけど、なんか「雰囲気楽しそう！」とかでもいいみたいだしね。
スーパーカミオカンデっていう粒子のやつで、物理的な話が盛り上がってゲストスピーカー賞に選ばれて。
banjun：なんか出てましたね。
treby：ああいう話とか絶対に分かんないんだけど聞いてるだけでロマンがあるみたいな。それであとは、私のほうは結構浅いって言ったら言い方があれですけど、3月の「Art of」のところが初めて。
takasek：そうですね。
banjun：そうそう。だからそのときは確か僕がtakasekさんに声をかけて参加していただいて、その関係でtrebyも知り合いになるっていう感じですね。
treby：あれから半年ですからね。早いもんですね。
banjun：うん、確かに。
takasek：そんなに経ってましたか。
treby：もっと経ってるような気もするから半年しか経ってないのかっていう感じもありますけど。アイマスのほうにも来てくだすってたイメージがありますね。
takasek：そうですね。
banjun：くだすってましたね。
takasek：そういえばの話。「Art of」よりも前に、去年のIM@Study。
banjun：IM@Studyのエンジニアトークかな。
takasek：あれにもちょこっと顔を出して。なので、多分そこでも顔は見ていたんじゃないかなと思います。
treby：いや、ありがたい。
takasek：あれは楽しいですね。
banjun：あれはいいですね。
treby：あれを楽しいって言っていただければありがたい。
banjun：そうそう。iOSDCがちょうどこの収録日からすると来週あるんですけど、そこもIM@Studyの話で一発技術パッション枠を取ろうと思ったんだけど取れなくて、結局ね。
そこはCFPがちょっと勢いが足らず取れなかったんですね。そのときの打ち合わせみたいな、協力いただいてますね。
takasek：そうですね。みんなで集まってどういう発表するかっていうのを。じゃあそれをどういうふうにアピールするかっていうのを考えて、CFPを作ったんだけれどちょっと狙いを外してしまったかもしれない。
banjun：ちょっと方向性がちょっとずれてたかもしれないですね。
treby：倍率が高かったりもしますからね。
banjun：まあね、ほかにも機会があれば狙っていきたいけれどもなかなかいい箱というか、カンファレンスは見つけるのは難しいかもなとは思ってます。
treby：自分たちがつくるのが一番早いのかもしれないですけどね。
banjun：それで言うともうあるから。
treby：まあ、アイマスのね。カンファレンスじゃないけど、勉強会はありますけど。
takasek：逆にbuildersconじゃないけれど、蛸壺化するんじゃなくてほかの人にも来てほしいからだから殴りこんで行くっていう感じを。
banjun：まあそうですね。それはIM@Studyに来てほしいっていうのももちろんあるけれども、もっといろんな別のカンファレンスとかiOSにこだわる必要ないんじゃないのみたいなところがあって、楽しいことをやっていこうっていうきっかけにしたかったんですね。
takasek：IM@Studyって言うと、そのコンテンツでつながるところだっていうのを一番押し出したかったんですよね。
banjun：そうですね。特定技術の話をするために集まるんじゃなくて、技術は玉石混交でいいんだけどコンテンツっていう軸で集まってみようっていう、そういうのも楽しいよっていう話ですね。
takasek：そのためにはiOSのアプリを作ってもいいし、オープングラフ？
banjun：Linked Open Data。LODですね。
takasek：Linked Open Dataを使ってそれぞれそのデータ解析をしてもいいし。
banjun：あれもいい話ですね。iOSDCといえばtakasekさん登壇されますね。
takasek：はい。そのタイトルが「生活にSOLID原則を適用する」っていうやつで。
僕結構原則が好きで、オブジェクト指向の原則って、要はオブジェクト指向って何のためにあるかって言うと、何かの問題に対して解決したいわけじゃないですか。
その問題を形作る、もしくはその解決策を形作るための解決の形を作るのがオブジェクトなので、これ別にプログラミングに限らずに生活のいろんなところでも使える考え方なんじゃないのかなっていうところを発表させていただけたらなというふうので、5分のLTなんですけれど考えているところです。
banjun：このPodcastが配信されてる頃にはもう終わってはいると思うので。
takasek：そうですね。
banjun：そうするとあとは資料と動画が出るかな？
takasek：動画も配信されるのかな、そのうち。
banjun：それでチェックできるかなというふうには思いますね。
treby：じゃあそんなtakasekさんと今日はお送りしていきたいと思います。よろしくお願いいたします。
banjun & takasek：よろしくお願いします。
RPGツクールからDISK-BASICへ(12:00〜)
treby：早速takasekさんのこといろいろ聞いていきたいんですけども。
まずは生い立ちから今までに至る経歴とかそういう話を聞きたいと思ってます。特に一番最初文系だったっていう話がありましたので、その辺を踏まえてどういうきっかけでプログラミングに興味を持って、どういう子ども時代を過ごしたかっていうところについて聞けたらいいかなというふうに思っております。
takasek：僕は小学校の頃にスーファミ結構遊んでいたんですけれど。そのときに『RPGツクール』っていうゲームご存知ですか？
treby：ありますね。
takasek：RPGを作る、そのままですけれど。『RPGツクール』でフラグの管理とかそういうのを学びながら、こういうふうにゲームって作られるんだっていうふうに思ってたんですけれど、なにせスーファミってすごい容量が少ないんですよ。なので、すぐに容量がいっぱいになりそうで。
treby：凝ったの作ろうとしたらね。
takasek：凝ったのを作ろうと思ってオープニングで止まるっていうのは常なんですけれど。全部完成したことがないんですけれど。オープニングを作ったらもうすでに4分の1ぐらい、容量使っちゃってるぞみたいな、そういう感じで。
これはちょっと厳しいんじゃないかと思ったときにPC-9800のツクールっていうのが出ているっていうことを知りまして。父親がPC-98を持っていたので、なので、じゃあそっちでやってみようというふうになったんですね。
そっちのRPGツクールはすごくて容量もめちゃくちゃ大きいし、グラフィックとかあとも音楽も自分で作ったものを作れるっていう、「すごい自由度高いぞこれは」って感動したんですね。
なので、そっち側でまたオープニングまで作っては飽きて放置みたいなことを繰り返したんですけれど。
でもそのためのグラフィックを作ったりとかドット絵打ったりとか、あるいはMMLっていうMusic Macro Languageっていうんですけれど、そういうのを使って音楽を作ってみたりとか、何かを作るっていうところの楽しみにどんどん目覚めていきました。
そうするとRPGだけじゃなくてほかのもの作りたいなって思ったんですね。そうするとフロッピーを入れるとMS-DOSが起動するっていうやつなんですけれど。
そのフロッピー入れないと、PC-98にそのまま入っているDISK-BASICっていうプログラミング環境がいきなり立ち上がるんですよ。
banjun：割と起動早いやつですか？
takasek：そうそう。そのDISK-BASICでBASICっていうのを使うともっといろんなことができるんだって思って、ちゃんとしたBASICの環境を入れてプログラミングをしてみるっていうのを中学の時にパソコンの部活に入ってやってました。
RPGツクールはちょっと壮大になりすぎて大体は挫折したんですけれど、でもN88-BASICで作ったゲームはいくつか完成させたりして。
treby：どんなゲーム作ったんですか？
takasek：こまをぶつけて、くるくる回すこま。あれをぶつけて押し出す相撲みたいなゲームを作ったりとか。
treby：グラフィカルなプログラミングするのって結構大変じゃなかったですか？
takasek：グラフィカルって言っても結局二次元配列の座標があってその座標を動かしていって、そこが何にヒットしたら何をするみたいなすごい単純なことをやっていたので。あんまり構造化とか考えなくてもある程度動いてましたね。
banjun：こまがぶつかって、あれですか？ベイブレード？ベーゴマ的なやつですか？
takasek：そんな感じです。
banjun：今だったらiPadとかあるから、タッチUIでシュッってやればできそうですけど。当時のグラフィックで、そもそも円をどうするかとか動きをどうするかって想像するの難しいんですけど、どんな感じなんですかね。
takasek：その辺はただのサークル命令みたいなので、ただ丸があってそいつがぶつかるっていう感じでした。
banjun：丸が動いていって。
takasek：丸を毎フレーム描画していって、ぶつかったらそこで弾き飛ばされてみたいに。
そのときに学んだのが、学校の勉強って実は役に立つなっていうのがすごいそのとき思ったんですね。こまがぶつかり合うときって三角関数が出てくるじゃないですか。
三角関数何に使うの？ってそのときまでは思っていたんですけれど、こういうときに使うんだなっていう、プログラミングをやっていて分かった感じですね。
banjun：それはよく分かりますね。それはいつ頃ですか？三角関数習ってからやったってことですか？三角関数っていつ習うんでしたっけ？
treby：高校ぐらい。
takasek：でも中学でやってたので、それより先行してましたね。
treby：すげえ。オレ中学のとき三角関数学ばなかったけどね。
banjun：でも僕もそうですね。BASICやってて三角関数いるんだってなって、やりました。
treby：sin(サイン)・cos(コサイン)っていうぐらいしか知らなかったですけどね。
banjun：そのサークル命令を使わずに円を描く場合でも三角関数はいるし、だから部分円を描くとか、円じゃなくて螺旋状にちょっと半径を描きつつ円を描くとか。すぐ三角関数が必要になってくるんで。
takasek：あとラジアン。
banjun：あとラジアンはそう。ラジアンは本当に何度もやっていつのまにか覚えてるみたいな。「÷180」って書くんだっけ？みたいな、そんな感じですね。
treby：それが中学時代ということですかね。
takasek：はい。
就職でプログラミング回帰
takasek：高校に入るとプログラミングからちょっと遠ざかっていたんですけれど、就職するときになって、プログラミング昔やってたしそこに近い会社がいいんじゃないかと思って選んだのがシステムエンジニアの会社だったんですね。
treby：そうなんですね。
takasek：はい。システムエンジニアの会社で結構サクッと入れて、そこで研修を受けたんですけれど。システムエンジニアって大体文系歓迎なんですよ、未経験歓迎。
その代わりに手厚く研修しますよっていう。研修が1年ぐらいあったんですね。がっつり研修する中でプログラミングの知識があるかないかでスタートダッシュが全然違って。
僕割とコーディングの部分だったら任せろバリバリみたいな感じでやってたんですね。基本情報っていうのも受けさせられて、みんながあそこで四苦八苦してるところでも僕はサクッと受かってしまって。
暇なときには自分でエクセル、エクセルでいろいろやり取りしてるんですけれど、そのエクセルのマクロの作り方を考えてみたりとか関数がどうなってるかとか試してみたりとか、そういうのをやって遊んでいました。
treby：エクセルでやり取りっていうのは何ですか？時間とかを管理するってことですか？報告書？
takasek：基本的なすべてのドキュメントはエクセルでやってまして。
treby：じゃあエクセル方眼紙みたいなのも含めてみたいな感じ？
takasek：そうです。エクセル方眼紙たくさん作ってました。縦横それぞれ等間隔に並んでいるセルに、仕様書も書くんですけれど。仕様書っていうのが大体コードと1：1で対応しているやつで。「何が何のとき、何をする、そうでなければ何をする」っていうのを全部日本語で書くんですよ。
treby：フローチャートみたいな。
takasek：コーディングのときにはそのまま1行1行正しい、そのまま落としていくっていう。何のために書いてるかよく分かんないやつなんですけど、今考えると。
だけどそういう仕様書を書いてやっているんですけれど、やっぱり繰り返し処理がたくさん出てくるのでそれを流し込めるようにしたらいいんじゃないかって思ってそういうマクロ書いたりとかしてました。すごい何のためにやってるか全然分かんないですけどね。
banjun：そうですね。メタプログラムですかね。
treby：メタプログラミングって、業務の要求されているドキュメントを作るために、レポートするためにやってるんですけども、大元を考えてみると何のために必要なんだっていう、それコードでよくねえ？みたいな感じなんですよね。
takasek：本当にそれなんですよね。
banjun：コードのほうが自動チェック効くから。
treby：そういう会社っていうところですよね。ちなみにその就職されたっていうのは高校のあとですか？
takasek：大学にいました。だけどその理系とは関係ない文系でした。
treby：じゃあ高校行かれて高校からプログラミングから遠ざかってました。大学も文系の大学に行きました。でも就職はそのシステムエンジニアの会社っていう流れがあるのですね。
takasek：そうです。
システムエンジニアの会社でのお仕事(20:10〜)
treby：そのあと、どのようなことをされてたんですか？
takasek：SEとしてやっていたのは、管理業務とか多かったんですけれど。
ドキュメントを作ってファイルサーバーにアップロードしたり、ダウンロードしたりしてそれぞれ書き換えたり、プリントアウトしたりとか、そういうのはたくさんあったんですけれど、当然自動化の余地がたくさんあるわけですよ。
それは社内のイントラネットのブラウザを使ってやり取りするときにも、これも結構繰り返しがあるぞっていうのをずっと感じてまして、それを自動化することにすごく興味が向きまして。
ブラウザにおいてはブックマークレットとか、JavaScriptで直接書き換えるとか、エクセルについてはマクロを作って、これをやれば同じ形式のエクセルファイルが吐き出されますよっていうのをみんなに使ってもらったりとかするんですけれど。
SEだとあんまりそういうところに興味ない人が多くて、今思うと僕の伝え方とかももうちょっとできたんじゃないかとは思うんですけれど、結局結論としてあんまり使ってもらえなかったですね。
効率化っていうものをみんな求めていないんだなっていうところにちょっと引っかかりを覚えて。
Web系企業への転職
takasek：だったら自分はもうちょっと効率化をみんなしようと思うような、そういうところに転職したほうがいいんじゃないかって思いまして、プログラマーとしてやっていこうっていう。
treby：それが入って何年目のぐらいの話ですか？
takasek：それは入って2、3年ですかね。
treby：やっぱり割とちょっとずつそのもやもやがたまり続けて、じゃあ動こうって思ったのはそれぐらいのタイミングだったんですね。
takasek：はい。そこです。
treby：どういう軸で会社を探すっていうか次のキャリアを探してました？
takasek：当時どういうふうに選ぶかっていうところをあんまりよく分かっていなかったので、じゃあどうしようかっていうのをうろうろしていたところ、会社のブログでうちは募集していますっていうふうに書いてある会社があって。
そこに連絡を取ったら、分かりましたじゃあ1週間後に来てくださいって、話が早えぞと思って。そのときに課題としてこれを出します、これをやってくださいっていうふうに書いてあって。
PHPで何か掲示板的なものを作ってくださいって言われたんですね。だけど僕はPHPやったことないんですよ。これは学ぶ機会だって思って。
treby：チャンスですか。
takasek：はい。その場で書店に行ってPHPの入門書を買って、勉強してそれらしいものを作ってみる。
これは楽しいぞと思いながら、言われていた資料よりもいろいろ機能をつけ加えたものを、気の利いたものを作って提出したら、そしたらそのままサクッと入ることになって。こんな転職ってこんなに簡単にできるものって拍子抜けしながらそこに入った感じですね。
そちらの会社ではPHPのほかにもJavaScriptとか、あるいはデータベース、MySQL書かせてもらったりとか。当時はガラケーのFlashをやらせてもらったりとか結構いろんな体験させてもらって。
そのガラケーのFlashを作る中でスマホも出てきたのでiPhoneのプログラミングをしてみようっていうので、そっちの案件をやらせてもらったりとか、かなりいろんな技術をそこで学ばせてもらいました。
treby：いわゆるWeb系の会社だったんですね。
takasek：そうですね。
treby：ブログの記事で見たって言いますけども、それはたまたま見かけたのか何か探したのかとかっていうのはあるんですか？
takasek：バズってました。
treby：じゃあはてブとかでバズってたのを見つけて申し込んでみようって申し込んでみて。
takasek：そういうことです。
treby：「なんかバズってるってことは、結構ほかの人も見てるんだろうな」って思ってたから、自分でいけるんだろうかって思ってたら結構すんなりと通っちゃたからびっくりしたっていう。
takasek：そうなんですよね。
treby：確かにびっくりしますね、それはね。
banjun：しかも未経験の言語でね。
takasek：そうなんです。
takasek：バズってる、結構ネット上でも有名な人がやってる会社なので、ほかにもエントリーしている人たくさんいるんだろうなと思い。
未経験の僕じゃ駄目なんじゃないかなって思ったんですけれど、そうすると話が早くサクサクと進んで。バズってるからといってそこで動く人ってそんなにいないのかもしれないなっていうのは今も思います。
banjun：それもありそうですよね。タイミングってあるから。
treby：ちなにみにどこの会社なんですか？
takasek：ユビキタスエンターテインメントっていう会社で清水亮さんっていう。
treby：清水さん？enchantMOONとかの？
takasek：そうそう。ほかにもいろいろ結構ビジョナリーっていう感じで新しいことを打ち出していたので、ネットでも結構評価されてたところですね。
banjun：なんか記事たくさん読んだ気がしますね。
treby：端末とか作られてましたよね。
banjun：enchantMOON。UI。
treby：enchantMOONがそれだっけ？
banjun：enchantMOONがハードウェア。
takasek：enchantMOONがその次のやつです。
treby：enchant.jsあれか、ゲームのフレームワークもあった。
takasek：はい。
treby：あのクマのやつがいる。
takasek：そうそう。そのenchant.jsでゲームを作ったりもしていました。
banjun：ゲームを作ってたんですね。
treby：UEIさんのほうにはどれぐらいいらっしゃったんですか？
takasek：大体4、5年ぐらいかもしれないです。そこでいろんな技術を覚えさせていただいたんですが、その中で一番やっていたのがiPhoneのアプリ開発の部分ですね。
そういったところで数をこなしているうちにこれをメインでやってみたいなっていうふうになったときに当時の知り合いが事業を起こすという話を聞きまして。
treby：起業するとか？
takasek：はい。そうです。その人となんかそろそろiOSの仕事やりたいと思ってるんだっていう話をしたら、「そしたらうち来てください」っていう話を聞いて。立ち上げたばっかりのベンチャーの会社でした。
treby：とはいえ現職がある中でリスクしかない立ち上げみたいなのに飛び込むってなかなか勇気いることだと思うんですけど、どういう志なんですか？もう楽しそうだから行ってみるみたいな感じなんですか？
takasek：そのときも、流れが来てるんだったら乗ってみるかみたいな感じで。やっぱり技術ってポータビリティがあると思うので、身につけていれば次のとこでも生かせるし、どこでもやっていけるんじゃないか、そういうことは思いましたね。
treby：移ったのがいつ頃の話になるんですか？
takasek：それが2009年から5年働いて、フリーランスとしてスタートアップにジョインしたっていう感じですね。それが2014年の話です。
banjun：フリーランスになったのはそのスタートアップに入ったとき？
takasek：そうです。
banjun：そのタイミングなんですね。
treby：そうか。今、takasekさんってフリーランスのイメージが強い。
takasek：はい。そのときからずっとフリーランスで、そのあとは就職はしていないです。
treby：従業員として働いてはいないってことですね。
takasek：はい。フリーランスって言うと、ちょこちょこいろんな案件を受けるイメージもあるかと思うんですけれど、僕はあんまりそういうことがなくて。最初入ったところでもそこ一本で1、2年ぐらいやっていました。
文筆業とフリーランス(27:29〜)
treby：それだとフリーランスにした理由って何かあるんですか？
takasek：そこがですね、実は僕、文筆業をやっているんですよ。前の会社勤めしているときに、出版のお仕事をいただいて小説を書いて出版するっていうことをやっていました。
なので、その仕事とどっちも続けられるんだったらフルタイムでコミットするというよりは柔軟に仕事を振り分けられるようなそういう勤務体系がいいかなと思って、それでフリーランスをやっています。
treby：従属するというよりはちゃんと自分の複数の収入があっても大丈夫なような体制を整えたっていうイメージなんですね。
takasek：そうです。
banjun：そのときはじゃあプログラミングのお仕事のほうは週5ではなかったんですか？そのときからもうすでに。
takasek：はい。週4で入って1日は執筆活動みたいな感じをしていて、執筆のほうが忙しくなったときには執筆のほうに集中するという、そういうわがままも聞いてもらいました。
banjun：デフォルトは週4で入ってるけど、そこは変動するっていう。
takasek：はい。
treby：なんか唐突に執筆業がきましたね。唐突に。UEIとはかぶってるんですか、執筆業の時期は？
takasek：はい。かぶっています。
treby：その頃からサブとしてやってたんだけども、今度キャリアを変えるにあたって両方ちゃんと両立できるような体制って考えたらフリーランスになったんですね。
takasek：はい、そうですね。
treby：なるほど理解しました。では、1、2年ぐらいそちらのスタートアップを手伝われてたわけですけど。
takasek：結局そのスタートアップはクローズすることになりまして。じゃあ次に何をやるかなっていうのでいろいろ考えたんですけれど、そんなときに勉強会にじゃあ行ってみるかと思って勉強会にいろいろ顔を出して。
その中で仲良くなったのがFiNCっていう会社でして。そこで続けてみたら意外と長続きして3年半以上ずっとやらせていただいてる感じですね。
treby：それまでは勉強会行ってたんですか？
takasek：最初のスタートアップの頃には勉強会には全然顔を出ししていなくて。「俺が今までやってきたこのやり方が良いんだ」っていう感じで、俺はこれだけ経験を積んでいるんだから正しいやり方をしているはずだっていう、そういう感じで結構うぬぼれてるところがあったんですね。
treby：自信満々に。
takasek：はい。だけどそのスタートアップのところで一緒にやってるメンバーがある日、「ちょっと来て」みたいな感じで声をかけてきて。何かと思ったら今の作り方がちょっと悪いとこれでは非効率過ぎだと。これだとどんどん納期とかも遅れていくし、うまく作れないと。
だから、まず認識を擦り合わせたほうがいいっていうふうにその人が言って始まったのが。その人がまずマーティン・ファウラーって知ってますか？っていうふうに言ったんですね。誰それ？って思ったんですけど。
treby：Refactoringとかね。
takasek：マーティン・ファウラー。設計の世界でのすごい強い人ですよね。マーティン・ファウラー、今では知らないとモグリだみたいな感じなんですけれど。その人の名前も知らない段階だったんですけれど、その人が関心の分離というものを大事にして。
なので、モジュールはこれとこれはこういうふうに分けるべきで、それはMVCというのはこういうものであって、それを分けていくとこういうメリットがある。
そのためにはオブジェクト指向のSOLID原則がかかって、こういうふうにやっていくべきだっていうような、そういった話を結構バーっとされて。そういう講義を1日受けたんですけれど、そうすると次の日から目に見えて開発の効率が変わったんですね。
それまで自分で手を動かしながら自分のベストなやり方を探ってきた。自分なりのやり方っていうのを自信を持っていたはずなのに、全然見えてる世界が違ったんだと。
もっとちゃんと考えている人が世の中にはごろごろ転がっていて、そういう巨人の肩に乗ることによってちゃんとやれるんだっていうことに衝撃を受けまして、それから勉強会に行き始めた感じですね。
treby：じゃあもう就職する前、したあともずっと行ってなくて、そのスタートアップの会社で1、2年ぐらいやってる中で言われてから行き始めるようになった。
takasek：そうなんです。本当目覚めたのがそれからという感じです。
banjun：それが設計の世界へつながっていくわけですね。
treby：設計の話。2010年代らしいですよ。まだ10年経ってないんですって、勉強会行き始めて。そんなtakasekさんがもう設計の第一人者みたいな感じに今なってますから。
banjun：それがきっかけだったのかもしれないですね。
FiNCでのお仕事内容(32:20〜)
treby：それで勉強会行き始めてFiNCさんと出会いましたと。FiNCさんではどういうお仕事をされてるんですか？
takasek：FiNCさんのアプリが何が面白いかって言いますと、あれ結構全部入りのアプリみたいな感じなんですよ。
SNSみたいな機能もあるし、フィードを読んでいくような機能もある。あとチャットみたいなところもあるし、あと自分の健康状態を記録するためのログ管理みたいな機能もある。
たくさんタブも分かれているし、その中でデータの整合性とか気をつけると無計画にやっているんだとすぐにヤバくなっていく、そういうものなんですね。
treby：破綻しちゃうと。
takasek：その中でちゃんとやっていくっていうことになると、ちゃんとした設計の考え方とかを意識しなきゃいけないし。
あとすごく刺激的なのが降ってくる案件、どういう用件でこういうのを作りたい、こういう機能を入れたいってなったときに、その機能は本当に必要なのかとかそれを変えるとどこに影響があるのかとか、そういったことちゃんと大局的に考えてその案件の調整をしつつアプリを育てていかなきゃいけないっていう。
そういうほかの人たちとやり取りをしながら、最終的にいいアプリを作っていくっていう、大局的な視点を養えるのがすごく刺激的で、それが好きで3年半以上やっている感じですね。
treby：前々回ぐらいいらっしゃったota42y(太田)さんもサーバーサイドやられてたわけですけど、takasekさんはアプリ側ってことですかね。
takasek：そうですね。
勉強するための時間をとる働き方
treby：FiNCさんは週5で働かれてたんですか？それともそうじゃない。
takasek：最初は確か週5だったと思うんですけれど、だけど週4、週3となって、今は週3ベースでずっとやっています。
treby：稼働日数を変えたのには何かほかの所を手伝うからとか理由があったんですか？
takasek：はい。それは副業もそうなんですけれど、あともう一つの理由としてはやっぱり自分の基礎知識が足りていないと思って。
それを調べたりとか、あと勉強会で縁を知ったし、勉強会に対して自分でフィードバックをしていくとか、自分が分かったことを伝えていくことが大事かなっていうふうに思って。
勉強会に出るためにまず調べる、調べたことをみんなで共有するといった、そういうサイクルをやっていきたいなというふうに思って、そのために1日以上は取りたいって考えで。
treby：ということは今お仕事をされているのは主にFiNCさんっていう状態、なんだけども週3でやってるっていう。
takasek：そうです。
treby：すごいですね。アウトプットのために時間を作るっていう。
banjun：時間割上その勉強の時間っていうのを取るのはすごく難しいことだと思うんですけど。
treby：ある種理想的なエンジニアのキャリアというか、働き方ともいえる気がしますね。模範的というか。
banjun：そういうのはありますね。
treby：やりたいと言いつつやれてる人はどれだけいるのか。
banjun：時間が有限であることを認識しつつもやっぱり時間を取るのは難しいっていうのは多分大半だと思うんで。
treby：特に稼働を減らすってなったら収入も減っちゃうわけで、そこをちゃんとやっていってるのはすごいなって思いました。
takasek：ただそういう意識高いことを言いつつ、勉強として充てた日になっても結局グダグダして起きるのは12時過ぎてからだし、そのあともご飯を食べながらテレビでアニメを見たらそしたら気になってそのまま次の回まで見てしまうとか。
そういうこともあったりしますけれど、やっぱり自己管理っていうのは大変ですね。
treby：自己管理の話を深堀りできそうだね。割とね、どうやって自分に鞭打つかとかね、割と気になります。
banjun：takasekさんは「勉強会駆動勉強」と言ってるんでしたっけ？
takasek：そうですね。
treby：勉強会に出すために勉強するっていうことですね。
takasek：はい。
treby：実際それでやられていった結果、その本を書いたりとかもされてるわけですよね。
takasek：『iOSアプリ設計パターン入門』という本で設計とかアーキテクチャの話を書くことができるっていう、そういう機会もできることもあったので。アウトプットってちゃんとそのあとにつながる活動になるなっていうのは思います。
treby：その勉強のための勉強を取ろうってし始めたのはFiNCさんに入って何年目ぐらいからの話だったんですか？
takasek：それはもう最初からでした。
treby：一番最初の最初は週5だったんだけども、まず勉強するために1日取ります、週4にしましょうとかって感じで持っていったわけですかね。
takasek：そうですね。
banjun：フリーランスで週5で入っていって、そこから勉強の時間が必要だってなって本当に時間を確保するために週4にするとかっていうことなんですけれども。
会社員として雇われていた場合あまり週5のものを週4にするとかって柔軟にはできないんじゃないですか。でもその代わり週5ある勤務時間の中で実質1日分とかを勉強に充てるとかっていう、その労働時間の中で週に1日分ぐらいを確保するみたいな、そういうやり方。
勤務として勉強に充てるみたいな、そういう調整もできなくはないのかなとかって思ってるんですけれども。
takasek：そういうのができる会社の社員になるっていうのも手なんじゃないかなっていうのはよく思います。あとフリーランスだと勉強会に行くとかあついはカンファレンスに行くとか、そこの部分が主にならないんですけれど、会社員だと一つの業務としてカンファレンスに行くっていうことができるというのも魅力ですよね。
banjun：フリーランスであったからやっぱりその辺は、フリーランスで勤務日なんだけど勉強に充てますっていうのはやっぱりしづらいから、もう週4にしますっていう調整をやっぱりせざるを得ないんですね。
takasek：そうですね。なので、フリーランスっていう前提の中でやるんだったらそうなるなという話で、会社員として勉強の時間をちゃんと取るとか、あるいは会社として取るような流れに乗るっていうのはすごくありな選択肢だと思います。
banjun：ありですが実現性はどっちが高いかみたいになると、多分そういう難しいバランスがあるような気がしますね。
takasek：どうなんでしょう。そういう会社員をやったことがないので。ただちゃんとできてる会社も多分ありますよね。
banjun：古くは20%ルールとかってありましたけど、最近あんまり聞かない気もしますけどね。
treby：融通は効きやすいですよね。会社員ある意味、定額なコストで雇われているから、働いてようが働いてましが毎月これぐらいは入ってくるのはある。一方で給料上げづらいとかはあるかもしれないんですけど。
フリーランスはその点、ほかのいい所があったから移りますっていうのがあるから比較的やりやすい。もちろん長くやってたら関係性とかもできますし、下手なことはできないかもしれないですけどね。
文筆業を始めたきっかけ(39:26〜)
treby：ちょっと話戻っちゃうんですけども文筆業をやり始めたというか、やろうって思ったきっかけとかってあるんですか？
takasek：それもやっぱり僕結構流れでやることが多いんですけれど、偶然そういう話が入ってきたという感じですね。
treby：やってみたら出版できそうになったので、それでやってっていう感じなんですね。
takasek：もともと文筆業は大学のときに目指したことはあったんです。
最初は漫画家だったんですけれど、就職活動するときにまず漫画を1本描いてそれを投稿してみる。それが箸にも棒にもかからなかったら普通の就職をしよう、そういうことをやったこともあったので。
話をいただいたときにそれをやれるっていうのは、しかも仕事をやりながら副業としてやれるっていうのは結構渡りに船だったことはあります。
treby：魅力的だったっていう感じですね。
takasek：なので、そのあとのフリーランスになるというのも、その可能性をつぶさずに今後も継続できる形で何とかキャリアを組みたいって考えました。
treby：でもそこで選んだフリーランスという手が稼働日数を減らして調整するっていうのをやりやすくしたっていう意味では、すごくつながってる感じがありますよね。
takasek：そうですね。
banjun：うまくいってますね。
treby：勉強会駆動勉強会じゃないですけど。いい言葉だなって思って聞いてたんですよね。自分だったらtakasekさんにとっての「たまにある日」が毎日続きそうだなって想像では思うんですけどね。
banjun：たまにね、アニメばっか見たりっていう。
treby：起きたら昼過ぎみたいな。それただの無駄だからね、人生の(笑)
takasekさんのキャリア戦略
treby：じゃあ今はそういう働き方をされているわけですけども、今後どうしていきたいとか、どういうところ狙っるとかあったらお聞かせ願いますか？
takasek：実は先々週末にJAISTという北陸先端科学技術大学院大学っていうところの説明会に行ってきまして。うまくいけば来年の4月からその大学に通ってみたいなというふうに思っています。
それはどういうものかって言いますと、品川の東京サテライトっていうところがあって、その品川だと働きながら土日とかあるいは平日の夜とかにある授業を受けながら仕事と並行して学ぶことができるっていう、そういうプランがあるんですね。
なので、そこでコンピューターサイエンスをしっかり学んでみたいなというふうに思っています。
banjun：講義を受けてレポートを出して単位をもらうみたいな、そういうイメージなんですか？
takasek：そうです。どういうふうにやって単位をもらうのかは分からないですけれど、とりあえず単位がたくさんの授業を受けることで手に入って、そのほかに自分の研究もちゃんとやって提出することによって卒業資格が手に入る。そうするとMaster(修士)としてやることができる。
banjun：コンピュータサイエンスの修士が得られると？最終的に。
takasek：そうなんです。
banjun：そうなんですね。研究っていうのはどうやるんですか？どこかの研究室に所属する感じになるんですか？
takasek：はい。ゼミがあるらしくてですね。そのゼミも社会人に最適化された形で。このJAISTって石川県に本部があるんですけれど、そちらのほうでは社会人じゃない学生たちがみんなで集まってゼミで研究をするっていうスタイルが主流なんですね。
東京のほうだと社会人がそれぞれ個別ゼミとしてそれぞれ教授と話し合いながらそれぞれの研究を進めていくっていうことをやっています。
その研究内容として説明会のときに興味深いなと思ったのが、今やっている仕事に密接した形で、あるいはもし会社の仕事のことが外に出せないとかがあっても趣味の活動とか、今やっている活動に合わせた技術を経営にどういうふうに生かすかとか、コンピュータサイエンスをどう生かすかとか、そういったことを研究テーマにしてくださいという、説明されていました。
treby：そのコースは社会人が受けることが前提にあるんですね。takasekさんの期待値としてはコンピューターサイエンスの基礎を学びたいというところにあるんですかね。
takasek：はい。コンピュータサイエンスの基礎を学びたいというのがもちろんあります。ただそれがどういうふうにいくかっていうのは知識を得ることで見えてる世界っていうのはどんどん変わってくると思うので、その時々において判断したいなというふうには思っています。
なので、今はとりあえずその先人たちの積み重ねた研究の宝の山が目の前にあるので、よっしゃまずはこの宝を手に入れるぞっていう、そこを考えていますね。
treby：いいですね。ワクワクしてますね。
takasek：ワクワクしてます。
banjun：そういう意味では基礎というか先人の知恵的なところは講義で手に入れつつ、やってみたいテーマとしては大規模アプリをそう作るかみたいなところなんですね。
takasek：今のところはそうです。
banjun：それはもちろん変わりますよね。学習していく中で。
お手紙「takasekさんのペンネームを教えてください」(44:29〜)
banjun：それではいつものコーナーやっていこうと思います。今日はお手紙をいただいておりますので、そこから紹介させていただきたいと思います。まず最初の手紙は@1024jpさんからです。ありがとうございます。
takasek & treby：ありがとうございます。
banjun：「いつもお世話になっております。takasekさんのペンネームが気になっています。そろそろ教えてください。よろしくお願いします。」とのことです。
treby：takasekさんのペンネームってtakasekじゃないの？
takasek：takasekですよ。あと『iOSアプリ設計パターン入門』という本では「関義隆」と本名が出ておりますね。
banjun：見たことありますね。
treby：フルネームですね。
takasek：ほかにペンネームありましたかね。
treby：あれじゃない？文筆業の。
banjun：え、もしかして。
takasek：……言い逃れできないんですよね。話し出しちゃいましたもんね。
treby：逆にペンネームをどうしてそこまで守りたいっていうふうに思ってるかっていう、そこの話になるんじゃないですか。というのも恥ずかしいからだとか、リアルバレするからだとか。
takasek：ずっと、これ聞かれるたびにすごいごまかしてきて。エンジニア界隈で知ってる人ほぼゼロだったんですけれど。
何でバレさせたくないかってようやく最近分かったんですけれど、エンジニアの仕事って結構本名と結びつくじゃないですか。
普通に写真とかも上がるし、カンファレンス行けば写真撮られてたり動画が上がったりするし、GitHubでもソースコードのところのヘッダーのコメントに自分の名前が出てたりとか。
なので、あんまり自分の名前が匿名でやれてないと思うんですよね。だけど文筆業のほうはどうかって言うと、リアルネームを出さないで、普段の生活とかもあんまりそこに紐づけられないっていうのがあって。
もしこちらのエンジニアのほうで文筆業のペンネームを言ってしまうと、そこがたどれてしまうわけですね。ということで、そこのセキュリティホールをなくしたみたいな、そういうことなんだなって最近自分で思いました。
お手紙「設計についての学習のきっかけや手法を教えてください」
treby：じゃあ続きましてペンネームねずみさしさんからいただきました。ありがとうございます。
banjun：ありがとうございます。
treby：「takasekさんといえばアーキテクチャパターンなどの設計に詳しいイメージがありますが、設計について学び始めたきっかけや動機、どうやって学んできたかなどを教えていただきたいです。」だそうです。
takasek：これもなんかさっきちょっとしゃべっちゃった感じがするんですけれど。
最初はもうそんなの全然なくて、オレオレ設計ですごいうぬぼれてたんですね。だけどそれに対して、「おいお前それはちょっと違うんじゃねえの？」っていうふうに一緒に働いてる人が抗議をしてくれまして。
そのときに、「あ、そうなんだ」っていう、視界がバーっと開けたんですね。そこが本当に転換点だったと思うんですよ。設計について学ぶことって何かって言うと、その設計って要は何か現実問題のごちゃごちゃしたものがあります。それに対してエンジニアリングで解決したいです。
じゃあその中でごちゃごちゃからまりあってる現実をうまく再解釈する、そのための構造を作ります。それに対して解決するための構図を作りますっていう、その構図をどうするかっていうのが設計。
なので、設計をするにあたってパターンがありますよと、似たような種類の問題に対しては大体似たような解決策が適用できますよと。じゃあその似たようなものをまとめますよっていうのが設計パターンっていうものだし、じゃあそれを組み合わせるときに、なんか似たようにみたいに見えるけれど、やっぱりそれ似てなかったねって、これ一緒にしちゃいけなかったねっていう、そういう反省とかもあって。
じゃあそれをどういうふうに何が違うのかみたいなのを気付けるために設計の原則みたいなのがある。っていうので、その原則とパターンっていうのをうまく使いながら設計をやっていく。
そういう先人の知恵を使っていくと、物事がどんどんクリアに見えるようになることですね。なので、物が今まで見えてなかった部分が、視界が開けるっていう原体験もあるし、その視界の解像度をどんどん上げていきたいっていうふうに思って、設計についてどんどん学んでいこうと思っています。
自分がオレオレ設計でうぬぼれていても、それって大体今までに考えて検討されて、穴があるからこれ駄目だねってさらに先まで行ってるものなんですよ。
大体中国の四千年の歴史の中で言われているようなものなので、自分の頭で考えようとかよく言われたりするけど、自分で頭で考えるほどに、お前頭いいのかと。
それよりかはちゃんと先人の知恵っていうものを尊重して学んで、その上でそれをうまく使えるっていう、そこに力を注いだほうが見えてくるものがあるんじゃないかなっていうのが設計についての今のスタンスですね。
treby：ありがとうございます。設計は中国四千年の歴史の中で語られてきたと。
takasek：中国かな？中国かどうかは、ちょっと勢いですかね(笑)
treby：中国ではない？(笑)中国四千年の歴史と同様に歴史があるものだという主張ですね。
takasek：みたいな感じですね。
treby：設計を学ぶモチベーションのところ今の話で分かったかなって思うんですけど。じゃあHow。どうやって学んでいくかっていうところについては、これから設計に興味がある方について、何か言えることはありますでしょうか？
takasek：やっぱり実践と座学の両輪だと思うんですよ。よく分かんないものを読んだときに、大体こういうことなのねって思っても実際に使ってみないと気付けないことはたくさんあるし、逆に自分でやることだけを優先してしまうと結局オレオレの穴のある概念にしがみついてしまうことになるので。
どっちもやりながらこれってどういうことなんだろうっていうのを、知識を深めるためにやる。そのやってきたことをさらに抽象化して考えて一段上から見て、これとこれは似ているよね、自分がやったこの経験と近いよね、でも僕は違うねみたいな、そういう違和感があったらそこについて深堀りするっていうふうにやっていくと解像度が上がっていくんじゃないかなと思います。
treby：じゃあこれから設計学びたいと思った人の第一歩としては、自分がリアルワールドでやっている、手を動かしてやってるところを、知識としてはどういうことなのかに結びづけをしてみることがいいっていう感じですかね。
takasek：そうですね。
banjun：実践というのは何でもいいんですかね？っていうところがちょっと気になっていて。普段仕事でやってるようなものに対して学んだ設計の知識なりを適用するっていう実践ができると、かなり実践としては良いものというか、それ以上の機会ってなかなかないと思うんですけれども。
趣味プロダクトみたいなところ、自分しか触らないようなコードを実践の対象にしてもいいのかなとか、あんまり得られる効果は少ないのかなとかって思うんですけど。
takasek：それを得られる効果が少ないような縁遠いようなところって、別に学ばなくていいんじゃないかって思うんですが。
設計って何かって、その設計に対しての問題がないとそれに対しての設計を適用できないので。解決すべき問題不在の設計って意味がないと思うんです。
なので、何か問題があったときにそれに対してどういうふうに設計できるかなっていうところを深く考えていくっていうことが学びにつながっていくんじゃないかなって思います。
banjun：ということは本当に一番最初はまず課題を認識するというか、たくさん拾い上げられることのほうが大事なんですかね。
takasek：そうですね。これが問題だっていうふうに分からないとそもそも解決しようと思わないっていうのがありますよね。
banjun：問題かどうかを洗うために、設計パターンで何が問題とされていたかっていうのはとっかかりになるのかもしれないですね。
treby：逆説的。
banjun：逆説的な話ですけど、そういうことなんですかね。
takasek：ありそうだと思います。
treby：あと実践の定義ですよね。オレオレパターンでもぶっちゃけ自分一人しか触らないコードだったら、まあ多くても困らなかったら自分自身だけというか、過去の自分が何でこんなん書いてるんかよく分かんないっていうことだけだと思うんですけど。
チーム開発だとそうはいかんわけですよね。いろんなメンバーいますし。知見として持ってると多くの人とやっていく上とかでコモンセンスとしての設計のパターンとかがあったりだとか、これ読んどいてとかができますしね。
takasek：それも結局問題を解決するっていうところに当たると思っていて。チームのメンバーがたくさんいるけれどそれぞれがやっていると整合性が取れない。
じゃあどうするのかっていう問題に対して、このアーキテクチャパターン、これを使いますっていうのをプロジェクトレベルで動きますっていう解決策があるっていう。
treby：意思疎通ができないっていうことが自体を問題だというふうに捉えるわけですね。
takasek：はい。コンウェイの法則に近いと思うんですけれど。組織の形がそのまま設計の形になる、アーキテクチャの形になるっていうのがあると思います。
シニアな悩み「レビューの属人性をなくしたい」(53:26〜)
treby：続きまして「シニアの悩み」のコーナーに行きたいと思います。takasekさんもエンジニアとして長く働かれてますというところなんですけども、最近自分自身が考えてて悩んでいることとかがあったら教えていただけますか？
takasek：悩みとしては、今FiNCさんで長年いると、その中でどういう問題が起こってきたとかコードがこういう経緯でこうなったとか、そういうこともたくさん知っているので、レビューが割と僕に偏ってくるんですね。
そうするとそういうレビューとしてこういうことがあったよとか、こういうことがあるからこのコードは良くないとか、ほかの部分でこういうコードがあるからそれ使うともっと楽にできるよとか、そういったことをレビューのときに言うことが多くて。
そうすると情報伝達のコストでっかいし、レビューを僕が通さないといけないっていう、そういうクリティカルパスになってしますのはちょっと問題だなというふうに思っていて。
暗黙値じゃなくて形式値にするみたいな部分もやりたいとは思うんですけれど、じゃあたくさんドキュメントを書けばそれでいいかっていうと、結局そのドキュメントが多すぎても読まれないし、どういうふうに属人化をなくしていけばいいかなっていう、そういうのが結構今悩んでいるところです。
treby：takasekさんと同様にその知見を持ってる人っていうのは社内にいらっしゃるんですか？
takasek：そうですね。いらっしゃいますが、その人たちにたくさんのコストがかかっていくっていうとあまり良くないですので、それをどういうふうに分散していくかっていうのは、結局は何人いようと問題は変わらないんじゃないかなと思います。
treby：割合の話だと思っていて。全員のその情報の量が均一であればそんなに、そこは。それぞれで分散できると思うんです。コンテキストを知らない人はそこそこの割合でいるとかいう話ですか？
takasek：そうですね。たくさんの機能もありますし、コードベースも大きくなっていると。
banjun：それはドメイン的な情報量なのか、あるいは単純にプログラミング的な？
takasek：どちらもあると思います。あと技術的な話だと、昔リプレイスしようとした機能が半端に生き残っていて、その負債のためにこうしなきゃいけないっていうのがまだあるとか。
treby：でもなんか今の話聞くとそれがボトルネックになっちゃってるっていう分析できるのであれば、そこ先にやっちゃったほうがいいよねっていう判断もしやすいのかなと思ったんですけど。
banjun：私も日々レガシーと戦っているので、気持ちはよく分かります。
treby：戦わなければいけない部分はすごい分かる。
takasek：なので、なるべく早いうちにレガシーはつぶしていって、一度に解決しなきゃいけない問題は小さくしていくっていうのはやっていかなきゃいけないなと思いますね。
ただそのときに、じゃあ今実際に山積みになっている問題はじゃあどう崩していくのか、それを崩していくのと新しく作っていかなきゃいけないものをどういうふうにやっていくか。
古いものを崩していくとしたらその分新しいことができなくなるけれど、じゃあそれを許すような組織構想とか握りになっているかとか、そういったところをうまくやっていかなきゃいけないなとは思います。一般的に言うと普通のことに見えるんですけれど、なかなか現実は厳しいですよね。
treby：直面してると特に思いますよね。分かる。ちなみにtakasekさんはそこの問題に対してどう解決しようと考えているとかあるんですか？
takasek：個別の事情にいろいろ含まれるので、あんまりここで個別に論じても意味がない気がしますね。
treby：それこそこういう問題っていうのは一般化するといろいろな現場で起きてると思うんですね。全体に適用できるパターンとかを出す前にまずはユースケース、個別の事例みたいなので、うまくいった、うまくいかなかったみたいなのがあると納得感というか、追体験できるのかなって一つあるかと。
自分が直面してるの何だろうな。結局やっぱり上から落とすのが一番早いっちゃ早いんですよね、そういう場合って。
banjun：政治的な話ですか？
treby：政治っていう言葉は正しいのかどうかっていうのはさておきとして。例えばCTOレベルとかでそれやるって言ったら、やるっていうふうに動けると思うんですけど。CTO自体がそもそもあんまり経営とかの決定権に入ってなかったら、それもできないっていう感じになるからまた難しくて。
banjun：そこまでしてやりたいのかっていう話もあると思ってて。
treby：でも生産性落ちるんだったらやらなきゃいけないし、そこまでしてやらなくていいものは多分それは問題じゃないのでは？っていう判断になっちゃうのかな。
takasek：そこでタイムスケールが違うのが問題だと思ってて。
少しの間だったら我慢できるんだけれど、これ累積するとばかでかい負担になるよねっていうのがあって、しかもそれがちょっとの間だったら大丈夫って思ったものがたくさん積み重なると、結局一つ一つの問題は小さいんだけれど、一つ一つつぶしていこうとしても始末に負えないっていう。
treby：計測しづらいっていうのがやっぱりきついんですよね。いわゆる負債解消系って言われるやつ。
takasek：たけどじゃあそれを、機能をmasterにマージするときにはきれいな形にしょうってすると、masterにマージするのが遅れて、アプリを触って検証できるのが遅れてしまうので、それもなかなか厳しいし。
その時点で検証したものに対して改修を加えると、結局そこでQAやり直しとかに……。
banjun：機能開発したものに対してそのあと改修が入るよね。
treby：入ったらそれはまたやり直さないとってなるしね。
takasek：QAの人たちが潤沢にいれば、してくださいっていうので投げられるんだけれど、そこがボトルネックになっているとエンジニア側でちょっと泣かなきゃいけないっていうのはある。
masterにマージするクオリティとかを落としてしまえば、クリティカルパスは解消されるんだけど、じゃあそれをやっていいのかっていう。
treby：それを判断するのは誰っていうのはもう決まってる？
takasek：この判断が僕によってしまっている。
treby：なるほど……。
banjun：じゃあそのクオリティというのがそもそも何？っていう話があって、別にQAで不具合が出る出ないとかではなくて。
これが負債になり得るか、ならないかみたいな判断だと非常に属人的になる可能性が高いと思っていて、それを判断できる人材っていうのはかなり限られると思うんですよね。
treby：takasekさんが決められるか、決められないかっていう軸と決めていいのかな、決めちゃいけないのかっていう軸があると思ってて、前者は決められる、決められないっていうと決められるんですよね。
これはこうしたほうがいいっていう意見は言える。じゃあゴーするかゴーしないかっていうところがふわっとしてるか、やっていいんだろうかっていうところでそもそも悩んでる。
takasek：結局はその機能を作るほうの人の責任になるので。僕はあくまでこれはまずいんじゃないの？っていうふうに言うだけなんですけれど。
だけどその目が通らない状態で判断できるかっていうと、結局向こう側も「takasekさんも見ないと」っていうふになって止まってしまう。僕が週3でやっていると、じゃあいないときにお願いしたいときどうするの？っていう。
treby：ていうと、これはまずいですよって言ったら通るくらいにはチームにもう浸透はしてて、逆にそれがボトルネックになっちゃってるっていう話ですよね。
安心感持ってマージできないから週3の稼働のtakasekさん、待つしかないみたいな。
takasek：はい。一つ解決策としては、そこまでの判断を必要とするようなものはプルリクを出すより前に設計レベルでちゃんと握っておこうっていうのはありますね。それで大体解決する問題はあると思います。
だから全ての問題をすぐに解決しなきゃいけないわけではなくて、解決できる手段が複数あるんだけど、それを一つ一つやっていって問題を小さくしていこうっていうことは大事なのかなって思います。
知見の共有方法と技術的負債(1:01:50〜)
treby：まあそうですね。レビューのコストを最小化するにはまあ。様々なレビューってコードレビューだけじゃないのか、設計レビューとかも入って。
takasek：設計レビューとかも入ってきます。
treby：最小化するためにやってることは何だろうね。ちっちゃいチームだから密にコミュニケーション取ってたかな。大きくなってくるとやっぱり知識をインプットする場とかを設けてますよね。
今Repro社とかはエンジニア40人ぐらいいるんですけど、ここ半年ぐらいですかね、新入社員向けのオンボーディングの会をやるようにしてます。
やっぱり背景には新しく入ってきた人がパフォーマンス出すまでにドメイン知識だとか、あとはチームのルールだとか、そういうところ分かんないよねっていうことで行ってることなんですけど。そうやってクオリティ一定化させていくっていう努力は必要なんじゃないかなとは思いますよね。
banjun：ドメイン知識の共有もそうだし、コーディングの技術、設計の技術もそうなんですけど、勉強する会をやったから身につきましたみたいな簡単な話ではないような気がしていて。
treby：もちろん、もちろん。
banjun：そこがそろうまで結局レビューコスト下がらないんだ、と実践的には使えないというか。もちろんやって悪いことはないと思うんですが、その知識に偏りがある状態でなおそのレビューっていうはやっぱり回していかなきゃいけないというか、だからこそレビューがあるかもしれない。
treby：もちろん。
takasek：レビューの目的にはいろいろありますよね。知識を伝達する目的もあるし、あるいは今の構想に対してチェックする品質担保の目的もあるし。
品質担保の目的であれば解決策として一つとは、PRが出るよりも前になるべく早く設計のレビューなり、仕様のレビューになり、そういうのをこまめに入れていくことによって方向性の間違いを最小限にするっていうのが一つの手になって。
品質担保ともう一つで学習の面でレビューのコストを最小限にするためには、例えばペアプロとかそういうのもあると思いますね。
banjun：ペアプロは良さそうな感じありますけど、どうですか？やってますか？
takasek：はい。ペアプロっていうほどフォーマルというかしっかりしたペアプロではないかもしれないけれど、直接対話しながらやっていくとやっぱり情報の伝達効率は上がりますね。
banjun：それによって単純に知識の伝達ですかね、レビュアーしか知らないこと教えてあげるというのにも役に立つといいなとは思っていますね。
takasek：そうですね。
banjun：ペアプロなのかなペアプロメインか、一緒にコードを書くという時間を取るきっかけをどうするかっていう話で、そこはレビューコメントから生まれるのか、計画的にやることなのか。だからPRを出す前に、どうしてますか？
takasek：どっちのパターンもあり得ると思って。もしそのコードのところをいじるのがあんまり慣れていない人がアサインされて、知識を伝達するのが口頭とかドキュメントだと難しいようなときだったら、ある程度それは先に分かっているので。
じゃあここはペアでやったほうが早いねっていう判断は先に入れられると思うんですね。あるいはそれでできなかった場合にもプルリクを見ていて、なんかコメントが10個以上つきそうだぞみたいな。
ちょっとやばい雰囲気があれば先に対面で話したほうがうまくいくパターンはあるかもしれないですね。
banjun：レビュアーとレビュイーについて、結構今、非対称な関係があるのかなというふうに見ていて。僕もそうだから、そう見てるんですけど。
「PRを作る人が何人かいます。そのPRに対してレビュー待ちになるのはtakasekさんのレビュー待ちになることが結構あります」みたいな課題があって、そこをいつか分散したいということについて。
その段階でドメイン知識が何かが足りてなかったから、結果としてやばいコードになっているとかをtakasekさんが指摘しますとかっていうのをやって歩いてるかもしれないんですけれど。
それはたまたまそのPRを作ったメンバーがその観点が抜けたまま実装していただけで、ほかのPRを作ったメンバーは知ってるかもしれないけど、単純にそのPRをレビューしてなかったから指摘できなかっただけとかだと、隣の人のレビューをするというのをやるだけで、もしかするといいのかなとかって思ったんですが。
takasek：それでいける部分もあるし、それでカバーできない部分が膨らんでいるっていうのが問題なのかな。
banjun：それ以外の部分の問題のほうが圧倒的に大きくて。
takasek：古くからいるから分かる部分っていうのが大きくなってしまっている。
treby：コードベースというか、プロダクトがっていうことですかね。ワンリポですか？
takasek：はい。アプリ自体はワンリポです。
treby：ota42yさんの場合とは逆のパターンっぽい感じがしますね。あっちはマイクロサービスでいうサービスが……
banjun：そうですね。分けていて、むしろマイクロサービス単位で見る人がいなくなるかもしれない心配とかっていう人が足りないって言ってましたね。
treby：アプリの場合は逆に一つのリポジトリだから、それにいろんな人がやっていろんな機能もあるんだけど、ある機能については知ってる人知らない人っていうのがいて。
banjun：そもそも巨大であるというところがキーポイントな気はするんですけどね。
takasek：あとマイクロサービスはそれぞれサーバーが独立でデプロイしてるけれど、要はそのパッケージの単位ってデプロイの単位なので、アプリはどう頑張ってもまとめてデプロイするしかないんですけどね。
banjun：それはそうですよ。ユーザー体験に直結するから分割する、しないというのは難しいんですよ。
treby：そうだよね。アプリの場合は大変ですよね。アプリっていう単位ですから。
takasek：マイクロサービスの場合にはそのサービスごと捨てて置き換えることができるっていう部分を意識すると、もうサービスオーナーがいいって言えばそのままやってしまって、その学びは次のサービスに生かせばいいやっていうのがマイクロサービスのおおたさんのときに話していた話だと思うんですね。
アプリの場合には一つのリポジトリの中でずっと生き残ってしまうから、それをやらなければいけない。ただ切り離せるところを意識するっていうのが一つの解だと思いますね。
あるところのインターフェイスさえ合っていれば、そしてそこからグローバルな何らかにアクセスするとかがなければ、ある程度はその中で抑えられるだろうという。
そこの部分であればあまり厳しくは突っ込まないっていう形でやっていけば、そこの部分を直したいときにはそこの部分だけ影響を止められるから大丈夫ということは。
banjun：大枠としてマルチモジュールみたいなのを切ってしまいますという前提があって、そうすると多少おかしなコードが入ったとしてもその影響範囲はある程度歯止めがかかるので、レビューが要求する水準がちょっと下げられるから楽になるという。
takasek：そういうことです。
banjun：そういうことですよね。
treby：同じリポジトリとか触りやすいところだったら、なかなかうまくいかないかなっていうふうに思ってますと。何でかって言うと、ちょっと微妙なコードって局所的に入ることって少なくないですか？
結構広い範囲で値を受け渡すときに変わっていくというか、引数から変わっていくみたいな感じで、分散して入っていくので、そういう渡し方をする？みたいな、あるような気がしてて。
なんかモジュール単位逃してるっていってても、いじりやすくしてたらそれだけでもうすぐに、ここで分離してたのに密結合になっちゃってるとかあると思うんですけど。
takasek：それをする前に多分止めるられるためには、PRレビューよりも前にインターフェースをレビューしようっていうところになるんじゃないかなと思います。
treby：厳密にしようとしたら全部のプルリクとかをレビューしなきゃいけなくなって律速するわけですね。
banjun：どうやって自分のレビューで開発速度を下げないかというのは非常に自分の身にも思い当たる、めちゃくちゃ痛い話ですね。
treby：あと共有知にできてるといいんですけどね。そこのインターフェースのところっていうのが。でも大体時間経つとそういうのって薄れていくし、弱いんですよね、規約というかこういうふうにしましょうっていうのを決めるっていうのは。
banjun：ルールが独自性のあるものであればあるほど共有は難しくなっていく。
takasek：結局それを使うか使わないかっていうのもケースバイケースになるから、それをルールとして定めてしまうと、じゃあそのルールを使うの？使わないの？っていう議論が生まれてしまうとかえって効率を落とすことにつながってしまう。
banjun：モジュールを切るとか依存の方向を管理するとかっていうのは言語的というか、ビルドシステム的に厳密にできるとは思うんですけど。それを厳密にやったところで概念的な蜜結合っていうのが発生するから、そうならないようにしましょうっていうと結局ルールが必要になってくるから。
ルールと何らかのビルドシステム的な機能とがうまく合致するところにみんながいければいいんだけど、それは結局情報共有の問題に戻るだけだよなっていう気はしなくもないですね。
takasek：やっぱりいける部分といけない部分を見極めて全部を一つの解決策で解決すんじゃなくって、なるべく軽減できるような策をいくつも打っていくっていうのが一般的なパターンになりますかね。
treby：その部分なったときに、これはこうだよねっていうケースバイケースっていうのが人によってまた違うっていうのがですね、出てくるわけですね。本当に進めながらやっていくしかないっていう気はしておりますと。
ルールベースじゃなくてできることベースで分けても、今度はビジネス上の要求が変わったときに柔軟に対応できないとかいうのも出てきたりしてですね。……この話は延々とできますね。
takasek：延々とできますね。
banjun：あと巨大なアプリの中にレガシーがあるパターンっていう。奇遇ですが私も同じようなアプリをメンテしてるんですけれども、そのパターン、レガシーがあること自体を除去できればいいよねっていう話がさっきもあったんですけれども。
レガシーがあると面白いのは、新機能開発で新たなレガシーを日々生産する、そういうフォースが働くんですよね。
あるレガシーの部分と強調して動く新機能を作らなければいけないときに、新規の部分も何やらレガシーな書き方で書かれると。そこに対して人によってはそうするしかないみたいな諦め的な書き方をすることも結構多くて、そうすると本当に雪だるま式にレガシーが増えていって。
本質的にはもともと放置されていたレガシーが悪いといえば悪いんだけど、割と最近作られたレガシーというのがいっぱいそこら中にあるなあ、みたいな世界がすぐ来てしまうんですね。
そこを防ぐために新機能を作るときに、レガシーのものを触りつつもできるだけ理想的なモダンなものにする。モダンなものを置いてレガシーとの橋渡し部分を小さくするみたいな技術が結構大事だなと最近思っていて。
本当はレガシーを消したいんですよ。消したいんですけれど、とはいえビジネス要件でいろんなものが生まれていく中で、生まれていくものの中に新しいレガシーを作らない技術って、そこはある程度技術でカバーできると思っていて。
takasek：腐敗防止層をどう作っていくかというやつですね。
banjun：そうそう。それをやるとだいぶいいかなとかっていう気はしてます。
takasek：そうですね。どこまで守らなきゃいけないかっていう点を明確にして、じゃあここの部分は守る、この部分については諦めるっていう、そういう判断を考えていくっていうのは大事ですね。
banjun：いつ何時もこのレガシーを除去していいよっていうチャンスが来たときに、いいよって言われたからやろうとしたら、自分たちが売り出したものですでにでかくなっていたみたいな。
そういうことにならないように消してもいいよって言われたときに、よし消すぞって言える態勢を残しときたいですね。
takasek：そうですね。
trebyへの質問「行動力の源は？」(1:14:37〜)
banjun：「パーソナリティーに聞きたいこと」のコーナー。これはtakasekさんに読んでいただいてもいいですか？
takasek：はい。trebyさんに聞きたいのが、僕結構後回しにしがちなんですけれど、いろんなことを。だけどtrebyさんって気付いたらすぐに動くような、そういう動きをしていることが多いと思って。その行動力ってどこから出てるんだろうなっていうのがすごく知りたいです。
treby：言うて、私多分takasekさんが思ってるよりもずっとずっとだらけてますけどね。
ただ意識してることは、頭の中にこれやらなきゃっていうふうに残ってる状況がずっと続くって不健全だなって思っているので、その不健全さを晴らすためにとりあえず行動するっていうのは、やれることについてはやってますね。
takasek：それが膨らむとですね、逆に動けなくなっちゃうんですよね僕。
treby：というと？
takasek：やらなきゃってなっていると、やらなきゃいけないことが小さいうちは小さいからすぐにできるだろうって思って放置してしまうんですけれど、それが少し時間が経つとやっていない状態に対してそれを保ってしまうような心の動きがあって。
多分完璧主義みたいなのがちょっと混ざってるかと思うんですけれど。やるとしたらちゃんとやりたいって思って、そこで手が出せなくなる。
解決策は分かってるんですよ。少しでも手をつけるとか、とりあえず最初の5分だけやってみるとか、そういうプラクティスは分かっているんだけれどですね。いざ実行しようとすると難しい。気性なんですかね、結局人の。
treby：気性は大いにあると思いますね。自分良くも悪くも結構大ざっぱなんで、やってみて考えるかっていうのはありますね。
今のtakasekさんの話じゃないですけど、まあやってみるかっていうふうな基本的な行動基準はありつつもできないことっていうのがあって。それは何かって言うと、大体アクションまで落とし込めてない、やりたいことなんですよね。
漠然と、PCとかもういらないから処分しようっていうふうに今あるんですけど、もう半年ぐらい放置したまま置いてあるんですよね。
banjun：うちもあります。
takasek：分かります、分かります(笑)
treby：結局具体的にアクションまで落とせてないんですよね。起動して、なんかファイルとかあるかもしれないからバックアップするっていうですけど、何をバックアップするかとか全然因数分解できてなくて。
banjun：PCリサイクルのページ、Safariのタブにいるんだけど、まだできてないってことですね。
treby：そうそう。そういうやつ。そうしてるうちにだんだん市場価値下がっていって。
banjun：売る予定なのね。
treby：2016年モデルのMacBookProなんですけど。もう半年ぐらい経っちゃってる。
takasek：分かりました。trebyさんも僕と同じだって分かりました(笑)
treby：ただ意識してるのは、何か動けるところがあったら動くっていうところですね。特に膨らんでいくときに、これっていうのはこのまま何もしないなっていうのが見えるので、だったら酔った勢いでも何でもいいので勢いがついたタイミングで手出しちゃうみたいな。
takasek：酔った勢いっていうのはいいですね。酔ったではないけれど勢いを借りるっていうのはいいですね。「俺はこれをやるぞ」って、ツイッターで宣言したらやれるみたいなのもあったりしますね。
treby：逆に私がtakasekさんに聞きたいのは、週3日働いて、週2日は勉強のためって、その2日を有効活用するテクニックじゃないですけど。
たまにだらけちゃうことがあるっていうのは先ほど伺ったんですが、普段どういうメソッドを使って自分自身を奮起させるのかっていうのは聞いてみたいですね。
takasek：そのためにはやっぱり自分のいる場所が変わるとモードが変わるので、それを意識するっていうのはありますね。
treby：場所を変えて自分に、環境変わったから動くよねっていうことですか？
takasek：はい。
treby：基本的には自宅でやるというよりは別の場所で何かやるっていうことが多いってことですかね。
takasek：自宅に仕事部屋を作っているので、そこに入るとちょっと気分が変わります。
treby：モードを変えて。結構デザインパターン感ありますね、それ。
banjun：仕事部屋すごいですね。
takasek：あともう一つあるのが、仕事を少しだけ残しておくっていうのが一つあると思います。
前にやるときにやり切ってしまうと、そのあとに仕事を続けるためのエネルギーが残っていない状態になって、エンジンをかけるところから始めなきゃいけないんだけれど、少し仕事を残しておくと、ここから始めればいいんだっていう取っ掛かりにもなるし。
さっき勢いを借りるっていうのにもちょっとつながりますけれど、その勢いをつけやすくする、そういうのがありますね。
treby：特に作業系だといいですね。
banjun：結構いいですね。僕も割とやったりします、それ。
treby：やってるうちに集中できるっていうか。
banjun：よくきりがいいから帰るみたいな話もあって、それはそれで気分がいいんですけれども、きりが良くなくても帰るときの言い訳にも使ったりしますね。
treby：ライフハック。
banjun：絶対これ、最後このタスクだけだから、あえて今日夜中やらなくても明日やればすっとできるから、むしろそのほうがその先の勢いがつくからいいんだと言い聞かせて帰るとかっていうのはありますね。
QoL(Quality of Life)のtreby仮説(1:20:11〜)
treby：全然関係ないような気もするんだけど、ちょっと話したいのが。QoL、Quality of Lifeって「仕事ができてるか、できてないか」じゃなくて、「できてるような気がしてるかどうか」だというふうな仮説を最近立てたんですよ。
banjun：treby仮説？
treby：そう。treby仮説。要するに最近うまく仕事できてるような気がしないなとかってへこむじゃないですか。そのへこんだ状態がさらにパフォーマンスを落とす原因になるじゃないですか。
じゃあできてるときって本当にできてるかどうかって自分でも分かんないはずなんですよ、本質的には。
「今日やったったで」とか、すげえ気分いいから何でもうまくいくような気がするっていう自信に満ち溢れた状態、あれっていうのは素晴らしいことだと思うんですけども 実際にそこで価値が、できてないなっていうときと価値、どれぐらい違うかっていうとあんまりないような気がしてて。分かります？
takasek：そうですね。僕もオレオレ設計でうぬぼれてたときに価値があったかっていうと、そんなに価値創造していなかったけれどでも自信ありましたからね。
treby：人生の充実度、充実してる感を出すためには、実は出してる価値っていうのは相関してないんじゃないかっていうか。自信に満ち溢れてると結果的にパフォーマンスが出るっていうこともあると思うんですよ。
なんですけどそれはあくまであくまであとからついてくるものであって、大事なのはまず自分自身が生き生きとして仕事できることなのかなっていう。
これ何がきっかけになったかって言うと、最近してる仕事がものを作るっていうところから離れてるところもあって、できたものっていうので計測できなくなってきたんですよ。
いろいろとメールのやり取りだとか、調整だとか、あとは実際に手を動かしたりだとか、何でも屋さんみたいなことをしてるんですけども。それの仕事量っていうのをそもそも比較しようがないし、やりきるっていうこともなくなってくるんですね。
あれもこれもあって、そのうちのどれぐらいまで手をつけられてるかどうかっていうのでチェックリストを作っていくんですけれども、チェックをつけてる間に新しいのが入ってきたりとか、いつの間にか入ってるやつが消えてたりとか、この案件は進めようと思ってたけどなくなったとかあったりして、ワヤワヤしてるんですね。
ってなると以前はこういうやることが決まってて、それをやることによって自分はやってるっていうので勢いづけたりすることができたんですけど。今っていうのはそういう測り方じゃ測れないなって思ったんです。
なので、そんなときにちょっと一つ浮かんだ仮説が、何かをやったこととかで成果っていうのを何かしら定義して測るんじゃなくて、測ることによって自分はできてるっていうような自信のもとにしてただけであって、自信をつけることができたら別にその手段は成果じゃなくてもいいんじゃないかっていう。
takasek：ただそれでQoLとしてはいいかもしれないけれど、ちゃんと価値を生み出すところにつなげているかっていうと、完全に別の話になってくる。
treby：そうですね。もちろん。
takasek：仕事としてはやっぱり自信を持っていても価値が出なければしょうがないので。
treby：なので、次のステップとしてはその自信を持った状態で、じゃあどういったことで定量的な仕事の量っていうのを計測するかっていうのを定義して、一緒に仕事してるメンバーとかにも見えるようにするかっていうところだと思うんですね。
仕事内容が分からない仕事だとまずは自信を持つことなのかなっていう仮説は最近立てました。そのためにライフハックとか使っていくと、テンションだけ上がるとかいうのは第一段階としてあるかなって思いました。
エンジニアの仕事はゲーミフィケーションしやすい
takasek：テンション上げることによってそれが結果的にパフォーマンスにつながればいいなっていう感じですか？
treby：まずは働いているときにどよーんっていうふうにしないっていうところが第一段階なのかもしれないですね。
banjun：どよーん、どよーんとしてたんですか？(笑)
treby：自分の仕事の成果が測れなかったからね。今までの基準とかだと。
takasek：それはそうですね。
banjun：確かにね。
treby：プルリクベースとかだったら、出したプルリクの数とか、もちろんそれだけじゃないんだけども一つは区切りとして使えるじゃないですか。
プルリクを出したとか、あと書いたコードとか消したコードとか。あとはたまに、ここのところリファクタリングしてこんなきれいな書き方にできたとか、ちょっとうれしいじゃないですか。
banjun：それは結構自信みたいなところかもしれないですね。だから成果はともかく、自分がいいコードを書いたか、いまいちなコードを書いたかっていうのは自分の感覚として分かるじゃないですか。
takasek：エンジニアのというか、プログラミングの仕事ってゲーミフィケーションしやすいんですよね。ただそれがしにくいところでじゃあどうするの？っていうのは結構難しいところですよね。
treby：だから分かった。測れない、ゲーミフィケーションできないところにいってゲーミフィケーションをするためのフレームワークを作る前座として、まずはここで折れないようにするっていうところのハックなのかもしれないですね。
takasek：Googleのre:Workに書いてあったんですけれど、効率的な仕事をするためにはまずその仕事の場を学びの場だと捉えるっていうのが結果的なパフォーマンスにつながるみたいな話があったんですね。
そうするとそういったどよーんとする期間っていうのは、できないっていうところにフォーカスするんじゃなくて、できないことに対処してそこの答えを見つけようとしているという。
この答えが少し見えてきたぞというところにフォーカスすると、どよーんがちょっとなくなってくるのかもしれないってちょっと思いました。
treby：おお、知見だ。
banjun：いいですね。
treby：ちょっと、自分の言いたいことが体系化された気がする。
banjun：それは多分エンジニアというか、普通にコードを書いてコミットしている人も多分同じやり方ができそうですね。
takasek：プルリクでまさかりを投げる立場なので、投げれられるほうは、これはどよーんってしちゃうだろうなって思うんですけれど、それで相手にそのせいで仕事が滞っているって感じてはほしくなくて。
やっぱりそこでそれだけの学びがあって次につなげられるぞっていうメンタリティにできると、チームとして良くなっていくのかなっていうのは思っています。
banjun：そうですね。プルリクはよく思うのは成果物納品のパスではないので、あくまでこうしたらこの機能が実現されるという仮説の実証だと捉えたいなと思っていて、それはメンバーに対してもそう思っていて。
やっぱり納品物のチェックって思っちゃうと、これじゃあマージできませんよっていうレビューコメントで弾くっていうのはそういうことだと思うんですけど。
takasek：それはやっぱりどよーんとしてしまう？
banjun：やっぱりPRっていろんな実現方式があった中で、今回はこういうふうに実装しましたがどうでしょうか、っていう形だと思うと、代替案と比べてここはいいし、ここは駄目だから、駄目なものが本当にクリティカルに駄目だったら採用できないし、ここの部分はいいからとここだけ直すかとかっていうふうになって。
takasek：あるいは提示はするけれど別にこれは参考にしてくれればよくって、今はこっちで全然オッケーだよっていうのもありますね。
banjun：ありますね。これが完成となって通るか通らないかっていう、そういう判定ではなく、こういう実装ができましたというそこに対してどうかという議論をする場であると思うと、いいのかななんて思ってます。
banjunへの質問「どうやって手堅く基礎力を高めている？」(1:27:32〜)
treby：じゃあ続きましてbanjunさん向けに質問があるということなので、takasekさんお願いしてもいいですか？
takasek：はい。banjunさんに対しては、すごい基礎力が手堅いなと思って。何かを調査するときにも基礎の部分からちゃんと調査をして、こうだっていう話をする、すごく手堅いその基礎力とあと継続力があるなっていう。
そこを尊敬してるので、そういったのを続けていく力とか、調べていく力みたいなそういう源が知りたいです。
banjun：基礎力はさっきの低レイヤーみたいな話で、継続力って言うとどういうものの？
takasek：調査の結果を出すこととか、あとbanjunさんが作っているプロダクトとかも、調べて終わりじゃなくてその調べたものをちゃんとプロダクトとして出すっていうのをたくさんやられているじゃないですか。
アイマス関連の様々なアプリとかも。まじで多いんですよ、banjunさんが作ってるアプリは。多いし、コンセプトをしっかりしてて、軽くサクッと作って終わりじゃなくて、それぞれにちゃんと難しいところがあるんだけれど、それをクリアして形にしているっていうものなんで、なんかすごいなって思います。
banjun：ありがとうございます。めっちゃうれしい質問ですね、それは。言われてみて思うと手堅い基礎力とはなんぞやっていう話もあって。それってどう生まれるのかってすごい難しいなとは思ってるんですけど。
先に、継続力というか作ったプロダクトの話をすると、単純にそういうプロダクトを作るのが好きなんですよね、だから。何でも作りたいわけじゃなくて、どうしても技術的に難しいとされているものがいちネタあるようなプロダクトを作るのが多分好きなんじゃないかというような気はしていて。
そこにやっぱり簡単に真似できないものを作るっていうのは一つ価値だと思っていて、結局オープンにするんですけどね。そういうところにできないと思ってたけどできたとかっていうのは、やっぱり好きだからやってんだろうなというところはありますね。
基礎力って何でしょうねって、バグの調査とかそういう話かもしれないし、あるいは何か技術的に難しい課題があったときにそれをできるのかできないのか、どこまで調べるかとかそういう話かもしれないですけど。確かに調べられるものはかなり調べたいなっていう、そもそもの欲求がありますね。
takasek：やっていて心がくじけたりはしないんですか？
banjun：くじけることは多分あると思いますね。どうやっても分からないこととかっていうのはまああるはず。具体的にどうかっていうのは置いておいて、多分めちゃくちゃいっぱいあったと思います、それは。
だけれどもある事柄を調べていくことで、そこで得るスキルとかっていうのがやっぱりあるはずで、それって調べたいと思ったネタ、バグならバグだし、何かの機能だったら機能に出会ってなければ得られなかったスキルだから、もうそれはチャンスだと思ってやってるみたいな感じですかね。
takasek：調べること自体に喜びを感じているっていう、さっきのtrebyさんの話ともちょっとつながってきますかね。
banjun：そうかもしれないですね。あとは調べれば、原理的にはそれは調べれば分かるはずだという直感みたいながあるんですね。それがどれぐらいコストがかかるかとか、調べることのコストパフォーマンスみたいなことを言い出すと多分難しいんですけど。
あるバグを見つけてそれを直すことでこれぐらいのプラスの効果があるとして、それに対してそのプラスの効果の10倍のコストをかけて調べるかとか、そういうビジネス的な賢いことを言い出すとどうか分かんないんですけど。
あんまりそういうことは気になんなくてですね。原理的に調べれば調べがつくんであれば調べたいという、やっぱりそういう欲求があるんだと思うんですね。
もしそれが調べがつかないのであれば、その原理的に調べがつくはずだと思ったのは一体何が間違ってたのかとか、どうやっても調査しきれない何か原因があるんじゃないかとか、そういうのが明らかになるだけでも面白いかなというふうに思いますね。
takasek：失敗したとしても別にそれは失敗という結果じゃなくて一歩前進したっていう、捉えることですね。
banjun：そう。原因がよりフォーカスされてというか、どうしてもここは駄目だから駄目なんですっていう仮説がもうちょっと深まりますよね。その仮説自体が狭くなってくればなるほど、その仮説自体が正しいかどうかみたいな突っ込みがもしかするとほかからもできるようになるかもしれない。
ふわっとここは調べるの大変ですだったやつが、この機能に関してここについては情報がどうやっても取れないので分かりませんってなったときに、そんなはずあるかっていう別の意見が出てくるかもしれないし、ふわっとしてるとそんな意見も出てこないけど。
より仮説は細かくなれば細かくなるほど、反駁可能になるので、そういうのを掘り起こすだけでもいいかなっていうふうに思いますね。
takasek：そうすると最初の仮説の作り方が結構大事になってきますね。
banjun：そうですね。まさにその直感によるというか、これは調べがつくだろうっていうその直感を攻めるしかないので、それですね。
takasek：その仮説が明確になってくるっていう喜びは僕もすごくよく分かります。やっぱりいろんなことを学びたいって思っているのは、学びによって世界の捉え方、粒度がどんどん細かくなっていくから。
それによって見えることとか言えることが増えていく。それによってさらに分かることが増えてくるっていう、そこがうれしいので。なので、それにはすごく共感しました。
banjun：具体事例とかって何があるかなとかって思うと、例えば前々職とかだと、ローカルネットワークのWiFiつないで云々するみたいなアプリを書いていたんですが。
その場合ってWiFiにつながるかつながらないかみたいなところのチェックをしなきゃいけないんですけれども。普通にプログラミングしてたら降りていってもソケットプログラミングすることにはなっても、その時点で今時にしては低レベルだとは思うんですけれども。
そこでエラーを取る、ログを取るみたいな話になるんですけども、WiFiにつながるかどうかって原理的には前段階あるよなとかって思って、WiFiをキャプチャし出すんですよね。
MacBook使ってキャプチャできるのかとか、そういうことを調べたりとかして。そうなってくるといわゆるL3では情報が足りないっていうことが多かって、WiFiっていうのはパケットを交換してるわけではないということに気付くわけですね。
パケットはL3から上の話だから、L2はフレームを交換しているということに気付いて、フレームは意外とルーターがあるネットワークではルーターをかまさないと到達しないとか。お互いに見えてるのにルーターをかましたものしかアクセスしないとか、そういうことが分かっていって。
ルーターがないときには直接交換するとか、ルーターを介してお互いに直接見えてないものがWiFiのフレームとして飛び交ってるとかっていうのが見えるようになる。
そうなってくるとWiFiにつながる、つながらないみたいなアプリ上のバグだったものが、WiFiのフレームをキャプチャすることで、このフレームが飛んでるときは動けるし、そうじゃないときは動けないねとか。あるいは途中からチャンネル変わってるよね、なんか知らんけどみたいな、いうのが分かってきて、それでより詳細な原因特定につながるみたいなのがあって。
そういうのを一応やっておくと次から気軽に、MacBook1個あればWiFiっていうのは全部キャプチャーできるんですよみたいな話になってきて、次からは得た知識を再現するだけなので、何かあっても特定できるみたいな、そういうのが楽しいですね。
takasek：強くなりますね。
banjun：そうなんです。
ちょっと前の私に伝えたい「フリーランスの仕事選びについて」(1:35:46〜)
treby：続きまして「ちょっと前の私に伝えたい」のコーナーです。ちょっと前の私に伝えたいのコーナーの趣旨なんですけど、こちらはtakasekさん長くエンジニアやってますと。ちょっと前までもエンジニアやってますと。
ちょっと前の自分に伝えたいことをわれわれがヒアリングすることによって、聞いてらっしゃる皆さんの、エンジニアの方のキャリアの参考になるんじゃないかということが趣旨となっております。こちらもtakasekさんからお願いしてもいいですか？
takasek：はい。僕がちょっと前の私に伝えたいと思うのは、フリーランスとして仕事を選ぶときの、その選び方の戦略もうちょっと考えろよっていうことを伝えたいですね。
僕今フリーランスで足かけ8年とかでしたっけ、やっていますけれど。割と流れで仕事を選んできているんですよ。自分から自主的に仕事を選ぶっていうことはあんまりしてきてなくて。
なので、あんまり選ぶ基準を決めていなかったんですけれど、そこをもうちょっと決めておくと戦略的にシニアとしてうまくやっていく、そういうやり方ができるんじゃないかなと思って、最近意識していることがありまして。
それをフリーランスを始めた辺りの、もしくはもっと前の自分に伝えられたらいいんじゃないかなと思いました。
その戦略とは何かと言いますと、自分の戦場にはいくつかあると思うんですけれど、主戦場として自分がこれは価値を出すことができるぜっていうところ、あとここの戦場についてはあまり良く分からないんだけれど、でもここについては学習したいっていう、そういう戦場二つあると思うんですね。
その二つをバーターにして提示していくといいキャリアの広げ方ができるんじゃないかなと思っています。つまり何か仕事を取るときに、自分はここの部分が強いのでここについてはもらえる金額の分だけの価値は保証しますよっていうふうに言うことができる。
もう一つ、ほかに自分はこういうことをやりたいのでそこについてはあまり力になれないかもしれません。だけどそれをカバーする分、主戦場のほうのスキルがありますので、その分お値段としてはちょっと押さえることはできますというような。
そういったバーターの形で金額を提示することができれば自分の値付けとしても発揮できるし、相手にも価値を提供できるし、しかも自分はお金だけではない学びとして新しい部分を広げることができる。
そういった領域を二つに分けて考えるっていうことを今まであんまりしたことがなかったので、今それを考えつつ仕事を選んでいるとうまくいっているなという気がしまして。なので、そういったことを伝えないなって思います。
treby：具体的にもし今転職というか、新しく環境を移るとしたらどういうことをバーターにしますか？
takasek：やりたいことたくさんあるんですよね。なので、そこはそのほかにも、向こうがどういうことをやっているかということに合わせて、いろいろその形は変えられるとは思うんですけれど。
例えば僕サーバー側がすごく昔にPHPで、それこそ何の設計も分からないまま雰囲気でやっているみたいな、そういったことしかやっていなかったので、今しっかりとサーバー側の知識を得たいっていうのがあるんですね。
ドメイン駆動設計とか結構しっかり読み込んでやっていきたいなって僕今思っているんですけれど、ただそのときにエリック・エヴァンスのDDDの本とかを読んでいて思うのが、これ完全にサーバー側の仕組みを前提に考えているなっていうので、クライアントとしてはあまりピンとこない部分とかあるんですね。
だけどそれはピンとこないのは自分がサーバー側の事情をあんまり知らないからなので、そこについてサーバー側の自分のDDDの知識を検証する目的としても、サーバー側の実装ができるようになれば、そうすればその知識がどういうものだったかっていう知識が自分の中に根付くはず。
なので、その結果それと比較して、じゃあ差分としてクライアントでは何をやれば良かったのかっていう、クライアント側の知識のフィードバックにもつながるはずっていうふうに思うので、サーバー側結構やってみたいなっていうのを思いますね。
treby：サーバー側をやりたい代わりにクライアント側も知見持ってますよという売り方ができる。
takasek：クライアントも知見持っているし、あるいはどういうふうに責務を分割するかっていう、その設計の部分についてはある程度価値を提供できますよという、そういった売り方で自分を売り込むことはできるんじゃないかと思っています。
もしこのラジオを聴いていて、静的型付けのScalaとか、そういった言語で僕とやってみたいみたいな方いらっしゃったらお声がけください。
treby：いいですね。
takasek：宣伝してきました。
banjun：あんまり考えたことなかったですね、この戦略は、私は。なるほどなと思って聞いてました。
treby：買う側からしたらちょっと難しい感じはしますよね。やりたいっていうのは分かりつつも、じゃあそれを目的に取るというよりはやはりこれまでやってきたことベースに取るっていうのが主体にはなるかなとは思ったんですけど。
takasek：なので、そこも含めてマッチすることは必要だと思います。あと主戦場でそれだけ価値が提供できますよっていう、その部分はちゃんとアピールできないと雇ってもらえないとは思います。
クロージング(1:41:34〜)
banjun：さて今回もお別れの時間が近づいてきました。きのこるエフエムでは番組へのお便りをお待ちしております。お便りはきのこるエフエム公式Twitterアカウントへのリプライか、ハッシュタグ#きのこるをつけてツイートするか、アンケートフォームでお寄せください。お待ちしております。
treby：お待ちしてます。今日takasekさん1日、1日と言うか半日ですね、とっていただきましたけどいかがでしたか？
takasek：自分の話をまとめるのが難しいですね。あっちこっちいっちゃって。
treby：Podcast自体は初めてですか？
takasek：はい。初めてです。
treby：実際今日いろいろ話していただいて、こちらもどういうことを聞いたら一番番組的に面白くなるかとか、聞いていらっしゃる、あと皆さんですよね。
興味ある分野の、言えてるかなっていうのが心配なんですけど、takasekさん自身が少しでも楽しくお話できたのであれば、これに勝る幸運はありません。
takasek：楽しかったです。ありがとうございます。
treby：ありがとうございます。
banjun：私もtakasekさんの知らない面が次々出てきたんで面白いなと。
多分だけどtakasekさんのことをすでに知っている、例えばiOS勉強会界隈のリスナーの皆さんもtakasekさんの知らない面を今回聞くことができるんじゃないかというふうに、そういう意味で結構いい回なんじゃないかなというふうに思ってます。
treby：意外とtakasekさんも話さない。
takasek：言ってないことたくさんありますからね。
treby：今後また、きのこるエフエム続いていったらゲストで来ていただく機会もあるかもしれないですけども、そのときはよろしくお願いいたします。
takasek：よろしくお願いします。
banjun：よろしくお願いします。
treby：じゃあそろそろクロージングに入りたいと思います。この番組はマネジメントに攻めるtrebyと……
banjun：……スペシャリストになりたいbanjunと。ゲストの……
takasek：……takasek……
banjun：……でお送りしました。
treby：それではまた次回の配信をご期待ください。バイバイ。
banjun & takasek：バイバイ。
この記事が気に入ったらサポートをしてみませんか？