去年の12月、「ツリホウ」、「ツリバカメラ」といったWEBサービス・アプリを運営している「ウミーベ株式会社」さんを訪問して来ました！
URL：https://umee.be/
今回はその記事の後編になります。
CTOにNiaさんが超熱く語っているので記事ボリュームが過去最大規模になっております。
前編：【会社のお話編】ITで釣りを釣りを、優しくする「ウミーベ」さんを訪問
今回話をしてくれた方々
 |
Shota Nagasakiさん（Niaさん）
ウミーベ株式会社のCTO。
何でもするけど基本はサーバーサイドの人らしいです。 一見クールですが凄く技術に対して熱い方。 |
 |
渋田 達也さん
ウミーベ株式会社のテックリード。
バックエンドもフロントエンドも熟すwebのエンジニア。 福岡のITサークル「chibi-developer」の主催の一人。 |
働くモチベーションの話
– take2(筆者)
（前編で）釣りに対してそこまで思いがあるわけではないという爆弾発言が出ましたね。
では、モチベーションって何ですか？
– Niaさん
いやー、モチベーションってあります？
渋田さんどうですか。
– 渋田さん
扱ってる領域？
「自分がやりたい領域ができているか」とか、「面白いデータが扱えるか」とかですね。
– Niaさん
たとえばVue.jsとか？
それはありますね。
– take2(筆者)
「技術的にやりたいことができる」ってことがモチベーションの1つなんですね。
– 渋田さん
あと、集まってくるデータを活用する所も面白そうだなと思います。
– Niaさん
それありますね。
僕がウミーベを選んだ理由もそんな感じです。
ある程度ユーザーがいるサービスのサーバーをやりたいというのはありました。
自分でイチからサービスを始めるとユーザーはほとんど居ないじゃないですか。
– take2(筆者)
なるほど。
そこを育てるというのが好きという人もいるかもしれないですけどね。
– Niaさん
そこは今までいっぱいやっていて…
リリースされたものもあるし、されなかったものもあるんですけど。
だから、ある程度ユーザーがいるサーバーを継続的に扱ってみたいという気持ちはありましたね。
すでに一定のユーザーがいるサービスのサーバーを見るのって中々できる経験ではないですよね。
– 渋田さん
それはありますね。
これだけのPVがあるサイトをどうやって捌けばいいのかという所は経験値としても良いなというのがあります。
– take2(筆者)
なるほど。
扱ってる技術を活用したり、そこでしか体験できない規模感を体験したいからエンジニアをやってるという方もいるんですね。
使ってる言語とかインフラとかフレームワークの話
– Niaさん
大体そんな代わり映えしないですよ。
Rails、Swift、Kotlin、AWS、JavaScript、PHP、WordPressとか…
PythonとGo言語も最近こっそり増えましたね。
– take2(筆者)
Go言語はどこに使ってるんですか？
– Niaさん
別に、特に使う必然性があって使ったわけではなく、「Go言語を使いたいな」というのが先行した感じです。
Apexっていう、AWS Lambdaのをfunctionを管理するOSSがあって、Goのコードをコンパイルしてデプロイできるんですよ。
それでNode.jsをエンドポイントにしてGoを動かすということができて、じゃあやってみるかって。
作ってるものとしては、業務上のパイプラインみたいなものです。
例えばサーバーのアラートをSlackに通知したり、まだ実装できてないですけどエンジニアのコミットを集積して週報を自動作成したり、ツリバカメラがリリースされたらSlackの全体チャンネルに投稿したり、といったことをやっていきたいですね。
– take2(筆者)
やっぱりGo言語だと早いんですか？
– Niaさん
そもそもそんなに重い処理を書いていないので、Goのメリットを活かせてるかというと全然だと思います。
– take2(筆者)
とりあえず使ってみようって感じですか？
– Niaさん
そうですね、Goを使ってみるということが先行してます。
あとは、もうすぐにネイティブのGoがAWS Lambdaで実行できるようになるので、それもGo言語を使うモチベーションになりましたね。
補足: AWS Lambda での Go サポート開始
URL：https://aws.amazon.com/jp/about-aws/whats-new/2018/01/aws-lambda-supports-go/
– 渋田さん
そうなったら僕もGoを使うかな。
– take2(筆者)
技術の話になると目がキラキラして来ますねｗ
コードはいつ捨てても良いもの
– take2(筆者)
話を伺うと、メジャーどころの言語は押さえてる感じですね。
Javaとかはどうなんです？
– Niaさん
Javaは滅ぼしましたね。
– 渋田さん
Androidにいましたが、Kotlinに変わりました。
– take2(筆者)
大変じゃなかったですか？
だって実質androidアプリの全リニューアルですよね？
– Niaさん
今出してる、バージョン2はほとんど全部書き直している状態なので、古いコードは9割9分消えてますね。
サーバー側もほとんど消えたので、残ってるのはDBの構造とモデル周りの基本的なビジネスロジックだけですね。
全消ししてリファクタっていうのは結構やりますね。
iOSでもやりました。
でも、大変か大変じゃないかっていうと、めっちゃ大変でした。
– take2(筆者)
ある程度ユーザーさんがいる状態だと怖いなとかならないですか？
テストを書いてるから大丈夫という所でしょうか？
– Niaさん
サーバーはそうですね、テストがちゃんと用意されてるので、ある程度は安心してコードを捨てられます。
アプリはまだ準備が整っていないので十分なテストを用意できていないのが現状です。
– 渋田さん
フロントは一部書いてますね。
ただビュー周りはテストがやりづらいし、変更頻度が高いのでテストしてられないというのがあります。
– Niaさん
ロジック周りはある程度書けるんですけどね。
– 渋田さん
WEBのフロントの場合はCIでチェックしているので、致命的なのはCIでこけるようにしていますね。
– Niaさん
結局、リファクタリングによる技術的負債の返済をしたということなんですが。
そもそも、技術的負債が生まれる理由は大きく2つあると思います。
まず第一に、技術的なパラダイムが変動して技術的負債が生まれるケース。
これは、どうしようもないです。技術の進歩に対処していくしかない。
そしてもう一つは、エンジニアが生み出す技術的負債です。
メンタリティの問題で、例えば「時間がないからこのコードで済ませよう」、「既存のソースのこの部分は良くないけど、今実装している部分とは関係ないから放置しておこう」というものは、技術的負債を生み出す大きな要因になります。
そういうものが積み重なると、返済不可能になってしまう。
ただコレを無にするのは難しい。
現実には有限の時間しかない。
だから次善の策として、技術的負債を返済するための方法は保持しておく必要があると思っています。
そういう意味で、「コードはいつ捨てても良い」という状態を作ることができれば良いなと思っています。
もちろん単に全部書き直すことをやっても意味がなくて、きちんとしたインテグレーションテストを用意していくということですし、まとめて全部のコードをぶっとばすってことではないんですが。
例えば特定の機能、ある1つのモデル、特定のUIコンポーネント。
そういった単位で良いと思うんです。
そういうレベルでコードを捨てて一（イチ）から記述し直すことが簡単にできないのなら、それは工学上の敗北だと思います。
自分が実装したコードを捨てることは勇気がいることですが、必要なことでもあります。
結局のところ、技術というのは「課題を解決する構造物」を作る知識のことだと考えています。
それが具体的にはアプリだったり、ライブラリだったり、フレームワークだったり、もっと小さなコードになるんですが。
でも、技術そのものはいつでもただの知識で、それを具体化する作業がコーディングだったり設計だったりするわけですよね。
じゃあ、技術をちゃんと集積することと、具体化のコストを下げていくことを実践していけば、いつでもコードを捨てることができるんじゃないかと思っています。
技術を蓄積することと、コードを残すことは違います。
– take2(筆者)
思い切ったご意見ですが、その通りですね。
– Niaさん
機械だってそうですよね。
その機械をもう1度作ることができて、今ある機械が古いなら、古い機械を捨ててもう一度作りなおすことができる。
例えば自作のラジオを持っていて、ガタがきたからもう1つ新しいものを作るとか。
この時に、ラジオの仕組みや道具の使い方をちゃんと習得していれば、新しいものを比較的簡単に作れるじゃないですか。
何も知らない人よりどれくらい簡単に「課題を解決するための構造物」を組み立てられるか、が技術ですよね。
もちろん、最終的になにかを捨てて再生産するというのは経営判断になります。ただ、経営判断を適用できる土壌を作っておかないと、負債が増えたら自動的に死にますよね。
ただでさえ、テスト駆動開発をすると工数が増えるし、ユーザーが増えるとテストの品質を上げないといけないので、個々の機能をリリースするためのコストはなにもしなければ増大していきます。
それをどうやって下げていくのか、というのはCTOとしての仕事の1つだと思っています。
– take2(筆者)
やはり速度は重要ですか？
– Niaさん
重要ですね。
今はアプリが2週間に1回くらいのアップデートしていますが、今でも遅いと感じています。
理想は数日に1回とかですね。
ミーティングも減らしたいですね。
コミュニケーションって必要だけど、時間かかるし遅いですよね。
– 渋田さん
ドキュメント共有だけのミーティングとかも増えてきましたしね。
– Niaさん
そうですね。
僕個人的な理想としては、「単一の機能について誰かが提案を出したときに、それが自動的に仕様的検討とデザイン的検討、経営的検討が行われて、どうするかが自動で決まって、あとはエンジニアがただ実装すれば良い。
実装すれば即リリースできる」というものを作りたいです。
さすがに人的リソースが足りないので、現状では「理想は理想、現実は現実」という感じですが……。
最終的にはそういう枠組みで仕事をしたいですね。
– take2(筆者)
枠組みが決まっていないと、ついついダラダラしたり、周りの状況に流されてしまったりしますものね。
AWSの採用について
– take2(筆者)
インフラAWSじゃないですか？DBも全部RDSですか？
やっぱり管理コストは下がる感じですか？
– Niaさん
そうですね。
ギリギリ画像がS3に移っていないくらいですね。
管理コストは増えますね。
その代わり、メンテナンスコストは減ってます。
– take2(筆者)
メンテコストと管理コストの違いがちゃんと解っていないので説明をお願いします。
– Niaさん
メンテナンスコストっていうのは、個々のサーバーの保守に必要な時間のことですよね。
AWSの場合、インスタンスは簡単に追加・削除されるものですし、RDSやAWS Elasticsearchなどを使えばサーバーをほぼ意識せずに特定のサービスのインスタンスを立てられます。
なので、一つ一つのサーバーを保守するコストはかなり下がります。
管理コストっていうのは、AWSのアカウント全体の設定を管理するコストっていう意味です。
正直、AWSにしか通じない知識も要求されるので、そこは辛いですね。
もちろんこれもメンテナンスコストではあるんですが、僕の中では別々の項目になっています。
– 渋田さん
AWS固有のサービスも多いですしね。
AWSのサービスは固有なもだけじゃないですが、そろそろ100超えるくらいありますし。
– Niaさん
うちの場合は今、ツリバカメラがAWSを使っているんですけど、もうすぐ「ツリホウ」もAWSに移ってくる予定です。
そうなるとAWSに乗っている複数サービスを上手く分離して管理する必要があります。
AWSのアカウント管理とかは地味に大変で、どうやるのがいいのか試行錯誤してる状態でもありますね。
僕と渋田さんのアカウントはほとんどのサービスにアクセスできる状態なんですが、そのアカウントのアクセストークンはどう管理するのがいいのか？ みたいな課題もあります。
そういうAWS特有の管理コストは増えてくるので、僕としてはサーバーにコマンド叩いた方が楽ですね。
もちろん、最近はそれもコードに乗るんですけど。
ライブラリやフレームワークに対する考え方
– take2(筆者)
Railsを使われているということですが、ライブラリやフレームワークの採用についてはどう考えられてますか？
– Niaさん
基礎ライブラリ、iOSでいうUIKitなど、そういう使わざる得ないものはしょうが無いと思うんですけど、それ以外のライブラリは何を使っているかを整理しておいて、必要だったら切り離せるよう準備したいです。
とくに万能系のライブラリなりツールは最悪ですね。万能ということは余分な機能が付いているということなので。
– take2(筆者)
そういう意味ではRailsとかはどうなんでしょうか？
– Niaさん
Railsは万能だし余分な機能も多いです。
ただ、Railsを長くやってきたエンジニアとしては、この見解の原因は「時代の流れがRailsにとって逆風である」という擁護はしたいですね。
Railsがリリースされた当初はHTMLのレンダリングはサーバーの仕事だったんです。
でも、今はHTMLのレンダリングはクライアント、あるいはフロントの近くにいる別のものの仕事になっています。
ウミーベでいえばサーバーサイドレンダリングをしているLambdaがいて、そいつの仕事ですね。
そういういままでRailsがやってきたフロントのレンダリング部分ってどんどん分離されているから、「Railsのフロント周りのコードは完全に要らないコードだよね」となってしまっている。
こういった、Webサービスのアプリケーション・サーバーに求められる役割が変わってきているというのは、逆風ではあると思います。
フレームワークとしてのRails、ユーティリティとしてのRailsは優秀だとは思うし、その機能を全部使わなくてもRailsを採用するメリットは大きいと思います。
あとRailsの「仕様より規約」という考え方は良いですよね。
規約で縛って、規約に従う限り素直にコードを書ける。
結局、規約って重要じゃないですか。
何らかのフレームワークを使うかどうかという話じゃなくて。
プロジェクトで仕事をしていると規約という共通言語を作って、育てていく必要があります。
具体的にはそれがそのソフトウェアのアーキテクチャになったりするんですが。
そうやって規約が必要な開発の現場で、規約を作るという手順の大部分をスキップできるというのは大きいメリットですよね。
ちゃんとしたRailsエンジニアであれば、Railsで書いたコードは概ね読める状態になるというのは、Railsを採用する大きな利点になると思います。
Railsはただ万能で余分な機能も多いライブラリではない。
そこに採用されているコンセプトをプロジェクトに取り入れるという意味で、すごいフレームワークだと考えています。
普段プライベートで勉強したり、コード書いたりしますか？
– Niaさん
最近は忙しすぎてそんな時間がないですね。（苦笑
– 渋田さん
僕はLTとか月1、2でやっていて、それのために準備をしつつ勉強している感じですね。
あとAdventカレンダーも今月（12月）書きましたし。
ただ、僕の場合は業務に向けた事前準備的な感じの側面もあります。
業務で使うかもしれないから先にやっとこうみたいな感じで。
最近取り組んでいるPWAとかもそうですし。
– Niaさん
俺、最近やってない気がする…
元々、前の会社にいた時やウミーベに入った当初はプライベートのプロジェクトもガンガンやってたけど、今は忙しくてできていない感じですね。
プライベートのプロジェクトはそれこそ、フロントをVue.js、サーバーをNode.jsで書いて、全部JavaScriptで書くぜ、みたいなことやってました。
– 渋田さん
実際全部一緒の言語だと楽ですよね。
– take2(筆者)
確かに、頭の切り替えが要りませんもんね。
– Niaさん
あとやっぱり業務上必要にやった奴とかですかね。
最近だと潮汐表の算出をどうすれば良いとか。
– take2(筆者)
潮汐表？？
– Niaさん
潮の満ち引きを観測する地点と、計算式があって。
観測点ごとに定数があるんですけど、それを式に当てはめると潮の満ち引きが算出できるんですよ。
観測点のリアルタイムデータは取れないので、いや一応見れるんですけど、あくまで個人利用のためのものなので、ツリバカメラで提供するデータは別途計算しないといけない。
– 渋田さん
あとはある日が大潮か小潮かなど潮の計算式とかの求め方とかもあったり。
ただ、正しく計算するのは結構難しくて、概算でこれくらいというのが出せる式など色々ありますね。
– take2(筆者)
IT化しようと思うと、そういう専門知識も必要ですもんね。
– Niaさん
うちはたまたまテーマが「釣り」で位置情報を扱っているから、そうなるのであって、そういうIT以外の領域特有の知識って、きちんとした形でまとまっていんですよね。
それをどう分かりやすく噛み砕いて、ノウハウにしていくのかという問題はこれから取り組むべき課題だと思っています。
企業としてエンジニアに学ぶ機会をどう提供していくのかというのは凄い大事なテーマだと思います。
それは一般的なソフトウェア工学の話もそうだし、釣りという分野における様々な技術の話もそう。
まだ確定じゃないですが、2018年は1人5万円まで勉強会に参加するための交通費・宿泊費として使える予算を割り当てようかなと思っています。
もちろん、会社として絶対に行ってほしいものがあれば予算とは別に捻出します。書籍代とかは予算があるわけじゃないけど、AmzonのURLを送ると2日後くらいに届くようになってます。
– take2(筆者)
会社としては仕組みで学習を応援する感じなんですね。
– Niaさん
そうですね。
会社としての取り組みで、最近やって効果があったのは、「全員でコードを見ながら問題点を話し合う時間を持つ」というやつです。
その場その場で放置したコード、つまり技術的負債をどう直すかっていう話をするんですが、そうやって話すことがリファクタリングのきっかけにもなります。
「リファクタリングの時間を作る」だけじゃなく「直そう」というモチベーションを高めるキッカケを作る必要があるということですね。
「ここのコード良くないよね」とか、「こんな風に直したら良くなるよね」とか、良くないという漠然とした感じのあるコードについて「そこがなぜ良くないと感じるのか？」という話もします。
細かくレビューしているとストレスも溜まるので、そういうところはなるべくLintとか機械的な処理に任せて、アーキテクチャやクラス設計のレビューをしたいですね。
うちのエンジニアチームは「設計が甘い」という弱点があるんで、そこを改善していきたいですね。
長く一つのコードをメンテしてきた経験者が僕と渋田さんくらいしかいなんですが、そういう仕事をすると「今こういうコードを書いていると将来これくらい先に、これくらいのことで困る」という感覚が身につきます。
でも、実践以外の方法で意識的にその肌感を身につけるのは結構しんどいという気持ちはあります。
– 渋田さん
そこは経験が必要ですよね。
– take2(筆者)
経験則ってことですか？
– Niaさん
経験則というより、「未来から今を見返す能力」で、1回経験すればその視点が身につくと思うんですが。
– 渋田さん
「言われたから、そうしてる」とかだと結局意味がないんですよね。
– Niaさん
なるべく少ない経験でその肌感を掴んで欲しいんですよ。
– take2(筆者)
組織が人を育てようとしてるのって、すごく良いなと思います。
私が入社した会社って、「絶対教えないぜ」、「自分で考えろ」っていうスタンスの会社だったのですごく羨ましいですね。
– Niaさん
そうなんです。すごく良い会社にしたいです。
教育って、教育する側が例えば10のコストで学んだことを5のコストで学んでもらうから価値があるんですよね。
同じ10のコストで学ばせるなら、その教育者には価値はないってことです。
そうやって学習時間を短縮しながら知識を継承させていくから文明が発展する。同じコストで学習するのでは意味がありません。
自分が1年かけて学んだことは1ヶ月で、1週間で学んだことを1日で教えたいですよね。
普段巡回してるサイトとかTwitterアカウントを教えてください
– Niaさん
RubyGemの最新動向を自動でツイートするアカウント（@rubygems）があります。
誰かがRubyのgemの最新版をpublishしたら、このgemの最新版がpublishされましたっていうのをひたすらツイートしていて、それは見てます。
– 渋田さん
僕はVue.jsとかフロント系の公式のアカウントとかですね。
とりあえず、最新の情報は元のところから出てくるので。
– Niaさん
一次情報を参照しないといけないですよね。
特にオープンソースソフトウェアって一次情報が簡単に手に入る世界なので…
言ってしまうと、オープンソースがらみのソフトウェア界隈で、一次情報にあたれないっていうのは相当ヤバいと思います。
世界にはデザインとか経営っていいう、一次情報にあたれない知的労働がいるわけじゃないですか。
エンジニアはそういう方たちと肩を並べて戦うわけで。
それなのに、これだけ情報が整備されているオープンソースを主体としたソフトウェアの世界で、一次情報にあたれないっていうのは「かなり情弱」ですよね。
– take2(筆者)
確かに。確かになんですけど、耳が痛い。
– Niaさん
僕の家ってそもそも金がない貧乏な家だったんですね。母子家庭だったので。
なので、なかなか学習機会が得られなくて…
高校の時にやりたくてできなかったのが「ハードウェアを触ること」なんですけど、金がないから当然買えないじゃないですか。
当時はロボットを触りたかったんですけど、触れないんですよ。
しょうがなく部活でやってたんですけど、その部活で使えるのは結局自分のお金じゃないから、自由に使えないんですよね。
当たり前なんですけど。
でも、ソフトウェアの世界って予算が必要ない世界じゃないですか。
最初始める時にはコンピューターは要りますが、でも必要なのはそれだけ。
コンピューターって15万くらいあれば何とかなるし、それ以上継続してお金が必要になるわけじゃない。
つまり15万あればオープンソース界隈で自由に知識を入手できるわけです。
Javaでも良いし、Kotlinでも良いし、サーバーでも良いし、どの分野でも知識が手に入る恵まれた状態なんですね。
だから、僕はソフトウェア業界に入ったところがあります。
ソフトウェア工学は行き着くところまで行ったら滅茶苦茶お金はかかるし、やることが量子コンピューターとかになると大変なことになるけど、普通に取り組む分には最初に武器がなくても戦える世界だと思います。
– take2(筆者)
確かにパソコンとインターネットさえあれば何とかなる世界ですもんね。
– Niaさん
必要な知識がネット上にはありますしね。
– take2(筆者)
最悪、ソースコードっていうガチの一次情報もあるわけですしね。
– 渋田さん
最近それです。
– take2(筆者)
ドキュメントを信じるなっていう？
– 渋田さん
ドキュメントが最新になっていることは稀なのであまり信じてないです。
– Niaさん
で、話に戻りますけど、巡回してるサイトとかはないですね。
– take2(筆者)
Twitterで一次情報系をフォローしておけば、良いって感じですね。
– Niaさん
あとは個人だとnoteのCXOをしてる深津（@fladdict）さんとか。
あとはだいたい知り合いとか。
– 渋田さん
メディアの開発をしているとどうしても必要になるので、SEO系の辻さん（@tsuj）や鈴木さん（ @suzukik）とかですかね。
まとめ
Niaさんとはお会いするのは2回目だったんですが、インタビューを通じて「技術に対して熱い人」なんだなという印象を受けました。
個人的には「コードはいつ捨てても良いもの」と考えている点や、「企業としてエンジニアに学ぶ機会をどう提供していくか」を大切にされている点が非常に印象的でした。
また、筆者自身も一次情報を得えようとインタビュー後にNode.jsの公式Twitterをフォローしましたが、なかなかきちんと読めてはいない現状です。
その辺は精進したいと思います。
こちらの記事を読まれて良いなと感じられた方は、ぜひ自社でパクるか、転職などのご参考にしていただけると幸いです。
Niaさん、渋田さん、お忙しい中、ご対応ありがとうございました！
< 取材日：2017/12/19 >
【関連記事】
 |
【エンジニアのお話編】ITで釣りを優しくする「ウミーベ」さんを訪問
2018.02.06
|
