2019年10月29日、スマートキャンプ株式会社の主催により、「B2B SaaSエンジニアMeetup – Sharing Issues #1 マネジメント」と題するイベントが開催された。B2B業界で働くエンジニアが直面する課題や解決方法などを共有することにフォーカスを当てた本イベント。今回は、その概要を講演レポートとしてお届けする。

写真撮影：多田圭佑

本イベントの目的について（井上 翔太朗氏）

井上：皆さん、本日は宜しくお願い致します。スマートキャンプ株式会社の井上翔太朗と申します。社内では、「師匠」と呼ばれています。ちなみに、弊社では、各メンバーに「あだ名」をつけるという「文化」がありまして、基本的には、その「あだ名」を命名するに至った経緯が存在するのですが、私の場合は、なぜか特に意味もなく「師匠」と呼ばれております。

さて、私の経歴ですが、スマートキャンプで新規事業の立ち上げを二回経験し、現在は、インセプションデッキやカスタマージャーニーマップなどの企画・進行を担当しています。イベントを開始する前に、軽く弊社の宣伝をさせて頂ければと思います。弊社では、「大きなビジネスをするのに、ヒト、モノ、カネの数や大きさは関係ない。少人数のチームでも、世の中をもっとよくできる、社会を動かせることを証明したい」という考えのもと、「Small Company, Big Business.」というビジョンを掲げています。その上で、「テクノロジーで社会の非効率をなくす」というミッションを定めており、主に以下の4つのサービスを提供しています。

上から順に、B2Bマーケティングプラットフォーム「BOXIL SaaS」、ビジネスパーソンのライフスタイルを支援するテクノロジーと人をつなぐビジネスメディア「Beyond」、BPOやコンサルティングサービス「BALES」、営業活動を最適化するインサイドセールスマネジメントSaaS「Biscuet」。これらを展開しています。また、会社関連の情報については、出来るだけ外部に発信することを意識しています。具体的には、「スマートキャンプ 会社説明資料」をspeakerdeckに掲載しているほか、PRメディア「.▲.tent.」や技術ブログ「SMARTCAMP Engineer Blog」を運営しています。

それでは、本イベントの趣旨について述べさせて頂ければと思います。まず、大前提として、皆さんが在籍している「B2B SaaS業界」というのは、その性質上、一般には理解されづらい特有の課題が生まれやすい傾向があると考えています。そして、それにもかかわらず、そういった情報が十分にシェアされていない点に課題意識を持っていまして、そのような経緯で、私とイベントチームで本イベントを立ち上げるに至ったという形です。

上記を踏まえ、このイベントの役割としては、これまでに発生した課題をシェアして、相談して、解決して、蓄積していく場所となることを目指しています。なので、今後も皆さんには積極的に登壇して頂きたいと考えています。そして、「こんな課題あったよ」「こんな課題解決したよ」ということをシェアして頂いて、新たに 「B2B SaaS業界」にいらっしゃった方々にとって、有益と思われる知見を蓄積していく場になることが出来ればと考えております。それでは、まず、弊社の米元から始めさせて頂きます。

B2B領域における開発組織作り 〜採用編〜（米元 智氏）

登壇資料：B2B領域における開発組織作り 〜採用編〜

米元：スマートキャンプ株式会社の米元と申します。最初に軽く自己紹介をさせて頂ければと思います。私は2018年2月にスマートキャンプ株式会社に入社しました。その後、BOXILとBiscuet（の前身となるプロダクト）の開発を経て、2018年10月からはエンジニア組織を統括するマネジメント業務に携わっています。また、昨年、子供が生まれ、絶賛子育て中の身でもあります。

本日は、 「B2B領域の開発組織作り」というテーマでお話させて頂ければと思います。先程、井上からお話があったように、弊社では、 B2Bマーケティング領域をはじめとして、いくつかの事業を展開しています。それらの事業を支える開発組織の体制については、エンジニアが（私を含めて）11名在籍しており、デザイナー業務を兼務している者が2名おります。あとは、業務委託でお手伝い頂いている方やアジャイルコーチ、さらにはアドバイザーの方がいらっしゃいます。詳細については、以下のスライド資料をご覧ください。

ちなみに、これは私が掲げている個人的な目標の一つなのですが、「自己組織化」したチームを再現性をもって作りたいと考えています。この場合の「自己組織化」というのは、管理者がいなくても自分たちで課題を発見・解決できる組織のことを指します。

さて、本日、お話させて頂く内容ですが、半年ほど遡って、2019年5月頃のお話をさせて頂きたいと思います。当時、チーム内には数多くの課題があったのですが、その中でも、採用面で特に大きな課題がありました。どういうことかと言うと、2018年10月以降、エンジニアの採用実績が0名でした。つまり、私がマネージャーになってから、エンジニアを1人も採用することができていなかったんです。

こちらはHRMOSのデータです。これらのデータを踏まえ、「そもそも採用したい人と出会えていないのではないか」と考えていました。

ちなみに、当時、我々が求めていた人物像についてですが、技術面に関しては、「弊社の既存メンバーと同等もしくはそれ以上であること」「フルスタックまたはどこかの領域に尖った技術力があること」「若手の場合はこれらのポテンシャルがあること」を掲げていました。また、人柄・マインド面については、「技術よりもプロダクトを成長させることにコミットする志向性があること」「課題解決が好きであること」「弊社の行動指針にマッチすること」を求めていました。

この時の私の「脳内」ですが、正直言って、まったく採用できる気がしなくて、「弊社が求める人材ってそもそも転職市場に存在するのか」「弊社ってエンジニアに対する知名度が全然無いな」等と考えていました。また、B2Bの業界は、ある意味では、「地味」な部分もあり、「事業内容を訴求しづらいな」とも思っていました。「そもそも今の採用のやり方自体が正しいのか」ということも考えていました。

しかし、会社の将来を考えた時、採用の土台についてはつくっておくべきですし、人が増えなければ、会社や事業の成長にも当然ながら影響がある。そして、会社が成長しなければ、私自身が目標として掲げている「自己組織化」した組織を作る意味もありません。上記の考えをもとに、私自身のリソースを採用に注ぎ込むことが組織にとって最も「レバレッジ」が効くことであると判断し、採用にフルコミットすることを決心しました。そして、今期で成果を出せなければ、マネージャーを辞めようと思っていました。

さて、あらためて、 B2B領域でのエンジニア採用についてお話したいのですが、採用に関して「そもそも今のやり方が本当に正しいのか」を確認するため、有識者の方に相談させて頂きました。具体的には、弊社の代表経由で、他社のCTOや技術顧問の方々にコンタクトを取り、アドバイスを頂きました。また、いつもお世話になっている転職エージェントの方々に対してヒアリングを実施し、現状の課題の改善点を探りました。さらに、採用コンサルの方にも相談させて頂きました。

その結果、今までの弊社の取り組みの方向性自体はそこまで間違ってはいないことが判明しました。そして、やはり「銀の弾丸」みたいなものはないんだなということを再認識しました。重要なことは、「やるべきことを愚直にやりきる」ということですね。

ちなみに、弊社はマーケティングが得意領域なので、その知見を採用戦略にも生かす形で、「リードジェネレーションから始めて、フェーズ毎にやるべきことを洗い出して、実行する」というやり方で進めていきました。また、採用条件の見直しや会社説明資料の作成に加えて、プロダクト毎の説明資料を作成しました。そして、会社やプロダクトについて説明する際に、誰が説明しても同じクオリティになるように工夫していきました。

さらに、今年の頭からは、弊社のエンジニア文化を知ってもらうべく、エンジニアブログに取り組んでいます。先日は、「150社のTechブログを分析して見えた、エンジニアが今転職するべき企業ランキング」という記事の中で、Techブログスコアランキングで第4位に選んで頂きました。

あとは、メンバーの強み・弱みを知ってもらうということで、各メンバーのストレングス・ファインダーを候補者の方に共有しています。ストレングス・ファインダーについては、取り組んだことがある方もいらっしゃるかもしれないですが、簡単に言えば、いくつかの設問にオンライン上で回答することで、自分自身の強みや弱みを明らかにすることができるテストです。このテストや他の性格診断の結果を利用し、候補者の方とチームメンバーの強み・弱みをお互いに確認しながら弊社に対する理解を深めて頂きました。

また、弊社に対する理解を深めて頂くという狙いで、「1日体験入社」のプログラムを策定し、選考中の候補者の方に来て頂きました。さらに、一緒にモブプロをしたり、お互いの価値観を知るカードゲームにも取り組みました。

加えて、外部の方を招いた勉強会に候補者の方に来て頂いたり、ピザパの日に来て頂いて、他部署の人間とも交流して頂いています。

選考の後半になるにつれて、入社後の流れやキャリアイメージ、期待していることなどを候補者の方に伝え、どのような活躍をして頂きたいかをできるだけ視覚的にわかるように共有しています。これについては、候補者の方ごとに作成し、なるべく入社後のミスマッチが発生しないようにしています。

最後に、オンボーディングですが、会社全体で制度やツールに関する説明資料を作成しています。また、スムーズに業務に入って頂くために、B2B領域のマーケティングやセールスに関する用語集を作成して、業務で使う用語を即座に理解できるようにすることにも取り組んでいます。さらに、入社前からSlack に入って頂いて、情報共有を行った上で、必要な技術やビジネス知識を共有しています。

色々と取り組んだ結果、無事、3ヶ月で2名のエンジニアを採用することができました。下記はSlackでのやり取りですが、非常に盛り上がっていますね。ちなみに、叫んだりしているのは、弊社の代表やCOOです。

ポイントとしては、自社の採用面における「中から見た強み」と「外から見た弱み」を正確に理解して、言語化した上で、対応策を考えることが大切かと思います。特に、弊社の場合は、エンジニアチームで言えば、技術だけではなくて、売上や事業を伸ばすことに意識が強いメンバーが多い。あとは、他部署のメンバーがすごく協力的で、エンジニアに対する理解がある。全体的に言えば、賢くて性格が良い人が多い。このような「外からは見えにくい良さ」が存在していて、この「強み」が候補者の方に伝われば、弊社のことを気に入って頂ける自信があったので、そこを伝える努力をしていきました。また、「弱み」の部分に記載した「B2Bマーケティング領域がエンジニアからするとわかりにくい」点については、会社説明資料を作成することによって、ある程度はカバーしています。ちょっとまだやりきれていないところもあるのですが、このような方向性で取り組んでいます。

もう一つ重要なのが、チームや会社を巻き込んで、全員で採用活動に取り組むことです。「どういう人を採用するのか」といったペルソナ設計にチーム全体で取り組んだり、振り返りを行ったり、他部署のメンバーに協力してもらって、ワークをしたりすることも必要なことかなと思います。

最後ですが、今後、取り組むべきこととしては、再現性のある採用フローとそれを実行できる組織作りを掲げています。また、より多くのエンジニアの方々にB2B領域でエンジニアリングを行う「魅力」を伝えていければと思っておりまして、まさに、このイベントからスタートしていければと考えています。私からは以上です。 

開発リーダーが結果的にPMと呼ばれるまで（郷田 祥史氏）

登壇資料：開発リーダーが結果的にPMと呼ばれるまで

井上：続いてですが、スマートキャンプ株式会社のプロダクトマネージャー、郷田から宜しくお願い致します。

郷田：「開発リーダーが結果的にPMと呼ばれるまで」というテーマで発表させて頂きます、スマートキャンプ株式会社の郷田と申します。本日は宜しくお願い致します。ちなみに、本日の発表内容ですが、「Roppongi Product Manager Meetup」というイベントで発表させて頂いた内容がベースとなっています。宜しくお願いします。

まず、本日の発表の目的ですが、B2B領域でPMになりたいと考えているエンジニアの方々に対して、私の実体験を紹介することで、今後の業務に役立てて頂くことを想定しています。内容は決してスマートなものではなく、どちらかと言うと、「泥臭い系」です。また、私自身、PMについては「勉強中」の身なので、拙い部分については、フィードバックを頂ければ有難いです。

では、最初に、私自身と弊社のプロダクトの紹介をさせて頂いた上で、「自称PM」になるまでの経緯とそのために取り組んだ施策についてお話させて頂きたいと思います。まず、自己紹介ですが、私、郷田と申します。2014年4月に新卒で動画配信のプラットフォーム開発を行っている企業に入社し、Androidの開発やWebでの自社フレームワークの開発を行っていました。その後、スマートキャンプに転職したのですが、当時のスマートキャンプではプロダクトがBOXILのみだったこともあって、BOXILの開発やサービスのリプレイスなどに取り組んでいました。また、エンジニアの正社員としては、私が二人目だったこともあり、エンジニア採用やインターン生の教育にも携わっていました。

その後、コーポレートIT部門の立ち上げや「Biscuet」というプロダクトの立ち上げに携わりました。ちなみに、苗字が郷田ということもあって、社内では「ジャイアン」と呼ばれています。懇親会でお話しする際は、「ジャイさん」と呼んで頂ければ幸いです。ドラムが好きで、「BABY METAL」というバンドがあるのですが、最近は、そのバンドのメンバーからドラムのレッスンを受けているくらいドラムが好きです。

次に、プロダクトの紹介です。インサイドセールスのマネジメントを行うためのSaasプロダクト「Biscuet」を開発しております。プロダクトのビジョンとしては、「効率的かつ効果的な営業組織を世の中に広める」ことを掲げています。インサイドセールスについて少しお話しておくと、昔は、セールス担当者がマーケティングから顧客サポートまでを一人が継続してサポートするという体制が一般的でした。しかし、そのプロセスからマーケターが切り離され、カスタマーサクセスが切り離され、このような形で、最近では、インサイドセールスやフィールドセールスという役割が生まれてきています。業務を分業化することによって、担当営業に依存せずに、専門領域に集中するというのが最近の営業組織のトレンドです。

そして、この中で言えば、Biscuetはインサイドセールスの領域に特化したSaaSです。ちなみに、同じ業界のサービスで言えば、Salesforceさん等があります。

利用技術については、以下の通りです。

ここからが本番です。「開発リーダーが結果的にPMと呼ばれるまで」について振り返ってきたいと思います。

まず、こちらがタイムラインです。上側が業務のタイムライン、下側が私の役割のタイムラインです。

実は、私は業務がある程度出来上がった段階でチームに加わっています。2018年12月頃、BAILSの業務専用システムの開発に取り組んでいたのですが、その開発の途中からジョインしました。先程、登壇していた米元が開発リーダーを務めていたのですが、その役割を引き継ぐ形で、私が開発リーダーになりました。

Biscuetの開発に着手し始めたのが、2019年3月です。その頃、プロダクトの成功について色々と考えた結果、「自分は越境しなければならないな」と考えるようになり、そのタイミングで、「プロダクト屋さん」に転身し、2019年8月にサービスをリリースしました。この後、また、2回目の越境があるのですが、ここからは1回目の越境と2回目の越境についてお話させて頂ければと思います。

まず、1回目の越境の話です。Biscuetに着手する際、当然、「プロダクトをやりたい」という気持ちは会社としてはありました。しかし、「誰に対するどのような問題を解決するプロダクトなのか」については特に定まっておらず、プロダクトの全体的な方向性を考える人もいませんでした。その頃、私は開発リーダーを務めていたのですが、そのことを上司に相談したところ、「だとしたら、それを考える役割を採用するかジャイアンがやるかの2択だよね」ということを突きつけられました。

実は、コーポレートIT部門の立ち上げの際も、採用をやらせて頂いたことがあるのですが、その経験上、「ゼロイチ」ができる人材の採用はめちゃくちゃ難しいということを強く感じていました。加えて、自社文化との親和性まで含めて考えると、採用にかなりの時間がかかってしまうことが想定される。「じゃあ、私がやるしかないよね」ということで、一度目の越境を決意しました。

「プロダクト屋さん」になると決めてから、「自分は開発はしない」「何よりも早く市場にプロダクトを出す」ことを最優先に考えました。具体的には、プロダクトをリリースする上でのボトルネックを見つけたり、そのボトルネックの改善に率先して取り組みました。足りない役割があれば、私が補うことを意識しました。ただし、自分が全部やってしまうと、自分自身の存在がボトルネックになってしまうので、補った役割をチームの担当者に分散させるということを心掛けました。最初の頃は、チーム内では、「やること多すぎやん！」「まとまって開発する時間とれんよ！」「要件を決める人も仕様を決める人もいないよ！」「モチベーション上がらんよ！」等と言われていましたが、それらをなんとか自分なりに咀嚼して、整理して、優先度を考えて、一つひとつに取り組んでいきました。

その中で、特にB2B SaaSプロダクトに関して言うと、求められる機能が非常に多いんですね。業務を完遂するために、あれもこれもやらないといけない。そして、プロダクトをリリースするためには、その中で、「何が最小限なのか」を見極めることも必要です。それが思っている以上に難しい。

これらを踏まえ、私自身も含め、エンジニアのドメイン知識を強化することに注力しました。具体的な取り組みとしては、あくまで一例ですが、業界のSaaSやサービスが出展する「営業支援EXPO」やインサイドセールスに関する日本最大級のカンファレンス「Inside Sales Conference 2019」に参加させて頂きました。また、インサイドセールスの会社向けのセミナーに参加したり、自社・他社も含めて、インサイドセールスの担当者の方々にヒアリングを行いました。

また、エンジニアチームのドメイン知識の向上については、個人的に「現代におけるセールスの教科書」として重宝している『THE MODEL』という書籍があるのですが、この本をエンジニアチームを含めて読み合わせをすることによって、ドメイン知識の向上を図っていきました。

また、二度目の「越境」の話ですが、弊社にはアドバイザーとしてお世話になっている方がいらっしゃいまして、その方に業務について色々とご相談させて頂いていたのですが、ある時、そのアドバイザーの方から、「あなたがやっていることはプロダクトマネージャーの仕事だと思います」ということを言われました。そして、そのタイミングではじめて、「プロダクトマネージャーという役割が足りていなかったらしい」ということを認識し、「自分がプロダクトマネージャーになるぞ」と決心しました。

さらに、最近、取り組んでいることとしては、インサイドセールスの担当業務フローや開発プロセスの整理を進めています。最後に、アドバイザーの方々から「参考にすると良いよ」と言われた書籍について、ご紹介させて頂きます。私からは以上になります。

B2Bサービスを作る上で心がけていること（渋谷 亮氏）

登壇資料：B2Bサービスを作る上で心がけていること

井上：ありがとうございました。続いて、株式会社マネーフォワードの渋谷さん、お願い致します。

渋谷：はい、株式会社マネーフォワードの渋谷と言います。宜しくお願い致します。本日は、私自身と株式会社マネーフォワードについて軽くご紹介させて頂いた後に、「開発者としてやって良かった取り組み」「社内の良いなと思った取り組み」をご紹介させて頂ければと思います。

まず、自己紹介です。渋谷と言います。株式会社マネーフォワードでVPoE（Vice President of Engineering）を務めております。インターネット上では、「ryoff」というIDで活動しております。マネーフォワードに入社する前は、ずっと広告のエンジニアをしていました。最初に登壇された米元さんは私の新卒時代の上司でして、今回はその縁でイベントに呼んで頂いた形です。マネーフォワード入社後は、ずっとB2Bの開発をしています。最初は「クラウド請求書」のエンジニアをしておりまして、その後は、「クラウド給与」「クラウドマイナンバー」の立ち上げをして、基盤やデータベース周りをやっていました。最近は、エンジニア組織全体を見るような立場で仕事をさせて頂いています。

今回は、会社紹介のスライドを1枚だけ用意しました。ご覧の通り、様々な事業に取り組んでいます。弊社には4つの事業ドメインがありまして、下記のスライドの一番左側がB2Bサービスです。弊社のサービスで一番有名なのは「家計簿サービス」だと思いますが、こちらはB2Cサービスです。また、金融機関と連携し、B2B2C事業にも取り組んでいます。さらに、新規事業にも積極的に取り組んでいます。様々な領域で事業を展開している会社です。

では、早速、「開発者としてやって良かった取り組み」を紹介させて頂きます。私自身、「B2Bサービスの特徴って何だろう」ということを良く考えるのですが、当たり前ですが、ビジネス向けであるということ／多くの会社の業務フローに取り込まれるということが特徴なのかなと思っています。また、「サービスが止まると仕事が止まる」「バグが出ると仕事が止まる」「仕様が変わると仕事が止まる」という感じで、サービスの安定稼働が特に求められる領域なのかなと考えています。弊社の中でも、「短距離走ではなく、どちらかといえば、マラソンっぽい開発だよね」ということが言われることがあります。「一瞬、120%頑張ることよりも継続的に80%頑張ることが大事だよね」という言い方もできるかと思います。

なので、新卒でモチベーションが非常に高くて、「帰りたくないです」「死ぬほど働きます」みたいな方がたまにいらっしゃるのですが、そのような方に対しては、「まあまあまあ。落ち着いて」「1〜2年後を見据えながら、もう少しゆっくり働いていこうよ」という話をすることがあります。また、個人で最速で立ち上げることが大切なフェーズは確かにあって、それ自体はまったく否定しないのですが、一方で、「チームに知見を残す」「誰かが辞めてもプロダクト開発が止まらない」ことも非常に大事かなと思います。課題としては、「暗黙知」「立ち上がり」「チームビルディング」「可読性」「メンテナンス性」といったところがキーワードになるのかなと考えています。

個人的にも、このあたりはずっと悩んでいて、私自身、失敗と成功を繰り返し続けているのですが、その中で、いくつかの取り組みをご紹介させて頂きたいと思います。

一つ目ですが、「和英辞典」を作成することに良く取り組みます。例えば、下記のスライドの中で言えば、「苗字」の英訳は「family name」「last name」のどちらでも英語としては間違っていないのですが、プロダクトの中にそれらが混在してしまうと、可読性が著しく低下してしまう。要するに、ワーディングを揃えるということですね。あとは、「略さない」ということも凄く重要です。

このような用語集を社内のWiki内に置いて、同じような単語については、「ワーディングを揃えようよ」ということを全員に意識づけています。また、コードを書く時間よりも読む時間のほうが長いことも踏まえ、「可読性を向上させて、属人性を排除していこうよ」という目的で、色々と取り組んでいました。

2つ目ですが、「もくもく会」のようなことをしていました。他部署の方には大変申し訳ないのですが、会議室を半日確保して、エンジニアとデザイナーが集まって、みんなで開発をします。お互いに話をしたりすることは基本的にはないです。ずっと自分で開発しているだけなのですが、「あれ、ここってどうなってる？」という風に、わからないことがあれば、目の前の人がその場で答えてくれるような環境を用意することは、実は重要かと思います。

3つ目ですが、「やる意思決定」よりも「やらない意思決定」を重視しています。これはニュージーランドに移住したプログラマーの方のブログから拝借してきたフレーズなのですが、そのプログラマーの上司は、「長時間仕事をしたところで、仕事が終わるなんてありえない」「問題解決するたびに、次の問題が見つかる」「常に苦渋の決断をしながら、優先順位をつける」「システム開発のような知的労働は、いくら時間をかけたところで終わらない」と主張していまして、様々な気づきを得ることができます。

実際、リリースまで1ヶ月で、ちょうど1ヶ月分のタスク量の状況があった場合、「あ、オンスケでいけるじゃん」という話になりがちなのですが、多くの場合、そうはいきません。「エンバグ」「デグレ」「仕様変更」「仕様漏れ」等が発生し、「10の仕事を終えれば、新たに3の仕事が生まれる」ことが通常です。

このあたりについては、昔、エンジニアブログに書いたことがありまして、興味があれば、見て頂ければと思います。それでは、ここからは「社内の良いなと思った取り組み」をご紹介していければと思います。

1つ目ですが、これも「暗黙知」を減らすことにつながる話なのですが、弊社では、「社内用語集」が数多くあります。具体的には、会社本体の「社内用語集」に加え、「プロダクト用語集」「業界用語集」「新卒今さら聞けない用語集」等があります。また、私が取り組んでいることで言えば、「歴史オリエン」というものがあります。例えば、「聞けば一瞬で分かるけど、聞かない限り、一生、謎が解けない設計や仕様」というのは、多かれ少なかれ、どの会社でも存在すると思います。これについては、古株のメンバーが「懺悔の気持ち」とともに、「これからどうしていきたいか」をしっかり伝えていく必要があると思っています。

せっかくなので、この場で一つ事例をご紹介させて頂きます。マネーフォワードは今はRailsで動いていますが、昔、 PHPで動いていた時代があります。どういうことかと言うと、起業当初、PHPベースでSNSを作ろうとしていた時期があり、「PHPっぽいコード」や「PHPっぽいテーブル」が残っています。これに遭遇すると、多くの場合、「なんじゃこれ」となるのですが、弊社のエンジニアであれば、誰もが一度は通る道かと思います。あとは、「歴史オリエン」で言えば、「昔、こういうことがあって、こういう意思決定が正しいと思って実行したけど、今から見ると、正直間違っているよね」というような開発の経緯の説明については、古株のメンバーだからこそできる側面があります。こういった開発の経緯を「すまん」という気持ちを示しながら、誠実に説明していくことが重要だと考えています。

あとは、最近、「良いな」と思っているのが、「パルスサーベイ」と「オンボーディングフィードバック」です。これは、毎日の「体重測定」のようなものです。全社的なサーベイについては、半年に1回の頻度で行っているのですが、パルスサーベイとは、「この会社を知り合いに紹介したいと思うか」等の質問を通じて、より短いスパンで、皆さんの会社への「想い」を集めていく仕組みです。2年前の課題と今の課題では性質がまったく異なりますし、組織の規模・フェーズ・文化が変われば、それに応じて、課題も変わります。「今の課題」に気づくためには、短いスパンで、組織について把握する必要があり、これは非常に良い取り組みだなと思いました。

また、こちらは、クックパッドさんのデータベースドキュメント管理システム「dmemo」です。簡単に言えば、「データベースwiki」のようなものです。新しく入社された方から、「ER図はないんですか？」と言われることがありますが、個人的な意見ではあるのですが、ER図というのは一度作ると、メンテナンスがめちゃくちゃ大変で、心が折れるタイミングが基本的には訪れるものだと考えていまして、弊社では、この「dmemo」を数年前から活用させて頂いています。

最後になりますが、「未来の組織図会議」を3ヶ月に1回の頻度で行っています。組織が大きくなって、「3年後に事業計画上はこうなる」ということが明確になると、その売上をつくり出すプロダクトの大きさやそのプロダクトの大きさを支える組織体制について考えます。もちろん、完璧には把握できないものの、とりあえずマッピングします。マッピングした上で、「30人のエンジニアを統括できるマネージャーって社内から生まれてくるの？」「生まれてこないなら、採用しないといけないけど、採用できるの？」「採用するための社内の給与レンジって市場と整合しているの」といったことをチェックしていきます。

具体的には、社内のエンジニアのグレード等を見ながら、「この人はきっとここまで伸びてくれるはず」という風に、各メンバー毎の期待値をベースに考えながら、次の半期の役割を考えていきます。

私からは以上になります。今回は、「良い取り組み」について紹介させて頂きましたが、失敗についても、数多く経験しています。そのあたりについては、懇親会で色々とお話できればと思います。本日は、有難う御座いました。 

インターナルマーケティングで織り成すマルチプロダクト開発（戸本 裕太郎氏）

登壇資料：インターナルマーケティングで織り成すマルチプロダクト開発

戸本：はじめましての方が多いと思いますので、自己紹介をさせて頂きます。戸本と言います。インフラ業界でエンジニアリングに携わってきた人間です。現在は、株式会社Linc’wellで医療業界向けのシステム開発に取り組んでいます。前職では、電力業界の非常にレガシーなシステムの開発に取り組んでいました。

ML（マシンラーニング）やブロックチェーンが好きです。個人的にプライベートチェーンを構築したりもします。（戸本氏追記：全然関係ありませんがこの記事を執筆中に引っ越すことになり、自宅の巨大リグをたたまざるを得ない状況になりました。あー・・・だれか電気代固定で運用できる場所を提供してくださらないかな・・・）

株式会社Linc’wellについてご紹介させて頂きます。創業は2018年1月。従業員は13名で、エンジニアは私を含めて6名という状況です。何に取り組んでいる会社かと言うと、ちょっと珍しいのですが、「病院」を作っている会社です。ですので、ITだけではなくて「箱」を作っています。私はエンジニアとして、患者さんの「体験」を良くするためのSaaSサービスの開発に取り組んでいます。

一般的に、病気に関わる事業というと、病院での体験をイメージする方が多いと思いますが、患者にしてみれば、病気というのは一日を通して辛いものですよね。弊社はそのような患者のコンテキストを通して、病院内外でより良い体験を広げていくことに注力しています。弊社のサービスを活用して頂くことで、来院前に「予約が簡単にできる」、来院中に「アルゴリズムで素早く診察入り」「iPadで院内検診」「クレカ事後決済」、来院しなくても「オンラインで診察」「薬をEC決済して宅配」等が可能になります。（※オンラインでの診察は、法律上、一部の自由診療に限られます。）

これは病院内外にある複数の顧客接点に対応するということなので、会社のフェーズに比べてプロダクトの数は多いです。具体的には、ウェブ／モバイル／LINE／ECサイト等がありますが、とにかくプロダクトが多い。最初の頃は、1チーム体制で開発を進めていたのですが、最近、そのやり方では、「うまくいかないな」と思うことが多くなってきました。

これから話すことは弊社の課題なので、皆さんにも当てはまるかどうかについては定かではありませんが、弊社のエンジニアには、BtoB ー医療ではBtoDtoC （Dはdoctor） と呼ばれたりしますがー において、「すべてのプロダクトに携わりたい」というタイプの人間が多いです。こういう事業モデルなので、なるべくすべての患者接点に関わりたいというマインドの人が集まってくるのは、当然ではあります。

とはいえ、このマインドを持った集団、実業務となると、おかしな現象が起きます。ユーザーの要求を叶えるべく、設計やプラクティスを議論するときは非常に盛り上がります。仲もいいですし、素晴らしいチーム議論が行われています。ただ、プロダクトが多いが故に、選択肢や共通部分の依存が密接で、そのようなケースで「共感」のみで議論を行うと、「あれもいいね」「これもいいね」で軸があいまいになりやすく、現実的なアクションがふわっとしたままミーティングが終わっていくことが散見されました。日本人特有の譲り合い精神みたいなものも関係あるかもしれませんね。あと、ファシリテーションやビジネス感覚をエンジニアに求めるのは酷とも思います。議論がディストピア化するとコスト感覚も失われていきます。

で、これは近くで見ていて「やばい」と感じました。何が「やばい」かと言うと、優先順位が存在していないことなんですね。でも、せっかく良い議論ができているのに、そこに割って入って、偉そうにファシリテートするのもなんか違う。それをやったら結果は出るけど、彼らの思い描いているカルチャーでは無くなってしまって、楽しくないです。なので、最初に取り組んだのは、彼らに「ポジション」を取ってもらうことでした。ちょうど一人一プロダクトくらいの組織なので、普通に一人一プロダクトを担当してもらい、お互いのポジションでどのような実装がベストなのかについて交渉してもらうような組織に変えました。

これ、普通のことしか言ってないように思われますが、最初は大反発というか、全く受け入れてもらえませんでした。今まで「全部やりたい」っていう熱量でコミットしてきた人たちなので、（患者接点をすべて押さえるという事業モデルからして、自然とそういう振る舞いを呼び込むんですね）領域を縦割りにされたら不自由さを伴うというか、自分がスタートアップに貢献するにあたってすこぶるやりにくいわけです。もうね、「嫌です」とか「なんすかそれ」とか「そういうのリンクウェルっぽくないっす」とか散々言われまして。

我々エンジニアの思いの丈の根幹って、時に「信念」というか、「やるからには〜」みたいなアツい想いがあるんだと思い知らされました。だから、彼らの気持ちについて、「それはそうだな」と思いまして、彼らを変えようとするのではなく、「インターナルマーケティング」の考え方を取り入れることで工夫しました。

インターナルマーケティングというのは、簡単に言うと、従業員満足度を高めるための施策で、社内の人間に向けたマーケティングのことです。一般的に、マーケティングというのは顧客に対して行うものですが、そもそも社員が働きやすい環境を整備したり、働く上での目的をキチンと設計しないと、エンドユーザーに対して良いものが作れないという話です。良く言われている話ではあるのですが、これをインターナルマーケティングと言います。

とはいえ、冷静になれば10人ちょっとの会社ですから、仕組みを入れるリソース自体ないと思っています。ですから、私が行ったのは非常にシンプルな行為で、エンジニア達に「今日、仮に一つのことしか出来ないのであれば、一番やりたいのはどれですか？」と問うことでした。このような聞き方をすると、面白いことに、最初は「えっ？」となるんですが、だんまりの後、最後は、凄くしっかりした目で「私はこれがやりたいんだ」って主張してくるんです。

言うなれば、「スラダンの三井」現象です。自分にとっての「一番」を自ら見つけてもらうことが大事だと言うことですね。

弊社には、私以外にエンジニアが5名在籍しているのですが、このような問いかけをすると、顔つきの違いはあれど、必ず「私はこれをやりたい」と宣言します。即答でプロダクト名しか言わない人もいます（笑）これ、一様に答えてくるのが不思議な現象だと思うのですが、クリエイティビティが源泉の人間というのは、自分の欲求をコミュニケーションすることに限っては、非常に正直ということかと思います。とにかく自分の一番を見つけてもらうことが大事でして、その段階で、「じゃあ、それでいきましょう」と私から伝えます。

「やりたいこと」と「やるべきこと」が重なると強い、という話は良く言われることだと思うのですが、私のような立場でより大事なことは、「やりたいことにやるべきことが重なっているようなモチベーション設計をすること」だと考えています。

弊社では、制度としてのOKRは採用していないのですが、少しカッコつけた言い方をすると、この状態は、「セレンディピティによって、OKRが自然に発生している状態」と言えるのではないかと考えています。一人一プロダクトをリードしてもらうわけなので、結果的に本人がチームリーダーであり、元が一人なので個人のOKRがチームのOKRに直結します。また、会社のグロースに燃えて入ってきているわけなので、そのマインドは組織全体の目標を意識したものになっています。CTOが下手な策を講じるよりもよほど自然で、いけてますよ。

また、いい意味で副作用もあります。各々繁忙してくると、自分のプロダクトをローンチしたり仕事をクロージングまで持っていくためには、余裕はないので、お見合いミーティングしている場合ではないという意識になっていきます。ですから、当たり前ですが、交渉が作用し、やり切るわけです。そうすると、結果的に、彼らが以前は失うと思っていた権利みたいなものに対して「ポジションをとってもやれるじゃん」ということに気づき始めます。これは、コミュニケーションを工夫する中で、リードで必要とされる力が身に付いたということだとすると、私の立場としては、かなり「棚ぼた」なことではないでしょうか。

とはいえ、制限もあります。希望が重なってしまうこともあるわけですし、そういう時はなんとかせざるを得ません。また、この話はすべての組織に応用できるかと言うと、そんなことは無いだろうと思っています。あくまでも弊社のような特徴を前提にした小さい組織での「工夫」の話です。笑い話ですが、仮に「誰も担当したくない」という役割が発生したら、私が担当することになります（笑）そういうわけなので、万能ではありませんが、PMFを目指して日々走る小さな組織においては、わりとベターなプラクティスの一つなのではないかと考えています。

最後に、弊社の宣伝をさせて頂きたいと思います。実は、ここ田町にも病院があります。実は田町発祥でして、週7日・夜21時まで開院しています。「クリニックフォア田町」という病院です。エンジニアは夜遅くまで仕事をすることもあると思いますが、院内処方ならばたった15分間で薬をもらうところまでいける病院です。仕事をサッと抜けて、訪れることもできるかと思います。

ちなみに、先程調べたのですが、スマートキャンプ本社からも11分でいける場所だそうです。

また、興味を持って頂けましたら、実際に来院して頂けると良いと思います。それでは、本日はどうもありがとうございました

B2B SaaS開発におけるモチベーションマネジメント（曽根田 侑也氏）

登壇資料：B2B SaaS開発におけるモチベーションマネジメント

曽根田：こんにちは、A1A株式会社の曽根田と申します。本日は、「B2B SaaS開発におけるモチベーションマネジメント」というタイトルでお話させて頂ければと思います。

まずは簡単に自己紹介をさせて頂きます。私は新卒で営業を一年半やっていまして、その後、婚活アプリ／旅行系アプリ／漫画系アプリの開発に取り組んでいました。 A1A株式会社には今年の2月に入社しまして、エンジニアをやっています。

好きな漫画は「GIANT KILLING」です。「GIANT KILLINGの楽しみ方」という資料を作成したので、機会があれば、ご覧頂ければと思います。

A1A株式会社について簡単にご紹介させて頂きます。2018年6月26日に設立した会社です。設立して一年半くらいのベンチャー企業です。社名の由来ですが、「B2Bをワンランク上に」というミッションを掲げており、結果、会社名がこのような名称になりました。

現在は、ビジネスサイドが8名／エンジニアが7名の合計15名で事業に取り組んでいます。提供しているサービスは「RFQクラウド」という名前でして、2019年10月2日にリリースしました。サービスについて凄く簡単に説明すると、製造業には調達購買というプロセスがあるのですが、その調達購買に対するソリューションを提供しているプロダクトです。より具体的には、購買調達の中でも、「見積査定」という業務があるのですが、これがなかなかアナログな業務でして、そこにデジタルを取り入れて、購買担当者にもっと楽になってもらうことを目指しています。

本題に入る前に、皆さんにお聞きします。 B2C領域のアプリって、パッとどれぐらい想像できるでしょうか。多分、たくさん頭に浮かびますよね。内容が分かりやすくて、とっつきやすくて、クリエイティブなイメージがある。自分も最初はそうでした。

それに対して、B2B SaaSのプロダクトですが、正直に言って、私自身、Smart HR／ジョブカン／マネーフォワード／freeeくらいしか知りませんでした。

ちなみに、B2B SaaSには二種類ありまして、「Vertical SaaS」と「Horizontal SaaS」があります。Horizontal SaaSというのは、会計／人事／採用など、どの企業にも存在するような機能に対するソリューションを提供しているSaaSのことを指します。一方、Vertical SaaSというのは、業界に特化したSaaSのことを指します。例えば、弊社であれば、製造業に特化したSaaSですし、KAMINASHIさんであれば、食品業界に特化したSaaSです。

ここからが本題なのですが、B2B SaaS開発のイメージって、B2Cに比べると、「クリエイティブじゃないよね」「自社開発というかむしろ受託開発に近そう」「技術的チャレンジの機会が少なそう」といったネガティブなイメージを持たれがちだなと思います。何を隠そう、私自身、そう思っていました。

今回の目的としては、この発表を聞いてもらって、「B2B SaaS開発ってイノベーティブだよね」「ユーザー思考がめちゃくちゃ必要とされるよね」と思って頂ければ、本当に嬉しいです。

それでは、本日のアジェンダです。「Vertical B2B SaaS開発の難しさ」「弊社での技術的チャレンジについて」「まとめ」の順にお話させて頂きます。

まず、「Vertical B2B SaaS開発の難しさ」についてです。弊社でも、新しく入社した方にお話を聞くと、「そもそも何をつくっているかわかりにくい」と言われることが発生します。なぜそのような問題が発生するのかと言うと、弊社の場合、製造業の調達購買に対する情報収集が難しいという点があります。また、様々な企業から多様な要望がやって来るため、どれが正しいのかがわかりにくい。さらに、企業向けのシステムであり、個人向けのフリーミアムなアプリではないため、仮説検証を行うことも難しい。

これらを一つずつ説明していきます。まず、情報収集が難しい理由についてですが、「身近に参考になるアプリケーションが少ない」「実業務とあまりにもかけ離れている」「業務内容が複雑であり、専門用語が多い」が挙げられます。実際、Horizontal SaaSのプロダクトと比べて、「実業務として身近に感じられない」という側面は確かにあります。例えば、Smart HRさんであれば、年末に利用する機会もあるでしょうし、なんとなく想像がつきます。一方、弊社のような製造業の見積査定システムについては、なかなか想像がつきにくい部分があります。また、業務内容が複雑で専門用語が多いことも特徴として挙げられます。

これらの課題に対して、どのようにして解決していったのかというと、まず、実際に展示会に参加してみました。

あとは、営業に同行していました。さらに、弊社にはドメインエキスパートとして真壁さんという方が在籍しているのですが、真壁さんと積極的に飲みに行ったりして、普段から質問できる環境を作っていきました。

弊社では、時々、全社員を巻き込む形で、真壁さんが社内向けに勉強会を開催して、見積査定のロープレをしてくれます。普段は優しいんですが、勉強会ではビシバシと教えて頂いています。

また、企業からの要望が多様な理由ですが、営業の人間から話を聞く限りでは、そもそも顧客自身が課題を認識できていないこともあって、そのため、色々な要望が出てきてしまうという側面があります。特に、製造業の場合は、企業によって業務内容がバラバラで、なかなか大変です。あとは、顧客自身が現在の業務フローが絶対に正しいと思っているケースが多いです。

これらの課題を解決するために何をやるかというと、「本当に解決したい課題とは何か」ということを追求します。あとは、「要求」自体は違うのですが、共通する部分もあるので、それらを「一般化」していくことを心掛けます。また、業界別に共通項がある場合は、グルーピングして、別機能として提供します。さらに、お客さんが「絶対に正しい」と思っている業務フローを見直すために、デザイナーさんを巻き込んでUXを設計していくことも大切です。

こちらは、AsIs／ToBeシートと呼ばれるものでして、簡単に言えば、営業担当が営業活動をした際に、お客さんの現状を細かく記載するシートです。お客さんの要望をヒアリングしつつ、このシートを活用しながら、「こうなるのが理想だよね」ということをお客さんと合意を取って、「じゃあ、 RFQクラウドでどうやって解決しましょうか」という形で解決していきます。

こんな感じで、ストーリーマッピングを作ってみて、デザイナー／PM／エンジニア／営業／ドメインエキスパートを含め、全員で議論していきます。

3番目の「解説検証が難しい」という点ですが、最初に軽く話しましたが、フリーミアムなプロダクトが少ないので、自分で触って試すことができません。また、企業業務に深く関わっているので、 B2Cの製品のようにどんどんアップデートして、ABテストを行うことも難しい。さらに、プロダクトの最初の設計のミスが将来の大きな「負債」になる可能性がある。

これらを解決するために何に取り組んでいるかと言うと、これは弊社の代表の松原が書いたブログにも記載されていますが、最初はプロダクトがないので、何をやったかと言うと、購買担当の方に徹底的にヒアリングを行い、モックと営業資料をつくる。その上で、松原が営業に行って、お客さんとやり取りする中で、「これは違うよね」「ここはもっとこうしてほしい」ということを繰り返して、実際に画面のイメージを見てもらって、それを展示会や営業の場所で繰り返して、やっと10月2日にリリースした形です。

また、弊社では、デザイナーの佐藤さんが非常にこだわってくれているのですが、「デュアルトラックアジャイル」 のカスタマイズ版を活用しています。このフローを回すのが良いプロダクトへの道のりだということで、凄くこだわってやっています。内容について、ざっくり言うと、情報を集めて、分類して、きちんと課題を抽出して、優先度を決めて、開発に入って、テストを回してというようにして、キチンとPDCAを回していきましょうということですね。

最後ですが、弊社の「技術的なチャレンジ」についてご紹介させて頂きます。上から順に、「共通コンポーネントの独自実装」「高度なデータモデリングとスキーム設定」「マイクロサービス・ビッグデータ」です。

まず、フォームライブラリーの独自開発ですが、このフォームはJSONをもとにして作られています。このフォームがなぜ必要なのかと言うと、見積の明細って会社ごとにバラバラなので、ここだけはこだわって、「カスタマイズできるようにした方がいいよね」ということでつくりました。元々、Mozillaがつくっていた「react JSON schema」というライブラリを利用していたのですが、「今後のことを考えると、拡張しにくいよね」ということで、21歳の若手のフロントエンジニアが作ってくれたライブラリです。「そのうち、OSSにしたい」と言っていたので、楽しみにしていてください。

「高度なデータモデリングとスキーマ設定」についてですが、左が弊社のCTOの佐々木の資料で、右が弊社のフロントエンジニアの資料です。気になる方は是非見て頂けると幸いです。

未来の話ですが、弊社のサービスは「多言語対応」していく必要があると思っています。また、現在は、「RFQクラウド」という見積査定に特化したサービスになっていますが、その前後のサービスについても、「プロダクトとして押さえていきたい」と考えていますので、どんどんマイクロサービス化していきたいという話をCTOとしています。

また、データがどんどん溜まっていくので、それを利用して、何か分析できるようなツールを作りたいということは考えています。それは技術的には非常にチャレンジだなと思っています。最後にまとめになりますが、複雑なユーザー組織のミッション・ドメインを正確に理解することが大事だなと感じています。その上で、風呂敷を最大限に広げて、ミニマムな設計と実装で作っていく。「ちょっと間違っていた場合でも、簡単にやり直せるような設計をしていきましょう」ということですね。あとは、ドメインを深く理解することで、未来を描いた技術的チャレンジも広がっていくのではないかと考えています。

どうでしょうか。B2B SaaS開発のイメージが湧いたでしょうか。このようなことを意識することで、B2B SaaS開発へのモチベーションを維持できるのではないかなと考えています。この発表を聞いて、B2B SaaS開発に対して、ポジティブな感情を持って頂ければ、今回の発表は自分にとっては大成功です。ご清聴ありがとうございました。

B2B製品開発における7つの失敗（堀 譲治氏）

登壇資料：B2B製品開発における7つの失敗

井上：それでは、最後に、株式会社シャノン CTOの堀さん、宜しくお願い致します。

堀：シャノンの堀と申します。本日は、「B2B製品開発における7つの失敗」というテーマで発表をさせて頂きます。直前のA1A株式会社さんの発表とは対照的に、凄く「ネガティブ」なことを言います（会場笑）。会社としては、20期目に突入しています。製品自体も15年ぐらいやっていて、数々の失敗を踏んできているので、「皆さんには同じ失敗をして頂きたくない」という思いで、本日は発表させて頂きたいと思います。

まず、私自身についてですが、株式会社シャノンという会社に在籍しています。大学卒業後、日本オラクルに入社しまして、7〜8年くらい働いていたのですが、やはり外資系の日本法人だと、なかなか製品開発に取り組むことが難しい面がありました。ちょうどその時、たまたまシャノンと知り合う機会があって、「自分でサービスを開発したい」と考え、入社を決心しました。私自身は、コーディング自体はそこまでやっていないんですけども、どちらかと言うと、技術のディレクションやプロダクトマネジメントに取り組んでいました。ちなみに、弊社はこのビルの4階にありまして、同じビルつながりで今回のイベントには呼んで頂いている形です。

事業内容としては、「SHANON MARKETING PLATFORM」というソリューションを提供しており、主に、マーケティングオートメーションやイベントマーケティングのサービスとして利用して頂いています。また、付随するコンサルティングサービスや導入サービス、BPOについても提供しています。

本日は、「B2B製品開発における7つの失敗」というお話をさせて頂きます。資料を作成していたら、7つに収まりきらなかったのですが、この点については、ご容赦頂ければと思います。以下、順番にお話させて頂ければと思います。

1. 顧客ごとのカスタマイズを受けてしまう

まず、一つ目ですが、創業期においては良くあるケースかと思われますが、「顧客ごとのカスタマイズを受けてしまう」です。もちろん、顧客ごとに「設定」を変える等であれば良いと思うのですが、「ソースコードの分岐」は基本的には避けたほうが良いと考えています。営業担当からは、「これを取れたら1000万円の受注になります」と言われて、まあ、悩むわけです。しかし、ここは心を鬼にして、カスタマイズは極力受けない方向で、「標準機能のままで設定を変えてもらう」「お客さんにそもそもの要件自体を見直してもらう」等で対応すべきケースが多いように思います。

2.開発はたくさんいるが営業とマーケが少ない

2つ目ですが、「開発はたくさんいるが営業とマーケが少ない」です。もちろん、創業期であれば、それが普通だと思います。しかし、製品が徐々に売れてくると、営業とマーケを採用する必要が出てきます。1000社にアプローチすれば、そのうちの200社が買ってくれるような状況だったとしても、営業・マーケの人員数が少ないと、50社くらいにしかアプローチすることができません。結果、その50社のみからの契約獲得を目指すことになる。そこで、どうなるかと言うと、「開発をたくさんしよう」「少ないお客さんにフィットさせに行こう」という話になりがちです。しかし、一社でもお客さんがいるということは、当然、フィットしている状況があるということなので、「フィットするお客さんをいかにして見つけに行くか」という風に発想を切り替えていく必要がある。もちろん、最初は開発が大事なのですが、その後は、営業とマーケに工数をかけることが必要となります。お客さんの要望に対応するというよりかは、「その製品がフィットするお客さんを見つけ出す」ことに注力する方向に切り替えていかないといけない。このあたりの切り替えの重要性については、私たちも当初は理解できていなくて、「目の前のお客さんに対応していけば良いでしょ」と考えていた時期がありました。これは反省ですね。

3.営業が機能の存在を説明できない

3つ目ですが、「営業が機能の存在意義を説明できない」です。会社／製品レベルでの話であれば、営業担当者がしっかり説明できるものの、機能レベルで落とし込むと、だんだんと怪しくなってくる。組織が小さいフェーズでは、こういうことはあまり発生しないのですが、組織が徐々に大きくなってくると、営業担当者がお客さんの質問に答えられないケースが出てきます。これは開発／企画サイドにも責任がある場合があって、機能に関する説明を社内で十分にしていなかったり、説明資料が作成できていない場合が考えられます。「どのような課題を解決するための機能なのか」について、社内においても、正確に認識を合わせることが重要です。

4.目指すアーキテクチャと組織図がずれている

4つ目ですが、「目指すアーキテクチャと組織図がずれている」です。これも過去に何回か経験したのですが、アーキテクチャというのは、技術的な要素だけで決まるものではなくて、会社の状況／ビジネスの状況で決まる要素も少なからずあると思っています。過去に、弊社においても、Perlベースの古いモジュールがありまして、「Perlでは人を採用できない」ということで、「新しい言語で新しいモジュールを作ろう」と考えていた時期があったのですが、その時にまずかったのは、組織を分けてしまったんですね。弊社が提供する製品としては、ひとつなのですが、組織を分けてしまった。すると、組織を分けた瞬間に、「あっちのチームがAPIを空けてくれない」とか「こっちのプロジェクトの要望に合わせてくれない」という風に、色々な不満が出てきてしまいました。目指すアーキテクチャと組織図を整合させることが重要です。逆に言えば、アーキテクチャというのは、基本的には、組織図の通りにつくられていくので、どちらかというと、「つくりたいアーキテクチャに対して組織図を合わせる」ことが大事かと思います。人は無意識のうちに組織を守るコードを書くものです。

5.重要な課題を解決していない

プロダクトの話に戻りますが、5つ目は、「重要な課題を解決していない」です。これは、日々、プロダクトマネジメントに関わっていて、非常に痛感しています。ご存知のように、 B2Bサービスというのは、非常にスコープが広くて、お客さんからの要望も多種多様です。お客さんも色々なことを言うし、カスタマーサポートも色々なことを言うし、営業部門も色々なことを言います。しかし、それらの要望のすべてに答えようとすると、何も生まれないことが多い。有名な話ですが、マクドナルド社でユーザーにアンケート調査をすると、「ヘルシーメニューが欲しい」「サラダが食べたい」という要望が出るのですが、実際に、ヘルシーメニューを出してみると、全然売れない。このように、お客さんが「言っていること」と「本当に求めていること」は違うんですね。お客さんが「欲しい」と言っている機能でも、「本当にお金を出してまで欲しいですか？」と聞くと、「お金は出せない」という話になることは実は多いです。「その課題はお金を払ってまで解決したい課題なのか」ということまで掘り下げて考えることが大切です。

6.技術的負債に向き合っていない

6つ目は、「技術的負債に向き合っていない」です。弊社では、Google Driveでドキュメント管理を行っているのですが、「技術的負債」というワードで検索してみると、結構、色々と引っかかってきます。13年間も会社をやっていると、「負債」の話が年に1回くらいは出てきます。引き継ぎ資料の中にも「負債」という言葉が入っていて、負債まで引き継がれている（会場笑）。「引き継がれた側は可哀想だな」と思うのですが、これを解決するのはなかなか難しいです。

弊社では、この点について、どのように対応しているかについて説明します。負債には、「大きい負債」と「小さい負債」がありますが、「小さい負債」については、開発のサイクルの中で、出来るだけ解消していくことを意識しています。そして、「大きい負債」については、必ず、「ビジネステーマとセットで返す」ような形を心掛けています。具体的に言うと、「ビジネス的なパフォーマンスが上がる」とか「セキュリティのレベルが上がる」といった風に、ビジネステーマとセットで対応することを常に意識しています。このあたりはなかなか難しいのですが、「ポリシーをセットする」ことも大事かなと思います。もちろん、会社ごとに状況は違うので、「これが正解」ということは一概には言えないですが、「ポリシーをセットする」ことは心掛けるべきかと思います。

7.自動テストがなく、年に一度ビッグバンリリースをしている

7つ目ですが、最近はあまり無いのかもしれませんが、自動テストがなくて、年に一度、大きなリリースをしているケースがあります。弊社の場合でも、初期の頃は、自動テストをうまく作れず、溜め込んだ機能を一度にドーンと出していました。例えば、12個の機能がある場合、毎月一個ずつ出した方が本当は良いのですが、「一年間かけて12個の機能を貯めこんで出す」ようなことをしてしまうと、本当に爆発してしまって、大変なことになります。こうなると、営業担当も説明しきれないですし、カスタマーサポートも本当に大変です。自動テストをしっかり組んで、「毎月リリースしていく」「作ったものからすぐにリリースしていく」ということが重要かと思います。

8.KPIで全社の意思疎通がはかれていない

8つ目ですが、「KPIで全社の意思疎通がはかれていない」です。さすがに「売上」については誰もが意識すると思うのですが、売上のひとつ下の階層のKPIである「解約率」や「一社あたりの獲得コスト」等についても、できうる限り、メンバー全員が意識すべきかと思います。 特に、スタートアップ企業の場合、組織全体を見ることができる状況で仕事ができることもありますし、そのメリットを享受する形で、目の前の実務に取り組みつつ、事業全体についても、しっかり把握する姿勢が大事かなと考えています。

9.仕事を見てるが人を見てない

最後ですが、「仕事を見ているが、人を見ていない」というケースがあります。特に、私も含めてですが、エンジニアって人に興味がないケースが多いのですが、それだと組織は大きくはなりません。「どのようにして人と向き合うのか」「どういう思いで仕事をしているのか」等について考えて、人に向き合いながら、組織を作っていくことが重要だと考えています。

最後に

今回のイベントレポートは以上となる。スマートキャンプ株式会社では、今後も、B2B SaaSエンジニア向けのイベントを定期的に開催していくとのこと。直近では、12/6（金）に「B2B SaaSエンジニアMeetup – Sharing Issues #2」が行われる予定。参加希望の方は、connpassのページから申し込みをすることを推奨する。