• Like
クライアントの要望にこたえるWebサービス開発 ~「らせん型ワークフロー」のススメ~
Upcoming SlideShare
Loading in...5
×

クライアントの要望にこたえるWebサービス開発 ~「らせん型ワークフロー」のススメ~

  • 49,844 views
Uploaded on

2012年8月26日に行われた、CSS Nite in SAPPORO, Vol.5 での発表資料です。

2012年8月26日に行われた、CSS Nite in SAPPORO, Vol.5 での発表資料です。

More in: Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
49,844
On Slideshare
0
From Embeds
0
Number of Embeds
22

Actions

Shares
Downloads
412
Comments
4
Likes
283

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. どうもありがとうございました