この記事はスタンバイAdventCalendar2023の10日目の記事です。

はじめに

こんにちは。スタンバイでプロダクトオーナー（PO）としてtoC領域を担当している城本です。

今回は、「ビジネス」と「開発」の連携というテーマで少しお話してみようかと思います。

新米POとしてまだまだ未熟な私ですが、「ビジネス」と「開発」に限らず、立場の異なる部門とのコミュニケーションってなかなか難しいと感じたことはありませんか？
ユーザーに価値を届けるという目的は一つのはずなのに、うまく意思疎通が図れない。協力して共に成果をあげたいと思いやっているはずなのに、なぜかモヤモヤ。そんな経験、ないでしょうか？

企業規模や組織構造によって、事情が大きく異なるテーマではありますが、ビジネス部門と開発部門の連携で成果をあげることができた経験を基に、気持ち良く協働し、ひいては成果に繋げていくための工夫を、自分なりに振り返ってみたいと思います。新米PO故、初心者向けの内容であることはご留意ください。

連携を困難にするのは何か？

開発とビジネスの連携はなぜ難しいのか？一般的によく挙げられるのは以下ではないでしょうか。

開発サイドはビジネス要件を理解していないし、ビジネスサイドは開発要件を理解していない
お互いの日々の業務が見えていないために共通言語で話すことができず、コミュニケーションコストが高い
開発が成し遂げたいこととビジネスが成し遂げたいことが必ずしも一致しておらず、お互いが見ているゴールが若干ずれていることでいつまでも認識が揃わない

相互理解がなく、ゴール認識がずれた状態で無理やり連携しようとすると、お互いにとって非常識なやり方で依頼をしてしまったり、どちらでボールを持つべきか曖昧な状態のまま重要なことを相手任せにして案件が進んでしまったり、なかなか幸せな未来は見えなさそうです。

スタンバイにおける開発とビジネスの距離

スタンバイに入社して１年半が経ちますが、ビジネスと開発の距離の近さは入社当時、とても驚いたことを覚えています。

スタンバイでは、新規機能の計画時は早い段階からビジネス部門への巻き込みを行います。なぜこの機能を作るのか？ユーザーにとってのメリットは？いつ実現するのか？一つずつ認識をあわせ、見落としている要素がないかを確認しながらロードマップ化を進めていきます。

当たり前ですが、新規機能は作っただけで終わりではありません。スタンバイの場合だと、作った機能を広告主であるお客様に導入してもらい、使ってもらって初めて価値が出せるタイプの案件も多く存在します。ビジネス側の導入提案の品質次第でも成果が大きく上下し、まさにビジネスと開発が両輪で動かなければ高い成果は望めません。

早い段階からプロジェクト（PJ）の全体概要をビジネスへ共有し、ゴールの認識を揃え、達成するために足りていない要素や認識の違う観点をレビューしあい、お互いに軌道修正をしながら解像度を高めていきます。必要な相互理解が前提にあり、ビジネスも開発も共通のゴールやそのためのアクションプランを忌憚なく意見しあえることで、お互いに職責を果たしながら最短で成果創出に向かうことができていると感じます。

ビジネスメンバーと開発メンバーがともに議論・共有するための定例MTGは社内を見渡せばそこらじゅうで行われているわけですが、このような環境が当たり前にあるからこそ相互理解が進み、ビジネス連携がしやすいのだろうと感じています。

距離を縮める7STEP

これだけだと、単に「コミュニケーション量を増やせ」という話に終始してしまいそうなので、ここで具体的にやったことと、開発メンバーがビジネス部門に対する理解を深めるために、やってよかったことをいくつかご紹介したいと思います。

STEP1：まずはキックオフ

当たり前すぎたら読み飛ばしてください。キックオフの質はとても大切です。抜かりなく準備しましょう。
関係者を集め、PJの全体概要を共有し、共通のゴールを作りましょう。フォーマットとしてはインセプションデッキなどが有名でしょうか。世の中にはたくさんのわかりやすい記事が存在しているので、よく知らないよという方はぜひ調べてみてください。

最初はゴールのすり合わせだけで数回議論を重ねることになるかもしれませんが、ここがPJ成功に向けた踏ん張りどころです。最初は相手の意見が非合理に思えることも、相手の立場を理解した状態で改めて見ると、大抵のケースで合理性があることに気づくのは私の経験則です。最初に意見が食い違うことがあっても、急がば回れの精神で土台を整えましょう。

STEP2：定期的なコミュニケーションの場を設定してしまおう

隔週や月１など、最適な頻度で先に定例をいれてしまいましょう。ダラダラ議論を防ぐため、最初は30分がおすすめです。相手も忙しいので嫌がられるのでは…と躊躇するかもしれませんが、短時間のMTGにすると事前準備をしないとなかなか議題が消化できないので、準備に時間をかけるようになります。結果的に効率的なコミュニケーションにつながるはずです。PJのフェーズにあわせて頻度は調整していきましょう。

STEP3：顧客向けの提案書が必要な場合は一緒に作ろう

一緒にお客様への提案方法を考えることは、開発がビジネスを理解するための効率の良いトライになります。特に顧客への導入を目的とする場合、顧客の理解を得る上で定量的なデータはきちんと開発サイドからも意見を出し、提案書に盛り込みましょう。顧客にとって、やるメリットややるべき理由をしっかり理解していただくための工夫には、ぜひ適切な時間を割いてください。

このデータ提示に、当初私はとても苦戦をし、開発目線で「顧客には定量的にこういったメリットを提供できるので、これを根拠にすると導入を提案しやすいのでは？」と数字を出したところ、「お客様はこの数字はあまり見ていない。こういう観点で考えてみてはどうか」と何度もアドバイスをもらいました。
基礎的な顧客理解を基に考えるのはもちろん、ほとんど同じことを言っていても顧客目線でメリットを感じてもらえる表現を心がけるというコツを掴むこともでき、振り返るととても良い経験です。

STEP4：提案に同行しよう

提案書ができたら次は提案です。可能であれば開発も顧客提案に同行してみましょう。忙しい方もぜひ1度は経験するのがおすすめです。百聞は一見にしかず。顧客理解が深まり、同じ目線での議論を一層スムーズにしてくれます。

個人的には、なぜあんなにスタンバイのビジネス部門の皆さんは流暢にわかりやすく、おまけに超絶感じよくお客様とコミュニケーションをとれるのか、ビジネス部門への一層のリスペクトを育むこと間違いなしです。

STEP5：質問しやすい環境をつくろう

実際に顧客と接するビジネス部門のメンバーは、顧客から日々技術的な質問も受けています。さらには、個別の事情にカスタマイズした提案をするために機能のかなり細かい仕様を知りたいケースもあります。

開発として、よくある質問をFAQページにまとめ、ビジネス部門のメンバーが見れるようにしておきましょう。また、質問したい時のフローを認識合わせしておくと便利です。例えば「slackチャンネルで誰々さん宛に。質問フォーマットはこれ。」くらいの粒度でOKです。新規の質問はFAQへの追加を欠かさないようにすると二度手間が防げます。

STEP6：ゴールまでの進捗を確認しよう

定例MTGの場があれば自然と確認できると思いますが、ロードマップ通りに進んでいるか。このまま行けばゴールを達成できるかの確認は定期的に行いましょう。

機能のデリバリーは予定通りになりそうか？提案の中で発見した新たな追加要件はないか？また、その追加要件は初期スコープに含めるか含めないか？など考えるべきことは多岐です。ロードマップの変更も視野に、ビジネス部門と共により良い進め方を意思決定していきましょう。

また、ビジネスからは、定量的な目標の達成に向けて、提案数は足りているか？提案数は足りているが決定率が悪いのか？といった共有も大事です。提案数が足りていない時に、提案リストの拡充とウェビナー実施をビジネス部門が取りまとめてくれたことがあります。開発として機能紹介や質問コーナーでの回答者として参加を依頼されたのですが、ビジネス部門のあの動きがなければ目標を達成することは困難だったのではないかと思います。そういった議論も定例MTGの中で話題にできるとベストですね。

STEP7：小さい成果を褒め合おう

ある程度プロセスがまわるようになってきたら最後はここです。
スタンバイのビジネス部門の空気はとても自由闊達で明るく、小さな成果でもslackチャンネルが定期的に盛り上がります。最終ゴールの到達までは長い道のりです。プロセスにも焦点を当てて、互いに小さな成果を褒め合い、ぜひ感謝を伝えてくださいね。

最後に

思えばこの１年半、入社当時から現在に至るまでビジネス部門の皆さんには勉強させてもらってばかりです。基本とも言えるであろう紹介させてもらったSTEPは、ビジネス部門から率先して整えて下さったり、意見をだしあって改善したりと、おかげ様で気持ちの良い連携が実現できていると感じます。このような動きがあるからこそ、ビジネスと開発の連携案件において、目標達成の高い打率を再現性高く保てているのではないでしょうか。

企業規模や組織構造によって、参考にできる部分・できない部分があるかと思いますが、何かしら考えるヒントになれば幸いです。

この場をお借りして、ビジネス部門の皆様に感謝をお伝えしたいと思います。
これからも、ユーザーにとって価値あるプロダクトを目指して、一丸となって切磋琢磨していきましょう！