Ruby Business Users Conference 2015 (http://rubybusiness-conf.org/)

1. Agile software development meets Ruby
10 years after
Ruby x Agileに至る
2015.02.25 (Wed)
品川フロントビル 会議室
Ruby Business Users Conference 2015
受託開発10年のいま
https://ja.wikipedia.org/wiki/%E5%A4%89%E8%BA%AB%E8%AD%9A#mediaviewer/File:Cadmus_teeth.jpg
(株) 永和システムマネジメント
アジャイル事業部
Ruby x Agile グループ
伊藤 浩一 (@koic)

2. 御礼

5. 自己紹介

6. 伊藤 浩一 (@koic)
•2000年頃、オブジェクト指向プログラ
ミングの学習言語として出会う
•好きなRuby256本シリーズは「極道
編」と「無道編」
•XPに憧れて2004年より現職 (10周年)
•現在、Railsをもちいた受託開発のプロ
ジェクトのリーダーを務める

7. 前史

8. 10 years ago

9. 2005.12.16

10. http://www.rubyist.net/ matz/slides/oc2005/

11. http://www.rubyist.net/ matz/slides/oc2005/

12. AWDwR写経会＠東京.ESM
http://kakutani.com/20051122.html#p01

13. Before Rails案件の素振り時代
http://kakutani.com/20051122.html#p01
Java
JavaJava
Java

14. http://kakutani.com/20051122.html#p01
Java
JavaJava
Java
社外の人
(のちに同僚となる)
Before Rails案件の素振り時代

15. 草の根運動から
Rubyの仕事と
仲間が増え始めた

16. Ruby on
Railsという
ホームラン

17. 時は流れる
http://ja.wikipedia.org/wiki/%E5%A4%A9%E3%81%AE%E5%B7%9D#mediaviewer/File:Milky_Way_from_Flickr.jpg

18. 2014.12.17

20. Techの話

21. コミュニティ担当
@koic @moro
プロジェクトリード職 プログラミング職

22. コミュニティ担当
@koic @moro
プロジェクトリード職 プログラミング職

23. 2015.02.25

24. いまここ

25. 今日の話

26. Rubyを使った
受託開発組織の
現場開発のいま
http://www.ruby.or.jp/ja/news/20150127.html

27. ホームラン
を打った後

28. 事例の話

29. #1 受託開発とRuby
#2 Agileソフトウェア開発
#3 Ruby x Agile
お品書き

30. #1
#1 受託開発とRuby
#2 Agileソフトウェア開発
#3 Ruby x Agile
お品書き

31. プロジェクトB
プロジェクトC
プロジェクトA
.
.
.
私がいる世界
開発者 仕事

32. 私がいる世界
•特定の業務知識に寄らない
•SES契約で、nヶ月をx人で受け
る体制が多い
•一括請負もあるにはあるけど…
•基盤となる技術はほとんどのプロ
ジェクトがRuby/Rails

33. 私が構築する世界
•World Wide Webで実現する
•Relational Databaseを中
心としたデータの永続化
•プロジェクトごとのユーザーが
頭に描いた世界

34. 変化する
プロジェクト
と人と技術

35. 技術基盤の変遷
•Java→Ruby
•CVS→SVN→Git
•Trac→Redmine→Pivot
al Tracker
•IRC→Idobata

36. プロジェクトに関わる人を横断する技術

37. プロジェクトに関わる人を横断する技術

38. Railsを中心
に据えた開発

39. 要員の変化を支える技術
•DRY
•プロジェクトごとにフレームワークの覚え直しが
減った
•設定より規約
•テスティング, Pull Request, Continuous
Integrationがどこに行っても当たり前になった
開発の文化
•Rubyコミュニティの人たちと仕事する際の規約

40. 環境を統一でき
なくなったもの
http://ja.wikipedia.org/wiki/%E3%83%90%E3%83%99%E3%83%AB%E3%81%AE%E5%A1%94#mediaviewer/File:Pieter_Bruegel_the_Elder_-_The_Tower_of_Babel_(Vienna)_-_Google_Art_Project_-_edited.jpg

44. •ペアプログラミングと比較して、
常時レビューの非同期化
•チーム単位での開発の透明性
•副作用としてどこまで進んでるか
Pull Request ベースで確認で
きる (生煮えWIP上等文化)
ソーシャルコーディング

45. コードレビューへの影響
•ペアプログラミングの低下と
ソーシャルコーディングの上
昇
•直交するものなので掛け合
わせると良さそう

46. 私がいる世界
•基本はプロジェクト専任
•業務特有の問題には踏み込み
づらいが、Ruby/Rails/
SQLなど横断する技術には比
較してコメントしやすい

47. コードを書けば、
他のプロジェクト
メンバーの目に触
れる機会がある

48. 開発者とし
ての楽しさ

49. 『美しいコードを書ける
からRubyを選んだ』
http://itpro.nikkeibp.co.jp/article/NEWS/20060620/241346/

50. Looks Good To Me
• PR は master に入る前の最後の機会
• master に入った後のコード読んでいますか？
• 永和のmasterには変なコードがない by @akiinyo
• https://speakerdeck.com/akiinyo/puroguraminguwei-jing-yan-nantebu-kunai-ritanzu#15
• LGTM画像にする
https://f.cloud.github.com/assets/1606673/2307945/6ef72b40-a2b5-11e3-9708-9a7e6f7486a8.png

51. http://www.lgtm.in
• Looks Good To Me
• レビューに楽しさを
• ご利用は文化にご相談ください
• LGTM画像にする
https://f.cloud.github.com/assets/1606673/2307945/6ef72b40-a2b5-11e3-9708-9a7e6f7486a8.png

52. プログラマーとユーザーと
プログラマー ユーザー
ソフトウェア
(触媒であり成果)

53. 受託開発
の楽しさ

54. お客さんが目
の前で喜んで
いるんだぜ？

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

56. 感性重要
•Rubyをキメているとき
•Pull RequestへのLGTM
•顧客とのハイタッチ

57. われわれの
受託開発を
支えるもの

58. #2
#1 受託開発とRuby
#2 Agileソフトウェア開発
#3 Ruby x Agile
お品書き

59. http://www.agilemanifesto.org/

60. https://ja.wikipedia.org/wiki/Vモデル
インプットとアウトプットが繋がるVモデル
反復型開発における草モデル
つづきはこちら
feedback feedback feedback feedback feedba

61. 継続的
デリバリー
見積りと
計画づくり

62. 見積りと
計画づくり

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

64. 見積りは
プログラマーの仕事
FAQ. どれくらいでできそうですか？

65. •Rubyでの実装を背景にした見積り
•「○というgemを使えば」
•「あのあたりはdeviseを独自拡張していて
(ry」
•類似を実装したときより大きいか、小さいか
•類似例に詳しいメンバーがいれば解決が速くな
る
•プロジェクトを横断した実装経験
見積り is 設計

66. 言語は見積り
を規定する

67. 言語重要

68. 環境重要

69. !
開発環境の構築 レビュー マージ
デプロイ &
デベロッパー
テスト
カスタマー
テスト
本番デプロイ
リリース
モニタリング
見積りと
計画づくり
!
プログラミング
作ってテストしたらデプロイ
Goal
Start

70. 継続的
デリバリー

71. •デプロイという普遍性のある
流れと cap deploy という
インタフェース

72. •rake deploy
•lib/task/deploy.rake
•Cap準拠のインタフェース
•驚き最小限の法則
とあるオンプレ環境

73. •ビッグバン結合の恐怖
•顧客は何が出てくるか手に汗を握
る
•イテレーションでできることを体験
•ユーザーが使っている機能の上に拡
張したい機能の話できる
リリースして経験する

74. フィードバッ
クを得続ける
ことの重要性

75. #3
#1 受託開発とRuby
#2 Agileソフトウェア開発
#3 Ruby x Agile
お品書き

76. プログラマー(現場)による開発手法

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

78. https://speakerdeck.com/kakutani/agile-samurai-and-now?slide=16

79. Lightweight feedback stream
脳
力
の
消
費
少
を
重
視
体
験
を
俊
敏
に
プログラマー ユーザー
ソフトウェア
(触媒であり成果)３.読み書きデプロイ
(プログラミング言語)
４.使う (Webブラウザな
ど)
個人との対話を
重視
1.対話する
ソフトウェア開発の至るところに存在する
フィードバックをいちはやく得たい
2.設計する、コードレビューする

80. 人からの
フィードバック
言語(環境)からの
フィードバック

81. 言語(環境)からの
フィードバック

82. • Lightweight Languageとは「脳
力」を少なく消費する
• 「脳力」はプログラミング中に消費され
る仮想的なパワーである
• 消費「脳力」の総和が少ないことももち
ろん重要だが瞬間最大消費「脳力」が大
きすぎるのもよろしくない
『脳力』のおさらい

83. • irb (rails c) とテストコードの組み合わせ
• 手軽な書き捨てを選択肢に入れたトライ&
エラー
• 環境の統一によりフロアに知見者がいれば
聞いて終わる手早さ
• インターネットの情報量
手早くフィードバックを得られる環境

84. 人からの
フィードバック

85. • ユーザーと共有した見積りと計画をメンテナンスし続ける
• Pivotal Trackerのストーリー
• ユーザーとプログラマーで共有された、チームのベロシティ
に乗っ取った期待の共有
• 「このフィードバックはどの程度のポイントか？いつに
リリースできそうか？」
• リリース後の動きを見た余地を残して、一気に全部を
作らない文化の形成
Embrace Change

86. プログラマーとユーザー
間でフィードバックを繰
り返しながら、狙え、か
まえ、撃てで手に入れる

87. 脳
力
の
消
費
少
を
重
視
体
験
を
俊
敏
に
プログラマー ユーザー
ソフトウェア
(触媒であり成果)
Lightweight feedback stream
３.読み書きデプロイ
(プログラミング言語)
４.使う (Webブラウザな
ど)
個人との対話を
重視
1.対話する
５.フィードバックする
2.設計する、コードレビューする
Problem
Us

88. 右手にRuby
Us
Problem
左手にAgile

89. 全体の調和
http://ja.wikipedia.org/wiki/%E7%A2%81%E7%9B%A4#mediaviewer/File:Go_board.jpg

90. アジャイルな
開発手法と実
によく馴染む

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

93. http://www.rubyist.net/ matz/slides/oc2005/