第3回:25年越しの負債に?「ゴッドテーブル」が招くシステム統合の罠
約12分

第3回:25年越しの負債に?「ゴッドテーブル」が招くシステム統合の罠

目次

TL;DR(超要約)

ID統合を阻む「真の壁」:最大の懸念はシステム改修ではなく、現場で定着している「業務運用フロー」の変更に対する恐怖心です 。

「ゴッドテーブル」の罠:特定のアプリに依存したユーザー管理(密結合)は、機能拡張を妨げる甚大な技術的負債となります 。代表の須藤が在籍していたTopcoderでは、この負債の解消に25年を要しました 。

Tactnaが導く解決策:APIベースの疎結合な設計により、既存の運用フローを壊さず、段階的に移行することが可能です 。

AIエージェント時代への備え:人間だけでなくAIやデバイスが「1つのID」でサービスにアクセスする未来において、「変化に耐えうる構造」を今手に入れることがビジネスを加速させます 。


はじめに

こんにちは、TC3のコーポレート部の麻生です。

恒例となりつつある第3回目のTactna座談会を開催しました。前2回の議論では、ID統合の重要性や技術的な基盤について深掘りしてきましたが、今回はより踏み込み、「なぜ多くのお客様がID統合に二の足を踏むのか」、そして「真にビジネスを加速させるユーザー管理とは何か」をテーマに熱い議論が交わされました。

参加者は、弊社代表の須藤をはじめ、エンジニアの岩倉、眞田、そして私、麻生の4名です。現場での苦労話から、須藤が過去に経験した「25年越しの技術的負債」の裏話まで、ここだけでしか聞けないエッセンスを凝縮してお届けします!


1. 「ID統合しなきゃ……」でも、なぜ一歩が踏み出せないのか?

麻生: 過去2回の対談を通じて、Tactnaがどれだけ安全で、自社で作るより圧倒的にコスパが良いかは、よく分かりました。でも、実際にID統合をするにあたって、「理屈はわかるけど、今まさに動いているシステムをいじるのは怖すぎる!」っていうお客様の葛藤もあると思うんですが.......

須藤: いやあ、その「怖い」っていう感覚、実はめちゃくちゃ正しいんですよ。ID統合をしようとスタートラインに立つと、どうしても2つの大きな「辛さ」が立ちはだかります。 1つは、これまで使ってきた認証の仕組みを別のものに変えなきゃいけないというシステム的な辛さ。 そしてもう1つが、「すでに現場で完璧に回っている業務運用フローを全部変えなきゃいけない」っていう、運用側の辛さです。

岩倉: 特に後者ですよね。システム的な改修コストは見積もれますが、運用フローの変更は影響範囲が広く、ビジネス全体が揺らぐ可能性があります。例えば、コールセンターの対応フローやユーザーの登録プロセスなど、現場が慣れ親しんだフローを変えることへの尻込みが、統合を阻む最大の要因になっていると感じます。

眞田: 運用負荷が高いからこそ、そこを「いかに今のフローを妨げずに段階的に移行できるか」がポイントになりますね。一度にすべてを変える「ビッグバン」ではなく、徐々に変えていけるという確信が持てれば、お客様も一歩踏み出せるはずです。


2. Tactnaが提供する「運用の壁」への回答

須藤: Tactnaが目指しているのは、まさにその「ハードルを下げる」ことです。TactnaはAPIベースなので、既存のオペレーションを極力変えずに導入できる。

眞田: 「サービス単位で疎結合(そけつごう)にする」という設計思想ですね。これによって、IDのライフサイクル、つまりユーザーがいつ使い始め、いつ属性を変え、いつ利用を停止するかというルールを、サービスごとに自由に決めることができます。

岩倉: 実際のお客様の案件でも議論になりましたが、「サインアップ(新規登録)はTactnaに任せ、ログイン後の処理は各アプリで行う」という標準的な形を提案することで、アプリ側のロジックをシンプルに保てます。お客様の既存フローを壊さず、かつ新しい基盤の恩恵を受けられるバランスですね。

須藤: IDとパスワードの管理といった「セキュリティの肝」は統合しつつ、その他の業務プロセスは最小限の変更で済む。この「段階的な移行プロセス」こそが、Tactnaを選んでいただく大きなベネフィットになると確信しています。

眞田: 「どこから手をつけていいか分からない」というお客様に、「まずはIDのライフサイクル(登録から削除までの一連の流れ)を確定させましょう」という「型」を提供できるのが、我々の最大の強みですね。


3. 「ゴッドテーブル(神テーブル)」の罠とTopcoderの教訓

麻生: 座談会の中で、須藤さんがおっしゃっていた「ゴッドテーブル」という言葉が印象的でした。これはどういう意味でしょうか?

須藤: ユーザー管理というのは、すべてのアプリにとっての「肝」となる。だからこそ、特定のアプリが持つデータベース内にユーザー情報を置いて、それを全アプリから参照しようとする「神のようなテーブル(ゴッドテーブル)」を作りがちなんだ。でも、これは非常に危険な罠なんですよ。

眞田: 特定のアプリに寄せてしまうと、そのアプリの改修が全システムに影響したり、他ベンダーが手を出しにくくなったりと、密結合(みつけつごう)による弊害が噴出しますね。

須藤:そうなんだよ。複数のアプリという話だけでなく、1つのシステムの機能拡張を「長年続けていくことでも同様のことが起こるんだ。

「Topcoder」(須藤がTC3創業前にR&Dのヘッドとして在籍していた世界最大級の競技プログラミングコミュニティの運営企業)での経験が、まさにTactnaの原点になっている気がするよ。

Topcoderは10年以上続いていたシステムだったんだけど、ユーザーテーブルを特定の古いデータベースの中にガッチリ作っちゃって、そこに複数のサービスや機能からそれぞれ変更・増築を加えているという、どうしようもない状況になっていたんだ。

麻生: 優秀なエンジニアがたくさんいても、改善できなかったんですか?

須藤: それがね、できなかったんですよ……。当時は最大で200人くらいの組織でしたが、あらゆる機能がその「ゴッドテーブル」と密結合をしていて、修正の影響範囲が誰にも把握できなかった。僕が在籍していた時も、なんとか応急処置はしてきたけど、根本的な解決はあまりにコストがかかりすぎて手が出せなかったんだ。

麻生: 脱却するのにどれくらいかかったんですか?

須藤: 結局、根本的な解決ができたのは昨年末って聞いたから、25年も経ってからだね。あまりに密結合になりすぎて、職人芸を要するメンテナンスが必要となり、ビジネスの発展を大きく妨げていた。この「負の遺産」の恐ろしさを知っているからこそ、ユーザー管理は特定のアプリから切り離し、抽象度の高い独立した基盤として構築しなければならないんだ。


4. Build vs Buyの分水嶺:なぜ「自前」ではなくTactnaなのか

岩倉: 確かに、お客様の中には「自分たちでスクラッチで作ったほうが楽ではないか」と考える方もいらっしゃいます。でも、実際に自前で共通基盤を作ろうとすると、結局Tactnaと同じようなものを作ることになりますよね。

須藤: そうなんだよね。複数のアプリが共通のユーザー情報をCRUD(作成・読み取り・更新・削除)するための「ルール」を誰が決めるのか、という問題に行き着く。

眞田: 例えば、「Excelで管理しているユーザー一覧を、複数のアプリが同時に更新しようとしたらどうなるか?」を想像すると分かりやすいです。誰が上書きしていいのか、どの属性が優先されるのか。この複雑な「交通整理」のインターフェースとノウハウを、すでにパッケージ化して持っているのがTactnaなんです。

須藤: 自前で作るとなると、そのルール決めから実装まで膨大な時間がかかるし、結局は特定のアプリの仕様に引っ張られて、また新たな「ゴッドテーブル」を生むことになりかねない。Tactnaを「Buy(購入)」することは、単なるシステム導入ではなく、将来にわたってビジネスの俊敏性を保つための「整理された設計図」を手に入れることなんだ。


5. セキュリティの大前提:「1ユーザー、1ID」への回帰

岩倉: 今後の標準として、私たちが強く推奨していくべきなのは「1ユーザーにつき1ID、1メールアドレス」という大前提ですね。

須藤: その通り。過去の経緯でIDを共有してしまっているようなケースもあるけれど、昨今のセキュリティ標準を考えれば、現時点ではそこは譲れないポイントだね。メールアドレスをIDの主要な属性に据え、個人のアイデンティティを確立すること。これができていない組織は、これからのDXも進まないだろうと思います。

眞田: 今後は、より安価に始められるステップアップ型のライセンス構成なども考えていきたいですね。最初はシンプルな管理から始め、徐々にマイページ機能や高度な統合へと進んでいけるような。

須藤: 「ゆりかごから墓場まで」じゃないけれど、システムの立ち上げ期から大規模統合期まで、一貫して寄り添えるプロダクトにしていきたいね。


6. 未来への視座:AIエージェント時代の「ID管理」

須藤: 最後に、未来の話を少し。ID統合は、単なるシステムの整理整頓だけではない、というのも重要なポイントだと思います。これからAIエージェントが「1つのID」を持って、人間と同じようにサービスにアクセスする時代が、もうそこまで来ています 。

眞田: 人間、AI、エッジデバイス……。これら多様な「主体(サブジェクト)」が複雑に関わり合う時代において、バラバラの基盤で管理し続けるのは、もはや不可能です 。

須藤: Topcoderのような25年の苦労を、皆さんが繰り返す必要はありません 。今のうちからTactnaという「整えられた箱」にIDを入れておくことで、将来AI活用が本格化したときにも、スムーズにシステムを適応させることができる 。 「認証を作る」のではなく、「未来のビジネスの変化に耐えうる構造を買う」 。この視点を持つことが、プロジェクトを成功させ、ビジネススピードを加速させる最短ルートだと確信しています 。


編集後記

今回の座談会で浮き彫りになったのは、ID統合の本質が「データの整理」だけでなく「ビジネスの自由度を取り戻すこと」にあるという点です。

特定のアプリとユーザー情報が密結合した「ゴッドテーブル」は、将来のビジネス拡張を妨げる足かせとなります。既存の運用フローを大切にしながらも、安全かつ段階的にこの負債から脱却し、変化に強い基盤を作る。そのための具体的なプロセスとノウハウが、Tactnaには詰まっています。

「今の運用を変えるのは難しいが、将来を見据えた統合は進めたい」という課題をお持ちであれば、ぜひ私たちにご相談ください。Tactnaをぜひご検討いただければ嬉しいです。

検討にあたって検討項目を解説したガイドブックを無料で配布中です。

こちらもぜひご確認ください。




関連記事

第4回:AIに権限をどう与えるか?エージェント時代に問われるIDの意義

第4回:AIに権限をどう与えるか?エージェント時代に問われるIDの意義

【TL;DR】(超要約)AIエージェントによる「プロセスの自動化」: 人間がツールを操作する時代から、AIが自らツールを選び、目的を完遂する時代への転換が始まっています 。「AIのアイデンティティ」管理の必要性: AIエージェントが自律的に動く社会では、その行動に対する権限付与やガバナンスの管理が、...
続きを読む
第2回:「作るより、買うが正解」開発工数4割削減を叶えた、Tactnaの狂気的なインフラ思想

第2回:「作るより、買うが正解」開発工数4割削減を叶えた、Tactnaの狂気的なインフラ思想

TL;DR(超要約)自社で認証・管理機能を開発すると、高額な維持費(年2,000〜3,000万円)やセキュリティリスクが発生します。開発工数の30〜40%を占めるアカウント・権限管理機能をTactnaで「買う」方が、自作するより圧倒的にコスト効率が良い(年間数百万円)です。開発者権限の時間制限や、特...
続きを読む
第1回:SSO導入で満足?現場を疲弊させる「見えない負債」の正体

第1回:SSO導入で満足?現場を疲弊させる「見えない負債」の正体

TL;DR(超要約)IDaaSが解決するのは「ログイン(認証)」のみ。「ユーザー管理」機能は自作が必要アプリが増えるたびに管理機能を自作・再構築することが「見えない負債」となるこの負債の主な原因は、壊れたから直す保守ではなく、成長のための機能拡張自作の管理機能は、セキュリティリスクの温床となり、対応...
続きを読む