【KiZUKAI開発ブログ#５】なぜKiZUKAIはMaterial-UIを導入したのか

はじめに

UIUXマネージャーの松崎です。

KiZUKAIでは今年2月頃より「プロダクト品質の向上および開発の加速」を目的とし、Reactコンポーネントライブラリ「Material-UI」（以下、MUI）を一部画面から導入開始しました。

MUIについて、公式ドキュメントでは下記のように書かれています。

「マテリアル UI は、Google のマテリアル デザインを実装するオープンソースの React コンポーネント ライブラリです。」 （“Material UI is an open-source React component library that implements Google's Material Design.”）

引用元：https://mui.com/material-ui/getting-started/

昨今では、MUI以外にも多くのコンポーネントライブラリが存在します。また、その中でMUIを選択することも珍しいことではありません。

しかしながらKiZUKAIでは、ユニークなイシューと導入理由があったため、今回改めて開発ブログで紹介できればと思います。

サマリー

1、UIUXチーム、フロントエンドチーム、オフショア開発チーム、それぞれのイシューをMUIを導入することで、一定程度は解決することが出来た。

2、日本人のデザイン的コモンセンスは海外では通用しない。デザインのバックボーンに「マテリアルデザイン」を取り入れたMUIは、グローバルな開発現場において相性が良い。

3、実際にベトナムに訪れたことによる一次情報によって、イシューの解像度が増し、より良いソリューションを選べた。

MUI導入に至った背景

2022年6月のシリーズA調達以前

当時はCTOがUIデザインまでを1人で兼任していました。また、シリーズAに向けて、プロダクトリリースを優先しており、プロダクトも小規模であったため、独自コンポーネントでの開発を進めていました。

2022年6月にシリーズAを調達

6月に松崎が入社。入社後にCTOから「独自性の高い機能のUIにリソースを割きたい」「将来的には、独自性の低い箇所はコンポーネントライブラリで対応したい」とオーダーを受けました。

ただ、当時は

• あまり問題が発生していなかった点
• UI全体を移行するとなると開発コストが掛かる点

から、外部ライブラリの導入については、タイミングを検討することに。取り急ぎは独自コンポーネントのライブラリ化を進めていました。

その後、新規機能開発を加速

機能追加により、画面数が約3倍と大幅に増加しました。もちろん量だけでなく、月当たりで扱う画面数も増えていき、結果として多くのイシューが発生しました。

根本原因として挙げられるのは「開発スピードが増したことで、コミュニケーションでカバーしていたポイントをカバーできなくなったこと」かなと思います。ある意味、成長痛のようなポジティブな問題であったと振り返ります。

それぞれのチームの問題について、UIUXチームとフロントエンドチームでコミュニケーションをとり、「MUI移行によるメリデメ」と「移行にあたっての不明点」を洗い出し、解消していきました。

結果として「独自コンポーネント周りの課題を改善するコスト」よりも「MUIを導入し、独自コンポーネントから切り替えるコスト」のほうが小さいと判断したため、移行を決定しました。

当時のイシューについて

1. 独自性の不要なコンポーネントにも設計コストが掛かる（UIUX）

現時点でコンポーネント化されていない場合、いわゆる汎用的なUIであったとしても、ゼロから設計する必要がありました。独自コンポーネントのライブラリを築き上げていくためには必要なコストではあるものの、UIUXチームには開発スピードを速めるべき必要性がありました。

というのも、KiZUKAIでは要件定義フェーズからモックアップを作成したうえで検討する文化があります。そちらもUIUXチームが担当しているため、開発フロー内でボトルネック化しやすく、全体の開発スピードに影響を与えていました。

2. 独自コンポーネントが基礎的なUXに対応できていない（UIUX）

前述の通り、当時の独自コンポーネントはプロダクトのリリースを最優先とした設計です。代償として、基本的なマイクロインタラクションに対応できていませんでした。 （具体的にはレコード背景やアイコンのhover時、inputのfocus時など）

他にも独自コンポーネントは、エラー時のUIパターンが最低限しか対応できておらず、既存コンポーネントのエラーUIを再考する必要がありました。また、新規コンポーネント作成時にも「都度都度エラーパターンを検討し、オフショア開発チームに具体的なパターンを共有する」というコストが必要でした。

3. コンポーネントに対してのドキュメンテーションにコストが掛かる（FE）

実装背景のすり合わせをせず、独自コンポーネントの実装を依頼したところ、再利用性の低い実装となってしまうケースが生まれました。そこで、今後どのようにこのコンポーネントを使用するかを伝え、同時にドキュメンテーションによってナレッジ化しておく必要がありました。

しかし、グローバルな現場ではどの言語でドキュメンテーションするかについても議論が交わされました。

A）日本語ドキュメントからベトナム語翻訳の場合

• 日本語が修正されるたびに翻訳が必要
• そもそも意図が正しく伝わっているかが検証しづらい

B）英語ドキュメントだけの場合

• KiZUKAI側も英語ネイティブではないため、英語の品質が不安
• KiZUKAI、オフショア開発チームそれぞれで、キャッチアップに時間が掛かる

4. オフショア開発チームのデザインリテラシー不足（FE、オフショア）

UIUXチームのリソース上、すべてのパターンを明示したデザインデータを作らず、いくつかのパターンを省略したFigmaデータを共有していました。

結果として「要件を満たしていない」「KiZUKAI的には考慮してもらいたかったstateやエラーパターンの抜け」などが発生。コードの品質も低くなってしまい、コードレビューに時間が掛かっていました。

ここはまさに以前の開発スピードであれば、コミュニケーションで解決していた部分です。しかし、開発が加速したことによって、どうしても明示的に示す必要が生まれてしまいました。

「スタートアップ的なスピード感を保ちつつ、厳密なデザインデータを作る」ためのソリューションが求められました。

ベトナムのデザインについて

4つ目のイシューで、バッサリと「オフショア開発チームのデザインリテラシー不足」と断じてしまいましたが、実際にベトナムに行き、そこで得られた経験から少しフォローをさせてください。

「このUIからこういう挙動、UIパターンを想定して欲しい」という願望はそもそも難しい背景が、ベトナムには3点ほどあると感じています。

1. PC向けの多種多様なサービスが存在しない

以前、ベトナム人の開発者から「東南アジア諸国のインターネット史にWeb2.0が存在しない」と聞いたことがありました。Web2.0とは、いわゆる「掲示板、動画共有サイト」など、PCからアクセスが主流であったUGCを主とするプラットフォームのトレンドのことです。今でもベトナムの固定ブロードバンド普及率は20%にも満たない状況です。

一方でスマートフォンはというと急速に普及し、今では多くの人が日常的にインターネットを活用しています。いきなり、スマートフォン+SNSの世界が普及した東南アジア諸国は、日本とは違ったサービス様式を進みます。例えば賃貸情報について、ベトナムではSUUMOのようなものはなく、Facebookグループ上で直接大家さん/管理会社と情報交換するそうです。他にも、GoogleマップよりもFacebookページのほうが飲食店情報がヒットしやすい、といった状況です。

つまり「日本のように多種多様なWebサービスに触られる機会が少ない」「そもそもPCサイトも少ない」といった背景があるのです。なかなか、PC版UIの完成形をイメージしづらかったり、独自のUIを生み出しがちな理由が、ここからうかがえると思います。

2. グラフィックデザインの未成熟さ

２つ目の背景は「まだまだ開発途上国で、デザインが未発達」という点です。

あくまでも市中を歩いた感想ですが、グラフィックデザインなどの品質はまだまだここからといった印象を受けました。高品質なデザインに日常的に触れられる日本と、コモンセンスの差が生まれるのも無理はないと思います。

とはいえ、マウントを取るつもりはなく、そもそも日本もガラパゴスUIが残っていたり、「欧米と比べるとまだまだ劣っている」と言われますよね。ベトナムの成長速度を体感すると、すぐにデザインも発達してくるのではと思わざるを得ません。

3. オフショア開発がメインの風土

弊社のマインドとしては、オフショア開発チームもワンチームで取り組みたいと考えており、実際にベトナムを訪れてコミュニケーションを取っています。

ただ、ベトナム国内だけを見ると、どうしてもオフショア開発会社が主流なため、受け身となる風潮があるのではと感じています。指示をくださいというレスポンスに対して「どうしたら良いと思いますか？」と返信すると、状況に適した回答が返ってくることが多かったため、積極的に主体性を高める問いかけが重要だと感じました。

ソリューション

最後に「MUIでどのように変わったか」についてです。

1. 完成されたコンポーネントライブラリ

• MUIはFigmaのアセットとして、公式から「コンポーネントライブラリ」を提供されています。Figma上でのデザインは、一定程度までライブラリの組み合わせのみで作ることが可能です。
• また、公式ドキュメントにライブデモが用意されています。オフショア開発チームも、デモを見ることで完成イメージをノンバーバルで掴むことができ、結果として完成のレベルを引き上げることが出来ます。

2. 基礎的なUXが考えられたコンポーネントを活用

• コンポーネントをそのまま使ったとしても、基本的なマイクロインタラクション、エラーパターンが用意されています。特殊なエラーがあったとしても、既存のエラーUIを共通認識として議論することが出来ます。

3.英語で書かれたMUI公式Documentがある

• コンポーネントごとに重要な情報であるコード、デモ、どういった振る舞いをするかが英語でまとめられています。
• 公式として推敲された英語ドキュメントであり、世界的にも知名度の高いライブラリのため母国語でのドキュメントも充実しており、双方に共通認識を持った状態で議論することが出来ます。

4. Material Designというデザインバックボーン

• 正直、このメリットがMUIを導入するに至った最大の理由です。
• 他の多くのコンポーネントライブラリ（Ant D, Polaris, Chakra-UI…etc）についても、内手として検討しました。しかしながら、そもそもデザインというコモンセンスがズレている中で、互いに議論を進めるのは難しいと考えました。
• 実際、Material Design（以下、MD）というデザインガイドラインおよびデザインフィロソフィーのせいで、MUIが敬遠される現場もあると思います。しかし、私たちにとってはデザインの共通言語としてMDを取り入れることで、感覚のズレを平準化出来ればと思ったわけです。
• オフショア開発チームには「デザイン」という抽象概念を広範に説くよりも、MDだけに絞って会話することを考えています。
• 個人的にも様々な国を訪れたことで、より「国によってデザインの良し悪しの感性が違う」と強く実感しました。

実際に導入してみた結果

永山CTOによる「一部分からでも良いから、体験の良いUIを提供していこう」という英断により、一部の機能や設定画面からMUIへと移行されました。

実際に移行をしたことで、社内メンバーやユーザーからポジティブなフィードバックを受けており、UXが改善出来ている実感があります。

一方で、まだまだ開発スピードが向上したか、MDが浸透しているかといったところについては、検証と改善のフェーズにあります。MUIを導入したことによるイニシャルコストも掛かっているため、明確に「メリットが享受できていると言えるフェーズ」はまだ先になるはずです。

記事としてまとめるべく、MUIを「銀の弾丸」のように扱っていますが、これですべてのイシューが改善されたわけではありません。

まだまだ改修するべき余地は残されており、KiZUKAI開発チームは日々チャレンジを続けていきます！

最後に

お決まりですがKiZUKAIでは絶賛エンジニアメンバーも採用中です！ カジュアル面談も大歓迎です。お気軽にエントリーしてください。