この記事は「株式会社メンバーズ Jamstack研究会主催 Advent Calendar 2023」の14日目の記事です。

初めての方もそうでない方も初めまして、株式会社メンバーズ ポップインサイトカンパニーの早坂です。

弊カンパニーでは、モニター会員の皆さまのチカラをお借りして、取引先企業さまのユーザーリサーチをご支援させていただいております。
その中で私は、モニターさまや取引先起業さまが利用するリサーチ支援システムの開発やインフラ保守などを日々行っています。

はじめに

本記事は、Jamstackと内容が異なりますが、Atomic Designを取り入れたアジャイルなものづくりを実現するための設計体験と題して設計体験の良し悪しをお話できればと思います。

また、Atomic Designの本質的な詳細内容については、Brad Frost氏の著書「Atomic Design by Brad Frost」をご覧下さい。

良い設計体験とは？

UXを業務にされている方は聞き慣れがあると思いますが「体験設計」という言葉があります。
体験設計という言葉には様々な文脈が含まれていますが、CXDS 体験設計支援コンソーシアムでは次のように定められています。

ユーザーや顧客にとって良い体験を設計し運用することが「体験設計」であれば、エンジニアが組織やチームにとって良い体験を運用することを「開発者体験の良い設計（=設計体験※）」と表しています。

• ※ 開発者体験は一般的な言葉として定義されていますが、設計体験は一般的に普及している言葉ではなく、私が勝手に社内的に作った言葉として利用していますのでご容赦ください。

エンジニアを経験されている方であれば、事前にある程度の設計を済ませて開発し、時間経過とともに何らかの要求変更が入ったときに、基本的な設計部分を変更せずに今あるものをそのまま利用できたときの気持ちよさを経験したことありませんか？

あの「カチッとハマってくれた」というか、大規模な変更が無くスッと収まってくれる、シンデレラフィットのような感覚に近いのですが、あの感覚って普段の開発や業務の中で長期に渡って維持していけたら少しだけ幸せになれそうですよね。

私達エンジニアが行うものづくりの中で、こんな「設計体験」を少しでも維持しながら開発ができると、マーケットニーズ変化への柔軟な対応やビジネス成長を後押しするきっかけになるのではないかと感じています。

良い設計体験の難しさ

ですが、設計は時間経過とともに「大きく作り変える必要」が出てきたり、「別のところに似たインターフェースやメソッドが存在する」といったことは、リファクタリングが追いつかなくなってくると現実的に発生してしまうものです。

特にフロントエンドの領域では、コンポーネントといった共通部品が生まれやすい領域だと感じており、初期段階からある程度想定をつけて準備・設計をしていないとあちこちに似通った実装が作られてしまい保守・開発がしづらい状態を招いてしまいます。

当時の開発チームでも似た状態にはまっていたことがあり、なにかいい方法はないのかと探していたところ「これは今のチーム状況にとって良い選択肢ではないか？」と感じて取り入れたのがAtomic Designでした。

Atomic Designの良いところ

個人的に感じるAtomic Designの良いところは次の3つです。

• 定義された構成が5つと少ない

• ほぼすべての構成をコンポーネントに置き換えることができるので理解・認識を揃えやすい

• デザイナーとエンジニアの間で設計のズレが起きにくい

定義されている構成が5つと少ない

開発が進むに連れて、言葉の定義がどうしても膨れ上がってしまうことがありますが、もともとの定義が少数に抑えられていることで、途中からジョインしてくれるメンバーの学習コストが低くなることと、チームメンバー間の理解のズレが起きにくくなります。

もちろん、Atomic Designで定義されている言葉だけでは曖昧さが残る部分については、図解したものを残すなど必要に応じて取り組みますが、図解するものも最小限になっていきます。

ほぼすべての構成をコンポーネントに置き換えることができるので理解・認識を揃えやすい

Atoms =（最も再利用性が高い）コンポーネント、Molecules = （再利用性が高い）コンポーネント、Organisms = （再利用性は低いが、ビジネスロジックをまとめられる）コンポーネント...と、ほぼすべての構成をコンポーネントに置き換えて表現でき、5つの構成をそのままフォルダ構成として採択することもできるので、開発時のあるある「フォルダ構成悩む問題」や「フォルダ増えすぎ問題」を緩和することができます。

特にフォルダ構成は「目的の部品がどこにあるのか」自明になっていることで、重複実装といった問題を低減できるので、フォルダ構成をある程度縛れる点はメリットになりうると考えます。

デザイナーとエンジニアの間で設計破綻が起きにくい

最近ではスクラムを取り入れることで、職能ごとの隔たりは世間的には減ってきていますが、これまで私が経験してきた中で多かったのは「ビジネス要求の変更に伴って画面デザインが、他の設計よりも先に変更・確定する」ことでした。このような状態になってしまうと本来協力関係にあるはずの2者間で壁というか距離間が生まれてしまい、自然とお互いのことを尊重しづらくなる環境が生まれてしまいます。

仕事としてやるけど本当にいいものを作っていくことへの協力性や協調していくことが徐々に減り、能動的なチームから受動的なチームへと変わってしまいます。

Atomic Designを導入する際、事前学習をすることは必須になりますが、デザイナーの方と事前に共通認識を作ったり、時間経過とともにデザインと実装にギャップが生まれないようにするための手段として、Atomic Designは非常に強力だと感じます。

デザイナーとエンジニア、2者間の隔たりが可能な限りゼロになることで、UXとしての「豊かな体験設計」を生み出すことができ、エンジニア としての「心地よい設計体験」が生まれ、ビジネス要求の変化に柔軟に応えられるものだと感じています。

このような観点から、個人的にはありますがAtomic Designという設計思想がとても強力だと感じています。

Atomic Designの難しい点

Atomic DesignはClearn Architectureなどのレイヤー型設計思想に分類されるので、階層管理や依存管理が難しいと言った点がどうしても残ってしまいます。

そのため、Moleclesをどの程度まで依存性を高めておくか・許容するのか、Pagesをどのビジネスドメインで分類するのか、といった事前の決めが必要になってきます。

特に新規事業のようなゼロから作っていく場合、このような事前のキメを判断するのが妙に難しく頭を悩まされます。

他の設計思想はあるのか？

Atomic Designをベースに独自でデザインシステムを設計・運用されている方も増えている印象ですが、最近「あ、これも良さそうかも？」と感じたのは「Pagesをビジネスドメインと定め、Pages以下に必要なコンポーネントを集める」方法です。

まだ採択できるタイミングはないのですが、Atomic Designをベースにビジネスドメイン単位で集約させ、目的のものがどこにあるのかはっきり管理・運用できる点は共通認識を持ちやすくスッキリとした構成だと感じました。

マーケットニーズへとの相性は？

昨今のマーケットニーズの変化はビジネス成長のチャンスでありますが、マーケットニーズの変化に伴いアプリケーションやシステムも必然的に仕様や設計の変化を求められます。

VUCA時代と言われる変化の激しい時代だからこそ、ユーザーの変化、マーケットの変化、ビジネスの変化といったさまざまな変化が日々発生しています。

このような連続した変化に応え続けるには、Atomic Designのような設計思想はマーケット変化との相性がよく、開発チームにとっても重要な基準であり変化を楽しむ上で「設計体験」を高く保つことが重要だと考えます。

最後に

私個人がAtomic Desingを導入して感じたことは「エンジニアがフォルダや部品の構成を維持するためだけの方法論」ではなく「マーケットニーズの変化に俊敏性高く適応していくための設計方法」だと感じました。

最近ではAtomic Designから一歩踏み込んだ設計を見かけることが多くなりましたが、各社のサービス実態やチーム状況に合わせた内容になっており、非常に参考になるものが多くなっています。

この記事を読んで、今よりもっと良いチーム環境や文化づくりの後押しになれば幸いです。

以上で、「株式会社メンバーズ Jamstack研究会主催 Advent Calendar 2023」の14日目の記事とさせていただきます。

最後まで読んでいただきありがとうございました！