ビジネスサイドとエンジニアサイド

こんにちは。
今日は「ビジネスサイド」と「エンジニアサイド」というテーマでお話ししたいと思います。

この話題は、組織の状況や規模によって内情が大きく異なるため、各企業ごとに相違があることをご了承ください。

個人的には、「ビジネスサイド」と「エンジニアサイド」という用語自体はあまり好きではありません。
実際のところ、ビジネスと開発の間には隔たりが存在しますが、このような言葉が組織を分断するきっかけとなっていることも多いと感じます。

ビジネス側と言えば開発は関係ないし、開発側と言えばビジネスは関係ないという意識を持つ人も多いのではないでしょうか？

あまりしたくはないですが、この記事では主語が明確になるように、「ビジネスサイド」と「エンジニアサイド」という用語を使用して説明していきたいと思います。

それでは、本題に入ります。

1.相互理解のある状態とは？

相互理解がある状態とは、どのような状態を指すのでしょうか？

● ビジネスサイドが技術や開発に理解を持っている状態。
● エンジニアサイドがビジネス要件に理解を持っている状態。

ビジネスサイドとエンジニアサイドが互いに心理的安全のある状態であり、ユーザーの課題解決を中心に据えた構造が円滑に運営されている状況が、相互理解のある状況であると言えます。

● ビジネスサイド - 【課題】 - エンジニアサイド

1-1.ビジネスサイドの技術理解

エンジニアと対等に話し合うためには、一定の知識が必要となります。
以下のような基礎的なエンジニアリングの知識は必要でしょう。

● Webはどのような技術の基盤上に成り立っているか？
● フロントエンドとバックエンドの違いは何か？
● データはどのように扱われているか？

1-2.エンジニアサイドのビジネス理解

ビジネスサイドと対等に話し合うためには、一定のビジネスへの理解が必要です。
以下のような基礎的なビジネスの理解は必要でしょう。

● なぜそれを行うのか？何を行うのか？
● ユーザーのどのような課題を解決することによって、事業にインパクトがあるのか？
● なぜそのタイミングで行う必要があるのか？

2.相互理解のない疎結合な組織

小規模な組織では、誰がどの役割を担当するかや職務の分担は明確ではありません。
しかし、一定の規模になると、業務の分担が必要となり、職務や責任が明確化されます。

この点において何ら問題はありません。

しかし、個人の担当範囲が限定されることで、意識的に把握している範囲も狭まり、他の領域で起きている出来事に対して鈍感になることがあります。
さらに進むと、自分たちの職務範囲外の出来事には関与しないようにし、他の人が対応すべきだという無関心な立場や、自身の領域に執着する縄張り意識が生まれます。
これにより、組織内の各部署が疎結合になり、事業全体としての一体感が失われます。
この疎結合は事業の推進にとって深刻な問題となります。
責任の押し付け合いが生じたり、エンジニアサイドが単なる受託企業のようになったりすることで、事業に不幸な事態が待ち受ける可能性があります。

2-1.あるあるな構造

組織の中で片方にバランスが偏っている状況はよく見られます。
これは一般的な話ですが、多くの場合、2つのパターンが存在するように感じられます。

● ビジネスサイドがエンジニアサイドを理解しようとせず、「いつまでに作ってください」「あ、急遽これ追加してください」といったスタンスを取っている場合。

● エンジニアサイドがビジネスサイドに無関心で、「私たちは作るだけです」「完璧な仕様書を1~10まで作ってから持ってきてください」といったスタンスを取っている場合。

2-2.これも追加でお願いします

ビジネスサイドの終わっているパターンその1です。
リリース日が確定しているのに、要求定義が変更されるパターンです。

「あ、やっぱり〇〇したいな...こっちも追加で〜、これも追加で〜、これは修正で〜」といったことがよくあります。
エンジニアサイドがクライアントの無茶に付き合っているのと何も変わりません。
工数が増えればリリース日も伸ばすべき、という話になるでしょう。

以下は一例ですが、一般的な事例としてよくある話です。

● 何がしたいのか具体的に決まっていない
● スケジュールが厳しい
● やりたいことが途中から増えていく
● いつ？なに？なぜ？の説明をデータをもとに説明できない

2-3.仕様できてませんけど？

終わっているパターンその2です。
ビジネスサイドに1~10まで完璧な仕様書を求めるパターンです。

「仕様に含まれていなかったですよね？仕様に含まれていないところは何もしてませんよ？そこの考慮は一切していません。」といったことがよくあります。
ビジネスサイドが受託企業に依頼しているのと何も変わりません。
チーム全体で協力して具体的に何を作るのかを考えるべき、という話になるでしょう。

以下は一例ですが、一般的な事例としてよくある話です。

● 作るだけになっている
● なぜその工数で、なぜその投資が必要なのかを説明できない
● 目的と手段が混同する

3.相互理解のある組織になるために

組織の疎結合は不幸を増やす結果となります。

全員の意識がズレていくほど、成果が上がらなくなり、参加者全員が日常的に不幸な状況に陥ります。
ビジネスサイドとエンジニアサイドが協力せずには、事業の成功は望めません。
ユーザーを中心にした仕事ができていない組織ほど、このようなつまらない問題が日常的に繰り返されています。

3-1.必要な前提

ビジネスサイドやエンジニアサイドにかかわらず、チームとして事業を成功させるためには、以下の大前提について認識を共有することが重要です。
これは組織が事業開発を行う際に不可欠な考え方です。

● なぜやるのか？
● なにをやるのか？
● いつやるのか？
● やった結果どうなるのか？

アジャイルのインセプションデッキを理解している方にはお分かりかと思いますが、これらがなぜ必要かというと、プロジェクトの全体像を把握し、チーム全員が共通の認識と目標を持ってプロダクトの開発に取り組むために必要だからです。

3-2.データをファクトとしてみること

データを事実として述べられない場合、以下のことを適切に実行することができません。

● 施策の優先順位決め
● 施策が良かった / 悪かったの振り返り

物事の優先順位を決められない場合、時間がいくらあっても足りません。
また、データを基に施策を立てていないため、結果に結びつきません。
事業の成長状況を判断するためにはデータが不可欠です。

3-3.ユーザー中心にすべてを決める

また、ユーザー中心でなければ、ユーザーにとって価値のあるものを提供することはできません。
ビジネスサイドやエンジニアサイドにとって、ユーザーとの関係は重要です。
ユーザーにとって何が価値であり、どれだけの価値を提供できたかが最も重要です。

言い方は少し厳しいかもしれませんが、どちらが悪いのか、私には関係ないといったことを言っている暇があれば、ユーザーが本当に価値を感じることは何かを日々考え、協力して改善し続けることが大切です。

ユーザーに価値を提供するためには、プロダクトを改善していくことです。これがすべてです。

4.まとめ

受託企業であろうと事業会社であろうと、職務による分断が起こっているところは多いのかもしれません。

共有すべき情報である必要なデータや定点観測データ、ビジネスの状況やインセプションデッキなどを共有し、メンバー間で意思を一致させることが重要です。
そして、ユーザーのために何ができるのか、どのような価値を提供できたかを基に組織全体でアウトカムに焦点を当てて仕事を進めることが重要になります。

それでは。