【開発クロスインタビュー】常に本質に立ち返りながら、仮説検証を素早く回し続ける。「すべては顧客の課題解決のために」と真正面から向き合える開発チームの強み
「ContractS CLM」が正式にリリースされて早4年。ContractSの組織は事業の成長に伴い、60人超もの組織に急拡大し、今もなお、コロナ禍においても積極的に採用活動を続けています。
その約半数のメンバーを占めるのは、ContractSの開発部門。昨年からは開発者ブログを立ち上げ、各メンバーが日々チャレンジしている技術領域を紹介してきました。
今年は、彼らの日々のチャレンジの「背景」や、ものづくりにおいて大事にしている「心構え」など”想い”の部分にスポットライトを当て、様々な切り口で開発メンバーを紹介していきます。
今回は同じチームのプロダクトオーナー（三内・写真右）と開発メンバー（友野・写真左）それぞれの立場から、プロダクト開発プロセスについて語ってもらいました。
「この機能のフィードバックは誰にもらうのが適切か」という疑問から掘り起こされた、根本的なチーム課題。ドメイン駆動設計を通じ、顧客の課題と真正面から向き合えるように
守屋 ContractSに入って、それぞれ約1年・半年が経った三内さんと友野さんですが、これまでを振り返って、入社時にイメージしていたものと実業務とでどんな違いや変化を感じましたか？
三内 シンプルに一番大きい変化は、顧客の課題に真正面に対処できるようになったことですね。
入社直後は、プロダクトに対する知識もそうですが、スクラムチームに入ったことが初めてだったので、1週間スプリントという短いスパンで改修を繰り返すスピード感に追いつくのが精一杯で。顧客の課題はなんだっけ？ということを振り返りたい意識はあったものの、余裕がなかったんですよね。
友野 私も全く同じところに課題感を持っていましたね。入社時はdev/opsでイテレーションを回していくようなイメージでいたんですが、ContractSの開発組織って、プロダクトバックログをプロダクトオーナーがものすごく丁寧に作り込んでいたんですよ。良くも悪くも、課題や実装すべき機能の詳細が丁寧に書かれているので、スプリント中はとにかく作ることに集中してしまって。ついつい自分たちのキャパシティのぎりぎりまでタスクを詰め込んでしまうんです。でもそれだと、次のスプリントで取り組む顧客の課題を先に深堀りして考えたりする余裕を作れなくて、結局また丁寧に作り込まれたバックログを消化するだけになってしまうんですよね。
守屋 顧客の課題に真正面に対処できるようになったきっかけってなんですか？
三内 きっかけは、スプリントレビューの準備をしている時に「この機能に対するフィードバックは誰にもらうのが適切なんだろう？」とふと分からなくなった時ですね。
それまでスプリントレビューで得られるフィードバックは「このボタンが分かりづらい」とか「この文言だと迷う」といったUIに関する指摘がほとんどでした。それが何故かを考えると「どんな顧客のどんな課題を解決したいのか」を伝えていなかったからだと気づきました。そこからさらに遡ると、自分たち自身も顧客の課題に対して向き合えていない。だから、インクリメントへのフィードバックも良いか悪いかふわっとしてしまっていたのだな…と。
この現状を変えるために、「まずはチームとして顧客の課題に向き合えるようにしよう」と意思統一し、チーム全体でプロダクトバックログへの向き合い方を変えていきました。
友野 得たいフィードバックから逆算していく中で、プロダクトオーナーがガチガチに”How”のレベルまで決めたものから着手していた状態から、その裏を想像するようになれたのは、確かに大きな変化でしたよね。
アーキテクチャの観点でも、これまではデータベースのスキーム中心で考えられたプロダクト設計だったので、具体的な仕様さえ決まっていれば、それを手続き的にコードで表すことは容易にできてしまっていました。
それが、いざドメイン駆動設計（以下DDD）を実践しようと思うと、これまでデータベースに依存していたロジックをビジネスルールに依存させないといけなくなるので、例えば「この情報の公開／非公開を制御したい背景がわからないと、どのドメインで実現すべきか判断できないよね」という状態になるんですね。
▼友野が執筆した、DDDの実践に向けた取り組みの過程についてのブログ
三内 アーキテクチャが一人ひとりの意識を自然と変えていったという点でも、ドメイン駆動設計を実践し始めたことは、とても大きな転機でしたね。
友野 実際に手を動かしてものづくりをしている私達エンジニア一人ひとりが、プロダクトが解決しようとしている課題や、抽象的な「ContractS CLMの目指す先」みたいなものの解像度をもっともっと高められれば、結果的にプロダクト開発はものすごく速くなると思うんです。
「それって本当に顧客の課題解決に役立つことなんだよね?」が実装側のメンバーの口癖に。仮説検証サイクルが一番速いスクラムチームが本質に立ち返っていることの強み
守屋 お二人の在籍するチームでは、顧客の課題を把握するために、カスタマーサクセスやセールスのメンバーにも積極的にヒアリングしている姿が印象的でした。
友野 これはもう、プロダクトオーナー様様ですね（笑）
三内 いやいや、実際は開発チームから突っつかれるんですよ（笑）
「このユースケース・このパターンはどんなデータが入るの？」とか、「この画面ではどんな情報が書き込まれるのか具体例を教えて」とか…。知ってても知らなくても実装する上では結果は変わらないことかもしれないんですが、「本当に顧客の課題解決に役立つことだよね？」ということを一人ひとりが強く意識していることが伝わってきています。だからこそ、慌てて色々な人から実例を元にした声を集めるように努めました。
友野 私たちのチームは、「既存のプロダクトに対する顧客課題の解決」をチームミッションに抱えるチームなので、特に学習サイクルを速く回しやすいチームだと思うんです。
そういう環境だと、どうしても目先にやるべきことだけを捉えがちなのですが、今は、”責務”や”概念”という言葉から立ち返っているので、特に変化が大きいと感じるんです。
仮説検証サイクルが一番速いはずのチームが、本質的な課題に立ち返りながらそれを実現できているのって大きいですよね。もちろん、まだまだ改善の余地はありますが。
顧客課題のすべてはContractSのミッションと紐づいている必要がある。モデリングを通して具体的な絵をしっかり描き、1週間スプリントともシンクロさせながら、全社員で顧客課題に向き合える組織へ
守屋 対して、現在もまだ解決されていないと感じる”構造上の課題”はどんなものがありますか？
三内 ミッションを実現するために解決すべき課題は、まだまだ無数にあるというのが正直なところです。今は”やっとドアの隙間から光が見えた状態”にあるかなと。
私達は1週間というスプリント期間で開発サイクルを回していますが、顧客と直接コミュニケーションを取っている営業やCSのチームともしっかり意思疎通を行い、このリズムを共有したいと思っています。
意思疎通の話って、顧客の課題を認識する「開発前のプロセス」と、実際に実現した課題解決のソリューションを共有する「開発後のプロセス」とで2つに分かれると思うんですが、特に前者がまだ弱いと感じています。
我々が解決する顧客課題のすべてはContractSのミッションと紐付いている必要があるので、顧客の課題を発見する営みにContractSで働いている全社員が深く関わっている状態にしないといけない。この「全員で顧客の課題を発見してプロダクトを育てていく」プロセスが一週間という開発のスプリント期間とうまくシンクロすれば、課題解決や仮説検証のスピードを劇的に向上できる。そのための仕組みの構築を早期に実現したいと思っています。
友野 私は、この顧客の課題認識についての意思疎通をする上で、モデリングの可能性というものを信じているんです。
モデリングって、実装に近い領域でも一定の価値はありますが、それだけではなくて。本来やりたいことや課題を特定するために我々の実現したい世界を見える化するプロセスなんですよね。
共通言語として「我々が目指す世界はこうなんだよ」「みんなここに向かっているんだよ」というのを具体的に絵として描きながらディスカッションできる。成果物としてのモデルの価値だけではなくて、それを描く過程で意識が統一されていく。このプロセスをより多くの人と共有できれば、自然と意思疎通ができるようになるんじゃないかと思っているんです。
長期的な世界観を見据えたプロダクト開発に取り組む、“300年続く事業の4年目”にある組織だからこそ。求める人材は、ソフトウェアのライフサイクルを意識できる人、そして、ビジョンを具体化できる人。
守屋 プロダクトの成長に伴って、これからも開発メンバーは次々と増えていくと思いますが、お二人はどんな人に仲間にきてほしいですか？
友野 抽象的かもしれませんが、シンプルにエンジニアリングをしっかりできる人ですね。エンジニアリングって課題解決するスキルなので、課題解決に真摯に向かう姿勢を持つことそのものに人材としての価値があると思うんです。
あとは、「ContractS CLM」の成長フェーズを意識した話をすると、ソフトウェアのライフサイクルを考えられる人、という感じでしょうか。極論、課題というのは、解決しようと思えば汚くコードを書いて済ませることもできるんです。でもContractSがそれをやらないのは、CLMという市場の可能性の大きさを信じていたり、300年続く事業の4年目にあるという、長期的な世界観を見据えてプロダクト開発に取り組んでいるからなんですよね。その意味で、中長期のソフトウェアのライフサイクルを意識してエンジニアリングができる人は、ContractSの戦力としてフィットする方だと感じています！
三内 友野さんに美味しいところを言われてしまいましたが（笑）、おそらく読者に身近であろう例に例えると、「HUNTER×HUNTER」でいう、具現化能力を備えてる人ですね。開発チームが発揮できるスキルというのは、詰まるところ、「ビジョンを具現化できる能力」だと思うんです。そこにこだわりきる人にぜひジョインしていただき、一緒に明るい未来をつくっていきたいですね！この想いに共感していただける未来の仲間に出会えることを楽しみにしています！
ContractSへ興味をもってくださった方はぜひご応募をお待ちしています！
🚩エントリーページはこちら🚩
この記事が気に入ったらサポートをしてみませんか？