ずんだもん「サービスの標準化によるメリットってなんなのだ？」

## 花見会場にて

<table>
  <tr>
    <td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/c0f938e8-bc8c-40c7-8ba6-db76fe6fe150.png" alt="Image 1" width="150"></td>
    <td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/eb5db776-7bdd-4908-83ee-cd120627b4bc.png" alt="Image 2" width="160"></td>
  </tr>
</table>

**ずんだもん（宴会部長）**「お花見の季節なのだ！うちの会社もそろってお花見でたのしいのだ！」

**きりたん（経理部長）**「ふふふ、そうですわね。ずんだもん、今年もセッティングお疲れ様ですわ」

**ずんだもん**「そういえばきりたん、今日みんなでここに来るときにタクシーを使ったのだけど、乗ったときに『どの道で行きますか？』って聞かれてちょっと困ったのだ」

**きりたん**「あら、それって私も経験ありますわよ。単に最短ルートで行きたいだけなのに、わざわざ聞かれるの、ちょっとだけ面倒ですわ...」

**ずんだもん**「そうなのだ！ほとんどのお客さんは『お任せ + 最短で』って思ってるのに、なんでいちいち聞くのだ？」

**きりたん**「それはタクシー会社側の事情もあるようですわね。『なんで勝手に道を選んだのか』というクレームがあるみたいですわ」

**ずんだもん**「えぇ～、そうなのだ？つまり一部のクレーマーのせいで、みんなが無駄な質問に答えなきゃいけなくなってるってことなのだ。なんだか悲しいのだ...」

**きりたん**「まさにそうですわ。これが**サービスの標準化が不足している状態**といえますわね」


## 標準化されていない vs 標準化されたビジネス

以下は、タクシー業界における標準化されたビジネスとされていないビジネスを比較した表です。

| **項目**        | **標準化されていないビジネス**                                                                     | **標準化されたビジネス**                                                              |
| ------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| **メリット**      | - 現場の裁量で柔軟に対応可能  <br>- 特定の顧客ニーズに合わせたカスタム対応がしやすい<br>- 「この担当さんなら安心」といった人材ベースのビジネスに向いている | - 一貫性のあるサービス提供でスケールしやすい<br>- 効率的な運用が可能<br>- 担当者によってサービスが変わらないため、顧客が安心して利用可能 |
| **デメリット**     | - ルールが曖昧でクレームのリスクが高い  <br>- サービス品質がばらつく  <br>- 不正行為の余地が生じる可能性がある                      | - 厳格にしすぎると柔軟性が低下する可能性  <br>- 特殊なニーズへの対応が難しい場合がある <br>- 標準化に時間とコストがかかる       |
| **タクシーの例**    | - 運転手が「どの道で行きますか？」と毎回聞く<br>- 遠回りして料金を高くするなど不正行為のリスクがある                                | - 最短ルートで自動的に案内する仕組みを導入 <br>- 「お任せ＋最短で」のサービスであると明記することでクレームも未然に防ぐ            |
| **顧客満足度への影響** | - 顧客によって満足度に差が出る  <br>- 一部クレーマーによる突発的なルール変更で現場負担増                                     | - 安定したサービス品質で顧客満足度向上に集中できる<br>- クレーム対応の負担軽減                                 |
| **運営側の負担**    | - 現場ごとの判断に依存し、効率が悪い  <br>- トラブル対応やクレーム処理の負担増                                          | - 標準化されたプロセスにより運営効率アップ  <br>- トラブル発生リスクの低減                                  |

**きりたん**「このように『現場の判断で』『臨機応変に』というアプローチは、一見柔軟に見えるけど、実はサービスの質を下げてしまうことがありますわ」

**ずんだもん**「なるほどなのだ！たとえば運転席の後ろに張り紙をして「お客様スマホで道案内をして頂いた場合、料金から10%引きとなります」みたいなこともできるのだ？」

**きりたん**「それは良い例ですわね。**標準化することでクレームの防止もしつつ、価格戦略にも転嫁できている**ことになりますわ」

**ずんだもん**「これからはこういうサービスが増えるかもしれないのだ！」

**きりたん**「[居酒屋タクシー](https://ja.wikipedia.org/wiki/%E5%B1%85%E9%85%92%E5%B1%8B%E3%82%BF%E3%82%AF%E3%82%B7%E3%83%BC)なんて問題もありましたわね。あれも「顧客を送り届ける」というサービスが標準化されていなかったから、問題になったわけですわ」

## IT業界におけるサービス標準化

<table>
  <tr>
    <td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/c0f938e8-bc8c-40c7-8ba6-db76fe6fe150.png" alt="Image 1" width="150"></td>
    <td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/eb5db776-7bdd-4908-83ee-cd120627b4bc.png" alt="Image 2" width="160"></td>
  </tr>
</table>

**ずんだもん**「きりたん、これってIT業界でいうと、どうなるのだ？」

**きりたん**「そうですわね。**SaaSとかMSP（マネージド・サービス・プロバイダー）の一部**がこれに当たると思いますわ」

**ずんだもん**「おお！サービス内容と月額がすべて明確になっていて『くわしくはお問い合わせください』になってないやつのことなのだ？」

**きりたん**「その通りですわ！個人向けサービスはそれが当たり前なのだけど、法人向けも増えてきていますわね」

**ずんだもん**「うちのような中小企業ではえらびやすいのだ！問い合わせる手間もないし、一石二鳥なのだ！」

**ずんだもん**「逆に標準化されていないサービスってどんなのがあるのだ？」

**きりたん**「人月工数をベースにした、個別見積もりのスクラッチ開発になりますわね。これは顧客の要望を聞き取って要件化してあげるという、コンサルティングサービスという側面もありますわよ」

**ずんだもん**「なるほどなのだ！難しい要件の場合は、そうならざるを得なさそうなのだ」

## IT業界での比較

以下は、IT業界における標準化されたビジネス（SaaSなど）とされていないビジネスを比較した表です。

| **項目**        | **標準化されていないビジネス**                                                                                      | **標準化されたビジネス (例: SaaS、MSPの一部)**                                               |
| ------------- | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- |
| **メリット**      | - カスタム開発で特定ニーズに完全対応  <br>- 柔軟性が高く独自仕様に合わせられる<br>- 責任を丸投げできる                                            | - 価格や導入期間の予測が容易  <br>- 定期的なアップデートとメンテナンスがふくまれることが多い  <br>- スケールしやすい           |
| **デメリット**     | - 開発コスト・期間の予測がむずかしく、ゴールポストが変更されるリスクがある<br>- 継続的なメンテナンスやアップデートの管理<br>- 依頼先ベンダーによって成果が全く異なるため、ギャンブル要素がある | - カスタマイズ性が不足することがある<br>- 自社で最新のIT知見をもって判断する必要があり、負担が大きい<br>- 責任が社内になり、丸投げできない |
| **例**         | - スクラッチ開発による独自システム構築 <br>- 人月工数ベース見積もりによる品質の不透明性                                                       | - NetflixやSlackなど月額課金モデル  <br>- 使用量応じ料金体系・複数プラン提供                             |
| **顧客満足度への影響** | - 責任を回避し、安心感を最重要とする顧客には高満足度で提供可能  <br>- 品質・納期不安定さによる不満のリスク                                             | - 一貫したサービス品質提供広範囲による長期的な信頼<br>- 柔軟性の欠如や、画一的なサポートによる不満のリスク                     |
| **運営側のメリット**  | - 顧客コントロールのノウハウが貯まり、利益の操作や循環が容易<br>- 人間をコントロールするノウハウが活かせるので、非エンジニアの雇用創出となる                             | - **最良のサービスを提供することで利益も最大化できる**<br>- サービス改良に注力できる                                  |
| **運営側のデメリット** | - 最良のサービスを提供してしまうと工数が減り、利益が反比例するリスク                                                                    | - エンジニアが大きな力を持つようになり、非エンジニアの活躍機会が失われるリスク                                      |

## まとめ

<table>
  <tr>
    <td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/c0f938e8-bc8c-40c7-8ba6-db76fe6fe150.png" alt="Image 1" width="150"></td>
    <td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/eb5db776-7bdd-4908-83ee-cd120627b4bc.png" alt="Image 2" width="160"></td>
  </tr>
</table>

**ずんだもん**「それぞれに長所短所があるのだ。企業のニーズに合わせて選ぶのが一番なのだ！」

**ずんだもん**「でも、人月工数って『だいたいの雰囲気で』になりがちなのが問題なのだ。PMいくら、シニアエンジニアいくらって計算するけど、各人のスキルはバラバラで、画一的に決められないのだ。」

**きりたん**「そうですわね。フルカスタム開発というニーズがある以上、どうしても計算は人月工数にするしかないのが現状ですわね」

**ずんだもん**「もうひとつの違いは、タクシーは個人利用がほとんど。安さや速さに敏感なのだ」

**ずんだもん**「いっぽうITシステムの開発委託は、発注者が会社員なのだ！だから使いやすさ・早さ・安さは二の次、というのが正直なところなのだ！」

**きりたん**「つまり、必ずしも導入するサービスが最良である必要はなく、自分が責任を取らずに済んで、そこそこの内容で社内に展開できれば良いと思っているのが発注者の本音というわけですわね....」

**ずんだもん**「そうなのだ。そしてその結果としてベンダーロックインや、責任スコープ定義の甘さなどで訴訟に至るケースがふえているのだ」

**きりたん**「ただ、最近は請負開発でも先進的な会社は、なるべくサービスを標準化して、メニュー価格をHPに掲示しているところも増えていますわね」

**ずんだもん**「[月額制の情シスサービス](https://www.google.com/search?q=%E6%9C%88%E9%A1%8D%E5%88%B6%E3%81%AE%E6%83%85%E3%82%B7%E3%82%B9%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9)も増えているのだ！たとえばPC何台までサポートとか、チャットで無制限サポートとか、いろいろな選択肢があって工夫されているのだ！」

**きりたん**「**サービスが標準化されたMSP**の良い例ですわね。こういう流れは中小企業の私たちも歓迎ですわ」

**ずんだもん**「そうなのだ！少しずつでも標準化しようとしている姿勢って、素晴らしいと思うのだ！だってタクシーの後ろに張り紙してあったら、ずんだもんは安心するのだ！」

**きりたん**「ふふふ、そうですわね。きっと、AWSとかMicrosoftも、標準化しようと努力したからこそ、今の地位があるのですわ。もし彼らが『毎回サーバー個別見積もりして利益があがればそれでいい』って考えだったら、今ほどの巨人にはなっていませんものね...」

**ずんだもん**「でも、標準化できない人もおなじ人間なのだ！だから彼らの事情を否定したり、理想を押し付けたりせず、理解してあげる姿勢もきっと大事なのだ！」

**きりたん**「そうね。『みんな違ってみんないい』ですわね。きっと技術より大切なことですわ！」

## 花見会場にて

<table>
  <tr>
    <td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/c0f938e8-bc8c-40c7-8ba6-db76fe6fe150.png" alt="Image 1" width="150"></td>
    <td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/eb5db776-7bdd-4908-83ee-cd120627b4bc.png" alt="Image 2" width="160"></td>
  </tr>
</table>

**ずんだもん**「でもさ、きりたん、標準化されたサービスって便利だけど、ずんだもんはちょっと心配なのだ…」

**きりたん**「あら、何が心配ですの？」

**ずんだもん**「もしタクシーの運転手さんが『まもなくランチタイムなので、乗車料金に運転手のおにぎり代が含まれます』って言ったらどうするのだ？」

**きりたん**「それは嫌ですわ！（笑）」

**ずんだもん**「きっとずんだもんも怒るのだ！おにぎり代まで請求されたら泣いちゃうのだ！」

**きりたん**「でも、そのおにぎりがずんだもんの好きなずんだ餅で、「ひとつあげるよ」って言われたらどうかしら？」

**ずんだもん**「うーん、それなら許しちゃうかもしれないのだ…。でも運転手さんが食べながら運転してたら危ないのだ！」

**きりたん**「確かに危険ですわね。じゃあ、おにぎりを食べる時間を標準化して、『10分間クルマを止めてお客さんといっしょに食べる』ルールを作ればいいですわ！」

**ずんだもん**「それなら安心なのだ！でも、休憩中に食べるおにぎりが全部標準化されて『塩むすびしかダメ』ってなったら悲しいのだ…。ずんだ餅が食べたいのに！」

**きりたん**「ふふふ、それなら『おにぎりカスタマイズオプション』を追加料金で提供すればいいですわね。塩むすび基本料金＋ずんだ餅トッピング！」

**ずんだもん**「うーむ…なんか話がややこしくなってきたけど、それならタクシーじゃなくて『おにぎり専門配達サービス』を作ればいいと思うのだ！」

**きりたん**「さすがずんだもんですわね。結局、おにぎりの話になっちゃいましたわ！」

## 利用キャラクター

- ずんだもん：[VOICEVOX:ずんだもん](https://voicevox.hiroshiba.jp/)

本記事で使用しているキャラクター画像の著作権は、それぞれの権利者に帰属します。
非商用目的での利用に基づき掲載しています。