エージェントの直しを頼んで、2週間待たされていませんか。Agentforceの設定と開発の線引きとは、機能でできるかどうかの区別ではありません。その変更を誰がどのくらいの頻度で直し続けられるかの区別です。 Agentforceは機能の追加が続いている製品のため、本記事の記述は2026年9月時点で確認できる範囲に限っています。
なお公式の案内では、2026年7月13日の週から、エージェントの新規作成先がAgentforce Builderという新しい画面に一本化されるとされています。この画面には、低コードで組み立てる表示と、スクリプトで書く表示の両方が用意されており、併用が想定されています。
※参考記事はこちら
本記事で扱うのは、直しの依頼が情報システムに滞留する状態の見分け方と、担い手を決める判断の順番です。判断に使う材料、作業の分け方、そして移した後に見る数字までを、1社の例を通して解説します。
当社はSalesforce公式コンサルティングパートナーとして、 ソリューション営業に特化したAgentforce導入・定着支援を 行っています。
- どのユースケースから始めればいいか分からない
- 設定は完了したが現場に定着しない
- ナレッジ設計から一緒に考えてほしい
というお悩みがあればお気軽にご相談ください。 1ユースケース×3ヶ月のスモールスタートプランから対応しています。
この記事を書いた人
合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援と、Agentic CRM設計支援を提供している。
設定を情報システムに預けたまま止まる3つの場面
搬送装置のメーカーでは、従業員118名のうち営業が10名、営業企画1名、情報システムの担当1名という体制で事業を続けてきました。この企業は説明のための架空の設定であり、実在の企業ではありません。エージェントの設定はすべて情報システムの担当1名が抱えており、営業から出た直しの依頼は月に14件、反映までは平均16日かかっています。「開発が要る話なのか、設定で済む話なのか」を誰も判断できないまま、依頼だけが積み上がってきました。そこでここでは、この会社を例に、設定を情報システムに預けたまま止まる3つの場面を整理します。
止まる原因を担当者の処理の速さに求めても、依頼の列は短くなりません。止まるのは人手の不足ではありません。直せる人が1名しかいない構造です。
場面①直しの依頼が数週間待ちになる
1つ目は「直しの依頼が数週間待ちになる」場面です。営業から出た変更が、順番待ちの列に並びます。
待ちが生まれるのは、依頼の受け口が1本しかないためです。項目を1つ足す作業も、外部の仕組みとつなぐ作業も同じ担当者の同じ列に入るため、5分で終わる依頼が3日かかる依頼の後ろに並びます。作業の重さで列を分けていないと、営業は依頼をためらうようになります。
この搬送装置のメーカーでは、依頼から反映までが平均16日でした。営業企画の担当が3か月分を記録したもので、最短は2日、最長は41日です。作業に使った時間は短いのに、待ち時間が大半を占めていました。同じ列に並んでいる限り、急ぎかどうかは順番に反映されません。
日数を記録するときは、作業に使った時間と待っていた時間を分けて数えましょう。待ち側が半分を超えているなら、担当者の作業を速くしても日数は短くなりません。
場面②依頼するほどではない直しが放置される
2つ目に挙げるのは、依頼するほどではない直しが放置される場面です。小さな違和感が、そのまま残ります。
放置されるのは、依頼のコストが変更の価値を上回るためです。回答の言い回しが少し硬い、参照する文書が1本古い、といった直しは、依頼書を書いて2週間待つほどのものではありません。営業は不便を抱えたまま使い続けるか、使うのをやめるかを選ぶことになり、エージェントの精度が上がらない原因の多くは、この放置された小さな直しにあります。なお、画面での操作の流れは、設定の手順の記事で詳しく解説しています。
先ほどの会社では、営業へ聞き取りをしたところ、依頼していない直したい点が21件挙がりました。いずれも所要は数分の作業です。依頼されなかった理由は、すべて「頼むほどではないから」でした。
聞き取りは、営業10名に「直したいが頼んでいない点」を1つずつ挙げてもらう形で足ります。挙がった件数が月の依頼件数を上回るようであれば、受け口が重すぎます。
場面③直せる人が1名しかいない
3つ目は「直せる人が1名しかいない」場面です。担当者が不在の期間、変更が完全に止まります。
止まるのは、設定の内容が他の人に見えていないためです。どの項目が何のために置かれているかは、作った本人の頭の中にあります。引き継ぎの資料を用意していても、なぜその条件にしたかという判断の理由までは残りません。担当者が異動や退職をした時点で、変更の手段が失われます。
この会社では、情報システムの担当が月に22時間を依頼の対応に使っていました。休暇を取った週は依頼が滞留し、翌週の作業量が2倍になっています。営業企画の担当は、この構造が続かないと判断しました。
見るべきは依頼の件数ではありません。担当者が不在だった週に、変更が1件も入らなかったかどうかです。
設定の可否をツールの機能で判断できない3つの理由
ここまでの3つの場面は、いずれも「どこまでを設定で済ませられるか」という問いにつながります。多くの解説は、宣言的な設定でできることとコードが要ることを機能の一覧で分けています。ところがこの分け方では、誰が持つかが決まりません。そこでここでは、設定の可否をツールの機能で判断できない3つの理由を整理します。
この会社でも「これは開発の案件でしょうか」という確認が、依頼書に添えられていました。作れるかどうかでは線を引けません。決めるのは直す頻度です。
| 比較の観点 | 作れるかで線を引く場合 | 直す頻度で線を引く場合 |
|---|---|---|
| 判断の材料 | 機能の一覧 | その変更が起きる回数 |
| 決まること | 実装の方法 | 担い手 |
| 担当者が変わったとき | 引き継ぎ資料に頼る | 持ち手が複数いる |
| 小さな直し | 依頼の列に並ぶ | その場で直る |
| 測る対象 | 実装できたかどうか | 開発を通さずに済んだ割合 |
理由①作れることと持てることは違うから
まず押さえたいのは、設定の画面で作れることと、その設定を直し続けられることが別だという点です。作れた時点では、誰が直すかは決まっていません。
違いが出るのは、作るのが一度きりで、直すのが繰り返しだからです。複雑な条件分岐を設定で組めば、その時点では動きます。ところが半年後に条件を1つ足そうとしたとき、組んだ本人以外には構造が読めません。作れた事実は、持てる証拠にはなりません。
この搬送装置のメーカーでは、以前に情報システムの担当が条件分岐を12段組んだ設定がありました。営業から変更の依頼が来たとき、担当者本人も読み解くのに半日かかっています。作った当人にとっても、持ちにくい形でした。
作る前に決めておくのは、実装の方法より先に、直す人の名前です。名前が空欄のまま作った設定は、読める人がいない状態のまま残ります。
理由②機能の一覧に業務の変わり方が出ないから
次に、機能の一覧には何が作れるかしか書かれていません。自社の業務が年に何回変わるかは、どの一覧にも載っていません。
一覧で決められないのは、変更の頻度が会社ごとに違うためです。商材の入れ替えが年1回の会社と、四半期ごとの会社では、同じ設定でも直す回数が4倍違います。機能の側からは、この違いが見えません。判断の材料は、自社の業務がどう変わってきたかの実績にあります。
先ほどの会社では、過去2年の変更の記録を種類別に数えました。商材の追加が年8回、営業の体制変更が年3回、価格の条件の変更が年11回です。最も多いのは価格の条件で、ここを営業側で直せる形にする判断につながりました。
数えるのは、過去2年に実際に起きた変更だけです。予定や要望まで混ぜると回数が膨らみ、移す範囲を決められなくなります。
理由③同じ要件でも直す頻度が違うから
最後に、同じ要件に見えるものでも、直す頻度は会社ごとに分かれます。外から見た機能の名前は、扱いを決める材料になりません。
分かれるのは、要件の背後にある業務が違うためです。外部の仕組みとつなぐ処理でも、つなぎ先が固定なら作った後はほとんど触りません。一方、参照する文書の入れ替えは毎月起きます。前者は開発に渡して問題がなく、後者は営業側に置かないと動きません。定義をコードで管理する側の判断については、Agent Scriptの記事をご確認ください。
この会社では、同じ「文書の差し替え」という作業が、仕様書では年2回、価格表では月2回でした。前者は情報システムに残し、後者だけを営業企画へ移しています。同じ名前の作業を、2つの担い手へ割った例です。
分ける単位は、作業の名前ではありません。その作業が過去2年に何回起きたかです。名前が同じでも、回数が違えば担い手も変わります。
設定を誰が持つかを決める4つの基準
前章の3つの理由は、いずれも「頻度で決まる」という一点に行き着きます。ただし頻度だけでは、営業側へ移してよいかまでは決まりません。月に2回起きる変更でも、間違えたときに社外へ影響が出るなら、営業側には置けないからです。基準を1つずつ別々に当てると答えが分かれるため、4つを順に重ねた結果で担い手を決めます。この4つは、営業企画のような非専任の担当が持つことを想定した並びです。そこでここでは、設定を誰が持つかを決める4つの基準を整理します。
担い手は役職や所属では決まりません。誰が持つかは4つの基準で決まります。頻度、業務知識、影響、確かめ方です。
基準①どのくらいの頻度で直すか
1つ目は「どのくらいの頻度で直すか」という基準です。年に何回その変更が起きるかを見ます。
これを最初に置くのは、頻度が高いほど待ち時間の損失が大きいためです。月2回起きる変更を依頼の列に並べれば、年24回の待ちが発生します。年1回しか起きない変更であれば、2週間待っても業務は続けられます。移す優先度は、頻度の高い順に決めて構いません。
この搬送装置のメーカーでは、価格の条件の変更が年11回で最多でした。1回あたり16日待つと、年間で176日ぶんの遅れになります。商材の追加は年8回、営業の体制変更は年3回で、いずれも価格の条件を下回りました。
頻度は回数だけで見ず、待ち日数を掛けた日数で並べましょう。年1回でも決算や商戦の直前に集中する変更は、この掛け算で上位に来なくても先に移す対象になります。
基準②直す判断に業務の知識が要るか
2つ目に挙げるのは、直す判断に業務の知識が要るかという基準です。何をどう直すかの判断が、業務の側にあるかを見ます。
業務の知識が要る変更は、情報システムに置くと二度手間になります。価格の条件をどう変えるかは、営業が決めることです。決めた内容を依頼書に書き、受け取った側が設定へ翻訳し、できたものを営業が確かめる工程が挟まります。工程が増えるほど誤解も待ち時間も膨らむため、決める人が直せる形が最も速くなります。
先ほどの会社では、価格の条件の依頼書が平均で2往復していました。書かれた内容だけでは意図が伝わらず、確認のやり取りが挟まっています。営業企画が直接直す形にした後、往復は0になりました。
依頼書の往復の回数を数えましょう。往復が多いほど、翻訳の工程が無駄です。
基準③間違えたときの影響がどこまで及ぶか
3つ目は「間違えたときの影響がどこまで及ぶか」という基準です。誤りが外へ出るか、内側で止まるかを見ます。
影響で分けるのは、取り返しのつく範囲かどうかが判断を変えるためです。回答の言い回しを直して不自然になっても、気づいた人が直せば済みます。一方、外部の仕組みへ書き込む処理を誤れば、相手側のデータまで変わります。影響が外へ及ぶ変更は、頻度が高くても営業側に置きません。影響の範囲をどう見積もるかは、影響範囲の設計の記事で扱っています。
この会社では、変更を影響の及ぶ範囲で3つに分けました。自部門で止まるもの、社内の他部門に及ぶもの、社外に及ぶものの3つです。営業企画へ移したのは、1つ目の範囲だけです。
分けるときに見るのは、誤りに気づいた人が自分で戻せるかどうかです。社内の他部門に及ぶ範囲は、相談の場を挟めば営業側でも扱えます。
基準④直した結果を自分で確かめられるか
4つ目に挙げる基準は、直した結果を自分で確かめられるかどうかです。直した人が、意図どおりかを判定できるかを見ます。
確かめられることが要件になるのは、判定できない変更を任せると、誤りに誰も気づかないためです。回答の内容が適切かどうかは業務を知っている人にしか判定できず、逆に処理の速度や連携の成否は、業務の側からは判定できません。判定できる人と直す人を一致させると、確認の工程が1つ減ります。
この搬送装置のメーカーでは、営業企画の担当が直した後に自分で試す手順を定めました。想定する質問を5つ用意し、返る内容を読んで確かめる形です。1件あたり10分ほどで済んでいます。
確かめ方は、直す前に「何が返れば成功か」を1行書いておくと決まります。書けない変更は、直した後にも判定できません。
設定で分かれる3種類の作業
前章の4つの基準を実際の作業に当てると、担い手は3つに分かれます。すべてを営業側へ移すことも、すべてを情報システムに残すことも、現実には成立しません。3つに分かれるのは、影響が自部門で止まるか、他部門へ及ぶか、社外へ出るかという違いによるものです。Agentforceでできることの範囲を押さえたうえで、作業を分類します。そこでここでは、設定で分かれる3種類の作業を整理します。
作業の分け方は難易度の高さでは決まりません。作業は3種類に分かれます。全部を一方に寄せる形からは外れます。
種類①営業部門が持つ作業
1つ目は「営業部門が持つ作業」です。頻度が高く、業務の知識が要り、影響が自部門で止まる作業を指します。
ここに入るのは、参照する文書の差し替え、回答の言い回しの調整、条件の値の変更といった作業です。いずれも判断の材料が業務の側にあり、誤っても気づいた人が直せます。営業企画のような、営業の業務を知りながら手も動かせる担当が向いています。
搬送装置のメーカーでは実際に、価格の条件の変更、案内の文面の調整、参照する文書の差し替えの3つを営業企画へ移しました。月14件の依頼のうち11件がここに入ります。移した後、この11件は依頼の列に並ばなくなりました。
移す順番は、影響が自部門で止まる作業からです。誤りが出ても営業のなかで気づいて直せるため、確かめ方の設計を軽く済ませられます。
種類②情報システムへ相談する作業
2つ目に挙げるのは、情報システムへ相談する作業です。判断は業務の側にあるが、影響が他部門へ及ぶ作業が該当します。
相談の形にするのは、決めるのと実装するのを分けるためです。参照できる範囲を広げる変更は、営業が必要性を判断し、権限の設計を情報システムが確かめる二段構えになります。片方だけでは決まらないため、依頼書を往復させるより同じ場に集まるほうが速く終わります。
先ほどの会社では、月1回30分の打ち合わせをこの相談の場にしました。持ち込まれるのは、営業側で直す月11件のうち2件ほどです。相談の場で権限の設計だけを確かめ、設定は営業企画がその日のうちに直しています。以前は依頼書で2往復していた内容です。
相談の場は、月1回30分あれば足ります。持ち込まれる件数が営業側で直す件数を上回るようであれば、移した範囲の切り方が合っていません。
種類③開発に渡す作業
3つ目は「開発に渡す作業」です。影響が社外へ及ぶ作業と、戻せない処理を含む作業が該当します。
渡す理由は、失敗の代償が大きいためです。外部の仕組みとつなぐ処理、大量の記録を一度に書き換える処理は、誤ると元へ戻せません。これらは頻度が低いことが多く、依頼の列に並んでも業務は続けられます。開発へ渡す範囲を狭く保つほど、待ち時間の総量は減ります。
この会社では、月14件のうち3件がこの範囲に残りました。基幹システムとの連携が2件、過去データの一括更新が1件です。この3件については、以前と同じ依頼の形を続けています。急ぎの案件はなく、月1回の相談の場で着手の順番を決めました。
開発へ渡す範囲は、社外へ影響が出るものと、戻せない処理を含むものの2つに限れます。この2つ以外を渡している依頼が残っていれば、移す候補として見直せます。
設定の判断をAIに任せる3つの線引き
前章で作業の担い手が決まりました。次に決めるのは、変更の判断をどこまで機械に渡すかです。影響範囲の確認まで機械に任せれば、営業側で持てる範囲は広がるでしょう。ただし本番へ入れる操作まで渡すと、誤りが誰の目にも触れないまま反映されます。そこでここでは、設定の判断をAIに任せる3つの線引きを整理します。
任せる範囲は自動化の技術では決まりません。任せてよいのは影響範囲を出すところまでです。本番へ入れるかは人が決めます。
線引き①変更の影響範囲を出すところまで任せる
1つ目は「変更の影響範囲を出すところまで任せる」ことです。直そうとしている箇所が、どこに効いているかを示させます。
ここを任せるのは、影響範囲の確認が最も時間のかかる作業だからです。1つの項目を変えたときに、どの回答が変わるかを人が追うには、設定を横断して読む必要があります。機械に任せれば、参照している箇所を一覧で返せるため、営業企画のような非専任の担当でも判断できます。
この搬送装置のメーカーでは、変更の前に影響範囲の一覧を出す手順を入れました。1件あたり数十秒で返り、営業企画の担当はその一覧を見てから直しています。3か月で、想定外の箇所へ影響した事例はありません。
影響範囲を先に出しましょう。読む作業が消えれば、非専任でも持てます。
線引き②直し方の候補までを任せる
2つ目に挙げるのは、直し方の候補までを任せることです。どう直すかの案を出させ、選ぶのは人にします。
候補までにするのは、選択肢を知らないと直し方が偏るためです。同じ要件でも、条件を足す方法と参照先を変える方法があり、後の直しやすさが変わります。案を並べて示せば、非専任の担当でも持ちやすいほうを選べます。ただし選んだ理由を残さないと、次に直す人が同じ判断をできません。
先ほどの会社では、直し方の候補を2つまで出す形にしました。営業企画の担当が選び、選んだ理由を1行で残しています。営業側で直す月11件の3か月分にあたる33件の記録が残り、後任への引き継ぎの材料になりました。
候補は2つまでに絞ると、選ぶ時間が延びません。3つ以上並べると比較の作業が増え、直すことよりも選ぶことに時間がかかります。
線引き③本番へ入れるかは人が決める
3つ目は「本番へ入れるかは人が決める」ことです。反映の操作を、自動にしません。
自動にしない理由は、誤りが誰の目にも触れずに広がるためです。設定の変更は、営業10名が使う回答に一斉に効きます。反映の前に人が1回見る工程を残せば、明らかな誤りはそこで止まります。確認にかかるのは数分で、待ち時間としては無視できる長さです。
この会社では、反映の前に想定する質問5つを試す手順を定めました。1件あたり10分ほどで終わり、3か月のあいだにこの工程で止めた誤りが4件あります。いずれも文面の言い回しに関する誤りで、営業へ届く前に直しました。
工程を残すかどうかは、確認にかかる10分と、誤った回答が営業10名へ一斉に届く影響を比べて決めます。この会社では、比べるまでもないという結論でした。
設定の対象を絞って始める4つのステップ
ここまでで、担い手の基準、3種類の作業、任せる範囲がそろいました。あとは着手の順番です。すべての作業を一度に振り分けようとすると、分類の議論が長引いて着手が遅れてしまいます。依頼を種類に分けるところから始めれば、数週間で動き始めるでしょう。そこでここでは、設定の対象を絞って始める4つのステップを整理します。
着手の順番は作業の難しさでは決まりません。最初にやるのは権限を渡すことではありません。依頼を種類に分けることです。
ステップ①直しの依頼を4種類に分ける
最初に取り組むのは、過去の依頼を並べて作業の単位で分類することです。件数が多いか少ないかを見る前に、種類で分けます。
分類から始めるのは、どこに集中しているかが見えないと移す対象を選べないためです。依頼を項目・条件・文面・接続の4つに分ければ、多くの会社で偏りが出ます。過去3か月分を数えれば傾向は十分に見え、それ以上さかのぼる必要はありません。
この搬送装置のメーカーでは、営業企画の担当が3か月分の依頼42件を分類しました。条件が19件、文面が14件、項目が6件、接続が3件です。所要は半日ほどでした。
分類の作業は半日で終わります。定義を詰めることに時間をかけるより、判断に迷った依頼を「その他」へ置いて先へ進めるほうが、偏りは早く見えてきます。
ステップ②最も多い種類を営業側へ移す
分類が終わったら、次に決めるのは最初に移す1種類です。件数の最も多い種類だけを対象にします。
1種類に絞るのは、移す範囲が広いほど確かめ方の設計が重くなるためです。条件の変更だけを移すのであれば、確かめる観点も条件に関するものだけで済みます。複数の種類を同時に移すと、想定する質問の数が増え、準備が終わりません。
先ほどの会社では、最も多い条件の変更19件だけを最初の対象にしました。移すまでに要したのは3週間です。効果を確かめた後、文面の調整14件を追加しています。
次の種類へ広げる合図は、移した種類の依頼が1か月続けて営業側で完結したときです。1件でも情報システムへ戻る依頼が残っているうちは、範囲を広げても列は短くなりません。
ステップ③移した範囲の確かめ方を決める
移す種類が決まったら、そのうえで直した後に何を試すかを定めます。確かめ方は、移す作業より先に決めておきます。
直した本人が判定できることは、担い手の4つ目の基準にあたります。判定の手順がなければ、この基準を満たせません。想定する質問を5つ用意し、返る内容を読む形が最も簡単で、追加の仕組みも要りません。確かめ方を仕組みとして用意する方法は、テストの用意の記事をご参照ください。
この会社では、条件の変更について想定する質問を5つ定めました。営業企画の担当が作り、営業2名が確認しています。1件あたりの確認は10分ほどで収まりました。
質問の数は5つで足ります。増やすほど確認の時間が延び、10分を超えると直すこと自体が後回しになります。
ステップ④残した範囲の依頼の出し方を決める
最後に決めるのは、開発へ渡す作業の窓口です。移した後に残る依頼だけを対象に、出し方をあらためて定めます。
定め直すのは、移した後に残る依頼の性質が変わるためです。以前は小さな直しと重い作業が同じ列に並んでいましたが、移した後に残るのは重い作業だけです。列が短くなるぶん、1件あたりに使える時間は増えます。依頼書の書式も、重い作業に合わせて作り直すほうが噛み合います。
この搬送装置のメーカーでは、残る月3件について、月1回の相談の場で扱う形にしました。着手から7週間で運用に入り、営業企画1名で計42時間を要しています。依頼から反映までの日数は、平均16日から平均3日へ変わりました。
以上が、設定の対象を絞って始める4つのステップでした。4つを順に踏めば、依頼の件数を変えないまま、待ち時間だけを短くできます。
設定を営業部門へ移すときの3つの落とし穴
前章の4つのステップは、順番どおりに進めば7週間ほどで運用に入ります。ところが途中で元へ戻る会社もあり、戻り方には型があるものです。いずれも早く広げようとして選んだ手が原因で、途中まで進めた分類や確かめ方の設計まで使われなくなってしまいます。移す作業よりも、移した後の3か月で何が起きるかを先に見ておくほうが、戻りを防げるでしょう。そこでここでは、設定を営業部門へ移すときの3つの落とし穴を整理します。
つまずく原因は担当者の技量では決まりません。移す範囲を決めずに権限だけ渡すと、直せる人は増えません。
落とし穴①すべてを設定だけで作ろうとする
1つ目は「すべてを設定だけで作ろうとする」ことです。開発を避けるために、設定の画面で無理に組みます。
無理が出るのは、組んだ構造が読めなくなるためです。条件分岐を何段も重ねれば動きはしますが、半年後に1つ足そうとしたときに全体を読み直すことになります。開発を避けたつもりが、持ちにくさという形で戻ってくるわけです。開発に渡すべき範囲を残すほうが、全体としては軽くなります。
先ほどの会社の条件分岐12段の設定も、同じ理由で残っていたものです。移す設計にあたっては、価格の条件と文面の条件を別々に扱う形へ作り直しています。作り直した後は、営業企画の担当が単独で直せるようになりました。
読み直せるかどうかで、組み方を選びましょう。判定は、作った本人以外の1名に見せて、意図を説明できるかを確かめれば済みます。
落とし穴②移す範囲を決めずに権限だけ渡す
2つ目に挙げるのは、移す範囲を決めずに権限だけ渡すことです。編集できる状態にすれば動き出すと考えます。
動き出さないのは、何を直してよいかが分からないためです。権限を渡された営業企画の担当は、影響が読めない変更に手を出せず、結局これまでどおり情報システムへ相談することになります。渡すのは権限より先に、直してよい範囲と確かめ方の2つです。
この会社でも、着手の初期に編集の権限だけを先に渡した時期がありました。営業企画の担当が自分で直したのは文面の調整だけで、条件の変更はすべて以前と同じ依頼の形へ戻っています。直してよい範囲を4種類に書き出してから、条件の変更も自分で直すようになりました。
定着まで伴走してほしい場合は、この順番を支援先と確かめてください。権限の付与から始める提案が出てきたら、範囲と確かめ方の設計がどこに入るのかを聞き直す場面です。
権限を渡す前に、直してよい範囲を1枚に書き出しましょう。書き出せない範囲が残っているうちは、権限を広げても直せる件数は増えません。
落とし穴③直した記録を残さない
3つ目は「直した記録を残さない」ことです。誰がいつ何を直したかが残らず、後から追えなくなります。
残さないと困るのは、不具合が出たときに切り分けられないためです。直せる人が3名になれば、変更の主体も3つに増えるため、記録がなければいつからおかしいのかを追う作業が発生します。残すのは、日付、直した箇所、選んだ理由の3つで足ります。
先ほどの会社では、直した内容を1行で残す運用にしました。営業企画と情報システムの双方が同じ様式で残しているため、月14件すべてが1つの一覧に並び、3か月では42件になります。直した後に戻した回数は2件で、いずれも記録から原因の箇所をすぐに特定できました。
記録は表計算のファイル1つで足ります。専用の仕組みを用意しようとすると、用意が終わるまで記録が始まりません。
設定を持ち続けられているかを測る4つの指標
前章の落とし穴を避けたうえで、次に要るのは変化を確かめる手段です。移した範囲が機能しているかは、依頼の件数だけでは分かりません。件数は業務の繁忙で上下するため、増えても減っても移した範囲の良し悪しを示さない数字です。指標は運用のなかで自然に取れるものに絞ると続き、集計のために新しい入力を増やす必要もありません。そこでここでは、設定を持ち続けられているかを測る4つの指標を整理します。
見るべき数字は設定した件数では決まりません。見るべきは設定の数より、開発を通さずに済んだ依頼の割合です。
指標①依頼から反映までの日数
1つ目は「依頼から反映までの日数」です。営業が困ってから解消するまでの時間を見ます。
この指標を最初に置くのは、移した目的をそのまま表すためです。担い手を変える理由は、待ち時間を減らすことにあります。平均だけでなく最長も見ると、特定の種類だけが滞留していないかが分かります。数字が下がらない場合は、移す範囲が足りていません。
この搬送装置のメーカーでは、平均16日から平均3日へ変わりました。最長は41日から9日です。移したのは条件と文面の2種類だけで、残る種類は以前と同じ扱いのままです。9日まで残っているのは、基幹システムとの連携を含む依頼でした。
平均と最長の両方を見て、差が開いているときは種類別に分けて数えます。平均だけが下がる状態は、件数の多い種類だけが移った合図です。
指標②開発を通さずに済んだ依頼の割合
2つ目に挙げるのは、開発を通さずに済んだ依頼の割合です。全体の依頼のうち、営業側で完結した割合を見ます。
この割合が効くのは、移す範囲の広さを直接示すためです。件数で見ると、依頼の総数が増減したときに読み違えます。割合であれば、依頼の総数が変わっても比べられます。100%を目指す数字ではありません。開発に残すべき範囲があることを前提に読みます。
先ほどの会社では、月14件のうち11件が営業側で完結しています。割合にすると79%で、着手の前は0%でした。残る3件は基幹システムとの連携と過去データの一括更新で、開発に残す判断をした範囲です。
目標として置くなら、開発に残す2種類を除いた範囲で100%に近いかを見るほうが、実態に合います。総数が動いた月は前月と比べず、同じ種類どうしで並べて読みましょう。
指標③直せる人の数
3つ目は「直せる人の数」です。実際に手を動かした人が何名いるかを数えます。
人数を見るのは、1名に戻っていないかを確かめるためです。範囲を移しても、実際に直すのが特定の1名だけなら、構造は変わっていません。過去3か月に1回以上直した人を数える形にすると、名ばかりの担い手を除けます。異動や退職への備えとしても、この数字が最も直接的です。
この会社では、1名から3名へ変わりました。営業企画1名、情報システム1名、営業から1名です。営業の1名は文面の調整だけを担っており、それでも人数には数えています。3名になってからは、誰かが休暇を取った週にも変更が止まらなくなりました。
直した実績のある人を数えましょう。名前だけの担当は、数に入れません。
指標④直した後に戻した回数
4つ目に見るのは、直した後に戻した回数です。反映した変更を取り消した回数を数えます。
この回数を見るのは、移した範囲が適切かを判定するためです。戻す回数が増えていれば、判定できない変更まで移しています。ゼロを目指す数字ではありません。範囲の当たり外れを読むための数字です。指標の定義の置き方は、効果測定の記事にまとめています。
この搬送装置のメーカーでは、3か月で2件でした。いずれも文面の調整で、営業からの指摘を受けて戻しています。条件の変更では発生しておらず、想定する質問5つで判定できていたためと見ています。戻した2件も、記録があったため原因の箇所を特定するまでに時間はかかりませんでした。
戻した回数は、種類別に数えましょう。特定の1種類に集中しているなら、その種類だけを情報システムへ戻せば済みます。
設定を開発に任せるべき3つの条件
前章の指標は、移した範囲が機能しているかを示す数字でした。ただし数字が良くても、開発に残すべき範囲はあります。判断は作業の難易度では決まらず、失敗したときに元へ戻せるかどうかで決まります。戻せない処理は、頻度が高くても、影響が自部門で止まっても、営業側には置けません。この3つの条件は、移す範囲を広げていく途中で毎回当てる形になります。そこでここでは、設定を開発に任せるべき3つの条件を整理します。
この会社が開発に残したのは、月14件のうち3件だけでした。戻せない処理を含む変更は、開発に任せます。
条件①外部の仕組みとつなぐとき
1つ目は「外部の仕組みとつなぐとき」です。社外のシステムや相手先のデータに触れる処理が該当します。
開発に任せるのは、誤りの影響が自社の外へ出るためです。相手側へ誤った内容を書き込めば、こちらで気づいても元へ戻せません。しかもこの種の処理は、つなぎ先が固定であれば作った後にほとんど触りません。頻度が低く影響が大きい範囲は、開発へ渡す条件がそろっています。
この搬送装置のメーカーの場合は、基幹システムとの連携が月2件でした。いずれも開発に残し、月1回の相談の場で内容を確かめてから着手しています。つなぎ先の仕様は着手の前から変わっておらず、待ち時間が業務に影響した場面はありません。
社外へ出る処理は、頻度を数える前に開発へ残す側に置きます。頻度を先に見ると、月2件という数字から営業側へ移す判断が出てしまいます。
条件②大量の記録を一度に書き換えるとき
2つ目に挙げるのは、大量の記録を一度に書き換えるときです。過去のデータをまとめて更新する処理が該当します。
任せる理由は、範囲を誤ったときの被害が大きいためです。条件の書き方を1文字間違えれば、対象外の記録まで書き換わります。件数が多いほど確認も復旧も重くなるため、実行の前に対象の件数を確かめる手順が要ります。この手順は開発側の作法に属するものです。
先ほどの会社では、過去データの一括更新が月1件ほどありました。実行の前に対象の件数を出し、想定と合っているかを確かめる手順を情報システムが持っています。件数が想定と合わなかった回は、実行を止めて条件を書き直しました。
一括の書き換えは、対象の件数を実行前に出せる人がいる範囲に限ります。件数を出せないまま実行する手順が残っているなら、それは移す前に直す対象です。
条件③戻せない処理を含むとき
3つ目は「戻せない処理を含むとき」です。取り消しの手段がない操作を含む変更が該当します。
条件として置くのは、戻せるかどうかが担い手を分ける最後の線だからです。頻度が高くても、影響が自部門で止まっても、戻せないなら移しません。削除を伴う処理、外部への送信を伴う処理がここに入ります。判定は「間違えたら何分で元に戻せるか」を問えば済みます。
この会社が開発に残した過去データの一括更新にも、実行後に元へ戻す手段がありません。営業企画の担当は、この処理だけを頻度を数える表から外し、最初から開発の欄へ書き入れています。
自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合も、この線の引き方は外部の目を入れる価値があります。戻せるかどうかの判定は、作った本人には甘くなりがちです。
問いに答えられない処理が1つでも含まれていれば、その変更はまとめて開発へ渡します。処理の単位で切り分けようとすると、切り分けの設計にかえって時間がかかります。
設定の線引きに外部支援を使う4つの判断軸
ここまでの内容は、営業企画の担当1名でも進められる範囲です。ただし分類の切り方や確かめ方の設計で迷う場面はあり、外部の支援を検討する会社もあります。支援先を選ぶときは、実績の数より判断の作法を見るのが確実です。作法は、最初の打ち合わせで何を聞かれるかに表れます。そこでここでは、設定の線引きに外部支援を使う4つの判断軸を整理します。
選ぶ基準は実績の件数では決まりません。支援を選ぶ基準は実績の数ではありません。直す頻度から線を引けるかです。
判断軸①直す頻度から線を引けるか
1つ目は「直す頻度から線を引けるか」という軸です。担い手の線を、機能の一覧に頼らず頻度から説明できるかを見ます。
この軸を最初に置くのは、線の引き方が成果を左右するためです。機能の一覧で線を引く提案は、実装の話には強くても担い手を決められません。ツール設定ではなく業務設計から入ってほしい場合は、最初の打ち合わせで過去の変更の回数を聞かれるかどうかで判断できます。支援先の選び方の全体像を先に押さえたい場合は、導入支援会社の選び方の記事が参考になります。
この搬送装置のメーカーが支援先へ最初に渡したのは、機能の要望ではありません。過去2年の変更の回数を種類別に並べた1枚でした。
過去の変更の回数を聞かれるかを確かめましょう。機能の話から入る相手は、この軸を満たしません。
判断軸②小さく始める形を示せるか
2つ目に挙げるのは、小さく始める形を示せるかという軸です。最初の3か月で何をどこまで移すかを、具体的に示せるかを見ます。
この軸が要るのは、範囲を絞る提案ができる会社が限られるためです。全体の運用設計を出すほうが、支援としては大きくなります。1ユースケースのスモールスタートで小さく始めたい場合は、契約の前に次の3つを数字で示してもらいましょう。
契約の前に確かめる数字 ①移す依頼の種類・・・4種類のうちどれを扱うか ②対象の件数・・・月に何件が移る想定か ③確かめ方の項目・・・想定する質問をいくつ用意するか
先ほどの会社が支援を検討したときも、最初に示された案は運用設計の全体から入る形でした。条件の変更19件だけを対象にする案へ組み替えてもらい、7週間で運用に入っています。
示せない提案は、範囲が定まっていません。3つの数字がそろって初めて、契約の期間と費用を自社で見積もれます。
判断軸③自社で構築する前提に対応できるか
3つ目は「自社で構築する前提に対応できるか」という軸です。作るのは自社で、線引きだけを見てもらう形に応じられるかを見ます。
この軸を置くのは、体制によって必要な支援が違うためです。社内に情報システムの担当がいる会社では、構築まで任せる必要がありません。分類の切り方と確かめ方の設計だけを見てもらう契約は成立します。支援の形が固定されている相手では、この頼み方ができません。
この会社にも情報システムの担当が1名いるため、設定の構築を外へ出す必要はありませんでした。頼んだのは、依頼を4種類に分ける切り方と、想定する質問の作り方の2点です。
頼む範囲を決めるときは、社内で手を動かせる人がいるかどうかを先に確かめます。1名でもいるのであれば、構築を含む契約は範囲が広すぎます。
判断軸④営業の商談を理解しているか
最後の軸は、営業の商談を理解しているかどうかです。扱っている商材と商談の進み方を、支援先が把握しているかを見ます。
この軸が効くのは、変更の頻度が商材によって変わるためです。仕様の擦り合わせに数か月かかる商材と、カタログから選ぶ商材とでは、条件が変わる回数がまったく違ってきます。ソリューション営業に特化した支援がほしい場合は、商談の進み方を聞かれるかどうかが目安になるでしょう。当社のAgentforce導入・定着支援では無料相談も受け付けています。詳しくはAgentforce導入・定着支援をご覧ください。
最初の打ち合わせで商材と商談の進み方を聞かれなければ、変更の頻度は支援先の想像で置かれます。想像で置いた頻度から引いた線は、運用に入って3か月ほどで合わなくなります。
【一問一答】設定と開発の線引きに関するよくある質問
ここまで、設定を情報システムに預けたまま止まる場面から、誰が持つかを決める4つの基準、移すときの手順と落とし穴、そして開発に残すべき条件までを整理してきました。読み進めるなかで、自社の体制に当てはめると判断がつかない点も出てきたのではないでしょうか。とくに「知識が要るのか」「誰が決めるのか」「どのくらいかかるのか」の3つは、検討の初期に必ず出てくる問いです。そこでここでは、設定と開発の線引きについて実際の検討でよく出る質問を5つ整理します。
質問①設定にプログラミングの知識は要りますか？
多くの範囲では要りません。項目の追加、条件の値の変更、参照する文書の差し替えは画面の操作で済みます。この記事の例に挙げた搬送装置のメーカーでも、3か月の依頼42件のうち最も多い条件の変更19件を、営業側の操作で完結させています。ただし外部の仕組みとつなぐ処理や、大量の記録を一度に書き換える処理は開発の範囲です。線は知識の有無では引きません。戻せるかどうかで引きます。
質問②設定は情報システムの担当でないとできませんか？
そうとは限りません。4つの基準を満たす範囲であれば、営業企画のような担当でも持てます。頻度が高く、業務の知識が要る変更のうち、影響が自部門で止まり、直した本人が確かめられるものです。この記事の例では、月14件の依頼のうち11件が営業側へ移りました。
質問③設定を営業部門へ移すと事故は増えませんか？
範囲を決めて移せば増えません。この記事の例では、3か月で戻した変更が2件です。いずれも文面の調整で、影響は自部門にとどまりました。移す前に確かめ方を定めておくことが条件になります。
質問④設定の線引きは誰が決めますか？
営業企画や営業推進の担当が向いています。過去の変更の回数を種類別に数え、影響の及ぶ範囲で分ける作業が中心だからです。この会社では営業企画の担当が3か月分の依頼42件を分類し、残る月3件だけを月1回30分の相談の場へ回しました。情報システムの担当は、影響範囲の判定で相談に入ります。
質問⑤設定を移すのにどのくらいかかりますか？
1種類に絞れば7週間ほどです。この記事の例では、依頼の分類に半日、移す範囲の決定と確かめ方の設計に3週間を使いました。残りは運用の立ち上げで、担当1名の計42時間です。
設定の線は、作れるかより持ち続けられるかで決まる
前章までで、担い手の基準から支援先の選び方までを整理してきました。設定でできるかどうかを機能の一覧で調べても、担い手は決まりません。作れることと持てることは別で、作るのは一度きり、直すのは繰り返しだからです。線を引くのは、その変更がどのくらいの頻度で起きるか、判断に業務の知識が要るか、間違えたときの影響がどこまで及ぶか、直した本人が確かめられるかの4つです。
先に決めるのは、依頼をどう分類するかです。過去3か月の依頼を項目・条件・文面・接続の4つに分ければ、どこに集中しているかが半日で見えてきます。最も多い1種類を営業側へ移したうえで、確かめ方を5つの質問で定めておきましょう。残った範囲は開発へ渡し、窓口は月1回の相談の場に置きます。この順番であれば、7週間で運用に入れるはずです。
この記事の例では、依頼の件数を1件も減らさず、反映までの日数が平均16日から平均3日へ変わりました。開発を通さずに済んだ依頼は月11件、直せる人は1名から3名へ、情報システムの担当の作業時間は月22時間から月5時間です。過去3か月の依頼を種類別に数えるところから着手できますので、本記事で整理した基準を自社の記録に当てはめて、少しでもお役に立てれば幸いです。