「5000人が毎日使うアプリを、3人で作る。」そう言われたとき、正直ゾクッとした。
プレッシャーではなく、純粋な興奮として。
こんにちは、K.Platinum代表の沼田です。
今日は、僕たちが手がけたプロジェクトの中でも特に印象深い案件について書いてみようと思う。大手企業の営業部門、約5000名が日々使う営業支援Webアプリをゼロから設計・開発した話だ。
技術的な話もするけれど、それより「この規模の仕事をどう受注して、どう乗り越えたか」という話がメインになる。K.Platinumがどんな会社で、エンジニアとして何を得られるのかが伝わるといいなと思っている。
このプロジェクトの背景 — 大手企業の営業現場が抱えていた課題
クライアントは大手製造業の会社。全国の営業拠点に5000人規模の営業チームを抱えていた。
聞いた話では、それまでの案件管理は「Excelが中心」だったらしい。担当者ごとに独自フォーマットのシートを作り、それをメールで送り合って集計する。リアルタイムで数字が見えない。モバイルから更新できない。誰がどの案件をどのフェーズで持っているか、上長がリアルタイムで把握できない。
「属人化」と「リアルタイム性のなさ」、この2つが営業現場の慢性的なストレスになっていた。
僕がこの話を聞いたとき、すぐに思ったのは「これは作れる」ということだった。解くべき課題がはっきりしている。技術的に解決可能。あとはどう設計するか、だけだ。
Azureで何を作ったのか — アーキテクチャと技術選定の話
技術スタックはMicrosoftのクラウドサービスを中心に組み立てた。
フロントエンドはReact + TypeScriptで開発したWebアプリ。PCでもスマホでも使えるレスポンシブ設計にした。営業マンが外回りの途中でスマホから案件ステータスを更新できる、というのが要件として最初から入っていた。
バックエンドはNode.js（Express）で構築し、Azure App Service上でホスティング。スケールアップ・スケールアウトが容易な設計にしておいた。5000人が同時アクセスする可能性を考えると、ここは手を抜けない。
データベースはAzure SQL Database。RDBMSを選んだのは、案件のステータス管理・担当者・進捗履歴といった構造化データを扱うのに向いているから。パフォーマンスチューニングにはかなりの時間を割いた。
ファイルストレージはAzure Blob Storage。営業資料や提案書をアップロードして案件に紐づける機能があったので、ここを活用した。
認証基盤はAzure AD B2C（現：Microsoft Entra External ID）を採用。これが一番悩んだ部分なので、次のセクションで詳しく話す。
設計で一番悩んだこと — 認証設計とマルチテナントの壁
正直、技術的にもっとも頭を使ったのがここだ。
クライアントは複数の事業部・拠点を持つ大企業。「事業部ごとに見えるデータを分けたい」「管理者権限も事業部レベルで設定したい」という要件があった。いわゆるマルチテナント設計だ。
Azure AD B2Cは本来、外部ユーザー向けのID管理サービス。ただ今回のケースでは、社内ユーザーでありながら「既存のActive Directoryとの統合がNG」という制約があった。そのため、社内ユーザーであってもAD B2Cで管理するという方針を取った。
一番悩んだのがロールと権限の設計だ。
「誰が、どの事業部の、どの案件を、どこまで見られるか」を定義するマトリクスが複雑で、最初に作ったDB設計は3回作り直した。最終的には「ユーザー」「事業部」「案件」「ロール」の4テーブルが関係するポリシーを、アプリ層で管理する設計に落ち着いた。
Azure側のサービスに任せすぎず、アプリ層でコントロールする。この設計方針が後々の運用でも効いてきた。「あの事業部だけ権限ルールを変えたい」「期間限定でクロス参照させたい」といった現場の細かい要望に、AzureのID基盤を触ることなく対応できる。柔軟性は、こういう場面で効いてくるのだと改めて感じた。
運用して分かった「大規模ならでは」の学び
リリース後、しばらく運用を手伝いながら気づいたことがある。
ピーク時の負荷が想像以上だった。
営業チームは朝イチと夕方に案件ステータスを一斉更新する文化があった。結果、毎日2回、数百〜数千リクエストが短時間に集中する。Azure App ServiceのオートスケールとSQL Databaseのパフォーマンス層を上げることで対応したが、最初の設計で余裕を持っておくべきだったと反省している。
「使われることで分かる課題」がある。
テスト環境でいくら動作確認しても、5000人に実際に使ってもらって初めて分かる課題がある。UIのフローが直感的でない箇所、エラーメッセージが分かりにくい箇所、スマホ表示でタップしづらいボタン。フィードバックをSlackでリアルタイムに収集して、スプリントで次々と改善していった。
監視設計はリリース前に完成させる。
Azure MonitorとApplication Insightsを組み込んでいたので、エラー発生時に即時アラートが飛んでくる。5000人が使うシステムでダウンが起きたら影響が甚大だ。「何かあったらすぐ検知できる」という体制を最初から整えていたことで、クライアントとの信頼関係も保てた。
K.Platinumがこの案件に関われた理由 — 小さな会社の大きな仕事
「なぜK.Platinumに頼んだのか？」とクライアントに聞いたことがある。
答えは「上流の設計から丸ごとお願いできるから」だった。
大手SIerに頼むと、設計チームと開発チームが分かれていて、伝言ゲームが起きやすい。僕たちは設計者が開発もする。要件定義の段階から「これは実装的にこう作った方がいい」というフィードバックができる。そのスピード感と一貫性が評価されたらしい。
会社の規模は関係ない。「何をできるか」と「どう動くか」だけが問われる。
これがK.Platinumが大切にしていることの一つだ。3期目の27歳の会社が、5000人規模のシステムを任される。それは「小さい会社」ではなく「高密度の会社」だからだと思っている。
もし「会社の規模ではなく、自分のスキルと裁量で評価される環境で働きたい」と思うエンジニアがいたら、ぜひ一度話してみたい。詳しい募集要項はこちらのページにまとめてある。
まとめ — 技術力と構想力が重なる場所で仕事をする
このプロジェクトを通じて、改めて実感したことがある。
エンジニアの仕事は「コードを書くこと」じゃない。課題を解いて、価値を届けることだ。5000人の営業マンが毎朝スムーズにアプリを開いて仕事を始められる。それが僕たちの成果だ。
K.Platinumには、こういう「技術×ビジネスインパクト」が直結する案件が多い。SES的な「言われたことだけやる」スタイルとは違う。要件定義から参加して、設計の意思決定にも関わる。そこが面白い。
もしこういう仕事に興味があるなら、ぜひ話しかけてほしい。採用ページも見てみてください。
筆者プロフィール
沼田 海斗 / 株式会社K.Platinum 代表取締役
沖縄高専→トヨタ生産技術→スタートアップITコンサルを経て、24歳で株式会社K.Platinumを設立。現在3期目、27歳。エンジニアギルドの構築を目指し、高専・理工系人材を中心に採用・育成を行っている。キックボクシングとママチャリ日本一周が趣味。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。