読者です 読者をやめる 読者になる 読者になる

UZABASE Tech Blog

株式会社ユーザベースの技術チームブログです。 主に週次の持ち回りLTやセミナー・イベント情報について書きます。

情報技術との向き合い方:SPEEDA/NewsPicksを支える価値を生み出す技術の選定手法

UZABASE技術チーム竹内(@chimerast)です。

ちょっと時間がたってしましましたが、2月7日にdots. Summit 2015 にて、ポエム「SPEEDA/NewsPicksを支える価値を生み出す技術の選定手法」を発表してきたのでその内容をもう少し突っ込んで書いてみたいと思います。

今回は、特定の技術や知見のことは全く話さず、何のために技術があるのかという、それ以前の話をしてきました。エンジニアとして、技術を追い求めることはとても大切なことですが、目的を見誤ってしまうと独りよがりになる可能性もありますし、変な方向に技術が伸びてしまいます。

僕は、多くの人に使われたり影響を与える、末永い良い製品・技術を生み出すには、目的はなんなのか見極めることが重要だと思っています。製品であればその価値が生み出す世界を想像し、技術であれば問題の本質とは何なのかを探求することです。

発表の後、社外の人何人かからフィードバックをもらい、とても心に響いたという人や、是非資料を社内で展開させてもらいたいという話ももらいましたが、そんなの当たり前だよという人や、そんなことどうでもよいという人も多いんじゃないかと考えながら発表資料を作っていました。ただ、僕自身そしてユーザベースがとても大切にしていることなので話をさせてもらいました。

ブログにも全内容を書きたかったのですが、前半の価値の話はブログ向きではない気がしたので後半の技術の話について書こうと思います。前半の話は、興味があればスライドを見てください。

対象読者

  • プログラミングを学び始めたばかりの人
  • 情報科学をあまり勉強したことがない人
  • 新しい技術スゲーって言ってる人

tl;dr

  • 製品を考えるのも技術を勉強するのもその目的を見極めるのがとても大事だよ
    • その技術が解決しようとする問題を先に考えることで技術の理解が早くなるよ
    • 複数の技術を組み合わせると具合がとても良いよ
    • 色んな分野の技術を沢山見ると新しい技術の理解が早くなるよ

よりよい価値を早く届けるために正しく技術を使う

技術とはなにかについて考えるとき、「よりよい価値を早く届けるために正しく技術を使う」と考えることが僕にとってはしっくりきます。特に「正しく技術を使う」というところはいつも気にしています。

技術は正しい使い方をしなかったり、的外れな技術を新たに生み出しても、なにかしらモノが出来てしまうことがあります。ただ、その状態で「よりよい価値を早く届ける」という点を達成していることはまれだと思っています。

また、手段が目的になってしまっているのを見ると非常に残念に思います。正しい価値を早く届けるためにアジャイル手法を使うのは賛成ですが、その手法に固執しすぎてその目的がないがしろにされている例をたまに見ます。必要であればウォーターフォール気味にやるくらいの気持ちでゆるくやった方が良いと考えています。正直、サービスの基盤の設計からアジャイルでやるのはなんかおかしいと思っていて、経験上、基盤を始めにかっちり設計して作っておいたほうが、上でアジャイルやらスクラムっぽいものがくるくる綺麗にまわる気がしています。

正しい技術の話をするにあたって、先に新しい技術の事に少し触れます。

技術パラダイム「アタラシイギジュツ」に惑わされない

f:id:chimerast:20150227200112p:plain

ネットを見ていたり勉強会に出て話を聞いていたりすると、常に新しい技術の話が出てきます。どこそこのサービスはこの新しい技術を使っていてすごい、みたいな話がわさわさ出てきます。

ただ、ここで気をつける必要があるのは、「新しい技術」だからそのサービスが多くの人に使われている(売れている)のとは違うということをちゃんと認識するべきです。「新しい技術」が「新しい価値」を生み出した結果、ユーザが増えます。「新しい価値」が間に挟まらなければユーザは増えません。

新しい技術だからという理由だけですぐ飛びついて使い始めてしまうのは、一番やってはダメなことです。新しい技術なんて次々と出てきます。

「アタラシイギジュツ」と正しく向き合うために

新しい技術と正しく向き合うためには、それがなんなのかということを考えるのが一番良いです。

よく言われることですが、情報技術はパラダイムを行ったり来たりしながら発展してきた歴史があります。パラダイムとまでは言わないまでも小さな流行についても行ったり来たりしながら発展していきます。

例えば、コンピュータの歴史は、分散と集約の歴史です。トランジスタ(真空管?)に始まり、現在のクラウドによる集約まで、分散と集約を何度も繰り返しています。

ここで重要なのは、それぞれの分散フェーズ、集約フェーズでは同じような考え方に基づいた技術が使われたり生まれてたりしていることです。分散フェーズだったら前の分散フェーズのことが、集約フェーズだったら前の集約フェーズの考え方がある程度通用します。

情報技術の世界では歴史がよく繰り返す

情報技術の世界では、よく歴史が繰り返されます(自分もまだ30代のペーペーなので歴史を話すのもなんですが)。歴史を繰り返しながら、前の歴史よりは少しずつ良くなっていきます。

新しい言語が生まれると別の言語での考え方が持ち込まれて同じようなものが構築されたり、新しいOSが生まれると別の似たOSの考え方が持ち込まれたりします。新しいプラットフォームが生まれると似たような周辺技術が周りに次々立ちます。

最近のiOSやAndroidで話題になる技術や手法を見ていると、なんか十数年前にWindowsで見たなというモノがあったり、最近話題のJavascriptのフロントエンド技術も数年前にJavaやRubyで見たことあったりよくします。IoTの話なんかも一昔前にユビキタスの人たちが言っていたことが多かったり、Dockerなんかもその基礎のコンテナ技術は元をたどれば、1980年代のchroot jailで、何度かVPSやなんやらを経た結果だったりします。Deep Learningも...。挙げればきりが無いです。

とにかくこの情報技術の世界は、再発見がとても多いです。ある技術が他の技術の流行・発展によって再発見が起きたり、ハードウェア性能の向上によって再発見が起きたりします。アカデミックの世界のモノが、周回遅れで現場に降りてきて流行が起きるという事もあります。

技術スパイラルに向き合う

f:id:chimerast:20150228233759p:plain

技術はスパイラル状に発展していくととらえることが出来ます。スパイラルといっても、進行方向の技術の飛びは大きいけど、隣り合う線の飛び幅は小さいスパイラルです。かつ、重要なのは、ある分野のスパイラルに出てくるパラダイム(流行)系統の数はそんなに多くないことです。

技術スパイラルの進み方は、隣り合う線(同系統のパラダイム)から最も影響を受け、時間軸で直近の別系統のパラダイムからも影響を受けます。

歴史をよく知らない新しく情報技術に触れ始めた人が、パラダイムの移動を経験すると、なんか全然違う新しい概念が出てきたように見えてしまうことがあるのですが、進行方向の飛びが大きいだけで、過去を見ると大体その基となる技術があります。そして、その基となる技術からの差分はそんなに大きく無いです。

また、誰も見たり聞いたことも無いような技術がスパイラル上にいきなり出てくることはないです。必ず何かの考え方をベースにしており、全然別の学問で確立されている技術や事実が元になっていることも多いです(情報科学の分野のアルゴリズムには自然科学から入ってきたものもちらほらありますね。将棋ソフトのBonanzaなんかも面白い例だと思います)。

誰も見たことも聞いたこともない新しい技術は、基本詐欺かダメな技術です。

技術を正しく使う・作る

新しい技術というものの正体についてみたところで、技術を正しく使うとはどういうことなのか考えてみます。

技術は、世の中になにかしらの問題がありそれを解決する為に生まれます。逆に技術が解決しようとしている問題を知ることが出来れば、その技術が何をするものためのものなのかすんなり理解することが出来ます。

この関係を認識することで、自分自身が問題に直面したときに、どの技術を選択すれば良いかの基準ができます。

新しい技術も何か特定の問題があって生まれてくるもので、新しい技術が過去の全ての問題を解決してくれると考えるのは、一番間違った考え方です。

技術に無理させない

技術は基本的に特定の問題に対する解決策として生まれます。逆にその問題以外を解くのには適していない事が多いです。

技術は特化されたものであるほど、対象がはまれば、より良く早く問題を解決することが出来ます。そのかわりに、他の問題に適用しづらくなります。ここを勘違いして、この問題がとても早く解けたのだから、他の問題も早く解けるだろうと考えてしまうのは間違いです。

例えば、世の中には汎用言語と半特化型言語(DSLまではいかないやつ)があります。

Javaは汎用言語で、どんな問題も無難に解決し、それなりに高速に動作しますが、対象によっては他の言語で書く方が簡潔に書けたり、速度が速かったりします。

PHP(Hypertext Preprocessor)は汎用言語の皮を被った半特化型言語です。HTML(Hypertext Markup Language)を出力することを主目的とする言語です。ちょっとした動的なHTMLを吐き出すことなら、PHPはとても正しい選択肢です。正直、実際にNewsPicksのWeb版を始めに作るときにRESTful APIを叩くだけのフロントとしてPHPを使うことを僕は提案していました(外部に協力を依頼しやすいとか、デザイナと連携しやすいとかといった理由もあります)。他のエンジニアに全力で拒否されましたが。

ただ、多くの人がご存じの通り、PHPで大きなシステムを作ったりするのは大変です。HTMLと全然関係無いバッチを書いたりするのは狂気の沙汰だと思っています。これはPHPがHTMLに対する半特化型言語であることを考えれば当たり前のことです。

技術を組み合わせることを覚える

作るシステムを複数の問題に正しく分割し、それぞれの問題に対して得意な技術を割り当ると、非常に高速に開発することが出来ます。作らなければならない部分も減るので、生み出すバグも少なくなります。

例えば、プログラムを書いて作るものが難しいものでも、インフラの技術で簡単に解決ができるものが多々あります。RDBMSが無い、データ管理を自分で書かなければならない世界を考えてください。RDBMSは一番わかりやすい技術を組み合わせる例です。

また、機械学習系のライブラリはPythonがとても充実しています。それだったら、機械学習の部分はPythonで書いてJavaなりRubyから呼び出す形にすれば良いと思います。全部一つの言語でやる必要は無いです。

複数の技術を使うことでその学習コストはどうするんだという話を良く聞かれますが、正しく切り出された問題に正しい技術を割り当てれば、それを解決するために必要な学習コストは非常に低いです。技術のチュートリアルを読んでこれはすごいと思うことが良くあると思いますが、その感覚です。

逆に、適していない問題を解決する方法を学習しようとするとコストが跳ね上がります。そもそもその技術が想定していない問題を解こうとした場合です。例えば、トランザクションが必要な問題をNoSQLと呼ばれるデータベースで考えようとするととたんに難しくなります。

たくさんの違う分野の技術を知ろう

技術を組み合わせるためには、複数の技術のことを知り、それぞれの得意な問題を理解する必要があります。

一から自分の知らない技術を知ることは非常に大変に見えるかもしれませんが、先ほどの技術スパイラルの話の通り、それぞれの技術は何らかの関係があります。基礎の部分をちゃんと押さえておけば、差分を意識すると実はそんなに学習するのは大変ではありません。ある一つの言語をそれなりに極めていれば、他の言語に移るときは低いコストで移れますよね。

重要なのは基礎の部分をちゃんと押さえることです。それについては先ほどの通り、解決しようとしている問題を認識することが近道です。

また、同じような問題を解決しようとしている技術をたくさん知ってもあまり意味はありません。たいてい同じような解決法が返ってきます。もし、手続き型言語を勉強したなら、その後は関数型言語、論理型言語、もしくはDSLの作り方等、全然違う系統の言語を学ぶべきです。言語から離れてインフラの知識を身につけるのも良いかもしれません。分散処理向けの言語の考え方が身につくかもしれません。なんにせよそこで得た知識や考え方は元の手続き型言語に戻ったときにも無駄になることなく生きてきます。

上でも少し触れましたが、一つの分野のスパイラルに出てくる押さえておくべき技術パラダイム系統の本数は少ないです。10もあれば多い方だと思います。効率よく学ぶとそんなに苦もなくそれっぽく身につく気がします。くどいようですが、同じ系統の技術を学んでも知識の幅は広がりません。また、ざっと俯瞰する場合は深く調べ始めると泥沼にはまるので、解決しようとしている問題とその解決方法の組み合わせがわかったら次に行った方が良いかもしれません。細かい所については、基礎さえ押さえておけば類推出来ます。実際に使うときに深く調べたのでも遅くないです。

技術を多く知るということ

技術は多くの種類を知れば知るほど、新しいものを学習するコストがどんどん下がっていきます。スパイラルの話で書いたとおり、基本的に情報技術は組み合わせとほんの少しの差分で生まれます。ある程度知ると、この技術はあれと、これと、それから影響を受けているんだなとわかるようになります。新しい技術が出てきてもあまりビックリしなくなります。

また、逆を考えると、多くの種類を知れば知るほど新しい技術も生み出しやすくなります。何か問題にぶち当たったときに、技術を組み合わせて新しい解決方法を生み出すというのは良くあることです。

まとめ

ユーザベースでは、「ユーザの理想から始める」というルールがあります。これは、ユーザに届ける価値を考えるのが先、ただ、それを考えることで良い技術が育つ、という思いも込められています。目的を考えることで、それにふさわしい広く使われる正しい技術が生まれると考えています。

技術チームでは、新しいものを作るときには使ったことのない技術を使うことを推奨しています。新しい考え方に触れることで、視野が広がります。

ただし、使う技術が問題を解くのにふさわしいか必ず考えるという条件をつけています。新しい技術でなんか流行っているからという理由だけで、的外れな対象に対して技術を適用すると全力で叩きます。マサカリ投げます。

ユーザベースでは、正しく「技術」を使い、創り、「価値」を高速に創造し届けることを心がけています。