「Scalaのアドバンテージはどういうところか？」を深く考えた先に
インタビューイー ビズリーチ 竹添
インタビューワー アットウェア 浅野/エリシール/ジェフ エムスリー 瀬良
浅野：今日は前回の瀬良さんからのご紹介で、GitBucket という Scala で書かれているオープンソースのGitHubクローンを開発されている、ビズリーチのCTO室チーフアーキテクト竹添さんです。まずは、瀬良さんから次の紹介者として竹添さんをご指名頂いた経緯をお願いします。
瀬良：このScala先駆者インタビューで、最初にヌーラボの吉澤さん、次に私という流れできましたので、毛色を変えた話をできたら面白いんじゃないかと思いました。というのも、Scalaインタビューを実施されているアットウェアさんが受託開発をやっています。そこで、前職で受託開発をして現在では自社サービスをやっており、双方でScalaを採用した竹添さんに、前職を離れてみて感じたことや受託開発当時をふりかえりながら様々な視点で話をできたらいいなと思いました。
竹添：受託開発では結構大変でしたね。技術的な採用決定権がある仕事ばかりではなかったので、Scalaをどういう切り口でお客さんに導入してもらうかといったあたりは最初苦労しました。
浅野：弊社だと、アットウェアのバリューを出してエンドユーザや顧客に価値を届けるためには、技術的決定権だったりいいと思えるものが提案できるという要素は必要だと感じていまして、ある程度技術的なところは裁量をもたせてもらいプロジェクトを進めさせていただくことが多いです。
竹添：そういう技術的決定権やいいものを提案しやすい状況の時にScalaのアドバンテージはどういうところだと考えていますか？前職の時そういうことをよく考えていました。
浅野：私はまだまだScala駆け出しでありきたりの言葉になりますが、後発の言語ということもありマルチコア時代の並列処理が書きやすく、扱いがしやすいのと、分散環境に対して最小限のリソースを最大限に活かしていくという辺りでうまく適用できる辺りと考えています。
瀬良：Jeffさんにも話を聞いてみたいですね。
Jeff：つい最近、1ヶ月でアプリケーションのプロトタイプを完成したいという方がいらっしゃいました。（冗談っぽく）その時私は「この要件だと1ヶ月以内でJavaでやるにはちょっと厳しいですね。逆にScalaで問題なければ、何とかなりますよ。」と言いました。これが、今までのベストアンサーかもしれません（笑）。
全員：アハハハ（笑）。
Jeff：話に戻ると、お客さんにScalaを他のプログラミング言語の代わりに売りにした時は、基本的にはScalaだけではなくTypesafe社の他の技術と一緒に紹介することによって、この技術群の全体的な有用性を強調しています。
竹添：なかなか難しいところですよね。やっぱり何ができるようになるのか、保守を5年～10年して欲しいという話があったり、コストもJavaで作った時と比べてどれくらい安くなるのか、早くできるのかのアドバンテージが出せないとなかなか難しいと当時思っていました。テクノロジーの話だけだと説得力がなくて、一般的な業務アプリケーションではScalaの特徴である並列処理などのメリットも出しづらく、保守でもOSやハードやミドルウェアもすでに購入が決まっていていることもあったりで、そこに突っ込んでいくことが難しかったです。
また、お客様は技術者ではないことも多いのでテクノロジーの話をしても伝わらないこともあります。
瀬良：それっていつ頃ですか？
竹添：2010年ころから取り組み始めてScala Conferenceのちょっと前くらいまでの頃の話ですね。
瀬良：Scalaのバージョンが2.9でTypesafe社もまだ設立前、Play2がちょうど出たあたりの頃でしょうか。Red Hat 社でいうJBossのような土壌がなくて、進みにくい時代ですよね？
竹添：Scalaとしては当時はPlayがネームバリューがあって、巷ではScalaの名前を聞きはじめ非同期とか分散処理に強いという情報が本に載り始めた頃で、Playという単語で攻めていく感じでした。あとは、「うちとしてもトライアルなので一緒にやらせてください」とお願いしたり、Javaで作ったシステムのリプレース案件もあり、当時Seasarの行く先がなさそうだったので、「新しいものにしていかないと保守が辛くなっていきますよ」という話をしていました。
瀬良：アットウェアさんはTypesafeのコンサルティングパートナーということで、興味があって聞きたいことなのですが、Typesafeのコンサルテーションサービスは私が知る範囲ではまだまだ利用が進んでいないように感じています。問い合わせは感覚的に想定より多いものなんでしょうか？
Jeff： クライアントは興味は持ちますが、Scalaを使うところまでなかなかいかず、Javaなど枯れた技術を望まれている事が多いです。ScalaでというよりSparkの問い合わせが多くそれに合わせてScalaがやりやすいので、Scalaを勧めることもあります。
竹添：前職では10名くらいのチームでアジャイルで小さいプロジェクトを短期間でイテレーティブにやっていました。長い間Javaでずっとやっていましたが、これ以上Javaでやっていても生産性が上がっていかないなという頭打ち感があって、他に何か新しいものをやっていく必要性を感じました。
プロジェクト自体が小さく、限られたメンバーなのでやっていけたというところもあります。
プロジェクト規模によってはScalaで生産性をあげるということよりも、きっちり仕様に従って動くものを作ることが重視されることもあります。また、Sparkが普及したからといってScalaのデベロッパーがすごい増えるかというとそういう風には思えず、Web界隈では使われはじめてきていても、エンタープライズな開発にScalaが使われていくようにならないと、全体としてScalaデベロッパーのボリュームが増えたかという観点で厳しくて、やっぱりSIerの数の力というのはすごいという事を現職になってから強く感じました。
瀬良：竹添さんが前職でやっていたプロジェクトは割と少数精鋭でやっている事が多かったと聞いてますが、社内で相談を受ける案件は大きなプロジェクトも多かったのではないでしょうか。
そういう大きい案件は、Javaで作られた基幹システムの一部をリプレースする提案だったり、全体のリプレースに向けた提案だったり前提はあるとは思いますが、Scalaを売りにいこうとしていた大きな案件のタイプと、どう合わなかったのかを教えていただけないでしょうか？
竹添：特定のプロジェクトというより次期システムの計画を立てている段階であったり、Seasarを使っているけど今後どうしていこうか考えているという話が多かったです。大きなプロジェクトだとScalaをできる人を集めるのが難しいという理由が一番大きかったです。
当時はJava8のリリースが控えていたので無理にScalaに行かなくてもというのはありました。
浅野：違う軸で話をしますと、Java6〜7時代の停滞時期もあり、コップ本（コップ本は通称で「Scalaスケーラブルプログラミング」という書籍名です）の発売でScalaの波がきたのを感じました。
瀬良：メインでScalaを使っている人が増えてきましたね。
竹添：実は若い頃LispやHaskellをやっており言語のフィロソフィーには共感していました。ただ、それらの関数型言語は仕事で使うには無理かなと思っていたのですが、Scalaの登場ではじめて仕事で「業務と関数型の力を両立」させられる言語に出会ったというのを感じました。当時の同僚がScalaをずっと前からやっていてはじめて聞いた時には「やっぱりまだ厳しいんじゃないかな」という話をしていたのですが、それから暫く経ってSeasarの次をどうしようかという時に「Scalaはやっぱいけるかも」という話をしたのを覚えています。
瀬良：このあたりの話は以前にもおっしゃっていましたね。竹添さんの立場も変わって1年以上経ちました。違うスタイルでScalaと関わってきています。今の視点でお話が聞けると面白いんじゃないかと思います。
竹添：現職ではスタンバイという求人情報の検索サービスを作っているのですが、最初プロジェクト立ち上げの段階から数十人規模のチームを作らないといけなくて、Scalaで大丈夫かなという心配がありました。
最初から大きくしていく事も想定しておりマイクロサービスも視野に入れていました。 Scalaでやると決めたら育成や採用に力を入る必要があって、前職では無理だなと思っていたが実際にやってみたら意外とできました。
瀬良：どういう工夫をされたのでしょうか？
浅野：育てるという面で社内にScalaを浸透させて駆動していくまでにどういった道のりがあったのか教えてください。
竹添：2本立てとなります。まずは、リクルーティングは絶対に必要ですがすぐにできるようにはなりませんので、外部での発表や記事の執筆などを積極的に行いブランディングに努めました。最近ではScalaで仕事をする上での候補に入れてもらえるようにはなってきて、効果が出てきています。それと両輪で社内の育成をやっています。
基本的にその時点でスキルが不足してもScalaをやりたいと思ってくれている人にプロジェクトに参加してもらうようにしています。いくらJavaで出来る方でもScalaをやってみると詰まってしまう場合もあります。一つ目としては人を選ぶという事と、二つ目にはScalaを普通にしちゃうというのがあります。
最初は難しいと感じる事も多く、例えば「他の言語ではこんな事をしなくてもいいのに」といった話が出てくるのですが、「簡単じゃん」とか「なんでわからないの？」など普通論のレベルをあげちゃうと人はできるものだなと。また、最終的にはどこかで諦める事も必要です。必要以上にScalaらしい書き方を強要することはしません。「ここは本当はこう書くべきだと」というのはあるのですが、要件や機能を満たしていれば納期との兼ね合いを見てどこかで妥協していくという事もしています。そうやって人間的な運用をしています。
瀬良：スタンバイチームではどれくらいの人がいるんですか？
竹添：Scalaが書けるエンジニアは20人くらいはいると思います。フロントエンドとサーバーサイドを分けていて、フロントはフロントエンジニアだけで開発できるようにしています。Scalaエンジニアはバックエンドを担当し、全員がScalaを知っていないといけないという状況にしようとしていないので、それなりの人数でもやっていけています。
瀬良：それって結構大事ですよね。
浅野：できる人でやるという感じでしょうか？
瀬良：HTMLやCSSを書く人がScalaのSBTを起動しないと開発できないというのを避けないと現場が大変になってしまいますよね。
竹添：そういう仕組みで工夫できるところもあると思っています。
瀬良：ビズリーチさんのようにScalaを書けるエンジニアを10人くらい増したいなと思った時に他の会社でもやれそうなことは？（笑）
竹添：「楽しいと思ってもらえるか」ということですね。私が開催していたわけではないのですが、最初は有志で毎朝勉強会をしていました。座学で勉強というよりは、楽しくディスカッションしたり、達成感を感じる宿題を出して「できた！！」というような、心を壁に作らせない、苦手意識を持たせないというようなことができるといいのではと思います。
浅野：学ぶ時は、すぐに動いて、すぐに確認できて、すぐに効果が見える、というのがモチベーションに繋がるなと思います。取り組む時に「こういうライブラリを動かしてみよう」とか「これを使ってみよう」などテーマを持って勉強会を開催されているのでしょうか？
竹添：最初はひたすらコレクションの使い方というのをやっていて「インとアウトをこういう形にしてみよう」という問題を、GitHubですぐにダウンロードして動かせる雛形プロジェクトを作っておいて、そこでサクッとプログラミングできるような準備をして実施してました。
コレクション操作はパズルみたいなところがあるので、面白いのではないでしょうか。Futureをひたすらずーっと1週間やるというようなトレーニングもやっていたみたいです（笑）
瀬良：それは楽しいですね。（笑）
竹添：人によって面白さを感じるポイントも違うみたいです（笑）