Django × Vue システム開発）業務知識がなぜ必要か
1. 内製で得られる効果
私自身この1年で、業務システムをベンダー依存からAIを活用した内製へ切り替えてきた。
そこで得られた コストとスピードの効果は圧倒的 だった。
- ベンダーに依頼すると数百万円規模の開発を、1カ月未満・ベンダーコストで内製化
- ベンダーなら数週間かかる修正を、数日〜1週間で反映
- 「もう直ったの？」と驚かれるスピード感
従来は「修正依頼を出す → 要件定義書をまとめる → 契約して納品を待つ」という流れで、そもそも依頼した内容すらユーザが忘れてしまう状況。
しかし、内製に切り替え、ニーズをすぐさま形にできるようになり、ユーザの反応は大きく変わった。
ただし、この効果はあくまで入り口にすぎない。
システムがすぐ作れるようになったからといって、業務そのものが変わるわけではない。
むしろ、この先にある「人と組織の課題」がはっきりと見えてきた。
2. ユーザ主体性の限界
ユーザからの要望の多くは 「今の仕事を楽にしてほしい」 というものが多い。
- 入力を減らしてほしい
- 帳票を自動で出したい
- 画面遷移を少なくしてほしい
確かに効率化としては正しいし意味がある。
だが、それだけでは業務の枠組みは変わらない。
顧客を巻き込んで業務フローを再設計する、そもそもプロセスを根本から見直すといった提案がユーザから出てくる現場は少ない。
主体性があることは大事だが、高い視座をもたないと、システムの効果は限定的 になる。
3. 細かい使い勝手の指摘に終始する現実
試作した画面を現場に見せると、返ってくるのは「ボタンの位置が不便」「文字サイズが小さい」といった細かい使い勝手に関する指摘が多い。
もちろんユーザビリティは重要。だがそればかりでは、システムが業務全体にどう貢献できるのか、という本質的な議論に至らない。
- この仕組みで業務の精度やスピードがどれだけ改善されるのか
- 運用ルールをどう変えるべきなのか
- 他の部門や顧客とのやり取りにどう影響するのか
こうした問いに触れてくれるユーザはごく少数。
「使いやすいシステム」にはなるが、「業務を変えるシステム」にはなかなかならない のが現実。
4. 仮説を立てられる人材の不足
「まず仮説を立てて、すぐに試し、改善する」という進め方を、よく効果的とされる。
しかし、そもそも仮説を立てられるユーザが少ないのが現実。
- 出てくる要望は「今の不便を減らしてほしい」レベルに偏る
- 「この仕組みがあれば顧客対応をこう変えられる」といった議論は生まれにくい
- 結局システム部門が仮説を考え、提示しなければ議論が進まない
本来、仮説は現場が一番持っているはず。だが、日々の定常業務に追われ、事業全体の課題やあるべき姿を普段から考えている人は限られている。
その結果、改善の発想はどうしても「効率化どまり」になってしまう。
5. 業務知識がなぜ必要か
ここまでで見てきたように、内製化によってスピードとコストは改善される。
だが、それだけでは業務そのものを変えることはできない。
本質的な変革を実現するには、システム設計者/開発者が業務知識を持つこと が不可欠。
ここで言う業務知識とは、ユーザ部門と同じレベルで現場を細かく知ることではない。
システム開発者としての経験や、他社・他業種で培った一般的な業務モデルの理解をもとに、俯瞰した視点で設計や議論を進められる力のことだ。
業務知識が必要な理由は大きく2つある。
(1) 設計の前提として必須
業務モデルを知らなければ、テーブル設計やAPI設計はできない。
販売管理・生産管理・会計などの一般的な構造を把握し、マスタやトランザクションの関係を理解することが、そもそものシステム設計の土台になる。
また、市販パッケージが多様な業務に対応できるのはなぜか、その設計思想を理解していれば、自社の業務を一般モデルに寄せるべきか独自化すべきかの判断ができる。
(2) 議論をリードする力
ユーザから出てくる要望は効率化どまりになりがちだ。
システム部門が業務知識を持っていれば、
「それは業務全体にどう影響するのか」「他部門との整合はどう取るのか」
といった問いを投げかけ、本質的な議論に引き上げられる。
まとめ
AIを活用した内製化で 開発スピードとコスト削減 はすぐ実現できる。
だが、それはゴールではなくスタートにすぎない。
- ユーザ要望は効率化どまり
- 指摘は細かいUI改善に集中
- 仮説を立てられる人材が不足
この現実を乗り越えるために、システム設計者/開発者には業務知識が欠かせない。
業務知識は、システムを設計するための前提であり、議論をリードするための武器でもある。
そのために必要な 一般的な業務モデルの理解と考え方 については、今後整理していく。
技術力だけでは不十分。
業務知識を土台にした設計力と議論力こそが、システム部門の真の強みになる。
Discussion