1．私が情報システム部門で感じた疑問

私が在籍していた化粧品会社は、スキンケア商品の定期購買型ECビジネスを展開していました。
インターネットを主要チャネルとし、新規顧客の獲得と継続購入を重視するビジネスモデルです。
そんな事業会社にSI業界から転身し、情報システム部門の責任者候補として採用された私は、会社全体が見えてきた際、いくつか疑問を感じることが出てきました。

システム開発案件の対応優先度の決め方

情報システム部門では、ECシステムからお客様に商品をお届けするまでの、いわゆるフルフィルメント業務を担うシステムを開発・運用していました。それゆえに、システム開発の依頼元になる部門は基幹業務に関わる全部門で、例えば、次のような依頼が来ます。

●新規顧客獲得の担当者：
「Cookie規制に対応しないと新規獲得できなくなる」
「eメールの開封率が下がっているからアプリを作りたい」

●LTVを向上させたい接客担当者：
「新商品の販売を早くしたい」
「クロスセル、アップセルしやすそうな顧客リストを抽出できないか」

●メールで届く注文変更などを行うバックオフィス担当者：
「注文変更をメールではなく、顧客側で行うことができる仕組にできないか」
「発送後商品の一部が返品された時の返品業務をシンプル化できないか」

●出荷担当者：
「今の配送業者から値上げの話が来ているので他社に変えたい」
「紙の同梱物のピッキングミスを防止するための仕組を入れて連動させたい」

担当によって責任を持たされているKPIがあるため、そのKPIを達成するために、目的や規模の違う色々な依頼が舞い込んできます。
当時は、各依頼部門の担当者とシステム開発担当者の間のみで優先度調整がなされ、ある意味「早い者勝ち」基準でスケジュールが決められていることに違和感がありました。

効果が見えない施策や効果がない施策の継続

顧客に継続購入や追加購入をしていただくための色々な施策があったのですが、その中に効果が見えないものがあったり、効果がないことがわかっているのに続けるものがありました。例えば、次のようなものです。

●荷物に多くの紙の案内を同梱：
年配の顧客が多かったこともあり、デジタルに不慣れな顧客への配慮ということで、新製品の発売や、購入回数特典の予告案内などを紙で1枚1枚、顧客に合わせて、お届けする荷物に同梱していました。
しかし、顧客が同梱された案内を見て商品購入に至ったかを追跡できる仕組になっておらず、手間やコストをかけて、案内を同梱することに効果があるのかがわからない状態でした。

●限定品の先行予約：
限定品を販売する企画が立ち上がり、「長期利用顧客が買い逃してしまうことを避けたい」という配慮から、先行予約ができる仕組を用意しました。結果的に、発売後も商品が早期に売り切れることはなかったことから、販売数を減らさない限りは、先行予約の仕組は過剰であり、長期利用顧客には先行案内だけをすれば充分であると判断できました。
翌年、同じ限定品を販売数を増やして販売することになったにもかかわらず、先行予約対応の依頼が来ました。

会員制度の内容

EC主体でしたので、リアル店舗主体の企業が昨今課題としている「顧客識別」は課題ではありませんでしたが、継続購入や追加購入のために用意している会員制度に課題があると感じていました。例えば、次のようなものです。

●購入回数だけで会員ランクが決まる：
購入3回目でブロンズ、10回目でシルバー…というように購入回数だけで会員ランクが判定される仕組みであったため、3つの商品を1つの荷物にまとめて購入した場合と、3つの荷物に分けて購入した場合で会員ランクが変わる状態であり、容易に制度の穴をつける状態でした。この点については、たくさんの購入をいただいているお客様からの声としても顕在化していた課題でしたので、早く対処する必要性を感じていました。

●使いづらいポイントサービス：
ポイント付与率は一律でしたが、支払いの際に利用することはできず、商品定価と同ポイントを商品と交換できるという制度でした。
長期継続購入する顧客にとっては、一定の魅力がある制度かもしれませんが、新規顧客や購入回数の浅い顧客には魅力があまりないと感じていました。

2．疑問の課題と対策

私が疑問に感じたことの課題を何であると捉えて、どんな対策をしたかを書かせていただきます。

対応優先度は、経営方針と期待効果を基準に判断する

システム開発における優先順位の決定は、単なる技術判断ではなく、経営戦略と密接に関連する重要な意思決定プロセスです。
私が直面した課題は、経営方針がコストダウンよりも新規顧客増加を優先する前提の中で、「1．コストダウンを目的とした開発案件」が先行しているために、「2．新規顧客獲得につながる開発案件」の重要性が後手に回る状況でした。
経営方針が、コストダウンよりも新規顧客増加を優先している状況においては、2→1の順で対応する、また「新規顧客増加につながる案件」が複数ある場合は、期待効果が高い順で優先度を決定していくのがよいでしょう。

情報システム部門は、全ての開発案件を包括的に把握できる唯一の部門であり、戦略的に誤った優先順位の決定を検知し、修正する重要な役割を担っています。この検知機能は、単なる技術的な調整を超え、経営の意思決定に直接的な影響を与える戦略的な機能と言えるでしょう。

私が課題と捉えたことと、対策は次の通りです。

●課題：
・対応優先順位を決める際の判断基準が曖昧である。
●対策：
・対応優先順位を決める際の判断基準は「経営方針」と「期待効果」と決めた。
・システム開発依頼の際に「経営方針のどれにつながるものか」「想定期待効果」を共有してもらうようにした。

効果的なシステム開発の優先順位決定には、経営方針との整合性、案件の戦略的価値、期待される成果の定量的評価が不可欠です。
情報システム部門は、これらの要素を総合的に評価し、企業の成長戦略に貢献する重要な役割を果たすことが求められています。

効果測定できる仕組は必須、施策の評価は関連した全部門で実施

施策の成功を評価するためには、単に実施するだけでなく、その効果を科学的かつ客観的に測定することが不可欠です。
効果が不明確な施策に対しては、効果測定の仕組みを組み込む必要があります。

紙の同封物による販促施策において、顧客の購買を追跡できない課題がありました。
この問題を解決するために同封物に記載するECサイトのURLを追跡可能な形式に変更し、正確な流入元と購買効果を測定できるようにしました。これにより曖昧だった施策の実際の影響力を明確に把握できるようになりました。

また、先行予約のような非効率な施策が継続されていたのは、前年の施策評価を主幹部門だけしか実施しなかったことによって、主な目標値（売上や利益）をクリアしたかどうかだけで判断してしまい、施策の無駄や非効率性に気づけなかったことが原因です。

私が課題と捉えたことと、対策は次の通りです。

●課題：
・施策を実現することが目的になってしまっている。
・施策の評価を主幹部門の指標だけでおこなってしまっている。
●対策：
・施策の設計段階で、施策開始後に効果測定ができる仕組をきちんと検討することを提案した。
・施策の評価会には、関連した全部門が参加することを提案した。

効果的な施策評価には、関連するすべての部門が参画し、多角的な視点から施策を検証することが重要です。
単一の部門や限られた指標だけでなく、顧客体験、コスト効率、戦略的整合性などを総合的に評価することで、真に価値のある施策を見極めることができます。

重要なのは、データに基づいた意思決定を行い、常に施策の効果を検証する姿勢です。
効果測定は単なる形式的な作業ではなく、継続的な改善と最適化のための重要な戦略的ツールです。

会員制度は、顧客起点で考える

会員制度設計において重要なのは、顧客の視点に立ち、顧客にとって魅力的で公平なサービスを提供することです。
単純に制度を作るだけではなく、顧客の感情や期待に応える制度設計が求められます。
あなたが顧客なら、1点5,000円の商品×3個をまとめて1回で買っても会員ランクが変わらないのに、友人が同じ商品を1個ずつ3回に分けて買ったら会員ランクが上がったという状況に憤りを感じませんか？

また、ポイントサービスは、顧客に継続購入を促すために会員制度として採用されますが、ポイントが貯まりにくい上に一定ポイントまで到達しないと使えないポイントサービスでは、顧客にとって魅力がありません。

私が課題と捉えたことと、対策は次の通りです。

●課題：
・会員制度が公平でない。
・安直な考えでサービスを決めている。
●対策：
・一定期間内の購入金額で会員ランクを更新する制度を提案した。
・ポイントサービスを廃止し、購入金額と継続購入年数で金額が決まるクーポンサービスへの転換を提案した。

会員制度の本質は、顧客との長期的な関係構築にあります。
単なる販促ツールではなく、顧客体験を向上させ、ブランドへの信頼と愛着を育むものです。
公平性、透明性、そして顧客にとっての明確な価値を兼ね備えることが大切だと言えるでしょう。

3．変革へのカギ

ここまで、情報システム部門時代の自分を振り返り、その時の思考や行動を書かせていただきましたが、私がなぜ疑問に思うことができたかを整理したいと思います。

・案件の優先順位
・施策の効果測定
・会員制度の内容

上の3つの疑問は、自分の役割を「情報システム部門責任者＝ITインフラやシステムの運用」と捉えていると踏み込まなくていい（会社によっては踏み込むことをはばかられる）領域なのかもしれません。しかし、所属する組織の枠に捉われず、自分の役割を「企業が存続するために何をすべきかを考える」と捉えれば、自然と踏み込むことになるのではないでしょうか。

・案件の優先順位⇒「経営方針を念頭に置いて行動する」
・施策の効果測定⇒「データに基づいて判断する」
・会員制度の内容⇒「商品やサービスは顧客起点で考える」

情報システム部門は、社内のあらゆる部門と関係する存在です。
それゆえに、会社全体の動きを俯瞰できる立場であるとも言えます。
さらに、社内のありとあらゆるデータに最も近く、データに基づく判断を一番早くできる立場でもあります。
そんな情報システム部門にいながら、インフラやシステムの運用だけをやるのはもったいないと思いませんか？

私の場合は、部門の垣根も気にせずに意見を言える、風通しのいい企業風土であったことも幸いして、踏み込んだ改善提案とその実施に関わることができ、情報システム部門責任者を経て、最終的に経営企画部門に移ることになりました。

先述しましたが、会社によっては疑問に思っていても変革させるための行動がはばかられることがあるのかもしれません。
「疑問に思っていても言えない」で留まっているとしたら、まず、その原因をさらに分解してみてはどうでしょうか。
「なんとなく疑問に思っているが、明確な根拠がない」のであれば、明確な根拠を集めれば解決します。
根拠を集めるのに自分だけの力では難しいのであれば、他の人に協力してもらえば解決します。
「明確な根拠はあるが、上の方で決まったことに意見するなんてできない」という方もいるかもしれません。
どうして意見できないのでしょうか。「評価に影響するかもしれない」「部門を越えて意見するなんて」とお考えでしょうか？
もしそうであれば、やり方や制度への否定だけで終わるのではなく、「経営方針に沿っていない」「お客様に喜ばれるものになっていない」ことを前面にして、データに基づく具体的な改善提案をすれば、大丈夫ではないでしょうか。

「経営方針を念頭に置いて行動する」「データに基づいて判断する」「商品やサービスは顧客起点で考える」という行動規範は、経営者でなくても、実務に反映させることができるものです。
情報システム部門が経営視点を持って行動することが、経営を支える、ビジネス視点を持った戦略的存在への変革のカギなのではないでしょうか。

4．まとめ

この記事では、情報システム部門で感じた疑問やその対策、変革への姿勢などについて私の実体験を通じてご紹介しました。
情報システム部門が経営視点を持って行動することが、経営を支える、ビジネス視点を持った戦略的存在への変革のカギであり、そのために必要な思考や行動は、以下の2つであると考えます。

・組織の枠に捉われず、企業が存続する（＝社会の役に立つ）ために何をすべきかを考える。
・「経営方針を念頭に置いて行動する」「データに基づいて判断する」「商品やサービスは顧客起点で考える」を行動規範にする。

この記事を通じて、情報システム部門が求められる役割や在り方など、みなさまに少しでもお伝えできなたら幸いです。