nrslib

「AtomicDesignとフロントエンドのインピーダンスミスマッチ」という LT をしてきました

「AtomicDesignとフロントエンドのインピーダンスミスマッチ」という LT をしてきました


なんだか耳に残る言葉、なぜか好きな言葉。
大した意味もなく、なんとなく好きな言葉というのはきっと皆さんにもありますよね。

もちろん自分にもそういった言葉はいくつかありまして、たとえば「インピーダンスミスマッチ」という言葉はそのうちのひとつです。

インピーダンスミスマッチは元々は電気工学の専門用語で電気の抵抗の不一致を意味しますが、転じて IT 業界では領域が異なるシステム間のギャップを指します。
ことソフトウェアにおいてはオブジェクト指向プログラミングとリレーショナルデータベースのギャップ（この二つは相性が悪いと一般的に言われています）のことをインピーダンスミスマッチと指すことが多いです。

このインピーダンスミスマッチは基本的にはあまりポジティブな意味ではありません。設計におけるギャップですからね。面倒ごとには違いないので、可能であれば避けたいところです。
しかしながら設計思想というものは領域により異なることが多く、どうしてもギャップが生まれがちです。
ある意味私たちは、この異なる設計思想間のインピーダンスミスマッチを埋めるべく、常日頃苦心しているようにも感じます。

そんなある意味憎らしい言葉であるインピーダンスミスマッチ。冒頭でお話したとおり自分はなぜか好きな言葉だったりします。
インピーダンスミスマッチ。
なんとなく呟いてみたくなったりしませんか。
インピーダンスミスマッチ。
呟きたくなってきたでしょう。

というわけでインピーダンスミスマッチという言葉を呟くために 2019/2/9(金) に「第２回AtomicDesignについて考える会（Link）」にて「AtomicDesignとフロントエンドのインピーダンスミスマッチ」という LT をしてまいりました。

イベント: 第２回AtomicDesignについて考える会(Link)
グループ: AtomicDesignについて考える会 (Link)

そのとき使ったスライドはこちらです。

さて、今回は LT という形でした。
それをふまえてスライドのページ数をご確認ください。

68 ページもあります。

今回の LT は 5 分なので、１ページあたりにかけることができる時間は約 5 秒。
正気かと疑いたくなりますね。


巻けばいけると思っているあたり、たぶん正気ではないです。

ただ、やはりその後危機感を感じたのか


思い直したようでした。

しかし２０分後に次のツイートが。


そして最終的には

少なくとも資料のせいではないと思います。

折角話すならアレもコレも。ご奉仕精神もとい情報を渡したいという欲求が強すぎます。

実際の LT では「プレゼンターに大事なことは、引きずり降ろされるまでマイクを離さないこと」とうそぶきながら必死で時間内に終わるように頑張りました。

さて、肝心の登壇内容なのですが、今回のテーマはタイトル通り AtomicDesign とフロントエンドのインピーダンスミスマッチです。
事前の参加者アンケートを拝見したところ、やはりどうすれば上手く実装できるのか、という点についての疑問が多かったので、今回のテーマはこちらにしました。

自分はもともとはゲームのクライアントなどのプログラムを書いていました。
ゲームのクライアントなどは Web と異なり html のようなものが存在しません。
画面に表示されるボタンなどの UI はデザイナーの用意した画像を用いて、実際に動作するパーツを自分で実装する必要があります。
つまり、何が言いたいかというと、コンポーネントのようなものは当たり前のように作らなくてはいけないのです。

反対に Web の世界ではどうでしょうか。
Web には html があります。パーツを作らなくても既存でボタンなどは存在しています。
元々パーツが用意されている関係上、それらのパーツを頑張って組み合わせれば、ソフトウェアを成り立たせることができてしまいます。
こういった背景が存在するので、Web 業界には比較的コンポーネントの文化が根づいていない印象です。

しかしながら、コンポーネントの力を上手く使いこなせば、再利用や保守性は向上します。
可能であれば取り入れたいところです。

では、どうすればそれを布教することができるか。

AtomicDesign は渡りに船でした。

AtomicDesign はコンポーネント指向に非常にマッチします。
特に Atoms が素晴らしい。
全ては Atom であるという考え。
全ての要素はコンポーネント。
これはコンポーネント指向の入り口です。

反面「五層であるとした」ところや「Templates の考え」はフロントエンドのプログラムにはあまりマッチしないと感じています。

層分けについてはスライド中でも２パターン紹介した通り Organism が Organism を包含するようなコンポーネントは関心の分離や再利用性の向上のためには必要になります。
Templates を用意し、そこにデータを流し込むことで Pages を完成させるというのは router-view などの昨今のフロントエンドフレームワークの機能にマッチせず非常に厳しい制約です。

ではなぜ AtomicDesign ではこれらの考えを押し出しているのかというと、それは「制限を加えなければ無意味なバリエーションを作ってしまう」という危険性を排除するためだと考えています。
つまり、あくまでもフロントエンドの技術ではなくデザインに対する考えなのです。

デザインという領域のための設計をフロントエンドという異なる領域に適合させようとすれば、そこにギャップが生まれます。
そう、つまりインピーダンスミスマッチです。

AtomicDesign とフロントエンドにはインピーダンスミスマッチが存在します。
AtomicDesign をそのまま適用しようとすると必ず壁にぶち当たります。
その壁を乗り越えるにはどうすればよいか。

フロントエンドの現実に適合させるように AtomicDesign の良いところだけ取り入れる。

これが私の結論です。
この結論をお伝えするために今回の登壇内容といたしました。
少しでも楽しめて、少しでもどなたかのヒントになったようであれば幸いです。
お疲れ様でした。

日記カテゴリの最新記事