IMG_1721_1

少しだけ論理的に本を読んでみよう

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

技術書を読むという習慣はみなさん持っていると思います。
技術書を消化しようと思った時、みなさんはどのようにされているでしょうか?
写経をしたり、議論をしたり色々な方法があるかと思います。

今回はもう一つの選択肢として、「少し論理的に読んでみる」という方法を紹介したいと思います。

と言っても、それほど難しいわけではなく、

① 主題はなにか?(何について書かれているか?)
② 問題はなにか?(何が問われているのか?)
③ 主張はなにか?(どう答えるのか?)
④ 根拠はなにか?
について考えながら読むだけです。

たとえば、ドメイン駆動設計本のコアドメインなら、

主題(何について)
巨大なシステムのドメインについて。

問題(何が問われ)
巨大なシステムは複雑なので、ビジネス資産がどこだかわからない。ドメインの全体像が見えづらい。設計が理解しにくいときに起きる問題と同じことがおきる。その解決策。

主張(どう答えるのか)
モデルの重要なコアを洗練する。

根拠
設計はすべての部分が等しく改良されるわけではないから、その中でもコアを洗練することによって、最も価値のある特化した概念を浮き彫りにする。

と考えることで要約もできて、理解も進みやすくなり、議論の元にすることもできるのではと思います。

また、ソフトウェアの設計というのが、ビジネスモデルの要約だと考えるならばこのような練習が設計のスキルアップに役に立つのではないかと、個人的に思っています。

そして、もっと論理的な考え方を身につけたいと思う方にお勧めの本が「新版 論理トレーニング(野矢茂樹 著)」です。

この本の例題を引用してみます。

タコは8本足である。
ジョロウグモはタコではない。
だから、ジョロウグモは8本足ではない。

どうでしょうか。何か違うのがすぐわかりますよね。

では、これはどうでしょうか?

思考は閃きを必要とする。
頭のよい人は閃きを得る力に恵まれている。
つまり、頭のよい人は思考力もある。

ぱっと読むと正しそうに見えませんか?
どこがおかしいか、ぜひ考えてみてください。

上記の例は「新版 論理トレーニング」の中の例題ですが、実際のWebや新聞の記事なんかでも論理的におかしいと気づくことがあります。

考えながら本を読むのは大変疲れますが、技術書のみならず、いろいろなジャンルの本やWEBの記事を読む際などにもきっと役に立つと思います。

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

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

井上です。 以前、本ブログでドメイン駆動設計(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への理解を深めるために有用そうな内容になっているので、少しづつ読み進めていきたいと思います。 興味のある方は手に取ってみてはいかがでしょうか?(個人的には日本語訳されることを期待しています)

2434031231_e11977262b_z

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

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

ソフトウェアを実利用者の文脈に沿ったものとして届けるために、利用者を知ることが大切であると言われます。
利用者を知るといった場合に、インタビューや行動観察をしてユーザーデータを集めることはとても重要ですが、その結果を分析しなければ、意味のないデータになってしまいます。
今回の記事ではまず、人間中心デザイン(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 より引用しました。)

カタカナ英語に逃げずに本質を捉えよう

こんばんは、前川@Posauneです。

ギルドワークスでは最近、カタカナ英語禁止令、とまでは言いませんが、あまり乱発しないように注意することが多くなっています。馴染みがないカタカナ英語で逃げようとすると「それは何?」と厳しい指摘が飛んできます。 それは、カタカナ英語によって生じる「なんとなく分かった気分」というのが非常に危険だからです。
続きを読む

Coderetreatを題材にした設計本

井上です。

Coderetreat (*1)というイベントをご存知でしょうか?
Coderetreat とは、ソフトウェア開発と設計の基本を学ぶためのイベントで、以下のような特徴があります。

  • 一日掛かりで行われる(5〜6セッション)
  • 参加者はペアでコードを書く(ペアプログラミング)
  • 1セッションは45分間
  • ライフゲーム (*2)」を題材とする
  • 各セッション終了後にコードを削除する
  • 各セッションで新しいペアを組む
  • セッションが進むにつれて制約を課す

また、CodeRetreatを世界中で同日に開催する 「Global Day of Coderetreat」 というものもあり、世界中で活発に開催されているイベントで、日本でも度々開催されています。(*3)
私もCodeRetreatに参加したことがあるのですが、一日掛かりのイベントなので大変な集中力を要しますが、とても勉強になりました。

そんな Coderetreat を題材にした設計本(洋書)を見つけたので紹介します。

続きを読む

ドメイン駆動設計のリファレンス本

井上です。

現在、ドメイン駆動設計(Domain Driven Desing . 以下 DDD)を用いて開発を行っています。

DDDの参考書籍といえば、もちろん「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本)ですが、その著者であるエリック・エヴァンスが最近(2014/9/22)「Domain-Driven Design Reference: Definitions and Pattern Summaries」という新しい本(以下 DDDリファレンス本)を出していることに気がつきました。

DDDリファレンス本とは

早速DDDリファレンス本を取り寄せてみました。88ページと非常にコンパクトな本になっています。

続きを読む