アジャイルについてマネージャーが知るべき97のこと

技術顧問先の社内イベントで登壇した際の資料です。ネタ多め

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. アジャイルについて マネージャーが知るべき 97 のこと 株式会社アトラクタ 取締役CTOアジャイルコーチ 吉羽龍太郎 (@ryuzee)
2. イントロダクション 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2
3. イントロダクション 最新書籍紹介（買ってください!!） 3
4. イントロダクション 「○○が知るべき97のこと」 (日本語) 4
5. イントロダクション 「97 THINGS EVERY ○○ SHOULD KNOW」 5
6. イントロダクション 6 「97 THINGS EVERY ○○ SHOULD KNOW」 どんな役割でも97個くらいは知るべきことがあるらしい（暴論）
7. 書いてみたら97個あった (たぶんもっともっとある)
8. 今日はこの中から重要なものを 書いてみたら97個あった (たぶんもっともっとある) 時間の限り紹介します!!
9. アジャイルについて マネージャーが知るべき 97 のこと
10. アジャイルについてマネージャーが知るべき97のこと 9 複雑な問題の解決において、QCDSを同時にすべて固定することはできない [1] ▸ 非常に古典的な話 ▸ 品質は通常は固定になる ▸ スコープ、費用、納期のうち同時に選べるのは2つまで ▸ スコープと費用を固定: 納期で調整する ▸ スコープと納期を固定: 費用で調整する ▸ 費用と納期を固定: スコープで調整する ▸ 「要件の決まっているものを早く安く作りたい」は妄想 [2] ▸ 同じ人が方法論やプロセスだけで何とかするのは不可能 ▸ アジャイルもその役には立たない ▸ SaaSやオフショアの活用はありえる
11. アジャイルについてマネージャーが知るべき97のこと 10 開発だけをアジャイルにしても意味がない [3] 1か月までの固定期間 1か月までの固定期間 1か月までの固定期間 1か月までの固定期間 1か月までの固定期間 ▸ アジャイルはフィードバックサイクルの集合体。これを元に不確実性に対処して価値の実現を目指す ▸ 大事だと思う要求から順番に実現していく(ときには不要なものを削除する) ▸ 作る(Build)、測定する(Measure)、学習する(Learn)の繰り返し ▸ 何が今やるべき大事なことなのかビジネス側は優先順位判断をし続ける(ビジネス側の継続的関与) ▸ スコープは固定できないので、アジャイルで請負契約は無理 [4] ▸ 「ウォーターフォールとアジャイルの良いとこ取り」は破滅への第一歩
12. アジャイルについてマネージャーが知るべき97のこと 11 すべてがアジャイルに適しているわけではない [5] ▸ アジャイル向き ▸ 経験を積んでからが良いもの ▸ 不向きの可能性が高いもの ▸ 競争領域 ▸ 大規模 ▸ 作るものが明確で変化少 ▸ 未踏領域 ▸ ハードウェア ▸ 顧客との契約が請負 ▸ 新規事業や新規プロダクト ▸ ミッションクリティカル ▸ 開発の外部委託 ▸ 仮説の検証が必要 ▸ スコープと納期固定 ▸ フィードバックループが必要 ▸ 既存システムの移行 ▸ 非ミッションクリティカル ▸ 特殊なパッケージや技術 ▸ 内製エンジニアの存在 ▸ 他のプロダクトの模倣
13. アジャイルについてマネージャーが知るべき97のこと 12 すべてのプロダクトが成功するわけではない [12] ▸ Amazonが撤退した主事業(ベイン・アンド・カンパニーの分析) ▸ 2011→2015 アマゾン・ローカル ▸ 1999→2000 アマゾン・オークションズ ▸ 2011→2015 テストドライブ(アプリの購入前試用) ▸ 1999→2007 Zショップス ▸ 2012→2015 ミュージック・インポーター ▸ 2004→2008 検索エンジンA9 ▸ 2014→2015 ファイアフォン ▸ 2006→2013 アスクビル（Q&Aサイト） ▸ 2014→2015 アマゾン・エレメンツ ▸ 2006→2015 アンボックス(TVや映画の購入・レンタル) ▸ 2014→2015 アマゾン・ローカルレジスター(携帯決済) ▸ 2007→2012 エンドレス・ドットコム(靴とバックのサイト) ▸ 2014→2015 アマゾン・ウォレット ▸ 2007→2014 アマゾン・ウェブペイ(P2P送金) ▸ 2015→2015 アマゾン・デスティネーションズ(宿泊予約) ▸ 2009→2012 ペイフレーズ(合言葉による決済) ▸ 2010→2016 マイハビット(会員制タイムセール)
14. 作りたいものは だいたい 決まっている
15. 作りたいものは だいたい 決まっている
16. アジャイルについてマネージャーが知るべき97のこと 最初のアイデアは仮説にすぎない [13] ▸ 多くのプロダクトを成功させているAmazonでさえたくさんのプロダクトが失敗している ▸ 事前の検討は当然やっている。それでも失敗する ▸ 事業計画はそのとおりになるはずがない [16] (のに詳細な事業計画や売り上げ目標を書いても無駄) ▸ 事前の検討をたくさんしても不確実性は減らない [17] ▸ 失敗する確率が高いことを前提にすると以下が重要になる ▸ いかに早く失敗に気づくか ▸ いかに早く撤退するか ▸ つまり、お金と時間を無駄にしない ▸ 課題と顧客の発見にフォーカスする 14
17. 初回のリリースはゴールではなくスタート [24]
18. アジャイルについてマネージャーが知るべき97のこと プロダクトの成功を計測する指標を定めよう [25] ▸ NSM、KGI、KPIを決めて、計測していかなければいけない ▸ 「期限までにN個の機能を作った」のような生産性指標が最重要なわけではない ▸ 売り上げやユーザー数も単体で見ると誤解を招くし、ハックできてしまう fl ▸ 一定期間計測して、見込みがないプロダクトは撤退しよう [30] Net ix Attention 月間N時間以上視聴しているユーザーの数 Spotify Attention 有償顧客の月間楽曲再生時間の合計 Amazon Transaction 1プライムユーザーあたりの購入金額の合計 Walmart Transaction 顧客の1回あたりの購入点数 Salesforce Productivity アカウントあたりの平均レコード作成数 Adobe Productivity エンゲージメントが高いサブスク購入者数 16
19. アジャイルについてマネージャーが知るべき97のこと 17 参考書籍 ▸ 「スクラムがもたらす最終的な結果、いわば設計目標は、飛躍的に 生産性を上げるチームの実現にある」(p.22) ▸ プロダクトが失敗しても、良いチームが残れば将来たくさんチャン スはある(はず) ▸ 機能しているチームを壊してはいけない [31] ▸ そもそも、機能しているチームとそうでないチームでは、パ フォーマンスに何倍もの差がでる ▸ 同じチームで仕事をするほど、予測精度も上がる
20. アジャイルについてマネージャーが知るべき97のこと 機能するチームを作るコツ (チームの構造編) ▸ チームを変えるときはゆっくりと [32] ▸ 相談なくチームから人を外してはいけない [33] ▸ チームに相談なく人を追加してはいけない [34] ▸ チームに悪影響を与えている人に対処しよう [35] ▸ プロパーを手厚く配置しよう [36] ▸ 良い人を採用しよう [37] ▸ パートナーとは長くつきあおう [38] 18
21. アジャイルについてマネージャーが知るべき97のこと 19 複数プロジェクトの兼任は避けよう [39] プロジェクト数 1プロジェクトあたりの稼働可能時間 コンテキストスイッチによるロス 1 100% 0% 2 40% 20% 3 20% 40% 4 10% 60% 5 5% 75% Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284.
22. アジャイルについてマネージャーが知るべき97のこと 専門性だけでチームを分けてはいけない [53] 実現したいユーザー価値 1番目に欲しい コンポーネントチーム 何をするにも受け 渡しの回数が多くなって 遅くなる プロダクト !!!!! 技術レイヤー1 2番目に欲しい !!!!! 技術レイヤー2 3番目に欲しい !!!!! 技術レイヤー3 20
23. アジャイルについてマネージャーが知るべき97のこと 専門性だけでチームを分けてはいけない [53] 実現したいユーザー価値 1番目に欲しい コンポーネントチーム 何をするにも受け 渡しの回数が多くなって 遅くなる プロダクト !!!!! 技術レイヤー1 クロスファンクショナルチームを作ろう 2番目に欲しい !!!!! 技術レイヤー2 3番目に欲しい !!!!! 技術レイヤー3 20
24. アジャイルについてマネージャーが知るべき97のこと 機能するチームを作るコツ (チームとの関わり方) ▸ チームが働いている様子を観察しよう [45] ▸ チームを外からの圧力から守ろう [47] ▸ チームが透明性を保てるように支援しよう [48] ▸ 無礼なふるまいを許さないようにしよう [49] ▸ チームが集中して働ける場所を作ろう [53] ▸ チームメンバーのキャリア開発を支援しよう [54] ▸ チームのメンバーと1on1をしよう [55] ▸ 良い点と改善点を定期的にフィードバックしよう [56] ▸ 人事評価の方法を説明しよう [58] 21
25. 『転職できるぐらいに人を訓 練し、転職したいと思わない くらいに厚遇せよ』 ff 書籍『E ective DevOps』より
26. アジャイルについてマネージャーが知るべき97のこと 23 昔とはマネージャーの役割は変わったということ 科学的管理手法 (産業革命後〜大量生産の時代) 人間関係論 (現代) 組織を効率的に運用する 従業員の心理的・社会的ニーズに注意を払う X 理論 Y理論 労働者は管理され指示されなければいけない 従業員が自由に意見を述べられ行動できると 貢献度が上がる
27. テキスト アジャイルマニフェスト
28. テキスト アジャイルマニフェスト アジャイルとは良い開発方法を探し続けること
29. テキスト アジャイルマニフェスト 過度な標準化は害を及ぼす [61]
30. アジャイルについてマネージャーが知るべき97のこと 27 アジャイル = 価値観＋原則 スクラム Crystal エクストリームプログラミング FDD リーンソフトウェア開発 DSDM カンバン
31. アジャイルについてマネージャーが知るべき97のこと 27 アジャイル = 価値観＋原則 不安かもしれないけど プロセスの詳細はチームに決めてもらおう [62] スクラム Crystal エクストリームプログラミング FDD リーンソフトウェア開発 DSDM カンバン
32. アジャイルについてマネージャーが知るべき97のこと マネージャーとしてプロセスとどう関わるか ▸ チームに権限や判断を移譲しよう [66] ▸ なんでも文書化させてはいけない [67] ▸ 詳細すぎる報告を求めてはいけない [68] ▸ 生産性のみに注目しない [69] 28
33. アジャイルについてマネージャーが知るべき97のこと 29 スプリントレビューに参加して、実物を見よう [70] ▸ 現地現物 ▸ 百聞は一見にしかず ▸ インクリメントを毎回レビューできてい ることがチームの健全性を表す ▸ 数字やレポートだけでは分からない ▸ チームで解決できない問題があれば、 その解決を助けよう [73]
34. アジャイルについてマネージャーが知るべき97のこと プロダクトには、それぞ れ固有の品質がある 30 プロダクトすべてで統一の品質を求めない [76] 不具合でもすべて 直す必要があるとは限ら ない [77]
35. アジャイルについてマネージャーが知るべき97のこと 現代のソフトウェア開発スタックはどんどん複雑になっている 31
36. アジャイルについてマネージャーが知るべき97のこと 現代のソフトウェア開発スタックはどんどん複雑になっている 技術やアーキテクチャーの指示をしない (できない) [80] チームが学習の時間を持てるようにしよう [85] チームの学習のためのお金を確保しよう [86] 31
37. アジャイルについてマネージャーが知るべき97のこと 32 アジャイルでもマネージャーは不要にはならない [87] ▸ いままでの仕事とやり方は変わるかもしれないが、マネージャーは不要にはならない ▸ マネジメントするのは人よりも環境 ▸ 成果を出せて、従業員が幸せに働ける環境を作って維持し続けるのが、マネージャーの最大の責任 ▸ そのためには ▸ チームのために時間を空けておこう [93] ▸ 自分の学習の時間も確保しよう [94] ▸ 自分が学習している姿をチームに見せよう [95] ▸ いつも機嫌よくしておこう [97]
38. あとで全部読んでみてください

Comment

No comments...