アジャイルについての入門とオブジェクト指向設計についての入門

1. DNA works 小川 崇

3. ソフトウェア開発にまつわる複雑な課題
http://www.projectcartoon.com/cartoon/586
そもそもないところから作る
データの動きは目に見えない
画面イメージはOKでも、動作が……
要件や仕様が変わる
工程を後戻りできない
そもそも脳内補完が人それぞれ
リリースしてから、これ違う！と言われる

4. 『人月の神話』（F. P. Brooks, Jr. 1975）
ブルックスの法則
遅れているソフトウェアプロジェクトへの
要員追加は、プロジェクトをさらに遅らせ
るだけ
「銀の弾などない」―― つまり……
決定的な解決方法はない！ということ

5. 購入できるものならば あえて作らない
素早くプロトタイプを提示する
順次追加していく手法をとる
若く抜きん出た設計者を発掘して育てる

6. アジャイル（機敏な）開発とは……
「アジャイルソフトウェア開発宣言」
（アジャイル マニフェスト 価値と原則）
http://agilemanifesto.org/iso/ja/manifesto.html
以下のものに価値を置く
• 個人と対話 ＞ プロセス、ツール
• 動くソフトウェア ＞ ドキュメント
• 顧客との協調 ＞ 契約交渉
• 変化への対応 ＞ 計画遂行

7.  顧客との協調
 密な意識合わせ
 チームメンバーの主体性の重視（少数精鋭型）
 メンバーの一体感の重視（お客様も巻き込む）
 短い反復型の開発
 小さなタスク化
 顧客には動くプログラムを素早く提供
 ドキュメントよりも動く製品を提供
 短期間のリリースで順次機能追加
 変化を受け入れることを前提とする
 冗長性の排除
 単純性と透過性の追求

8. 毎日のごく短いミーティング（起立して）
バーンダウン チャート（%ではない）
かんばん
ふりかえり（KPT）
ほかにも、テスト駆動開発、自動テスト、
あんどん
そして、カイゼン

9. eXtreme（極限） Programming の略
最も代表的なアジャイル開発手法
先進的であり、ヒナガタとも言える
5つの価値
12～21のプラクティス（実践手法）
プラクティスは状況により取捨選択
ひとつとして同じ状況はない

10. 以下のことは、これまで語ってきたことと
関係が深いことがおわかりでしょう。
• コミュニケーション
• 簡潔さ
• フィードバック
• 勇気
• 尊重

11. 顧客もチーム メンバー！
顧客は機能をストーリーとして記す
優先度は顧客が見積る
開発メンバーはどう実現するかを決定する
ストーリーの工数は開発メンバーが見積る
2～3週間で何がリリースできるかを話し
合い、リリースするものを決める
顧客は要件と優先度を、開発者は実現方法
と工数を決める権利がある

12. タイムボックス化
顧客のストーリーを開発者のタスクに変換
開発メンバーがタスクを自分で選び取る
計画ゲーム～短期リリースの繰り返し
一反復（Iteration）は2～3週間程度
一反復の中に、すべての工程が入る
動くものをリリースしてフィードバックを
得る
フィードバックを受けて軌道修正
変化を受け入れるその中での取捨選択

13. 機能、モジュール、動作などに、顧客、開
発者、マネージャーを通じてイメージでき
るわかりやすい名前をつけ、システムや機
能のイメージを皆で共有する
目に見えない抽象的なソフトウェア要素に
対して同一イメージを共有するために有効
モックやプロトタイプの提供
厳密な詳細設計ドキュメントは作成しない

14. 忍び寄る複雑さの排除
反復の中で機能などを順次追加していく
追加されるごとに複雑さを回避し見直す
今必要ないものは作らない
計画は変更されるものという前提
YAGNIの原則 “You Ain’t Gonna Need It!”

15. テストに通ったものだけ、価値がある
「未テストのコードは、無いのと一緒」
まず最初にテストを作ってしまう「テスト
駆動開発」(Test Driven Development)
テストが仕様を表している
単体テストと機能（ストーリー）テスト
テストを自動化する
「あんどん」などを活用

16. 機能は変えずに、内部設計を最適化する
いつでもどこでも誰でも常に行い続ける
テストがあるから、実現できる
壊したらその人が直す
シンプルさを保つためにコードを保守する
コードが詳細設計書である
人も読めるように単純化する

17.  常に2人ペアでプログラミングする
 直々の即時レビューを兼ねている
 誤りに気づく、軌道修正が入る
 学び合い、刺激し合い、効率が上がる
 責任を分け合い、安心感がある
 コードも知識も共有できる
 独りに比べて、統計的に以下の効果がある
• 工数は 2 倍にはならず、15% 増しである
• 欠陥率は 85% に減少する
• コードは 70～90% に減少する
• 再作業が 15 分の 1 に減少する

18. 専門担当はない、皆が所有者
積極性を歓迎する
知識もノウハウも分かち合い、一つになる
皆で向上し、改善する
コードも皆が所有者、皆が全部の担当者
常に誰でもどの箇所も編集可能
複数人にレビューされる効果がある
偏らないで知識とイメージが共有できる
初心者には学びとなる

19. 単体テストが済んだものはすぐ結合する
リスクの高いものは先に行う
失敗しても早く気づき、手当てできる
結合が遅れると、他の依存物も遅れる
自動ビルドや自動テストがあるとよい

20. 残業はしない
1日8時間×5日=40時間
リズムを作ることが大切
チームのために必要
モチベーション維持のため
品質を確保するため
残業しても能率も成果も上がらない
バグなどリスクが増えるだけ
タイムボックスで区切り、その中で解消
できないならば、計画の仕切り直し

21. 顧客もチーム メンバーである
決定権のある顧客に常駐してもらう
機能テスト作成は本来、顧客の仕事
開発チームとの連帯性を高める
開発チームの作業を見守る
質問などに即座に答え、意識乖離を防ぐ
無理なら毎日でなくてもよい
逆にチームが顧客の所へ常駐でもよい
それでも無理なら顧客代理人を立てる

22. 皆が編集しやすいように標準を設ける
コードの共有を円滑に進めるため
縛り付けるためではない
「rule」ではなく「standard（ 標準）」
リファクタリングはこのコード標準に準拠
して行われる

23. 透過性の重視――正直に見える化！
問題を早く摘み取る
開発者以外でも進捗を正しく把握
報告の時間短縮、即時性
コミュニケーション促進（一体化）
単純明快な表示
• バーンダウンチャート
• かんばん
• あんどん
• ニコニコ カレンダー

24. 今や世界でも通じる Kaizen
現場のノウハウから、改善していく
最終ゴール（限界）はない
反復の中での ふりかえりと実践
アジャイル開発それ自体がカイゼン
KPT（ケプト）は、K がミソ
Keep Problem Try
毎日小さなことでも、改善点、伸長点を書
いていく

25. 皆がメンターになる
知識を共有する
教えることが深い理解につながる
できることが増えると楽しくなる
育成ゲーム

26.  暗黙知とは……見えないお互いの了解
 「KY」「今日の茶漬け」など、日本は暗黙知
を重んじる文化
 親密になると、価値観、経験、情報を共有で
き、暗黙知が増える
 通じた「つもり」のトラブルもある
 形式知とは……詳細な説明
 プログラミング言語や契約書
 しかし、すべて記述するのは不可能であり、
Output も Input も効率が悪い

27. 『アジャイルプラクティス
達人プログラマに学ぶ現場開発者の習慣』
『アジャイルサムライ
－達人開発者への道－』

29. アジャイル開発での問題解決との対応
• 順次機能追加
• 仕様変更
• 小さなタスク
• 順次リリース
• テスト
• リファクタリング
⇒ 独立した部品
• メタファー（比喩）
⇒ 部品はオブジェクト（←比喩！）

30. 取り換え可能（仕様変更）
単体テストが容易（テスト）
メンテナンスが容易（リファクタリング）
部品追加で機能追加
（小さなタスク、順次リリース）
⇒実現させるために必要なものは、
疎結合

31. 依存関係を減らし、一点に集約させる
• 他オブジェクトへの依存
• 状態への依存
• 環境への依存
解決方法
• 依存先の移行 オブジェクト⇒インターフェイス
• 依存性の注入 (Dependency Injection)
• デザイン パターン

32. わかりやすい名称をつける
⇒ 責務と役割が明確に
列挙型（Enum）の存在意義
⇒ 選択肢の比喩化
多態性（Polymorphism）の意義
⇒ 責務の相手への委譲
抽象化≒比喩
⇒ モデリング（＝比喩）

33. 冗長性……たとえば、コピペのコード
冗長性は、オブジェクトの責務を壊す
仕様変更などでは、すべてを正しく調整す
る必要が生じる
冗長性はバグとタスクを増やす

34. ドキュメントとコードは、冗長である
コメントとコードも冗長である
両方のメンテナンスが必要
動くソフトウェアの提供が最も重要
仕様はドキュメント、詳細設計はコード
読めるコードの必要性
コメントはあくまでコードの補完

36. モチベーションに大きく作用
効率や品質に影響
人の体の構造、プログラムとよく似ている
原因があり不具合が発生する
環境（人）によって様々
不具合対処で大切なのは、原因の除去
例：頭痛薬（応急処置）

37. ご清聴、ありがとうございました。