自社プロダクト開発
OUR OWN
PRODUCT
just build it
- トップ
- 自社プロダクト開発
概要

足りなければ、作ります。
既存のサービスを紹介するだけの会社ではありません。現場に必要なものが世の中に無いなら、自分たちで開発します。
実際に、サロン向けのSaaSを自社で開発・運営しています。作る側に立っているからこそ、「これは仕組みで解決できる」「これは運用で回したほうが早い」の判断ができます。
開発しているもの
開発しているもの
-
01自社SaaS・業務システム
勤怠管理、予約管理、マッチングの仕組みなど。業務に合わせて設計から行います。
-
02電子カルテ
クリニック・サロンの施術記録を、現場が使い続けられる形で。
-
03かしこみ
サロン向けの回数券・カルテ管理サービス。LINEから使える形で開発しています。
こういうものを作っています
大規模な基幹システムよりも、現場の人が毎日触る道具を作ることが多いです。
- 予約・顧客管理の仕組み(LINE連携を含む)
- 施術記録・カルテの電子化
- 回数券・サブスクリプションの残数管理
- 社内の勤怠・シフト管理
- 複数店舗の設定を一括で揃える管理ツール
- 既存サービスのAPI連携、データの自動取り込み
- 業務の一部を自動化する小さなツール
「わざわざ作るほどのことか」と思われるような小さいものでも構いません。毎日15分かかっている作業は、年間で60時間を超えます。
Build
世の中に無いなら、作ればいい。
作る側に立っているから、判断できます。
自社プロダクト
「かしこみ」で解こうとしていること
サロンの回数券は、紙の台紙かExcelで管理されていることがまだ多いのが実情です。紙は無くなり、Excelは誰かひとりのパソコンの中にあります。お客様に「あと何回残っていますか」と聞かれて、すぐ答えられない。この状態を無くしたい、というのが出発点でした。
お客様側はLINEから残回数を確認できます。店舗側は、施術の記録と回数券を同じ画面で扱えます。よく使う項目が入った状態で始められるため、導入時に項目をゼロから考える必要がありません。
作りながら気づいたのは、現場が求めていたのは高機能さではなく、忙しい時間帯でも迷わず触れることだったという点です。設定用語を画面に出さない、入力の手数を減らす。そういう細かい部分を、現場の声を聞きながら直し続けています。
現在も開発を継続しています。導入のご相談、先行してのお試しについてはお問い合わせください。
作るべきか、既存サービスで足りるか
私たちは開発会社ですが、作らないほうがいいと判断したらそう言います。自社で作ると、最初の費用だけでなく、その後ずっと直し続ける責任がついてくるからです。
| 項目 | 既存サービスを使う | 自社で開発する |
|---|---|---|
| 向いている場合 | やりたいことが一般的な業務で、業務のほうをサービスに合わせられる場合。 | 業務のやり方そのものが強みで、既存サービスに合わせると会社らしさが消えてしまう場合。 |
| 立ち上がり | 早く始められ、安定して動きます。 | 設計から始めるため、時間がかかります。 |
| 費用のかかり方 | 月額で安定します。 | 初期費用に加え、その後も直し続ける費用がかかります。 |
| 弊社の関わり方 | 選定と初期設定のお手伝いを行います。 | 設計・実装から公開後の保守まで担当します。 |
受託開発
受託開発も承ります
自社プロダクトの開発で使っている体制を、そのまま受託開発にも使えます。デザイナーとプログラマーが社内にいるため、企画から実装まで一貫して担当できます。
「こういうものが作れないか」という相談の段階からお声がけください。
受託開発の進め方
「こういうものが作れないか」という段階からご相談いただけます。仕様が固まっていなくても構いません。むしろ、固める前に一度話したほうが安く済むことが多いです。
- 困っていることを聞く作りたいものではなく、困っていることから伺います。話しているうちに、作らなくても解決する場合もあります。
- 作る範囲を決める最初から全部を作りません。いちばん困っているところだけを切り出して、小さく動くものを先に作ります。
- 画面を先に見せる文章の仕様書だけで進めると、できあがってから認識のずれが見つかります。触れる画面を早い段階でお見せします。
- 開発実装とテストを進めます。動くものを段階的にご確認いただきながら進めます。
- 現場で試す実際の業務で使っていただき、詰まったところを直します。ここを省くと、使われないシステムになります。
- 運用と改修公開後の保守、機能追加に継続して対応します。
よくあるご質問
- 仕様が決まっていませんが、相談できますか。
- その段階でご相談いただくほうが良い結果になります。決まった仕様を渡されて作るより、何に困っているかを聞いてから設計したほうが、無駄な機能を作らずに済みます。
- 小さいツールでも依頼できますか。
- できます。実際、数日で作れる小さなツールのほうが費用対効果は高いことが多いです。まず小さく作って、効果を確認してから広げる進め方をお勧めしています。
- 作った後の保守はどうなりますか。
- 継続して担当できます。OSやライブラリの更新、障害対応、機能追加まで含めた保守をご相談のうえで設計します。作りっぱなしにはしません。
- 既存システムとの連携は可能ですか。
- APIが公開されていれば可能です。公開されていない場合も、CSVの受け渡しなど別の方法で連携できることがあります。まず現行システムの仕様を確認させてください。
- デザインも含めてお願いできますか。
- できます。デザイナーとプログラマーが社内にいるため、画面設計から実装まで一貫して担当します。業務システムは見た目を後回しにされがちですが、毎日触るものほど使いやすさが効きます。
