ありがたい話 公開版 http://esminc.doorkeeper.jp/events/18782

1. INSPIRE
(株) 永和システムマネジメント
アジャイル事業部
Ruby x Agile グループ
伊藤 浩一 (@koic)
2015.01.16 (Fri)
(株)永和システムマネジメント Room Right/Left
ありがたい話 公開版
FUTURE
GENERATIONS
現場リーダーのありがたい話2015

2. 満員
御礼

6. 対象者
•ちょっと未来の@ivezuki
•ちょっと過去の@flada_auxv
•私と一緒のプロジェクトを経験
していないメンバー

7. 自己紹介

8. 株式会社 永和システムマネジメント アジャイル事業部
所属。JavaによるWebアプリケーション開発やセミナー
講師などを経て、XPとオブジェクト指向をキーワード
に2004年より現職。2007年よりRailsを用いた Web
アプリケーションの構築に携わり、現在はRubyとアジャ
イルをキーワードとした4∼6人程度の小中規模の受託
開発プロジェクトのリーダーを務める。共著書に
『Web 2.0ビギナーズバイブル』(絶版) 。最も影響を
受けた開発手法は『エクストリーム・プログラミング』。
伊藤 浩一 (@koic)

9. 現場での私のミッション
•アジャイルソフトウェア開発
の現場をリードする
•チーム、メンバーを育成する

10. 現場での私のミッション
•アジャイルソフトウェア開発
の現場をリードする
•チーム、メンバーを育成する

11. 仲間たち

12. http://www.slideshare.net/esminc/new-year-2015-agile-div

13. 現場での私のミッション
•アジャイルソフトウェア開発
の現場をリードする
•チーム、メンバーを育成する

14. http://www.esm.co.jp/agile/business_plan_esm_agile_div_35th.pdf

15. 育成担当
@koic @moro
プロジェクトリード職 プログラミング職

16. @koic @moro
プロジェクトリード職 プログラミング職
どこを より 特化するか

17. @koic @moro
プロジェクトリード職 プログラミング職
今日の話の育成観点

18. 私のミッション
•アジャイルソフトウェア開発の
現場をリードする
•チーム、メンバーを育成する

19. 永和現場リーダー
としての私のミッ
ションと実践の話

20. 本日は
よろしく
お願いします

21. 文化の形成
おさらい

22. 現場リーダーのお仕事
•プロジェクトを進めるにあたる
レール上の障害物を退ける
•メンバーとチームの育成

23. 現場リーダーのお仕事
•プロジェクトを進めるにあたる
レール上の障害物を退ける
•メンバーとチームの育成
プロジェクトデザイン

24. 『Extreme Programming Embrace Change』より

26. 開発を成功させるためには、
プログラマーとユーザーが
自分たちの不安を認識し、
権利と責任を受け入れられ
る文化 (環境) を創らなけ
ればならない。『エクストリーム・プログラミング実行計画』9ページより抜粋

27. プログラマーの権利章典
ユーザーの権利章典
プロジェクトの両輪

28. • 全体の計画でいつ何がどのくらいのコストで達成されたかを知る
権利がある。
ユーザーの権利章典
• 毎週のプログラミング週から、最も可能な価値を得る権利がある。
• 作業中のシステムの進 状況、規定した繰り返しテストをパスで
きていること (作業の証明) を見る権利がある。
• 法外なコストを支払うことなく、自分の考えを変えたり、機能の
入れ替え、プライオリティの変更を行う権利がある。
• 予定日を修正しスコープを縮小するために、スケジュールの変更
通知を受ける権利がある。いつでもキャンセルすることができ、
現在までの投資を反映して機能しているシステムを残してもらう
こともできる。

29. • 何が必要なのか、プライオリティの明確な位置づけを知る権利が
ある。
プログラマーの権利章典
• 常に質の高い仕事を行う権利がある。
• 援助を要求し、仲間、マネージャ、ユーザーから助けを得る権利
がある。
• 自分の見積りを作成し更新する権利がある。
• 責任を割り当てられるのではなく、受容する権利がある。

30. ユーザーとプログ
ラマーの権利を尊
重する文化の形成
現場リーダーの仕事

31. 本編

32. •#1 ソフトウェアの見積り
•#2 チームのはなし
•#3 チーム開発の意義
お品書き

33. #1
•#1 ソフトウェアの見積り
•#2 チームのはなし
•#3 チーム開発の意義
お品書き

34. ?なぜ見積る
のか？

35. 計画のない
プロジェクト
はない

36. https://ja.wikipedia.org/wiki/プロジェクト

37. 見積りは
計画を立てる
ための視点

38. ユーザーの
ための計画

39. 現場リーダーのお仕事
•プロジェクト (計画) を進める
にあたるレール上の障害物を退
ける
•メンバーとチームの育成

40. レールから障害
物を退けるのが
リーダーの仕事

41. 障害物

42. 見積もり
!
真実8：プロジェクトが大失敗する原因には二つある。一つは見積も
りミスだ（もう一つはP.110の真実23を参照）
!
真実9：ソフトウエア開発の見積もりは、プロジェクトの開発時に
実施する場合が非常に多い。これだと、要求定義が固まる
前に見積もることになり、どんな問題がどこにあるかを
理解する以前に予測するので、意味がない。従って、
見積もり時期として適切ではない。
!
真実10：見積もりは、上層部かマーケティングが実施する場合がほと
んどだ。実際にプログラムを開発したり、開発プロジェクト
の直接のマネジャが見積もることはない。結局、適切な人が
見積もっていないのだ。
!
真実11：プロジェクトが進むに従って、見積もりを調整することは、
まずない。従って、不適切な時期に不適切な人間が実施した
見積もりをが修正することは、ほとんどない。
!
ソフトウェアエンジニアリング
ソフトウェア開発55の真実と10のウソ
ロバート・L・グラス

43. 確度の低い見積り
未凍結の仕様
割と密接

44. • 放っておいても狭くはならない
• コーンを狭めるには情報が増えるなど状況変化が必要
不確実性のコーン

45. 見積りできた？
見積りできた？
見積りできた？
いつリリースできるの？

46. • 見積りの難しさ (途中で変わる/固り切らない状態でゴー)
• 存在していないものは期待にすぎない
• ユーザーインタフェースのあるシステムであれば、ワイ
ヤーフレームによる期待の擦り合わせは有効
• ペーパープロトタイピングはやったことないけど、ど
うなんでしょうね？ (ある程度で作っちゃうので)
そして厄介な現実
ユーザーも真実欲しいものは分からない
(正解があるとは限らない)

47. でもやるんだ
よ。だって仕
事でしょ？http://d.hatena.ne.jp/m_seki+b/20101202/p1

48. 要件がどこまで生
煮えで手が動くか
ソフトウェア開発の現実

49. 地に足のついた
見積りに
必要な能力

50. プログラミング

51. 何かをプログラムす
る時、どの位かかるか
を見積るということは
完全に技術的な決定で
ある エクストリームプログラミング実行計画15ページ

52. 見積りは
開発者の仕事
FAQ. どれくらいでできそうですか？

53. 見積り
プログラミング能力は
十分条件ではなく必要
条件
書き
読み

54. プログラミング能力は
十分条件ではなく必要
条件
書き
読み
見積り
時間という制約の中で
結果を出すのがプロ

55. 1.標本を集める
2.相対値を作る
繰り返してより地に足のついた数に

56. Copyright (c) 2011 Eiwa System Management, Inc.
イテレーション (1週間) の流れ
要求
リリース可能な
ソフトウェア
Ship It!
次の
イテレーションへ
内部リリース
ふりかえり
! KPT
!ベロシティ
バックログ
タスク
プログラミング
"機能
"バグ
"データ移行
"ドキュメント
"環境構築
"性能
"ジョーカー 受入テストを
書く 受入テストを
する
" 完了基準
! TDD
! CI
! 仕様の確認
! 見積り
! スパイク
ふりかえりやバックログの優先度
付けなどはお客さまにご協力いた
だきながら進めていきます。

57. Copyright (c) 2011 Eiwa System Management, Inc.
まわして「見積り続ける」
要求
リリース可能な
ソフトウェア
Ship It!
次の
イテレーションへ
内部リリース
ふりかえり
! KPT
!ベロシティ
バックログ
タスク
プログラミング
"機能
"バグ
"データ移行
"ドキュメント
"環境構築
"性能
"ジョーカー 受入テストを
書く 受入テストを
する
" 完了基準
! TDD
! CI
! 仕様の確認
! 見積り
! スパイク
ふりかえりやバックログの優先度
付けなどはお客さまにご協力いた
だきながら進めていきます。

58. • だいたい半年前に作った○○機能と同じくらい
• 同じ経験があると強い (それなりに根拠ある信頼)
• 相対的な数値化してユーザーに伝えられる (責任)
• 「これだけのことをやると、○○機能に比べて△△
くらいの大きさです」
• もちろん他プロジェクトでの経験も大きな標本
• 最後は開発者の作れそう感 (経験重要)
サンプルの重要性

59. • プランニングポーカーを使ったチームでの見積り
• 見積りは設計行為
• 数字の違いにリスクが隠れていることも
開発チームのやれそう感

60. 人間は成長
する生き物

61. だんだんと
うまくなる

62. だんだんと
うまくなる
プログラマーもユーザーも

63. #2
•#1 ソフトウェアの見積り
•#2 チームのはなし
•#3 チーム開発の意義
お品書き

64. 育成担当
@koic @moro
プロジェクトリード職 プログラミング職

65. チームの
成長

66. • 本を読んだだけではプログラミングはできない
• 本を読んだだけではプロジェクトはまわせない
• 実際は知識も大事、経験も大事
• 『巨人の肩の上に立つ』
実践に勝る経験はない

67. • メンバーの特徴とプロジェクトの状況をつかむ
• メンバーはできるだけ縦で見る
• 似た機能を作った経験の速度重視か、あまり経験のない
ないようにフォーカスしたストレッチした成長重視か
• ユーザーの計画を考慮したうえで組み立てる
• 開発者の「おもしろそう」「作ってみたい」もだいじ
フォーメーション

68. 弾けないフレー
ズを弾けるよう
にするのが練習
オレのB面から

69. • ユーザーとの会話が分かる (議事録)
• 使ったことのない技術をもちいる (できるだけ地雷は先に
踏む)
• 外部チームと連携する (インタフェース設計、異文化交
流)
• ユーザーへの提案を行う (フロント業)
• 自分で作れる前提で、あえて手を動かさない (ただし放置
はしない)
ストレッチのポイント例

70. 受託開発の持つ性質
仕事
要員
リスク
チャンス

71. • 4人以上のチームの場合のサブチームづくり
• Pivotal TrackerでいうEpicの粒度でチームを組む
• 編成として「刺激になりそう」を組み合わせたり
Epicとフォーメーション

72. 刺激を
演出する

73. 誰と重要
@beakmark

74. • すごいRubyistだったり、コミュニティの仲間だったり、
ネット著名人だったり、From Java to Rubyな同僚
だったりさまざま
• 安定したプロジェクト経験者と新しいメンバーで組むのが
黄金パターン (オブジェクト指向の設計原則にも『安定
に依存せよ』とありますね)
• なんとなく知っていると他人に説明できるのギャップを
埋める (アウトプットすることで整理できることも)
新しいメンバーを迎え入れる

75. 演出の
大前提

76. • 「開発はうまいことやる」お任せ安心感
• いつ頃に次の作業が出来そうか (透明性)
• いつまでに要件凍結が必要か
• 開発メンバーのやることがないを作らない
• いったことをきちんとやる
アカウンタビリティ

77. 現場での私のミッション
•アジャイルソフトウェア開発
の現場をリードする
•チーム、メンバーを育成する

78. XP
Tracker
という役割

79. 全体
俯瞰

80. 見積りと
予測可能性

81. 要求ヒアリング
見積り
計画づくり
ビジネス検討 実装
効果測定 テストリリース
9:1
5:5
ボールの滞在率 (ユーザー:プログラマー)
1:9
9:1
7:3
1:9
1:9
5:5

82. プロジェクトの成
功とチームの成長
のバランスを見る
現場リーダーの心得

83. 現場での私のミッション
•アジャイルソフトウェア開発
の現場をリードする
•チーム、メンバーを育成する

84. #3
•#1 ソフトウェアの見積り
•#2 チームのはなし
•#3 チーム開発の意義
お品書き

85. チーム開発
の意義

86. 何事もひとり
では成し遂げ
られない

87. ユーザーとプログ
ラマーの権利を尊
重する文化の形成
リーダー業のひとつのゴール

88. • コミュニケーション
• シンプルさ
• フィードバック
• 勇気
• 敬意
XPの5つの価値

89. 敬意

90. 業務
○○に
期待
サービス
インフラ提供
ご近所さん

91. この世に同じ
プロジェクト
はふたつない

92. 自分たちの
やり方を
自分たちで
決めて作って
いける(株)永和システムマネジメント
アジャイル事業部 事業部長
木下 史彦 氏

93. • コミュニケーション
• シンプルさ
• フィードバック
• 勇気
• 敬意
XPの5つの価値

94. 勇気

95. • コミュニケーション
• シンプルさ
• フィードバック
• 勇気
• 敬意
気持ちにかかわるもの

96. ソフトウェアは
人が人のために
作るもの
―Kenji Hiranabe

97. INSPIRE
FUTURE
GENERATIONS
いきいきした
文化の継承を

99. 予習復習研究はこちら
http://capsctrl.que.jp/kdmsnr/wiki/bliki/
ぶりきじゃ
ソフトウェア見積り
人月の暗黙知を解き明かす
http://www.amazon.co.jp/dp/489100522X
エクストリーム・プログラミング実行計画
http://www.amazon.co.jp/dp/4894713411
ケント・ベック／マーチン・ファウラー
Matin Flowler s Blikiの翻訳Wiki
Steve McConnel著