禅とソフトウェア設計技術

心の落ち着きは、技術的作業にとって決して表面的なものではない。これこそが重要なものである。心の落ち着きを生み出すものは、優れた仕事であり、それを破壊するものは悪い仕事である。仕様書、計量器機、品質管理、最終点検などはすべて、作業責任者に心の落ち着きを与えるための手段である。ここでは心の落ち着き以外に重要なものは何ひとつない。なぜかといえば、心の落ち着きこそが例の <<クオリティ>> を知覚するための前提条件だからである。

(※ 禅とオートバイ修理技術より(単行本 下巻164ページ) )

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

ソフトウェアにとって、心の落ち着きをもたらしてくれるもの、つまりは優れた仕事、 <<クオリティ>>を知覚できるものは何でしょうか?

Excelの設計書?
トランザクションスクリプトなソースコード?

これらを注意深く、完璧に仕上げたとして心に落ち着きを与えられるでしょうか?

変わり続ける仕様・業務の知識・ビジネス、100%なくすことができないバグが存在する前提がある以上、ソースとドキュメントとの乖離があるのではないかという不安と、ソースコードを変更するたびに他にも影響があるのではないかという不安は消えないのではないのでしょうか?

であれば、ソースコードに変更を加えることが容易になる設計手法こそが心に落ち着きを与えうる設計であると言えると思うのです。

私たちは、ドメイン駆動設計にその活路を見出し取り組んでいます。

それにしても、「心の落ち着き」と「<<クオリティ>>」を結びつけるということに意外であると思う一方、ソフトウェアに携わってきた経験上、妙な納得感がありました。
設計手法以外にも深夜・休日まで仕事をしてしまう、少ないコミュニケーション、要件定義・設計・開発など工程でチームが分かれる・・・などなど心を乱す要因はいろいろありそうですね。

最後に、心の落ち着きを生み出すために美味しい一杯のコーヒーを飲みましょう。。。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

CenterではなくCoreを探し駆動していく 〜人間中心設計についてもう一度考えてみた〜

ギルドワークスの佐々木です。

私はエンジニアですが、バックグラウンドとして人間中心設計(Human Centered Design:HCD)を学んできました。このエントリーでは、このHCDを否定するわけではなく、もう一歩進めて、User/HumanをCenterにするのではなく、CoreにしてDriveするのがよいのではないか、ということを書いてみたいと思います。

続きを読む

エンティティの識別子をラップしたクラスを用意するとよい理由

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

今回は、ドメイン駆動設計における、エンティティの識別子の実装面について考えてみたいと思います。(あまり本質的な話題でなくてすみません。。。)

エンティティの識別子、どう実装していますか?

私の場合、以下の図のようにエンティティが直接LongやStringなどプリミティブの型で持ってもよいと思っていました。エンティティの識別にしか使われないのでエンティティが直接持っていた方が使いやすいと思っていたのです。

VoyageClass

ドメイン駆動設計本の例はどうでしょう・・・。

ドメイン駆動設計ではプリミティブの型を使用している例も載っていますが、書籍内のサンプルを実装したDDDSampleではVoyageNumberやTrackingIdなど識別子をラップしたクラスを使ってます。

VoyageAndVoyageNumberClass

実践ドメイン駆動設計本では日付時刻を含んでいるような識別子を例にあげてこのような複雑な識別子はラップしたクラスを使うべきとあります。

要は識別子の複雑さや使われ方によるのかなと思います。

という曖昧な結論では記事になりませんので、識別子用のクラスを持つことで効果がでるケースを紹介したいと思います。

例は、よくある求人サイトの想定で、求職者が求人に応募するようなモデルです。

まずは、求人パッケージ(モジュール)。
求人

そして、求職者パッケージ(モジュール)。
求職者は求人に応募しますので、応募クラスは求人IDクラスを持っています。
求職者

・・・と、クラス図だけではなんてことないのですが、パッケージ図を見るとこうなります。
求人サイト

これが求人や求職者の識別子がプリミティブな型の場合は以下の通り依存関係を持つことはありません。

求職者2

求人サイト2

実装上はこれでも問題ないのですが、ドメインの知識をソースコードに反映するということを考えると、パッケージ間の依存関係がきちんと表現できるとよりわかりやすい設計になると思います。

エンティティの識別子はそのエンティティの同一性を保証してあげるだけの役割ですので、わざわざラップして使う必要がないと思いがちです。
しかし、ラップして使うことで、プリミティブな型をそのまま使うことに比べてモデルをより豊かに表現することができ、ドメインの知識をより深く理解する手掛かりとすることができます。

ぜひ試してみてください。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

※ アイキャッチ画像(Original Update by paurian https://www.flickr.com/photos/paurian/3707187124)

新しく「ドメイン駆動設計のパターン・原則・プラクティス本」が出ました

井上です。 以前、本ブログでドメイン駆動設計(Domain-Driven Design 以下 DDD)のリファレンス本について紹介致しました。 おかげさまで非常に多くの方にご覧頂いたようで、DDDの注目度を改めて感じました。 また、「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本) に続く2冊目ドメイン駆動設計本として、「実践ドメイン駆動設計」(以下 DDD実践本) も出版され、日本におけるDDDへの注目度がさらに増しているように思います。 私自身、普段からDDDを用いた開発を行っているので、日本語で多くのDDD情報が入手できることはとても嬉しい限りです。 そんな中、DDDを冠した「Patterns, Principles, and Practices of Domain-Driven Design」という新しい本 (以下 DDDパターン・原則・プラクティス本) が 2015/4/20 に出版されたようです。

Patterns, Principles, and Practices of Domain-Driven Design

私自身、まだ購入したばかりで流し読みしか出来ていないのですが、簡単に紹介したいと思います。

DDDパターン・原則・プラクティス本とは

本書は、大きく4つのパートから構成されています。概要は以下の通りです。

  • PART I – DDD の哲学 (philosophy) 、原則 (principles) 、プラクティス (practices) について
  • PART II – 境界付けられた境界 (bounded contexts) を統合する 戦略的パターン (strategic patterns) について
  • PART III – 効果的なドメインモデルを作るための 戦術的パターン(tactical patterns) について
  • PART IV – ドメインモデルを活用し効果的なアプリケーションを構築するために適用可能なデザインパターン (design patterns) について

戦術的パターンより戦略的パターンが先に紹介される構成となっており、その点はDDD実践本と同じですね。 また、本書は792ページと非常にボリュームがあります。 DDD本が560ページ、DDD実践本が 656ページであることと比較しても、そのボリュームがわかると思います。 なお、DDD本とDDD実践本のサンプルコードはJavaで記述されていましたが、本書はC#で記述されています。

章構成

具体的な章構成は以下のようになっています(日本語訳は私が付けたもので、正式なものではありません) 各パート・章のタイトルを見ていただければ、どのような内容になっているのかある程度想像がつくのではと思います。

  • INTRODUCTION
  • PART I: THE PRINCIPLES AND PRACTICES OF DOMAIN-DRIVEN DESIGN (ドメイン駆動設計の原則とプラクティス)
    • CHAPTER 1: WHAT IS DOMAIN-DRIVEN DESIGN? (ドメイン駆動設計とは何か?)
    • CHAPTER 2: DISTILLING THE PROBLEM DOMAIN (問題ドメインの蒸留)
    • CHAPTER 3: FOCUSING ON THE CORE DOMAIN(コアドメインに注目する)
    • CHAPTER 4: MODEL-DRIVEN DESIGN(モデル駆動設計)
    • CHAPTER 5: DOMAIN MODEL IMPLEMENTATION PATTERNS(ドメインモデル実装パターン)
    • CHAPTER 6: MAINTAINING THE INTEGRITY OF DOMAIN MODELS WITH BOUNDED CONTEXTS(境界づけられたコンテキストのドメインモデルの整合性を維持する)
    • CHAPTER 7: CONTEXT MAPPING(コンテキストマッピング)
    • CHAPTER 8: APPLICATION ARCHITECTURE (アプリケーションアーキテクチャ)
    • CHAPTER 9: COMMON PROBLEMS FOR TEAMS STARTING OUT WITH DOMAIN-DRIVEN DESIGN (ドメイン駆動設計から始めたチームの共通問題)
    • CHAPTER 10: APPLYING THE PRINCIPLES, PRACTICES, AND PATTERNS OF DDD (DDDの原則、プラクティス、パターンを適用する)
  • PART II: STRATEGIC PATTERNS: COMMUNICATING BETWEEN BOUNDED CONTEXTS(戦略的パターン:境界づけられたコンテキスト間のコミュニケーション)
    • CHAPTER 11: INTRODUCTION TO BOUNDED CONTEXT INTEGRATION(境界づけられたコンテキストの統合の概論)
    • CHAPTER 12: INTEGRATING VIA MESSAGING(メッセージングによる統合)
    • CHAPTER 13: INTEGRATING VIA HTTP WITH RPC AND REST (RPCやRESTを用いたHTTPによる統合)
  • PART III: TACTICAL PATTERNS: CREATING EFFECTIVE DOMAIN MODELS(戦術的パターン:効果的なドメインモデルの構築)
    • CHAPTER 14: INTRODUCING THE DOMAIN MODELING BUILDING BLOCKS (ドメインモデリングの構成要素の紹介)
    • CHAPTER 15: VALUE OBJECTS (値オブジェクト)
    • CHAPTER 16: ENTITIES (エンティティ)
    • CHAPTER 17: DOMAIN SERVICES (ドメインサービス)
    • CHAPTER 18: DOMAIN EVENTS (ドメインイベント)
    • CHAPTER 19: AGGREGATES (集約)
    • CHAPTER 20: FACTORIES (ファクトリ)
    • CHAPTER 21: REPOSITORIES (リポジトリ)
    • CHAPTER 22: EVENT SOURCING (イベントソーシング)
  • PART IV: DESIGN PATTERNS FOR EFFECTIVE APPLICATIONS(効果的なアプリケーションのためのデザインパターン)
    • CHAPTER 23: ARCHITECTING APPLICATION USER INTERFACES (アプリケーションのユーザインタフェース設計)
    • CHAPTER 24: CQRS: AN ARCHITECTURE OF A BOUNDED CONTEXT (コマンドクエリ責務分離 : 境界づけられたコンテキストのアーキテクチャ)
    • CHAPTER 25: COMMANDS: APPLICATION SERVICE PATTERNS FOR PROCESSING BUSINESS USE CASES (コマンド:ビジネスユースケースを処理するためのアプリケーションサービスパターン)
    • CHAPTER 26: QUERIES: DOMAIN REPORTING (クエリ:ドメインのレポーティング)

想定する読者

Introduction」の「Who Should Read This Book」で、本書の想定読者について触れています。 以下、上記からの引用です。

It is not a replacement for Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans (Addison-Wesley Professional, 2003). Instead, it takes the concepts introduced by Evans and distills them into simple straightforward prose, with practical examples so that any developer can get up to speed with the philosophy before going on to study the subject in more depth.

ここでは、本書が「DDD本の代用品ではない」と明確に述べていますね。 また、「エヴァンスによって紹介された概念を、単純で (simple) 分かりやすい (straightforward) 散文 (prose) に蒸留する (distill) 」という記述もあります。 これは、DDD本自体が文学的で韻文形式の文章を多く含んでおり、それがDDD本の読みづらさに繋がっていたと思うので、韻文と対比する形で散文 (prose) という言い回しを使うことで、分かりやすさを強調しているのかなと解釈しました。 つまり本書は「DDD本を読むだけでは分かりづらかったDDDの概念を、わかりやすい文章と実践的なコード例を用いて解説する」という内容になっていると思います。 著者が述べている通り、DDD本を既に読まれた方が、理解を深めるための副読本として読むのが良いのかもしれませんね。

まとめ

今回は、DDDパターン・原則・プラクティス本について簡単に紹介しました。 DDDへの理解を深めるために有用そうな内容になっているので、少しづつ読み進めていきたいと思います。 興味のある方は手に取ってみてはいかがでしょうか?(個人的には日本語訳されることを期待しています)

デザインの神様 舞い降りて

こんばんは、ギルドワークスの藤田です。

皆さんは「神」を信じますか(※怪しい勧誘ではありません)。

私は不可知論者なので、神様がいてもいなくてもいいし、いたとしても現前はしないだろうということで、あまり祈ったりしないのですが、日常のふたつのシチュエーションで、神様に助けを乞います。

ひとつは、お腹が痛くてトイレにこもっている時。
もうひとつは、デザインワークが進まない時です。

明日までにビジュアルデザインを提出しないといけないのに神が降りてこない…!

私はしょっちゅう「デザインの神様が降りてこない」「神が降りてこないのでデザインがピリッとしない」と言うのですが、これは、決して言い訳ではありません。本当に、デザインの神様が降りてきてくれないのです。
デザイナーの仕事は、実はパソコンに向かう時間は本当に少ないです。
その前にリサーチし、構想をあたため、どのような表現で、どのように伝えるか、手書きのラフを何十枚も描いて、そして、これならいける!という確信を得た時に、やっと、パソコンへ向かうのです。
パソコンで行う作業は「清書」であって、パソコン作業で何かクリエイティブなことをしているわけではありません。
この「確信」を、「神が降りてきた」と、呼んでいます。

そんなの作業が遅い言い訳だろ…という向きもあるかもしれないので、デザインの神様が舞い降りてきていない、我ながら「いけてないわー」な、バナーはこちらです。

神が降臨しなかったバナー

ギルカン1

先日、デザインの神様を降臨させる踊りを3時間踊り続けたところ、やっと神が降りてきました(自己判定)。そのバナーがこちらです。

神が降臨したバナー

ギルカン2

比較してみるとわかりやすいかと思いますが、基本的な部分というのは変わっていないのです。

  • 伝えたいこと:開発者向けカンファレンスをギルドワークスが開催すること
  • 伝えたい相手:エンジニア、デベロッパーなど、開発者の方々
  • 使っている色:紺寄りの青と白
  • フォントやキャッチフレーズ
  • 直線と矩形

神が降臨済みのほうは、アイコンを用いて視覚的に細部が整った印象ではあるのですが、この細部によって、全体も大きく異なります。

デザインのトーン&マナーが大事だよというブログを先日書きましたが、やはり、トーン&マナーがどんなに精緻に作られていたとしても、形として目に見えるものが、そのトーン&マナーをふさわしく表現するものでなければなりません。
私自身はコンテンツファーストを標榜していますが、ビジュアルデザインが「何だってかまわない」「どのようなものでもありさえすればいい」というふうには決して思わず、そのコンテンツにふさわしい、コンテンツを伝えるに足るものでなければ、コンテンツの良さも伝えられないのでは、と考えています。

ただ、デザイナー歴はそこそこあるものの、デザインの神様を気軽に降臨させる呼びこむコツがまだわかっていません。
日頃からの鍛錬が必要なのだと思いますが、デザインワークのたびに、「神が降りてこない…!」となるのはよろしくないので、できるだけ早く神を降ろせるように精進する次第です。

そんなわけで、このバナーで一番伝えたいことである、ギルド開発者カンファレンス2015へのご参加をお待ちしています!

開発者ギルドカンファレンス2015
https://guildworks.doorkeeper.jp/events/26156

開発チームのビルドをどのように始めるか

ギルドワークス市谷です。

ギルドワークスで手がけている開発プロジェクトは、チームメンバーがだいたいリモートワークで参画しています。ギルドワークス自体も、仙台や大阪で開発しているメンバーがいますし、一緒に組んでいるフリーランスのデベロッパーも、東京にかぎらず日本の場所を問わず参画してもらっています。東京在住であったとしても、所在が離れあっているため、結局どのような立ち位置であれリモートワークなチームとなるわけです。

リモートワークに限らず、チーム運営を間違えると「何を何のために作っているのか」が見えにくくなりがちです。目の前のバックログを倒して続けていれば、目的にあったプロダクトがいつ出来上がるだろうというのは、いくら何でも楽観的過ぎますよね。プロダクトオーナーと目線を同じくとしたチームでなければ、期待するプロダクトを作り出すのは難しいところです。プロダクトオーナーやチームの他メンバーとの接点が少ない、限られる場合には、意識を高く持ち保つにはさらに不利といえます。では、どのようにしてチームビルドを始めると良いでしょうか。

ギルドワークスでは「何を何のためにどれだけ作るか」を見定める、いわば開発の入口を整えるために価値探索というフェーズを設けるようにしています。我々が仮説キャンバスと呼んでいる一枚絵でコンセプトをまとめ、仮説検証を行なうようにしています。検証を終えるまで、開発は始めません。No Why, No Devの考えを取っています。

結果、開発を始める際には「コンセプトが簡潔にまとめられた検証済みの一枚絵」「ユーザー行動に基づいて整理された必要な初期のバックログ群」が用意されており、「プロジェクトの方針を可視化したインセプションデッキ」づくり、そして「バックログの手入れ(内容を理解し、開発可能に仕立てていく)」からプロジェクトをスタートするのです。「何を何のために作るのか」の背景のすりあわせ、ディスカッションをチーム全員で行います。

プロジェクト立ち上げの時期は、さらにプロダクトの初期モデリングをチームで行うようにしています。インプットとなる情報から叩き台となるモデルを作り議論したり、白紙のホワイトボードから全員でモデリングを始めたり、やり方は様々です。この初期モデリングを通じて、このプロジェクトにおける関心領域は何なのか、その可視化と共通理解を作ることを目的としてやります。この際には、一箇所に集まるか、オンラインでアウトプットを共有しながら進めます。

以上のように、開発プロジェクトを始める際には私たちは「状況作り」を重視しています。時間は相応かかりますが、この時間を惜しんだばかりに、後々途方も無いすれ違いを生んでしまいかねないことを考えると、躊躇の必要がない取り組みといえます。

ギルドワークスの取り組みをご紹介する場「開発者ギルドカンファンレンス」を設けました。ぜひご参加ください。

26156_normal_1435841034_doorkeeper用バナー

トーン&マナーの日々よ

こんばんは、ギルドワークスの藤田です。

皆さんの職場は、業務時間中にイヤホンをするのがOKな職場ですか?
ギルドワークスではイヤホンOK、というか、そもそも仕事中にこうしなければならないという縛りが何ひとつなく、靴下を脱ぎ始めたり壁に足をたてかけたりして仕事をする代表がいたり、正座しながらチョコパンを食べてPCに向かう現場コーチがいたり、そんなフリーダムな雰囲気ですが、私は集中したいときは爆音で音楽を聴くことが多いです。
そのせいもあってか、「このお客様のテーマソングは○○だな!」とか、「このサービスのテーマは■■だ!」とか、音楽や人をイメージすることが多いです。

先日も、とあるお客様のトーン&マナー設定をおこない、UIイメージを作成したのですが、サービスのコンセプトを知った時から、「これはB’zだ! B’zの”Times Flies”だ!」と、そのお客様の仕事の時は常にB’zを聞きながらで、アウトプットを共有するときも常に「B’zです!」と言い続けてきたのですが、みんな、私がいつもの通り寝言を言っていると思っていたのか、完全スルーされていました……でも、B’zなんです!

トーン&マナー設定

さて、ここから本題です。

実は、これは、「トーン&マナー設定」の画像です(さすがに、B’z画像はご提案の時には削除していますが…)。

トーン&マナー設定は、簡単にいえば、「色、モチーフ、印象の設定」なのですが、これによって、ビジュアルデザインの基礎ができる、というだけではありません。
そのサイトなりアプリケーションなりを「使う人(ユーザー)」はもちろん、「提供する人(サービス事業者)」、「システムやデザインを制作する人(制作者)」にも非常に重要なものなのです。

なぜなら、トーン&マナーは、サイトやアプリケーションや、それを含めたサービスが、「どのようにユーザーと接するか」「どのようにしてユーザーとコミュニケーションをとるか」を定める、ブランディングとしての意味も含んでいるからです。

ブランディングとしてのトーン&マナー

ビジュアルデザインは、ただの「見た目」なのではなく、そのサービスやアプリが「どういうものなのか」「ユーザーに対してどういう接し方をしてくるのか」ということの、一番わかりやすい表されかたです。

たとえば、BtoBの、信頼性が必要なインフラサービスが、「僕は明るくて楽しくてちょっとうっかりさんだよ!」と、表明するようなトーン&マナーをもっていたとしたら、ユーザーは高いお金を払ってそのサービスを利用する気になれなさそうです。それに、担当者はそういう人が好きでも、偉い人が承認する稟議に通らないかもしれません。
とてもかわいらしい雑貨を売っているECショップなのに、「道に倒れて誰かの名を呼び続けたことがありますか……」と、表明するようなトーン&マナーだったら、可愛いもの好きのユーザーは、そこに自分の求めるものがあるとは思えないでしょう。

それがどんなに素晴らしいサービスで、どんなに便利なものであっても、「使う人とどういうふうにコミュニケーションをとっていくか」が想定されていなければ、サービスは結局使われないままで終わってしまいます。

「このサービス(や、アプリケーション)は、こういうもので、こういう接し方をあなた(利用者)とするものです」ということを見定め、それに沿ったコミュニケーションを総体として行っていくための基礎がトーン&マナー設定なのです。

これはつまり、ブランディングの一部であって、ブランディングである以上は、利用者だけに関わるものではありません。
コミュニケーションは双方向であり、「このサービスはこういうものです」と、表明しているのですから、サービスを提供する事業者もそのように振る舞わなければなりません。
「信頼できる」トーン&マナーを持っているのに、カスタマーサポート部門が信頼できない振る舞いを行っては、トーン&マナーに反しています。
また、トーン&マナーに反した広告やプロモーションを行っても、コミュニケーションの前提がそもそもずれているので、無駄な投資となるだけです。
そして、そのサービスを開発する制作者も、「このサービスはこういうものです」に、合致しない振る舞いを、機能として実装するわけにもいかないのです。

「色を決めるだけ」「印象を決めるだけ」と、思われがちなトーン&マナーですが、サービス全体をひっくるめた、広義のデザインの基盤となるもので、これをまず最初に行うことは、その後の事業展開においても、非常に重要なことだと考えています。

ギルドワークスでは、新規事業や既存の事業の見直しを支援する、「価値探索」サービスを行っていますが、その中で、このトーン&マナー設定メニューも含んでご提案をしています。

企画や開発だけでなく、デザインに基づいたブランディングについてもお悩みのかたは多いかと思います。
何の色を使って、何のモチーフをもって、どういうふうにユーザーに接するのがベストなのかは、ビジュアルデザインだけでなく、UXデザインの領域にも踏み込むことなので、なかなか自社だけで行うのは難しいところがあるのではないでしょうか。

現在、期間限定でこの価値探索サービスの資料が無料でダウンロードできますので、企画だけでなく、ブランディング、利用者とのコミュニケーション戦略にお悩みのかたも、ぜひご一読ください。

資料ダウンロード:http://guildworks.jp/download_201506/

自分のところのサービスやサイトのトーン&マナーをつくってほしい!というご要望がございましたら、ヒアリングにお伺いしますので、こちらもお問い合わせください。

では、そろそろ、THE YELLOW MONKEYをテーマソングにしたお仕事に戻ります!

利用者を取り巻くあれこれを可視化する

ギルドワークスの佐々木です。

ソフトウェアを実利用者の文脈に沿ったものとして届けるために、利用者を知ることが大切であると言われます。
利用者を知るといった場合に、インタビューや行動観察をしてユーザーデータを集めることはとても重要ですが、その結果を分析しなければ、意味のないデータになってしまいます。
今回の記事ではまず、人間中心デザイン(Human Centered Design:HCD)の観点から整理してみたいと思います。

Contextual Design

コンテクスチュアル・デザイン(Contextual Design)という手法・考え方があります。これは、ユーザー中心デザイン(User Centered Design)の手法として、1990年代後半にHugh Beyerと Karen Holtzblatt によって提案されました。この手法は以下の6つのプロセスより成り立っていますが、今回は Work modelingにフォーカスします。

  • Contextual inquiry:インタビューによるユーザー調査
  • Work modeling:5つのワークモデルを用いた分析
  • Consolidation:分析結果の統合
  • Visioning & StoryBoarding:統合結果をシナリオ化しリデザイン
  • User Environment Design:ユーザーをとりまくシステム環境を描く
  • Prototyping and Implementation:プロトタイプと実装

Work Modeling

Work Modelingでは、前段のコンテクスチュアル・インクワイアリーで得られたデータをモデル化します。このモデル化には、5つのワークモデルが使われます。

  • Flow model
  • Sequence model
  • Cultural model
  • Artifact model
  • Physical model

Flow model

フローモデルは、利用者が行なうべきコミュニケーションを可視化します。利用者があるタスクを行なう際に、どんなコミュニケーションを必要としているかを、公式・非公式区別なく記載していきます。必要であれば、人工物も描くようにします。
フローモデル

Sequence model

シーケンスモデルは、時系列で流れをみるものです。ある利用者がどんなタスクをどんな順番でこなしているのかを可視化します。流れ作業でやってしまっているステップでも、書き出してみると実は必要のないステップであることに気付いたりすることがあります。
シーケンスモデル

Cultural model

カルチュラルモデルは、ある利用者が何かのタスクを達成するために、周りの人にどんな影響を受けているかを可視化します。何かを意思決定する時、その人個人だけが独立して判断していることはほとんどありません。周りの何らかの影響を受けていることが多いです。重要なステークホルダーを洗い出すことで、デザインにつなげます。
カルチュラルモデル

Artifact model

利用者がゴールに向かうために使う人工物・道具を可視化します。単に「同僚に連絡する」と言っても、チャットツールを使う人も居れば、狼煙を使う人もいるでしょう。その使う道具を洗い出して、デザインのヒントを得ます。

Physical model

利用者が置かれている環境を可視化します。どんな部屋でシステムを使うのか、モバイルデバイスを使っているのか、近くにはどんなものが置かれているのか。そういったことを洗い出すことで、どんなものを届けたらよいのかが判断できるようになります。

カスタマージャーニーマップ

紹介した5つのワークモデルを利用しているデザイナーは、あまり見かけなくなりました。その代わりに活用されているのは、カスタマージャーニーマップサービスブループリントであると思います。

(参考)
2時間で作るカスタマージャーニーマップ――実例とともに考える新しい「おもてなし」のカタチ
ブループリント | Service Design Tools

これらは、短時間でワークショップ形式でユーザーの行動を追うためにとても有用なツールであると考えます。一方で、多数のステークホルダーが関わったり、多様なストーリーがある場合に、1人の利用者、1つのストーリーに強くフォーカスが当たってしまう傾向があります。そういったトレードオフを理解しつつ、利用者を取り巻く環境を可視化する手法を組み合わせ、利用されるソフトウェアの開発に繋げていければと思い、日々活動しています。

まとめ

ユーザーの調査結果を分析する際に、どんな可視化の方法があるかを簡単にまとめました。
次回は、システムを設計する視点からのモデリング方法についてまとめたいと思います。

ギルドワークスでは「価値探索」というサービスを提供しています。その中では、想定利用者のインタビューを実施し、マップやキャンバスを駆使しながら、利用者により良いシステムを届けるお手伝いをしています。
本日、弊社で実施している内容をご紹介する資料を公開し始めました。ご興味がありましたら、こちらよりご覧ください。

(アイキャッチ画像は https://flic.kr/p/4H63FH より引用しました。)

鉛筆とラフスケッチと私

こんにちは、最近の仕事道具は鉛筆、な、ギルドワークスの藤田です。

とあるウェブ開発のデザイン制作で、ラフスケッチを描いたり、ビジュアルイメージをかためるのに、このところずっと鉛筆を使っています。
このクライアント様は、自社のブランディングをとても大切にされているので、思いを反映したビジュアルデザインのために、まず手書きの、鉛筆を使ったスケッチ画を作成して、それを元にして意見交換し、お互いのイメージしているもののすり合わせを行っています。
デザインワークの7割くらいは、お客様のイメージと、そのプロダクトやサービスのコンセプトと、ビジュアルデザインというアウトプットの3者を合致させることに充てられます。
無事サービスがローンチになりまして、クライアント様の許可が出ましたら、このブログでこんなふうにやってたんです、という報告をしたいなあと思っています。

検証のための手書き

普段、ワイヤーフレームを起こしたりするときには、プロッキーを愛用しています。
img_02手で書く、ということには、相当のこだわりがあり、私はペーパープロトタイピングも好きなのですが、手で書くことにこだわる理由は、手書きのアウトプットには、だいぶん想像の余地が残るからです。

もちろん、ウェブでしたら、そのままHTMLなり何なり、コードを書いたほうが画面として早い、というのは重々承知しているのですが、コードというカタチをもってしまうと、コードに対する検証になってしまうのではないかという懸念があるのです。
「その実装以外の表現方法はないのか」「本当にその画面で、その遷移で、その情報でいいのか」ということを曇りなき眼で、また、早い段階で検証するには、手書きに勝るものはないのでは、というのが私の考えです。

それと、手書きの利点としては、項目と項目をつなぐのがとても簡単です。ぐるって囲んで、線でつなげればいいだけです。

img_04

こういう、ある項目からつながっていくランダムな関係性を表現するには、アプリケーションなら何秒もかかりますが、手書きなら体感1秒です。

「人が机に向かっていて、机の上にはPCと書類とタブレットがある」ということを伝えるのにも、手書きにすれば3秒です。

img_03

相当雑ですが、何しろ3秒で書けるレベルですので…でも、この程度でも、要素(人、PC、机、紙、タブレット)と、その配置、要素同士がどういう関連をもっているのかを伝えるには、十分です。

関連性を見出すための手書き

関連性、というのが手書きのキーワードかもしれません。
クライアント様へのヒアリングで、お客様がポロッとおっしゃったことを拾ったり、議事録に載せるほどではないけれども、何か興味深いエピソードを書き残しておいたり、そうしたらその前後で、これとこれが実はつながっていた!ということがあったり。
ざっくり書きつつも、書かれた事柄になんとなくの関連性が見えてくる時には、いいヒアリングができた、お客様のことを知ることができたと、思えます。

また、ミーティングなどの場でざっとインターフェイスの案を手書きで起こして、求められていること、求めていることを確認し、それが有効かどうか、判断するときもあります。
さしあたっての共有、すり合わせには、「手書きする」ということは、有効なのではないでしょうか。
いきなりパソコンに向かうのではなく、手をもって、ことばを書いてみる、ものの形をスケッチしてみる、というのは、クオリティの如何ではなく、思考の鍛錬として、なかなか使えるように思います。

手書きの難点といえば、マジックを使った時は、手がひたすら汚れることでしょうか。だいたいいつも私の指先にはプロッキーの黒か青がびっしりついていて、たまに、会社帰りにおしゃれなお店で買い物をするときなんかに、ハッと気づいて恥ずかしい時があります。

そんな、手書きの良さを熱く語ったあとで何なんですが………

「モバイルPCがないと不便でしょう」という代表のお心遣いにより、MBAを支給していただきましたワーイヽ(=´▽`=)ノ
(入社してから、iMacのみで仕事をしていました)
2015-05-27 13.29.54-2
手書き至上主義とはいえ、やはり、手で書く時と、ドキュメントとしてPCで書いて残す時と、使い分けはします。
汎用性のあるドキュメントをつくったり、情報共有のためのテキストなどは、誤解やすれ違いを生まないようにする必要があるからです。

私もすり合わせのためのUIの叩きは手書きしますが、どのようなルールで、どのような方針でUIを作っていくかのUI設計書は、InDesignなどのアプリケーションを用いてドキュメントに残します。

思考の段階では徹底的に検証し、叩き、そしてそのあと、かっちりと作る。
まずもって検証する、という前提が作れるから、手書きが好きなのかもしれません。

「手書きがいいのはわかったから、ちょっと目の前で書いてみてよ!」というかたは、ぜひご用命ください。
なぜこんなに私の手がプロッキーで汚れるのか、実演いたします!

設計力を上げるための社内勉強会

ギルドワークスの佐々木です。
ギルドワークス内部クローズドで、3月より社内有志で社内勉強会を開催しています。
名前は「ちくちく設計鍛錬場」です。
その内容を紹介したいと思います。

何故やってるいのか

ギルドワークスが理念として掲げている「正しいものを正しくつくる」を実践するために実施しています。とりわけ「正しくつくる」の実践を主眼に置き、メンバーの開発力・設計力の強化を目的としています。

何時、誰がやっているのか

ほぼ隔週の平日18時頃より1.5時間程度、ギルドワークスの有志で行なっています。
参加者の中には、私のようにリモートワークのメンバーもいるため、skypeで繋いでいます。

何をどうやってるのか

「ちくちく」読むということ

エリック・エヴァンスのドメイン駆動設計を「ちくちく」読んでいます。
DDD

ちくちく」読む、とはどういうことか…こういうことになります。

  • 第一回:本書まえがきの3段落の前半読み合わせ(0.5ページ分)
  • 第二回:本書まえがきの3段落の後半+本書の構成+対象読者の読み合わせ、第一部まえがきの概略(4ページ分)
  • 第三回:第一部まえがきの前半2段落の要約(0.5ページ分)
  • 第四回:第一部まえがきの後半3段落の要約(0.5ページ分)
  • 第五回:第一部まえがき2節の要約(3ページ分)
  • 第六回:第一部まえがき2節の要約やり直し(3ページ分)

なんと、6回もやって、まだ11.5ページしか読んでいません。しかもまえがき部分です。

輪講形式

雰囲気としては大学の「輪講」に近いです。
輪講では、代表者が論文やテキストを選んで要約し、ゼミ生みんなでツッコミを入れ、意見を出しつつ、読み合わせます。
本勉強会では、事前課題として要約すべき箇所が指定され、それを参加者がそれぞれ要約してきます。
事前課題の出題者は、ドメイン駆動設計の実践者である増田氏です。
そのそれぞれの要約をベースに、勉強会で意見を出し合います。

要約

要約は「40文字」といった字数制限があり、国語のお勉強です。
(どこが国語のお勉強?と思った方は、「100字要約ドリル」で検索していただくと分かると思います。)

何気なく言葉に出した「要約」は、ドメイン駆動設計を実践する上でとても重要です。
メタですが、本勉強会で要約することは、モデリングスキルを磨いていくことにも繋がっています。
要約はとてもむずかしく、言葉の筋トレといった様相です。

何を学んだか

ここまで読んで分かったことを簡単に述べたいと思います。

まず、ドメイン駆動設計はオブジェクト指向に大きな影響を受けているということでした。
オブジェクト指向以外のパラダイムで捉え直す試みも大事だと思います。
ただし、ドメイン駆動設計の根底には、モデル駆動やオブジェクト指向で産み出された数々の概念やプラクティスを、異なる視点でまとめ直したものであることを踏まえる必要があると考えます。

また、「開発者」に求められるものの大きさを感じました。
開発者という言葉は、スキルや考え方でかなり幅がある言葉だと思います。
しかし、ドメイン駆動設計で言われている開発者は、ユーザー・顧客のドメインを理解し、モデリング技術を研ぎ澄ます必要があります。
とても求められるものは大きく、だからこそ、面白い世界なのだと感じています。

まとめ

今回は、ギルドワークスの正しくつくる活動の一環として、社内勉強会の様子についてご紹介しました。

本勉強会自体はクローズドですが、ギルドワークスが主催する勉強会として、違う形でドメイン駆動設計に関する勉強会を開催したいと思っています。
その際は、こちらのブログでも改めてお知らせしたいと思います。

もし、ギルドワークスにご興味が湧きましたら、お気軽にご相談ください。(お問い合わせ