LINE連携の入力項目を変えるとき、どこまで確認する? 変更前後のチェックポイント

LINE連携の入力項目を変えるとき、どこまで確認する?|変更前後のチェックポイントのアイキャッチ画像

「LINEの申込フォームに、返信方法の選択肢を足したい」「電話番号を必須にしたい」。運用が始まると、入力項目を変えたくなることがあります。

画面に選択肢を追加できても、業務システムに保存する値や、担当者への通知が古いままなら、意図した運用にはつながりません。変更する前に、情報が通る場所と、確認する内容をそろえておきましょう。

「どの項目を変えるか」と「何を実現したいか」をセットにする

例えば、問い合わせフォームの「返信方法」に「電話」を追加する場面を考えます。これは説明のための架空の例です。

目的が「メールを見ない方にも連絡できるようにしたい」なら、電話を選んだ方の電話番号をどう受け取り、誰が電話するかまで考える必要があります。選択肢を増やすだけでは、連絡に必要な情報がそろうとは限りません。

【推奨】依頼するときは、「今はどうなっているか」「何を変えたいか」「変えた後、担当者が何をできればよいか」を短く書いてください。入力の手間が増えても集める必要のある情報か、別の確認方法でも足りるかも、この段階で整理します。

入力画面から、登録先と通知までたどる

【推奨】変更対象を、入力画面・連携処理・登録先・担当者への通知に分けて確認します。連携処理とは、受け取った内容を確かめ、登録先に合わせた形へ変換する部分です。すべての場所を修正するという意味ではありません。どこに影響するかを確かめ、必要な箇所を選びます。

返信方法に電話を追加する例を、入力画面、連携処理、登録先、担当者への通知に分け、それぞれの確認点を示す図
「返信方法に電話を追加する」場合の確認例です。実際の変更箇所は連携の作り方によって異なります。※概念図

図を拡大して見る

  • 入力画面:電話を選べるか。必要な場合だけ電話番号を求める形にするか。
  • 連携処理:新しい選択肢を受け取り、登録先が扱える値へ変換できるか。
  • 登録先:電話番号と返信方法が、決めた項目に保存されるか。
  • 通知・担当者確認:誰に、どの情報を知らせ、連絡対応を始めてもらうか。

「送信できました」という表示だけで終わらせず、登録先の記録と担当者が見る通知まで、同じテスト内容で照合します。

画面の名前と、連携に使う名前を分けて確認する

【事実】kintoneでは、APIによるデータの作成・取得・更新にフィールドコードを使います。HubSpotのプロパティにも、画面に表示する名前のlabelと、内部名のnameがあります。(出典:kintone Developer Program「Field Types」、HubSpot「Properties API」)

【推奨】画面に出る「返信方法」という名前だけでなく、連携処理が指定している項目名と、保存する選択肢の値も確認します。「表示名を変える」「連携用の名前を変える」「保存する値を変える」は分けて扱いましょう。

画面の表示名を変えても連携に影響しない場合はあります。一方で、連携側が表示名や表の列位置を手がかりにしている実装なら、表示や並び順の変更も関係する可能性があります。自社の仕組みが何を目印にしているか、実装担当者に確かめてください。

過去の記録と、変更前に開いた入力画面も考える

新しい項目を必須にしても、過去の受付にはその情報が入っていません。「古い記録は空欄のまま残す」「必要な案件だけ担当者が確認する」など、過去データをどう扱うかを決めます。分からない値を、推測した内容で一括補完しないようにしましょう。

【事実】kintoneでは、フィールドを削除すると、そのフィールドに登録されているデータも削除されます。(出典:kintoneヘルプ「フィールドを削除する」)

【推奨】項目を使わなくなるときも、すぐに削除せず、既存データの保存方法と他の処理からの参照を確認してください。設定を元に戻すことと、失われたデータを戻すことは別に準備します。

変更前から開いていた入力画面が、変更後に送信される場面も確認対象です。古い形式を受け付けるか、再読み込みを案内するかなど、作り方に合う扱いを決めておくと、切り替え時の対応を整理できます。

新しい項目が入る場合だけでなく、入らない場合も試す

【推奨】変更箇所のテストには架空の情報を使い、「新しい選択肢」「必須情報の不足」「従来の選択肢」「登録失敗」「失敗後の再実行」を用意します。確認の目的は、正常な申込みを登録できることと、登録できないときに担当者が状況を追えることです。

新しい選択肢、未入力、従来の入力、登録失敗、再実行について、試す内容と確認する結果を組み合わせた表
連携の仕様に合わせて、期待する結果と確認者を決めるための例です。※確認表の例

確認表を拡大して見る

登録に失敗したとき、画面に成功と表示しないか。再実行したとき、既に登録された記録と重ならないか。通知が届かなかったとき、担当者が登録先から確認できるか。実際に必要な範囲を、開発・保守担当と業務担当で分担して確かめます。

また、変更していない「メールで返信」の申込みも試します。追加した入力だけが動いても、従来の利用方法が使えなくなっていれば、確認は終わりません。

切り替えの前に「止める条件」と「戻し方」を共有する

【推奨】本番に反映する前に、切り替える日時、確認担当、登録できない場合の連絡先を決めます。「保存先に必要な情報が入らない」「従来の入力を受け付けられない」など、反映を止める条件も共有してください。

変更後に受け付けたデータは、設定を戻しても残る場合があります。古い設定で扱えるか、担当者による確認が必要かを含めて、戻し方を準備します。手順が確定するまでは変更を見送り、追加情報を担当者が確認する運用を続ける選択肢もあります。

まずは、変更メモを作る

次の項目を、分かる範囲で書き出してください。連携用の名前が分からない欄は「不明」のままで構いません。

  • 変えたい入力項目と、その目的
  • 入力画面の変更前・変更後の内容
  • 連携用の項目名、保存する値、登録先
  • 過去の記録と、変更前の画面から届く入力の扱い
  • 担当者への通知、確認する人、試す内容
  • 本番へ反映する条件と、不具合が出たときの戻し方

和-Nodeでは、LINEと今お使いの業務システムの連携について、変更したい目的から必要な改修範囲を整理します。入力項目の変更について相談する際は、この変更メモをお使いください。実際の顧客情報や接続キーを送る必要はありません。