ベンダ（ハードウェア・ソフトウェア）でのAI活用術

ベンダ（ハードウェア・ソフトウェア）に、そもそもAIは必要なのか

自社で製品を持つベンダの業務には、AIを入れて効くものと、入れても変わらないものがあります。見分けるには、その判断が月に何回戻ってくるか、一度取り違えたとき誰にどんな形で跳ね返るかの二つを数えてみてください。

片方だけ大きい業務に手を入れても、労力には見合いません。 二つとも大きい業務 から並べるのが現実的です。

ITベンダーでこの二つが両方大きいのは、答えが製品の側にあり、それを顧客ごとに当て直す業務です。引き合いごとの提案資料と見積は、エディションと保守年数の組み合わせを毎回組み直します。構成を一つ落とせば、導入後に追加の請求か持ち出しかの話になります。

顧客から上がる不具合報告の仕分けと優先度付けも、どの版で起きた症状かを取り違えると、直す順番が入れ替わります。サポートに届く問い合わせを中身で分類する作業も同じです。

一方、次の版に何を載せるかの決定は、AIに寄せてはいけない業務です。開発に割ける人数、前の版で大口顧客に約束した機能、競合の出方。載せる順番は、 社内の事情と約束の重さ を天秤にかける仕事だからです。重い不具合を顧客に公表するかどうかも、同じ理由で人が背負います。

どこに線が引けるかは、扱う製品によって変わります。売り切りで保守を続ける製品と、契約を更新しながら使う製品とでは、同じ判断が戻る周期が違うからです。まず自社の仕事を工程に分け、繰り返しの集まる場所を見るところからです。

製品企画から品質・改善まで、負荷が大きいのはどの工程か

ベンダの仕事は、製品を作る流れと、顧客ごとの商談の流れが別々に動きます。部門ごとに並べ直すと、答えが製品の側で決まっている作業と、相手の環境しだいで毎回変わる作業の差が見えてきます。

手が止まりやすいのは知財・ライセンスです。 製品は一つでも、使用許諾は顧客の数だけ結ぶ ことになるからです。

顧客の購買部門は自社の基本契約の雛形を出してきます。そこに製品の使用条件を載せると、再頒布の可否、監査を受ける範囲、サポートが切れたあとの扱いといった項目が、毎回少しずつ違う書き方でぶつかります。

神経を使うのは、 答えを社内から集める往復 のほうです。この機能に外部の部品が含まれるか、この版の保守をいつまで続けるかは、開発の担当者しか知りません。法務が開発に問い合わせ、営業が返答を待つ間に、顧客の締切が来ます。

ここが整うと、提案・見積の段階で条件を言い切れるようになり、契約直前の差し戻しが減ります。

極小と置いた導入・立ち上げは、顧客がすでに使っている環境に自社製品を繋ぎ込む場です。同じ製品でも、相手の設備の古さや、止められない時間帯によって手順が変わります。ここは人が目の前で決めていく工程です。

ベンダ（ハードウェア・ソフトウェア）で最初に取り組むべきAI活用、3つ

先の二つの軸で並べたとき上位に来たのは、製品そのものを考える仕事ではなく、製品の周りで同じ判断が毎日戻ってくる仕事でした。商談とサポートの現場に集まる次の3つから手をつけます。

顧客の要件一覧を、製品構成と見積の案に直す

提案・見積の工程です。顧客から要件の一覧や仕様の照会が届き、営業が引き合いとして登録した時点で動きます。AIは自社の製品仕様書、価格表とライセンスの数え方、過去に同じ業種へ出した提案書と見積を参照します。要件を一行ずつ、標準機能で足りるか、追加が要るか、対応できないかに当てて構成の候補を組みます。

出てくるのは、提案書の下書きと構成ごとの見積の案です。引き合いの保管先に文書として残り、要件と仕様の対応表が添えられます。似た案件の見積を探して数字を打ち替えていた作業が、組まれた構成から外すものを決める作業に変わります。

値引きの幅と、対応できないと出た要件を持ち帰るかどうかは、担当営業が決めます。 ライセンスの数え方が顧客の使い方に合っているか は、受注前に製品管理の担当者が確かめます。

不具合報告を、版と影響の広さで順位づける

サポート窓口や代理店から不具合報告が受付の一覧に登録されると動きます。品質・改善の工程です。AIが読むのは、報告の本文と、版ごとの変更履歴、過去に同じ症状で重さを決めたときの記録です。再現手順が書かれているか、どの版から出ているか、回避策があるかを見て、重さの区分と引き取るチームを当てます。

結果は開発の課題一覧に1行として増え、最も重い区分が付いた分だけ担当のリーダーに業務チャットで届きます。いまは受け付けた順に目を通して仕分けているため、重い報告ほど後ろに埋もれます。 埋もれていた分が先に見える 形になります。

回避策が本当に使えるか、再現するかは、サポートの担当者が報告者に確かめ直します。その不具合を顧客に公表するかどうかは、品質保証の責任者が持つ判断です。

同じ質問が集まる箇所を、製品側の課題として立てる

サポートの工程は、週ごとの区切りで動かします。AIが見るのは、その週に閉じた問い合わせの記録と、製品の手引きの目次、前の週までの分類の一覧。一件ずつを、製品のどの機能についての質問か、手引きのどこを読めば済んだのかという二つの軸に当てて数えます。

出力は、分類ごとの件数と代表的な問い合わせ文が並んだ週次の傾向表です。質問が集まっているのに手引きに記述がない箇所は、改訂の候補として別に挙がります。月末にサポート担当が記憶を頼りに報告していたところが、 週の頭に表が出ている 形に変わります。

集まった質問が製品の作りの問題か、書き方の問題かの切り分けは、サポートの責任者が見ます。挙がった候補を手引きに反映するかは、製品の管理担当が決めます。

業務に組み込むまでの4ステップ

不具合報告に順位をつける例で、4ステップを追います。新しい仕組みを開発する話ではなく、報告の受け口と、版の記録と、開発の課題一覧をつなぐ作業です。

1. 使う情報がどこにあるかを決める

順位をつけるのに要るのは、報告そのものだけではありません。

• 出荷済みの版と、どの顧客がどれを使っているかの対応表
• 保守契約ごとの対応期限
• 過去に重さを決めたときの判断の記録

どれも今ある書類です 。散らばっているなら、置き場所を一つに決めるところから始めます。

2. 何をきっかけに動かすかを決める

報告が受付の一覧に登録された時点を、動き出す合図にします。担当者が手の空いたときに見に行く形では、問い合わせの多い日ほど後回しになり、重い報告ほど遅れます。代理店からメールで届く分も、同じ一覧に入る道筋を先に作ります。

3. 判断の基準を設定しておく

この工程がいちばん手間です 。ベテランが報告を読んだ瞬間にやっている重さの見立てを、文章に起こします。たとえば次のような基準です。

• 保守の対象から外れた版でしか出ない症状は、重さを上げず、更新の案内として返す
• 回避策があるものは、手順を書けるなら一段下げる
• 一社からしか出ていなくても、その版を使う顧客が多ければ下げない

こうした線引きは、いまも報告が来るたびに口頭で確かめ合っているはずです。書き出すのは一度で済みます。

4. 結果の戻り先と、確認する人を決める

戻り先は、開発が毎朝見ている課題一覧です。重さの区分と根拠の抜粋が入った行として増え、最も重い区分だけ担当のリーダーに業務チャットで届きます。

朝の打ち合わせで、前日に付いた区分をサポートの責任者が上から確かめ、直した跡を残します。

先に知っておきたい、つまずきやすい3か所

• 価格表とライセンスの数え方を改定したとき、参照先の差し替えを忘れると、AIは古い決まりのまま構成を組み続けます。見積の案に 改定日を印字させておき 、改定した人が参照先も直す担当を兼ねる形にします。
• 版の付け方が製品ごとに違うと、不具合報告がどの版の話か当てられず、区分の付かない行が並びます。顧客ごとの個別対応版は最初から対象外と決め、人が見る列を分けておきます。
• 電話で受けた問い合わせが記録に残らないと、いちばん多く集まっている質問ほど週次の表に出てきません。通話のあとに 要点を同じ一覧に書き残す ところまでを、窓口の手順に組み込みます。

ベンダ（ハードウェア・ソフトウェア）のAI活用は、どこから考えればいいか

この記事で引いた線は、答えが製品の側にあって顧客ごとに当て直すだけの作業と、社内の事情や約束の重さを天秤にかける判断との間にありました。先に挙げた3つは、 いずれも前者 です。製品が変わっても判断の形が変わらず、取り違えが請求や修正の順番として戻ってくるからです。

3つを並行して進める必要はありません。引き合いが立て込んでいるなら見積の下書きから、報告が積み上がっているなら不具合の順位づけからで十分です。必要なのは過去に出した見積と製品の版の記録で、 どちらも買い足すものではありません 。