SlackやGoogle Spread sheet、 Google driveといった既存ツールから、スケルトンSaaSを作りたい。（Part1）～コンサル時代の話
「Jinbaflowを使って何がしたいのか。」という話を、一歩実際の世界に近づけると、「スケルトンSaaS」みたいな言葉がぴったり来ます。
つまり、しっかりとした骨格を作ることが出来れば、見た目は、一旦置いておいたとしても、使えるものが出来るのではないか。
そっちの方が、結局みんながきっと使いたいものになるのではないか。
今回はから、このスケルトンSaaSいいじゃんとなった理由とスケルトンSaaSはどういう定義でどういうものにしていきたいかについて考えていきたいと思います。
(ぜひ、jinbaflowを登録して使ってみてください）
まずスケルトンSaaSは何か一応GPTに聞く
スケルトンアプリケーションとは、ソフトウェア開発の初期段階で使用される、最小限の構造と機能だけが実装されたアプリケーションのテンプレートや雛形のことを指します。このアプリケーションは、プロジェクトの基本的なフレームワークやディレクトリ構造、設定ファイルなどが含まれており、新しいプロジェクトを迅速に立ち上げるための土台となります。
「スケルトンSaaS」は一般的に広く使われる言葉ではありません。
「スケルトンアプリケーション」や「SaaSボイラープレート（SaaS Boilerplate）」といった表現のほうが一般的です。私が今回ちょっとだけ造語しました。ただ、きっとニュアンスはすごい伝わると思います。
こういうときは、ノリでChatGPT先生に解説してもらいましょう。
スケルトンSaaSの特徴
基本機能の提供: ユーザー認証、アカウント管理、サブスクリプション管理、支払い処理、APIの設定など、SaaSに共通する基本的な機能が実装されている。
カスタマイズ性: 開発者が特定のビジネスロジックやデザインを追加しやすいように、柔軟にカスタマイズできる構造になっている。
スケーラビリティ: 初期段階から将来的な拡張が考慮されており、必要に応じて機能を追加・変更していけるようなアーキテクチャを備えている。
クラウドインフラとの統合: クラウドサービス（AWS, Azure, GCPなど）と連携し、スケーラブルなデプロイメントと運用が可能になっている。
一旦、どんなものをやりたいか、説明いただいたので、ちょっと理由を書きます。これを実現したい原体験が3つあります。今回は1つ目を書きます。
スケルトンSaaSがいいなと思う理由 1つ目 コンサル時代の経験から
１．大企業をコンサルしていた時の話。
「結局そのシステム、エクセルでできるじゃん」となった話と、「その手作業、マクロでできるじゃん」となった話
「結局そのシステム、エクセルでできるじゃん」
大企業のDXの失敗
戦略コンサル時代のクライアントで、数億円から数十億円という値段を使ってITベンダーに発注していたシステムが、本当はエクセルと、ちょっとした簡易SaaSで代替できるんではとなったことがあります。こういう独自ツール失敗は、それはそれで一つの本が出来るくらいの難解さがあるかと思います。構造的には、ITコンサルは極めて優秀な一方で、彼ら自身のインセンティブの歪みやクライアント側のIT知識技術の欠如より変な方向に進んでしまいます。それ以上に、作るものの性質によってもこのおかしな失敗は生まれやすくなってしまいます。それは、「基幹システム以外の部分のＤＸ」というの命題を目指した時です。
「基幹システム以外の部分のＤＸ」はSaaSにしては？
基幹システムの入れ替えでも失敗してしまうことはもちろんありますが、例えばＳＡＰなどの有名どころを筆頭に、そのプロジェクトをやるプロが沢山います。一方で、基幹システム以外のＤＸはある意味でSaaSベンチャーみたいな開発にちょっと近いです。正解のUIがあるわけではなく、顧客の言葉をヒントに作り上げないといけない訳です。これ自体はすごく面白い仕事ではあるものの、前述の失敗の原因の加えて、毎回作るものが違い、クライアントも本当に欲しいものを最初から言語化できるわけではなく、何回かの失敗（ピボット）が起きないと本当に使いやすいものにならないという性質があります。まさにベンチャー向きです。これを巨大ＩＴコンサルが実行したらどうなるでしょうか。もちろんアジャイル開発に特化したチーム編成の場合はもちろん別ですし、初めから目的が明確です。ただ、大抵の場合はそうはなりません。はじめは、業務改革やりますと言って始まり、なんかＤＸできそうなところを普通のコンサルテーションで実行していくことになります。要は、普通のコンサルマネージャーと普通のコンサルタントがついて、大規模開発のように、開発チームのマネージャーが入り、その下に開発チームがいて、さらにその先にベトナムとかフィリピンとかのエンジニアがつきます。あ、もちろんこの上にディレクターがついています。こんなことをベンチャーでやったら死にます。確実に、変な資金調達の仕方をしない限り、終わります。なぜなら、毎日のように作るものディテールがどんどん変わって変更を行う意思決定をし、その場で修正します。これは、クライアントもそのつもりで意思決定できないと無理な話です。コーディングとは創造のはずです。いわれたものだけを作るという形にしたときに、プログラムの進化は鈍化します。
「その手作業、マクロでできるじゃん」となった話
一方で、そのオペレーションを手でやるんですか….となったことも沢山あります。ちょっとコードを書けばできるじゃないですか！という案件です。
上記の「基幹システム以外の部分のＤＸ」との大きな違いの一つは、そこまで大きくない工数の場合や、本筋のオペレーションではなく、「必要だけどちょっとしためんどい作業」と「ちょっとめんどくさいからスキップする分析」が多くの手作業を必要とするもの正体です。
でも、こういうところに重要なことがある。
「必要だけどちょっとしためんどい作業」と「ちょっとめんどくさいからスキップする分析」
「必要だけどちょっとしためんどい作業」に関する悪は、人の時間です。いわゆる単価の高いパソコンを使っているメンバーがある意味こういう付加価値の低いしごとを一生懸命やっています。これは、想像超えるほどに非効率です。現場がある仕事であれば、現場で汗を書いた方が結果的にお金を作れるかもしれません。もっともな悪は、こういう作業をしていることを正当化したくなる感覚です。つまり、これだけ大変な作業をしているのだからこれによって利益を生み出すことが出来るのだと考えたくなってしまいます。これは、特に一定程度に必要な業務を手作業でやっているときに発生しています。例えば、社員のアンケートを手作業で集計するとか。。。
さらに本当の問題は、「ちょっとめんどくさいからスキップする分析」です。百歩譲って、大企業なので一人が多少、付加価値の低い必要なオペレーションをしていたとしましょう。これは、必要なので良しとしましょう。
一方で、めんどくさい分析はどうでしょう。分析は、経営や事業の意思決定に大きな意味あいを生み出します。大企業は、でかいので、当たり前のように経営者や意思決定者は全体の本当の実態を知って意思決定するなどほとんど不可能です。では、なにが必要か、それは現場（顧客や従業員、競合）のリアルをとらえた情報と分析です。これらの分析は普通にめんどくさい。なぜなら、これは粒度の細かいく広範広がる情報を集め、そこから意味合いをださなくてはいけない作業だからです。（だからコンサルをやとうんだ！というのは置いといて）これらの作業をやるメンバーは大抵の場合、技術がなければ手作業になる多くの作業を考え、途中で、この分析は「出来ない」ので辞めますとなってしまいます。これは、大きな経済損失を生みます。
これは、具体例を出せばいくつでも出てきます。結局最もな重要な情報は社内にあったりします。なぜ、データがあるのに、コンサルなしで同じことが出来なかったのか、それは面倒だからです。よく、このクライアント内部の情報が一番重要という話を最初にクライアントに言うと、特にエリート意識の強い企業ほど「うちは、外の情報をできる限りもらうために雇ったんだ」とお話されます。ただ、多くの場合、2－3週間一緒に分析を進めるなかで、内部情報にものすごく重要な意思決定のカギがあったりします。
こういうときは、だいたいエクセル対応になる理由。
これはいくつかの理由があります。
クライアントがそもそも導入しているものを使いたい。
大規模な開発を必要とするほど価値がない。
新しいツールを導入するよりも、みんなが慣れ親しんでいる
また、新しいツールだと保守管理が面倒。（そもそも、新しいツールを作るとなると、上の分類の「開発」そのもですが。）
プログラミングの壁・SaaSの壁
また、これはエクセルの関数がめちゃめちゃできるで対応できる範囲であれば、大丈夫ですが、2か月1回くらい、あ、これはコーディングした方がいいなと思うものとぶち当たります。たとえば、複数のサービスに情報がまたがってします（含む、ウェブサイト）や、時間間隔を置いて継続的に行わなければない処理などです。
一方で、それらはSaaSで対応しきれない細かい調整が必要だったりします。
そして、すべては、IT部に大きく依存する
最後に、すべての会社がこうでないことも事実です。強いＩＴ部、これは、単に僕たちＩＴ分かっているからね。とやっているのではなく。
実際に手を動かし、考え、必要なら外部と即座に連携できるメンバーがいればこういう問題は起きません。ただこういうメンバーにあうのも実は非常に稀です。
まとめ
一つ目の僕の原体験についてでした。コンサル時代のことを書こうと思うとまだまだ止まらないので、また書かせていただきます。
大企業のDXの失敗の一例
- 実際にはエクセルや簡易SaaSで対応可能なシステムに、数億円単位の投資がされるケースがある
- 基幹システム以外のDXには、シンプルで実用的な解決策が必要。
手作業の無駄とその影響
- 自動化できる手作業に多くの時間と労力が費やされている。
- データ分析が手間になることで、企業が意思決定の質を高めるチャンスを逃している。
これらに対する打ち手が、スケルトンSaaSです。
今まで使っていたツールを自由に拡張することにより、基本業務や分析のテイラーメードが可能です。
次回、自分で作れる楽しさとスケルトンSaaSについて話ます。。。
長々と失礼しました。
Tak