デザイナーが作る、組織の情報共有の仕組み 〜急拡大する組織の中でサービスを作り続ける〜
こんにちは、LegalForceでサービスの UI / UX デザインを担当しています、鈴木智絵（@Sakurampoo）です。
こちらの note は、2021.10.23-24 に行われる Designship2021 でお話しさせていただく内容をまとめたものです。
当日の発表時間の約4分半では話しきれない部分がたくさんあるので、少し内容を補足しつつ書いてみました。
LegalForceとは？
株式会社LegalForce は「全ての契約リスクを制御可能にする。」をミッションとする、2017年4月創業のリーガルテックのスタートアップです。
企業の法務部や、弁護士事務所で働く方に向けた、「契約業務」をサポートするサービスを開発・提供しています。
サービスの特徴は、AI を活用した機能群。代表的な機能は、契約書をアップロードすると、一般的な論点で構成されたチェックリストと突合し、その場で契約書の危ない箇所を発見できる「自動チェック機能」でしょうか。
そんな自動チェック機能を搭載した、当社の1つ目のサービスである LegalForce は、2019年4月に正式版をリリースし、今年2021年の夏に初の CM を放映しました。
入社直後に感じた「難しさ」
さて、私はそんな株式会社LegalForce に、1 人目の UI/UX デザイナーとしてジョインしました。
あれから約3年。もちろん色んな問題はありました。その中で一番「難しいな」と感じたことは
「作りたいものを、正確にステークホルダーに伝える」ことです。
サービス開発に関わる誰もが経験したことがあると思います。間違って情報が伝わって開発が進んでしまい、手戻りが発生した時の時間のロス。その時の「やってしまった…」というストレス。
もちろん、前職でも UI デザイナーとして働いていたので、その難しさは分かっていました。ただ、前職とは違ういくつかの要因が、情報共有をより難しくしているように感じました。
何が情報共有を難しくしているのか
BtoB ツールならではの要因
まず、当社のサービスは法務領域の知識がないと、サービスがどう使われるのか理解しにくいという特徴があります。私も、潜在・既存ユーザーの方に何度も何度もヒアリングをさせていただき、全体像をつかんできました。
加えて、これは AI を活用していることにも依るのですが、見えない部分での内部処理が複雑です。
総じて、開発以前のサービスそのものを理解するために、さまざまな知識が必要です。（もちろん、そこが BtoB の面白さの一つでもあります。）
スタートアップならではの要因
それでもずっと同じメンバーだけで開発ができれば、ある程度は時間が解決してくれます。ただ、ここはスタートアップならではと言いますか。
特に初期は副業としてスポットで関わる方も多く、なかなか時間をかけて文脈を共有することができません。
また、どうしても開発スピードを優先したい場面が多く、毎度しっかりと仕様書を作る時間も、人手も足りませんでした。
このまま何もしないと…
さらに、この 2 年で従業員数が 5 倍以上になりました。この増加スピードでは、毎月のように入社する社員全員に、1 から説明するのもなかなか大変です。
このままだと、自分の時間が情報共有に取られる一方。とはいえその手を抜けば認識齟齬が繰り返され、開発組織が疲れて最悪崩壊しかねない。
私に何ができるかな？と考えました。
デザイナーの強みとは？
開発の中の情報共有において、デザイナーはいくつかの強みがあると思います。
1つ目は、最終アウトプットが「絵」である場合が多いこと。機能 1つとっても、画面イメージがあるだけで想像しやすさがグッと変わりますよね。(ここでの「絵」とはビジュアルデザインではなく、何かを可視化したもの、という意味です。)
2つ目は、企画と実装の間のフェーズを担当していること。様々な職種とコミュニケーションを取らないと仕事にならない分、情報が集まりやすい。
組織の形が変わると、どんな情報がどこで足りないのかが変わってきます。デザイナーは情報が集まりやすい分、どのフェーズで改善が必要なのか特別なことをしなくても把握しやすいポジションにいるな、と思いました。
そこで、これらの強みを活かして、組織のフェーズに合わせた情報共有のための施策を、デザイナー主導でいくつか行いました。
初期フェーズ
まず、開発仕様書のテンプレートを作成しました。これは、この問題を認識してから始めに取り掛かかったものです。今でも私が、定期的にアップデートをし続けています。これは、
・入社したての人でも、このテンプレートを埋めれば最低限必要なチェックポイントを確認できる
・この機能仕様に至るまでの文脈を、後から見返しやすい形で残す
ことを目標に、開発メンバー全員で埋めていくものとして作りました。
この仕様書の内容については、話し始めると長いので、別途まとめた note を書こうかなと思っています。
職種混合のチームでサービスを作るフェーズ
次に UI 制作を行うタイミングから他職種を巻き込み、説明コストを減らしました。
全社のコミュニケーションツールとして使っているSlack上で公開しながら行うデザインレビュー。Webミーティングに集まり、話しながら UI を作るモブデザイン会などがそれです。
初期はウォーターフォールに近い形で開発をしていたのですが、途中から職種混合のチーム単位で動き、その全員が上流工程から下流工程まで関わる、という形に変わりました。
特にそのような形になってから、デザイナー以外が積極的に発言するようになり、効果を発揮し始めたように思います。
複数のチームで1つのサービスを作るフェーズ
最近は、職種混合のチームがだいぶ増え、今度は隣のチームでどんなことをやっているのか？が見えづらくなってきました。
フロント、サーバー、インフラ、デザイン、QAと、職能別に集まって情報共有は行いますが、その場合どうしても技術的な話が中心になります。
とはいえ、隣のチームが何故その機能を作っているのかを知らないという状態は、各々のチームが違った方向を向きかねないなと思いました。
そこで、Webミーティングでデザインレビュー会を行い、それを公開しています。この会では、UIへの言及に加え、「なぜこの機能を作るのか？」の背景情報の説明を厚くするようにしています。
今後やりたいこと
今まで様々な情報共有の場を作ってきましたが、今やりたいことは、開発と営業の情報交換の場を作ることです。
以前はよく立ち話をしていた営業メンバーとも、人数拡大とリモートワーク中心の生活スタイルになり、どうしても接点が減ってきました。新しく入社した人は尚更です。
開発目線ですが「今日リリースしたこの機能は、あの人が作っているんだな」と営業の人が想像できる状態を、まずは目指したいなと思っています。
まとめ
スタートアップだからこそ、開発スピードも組織も保っていくために、誰か一人の負担にならない情報共有の仕組みを作ることが重要です。また、デザイナーの立ち位置は、その仕組みを作りやすいポジションにいます。
サービスを作るだけではなく、「開発のやり方」を作ることにも、引き続きデザイナーとして関わっていくつもりです。