アジャイルとユースケース駆動開発を統合したプロセスを実践してみた

by AITC - DENTSU SOKEN

Slide 1

Slide 1 text

1 電通国際情報サービス（ISID） X（クロス）イノベーション本部 AIテクノロジー部 AIトランスフォーメーションセンター御手洗拓真アジャイル×ユースケース駆動開発を統合したプロセスを実践してみた

Slide 2

Slide 2 text

2 自己紹介所属：電通国際情報サービスクロスイノベーション本部 AIトランスフォーメーションセンター経歴： 2015年3月：大学卒業（学部 2015年4月：新卒でとあるSIerへ入社し、 Azureベースの機械学習システム導入案件を推進 2020年2月：ISIDへ中途入社現在は、顧客支援と並行してAIを使った自社サービス開発に尽力中業務：機械学習システム開発・導入、自社のAIソフトウェアの開発、主にAzureによるアーキテクチャ設計 Qiita : https://qiita.com/tamitarai 趣味：コーヒー、ウィスキーなど御手洗拓真

Slide 3

Slide 3 text

3 本日お話すること、しないことお話すること ➢我々がアジャイルに取り組んで直面した問題たち ➢試行錯誤してたどり着いたアジャイルと設計をきちんと両立するプロセスの紹介 ➢やってみた結果（良かったこと、残課題）の紹介お話しないこと ➢「そもそもアジャイルとは？」「ウォーターフォールと何が違う？」といった説明 ➢Azure DevOpsの細かい使い方（『アジャイルとスクラムによる開発手法』というがオスススメ） ➢プロセスで作成するドキュメントの書き方に関する詳細な説明

Slide 4

Slide 4 text

4 アジェンダプロセスを実践した結果とまとめ５：採用の宣伝６：プロセスの具体的な中身の説明４：アジャイル×ユースケース駆動設計のプロセス概要３：紹介するプロセスに至ったチームの背景と課題２：はじめに１：サービスの選定理由 Appendix：

Slide 5

Slide 5 text

5 はじめに 01

Slide 6

Slide 6 text

6 宣伝自分が所属する製品開発グループのメンバーと『アジャイルとスクラムによる開発手法: Azure DevOpsによるプロフェショナルスクラムの実践』という書籍を翻訳出版。Azure DevOpsを使うなら必読、それ以外の方にも良い本。 ◼ 基本的なコンセプト ➢ スクラムの原理原則だけではなく、実践的なプラクティスを押し付けない形で紹介している（意外と無い） ➢ Azure DevOpsの単なる使い方ではなく DevOpsへの批判も込みで「スクラムで使うならこうなら、ここをこう使え。これは使うな。」という内容を紹介 ◼ 学べる内容は、以下のとおり ➢ スクラムの実践的なプラクティスと取捨選択の基準と、体系と紐づけて理解できる ➢ Azure DevOpsのとても便利な使い方がよくわかる

Slide 7

Slide 7 text

7 自分たちでもやってみた結果かなり実践的な知識がありとても役に立った（だから翻訳した）。実際に多くのプラクティスを実践し、本日の発表にも一部含めている。一方で、現実には本のとおりにうまくいかない点もある

Slide 8

Slide 8 text

8 直面した問題たちチームの前提条件が揃っていない状態でスクラムに挑戦すると陥りがちな問題たち。 DevOps本を翻訳した我々も、漏れなく直面した。（※ このあと、個別に説明していきます）バックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況１２３

Slide 9

Slide 9 text

9 問題をプロセスで解決問題を解決するために試行錯誤してたどり着いたのが、アジャイル×ユースケース駆動開発のプロセスアジャイルユースケース駆動開発

Slide 10

Slide 10 text

10 紹介するプロセスに至ったチームの背景と課題 02

Slide 11

Slide 11 text

11 大事な前提この物語はフィクションである。全て、架空のAI製品開発チームのお話

Slide 12

Slide 12 text

12 開発チームの概要 • BtoB向けのAI製品を提供 • 半年に一度程度の頻度で新バージョンをリリース • 開発メンバーは、全て正社員（POを含めて7名） • メンバー全員がフロントエンド、バックエンド、 ML部分を担当 • 顧客やコンサルタントなどから、随時、機能の要望を頂ける

Slide 13

Slide 13 text

13 X年前の開発チームのざっくりした状況このような状況で、書籍にならってスクラムを実践しようとしていた PO 熱意はあるが比較的若手で、製品の方針を決めて推し進めるには権限が不足開発チーム（計6名） • スーパーエンジニア：２名 • 自律した開発者： 2名 • 若手（やや修行中）： 2名スクラムマスター実質的に不在当時のチーム構成（実際とはボカして書いてます）

Slide 14

Slide 14 text

14 書籍との違い書籍の前提現実の制約 PO 専任案件で6割以上稼働十分な権限開発する機能の決定にはPOの上司やマネジメント会議での合意が必要スクラムマスター専任不在（開発メンバーが兼任）開発チーム基本、自律して動けるエンジニア完全に自律して動けるのは2/3 良し悪しは別にして書籍で置かれている前提とは以下のような違いがあった

Slide 15

Slide 15 text

15 我々にあったもの • 一部の高い開発スキルを持ったメンバー • 開発メンバー全員の「製品を良くしたい」という強いモチベーション • 開発スキルに関わらずフラットで発言しやすいチームの雰囲気

Slide 16

Slide 16 text

16 生じていた問題たち以下のような問題がなかなか解消しなかったバックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題バックログの管理コストが高く、かつPOも専任ではなかったことから、メンテナンスされないまま数百も積み上げられ、どこからどう手をつけるべきか分からない状況とにかく動くものを作ることを優先していた結果、ドキュメントが断片的にしか存在しておらず、製品の全体像から細かい仕様まで開発メンバーに聞かないとわからない。上の二つから帰結するが、設計や実装方針などが整備されていないため、新規メンバーのキャッチアップコストがあまりにも高い概要

Slide 17

Slide 17 text

17 なぜ解消が難しかったのか？スクラムの条件を満たしていなかったため、スクラムの枠組みで解決が難しかったバックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題 • POがメンテナンスする時間を取れない • どうメンテナンスすべきか分からない • インクリメントの開発を優先しドキュメントを作成しなかった • 設計書や開発方針のドキュメントが無いため新メンバーがジョインしづらい原因 • 様々な前提が全て頭の中にあるため対話でカバーしきれない • POは6割以上案件で稼働 • 若手なためHowToがわからない • メンバーごとにスキル差が大きく、対話だけでは差を埋められない • 「必要」なタイミングを判断するスクラムマスターの不在現実 • POが責任をもってメンテナンスする • 自律した開発者が対話を繰り返して同期せよ • 必要に応じてドキュメントを作れ • 自律した開発者が対話を繰り返して同期せよ書籍の教え

Slide 18

Slide 18 text

18 書籍のスクラムを分解して再構成「PO」や「自律した開発者」に担われている責務を一度分解し、仕組みやチーム全体で吸収できるよう再構成し、プロセス化

Slide 19

Slide 19 text

19 アジャイル×ユースケース駆動設計のプロセス概要 03

Slide 20

Slide 20 text

20 基本の方針 ① プロセスを重たく or きっちりしすぎない手間がかって結局やりきれなかったり、キチキチで変更に対応できない状態は避ける ② メンテナンス性を考慮した最低限の設計をする「とりあえず動くものを作ってから考えよう！」という過激な現物主義は避ける ③ 新加入メンバーが頭を悩ませない開発体制これから成長していく若手が、進め方の面で迷子にならずに開発に入れて、比較的チームがスケールしやすい状況にしたかった。アジャイル×ユースケース定義のプロセスを考える際、念頭においた基本方針

Slide 21

Slide 21 text

21 作ったプロセスの全体像がこちら ※ このあと観点を絞って、もう少し説明

Slide 22

Slide 22 text

22 作ったプロセスの全体像がこちら ※ このあと観点を絞って、もう少し説明バックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するプロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者開発者激ゆるややゆるきっちりややゆる責任もつ人きっちり度

Slide 23

Slide 23 text

23 問題への打ち手とプロセスの対応関係 ※ 問題への効果については次のセクションで一つ一つ説明しますバックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するプロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者開発者責任もつ人

Slide 24

Slide 24 text

24 プロセスのおおまかな情報の流れ情報のおおまかな流れは以下のようなイメージ。このようなプロセスを次頁のようにアジャイルに回していく。 ※ 一つ一つのステップついては、この後で触れますゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するツール概要 Azure DevOpsの Boads Azure DevOpsの Boads Confluence Confluence 責任もつ人 PO PO 開発者開発者情報の流れ

Slide 25

Slide 25 text

25 アジャイルに回すとお気持ち＆要求分析要件定義＆設計日々のタスクチケット管理お気持ち＆要求分析要件定義＆設計日々のタスクチケット管理お気持ち＆要求分析要件定義＆設計日々のタスクチケット管理アジャイル開発イテレーション２イテレーション１イテレーション３ゆる秩序バックログ管理ゆる秩序バックログ管理ゆる秩序バックログ管理ゆる秩序バックログ管理ゆる秩序バックログ管理実際にはこんなに美しく回ってはいないが、イメージはこのような形気付いたらやる

Slide 26

Slide 26 text

26 アジャイルに回すとアイディアは顧客やコンサルから貰ったタイミングで貯めておいて忘れないように＆タイミングによって差し込み検討できるようにし、お気持ち＆要求分析要件定義＆設計日々のタスクチケット管理お気持ち＆要求分析要件定義＆設計日々のタスクチケット管理お気持ち＆要求分析要件定義＆設計日々のタスクチケット管理アジャイル開発イテレーション２イテレーション１イテレーション３気付いたらやるゆる秩序バックログ管理ゆる秩序バックログ管理ゆる秩序バックログ管理ゆる秩序バックログ管理ゆる秩序バックログ管理

Slide 27

Slide 27 text

27 アジャイルに回すと日々の開発では、イテレーションのなかでドキュメント作成ができるようプロセス化するお気持ち＆要求分析要件定義＆設計日々のタスクチケット管理お気持ち＆要求分析要件定義＆設計日々のタスクチケット管理お気持ち＆要求分析要件定義＆設計日々のタスクチケット管理アジャイル開発イテレーション２イテレーション１イテレーション３気付いたらやるゆる秩序バックログ管理ゆる秩序バックログ管理ゆる秩序バックログ管理ゆる秩序バックログ管理ゆる秩序バックログ管理

Slide 28

Slide 28 text

28 きっちりさのバランス「人間は集中してないとしっかりできない」という前提にたち、「片手間での作業になる可能性がある」ところは緩く整理し、明確な認識合わせが必要なところはきっちりと整理。ゆる秩序バックログ管理お気持ち＆要求分析要件定義＆設計日々のタスクチケット管理ツール Azure DevOpsの Boads Azure DevOpsの Boads Confluence Confluence きっちり度合い激ゆるややゆるきっちりややゆる PO PO 開発者開発者責任もつ人

Slide 29

Slide 29 text

29 全部部まとめるとバックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するプロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者開発者激ゆるややゆるきっちりややゆる責任もつ人きっちり度

Slide 30

Slide 30 text

30 プロセスの具体的な中身の説明プロセスを各ステップごとに解説します！ 04

Slide 31

Slide 31 text

31 バックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するプロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者開発者激ゆるややゆるきっちりややゆる責任もつ人きっちり度全体像の再掲

Slide 32

Slide 32 text

32 バックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するプロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者開発者激ゆるややゆるきっちりややゆる責任もつ人きっちり度ゆる秩序バックログ管理

Slide 33

Slide 33 text

33 ゆる秩序バックログ管理：概要頭を悩ませずに機能要望や新機能のアイディアを取っておくために、ゆるい秩序だけを維持して雑に放り込める場所を設ける。我々の場合はAzure DevOpsのBoadsを利用。

Slide 34

Slide 34 text

34 ゆる秩序バックログ管理：必要なわけ ⚫ 緩くしないと書かなくなる ➢ 「思いついたときに手軽に書ける」程度の軽さで置いとける場所がないと、「面倒だから後にしよう・・・」となり、流れてしまう。 ➢ 「バックログをちゃんと書く」ことを意識すると、意外と粒度や書きぶりなどで悩みが生じ、書かなくなる。 ⚫ 無秩序すぎると見返さなくなる ➢ とはいえあまりに無秩序になると誰も見返さなくなり、本当に「ただ存在しているだけ」になってしまう。以下の二点。

Slide 35

Slide 35 text

35 ゆる秩序バックログ管理のポイントポイント①：楽をするポイント②：順番づけは超ざっくりポイント③：とはいえ最低限の秩序はキープ

Slide 36

Slide 36 text

36 ポイント①：楽をするゆる秩序バックログに作るアイテムの中身は、あまり頑張って書かない。ただしタイトルだけは、最低限、読んで分かる内容にする • 受け入れ条件は、当然かかない。 • ユーザーストーリーも「〇〇が、××するために欲しい」という程度

Slide 37

Slide 37 text

37 ポイント②：順番づけは超ざっくりバックログの並び替えも、大まかに以下の３段階くらいにしておく。並び替える作業は思った以上に脳を使うため、真面目にやると破綻するから。バックログの３段階 ① 絶対に次回のリリースに入れる（ここだけはある程度は並び替えておく） ② 一年以内にリリースする ③ タイミングがあえばやりたいものたち

Slide 38

Slide 38 text

38 ポイント③：とはいえ最低限の秩序はキープとはいえ、油断すると無秩序になるため、以下のような軽めの工夫で、最低限の秩序を維持。大事なことは「いきなり重たいルールを作らず、できる範囲を見定める」こと。ただしタグを作りすぎると管理しきれなくなるので、「セットで実装するものないかな～？」を探すのに最低限なタグにするとよい。 30分/週のメンテナンスを定例化バグ、PBI、作業を一目で分かるようにする大きな機能分類用にタグを用意 POと開発者のうち一人が、最低週に30 分は定例でバックログを並び替える作業をする組織にもよるが、現在はバグ、PBI、 Work Itemの3種類を利用。分け方の観点は「クエリで抽出したい or 除外したい」のはどれか？と言う点。

Slide 39

Slide 39 text

39 バックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するプロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者開発者激ゆるややゆるきっちりややゆる責任もつ人きっちり度お気持ち＆要求分析

Slide 40

Slide 40 text

40 ⚫ 大きな機能分類ごとに要求がまとまっていないと、後から仕様を確認するためにチケットを掘り出すのがとてもしんどい（チケットが細かいと特に）。 ⚫ バックログだけを拠り所にした開発では、チケットを切る際にPOが粒度に頭を悩ませてしまう。それなら、軽量なフォーマットを定めて要求定義を書いてしまった方がはやい。お気持ち＆要求分析：必要なわけゆる秩序バックログ管理だけでは、以下が不足しているから

Slide 41

Slide 41 text

41 お気持ち＆要求分析：概要直近数カ月で開発する機能は、大きな機能単位でゆる管理バックログを集めて１ページ用意。そしてユーザーが「どういうお気持ちで」「どういう機能を求めているのか」を軽量なドキュメントとして整理する。複数のユーザーストーリーを、大きな機能で括って一ページに収めるイメージ。

Slide 42

Slide 42 text

42 お気持ち＆要求分析のポイントポイント①：お気持ちと機能の両方をかくポイント②：キッチリな構造化はしないポイント③：「あると嬉しい」ゾーンで柔軟性をとる

Slide 43

Slide 43 text

43 ポイント①：お気持ちと機能の両方をかく要求定義書として「お気持ち」と「要求事項」を両方とも記載することで、設計や実装で開発者がユーザーのお気持ちに共感して工夫できるようにするお気持ち要求事項なぜ必要？ユーザーの利用シーンとその気持ちに共感しながら、開発者が工夫して欲しいから開発者が開発すべき機能たちを明確にするため何を書く？「～したい」「～できると嬉しい」といったユーザーの気持ちや要望。ユーザーストーリーに近い。「～できること」という機能の要求。アジャイルの「受け入れ基準」と実質同じようなもの。具体例

Slide 44

Slide 44 text

44 ポイント②：キッチリな構造化はしない要求定義書を書くのは多忙なPOなので、きっちりした構造化は求めない。厳密な管理もしない。開発者が次のステップで要件定義に着手できればいい。

Slide 45

Slide 45 text

45 ポイント③：柔軟性を組み込む例えば、要求定義に「必須」ゾーンと「あると嬉しい」ゾーンを設けておくことで、ある程度の柔軟性を設けておく。

Slide 46

Slide 46 text

46 バックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するプロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者開発者激ゆるややゆるきっちりややゆる責任もつ人きっちり度要件定義＆設計

Slide 47

Slide 47 text

47 要件定義＆設計：必要なわけ「お気持ち＆要求分析」だけでは以下が不足しているから ① POや開発者間での作成物に関する認識あわせが空中戦になりがち ② コードと会話からこれまでの経緯や開発方針を理解する必要があり、新規メンバーの加入障壁があまりに高い ③ 要求定義書だけでは、具体的なシナリオが分からずヌケモレが発生しがち。一時的に会話で解消しても、行方不明になったりする。 ④ POとの対話をとても頻繁に行いながら実装する必要があり、コーディングに集中しづらく開発スピードが上がりづらいと、を両方かく

Slide 48

Slide 48 text

48 要件定義＆設計：概要開発において必要最小限となるドキュメントを作成する。製品開発チームの場合は試行錯誤の結果、以下のドキュメントを作成している。概念クラス図・ドメンモデル図に登場する各クラスの属性を記載する画面定義書・画面の紙芝居を作成し、画面上の項目を定義する・バックエンド開発時のヌケモレを減らすユースケース定義書・システムがユーザーに提供する機能をユースケースとして漏れなく洗い出し、図にまとめる・基本シナリオと代替シナリオをシステム利用ユーザーとシステムとの対話形式で記載する（細かいロジックは書かない。）ドメインモデル図・アクターがシステムで操作する「モノ」の概念と関係性をモデル化する。・チーム内で使う用語と、システムを使う業務の全体像の認識をあわせる。コンテキストモデル・アクター（システム利用者と、外部システム）を具体化する。・具体化することでユースケースの主語がブレなくなる。要件定義（POレビュー必須）設計（開発者内レビュー）

Slide 49

Slide 49 text

49 要件定義＆設計のポイントポイント①：POレビューをしっかり入れるポイント②：イテレーティブに作っていくポイント③：定義した言葉で頑張って喋る

Slide 50

Slide 50 text

50 ポイント①：POレビューをしっかり入れる特に要件定義系ドキュメントは「作るべきもの（What）」の正体を明らかにするためのもの。そのため、Whatに責務を持つPOからのレビューを必ず受ける。さらに、レビューは作成者が実際に声を出して読む方が効果が高いので推奨。概念クラス図・ドメンモデル図に登場する各クラスの属性を記載する画面定義書・画面の紙芝居を作成し、画面上の項目を定義する・バックエンド開発時のヌケモレを減らすユースケース定義書・システムがユーザーに提供する機能をユースケースとして漏れなく洗い出し、図にまとめる・基本シナリオと代替シナリオをシステム利用ユーザーとシステムとの対話形式で記載する（細かいロジックは書かない。）ドメインモデル図・アクターがシステムで操作する「モノ」の概念と関係性をモデル化する。・チーム内で使う用語と、システムを使う業務の全体像の認識をあわせる。コンテキストモデル・アクター（システム利用者と、外部システム）を具体化する。・具体化することでユースケースの主語がブレなくなる。 ↑ 要件定義（POレビュー必須）設計（開発者内レビュー）

Slide 51

Slide 51 text

51 ポイント②：イテレーティブに作っていく要件定義は、進めていくなかで様々なことが明らかになるプロセス。そのため、最初から完璧を目指すのではなく、「一歩進んでは戻って修正」を繰り返しながら作り上げていく。そこで、特に初回は2Hなどタイムボックスを設定して切り上げることを推奨。ユースケース定義書ドメインモデル図画面定義書コンテキストモデル初回の作成初回の作成初回の作成修正1 修正初回の作成修正2 時間の流れ

Slide 52

Slide 52 text

52 ポイント③：定義した言葉で頑張って喋るドキュメント化していても、人によって言葉の使い方が異なると致命的な認識齟齬が生まれることが本当に多い。（感想ですが特にAIシステムでは多いと感じています。学習と訓練や、テストとバリデーションなど。） POも含めて、普段の会話で使うワードもコンテキストモデルやドメインモデルで定義した言葉・概念に頑張ってそろえる。

Slide 53

Slide 53 text

53 （参考）ユースケース駆動開発実践ガイドここで紹介するドキュメントの具体的な作成方法については、最終的には『ユースケース駆動開発実践ガイド』を一読することを強く推奨 https://www.shoeisha.co.jp/book/detail/9784798114453

Slide 54

Slide 54 text

54 （参考）ユースケース駆動開発とはソフトウェア開発のための最小限のUMLモデリング手法紙芝居ユースケースモデルロバストネス図シーケンス図ドメインモデルクラス図実装コード単体テスト静的動的イテレーティブテスト計画 UMLを活用し、ユーザーのやりたいこと（ユースケース）からソフトウェアの実装コードにもっていくまでを最小限の成果物で目指す手法（UMLとは、記号と表記法やその意味が定義されたモデリングのための言語）

Slide 55

Slide 55 text

55 （参考）コンテキストモデル目的： • システムに関わるアクター（システム利用者と、外部システム）を具体化することで、自分たちが作るシステムの範囲を明確にし、この後のユースケースにおける主語がブレないようにする。書くこと • 開発するシステムを取りまくアクターとシステムとの関係。 ※ 具体的な書き方は専門の書籍をご参考ください

Slide 56

Slide 56 text

56 （参考）ドメインモデル図目的：以下について認識をあわせる • チームや関係者どうしで使う言葉の定義 • システムが実現する世界の全体像書くこと： • システムで扱う「モノ」の概念と関係性のモデル化。 • 関係性は、is-a関係（汎化）と、has-a関係（集約）だけにした方が良い。 • この時点ではフィールドは書かない。「モノ」だけを書く。 ※ 具体的な書き方は専門の書籍をご参考ください [引用元] ダグ・ローゼンバーグ, マットステファン『ユースケース駆動開発実践ガイド』P.44 図2.7

Slide 57

Slide 57 text

57 （参考）ユースケース定義書目的： • ユースケースのヌケモレを防ぐ。 • アクターがシステムを理由する際に、システムとユーザーがそれぞれどのような順番で相互作用するのかを明確にする。書くこと： • ユースケース図（上の画像）。ユースケースとアクターを漏れなく洗い出すことが大事。 • ユースケースのシナリオ（下の画像）。基本シナリオと代替シナリオを作成することが重要。 ※ 具体的な書き方は専門の書籍をご参考ください [引用元] ダグ・ローゼンバーグ, マットステファン『ユースケース駆動開発実践ガイド』P.72 図3.8 [引用元] ダグ・ローゼンバーグ, マットステファン『ユースケース駆動開発実践ガイド』P.89

Slide 58

Slide 58 text

58 （参考）画面定義書目的： • ユースケース定義書に書くと細かくなりすぎるUIに関して共通認識をもつ。書くこと： • 画面のワイヤーフレーム or 紙芝居。（画像の上部） • 画面の項目、UIの制約など（画像の下部） ※ 具体的な書き方は専門の書籍をご参考ください [引用元] 株式会社モンスターラボ「仕様書とは？開発事例をもとに成功する仕様書の書き方を解説」https://monstar-lab.com/dx/solution/howto-specification/

Slide 59

Slide 59 text

59 （参考）概念クラス図目的： • 開発者が、実際に実装するモデルについて認識あわせしやすくするために作成する。書くこと： • ドメインモデル図のタイトルを英語にして、さらにフィールドをクラス図の形で記載する。 • なお、使うフレームワークの制約によって、実際に実装するクラスとは必ずしも綺麗に一致しない点に注意。 ※ 具体的な書き方は専門の書籍をご参考ください [引用元]「 UMLによる概念モデリング入門」https://speakerdeck.com/hiroyazaki/umlniyorugai-nian- moderinguru-men-e380f33b-ed46-46fd-90d6-a35545ee9c63?slide=7

Slide 60

Slide 60 text

60 バックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するプロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者開発者激ゆるややゆるきっちりややゆる責任もつ人きっちり度日々の作業チケット管理

Slide 61

Slide 61 text

61 ⚫ 誰が何の作業をしているかの同期がしづらく、一つの機能に対してSwarm （複数人で一つのバックログに対応すること）で開発できない。 ⚫ 気軽に自分の作業をタスクに分解したり、他の人と分担したりしづらい。 ⚫ 逆に作業タスクにまでバックログを分解すると、細かすぎて管理不能になる日々の作業チケット管理：必要なわけ要件定義ドキュメントだけでは、以下が不足してるから。

Slide 62

Slide 62 text

62 日々の作業チケット管理：概要ユースケース定義書に記載した「ユースケース」単位で「プロダクトバックログ」を作成し、その子子供としてさらに細かい実装タスクである「Task」を切っていくプロダクトバックログ Task

Slide 63

Slide 63 text

63 日々の作業チケット管理のポイントポイント①：『アジャイルとスクラムによる開発手法』の６章を読む

Slide 64

Slide 64 text

64 『アジャイルとスクラムによる開発手法』の６章を読む読みましょう！

Slide 65

Slide 65 text

65 プロセスのステップたちバックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理日々、新たに産まれる「こういう機能欲しい」「ここ直したい」というバックログを緩い秩序で雑に溜める場所お気持ち＆要求分析バックログをインプットに、誰が、どういう時、どういう気持ちで、どういう機能を求めるか少しだけ整理して書く場所要件定義＆設計要求をもとに、ドメインモデル図やユースケース定義書など最低限必要なドキュメントを作成して整理する日々のタスクチケット管理要件をタスク分解してアジャイルに進めるために日々の作業を同期するポイントだけまとめ ① 楽をする ② 順番付けは超ざっくり ③ 最低限の秩序をキープ紹介したポイント ① お気持ちと機能を両方かく ② きっちりな構造化はしない ③ 「あると嬉しいゾーン」で柔軟に ① POレビューをしっかい入れる ② イテレーティブに作成する ① DevOps本の第6章を読む

Slide 66

Slide 66 text

66 やってみた結果とまとめ 05

Slide 67

Slide 67 text

67 問題に対してどうだったかそもそも解きたかった問題に対しては、一定の効果を実感できたバックログの管理がしきれない頭のなかだけにある詳細な製品仕様開発メンバーを増やしづらい状況問題ゆる秩序バックログ管理お気持ち＆要求分析要件定義＆設計日々のタスクチケット管理関係するプロセス問題に対する効果半分程度は解決。優先度が高いものについてはそれなりに並び替えが機能するようになった。ほぼ解決。要件と設計が可視化され、誰とでもすぐに共有でき、認識合わせが可能な状態となった。ほぼ解決。ドキュメントが理解できるレベルの開発者であれば１週間以内に完全に自律的判断でコーディングが可能になった。

Slide 68

Slide 68 text

68 想定外の良い効果問題への対処以外にも、いくつかのメリットが得られた • 開発の高速化 ➢ドキュメント作成に時間がかかりスピードが遅くなることを懸念していたが、実際には認識あわせの工数が大幅に減り、むしろ開発が高速化した • 負荷の平準化 ➢これまで一部のスーパーエンジニアの負荷が高い状況だったが、メンバーごとの負荷がかなり平準化された • コーディングスキルの向上 ➢要件定義や設計のスキルが強化されたことで、結果としてコーディングのスキルも強化されたという意見が得られた

Slide 69

Slide 69 text

69 残っている課題以下のような課題はまだ残っているため、継続的に改善を続けたい • 未整理の古いバックログ ➢過去の整理されていないバックログが、ざっくり優先度整理もされないまま、別のエリアに半分くらい放置されている。 • 要求分析は少し乱雑になりがち ➢要求分析は「手軽に書ける」ことをすこし優先しすぎて、リストがやや乱雑になっている嫌いがある。（それでも今までよりはだいぶ改善された） • 要求分析が開発に追いつかない状況 ➢開発がスピードアップしたことと、POが専任ではないことにより（POの責務自体は軽くなったが）要件定義や開発に、要求分析が追いつかないケースがある。そのため、一番最初認識あわせに時間を要している。

Slide 70

Slide 70 text

70 まとめ ⚫ スクラムに関する書籍を翻訳してスクラムに挑戦したが３つの問題に直面した ① バックログの管理がしきれない ② 頭のなかだけにある詳細な製品仕様 ③ 開発メンバーを増やしづらい ⚫ アジャイル×ユースケース駆動のプロセスで問題にアプローチし、以下のような結果に ① バックログの管理がしきれない→ 半分くらい解決 ② 頭のなかだけにある詳細な製品仕様 → ほぼ解決 ③ 開発メンバーを増やしづらい → ほぼ解決さらに副次効果として、開発効率化、負荷の平準化、コーディングスキル向上などが得られた ⚫ ただし、まだ以下の課題もあるので、継続的に改善していきたい ➢ 古いバックログがまだいくつか未整理 ➢ 要求分析ドキュメント内の要求事項がちょっと乱雑になりぎみ

Slide 71

Slide 71 text

71 最後に本日のお話は ”フィクション” ですが、我々、ISID AITC 製品開発グループもそっくりな問題に対し試行錯誤をし、日々、様々な活動に取り組んでいます。アップデートを続け、またこのような場で共有します！

Slide 72

Slide 72 text

72 中途採用の宣伝 06

Slide 73

Slide 73 text

73 ISID AITCでは新しい仲間を募集しています少しでも興味がある方は、是非、まずはカジュアルにお話しましょう！是非、気軽にカジュアル面談フォームからご応募ください！カジュアル面談フォーム https://forms.office.com/ r/a6NuyRU3t3

Slide 74

Slide 74 text

74 ISID AITCでは新しい仲間を募集していますまた、右側の職種への応募用ページからご応募頂いても大丈夫です。コンサルティング系 AIコンサルタント https://groupcareers.isid.c o.jp/pgisid/u/job.phtml?jo b_code=591&company_co de=1 AIビジネスプロジェクトマネージャー https://groupcareers.isid.c o.jp/pgisid/u/sp/job.phtml ?job_code=532 製品開発系 AIエンジニア（製品開発） https://groupcareers.isid.c o.jp/pgisid/u/job.phtml?jo b_code=647&company_co de=1 AIプロダクトマネージャー https://groupcareers.isid.c o.jp/pgisid/u/job.phtml?jo b_code=693&company_co de=1 職種ごと応募ページ

Slide 75

Slide 75 text

75 新卒採用もやってます ISIDでは、「データサイエンス職」という新卒応募枠をご用意しています。データサイエンス枠で合格された方は、AIトランスフォーメーションセンターへの配属が確約されます。興味がある方、是非ご応募ください。問い合わせ先：株式会社電通国際情報サービス人事部新卒採用・インターンシップ担当 [email protected]

Slide 76

Slide 76 text

76 AI製品開発グループ ISIDのAI製品開発グループでは、機械学習とアプリケーション開発両方の知識を活かしながら、 AI製品の研究開発を行っていますフロントエンドバックエンドコンテナ・仮想化クラウド&インフラ AI/ML アジャイル開発（スクラム）（AIスキルだけじゃない！） AI × IT × Biz AIはシステムの一部、フルスタックなIT実装力 UVP ・機械学習アルゴリズム・統計解析・機械学習工学・ディープラーニング・Webシステム構築・MLOps ・データ分析基盤構築・IoTシステム構築・PM、PdM ・デザイン思考（UX/UI）・ビジネスクリエーション（リーン, ジョブ理論, etc.）・業界や分野の専門知識 IT技術 Biz AI/データサイエンス

Slide 77

Slide 77 text

77 コンサルティンググループ顧客とのコミュニケーションを通じて、問題を実際に解ける課題にまで切り分ける • ヒアリング • 顧客業務の理解 • 問題の把握 • 解くべき課題の特定企画データを集めてAIモデルを構築し、切り分けた課題をAIで解けることを検証する • データ収集 • モデル作成 • モデル評価 • レポーティング PoC（概念検証）顧客内のAIリテラシーを高め、顧客内のAI活用文化醸成を支援する • レクチャー資料作成 • レクチャーの実施 • フィードバック教育実運時の課題を洗い出すためのプロトを構築し、業務適用を検討、検証する • 業務フローの作成 • プロト開発 • 顧客レクチャー • 仮運用時の課題整理プロト開発顧客業務に組み込むAIシステムの設計・開発・テストを実施。コンサルタントはPMとしてのアサインが多い • 要件定義 • 設計 • 開発・テスト • 運用システム開発 ISIDのAITC コンサルティンググループでは、顧客が抱える「AI/データをうまく活用できないだろうか」という課題を、「こうすればAI/データ分析で解決できる」という整理を行い、 AI/データ分析の社会実装/運用を実現しています

Slide 78

Slide 78 text

78 おわりご清聴ありがとうございました！

Slide 79

Slide 79 text

79 サービスの選定理由 Appendix

Slide 80

Slide 80 text

80 Azure DevOpsのBoards 以下の条件に当てはまったツールだったから。（他に当てはまっているツールがあればそれでもよいかも） 1. 動作がもっさりしていないこと 2. バックログと、その下にあるタスクという二つの階層でボードを構成できること（＝スウォームがしやすい構造になっていること） 3. Gitリポジトリとチケットが連携させられること 4. チームの進化に応じてチケットに柔軟にプロセスをカスタマイズしたり、カスタムのフィールドを増やせたりすること

Slide 81

Slide 81 text

81 Confluence 以下の条件にあてはまったツールだったから（ちなみにDevOpsのwikiは、No.4以外当てはまらなかった） 1. ドキュメント同士を、超簡単にリンクさせられること 2. ほとんどの操作がショートカットキーで行えること 3. ドキュメントのなかにdraw.ioなどのUML描画ツールを簡単に埋め込めること 4. ブラウザで簡単に開けること