Tweet
Tweet

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. ブラウザで簡単に開けること