エンジニア、デザイナーも上流から参加！ユーザー課題に全員で向き合う、チーム開発の裏側とは？
LegalOn Technologiesの開発組織では、開発する機能やアプリケーション毎にPdM、デザイナー、エンジニアという異なる役割で構成された小中規模のチームで開発を進めています。
今回はその中でも、『LegalForceキャビネ』の機能開発を担うRisk Detectionチームの3名にインタビュー！ PdM、デザイナー、エンジニア3者それぞれの観点から、日々のチーム開発について語ってもらいました！
前編は実際の開発の進め方や上流から全員が参加するメリット、後編はチームの課題感や今後の展望にフォーカスし、2部にわたってお届けします。ぜひご覧ください！
乾 瑛美子（いぬい・えみこ） PdM
京都大学法学部卒業後、銀行員、法律事務所でのパラリーガルのキャリアを経て、2019年9月にLegalOn Technologiesへ参画。法務コンテンツの開発に1年ほど携わったのち、2020年7月よりPdMを担当。行政書士の資格も持つ。
矢野 りん（やの・りん） プロダクトデザイナー
美大卒業後、Webページの制作やアプリ開発のUI/UXデザイナーとして幅広い実績を積む。フリーランス時にはスマホ日本語入力の先駆けとなるキーボードアプリ「Simeji」を開発。2021年11月によりLegalOn Technologiesに参画し、現在はデザイン組織の責任者を務める。
木﨑 力（きざき・りき） バックエンドエンジニア
大学在学中は制御機械系のプログラマをしており、卒業後は金融系SIerでのSEを経て、交通系Webサービス企業のフルスタックエンジニアとして活躍。2022年10月よりバックエンドエンジニアとしてLegalOn Technologiesに参画。
企画と開発に垣根なし！エンジニアもデザイナーも、全員が上流から参加
ー まずは、皆さんのRisk Detectionチームについて教えてください。
乾 私たちは『LegalForceキャビネ』の機能開発をしています。
『LegalForceキャビネ』は締結済みの契約書をデータベースベース化し、契約管理の手間を軽減するプロダクトですが、その中でも契約書のリスク管理に繋がる機能をつくっているチームになります。
契約書は契約当事者の間で権利や義務を発生させる文書です。
締結後の管理が不十分だと気づかないうちに契約違反を犯してしまったり、不利な契約内容のまま自動更新してしまうなどの問題につながることもあります。
そうした契約リスクを回避するために、更新/終了の期限を知らせるアラート機能や、契約書の内容や期限など様々な項目で契約書を検索できる機能などを開発しています。
ー 開発はどのような流れで進めているのでしょうか？
矢野 企画と開発、大きく2つのフェーズに分けて開発を進めています。
LegalOnでは企画のフェーズを「Discovery」、開発のフェーズを「Delivery」と呼んでいます。
Discoveryフェーズでは、PdMが中心となって顧客のニーズや営業チームからの要望などをもとに、課題発掘と仮説の設定をします。
課題が特定され、顧客に価値ありと判断した場合、次にDeliveryというプロセスに移ります。
その際、PEMと呼ばれる開発チームの指揮をとる人が役割分担を決めます。
そしてプロダクト要求仕様書（PRD）の作成・業務フロー図の作成、画面デザイン、要件定義、工数見積、技術調査などを行って行きます。
チームごとに異なる部分もありますが、おおむねこんな流れで進めています。
― 企画を行う「Discovery」と開発を行う「Delivery」、大きく二つのフェーズに分かれているのですね。
乾 主にDiscoveryはPdMが、Deliveryはエンジニアとデザイナーが中心となって進めていくのですが、各フェーズでの役割は明確に区切ってはおらず、Discoveryの段階からエンジニアやデザイナーも関わっていくことが多いです。
例えば、課題を特定するためのユーザーヒアリングにも、エンジニアやデザイナーが一緒に参加して、どんなユーザーが課題を抱えているのか、その発生状況についてなど、実際のお客様に聞きながら調査をします。
課題が明らかになって実際にその課題を解決していくとなったら、図を書いて要求を整理するのですが、そこでもエンジニアやデザイナーに見てもらって、どんどん意見をもらっています。
お客様がどんな課題を抱えているのか、みんなで共通認識をもって解決に向けたアプローチを一緒に考えていきます。
お客様のヒアリングにエンジニアも同席。高い解像度でユーザーの課題解決に挑む
ー 何をつくるのか決める段階から、エンジニアやデザイナーも入るのですね！
木﨑 そうですね。会社や開発組織によっては、PdMが決めたものをあとはもう作るだけっていうところもあれば、上流の段階からエンジニアが入っていくところもあります。
自分はこれまでにどちらのパターンも経験しましたが、LegalOnはさらにその1歩先を行っている感じがします。
実際に触られている担当者様のところにも同席して話が聞けるというのは、ユーザー理解がすごくしやすい会社だなと。
ー ヒアリングまで一緒に行くというのは、あまりないケースですか？
木崎 エンジニアが同席するというのは、珍しいと思いますね。
乾 リリース後に行う効果検証でも、実際のお客様に開発した機能の使用状況や使い勝手などヒアリングをしているのですが、そこにも開発メンバーが同席しています。
自分たちがつくった機能がどの様に活用されてるのか、お客様からの声を直接受け取る事で次の開発に活かせる部分も多いですし、何か問題があった場合にはチーム全体で解決策を考えて行けるので。
木﨑 何よりも、自分たちが作った機能を使って喜んでくれている声を聞けるというのは純粋に嬉しいですし、モチベーションにもなりますね。
乾 開発メンバーがお客様の声を聞いてすごく喜んでいる姿を見ていると、「ユーザーにとにかく良いものを届けたい」という強い想いが伝わってきます！
ー 本当に、ユーザー志向が強いメンバーが多いのですね！
矢野 逆に、ユーザー志向でない人っていなくない？
木崎 確かに、ユーザーにとって良いプロダクトを作る為にできる事は何かを考えながら動いている人が多いですよね。
乾 だからこそ、お客様にしっかり価値を感じてもらえる機能を開発できているのだと感じます。やはり上流から一緒につくることで、お客様の課題やその発生状況をみんなが解像度高く理解できているというのは大きいと思います。
LegalOnでは、上流から関わる方が良いプロダクトを作れると考えて積極的に関わる人が多いですね。
ー 確かに、ユーザーへの価値提供を追求しているLegalOnだからこそ、そういった開発の進め方があるのかもしれませんね。
早期の目線合わせが、コミュニケーション効率アップや手戻り防止など様々なメリットをもたらす
ー Delivery（開発）フェーズでも、上流から入っていることによる良い影響はありますか？
木﨑 いろいろあると思います。
エンジニアとしては「なぜこの機能を作るのか」の背景を知った上で入れるところですかね。
最終的な課題解決に繋がっていることを確信しながら開発できるのは、心理的にかなりいいなと感じます。
あとは「何を作るか」についても、一度Discoveryの段階で議論の俎上にあげた上で決まっているので、腹落ちした状態で開発できています。
矢野 リリースしたものに関しては、結構みんな納得しながら作ってるよね。
あとはDiscoveryとDeliveryの間の役割にもいい感じにグラデーションがあって、早い段階から目線合わせができているので、ある程度出来上がってきた時に「え、思ってたのと違う」ってなることはあんまりないよね。
木﨑 ないですね。確かに、手戻りが少ないとのいうのは、めちゃくちゃ良いですね。
他にも、ユーザーの実際の業務フローや日々のペインポイントを理解している事で、実装もかなりスムーズに進められています。
ユーザー視点での使いやすさや使いづらさが感覚的に分かってくると、実装中に違和感がある部分を手早く修正できるので。
課題感の共有ができていることで、その都度PdMへの確認やユーザーアンケートを挟まなくても、エンジニア達で方向性を決めながら進められるところもあって、効率的でやりやすいです。
また、早期からデザイナーとも議論できることにより、UI/UXの観点でもっとよりいい機能や使いやすさというのはどういうものかを学べるので、そういったところも実際の開発にすごく活かせているなと実感しています。
矢野 デザイナーとしても、PdMといっしょに顧客や市場理解、製品への要求の整理を一緒にできるとデザインの方向性の絞り込みが早めにできますし、プロトタイプなど見えるかたちで検討を進めて、ユーザーも含めた合意形成が開発の前にできるのはよいことです。
また、開発に入ってからも、処理にかかる時間や読み込み範囲といったテクニカルな制約をいいかんじにカバーするアイデアを出し合うなど、お互いの知識を合わせて解消できることがいろいろあります。
ー エンジニアやデザイナーも上流から関わっていることで、ユーザーへの価値提供や実装面でも多くのメリットがあることが分かりました！
次回はぜひ、実際のチーム開発の様子ついてなど、より詳しく伺えればと思います！ありがとうございました。
