登壇者の紹介
久松氏：本日はモデレーターを務めさせていただきます久松と申します。現在、Offersでは『デジタル人材総研』の所長を担当しております。
我々の領域ではデジタル人材の流動性についてよく言及されますが、デジタル人材がどのようにキャリア選択を行っているのかなど、デジタル人をテーマに、月1程度に何かしらのリリースを行っています。本日はよろしくお願いいたします。
今日の役割として、登壇者の皆様のお話を掘り下げることになります。それでは、まず登壇者の自己紹介から始めていただければと思います。最初に加藤様、よろしくお願いします。
加藤氏：はい、加藤潤一と申します。現在はChatworkのテックリードを務めています。10歳からプログラミングを始め、SIerでさまざまな現場での経験を積んだ後、Web領域に転身しました。直近では大手ソーシャルゲームの会社などで、Scalaやドメイン駆動設計を採用したシステム開発を行ってきました。直近では2014年の7月からChatworkに在籍していまして、技術的な負債の返済や次期アーキテクチャのプランニング・設計・開発などを手がけています。今日はよろしくお願いします。
久松氏：ありがとうございます、次に竹端様、よろしくお願いします。
竹端氏：はい、竹端と申します。現在はフリーランスのエンジニアとして活動しています。以前はSIerなどでいくつかの仕事を経験した後、サイバーエージェントグループでゲームの開発を10年ほど行っていました。主にソーシャルゲームの運用や新規開発、マネジメントなどを行い、その中でKotlinでのサーバーサイドの新規開発に参加しました。
その経験からKotlinに関するブログの執筆や登壇などの情報発信を行い、サーバーサイドKotlinに関する書籍も出版しました。2020年からはフリーランスとして、サーバーサイドKotlinの技術顧問の仕事や、他の言語での開発やフロントエンド、インフラなどの業務にも取り組んでいます。本日はよろしくお願いします。
久松氏：竹端様、ありがとうございます。それでは早速、ディスカッションに移りたいと思います。まずは、お二人からそれぞれのご意見をお聞きしたいと思います。
ディスカッション
言語を選定した理由 魅力を感じた点について
久松氏：まずは、お2人がそれぞれの言語を選定した理由や魅力に感じた点を教えてください。加藤さんはScala、竹端さんはKotlinのどういった点に魅力を感じたのでしょうか？
加藤氏：私は元々Javaの開発を多くやっていました。さまざまなフレームワークやライブラリを試す中で、ビジネスロジックを効率的に書くためには、どういったことが必要かを常に考えていました。その結果としてScalaに辿り着きました。それが2009年頃のことです。
Scalaの魅力は、プログラミング言語としての表現力の高さです。これまでにない選択肢が増えたことで、開発における設計の幅が広がりました。
久松氏：それでは、竹端さんはいかがですか？
竹端氏：私がサーバーサイドKotlinを始めたのは2017年のことです。元々Javaを長く使っていました。しかし、新しい言語に挑戦したいという話が社内であり、また、自身も新たな選択肢を模索していました。その中で候補に挙がったのがKotlinです。
その頃は主にAndroidの開発で使われているイメージが強かったのですが、GoogleI/OでAndroidの公式開発言語になるという発表があったことでKotlin自体が盛り上がっていたこと、またJavaで有名なSpring FrameworkがKotlinのサポートを始めるという発表もあったため、Kotlinに注目しました。
新しい言語でプロダクトを作ることは大きな決断ですが、過去の資産を活用しながらモダンな形で書けるようになり、Javaのフレームワークやエコシステムがサポートしてくれるという安心感もあり、Kotlinを選択しました。
久松氏：やっぱりKotlinを使っている方々は、元々Javaを使っていた人が多いのでしょうか？
竹端氏：Javaの経験を持つ人が多い可能性はあります。ただ、それが直近の経験であるかはわからないですね。また、以前はJavaを用いて使って開発したいと思ったようなシステムでも、現在ではJavaではなくKotlinを使う選択肢も存在します。
例えば、Javaが適しているけれども、新しい言語で開発したいという場合に、その中間をとってKotlinで開発するというパターンもあるのかなと思います。
久松氏：ありがとうございます。ぜひScalaについても同じ質問をさせていただければと思いますが、いかがでしょうか？
加藤氏：元々Javaを使っていた人はもちろんいますが、TypeScriptやOCaml、Haskellを使っている人も多くいます。ScalaはJavaから見るとかなり遠い言語で、Kotlinの方がJavaに近いと思います。しかしScalaは関数型に強く傾いており、Javaのフレームワークはそのままでは使いにくいという特性があります。
それゆえに、Scalaでは独自のエコシステムが存在し、SpringではなくAkkaやPlayFrameworkを用いる方が自然であると思います。つまり、Scalaは関数型言語文化圏に近いと言えます。Scalaを使っている人たちは、そのような特性を好む傾向にあるようです。
学ぶ上でハードルは何でしたか？それをどのように克服しましたか？
竹端氏：それでは、私の経験に基づいてお話しします。Javaの経験があるかないかで、Kotlinの学習に影響があるかもしれません。先ほど触れたフレームワークやエコシステムの利用といった要素が関わってきます。
新たに何かを作るときに、その言語自体の知識だけでいうと、それは全体のうち2割程度だと思います。残りはエコシステムやプラットフォーム、クライアントの仕組みといった要素を学ぶ必要があります。
Javaの経験があればそのエコシステムなどの知識は再利用できる可能性があるため、その場合は学習ハードルが低くなるかもしれません。Java7より古いバージョンを使っていたら別ですが、Java8以降、つまりストリームAPIが導入されて関数型の考え方が入ってから学び始めた方々にとっては、Kotlinの学習は比較的容易になると思います。
ただし、それはフレームワークやエコシステムなどが同じ環境、同じ技術セットで学習する場合の話です。それがない場合、他の言語と同じぐらいの学習コストが必要になるのではないでしょうか。とはいえ、他の言語に比べてそれほどハードルが高いとは思いません。どちらかと言えば、Javaを知っていれば学習をショートカットできるようなイメージです。
久松氏：Kotlinを学ぶためだけに、わざわざJavaを学習する必要はないということですね。
竹端氏：そうですね。もしJavaのライブラリやフレームワークを使用するなら、JavaのフレームワークやJVMの知識が必要になります。
しかし、それはJavaの知識というよりはフレームワークの知識やJVM自体の知識ですので、Kotlinを学ぶ過程で自然と勉強することになるでしょう。
久松氏：ありがとうございます。加藤さんはいかがでしょうか。
加藤氏：最近のプログラミング言語は関数型の機能を取り込んでおり、後発のオブジェクト指向言語にその要素がないものはほとんどありません。たとえば、最新の言語であるKotlinやSwiftもそうです。関数型のカルチャーは、かなり浸透してきています。そのため、学習に対するハードルは決して高くないと思います。
しかし、命令型のプログラミングに慣れている人にとっては、関数型の特徴であるmapやfoldのような関数をいきなり使うのはハードルが高いかもしれません。
このハードルを乗り越える方法としては、ScalaやKotlinのような言語でも、命令型の記述を維持しつつ、徐々に関数型の完成形に慣れていくのが一番良いと思います。
自分が以前に経験した難点は、Scalaではコレクションを関数型で書かなければならないという点でした。コレクションのAPIが基本的に関数型でしか書けないので、できないと仕事に支障を来たします。この点ではKotlinとは少し違うかもしれません。
スキルテストで見る観点
久松氏：関数型言語のScalaやKotlinのエンジニアを採用する際、スキルテストでどのような観点を重視しますか？
加藤氏：Scalaをすぐに書けるかどうかよりも、アルゴリズムや処理手順を日本語で適切に説明できることが前提です。そういった説明ができる人であれば、ScalaやKotlinなどに対応することはそこまで難しくないと思います。
もちろん、関数型言語で副作用のないロジックを書く能力には経験が必要になりますが、それは採用するポジションによるでしょう。シニアなのか、ジュニアなのか、それぞれの立場で重視する要素は変わってきます。
ジュニアであればこれからの成長の可能性を重視し、シニアであればこれまでどのような経験をしてきたかを知るため、そのポートフォリオを重視します。ですので、一概にスキルテストだけで測ることは難しいとも思います。
久松氏：ありがとうございます。竹端さんはいかがでしょうか。
竹端氏：採用要件を決める時、特定の言語の経験を重視することはあまりありません。Kotlinのみに限定すると、採用が厳しくなるのも一因です。
オブジェクト指向言語には触れてて欲しいな、くらいは考えます。ですがより重視するのは、その言語を用いて何を作り出してきたか、どういう設計を考えてきたかという部分です。
ただ、プロジェクトの状況によって今すぐにバリバリコードを書ける人が必要な場合は、Kotlinの経験がある人やJavaでSpringFrameworkを使ったことのある人を探す必要もあると思います。
経験がない場合は、新しいプロジェクトに入った時には言語以外も含めさまざまな学習が必要になるので、その一環としてしっかりとキャッチアップできる人かどうかは確認します。
最も印象に残るプロジェクトや経験はどんなものでしょうか
久松氏：お二人にとって、最も印象に残るプロジェクトや経験は何でしょうか。
竹端氏：初めてKotlinを導入した時のプロジェクトが非常に印象に残っています。当時、私が所属していた会社では、新しいプロダクトを作る際にテンプレートとなるJavaのプロジェクトがあり、様々な機能が既に組み込まれていました。そのテンプレートのプロジェクトを全てKotlinに置き換え、新しいプロジェクトを作成するための新たな基盤を構築したのです。
そのコードは非常に多く、IntelliJの機能を使って一気にKotlinに変換したのですが、多くのコンパイルエラーが発生しました。それらを1つずつ解消しながら、併せてKotlinの特性に合わせてコードを書き換えました。
その新たな基盤を使って新しいプロジェクトを開始し、結果として1つのプロジェクトをKotlinで0からしっかりと作り上げることができたことは大きな成果でした。
しかし、振り返ると当時のコードには改善の余地が多く見受けられます。特にKotlinの特性を十分に活かせていなかったという点については、少々後悔しています。
久松氏：差し支えなければで構いません。その後悔ポイントとはどのようなものでしょうか。
竹端氏：Java的な書き方が一部残ってしまったかな、と感じる部分はありました。その理由としては、一部のコードがJavaと共存していたためです。例えば、O/Rマッパー周辺の部分では、データベースのテーブルに紐付いたデータ保持のためのクラスが、元々はJavaのO/Rマッパーの機能によって自動生成されていました。しかしこれはJavaでしか生成できず、結果としてそのままJavaの形式で使用していた部分がありました。
それが最近では同じフレームワークでもKotlinで生成できるようになりました。それに伴い、そのフレームワークを呼び出す際の書き方も変わりました。
久松氏：ありがとうございます。加藤さんはいかがでしょうか。
加藤氏：2014年ごろからChatworkのPHPの技術的負債を返済するようなプロジェクトを立ち上げました。当初は紆余曲折がありましたが、2016年末にメッセージのデータを扱う部分をScalaで置き換えました。
当時、メッセージの総数は約10億件ほどあり、これをAkka、データベースはKafkaとエッジベースを使った分散システムに移行しました。この経験を通じて、障害に強いシステムを作り上げるというAkkaの特徴を身につけました。
例えば、データベースのネットワーク障害が起きたときでも、そのネットワーク障害が回復すると自動的に残りのタスクが再開できるといった回復力がAkkaには備わっています。このような高い対障害性を持つシステムを比較的簡単に作ることができました。
もちろん、分散システムの知識は必要ですが、それを使ってサービス運用が安定し、夜中に起こされることもなくなりました。
また、Chatworkでは基本的にAkkaを使うという方針を持っており、システム自体が障害発生時に自動的に復元するように設計しています。このように、全体の障害につながることのないようなシステム設計を心掛けています。
これは、ScalaやAkkaの文化圏では一般的な考え方で、この考え方は関数型や障害に強い設計の考え方をCQRSやイベントソーシングをうまく使って進めてきた経験は大きな学びとなりました。
ScalaからKotlinを、KotlinからScalaを見てどういう印象を持ちますか？
加藤氏：繰り返しになりますが、最近の言語は関数型を取り入れています。例えばRustなどもそうです。Scalaに慣れていると、Rustでも同様の開発体験が可能になります。
Goもそうですが、継承や例外に依存しない言語機能が実装されている言語にも容易に馴染むことができます。ただし、この関数型の特性があまり魅力的に感じられない人にとっては、少し抵抗感があるかもしれません。
そのような人には、Javaに近いオブジェクト指向を持つKotlinがお勧めです。Javaも進化していますが、Kotlinは最新の言語仕様を取り入れていて、オブジェクト指向でプログラミングしたい人には非常に魅力的です。私の周りでも、技術顧問としてアドバイスをしている人たちの中には、Kotlinを採用したいと考えている人が多くいます。現在の需要も考えると、サーバーサイドでもKotlinが非常に注目されていると感じます。
久松氏：それを受けて、竹端さんいかがでしょう。
竹端氏：Scalaについては、約10年前に少し触れたことがあります。ScalaはJavaと共存可能で、JavaのJVM仕様を持ちながら、より強力な機能を求める言語として位置づけられているイメージがあります。
10年ほど前は、Scalaは関数型の言語として尖ったイメージがありましたが、最近ではJavaやKotlinでも関数型の概念がどんどん取り入れられ、怖い印象が薄れてきています。
また、KotlinはJavaとより強く紐付いており、共存している印象があります。したがって、Javaを使用している企業やJavaの経験がある人々にとって、よりモダンな言語としてKotlinが適していると感じます。Javaを使いながらも強力な機能を求める人々には、より発展した言語仕様を持つScalaが適していると思います。
久松氏：先ほど加藤さんからも話が出ましたが、関数型言語に抵抗があるからこそKotlinを選択するという組織は見られますか？
竹端氏：私が見た限りでは、そういった組織はあまり見かけません。それについて言えば、関数型言語は現在、昔よりカジュアルな感じがあると思います。もしそこを突き詰めてこだわりたいという方がいれば、その場合には本当に関数型言語を選択するのかもしれません。
Googleトレンドを見るとKotlin登場以来Scalaの検索ボリュームが減少トレンドのようですが何か思うところはありますか
加藤:実際、JetBrainsのマーケティングの優れている部分は否定できません。しかし、一番大きな影響を与えたのは、GoogleがAndroidの公式言語としてKotlinを採用したことだと思います。
それでも、Scalaが関数型の良さを理解し、その魅力を他の言語に伝えるという意味では、JavaやKotlinに多大な影響を与えました。
Scalaが先駆者として開拓してきた道を、Kotlinや他の言語が上手く利用している部分もあります。特に、現在のJavaの言語仕様は、Scalaの影響を大いに受けていると思います。ScalaからKotlinに輸入された機能などもあるため、言語間で影響を受け合いながら発展している部分が見受けられます。
Scalaがその強力な関数型言語の特性から独占的に市場を占めるとは思っていません。他の言語がScalaの特性を取り入れるほど、Scalaの相対的な魅力は減ってしまいます。そのため、メジャーな言語としてずっと活躍し続けるのは難しいでしょう。
Javaと比較すると、Scalaのコミュニティは小さいかもしれません。しかし、影響を与える度合いにおいては、非常に大きな存在だと思います。Javaだけでなく、他の言語にも影響を与えているからです。関数型言語コミュニティからすると、Scalaは非常に魅力的な存在で、関数型言語の中で花形などと言われることもあります。
KotlinにもScalaの一部が見受けられ、その部分が評価されることにより、Kotlinが台頭してきたことで、Scalaの需要が相対的に減る可能性もあります。しかし、それを受け入れ、前向きに考えています。
竹端氏：確かに、Kotlinは後発の言語として登場したという大前提があります。Javaは長い歴史を持つ一方で、新しい言語であるScalaも生まれてきました。それぞれが登場するたびに、良い面や悪い面が存在していたと思います。
それを踏まえた上で、Javaではいくつかの部分が足りないと思われたり、Scalaだけでは難易度が高いと感じる部分などを、Kotlinは上手く取り入れていると思います。
Kotlinは、Javaに寄り添う形で、Javaと共存するような位置づけで出てきた感じがあります。これは、Kotlinが先行する言語の良い面を取り入れ、後発の言語として出てきた利点も活かしているからかもしれません。
現在、Android開発の推奨言語になったり、サーバーサイドではスプリングのサポートがあるなど、言語自体の外部からKotlinが盛り上がっている面もあります。このような要素が影響している可能性もあると思います。
Javaと比べると新しいパラダイムは導入されている言語ですが最近のJavaの進化をどう見ていますか
久松氏：皆さんから見たJavaの進化についてお伺いしたいと思いますが、加藤さんはいかがですか？
加藤氏：Javaの進化は驚くほど速くなっています。バージョン6や7の頃と比べて、改善や進化がとても早いですね。Scalaに存在していた機能 -例えばシールドインターフェースやレコード型などのScalaの初期機能 -の要素はどんどんJavaに取り込まれています。
最近のJavaを見ると、Scalaにかなり近い感じがすると言われることもあります。一部の人々は「JavaがいずれScalaのようになる」と言っていますが、それは少々無理があるかもしれません。ただ、そのくらいJavaの進化は目を見張るものがあります。
一方で、このJavaの進化はScalaにもプラスになっています。例えば、バイトコードが小さくなったり、JVM上の機能を用いて新しいことができるようになったりといった好影響があります。これが相乗効果を生み出し、より良い結果をもたらしていくと思います。これはKotlinにも影響を及ぼすでしょう。
JVMのインフラに乗る、つまり「巨人の肩に乗る」ような利点があると思います。
久松氏：ありがとうございます。竹端さんいかがでしょう。
竹端氏：Kotlinから見ても、JavaにもKotlinと近い機能が多く出てきているという印象があります。具体的には、シールドインターフェースのような分かりやすい例が挙げられます。また、Javaにレコードクラスという機能が追加されました。これはKotlinではデータクラスと呼ばれている機能にあたるものです。
また、その後KotlinでもJavaのレコードクラスをKotlinのデータクラスの扱いで呼べるような仕様が追加されました。このように、Javaの仕様をKotlinが追随している面もあります。
さらに、Javaの開発ペースが速くなっていることを強く感じています。6から7に上がった時などはかなり時間がかかりましたが、Javaのバージョン9以降は半年ごとにバージョンアップが行われています。
以前はじっくり作って出来上がったものをリリースする感じでしたが、現在は半年というスパンでリリース可能なものをどんどん出しています。これらから、Javaの開発ペースが大幅に早くなっていることがわかります。
だからといって、KotlinやScalaを使わずにJavaを使えば十分とは必ずしも言えません。しかし、Javaも魅力的でモダンな機能が増え続けており、その進化を見守るのはとても興味深いです。
最近はGoが注目されることが多くなりましたが、その点について何か考えはありますか？
竹端氏：そうですね、Kotlinとは指向が真逆で、最近流行っている言語の中でも少し異質な部分があると思います。例えば、クラスなどオブジェクト指向の概念が存在しないという点などです。それにより、他の言語と並べて考えるのが難しいところがあります。
また、Kotlinは機能が非常に多く、書き方も多様です。そのため好きなように書けるという自由度の高い思想の言語です。そして、Kotlinらしい特定の書き方に固執する必要はないという思想の言語でもあります。
それに対して、Goは逆に機能を最低限に絞り込むことで、書き方が統一され、迷うことなく書けるように工夫されています。その考え方はKotlinとは真逆で、好みが分かれるポイントでもあります。
ただ、Goのパフォーマンスや、軽量でシンプルな言語である点、そしてエコシステムもシンプルであるという点は魅力です。特に、Goは公式が自前で用意しているツールを基本的に使うため、初心者が詰まることなく、始めやすいと感じています。
加藤氏：竹端さんが指摘されたように、Goの言語仕様は異質ですね。その魅力としては、ランタイムの性能が挙げられます。最近では、マイクロサービスを始める際に最初に選ばれる言語となっており、ランタイムが小さいという点が魅力となっています。Javaと比べると圧倒的に小さいため、プロセスの停止や起動が頻繁に行われるマイクロサービスや、クラウドネイティブなサービスを考えたときには、相性が良いです。
JVMは何度も再起動するとJITのプロファイリングが無駄になることが多いので、GoやRustは機動停止が頻繁に起こるような場所には適しています。
最近、GraalVMというソリューションが登場し、その商用機能が無償版でも使用可能になるという話題がニュースで取り上げられていました。このGraalVMは日々改良され続けています。AWS LambdaやGoogle Cloud Functionsのようなサービスでは、機動停止が頻繁に発生してしまいますが、GraalVMを使うことでそのような利用シーンでもJavaアプリケーションを利用できます。
いずれにしても、選択肢が多くて判断が難しいかもしれませんが、Goが注目されている点はランタイムの使い勝手にあるので、それを踏まえた上で言語選定をする必要があると考えています。
これから学ぶ開発者へのアドバイスを一言お願いします!
竹端さん：Kotlinは国内でも採用事例が増えてきているため、QiitaやZenなどで情報が増えてきています。そういった場所を探しながら進むと、ある程度は学ぶことができると思います。
また、これはScalaと共有する点ですが、Kotlinの学習ではJavaの知識が使えます。このことにより、「Javaを覚えなければKotlinができないのか？」と思う人もいるかもしれません。しかし、そんなことはありません。むしろ、Kotlinの情報がなくてもJavaの情報があれば、それを利用することができます。例えば、Kotlinでやりたいことを実現するための情報がなくても、JavaのコードがあればIntelliJに持ってきて貼り付けて、それをKotlinに変換することができます。これにより、動作するものを作ることができます。
Javaの歴史は30年近くになるため、その情報量も大きいです。それと新しいKotlinの情報を組み合わせると、情報を集めることが比較的容易になります。そのため新しい言語としては、比較的情報が集めやすいと思うので、上手く活用すれば効率よく学習できます。
加藤氏：私はKotlinについてもそう思いますが、Scalaも昔に比べて書籍が増え、インターネット上の情報もかなり充実してきています。このような状況なので、実習等で学びたい人にとっては十分な情報があると思います。
しかし、仕事の中でScalaを採用しようと思うと、そのチームにScalaをリードできる人がいないと、採用は難しいかもしれません。そのため、Scalaに精通した人と交流し、ノウハウを学びつつ自分で実際に試すことが、最良の学習方法ではないかと思います。
私がScalaを採用する主な理由は、アクターモデルフレームワークのAkkaを使用するためです。Akkaは、分散システムや高い耐障害性を必要とするサービスの実現に役立つフレームワークで、DDD（ドメイン駆動設計）を前提に作られています。
この特性から、設計のスキルや知識を向上させたい人に合うと思います。また、分散システムや関数型プログラミング、アクタープログラミング等に挑戦したい人にも、ScalaとAkkaは適していると思います。
ただし、Scalaを使いこなしている経験者と出会うのは難しいかもしれません。そういった方は、私に連絡していただければ、交流を通じてさまざまな情報を提供できると思います。
質疑応答
質問「Webバックエンド開発におけるScalaやKotlinのコンパイラやエコシステムで、あったらいい機能や伸ばして欲しい側面はありますか？」
竹端氏：私がよく感じるのは、パッケージマネージャーですね。依存環境の管理などは基本的にGradleを使用するのですが、GoやNodeのnpmなどを使用すると、楽だなと感じます。Gradleはビルドスクリプトを書き、その中で依存環境の定義をする形になるので、初学者の方々はここにはまることが多いです。これはAndroidを含めてよくある話ですね。
新しい良いツールが出てきたり、Kotlinの純正で何か良いものがあると嬉しいなと思います。
加藤氏：私はあまり困ってはいないのですが…。最近よく触っているRustのコンパイラのエラーメッセージは非常に丁寧で、エラーへの対処法も提案してくれます。具体的にどのコードを直せば良いか、コード例まで示してくれるんですね。Scalaも同じように、このようなコンパイラのサポートが取り入れられると、みんなが幸せになるのではないかと思います。
最近ではChatGPTに質問して、色々なサポートを受ける時代になっています。どちらも充実するといいなと思います。
久松氏：それとは別に、加藤さんがRustに注目しているとのコメントがチャットで見受けられますが、Rustは将来性があると思われますか？
加藤氏：Rustの将来性については、皆さんもニュースでご存じかと思いますが、Linuxカーネルの開発言語として採用されていること、GoogleやAWSなどからも大きな投資が行われていることなどから、非常に明るいと思います。また、Stack Overflowの調査でも、5年連続で愛されている言語の上位に位置しています。現在、Rustの開発者の中には非常に熱狂的な人々も多く、その熱気は異常なほどです。
Rustは、JVMでカバーできないような用途、例えばAWS Lambdaなどでよく使用されます。また、CQRSのリード（クエリ）側では、そこまで複雑なアクターを使用しなくても問題ないので、Rustを使用することが多いです。RustかGoのどちらを使用するかという選択をよくします。
言語を複数持つことは大変ですが、Chatworkは目的に応じて言語を切り替えることが多いので、そのような使い方をしています。
質問「ScalaとKotlinに関する質問です。これまでに、高い対障害性を備えたAkkaについてのScalaの話をしてきましたが、他にどのようなシステムを構築する際に、ScalaやKotlinの強みが発揮されやすいのでしょうか。それぞれの言語で使用するフレームワークについても教えていただけると幸いです」
加藤氏：
「品質向上の観点から見ると、関数型プログラミングの文化でよく取り上げられる事例の一つが、プロパティベースドテスティングです。通常のテストでは、固定値を関数の入力にして試しますが、プロパティベースドテスティングでは、特定のプロパティを持つデータを関数に入力します。例えば、「要素が一つ以上で自然数が入っている」というプロパティを関数型で記述すると、プロパティベースドテスティングのツールがそのプロパティに基づくデータを生成してテストしてくれます。
この機能は、HaskellだとQuickCheckと言われるライブラリになります。多くのプログラミング言語でも実装されていますが、元々は関数型のカルチャーでできたものです。
また、パーサーコンビネーターという機能を使うと、構文解析や言語処理系の設計、インタープリタの実装などが関数型のモナドを使った簡潔で凝縮されたコードで可能になります。このように、関数型プログラミングの機能を利用すると、コードの量を大幅に減らし、一つ一つのコードが持つ意味を高めることができます。そういった観点に興味があれば、関数型の機能を利用するのは面白いと思います。
竹端氏：
実はKotlinは革新的な機能や特定のドメインに特化した強力なライブラリなどは特にありません。Javaに近い用途が多いと言えます。Kotlinの特徴としては、オブジェクト指向の機能をしっかりと持ちつつ、それらを洗練された形で実装している点です。特に、金融系の企業などでよく導入を検討されますが、静的な言語でかつ、オブジェクト指向の言語でしっかりと設計したい、さらにモダンな形で実装したいというときに、ハードルが低くてちょうど良い言語だと思います。
また、Kotlin Multiplatformという機能があり、iOSやLinux、Android、JVM、JavaScriptなど、さまざまなプラットフォームでKotlinのコードを共有することができます。これは、特にクライアントサイドで同じような画面を異なるプラットフォームに実装する際に有用です。また、サーバーサイドもKotlinで実装されていれば、サーバーサイドとすべてのクライアント間でロジックを共有することも可能です。
サーバーとクライアントで言語を統一せずにロジックを共有できることは、他にはない魅力です。この機能に興味がある方は、ぜひ公式ドキュメントなどで調べてみることをお勧めします。
ScalaとKotlinは、近年開発者にとって人気の高い言語です。
Kotlinは「Better Java」と呼ばれることがあるようにJavaの長所を保ちつつ、よりシンプルで現代的な特性を提供しています。一方Scalaは、Javaとは異なるアプローチを持ち、関数型プログラミングとオブジェクト指向プログラミングの統合を特徴としています。どちらも、豊富な機能と拡張性により、開発者の間で高い需要が予想されています。
本イベントでは、ScalaとKotlinの専門家であるお二人から両言語の利点と適用範囲、それぞれの哲学や特色を深く掘り下げ、実務的な視点から解説します。また、進化を遂げるJavaについてもお二人がどう捉えているかにも言及していきます。
登壇者の紹介
久松氏：本日はモデレーターを務めさせていただきます久松と申します。現在、Offersでは『デジタル人材総研』の所長を担当しております。
我々の領域ではデジタル人材の流動性についてよく言及されますが、デジタル人材がどのようにキャリア選択を行っているのかなど、デジタル人をテーマに、月1程度に何かしらのリリースを行っています。本日はよろしくお願いいたします。
今日の役割として、登壇者の皆様のお話を掘り下げることになります。それでは、まず登壇者の自己紹介から始めていただければと思います。最初に加藤様、よろしくお願いします。
加藤氏：はい、加藤潤一と申します。現在はChatworkのテックリードを務めています。10歳からプログラミングを始め、SIerでさまざまな現場での経験を積んだ後、Web領域に転身しました。直近では大手ソーシャルゲームの会社などで、Scalaやドメイン駆動設計を採用したシステム開発を行ってきました。直近では2014年の7月からChatworkに在籍していまして、技術的な負債の返済や次期アーキテクチャのプランニング・設計・開発などを手がけています。今日はよろしくお願いします。
久松氏：ありがとうございます、次に竹端様、よろしくお願いします。
竹端氏：はい、竹端と申します。現在はフリーランスのエンジニアとして活動しています。以前はSIerなどでいくつかの仕事を経験した後、サイバーエージェントグループでゲームの開発を10年ほど行っていました。主にソーシャルゲームの運用や新規開発、マネジメントなどを行い、その中でKotlinでのサーバーサイドの新規開発に参加しました。
その経験からKotlinに関するブログの執筆や登壇などの情報発信を行い、サーバーサイドKotlinに関する書籍も出版しました。2020年からはフリーランスとして、サーバーサイドKotlinの技術顧問の仕事や、他の言語での開発やフロントエンド、インフラなどの業務にも取り組んでいます。本日はよろしくお願いします。
久松氏：竹端様、ありがとうございます。それでは早速、ディスカッションに移りたいと思います。まずは、お二人からそれぞれのご意見をお聞きしたいと思います。
ディスカッション
言語を選定した理由 魅力を感じた点について
久松氏：まずは、お2人がそれぞれの言語を選定した理由や魅力に感じた点を教えてください。加藤さんはScala、竹端さんはKotlinのどういった点に魅力を感じたのでしょうか？
加藤氏：私は元々Javaの開発を多くやっていました。さまざまなフレームワークやライブラリを試す中で、ビジネスロジックを効率的に書くためには、どういったことが必要かを常に考えていました。その結果としてScalaに辿り着きました。それが2009年頃のことです。
Scalaの魅力は、プログラミング言語としての表現力の高さです。これまでにない選択肢が増えたことで、開発における設計の幅が広がりました。
久松氏：それでは、竹端さんはいかがですか？
竹端氏：私がサーバーサイドKotlinを始めたのは2017年のことです。元々Javaを長く使っていました。しかし、新しい言語に挑戦したいという話が社内であり、また、自身も新たな選択肢を模索していました。その中で候補に挙がったのがKotlinです。
その頃は主にAndroidの開発で使われているイメージが強かったのですが、GoogleI/OでAndroidの公式開発言語になるという発表があったことでKotlin自体が盛り上がっていたこと、またJavaで有名なSpring FrameworkがKotlinのサポートを始めるという発表もあったため、Kotlinに注目しました。
新しい言語でプロダクトを作ることは大きな決断ですが、過去の資産を活用しながらモダンな形で書けるようになり、Javaのフレームワークやエコシステムがサポートしてくれるという安心感もあり、Kotlinを選択しました。
久松氏：やっぱりKotlinを使っている方々は、元々Javaを使っていた人が多いのでしょうか？
竹端氏：Javaの経験を持つ人が多い可能性はあります。ただ、それが直近の経験であるかはわからないですね。また、以前はJavaを用いて使って開発したいと思ったようなシステムでも、現在ではJavaではなくKotlinを使う選択肢も存在します。
例えば、Javaが適しているけれども、新しい言語で開発したいという場合に、その中間をとってKotlinで開発するというパターンもあるのかなと思います。
久松氏：ありがとうございます。ぜひScalaについても同じ質問をさせていただければと思いますが、いかがでしょうか？
加藤氏：元々Javaを使っていた人はもちろんいますが、TypeScriptやOCaml、Haskellを使っている人も多くいます。ScalaはJavaから見るとかなり遠い言語で、Kotlinの方がJavaに近いと思います。しかしScalaは関数型に強く傾いており、Javaのフレームワークはそのままでは使いにくいという特性があります。
それゆえに、Scalaでは独自のエコシステムが存在し、SpringではなくAkkaやPlayFrameworkを用いる方が自然であると思います。つまり、Scalaは関数型言語文化圏に近いと言えます。Scalaを使っている人たちは、そのような特性を好む傾向にあるようです。
学ぶ上でハードルは何でしたか？それをどのように克服しましたか？
竹端氏：それでは、私の経験に基づいてお話しします。Javaの経験があるかないかで、Kotlinの学習に影響があるかもしれません。先ほど触れたフレームワークやエコシステムの利用といった要素が関わってきます。
新たに何かを作るときに、その言語自体の知識だけでいうと、それは全体のうち2割程度だと思います。残りはエコシステムやプラットフォーム、クライアントの仕組みといった要素を学ぶ必要があります。
Javaの経験があればそのエコシステムなどの知識は再利用できる可能性があるため、その場合は学習ハードルが低くなるかもしれません。Java7より古いバージョンを使っていたら別ですが、Java8以降、つまりストリームAPIが導入されて関数型の考え方が入ってから学び始めた方々にとっては、Kotlinの学習は比較的容易になると思います。
ただし、それはフレームワークやエコシステムなどが同じ環境、同じ技術セットで学習する場合の話です。それがない場合、他の言語と同じぐらいの学習コストが必要になるのではないでしょうか。とはいえ、他の言語に比べてそれほどハードルが高いとは思いません。どちらかと言えば、Javaを知っていれば学習をショートカットできるようなイメージです。
久松氏：Kotlinを学ぶためだけに、わざわざJavaを学習する必要はないということですね。
竹端氏：そうですね。もしJavaのライブラリやフレームワークを使用するなら、JavaのフレームワークやJVMの知識が必要になります。
しかし、それはJavaの知識というよりはフレームワークの知識やJVM自体の知識ですので、Kotlinを学ぶ過程で自然と勉強することになるでしょう。
久松氏：ありがとうございます。加藤さんはいかがでしょうか。
加藤氏：最近のプログラミング言語は関数型の機能を取り込んでおり、後発のオブジェクト指向言語にその要素がないものはほとんどありません。たとえば、最新の言語であるKotlinやSwiftもそうです。関数型のカルチャーは、かなり浸透してきています。そのため、学習に対するハードルは決して高くないと思います。
しかし、命令型のプログラミングに慣れている人にとっては、関数型の特徴であるmapやfoldのような関数をいきなり使うのはハードルが高いかもしれません。
このハードルを乗り越える方法としては、ScalaやKotlinのような言語でも、命令型の記述を維持しつつ、徐々に関数型の完成形に慣れていくのが一番良いと思います。
自分が以前に経験した難点は、Scalaではコレクションを関数型で書かなければならないという点でした。コレクションのAPIが基本的に関数型でしか書けないので、できないと仕事に支障を来たします。この点ではKotlinとは少し違うかもしれません。
スキルテストで見る観点
久松氏：関数型言語のScalaやKotlinのエンジニアを採用する際、スキルテストでどのような観点を重視しますか？
加藤氏：Scalaをすぐに書けるかどうかよりも、アルゴリズムや処理手順を日本語で適切に説明できることが前提です。そういった説明ができる人であれば、ScalaやKotlinなどに対応することはそこまで難しくないと思います。
もちろん、関数型言語で副作用のないロジックを書く能力には経験が必要になりますが、それは採用するポジションによるでしょう。シニアなのか、ジュニアなのか、それぞれの立場で重視する要素は変わってきます。
ジュニアであればこれからの成長の可能性を重視し、シニアであればこれまでどのような経験をしてきたかを知るため、そのポートフォリオを重視します。ですので、一概にスキルテストだけで測ることは難しいとも思います。
久松氏：ありがとうございます。竹端さんはいかがでしょうか。
竹端氏：採用要件を決める時、特定の言語の経験を重視することはあまりありません。Kotlinのみに限定すると、採用が厳しくなるのも一因です。
オブジェクト指向言語には触れてて欲しいな、くらいは考えます。ですがより重視するのは、その言語を用いて何を作り出してきたか、どういう設計を考えてきたかという部分です。
ただ、プロジェクトの状況によって今すぐにバリバリコードを書ける人が必要な場合は、Kotlinの経験がある人やJavaでSpringFrameworkを使ったことのある人を探す必要もあると思います。
経験がない場合は、新しいプロジェクトに入った時には言語以外も含めさまざまな学習が必要になるので、その一環としてしっかりとキャッチアップできる人かどうかは確認します。
最も印象に残るプロジェクトや経験はどんなものでしょうか
久松氏：お二人にとって、最も印象に残るプロジェクトや経験は何でしょうか。
竹端氏：初めてKotlinを導入した時のプロジェクトが非常に印象に残っています。当時、私が所属していた会社では、新しいプロダクトを作る際にテンプレートとなるJavaのプロジェクトがあり、様々な機能が既に組み込まれていました。そのテンプレートのプロジェクトを全てKotlinに置き換え、新しいプロジェクトを作成するための新たな基盤を構築したのです。
そのコードは非常に多く、IntelliJの機能を使って一気にKotlinに変換したのですが、多くのコンパイルエラーが発生しました。それらを1つずつ解消しながら、併せてKotlinの特性に合わせてコードを書き換えました。
その新たな基盤を使って新しいプロジェクトを開始し、結果として1つのプロジェクトをKotlinで0からしっかりと作り上げることができたことは大きな成果でした。
しかし、振り返ると当時のコードには改善の余地が多く見受けられます。特にKotlinの特性を十分に活かせていなかったという点については、少々後悔しています。
久松氏：差し支えなければで構いません。その後悔ポイントとはどのようなものでしょうか。
竹端氏：Java的な書き方が一部残ってしまったかな、と感じる部分はありました。その理由としては、一部のコードがJavaと共存していたためです。例えば、O/Rマッパー周辺の部分では、データベースのテーブルに紐付いたデータ保持のためのクラスが、元々はJavaのO/Rマッパーの機能によって自動生成されていました。しかしこれはJavaでしか生成できず、結果としてそのままJavaの形式で使用していた部分がありました。
それが最近では同じフレームワークでもKotlinで生成できるようになりました。それに伴い、そのフレームワークを呼び出す際の書き方も変わりました。
久松氏：ありがとうございます。加藤さんはいかがでしょうか。
加藤氏：2014年ごろからChatworkのPHPの技術的負債を返済するようなプロジェクトを立ち上げました。当初は紆余曲折がありましたが、2016年末にメッセージのデータを扱う部分をScalaで置き換えました。
当時、メッセージの総数は約10億件ほどあり、これをAkka、データベースはKafkaとエッジベースを使った分散システムに移行しました。この経験を通じて、障害に強いシステムを作り上げるというAkkaの特徴を身につけました。
例えば、データベースのネットワーク障害が起きたときでも、そのネットワーク障害が回復すると自動的に残りのタスクが再開できるといった回復力がAkkaには備わっています。このような高い対障害性を持つシステムを比較的簡単に作ることができました。
もちろん、分散システムの知識は必要ですが、それを使ってサービス運用が安定し、夜中に起こされることもなくなりました。
また、Chatworkでは基本的にAkkaを使うという方針を持っており、システム自体が障害発生時に自動的に復元するように設計しています。このように、全体の障害につながることのないようなシステム設計を心掛けています。
これは、ScalaやAkkaの文化圏では一般的な考え方で、この考え方は関数型や障害に強い設計の考え方をCQRSやイベントソーシングをうまく使って進めてきた経験は大きな学びとなりました。
ScalaからKotlinを、KotlinからScalaを見てどういう印象を持ちますか？
加藤氏：繰り返しになりますが、最近の言語は関数型を取り入れています。例えばRustなどもそうです。Scalaに慣れていると、Rustでも同様の開発体験が可能になります。
Goもそうですが、継承や例外に依存しない言語機能が実装されている言語にも容易に馴染むことができます。ただし、この関数型の特性があまり魅力的に感じられない人にとっては、少し抵抗感があるかもしれません。
そのような人には、Javaに近いオブジェクト指向を持つKotlinがお勧めです。Javaも進化していますが、Kotlinは最新の言語仕様を取り入れていて、オブジェクト指向でプログラミングしたい人には非常に魅力的です。私の周りでも、技術顧問としてアドバイスをしている人たちの中には、Kotlinを採用したいと考えている人が多くいます。現在の需要も考えると、サーバーサイドでもKotlinが非常に注目されていると感じます。
久松氏：それを受けて、竹端さんいかがでしょう。
竹端氏：Scalaについては、約10年前に少し触れたことがあります。ScalaはJavaと共存可能で、JavaのJVM仕様を持ちながら、より強力な機能を求める言語として位置づけられているイメージがあります。
10年ほど前は、Scalaは関数型の言語として尖ったイメージがありましたが、最近ではJavaやKotlinでも関数型の概念がどんどん取り入れられ、怖い印象が薄れてきています。
また、KotlinはJavaとより強く紐付いており、共存している印象があります。したがって、Javaを使用している企業やJavaの経験がある人々にとって、よりモダンな言語としてKotlinが適していると感じます。Javaを使いながらも強力な機能を求める人々には、より発展した言語仕様を持つScalaが適していると思います。
久松氏：先ほど加藤さんからも話が出ましたが、関数型言語に抵抗があるからこそKotlinを選択するという組織は見られますか？
竹端氏：私が見た限りでは、そういった組織はあまり見かけません。それについて言えば、関数型言語は現在、昔よりカジュアルな感じがあると思います。もしそこを突き詰めてこだわりたいという方がいれば、その場合には本当に関数型言語を選択するのかもしれません。
Googleトレンドを見るとKotlin登場以来Scalaの検索ボリュームが減少トレンドのようですが何か思うところはありますか
加藤:実際、JetBrainsのマーケティングの優れている部分は否定できません。しかし、一番大きな影響を与えたのは、GoogleがAndroidの公式言語としてKotlinを採用したことだと思います。
それでも、Scalaが関数型の良さを理解し、その魅力を他の言語に伝えるという意味では、JavaやKotlinに多大な影響を与えました。
Scalaが先駆者として開拓してきた道を、Kotlinや他の言語が上手く利用している部分もあります。特に、現在のJavaの言語仕様は、Scalaの影響を大いに受けていると思います。ScalaからKotlinに輸入された機能などもあるため、言語間で影響を受け合いながら発展している部分が見受けられます。
Scalaがその強力な関数型言語の特性から独占的に市場を占めるとは思っていません。他の言語がScalaの特性を取り入れるほど、Scalaの相対的な魅力は減ってしまいます。そのため、メジャーな言語としてずっと活躍し続けるのは難しいでしょう。
Javaと比較すると、Scalaのコミュニティは小さいかもしれません。しかし、影響を与える度合いにおいては、非常に大きな存在だと思います。Javaだけでなく、他の言語にも影響を与えているからです。関数型言語コミュニティからすると、Scalaは非常に魅力的な存在で、関数型言語の中で花形などと言われることもあります。
KotlinにもScalaの一部が見受けられ、その部分が評価されることにより、Kotlinが台頭してきたことで、Scalaの需要が相対的に減る可能性もあります。しかし、それを受け入れ、前向きに考えています。
竹端氏：確かに、Kotlinは後発の言語として登場したという大前提があります。Javaは長い歴史を持つ一方で、新しい言語であるScalaも生まれてきました。それぞれが登場するたびに、良い面や悪い面が存在していたと思います。
それを踏まえた上で、Javaではいくつかの部分が足りないと思われたり、Scalaだけでは難易度が高いと感じる部分などを、Kotlinは上手く取り入れていると思います。
Kotlinは、Javaに寄り添う形で、Javaと共存するような位置づけで出てきた感じがあります。これは、Kotlinが先行する言語の良い面を取り入れ、後発の言語として出てきた利点も活かしているからかもしれません。
現在、Android開発の推奨言語になったり、サーバーサイドではスプリングのサポートがあるなど、言語自体の外部からKotlinが盛り上がっている面もあります。このような要素が影響している可能性もあると思います。
Javaと比べると新しいパラダイムは導入されている言語ですが最近のJavaの進化をどう見ていますか
久松氏：皆さんから見たJavaの進化についてお伺いしたいと思いますが、加藤さんはいかがですか？
加藤氏：Javaの進化は驚くほど速くなっています。バージョン6や7の頃と比べて、改善や進化がとても早いですね。Scalaに存在していた機能 -例えばシールドインターフェースやレコード型などのScalaの初期機能 -の要素はどんどんJavaに取り込まれています。
最近のJavaを見ると、Scalaにかなり近い感じがすると言われることもあります。一部の人々は「JavaがいずれScalaのようになる」と言っていますが、それは少々無理があるかもしれません。ただ、そのくらいJavaの進化は目を見張るものがあります。
一方で、このJavaの進化はScalaにもプラスになっています。例えば、バイトコードが小さくなったり、JVM上の機能を用いて新しいことができるようになったりといった好影響があります。これが相乗効果を生み出し、より良い結果をもたらしていくと思います。これはKotlinにも影響を及ぼすでしょう。
JVMのインフラに乗る、つまり「巨人の肩に乗る」ような利点があると思います。
久松氏：ありがとうございます。竹端さんいかがでしょう。
竹端氏：Kotlinから見ても、JavaにもKotlinと近い機能が多く出てきているという印象があります。具体的には、シールドインターフェースのような分かりやすい例が挙げられます。また、Javaにレコードクラスという機能が追加されました。これはKotlinではデータクラスと呼ばれている機能にあたるものです。
また、その後KotlinでもJavaのレコードクラスをKotlinのデータクラスの扱いで呼べるような仕様が追加されました。このように、Javaの仕様をKotlinが追随している面もあります。
さらに、Javaの開発ペースが速くなっていることを強く感じています。6から7に上がった時などはかなり時間がかかりましたが、Javaのバージョン9以降は半年ごとにバージョンアップが行われています。
以前はじっくり作って出来上がったものをリリースする感じでしたが、現在は半年というスパンでリリース可能なものをどんどん出しています。これらから、Javaの開発ペースが大幅に早くなっていることがわかります。
だからといって、KotlinやScalaを使わずにJavaを使えば十分とは必ずしも言えません。しかし、Javaも魅力的でモダンな機能が増え続けており、その進化を見守るのはとても興味深いです。
最近はGoが注目されることが多くなりましたが、その点について何か考えはありますか？
竹端氏：そうですね、Kotlinとは指向が真逆で、最近流行っている言語の中でも少し異質な部分があると思います。例えば、クラスなどオブジェクト指向の概念が存在しないという点などです。それにより、他の言語と並べて考えるのが難しいところがあります。
また、Kotlinは機能が非常に多く、書き方も多様です。そのため好きなように書けるという自由度の高い思想の言語です。そして、Kotlinらしい特定の書き方に固執する必要はないという思想の言語でもあります。
それに対して、Goは逆に機能を最低限に絞り込むことで、書き方が統一され、迷うことなく書けるように工夫されています。その考え方はKotlinとは真逆で、好みが分かれるポイントでもあります。
ただ、Goのパフォーマンスや、軽量でシンプルな言語である点、そしてエコシステムもシンプルであるという点は魅力です。特に、Goは公式が自前で用意しているツールを基本的に使うため、初心者が詰まることなく、始めやすいと感じています。
加藤氏：竹端さんが指摘されたように、Goの言語仕様は異質ですね。その魅力としては、ランタイムの性能が挙げられます。最近では、マイクロサービスを始める際に最初に選ばれる言語となっており、ランタイムが小さいという点が魅力となっています。Javaと比べると圧倒的に小さいため、プロセスの停止や起動が頻繁に行われるマイクロサービスや、クラウドネイティブなサービスを考えたときには、相性が良いです。
JVMは何度も再起動するとJITのプロファイリングが無駄になることが多いので、GoやRustは機動停止が頻繁に起こるような場所には適しています。
最近、GraalVMというソリューションが登場し、その商用機能が無償版でも使用可能になるという話題がニュースで取り上げられていました。このGraalVMは日々改良され続けています。AWS LambdaやGoogle Cloud Functionsのようなサービスでは、機動停止が頻繁に発生してしまいますが、GraalVMを使うことでそのような利用シーンでもJavaアプリケーションを利用できます。
いずれにしても、選択肢が多くて判断が難しいかもしれませんが、Goが注目されている点はランタイムの使い勝手にあるので、それを踏まえた上で言語選定をする必要があると考えています。
これから学ぶ開発者へのアドバイスを一言お願いします!
竹端さん：Kotlinは国内でも採用事例が増えてきているため、QiitaやZenなどで情報が増えてきています。そういった場所を探しながら進むと、ある程度は学ぶことができると思います。
また、これはScalaと共有する点ですが、Kotlinの学習ではJavaの知識が使えます。このことにより、「Javaを覚えなければKotlinができないのか？」と思う人もいるかもしれません。しかし、そんなことはありません。むしろ、Kotlinの情報がなくてもJavaの情報があれば、それを利用することができます。例えば、Kotlinでやりたいことを実現するための情報がなくても、JavaのコードがあればIntelliJに持ってきて貼り付けて、それをKotlinに変換することができます。これにより、動作するものを作ることができます。
Javaの歴史は30年近くになるため、その情報量も大きいです。それと新しいKotlinの情報を組み合わせると、情報を集めることが比較的容易になります。そのため新しい言語としては、比較的情報が集めやすいと思うので、上手く活用すれば効率よく学習できます。
加藤氏：私はKotlinについてもそう思いますが、Scalaも昔に比べて書籍が増え、インターネット上の情報もかなり充実してきています。このような状況なので、実習等で学びたい人にとっては十分な情報があると思います。
しかし、仕事の中でScalaを採用しようと思うと、そのチームにScalaをリードできる人がいないと、採用は難しいかもしれません。そのため、Scalaに精通した人と交流し、ノウハウを学びつつ自分で実際に試すことが、最良の学習方法ではないかと思います。
私がScalaを採用する主な理由は、アクターモデルフレームワークのAkkaを使用するためです。Akkaは、分散システムや高い耐障害性を必要とするサービスの実現に役立つフレームワークで、DDD（ドメイン駆動設計）を前提に作られています。
この特性から、設計のスキルや知識を向上させたい人に合うと思います。また、分散システムや関数型プログラミング、アクタープログラミング等に挑戦したい人にも、ScalaとAkkaは適していると思います。
ただし、Scalaを使いこなしている経験者と出会うのは難しいかもしれません。そういった方は、私に連絡していただければ、交流を通じてさまざまな情報を提供できると思います。
質疑応答
質問「Webバックエンド開発におけるScalaやKotlinのコンパイラやエコシステムで、あったらいい機能や伸ばして欲しい側面はありますか？」
竹端氏：私がよく感じるのは、パッケージマネージャーですね。依存環境の管理などは基本的にGradleを使用するのですが、GoやNodeのnpmなどを使用すると、楽だなと感じます。Gradleはビルドスクリプトを書き、その中で依存環境の定義をする形になるので、初学者の方々はここにはまることが多いです。これはAndroidを含めてよくある話ですね。
新しい良いツールが出てきたり、Kotlinの純正で何か良いものがあると嬉しいなと思います。
加藤氏：私はあまり困ってはいないのですが…。最近よく触っているRustのコンパイラのエラーメッセージは非常に丁寧で、エラーへの対処法も提案してくれます。具体的にどのコードを直せば良いか、コード例まで示してくれるんですね。Scalaも同じように、このようなコンパイラのサポートが取り入れられると、みんなが幸せになるのではないかと思います。
最近ではChatGPTに質問して、色々なサポートを受ける時代になっています。どちらも充実するといいなと思います。
久松氏：それとは別に、加藤さんがRustに注目しているとのコメントがチャットで見受けられますが、Rustは将来性があると思われますか？
加藤氏：Rustの将来性については、皆さんもニュースでご存じかと思いますが、Linuxカーネルの開発言語として採用されていること、GoogleやAWSなどからも大きな投資が行われていることなどから、非常に明るいと思います。また、Stack Overflowの調査でも、5年連続で愛されている言語の上位に位置しています。現在、Rustの開発者の中には非常に熱狂的な人々も多く、その熱気は異常なほどです。
Rustは、JVMでカバーできないような用途、例えばAWS Lambdaなどでよく使用されます。また、CQRSのリード（クエリ）側では、そこまで複雑なアクターを使用しなくても問題ないので、Rustを使用することが多いです。RustかGoのどちらを使用するかという選択をよくします。
言語を複数持つことは大変ですが、Chatworkは目的に応じて言語を切り替えることが多いので、そのような使い方をしています。
質問「ScalaとKotlinに関する質問です。これまでに、高い対障害性を備えたAkkaについてのScalaの話をしてきましたが、他にどのようなシステムを構築する際に、ScalaやKotlinの強みが発揮されやすいのでしょうか。それぞれの言語で使用するフレームワークについても教えていただけると幸いです」
加藤氏：
「品質向上の観点から見ると、関数型プログラミングの文化でよく取り上げられる事例の一つが、プロパティベースドテスティングです。通常のテストでは、固定値を関数の入力にして試しますが、プロパティベースドテスティングでは、特定のプロパティを持つデータを関数に入力します。例えば、「要素が一つ以上で自然数が入っている」というプロパティを関数型で記述すると、プロパティベースドテスティングのツールがそのプロパティに基づくデータを生成してテストしてくれます。
この機能は、HaskellだとQuickCheckと言われるライブラリになります。多くのプログラミング言語でも実装されていますが、元々は関数型のカルチャーでできたものです。
また、パーサーコンビネーターという機能を使うと、構文解析や言語処理系の設計、インタープリタの実装などが関数型のモナドを使った簡潔で凝縮されたコードで可能になります。このように、関数型プログラミングの機能を利用すると、コードの量を大幅に減らし、一つ一つのコードが持つ意味を高めることができます。そういった観点に興味があれば、関数型の機能を利用するのは面白いと思います。
竹端氏：
実はKotlinは革新的な機能や特定のドメインに特化した強力なライブラリなどは特にありません。Javaに近い用途が多いと言えます。Kotlinの特徴としては、オブジェクト指向の機能をしっかりと持ちつつ、それらを洗練された形で実装している点です。特に、金融系の企業などでよく導入を検討されますが、静的な言語でかつ、オブジェクト指向の言語でしっかりと設計したい、さらにモダンな形で実装したいというときに、ハードルが低くてちょうど良い言語だと思います。
また、Kotlin Multiplatformという機能があり、iOSやLinux、Android、JVM、JavaScriptなど、さまざまなプラットフォームでKotlinのコードを共有することができます。これは、特にクライアントサイドで同じような画面を異なるプラットフォームに実装する際に有用です。また、サーバーサイドもKotlinで実装されていれば、サーバーサイドとすべてのクライアント間でロジックを共有することも可能です。
サーバーとクライアントで言語を統一せずにロジックを共有できることは、他にはない魅力です。この機能に興味がある方は、ぜひ公式ドキュメントなどで調べてみることをお勧めします。
