【事例】マーケ・企画が開発の成果物にどう関わったか｜コードを書かない役割

システム開発において、マーケティング担当や企画職が「技術のことはエンジニアに任せている」と口にするのは、一見すると専門性を尊重しているように聞こえますが、実務上は非常に危険なサインです。エンジニアが責任を持つのは「コードの品質」や「システムの安定稼働」であり、そのシステムが「誰を幸せにし、どう利益を生むか」というビジネスロジックの正当性に責任を持てるのは、マーケ・企画側しかいないからです。

本記事では、コードを一行も書かない「非エンジニア」の担当者が、開発プロジェクトにおいてどのようなアウトプットを出すべきか、その具体的な実務手順を解説します。単なる「お願い」ではなく、開発側が迷わず実装に移れる「入力（インプット）」を定義することが、プロジェクト成功の唯一の道です。

マーケ・企画が「開発の成果物」に責任を持つべき理由

エンジニアが書くのは「コード」であり「ビジネスモデル」ではない

エンジニアの職能は、与えられた仕様を最も効率的かつ堅牢なコードに落とし込むことです。しかし、例えば「会員登録時にクーポンを付与する」という仕様があったとき、そのクーポンが「即時利用可能か」「有効期限の計算ロジックはどうあるべきか」「不正取得を防ぐための判定ロジックは？」といったビジネス上の細かな判断は、マーケティング戦略に紐付くものです。ここを曖昧にすると、エンジニアは「最も実装しやすい形」を選択せざるを得ず、結果としてマーケティング施策として成立しないシステムが出来上がります。

非エンジニアが開発に関与しないことで起きる「3つの悲劇」

• データの孤立化（サイロ化）： 現場の運用を考慮せずにシステムを作った結果、必要なデータが取得できなかったり、既存のCRM（顧客管理システム）との名寄せができなかったりする。
• 例外処理の放置： 「ユーザーが途中で離脱した場合」「ネットワークが切れた場合」など、正常系以外のケースが考慮されておらず、リリース直後にカスタマーサポートがパンクする。
• 拡張性の欠如： 3ヶ月後のキャンペーン展開を考慮せずにガチガチの設計をしてしまい、軽微な文言変更やバナー差し替えにすら開発工数が必要になる。

【実務手順】コードを書かない役割が担うべき「5つの定義」

エンジニアに「これを作ってください」と伝える際、最低限揃えておくべき5つの要素があります。

1. ユーザー体験（UX）と画面遷移の完全言語化

FigmaやAdobe XDなどのデザインツールを使うのも手ですが、非エンジニアにとって最も重要なのは「ステータス遷移」の定義です。ユーザーがログインしているか、未ログインか。課金ユーザーか、無料ユーザーか。それぞれの状態で「何が見え、何ができないか」をマトリクスで整理します。

2. ビジネスロジックの例外処理（準正常系）の洗い出し

開発が最も困るのは「想定外の挙動」です。企画側はハッピーパス（すべてがうまくいく手順）だけでなく、以下の「もしも」を定義してください。

• 入力フォームで全角・半角が混在した場合はどうするか？
• 決済が失敗した際、ユーザーにはどのようなメッセージを表示し、どの画面に戻すべきか？
• クーポンが上限枚数に達した瞬間にアクセスしたユーザーには、何を見せるか？

3. データ項目の定義と「名寄せ」のルール設計

システム間でデータを連携させる際、キーとなる項目（IDなど）の設計は企画側が主導すべきです。例えば、LINE公式アカウントと自社サイトを連携させる場合、どのタイミングでLINE IDと会員IDを紐付けるのか。その設計が甘いと、後からデータ分析を行うことができません。詳細な設計については、以下の記事も参考にしてください。

WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ

4. 外部システム・SaaSとの疎通要件

現代の開発で、単体で完結するシステムは稀です。決済代行、MA、SFA、会計ソフトなど、複数のSaaSが絡み合います。企画側は、各SaaSが提供するAPIの仕様を（コードは読めずとも）公式ドキュメントで確認し、「何ができるか」の限界値を把握しておく必要があります。

5. 受け入れテスト（UAT）のシナリオ作成と実施

「バグがないこと」を確認するのはエンジニアの仕事ですが、「業務が回ること」を確認するのは企画・マーケ側の仕事です。実際の業務フローに基づいたテストシナリオ（例：商品Aを購入し、キャンセルを行い、返金処理が正しく行われるか）を作成し、自らテスト環境を触って検証します。

マーケ・企画が主導する「ツール選定」の比較と判断基準

ツール選定において、機能の有無だけで選ぶのは失敗の元です。特に「他システムとの連携性」と「データの抽出性」を重視すべきです。

【比較表】データ連携・MA・SFAツールの評価マトリクス

例えば、高額なMAツールを導入しても、基盤となるデータが整理されていなければ宝の持ち腐れになります。逆に、必要な機能だけに絞り込み、BigQueryなどのデータ基盤を活用して「必要な時だけ動かす」構成の方が、コストも運用負荷も抑えられるケースが多いです。

高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャ

【事例】ノーコード・ローコード開発における「企画の役割」

最近では、プログラミングを必要としないノーコードツールや、最小限の記述で済むローコードツールの活用が広がっています。これにより、企画側が「成果物そのもの」を作る機会も増えています。

AppSheetやGoogle Workspaceを活用した内製化事例

Excelや紙での管理から脱却するために、Google WorkspaceのAppSheetを活用するケースが増えています。ここで企画側が担うべき役割は、エンジニアリングではなく「データベースの正規化」に近い思考です。どの情報をどのシートに持たせるか、重複をどう避けるかという「情報の整理整頓」が、アプリの使い勝手を決定づけます。

Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

LINE公式アカウントとCRMの高度な連携設計

マーケティング施策としてLINEを活用する場合、単にメッセージを送るだけでなく、Webサイト上の行動データと連携させることが求められます。この際、エンジニアには「連携機能の実装」を依頼しますが、企画側は「どのユーザーに、どのタイミングで、どのリッチメニューを表示すべきか」という動的な制御のロジックを設計しなければなりません。

開発現場でマーケ・企画が陥る「よくあるエラー」と対処法

プロジェクトを遅延させ、成果物の品質を著しく低下させる要因は、多くの場合コミュニケーションエラーにあります。

エラー1：開発中盤での「仕様追加・変更」

開発がスタートしてから「やっぱりこの機能も追加したい」というのは、建築で言えば「基礎を打った後に地下室を作りたい」と言うようなものです。
【対処法】: 最初の企画段階で「MVP（Minimum Viable Product：最小限の機能を持つ製品）」を明確に定義し、それ以外の機能は「フェーズ2」以降に回すという合意形成を最初に行っておくこと。

エラー2：データの「持ち方」を考慮しないUIデザイン

画面上は1つの項目に見えても、裏側では複数のデータベースから情報を引っ張ってこなければならない場合、表示速度が極端に落ちることがあります。
【対処法】: デザイナーや企画者が画面案を作る際、必ずエンジニアに「このデータを表示するのに、どれくらいの負荷（または工数）がかかるか」をクイックに確認する癖をつけること。

エラー3：本番環境とテスト環境の不一致

企画側がテスト環境で確認して「OK」を出しても、本番環境のデータ量や連携しているSaaSの設定が異なると、リリース当日にエラーが発生します。
【対処法】: リリース前に、本番相当のデータ（匿名化されたもの）を用いた最終テストの時間を確保するよう、スケジュールを企画側から死守すること。

まとめ：コードを書かない役割こそが「プロダクトの価値」を決める

システム開発の成功は、書かれたコードの行数ではなく、そのシステムが解決する課題の深さで決まります。マーケティングや企画の担当者は、コードを書かない代わりに、以下のことに責任を持つべきです。

• ビジネスルールの厳密な定義（あいまいさを排除する）
• データ活用の出口設計（作った後にどう使うかを決める）
• 部門間の調整と合意形成（開発がスムーズに進む環境を整える）

「エンジニアに任せる」という姿勢を捨て、システムの「仕様」という名のビジネスデザインに深く関わること。それが、開発プロジェクトの成果物を真に価値あるものに変える、唯一の方法です。

3. **追記するHTMLだけ**（通常は `