BLOG
2023年05月23日
「世界に通用するスタートアップの育成」を目的に、2010年にスタートしたOpen Network Lab（以下「Onlab」）。14年目を迎えるOnlabの卒業生たちはさまざまな領域で活躍しています。今回のテーマは「権限委譲」です。創業者に始まり、経営陣が仲間になり、メンバーを採用し……と組織が大きくなる中で欠かせないマネジメント手法について深堀りします。
災害・リスク情報解析SaaS「Spectee（スペクティ）」を運営する、防災テックベンチャーでOnlab第11期の株式会社Spectee（以下「Spectee」) は2014年の創業。創業9年目となる現在も対応業種や顧客を増やしつつ、組織を成長させ、2023年4月には約120名のメンバーが働くスタートアップ企業に成長しています。その過程で、社長の村上さんは少しずつ権限委譲を意識してきましたが、必ずしも全てが上手くいったわけではありませんでした。「何より大事なのは組織DNAの浸透だと学んだ」と村上さんは語ります。そんなSpectee村上さんにスタートアップの権限委譲のポイントを伺いました。
＜ プロフィール ＞
株式会社 Spectee 代表取締役 CEO 村上 建治郎
ソニー子会社にてデジタルコンテンツの事業開発を担当。その後、米バイオテック企業にて日本向けマーケティングに従事、2007年から米IT企業シスコシステムズにてパートナー・ビジネス・ディベロップメントなどを経験。2011年に発生した東日本大震災で災害ボランティアを続ける中、被災地からの情報共有の脆弱性を実感し、被災地の情報をリアルタイムに伝える情報解析サービスの開発を目指し株式会社Specteeを創業。著書に「AI防災革命」(幻冬舎)
Contents
― 2014年に創業したSpecteeのサービスや組織について聞かせて下さい。サービスはどのような歴史を辿ってきたのでしょうか。
Specteeは、SNSや気象データ、カーナビ情報や道路カメラなどのデータから災害・リスク情報を解析し、被害状況の可視化や予測を行うサービスです。災害や事故などのリスク情報をリアルタイムに配信するほか、SNSや河川・道路カメラ、カーナビ情報、人工衛星等のデータをもとにAIで災害時の被害シミュレーションや予測をし、被害状況を可視化します。
Specteeは当初、報道機関でご利用いただくことが多かったのですが、最近は公共エリアの防災を担う官公庁や自治体、また、電力、ガス、鉄道といったインフラ系の企業でのご利用も多くなってきました。
インフラ関連の事例では、現在イオングループでSpecteeをご利用いただいています。災害が発生した際、店舗やその周辺の被災状況を確認するためです。もし店舗が被災すると、食品や日用品の流通が滞り、周辺住民が困ってしまいますからね。場合によっては周辺住民に災害時に水を配るといった役割もありますし、そういった意味でもスーパーはインフラと言えるでしょう。また店舗は大丈夫だったとしても、配送センターや物流経路にダメージがあって、店舗に品物が届かなくなってしまうかもしれない。いずれにせよ、そういった被害状況を最速で可視化するためにSpecteeを導入いただいています。
― 地震などの災害は頻繁にあるものでもありません。万が一の時のためにSpecteeが導入されているということでしょうか。
もちろん万が一の場面でもSpecteeは力を発揮します。しかしイオンですと全国に1.5万店舗もあるので、豪雨や積雪といったレベルの天災は毎日のようにどこかで起きているんです。そういった事象が店舗や経営にどのような影響を及ぼすか、それを調べるために日常的にSpecteeが使われています。
― メディア、インフラと来て、次はどういった市場でSpecteeの導入が進んでいますか？
現在注力しているのは、製造業や物流企業での、サプライチェーンのリスク管理での利用です。何か事故や災害が起きたときに、製造業だったら、当然自社工場への影響を把握しなければなりませんよね。とはいえ、自社工場に被害がないから大丈夫というわけでもないんです。なぜなら製品をつくるための部品や材料などの調達先（サプライヤー）が影響を受けているかもしれないから。ネジ1本でも調達できなくなったら、それだけでも製造が止まってしまうかもしれない。そのため、何かが発生したときに、サプライチェーン上にどんな影響があるかを直ちに把握することは、製造業や物流業にとっては非常に重要なことなんです。
そこでSpecteeには「サプライヤー登録」という、部品等を調達している取引先を登録できる機能をつけました。取引先を登録すると、その取引先の拠点の周辺や途中の物流網で何か被害があった際に、アラートが出たり、その取引先への影響具合がわかるという機能です。その取引先の今の状況はどうなっているのか、納期にはどの程度影響がありそうか、といったことを把握できます。この機能はまさに製造業の方から「こういう機能が欲しい」と要望をいただいて開発・強化してきた機能です。
― 最近だと半導体が仕入れられなくて、製造業各社に影響がありました。それに国内だと地震や水害のリスクは無視できません。
まさにそういったケースでの利用を想定しています。例えば昨年、国内で大きな地震があった際、ある自動車メーカーのサプライヤーの工場が止まってしまったというようなことがありました。影響のあった各社は代替品を提供できるサプライヤーを探したのですが、あるメーカーはその動きに乗り遅れ、代替品を入手できなかったそうです。そういった事態にSpecteeを活用することで、もっと早く立ち回れた可能性があります。こういったリスクを回避するために、サプライチェーン管理の一貫としてSpecteeの導入が進んでいます。
また国内では水害も少なくありません。そこでその対策として、水害が発生したときにリアルタイムに浸水深と浸水範囲を予測推定できる「リアルタイム浸水推定」の機能もリリースしました。例えば、会社の工場がある地域で豪雨で冠水している家があるという情報がSNSにあったとします。その際に知りたい情報は、工場に浸水等の影響があるかどうかです。そこでSNSにある写真を画像解析して浸水の深さを推定します。また、その地域の標高データや周辺の降水量のデータを組み合わせて浸水範囲をリアルタイムに推定することで、工場への影響を予測します。その結果をSpecteeのユーザーに必要に応じてアラートする。これが「リアルタイム浸水推定」機能です。この機能も非常に好評いただいています。
― 報道機関向けのSaaSだったものが、この数年でインフラ、サプライチェーン管理、店舗の被災管理など、どんどん進化していますね。この進化はもともと構想していたのでしょうか。
いえいえ、それこそOnlabにいた時は全くこんなこと考えていませんでしたよ（笑）。
構想したいたわけではなく、Specteeがさまざまなお客様に使っていただけるようになって、そこからニーズを汲み取って、サービス開発して……この繰り返しで進化してきました。
― Specteeが成長していく中で、クライアントの業種が多様化し、それにともなって組織が大きくなっていったかと思います。その過程で権限委譲の必要性が出てくると思いますが、どのような方針を立てていますか？
正直に言って、自分自身、Specteeの権限委譲が上手くできているとは思っていないんですよね（笑）。
権限委譲を考えるための前提として、まず部門責任者のことを考えなくてはいけません。権限を移譲しようにも、そもそも移譲する人が適切でないといけませんからね。とはいえ、どこのスタートアップも同じだと思いますが、これがまた難しい。Specteeの経験では例えば、過去に部門責任者を採用してすぐに部門責任者を任せたことがあったのですが、これはあまり上手くいきませんでした。かといって、急激に成長する過程でメンバーに加わってきた人たちが、必ずしもマネージャーの経験があるわけではありません。それはそれでいきなり部門責任者を任せるわけにはいかないわけです。
色々と試行錯誤した末、今は「Specteeのことをしっかり理解している人に責任者になってもらう」ようにしています。今いるメンバーに経験を積んでもらって責任者になってもらうパターンもありますし、将来的にそのポジションに就いてほしいと思っている方を採用して、1年後くらいに責任者に就任してもらうという形を採っています。
― 他のスタートアップの話を聞いても、ある程度会社に馴染んでから就任というパターンは多い気がします。
そうですよね。私も社内のメンバーが認めてから昇格するのがいいと感じています。ただこれはこれで難しい点もあって、それなりの方を採用しようと思ったら、ある程度ポジションを約束しないと採用できないケースも多いんです。とはいえ、すぐに部門責任者にしてしまっても前述のように上手く回らないリスクが高い。ここはジレンマですね。
― 部門責任者が決まったら権限移譲を考えます。そこからの権限委譲の難しさはどんなところにあるのでしょうか。
スタートアップはメンバー全員が一願となって、ビジョンやミッションに向かっていかなければなりません。これは絶対です。なので権限委譲によってそこが少しでもブレてしまってはいけません。部門責任者はあくまでその部門の責任者であり、会社全体を見ているわけではない。結果を出そうとするのはもちろん大事なのですが、それがSpecteeの方向性とぶれてはいけないのです。
営業だったら、自分たちだけでなくお客様にもSpecteeの哲学を伝えていかないと、数字を追いかけるだけの組織になってしまう。開発部門が哲学を理解していないと、単に仕様をコーディングするだけになってしまう。ちょっと方向性がブレているときに、いかにSpecteeのDNAをもって修正できる体制を整えるか。権限委譲を考えるにあたっては、非常に難しいけれどこれらに対処しなくてはならないことだと考えています。
― 組織のDNAを伝えていくために、どのような施策を打っていますか？
例えばSpecteeでは、プロダクトのコンセプトミーティングを頻繁に開催するようにしました。
先述したようにSpecteeはこれまで、お客様の声を聞いて、それをプロダクトに反映してきました。そのお客様の声を全社的に共有するための「VOC（Voice Of Customer：顧客の声）ミーティング」を、昔は頻繁に開いていたんですが、組織が大きくなったり、営業が忙しくなったり、お客さまの数が増えたりで、一時期その頻度が少なくなっていました。そうすると当然、組織に「お客様の声」という共通認識がなくなっていき、同時に組織の行動が「Specteeっぽくない」と感じることが増えていたんです。
― 組織のDNAのズレといった課題はいつごろ出てきたのでしょうか。
Specteeの場合は組織が80人くらいのときから感じ始めました。部門が分かれていても部門間で意思疎通できていた時代は大丈夫だったのですが、80人を超えたあたりそれが難しくなってたんです。
これではいけないということで、プロダクトのコンセプトミーティングを再開しました。さすがに以前やっていた「VoCミーティング」のように細かいことまでは共有できませんし、人数も多いと全員が参加するわけにもいきませんが、「今後プロダクトはこうしていく」といった方針を、少なくとも部門長クラスには浸透させることを目的として定期的な会議を開いています。それを受けて各部門がどうするかは任せていますが、これによりプロダクトや会社の方向性が、会社のDNAとズレるようなことは減ってきました。
まとめると、権限委譲するにしても、それによって会社として取るべき行動と、実際の行動がズレないように意識し、対策を練ることが重要だと思います。
― 権限委譲すると、今まで直接自分が得ていた情報をリアルタイムで把握しづらくなるのではないかと思うのですが、この点はどう考えていますか？
権限委譲自体はどんどんしていかなくてはならないと思っているのですが、それによって社長である私が現場の状況を把握できなくなってしまうのもよくないと考えています。例えば「お客様がこんなことを言っている」と営業メンバーから聞くだけではダメなこともあって、必要なら営業にも私が同行するし、会議にも参加する。もちろん営業だけでなく、開発にもオペレーションにも入って、状況は把握できるようにはしています。
― 村上さんが現場や会議に出ることで、村上さんの意見が強くなってしまう側面はないでしょうか。
ちょっと方向性がズレてるなと思った場合は口を挟みますが、そもそもみんなでしっかり議論して話が進んでいるなら、あまり発言しないようにはしています。なるべく方向性や、やるべきことを示した上で、細かいことはチームに任せる方針でいますが、自分が変に影響させてしまいそうだから現場や会議に出ないという意思決定はあまりないですね。むしろ僕はかなり色々なミーティングに出ているほうだと思います。みんながそれをどう思っているかはわかりませんが（笑）。なんにせよ、自分がやれない範囲まで口を挟むのは良くないと思っています。
― やれない範囲とはどのような意味でしょうか。
能力だったり経験だったりで、僕ができないことです。例えば僕は技術者ではないし経理の専門家でもないので、その分野の細かいこと専門ではないので、口を出しません。逆に言うと、口出しするのは自分が責任をもって対応できることです。口だけ出して責任を取らないのはよくないですからね。「何かよくわかんないけど社長がこう言うから」と組織がなるのはよくありません。普段は何も見ていないのに、ふらっとミーティングだけ出てきて、好き勝手言って終わるのはやらないと言い換えてもいいかもしれません。
例えばマーケティングチームがセミナーを開催するとします。マーケティング施策そのものに関してはそんなに口出ししませんし、やりたいこと、ベストだと思う施策をどんどん進めてもらって問題ありません。ただ最後に責任を取るのは当然社長の私なので、その範囲でおかしなことがないかは確認している、というイメージです。
― これから権限委譲を実践していこうとするスタートアップは、どんな点に気をつければよいでしょうか。
権限委譲できていないと言っている僕がアドバイスしていいのかわかりませんが……（笑）。
繰り返しになりますが、権限委譲に際しては、どこまで自分で対応して、どこから人に任せるのかを明確に分けることが重要だと僕は考えています。必要なことは自分で把握できるようにすることも同様に大事です。
私を例にするなら、（エンジニアではないので）技術に関してはほとんど任せているけど、営業は自分で見る範囲を広げています。といっても、全てのお客様にお会いできるわけではないので、営業責任者にSpecteeのDNAを注入しつつ、バトンタッチする。そして任せたからには、社長である私が当然、最終的に責任を取る。
権限委譲のタイミングとしては、これも先述しましたが、Specteeは80人程度のときに組織内のコミュニケーションに、確かに壁を感じました。といっても、このコミュニケーションの壁はどのスタートアップにもあるようで、ただそれが80人のときとは限りません。でも一つの目安として、「コミュニケーションが取れなくなってきた」ら、権限委譲を検討するいいタイミングなんじゃないかと思います。
周りのスタートアップをみても、いきなり権限委譲して成功した会社は見たことがありません。自社なりの在り方を考えながら、少しずつトライアンドエラーをしていくしかないと思います。
と色々と語らせていただきましたが、私も今また壁を感じているところで、Specteeも次の権限委譲が必要だと感じています。マネージャーも育ってきているので、早く彼らに活躍してもらうためにも、権限委譲していかなくてはならないですね。
― 村上さん、本日はありがとうございました。
（執筆：pilot boat 納富 隼平 撮影：taisho 編集：Onlab事務局）
ENGLISH
