障害対応管理ール「Reactio」というSaaSサービスを起案からローンチし運営していて気づいたことを、ランキング形式でお伝えしていきます。（そのランキングの統計的数字ってどうなのよ？って疑問を抱くかと思いますがローンチしてまだ7ヶ月くらいのツールで、まだまだ胸を張れるような母数ではないのでナイショですw）
簡単に自己紹介（ここは気兼ねなく読み飛ばしてOK）
Gaiaxには2007年に入社して、7年半に渡って社内インフラと自社サービス向けインフラと、受託開発系インフラ、要はインフラっぽいところすべて担当してました。今は、その7年半ずっと障害対応をしてきてその課題を解決するために開発したツールを、社内スタートアップとしてSaaSサービスの運営に取り組んでいます。
趣味は、ゲームとバイクと写真（カメラ）と、障害対応です。
「Reactio」を導入した理由TOP3
スタートアップの初動は、本当にイノベーター理論における「イノベーター」と「アーリーアダプタ」からしか反応がない。さらに課題や価値に共感してもらえると人（組織）にしか利用してもらえないんですよね。
その限られた母数の中で、共感して頂いて導入した理由のTOP3です。
- まさにこれが欲しかったですね
- 最初は自社の課題を解決するために特化して開発したのをサービス化する上で最低限必要な箇所を改修して提供していただけあって、同じ課題をお持ちの企業は、「こういうの作ろうと思ってましたよ〜」と言っていただくことが多いです。
- 電話で通知くれるのいいですね
- 障害対応で監視ツールの通知に気づかない（気づけない）問題は多くて、「たまに気づけないですね！ハハハ！」でなんとかなるところと、「確実に検知と対応するために24時間/365日体制の部門あります！」の大企業の中間の組織がご利用頂いてます。
- PagerDutyとかを利用しているところも多いようですが、日本語で利用できないのとコストがそれなりに高いので導入しないところが、「Reactio」をご選択してるように見受けられます。
- 障害対応の蓄積を最適化したいですね
- RedmineなどのBTSのチケットや、各種情報管理ツールのWikiとかに蓄積してたけど、もっとちゃんと蓄積していかないと意味ないなぁと感じているところが、導入して頂いています。
スタートアップ初期で「アーリーマジョリティ」にいくら営業をかけても、箸にも棒にもかからないんです。なので、そのアーリーアダプタ層のチャネルを見つけるためのマーケティングが重要だし、それがまた難しいところでもあります。
SaaSサービスだからNGな理由TOP3
WEB系の企業にいると、「Qiita」や「Github」とか「Backlog」とか「Mackerel」など価値が高くコストが低いSaaSサービスを使うのが当たり前感覚になってしまっていました。
でもそれは全然マジョリティじゃないんですよね。むしろ社会全体でいえばマイノリティなのかもしれません。なので、SaaSサービスだからって断れれるケースもあり、その理由をご紹介。
- 情報管理の問題
- 組織内のインフラかプライベートクラウドにしか、情報を記録してはいけないっていうルールがある場合には絶対に無理です。妥協点を探すと必ずインストール型のツールならとお声かけ頂きますが、メンテが行き届かずにご迷惑おかけするので丁重にお断りさせて頂いております。
- 知名度の問題
- 「SalesForce」とか、大企業の◯◯さんも使ってるとか実績がないと、到底無理っとバッサリ切り捨てられることもしばしばあります。それこそ「レイトマジョリティ」なので、スタートアップの初期段階では無理な話ですね。
- Microsoftの問題
- Microsoft（以下、MSと省略）のActiveDirectory（以下、ADと省略）環境を活用したソリューションをどっぷり導入されている企業は、まずMSで似たようなツールがあればそれを使う。なければAD連携していないとアカウント管理できないので無理ですと言われてしまいます。
- そういう組織は大抵大きめの企業がほとんどなので、契約してもらえると数千人規模の導入だし「じゃあ、AD連携しちゃえばいいかも！」と、ついつい思ってしまいがちです。しかしAD連携しても導入する確証もなければ、そもそも導入検討自体に非常に時間がかかるので、気軽に判断できないと考えています。
ついつい組織の知名度や数に囚われてしまいサービスやプロダクトの本質から外れてしまうことがあります。大抵そういう時は、チームメンバーからの疑問や指摘で気づかされることが多いですね。感謝です。
「Reactio」が共感されないときTOP3
偉人たちや先輩には気にするなと言われるが、スタートアップの時ほど課題や価値に共感されないと辛いし不安になってしまうことが多々あります。共感されない事実を受け止めなくても良いケースの見極めてから、私は平気になりました。その受け止めなくても良いケースのTOP3です。
- そもそもシステム運用保守担当者じゃないとき
- 提案したい企業がいて同僚や知り合いから紹介してもらうケースだとたまにあるのですが、仮説を立てたペルソナと離れていると「面白いですね！」とは言われても紹介しておきますね！で、終わってしまいます。
- 本当にただお付き合いでお話しを聞いていただくだけになってしまうので、最近は「◯◯社の人と会えるぞ！」と浮かれてしまわないように気をつけてます。（各方面でご迷惑おかけしました！）
- メインのサービスやプロジェクトがひとつのとき
- 単一サービスで大成功している組織の場合には、環境をそのサービスに最適化しやすいのがとても特徴的です。
- 「Reactio」のようなスタートアップとして取組んでいる課題や提供している価値は、サービスに合わせて組織や環境で最適化されてしまっているケースが多いです。逆に詳しくヒアリングさせてもらえた時の学びは大きいです。
- スタートアップな組織のとき
- まだ組織の人数が少ない場合には、小回りが利くのでシステム運用開発もダイナミックなケースが多く、事業のコア以外は本当に必要最低限にしておくことが多いのが特徴です。
- 意思の疎通も図りやすく連絡体制や情報の蓄積が散漫にならないので、「いずれ必要になりそうですね。」で言われますが、スタートアップこそSaaSサービスを利用して楽することが必要だと感じるので、感慨深いです。
簡単ではありますが、スタートアップとして取組んでる中での気づきをご紹介させて頂きました。もちろんサービスやプロダクトによって、ケースは様々なので参考になるもかわからないですが、すこしでも読み物として興味を持って頂けていたら幸いです！