Submit Search
クライアントの要望にこたえるWebサービス開発 ~「らせん型ワークフロー」のススメ~
•
319 likes
•
34,315 views
Mayuko Sekiya
Follow
2012年8月26日に行われた、CSS Nite in SAPPORO, Vol.5 での発表資料です。
Read less
Read more
1 of 130
Download now
Downloaded 473 times
More Related Content
クライアントの要望にこたえるWebサービス開発 ~「らせん型ワークフロー」のススメ~
1.
クライアントの要望にこたえるWebサービス開発 らせん型ワークフロー
のススメ CSS Nite in Sapporo Vol.5 Sun 26th, Aug, 2012 SEKIYA MAYUKO
2.
About me SEKIYA
MAYUKO
3.
About me
10年くらい Webデザイナーです。 SEKIYA MAYUKO
4.
昨年転職し、3人のプログラマーといっしょに
働いています
5.
今は Ruby on Rails による制作が中心です
6.
私たちが携わっている案件: ・デザインもプログラムも Webサービス全体として
請け負うことが多い ・長期間にわたる継続的な プロジェクトが多い ・道外など遠方の取引先が多い
7.
私たち流 らせん型ワークフロー のよいところについてお話しします
8.
今日のお話
お客様のご満足に近づけるように、 1 私たちがらせん型ワークフローで していること Webデザイナーとして 2 らせん型ワークフローに 参加していく心得
9.
よくある開発フロー:
要求分析 ワイヤーフレーム提出 実制作 デモ・納品
10.
よくある開発フロー:
要求分析 ワイヤーフレーム提出 実制作 デモの結果がイマイチだった... デモ・納品
11.
よくある開発フロー:
要求分析 ワイヤーフレーム提出 納期を延期できないと、 実制作 もう修正できない... ><; デモ・納品
12.
要望どおりに作成したはずなのに
どうして...
13.
時間が経つと、 欲しいものだって変わる... 実際に動く画面をみると、 想像とは違った... もっと良いアプローチを思いついてしまった...
14.
受け入れよう! 仕様
や 要望 って 変わっていくもの
15.
じゃあ、 どうしたらよいのか
16.
まとめて 作りすぎない!
17.
少しずつ
作って 少しずつ フィードバックをもらう
18.
戻れないフローはやめて 繰り返すサイクルにする
19.
よくある開発フロー:
要求分析 ワイヤーフレーム提出 実制作 デモ・納品
20.
らせん型に作ると...
21.
らせん型:
要求分析 ワイヤーフレーム提出 実制作 レビュー 納品
22.
らせん型:
要求分析 フィード ワイヤーフレーム提出 バック 実制作 レビュー 納品
23.
らせん型:
フィードバックに基づき フィード 改修を重ねることで バック 実制作 レビュー お客様の満足に近づける!
24.
1
私たちがらせん型ワークフローで 具体的にどんなことを しているか
25.
①お客様の要求を深く理解するために ②プロジェクトが死なないように ③変わりゆく要望に対応し続けるために
26.
①
お客様の要求を深く理解するために 私たちは ユーザーストーリーを書く
27.
お客様の要求を 深く理解するには どうしたらよいか
28.
要求を ユーザーストーリーに 書き起こすとどうでしょう?
29.
ユーザーストーリーとは...
30.
ユーザーストーリーとは... ペルソナを主語とした 「誰として何々したい(および、その理由)」 という短い文章で、 要求を小さいフィーチャー単位で カードに記述していきます。
「アジャイル・ユーザビリティ」より引用
31.
例えば 要求はこんなふうに変わる...
32.
既存のWebサービスに追加要求がきました
Webサイトにニュースの ヘッドラインを 表示してください! お客様
33.
追加要求に対応しました
サイトトップに ヘッドラインを 表示しました! 制作者
34.
しばらくすると、変更要求がきました
やっぱり、ヘッドライン はいらないので、RSSを 表示してください お客様
35.
作り変えることになってしまいました
はい...。 制作者
36.
あなたならどういう タスクにおこしますか?
Webサイトにニュースの ヘッドラインを 表示してください! お客様
37.
どういうタスクに? 「ニュース表示機能の追加」ですか?
「トップページに ヘッドラインを表示する」ですか?
38.
要求を ユーザーストーリーに 書きおこすとこうなります
39.
週に1度程度しかアクセスしないユーザーとして トップページにヘッドラインが表示されてほしい。 なぜなら他のページを巡ってニュースを 確認するのは大変だからだ。
40.
週に1度程度しかアクセスしないユーザーとして トップページにヘッドラインが表示されてほしい。 なぜなら他のページを巡ってニュースを 確認するのは大変だからだ。
41.
[誰のために(役割)]として、 [何を(機能を)]したい。 なぜなら[なぜ(ビジネスの価値)の]ためだ
42.
[誰のために(役割)]として、 [何を(機能を)]したい。 なぜなら[なぜ(ビジネスの価値)の]ためだ ちなみにこの形式を「Connextraフォーマット」といいます
43.
週に1度程度しかアクセスしないユーザーとして トップページにヘッドラインが表示されてほしい。 なぜなら他のページを巡ってニュースを 確認するのは大変だからだ。 「なぜなら」が大切!
44.
「なぜなら」を共有すると ユーザーの要求を
深く理解できる
45.
・どんなユーザーが ・どういう理由で ・何をしたいのか を、知ることが大切!
46.
このフォーマットがあると コミュニケーションしやすい 実際にユーザーストーリーを
書いてみましょう
47.
お題「 CSS
Nite in SAPPORO」についての要望 [誰のために(役割)]として、 [何を(機能を)]したい。 なぜなら[なぜ(ビジネスの価値)の]ためだ 【例】 学生として、学割がほしい、 学生はお金がないけど知識は得たいからだ
48.
休憩中にみかんを出して
下さい! やっぱり、みかんは手が 汚れるので、スイーツを 出してください! お客様
49.
休憩中に何か食べながら
みんなとおしゃべり したいなぁ... お客様
50.
休憩中にみかんを出して
下さい! やっぱり、みかんは手が 汚れるので、スイーツを 出してください! 下位の要求 お客様
51.
休憩中に何か食べながら
みんなとおしゃべり したいなぁ... 上位の要求 お客様
52.
私の経験からすると、 下位の要求は変わることが多いが、 上位の要求は変わらないことが多い
と思う
53.
なので、 ユーザーの上位要求を おさえることは大切
54.
②
プロジェクトが死なないように 私たちは プロジェクトを 見積り続ける
55.
私たちは、 プロジェクトの過程で
何度も見積る ユーザーストーリー単位で みんなで見積る
56.
私たちは、 プロジェクトの過程で
何度も見積る ユーザーストーリー単位で みんなで見積る ここでの「見積り」はお客様に請求する金額の ことではなく、プロジェクトの作業量のこと
57.
何のために
58.
プロジェクトが 無理な方向に進んでしまわないか、 小さなサイクルで何度も確認し合うため
59.
はじめはざっくり見積る ( ) チームの力量がわからないので
ざっくりしか見積れない
60.
見積りを何度もおこなうと、 見積りの精度は高まっていく 自分達がどれくらいの時間で どれくらいの作業ができるか だんだん正確に把握できるようになっていく
61.
みんなで見積る みんなで見積ると... 私は「簡単そう」と思う作業を、 みんなは意外と「時間がかかりそう」 と思っていることに気づくことができる。
62.
お気に入り機能の実装に こんなに時間がかかると 思わなかったー…… というような事態を
少しでも防ぐ
63.
相対的に見積る はじめから、「この作業に何時間かかる」なんて 正確には言えない。 「この作業はあの作業の3倍くらいかかりそう」 という相対値にしておく。
64.
例えば... 「サインインの実装」を「1」とすると、 「お気に入りの実装」は「3」くらいかなあ? 「サインイン」の機能を実装
「いいね」の機能を実装 1 3
65.
ちなみにゲーム形式の相対ポイントによるこの見積りを 「プランニングポーカー」といいます
参考: 「アジャイルな見積りと計画づくり」
66.
専用のカードもあるけど、 私たちはもっと気軽に、せーのっ どん! と 指を出してやっています
67.
チームの力と 要求のボリュームを見積って
プロジェクトを 観測し続けることは大切
68.
③
変わりゆく要望に対応し続けるために 私たちは お客様といっしょに 優先順位を見直す
69.
お客様のやりたいことはたくさんある! 全部できそう?
70.
どれが最もやる価値があって、 どれは後回しにできるか お客様と一緒に考え 優先順位の高いものから
お届けしていきます
71.
お客様といっしょにユーザーストーリーの優先順位を並べ替える
Done Current Backlog Icebox 時間が これは できたら 作成中 1番目に する したい! 2番目は これを したい できれば したい
72.
フィードバックを回収して 新たな要求を追加 優先順位は何度も決め直す
73.
紙で貼ってできる
➜ 遠方のお客様とも ツール を使えば 同じようなことができる
74.
Pivotal Tracker
h t t p s : / / w w w. p i v o t a l t r a c k e r. c o m
75.
Pivotal Tracker ユーザーストーリーや ストーリーポイントを記入
76.
Pivotal Tracker
Webブラウザ上で、 ユーザーストーリーを ドラック&ドロップして 優先順位を管理
77.
Pivotal Tracker ・ポイントによる見積りの管理
・ストーリーの優先順位の管理 ・ストーリー単位でのコミュニケーション ・プロジェクト全体の進行速度の管理 など...
78.
変わりゆく要望に、 応えられるように 優先順位を見直し続ける
ことが大切
79.
優先順位の高いものから 時間のある限り作業し お客様へ価値を
届け続けます
80.
2
Webデザイナーとして らせん型ワークフローに 参加していくには
81.
時間をかけてつくられたワイヤーよ り、インタラクションを試せるWeb サイトの形をしたものを早めにお見せ できるように!
参考: 「包括的なドキュメントより動くソフトウェアを」 アジャイルソフトウェア開発宣言 http://agilemanifesto.org/iso/ja/
82.
① ワイヤーフレーム制作に
時間をかけない
83.
自分にとって一番ラクなやり方で。 ツールを使ってラクするとか。 ちなみにわたしはこれ
➜ SwordSoft Layout
84.
例えばお客様の前で小さめの紙に 1画面に収めるものを書いて、 画面遷移順に大きなテーブルのうえで みんなでいっしょに並べ替えてみる
85.
ワイヤーフレーム制作の時間を短縮できるだけでなく、 一緒に考えてもらうことで、共有が深まる
86.
要望は早い段階でぼんやりとしたものを 出してもらい、いっしょに理想型を固め られるほうが、制作者の側も参加する余 地があってよいのでは?
87.
ワイヤーフレーム制作に 時間をかけないよう工夫する。 試せるインタラクションが大切
88.
② 少しずつ作って フィードバックを取り込む
89.
Webサービスにおける、機能の場合: アカウントを登録できるようにしたい
➜ ユーザー自身がマイページでアカウント情報を編集できるよう になりたい ➜ ➜ マイページにお気に入り登録した記事一覧を表示したい 表示する記事一覧は全てではなく、過去1週間分でよい
90.
Webデザイナーの場合どう? 少しずつ作るって どうやってやるのか
91.
少しずつには 2つのアプローチがある
92.
1.インクリメンタル(漸進的):
「アジャイル・ユーザビリティ」より引用
93.
1.インクリメンタル(漸進的):
「アジャイル・ユーザビリティ」より引用 例えば、Webサイトを1ページずつ完成させる ➜ なかなか後戻りがきかない
94.
2.イテレーティブ(反復的):
「アジャイル・ユーザビリティ」より引用
95.
2.イテレーティブ(反復的):
「アジャイル・ユーザビリティ」より引用 例えば、Webサイトの色だけみてもらって、 輪郭ができてきて...? ボタンがアクションがついてきて...??
96.
2.イテレーティブ(反復的):
「アジャイル・ユーザビリティ」より引用 例えば、Webサイトの色だけみてもらって、 輪郭ができてきて...? ボタンがアクションがついてきて...?? ➜ ちょっと...OKをもらいにくい...
97.
デザインは部品の集まりではない。 だから、最初のデザイン入れの段階では、 ぼんやりした状態でOKをもらうのは
難しい
98.
最初のデザインを入れてから できる範囲でやろう
99.
最初のデザイン入れ以降は、改善の繰り返し。 インタラクションとしてお客様がためせるように ひとつの機能として 完成されている こと
100.
ケーキ美味しいです
参考: 「アジャイルサムライ」
101.
➜➜➜ ケーキが美味しいのは、 縦に食べると一度に いろんなものが 口に入ってくるから。 お客様により実物に近い状態で試してもらうには... 完成されたケーキのスポンジだけお渡しするのではな く、クリームやフルーツもいっしょに縦に積まれた状 態で、小さい一口ずつ渡せるように心がける!
参考: 「アジャイルサムライ」
102.
要求分析をし、試作とレビューを繰り返した結果、 その機能自体要らなかった!と気づくこともある そのときは、 勇気を持って捨てること!
103.
インタラクションを試してもらい、 フィードバックを得るには
縦に美味しい価値を 少しずつ届ける
104.
③
いろんな役割を 担えるようになる
105.
小さな単位で 価値を届け続けるためには チームとして効率的に 作業できなければならない
106.
お互いの役割の 重なり合う部分を増やす
107.
最近、私が感じていること
108.
「Twitter Bootstrap をベースに
デザインをあててほしい」 私の周りでの、 この需要の多さ!
109.
Twitter Bootstrap とは、 簡単にさっと開発をはじめるための フロントエンドフレームワーク
110.
どうして需要が多いのか
111.
2つの理由
112.
程よいデザインが
手に入る エンジニアが手をかけずに簡単なマーク アップで「ある程度いい感じに見える」 ビジュアルを手に入れられる。 お客様のフィードバックを得やすい。
113.
共通ルールがある 複数の開発者同士で、デザインに関する マークアップの共通ルールがある。 早く開発にとりかかれる。
114.
デザイン側でTwitter Bootstrap のCSSを上書きした い場合、ちょっと大変な場面もある。 けれど、
Twitter Bootstrap を使うことを許容できた らいい感じでチーム開発ができる。 エンジニアだって必要に応じて気軽にデザインを調整 できると、チームとして効率がよい。
115.
小さなスパンで、優先順位の上から順に
ストーリに着手するには お互いの役割の重なり合う部分を 分かり合い、作業し合う必要がある
116.
らせんを実践するって、 言うほど簡単じゃない
117.
お客様と現場でやる要求の分析は、 「社内に持ち帰って...」
がやりにくい。 技術の話をできる人が必要
118.
チームを成す専門家同士に 役割の重なり合いがないと
難しい
119.
今までのお客様に対して
やり方を変えるのは大変 お客様に1〜2週間ごとに フィードバックを返す習慣がないと、 大変だと思う なので、ちょっとずつはじめる
120.
まとめ
121.
らせん型ワークフローのメリット:
フィードバックに基づき フィード 改修を重ねることで バック 実制作 レビュー お客様の満足に近づける!
122.
1
私たちがらせん型ワークフローで 具体的にどんなことを しているか
123.
① 「どんな属性の人が なぜそうしたいのか」を ユーザーストーリーに起こして 上位の要求をより深く理解する
124.
② ユーザーストーリーを見積り、 プロジェクトが無理な方向に 進んでしまわないよう、 観測を続ける
125.
③ 優先順位はお客様とともに 共有し、いっしょに並べ替え、 価値の高いものから順に 届けられるようにする
126.
2
Webデザイナーとして らせん型ワークフローに 参加していくには
127.
① ワイヤーフレーム制作より 試せるインタラクションが大切
128.
② 少しずつ作るとは、 縦に美味しいものを 継続的に提供できるよう 心がけること
129.
③ お互いの役割の重なりあう部分 を増やし、 できる作業を増やせるように 努めること
130.
どうもありがとうございました
Download