
2025.02.04
能登半島地震で自宅は全壊、「これでどうやってDXするねん」 被災したサイボウズ社員と支援者らが語る災害支援のノウハウ
リンクをコピー
記事をブックマーク
河西紀明氏:こんにちは。DMM.comの河西(@norinity1103)と申します。よろしくお願いします。
僕は現在、DMMテクノロジー本部のデザインストラテジストとして、ブロックチェーンなど先進的な技術を活用したプロダクトの研究開発をしています。
組織の中での立ち位置としてはプロダクトの提供価値をユーザーやマーケットの抱える本質的な課題に応じてフィットさせるための戦略を引いたり、単なる「すごい技術」の転用でなく「ユーザー」にとっての利用しやすさや、体験価値の向上ができるように、開発フローに対してUXデザインプロセスを少し先行させた検証・実験などを繰り返しています。
前職では6年間ほど地域情報のサービスデザインと開発に携わり、2年前にDMMに転職。デジタルコマース事業のグロースや、開発基盤の改善、スクラムチーム組成の支援など、デザイン領域にこだわらず様々なプロジェクトに関わっていました。複業でゲストハウス経営をして、開発者支援とかもやってます。デザイナー以外で複数の生業を持つことは多くの視座を得られる良い機会となっています。
だいぶ会場がピリっとした雰囲気で、僕の話す内容が今回のトーンに合っているのか不安に思っています(笑)。
DMMでは新旧合わせて40以上の事業があるのですが、そんな事業会社の中でビジネスモデルの設計や戦略設計に関わりプロジェクトを牽引できるようなデザイナーの育成や、BTD(ビジネス・テック・デザイン)が協業できる体制づくりを模索しています。
今日は「アトミックデザインの話をちょっと」とお声掛けをしてもらい、登壇の機会をいただきました。タイトルの「共業≒協業」というのはただの言葉遊びなんですが、そういった世界観を目指すために僕が関わったサービスやプロダクトでどのようにアトミックデザインを活用したのかという話をさせていただきます。
そういえば、同じテーマを扱う書籍が出版されたり、日本語のナレッジも増えてきましたね。アトミックデザインは組織やサービスによってその概念の活用法は多様化してきたと思いますので、まずこのセッションにおけるアトミックデザインの位置づけを話します。
我々にとってのアトミックデザインの位置づけは、サービスやプロダクト開発におけるコミュニケーションを円滑にする「共通言語」づくりの一歩目、またはサービス開発やアプリケーションデザインの経験が少ないデザイナーがテクニカルな開発現場に対して歩み寄るための知識を身につけるための学習法・考え方として認識しています。
実際に、この手法が自体がサービスやチームの抱える問題に対して「銀の弾丸」になったということは一切ありませんでした。
原義としてのアトミックデザインとは、モジュラーデザインという考え方を元にブラッド・フロストさんが考案したUIデザイン手法です。モジュラーデザインは、プロダクトの各モジュール(機能的にまとまった部分)を作成した後、それらを繋げて完成品を作る手法です。冒頭の「デザイナーが開発に必要な知識を身につける」というをより具体的にすると、この「機能的にまとまった部分」というものを理解し、対象の開発体制で実装させているコードと比較した上で、常時のインターフェースの設計に活かしていくということです。
弊社での代表的な事例としては、アトミックデザインの概念を理解したデザイナーが主導でチームで『UIインベントリ』のワークショップ実施し、継続的な活動で経緯で得られる成果を、徐々に開発チーム全体にとっての学習のボトムアップや成果に繋げました。
UIインベントリは、サービス内で利用されている全てのUIパーツを棚卸して整理・分類、パターン化するワークショップで、これを活用することでWebサイトやアプリケーションで利用されているコンテンツを網羅的に把握することができます。
ボタンやナビゲーション、ラベルなど、分類手法にバリエーションがありますが、プロダクトによって表層構造を作るフレームワークによって名称が異なる場合もあるので、多くの場合は初期段階でアトミックデザインの概念におけるレベル分けや原子、分子などの粒度分けを元に切り分けることができます。
ワークショップの実施を通しての成果物の一部が開発チームの「共通言語(パターン)」として機能するようになりました。それらは結果的に、開発サイクルの効率化や、サービスやチームの抱えるより大きな課題を解決する足がかりになったことは間違いありません。
現在でもサービス開発経験が浅いデザイナーでも気軽にスタートできる、歩み寄りの第一歩としてオススメしています。 実際の取組みについては後ほど詳しくご紹介いたします。
実例の紹介の前に、タイトルの「共業≒協業」という言葉遊びをつかって昨今で話題の他職種の協業について掘り下げてお話いたします。
「共業≒協業」、これは単純に「それぞれの職務領域のコミュニケーションの壁を取り払って良いサービス・プロダクトを考えつくっていきましょう」ということです。ビジネスシーンで現場は協業せよ……協業せよ……と叫ばれるのは今にはじまった話じゃないのですが、改めて我々が目指している体制づくりのニュアンスが「開発に関わるメンバー全員で一緒に良いもの作りましょう!」という方向性になっているかがポイントです。
「共業」という言葉をカジュアルに表現するならば、新しい事業や価値を生み出すために「みんなでやっていきましょうよ!」という文脈なんですが、原義的には宗教的な意味合いも包括するので一般的な言葉ではありません。乱用注意です。
共業(ぐうごう)……集団としての責任。人類全体や日本人全体の業。(引用)
一方、「協業」のほうは、もともと設定されているゴールに対して職務領域ごとの「3つの力を足す」ような感じの考え方で描くため、共業とはすこし文脈が変わってくるのかなと思っています。
同一の生産過程あるいは相互に関連のある生産過程で,多数の者が計画的に協力して生産に従事する形態。 → 分業(引用)
……辞書にはこのように記されています。
まさに言葉遊びですが、単に「協力してやっていきましょう」というのは昔から言われている話です。今後のモノづくりのあり方は、規則やルールではない「行動指針」を定め、チームとプロダクトを成長させながら「共通言語(パターン)」をつくっていくという部分が重要になってくるじゃないかなと僕は考えています。
実際の開発現場では、協業体制を目指しながらも実態は同じ組織でそれぞれの職務領域を分ける「分業」によって効率化する文化が根強く浸透しているのではないでしょうか。どのような開発スタイルやフレームワークを採用しても、作業に向き合うメンバーは上位設計や戦略設計に一切関われずにいることで、結果的に“協業体制っぽい社内受発注形式”になってしまい最終的にこういった典型的なウォーターフォール形式に陥り、チームはあらゆるリスクにさらされることになるでしょう(笑)。
このようなケースは組織の規模や新旧を問わずどこでも発生していています。
これをあまり大きな声に出したら炎上するかもしれませんが、たとえ組織体制や文化が「クソトップダウン」や「クソ中央集権」であっても、本当はそれぞれが「良いものを作っていきたい」というのは、各自の立場と視点で考えられているだと思います。
絶対売上主義な方や、好きではないことを仕事としている方も当然いらっしゃいますが、ビジネスに関わる多く人は「できること」や「好きなこと」を武器に、価値のあるサービスをつくりたいと夢見てこの業界に入ってきたのだ...と期待していますが(笑)。中々、上手くいかないことは多いですよね。
何かしら立場や環境によって、動きづらさや抑制力が働いてしまうことが多いですが、今こそユーザーの体験を設計し、ユーザーに一番近いとされているデザイナーから行動を起こせる開発側への歩み寄りの接点が必要なのではないか?ということです。
じゃあ、どのように「一緒にデザインしましょう」を推進していくのか? ここで、ようやくアトミックデザインの話が登場します。つまり、アトミックデザインは職務領域を越えたコミュニケーションにおいて「共通言語(パターン)」づくりに役立つんじゃないかということですね。
アトミックデザインの表面的な理解としては独自の分類と粒度分けの型といものが存在しており、その型に応じて対象のサービスの要素を分類するというものですね? しかし分類を進めているうちに、おそらく多くの方も同じ疑問に辿り着いたと思います。
分類の仕方も粒度もそれぞれの知識的な背景と個別の解釈で迷いますし、デザイナーどうしで話し合った所で最適な答えにたどりつきにくいのです。例えば分けたパーツに似て非なる機能が付随していたり、ユーザーのサインイン・サインアウトの有無や商品の購入前後のような「状態の変化」によってボタンの色や表示される文言が変わったりします。
よくあるデザイナー側の歩み寄りのアンチパターンとして「せっかくなら一緒に楽しくやっていきましょうよ」「アトミックデザインを導入しましょう」と前のめりになって、周囲のデザイナー”だけ”を巻き込んで、キレイなSketchデータを最終成果物にしガイドラインとして運用していくとううケースがありますが、よくないですね。それはデザイナーにか得しないプロダクトをつくっていることと同じです。
単に分類するだけでは「で?それからどうすんの?」という話ですね。でもかんでも同じように導入して成果を得られるわけでもなく、既存サービスのUI/UXデザインの体系化、または新規サービスを立ち上げ後のデザイン資産の管理・運用などがあります。対象とするサービスの成長フェーズや属性によって取り掛かり方が異なります。歴史として繰り返されてきた、管理されないデザインスタイルガイドをつくって終わりになります。
瞬発的な行動を起こすことは誰にでもできますが、手法を導入して成果を残すには戦略がなくてはいけません。
結局は「手段を目的化しないように」という言葉に尽きますが、そのような前提があるにもかかわらず、いつの間にか目的がすり替わって、作業を楽しんでしまっている事態も少なくありません。最近はデザインツールが大きく進歩し出来ることが増えてきたので、視覚的な成果物に囚われ、今おこなっている取り組みの目的を見失いがちなのです。
とかく、進めているうちについ華やかな手法やツールに目がいき、楽なほうに向かってしまうことが多いのです。これまでの話から手法としてアトミックデザインを活用する場合も、戦術や計画が大切ということでした。
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
第20回エクゼクティブメンターイベント「今、「ひと」と組織が共創する〜働き方の未来へ」
2024.12.07 - 2024.12.07