自己紹介と株式会社hokanについて
横塚出氏（以下、横塚）：よろしくお願いします。今日は「組織で向き合う、しくじりと開発体制の歴史」ということで、hokanの2年間ほどの開発体制で、しくじってきたところを中心に振り返りたいと思います。
簡単に自己紹介です。私、システム開発系の会社や、学習塾保育園などを運営する会社を創業しつつ、大学時代からエンジニアをずっとやってました。中小企業でチーフエンジニアや、リクルートでデータパイプラインやAPIの開発などをしてました。今、hokanの取締役CTOとしてやっています。
hokanがどんな会社かというと、2017年に創業したので、もう5期目に入ります。ミッションは「保険業界をアップデートする」ということで、保険業界の課題をテクノロジーで解決すべく、InsurTechという領域で保険業界を盛り上げるべくやっています。
メインプロダクトの紹介をさせてください。われわれのメインサービスは、保険営業マン向けの顧客・契約管理システムhokanを、開発・提供しています。
昨今、保険販売でちょっとニュースになってる部分もあるかと思いますが、社会的なところにも意義を感じつつ、開発しています。保険代理店の成長支援するための顧客・契約管理システムをやっています。
いいプロダクトはいい組織から生まれない
さっそく本題です。本日お話したいこととしては、数年やってみても、「いいプロダクトを作るため、いいプロダクトは、やはりいい組織からしか生まれないなあ」と常々思っています。
顧客中心のプロダクトを目指して、われわれがどんなつまずきを経て、体制・文化を変えていったのかお話しできればと思います。かなり急ぎめになると思いますが、あっさりさらっと歴史としくじりについてお話しします。
しくじりと言いつつ、最初からちょっと自慢です。この2年間のサービスの成長ちゃんと見てもらえますか。この1年でしっかり3.5倍ほど伸ばしています。一応数字は出していますが、MRR（Monthly Recurring Revenue）です。
当然、内部の体制は正直なところ、いろいろとしくじっていました。メンバーにもすごく負荷がかかったりなど、多大なる迷惑をかけてはいました。そのあたりをお話しできればと思います。
フェーズ1の体制と反省
フェーズ1、フェーズ2、フェーズ3と、これからというところで、3つに分けて簡単にお話しできればと思います。
フェーズ1です。こちらの状況としては、とりあえずまだ機能GAPがありつつも、わりと大きな代理店さん2社のトライアルが終了して、年間契約を獲得しました。そのため、会社としてはすごくうれしいところですが、機能GAPを埋めにいくところと、新規顧客開拓すべく、新機能開発を行っていました。
開発体制としては、一応Biz、Devと。事業責任者と機能開発チームとに分かれていました。
しくじりポイントとしては、事業責任者がSales、CS、PM、デザインもすべて兼任しており、先ほどお話しした機能GAPみたいなところを、わりと機能軸で機能開発を分けていました。
どんなことが起きたかというと、想像つくかと思いますが、事業責任者の負荷増大というところ。事業責任者がSales、CS、PM兼任していて、どの立場からの意見かがすごくわかりづらく、優先順位の決めが難しい。
非常に感謝していますが、このときの事業責任者が優秀なプレイヤーであったがゆえに、初期フェーズをなんとか回してしまう部分もあって。“負債”という言葉で書いていますが、組織でサイクルを回すフェーズが、知らぬ間にちょっと先延ばしになってしまいました。
あとは、機能軸別でユニット開発を進めたことによって、属人化、品質の低下が起きてしまいました。実装が属人化してしまい、運用保証面での難易度がすごく高くなりました。実装方法にも差分が出ており、結果として品質がちょっと低下してしまい、結果、その機能部分だけまるまる、作り直すことになりました。結果、コストがかなりかかりました。
反省ですが、いわゆる兼任はよくない。もちろんありがちな話ではありますが、the model型ではなく、「スタートアップなんだからいけるっしょ」みたいな、ひたすら気合い型。
たぶん当時の弊社は、もう全員「やってやるぜ」みたいな。信じられないような目つきで大手町を歩いていた気がします。とりあえずその気合いだけでやっていました。
今振り返ってみると、やはり「最初だからしょうがない」という言い訳は無用です。採用は難航するところもあると思うので、1社目が決まる前の段階から、やはりCSチームを立ち上げる準備などは絶対すべきだと。「ここがやはり遅れることはいけないなあ」と思っています。
役割・責任が明確になっていない兼任は、個人の負荷増大だけでなく、「すげえがんばってるから言いづらい」ところもけっこうあるのかなと思っていて。いずれ組織内の対立も生んでしまって、組織文化が一気に壊れる可能性もあるんじゃないかなと思っています。
あと、開発文化がないままの機能別ユニット開発。先ほどお話ししたとおりの気合い文化だったので「とりあえずスピードだ」「機能GAPがあったらそこを2人で潰せ」みたいな。相互レビューもせず開発を行っていました。
今はもちろんレビュー体制もペアプロ体制も引いてはいますが、今考えると「本当に信じられないことをしてるなあ」と。実装方針のすり合わせ、コーディング規約、相互レビューの文化作りは、この時期からやはり手を入れていかなければいけなかったと思っています。
フェーズ2の体制と反省
フェーズ2ですね。シリーズAの資金調達もあり、顧客の増加・組織の拡大中です。このあたりで、調達に向けてというところもあり、チャーン率を下げるべく、開発体制を変更しました。フェーズ1の課題も改修しつつ、事業としてはチャーン率の低下を目指して行いました。
チャーンを下げるべく、課題発掘と解決企画を両者ともに担うかたちでCSがPMを兼任。このフェーズから人数が増え、役割ごとにチーム分割を行いました。
CSがPMを兼任することで、チャーンは非常に下がり、1パーセントを切れました。しかし、やはり顧客の言われたとおりに作ってないところは開発側から声が上がってきていました。CSチームもかなり精査はして、開発チームもタスクに対してかなり突き返すところはありましたが、やはり優先づけに一定の疑問があると。
一時的なチャーン低下のための解決策としては悪くなかったのではないかと思いつつ、期間としてかなり長くかかってしまい、結果組織編成を変えづらい傾向になってしまったところはあります。
2番目のほうがけっこう大きかったのですが、徐々に人が増え、チームを縦割りにしたことによって、組織全体として「このプロダクトはどこを目指してるの？」みたいな声が起きてきてしまいました。ここはCEOと同様に、やはりCTOとしてすごく「あ、ツラい」というころがありました。
もちろん常日頃やるべきだと思いますが、組織編成変えるっていうときは、あらためてこのあたりの認識をしっかり揃えていかないと、と思っています。
課題発見・解決というところです。今、CSとPMというところなんですが、解くべき課題の解像度を上げていくところ、課題解決、企画を分ける。
これはやはりどちらもすごく大変なことだと思っています。それぞれにリソースコストをすごく割くべきだと思っていて。かつ、企画に対しての優先順位づけも、別の部隊を作っていこうとなりました。
2番は先ほどの話のとおり、「このプロダクトがどこを目指してるのか」は、組織拡大のタイミングで、常々認識を合わせておく必要があると思っています。代表が全員を集めてプロダクトのコンセプトなどを話す機会を、この時期から入れるようになりました。
これからの体制変更・方針
最後にこれからです。これからのところはまさに現在取り組んでいるところです。4月は大型代理店の運用開始。5月頭より、さらなる事業拡大・組織拡大に向け、組織編成を変更しました。
事業責任者がPPといわれる、Product Planningチームの立ち上げを行いました。Product Planningの中でしっかり4人アサインしています。この4人もけっこうおもしろい経歴だと思っていて。保険業界出身のエンジニアや、データエンジニア、デザイナーなどが在籍し、クォーターのしっかり解くべき課題を精査しています。
機能開発のところも、今後SREやQAのところ、役割を変えつつ、分担しつつ、チームを立ち上げていきたいと思っています。
顧客の課題に向き合い解決するには整った体制が必要
最後、まとめです。顧客の課題に適切に向き合い解決するためには、体制が整っていることが必要です。「顧客の課題はなんだ」というところはずっと考えていますが、「それに向き合う体制できてんの？」みたいなところは、「最初は人数少ないしいいや」のようなところがあると思います。
ちょっと「うまく進んでないな」と思ったときには、組織、体制、そして根づいてる文化も見直す必要があるなと思っています。
体制の見直しはすごく大変。まだスタートアップ、20〜30人だから、みたいなところもあるかとは思いますが、まったくそんなことはないなと。20〜30人でも体制の見直しはすごく大変で、だからこそ定期的な振り返り、そして入念な準備を行って、体制の見直しをしていくべきだとこの2〜3年やって非常に反省しています。
本日はありがとうございました。
質疑応答
田仲紘典氏（以下、田仲）：ありがとうございました。質疑応答の時間をちょっと取っていきますか。フェーズ1に“気合い”という言葉がけっこう出ていたと思います。“気合い”は僕も好きですが、フェーズ1の段階で採用にあまりリソースは割きませんでしたか？
横塚：がんばってはいましたが、結局妥協できないというところと、CSのリーダーも時間がかかったものの、結局いいメンバーがジョインしてくれたとこともあって。がんばってはいましたが、やはり採用の意識は全社として低かったところはあると思います。
津田遼（以下、津田）：それこそスタートアップでアーリーステージいる人って、たぶんすごい気合いな人ばかりじゃないですか。
とはいえ、体制がしっかりしていないと無理なところもある。当時の自分にTipsを渡すとしたら、気合いでがんばろうとする自分に対して、どういうTipsを与えますか。「こういうタイミングになったら、体制もしっかり見ないとダメだよ」と。正直同じ場になると、僕も「気合いで」とか言っちゃうような気がしていて。
横塚：そうですね。とはいえ、すべて後手後手だったなと。僕もたぶんもともとが気合い型の人間なので、「とりあえずがんばる」みたいなところで。
やはり1社目の大型が決まるところが見える前には、確実にCSの採用に動いて、合わせにいくことは計画しておくべきだったなと。
これも意識づけの問題ですが、プロダクトロードマップは作っていても、そのプロタクトロードマップに対しての組織のロードマップをたぶん考えている時間が最初非常に少なくて。
セグメント分けて、そのセグメントに対してどんな課題があって、どんなソリューション出すかはすごく考えていても、その後、そのソリューション出す体制をずっと考えてるところはやはり最初取れてなかったなと思っていて。
もちろん、なんとなく人増やさなきゃいけない、採用しなきゃいけないというところは知ってはいましたが、解像度はあらためて低かったという反省はあります。
田仲：やはり課題が見えてきて、「ここに人を当てていくべき」とかがたぶん一番見えてくると思いますが、ちゃんと見ないと見えてこないところですよね。ちゃんと見返してみて、「やはり必要だったな」みたいなところで、採用に至る感じです。
あと、フェーズ1の時点でのその、たぶん縦割りカットだったときのコードってどんな感じだったのか説明できます？
横塚：ああー。そうですね、自分で言うのもなんですが、やはり縦割りになる前は、たぶん普通なんですよね。1人とか、2〜3人で書いてるのである程度統一感があって。汚いというより、コードの中に異文化が若干入ってしまっているような意味で、「かなりつらい」みたいなところです。
例えばフロントの部分では、この人数ですが、状態管理をどうするかの問題みたいなところ。でもそこも最悪、最終的に改修できたのでよかったのですが。やはりDBの設計思想みたいなところは、リプレイスしていくときにちょっと苦労しました。
中山太雅氏（以下、中山）：なんとなくわかります。要は、その異文化うんぬんみたいな話は、なんとなくそのアーキテクチャレベルで違うことやってる人たちがいるような話の気がしていて。
つまりそこって、“ガイドライン”と言ったらおかしいですが、図かサンプルコードかわかりませんが「だいたいこんなアーキテクチャでやります」みたいなものがあれば、だいぶ違ったのかな、というのをベースに持ってはいます。
そこからのプラスアルファの話でけっこう難しいなと思ってるのが、リーナスの『寛容な独裁者』でしたっけ。ちょっと忘れてしまいましたが、要はどこまでそれを押しつけるというか、どこまでそれを遵守させるかみたいな話があると思っていて。
レビューする人があまりに強烈にガンガン言いすぎると、要はエンジニアとしてのクリエーティビティが損なわれるような話も無きにしも非ずだと思っていて。そのあたりの温度感は難しいなと。なんの答えにもなっていませんが、難しいなと思っています。
田仲：なるほど。少し間を割ってしまいますが、質問がきているので。「フェーズ1に関して、最初から体制を十分に整えるのに、人件費をけっこうかけることになると思っていますが、それは許容していく意思決定が必要なのでしょうか。
その意思決定をするタイミングを聞きたいです。あとは、潜在的課題がうっすらと見えてきたタイミングで、スケジュールアウトを落とし込んでいくイメージでしょうか」と質問がきています。横塚さんどうですか。
横塚：ありがとうございます。言われたとおりで、なかなかこの意思決定難しいと思います。やはり前提としては、せっかく資金調達してるので、採用に早めに踏み込んで、リスクだろうと取って、どちらかというと専任のような体制を引いていかなければというところがあると思います。
とはいえ、最初兼任は仕方ない問題はあると思っていて。としたときに、兼任したときこそ、より選択と集中で、役割と責任の定義はさらに明確にするべきだと思っていて。
Sales兼CS兼PMという謎の体制ではありましたが、「もう2ヶ月はいったん、別にセールスしなくていい。」というところまでもう言い切っちゃってもいいとか。
結果、そういうことをやっていたほうが、選択と集中で早かったんじゃないかなと。5つ分かれると、結果、スイッチングコストで「ほとんど仕事してないみたいな」というのあったと思います。
田仲：大丈夫そうですね。ではそんな感じで横塚さん、発表ありがとうございました。
