弁護士からみたプロダクト開発の難しさと面白さ

はじめまして。Holmesの開発本部・PMチームの酒井です。

10年弱に亘り弁護士として働いたのち、昨年Holmesに入社してからはCEO室室長として主に経営企画やセールス的な仕事をしてきました。プロダクト開発との関係では、Holmesの事業領域である契約業務のドメインエキスパートとして関与してきたのですが、先月より正式に開発本部・PMチームに異動となり、PMM（プロダクトマーケティングマネージャー）を拝命しました。つまり、プロダクトマネジメントについては完全な素人です。

 

今回は、そんな初心者PdMが、プロダクト開発に潜む溝とそれを克服するために実践していることをまとめてみました。

部門間の言葉の溝をなくす

まず、セールス側で働いていたときには、開発陣から発せられる言葉の意味は全く理解できていませんでした。アジャイル？スプリント？レビュー？インクリメント？何となくわかったつもりでいましたが、開発で働き始めたら何もわかっていなかったことがわかりました。無知の知です。また、同じ言葉なのに全く違う意味で使われている場面もありました。例えば、「リリース」という言葉を、開発は内部リリースの意味で使い、営業は外部リリースの意味で解釈し、マーケはプレスリリースの意味で捉えていました。コミュニケーションコストが高くて仕方ありません。

 

このように、言葉の理解や使い方一つとっても、開発とそれ以外の世界には大きな溝がありますが、この問題を克服するためには、一つひとつの言葉を大切に定義して、その定義を徹底するという地道な作業をしなければならないと思っています。ちなみに、弁護士という生き物は、言葉の定義に並々ならぬこだわりを持つ人種なので、そのバイアスがかかっているのかもしれません。（ちなみに、法律や利用規約においては、第１条が目的、第２条が定義と相場が決まっています。）

 

フィードバックの背後にある課題を想像する

Holmesでは、ユーザーの皆様から寄せられた全ての要望やクレームを、「顧客要望」としてセールスフォースに登録して管理しています。MVP（Minimum Viable Product：実行可能な最低限のプロダクト）の形で市場に投入するのは、ユーザーの皆様からのフィードバックをいただくためと言っても過言ではありません。

 

ただ、ユーザーのフィードバックを、きちんと理解せずに言葉通り受け止めるだけでは、其の背後にある本質的な課題を見逃すおそれがあります。「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう」とか、「ドリルを買いに来た人が欲しいのはドリルではなく穴である」といった格言が示すとおりです。ユーザーの言葉を理解するためには、ユーザー自身のことを理解しなければならないと強く感じます。

 

課題を理解するために、まずはユーザーを理解する

課題を特定するためには、前提として「ユーザー」をきちんと理解しなければなりません。そして、ユーザーの理解は、企業レベル・個人レベルの両方が必要です。企業としてのユーザーの規模、業種・業界、ビジネス構造、組織図はどうなっているのか。個人としてのユーザーの、部署、立場、日々の業務はどうなっているのか。一人ひとりのユーザーの視点に着目し、その一人の人にとっての世界を想像しなければ、自分たちが誰の、どのような課題に取り組まんとしているのか、迷子になってしまいます。

 

ホームズクラウドは、契約業務に関わらず全ての人の課題解決を目指していますが、契約業務には、法務部門だけでなく、事業部門やその他の管理部門、そして取引先などの様々な当事者が関与します。その分、ホームズクラウドのユーザーも多岐にわたり、必然的にユーザーの課題も多種多様です。

 

このような複雑・多様なユーザー課題を深堀りするために必要となるのがドメイン知識です。Holmesの開発組織では、ドメイン駆動設計（DDD）を取り入れています。Holmesには、私以外を含め、弁護士経験者が3名、司法試験合格者が1名、法務部経験者が1名いるのですが、これらのメンバーがプロダクトオーナーとスクラムメンバーにドメイン知識を共有する取り組みを進めています。開発が極めて専門性の高い領域であるのと同じように、契約業務も専門性が高く、独特の専門用語が飛び交う領域です。この２つの異なる世界線が交わるよう、共通言語を作っていくことこそ、Holmesのプロダクトマネージャーとして求められる役割なのではないかと考えています。

 

補論：弁護士業務との近似性

実はこの思考回路、弁護士がクライアントからの質問を受けるときに求められる姿勢と全く同じということに気づきました。たとえば、クライアントから「この契約書をレビューしてください」という依頼をうけたとき、契約書の文字面だけを見て、契約書の中の世界だけを見てレビューすることも可能です。ただ、実は、その契約によってやろうとしている取引自体が、法律上問題のある取引であるような場合もあります。だからこそ、弁護士は「このクライアントからの直接の依頼は契約書のレビューだけど、そもそもの問題点は取引の仕組みそのものにあるのではないか？」という想像が求められます。

 

また、裁判における事実認定の過程にも似ています。裁判では、「証拠上明らかな事実から、神様しか知り得ない客観的な事実を『推認』する」という過程を経て、事実認定が行われるのですが、目に見える事実を積み重ねて、過去の経験則（前提知識）に照らし合わせながら、目に見えない「顧客の本質的な課題」の仮説にたどり着くという開発における営みと親しいものに感じます。

 

今後の目標

ユーザーの本質的な課題を解決できるプロダクトを世の中に生み出すためには、開発言語、セールス言語、ドメイン知識という（同じ日本語のはずなのに）全然伝わらない3つの言語をうまく融合させることが必要不可欠です。そのためには、開発メンバーがセールスの言語を学び、セールスメンバーが開発の言語を学び、そして両者がドメイン知識を身につけることが必要になります。

 

持っている知識や経験が全く違う人たちが、相互理解を深めていくというのは簡単ではありません。そこのドメイン知識まで必要となると非常に高いハードルのように思えます。しかし、だからこそ、開発言語・セールス言語・ドメイン知識が三位一体の組織を創ることができれば、その組織そのものがHolmesという会社の競争優位の源泉になっていくのではないかと思っています。

 

Holmesでは、法務での経験をプロダクト開発やセールスに活かし、事業の中心として働きたいという人材を募集していますので、いつでもお気軽にご連絡ください！