移行作業は？人材育成はどうする？ TypeScriptを導入して分かったリアルなメリットと課題とは

TypeScriptを組織として推進するヤフー、Sansan「Eight」はTypeScript率100％を達成

2022/12/16 12:00

　フロントエンド領域の開発言語としてデファクトスタンダードになりつつある「TypeScript」。サービス開発において、標準のJavaScriptが抱える問題の解決を念頭に、導入を検討している現場も多いのではないでしょうか。しかし「導入はどう進めればいいのか」「移行のメリットが対応コストに見合うのか」「エンジニアはどうすれば育成できるのか」といった懸念から、本格的な導入に踏み切れていないケースもあるようです。今回は、ヤフーとSansanで、開発現場へのTypeScript導入を主導してきた二人のエンジニアに、導入して分かったメリットや注意点、社内での普及に向けた取り組みなどをお話しいただきました。

──最初に、お二人のプロフィールと、主にTypeScriptに関連して社内で取り組んでいることについて、ご紹介ください。

狩野和博氏（以下、狩野）：ヤフーの狩野です。CTO室の「SWAT」に所属しています。また、兼務として、特定の開発言語に関連した支援を行う「言語サポートチーム」で、今回のテーマであるTypeScriptの普及活動を行っています。よろしくお願いします。

鳥山らいか氏（以下、鳥山）：Sansanの鳥山です。2019年4月に新卒で入社し、個人向けサービスであるキャリアプロフィール「Eight」の開発組織に所属しています。Eight内には個人向けの他にも、付随する複数の企業向けサービスが存在するのですが、それらを横断してWebフロントエンドの開発をサポートしています。加えて、技術負債やデザイン負債の解消、ビルド回りの改善など、開発者体験を向上する取り組みについては「何でもやる」といった感じです。その一環で、TypeScriptの導入やデザインシステムの整備も手がけています。こちらこそ、本日はよろしくお願いします。

　ヤフーでは現在、どんなプロジェクトでTypeScriptを使っているのでしょうか。

狩野：主にReactやVueを使ったUIやBFFといったフロントエンド開発で導入しています。Sansanはどうですか。

鳥山：新しいプロダクトのWebフロントエンドはTypeScriptで書いています。バックエンドについても、Node.jsのプロダクトはTypeScriptですね。

「現場での自主的な採用」が進んだ結果「社内標準」の開発言語に

──両社がTypeScriptを導入しはじめたのはいつごろでしたか。

狩野：ヤフーでは、2017年の終わりごろから、全社でテクノロジーの“脱レガシー”をスローガンに掲げて動きはじめたのですが、いくつかのプロジェクトやサービスが率先して、言語を従来のPHPから移行する際にTypeScriptを選択しました。また、それ以降、新しく作るプロダクトでもTypeScriptの採用が進んでいます。

　2017年4月の「ng-conf 2017」で、Googleが社内の標準言語としてTypeScriptを承認したという発表を行ったことも、少なからず影響を与えていると思います。

鳥山：私がTypeScript導入を主導したのは、2019年の入社直後に関わった、PC版「Eight」のWebフロントエンドです。このサービスは、2012年2月にスタートしており、今年で10年目になります。以前は、大部分がJavaScriptで書かれていたのですが、長い運営期間の中でロジックも巨大になっており、今後のことを考えると、静的型付けを導入して、より安全でサステナブルな形にシステムをリプレースしていく必要があると感じました。

　ヤフーでは、どのようなステップで移行を進めたのですか。

狩野：“脱レガシー”の取り組みの中で、例えば、以前はPHPで動いていたようなサービスを、Node.js、React、Vue.jsなどでモダナイズしたいといった要望がある場合、「そのあたりのフレームワークを採用するのであれば、TypeScriptを使うと開発しやすくなりますよ」と提案をしていました。

　合わせて、「言語サポートチーム」でTypeScriptのハンズオンを提供したり、「Webフロント技術室」を通じて、各フレームワークと合わせた活用をサポートしたりしていました。

狩野和博（かりの・かずひろ）氏

　ヤフー CTO室 SWAT所属。ヤフーの「SWAT」は、特定のサービスに属さず、システムの新規開発や刷新、技術調査など、技術的な課題に直面している社内のチームへのサポートを提供する組織。兼務として「言語サポートチーム」に所属し、TypeScriptに関する技術支援や人材育成、教育コンテンツの開発といった普及活動を手がける。

鳥山：「言語サポートチーム」と「Webフロント技術室」というのは、それぞれどのような役割を持っているのですか。

狩野：「言語サポートチーム」は特定の言語に対するサポートをしています。「Webフロント技術室」は、より広くフロントエンド領域全般でパフォーマンス改善など社内での横断的な取り組みを進めたり、フロントエンド領域の困りごと解決をしたりしているチームで、TypeScriptのほかにもReactやVue.jsのようなフレームワークについても扱います。私はどちらも兼務していますので、言語やフレームワークの支援にはかなり幅広く関わる感じになります。

　「Eight」での導入は、どんな感じだったのでしょう。

鳥山：まず、事前準備として社内で勉強会を開催し、エンジニアたちで基礎知識をインプットすることから始めました。並行して、既存のJavaScriptで書かれた社内向けライブラリをTypeScriptで置き換えながら、ある程度の準備が整った段階でプロダクトに入れていったという感じです。そこから、機能開発の片手間に、古いコードをどんどんTypeScriptで置き換えていき、2年ほどかけて全体の移行が完了しました。

──TypeScriptの採用にあたって、それぞれの社内では、どこかの部署や担当者が決定権を持っていたのでしょうか。

狩野：ヤフーの場合、“脱レガシー”の開始当時は「言語サポートチーム」がありませんでしたので、各サービスで主導した部分が多かったように思います。ヤフーでは現在、社内の「標準言語」と「準標準言語」を定めています。サービス開発にそれ以外の言語を使いたい場合は、その都度、技術責任者に承認をもらう必要があります。TypeScriptは「準標準言語」として取り扱っているのですが、さまざまなサービスで採用されていく中で、他のサービスでもより使いやすいものにできるよう、全社的に「標準言語」にする動きがあります。

　最初から「標準」として採用したかったのですが、当時はまだ、教育研修コンテンツなどが十分に整備されていない状況だったため、まずは「準標準」での採用になりました。その後、コンテンツや体制の整備が進み、2023年度以降は晴れて「標準言語」となる見込みです。標準言語に採用されると、プラットフォームチームと今以上に協力してSDKの改善をしやすくなり、TypeScriptが現場でより使いやすくなります。

鳥山：Sansanも「どこかが主導して」という感じではなかったように記憶しています。EightのTypeScript導入については、入社後、私が当時のテックリードやアーキテクトに直接掛け合って、採用を承認してもらいました。既に現場でも「JavaScriptだけでは、この先厳しい」という見方が出てきており、対策を議論していましたが、そのタイミングではTypeScriptへの移行がベストだろうと考えられました。

　加えて、たまたま当時、フロントエンドに強いエンジニアのリソースに余裕があったという社内事情もあります。今やらなければ、この先もっと大変になるという危機感のもと、それぞれのプロダクトで導入を進め、今ではTypeScriptがデファクトスタンダードになっているという状況です。

TypeScriptが「開発者」「チーム」「プロダクト」にもたらすメリット

──実際にTypeScriptを導入して、感じているメリットはありますか。

狩野：一番のメリットとしては、よく言われるように「静的型付け」によるコード品質の担保や、メンテナンス性の向上などが挙げられると思います。移行以前は、PHPやJavaScriptのような動的型付け言語で書かれたコードが、長年にわたって継ぎ足されてきた状況でした。機能追加や改修などの際には、昔に書かれたコードの意図を理解するのに時間をかけたり、他の機能への影響を気にしたりしながら進めていたのですが、TypeScriptに移行し、型が書かれるようになったことで、そのあたりがかなりシンプルになりました。

　あと、実際にコードを書く際にも、IDEと連携したコードの補完機能、型のチェック機能が有効に使え、開発者の生産性向上に寄与しています。

鳥山：開発現場でのメリットについては、狩野さんの言われた部分が大きいですね。型には、コードの意図を明確にするドキュメントとしての側面がありますが、TypeScriptが標準的に使われるということは、きちんとドキュメントが残されるコードが増えることを意味します。既存のコードを1カ所だけいじるような場合も、型エラーが示されることで影響範囲が分かりやすくなり、長く触られていなかった部分や、他の人が書いた部分などに手を入れる際の開発者の負担が軽減されます。

　コードの品質が上がることで、プロダクト全体の品質も上がります。Sansanでは、QAチームが定量的に評価していますが、以前と比べてフロントエンドに起因するバグの発生は明らかに減りました。これは、静的型付けによって、安全なコードが多く書かれるようになったことが大きな理由だと思います。開発者、チーム、プロダクトのいずれにとっても、移行のメリットはあったと感じています。

鳥山らいか（とりやま・らいか）氏

　Sansan 技術本部 Eight Engineering Unit フロントエンドエンジニア。大学・大学院ではHCI（Human-Computer Interaction）を専攻し、インタラクションデザインを学ぶ。2019年、新卒でSansan株式会社に入社。複数のサービスを横断してWebフロントエンドの開発サポートを行いつつ、開発者体験（DX）向上に取り組む。

──TypeScriptの導入にあたって、特に注意した点や難しいと感じた点はありましたか。

狩野：これは、ヤフー固有の事情ですが、TypeScriptを本格的に採用しはじめた時期と、全社で“脱レガシー”に動きはじめた時期が重なったのが、少し大変でしたね。プラットフォームや開発プロセスを変えていくのと同時に、言語にも新しいものを採用しようとしたことで、現場の負荷は大きくなりました。ただ、たしかに苦労はありましたが、そこから学べたことも多く、将来的にも有益な取り組みだったと思います。

　あと、実装時の注意点としては「あまり型づくりに凝りすぎない」ようにした方がいいかもしれません。今では、TypeScript自体の機能がリッチになり、いろいろな型を書けるようになっています。開発者自身も、言語への理解が進むと、書きながら「こういう型があるといいな」と思いはじめます。そこで、型づくりに凝りはじめると、肝心の実装が進まなくなりがちです。実際のところ、時間を掛けて作ってはみたものの、それほど効果的ではなく、既存の型を使ったほうがいい場合も多々あります。そのあたりは、ほどほどにしておく意識が必要かもしれません。

鳥山：私の場合は、既存のコードをTypeScriptに置き換える作業を大量にやりましたが、そこで重要視していたのは「型とロジックを同時にいじらない」ことでした。JavaScriptのコードは、書き方によって、TypeScriptの型を当てはめるのが難しいものになっていることが結構あります。その場合は、あまり深入りせず、ひとまず型だけを当てておき、ロジックについては後でリファクタリングするという方針にしました。型の当てはめとロジックの整理は、段階を分けて別々にやらないと混乱を招きます。

狩野：たしかにそうですね。プロダクトやコードの品質を上げるための移行作業なのに、ロジックをいじったことで、バグが増えてしまうという失敗はありがちです。

鳥山：TypeScript自体やそのエコシステムも日々進化していて、標準で使える型が増えたり、表現力が向上したり、関連ツールが強化されたりしています。その時点で難しい作業も、次の年にやってみたらすんなりできてしまうようなことが、実際にあります。ですから、「難しい」と感じたら、その場では適度にあきらめながらやるのが、移行をうまく進めるコツかもしれません。

TypeScript促進のための「人材育成」はどう進める？

──社内にTypeScriptを書けるエンジニアを増やすために、両社ではどのような取り組みをされていますか。

狩野：前出の「標準言語」への採用にあたっては、まず「教育研修コンテンツの拡充」が課題でした。なので、最初に注力したのは、ハンズオントレーニングの資料作成ですね。TypeScriptの基本的な文法を学べるような資料を作成し、社内に勉強会開催のお知らせを出したところ直後に20プロジェクトくらいから申し込みがありました。現在でも、半年に1～2回ほど、ハンズオン形式の勉強会を社内で開催しています。

鳥山：Sansanでは現在、「勉強会」と「業務現場でのサポート」の大きく2つに注力しています。勉強会については、ランチタイムにご飯を食べながら書籍やドキュメントを輪読したり、「Type Challenge」と呼ばれる型パズルの問題集を解いたりしていますね。

　あと、業務現場でのサポートは「TypeScriptで書きたいけれど、何をどう書けばいいか分からない」という人に対して、直接コードレビューをしながら、習得を手助けしていくという感じです。

　さらに、自分が移行時に大量に手がけた、JavaScriptからTypeScriptへの変換作業をドキュメント化することも並行して取り組んでいます。ドキュメントを通じて、誰でも作業ができるようにしておくことで、新しいメンバーが自主的に移行に取り組んでくれるような環境を作りたいと思っています。

狩野：移行作業のドキュメント化には、私も興味があります。新規開発についてはTypeScriptを使うのが標準になりつつありますが、過去にJavaScriptで作ったものを移行する作業は、まだ多くあります。どういうドキュメントが必要なのでしょうか。

鳥山：移行作業のドキュメントについては、「誰でもやれる」ことを念頭に、特に安全性に配慮して作っていますね。このとおりにやれば、9割のコードはすんなりと移行できるようなものを意識しています。私も、ヤフーでどのような教育研修コンテンツを用意しているのか、興味があります。

狩野：コンテンツの作成にあたって、「TypeScript Deep Dive」のような公開ドキュメントは参考にしました。あと、今は多くの企業がTypeScriptに関する研修資料を公開していますが、自分としては、リクルートの新卒研修資料の「流れ」がとても良いと感じ、参考にしています。

　研修資料だと、どうしても基礎的な部分から網羅的に説明しがちになってしまうのですが、その資料では、簡単な型、関数、インターフェースの説明から、「実際のアプリケーションでは、こういう表現が必要になる」というところまでを、まとめて見せています。段階的に難易度を上げ、見ている人を飽きさせずに、できることを増やしていく流れが良いと思いました。

TypeScript Deep Dive 日本語版
TypeScript Bootcamp 2022（リクルートの新卒研修資料）

──TypeScriptを学んでいるエンジニアによく聞かれることや、それに対してのアドバイスなどはありますか。

狩野：ハンズオン研修の受講者からは「勉強のために良い書籍はある？」と聞かれることが多いですね。自分の場合は、公式のドキュメントやアップデート情報を見ながらやっているので、「書籍のお勧め」がすぐに出てこないことがあるのですが、Sansanの輪読会では、何を読んだのですか。

鳥山：『実践TypeScript』（吉井健文著、マイナビ出版）や『プログラミングTypeScript』（Boris Cherny著、オライリージャパン）などを読みました。あと、新しいものだと“ブルーベリー本”と呼ばれている『プロを目指すためのTypeScript入門』（鈴木僚太著、技術評論社）あたりは、全体の流れがよく、特に初学者の人に向いているのではないかと思います。

狩野：あと、実際に勉強する際には、TypeScript単体を知ろうとするより、最初に基本的な文法を覚えたら、その後はReactやVue.jsのようなフレームワークと組み合わせて勉強していくほうが、より早く使いこなせるようになると思います。

鳥山：そうですね。実践的なライブラリやフレームワークと組み合わせて学ぶと、TypeScriptの便利さがより際立ちますし、理解度も上がりますね。

さらなる「品質」と「開発者体験」の向上を目指して

──現在、お二人が注目されているTypeScriptのトピックはありますか。

鳥山：ここ数年ずっと気になっているのは、スキーマ駆動開発とそれに伴うTypeScriptファイルのコードジェネレーションです。TypeScriptが、フロントエンドだけでなくバックエンドでも導入されるに従って、APIの型がより重要になってきています。まずAPIスキーマをしっかりと定義し、そこから型やコードに変換していくというプロセスをとることで、作られるアプリケーションもより堅牢なものにできるだろうと思っています。

狩野：私もその領域は気になっているのですが、規模が大きな既存サービスが複数あり、それぞれのチームでAPIを管理しているようなケースでは、実現のハードルが高いなと感じています。全社向けのチームで主導して、うまく進める方法を考える必要があるかもしれないですね。

　そのほかで気になっているテーマとしては「ビルド環境の改善」があります。最近、TypeScriptやNode.jsのライブラリにも、Rustを使ったものが増えているのですが、これはビルドやテストのパフォーマンスに対する、開発者のニーズが高いことを示していると思います。開発している時、コード修正から画面更新までの間に、何秒も待たされるというのは、エンジニアにとって嬉しくないですよね。

鳥山：たしかに、TypeScriptは型を取り除く変換を行う必要があるため、動くコードが出てくるまでのステップが、JavaScriptよりも多少増えることになりますね。

狩野：そのあたりの効率を上げる施策で、より良い開発者体験を提供できるようにしていきたいと考えています。

──最後に、TypeScriptに関連して、今後社内で進めたいと考えておられる取り組みがあれば聞かせてください。

鳥山：EightのWebフロントエンドについては、ひとまずTypeScript率100％を達成したので、まずはちょっと休みたいというのが正直な気持ちなのですが（笑）、コードのリファクタリングは、まだ完全とは言えないので、その作業をしていかなければと思っています。

　先ほど少し触れましたが、TypeScriptへの移行では「ロジックと型を同時にいじらない」ことを原則としていたため、現状、すべてに「型」が付与されたとはいうものの、ロジックには古いものが残っています。今後、コードを見直しながら、ロジックをより安全で、より正しいものにブラッシュアップしていきたいと思っています。しっかりやろうとすると、年単位での大規模な取り組みになるのですが、粛々と進める所存です。

狩野：ヤフーでは、今後TypeScriptを、社内の「標準言語」としていく方針があるので、新人か、ベテランかを問わず、サービスに関わるより多くのエンジニアが、迷わずTypeScriptを使って開発を進められるよう、環境整備を進めたいと思います。資料やハンズオンの改善も含めて、やるべきことは多くありますので、ぜひ一緒にやってみたいという方がいれば、声をかけてください。