Webアーキテクチャで迷わないためのイリティ（-ility）のすゝめ

はじめに

こんにちは！NewsPicks、 Web Experience Unit のイイダユカコ (@becyn) です。
本記事は NewsPicks Advent Calendar 2023 の 25 日目の記事です。最終日の担当をキャッチしてしまいました。ハードルがやや上がっていることを感じますが、2023年もあと数日、優しい気持ちで読んでいただけると幸甚です。 (24日にコロナ＆インフルに同時感染してしまい、投稿が遅れました。お待たせして申し訳ありません。)

イリティ (-ility) とは

イリティ (-ility) というワードを目にしたことがあるでしょうか？プロダクト開発をしていると、可用性、信頼性、テスト容易性、スケーラビリティなどの単語をよく聞くと思います。これらを英語表現した時、Availability、Reliability、Testability、Scalabilityのように-illityとなり、これらの総称をイリティ (-ility) 、日本語ではアーキテクチャ特性と呼びます。書籍『ソフトウェアアーキテクチャの基礎』では以下のように紹介がされており、ソフトウェアアーキテクチャを考える上で軸となる考え方であることがわかります。

私たちは、ソフトウェアアーキテクチャを、システムの構造、システムがサポートしなければならないアーキテクチャ特性 (-ility) 、アーキテクチャ決定、そして設計指針の組み合わせで構成されるものだと考えている。

この記事では、イリティの考え方を実際のWebプロダクトの開発、設計を進める中でどう解釈し、どうアウトプットに繋げ、どう運用しているかを紹介したいと思います。

NewsPicksとWebプロダクトの現在地

具体例を共有する前に、よりイメージしてもらいやすいよう、少しだけ私達が現在携わっているプロダクトについて紹介させてください。

NewsPicks は2013年9月よりサービスを開始し、 2014年6月よりウェブプラットフォームでのサービス提供を開始しました。当時の技術選定は何も特別トリッキーなことはなく、安定した技術選定がされていたと思います。ただ、2020年代に入り、フロントエンド技術は格段に進化し、その分、フロントエンド領域が担うものは増え、より大きなシステム、大きな事業を担える存在になりました。NewsPicks を始めとするメディア・サービス界隈でも同様です。より他社のサービスに負けないよう、いち早くユーザーに新機能を届けられるよう、開発スピードを精度高く上げていく必要があります。そのため、実装内容の依存関係を追いやすくし、テストで機能を担保し、開発障壁を下げた上で開発部隊が最速で実装＆リリースできる環境が求められました。これらを実現するため、2021年より基盤となる技術を乗せ換えるリアーキテクチャプロジェクトが開始されました。実際には、元々 Java の Spring Framework ベースの Web プロダクトを Next.js 、 TypeScript、 GraphQL を用いた基盤に移し替え、ガラッと風貌を変えることになります。

リアーキテクチャ前後における印象の差

旧基盤と新基盤を比較した際、使用技術を大きく変えたのはもちろんですが、メインメンテナーポジションという個人から見た「一番のギャップ」はイリティへの配慮とその表現です。

前述した通り、本プロジェクトの目的は「実装内容の依存関係を追いやすくし、テストで機能を担保し、開発障壁を下げた上で開発部隊が最速で実装＆リリースできる環境を実現するための仕組みをつくること」です。また、今回手掛けるWeb基盤は、メインメンテナーを担っている我々（Web Experience Unit）以外の division メンバー（普段フロントエンド領域をメインで触ってない方が多数）もコミットメントすることが前提となっています。コミットメントしてくれるメンバーの前提知識量に依存せず、上記を再現性高く表現できる必要がありました。

以下のセクションでは、実際にどういったアーキテクチャ特性を設計や仕組みに練り込んだかを紹介します。

使いやすさ （Usability）

1つ目のイリティは、実際にサービスを利用するエンドユーザーにとっての使いやすさ (Usability) です。

リアーキテクチャプロジェクトが始まったタイミングで同時にUIのリニューアルプロジェクトも始まりました。いわずもがな、Webプロダクト全体を通して一貫性のある、ユーザーが学習可能な使いやすいプロダクトをデザインし直そうという動きです。その際、新しく定義されるデザイントークンやデザインルールでより「NewsPicks らしさ」を表現していきたいという思いから、デザインシステムを作るプロジェクトも同時に立ち上がり、プロダクト全体の世界観の表現と統一を目指すことになりました。
せっかく考えれらたデザイン仕様を実装面でしっかりと追従し、また似たような形のコンポーネントの重複が起こらないよう管理しなければいけません。

より良い状態で管理するため、実装面では、大小問わずすべてのコンポーネントに対して Storybook を用いたUIライブラリーを用意し、社内ネットワークに繋がっていれば誰でも確認できるようにしました。その中で管理されているコンポーネントは、わかりやすく言うと、すべてです。button サイズの小さなコンポーネントはもちろん、ページレイアウトを司る1ページ分のコンポーネントまでを含んでいます。また、それら一つ一つのコンポーネントがもつ props の変化によって変わる表示のバリエーションをすべて変数をいじることなく確認できるようメンテナンスしています。
それだけだと「やや不安…」という方もいらっしゃると思います。我々もそうで、現在では週に一度、Webの開発に関わってくれているデザイナーさんたちと一緒に「コンポーネント Sync」というミーティングを開いています。ここでは、既存のコンポーネントやこれから扱う予定のコンポーネントをデザイナーとエンジニアが一緒になって確認し、これまでのルールに沿っているか、より最適化された管理しやすい状態はないかなど話し合われます。（規模によっては、実際にその場で直して即コード反映しています）

これらによって、デザインシステムに連動する実装面を整備、職種を越境してチェックすることで、機能拡充、ページリニューアルを行いながらしっかりと使いやすさ Usability 向上を確実に行える環境に整備しました。

テスト容易性・テスト実行可能性 (Testability)

2つ目のイリティは、成果物に対するテスト容易性・テスト実行可能性 (Testability) です。

テストは、プロダクトが壊れていないことを保証することと同時に、何がどう動いていることが求められているのかを開発者が理解するために必要とされる存在です。そのため、Web リアーキテクチャプロジェクトが始まった当初からだいたいのテストは実装対象となっていました。Webプロダクト内では、以下の7つの種別のテストが存在しています。

• lint テスト
• build テスト
• util に対する単体テスト
• コンポーネント毎のレンダリングテスト
• コンポーネント毎の Storybook を元にしたコンポーネントの Accessibility テスト
• コンポーネント毎の Storybook を元にしたコンポーネントの VRT (Visual Regression Testing)
• End-to-End テスト

前述した通り、普段 Web 基盤に触れていないメンバーがコミットしてもらうことを前提としています。そのメンバーに同様のテストケースを用意してもらうため、「コンポーネント毎のレンダリングテスト/Accessibility テスト/VRT」の3つについては hygen を使ったテストファイルを自動生成させています。また、複雑すぎたり、flaky なテストを避けるため、「End-to-End テスト」では API 疎通とレスポンスを使用した最低限のテストのみに限っています。

このように、誰しもがコミットメントでき、気軽にメンテナンスに貢献できる仕組みづくりに努めました。これらすべてが、今開発するメンバーの増加後もデプロイ頻度を下げず開発し続けられる要因になっていると感じています。これに関しては以下の登壇資料でも言及しているので、もし興味があればご覧になってください。

可観測性 (Observability)

3つ目のイリティは、プロダクトの可観測性 (Observability) です。ここでの可観測性の対象環境は、本番環境だけではなく、開発環境から本番環境に至るまでのすべての環境を含んでいます。

NewsPicks の Web プロダクトでは、New Relic をObservabilityツールとして採用しています。普段の自分たちの業務の効率化のためはもちろん、「何かが起こった時」に自身のUnitがメインメンテナーとして見ている基盤を属人化スキルを不要とし、チームで解決に向かわせる環境づくりとしてもとても重要な役割を持っています。また、いわゆる「見える化」が進むことにより、Reliability、Availability を誰でもいつでも見れる状態になりました。毎週の定例でもUnitメンバー全員で確認する時間を設けることで、関連SLOに対しての定義も含めてチームで同じ認識を取れている状態です。その結果、新卒一年目のメンバーから基盤に対するSLO調整について提言をしてもらえました。そのぐらい身近な存在になれた状態になり、Unit が持つ「基盤のメインメンテナー」としての役割を担えている状態になったと思っています。

少し前の登壇になりますが、導入や実際に使用している New Relic の機能の話もしているので、もし興味あればご参照ください。

個人的には、他のイリティの中でもかなり力を入れて進めている部分です。いずれ組織の形が変わっても（最悪自分やメンバーが離れてしまっても）問題が起こらないよう、誰かに状況を把握してもらいやすくするための 生きる引き継ぎ資料 となっていると思っています。来年はよりSREメンバーのみなさんと連携し、division で監視体制の取れる状態に成長させたいと思っています…！（良くも悪くもガラパゴス的に成長させまくってしまった気がしているので、組織内での最適化を図りたい ）

アクセシビリティ (Accessibility)

4つ目のイリティは、アクセシビリティ (Accessibility) です。

ユーザーが接するプロダクトを開発する人であれば、利用されるあらゆる環境に対して適切な形で情報を提供したいですよね。私も同じ思いで、小さくてもいいから少しずつアクセシビリティを向上する仕組みを入れたく、リアーキテクチャプロジェクトを始めた頃からチェックする仕組みを取り入れてきました。

「テスト容易性・テスト実行可能性 (Testability)」の章内で「コンポーネント毎の Storybook を元にしたコンポーネントの Accessibility テスト」と紹介しましたが、lint チェックのようにアクセシビリティの最低限のテストを行うために jest-axe を用いています。これにより、最低限の品質をすべてのコンポーネントで担保できている状態を整えました。

一方、最終的に目指すアクセシビリティ品質は、プロダクト要件によって変わります。当初私達も、自分たちのプロダクト上でどういったアクセシビリティ品質を提供すべきかについて不透明な状態でした。リニューアルプロジェクトにおいてこの問題を解決するには、開発者だけでなく、デザイナーやPdMの方も含めて一緒に考えられる状況が必要でした。そのために、開発者主導でWebアクセシビリティガイドラインを NewsPicks Web用に用意しました。現在も、プロダクトに対するチェックとガイドラインのメンテナンスを開発者主導で行なっています。具体的な活動内容については、以下のスライドでも紹介しているので、興味があれば覗いてみてください。

これらによって、テストで実装上気をつけるべき最低限のものを保証しつつ、メンバー一人ひとりが「目」となりアクセシビリティの品質に関心を持てるような環境に近づけました。正直実装としてもまだまだこれからなフェーズで、根本仕様としても見直さないといけない部分も多く存在しています。が、一朝一夕で完璧になるものではないと思うので、今後もチーム一丸となって「上質なプロダクトだ」と言われるよう精進していきたいですし、それをチームとして目指していけるような環境を作りたいです。

得られた成果

これらのイリティは当然ながら一日でできあがったものではありません。Web 基盤のリアーキテクチャプロジェクトからリリースされた記念すべき第一弾は、2021年12月14日、アクセス数が比較的多くない設定画面内の1ページでした。気がつけばそこからちょうど2年が経ち、イリティから得られた成果は数えられないほどあります。

その中でも、特に印象深かったのは、直近あったトップページのリアーキテクチャ前後の Observability です。設定画面内の1ページから始まったリアーキテクチャも、今年はついにトップページのリリースに至り、プロジェクトとして大きな山場を超えた年になりました。想像できる通り、これまでリアーキテクチャしてきたページとは比にならないぐらいのアクセス数や負荷を受ける状態になりました。そんな時に「どこをどう見れば良いのかわからない」という路頭に迷うことがなかったのは、上記で紹介したイリティの一つ、Observability が効いたんだと思います。まさに、大きな山場を越えるための杖になってくれました。

他のイリティについても、プロダクト開発の中で同じような心強さを感じます。プロダクト拡大フェーズにぶつかる「想定した動きができているだろうか」「ちゃんと届けたい情報が届けられているだろうか」「困っているユーザーはいないだろうか（いたとして、どのくらいの規模だろうか）」といった不安にイリテイを考慮した設計が安心をくれます。長期開発が想定されるプロダクトこそ、このイリティと向き合い、設計に取り込み仕組み化するプロセスが大事だと身をもって感じています。

まとめ

この投稿に書ききれていないものもありますが、私が Web アーキテクチャを考える際に考慮したイリティを紹介させていただきました。正直なところ、はじめからこれだけのイリティを考えられていたかでいうと怪しいです（初期は、事業として、開発の要件定義や技術選定や安定性に集中したフェーズでした）。しかし、日々の開発の中で、「開発しやすさ、メンテナンス性向上のために」と少しずつ取り入れ、今に至ります。改めてプロダクト全体をイリティの切り口で見た時に上記したような形となり、「アーキテクチャは一日してならずだ」と改めて深く感じます。

同様に、2024年も全く同じ形で走り抜けるだろうとは思っていません。少しずつ改善していき、より開発しやすい基盤に仕上げていきたいと思っています。

さいごに

体調不良により投稿が遅れ、完全に年末モードのお休みタイミングでえらい真面目な話をしてしまった気がしますが、「イリティの視点をプロダクトに導入、メンテナンスすることで、基盤設計時や開発フェーズで迷いが減り、背中を押してくれる存在になってくれるぞ！より全員が開発に集中できてええぞ！」という内容でした。（取り入れりゃいい、多ければいいってもんじゃないと思うので、用法用量に気をつけて、適度に導入していくのが大事っぽい。何事もプロダクトや組織との会話が大事ですね。）

最後まで読んでいただきありがとうございました。また、もう絶対伝わってると思いますが、今回紹介した内容は私一人で全部用意したものではありません。これまで Web 基盤の開発に携わってくれたひとりひとりがより良い基盤を目指した結果です。この場を借りて、尽力してくれたみんなに感謝を伝えたいです。ありがとございました…！！改めまして、関係各所のみなさま、今年もお世話になりました！来年もしっかりやっていくぞ！

では、みなさん良いお年をお迎えください〜
コロナとインフル、両方お気をつけて〜ほんとに〜

告知

なんと、NewsPicks プロダクトチームが、あの『Software Design』で連載を開始します Software Design 2024年1月号からとなっております！アドカレの後は是非こちらもご一読くださいー！

2021年9月から始めた UZABASE のテック系 Podcast 『Meet UB Tech』では今でも MC を担当しています！（新 MC も増えて、より豪華になりました！）こちらも気づけば3年目です。元気な社内紹介回、豪華なゲスト回がてんこ盛りです！よかったら聴いていってください！

遅ればせながら、簡単な自己紹介

2019年9月より NewsPicks でフロントエンド領域を中心にエンジニアとして従事しています。興味分野は、Observability、Accessibilityあたりです。最近は自分でまだ切り口を見い出せてないイリティを探しているフシがあります。

今年は、7月から Unit リーダーに就任し、個人的にも大きな変化の年でした。最後でも触れていますが、2024年も開発ハードルの低い、みんなが安心して挑戦できる基盤をより改善＆推進＆開発していきたいと思います！「最近どんどんパワーアップしてんね？」と言ってもらえるよう張り切っていくぞ！