ライフライン業界を知る

Date2026/05/25 Last Modified2026/05/25

概要

前稿の業務フロー自動化で触れたが、平たく言えば「業界あるある」をよく知ってないと、システム開発以前につまずくことが多いと感じた。
銀行に行ったことがないと口座開設の手続きでどこが面倒くさいか説明できないように、サービス一つ一つには独自のルールがあり、知らないと大体わからないものである。
単純に人生経験が浅い～で済ませてもよいとは思うが、それを明示的に教えてくれる人って少ないので、自分から知りに行かないといけない。
そこで、自分が関わる機会の多いライフライン業界について、一般的なポイントを押さえてみたいと思う。

ライフライン業界とは

ここでのライフライン業界とは、主に住宅や暮らしにまつわるサービス(電気、ガス、水道、インターネット)のことを指す。（本来は交通や土木まで広く指す）
特徴として、それ自体はブランドを持ちにくいので価格競争が起こりやすく、さまざまな企業と提携して販売計画を立てていくケースが多い。

電気

電気は、2016年の電力自由化にともなって電力会社を乗り換えるという消費者が多くなった。
電力自由化が起こった背景には、大手電力会社による独占的な市場を変革するという目的があり、価格競争可能にすることであった。
ただ他のサービスと大きく異なるのは、発電所と送電網は代えが利かないということ。発電所は土地の問題があるし、電力会社ごとに電柱を立てていたのでは大変である。
それゆえ、小売の部分だけでも市場を開放するというのが電力自由化である。

そもそも電気は、単体で利益が出にくいという構造がある。
電気そのものは差別化ができないため、必然的に価格競争に巻き込まれてしまう上に、ブランド化も難しい。（〇〇の電気は質が良い、とはならない）
新電力会社（小売）は一般的に発電所を持たず、大手電力会社から使用枠を買い上げて、消費者へは送電の契約をやっているだけなので、単純に送電するだけでは利益が出ない。
そのためにも、何かとパッケージングして販売することが多くなっている。
よくあるものとして、生活・娯楽商品、ポイントやキャッシュバック、カスタマーサポートなどが挙げられる。

電気契約は2通りあり、再点灯（新規）とスイッチング（切替）である。スイッチングとは、住みながら電力会社を乗り換えることを指す。
個人視点だと「電気＝引越のときに変える」くらいの感覚だったが、市場の統計的にはスイッチングは46%(参考: 25年12月の統計)程度存在するので重要なマーケティング要素になり得る。
この2つの契約形態は、顧客の管理としてはあまり重要ではない情報だが、分析には重要な情報になるので、データとしての棲み分けは必要になる。

もう少しマーケティングに寄っていくと、スイッチングが多いだけではサービスが魅力的なのかはわからなくて、解約率を見ていくことが重要になる。
獲得の時点では営業力や、商品の新規性などでいくらでも増やせるかもしれないが、本質的に良いサービスかどうかは解約率がもっともよく示してくれる。
例えば、大量のキャッシュバックがあって一時的に契約を獲得したが、本来の電気料金は高いので、キャンペーン期間後にすぐに乗り換えられてしまったなど。
こうなると顧客獲得+サービスのコストに対してLTVが見合わないので失敗となる。(LTV/CAC比は〇〇以上であるべき、または下回らない、という業界標準をもとに)
その一方で、再点は契約の見直しが行われやすい（心理的に見直しコストが低い、または乗り換えざるを得ない）ので、それもまた別軸で分析が必要になる。

請求のややこしい話

電気契約は一応住所に結び付いているが、結局のところ個人に対する請求である。
供給地点番号というものがあり、これは一意の住所を指すものなので、個人情報＋供給地点番号さえあれば請求可能である。
逆に住所変更連絡を忘れたりすると、代わりに入居した人が「誰かがうちの電気を払っている」という謎の状況になる。
そのため、いつでも緊急時に個人を特定できるように電話番号やメールアドレスなどの連絡先も必須事項である。

電力供給の請求に関係するフローはおおよそ3つあり、「電気供給開始日 / 停止日 / 検針日」のようになっている。
ここで難しいのは、関係各社によって請求をかける対象が異なってくるというところ。

電力会社は「使用量」を基準に請求をかけることになる。
この使用量を計測するには検針が必要になるが、検針日は「毎月この日」というのが定まりにくかったりする。
すると、「初月は4/10~~5/5までを請求する。翌月以降は5/6~~6/5」といった変則的な形式になるのがややこしいところ。
もっと厳密には、「検針日→データ確定日→請求確定日」のように細かくデータ管理する場合もあり、この不定形のルールをパッケージ販売する各社に合わせようとすると、どうしてもゆがみが生じてしまう。
そのため、別の線引きを設けて請求を行うというケースも多い。

電力会社の請求システムをもう少し細かく考えるとすれば、検針日にばらつきがあるのを抑えるには「推定使用量」での請求をかけるなどがある。
これは年末調整のようなもので、差異をまとめて着地させるという方針になる。

パッケージ商品は毎月「顧客数×定額」で請求をかけることが多く、毎月の決まった日に一括で請求することがある。(月末締め月初払いなど)
そのためにはコンテンツ提供側（メーカー）としても、決まった日にサービス利用可能にする必要があるのだが、例えば毎月1日に請求をかけるのに前月の31日に申し込みをしてきた人がいたら、「1日しか使ってないのにもう請求ですか！？」となってしまう。
何かの型に合わせようとすると、ステークホルダーの誰かがそのツケを払うことになってしまう。基本的には消費者が負担することのないよう、メーカーまたは小売の方で契約をしっかり締結する必要が出てくる。

ひとつの例だと、本来は1か月無料のサービスだが申込日によって差異がある場合、「最大2か月無料」のような形式にして差を吸収するという方法がある。
この場合、「2か月まるごと使えてしまう人」と「1か月と1日しか使えない人」が発生しても問題ない。

ここで整理するとすれば、
「複数のサービスやコンテンツをまとめて販売しようとすると、請求フローに必ずひずみが生じる。なので、そのひずみを誰が飲み込んで処理するのが最適なのかを議論する必要がある」
ということになる。システム開発で意識すべきなのはそのあたりで、プラス会社間の関係性とか、そういうところで決まっていくこともある。
電力会社にかかわらず、数社混ざると必ず発生する課題である。

電気のまとめ

キーポイントまとめ。

個人情報＋住所(供給地点番号)＋連絡先の情報が必須である
電気で再点とスイッチングを分けるのはマーケティング的な視点での意味がある
サービスへの評価は「解約率」が最も重視される
請求にまつわる日時は「電気供給開始日」を基準にするのが最も安定している
多くのケースで請求フローのずれが混在するので、ステークホルダーの誰かが吸収する必要がある

代理店事業について

代理店事業とは、自社商品・サービスを拡販するために、外部企業へ営業・契約・販売などの役割を担ってもらう事業形態である。
例えば、取次代理店というのが一つの形態としてある。
取次で一般的なのは、特定の地域での営業や小規模な広告、そこから契約までを請け負うというもの。
契約主体がどこになるかによって、顧客データの管理主体や業務フローも変化する。
取次の場合は代理店が契約まで行うことになるが、その顧客データを自社へ取り込む流れの中で発生する業務をまとめていく。

まず必要になるのが、代理店への報酬条件である。
ショット（単発報酬）とストック（継続報酬）の2パターンがあるのだが、これは代理店ごとに異なる契約内容になりやすい。
ストックの場合は、さらに契約期間という軸もある。年次で報酬率が変わったり、解約者の管理が発生するということを踏まえる必要がある。
どちらも成果の確定日を申込時点にするのかなど明確にする必要があり、どのように請求してもらうかによって参照すべきデータが異なってくる。

次に必要になるのが、個人情報の管理である。
ライフラインを前提にすると、顧客の住居や連絡先を含めた個人情報、加えて開通日などの付属情報あたりが必要になる。
ここで重要なのは、その下流にあるコンテンツ提供会社(メーカー)が必要としている情報を満たせるか、という視点である。
例えば保険も一緒に契約する場合、保険商品の加入条件や審査の観点から生年月日や性別、年齢などが必要になる場合があるとする。
そうなると、仮に代理店の方で生年月日を取得できなかった場合、自社で追加対応をしなくてはならない。
さらにそれが原因でサービス対象ではないことが判明し、キャンセルになったりすると、代理店の獲得件数から減らす必要があり、フローが煩雑になってゆく。

その一方で、メーカー側が独自で問い合わせるというフローも存在する。
サブスク型のシステムで管理しているサービスなどは事前に全てを伝える必要があるが、メーカーのサービスを使うときに電話がメインだったりする場合もある。
その場合は、口頭で必要な情報を回収できるというケースもあり、その場合は一部のカラムが欠損していても大丈夫なことがある。
ただしこれはメーカーに完全に依存するので、一般的なケースではない。

加えて必要なのは、IDなどの会社ごとの独自の識別子である。
これは自社が発番して全体に返す場合と、関係各社のすべてのIDを統括する場合と、様々考えられる。
特にシステム化しているとIDの発行というのは顕著で、API連携などに使える可能性もある。
逆にIDがないが個人を特定する必要に迫られると、電話番号や住所などで突合して見つけ出す必要があるが、それらは変化する可能性があるので、どうやって見分けるかは規定する必要がある。

他には、代理店によってはプライバシー保護の観点から特定の個人情報の受け渡しをしないとか、契約で締結していない要素が必要になったとかで、データが欠損するケースがある。
そうなるとまた自社の現場対応などで架電対応などして解決する必要が出てくるので、何を採用しているのか把握しておけると強い。

コールセンターのオペレーション

自社対応、現場対応などの用語を用いるときは、大抵コールセンターがある。もしくは営業部隊などと言ったりする。
このポジションの人は、架電による営業や既存顧客への確認を行い、それで得られたデータをクラウドやDBに保存したりする。他にもメール送信やSNS対応などがある。
今扱っているサービスがどのような販路を辿ってきたかは重要ではなく、そのサービス名と顧客情報が結びついていれば良かったりする。
そのため、販路の拡大が著しい企業などは部門に対して扱うサービスの量が多くなり、管理が煩雑化、一元化してDBが混雑するといった事象が発生しやすい。

全体のフローのうち、何を上流から取得して何を下流へ渡すというのは重要ではなく、とにかく目の前の顧客に対して必要情報を取りに行くといった形態になりがちである。
そのため、サービスに応じたフォーマットをシステムなどで制御していないと、データが無法地帯になりがちである。（氏名の姓と名が一緒になったり、概要に色々書いたり）
多くの場合は、基幹システムを改修するコストは持てないのでシステム化を行おうとするなら、そのコンテンツだけは別の入力システムを使ってもらう、などの方法が手っ取り早い。
特に基幹システムは、ただのDBと化していたり、ノーコードツールなので改修しようとしてもわからない、といったケースがあり得るので上記の対応になる。

ただし現場に応じて柔軟な対応方法を考えるべきである。例えば上流から来るデータが足りなくて現場対応している場合、上流に掛け合った方が良い場合もある。
またはシステムを導入して自動化するコストと、その対応をするオペレーターを一人多く雇う場合では、雇った方がコストが抑えられる場合もある。
さらにシステムを導入すると現場のフローが変わってマニュアルなどの差し替えが必要になる。その対応コストが高すぎる場合は、既存のままで大丈夫だったりする。

続きは随時更新。