オープンセミナー2014@広島のLT（10分）用スライドです

1. 形から入るスクラム
!
㈱リンクロード 川口稔

2. 自己紹介
•
川口 稔
•
㈱リンクロード所属
•
業務系システムの開発
•
すくすくスクラム広島スタッフ

3. 下請・派遣

4. スクラム導入
http://www.flickr.com/photos/royskeane/413103429

5. ごめんなさい

6. スクラム、ちゃんと
やったことない
http://www.flickr.com/photos/explosivebolts/60622410

7. システム開発
経験８年
プロジェクト１２個

8. アジャイル開発
みたことない
http://www.flickr.com/photos/rmlowe/3280523887

9. アジャイルな開発が
したいです…
http://www.flickr.com/photos/jason_burmeister/4102808332

10. では

11. 大手IT企業のアジャイル開発に関する取組み
企業
NTTデータ
NEC
日立製作所
富士通
日本IBM
内容
若手リーダー対象の研修開始．
3年間で計1,000人の人材を育成する計画．
大規模案件に適用できる技術者を2012年度に約30人育成する計画．
「品質会計」と組み合わせたアジャイル開発ガイドを作成．
大規模案件に適用するための枠組みや実際の手順等をまとめたガイド
ラインを策定．
開発現場で蓄積したノウハウを適用するための開発標準を策定．
12年度から顧客に向けアジャイル開発手法に基づくシステム開発の提
案を強化．同手法を取り込んだ自社の開発標準を活用．
出典：大手IT企業が「アジャイル開発」を強化，日経コンピュータ，2012年5月24日号

12. やってないの
俺の周りだけ？

13. ちょっと調べてみた

15. WF
反復型
その他
開発ライフサイクルモデル
反復型
2.4%
WF
96.5%
WF：2854
反復型：70
その他：33

16. 2.4%

17. WF
反復型
その他
開発ライフサイクルモデル
反復型
2.4%
WF
96.5%
WEB系・ゲーム系は
もっと多そう
WF：2854
反復型：70
その他：33

18. 俺の周りだけじゃない

19. なぜこんなに少ない？

20. ちょっと考えてみた
http://www.flickr.com/photos/scragz/133270527

21. 日本のIT業界の特徴①

22. 重層的下請構造
http://www.flickr.com/photos/jaybergesen/3335698859

23. ソフトウェア産業の重層的下請構造
全体
独立型
元請型
中間下請 最終下請
企業数
3832
452
778
1990
612
割合
100%
11%
21%
51%
17%
従業員数
（平均）
415
257
412
485
308
独立行政法人 経済産業研究所２００８

24. 下請が約７割

25. で？

26. 下請けだとアジャイル
できないの？

27. ユーザー企業
１次請け
２次請け
２次請け
３次請け ３次請け
３次請け

28. ユーザー企業
発
注
１次請け
２次請け
２次請け
３次請け ３次請け
３次請け

29. ユーザー企業
発
注
１次請け
発
注
２次請け
発
注
２次請け
３次請け ３次請け
３次請け

30. ユーザー企業
発
注
１次請け
発
注
発
注
２次請け
２次請け
発
注
発
注
３次請け ３次請け
発
注
３次請け

31. ユーザー企業
発
注
１次請け
発
注
発
注
２次請け
２次請け
発
注
発
注
３次請け ３次請け
アジャイルで…
発
注
３次請け

32. ユーザー企業
発
注
１次請け
発
注
は？
発
注
２次請け
２次請け
発
注
発
注
３次請け ３次請け
アジャイルで…
発
注
３次請け

33. ユーザー企業
発
注
１次請け
発
注
発
注
２次請け
２次請け
発
注
発
注
３次請け ３次請け
いえ、別に…
発
注
３次請け

34. ユーザー企業
発
注
１次請け
発
注
発
注
２次請け
納
品
２次請け
発
注
発
注
納
品
３次請け ３次請け
納
品
発
注
３次請け

35. ユーザー企業
発
注
１次請け
納
品
発
注
発
注
納
品
２次請け
納
品
２次請け
発
注
発
注
納
品
３次請け ３次請け
納
品
発
注
３次請け

36. ユーザー企業
納
品
発
注
１次請け
納
品
発
注
発
注
納
品
２次請け
納
品
２次請け
発
注
発
注
納
品
３次請け ３次請け
納
品
発
注
３次請け

37. アジャイルなとこも
あるらしい

38. ユーザー企業
１次請け
２次請け

39. アジャイルで！
ユーザー企業
発注
１次請け
２次請け

40. アジャイルで！
ユーザー企業
発注
１次請け
発注
２次請け
アジャイルで！

41. アジャイルで！
ユーザー企業
発注
１次請け
１月ごと
納品
発注
２次請け
アジャイルで！

42. アジャイルで！
ユーザー企業
１月ごと
発注
納品
１次請け
１月ごと
納品
発注
２次請け
アジャイルで！

43. 下請エンジニアとしては
http://www.flickr.com/photos/bfishadow/3634061465/

44. アジャイル案件に当たるのは
http://www.flickr.com/photos/bfishadow/3634061465/

45. 運次第
http://www.flickr.com/photos/dahlstroms/5276348473/

46. 2.4%

47. 日本のIT業界の特徴②

48. 派遣も多い
(・ ・)ﾊｹｰﾝ

49. 情報サービス事業売上に対するサービス提供内容売上比率
受託
ハード
派遣
BPO
PKG
その他
3%
5%
ASP
運用
保守
7%
6%
46%
15%
3%
4%
12%
経済産業省 2012

50. 情報サービス事業売上に対するサービス提供内容売上比率
受託
ハード
派遣
BPO
PKG
その他
3%
5%
ASP
運用
保守
7%
6%
46%
15%
3%
4%
12%
売上ベースなので、人数で言えばもっと多いはず
経済産業省 2012

51. 派遣は雇用の調整弁
http://www.flickr.com/photos/elsie/528483453

52. PJ終わったらサヨナラ
http://www.flickr.com/photos/greencolander/2503743724/

53. 開発プロセスをどうこ
うできる立場ではない

54. アジャイルやってると
こに派遣されれば…

55. 運次第
http://www.flickr.com/photos/dahlstroms/5276348473/

56. 2.4%

57. 結局、下請・派遣エンジニア
がアジャイル
やれるかどうかって

58. 運次第？
http://www.flickr.com/photos/dahlstroms/5276348473/

59. アジャイルがもっと普及
するのを待つしかない？

60. 下請・派遣エンジニアに
できることは無いのか？
http://www.flickr.com/photos/bfishadow/3634061465/

61. ありません
http://www.flickr.com/photos/explosivebolts/60622410

62. 終了

63. ではなく

64. やってみた
http://www.flickr.com/photos/popculturegeek/5822675610/

65. •
ユーザー企業のIT部門に派遣
•
新規開発案件
•
普通にウォーターフォール
•
10人程度のチーム

66. 工事の行程管理
http://www.flickr.com/photos/infraero/11100514364

67. 製造フェーズ中盤
!
なんかスケジュール的
にやばそう

68. お客さん「間に合わせるために、
効率を上げる方法を考えてください」
http://www.flickr.com/photos/qwrrty/6348790751

69. 「スクラムのやり方を使いましょう。
管理工数も減らせます！」
http://www.flickr.com/photos/qwrrty/6348786773

70. お客さん「やってみて∼」
http://www.flickr.com/photos/qwrrty/6348790751

71. やったこと

72. 形から

73. WBSのタスクに管理者
がメンバをアサインする
のをやめて、

74. タスクボードで
PULL型タスク消化
http://www.flickr.com/photos/otacke/10034579444

75. •
誰が今何やってるか、見える化
•
自主的にタスクを選択するのでモチベーション
維持
•
管理工数を削減

76. ガントチャートをやめて、
http://www.flickr.com/photos/jeanlouis_zimmermann/3203571471

77. バーンダウンチャートで
進 確認
http://www.flickr.com/photos/kakutani/2761992149

78. http://www.flickr.com/photos/kakutani/2761992149

79. •
間に合いそう／ヤバそうをチームで共有
•
作業負荷の平準化
•
管理者の工数を削減

80. お手製プランニングポーカーで、
開発者が見積り
http://www.flickr.com/photos/heliomedeiros/4512111588

81. •
詳細見積もりの精度がよかった
•
開発者の納得感が高かった
•
管理者の工数を削減

82. http://www.flickr.com/photos/philon/2477878611

83. 実は、

84. これらは「スクラム」の
必須要素ではない…

85. 肝心なアレは？

86. スクラムといえば
http://www.flickr.com/photos/montypython/2667752608

87. スプリントをまわす

88. できませんでした

89. ダメじゃん
http://www.flickr.com/photos/explosivebolts/60622410

90. •
もともとWFで進めている
•
POは立てられなかった
•
お客さん忙しい→２週間ごとにデモは無理

91. しかし

92. ここしかユーザーが触るチャンスがない
http://ja.wikipedia.org/wiki/Vモデル

93. これはあかん

94. ユーザーが触るチャンスを増やそう
http://ja.wikipedia.org/wiki/Vモデル

95. 「使い物にならなかったら怖いです！
早くユーザーに見せてください！」
http://www.flickr.com/photos/qwrrty/6348786773

96. 「ユーザーレビュー」「操作説明会」
等と称して、早くからお客さんに
触ってもらう機会を複数回
→その度にフィードバックもらう

97. 結果、
•
要件の漏れを防ぐことができた
•
タスクの優先順位を入れ替えて対応
•
タスクの量、優先順位、チームの速さが見える
化されていたから納得してもらえた

98. まとめ

99. •
開発プロセスを変えるのは難しいかもしれない
•
下請・派遣は無力かもしれない

100. できることから

101. コツコツと
http://www.flickr.com/photos/photonfreak/12188619633/

102. ちゃんとした実践の話
は昼休みの後

103. ありがとう
ございました
http://www.flickr.com/photos/scragz/132300597