機械学習を含む開発をアジャイルに取り組む
概要
機械学習・ディープラーニングなどアルゴリズム検討を含めてうまくアジャイル開発を回すやり方を考えたい。
Spotifyで機械学習に取り組むDavid Murgatroyd氏がSlideshareに公開している資料をベースとしている。
www.slideshare.net
詳細
機械学習の検討がアジャイル開発でうまく回せない要因
アプリケーション・システムの開発と比較してアルゴリズム開発は予測しづらい事項が多い。また手番も長くかかるため、製品全体を固定期間のスプリントで区切り、アジャイルに開発しようとするとアルゴリズム周りでうまくいかないことが多い。近年だと機械学習やディープラーニングが関係する箇所が特にそうなりやすいのではないか。
機械学習の検討の流れ
David Murgatroyd氏の資料では下記のように整理されている。楽曲の推薦アルゴリズムを業務で開発していると思われるが、検出や認識など他のアルゴリズムでも大枠は外してないと思われる。
- 問題を明らかにする (Identify Problem) : 解決すべき課題を明確にする。
- メトリクスを明らかにする (Identify Metrics) : 課題が解決できたか確認できる指標を明確にする。
- データを明らかにする (Identify Data) : 扱うデータセットの用意・整備
- モデルを明らかにする (Identify Model(s)) : どのようなアプローチで問題に取り組むか。ディープラーニングのネットワーク検討など。
- 探索・実験 (Explore & Experiment) : データセットをもとに学習を施行する。
- 分析 (Analyze) : モデルがうまく動作しているか、仮定に見落としが無いかを確認する。
- 優先順位づけ (Prioritize) : 課題の対処法を検討する。
- 製品投入 (Productize) : 完成したモデル・アルゴリズム・モジュールを製品に組み込む。
開発フロー案
別チームとして扱い、アジャイル開発のサイクルに取り込まない。定期的に成果物をリリースしてもらう。
機械学習の検討を行うチームとアジャイル開発を行うチームを完全に分ける。機械学習検討チームはアジャイル開発を行わず、彼らの都合の良いタイミングで不定期にリリース物を出してもらう。そしてタイミングを見てアジャイル開発チームが成果物を製品に統合する。。全体としてアジャイル開発は実現できていないが、とりあえず機能する。
デリバリーまでに時間がかかること、顧客からのフィードバックが届きにくいこと、フィードバックを踏まえた開発項目の優先順位見直しがやりにくいことが課題である。
機械学習の検討ステージによってスプリント内で扱う開発項目を絞る。
よくあるスクラムを用いたアジャイル開発は固定期間のスプリント内(1週間〜1ヶ月)で要求分析・設計・実装・テストまでを行う。先の機械学習の流れで言うと1から8まで1週間〜1ヶ月で終わらせるイメージとなる。これでは検討時間が十分に確保できず、スプリント内で不足の自体が起きると成果なしとなってしまう。
そこで機械学習の検討ステージによってスプリント内で検討する項目を限定し、開発期間の短縮を図る。具体的には次のようにする。
- 課題の明確化・基本方針の決定→1〜4を扱う : 課題・指標がうまくつかめるまで試行錯誤を行う段階。基本方針となりうる候補をいくつか見つける。
- モデルの選定・改善→4〜7を扱う : モデル・データ・アプローチを変えながら改善を試みる。最終製品で用いるモデル・アルゴリズムを決定する。
- 製品投入前の仕上げ→ 5〜8を扱う : パラメータの調整を行い、製品品質に精度を高める。
チーム構成案
クロスファンクショナルチームを構成する
各チームに機会学習に長けた人材を配置し、アプリケーション・システム開発を行うメンバと協調して開発を進める。 アジャイル開発としてはもっとも望ましい状態。 各チームに機械学習エンジニアが大勢いることはないので、機械学習アルゴリズムの深掘りがしにくい課題がある。 製品にたくさんのモデル・アルゴリズムがあり、それぞれが比較的シンプルな場合に有効。
専門チーム
機械学習に長けた人材をチームに集め、成果を別チームに提供する。 機械学習アルゴリズムの深掘りはやりやすくなる。 システム・アプリケーションを開発する別チーム間と開発スピード・サイクルを揃える必要が出てくる。 製品に少数で複雑なモデル・アルゴリズムがある場合に有効。
機械学習エンジニアの分類と役割
ひとくちに機械学習エンジニアといっても本人の特性・資質によって役割が異なる。
「機械学習の適用」を行うエンジニア
ツール・ライブラリ・既知のモデルを元に、製品で活用できる機械学習技術を開発するエンジニア。 ArXivに投稿される最新論文や、分野ごとの技術動向をウォッチし、自社の製品に活用できるものを見定めて取り込むことを行う。 求められる素養としては「アルゴリズムもわかるエンジニア」。
「機械学習に必要なツール」を開発するエンジニア
最新の論文、分野ごとの技術動向をウォッチし、背景の理論を理解し、技術の検討・開発に必要なツールを開発するエンジニア。 求められる素養としては「理論がわかり、実装にも強い研究者・またはエンジニア」。
「機会学習の理論」を開発する研究者
みんなどうしているんだろう?
事例を集めてもっと良いやり方を見つけたい。
「プロダクトオーナーの役割に関する誤解」が組織に与える害について、また避けるために何をすべきか。
概要
YouTubeにアップロードされている"How Misconceptions About the Product Owner Role Harm Your Organization and What To Do About It"の意訳。
詳細
「プロダクトオーナーの役割」はどう開発に作用するか
小さなチームで1つの製品を作る場合、プロダクトオーナーはすぐ近くにおり、「製品・開発のビジョン・優先順位・目的」は明確である。 顧客もすぐ近くにいることから開発成果に関するフィードバックがすぐにもらえ、チームは複数の作業がこなせるクロスファンクショナルチームであり、プロダクトオーナーは多くの決定権限を開発チームに与え、開発をより加速させていくことができる。
大規模組織になるとプロダクトオーナーの役割がどう誤解されるか
1チームではスクラムが回せなくなるので、チームの分割を検討する。 一番簡単なやり方は1チームの時のスクラムのコピーを複数作り、それぞれにプロダクトオーナーをつけることである。 ※以降この形式を「大人数での単純スクラム」と呼ぶ。
しかし各プロダクトオーナーが対等の立場であるとすると、各プロダクトオーナーには製品全体の決定権がなく、バックログの並び替えすら行うことができない。 この場合組織はプロダクトオーナーに「チームの生産性を最大化する」ことを期待するしかない。 動画ではこのプロダクトオーナーの状態を「チームアウトプットオーナー」と呼んでいる。 チームアウトプットオーナーは、チーム固有のバックログを作成し、チームのアウトプットのみの最大化に注力することになる。
チーム内の生産性は高まるかもしれないが、チーム間の協力は機能せず、開発メンバーを増やしただけの開発加速は期待することができない。
「プロダクトオーナーの役割に関する誤解」が顧客フィードバックを遅くするのはなぜか
通常のスクラムは各スプリントごとに出荷できるプロダクトを開発する。これにより顧客のフィードバックを早期に獲得する。
「大人数での単純スクラム」は各チームがスプリント内で「コンポーネント」を開発することが多い。 コンポーネントだけでは顧客にとって価値のある単位ではなく、これを基にしたフィードバックを獲得することができない。
チームアウトプットオーナーはチームのアウトプットの最大化にのみ注力するため、効果が測りにくい「ビジネス全体での優先順位」や「他のコンポーネントとの整合性」ではなく、ベロシティなどのメトリクス最適化を重視するようになってしまう。
コンポーネントを結合するタイミングが遅れれば、顧客フィードバックを獲得するタイミングが遅れることになり、遅れている間他のチームはさらに別の新コンポーネントの開発に着手したり、コンポーネントの改修を始めたりするかもしれない。これがまたコンポーネント統合のタイミングを遅らせることになり、顧客フィードバックはますます得にくくなっていく。
「プロダクトオーナーの役割に関する誤解」が開発者のモチベーション、顧客への共感を減らしてしまうのはなぜか。
「大人数での単純スクラム」は開発チームと顧客が話す機会がほとんどない。 開発チームは橋渡し役の満足度を高めようと動くようになる。 当然のことながら実際の顧客から得られるフィードバックと橋渡し役から得られるフィードバックは異なる。
本物のプロダクトオーナーは高い顧客価値をどう提供するか
本物のプロダクトオーナーは下記ができなければならない。
- 大きなビジネス上の決定
- 製品のビジョン・開発優先順位の見直し
- 開発項目でなく、顧客視点からみた課題を記述したバックログの用意
上記をインプットとして、スクラムチームが自律的に開発を進める。
「プロダクトオーナーの役割に関する誤解」が価値の提供を減らしてしまう訳
「大人数での単純スクラム」は特定コンポーネントに特化してしまうリスクがある。 スキルセットが古くなったり、他のチームがコンポーネントを扱えなくなることがこれに該当する。 チームアウトプットオーナーはチームにできる作業を優先順位をつけ、メンバーも言われた通りに作り続けるが、顧客に価値を提供できる開発項目は他チームのバックログに隠れていたりするため、組織全体として提供できる価値は低くなる。
開発チームがどんなに忙しくしていても実際に価値を生んでいるチームはその中の一部であり、アジリティを持ったビジネスを展開していくことは叶わない。
誤ったプロダクトオーナーの役割を果たし続けることによるうれしくないこと
チームアウトプットオーナーは板ばさみとなる。ビジネス上の決定権がないのに責任を押し付けられたり、開発チームから突き上げを食らったりする。管理職としての業務、進捗報告、複数チーム間の調整をプロジェクトマネージャーとして求められたり、完全なユーザーストーリーの記述などなどなど・・・できないことばかりがスタックしてしまう。
チームの自律性・クロスファンクショナルの改善を促し、スタックしている人を助けるか
1人のスーパーマンが全てを引き受け、全てを調整することはできない。 チームに責任を移譲することで特別な役割を持つ人を減らしていく。
プロダクトオーナーに由来する新たな役割を作るべきか、チーフプロダクトオーナーとか、ビジネスオーナーとか
不要。
プロダクトバックログを1つにし、チーム間の壁を取り払い、顧客から開発チームフィードバックを得ることができるようにすることで、チーム同士が協力しあい、全体としてアジリティのある開発を行うことができる。
上記の開発を実現できる人のことをプロダクトオーナーと呼ぶ。新たな名称を設ける必要はない。
感想
「チームアウトプットオーナー」という呼び名は新鮮で面白い。 動画ではLeSSが一言も紹介されていないが、LeSSの基本思想である「組織全体(複数チーム)で1つのスクラム開発を行う」がなぜ必要なのかが丁寧に説明されていると感じた。
1on1
概要
「定期的」に「上司と部下の間」で行う1対1の対話。 対話を通じて部下の行動や経験学習を深めることを目的としている。
詳細
1on1とは
「定期的」に「上司と部下の間」で行う1対1の対話。 「具体的な経験」を思い出し、「内省」し、「教訓を引き出し」てから、「新しい状況へ適用」するサイクルを回すことで業務経験から成長につなげる。
部下の成長のために行われるミーティングである。 上司の進捗管理のためではない。 また評価のための面談ではない。
やり方
定期的に実施する。ヤフーの場合、週に1回30分程度。 間隔が開いても3週間程度に留める。
「今日は何を話そうか」から切り出すと良い。1on1で話すトピックの選択を部下に委ねることになり、上司・部下両方の頭を「1on1は部下のために行うもの」へと切り替えることができる。
部下に十分に話をしてもらうことが重要。なぜなら経験学習を深めるには自らの経験を詳細に思い出し、自分の言葉で口にし、深く内省することが効果的だからである。 部下の話を遮らず、傾聴することが重要。 話を間違った方向に進めてしまうかもしれないので自分の考えも話さない。 また部下の考えを深めるために「言い換え」を使うと良い。
1on1終了後の次の行動は、部下に自ら思いついて行動に移ってもらうと良い。 「今回の出来事で何を学んだの?」と聞くのがよい。 次の行動を部下より先に上司が示してはならない。
効果
- コミュニケーションをとるきっかけになる。コミュニケーションは長さよりも頻度が重要。定期的に行うことで上司も部下も時間が割きやすくなる。
- 相談。評価を短い間隔でフィードバックできる。
- 部下の状況を上司が知ることができる。
1on1をレベルアップするための手法
- アクティブリスニング : うなづく、相槌を打つ、相手が言った言葉を繰り返す
- レコグニション : 部下のありのままを受け止め、それを相手がわかるように伝える。
- 短くシンプルな、オープンクエスチョン(=答えがYes/No以外になる質問)を投げかけることを心がける。
- 時間は木曜日午後15時〜17時がベスト、次が水曜午後・金曜午後
シャドーコーチング
5人で1on1を実施し、終わった後にコーチ役が残り4人からフィードバックを受ける。
- コーチ :上司役、レビューを受ける側
- クライアント : 部下役
- シャドークライアント : クライアント役になったつもりでコーチの表情・姿勢・ジェスチャなどを観察する。
- シャドーコーチ : コーチ役になったつもりでクライアントの表情・姿勢・気持ちの現れを観察する。
- オブザーバー : 会話を聞き、出てきた言葉を正確に書き取る。フィードバック時の素材を記録する。
フィードバックアンケート
クライアント(部下役)にアンケートをとる。
- 内省効果がでているか
- 有効な気づきが得られているか
- キャリアを描くための支援が得られているか
- 目標達成のための支援が得られているか。
コーチ陣で情報交換する
どんなことを話したのか、どんなアドバイスが効果があったのかを情報交換することで質を高める。
話す際のテーマ例
- キャリアについて
- 3年後どうなっていたいか
- そのために今年、今のチームで何をしたいか
- 目標/評価について
- 目標/評価について悩んでいること・障害はあるか?
- 相談/不安/不満/報告
- 組織について
- プロジェクト/チームについて
- 一緒に働くメンバーについて
- その他
- 製品・プロジェクトをよくするために何をしたいか?
- 自分がリーダーだったら製品・プロジェクト・チームをどう改善したいか
- 今の仕事・環境はあなたや周りのメンバーの能力をちゃんとひきだせているか?
- 与えられた仕事は面白いか
- 今やっていることで1つやめるとしたら何か、一番無駄だと思うことは何か
マジックフレーズ
6つのマジックフレーズでエンジニアの力を引き出せ！「発想を生み出す1on1」とは？ – フルスイング – DeNAより。
- 発想を引き出す→先週こんな話したよね
- 発想を引き出す→ニュースで〇〇をやっていたね
- 発想を引き出す→最近何か面白い技術はある?
- 発想を見つける→自分だったらこうするかなあ
- 発想をみつける→それって〇〇ということだよね
- 発想を後押しする→一緒にやってみよう
参考
書籍
ヤフーの1on1―――部下を成長させるコミュニケーションの技法
- 作者: 本間浩輔
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/03/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Web
スキルマップ
概要
複数チームで1つのプロダクトを開発する場合、開発対象であるコンポーネントでチームを分けるのではなく、各チームが複数コンポーネントを扱うことができ、単独で価値を提供できるフィーチャーチームを組ませる方が良い。 フィーチャーチームがうまく機能しない場合、原因の一つにスキルの偏りが考えられるため見える化して対策をうつとよい。
詳細
作り方
- チームの開発に必要な技術をリストアップする
- 開発言語(C/C++/C#)、ミドルウェア(DB, Webフレームワーク)、ネットワーク知識(HTTP )、構成管理(Git)、テスト関係、ファシリテーションなど
- チームメンバのそれぞれに、各技術に対する自信度を記入してもらう
- ◎:得意、○:一人でできる、△:助けてもらえばできる、・:今後頑張りたい、空欄:できない など
- チームメンバの見える所に置く。印刷して貼るなど。
- 定期的(数ヶ月に1度とか)にスキルマップを更新する。
効果
- 質問相手が探しやすくなる。得意・一人でできる メンバに聞きに行けば良い。
- チームに不足してるスキルが明確になる。得意・一人でできる人数を数えればトラックナンバー1を早期に発見することができる。
- チーム分けを行う際にスキルの偏りがわかりやすくなる
注意点
記入者の意見を尊重する・人事評価を絡めない
「得意・一人でできる」など客観的な基準ではないので、記入してもらった後に評価を上げたり下げたりしない。 「各人の現状認識の共有、過去の記入結果との比較、今後学習したいと考えている項目の宣言」ぐらいに扱う。
また「スキルを幅広く身につけている人が優れている」ことはないので、人事評価にも利用しないこと。
チームの成長に必要な技術をリストアップする。
開発に必要な知識・技術はスキルマップに表しきれないほどあるかもしれないが、全員が一人でできると回答している基本技術や、今現在の開発に必要のない技術は項目として選ばない方がよい。
FAQ
各自の技術を見えるようにして貼り出すと嫌がる人がいるのでは
アジャイル開発・スクラムに取り組んだことがない人がよく挙げる懸念事項。 チームで開発を進めるうちに各人の得意・不得意分野、力量は互いにつかめてしまうもの。
TIPS
- 「今後習得したい」の記号を「↑」で表現するとやる気が表せていい感じ。
- スキルマップの下部に「◎:得意、○:一人でできる」の数を集計して表示するとまさに「トラックナンバー1」があぶり出される。目で記号を見ていても深刻に感じないので実際に集計してみた方が良い。
参考
Re: スクラムを大人数で運用したところ💩な結果になった。
はじめに
スクラム導入の成功事例は近年よく目にするようになり、最近ではLeSS導入の事例も増えてきました。 でもLeSS導入の難しさを紹介した事例はこれまで見かけたことがなかったので、自分がプロダクトオーナー/スクラムマスター/アジャイルコーチの立場ならどうしたかなと思うところをまとめてみました。
私のLeSS経験は1年半ほど、開発者が20〜30名の開発で、チーム数は2〜4チームの間を変動しています。 LeSS Hugeは導入したことがありません。 LeSS実践者研修は2018年の5月に受けました。
気になった点
ベロシティは生産性の指標では無い、チーム間で比較しちゃダメ
ベロシティ(達成pt数)という形でチームの貢献度が表されて、みんなが働いている状況を数字で共有できる
スクラムにおけるベロシティは「あるチームがスプリント内に提供できる要求の量」であり、次回以降のスプリントの参考にする指標でチームの成長や生産性をはかる指標ではありません。下記に詳しく紹介されています。
LeSSでは1つのプロダクトバックログを全チームで共有するため、「チーム横断で見積もられたストーリーポイントを比較に使えるじゃないか」と思うかもしれませんが、そもそもストーリーポイントは規模の相対比較の指標であり、正確なものではありません。 また作業を担当する人・経験によって工数は変わってしまいます。
LeSSにおけるストーリーポイントの利用方法は、複数チームでのストーリー分配時の目安です。各チームのスクラムマスターが自分のチームにとってこなせる作業量であることを判断するのに使います。チームにとって得意なストーリーが多ければ全員で見積もりして合意したストーリーポイントは過大評価になりますし、苦手なものが多ければ逆になります。とはいえチーム分配後にストーリーポイントを見積もり直すようなことはしません。LeSS実践者研修で講師だったBas Vodde氏は「やりたければやっても良いが、何の意味もない。」と質問に答えていました。
2つの大きなプロダクトをグロースさせるために、トライアンドエラーとリリース速度をあげたかった。
スクラム/LeSSの生産性を測りたいのであれば別の指標を用いるべきです。例えば…
- リリース/デプロイの回数、頻度
- ストーリーが積まれてから顧客に届けられるまでの期間
- スプリント完了後に見つかったバグ、バグ発見から修正までの期間
関係者と責任者は別、全チームがプロダクトの全部分をさわれなくても良い、調整はチームにやらせる
関係者が増えたおかげで、責任が不明瞭になり物事の決めごとに労力と時間がかかる。
複数チームで1つのソースコード・コンポーネント・ソフトウェアを開発することになるので、設計・機能・品質に関して人ごとのぶれが発生します。この問題の解決策としてコンポーネントコミュニティ & コンポーネントメンターを設置すると良いです。決め事は代表者で決めれば良いし、相談が必要なほど皆が関心があるならコミュニティが機能するはず。
プロダクトの定義とDoneの定義は少しずつ拡大していく
1週間のスプリントで、見たこともないプロダクトの見積もりと学習をし、数チームと合意し、複数のSMと合意するのは無理ある。
全部のプロダクトを全チームが同じようにいじれることは理想かもしれないが、現実的には少しずつ増やしていくしかない。
- システムに含まれる全てのコンポーネント→プロダクトの定義
- システムのリリースまでに必要な全ての作業→Doneの定義
を書き出し、縦軸にプロダクトの定義に照らし合わせて大きいものから並べ、横軸にチームができるようになるべきリリース前作業を優先順に並べる。チームの現在位置を皆で確認し、数ヶ月後・半年後・一年後といったスパンでチームの将来位置をみなで話し合うとチームの成長に必要な要素(扱えるようになりたいコンポーネント、スプリント内でできるようになるべきリリース前作業)が差分として明らかになる。LeSS実践者研修では「Doneの拡張ワークショップ」として行なった。
チームは変えない
スクラムに不慣れな人間がたくさんいる状況は仕方がないが、習熟と効率化が発揮されるのが遅い。 人の入れ替え、組織変更を挟むと初期化される...
スクラムの目的が「チームを成長させ、自律的に動き価値を提供できるようにする」です。メンバを変えるとチームの文化が変わってしまうので入れ替えは基本行いません。 プロダクトに合わせてチームを構成するのではなく、チームにプロダクトを与えます。チームと技術分野が噛み合わないプロダクトだったとしてもチームが技術を学び、不足を自分たちで補えるようにすることで、自律的なクロスファンクショナルチームができます。
振り返りはできるものを少しずつ
トップダウンで案件が降ってくる形になり現場での改善活動ができなかった。
開発がどんなに忙しくとも、スプリントの終わりに振り返りを必ず行い、少なくとも1つは改善を行いましょう。 やりがちなダメな改善は「次から気をつける。次は頑張る」です。気持ちの問題にするのではなく、プロセスの問題として捉えましょう。 振り返りの最中に答えが出なくても、状況を1歩進める行動を明確にするだけでも違います。例えば「XXXについてYYさんに話す」とか。
LeSS導入とは組織変革である
普通の話だけど、権限と責任の移譲をしっかりやって、コンパクトな組織を維持できるようにしたほう良いと思った。
LeSSの思想は「1つの大きなプロダクトに対して、1つのスクラムチームで取り組むことを考える。その時にボトルネックとなる事項は分散させる。」です。基本的に全体で1チームとして考えます。SAFe/Nexusなどのスケーリング手法は統合チームを置いたり、調整役(XXXリーダーとかプロジェクトマネージャーとか)を置くことで対処していますが、LeSSは調整をチームに委ね、調整役を置きません。したがってLeSSの導入が進むほどに、過去の組織にあった「プロジェクトマネージャー」などの調整役が不要になり、組織構造がコンパクトになります。
LeSSの導入には組織変革が避けて通れないため、LeSS研修には管理職向けのものも用意されています。
LeSS導入は組織変革を伴うので、少しずつ進める必要がある
私の経験を振り返ると
- 1チームでスクラムがきちんと回せるようになる
- 人数が増えたチームを分割し、2〜3チームでスクラム/LeSSが回せるようになる。
- 8チームでLeSSを回せるようになる。
- 4チーム x 2エリアでLeSS Hugeを回せるようになる
- LeSS Hugeが回せるようになったので必要なだけスケールさせる
だと思います。いきなり4、5は無理です。
LeSS実践者研修オススメ
上記の内容を3日間で学べるLeSS実践者研修オススメです。次回は2018年3月12〜14日です。
スプリントレビューでデモしにくい時 → 551メソッド
概要
「UIが無い」などスプリントレビューの参加者にスプリントの成果が見せにくいときのやり方。 成果が「あるとき」と「ないとき」を明確にすることで、何が変わってどのくらい価値が生まれたのかわかりやすくする。
ネタ元
プロダクトオーナーはどこにいる？
概要
適切なプロダクトオーナーを見つけることはアジャイル開発の成功のために欠かせない。 自分たちの開発形態を踏まえ、正しいプロダクトオーナーを探す努力を続けること。
詳細
3つの開発形態とプロダクトオーナーがどこにいるか
プロダクト開発(Product development)
製品・サービスを開発し、社外の顧客へ提供する形式。多くの製品開発はこれに属する。 適切なプロダクトオーナーは社内にある事業企画を検討する部門などビジネスサイドにいることが多いが、アジャイル開発に巻き込めず開発サイドの窓口を代理のプロダクトオーナーとして立てることが多いと思われる。
社内(プロダクト)開発(Internal (product) development)
社内で使われるシステム・ツールの開発を行う。 社内システム・ツールの取りまとめ部門にプロダクトオーナーの適任者がいる。
顧客も社内の人間であり、プロダクトオーナー含めてアジャイル開発に巻き込みやすい。
プロジェクト開発(Project development)
社外から委託を受けて開発を行う。委託元の開発形態はプロダクト開発かもしれないし、社内開発かもしれない。 いずれの場合もプロダクトオーナーは開発者が所属する会社ではなく、委託元の会社にいる。
プロダクトオーナーを探す
適切なプロダクトオーナーをビジネスサイドから立てることが望ましいが、開発の最初からアジャイル開発に巻き込むことが難しいことが多々ある。この場合、主に開発サイドから、代理のプロダクトオーナーを立てて開発を開始することになる。
しかし適切なプロダクトオーナーをアジャイル開発に巻き込む努力を止めてはならない。 下記の違いに留意し、現在のプロダクトオーナーがどの位置付けなのか開発メンバが認識しておくようにする。
- 代理プロダクトオーナー(Proxy Product Owner)
- 適切なプロダクトオーナーは見つかっているが、多忙のためアジャイル開発に割く時間がなかったり、拠点が離れていて開発チームと密なコミュニケーションが持てない場合に立てる。代理プロダクトオーナーは本物のプロダクトオーナーと開発チームの間を行き来して開発が滞らないように協力する。
- 偽プロダクトオーナー(Fake Product Owner)
- 適切なプロダクトオーナーが見つかっておらず、開発サイドから立てた代理の場合こう呼ぶ。「偽」とつけることで、ビジネスサイドから本来開発を主導するべき適切な人材を探す努力を忘れないようにする。
プロダクトオーナーを育てる
プロダクトオーナーを立てるべき適切な部門を見つけることは難しくないが、プロダクトオーナーとなるべき適切な人材は見つからないことが多い。製品についてビジョンと情熱を持ち、優先順位を明確化して決断することが求められるが、全てを最初から備えた人物がいることはまずない。
その場合はスクラムマスター/アジャイルコーチがプロダクトオーナーを育てる必要がある。
ネタ元
LeSS実践者研修で学んだ。下記サイトでも紹介されている。
