KotlinについてのQ&A - PinterestのChristina Lee氏に聞く

InfoQは先日、PinterestのCore UIチームのAndroidエンジニアであるChristina Lee氏と席を共にし、PinterestでのKotlinの採用状況、採用に際してPinterestが直面した組織的課題、最大の教訓、Javaから移行する際のヒント、KotlinConf 2018で予定されている氏の講演 “Representing State: the Kotlin Edition” の内容などについて話を聞いた。

InfoQ: Pinterestでのあなた自身の役割を、特にKotlinの採用促進に関して、簡単に説明してください。

Christina Lee: 私はChristina、PinterestのCore UIチームのエンジニアです。Pinterestには数年前、勤務先の買収に伴って参加しました。その会社では数年間、Kotlinを広範囲に(そして中心的に！)使う自由がありました。ですから、Pinterestで働き始めても、その経験と熱意を自然と新しい仕事に向けるようになったのです。Pinterestに参加して数週間のうちに、当時私が取り組んでいた仕事(Androidのビデオサポート)にKotlinを試用することを許可してもらうことができました。この仕事や、それに関連して行った社内での宣伝活動によって、私たちのAndroidアプリの中でKotlinの使用が広がって、今年最大の成果である、PinterestのAndroid環境でKotlinを最優先する(Kotlin-first)という、新たな方針が生まれたのです。

InfoQ: Kotlin言語のどのような部分が、それほど強く、目に見える形で採用を主張した理由なのでしょうか？

Lee: JVMバイトコードを生成するという意味で、KotlinはJavaから革新的に離れている訳ではありません。しかし、それが功を奏しているのが、Kotlinが本質的には、最高のプログラミングプラクティスをその言語に組み込んだ、Javaの1バージョンであるということです。ですから、間違ったことよりも、正しいことを行う方がずっと多いのです。これによって速度と信頼性に優れたコードを書くことが可能になり、Javaを使用する場合に必要とされていた作業の多くを排除できます。コーディングは文章と同じで、表現力に富んだ芸術様式ですから、自らの思考を明確かつ素早く、正確に表現できるツールがあることは満足のいく状況であり、エキサイティングに感じるだけの価値があります。これに業界をリードするツールと言語の相互運用性、そしてJetBrainsチームが提示する緻密で思想豊かな言語のリーダーシップの組み合わせとなれば、魅力を感じないはずがありません。

InfoQ: Kotlinを採用する中で、Pinterestではどのような組織的課題に直面しましたか？それらをどのように克服したのでしょうか？

Lee:  Kotlinを採用する上で直面した最も大きな課題のひとつは、Kapt(Kotlinのアノテーションプロセッサ)に以前からある問題など、ビルド関係の問題でした。ビルド状態が正しく分離されていないために、ローカルでブランチを切り替える際に頻繁にビルドエラーが発生するだけでなく、CIビルド環境でもエラーが発生する場合があるのです。これらの問題のため、上級エンジニアの一部からは、Kotlinは止めるべきだという意見もありました。このような問題点のいくつかは、新しい言語を採用する上での成長痛のようなもので -- Kapt自体がツールに起因するバグや欠陥を抱えているので -- 社内の誰かが修正できる類いのものではありません。このような問題は、Kaptや関連するビルドツールが改善されたことで解決されましたが、多くの開発者の心の中の、Kotlinはビルドが不安定だという、言語に対する意見に影響しています。

しかしながら、問題のもうひとつの部分は、新しい技術を始めて使って開発するときに必然的に起こる盲点から来るものでした。これらの問題は社内で解決可能な問題でしたから、私たちは教育に集中することで取り組んできました。ひとつの例は、開発者がインポートステートメントを忘れたり、Kotlinとは無関係なエラーを起こすという、コンパイル時に発生するエラーの類いでしたが、KaptがAndroid Studio内に情報を出力する方法のため、ビルド出力からこのエラーを見つけるのが難しかったのです。実際にコンパイル時のエラーを見つける方法を教えることで、このようなエラーを自分でナビゲートするために必要な知識を提供することができました。このタイプの問題を解決するため、Kotlinやビルドに関する質問用にいくつかのSlackチャンネルを用意して、どんな質問でも歓迎し、それに答えるというやり方にしました。Kaptのような新しいコンポーネントがどのように動作するのか、どのようなエラーが通知されるのか、どうやって解決策を探すためにまず何をすればよいのか、といったことは、移行の苦痛を緩和する上で大いに役立ちました。

InfoQ: Kotlinを使うためにAndroidのコードベースを再構築することについて、どうやってチームに納得させたのですか？

Lee:  Pinterestでの私たちのポリシはKotlin優先(Kotlin-first)なのであって、Kotlinのみ(Kotlin-exclusive)ではありません。つまり、Kotlinが社内のAndroid開発における主要言語であり、PinterestのすべてのAndroid開発者がKotlinの読み書き方法を理解する必要があるということと、新たなコードはKotlinで記述しなければならない、ということなのです。ただし、変更の必要がないと思われる既存のJavaファイルについては、事前に変換しないように、特に呼びかけました。この背後には２つの論理があります。ひとつは、“壊れていないものは修正するな”という言葉に集約されます。動作しているものを変更すれば、その変更が既存の動作を損なう可能性があります。ファイルをKotlinに変換する作業に明確なROIや、その他の変更する理由がなければ(ある場合もあります！)、他の変更を実施することで同じようなリスクを想定しなければならない時が来るまで、運用中のコンポーネントはそのままにしておいた方がよいのです。ふたつめは、PinterestコードベースのすべてのファイルをKotlinに書き換えるには多くの時間を要するので、非常に大きな投資になるということです。さまざまな選択肢を考えた時、相当数の開発時間を費やす上で、最も価値のある方法であるとは思えませんでした。

InfoQ: Kotlinの採用を通じて学んだ、最大の教訓は何でしたか？

Lee: よいことではないのですが、私はどちらかというと、反抗的な性格なのです。人に指図されることが嫌いなので、KotlinとJavaのどちらを使うべきかを決める上では、Pinterestの開発者がそれぞれ自分で選ぶべきだと考えていました。Kotlinが優れたJava相互運用性を備えているという技術的観点から言えば、これは十分に可能なことですし、社内の他の人たちも同じ考えだったのですが、それができなかったのは人間性の問題でした。人は不確実性を嫌いますから、API設計やnull許容パターンといった会話がそれぞれのキャンプ(Javaチーム、Kotlinチーム)に頻繁に分かれるようになって、“我々と彼ら”というシナリオに陥ることが多いのです。Kotlinを社内で組織的に広めたことで、最終的には、大部分の開発者が新しい言語を積極的に試し、関心を持たない多くの開発者がオプトアウトするという、ひとつの壁にぶつかりました。

十分な時間があれば、本質的な方向性が最終的にすべての開発者を変えることができたかも知れませんが、ロールアウトのスケジュール上の問題から、チームが分裂した状態が長く続くことになっています。プラットフォームリーダのSha Sha Chuが(他のエンジニアリングリーダの協力の下で)Kotkin-firstという強い言語方針を展開するという決定を下したとき、選択肢が失われることに対してメンバが不満を持つのではないか、という懸念がありました。ですが、プロセスに関して健全な議論が行われた結果として、ポリシが実施された後、チームの結束力と幸福感は大きくジャンプアップしたように思います。この経験からPinterestが得た最大の教訓のひとつは、チームが分裂した状態にある時間を最小限に抑えるためには、調査とロールアウトの段階で明確かつ直接的なガイダンスを提供することが重要だ、ということです。チームとしては、徹底的にテストをして、ひとつの結論(完全に排除するか、完全にコミットするか)に素早く達することの価値を強く認識することができたと思っています。

その他に学んだこととして大きなものは、Kotlin(特に早い段階)によってビルドが不安定になり、そこで発生した問題(おもにCIとKaptに関して)を解決する上で、監視と修正に相当なリソースを割り当てる必要があったことです。これらの問題はどれも克服可能でしたが、 周到な調査を必要としたため、エンジニアの時間的投資がゼロではありませんでした。当初この作業に十分な人員を割り当てていなかったため、初期のビルド障害の調査には必要以上に時間を費やしてしまいました。この分野に専任のリソースをアサインした後は、こうしたビルドの問題に対しても、比較的短時間で適切なサポートができるようになりました。このオンコールエンジニアに対する初期投資には大きな効果があったので、今後のフレームワークのロールアウトでも試してみようと思っています。

InfoQ: JavaからKotlinに移行する上で、何か役に立つヒントはありますか？

Lee:最近では、Kotinを始めるためのコンテンツが(Huyen Tue Daoや私の講演なども含めて)たくさんありますから、どのような学習スタイルでも、Javaからの移行を支援するようなコンテンツを簡単に見つけられると思います。ですが、無料の講演やチュートリアル以外で私がお勧めしたい最高の学習ツールは、IntelliJ IDEファミリです。Javaコードをコピー・アンド・ペーストするだけで、自動的にKotlinに変換する機能が提供されているのです。これを使えば、Javaのコンセプトがどのように新しい言語に変換されるのか、大まかなマッピングを得ることができます。新しい自然言語を学ぼうというときに、Google Translateが言語翻訳の概要を知る上で役に立つのと同じような感覚です。エディタの提案が誤っている場合もありますが、たいていは非常に分かりやすいエラーメッセージが出ますので、StackOverflowで簡単に検索することができます。

もうひとつ重要なのはコードレビューです。ほとんどのプログラミング言語がそうであるように、Kotlinで同じタスクを達成する方法はたくさんあります。社内で言語の運用を始めた頃、私たちはKotlin専用のレビュアを用意して、言語を使い始めた人たちから来るプルリクエストを確認するようにしていました。基礎となるコードが技術的に適切であるかを評価することが目的ではなく、言語がどのように使われているか、ベストプラクティスや推奨スタイルガイドに沿っているか、といったことのみに注目していました。こうしたコードレビューでのやり取りが、組織的な学習の普及につながりました -- レビューを受ける側は提案を受け取り、レビューをする側は質問やコメントをするために、言語について深く考えることを求められました。PRを読んだ他のチームメンバが参照できるように、議論の内容はドキュメント化されています。

InfoQ: KotinConf 2018での講演では、どのような話をしますか？そのトピックを選んだ理由も教えてください。

Lee; 今年のKotlinConの講演では、アプリケーションの不連続な状態を簡単かつ正確に定義する上で、Kotlinの言語機能がいかに有益か、という話をする予定です。私が特に熱意を持っているのは、データ構造の明確な定義についてです。プログラミングの領域なので、コードレビューやアーキテクチャの議論では見過ごされがちなのですが、それが原因で生じる未処理問題やバグの数は可は計り知れません。クリーンな部屋を清潔に保つのが簡単であるように、プロジェクトの初期に論理的なデータ構造の確立や維持に時間を費やすことは、コードがさまざまな使用フェーズに移行する際に、適切な作業を行なうことが簡単にできるようになります。これは開発者にとって開発速度上の勝利であり、ユーザにとっては安定性における勝利です。

InfoQ: 今日は私たちのために時間を頂いて、ありがとうございました。他に何か，InfoQ読者に伝えておきたいことがありますか？

Lee: Kotlinに関して最も印象的なことのひとつは、この言語を採用して徹底的に利用するというアプローチを実行して、それを後悔したという開発者を知らない、ということです。Swiftに関する個人的な経験では、言語としては概ね人々の気に入られていたものの、ビルド時間や相互運用性や言語バージョンのマイグレーション問題といった理由から、移行に難色を示す人たちが多かったのです。私の経験から言うと、Kotlinに対する声高な批判の大部分は、実際には使っていない人からのものであって、広く使用している人たちからのものはほとんどありません。言語の採用に関して何ヶ月も議論を続けてきた人が、言語を転換した数週間後に私のデスクに来て、KotlinのおかげでAndroid用の開発にもう一度愛情を持てるようになった、と語ってくれたこともありました。別の開発者は、最初は言語の採用を嫌っていたのですが、現在ではレガシファイルのメンテナンスでJavaに戻らなければならないことに不満を言っています。最も乗り気でない開発者でさえ魅了するこの能力は、言語そのもの、それを取り巻くツール、その使用を推進するチームの存在を示す何よりの証拠なのです。

PintetestでのKotlinに関する情報は、Pinterestのエンジニアリングブログで詳しく紹介されている。InfoQ Javaホームページにアクセスすれば，Java関連の最新ニュースを確認することも可能だ。