ソフトウェア開発の現場風景

(株) 永和システムマネジメントサービスプロバイディング事業部

アジャイルグループ伊藤 浩一

2012.01.13 (Fri)20号館5階名古屋工業大学コミュニケーションルーム

オブジェクト指向勉強会

御礼

Copyright (c) 2011 Eiwa System Management, Inc.

私たちは「お客さまに価値を提供し続けるシステム」を構築します。お客様の環境やビジネスの変化に適応するシステムを、お客さまと一緒に育てていきます。私たちは、ソフトウェア開発のプロフェッショナルとしての誠実な態度と、アジャイル開発のアプローチを通じてこれを達成します。そして、そのための手段としてオブジェクト指向スクリプト言語Rubyが有効だと信じて行動しています。

永和システムマネジメントサービスプロバイディング事業部について

要求　　R(t)システム　　S(t)

チーム(t)R(t) S(t)

Δ

Δ t

不明確かつ不安定な要求

Copyright (c) 2011 Eiwa System Management, Inc.

投資効果のある、ちゃんと動くソフトウェアを、期待される期間内に提供し、それを維持・変更し続けられるベンダであり、ソフトウェアは、人が人のために作っているというシステム開発を実現します。

私たちのミッション

Copyright (c) 2011 Eiwa System Management, Inc.

0

2

4

6

8

10

0 6 12 18 24 30

人数

期間 (月)

Ruby x Agileの実績

decoblog.ne.jp

c-team.jp

Copyright (c) 2011 Eiwa System Management, Inc.

適用分野

BtoCサービス52%業務システム

31%

R&D17%

Copyright (c) 2011 Eiwa System Management, Inc.

社員の活動書籍

コミュニティオブラブ日本XPユーザグループ日本Rubyの会 Asakusa.rb

自己紹介•プログラマ兼現場リーダー•たまに講演、まれに執筆•XPやオブジェクト指向で人生が曲がって2004年から現職

•好きなオブジェクト指向関係の書籍は『アジャイルソフトウェア開発の奥義』

私の関心事

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

ソフトウェアは人が人のために作るもの

―Kenji Hiranabe

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

本編

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

概要

個人とチームの話

お品書き

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

お品書き

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

現場

開発風景

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

プロジェクト別

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

座席の配置

2～4人?

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

業務

○○に期待

サービスインフラ提供

ご近所さん

業務

○○に期待

サービスインフラ提供

利害関係別

業務

○○に期待

サービスインフラ提供

ここ

話の中心

本編における少人数開発•同一場所の開発体制2～4人•顧客や他社ベンダーなどを含めると見た目以上の要員が関わる

•東京都心が中心だが、プロジェクトによって中部、北陸、海外に分散してのリモート開発

お品書き

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

現場の一日

現場の活動例朝会

夕会

プログラミング

ディスカッション

15%

5%

25%

5%

40%

10%

昼休 午後夕会 その他朝会 午前

10:00

18:00

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

朝会

•デイリースタンドアップ•2人～4人で5分～10分くらい•昨日の行ったこと、今日行うこと、そして、問題点を共有する

•ありのままを、正直に伝える

朝会

•簡単なアドバイスで解決できる問題であれば、その場で解決

•大きな問題で時間がかかる議論が必要であれば、別途の場となる分科会を設ける

•朝会自体はライトウェイトに

問題が出た！

問題が出ない!?•本当に問題はないの？•プロジェクトは本質的に火事•メンバーは仕事中ぼやいていないか？

•あなたにとって小さな問題がチームにとって大きな問題かも

プログラミング

あなたならどちらを選ぶ？

•A)年末の冬休みに緊急障害が発生し、真夜中に１メソッド２０００行のCodeの解読に頭を痛め「ひゃはー！これはひどい、Codeだぜ！」と思った瞬間

•B)自分よりできる奴が書いたコードを読んで「あ！こんな記述できるんだ。こりゃCoolだぜ!」と思った瞬間

http://patterns00-haru01.heroku.com/#57

プログラマーがコードリーディングしている時

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

「静的解析とはつまりソースコードの解析だ。そしてソースコードの解析とは名前の調査である。ファイル名・関数名・変数名・型名・メンバ名など、プログラムは名前のかたまりだ。」

ものには、すべて名前がある

-Rubyソースコード完全解説 (青木 峰郎)

名前重要

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

RSpecdescribe Array, "when empty" do before do @empty_array = [] end

it "should be empty" do @empty_array.should be_empty endend

http://jp.rubyist.net/magazine/?0021-Rspec編注: 現在の RSpec ではコマンド名が spec から rspecになっています

t-wada先生の写経術

継続は力なり

チームのインフラ

(D)SCM•技術者の基礎技術•私の系譜は CVS→SVN→Git•ローカルからリポジトリにコミットすることで個人のコードからチームのコードになる

•プロジェクトの歴史に名を残す責任

最近の動向

自動化•繰り返し発生するコンピュータを使った作業をプログラミング

•例えばビルド、テスト、アセンブリ、デプロイなどは定型作業

•誰でもオペレーションミスなく同じようにコマンド実行

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

継続的インテグレーション•リポジトリに変更を補足して、ビルド、テスティングを実行

•ビルド結果を IRC やメール等で通知

•ビルドを壊したことをいち早く見つけて小さい差分のうちに対処

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

ホワイトボード

会話風景

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

往来

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

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

共通項を探せ｠!

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

同じ物を見る

•触媒 (PC、壁、ホワイトボード) を使って問題を見える化する

Problem vs UsYou vs Me

問題の見える化

That’s You!きみ、

きちんとお互いのイメージが合った状態で

話してる？

その作りだと○○の時の振る舞いが足りなくな

いですか

いま考えている設計を書き出してみると、こんな感じ

なのね

Problem vs Us•個人についてではなく問題に対して意見をする

•You vs Me ではなく、Problem vs Us の形にする

情報の伝達

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

報連相は社会人の基本

人生の師匠の言葉

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

•メーリングリストで時々の情報の発信をする (スレッド)

•Wikiでまとめ情報を参照できるようにする (スタック)

メールとWiki

早めにズレを修正時間の経過▶

情報の同期は頻繁にズレはどこまでも時間経過

勘違い、忘れた、欲しい物の内容や優先順が変わった、連絡がないとそもそも何を考えしてるのか

分からず不安

信頼関係の低下▶

相手に分かる言葉で•文章に不安があれば、メンバー間でのレビューは有効な手段

•大きな質疑はキャッチボールで•“伝える事柄と伝える方法は車の両輪だと考えること” と達人プログラマーにもあるよ

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

お品書き

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

Copyright (c) 2011 Eiwa System Management, Inc.

イテレーション (1週間) の流れ要求

リリース可能なソフトウェア

Ship It!

次のイテレーションへ

内部リリース

ふりかえり KPTベロシティ

バックログ

タスクプログラミング

機能バグデータ移行ドキュメント環境構築性能ジョーカー

受入テストを書く 受入テストを

する

完了基準

TDD CI

仕様の確認 見積り スパイク

ふりかえりやバックログの優先度付けなどはお客さまにご協力いただきながら進めていきます。

開発打ち合わせ

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

これらは一例

見積りと計画づくり

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

見積りと計画づくり•開発メンバー全員で、•作業を洗い出して、•作業が終わるのにどれだけかかるかを見積って、

•優先順位をつけてならべる

プランニングポーカー

数字が合わない！•ゲームではなく見積り•数字合わせではない•どうなればその作業が終わるかの認識が合っているか話し合おう

•まわりが見落としている作業にきみだけが気づいているかも

Pivotal Trackerwww.pivotaltracker.com

変化ヲ抱擁セヨ

ふりかえり

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

関連した他の

なぜチームか？

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

敬意

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

お品書き

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

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

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

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

外部発信•Web日記

•勉強会•執筆•ソフトウェアの公開、パッチ•コミュニティ

Web日記

ソースコード

情報発信•アウトプットを出すことで整理できる

•パブリックな職務経歴書•誰(どんな人)と仕事をしたいか•仕事をしたいと思われるか•中の人の顔が見える組織

誰と重要by Ryo Amano

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

専門職

少人数開発と多能工

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

まだまだあるぞ！

一朝一夕には成せない

継続は力なり

1.自らの技術に関心を持つこと2.あなたの仕事について考えること！

1.君は学ぶことが心から好きだ

2.君はソフトウェアのことを大切に思っている

アジャイルサムライJonathan Rasmusson

達人プログラマーDavid Thomas, Andrew Hunt

名著が語る重要なこと

予習復習研究はこちら

http://www.amazon.co.jp/dp/4774134538

受託開発の極意

アジャイルサムライ

http://www.amazon.co.jp/dp/4274068560

達人プログラマー

http://www.amazon.co.jp/dp/4894712741David Thomas, Andrew Hunt

岡島 幸男

西村直人, 角谷信太郎(監訳)近藤修平, 角掛拓未(訳)

Jonathan Rasmusson

誇りと希望