SlideShare une entreprise Scribd logo
1  sur  13
Télécharger pour lire hors ligne
Copyright © Software Research Associates, Inc. All Rights Reserved
株式会社 SRA
阪井 誠
プロセスモデルの補完方法
- モデル・ノウハウ・人 -
Copyright © Software Research Associates, Inc. All Rights Reserved
•SRAにて38年間技術者&研究者
•気になること
• プロセスモデリング
• 経験の活用
• 成長を促す方法
•具体的には
• 問題点の明確化・単純化
• Case-based reasoningの実践
• 経験で得た知識にインデックスを貼る
• 類似性・原理の発見、まねること
自己紹介と議論の種
Copyright © Software Research Associates, Inc. All Rights Reserved 2
同じプロセスモデル(標準)でも
うまくいく/いかない場合がある
•業務が違う=ノウハウが違う
•経験が違う=学んだことが違う
⇒モデルだけでなく、ノウハウや
人の成長を考慮しないといけない
背景(モチベーション)
Copyright © Software Research Associates, Inc. All Rights Reserved 3
プロセスモデル
•主たる課題の解決が目的で記述
• 考える、伝える、議論する
•プロセスを何らかの視点で整理
(単純化)したもの
•汎用性や粒度によって記述されない
開発ノウハウがあるのでは?
⇒アジャイル開発を例に考察した
Copyright © Software Research Associates, Inc. All Rights Reserved 4
西さんのツイート
仮説:
モデルに関係なく実現しないといけないことがあるが、
注目する問題点に対するモデル化を行ったのではないか
https://twitter.com/YasuharuNishi/status/1164336449967099904
Copyright © Software Research Associates, Inc. All Rights Reserved 5
モデルに関係ないが開発に必要なこと
例:リーダーシップについて
• ハンフリーはソフトウェア開発に「自律的なチーム」や
「その最大限の能力を最大限発揮できるようメンバーを動
機付け,コーチし,後押しする」ことが重要だとした
• W.ハンフリー,TSPガイドブックリーダー編
• 阪井, デブサミ運営事務局・SEshop.com編集部編,リーダーに求められる大切なこと,
100人のプロが選んだソフトウェア開発の名著, pp.20-21 , 翔泳社,
https://www.slideshare.net/MakotoSAKAI/ss-16581244, 2012
• スクラムではスクラムマスターがチームを支援する
奉仕者であり,真のリーダー
• Ken Schwaber, Jeff Sutherland, スクラムガイド,
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf,
ScrumGuides.org, 2020
Copyright © Software Research Associates, Inc. All Rights Reserved 6
アジャイルよろず相談室, 「ウォーターフォールでもしっかり開発出来ないのにアジャイル開発なんて出来るわけがない」
という言い方をどう思いますか?, https://qr.ae/pGLjdc, Quora, Inc.
Copyright © Software Research Associates, Inc. All Rights Reserved 7
プロセスモデルの移行
Copyright © Software Research Associates, Inc. All Rights Reserved 8
アジャイル開発モデルの例
•汎用&粒度大のモデル
•「現地現物」が実践できる
•タイムBOXの視点で整理
•単独チームの汎用モデル
• リスクの視点が弱い (廃棄された?)
例:複数チームなら「決定を遅らせる*」
ことも必要だが説明されることは少ない
*メアリー・ポッペンディーク, トム・ポッペンディーク,リーンソフトウェア開発,
pp.79-109, 日経BP社, 2004
Copyright © Software Research Associates, Inc. All Rights Reserved 9
• スクラムに対してマネジメントプロセスは制約の源泉として完全に適用
できるが,リスク/機会は制約として適用できるのは部分的とし,強い
リスク駆動とはされていない
※ プロダクトバックログの優先順位に応じてストーリを実現する仕組みだから
• バリー・ベーム,アジャイルと規律, pp.205-210, 日経BP社, 2004
• ジェフサザーランドは,プロダクトオーナー研修で
「PBLは価値最大,リスク最小で優先付け」と説明し
スクラムのモデルを補完するノウハウを示している
※このほかにも開発チームにおいては妨害リストが管理されるなど
ノウハウでプロセスモデルを補完してリスクが管理されるようになっている
• Sukusuku Scrum, スクラムプロジェクト準備(公開用) No.31,
https://www.slideshare.net/SukusukuScrum/ no31-13338313/41, p.41,
2012
• イテレーティブ開発を「はじめに小さく失敗する」と説明し,
あたかも全てのリスクが減るように表現されることもある
• リスクに関して記述の少ない書籍も多い
• 業務によって必要性が異なる(汎用ではない)からと考えられる
⇒モデルに組み込まれなかったノウハウは新たに確立しないといけない
アジャイル開発のリスクについて
Copyright © Software Research Associates, Inc. All Rights Reserved 10
プロセスモデルの移行(改)
単純にノウハウを
捨ててはいけない
取捨
選択
アドバイス
Copyright © Software Research Associates, Inc. All Rights Reserved 11
結論「ノウハウを共有しよう」
• 昔のSSは面白かった
• 現場の改善談がたくさん聞けた
• 業務や課題が近いとノウハウが流用できる
(例:組み込み、品質、etc.)
• CMMでQC活動の文化は消えたらしい
• 寂しいという話はよく聞いた
• アジャイルの普及で過去のノウハウが
消えてしまわないか心配
• モデルの議論だけでなく、
• 業務に合ったノウハウ
• 人の育て方(訓練?知識?知恵?)
を議論しよう!
Copyright © Software Research Associates, Inc. All Rights Reserved 12
プロセスモデルの補完方法
- モデル・ノウハウ・人 -
完

Contenu connexe

Similaire à プロセスモデルの補完方法 -モデル・ノウハウ・人-

非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門Kiro Harada
 
チケットの利用による経験を活かした開発の可能性
チケットの利用による経験を活かした開発の可能性 チケットの利用による経験を活かした開発の可能性
チケットの利用による経験を活かした開発の可能性 Makoto SAKAI
 
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティスアジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティスYasui Tsutomu
 
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンスGuildWorks
 
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス増田 亨
 
BPSttudy#84 アイデアをカタチにする方法
BPSttudy#84 アイデアをカタチにする方法BPSttudy#84 アイデアをカタチにする方法
BPSttudy#84 アイデアをカタチにする方法Haruo Sato
 
ハッカソンてなに?
ハッカソンてなに?ハッカソンてなに?
ハッカソンてなに?sonycsl
 
【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン 【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン Ryota Inaba
 
ETの開発現場で求められている人材像と育成方法
ETの開発現場で求められている人材像と育成方法ETの開発現場で求められている人材像と育成方法
ETの開発現場で求められている人材像と育成方法ESM SEC
 
AgileJapan 2017 ビジネスアジャイル 匠Methodとスクラム
AgileJapan 2017 ビジネスアジャイル  匠MethodとスクラムAgileJapan 2017 ビジネスアジャイル  匠Methodとスクラム
AgileJapan 2017 ビジネスアジャイル 匠MethodとスクラムHagimoto Junzo
 
情報システム部門の組織開発
 情報システム部門の組織開発 情報システム部門の組織開発
情報システム部門の組織開発Kazutaka Sankai
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門陽一 滝川
 
Careerworkshop 20121123
Careerworkshop 20121123Careerworkshop 20121123
Careerworkshop 20121123Kenji Okubo
 
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてAgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてShuji Morisaki
 
Odstudy 20120225 エンジニアのための提案力向上セミナー
Odstudy 20120225 エンジニアのための提案力向上セミナーOdstudy 20120225 エンジニアのための提案力向上セミナー
Odstudy 20120225 エンジニアのための提案力向上セミナーkumi_shiki
 
131102ちゅらシム・プレゼン
131102ちゅらシム・プレゼン131102ちゅらシム・プレゼン
131102ちゅらシム・プレゼンIkegami Keiichi
 
エンジニアとマネージャーは、いつも勝負をしているのだと思う
エンジニアとマネージャーは、いつも勝負をしているのだと思うエンジニアとマネージャーは、いつも勝負をしているのだと思う
エンジニアとマネージャーは、いつも勝負をしているのだと思うgree_tech
 

Similaire à プロセスモデルの補完方法 -モデル・ノウハウ・人- (20)

非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
 
チケットの利用による経験を活かした開発の可能性
チケットの利用による経験を活かした開発の可能性 チケットの利用による経験を活かした開発の可能性
チケットの利用による経験を活かした開発の可能性
 
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティスアジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティス
 
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス
 
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス
 
関西匠塾
関西匠塾関西匠塾
関西匠塾
 
BPSttudy#84 アイデアをカタチにする方法
BPSttudy#84 アイデアをカタチにする方法BPSttudy#84 アイデアをカタチにする方法
BPSttudy#84 アイデアをカタチにする方法
 
ハッカソンてなに?
ハッカソンてなに?ハッカソンてなに?
ハッカソンてなに?
 
Xp2
Xp2Xp2
Xp2
 
To be sn agile enterprise
To be sn agile enterpriseTo be sn agile enterprise
To be sn agile enterprise
 
【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン 【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン
 
ETの開発現場で求められている人材像と育成方法
ETの開発現場で求められている人材像と育成方法ETの開発現場で求められている人材像と育成方法
ETの開発現場で求められている人材像と育成方法
 
AgileJapan 2017 ビジネスアジャイル 匠Methodとスクラム
AgileJapan 2017 ビジネスアジャイル  匠MethodとスクラムAgileJapan 2017 ビジネスアジャイル  匠Methodとスクラム
AgileJapan 2017 ビジネスアジャイル 匠Methodとスクラム
 
情報システム部門の組織開発
 情報システム部門の組織開発 情報システム部門の組織開発
情報システム部門の組織開発
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
 
Careerworkshop 20121123
Careerworkshop 20121123Careerworkshop 20121123
Careerworkshop 20121123
 
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてAgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
 
Odstudy 20120225 エンジニアのための提案力向上セミナー
Odstudy 20120225 エンジニアのための提案力向上セミナーOdstudy 20120225 エンジニアのための提案力向上セミナー
Odstudy 20120225 エンジニアのための提案力向上セミナー
 
131102ちゅらシム・プレゼン
131102ちゅらシム・プレゼン131102ちゅらシム・プレゼン
131102ちゅらシム・プレゼン
 
エンジニアとマネージャーは、いつも勝負をしているのだと思う
エンジニアとマネージャーは、いつも勝負をしているのだと思うエンジニアとマネージャーは、いつも勝負をしているのだと思う
エンジニアとマネージャーは、いつも勝負をしているのだと思う
 

Plus de Makoto SAKAI

SQiP20222投稿応援フォーラム「開発現場で役立つ論文の書き方のお話」
SQiP20222投稿応援フォーラム「開発現場で役立つ論文の書き方のお話」SQiP20222投稿応援フォーラム「開発現場で役立つ論文の書き方のお話」
SQiP20222投稿応援フォーラム「開発現場で役立つ論文の書き方のお話」Makoto SAKAI
 
メールやチャットでも役立つテクニック
メールやチャットでも役立つテクニックメールやチャットでも役立つテクニック
メールやチャットでも役立つテクニックMakoto SAKAI
 
改訂版:開発現場で役立つ論文の書き方のお話
改訂版:開発現場で役立つ論文の書き方のお話改訂版:開発現場で役立つ論文の書き方のお話
改訂版:開発現場で役立つ論文の書き方のお話Makoto SAKAI
 
(講演資料)開発現場で役立つ論文の書き方のお話
(講演資料)開発現場で役立つ論文の書き方のお話(講演資料)開発現場で役立つ論文の書き方のお話
(講演資料)開発現場で役立つ論文の書き方のお話Makoto SAKAI
 
論理的思考力を身に着けるための論文研修
論理的思考力を身に着けるための論文研修論理的思考力を身に着けるための論文研修
論理的思考力を身に着けるための論文研修Makoto SAKAI
 
SS2019 エッジデバイス開発の難しさ
SS2019 エッジデバイス開発の難しさSS2019 エッジデバイス開発の難しさ
SS2019 エッジデバイス開発の難しさMakoto SAKAI
 
[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?Makoto SAKAI
 
スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会
スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会
スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会Makoto SAKAI
 
新技術で未来の扉を開け! - Node-REDの環境構築と社内導入 -
新技術で未来の扉を開け! - Node-REDの環境構築と社内導入 - 新技術で未来の扉を開け! - Node-REDの環境構築と社内導入 -
新技術で未来の扉を開け! - Node-REDの環境構築と社内導入 - Makoto SAKAI
 
Node-RED導入時の効果的な開発を考える
Node-RED導入時の効果的な開発を考えるNode-RED導入時の効果的な開発を考える
Node-RED導入時の効果的な開発を考えるMakoto SAKAI
 
プロのためのNode-RED再入門
プロのためのNode-RED再入門プロのためのNode-RED再入門
プロのためのNode-RED再入門Makoto SAKAI
 
Node-redでプロトタイピング
Node-redでプロトタイピングNode-redでプロトタイピング
Node-redでプロトタイピングMakoto SAKAI
 
プロジェクトを成功させるチケット管理
プロジェクトを成功させるチケット管理プロジェクトを成功させるチケット管理
プロジェクトを成功させるチケット管理Makoto SAKAI
 
Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点
Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点
Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点Makoto SAKAI
 
Node-REDから見えた未来 - 変わるもの、変わらないもの -
Node-REDから見えた未来 - 変わるもの、変わらないもの -Node-REDから見えた未来 - 変わるもの、変わらないもの -
Node-REDから見えた未来 - 変わるもの、変わらないもの -Makoto SAKAI
 
複合主キーの扱い方
複合主キーの扱い方複合主キーの扱い方
複合主キーの扱い方Makoto SAKAI
 
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発Makoto SAKAI
 
効果的な XP の導入を目的としたプラクティス間の相互作用の分析
効果的な XP の導入を目的としたプラクティス間の相互作用の分析効果的な XP の導入を目的としたプラクティス間の相互作用の分析
効果的な XP の導入を目的としたプラクティス間の相互作用の分析Makoto SAKAI
 
社会人のためのシンポジウム発表入門 リーン論文作法
社会人のためのシンポジウム発表入門   リーン論文作法社会人のためのシンポジウム発表入門   リーン論文作法
社会人のためのシンポジウム発表入門 リーン論文作法Makoto SAKAI
 
パネル:Redmineの未来を考える
パネル:Redmineの未来を考えるパネル:Redmineの未来を考える
パネル:Redmineの未来を考えるMakoto SAKAI
 

Plus de Makoto SAKAI (20)

SQiP20222投稿応援フォーラム「開発現場で役立つ論文の書き方のお話」
SQiP20222投稿応援フォーラム「開発現場で役立つ論文の書き方のお話」SQiP20222投稿応援フォーラム「開発現場で役立つ論文の書き方のお話」
SQiP20222投稿応援フォーラム「開発現場で役立つ論文の書き方のお話」
 
メールやチャットでも役立つテクニック
メールやチャットでも役立つテクニックメールやチャットでも役立つテクニック
メールやチャットでも役立つテクニック
 
改訂版:開発現場で役立つ論文の書き方のお話
改訂版:開発現場で役立つ論文の書き方のお話改訂版:開発現場で役立つ論文の書き方のお話
改訂版:開発現場で役立つ論文の書き方のお話
 
(講演資料)開発現場で役立つ論文の書き方のお話
(講演資料)開発現場で役立つ論文の書き方のお話(講演資料)開発現場で役立つ論文の書き方のお話
(講演資料)開発現場で役立つ論文の書き方のお話
 
論理的思考力を身に着けるための論文研修
論理的思考力を身に着けるための論文研修論理的思考力を身に着けるための論文研修
論理的思考力を身に着けるための論文研修
 
SS2019 エッジデバイス開発の難しさ
SS2019 エッジデバイス開発の難しさSS2019 エッジデバイス開発の難しさ
SS2019 エッジデバイス開発の難しさ
 
[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?
 
スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会
スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会
スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会
 
新技術で未来の扉を開け! - Node-REDの環境構築と社内導入 -
新技術で未来の扉を開け! - Node-REDの環境構築と社内導入 - 新技術で未来の扉を開け! - Node-REDの環境構築と社内導入 -
新技術で未来の扉を開け! - Node-REDの環境構築と社内導入 -
 
Node-RED導入時の効果的な開発を考える
Node-RED導入時の効果的な開発を考えるNode-RED導入時の効果的な開発を考える
Node-RED導入時の効果的な開発を考える
 
プロのためのNode-RED再入門
プロのためのNode-RED再入門プロのためのNode-RED再入門
プロのためのNode-RED再入門
 
Node-redでプロトタイピング
Node-redでプロトタイピングNode-redでプロトタイピング
Node-redでプロトタイピング
 
プロジェクトを成功させるチケット管理
プロジェクトを成功させるチケット管理プロジェクトを成功させるチケット管理
プロジェクトを成功させるチケット管理
 
Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点
Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点
Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点
 
Node-REDから見えた未来 - 変わるもの、変わらないもの -
Node-REDから見えた未来 - 変わるもの、変わらないもの -Node-REDから見えた未来 - 変わるもの、変わらないもの -
Node-REDから見えた未来 - 変わるもの、変わらないもの -
 
複合主キーの扱い方
複合主キーの扱い方複合主キーの扱い方
複合主キーの扱い方
 
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
 
効果的な XP の導入を目的としたプラクティス間の相互作用の分析
効果的な XP の導入を目的としたプラクティス間の相互作用の分析効果的な XP の導入を目的としたプラクティス間の相互作用の分析
効果的な XP の導入を目的としたプラクティス間の相互作用の分析
 
社会人のためのシンポジウム発表入門 リーン論文作法
社会人のためのシンポジウム発表入門   リーン論文作法社会人のためのシンポジウム発表入門   リーン論文作法
社会人のためのシンポジウム発表入門 リーン論文作法
 
パネル:Redmineの未来を考える
パネル:Redmineの未来を考えるパネル:Redmineの未来を考える
パネル:Redmineの未来を考える
 

プロセスモデルの補完方法 -モデル・ノウハウ・人-

  • 1. Copyright © Software Research Associates, Inc. All Rights Reserved 株式会社 SRA 阪井 誠 プロセスモデルの補完方法 - モデル・ノウハウ・人 -
  • 2. Copyright © Software Research Associates, Inc. All Rights Reserved •SRAにて38年間技術者&研究者 •気になること • プロセスモデリング • 経験の活用 • 成長を促す方法 •具体的には • 問題点の明確化・単純化 • Case-based reasoningの実践 • 経験で得た知識にインデックスを貼る • 類似性・原理の発見、まねること 自己紹介と議論の種
  • 3. Copyright © Software Research Associates, Inc. All Rights Reserved 2 同じプロセスモデル(標準)でも うまくいく/いかない場合がある •業務が違う=ノウハウが違う •経験が違う=学んだことが違う ⇒モデルだけでなく、ノウハウや 人の成長を考慮しないといけない 背景(モチベーション)
  • 4. Copyright © Software Research Associates, Inc. All Rights Reserved 3 プロセスモデル •主たる課題の解決が目的で記述 • 考える、伝える、議論する •プロセスを何らかの視点で整理 (単純化)したもの •汎用性や粒度によって記述されない 開発ノウハウがあるのでは? ⇒アジャイル開発を例に考察した
  • 5. Copyright © Software Research Associates, Inc. All Rights Reserved 4 西さんのツイート 仮説: モデルに関係なく実現しないといけないことがあるが、 注目する問題点に対するモデル化を行ったのではないか https://twitter.com/YasuharuNishi/status/1164336449967099904
  • 6. Copyright © Software Research Associates, Inc. All Rights Reserved 5 モデルに関係ないが開発に必要なこと 例:リーダーシップについて • ハンフリーはソフトウェア開発に「自律的なチーム」や 「その最大限の能力を最大限発揮できるようメンバーを動 機付け,コーチし,後押しする」ことが重要だとした • W.ハンフリー,TSPガイドブックリーダー編 • 阪井, デブサミ運営事務局・SEshop.com編集部編,リーダーに求められる大切なこと, 100人のプロが選んだソフトウェア開発の名著, pp.20-21 , 翔泳社, https://www.slideshare.net/MakotoSAKAI/ss-16581244, 2012 • スクラムではスクラムマスターがチームを支援する 奉仕者であり,真のリーダー • Ken Schwaber, Jeff Sutherland, スクラムガイド, https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf, ScrumGuides.org, 2020
  • 7. Copyright © Software Research Associates, Inc. All Rights Reserved 6 アジャイルよろず相談室, 「ウォーターフォールでもしっかり開発出来ないのにアジャイル開発なんて出来るわけがない」 という言い方をどう思いますか?, https://qr.ae/pGLjdc, Quora, Inc.
  • 8. Copyright © Software Research Associates, Inc. All Rights Reserved 7 プロセスモデルの移行
  • 9. Copyright © Software Research Associates, Inc. All Rights Reserved 8 アジャイル開発モデルの例 •汎用&粒度大のモデル •「現地現物」が実践できる •タイムBOXの視点で整理 •単独チームの汎用モデル • リスクの視点が弱い (廃棄された?) 例:複数チームなら「決定を遅らせる*」 ことも必要だが説明されることは少ない *メアリー・ポッペンディーク, トム・ポッペンディーク,リーンソフトウェア開発, pp.79-109, 日経BP社, 2004
  • 10. Copyright © Software Research Associates, Inc. All Rights Reserved 9 • スクラムに対してマネジメントプロセスは制約の源泉として完全に適用 できるが,リスク/機会は制約として適用できるのは部分的とし,強い リスク駆動とはされていない ※ プロダクトバックログの優先順位に応じてストーリを実現する仕組みだから • バリー・ベーム,アジャイルと規律, pp.205-210, 日経BP社, 2004 • ジェフサザーランドは,プロダクトオーナー研修で 「PBLは価値最大,リスク最小で優先付け」と説明し スクラムのモデルを補完するノウハウを示している ※このほかにも開発チームにおいては妨害リストが管理されるなど ノウハウでプロセスモデルを補完してリスクが管理されるようになっている • Sukusuku Scrum, スクラムプロジェクト準備(公開用) No.31, https://www.slideshare.net/SukusukuScrum/ no31-13338313/41, p.41, 2012 • イテレーティブ開発を「はじめに小さく失敗する」と説明し, あたかも全てのリスクが減るように表現されることもある • リスクに関して記述の少ない書籍も多い • 業務によって必要性が異なる(汎用ではない)からと考えられる ⇒モデルに組み込まれなかったノウハウは新たに確立しないといけない アジャイル開発のリスクについて
  • 11. Copyright © Software Research Associates, Inc. All Rights Reserved 10 プロセスモデルの移行(改) 単純にノウハウを 捨ててはいけない 取捨 選択 アドバイス
  • 12. Copyright © Software Research Associates, Inc. All Rights Reserved 11 結論「ノウハウを共有しよう」 • 昔のSSは面白かった • 現場の改善談がたくさん聞けた • 業務や課題が近いとノウハウが流用できる (例:組み込み、品質、etc.) • CMMでQC活動の文化は消えたらしい • 寂しいという話はよく聞いた • アジャイルの普及で過去のノウハウが 消えてしまわないか心配 • モデルの議論だけでなく、 • 業務に合ったノウハウ • 人の育て方(訓練?知識?知恵?) を議論しよう!
  • 13. Copyright © Software Research Associates, Inc. All Rights Reserved 12 プロセスモデルの補完方法 - モデル・ノウハウ・人 - 完