なぜ中小企業では「完璧な要件定義」が難しいのか
要件定義とは、システムを作る前に「何を、どこまで、どんな動きで実現するか」を文書で決める工程です。大企業の情報システム部門であれば、専任の担当者が数か月かけて業務を洗い出し、関係部署と調整して仕様を固めます。しかし、従業員10〜100名ほどの会社では、次のような理由でこの進め方がうまくいかないことが多くあります。
専任の担当者がいない
多くの場合、システム化の窓口は総務や経理の担当者、あるいは社長自身が兼務しています。日常業務の合間に、業務フロー図を描き、例外処理を洗い出し、画面のレイアウトまで決めるのは現実的ではありません。
業務の中身が人の頭の中にある
「この得意先は締め日が違う」「この製品だけ単価の計算が特殊」といったルールは、ベテラン社員が経験として覚えていて、どこにも書かれていないことがほとんどです。聞き取りをしても、本人にとって当たり前すぎて話に出てこず、システムができあがってから「この場合はどうするの？」と発覚します。
使ってみないと分からない
紙やExcelで回していた業務を画面に置き換えたとき、実際に使いやすいかどうかは触ってみるまで分かりません。紙の上で決めた仕様が、現場で使うと手間が増えるだけだった、ということは珍しくありません。
要件定義が進まないのは、担当者の能力不足ではありません。「使う前にすべてを決める」という進め方そのものが、中小企業の実情に合っていないことが多いのです。
その結果、要件定義の段階で数か月が過ぎて社内の熱が冷めてしまったり、時間をかけて作り込んだのに現場で使われなかったりします。そこで考えたいのが、次に説明する「60点から始める」進め方です。
「60点から始める」とはどういう進め方か
60点から始めるとは、業務の中心となる部分だけを最小限の機能で作り、すぐに現場で使い始め、使いながら足りない部分を足していく進め方です。ソフトウェア開発の世界では「アジャイル開発」や「MVP（必要最小限の機能を持った製品）」と呼ばれる考え方に近いものです。
具体例：クリーニング店の受付管理
たとえば、複数の店舗を持つクリーニング店が、紙の預かり票とExcelで管理している受付業務をシステム化したいとします。最初から「会員管理、ポイント、売上集計、工場への指示書、LINE通知」まで盛り込もうとすると、仕様を決めるだけで半年かかりかねません。
60点版では、たとえば次のように絞り込みます。
- 受付時に、お客様名・品物・仕上がり予定日を入力できる
- 預かり番号で検索して、引き渡し済みにできる
- その日の受付一覧を印刷できる
これだけでも、紙の預かり票を探し回る時間は減ります。そのうえで、1〜2か月使ってみて「仕上がり日が過ぎた未引き取り品を一覧で見たい」「工場に渡す一覧も出したい」といった声が出てきたら、優先度の高いものから順に追加していきます。
従来の進め方との違い
| 項目 | 従来型（一括で作り込む） | 60点から始める |
|---|---|---|
| 最初に決めること | 全機能の詳細な仕様 | 中心業務と最低限の機能 |
| 使い始めるまで | 数か月〜1年以上かかることも | 比較的短期間で試用を始められる |
| 費用の出方 | 初期にまとまった金額 | 初期は小さく、その後は月々の改善費 |
| 仕様の変更 | 追加費用・再見積もりになりやすい | 改善の一部として順番に対応 |
| 向いている状況 | 業務ルールが明確で変わらない | 業務が整理しきれていない、使ってから考えたい |
ここで大切なのは、60点版は「手抜き」ではないという点です。入力したデータが消えない、計算が合っている、といった基本的な品質は100点である必要があります。60点なのは「機能の範囲」であって、「品質」ではありません。
60点版を作ったあとの「改善の期間」まで含めて計画しないと、本当に60点のまま放置されてしまいます。開発と保守・改善をひと続きで考え、同じ相手に継続して頼める体制にしておくことが前提です。
最初に手をつける業務の選び方
60点から始める進め方で一番大事なのは、最初の題材選びです。いきなり基幹業務の全体を対象にすると、結局は大がかりな要件定義が必要になります。最初は「小さく、効果が見えやすく、失敗しても業務が止まらない」ものを選びます。
- 毎日または毎週、決まった人が繰り返している作業である
- 転記・集計・探し物など、明らかに手間がかかっている部分がある
- その作業の流れを、担当者が口頭で10分程度で説明できる
- 関わる部署・人数が限られている（まずは1部署・数名程度）
- うまくいかなかった場合、元のExcelや紙のやり方にすぐ戻せる
- 成果を「時間が何分減った」「ミスが何件減った」など数字で確かめられる
- 会計や給与など、法令や外部とのやり取りに直結する処理ではない
題材の例
- 製造業：日報（作業時間・不良数）をExcelに手入力して月末に集計している作業を、タブレット入力と自動集計に置き換える
- 建設業：現場ごとの資材発注や職人の手配状況を、ホワイトボードと電話で管理しているものを一覧画面にする
- 卸売業：FAXで届く注文を見ながら在庫表を確認し、出荷指示書を手書きしている流れのうち、在庫照会と指示書の作成だけを先に仕組み化する
逆に、最初の題材として避けたほうがよいのは、「全社で使う販売管理を丸ごと入れ替える」「会計システムと連携させる」といった、影響範囲が広く後戻りしにくいものです。こうした業務は、小さな成功体験を積んで社内の進め方が固まってから取り組むほうが安全です。
現場の声を集めて改善につなげる方法
60点版を使い始めたら、次は「何を足すか」を決めるための声を集めます。ここが仕組みとして回っていないと、改善が止まるか、声の大きい人の要望ばかりが通るかのどちらかになりがちです。
要望は1か所に集める
口頭、チャット、メモ書きなど、要望がばらばらに届くと必ず抜け漏れが出ます。共有のExcelシートやチャットの専用スレッドなど、置き場所を1つに決めます。記録する項目は、次の程度で十分です。
| 記録する項目 | 記入例 |
|---|---|
| 日付・記入者 | 10/3 出荷担当 田中 |
| 困っていること | 同じ得意先の注文を毎回ゼロから入力している |
| どのくらいの頻度か | 1日に10件ほど |
| こうなるとうれしい | 前回の注文をコピーして修正できるとよい |
| 対応状況 | 未着手／検討中／対応済み／見送り |
ポイントは「こういう機能を作ってほしい」ではなく、「何に困っているか」を書いてもらうことです。困りごとが分かれば、作る側がより簡単な解決策を提案できることもあります。
定期的に短い打ち合わせを持つ
月に1回、30分〜1時間程度、社内の取りまとめ役と開発側で要望リストを見直します。その場で「次の1か月で対応するもの」を2〜3件に絞り、残りは次回以降に回します。毎回すべてに応えようとしないことが、長く続けるコツです。
使われ方も確認する
声を上げない人が不満を抱えていることもあります。「入力が二度手間になっていないか」「結局Excelに書き写していないか」を、取りまとめ役がときどき現場を見て確かめると、要望として出てこない問題に気づけます。
予算の組み方｜月々の小さな改善で進める
60点から始める進め方では、費用の考え方も変わります。最初にまとまった開発費を払い切るのではなく、「最初の60点版の開発費」と「その後の月々の保守・改善費」に分けて考えるのが一般的です。
費用を左右する主な要素
具体的な金額は、作るものと体制によって大きく変わるため、ここでは一般的な目安を決める要素を挙げます。
- 対象業務の範囲：画面の数、帳票の数、扱うデータの種類が多いほど費用は上がります。
- 既存のデータや仕組みとの連携：既存のExcelから移し替える、会計ソフトにデータを渡す、といった連携が入ると手間が増えます。
- 使う人数と場所：社内の数名で使うのか、複数拠点や社外から使うのかで、必要なセキュリティや環境が変わります。
- 月々の改善の量：毎月どの程度の作業時間を改善に充てるかで、月額が決まります。
月額で組むときの考え方
月々の改善費は、「毎月◯時間分の作業枠」のように決めておくと、社内でも予算を説明しやすくなります。たとえば、ある月は小さな改修を3件、別の月は少し大きな機能追加を1件、というように枠の中で優先度を決めて使います。繁忙期で要望が少ない月は、システムの点検やデータの整理に充てることもできます。
月額で進めると、大きな稟議を通さなくても始めやすく、効果が見えなければ途中で規模を見直すこともできます。一方で、契約時には「月の作業枠を超えた場合の扱い」「使わなかった枠を翌月に繰り越せるか」「解約時にソースコードやデータを受け取れるか」を必ず確認しておきましょう。契約条件に不安がある場合は、専門家に相談することをおすすめします。
よくある失敗と防ぎ方
60点から始める進め方は柔軟な分、気をつけないと失敗しやすい落とし穴もあります。代表的なものと対策をまとめます。
失敗1：要望が膨らみ続ける（スコープクリープ）
「せっかくだからこれも」「あの部署でも使いたい」と、当初の範囲がどんどん広がっていく現象を、スコープクリープと呼びます。いつまでも完成しない、費用が想定を超える、といった問題につながります。
対策：最初に「今回の60点版で実現すること」と「今回はやらないこと」を1枚の紙に書き出して合意しておきます。新しい要望は否定せず、要望リストに載せて次回以降の優先度判断に回します。
失敗2：社内に取りまとめ役がいない
最も多いのがこのケースです。開発会社に任せきりにすると、現場の声が届かず、優先順位も決まらず、改善が止まってしまいます。
対策：社内に1名、取りまとめ役（オーナー）を決めます。システムに詳しい必要はありません。必要なのは、現場の業務が分かっていて、「今月はこれを優先する」と決める権限を持っていることです。週に1〜2時間程度、この役割に時間を割けるよう、上長が業務量を調整することも大切です。
失敗3：60点のまま誰も使わなくなる
最初の版が使いにくく、現場が元のExcelに戻ってしまうケースです。
対策：使い始めの1〜2週間は、取りまとめ役が現場に「困っていることはないか」を積極的に聞きに行きます。最初の改善を早めに反映すると、「言えば良くなる」という実感が生まれ、要望が出やすくなります。
失敗4：作った人しか分からない仕組みになる
改善を重ねるうちに、仕様が誰にも分からなくなる。これでは、属人化したExcelマクロと同じ問題を繰り返すことになります。
対策：改善のたびに「何を変えたか」を簡単な記録として残してもらい、ソースコードやデータの保管場所を自社でも把握しておきます。開発会社が変わっても引き継げる状態を保つことが、長く使い続けるための保険になります。
ソースコードの権利や保管場所が契約で曖昧なまま進めると、後から保守会社を変えたくなったときに困ることがあります。始める前に、成果物の扱いを書面で確認しておきましょう。
まとめ
- 中小企業では専任者がおらず、業務ルールも人の頭の中にあるため、最初から完璧な要件定義をするのは難しいのが普通です。
- 中心業務だけを最小限の機能で作る「60点版」を早く使い始め、使いながら改善するほうが現場に合った仕組みになりやすくなります。60点なのは機能の範囲であり、品質ではありません。
- 最初の題材は、繰り返し作業で手間が見えやすく、関わる人が少なく、失敗しても元に戻せる業務を選びます。
- 要望は「困りごと」として1か所に集め、月1回の打ち合わせで優先度を決めて少しずつ対応します。
- 費用は「60点版の開発費」と「月々の改善費」に分けて考え、作業枠や成果物の扱いを契約で確認しておきます。
- スコープの膨張と、社内の取りまとめ役不在が最大の失敗要因です。「やらないこと」の合意とオーナーの指名から始めましょう。