DoorKeepr
http://yokohama-dojo.doorkeeper.jp/events/5061
以下の書籍をターゲットとした読書会なのです。
 | アジャイルサムライ−達人開発者への道− (2011/07/16) Jonathan Rasmusson 商品詳細を見る |
場所はいつもの横浜、アットウェアさんです。
参加者は20人弱でしょうか。
今回は特別編ということで、江端一将氏をお招きしてワークショップをやりました。
■ディスカッション＆模造紙
ウチのチームは道場主含む4名で、模造紙はこんなカンジ。大半が、道場主が書いたものｗ
以下、個人メモ。私が印象深かった点は赤字にしました。
■江端さんの自己紹介
・これまでは海外で活動してきたが、今は千葉にいて、活動の拠点を日本に移すとのこと。
・アジャイルコーチをやっている。
・オープンソースのコミッターをやっている。
・「すくすくスクラム」というコミュニティを立ち上げた。他にもいくつかコミュニティで活動している。
■今日の議題
大きく3点。今日はこれらに踏み込みたい。
１．成功の定義
・プロダクト開発の常識が間違ってるんじゃないか？
・そもそも成功ってどう定義されるのか？
・「プロジェクトの成功」をきちんと定義してからプロジェクトに入った人って、どのくらいいるのか？
２．柔軟性
・「柔軟性」って何を持って考えるべきなのか？
・柔軟じゃないほうが良いのは何か。
３．ものごとの賞味期限
・ものごとには賞味期限がある。価値がある情報がインテリジェンスである。
■１．成功の定義
■成功の定義とは？
・成功ってどういうふうに定義しているのか？例えばプロジェクトとか製品開発の成功を例に考えてみて欲しい。
この問いに対し、ウチのチームから出た意見は以下。
・お客様のほしいものを提供できた時が成功。
・チームの人間関係が良い。
■プロジェクトを成功させるためのルールって必要だと思うか？
この問いに対し、参加者から出た意見は以下。
・4人とか5人とか、一定の人数を超え始めたらルールは必要では。
・いや、一人でもルールがいるのでは。
・例えば、フレックス勤務でコアタイムが無いと、メンバが揃わないのでやりにくいことがあった。
→ チームであるためのルールが必要だと思った。
・法律順守は絶対必要だよね。
■プロジェクトで勝手にルールを作ってませんか？
・プロジェクトで「ルールを作りましょう」って言い出す人って、どのくらいいますか？
・お金とか納期のデッドラインは、お客さんから言われますよね。
・でも、働き方のルールをお客さんから言われることはあまりないですよね。
・で、お客さんに「何かルールありますか？」と聞くと、「無い。どーゆうやりかたをやってもらってもいい、モラルに反しなければ」と言われる。
■プロジェクトのルールは決めたほうが良い！
・なぜなら、互いの意見が分かれたときに「私はこの前提でやってます」と言えるようになるから。
・ルールが無いと、コミュニケーションが難しい。
・でも、プロジェクトでルールを作ろうとはなかなかしない。
・自己組織化とか言われるけど、それって妄想だよね。
・ルールが必要だから、スクラムでも「スクラムマスター」を必要としてる。
■プロジェクトの終盤には大抵ルールがあるのに、なぜ最初に働き方のルールを決めないのか？
この問いに対し、参加者から出た意見は以下。
・そんなルールなんて当たり前でしょ、というのがあるから。
・どこまで決めたら良いのかが分からないから。
・前例とか実績とかで暗黙で決まっているから。
■ルールは、合わなければ変えれば良い！
・ルールは変わる。
・最初にルールを完璧に作る必要ってありますか？
・最初から完璧を求めると、難しいから誰もやりたがらない。
・そうじゃなく、ルールを変えるためのルールを決めればいいのでは。
・イギリスのお客さんは、働き方のルールを最初に決めていた。
・最初にルールを決めることで、プロジェクトの成功率が25%くらい上がった、という実績もある。
・スクラムのルールは走ってるが、プロジェクトを成功に導くルール決めをしないことが多い。
・それは思考停止である。
■成功に完成形はあるか？
・成功に完成形が無いなら、なぜ「プロジェクトが成功した」というニュースが聞こえてくるのか？
この問いに対し、参加者から出た意見は以下。
・完璧じゃなくて、ある指標を超えたら成功、としているのでは。
・時間は動いているので永続的な成功が定義できない。
・成功の判断は他人がしているので、自分と他人の成功の基準が違うことが多い。判断軸の違い。
・成功の定義が主観的。
■楽天は成功していると言えますか？
この問いに対し、参加者から出た意見は以下。
・判断が付かない。
・分野によって違う。成功してる分野もあれば失敗してる分野もある。
・成功してると思う。なぜなら、ベンチャーがこれだけ高い倒産率を示す中で高い企業生存率を示しているから。
・企業が大きくなって規模が永続しているので、成功と見なせるのでは。
■プロジェクトに入った時に、何を目標にしますか？
・何かを目指していますか？
・それをプロジェクトの完成形に置き換えることはできますか？
この問いに対し、参加者から出た意見は以下。
・成功を決めると足を止めてしまう。なので目標を決めて達成を目指す。
・「黒字化」という前提があるのでは。
・大きな会社を超えるぞ、みたいな目標を立てる。より大きな目標をきめる。その際は売上が目標になることが多い。
・納期内に仕様を満たしたものをリリースする。
■プロジェクトの目標は「黒字」が大前提になっている。それで合ってますか？
この問いに対し、参加者から出た意見は以下。
・エンドユーザ向けなら、エンドユーザの満足度が成功では。
■エンドユーザの満足度が高ければ成功と言えるなら、大赤字でもいいのか？
・「ビジネスに黒字は大前提だけど、成功の完成形はない」と、どの国でも言う。
・でも、そんなたくさんのこと考えてますか？
・何に基づいて目標が定められるのが理解されていない状態を検証しないで、本当に良いのか？
・プロジェクトを進める上で、何を変えることが良いことなのか。
・ビジネスは難しい。なにをやれば黒字になるかわからない。
・根拠のない数字が、従うべき数字なのか？例えばマイルストーンとか。
■プロジェクトを成功させるために常識を変えたほうが良いものはあるか？
・他の人と自分が考えることの共通認識をどう取るか？
・コミュニケーションのキッカケはルールでなくてもいい。
・ルールをいくつ置くかで、プロジェクトの成功を高められるのでは。
・スクラムの良いところは「フィードバックループを上手く使いましょう」という思想がデフォルトで入っているところだと思っている。
・でも、それを超えるものがあるはずだ、と思っている。
・目に見えてるところと実際は、必ずしも一致しない。向こう側にきっと別の誰かがいる。
・意思疎通のキッカケが多いほうが、成功の確率を高めるひとつの方法である。
・どうやってみんなをフォーカスさせていくかが重要。その方法はたくさんある。
・「標準化」も良い。「標準化」が悪いんじゃなくて、「標準化したものが形骸化すること」がダメなんだ。
・「標準化」することで、時間をかけずに済むメリットもあるはず。
・実は形骸化する前に気づけるものがあるはず。
・「あなたの思っている常識がカイゼンのポイントになる」とはスクラムではよく言う。
・「常識には罠がある」と思ってみるのがよい。
２．柔軟性
アジャイルをやってると「柔軟性」というキーワードによく遭遇する。
・では、私達が柔軟性を持つべきものはどういうものなのか。
・柔軟性は何種類あるのか。
■柔軟性を持たせたほうが良いものと、持たせないほうが良いものは何か？
この問いに対し、ウチのチームで出た意見は以下。
●柔軟性を持たせたほうが良いもの
・失敗から学ぶ姿勢
・常識に囚われない
・相手の意見を取り込む
●柔軟性を持たせないほうが良いもの
・自動化する際のルール。
→ 例えば、コーディングルールとか。静的解析ツールで自動チェックしようとすると、厳密性が求められる。
■出た意見を他のチームと共有してほしい
チーム4名のうち、2人が他のチームへヒヤリングへ行きました。残り2人は、他のチームから来た方に説明する係。
他のチームでは以下のような意見が出てました。
●柔軟性を持たせたほうが良いもの
・開発場所
・仕様
・ルール
・チームメンバ（例えば、ピンポイントでデザイナーさんを呼んでくるとか）
●柔軟性を持たせないほうが良いもの
・チームメンバ（アジャイルはチームメンバをあまり変えないほうが良いとしている）
・ルール変更のためのルール
・コアタイム
・信念
■「ヒヤリングする側」と「伝える側」の成功として、あなたは何を定義したか？
・皆さん、共有の場でどういうことに貢献しようとしましたか？
・それは私（江端さん）の意図と一致しているか？
・なぜ、「どういう役割をこなせばいいのか」と私（江端さん）に確認しに行く選択をしなかったのか？
・「聞くまでもない」という考えが、皆さん常識としてあったのでは？
・では、あなたの常識をどう証明しますか？
■間違っていることを証明するのは難しくない。正しいことを証明するのは難しい。
・「お客様に聞けば良い」という文脈で、「確認する」という文脈は思い浮かばない。これが罠。
・互いに「なぜ教えてくれないのか」、「なぜ分かってくれないのか」となる。この齟齬は何か？
・それではお互い繋がりっこないが、お互いに言い分がある。
・果たしてそれでコミュニケーションが成立しますか？
・真剣にやってるほど、そうなってしまう。相手に「こうして欲しい」となってしまう。
・「当たり前だろ」となってしまう、そここそが問題なんだ。
■柔軟性と適当は同じではない
・どこを疎として、どこを密とするかの戦略が無いと、ものごとは上手く進まない。
・どこにボトルネックを持たせるのか、持たせないのか、を考えること。
・「当たり前」に気づけることが大事。
・出会いや縁は偶然だが、学んだり経験することは自分から機会を持っていける。
・柔軟性を考える上で、直感に従うと間違っていることが多い。
・人間が考える「常識」には、罠がある。そこに気付けるかどうか。
■３．ものごとの賞味期限（消費期限）
■ものごとには賞味期限がある。では、賞味期限のないものはあるか？
この問いに対し、参加者から出た意見は以下。
・信念、ポリシー
・でも信念やポリシーは時代の移り変わりによって変わるのでは。
・普遍なものはない、という考えは普遍。
■ものごとに賞味期限がある場合、それをどう計測しているか？
・何かを変えるために、何かを計測していますか？それとも、闇雲？
・何か判断軸があるはずでは？
■PDCAサイクルは意識しないと回せない
・プロジェクトの最後にやる「振り返り」を活かしたのはどれくらいありますか？
・なぜ「振り返り」をするのに改善できないのか？
・それは、仮説検証をしていないから。
・明文化せず勝手に思い込んでることが原因になる。
・気づいたこと、考えにも、維持するための期限がある。
・チャンスを活かすにも期限はある。
・インパクトだけじゃなく、改善までに取り込む時間に法則がある。
・改善が可能な時間を超えると、改善することができなくなる。
・それは、日々の雑務よって遠くなる。
・改善しないといけないこと以外は雑務。活かすこと以外は雑務。
■４．まとめ
・今日の話は、どのプロジェクトにも共通だからテーマとして選んだ。
・プロジェクトに最初、ルールがないのに、途中から「あたりまえ」という言葉が出てくる。そうじゃない。
・持ってる情報には期限がある。情報は持っているだけじゃダメなんだ。
・人間がもっとも思考しにくい部分が今日の話のテーマ。
・関わるのが人間である限り、今日のテーマは世界中でもあまり変わらないことがわかった。
・なので、しばらくは日本で活動しようと思っている。光石探しに世界に出たが、なにひとつ無かった。
・整理する、定義していくことが日本人はあまりにもヘタ。
・ルール決める１つとっても、海外は「とりあえず決める」。
・日本は、ルールが嫌になると、勝手に守らなくなる。それって「柔軟」とは違うよね。
・そこに気付いて改善してくことがプロジェクトの成功率を高めていくと思う。
・プロジェクトの振り返りを活かせないのは世界共通。
・期限があるなら計測しましょう。検証しましょう。
・成功しないプロジェクトは、仕組みがイケてない。上手くいかないときは、仕組みを変えるべき。
・考えるプロセスも仕組みの１つ。考える順番だったり、人との接し方とかも仕組みの１つ。
・感情面はコントロールできない。でもそういう感情にならない仕組みは取り入れていけるのでは。
・変えるべきは「仕組み」なんだ。
★感想：
非常に興味深い切り口のワークショップでした。
心の奥底に踏み込むというか。。。ｗ
ハッ！とさせられるキーワードも多かったですねー。「情報や改善には期限がある」なんて、グサッと。
例えば勉強会で学んだ知識もINPUTばっかじゃダメで、実践を通してOUTPUTしたりしていかないと、いつかは「期限」を迎えるわけで。。。
この日のワークショップで学んだ知識も、活かせるまでの期限があるわけで。。。
あと、常識を疑う、という点が実に興味深い動作だ。
何かの判断を下す際、自分という存在から一歩引いて、第三者の視点とか立場の異なる人の視点から物事を考え直してみる、というプロセスを個人的には意識してみようと思いました。
あと、やっぱ自分1人では気付けないことも多々ありそうで、他の人の考えを参考に自分の下した判断や常識を補正する、というのも必要そうです。
@makopi23よ！今後は決断する前に一度、常識を疑え！
講師の江端さん、参加者の皆さん、ありがとうございました。
あ、あと折り畳み傘、ようやく回収できたよ。。。
明日のTry： 折り畳み傘を今度こそ持って帰る。。。 #agilesamurai #横浜道場
— makopi23 (@makopi23) August 26, 2013
- 関連記事
-
- 「DAD読書会#2」に参加しました
- 横浜道場 特別編 「Challenge our Product Development's Assumption Change! ～ adapt PDAC to PDCA ～」に参加しました
- JJUG ハンズオン祭り 「Java EE 7ハンズオン」に参加しました
