基礎は、毎回発明しない
オーダーメイドで作ると言いながら、私たちは毎回同じ土台から始めます。自社の開発テンプレート EmulsiaBuildTemplate を持つ理由と、AIが進むほどそろえた土台が効くこと、測り続けないと腐る理由を書きます。

オーダーメイドと言いながら、毎回同じところから始めます
私たちは、お客様の業務に合わせてシステムを作ります。既製品に業務を寄せるのではなく、その会社のやり方のままで動くものを作る。それが仕事の中身です。
なのに、新しい案件が始まったとき、最初に開くファイルはいつも同じです。EmulsiaBuildTemplate という、自社で持っている土台。ログインの仕組み、誰が何を見ていいかの権限、いつ誰が何を書き換えたかの記録、そして出す前の検査。この四つは、どの案件でも同じものを使い回しています。
「オーダーメイドじゃなかったのか」と言われそうです。私たちも最初は、そう思っていました。
ゼロから作っていた頃、同じ穴を二度掘りました
独立してしばらくは、ノーコードを使っていたのであまり気にはしていませんでした。新しくWebアプリという技術を選び直すところから始めて、ログインを作り、権限を作り、記録の仕組みを作る。そこまでで、ずいぶん時間がかかることに気が付きました。
問題は、時間そのものより、その時間の使い先でした。土台に手間を取られるほど、肝心の「その会社らしさ」を作り込む時間が減っていきます。呼び名、順番、例外の扱い。本当はそこにいちばん時間をかけたいのに、削るのはいつもそこでした。
もう一つ、もっとまずいことがありました。ある案件で見つけた設計の間違いが、次の案件に伝わらないのです。頭では覚えているつもりでも、次の現場では別の形で同じ穴を掘っている。毎回ゼロから作るのは腕がいいことのように見えて、実際は記憶を頼りに同じ作業を繰り返していただけでした。
削られるのは、いつも右側でした。
注文住宅の基礎を、毎回発明する大工はいません
注文住宅は、一軒ごとに違います。間取りも、動線も、収納の位置も。それでも基礎の配筋や耐震の考え方、配管の勾配は規格に沿って作られます。「うちは基礎から独自です」という工務店がいたら、腕がいいのではなく危ないと思うはずです。
システムも同じです。変えるべきところと、毎回発明してはいけないところがあります。
地面より下は同じ。地面より上は、1社ずつ違う。
線の引き方は単純です。間違えたときに取り返しがつかないものを、下に置く。 誰がどこまで見られるか、記録が消えないか、出す前に検査を通ったか。ここは現場の都合では変えません。逆に、画面の並びや呼び名、承認の回し方は上です。ここは現場に合わせて変えます。
触っていいところと、触ると壊れるところ。その線を私たちが引いて、あいだに立つ。これが、人とシステムのあいだでやっている仕事です。
AIが進むほど、そろえた土台が効きます
2026年7月、私たちは自分たちの土台そのものを点検しました。動いているかどうかではなく、決まりごととして開いていないか、という見方で全部を洗い直す作業です。
そこで、権限の設定に穴が見つかりました。本来は限られた人しかできない操作に、一般の利用者から回り込める経路が残っていた。実際に使われた形跡はありません。それでも、構造として開いていたことに変わりはありません。
本来なら、すべてのアプリに同じ修正を入れるのは手間です。だから「最初からみんな一緒にしておこう」が通説でした。今はAIがあります。
同じ直しでも、AIに頼む手順そのものをプログラムにしておけば、放っておいても直せるようになりました。
AIが進むほど、土台をそろえておくことが効きます。アプリごとに土台が違えば、直し方も変わります。ルールと基礎構成がそろっているからこそ、テンプレートは役に立ちます。
一つの不具合を、一つの製品で直して終わりにしない。
通ったときは静かで、止まったときだけ声が上がります。
毎回思い出すのではなく、毎回機械に確かめさせています。
そろえた土台ほど、測り続けないと腐ります
ここまでだと、テンプレートさえ持っていれば安心という話に聞こえます。そうではありません。
土台は、作った瞬間から古くなります。案件が動き出すと、その現場の事情に合わせた手当てが積み重なり、少しずつ土台から離れていく。逆に、ある案件の事情だけを書いた記述が、共通の土台のほうへ紛れ込んだこともありました。全案件に配られる場所に、一社だけの話が混ざる。気づくまで、誰も気づきません。
だから私たちは、定期的に「どれだけズレたか」を測ります。土台と、そこから生まれた各システムを並べ、違いを一件ずつ突き合わせる。地味な作業ですが、これをやめると、テンプレートの利点はそのまま欠点に反転します。一か所直せば全部に届くということは、一か所放置すれば全部が同時に古びるということでもあるからです。
同じ構造が、良いほうにも悪いほうにも効きます。
固定するのは、個性を消すためではありません
固定するのは、自由にする場所を残すためです。
土台に使っていた時間が減った分は、そのままお客様の作り込みに回ります。この会社では検査と出荷を一人が兼ねている。この会社では、社長が最後に必ず目を通す。そういう「その会社にしかない形」に時間を使えるようになりました。同じ形に揃えるためではなく、揃えないところに時間を残すために、揃えられるところだけを揃えています。
固定するのは、
自由にする場所を残すため。
だから、土台は共通で構いません。
もうひとつ、大事なことがあります。この土台は、公開されている標準の部品だけで組んでいます。私たちにしか動かせない独自の仕掛けは入れていません。切り離すときの手順も文書にしてあります。私たちとの取引が終わっても、システムはそのまま持って出られます。
縛らないことを、契約ではなく構造で担保します。
私たちが土台を持っているのは、速く作るためではありません。壊れにくく、壊れたときに直りが早いためです。順調なときは、何も起きません。その「何も起きない」に、いちばん手をかけています。
よくあるご質問
- テンプレートを使うと、費用や期間はどれくらい変わりますか。
- 土台をつくり直す工程がない分、立ち上がりは短くなります。ただし金額が一律に決まるわけではありません。費用を左右するのは土台ではなく、その会社にしかない業務をどこまで作り込むかのほうです。まず現場を見せていただき、どこを作り込むかを決めてから、範囲と金額をお出ししています。
- いま使っているExcelや既存のシステムは、作り直しになりますか。
- いいえ、まず残したまま始めます。回っているものを先に止めると、いちばん困るのは毎日それを使っている方です。私たちは、既存のやり方を一度そのまま見せていただき、置き換える順番を一緒に決めます。全部を一度に載せ替えるより、困っている一つから移すほうが、現場は落ち着いて動けます。
- 納品したあとに土台側が新しくなったら、うちのシステムにも反映されますか。
- 自動では反映しません。安全に関わる修正は、必要と判断した時点でご連絡し、適用するかどうかを一緒に決めます。それ以外の改良は、必要になったときに個別にご相談します。断りなく本番の仕組みが書き換わることはありません。
- 開発を他社に引き継ぐことになったら、何を渡してもらえますか。
- システムのコード一式、設定、動かすための手順書、そしてデータそのものです。いずれもお客様の環境に置いてあり、私たちにしか動かせない独自の仕掛けは入れていません。引き継ぎの手順も文書にしてあるため、他社の技術者がそのまま保守を続けられます。
技術は真似できる
定着させるノウハウが、弊社の強みです。
まずは相談してみる
現状を整理してみる、くらいの気持ちで大丈夫です。