独自開発

「作る前」に決まっていないと、高くついて、使われません。

「自社専用のシステムを作りたい」というご相談の裏には、よく似たつまずきがあります。ベンダーに丸ごと任せたものの、現場で使われず費用だけがかさんだ。要件が固まらないまま作り始めて、できたものが想定と違った。あるいは、既製のツールやちょっとした工夫で足りたはずのものまで、一から作ってしまった。

どれも、コードを書く前の「何を・なぜ作るのか」、そして「そもそも作るべきか」が詰められていないことから起きます。独自開発は、作り始めてからでは引き返しにくい——だからこそ、作る前の見極めが要ります。

まず担うのは、コードを書くことではありません。

KAISHINがはじめに担うのは、コードを書くことではありません。御社の業務の、どこに・どんな手間や詰まりがあるのか（ペイン）を現場から引き出し、「何を・なぜ作るのか」を要件として固めること。そして、それは本当に独自開発で解くべきか、既製のもので足りないかを見極めることです。

作ると決めたら、開発そのものは、案件に合わせてパートナーのエンジニアと、ひとつの指示系統で進めます。KAISHINは黎明期からコードを書いてきた立場なので、エンジニアと対等に話し、実現できること・できないことを踏まえて、無茶な仕様や過剰な作り込みを止められます。発注側に立って、業務と技術の両方が分かる窓口がひとつある——そこが違いです。

費用は、どこまでを任せるか＝必要な稼働（どれくらい関わるか）で決まります（→ 費用の考え方）。お見積もりは、初回相談（無料）で状況をうかがって概算をお出しし、内容が固まってから精査します。パートナーのエンジニアと開発する場合も、費用は同じ見積もりにまとめてご提示します（窓口・請求はKAISHINひとつ）。

作れることより、「作るべきものを、作るべき分だけ」。

過去に携わってきたなかには、こんな見極めがあります。外部のシステムとの連携は、後々の保守のことを考えて、独自開発せず既製のものを使った。データの自動取得は技術的には可能でも、提供元の都合で形が変わりうるため、あえて自動化しきらず、手作業を軽くする補助に留めた。新しい仕組みは、いきなりシステム化せず、まず数カ月、人手で試してから、作るかどうか・どこまで作るかを決めた。

「買うか・作るか」を先に決めず、要件と費用対効果を詰めてから選ぶ。効果が見込めて、難しすぎないものから着手する。——独自開発の良し悪しは、作れることよりも、作るべきものを、作るべき分だけにできるかで決まります。

独自開発が正解とも、決めていません。

多くの場合、いきなり独自開発には入りません。まず脱Excelを、kintone などのノーコードで始め、データを使う習慣と土台が整ってきた段階で、独自開発や専用のシステムに進みます。一方で、業務の複雑さや運用の負荷、将来の拡張を見て、はじめから独自に作ったほうが合うこともあります。逆に、表計算の共有や無料の社内 wiki で十分なこともあります。

どれを選ぶかは、業務の中身と費用対効果から決めます。過剰な投資を避けることも、独自開発の設計の一部です。

「システムを作りたい」が、入り口だったとき。

独自開発のご相談をうかがうと、本当に必要なのはシステムそのものではなく、業務の流れや、集客・営業との接続の整理だった、ということもあります。その場合は、開発単体でなく、事業全体の中でどこを直すと効くのかを一緒に見ます。それが「社外の事業推進責任者」です。

何から手をつけるべきか分からない場合は、まず課題整理から。 → ［ 社外の事業推進責任者とは ］