1 電通国際情報サービス（ISID） X（クロス）イノベーション本部 AIテクノロジー部 AIトランスフォーメーションセンター AI製品開発グループ 福⽵裕昭 実践Azure DevOps 〜Azure DevOpsクイックツアーとBoardsを少々〜

2 はじめに 本セッションのねらい • Azure DevOpsに興味を持っていただく、参考になりそうな活⽤法やTIPSを⾒出していただく Ø広く浅く、Azure DevOpsの全体像と、実践で得た所感を共有します #Azure DevOpsを知らない⼈ #知ってて少し触ったことある⼈ #触ってるけど使い⽅に迷っている同⼠ #アジャイルに活動するチームのツールやプロセスに興味のある⼈ 参考になれば嬉しいですし、QAや議論のタネ、歓迎です！ （Live QAやTwitter、カジュアル⾯談）

3 しゃべるひと 所属： 電通国際情報サービス Xイノベーション本部 AIトランスフォーメーションセンター AI製品開発グループ 経歴： 社会⼈10年⽬くらい 2012年：学部卒（⽂学部 哲学倫理 国語の潜在教員 ） ユー⼦系SIer⼊社 (業務システム構築/クラウド基盤/画像AI) 2021年：ISID⼊社 業務： ジェネラリスト寄りのAI製品開発エンジニア ⾃社AIプロダクト開発(Python/Azure/Web/MLOps) 実装ときどきマネジメント(スクラムマスター) ユーザー教育⽀援や個別案件 備考： ・関⻄在住(メンバはほぼ全員東京) 福⽵裕昭 one of a translators...

4 アジェンダ 1) なぜAzure DevOps? 2) Azure DevOps クイックツアー 3) Azure Boards ピックアップ 4) 考察・まとめ

5 なぜAzure DevOps? 1)

6 私たち（AI製品開発グループ）について AI製品開発から顧客⽀援、研究開発活動まで • 継続的なAI製品開発を主なミッションとしつつ、 並⾏して中⻑期の研究開発活動や、 コンサルタントチームとの個別プロジェクト(受託分析/プロト開発) • 複数のMLプロジェクトが常に⾛っているチーム Øチームメンバーは製品開発で10名ほど、 コンサルタントチームも合わせる関係者は20名を超える 2022 2021 2020

7 アジャイルと私たち MLプロジェクトとアジャイルは隣り合わせ • 製品開発ふくめ、MLプロジェクトは素早い試⾏錯誤の中で、 継続的な価値提供が求められる傾向にある • つまり、MLプロジェクトを推進していると、 アジャイルなプロジェクト運営が求められてくる Ø実際、ウォーターフォール感覚のプロジェクト運営では、 不確実性への対処が無理筋であるように感じる(私⾒) • そんなアジャイルなプロセスを、 ツールセットから⽀えてくれるのがAzure DevOps CRISP-DM(Q) 2022年度⼈⼯知能学会インダストリアルセッション『CLISP- ML(Q)をはじめとしたMLシステムの品質確保に関する調査』より

8 • ⼀⾔で⾔えば、 アジャイルなソフトウェアインテグレーションを⾏う上で、 ライフサイクル上必要なサービスを全部乗せしたもの Ø複数のサービスが統合されいている 具体的にはタスク管理(Azure Boards)、リポジトリ(Azure Repos)、 CICDパイプライン(Azure Pipeline)などなど 全部乗せなので、始めやすく、広げやすい 全部乗せの、サービススイート Azure DevOpsとは？

9 なので、使いみちは⼯夫次第なのですが 誰が為のDevOps üアジャイルに活動するプロジェクト運営が増えてきたが、 ツールやプロセスがプロジェクトによってバラバラになりがち üスクラムで開発しているが、 アジャイル前提でないツールを⼯夫して運⽤している • こういったチームには特にお勧め MS製品やAzureを利⽤しているチームにもおすすめ(ユーザー管理はAzure AD) • 私たちも、プロジェクトが複線化したあたりから意識してAzure DevOpsを使⽤するようになった 本⽇のお話は、この活⽤知⾒がベース

10 • Azure DevOpsの展開にあたっては、 本書『アジャイルとスクラムによる開発⼿法』の知識も下敷きにしたうえで、 ⾃分たちなりの試⾏錯誤を重ねています Ø 本書(以降「⿊本」)だけがベースではなく、元々⾃⼰流でAzure DevOpsを使っていたところに、 書籍の知識に試⾏錯誤しています（⼀部メンバーは認定スクラムマスター(CSM)も取得済) • アジャイルなプロセスを実践する上で参考になる知⾒が詰まっています • スクラムをAzure DevOps(特にBoards)に落とし込みたい⽅には、 特に強くお勧めします 兼、宣伝 補⾜：実際に使った参考書

11 2) クイックツアー Azure DevOps

12 • Azure DevOpsの⼀通りのサービスを⾒ていきます。 • 合わせて私達が実際に各サービスをどう使っているか、 簡単な紹介と所感も交えてご紹介します ü Azure DevOps のユースケースの例として ü Azure DevOpsに興味を持つ最初の⼀歩として ü アジャイルに活動するチームのツールやプロセスを考える切っ掛けとして ※本⽇のお話は全てクラウド版のAzure DevOps Serviceのお話です ※Artifactsについては触れません(単体では少し説明しづらいので) メニューの上から下まで クイックツアー Azure DevOps

13 クイックツアー Azure DevOps 実際のメニュー画⾯を抜粋すると Wikiに情報を書いて Boardsでチームは⽇々のタスクを管理 Reposでソースコードは管理して Test Plansでシナリオテストをやって Pipelinesでデプロイ Organizationの下に各プロジェクト

14 • 各Projectsごとの情報の集約場所 • Dashboard Øプロジェクトの情報ポータルを作成できる • スプリントゴールやクエリの可視化グラフなどを Widgetとして配置できる • Wiki ØMarkdownベースのWikiを作成できる Dashboard・Wiki サービス紹介 画像はMS Learnから Azure DevOps でダッシュボードを追加、名前変更、削除する （https://learn.microsoft.com/ja-jp/azure/devops/report/dashboards/dashboards?view=azure- devops） ダッシュボード、グラフ、レポート、 & ウィジェットについて（https://learn.microsoft.com/ja- jp/azure/devops/report/dashboards/overview?view=azure-devops）

15 • プロジェクト管理ツール スクラム開発にネイティブ対応した バックログ管理が出来る • かんばんボードにも対応 Azure Boards Azure Boardsとは 画像はMS Learnから Azure Boardsとは （https://learn.microsoft.com/ja-jp/azure/devops/boards/get-started/what-is- azure-boards?view=azure-devops）

16 Azure Repos サービス紹介 • プロジェクトごとにGitリポジトリを作成できる ØプレーンなGitリポジトリ リポジトリそのものの使⽤感は 同様のサービスとほぼ変わりない Ø1プロジェクトに複数リポジトリ作成できる 画像はsmart hotelのサンプルプロジェクトから 以下で⽣成可能 (https://azuredevopsdemogenerator.azurewebsites.net/)

17 • テストの計画〜実⾏をサポートするサービス • テスト計画(Test Plans)と各シナリオ(Test Case)を テンプレート化し、Azure Boardsで扱えるタスクとして 繰り返し利⽤、管理できる Ø ⼿動テストの記録、⾃動テストの実施記録 どちらにも対応 • Test Plans関連ワークアイテムを管理するユーザーには 少し⾼額なBasic＋Testライセンスが必要 Azure Test Plans サービス紹介 画像はMS Learnから Azure Test Plans とは（https://learn.microsoft.com/ja-jp/azure/devops/test/overview?view=azure- devopsAzu）

18 • CI/CDパイプラインの実⾏管理 • 追加費⽤無しでCICD⽤のVM環境を 利⽤可能(1800分/⽉ 同時実⾏1まで) • job定義はyaml形式 Azure Pipelines サービス紹介

19 Azure DevOpsの使い分け（私たちの場合） 製品開発 時限プロジェクト 機能的な競合 Wiki プロジェクト情報 PJ横断Wiki プロジェクト情報 Confluence Notion Boards バックログ管理 タスク管理 Jira Repos ソースコード管理 ソースコード管理 GitHub Test Plans シナリオテスト管理 - Pipeline Test&Lint ビルド/デプロイ デプロイ GitHub Actions 常に全てを利⽤するわけではなく、ユースケース別に使い分けている 実際使ってみてどうか？

20 • Wikiを主に利⽤。 Ø プロジェクトごとの情報集約先にも利⽤しているが、 Organization横断の情報Wikiがメンバには好評 (Project知⾒を定期的に転記している) ○ 簡易な情報集約場所としてWikiは⾮常に便利 (Organizationにメンバーを集めていると展開しやすい) Ø ⽂書をリッチにしていくと、少し不⾜を感じることも △ Dashboardは決まった⽤途がないと陳腐化しがち Dashboard・Wiki 使い⼼地・所感

21 Azure Repos / Azure Pipelines 使い⼼地・所感 ソースコード管理を必要に応じReposで、 コードを継続的に利⽤する場合は、Azure Pipelineで テスト実⾏、ビルド、デプロイ ○ ReposはGitに慣れていれば違和感なく利⽤可 Ø commitにPBIのIDを含めることで、 簡単にバックログからリンクができる機能が好きです ◎ Reposを使っているなら、CICDはAzure Pipelinesで必要⼗分 △ GitHub Actionsに⽐べると参考情報が少ないのは⽟に瑕 △ 無償で利⽤できる範囲以上にジョブリソース(VM)を使いたい、 ⽤意されていないVMイメージを使いたい、などの幅が出てくると 要追加コスト

22 • 製品のシナリオテストの実施記録に利⽤中 ◎ テストの記録・可視化が容易 (元々Excelを使っていました…) △ 追加料⾦がかかる。WorkItemの構造も少し複雑 Ø シナリオ作成を⾏うユーザーは、 グレードの⾼いライセンスを有効にしている必要がある 興味を持ったは第7章『テスト駆動型計画』を御覧ください → Azure DevOpsオンライン Vol.7でも、 TFSUGさんがテーマとして取り上げています(おすすめ) Ø https://tfsug.connpass.com/event/262960/ Azure Test Plans 使い⼼地・所感

23 3) ピックアップ Azure Boards

24 • アジャイルなプロセスで⾏うタスク管理の要が、 Azure Boards ØAzure Boardsを使い込めると、 Azure DevOpsの良さをより享受できます 本パートで、少し深堀りします 私(達)のご贔屓 ピックアップ Azure Boards

25 • 私たちのチームでは、 [1]製品開発におけるプロジェクト管理 [2]個別プロジェクトのタスク管理 の両⽅で使⽤ • スクラム開発で最も効果を発揮するが、 アジャイルなサイクルで活動している 全てのチームにオススメ Azure Boards 使い⼼地・所感 参考画像：Azure Boardsとは （https://learn.microsoft.com/ja-jp/azure/devops/boards/get-started/what- is-azure-boards?view=azure-devops）

26 Azure Boards [2]ちょっとした個別プロジェクトのタスク管理 ＜ユースケースの例＞ • 3⼈で、数ヶ⽉くらいかけて、書籍の翻訳をしたい • 章やページごと、レビューごとにバックログを切った • 各個作業しつつ、 週1程度でBoardsを⾒ながらMTG 🥸今⽇はこれやるか… 例 メンバーの進⾏状況が 直感的にかんばんで 確認できる

27 Azure Boards [2]ちょっとした個別プロジェクトのタスク管理 より真価を発揮するのは、やっぱりスクラム その場合は、もっとスクラムイベントで 意識的にメンテする必要あり(⿊本参照) Taskboardsで 進⾏中のバックログを 細かいタスクに切って取り組む 🤨今⽇の進捗次第だけど、 あと数⽇かかりそうだな… • 個⼈で作業する時は、とりかかるバックログを決めて、 Taskboards画⾯で、数時間単位にタスクを切る • タスクが終わるまでの残り時間 (Remaining Works)をざっくり⼊れてみる。 • 実際に作業して 「思ったよりかかるな」「意外と早く終わるな」を ⽇々Remaining Worksに⼊れていく 意外と、これくらいの使い⽅でも便利 例

28 Azure Boards Azure Boardsの良いところ o バックログ、かんばんのリッチさ o Azure DevOps内のだいたい全ての情報と紐付けられる バックログの中で画像の貼り付けやDiscussionが可能 o データが溜まってくるとクエリが効果を発揮する o テンプレートで初期値やステータス遷移を設定できる。 その設定をOrganization間で共有できる o アジャイル・スクラムにネイティヴなつくり ⽤語やイベントを知っていると⾮常に使いやすい Ø ⼀部の例外を除き、メニュー名も全て スクラムの⽤語やイベントに対応している。 😗各章、残ってるバックログ何個だろう？ クエリして、State(状態)で⾒てみるか

29 Azure Boards Azure Boardsのとっつきづらいところ • メニュー項⽬の名称は英語表⽰のみで、 少しとっつきづらい。 Ø が、内容は⽇本語で書けるので、慣れると気にならなくなる Ø かんばん(Boards)は直感的なので、ここから使うのがおすすめ • バーンダウンチャートの出⼒などは、少しクセがある Ø Effort(⼯数)など、 追いかけたい指標をしっかり⽇次で記録できるよう、 意識してスプリントイベントを設定する必要あり • カスタマイズもできるが、ちょっと沼 Ø ステータス遷移やBoardsの項⽬を細かく定義できるが、やりすぎ ると運⽤がつらいくなる。Scrumプロセスを基本にむしろ⼊⼒項 ⽬を減らすのが吉（⿊本 3.3.1ご参考） 参考画像：スプリント バーンダウンの構成と監視（ https://learn.microsoft.com/ja- jp/azure/devops/report/dashboards/configure-sprint- burndown?view=azure-devops&tabs=remaining-work%2Cmay）

30 • 3rd partyで開発された拡張機能を追加できる Marketplaceが存在する Ø Organization単位で追加・管理 • あるとないとでは⽣産性が変わるレベルで良いものが、 結構あります。 Ø いっぽう、英語表記が基本である、更新が⽌まっているものが ある、といった難点はあり • ⾊々と試した中で、私たちが⽐較的よく使っているも のだけ、少し紹介します。 その他のTIPS：Extensionsの活⽤ 拡張機能を増やせます

31 • Azure Boards内のWork Itemを、 Excelから⼀括で操作できる ○ Excelで⼀気にコネコネしたい時に。 △ Mac版Excelは対応していない… • Work Itemの⼀括操作そのものはBoards > Backlogsでも結構頑張れるので(複数選択して右ク リック)、Excelが不可⽋なワークロードが無いなら意外 と使わないかも Extensions Azure DevOps Open in Excel 参考画像：Azure DevOps Open in Excel （https://marketplace.visualstudio.com/items?itemName=blueprint.vsts-open-work-items-in- excel） 開いた先のExcelで編集した 結果を反映できる

32 • プランニングポーカーがAzure DevOps上で実⾏できる ○ スプリントプランニングの時に使います。楽しいです。 • Sprint以外にQueryでも⾒積もり対象を選べるので、 スプリントプランニング意外の局⾯でも。 • あまり⼤量のWork Itemを選択すると、 パフォーマンスが落ちることもあり… Extensions Estimate 参考画像：Estimate （https://marketplace.visualstudio.com/items?itemName=ms-devlabs.estimate） ポーカーなので開くまでちゃんと 他の⼈のカードは⾒えない そのままバックログの項⽬ (Estimate)に反映できる

33 • Google Chrome拡張機能を⼊れることで、 画⾯の操作やバグの発⽣箇所を簡単にキャプチャし、 そのままBoardsのバックログとして起票できる • 製品テスト時のBugワークアイテムの起票に使っています Ø 画⾯キャプチャや状況についての記述など、 ⼈によってバラつきがちな部分をあるていど統⼀できます • UIは少しクセがあり、慣れが必要かも Extensions Test & Feedbacks Chome上で 画⾯キャプチャを取得 バックログ として起票 キャプチャとメモが⼊った バックログが起票される

34 考察・まとめ 4)

35 • アジャイルなプロジェクト運営に必要な⼀連のプロセスを Azure DevOpsはサポートしてくれる • チーム内(Organization)の中で Azure Boardsを上⼿く活⽤していくことで、 情報やプロセスが横展開しやすくなるメリットもあった Ø「あれどうやったの？」の拡がり • いっぽう、使い⽅を試⾏錯誤しているポイントもある 本セクションのまとめ Azure DevOpsを使うことの嬉しさ

36 • Organizationはなるべく1つで運⽤する • プロジェクト横断の情報検索、カスタマイズしたプロセス など、Organizationを共有しないと共有できません • 個⼈でAzure DevOpsを始めるとOrganizationを増 やしがち。早めに⼀本化してAzureサブスクリプション等 に紐付けたほうが良いです • 『Azure DevOps Migration Tool』でBoards周辺は 移⾏できますが、完全ではない Azure DevOpsを使う上での試⾏錯誤 [1] Organizationの管理

37 • Boardsが向かないプロジェクトには、 Boardsを選択しない Ø当たり前かもしれませんが… • 『決まった何かを決まった期間で集中的に作る』 のようなシチュエーションでは、 私たちもWBS(JiraやExcel)を使⽤することがあります • かんばんで無理に表現しようとすると、 逆にタスクの漏れや認識齟齬に繋がりかねないかも Azure DevOpsを使う上での試⾏錯誤 [2] Azure Boardsの使い所

38 • 本当に必要だと感じた時は、 個別特化のサービスも検討する • Azure DevOpsは優れたサービススイートですが、 個別サービスを他の特化型サービスと⽐較した場合、 機能的には他のサービスが優れる局⾯もあります Ø 実際、私たちもConfluenceやGitHub/GitHub Actionsを部分的に採⽤します • Azure DevOpsで過度に縛らず、 Boardsを情報ハブに、必要に応じたトッピングをするのが 現実解だと思っています Azure DevOpsを使う上での試⾏錯誤 [3] 特化型ツールの誘惑

39 まとめ 私たちの活動ライフサイクルにおける、Azure DevOpsの使われ⽅についてお話しました Ø#Azure DevOpsを知らない⼈ #少し触ったことある⼈ #触ってるけど使い⽅に迷っている同⼠ #アジャイルに活動するチームのツールやプロセスに興味のある⼈ • 参考になれば嬉しいですし、まだ知らないproven practiceを探す仲間や議論を、歓迎しています （Live QAやTwitter、カジュアル⾯談など） また読者が「ベストプラクティス」を探しているのであれば、本書や著者は適していません。 著者は「ベストプラクティス」という⾔葉を使⽤しません。 なぜなら「ベストプラクティス」という⾔葉からは、 （1）あらゆる組織で、あらゆるプロダクトに取り組む、あらゆるすべてのチームにとって、 このやり⽅が本当に「ベスト」であるという前提、および （2）そのベストプラクティスが⾒つかったら、 チームは探求したり実験したりするのをやめることができる、 といった誤解を与えるためです。 そこで著者は代わりに、 「有⽤性が証明された、実績のあるプラクティス（proven practice）」 という⾔葉を使⽤します。 (0.2 章 xvii より)

40 Appendix：中途採⽤の宣伝 0#

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

42 ISID AITCでは新しい仲間を募集しています 代表的な４つの職種については、以下に応募リンクのQRコードを掲載しております！ 製品開発系 コンサルティング系 AIコンサルタント https://groupcareers.isid.co.jp /pgisid/u/job.phtml?job_code =591&company_code=1 AIビジネスプロジェクトマネージャー https://groupcareers.isid.co.jp /pgisid/u/sp/job.phtml?job_c ode=532 AIエンジニア（製品開発） https://groupcareers.isid.co.jp /pgisid/u/job.phtml?job_code =647&company_code=1 AIプロダクトマネージャー https://groupcareers.isid.co.jp /pgisid/u/job.phtml?job_code =693&company_code=1

43 新卒採⽤もやってます ISIDでは、「データサイエンス職」という新卒応募枠をご⽤意しています。データサイエンス枠で合格された ⽅は、AIトランスフォーメーションセンターへの配属が確約されます。興味がある⽅、是⾮ご応募ください。 問い合わせ先： 株式会社 電通国際情報サービス ⼈事部 新卒採⽤・インターンシップ担当 public-fesh@isid.co.jp

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

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