近年、エンジニア界隈において「技術的負債（Technical debt）」という言葉が頻繁に使われるようになっている。もともと「技術的負債」という言葉は1992年にWikiWikiを生み出したウォード・カニンガム氏によって提唱されました。

In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

これはイケていないコードによって構築されたソフトウェアは、サービスが成長した際にデバックやリファクタリングを行わなければいけないという言わば借金を背負うことを示唆しています。 要は、構造的な欠陥を放置することによって、長期的に大きな不利益を被るという話です。

そして、ここからは私見となりますが、「技術的負債」は何もエンジニアリングに携わるものだけではないと考えています。特にマーケティング領域においては、多くの組織が「マーケティングにおける技術的負債」に悩んでいるのではないでしょうか？

例えば、「データの欠損によって、適切な施策のセグメンテーションが切れない」ということを経験したことがある人は多いのではないでしょうか？ また、「データベースを再設計する際に、長年放置されていたことによって修正項目が大幅に増加していた」という話もよく聞く内容であり、マーケターのリソースが大きく奪われてしまうこともしばしば・・・

そこで今回は「マーケティングにおける技術的負債」について、なぜ発生するのかから事例、どのように向き合っていくべきかを述べていきます。

マーケティングにおける技術的負債とは何か？

先述したように「技術的負債」は元々エンジニアリング界隈の用語ですが、実はマーケティングにおいても「技術的負債」は存在します。具体的な例は以下のような内容が挙げられます。

• 構造的にデータが欠損してしまうSFA
• 将来の拡張性が無視されているDMP
• 必要な情報が取れないアクセス解析ツール

例を挙げればキリがないくらいにマーケティング領域においても「技術的負債」は存在します。マーケティング領域においてはデータ基盤を切っても切れない関係ですので、「技術的負債」が発生する可能性を常に孕んでいます。

その中でも特にマーケターを悩ませるのがSFA関連です。特に日本でもシェアの大きいセールスフォース関連は、どの組織においても少なからず課題が存在しています。※これまで7社に在籍し、複数社のマーケティングコンサルを実施してきましたが、全組織に課題が存在しました。

ここまでお伝えしてきたように「マーケティングの技術的負債」は、ほとんどの組織においてマーケターが頭を抱えている課題であり、目を背けてはいけない現実でもあります。

技術的負債が発生する不可避なメカニズム

組織において「マーケティングの技術的負債」が発生する懸念があることをお伝えしましたが、なぜ多くのマーケターが「マーケティングの技術的負債」を抱えてしまうことになるのでしょうか？ 多くのマーケターが悩んでいるのであれば、対策は行われてしかるべきでしょう。

しかしながら、事態はそう簡単なものではありません。この問いに対する個人的な結論を言ってしまうと「分かっていても防ぐのが難しい」が答えになります。ちなみに難しい要因は以下のような現実があるからです。

• データ基盤設計時に必要な情報を全て集めることは現実的でない
• データ基盤への要求がフェーズによって変化する
• リソースを割く優先順位が上がりにくい

過去の経験から言えば、一定の経験があればデータ基盤設計時に最低限必要な機能は実装可能ですが、その後に必要となる機能は「予測出来ない」「予測出来てもリソースが逼迫しているのでスコープから外れる」「スコープから外れて、長期間放置される（そして技術的負債に・・・）」となっていきます。

そして、このようなメカニズムによって生まれた「技術的負債」は、ある時から施策の精度を下げる要因になったり、そもそも施策を実施出来ない原因になったりしていくのです。

【実体験】問題だらけのDBに苦悩しかなかった話

ここでは、私の体験からセールスフォースで構築されたDBに苦労した話をご紹介していきます。

苦労話① 入力データの欠損が酷く、何が正のデータなのか分からない

転職組のマーケターあるあるなのが「DBに入力されてるデータの欠損が酷くて使い物にならない問題」。新任のマーケターにいきなり重い枷がハメられる瞬間です。※サラッと「キレイにしてね！」と言われて〇意が湧くやつですね

これがエクセルにデータがあって移管するだけだったら簡単なものです。しかし、そんなものはありません。そもそも「正のデータが分からない」なんて、良くある話です。正のデータを持ってくる方法を考えるだけで、心労が溜まります。

そして、ここがポイントなのですが、そもそも論で「元のDBの項目設計がイケていないので、正しいデータが入力されてもマーケティングに活かせない」というところまでがお約束となっています。面白いことに設計がちゃんとなされているとデータもキレイなことが多いのですが、データが入力されてないと設計もイケてないことが多いのが現実です。

苦労話② 新規と既存の整理さえつかず、pardotがただのメルマガ配信ツール化

当時はSFAとしてセールスフォースを使っていたのですが、セールスフォースと相性が良いpardotがMAツールとして導入されていました。やはり、シームレスにSFAとMAを連携させることが良いので、組み合わせとしては理想的です。

ですが、どんなに良いMAツールを導入していたとしても適当なDB設計かつデータの欠損が多ければ、パフォーマンスはなかなか出ません。本当に笑えるような話なのですが、新規と既存顧客の判別もままならない状況であり、セグメントを切った施策が打てないという事態・・・

pardotの機能を活かしきれず、単なるメール配信ツールと化し、どうにか機能を活用しようとして効果があったのは「アクティブプロスペクトがwebにアクセスしたら営業担当に通知する」という施策くらいでした。※これは効果がありました。MAツールの効果的な活用方法はまた別の機会に！

苦労話③ 会計周辺のデータも統合することになり改修で地獄絵図

セールスフォースはSFAのみならず、CRMやバックオフィス周り、他にも採用管理ツールとして活用している企業もあるほど、汎用性が高いDBとなります。だからこそ、全てのデータを一元管理したいと考えるのはおかしい話ではありません。

私も例に外れませんでした。必死にデータクリーニングとDB再設計を考えていた時に、いきなり話が振られました。

「会見関連のデータもセールスフォースで管理することになって、早急に構築しないといけなくなった。社内で触れる人もいないから、とりあえず来月までによろしく！」

目の前が真っ暗になりました。そもそもマーケターの仕事でもない気がしますが、それは置いておきましょう。ただえさえ迷宮ラビリンスなSFAに会計データを突っ込もうとすれば、それは地獄絵図になる未来しか見えません。

しかし、避けられないオーダー。私は効果的なマーケティング施策が打てる日が来るのを一旦諦めました。そして、業務フローを設計し、新しいカスタムオブジェクトを追加してテストを続ける日々が始まったのでした・・・

私の経験談は「マーケティングにおける技術的負債」として少しヘビーなものでしたが、苦労話①と②に近しい状況を経験したことがある方は少なくないのではないでしょうか？

マーケターとしては是が非でも避けたい状況であるものの、絶対的な回避策もありません。それではどのように「技術的負債」と向き合うべきなのでしょうか？

マーケターはどのように技術的負債と向き合うべきか

「マーケティングにおける技術的負債」に悩まないために一番大事なのは、「負債を溜め込まない」ようにすることです。※これはエンジニアリングにおける「技術的負債」とも共通しています

もう少し分解すると「負債が溜まらないための初期設計」と「それでも負債が発生するのですぐに解消出来るように動く」ことの2つが大事になります。

初期においては、具体的に「必要な項目を定義して、データが欠損しないように死守すること」が大事です。

• 初期設計において最低限必要な項目を設計する
• データの欠損が発生しないフローに
• 人的なデータ欠損はアラートを出すだけでなく、入力サポートする

それでも、初期設計では対応しきれないことがほとんどです。そのためミニマムでも「クオーターに1回はDB基盤を見直し、追加設計が必要かを検討すること」が求められます。これを放置すれば放置するほど、追加設計後のデータ欠損は増加し、マーケターを苦しめることになります。

残念なことに「これをやっておけば大丈夫！」という安全安心な「マーケティングにおける技術的負債」の回避策はありません。それゆえに、定期的な見直しやメンテナンスが、マーケターとしての自衛策となるのです。

◆著者プロフィール
大野知希 / Haruki Ohno
2014年に大学卒業後、累計7社でセールス、マーケ、CS、採用などに従事。
現在はRepro株式会社でカスタマーマーケティングがメイン。サブで個人でライティングやコンサル請け負いながら起業準備中。
趣味は「乃木坂46」と「欅坂46」と「けやき坂46」