【読書】【メモ】This is Service Design Thinking その1

This is Service Design Thinkingを読んだメモと50ページ目くらいまでのまとめ。

◇ざっくり読んだ感想
サービスデザインの定義には"学際的なもの"と書いてあって、たしかに多彩な観点からサービスデザインに関する記述がなされているのだけど…　「それ本当にサービスデザインに必要？」みたいなものも混ざりこんでいるような気がする。

例えば、この本には経営学の辺りの話題も幾つか出ていて（マーケティング、オペレーションズマネジメント、あと経営戦略）、たしかに読んでいて示唆はあるのけど、これらがサービスデザインのプロセスや考え方に対してどう関わり貢献するのか、という辺りの記述があまりない。

これは別にサービスデザインに経営学が関係ないとか言いたいわけではなくて、「同じ経営学でも、そこの領域ではなくない？」という。

『組織の文化や既に提供しているサービスを踏まえてサービスデザインをしなければいけない』 みたいな記述がこの本の中盤には繰り返しでてきて、これは明らかに経営学の観点から語れる領域なのだけど、そうであればマーケや経営戦略の人ではなくて、組織論について語れる人を連れてこないとしっくりこないというか…


--What is service design?--

◆サービスデザインの定義
・様々な学問領域から方法論やツールを集めた学際的なもの
・だから明確に言葉で定義できるものではない



◆五つの原則

サービスデザインの定義はないけど、求められる考え方を示すことはできる

・ユーザ中心 : 顧客の視点からサービスを見る
・共創 : デザインプロセスにステークホルダーも巻き込む
・流れがある : 相互に関係のあるもの同士の流れであるように見せる
・形に残る : 無形のサービスは物理的な何かで見えるようにする
・全体的 : サービスを取り巻く全ての環境を考慮に入れる


■ユーザ中心
・サービスは提供者と享受者のインタラクションで生み出されるもの
・享受者はそれぞれが違う経験や価値観を持っている
　→それぞれを理解しようとすることからサービスデザインは始まる
・チームも同じ
　→それぞれの知識を持ち寄ってサービスデザインするのが成功には必須
　→→だからユーザ中心を共通のサービスの言語にする


■共創
・サービスのプロセスに関わる（様々な領域の）人を集めることが重要
・サービスをデザインする人は考えるのではなく場を作りアイデアを評価する
　→ツールは適宜選ぶ
・共創は、顧客やサービスを実施する人達と行う
・ロイヤリティやエンゲージメントのためには、顧客を巻き込むことが重要


■流れがある
・サービスの持っているリズムは顧客に何かしら印象を与える
・顧客とサービスの接点
　→人と人
　→人と機械
　→機械と機械
・サービスのステップ
　→サービス提供前
　→サービス中
　→サービス提供後
・ワクワクするような印象を常に抱いてもらう
　→ストレスを与えること無しに
・プロトタイプを作る
　→サービス享受者がどう感じるのかを繰り返しテストする


■形に残る
・サービスは見えないところでひっそりと提供されていたりする（ハウスキープなど））
　→形にすることで、サービスのことを印象付けてもらうことができる
　→→ロイヤリティや推薦に繋がる可能性がある
・いつもそうすれば良いとは限らない
　→サービスの流れやタッチポイントの中でやるのが良い


■全体的
・顧客は（意識していないかもしれないが）サービスを五感で感じる
・幅広いコンテキストからサービスのプロセスを見ること
・顧客の体験を素晴らしいものにしていくためには繰り返し改善することが必要
　→現状の代替となるタッチポイントややり方を常に持っておくこと
・サービスジャーニーでステークホルダーが持つ印象を示しておくことが重要
　→企業の文化、価値観、組織構造、プロセスがサービスデザインには重要



◆マーケティングとサービスデザイン

・同じ課題に対しての出発点やアプローチが違う
　→マーケティングは共創のために顧客との関係を築く仕組み
　→デザインはステークホルダーを中心に据えて、彼らと共創する仕組み
・サービスデザインの中心
　→人・もの・組織の間にある価値
　→それらの間にあるべき関係性

【読書】システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意

モニターということで、ソフトバンククリエイティブ様より御本を贈って頂きました。ありがとうございます。

まだ隅々までは目を通しきれてはいないのですが、いま読んでいて思ったことなど書いておきたいと思います。



■はじめに

この本の最後の章には次のような記述があります。

・本書は共通・文書化などを取り上げているため、「ウォーターフォール」型開発に関する書籍だととらえられてしまうのではないかという危惧を抱いています。 

・本書ではあえて設計や文書化の方法に多くの説明を行っています。これは、「設計要素を知っていて文書や記述を削る」のは適切な行為だと思いますが、「設計要素があることを知らずに文書や記述を削る」のは品質やプロジェクトの遂行に対してマイナスの要素をもたらすと考えているからです。 

・アジャイル開発では「設計はしない」「設計書は書かない」ととらえているとしたら、それは誤解です。アジャイル開発においても当然設計は行います。

この本自体は、要求から始めて段階的に設計を詳細化していくというスタイルで記述されており、一見するとウォーターフォールなソフトウェア開発における上流工程のエンジニアリングについて書いてあるように見えます。

しかし、先ほど引用した文章に書いてあるとおり、著者の意図は『この本に書いてある順番どおりに設計プロセスを進めて欲しい』ではなくて、あくまで『各種設計フェーズにおける検討事項や設計する際のポイントについて理解してもらいたい』なのです。

ここを押さえて読むのと押さえないで読むのとでは、だいぶ受ける印象が違うと思います。

※なお、3つ目の引用では、アジャイルと設計・ドキュメンテーションの関係について触れているのですが、この点はとても大事だと思います。大事なことなので繰り返し書きますが、アジャイルなソフトウェア開発でも設計はするし、必要なだけのドキュメントは書きます。



■感想

システム設計についてこれから始める人にとってはいろいろ便利な本なのかなーと思いました。

タイトルにあるとおり、この本はシステム設計についての本なので、システムを構築するにあたっての知見がいろいろと詰めてあります。例えば、要件定義から設計の間にやるべきこととして、次のような作業を上げています。

●全体設計
・システム境界図
・システム俯瞰図
・サブシステム連携概要 

●アーキテクチャ方針
・オンラインアプリケーション方針
・帳票出力方式
・ジョブ管理・実行方針 

●標準設計
・文書テンプレート
・記述粒度・ガイドライン
・設計基準 

●共通設計
・画面共通
・帳票共通
・バッチ共通
・DB共通
・メッセージ共通

割とがっつりと検討してますよね。で、この"がっつり"という点が個人的には重要だと思っています。

例えば、システム設計について経験したことが無い人がその辺りの知識を自主的に学ぼうと思った場合を考えます。個人的にちょっとしたツールなどを作るときに、設計などやってみて知見をためるというのは1つの優れたやり方ではあるのですが…　こと設計については話がやや異なると思っていて、それは"ちょっとしたツール"という規模だと、上述したような質・量で事前の検討はしないと思うからです（してもあまりメリットを実感できないと思います）。つまり、そこから学ぶことができるはあくまで"ちょっとしたツール"の規模の複雑さと、それに応じた設計までにしかならないということです。

あるいは、自主的に学ぶのではなく実際にシステムを作るときに失敗などを経験し、そこから学ぶのもよいのですが、現場で失敗するのはいろいろとおいしくないし、それよりは先人の知恵から学んだ方が良いわけで、そういう意味でこの本は便利だなーと思いました。


で、この本を読む時、成果物として定義してあるドキュメントの書き方からそのまま覚えていくという、ストレートな学び方もありだと思うのですが、ここまでかっちりしたドキュメントが必要となる現場はともかく、そうでない現場にいる人であれば、もう少しエコに読み進めていくのが良いとも思います。

システムの構築を行う際にその設計が求められる理由や、その設計を行うことによってどのようなリスクを事前に考慮できるのかなど、そういった観点に立って読んでいくと良いということです。


また、粒度や方針・整合性といった、一貫性のある設計をするのであれば否応なしに意識せざるをえない観点について、繰り返し記述が入っているのも良いと思いました。そういうのは大事です。

設計における一貫性を検討しない（設計思想がない）まま実装を始めてしまうと、やはり当然というか、コードからは設計レベルにおける意図が見えてこないような成果物ができてしまうだけなので…　やはりそういうソースは保守していくのも面倒だし…



■最後に

この本はオブジェクト指向やドメイン駆動なアーキテクティング・デザインについての本ではないと断ってあるのですが、OODやDDDから始める場合だってオブジェクトを永続化するのに使うのは大体の場合DBなわけで、そうであるならI/Oやトランザクションについて検討するのはやはり重要なわけです（この本に書いてあるような事柄を検討しないまま実装するとだいたい後で酷い目に会います）。

この本は、そういう意味でも"開いた"内容になっているので、この本に書いてあることがズバリ当てはまるような業務系のSEだけではなく、広い意味で設計に関わっていくような人はまず押さえておくとよいのかなーと思いました。

個人的には、手元においてハンドブックみたいに使おうかなーと思っています。

【読書】Ed Emberley's Drawing Book MAKE A WORLD

ノートを書くのであれば、情報や知見がまとまったものにするのはもちろんですが、そのとき思ったこととか考えていることを手繰り寄せるための手がかりのようなものになっていてくれるといいと思います（そのためにはあと後で見返したくなるくらいには面白みがないといけない）。

であれば、思い出すための手がかりになるものはできるだけ多く書いてある方がよいです。そして手がかりはあくまで思い出すためのとっかかりなので、それが理路整然としている必要はありません。それよりは、その時の感覚とか雰囲気を閉じ込めておけるようなものであって欲しいのです。

そのためには有効なのが絵です。文字は言葉を正確に写し取るための確実で間違いのないやり方なのだけど、そこに織り込める表現には限りがあります。色使いや筆致でバリエーションを作るのには限界があるし…　それでも文字で表現しつくそうとするのであれば、これでもかと言うくらいの文字を使ってその輪郭を延々と描き出していかないといけません（この文章みたいに）。

絵そのものは難しい必要はなくて、それよりもノートに込めようとしているニュアンスや雰囲気をいかに的確に表せているかが重要です。ノートに書く絵は、簡単でさっと書けるようなもので、文字や記号に見劣りしないくらい単純、かつ彼らに自然に溶け込んでしまえるようなものになります。

しかしなかなかそういう絵を描くのは難しいです。私に絵心がないのを差し引いても、です　…という問題意識を漠然と持ちつつ、amazonをうろうろしているときに見つけたのがこの本になります。


Ed Emberley's Drawing Book: Make a World

絵の描き方のための本。

簡単な図形の組み合わせでたくさんの絵を作り出すための本。絵といっても今風のそれの書き方ではなく、もっと象徴的なもの。

こんな感じ。

丸とか四角とか簡単な曲線の組み合わせでこれだけの表現ができるという。

人もたくさん書き分けられます。

洋書なのですが、見てのとおりの本なので英語力は全く問題になりません…　ということで、上手くならなくていいから、それより絵のバリエーションが欲しいという私にはなかなか良い本でした。

P.S. 購入後に気がついたのですが、これは子どもに絵の描き方を教えるための本のようです…

セーフウェア - 安全・安心なシステムとソフトウェアを目指して

この本はコンピュータ制御システム及び、コンピュータ制御システムに携わるエンジニアのための本です。

私が関わる業務領域の中には、安全性のためだけにここまで論理を組み上げて品質を作りこむ必要がある領域というのはありませんでした。

業務系のシステムでは（要件が人の生死に関わらないという範囲において）品質や安全性は、コストに対してトレードオフさせるのが一般的です。そして、大抵の業務系システムの要件は人の生死には関わりません。私が携わってきたシステムの中にもそのようなものはありませんでした。おそらく、今後もないでしょう　…ですが、ここまで知っておいて損することはないとも思います。

分析や設計をする際、その思考プロセスの根底に安全性や信頼性が横たわっており、それを見通しながら作業を進めることができるのと、そうできないのとでは、成果物のできあがりに明らかな差がでるように思えてならないからです。私は設計に品質を織り込みたい性格なので、存在を知った瞬間にこの本を即買いしました。

いわゆるSIerが取り扱うシステム・業務領域というのは、この本で対象にしているものとは違います。ですが、安全設計に係る考え方を知っていることは全く損にならないし、ここで学んだことをシステム構築に応用できたなら、それは素晴らしいことです。


◇どういう本か

コンピュータ制御システムなどの中に入っているソフトウェアが対象となっています。その中でも、システムのエラーが人の生死に直接的に関わるようなシステムに特化した内容になっています。なので、エンタープライズ・ビジネス系のそれとはだいぶ毛色が違います。

例として、信号の制御システムを考えて見ます。

車の運転中に全ての信号がいきなり真っ暗になったら困りますよね？　で、交差点とか横断歩道を越える際にはものすごい神経をすり減らしながら走り、精神ががっつり削られたくらいにやっと家にたどり着いて、調べたら「初歩的なエラーでソフトが落ちたらしいんですが、原因が分からないんですよね。あの後に再起動したら、なんかうまく動いているので、しばらくはこのまま監視しようと思います。トラブル発生時のログなんてとってないし、まあ、再現したらそのときに調べますよ」とかいう話だったとします。今まで事故を起こさずやってこれたことに感謝すると同時に、明日からの自動車の運転に深く絶望し、同時にこのシステムに携わる全ての人間をぶっとばしてやりたい、という感じになりますよね？

そういったクリティカルなシステムをつかさどるようなソフトウェアを安全に構築するための理論や方法論までを包括的に述べたのがこの本です。


◇内容

人の生死に関わるようなシステムの設計方法を述べるだけあって、コンピュータ制御システムの安全について詳細に論じられています。大体、次のような感じです。

1. リスクの概念をコンピュータに結び付ける。
2. これをコンピュータにまつわる誤った神話に関連付け、解きほぐす。
3. 事故の原因におけるシステムとヒューマンエラーの関係から、人間の役割について論じる。
4. 工学的観点からシステム安全について述べる。
5. システムを安全に作成・運用するためのプロセスについて論じる。
6. ハザードを分析し、要求分析フェーズで検討するための手法について述べる。
7. 安全性のための設計やインタフェースの設計について論じる。

◇付録

システムハザードを伴う10の重大事故のレポートが巻末に付録として収録されています。チャレンジャー号・ボパール・チェルノブイリといった有名なものから、Therac-25・セベソといったものまで多岐にわたります。

中でも、Therac-25のレポートは衝撃的です。この治療機器には、特定の条件下で起きるソフトウェアのエラーにより、致死量の放射線を患者に浴びせてしまうというハザードがありました。ですが、Therac-25の発売直後には誰もそんなことは知りませんでした。だから、致死量の放射線を浴びせたとしても治療者は気づきません。そして、致死量の放射線を浴びてしまった患者は、患部に強い痛みを感じたまま家に帰り、数日後に原因不明のまま死んでしまうのです。そうやって何人かの死者を出した後、一連の死者はシステムハザードの犠牲者であり、犯人はTherac-25、原因はソフトウェアのバグ、いうことが明らかになります。

患者が体調不良や違和感を訴える一方で、治療医や製造業者はシステムが抱えている危険を認識していなかったりします。認識不足、ちょっとしたミス、簡単な見落としや思慮不足が重篤事故に繋がり、人の生き死にに直結するのです。そう考えると、非常に恐ろしい話です。


◇最後に

この本の対象に業務系システムが含まれていないということは書きました。それはこの本の論旨からも明らかです。しかし、これは、この本がシステムの用途と人の生死がリンクするようなシステムについてしか取り上げていないだけ、という話であるとも考えます。

業務系のシステムの中には、「これ本当に運用設計したの？　あと、この挙動バグじゃない？　問題ないの？　これ、詳細設計とか書くようなプロジェクトじゃなかったっけ？　ところで、テストの資料は？　え？　もう残ってないの？　じゃあ、これが要件を満たしていることは誰が担保してるの？　えー？　それは…」という、いろいろと酷いシステムがあって、運用チームが神経をすり減らしながらだましだまし動かしているようなものだってあるわけです。ある意味で、人が緩やかに死んでいくようなシステムです。

そういうシステムを見ると悲しい気分になります。たしかに、業務系のシステムは要件的に人の命には直結しないものばかりですが、システムのライフサイクルと携わる人達全てにまで視野を広げれば、（例えこの本が私のようなエンジニアを視野に含めていないとしても）この本が私には無関係である、とは言い切れないのです。

私は、デベロッパー・プロダクトのオーナー ・ それからユーザー ・ その他もろもろの関係者が心穏やかにすごせるようなシステムを作りたいし、そのためには設計に品質を織り込むというアプローチは非常に有効だと考えているし、そのときにこの本の知識があれば役に立つんだろうな、と思っているわけです。




各章を読んでノートしていきます。