ブログ（2018.1）
「サービス設計12箇条」を読んで、の詳細
2018.1 「サービス設計12箇条」を読んで
ＩＴ戦略本部の第30回新戦略推進専門調査会電子行政分科会（2017.12.1）に
提出された下記資料の中で、サービスデザイン思考実践の具体的なポイントが
「サービス設計12箇条」として提示されている。
【資料１−２】サービス設計の基本ルール及びサービスデザイン思考の実行について
そこで、過去の研究との関連で、これらの項目についてコメントする。
第１条
利用者のニーズから出発する
第２条
事実を詳細に把握する
第３条
エンドツーエンドで考える
第４条
全ての関係者に気を配る
第５条
サービスはシンプルにする
第６条
デジタル技術を徹底的に活用する
第７条
利用者の日常体験に溶け込む
第８条
自分で作りすぎない
第９条
オープンにサービスを作る
第10条 何度も繰り返す
第11条 一遍にやらず、一貫してやる
第12条 システムではなくサービスを作る
■第１条 利用者のニーズから出発する
提供者の視点ではなく、利用者の立場に立って、何が必要なのかを考える。様々な利用者がいる場合には、それぞれの利用者像を想定し、様々な立場からの検討を繰り返す。サービス提供側の職員も重要な利用者として考える。
↓
★当たり前の話だが、意外と忘れがち。以下の拙著で言及：
（筆者の文献）
・巻頭言 CS-life、コンピュ-タソフトウェア(日本ソフトウェア科学会)、11,6,(Nov. 1994)
（引用）
「生産者中心の視点から利用者中心の視点への転換が必要」
「『エンドユーザ→ソフトウェア産業→ソフトウェア工学→ソフトウェア科学』という
技術移転とは逆方向の問題認識の移転が重要」
■第２条 事実を詳細に把握する
十分な実態の調査や分析を伴わない思い込みや仮説のみに基づいてサービスを設計するのではなく、実際の現場では何が起きているのか、実態を事実に基づいて細かな粒度で一つ一つ徹底的に把握し、課題の可視化と因果関係の整理を行った上でサービスの検討に反映する。データに基づく定量的な分析も重要である。
↓
★これも要求定義プロセスで当たり前の話。以下の拙著で言及：
（筆者の文献）
・ソフトウェア工学、朝倉書店 (1997.5)。同左
第2版（2004.3）。第3版（2014.3）
（引用）
「最初に，現状の業務がどのように行われているかを分析し，その業務モデルを現状物理モデルとして
構築する．・・・できるだけ現状を物理的なレベルで表現する．そのほうが利用者との
コミュニケーションがやりやすく，現状の問題点が利用者側から具体的に提示されやすい．」
■第３条 エンドツーエンドで考える
利用者のニーズの分析に当たっては、個々のサービスや手続のみを切り取って検討するのではなく、利用者が思い立った時からサービスが終わる時まで（エンドツーエンド）の、他の行政機関や民間企業が担うサービスまで含めた全体の一連の流れを考える。
↓
★これは、アプリケーション開発プロセスにおいて、エンドユーザの視点で、
まずビジネスモデルを定義し、次にその実現のために必要となるサービスを定義し、
最後にサービスを実装するソフトウェアを定義するという手順で達成される。
これは、私の従事してきたエンドユーザ主導開発技法の研究の基本的考え方である。
（筆者の文献）
・A Form-based Approach for Web Services by Enduser-Initiative
Application Development,
SAINT2002
Workshop (Web Service Engineering), IEEE Computer Society, pp.196-203 （Feb. 2002).
（引用）
The business
model at the business level is proposed by end-users of business professionals
or domain
experts. Then, at the service level, the domain model is constructed and
the required
services are specified. That is,
the requirement specifications
of
the
application for the business model is defined. At the software level,
the domain
model is implemented by using components to be combined.
■第４条 全ての関係者に気を配る
サービスは様々な関係者によって成り立っている。利用者だけでなく、提供者である職員（フロントオフィス及びバックオフィスの双方）や関係する民間団体（企業、士業等）、周辺住民等も考慮に入れ、全ての関係者について、どのような影響が発生するかを分析し、Win-Winを目指す。
↓
★要求分析におけるステークホルダの重要性は、プロジェクト管理の知識体系
ＰＭＢＯＫ(Project
Management Body of knowledge)にも明記されている。
前述の拙著「ソフトウェア工学（第3版）」では、以下のように記述している。
（引用）
「j.ステークホルダ管理
これはＰＭＢＯＫ第５版で追加された１０番目の知識エリアである．
利害関係のあるステークホルダの適切な管理がプロジェクト成功の重要要因であるという観点から
ステークホルダとの意思疎通に努める．」
■第５条 サービスはシンプルにする
利用者が容易に理解でき、かつ、容易に利用できるようにシンプルに設計する。初めて利用する人が、複雑なマニュアルに頼らずとも、自力でサービスを利用して完結できるようにする。また、行政が提供する情報や、利用者に提出や入力を求める項目は、真に必要なものに限定する。
↓
★国際標準化機構（ISO）では，ソフトウェア製品の品質属性として，機能適合性、性能効率性、
互換性、使用性、信頼性、セキュリティ、保守性、移植性の８項目の特性を規定している．
本条の内容は、特に使用性の以下の副特性が関係する．
（拙著「ソフトウェア工学（第3版）」から引用）
・適切度認識性：ニーズに適しているか否かをユーザが認識できる度合
・習得性：製品やシステムの使用のための学習目標を達成できる度合
・運用性：運用や管理を容易にする特性を備えている度合
・ユーザエラー防止性：システムがユーザの誤操作を防止する度合
・ユーザインタフェースの審美性：魅力的なインタラクションの度合
・アクセシビリティ：特性や能力の多様な人々により使用できる度合
■第６条 デジタル技術を徹底的に活用する
サービスには一貫してデジタル技術を用い、デジタルファースト、ワンスオンリー、コネクテッド・ワンストップを実現する。これまでデジタル以外の媒体で解決してきたものであっても、デジタル技術への置き換えの可能性を検討し、サービスの改善を図る。
↓
★2001年のe-Japan 以来の目標では？
■第７条 利用者の日常体験に溶け込む
サービスの利用コストを低減し、より多くの場面で利用者にサービスを届けるために、既存の民間サービスに融合された形で行政サービスの提供を行うなど、利用者が日常的に多くの接点を持つサービスやプラットフォームとともに行政サービスが提供されるように設計する。
↓
★具体的には、民間サービスに融合された形とは、Ｗｅｂサービス連携を意味すると思われるので、
行政サービスのインタフェースとしてＡＰＩを用意する必要がある。ＡＰＩ技術はすでに確立している。
（筆者の文献）
・A Form-based Approach for Application Development By Web Service
Integration,
Applied
Computing 2006, IADIS, pp.600-605 (Feb. 2006).
（引用）
In the
business world, recently, the external specifications of application software
are considered
as services. The various infrastructure technologies such as
SOAP[10], UDDI
[9] and WSDL [11] are used for rapid Web service provision [6].
■第８条 自分で作りすぎない
サービスを一から自分で作るのではなく、既存の情報システムの再利用やノウハウの活用、クラウド等の民間サービスの利用を検討する。自分で作成する場合も、過剰な機能や独自技術の活用を避け、他で再利用することを考慮し、共有できるものとするよう心掛ける。
↓
★前の第7条の民間サービスから行政サービスを利用する場合の逆で、
行政サービスから民間サービスを利用するようなＷｅｂサービス連携で、技術的には同様である。
■第９条 オープンにサービスを作る
サービスの質を向上させるために、サービス設計時には利用者や関係者を検討に巻き込み、利用者の意見を取り入れる。検討経緯や決定理由について可能な限りオープンにするとともに、サービス開始後も、提供状況や品質等の状況について公開する。
★第4条で述べたステークホルダ重視および第7，8条でのＷｅｂサービス連携促進が本項にも関連する。
↓
■第１０条 何度も繰り返す
試行的に情報システムを用いてサービスの提供や業務を実施し、利用者等からのフィードバックを得るなど、何度も確認と改善のプロセスを繰り返しながら開発を行う。サービス開始後も、継続的に利用者や関係者からの意見を収集し、常にサービスの改善を図る。
↓
★適用の初期段階でのユーザからの不満にこたえて迅速に改善を繰り返すことが重要で、
私は「ユーザの不満が出れば大成功」といってきた。
（筆者の文献）
・座談会「ソフトウェアの研究って何だろう？」、bit, vol.25, no.6, 5-7(June 1993).
（引用）
「ファーストユーザは神様です。ユーザの不満が出れば大成功」と言っています。
ユーザが不満を抱くところまで持って行くのが大変なんですね。
■第１１条 一遍にやらず、一貫してやる
困難なプロジェクトであればあるほど、全てを一度に実施しようとしてはいけない。まずビジョンを明確にした上で、優先順位や実現可能性を考えて段階的に実施する。成功や失敗、それによる軌道修正を積み重ねながら一貫性をもって取組み、全体像を実現する。
↓
★過去に類似システムの開発経験のないようなプロジェクトでは、設計・実装前に
完全な要求仕様の定義は難しい。最近では、ウォーターフォール型に変わり、
アジャイル開発が普及しつつある。
■第１２条 システムではなくサービスを作る
サービスによって利用者が得る効果（ベネフィット）を第一に考え、実現手段であるシステム化に固執しない。全てを情報システムで実現するのではなく、必要に応じて人手によるサービス等を組み合わせることによって、最高のサービスを利用者に提供することが目的である。
↓
★要求分析は、4段階（現行物理モデル→現行論理モデル→新規論理モデル→新規物理モデル）で実施するが、
前述の拙著「ソフトウェア工学（第3版）」では、最後の新規物理モデル構築で、以下のように記述している。
（引用）
「論理レベルで複数の案が作成された場合，費用と効果の関係などを考慮して１つに絞る．
この段階で，コンピュータ化する部分と人手で遂行する部分との境界を最終的に決定する．」
以上