Civichat撤退にあたり
>日本中の官僚が頭を絞って作って書いて公開された制度を俺一人で人間にわかりやすいように書く仕事。全くスケールしなくて辛い。しかもこれをアルゴリズム様が解釈しやすいように符号を振る作業もある…
> うーんなんか次やる時は、ちゃんとボトルネックがどこにあるのかみたいなのを考えとかないと全然ハマるな。それこそRule as Code的な感じで中央からやらないと意味ないし、それでも取り扱う範囲が広いと破綻する。
>MVPって”直近は手でやるけどゆくゆくはそこも含めて自動化します”みたいな感じではあるが…その自動化に目処がついていない（or 10年後とか）だと非常につらい。
>このプロダクト作り的なところで初手でミスってたのもあるし、ドメイン的な話でいうと「制度の情報は頻繁に更新される」「制度の発行元自体が利用数を増やすインセンティブがない」なおかつ、「デジタル化が進んでいない」という三重苦…それ以外にもたくさん事業上でミスしたけどこんなところかな
事業構造の問題
1 だけであればUbieが解決しているように思える（対話によって認知できていないことを認知する） が、Civichatの場合はドメイン的な課題もいくつかあった。全部重なったことでうまくいかなかったと認識している。アグリゲーション部分で抽象化出来たことがコアであり、ここをソフトウェアによって代替出来ていたのが成功要因だったと考える。Civichatでいう「餅から米を作る」の部分をうまく解決した。
抽象化すれば、「コンサルティングの要素が大きいもので最初に受託から入り、そこでのニーズを拾い上げ、抽象化してBtoB SaaSとして落とし込む」のが王道だった
GoodpathのSaaSも、LayerX インボイスもそう開発された
1. そもそも形式論理の記述がスケールしない
形式論理によって知識を構造化するのは、 #餅から米を作る 行為
Rule as Codeのような、論理のシステムを標準化しないことには出来ない
2. エンドユーザーである市民と、サービス提供者の自治体の2者間に挟まる形での事業
アライアンスを組み、パートナーとして価値を提供する必要があった
toCのプロダクトの方はPDCAが回っていて数字も伸びていたが、そっちにもピボットしきれなかった
>
>
3. 制度の情報自体は頻繁に変更される（+フォーマットは自治体でバラバラ）
公開した情報を継続的に管理するという点は自治体が最も苦手なものの一部ではあった
そもそもアーキテクトが弱いという点は常に大きな問題だった、負債の量が桁違い。
CPSVという制度のフォーマットを統一化する流れは日本でも進められているが、まだまだ地方自治体となると対応していない
「制度を一括で管理できるCivichatポータル」（BtoG SaaS）として進めていたが、顧客はこの問題に痛みを感じていなかった
4. 公共制度を利用されること自体に、制度の発行側（自治体）はインセンティブがない
自治体の職員は課題を解決したいわけではなく、すぐに帰りたい・楽にしたいだけなので
5. 全体的に官僚気質で、DXへの焦りがない
行政DXと言われる昨今だが、やるのは学生向けにピッチイベント。おわり。
経営者としての問題
下記以外はだいぶ頑張ったと思うが、上の事業構造の問題と合わせて現状の結果になってしまった
器用貧乏さとの戦い
今後の選択肢として修行、優秀なPdMの下で働いて推進力を付ける
共同創業者の経営能力がない
従業員の前職へのリファレンスチェック
権限委譲とのバランス
会計を任せていたらお金がなくなっていた、
任せたのが悪かったが、これによってオフィス2つ（40万円/月）や家具・セキュリティ等で150万円ほど無駄にした
中には一回も座られていないような椅子もあった（これらはフツパーに譲りました）
できることならもっと早くから投資家とコミュニケーションを常に取っておくべきだった
残ったもの
失ったもの（使ったもの）は時間ぐらいしかない。もう二度と繰り返したくはないけど、やったことに後悔はない。
ネットワーク
ソーシャルキャピタル（言い換えると、インターネットタトゥーも）
スキル的な学び
防窮訓練プロジェクト
起業失敗をどう活かせるか
これを公開する
>
>・やるなら賢くやってくれ
> ・せめてデータ出してくれ
> ・福祉を縮小して民間に任せる（小さな政府）なら民間に金出せ
> という…
今後どうするか
>
raw title: Civichat撤退にあたり
original page: /tkgshn-private/Civichat撤退にあたり