SIerで自然言語処理AI製品をアジャイル開発した際の試行錯誤_200704
- 2. 「 Machine Learning 15minutes! 」の発表時間って何分ですか?
その名の通り、15分ですね!!
なんと! スライド40枚、50分くらいになっちゃいました「ML 50minutes! 」です ・・・
ということで、本日15分では、重要なポイントのみお話させていただきます!!
(そして、本スライドは全公開いたします)
2
- 6. 6
小川 雄太郎 所属:電通国際情報サービス クロスイノベーション本部 AIテクノロジー部
業務:深層強化学習、DL解釈性などのAI案件、自社AIソフトの開発リーダ、
研究開発&学会発表、外部講演・登壇など
兼職:早稲田大学 非常勤講師、日本ディープラーニング協会 委員
詳細:https://github.com/YutaroOgawa/about_me
Twitter:https://twitter.com/ISID_AI_team
出版: PyTorchによる発展ディープラーニング、深層強化学習、機械学習入門、因果分析
[1] 自己紹介
- 15. 15
https://www.amazon.co.jp/dp/4822286584/
書籍「More Effective Agile ~“ソフトウェアリーダー”になるための28の道標」より。
平均的チームにおいて、スクラム要素8つの各達成度は5点満点の何点でしょう?
※健全なチームの場合は全項目が3.5点以上
1. スプリントプランニング [?点]
2. スプリントバックログ [?点]
3. プロダクトバックログ・リファインメント [?点]
4. デイリースクラム [?点]
5. スプリントレトロスペクティブ [?点]
6. プロダクトオーナー [?点]
7. スクラムマスター [?点]
8. 機能横断かつ自己管理できる開発チーム [?点]
[3] アジャイル開発_苦労点と解決例
- 17. 17
[3] アジャイル開発_苦労点と解決例
1. スプリントプランニング
1.1 全体のフェーズ分け(4カ月を以下のように分割)
1.2 スプリントの長さ(発表では解説は省略)
プロダクト骨子
作成期間(1カ月)
ガチ開発期間
(2カ月)
エンドゲーム≒
品質検証(1カ月)
【工夫6】骨子作成期間を最初に設け、製品のMVPを作成。この期間はモブプロにし、メンバ全員の技術知識・スキルを標準化
【工夫7】品質向上&検証のために、エンドゲームと呼ばれる、品質検証フェーズ(Verification)を導入
【工夫8】スクラムにおいて1スプリントの長さは、基本的に2週間が多いが、今回は1週間で設定
●利点:スクラムの開発サイクルに慣れ、スクラム習熟が早かった
●欠点:1週間で実施するので、スプリントバックログの重さを定めるポイント制度(プランニング・ポーカー等)の概念が
皆無。スプリントバックログもすべて。どうにか1週間でできる小ささまでを分割し、かつ受け入れテストを設定。
POの負担は絶するものがあった(ので、PO補助の人員を置いた。PO系は後述)
- 18. 18
[3] アジャイル開発_苦労点と解決例
2. スプリントバックログ(発表では解説は省略)
2.1 ユーザーストーリーマッピング
(1) どんな属性のユーザが、本ソフトを、どんなときに、どう使用するのかシナリオ文書作成
(2) シナリオを、ユーザーストーリーマッピングに落とし込む
(3) 製品受け入れシナリオテストとそのテストのためのテストデータを作成
【工夫9】アジャイルでの品質確保は難しい(後述)。ウォーターフォールでの
受け入れテストに対応するシナリオテストと、使用する訓練・推論データを最初に用意する。
とくにAI製品は使用するデータに強く依存するので、開発開始時に、
どんなデータに対応させたいのか?、デモ用データの準備は最初にやっておくのが良い。
(例)今回、開発チームは教師ラベルは第1列に入っているという前提でいたが、可変設定だった(>_<)・・・
https://miro.com/app/
- 19. 19
[3] アジャイル開発_苦労点と解決例
2. スプリントバックログ(発表では解説は省略)
2.2 プロダクトバックログにおけるユーザーストーリーの書き方
【工夫10】一般的なテンプレートのユーザーストーリーは使いにくい(と私は感じている)。ジョブ理論を取り入れたい。
動詞ではなく、名詞に焦点を当てて記載する。基本テンプレートの「〇〇をしたい」という表現は動詞的。動詞に焦点を当て
ると、手順書や、ウォーターフォールの設計書、仕様書のようになりがち。要件や仕様を書くのではなく、あくまで要求を書
く。名詞( ≒ ユーザが得られる成果 )に焦点を当て、ユーザが得る価値・成果についてストーリーをチケット化する。
●定番テンプレート:「<ユーザーの種類>として、<達成したいゴール>をしたい。なぜなら<理由>だからだ。」
●改変テンプレート:「<ユーザーのデモグラ&製品内でのユーザ権限>として、<解決したい困りごと≒JTBD>という
ビジネス課題があり、それを解決するために、<成果(名詞で記述)>を得たい。」
【工夫11】受け入れテストの記述が甘いと品質が担保できない。しかし、丁寧に受け入れテストの手順を書いていると、POの
仕事が終わらない。よって、画面イメージ図を手書きで良いので書いて、画面内の入力欄には入力候補(境界値含む)を書い
た紙芝居を用意し、チケットの受け入れテストを記載。画面イメージ図を渡されると実装側も楽である。そして画面イメージ
はUXに直結するので、POがきちんと開発チームに伝えるべき。
(もちろん、非機能要件などのいわゆる完成定義は別途通常通り。あくまでストーリー部分の実現性テストの話)
- 20. 20
[3] アジャイル開発_苦労点と解決例
2. スプリントバックログ(発表では解説は省略)
2.3 プロダクトバックログの状態
【工夫12】一般的にプロダクトバックログの状態は「New(新規作成)」、「Approved(仕掛中)」、「Committed(開
発済)」、「Done(受け入れ完了済)」の4状態。
だが、開発を終えたが、受け入れでリジェクトされたチケットを、 「Approved(仕掛中)」にすると、これから開発する
「Approved (仕掛中) 」チケットと、残タスクの時間がかなり違うので、スプリント計画時に分かりづらい。
かといって、受け入れ失敗に対して、新しいチケットを作るのも変な感じがする。
プロダクトバックログの状態に「受け入れ失敗改善中」という状態を追加しておくと、把握しやすい。
(とくに1週間スプリントだと、受け入れ失敗状態のタスクが多い)
結果、「New(新規作成)」、「Approved(仕掛中)」、「Committed(開発済)」、「受け入れ失敗改善中」、
「Done(受け入れ完了済)」の5状態。
- 22. 22
[3] アジャイル開発_苦労点と解決例
4. デイリースクラム
4.1 定番の方法から変化させる
通常のデイリースクラムは、「昨日やったこと」、「今日やること」、「障害となっていること」を発表しますが、これを変
更しました。定番デイリースクラムの内容はチケットの状況見ればだいたい分かるし、楽しくない(と感じます)。
そして楽しくない行為は続かないです。
【工夫13】デイリースクラムではYWT-Pを利用。「Y:昨日やったこと」、「W:昨日分かったこと、理解し学んだこと」、
「T:今日やること」、「P:問題かも?もやっ~と気になること」を、各自、まずTeamsに5分で記入し、その後発表する。
一度、文字で書き下すことで頭が整理され、発表しやすい。また、毎日書き下したYWT-Pの記録は、スプリント終わりのレト
ロスペクティブの材料になる。
「W:昨日分かったこと、理解し学んだこと」を記載することで、各人が毎日の自分の成長を感じられ、チームの活性化へと
つながる(メンバのWが、中期間に渡って微妙な状態のときは、リーダーはチームや個人にテコ入れをするべきと分かる)。
逆に、チームおよび個人が成長を感じられない組織や仕事内容は、単に時間とカロリーを金に換える行為であり、人が離職し
やすい(ように感じます)
- 23. 23
[3] アジャイル開発_苦労点と解決例
5. スプリントレトロスペクティブ
5.1 きちんと開催がされない状態にならないよう、気をつける
【工夫14】日本人は集団内で自分をさらけ出して、本気で振り返りをするのは苦手のように感じます。いわゆる通常のレトロ
スペクティブの実施だけではスクラムが機能不全になりやすいように感じます(海外の平均チームでもレトロスペクティブは
ポイント2点と難しい項目です)。
そこで、開発メンバの各人と私が、2週間に1度、1on1(30分)を実施し、1:1で個人とチームについてレトロスペクティブ
する要素を追加し、レトロスペクティブを分厚くする。
(発表では解説は省略)
【工夫15】デイリースクラムでYWT-Pを毎日記載しているので、その記載をベースに実施すれば短時間でレトロスペクティ
ブが可能になる。そこでも基本的には、「W:分かったこと、理解し学んだこと」を中心にしつつ、次のスプリントでよりカ
イゼンするために試みる「Try」を定める。基本的にKPTよりもYWT-Pの方が、初心者が多い場合はやりやすい。逆に猛者たち
の集まりで、各自がいろいろなアジャイル・スクラム経験がある場合は、今回のメンバでの最適を探すべくKPTが適している
(ように感じる)。
- 24. [3] アジャイル開発_苦労点と解決例
6. プロダクトオーナー(発表では解説は省略)
6.1 大変すぎるプロダクトオーナー:期待される、必要とされる知識・スキルは膨大
図3. プロダクトオーナーが周囲から期待される職務とそのために必要な知識
プロダクトを形にするために必要な運用スキルと知識
プロダクトが
どうあるべきか
の牽引のために
チームとの
協働のために
プロジェクトを
遂行するために
開発メンバーとの
意思疎通のために
受け入れテストの実施と
テスト結果の活用
ユーザーテストによる
フィードバック取得と
継続的な計測
プロダクトバックログの
管理方法
コミュニケーション設計
プロジェクトマネジメント
ソフトウェア開発の基本的な知識
https://www.amazon.co.jp/dp/4802511191/
- 26. [3] アジャイル開発_苦労点と解決例
6. プロダクトオーナー
6.1 大変すぎるプロダクトオーナー:期待される、必要とされる知識・スキルは膨大
Biz
AI
UVP
●AI系のPoC案件のPM経験は
ある。だが、ITソリューション
を作ったり、ITシステムのPM
経験がない
↓
・ソフトウェア要求を特定でき
ない
・開発チームの技術課題を理解
できない
機械学習・DLの
各種アルゴリズム
統計解析
ITシステム構築
MLOps
機械学習工学
AIソリューションの企画
プロジェクトマネジメント
ビジネスモデル構築
IT
●IT実装で、AIも実装できる。
だがPMやリーダーは経験して
いない。顧客との会話も少ない
↓
・技術ありきで開発を進めがち、
顧客の課題解決ソリューション
にならない
・チームをリードできない
●いわゆる上流SIerに多いPM
人材。AIはかじり程度で、製
品レベルのAI実装力や統計知
識がない
↓
・AIソフトウェア特有の開発
チームの技術課題を理解できず
・AIとしてのソフトウェア要
求や品質管理を特定できない
理想のPOは、Biz × IT× AIの
3領域の交点にいる
Biz × AI
Biz × IT(解説省略)
IT × AI(解説省略)
- 27. 27
[3] アジャイル開発_苦労点と解決例
6. プロダクトオーナー
6.1 大変すぎるプロダクトオーナー:期待される、必要とされる知識・スキルは膨大
【工夫16】PO(Biz×AIの人材)を補助するために、自社製品開発のPM経験者(Biz×IT)の人材をPO補助としてアサイン
し、POを支援する体制を構築
【工夫17】(発表では解説は省略)
フロントとバックを分離した構成にし、API通信(axios、Ajax)でデータをやりとりさせる。
すると、POはUX・UIメンバとフロントというビジネスとユーザーの接点に焦点を当て、ビジネスデモをフロントだけでできる
(バックエンドはあらかじめJSONファイルを用意したオズの魔法使い作戦)。
この「フロントだけのオズの魔法使い作戦」でも、ユーザー体験UXの大雑把な検討やカイゼン、プロダクトのユーザーストー
リーマッピングやプロダクトバックログの精査がしやすくなる。
これがフロントとバッグが密結合だと、POにとってはバックの理解も少し必要になり、大変さが増す。
- 32. 32
[3] アジャイル開発_苦労点と解決例
他. AI製品の品質確保(発表では解説は省略)
アジャイル開発での品質確保のデファクトスタンダードはまだ存在しない。。。
「ソフトウェア品質知識体系ガイド(第3版) -SQuBOK Guide V3-」で発表(2020年秋予定)。
(AIやアジャイルが含まれたバージョンアップの予定の詳細は以下URL)
https://www.juse.or.jp/sqip/squbok/index.html#10
【工夫20】そこで実施した工夫たち
(1) AI製品なので、有名で代表的なデータセットでの、各種性能は確認しておく
(2) AI製品なので、バッチ推論や訓練にかかる時間が、ファイルサイズの増加に対しどのように効くのか確認しておく
(3) オンライン推論やバッチ推論や訓練のリクエストが多数同時に来た時の、挙動を確認しておく
(4) 「ユーザーストーリーの実行範囲でバグがない」と「実際にリリースして製品としてバグがない」は一致しないことを意識
(5) フロントとバックは分離させ、バックエンドは基本API化しているので、CRUDベースに機能視点のデモシナリオテストを
作成し、通しのテスト
(6) データアップロード、学習、運用、データ追加、再学習、運用といったMLOps的視点で実際の使い方のビジネスシナリオ
テストを作成して、通しのテスト。このように受け入れテストを2観点で作って実施し、エンドゲームのフェイズで実施。
- 35. 35
[3] アジャイル開発_苦労点と解決例
他. アジャイル・スクラム開発前にメンバが読んだ書籍(発表では解説は省略)
【工夫23】 POやリーダークラスは、以下をおすすめ
正しいものを正しくつくる
https://www.amazon.co.jp/dp/B07SGCH8R6/
レガシーコードからの脱却 スクラム現場ガイド
https://www.amazon.co.jp/dp/4873118867/ https://www.amazon.co.jp/dp/4822286584/
https://www.amazon.co.jp/dp/4839951993/
More Effective Agile
アジャイル開発の
プロジェクト
マネジメントと
品質マネジメント
https://www.amazon.co.jp/dp/4817196955/