Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ふつうの受託開発チームのつくりかた
           手塚モデルの実践編




           @kawasima
@kawasima
Past Slides




http://www.slideshare.net/kawasima/
2011 DevLOVE HangerFlight - Snow Barrage -
2011 DevLOVE HangerFlight - Snow Barrage -
2011 DevLOVE HangerFlight - Snow Barrage -
2011 DevLOVE HangerFlight - Snow Barrage -
チームの構成のしかた
  How to construct a team.
体制

         Product Manager   Project Manager
        (プロダクトそのものの品質管理)   (予算/費用の管理)




     特に選抜してないふつうの4年目以下のメンバ
SIerの組織心理を利用して集める

人月ビジネスのSIerにとって、1人月分の成果を
出せない駆け出しを引き受けてくれるチームは
ありがたい



 これを利用して、まだ普通のSIerの仕事のやり方
 を知らない若手をゲットします
役割分担
 Product Manager
 Product Manager         Project Manager
                         Project Manager

 Design Quality  ...
分業のねらい


✔ 大手SIerに不足しがちな"プロジェクト

マネージャ"という役割の責務を減らす
✔ 受託開発でつくるソフトウェアの設計品

質に責任をもつ役割を作る
開発のしかた
How to develop software.
開発プロセス

いたってふつうのスクラム
アーキテクチャ

いたってふつうのSAStruts MVC




これらを案件ごとに変えず固定化するのが大事
オーソドックスにやるのは
     わりと難しい

業務ドメインの特殊性や組織事情のせいで、教科書
どおりやるのは難しい、って言っちゃいがち




 実はエンジニアリングの熟練度不足に起因するのでは?
よこみち




 エンジニアは紆余曲折をへて
オーソドックス(王道)にたどり着く
Engineer's Lifecycle


ミーハー期   オレオレ期      王道期



           べんりや期




        こんな変遷をたどる気がする…
ミーハー期
✔ホッテントリのものを試してみたい



✔業務で使うとかは関係なく、ハヤリものは後


学のために試してみる
オレオレ期
✔カスタマイズしたがる



✔「車輪の再発明も重要なんだよ」



✔メジャーなプロダクトのいけてないところを


あげつらう
王道期

✔標準を軽視しない



✔巨人の肩の上に立つ



✔SAStrutsの設計は、まさに王道の設計
べんりや期

✔トラブルプロジェクトを渡り歩く(火消し)



✔早く仕事を終わらせても、他人の仕事がま


わってくる



 はやく「仕組みを作る側」にまわれる道を探しましょう
王道を貫くにはハイスキルと
くじけぬこころが要求される
  コードを書いて精進しよう
  高い生産性はだいたいの問題を解決する
チーム`力to build a team.
   How
       のつくりかた
SIerに入社してくる人は、
   ✔   見積りの正確性
   ✔   タスクの完了責任
   の意識が高い。

なので、そういうところの指導はおいとい
て、
まず徹底したチームプレイを指導してます
Pair Programming

ふつうのチームにおいて、単独の作業だと十分
な質の成果物ができにくい

必然的にペアプロせざるをえない
ふりかえり駆動のチーム力強化
スプリントふりかえりの例
【T】ストーリーからかんばんタスクへブレークダウン後にタ
スクを積み上げて目的を果たしているか確認する。
【P】もれがおおい より


【T】”すげぇ”コードを書いたらみんなに自慢をする。...
プロジェクト振り返り




スプリント毎のふりかえりでは話しきれな
かった重めのテーマをあつかいます
【「残業が増えたのはなぜか」のFIVE WHYS】


Q1「残業が増えたのはなぜか」
A1.残不具合が減らないから。


Q2.なぜ残不具合が減らないのか。
A2.テストケース消化が後ろ延ばしになってしまったから。


Q3.テストケース消化...
【「残業が増えたのはなぜか」の解決策検討】
①に対しての解決策
◆Storyとテストケースを関連付けてちゃんと把握しましょう。
◆テストの実施完了を持ってStoryの完了としましょう。不具合改修は除く。
◆テスト未実施とブロックをちゃんと分けま...
ミッション設定とスキルの評価




SIerが好んで採用する、ITSSという指標は
経験と実績の評価メインで測定が難しい
スキルバッジ システム
    行動評価+360度評価+ゲーミフィケーション




✔ そのスキルの具体的な行動を示し、その行動

を普段とることを目標とする。
✔ 他者からの仕事の中での評価(Good    Job)に
よってバッジが集まる。
Example
 Dicon役者 (エンジニアリング系)

 ✔   Seasar2コンテナのデプロイの仕組みがわかる。
 ✔   HotDeploy、CoolDeployの違いがわかる。
 ✔   diconを1から記述でき、環境差異を考慮し...
こういうサイクル

    目指すバッジを宣言する




             チームの目標と照らし合
仕事のなかで評価する   わせて、目指すバッジの
             調整をする
チームの維持のしかた
  How to keep the same team.




                 ヒト、クーダサーイ
SIerのチーム作り方の変遷

インターネット   チームに案件を割り当てる
ビジネス黎明期
           プロジェクト規模増大に伴い…

インターネット   案件に人を割り当てる
ビジネス隆盛期
          (かき集める)

...
チームを維持しようとしても外圧がかかる


うまいこと開発案件を入れてくことは困難なので、
空きがでる期間がある

 ➔人持って行かれる




         そういう外圧から守るために…
ソリューションを売るチームに仕立てる




   ここで「ソリューション」と呼んでいるのは…
Selfish Solution

いわゆる「ソリューションを担ぐ」ってやつ

販売すること自体が目的
「中間マージン」で儲けてやるぜ




        こういうのではなく…
Real Solution
✔早く安く顧客にシステムを届けるための基盤



✔営業用にパッケージっぽくもみえるようにして


おく



それを使ってアプリケーションを作れる人そのものに
価値があるので、剥がされにくくなります。
こういうサイクル


            プロジェクトA                     プロジェクトB
                 機能追加
   提案する     使う   Bug Fix    提案する       使う...
プロダクトのつくりかた
   How to make products.
Product Managerは
どういう類のコードを書くか?
チームの仕事が、ページの表示項
目とDBのマッピングになるよう
に、その周辺の機能・ツールを書
きます。


   再利用・非ロックインのために
      オープンソースで!
Open source for SIer
✗ ただで使えてコスト削減
✗ 公開しとけば世界中の人が使ってくれて品質
  があがるよ
✗ オープンソースの方が品質が高いよ

✔ライセンス譲渡する必要のないコード保護
✔「ググってコピペ」をさせない...
GitHubとの付き合い方
✔SIerではじめるときは「業務外」で作るほうが


無難

✔ライセンスを明記しましょう



✔作ったものを業務で使うようにしましょう



✔チームメンバにもGitHubアカウントを作ってもらい、


issu...
こういうサイクル


     プロジェクトA                プロジェクトB
                  プロジェクトB
仕様のこだわ   ふりかえりで   プロトタイプ
りが強く実装   実装詰まった
難儀なのでお  ...
まとめ
みなさんも最強の
ふつうの受託開発チームをつくって
     みませんか?
ふつうの受託開発チームのつくりかた
You’ve finished this document.
Upcoming SlideShare
ウォーターフォールとアジャイルのフェアな比較
Next
Upcoming SlideShare
ウォーターフォールとアジャイルのフェアな比較
Next

Share

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

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

Related Books

Free with a 30 day trial from Scribd

See all

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

  1. 1. ふつうの受託開発チームのつくりかた 手塚モデルの実践編 @kawasima
  2. 2. @kawasima
  3. 3. Past Slides http://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. Engineer's 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. みなさんも最強の ふつうの受託開発チームをつくって みませんか?
  • JunKawasaki

    Sep. 24, 2020
  • tk23ohtani

    Jul. 13, 2019
  • southernx0604

    Dec. 16, 2018
  • satoshiichikawa12

    Apr. 17, 2018
  • MayuMurakami

    Jan. 9, 2018
  • onishicba

    Oct. 28, 2017
  • minako.kubo

    Jun. 18, 2017
  • ShingoYamazaki

    May. 31, 2017
  • lofty_hyde

    May. 18, 2017
  • mserikawa1

    Apr. 29, 2017
  • chan_tk

    Mar. 28, 2017
  • ToshiakiIto

    Mar. 19, 2017
  • yusukeendo3958

    Mar. 6, 2017
  • komeshogun

    Feb. 14, 2017
  • hirokitoya

    Dec. 26, 2016
  • yumios

    Dec. 25, 2016
  • OkadaShiena

    Dec. 3, 2016
  • taktyler

    Jun. 11, 2016
  • mayosuke

    Mar. 10, 2016
  • mamorumurayama

    Dec. 10, 2015

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

Views

Total views

45,318

On Slideshare

0

From embeds

0

Number of embeds

3,988

Actions

Downloads

0

Shares

0

Comments

0

Likes

186

×