ログラスは “経営管理” という複雑な業務を支援するプロダクトを開発しております。
複雑な業務ゆえに、ログラスのプロダクト開発では課題の難易度・複雑度が高く、1つのプロジェクトあたり約1ヶ月の期間を、要件定義からUIやモデル設計などの「What(何をつくるのか)」を決めるためのリサーチのプロセスに使っています。
ログラスでの、複雑な業務への解像度を高める探索フェーズの開発プロセスをまとめてみます。
ログラスは、2019年に創業した、経営管理をクラウドで完結できるBtoB SaaSの会社です。
会社として「良い景気を作ろう。」というミッションを掲げ、課題が山積みの経営のドメインに対してプロダクトを提供しています。
課題が山積みな経営のドメインに対してテクノロジーの力で解決策を提供し、良い景気を作ることを目指している
ログラスが取り組む経営管理という領域では、業務が非常に複雑で、それゆえに大きなペインが発生しています。
以下に示した図はあくまで課題の一部ですが、100社以上にヒアリングをした結果、経営企画の現場では、例えば以下のような業務が求められています。
経営管理に取り組む経営企画の方は、2000を超える部署の予算が入った表計算ソフトをメールで集めている
それらの表計算ソフトを一つ一つ開きながら、一つのファイルに統合していく作業を行う
足りない情報は、5レイヤーからなる組織構造のそれぞれの関係者からヒアリングしていく
それらを統合した予算計画を経営層に提案した上で、質問や指摘が入った部分は、説明責任があり、説明できない場合は改めて調査や修正をする
経営企画の現場では、業務が複雑なあまり、素早く正しい経営判断を行うことができていないのが実態です。
経営に関わる数値は間違えやすく、大企業ほど難しい。結果として経営判断が遅くなる。そのような状況をテクノロジーの力で解決するのがログラスです。
そんな経営管理という領域でプロダクトをつくるためには、企業や担当者ごとに決まったプロセスがない複雑な業務をうまく紐解き、シンプルな体験に統合する必要があります。
これまでにも経営管理の領域には、いくつもサービスが生まれていますが、どれも複雑な業務に合わせて、難解な体験となってしまっていました。
ログラスでは、そのように複雑になりがちな領域だからこそ、とことんシンプルな体験を提供することで、本当に現場で使いやすいプロダクトを目指しています。
ログラスでプロダクト開発に取り組むデザイナーとしては、複雑な業務を解像度高く理解したうえで、シンプルな体験に落とし込んでいくことが求められます。(ここが、ログラスでデザインする上で、難易度が高く、また、面白いポイントでもあります)
ログラスは初期と比較してプロダクトが高度化し、より複雑なプロセスを処理できる高度な開発が増えており、PdM・デザイナー・エンジニアそれぞれの領域で難易度があがっていました。
機能を作ったけど使われなかった...ということが絶対起こらないように探索（ディスカバリー）のプロセスに力を入れています。
具体的には、以下のような探索のためのアクションを約1ヶ月かけて取り組む開発フローを導入しています。
ドメインエキスパートへのヒアリング
ユーザーストーリーマッピングによる理想の体験とMVPを策定し、不確実性を潰しこむ
プロトタイプでのビルド＆スクラップ
ドメインモデリングで具体的なデータのあり方、変遷を設計
複雑な業務を正しく捉えて機能を開発するために、約1ヶ月を探索(リサーチ)に充てている
まず、要件を具体化するために、経営企画経験を持つ社内のCS(＝ドメインエキスパート)へのヒアリングからプロジェクトは開始します。
必要ならば、このタイミングでお客様にもお話にいくこともありますが、ログラスでは高い解像度で業務を把握しているドメインエキスパートが複数人社内にいるため、このようなステップを必須で取ることで要件の精度を上げることができます。(*1)
また、このヒアリングの前後で、ユーザーにとって理想的な体験を表したUIを作成する場合もあります。
「何をつくるのか」が空中戦にならないように、実装面の難易度はあえて考慮せず、理想的なUIをつくっておく
お客様の業務内容や課題が複雑な時は、何をつくるべきか、議論が空中戦になってしまうことが多々あります。そのため、チームとして同じゴールを具体的にイメージできるように、実装面の難易度はあえて考慮せず、理想的なUIをしれっとつくっておきます。
この理想的なUIは、実装するために提案するのではなく、あくまでチームの目線をあわせ議論を地上戦に持ってくるためにつくっています。これがあることで、具体的な画面をベースにしながら「理想はどうあるべきか」「技術課題はどこで発生するか」を正しく議論することができ、プロジェクトの前進に貢献できます。(*2)
ドメインエキスパートへのヒアリングを終え、理想的なUIがメンバーの頭にある状態で、具体的な今回の開発スコープを決めていきます。
ここでは、ユーザーストーリーマッピングを用いて整理を行います。
ユーザーストーリーマッピングは、解決したい課題(why)がある程度決まっている機能の開発にとてもオススメです。
特に、ログラスのドメインは複雑な業務をデジタルプロダクト上で成立させないといけないため、チーム内の目線合わせや、今分かっていることはなにか？分かっていないことは何か？の不確実性を潰しこむことに効果を発揮します。
不確実性のあるところは具体的なアクションに落とし込みます。
ここでリリーススライスを切ることで、どこまでの機能やアウトカムを作ればMVPとなるのか、MVPのあとにはどんなリリーススライスを切るべきかも作成できるので、より解像度があがります。
ユーザーストーリーマッピングのお陰で、メンバーの暗黙知を視覚的に表現することで、効果的なコラボレーションと知識・ステータスの共有ができています。
この工程をPdMや誰か1人に任せるのではなく、PdM・デザイナー・エンジニアが一丸となってチームで解決できる状態を作ることで、有機的でスケールしていけるチームへ成長していきます。
現実的に開発のスコープを決めたら、ドメインエキスパートやチームメンバーでプロトタイプのテストを行います。
プロトタイプのデザイン作成は時間をかけず、途中の状態でもいいので、周りを巻き込みながら作成できる方法を取るようにしています。
これは、ドメインと技術的な制約が難しくデザイナー単体では全てを紐解くのが難しいという観点があるため、デザイナーでボールを持ち過ぎない方が良いと考えているためです。
特にデザインを作るターンとデザインをレビューするターンを明確に分け過ぎてしまうと、何度もレビューと修正のループが走ってしまい逆に効率が悪くなったり、デザイナーのメンタルとしても辛くなる傾向があるので、避けた方が良いです。
このプロセスはデザイナーによって進め方が違いますが、以下のようなアプローチを取る事で効果的にデザインを進めることができるため、積極的に取り入れるようにしています。
| ライブデザイン バーチャルオフィスなどのチーム部屋で、勝手に画面共有をしてデザインの制作工程を垂れ流し、困った時・悩んだ時はその場でエンジニアに声かけて解決ができるようにしています。
エンジニアやPdMも気になってのぞいたり、「このUI良いですね、ここは仕様上結構厳しい…」と意見を勝手に言ってくれたりします。
| ペアデザイン
ペアデザインは2人以上で一緒にデザインを作成します。ライブデザインと違うのは、メンバーと時間を明確に抑えてデザインを作成する点です。
メンバーは3名ぐらいがベストだと思っており
デザイナー×2＋エンジニア
デザイナー×2＋PdM
デザイナー＋エンジニア＋PdM
このような組み合わせで開催するようにしています。
デザイナーを2名にすると、思想の部分だったり、ユーザーがどう感じて使っていけるかなどメンタルモデルの部分まで深く議論・学びがあるので、良い化学反応が起こります。
また、ここにPdMやエンジニアなども巻き込む事でソリューションの最適化も効率的に行えます。デザインに対する理解度・可能性を他職種の人に感じ取ってもらえるという副産物も生まれるのでオススメです。
| デザイン壁打ち会
デザイナー同士でデザインレビューをする会です。UIやUXに関して専門的なディスカッション・セカンドオピニオンを得られる会となっています。毎日、夕方30分だけ時間を押さえていて、その場には何でも持ってきて相談・話ができます。
デザインは完成したものではなく、できる限り途中のものを持ってくることを意識しています。
これは、途中のものであれば、そのレビューを反映しやすく、デザイナーのメンタル的にもデザインレビューに対するハードルを高めないようにするためです。「レビュー辛い」という状態より「レビューが楽しい」「議論が広がる」という状況を作ろうとしています。
ユーザーストーリーマッピング、プロトタイプと、実装面の整合性を取っていくために、ドメインモデリングを行います。
プロトタイプデザインがある程度できてから実施する場合もありますし、その逆もあります。特にデータの処理・流れが複雑になる場合は、ドメインモデリングを先に実施することで複雑な処理でもプロトタイプデザインの整合性が担保できるようにします。
ドメインモデリングはPdM・エンジニア・デザイナーで実施します。場合によってはドメインエキスパートも招待しています。
上記の画像はLoglass内のとある機能におけるデータの状態変更のパターンを図示したものになります。業務で求められる複雑な処理を視覚化することで、技術的な成約をチームメンバーが正しく認識し、どういったソリューションなら課題を解決でき、良い体験を作れるのかを議論することに集中できます。
===
このような探索のプロセスを踏まえて、実装段階に進んでいきます。
Loglassのプロダクト開発では、大きなクライアントも多く、一つ一つの機能の開発難度も高いため、毎回のリリースで確実に使われるものを出していくことが求められます。
そのため、とにかく業務の解像度を高め、丁寧なリサーチからUI、実装の両面から検討を行い、開発前に使われる確信がある状態とすることを意識しています。
業務の解像度を高めるために、開発プロセス以外にも、組織としてドメイン理解を支えるしくみを用意しています。
特にデザイナーとして活用しているしくみをいくつか紹介します。
各プロジェクトでリサーチを繰り返すなかで、お客様の業務フローの一般化できる部分が見えてきていたので、そこは全プロジェクト共通の情報として残しています。
あくまで全体観がわかる補足資料としてですが、プロジェクトの動き出しを早める情報としてこのようなものがあると機能しやすくなります。
前述したように、社内にはドメインエキスパートが複数名おり、いつでもドメインのことをキャッチアップできるようになっています。
社内に複数いるドメインエキスパートをうまく頼りながら業務を進めることができる
さらに、これまでの商談動画や、ヒアリングの動画はすべて蓄積されているので、新しくLoglassに関わるデザイナーも早くドメインのキャッチアップを行うことができます。
新規事業領域のデザイナーkouさんも、このようなしくみを使って、ドメインを早く掴むための動き方を事例としてまとめてくれています。
丁寧な探索プロセスや、ドメイン理解を支えるしくみによって、Loglassがお客様から導入される理由の一つに「プロダクトの使いやすさ」をあげていただけるようになっています。
体験やユーザビリティが導入における優位性になっている
これは、経営管理という領域で、過去にここまで丁寧にドメイン理解に取り組みデザインに投資したプレイヤーが少ないということでもあると思います。つまり、デザイナーとしてログラスに関わることで、本当に現場で使われるプロダクトへと成長させることができる。そこに意義を感じています。
また、新しく関わるメンバーも、ドメイン理解をしっかり進めた上で働けるようになっています。実際、これまでは3ヶ月ほどかかっていたリリースサイクルが、今では1ヶ月に2〜3機能のリリースができるようになっており、良い循環ができてきました。
前述したように、ログラスが取り組む経営管理という領域は、業務も複雑で、かつ企業や担当によってもプロセスが異なるため、ドメイン理解がかなり難しい領域です。
ただ、そんな領域に対して、シンプルなプロダクトの体験を提供しようとしているログラスでは、デザイナーが貢献できる範囲は非常に大きいと思います。
事実、ログラスではUIやプロダクトの体験を評価していただいてサービスを導入いただいている声も多くいただいており、これからも組織拡大する予定です。数年後には正社員だけで40名規模のデザイン組織を目指しています。
複雑な経営管理の業務をシンプルにするログラスで、今回まとめたような探索のプロセスをさらに磨いていけるよう、引き続き取り組んでいきます。