画面数で見積もられてしまう前に、企業が知っておきたいシステム開発の構造
システム開発の見積書を見ると、よく登場するものがあります。
操作画面の数。
入力フォームの数。
一覧画面の数。
帳票の数。
機能の数。
もちろん、画面や機能を作るには工数がかかります。
ですから、それらが見積もりに反映されること自体が間違いというわけではありません。
しかし、企業側が注意すべきなのは、画面数や機能数が、システム開発の価値そのもののように扱われてしまうことです。
本当に価値があるのは、画面を何枚作ったかではありません。
その会社の業務をどこまで理解したか。
現場の判断をどこまで整理したか。
経営者の考えをどこまで業務構造に落とし込んだか。
会計、権限、承認、顧客管理、外部専門家との関係をどこまで見通したか。
本来、システム開発で最も重要なのは、こちらの方です。
画面は分かりやすい。だから請求しやすい
なぜ、システム開発会社は画面数や機能数を見積もりの根拠にしやすいのでしょうか。
理由は単純です。
顧客に説明しやすいからです。
「入力画面が10枚あります」
「一覧画面が5枚あります」
「帳票が3種類あります」
「管理画面を追加します」
このように説明されると、発注する企業側も分かった気になります。
目に見えるものだからです。
画面が増えれば、作業が増えたように見える。
機能が増えれば、開発量が増えたように見える。
帳票が増えれば、業務に合わせて作り込んでいるように見える。
しかし、ここに落とし穴があります。
画面は見えます。
だから分かりやすい。
一方で、業務理解は見えません。
権限設計も見えません。
データ構造も見えません。
将来のセキュリティ強化に備えた設計も、見積書だけでは分かりにくい。
その結果、本当に重要な設計よりも、見えやすい画面数が請求根拠として前面に出てきやすくなります。
本当にコストがかかるのは、画面ではなく業務理解
企業向けのシステム開発で本当に難しいのは、操作画面を作ることではありません。
本当に難しいのは、開発する企業の業務を理解することです。
どの業務が会社の利益を生んでいるのか。
どの手順が現場の工夫なのか。
どこに例外処理があるのか。
どの情報を外部に見せてはいけないのか。
誰が判断し、誰が承認し、誰が責任を持つのか。
どのデータが会計・請求・在庫・顧客管理につながるのか。
こうした情報は、表面的なヒアリングだけでは出てきません。
企業独自のノウハウには、他社に知られたくない情報もあります。
経営者が簡単には話したくない判断基準もあります。
現場担当者が長年の経験で覚えている暗黙知もあります。
それらを、信用を得ながら聞き出し、守秘しながら整理し、後から読める概要書面に落とし込む。
ここに、本来のコストがかかります。
画面を作る前に、会社の業務を言語化する。
この工程こそ、システム開発の上流で最も価値がある部分です。
画面から始めると、システムは膨らみやすい
問題は、画面からシステムを考えてしまうことです。
最初に画面イメージを作る。
顧客がそれを見て「分かりやすい」と感じる。
そこに入力項目を足す。
一覧画面を足す。
検索画面を足す。
管理画面を足す。
帳票を足す。
こうして、画面はどんどん増えていきます。
しかし、画面が増えたからといって、会社の業務構造が整理されるわけではありません。
むしろ、業務理解が浅いまま画面を増やすと、後から困ることになります。
同じような情報を複数の画面で入力する。
どのデータが正しいのか分からなくなる。
権限管理が後付けになる。
部署が増えたときに対応できない。
外部専門家と連携しにくい。
会計や請求とのつながりが曖昧になる。
将来のセキュリティ強化で作り直しが必要になる。
見た目には便利そうな画面が増えていても、裏側の構造が整理されていなければ、システムは複雑になっていきます。
見積もりコスト回収型の画面増殖
少し踏み込んだ話をすると、システム開発では、提案や見積もりを作る段階にもコストがかかります。
顧客の話を聞く。
業務を整理する。
提案書を作る。
概算を出す。
画面イメージを作る。
見積書を作る。
これらは本来、価値ある作業です。
しかし、顧客側が「提案や業務理解そのもの」に価値を感じにくい場合、そのコストをどこかで回収する必要が出てきます。
そのとき、画面数や機能数は説明しやすい請求根拠になります。
「この画面も必要です」
「この管理機能も必要です」
「この帳票も作りましょう」
このようにして、見積もりや提案にかかったコストを、画面や機能の数に乗せて説明する構造が生まれやすくなります。
もちろん、すべてのシステム開発会社が意図的に画面を増やしているわけではありません。
しかし、請求根拠が画面数や機能数に偏っていると、どうしても「作るものを増やすほど売上が増える」構造になります。
これは、発注する企業側にとって注意すべきポイントです。
画面を増やすことと、アプリケーションを分けることは違う
ここで誤解してはいけないことがあります。
画面を増やすことと、アプリケーションを分けることは違います。
画面を増やすとは、操作する入口や見た目を増やすことです。
一方で、アプリケーションを分けるとは、業務責任・権限・データ管理・会計連携・外部専門家との役割分担を整理することです。
たとえば、顧客対応、会計、講座運営、資料管理、外部専門家連携、権限管理を、必要に応じて分けることがあります。
これは画面数を増やしたいからではありません。
誰が何を見てよいのか。
誰がどの情報を変更してよいのか。
どのデータが正本なのか。
どの業務が会計とつながるのか。
外部専門家にはどこまで共有するのか。
将来、セキュリティ強化や事業分割が必要になったときに対応できるのか。
こうした境界を明確にするためです。
つまり、正当なアプリケーション分割は、画面を増やすためではなく、会社の業務と情報を守るために行います。
画面は少なく、構造は明確に
企業側が本当に求めるべきなのは、画面が多いシステムではありません。
使う人にとって画面は少なく、分かりやすい方が良い。
教育コストも下がります。
操作ミスも減ります。
保守対象も減ります。
一方で、裏側の構造は明確である必要があります。
業務ごとの責任範囲。
権限管理。
承認フロー。
データの正本。
会計との接続。
外部専門家との共有範囲。
将来のセキュリティ強化への備え。
ここを曖昧にしたまま画面だけ増やしても、会社にとって本当に使えるシステムにはなりません。
大切なのは、画面数ではありません。
会社の業務構造をどこまで理解し、どこまで整理し、どこまで将来に耐える形にできるかです。
高度な外注開発は、結局「内製化教育」に近づく
将来的なセキュリティ強化や権限分離まで考えたシステムを提案しようとすると、開発会社は企業側にシステム構造を説明する必要があります。
なぜ業務ごとに分けるのか。
なぜ権限管理が必要なのか。
なぜ顧客情報、会計情報、外部専門家との共有情報を同じ場所に置いてはいけないのか。
なぜ今は小さな会社でも、将来の部署分割や経営統合を考えた設計が必要なのか。
ここまで説明するなら、それは単なるシステム開発の提案ではありません。
企業側が、自社の業務構造とシステム構造を理解するための教育でもあります。
であれば、最初から「外部に丸投げするシステム開発」ではなく、企業側が構造を理解しながら進める内製化支援として始めた方が自然です。
内製化とは、すべてを自社だけで作ることではありません。
外部専門家を活用しながらも、自社の業務構造、権限、データ、会計、セキュリティの考え方を、企業側に残していくことです。
見積書で見るべきもの
システム開発の見積書を見るとき、企業側は画面数や機能数だけを見てはいけません。
見るべきなのは、次のような点です。
その会社の業務をどこまで理解しているか。
業務の概要書面が残るか。
権限や承認の考え方が整理されているか。
データの正本が明確になっているか。
会計や請求とのつながりが考えられているか。
将来のセキュリティ強化に対応できるか。
外部専門家を活用しても、会社側に判断軸が残るか。
画面は、システムの入口にすぎません。
本当に見るべきなのは、その奥にある業務構造です。
まとめ
操作画面を増やせば、見積もりは説明しやすくなります。
しかし、画面が多いことと、良いシステムであることは別です。
本当に価値があるのは、画面を増やすことではなく、会社の業務を理解し、企業独自のノウハウを尊重しながら、業務構造・権限・データ・会計・セキュリティを整理することです。
画面を増やすほど、会社のシステムは分かりやすくなるとは限りません。
むしろ、業務理解が浅いまま画面を増やすと、後から直しにくいシステムになってしまいます。
雲楼システムパートナーズでは、画面数や機能数を増やすことを価値とは考えていません。
当社が重視しているのは、企業側が自社の業務構造を理解し、必要に応じて外部専門家を活用しながら、将来に耐えるシステム設計を考えられる状態を作ることです。
画面から考えるのではなく、会社の業務構造から考える。
それが、中小企業のDXやシステム内製化で失敗しないための第一歩です。
コメントを残す