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.

プロジェクトを成功させるチケット管理

2,521 views

Published on

QuaSTom高品質ソフトウェア技術交流会 第2回例会 講演資料

Published in: Software
  • Be the first to comment

プロジェクトを成功させるチケット管理

  1. 1. プロジェクトを成功させる チケット管理 株式会社SRA 阪井 誠
  2. 2. 自己紹介 2 •阪井誠(さかば、Twitter: @sakaba37) •ソフトウェアプロセス、チケット駆動開発(TiDD)、Node-RED、 アジャイルに興味を持つ「プロセスプログラマー」 •現場の開発からコンサル・研究まで、論文、書籍、雑誌など レビュー監訳 New: 8/14
  3. 3. チケット駆動開発関連の業務経験 • チケット駆動開発によるソフトウェア開発 – 請負開発での社内利用(事例1) – SESでの客先利用 • チケット駆動開発導入支援(コンサル) – ツール導入支援 – ワークフロー定義支援(レビュー、提案)(事例2) • チケットシステムの社内導入 – PC資産管理への応用* – Wikiによる情報共有 *日経SYSTEMS 2013年9月号「こうすれば必ず成功!Redmine導入の勘所」 [#47Redmine]ユーザコミュニティが盛り上がってきた - 第5回 品川Redmine – http://sakaba.cocolog-nifty.com/sakaba/2013/06/47redmine---red.html 3
  4. 4. 目次 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – チケット駆動開発の効果 – チケット駆動開発の形態とチケットの管理方法 • 事例 – 現場の自律によるリスク低減(文教パッケージのカスタマイズ) – 効果的なコミュニケーション(オフショア開発の支援) • プロジェクトを成功させるチケット管理 – うまくいかない話は意外と多い – 事例がうまくいった理由 – プロセスモデルに基づく支援 – まとめ • おまけ:サーバントリーダーシップ 4
  5. 5. TiDDのはじまり • masuidrive的プロジェクトの方針(2007) http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/ • まちゅ, 「もうひとつのTDD」, ITpro Challenge のライト ニングトーク http://www.machu.jp/diary/20070907.html#p01 • Shibuya.Tracキックオフ • XPJUG関西 TiDD勉強会発足 (2008) • 「Redmineによるタスクマネジメント実践技法」(2010) • RxTstudy、Shinagawa.Redmine(2011) • 「チケット駆動開発」(2012) : 5 Tracブーム チケット駆動開発 誕生 現Redmine大阪、 redmine.tokyo
  6. 6. チケット駆動開発 • ITS(BTS)のチケットで障害、課題、タスクを 管理して個人のタスクとプロジェクトを管理する • 構成管理、Wiki、継続的統合などツールを チケットに連携させて自動化する • プロジェクトの情報をチケットに関連付けて 管理することで、コミュニケーションを支援する  現場による、現場のための改善活動  プロジェクト関心事の電子化によるコミュニケー ション支援 6
  7. 7. バージョン管理とチケット(仕様変更) 7 仕様変更仕様変更 タスク1タスク1 タスク2タスク2 新規追加 更新 更新 タグ 競合チェックアウト アップデート 解決 関連タスク トレーサ ビリティ
  8. 8. バージョン管理とチケット(バグ) 8 バグバグ 更新 更新 ブランチ
  9. 9. ツール連携 9 ITS バージョン管理 ツール コメント 作業内容、担当者、 ステータス、進捗 開始、終了 refs #チケット番号 fixes #チケット番号 表計算ソフトだと 縦や横に伸びる
  10. 10. チケットによる管理 チケットシステム(ITS) 親チケット 障害・課題・タスク障害・課題・タスク 継続チケット継続チケット 関連チケット関連チケット プロジェクト ステータス 種類とロール毎のワークフロー レポート、カスタムクエリ、 ロードマップ、ガントチャート 等で参照できる
  11. 11. 11 チケット一覧(例:Redmine) SQiP2009発表資料より ©小川明彦, 阪井誠
  12. 12. 12 ワークフロー設定(例:Redmine) SQiP2009発表資料より ©小川明彦, 阪井誠
  13. 13. 13 ワークフロー設定(例:Redmine) ユーザ権限と チケット種類の単位で ステータスの現在・移行先を指 定する ソフトウェア開発のワークフローは BTSのワークフロー機能で 制御できる ステータスの移行先 現 在 の ス テ ー タ ス SQiP2009発表資料より ©小川明彦, 阪井誠
  14. 14. ツール連携とチケット リビジョンリビジョンリビジョンリビジョン バージョン管理 CIツール チケットシステム(ITS) 親プロジェクト 親タスク/ストーリー タスクタスク 継続タスク継続タスク 関連タスク関連タスクWiki プロジェクト ステータス チケットの種類とロール毎のワークフロー 参照 実行結果 チケット参照 連携 参照 連携 構成管理、Wiki、 CIツールなどを チケットに連携
  15. 15. チケットによるコミュニケーションの支援 リビジョンリビジョンリビジョンリビジョン バージョン管理 CIツール チケットシステム(ITS) 親プロジェクト 親タスク/ストーリー タスクタスク 継続タスク継続タスク 関連タスク関連タスクWiki プロジェクト ステータス チケットの種類とロール毎のワークフロー 参照 実行結果 チケット参照 連携 参照 連携 議論や更新を メール、RSS、 プラグインで 通知できる
  16. 16. チケット駆動開発の効果 ツールを有効活用してプロジェクトの負担を減らす • 過去: – 履歴の活用(経緯の確認、ノウハウの利用) • 現在: – 障害、課題、タスク、ツール実行の管理 – 情報共有、自動化、コミュニケーション • 未来: – 計画、備忘録、リスクの見える化 16
  17. 17. 統率の とれた 組 織 の 特 性 自律的 小 変更量 大 チケット駆動開発による開発法の拡張 アダプタブル ウォーターフォール アジャイル開発 ウォーター フォール型開発 TiDD TiDD TiDD アジャイル チケット駆動開発 TiDD
  18. 18. TiDDの形態 • 完全チケット方式(アジャイルTiDD、WF) o チケットですべての作業を管理する o 管理が集約される o プロセスを変更するので社内調整が必要 • 補完チケット方式(アダプタブルWF) o 既存の管理は変更しない o 計画外の作業をチケットで管理する o こっそり開始できる(でも報告は必要<=後述)
  19. 19. 19 チケットの管理方法 • ワークフロー型(事例2:ライトウィング) o 起票や終了には権限が必要 o 仕様の一貫性を保障できる • オープン型(事例1:レフトウィング) o 誰でも起票・終了できる o 機敏さ、自由がある *アダプタブルWFでは特に規定しないが オープン型が望ましい 技術・規律重視 チームワーク重視
  20. 20. 目次 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – チケット駆動開発の効果 – チケット駆動開発の形態とチケットの管理方法 • 事例 – 現場の自律によるリスク低減(文教パッケージのカスタマイズ) – 効果的なコミュニケーション(オフショア開発の支援) • プロジェクトを成功させるチケット管理 – うまくいかない話は意外と多い – 事例がうまくいった理由 – プロセスモデルに基づく支援 – まとめ • おまけ:サーバントリーダーシップ 20
  21. 21. TiDDの 事例 21 現場の自律によるリスク低減 チケット駆動開発の事例1
  22. 22. TiDDによる自律とリスク低減の実現 • 開発時の履歴をその後の開発につなげます • 開発者の気付きをチケットに記録します • 協調作業を支援してプロジェクトを活性化します 22 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
  23. 23. 事例1の概要 • 文教パッケージのカスタマイズ(最大8人x1年) o 短納期 & 仕様の決定遅れ・変更 o スキルは高いが経験者が少ない(リーダは途中交代) o オープンフレームワークの初めての組み合わせ (サブシステム、ミドルウェアのバージョン) o 義務感と不安、重苦しい雰囲気、閉塞感、、、 o 守りに入るので、コミュニケーションが悪い システムテストの時期になると、計画外の環境構築やリリース準備 作業が明らかになった(環境に関連するバグも、、、) ⇒ そうだ!チケット駆動開発をしよう! 23
  24. 24. オープンなフレームワークの苦しみ 長所 • 同じようなコードが減る • 個別の業務要件に対する固有の開発だけでよい 短所 • お約束が多い複雑な作業で、気が抜けない • 工夫できる余地が少ない • 少人数で大規模なシステムが作れてしまう • セキュリティ対策で実行環境の構成は日々変化 ⇒ 煩雑なのに情報が少ない、、、大変! 24
  25. 25. TiDDの実施方式 • アダプタブルウォーターフォール(補完型TiDD) • WBSと併用(と言っても更新作業は全てチケットあり) • オープンな運用 • だれでもチケットが作成できる • システムテスト以降 • システム全体 • メンバー全員 • trac(単独) ・・・ SRA共通開発環境(trac,subversion,mailmanの仮想環境) 現在のProjDepot
  26. 26. チケット駆動開発の導入 • 宣言と実行 「 バグだけではなく、ソースを触るときや、WBSにない作業をするとき は、チケットを登録してください!」 • 環境の準備 o レポート(チケットの一覧)の作成  bugのみ、 taskのみ、 その他、など o 権限の追加  tracの権限の設定が堅かったので、チケットを修正できるように 全ての権限を与えた(リスクを考慮して設定してください) • 教育 • パッケージチームとのQAの経験はあった 26 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
  27. 27. 結果 • チケットの数(BUG以外) o システムテスト:31 o 本番環境構築:42  データの準備、環境準備、BUG関連で増えた作業、 細かな仕様変更など、手順書にない1回だけの作業 • 作業漏れ減少!納期までに作業が完了! (知らないこと、気付かないことはできませんでした、、、orz) それ以外にも、メンバーに変化が、、、 27
  28. 28. 目が輝いた! サブリーダ(クラス)なのに遠慮をして いたメンバーが、生き生きしだした • 「チケットを切ってもいいですか?」 ⇒ 義務的な作業からの解放 • 「チケットを切っておかないと忘れてしまう!」 ⇒ すぐに使いこなしていた • 「ちゃんとクローズしてね」 ⇒ 他の人に指導をしていた! • 「残っているチケットが多くてわかりにくいから整理 しますね」 ⇒ 今後のことも考えている
  29. 29. 事例1のまとめ • システムテスト以降にTiDDを導入 • 備忘録のつもりで気づいたことをチケット化した • 手順はWikiにまとめた • 計画外の作業を管理できた • 作業を見える化することで コミュニケーションが向上した • メンバーが前向きになり、 プロジェクトが元気になった 29
  30. 30. 事例1からの学び • 新しい環境、実装方法、アプリケーションに挑戦 するには、以下の点を考慮しないといけない – 気づいたことが共有されること – 少ない経験が蓄積されること – 蓄積した経験が生かせること サーバーントリーダーシップを意識した チケット駆動開発の運用方法が必要 30
  31. 31. ポイント1: 気づいたことが共有されること • チケットが容易に起票できるようにする – 起票の権限をメンバーに与える – ワークフローの制限を少なくする • チケットの種類や属性を増やしすぎない – 考えなくて良い様にする – 記入項目を減らす • リアルタイムに共有してモチベーションを高める – メール、RSS、Eclipseとの連携 – コミュニケーションのタイムラグ減ると利用が増える 31
  32. 32. ポイント2: 少ない経験が蓄積されること • チケット駆動を習慣づける – 基本的な教育 – メリットを感じさせる – 備忘録としての利用 • 利用に向けた支援 – カスタムレポートの用意など環境整備 – アドバイスのための棚卸し – ルールの整備 (“No Ticket, No, Commit!!”をどこまで守るか、など) 32 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
  33. 33. ポイント3: 蓄積した経験が生かされること • 経験の種類に応じて整理する – 一度だけの作業はチケットを起票する – 手順やチェックリストはWikiにまとめる • 書きっぱなしのチケットを防ぐ – 完了条件を明確にする – 適切な棚卸しをする • 発想力・提案力の向上 – 棚卸しの頻度を増やしすぎない – 自律的なチーム 33
  34. 34. TiDDの 事例 34 効果的なコミュニケーション チケット駆動開発の事例2
  35. 35. 事例2:オフショアでの利用 • コミュニケーションが問題になりやすい – 状況が見えない – 履歴を確認したい場面が多い – ボトルネックが発生しやすい • 複数拠点 – プロトコルに制約 – メールは使いにくい 35
  36. 36. メールではうまくいかない – 情報の所在(ありか) • 個人的な分類・管理(本人以外は検索できない) • MLサーバーで管理(分類がないので検索が困難) • クローズドな情報(関係者が限定される) – 情報の関連付け • ソースとのリンクが困難(更新と理由) • Wikiなどにまとめても、メールと関連付けにくい – 情報の内容 • 承認ワークフローがなく、ステータスがわからない • 検索のキーがない 36 => チケットシステムを導入
  37. 37. ワークフローの検討 • メールを原則禁止、チケットを利用 – 質疑応答や議論の経緯を残す – カスタムクエリで状況を容易に確認できるようにした • チケットは基本的に発注側の責任者が閉じる – ボトルネックになるが、最終確認ができる – チケットの種類を工夫して作業を効率化 • 無駄に厳密にしない – ボールの持ち主は、ステータスでなく担当者 – 担当がいなくても情報共有、更新ができる 37
  38. 38. 事例2の結果 • メールとファイル共有による開発が一変 – 履歴の検索が容易になった – ファイル共有によるロックの問題が解消 – 安全に修正作業ができる => 「もっと早く使っておけばよかった!」 38
  39. 39. 目次 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – チケット駆動開発の効果 – チケット駆動開発の形態とチケットの管理方法 • 事例 – 現場の自律によるリスク低減(文教パッケージのカスタマイズ) – 効果的なコミュニケーション(オフショア開発の支援) • プロジェクトを成功させるチケット管理 – うまくいかない話は意外と多い – 事例がうまくいった理由 – プロセスモデルに基づく支援 – まとめ • おまけ:サーバントリーダーシップ 39
  40. 40. うまくいかない話は意外と多い • 面倒くさいと感じている – 義務的・管理的に感じている – 大量のチケット(細かい、コミットごと) • ITSを使いこなしていない – 「Wikiは使っていません」 – 同じ情報をエクセルと2重管理 • 混乱しているプロジェクトに役立っていない – チケットを書いてくれない、放置される – 閉じるタイミングがないチケット => 事例との違い(チケット駆動開発のツボ)を考える
  41. 41. ソフトウェアプロセスは文脈に依存する • (ソフトウェア)プロセスは人が実行する • プロセスは組織文化と業務の上に成り立っている • 例外は厳密なプロセスの機械的な実行 =>重いプロセスになり易い ※EASEプロジェクトのチケット属性
  42. 42. チケット駆動開発による改善 42
  43. 43. 43 うまくいった理由(事例1) 事例1: 現場の自律によるリスク低減 事例2: 効果的なコミュニケーション 問題が共有されていた 迫る納期、厳しい顧客、不安感 =>情報共有がうまくいっていなかった メールによるコミュニケーションは難しい => 情報共有の仕組みが必要 仕組みがある チケットシステム(trac) =>パッケージの障害管理に使っていた チケットシステム(Redmina) => ふさわしい運用方法を検討した 改善のモチベーション これ以上ひどくなったらヤバい =>ワラをもつかむ改善の考え方 開発を始めるまでに良い方法を作りたい =>サマリ機能を利用した
  44. 44. 44 • 問題を共有する 解決すべき問題が共有されないといけない • 仕組みを作る 環境を整えて必要なものを必要なだけ • 改善のモチベーション 自分ごととして実施する うまくいく方法 あとで出てきます
  45. 45. チケット駆動開発の3要素 • モデル、見える化、チームづくりの設計が必要 45 チケットシステム 開発チーム プロセスモデルに基づく支援 CSCWによるチームづくり 履歴、バージョン管理、Wiki リポジトリ データの見える化
  46. 46. プロセスモデルに基づく支援 46 チケットシステム 開発チーム プロセスモデルに基づく支援 CSCWによるチームづくり 履歴、バージョン管理、Wiki リポジトリ データの見える化
  47. 47. プロセスモデルの特徴 • 人間が実行する – 判断や調整など実行に時間がかかる – 学習コストがかかる – 個人差、モチベーションの差が大きい – 柔軟な判断が可能  現状を大きく変えず、負担を増やさないで 楽になるような改善・運用と組み合わせる
  48. 48. プロセスモデリングのゴール • 理解する事 • プロセス改善 • プロセス管理 • 自動実行 • 自動ガイド => ツボを押さえたモデリングが必要 * Bill Curtis, Marc I. Keller and Jim Over, Process Modeling, Communications of the ACM (Impact Factor: 2.86). 09/1992; 35(9):75-90 プロジェクト: 概要、バージョン、サブプロジェクト 作業: 作業の概要、担当者、期限、重要度、ステータス メンバー: アカウント、名前、ロール、 作業品質: カスタムフィールド. テンプレートプラグイン プロダクト品質: 優先度別カスタムクエリ, CIとの連携 管理の効率化: 進捗報告, 作業時間、サマリ 作業漏れ防止:未完了のクエリ、 ワークフロー(トラッカー、ロール、ステータス) 進捗の集計: ロードマップ ツール連携: バージョン管理、メール、rss、CI、スマホ メニュー: ワークフローの設定に応じたメニュー リマインダ: 期限が近付くとメールで通知
  49. 49. ツボその1:プロジェクトのゴール • 段階的に詳細化して実施を容易にする – プロジェクト • 全体のゴールを示す • 必要に応じて階層化する – バージョン • マイルストーンを示す • 直近のゴール&管理単位 – チケット • 作業間の関係を示す – 制約を増やしすぎると使いにくくなる • 適切な作業粒度のゴールを示す ※アンダーライン部は後のページで説明します 青:先行、後続 赤:ブロック プロジェクトバー ジョン チケット(親子)
  50. 50. プロジェクトのツボ 識別が容易な名称 共有すべきゴール プロジェクトの階層 化 限定して利用法を明確 に 混乱させない様にシンプルに
  51. 51. ツボその2:チケットの粒度 • 明確に、わかりやすく、リズムによる学習を考えて – チケットの単位 • 完了条件が明確な単位 – チケット一覧 • 一度に見る量が多すぎないように • 用途に応じたカスタムクエリを利用する – 作業のリズム • 2日に1度は完了するように • 階層化して細かくする =>プログラミングのモジュールと同様* * Leon J. Osterweil, “Software processes are software too,” ICSE , pp. 2-13, 1987. フィルタ条件を カスタムクエリにできる
  52. 52. ツボその3:規律 • 運用とのバランスを考えて – カスタムフィールド • 漏れ、間違いを防ぐ • 入力書式、必須など決める – ロール • 誤操作を防ぐ • デフォルトは厳しい(要変更) – ワークフロー • 遷移を限定しミスを防ぐ • 手順を示す • ボトルネックを生みやすい • トラッカー(種類)、ロール、ステータスで指定 => 厳密にするほど使いにくいので、運用回避も検討する 入力を必須にできる 入力書式の選択
  53. 53. ワークフローの設定 ロールとトラッカーごとに 指定 例:終了のチェックを外すと開 発者はチケットを終了できなく なる(要承認) フィールドの更新権限を 設定 作成者、担当者用の ワークフロー
  54. 54. データの見える化 54 履歴、バージョン管理、Wiki チケットシステム 開発チーム リポジトリ プロセスモデルに基づく支援 CSCWによるチームづくり データの見える化
  55. 55. データの見える化 利用シーンを考える • ロードマップ – バージョンごとの進捗を示す • チケット一覧 – 進捗と各フィールドを示す – クエリ、カスタムクエリ • 作業実績 – ユーザ、作業種別等の単位で集計 • ガントチャート – 予定・実績を線表で示す – イナズマ線、親子、関連 • チケットと更新 – No ticket, No commit ! – ロジカルカップリングを示す => 必要に応じて使い分ける バージョン単位で 進捗を示す 予実をイナズマ線 で確認できる
  56. 56. 作業実績
  57. 57. 作業実績 チケット編集画面からも入力できる フィルタや集計単位を指定できる
  58. 58. No ticket, No commit !
  59. 59. No ticket, No commit ! コミット時に「refs #チケット番号」とする とチケットに関連付けられる 複数のコミットをチケットに関連付けることで ロジカルカップリング(論理的なつながり)を 示せる。コミットごとに分けてはいけない
  60. 60. CSCWによるチームづくり 60 履歴、バージョン管理、Wiki チケットシステム 開発チーム リポジトリ プロセスモデルに基づく支援 CSCWによるチームづくり データの見える化
  61. 61. CSCW*によるチーム作り 全体のコーディネートを考える • 伝統的リーダーシップ – トップダウンによる指示・報告系統の確立 – 完了はリーダーのみとして、必ずレビューするなど制限を与える • サーバントリーダーシップ – 自律的なチーム作り – 誰でも完了できるなど、自由度の高い設定をする • Wiki – チケットよりも検索が容易 – ルールやTIPSなど、まとめとして利用する • フォーラム、ニュース、etc. – 最新情報の連絡に用いる – メールと連携していれば必須ではない * Computer Supported Cooperative Work
  62. 62. その他の失敗しないポイント • なぜチケット駆動開発をするのか考える – 楽をするため • あるものは使う • 便利な機能を知る • 良く考えないと負担が増える – 効率化 • 管理よりも現場の工数が大きい • 現場の効率化は効果が大きい • 管理はボトルネックになり易い – 新しいプロセス(文化)の導入 • ツールの導入ではない • より良い組織を目指す • 準備が重要(資料、説明会、ワークショップの開催)
  63. 63. まとめ • チケット駆動開発の3要素 – モデリング、見える化、チーム作りを設計する – ゴールの段階的詳細化、チケットの粒度、 規律を考慮してモデリングする – データの見える化は利用シーンを考える – チームのコーディネートが重要 => チケット駆動開発で解決すべき問題を よく考えて実施してください
  64. 64. 注意点 • 規模、文化、業務でやり方は変わる 有効性を確認しながら実施する – まずは障害管理から始めるのも一つの方法 • プロジェクトのチケット経験や体制で変える 味方を増やす(ただし、全員に目を配る) • なぜそれが必要かを話す(説明責任) – 説明会、ワークショップ • 人を見る(積極的な人、受け身な人) ルールは細かくしすぎず、運用で指導する – ピンチを演じてみる(孫子の兵法) • 自立を促して負担をかけない方法を模索する 本当にすごいのは誰にも気付かれずに結果を出すこと(孫子) – 利用者にメリットを与える。サーバントリーダーシップの考え方 64
  65. 65. 目次 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – チケット駆動開発の効果 – チケット駆動開発の形態とチケットの管理方法 • 事例 – 現場の自律によるリスク低減(文教パッケージのカスタマイズ) – 効果的なコミュニケーション(オフショア開発の支援) • プロジェクトを成功させるチケット管理 – うまくいかない話は意外と多い – 事例がうまくいった理由 – プロセスモデルに基づく支援 – まとめ • おまけ:サーバントリーダーシップ 65
  66. 66. 自律を支援するリーダーシップ • サーバントリーダーシップ – コマンドコントロールをやめ、 メンバーが能力を生かせるように支援する • マクロマネジメント – マイクロマネジメントをすると依存するようになり、 自律性が失われる • 濡れぞうきんはしぼらない – 本田宗一郎氏がIIJ鈴木幸一社長(当時)に送った言葉 – ガチガチの管理からは柔軟な発想は生まれない 66
  67. 67. サーバントリーダーシップのイメージ 67 • ゴールを見失わないように自律的チームを支える コマンドコントロールサーバントリーダーシップ
  68. 68. サーバントリーダーシップ • ロバート・グリーンリーフ(1904~1990)が1970年に提唱 – 「リーダーである人は、まず相手に奉仕し、 その後相手を導くものである」というリーダーシップ哲学 – サーバントリーダーは、奉仕や支援を通じて、 周囲から信頼を得て、主体的に協力してもらえる状況を作り出す • サーバントリーダーシップの10の特性 – 傾聴、共感、癒し、気づき、納得、概念化、先見力、執事役、 人々の成長への関与、コミュニティづくり • 「リーダーがするべき最も重要な選択は、奉仕することだ。それがな ければ、人々をリードする能力は恐ろしく限定されたものになる」 *NPO法人日本サーバント・リーダーシップ協会 http://www.servantleader.jp/index.html 日本人のイメージと違う
  69. 69. サーバント(僕)とリーダーシップ • 「お客様、よろしければ、どうか、僕のもとを通り過ぎないで ください」紀元前1800年頃創世記 18・3 (イサク誕生の予告) • 「僕は聞いております」紀元前11世紀頃 サムエル記上3・9(ユダヤの預言者・指導者) • 「上に立つ人は、仕える者のようになりなさい」 西暦30年頃ルカによる福音書 22・26 =>叙階式で画像検索 • 「一人称「僕」の普及は、吉田松陰が開いた私塾 「松下村塾」に由来する」1860年頃 人称代名詞「僕」は近代の始まり http://blog.livedoor.jp/t2250maeda/archives/54569732.html • アジャイル開発手法「スクラム」1993年 • W・ハンフリー「TSP ガイドブック:リーダー編」2007年 *聖書引用は日本聖書協会 新共同訳
  70. 70. 司祭(神父)叙階式 70 https://twitter.com/hiroshisj/status/446932842086281216
  71. 71. サーバントリーダーシップの実際 71 W・ハンフリー「TSP ガイドブック:リーダー編」, 2007. – 「自律的なチーム」を構築 – 「その最大限の能力を最大限発揮できるようメンバー を動機付け、コーチし、後押しする」 – 「フィードバックとコミュニケーション」 – 「動的な負荷調整」 – 「管理することとリードすることは違います」 – 「人はリードされたいけれども管理されたくはない」 – 「リーダーは部下を動機付け」るなど、 「下からリード」して「ゴールを達成」する デブサミ運営事務局、100 人のプロが選んだソフトウェア開発の名著 君のために選んだ 1 冊, pp.20-21. 「リーダーに求められる大切なこと」 http://www.slideshare.net/MakotoSAKAI/ss-16581244
  72. 72. プロジェクトの成功に必要な考え方 サーバントリーダーシップとは 僕(しもべ)と言っても雑用係ではなく、 昔からある良いリーダー像 • 与えられたロール(役割)を認識し • みんなを支え • ゴールのためなら何でもする うまくいく方法と同じ • 問題を共有する • 仕組みを作る • 改善のモチベーション
  73. 73. 73 • 問題を共有する 解決すべき問題が共有されないといけない • 仕組みを作る 環境を整えて必要なものを必要なだけ • 改善のモチベーション 自分ごととして実施する うまくいく方法から考える チケット管理のチェックポイント 問題を解決しているか 負担は増えていないか 納得しているか (文脈の説明を忘れずに) ディスカッションに向けて
  74. 74. プロジェクトを成功させる チケット管理 おわり

×