翠灯舎 | Suitosha Inc. 翠灯舎 Suitosha Inc.

News|新着情報

【UX中級編・ワークショップ後編レポ】体験プロトタイピングを学びました

2016.5.12

株式会社おいかぜさんとの合同主催のUX勉強会、
UX中級編ワークショップ「行動シナリオ法・プロトタイピングを活用したサービス開発」(全3回)。
4/23(土)はその最後を締めくくる後編の開催日でした。

今回はその日の様子をレポートします。

後編のテーマは「体験プロトタイピング」。
前編ではシナリオやサービス概要を、
そして中編ではストーリーボード、ワイヤーフレームを作りましたが、
後編ではそれらを移植したプロトタイピングツール「Prott」を実際に使いながら、
サービスサファリを実施。

チームで外出し、自分たちがユーザーになって実際にサービスを体験してみながら、
「このサービスってどうなの?」ということをいろいろな側面から評価します。
そこで得た気づきをもとに、帰ってからサービスをさらにブラッシュアップして、
最後には各チームのプレゼン。

…という、朝から夕方までの、1日みっちりフル稼働コース。

DSC05936
天気も良く、絶好のサービスサファリ日和です。

DSC05919
Prottに移植すると、こんな感じで手書きのワイヤーフレームがスマートフォン上に表れます。
タップするとちゃんとページ遷移もできるすぐれもの。
こちらを携えて、各チーム外に出かけます。

DSC05934
弊社の田中のチームは出町柳方面へ。
サービス内容に「釣り」というキーワードがあるので、
シチュエーションの近い鴨川へ向かうそうです。

DSC05951
チーム内では、
・被験者(ユーザーになりきってサービスを使う人)
・ディレクター(調査の全体を指揮する人)
・観察者(被験者の言動を記録する人)
に分かれてサービスサファリを実施。

被験者は思ったことをひたすら口に出し続ける「発話法」を行います。
「こういうときってどうしたらいいんやろな〜」とか
「これってどっからログインするんやろな〜」とか
「使いにくいな〜このアプリ〜」とか
とにかく何でもいいので思ったことをどんどん口に出していきます。
そしてそれを観察者がひたすらメモ。
キリの良いところでディレクターがミーティングを入れ、
課題点を整理してアイデアを出し合う。
そんな、チームワークが求められる作業です。

DSC05956
合間にごはんも入れつつ、ミーティングは続きます。

DSC05961
会場に帰ってきてからは、問題点を整理し、改善案を出し、
シナリオやワイヤーフレームを直していきます。

_DSC7956
さらにプレゼン資料も作るので大忙し!
こちらは時間が全然足りなくて、ちょっと放心気味の野田です。

_DSC8002 (1)
ついにプレゼンが始まりました。
今回のプレゼンで用いたのは、「オズの魔法使い」という手法。
ユーザーとして演技をする人と、背後でインターフェイスを操作する人に分かれて、
「サービスを使うシーン」のお芝居をします。
弊社の代表・田中も女優魂を見せています。

_DSC8130
皆さん、役者ですね!

_DSC8088
各チームのプレゼン後には、講師の浅野先生による講評。
「それって本当にユーザーが必要としていることなの?」
「それでどうやって儲けるつもりなの?」
と、びしばし厳しいツッコミが。

ユーザーの求める本質×ビジネスとして儲かる仕組みが、
サービスの肝なんですね。

それが頭でわかっていても、なかなかできない…!!

ということを、しみじみ痛感した1日でした。その痛感も実りです。

_DSC8025
各チーム、アイデアいっぱいの楽しいプレゼンでした。
皆さん、お疲れ様でした!

この日をもって、全3日間のUX中級編ワークショップ、無事終了いたしました。
ひとえに、浅野先生、アシスタントの皆様、会場のMTRL KYOTO様、
そして受講生の皆様のおかげでございます。
拙い運営にも関わらず温かく見守っていただき、本当にありがとうございました!

受講生としてはもちろん、運営スタッフとしても非常に勉強になる3日間でした。
今後もUX KYOTOとして、おいかぜさんと共にいろいろと計画中ですので、
またこちらでアナウンスしてまいります。
よかったらチェックしてくださいませ。

おいかぜの柴田さん、蔵多さんも本当にお疲れ様でした!

今後こちらで学んだことを実務に反映していきたいと
切に願っている野田でございました。

こちらでもレポートあがっておりますので、合わせてどうぞ!
■UX KYOTOブログ
<レポート>中級編ワークショップ後編「体験プロトタイピング」を開催しました!

■浅野先生ブログ
UX京都中級編#03体験プロトタイピング

■おいかぜさんブログ
【UX勉強会レポート】体験プロトタイピングを学びました

【PMヘの道3】「プロジェクト計画書」とは?@WebPM体験共有会

2016.4.15

プロジェクトが発生した時、どんなふうに計画を立てますか?

今回は、プロジェクトの「計画」部分についてです。

プロジェクトが発生したらまず出てくる「計画」。
しかし、「計画」ってそもそもどうやって立てるのがいいのでしょうか?

私はこのあいだまで、まずプロジェクト概要とスケジュールを用意していました。
しかし、その内容がすべて自己流でどうも心もとない。
そもそもプロジェクト「概要」って何の項目が必要で不要なの?
「概要」+「スケジュール」=「計画」と言っていいの?と手探り状態。

いや、そもそものそもそも、「計画」って誰のために、何のために立てるのか。
自社チームでの共有のため?クライアントとの合意のため?

と、何だか闇雲に立てられてる感がすごい私の「計画」…。

プロジェクトをマネジメントするのが専門の世のプロマネさんたちは、
どんな計画書を作っているんだろう?といつも気になっておりました。

3月15日に、OPEN “VERSION UP” PROJECTの一環として行われた、
2回目の「WebPM体験共有会@大阪」のテーマはまさにそれ。
ロフトワーク・入谷さんの「プロジェクト計画書」編!

年間約300件のWEBプロジェクトを担うロフトワークさん。
まさにPMのプロである彼らが日常業務で使っている
「プロジェクト計画書」とはどんなものなのでしょうか?

ロフトワークさんの「プロジェクトマネジメント計画書」

ロフトワークさんではWEBプロジェクトが発生した際、
必ず最序盤に「プロジェクトマネジメント計画書」(以下PM計画書)を作成されるとのこと。
さらにその計画書をシニアマネージャーが確認し、レビューを受けることが必須とされているのだそうです。
社内でもそのひな形はしばしばアップデートされ、試行錯誤を重ねていらっしゃるのだとか。

入谷さんいわく、「PM計画書」とは

“スコープ・スケジュール・コストなどすべての知識エリアを横断した、
プロジェクト計画の「集大成」であると同時に、プロジェクトを通じて
「更新」されていく共通理解の基盤”

ということ。
つまり、
・様々な視座からプロジェクトを見ること
・みんなで共通の理解を得ること
を目的とした計画書です。

入谷さんのスライドはこちらから見ることができますのでぜひどうぞ。

以下は、復習的にまとめた私のメモです。
今回もずらずら文字ばかり並んでおりますが、何かのご参考になれば。
———————————–
【フォーマット】
WordでもGoogleDocs.でも、管理しやすいものを使えばOK。

【目次】
PM計画書は、以下の9つの項目で成り立っている。

統合
 プロジェクト発生の背景・目的・目標。
 背景…なぜこのプロジェクトが生まれたか。課題。
 目的…最終的に達成したいものは何か。
 目標…目的到達のための具体的な目安(数値目標)。

スコープ
 作業範囲のこと。
 納品する成果物と、そのための作業内容を挙げる。
 逆に、やらないことも明記しておくとなお良し。
 クライアント側の作業内容もリストアップする。
 →これが見積の基礎になる。

タイム
 スケジュール。
 スコープで明確にした作業内容を時系列に落とし込む。

調達
 外から調達しなくてはいけないもの。
 例えば、外部業者さん、素材、サーバー、ドメイン、ライセンスなどなど。

コスト
 プロジェクトにかかる費用を洗い出します。
 
品質
 成果物の品質(完成度)と、それを達成するための手法。
 例えば、バグをなくすためにどのような方法でテストするのか、
 質の高いデザインを担保するために何をするのかなど。
 また、ここまではやります、というのもここで明示。例えば対応ブラウザとか。
 
ステークホルダー
 チーム、クライアントなど、関係者をすべて洗い出した体制図。
 誰が窓口で、誰がリーダーで、誰が決定権を持っている人なのか?など、
 各人の役割と責任を明確にする。

コミュニケーション
 ステークホルダー同士でのコミュニケーションルール。
 プロジェクトの管理ツールは何を使う?
 定期的に対面での打ち合わせをする?
 意思決定で困ったらどういうふうに決める?などなど。

リスク
 「起こったら嫌なこと」のリストアップ。
 スケジュールの遅延、途中での予算オーバー、公開時にバグがいっぱいある…
 などなど、「起こったらやだな〜」ということをリストアップし、
 ではそれが起こらないようにするにはどうしたらいいか?を考える。
———————————–

そもそも「PM計画書」は誰のために、何のためにあるのか

今回の体験共有会でおもしろいなと思ったのは、
そもそも「PM計画書」との存在理由とは?という話が改めて出たことでした。

・チームメンバー、クライアントとの計画共有
・解釈のすりあわせ
・プロジェクト合意
・コミュニケーションの惹き付けツール
・社内での先輩・後輩の仕事チェックツール
・プロジェクト遂行プロセスの一環

私は面倒臭がりなので、上記の全部がこれひとつでできたらいいと思います。

真似して「PM計画書」を作った感想

ちなみにこちらが入谷さんが用意されたひな形です。
勉強になるな〜!ということで、
私も見よう見まねで実際に「PM計画書」を作りました。

素直な感想を申し上げますと、
「これ、絶対要る」
でした。

特にスコープは、入谷さんのひな型を見て
「これまで私の作ってたのは大雑把すぎたな」と反省しました。
マスト作業から何となくやっていたことまで、
とにかく作業と呼ばれるものすべて文字に起こしたら、
見積の見方やスケジュールの組み方も全部変わってきました。
また、お客様の作業内容も明確にすることで、
「あれって私がやるんだっけ?」もなくせるので効率的。

まずはこちらを使用しながら、ひとつプロジェクトを遂行して、
反省会をしてみたいと思います。

あとこの「PM計画書」って何にでも使えそうですね。
ダイエットとか貯金とか受験とか…
ちょっと今度私生活でも作ってみようなどと思う野田でした。

ではでは。

【UX中級編ワークショップ中編レポ】ペーパープロトタイピングを学びました

2016.4.7

株式会社おいかぜさんとの合同主催のUX勉強会、
UX中級編ワークショップ「構造化シナリオ法・プロトタイピングを活用したサービス開発」。
4/2(土)に、その第2回目が開催されました。

今回のテーマは「ペーパープロトタイピング」。
前回作ったシナリオやサービス概要を、どんどん目に見える形に変換していきます。

_DSC6877
会場はMTRL KYOTOさんの2階。
2階はこんな感じで和室になっているのです。
みんなでちゃぶ台を囲んでワークショップスタート!

_DSC6915

まずはストーリーボードなるものをどんどん作っていきます。
ユーザーの観点から、「どんなときにサービスに触れるのか(タッチポイント)」を見いだし、
タッチポイント1つ1つを絵コンテと簡単なテキストで表現していきます。

_DSC6904
とにかく描いて描いて描きまくる私たち。

このとき注意するのは「できるだけスマホやPCで検索しているところ」というような姿は描かないこと。
どんなふうに感じ、どんなことを考え、どんなふうに行動をとろうとしているのか、
「検索」と一言で片付けるのではなく、より本質に近づいた「ストーリー」に落とし込みます

私達のチームでは、この時点で「このサービスいけてんのかなあ」というもやもやがありました。

ユーザーが求めているものって結局何なのかな?
これ何回も使ってもらえるのかな?
本当に儲かるのかな?

こうしてストーリーボードにしてみると、どうも納得がいかない…

そこで浅野先生がおっしゃったのが、
「ユーザーは便利を求めているのではなく、成長を求めている」
という言葉。

その言葉がヒントになり、どんどんサービスが変容しシンプルになっていきました。
それにともない、ストーリーボードもどんどん変化。
それがとってもおもしろかったです。

_DSC6928
次は、ワイヤーフレームの作成。
こちらももちろん紙に描いていきます。

前編で作ったインタラクションシナリオをもとに、情報を整理し画面上に設計。

「なるほどー」と思ったのは、TOPにあれがあって、下層にこれがあって〜というように
構造をまず考えるのではなくて、ユーザーの行動からワイヤーフレームを描いていくということ。
だから、ストーリーボード1枚に対してワイヤーフレーム1枚が生まれます。

つまり、ストーリーからワイヤーフレームは生まれるのです。

普段は
「全体の構造(サイトマップ)がどうなっているか」
→「それをユーザーがどう使うか」
の順で考えていたので、これは目から鱗でした。

あと個人的に、いつもPC上でワイヤーフレームを作っているので、
手でワイヤーフレームを描くのがすごく難しかったです。
メンバーの方がさくさく描いてくださったので本当に助かった…。

_DSC6931
ワイヤーフレームが描けたら、今度はどんどん切る!

_DSC6939
切って切って切りまくり、
ワイヤーフレームを1枚ずつばらばらにします。

_DSC7007
切ったら並べます。これが遷移図
ストーリーボード(コト)が、ワイヤーフレーム遷移図(モノ)に変換されていきます。

_DSC7025
遷移図ができたら、ユーザーとして実際に使ってみます。
「あのボタンが足りない!」「この機能じゃま!」などとどんどんブラッシュアップしていきます。

_DSC7042
それができたら次はプロトタイピングツール「Prott」への移植。
描いたワイヤーフレームを写真に撮ってこのProttに取り込むと、
手書きのワイヤーフレームにリンクが張れたりクリックして動かしたりできるという
何とも画期的なサービス。これはすごい。

_DSC7083
PCに取り込むとこういう感じですね。
「何だこれむちゃくちゃ便利だなー」と思いました。

中編はここまで!
今回は「コト」を実際に「モノ」にしていく作業でした。

最後の後編は4/23(土)、テーマは「体験プロトタイピング」です。
作った「モノ」を体験してもらう、ということでしょうか??
何はともあれ、各チームからどんなものができあがるのがとても楽しみです。

ご参加された皆様、2日目もどうもありがとうございました。
あと1日、どうぞよろしくお願いいたします!

野田

Photo by  YUMI KURATA

GW休業のお知らせ

2016.4.5

今年もゴールデンウィークの季節がやってまいりました。
弊社では下記の通り休業日をとらせていただきます。
どうぞよろしくお願いいたします。

〈休業日〉
4/29(金)〜5/1(日)
5/3(火)〜8(日)
※5/2(月)は通常通り営業しております。

メールでのお問い合わせへのお返事は営業日内での対応となります。
お客様にはご不便をおかけいたしますが、何卒ご了承頂けますよう宜しくお願い申し上げます。

それでは皆様、素敵なゴールデンウィークをお過ごしください!

野田

【PMへの道2】体験共有会で学んだPMの「仕組み化」

2016.3.16

こんにちは、野田です。
昨日より始まりました連載、「PMへの道」。
こちらでは翠灯舎のディレクター野田が、
プロジェクトマネジメント(略してPM)を
楽しく学ぶ様子を書き綴っていきたいと思います。

さて、2月8日に、OPEN “VERSION UP” PROJECTの一環として
「WebPM体験共有会@大阪」が行われました。

ひとりの話し手によるショートプレゼン&公開インタビュー形式で、
Webに関わるプロジェクトマネージャー同士で経験を共有するこの会。

マニュアルのないプロジェクトマネジメントという仕事を、
他の会社のみんなはどんなふうに普段行っているだろう?
と日々気になっていたので、意気揚々と私も梅田まで出かけてまいりました。

今回の話し手は、マーケティングプロデューサー・Mharuさん。
メインテーマは『コミュニケーションマネジメント』です。
Mharuさんいわく、
問題の9割はコミュニケーションのズレが原因で起きている
とのこと。
そのほとんどはカリスマ性や人情などではなく、『仕組み』で解決できる
ということでした。

当日は私が聞き手となり、インタビューをさせていただきました。
仕事を円滑に進めるための、Mharuさんの『仕組み』とはどんなものなのでしょう?
いろいろ聞きたいことがあったので、前もって全部質問を投げさせていただいたのですが、
当日Mharuさんが準備万端状態でお応えくださったので、大変大変勉強になりました。
Mharuさんありがとうございました!

詳しくは、Mharuさんが後日挙げてくださったスライドでどうぞ。
>>>『プロジェクトマネジメントは仕組み化が9割』

本ブログでは、野田が特に大事だなあと思ったことを
復習的にまとめていこうと思います。
今回聞き手としてインタビューするのに必死でまったく写真撮ってません。
ずらずら文字ばかり並んでいますが良かったらお読みください。

1)話し手のMharuさんについて

Mharuさんの経歴はこんな感じです。

・大手SIerで、SEとして大規模な基幹システムの設計・開発・運用に従事。

・Webベンチャー企業に転職後、Webサイトや構築・システム開発を担当。
 →その後、ディレクター・プロジェクトマネージャーを経てマーケターに。

・【現在】企業のマーケティング活動を支援する、マーケティングプロデューサーとして活躍中。

もともとは現場でごりごりに手を動かす立場にいらしたMharuさん。
年月とともに、進行管理・仕組み作りをする立場へと変わっていかれました。

そんなMharuさんのプレゼンタイトルは
『プロジェクトマネジメントは仕組み化が9割』。

「僕は面倒くさがりなので、何でも仕組みにしたがるんです。
一回仕組みにしてしまえば、後々ラクですから。
何か問題が起こるたび、今後それを繰り返さない「仕組み」を考え、
すぐに取り入れて実践するようにしています」
とのことでした。

2)「グループ」と「チーム」の違い

まずは「グループ」と「チーム」の違いについてきちんと理解する、
ということからお話が始まりました。

「グループ」とは、共通の性質で分類した一団のこと。
例えば、“営業”、“デザイナー”、“コーダー”などで分類したときの群のことです。
こちらは個々のメンバーの力が足し算されて成果に繋がります。

一方「チーム」は、共通の目的のために協力して行動する集団のこと
同じ目的を果たすために、各役割を担った人がひとところに集まった状態、
という感じでしょうか。
こちらは個々のメンバーの力が掛け算されて成果に繋がります

PMはこの「チーム」をきちんと動かしていくことが大事。
そのためにも、
・チームの目標
・メンバーの役割と責任範囲
・評価基準
この3つの明確化が必要であるということでした。

つまりこれ、チーム内部の仕組み化です。
実際人が集まると、すぐにプロジェクトに向き合ってしまいがちですが、
まずは内部できちんと体制を整えて仕組みを作ってから、
プロジェクトに取り組むという流れが大切なんですね。

そうしないと、いったいどこに向かい、何のために頑張っているのかわからなくなる。
誰が何を担い、どのように動いたら評価・成果に繋がるのかわからなくなる。
チームの力を健全に掛け算するためにも、まずは内部から整えること。

また、Mharuさんは「問題を言い合える」関係を築くことを大事にされていました。
意識的にチーム内の人をランチに誘ったり、飲み会を設定したりしながら、
普段思っていることを聞き出したりしているそうです。

3)Mharuさんのプロジェクトマネジメント7つ道具

個人的にはこちらが一番興味深い内容でした。
複数案件を抱えていると、「あれってどうなってたっけ?」
ということが起きてしまいがち。
それを防ぐためにもしっかりドキュメント化するのが大事。
Mharuさんは普段、以下の7つの資料を作っているとのことでした。

1. 体制図
プロジェクトに関わるメンバーを明確にし共有するための図。
・社内メンバー&外注先メンバー…誰が何を担当するかの明確化。
・お客様側の体制図…窓口、承認、決済など、キーパーソンの明確化。

2. ガントチャート
チーム内&お客様側のタスクの洗い出しと、それをスケジューリングしたもの。
定期的に確認・見直しをしながら、全体スケジュールを俯瞰する。

3. 施策マップ
お客様のビジネスモデル・施策を把握するマップ。
どんなチャネルを持っていて、どこで収益を上げているのかを一枚のマップに落とし込む。
それをもとに課題を見つけ出し、新しい提案をする。

4. 業務フロー図
リリースにいたるまでの業務の流れを見える化したもの。
おおまかな「やること」&「やる人」リストといった感じ。
お客様のチェックがどの時点で入るのかも明記しておくと◎。

5. 障害発生時のレポートライン
名前の通リ、何かあったときのための連絡網。
誰に何をいちばんに伝えるのか、担当者が不在の場合どうするのかなども
併記しておくことがポイント。

6. 予実管理表
チーム内での、売上・粗利率・予実乖離率を算出した表。
見積の金額で本当に良かったのか?
もし見積もっていた工数よりも実績工数が大幅にオーバーしていた場合、
何が原因だったのか?
次に活かして負担を少なくするために作るもの。

7. 振り返りシート
案件終了後にメンバー全員で振り返るときに使うシート。
続けたいこと、問題点、今後やりたいこと、
この3つを軸に反省会をする。
同じミスを繰り返さず、次回からの生産性を上げるため。
おそらくここで仕組み化の種が見つかるはず。

以上の7つがMharuさんの必須道具。
ぜ、全部ものすごく要るものだ!!と思ったので、
私もぜひ取り入れようと思います。

4)成果物に対するチェック基準

あととても気になっていたのが、できたものに対して
どのように「OK!これで納品だ!」とGOを出しているのか?ということ。

たとえばデザイナーがあげてきてくれたデザインに対し、
デザイナーではなプロマネがどういうふうに「OK」か「やり直し」かを
判断するのかなと疑問に思っておりました。

その質問に対し、Mharuさんは簡潔に
「論理的に矛盾していないかどうか」
で判断すると答えてくださいました。

そのデザイン、お客様の要望を満たしている?
ユーザーにとって使いやすい?
コンセプトとずれていない?
前やった失敗もっかいやってない?

好きとか嫌いとかではなく、ただただ論理的に判断する。
そうすることで、デザイナーにも的確な指示が出せるし、
お客様にも自信をもって説明できるということでした。

5)まとめ

プロマネをする上で、気をつけていることをいろいろうかがいましたが、
総じて言えるのは
仕事はひとりでするものじゃないということを理解する
ということだったと思います。

強みも、考え方も、価値観も異なる人間同士が集まったチームだからこそ、
みんなが使える、理解できる仕組みが大事。

みんなが気持ちよく働けるように、各人が最大限パワーを出せるように、
環境を整えてあげることがプロマネの仕事なんだなあと思いました。

余談ですがMharuさんはほぼ残業をしないそうです。
定時であがったあとは、書店で仕事に役立つ本を探して読むのが日課なのだとか。
まさにご自分の生活をマネジメントされているなあ…と見習いたい気持ちでいっぱいです。

おすすめされていた本、
『大工の棟梁に学ぶプロジェクトマネジメント』
『今いるメンバーで「大金星」を挙げるチームの法則』
も読んでみようと思います。

Mharuさんありがとうございました!

野田

Offer to Us

to Top Page

Contact

Contact