Agile Japan 2010 Day2に行ってきました
てくてくセミナ参加してみました。
考えながらメモっていたので間違ってるところもあるかも。
なお土曜だけです。
キーノート：アジャイルの現状と未来、次にくるもの〜リーン開発への展望〜
講演：Alan 氏
同時訳：平鍋氏
Twitterのつぶやきが前スライドに表示されてます。なう。
カッコ書きは私の補足です。
- バリューストリームマップ
- XPとScrumが人気
- そこにマネジメントはないと思われている
- ScrumもXPも1プロジェクトに着目したもの。
- Agileは広がっているが、企業レベルではうまくいってない
- 今私たちが必要なのはチームアジリティではなく*ビジネス・アジリティ*
- 企業に拡げるには原則を明示する
プロダクトポートフォリオマネジメントをする。そのためにLean思考をする
*「速く提供する」の意味は、「ディレイを無くす」こと。これは一緒ではない。速く行くだけではエラーを起こす。効果的に動くことがムダがない＝ディレイがないということ*
- ルールは必要だが、そこに着目するのはクリエィティビティを損なうことではない
- 何か問題があれば人の責任ではなくシステム、つまる仕事の環境の責任
- 顧客には早くやりたいことがある。待っている。だから開発者を急かせる。
- そこでマネジメントの役割が出てくる。人を忙しくさせることがマネジメントではない。効果的に動かすことがマネジメント（←このセリフはものすごいつぶやかれてた）
- これがリーン。
- プロダクトポートフォリオマネジメント
- ビジネス価値に注目
- チームに負荷を掛けすぎない
- つまり要らないものを作り出さないようにする（仕掛かり品の削減）。
無用なものを作り出す仕事を作り出さない。例えば、
- このディレイによって、あとから仕事を作り出してしまう。（結合テストでのバグ大爆発とか）
- 本当のインテグレーションエラーは少ない。ホントは2つのチームがずっと前にコミュニケーションできなかったことによるもの。
（ってことは要件定義ちゃんとやれってことになるのでは？？？）
- 速くやる・自動化は大事だが、遅れを除去することの方が大事。ただしこれは難しい。
- 大事なことは生産性ではなく遅れを作り出している仕事を見つけること。一つやり始めて完成させるというサイクルを繰り返す。
- プロジェクトレベルではScrum/XPで対応できる
- 企業レベルではプロジェクトが5つも6つもあったらなかなかそうはいかない。1つのチームでは出来ても複数のチームではできない。チームに降りかかっている複数のことマネジメントすることが必要。
- チームが沢山のことをいっぺんにやるのではなく、一つづつ出来るようにする。これがマネジメントの役割。
- ウォーターフォールでやらないといけないこともあるが、できる限り避けたい。
- 価値×時間のグラフが一次直線になるようにするのがマシな道。（アジャイルは最初から価値を提供するがウォーターフォールは最後の最後まで価値を提供できない）
- なのでAgileとウォーターフォールをブレンドする
実際にどうやるのか。
- Epic（複数のユーザストーリーのカテゴリのようなもの）に対して、ビジネス価値が細かくなるように小さなストーリーに分割する。それを優先度付けしてマイルストーンにいれていく。（1回のマイルストーンで、あるEpicの全てが完了しなくても良い）
- これまでの4つの産業パラダイム
バリューストリームをなす3つの要素
- ビジネス：価値
- チーム：開発
- マネジメント：フロー
質疑
ムダというが有能な開発者は色々試してみたくなるものだ。どういうものがムダなのか。
→そういうのはムダではない。製造業ではなくソフトウェア開発というクリエイティブな仕事ではムダというのは定義しづらい。どちらかというと遅れをとるというほうが正しい。
→最近、TSPで使っていた言葉を使うとソフトウェア開発には意味が違ってしまう言葉があることが分かっている。言語化の問題だが、私はムダとりというより遅れを取るというほうが適切だと思っている。
特に上位の管理者になるほど言葉が通じないことが多い。説得するには。
→あなたが始められるところから始めるのが良い。ステークホルダを巻き込むのは重要だが、それよりチームを改善することを優先したほうがよい。
ステークホルダを教育するというのも手である。ステークホルダがボトルネックになるのであればそれは良くない。
顧客が複数居る場合はどうすればいいのか。
→顧客に迅速に提供できる小さい価値を順番に提供するのがよい。
もうひとつ、すべての顧客が等しく重要なわけではない。
ビジネス上、重要な顧客がいるということもある。その場合、その顧客を優先することはある。
各工程で品質の担保をするという制度が会社にある場合、どのように品質を担保するのか。分析する方法はあるか。
→QA部門にはバグを見つけるのではなく問題を見つけてくれと言った。ウォーターフォールでも同じくテスタが仕様を理解しておくのは重要。これがQAを通過する条件。これはカンバンで解決する。（分析については言及なしだったかと）
非ウォーターフォール型開発に関する調査結果と課題
講演：伊久美氏
請負契約と準委任がそれぞれ1/3位ある。後は社内開発か混在。
（下請法に違反しないのか？やや疑問…）
（質疑なしで終了。ちょっと聞いてみたいことがあったのですが残念）
かんばんゲーム
ワークショップ
最初にAlan氏から10分ほど導入の説明。
- バリューストリームマップを書くと、実際に手を動かしている時間よりずっと時間がかかっている。これは割り込みだったり待ちだったりする。
- どうしてそこがボトルネックになるのか分析し、ステージ（例えばテストで滞留しているなら、テストケース作成というステージを作って分割してみる）
ゲームは結構考えられていて、特に第三ゲームの意味を後から説明されたのだけれど、みんな納得。これは会社で試してみよう。
（知らずにプレイしたほうがいいのでここには書きません。）
成長する組織へ導くコミュニケーション変革
対話セッション
- シリウステクノロジーズ
- ブレインラボ
2社の経営者（といってもウチの経営者の半分も生きてなさそうですが）と認定スクラムマスターのペアがお題に沿ってトークしていました。
Scrum導入前
お客様からクレームが多かったことによる経営層の態度は
→怒りました。（ブレインラボ）
→怒る感じではないが、見捨てられる視線があった（シリウス）
Scrumとのファーストコンタクト
XPをやろうとしたが、勉強していく上で比較的導入しやすそうなScrumにした（ブレインラボ）
前に西海岸に居たが、そのときScrumを失敗していた。が、書籍を読んだら良いことが書いてあるのでまたやってみた（シリウス）
Q）どのように勉強したか？
自学自習していたが、スクラムマスター認定（CSM）を受けて良く理解した。（ブレインラボ）
書籍で勉強した。Agile Project Management with Scrum, Ken Schwaber, Microsoft Pressを読んだ（シリウス）
ただし、本で学べることは多くないので人間的な経験的なところからの学びが多い（シリウス）
導入までの物語
上司に飲み会でScrumの導入を説得。その後、チームメンバーに説明して導入（ブレインラボ）
プレゼンテーションを作って、開発チーム、ビジネスチーム、マネージャー層に対してプレゼン。会社課題の解決の糸口になることを説明（シリウス）
→プレゼンのときに、最初は大変であることをきちんといって期待値を下げておいた。またScrumの練習期間を設けた（シリウス）
→無難なプロジェクトを選んでやった（ブレインラボ）
アジャイルコーチや外部コンサルをいれたか
いれてない。本で十分だろうと思っていた。が、このあと*色々問題が起きて、コーチをいれた*（シリウス）
コーチはお願いしていない。コミュニティから知識を得た（ブレインラボ）
Q）今から振り返っての反省点はあるか
ない。頑張った俺的な。（ブレインラボ）
本は良かったが、やり方のフレームワークであって具体的ではない。組織固有の問題があればチューニングをしないといけない。それに気づかなかった。（シリウス）
→Scrumをやるとすぐ成果がでるが、その後ひずみがでる。これはトラップだと思っている。（シリウス）
導入に至るまでどのくらいのステップ・期間が必要だったか。
1ヶ月くらいで始められた（ブレインラボ）
3週間くらい。本を本格的に読み始めたときからプロダクトバックログを作るためのテンプレートを作り、練習スプリントを始める前くらいまでの期間（シリウス）
Ｑ）プロダクトバックログとは
→機能のリスト。（シリウス）
Ｑ）今Scrumをやろうとするとき、コーチをいきなりいれるのが適切か
→1回やって問題点がでて、自組織の問題点が見えてからコーチをいれた方が良いと思う。（シリウス1）
→最初にコーチが来ると、「考え方はコーチから教えられるものだ」とメンバーが思ってしまう。（シリウス2）
導入に至るまでに理不尽を感じたことは
保守的な人がいた。保守的な人たちから共感を引き出すのが大変だった（ブレインラボ）
Q）抵抗勢力があったとして、今から思うとどう対処するか
今のチームにも昔は保守的だった人がいる。
でも今はそういう人は今は推進派になっている。
チームのスプリントプランニングの時間を開発に回した方が良いと思っている人がいた。
そのときは上手く回っていたのでチームでばらばらで良いことにした。
ただし、やってしまったらリスクがある（他の人がなにをやっているかわからん）ことは分かっていながら任した。
チームの多数決を取ったらこのままやりたいとなったので、抵抗勢力の人もじゃあみんなが、と思っているならと協力的になった（ブレインラボ）
開発チームの中と外があるが、外の人は正しく説明することで抵抗する理由を解きほぐしてあげればよい。
開発チームの中は難しい。これは2段階で対応する。まずは、こういう問題を解決しようとしてこうしたいと説明する。
2段階目はやらせてみて失敗したら振り返りで直す。Scrumの良いところは振り返りで悪いところを見つけられるところ。（シリウス）
Q）向いている規模や受注形態は
規模はちっさくてやったことのある、お客様と信頼関係があるもの（ブレインラボ）
サイズ・お客様からの期待をマネジメントできるかどうか。
サイズは1チームでやるのがやりやすい。数名。3-4名で回せる規模。
お客様からの期待は多少失敗しても（リリースを守るのはできるが機能スコープが落ちることがある）問題が少ないところがよい（シリウス1）
→期間は長い方がスキルが上がるのでよい。超短期はウォーターフォールの方がいいかも（シリウス2）
（Scrumを、試行錯誤によってチームを強靭にするツールとしてとらえているがゆえの発言なんでしょう。たぶんですが）
導入直後の失敗
スプリントプランニングに失敗した。積極的に発言してもらえなかった。タスクのサインアップもなかった。（ブレインラボ）
最初のチームは小さかったのでうまくいった。が、2チームにスケールしたらいきなり失敗した。スプリントで約束したことが全然できないことに気づいた。
そのときはフロントエンドチームとバックエンドチームに分けたがこれが良くなかった。このときコンサルをいれたらボロボロにダメなところが出てきた。
また、プロダクトオーナーとスクラムマスターを1人が兼任したがこれ相反する立場なので一緒の人が行ってはいけない。
今の本を読むと色々書いてあって良いが、古い本（2004）を参考にしたので失敗が多かった。
プロダクトバックログは最初は機能リストになるが、進むと機能リストではダメになる。*ビジネスニーズの抽出として行うことが大事*。
*これはプロダクトオーナーのスキルが試される。これが出来ないとプロダクトオーナーが会社の価値を提供できなくなる日が来る。*（シリウス）
（これはかなり難しいのですが、後でミルズ氏に聞いてみたところプロダクトオーナーの教育か、直接開発者がアクセスできるようにして聞き出すしかないとのことです。）
予想していなかった一番大きな問題は
脱落者が出た。チームの求められている行動ができないと言って外れた。（ブレインラボ）
本で会得するのは難しい。教科書通りにやっていた。何かの問題が起きた場合に教科書が正しくて我々に問題があると思ってしまい、間違いの発見が遅れた（シリウス1）
仕事を向上させようという気持ちを持つメンバーが思ったより少ない。（シリウス2）
Q）チームが成果を上げたときにどういう風に褒めているか。
特にScrumだからといって変えていないが慰労会をやる。導入後で違うのは個々人に自発的に動けている感じがあったので各自のがんばりみたいなものが分かる。話せる。それを共有する。（ブレインラボ）
ありがとうという。またビジネス的な意義をきちんと伝える。（シリウス）
スプリントレビューで拍手する（シリウス）
垂れ幕に「ありがとう」というのを書けている。最近は増えすぎて神社みたいになっている。（ブレインラボ）
振り返りをカフェでやったり雰囲気を変えてやってみる。（シリウス）
プロダクトバックログ・スプリントバックログ
プロダクトバックログはお手製Webツール。スプリントバックログはExcelでやっている。（ブレインラボ）
Google DocsのスプレッドシートExcelでやっている。スプレッドシートが一番（シリウス）
（これは個人的にちょっとおもしろいと思いました。各社アジャイル対応ツールと銘打って販売競争があるなかスプレッドシートで良いとの意見。時間がなくてこれ以上の深入りはしませんでしたがツール導入となるとアジリティが遅くなるし面倒なのでしょうか）
成長を感じたことは
守破離の大切さ。
*指示型マネジメントではメンバーは指示待ちになる*。（ブレインラボ）
Scrumの背後の考え方を習慣化することで経営者として必要な資質の一部が身につく。
人事の制度（採用基準・採用プロセス・人事プラン・評価制度）などもScrumにあわせて設計した（シリウス1）
リーダーシップなども身についた（シリウス2）
採用の設計制度を見直すというのはScrumにはファシリテーション・ロジカルシンキング・クリティカルシンキングなどが必要で、そういうものがないとパフォーマンスが発揮できない。なので採用のときにそれらを試してコーディング力だけでは入社できないことにした。（シリウス1）
上手く回ったと感じているメリット・デメリット
チームの自発性が向上した。なぜこれを開発しなければいけないのか。なぜこれが必要なのかを理解するようになった。
毎週金曜に勉強会をきちんと計画通りにやるなどの学習サイクルが生まれた（ブレインラボ）
チームに活気が出る。他の会社から見学にくると必ず言われる。他部門に信頼されるようになる。（シリウス）
必要十分のペースで開発できるようになる。（シリウス）
デメリットは、ストイックになってしまうこと。生産性が上がりすぎて、一見ムダにも見えるアイディアの芽をつみ取ることになる（キーノートの例）可能性がある。
コーポーレートレベルで色々変えないといけない。会社レベルで変化する覚悟が必要。（シリウス1）
プロダクトオーナーのコミュニケーション負荷が高い（シリウス2）
Q）気持ちの維持や盛り上げる技は。
過剰なまでに褒める。だんだん連鎖していく。（ブレインラボ1）
キーマンの心を折れさせない。経営者として認めていることを伝える（ブレインラボ2）
ふざけること。Scrumマスターのテンションをあげていること。（シリウス1）
チームが問題を抱えているときに振り返りで出てくるのでそれをくみ取る。
時々ゆるんできたなと思ってきたら少し先のビジネス状況を伝えて頑張ってほしいことを伝える。
プロダクトオーナーの責任できちんとビジネス意義を伝える。（シリウス2）
（やっぱりプロダクトオーナーが1番大変な気がしますね。。。）
最後に
Scrumですべてが解決しているとは思わないが、寄りかかれるイイフレームワーク。
Scrumやってみたいなーと思った人は、まずこうやってみて欲しい。
スプリントを2週間に設定して、最初の始まりでこの2週間でやることをチームで話してみる。
2週間の最後に振り返りをやってみる。そのとき、反省からかならずアクションを1つか2つだけチョイスする。多すぎるとできないので。
次の週で必ずそれを試してみる。これを繰り返すといつかScrumになる。と、思う。（シリウス1）
Scrumを会社として正しく導入すると会社のビジネスに直結して、チームが良いチームになる。
最初、経営陣はウチの開発チームはダメだと言っていたが、今は最大の資産だと思っている。
Scrumのコンサルテーションは高いがリターンの方が多い。（シリウス2）
個別インタビュー（ブレインラボ榎本氏）
チームの規模は？
→20名程度
契約形態は？
→請負。ただし途中で要件をある程度変えられるようにしている。その場合はブロダクトバックログから優先度の低いものをドロップしてもらう。
それでお客様との関係は悪くならないのか
→途中で要件を変えられるということにメリットを感じてもらっている。お客様の業種的に官公庁のようなきっちりしたプロセスではなくスピードにビジネスメリットを感じるところが多いというのもあるかもしれない。
最初にプロダクトバックログを作る時にどうしてこれがthat's allだと言える、またはお客様にご説明できるのか
→他の方法を使っても完璧な要件は確定できない。
お客様がプロダクトオーナーとして忙しくなるがどのようにご理解いただいたか
→元々こまめなレビューなどのコミュニケーションがあったためそんなに違和感は無かった。
→お客様の中には以前はウォーターフォールで開発されていた方もおり、どんどん実装が進むので逆に安心されるようだ。
そういうお客様は普通最初に出て来るものは設計書と思っていると思うが、設計書はどの程度書いているのか
→画面キャプチャやロジックの設計書はほとんど書かない。プロダクトバックログを一生懸命説明する。
ミルズ氏個別インタビュー
（手元にメモがないので後で書きます）
個別質問が長引いてしまったのでクロージング出れず…
ちなみにワークショップで一緒になった人は口を揃えて野中教授（有名なSECIモデルの方です）の講演が面白かったと言ってました。やっぱり金曜も申し込んとけばよかったなー。
