250万人の会員基盤を支えるシステム刷新。東急がBacklogで実現した、グループ横断の「自走するプロジェクト」

鉄道から都市開発まで幅広い事業を展開する東急株式会社。同社は、会員数250万人規模のポイントシステム刷新という大規模プロジェクトに、Backlogを活用して臨みました。東急グループ各社から集まった総勢150名は、どのようにしてBacklogでチームワークを発揮したのか。プロジェクトの中核を担うメンバーにお話を伺いました。

本プロジェクトの取り組みは、2025年12月に開催された「Good Project Award 2025」でも登壇いただきました。

250万人の会員基盤を支えるシステム、20年目の刷新

── まずは御社の事業概要と、今回のプロジェクトの背景を教えてください。

東急グループは鉄道を中心にした「街づくり」を事業の根幹に置き、不動産、生活サービス、ホテル・リゾート事業など、幅広い事業を展開しております。

お客様とのリアルな接点は多いのですが、デジタル領域の展開はまだまだこれからという状況でした。そこで、両者を融合していく取り組みの一環として立ち上がったのが、「ポイントWeb更改プロジェクト」です。

東急グループ共通のポイントサービス「TOKYU POINT」は、鉄道、スーパー、百貨店、ショッピングセンターなど、さまざまな場所でご利用いただいており、会員数は約250万人に上ります。しかし、サービスが始まってから約20年が経ち、設計の老朽化によってシステムのアジリティが低下していました。

そこで、まずモバイルアプリや会員Webサイトのシステムを刷新するためのプロジェクトが、2023年にスタートしたのです。ただ古いシステムを作り直すだけでなく、主要機能の内製開発を実現し、今後の機動力を高めることが目的です。

── プロジェクトを進める前に見えていた、「困難なハードル」は何でしたか？

第一は、“関係者の多さ”ですね。TOKYU POINTに関わるグループ会社は、東急カード、東急電鉄、東急百貨店、東急ストア、東急モールズデベロップメントなど多岐にわたりますし、関連するシステムは20にも及びます。

東急にはフラットな企業文化がありまして、グループ会社の意見を尊重しながら進めていくという姿勢を大事にしています。トップダウン的なやり方は馴染まないため、各所との丁寧な意見調整にはどうしても時間がかかってしまうんです。

── いくつものグループ会社が関わる大規模なプロジェクトだったのですね。その中で、Backlogの導入を判断された経緯を教えてください。

プロジェクト管理ツール自体は、システム部門の中でいくつか使っていました。小規模なプロジェクトであれば、我々がすべてのタスクを起票してもいいのですが、今回のように関係者が多いプロジェクトでは、関わるメンバーが自ら起票し、期限を守って自発的に動いていただく必要があります。

そうなると、システム・ビジネス問わず「すべてのメンバーが使いやすく、親しみやすい」という点が最も重要です。過去に、エンジニア向けのプロジェクト管理ツールの利用をビジネス側へ呼び掛けたものの、定着しなかった経験もありました。

その点、Backlogは誰でも触りやすい設計になっています。ちょうど別のプロジェクトでBacklogを使い始めていたこともあり、そのときのテンプレートや運用の考え方を参考にして、ポイントWeb更改プロジェクトへの導入を決めました。

「情報はすべてBacklogにある」という状態をつくる

── Backlogのアカウント数は、グループ全体で150名に上ったと聞いております。この規模のプロジェクトでBacklogを浸透させるために、どのような工夫をされたのでしょうか？

まず、プロジェクト計画書に「このプロジェクトのタスク管理はBacklogを使う」と明示して、全体に周知するところから始めました。

そのうえで運用ルールを定めて、Backlog内にドキュメントとして記載。たとえば、

・誰に何を決めてもらう課題なのか
・課題詳細欄にはどのようなことを書かなければいけないのか
・運用上どうすれば「完了」とできるのか

といった、課題起票において留意すべきポイントを明文化したのです。

── Backlogでよく使う機能はありますか？

あらかじめ記入すべき事項を設定しておける「課題のテンプレート」を活用しています。他部門への作業を依頼する場合は依頼概要のみではなく、起票者には「期限日の設定理由」や、「課題の完了条件」を記載するように促しました。。

というのも、プロジェクト当初は「締め切りの温度感」がわからなかったんです。期限日は絶対厳守なのか、少し猶予があるのかはっきりしなかったので、テンプレートに最初から組み込むようにしました。

── 会議体の運営にも、Backlogを活用されていたそうですね。

会議のアジェンダは事前にBacklogに登録しておき、その中に各議題の関連資料を貼り付けることで、Backlogを見ながらタスクの進捗確認や議論ができるようにしました。会議の議事録も、Backlogに記載していました。

「このプロジェクトの情報はすべてBacklogにある」という状態を作ったことで、Backlogの利用が自然と業務のルーティンに組み込まれていきました。

── 利用するほかのメンバーからは、Backlogへの抵抗感などはありましたか？

大きな拒絶反応はなかったと記憶していますが、ビジネス部門では「自分でタスクを登録するのは初めて」という方がほとんどでした。そのため、“プロジェクトの進め方”を理解してもらうのに最初は苦労しました。業務を分解して整理するとはどういうことか、考え方がなかなか伝わらなかったんです。

そこで、資料を一緒に開きながら具体的な使い方や進め方をレクチャーするなど、手取り足取りのフォローを徹底。あわせて、会議のアジェンダや議事録をすべてBacklog上に集約し、「Backlogを見る・触る」機会を増やしたんです。日々の業務ルーティンにBacklogを組み込んだことで、徐々に浸透していったと感じています。

── セキュリティの面ではいかがですか？

グループ会社ごとにセキュリティポリシーが異なるので、その点は工夫が必要でした。たとえば東急カードでは、常に個人情報を取り扱う関係上、外部への情報発信ツールを非常に厳しく制限しています。そのため、事前に運用ルールを厳密に策定した上で、Backlogを利用できるようにしました。こうした調整も、一つひとつ丁寧に進めていきました。

「Backlogに起票しますね」が合言葉に

── 「ポイントWeb更改プロジェクト」において、Backlogを活用したことによる効果をお聞かせください。

いちばんは情報の可視化です。Backlogには、やり取りの履歴がそのまま残るので、決定事項だけでなく、そこに至るまでの経緯も明確に追えるようになります。設計書だけだと「なぜこの仕様になっているのか？」がわからないことがありますが、Backlogならそこに至った背景や理由が残っているんです。

また、「タスク漏れ」を避けられるようになったことも大きいです。短いサイクルで動いていると、タスクを一つ忘れただけで、のちのち大きな問題になりかねません。でも、いったんBacklogに登録してしまえば、たとえ対応が遅れたとしても、少なくとも漏れることはありません。早期にリスクを発見して、対処できるようになりました。

── ビジネス部門にも変化はありましたか？

メールやチャットでいきなり相談するのではなく、自分の中で整理してから持ってきてくれるようになりました。期限を意識し、論点を絞り込んだ上で相談してくれる。そういう動き方が身に付いていったように感じます。

それから、証跡を残す文化が根付いたことも大きな変化です。以前は打ち合わせで何か依頼事項があっても、口頭で終わることも多かったんです。それが今では、相手から「Backlogで起票しておきますね」と言ってくれるようになりましたね。

今はシステム開発だけでなく、日々の業務運用やサービス保守の課題管理などでもBacklogが使われるようになりました。

Backlogがプロジェクト管理から、サービス運営の基盤へ

── 2026年2月に無事リリースされたのですね！

やっと峠は越えた、という印象です（笑）

付随するサービスや機能をこれからもアップデートしていく予定ですし、運用フェーズに入ると障害対応や顧客からの問い合わせ対応など新たな課題も見えてきます。

── これからもプロジェクトは続いていくんですね。これまでの道のりを振り返って、今の感慨はいかがですか？

実は、10年以上前にもシステム刷新を試みたのですが、さまざまな理由で進みませんでした。プロジェクト管理も、メールやエクセルの世界ではなかなか難しく、結局頓挫してしまいました。今回も途中でスケジュール変更してリリースまで３年を要しましたが、ようやく形にすることができたという思いが強いです。

今回のプロジェクトには、意識的に若いメンバーに入ってもらいました。サービスやアプリというものは、作って終わりではなく、常に改善・改良を加えていく必要があります。そのため、システム部門だけでなく、ビジネス部門でも、「運用フェーズまで見越して要件を固める」という仕事の進め方を学んで欲しいという意図がありました。結果的に、「プロジェクトを通じて人を育てる」ことができたかと思います。

── リリース後は、Backlogをどのように活用されているのですか？

Backlogによるコミュニケーションが定着したので、今は、新しいプロジェクトを立てて、障害対応や不具合管理に利用しています。たとえば、システム側でアラートが発生した際、重要度の高いものはBacklogに自動で起票されるようにしています。従来だとメーリングリストの中に埋もれてしまっていたお問い合わせや、担当者が気づいた不具合などもBacklogに集約できるんです。

── プロジェクト管理だけでなく、運用フェーズの基盤としても活用されているのですね。

プロジェクト管理ツールというと身構えてしまう方もいますが、Backlogは「サービス管理ツール」としても使えると考えています。お客様対応もシステムエラーも一元的に管理できるツールとして、非常に有効だと感じています。

── 今後の展望についてお聞かせください。

今後もどんどん新しいプロジェクトが生まれていきますし、世代も入れ替わります。新しい人が加わったときに、ナレッジが自然と引き継がれていく仕組みが大事だと考えています。

今回、プロジェクトの知見をBacklogに集約したおかげで、「あのときどう対処したか」が記録として残り、ナレッジが継承されていく仕組みができつつあります。

あとはAI技術も活用したいですね。Backlogでは、ひとつの課題に対するコメントの量が膨大になると、結論が埋もれてしまうという悩みがありましたが、「Backlog AIアシスタント」を活用することで効率化できそうです。一人ひとりが自力で求める情報にたどり着ける環境が整えば、管理者の負担軽減も実現できると期待します。

── 150名がチームワークを発揮し、大規模プロジェクトを完遂されたご経験をご共有いただきました。貴重なお話をありがとうございました！

※掲載内容は取材当時のものです。