For the session A-4 ,DevLOVE Kansai 2012 Drive.

1. ふつうの受託開発チームのつくりかた
手塚モデルの実践編
@kawasima

2. @kawasima

3. Past Slides
http://www.slideshare.net/kawasima/

4. 2011 DevLOVE HangerFlight - Snow Barrage -

5. 2011 DevLOVE HangerFlight - Snow Barrage -

6. 2011 DevLOVE HangerFlight - Snow Barrage -

7. 2011 DevLOVE HangerFlight - Snow Barrage -

9. チームの構成のしかた
How to construct a team.

10. 体制
Product Manager Project Manager
(プロダクトそのものの品質管理) (予算／費用の管理)
特に選抜してないふつうの4年目以下のメンバ

11. SIerの組織心理を利用して集める
人月ビジネスのSIerにとって、1人月分の成果を
出せない駆け出しを引き受けてくれるチームは
ありがたい
これを利用して、まだ普通のSIerの仕事のやり方
を知らない若手をゲットします

12. 役割分担
Product Manager
Product Manager Project Manager
Project Manager
Design Quality Budget/Cost
Architecture Deadline/Progress
Scope
Sprint Planning
マンガプロダクションと担当編集の関係に着想

13. 分業のねらい
✔ 大手SIerに不足しがちな"プロジェクト
マネージャ"という役割の責務を減らす
✔ 受託開発でつくるソフトウェアの設計品
質に責任をもつ役割を作る

14. 開発のしかた
How to develop software.

15. 開発プロセス
いたってふつうのスクラム
アーキテクチャ
いたってふつうのSAStruts MVC
これらを案件ごとに変えず固定化するのが大事

16. オーソドックスにやるのは
わりと難しい
業務ドメインの特殊性や組織事情のせいで、教科書
どおりやるのは難しい、って言っちゃいがち
実はエンジニアリングの熟練度不足に起因するのでは?

17. よこみち
エンジニアは紆余曲折をへて
オーソドックス(王道)にたどり着く

18. Engineer's Lifecycle
ミーハー期 オレオレ期 王道期
べんりや期
こんな変遷をたどる気がする…

19. ミーハー期
✔ホッテントリのものを試してみたい
✔業務で使うとかは関係なく、ハヤリものは後
学のために試してみる

20. オレオレ期
✔カスタマイズしたがる
✔「車輪の再発明も重要なんだよ」
✔メジャーなプロダクトのいけてないところを
あげつらう

21. 王道期
✔標準を軽視しない
✔巨人の肩の上に立つ
✔SAStrutsの設計は、まさに王道の設計

22. べんりや期
✔トラブルプロジェクトを渡り歩く(火消し)
✔早く仕事を終わらせても、他人の仕事がま
わってくる
はやく「仕組みを作る側」にまわれる道を探しましょう

23. 王道を貫くにはハイスキルと
くじけぬこころが要求される
コードを書いて精進しよう
高い生産性はだいたいの問題を解決する

24. チーム`力to build a team.
How
のつくりかた

25. SIerに入社してくる人は、
✔ 見積りの正確性
✔ タスクの完了責任
の意識が高い。
なので、そういうところの指導はおいとい
て、
まず徹底したチームプレイを指導してます

26. Pair Programming
ふつうのチームにおいて、単独の作業だと十分
な質の成果物ができにくい
必然的にペアプロせざるをえない

27. ふりかえり駆動のチーム力強化
スプリントふりかえりの例
【T】ストーリーからかんばんタスクへブレークダウン後にタ
スクを積み上げて目的を果たしているか確認する。
【P】もれがおおい より
【T】”すげぇ”コードを書いたらみんなに自慢をする。その
ための発表会をセッティングし、発表する。
【会話】他の人から学ぶ。学んだことを展開する。より
【T】タスクはナビゲーターが責任を持ってクローズする。カ
ンバンの名前をナビゲーターの名前にしてクローズする。
【P】ナビゲーターの役割が薄い。より

28. プロジェクト振り返り
スプリント毎のふりかえりでは話しきれな
かった重めのテーマをあつかいます

29. 【「残業が増えたのはなぜか」のFIVE WHYS】
Q1「残業が増えたのはなぜか」
A1.残不具合が減らないから。
Q2.なぜ残不具合が減らないのか。
A2.テストケース消化が後ろ延ばしになってしまったから。
Q3.テストケース消化が後ろ延ばしになってしまったのはなぜか？
A3.Sprintごとのストーリー完了を蔑ろにしていたから。
Q4.Sprintごとのストーリー完了を蔑ろにしていたからのはなぜか？
A4.「出来るところは全部できました！」といって忘れ去られているストーリー完
了があったから。
Q5.忘れ去られているのはなぜか？
A5.２パターンの原因がある。
①テストケースの消化をが忘れてしまった。
②ブロック（課題）があり今できないケースをそのまま放置した。
放置したケースに気づくのが遅くなった。

30. 【「残業が増えたのはなぜか」の解決策検討】
①に対しての解決策
◆Storyとテストケースを関連付けてちゃんと把握しましょう。
◆テストの実施完了を持ってStoryの完了としましょう。不具合改修は除く。
◆テスト未実施とブロックをちゃんと分けましょう（今はできないをきちんと「保留」
として扱いましょう。
②に対しての解決策
「保留」を管理する。
◆「保留」が出るのは３タイミング
● 計画MTG：他責は取り除く。取り除き方は、「キメとして実装」or[そもそもStoryに
いれない」のどっちか
● 実装時：懸案チケットとしてきちんと上げましょう。（QAがスクラムマスタと相談し
て懸案かどうか判断する）
● テスト時：懸案チケットとしてきちんと上げましょう。（QAがスクラムマスタと相談
して懸案かどうか判断する）
◆「保留」の管理
● 「保留」が出た箇所は他責か自責かを明らかにする。
● 「保留」の解消に期限を決める。
● 「保留」によるスプリントスケジュール影響を見える化してお客さんと調整できるよ
うにする。

31. ミッション設定とスキルの評価
SIerが好んで採用する、ITSSという指標は
経験と実績の評価メインで測定が難しい

32. スキルバッジ システム
行動評価＋360度評価＋ゲーミフィケーション
✔ そのスキルの具体的な行動を示し、その行動
を普段とることを目標とする。
✔ 他者からの仕事の中での評価(Good Job)に
よってバッジが集まる。

33. Example
Dicon役者 (エンジニアリング系)
✔ Seasar2コンテナのデプロイの仕組みがわかる。
✔ HotDeploy、CoolDeployの違いがわかる。
✔ diconを１から記述でき、環境差異を考慮し整理できる。
フィールドマネージャ (マネジメント系)
✔ プロジェクトの開発現場で起きている問題を、開発現場で使
われている言葉で理解し、打ち手を考え実行できる。
✔ チームで解決できない問題を察知し、取り除く手伝いをす
る。
✔ 顧客との折衝をにないプロジェクトを迷走させないようにす
る。

34. こういうサイクル
目指すバッジを宣言する
チームの目標と照らし合
仕事のなかで評価する わせて、目指すバッジの
調整をする

35. チームの維持のしかた
How to keep the same team.
ヒト、クーダサーイ

36. SIerのチーム作り方の変遷
インターネット チームに案件を割り当てる
ビジネス黎明期
プロジェクト規模増大に伴い…
インターネット 案件に人を割り当てる
ビジネス隆盛期
(かき集める)
チーム力を成長させるということが出来にくくなった

37. チームを維持しようとしても外圧がかかる
うまいこと開発案件を入れてくことは困難なので、
空きがでる期間がある
➔人持って行かれる
そういう外圧から守るために…

38. ソリューションを売るチームに仕立てる
ここで「ソリューション」と呼んでいるのは…

39. Selfish Solution
いわゆる「ソリューションを担ぐ」ってやつ
販売すること自体が目的
「中間マージン」で儲けてやるぜ
こういうのではなく…

40. Real Solution
✔早く安く顧客にシステムを届けるための基盤
✔営業用にパッケージっぽくもみえるようにして
おく
それを使ってアプリケーションを作れる人そのものに
価値があるので、剥がされにくくなります。

41. こういうサイクル
プロジェクトA プロジェクトB
機能追加
提案する 使う Bug Fix 提案する 使う
ソリューション開発 ソリューション開発

42. プロダクトのつくりかた
How to make products.

43. Product Managerは
どういう類のコードを書くか?

44. チームの仕事が、ページの表示項
目とDBのマッピングになるよう
に、その周辺の機能・ツールを書
きます。
再利用・非ロックインのために
オープンソースで！

45. Open source for SIer
✗ ただで使えてコスト削減
✗ 公開しとけば世界中の人が使ってくれて品質
があがるよ
✗ オープンソースの方が品質が高いよ
✔ライセンス譲渡する必要のないコード保護
✔「ググってコピペ」をさせないため

46. GitHubとの付き合い方
✔SIerではじめるときは「業務外」で作るほうが
無難
✔ライセンスを明記しましょう
✔作ったものを業務で使うようにしましょう
✔チームメンバにもGitHubアカウントを作ってもらい、
issue/pull requestのやりとりをしましょう

47. こういうサイクル
プロジェクトA プロジェクトB
プロジェクトB
仕様のこだわ ふりかえりで プロトタイプ
りが強く実装 実装詰まった
難儀なのでお /手を取られ
Issue/
断りした機能 ているところ
使う PullRequest
アイデア 作る バグ修正

48. まとめ

49. みなさんも最強の
ふつうの受託開発チームをつくって
みませんか？