Submit Search
Upload
ふつうの受託開発チームのつくりかた
•
188 likes
•
16,606 views
Yoshitaka Kawashima
Follow
For the session A-4 ,DevLOVE Kansai 2012 Drive.
Read less
Read more
Technology
Report
Share
Report
Share
1 of 49
Recommended
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
Yoshitaka Kawashima
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
Recommended
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
Yoshitaka Kawashima
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
AutoGluonではじめるAutoML
AutoGluonではじめるAutoML
西岡 賢一郎
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
先端技術とメディア表現1 #FTMA15
先端技術とメディア表現1 #FTMA15
Yoichi Ochiai
「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側
「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側
Takeshi HASEGAWA
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
統計的係り受け解析入門
統計的係り受け解析入門
Yuya Unno
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
増田 亨
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由
増田 亨
型安全性入門
型安全性入門
Akinori Abe
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
Yoshitaka Kawashima
Rustに触れて私のPythonはどう変わったか
Rustに触れて私のPythonはどう変わったか
ShunsukeNakamura17
Data-Centric AIの紹介
Data-Centric AIの紹介
Kazuyuki Miyazawa
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
ドメイン駆動設計 ~ユーザー、モデル、エンジニアの新たな関係~
ドメイン駆動設計 ~ユーザー、モデル、エンジニアの新たな関係~
啓 杉本
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
はじめてのScrumこれから大切にしたいこと Release#2
はじめてのScrumこれから大切にしたいこと Release#2
Takenori Takaki
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
More Related Content
What's hot
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
AutoGluonではじめるAutoML
AutoGluonではじめるAutoML
西岡 賢一郎
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
先端技術とメディア表現1 #FTMA15
先端技術とメディア表現1 #FTMA15
Yoichi Ochiai
「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側
「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側
Takeshi HASEGAWA
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
統計的係り受け解析入門
統計的係り受け解析入門
Yuya Unno
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
増田 亨
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由
増田 亨
型安全性入門
型安全性入門
Akinori Abe
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
Yoshitaka Kawashima
Rustに触れて私のPythonはどう変わったか
Rustに触れて私のPythonはどう変わったか
ShunsukeNakamura17
Data-Centric AIの紹介
Data-Centric AIの紹介
Kazuyuki Miyazawa
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
ドメイン駆動設計 ~ユーザー、モデル、エンジニアの新たな関係~
ドメイン駆動設計 ~ユーザー、モデル、エンジニアの新たな関係~
啓 杉本
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
What's hot
(20)
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
AutoGluonではじめるAutoML
AutoGluonではじめるAutoML
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
先端技術とメディア表現1 #FTMA15
先端技術とメディア表現1 #FTMA15
「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側
「スプラトゥーン」リアルタイム画像解析ツール 「IkaLog」の裏側
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
統計的係り受け解析入門
統計的係り受け解析入門
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由
型安全性入門
型安全性入門
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
Rustに触れて私のPythonはどう変わったか
Rustに触れて私のPythonはどう変わったか
Data-Centric AIの紹介
Data-Centric AIの紹介
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
ドメイン駆動設計 ~ユーザー、モデル、エンジニアの新たな関係~
ドメイン駆動設計 ~ユーザー、モデル、エンジニアの新たな関係~
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Similar to ふつうの受託開発チームのつくりかた
はじめてのScrumこれから大切にしたいこと Release#2
はじめてのScrumこれから大切にしたいこと Release#2
Takenori Takaki
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
[Biz reach qa meetup] qa team_build
[Biz reach qa meetup] qa team_build
久仁朗 山本(旧姓 村上)
"Business Model canvas", "Empathy Map", "Lean Canvas" のワークショップのスライド(仮)
"Business Model canvas", "Empathy Map", "Lean Canvas" のワークショップのスライド(仮)
masashi takehara
To be sn agile enterprise
To be sn agile enterprise
Rakuten Group, Inc.
Scrum"再"入門
Scrum"再"入門
You&I
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
Yoshihito Kuranuki
アジャイル開発&TFS導入
アジャイル開発&TFS導入
You&I
アジャイルマネジメントとは?
アジャイルマネジメントとは?
Kiro Harada
Vantan shinsuke miyaki_upload
Vantan shinsuke miyaki_upload
Shinsuke Miyaki
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
満徳 関
Ishihara wcan autumn_2013
Ishihara wcan autumn_2013
Takashi Ishihara
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
Miho Nagase
アート・オブ・アジャイル デベロップメント 〜テストが駆動するビジネス価値〜
アート・オブ・アジャイル デベロップメント 〜テストが駆動するビジネス価値〜
Fumihiko Kinoshita
Introduction to Agile - how business and engineer team up
Introduction to Agile - how business and engineer team up
Kenji Hiranabe
どうすれば小さなチームでも大きな成果を出せるのか
どうすれば小さなチームでも大きな成果を出せるのか
Yoshihito Kuranuki
JIRA collaboration without walls [JIRAが引き出す現場力] #JiraServiceDesk
JIRA collaboration without walls [JIRAが引き出す現場力] #JiraServiceDesk
智治 長沢
ワークショップ 明日からはじめるアジャイル
ワークショップ 明日からはじめるアジャイル
ESM SEC
「ビジネスモデルYOU」ワークショップ(BMGとBMYで何かやる #6 )公開用
「ビジネスモデルYOU」ワークショップ(BMGとBMYで何かやる #6 )公開用
masashi takehara
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)
IMJ Corporation
Similar to ふつうの受託開発チームのつくりかた
(20)
はじめてのScrumこれから大切にしたいこと Release#2
はじめてのScrumこれから大切にしたいこと Release#2
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[デブサミ関西2013]チケット駆動でプロジェクトチームを加速せよ
[Biz reach qa meetup] qa team_build
[Biz reach qa meetup] qa team_build
"Business Model canvas", "Empathy Map", "Lean Canvas" のワークショップのスライド(仮)
"Business Model canvas", "Empathy Map", "Lean Canvas" のワークショップのスライド(仮)
To be sn agile enterprise
To be sn agile enterprise
Scrum"再"入門
Scrum"再"入門
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
アジャイル開発&TFS導入
アジャイル開発&TFS導入
アジャイルマネジメントとは?
アジャイルマネジメントとは?
Vantan shinsuke miyaki_upload
Vantan shinsuke miyaki_upload
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
Azure DevOps × スクラム で実現するプロダクト開発のポイント #dotnetlab #jazug
Ishihara wcan autumn_2013
Ishihara wcan autumn_2013
Agile-development-course-advanced-1-2
Agile-development-course-advanced-1-2
アート・オブ・アジャイル デベロップメント 〜テストが駆動するビジネス価値〜
アート・オブ・アジャイル デベロップメント 〜テストが駆動するビジネス価値〜
Introduction to Agile - how business and engineer team up
Introduction to Agile - how business and engineer team up
どうすれば小さなチームでも大きな成果を出せるのか
どうすれば小さなチームでも大きな成果を出せるのか
JIRA collaboration without walls [JIRAが引き出す現場力] #JiraServiceDesk
JIRA collaboration without walls [JIRAが引き出す現場力] #JiraServiceDesk
ワークショップ 明日からはじめるアジャイル
ワークショップ 明日からはじめるアジャイル
「ビジネスモデルYOU」ワークショップ(BMGとBMYで何かやる #6 )公開用
「ビジネスモデルYOU」ワークショップ(BMGとBMYで何かやる #6 )公開用
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)
More from Yoshitaka Kawashima
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
Are Design Patterns Dead?
Are Design Patterns Dead?
Yoshitaka Kawashima
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
Yoshitaka Kawashima
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
本番障害に至る病
本番障害に至る病
Yoshitaka Kawashima
システムダウンのひみつ
システムダウンのひみつ
Yoshitaka Kawashima
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
アンチフラジャイルの世界
アンチフラジャイルの世界
Yoshitaka Kawashima
Atomic Architecture
Atomic Architecture
Yoshitaka Kawashima
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
How to find tech books
How to find tech books
Yoshitaka Kawashima
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
Yoshitaka Kawashima
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
Yoshitaka Kawashima
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Yoshitaka Kawashima
Antifragile Clojure
Antifragile Clojure
Yoshitaka Kawashima
Boilerplate vs Magic
Boilerplate vs Magic
Yoshitaka Kawashima
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Yoshitaka Kawashima
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Yoshitaka Kawashima
More from Yoshitaka Kawashima
(20)
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Are Design Patterns Dead?
Are Design Patterns Dead?
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Tackling Complexity
Tackling Complexity
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
本番障害に至る病
本番障害に至る病
システムダウンのひみつ
システムダウンのひみつ
Mavenの真実とウソ
Mavenの真実とウソ
アンチフラジャイルの世界
アンチフラジャイルの世界
Atomic Architecture
Atomic Architecture
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
How to find tech books
How to find tech books
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Antifragile Clojure
Antifragile Clojure
Boilerplate vs Magic
Boilerplate vs Magic
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
ふつうの受託開発チームのつくりかた
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 -
8.
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.2パターンの原因がある。 ①テストケースの消化をが忘れてしまった。 ②ブロック(課題)があり今できないケースをそのまま放置した。 放置したケースに気づくのが遅くなった。
30.
【「残業が増えたのはなぜか」の解決策検討】 ①に対しての解決策 ◆Storyとテストケースを関連付けてちゃんと把握しましょう。 ◆テストの実施完了を持ってStoryの完了としましょう。不具合改修は除く。 ◆テスト未実施とブロックをちゃんと分けましょう(今はできないをきちんと「保留」 として扱いましょう。 ②に対しての解決策 「保留」を管理する。 ◆「保留」が出るのは3タイミング ●
計画MTG:他責は取り除く。取り除き方は、「キメとして実装」or[そもそもStoryに いれない」のどっちか ● 実装時:懸案チケットとしてきちんと上げましょう。(QAがスクラムマスタと相談し て懸案かどうか判断する) ● テスト時:懸案チケットとしてきちんと上げましょう。(QAがスクラムマスタと相談 して懸案かどうか判断する) ◆「保留」の管理 ● 「保留」が出た箇所は他責か自責かを明らかにする。 ● 「保留」の解消に期限を決める。 ● 「保留」によるスプリントスケジュール影響を見える化してお客さんと調整できるよ うにする。
31.
ミッション設定とスキルの評価 SIerが好んで採用する、ITSSという指標は 経験と実績の評価メインで測定が難しい
32.
スキルバッジ システム
行動評価+360度評価+ゲーミフィケーション ✔ そのスキルの具体的な行動を示し、その行動 を普段とることを目標とする。 ✔ 他者からの仕事の中での評価(Good Job)に よってバッジが集まる。
33.
Example Dicon役者 (エンジニアリング系)
✔ Seasar2コンテナのデプロイの仕組みがわかる。 ✔ HotDeploy、CoolDeployの違いがわかる。 ✔ diconを1から記述でき、環境差異を考慮し整理できる。 フィールドマネージャ (マネジメント系) ✔ プロジェクトの開発現場で起きている問題を、開発現場で使 われている言葉で理解し、打ち手を考え実行できる。 ✔ チームで解決できない問題を察知し、取り除く手伝いをす る。 ✔ 顧客との折衝をにないプロジェクトを迷走させないようにす る。
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.
みなさんも最強の ふつうの受託開発チームをつくって
みませんか?