ビジネスサイドがエンジニアと併走する5つの注意点

こんにちは、ウェビナーの出会いを最大化するツール・コネルバのせきともです。
非常に暑いですね。。
我々も夏に負けず、あつ〜く開発を進めております。

このまま進めば、9月には全容を理解出来る何かしらの形がお見せできます。

さらっと、大切なお知らせでした。笑
ウェビナーやオンライン商談、授業などやってらっしゃる方は是非ご連絡ください！☝️

さて、開発といえば、ビジネス側がエンジニア側とどう向き合うべきか？がよく議論になります。
特に最近テックビジネスが増えたことで、お困りの方々も多いのではないかと推察します。
もはやエンジニアリングはビジネスサイドでも必須スキルとおっしゃる方もいますが、せきとももなかなか習得に時間がかかったり、ビジネスサイドのワークに付きっきりになってしまい手をつけられなかったりします。

最近コネルバでも開発のマイルが続いているので、ビジネスサイドをメインにプロダクトに関わっているせきともはファウンダーとしてもPM的に進捗管理しつつ進めておるのですが、
チームはエンジニア2人とエンジニアリングは素人に毛が生えたレベルの僕なので、気をつけたいなと思う気付きがちょくちょくあります。

今日は僕が気をつけたいと思った5つのことをまとめます。
少しでもビジネスサイドとエンジニアサイドの隔たりが無くなるといいな〜

1.チームでコト作りする意識を持つ

消費の仕方が変わったという話があります。
モノ消費とコト消費という話です。
所有や購入に重きが置かれた時代、人々はモノやサービスそのものに価値を感じていたため、より良いモノ作りに各企業が投資していました。これまでに無い薄型テレビ、パワフルな冷暖房、これまでより健康に良い玄米…
革新的な機能性に対して爆発的なニーズが生まれていました。
しかし昨今、モノだけでは売れない時代だと言われます。
モノの機能の素晴らしさだけで飼いたいと思う人がたくさんいた時代は終わり、スターバックスコーヒーのサードプレイスやb-monsterやfeel cycleといった暗闇フィットネス、Amazonの無人店舗(今や有人回帰ですが…)、オンライン学習などを筆頭に、コト、つまり体験に対して価値を感じ、その周辺商品を買うという消費にニーズが移り変わっています。
プロダクト作りでも同じ、いやむしろそれ以上の変化があると思っていて、ユーザー体験、つまり、昨今市場で認識が広まってきたUXを向上できる素地を持つデジタルワールドでは、モノではなくコトを提供して価値を感じてもらうという意識をチームで持つ必要があると思っています。
ビジネスサイドとエンジニアサイドの間に起きる議論において、最も重要な認識であり、イニシアティブを持つ人間はチームがどんな価値をもたらすコトを作っているか、指針を定める必要があります。

2.適量のレポーティングを

コネルバでは、エンジニアサイドとの議論は基本定例の時間か、slackなどのチャットで行っています。
限られた時間で、どんな進捗があったか、チームでネクストどんな連携をすべきか、チェックはどこまですべきか、次回に向けてどんな進捗を予定しているか。
これらを摺り合わせていくわけですが、もちろんビジネスサイドでは理解仕切れない大変な開発作業があります。(わかってはいるつもりでも、ここでわかったフリをするのもいけないのでこれぐらいにしますが…)
なので、いわゆるレポーティングは、こちらから突っ込まないというのを意識しています。
ここで重要なのは、どこまで共有すべきかを判断してもらうために、相手を信頼する必要があるということ。
なぜなら、当たり前ですが、適切な共有内容を判断できるのもエンジニアサイドだけだからです。
その判断をしてもらうためにも、日々外を向いたタイミングでチームを意識したり、出来るだけ密に連絡したりといったコミュニケーションが必要です。

3.エンジニアの話を聞く

2と被りますが、信頼感はチームの基礎になります。
以前別の仕事でエンジニアと作業をしていた時、共通言語を作るのに苦しんだ経験があります。専門用語はもちろん、ビジネスそのものの進め方、型が全然違うなと思い、プロジェクトの継続が難航したことがあるのです。(具体的に言えず申し訳ありません…)
言ってしまえば、ビジネスサイドが抱きがちなエンジニアサイドのコミュニケーション能力不足、みたいなものは妄想でしか無いことが多く、ほとんどの場合は両者のお互いの考えの理解不足です。
エンジニアサイドも考えを持ってプロジェクトを進捗している中、ビジネス側の主張だけしてしまうと、どちらも嫌な想いしかしません。
まずは話を聞いて、課題はどこにあるのかを引き出しつつ、こちらの課題も伝えてどんどん想いをすり合わせていくこと。
難しいけれど、聞くこと、伝えることは大切な仕事だと思っています。

4.自分の悩みをチームの悩みにする

よく、エンジニアに無理な主張・要求をしてしまうビジネスサイドがいます。かくいう僕も、これまで作業内容や工数がわかっていないのにお願いしてしまうことがいろんな場面でありました。
いつまでにこれ作れないと説明がつかなくてまずいんだけど…そういうお願いは、エンジニアサイドとしてはリソース不足として難しくても断るに断りきれなかったりするものだと認識しています。なぜやるべきなのか理解できず、断る力があるエンジニアサイドでも、結果結論に辿り着けず右往左往することもありますし、最悪チームが空中分解することもあります。
エンジニアサイドとビジネスサイドが戦う構図は、チームにとってもメンバーにとっても投資家にとっても社会にとってもなんのいい影響もありません。
まずは課題を共有して、課題に対して何が必要要件か、ありたき姿はどんなものなのか、どうすればマイルストーンに進めるのか、そのための工数やtodoは何か、チームとして、メンバーとして手伝えることは何かを噛み砕いていくことで、意思疎通がしやすくなると思っています。
この時に大切なのは、課題を最初に共有する言語化能力だと思っています。
ビジネスサイド、というかコミュニケーションの仕事を本業にしている僕としては、ここがビジネスサイドの本職だとすら思っていて、課題さえ共有できれば答えは共に作り上げられると考えます。
今、何に、どんな状況下で困っているのか。相手とチームが判断しやすい言葉で伝えきるスキルを身に付けたいですね。

5.アウトプットを説明してもらう

案外一番大切かもしれないポイント。
それがこの5つ目です。
それは、エンジニアに適切かつ丁寧な説明を求め続けることです。
元来僕はビジネスサイドもエンジニアサイドもガンガン領域侵犯すべき派なので、ビジネスサイドはもっと開発やデザインを学んで口を出す(自分の意見を持つ)べきだし、エンジニアサイドももっとビジネスモデルや収益性、機能やプロモーションなどにも突っ込んで欲しいと考えています。
その上で、タスクを切って逐次説明をし続けてもらうことは、ビジネスサイドの進捗理解や進捗しているかどうかの不安解消と共に、今後さらに需要が増えるであろうエンジニアサイドのビジネスへの理解も促せると考えます。
大変ではありますが、お互いがお互いの作業を説明し続けることでモチベーション維持のようなソフト面への影響もあります。

手を取り合う日をみんなで作ろう

といいつつ、人間としての関係性やコミュニケーション不足、こちらのモチベーション、エンジニアのスキルセットなど、様々なハードルがあり難しいのも事実。

特に日本ではこういったチーム体制を組んで推進した経験のない人が多すぎて、経験値が非常に不足しています。
ビジネスサイドとエンジニアサイドの仲が深まるのはまだまだこれからといっていいでしょう。

コネルバでもそうですが、想いを広げるのも、想いを形にするのも、チームみんなです。ビジネスサイドだから、その想いを形にするのはエンジニアにお願い…なんていうのは、もう通じなくなってきています。

その時に大切なのは、やはり、コミュニケーションです。
コミュニケーションの型ができれば、ビジネスサイド・エンジニアサイドなんていう分け方が徐々に崩れてくるし、ディビジョン内でも話しやすくなります。

コネルバも星の数ほどあるスタートアップの1でしかありませんが、みんなでプロジェクト推進、開発の型を築き、未来の当たり前を作っていきたいですね。

さて、いつも日曜の定例ですが、今週はずらしてもらって今日の夜。
加速度を増している開発ですが、引き続き頑張っていきたいと思います。