TMNSolutions

ジェネラリスト型エージェンシーかスペシャリスト型か?本当の見分け方

著者 Emma Trần

ジェネラリスト型エージェンシーかスペシャリスト型か?本当の見分け方

どのエージェンシーも「御社のビジネスを理解しています」と言います。ジェネラリスト型は医療・フィンテック・物流・小売と幅広い実績を並べて「柔軟性の証拠」とし、スペシャリスト型は特定の領域だけに絞ると言って「深さの証拠」とします。営業の場ではどちらも説得力があります。

問題は、どちらが本当に成果を出せるか判断できるころには、すでにプロジェクト開始から3ヶ月が経過しており、予算オーバー、スケジュール遅延、あるいは技術的には動くが本質を外した成果物が手元にあるという状況になっていることです。

この記事は、契約を結ぶ前にその判断を下すためのガイドです。

「スペシャリスト」とは実際に何を意味するのか

多くの人はスペシャリストを技術的な専門性だと思っています。Reactしかやらない、iOSアプリだけ作る、Laravelバックエンドのみ担当する、というイメージです。それも専門性ですが、エージェンシーを選ぶ際に評価すべき種類ではありません。

技術は学べます。優秀なチームなら新しいフレームワークを数週間で習得できます。しかし偽れないのがドメイン知識です。特定の業界がどのように機能するか、実際のエッジケースはどのように現れるか、ユーザーが言うことと実際にすることの違い、そしてある技術的決定が数ヶ月後にビジネス上の結果としてどう波及するか——こうした知識の蓄積こそがドメイン専門性です。

フィンテック専門のエージェンシーは、取引処理システムの構築方法だけでなく、管轄地域によって小額取引がAML審査でフラグされることや、オンボーディングの摩擦が一定の閾値を超えると特定のユーザー層の定着率が崩壊すること、ステージングではきれいに動く照合ロジックが四半期末の取引量で破綻することを知っています。実際に構築し、壊れるのを見て、修正したからこそ知っているのです。

これが本当のドメイン専門性です。特定のコンテキストで繰り返し実際の問題に接触することによってのみ得られる、運用知識です。

「御社の業界で実績があります」は専門知識ではない

この言葉には慎重になるべきです。ほとんどのジェネラリスト型エージェンシーは、正直に言ってこれを言えます。物流会社のダッシュボードを作ったことがある。医療系クライアントの決済ゲートウェイを統合したことがある。飲食チェーンのモバイルアプリをリリースしたことがある。

しかしそれでは専門家にはなれません。

本物のドメイン専門性とポートフォリオの1行を区別するのは、パターン認識の深さです。スペシャリストは同じ種類の問題を十分な回数見てきたため、クライアントが気づく前に何を聞くべきか分かっています。エッジケースを経験しています。v1が何か痛いことを教えてくれた後にv2をリリースしています。何が必要か説明し終わる前に、アーキテクチャについて意見を持っています。

関連する実績が1件だけのジェネラリストは、うなずき、丁寧にメモを取り、指定通りに構築します。仕様の通りに作ることはできます。しかし、仕様が重要な何かを見逃していた場合、それを指摘するだけの知識がないのです。

ドメイン専門性のミスマッチが生む見えないコスト

エージェンシーが深いドメイン知識を欠いている場合、そのギャップは自ら表明しません。ゆっくりと表面化します。

見落とされるエッジケース。 看護師の交代がどのように実際に行われるかを考慮していない医療プラットフォーム。同じ建物内に複数の停車地点があるドライバーで壊れる物流アプリ。通常の取引は正常に処理できるが月末のバッチ照合で失敗するフィンテックツール。これらはコードのバグではなく、リリース後にバグとなるドメイン理解の失敗です。

遅いオンボーディング。 エージェンシーはスペシャリストなら既に知っている業界の基礎を理解するために時間が必要です。その時間はタダではなく、プロジェクトのタイムラインと、説明不要なはずのコンテキストを説明するためのチームのリソースから引かれます。

浅いプロダクト思考。 ジェネラリストは依頼された内容を最適化します。スペシャリストは依頼された内容に異議を唱えることがあります。それは本当に必要なものを理解しているからです。その違いはプロダクトの判断に現れます。どこに複雑さを置くか、何を簡素化するか、何を自動化して何を監査可能性のために手動に保つか、なぜシンプルに見える機能が実は罠なのか。

長くなるまでの時間。 最初の納品がドメインの前提を外れていた場合、修正が始まります。エージェンシーが御社の業務を学びながら何度も修正を繰り返すと、タイムラインが延び、予算もそれに伴います。

違いを明らかにする5つの質問

これらは意地悪な質問ではありません。エージェンシーが本物のドメインの深さを持っているのか、磨き込まれたピッチトークを持っているだけなのかを明らかにするための会話の出発点です。具体性を聞き取ってください。抽象的な答えはシグナルです。

1. 「ドメイン知識が技術的決定を変えたプロジェクトを教えてください。」

スペシャリストには話がすぐに出てきます。クライアントの運用チームがデプロイメントのオーバーヘッドを管理できないという理由でマイクロサービスアプローチに反対した話。業界のデータモデルに特有の点があり「きれいな」解決策が実用的でなくなったためAPIデザインを簡素化した話。その話は具体的で、ドメインへの熟知からのみ知り得る制約を含み、なぜ別のエージェンシーはそれを気づかなかったかもしれないかを説明するものになるはずです。

ジェネラリストは要件への適応について一般的な答えをします。それは同じことではありません。

2. 「直近のクライアントの業界でどんな前提に疑問を持ちましたか?」

良いエージェンシーは反論します。言われたことをこなすだけではありません。御社のドメインのスペシャリストであれば、クライアントが繰り返し犯す前提のリストと、それらを早期に表面化させてきた実績があります。答えが曖昧な場合(「私たちは常に前提に疑問を持ち、クライアントと協力して取り組みます」)、具体的な例を求めてください。実際の話が出てくるか、行き詰まるまで掘り下げ続けてください。

3. 「チームに御社の業界で開発者としてではなく実務者として働いた経験のある人はいますか?」

これは直接的な質問で、一部のエージェンシーは居心地が悪く感じます。しかし重要です。最良のドメインスペシャリストのチームには、自分たちが提供するサービスの業界で実際に働いた経験のある人が少なくとも一人います。プロダクトマネージャーになる前に物流で働いていたアナリスト、エージェンシー側に移る前に医療会社で3年間働いた開発者などです。その実体験が、チーム全体が質問を立て要件を解釈する方法を形作ります。

すべての優れたエージェンシーがこれを持っているわけではありませんが、持っている場合は意味のあるシグナルです。持っていない場合は、どのように補っているかを聞いてください。

4. 「自分たちのために作るなら、何を変えますか?」

これは意見を問う質問です。スペシャリストには意見があります。御社の領域で十分に構築してきたため、何が機能し、何が機能せず、常識がどこで間違っているかについての見方を持っています。答えが「依頼通りのものを作ります」であれば、黄色信号です。過度に従順か、意見を持つだけのドメインコンテキストがないかのどちらかです。

伝えた内容を超えて御社の問題について考えてきたエージェンシーが必要です。

5. 「ドメインの文脈からクライアントの仕様に異議を唱えた事例を見せてください。」

異議は健全です。一度も異議を唱えないエージェンシーは、従順すぎるか、反論するだけの知識がないかのどちらかです。クライアントの仕様に問題があると伝えた具体的な例を求めてください。技術的な問題ではなく、ドメインの問題です。依頼通りの機能は技術的には動くが、商業的、運用的、またはエンドユーザーにとって失敗するケース。クライアントがどう反応したか。その後どうなったか。

その答えは、何を知っているかだけでなく、どのように働くかについて多くを語ってくれます。

TMNSolutionsとは何か(そして何でないか)

私たちはWebアプリケーション、Laravelシステム、モバイルアプリを構築します。技術的に堅固で、納品重視で、タイムラインに誠実です。Eコマース、専門サービス、社内ツール、SaaSのクライアントと取り組んできました。

私たちは「何でもやります」という会社ではありません。データエンジニアリング、組み込みシステム、エンタープライズERP導入はやりません。スコープ外のプロジェクトをお持ちの場合は、率直にお伝えします。間違った方向に誘導することは誰の利益にもなりません。

私たちが専門とするのは実行層です。明確に理解された問題を受け取り、その周囲に信頼性が高く保守しやすいソフトウェアを構築すること。十分なプロジェクトを経て、引き渡しが容易なWebアプリとメンテナンスの悪夢になるものの違い、異なるユーザー行動をまたいで機能するモバイルUXパターン、18ヶ月後に技術的負債となるLaravelのアーキテクチャ決定を学んできました。

それが私たちのドメインです。意見を持てるだけの深さで理解しています。

知らないことを認めるエージェンシー

スペシャリスト的思考の最も明確なシグナルは自信ではなく、境界線を引く意志です。ジェネラリストはすべてのプロジェクトを受けます。なぜならすべてのプロジェクトが能力の範囲内だからです(彼らはソフトウェアを構築できる)。スペシャリストは時に断ります——あるいは「その部分は私たちではない」と言います。能力と専門性の間のギャップにはコストがあり、そのコストはクライアントに降りかかると理解しているからです。

エージェンシーを評価する際、「それは私たちの強みではありません」または「その部分については専門家を入れたい」と言うエージェンシーは、すべてにYesと言うエージェンシーよりも信頼できることが多いです。

5つの質問をしてください。具体性を聞き取ってください。誠実さを評価してください。自分が何を知らないかを知っているエージェンシーこそが、6ヶ月後に驚かせないエージェンシーです。

関連記事

エージェンシー契約で交渉すべきこと
ベストプラクティス

エージェンシー契約で交渉すべきこと

多くのクライアントは価格とスケジュールしか確認しません。しかし契約終了後に、誰も理解できないコードベース、ドキュメントなし、リポジトリはエージェンシー所有という事態に直面します。契約前に交渉すべき3つの条件を解説します。

誰の時間も無駄にしない技術ブリーフの書き方
ベストプラクティス

誰の時間も無駄にしない技術ブリーフの書き方

プロジェクトの失敗の多くは、コードが書かれる前から始まっています——曖昧で不完全なブリーフが原因です。正確な見積もりを出すために、開発会社が本当に必要とする情報をお伝えします。