成長する組織へ導くコミュニケーション変革 - Agile Japan 2010

1,282 views

Published on

A presentation that was showed in Agile Japan 2010.
Speakers:
Masaki Nagai (Brain Lab.)
Akihito Enomoto (Brain Lab.)
Ren Ando (Cirius Technologies, Inc)
Kaz Takahashi (Cirius Technologies, Inc) - me

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,282
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
13
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

成長する組織へ導くコミュニケーション変革 - Agile Japan 2010

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

×