nextbeat Tech ブログはじめました！技術だけじゃない！ビジネスを創るエンジニア組織へ。

ネクストビートは「人口減少社会において必要とされるインターネット事業を創造し、ニッポンを元気にする」という理念を掲げて事業を行なっております。そんな中で働くエンジニアでnextbeatTechブログを立ち上げました。今回は一発目のコンテンツとしてCTO(最高技術責任者) 衣笠 嘉展さんとScala界隈でおなじみの加藤 潤一さんの開発組織に関するセッション記事です。

加藤: おはこんばんにちわ、かとじゅん(@j5ik2o)です。プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動を行なっています。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。

衣笠さんとの出会いは、前職のソーシャルゲーム事業会社でした。同時期に在籍はしていたのですが、一緒に仕事をする機会はありませんでした。一世を風靡した釣りゲームを作ったエンジニアということで、僕の在籍している部署でも、噂話を聞くことが多かったと記憶しています。同じ会社にいながらも、仕事を一緒にしたことがなかったのですが、卒業生が集まる飲み会でお会いし、Scalaやドメイン駆動設計*1(以下、DDD)の話をした時に意気投合したことがきっかけです。それ以来、深夜まで技術談義をする機会が多く、ひどい酒の飲み方をお互いにして、交友を深めています(笑)。技術面で共通の課題認識を持っていることが多いことから、個人名義で時々お手伝いをしています*2。

今回は、その衣笠さんの人物像に迫るインタビューを僕が担当させていただきました。インタビューは初めてだったので、不慣れで読みにくい部分があるかと思いますが、興味があればぜひ読んでみてください。

nextbeatとの出会いと、これからどんなことをするのか？

加藤: まずnextbeatに入社するきっかけを教えてもらってもいいですか？

衣笠: これまでソーシャルゲーム事業などに関わってきましたが、5年や10年の長いスパンで利用できるサービスの開発に関わりたいというモチベーションがありました。転職先を選ぶ軸としては、組織もサービスも一から作っていくという思いが強かったので、大手企業さんというよりも自分の知らないベンチャー企業さんをエージェント経由で紹介してもらったのですが、その中にnextbeatがあったんですよね。それが最初のきっかけですね。

加藤: 特に知り合いがいたわけではなかったんですね？意外ですね。また某社出身の方の紹介とかかなと思っていました(笑)

衣笠: はい。そうなんですよね。そのような状況でいろいろな企業さんからお話を聞いたのですが、nextbeatを決めた一番の要因としては、外部投資家からの出資を受けずにリスクを取りながらも新しい挑戦が自分たちの裁量できるという点が大きかったですね。私自身もそういうマインドが強いので、nextbeatのいろいろなところで力になれるかなと思ってジョインしました。

加藤: 確かに、外部からの出資が入るとどうしても投資家は無視できないという一般的な力学はありますね。資金面やリソース面で制約はないとはいえないと思いますが、事業に対して自分たちの責任の範囲で裁量権があるってことですかね？

衣笠: そうですね。私の経験上では、今の状況はソーシャルゲーム事業での経験に通じるものがあると思っています。ソーシャルゲームの黎明期に新規プロダクトをたくさん出したのですが、新規プロダクトが当たるかどうかは本当にわかりません。それでも試行錯誤を繰り返した結果、大きなサービスが生まれたりします。そのような挑戦をする時期に、外部からの出資が入っていると事業の方向性が、どうしてもそれ一直線で進まないといけないところがあるので難しいと考えました。そのような取り組みができる会社となると多くはないので、選択肢が絞られたという背景もありますね。

加藤: 一般的な起業家の観点では、こういうリスクがあるチャレンジングな戦略は取りにくいと思うんですよね。机上で計算するとリスクが高いからそんなことしなくていいんじゃないか？とかって話になりがちだけど、あえてそういう挑戦をしたいというのは、もともとそういうモチベーションがあるってことですか？

衣笠: そういうモチベーションがあると思います。 今でこそソーシャルゲームの課金モデルは一般的に認知されていますが、当時は誰も想像できませんでした。あの課金モデルが最初から成り立つと思っていた人はいなかったと思います。でも、今ではその課金モデルが市場文化を創り上げたと思っています。そういう意味では、保育士業界でもいろいろな経営支援サービスであったり、キュレーションメディアなどの既存サービスがありますが、これらの事業もまだ黎明期であって、ITが十分に使いこなせない保育園向けのサービスというのはまだまだ少ないと思うので、そこに挑戦したいというモチベーションがあります。

加藤: 保育業界で、まだそこまでITが普及していない現状では、ITサービスとユーザの距離は遠いような印象を受けたのですが、実際はどうなんでしょうか？

衣笠: 保育事業者さま側はITで改善したいというニーズはあると思っています。最初に作ったソーシャルゲームの時は、潜在的なユーザ規模はわかっていたのですが、サービスへの誘導方法がよくわかりませんでした。それがSNSと絡めてうまくサービスが軌道に乗ったという経験があります。今回の保育士関連の事業でも、同じ状況があると思っていて、待機児童解消などのニーズがあるのに現状のソリューションとしてはうまく提供・機能できていないと思っています。我々が提供するサービスでそういう問題を解決していきたいと思っています。

加藤: 最近、ニュースでも取り上げられていますが、そういう社会的な問題が前提にあると需要としては喚起しやすいですよね。ソーシャルゲームでは、前身となるSNSがあってそこから普及・発展したように思えるのですが、保育関連のサービスではどんな切り口になるんでしょうか？やはり社会的な問題でしょうか？

衣笠: 社会問題もありますが、やはりITが使いたいけど使えないという問題が大きいですね。経営支援サービスを作っても使いこなせないという事例もあります。保護者からの要望としては、登下園管理や写真の管理などがありますが、未だに紙などでやりとりされているところがあったりします。緊急連絡網も個人情報が関わっていてやりにくくなってたりと解決したい問題はあります。園との連絡手段としてはいろんなものがありますが、未だに連絡帳で提出してやりとりしてというのが多いですね。こういった難しく複雑そうに見える機能をITを使いながら分かりやすく使えるシンプルなUIで誰にでも使えるものに解決していきたいですね。

加藤: その状況で、困っていたらIT化するといいと思うんですが、アナログでも満足している人は多いとか少ないとかはどうなんでしょうか？それとIT化されることによる抵抗感というのはあったりしないんでしょうか？

衣笠: 温かさがあるという人もいるし、不便だという人もいるし、いろいろですね。抵抗感もすごく強い業界だと思っています。

加藤: そういう意味では、人の温かさを感じられない、ただ便利なサービスというのはよくないという考え方になるんでしょうか？ 御社のKIDSNAコネクトというサービスはSNSをベースにされていると思いますが、そういう観点から来ているんでしょうか？

衣笠: その通りですね。人(保育園)と人(保護者)のつながりを大切に考えているので、そのような考え方はこれからも必要だと思っています。これまでの経験でも多くのユーザさんたちからのフィードバックでサービスを改善してきた経験があるので、今の事業でもその考え方は生かせると思っていますし、一方的にサービスを作って提供するというよりは、利用者様と一緒にサービスを作り上げたいと思っています。

CTOとしてエンジニアにどんなキャリアを描いてもらいたいのか？

加藤: 話は変わって、キャリアの話として、CTOとしてエンジニアにどういうキャリアを描いてもらいたいかという話をしたいです。ソーシャルゲームの分野から考えると、少子化をテーマをしたビジネスというのは切り口が違うので、求められる技術も違うものになると思いますが、衣笠さん個人としてこの事業分野で技術的に実現したいことは何かありますか？

衣笠: 技術的に何か達成したいテーマというよりも、ゴールに対して適切なITとしての手段という側面を考えています。たとえば、今後、保護者と園が密にチャットをするのであれば、我々がその技術水準に達しないといけないと思っています。 目的やゴールに合わせて必要な技術をキャッチアップしていくものだと考えています。

加藤: 目的に対して必要な技術を身につけていくという価値観が垣間見えた気がするのですが、エンジニアとして必要な価値観って他にありますか？

衣笠: 入社時期にエンジニアの皆さんによく聞くことで、"マネージャになりたいのか？スペシャリストになりたいのか？自分で決めてほしい”ということがあります。なぜそのようなキャリアの方向性をきめていくのがよいのか？と言われると自分のキャリアプランで必要とされる必要要件を具体的に意識してほしいからです。たとえばスペシャリストになる人は、技術に没頭するというスタンスでよいですが、複数のチームに使える形でその価値を転換してほしいと思っています。

加藤: 他のメンバーに対して技術力を底上げするような立場になってほしいということですかね？

衣笠: はい。そうです。

加藤: ちなみに、衣笠さんはどっちのタイプですかね？答えはだいたい想像できますが（笑）

衣笠: 私は経営や事業も見ていますが、どちらかというと技術特化タイプだと思います。

加藤: ですよね（笑）一般にマネージメントというと大勢のメンバーを抱えて大きな労力を割くイメージが強いと思いますが、たとえばスペシャリストで専門スキルに特化していたとしても、セルフマネジメントという側面ではマネジメントという課題は無視できないですよね。

衣笠: そのとおりですね。セルフマネジメントできない人は大変ですね（笑）スペシャリストであってもマネジメントに関わらなくていいという価値観は違うと思っています。 一方で、マネージャに対しては、メンバーの管理というよりも、プロダクトマネジメントをやってほしいと思っています。たとえば、課題達成のために組織構造を変えたり、リーチするユーザ層を変えたりと、様々な仕事があると思いますが、つまるところ、プロダクトのビジョンやミッションに基づいて、日々起こるプロダクトの問題や課題に対して、戦略・戦術面で様々な方法で貢献をしていくイメージですね。

加藤: なるほど。プロダクト中心型の組織なんですね。いわれてみたら妥当だと思いますね。その企業の成長エンジンって結局プロダクトですからね。たとえば、ウェブサービスのプロダクトマネジメントを考えると、企画と技術の両面で考えることがあると思いますが、その辺はどんな考え方になるんですかね？

衣笠: そうですね。そこについては、企画サイドと技術サイドでそれぞれに最高責任者を設けて事業を立ち上げていくことを想定しています。なぜそうするかというと、企画と技術が社内受発注のような主従の関係性に陥らないように、できるかぎり対等の立場でプロダクトについて考えて作り上げてほしいと思っているからですね。 たとえば、企画と技術にパワーバランスが悪いと機能不全になることがあります。技術に造詣がない人が企画するとフィージビリティが乏しいという問題とか。過去に所属していた企業では、エンジニアあがりの企画職が多かったのでこういう問題はなかったですが。 また、その逆のケースとして、エンジニアが頭で考える企画は、面白くないとか、使いにくいという問題もあります。そういう意味では、ユーザに近い企画職と実現能力に長けた技術が補完関係を作る組織を目指していきたいと考えています。

加藤: それはすごく共感できます。僕も過去にそういう経験をしたことがあります。技術がわからない企画職の方が自組織内で決まった提案をもってくるのですが、実装コストがものすごく高くて没になったりと。ちゃぶ台返しみたいな（笑）まぁそれはそれでいいのですが、なぜフィージビリティが低いのかを理解してもらえるまで、かなりのコミュニケーションコストを払いますね。まぁそれも必要なコストだと思うのですが、企画が発注側、技術が受注側のような関係性は、ファクトベースでアクションを起こせなくなる可能性があるので、結果的にプロダクトのためにはならないという思いは僕にもあります…。

衣笠: あるあるですね（笑） 言うは易く行うは難しなんですが、組織の体系にもよるかなと思っています。 弊社ではどうなっているかというと、所属組織は職種ごとに分かれていますが、プロダクトごとに混合職種でチームを編成します。さらにそのプロダクトチーム単位に裁量権を委譲していきます。できるかぎり、職種ごとの組織がで裁量権を持たないようにしています。ただ、横串で解決する課題や問題に対するサポートはしていきますが、事業の中心はプロダクトチームということになります。

加藤: なるほど。プロダクトチームがコアで、それをサポートする横断的な組織が周りにあるということですね。そういう意味ではプロダクトチームが社内企業のようなイメージがありますね。

衣笠: はい。そうです。小さなベンチャー企業があつまっているようなイメージに近いですね。プロダクトごとにPL/BSがありますが、使っているサーバの必要性だったり、人件費だったりを掌握できるような体制になっています。

加藤: 確かに、裁量権をもっているプロダクトチームといいながらも、事業のために経営資源をコントロールする意味での裁量がなかったりする、いわゆる形だけの裁量という事例もある中で、おっしゃるような体制はもちろん経営責任は伴いますが、合理的な考え方に思えますね。プロダクトを自分たちで経営判断していけると考えると、リスクを取って新しい挑戦をするというのもありなんですかね？

衣笠: そうですね。プロダクトを成長させるための社内制度としても、ラウンド別にベンチャープログラムを作っています。その段階ごとに評価基準で人事考課をしていくイメージですね。

加藤: ステージが進むと、子会社やバイアウトしたりということもあり得ますか？

衣笠: はい。まだそこまでのステージに進んでいるプロダクトはありませんが、ゆくゆくはそうなる可能性もありますね。

加藤: そういう話を聞いていると、独立して事業を立ち上げたいようなエンジニアには向いてそうな環境に見えますね。そういう文化があるって感じなんですかね？

衣笠: 五年後にベンチャーを自分で立ち上げてみたいというエンジニアにとっては、ある意味 経営的にはノーリスクで学べる環境じゃないかなと思っています。今在籍している、28歳から30歳までの若手のエンジニアは、30歳後半ぐらいで独立したいという人たちばかりですね。

加藤: やっぱりそういう人たちが集まっているんですね。これからもそういうエンジニアにきてほしいってことなんですかね？ある意味若くて生きがいいような。その一方でエンジニアのキャリアとして、抱えている問題ってありますか？

衣笠: そうですね。若手のエンジニアさんたちには、新規事業をやりたいという人が多いのですが、0から1を作るという方法論がわからないというのはどうしてもありますね。あとはベンチャーマインドの醸成というところですかね。

加藤: 0から1の方法論というと、知識が足りないか、経験が足りないかというとどっちでしょうね？

衣笠: 現状を見ている限りでは、やはり経験不足というのは否めないと思います。若さ故にそこまでの経験を積んでいる人はごく希だと思いますので（笑）

加藤: まぁ、そうですよね（笑）。逆に、中途のエンジニアはどんな人物像を期待しますか？経験はそこそこあるので、場数を踏んで何度も輪廻転生しているような人ですかね（笑）。あと、マインドセットについて求めることってあります？

衣笠: 0から1の事業を経験した中途のエンジニアさんについては、知識・経験があるのは言わずもがなですが、エンジニアリング以外にも、他の業務との関係性を把握したり、人間関係を適切に作っていったりというマインドセットが重要になると思っています。あと、事業を立ち上げるエンジニアは、採用力が重要だなと思っています。人は与えられるものではなく、自らプレゼンスを名実ともに高めて、獲得していくことを考えてほしいですね。たとえば、新規事業をやりたいけども、今いるメンバーがどんな人がいるか、ということばかりを気にするというケースがありますが、これは0から1を作り上げるという価値観とは少しずれてしまうと思っています。自ら作り上げていくというマインドセットを持っている人に来てほしいですね。これは社員でも業務委託の方でも同じで、業務を進めるメソッドはある程度持っているので、それをそういうマインドで進められるかどうかという話はあると思っています。

加藤: マインドの話が出たので、衣笠さん自身のマインドについて質問したいです。衣笠さんってすごく前向きな人だと思うんですが、なぜそうなんですか？(笑) 難しい状況に遭遇すると人はへこたれたりすると思うですが、そうじゃなかったんですかね？

衣笠: はい。戦う方ですね(笑) 釣りのゲームの時は過酷でしたね…。 0から1を乗り越えられたのは、その中での成功体験と、大きなチーム(数十人のチーム)で仕事していなくて、少人数のチームでやってきたからだと思います。大きなチームだと全体像を把握するのが難しいと思うのですが、少人数だとサービス全体を把握しやすいというのはあります。また、自分の責任と裁量も相対的に大きいので他人事ではなく自分事にできたことというのが関係していると思います。

加藤: あー、それはわかります。うちの会社でもチームはできるだけツーピザルールで作っています。どうしても人数が多いと、議論する際でも自分が関わらなくてもいいかという後ろ向きな姿勢になりやすいというのはありますね。チームメンバーと協働しながらも、自分の主体性や責任の大きさを感じながら仕事をするのは重要ですね。

衣笠: そうですね。端的にいえば後ろに誰もいなくて、自分がやるしかないという状況ですね。これがいいプレッシャーになりました(笑)

加藤: お膳立てがなくても、自ら考えて行動していける人ってことですかね。うちの会社でも自走することに重きを置いているので、大切さがわかります。そうやって自発的に取り組むことによって、新しいアイデアが生まれたりするので、個人的にはそっちの方が成功する可能性があったりするんじゃないかという仮説を持っています。一方で、自分に自信がないとかの理由で自律的に考えて行動できない人の場合は、そういう環境に置かれた場合は、ネガティブにとらえがちだと思うんですが、そういう人たちに対して自ら行動することによる魅力とは何か訴えられるものってありますか？

衣笠: そうですね。あくまで独立心が強いエンジニア向けという意味合いになりますが、たとえば、次のステージでCTOなどで独立した際に、ゴールに向かうために技術だけではなく、財務や法務の知識が少なからずないと、自分自身のポジショニング自体が難しいというのはあるかと思います。エンジニアとしては技術に軸足を置くのは当然ですが、先ほど述べたように小さなプロダクトチームの中で、自分なりに事業や経営に関わることで、未来の自分に対してそのような投資ができるという魅力はあると思います。

加藤: 衣笠さんは今でこそ伝説のプロダクトを作ったエンジニアという風に見えると思うんですが、実際にはそこまで到達する過程というのがあったと思うんですが、それはどういう背景がありますか？

衣笠: そこはもう、いい上司がいたらからですね。２、３名の少ないチームで、そういう人たちからいい関係で適切なアドバイスをもらえたからですね。ソーシャルゲーム事業会社では、経営目線でAさんとか、インフラ目線ではIさんとか、技術目線ではFさんからとか。Fさんがきて机を叩いたりとか(笑) たとえば、技術的にはあれこれ方法論を提案してくれるのですが、自分では手を動かさないので、自分たちがそれを具現化するというサイクルでやっていました。口は出すけど手はださない的な(笑) こういう言い方をすると悪い印象に捉えられがちですが、彼らもプロダクトを支援する役割として真剣にアドバイスしてくれました。つまるところ、提案されたアイデアをどうやってプロダクトで実現するかは自分たちで創意工夫するので、プロダクトチームの成長を促せるのではないでしょうか？ そういう意味では貴重な経験をしたと思っています。

エンジニアとしてどういうスタンスで仕事に望むか？

加藤: ちょっと話題を変えて、技術的なお話を。PHPを10年近くやってきて、今回はなぜScalaを採用したのかを聞きたいですね。たぶん、僕のせいでもあると思うんですが、聞きたいです(笑)

衣笠: それはありますね(笑)。PHPを長くやってきましたが、根幹となる基盤部分のコードを記述する際につらいなと思うようになりました。特にチームが大きくなると、実装されていたメソッドの仕様が変わることがどこでもあると思うのですが、そういう変更を共有したりする際にコミュニケーションの行き違いがあったりしたりして、障害が起こることもありました。静的型付けの言語でも完全に回避できないというのは理解していて、本質的には仕事の進め方の問題だと思います。ですが、コンパイラのチェックなどで未然に防げる単純な問題はあると思っています。 あとは、今は新しい言語へ移り変わるタイミングだと思っています。言語そのものというより、その言語が持っている新しい問題解決の考え方をキャッチアップしたいと考えています。その方が若い人にも興味を持ってもらえると思っています。

加藤: それはわかります。僕もScalaを通して問題に対してどういう解決方法を採用するか選択肢が広がったと思っています。Scalaは関数型の機能の多くを持っていますが、時には命令型で解決することもあります。Scalaは中途半端な言語だと揶揄する人もいますが、そういう人は視野が狭いと勝手に思っています(笑) あと、ScalaがよいのはJavaの基盤の上で動作するところですね。現実の運用面の問題をクリアできるのはJVMのおかげで、それがなければScalaはここまで普及しなかったと思っています。

衣笠: はい。そうですね。各社からいろいろなSDKが出ていますが、Javaに対応したものが多いのでその点を考えてもScalaは有利ですね。当然世になくて事業に必要なものはフルスクラッチで作るのもありですが、すでにある資産はできる限り流用したいですね。たとえば、AWS SDKはJavaに対応していますが、新しい言語で流用できる資産がないのでフルスクラッチで作るとなると、機能の網羅性や品質の維持なども大きなコストを抱えることになります。Scalaではよく、Javaの資産を使うと副作用がつらいという話は聞きますが、それでもやはり実績のあるものを組み込んで使えるのは費用対効果は大きいと思っています。

加藤: そうですね。そこはビジネス的に考えても大きな魅力ですね。実際の現場では、Javaの資産を流用する際のノウハウはおじさんがだいたい持っていて、それを若手の人にアドバイスするという構図はありますね(笑)。

衣笠: ですです。おじさんも若手と一緒にScalaコードを書きながらキャッチアップし、またおじさんが若手にJavaでのノウハウを共有していくという好循環な関係性を作れると思っています。結局そういうスタンスの人たちが変化に柔軟に対応できて生き残っていけるのだと思っています。

加藤: 僕もおじさんの一人ですが、若い時代にインストールされた知識や経験が正義となっている部分があって、現実問題として変化に柔軟に対応するって相当努力が必要だと思うんですが、どうですか？Scalaに関係した話ではないですが、例えば、AWSにファイルアップロードする機能を、一時的なクレデンシャルを発行してS3にアップロードしないで、EC2上のアプリケーションにそのままアップロードするのは一般的なアンチパターンですが、そういうことも頭が硬いとなかなか踏み込んで理解しようとしないって問題もあるかもしれません。偉そうにいう僕も過去にやったことがありますが…。

衣笠: はい。僕もやったことあります(笑)。

加藤: 誰もが通る道ですかね(笑) 過去の経験による価値観はそれはそれとして、新しい考え方を取り入れる努力は必要ですね。そういう人であれば、失敗をただの失敗で終わらせるのではなく、次につながる学びに変えていけるというのはあるかもしれません。

衣笠: そうですね。それはドメイン駆動設計に代表されるアプリケーション設計でも同じようなことがいえますね。状況を踏まえずに、すべての設計パターンを適用したがるとか？(笑) やっぱりそういう意味では、新しい知識を取り入れつつ、理想と現実を結びつける柔軟な思考が問われますね。

加藤: はい。僕も、理想と現実を見据えて、絶妙に妥協することが設計では重要だと思っています。たとえば、アンチパターンというものでも、文脈を踏まえればデザインパターンとなる可能性もあります。たとえば、ライフサイクルが短くて作って捨てるようなプロダクトであれば、DDDでアンチパターンとされるSmart-UIパターンが有効ですし、CQRS*3という手法を使えば重要な部分とそうでない部分の優先順位を付けて、一部をアンチパターンにすることで開発の戦略上リスクコントロールを可能にできると思っています。そういう意味で、現実に落とし込む際に絶妙に妥協できるとよいと思っています。

衣笠: そうですね。あとはシンプルな要件に対して、複雑に作りすぎるというのもありますね。非機能要件がそこまで厳しくないのに、Event Sourcing*4を採用してみたりと。そういう意味では、若手の人は、よきアドバイザーとしてのおじさんのサポートを受けながら、バランス感覚のある、柔軟な設計思考というのは身につけてほしいなと思っています。先ほども話したように、そういうおじさんたちはヒントは出すけど、あえて若い人に実践させるという関係がよいですね。そうすることで、失敗を学びに変えていける環境を作れると思っています。なんでもかんでも先輩方が答えを出すのではなく、自分の頭で考えて咀嚼してほしいというのはありますね。たとえば、Stack Overflowは強い味方なんですが、自分で咀嚼しないで利用するのはエンジニアとしてよくないと思います(笑)

加藤: なるほど。同意します。設計論だけ話しましたが、僕は設計と実装は両輪だと思っています。実装力をあげるためのプラクティスみたいなものってありますか？衣笠さんからPlay2 FrameworkやSlickやScalazのコードを読み込んだ時の感想を聞くことが多いのですが、若手のエンジニアにも日頃から使っているライブラリやフレームワークにも関心をもっと向けてほしいと思うことはありますか？

衣笠: あります、あります。よく使われているOSSのプロダクトのコードを読むこと推奨しています。それによって、技術的なアイデアの引き出しが増えると思っています。技術的な選択肢が広がるってイメージですかね。そういうアイデアを自分のたちのプロダクトにも転用できる可能性はあると思うからですね。Scalaをやるようになってから私自身もだいぶ学んだことが多いです。
これは個人的な感想ですが、長くPHPのOSSのコードを読み込んできましたが、それと比べてScalaのプロダクトはすごいなと思うことがあります。例えば、PHPのZend FrameworkやSymfonyなどは機能が豊富な反面、パフォーマンスが劣化するという問題があります。これはプロダクトが成熟するといろいろなフィードバックを受けて機能が追加されていくので仕方がないのですが、実際のユースケースではそこまでの機能がいらなかったりします。提供者と利用者のギャップがフィットされていないって感じですかね(笑)
Play2は割と実装者目線で必要最低限の開発が進められているように思います。フレームワーク側がなんでもかんでももりもり機能を提供するのではなく、標準で用意されているシンプルな機能である程度の要件に対応できるような設計になっているのがよいと個人的に思っています。フレームワークの進化とともに書きやすくなったり、コード量が減ったりするのを体験しています。

加藤: Play2はドキュメントが翻訳されていますし使っている人も多くなったので、ハードルはそこまで高くないですよね。僕はAkka*5の英語のドキュメントを四苦八苦しながら読んでますが(笑)

衣笠: いや、まぁ日本語のドキュメントでなくても、ソースコードを読んでしまえと思ってやっています。コードは結構読みやすいと思っています。

加藤: なるほど。ちょっとまた違う質問をしますが、新しい言語を検討する上でGo言語は選択肢に入らなかったのですか？

衣笠: Scala, Go, C#, PHP, Hack, Rust, OCamlは検討しましたが、いくつかの点でScalaの方が魅力的でした。一つ目は先ほども話しましたが、最悪Javaの資産が使えることですね。二つ目はLightbend社のエンジニアが書くコードが洗練されていて読みやすかったことですね。個人的には、あれはもうびっくりするレベルでした。ライブラリー不具合などで何か必要に迫られた場合は、コードを読み込まないといけないのでこの評価軸は無視できませんね。

加藤: 僕も仕事で使っているので、Akkaのリポジトリを日々読みますが、Actorのコア部分のコードは薄くてシンプルでわかりやすいですね。社内読書会でコードを眺めようとなったのですが、概要を把握するのにそこまで時間はかかりませんでした。

衣笠: そういうモジュール化されているところは当然よいのですが、ForkJoinやトランポリン再帰による最適化がなされたExecutionContextがあったりと、開発者側であれこれワークアラウンドを考えずにアプリケーションコードに集中できるというのがよいですね。

加藤: そういう意味ではJavaで苦労したことが、Scalaだとなんだったんだという状況ですよね。Threadに対するFutureやActorなどもそうですね。まぁ、この手は機能は高レベルAPIを提供するものなので、問題に直面した時には低レベルな知識は必要だと思いますが、さすがに僕も生のスレッドは扱わなくなりました。volatile宣言も最近書いたことがありません(笑)

衣笠: Scalaはそういう非同期やのブロッキングI/Oなどがやりやすいというのが、PHPと違って大きな魅力ですね。ウェブアプリケーションでいうと、昔はサーバサイドでHTMLを生成してクライアントは表示するスタイルで、それほど端末数も多くなかったと思いますが、最近は、スマフォの普及も相まって、ReactやAngular2などに代表されるSPA*6スタイルで端末数の比較的多くなってきているので、非同期にどれだけリクエストを捌けるかという問題がありますね。

加藤: そうですね。昔と比べて小さなリクエストが非同期にたくさんリクエストされる状況ですものね。俗にいうC10K問題*7ですよね。そういう新しいプログラミングモデルに従わなくても、サーバを増やせばいいのでは？という確かに発想もありますが、コストパフォーマンスの効率は事業の側面で考えると無視できないと思うんですよね。

衣笠: はい。サーバとしてはいかにコアを有効に活用できるかという点に特化した方が今の時代にあっていると思っています。そういう意味ではScalaを選んでよかったと思っています。

加藤: 時代の要求に合わせて、言語やスタックを選んでいくという考え方は同意します。クライアントサイドでもそういう考え方で選んでいる感じですか？

衣笠: そうですね。うちでもAngular2をRCから使ってTypeScriptでコードをバリバリ書いていますね。RC5になってからNgModuleが登場で結構変わったのですが、、、すでにAngular4もプロダクトに使ってますし、新しいことは常にキャッチアップしていきたいと思っています。なので、新しいことに関心があるエンジニアにぜひエントリーしてほしいですね。

加藤: 長くおつきあいいただきましたが、いろいろな話を聞かせていただき大変勉強になりました。ありがとうございました。また、機会があればよろしくお願いします！

nextbeatホームページはこちら↓

https://www.nextbeat.co.jp/

wantedlyからのご応募はこちら↓

https://www.wantedly.com/companies/nextbeat2

*1:エリック・エヴァンスのドメイン駆動設計、ソフトウェアで解決する問題や関心事を中心にソフトウェアを設計・実装するための手法

*2:現在在籍しているChatWork社からは許可をいただいています。うちの会社はなんと寛容なんでしょうー(ステマ

*3:Command and Query Responsibility Segregation の略。コマンド・クエリ責務分離。2010年 Greg Young氏が考案。Bertrand Meyer氏が考案したコマンドクエリ分離原則(Command-Query Separation:CQS)をアーキテクチャに適用したものがCQRS。http://martinfowler.com/bliki/CQRS.html

*4:最後に確認された状態を基にするのではなく、発生した出来事(イベント)を基にするアーキテクチャ。http://www.martinfowler.com/eaaDev/EventSourcing.html?s_tact=C43202QW

*5:Erlang OTPの概念をScalaに輸入したプロダクト。リアクティブシステムを実現するためのプロダクトの一種。 http://akka.io/

*6:一つのページで実装されたJavaScriptアプリケーション。https://en.wikipedia.org/wiki/Single-page_application

*7:インターネットの普及によりサーバが一万ものクライアントを処理しなければいけなくなったという問題。 http://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem