More Related Content Similar to 成長する組織へ導くコミュニケーション変革 - Agile Japan 2010 (20) 成長する組織へ導くコミュニケーション変革 - Agile Japan 20103. モデレータ・演者紹介
■永井 正樹 ■ 安藤 連
代表取締役COO 取締役
認定スクラムプロダクトオーナー
■榎本 明仁 ■ ⾼橋 ⼀貴
認定スクラムマスター 認定スクラムマスター
4. ■ 設⽴ 2002年11⽉(8期目)
■ 従業員 30名
⼈材ビジネスへのトータルソリューション
■ ⼈材紹介会社向けコンサルティング、サポート業務
■ ⼈材紹介システム(パッケージ)開発・販売業務 - CareerPlus
■ その他受託開発
7. どんな開発マネジメント⼿法でしたか?
場当たり的 マネージャー / プロジェクトによっ
てマネジメント⼿法が異なる
マネージャが全てを把握
個⼈で担当するコンポーネントや機
基本的に個⼈プレー 能が決まっている
スケジュールを組んでも結局 品質は個⼈に依存している
スケジュール通りに納品できない
9. QCD はどう
■Quality: ■ Quality:
お客様からのクレームが今と⽐べると 正常系は動く
多かった
■Cost: ■ Cost:
単⼀プロジェクトしか回せない状態 ⾒積以上に開発コストがかかる
だったので、⽣産性はいまから⽐べる
と低かったと思います。 ■ Delivery:
■Deliverly: 間に合う場合もある
まともに予定通り納品できた試しがな
かった・・・
13. 学習に対する姿勢はどうでしたか?
■ 要望があれば、会社負担での学習 ■ 社内にロールモデルが不在なので、
も可能だった。自発的な活動を待っ 学習するインセンティブが希薄。
ていた
■ プロジェクト (もしくはタスク)ド
■ 完全に個々⼈に依存している状態 リブン学習
で、チーム間での知識共有なども少
なかった。 ■ 自発的にはやらなかった(メン
バー談)
16. なぜスクラムを選択したか。
技法というよりも、まずは体制への 直接のきっかけは、前の職場で失
問題意識が強かったので、 XPやRUP 敗しているのを⾒たこと。
よりもスクラムを選択
当時組織が抱えていた課題:
XPについてはScrumでついた基礎 (1)自⽴⾏動するチーム
体⼒の上で実践して⾏く事を考えてい ⇒ミドル層の知的資源を
ました。 他の事に活用。
(2)⼀体となって問題解決する
リーンはスクラムの親で考え⽅は チーム
かなり共通していると思います。 ⇒チームとして使える知的
ただ、スクラムの⽅がソフトウェア開 資源増加
発に主眼がおかれているので導⼊が容 リーン vs. スクラム vs. XP
易だと感じていました。 そもそもこれら3つの間にconflicts
は無い。
17. どのようにアジャイルを勉強しましたか?
■本 ■ 書籍
■ コミュニティ "Agile Project Management with
■ CSM Scrum"
(Ken Schwaber, Microsoft Press)
前の職場(Scrumに失敗していた)で
バイブル的な扱いをされていたので。
■本
("初めてのアジャイル開発"など)
■ Webサイト
19. 導⼊への1st step
「アジャイル、アジャイル」、 ⼊社時点で、導⼊の余地を感じ取り、
「スクラム、スクラム」と 社内に提案。
呪⽂のように⾔い続ける。
開発チーム、ビジネスチーム、マ
CSMを受ける ネージャー層に対してプレゼン。「こ
れをきっかけに何か変わりそう」とい
上司を説得する う期待を抱かせる。
チームを説得する 「ワークするまでに数ヶ⽉はかか
る」と全員の期待値を下げておく
1つのチームで練習スプリントを開
始。
23. (受⼊側への質問)導⼊を受け⼊れた理由と、
そこで抱いた不安について教えてください。
(経営) ■ 提案時点で既に経営層やビジネス
■ 榎本がやりたいと積極的に提案して グループは「開発チームを良くした
きたから。 い」と思っていた。
■ サボるのではないかは不安だった。
■ もともと導⼊したかった
(チーム)
■ 榎本が積極的だったから。 ■ 組織だった開発マネジメントがさ
■ 変化に対する不安。 れていなかったので、拒否する理由
がない
■ 組織とプロセスを⼀度に変えるこ
との不安
24. (導⼊提案側への質問)受け⼊れてもらうために
使ったKnow-howについて教えてください。
■ しつこさ w ■ 開発チームを取り巻く⼈たちが本当
■ 準備を⼊念に に聞きたいことを伝えること。
(社内営業のつもりで)
■ すなわち「私たち共通の問題を解決
■ 周囲を巻き込むこと しましょう」というトーンのコミュニ
(こちら側に引き⼊れる) ケーションを⾏うこと。
■ 榎本の⼼を折れさせないこと 「今の問題はこういうことです」
「この状況を改善するアプローチとし
て、この枠組みを導⼊します。」
「この枠組みが状況を
改善する理由は
こういうことです」
・・・etc
29. (導⼊者側)⼀番最初にした失敗は?
■ スプリントプランニングが暗かっ ■【第1期】
たし、興味を持ってもらえなかった。 当時は失敗したと思っていなかった
今振り返ると、以下が失敗:
・スクラムをプロセスとして捉え、やり⽅を丸コ
ピーした上で、プロセスの効率化を図った。
・プロダクトオーナーとスクラムマスターを兼任し
た
・古い本(2004)をベースにしたので、やり⽅が古
かった。
・User Storyが、ビジネスニーズの抽出として書か
れていなかった。(機能リストになっていた)
■【第2期】
ここで失敗に気づいた
・チームのスケールのさせかたを間違えた(技術レ
イヤー別のチームを作った)。
30. 予想していなかった⼀番大きな問題は?
■ 変化を嫌う⼈の抵抗 ■ Scrumの向こうにあるprinciple
(脱落者を出してしまった事) (Lean的なもの)は、実はScrumの書
籍1冊だけで会得するのが難しい(書
き切るのが難しい)
・・・ということに気づくのに相当時
間がかかった。
■ 「我々は教科書の通りにやってい
る」と思っていたため、多数の間違い
の発⾒が遅れた
■ 仕事を向上させたいという気持ちを
持つメンバーは思ったより少ない
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. メンバーは楽しく仕事をしていますか?
■ 楽しんで仕事をしている⼈が多い ■ 基本的に、仕事が楽しくないという
会社であるとは思いますが、どんど ⼈はうちの会社にはいないと思います。
ん活発になってきていると思います。
■ もちろん、先に述べた理由で時に
■ ただ、スクラムはチームにとって ストイックさを求めるので、エンジニ
も厳しい⼿法だと思います。責任と ア的刺激が薄いと感じる場⾯はあるよ
自⽴を求めるので。 うです。
■ 楽しくやっていると思います。ただ、
コミュニケーションの難しさを感じて
いる時もあるようです。
46. 学習に対する姿勢はどうですか?
■ ⾦曜⽇の⼣⽅に勉強会が開催され ■ TechTalkの内容はおもしろいもの
るようになり、講師を持ち回りでや が多いですね。
るようになっています。
■ 今後の学習課題が、明確になり、
■ ペアプロをチームのメンバーが積 学習の意欲が向上した。
極的にやる場⾯が⾒えるようになっ
てきています。 ■ プロジェクトドリブンで勉強をす
ることに変わりはない。
50. twitter
■ 永井 正樹 ■ 安藤 連
nagaim renando
■ 榎本 明仁 ■ ⾼橋 ⼀貴
akie kappa4
*会社⾒学は常時やってます。