“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５：エンジニアと営業のインターン同士でペアを組み、プロジェクトを進める

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

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

STEP１〜５の結果、変わったこと

そのようにビジネスサイドと開発サイドの間の情報流通量を増やした結果、「①顧客／ユーザーのニーズを汲み取る→②仕様を決める→③実装する→④リリースをして反応をみる」というプロダクトの改善サイクルを劇的に速めることに成功しました。

現在のシェルフィーでは、

①の段階でビジネスサイドが把握したニーズは全てGitHubにまとめられ、気になることがあれば誰でもコメントを通して気軽に突っ込みを入れられます。

②の仕様決定の場では、ビジネスサイドも開発サイドも混ざって議論することができるようになり、問題意識やその解決策は関係者全員が認識しています。

③の実装中はGitHubを見るだけで進捗やリリース時期を確認することができ、

④のリリース時には全員が、それまでの議論の経緯を含めて新しくリリースされたものを理解しています。

こうしてPDCAが速く回ることで、SHELFYというプロダクトの品質が飛躍的に向上し、顧客継続率100%、新規獲得数の増加といった結果を生むことができました。

開発も営業も、会社にとってはすべて”手段”である

「目の前の仕事は、会社にとってはすべて”手段”である」とは代表の呂(ロイ)がよく言っていることですが、なぜ「ビジネスサイドと開発サイドが対立しやすいのか」を考えると、各々が目の前の仕事に夢中になるにあまり、目的と手段が入れ替わるからではないでしょうか。

会社はVISION・MISSIONの実現のために存在しており、シェルフィーで言えば、営業も開発も「建築業界に健全な競争環境をつくり、利用者の納得感を生み出す」ための”手段”でしかありません。

しかし目の前の仕事、たとえば「ある顧客の要望に応えること」「最新の技術を使うこと」などが”目的化”してしまうと、全体最適よりも個別最適が優先され、部署間で目的が相反するといった事態になってしまいます。

ビジネスサイドと開発サイドの対立や不和を防ぐ鍵は、「目の前の仕事は、会社にとってはすべて”手段”である」という「マインド」と情報流通量を増やし、情報格差を可能な限り無くす「仕組み」にあるのだと思います。

そんなシェルフィーでは現在全職種・全方位で人材を募集していますが、その中でもとくにプロダクトをつくりたいUI/UXデザイナーの手が足りません…  上記を読んで少しでもシェルフィーのDevチームに興味を持ったデザイナーの方、ぜひこちらより遊びにきてください！

「納得感」をもってデザインできる環境には自信があります！ちなみに転職を考えていなくても全く問題ありませんので、お気軽にどうぞ。笑