2016/06/26、アジャイル巡業in仙台でのセミナー資料です

1. アジャイルパラレル開発
アジャイルプロセス協議会 ASMWG
川上 文夫

2. 自己紹介
• 川上 文夫
• 1988年からシステム開発に携わる
• 1994年からは中規模案件の開発リーダー、現役続行中
• 制御アプリ、業務アプリ、インフラ構築、フレームワーク
• 雑誌、Web
– 「開発の現場」、「Software Design」、「PM Magazine」
– マイナビ 「現場から届けるアジャイル開発」
• http://news.mynavi.jp/series/agile_developme/001/
• ワークショップ
– 議事録からはじめよう、コミュニケーションの輪(オブジェクト倶
楽部2008年)
– WikiWikiアジャイル(Regional Scrum Gathering® Tokyo 2014 )

3. 本日のアジェンダ
• 14:10 アジャイルパラレル開発についての
ご紹介
• 14:30 グループディスカッション
• 14:50 グループ発表

4. いまさらアジャイル
• アジャイルプロセスはすでに定着
• しかし諸事情によりアジャイルを実践できな
い現場も多い
– やり方がよくわからない
– 反対しているメンバーがいる
– お客様がウォーターフォール開発を希望している

5. アジャイルパラレルとは
• 全員が、設計、実装、テストを担当
• イテレーション期間は決めない
設計、実装、テストは常に同時に実行される
• リスクの高い部分は別ブランチ(都度判断)
• 時には見積もり時や要件定義時にも適用
• 建築では不可能と思われる
– 設計と実装が同時に進む
• コンカレントエンジニアリング(サイマルテニアス
エンジニアリング)と似ている
この資料を書いている最中に発見しました
https://en.wikipedia.org/wiki/Concurrent_engineering

6. ウォーターフォール開発
要件
設計
実装
テスト
運用
要求

7. ウォーターフォールの理由
• 何度も作り直しはできなかった
– コンパイルは30分
– 動作確認は接続先のホスト
– 開発後半の修正はコスト大
• プログラミングは専門知識
– ベンダーごとに異なる仕様
– 専門知識
• 建築と同じ
– 設計して、基礎を作って、建物建てて

8. ウォーターフォールの問題
• 設計書は必ずミス、漏れがある
• 設計書は必ず古く、最新化されない
• 設計書の解釈が人によって違う
• テスト局面で障害が多発
– 動かしてみたら要件漏れが発覚
– 動かしてみたら仕様に齟齬
• 仕様Fix後には何も変更できない
– 「設計書に記載されていないので作れません」
– 「その部分は修正できないんだよ。下手に触ると動か
なくなりそうなんだ。」

9. アジャイル開発
(イテレーション)
要件
設計
実装
テスト
運用
要求

10. アジャイル開発の理由
• 細く設計、実装、テストを繰り返す
– 動くシステムを見ながら確認
– テスト、リファクタリング技術の発達
– モック、ドライバの実現
• 動かしてみれば問題に気づくのなら、動かし
てみよう
• 組み立て式住居
– 設計、して工事していく方針は同じ

11. アジャイル開発の問題
• 設計者と実装者は別
– 認識のズレなどが起きる場合も
– 仕様書は重視されない
– 開発は成功しやすいが、運用保守では仕様書がない
と厳しい
• イテレーション開発ノウハウがないと失敗する
– 要件変更が多すぎる
– ドキュメントがない
– テストの工数が高く、維持できない
– イテレーション完了時に初めて齟齬に気づく場合も

12. アジャイルパラレル
(並列実装モデル)
要件
設計
実装
テスト
運用
要求
• 開発者全員で、設計、実装、テストを並列で
行う手法
• 常に動くシステムを維持するのでイテレーショ
ン概念は無い

13. 常時開発、常時結合
• 設計、実装、テストは同時進行
• 適用局面は設計以前ならいつでも可能
– 見積もり時に実装、テストをすると見積精度アッ
プ
• 確認しながら実装、問題に気づきやすい
• 実装しながら仕様も更新

14. フルスタックエンジニア
• 理想は、全員が設計、実装、テスト担当
– プログラミングは小学生でも可能な時代
(設計しかできないなんて言わせない)
– 実装能力があるほうが設計に有利
– 設計能力があるほうが実装に有利
– それぞれ専門分野があれば尚良し

15. アジャイルパラレルの理由
• 作って試すコストが低減
• 子供でもプログラミング可能な時代の到来
• 設計者が実装するのが最も効率的
• 設計書は不要、仕様書は必要。仕様書は実
装しながら書く

16. アジャイルパラレルの問題
• 大規模開発には適用できるかわからない
– できると思うが経験がない
• 設計者も実装スキルが必要
– ペア作業により均一化をはかっていく
• 仕様書の修正を忘れてしまう
– 忘れないようにその場で修正(Wikiを使う)
– 朝会で報告、認識合わせ
• いつ完成するのかわからない
– 機能単位で必須、任意を区別する
– 必須機能が全て完了すればあとは余暇

17. 大事なこと
• 仕様はFixしない
– 変更要求は良いシステムになろうとする継続的な
状況
– なんでも受け入れるのではなく、期日、システム
への影響度などを考慮し優先付け、Must haveを
心がける
• 実装、テストは変更される前提と心得る
– 変更がはいってもへこたれない
– 完成品は存在しない、(よく出来たコードも明日に
は他の人が改造するかもしれない)

18. 気をつけること
• 一度手をとめて十分設計が必要なときもある
– 難易度の高い機能などはチームで検討
– 方針が決まったら簡単なメモをのこし、実装へ
– 実装、テストをしながら仕様書を書いていく
• チーム内で何が起きているかを毎日共有
– 朝会、必須
– 朝会議事録、必須(明日伝えたい事は伝えたいと
思った瞬間に書いておく)

19. 仕様書は重要
• 仕様には5W1Hを書く。特に「なぜ」が重要
– なぜ(何を目的に)このよう仕様か
• 得意先の選択方法がA機能とB機能で違う理由
• 条件網羅など動かしてもわからない
– 特殊な条件は気づきにくい
• サービス停止1時間前に特殊メッセージを表示
• 2/29は特別な処理
• 事前にAを実施している場合、B機能の振る舞いが違う
• 作るための設計書は不要な場合が多い

20. アジャイルパラレルの事例1
• サービス連携する二つのサブシステム
– 2名 x 2チーム、2ヵ月の構築期間
• 設計レビュー時
– 他チーム:30ページに及ぶWordドキュメント
– 自チーム:2ページの概要設計
• 実装はどちらもオンスケ
• テスト
– 他チーム:デグレード頻発
– 自チーム:サポートに回る余裕
• サービスイン時
– 他チーム:古い設計書、後で直すとのこと
– 自チーム:30ページの仕様書、コードと同期

21. アジャイルパラレルの事例2
• 2-4名の保守案件
• 数ヶ月に1回機能追加、3-10人月程度
• 見積ミスが多発
– 想定していなかった既存パターン
– 要求事項の齟齬の発見
• 見積もり提示前にアジャイルパラレルを適用
– ソースをみて実装するため、想定していなかった既存
パターンを早期に発見
– 動かすために、他機能との連携などにも気付きやす
くなった
– 正確な見積もりからリスク回避が実現された

22. 最近の事例
• フルスタックエンジニアによる全員設計、実装、
テストは実現できていない
• オフショア開発、分散オフィスなどによる弊害
• ただし、常時開発、常時結合は常に実施
– マルチベンダー案件
• 他社に比べ重要な機能追加を柔軟に取り入れ、顧客
満足度アップ
– トラブルプロジェクトへリーダとして途中参加
• メンバーモチベーションアップ
• リカバリー期間を短縮、品質アップ

23. なぜ設計ファーストだったのか
• ライン生産方式
– 設計、実装、テストは分業
– プログラミングに専門スキルが必要
• C言語でソケットプログラムを作る VS Scalaで作る
– 設計スキルも必要
• 現代ほどシステムがあふれていないため、設計なども特別
なスキルが要求されていた。昔はスマホはなかった
– 単純なシステム、同様のシステム構築に向いていた
– 一度実装すると修正が大変
• 単独でテストできる環境がない、ビルドに30分など

24. 実装並列モデルが可能になった
• セル生産方式
– プログラミング、設計は簡易な学習で可能な時代
• 全員プログラマ、設計者、テスターになることができる
– どこでもすぐに試すことができる環境
• テストコードを統合環境で即時実行
• 試しながら実装し設計することで最短距離で進むこと
が可能
– 実装、テスト、リファクタリングが容易に行える環
境
• 大きな修正も比較的リスクなく実施可能

25. 気持ちの問題
• 設計だけ、実装だけは楽しいですか?
– 要件定義、設計にはやりがいがある
– プログラミングやテストは楽しい
– 新しいことを知る喜び
– 自分が作ったプログラムが動いている実感
• 発想の転換が必要
– 無駄なく効率よく作りたい --- BAD
– 無駄でも効率悪くても早期に作る --- GOOD

26. ディスカッション
• 5人程度のチームに分かれてください
• 20分程度、メリット、デメリット、障壁などをディ
スカッションしてください
• 発表内容は完結に付箋に書きましょう
• ディスカッション後に簡単なまとめをグループ
ごとに発表してもらう予定です

27. 最後に
• 実装並列モデルが完璧なわけではありませ
ん
• 単なる一つの手法であり、適用する環境や局
面、メンバーなどの状況によって効果は様々
• 皆様の引き出しに新たな手法が増えたのなら
とても嬉しいと思います