試験に役⽴つモデリングの紹介サイボウズ 株式会社渡邉 豊幹
View Slide
渡邉 豊幹⾃⼰紹介2011年新卒⼊社、QA現在は販売管理システムを担当サイボウズ株式会社開発本部
中⼩企業向けグループウェア⼤企業向けグループウェア業務アプリ構築クラウドメール共有システム製品紹介
• モデルを作成し、試験に活⽤した話• メリットと作成時のポイントお話しすること
アジェンダ担当プロダクト/チームの紹介と抱えていた問題実施した解決策「モデルセットを作成する」作成時のポイントとコストについて今後の展望
担当プロダクト• ⽶国市場向けの販売管理システム• ユーザー1. 製品のエンドユーザー• 試⽤申し込みや契約 など2. 社内のセールスチーム• 特別価格での発注やライセンス管理、キャンペーンの設定 などൢചཧγεςϜ֎෦αʔϏεEnd User Sales Team
チームの紹介チーム構成開発スタイル状況
チームの紹介チーム構成開発スタイル状況• 開発チームは6名（うち QAは3⼈）• セキュリティ検証は社内専⾨チームに依頼QA
チームの紹介チーム構成開発スタイル状況• スクラム開発（1スプリント1週間）• リリース頻度は約2回/週試験後にQA がリリース
チームの紹介チーム構成開発スタイル状況実装前に全て設計することや、内部の詳細なドキュメントを作成することはせず、段階的に開発を⾏いリリースしている事前に全てを設計しない
チームの紹介開発スタイル状況1. 開発が進むにつれて処理が複雑になる2. 各機能の仕様書はあるが、全体像を把握できるドキュメントが無いチーム構成 個々の機能仕様書はあるけど…
開発上の問題点試験の影響範囲が把握しにくい新規メンバー/他チームへの教育コストが⾼い
開発上の問題点試験の影響範囲が把握しにくい新規メンバー/他チームへの教育コストが⾼い連携している外部サービスとのシステム境界が複雑になり、試験設計の難易度が上がる
開発上の問題点試験の影響範囲が把握しにくい新規メンバー/他チームへの教育コストが⾼い個々の機能の詳細な仕様書はあるが、全体像を把握するための資料が無い
開発上の問題点試験の影響範囲が把握しにくい新規メンバー/他チームへの教育コストが⾼い基本的なケースのモデルを作成して解決できないか
なぜモデルが必要?ひも?• ⽂書よりイメージの⽅が概要をうまく掴める• 細かい点だけに着⽬すると全体像を掴みにくいかべ?
モデルに着⽬したきっかけ平鍋健児さんを招いて開催された社内勉強会• アジャイルにおいて必要⼗分な設計とは？• ⼀貫性を保って開発するには？• 効果的な対話のために必要なものは？→ シンプルなモデルセット(Keeps)を作成する、というアイディアを知るKeeps!
Keeps?モデルモデルとして残すもの・安定している・寿命が⻑いKeeps残さないもの・実装中に変わる・⼀度共有して捨てるTemps
Keeps?モデルモデルとして残すもの・安定している・寿命が⻑いKeeps残さないもの・実装中に変わる・⼀度共有して捨てるTemps共通理解を促すシンプルなモデルセット
作成したKeepsの紹介Keepsシステム全体の構造を表すものArchitecture業務で扱う対象とそれらの繋がりを表したものDomain Modelユーザーから⾒たシステムの代表的な使い⽅Key Use Cases
作成したKeepsの紹介Keepsシステム全体の構造を表すものArchitecture業務で扱う対象とそれらの繋がりを表したものDomain Modelユーザーから⾒たシステムの代表的な使い⽅Key Use Casesユースケース図コミュニケーション図
ユースケース図※⼀部秘密情報のため、実際の表現を変えています
ユースケース図特定の操作の影響範囲がわかる※⼀部秘密情報のため、実際の表現を変えています
コミュニケーション図渡されるデータや実⾏ API を記載※⼀部秘密情報のため、実際の表現を変えています
改善できた点試験の影響範囲が把握しにくい新規メンバー/他チームへの教育コストが⾼い
改善できた点試験の影響範囲が把握しにくい新規メンバー/他チームへの教育コストが⾼い1. 連携サービスとの境界や、サービスが実⾏されるタイミングが分かりやすくなった2. 仕様書では細かい挙動に注⽬しがちだが、俯瞰して影響範囲を⾒ることができる
改善できた点試験の影響範囲が把握しにくい新規メンバー/他チームへの教育コストが⾼い1. システム全体で各ユーザーがどのような操作を⾏うのか、俯瞰して⾒ることができる2. 各ユースケースごとのシステムの振る舞いについても概要が把握しやすい
改善できた点試験の影響範囲が把握しにくい新規メンバー/他チームへの教育コストが⾼いその他1. モニタリング対象の API を洗い出す際に活⽤2. E2E のテストの改善で活⽤
作成時のポイント⽬的を明確にするチーム内で合意をとるツールを活⽤する
作成時のポイント⽬的を明確にするチーム内で合意をとるツールを活⽤する1. スコープを明確にし、作りすぎを防ぐ2. 作成するケースを最⼩限に抑えるゴール
作成時のポイント⽬的を明確にするチーム内で合意をとるツールを活⽤する1. メンテナンスコスト含めて検討する2. 更新すべき情報について共有する協⼒が不可⽋
作成時のポイント⽬的を明確にするチーム内で合意をとるツールを活⽤するPlantUML を使⽤し作成コストを抑えた
作成時のポイント1. 誰でも同じような図を作成できる2. コードなので git でバージョン管理できる⾒た⽬の微調整が難しいが、厳密な表現より概要を把握できることを優先して使⽤PlantUMLコードで UML を作成するツール
メンテナンスについてルール作成コストメンテナンスコスト
メンテナンスについてルール作成コストメンテナンスコスト• 開発時（仕様変更時）に PG/QA が修正• 上記ルールは他の機能仕様書などと同様既存のプロセスに合わせる形で開始
メンテナンスについてルール作成コストメンテナンスコスト• 10⼈⽇程度• 計11枚の図と説明を作成クラス図 ×1オブジェクト図×1ER図×1コミュニケーション図×1ユースケース図×7
メンテナンスについてルール作成コストメンテナンスコスト• 2020年6⽉の運⽤開始後、誤りを⼀度修正• 仕様変更による修正はまだ無し
今後の展望チーム内⽤語を記載ADR の記載
今後の展望チーム内⽤語を記載ADR の記載チーム特有の⽤語を定義し記載することで認識に齟齬が⽣じることを防ぐ
今後の展望チーム内⽤語を記載ADR の記載Architecture Decision Records と呼ばれる、アーキテクチャ上重要な意思決定の背景を記載し、暗黙知が増えることを防ぐ
まとめ• 下記問題を解決するために Keeps を作成した• 試験の影響範囲が把握しにくい• 新規メンバー/他チームの教育コストが⾼い• 作成ポイント• ⽬的を明確にする• チーム内で作成について合意をとる• 楽に作成できるツールを活⽤する• メンテナンスのルールを決める• 今後の展望• ⽤語の定義と ADR を記載する
参考情報• 平鍋健児さんの資料「 Modeling in the Agile Age」https://www.slideshare.net/hiranabe/modeling-in-the-agile-age-228224347• PlantUMLhttps://plantuml.com/
cybozuinsideout
kochizufan
ama_ch
miu_crescent
keio_smilab
makotu
oracle4engineer
moriyuya
konifar
claudioed
.png){kind=icon}
3playmarketing
soracom
koudaiii
chrislema
lauravandoore
colly
iamctodd
chrisshort
malarkey
lynnandtonic
searls
akosma
phodgson
panda_program