サービスの特質

サブスクリプションサービスは、簡単に始められると同時に簡単に他のサービスに乗り換えられることができます

サブスクにして月々の費用は小さいが継続してもらうことが重要で、そのための

Design Document

サービスデザインをメンバー(だけでなくできればステークホルダー全員)で共有して共通の理解をしておくことでより効率的にビジネス推進ができます。

世の中あまたある「設計書」のご多分に漏れず、すべての思いを言い表すことはできないですが、
・少しでも書いておく、
・ことあるごとに共有する、
・常に見直して改訂し続けること
が大切だと考えています。

サービスの立ち上げ段階ではバイブルとしてサービス開発メンバーで「デザインポリシー(考え)」を共有します

フレームワークはまだ固まっていませんが、次のような構成要素が含まれています

1. はじめに

   • 本サービスは・・・である　　(サービスの定義、目的)

   • 補足になるような提供価値、特徴、ありたき姿などを冗長でも良いので記述

2. デザインポリシー

   • どれだけ変化してもこれだけは変えないというような”芯”を書いておく 

3. overview

   • ステークホルダーとサービス、システムの構成、ビジネスモデルが分かる図
     補足として相互の関係性や具体事例を追記

4. ステークホルダー 

   • 一覧

   • 利用者、契約者、販売パートナー、デリバリーパートナー、開発パートナー　それぞれの定義

   • 上記を記述することでビジネスモデルを再点検できる

   • できるだけ具体例も挙げておく

5. サービス

   • サービス毎の定義

     • from who to who

     • What

     • Why

     • How much(price)　価格の考え方、凡その数字(価格感)

     • Where　国内、海外

   • 提供するサービスだけでなく提供を受けるサービスも記述する

サービス仕様書

契約者/お客様に提供する公式文書になります

目次の例
1. 関連マニュアル,参考ドキュメント一覧

2. サービスの概要

3. サービス提供のシステム構成

4. 提供サービス

5. 拡張サービス

6. 個別見積り項目

7. サービスの一時停止について

8. サポートサービス

9. 連絡先

品質合意(SLA)

契約書類

サービス契約関連

基本契約、利用契約、変更申込書兼受領書、終了届兼受領書　等々

デジタルサービスは「役務(えきむ)の提供」になるので販売モデルについては要注意 

パートナー契約(販売、開発、協業)

比較的オーソドックスな契約となる場合が多い

品質

「品質確保管理」という概念

一般的にプロダクトの品質管理はQA部門が「品質保証」をし、プロダクトが出荷(提供)され、万が一不良が発生した時の一義的な責任はQA部門が担っている

”デジタルサービス”の品質に対する責任部署は設計部門が担っていて、QA部門は設計部門が品質確保に向けた正しい活動を確実に実施させることが役割となっている。

QA部門が独立組織でない場合でもこの考え方の違いは理解しておく必要がある。

不良や予期せぬ停止は有り得る

プロダクトの場合は徹底して不良を排除するので所謂”検査”に時間がかかり開発にある程度の期間が必要となる

サービスは利用者が欲しいと思った機能をタイムリーに提供されないと利用者からみたサービス品質は低下し、サービスから離れていくことになる

(c) 2025 Y's Business Lab