アジャイルと形式手法

アジャイルと形式手法

1. 1. ライフロボティクス株式会社 川口 順央 アジャイルと形式手法 1 2017.04.13
2. 2. 自己紹介 2 はじめに 2004年から形式手法に興味を持ち、勉強と試行の繰り返し 個人レベルでは何度か現場に導入したことあり（Spin, Alloy, CSPなど） 川口 順央（かわぐち まさてる） @masateruk ライフロボティクス株式会社 CORO開発プロジェクト プロジェクトリーダー http://www.nikkan.co.jp/articles/view/00422414 日刊工業新聞より
3. 3. 適用プロジェクトの概要 3 はじめに スタートアップゆえにスピードが求められるが、 同時に品質も求められる 人の近くで動く協働ロボットCORO®の開発 プロジェクト全体をスクラムで回しつつ、仕様を形 式的仕様記述言語で記述する アジャイルと形式手法
4. 4. アジャイルと形式手法を両立する？ 4 はじめに イテレーティブでインクリメンタルな開発 は不確実性が高い状況ではとても有効 形式手法は数学を道具としてソフトウェア の品質を飛躍的に高められる アジャイルのいいところ 形式手法のいいところ “ドキュメントより動くソフトウェア”って言うけど 導入コストが高い？相性が良くない？
5. 5. 発表の構成 5 はじめに 形式的仕様記述の理由 より良い開発をめざして 自分たちの手法 はじめに
6. 6. 発表の構成 6 自分たちの手法 形式的仕様記述の理由 より良い開発をめざして 自分たちの手法 はじめに
7. 7. 自分たちの手法 ー プロジェクト全体の運用 7 自分たちの手法  スクラムを採用 スプリントは２週間 顧客の価値を表すユーザーストーリーをバックログに
8. 8. 仕様を書く 自分たちの手法 ー ユーザーストーリーの実現の仕方 8 自分たちの手法 テストケース をつくる ソースコード レビュー 不具合を 修正する テストを 実施する ユーザー ストーリー 仕様書 （形式的記述） 設計して 実装する プログラム テストケース 開発チーム QAチーム
9. 9. 自分たちの手法 ー 仕様の書き方 9 自分たちの手法  仕様は状態遷移モデルで記述する。遷移の構成要素は、 – 遷移元の状態、イベント（パラメータを含む）、ガード条件、事後条件、遷移先の状態  状態は変数をもつことができる。ガード条件、事後条件の記述を論理式と自然言語で書く。 論理式は、独自の仕様記述言語KMLで書く  独自の言語を作った理由 – 気に入ったものがなかった。VDMも候補だったが、補助関数については関数型プログラ ムのように書けるものがほしかった。
10. 10. KMLの記述例 10 自分たちの手法 // 例) ロボットの移動点の編集状態の状態遷移 state Edit@(移動点の編集状態) { var points : Point List = []; var index : Int = 0; invariant { // この状態で成り立つ不変条件 (length points != 0) => (0 <= index && index < length points); }@{ 点のリストが空でなければ、インデックスは0以上、 かつ、点のリスト長より小さい } transition addPoint(p : Point) when length points < 10 @[- 点のリストが10未満のとき -] --> { post { target points; points' = points ^ [p]; }@{- 事後の点のリストは、事前の点のリストの末尾に 点pを追加したもの -} } transition move when length points != 0 @[- 点のリストが空でないとき -] --> { post { state' = Moving(points); }@{- 移動状態へ遷移する -} } } state Moving@(再生状態)(ps : Point List) { … 異なる状態への遷移 ガード条件を持つ遷移 状態変数 不変条件 ※ 赤字で書いた部分は必須の注釈 注釈がない場合はコンパイルエラー
11. 11. KMLの記述例 ー 状態変数と不変条件 11 自分たちの手法 // 例) ロボットの移動点の編集状態の状態遷移. // でコメントが記述できます state Edit@(移動点の編集状態) { var points : Point List = []; var index : Int = 0; invariant { // この状態で成り立つ不変条件 (length points != 0) => (0 <= index && index < length points); }@{ 点のリストが空でなければ、インデックスは0以上、かつ、点のリスト長より小さい }
12. 12. KMLの記述例 ー 状態遷移 12 自分たちの手法 transition addPoint(p : Point) --> { when length points < 10 @[- 点のリストが10未満のとき -] --> { post { target points; points' = points ^ [p]; }@{- 事後の点のリストは、事前の点のリストの末尾に点pを追加したもの -} }
13. 13. 自分たちの手法 ー まとめ 13 自分たちの手法 スクラムを 採用 ユーザーストーリーをもとに 仕様を形式的に書く 仕様 を書いた後は、開発チームとQAチームは並行に作業する
14. 14. 発表の構成 14 形式的仕様記述の理由 形式的仕様記述の理由 より良い開発をめざして 自分たちの手法 はじめに
15. 15. ”ドキュメントよりも動くソフトウェア”の理由 15 形式的仕様記述の理由  すでに終わった作業についての単なる文書化（創造的な活動ではない）  編集環境が気に入らない。WordやExcelが嫌いだ  意味のわからないフォーマットや体裁に従わないといけない  書いたドキュメントを誰も使わない。用途が不明 かけた 時間に対して効果が少ない。費用対効果が悪い  楽しくない こんな文書化は嫌われる まとめると
16. 16. 本来ドキュメントがもつ力 16 形式的仕様記述の理由  頭の中で何となく考えていたものが明確 になる  考えが足りなかったことに気づく  間違いを発見できる  人にレビューしてもらえる  あとで読み返すことができる 考えをアウトプットさせられる 書いたものが手に入る
17. 17. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 17 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものが明確 になる  考えが足りなかったことに気づく  間違いを発見できる  人にレビューしてもらえる あとで 読み返すことができる
18. 18. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 18 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものが明確 になる  考えが足りなかったことに気づく  間違いを発見できる  人にレビューしてもらえる  あとで読み返すことができる
19. 19. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 19 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものを厳密 にアウトプットさせられるため、より明 確になる  考えが足りなかったことに気づく  間違いを発見できる  人にレビューしてもらえる  あとで読み返すことができる
20. 20. 形式的に仕様を書くとより明確になる 20 形式的仕様記述の理由 # 移動点に点 p を追加したとき 移動点のリストに点 p を追加する 自然言語だけで書いた仕様 transition addPoint(p : Point) --> { post { target points; points' = points ^ [p]; }@{- 事後の点のリストは、事前の点のリストの末尾に点pを追加したもの -} } KMLで書いた仕様 挿入？末尾に追加？先頭に追加？ 末尾に追加することが明確
21. 21. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 21 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものを厳密 にアウトプットさせられるため、より明 確になる  考えが足りなかったことに気づく  間違いを発見できる  人にレビューしてもらえる  あとで読み返すことができる
22. 22. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 22 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものを厳密 にアウトプットさせられるため、より明 確になる 未定義 な言葉で説明したつもりの文章は 書けないため、考慮不足をごまかせない 間違 いを発見できる  人にレビューしてもらえる  あとで読み返すことができる
23. 23. 形式的に仕様を書くと未定義な言葉でごまかせない 23 形式的仕様記述の理由 # 移動点に削除操作したとき インデックスに対応した点を削除する 自然言語だけで書いた仕様 transition deletePoint when length points != 0 @[- 点のリストが空でないとき -] --> { post { target points, index; points' = [ points # i | i : Int & 0 <= i && i < length points && i != index ]; index' = if index + 1 = length points then max(index – 1, 0) else index; }@{- 事後の点のリストは、事前の点のリストからindex番目を除いたもの インデックスは末尾を指していた場合は1つ小さい値と0の最大値、そうでなければ変わらない -} } KMLで書いた仕様 未定義になりやすい言葉  ○○に対応した  ○○に応じた  ○○に一致する
24. 24. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 24 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものを厳密 にアウトプットさせられるため、より明 確になる 未定義 な言葉で説明したつもりの文章は 書けないため、考慮不足をごまかせない 間違 いを発見できる  人にレビューしてもらえる あとで 読み返すことができる
25. 25. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 25 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものを厳密 にアウトプットさせられるため、より明 確になる  未定義な言葉で説明したつもりの文章は 書けないため、考慮不足をごまかせない  ツールの力で間違いを発見できる  人にレビューしてもらえる あとで 読み返すことができる
26. 26. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 26 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものを厳密 にアウトプットさせられるため、より明 確になる  未定義な言葉で説明したつもりの文章は 書けないため、考慮不足をごまかせない  ツールの力で間違いを発見できる  人にレビューしてもらえる  あとで読み返すことができる
27. 27. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 27 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものを厳密 にアウトプットさせられるため、より明 確になる 未定義 な言葉で説明したつもりの文章は 書けないため、考慮不足をごまかせない ツール の力で間違いを発見できる  レビューアが間違いかそうでないか 判断を正確にできる  あとで読み返すことができる
28. 28. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 28 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものを厳密 にアウトプットさせられるため、より明 確になる  未定義な言葉で説明したつもりの文章は 書けないため、考慮不足をごまかせない  ツールの力で間違いを発見できる レビューアが 間違いかそうでないか 判断を正確にできる あとで 読み返すことができる
29. 29. 形式的記述は、本来ドキュメントがもつ力を最大限に引き出す 29 形式的仕様記述の理由 考えをアウトプットさせられる 書いたものが手に入る  頭の中で何となく考えていたものを厳密 にアウトプットさせられるため、より明 確になる  未定義な言葉で説明したつもりの文章は 書けないため、考慮不足をごまかせない  ツールの力で間違いを発見できる  レビューアが間違いかそうでないか 判断を正確にできる  曖昧さがない。そのため解釈が多様 にならない
30. 30. 費用対効果の点でおいしい形式的仕様記述 #1 30 形式的仕様記述の理由 仕様 をすべてのはじまりにすることで仕様の利用頻度（参照回数）が多くなる 開発者– が設計をするとき QA– がテストケースをつくるとき バグっぽい– 動きを見つけた時に、仕様かバグかを判断するとき 仕様変更– をうけたときに今の仕様を確認するとき – 問い合わせをうけたときに仕様を確認するとき マニュアルをかくとき–
31. 31. 費用対効果の点でおいしい形式的仕様記述 #2 31 形式的仕様記述の理由  仕様を形式的に書くことで得られるおいしさ – 形式的に書くと、たくさんの間違いや考慮漏れに気づく – コードを書く前に気づくことができる。 Fail Fastを仕様で実現する  意思決定がはやくなる。何をやるべきか明確になる – 仕様に違反した実装であれば、バグなのでプログラムを修正する – 仕様が妥当（望ましいもの）でなければ、仕様変更を検討する
32. 32. 効果が見えて楽しいのが継続のカギ 32 形式的仕様記述の理由 自然言語✓ で書かれると読む人によって解釈が多様になるけど、論理式だと曖昧さがない 日本語✓ と併記している仕様を見ると、日本語の不明瞭さがよくわかる 齟齬✓ が生じにくいのでコミュニケーションが取りやすかった 仕様✓ の漏れに気づきやすい ✓ 書いていて楽しいKML メンバーの感想
33. 33. 発表の構成 33 より良い開発をめざして 形式的仕様記述の理由 より良い開発をめざして 自分たちの手法 はじめに
34. 34. ソフトウェアの開発は段階的詳細化 34 より良い開発をめざして  どの程度段階を踏むのか、それぞれのモデルを書く、書かない、などさまざまな選択肢があ るが、すべての開発で陽に陰に行なっている  モデルを記述することには効果がある。問題は費用対効果である  対象を抽象的に記述したり、書いたものを分析する技術が向上すれば費用は抑えられる 低高 抽象度 仕様 プログラム
35. 35. 形式手法を通して得る抽象化能力 35 より良い開発をめざして 数理論理学 をベースとしている。数学は抽象的な記述に向いている 詳細化関係 など形式的な定義を理解することで得られる自分の作業のより明解な理解と認識 たとえ– 非形式的に作業を行うとしても形式的な定義に照らし合わせると自分が何をやっ ているのかを明確に認識できる – 何を行なって、何を行わないかを意識的に選択することができる 記述 したモデルの分析と検証が計算機で可能。検証を正確に、網羅的に、高速に行える  使っているうちに検証能力がいつの間にか身につく
36. 36. スモールスタートで初期コストを抑える 36 より良い開発をめざして まずは 仕様記述から始める ハードルが– 高い形式的な検証や分析は最初はあきらめる 初学者 は読むことから – 書くより読むほうが易しい 自然言語– を併記すればなんとなく読めるという状況をつくる ある– 程度読む期間を経て記述に慣れてきたら書くことに挑戦する わからないことは 経験者にすぐに聞ける環境が望ましい
37. 37. より良い開発手法への挑戦 37 より良い開発をめざして アジャイルや 形式手法に限らず、開発をよりよくする技術であれば挑戦したい いつか– 暇になったら、というときは永遠に訪れない 普段– の開発をしながら自分たちを高めていく – 新しい技術への挑戦を当たり前のことにしたい アジャイルも 形式手法もまだまだ道半ば
38. 38. 本質的な問題に注力するために 38 より良い開発をめざして 最近 スケジュールが優先され品質が軽視される傾向があるが、実際に求められているのは品質の 高い製品を早く届けること 品質 を犠牲にしてスピードを求める人たちは、いつまでたっても品質の高いものを速く作れるよ うになれない 品質 の高いものをつくる技術を持った人たちが訓練を重ねれば、速く作れるようになれる 自分たちを訓練して当たり前のように品質の高い製品が作れるようになれば、 ユーザにとっての価値は何か？とか、使い勝手とか、より本質的な問題に注力 することができるようになる
39. 39. 発表の構成 39 より良い開発をめざして 形式的仕様記述の理由 より良い開発をめざして 自分たちの手法 はじめに
40. 40. まとめ 40 まとめ アジャイルと 形式手法のいいとこ取りはできる 仕様 を形式的に書いてドキュメントの費用対効果を高める 開発 をより良くするために日常の中で新しい技術に挑戦する
41. 41. 発表の構成 41 はじめに 形式的仕様記述の理由 より良い開発をめざして 自分たちの手法 はじめに