Gaudiy Tech Blog

Gaudiyの技術、開発組織、カルチャーについてお伝えするブログです

エンジニアが改善に取り組んだ、スカウト運用のナレッジを公開

f:id:gaudiy:20211012111328p:plain

こんにちは。エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでバックエンドを担当しているkei(@kei32bit)です。

エンジニア採用は、どの企業も苦戦しているのではないかと思います。Gaudiyでも今年の4月頃から本格的にエンジニアのスカウト運用を始め、エンジニアと人事が協力して改善を進めてきました。

最初は苦戦していましたが、徐々に「どのようなスカウト文を書けば返信が返ってきやすいか」「エンジニアと人事でどう連携すると良いのか」がわかってきて、一時は週平均で20%近くまで低迷していたスカウト返信率が、ここ数週間は35〜50%にまで向上しています。(もちろん波はありますが、9月は月平均でも41%でした。)

そこで今回は、「採用に関わっていきたいけど、どう関わればいいのかわからない…」「スカウトの返信率を高めたい」といった課題感をもつ方々のご参考になればと思い、Gaudiyではどのようにエンジニアがスカウト運用に関わっているのか、具体的にどのような工夫をしているかを詳しくご紹介してみますご参考になれば嬉しいです!

1. リファラル中心→スカウト強化へ

Gaudiyは2018年5月の創業で、つい1年前までは全社で10名ほどの組織規模でした。現在は、フルタイムで22名、副業・業務委託も含めると35名ほどになっています。そのうちエンジニア比率は50%ほどで、これはフルタイムも副業メンバーも同じです。

創業初期から組織規模が10名くらいになるまでは、ほぼ代表のリファラルで組織を拡大してきました。ですが昨年の夏頃から大きな案件が増えてきて、事業拡大のスピードに組織が追いついていかない状況になり、エンジニア採用が急務になっていました。

そんな中、今年の4月からエンジニアのスカウト運用(媒体はYOUTRUST)を本格的に始めることになり、私も候補者リストのアプローチ判断からスカウト文の作成までを担当することになりました。

Gaudiyでは全員で採用活動をするカルチャーがあるので、一緒に働きたいと思うエンジニアの方を見つけてスカウトを送る、という一連のフローに携わっています。

2. テンプレ感の強かった初期の試行錯誤

ただ、前職のメガベンチャーでは採用業務に関わった経験はなく、どのようなワークフローでスカウトを送っているのかもわからないような状態からのスタートでした。

YOUTRUSTの「キャリアSNS」という特性上、転職意欲が高くてプロフィールが充実している方もいれば、そうではない方もいらっしゃいます。そのため、YOUTRUSTのプロフィールだけでなく、Twitter、GitHubなども確認してはいましたが、はじめの頃は「つよそう」「よさそう」といったなんとなくの雰囲気でスカウト文を出す/出さないを判断してしまっていました。

改めて当時自分が送っていたスカウト文を見返すと、テンプレート感が全面に出ており、返信したくなるような文面ではないと感じます。

f:id:kei32bit:20211012110254p:plain

当時の文章を再現(※宛先は弊社の人事です)

この頃は「しっかりめ / カジュアルめの文面パターンを試す」「Gaudiyのミッションから伝える」「スカウトを送る曜日・時間を変えてみる」といった試行錯誤はありましたが、どれもはっきりと効果がみえたものはありませんでした。

3. 改善の方針は、相手の価値観やWillに寄り添うこと

なぜ興味を持ってもらえないか。その原因は、以下の2つにあったかなと思います。

  • 候補者の価値観やWill(これから何をやっていきたいか)を理解できておらず、寄り添えていない
  • 候補者のWillに刺さるようなスカウト文に落とし込めていない

スカウトメッセージを受け取った方からすると、企業のビジョンやカルチャーと、自身の実現したい未来が重なることで初めて興味をもつはずです。少なくとも自分だったら、何ができるか(What)よりも、どう在りたいか(Will)に寄り添った文章の方が返信する気持ちになると思います。

そのための情報が把握できておらず、相手の心に刺さらない文章になってしまっていたことに課題があると考えました。

上記の仮説にもとづき、具体的にどのように改善したかを次からご紹介します。

4. 実際にどう改善したのか

まず前提の考え方として、Gaudiyが採用において最も重視していることはミッションやバリューへの共感です。そのため、Gaudiyのミッションやバリューに合いそうか / 興味をもっていただけそうか、に重心を置いてリサーチするようにしています。

もちろん技術力も大事ですが、技術スタックが多少合っていなかったとしても、Gaudiyの掲げているミッションとバリューに近い価値観を持っている方であれば入社後のキャッチアップで問題ないと考えているからです。そこで私が改善したのは以下の2点です。

4-1. 相手の価値観やWillを見つけ出せるリサーチ手法を確立する

候補者の方のアウトプット(ブログや取材記事など)をしっかり探すため、リサーチだけで1人につき大体10〜20分くらいかけるようにしました。 検索媒体についても、個人ブログ、Twitter、Github、Qiita、Zenn、YOUTRUST、Wantedly、 connpassのイベント参加履歴、所属してる企業の採用ポリシー etc...あらゆるものを活用しています。

というのも、媒体ごとに情報の特性が異なるので、いろんな角度から情報を拾ってくるイメージです。

たとえばGithubにDDDのサンプルコードがあったらドメイン駆動開発に興味がある方だとわかりますし、Qiitaにプロジェクトマネジメントの記事があったらエンジニアリングだけでなく、プロダクト開発手法にも興味がある方かもしれません。こうしたキーワードが見つかると、候補者の方が将来目指してるキャリアを仮説立てることができます。

またTwitterでは、つぶやきから興味関心がわかることがあるので「from:{アカウント名} おもしろそう」「from:{アカウント名} 書いた」といった検索をすることもあります。

一方で、中にはブログやSNSでのアウトプットがほとんどない方もいらっしゃいます。そういう場合には、所属企業の採用ポリシーや求人を参考にしていました。そこに所属している候補者の方も、おそらく近い人物像であることが伺えるからです。たとえば求める人物像に「エンジニアリングの枠だけに捉われず課題解決という目的を達成できる方」などがあれば、このような価値観を持っている方だと仮説づけることもできます。

こうしたリサーチを徹底することで、候補者の方のWillや価値観がわかり、スカウト文に入れたい情報を揃えることができるようになりました。

4-2. スカウト文では、WHY YOUとWHY MEをリンクさせる

次に、魅力に感じる部分を言語化した上で、どうスカウト文に落とし込むかも非常に重要です。実際に、リサーチを手厚くして魅力的に感じる部分を詳細に書けるようにはなったものの、スカウト返信率がなかなか改善しない時期がありました。

そこで人事の山本さんと作戦会議を行い、YOUTRUSTさんにいただいたアドバイスを参考にする形で、 WHY YOU(なぜあなたなのか)だけでなくWHY ME(なぜGaudiyなのか)に紐づけることを意識してみることにしました。

  • WHY YOU・・・なぜあなたなのか?どのようなWillや価値観を魅力に感じているかを伝える。
  • WHY ME(Gaudiy)・・・現状Gaudiyが抱えている課題を伝え、解決に向けて一緒に取り組んでいきたいことを伝える。

相手の魅力に加えてGaudiyの課題感を正直にお伝えすることで、「なぜあなたじゃないとダメなのか」という点において納得感を持たせることができます。

以下は実際に今の自分がスカウト文を出すとしたらこんな文章を書きます、という例になります。ここでは弊社のエンジニア宛にスカウト文を作成してみました。

f:id:gaudiy:20211012112324p:plain

弊社エンジニアを対象に書いてみたスカウト文の例

スカウト文のドラフトを自分が作成し、人事の山本さんに表現の修正や読みやすく編集をしてもらった上で送付する、という役割分担もうまく回っていたと思います。

5. エンジニア全員に向けてノウハウを水平展開へ

こうして気をつけるべき点の言語化ができてきたので、現在はエンジニアが誰でも質の高いスカウトメッセージを送れるように、ノウハウの水平展開に注力しています。

主な取り組みとしては、以下2点です。

5-1. 過去に返信が来たスカウト文やリサーチ方法をデータベース化

Notionで過去に返信がきたスカウト文や、候補者のWillを探るためのリサーチ手法をまとめてNotionのナレッジデータベースに蓄積することで、他のエンジニアもスカウト文が書きやすい環境を整えています。

f:id:kei32bit:20211007211839p:plain

Notionにナレッジを蓄積

5-2. スカウト文の質担保のため、リサーチコメントをテンプレ化

リサーチ時にどんなWillに着目したのか、どういう観点でGaudiyの文化と相性がよいと思ったのかを言語化しておくことで、スカウト文が書きやすくなります。

人によって観点が抜け漏れないように、リサーチコメントのテンプレートを作成しました。

f:id:kei32bit:20211007212643j:plain

スカウト文に含めたい情報をテンプレ化

このような工夫を取り入れて、エンジニア全員が採用に参加する仕組みづくりを推進しています。

6. さいごに

今回はエンジニアのスカウト改善についてお伝えしました。なにかしらご参考になれば嬉しいです。

GaudiyではDAO(Decentralized Autonomous Organization:自律分散型組織)の思想のもと、プロダクト開発と同じように組織開発においても全員で向き合っています。

まだまだ理想には程遠く、日々みんなで改善している途上なので、もっと良い方法があったらぜひ知りたいですし、私たちとしても常に改善を続けて新しい学びをまたシェアできたらと思っています。

課題はたくさんあるけれど、全員でコトに向き合えるチームですので、少しでも興味持ってくださった方はぜひお話ししましょう!エンジニア採用の情報交換もぜひ。

meety.net

毎週水曜に、オープン勉強会なども開催してますので、こちらもよろしければ!

www.notion.so

Gaudiyの技術スタックと選定における思想

f:id:takuya510:20210917223149p:plain

こんにちは!エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiy共同創業者の後藤(@PTeamd)です。

Gaudiyでは、ファンエコノミーの実現をめざして、ブロックチェーンを活用したファンコミュニティサービスなどを開発・提供しています。ブロックチェーンは事業価値を高める上でのコアな技術ではありますが、他にも様々な技術や開発手法を使っています。

今回はその技術選定における思想と、実際にGaudiyで採用しているアーキテクチャや技術スタックについて詳しくご紹介したいと思います。

Gaudiyで働くことに興味を持っていただいている方のご参考になれば嬉しいです!

1. Gaudiyの事業概要

多くの企業がそうであるように、私たちが採用する技術スタックや開発プロセスは、私たちの事業と密接に紐づいています。

Gaudiyでは、エンタメ企業に対して、独自のファンエコノミーを構築できるプラットフォーム「FPaaS(Fan Platform as a Service:エフパース)」を提供しています。

f:id:gaudiy:20210917174512p:plain

具体的にいうと、現在は以下3つのプロダクトを開発しています。

  • ファンコミュニティサービス
  • NFTなどを活用した新しいエンタメ体験、ソリューションサービス
  • ファンの活動を記録・蓄積する分散型IDシステム

Gaudiyの事業領域となるエンタメコンテンツ業界の特徴は、ステークホルダーの多い業界構造にあります。

たとえば、弊社が関わっているプロジェクトのひとつ、週刊少年ジャンプの人気漫画『約束のネバーランド』のコミュニティサービスでは、マンガ原作の集英社、アニメ制作のアニプレックス社、映画制作の東宝など、IPを取り巻く多数の関係者が存在しています。

また、ビジネスモデルとしてはBtoBtoCなので、クライアント(IP関係者)の要件を満たすだけでなく、ファン(エンドユーザー)にとって最高の体験を届けることが重要です。

そのため、ブロックチェーン技術を活用して顧客の課題を解決しながらも、ファンにとっては「ブロックチェーン技術を意識させない」良い体験づくりが事業のコアになっています。

2. 技術選定における意思決定の軸

こうした特性をもつ事業価値を最大化するため、Gaudiyでは以下の軸で技術選定を行っています。

  • コラボレーションを促せるかどうか
  • 仕様や要件の調整を、柔軟かつ低コストにできる仕組みか
  • 枯れた技術ではなく、将来性のある技術かどうか

f:id:takuya510:20210917223118p:plain

2-1. コラボレーションを促せるかどうか

まず前提にあるのは、開発というプロセスを通じて、あらゆるステークホルダーの「コラボレーション」を促せるかどうかです。

というのも、Gaudiyの事業特性上、エンタメ業界のDXに取り組む上では、業界や企業、組織、案件の単位で、さまざまな個別の要望が生まれます。そのため、単発の機能開発スピードを高めるよりも、そうした各方位の要求をどこまで考慮し、取り入れられるかが、事業価値を高めます。

ここで意識しているのは、DXという形で理想的な技術活用をめざしつつも、技術的な理想だけを追求してしまわないようにすることです。

技術選定の上では、特定の技術がどのような思想や歴史的背景で生まれているか、それがコラボレーションを重視する文脈に位置しているかを最も重要視してます。

それにより、技術的な理想を追求していったとしても、クライアント、ユーザー、開発者、デザイナーなど各ステークホルダーの視点を欠いたエンジニア組織にならず、プロダクトづくりの理想的なワークフロー構築に自然とつなげることができます。

2-2. 仕様や要件の調整を、柔軟かつ低コストにできる仕組みか

次に、コラボレーションを土壌として、そこで得られた様々なステークホルダーから求められる要件やワークフローに対して、柔軟に対応できる仕組みかどうかを重視しています。

社内のDXや、先端技術であるブロックチェーンを扱う事業では、単にプロダクト開発を進めるだけでなく、社内の規定や法務などのルールメイキングを同時に進めなければ着手ができないような案件もあります。

そのため、事業戦略上、クライアントとともに「時代を進める」ような取り組みを推進するためには、さまざまな特殊な障害を乗り越えるために、仕様の調整や拡張がしやすいシステムを構築できるかがカギとなります。

もちろんプロダクト全体のバリューとしては個別最適ではなく、レバレッジをどれだけ効かせられるかを意識して開発を行っていますが、多くの企業をDXに巻き込んでいくためには柔軟に対処する力が大事になります。

2-3. 枯れた技術ではなく、将来性のある技術か

上述した思想を踏まえた上で、必ずしも枯れた技術を優先するわけではなく、現時点ではまだ未熟でも、理想的な思想・性質を持っている技術かどうかを重視しています。技術はあくまで "手段" なので、新しい技術にこだわることは本末転倒です。

しかし、採用事例の多さや技術の経験者が多いなどの理由だけでは、選定すべきでないと考えています。それよりも、理想的な性質を備えている技術・フレームワークは、たとえ実用上の課題があったり、学習コストが高かったとしても、自分たちで実用方法を開拓するようにしています。

では次に、開発システムの全体像や、アーキテクチャ、技術スタックについてご紹介していきたいと思います。

3. 開発システムの全体像

f:id:takuya510:20210917223252p:plain

はじめに、全体の構成を簡単にご紹介すると、フロントエンドはReact × Next.js × Typescript、バックエンドはGo言語を使用しています。

またBFF(backend for frontend)にはGraphQLを導入しており、そのシステムではフロントエンドの開発者が柔軟に扱えるようにTypescriptを採用しています。

4. アーキテクチャ

4-1. マイクロサービス化

Gaudiyでは、マイクロサービスでバックエンドを構築しています。

背景としては、Gaudiyの提供するコミュニティアプリは、提供する機能が多いことや、クライアントの既存サービスに合わせてさまざまな拡張性に対応し、柔軟に入り込めることが事業価値に直結するため、スタートアップの規模感であったとしてもマイクロサービスとの相性が良いです。

ただ実際、マイクロサービスの採用には賛否あるとは思います。ECサイトやSNSなどのC向けのサービスや、同一の汎用的な機能を広く提供するようなSaaSの場合は、プロダクトの中で使われている機能が組み合わさって全体が成立していることが多く、個々のサービスが疎結合である必然性が少ないケースが多いと感じています。

一方、Gaudiyが提供するサービスは、個別のIPにそれぞれカスタマイズ可能なファンコミュニティのシステムを提供しています。決済サービス・チケッティング・動画配信・ゲームアプリやファンクラブとの連携など、それぞれの依存関係を排して柔軟に提供したいという背景から、マイクロサービスを採用しています。

またスピード感を求めつつも、小規模な組織でマイクロサービスを行うために、コストの高いk8sではなく、CloudRunを採用して規模の拡大に伴って移行できる体制にしています。

さらに、そのマイクロサービス間をスキーマ駆動開発で進めることで、マイクロサービス間の開発やフロントエンドとの間におけるドキュメントなどの作成を減らしています。開発着手前に仕様のコラボレーションを行うことで、不要なコミュニケーションコストを下げています。

4-2. monorepo化

マイクロサービスを推進するため、シングルレポジトリ構成のmonorepoを採用しました。マイクロサービス化によって自律分散的な開発を実現しつつも、そのデメリットとして、ナレッジや運用ルールなどの統一性がなくなってしまうという問題が生じ得ます。そこをmonorepo化することで、コード、思想、言語、記述の仕方などが共通化しやすいといったメリットがあります。

さらに、レビューする人が増えたり、担当領域外の開発の可視化にもつながるので、よりコラボレーションを意識できる環境になっています。

5. 技術スタック

ここからは、各領域で採用している技術スタックをご紹介します。

5-1. React × Next.js × Typescript × Tailwind

■PWA

f:id:gaudiy:20210918145400j:plain

まず前提として、ユーザーが利用するアプリケーションは、Web上でアプリのような体験を提供できるPWA(Progressive Web Application)によって構築されています。

その背景としては、日本のエンタメコンテンツ事業者のプラットフォーム依存という問題を解決し、エンタメIP自体がプラットフォームとなる「ファン国家」の世界観を実現するためです。

iOSやAndroidのネイティブアプリを利用すると、どうしてもプラットフォーマーによる制約を受けることになるため、創業当初から理想的な技術としてPWAへの投資を続けていました。

現時点では、iOSでプッシュ通知が行えないなどの制約はありますが、自分たちでより良いやり方やUXの向上を通じて理想的な状態をめざしています。

■ React × Next.js × Typescript

f:id:gaudiy:20210918145418j:plain

Web上で柔軟に拡張性の高いアプリを構築する上では、Next.jsは最適な選択でした。もともと2018年の4月頃から、フロントエンドの設定などの煩雑な項目を廃しつつ、SSRなどの高度な機能が簡単に行えるという理由から採用していました。現在ではISRなどの機能も増え、ますます魅力的な選択肢かと思います。

■CSSフレームワーク:Tailwind

f:id:gaudiy:20210918145433j:plain

Webアプリの場合、ネイティブアプリとは異なり端末ごとに最適化されたネイティブUIが基本的には存在しません。そのために、1つ1つのパーツや、動作のインタラクションやUIを組む上での原則を作成、すり合わせて、高品質なものを担保できる状態を作ることが重要です。

そこで、デザイナーとエンジニアのコラボレーションを促進しつつ、品質の高いUIを安定的に組めるデザインシステムの構築を重視しています。

ユーティリティファーストであるTailwindは、Storybookなどでコンポーネントの管理をして使い回しをするよりも、さらに細かい粒度でデザインルールを実装に落とし込むことが可能であり、共通言語を作り上げる基盤的な役割を果たしています。

5-2. BFFとしてのGraqhQL

f:id:gaudiy:20210918145911p:plain

マイクロサービスを構築する上で、BFF(backend for frontend)をAPIゲートウェイとして活用することで、フロントエンドとバックエンドの連携をスムーズにしています。

言語としてはGraphQLを利用しているほか、こうしたクライアントとサーバーの両者を一貫して開発できるようにするために、Apollo Server&Apollo Clientを採用しています。

元々、フロントエンドとバックエンドでAPIインターフェイスの認識齟齬が発生することから手戻りが起こり、開発効率を下げているという課題があったため、GraphQLの導入を決めました。graphQL codeGen スキーマからtypescriptの型を生成することで、認識齟齬を減らしています。

この導入によってパフォーマンスが上がり、APIのレスポンス定義もエンジニア全員が随時アップデートしていくという開発スタイルが根づきました。また、スキーマを確認する会にプロダクトオーナーが同席することで、ドメイン知識を反映させるようなことも可能になりました。

さらに、コミュニティ毎に異なるカスタマイズ性なども、BFFが機能の出し分けを吸収することでフロントエンドでの複雑性を削減しています。

Gaudiyでは、特定のIPコンテンツのサービス同士をブロックチェーンを活用してつなぐDID(分散型ID)が存在していますが、最近ではGraphQL Composeを利用し、他社のサービスとの連携を行う場合などに、個別にバリデーションをかけるなどセキュアな体制を作る上で役立てています。

5-3. KotlinでDDDを推進

f:id:gaudiy:20210918145514j:plain

DDDの導入に合わせて、Kotlinを利用したサーバーサイドの構築を進める方針を採用しています。

ドメインエキスパートとエンジニアのコラボレーションを、業務フローでどう実現するかという課題がありましたが、バックエンドの設計はプロダクトの拡張性を根本から規定するにもかかわらず、非エンジニアが関わることが難しい領域でした。

そこで、DDDのドメインエキスパートのメンタルモデルを反映するという戦略的設計に取り組み始めました。

こうした社内の開発文化を強化し、導入を浸透していく上で、DDDの実践が行いやすいJavaベースの言語で、かつ導入事例はまだ多くはないものの開発者体験(DX)が良好なKotlinを採用することにしました。

(もちろん、要件に応じてサッと組みたい場合や、フロントエンドのメンバーが密に関わる場合などは、学習コストや記述のコストが低いGoNestJSを採用するなど使い分けもしています。)

5-4. Quorum(ブロックチェーン)

f:id:gaudiy:20210918145537j:plain

ブロックチェーンには、管理者が存在しない「パブリックチェーン」(ex. イーサリアム)と管理者が存在するプライベートチェーンの2種類が存在しますが、Gaudiyではプライベートチェーンを選択しています。

この主な理由は、著作権などの権利が絡むIPコンテンツ(知的財産権)に対して、パブリックチェーンを最初から本格的に導入することは、導入実績や権利関係の調整などの点から困難なことがあります。

しかし、私たちの理想とする「ファンの熱量が評価・還元される経済圏の実現」にあたっては、パブリックチェーンベースによる経済圏は実現すべきミッションだと考えています。その軸を、目先の事業機会や制約によって安易に流されることなく、理想的なシステムを常に追求し続ける意味で、通常のデータベースではなくパブリックチェーンを前提とした開発をめざしています。

Quorumは、今もっとも使われているEthereumをベースとしたプライベートネットワークを構築できるため、パブリックチェーンへの切り替えを視野に入れたノウハウの構築やプロダクトへの投資が実現できます。

現時点でも、パブリックチェーンで問題となる秘密鍵の管理やトランザクションなどを回避し、テクノロジーに詳しくない「エンタメのファン」でも快適に楽しめる設計を現在進行系で行っています。

また、KaleidoというフルマネージドのBaaS(Blockchain as a Service)を採用しています。Nodeの運用が不要になるほか、ブロックチェーンエクスプローラーやイベントフックの開発などもwebhookで提供してくれるなど、AWSと比べても高機能なサービスとなっています。

6. まとめ

今回は、Gaudiyの事業特性をふまえて、技術選定における思想や、各領域の技術スタック、アーキテクチャについてご紹介しました。

文中にも書きましたが、Gaudiyの事業価値を高めるためにはコラボレーションが重要であり、そのような開発を推進するには、個人がただ技術や手法を取り入れただけでは実践できないため、周囲の理解が必要です。

その点、Gaudiyでは、全員参加の輪読会で「エンジニアリング組織論への招待」を読み、アジャイルへの理解を深めたり、DDD勉強会が開催された際にはコーポレートなども含めたメンバーが参加したりと、全社でそのカルチャーを強めています。

全員がプロダクトに向き合う環境で、ともに時代を進めていく仲間を募集していますので、少しでも興味を持ってくださる方は、ぜひ気軽にお話ししましょう!

youtrust.jp

meety.net

www.notion.so

DDDを試行錯誤しながら実践するチームの学びをまとめてみた

f:id:kei32bit:20210910165752p:plain

こんにちは!エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでバックエンドエンジニアをしている椿(@mikr29028944)です。

Gaudiyは、まだエンジニア10名、デザイナー2名ほどの開発チームですが、今年の6月からDDDと呼ばれるドメイン駆動設計を開発に取り入れました。

DDDとは、一言で言うとドメインエキスパートと呼ばれる担当業務やシステム設計に最も詳しい人と、エンジニアが共創してソフトウェアを開発する手法です。

今回は、DDDを実践する中での気づきや学び、躓きやすいポイントをどのように乗り越えてきたかについて、ご紹介してみたいと思います。

DDDを検討しているチームや、導入して間もないチームのご参考になれば幸いです!

1.なぜDDDを導入したのか

Gaudiyでは元々、アジャイル開発を進めており、繰り返し小さくサイクルを回していくことで品質の高いプロダクトを作る、という開発スタイルを実践してきました。

また、エンタメ企業に対してブロックチェーンを活用したファンコミュニティサービスを提供している事業特性上、扱うドメインがかなり広いかつ複雑で、追加での機能開発が入ることも多いのが特徴です。

そうした中で、ドメイン知識のある人に開発者がヒアリングして実装する、という進め方は以前から個別では行われていましたが、それを体系的に行う開発スキームがなく、実際にドメインエキスパートと開発者の間で認識齟齬が生まれてしまうことも度々ありました。

そうした中で、コラボレーションを促進し、価値提供する対象のメンタルモデルを探った上でプロダクトの品質を高めていくため、2021年6月にDDDを導入することにしました。

DDDは、ドメインエキスパートがもつ知識をプロダクトに関わる全員がしっかり理解・共有するのに、とても優れたフレームワークだと感じています。

2.GaudiyではどのようにDDDを取り入れているか

DDDには、よく「戦略的設計」と「戦術的設計」と呼ばれる手法がありますが、その本質は、ドメインを理解して適切にコードに反映することで、事業価値の高いソフトウェアを開発することにあると思います。

Gaudiyでは、ドメインエキスパートに対するヒアリングからドメインモデルをつくり、それをソフトウェアの実装に反映する、といったDDDの一連の流れを取り入れています。

特に、ドメインの不確実性が高かったり、複雑なものであったりする場合は、率先してDDDを行うようにしています。逆に機能要件がシンプルでわかりやすいものは、DDDを行わないこともあります。

例えば、ある新機能の開発では、以下のようなチームでドメインモデリングを行いました。

  • ドメインエキスパート:プロダクトオーナー
  • 参加者:Bizメンバー2名、デザイナー1名、エンジニア5名

進め方は、一般的なDDDと同じく、まずはユースケースを全員で洗い出し、その全ケースを実現するための理想的なドメインモデル図を話し合います。ユースケースに基づいて、様々なステークホルダーの視点から質問していくことで、ドメインエキスパート自身も言語化できていなかったことがクリアになっていきます。

f:id:gaudiy:20210910124323p:plain

フォロー機能のドメインモデル図

ドメインモデルを作ったあとは、それをどうソフトウェアで実現するかを話すため、ユビキタス言語やドメインモデル図をもとにコミュニケーションを取りながら、実装コードへと落とし込んでいきます。

Gaudiyでは、バックエンドにNestJS(TypeScriptのフレームワーク)やGoを採用しており、オニオンアーキテクチャ構成を取り入れています。

f:id:gaudiy:20210910144751j:plain

オニオンアーキテクチャ構成

この一連のフローにおいて大事だと思うのが、ドメインモデルをつくるところに必要以上に工数をかけすぎず、ヒアリング→ドメインモデルの作成→実装のサイクルを細かく回すことです。

というのも、ドメインエキスパートが最初からすべてを話せるわけではないし、実装側としてもモックベースで一度作成してから、「こういうフローが必要だよね」「ここの処理どうする?」といった議論に展開しやすいからです。

その中でモヤっとしたら、ドメインエキスパートに再度ヒアリングして、ドメインモデルとコードをアップデートしていく方法が進めやすいと思います。

3.DDDの実践で生じた課題と乗り越え方

DDDを導入したことで、以下のようなメリットが得られました。

  • ステークホルダー間で共通言語ベースのコミュニケーションが生まれることで、ドメインへの理解・学習が効率的にできる
  • 頻繁な変更に耐えうる拡張性や保守性が高いソフトウェア設計が行える
  • 全てのコードがドメインの翻訳になる
  • コアドメインを理解し、ビジネス価値を最大化できる
  • 多角的な視点からドメインの新たな要素の発見やドメイン同士の重要な関係性を見出すことができる

一方で、チームの学習コストの高さや、モデリング実装の難しさ、抽象化と作り込みの問題など、さまざまな課題も感じています。

ここからは、実際にぶつかった課題と、そのときチームがどう行動したか、そこから何を学んだかを紹介したいと思います。

3-1.チーム全員でDDDを学習する

DDDでは、エンジニアだけではなくBizメンバーも含めてプロダクトに関わる全員が、以下のようなことを学ぶ必要があります。

  • ドメインモデリングの手法
  • ドメインエキスパートのメンタルモデルを探り、言外の背景まで引き出すスキル
  • チーム全員がドメインについての理解を深めるマインドや姿勢
  • アーキテクチャ設計やソフトウェア設計原則の理解

これを全員でキャッチアップする学習コストはかなり高いですが、僕たちのチームでは、以下の方法でキャッチアップしていきました。

3-1-1.外部講師を招いた

DDD界隈で有名なログラスの松岡さん(@little_hand_s)をお招きして、自分たちが普段扱っている開発のドメインを題材に、DDDの実践方法を教えていただきました。

オンラインでDDD勉強会を2回ほど開催いただき、実際にユースケース図の書き起こしからドメインモデリング、実装までの一連の流れを実演いただきました。

この勉強会を通じて、どのようにドメインエキスパートのメンタルモデルを探り、知識を引き出すことができるかを知ることができました。

f:id:gaudiy:20210910125835p:plain

エンジニアだけでなく、Bizメンバー、デザイナーも全員参加したDDD勉強会

自分が一番学びがあったのは「ドメインエキスパートへのヒアリングの仕方」でした。参考になった質問を以下に記載します。

  • このオブジェクトに足りない要素は他にはないか
  • この時のユーザーの状態はどういうものがあるか
  • オブジェクトの具体的な例が知りたい
  • キャンペーンとは期間限定のものなのか、それとも恒常的に開催されてるのか
  • このAオブジェクトとBオブジェクトの関係性はどうなのか
  • このクラスのルールや制約はどのようなものが存在するか
  • 強い整合性を表す集約の範囲はどうするか、それとも一旦実装してから検討する方が良いか

特に「このクラスのルールや制約はどのようなものが存在するか?」
という質問はプロダクト視点で「このサービスで何を実現したいのか」を言語化できる、非常に重要な質問だと感じています。

たとえば「キャンペーン中のミッションをすべて達成した場合に何か副作用がありますか?」というドメインのルールを質問することで、ドメインエキスパートから「実はフルコンプリートミッションというミッションを考えていたのでそれも考慮した設計にしたいです」という発言を引き出せました。

上にも挙げましたが、ドメインエキスパートが最初から何でも知っているというわけではない、という前提に立って、ヒアリングをする姿勢が大事になります。

3-1-2.DDDの書籍や記事、登壇資料などを読み漁る

書籍を読むことで理論を学びました。以下に、学びが多かった書籍を載せます。

booth.pm

最初にこの書籍を読みました。戦術的アプローチ・戦略的アプローチの違いから、モデリング→実装に落とし込むまでの流れがとてもわかりやすく説明されています。

また、ところどころにDDDでつまずきそうなQ&Aが記載されており、DDD初心者でも最後まで読み切れる構成になっています。

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法(増田 亨)

こちらもドメインモデルの設計方法が手厚く書かれている良書です。またドメイン知識の重要さについての記載もあり、ドメインエキスパートとエンジニアの共創が非常に大事だと改めて実感できました。

さらに書籍だけでなく、DDDの記事や登壇資料を読み漁りました。

特に参考になった記事や資料は、以下になります。

tech.readyfor.jp

little-hands.hatenablog.com


3-2.モデリング実装に実際にどう落とし込むか?

また、ドメインモデル図を作成できても、それをどのようにソフトウェアに実装するか?も実際にやってみると難しかったです。

この際も、外部講師の松岡さんにチャットサポートしていただき、Slackでどんどん質問しました。

f:id:gaudiy:20210910124357p:plain

#ask_ddd_room での質問

DDD導入直後は、モデリングから実装に落とし込む際の懸念などを活発に質問することで、わからないことをわからないまま放置せずに理解を深めました。

後から振り返ってよかったことは、質問することで思考回路が言語化されるということです。

これにより、チームでDDDの振り返りをする際に「どういう判断基準が良かったか」「どういう進め方に改善の余地があるか」といったネクストアクションにつなげることができました。

3-3.「早すぎる抽象化」による不必要な開発の問題

ドメインモデル図の作成では、「いずれこういうユースケースにも対応したい」「きっとこういう使われ方をする」といった未来のユースケースを想定することもあります。結果として抽象化されたドメインモデル図から、いま不必要な開発までしてしまうことがありました。

不必要な開発をした結果、自分たちのチームでは以下の負債が発生してしまいました。

  • 複数のパターンに耐えうる汎用的な機能はあらゆるケースを包括的に対応できるが、そのケースが将来存在しなかった場合には、コードが負債に転じる
  • 不必要なコードが積もると、後からコードを修正する人がその複雑なコードを扱わなければならない、それよりは追加実装するほうが速い、などの理由で重複したコードが作られる

実際に、週刊少年ジャンプの漫画「約束のネバーランド」の展示会で、アプリでQRコードをかざすとNFTが受け取れる、という体験を開発した際、複雑で不確実性の高いドメインを扱う必要がありました。

コミュニティ内のあらゆる諸条件と、コミュニティ外でのユーザーの活動があり、無数の条件の組み合わせがある中で、複雑なユーザーの状態をあらゆるドメインから情報を集めて、判定を行わなければならないといった状況でした。

さらにNFTに関しては、メタデータを参照するケースも今後は増えてきたり、条件クリアのアイテムを付与するために外部APIやBlockchainとの通信、DBの更新を行わなければならないケースだったりと、様々なケースがありました。

そんな状況下、モデリングしたはいいけれど、将来起こりうる仕様拡張を考慮しすぎて汎用化させてしまった結果、コードを作り込みすぎてしまい、結果的に今も使われてない実装が残ってしまっています。

この反省を踏まえて、汎用的なドメインモデルを扱う際に、不必要に作り込まれたコード実装に陥らないよう、Gaudiyでは「早すぎる抽象化(早抽)」というパターン・ランゲージ(※)を作りました。

パターン化したことで「これって過去に失敗したモデリングの方向に向かってしまっている...?」と、レビュー時などに気付けるようになります。

※パターン・ランゲージとは、組織の中で暗黙知になっている行動様式(パターン)を言語化したもの。過去の複数事例に共通する性質を抽出することで、同じ問題が発生した場合に対処できるよう活用しています。

f:id:gaudiy:20210910124435p:plain

日常的に意識されている「早抽」

また、個人的には以下が大事だなと学びました。

  • 単一責任原則や高凝集・疎結合を意識し、適切なモデリングを行い、適切なタイミングで抽象化を行うことで「誤った抽象化」を防ぐことができる
  • 「仕様は変化し、その将来の姿は予測できない」という現実を受け入れる

一方、逆に「早すぎる抽象化」を意識しすぎると、今度はユースケースの幅を狭めすぎてしまって作り込み不足に陥るという事態も発生してしまいます。

作り込み不足で進めてしまうと、のちにリファクタリングが必要になり、保守・運用が難しくなってしまうため、その解決策のひとつとしてテスト駆動開発(TDD)を取り入れています。

また受け入れテスト駆動開発(ATDD)を導入することで、事前にドメインエキスパートとエンジニア達で決めたユースケースが満たされてるかを確認する方式を取り、作り込み不足になっていないかを確認しています。

4.おわりに

まだまだDDDの実践を始めたばかりではありますが、基本原則を守破離の「守」で学びながらも、自分たちのチームにあうやり方を模索していきたいと思っています。

また今後、DDDでソフトウェアをアップデートをしていく上では、以下のマインドと行動を継続的に実践して、DDDをブラッシュアップしていく予定です。

  • 上述した「早すぎる抽象化」「作り込み不足」などに気をつける
  • ドメインエキスパートへのヒアリングを通じて設計が再構築されるサイクルを回す
  • パターン指向リファクタリングなど、デザインパターンを使って設計を改善する

また、DDDの社内勉強会を開催して、エリック・エヴァンスの書籍もみんなで読んでいきたいと思っています。

もしこの記事を読んで、少しでもDDDの話を聞いてみたい!などご興味を持っていただけたら、ぜひお話しましょう!

meety.net

Gaudiyの技術選定については、こちらの記事をご参考ください!

techblog.gaudiy.com

毎週水曜、オープン勉強会も開催しています!

www.notion.so

未経験から1年でキャッチアップしたブロックチェーンの学習法をまとめてみた

f:id:gaudiy:20210902104804p:plain

こんにちは。エンタメ業界のDXを進めるブロックチェーンスタートアップ、Gaudiyで主にバックエンドを担当しているkei(@kei32bit)です。

自分がブロックチェーン技術をキャッチアップし始めたのは1年ほど前です。最初の半年間くらいは趣味として、その後はブロックチェーン企業に入って仕事でもブロックチェーンに触れるようになりました。

もちろん全部を理解しているわけではないですが、次に来そうなブロックチェーン技術を予測したり、自分なりにテーマ課題を立てて調べたりできるようになりました。

(以前投稿した記事) techblog.gaudiy.com

本記事では、この1年間で自分がどういう情報ソースを元にブロックチェーンを勉強したかを紹介したいと思います。

今からブロックチェーン技術をキャッチアップするエンジニアの方々にとって、自分のキャッチアップの方法がご参考になれば幸いです。

1. 良質なインプットで理論を固める

「ガベージイン・ガベージアウト」というシステム用語がありますが、キャッチアップが早くても吸収する情報の質が良くなければ、何も得られません。以下に載せた内容は比較的、中立的な資料を選んで挙げているのでぜひ一読してみてください。

1-1. 先駆者の考え方をトレースする

自分がブロックチェーンを学ぶ上で参考にした方は、Matsuo Shin'ichiro先生(@ShaneMatsuo)です。

米国の大学でクリプトの研究を進めていらっしゃる方です。とても中立的な立場から、ブロックチェーンが現代社会に必要な背景を説明されています。自分はまず、この方がパブリッシュしてる資料をとにかく読みました。数年前の記事でも示唆が溢れているので現在でも読む価値が高いです。

ブログ

連載記事

レポート

この辺りを一通り読み終わると、ブロックチェーン技術に対する意見がぼんやり言えるようになってくるかと思います。

1-2. 各研究機関が出してる資料を読み漁る

ブロックチェーン技術をキャッチアップするときは、背景知識も必要です。なぜブロックチェーンが有用なのかを理解するためにも、国や研究所が出すような包括的にリサーチされているドキュメントにふれるのが自分には合っていました。

DXからスマートシティ、セキュリティのtopicまで様々なジャンルを挙げてますが、根底にあるブロックチェーン技術の思想としては同じものです。異なる視点から見ると理解が深まるはずです。 ※比較的新しい2019年以降の資料を選んでいます。

1-3. ホワイトペーパーを読む

ホワイトペーパーとは企画書のようなものです。暗号資産は各々ホワイトペーパーを持っており、そこでは使用するプロトコルなどが明記されています。この企画書を読むことで、各々の暗号資産が生まれた背景や解決するための思想について学び取ることができます。

ブロックチェーンを理解する上で、ビットコインとイーサリアムのホワイトペーパーはマストで読んだほうが良いと思います。

・ビットコインのホワイトペーパー

https://bitcoin.org/bitcoin.pdf

・イーサリアムのホワイトペーパー

https://ethereum.org/en/whitepaper/

1-4. 書籍で勉強する

以下は自分が読んだ中でおすすめの書籍です。ブロックチェーン理論と実践だけでなく貨幣の歴史についても学ぶと、多くのトークンが生まれる理由についても分かるようになります

ただし、基本的にコントラクト周りの開発をする際はあまり書籍を参考にしないほうが良いです。(古い情報になるのでコードが動かないケースが多い。)後述しますが、手を動かしたい場合は、直接GitHubのtutorialを実施するのが良いです。

・ビットコインスタンダード

https://www.amazon.co.jp/dp/4623090299/www.amazon.co.jp

ビットコインがなぜデジタルキャッシュになれたかの理由を「貨幣の健全性」という定義に照らし合わせて解説した書籍です。 現在流通してる貨幣が不健全な理由についても触れています。既存貨幣が後続の貨幣に駆逐された歴史背景を学ぶと、なぜビットコインがデジタル・ゴールドと言われ、デジタルキャッシュとしての地位を築けたかが理解できると思います。

・ブロックチェーンの技術と革新

https://www.amazon.co.jp/dp/4315523852/www.amazon.co.jp

「信頼」をテーマに、その再定義と、実態のない対象に対してブロックチェーン技術がどう信頼を担保できるかを説明した書籍。 この本の中で度々引用されるコモンズ/ローレンス・レッシグ著という書籍も名著なのでこちらも一読の価値があります。 信頼の歴史を動画でキャッチアップしたい場合はTEDのこちらの動画がおすすめです。15分くらいで信頼の歴史がlocal=>international=>decentralizedに変化した背景が理解できます。

・SolidityとEthereumによる実践スマートコントラクト開発

https://www.amazon.co.jp/dp/4873119340www.amazon.co.jp

原著は2019年の出版ですが体系的によくまとまっています。実際に手を動かすパートについては、コードが若干古いので目を通すだけで良いと思います。(Truffleや周辺ツールの使い方を勉強する場合は、Webサイトに訪れてtutorialを見ながら手を動かして実践するのがベストです。)ただトランザクションの実行結果の各パラメータの見方や、トランザクション発行までの流れを言語化されているので、現在でも学べる部分は多いです。

参考: Truffleのチュートリアル

・マスタリングイーサリアム

https://www.amazon.co.jp/dp/4873118964/

ビットコインと比較しながらイーサリアムの特徴とその歴史について書かれた書籍です。イーサリアムの仕様だけでなく、なぜスマートコントラクトがすごいのかを理解するにあたって良書です。

・Token Economy: How the Web3 reinvents the Internet

https://www.amazon.co.jp/dp/B08BKSY3QZ

これだけ英語です。実はGithubにレポジトリが合ってそちらであれば無料で読めます。トークンエコノミーについて理解を深めたい場合はこの本が一番おすすめです。(翻訳かけて読むとかで全然OKです) Web2.0からWeb3.0へへ移行していく所から説明されてるのでブロックチェーンが必要になった背景理解が深まります。

github.com

1-5. より専門的な記事を読む

ここまで挙げた資料を読み込むと、たとえば「セキュアでノンカストディなウォレットを作るために必要な技術とは何か?」といった知識が必要な問いには答えられるようになります。

さらに「これからブロックチェーン技術がどう発展いくか?」といった未来を仮説付けるような問いを自ら立てるためには、専門家の記事が有用です。

この辺りの問題提起などの言語化には、以下のサイトが非常に勉強になったので紹介します。

・HashHub Research

https://hashhub-research.com/

プランはいくつかありますが、個人で入るなら9,990円/月のBasicプランがあります。 リサーチャーの方の所感や考えが記事に反映されており、新しい情報だけでなく示唆も得られます。

自分が気に入ってる記事のひとつに「論考・ロングタームで大局観を持ちながら、 暗号資産・ブロックチェーンに投資をする5つの原則」というものがあります。これは投資に興味がなくても、技術者として「アプリケーションとインフラ周りのサイクルがどう発展してきたか、ブロックチェーン業界に置き換えると現在はアプリケーション層が発展してるが今後インフラ層のプロダクトもきっと発展するだろう」という示唆が得られます。今後来るであろう技術を予測するという観点で非常に学びがありました。

hashhub-research.com

・Token Lab

https://blog.token-lab.org/

こちらも4980円/月の有料レポートですが、最新のブロックチェーン動向を追えます。ブロックチェーン系プロダクトの内容を詳細に記載するスタイルで読み応えがあるので、ある程度ブロックチェーン用語に慣れてから読み始めるのがおすすめです。

また、記事のコメント欄で有識者の方々が議論しているのでそれを見るのも学びがあります。

・イーサリアム創設者ヴィタリック氏のブログ

https://vitalik.ca/index.html

正直、結構難しいことを書いている(しかも英語で)ので、イーサリアムの知識がある程度ついてから、今後イーサリアムの開発はどうなっていくのか知りたくなったタイミングで読むのをおすすめします。詳細な数式モデルなどは分からなくてもイーサリアムのシステムの方向性は掴めると思います。

1-6. クリプト業界のレポートを読む

自分は定期的にCryptTimesさんとCoinGeckoさんのレポートを読んでいます。技術だけでなくブロックチェーンの流行りを理解するのに最適です。直近1年間のレポートと、個人的に有用だと思う技術レポートを貼っておきます。これを読んでおくだけで最近のブロックチェーン動向については抑えられるかなと思います。

※ CryptoTimesさんのレポート一覧はこちら

1-7. YouTubeで学ぶ

イラストでブロックチェーンが学べるコンテンツです。英語ですがイラスト見るだけでも楽しいのでぜひ息抜きにでも!

・Finematics

https://www.youtube.com/channel/UCh1ob28ceGdqohUnR7vBACA

個人的にLayer2 Scalingの動画とか分かりやすくておすすめです。

www.youtube.com

1-8. 議論されてる場所に行く

現在進行系で今後のブロックチェーン開発をどうしていくか、といった議論がされてる場所があります。 Improvement Proposalsと呼ばれており、日本語でいうと改善提案を行う場所です。

全部の議論を把握する必要はないのですが、スマートコントラクト開発をしていて「こんな機能ないのかな〜」と思いものは大体議論されてることが多いので、該当するブロックチェーンのImprovement Proposalsをググると見つかるかもしれません。

ここではイーサリアムというブロックチェーンと、NEARというブロックチェーンのImprovement Proposalsを紹介します。

・EIPs(Ethereum Improvement Proposals)

https://eips.ethereum.org/

・NEPs(NEAR Improvement Proposals)

https://gov.near.org/

1-9. ブロックチェーン技術の全体像を掴む

技術の全体感を把握するのに良いなと思って拾ってたtweetや記事を貼っておきます。どの技術も関連性があるので、迷ったらこのようなマップにもどってくると理解が深まります。

・ブロックチェーン技術のコンセプトマップ

f:id:kei32bit:20210901155006p:plain
ブロックチェーン技術のコンセプトマップ

medium.com

・Bitcoin周りの技術ネットワーク図

1-10. (番外編)人から直接教えてもらう

自分でキャッチアップもしましたが、実際にブロックチェーン業界に入って周りの方々に教えてもらうことのほうが実りがあるものが多かったです。 最近Meetyが流行っていますが、「ブロックチェーン」というワードで検索をかけるとたくさんの面談が出てきます。興味のある業界や興味のあるアプリケーションがあったら、直接話を聞きに行くのが一番だと思います。もし今からブロックチェーンをキャッチアップするなら自分がやるだろうなという方法なので挙げました。

f:id:kei32bit:20210901155649p:plain
Meetyで「ブロックチェーン」というワードでの検索結果

2. 実践してみる

良質なインプットのあとは、実践です。ブロックチェーンの開発に着手する際は、できる限り新しく(直近1ヶ月にcommitがあるなど)、githubレポジトリにあるものを動かしながら学ぶのが良いと思います。

以下のような、最新のHow To Learn記事を参考にすると良いと思います。イーサリアムだとSolidityという言語を使いますが、基本的に普通のプログラミング言語と変わりません。

medium.com

また、イーサリアムとは別のブロックチェーンになりますが、Rustでスマートコントラクトを書きたい場合は、NEARというブロックチェーンもおすすめです。チュートリアルが充実しており、スマートコントラクトをデプロイするところまで実施できるドキュメントがあるのでこちらも紹介します。

learnnear.club

examples.near.org

3. おわりに

ブロックチェーン界隈は次々に新しいトレンドやプロダクトが生まれるので、追いかけ続けるのは正直言って困難だなと思います。

ただ、自分なりのキャッチアップの仕組みを整えておくと、1ヶ月ほどブロックチェーン業界から離れていても割とすぐにもどってこれます。必要なのはブロックチェーンの知識量ではなく、キャッチアップの速度をいかに早めるかです。

もし本記事を読んで少しでもブロックチェーンに興味を持っていただいた方は自分もmeetyやってるので声かけていただけると嬉しいです! 「ブロックチェーン技術を事業に結びつけてどうマネタイズするの?」など事業目線での疑問にもお答えします。

meety.net

また、Gaudiyではブロックチェーン以外の技術ももちろん使ってますので、こちらの記事をご参考ください!

techblog.gaudiy.com

スモールチームで始める、デザインシステムの第一歩

f:id:gaudiy:20210824232101p:plain

こんにちは。エンタメ業界のDXを進めるブロックチェーンスタートアップ、Gaudiyで主にフロントを担当しているkodai(@r34b26)です。

弊社は、まだエンジニア10人、デザイナー2人ほどの小規模な開発チームですが、デザインシステムの構築に取り組んでいます。

デザインシステムは、一貫性のある品質の高いUIを継続してデリバリーする上ですぐれた仕組みですが、リソースの限られた環境ではなかなか着手しづらい面もあると思います。実際、デザインシステムを導入している会社では、専任の人やチームを組成して取り組まれていることが多い印象です。

そこで今回は、スモールな開発チームで、デザインシステム、特にコンポーネントライブラリを構築する上で工夫していることをご紹介してみたいと思います。

デザインシステムとは?

デザインシステムとは、一言でいうと「一貫性のある品質の高いUIを継続してデリバリーするための仕組み」です。デザインの原則や基準をまとめたドキュメントと、それを満たすデザイントークンやコンポーネントから構成されます。

複数人のデザイナー/エンジニアが、複数アプリケーションの実装を進めていくと、各々の実装の仕方によって "似て非なるもの" が繰り返し生成されてしまいがちです。

デザインシステムを適切に構築することで、繰り返し生成するコストやUIの実装コストを削減したり、表現のブレをなくしてユーザー体験の向上を実現することができます。

なぜ導入したのか?

これまで、弊社ではMaterial Designをデザインシステムに、Material UIをコンポーネントライブラリに使用してきました。

プロダクトの検証フェーズでは、このようなOSSに完全に依存し、ごく少人数で高速に実装できることはValueの高いことでした。ですが、新しいファン体験をより高品質に提供していくフェーズに変わり、開発チームの人数も増えてきたことで、従来のやり方ではValueを出せなくなってきました。

例えば、

  • iOSはMaterial Designの表現やインタラクションの体験がなじまないこと
  • HIGベースに話すデザイナーと、MUIしか認知していないエンジニアでの認識齟齬
  • ありふれ"すぎた"体験のものしか作れないこと
  • MUIを都度上書きして使うことによる、表現のブレの多発
  • Figmaと実装のコンポーネントが結びついていないことによる、認識のずれ、再発明の多発

といった課題がありました。また弊社の特徴として、複数のコミュニティアプリを作っているため、レバレッジの効く仕組みづくりに早いうちから着手する必要があります。

このような課題を解決する手段のひとつとして、デザインシステムを導入する意思決定をしました。 

Gaudiyのデザインシステム

現在は、デザイナー1人、エンジニア1人の体制で、少しずつデザインシステムを構築し始めています。

f:id:gaudiy:20210824113530p:plain

デザイン原則、スタイルガイド

f:id:gaudiy:20210824113624p:plain

コンポーネント

弊社のデザインシステムを簡単にご紹介すると、デザインはFigmaを、フロントの実装はReactを使用しており、そのコンポーネントの組み方と命名を完全に一致させています。この組み方が違うと、のちにFigmaで新しく組んたものが実装で反映できないことがあるので、はじめに認識を合わせておきます。

また、細かい色やマージンなどのデザイントークンと呼ばれるものは、Tailwindのconfigで管理して、こちらも命名と内容を合わせます。さらに、実装したものはStorybookにすべて登録してFigmaに存在する使用例を再現し、次回の実装からStorybookの例からコードをコピペできるように用意しています。

f:id:gaudiy:20210824113221p:plain

実際のStorybook

実際にどう作っているのか?

フェーズが変わり、デザインシステムの導入を始めたとはいえ、まだまだ少人数で高速に開発しなければならず、プロダクト開発以外にリソースを潤沢に割くことはできません。

そこで、限られたリソースでどのようにコンポーネントライブラリの構築を進めているか、その工夫を3つほどご紹介します。

1. プロダクト開発の一部に取り込む

すべてのデザインシステムを揃えるには、相当な労力がかかります。そこで弊社では、「プロダクト開発の一環で使用したいもの」かつ「その時点で複数機能/環境で使うような汎用性をもちたい要件であった時」に、新しいコンポーネントを作成するようにしています。

具体的には、必要とする実装者がオーナーとなり、まずは既存のデザインシステムに存在するかを確認します。そこでなければ、他のエンジニアやデザイナーにヒアリングしながら実装のやり方を考え、プロジェクトのチケットの一部として進行します。

こうすることで、チームへのデザインシステムへの意識を伝え広げるとともに、プロダクト開発の一部として、デザイナー/エンジニア以外への認識向上も含めながら進めていくことができます。

f:id:gaudiy:20210824232828p:plain

PM的な立ち回りの人がコメントしてくれる

2. 完璧をめざさない

最初からベストプラクティスを追い求め、バグがなく、アクセシビリティも高く、汎用的なコンポーネントをめざしてしまうと、いくら時間があっても足りません。 また、実際に使うことでわかることもあるため、他エンジニアへのヒアリングやツールの導入で最低限の水準を担保しつつも、はじめから求めすぎないことが大切だと考えています。

実際に開発の一部として進めることで、自分たちのユースケースを反映することができるので、そこで実現できないものがあったときにはリファクタ、追加、修正することで改善の機会を逃さないようにしています。

f:id:gaudiy:20210824111103p:plain

story baseのチケットで、タスクの一部としてボタンの挙動を更新した例 

3. OSSの力を借りる

ModalやTransitionなど、若干の実装コストがかかるが車輪の再発明になってしまうようなものに関しては、OSSを使用するなどして、直近のコストを積極的に下げるようにしています。

その使い方に関しては、MUI v5のunstyledheaedlessui のようなものを使ってunstyledな層は任せ、styledな層を自分で実装する。もしくはstyledな層も任せるが、それらを組み合わせたutility的な層を自分で実装するなど、ケースによって柔軟に対応できるように工夫しています。

f:id:gaudiy:20210824111329p:plain

分割してlerna管理している

運用を始めてみての効果と課題

実際にデザインシステムを導入してみて、UI実装をするときの変化を感じています。

例えば、デザイナーと「デザインシステムに定義すべきか」を話したり、他のエンジニアに「どう使用すべきか」を尋ねたり、また「実現できなかったときはどのように調整すべきか」といった会話もチームでなされています。

デザイントークンとコンポーネントライブラリ自体の向上が少しずつ進んでいますが、 それ以上に、デザイナーとエンジニア間でのコラボレーション機会が増え、お互いにヒアリングし合うべき内容を伝播できていることに一番効果を感じています。

一方で、

  • プロジェクトでスピードが重視される期間に、導入/改善が挟みづらい
  • 初回の実装や相談相手が、まだまだ特定の個人に偏っている
  • デザインシステムの実装が絡まないパートである、デザイン原則などのドキュメント整備やその周知が進まない

といった課題もあり、この辺りは今後改善していきたいです。

まとめ

今回は、弊社のデザインシステムに関する取り組みをご紹介しました。リソースがない中でも工夫すれば始められないことはないので、初期フェーズからデザインに投資したいと思っているチームの参考になると嬉しいです。

整備しきるまでは長い道のりですが、コラボや会話促進といった+αの価値も出せているので、地道に改善していきたいと思います。 デザインシステムの相談相手いないのでほしい。。。。

meety.net

Gaudiyの技術選定は、こちらの記事をご参考ください〜

techblog.gaudiy.com