なぜ今、デザイナーがトラックナンバーを考えるべきか


トラックナンバーとは、プロジェクトやチーム開発において、「ある特定の人物がトラックに轢かれるとプロジェクトが立ちゆかなくなったり、チームでの開発が困難になる人数」のことです。

「このコードは◯◯さんしか修正できない」「この開発環境の構築は△△さんに聞かないと分からない」といった状況はトラックナンバー1の状態です。共同開発を行う際にこのリスクが増加するため、 スクラムなどアジャイル開発の手法を選ぶメリットとして引き合いに出されることが多いです。

トラックナンバーは数字が少ないほどリスクが高まります。

「デザイナーワーク」におけるトラックナンバーとは

本来はプログラミング業界で扱われることが多かった用語ですが、職責の壁が溶けている昨今の開発現場では、デザイナー例外ではありません。

このデザインは◯◯さんしか作れない!さすがデザイナーさんだね

この言葉は、デザイナー冥利に尽きる甘美な響きに聞こえますが、この状態は非常にキケンなことです。

特定のデザイナーがいないとプロジェクトの進行が滞る状況や、新しいUI/UXの設計やアウトプットができない状態は、トラックナンバー1ということになります。

もしあなたがデザイナーで、他チームからのスポットアサイン、もしくは外注の雇われデザイナーでない限り、この事態はプロダクトとチームの将来のために真剣に考えなくてはなりません。

トラックナンバーの増やし方

では、トラックナンバーを2や3にしていくにはどうすれば良いのか?
従来的な解決策から学んでみましょう。

①ドキュメントを揃える

引継ぎタスクやマニュアルを用意し、「常に見える場所」に記録します。全てをドキュメントにするのは難しくコストもかかります、優先度が高いものからアップデートを欠かさず、管理できるのであれば有効な手段です。Confluence, Github Issue, GoogleDrive etc...
大事なのはチームで利用しやすい、共同編集可能なドキュメントツールを選ぶことです。

②ペアプログラミング

ペアプログラミング(英: pair programming)は、2人のプログラマが1台のワークスペースを使って共同でソフトウェア開発を行う手法。テストを打ち込んでいるときに、もう一方がそのテストを通るクラスについて考えるといったように、相補的な作業をします。

実際に端末を操作して作業する人を「ドライバー」、もう1人を「ナビゲーター」と呼びます。30分ごとか、プログラムやモジュールを1つ完成させる度に役割を交替するのがよいとされます。また、1日に一度の割合でパートナーを変えるのが良いともされています。

③複数人での単一作業

プログラミング以外の作業などでも同じ効果が見込めるので「ペア作業」も良い方法の1つです。プログラムやモジュールに複数人が関わることになり、トラックナンバーは2以上になります。

これらワークの効果の1つとして「第三者が読んで分かりやすいコード」になることがあります。

結果、イレギュラーで欠員がでたとしてもプロジェクトにとっての致命的リスクを避けながら開発を継続することができます。

モブデザインという方法論

さて、これをデザインワークに当てはめるとどうなるでしょうか? 職場に大きいディスプレイがあるなら、モブプログラミング(英: mob programming)を応用したモブデザイン(英: mob design)という手法があります。


この手法は、デザイナーのWF作成、ステークホルダーを巻き込んだプロトタイピングをはじめ、あらゆるワークの共業化に役立つでしょう。

シニアデザイナーが実際に作業を、育成対象デザイナーに開示することで教育的な側面も持つこともできます。

上記のイメージではFigmaを利用し、非デザイナーを含むチームメンバーとサービス内に混在する未管理のデザインパーツを洗い出し、コンポーネントライブラリ化するための「UIインベントリ(Interface Inventory)」というワークを行いました。

これにより煩雑になっていたサイト内のUI設計が、全員の共通認識になり、新規開発の際の想定漏れを防ぐだけでなく、デベロップサイドでも再利用可能なコンポーネントライブラリが設計できるようになりました。

デザイナーのトラックナンバーリスク回避は、手順の「見える化」や「規範づくり」では足りない

従来的なデザインのワークフローにおいても、PhotoshopやSketchなどツールに限らず、誰にでも理解しやすく美しいデザインデータ構造をつくることが義務付けられ、最新のデータを指定の場所に格納したり、付属する資産を管理する作法を細かく「ルール化」してきたでしょう。

前述のアイディアをデザインのワークフローに当てはめ、ペアプログラミングを応用したペアデザイン(英: pear design)などの方法で、ツールの使い方など始めとした対デザイナー向けの教育を補うことは可能かもしれませんが、本質的なトラックナンバーリスクを解決することにはつながりません。

多くの場合これらはあくまで「手順」であって本質的なデザイナーのシゴトではないからです。ルールを学習するのにも大変時間がかかります。

リスク回避としての「デザインシステム」の構築

ある種のデザイナーはプロダクトの品質に対して、一貫性のある「体験」をユーザーに提供するため一定の責任を持つ存在です。

しかし、UIデザイン、UXデザイン、インフォメーションアーキテクト、色彩パターンなど、広義に「デザインスキル」と形容されていた知見は、最近では良質な書籍やアウトプットにより、非デザイナーであっても容易に理解し、身につけやすくなりました。

また、優秀なUIフレームワークやJSフレームワークも日々アップデートされオープンソース化されています。

つまり、非デザイナーでも狭義のデザインをすることが可能になっているということです。

一方で「誰のため」など本質的な表現の追求に関しては、前後の文脈も含めて見える化されていないことが多いです。

例えば、Webアプリの開発だった場合では、エンジニアがデザインスタイルを実装する能力を持っているにも関わらず、ボタンのRの度合いやテキストの「です」「ます」の言い回しなど、あらゆる「表現」の部分を逐次デザイナーに確認するはめになるでしょう。これはボトルネックで、古いタイプのBOSSがマイクロマネジメントを入れてくる状況に似ています。チームのコミュニケーションとしても悪い影響が及びます。

その解決策として、効果的と考えられているのが、チームを巻き込んだ漸進的な「デザインシステム」の構築プロセスです。

電子ブック:『Why Build a Design System?』
https://www.uxpin.com/studio/ebooks/design-systems-why-build-one/

改めて「デザインシステム」の必要性を考える

ビジョンには頑固だが、ディテールには柔軟に
── ジェフ・ベゾス

「デザインシステムズ」の基盤を設計し、ステークホルダーの賛同を得ながら体系化を先導することは一過性のデータをつくることよりチーム貢献価値が高いことを示します。

これらをシステムを構築することは、高度なレベルを要すると考えられがちですが、チーム一丸として取り組み、ディスカッションし、漸進的に設計するプロセスを通して互いに良い学習効果を得られると同時に、信頼値を高められます。

良きサンプルをステークホルダーと読み合わせる

Alex Pate氏がキュレーションしている、デザインシステムズのリソースまとめ。有名所のサービスやブランドのあれこれがまとまっている。

<項目>
コンポーネント:コード化されたパターンとサンプルが含まれている。
ボイス&トーン:言語の使用方法に関するガイダンスを提供。
Designer kit:Sketchデータなど。デザイナーのためのファイル。
・Storybook:React Storybookの関連記事を提供。

参照:https://github.com/alexpate/awesome-design-systems

最後に

デザイナーが改めて、プロダクトやチームに対するプレゼンスを考えたときに、より専門性が高く属人化している部分が見えてくる時があります。その対策を考え続けることは大切で、それをチームで議論することは更に重要です。

デザイナーはプロダクトの品質に対して、一貫性のある「体験」をユーザーに提供するため一定の責任を持つ

リスクの回避のベストプラクティスが、必ずしもデザインシステムの構築とは限りませんが、「強いシステム」は、あらゆるトラックナンバーリスクを潰す可能性を秘めていると私は思います。

余談:トラックナンバーという名前を変える

「トラックナンバー」って名前はあまりにアグレッシブでプレッシャーを感じると思いませんか?笑

本来、リスク管理とは鬼気迫る状況と思われますが、ものづくりは創る側が楽しくなければ、本当に良いものは生まれません。

「トラックナンバー」という名前は、限りなく極端な話で日常からそんな不幸な出来事が多発しては世界は滅んでしまいます。

もっと、建設的な話として、メンバーがお互いにいつでも長期の休暇がとれる状況を用意できていたとしたら素敵なことだと思いませんか?

あるときはリフレッシュのために気軽に旅行に行ったり、無駄に有給消化して好きなゲームに熱中したりと。

代わりに命名するとしたら、結婚旅行を想定した「ハネムーンナンバー」や、育休だとかの「ベビーナンバー」でも良いかもしれませんね。

デザインワーク共業化については、こういうのも書いてみたので、よろしければぜひご参考に。


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

note.user.nickname || note.user.urlname

サポートありがとうございます😃 いただいたものは、我が家のウコッコさんのエサ代か、書籍などのインプットに活用させていただきます! Twitterフォローいただけると嬉しいです!気軽に絡んでください https://twitter.com/@norinity1103

50

DMMの仲間たち

DMM.comのエンジニア・デザイナーがゆるい感じで、いろいろ書きます
1つのマガジンに含まれています

コメント1件

久々に書いたら内容盛り込みすぎな件、自戒。実は花山兄貴を描きたかっただけという。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。