Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
アジリティを目指した先にあった真のパートナーシップ
Search
Recruit
PRO
November 15, 2022
Technology
1k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
アジリティを目指した先にあった真のパートナーシップ
2022/11/15_Agile Japan 2022での講演資料になります
Recruit
PRO
November 15, 2022
More Decks by Recruit
See All by Recruit
局所最適は悪ではない。壊れているのは指標です。量と質を同時に見る先行指標の設計
recruitengineers
PRO
3
1.4k
実体験から学ぶ分析エージェントの開発と運⽤
recruitengineers
PRO
9
2.7k
大規模フロントエンド開発におけるmonorepoという選択肢
recruitengineers
PRO
2
130
自律型 AI をセキュアに実装!Gemini と MIG で作る動的コード実行環境
recruitengineers
PRO
1
340
Google Cloud Next Tokyo 26登壇時のスクリプト
recruitengineers
PRO
0
360
つくって納得、つかって実感! 大規模言語モデルことはじめ ver2.0
recruitengineers
PRO
6
3.1k
ブラウザ研修 2026
recruitengineers
PRO
8
2.2k
事業価値と Engineering 2026年度版
recruitengineers
PRO
60
31k
トヨタ⽣産⽅式(TPS)⼊⾨
recruitengineers
PRO
3
1.5k
Other Decks in Technology
See All in Technology
kintoneで在庫管理システムを作るときの要件定義・設計ポイント
kai0707
0
230
AI Agent 時代のデータ基盤: ClickHouse で実現する 超高速分析とコスト削減の両立
jozono
0
120
200人の配信コメント、 全部Jevが仕分けます 〜 マサカリガードを作ってみた 〜
katayamatg
1
530
Patterns in AI Driven Software Development
akosma
PRO
0
470
[General] 개발자로 해외 기업에서 일하기
skydoves
1
290
E2Eってつらくないですか?E2Eの管理コストを下げる手段とその実践
akaboshinit
6
3k
AI Search (Foundry IQ) におけるRAGデータの準備と配置
ryomaru0825
1
140
AI時代、つくる力を自分たちの手に。 ──電通×KAG、アジャイルとAI駆動開発で挑む開発の変革
yuukiyo
3
460
"AWSはちょっと苦手"でも大丈夫。AWS Blocks で手軽に作る Flutter のバックエンド #FlutterKaigi
tacck
PRO
0
130
(swiftc) NonCopyableとライフタイム修飾子
teamhimeh
0
170
FinOpsを導入してマルチプロダクトのコスト最適化を実現する
kworkdev
PRO
0
120
AIエージェント統制はAPIから——押さえるべき5つの要素
nagix
0
120
Featured
See All Featured
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
870
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
610
[RailsConf 2023] Rails as a piece of cake
palkan
59
7.1k
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
2
6.4k
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
670
The untapped power of vector embeddings
frankvandijk
2
2k
Bash Introduction
62gerente
615
220k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
520
Build your cross-platform service in a week with App Engine
jlugia
234
19k
Designing Experiences People Love
moore
143
24k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
7k
Agile that works and the tools we love
rasmusluckow
331
22k
Transcript
アジリティを目指した先にあった 真のパートナーシップ
自己紹介 藤田健人 高橋陽太郎
本日は「協調」について話します。それは我々にとっては「目線を合わせる」 ことでした。簡単そうですが目線が合うまで4年を要しました
フロントエンド開発 チーム(スクラム) バックエンド開発チー ム(スクラム) 企画チーム 2week sprint 2week sprint 企画ができても次の
スプリントまで待ち 2日でフロントエンド開 発が終わってもバック エンドチームの次の スプリントまで待ち 最短で4日でできる案件でも1ヶ月以上かかってしまう状態 (でもみんな「全力で頑張っている」) これは正しい状態なのだろうか?という違和感 たとえば、『タウンワーク』のUI/UXの改善チームでは、早期にスクラムを導入してい たものの、「違和感」がありました
この違和感は、ふりかえると4つのレイヤーで整理することができます。本日はこ のレイヤーに沿って話を進めます 目的 要求 要件 実装 ビジネスゴールやアウトカムと言われるも の。何かの要求をする際の背景となるも の。 ビジネスゴールを実現するためにどのよう
な考え方、戦略を取るか。 要求を実現する上での進め方、取り組み 方、開発プロセス (例)スクラム、カンバン、ウォーターフォー ル コーディングやテストなどの実際にインクリ メントを増やす活動 スクラム 要求は4日? 1ヶ月でOK? ?????? なにやら あやふや はっきりしてい る
最初は、リクルートとNTTデータでも全く異なる目線でした。 目的 要求 要件 実装 リクルート目線 NTTデータ目線 目的 要求 要件
実装 目的 要求 要件 実装 (あんまりよくわ かってないけど) 早くやりたい スクラムで スクラムで 毎月リリースした い
活動をふりかえると、大事なステップが3つありました。 目的 要求 要件 実装 リクルート目線 NTTデータ目線 目的 要求 要件
実装 目的 要求 要件 実装 ステップ①:目的・要求を明確化し 言語化する ステップ②:明確化した目的・要求 を理解する ステップ③:全員が 理解できる状態を 作る
『タウンワーク』は、仕事探しのより良いユーザー体験を提供していくことが目的です。それ は、年間のユーザーアクション数を最大化する必要があることを意味します リボン図
ユーザのアクションを最大化させるために、開発プロセスによって貢献で きる事は何か?を考えます。 価値 期間 ユーザ体験の向上によって 得られるアクション数 開発期間 開発期間が短くて、リリース後の期間が伸びるほど、 ユーザ体験の向上期間が伸びる。 →アクション数が増える
「もしも仮に、選ぶとしたらAとBは、どちらでしょうか?」を言語化し、明 示します 開発プロセスに対するビジネス要求: 同期間の開発量 < 同期間のユーザ体験が生む価値の総量 の優先度が高い。 価値 期間 価値 期間 同じ期間に多くの機能を出すこと よりも 同じ期間に生まれる価値総量
をとる A:一気に開発 B:コツコツ開発
ステップ②は明確化した目的・要求の理解するステップです 目的 要求 要件 実装 リクルート目線 NTTデータ目線 目的 要求 要件
実装 目的 要求 要件 実装 ステップ②:明確化した目的・要求 を理解する NTTデータ側の先頭にたち全員が理解するために 自身が正しく理解する必要がありました ステップ①:クリア
きちんと理解しようと資料を追いかけても、資料化されている知識を追 うだけでも膨大な分量でした
正しく理解するために 膨大な資料の咀嚼を、二人で時間をかけてディスカッションを重ねました 長い時間をかけて正しく理解 ディスカッションする過程で重要な気付きがありました
大切なことに気が付きました 目的定義 要求定義 要件定義 設計、製造、試験、リリー ス 開発案件の工程 目的 要求 要件
実装 プロセスの工程 開発案件を開発する時は、ビ ジネス目的、要求を理解した 上で、最適なシステム要件を 選択していくのに・・・ 開発プロセスにも目的と要求 があり、それを理解しなけれ ば最適な要件、実装にならな い、という当たり前なことが抜 けていた なんのためのアジャイルか?が抜けていました
目的 要求 要件 実装 リクルート目線 NTTデータ目線 目的 要求 要件 実装
目的 要求 要件 実装 ステップ③:全員が 理解できる状態を 作る ステップ③は全員が理解できる状態を作ることです ステップ②:クリア ステップ①:クリア
目的、要求、要件の理解のために 知識 目的、要求をインプットする メンバーのチームや目線もそれぞれ異なる。それぞれの目線から見える現状と照らし 合わせ、最適な要件(=開発プロセス)を自分たちで考えていく。 自ら考えることで、目的、要求、要件が正しく伝搬
「自分たちで考えた」ことを実践し、くりかえします 実装 適用 実際にプロセスを回しながら、改善をくりかえすことで プロセス要件は、概念レベルから自分たちのプロセスに 要件 学び 疑問 くりかえし くりかえし
改善 改善
例 カンバン方式(要件)でやっているけ ど、さらに開発リードタイム短縮(要 求)するためにどうしたらいいだろ う? テスト工程で故障が結構出てます ねー。フロントエンドとバックエンドの 認識齟齬のところが結構あります ね。 じゃあ設計段階でフロントエンドと
バックエンドで設計の認識合わせを やろう。さらにペアプロも考えるか ・・・ プロセス要求、要件、実装の繋がりを考えながら実装に組み込むことで チームに最適化したプロセスとなる
目的 要求 要件 実装 目的 要求 要件 実装 目的 要求
要件 実装 リクルート目線 NTTデータ目線 3ステップを通して、ようやく「目線を合わせる」ことができました。 ステップ①:目的・要求を明確化し 言語化する ステップ②:明確化した目的・要求 を理解する ステップ③:全員が 理解できる状態を 作る
目的 要求 要件 実装 リクルート目線 NTTデータ目線 目的 要求 要件 実装
目的 要求 要件 実装 ふりかえって反省すると、リクルート目線では目的・要求が不明確なのに、「アジャイルで」とい う要件をお願いしてしまっていました 【大反省】 ビジネスゴールも不明確 で、それを実現するための 要求もわかっていないが、 「アジャイルでという要件」 をお願いしてしまっていた
目的 要求 要件 実装 リクルート目線 NTTデータ目線 目的 要求 要件 実装
目的 要求 要件 実装 NTTデータ目線では、目的・要求が不明確にも関わらず、それを鵜呑みにしてしまったこ とが反省点でした 「アジャイルでやること」が 暗黙的なゴールになってし まっていた
目的 要求 要件 実装 目的 要求 要件 実装 目的 要求
要件 実装 リクルート目線 NTTデータ目線 目的・要求が不明確で、要件定義がグダグダになる。システム開発あるあるが、我々のプロセス設計に おいても起きてしまっていました( 4レイヤーの命名の由来) 「アジャイルでやること」が 暗黙的なゴールになってし まっていた 【大反省】 ビジネスゴールも不明確 で、それを実現するための 要求もわかっていないが、 「アジャイルでという要件」 をお願いしてしまっていた
良いコードを書くためには、「なぜ?この機能を作るのか」を常に重視して います。 それは、開発プロセスにおいても同じでした。 「なぜ?このプロセスを採用するのか」が分からない状態でプロセス構築 したところで、それは良いプロセスにはなりえません。 そして、チーム全員が、目的・要求・要件を理解して「目線を合わせる」こ と。 これが私たちが、「私たちのプロセス」を構築するために必要なことでし た。 学び
目的 要求 要件 実装
「目線を合わせ協調を」 ご清聴ありがとうございました