2015/12/02におこなった”東京大学医療社会システム工学寄付講座・ベリサーブ共同シンポジウム「品質イノベーションの追求」”の講演資料です。 大規模組織における、ソフトウェアの素早い提供を重視する中での品質に関する取り組みを紹介しました。

2. ヤフーのここ3年の取り組みから
⾃社で使えそうな取り組み・考え⽅
本セッションでは
をお持ち帰りいただければ幸いです

3. ⼭⼝ 鉄平
ヤフー株式会社
■ソフトウェア開発技術の普及や開発変⾰の推進担当
■「Fearless Change アジャイルに効く
アイデアを組織に広めるための48 のパターン」共訳
■「システムテスト⾃動化標準ガイド」 レビュアー
■ JaSSTなどでの登壇多数

4. 今⽇の話
ヤフーの今 権限委譲
スモール
チーム
サポート
部⾨強化
まとめ

5. ヤフーの今 権限委譲
スモール
チーム
サポート
部⾨強化
まとめ

6. WEB企業が求める品質

7. メーカーとWEBの求める品質の違い
WEB
不具合 少
不具合 多
遅
リリース速度
速
リリース速度
メーカー

8. ヤフー株式会社の3年前
WEB
メーカー
ヤフー
不具合 少
不具合 多
遅
リリース速度
速
リリース速度

9. ヤフー株式会社の今
WEB
メーカー
ヤフー
不具合 少
不具合 多
遅
リリース速度
速
リリース速度

10. 課題感と変化のきっかけ

11. • 新規事業が育たない
• 競合他社に先⾏されていた
など多くの課題が発⽣していた
なぜ変化したのか？

12. 経営陣交代
3年前に起きたこと

13. • 権限委譲
• スモールチーム
• サポート部⾨強化
3年前から変えたこと

14. ヤフーの今 権限委譲
スモール
チーム
サポート
部⾨強化
まとめ

15. 課題

16. • サービス開発の承認プロセスが⻑期化
• 不具合が他⼈事

17. • サービス開発の承認プロセスが⻑期化
• 不具合が他⼈事

18. • 様々な役職の⼈からの承認が必要
• 承認を得るための資料作成が必要
サービス開発の承認プロセスが⻑期化

19. • サービス開発の承認プロセスが⻑期化
• 不具合が他⼈事

20. • 開発の責任がコードを作ること
• テストはQA部⾨がおこなう
不具合が他⼈事

21. • サービス開発の承認プロセスが⻑期化
• 不具合が他⼈事
課題

22. 施策

23. • 承認項⽬の削減
• 基本的に⾃分たちによるテスト

24. • 承認項⽬の削減
• 基本的に⾃分たちによるテスト

25. • なぜ、その承認を⾏うのか？
• その⼈でなければできないことなのか？
承認項⽬の削減

26. • 承認項⽬の削減
• 基本的に⾃分たちによるテスト

27. • プロダクトの成⻑で関係者を評価する
• リリースを⾃分でおこなう
• 関係者全員でテストする
基本的に⾃分たちによるテスト

28. • 承認項⽬の削減
• 基本的に⾃分たちによるテスト
施策

29. 結果

30. • リリース速度の向上
• 不具合への意識改善
• 開発メンバーのモチベーション向上

31. ヤフーの今 権限委譲
スモール
チーム
サポート
部⾨強化
まとめ

32. 課題

33. • 情報伝達のコストが膨⼤
• 責任の分散

34. • 情報伝達のコストが膨⼤
• 責任の分散

35. • 組織の肥⼤化
• 誰が情報を持っているのか不明確
情報伝達のコストが膨⼤

36. • 情報伝達のコストが膨⼤
• 責任の分散

37. • 作業に対する責任になった
• 組織の肥⼤化による責任がぼやけた
責任の分散

38. • 情報伝達のコストが膨⼤
• 責任の分散
課題

39. 施策

40. • サービス開発に必要な役割を１まとまりに
• １まとまりの少⼈数化

41. • サービス開発に必要な役割を１まとまりに
• １まとまりの少⼈数化

42. • ビジネス・開発などを１チーム化
• チームは席を近くに
サービス開発に必要な役割を1まとまりに

43. • サービス開発に必要な役割を１まとまりに
• １まとまりの少⼈数化

44. • １まとまりのサイズを多くとも10名程度に
• １まとまりごとにサービスの責任を持たせる
１まとまりの少⼈数化

45. • サービス開発に必要な役割を１まとまりに
• １まとまりの少⼈数化
施策

46. 結果

47. • 業務⾼速化
• 責任の明確化

48. ヤフーの今 権限委譲
スモール
チーム
サポート
部⾨強化
まとめ

49. 課題

50. • 重複の多発による⾮効率
• 技術・ノウハウのタコツボ化

51. • 重複の多発による⾮効率
• 技術・ノウハウのタコツボ化

52. • 同じ機能を複数の部⾨でそれぞれ開発
• ビルド環境やテスト環境が乱⽴
重複の多発による⾮効率

53. • 重複の多発による⾮効率
• 技術・ノウハウのタコツボ化

54. • 違う部署へ移動すると覚え直すことが多い
• 良いノウハウが伝搬しにくい
技術・ノウハウのタコツボ化

55. • 重複の多発による⾮効率
• 技術・ノウハウのタコツボ化
課題

56. 施策

57. • 機械的な作業のサポート部⾨での統合
• 技術・ノウハウのツール化，普及部⾨の強化

58. • 機械的な作業のサポート部⾨での統合
• 技術・ノウハウのツール化，普及部⾨の強化

59. • UI部品や汎⽤機能のサポート部⾨からの提供
• ビルド環境などサポート部⾨からの提供
機械的な作業のサポート部⾨での統合

60. • 機械的な作業のサポート部⾨での統合
• 技術・ノウハウのツール化，普及部⾨の強化

61. • 良い施策や便利な道具のツール化
• プラットフォーム部⾨や技術普及部⾨の強化
技術・ノウハウのツール化，普及部⾨の強化

62. • 機械的な作業のサポート部⾨での統合
• 技術・ノウハウのツール化，普及部⾨の強化
施策

63. 結果

64. • 本質的な業務への集中
• 技術・ノウハウの向上

65. ヤフーの今 権限委譲
スモール
チーム
サポート
部⾨強化
まとめ

66. • 権限委譲
• スモールチーム
• サポート部⾨強化
我々がおこなった施策

67. これから

68. ヤフーがこれから⽬指す先
WEB
メーカー
ヤフー
不具合 少
不具合 多
遅
リリース速度
速
リリース速度

69. • ⾃動化の拡⼤
• 関係者の意識の向上
更なる品質改善に向けて