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

途中で簡単なプレゼンテーションが入ります。
このセッションでは… モデレーターからの質問にパネリストが回答する形で進行させて頂きます。最後に Q ＆ A の時間を予定しておりますので、質問はご用意しておりますポストイットに書き留めておいて下さい。

モデレータ・演者紹介
安藤連取締役認定スクラムプロダクトオーナー
永井正樹代表取締役 COO 高橋一貴認定スクラムマスター榎本明仁認定スクラムマスター ■ ■ ■ ■

■ 設立 2002 年 11 月（ 8 期目） ■ 従業員 30 名人材ビジネスへのトータルソリューション ■ 人材紹介会社向けコンサルティング、サポート業務 ■ 人材紹介システム（パッケージ）開発・販売業務 - CareerPlus ■ その他受託開発

スクラムを始める前はどんな状態？
サボっていないか不安（経営者）
納期に間に合わない（ミドル）
知識共有がされていない（チーム）
ビジネスグループからの「要望」がマネージャーに集まる
マネージャーがそれを作業のリストに変換してメンバーに提示
納期 / 機能の調整より、品質を調整
納期に間に合わないこともあった

どんな開発マネジメント手法でしたか？
場当たり的
マネージャが全てを把握
基本的に個人プレー
スケジュールを組んでも結局
スケジュール通りに納品できない
マネージャー / プロジェクトによってマネジメント手法が異なる
個人で担当するコンポーネントや機能が決まっている
品質は個人に依存している

メンバーは楽しく仕事をしていましたか？
それなりに楽しくはやっていた。（大変な状況でも楽しめるメンバーだったので）
納品が間に合わないのが常習化している事により精神的プレッシャーはかなり高い状態であった
ゴールが見えない
開発自体は楽しい
納期直前はかなりの緊張感
デスマーチに近い（日々終電）

QCD はどう
■ Quality: お客様からのクレームが今と比べると多かった
■ Cost: 単一プロジェクトしか回せない状態だったので、生産性はいまから比べると低かったと思います。
■ Deliverly: まともに予定通り納品できた試しがなかった・・・
■ Quality: 　正常系は動く
■ Cost: 　見積以上に開発コストがかかる
■ Delivery: 　間に合う場合もある

ビジネスとしてうまくいっていましたか？
■ 売上という意味ではうまくいっていたと思います。
■ クレームが多かった
■ 大きめなプロジェクトは１つしか回せなかった
■ それなりにうまく行っていたようです。

メンバーに対して、どのような想いを抱いていましたか？
■ 一人一人を管理しないとだめ（経営者）
■ 頑張ってやっていたと思う（経営者）
■ もっと積極的になってほしい（経営者）
■ 多能工になってほしい（ミドル）
■ 他のメンバーの仕事は知らない（メンバー）
■ わが社の社員は自発性がない…と思っていたはず
■ 設計・実装からテストまで一人である程度こなして欲しい
■ 技術不足のメンバーへの不満

コミュニケーションの形は？
■ 経営者、マネージャに全てのコミニュケーションが集約されていた。
■ ビジネスグループからの要望はマネージャーを経由してメンバーに届く。その時点で、作業のリストに変換されている。
■ ツリー型：チーム・メンバー間のつながりはあまりない。

学習に対する姿勢はどうでしたか？
■ 要望があれば、会社負担での学習も可能だった。自発的な活動を待っていた
■ 完全に個々人に依存している状態で、チーム間での知識共有なども少なかった。
■ 社内にロールモデルが不在なので、学習するインセンティブが希薄。
■ プロジェクト ( もしくはタスク ) ドリブン学習
■ 自発的にはやらなかった ( メンバー談）

その時はどういう状態が理想だと思っていましたか？
個々の能力が高く、自発的に活動が出来る状態。
自立した個人が有機的につながったチームで仕事をする状態が理想だった。
sense of ownership と leadership 、自律的で協調的な問題解決
当事者意識、技術的に成熟し、新しい技術にも貪欲なメンバー
技術者の性格・性質に理解を示すマネジメント層
個々が協力し合いながら仕事を進める

なぜスクラムを選択したか。
技法というよりも、まずは体制への問題意識が強かったので、 XP や RUP よりもスクラムを選択
XP については Scrum でついた基礎体力の上で実践して行く事を考えていました。
リーンはスクラムの親で考え方はかなり共通していると思います。ただ、スクラムの方がソフトウェア開発に主眼がおかれているので導入が容易だと感じていました。
直接のきっかけは、前の職場で失敗しているのを見たこと。
当時組織が抱えていた課題：
（ 1 ）自立行動するチーム　　　⇒ミドル層の知的資源を　　　他の事に活用。（ 2 ）一体となって問題解決する　　　チーム　　　⇒チームとして使える知的　　　資源増加
リーン vs. スクラム vs. XP そもそもこれら３つの間に conflicts は無い。

どのようにアジャイルを勉強しましたか？
■ 本
■ コミュニティ
■ CSM
■ 書籍
"Agile Project Management with Scrum"
(Ken Schwaber, Microsoft Press)
前の職場（ Scrum に失敗していた）でバイブル的な扱いをされていたので。
■ 本 (" 初めてのアジャイル開発 " など )
■ Web サイト

導入への 1st step
「アジャイル、アジャイル」、「スクラム、スクラム」と呪文のように言い続ける。
CSM を受ける
上司を説得する
チームを説得する
入社時点で、導入の余地を感じ取り、社内に提案。
開発チーム、ビジネスチーム、マネージャー層に対してプレゼン。「これをきっかけに何か変わりそう」という期待を抱かせる。
「ワークするまでに数ヶ月はかかる」と全員の期待値を下げておく
1 つのチームで練習スプリントを開始。

1st step を今から振り返って、反省点はありますか？
うーん。思い当たらないです・・・
スクラムは framework でしかないということを正しく把握できていなかった。 ※ただし、この時点ではちゃんと成果は上がった。
（ 1st step がうまく行くように見えるのが、スクラムの落とし穴の 1st step ）

導入に至るまで、どれくらいのステップ・期間が必要でしたか？
■ CSM の前からすこしずつ本で読んだ事をベースに色々試してみましたが、本格的に始めたのは CSM を受けてからですね。
思い立ってから 3 週間ぐらい。
■ 本を読みながらポイントを把握
■ 社内向け説明スライド作成
■ 社内向けプレゼンテーション数回実施
■ Product Backlog と Sprint Backlog のテンプレートを作成
■ 練習スプリント開始

導入に至るまでに理不尽さを感じた出来事はありますか？なぜ諦めなかったんですか？
■ 共感を得るのが難しい
■ 保守的である
このままじゃ駄目だという危機感と、自分が理想としている職場に近づけたいから。
■ ありません

( 受入側への質問 ) 導入を受け入れた理由と、そこで抱いた不安について教えてください。
（経営）
■ 榎本がやりたいと積極的に提案してきたから。
■ サボるのではないかは不安だった。
（チーム）
■ 榎本が積極的だったから。
■ 変化に対する不安。
■ 提案時点で既に経営層やビジネスグループは「開発チームを良くしたい」と思っていた。
■ もともと導入したかった
■ 組織だった開発マネジメントがされていなかったので、拒否する理由がない
■ 組織とプロセスを一度に変えることの不安

( 導入提案側への質問 ) 受け入れてもらうために使った Know-how について教えてください。
■ しつこさ　ｗ
■ 準備を入念に（社内営業のつもりで）
■ 周囲を巻き込むこと（こちら側に引き入れる）
■ 榎本の心を折れさせないこと
■ 開発チームを取り巻く人たちが本当に聞きたいことを伝えること。
■ すなわち「私たち共通の問題を解決しましょう」というトーンのコミュニケーションを行うこと。
「今の問題はこういうことです」
「この状況を改善するアプローチとして、この枠組みを導入します。」
「この枠組みが状況を改善する理由は
こういうことです」
・・・ etc

導入までにかかったコストについて教えてください。
■ CSM の受講料と本代
■ 説得＋説明の時間（トータルで 16 時間くらい）
■ スライドを作った時間（数時間）
■ プレゼンテーションセッション３回ぐらい
■ バックログのテンプレート作成と共有方法を試行錯誤した数時間
■ ramp-up のためのオーバーヘッド
（ 1 チーム 1 週間ぐらいの
loss ）

( 導入者側 ) 一番最初にした失敗は？
■ スプリントプランニングが暗かったし、興味を持ってもらえなかった。
■ 【第 1 期】
当時は失敗したと思っていなかった
今振り返ると、以下が失敗：
・スクラムをプロセスとして捉え、やり方を丸コピーした上で、プロセスの効率化を図った。
・プロダクトオーナーとスクラムマスターを兼任した
・古い本 (2004) をベースにしたので、やり方が古かった。
・ User Story が、ビジネスニーズの抽出として書かれていなかった。（機能リストになっていた）
■ 【第 2 期】ここで失敗に気づいた
・チームのスケールのさせかたを間違えた（技術レイヤー別のチームを作った）。

予想していなかった一番大きな問題は？
■ 変化を嫌う人の抵抗　（脱落者を出してしまった事）
■ Scrum の向こうにある principle （ Lean 的なもの）は、実は Scrum の書籍１冊だけで会得するのが難しい（書き切るのが難しい）
・・・ということに気づくのに相当時間がかかった。
■ 「我々は教科書の通りにやっている」と思っていたため、多数の間違いの発見が遅れた
■ 仕事を向上させたいという気持ちを持つメンバーは思ったより少ない

導入直後の QCD はどうでしたか？
■ もともとがヒドかったので、全面的に上がったと思います。
■ 少なくとも当時は、工学的な要素よりも、人間的な要素の改善が著しく見られたという印象です。

スクラムが導入できた！と思った瞬間は？
■ チームがスプリントバックログ用のツールを自分たちで勝手に作り始めた時。
【第 1 期】
■ メンバーの sense of ownership や leadership が感じられた。
■ メンバーが機能を提案してくれるようになった。（でも、そんな認識は今考えると甘かった。）
【第 2 期】
■ チーム数を増やしてスケールしても
ワークするようになった。
■ メンバーから Product Owner への質問中の技術的要素が激減。
■ Product Owner による Story cards の活用
■ 形だけのふりかえりではなくなり、ふりかえり->改善のサイクルが回り始めたとき

ブレイン・ラボスプリントバックログ（ You たち作っちゃいなよ）社内ツールの写真（ BL ）

プロダクトバックログ社内ツールの写真（ BL ）

スプリントバックログ社内ツールの写真（ BL ）

自分のどのような部分が成長したと感じましたか？
■ 観察する力を持つことができるようになってきた。
■ 守破離の大切の気づき
■ 指示型マネジメント
■ Scrum の背後にある考え方を習慣化 ⇒ People manager として、経営者として、必要な資質の一部が身につきます。
■ 会社の採用基準、採用プロセス、人事プラン、評価制度も Scrum に合わせて設計 ⇒ 経営の人材的側面においてユニークな経験が身につきました。
■ エンジニアリングの部分というよりは、人間的な成長が大きいと思います。

実際にうまく回り始めて、今感じているメリット・デメリットを教えてください。
【メリット】
■ 自発性が生まれた
■ 学習のサイクルが生まれた
【デメリット】
■ スクラムマスターを育てるのが大変
■ 現状維持をしようと
してしまう傾向がある
【メリット】
■ チームに活気が出る（よく社外で感心される）
■ 社内の他部門に信頼される
■ 生産性あたりの施設コストが小さい
■ 品質を十分に確保できるペースで開発できる
■ 作業環境・方法を自分たちにあった方法に最適化できる
【デメリット】
■ 本質的にクリエーターであるエンジニアやデザイナーにとって、クリエーター的衝動を否定しなければいけない場面が多くなる
■ 戦略的な人材育成、獲得、評価プログラムが必要になるので、コーポレートレベルでの変化能力が必要
■ ファシリティ的制限。大きなスペースが要る。
■ プロダクトオーナーのコミュニケーション負荷が高い

QCD はどうなりましたか？
■ 納期のズレや、顧客との仕様のズレが無くなった
■ 導入当初のような劇的な変化は無い
■ 少しずつ改善はされていると思う
■ Quality, Delivery は向上
■ Cost はあまり変わらない
■ Q, C の定量化はしていない
■ QCD すべてにおいて改善の余地はある
■ 継続して改善

今悩んでいることは何ですか？それに対してどのような行動をしていますか？
■ スクラムマスターが育ってない（ミドル）
■ 以下のような課題の唯一解は、スクラムフレームワークには用意されていないので、 Principle は何だろうと考えながら実験をしています。
1) 複数スクラムチーム間での隠れた　 dependency を発見 / 通知する仕組み（ Scrum Of Scrums は万能ではない）
2) 複雑な Story のデザインプロセスを、組織内にどう実装するか。複雑な成果物に対する Responsibility をどう担保するか。
■ メンバーのアジャイルマインド向上

受け入れた人たちは、今はどう思っていますか？
■ 任せることができる
■ ゴールが見えるようになった（チーム）
■ 経営陣は、スクラムチームが会社の最も重要な asset のひとつだと捉えています。
■ ビジネスグループから見ても「以前よりもずっと頼りになる」と思って
もらえているはずです。
■ メンバーの自主性が向上した
■ チームの規模に対して、コミュニケーションの質が良い
■ バックログアイテムを完了させた時の感触が良い

メンバーは楽しく仕事をしていますか？
■ 楽しんで仕事をしている人が多い会社であるとは思いますが、どんどん活発になってきていると思います。
■ ただ、スクラムはチームにとっても厳しい手法だと思います。責任と自立を求めるので。
■ 基本的に、仕事が楽しくないという人はうちの会社にはいないと思います。
■ もちろん、先に述べた理由で時に
ストイックさを求めるので、エンジニア的刺激が薄いと感じる場面はあるようです。
■ 楽しくやっていると思います。ただ、コミュニケーションの難しさを感じている時もあるようです。

ビジネスとしてうまくいっていますか？
■ まだ小さい会社ですので、影響は出やすいです。直接売上に結びつくことはまだありませんが、統合的に見て十分当社のビジネスに役にたっていると思います。
■ 市場が伸びており、その中での弊社のビジネスの成長をサポートする…というフェーズにいるので、うまく行かせるためにがんばっています。

メンバーに対してどのような想いを抱いていますか？心境に変化はありましたか？
■ 頼もしい。
■ 自発性が生まれてきている。（もっと自発性を育てていきたい）
■ 私自身（今は経営陣の 1 人）は、 Scrum team の構成員達こそが弊社の最大の売りだと思っています。
■ 技術力の面で不安がなくなりました
■ メンバーの成長に貢献したいと思うようになりました

コミュニケーションの形は？
■ スター型からネットワーク型へ
■ ネットワーク型 x クラスタ

学習に対する姿勢はどうですか？
■ 金曜日の夕方に勉強会が開催されるようになり、講師を持ち回りでやるようになっています。
■ ペアプロをチームのメンバーが積極的にやる場面が見えるようになってきています。
■ TechTalk の内容はおもしろいものが多いですね。
■ 今後の学習課題が、明確になり、学習の意欲が向上した。
■ プロジェクトドリブンで勉強をすることに変わりはない。

今は、プロジェクトがどういう状態が理想だと思っていますか？導入前に思っていた理想の状態と違いはありますか？
■ 理想の状態は変わってないです。
■ 人の振る舞い的には、理想にかなり近づいたと思います。
■ 本当は、プロジェクトが平穏だともっと理想です。
■ メンバーの興味とビジネス要求の実現を両立出来ている状態
■ QCD 向上への欲求は終わりが無いとわかった

最後に、導入を検討している方へのアドバイス、注意点などありましたらよろしくお願いします。
■ 色々な所で反発があると思いますが、しつこさで乗り切って下さい。ｗ
■ CSM のコースは有益だと思います。

twitter
＊会社見学は常時やってます。
安藤連 renando 永井正樹 nagaim 高橋一貴 kappa4 榎本明仁 akie ■ ■ ■ ■

http://d.hatena.ne.jp	110
http://www.slideshare.net	23
http://www.health.medicbd.com	2
http://twitter.com	1

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

by Akihito Enomoto on Apr 12, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 136

Statistics

成長する組織へ導くコミュニケーション変革 - 事例に学ぶコミュニケーション革命 -Agile Japan 2010 — Presentation Transcript