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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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