Curiosity

骨とワニが好きなデザイナーです

【勉強会】Lean UX Circle Meetup with Pivotal Labs_150610

全編英語だと知らずに申し込んだので、つらみを味わいました。いちおう、がんばったメモです。正確性に自信はありません、どうかあしからず!!!!

概要

Building better Products at Pivotal Labs

  • Jason Fraser @jfraser
  • Pivotal Labsとは
    • プロダクト開発やコンサル?などを行うアメリカの会社。Pivotal Trackerをつくってるところ
    • 9.1に東京オフィスをOPEN!採用も考えてるので、興味があったらぜひ声かけてね
  • Pivotal Labsの特徴
    • クライアントと一緒のチームになって仕事をすすめる(はじめにクライアントと「必ずチームに入って一緒にプロダクトを作る」という契約を交わす)
    • メンバーは必ずペアで動いている。仕事の時はひとつのCPUでふたつのモニタという状況。ご飯も二人一緒。休憩時にも一緒に卓球をしたりしている
    • クライアント側のディベロッパーの教育も事業として含む

Innovation at Pivotal

  • 開発時にクライアントと行うワークショップで、以下のような質問をする
    • Who is the customer?
    • What is problem?
    • Worth solving problem?
    • Is our solution the right solution?
    • Is there a market?
    • Does market scalability matter?
    • Is the business model well thought out?
  • 上記の質問を通じて、プロダクト開発における不確定要素を明らかにしていく
  • プロジェクトの成功ではなく、プロダクトの成功を目指す

Why Agile?

  • Lean UXはAgileを応用した考え方
  • 失敗は小さく早くしよう
  • アジャイルソフトウェア開発宣言
    • プロセスやツールよりも個人と対話を、価値とする
    • 包括的なドキュメントよりも動くソフトウェアを、価値とする
    • 契約交渉よりも顧客との協調を、価値とする
    • 計画に従うことよりも変化への対応を、価値とする

Extreme Programming (XP)

  • wiki
  • “How little can we do and still build great software?”
  • XPという開発手法
    • 躓いてもすぐに取り返す
    • ビジネスの意志決定のための「オプション」を増やす
    • XPでもっとも大切にされている価値は、コミュニケーション、簡潔さ、フィードバック、そして勇気
    • おすすめの本:Extreme Programming Explained
  • Why Simplicity?
    • アメリカ政府のヘルスケア関連のプロセスはすごい複雑
    • 複雑なものはうまく働かない
  • How do you approach a typical project?
    • Analysis → Plan → Stakeholders → Feedback → Revise → Budget → Approval → Execute → Measure
    • 上記のような典型的な開発プロセスだと、ひどいアイデアで時間を無駄にするという悲劇が起こってしまう
    • そこでExtreme Programming!

Extreme Programming at Pivotal Labs

  • チームにフォーカス
    • Communicative overhead:人が増えると、コミュニケーションコストは増大していく
      • 3 people 3 relationships. 4 people 6 relationships
      • 3人がそれぞれ握手をするには3回必要。それが4人になると6回必要になる
      • relationships = n(n-1)/2
      • 社会心理学的に見てもネガティブな効果が現れてくる → ex.傍観者効果, 社会的手抜き
      • そこで、以下のようなことに気をつけた
    • Team Size
      • チームは小さく!
      • ベゾス「チームの人数はピザ二枚分がいい」
    • Pair Programming
      • ペアで働くことの利点
        1. より早くよりエレガントなソリューションが生まれる
        2. エラーが減る
        3. チームの繋がりが強くなる
        4. ドキュメントがいらない
      • Pivotal Labsではデザインもペアでやってる
      • ペアだとよりコストがかかるように思えるかもしれないが、やってみると通常より3割(3倍?)開発が早くなった
  • 率直さを大切に
    • No Rockstars:egoは必要ナシ!
    • 意見を出しやすくする工夫:ホワイトボードに3つの顔(にっこり、真顔、おこ)をかき、そこにチームメンバーが意見を書いていく
  • 規範(Predictive)ではなく予測(Prescriptive)
    • スクラムでいこう
    • [Pivotal Trackerのキャプチャ]
    • Velocityはその週で何がどれだけできるか、を予測するための数字。罰則のためのものではない
  • テスト駆動開発
    • テストが通ってからデプロイ
    • 前述のとおり、Pivotal Labsでは基本ペアで開発してるので、クオリティチェックは同時に行われてると考える。なのでテストが通っていればOK
  • Interactive
    • No sprints
    • スコープではなく、時間にコミットする
    • 顧客のバリューにフォーカスする
    • 継続的にデプロイ

Product Management for XP

  • 伝統的なプロダクトマネジメント
    • ビジネス、デザイン、マーケティングなどをプロダクトオーナーが握っていて、そこから開発指令が発せられる
  • Pibotal Labsのプロダクトマネジメント
    • ビジネス/プロジェクトマネージャー(PM)、開発&エンジニアリング、UX&デザインの3チームがいて、それぞれが良いバランスで開発に責任を持つ
    • 最終意思決定者はPM。ただし、PMがよくない決定をしてたらそれを簡単に変更できる
  • Pivotal LabsのPMがやってること
    • プロジェクトを前進させるための仕様書づくり
    • カスタマーバリューの優先度付け
    • Work directly with the developers plannning ...
    • クライアントと一緒に、プロダクトのビジョンを洗練させていく
    • プロジェクトのリスクとプロダクトのリスク、両方をマネジメントする
  • What does it all mean?
    • We can build rock-solid software quickly and reliably with very little interpersonal drama.

質疑応答

  • (会場)クライアントとはどういう契約を交わしているの?
  • (JF)プロダクトを単価で買うというよりは、5〜6ヶ月とか開発期間を買うという感じ。中身の保証をしていないので、プロダクトそのものにとらわれない開発ができる

  • (会場)クライアントのメンバーのコミット度は?
  • (JF)100%!複数掛け持ちはNO!

  • (会場)クライアントからはどういった職種の人に参加してもらってる?
  • (JF)重要なのは職種ではなく性格。こういう性格の人をお願いします、というふうにお願いしている。Pivotal Labsは、ディベロッパーの教育の役割も担っているのでそういう風にしてる

  • (会場)Jasonさんが事業会社のPMとして新規開発をはじめるとしたら、どうやって予算を取りに行く?
  • (JF)リスクに直面する前に、クライアントにリスクを自覚させる問いを投げかける。ポイントは、Build − Measure − Learnのサイクルを小さく早く回していくこと。無駄に思えるかもしれないが、こっちのほうが通常の(ウォーターフォール的な)プロセスよりもリスクが少ないということを伝える
  • (坂田)学ぶための環境づくりが大事。いかにClosedな状況でBuild − Measure − Learnサイクルが回せる環境を社内に作れるか、がキモになりそう

  • (会場)Pivotal Labsのプロジェクトではいつまで作らなければならないというデッドラインの概念はほとんど無いと思うが、それでもクライアントがしびれを切らすことはない?
  • (JF)うちではプロダクトをリリースしてはいどうぞ、というやり方ではなく、ずっと一緒に改善していくものだという認識で進めている。そういう意味では「完成」や「納品」という概念無い。なので、もしそういうことになったとしても、Leanなプロセスでやっている以上プロダクトは早い段階からある程度の形にはなっているし、プロジェクトがどの段階で終了になるか、というだけ

  • (会場)クライアントはリソースが無いからこそ外部であるPivotal Labsに依頼してきているのだと思うが、Pivotal Labsのバリュープロポジションは何なのか?
  • (JF)良いプロダクトをつくることはもちろん、クライアントの上に立って、クライアントをうえに導いていく存在であるということ。クライアントの中にいる社員のことはもちろん、社会全体も良くする存在である

おまけ:タスクの優先度付けマトリックス

  • 懇親会でお話されていた内容です!
  • クライアントにやってもらったテストやヒアリングの結果出てきたタスクに、どう優先度をつけていくか

f:id:takana8:20150611020439j:plain

  • 横軸がタスクの重さ(←難しい →カンタン)、縦軸がカスタマーバリュー(↑高い ↓低い)のマトリックスを用意する
  • バグや要望(新規機能など)をタスクとしてふせんに書き出す
  • それらのふせんをマトリックス上に貼っていく。正しいかどうかはとりあえず置いといて、どんどん貼っていく
  • 各タスクの優先度を判断する
    • 重要なのは「今考えるべきこと」にフォーカスすることなので、下半分(=カスタマーバリューが低いもの)は全て落とす
    • 左上部分(=バリューが高く比較的容易なもの)はもちろんやっちゃう
    • 右上部分(=バリューは高いが困難なもの)の優先度は、Minimum Viable Productに必要かどうかで決めていく
    • もし右上部分の優先度付けでうじうじ悩んじゃうようなら、ラビッドプロトタイピングでサクッとつくっちゃって、再度クライアントにテストしてもらって判断する。悩む時間がもったいない!
  • 優先度を落とした機能が後々必要になったとしら、それはその時また考える。とにかく、今やるべきことにフォーカス・フォーカス・フォーカス!