ストーリーボードとサービスブループリント

はじめに

こんぬづは、無職の田中です。

最近知り合いのデザイナーさんにデザインについて教えてもらう機会があり、その中で「ストーリーボード」と「サービスブループリント」というものが出てきたので、知識を固めるために自分でも調べ直しました。今回はそのまとめです。

サービスブループリントについては実際にワークショップをやってもらったので、少し分量多め。

ストーリーボード

共感を測るためのツールという印象。(「印象」と書いたのは、ネットをナナメ読みしたからそんなに自信が無いのと、人によって認識が違いそうだったから)

画像や絵を使って、ユーザーの感情や行動をストーリーに落として、そのストーリーに共感できるかどうかでサービスの価値を図ることにつなげる。

ユーザーテストじゃないけど、ストーリーボードを組んで人に見てもらうのは、市場調査段階でやると良さそう。

参考

• http://esaura.jp/ux-blog/what-is-storyboarding#i
• http://uxmilk.jp/65569

サービスブループリント

ユーザーがサービスをどこから知り、どんなプラットフォームを介して触れるのか(タッチポイント)に重きを置いている印象。

具体的なビジネスに落とし込んで考えているとも言えそう。 ある記事には「ビジネスセッション」と「テクニカルセッション」という2つのセッションでこのツールを使っていくことが書かれていた。 ビジネスセッションで、ビジネス上の理想形(青写真)を描いて、テクニカルセッションで理想を実現可能な形で落とし込む。

テクニカルセッションを経ることで、サービスを提供することができるかどうか測れるのが良さそう。

参考

• https://u-site.jp/alertbox/service-blueprints-definition
• https://webtan.impress.co.jp/e/2013/12/18/16557
• https://it.impressbm.co.jp/articles/-/13912

ストーリーボードとサービスブループリントの違い

ストーリーボードとサービスブループリントは部分的に一致するところもあるが、サービスを提供する側の行動や提供するものまでを想定しているかどうかの違いがありそう。

ストーリーボード: 市場調査段階でやると良さそう サービスブループリント: 需要が見込めて、実現可能かを測るのに良さそう

という感じ。

感想

違いでも書いた通り、それぞれ「使うフェーズが違う」と思った。

エンジニアは実現可能性に目を向けがちだと思った。 最近自分は技術的な面で1→10にするためのスキルを磨いている傾向にあると思っていて、0→1が弱いと感じていたのだけれど、今回触れた2つのツールには良いヒントがあった。

デザインを考える手法やツールはこれまでいくつか触れてきたことがあって、部分的に一致する様々なものがあるので混乱していた。今回人に教えてもらって、調べたことで「なるほど、こういう違いの傾向にあるのか、完全に理解した(←わかってない)」となれてよかった。

雑な理解だけど、もっと深く知るのはより必要になった時にまわそうと思う。

追記

デザイナーさんとは「本来【デザインする】って言った時は、こういったツール/フレームワークを使って深掘りするところから始めないと、どういう見た目にすればいいかも考えられない」なんて話もした。

確かにこの段階を踏まえないと、どういう目標地点に向けたデザインをすればいいかわからないと思った。これを踏まえないで【デザインする】ことって結構多いんじゃないかとも思った。

仕事を始めるとき、「うちの会社(やり方)ではお客さんとのヒアリングで最初にこれをやるんです」くらいに決め打ちをお客さんに要求してしまってもいい気がした。自前のサービスでも。

僕にはセンスが無いから

僕はセンスが無いと思ってるけど、その分足で稼ぐ性分なんだとわかってきた。

なにかとセンスが良くて一人で調べてシュッとこなしてしまうようなセンスの良い人は、物事をうまく抽象化して理解するのがうまかったり、理解に至る道筋が見える人だったりする。

一方で僕は経験から物事を考えたり、やってみて考えることが主になっている。 なにかを理解しようとしたとき、全体のふんわりとしたコンテキストから理解を得ようとする。文章もナナメ読みするし、国語や英語の問題の解き方もそうだったのだけど、多分そのほかの物事を理解するプロセスも同じ。エンジニアリングに関することもこういう考え方をするので、理解が遅いと感じることが多々ある。

センスの良い人には劣等感を覚える。

けれど「行動する」ことが、センスが無いと思っている自分の生存戦略だとわかってきた。

• ブログを書いてみる
• イベントに参加、登壇、運営してみる
• 友達を増やす
• 同人誌を書いてみる
• 技術を学ぶためにサンプルを書いて手を動かす
• 見たことのない映画を見る
• オススメされた本や漫画はとりあえず読む
• やったことのないことはとりあえずやってみる

行動してみると、それまで見えてなかったことが見えるようになるし、なによりそれをやったことのない人より圧倒的に語れることが多くなるのが良い。見えるものが増えると、全く別の物事にも共通したコンテキストが存在するのが見えるようになって、理解が早くなったりする。

本来の言葉の意味とはずれるかもしれないけど、行動しないでいるとどんどん良くないほうに転がっていく感覚に対して、「貧すれば鈍する」という言葉をよく唱えている。行動してみるとわかることが多いし、人生が加速するので動き続けるようにしている。

センスが無いと感じる僕は、足で稼ぐ。

---

そんなふうにここまで生きてきたけど、最近は行動や経験で得たものをそのままにはせず、一般にはどう捉えられているのかなど、本を読んで理解の軌道修正をするようになってきた。実際に体験することは間違ったことではなくて、本に書いてあることとどういう差分があって、机上だけでなく、現実としてはどうなっているのか理解するように勤めるようになった。この辺りは人にうまく伝えられるようになってくる段階な気がするので、体験したことの軌道修正は楽しい。

様々な環境に依存できることが真の安定

誰かから聞いた話が頭の中に残っているだけかもしれないけれど、依存先が多いことが真の安定であるということを信じている。

大きい会社にいることが安定ではなく、世界から自分が求められ続ける状況こそが安定。

一つの環境に依存して安定を求めるのではなく、様々な環境に依存できる生き方が真の安定。

友達が多かったり、仲良くなりやすかったり、なじみやすかったりも同じ。自分はそういう生き方に安定だけでなく、安心を得ているなと思った。

今は割とできていると思っているので、これからもこの生き方がしたい。

技術書典4で、SwiftでTDDを紹介する本を頒布した後の話 #技術書典

まずはお疲れ様でした！

おばんです、技術書典が最高に楽しかった田中です！ありがとうございました！

技術書典自体も、即売会へのサークル参加自体も初めてでしたが、自分がこれまで読んでた本の作者さんとか、ネットでしか会ったことのない人に会えたのが刺激的でした。

サークル参加で忙しくしたものの、なんとか戦利品を勝ち取ることもできたのでよかったです。

はい買いすぎ#技術書典 pic.twitter.com/L5dg6C0gHN

— ダンボー田中 (@ktanaka117) 2018年4月22日

技術書典にサークル参加してきました

こんな本を出しました。

tanakalivesinsendai.hatenablog.com

売り子をして、素敵な表紙を描いてくれた@kiko_twさんには頭があがりません...！ 一緒に本を作って参加できて楽しかったです！

#技術書典

く-07で
お待ちしてます！！ pic.twitter.com/baELRHi9Cc

— ダンボー田中 (@ktanaka117) 2018年4月22日

感想が届いて嬉しかった

Twitterに続々上がってくる戦利品画像の中に、自分が買いた本もある。 感極まる。

技術書典が終わったあと、内容について質問や意見をくれる人がいてくれてとても嬉しかったです。 個人的にもTDDの話で議論できるのはとても勉強になるので楽しいです。

@ktanaka117 今日のTDD本拝読しました。サクッと読めてよかったです。実はテストファーストとTDDの違いがよくわかっていないのでそこに関する記述があるとよかったです。レッド、グリーン、リファクタリングの3ステップを意識するところがTDDなんでしょうか？

— 🄺🄰🅉🅄🄺🄸🤧🄾🄷🄰🅁🄰 (@yamoridon) 2018年4月22日

お疲れ様でした🙇‍♂️ 本を買わせていただいたうちの一人です。
普段テストを書かないのですが、すごく読みやすいです！
ひとつ気になった点があります。38ページのEquatableに準拠したところでpropertyを比較していましたが、その前に作ったメソッドを使うというのはありでしょうか？

— Sato Kei (@Ka0sTie) 2018年4月22日

ぜひ読んだ方は感想とか、気になったところとかを @ktanaka117 までTwitterでメンション飛ばしてください！なんでもしますから！（なんでもするとは言っていない）

支払い状況

• 現金: 86冊
• Kyash: 5冊
• かんたん後払い: 19冊

でした。 価格が1000円だったので、お札でのやりとりでラクできました。 お釣り用意に関して同僚に話したら、「それ諭吉3発で死ぬじゃん」とか言われましたが、余裕でしたw

Pixiv PAYにも対応しようとしたのですが、SMS認証周りの復帰不能バグっぽいのに当たったのでバグレポートしました。きっと近く対応してくれるはず...！

全然印刷数が足りなかった

150部刷って、当日は110部くらい持っていって完売しました。しかも 1時間ちょい 。

初参加で余るかもしれないと日和っていたのですが、前日から急にサークルのチェック数が伸びて、最終的には124くらいになって、全然足りませんでした。

次はもっと強気で刷っていこうと思います！

近々web販売します！

身の回りやTwitterを見ていると、「手に入れられなくて残念だった」という嬉し申し訳ない声が聞こえたので、PixivのBOOTHあたりに、手元に残っている本を少し出したり、電子版を発行しようと思います！

GW中とかを目処に出しますので、ぜひTwitterとかこのブログをチェックしていてください。 乞うご期待。

技術書典4で『Swiftで書いておぼえるTDD』という同人誌を出展します #技術書典 #く-07

はじめに

おばんです、月ノ美兎のプリクラ機の声がツボにハマった田中です。(動画の10分くらいから)

www.youtube.com

さて本題ですが、明日開催の技術書典4で『Swiftで書いておぼえるTDD』という同人誌を出展します。 このブログでは宣伝として、本の魅力と、執筆にあたって込めた想いなどを書いていきます。

dev.classmethod.jp

『Swiftで書いておぼえるTDD』

「Swift でテスト駆動開発に入門する」本です。

みどころ

• TDDについてわかる
• TDDでSwiftを解説する、しかもサンプルコード付き
• テストと型によって駆動するSwiftらしい設計
• SwiftでTDDをするときの課題とその乗り越え方

世の中にはJavaで解説されたものが多い

TDDってJavaで解説されたものばっかじゃね...？ TDD自体は言語にとらわれない開発手法ではあるのですが、実際のところ、言語によって書き方や設計思想、どういうところをテストしなければいけないかは変わってきます。 仮に初歩的な内容の解説だったとしても、早いうちから言語特有の書き方が出てくるはずで、Swiftで書いた場合どうなるか解説したものは世の中に多くありません。 新しいことを学び始めるときは、なるべくわかりやすくハードルが低くあるべきだと思ったので、Swiftを普段書いている人がTDDに入門しやすいようにしたいという想いでこの本を書きました。

TDD ってなんか難しそう...

自分もそう思っていたのですが、コードを書きながら理解していったらわかりやすかったという経験がありました。 『テスト駆動開発』というバイブルも同じような書き方になっているのですが、『Swiftで書いておぼえるTDD』もそれにならって、コードとともにTDDを解説する内容にしました。 ぜひ本を読みながら写経してみてほしいです。

仕様

• サークル名: ダンボールハウス
• サークルスペース: く-07
• ページ数: 64
• 価格: 1,000円

目次

謝辞
はじめに

第1章 TDDとは
1.1 TDDのメリット
1.2 TDDのデメリット
1.3 レッド/グリーン/リファクタリング
1.4 チームの理解を得よう

第2章 書いておぼえる TDD
2.1 開発環境
2.2 サンプルプロジェクトのリポジトリ
2.3 演習問題
2.4 ポーカーの言葉の整理
2.5 トランプの言葉の整理
2.6 カードの文字列表記(インスタンスの生成)
2.7 カードの文字列表記(文字列表記の取得)
2.8 カードの比較
2.9 ツーカードポーカーの役を判定(ペア、フラッシュ、ハイカード)
2.10 この章のまとめ

第3章 2018 年現在の Swift での TDD 開発
3.1 ビルドが遅い問題
3.2 モック自動生成ツールが不足している問題
3.3 他のIDEにできることがXcodeにできない問題

第4章 参考文献
4.1 『テスト駆動開発』
4.2 『実践テスト駆動開発』
4.3 『Test-Driven iOS Development with Swift 4』

著者紹介

さいごに

TDDについてディスカッションしたい

今回本を書いて、自分が考えるTDDについて大きめにまとめて、整理することができたと思っています。 読んでみて「ここは良い説明だった」とか、「もっとこう説明した方がよい」というところがあれば教えて欲しいです。 「読んでみた」ブログを書いたり、疑問が生まれたりした人は、この本を書いてよかったなと思うので、ぜひTwitterでメンションください。(@ktanaka117) これをきっかけに、すでにTDDに詳しい人や、これからTDDを始めて疑問が生まれた人と意見を交わせると僕としてはすごく嬉しいです。

ディスカッションだけでなく、SwiftでTDDペアプロする活動というのを最近やり始めています。 一回やってみた感じだと、どういう設計思想でコードを書くか、どういう観点でテストを書くかという考え方を共有できるのでとても有意義でした。 僕からもお誘いする人もいると思いますが、逆にお誘いしてもらえたら嬉しいので、声をかけてください。

「お客さんにとってプロジェクトというものは一大事である」と聞いた話

受託で仕事をしているエンジニアにとって、プロジェクトは常日頃から身近にあるもので、プロジェクトからプロジェクトに渡り歩くこともよくある話。でも「アプリを作る」、「システムを作る」というようなプロジェクトは、お客さんによっては一世一代の大きな出来事ということもあるという話を聞いた。

プロジェクトは性質上、予測不能なもので、日々それを仕事にしている人間でも扱うのが困難なものだが、どういう地雷がありそうかというのを経験から察知して、よりベターな行動をとることもできる。一方、一世一代のこととなっている人間にとっては、察知できないので、地雷に吹き飛ばされるしかない気がした。

受託お仕事ではその地雷に巻き込まれないために、経験を積んだマネージャーやエンジニアが必要なんだなあ。

だんぼーる

「これは自分だけのせいじゃないしな」と考えるようになってから気持ちが軽くなった話

一見無責任な気がするけれど...

「じゃあ次どうするかな」って考えることをやめなければ良い気がするようになった気がする。(曖昧の重ねがけ)

• 「この要件で、この納期ではまあ仕方ないな」
• 「もっとこうしたいけど、一旦は置いておいてこの路線でいくのがベストっぽいな」
• 「周りに理解されないなら、理解させるための材料を持ってなかったので仕方ないな。あるいはそういう機会や場ではなかったんだろうな。また次」

みたいな。だいたい時間とかコストの問題だけど、それは気付いた時にはどうしようもないことが多いので、地雷踏んだら覚えておいてちょっとずつ良くしていければ良いな。 状況は変わらないけど、気の持ちようで余裕ができるので、リスクの見え方とか今対処すべきかすべきでないかみたいなのが見えるようになる。その方が良いし、焦ってもしゃあない。次の機会でそれを改善できれば良いのだ。改善できれば。

箱根で温泉に入ったら回復した

こんな考えができるようになったのが、この間箱根に行って色々回復させてからな気がする。

hakone-swift.connpass.com

自然に触れて、

動物を間近で見て、

美味しいものを食べて、

綺麗なものを見て、

友達と話をして、

好きなことをして、

温泉に入って回復したら色々良くなったので、定期的に箱根とか温泉とか行く必要がありそうだと思った。温泉付きの開発現場 :kudasai: 。