自社プロダクト開発

OUR OWN

PRODUCT

just build it

  1. トップ
  2. 自社プロダクト開発
Overview

概要

現場に必要なものを作る

足りなければ、作ります。

既存のサービスを紹介するだけの会社ではありません。現場に必要なものが世の中に無いなら、自分たちで開発します。

実際に、サロン向けのSaaSを自社で開発・運営しています。作る側に立っているからこそ、「これは仕組みで解決できる」「これは運用で回したほうが早い」の判断ができます。

Service

開発しているもの

開発しているもの

  1. 01自社SaaS・業務システム

    勤怠管理、予約管理、マッチングの仕組みなど。業務に合わせて設計から行います。

  2. 02電子カルテ

    クリニック・サロンの施術記録を、現場が使い続けられる形で。

  3. 03かしこみ

    サロン向けの回数券・カルテ管理サービス。LINEから使える形で開発しています。

こういうものを作っています

大規模な基幹システムよりも、現場の人が毎日触る道具を作ることが多いです。

  • 予約・顧客管理の仕組み(LINE連携を含む)
  • 施術記録・カルテの電子化
  • 回数券・サブスクリプションの残数管理
  • 社内の勤怠・シフト管理
  • 複数店舗の設定を一括で揃える管理ツール
  • 既存サービスのAPI連携、データの自動取り込み
  • 業務の一部を自動化する小さなツール

「わざわざ作るほどのことか」と思われるような小さいものでも構いません。毎日15分かかっている作業は、年間で60時間を超えます。

Build

世の中に無いなら、作ればいい。
作る側に立っているから、判断できます。

Kashikomi

自社プロダクト

「かしこみ」で解こうとしていること

サロンの回数券は、紙の台紙かExcelで管理されていることがまだ多いのが実情です。紙は無くなり、Excelは誰かひとりのパソコンの中にあります。お客様に「あと何回残っていますか」と聞かれて、すぐ答えられない。この状態を無くしたい、というのが出発点でした。

お客様側はLINEから残回数を確認できます。店舗側は、施術の記録と回数券を同じ画面で扱えます。よく使う項目が入った状態で始められるため、導入時に項目をゼロから考える必要がありません。

作りながら気づいたのは、現場が求めていたのは高機能さではなく、忙しい時間帯でも迷わず触れることだったという点です。設定用語を画面に出さない、入力の手数を減らす。そういう細かい部分を、現場の声を聞きながら直し続けています。

現在も開発を継続しています。導入のご相談、先行してのお試しについてはお問い合わせください。

作るべきか、既存サービスで足りるか

私たちは開発会社ですが、作らないほうがいいと判断したらそう言います。自社で作ると、最初の費用だけでなく、その後ずっと直し続ける責任がついてくるからです。

項目既存サービスを使う自社で開発する
向いている場合やりたいことが一般的な業務で、業務のほうをサービスに合わせられる場合。業務のやり方そのものが強みで、既存サービスに合わせると会社らしさが消えてしまう場合。
立ち上がり早く始められ、安定して動きます。設計から始めるため、時間がかかります。
費用のかかり方月額で安定します。初期費用に加え、その後も直し続ける費用がかかります。
弊社の関わり方選定と初期設定のお手伝いを行います。設計・実装から公開後の保守まで担当します。
Flow

受託開発

受託開発も承ります

自社プロダクトの開発で使っている体制を、そのまま受託開発にも使えます。デザイナーとプログラマーが社内にいるため、企画から実装まで一貫して担当できます。

「こういうものが作れないか」という相談の段階からお声がけください。

受託開発の進め方

「こういうものが作れないか」という段階からご相談いただけます。仕様が固まっていなくても構いません。むしろ、固める前に一度話したほうが安く済むことが多いです。

  1. 困っていることを聞く作りたいものではなく、困っていることから伺います。話しているうちに、作らなくても解決する場合もあります。
  2. 作る範囲を決める最初から全部を作りません。いちばん困っているところだけを切り出して、小さく動くものを先に作ります。
  3. 画面を先に見せる文章の仕様書だけで進めると、できあがってから認識のずれが見つかります。触れる画面を早い段階でお見せします。
  4. 開発実装とテストを進めます。動くものを段階的にご確認いただきながら進めます。
  5. 現場で試す実際の業務で使っていただき、詰まったところを直します。ここを省くと、使われないシステムになります。
  6. 運用と改修公開後の保守、機能追加に継続して対応します。
FAQ

よくあるご質問

仕様が決まっていませんが、相談できますか。
その段階でご相談いただくほうが良い結果になります。決まった仕様を渡されて作るより、何に困っているかを聞いてから設計したほうが、無駄な機能を作らずに済みます。
小さいツールでも依頼できますか。
できます。実際、数日で作れる小さなツールのほうが費用対効果は高いことが多いです。まず小さく作って、効果を確認してから広げる進め方をお勧めしています。
作った後の保守はどうなりますか。
継続して担当できます。OSやライブラリの更新、障害対応、機能追加まで含めた保守をご相談のうえで設計します。作りっぱなしにはしません。
既存システムとの連携は可能ですか。
APIが公開されていれば可能です。公開されていない場合も、CSVの受け渡しなど別の方法で連携できることがあります。まず現行システムの仕様を確認させてください。
デザインも含めてお願いできますか。
できます。デザイナーとプログラマーが社内にいるため、画面設計から実装まで一貫して担当します。業務システムは見た目を後回しにされがちですが、毎日触るものほど使いやすさが効きます。