332 Views
December 01, 25
スライド概要
(AIによる要約)
本スライドは、新規商材開発における品質リスク対策について、筆者の経験事例を通して考察するものです 。
【事例の概要と教訓】 新規の画像解析関連事業において 、当初は開発ベンダーの自主性に任せる「願望ドリブン開発」で進めた結果 、開発中期に不具合が増加し、リリース遅延の危機に瀕しました 。
この教訓から、リスク分析を実施し 、あえてチームの「約束事」を決めて忠実に守るという対策を講じました 。具体的には、アジャイルコーチをつけてスクラムセレモニーの実施日時(タイムボックス)や参加必須/任意を明確化しました 。
【効果と結論】 これにより、各自の役割と責任が明確になり 、チームにリズムが生まれて自己組織化が進みました 。結果、不具合対応が迅速化し、不具合件数も収束してプロダクト品質が向上しました 。
筆者は、プロセス(約束事)を決めることはアジャイルっぽくないと思っていたが 、実際はそれが品質とアジリティを担保する有効な品質リスク対策となったと結論付けています 。最も重要なのは、誰かに押し付けられるのではなく、チーム自身で考え、必要に応じてアップデートできる約束事である、としています 。
この知見を基に、「製品の質」「仕事の質」「チームの質」など広範な「品質」を意識し 、品質リスクチェックリストを活用しながら品質リスクについて考え続けることの重要性を説いています 。
アジャイル/スクラム/データサイエンス/プロダクトマネジメント/プロジェクトマネジメント/組織論など、日々の学びをスライドにします。
新規商材の品質リスク対策 ~スクラムチームの”約束事”を事例 として品質について考えてみる~ 2025/12/01 @shimitaka1982 清水 隆史
はじめに このスライドは私(清水)のとある新規商材開発にお ける企画・設計・開発・テスト・運用・販売など一連の プロジェクトの経験を「品質リスク」という観点で見直 して整理するものです 具体的なプロジェクト名は出せませんが イメージしやすいように業界やプロジェクト 規模などを示しながら事例を紹介します
【事例】 敢えて“約束事” を決めた
プロジェクト概要 業界:画像解析関連事業(新規事業・新規商材) 概要:小売店舗に設置したカメラによる購買行動検知 のシステム開発プロジェクト 規模: ✓プロダクトオーナー:1人 ✓スクラムマスター:1人(自分) ✓チームメンバー:2~4人(タイミングによって異なる) ✓ステークホルダー:たくさん(10人以上) 結果:うまくいかなかった⇒うまくいった
最初は開発ベンダーに敢えて任せた 開発ベンダーA社に発注。その時点ではまだ企画段階で あり要件が不明確であったため業務委託とした プロジェクトのポリシーとしてアジャイルに進めると して開発ベンダーの自主性に任せてタスク出しや スケジュール立案を行ってもらうこととした その背景として開発ベンダーはプロであるから自分 で品質を担保しながらうまいことタスク出しをして うまいこと開発出来るだろうという考えがあった 敢えて名前を付けると”願望ドリブン開発”だった
最初は開発ベンダーに敢えて任せた 開発中期になって不具合が増加 ✓GPUを搭載したエッジデバイスで謎のエラーが発生 リリースに間に合わないことも増加 ✓顧客がいるPoCに最新版モジュールが提供できない 開発ベンダーのマネージャはこう言った 「後から仕様追加されても困るんですよね」 「品質基準も決まってないですよ」 「認識があってなかったんじゃないですか」 「準委任(業務委託)ですし」
考えたこと こちらとしては自主性に任せているつもりでも、開発 ベンダーとしてはそうではなかったのかもしれない (放任していると思われたのかもしれない) お互い合意したつもりでも実は腹の底から合意できて なかったのかもしれない 「アジャイルに取り組む」ということを勘違い してたのかもしれない(自分も開発ベンダーも) もしかしたら外注でアジャイルは難しいのかも しれない
やったこと A社との関係の教訓から、現在のプロジェクトが置かれ た状況を再度整理して、そのリスクを洗い出した そのリスクに対して発生確率と(仮に発生した際の) 影響度のマトリクス分析を行った上で対策を考えた リスクを意識しながらプロジェクトを 運営することが出来るようになった リスクの内容 発生確率 影響度 総合評価 ・・・ 高 大 S ・・・ 中 中 B 効果
やったこと アジャイルコーチについてもらいスクラムセレモニー の実施曜日・時間(タイムボックス)を明確に決めた 効果 仕事にリズムが生まれた 限られた時間でそのセレモニーの目的を達成できる よう考えて時間を使うようになった 月 火 水 木 金 午前 デイリースクラム デイリースクラム スプリントプランニ ング デイリースクラム デイリースクラム デイリースクラム 午後 スプリントレビュー ふりかえり
やったこと 各セレモニーの参加必須/任意なども明確に決めた 「参加不可」のセレモニーも明言した 効果 自分の役割と責任を明確化できた 何の権限もない人が”余計な口だし”をできなくなった イベント 時間 デイリースクラム スプリントプランニング スプリントレビュー : ◎:主幹 15分 PO ○ Dev ◎ SM ○ Others × 期限なし ◎ ○ ○ × △:状況に応じて参加 1時間 ◎ ○ ○ △ ×:参加不可 : : : : : ○:参加必須
やったこと つまり、敢えて チームの約束事 を決めて忠実に守った 言ってしまえば ただそれだけ
起こったこと 各自が自分自身のロールを意識しながら業務にあたれる ようになった! ✓(例)デイリースクラムを主幹するのはDevチームとした。これによって Devチームはただの進捗報告ではなく課題や気付きをプロダクトオーナー と共有してその日の活動量を最大化することに重点を置くようになった 自然と自己組織的なチームになった! ✓上記の通り各自が各ロールを意識して活動することにより、 他責にするのではなく自身が考え動くようになった。 ✓スクラムセレモニーを延長したい場合は「○○の理由で 延長したいです」ということを誰かが言いそれをチームで 合意した。必要があればチームの”約束事”をアップデートした
起こったこと そして品質が向上した! ✓正確にいえば不具合は出ることがあったが、その不具合に対する対応が 迅速だった。翌日にはデイリースクラムで報告され、スプリントに影響 が出るかどうかを精査し、影響がでるならプロダクトオーナーと交渉す る、ということが日常的に行われるようになった ✓セレモニーのタイムボックスを決めることにより質の高い対話が 行われるようにもなった ✓不具合件数自体も収束し、リリース予定日にも十分間に合う アプリが開発されていった つまり、チームの質が向上したことにより、 プロダクト品質も向上した、といえる
ふたたび考えたこと 最初は「約束事(≒プロセス)を決めるってなんだか アジャイルっぽくない」と思っていた ところが実際は敢えて約束事 (スクラムセレモニーやスクラムのロール) を決めたり意識したりする ことで品質とアジリティ (スピード)が担保できた つまり品質リスク対策として 有効だったと考えられる
ふたたび考えたこと 誰かが考えた品質管理プロセスを忠実に守っていたら 同じ事が起こったかというと、そうは思えなかった 大切なのは、この約束事を誰かから押し付けられるので はなく「自分たちで考えた」という点だった スクラムガイドはあくまで”カタ”として 参考程度にし詳細は自分たちで考えた そのため納得感も生まれたし、自分たち で考えたからこそ、自分たちで容易に アップデートすることが出来た
私の事例のポイント リスクの発生確率と影響度の表を作成した スクラムガイドを参考にチームの約束事を決めて それを忠実に守った。具体的にはスクラムセレモニーの タイムボックスや参加必須/任意の明確化など。 それにより自己組織的なチームが生まれ、品質とアジリ ティの向上がみられた 大切なのは自分たちで考えたという点。自分たちで考え たからこそ容易にアップデートできた。
Intermission… ここからは少し話を広げて”新規商材”や”品質リスク”に ついて考えてみます
新規商材 とは
そもそも ”新規”って なんだっけ…?
新規商材ってなんだろう? 初めての事業(業界)における商品 ✓いわゆる「新規事業における新規商材」 ✓(例)ソニーが損害保険業界に参入してはじめて出す保険商品 事業(業界)は既存だが新しい商品 ✓いわゆる「既存事業における新規商材」 ✓(例)ソニー損保の新しい保険商品 ソフトウェアやハードウェア、サービスやソリュー ションなど様々なものが一体となって顧客に販売を行う もの
“新規”を扱わないということがあるか? こういった話をすると「私(の部署・会社)は新規をや らないから関係ないです」といった反応がよくある しかしどんな商材にも何かしらの新規性はあるのでは? ✓はじめての顧客に対して販売する ✓はじめての機能を開発する ✓はじめての人・チームで取り組む そもそもプロジェクトの定義のひとつに独自性がある (今後の人生において、新しいことに取り組まないとか、 新しい人に全く会わないとか、あえりないのでは?)
ということで なにかしら新規モノに関わることはありうると思うので “新規(商材)”について 考えてみて損はない
品質リスク とは
そもそも ”品質”って なんだっけ…?
品質とは 品質については様々な人が様々なことを言っているが、 私はにしさんの教えが全てだと考えている (日本的)TQMでは 「あらゆる(品)質が重要」 と言っている 品質とは「品物の質」では なく「品格の品」+質 製造業の品質管理の考え方をイマドキのスタイルで読み解いてみよう https://youtu.be/HcTnUz55trg?si=KzfIWXsVHKMWlKPZ&t=991
(品)質を挙げてみよう! 製品の質 エンジニアの質 仕事の質 サービスの質 マネージャの質 経営者の質 情報の質 プロセスの質 人間関係の質 戦略の質 部署の質 チームの質 戦術の質 会社の質 人の質 いっぱい ある!
品質とは たとえば狩野モデル 顧客満足度に影響を 与える品質要素 ✓当たり前品質 ✓一元的品質 ✓魅力的品質 ✓無関心品質 ✓逆品質 *[出典]狩野モデル https://ja.wikipedia.org/wiki/%E7%8B%A9%E9%87%8E%E3%83%A2%E3%83%87%E3%83%AB
それぞれの品質は相互作用する 会社の質 (例)仕事の質が製品の質に関わる (例)プロセスの質が製品の質に関わる (例)会社の質が戦略の質に関わる 戦略の質 人の質 人間関係 の質 (例)人の質が会社の質に関わる (例)人の質がチームの質に関わる チームの 質 (例)人間関係の質がチームの質に関わる (例)人間関係の質がサービスの質に関わる サービス の質
品質リスクとは 先述のような”品質”が担保出来ないリスクのこと ✓ここでいうリスクとは目的達成を妨げる不確実な事象のこと (例)顧客ヒアリングの質が低くて魅力的品質が担保 出来ない(気付けない)リスク (例)仕事の質が低くて当たり前品質が担保出来ない リスク (例)戦略の質が低くて組織体制の質が低くてサービ スの質が担保出来ないリスク
改めて事例と ともに考える
リスク分析を行うのが大事 改めて事例を思い返してみるとリスク分析を行った ことが決定的に大切だった 初期のタイミングでリスク(目的達成を妨げる不確実 な事象)を出来るだけリストアップすることが大事そう さらにそのリスクについて発生確率と影響度を割り出 した上で対応策を考える 新規商材だけでなく新規事業や既存商材や日々のルー ティンワークでさえも必要そう
(参考)4種類のリスク対応策 一般的に対応策は回避・軽減・転嫁・受容の4種類ある とされる(※諸説あります) 種類 詳細 例 回避 リスクの原因となる活動や状況自体 を排除するアプローチ ・失敗しそうなプロジェクトを中止する ・リスクの高いサプライヤーとの取引を避ける 軽減 リスクが発生した場合の発生確率や 影響度を小さくするための対策を講 じるアプローチ ・セキュリティソフトを導入してサイバー攻撃の確 率を下げる ・重要なデータをバックアップして影響を軽減する 転嫁 リスクによる損失や責任を第三者に 移すアプローチ ・損害保険に加入して金銭的損失のリスクを保険会 社に移す ・業務の一部を外部委託して責任を共有する 受容 リスクの発生を認識しつつ、積極的 な対策を講じずにそのまま受け入れ るアプローチ ・大地震が発生してシステムがダウンする、という リスクは発生確率が低く対策のコストが見合わない と判断して何も対策しない
リスク対策にはリスクが伴う リスク対応策を実施すること自体にもリスクが伴う (例)事例のケースでは、”願望ドリブン開発”により 不具合が多発するというリスクに対する対応として、 チームの約束事を決めるという対応策を取った。しかし これはスクラムセレモニーをカタ通り”ガチガチ”に行う ということでもあり、逆に「プロセスがないと動けない チーム」になるリスクや「その”カタ”がハマらないリス ク」があった (実際にはそのリスクは発生しなかった)
経験則を積み想像を働かせる 「リスクをリストアップして評価する」というが、 そのこと自体が難しい、という意見もある それに対する解としては、以下の3点をオススメしたい ✓経験則を積み重ねる ✓事例をたくさん知る ✓想像力を働かせる プロジェクトの実践経験を多く積むことで勘所が見え てくる。とはいえ経験できる数にも限りがあるから、 様々な事例を見たり聞いたりした上で「自分だったらど うするか」という想像力を働かせると良いのではないか
品質についてずっと考え続ける プロジェクトにおいて担保すべき品質とは何か、その 品質が担保出来ないリスクは何で、その対応策は何か、 をずっと考え続ける ずっと考え続けるというのは、プロジェクトの企画・ 計画段階だけではなく、文字通りの意味でプロジェクト の実施期間中ずっと、という意味 次頁から挙げるような「品質リスクチェック リスト」を自分なりにつくって考え続けて いこう!
(おまけ)品質リスクチェックリスト プロジェクトの戦略の質は担保出来ているか?戦略が 曖昧で業務の優先順位が決まっていなかったり、メン バーのモチベーションが低下していたりしないか? 人間関係の質は担保出来ているか?心理的安全性が保 たれておらず「言いたいことが言えない」といったこと が起きてないか?改善マインドはあるか? チームの質は担保出来ているか?誰が何の役割と責任 を持っているか明確か?自己組織化したチームになって いるか?
(おまけ)品質リスクチェックリスト プロセスの質は担保出来ているか?これから実施する プロジェクトにおいてそのプロセスがうまく適用できる ことが確認できているか?単に「会社で決まっているか ら」という理由でやろうとしていないか? 人の質は担保出来ているか?もし担保出来ていないと したら、どのようなスキルを持った人がどれぐらい必要 で、どうやって確保するのか作戦はあるか?(採用する、 委託する、育成する、など)
(おまけ)品質リスクチェックリスト テストの質は担保出来そうか?テスト戦略やテスト計 画はきちんと決められているか?テストで発生した不具 合に対しては誰がどのように対応するのか?対応するた めのスケジュールの余裕はあるか? 製品の質は担保出来そうか?サービスやソリューショ ンの場合、その品質基準が曖昧になっていないか?SLA や契約などで決められているか?顧客やチームメンバー で共通認識が取れているか?
(おまけ)品質リスクチェックリスト 営業やマーケティングの質は担保出来ているか?営業 担当者は商材のメリット・デメリットを理解し顧客の質 問に答えられるようになっているか?マーケティング担 当者は適切なタッチポイント(Webサイト・展示会・ ウェビナー等)で適切な顧客に適切な手法で商材をPR出 来るようになっているか? 経営の質は担保出来ているか?新規商材に対する会社 としてのバックアップは万全か?不足点があればどんな ステークホルダーにどんな働きかけをすればよいか?
最後にメッセージ 品質リスクについて 考え続けることで 高品質の商材を 世に送り出そう!
Thank you for your attention!!