https://www.flickr.com/photos/drachmann/327122302/

プロジェクトを始める際に問うべき6つの項目

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

先日、関係者とともにMVPアワードの一次選考の最終検討を行っていました。はじめてのアワードに関わらず、多数の応募を頂きました。興味深い切り口の課題を扱ったもの、すでに仮説の検証が終わっているもの、充実したMVP、少し変わった技術の活用、多種多様な内容でした。ご応募頂きありがとうございました。

今回のアワードでは、アイデアを説明する道具の一例としてリーンキャンバスを挙げ、多くの皆さんに書いて頂きました。リーンキャンバスとは「Running Lean」という書籍で紹介されている、検証すべき仮説を整理するための一枚絵です。ビジネスモデルキャンバスの流れを組んでおり、より仮説を練ることに適したキャンバスのため、ギルドワークスでもちょっとアイデアが浮かんだら、キャンバスを書くという使い方をしています。一枚で内容がまとまるため、仮説を誰かに伝える際にも分量が多くなりすぎることがなく、読み手にとっても負担が少なく、重宝します。そのような点で、今回のアワードでも皆さんに書いて頂くことを推奨致しました。

こうしたサービスの仮説を考える際に役に立つキャンバスですが、クライアントワークでも一部を用いることがあります。プロジェクトやプロジェクトの期間を越えて、「お客様に何ができるのか」「お客様とどうありたいのか」という考えを整理することにも、有効です。

①顧客 => 今回のプロジェクトのお客様。どのような状況にあるのか。

②課題 => お客様の課題は何か。今回のプロジェクトでは何を解決したいのか。

③価値提案 => ギルドワークスとして何が提供できるのか。どういった点で値打ちを出せるのか。

④ソリューション => 値打ちを出すために具体的に提供する手段は何か。

⑤圧倒的優位性 => 他ならぬ自分たちが関与することの(お客様にとっての)メリットとは何か。

⑥主要な評価指標 => どのような点を達成すれば今回の目的を果たせそうか

たった6つの項目ですが、強力です。現状分かっていることを可視化することはそれほど時間がかからないと思います。書き出してみて、もし書き出せないところ、しっくりこないところが出てきたら、これから何を考えるべきか、何をやるべきか自ずと見えてくる次第です。

最後に、MVPアワードですが6月中旬には最終結果を出す予定です。その後、表彰結果について公開致します。今後もMVPアワードは開催していく予定ですので、その折には皆様のご応募をお待ちしたいと思います。

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

GuildWorks Inc.
img

鉛筆とラフスケッチと私

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

とあるウェブ開発のデザイン制作で、ラフスケッチを描いたり、ビジュアルイメージをかためるのに、このところずっと鉛筆を使っています。
このクライアント様は、自社のブランディングをとても大切にされているので、思いを反映したビジュアルデザインのために、まず手書きの、鉛筆を使ったスケッチ画を作成して、それを元にして意見交換し、お互いのイメージしているもののすり合わせを行っています。
デザインワークの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などのアプリケーションを用いてドキュメントに残します。

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

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

DDD

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

ギルドワークスの佐々木です。
ギルドワークス内部クローズドで、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字要約ドリル」で検索していただくと分かると思います。)

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

何を学んだか

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

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

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

まとめ

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

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

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