ふつうの受託開発チームのつくりかた

40,095 views

Published on

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

Published in: Technology
2 Comments
180 Likes
Statistics
Notes
  • @ledsun1 おぉ、そのとおりだと思います。一応、'クオリティを下げない記号表現'については、'お決まりのパターン'というのを定義してあるのですが、手塚センセイと同じように、リモートで「何番のパターン」って指示すれば、そのとおり書き上がるってレベルには到達できてないのですよね…

    'ウケることが分かっているキャラクター'のカギは、ソリューションのくだりのスライドを考えています。当日はうちのチームのソリューションの資料をお見せしたのですが、まだおおっぴらにできる手筈が整ってなくて…
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 手塚治虫をモデルにするなら、クオリティを下げない記号表現と、ウケることが分かっているキャラクターが必要ですね。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
40,095
On SlideShare
0
From Embeds
0
Number of Embeds
3,815
Actions
Shares
0
Downloads
0
Comments
2
Likes
180
Embeds 0
No embeds

No notes for slide

ふつうの受託開発チームのつくりかた

  1. 1. ふつうの受託開発チームのつくりかた 手塚モデルの実践編 @kawasima
  2. 2. @kawasima
  3. 3. Past Slideshttp://www.slideshare.net/kawasima/
  4. 4. 2011 DevLOVE HangerFlight - Snow Barrage -
  5. 5. 2011 DevLOVE HangerFlight - Snow Barrage -
  6. 6. 2011 DevLOVE HangerFlight - Snow Barrage -
  7. 7. 2011 DevLOVE HangerFlight - Snow Barrage -
  8. 8. チームの構成のしかた How to construct a team.
  9. 9. 体制 Product Manager Project Manager (プロダクトそのものの品質管理) (予算/費用の管理) 特に選抜してないふつうの4年目以下のメンバ
  10. 10. SIerの組織心理を利用して集める人月ビジネスのSIerにとって、1人月分の成果を出せない駆け出しを引き受けてくれるチームはありがたい これを利用して、まだ普通のSIerの仕事のやり方 を知らない若手をゲットします
  11. 11. 役割分担 Product Manager Product Manager Project Manager Project Manager Design Quality Budget/Cost Architecture Deadline/Progress Scope Sprint Planningマンガプロダクションと担当編集の関係に着想
  12. 12. 分業のねらい✔ 大手SIerに不足しがちな"プロジェクトマネージャ"という役割の責務を減らす✔ 受託開発でつくるソフトウェアの設計品質に責任をもつ役割を作る
  13. 13. 開発のしかたHow to develop software.
  14. 14. 開発プロセスいたってふつうのスクラムアーキテクチャいたってふつうのSAStruts MVCこれらを案件ごとに変えず固定化するのが大事
  15. 15. オーソドックスにやるのは わりと難しい業務ドメインの特殊性や組織事情のせいで、教科書どおりやるのは難しい、って言っちゃいがち 実はエンジニアリングの熟練度不足に起因するのでは?
  16. 16. よこみち エンジニアは紆余曲折をへてオーソドックス(王道)にたどり着く
  17. 17. Engineers Lifecycleミーハー期 オレオレ期 王道期 べんりや期 こんな変遷をたどる気がする…
  18. 18. ミーハー期✔ホッテントリのものを試してみたい✔業務で使うとかは関係なく、ハヤリものは後学のために試してみる
  19. 19. オレオレ期✔カスタマイズしたがる✔「車輪の再発明も重要なんだよ」✔メジャーなプロダクトのいけてないところをあげつらう
  20. 20. 王道期✔標準を軽視しない✔巨人の肩の上に立つ✔SAStrutsの設計は、まさに王道の設計
  21. 21. べんりや期✔トラブルプロジェクトを渡り歩く(火消し)✔早く仕事を終わらせても、他人の仕事がまわってくる はやく「仕組みを作る側」にまわれる道を探しましょう
  22. 22. 王道を貫くにはハイスキルとくじけぬこころが要求される コードを書いて精進しよう 高い生産性はだいたいの問題を解決する
  23. 23. チーム`力to build a team. How のつくりかた
  24. 24. SIerに入社してくる人は、 ✔ 見積りの正確性 ✔ タスクの完了責任 の意識が高い。なので、そういうところの指導はおいといて、まず徹底したチームプレイを指導してます
  25. 25. Pair Programmingふつうのチームにおいて、単独の作業だと十分な質の成果物ができにくい必然的にペアプロせざるをえない
  26. 26. ふりかえり駆動のチーム力強化スプリントふりかえりの例【T】ストーリーからかんばんタスクへブレークダウン後にタスクを積み上げて目的を果たしているか確認する。【P】もれがおおい より【T】”すげぇ”コードを書いたらみんなに自慢をする。そのための発表会をセッティングし、発表する。【会話】他の人から学ぶ。学んだことを展開する。より【T】タスクはナビゲーターが責任を持ってクローズする。カンバンの名前をナビゲーターの名前にしてクローズする。【P】ナビゲーターの役割が薄い。より
  27. 27. プロジェクト振り返りスプリント毎のふりかえりでは話しきれなかった重めのテーマをあつかいます
  28. 28. 【「残業が増えたのはなぜか」のFIVE WHYS】Q1「残業が増えたのはなぜか」A1.残不具合が減らないから。Q2.なぜ残不具合が減らないのか。A2.テストケース消化が後ろ延ばしになってしまったから。Q3.テストケース消化が後ろ延ばしになってしまったのはなぜか?A3.Sprintごとのストーリー完了を蔑ろにしていたから。Q4.Sprintごとのストーリー完了を蔑ろにしていたからのはなぜか?A4.「出来るところは全部できました!」といって忘れ去られているストーリー完了があったから。Q5.忘れ去られているのはなぜか?A5.2パターンの原因がある。 ①テストケースの消化をが忘れてしまった。  ②ブロック(課題)があり今できないケースをそのまま放置した。  放置したケースに気づくのが遅くなった。
  29. 29. 【「残業が増えたのはなぜか」の解決策検討】①に対しての解決策◆Storyとテストケースを関連付けてちゃんと把握しましょう。◆テストの実施完了を持ってStoryの完了としましょう。不具合改修は除く。◆テスト未実施とブロックをちゃんと分けましょう(今はできないをきちんと「保留」として扱いましょう。②に対しての解決策「保留」を管理する。◆「保留」が出るのは3タイミング● 計画MTG:他責は取り除く。取り除き方は、「キメとして実装」or[そもそもStoryに いれない」のどっちか● 実装時:懸案チケットとしてきちんと上げましょう。(QAがスクラムマスタと相談し て懸案かどうか判断する)● テスト時:懸案チケットとしてきちんと上げましょう。(QAがスクラムマスタと相談 して懸案かどうか判断する)◆「保留」の管理● 「保留」が出た箇所は他責か自責かを明らかにする。● 「保留」の解消に期限を決める。● 「保留」によるスプリントスケジュール影響を見える化してお客さんと調整できるよ うにする。
  30. 30. ミッション設定とスキルの評価SIerが好んで採用する、ITSSという指標は経験と実績の評価メインで測定が難しい
  31. 31. スキルバッジ システム 行動評価+360度評価+ゲーミフィケーション✔ そのスキルの具体的な行動を示し、その行動を普段とることを目標とする。✔ 他者からの仕事の中での評価(Good Job)によってバッジが集まる。
  32. 32. Example Dicon役者 (エンジニアリング系) ✔ Seasar2コンテナのデプロイの仕組みがわかる。 ✔ HotDeploy、CoolDeployの違いがわかる。 ✔ diconを1から記述でき、環境差異を考慮し整理できる。 フィールドマネージャ (マネジメント系) ✔ プロジェクトの開発現場で起きている問題を、開発現場で使 われている言葉で理解し、打ち手を考え実行できる。 ✔ チームで解決できない問題を察知し、取り除く手伝いをす る。 ✔ 顧客との折衝をにないプロジェクトを迷走させないようにす る。
  33. 33. こういうサイクル 目指すバッジを宣言する チームの目標と照らし合仕事のなかで評価する わせて、目指すバッジの 調整をする
  34. 34. チームの維持のしかた How to keep the same team. ヒト、クーダサーイ
  35. 35. SIerのチーム作り方の変遷インターネット チームに案件を割り当てるビジネス黎明期 プロジェクト規模増大に伴い…インターネット 案件に人を割り当てるビジネス隆盛期 (かき集める)チーム力を成長させるということが出来にくくなった
  36. 36. チームを維持しようとしても外圧がかかるうまいこと開発案件を入れてくことは困難なので、空きがでる期間がある ➔人持って行かれる そういう外圧から守るために…
  37. 37. ソリューションを売るチームに仕立てる ここで「ソリューション」と呼んでいるのは…
  38. 38. Selfish Solutionいわゆる「ソリューションを担ぐ」ってやつ販売すること自体が目的「中間マージン」で儲けてやるぜ こういうのではなく…
  39. 39. Real Solution✔早く安く顧客にシステムを届けるための基盤✔営業用にパッケージっぽくもみえるようにしておくそれを使ってアプリケーションを作れる人そのものに価値があるので、剥がされにくくなります。
  40. 40. こういうサイクル プロジェクトA プロジェクトB 機能追加 提案する 使う Bug Fix 提案する 使うソリューション開発 ソリューション開発
  41. 41. プロダクトのつくりかた How to make products.
  42. 42. Product Managerはどういう類のコードを書くか?
  43. 43. チームの仕事が、ページの表示項目とDBのマッピングになるように、その周辺の機能・ツールを書きます。 再利用・非ロックインのために オープンソースで!
  44. 44. Open source for SIer✗ ただで使えてコスト削減✗ 公開しとけば世界中の人が使ってくれて品質 があがるよ✗ オープンソースの方が品質が高いよ✔ライセンス譲渡する必要のないコード保護✔「ググってコピペ」をさせないため
  45. 45. GitHubとの付き合い方✔SIerではじめるときは「業務外」で作るほうが無難✔ライセンスを明記しましょう✔作ったものを業務で使うようにしましょう✔チームメンバにもGitHubアカウントを作ってもらい、issue/pull requestのやりとりをしましょう
  46. 46. こういうサイクル プロジェクトA プロジェクトB プロジェクトB仕様のこだわ ふりかえりで プロトタイプりが強く実装 実装詰まった難儀なのでお /手を取られ Issue/断りした機能 ているところ 使う PullRequest アイデア 作る バグ修正
  47. 47. まとめ
  48. 48. みなさんも最強のふつうの受託開発チームをつくって みませんか?

×