【NTTドコモ金融を飲み込む不器用なインフラ】第十二回 ドコモのアプリ「使いにくさ」には理由がある。縦割り組織と開発体制が抱えるUI/UXの構造的課題(全二十五回)
前回、ドコモが「金融ARPU」を稼ぐために通信料金プラン(irumoやeximo)を複雑化させ、ユーザーを自社のエコシステムに縛り付けている構造を解説しました。
しかし、ここで多くのユーザーが抱く「ある素朴な疑問」があります。
巨大なインフラを持ち、4,200億円で銀行を買収できるほどの豊富な資金力がある国内トップ企業。それなのに、「なぜドコモのアプリやウェブサイトは、信じられないほど使いにくく、分かりにくいのか」という疑問です。
IT業界では、画面の見た目やボタンの配置などを「UI(ユーザー・インターフェース:顧客との接点)」、それを通じてユーザーが得られる「使いやすい」「迷わない」といった体験全体を「UX(ユーザー・エクスペリエンス:顧客体験)」と呼びます。
dアカウントの無限ログインループ、目的の画面にたどり着けない迷宮のようなアプリ、解約ボタンが見つからないウェブサイト。私たちが日々感じているこれらの「劣悪なUI/UX」は、決してエンジニアの技術力不足や、偶然によるものではありません。
今回は、使いにくいアプリが生み出される裏側に潜む「大企業特有の縦割り組織」「丸投げの下請け構造」、新聞やネットで話題となる「意図的な悪意(ダークパターン)」に迫ります。
1. 「コンウェイの法則」が証明する迷宮アプリ
IT業界には「コンウェイの法則」という有名な格言があります。
『システム(ソフトウェア)の構造は、それを設計した組織の構造をそっくりそのまま反映する』という法則です。
ドコモのアプリ群は、まさにこの法則の最も残酷な成功例と言えます。
PayPayやLINEなど、後発のITプラットフォーマーは「スーパーアプリ」という概念を持っています。これは、日常のあらゆる手続き(決済、ポイント、クーポン、金融)が、ひとつのアプリ内で完結する巨大で便利なアプリのことです。
一方、ドコモのサービスはどうでしょうか。
スマホの中には「d払い」「dポイントクラブ」「dカード」「My docomo」など、似たような名前のアプリが乱立しています。なぜ、ひとつにまとめられないのか。
それはドコモ内部において、「決済担当事業部」「ポイント担当事業部」「クレジットカード担当事業部」が、それぞれ全く別の(縦割りの)組織として存在しているからです。
各事業部には独自の予算と、絶対に達成しなければならない「KPI(Key Performance Indicator:重要業績評価指標)」が設定されています。
KPIとは、部署や個人の成績を決める「通信簿」や「ノルマ」のことです。例えば「自社アプリのダウンロード数を年間100万件にする」「メルマガ会員を毎月1万人増やす」といった具体的な数字がこれにあたります。
もしドコモ全体で「d払い」のアプリに全機能を統合しようとすると、「我々ポイント事業部の独自アプリがなくなったら、今年のKPI(ダウンロード数)が達成できず、部署の評価やボーナスが下がってしまう」といった社内の強烈な縄張り争い(政治)が起きます。
結果として、各部署が「自分たちの成績(KPI)のための独自のアプリ」をバラバラに作り、後から無理やりリンクで繋ぎ合わせることになります。ユーザーが体験する「別アプリへ飛ばされる」というイライラの正体は、ドコモ内部の「部署間の壁」を、ユーザーにまたがせているだけなのです。
2. SIer丸投げと「WebView」という手抜き
さらに、そのバラバラのアプリの内部構造にも、大企業ならではの「技術的な妥協」が隠されています。
「アジャイル」に動けない外注丸投げ構造
ドコモのような伝統的な大企業は、自社内に多数のプログラマーを抱えていません。システム開発の大部分は、NTTデータなどの「SIer(エスアイヤー:システム開発を請け負う巨大IT企業)」と、その下に連なる何層もの下請け企業に丸投げ(外注)されています。
現代のIT開発では、ユーザーの反応を見ながら小さな修正を素早く毎日繰り返す「アジャイル(俊敏な)開発」が主流です。
しかしドコモの外注構造では、「ボタンの位置を数ミリ直す」という些細な変更ですら、何重もの見積もりと数ヶ月の期間、数千万円のコストがかかります。
これでは、毎日アプリを改善し続ける楽天やPayPayのスピードに勝てるはずがありません。
「WebView」というハリボテの正体
そして、コストと時間を削減するために多用されるのが「WebView(ウェブビュー)」という妥協です。
本来、スマホの性能を100%引き出してサクサク動かすためには、専用の言語で「ネイティブアプリ」と呼ばれる本物のアプリを作る必要があります。しかしドコモのアプリは、動作がモッサリしていて、突然ブラウザ(SafariやChrome)のような画面が開くことがよくあります。
これは、「アプリの枠(ガワ)だけを作り、中身はただのインターネットのウェブサイトを表示しているだけ(WebView)」だからです。この妥協のハリボテ技術が、ユーザー体験を根本から破壊しています。
3. スパゲティコードと「ハンコ文化」が生む悲劇
こうしたアプリの裏側(バックエンド)もまた、絶望的な状態にあります。
ドコモの顧客管理システムは、20年以上前の「ガラケー時代」に作られた古いシステムがベースになっています。そこに新しいサービスを始めるたびに、ツギハギで無理やり線を繋ぎ合わせて増改築を繰り返してきました。
結果として、内部のプログラムは絡み合った麺のように複雑化し、誰も全貌を把握できない「スパゲティコード」と呼ばれる状態に陥っています。
ちょっと手直しをすると別の場所でシステム障害が起きるため、根本的な改善に手を出せないのです。
「ユーザー」ではなく「ハンコ」を向いて作られる画面
さらに、画面の見た目(UI)を決めるプロセスも致命的です。
使いやすい画面を設計するのは専門のデザイナーではなく、総合職の担当者が作ったエクセルの仕様書です。消去法的に、社内の様々な部署の承認(ハンコ)を得なければ実装されません。
・法務部
「クレームにならないよう、規約と注意事項を一番目立つところに全て記載して」
・営業部
「今月はこのキャンペーンを推したいから、トップに巨大なバナーを追加して」
・セキュリティ部
「安全のために、ここで強制的にSMS(ショートメッセージ)による2段階認証を挟んで」
小さなスマホの画面は、びっしり書かれた注意事項と、チカチカする巨大な広告、そして何度も現れるログイン画面で埋め尽くされます。
これは「誰からも社内クレームが出ないように(自分の責任を回避するように)最適化された画面」です。ユーザーの使いやすさは、保身の前に完全に無視されているのです。
4. 「フリクション(摩擦)」が命取りになる金融ビジネス
通信インフラの時代であれば、多少UIが使いにくくても、ユーザーは逃げませんでした。「ドコモの電波」という代替不可能な価値があったからです。
しかし、これからドコモが戦おうとしている「金融エコシステム」の領域では、このUI/UXの劣悪さは致命傷になります。
楽天証券やPayPay銀行を使うユーザーは、「アプリがサクサク動いて直感的に操作できるから」という理由でそれらを選んでいます。
金融サービスにおいて、ログインに手こずったり、エラーで先に進めなかったりする「フリクション(摩擦)」は、そのままユーザーの離脱(資金の流出)に直結します。
5. まとめ
私たちがドコモのサービスを使うたびに感じるイライラや「使いにくさ」。それは決して偶然でも、単なる技術力不足でもありませんでした。
・部署間の縄張り争い(社内政治とKPI至上主義)
・アジャイルに動けない下請け丸投げ構造
・ガラケー時代からのツギハギシステム(スパゲティコード)
・ユーザーより保身を優先するハンコ文化
これら大企業特有の「内部の論理」を、そのまま顧客の画面(UI)に押し付けた結果生み出された、必然的なUXの崩壊。組織とインフラの歪みが、システムを歪め、最終的にユーザーの体験を破壊していく。
そして、この「縦割り組織と複雑に絡み合ったスパゲティシステム」が引き起こす悲劇は、単なる「使いにくさ」だけにとどまりません。過去、この複雑なシステムと組織の隙間を突かれ、日本中を震撼させた大規模な事件が発生しています。
お知らせ
ブログで使用している画像はGeminiで生成したものです。
この文章はAIのサポートで作成されています。
本記事は情報提供を目的としており、特定の投資や政策を推奨するものではありません。
本記事は個人の雑記であり、法的なアドバイスを目的としたものではありません。意思決定に関する最終判断は、ご自身の判断と責任において行っていただきますようお願いいたします。
いいなと思ったら応援しよう!
活動費として使わせていただきます!
よろしくお願いいたします🙇