AIの窓口が動き始めて、しばらく経つ。実際に使っているうちに、いろいろなことが見えてくる。
「ここ、こうなっていたら便利なのに」 「あの情報も、答えられるようにできない？」 「予約まで受けられたら、もっといいよね」
こういう声が社内やお客様から出てくるのは、とても良い兆候です。 使われている証拠であり、現場がそれを自分たちの道具として考え始めた証拠でもあります。
私たち株式会社Milestoneは、静岡県沼津市を拠点に、AIシステムとAIチャットボットの開発を手がける静岡のAI会社です。今日は、この「追加できますか」への向き合い方をお伝えします。
先に言っておくと、追加すること自体は、まったく悪いことではありません。 システムは使いながら育てるものであって、最初から完璧な形が分かっていることのほうが、むしろ稀です。
ただ、足す前に決めておくことがあります。それを飛ばすと、気づけば費用が膨らみ、動きが重くなり、誰も全体像を把握していない仕組みができあがる。今日は、その分かれ道の話です。
追加の相談が出てきたときが、いい状態
まず、前向きな確認から。
使われていなければ、要望は出ない
「追加したい」という声が出るのは、その仕組みが実際に使われているからです。誰も触っていない仕組みに、改善の要望が出てくることはありません。
導入したあと、半年間まったく何も言われないほうが、実は危ないのです。沈黙は、満足の表れではなく、無関心であることが多いものです。
使って初めて、分かることがある
そして、最初の要件定義の段階で、必要なものを全部見通すのは、正直に言って不可能です。実際に動かして、お客様が使ってみて、そこで初めて「ここが足りない」が見えてきます。
だから、追加開発が発生することは、最初の設計の失敗ではありません。 育てる過程の一部として、最初から織り込んでおくべきものです。
ただし、無計画に足すと重くなる
一方で、要望が出るたびに足していくと、どうなるか。
機能が増え、画面が複雑になり、費用が積み上がり、そして誰も全体を把握していない状態になります。だから、足し方には順序が要るのです。
要望には、三つの種類がある
相談が来たとき、まず種類を見分けてください。そのうち二つは、開発しなくても済みます。
| 種類 | 例 | 対応 |
| ①教材で済む | 「この質問にも答えてほしい」 | 資料を足すだけ。運用の範囲 |
| ②設定で済む | 「この言い方を変えたい」 | 設定の調整。軽微な作業 |
| ③開発が要る | 「予約まで受けたい」 | 見積もりと計画が必要 |
実は、①が一番多い
現場から出てくる要望の多くは、実のところ①です。「答えられる範囲を広げたい」は、教材を足せば済む話であって、新しく作る必要はありません。
ところが、これを大がかりな「追加開発」だと思い込んで、相談すること自体をためらってしまう会社が、少なくありません。これは、もったいない話です。 月々の手入れでできることを、何か月も我慢して使い続けている。聞けば、その日のうちに解決するかもしれないのに。
まず「これは何番ですか」と聞く
だから、要望が出てきたら、開発側にこう聞いてください。「これは、教材で対応できますか。それとも開発が要りますか」。
この一言で、話は驚くほど早く進みます。 ①なら今月中に直せるかもしれない。③なら、腰を据えて計画する。仕分けができれば、待つべきものと、すぐできるものが分かれます。
足す前に、決める三つのこと
順番があります。
| 決めること | 具体的に |
| ①本当に要るか | 誰が、どれくらいの頻度で使うのか |
| ②いま要るか | 今期か、来期か、その先か |
| ③どこに足すか | いまの仕組みの中か、別に作るか |
①本当に要るか──「あったら便利」と「無いと困る」
要望には、二種類あります。無いと業務が回らないものと、あったら便利なもの。
どちらも価値はありますが、優先順位はまったく違います。「あったら便利」を全部足していくと、費用も複雑さも際限なく増えます。
判断の物差しは、頻度です。月に何回起きるのか。 そして、それに何分かかっているか。この二つを聞くだけで、たいていの要望は仕分けできます。
②いま要るか──時期の判断
必要だとしても、今すぐとは限りません。
半年後に予定している別の変更と一緒にやったほうが、安く済む場合もある。繁忙期を避けたほうがいい場合もある。来年の料金改定を待ってからのほうが、二度手間にならない場合もある。必要性と、時期は別の判断です。
そして、しばらく寝かせると「やっぱり要らなかった」となる要望も、実はかなりあります。一か月置いても、まだ同じことを言われる要望。それが、本物です。
③どこに足すか──同じ場所とは限らない
三つ目が、見落とされがちな論点です。いまのAI窓口に機能を足すのが最適とは限りません。
社内向けの機能なら、お客様向けの窓口とは別の仕組みにしたほうが、かえって整理される場合があります。使う人が違うなら、分けたほうが両方とも使いやすくなることもあります。
一つに詰め込むと、どちらの用途にも中途半端になる。 ここは、開発側に相談する価値のある論点です。
費用は、どう決まるのか
見積もりの中身の話です。
「小さな追加」が、小さいとは限らない
発注側から見て簡単そうな追加が、実は大がかりということがあります。逆もあります。
例えば、答える内容を一つ足すだけなら、教材の更新で済むことが多いのです。一方、外のシステムとつなぐ機能は、見た目が地味でも手間がかかります。
見た目の大きさと、作る手間は比例しません。 だから、まず聞くのが正解です。「これは、どれくらいの規模になりますか」。
手間がかかりやすい追加、そうでない追加
目安として、こういう傾向があります。
比較的軽いのは、答える内容を足す、文言を変える、質問の見本を入れ替える、といった中身の調整です。これらは教材や設定の範囲で収まることが多いのです。
手間がかかりやすいのは、他のシステムとつなぐ、新しい画面を作る、判断の分岐を増やす、といったものです。特に外とつなぐ話は、相手側の都合にも左右されます。
「ボタンを一つ増やすだけ」に見えて、その裏に十の処理が必要なこともあります。だから、まず聞く。それが一番速い方法です。
月額が増えるのか、一度きりか
追加開発の費用には、二種類あります。作るときの費用と、その後ずっとかかる費用です。
新しい機能が増えれば、月々の保守や利用の費用が上がることもあります。一度きりの出費のつもりだったものが、実は毎月の固定費を押し上げていた、ということがないようにしてください。
「初期いくら、月額はいくら変わりますか」。 この二つを、必ずセットで確認してください。
まとめて頼むと、安くなることがある
三つの要望を、三回に分けて頼むより、一度にまとめたほうが安く済む場合があります。作業の段取りが一回で済むからです。
急がないものは、溜めておく。要望のリストを作って、半年に一度まとめて相談する。 これは実務として、かなり有効な進め方です。
実際に、こう相談すればいい
要望が出てきたとき、開発側にそのまま使える聞き方を挙げておきます。
種類を確認するとき
「こういう要望が現場から出ているのですが、これは教材の追加で対応できますか、それとも開発が必要でしょうか」
規模を確認するとき
「これは、どれくらいの規模の作業になりそうですか。初期費用と、月額への影響もあわせて教えてください」
時期を相談するとき
「急ぎではないのですが、次の見直しのタイミングでまとめて相談したい要望がいくつかあります」
具体的に聞くほど、具体的な答えが返ってきます。 「なんとなく気になっている」で終わらせず、この形で聞いてみてください。
要望を、溜めて整理する
その運用の話です。
出てきた要望を、書き留める場所を作る
思いついたときに口で言うだけでは、たいてい忘れられます。共有のファイルでも、ノートでも構わないので、要望を書き留める場所を一つ決めてください。
書くのは三つだけで構いません。何をしたいか。誰が困っているか。どれくらいの頻度で起きるか。
半年に一度、並べて見る
溜まった要望を、半年に一度見直します。すると、面白いことが起きます。
同じ内容が何度も書かれているものと、一度書かれたきりのものに、はっきり分かれるのです。前者は本物の要望、後者はその場の思いつきだった可能性が高いということです。
特別な分析は要りません。時間が、自然と選別してくれます。
上位三つだけ、相談する
そして、優先順位の高い三つだけを開発側に相談します。全部を並べると、どれも中途半端になります。
三つに絞ると、費用も見通しも、一気に現実的になります。 残りは、次の機会に回せばいいのです。
見送った要望の、伝え方
優先順位をつければ、必ず見送るものが出ます。ここの伝え方が、意外と大事です。
「却下」ではなく「順番」として伝える
要望を出した人にとって、何も返事がないのが一番つらいものです。「言っても無駄だ」と思われたら、次から要望は出てきません。
だから、こう伝えてください。「その要望はきちんと記録してあります。今回は〇〇を優先しますが、次の見直しのときに、改めて検討します」。
却下ではなく、順番の問題として伝える。 この言い方なら、出した人も納得しやすいはずです。
理由を、一言添える
「費用が合わないので」「使う人が限られるので」「来期の変更と一緒にやったほうが安いので」。理由が一つあるだけで、受け止め方は変わります。
理由がないと、「聞いてもらえなかった」になります。理由があれば、「そういう事情なら仕方ない」になります。
実現したときは、伝える
そして、実際にその要望が形になったときは、言い出した人に必ず伝えてください。「前に言っていたあれ、できるようになりました」。
この一言が、次の要望を呼びます。 そして次に出てくる要望こそが、その次の改善のもとになる。この循環が回り始めた会社は、強いのです。
追加と、作り直しの分かれ目
ここも大切な判断です。
足しすぎた仕組みは、重くなる
追加を重ねていくと、どこかで限界が来ます。画面が複雑になり、動きが遅くなり、直すたびに別の場所が壊れる。
この段階まで来たら、足し続けるより、作り直すほうが結果的に安いことがあります。
見直しの合図
次のような状態が出てきたら、一度立ち止まってください。
同じような要望への見積もりが、以前より明らかに高くなってきた。一箇所を修正するたびに、別の場所で不具合が出る。何がどこにあるのか、説明できる人が社内にも業者側にもいない。 これらは、土台が限界に近づいている合図です。
作り直しは、失敗ではない
そして、作り直しを検討することは、最初の選択が間違っていたという意味ではありません。
何年も使い続けたからこそ、本当に必要なものが分かった。 その情報を持って作る二回目は、一回目よりずっと良いものになります。最初から正解を引ける人は、いません。
やってはいけない、三つのこと
やってはいけない①：言われるまま、全部足す
社内の声を大切にするのは良いことですが、出てきた要望を全部実現する必要は、ありません。 優先順位をつけるのは、現場ではなく経営の仕事です。
「今回はここまで、これは次回」。この線引きを、誰かが決めなければなりません。
要望のたびに場当たり的に足していく型の失敗は、AIに飛びついた中小企業が、半年後に後悔する3つのパターンにもまとめています。
やってはいけない②：費用を確認せずに、依頼する
「ちょっとだけなので」と口頭で頼み、後から請求を見て驚く。これは双方にとって不幸です。
どんなに小さな追加でも、金額を確認してから。 開発側も、聞かれれば答えます。むしろ、聞かないまま進んで後から揉めるほうが、双方にとって気まずいものです。
やってはいけない③：記録を残さずに、変えていく
何を、いつ、なぜ足したのか。これを残していないと、数年後に誰も理由が分からなくなります。
一行でいいので、記録を残しておく。 担当が代わったとき、業者を変えるとき、そして作り直しを検討するとき。この記録が効いてきます。
「AIを制御する技術」×追加開発──Milestoneの考え方
私たちは、追加のご相談をいただいたとき、まず「本当に必要ですか」と聞くことがあります。
売上だけを考えれば、言われたものを作るほうが早いものです。でも、要らない機能を足して重くするのは、貴社にとっても私たちにとっても損だと考えています。
「それは教材の更新で足りますよ」「それは別に作ったほうが安く済みます」「それは半年後でいいのではないですか」。こういう会話が自然にできる関係でありたい、と思っています。
そして、追加を重ねて限界が近づいてきたら、そう申し上げます。作り直しを提案することは、これまでの仕事を否定することではありません。 一緒に育ててきたからこそ、次に必要なものが見えている。静岡のシステム会社として、そういう関係を地元の会社と長く続けたいと思っています。
よくある質問（FAQ）
Q1．追加開発は、どれくらいの費用がかかりますか？ A．内容によって幅が大きすぎるので、一律にはお答えできません。ただ、繰り返しになりますが、教材や答えの内容を足すだけなら、運用の範囲で済むこともあります。 まず、それが開発を伴うものかどうかを確認してください。
Q2．保守契約に入っていれば、追加も無料ですか？ A．たいていの契約では、別扱いです。保守は「いまある機能を動かし続けること」、追加開発は「新しい機能を作ること」です。契約書で、どこまでが保守の範囲かを確認してください。 ここが曖昧だと、認識がずれます。
Q3．どれくらいの頻度で追加するのが普通ですか？ A．決まりはありませんが、稼働後の数か月は細かい調整が続き、その後は半年に一度くらいの見直しが現実的です。毎月追加している状態は、最初の設計に無理があったサインかもしれません。
Q4．要望が現場から次々出てきて、困っています。 A．良い状態です。ただ、全部に応える必要はありません。要望を書き留める場所を作り、半年に一度まとめて見る。 それだけで、現場も「聞いてもらえている」と感じますし、経営側も落ち着いて判断できます。
Q5．他社が作ったシステムに、追加を頼めますか？ A．可能な場合と、難しい場合があります。仕組みの作りと、元の業者との契約次第です。まず、いまの契約書と、システムの構成を確認するところから始めてください。 拝見すれば、判断の見当はつきます。
Q6．追加すると、既存の部分が壊れませんか？ A．その可能性はゼロではありません。だから、追加後は既存の機能も確認してください。 よく使う質問をいくつか投げて、前と同じ答えが返るか。この確認を、開発側にも依頼しておくと安心です。
Q7．いつまで追加を続けられますか？ A．土台が耐えられる範囲までです。ただ、その限界は使い方によって大きく変わります。見積もりが高くなってきた、直すと別が壊れる。 この二つが出てきたら、相談どきです。
Q8．追加するか、作り直すか迷っています。 A．判断材料をお出しできます。いまの構成、これまでの追加履歴、これからやりたいこと。この三つが分かれば、どちらが安く済むかの見当はつきます。静岡のAI会社として、第三者の目で見ることも可能です。
Q9．社長の思いつきと、現場の要望、どちらを優先すべきですか？ A．どちらが偉いかではなく、頻度と影響で判断してください。 現場が毎日困っていることと、社長が月に一度思い出すこと。前者のほうが、たいてい効果は大きいものです。ただし、経営の方向に関わる判断は、社長が決めるべきです。
Q10．追加を頼んだら、断られました。 A．理由を聞いてみてください。技術的に難しいのか、いまの土台では無理なのか、費用に見合わないと判断されたのか。理由を説明してくれる相手なら、信頼できます。 代替案まで出してくれるなら、なお良いでしょう。
Q11．要望を書き留める場所は、どんな形が良いですか？ A．凝った仕組みは要りません。表計算のソフトに一行ずつ書くだけでも十分です。大切なのは形式ではなく、書く習慣が続くことです。 続かない仕組みは、無いのと同じになってしまいます。
Q12．何から相談すればいいですか？ A．いま出ている要望を、そのまま見せていただくのが一番早いです。静岡のシステム会社として、その場で種類分けと優先順位の見当をお伝えします。
育てるのと、膨らませるのは違う──株式会社Milestone
「これも追加できますか」は、使われている証拠でした。
でも、言われるまま足していくと、費用は膨らみ、仕組みは重くなり、誰も全体を把握できなくなります。
本当に要るか。いま要るか。どこに足すか。 この三つを決めてから足す。そして要望は溜めておき、半年に一度、上位三つだけを相談する。
そして、足しすぎて重くなったと感じたら、作り直しも選択肢に入れる。育てることと、膨らませることは、違います。
私たちMilestoneは、静岡のAI会社・システム会社として、静岡県沼津市を拠点にAIシステムとAIチャットボットの開発と導入支援を行っています。「AIを使う」のではなく「AIを制御する」を核に、作った後の育て方まで、一緒に考えます。
こんなご相談を歓迎しております
- 出てきた要望を、優先順位をつけて整理したい
- 追加開発の見積もりが妥当か見てほしい
- 他社が作ったシステムへの追加を相談したい
- 追加を続けるか、作り直すか判断したい
- 要望を溜める仕組みから作りたい
訪問対応（静岡県内・隣接エリア）、オンライン対応（全国）、どちらでも可能です。静岡のAI会社として、県内は対面でも伺えます。30分ほどお話を伺うだけで、いま足すべきものと、待ったほうがいいものは、たいてい見分けられます。
▶ ご相談・お問い合わせ https://milestone-net.com
「資料だけ見たい」「他社と比較検討中」というライトな段階のご連絡も、歓迎しております。
「やりたいをできるに、できるをできたに」。中小企業の長期パートナーとして、責任を持って伴走します。
株式会社Milestone（マイルストーン） 代表取締役 大石 湧斗（おおいし ゆうと） 所在地：静岡県沼津市
中小企業向けAIシステム開発・導入支援。「AIを使う」のではなく「AIを制御する」を経営の核に据え、業務にフィットしたAI導入を伴走型でご提案。静岡県全域と隣接エリアで対面対応可能。「やりたいをできるに、できるをできたに」をミッションに、貴社の長期パートナーとして責任を持ってご支援します。
