PRODUCT使われるものを、最短でつくる。
要件を固めきる前に、動くものを一度出します。画面を触ってはじめて出てくる「これじゃない」を、紙の上ではなく実物で拾うためです。
- 業務アプリ
- モバイルアプリ
- PoC・試作
- 既存システムとの接続
Kagaryについて提案する人と、
提案する人と、
つくる人を分けない。
立派な提案書は出てきたが、実装は別の会社だった。 DXが途中で止まる理由の多くはここにあります。設計した意図は引き継ぎのたびに薄まり、 動くものが出てくる頃には、最初の課題からずれている。
Kagaryでは、話を聞いた人がそのまま手を動かします。仕様を文書で受け渡す工程がないぶん、試すまでが速く、外れたときの引き返しも早くなります。
もうひとつ決めているのは、まず捨てないことです。 いま動いている仕組みには、書かれていない事情が必ず埋まっています。 すべてを作り直す前に、何が効いているのかを見に行きます。
事業領域
入口が三つ、行き先はひとつ。
EXPERIENCE効率の前に、体験を見る。
手数を減らしただけの改善は、たいてい元に戻ります。誰がどこで詰まっているのかを先に見て、業務と接点の両方を組み直します。
- 顧客・従業員体験の可視化
- 業務フローの再設計
- 接点の設計
- 定着の伴走
CONSULTING構想で、終わらせない。
経営の判断と現場の手順は、片方だけ変えても噛み合いません。両方に同時に手を入れられる位置に立って、決めるところから定着まで進めます。
- 課題の棚卸し
- ロードマップ設計
- データ活用
- 導入後の改善
ひとつ直すと、隣が動く。
業務の一部をアプリにすると、これまで人づてだった情報が形になります。 形になると、次にどこが詰まっているのかが見えます。
だからKagaryは、頼まれた範囲だけを納品して引き上げることをしません。 いま選ぶ一手が次の一手をどう変えるかまで含めて、順番を決めます。
進め方
話してから、動くものが出るまで。
聞く
まだ言葉になっていない違和感のままで構いません。整理はこちらでやります。
決める
全部を一度にはやりません。最初に手をつける一箇所を、理由とセットで決めます。
つくる
短い周期で動くものを出します。触った感想が、次に何を直すかを決めます。
続ける
使われ方を見ながら直します。手が離れたあとも回る形にして渡します。
よくある質問
先に、答えておきます。
何から相談すればいいか分かりません。
「何が問題なのか分からない」という状態のままで大丈夫です。最初の打ち合わせは、課題を特定するところから始めます。整理された要件をお持ちいただく必要はありません。
いま使っているシステムは入れ替えになりますか。
まず入れ替えない前提で考えます。動いているものには書かれていない事情が必ず埋まっているので、何が効いているのかを確認したうえで、つなぐ・足す・置き換えるのどれが妥当かを判断します。
提案だけ、あるいは開発だけでも頼めますか。
どちらも承ります。ただしKagaryの前提は、話を聞いた人がそのまま実装まで担当することにあります。分けてご発注いただく場合は、その利点が薄くなる点だけ先にお伝えしています。
社内にエンジニアがいなくても進められますか。
進められます。ただし、業務を一番よくご存じの方には途中で何度か時間をいただきます。仕様は現場にしかないためです。
どのくらいの規模から相談できますか。
「この帳票をひとつなくしたい」くらいの大きさから構いません。小さく始めて手応えを見てから広げるほうが、結果的に速いことが多いです。
お問い合わせその違和感を、
その違和感を、
聞かせてください。
整理してからでなくて構いません。 いま困っていることを、そのままの言葉でお送りください。