名古屋工業大学 オブジェクト指向勉強会 http://www-ailab.elcom.nitech.ac.jp/oop/

1. オブジェクト指向勉強会
2012.01.13 (Fri)
20号館5階
名古屋工業大学 コミュニケーションルーム
ソフトウェア開発の
現場風景
(株) 永和システムマネジメント
サービスプロバイディング事業部
アジャイルグループ
伊藤 浩一

2. 御礼

4. 永和システムマネジメント
サービスプロバイディング事業部について
私たちは「お客さまに価値を提供し続けるシステム」を
構築します。お客様の環境やビジネスの変化に適応する
システムを、お客さまと一緒に育てていきます。
私たちは、ソフトウェア開発のプロフェッショナルと
しての誠実な態度と、アジャイル開発のアプローチを通
じてこれを達成します。そして、そのための手段として
オブジェクト指向スクリプト言語Rubyが有効だと信じ
て行動しています。 不明確か
つ不安定
な要求 要求 R
Δ (t)
システム S(t)
Δ t
R(t) チーム(t) S(t)
Copyright (c) 2011 Eiwa System Management, Inc.

5. 私たちのミッション
投資効果のある、
ちゃんと動くソフトウェアを、
期待される期間内に提供し、
それを維持・変更し続けられるベンダであり、
ソフトウェアは、人が人のために作っている
というシステム開発を実現します。
Copyright (c) 2011 Eiwa System Management, Inc.

6. Ruby x Agileの実績
10
c-team.jp
8
6
人数
4
2
decoblog.ne.jp
0
0 6 12 18 24 30
期間 (月)
Copyright (c) 2011 Eiwa System Management, Inc.

7. 適用分野
R&D
17%
BtoCサービス
業務システム 52%
31%
Copyright (c) 2011 Eiwa System Management, Inc.

8. 社員の活動
書籍
コミュニティ
 オブラブ
 日本XPユーザグループ
 日本Rubyの会
 Asakusa.rb
Copyright (c) 2011 Eiwa System Management, Inc.

9. 自己紹介
•プログラマ兼現場リーダー
• たまに講演、まれに執筆
• XPやオブジェクト指向で人生が曲がっ
て2004年から現職
•好きなオブジェクト指向関係の書籍は
『アジャイルソフトウェア開発の奥義』

10. 私の関心事

11. ソフトウェア
開発とは何か

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

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

14. 本編

15. 概要
親兄弟にも説明の難しいソフトウェア開発の仕事に
ついて話します。今回はソフトウェア開発の現場
で、私の目に届く範囲の開発者が実践していること
や、私の身の回りで起きていることを題材に話を進
めたいと考えています。標本となるプロジェクトは
アジャイルと言われる開発手法を用いた事例から引
用します。特に少人数での開発の進め方に対して、
何かしら持ち帰って頂ける話にできればと思いま
す。

16. 個人と
チームの話

17. お品書き
•本編における少人数開発
• 現場の一日
• 現場の一週間
• いち技術者として

18. お品書き
•本編における少人数開発
• 現場の一日
• 現場の一週間
• いち技術者として

19. 現場

20. 開発風景

21. だいたい
http://www.slideshare.net/t_wada/the-only-one-big-thing-every-programmer-should-know/58
2∼4人から
の規模

22. プロジェクト別

23. 座席の配置
プロジェクト単位で会話が
しやすいように座席配置

24. 2∼4人?

25. プロジェクトに
はステークホル
ダーがいっぱい

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

27. サービス
インフラ提供
業務
○○に
期待
利害関係別

28. サービス
インフラ提供
業務
○○に
期待
ここ
話の中心

29. 本編における少人数開発
• 同一場所の開発体制2∼4人
• 顧客や他社ベンダーなどを含め
ると見た目以上の要員が関わる
•
東京都心が中心だが、プロジェ
クトによって中部、北陸、海外
に分散してのリモート開発

30. お品書き
•本編における少人数開発
• 現場の一日
• 現場の一週間
• いち技術者として

31. 現場の一日

32. 現場の活動例
プログラミング
朝会
15% 10%
10:00 5%
25% 40%
ディスカッション
夕会 5%
18:00
昼休 午後
夕会 その他
朝会 午前

33. チーム開発の一日
は朝会ではじまる

34. 朝会

35. 朝会
• デイリースタンドアップ
• 2人∼4人で5分∼10分くらい
• 昨日の行ったこと、今日行うこ
と、そして、問題点を共有する
• ありのままを、正直に伝える

36. 問題が出た！
•
簡単なアドバイスで解決できる
問題であれば、その場で解決
•
大きな問題で時間がかかる議論
が必要であれば、別途の場とな
る分科会を設ける
• 朝会自体はライトウェイトに

37. 問題が出ない!?
• 本当に問題はないの？
• プロジェクトは本質的に火事
• メンバーは仕事中ぼやいていな
いか？
•
あなたにとって小さな問題が
チームにとって大きな問題かも

38. プログラミング

39. あなたならどちらを選ぶ？
プログラマーがコードリーディングしている時
•A)年末の冬休みに緊急障害が発生し、真夜
中に１メソッド２０００行のCodeの解読
に頭を痛め「ひゃはー！これはひどい、
Codeだぜ！」と思った瞬間
•B)自分よりできる奴が書いたコードを読ん
で「あ！こんな記述できるんだ。こりゃ
Coolだぜ!」と思った瞬間
http://patterns00-haru01.heroku.com/#57

40. 動くきれいな
コードを目指す

41. ものには、すべて名前がある
「静的解析とはつまりソースコードの解
析だ。そしてソースコードの解析とは名
前の調査である。ファイル名・関数名・
変数名・型名・メンバ名など、プログラ
ムは名前のかたまりだ。」
-Rubyソースコード完全解説 (青木 峰郎)

42. 名前重要

43. http://www.slideshare.net/t_wada/the-only-one-big-thing-every-programmer-should-know/58
―Takuto Wada (t-wada)

44. RSpec
describe Array, "when empty" do
before do
@empty_array = []
end
it "should be empty" do
@empty_array.should be_empty
end
end
編注: 現在の RSpec ではコマンド名が spec から rspecになっています http://jp.rubyist.net/magazine/?0021-Rspec

45. t-wada先生の写経術

46. 継続は力なり

47. チームのインフラ

48. (D)SCM
•技術者の基礎技術
• 私の系譜は CVS→SVN→Git
•ローカルからリポジトリにコミット
することで個人のコードからチーム
のコードになる
• プロジェクトの歴史に名を残す責任

49. 最近の動向

52. 自動化
•
繰り返し発生するコンピュータ
を使った作業をプログラミング
•
例えばビルド、テスト、アセン
ブリ、デプロイなどは定型作業
•
誰でもオペレーションミスなく
同じようにコマンド実行

53. コンピュータの
仕事と人の仕事
の住み分け

54. 継続的インテグレーション
•
リポジトリに変更を補足して、ビ
ルド、テスティングを実行
•
ビルド結果を IRC やメール等で
通知
•
ビルドを壊したことをいち早く見
つけて小さい差分のうちに対処

55. http://speakerdeck.com/u/kenchan/p/devlove201112?slide=34
詳しくは、リンク元の @kenchan による『DevLOVE201112 ビルドをだいじに』を参照してください

56. ホワイトボード

57. 会話風景

58. 何を話しているの？
• 困った時はメンバーに相談
• 仕様の理解の意識合わせ
• 設計方針の議論
• 利用技術の相談

59. 往
http://www.slideshare.net/t_wada/the-only-one-big-thing-every-programmer-should-know/58
来

60. http://www.slideshare.net/t_wada/the-only-one-big-thing-every-programmer-should-know/58
共通項を
探せ !

61. http://www.slideshare.net/t_wada/the-only-one-big-thing-every-programmer-should-know/58
同じ物を
見る

62. 問題の見える化
•触媒 (PC、壁、ホワイトボード) を使って問
題を見える化する その作 いま考えて
きみ、
りだと○○の時の振 いる設計を書き出し
That s You! きちんとお互いのイ
る舞いが足りなくな てみると、こんな感じ
メージが合った状態で
いですか なのね
話してる？
You vs Me Problem vs Us

63. Problem vs Us
•個人についてではなく問題に対
して意見をする
•You vs Me ではなく、
Problem vs Us の形にする

64. 情報の伝達
鮮度の高い情報は時間が過ぎる
と乖離する

65. 報連相は
社会人の基本
人生の師匠の言葉

66. 情報伝達の重要性
•ステークホルダーがいっぱい
• 壮大な伝言ゲーム
• 正しい情報を正しく伝える
• 間違った情報に対して正しく
作ってしまうと、顧客が欲しい
ものを提供できない

67. メールとWiki
•
メーリングリストで時々の情
報の発信をする (スレッド)
•
Wikiでまとめ情報を参照でき
るようにする (スタック)

68. 情報の同期は頻繁に
信頼関係の低下▶
ズレはどこまでも
時間経過
勘違い、忘れた、欲しい物の
内容や優先順が変わった、連絡がな
いとそもそも何を考えしてるのか
分からず不安
早めにズレを修正
時間の経過▶

69. 相手に分かる言葉で
•
文章に不安があれば、メンバー
間でのレビューは有効な手段
• 大きな質疑はキャッチボールで
•伝える事柄と伝える方法は車
の両輪だと考えること と達人
プログラマーにもあるよ

70. こんな大人はやだ
•「言った」「言ってない」問題
• 大人として恥ずかしい
• 伝えるための努力をしよう

71. お品書き
•本編における少人数開発
• 現場の一日
• 現場の一週間
• いち技術者として

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

73. 開発打ち合わせ

74. 開発打ち合わせ
•デモとフィードバック これらは一例
• 要望のヒアリング
• 作業の完了条件を共有する
• 問題点、課題点の共有
• 全体スケジュールの確認

75. 見積りと計画づくり

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

77. 見積りと計画づくり
•開発メンバー全員で、
• 作業を洗い出して、
•作業が終わるのにどれだけかかる
かを見積って、
•優先順位をつけてならべる

78. プランニングポーカー

79. 数字が合わない！
•ゲームではなく見積り
• 数字合わせではない
•どうなればその作業が終わるかの
認識が合っているか話し合おう
•まわりが見落としている作業にき
みだけが気づいているかも

80. Pivotal Tracker
www.pivotaltracker.com

81. 変化ヲ
抱擁セヨ

82. ふりかえり

83. Problem vs Us
•個々での気づきや問題を共有
• 原則チーム全員が参加する
• 反省会ではなくふりかえり
• 過去から学んで、いまの状況を
確認して、次への改善行動に繋
げる

84. 関連した他の

86. なぜチームか？

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

88. 敬意

89. まだ時間は
大丈夫です
ね？

90. お品書き
•本編における少人数開発
• 現場の一日
• 現場の一週間
• いち技術者として

91. どんな人と
仕事をした
いですか？

92. 人に注目する
•同僚
• プロジェクトメンバー
• コミュニティ
• プロダクトやサービスの製作者
• 興味ある技術発信をしている人

93. 発信
http://ja.wikipedia.org/wiki/ファイル:2002東京タワー塗装作業中.jpg

94. 外部発信
•Web日記
• 勉強会
• 執筆
• ソフトウェアの公開、パッチ
• コミュニティ

95. Web日記

96. ソースコード

97. 情報発信
•
アウトプットを出すことで整理
できる
• パブリックな職務経歴書
• 誰(どんな人)と仕事をしたいか
• 仕事をしたいと思われるか
中の人の顔が見える組織

98. 誰と重要
by Ryo Amano

99. 何ができれば一
人前と呼ばれる
でしょうか？

100. 専門職

101. 少人数開発
と多能工

102. 現場技術の一部
•Linux まだまだあるぞ！
• ソースコードの読み書き
• 文書の読み書き
• 見積りと計画作り
• (D)SCM、テスト、自動化

103. 一朝一夕に
は成せない

104. 継続は力なり

105. 名著が語る重要なこと
達人プログラマー
David Thomas, Andrew Hunt
1.自らの技術に関心を持つこと
2.あなたの仕事について考えること！
アジャイルサムライ
Jonathan Rasmusson
1.君は学ぶことが心から好きだ
2.君はソフトウェアのことを大切に思っている

106. 予習復習研究はこちら
達人プログラマー
David Thomas, Andrew Hunt
http://www.amazon.co.jp/dp/4894712741
アジャイルサムライ
Jonathan Rasmusson
西村直人, 角谷信太郎(監訳)
近藤修平, 角掛拓未(訳)
http://www.amazon.co.jp/dp/4274068560
受託開発の極意
岡島 幸男
http://www.amazon.co.jp/dp/4774134538

107. 誇りと
希望