第4回読書会

• 2011年9月13日 19:00-21:00
• エスプランニング開発室
• 参加者 8人
• 4章～ 4.4まで

第4章 全体像を捉える

4.1 我われはなぜここにいるのか？

自分自身が現場で確かめる

• なかなか現場に行けないよね
• 間に挟まっている（孫請け）とエンドユーザーの顔を知れることってほとんどないんだよね

司令官の意図をつかむ

• 孫請けの場合の司令官(目標や目的を持つ人)は仕事を発注した会社だよね
  • 相手の意図をつかめているか？ → 意図を伝える側にもスキルが必要…だけど発注側からうまく伝わらないことも多々あるよね
  • 発注した会社の人の話を聞いて「本当にお客さんがそう言ってるの？」と思うことがある
    • 「本当にお客さんがそう言っているの？」という疑問は伝えないといけない
  • 「お客さんはどう思っているのですか？」「お客さんに聞いてみてください」といえる環境は風通しが良い
  • そもそも、孫請けの場合、「お客さん」は発注してきた会社になるのでは？
  • 発注者のためにモノを作ることが最終的なお客さんのためになるのか？という「モノを作る者」としてのジレンマ * でも、直接やり取りしているしている人が幸せになれることを考えるのが良いのでは？ * そこに価値を置くべき * 身近に接して仕事をしているから、「エンドユーザーのためか？」よりも幸せが想像しやすい * 発注者にも発注者の戦略がある * 発注者が戦略にどうアプローチしているのかを知ろうとする → どうすれば幸せになるか考えられるよね * 発注者も同じようにモヤモヤしている事が多いと思うよ * いかにそれを解決してあげるというかというアプローチが大切になる
• メンバーにとってはPMが"司令官の意図"を伝える者になるね
  • だれから意図を伝えられるか、は立場によって変わってくるね
• プロジェクトがはじまるときに「我々はなぜここにいるのか」を話す時間をとれていることってどれくらいある？
  • 「我々はなぜここにいるのか」を最初にすることはかなりメンバーのモチベーションに影響する
    • いきなり呼ばれて「いいから作れ」は本当にモチベーションが落ちていく
  • 「自分はなぜ必要か」「あなたはなぜそのプロジェクトに必要か」は伝えることが大切
  • この本を読んでから大事にするようにしている
    • アサインが流動的なプロジェクトだとなおのこと大切だなと実感している
  • リーダーとしてメンバーに必ず伝えるようにしている
    • そのうち、メンバー側から自発的に聞いてくるような形になってきたよ

4.2 エレベーターピッチを作る

• 企画書や提案書（プレゼン資料）で同じような内容のものを作ることはあるよね
• じゃあ営業さんが作って提案した資料を配布しただけでもいいのかな？
  • チームとしての意識を共有するために、プロジェクトの目的をはっきりさせるために必要なものだよね
  • だからチームで作ったほうがよいんだね
    • もし、チームでゼロから作れない環境のプロジェクトであったとしても、せめてチームで話しあう、修正する、意見をすり合わせる時間があるといいよね
• 「エレベーターピッチ」 という言葉は売り込みから発生した言葉だけど、今回は「なぜこのプロジェクトが存在するのか」というのを説明するための方法として登場しているんだね
• テンプレート自体はどんどん改変していけばいいよね
  • 最後の2つ（=価値）を除いて他は全部考えたほうが良いね
    • 出来ればあったほうがよいけど、志としては意識したい
    • でも、やっぱり「価値」あるものを作るためにプロジェクトがあるのだから、価値にについては考えていくべきだね
    • 価値が「（他よりも）価格が安い」ということだけに偏るのはなかなか厳しいね
      • 市場価格がどんどんさがる（CMS PHP案件とか）誰も幸せになれない
      • 価格以外の価値を出していきたい（デザイナーさんよりもエンジニアとしてきっちりプログラムを作るよ、とか）
      • お客さんもエレベーターピッチを読んだら、価格以外のことにも価値があるということが伝わるようになるんじゃないかな
• PMがメンバーにプロジェクトの目的を伝える手段に有用だね
  • 逆に目的などを伝えたあとに、メンバーにエレベーターピッチを書いてもらい、目的が共有できたかを確認する手段にも有用だと思う
  • 伝言ゲームが伝わっているか、という確認にも使える
• 読みかえす、印象に残す
  • だから短く簡潔にまとめてあることが大事だね

4.3 パッケージデザインを作る

• Webサービスだと必ずそれを考えているだろうなぁ
  • 受託だと全部に力を注ぐことはなかなか…できないなぁ…
    • STEP1はできるよね（というかやらないといけないよね）
    • 機能（フィーチャ）に値段がついてしまうと困ったことになる
      • フィーチャを買ってもらっても効能が何かわかっていない状態（本当に実現したいことは何？）
• 効能を実現したいけどどこにその機能があるのかわからない（某Office製品など）
• 効能を見せるのはAppleが上手いよね
  • CMでスペックとか全然言わない（でもハイスペックなんだよねぇ）
• プロジェクトメンバーでパッケージデザインについてひと通り考えてみる、やってみることは大事だよね
• 最近プロジェクト内でパッケージデザインの手法を少し取り入れてみた（企画の段階で）
  • キャッチコピー作るの恥ずかしい
    • インチキ臭くなってしまうのが気恥ずかしくて…
  • でもチームビルディングとしての効果はなかなかあった
• パッケージデザイン = 自分の作るものだからかわいがって名前をつけてあげたい
  • プロジェクトやプロダクトに愛着があるか
    • darashiさんとかからは、プロダクト愛が伝わってくるね
  • お客さんを巻き込んでいい関係を作っていかないと受託製品にそこまで愛着持てないんだよなぁ
  • 愛着が湧くようにする工夫
    • Tracにパッケージロゴを入れるとか
    • 会社のロゴをwikiに入れておくとか
  • やってみると意外と楽しいかもね、やってみるといいかも
• パッケージデザインを自分たちで作ることに意味がある
  • 出来上がったものを渡されても（ただ、与えられても）なんにも思わないよね
• ハードと違ってソフトウェアはキャッチコピーが思い浮かびにくいな
  • でも、ソフトウェアって意外と形ある製品よりキャッチコピーつけやすいのかもしれないと思ったよ
    • 目的や動きに特色が出る製品だから
• 見えるところにずっと貼っておくのはいいね
  • 没になったものも含めて
  • ふりかえりのときに見たりとか

4.4 やらないことリストを作る

• いいですね
  • ぜひお客さんと面と向かってやりたいですね
    • こっちが勝手にやらないことリストを作ってしまうと「なんでやらないの？」という疑問がわくから対面がベター
    • お客さんと一緒に納得しながら決めていかないと「やらないって言ったじゃん」ってなっちゃう
    • 時間をかけて両者が納得して、覆らない「やらない」ことを決めることが大事だね
• 「やらないことリスト」はイテレーションによる開発が前提だね
  • まずは「やらない」を決める
  • イテレーションごとに「あとで決める」から「やる」にうつしていく感じ？
  • アジャイル的な開発では「あとで決める」時間、機会があるから「あとで決める」が活きてくる
• 「やらない」ことを決める勇気、コスト、決断、難しい
  • 早ければ早いほうがいい（のだけれど…）
  • 「やる」は決めやすい
• 「プロジェクトの目的、司令官の意図」があるからこそ、何をやらないか、何をやるかを決めることができるんだね。
  • プロジェクトの目的（エレベータピッチに書いたこと）が、やる／やらない を決めるぶれない指針になる
• 「やらない」ことが契約が絡んでくることが多いよね
  • この本には契約の話が出てこないよね
  • 海外ではある（ThoughtWorks社）、日本だとE和さんが少しやっている？
  • 現状の契約形態とどう折り合いをつけていくか、だよね
    • 準委任？
    • お客さんはリスクを取りたくない
      • 「一緒に作る」という考え方が生まれてくるとリスクを押し付けあうという気持ちが減るのかな
      • リプレースだとなかなかそのモチベーションがあがらない（特に大きい組織だと）
        • 「いきなりガラっと変えられてもこまる」「前と同じがいい」
        • 「前と同じ事を我慢している」ところを見つける
        • 作ってみる → 触ってもらってみる → 感触を反映させるというイテレーションの開発はリプレースにも向いているんだね
• やる／やらないの決定をお客さんとできたらいいけれど、どうやっていけばいいのかな
  • 納得させるための材料を準備する
  • お客さんにプロジェクトに巻き込まれている自覚を持ってもらう
  • 信頼関係大事 → 必要ないからやらないんじゃなくて、やりたくないんじゃない？ と思われないように
  • お客さん側の人が、こういう読書会にくるようになるといいな
  • 出来上がる「プロダクト」について愛着をもっているお客さんは少ないよね
    • パッケージデザインをお客さんと一緒に作ってみるとか
      • 現実的には難しいけれど
  • メンバーでもなかなか向上心がある人がいないのに、お客さんが巻き込める時代はまだ先だよね
  • やりとりをするお客さん（担当者）が権限を持っていない → もっと上を巻き込まなければいけないよね
    • ということは、自分のチーム（会社）の上の人にも理解してもらう必要があるよね
      • 上層部がきっちりこのことを理解して実践していっている会社はうまくいっているとおもう
    • お客さん側でのトップダウン（権限を持った人から巻き込んでいく）
      • お客さん側の上層部から意識を変えていってもらい、部下に啓蒙していってもらうとか、どう？
  • なかなか北海道でお客さんをまきこめている会社はないよね
    • えにしてっくさんはどうなんだろう
    • 東京以外の地方都市（※島根をのぞく）でアジャイル的な開発がうまくいっている地域ってあるのかなぁ

他流試合について

• 道場紹介文を書こう（オム子）
  • 札幌でいつも話題に上がることについて書いてみよう
    • 「どうやってお客さんを巻き込んでいくの？」
    • 他の道場ではそのあたり、どんなふうに話していますか？

---

次回は 4.5 からになります。 9/27（火）開催です。