こんにちは！Goodpatchでは2020年9月18日（金）に第6回目となるエンジニアのためのミートアップ「Goodpatch Engineer Meetup Vol.6」を開催しました。
初めてのオンライン開催となりましたが、たくさんの方にお集まりいただきました！今回はデベロッパー3名がプロトタイプの制作、エンジニアとデザイナーの共通言語を構築するための取り組み、バックエンドエンジニアにとっての「デザイン」などについてナレッジをお話ししました。
登壇メンバーたちの発表内容を元に、イベントの様子をお届けします！
「プロトタイプのすすめと注意」 田中健
はじめに、弊社でiOSデベロッパーを務める田中から、プロトタイプ制作についてお話しました。
本日はプロトタイプの意義やメリット、実施する際に注意すべきことについてご紹介します。
みなさんはプロトタイプ制作を実施した経験はありますか？
従来のソフトウェア開発は長期的かつ厳密な計画を元に遂行される物がほとんどでした。一方でCOVID-19の流行などを始めとする、目まぐるしく常識や当たり前が変わるこの時代での開発は、緻密な計画を通りに行うことではなく変化に対して柔軟に対応することが求められます。
2020年7月には「プロトタイプシティ 深センと世界的イノベーション」という書籍が発売されました。この書籍では、デジタル技術を用いて既存事業の改良や改善を繰り返す「連続的価値創造」と、トライアンドエラーを繰り返して偶発的に今までにないプロダクトを生み出し続ける「非連続的価値創造」について扱っており、この非連続的価値創造をプロトタイプ駆動によって実現する手立てを紹介しています。
これらの背景も相まり、変動性が非常に高い現代において、プロトタイプはより多くの注目が集まる開発手法だと言えるでしょう。
プロトタイプとは
この「プロトタイプ」ですが、みなさんはこの単語に対してどのようなことを思い浮かべますか？プロトタイプは一見シンプルですが、手法は多岐に渡ります。
「takram design engineering|デザイン・イノベーションの振り子」という書籍では、製品のタイプによってプロトタイプの分類を行っています。特にソフトウェアに関するプロトタイプは以下の4種類があります。
- ダーティプロトタイプ: ありあわせありの材料でアイデアを形にしたもの
- コールドモックアップ: 実際には機能しないが完成型と見分けがつかないもの
- テクニカルプロトタイプ: 実装が完了し、機能するもの
- ワーキングプロトタイプ: 見た目的にも機能的にも完成形に近いもの
余談ですが、弊社が提供しているプロトタイピングツール「Prott」はこの分類を元にすると、コールドモックアップを作成するためのツールと言えるでしょう。
プロトタイプの種類はこのように多岐に渡りますが、プロトタイプの活用場面も様々なケースが存在します。身近な例ですと、チームやプロジェクトの内外を問わず、コミュニケーションをする際に用いることができます。言葉だけで議論するのではなく同じ物を共有しながら議論することは、チーム間の共通認識をより強固な物にし、合意形成を促進させてくれるでしょう。
また、新しい機能やリリースされていないプロダクトを不完全な状態だとしても実験的に公開し、ユーザーからフィードバックを得ながら改善を繰り返す際にも有用性を発揮します。
弊社で行っているクライアントワークでも、コールドモックアップを用いてユーザーインタビューを実施したり、テクニカルプロトタイプを用いながら実装を行っています。
Why プロトタイプ？
続いて、プロトタイプを実施する意義について、プロトタイプの持つ効果やメリットを混じえながらご紹介します。
ソフトウェア開発の現場では、細かな表現や仕様を言葉のやり取りだけで伝達しながら進めようとする程、チーム間での認識のズレが発生してしまいます。一方で表現や仕様を言葉ではなく見える形にして共有することで、認識や解釈の違い・コミュニケーションの齟齬は防ぐことができます。プロトタイプにはこのような、チームでのコミュニケーションをより活性化させる力があります。
弊社が提供しているプロトタイピングツール「Prott」のキャッチコピーは「1000の会議より、1つのプロトタイプ」ですが、このコピーはプロトタイプがチームのコミュニケーションを円滑にするという利点を的確に表しているのではないでしょうか。
また「具現化と価値検証」のサイクルを素早く回せる効果も存在します。長い時間をかけて議論を重ねて開発し完成したプロダクトだとしても、価値検証が遅いとプロダクトを作っている間に類似サービスの登場・既存サービスの追従・時代の変化に遅れを取るといった問題が発生します。何よりも、長い時間をかけてプロダクトを制作しても、そのプロダクトに価値があるとは限りません。
このような問題を防ぐには、プロジェクト初期段階での素早い具現化と価値検証によって誤りを検知したり、時代の変化に対応する必要があります。そして小さく・素早く作ることのできるプロトタイプには、このサイクルを加速させる効果があります。
—
プロトタイプはプロダクトの完成形をいきなり作るのではなく、アイデアをまず形にする所から始まります。それでは、いきなり完成形を作らない手法であるプロトタイプは簡単かつ楽な物なのでしょうか？
親しいチームの中だけでプロトタイプを用いるのであれば問題ないかもしれません。一方でプロトタイプを顧客やユーザー・チーム外のメンバーと共有する場合はどうでしょうか。
また、関係者が多くなる程「これも検証して欲しい」「あんな機能も欲しい」といった声も増えるでしょう。しかし、様々な要望に対応した結果「検証が不明瞭になってしまった」「検証までに時間がかかってしまった」「実装スコープが大きくなってしまった」という事態が起きては元も子もありません。
これらの問題はプロトタイプが気楽な物であるという誤解や、関係者間でのプロトタイプに対する認識や目的意識のズレが原因であると考えられます。
この問題が発生しないようにするためには、次のことについて、関係者で共通認識を持っておくことが重要です。それは、プロトタイプは検証結果が伴うことで始めて有用性を発揮すること、プロトタイプには明確な目的が必要であること、そして素早い時間で実施する必要があることです。
プロトタイプ制作の前に必要な物
プロトタイプ制作の前には、Why・How・Whatの3点を検討する必要があります。
プロトタイプ制作において、初めの土台になるのはWhy（価値検証の理由）です。検証が必要であるということは、そこには以下のような分からないもの・不確実なものを解消したいというモチベーションがあるはずです。
- アイデアがユーザーにとって価値のあるものなのか知りたい
- 仮説通りにユーザーが行動するのか知りたい
- 技術的に実現が可能か知りたい
さらに、実装を要するテクニカルプロトタイプの開発を検討する場合は以下のような動機があるのではないでしょうか。
- 端末のセンサーやOS固有の機能へ依存するアイデアに価値があるか知りたい
- ユーザー行動データの蓄積によって生まれる体験に価値があるか知りたい
何を検証したいかというプロトタイプのWhyを明確にすることで、テクニカルプロトタイプやコールドモックアップなど、どのようなプロトタイプが必要か選択できるようになります。実装などはあくまでも手段の一つに過ぎません。少ない工数で素早く検証できる手法を選ぶことがプロトタイプ制作では重要になります。
続いて、プロトタイプ制作の前に必要な要素はHow（検証方法）です。
プロトタイプでの価値検証をする場合、成功・失敗の判断軸を設置する必要があります。
- チーム内で合意形成・不明点の解消が実現できるか
- 目標とする特定のKPIに寄与するか
- ユーザーインタビューでどのような反応を得られるか
これらのような判断軸が存在しないと、価値検証を実施しても肝心の結果が分からないという事態が発生します。一方で検証結果の判断軸が定まることで、何を作るべきなのかを関係者と共通認識を持って絞り込むことができるようになります。
プロトタイプ制作において、事前に決めるべき最後の要素はWhat（作成内容）です。
この何を作るか決めるフェーズにおいて重要なのは何を作らないか決めることです。素早く検証をするためにも、検証に必要のない機能や仕様はスコープアウトするべきです。
Whatを決める前にHowが定まっていると、必要最小限のスコープや必要な品質を定義する作業を容易になります。
プロトタイプ制作の事例の中には、テクニカルプロトタイプをリリースまでのベータ版と定義して実施ケースも存在しますがこの手法はとても危険です。考慮していては、設計や実装に時間がかかってしまい、素早い価値検証ができなくなってしまいます。
また、作る物が事前に定めた検証内容よりも過剰である状態もNGです。繰り返しになりますが、プロトタイプ制作ではいかに早く価値検証を行えるかという点が重要になります。
プロトタイプはエンジニアにとって強力なツール
プロトタイプには様々な活用シーンがありますが、チーム内で合意を形成するためのプロトタイプであれば、誰でも・明日にでも・身近に実践できます。
チームの議論が膠着していたり、アイデアがうまく伝わってないと感じたとき、エンジニアはその状況をプロトタイプによって打開できる可能性を持っています。なぜならエンジニアには、言葉で飛び交うアイデアを実装というスキルで具現化させる力があるからです。
初めは能動的にプロトタイプを制作することに対して、失敗などの恐怖から足踏みしてしまうケースもあるかもしれません。しかし、プロトタイプのメリットは素早い検証サイクルと失敗にあります。失敗によって新たな議論を産み出し、状況を打開するほうが価値が高いのではないでしょうか。
プロトタイプによって、エンジニアはデザイナーのデザインデータを形にするだけでなく、デザインをより良くするための議論を進展させるための役割を担うこともできるようになります。さらにはプロダクトを前進させるアイディアがあるならば、プロタイプを実践してマネージャーに共有することも効果的です。
エンジニアが持つ実装スキル・アイデアを具現化する能力は、エンジニアならではの特権です。エンジニアが生み出すプロトタイプは、チームに物で語り合う文化をもたらす可能性を秘めています。
より良いプロダクト開発のために、ぜひ明日から楽しんでプロトタイプ制作を実践してみませんか？
「デザイン組織で共通言語を設計するエンジニアの取り組み」 乗田拳斗
続いて、弊社でフロントエンドエンジニアを務める乗田拳斗かから、グッドパッチにてエンジニアとデザイナーが共通言語を構築するために実施している取り組みについてお話しました。
デザイナーとエンジニアが共創をする必要性
昨今、デザイナーがソースコードを理解することの、エンジニアがUIデザインを理解することの重要性について頻繁に議論が行われています。それでは、デザイナーとエンジニアはなぜお互いを理解して共創をする必要性があるのでしょうか？
そこには、ソフトウェア開発の現場に存在する、開発の進行を阻害する様々な障壁や課題となりうる要素の影響があります。そして、その課題は現在の時代や社会情勢を表すキーワード「VUCA」で表すことができます。
VUCAは現代のビジネスにおける課題の頭文字を繋げた造語で、グッドパッチでも例に漏れずこの困難に直面しています。また、ビジネスや社会情勢だけでなく、昨今のソフトウェア開発も変動性(Volatility)が高く、不確実(Uncertainty)かつ、複雑(Complexity)で、曖昧(Ambiguity)であると言えるでしょう。その結果、ソフトウェアをリリース時から高い拡張性を持つシステムにする必要や、これまでよりもさらに複雑性を排除してシンプルな形にする必要が生まれています。
グッドパッチでは不確実性や曖昧性を解消するソリューションの一つは「チームの力」であると捉えています。また、「偉大なプロダクトは偉大なチーム」という言葉が何年も前から大切に語られてメンバー間での共通認識となっているほど、チームの力を信じている組織でもあります。
グッドパッチには、エンジニアはキックオフのタイミングからプロジェクトに参画するという方針もあります。この方針にはソフトウェアは必ず実装されるからこそ、デザイナーといち早くチームを結成した上で素早くコミュニケーションを取り、発生しうる手戻りや不確実性を減らすためという意図があります。
デザイナーとエンジニアが共創をする必要性が高まった要因には、従来よりも品質の要求が上がったことや、様々な手戻りや不確実性をチームの力によって排除する必要性が生まれたことが影響しているのではないでしょうか。
共創のための4つの取り組み
グッドパッチでは、デザイナーとエンジニアが前述のような様々な不確実性を乗り越えて円滑にプロダクト開発を行うために、クライアントワークの内外で様々な取り組みを実施しています。本日はその中から4つの事例をご紹介します。
❶ ユビキタス言語
1つ目の取り組みは「ユビキタス言語」の構築です。ユビキタス言語はEric Evansが提唱したドメイン駆動設計の要素の一つで、 ユーザーが使う言葉とプログラムの中の言葉を一致させるための用語です。 私が携わったワンキャリアクラウドの開発ではこの手法をUIデザイン・UIコンポーネントに応用して実践していました。
ユビキタス言語を定義したことで、デザイナーとエンジニアの間で共通言語が生まれてコミュニケーションが円滑になった他、デザインファイルとソースコードの命名が統一され、高速な作業を実現できました。
ユビキタス言語は小さな単位からでも始めることができる上に、導入の恩恵を得やすいソリューションです。ボタンやラベルの命名などから始めてみるのはいかがでしょうか。
❷ デザイナー×エンジニア交流会
続いては弊社の中で実施した「デザイナー×エンジニア交流会」というイベントです。このイベントは職能に縛られないコミュニティで、社内でのソフトウェアデザインに対する認識を合わせ、共通言語をかたちづくるという目的の元でスタートした物です。
社内では複数のエンジニアとデザイナーがチームを組んでクライアントワークを行っております。そこで、各々がプロジェクトで得たナレッジや抱いた疑問などを社内で持ち寄り、専門性や価値観の違いを尊重しながら、より強固な共通言語を産み出すべくしてこの交流会を実施しました。
交流会では参加者が「悩んでいること」と「その悩みが生まれた背景の解説」を持ち寄り、その問題に対して他の参加者がフリップに回答を記述して答え合わせと議論を行う形式で共通言語を産み出すワークを実施しました。ワークでは「色の命名はどのように行うべきか」「デザイナーは1px単位の視覚調整は行ってもよいのか、エンジニアは反映してもよいか」などのお悩み投稿があり、お悩みの中でも解決に運んだ上で共通言語を生み出せたものは社内で「ナレッジの種」として登録しました。
半年程実施した結果、デザイナー・エンジニア双方から「普段プロジェクトを進める中でお互いが心の中で思っていても、中々言葉に出来ていなかかったことが吐き出せた」というFBや「解決せずになんとなくプロジェクトで進めきたような問題もこの取組みで共通言語が出来てきている気がする」といったポジティブな意見が集まり、意義があったイベントであると言えるのではないかと思います。
❸ UIレビュー
3つ目の取り組みは「UIレビュー」です。グッドパッチではエンジニアもUIデザインの品質に責任を持ち、特に実現可能性の観点やプラットフォーム制約の観点からレビューを実施します。最近はこれらの観点からのレビューに加え、アクセシビリティ観点でのFBも実施しています。
WebアクセシビリティはW3CによってWCAGと呼ばれるガイドラインが作成されているため、そのガイドラインに基づいてFBを実施する形式を取りました。アクセシビリティFBは配色やタイポグラフィ、余白設計などのUIの可否を数値から客観的かつ定量的に測定できるため、主観的であったり属人的なインターフェイスを改善するきっかけを作ることができます。
アクセシビリティは国内ではまだ理解が薄く、積極的に取り組んでいる例も少ないので、実装も兼ねるエンジニアから提案してみると、プロダクトの品質向上に効果的なのではないでしょうか。
❹ ライブデザイン
最後は「ライブデザイン」という取り組みです。ライブデザインとは、デザイナーとエンジニアがライブコーディングのように1つの画面を見ながら、リアルタイムにデザインを行うワークです。
関連記事：「ワンキャリアクラウドのデザインプロセス」
チームは物理距離・時間距離が広がるほど、コミュニケーションが伝言ゲーム化してしまい、認識のズレや手戻りが起きやすくなってしまいます。これはエンジニアとデザイナーによるUIデザインのプロセスについても同様のことが言えます。
ライブデザインはリアルタイムでレビューと改善を繰り返して行われるため、この手戻りや認識のズレを減らすのに効果的でした。また、ライブデザインを実施する中で、チームで同じモノを見て同じモノに向き合う大切さや、共通認識がどんどん取れていく様子、チームで合意形成を重ねてより強固なプロダクトを構築する感覚を実感できたことは個人的な収穫でした。
ライブデザインはUIデザインが完成した後のレビューだけではなく、6,7割の完成度のデザインを一気にゴールまで導く手法としても有効的であり、様々な組織にも恩恵をもたらす取り組みであると考えられます。
グッドパッチのデザイナーエンジニアはこれらの手法を用いて素早くコミュニケーションを取り、発生しうる手戻りや不確実性を減らしてプロジェクトに取り組んでいます。
もしどれか一つでも惹かれる取り組みがあれば実践してみてはいかがでしょうか。
バックエンドエンジニアにとっての「デザイン」を考える 矢原将宗
最後に、StrapやProttなどの自社プロダクトのバックエンドエンジニアであるやっはー（@yahharo）から、バックエンドエンジニアにとってのデザインとは何かというお話をさせていただきました。ちなみに、資料は全てStrap上で作成したものだったそうです！
私はどんなエンジニアか（なぜ「デザイン」なのか）
僕自身はテーブルコーディングと言われる時代からWebエンジニアをやっておりまして、少しずつバックエンド寄りになってきました。
僕はもともと、身近な人に心地よく使ってもらえるシステムを作りたいと考えてエンジニアとして働いていました。心地よく使えないシステムの問題はどこにあるのか考えたときに、画面の問題なのか？それとも処理速度が遅いせいか？といろいろ探り、ユーザーエクスペリエンスの考え方に出会ったのです。
ヒューストン空港の新手荷物引所の例
米国のヒューストン航空では、荷物が着いてから荷物を受け取るまで8分がかかると言われています。到着ゲートから手荷物引渡所まで1分歩き、そこで7分待って手荷物を受け取ったお客さんは不満を感じていました。手荷物を受け取るところを遠くに置き、お客さんの移動時間が長く、待機時間が短かったになった後、体験がとても上がって苦情がほぼゼロになった事例です。
（画像引用元：「UIの改悪がUXを改善させる場合 – A Successful Failure」より）
このように、インターフェースだけではなく、ユーザーの体験においてストレスを改善できるシステムを作っていきたいと思いました。体験がデザインされ、身近な人が心地よく使えるシステムを構築できるエンジニアになりたいと思って、グッドパッチに入社を決めています。
今日は、バックエンド周りを中心にやってきた僕にとっての「UXデザイン」についてお話をしていきたいと思います。
「システム」を「デザイン」するとは
システムとは、相互に影響を及ぼしあう要素から構成される、まとまりや仕組みの全体を指します。以下はSinglePageApplication（SPA）の例ですが、僕がやっているWebシステムは大体こんな感じです。
バックエンド・インフラにとってUXデザインの5段階モデルに当てはめると
皆さんご存知の方が多いと思いますが、「UXデザインの5段階モデル」というユーザー体験を構成する5つの段階があります。この5段階モデルをバックエンド・インフラで当てはめてみます。
関連記事：「UXデザインにおける5段階モデルとは？」
WebAPI、インフラなどは、「どんな人が使うのか」を策定するため「戦略」のプロセスに当てはまります。また、「データベースのスキーマをいかに柔軟にして、拡張性を持たせるか」については「構造」のプロセスに当てはまります。構造についてはまさにエンジニアが考えるべきところだと思います。
その上で最適なレイアウトを作り、どのような形でデータを返すのか、インタラクションを検証します。最終的に、即効性と遅効性を兼ね備えたビジュアルデザイン、「表層」が出てくると思います。
このプロセスの中で、「誰に対して、どのような価値を届けて対価をもらうのか」という「戦略」の部分を特に大事にしたいと考えています。ですが、エンジニアにとっての「戦略」とは何なのか考える機会は多くはありません。
なので続いて、僕が考える戦略の部分についてお話ししたいと思います。
先ほどのWebシステムの図に、それぞれ運用者を付け加えてみました。要するに、インフラは勝手に動いてるわけではなく、僕たちは運用者に対しても価値を提供することが大切なのです。
例えば他にも、セールス、CS、マーケティングなど、チームのメンバーとユーザーのためにシステムをデザインすることが重要だと考えています。
それぞれのユーザーに届ける価値が違う
下記のように、複数のユーザーがいるシステムでは、それぞれのユーザーに届ける価値、ユーザーが受け取る価値は異なります。
運用者：ロギング、監視、バックアップ、開発環境
開発者：API、デプロイ、デバッグ、開発環境
ユーザー：システム機能、パフォーマンス、セキュリティ
セールス・CS・マーケティング：利用状況、過去の履歴、統計情報、契約状況
「ユーザー」の「ユーザー」
ここまで運用者の側面からお話ししてきましたが、続いてはユーザー、実際の利用者についてです。
メインユーザーについて掘り下げていくと、他にもたくさんのユーザーがいることに気がついてきます。
メインユーザーにとっての対価は「このシステムを利用して作成された価値」です。では、メインユーザーはその価値を誰に届けたいのか。そう考えていくと、メインユーザーの先にはクライアントがいるが分かります。
メインユーザーのクライアントの属性を仮定して、例えばエクスポート形式はPDFが良さそうだとわかったら、PDF書き出しのシステムをしっかり設計して、メインユーザーに速く価値を届ける。
情報システムにおいて「このシステムだったら大丈夫、安心だよね」と思ってもらうには、メインユーザーのクライアントたちが「こういうエクスポートできるツールだったら安心だよね」「資料が見やすくないと困る」など個人の要求があるため、こういったものをしっかり答え、戦略の時点で把握しておかなければなりません。
エンジニアが届けられるのは、メインユーザーに対する直接的な価値だけではないのです。
どんなユーザーがいるのか、その中でどんな打ち手があるのか、例えばセキュリティに関してどこまでやっておけばいいのかなどをしっかりと考慮した上で、システムをデザインしていく必要があります。
「メインユーザー」の「ユーザー」
しかし、最初にプロダクトを作る際に、いきなりこれを全部やることは難しいです。僕がStrapを構築した際には、「このシステムを使うのは誰？どんな人がいる？」といった戦略の部分を情報システム部の先の人のことまで考えて、全体像を想像しながら取捨選択して、メインユーザーにとってどんな価値が大事なのかという価値検証をしました。そして、構造を柔軟に変えられるようにデータベースとプログラムの柔軟性を持ちつつ、理想の未来を描きながら技術を選定しました。
最後におまけですが、Strapの初期の概念図をご紹介します。
ただあるものを組み合わせて作ったこの概念図はすごくシンプルなものですが、これだけで十分動いていて、そして今はこの先にどんどん広がっています。
どういうふうにスケールされていくのか、検索機能やログイン、そしてセキュリティ要件をどうするべきなのか、この段階でも拡張できるように想定していたので、大きな構成変更なく正式版をリリースできました。現時点ではまだ不足している運用側の機能も、将来構築できるように最初期から検証はしていました。
エンジニアにとって、戦略を考える機会がなかなかないですが、これから誰に対してどんな価値を届け、対価をもらうのかっというのデザイン的な思考を実践してみてはいかがでしょうか。
以上、「Goodpatch Engineer Meetup Vol.6」のイベントレポートをお届けしました。イベントが終わった後は登壇者と参加者たちはオンライン交流会を行い、この日のイベントへの共感や発見の声が多く聞けました。
ご参加いただいた皆様ありがとうございました！
Goodpatchではデザインの力を信じるエンジニアを探しています。ご興味がある方はこちらのリンクから気軽にご連絡ください！