途中で簡単なプレゼンテーションが⼊ります。

このセッションでは…

モデレーターからの質問にパネリストが回答する形で進⾏させて頂きます。

最後に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の活用■ 形だけのふりかえりではなくなり、ふりかえり→改善のサイクルが回り始めたとき

社内ツールの写真（BL）

ブレイン・ラボ スプリントバックログ（Youたち作っちゃいなよ）

社内ツールの写真（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

■

■

■

■