こんにちは！Goodpatchでは2019年12月10日（火）に第5回目となるエンジニアのためのミートアップ「Goodpatch Engineer Meetup Vol.5」を開催しました。
GoodpatchはUI/UXに強みを持ったデザイン会社ですが、今回のイベントではGoodpatchで働くエンジニアだからこそ持ち合わせている、インターフェイスデザインの観点やカイゼン事例、ペアデザインがもたらす価値についてなどのナレッジをご紹介しました。
今回は登壇された方々の発表内容を元に、イベントの様子をお届けします！
目次
「インターフェイスデザインとの向き合い方」丸怜里
はじめに、弊社の元iOSデベロッパーで、現在はソフトウェアデザイナーを務める丸怜里（@usagimaruma）から、エンジニアリングの発想を活かすUI設計の観点についてお話しました。
User Interface: ユーザーインターフェイス
まずはユーザーインターフェイスについて改めて紐解いてみたいと思います。
インターフェイスと言うと、iPhoneのようなGUIを想像される方も多いのではないでしょうか。しかしながら、普段使っているマウスやコンピュータへ接続するコネクタ、ボタンが沢山並んだコントローラーも広く捉えるとインターフェイスの1つです。また、交通機関に目を向けるとどうでしょうか。日本のバスとドイツのバスは外観が正反対のように見えますが、これは国による慣習や法律の違いがインターフェイスの違いを生んだ面白い例です。
インターフェイスを英語表記にすると「Inter-face」と分解し、「面と面の間」と直訳できます。この面と面を意識するとインターフェイスデザインの本質に迫りやすくなると考えています。
以下の図はインターフェイスが置かれている世界観を表したものです。左側は道具を使うユーザーの世界、右側はユーザーが用いるソフトウェア（対象）の世界であり、これらの世界の間にあるものがインターフェイスであると考えることができます。この世界ではインターフェイスを介してユーザーが対象へ、対象がユーザーへ作用を及ぼすことが可能です。両者が互いに作用を及ぼすことを相互作用、すなわち「インタラクション」と定義できるのではないでしょうか。
インタラクションという言葉も、英語表記にすると「Inter-action」と分解し、「お互いに作用すること」と読み解くことができます。ユーザーがあるボタンを押下したいと考え、クリックが完了するまでのインタラクションは以下のように例示することができます。
- ボタンを押してみようと考える
- カーソルをボタンの上に移動する
- ボタンをクリックする
この行為をインタラクションデザインやエンジニアリングの観点から考えると、以下のように細かく分類できます。
- ボタンはプッシュが可能なことをアピールし、ユーザーはボタンを視認して次の行動を検討する
- カーソルを操作して目標（ボタン）をポインティングする
- 目標（ボタン）の上でマウスボタンを押下し、ボタンは作用に反応して見た目を変化する
- マウスボタンから指を離してクリックフェーズを終え、ボタンは押し込み解除に反応して見た目を変化する
ユーザーが意識するボタンの操作方法は基本的に「ポインティング」と「クリック（マウスダウンとマウスアップの複合イベント）」のみです。一方でエンジニアはインタラクション設計のために、あらゆる画面・状態・挙動に対して適切なプログラミングをする必要があります。また、様々な作用に対して反応をどのように返すかについて考え、パターンを設計することが求められます。
ユーザーとエンジニアの両視点からインタラクションを捉え、インタラクションテクニックを正しく定義することで、適切なユーザーインターフェイスが成り立つのではないでしょうか。
Interface Architecture: インターフェイスアーキテクチャ
ソフトウェアデザインの主要な3つの観点とその割合は、Designing for the User with OVID (IBM, 1998)によると以下の図ように解釈できます。
この図から、良いGUIやソフトウェアを構築するためには、表層だけでなく裏側までを含めた仕組みを正しく設計する必要があることを読み解けます。そして、このオブジェクトモデルからインタラクション・視覚表現まで一貫した仕組みを設計する行為を、Goodpatchでは「インターフェイスアーキテクチャ」と表現しています。
インターフェイスアーキテクチャにおける重要な観点は以下のように表すことができます。
インターフェイスの構造は、関わる概念、デザイナーの設計思想、ユースケース、それらを基盤とした情報設計やモデリングにより形作られます。 UIとして機能させるためには、適切なインタラクション技術を用いて入出力の仕組みを設計し、正しく対話が行われる環境に仕立てることが重要です。
エンジニアリングの分野では当たり前のように扱われる「クラス」と「インスタンス」ですが、これらの概念をUIデザインに取り入れることで、UI設計をより柔軟に行うことができるようになります。
UI設計にクラスの発想を取り入れることで、UIの構造をパターンとして捉えられるようになり、拡張性も検討しやすくなります。インスタンスがどの程度具現化することができるのかを示す「多重度」の考え方や、多重度を設計するための決まりごと「Zero One Infinity ルール」を導入し、これらの設計を行います。Zero One Infinityルールは「ソフトウェアで扱う数的制約は、0 / 1 / 無限大 のみで表す」という原則であり、設計時は0..1、1..n、1などのように表現します。
このZero One Infinityルールを正しく理解することで、macOSのFinderのような「親を1、子を複数」の関係で構成される「ツリー構造」や、iOSの写真 Appのように「親も子も複数」で構成される「セミラティス構造」の観点からUIを簡潔に設計できるようになると考えられます。
また、エンジニアリングの分野ではよく知られているオブジェクト指向の設計論ですが、本質的にはGUIもオブジェクト指向の発想で成り立っており、これを「OOUI」と表すことがあります。インターフェイスアーキテクチャの設計において、OOUIの観点は非常に重要です。OOUIの操作は、はじめに名詞（目的語）であるオブジェクトに注目し、次にそれに対する動作としての動詞を選ぶ手順で行われます。以下の画像のように、macOSのメニューバーやツールバーは「名詞→動詞」構文で表現できるわかりやすい例ではないでしょうか。
OOUIについてさらに詳しく知りたい方は、以前執筆した記事「OOUI・オブジェクトベースなUIデザインに取り組むための心構え」をご覧ください。OOUIの捉え方や、OOUIモデリングについて紹介しています。
インターフェイスアーキテクトとは、これらの概念を適切に扱いながらインターフェイスデザインに向き合う役割であり、Goodpatchでは以下のように定義しています。
インターフェイスアーキテクトとは、GUIの構造や設計パターン、システムの仕組みに精通しており、アーキテクチャの設計に責任を持つ「UIデザイナー」の一種です。GUIに関する概念・ 設計思想の定義、ドメインモデルの設計、情報設計、OOUIモデリング、インタラクション設計を中心に、ソフトウェアの“拡張性”を考慮しながらデザインに取り組みます。
Goodpatch Blog「UIデザインにおけるインターフェイスアーキテクトの役割」より
元iOSデベロッパーがエンジニアリングの発想を活かし、ソフトウェアデザイナーとして働く上での役割やUI設計に取り組む観点について紹介しました。インターフェイスアーキテクトについては、Goodpatch Blog「UIデザインにおけるインターフェイスアーキテクトの役割」も詳細を執筆しております。ご興味のある方はぜひ一読いただけると幸いです。
「小さなチームのための小さなカイゼン」 高橋一樹
続いて、弊社でフロントエンドエンジニアを務める高橋一樹（@kazudeath1）から、前職と現職での業務カイゼンについてお話しました。
前職でのカイゼン
私は前職時代、精密機械の組立現場におけるカイゼンに取り組んでいました。現在は多くの工程にロボットアーム等の機械が導入されていますが、今日も人間の手作業が必要となる工程は少なくありません。このような環境の中で、人間と機械の両方の業務をカイゼンするために試行錯誤していました。カイゼンの最大の目的は時間あたりの売上や利益を増やし、生産性を向上させることです。
カイゼンをするためには「ムリ・ムラ・ムダの削減」という基本的な考え方がとても重要です。ムリ・ムラ・ムダとは、以下のような状態を指します。
- ムリ: 処理能力を超えた量・性質の作業を行うこと
- ムラ: 作業に要する時間や、品質がばらつくこと
- ムダ: 生産に寄与しない作業が生じること
ムダについての話をすると、「休憩を取ることはムダにあたるのでは？」という意見が頻出しますが、休憩を取らずに作業をすることはムリに相当し、成果物の品質にムラが生じるため、結果として生産性の低下に寄与します。このように、製造現場では様々な利害関係を見極めながらムリ・ムラ・ムダの削減が行われています。そして、効率よくこれらを削減するための施策が「自動化」と「5S」です。
自動化とは、人間が行う作業を機械で代替することを指します。自動化をすることで、人間が単純作業から開放されると同時にヒューマンエラーを削減できるという利点が生まれます。近年ではRPAと呼ばれていますが、製造業では従来からこの取り組みが行われていました。
また、5Sとは以下の取り組みを指します。
- 整理: いらない物を捨てる
- 整頓: 決められた物を決められた場所に置き、いつでも取り出せる状態にする
- 清掃: 常に掃除をする
- 清潔: 3S（整理・整頓・清掃）を維持し、職場の衛生を保全する
- 躾: 決められたルール・手順を正しく守る習慣をつける
この自動化や5Sを忠実に遵守し、遂行できていることが日本の製造業の強みであると考えられます。また、ムリをするとムラが出てムダが生じることを正しく理解した上でカイゼンに取り組んでいることも日本の製造業の強みの1つでしょう。それでは、日本のソフトウェア産業の場合はどうでしょうか。
ReDesignerでの小さなカイゼン
現在私が開発を務めている、デザイナーを目指す学生向けキャリア支援サービス「ReDesigner for Student」で行っている取り組みについて紹介します。
ReDesigner for Studentは今年の6月にリリースが完了したサービスです。一方で、今後もサービスの価値をさらに向上させるために、追加機能の開発・リリースを行う必要があります。しかしながら、チームが持ちうるリソースには限りがあります。このような中で生産性を高めるためにはどのような施策が必要でしょうか。
テストの自動化
サービスの安定した動作を保証するためにも、テストの実施はとても重要です。一方で、フロントエンド単体テストやリグレッションテストは多くのリソースが必要となるため、導入は容易でありません。
そこで、ReDesignerでは自動テストを最小のコストで小さく始めました。それが「Puppeteer」を用いた全ページの表示テスト及び、コア機能の正常系テストです。テストが始まるとボットはアカウント登録から退会までを自動で実施し、任意のフェーズでスクリーンショットを取得します。この環境のおかげでコア機能の不具合を自動的に検知することが可能となりました。また、スクリーンショットの一覽はPOやデザイナーも確認できるため、レイアウト崩れの検出も容易に行うことができます。
ソフトウェアの「5S」
5Sとは、必要な道具が適切な場所に配置されており、いつでも使える状態を維持するための取り組みです。製造工場における必要な道具とは、ハンマーやペンチなどを指します。それでは、ソフトウェア開発における必要な道具とは何でしょうか。ReDesignerの開発現場では、コンポーネント・ドキュメント・リポジトリが必要な道具であり、整理すべき対象と考えています。
コンポーネントの整理ができていないと、検索コストの増加やコンポーネントの重複作成を引き起こすリスクが高まります。このような問題を回避するためのソリューションとして有名なのは「Storybook」ではないでしょうか。一方で、Storybookには導入コストや運用コストが高いという課題があります。
そこで、ReDesignerではページにコンポーネントを並べるだけの環境を用意し、運用しています。また5Sの「躾」として、新しくコンポーネントを作成した際には同時にコンポーネントリストへ登録するルールを徹底しました。コンポーネントリストを導入したことで、同じコンポーネントを重複作成してしまう問題や、検索性の低さから再利用性が失われてしまう問題を解消できました。コンポーネントリストは小さなチーム、小さなプロダクトにおいても、十分な効果を得ることができる施策と言えるでしょう。
以上、ReDesignerでのカイゼン事例を紹介しました。自動テストやコンポーネントの管理をすることで、ReDesignerでは様々なムダをすることに成功しました。開発現場におけるリソースは有限であり、往々にして不足するものです。エンジニアリングの力でムリ・ムラ・ムダを削減し、限られたリソースで生産性を上げ、価値を創造しましょう。
「プロダクト開発を推進するペアデザイン」西山雄也
最後に、弊社でマネージャーを務める西山雄也（@nsyee）から、ペアデザインがプロダクト開発にもたらす価値とGoodpatchでの実践事例についてお話しました。
ペアデザインとは
現在、プロダクトDivでは以下のような開発思想を掲げてプロダクトの開発に取り組んでいます。
- アイデアをオープンに、目に見えるカタチにする
- チームで同じモノを見て同じモノに向き合う
- 学びと共通認識を積み上げていく
これらの思想の根底には、「ラバブルなプロダクトを楽しく開発する」という想いがあり、この考え方を体言するためにチームで取り組んでいる手法が「ペアデザイン」です。
ペアデザインとは、2人以上のデザイナーが同じデザインタスクを同じ時間に同じ場所で行う手法を指します。ペアデザインのルーツはエンジニアがアジャイルプロセスの文脈で行っていたペアプログラミングやモブプログラミングであると考えられています。ペアデザインの手法をいち早く確立したPivotalによるブログ「The Benefits of Pair Design」は拝読された方も多いのではないでしょうか。
ペアデザインのメリットには以下のようなものが挙げられます。
- 意思決定までの時間が凝縮される
- 一人で解決できないことが解決できる
- メンバー間の知識レベルが揃う
- 意思決定時の個人への負荷が軽減する
- 裁量の分担からオーナーシップが生まれる
Goodpatchでの実践例
Goodpatchでは以下の図のように、ペアデザインをデザイナー同士だけではなく、デザイナーとエンジニア・デザイナーとPM・エンジニアとエンジニア、そしてデザイナーとカスタマーサクセス等の職種を越えた組み合わせで行っています。従来から行っているペアプログラミングと今回取り組んでいるペアデザインを並行して実践した結果、UIデザイン・設計・開発の工程のシームレスな切り替えを実現できました。
実際にペアデザインを行うと、友達と一緒に謎解きゲームを解決するような達成感や、プロスポーツのチームプレイのように、状況に応じて最適な判断を流動的に行う気持ちよさを味わうことができます。
ペアデザインの際は様々な職種をまたいで行われるからこそ、ユビキタス言語を定義することや、ギャレットのUX5段階モデル等を用いてプロセスを共有することを大切にしています。また、「Whimsical」「Miro」「Notion」などのオンラインツールや、1つのディスプレイを使用し、同じ情報を即時的に共有しながら合意形成を図ることも重要なポイントです。
今日のプロダクト開発現場には様々な不確実性が存在します。そのような中でより良いプロダクトを開発するためには一人で課題に向き合うのではなく、専門性が結集されたチームで立ち向かう必要があります。そして、全力でペアデザインを介してコミュニケーションを取ることで、チームにおける知識の総量や成長速度を増大させる効果を得ることができます。これらの試行の先にこそ、ラバブルなプロダクトや、ビジネスの成功があると考えています。
はじめに話したように、ペアデザインには「アイデアをオープンに、目に見えるカタチにする効果」「チームで同じモノを見て同じモノに向き合う効果」「学びと共通認識を積み上げる効果」があります。これらの効果をもたらし、楽しいプロダクト開発へ導くペアデザインを実践してみてはいかがでしょうか。
以上、「Goodpatch Engineer Meetup Vol.5」のイベントレポートをお届けしました。インターフェイスデザインの観点やソフトウェアのカイゼン、ペアデザインについてご理解いただけましたでしょうか。
イベント終了後の懇親会では、軽食を囲みながらLTの内容について白熱したディスカッションが行われていました。
Goodpatchではさらにデザインの力を信じるエンジニアを募集しています。GoodpatchのことやGoodpatchのエンジニアについてお話しをする機会も用意しております。興味がある方はこちらのリンクから気軽にご連絡ください！！
