竹添：私がこのインタビュー企画のお話を瀬良さんから「元SIerとWeb界隈の両方経験を合わせた話を聞きたい」ということで紹介頂きました。私はSIerで頑張りきれなくて挫折してしまったのですが（苦笑）、現役でSIerで頑張っているTISの前出さんだと貴重なお話が聞けるのではないかと思い、声をかけさせて頂きました。Web界隈ではScalaを使っている会社はたくさんあって、色々な方からお話を聞けたりご紹介もできそうでしたが、私自身も話を聞いてみたいと思いました。
前出：苦しい話ばかりかもしれませんねー（笑）
浅野：言われてみると、Scalaイベントでは発表者は自社サービスの方が多いイメージですね。
前出：そうですね。でも、確か、竹添さんがScalaMatsuriで最初に発表された時にはSIerに在籍中でしたよね？
竹添：はい、一昨年が前職で去年が現職でした。
前出：私が業務の一環としてScalaの活動をし始めた時には竹添さんが作って下さった道があった気がします。例えば、Scala逆引きレシピが出版されていたり、Javaとの比較をしたプレゼンをされていたり。きっと竹添さんがSIerで取り組まれていた時に比べると、まだやりやすさはあったのだと思います。
竹添：私がやっていた時は小さなチームでやっていたので、会社名を背負ってやっていたわけではなかったのですが、前出さんはTypesafeの取り組みを含め会社の看板を背負ってやっている印象があります。
「最初から苦難の連続でした」
前出：最初の1年くらいはこじんまりと活動をしていました。Scalaを会社でガッツリ使う方向に持って行きたかったのですが、すぐには実現できず、R&Dとして継続して活動していくには会社への何らかのメリットが必要で、模索した結果としてTypesafeとパートナーシップを結びコンサルティングサービスを始めました。R&Dとしてやって行く限りは、会社の看板を背負っていることは常に意識しています。
浅野：会社ではその取り組みを一人でやり始めたのでしょうか？
前出：はい、元々は研究開発の部署で社内フレームワークを作ったり・社内展開をしたりして生産性をあげることを目的とした取り組みをしていました。そこではSeasar2をはじめOSSを活用し、3〜4年間で自分なりにやりきった感はありました。さらに生産性をあげる事を求められるわけですが、社内フレームワーク自体の機能拡張やCIなどの周辺技術の改善だけでは、生産性をあげていく事への頭打ちが見えてきました。
そういうなかで、これまで大前提としていたJavaから言語を変える事を視野に入れ始めた時にScalaに興味を持ち始めました。動的型付け言語はチームがスケールしていく上で選択肢として外しおり、「LLみたいに使えて且つ静的型付けで、我々の持つJavaの資産も使える」ことがScalaを選んだ理由です。
竹添：私もJavaで生産性が頭打ちになって他に何かやらなければならないと感じScalaをやり始めたので、動機は前出さんと同じですね。
前出：また、当時のSeasar2は新たに機能追加をしないという状況で、これまでメインで開発とかサポートをやっていた社内フレームワークは社内標準ではなくなるという決定が下されたということも後押しし、自身も次のステップに移ることを決め、次世代の標準フレームワークを模索するということで本格的にScalaに取り組むことにしました。
そこからはScalaで社内向けのフレームワークを作り直したりしました。当時の社内フレームワークはOSSにはないエンタープライズ向けシステムでよく使うような機能群に加え、賛否両論ありますが自動生成系の処理もやっていたので、生産性を考えてScalaで開発するためのGeneratorも作ったりしました。しかし、Scalaという新しいものの壁は大きかったです。様々な障壁があり、単に生産性が高い言語というだけではScalaの浸透はできませんでした。
「Scalaの言語の力で生産性をあげることからReactiveへの転換」
浅野：その後、方向性についてはどう考えましたか？
前出：これまでの社内フレーム同様の環境が整えて、その上でScalaを使えば言語の力で生産性があがる、という方向性では難しさを感じました。ちょうど悩んでいた頃（約1年前に）海外に2ヶ月間赴任する機会があり、Typesafeの方や現地エンジニアの方々とお話させて頂き、「Reactive」が注目されている事を知りました。そして、Typesafeのとあるセールスの方から「Scalaで推して食いついてくるのはあなたみたいなScala大好きなプログラマだけだよ（意訳）」と言われました（笑）「これからはリアクティブのようなユーザーへ価値を提供できるもので推していかないと」という話をしていたところに、Typesafeのホームページもリアクティブ推しに変わってきて、我々も言語推しを控えめにしてリアクティブ推しに変えていこうと考えました。
浅野：弊社でもエンジニアは殆どJavaをメインに使ってWebアプリケーションを書いているのですが、Scalaの取り組みをしていこうとした場合に、言語推しだけだと厳しくて、問題解決領域にフォーカスしてその中で浸透を深めようとしています。
前出：「誰もがScalaを使うと生産性が2倍になるのであれば、全社をあげて1,000人のScalaエンジニアを教育していくぞー」という事が言えれば響くのかもしれませんが、生産性が多少変わるくらいだと難しいですね。
竹添：SIerでやっていた当時は実際に数値もとって「生産性2倍」を謳っていました。少人数でScalaを使ってやれば倍くらいにはなるとは思うのですが、SIの場合は開発のボリュームがあって、100人〜200人くらいの規模でScalaを使って倍になるかというと別の話が気がします。私は小規模なチームで生産性を出す事にフォーカスしていたのでやりやすかったのですが、TISさんはどういうステージなんでしょうか？
前出：小規模なシステムやサービスには適用してみました。早く効果を出すという面で小さいチームで早く作る時のベストプラクティスや得意領域を作っていくのはアリだと思います。ただ、それだけで終わってしまうと、SIerとして価値を見出せなくなってしまいますので、最終的には会社全体の生産性を上げていくのに繋げていきたいのです。この辺りの話は今も葛藤があり結論を見い出せていません。
「Reactiveはクラウドは落ちる事を想定するという所で強みとなる」
竹添：素朴な疑問ですが、リアクティブ推しでコンサルは実際にささるのでしょうか？今週、そういう話題をTwitterでつぶやかれているのを見たので。（笑）リアクティブって必要なところはあるとは思うのですが、社内標準的にWebアプリケーションを作るときにどこに使うのだろうと...
技術要素としてはトラフィックが多くてメッセージの流量が多いところにはハマりますが、大人数でエンタープライズなWebアプリケーションを開発する場合の全体の基盤として必要なのかを個人的に疑問に感じています。
前出：トラフィックと障害に強いというところを売りにして行きたいのですが、そういうシステムはインフラと運用とセットでがっしり対策しているので、差別化要素とはなかなか言えません。もちろん、コストメリットはあると思います。一方、エンタープライズ領域も徐々にクラウドに乗せていこうという流れがあります。クラウド以前は、アプリはA社インフラはB社が担当するというタッグを組み、絶対に落ちない基盤を担保するという事をしていました。しかし、クラウドでは落ちる事を想定しないといけなくて、尚且つ、インフラベンダーは存在しないので、アプリ側でそこを担保することが１つの差別化要素と考えています。
それでも、大きいシステムはクラウドに持っていくのは簡単なことではないので... なかなか難しいですね。
「Web界隈ではScalaは盛り上がっているけどSIerにはもう少し...」
浅野：少し話は変わり「現在のScalaを取り巻く状況が2〜3年前には想像ができていなかった」と竹添さんが前回のインタビューで言っていましたが、前出さんはどう感じていますか？
前出：Web界隈では盛り上がっているけど私が働くSIer周りではではまだまだだなと。例えばお客さんのシステムをリアクティブシステムやScalaベースで作るために、弊社が提案しても、まだ弊社でしかできないと見られてしまいます。一見、他社から差別化できて理想の姿に見えるかもしれませんが、お客様からするとTISしか作れなくて、TISしかメンテナンスできないシステムにはしたくないですよね。OSSベースなのにある意味ベンダーロックみたいな。「Web界隈では盛り上がりはあっても、エンタープライズでは特定の会社にしか頼めない」のが現状ではないでしょうか。
お客様はある程度いろんな会社、知名度の高い会社もやっているというのがないと技術にYesと言いづらいですね。
浅野：そういう意味ではSparkがそういう感じかもしれませんね。IBMの数万人投入というニュースがあったり。
竹添：Sparkに関してはどうでしょうか？
浅野：弊社では関わっている案件でSpark関連のものが出始め、盛り上がりは感じています。
前出：Sparkは先日うちのメンバーがハンズオンセミナーをやったり、触り始めましたがまだ本格的には取り組んでいません。現場では使っているのか、使おうとしているところなのか定かではありませんが、そういう声は聞こえてきます。
竹添：Sparkはデータ分析であったり、Hadoopからの置き換えで高速化を狙ったりと引きは多そうです。数台のクラスターで使い始めることができるという手軽さもありますね。
浅野：大きなSIerさんで大規模プロジェクトだとSparkがセットくらいに思っていました。
竹添：去年あたりまではSparkはバグも多かったのですが、最近は安定してきてライブラリも出揃ってきて使える状況になってきました。
浅野：AWSのEMRがSparkに対応して、気軽に使えるようになって一波きた気がします。
前出：こんなにSparkを勧められるとは思いませんでした（笑）
竹添：エンタープライズでScalaというと、私がSIerでやっていた頃はそれくらい突破口を見出すのが難しかったです。
「理想形は現場がScalaでやりたいと言い出してやれること」
浅野：自社のエンジニアでみんながScalaやっているイメージは湧きますか？
前出：私のイメージする理想形は、まず10人くらいのチームを作って、小規模でもいいのでScalaで開発します。そして、別のシステムを作るときは、コアメンバ以外は固定せず、メンバーをどんどんローテーションすることで、現場にScalaエンジニアが散らばっていきます。その状態になれば、最終的にどの技術を使うかを決めるのは現場の人たちなので、現場のチームがScalaをやりたいと言い出して、「これもScalaでやろう」「あれもScalaでやろう」となっていく形ですね。
今は、Webシステムのスクラッチ開発ではJavaベースでフルスクラッチの社内フレームワークが標準になっていて、それ以外の方法で作るとなると十分な説明が求められ、それを避けるため、標準以外に最適なモノがあるかを議論せずに、標準を選択してしまうというケースさえありました。
Scalaを標準として展開するのはなかなか難しく、現場がこの技術が良いと思って選択してくれるのがベストでそういう流れを作り、それをサポートしたいですね。
竹添：カルチャーを変えるところからですね。
浅野：「カルチャーを変える」いい響きですね。
竹添：アーキテクトがいないプロジェクトだと保守的に社内標準を使うというのはあることはありそうですね。場合にはよってはR&D部門から導入支援もしてもらえるし、使いやすいというのは実際現場としてはあるわけで、そこに対抗していくのは難しいですね。
前出：そうですね。さらに、SIは自社サービスとは違い、新しい技術を導入するにはお客様を説得しないといけないという苦労もつきまといます。
そのためにも、自社の取り組みを社外にも発信していますが、他のSIerさんにも入ってきて、どこでもやっているくらいにしないと、いくら現場がやりたくてもお客さんにYESと言ってもらえづらく、両方のアプローチが必要になります。
浅野：Scalaで作りたいことが普通になる状態になる必要がありますか？
前出：そうですね。普通になって、幾つかの会社が「Scalaで作りたい」と名乗りをあげる状況になっていないので、今は自分の周りで普及している感が実感できていません。
浅野：前出さんのような先駆者の方の姿や事例を周りが見て「使ってもいいんだな」と思って広まっていたという形は2年くらい先にはきそうでしょうか。
前出：うーん、２年ですか... R&Dとして成果を出さないと、そこまで続けていくのは厳しいかもしれませんね。今年も、成果が出なければ最後かもしれないというつもりでやっています。幸い今年はコンサルサービスを立ち上げるということで１つ形になりましたし、来年も続けることができるなら今年以上の成果が出せないと最後かもしれないというつもりでやっていきます。広まって使えるのが先に来るのか、ちょっと無理だなと判断する時期が先に来るのか？(笑)
竹添：SIerでScalaの火を絶やさないようにしていって欲しいです。(笑)
前出：はい、わかりました。（微笑）
「モチベーションは反骨精神かもしれません（笑）」
浅野：今Scalaに一番面白み感じるところはありますか？
前出：最初はコレクションあたりを扱うのが楽しかったです。一時期、生産性に着目していたこともあり、「どれくらい短いコードにするか」を楽しんでいた時期があったりしました。今はなんでしょうかね（笑）
浅野：一人でこれだけ推進しようとするには相当モチベーションがないとできないと思うのですが、どこから湧いてくるんでしょうか？（笑）
竹添：ないとできないですよね。
前出：SIerからWeb界隈にいっぱい流れてっている人達がいるのは、ある意味モチベーションになりましたね。自分がSIerでやるしかないと。
竹添：あまのじゃく的ですね（笑）
前出：会社では誰もやっていない新しいことをやろうとしているので、ぶつかることは多かったですね。会社の予算でやらせてもらっているので当たり前なのですが、事ある毎に説明し認めてもらう作業に時間を取られて何も産み出せない時期があったり、なんで続けているんだろう...
自分がやりたいと思って始めたことを途中で投げ出すのが嫌な性格なので、いつの間にか引けなくてなっているのかもしれませんね。
今では、一緒にやる仲間もいますし。
今はJavaがあたり前になっていて、それは誰かが普及させたわけで、Scalaをそういう感じで「Scalaをこの会社に広めたのは自分たちだ！」という未来を思い描いたりして、そんな日がいつか来るかなというのが密かなモチベーションなのかもしれません。
竹添：「この会社で...」に留まらず「日本のエンタープライズで...」とか「SIerで当たり前に使われているのは自分がここまでやったんだ」ぐらいで（笑）
大きなところで施行事例がでて来ると他社さんも使いやすくなると思うので、TISさんみたいな大きな会社が第一歩を踏み出して、Seasarの時のような感じで適用事例が世に出て盛り上がっていければいいですね。銀行さんの事例とか。
前出：いいですね。我々が言っているだけでなく、銀行さんなども一緒に事例を発表してくださるようになると本当に普及したって言えるんでしょうね。
「リアクティブのトレードオフは運用がキーになる」
浅野：社外の方を交えた勉強会などされたりしているのでしょうか？
前出：Scalaに関してはReactive System Meetupを開催したのと、細々とReactive Design Patternsの読書会をやっているくらいです。
竹添：意外と営業さんが勉強会の情報を見ているんですよね。営業さんはお客さんと密に対話しているので、ベンダー丸投げではなく内製のすることの重要性などもわかってきています。そういう意味で、そういう方に目につくように社外に情報を出していくのはいいことだと思います。
前出：Meetupはもっとやっていきたいと思っていて、今期もやる予定です。ぜひそこでも登壇お願いします（笑）
竹添：ぜひぜひ。
竹添：技術的な質問をさせてください。Akkaは使っていて大変だと思うのは、プログラムはシンプルに非同期に書けるのですが、設定やスレッドプールの管理が難しいと感じていて、その辺りのトレードオフはどうでしょうか？
プログラミングモデルとしてはシンプルだけど、ランタイムは複雑になるというあたりの捉え方です。
前出：Akkaを使わず非同期処理を実装するためにロックを考慮したり、デッドロックのことも考慮したりということを考えたら、それだけでもメリットは大きいと考えています。設定の部分は、最近はTypesafeモニタリングを使ってActorの状態を監視してみたりしていますね。
竹添：単純なスレッドモデルと比べ、Play Frameworkの場合はバックエンドで動いているAkkaのアクターを意識して複雑な設定をする必要があります。普通のWebアプリケーションを作っている分には割に合わないんじゃないかと。
浅野：Webアプリでは同期処理がほとんどなので、Webアプリを非同期ベースにするのは今じゃなくてもいいのではという話をしていたりします。裏でデータを捌くところを非同期という感じで、使い分けを模索しています。
まだ、適用事例をいくつか試したいという段階です。
前出：私も運用で本気で困るくらいまでは使い倒せていませんね。
最後に
浅野：最後に、次の方をご紹介いただけないでしょうか。
前出：リアクティブに導いてくれた、当時アメリカにいた大村さんをご紹介します。アメリカで出逢った時はOGISさんだったのですが、現在はチャットワークさんで働いています。プログラミングScalaの翻訳もされていますね。
竹添：このプログラミングScalaという本はScala逆引きレシピを書くときにコップ本（コップ本は通称で書籍名はScalaスケーラブルプログラミング）と共にとても参考させて頂きました。
浅野：では、本日は長時間どうもありがとうございました。
出席者
- インタビューイー TIS 前出
- インタビューワー アットウェア 浅野、 ビズリーチ 竹添
