開発とビジネス、立場による「すれ違い」をなくす3つのアクション
こんにちは、グローバル・ブレイン（GB）の二宮と申します。
GBでは、出資先スタートアップのハンズオン支援を専門とする「Value Up Team（VUT）」の一員として、複数社のスタートアップのプロダクト開発をサポートしています。かつてはソフトウェアエンジニアとして、ゲームやアプリなどのtoCサービスから、BtoB SaaSまで幅広く携わってきました。
今回は、私自身の経験やGBでの開発支援を通じて得られた、プロダクト開発を進める上でのポイントをご紹介します。
開発でつまずくのは多くの場合、プロダクトを作る「開発側」とプロダクトを売る「ビジネス側」の連携が上手くいっていないことに起因します。
本来、開発とビジネスはチームとして同じ目的意識を持って業務を遂行していくべきですが、組織拡大や職種による関心の違いによって不幸なすれ違いが発生し、それぞれの部署にとって都合のよいプロダクト開発に陥ってしまうことは少なくありません。
こういった「分業気質」から抜け出せないままだと、事業が大きく成長することは期待できないと思います。
そうした状況を防ぐために必要な、プロダクトに関わる開発サイドとビジネスサイドを支える概念「チームファースト」を浸透させる方法についてご紹介します。
「分業気質」になっている現場の特徴
チームファーストを浸透させるアクションをお伝えする前に、自社が分業気質になっているかを見極めるポイントをご紹介します。
仕事ではよく「開発待ち」「〇〇さん待ち」「デザイン決定待ち」など、「〇〇待ち」という言葉が出ることがあります。自分にアサインされたタスクが完了した、あるいはタスクはあるが前工程が完了していないために手が空いてしまったというシチュエーションですね。
一見仕方がない状況のようにも見えますが、こうした言葉が頻発する組織は「分業気質」になりつつあります。なぜかというと、仕事の関心が自分1人のタスクに寄りすぎており、他工程のことが他人事になっている発言だからです。
また、「常に開発が忙しそうにしているが事業KPIが伸びていない」とか、「技術的負債を解消するのにリソースを割きたいものの、ビジネスサイドの理解が得られない」といったシチュエーションも同様です。
「開発は開発」と事業KPIに貢献していなかったり、「ビジネスはビジネス」と技術に関して無理解だったり、それぞれ領域の範囲内で動いている時点で、チームではなく分業になってしまっています。
チームファーストな組織をつくる3つのアクション
では、分業気質を脱し、チームファーストを浸透させるためにはどうすれば良いのでしょうか？典型的な3つのアクションをご紹介します。
①ビジネスメンバーが「開発プロセス」を理解する
②開発メンバーが「事業KPI」を理解する
③メンバーの目線が揃ったら、実践と改善を繰り返す
①ビジネスメンバーが「開発プロセス」を理解する
業務を通じて多くのスタートアップの現場を見てみると、自分たちの開発プロセスを長年変えず、惰性で続けてしまっている企業が少なくありません。
たとえば、開発者が10人近く入ってきているのに、0→1でプロダクトを作っていた初期の頃から進め方が変わっていなかったり、朝会やレトロスペクティブ（スクラム開発におけるふりかえり）などの型が形骸化していたりすることが多くあります。
そうした場合には、スクラムガイドや書籍など、採用している開発プロセスに関する世の中の知見をインプットすることをお勧めします。改めて立ち止まって見直すことで、今の開発プロセスに対する違和感や気づきを得られることが多くあるからです。また、客観的な視点で自社のやり方を振り返るために、外部のアジャイルコーチを活用するのも1つの手です。
その上でさらに、ビジネスの方にもその開発プロセスを知ってもらうとよいでしょう。ビジネスサイドも開発の進め方を知らないと、開発側がいま何に取り組んでいるのかを理解できず、コミュニケーションもうまくいかなくなってしまうためです。
ビジネスサイドが開発プロセスを深く理解した好例として、リーガルテックサービスを提供するスタートアップ、株式会社リセがあります。リセ社では、ビジネスサイドも含めて全社でアジャイルを理解するワークショップを実施。いまではスクラムイベントに非エンジニアのCEOやビジネスサイドの社員も参加し、開発について議論できるほどになりました。
②開発メンバーが「事業KPI」を理解する
次に取り組みたいのが、開発メンバーに事業KPIを理解してもらうことです。
ほとんどのエンジニアの方は、事業成長のために開発を行っているという意識は持っていらっしゃいます。しかし、手元で実装している機能が事業KPIに与える影響に関心を持っている方は多くはない気もしています。
この理解不足によって生じるのが「開発生産性を高める」ことに対する、ビジネスサイドと開発間での認識のずれです。
ビジネスサイドにとっての開発生産性は「アウトカム」、つまり開発された機能がどう事業に貢献したのか、どのくらい業績やユーザーの行動変容に繋がったかで考えます。
しかし、事業KPIへの意識が薄い開発メンバーは、ビジネスサイドと開発生産性について議論すると「レガシーコードや技術的負債が多く速やかな機能追加の障壁になっている」のように、開発業務自体の生産性について語ってしまうのです。
両者は共に開発スピードの話を取り上げながらもそれぞれ別のレイヤーの話をしているため、当然コミュニケーションもうまくいきません。ビジネスサイドは日々アウトカムのためのKPIを追っており、開発タスク量の話をされても議論が進まないのです。
レガシーコード改修や技術的負債の解消は大事ですが、プロダクト開発の根底には必ずアウトカムにどう繋がるかへの意識があるべきです。そのために開発メンバーは、手元の開発内容を事業KPIに紐づけて説明できる必要があります。
③メンバーの目線が揃ったら、実践と改善を繰り返す
ここまでのアクションで開発とビジネスの目線が揃ったら、あとは実践あるのみです。時間が有限であるということもありますし、やってみたからこその気づきもありうるからです。
スクラムやエクストリーム・プログラミングなどのアジャイルな開発手法では、標準でふりかえりの仕組みが含まれています。うまくいかなければまた変えれば良い、という気軽な感じで始めてみましょう。
ふりかえりの効果を最大化するためには、参加者の主体性が重要です。その機会が設けられても意見が全然出なかったり、発言するメンバーが偏っていたりする現場をたまに見かけます。メンバー全員がふりかえりの役割を理解し、主体的に参加できるように事前準備からアクションまでを整えましょう。
ちなみに手法としてはKPT（Keep Problem Try）が有名ですが、その他にもいろいろな種類があります。先述したリセでは、メンバーの発案で「Sailboat Retrospective（帆船のふりかえり）」という船の絵を用いた手法で行われています。
ふりかえりはチームで目線を揃え、次の活動に繋げる上で重要なイベントです。実践を通じて、チームに合う形を探してみてください。
ただ再度強調したいのは、開発を進めても決して「開発とビジネス」「作る人と売る人」で分かれてはいけないということ。互いの関心が離れることが分業の始まりであり、チームがチームとして機能しなくなってしまいます。
まとめ
今回はチームファーストな組織を目指すための3つのアクションについて紹介しました。
スタートアップで難しいのは、0→1のフェーズでは有効だった戦略が、人員を拡大し始めたタイミングで通用しなくなってくることです。人が増えると役割が細分化される力学が働いて分業化されるため、問題が起こりやすくなるケースはよく見られます。
上記のアクションを通じて、開発とビジネスが互いに共通のものを追えている時、それはチームであり、メンバー各人はチームファーストであるといえます。
本記事が少しでもみなさまの開発現場の参考になれば嬉しいです。