アジャイルチームの秘密
Upcoming SlideShare
Loading in...5
×
 

アジャイルチームの秘密

on

  • 2,180 views

長年の現場経験からうまくやっているアジャイル チームが暗黙的に理解/共有している秘訣についてまとめました

長年の現場経験からうまくやっているアジャイル チームが暗黙的に理解/共有している秘訣についてまとめました

Statistics

Views

Total Views
2,180
Views on SlideShare
2,173
Embed Views
7

Actions

Likes
11
Downloads
20
Comments
0

2 Embeds 7

http://s.deeeki.com 5
https://twitter.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

アジャイルチームの秘密 アジャイルチームの秘密 Presentation Transcript

  • アジャイルチームの秘密 ©2009-2012, Sertice Inc. All rights reserved. 1
  • はじめに•  弊社はコンサルティングサービスを通じてアジャ イルチーム立ち上げのお手伝いを行っています•  長年の現場経験からうまくやっているアジャイル チームが暗黙的に理解/共有している秘訣について お話いたします•  また、この秘訣をチームとして組織として達成/維 持するためのポイントと弊社事例も紹介いたしま す•  最後に、御社が外部のエンジニアリングリソース をうまく活用して開発部門のアジャイル対応を実 現するための課題について提案いたします 2 ©2009-2012, Sertice Inc. All rights reserved.
  • 弊社についてサーティス株式会社 事業内容 •  コンサルティング事業 –  アーキテクティングコンサル –  ビジネスアナリシスコンサル –  アジャイル開発コンサル •  アーキテクチャ事業 –  アーキテクチャの企画と開発 –  テクノロジスキャンDBの構築 設 立 : 2009年10月 –  リファレンスモデル/ベストプラク 資本金 : 500万円 ティスの販売 代 表:藤澤 悠介 •  システムエンジニアリン 所在地 : さいたま市南区 グサービス事業 –  特11-302086 http://sertice.com/ 3 ©2009-2012, Sertice Inc. All rights reserved.
  • 1.アジャイルチームの秘密 ©2009-2012, Sertice Inc. All rights reserved. 4
  • アジャイルチーム7つの秘密うまくやっているアジャイルチームが経験的に理解していることを7つピックアップしました1.  稼働時間が少ないほど成果が上がる2.  兵站能力が開発のスピードを決める3.  チームが成熟するのは次のプロジェクトから4.  付箋とペンとホワイトボードで会話する5.  開発プロセスは標準化されない6.  報告は壁に対して行う7.  プロダクトとチームと人を愛している 5 ©2009-2012, Sertice Inc. All rights reserved.
  • 1.稼働時間が少ないほど成果が上がる稼働時間が少ないほど成果が上がる✔経験則 プロジェクト開始前に必要な全ての知恵を身につけているエ ンジニアはいない•  エンジニアは学習が必要 –  就業時間内と就業時間外の両方の学習が必要 –  学習により身につけた“後知恵”をチームにフィードバック することが肝要•  個人学習とチーム学習 –  個人に足りてない知識を早急に吸収するスキル –  チームに足りてない能力を認識し調達するスキル –  調達した能力をチーム内に展開するスキル •  One for All, All for Oneの精神 –  自己組織化されたチームには“学び”は報酬となる 6 ©2009-2012, Sertice Inc. All rights reserved.
  • 2.兵站能力が開発のスピードを決める兵站能力が開発のスピードを決める•  【用語説明】兵站とは 戦闘部隊の後方にあって、人員・兵器・食糧などの前送・補 給にあたり、また、後方連絡線の確保にあたる活動機能。ア ジャイルにおける兵站とはチームメンバーが無理なく効率よ く働けるように組織またはチームが各メンバーをバックアッ プするシステムのこと。•  アジャイルに必須の兵站能力 –  SCM, Issue Tracking, WIKI, アーキテクチャ/フレームワー ク/リファレンスモデル, 開発環境/テスト環境, CI/継続的デ リバリー, TDD/BDD, –  速いマシン, マルチモニター, 広い作業机, 疲れない椅子 –  アーキテクティング, 改善, ツール生成 –  座席配置、ホワイトボードや壁の有無も兵站の一部 7 ©2009-2012, Sertice Inc. All rights reserved.
  • 3.チームが成熟するのは次のプロジェクトからチームが成熟するのは次のプロジェクトから✔経験則 チームとして最大の“気づき”が得られるのはプロジェクトの切れ目 (ウォーターフォールでもアジャイルでもそれは変わらない)•  アジャイル(Scrum)では2週間を1つのスプリントとし、 数回のスプリント回すことで開発を前に進める•  プロジェクトを成功させるためには期間を6ヶ月以内にして おくことがよい –  チームが立ち上がるまでに4Sprint消費する –  残りのスプリントを2分割し、さらにその間に1週間のショー トスプリントを挟む•  チームの組織能力≠個人能力の総和 –  チームの組織能力を成熟させる(効率的に上げる)には、プロ ジェクトに人をアサインするのではなく、チームにプロジェク トをアサインする逆転の発想が必要 8 ©2009-2012, Sertice Inc. All rights reserved.
  • 4.付箋とペンとホワイトボードで会話する付箋とペンとホワイトボードで会話する プロセスやツールよりも個人との対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを認めな がらも、私たちは右記のことがらにより価値をおく。 アジャイルソフトウェア開発宣言•  資料をI/Fとして人とコミュニケーションするのではなく、(人との 対話の触媒として)会話を“引き出す”感覚で付箋やインデックス カード、ホワードボードを使う•  コミュニケーションの目的は“動くソフトウェア作るために必要最低 限の情報を引き出すこと” “追加された価値の検証方法/計測方法を決 めること” –  アーキテクチャ設計をしていれば、実装レベルの設計書をソースコード とは別に書き起こすことにたいして意味はない –  最新であることが保証された唯一のドキュメントはテストコード 9 ©2009-2012, Sertice Inc. All rights reserved.
  • 5.開発プロセスは標準化されない開発プロセスは標準化されない✔経験則 チーム内のプロセスは各チーム内で絶えず変化している•  プロジェクトの状況やチームが取り組む課題に応じてプロセ スは変えるべき•  開発プロセスがチームのリズムを狂わせたり、開発スピード を遅らせることになってはならない –  開発プロセスはチームに考えさせるべきこと –  チームのリズムはチームそれぞれ。チームの意思を尊重するこ とが大切 –  開発スピードを出すことに注力すると思いも寄らないアイデア がチーム内から出ることがある•  標準化/正規化すべきは、プロセスではなく“検証方法”や“計測 方法” –  構築-計測-学習のフィードバックループ •  最初からレベル5でいく 10 ©2009-2012, Sertice Inc. All rights reserved.
  • 6.報告は壁に対して行う報告は壁に対して行う✔経験則 人に報告するための作業が度々発生する状況はチーム運営がうまく 回っていないときに起きる•  アジャイルチームは“透明性の確保”こそがユーザーとの信頼関係 の源泉であることを知っている –  報告の自働化 •  壁(現場)にcurrentの情報を集約する •  壁に人が集まり、状況/情報が更新される –  悪い知らせと良い知らせ •  悪い知らせはチームが進化するきっかけを与えてくれる •  チームで共有しチームで解決する •  良い知らせを使ってチームを盛り上げる•  チームに人格を持たせる –  壁はチームの口。ステークホルダーとの外交は壁にやってもらう –  壁に露出されていることによりステークホルダーの矛先が壁に向か う 11 ©2009-2012, Sertice Inc. All rights reserved.
  • 7.プロダクトとチームと人を愛しているプロダクトとチームと人を愛している✔経験則うまくいってくるとチームに愛嬌が出てくる•  チームになれていない状態 –  リーダーが仕事を分解し、仕事をメンバーに割り当てる –  最新の情報が人に張りついている –  遅延が確定してからメンバーのフォローが入る•  チームになっている状態 –  チーム全員で仕事を分解し、メンバーが仕事を引き取る –  最新の情報が壁に張りついている –  遅延しそうな匂いがすぐ漂い、メンバーのフォローが入る –  新しい知識/知恵を積極的かつ実験的にチーム内で試そうとする –  現在のチームの成熟度を真 に受け止め、NOと言うことができる –  自分のチームに第三者視点と愛情を持っており、チームの成長を 我が子のように暖かく長い目で見守っている 12 ©2009-2012, Sertice Inc. All rights reserved.
  • 2.チームを支えるスキル ©2009-2012, Sertice Inc. All rights reserved. 13
  • アジャイルチーム4つのスキルうまくやっているアジャイルチームが際立っている4つの高スキル領域 モデリングスキル コミュニケーションスキル とらまえる技術 ひきだす技術 テクニカルスキル ロジスティクススキル つくりあげる技術 つなげる技術 14 ©2009-2012, Sertice Inc. All rights reserved.
  • モデリングスキル•  ビジネスをとらまえる –  Business Framework •  ピクト図解, 業務フロー, REAモデル …. –  EA (Enterprise Architecture) •  TOGAF –  BABOK (Business Analysis Body of Knowledge)•  データをとらまえる –  DOA (Data Oriented Approach) –  DMBOK (Data Management Body of Knowledge)•  ドメインをとらまえる –  DDD (Domain Driven Design) –  ICONIX•  ホワイトボード/A3用紙/付箋紙/ペンを使ってワークショップ形 式でモデリングができるスキルを身につける –  モデリング作業は個人で行わない 15 ©2009-2012, Sertice Inc. All rights reserved.
  • コミュニケーションスキル•  信頼貯金の貯め方 –  素直さと謙虚さ –  傾聴、共感•  要求を引き出す –  行動観察, ラフスケッチ, プロトタイプ, ライブコーディング –  クリティカルシンキング –  課題認識力, 課題設定力•  政治力 –  全員が幸せになる方法を考える –  宣言してから信頼貯金を使う•  ファシリテーション –  チームビルディング –  ワークショップデザイン –  気づきのための指摘•  チームメンバーのパーソナリティの良い成分を化学反応させる –  笑いはチームの薬 16 ©2009-2012, Sertice Inc. All rights reserved.
  • テクニカルスキル•  プログラミングパラダイムの理解と実践 –  オブジェクト指向プログラミング, 関数型プログラミング•  パターンの理解 –  アーキテクチャパターン, デザインパターン, 実装パターン ….•  フレームワーク/ライブラリ/アルゴリズム –  テーラリング方法, 拡張方法, リファレンスモデル作成•  テスト技法/リファクタリング手法 –  xUnit, TDD/BDD, テストの自動化 ….•  ツール作成 –  コード生成, ドキュメント生成•  日本語/英語•  チーム内勉強会をプロジェクト期間内に定期開催する –  チームに足りてない知識を仕入れる –  チームが気になる要素技術をチームで事前調査する 17 ©2009-2012, Sertice Inc. All rights reserved.
  • ロジスティクススキル•  プロセスフレームワーク –  Lean Startup, Scrum, Lean•  アーキテクティング –  アーキテクチャの決定と構築, ガバナンスの設計と運用•  環境構築 –  Issue Tracking, WIKI, Rulebook ….•  自働化 –  コード生成, 継続的デリバリー, テクニカルライティング•  教育 –  初期トレーニング, 後知恵の回収とフィードバック•  有事対応 –  リスク管理, 火消し力•  チームにとってロジスティクスは“空気”や“水”のような存在 –  無くては生きていけない。おいしい空気が吸いたい、おいしい 水が飲みたい –  チームに“抵抗”を感じさせないことが大切 18 ©2009-2012, Sertice Inc. All rights reserved.
  • 3.弊社支援事例©2009-2012, Sertice Inc. All rights reserved. 19
  • 事例:モデリングワークショップモデリングワークショップ•  課題 –  設計者がドメインエキスパートからヒアリングした結果を持ち帰 り、概念モデルを作成してくるものの、ドメインエキスパートから の反応が悪く、プロジェクトが進展しない•  ソリューション –  付箋紙を使ったモデリングワークショップを実施 –  ドメインエキスパートと一緒に業務シナリオを作成し、業務シナ リオを元に概念モデルを“動かした”オブジェクト図も作成した•  効果 –  ドメインエキスパートにUMLを使ったモデリング力が身に付いた –  実業務を抽象化し、概念レベルでパターン化しようとする思考が 身に付いた –  具体的な業務シナリオが内部結合テスト/システムテストの準備工 数削減に貢献した 20 ©2009-2012, Sertice Inc. All rights reserved.
  • 事例:技術者研修技術者研修•  課題 –  企画部門の思いに開発部門のスピードが追いついていない原因 の一つに、エンジニアのテクニカルスキル不足があった•  ソリューション –  個人に足りていないテクニカルスキルを抽出するための試験問 題の作成 –  試験結果を元にしたオリジナルカリキュラムの作成 –  集合研修の実施•  効果 –  プログラミングパラダイム/パターンの理解 –  設計技術力の向上 –  体系的なプログラミングモデルの習得   21 ©2009-2012, Sertice Inc. All rights reserved.
  • 事例:自働化自働化•  課題 –  定型作業が手運用で行われており、オペレーションミスによる 手戻りが発生する –  担当者に情報が張りついているため、担当者が休むこともでき ず、ますます忙しい•  ソリューション –  チーム用のJenkinsサーバの構築 –  定型作業のJob化(Jenkins Job/Jenkins Plugin)•  効果 –  チーム内の誰でもが定型作業を行うことが出来るようになり、 チーム内の作業負荷が下がった –  定型作業が動くドキュメント(コード)になり、情報が人から 剥がれた –  各自の作業マシンにJenkinsがインストールされはじめ、個人作 業も再現性がありそうな作業はJob化され、それがチーム用 Jenkinsにフィードバックされる好循環が生まれた 22 ©2009-2012, Sertice Inc. All rights reserved.
  • 事例:コード生成コード生成•  課題 –  データモデルの変更対応コストが高い•  ソリューション –  モデリングツールのAPIを利用してアーキテクチャに準拠した ソースコードをER図から自動生成•  効果 –  データモデル変更コストの大幅な削減 –  モデルの変更に対する耐性がつき、モデルのリファクタリング にチームが積極的になった –  データアーキテクトが整備していた用語辞書を活用して論理名 から物理名の変換を自動で行うエンジンが作られた   23 ©2009-2012, Sertice Inc. All rights reserved.
  • 事例:環境構築環境構築•  課題 –  課題管理、構成管理がうまく出来ていない•  ソリューション –  Issue Tracking (JIRA)の導入 –  Subversion, Hudson, Proximity, MediaWikiによるソフトウェア構 成管理システムの構築 –  開発環境利用ガイドの作成、教育•  効果 –  エクセルベースのマネジメントからの脱却 –  課題の可視化 –  仕様/ソースコードの共同所有   24 ©2009-2012, Sertice Inc. All rights reserved.
  • 4.チーム参画パターン ©2009-2012, Sertice Inc. All rights reserved. 25
  • 製品開発チームへの参画製品開発チームへの参画 Step 1:既存メンバーの業務の削減 デベロッパーとしてアジャイル経験者が数名参画。既存メンバーの業務を巻 き取る形で追加メンバーが製品の理解を行い、同時既存メンバーの稼働を下 げます。 Step 2:プロダクトオーナー選定 選挙形式で、メンバーのなかからプロダクトオーナーを1名選定します。選 挙期間中、候補者はプロダクトオーナーのトレーニング受けます。製品に対 するビジョンについてまとめ、関係者を前に発表をします。 Step 3:チームビルディング プロダクトオーナーはスクラムマスターを任命します。チーム学習によりア ジャイルのトレーニングを開始しつつ、アジャイル経験者を中心に兵站(ロ ジスティクス)を整備します。 Step 4:中間成果報告 チームビルディングから半年後を目処に、プロダクトとチームの状況を経営 層に報告します。最初の“大規模な”ふりかえりを行い、必要に応じて手当を 行います。 Step 5:支援終了判定 チームが十分に育ったと判断したら、メンバー数を製品開発に最適な人数に 整えます。抜けることになったメンバーはアジャイル経験者。他のチームに 移籍し、再度Step1からおこなっていきます。 26 ©2009-2012, Sertice Inc. All rights reserved.
  • SIチームへの参画SIチームへの参画 Step 1:スクラムマスター参画 プロジェクトキックオフ直前の参画が一番効率的です。チームリーダーと一 緒に開発スコープのうちパイロットプロジェクトと切り出せる部分を選定し、 お客様の承認をもらいます。 Step 2:パイロットプロジェクト開始 パイロットプロジェクトをアジャイル(Scrum)を使って実施します。パイ ロットプロジェクト期間中は、スクラムマスターが中心となってチーム学習 をOJT形式で行います。 Step 3:プロジェクト開始判定 パイロットプロジェクト結果をまとめ、それを元にプロジェクト開始判定 (残りの開発スコープもアジャイルでやるかどうかの判定)を行います。お 客様への意識改革もこのステップで行います。 Step 4:プロジェクト開始 お客様も含めて改めてプロジェクトのキックオフを行います。パイロットプ ロジェクトを経験したメンバーでプロジェクトをスタートします。 Step 5:プロジェクト終了 プロジェクト終了でチームを解散することはせず、チームはそのままで別の プロジェクトをアサインします。もちろん成熟したこのチームはステップ1か らステップ3はもう不要です。 27 ©2009-2012, Sertice Inc. All rights reserved.
  • 5.組織に求められる変革 ©2009-2012, Sertice Inc. All rights reserved. 28
  • 組織に求められる変革•  人事考課制度 –  役職 •  プロダクトオーナー、スクラムマスター –  評価•  契約 –  準委任契約•  労務 29 ©2009-2012, Sertice Inc. All rights reserved.
  • ごあいさつ最後までご覧頂きありがとうございます。感想やご意見をお待ちしております。サーティス株式会社 | Sertice Inc.藤澤悠介 | Yusuke FUJISAWA Mail : fujisawa@sertice.com Twitter : @yusukef Facebook : http://www.facebook.com/Yusuke.FUJISAWA SlideShare : http://www.slideshare.net/sertice 30 ©2009-2012, Sertice Inc. All rights reserved.