2022/11/15_Agile Japan 2022での講演資料になります
アジリティを目指した先にあった真のパートナーシップ
View Slide
自己紹介藤田健人高橋陽太郎
本日は「協調」について話します。それは我々にとっては「目線を合わせる」ことでした。簡単そうですが目線が合うまで4年を要しました
フロントエンド開発チーム（スクラム）バックエンド開発チーム（スクラム）企画チーム2week sprint 2week sprint企画ができても次のスプリントまで待ち2日でフロントエンド開発が終わってもバックエンドチームの次のスプリントまで待ち最短で4日でできる案件でも1ヶ月以上かかってしまう状態（でもみんな「全力で頑張っている」）これは正しい状態なのだろうか？という違和感たとえば、『タウンワーク』のUI/UXの改善チームでは、早期にスクラムを導入していたものの、「違和感」がありました
この違和感は、ふりかえると4つのレイヤーで整理することができます。本日はこのレイヤーに沿って話を進めます目的要求要件実装ビジネスゴールやアウトカムと言われるもの。何かの要求をする際の背景となるもの。ビジネスゴールを実現するためにどのような考え方、戦略を取るか。要求を実現する上での進め方、取り組み方、開発プロセス（例）スクラム、カンバン、ウォーターフォールコーディングやテストなどの実際にインクリメントを増やす活動スクラム要求は4日？1ヶ月でOK？？？？？？？なにやらあやふやはっきりしている
最初は、リクルートとNTTデータでも全く異なる目線でした。目的要求要件実装リクルート目線 NTTデータ目線目的要求要件実装目的要求要件実装（あんまりよくわかってないけど）早くやりたいスクラムで スクラムで毎月リリースしたい
活動をふりかえると、大事なステップが３つありました。目的要求要件実装リクルート目線 NTTデータ目線目的要求要件実装目的要求要件実装ステップ①：目的・要求を明確化し言語化するステップ②：明確化した目的・要求を理解するステップ③：全員が理解できる状態を作る
『タウンワーク』は、仕事探しのより良いユーザー体験を提供していくことが目的です。それは、年間のユーザーアクション数を最大化する必要があることを意味しますリボン図
ユーザのアクションを最大化させるために、開発プロセスによって貢献できる事は何か？を考えます。価値期間ユーザ体験の向上によって得られるアクション数開発期間開発期間が短くて、リリース後の期間が伸びるほど、ユーザ体験の向上期間が伸びる。→アクション数が増える
「もしも仮に、選ぶとしたらAとBは、どちらでしょうか？」を言語化し、明示します開発プロセスに対するビジネス要求：同期間の開発量 ＜ 同期間のユーザ体験が生む価値の総量 の優先度が高い。価値期間価値期間同じ期間に多くの機能を出すこと よりも 同じ期間に生まれる価値総量 をとるA:一気に開発 B:コツコツ開発
ステップ②は明確化した目的・要求の理解するステップです目的要求要件実装リクルート目線 NTTデータ目線目的要求要件実装目的要求要件実装ステップ②：明確化した目的・要求を理解するNTTデータ側の先頭にたち全員が理解するために自身が正しく理解する必要がありましたステップ①：クリア
きちんと理解しようと資料を追いかけても、資料化されている知識を追うだけでも膨大な分量でした
正しく理解するために膨大な資料の咀嚼を、二人で時間をかけてディスカッションを重ねました長い時間をかけて正しく理解ディスカッションする過程で重要な気付きがありました
大切なことに気が付きました目的定義要求定義要件定義設計、製造、試験、リリース開発案件の工程目的要求要件実装プロセスの工程開発案件を開発する時は、ビジネス目的、要求を理解した上で、最適なシステム要件を選択していくのに・・・開発プロセスにも目的と要求があり、それを理解しなければ最適な要件、実装にならない、という当たり前なことが抜けていたなんのためのアジャイルか？が抜けていました
目的要求要件実装リクルート目線 NTTデータ目線目的要求要件実装目的要求要件実装ステップ③：全員が理解できる状態を作るステップ③は全員が理解できる状態を作ることですステップ②：クリアステップ①：クリア
目的、要求、要件の理解のために知識目的、要求をインプットするメンバーのチームや目線もそれぞれ異なる。それぞれの目線から見える現状と照らし合わせ、最適な要件（＝開発プロセス）を自分たちで考えていく。自ら考えることで、目的、要求、要件が正しく伝搬
「自分たちで考えた」ことを実践し、くりかえします実装適用実際にプロセスを回しながら、改善をくりかえすことでプロセス要件は、概念レベルから自分たちのプロセスに要件学び疑問 くりかえしくりかえし 改善 改善
例カンバン方式（要件）でやっているけど、さらに開発リードタイム短縮（要求）するためにどうしたらいいだろう？テスト工程で故障が結構出てますねー。フロントエンドとバックエンドの認識齟齬のところが結構ありますね。じゃあ設計段階でフロントエンドとバックエンドで設計の認識合わせをやろう。さらにペアプロも考えるか・・・プロセス要求、要件、実装の繋がりを考えながら実装に組み込むことでチームに最適化したプロセスとなる
目的要求要件実装目的要求要件実装目的要求要件実装リクルート目線 NTTデータ目線3ステップを通して、ようやく「目線を合わせる」ことができました。ステップ①：目的・要求を明確化し言語化するステップ②：明確化した目的・要求を理解するステップ③：全員が理解できる状態を作る
目的要求要件実装リクルート目線 NTTデータ目線目的要求要件実装目的要求要件実装ふりかえって反省すると、リクルート目線では目的・要求が不明確なのに、「アジャイルで」という要件をお願いしてしまっていました【大反省】ビジネスゴールも不明確で、それを実現するための要求もわかっていないが、「アジャイルでという要件」をお願いしてしまっていた
目的要求要件実装リクルート目線 NTTデータ目線目的要求要件実装目的要求要件実装NTTデータ目線では、目的・要求が不明確にも関わらず、それを鵜呑みにしてしまったことが反省点でした「アジャイルでやること」が暗黙的なゴールになってしまっていた
目的要求要件実装目的要求要件実装目的要求要件実装リクルート目線 NTTデータ目線目的・要求が不明確で、要件定義がグダグダになる。システム開発あるあるが、我々のプロセス設計においても起きてしまっていました（ 4レイヤーの命名の由来）「アジャイルでやること」が暗黙的なゴールになってしまっていた【大反省】ビジネスゴールも不明確で、それを実現するための要求もわかっていないが、「アジャイルでという要件」をお願いしてしまっていた
良いコードを書くためには、「なぜ？この機能を作るのか」を常に重視しています。それは、開発プロセスにおいても同じでした。「なぜ？このプロセスを採用するのか」が分からない状態でプロセス構築したところで、それは良いプロセスにはなりえません。そして、チーム全員が、目的・要求・要件を理解して「目線を合わせる」こと。これが私たちが、「私たちのプロセス」を構築するために必要なことでした。学び目的要求要件実装
「目線を合わせ協調を」ご清聴ありがとうございました
recruitengineers
yoshikieguchi
keithyokoma
takahia1988
trycycle
washizaki
watany
taka2noda
takashi1029
hosimesi11
yoyakoba
jfg956
niryuu
jmmastey
skipperchong
mongodb
marcelosomers
jcasabona
shpigford
scottboms
edds
notwaldorf
afnizarnur
panda_program
keavy