Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アジャイル開発お悩み相談会_vol.4_Q&A
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
SHIFT EVOLVE
PRO
January 24, 2024
Technology
0
180
アジャイル開発お悩み相談会_vol.4_Q&A
2024/1/24に開催したアジャイル開発お悩み相談会でいただいた質問と回答資料です
SHIFT EVOLVE
PRO
January 24, 2024
Tweet
Share
More Decks by SHIFT EVOLVE
See All by SHIFT EVOLVE
私たち準委任PdEは2つのプロダクトに挑戦する ~ソフトウェア、開発支援という”二重”のプロダクトエンジニアリングの実践~ / 20260212 Naoki Takahashi
shift_evolve
PRO
2
210
茨城の思い出を振り返る ~CDKのセキュリティを添えて~ / 20260201 Mitsutoshi Matsuo
shift_evolve
PRO
1
410
初めてのJAWSボランティア活動目録 ~JAWS DAYS 2025~ / 20260131 Mitsutoshi Matsuo
shift_evolve
PRO
0
89
長期実行 AI エージェントの最新の実装標準を知ろう! / 20260128 Ikuma Yamashita
shift_evolve
PRO
1
78
ファシリテーション勉強中 その場に何が求められるかを考えるようになるまで / 20260123 Naoki Takahashi
shift_evolve
PRO
3
750
AWSネイティブサービス&AIサービスで自社で内製化するAWSセキュリティのPDCAサイクル / 20260117 Hironobu Otaki
shift_evolve
PRO
1
110
1万人を変え日本を変える!!多層構造型ふりかえりの大規模組織変革 / 20260108 Kazuki Mori
shift_evolve
PRO
7
2.1k
あの夜、私たちは「人間」に戻った。 ── 災害ユートピア、贈与、そしてアジャイルの再構築 / 20260108 Hiromitsu Akiba
shift_evolve
PRO
0
1.1k
Cloud WAN MCP Serverから考える新しいネットワーク運用 / 20251228 Masaki Okuda
shift_evolve
PRO
0
170
Other Decks in Technology
See All in Technology
StrandsとNeptuneを使ってナレッジグラフを構築する
yakumo
1
130
コスト削減から「セキュリティと利便性」を担うプラットフォームへ
sansantech
PRO
3
1.6k
生成AIを活用した音声文字起こしシステムの2つの構築パターンについて
miu_crescent
PRO
3
220
【Ubie】AIを活用した広告アセット「爆速」生成事例 | AI_Ops_Community_Vol.2
yoshiki_0316
1
120
pool.ntp.orgに ⾃宅サーバーで 参加してみたら...
tanyorg
0
1.1k
猫でもわかるKiro CLI(セキュリティ編)
kentapapa
0
110
Claude Code for NOT Programming
kawaguti
PRO
1
100
SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント
rvirus0817
0
350
ブロックテーマ、WordPress でウェブサイトをつくるということ / 2026.02.07 Gifu WordPress Meetup
torounit
0
200
登壇駆動学習のすすめ — CfPのネタの見つけ方と書くときに意識していること
bicstone
3
130
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
93k
制約が導く迷わない設計 〜 信頼性と運用性を両立するマイナンバー管理システムの実践 〜
bwkw
3
1.1k
Featured
See All Featured
Game over? The fight for quality and originality in the time of robots
wayneb77
1
120
The Invisible Side of Design
smashingmag
302
51k
The Language of Interfaces
destraynor
162
26k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
60
42k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
170
Rails Girls Zürich Keynote
gr2m
96
14k
Balancing Empowerment & Direction
lara
5
900
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
350
Principles of Awesome APIs and How to Build Them.
keavy
128
17k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
0
150
Reality Check: Gamification 10 Years Later
codingconduct
0
2k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Transcript
当日出た質問 アジャイル開発 全般についての 感じている課題 があればご記載 ください 2024/01/24 ~PO 問題どうしてる?~ 回答
アジャイル開発のガイド ライン( アジャイルガイド など) に、どの程度従うべ きなのでしょうか? スクラムガイドのことでしょうか。ス クラムガイドに書いてあること(スク ラムのフレームワーク)はすべて導入 しないと本来の効果は得られません。 外れる場合は、デメリットを理解した 上で実施する必要あります。 アジャイルの管理方法は使っているが、やっていること はWF のようなプロジェクトにしか参加したことが無い。 アジャイルをそもそもどのような時に導入するか、WF と 比べた利点は何かを理解しないまま運用を始めるプロジ ェクトが多いのかと思っていますが、アジャイルの経験 豊富な方からはどうやったらアジャイル開発がうまくい くのかなどの前提条件やどの層まで意識させるか等はご ざいますか? なぜWF ではなくアジャイル開 発をするのかの理由、目的を明確にして合意す るのが第一歩です。 また、アジャイル開発をスムーズに導入するに は組織の理解(今までにやり方を変える)が必 要なので、社内のルールを変える権限がる層ま で理解してもらう必要があります。 先ずはそのままやってみるのがいいと 思います。そのまま実施することによ ってスクラムの透明性、検査、適用が 出来てくるので1 つのイベントを実施 しなかったりすると何かが欠けます。 従えないものがあるのであれば、 それがどういう影響を及ぼすのかを 考えないとアジャイルを導入する メリットが失われる可能性が高いです。 最低限の軽量フレームワークですので、こ れができないとそもそも何もルール化、仕 組化できないになってしまうと思います。 現場でアジャイルやりたいぜーに なっても、予算や権限の問題から、 なかなか実現できないのが現状で、 上位層の理解を得る必要があります。 小さいプロジェクト、社内ツールなどで 効果を確認できるようなものから 始めるとよいです 変化の大きそうなプロダクトなどはアジャイルに向いて いると思いますが本当にアジャイルで実施するのかどん なメリットがあるのか検討が必要だと思います。 アジャイル開発が上手くいく前提条件としてはプロジェ クトに対しての決定権がある層までにアジャイル開発の 考え方を理解していただく必要があると思います。 デイリースクラムがた だの進捗報告会になり がちなのが悩みです。 よくある3 つの質問をやっていると 進捗報告会になりがちです。 あとSM がひたすら仕切るとSM への進捗報告になりがち です 開発チームがお互いで困っていること、今話をしないと いけないことを うまく引き出すようにSM がファシリできれば。 アイスブレイクも効果的 スプリントゴールが達成できそうか。 スプリントレビューで価値が見せるこ とが出来そうか を確認するといいかなと思います。 PO に対して実 際に行ったア クション・プ ラクティス ファイブフィンガー PBI の内容があまりDEV に伝わ らなかった。 →PO に対して書き方の指導。 PO とDEV 集めて会議してすり 合わせ。 PO の上にモンスター ステークホルダーが おり、PO の存在感が 薄まってしまってい ます。どう対処した ら良いでしょうか? PO に対して、DEV から 疑問質問が出てきたら 回答するように意識付 けをした 具体的にもう少し どこに困っている かをいただけると 回答も解像度があ がります! PO はWhat、DEV はHow を 徹底するように意識付け。 ※ つまりPO は作り方まで口 を出さないように 全部やりたい! リリースまで1 年以 上かかる開発をやりたい! というP O に対して、できれば小さくリリ ースしていくことを伝えたいなと 考えています( 検査適応サイクルが 回せないので) その際、どのようなことを話した り、どのような切り口から話しま すか? 2 つ。1 つ目はステークホルダーをPO とす る、2 つ目は権限を委譲する。 上記は最終で、まずはステークホルダーが 何をどこまで望んでいるのか?を会話する (※ 例えばしっかり進捗を把握できればい いのか、など) 簡単に腹を割って話 せないような、モン スターステークホル ダーの場合には、ど のようにすれば良い でしょうか? アカマネとか、偉い人 にアプローチできる偉 い人を仲間にして攻略 していく! 要求を出してもらうところを スプリントレビューの場だけ にしてもらうなど、絞っても らうようにしていく。 モンスター=スケジュールを 圧迫するような人? ともあれ、どうにかして「味 方につける」というのが大切 スプリント毎にとどく価値を 作るのがアジャイルですよね 、そうじゃないとアジャイル でやる意味ないよね、とひた すら伝える 1 年後、ほんとに今 考えてるの価値ある ?とひたすら伝える ビジネスとして1 年後成り立つ? 作ることが大切であればWF でもいい のかもしれない。早くFB もらいたい のであればアジャイルかもしれない。 どうしてアジャイルでやりたいのか、 をしっかりと会話することが大切では ないか。 (佐々木から の質問)アジ ャイルでやる 意味って? ステークホルダーやPO から プロダクトで実現したい要 件要求がすべて出てこず、 プロダクトのあるべき姿を 理解して提案しろと言われ ています。 誰に対してどのように動く べきでしょうか? アジャイルを「銀の弾 丸」と考えているのか もしれない、、、これ はまずい アジャイルのプロセス に納得(理解)してい ないのかもしれない SM の場合:PO に一緒に考 えましょうよ!と会話する 。どういう方向にもってい きたいですかー?など どういうポジョションにいる人? DEV の場合:プロトタイプつくってこんな かんじ?と言っていく? 出てる部分で作 ってみました。こんな感じでいかがでしょ うか? ※ プロトタイプってどれぐらい時間かける イメージ?→1 ~2 日ぐらい 今の現場でスクラ ムマスターがPO の タスクをやってい るように感じてい て、兼任はかのう ですか? SM の場合:要件はある と思うので、出てくる ものに対して優先度つ けろ!という DEV の場合:・・・ (いけてない場合=成 熟度が低い)ブリッジP O 的な人を準備して、そ の人が要件をまとめる (いけてる場合=成熟度高い )PO が方向性だけ示す。DEV が何を作るかまで考え実現し ていくことで全体のスピード があがる PO とSM の兼任はダメ! 絶対ダメ!(アジャイ ルにならない気がする ) 多くの開発では、守るべき期日の デッドラインがあると思います。 最低限どこまでリリースできるか 、PO 的には知りたいケースに何回 か遭遇してきました。( ステークホ ルダーに現時点での想定を伝える ため) その際の見積もり、どのように行 っていますか? なぜ? → 何をやっているかわからなくなって くる・・・(体験談) これ正しいの? チームが成立してい る? あたりが怪しくなってきた。 基本的にはバッドプラクティス。かつかつじゃなければ出来るかも ね。 PO がアクセル、SM がブレーキ、いい意味でのせめぎ合いをやるた めにも同じ人だとできないから。限られたリソースで最大限の価値 をだすことを考えたら兼任無理だよね。 あとPO しっかりやろうとするとやること多くて兼任している場合じ ゃない。 ベロシティをみて、PBI の数値 から計算。 今時点の想定です。Must とし ては言えないです、という。 単年度で入札となる案件で あり、どうしてもステーク ホルダーやPO の方が立場的 に強い関係になってしまっ ています。 対等な関係を築くためには どうしたら良いでしょうか? チームの成熟度によって変わりそう。ベロ シティが安定しているなら「これでいけま す!」でOK 安定していないのであればリスクがある、 ここまでは出来ると思うんですけど、、、 とリスク込みで伝える。 実績ベースで、「常に」「 早く」伝える。そうするこ とで想定通りにならなそう でも打ち手が増える。 どうPO を支援していくか難 しいです。PO もステークホ ルダーとの関係があるので 、あまりあやふやには言え ないケースなどもあるので 、どのような武器や情報を 伝えればよいのか... ・・・ プロダクトのことを考えて、こっちも 強気で! 少なくとも下手にでるのは 違う。同じチームなんだから。 一緒に飲みにいく、とかw そもそもアジャイルでやるべきじゃな いかもしれない。 WF だと上下あってよい・・・?→ 請 負という意味ではそうかもしれないが 。 プロダクトの価値とかを上手 にステークホルダーに見せれ れば・・・ スプリントレビ ューでうまく見せるとか。 ステークホルダ ーと同じ目線を もててないから ちゃうか 早く、真実を、伝える。 DEV から見た場合、PO が嘘でもいいから こうだ!と言い切ってほしい。 PO はステークホルダー調整大変なので、D EV にいかないように防波堤になる!(そ のうえでバックログをちゃんと並べる) ※ だからこそPO は大変、、、