ふつうの受託開発チームのつくりかた
Report
Yoshitaka KawashimaFollow
Nov. 10, 2012•0 likes•16,448 views
188 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
ふつうの受託開発チームのつくりかた
Nov. 10, 2012•0 likes•16,448 views
188 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Report
Technology
For the session A-4 ,DevLOVE Kansai 2012 Drive.
Yoshitaka KawashimaFollow
ふつうの受託開発チームのつくりかた
- ふつうの受託開発チームのつくりかた 手塚モデルの実践編 @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 Budget/Cost Architecture Deadline/Progress Scope Sprint Planning マンガプロダクションと担当編集の関係に着想
- 分業のねらい ✔ 大手SIerに不足しがちな"プロジェクト マネージャ"という役割の責務を減らす ✔ 受託開発でつくるソフトウェアの設計品 質に責任をもつ役割を作る
- 開発のしかた How to develop software.
- 開発プロセス いたってふつうのスクラム アーキテクチャ いたってふつうのSAStruts MVC これらを案件ごとに変えず固定化するのが大事
- オーソドックスにやるのは わりと難しい 業務ドメインの特殊性や組織事情のせいで、教科書 どおりやるのは難しい、って言っちゃいがち 実はエンジニアリングの熟練度不足に起因するのでは?
- よこみち エンジニアは紆余曲折をへて オーソドックス(王道)にたどり着く
- Engineer's Lifecycle ミーハー期 オレオレ期 王道期 べんりや期 こんな変遷をたどる気がする…
- ミーハー期 ✔ホッテントリのものを試してみたい ✔業務で使うとかは関係なく、ハヤリものは後 学のために試してみる
- オレオレ期 ✔カスタマイズしたがる ✔「車輪の再発明も重要なんだよ」 ✔メジャーなプロダクトのいけてないところを あげつらう
- 王道期 ✔標準を軽視しない ✔巨人の肩の上に立つ ✔SAStrutsの設計は、まさに王道の設計
- べんりや期 ✔トラブルプロジェクトを渡り歩く(火消し) ✔早く仕事を終わらせても、他人の仕事がま わってくる はやく「仕組みを作る側」にまわれる道を探しましょう
- 王道を貫くにはハイスキルと くじけぬこころが要求される コードを書いて精進しよう 高い生産性はだいたいの問題を解決する
- チーム`力to build a team. How のつくりかた
- SIerに入社してくる人は、 ✔ 見積りの正確性 ✔ タスクの完了責任 の意識が高い。 なので、そういうところの指導はおいとい て、 まず徹底したチームプレイを指導してます
- Pair Programming ふつうのチームにおいて、単独の作業だと十分 な質の成果物ができにくい 必然的にペアプロせざるをえない
- ふりかえり駆動のチーム力強化 スプリントふりかえりの例 【T】ストーリーからかんばんタスクへブレークダウン後にタ スクを積み上げて目的を果たしているか確認する。 【P】もれがおおい より 【T】”すげぇ”コードを書いたらみんなに自慢をする。その ための発表会をセッティングし、発表する。 【会話】他の人から学ぶ。学んだことを展開する。より 【T】タスクはナビゲーターが責任を持ってクローズする。カ ンバンの名前をナビゲーターの名前にしてクローズする。 【P】ナビゲーターの役割が薄い。より
- プロジェクト振り返り スプリント毎のふりかえりでは話しきれな かった重めのテーマをあつかいます
- 【「残業が増えたのはなぜか」のFIVE WHYS】 Q1「残業が増えたのはなぜか」 A1.残不具合が減らないから。 Q2.なぜ残不具合が減らないのか。 A2.テストケース消化が後ろ延ばしになってしまったから。 Q3.テストケース消化が後ろ延ばしになってしまったのはなぜか？ A3.Sprintごとのストーリー完了を蔑ろにしていたから。 Q4.Sprintごとのストーリー完了を蔑ろにしていたからのはなぜか？ A4.「出来るところは全部できました！」といって忘れ去られているストーリー完 了があったから。 Q5.忘れ去られているのはなぜか？ A5.２パターンの原因がある。 ①テストケースの消化をが忘れてしまった。 ②ブロック（課題）があり今できないケースをそのまま放置した。 放置したケースに気づくのが遅くなった。
- 【「残業が増えたのはなぜか」の解決策検討】 ①に対しての解決策 ◆Storyとテストケースを関連付けてちゃんと把握しましょう。 ◆テストの実施完了を持ってStoryの完了としましょう。不具合改修は除く。 ◆テスト未実施とブロックをちゃんと分けましょう（今はできないをきちんと「保留」 として扱いましょう。 ②に対しての解決策 「保留」を管理する。 ◆「保留」が出るのは３タイミング ● 計画MTG：他責は取り除く。取り除き方は、「キメとして実装」or[そもそもStoryに いれない」のどっちか ● 実装時：懸案チケットとしてきちんと上げましょう。（QAがスクラムマスタと相談し て懸案かどうか判断する） ● テスト時：懸案チケットとしてきちんと上げましょう。（QAがスクラムマスタと相談 して懸案かどうか判断する） ◆「保留」の管理 ● 「保留」が出た箇所は他責か自責かを明らかにする。 ● 「保留」の解消に期限を決める。 ● 「保留」によるスプリントスケジュール影響を見える化してお客さんと調整できるよ うにする。
- ミッション設定とスキルの評価 SIerが好んで採用する、ITSSという指標は 経験と実績の評価メインで測定が難しい
- スキルバッジ システム 行動評価＋360度評価＋ゲーミフィケーション ✔ そのスキルの具体的な行動を示し、その行動 を普段とることを目標とする。 ✔ 他者からの仕事の中での評価(Good Job)に よってバッジが集まる。
- Example Dicon役者 (エンジニアリング系) ✔ Seasar2コンテナのデプロイの仕組みがわかる。 ✔ HotDeploy、CoolDeployの違いがわかる。 ✔ diconを１から記述でき、環境差異を考慮し整理できる。 フィールドマネージャ (マネジメント系) ✔ プロジェクトの開発現場で起きている問題を、開発現場で使 われている言葉で理解し、打ち手を考え実行できる。 ✔ チームで解決できない問題を察知し、取り除く手伝いをす る。 ✔ 顧客との折衝をにないプロジェクトを迷走させないようにす る。
- こういうサイクル 目指すバッジを宣言する チームの目標と照らし合 仕事のなかで評価する わせて、目指すバッジの 調整をする
- チームの維持のしかた 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アカウントを作ってもらい、 issue/pull requestのやりとりをしましょう
- こういうサイクル プロジェクトA プロジェクトB プロジェクトB 仕様のこだわ ふりかえりで プロトタイプ りが強く実装 実装詰まった 難儀なのでお /手を取られ Issue/ 断りした機能 ているところ 使う PullRequest アイデア 作る バグ修正
- まとめ
- みなさんも最強の ふつうの受託開発チームをつくって みませんか？