Readingagilesamuraiinsapporo20110830
irasally edited this page Aug 30, 2011
·
5 revisions
- 2011年8月30日 19:00-21:00
- エスプランニング開発室
- 参加者 6人
- 2.3途中～3章まで
- 自己組織化とは（前回のおさらい）
- 自分で考えて自分で動く事のできる組織のこと
- かつ、そのスキルがあることが前提だよね
- 自分で考えて自分で動く事のできる組織のこと
- 帽子をかぶり分けるという比喩
- きのこ本にも出てきたよね
- 「複数の帽子をかぶることに納得するかどうか」の前に「いろんな帽子を被ることができる人でなければいけない」のが難しいね
- 役割の帽子をかぶり分けることに納得できなくてもかぶった帽子の役を演じていればいいのかな
- 帽子をかぶるということはアジャイルの考え方としては不要なんだと思う
- 「役割の帽子をかぶり分ける」は縦割りの役割分担へのアンチテーゼでもあるよ
- 複数の帽子をかぶり分ける事が出来る人で職能横断型チームを構成していくということではないの？
- 自己組織化されたチームでは帽子をかぶり分けない（常に複数の帽子をかぶっている）
- 帽子そのものが要らない
- 役割の帽子が先にあるのではなくて、人がある
- 定義が「職能横断型チーム」というのがハードルが高いよなあ
- ここでは自己組織化されたチームへ進むための円滑な移行のために「いろんな役割の帽子をかぶり分けなければいけない」と伝えているのだと思う
- 役割＝責任＝担当（一人） が従来の考え方
- かぶり分けるというところから自己組織化へつなげる
- 単に帽子をかぶり分けるだけなら小さいチームでのウォーターフォール開発でもよくある話
- 一人何役というだけならアジャイル的ではない
- プロジェクトで時間を何に使っているのかはアジャイルなチーム編成では厳密に計測しないんじゃないかな
- 役割によって「XXX（管理とかテストとか）に○%」と時間をはかることに何も価値がない という考え
- 契約の関係上形式的にそういうことをやる場合があるというのとは別の話なので注意
- 複数の帽子をかぶり分けることに納得していない人に対するアプローチはどうすればよいのだろう
- この本には、納得していない人がいる場合にどうすればいいかは書かれていない
- 現実のチームの中でひとりでも異を唱える人がいればチームとして成り立って行かないのではと不安
- 納得していない人を納得させるのは大変だが実際問題どうすればいいのか
- 実際問題、無理… * 強制的にアジャイルなチームに参加させることになるが、その時点でアジャイルなチームになり得ない * その役割のフェーズしかできない * その人の作業だけ切り離す
- 全員に向くとは思わない * 知らないからできない、やっていない、人はまだいると思う * 実際に間近でアジャイルなプロジェクトを見ていいなあと思う人はいるかも
- そういう人は、たぶんそもそもプロジェクトに参加している目的が違うのかもしれない * 「顧客によいものを提供する」という目的をもっていないのではないかな
- 今眼の前にいる納得していない人より、このプロジェクトをどこかで見ていて納得するかもしれない誰かを仲間にする * そのために今目の前にあるプロジェクトをうまくやっていこうと思うことも大事なんじゃないかな
- デザイナーには「複数の帽子をかぶること」を納得してもらえない事が多い（区切りを付けたがる）
- 全部のデザイナーがそうではない
- デザイナーさんとは契約が完全に分かれてしまうことがほとんどだからそう見えるだけで、テストやプログラムも作業を切り取って分けて出せば同じじゃないかなぁ？
- この本には、納得していない人がいる場合にどうすればいいかは書かれていない
- 読んだことある人からの話
- 求められるものが高すぎる
- 高スキルなことを書いてある
- テスターとしてのスキルが足りていないことを実感する
- ひと通りのスキルがあることが求められている
- 実際、プログラマ以外のスキルで「そこそこ」に達している人もなかなかいない
- 「アジャイルな～」となる前の壁が高いですね
- 話をしていくうちに、前提の壁が高すぎて自分には無理だと思った…
- この本に書かれていることは理想、目指すところ
- アジャイルのすべてが理想論ではないよね
- どうやって現実と折り合いとつけていくかが大事になるね、やっぱり
- この本で求められていることをすべてやらなければアジャイル開発ができないわけではないよね
- このあたり（前半）は理想についてがつんと書かれているのでへこみやすいのかも
- 口当たりよく書かれているよりがつんと書いてくれている方がいいね
- 顧客に価値を届けるということを第一目的としているというのが大事
- 技術は後からついてくる（ちゃんとやれば）
- ただし、基礎体力は必要
- 基礎体力をつける方法はこの本の範囲外
- この本は基礎体力をつけるための本じゃなくて、基礎体力を持っている人が前提になっている
- 目線を変えれば、足りないことを見つけるための本じゃないかな
- 目指すことが書かれてあってそれのために何をすればいいのか
- 読み進めていって悲観的になるための本ではない * 足りないことが多すぎるということに気がつくことはあるけど
- 「お目にかかれて光栄です」で書かれていることがとても大切
- 「あまり堅苦しく受け止めないでほしい」
- 「場外ホームラン級の圧倒的なアジャイルプロジェクトの姿」
- 感覚的にはメンターなのかな
- チームを導入して進めていく手法
- トレーナー、コーチ、メンターの違い
- トレーナー：調整、管理
- コーチ：スキルを伸ばす
- メンター：自分が現場に入り込んで一角となってプロジェクトを成功させる
- 「ゼネラリスト」は技術的に高いものを求められるものだけれど「あいまいな状況に抵抗がない人」「我を張らない」は性格的な部分も大きいね
- 「あいまいな状況に抵抗がない人」というのはウォーターフォールのアンチテーゼとして書かれている部分も大きいね
- 「我を張らない」ことに自覚的 となるにはどうすればいいのだろう
- 口出しを許せるか、納得できるか
- そもそもそれができるのが一人しかいない場合は仕方ない
- そういうときは、相手を信じて他が口出ししないということも我を張らないことにつながるよね
- 「何らかの役割の帽子をかぶっている」から自我を通さない
- チーム全体のことを考えれば 個々が「我を張る」ことはないよねということが理解できているかどうかなのかな
- チームにはにはお客さんも含まれているわけです
- むむむ、そうなのだった…
- 現実解としては完璧なゼネラリストになる（そういうひとがいる）というよりは、それぞれの領域のそこそこのプロフェッショナルでチームを編成して、お互いのフィールドを理解しながら見識を広げていくというアプローチが多いですよね
- アジャイルなプロジェクトだといろんな分野の仕事を目にするので他の分野に興味を持てる機会が多いのかな
- 周りができなさ過ぎて一人で頑張っていたら、結果的に「ゼネラリスト」になっていた
- 顧客に価値を届けるということを第一目的としていると結果的にそうなる
- 禅問答みたい
- 「適切な人がいなかったら連れてこればよい」は現実な解決としてはなかなか難しいよね
- だからどうしよう、と試行錯誤をしているのに…
- 絶望的になってしまったので「探す」を「作る」に読みかえるようにしているよ
- 熱心な弟子はセンセイのこの答えで満足したのだろうか
- 関係者「全員」でプロジェクトについて話しあってからプロジェクトをはじめることってなかなかないよね
- トップダウン式で仕事が降りてくる事が多いからかな
- プロジェクトを考える人とプロジェクトを作る人が完全に分かれている傾向がある
- 企画や分析は開発者がやることではないという風潮
- 作るものが決まっている事が多いしね
- 現実として何ができるか
- チームメンバーでせめて「何を作るか」を共有すること（チームで「○」と「△」を目指す人がいないように）
- お客さんと全然違う形でチームで納得してしまわないように注意が必要
- そしてチームとお客さんの答えが違わないように（お客さんは「○」、開発者は「△」とならないように）
- チームメンバーでせめて「何を作るか」を共有すること（チームで「○」と「△」を目指す人がいないように）
- ゼネラリストを集めてプロジェクトの形を描くことができれば伝言ゲームがある程度解消できるかも
- 現実はプロジェクトが降りてきたときに、一人が「△」を思い浮かべ、ほかは思い浮かべられない（思い浮かべようとしない）チームだったりしますね
- 良くて一人が「△」一人が「○」とか…
- プロジェクトが降りてきたときにメンバーがアナリストの帽子をかぶっていないと「○」だか「△」だかわからない
- 技術の有無というよりは、意識、何ができるかを思い浮かべようとするかどうか
- 思い浮かべようとしなければ意見をすりあわせることもできない
- ゼネラリストの必要性を痛感しますね
- プロジェクトについて話しあう＝手ごわい質問ができるかどうか
- アジャイルなプロジェクトにかかわらず、プロジェクトのキックオフでは大切なこと
- 手ごわい質問をする勇気があっても権利がない
- 手ごわい質問をしてみたいよねぇ
- せめてチーム内で手ごわい質問をする機会があるといいよね
- でもPMに質問をしても答えられない内容だったりする
- プロジェクト憲章が目指している項目も同じ
- 考える人が一部の関係者になる
- 実際にプロジェクト憲章を作ってみると、プロジェクトの意義があれれ・・・このプロジェクト、必要？となることもある
- これは辛い
- 本当はお客さんがメインで作成するもの
- 実際はPMが社内向けに作って引き出しにしまっておかれたりしている
- お客さんと作るというのにも2パターンある
- お客さんが作れないから手伝う
- 規模が大きいから一緒に作ってしまいましょう
- 「本来のプロジェクトの流れ」というのは一度しっかり知っておいたほうが良い
- お客さんがほしい物がある → 話を聞いてプロジェクト憲章をつくる → 提案できるだけの材料としてRFPを作る
- 本来プロジェクト憲章が先なんだよー
- 本来のプロジェクトマネジメントについて、一度きちんと学んだ上でインセプションを学んだほうがためになることが多いよ
- 基礎を学ぶのにはプロジェクトマネジメント系の入門書ならだいたい何でも大丈夫
- 見えるところにおくというのもとても大事だね
- 自分で作ってそれを説明していると作ったことに満足してしまう
- みんなで作ると他人ごとにできないというのはいいよね
- インセプションデッキは生きた成果物
- プロジェクト憲章って作りっぱなしのイメージがある
- 「必要に応じて見直す」のが本来のあり方なんだよ
- 知らなかった・・・・！なんとなく変えられないものだと思ってた
- 「必要に応じて見直す」のが本来のあり方なんだよ
- プロジェクト憲章って作りっぱなしのイメージがある
- 何が大事？とりあえず何があればいいかな
- 1をやるだけでも十分にメンバーの士気が高まる
- 2,3は「ものづくりをする人」として絶対必要だと思う
- お客さんと作るからこそ 4,8,9 あたりが重要になるよね
- いきなりインセプションデッキを全部出してもうけいれにくいよね
- 一度に全部やるのは難しい
- 書かれている項目を少しずつチームで共有するとか
- PMであれば「とりあえずこれについて考えてきてみて」という提示もありだと思う
次回は4章からです！