fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「XP祭り関西2014 ～ やってみよう！XP ～」に参加しました

2014/4/26(土) 「XP祭り関西2014 ～ やってみよう！XP ～」に参加してきました。

DoorKeeper
http://xpjug.doorkeeper.jp/events/9030

Togetter
http://togetter.com/li/659934

場所は大阪市鶴見区民センターです。
参加者は50人くらいでしょうか。



東京在住の私が2年連続で参加できたのは、ちょうどＧＷ帰省の初日に開催されたからなのです。
朝7時くらいの品川発-新大阪着の新幹線に乗り、新大阪駅からJRと地下鉄を乗り継いで30分くらいかな？

ちなみに去年書いたブログはこちら。

「XP祭り関西2013」に参加しました
http://makopi23.blog.fc2.com/blog-entry-72.html

もう1年経ったんですねぇ。
ということで、取ったメモを自分の復習用にダラダラと書き起こしてみる。

■オープニングセッション
「わかりやすいアジャイル開発の教科書 ～ 教科書の向こうに何が見えてますか？ ～」

書籍「わかりやすいアジャイル開発の教科書」の著者3名が、参加者のアジャイルに関するご質問、お悩み、課題などに答えていくセッションです。

わかりやすいアジャイル開発の教科書わかりやすいアジャイル開発の教科書
(2013/03/28)
前川 直也、西河 誠 他

商品詳細を見る

以下、個人メモ。

Q1.
  • 要件や仕様が確定しないと進めない、レビューが完了しないと先へ進めない現場がある。
  • でも、アジャイルだとそれはマイクロPDCAになってしまう。
  • がんじがらめの組織の場合にアジャイルをどう導入していけば良いか？

A1-1. 細谷さん
  • 「Doneの定義」を満たすことで「完了」にしますよ、といったように、プロセスを明確にしている。
  • ステップの管理という意味では、ステップは小さくするようにしている。
  • 今の現場は、１～2ヶ月単位で第三者検証を実施しているが、計画がミソ。
  • アジャイルの計画を立てて、それを第三者検証の担当者と合意をして、各フェーズにメトリクスを設定し１～2ヶ月単位で検証していく。
  • キモは、プロセス検証をしてる人とどう合意できるか、という点である。

A1-2. 前川さん
  • 重いことをやっている間にどんどん変わる。
  • どんどん仕様が変わっていかないと勝てない。
  • でも好きなようにやらせるとバグだらけになる。
  • なのでタイムボックスを切って、動くものを出していく。
  • 現物を見て、直すということを繰り返す。
  • QAの人にも早く入ってもらう。
  • それを経営者がそろそろ気づいている。なので現場も「やりましょうよ」と変えていかないといけない。

A1-3. 細谷さん
  • やり方を変えなきゃいけないと気づいてないケースがけっこうある。

A1-4. 西河さん
  • スマフォ開発はウォーターフォールでやってる間にOSのバージョンが上がる。
  • メーカーもそれに合わせて対応していかないといけない。
  • 各プロセスをちゃんと通らせるが、そこにどう変更プロセスを組み込むかが大事。
  • 変更プロセスを仕組みとしてちゃんと組み込むようにしている。



Q2.
  • アジャイルって少数精鋭？

A2-1. 西河さん
  • 新入社員のころからアジャイルが当たり前になるように、仕組みでアジャイルな組織にしている。

A2-2. 前川さん
  • 少数誠意なのはウォーターフォールもアジャイルも一緒では。
  • 成長していくアプローチができるのがアジャイルのいいところ。
  • 小学校や中学校が30人クラスだからといって、人が成長しないわけではない。
  • 100人で「なんちゃってスクラム」を回しているが、小さいサブユニットが複数できるのでチームは少人数になる。

A2-3. 細谷さん
  • いかに成長していくチーム作りをするかが重要。
  • 現場で実践すること。
  • １つ１つのことをチームでしっかり見ていくこと。
  • ストーリーカードを詳細化するときには、チームで話し合う。
  • 設計はホワイトボードの前にチームで集まって話し合おう。
  • コーディングはペアプロとTDDを取り入れ、コミット時にはレビューをする。
  • 振り返りをしっかりやる。
  • 少人数は結果。１つ１つをしっかり見ていけるチームじゃないと成長できないし、品質も保てない。



Q3.
  • 考え方の古い管理職をどう指導していけばいいか？
  • PO的に暖かく見守ってくれる人になってほしいが、どうすればいいか？

A3-1. 細谷さん
  • 相手がどんな価値観を持ってるかをよく理解する必要がある。
  • チームが活き活き働いて、成功して、自分が評価される、というのを嫌という人はあまりいない。
  • そこは共有できるはず。
  • でもアジャイルを提案すると「嫌」という人は、何かリスクを感じてるはず。そこを観察するのはすごく大事。
  • アジャイルをネガティブに思ってる間は、アジャイルに否定的である。でもポジティブに感じ始めると上手く回りだす。
  • 小さい成功をプロモーションするのが結構大事。
  • エンジニアはプロモーションあんまりしない。そうじゃなく、上手くいったことを伝えて、ちゃんと広げること。
  • チームメンバーのプロモーションも大事。お互いのいいところを口にだして共有すること。

A3-2. 西河さん
  • アジャイルは「やる」ものでなくて、「組織が成る」もの。
  • 「やりましょう」じゃなくて、「なりましょう」。
  • 作るものの価値を最大化することが最大の目的。
  • その価値を達成するための行動を定めているのがＸＰとかアジャイル。
  • 上司は説得するものではなく、なるもの。価値観を共有すること。
  • プラクティスから入るより、飴ちゃんを机に置くだけでもアジャイルは始まる。それだけでもほんわかするよね。

A3-3. 前川さん
  • オンサイト顧客でストーリーを書きましょう、というのと一緒。
  • 互いの価値を共有すること。

A3-4. 細谷さん
  • 急に変えれないことは、変えれない。
  • すぐに変えれることは、すぐにやればいい。
  • アジリティを高めていくことを際限なくやり続ける。
  • 今よりも少しだけアジリティを高め、実行して結果を出しましょう。
  • それをずっとやり続けること。


Q4.[失敗談、デメリット] 
  • なんでも変更を受け付けてきて、責任が曖昧になって地獄になることがあるが、どーすれば。

A4-1.
  • その機能ってホントに使うんですか？と踏み込むのがアジャイル。
  • やりたいことはいっぱいあるけど、機能的に、、提供時期までにホントに全部必要なのか？
  • その機能だったらリーズナブルにこの期間で届けられますよ、と導いていく。
  • お客さんの予算で最大の価値を届けるようにすること。
  • ストーリーの優先順位がシビアになることが多いが、優先順位を3つのカテゴリに分けるようにしている。
    • １．法律違反とか、ぜったいやらないと存在しえない
    • ２．これやらないと価値がない
    • ３．その他
  • 優先度をA,B,Cと3段階に分けるのは良くない。優先度は主観が入るし、属人性がある。
  • 誰の目にも分かるように、「カテゴリ」に分類すること。
  • 優先順位を付けるのではなく、３つのカテゴリに分類してください、と持っていく。
  • カテゴリ分けをやっている間に、お客さんが優先順位に気づいてくる。
  • それを元に交渉して、プロダクトバックログに落としていく。

A4-2. 前川さん
  • 責任どーするの？と曖昧になることある。
  • 責任を取らないといけないのは、POとかマネージャ層。
  • POやマネージャに、チームメンバがひっきりなしに聞きに来るので、面倒くさい。
  • んじゃ、ドキュメントに書きゃいいじゃん。
  • 何のためにドキュメントを作るのかを書くこと。
  • アジャイルって面倒くさい。でも、メンバーが成長してくれれば良いと思う。


Q5.
  • 印税はいくらくらい？

A5.
  • 書籍の値段を下げるため、細谷さんと西河さんは印税を貰っていない。
  • 前川さんは、印税で家族を旅行に連れて行くという目的を最初に立てたので、少しだけ貰っている。
  • コンビニでバイトしたほうが儲かる。


お題
  • 書籍に「Smiling Adventure」という章がある。これは前川さんの案で書いた。
  • 「お客様は誰？」、「誰のために作ってるの？」という問いに、結構即答できないことがある。
  • 第一歩は「お客様は誰か」を把握すること。
  • 次に「そのお客様にとっての最大の価値は何か」を考える。
  • 何からアジャイルを始めたら良いかを考える際は、この２つの議論をチームで話すことから始めたらいいのでは。
  • お客さんのhappyを考えてそれを実現したら、あなたはどう思いますか？
  • そこまで考えるようになると、チームのモチベーションが変わってくる。

Q6.
  • 書籍を書いて良かったことは？

A6-1. 前川さん
  • 普段思っていたことを書けたこと。「読んでください」と言えるのが良い。

A6-2. 細谷さん
  • 「Fealess Change」という書籍に「モノを渡すことが大事だよ」という、「トークン」というパターンがある。
  • なので、形になってるのは偉大だと思った。

A6-. 西河さん
  • 日本のアジャイルってやっぱあると感じる。
  • そういうものを考えて、本に纏めるために深く考えることができたのが良かった。

---
Q&Aの一場面はこんなカンジ。

20140426_xpjugkansai1.jpg

■アジャイル和室

お昼休みに、別室に設けられている「アジャイル和室」にも行ってきました。
参加者の皆さんが「アジャイルかるた」なるものをやってました。

20140426_xpjugkansai2.jpg

読み上げるカードには「Redmine」といった単語と、その説明が書いてあります。
それを読み上げて、「R」のカードを参加者が探して取る、といった具合です。

20140426_xpjugkansai3.jpg


そういや去年は「アジャイル双六」でしたねぇ。
あと、コンセントを借りてPCの充電をさせていただきました。
こっから午後セッション。だらだらメモを書き起こしてみる。

■講演１　今日から始めようXP

稲田信平さん

■　そもそも、グローバルに働くとは？
  • 英語が出来ることではない！
  • 「どこでも通用できる働き方がグローバルな働き方」だと自分で定義している。

■　これからXPを始める方へ
  • 肩の力を抜く
    • IT業界のエンジニアって、みんな真面目で頑張っちゃう人が多い。
    • なので「それ以上はやらないで」と止めるようにしている。
    • やらないでいいことをやりすぎると、本来やらないといけないことができなくなる。
  • 常にアラートを出すようにしてもらう。
    • アラートを出さない人には怒るようにしている。
  • 教科書どおりにやらない
  • でも知識として知っておく必要がある。

■　ビジネスモデルの作成
  • ビジネスモデルを書いて、クライアントと方針を決めた。
  • ビジネスモデルはどんな立場でも書ける。
  • ビジネスモデルは、誰がどういうことをするかを掴みやすくする図。
  • 仕様変更って、プログラマの立場からするとピンポイントで来る。
  • それをピンポイントに修正しだすと、コードベースがぐちゃぐちゃになってしまう。
  • その仕様変更が正しいかどうかを判断するために、ビジネスモデルのどこに埋め込むのが正しいかを判断する必要がある。


■ 取り入れたXPのプラクティス
  • リファクタリング
    • ソースコードをチームで共有するためには、ソースを綺麗に保つ必要があった。
  • ペアプロ
    • ペアプロを応用して、リーダーと設計者で「ペア詳細設計」をやった。
    • プログラミング以外でもコミュニケーションをとって仕事をしてくれるようになった。
  • 朝会
    • 朝会でアラートを出してもらう。
    • デスマになる時は、独りで仕事や悩みを抱え込むことが多い。
    • 　なので、アラートを出すタイミングは「朝会」の場であると指示していた。

■　機能ごと設計・開発（ぜんぶ作らない）
  • まずゴールがあって、それまでにどんだけ作らないといけないかがある。
  • これを考慮しないと、一方だけ高機能で、もう一方が低機能、みたいになってしまう。
  • 必要なものから作る。

■　ハイブリッド
  • 全体計画はウォーターフォールで、どこをゴールとするかを決める。
  • 細かく計画、開発を繰り返す。
  • アジャイルとウォーターフォールの良いトコ取りをすると良いものができる。

■　ＷＢＳは無視する
  • ＷＢＳの順番でやって絶対できないことがでる。
  • 重要なのは問題点を洗い出して共有すること
  • まずシンプルに設計段階で切って回す。

■　XPをやってみた気づき
  • ペアプロは人によることが大きい。理解度とか教育とかでいろいろある。
  • いろいろな形態があり、それに合わせることが可能。
  • 捨てることが重要。
  • はまりすぎないこと。ＷＢＳがあったら、この期間中にやらないと！って背負っちゃう。
  • できないことはできない、やらないことはやらない、という勇気が必要。

■　コツ
  • 目標を立てて仕事しよう
  • 短期的な目標でもいい。
  • 早く帰りたい、休みたい、色んな仕事をしたい、etc
  • それをよりよくしようとそれを目的にしちゃうとそこにハマってしまう
  • XPのプラクティスを完全ゴールにしちゃうと良くない
  • 経験の積み重ねが重要。

■　グローバルって？
  • 何処に行っても通用すること。
  • 何処に行ってもパフォーマンスが発揮できること。
  • XPは、言語依存じゃない、国依存じゃない。
  • どこでも使える、その根底がXP。

■　結論
  • グローバルにはXPは最高のプラクティス。

■　おまけ
  • 趣味を持ちましょう。
  • 人を作るのは仕事だけではない。

■講演２　ビジネスモデル・キャンバス入門

山中美智子さん

■ビジネスモデルって何？
  • どのように価値を創造し、顧客に届けるかを論理的に書いたもの
  • ビジネスモデルは営利企業とか以外でも、家庭とかでも使える。
  • 収益を上げ、体制を維持、発展させる活動を行うことに変わりはない。

■　ビジネスモデルを書く狙い
  • 見える化できる
  • 鳥瞰できる
  • 現在のビジネスモデルの分析と、新しいビジネスモデルの構築がしやすくなる

■　ビジネスモデルキャンバスとは
  • ビジネスモデルに必要な要素を1枚の絵に纏めたもの
  • ９つのセグメントに分かれている。
    • １．顧客セグメント
    • ２．価値提案
    • ３．チャネル
    • ４．顧客との関係
    • ５．収益の流れ
    • ６．リソース
    • ７．主要活動
    • ８．パートナー
    • ９．コスト構造

そういや、アジャイルサムライ横浜道場の特別編でビジネスモデルキャンバスを書いたことがあったなぁ。
そんとき書いたブログはこちら。

横浜道場　特別編 「現場で役立つ（かもしれない）ビジネスモデル・キャンバスのワークショップ」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-106.html

■講演３　XP入門と導入の壁についての話

平田大作さん

■　ソフトウェア開発は設計
  • 「リーンソフトウェア開発」という書籍に、「ソフトウェア開発は試行錯誤を含む学習プロセス」と書いてある。
  • この言葉は衝撃的だった。
  • ソフトウェア開発は、完璧に計画可能な「製造プロセス」ではない。

■　ソフトウェア開発は複雑で難しい
  • ソフトウェアの構成要素は言語である。
  • 言葉は物理的制約を受けない。この制約の無さが捉えどころの無い複雑さを生んでいるのでは。
  • 逆に、建築とかは物理的な制約を受ける。
  • ソフトウェア開発は測定できない。
  • 建築だと材料力学とかあって、性質とかは実験して測定できる。
  • モノは決まった性質しか示さないが、ソフトウェア開発はそういうところがない。
  • ＷＦでもＸＰでも、難しいものが簡単になるのではない。アプローチが変わるだけ。
  • 難しいものを相手にしていることを忘れないようにしよう。

■XPとは？
  • ５つの価値と１２のプラクティスから成る。最近は１２から拡張して１９のプラクティスと言われる。
  • ５つの価値は、迷ったときの判断基準になる。
  • 何かに迷ったり複数の選択肢があった場合は、この５つの価値に照らして活動を選択する
  • 陥りがちな５つの価値
    • １．ルール重視、ドキュメント重視
    • ２．機能を詰め込めばいい
    • ３．動くものは触るな
    • ４．波風を立てない
    • ５．権威

■　計画ゲームと小規模リリース
  • イテレーションに盛り込むものを計画ゲームで決める。ここがキモだと思っている。
  • 試行錯誤と学習の機会を与えてくれる。

■　小規模リリース
  • 2週間は、難しくても制御可能な期間である。タイムボックスを切る。
  • 計画ゲームが重要。
  • 計画ゲームはあまりしっくり来てなかったが、やってみると腑に落ちる。
  • 例えば前のバグの積み残しが後のイテレーションを圧迫すると、大変な開発になる。
  • こういったときに、イテレーションの前に計画ゲームを実施し、どれを入れるかをちゃんと決める必要がある。
  • 計画ゲームで負荷を制御する。
  • XPが「学習プロセス」というのは、イテレーションを繰り返すことによってどのくらいの難しさでどのくらいでできそうか、が段々わかってくる点にある。

■　テスト駆動開発
  • インタフェースを決めたらテストコードを書く。
  • テスト先に書くことで使い方の理解を得られる。
  • テスト駆動開発の注意点
    • テストコードの粒度を細かくしていると変更コストが増大する。
    • テストコードはインタフェース＝Public Methodに対して書く。

■　ペアプログラミング、共同所有権
(1) 利点
  • リアルタイムレビュー、強制的コミュニケーション
  • 品質、実力の底上げ
  • ばらつきが減る
  • シンクロ率アップ
  • 人の流動に対してフレキシブルになる。
(2) 注意点
  • かなりの労力が必要。
  • 向き不向き結構ある。

■　その他の話題
  • 開発全体の計画は必要。
  • ドキュメントは考えたことを伝える手段として必要。文書化の手間はかかるので、wikiでも充分。
  • 保守用ドキュメントは別途作成が必要。　

■　導入の壁
  • 「人の壁」の対策
    • 新人教育からＸＰを教える組織として変えていくのはこれがいいかなと思っている。
    • XPJUGに入ってもらう



■講演４　KPTによるプロセス改善～あなたはPDCAを回したことがありますか？

KPTによるプロセス改善～あなたはPDCAを回したことがありますか？ from akipii Oga
  • KPTはCAPDから回すべし。
  • 自分の考えを共有するよりも、自分以外の人間に景色がどう見えているのかを認識することが重要。
  • コンフリクトが起きたらKPTを実施して、意識して「雨降って地固まる」プロセスを通過させよう。


今回の講演について、あきぴーさんがブログに書いてます。




■ライトニング・トークス

3名の方によるLTです。

■ @sakaba37 さん
リーダー諸君！アジャイル開発を学び未来への道を切り開こう(XP祭り関西LT) from Makoto SAKAI

5分の枠が、まさかの3分半で終了。
残り1分30秒あまりを埋めるのに苦労するさかばさん。。。


■ @Chuki さん
  • 「わんくま同盟」で活動中。
  • 「コタツモデル」というのが出てきた。


■ 開原さん
XP祭り関西2014 LT やってみよう！スクラ○ from Takahiro Kaihara
  • スクラムを社内に取り入れるためのノウハウに関するLT～

★感想：
去年に引き続き今年も東京から参加したんですが、東京と大阪のノリの違いとか随所に感じられて楽しかったです。
参加者にカメラ役を任せたりとか、最後のクロージングの西さんの振る舞いとか、関西なんやな～とｗ
いや、私も実家が大阪腑箕面市なんですけどね。。。

来年も参加できるといいなぁ。
スタッフ、参加者の皆様、ありがとーございました。

関連記事

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://makopi23.blog.fc2.com/tb.php/139-8b58c286
この記事にトラックバックする(FC2ブログユーザー)

-->