「サービスデザイン思考入門（オージス総研）」に参加しました

サービスデザイン思考入門@オージス総研

ペルソナ、カスタマージャーニーマップ、ビジネスモデルキャンバスを使いながら、病院のサービスを題材にサービスデザイン思考をしてみる4時間のワークショップ。
個人的にはとてもよい勉強になったけど、会社でやるのはなかなかに大変だなぁ。

資料は、フェイスブックの「デザイン思考コミュニティカレッジ」で公開してくださるそうです。
なんで、資料はそちらから。

ペルソナの設定

はじめに、エンパシーマップを使って、ペルソナを設定しました。

私が知っているペルソナとは違うやり方なので、おもしろかったです。

「共感」を大事にしているデザイン思考にあったフォーマットなんですかね。

カスタマージャーニーマップ（AsIs）

流行りのカスタマージャーニーマップ。

ググると色々なフォーマットがありますよね。

今回は、とてもシンプルなフォーマットを用意してくれていました。

横軸が時間で、縦軸は「アクティビティ（シーン）」、「インタラクションズ」、「感情の起伏」の３つだけ。

インタラクションには、「気持ちとかも入れていいよ」というゆるい感じ。

やりやすいですね。

テーマ設定

カスタマージャーニーマップを踏まえて、テーマを決めます。

「感情が下がったところが狙い目だけど、視野を広く持ってテーマを決めましょう」とのこと。

でも、やっぱり、感情が下がったところをテーマにしちゃいました(^^)

アイディアだし

テーマに沿って、アイディアだしをします。
ここも、多少テーマからズレてもOKとのこと。
あと、「枠からはみだせ！」と。
いっぱいアイディアがでました。

カスタマージャーニーマップ（ToBe）

アイディアを適用したときのカスタマージャーニーマップを書いてみます。
感情のマイナスがなくなりました！

寸劇とフィードバック

できたカスタマージャーニーマップをもとに、寸劇を披露します。
（恥ずかしいけど、結構、雰囲気ができあがってるからできてしまう。）
で、寸劇をみた他のグループからフィードバックをもらう。
「良かったところ」、「改善点」、「疑問点」、「アイディア」の4分類。
意外に、見た人から「こんなのどう？」的なアイディアももらえたりしたのがおもしろかったです。

ビジネスモデルキャンバス

ビジネスモデルキャンバスは有名ですね。
（リーンキャンバスも有名。）
ググればすぐでてきますが、私は書いたことはなく、初体験。
ここで、スイッチが現実モードに切り替わります。
で、かなり「うーん」ってなってしまいました。
現実では、キャンバスの時点やプロトタイプをリリースした後のフィードバックで、何度もやりなおすんでしょうね。

ピクト図解

ピクト図解はワークはなくて、説明だけでした。
でも、ルール自体は簡単なので、使うのは簡単そうです。
使いこなすのは難しいんでしょうが。

ふりかえり

KPTです。

まあ、おなじみのやつです。

懇親会

色々なバックボーンの人の色々な話を聞けて、とてもよい懇親会でした。
中でも「実際には、叩かれまくるフェーズが絶対必要！」というのが印象に残りました。
そりゃそうですよね。

お礼

4時間コースで、懇親会の軽い飲食があって1000円。
えらいぞ、オージス！
これからも頑張ってオージス！！
ということで、オージス総研さん、ありがとうございました。

DAD本読書会#4に参加しました

DAD本読書会#4 @21cafe

DAD本こと、「ディシプリンド・アジャイル・デリバ​リー エンタープライズ・アジャイル実践ガイド」の
読書会#4です。
今回は、監修者の藤井さんに質問して、お話を聞いたり、みんなでディスカッションする方式でした。
DAD本勉強会ですが、RUPの話で盛り上がってしまいました。
以下、メモです。
誰がしゃべったのかは、もう覚えてませんので、藤井さんの見解とズレもあると思いますので、ご注意を。

方向付けフェーズ

方向付けフェーズは重厚じゃない。ゆるいRFPをつくるイメージ。

お客様がアジャイルについてわかっていないとDADを提案するのは難しい？
教育をして、DADでできるか判断する。
RFPでてからだと遅い。

検討不足と学習や発見との違いは？

そもそも、検討不足と学習や発見の分類に意味がない。
抜けが見つかってよかったと言えばいい。
結果的に価値のあるものをつくるために、つくってみて、動くものをみた方が抜けを見つけやすいことが多い。

推敲フェーズ

Unified Processの「アーキテクチャ中心」は捨てた？

なんでDADでは推敲フェーズがないのか？

出版前には推敲フェーズがあった。
Unified Processの「アーキテクチャ中心」を完全に捨てた訳ではない。
アーキテクチャを初期に確定させるのはNGだけど、変える前提で、ある程度アーキテクチャの見通しをたてて、リスクを潰すという発想。
そうなると、フェーズとして残さない方がよいという判断だと思う。

XPではアーキテクチャをはじめに考えない？

Kent Beckはテクニカルなリスクを優先順位に一切考慮しないと言っていて、Martin Fowlerは少しは考慮すると言っている。
このレベルの人たちは、飛行機の中でxUnitつくっちゃう人だから、頭のなかでアーキテクチャのこともちゃんと考えてるから崩壊しない。
DADでも他でもそうだが、stabilizationという機能を追加しないでアーキテクチャの整合をとるためのイテレーションを設けることがある。
大規模開発や金融系の開発をバックボーンに持つ人はアーキテクチャを重視する傾向にある。

DADは合意を重視

DADはアジャイルスケーリングモデルの中間。
意思決定やコミュニケーションの仕方を整理している。
常に早くリスクヘッジする。
それがビジネスリスクかテクニカルリスクかは問わない。
重要なのはそれを合意すること。
フェーズの区切りは、合意ができていること。

WaterfallとUnified Processは何が違う？

Waterfallで1次開発、2次開発とやっていたら、繰り返し。
Waterfallはアーキテクチャを重視する。
そもそも、ロイズの論文ではWaterfallは規模が大きい時は2回は繰り返すと言っている。
だったら、WaterfallとUnified Processは何が違う？

ユースケース駆動

UPの「ユースケース駆動」、「アーキテクチャ中心」、「インクリメンタルかつイテレーティブ」の3つで残るのは、ユースケース駆動。
あとは、1年を2回とかで反復と言えるか？

日本での大規模開発はRUPがいい

RUPはヘビーという誤解がある。
RUPは成果物を決めているが、成果物は紙ではない。
決めなければいけないことを定義しているだけ。
アジャイル開発でプロジェクトを進めるときは、バラバラの要素を組み合わせる必要がある。
RUPはまとまっている中から省いていく。
そうとらえると、日本の大規模開発では、RUPがあっているように思う。

業務システムでアジャイル開発は難しい？

業務システムは機能も多いし、ある程度まとまらないと評価できないので、アジャイル開発が難しいのでは？
BPRをしたいが、ステークホルダーが多くて、かつ、ITリテラシーが低い人ばかりなので、使わせて確認しながらやりたいというお客様の要望でやってうまくいったことがある。
業務システムという区切りではなく、何をしたいかが重要。
ゴールが不明確でアジャイルと言っているケースが多い。
BPRしたいとか、変えたいという意思がないとアジャイル開発する意味は無い。

大規模ではアジャイル開発は難しい？

なんで大規模だとアジャイル開発は難しい？

意思決定が難しいのでは？

Waterfallでも意思決定しているはず。ものを見せずに意思決定できるのなら、ものを見せたらもっと意思決定がしやすいはずでは？
みせる人数が多くて大変だったり、みせると意見がですぎてまとまらないのでは？
人数については、機能ごとに対象者は絞られるので、そうでもない。
ただし、バラバラにでた意見のまとめ役は必要。
意見はいっぱいでていい。
くだらない意見がいっぱいでて、実際に動くものをみると、くだらないことがわかるようになる。

複数システム、プロジェクトと連携するマルチベンダーの場合は？

アジャイル開発というかイテレーション開発になるが、統合リスクを管理するために、定期的に統合するメリットはある。

感想

アジャイル開発の勉強会で出席者がSIの人ばっかりってのはめずらしい。
貴重な場です。

あと、21cafe。すごくおしゃれで、無料。すばらしい！
いつか自分もここで勉強会を主催したいなぁ。

お礼

藤井さん、21cafeさん、ステッカーありがとうございました！