クラウドサインのデザイナーは、プロダクト開発を担うプロダクトデザインチーム、ブランド浸透を担うブランドデザインチームに分かれて所属しています。
2015年にリリースされたクラウドサイン。果敢に市場に挑戦し続けてきたこれまでのメンバーの努力や、コロナ禍による環境変化を受けて、今では通算2000万件の契約締結を行うまでに成長しました。
私は2019年に入社し、デザインリードとしてカテゴリーごと急成長するクラウドサインのプロダクトのデザインを担ってきました。
今回は、プロダクト開発において「正しくつくる」「速くつくる」ことをどのように両立しているのか、「価値探索のプロセス」とともにクラウドサインのデザイナーとして取り組んでいることを紹介します。
クラウドサインは2015年のリリース以降、長い紆余曲折を経て、今では多くの方に当たり前のように使ってもらえる選択肢となりつつあります。
投資契約、登記、など10年前にはクラウドサインで行えなかった契約は、すべて締結可能になっています。
幅広い業界の大企業や、70%以上の自治体での導入、SMBCとの連結子会社の設立など、この10年間は、クラウドサインはじめ、電子契約締結という新たな手段＝カテゴリーが、世の中に受け入れられてきた数年間でした。
カテゴリーの創造を行ううえで、セールスやマーケと同じく大きな役割を担ってきたのが、クラウドサインというプロダクトです。
電子契約を信じてくれたお客さまが、確実にクラウドサインのファンになってくれるように、プロダクト開発チームは、とにかくシンプルで使いやすい体験にこだわってきました。
特に初期は、プロダクトの機能は、契約締結のみ。管理はAPIを活用して他のプロダクトに任せるなど、体験自体もとにかく絞ってシンプルにすることを守りました。
クラウドサインでのプロダクト開発環境に変化が生まれたのが、2021年ごろのことでした。
当時、コロナ禍で、電子契約のニーズは急激に拡大し、クラウドサインもそれにならって急加速で育っていきました。
同時に、プロダクトに対しても、多様な要望をいただくようになります。
これらを受けて、検証を十分行わずに、ただ速くつくることだけを考えて開発をしてしまうと、つくっても使われない機能がたくさん生まれてしまいます。特に事業が急拡大するなかでは、より意識的に「正しくつくる」「速くつくる」を両立していく必要があります。
そのような状況に対応するために生まれたのが、クラウドサインの開発フローと、仮説検証のための「価値探索プロセス」です。
クラウドサインでの価値探索のプロセスは、大きく2ステップに分かれています。
1つ目は、機能コンセプトの検証 (誰のどんな課題をどう解決するか) 。 2つ目は、初期スコープの検証 (何をどこまでつくるか) 。
その後のステップとして、アジャイル開発へと進んでいきます。これらすべてのプロセスの、はじめから終わりまでデザイナーは関わっています。
そして、それぞれのステップの終わりには、チェックポイントが設けられています。プロダクト&PMOミーティングという場に資料を持っていき、開発チーム全体の議論を経て、次に進んでいくようなフローとなっています。
検証の過程でもチェックポイントを置いているのは、抜け漏れた論点がないかを適切に確認する「体験の向上」の位置付けと、意思決定の背景をドキュメントに残しておく「共有」の位置付けの2つが狙いとなっています。
ここからは、2023年7月にリリースした「マイナンバーカード署名機能」を例に、それぞれのステップで行っていることについてまとめます。
アジャイル開発に入る前の検証のプロセスは2段階に分かれています。はじめのステップは、「機能コンセプトの検証」です。
このステップでは、エピックリストから取ってきた機能案に対して、プロダクトマネージャーやエンジニアと一緒に、数名のデザイナーがアサインされて、はじめのコンセプトの検証から一緒に進めていきます。
エピックリストを踏まえて「本当に課題があるんだっけ？」「そもそも誰が使うんだっけ？」というコンセプト面のヒアリングを、複数名のお客さまに対して行います。
課題や、起こしたいアウトカムが明確になってきたところで、仮想プレスリリースを用意します。これはプロダクトマネージャーが中心に行っていることです。(Amazonが採用している、Working Backwordsという手法を参考にしています。)
これらのコンセプトをまとめて、チェックポイントであるプロダクト&PMOミーティングに持っていき、開発メンバー全体でここまでのステップで検証した内容に対して議論を行います。
仮に消化できてない論点があるならば、次のプロダクト&PMOミーティングに再度もってくる
議論を経て「Step2. 初期スコープ検証」のキックオフに入っていきます。
次のステップは、初期スコープの検証です。プロトタイプをつくりながら、ユーザーテストを繰り返し、具体的につくるべき画面を明確にしていきます。
このステップの終わりも、同じくチェックポイントとしてプロダクト&PMOミーティングでの議論を行います。確認するのは以下のような点です。
UIフロー
ユースケースの想定
具体的なモックアップ
キックオフのあと、プロトタイピング・課題リスト・ヒアリングの3つを回しながら進めていきます。
まず、1週間でざっと画面全体をプロトタイピングしていきます。ここで意識しているのは、なるべくリアルすぎないようにすることです。
もちろんクラウドサインにもコンポーネントライブラリはありますが、スタイリングの前に体験をシンプルに考えたいので、あえて四角や丸の簡単なシェイプでつくっています。
プロトタイプの作成と同時に、考えないといけないこと、論点をドキュメントに書き起こします。
これらの論点をプロダクトマネージャーや、当時のデザインマネージャーとSlackで調整の議論を進めていきます。論点が解消される度に、Figmaのプロトタイプをアップデートしていき、バージョン管理しながら進めていくようなイメージです。
内部だけではわからない体験面の論点は、お客さまに直接ヒアリングしにいって検証を進めます。
ここで意識しなければいけないのが「全く新しい体験なので、リクルーティングを担当する社内メンバーにも、正しく理解してもらわなければいけない」ということです。
なので、ちょっと回りくどいように感じられるかもしれませんが、まずは社内へのヒアリングの場を設けます。機能に対するラーニングをしてもらいながら、次のリクルーティングにつなげていくようなイメージです。
ここで「実際に売るときには、どう提案するか？」のような、リリース後のところの相談もしておきます。
特に今回の「マイナンバーカード署名機能」は、お客さまとしても、これまで体験したことがないことなので、丁寧に説明をしていく必要があります。なので、初期からどういう訴求にすると良いのか？についてもCSや、セールスのメンバーを巻き込んで認識を揃えていました。
その後、CSやセールスのメンバーに、リクルーティングを手伝ってもらい、社外ヒアリングを行います。
確認すると、企業と自治体を合計して、8団体くらいにヒアリングを行っていました。ヒアリングをしながら、プロトタイピングのアップデートをぐるぐる回していきます。
このアップデートを進めやすくするしくみとして機能したのが「課題リスト」でした。
課題リストを解決するための仮説をプロトタイピングし、それをもってヒアリング、ヒアリング後には必ず振り返りの場を設けているので、そこで課題リストにアンサーを記入する、というフローでどんどん論点をつぶしていきます。
新たにヒアリングから出てきた課題は、この課題リストに新規で追加し、また次のヒアリングの際に解消していく・・という流れで進めていきます。
クラウドサインでは、毎回のプロジェクトの「Step2. 初期スコープの決定」の段階で、UIフローも設計するようにしています。
マイナンバーカードの認証は、PCとスマホを行き来するような体験になるため、スマホ・PCの両方の体験をまとめています。システムの外のユーザー行動までまとめ、俯瞰して体験を想定できるようにしています。
狙いとしては、以下のようなものがあります。
画面を洗い出し、体験に対して必要な画面が抜け漏れないようにする
ユーザーの要求を満たせているのかを確認する
(特にバックエンド) エンジニアと先にすり合わせて、データ構造を想定しておく
(本来はプロトタイピングの前に行うことが多いのですが、今回はプロダクトマネージャーとフローの認識が揃っていたため、この順番で行いました。基本的にUIデザインは、抽象→具体...と進めるようにしています。)
ここまでの結果を資料としてまとめ、チェックポイントとして、再度プロダクト&PMOミーティングに持っていき、議論を行います。
無事、Step2も終わったので、「Step3. アジャイル開発」に入っていきます。ここでは、デザイナーは、スタイリングを整えることはもちろん、リリースまでの技術的な課題の解決のサポートや、リリース後のPR / 運用を円滑にするための関わり方をしています。
UIデザインを渡して終わり、というよりも、機能案が生まれてから、リリースされ、ユーザーに意図通り使ってもらうまでを、ずっと並走しているような働きかけを、クラウドサインのデザイナーはしているなと思います。
当初は簡易なシェイプでつくっていたプロトタイプを、コンポーネントライブラリを使いながら、精緻な形に整えていきます。
クラウドサインでは、どのようにユーザーに認識してもらいたいのか？ということも踏まえて、テキストの内容も、デザイナーが決めています。
また、機能によっては、ヘルプページを見なければ理解しづらいものも多くあります。UIでヘルプセンターの誘導を促す場合もあるので、デザイナーからヘルプドキュメントにどのような内容を記載して欲しいのかも伝えるようにしています。
後からツールチップを入れる場合、どこに埋めて欲しいというところも、デザイナーから細かく指定していきます。
ただスタイルを整えるというよりも、これまでの検証の流れで明確になった「ユーザーに届けたい体験」を確実に届けられるように、プロダクト全体のコミュニケーションを設計していくような意識で動いています。
開発において、技術的な課題があった時にも、積極的に議論に参加するようにします。
デザイナーの中には「技術的な課題はエンジニアじゃないと理解できない」と考えている方もいるかもしれませんが、私は、実はエンジニア同士での会話においても認識が揃っていないことはよくあるのではないかと思っています。
認識を揃えづらい難しい論点を、デザイナーが頑張って図解していく。そうすればエンジニア同士の理解も、エンジニア以外の職種の理解も促すことができ、課題解決につなげられます。
このような開発上の問題は、毎朝行っているStandupミーティングや、Slackでの会話を見てキャッチアップするようにしています。
(おそらく) デザイナーのことを信頼してくれているので、ユーザーが触れる部分の実装で迷うポイントは、エンジニアの方もよく相談してくれるため、そこに応えるようにして一緒にリリースまで並走していきます。
リリース前にもう一つ大事なのは、運用のための準備をしておくことです。
機能がリリースされたあと、ずっと同じプロダクトデザイナーが機能を担当できるわけでもありません。また、機能のPRに関する制作など、ブランドデザインに関わるところは、ブランドデザインチームが行うので、ユースケースや設計を理解してもらう必要があります。
そこで、今後のデザインの運用しやすさのために、勉強会を実施するようにしています。
例えば「マイナンバーカード署名機能」の場合は、そもそもマイナンバーカード / マイナンバーカード署名とは？というところをクイズのように伝えたり
想定ユースケースや、なぜ今リリースする必要があるのか。短期で追いかける指標があるというよりは、そもそも「新しい契約のかたち」をつくるための機能である、という位置付けについても詳しく伝えます。
このように丁寧に共有することで、誰でもこの機能に関する制作や、改善を行えるようになります。
こうして「マイナンバーカード署名機能」がリリースされました。
リリース後の結果は、これから現れるだろうと想定しています。法制度、マイナンバーカード自体の普及度など、プロダクト以外の変数が影響して、当たり前に使われているような状態とはまだなっていませんが、これからマイナンバーカード自体が普及していくと、はじめて利用できる環境になっていきます。
クラウドサインの特徴として、単にユーザーの使いやすさなどを想定した機能だけでなく、このようにそもそも業界の標準をアップデートするような機能開発も多く扱います。出してすぐ指標が上がる、というわけではないが、必ず出しておくべき機能にもチャレンジすることができて本質的だなと思います。
少し話がそれますが、私がクラウドサインに入社したきっかけは、「社会的にインパクトがあることをやりたい」と思ったことです。これから長く続く「あたらしい契約のかたち」を設計し、プロダクトに実装できたことは、とても嬉しい経験になりました。
このような取り組みによって、これまでクラウドサインには多くの機能が生まれてきました。どれも、丁寧な価値探索のプロセスを経て検討された、必要なのでつくられたものばかりです。急成長する中でも、シンプルな体験にこだわり続けました。
多くのプロダクトでは、事業が成長すると、PdMとUIデザイナーとエンジニアは明確に分業されてしまうこともあると思いますが、クラウドサインでは変わらずフラットな体制を維持することができています。
ここまで拡大してもクラウドサインの成長は止まりません。さらなる成長を目指して、いくつかの戦略を打ち出しています。
エンタープライズ企業などへの利用浸透に加えて、契約ライフサイクルマネジメントサービスとして契約締結だけではないプロダクト提供を目指しています。
今後、クラウドサインはこれまでよりも、幅広いお客さまに活用いただくことになり、契約管理、電子署名など、多岐にわたる機能がプロダクトに加わることにもなります。
それでも、クラウドサインのコアである「シンプルな体験」を守っていくために、プロダクト開発においては、より丁寧な価値探索のプロセスが重要になります。
すべては電子契約が当たり前になる世界に向けて。安心して、便利に使えるプロダクトづくりを今後も続けていきます。
