実践から学んだ、SaaS企業のプロダクトデザイナーのための注意点8つ【反省編①】
SaaS企業の開発チームは、日々いくつもの難解な問題と格闘しています。PdMやプロダクトデザイナーもその内の1人で、格闘の末、大小・公私にさまざまな失敗を経験します。実際にどのような失敗があるのでしょうか？対策は？ 成功には再現性がありませんが、失敗にはあります。同じ轍を踏む人が少しでも減ればと願って、SaaS企業で経験した8つの失敗と対策をシェアします。
Introduction
前回のおさらい
前号で、SaaSやデザインツールのデザインについてノウハウをシェアしました。
このモデルになった会社での仕事では様々なアウトプットとともに、いくつもの失敗や反省もしました。
そして実は今、また別の会社で別のSaaSを担当しているのですが、そちらでも似た現象, 似た課題を目にしており、悪い予感が的中中です。成功には再現性がありませんが、失敗にはあるということです。
具体的にはどのような失敗があったのでしょうか？
良い機会なので、今回はSaaS企業での実際の仕事で得た失敗と反省点、どうすればよかったのかを言語化してみます。
私個人の反省とチーム視点の反省に触れますが、一度に話すにはとても長くなってしまったため、それぞれに分けてお送りします。
もくじ
SaaSを設計する上での反省
個人として（今回）
1. 高すぎるオーナーシップは毒
2. UIの発想のバイアス
3. UXリサーチの放棄
4. バーンアウト
A. 以上4つを防ぐ5つの方法
チームとして（次回）
まとめ
SaaSを設計する上での反省
個人として
1. 高すぎるオーナーシップは毒
当該プロジェクトにおいて、私はとても高いオーナーシップを持っていました(自分で言うのも何ですが)。
基本的にスタートアップ村で育ってきたため、個々が強いオーナーシップを持つことは望ましいと思っています。恐らくこれを読んでいる方もそうだと思いますし、実際当該チームからも評価いただいていました。
しかし、過分なオーナーシップを持って臨んだ結果は悲しくも次のようなものでした。
オーナーシップによる積極的な振る舞いが周囲からリーダー的に映り、明示的なリーダーを形骸化させることに繋がった1
それにより対外的な連絡経路が混乱。実装よりも大きい粒度の情報や資料を誰が揃えるのか、セールスやCSとのリレーションは誰が行うのかといったことが誰も(私も)分からなくなった
リリースがグダグダになり、後味が悪い結果に
このことからは、オーナーシップも過ぎれば毒。ということを学び取れます。このオーナーシップの弊害を一言で言えば、分業の破壊です。
分業の破壊とは、責任の所在の破壊です。
他のメンバーから見れば船頭が2人いるように見え、本来のリーダーは自分がリーダーなのか自信が無い状態になります。プロジェクトが不安定になって当然ですが、振り返りが行われるまで全く気づきませんでした。
オーナーシップよりも分をわきまえた振る舞いが必要なケースもあるということです。
自分の直感と思想に大きく反するものですが、受け入れなければなりません（こうして人は丸くなっていくのでしょうか）。
2. UIの発想のバイアス
全くの別角度ですがUIデザインについても反省点があります。
UIはつい自分が使い慣れているものや自分が良いと思うものへ傾きがちです。
例えば私は、あるプロジェクトでインラインエディター式のUIを採用しました。これは今振り返ると、ところどころNotionに引っ張られていた気がします。
採用はユーザビリティテストの結果でしたが、「Notionに似ている」ことを認識できていれば、前号で述べたように「ウチのプロダクトはNotionほど高頻度で使用されるものだろうか？」「Notionに似てしまったが、もっと違う発想を出してみるべきでは」といったことも検討できたはずです。
顕在的な問題があったわけではありませんが、UIについてのアンコンシャス・バイアス2を払拭できていたとは言えないでしょう。
3. UXリサーチの放棄と視野狭窄
プロダクトデザイナーの仕事は、機能やエピックごとの抽象と具体の行き来で説明できます。
プロジェクトの前半はエピックを読み解き、プロトタイピングやユーザーインタビューを用いて仮説の探索や検証を行います(Discovery)。
後半はプロダクトを実装するフェーズ(Development)であり、ここでは一旦抽象を忘れて具体に没頭します。基本的にはリサーチは行わず、現実に実装するための粒度に落とし込む仕事を行います。UIデザイン, ドキュメンテーション, 仕様の整理, ハンドオフなどですね。
私の失敗は、Developmentの期間が半年間以上にも渡ってしまったことです。この期間は基本的にリサーチを忘れますから、私とチームは半年間もの長い間、ユーティリティとユーザビリティ以上の範囲を見ていない状態でした。
開発者がユーザーから離れてしまうと、大抵いい結果を迎えません。
幸いにも対外的な深刻な破綻は起きませんでしたが、一方でチームに大きなストレスを与える事になってしまいました。
というのも、各機能や仕様に対する「どうしてこうしたの？」という問いに私はビジョナリーな回答を持ち合わせず、結論や発想の元となった材料3を繰り返し説明するだけになってしまったのです。4
「どうしてこうしたのか」という”目標”に分類されるオブジェクト(エピックやユーザーストーリー)に触れたのがもはや半年前であり、完全に忘れ去っていたためです。
信じられないかもしれませんが、UIや実装ばかり見ていると目標なんて簡単に忘れてしまうのです。Developmentフェーズはとても地道で1つ1つに集中力と注意を払う必要があり、他のことを考えるのに割ける時間と気力が減ることに起因します。
4. バーンアウト
最後にとても個人的なことですが、そうしてUXリサーチから長期間離れることが、私にとっては毒となりました。
半年間もの間UIデザインとドキュメンテーションばかりやってUXリサーチを行っていないことに認知的不協和を強め、結果としてバーンアウトが起こりました。
バーンアウトとは、やる気ある人が燃え尽きて労働意欲や気力を急に失うことです。
これは、”自分の思想は脇に置いてUIデザインを頑張ってリリースを絶対にやりきるんだ” と無理に克己に努めた結果でした。
リサーチ活動や抽象的な領域の仕事から離れて何ヶ月も実装フェーズを無心でこなす仕事は、自分にとっては危険だということを認識しました。
抽象化すると、今やるべきことにばかり目が向いて、安定的にパフォーマンスを発揮できるように自分をコントロール出来ていなかったということです。
以上4つを防ぐ5つの方法
以上4つの反省点に対してのアンサーが5つあります。
1. オーナーシップ過剰に対するRACI
1に、過剰なオーナーシップとバーンアウトについては、オーナーシップを適度にコントロールするのが望ましいアプローチです。これに適しているのは、連絡経路を混乱させるほど積極的な動きを防止するため、業務と責任について分業を定義し実装することです。
具体的な方法として、例えばRACIフレームワークを活用することで「俺がやらなければ」というヒロイックなオーナーシップの発露を抑えられるかもしれません。これはプロジェクトマネジメント領域ですからデザイナーの独力では達成できませんが、PMに提案することは出来ます。
2. 事前にパターンを出す
2にUIの発想のバイアスについては、大まかなUIパターンの分類を具体的なUIデザインを始める前に出すことが望ましいでしょう。
GUIのデザインは既に40年の歴史を持ち5、大抵のことは過去の体系の中で分類可能な世界です。UIパターンの分類は知識とやる気のあるUIデザイナーにとって難しくない仕事です。
3. 生成AIでバイアス回避
しかしどんなUIデザイナーにもバイアスがありますし、そもそも知識あるデザイナーがいない場合は取り組めません。
そこで検討できるのが、生成AIの利用です。
UIデザインにフォーカスしたAIプロダクトがいくつも登場しており、より多くのパターンを出してもらうことが出来ます。
例えば先日正式リリースされたガリレオは、ディスカバリーのために十分活用できるクオリティになっています。
ガリレオのように直接的にパターンを出してもらう以外にも、ChatGPTに反論を要求することで、自身のバイアスに気づくことも期待できます。
4. 機会を設計しておく
3にUXリサーチの放棄とバーンアウトについては、これそのものを解決するというより、プロジェクトにとってポジティブな2つの工夫を行うことで、ついでに解決されるでしょう。
1つ目は、プロダクトデザイナーが単なる画面屋・仕様屋にならないようにする工夫です。
長い間UIに没頭すると抽象レベルのことを忘れてしまいがちなので、デザイナーはPdMなどEpicに責任を持つ人間と高頻度で会を設けるとよいでしょう。ここで今作っているものがEpicやユーザーストーリーを達成できるかをPdMから口酸っぱくレビュー・フィードバックしてもらうのです。
これを実現するために、デザイナー-PdM間の日次や週次の相互共有, PdM-他職種間の中間報告会をセットで運用するとよいでしょう。
2つ目は、プロジェクトを間延びさせない工夫です。
いつまでもDevelopmentフェーズからリソースを転換出来ないような事態を防止するため、例えばDevelopmentが2ヶ月を上回ってしまった場合に次の1ヶ月後を期限に必ずこなす中間リリースを計画します。
5. ShapeUpフレームワークで戦略的に
また、そもそも実装が長期化すること自体が望ましくないため、より良い基本的な開発サイクルを定義しておくのも有用です。
具体的には、例えばShapeUpフレームワークを活用することで、1つの開発には2つの開発ラインが存在し、それぞれのサイクルにおいて誰が何に関与するのかを明文化できます。
設計フェーズと実装フェーズとの間にスコープを再定義する時間を入れ込むことで、超大な実装を排除しやすくなります。
スプリントよりもスケジュール感が分かりやすいですし、Pre CycleとIn Cycleは常に回っていなければならないためデザイナーを2人(2種類)採用しておくべきだ、といった全体最適な考え方も生まれてきます。
まとめ
今回は、SaaSプロジェクトにおける個人的な反省と対策についてでした。次回は、より客観的なチーム視点での反省と対策をシェアします。
もくじ
SaaSを設計する上での反省
個人として（今回）
1. 高すぎるオーナーシップは毒
2. UIの発想のバイアス
3. UXリサーチの放棄
4. バーンアウト
それらを防ぐ方法
チームとして（次回）
5. 肥大化したドキュメントとバッチサイズ
6. 構想と設計が分かれていない
7. タイムパフォーマンスが悪い
8. ポストモーテムの不在
それらを防ぐ方法
Substackアプリを使うと読みやすいのでおすすめです。
【明示的なリーダーを形骸化させることに繋がった】
補足:当該プロジェクトにおいて自分はリーダーではなく、別の人が指定されていた。
【アンコンシャス・バイアス】
無意識下のバイアスのこと。
【結論や発想の元となった材料】
顧客の発話や分析結果, ユーザビリティテストの結果, 開発上の障害や都合など。
【発想の元となった材料(中略)を繰り返し説明するだけになってしまった】
テスト結果を示せば説明として充分と思われるかもしれませんが、実際にはそれでは局所最適に映ります。私の経験上、納得できるストーリーやロジックなくテスト結果を示しても、内容に疑いを持たれるだけです。
厄介なのは、それでもテスト結果はデータであり信頼すべきであるように見えるので、説明者は説明を尽くした気になって生存性バイアスを見落とし、説明を受けた者は反論が難しく押し黙る傾向にあるという不幸を呼び込みがちな点です。
【GUIのデザインは既に40年の歴史を持ち】
初代Macintoshから数えている(1984年〜2024年)。