20120728 アジャイル本読書会

Agile459 アジャイルサムライ読書会 #6
===========================

:日付: 2012/07/28
:場所: Creative Cafe
:参加者:

* 黒星さん
  * 会社きまりそう
* 小林さん
  * これから仕事に戻る
* 上田さん
  * ファーストサーバー対応
* 岩井さん
  * ひさしぶりー。
* 中島さん
  * 今年一月に転職して松山に戻ってきたが、
    前の会社から外注できてくれないか→今週から行っている。
  * 二ヶ月前に子供が生まれた。
* 懸田
  * 東京、大阪、広島に出張にいってた。

ふりかえりの確認
============
* 予習やってきた?→やってない...
* トーキングオブジェクトもってきたよ。
    
4.3 プロダクトパッケージ
===================
    
エレベータピッチは顧客向け、パッケージデザインはチーム向け?(黒星さん)
  対象は限定しないのでは?()
  モチベーションをたかめるため。だれるから? 呑み会は一回、二回しか効かない。

フィーチャ→日本的なイメージ
  「赤外線通信ができます」
効能→海外的なイメージ
  Appleとか。(ユーザー体験)
    
「このプロダクトで生活がどう変わるか」→チームからは「これで世界を変える」モチベーションアップ
お客さんから→「興味をそそられる」

絵をデザイナーに書いてもらう→違う。発見がある。モヤっとしたものが具体的になる。

エレベーターピッチと何が違う?
  エレベーターピッチをかいて、満足しそう。いらないのでは?
  すべてをやる必要はないのでパッケージはなくてもいい気がする。

フィーチャは機能?
  日本語の機能にあたるものは、functionのイメージ。(懸田)
  フィーチャ(feature)は、パッケージに書いてある特徴のイメージ。(懸田)
    
見積などは、機能一覧のレベルでやる/やらないを判断するから難しいよね。
    
エレベーターピッチもパッケージデザイン
  全部作る必要はないんじゃない?
    
今はパッケージじゃないな。ダウンロードだね。

4.4 やらないことリスト
================

今のサイトでこういうの作ってなかった。
どうしてもお客さんからしたら「あれもやりたい」「これもやりたい」。
最初はそういう話じゃなかったのにな...

やらないと決めたものに、後でどう対応するか?
  バージョンアップで対応しようとしてたけど、丸々別のツールとして出せばお金をもらいやすいかなと思う。
  「お客さんが考えていた」
  ここは重要
  「やらない」を「やる」に変える時に、次のバージョンで実現にやってもらうことで、継続案件になる。

最初はこのくらいでいいけど、どんどん増える。どのあたりまでをこのリストに書いておくか?
  どこまで
後で決めるを、いつ決めるか。遅らせて、後で時間がないにならないのかな?

これって、途中で変っていっていい前提なのか、変らない前提なのかがわからない。
  多分、リリースの度に作るものだと思う。やらない、あとで決めるのは次バージョンかな?
    
やることリストを必ず入れるようにしている。(バックログだね)

「後で決める」は、開発からみたら「やらない」、顧客からみたら「考慮してくれている」
  グレーゾーンを明確にする。
  「これできるからやっちゃおうか」というのもある。
    
「これをどのように顧客に見せる?」
  直接顧客に見せるようなことはしない。→後でお客さんに企画をだす。「こういうことはいってましたよね?」
    
4.5 ご近所さんを探せ
==================

* ここで集ってる人もご近所さん
* 考えるのが難しい。全貌はどうやって見つけだすの? どう信頼関係を築くの? 難しい。
* ピンとこないな。どう実践すればいいのかわからないな。何をどう整理するのかわからない。
* きびしい。
* 信頼関係を築くのは確かにそうだねと思うけど、本にあるようなドキュメントのレビューをしたいと考える人と信頼関係を築いたとしても、レビューするのは変わらない。やらないといけないことはわからない。

* 功罪があるんだ。  アジャイルに関係ない。
* 「社内営業」として、根回しが重要。日々仲良くしておくことは大事。
  * 社内営業って何?→社内で根回しすること。
  * 「根回し」は英語でもnemawashiだよ。外人には重要と位置付けられている。
* 内容は皆で共有しておくのが大事だよ。
  * 共有はしてなかったなぁ。
* 「それはあっちに聞いてくれ」とか言われてタライ回しにあった
* グループではなく、バイネームのマップも重要→「裏体制図」
  * 表の体制図は役に立たない。そこにない関係性とか、役割とかが実は重要。
* タバココミュニティ重要→みな仲ないい。そこにいかないと立ち行かなくなった。すわないのにタバコ部屋にいった。
* 裏の体制図と相性図が重要。
* 表と裏があると、きっとうまくいってないんだよね。

マスターセンセイの話
===============

* 顧客のコミットメントが本質だと思う。なだれこむのではなく重要。

5.1 解決案を描く
============

* リスクを見えやすくするために作るんだろうなぁ
* 「チームを選ぶことはアーキテクチャを選ぶこと」
* 現場だと「チームを作る」機会がないよね。いる人でなんとかしないといけない。何が得意かでチームが決ってしまう。難しいと思う。
* 人が足りない時にチームがつくれない。
* 図でかくのがおすすめ。絵をかくのがいい。
* ここでも「後できめる」「やらない」があるのが重要と感じた。
* 自分の経験でも、こういうのがなくて困ったことがあったので、グレーはグレーで明確にしよう。
* 一緒に仕事しないと得意分野はわからないよね。早期にメンバーを変えるのは大事だよね。
* 縦割り(設計からテストまでできる)ようにメンバー配置するのが大事。()
  * 実践的だよね。
  * 専門分化していると、案件規模が縮小して、人が減ると大変
  * メンバーを縦割りで育てていれば、プロジェクトが縮小して人が少なくなっても大丈夫になる。
  * 「積分」って呼んでる。


blog comments powered by Disqus

Published

28 July 2012

Tags