【設計思想】要望に応えるほど、システムが使いにくくなる？ 受託開発で起こりやすい落とし穴と2つの対策
業務システムや社内ツールは、最初はとてもシンプルな形で始まることが多いものです。ところが、試作品を確認したり、実際に使い始めたりすると、「この条件も追加したい」「この部署だけ計算を変えたい」といった要望が少しずつ出てきます。
一つひとつの要望に応えていった結果、気づくと画面には入力欄やボタンが並び、どこで何を操作すればよいのか分かりにくくなっている。「希望した機能を入れてもらったはずなのに、かえって使いにくくなった」という、少し不思議なことが起こり得ます。
この記事では、なぜ要望に応えるほど仕組みが複雑になるのかを整理したうえで、作る前の業務整理という予防策と、2つの対策を紹介します。外部に開発を依頼する方だけでなく、Excel VBAやGoogle Apps Script（GAS）、AIなどを使って社内ツールを自作している方にも当てはまる話です。
同じ内容を動画でも解説しています。
なぜ要望に応えるほど複雑になるのか
多くの場合、複雑さは一度に生まれるのではなく、次のような段階を経て少しずつ積み重なっていきます。
最初の仕様を決める。この段階では、何をするための仕組みなのか、全体像が比較的はっきりしています。
動作確認や納品後の利用の中で、追加の要望が出てくる。例外的な処理、取引先ごとの計算方法、入力欄の追加などです。
条件分岐（「この場合はこう、あの場合はこう」という分かれ道）や例外処理、画面の項目が増え、仕組み全体が複雑になる。
使う人、さらには依頼した本人でさえ、どの条件で何が起こるのかを把握しにくくなる。
行き着く先は、「使いにくい」「問い合わせが増える」「運用が不安定になる」といった状態です。どの段階にも、誰かの明らかな失敗があるわけではありません。それぞれの判断はもっともなのに、全体としては扱いにくくなっていく。ここがこの問題の分かりにくいところです。
具体例：Excelの見積計算に処理を足し続けた場合
ここからは、説明のための架空の例です。実際の案件ではありません。
最初は「数量×単価」で金額を出すだけの、ごくシンプルな見積計算のシートだったとします。そこに、次のような要望が順番に加わっていきます。
特定の取引先には割引をかけたい
商品の区分によって端数処理（切り捨て・四捨五入など）を変えたい
担当者や納品日によっては例外的な計算をしたい
自動計算の結果を手で調整できる欄もほしい
どれも業務上の理由がある要望です。しかし、これらをすべて一つの計算式やマクロに入れ込むと、式はどんどん長くなり、入力欄も増えていきます。
その結果、表示された金額を見ても「どの計算が適用されたのか」がすぐには分からなくなります。お客様に計算の根拠を聞かれても説明に時間がかかり、入力の仕方を間違えても気づきにくい。こうしたことが、ミスや社内の問い合わせにつながっていきます。
社内で自作する場合にも同じ問題が起きる
この現象は、外部に開発を依頼したときだけのものではありません。Excel VBAやスプレッドシート、AIを使って社内でツールを作る場合にも、同じことが起こり得ます。
社内ツールは身近な分、各部署から「このボタンも付けてほしい」「この入力欄も足してほしい」と頼まれやすいものです。応えるたびに画面の項目が増え、誰がどの機能を使うのか、どれが今も使われているのかが分かりにくくなっていきます。
特にAIを使うと、機能を一つ足すこと自体はずいぶん手軽になりました。ただ、機能を足しやすくなっても、業務全体を整理したり、何を優先するかを決めたりする必要がなくなるわけではありません。むしろ足しやすい分、全体を見直す機会を意識して持つことが大切になると考えています。
自作か外注かのどちらが良いという話ではなく、どちらの場合でも、要件の整理と全体の設計が必要だということです。
問題の本質は「使う人の理解力」ではない
仕組みが分かりにくくなったとき、「使う人がよく理解していないから」と考えてしまいがちです。しかし、原因はそこではないことが多いと思います。
まず、現場の業務ルールそのものが複雑な場合があります。長年の取引の経緯や、特定のお客様への配慮から生まれた例外は、どの会社にもあるものです。業務が複雑なら、それに忠実に合わせたシステムも複雑になりやすくなります。
次に、個々のルールを理解していることと、それらが組み合わさった仕組み全体を理解できることは別の話です。現場の方は「この取引先は割引」「この商品は切り捨て」と一つずつはよく分かっています。それでも、それらが何重にも条件分岐として組み合わさると、「この組み合わせのときはどうなるのか」を頭の中で追うのは誰にとっても大変です。
つまり問題は、使う人の能力ではなく、仕組みを使うときに頭の中で考えなければならないことの多さ（認知負荷と呼ばれることもあります）と、業務そのものの複雑さにあります。一つひとつの変更が合理的でも、積み重なった全体が最適になるとは限らない、ということです。
まず予防策：作る前に業務を整理し、関係者で認識をそろえる
対策の話に入る前に、そもそも複雑になりすぎないための予防策があります。それは、作り始める前と、仕様を変えるたびに、現場の業務を整理して関係者で認識をそろえることです。
確認しておきたいのは、たとえば次のような点です。
業務の始まりから終わりまでの流れと、それぞれの担当者
どんな情報を入力し、何を出力するのか
判断の条件や計算のルール、そして例外
今使っている帳票やファイルの形式
誰が、いつ、どの画面を使うのか
口頭の説明だけでは、思い違いが残りやすいものです。業務の流れを簡単な図にしたり、サンプルのデータや画面のラフ（手書きのような簡単な下書き）を見ながら確認したりすると、認識のずれに早く気づけます。
あわせて、「必ず必要な要件」と「できればほしい要望」に優先順位をつけておくことも大切です。その要望を入れると操作がどれだけ増えるのか、後々の手直しの負担はどうなるのかも、このときに確かめておきます。要望を絞って最小限から作る考え方については、「受託開発で要望を全部入れると失敗しやすい理由」でも詳しく書いています。
とはいえ、すべての仕様を最初に完全に決めきれるとは限りません。開発の途中や納品後にも変更は出てきます。そのたびに、影響を確かめ、合意してから直すという手順を繰り返すことが、複雑さを溜め込まないための基本になります。
対策① システム側で複雑さを吸収する
予防をしていても、業務の性質上、どうしても複雑さが残ることはあります。そのときの対策は、大きく分けて2つあります。
1つ目は、業務のルールを変えにくいときに、システム側で複雑さを引き受けるという考え方です。中身の計算や判定が複雑でも、使う人が毎日触る部分はシンプルに保ちます。
具体的には、次のような工夫があります。
その場面で必要な項目だけを表示する
条件の判定や計算を自動にして、使う人が判断する場面を減らす
入力の誤りを見つけたら、どう直せばよいかを案内する
計算結果について、どの条件が適用されたのか、根拠を確認できるようにする
先ほどの見積計算の例でいえば、取引先・商品・数量を入れれば、割引や端数処理は自動で判定される形です。表示された金額の横に「取引先割引を適用」などと出るようにしておけば、根拠の説明もしやすくなります。
ただし、画面を分かりやすくするだけでは、業務ルールそのものに矛盾があったり、例外が多すぎたりする問題までは解消できない場合があります。その場合は、次の対策も合わせて考えます。
対策② 業務ルールそのものを見直す
2つ目は、ルールや書式を見直せるときに、システムに合わせる前に業務自体を整理するという考え方です。
たとえば、次のような見直しが考えられます。
その例外処理が今も本当に必要か、改めて確認する
担当者によって違うやり方を、一つの手順にそろえる
使われていない入力項目や、重複している確認の工程を減らす
めったに起きない例外は、普段の処理とは切り分けて扱う
部署や担当者ごとに異なる書類や入力の様式を、業務上問題のない範囲で統一する
システムにすべての業務を合わせ込む前に、業務そのものを少しシンプルにできないかを考えてみる。それだけで、作るべき仕組みがぐっと分かりやすくなることがあります。
ただし、法令や契約、会計上の決まりなど、変えられないルールを無理に簡略化してはいけません。また、業務ルールを変えるには現場の合意が必要です。開発する側が独断で「このルールはなくしましょう」と決めるのではなく、現場の方と相談しながら進めることが前提になります。
発注する側と開発する側、双方に求められる役割
ここまでの予防策と対策は、どちらか一方だけでは進みません。発注する側と開発する側が、それぞれの役割を持ち寄ることが大切です。
発注する側（現場）：今の手順、例外となるケース、困っていること、優先順位、変えられない制約をできるだけ具体的に伝える。試作品は、実際に使う現場の担当者にも確認してもらう。
開発する側：業務の整理をリードし、言われた機能をそのまま足すのではなく、その変更が全体にどう影響するのか、ほかにどんな選択肢があるのかを分かりやすく説明する。
双方：操作のしやすさ、計算の根拠、変更の範囲、保守や使い方の説明にかかる負担を一緒に確認し、変更内容に合意する。
社内で自作する場合は、作る人が「開発する側」の役割も担うことになります。頼まれた機能をすぐに足す前に、一度立ち止まって全体を整理する時間を取ることが、結果的に使いやすいツールにつながりやすいと考えています。業務が込み入っていて社内だけでは整理しきれないときは、設計の段階から外部の専門家に入ってもらうのも、一つの選択肢です。
仕様変更を依頼・承認する前に確認したいこと
最後に、新しい機能を頼む前、あるいは変更を承認する前に、確認しておきたい点をまとめます。
その追加機能は、どんな困りごとを解決するためのものか
今ある仕組みで代わりにできないか
業務ルールの見直しで解決できないか
操作や計算が複雑になりすぎないか
使う人が、変更後の流れを理解し、人に説明できるか
開発の費用だけでなく、運用・教え方・保守の負担はどう変わるか
可能であれば、実装する前にサンプルのデータと画面の案を使って、変更後の操作を実際に試してみると安心です。作ってから「思っていたのと違う」となるよりも、ずっと少ない手間で認識をそろえられます。
まとめ：大事なのは「要望どおり」より「使い続けられる仕組み」
要望に応えること自体は、もちろん大切です。ただ、機能を足すことが常に最善とは限りません。一つひとつの要望は合理的でも、全体を見直さずに足し続けると、仕組みは少しずつ分かりにくくなっていきます。
この記事の内容を整理すると、次のとおりです。
予防：作る前と仕様を変えるたびに業務を整理し、関係者で認識をそろえる
対策①：業務のルールを変えにくいときは、システム側で複雑さを吸収する
対策②：ルールや書式を見直せるときは、業務ルールそのものを見直す
外注でも自作でも、目指したいのは、使う人が理解でき、長く安定して運用できる仕組みです。新しい要望が出たときには、その機能を足すかどうかだけでなく、全体として使い続けられるかどうかという視点で、一度立ち止まって考えてみていただければと思います。
