Scrum talk at Agile Japan 2010
•
3 gostaram•976 visualizações
I presented a talk at Agile Japan 2010 conference on Scrum adoption in one of my previous jobs, as the first Certified Scrum Product Owner in Japan. The content is in Japanese.
Recomendados
Mais conteúdo relacionado
Semelhante a Scrum talk at Agile Japan 2010
Semelhante a Scrum talk at Agile Japan 2010 (20)
Scrum talk at Agile Japan 2010
- 3. モデレータ・演者紹介 安藤 連 取締役 認定スクラムプロダクトオーナー 永井 正樹 代表取締役COO ⾼橋 ⼀貴 認定スクラムマスター 榎本 明仁 認定スクラムマスター ■ ■ ■ ■
- 4. ■ 設⽴ 2002年11⽉（8期目） ■ 従業員 30名 ⼈材ビジネスへのトータルソリューション ■ ⼈材紹介会社向けコンサルティング、サポート業務 ■ ⼈材紹介システム（パッケージ）開発・販売業務 - CareerPlus ■ その他受託開発
- 9. QCD はどう ■Quality: お客様からのクレームが今と⽐べると 多かった ■Cost: 単⼀プロジェクトしか回せない状態 だったので、⽣産性はいまから⽐べる と低かったと思います。 ■Deliverly: まともに予定通り納品できた試しがな かった・・・ ■ Quality: 正常系は動く ■ Cost: ⾒積以上に開発コストがかかる ■ Delivery: 間に合う場合もある
- 10. ビジネスとしてうまくいっていましたか？ ■ 売上という意味ではうまくいって いたと思います。 ■ クレームが多かった ■ 大きめなプロジェクトは１つしか 回せなかった ■ それなりにうまく⾏っていたよう です。
- 11. メンバーに対して、 どのような想いを抱いていましたか？ ■ ⼀⼈⼀⼈を管理しないとだめ （経営者） ■ 頑張ってやっていたと思う （経営者） ■ もっと積極的になってほしい （経営者） ■ 多能⼯になってほしい（ミドル） ■ 他のメンバーの仕事は知らない （メンバー） ■ わが社の社員は自発性がない…と 思っていたはず ■ 設計・実装からテストまで⼀⼈であ る程度こなして欲しい ■ 技術不⾜のメンバーへの不満
- 12. コミュニケーションの形は？ ■ 経営者、マネージャに全てのコミ ニュケーションが集約されていた。 ■ ビジネスグループからの要望はマ ネージャーを経由してメンバーに届く。 その時点で、作業のリストに変換され ている。 ■ ツリー型：チーム・メンバー間の つながりはあまりない。
- 13. 学習に対する姿勢はどうでしたか？ ■ 要望があれば、会社負担での学習 も可能だった。自発的な活動を待っ ていた ■ 完全に個々⼈に依存している状態 で、チーム間での知識共有なども少 なかった。 ■ 社内にロールモデルが不在なので、 学習するインセンティブが希薄。 ■ プロジェクト (もしくはタスク)ド リブン学習 ■ 自発的にはやらなかった(メン バー談）
- 16. なぜスクラムを選択したか。 技法というよりも、まずは体制への 問題意識が強かったので、 XPやRUP よりもスクラムを選択 XPについてはScrumでついた基礎 体⼒の上で実践して⾏く事を考えてい ました。 リーンはスクラムの親で考え⽅は かなり共通していると思います。 ただ、スクラムの⽅がソフトウェア開 発に主眼がおかれているので導⼊が容 易だと感じていました。 直接のきっかけは、前の職場で失 敗しているのを⾒たこと。 当時組織が抱えていた課題： （1）自⽴⾏動するチーム ⇒ミドル層の知的資源を 他の事に活用。 （2）⼀体となって問題解決する チーム ⇒チームとして使える知的 資源増加 リーン vs. スクラム vs. XP そもそもこれら３つの間にconflicts は無い。
- 17. どのようにアジャイルを勉強しましたか？ ■ 本 ■ コミュニティ ■ CSM ■ 書籍 "Agile Project Management with Scrum" (Ken Schwaber, Microsoft Press) 前の職場（Scrumに失敗していた）で バイブル的な扱いをされていたので。 ■ 本 ("初めてのアジャイル開発"など) ■ Webサイト
- 21. 導⼊に⾄るまで、どれくらいの ステップ・期間が必要でしたか？ ■ CSMの前からすこしずつ本で読ん だ事をベースに⾊々試してみました が、本格的に始めたのはCSMを受け てからですね。 思い⽴ってから3週間ぐらい。 ■ 本を読みながらポイントを把握 ■ 社内向け説明スライド作成 ■ 社内向けプレゼンテーション数回 実施 ■ Product BacklogとSprint Backlog のテンプレートを作成 ■ 練習スプリント開始
- 23. (受⼊側への質問)導⼊を受け⼊れた理由と、 そこで抱いた不安について教えてください。 （経営） ■ 榎本がやりたいと積極的に提案して きたから。 ■ サボるのではないかは不安だった。 （チーム） ■ 榎本が積極的だったから。 ■ 変化に対する不安。 ■ 提案時点で既に経営層やビジネス グループは「開発チームを良くした い」と思っていた。 ■ もともと導⼊したかった ■ 組織だった開発マネジメントがさ れていなかったので、拒否する理由 がない ■ 組織とプロセスを⼀度に変えるこ との不安
- 24. (導⼊提案側への質問)受け⼊れてもらうために 使ったKnow-howについて教えてください。 ■ しつこさ ｗ ■ 準備を⼊念に （社内営業のつもりで） ■ 周囲を巻き込むこと （こちら側に引き⼊れる） ■ 榎本の⼼を折れさせないこと ■ 開発チームを取り巻く⼈たちが本当 に聞きたいことを伝えること。 ■ すなわち「私たち共通の問題を解決 しましょう」というトーンのコミュニ ケーションを⾏うこと。 「今の問題はこういうことです」 「この状況を改善するアプローチとし て、この枠組みを導⼊します。」 「この枠組みが状況を 改善する理由は こういうことです」 ・・・etc
- 25. 導⼊までにかかったコストについて 教えてください。 ■ CSMの受講料と本代 ■ 説得＋説明の時間 （トータルで16時間くらい） ■ スライドを作った時間（数時間） ■ プレゼンテーションセッション３ 回ぐらい ■ バックログのテンプレート作成と 共有⽅法を試⾏錯誤した数時間 ■ ramp-upのためのオーバーヘッド （1チーム1週間ぐらいの loss）
- 30. 予想していなかった⼀番大きな問題は？ ■ 変化を嫌う⼈の抵抗 （脱落者を出してしまった事） ■ Scrumの向こうにあるprinciple （Lean的なもの）は、実はScrumの書 籍１冊だけで会得するのが難しい（書 き切るのが難しい） ・・・ということに気づくのに相当時 間がかかった。 ■ 「我々は教科書の通りにやってい る」と思っていたため、多数の間違い の発⾒が遅れた ■ 仕事を向上させたいという気持ちを 持つメンバーは思ったより少ない
- 31. 導⼊直後の QCD はどうでしたか？ ■ もともとがヒドかったので、全⾯ 的に上がったと思います。 ■ 少なくとも当時は、⼯学的な要素 よりも、⼈間的な要素の改善が著しく ⾒られたという印象です。
- 32. スクラムが導⼊できた！と思った瞬間は？ ■ チームがスプリントバックログ用 のツールを自分たちで勝⼿に作り始 めた時。 【第1期】 ■ メンバーのsense of ownership や leadership が感じられた。 ■ メンバーが機能を提案してくれるよ うになった。（でも、そんな認識は今 考えると⽢かった。） 【第2期】 ■ チーム数を増やしてスケールしても ワークするようになった。 ■ メンバーからProduct Ownerへの 質問中の技術的要素が激減。 ■ Product OwnerによるStory cards の活用 ■ 形だけのふりかえりではなくなり、 ふりかえり→改善のサイクルが回り始 めたとき
- 36. 自分のどのような部分が成⻑したと 感じましたか？ ■ 観察する⼒を持つことができるよ うに なってきた。 ■ 守破離の大切の気づき ■ 指⽰型マネジメント ■ Scrumの背後にある考え⽅を習慣 化 ⇒ People managerとして、経営 者として、必要な資質の⼀部が⾝につ きます。 ■ 会社の採用基準、採用プロセス、 ⼈事プラン、評価制度もScrumに合わ せて設計 ⇒ 経営の⼈材的側⾯におい てユニークな経験が⾝につきました。 ■ エンジニアリングの部分というよ りは、⼈間的な成⻑が大きいと思いま す。
- 38. 実際にうまく回り始めて、今感じている メリット・デメリットを教えてください。 【メリット】 ■ 自発性が⽣まれた ■ 学習のサイクルが⽣まれた 【デメリット】 ■ スクラムマスターを育てるのが 大変 ■ 現状維持をしようと してしまう傾向がある 【メリット】 ■ チームに活気が出る（よく社外で感⼼される） ■ 社内の他部門に信頼される ■ ⽣産性あたりの施設コストが⼩さい ■ 品質を⼗分に確保できるペースで開発できる ■ 作業環境・⽅法を自分たちにあった⽅法に最適 化できる 【デメリット】 ■ 本質的にクリエーターであるエンジニアやデザ イナーにとって、クリエーター的衝動を否定しな ければいけない場⾯が多くなる ■ 戦略的な⼈材育成、獲得、評価プログラムが必 要になるので、コーポレートレベルでの変化能⼒ が必要 ■ ファシリティ的制限。大きなスペースが要る。 ■プロダクトオーナーのコミュニケーション負荷 が⾼い
- 39. QCDはどうなりましたか？ ■ 納期のズレや、顧客との仕様のズ レが無くなった ■ 導⼊当初のような劇的な変化は無 い ■ 少しずつ改善はされていると思う ■ Quality, Delivery は向上 ■ Cost はあまり変わらない ■ Q, Cの定量化はしていない ■ QCDすべてにおいて改善の余地は ある ■ 継続して改善
- 40. 今悩んでいることは何ですか？ それに対してどのような⾏動をしていますか？ ■ スクラムマスターが育ってない （ミドル） ■ 以下のような課題の唯⼀解は、 スクラム フレームワークには用意されて いないので、Principleは何だろうと考え ながら実験をしています。 1) 複数スクラムチーム間での隠れた dependencyを発⾒/通知する仕組み （Scrum Of Scrumsは万能ではない） 2) 複雑なStoryのデザインプロセスを、 組織内にどう実装するか。複雑な成果物 に対するResponsibilityをどう担保する か。 ■ メンバーのアジャイルマインド向上
- 41. 受け⼊れた⼈たちは、今はどう思っていますか？ ■ 任せることができる ■ ゴールが⾒えるようになった （チーム） ■ 経営陣は、スクラムチームが会社の 最も重要なassetのひとつだと捉えてい ます。 ■ ビジネスグループから⾒ても「以前 よりもずっと頼りになる」と思って もらえているはずです。 ■ メンバーの自主性が向上した ■ チームの規模に対して、コミュニ ケーションの質が良い ■ バックログアイテムを完了させた時 の感触が良い
- 42. メンバーは楽しく仕事をしていますか？ ■ 楽しんで仕事をしている⼈が多い 会社であるとは思いますが、どんど ん活発になってきていると思います。 ■ ただ、スクラムはチームにとって も厳しい⼿法だと思います。責任と 自⽴を求めるので。 ■ 基本的に、仕事が楽しくないという ⼈はうちの会社にはいないと思います。 ■ もちろん、先に述べた理由で時に ストイックさを求めるので、エンジニ ア的刺激が薄いと感じる場⾯はあるよ うです。 ■ 楽しくやっていると思います。ただ、 コミュニケーションの難しさを感じて いる時もあるようです。
- 44. メンバーに対してどのような想いを抱いて いますか？⼼境に変化はありましたか？ ■ 頼もしい。 ■ 自発性が⽣まれてきている。 （もっと自発性を育てていきたい） ■ 私自⾝（今は経営陣の1⼈）は、 Scrum teamの構成員達こそが弊社の 最大の売りだと思っています。 ■ 技術⼒の⾯で不安がなくなりまし た ■ メンバーの成⻑に貢献したいと思 うようになりました
- 45. コミュニケーションの形は？ ■ スター型からネットワーク型へ ■ ネットワーク型 x クラスタ
- 46. 学習に対する姿勢はどうですか？ ■ ⾦曜⽇の⼣⽅に勉強会が開催され るようになり、講師を持ち回りでや るようになっています。 ■ ペアプロをチームのメンバーが積 極的にやる場⾯が⾒えるようになっ てきています。 ■ TechTalkの内容はおもしろいもの が多いですね。 ■ 今後の学習課題が、明確になり、 学習の意欲が向上した。 ■ プロジェクトドリブンで勉強をす ることに変わりはない。
- 47. 今は、プロジェクトがどういう状態が理想だと思っています か？導⼊前に思っていた理想の状態と違いはありますか？ ■ 理想の状態は変わってないです。 ■ ⼈の振る舞い的には、理想にかなり 近づいたと思います。 ■ 本当は、プロジェクトが平穏だと もっと理想です。 ■ メンバーの興味とビジネス要求の実 現を両⽴出来ている状態 ■ QCD向上への欲求は終わりが無いと わかった
- 48. 最後に、導⼊を検討している⽅へのアドバイス、注意点 などありましたらよろしくお願いします。 ■⾊々な所で反発があると思います が、しつこさで乗り切って下さい。 ｗ ■CSMのコースは有益だと思います。
- 50. twitter ＊会社⾒学は常時やってます。 安藤 連 renando 永井 正樹 nagaim ⾼橋 ⼀貴 kappa4 榎本 明仁 akie ■ ■ ■ ■