朝5時45分に起きて、メールも見ずに依頼を受けている市向けの配車システムの続きを始めた。
この日は新町からiMacや書類を南船場へ移動したり、翌日の車の点検に備えて実家で車を入れ替えたりと、細かな用事も多かった。
南船場には、まだ整理しなければならない書類も残っている。
やってしまいたい気持ちはある。
ただ、今はBit MVPやわ。
書類整理も必要だが、優先順位としてはかなり低い。何でも目の前から片付ければいいわけではない。今やるべきことを考えれば、MVPの開発を進める方が重要だった。
午後から再び開発を進め、18時半に郡上市向けの送迎配車システムで、メール入力と音声入力の2つが完成した。
今回、自分の中で大きかったのは、単に配車システムが動いたことではない。
メールと音声は「入口が違うだけ」だと整理できたことである。
メールから入れても、音声から入れても、最終的には同じデータベースへ保存する。
そう考えると、これは配車だけの仕組みではなくなる。
例えばミーティングの記録でも、日報でも、基本的な構造は同じである。保存する項目を変えれば、同じ仕組みを使い回せる可能性がある。
これまでは案件ごとに「何を作るか」を考えていた。
しかし、共通部分をコアとして持っておけば、毎回ゼロから作らなくてもいい。
今回作っているものが、別のMVPを作るための土台にもなっていく。
ここが大きい。
もちろん、仕組みを共通化できたからといって、現場まで全部同じにするつもりはない。
配車であれば、実際に使っているホワイトボードと見比べながら、どんな項目なら見やすいのかをこちらから提案する。実際に使ってもらって、要望があれば修正する。
仕組みは共通化する。
使い方は現場に合わせる。
この2つは分けて考えた方がよさそうだ。
報連相の仕組みについても同じで、料金プランによって機能を細かく分けるより、API料金を別途負担してもらえるのであれば、スタッフが使いやすい入力方法を選べる形でもいいのではないかと考え始めた。
ただ、これはまだ自分の思いつきである。
現場からすると、選択肢が多いより「これを使ってください」と一つに決まっている方が楽かもしれない。経営者から見れば、API料金がかかる方法ばかり使われるのも困るだろう。
作れることと、実際に使いやすいことは違う。
だからこそ、まず小さく作って現場で使ってもらいながら考える。
今日できたコアを土台に、次はそこを確かめていきたい。