システム導入の現場では、どこへ行っても「PoC」や「アジャイル」という言葉がきかれ、特に我々が関わる営業やマーケティングといったフロントのシステムでは、使いながら完成させるというアプローチが非常に一般的になりました。
進め方はそういった工夫がされるようになりましたが、企業内なので役割の違うメンバーが協力するという体制面や立場の面からくる「言葉が通じない難しさ」は依然存在します。
実際に経験した、そういったケースをご紹介しながら、この古くて新しい問題をどう解決できるかを皆さんとご一緒に考えていきたいと思います。
ケース1｜依頼者側の苦労：“はじまらない”プロジェクト
まず1つ目のパターンは、ビジネス側から依頼した要求が、技術者側に総スカンにされてしまい、進めたいPJが膠着やペンディングの状態に陥ってしまったケースです。
A社の経営企画部では、毎月費用として計上される様々な費目のリストを用いた月次の採算管理を行っていました。その集計のために担当者は毎月末には2～3日の徹夜作業をしているような状況でした。長年行われている管理ではあるのですが、まとまった手順書はなく、口頭とOJTでの引継ぎの形式で実施されてきた業務です。
自分たちの味方と思ってお願いをしてみたものの…
そういった中で、経営企画部のAさんは業務改善のため、社内のシステム開発部門に、費用の各帳票を単位ごとに自動的に割り振り、集計してもらえるようなシステムの開発をお願いしに行くことを決めました。
Aさんの胸の内はこうでした。「社長付組織の経営企画部のお願いごとで、業務の実情も説明すれば、必ずシステム開発側は協力してくれるだろう。」
Aさんにはいわゆる要求定義や要件定義といったことの知識はなく、また社内のIT部門と会話する機会といえば、会議ツールの設定ぐらいでした。今やっていることをある程度理解してもらえれば、後はシステムが付いてくる、といった程度の考え方で依頼を進めようとしていました。日々忙しいなか、この仕事に時間を割いてはいられません。
必要なことを用意できていない！？
早速、Aさんはシステム開発部の担当課に説明するために、前月の社長報告資料と、その元ネタの計算シートファイルを準備。アポイント当日は意気揚々とシステム開発部担当者に説明を行いました。
「私たちの部門は毎月この資料作成業務がひっ迫しています。別途お渡ししているシートで計算していますが、帳票を手動で読み込ませないといけないし、読み込ませたデータの集計・整形にはそれなりの手作業が発生しています。是非システム開発部の皆さんの力をお借りして、業務自動化を実現したいので、協力お願いします。」と、Aさんはパワーポイントに張り付けた表を見せながらお願いの言葉を発しました。
ところが、システム開発部の反応はAさんの想定と反したものでした。「そもそも何の帳票のどこを読み込ませているのか全く分からないです。」「この計算シートの計算は合っていますか？システムを作ったとしても、それで何かが間違えて後で自分たちのせいにされても困ります。」「我々も忙しいので、せめてちゃんとした依頼でなければ受け入れることはできない。」といった指摘のコメントが大量に飛び交い、到底話し合いという形にはなりませんでした。
返ってきたのは大量の宿題…
細かい議論も想定して1時間確保した時間枠は怒涛の指摘の後でも半分も消化していない状態でした。開始から20分程度で会議は散会し、大量の指摘確認事項をAさんは抱えることになりました。
「日常の業務を回すだけでも精いっぱいなのに・・・」そう思ったAさんは、開発部からの指摘確認事項に対応することを断念してしまいました。その後上司に、「業務改善のための開発協力依頼を行いましたが、先方の担当者は全く取り合ってくれませんでした。」と言葉短かに報告をし、その後業務改善の依頼を再度お願いすることはありませんでした。
上記の例は、少し極端な想定ではありますが、場合にしてビジネス側の要求が曖昧過ぎて開発として受け入れて前に進められないことや、開発側の姿勢が保守的で、様々なことが事前にクリアになっていないと一歩も実務に着手できない、といった事象は実際のシーンでも散見されるのではないでしょうか。
相手の仕事の理解と組織的なやり方を
実際にこういう話が背景にあって、お声かけいただく案件はいまだ後を絶ちません。まず気づくのは、「これは誰の仕事か？」という点だと思います。一担当者が日々の業務のレベルのことで乗り込んでいって、どこまで聞いてもらえるのか？という話です。
受け取る側も、年度の計画や予算のなかで活動しています。組織としての重要課題だということを認識してもらうことがまず足りません。そのための準備がAさんには決定的に不足していました。
準備というのは、資料ではありません。相手が聞いてくれる状態を作る、そのための自部門内でのコンセンサスと階層をまたいだ対応です。システム開発のことを知らないことは大きな問題ではなく、理解・納得してくれれば曖昧な要求でも拾い上げて仕事を進められるものです。
そういった相手の状況の理解や、組織としての動き方を見直さないと、「自分はがんばっているのに、、、」という負のサイクルに入り、おそらく一歩も進まないことでしょう。
ケース2｜開発者側の苦労：ビジネス側の曖昧な要求への対応での工数爆発
「企画をして開発側に要求を行うビジネス側」と、「ビジネス側からの要望を受け、設計・実装を行う開発側」がいる場合、ビジネス側が開発側に対して、意図せず曖昧かつ無茶な要求を行なってしまうケースは多く存在するかと思います。
最近でも、例えば、我々が主業務としているデジタルマーケティングの現場で、こんなケースがありました。
B社のマーケティング部は、営業から「架電対象となるHOTリードを多く引き渡してほしい」との要望を受けて企画を考えました。
そして、マーケティング部Bさんから開発部Cさんへ「営業へ共有するHOTリード選出のため、MAツールを用いてメールでのナーチャリング施策を来月から開始したい。」「その施策の反応から営業にツールでアラートをあげたいです。」と依頼しました。
開発部Cさんは、マーケティング部Bさんからの要件をExcelファイルで受け取ったものの、中身は曖昧な指示しかない非常に簡易的なもので、不吉な予感がした状態でした。
悪気がないのが一番手ごわい
開発部Cさんは内心困りつつ、一次回答として「来月は頑張っても無理なのでご了承ください。ちなみに、設計に必要な詳細情報は既に揃っているのですか。」と投げかけます。
するとマーケティング部Bさんは、「必要な情報とは？必要なものがあればお渡しするので教えてくださいね。まだ今日は上旬なので来月中リリースでいきましょう！」と笑顔で返事をします。マーケティング部側には施策実行までの道筋が具体的に見えていないため、開発側へ無理を強いていることに気が付いていないのです。
開発部は、依頼を実現するための確認事項を洗い出します。考えることは盛り沢山です。
メール文面は作成済なのか？メールへの反応が条件になっているがMAで追えるようにタグは埋め込まれているのだろうか。ナーチャリングのフローの分岐はあるのだろうか。社内対応ステータスはMAに既に連携されている項目なのだろうか、SFAツールでアラートを挙げる際どのような形で引き渡す必要があるのだろうか。あ、SFAツールと連携するなら、パートナーさんに動いてもらう必要もあるから対応してもらえるか確認しないと･･･。
確認すると、残念ながらパートナーさんから「着手可能なのは来月下旬です」との回答をいただいてしまいます。
開発部で確認できることは全て確認完了し、必要情報を洗い出したところで、開発部Bさんはマーケティング部との会議を設定します。会議は開発部からの怒涛の質問タイムです。質問を投げかけるものの、どれもこれもマーケティング部から明確な回答は得られません。
さらに、「それはこちらもわからないので一緒に考えていきましょう」というこちらの心配とは真逆のポジティブな返事ばかり。なんとか実現したいものの、「そこまで拾わないといけないのか？」と、Ｃさん側でもよくない方向へ気持ちの変化が表れてきました…
一気に雲行きが怪しくなる瞬間 ～早期リリース希望の企画 VS 現実路線提示の開発～
とはいえマーケティング部Bさんはそれなりにがんばってくれて、「ではそれぞれ制作担当に確認します。フロー分岐が必要かも考えますね。2週間程度で開発部にお渡しできるようこちらが頑張れば、2週間あるので来月には開始できますよね？」とのこと。
向こうもやや姿勢が変わってきてしまいました。「納期の圧」をかけてきたのです。開発部Cさんは必死に実情を訴えます。「要件定義書～テスト設計書の作成、実装、MA-SFA連携テスト、リリースを2週間で行うのは無理です。フロー分岐が必要となると条件をMAで抽出できるかの確認も必要です。」「そもそもSFAツールのパートナーさんのリソースの空きがないため今月テストに着手すること自体不可能です。」
マーケティング部Bさんはちょっと困り顔になり「思ったより大変なのですね。どうにも調整きかないのですか？」と理解を示すような雰囲気を醸し出しつつも、引き下がってくれません。「ひとまずお互い確認を進めましょう」という形で、具体的な話をできないまま会議は散会となってしまいました。
実現にはこぎつけたが本質的な解決につながったのだろうか？
その後、実装方法含むナーチャリングのフロー分岐の検討に1か月半、リード状態に合わせたコンテンツの検討に1か月と企画側も関係する内容の検討だけで計2か月半を要しました。ここから開発部がようやく要件定義書の作成に着手し、そこからリリースまでに約2か月。
結果的に、開発部が依頼を受けてから施策開始までに4か月半も要したのです。施策を無事開始後、マーケティング部Bさんから「配慮が足りず申し訳なかったです。次回以降は早い段階で開発側に相談し、余裕をもって依頼できるようにします。」との連絡をもらい、ほっと胸をなでおろした開発部Cさんでした。
上記の例は少し極端にスケジュールが延びてしまっていますが、企画側の想定以上に労力がかかるものであったという事例は多いのではないでしょうか。
こういうシーンのために普及しつつある“MOps”
最近、マーケティングオペレーション「MOps」という言葉を耳にする機会も多いのではないでしょうか？ ケース２の問題は、知識や配慮不足ではなく、「部門をまたいだ仕事がまったくルール化されていないこと」の方が根底にあり、それらへの対応策としてMOpsという考え方が出てきたと思えば理解しやすいでしょう。
こういうときはこうする、というしくみや手順を決めて、それに沿って個々の施策の準備を進めることで、抜け漏れを防ぎ、「狙いと実現手段と期待効果」が見えている仕事にすることができます。
さらに再現性をもって臨めるので、回数を重ねることで良かったことと悪かったことが浮き彫りになり、ノウハウもたまります。対象業務の幅を広げて応用すれば、ケース1のようなしくみでもカバーは可能でしょう。
自社のレベルに応じた対策を
以上2つのケースをもとに、いまだ埋まらない部門間の溝の話をさせていただきました。ケース1と2はそれぞれ、違う立場かつリテラシーも異なる事例です。
そのため解決策がまったく同じということはあり得ません。ただ、さまざまな解決手法が世の中に出てきているのは事実で、それは同じような課題を抱えた人がたくさんいるということです。
自分たちだけが特殊だと感じてあきらめてしまわずに、さまざまな新しい手法も自社流にアレンジして取り入れながら、ひとつひとつ目の前の問題を解決していきましょう。その先にはきっとストレスの減ったよりよい現場の姿が待っていることでしょう。
記事を書いた人
菊次渉