音声書き起こし
1. オープニング
@potato4d
みなさんこんにちは。UITの4Dです。ユーザーインターフェイスとテクノロジーに関する開発者のためのポッドキャストUIT Inside、今回もやっていきたいと思います。この度ですね、現在ご覧いただいているUIT InsideのWebサイトをリニューアルいたしました。今回は、ポッドキャストの新しいウェブサイトの魅力ではなく、使いやすさとサステナビリティを両立するためのオウンドメディアのシステム作りを紹介したいなと思います。
2. リニューアルの経緯
@potato4d
まずですね、今回のリニューアルの経緯からなんですけど、もちろん単にメンテナンスコストを下げることがゴールではなくてですね。今見てもらっているウェブサイトを我々はポッドキャストフロントエンドって呼んでるんですけど、このポッドキャストフロントエンドのコストがですね、元々Nuxt.js v2で運用していてですね。で、今Vue 3時代にも突入してるかなと思うんですけど、結構前からそろそろ
@potato4d
移行しないといけないんじゃないかみたいな話が上がっていて、今ご覧いただいてるこのUIT Insideっていうのは、実際にアクセスいただいているウェブサイトの他に3つシステムがあって、計4つのシステムで稼働してるんですけど、このウェブサイトであるポッドキャストフロントエンドと我々が呼んでいるものと、入稿する社内ネットワークからだけ見れる管理画面のポッドキャストと呼ばれるCMS
@potato4d
と、外部向けAPIと、内部向けのCMS用のAPIっていうの。このうち、このポッドキャストフロンテンドって呼ばれる外部向けのウェブサイトと、外部向けのポッドキャストっていう管理画面のシステムが、それぞれNuxt.js v2とVue 2で運用しているシステムでですね、2019年に作ってそのまま運用って感じだったんですけど、このポッドキャストフロントエンドとポッドキャストCMSってのが、それぞれ2019年と2020年に作ったやつなんですけど、どちらもNuxt.js v2とVue 2になっていてですね、
@potato4d
ちょっとVue 3時代になるにあたって、サポートも終わるんで、ずっと移行しないといけないっていう風な状態がありました。で、これに合わせてですね、同じタイミングで、内部で使っている業務用API、外部向けAPIと内部向けAPIをホスティングしていた社内基盤みたいな、コンテナサービスのDockerファイルの基盤っていうのがデリケートになって、別のシステムに移行する必要があったっていうので、フロントエンドもサーバーサイドも全部乗り換えないといけないっていう風な都合が
@potato4d
発生しました。どちらかというと、メンテナンスが終了するシステムの移行っていうのが必然性として発生したので、それに合わせて全体のシステムを見直そうっていう風なところで、今回リニューアルに至ったっていう風な形となります。それぞれの記述自体は結構別々ではあるんですけど、毎回毎回リニューアルしても結構大変っていうことなんで、まとめてこの機会に全システム
@potato4d
見直したっていう風なところです。個別のリニューアルの詳細を伝える前に、今回のリニューアルの目標を2つ紹介したいなと思います。で、今回掲げたのは、より良いユーザー体験っていうところと、メンテナンスフリーなシステムってのを両立しようかなと。ユーザー体験の方はですね。先ほど申し上げたように、UIT Inside自体は2019年の初代のシステムからですね、ほぼ同じコードベースを継ぎ足しで管理してい
@potato4d
っていう風なところで、過去も何度かUIとかUXのリニューアルとか機能追加とか、今だとあれですかね、トランスクリプト、文字起こしデータの表示とかも以前アップデートで紹介させてもらったかなと思うんですけど、そんな感じでできること自体は増えていって、どんどん機能追加自体は行ってるんですけど、全部コードベースってのは5年前ですかね、のコードをそのまま継ぎ足して使っていたような形となります。
@potato4d
ただですね、初代のシステムっていうのが、そもそも音声のホスティングのためのウェブサイトが必要ってだけで作ったようなシステムで、結構簡単な作りだったんですよね。なんで、あんまり拡張性とか考慮してなくてですね、根本的な再生体験とかウェブサイトの使いやすさみたいなのを、当時は迅速にとりあえず最低限の音声再生のシステムだけあればいいやと思って作ったシステムのままになってしまって、あんまりこう、根本的な使いやすさが
@potato4d
良くないみたいな状態が続いてました。なんで、せっかくリニューアルするのであったら、過去のコードベースは残さずにこれで発信しようっていう風なところで、いいユーザー体験をちゃんと提供しようっていうところも1つの目的としました。もう1つの軸っていうのが、ポッドキャストでも話していたメンテナンスフリーなオウンドメディアみたいなのを作るっていう風なところとなってます。
@potato4d
で、UIT Insideって、もちろん今お聞きいただいているコンテンツ自体のこの音声コンテンツが本体ではあるんですが、なんかこのウェブサイト自体もある意味で開発者コンテンツではあるかなとは思っていて。自分たちの開発者が運営するオウンドメディアって、どういう風な構成になるんだろうっていうのも、1つの面白いコンテンツであったりだとか、他の開発者にとって参考になるような、好きになってるべきなんじゃないかなと思っていたので、それを高い水準で実現したいなというふうに思った次第です。
@potato4d
で、結構えてして、こういうサイトって、なんかメインの業務があって、その合間で更新するみたいなことになるのがほとんどなんで、やっぱりこう、コンテンツのアップデートはできるけど、システムの改修ってなると時間を割きづらいし、最低限の改修にとどまるみたいなのが多いかなと思ってます。なんで、そんな状況下でも安定して動き続けるサイトみたいなのをちゃんと作るべきだなと思っていて、それを1つのシステムとして作り上げて、今回せっかくなんでリニューアルエピソードで紹介したいなと。
@potato4d
それに向けて構築しました。それぞれをどういう風に実現していったかっていうのをこれから話したいなと思います。まず、フロントエンドの領域から説明していきたいなと思います。バックエンドの話はあんまり多くもないんで、まずフロントエンドの領域から紹介していきたいなと思います。で、結論から先に述べると、外部向けのサイトである、今ご覧いただいているポッドキャストフロントエンドっていうシステムは、Nuxt.jsのv2から最新のNext.jsに移行しました。で、管理画面の方のCMSと我々が呼んでいるポッドキャストアドミンのシステムは廃止することとしました。それぞれ少しずつ話していきたいと思います。で、ポッドキャストフロントエンドのこのウェブサイト本体の方はですね、とにかくユーザー体験の水準を上げるってのにこっちはこだわっていいかなと思って、Next.jsの移行を行いました。これまでもですね、従来のシステムでも、サードパーティのSDKみたいなところの要因を除くと、主要ページのほとんどで、ChromeにLighthouseが
@potato4d
搭載された頃からずっと、ほぼ100に近いスコアを維持するみたいなところを目標としていて、基本的な品質みたいなのは高め続けることを意識してました。で、ただ一方で、エピソードをまたいで、なんかこう、エピソード150を聞いた後に別のページに行って151番を聞くみたいなことをやった時に、再生体験があんまり良くなかったりとか。あと、当時のNuxt.js v2をベースにしてるんで、プリフェッチとかが十分じゃなくて、早いページと遅いページがあるみたいな形だったり。CSSのインジェクションをTailwindとNuxt.js v2で使ってるんですけど、その辺の都合で一部レイアウトの不具合というか、あんまり綺麗なレンダリングがなされてないみたいなのがあって、細かなユーザー体験にいくつか課題がありました。で、このあたりは、ソースコードを1から書き直すことによって、レイアウトシステムの部分とか、CSSインジェクションの問題は解消して、プリフェッチだったりっていう風なスピードの面っていうのは、Next.jsに移行することによって、パフォーマンスの課題を解消しました。
@potato4d
やっぱり今のNext.jsだと、プリフェッチとかキャッシュとかっていうのがかなり優秀なので、各ページの遷移体験っていうのがかなり良くなったかなと思っていますし、あと音声プレイヤーの方もスクラッチし直すことによって、結構従来のプレイヤーだとかなり昔のアーキテクチャだったので、DOM要素とVuexをまたぐような形で音声プレイヤーが動いていて、なかなかこう管理が万全とは言えないようなコードベースだったんで、ちょっと現代的なコンポーネントの分割統治みたいなの軸で、状態ライブラリ入れなくて、ちゃんと
@potato4d
密接なところで最低限の状態を管理していきましょうねみたいな形にしたことによって、結構ページアクセスごとに現代的なコンポーネントの分割、当時軸にしたことによって、ページ遷移のタイミングで、キャッシュを発していいようなステートっていう風なところと、継続的にページをまたいで管理したいステートみたいなのを明確に区別されるというような形の、現代的なアーキテクチャに寄せて、不整合とかが起きなくなっています。せっかくなんでですね、このあたりの内の解消と角度面の改善ってのを体験するためにも、ぜひ、今ですね、ウェブサイトでお聞きになってる方は、
@potato4d
このエピソードを聞きながらですね、適当にサイトの方を回遊していただいてですね、よりサクサク動作になったフロントエンドを体験してもらえればなと思います。ていう風なところで、ポッドキャストフロントエンドでは細かな体験の改善っていう風なところと、パフォーマンス向上みたいなところをメインで行いました。結構これまでもJPEGとPNGを使って画像配信していたりとかしていて、細かな部分の改善とかもやってたんで、ほとんどフレームワークによる恩恵が大きいような形にはなってるんですけど、試しに触ってみてもらえると違いは実感しやすいかなと
3. フロントエンドの話
@potato4d
思います。逆にポッドキャストアドミンの方はですね、もう今後のサステナビリティを重視して、もうWeb UI自体を廃止することとしました。代わりにですね、簡単なCLIのアプリケーションをロールリリースで作ることによって、ヘッドレスな運用へと切り替えました。コンテンツにこだわりさえできればいいっていう管理画面の特性上ですね。これまでアドミン自体は開発をしていたんですけど、機能改修ってのはほとんど行ってなくてですね。OCPのプレビュー機能をつけてやったりだとか、マークダウンのプレビュー機能をちょっと付けたりみたいな
@potato4d
形の開発の体験の改善みたいなのはやっていたんですけど、本当に片手で数えられるほどでしかなくて、機能改修以外で、どっちかっていうとこう、ホスティング基盤を移すとか、なんかそういうことばっかりやっていてですね。そのたびに、フレームワークとか依存ライブラリの本体の更新みたいなのはもちろんですけど、新しいNode.jsのメジャーバージョンに追従する際にこれが動かないとか、あと、手元で開発するときに、Appleシリコンだとこのネイティブエクステンションがあんまりうまく動かないみたいなのがあって、
@potato4d
結構こう、触るたびに修繕が必要になるみたいなのがあってですね。なかなかこう、あんまり触らない割にこ、管理コストが高いみたいな状態が続いてました。で、それを新たに作り替えるってのも1つの選択肢ではあったんですけど、運営チームが全員フロントエンドの開発者っていうところなので、これなら専用の画面はもう作らなくてもいいかなと思っていてですね、内部のAPIとの連携をシームレスに行ってくれるCLIさえあればいいなと思って、それで作り直すことにしました。今回はCacJSを使ってるんですけど、シンプルなCLIを使えるものであればなんでも技術的にはいいかなと思っております。コマンド自体は7つしかなくて、ほとんどJSONの入出力と、ただのAPIだとできない検索機能の提供みたいなところだけやっていてですね、プログラマブルに扱いやすい、JSONをうまくAPIと手元で同期してくれるっていう風なところをメインとするようなCLIツールにしていて、例えば下書き中のエピソードを公開する作業とかだけをCLIのコマンド1発でできるような形にするっていうシンプルな
@potato4d
作りとしました。なんで、ちょっとショーノートの方にどんなコマンドがあるかっていうのを掲載しておこうかなと思うんですけど、もう本当にサーチ機能、エピソードであったり、出演者の検索機能とアップロード機能、ダウンロード機能と公開のコマンドみたいなものしかなくてですね。非常にシンプルに作り上げていることから、あんまりメンテナンスすることもないですし、最悪、裏のAPIの設計っていうのが透けて見えるような実装になってるんで、もしトラブルがあったら最悪APIともユーザー体験自体は落ちますけどできますし、
@potato4d
修正とかも容易で、今後の更新みたいなところの対応も容易っていうところから、もう完全にCLIに寄せてしまうっていう風な方針にしました。で、これまでの課題であった依存パッケージの更新がめんどくさいみたいな話も含めて、もう10個を切ったような形の依存関係にしていて、機能拡張の際とかも、ライブラリの更新から始めることになるみたいな事態を防ぐような形にしています。で、実はこのCLI自体は、全体のリニューアルに先立って、システム移行の半年ぐらい前から行っていて、ただ、現状大きなトラブルもなくですね、管理コンポーネントが1つ減ったことによって、シンプルに意識向ける対象が減って楽になったかなっていう風なところがあります。なんで、結構やっぱり開発者向けであっても、せっかくなら管理画面を。みたいなのってフロントエンドのエンジニアだとこだわりたくなる。プラス、あんまりプロダクション環境だと使えないUIフレームワークというか、UIライブラリを実験する場所にもなったりしてるかなと思うんですが、なんか我々のニーズだったら
@potato4d
CLIでいいかなっていう風なところで、どっちかっていうとこう、メンテナンス対象を減らすっていう風な形で取ることとしました。で、ここまでがフロントエンドの話となります。で、次にバックエンドの更新も紹介したいと思います。バックエンドはですね、基本的にシステム本体には手をつけずにですね、ランタイムの実行基盤だけ移行することとしました。というのもですね、今回バックエンドも移行しないといけないってそもそもの要因となったのが、社内の古いコンテナサービスがあるっていう部分だったので、そこの移行だけするっていうのがいいんじゃないかなと思って行いました。
4. バックエンドの話
@potato4d
で、この時に行った我々の意思決定として紹介したいのがですね、いわゆるコンテナサービスのDockerfile型の管理ではなくてですね、いわゆるビルドパック型と呼ばれるプラットフォームアズアサービス（PaaS）の形を採用したことになるかなと思います。最近だとですね、結構コンテナ自体でもあるんで、Kubernetesアズアサービスだったり、コンテナアズアサービスのPaaSとかが利用されることが多いかなと思うんですが、今でも結構ビルドパック型のPaaS基盤ってのはある意味メジャーかなとは思っていて、それを選択した風な形となります。
@potato4d
で、ちょっとフロントエンドエンジニア向けのポッドキャストであるので、ビルドパック型の基盤ってどういうものかっていう風な話をさせてもらうとですね、いわゆる外部サービス、我々の社内のサービスで言うとGoogle CloudのApp Engineであったり、あとCloud Foundryにも結構こう、Pythonとかのランタイムをビルドパックってものが用意されていて、実はDockerfileに依存せずにDockerベースの仕組みってのを動かすってのは各プラットフォームに存在します。
@potato4d
コンテナサービスのDockerfile型のシステムってのは、自分たちでDockerfileを書いて、そのイメージってのをレジストリに送ることによって、そいつを動かしてくれるっていうサービスになるかなと思うんですけど、ビルドパック型のサービスていうのは、ソースコードを変えて、今回だとNode.jsのコードを変えて、プラットフォーマーが提供している言語ランタイム、今回であればNode.jsのバージョンいくつですよっていうのを指定することによって、プラットフォーマー自身が所持しているDockerfileの中にプラットフォーム側が我々が提出したユーザーが提出したソースコードを注入した上でのイメージを焼いてくれるみたいなシステムとなっております。なんで、自分たちでDockerfileをメンテする必要はなくて、プラットフォーマーが提供するDockerイメージにソースコードが肉付けされるっていう風なイメージになりますね。と、そんな形をとっています。で、もちろんですね、これを使うとですね、Dockerfileを直で書くわけじゃなくなるんで、こう、柔軟性みたいなのは下がるんですけど、Dockerfile自体のメンテナンスが不要であることはもちろんですね。あと、デプロイのたびにプラットフォーマーが用意しているベースとなるビルドパックにソースコードを入れるって形になることから、毎回その時点での最新のセキュリティパッチが適用されたバージョンっていうのを使ってくれるっていうところから、まあとにかくセキュリティパッチとかの安全面含めてマネージな状態で動かすことに貢献してくれるっていうところに魅力を感じて、今回はビルドパック型を選択しました。どうしてもやっぱりコンテナとかだとなんでもできちゃうんで、コンテナベースのシステム買うならDockerfileがいいよねっていう風に魅力的にうつ
@potato4d
ちゃうこともあるかなと思うんですけど、そもそも我々が結構コンテナベースのシステムとかPaaSとかを利用する理由って、やっぱり運用コスト、ちょっと柔軟性をどういう風に天秤に取るかっていうところかなと思っていて。なんでもできる方がいいんだったら全部IaaSを使うと思うんですけど、じゃあなんでIaaS使ってないのっていうところを考えると、やっぱりメンテナンスコストだったり安全性みたいなところをマネージドのレイヤーで担保してくれるからかなと思っていて。そうなった時、我々のユースケースだとシンプルなNode.jsアプリケーションを動かすってだけになるので、実はDockerfileにこだわる必要はないんじゃないかなっていう風なところから、ビルドパック型を採用しました。ちょうどですね、収録してる本日5月15日段階でFirebaseのApp Hostingっていうのが発表されたんですけど、それも結構こう、ソースコードを渡すと自動でシステムのフレームワークとか言語を検知してくれて、それでホスティングしてくれるっていう機能みたいで。
@potato4d
数自体が多いかって言われると多くはないかなと思うんですが、やっぱり世間的な認知としても、引き続きビルドパック側の需要はあるんじゃないかなと思っております。なんで、昨今の情勢とかを見ても、全然このビルドパックを採用するデメリットってのは大きくはないかなっていう風なところ、システムの複雑さっていうところを考えると、ビルドパック型で十分じゃないかなと思って移行しました。実際に私たちが使っているのはLINE社内のプライベートクラウドなんですが、今言及したようにPaaSであったりだとか、Google Cloudっていったパブリッククラウドの世界でも同様の考えが通用するので、ぜひ選択肢の1つとしてビルドパック型っていうのを考えてみてもらえるといいんじゃないかなと思っております。なんであんまり背伸びしなくてもいいみたいなのが、この点のエンジニアとしては言えるんじゃないかなと思っております。そんなこんなで、全体として使いやすさとメンテナンスフリーみたいなのを両立することとしてリニューアルしたUIT Insideですけど、実際ですね、使いやすいと感じてもらえるかどうかは、このウェブサイトの今触って聞いていただいている方々次第かなと思いますので、ぜひでもハッシュタグ、ハッシュUIT、アンダースコアインサイドで新しいシステムどうや。っていう風に言ってもらったりすると嬉しいなと思っております。
5. クロージング
@potato4d
少なくとも、サステナブルなオウンドメディアみたいなところをゴールとした場合に、メンテナンスフリーにはなってるんじゃないかなとは思ってるんで、今後また1年後とかでシステムどうでした。みたいな話はできるといいかなと思っております。という風なところで今日のエピソードは終わろうかなと思います。今日はUIT Insideのリニューアルの裏側について話していきました。ありがとうございました。
