“ITスタートアップあるある”「ビジネス」と「開発」の対立を回避するためにシェルフィーが行った５つのこと

営業やカスタマーサポートといった"ビジネスサイド"とエンジニアやデザイナーといった"開発サイド"が同数で存在する会社では、両者が対立するといった問題が起きがちです。

事実、Google検索で「開発」「営業」と入力すると「対立」というキーワードが一番上の候補として表示されるのはご存知ですか？笑

シェルフィー株式会社も組織拡大に伴い、例外なく同じ問題にぶつかりました。しかし様々な取り組みを試した結果、今では両者が協力してプロダクトを作る風土が出来上がっています。その文化形成に最も効果的だった５つの施策とは...？

サービスの高度化に伴い、問題が勃発

サービスリリース当初のSHELFY (https://shelfy.jp/) は店舗の内装の事例を見るだけのサイトでしたが、組織の拡大に伴い、ユーザーの動線が増えたりたくさんの機能がついたりと、WEBサービスとしてより高度なものになっていきました。

その一方で、ビジネスサイドと開発サイドの共通認識が充分にとれていないまま進んでしまい、「顧客に１週間以内にリリース予定と伝えたものが、開発チームでは後回しになっていた」「顧客のニーズが曖昧なまま進めてしまい、リリースしたものの誰も使わなかった」といった事態が発生するようになってしまいました。

全員が「SHELFYをよりよいプロダクトにしたい」という強い想いはあるがゆえに、それぞれが「自分なりの正解で進める」という状態になっていたのです。

そういった問題の原因はビジネスサイドと開発サイド間の情報格差にありました。

SHELFYはBtoBサービスかつ対象が建築市場であり、普段の生活では触れ合わない人たちが顧客対象であるため、開発サイドにとってはユーザーのペルソナが理解しにくく、ビジネスサイドがあげた要望に対して微妙な認識のズレが発生しやすかったのです。

またビジネスサイドでは、開発の進捗を知る術がなく、せっかくリリースされた便利な機能が顧客に知らされないといった事態も起きていました。

早急に、「顧客のニーズは把握しているが、そのニーズをどう機能に落としていいか分からない」ビジネスサイドと、「機能にどう落とすべきかは分かるが、顧客のことがあまり分からない」開発サイドとをつなぎ、双方の情報格差を埋める仕組みが必要だったのです。

"社内の情報流通量を増やす"ために実施した５つのこと

STEP１：レクチャーの実施

まずはそれぞれが日常に使っている用語などの前提知識を共有することから始めようと、ビジネスメンバーには開発サイドのマネージャーから「WEBレクチャー」を、開発メンバーにはビジネスサイドのマネージャーから「建築業界レクチャー」を実施しました。

「WEBレクチャー」の内容については開発マネージャー・坂上のブログに改訂版が上がっていますので、こちらをどうぞ。

シェルフィーのメンバーは開発 or ビジネスのどちらかにしかバックグラウンドがない人が多かったため、こういった前提知識を共有することはコミュニケーションの円滑化に非常に効果的でした。

STEP２：エンジニアが営業に同行

この取り組みはビジネスサイドからではなく、開発サイドの提案から始まりました。「顧客やユーザー像が想像できないと、本当に便利なサービスは作れない」という危機感から、自ら志願して営業に同行するエンジニアがじわじわと増加しました。

この効果は想像以上で、ユーザーや顧客理解が深まったのはもちろん、ビジネスサイドの仕事に対する開発サイドからの更なるリスペクトも生まれ、社内の空気がとてもよくなりました。「『強制』ではなく、『自発的』に始まったのが成功の秘訣だったのかもしれません。」(開発マネージャー・坂上)

STEP３：ビジネスサイドもGitHubを使用

毎回進捗を確認される開発サイドからは「ビジネスサイドもGitHub（開発に使うツール）を見ればいいのでは」という声があがっていました。

とはいえ、GitHubははじめて触れるビジネスサイドには導入ハードルが高かったため、上記同様、まずは目的や使い方を説明するレクチャーを実施。そのうえで「ビジネスサイドはissueをあげる際に解決法 (例：この機能を追加する)ではなく、課題 (例：顧客がこういうことで困っている) をあげる。それをどう機能に落とすかは開発サイドと議論し、決まったあとに議論の過程と結論をGitHubにも記入する。」というルールを作りました。

このルールにより、要望を出したビジネスサイドのメンバーと担当の開発サイドメンバーが仕様決定の議論から行うことができるよう、認識のズレがなくなりました。

また他のビジネスサイドのメンバーも新しい課題をあげる際にGitHub上で検索することで、「それが既出なのか、新しく話すべきことなのかどうか」が分かるようになり、今は入社後すぐのメンバーであっても積極的にissueをあげています。

STEP４：モニターのある席をバラバラに

シェルフィーは元々フリーアドレス制でしたが、エンジニアの席は自然とモニターの前になります。そこでモニターのある席の位置を点在させました。

隣に違う部署の人がいることで"気になる機会"が必然的に増え、営業が顧客からの問い合わせの電話を受けているのを横で聞いていたエンジニアが「あの機能のこと？」と質問したり、営業が隣に座っているエンジニアに「今なに作ってるの？」と話しかけたりといったことが起きるように。

非常にシンプルな方法ですが、社内コミュニケーションの活性化に大きく寄与しました。

STEP５：エンジニアと営業のインターン同士でペアを組み、プロジェクトを進める

インターンはある程度タスクが分解されてから落ちてくるため、どうしても目の前の仕事に集中してしまい、営業と開発の間が分断されがちでした。

そこで、エンジニアチームと営業チームからインターンを１名づつ選出してチームをつくり、１つの小さなプロジェクトを任せてみることにしました。すると、プロジェクトに選ばれたメンバー間はもちろん、選出されていないインターンの間でもビジネスサイドと開発サイドの間のコミュニケーションが活発化し、社員だけでなくインターン生の間でも相互理解を促すことができました。