マネジメントは怖くない？〜エンジニアが“チームリード”になるまでの葛藤と成長〜

詳細：https://confengine.com/conferences/scrum-fest-osaka-2025/proposal/22707

私は「一生手を動かして技術者として生きていきたい」という強い思いから、マネジメントやビジネスの問題にはできるだけ関わらずに済む道を選び、エンジニアとしてのキャリアを歩んできました。むしろ、そういった領域を避けたいからこそエンジニアという職種を選んだ、と言っても過言ではありません。

しかしキャリアを重ねていくうちに、技術的な課題に集中しようとすればするほど、技術だけでは解決できない問題や、チーム・組織の壁に直面することが増えていきました。そんな中、多くの仲間と出会い、アジャイルの考え方に触れることで、自分の価値観が少しずつ変化していくのを感じました。仲間との別れや組織の変化の中で無力感を覚えることもありましたが、これまでの出会いやアジャイルの学びが自分を支え、壁を乗り越える力になってくれました。

そしてアジャイルコーチのOyobeさんが組織に来てくれてからは、コミュニティでの繋がりをきっかけに毎週1-on-1を実施し、チームの課題や自分自身の成長、現在取り組んでいるプロジェクトについて壁打ちしながら伴走してもらいました。その中で、少しずつ「技術だけ」にこだわっていた自分が変わっていくのを実感し、チームを良くすることや職種を超えたコラボレーションに邁進することも「ソフトウェアエンジニアリング」なのだと考えられるようになりました。

このセッションでは、エンジニアとしてマネジメントやビジネスの問題を避けてきた私が、どのようにして“チームのリード”としての役割や成長に向き合うようになったのか、その葛藤と変化、そしてアジャイルコーチとの伴走を通じて得た気づきをお話しします。

及部（アジャイルコーチ）からのメッセージ
今回のセッションでは、Kinjoさんのエンジニア人生においてとても大切な時期の内容を話してくれます。そんな時期に伴走することができ、アジャイルコーチ冥利に尽きる経験をすることができました。

私自身もエンジニアからキャリアをスタートしました。そのため、コーチングを通してKinjoさんのエンジニアとしての葛藤の話を聞いたときはとても共感しました。エンジニア経験がある方や今もエンジニアをされている方にとって、とても参考になる内容だと思います。

Kinjoさんがメインスピーカーですが、近くで見ていたアジャイルコーチとして第三者目線でどう見えていたのかという視点でガヤを入れ、彼の話に華を添えたいと思います。

Transcript

1. マネジメントは怖くない？ 〜エンジニアが“チームリード”になるまでの葛藤と成長〜 Kinjo Shogo/Oyobe Takao
2. 自己紹介 • Shogo Kinjo • Software Engineer@Rakuten Rakuma • @ATOM03151 on X • 一児（もうすぐ二児）の父 2
3. 制御不能なアジャイルモンスター 及部 敬雄 @TAKAKING22 AGILE-MONSTER.COM アジャイルコーチ 株式会社ホロラボ 執行役員 • Silver Bullet Club（チーム）でチーム転職 ◦ 楽天→デンソー→現職 • 2025年4月に福岡に移住したよ！
4. KinjoとOyobeの関係性 4 • 2024年7月からアジャイルコーチとしてRakuten Rakumaを支援 ◦ 組織へのアプローチ、チームコーチング、パーソナル1on1 • 活動の中でKinjoさんとアジャイル開発の推進について一緒に取り組んだり、 Kinjoさんのチームへの支援をするようになった
5. 今日のお話 5 • エンジニアがマネジメント（そしてアジャイル開発やスクラム）に携わる際に感じる葛 藤のリアル • N=1かもしれないが、Kinjo-sanの話のどこかに共感して、 誰かと話すきっかけになる人が一人でもいたらとても価値があるお話 アジャイルコーチの ガヤ・・・解説付きでお届け！！
6. 最初に話しておきたいこと 6 • 私は現在Individual Contributorでマネジメントの経験はない ◦ Individual Contributor（IC）とは、一般的に「管理職ではない専門職」を指す言葉 • チームリードの経験 • 私の体験・経験ベースで話しますので、方法論やプラクティスではありません。 • 「ソフトウェアエンジニアリング」と「エンジニアリング」という言葉を入れ替え可能な形で使 います
7. アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁・チームや組織の壁との遭遇 3. 仲間・スクラムとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 7
8. アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁・チームや組織の壁との遭遇 3. 仲間・スクラムとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 8
9. 私はキャリアを始めた時から 「一生現役エンジニアとして生きていきたい」 と思っていました 9
10. つまりマネジメントの道は選ばずに キャリアを歩んで行きたいということです 10 マネージャー エンジニア
11. なぜそう思っていたのか 11
12. マネジメントに近づくことは エンジニアリングと遠ざかることだと考えていた 12 エンジニアリング マネジメント
13. マネジメントに近づくことは エンジニアリングと遠ざかることだと考えていた 13 エンジニアリング ソフトウェアエンジニアでは なくなってしまうのではないか そうだとすると自分にとっては 恐怖 マネジメント
14. その時の自分にとってエンジニアリングとマネジメントの距離 14 マネジメントに近づく　＝　エンジニアリングと遠ざかる エンジニアリング マネジメント 距離がある・領域が重ならない
15. じゃあなぜエンジニアリングから 遠ざかりたくないのか？ 15
16. エンジニアリングから遠ざかりたくない二つの理由 • 内発的な動機 ◦ エンジニアという仕事が楽しくて好き • 外発的な動機 ◦ 遠ざかることで周りから置いていかれてしまう恐怖
17. エンジニアという仕事のどんなところが好きか 17 • 考え過ぎることが評価される世界 • 自らの手でモノを作る部分に触れている点 • 学び続ける文化自体が好き
18. 私のエンジニア歴 18 新卒(2011年4月) 2020年 2025年現在 営業や運送などの職種 エンジニアとして働いた歴 この期間の分他の人と比べて遅れを 取ってるのではないかという消えない焦り
19. つまりまとめるとこういう事です 19 マネジメントはしたくない マネジメントに近づくことはエンジニアリングと離れること エンジニアの仕事が好きだし 職歴の短さから来る焦りで少しでも離れると置いていかれる恐怖
20. 20 • 約10ヶ月前に一緒に飲んだときに、「マネジメントに手を出すことを 躊躇している」とKinjo-sanが語っていたことを覚えている • でも自分から見えるKinjo-sanは、スクラムコミュニティもいたし、 組織やチームでスクラムの実践や普及に積極的に関わっていた • 自分もエンジニアとしてアジャイル開発やスクラムに出会って、関わり続けてきたの で、その矛盾した葛藤の気持ちがよくわかる
21. アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁・チームや組織の壁との遭遇 3. 仲間・アジャイルとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 21
22. 技術だけでは解決できない壁との遭遇 22 キャリアを重ねる中で 技術だけでは解決できない問題 やチーム・組織の壁に 何度も遭遇 またお前か...
23. 一つ目の壁：信頼の壁 23 信頼の壁 技術的に妥当で低コストのソリューションを提案したが 高コストだが信頼とサポート体制がある 他社のソリューションが採用された時 技術だけで物事は 動かないと痛感
24. 二つ目の壁：チームとチームの壁 24 私が所属する組織は大きなプロダクトを開発していて、 複数のチームに分かれて開発しています。 機能別にチームが分かれた構成になっているのですが、 チーム間に落ちたボールやチーム間の協働が想像していたより 簡単ではなかったです。
25. 例えば二つのチームがあります 25 機能A 担当チーム 機能B 担当チーム
26. 例えば間に問題が落ちてきたとします 26 機能A 担当チーム 機能B 担当チーム
27. たまたま両方のチームの間にあって 自分のチーム担当じゃないと思った場合 27 機能A 担当チーム 機能B 担当チーム Bチームの ものだな Aチームの ものだな
28. これは誰にも拾われないボールとなるという例です 28 機能A 担当チーム 機能B 担当チーム Bチームの ものだな Aチームの ものだな 誰にも拾われない
29. これは誰にも拾われないボールとなるという例です 29 機能A 担当チーム 機能B 担当チーム Bチームの ものだな Aチームの ものだな 誰にも拾われない この状態やチームを責めたい訳ではなく このボールを拾えるようになった方が みんな幸せなのではと考え じゃあどうすれば拾えるようになるのだろう と考えました
30. 三つ目の壁：開発とビジネスの壁 30
31. 当初対面のビジネスチームと細かくやりとりをしていた 31 開発 ビジネス 直接やりとりをしていた
32. 組織が大きくなるにつれ直接やりとりが減った 32 開発 ビジネス 間に立つ役割
33. 33 組織が大きくなってきたからこそ ビジネスチームも 効率化したいのだろう。 じゃあその思いを無視はできない 事情が理解できるからこその葛藤
34. 壁を感じてどう思ったのか 34 技術だけではプロダクトを成長させるには片手落ちな気持ち
35. 壁を感じてどう思ったのか 35 技術だけではプロダクトを成長させるには片手落ちな気持ち もちろんそれは別の職種が担ってくれる部分であって エンジニアが集中する部分は他にあるのかもしれない
36. 壁を感じてどう思ったのか 36 技術だけではプロダクトを成長させるには片手落ちな気持ち もちろんそれは別の職種が担ってくれる部分であって エンジニアが集中する部分は他にあるのかもしれない ただこの壁を感じてしまった以上 無視することができなくなってしまった
37. 壁を感じてどう思ったのか 37 技術だけではプロダクトを成長させるには片手落ちな気持ち もちろんそれは別の職種が担ってくれる部分であって エンジニアが集中する部分は他にあるのかもしれない ただこの壁を感じてしまった以上 無視することができなくなってしまった 壁を超えられるようになりたい
38. 38 • 壁を感じたときに、なぜ「◯◯がもっとちゃんと仕事すればいいのに」 という他責思考ではなく、自ら壁を超えられるようになりたいと思えたのか
39. アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁との遭遇 3. 仲間・スクラムとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 39
40. そんな中での出会い 40 今の組織で多くの 貴重な出会いをすることができました。
41. 今の組織での刺激的な仲間との出会い 41 • スクラムコミュニティに参加してる人 • 組織に問題提起を投げかけ続ける思いを持つ仲間 • 一緒に学び続けてくれる仲間 多くの気付きと学びを 与えてくれました
42. それをきっかけにコミュニティとも出会う 42 • 自分が所属してる組織以外で、同じように戦い続けてる人が集まる場所 • 学びを大切にする同じ思いを持つ仲間たち • 会社外でも刺激を受けるようになった 組織の外に同志がいると思うと 組織の中でちょっと無理をしてみようとなる 安心感がある
43. 既にスクラムとは出会っていて、その時の理解 43 • 前職時代にスクラムとは出会っていた ◦ その時は「ただのフレームワーク」ぐらいの解像度 • 「流行ってるもの」という感覚 • MTGが多く開発の時間が減る
44. 当時の私にとってのエンジニアリングとスクラムの距離感 44 エンジニアリング マネジメント スクラム マネジメント同様距離は遠い
45. コミュニティに参加してからスクラムに再会 45 • スクラムはより上手く開発するためのHow • ただ学ぶのではなく失敗や他者から学ぶ価値観 に共感 共感はできても エンジニアとしては 抵抗があるんだよな..
46. 少し変わった エンジニアリングとスクラムとマネジメントの距離感 46 エンジニアリング マネジメント スクラム 少し距離は縮まった マネジメントまでの間にあるもの
47. そんな矢先に仲間との別れ 47
48. 新しいチャレンジのための旅立ち 48 当然ずっと同じ仲間と働いていけるわけもなく、新しいチャレンジをしていく仲間との別れ を経験することになります。
49. そして組織の変化 49 自分自身も 組織の再編で 同じプロダクト組織内での 別チームへの異動 組織が優先すべきミッ ションが 変化していく
50. 奔走するも無力感を感じる日々 50
51. 自分は仲間たちの代わりになれないという無力感 51 別れた仲間は組織に 火を起こす人物だった その仲間がいなくなった組織で どうやって火を起こせばいいのだ ろうか 自分自身は 火を起こせる人物で はなかった
52. 52 • アジャイル開発やスクラムへの認識が多少変わったとしても、 エンジニアリングとは別の領域のものだという認識を持ちながら、 コミュニティに参加したり興味をもって行動していたのはなあぜなあぜ？
53. アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁・チームや組織の壁との遭遇 3. 仲間・スクラムとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 53
54. そんな中組織にアジャイルコーチとして参画したOyobe さんと出会う 54
55. Oyobeさんとの伴走の始まり 55 コミュニティ繋がりをきっかけに毎週1-on-1を実施してもらうことになる 組織での 無力感について チーム活動の悩み 自分自身のキャリアの 悩み コミュニティの雑談 育児と仕事について
56. そんな時にたまたま大きなプロジェクトが始まり チームリードとしてアサインされる 56
57. が、そのプロジェクトは始まった時点で 難易度がとても高いものだということが見えていた 57
58. そのプロジェクトの難易度が高い理由 58 組織の戦略におい て優先度が高く期 待も大きい サービスインの 日付が動かせない 開発チームは今まで チームとして動いたこ とがないメンバーが集 まる 複数の他部署と 連携が不可欠
59. Oyobeさんにもプロジェクトの活動に 入ってもらうことに 59 • イベントにOyobeさんにコーチとして参加してもらう • 普段のイベントをみてもらいながらその都度Feedbackをもらう • 毎週続けてた1-on-1でさらにFeedbackをもらいつつ、今後について壁打ちをしても らう
60. このプロジェクトを通して Oyobeさんとの壁打ちで得た気付き 60
61. 自分の扱える範囲内にある変数と範囲外の定数があった 61 開発 設計 テスト 自分が扱える範囲の変数 チームリード マネジメント PjM PdM 営業 企画 マーケティング 経営 法務 人事 範囲外の定数
62. 「私がこの範囲に閉じていたら このプロジェクトは成功しないかもしれない」 62
63. 思い切って範囲の外に手を伸ばしてみた 63 開発 設計 テスト 自分が扱える範囲の変数 チームリード マネジメント PjM PdM 営業 企画 マーケティング 経営 法務 人事 範囲外の定数
64. 「手を伸ばしてみたら思った以上に より上手くやれてる気がする！？」 64
65. そして範囲外にあった定数が自分が扱える変数になった 65 開発 設計 テスト 自分が扱える範囲の変数 チームリード マネジメント PjM PdM 営業 企画 マーケティング 経営 法務 人事 範囲外の定数
66. 扱える範囲は広げられるし、広げることでよりソフトウェア開発が上手く なれたという気付き 66 開発 設計 テスト チームリード マネジメント PjM PdM 営業 企画 マーケティング 経営 法務 人事
67. ソフトウェア・プロダクト開発に更なる手応えを感じた 67 開発 設計 テスト チームリード マネジメント PjM PdM 営業 企画 マーケティング 経営 法務 人事
68. 今後もっとこの範囲は広げられるのでは？？ 68 開発 設計 テスト チームリード マネジメント PjM PdM 営業 企画 マーケティング 経営 法務 人事 範囲外の定数
69. 扱える変数が増えるとソフトウェア開発が楽しくなる 69 これが私が技術以外の領域にしっかりと足を踏み出したきっかけとなった気がします。 何となく技術以外の領域について色々理由をつけて蓋をして見ないようにしていただけ なのだと気付いた。 技術領域以外の変数を持ち合わせるこ とで、もっと良いプロダクトを作れるように なるし、チームをもっとよくできるようにな るのでは？
70. 「チームを良くする」 「コラボレーションする」 ことへの意識の変化 70
71. それぞれが価値を感じてるものがある 71 チーム コラボレー ション エンジニアリ ング エンジニアリ ング コスパ 省エネ
72. それは人それぞれの変数でしかない 72 チーム エンジニアリング コラボレーション エンジニアリング 省エネ コスパ
73. それは人それぞれの変数でしかない 73 チーム エンジニアリング コラボレーション エンジニアリング 省エネ コスパ だからもっとみんな チーム活動をしようよ！ チームを良くすること、コラボレー ションすることに価値を持つのは当 たり前だよね！！
74. 相手から見ると変数ではなく定数なのかもしれない 74 チーム コラボレーション エンジニアリング 省エネ コスパ 自分にとっては 当たり前じゃないん だけどな。。 エンジニアリング
75. 「チームを良くする」「コラボレーションする」 は押し付けず観察から始まるものだった 75 チーム コラボレーション エンジニアリング 省エネ コスパ エンジニアリング ここを観察す る
76. プロジェクトを通してアジャイルコーチと 伴走しての気づきと学びまとめ 76 • 自分が扱ってた変数の範囲の外に手を広げる事の手応えと面白さ • 「チームをよくする事」と「コラボレーションする」は押し付けるものではなく観察から 始まること • 上記二つから今まで自分が思っていたソフトウェア開発やプロダクト開発から大きく 解像度が上がった
77. 77 • アジャイルコーチとしてチームや組織に関わるときは、 最初からコーチがいなくなったあとのことを考えて支援のかたちを考える • 役職やロールに関わらず、チームの核となっている・なりそうな人を 中心にサポートをすることが多い（今回の場合それがKinjo-sanだった） • Kinjo-sanの場合は、答えやそれにつながる情報はKinjo-sanの中にあることが多 かったので、一緒に探索して認知する壁打ち相手になることが多かった 無印の “コーチング ” に近い関わり方
78. アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁・チームや組織の壁との遭遇 3. 仲間・スクラムとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 78
79. チームリードをする前 自分は「人をリードするタイプ」じゃないと思っていた 79
80. 「自分は人をリードするタイプじゃない」とは 80 チームや組織に火をくべるリードをする仲間たち すごい、、 真似できないなぁ。。
81. 仲間との別れを経て代わりになろうとしたが 81 あの人達の代わりは自分には できなかった。。
82. そんな時ある発表を思い出す 82 “チームにノリをもたらした時にいた「二人目に踊る人」の共通点 ” by piyonakajima-san Scrum Fest Osaka 2023 https://speakerdeck.com/piyonakajima/timuninoriwomotarasitashi-niita- er-ren-mu-niyong-ruren-nogong-tong-dian?slide=144 これは私がいつも 思ってることだ
83. 二人目に踊る人になろう 83 https://youtu.be/OVfSaoT9mEM 私 火を起こす人を探したり 背中を後押しするような場を 作ることに注力しよう 自分は ファーストペンギン ではなく 二人目に踊る人だった
84. 具体的にどんな事をしたのか 84 • スクフェスやRSGTなどの視聴会を社内で多い時は週に一回開催 • 有志で集まれるスクラム・アジャイル関連の輪読会を開催 • 組織のブログ文化を復活させる活動
85. チームリードも誰かの火を大きくするために動こう 85
86. プロデューサー：楽天の職種でPdMとPjMの役割をしてくれる Oyobeさんと伴走した時のプロジェクトのメンバー構成 86 経験豊富なエンジニア プロデューサー 私
87. 私以外の人全員のために動こう 87 私 • 皆がスムーズに仕事をやれる環境を作ろう • プロジェクトを前に進めることであればなんでもやろう
88. 具体的に何をしたのか 88 • チームのスピードを緩めてしまうものを排除する • チームが働きやすい場を整備する • エンジニアと他職種とのハブになる 全てキャリアを開始した時には エンジニアの仕事ではないと思っていたもの
89. チームリードだからやらされていたのか？ 89 全て自分が必要だから という気持ちで行動していたので、やらされていたとか は全くなく、振り返ると自発的だったからなのか楽しかった記憶です。 チームのために走り回るのも 楽しいな
90. プロジェクトは予定通りサービスイン、大きなバグもなし 90 プロジェクトは成功だったのかなと思います。 個人としては学びも多く、視野が広くなるきっかけだったと強く感じています。
91. 振り返った時の反省点 91 チームを自律的にするた めの機会や学び 成長は私が奪っていた かもしれない 次はもっとチームの学 びも重視しつつやれる ようになりたい
92. 92 • Kinjo-sanは「一人目になれない」「二人目に踊る人だった」と言っているが、 チームや組織にいる他の人から見たらKinjo-sanが一人目になっている • おそらくKinjo-sanにとっての「一人目」も同じようにバトンを受け取っている • Kinjo-sanが急に進化して新しいなにかをはじめたわけではなく、 もともとやっていたことを、「それでいいんだ」と自分の中に腹落ちさせることができる ようになったのでは？ 自分を認知して受け入れる
93. アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁・チームや組織の壁との遭遇 3. 仲間・アジャイルとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 93
94. 以前と比べてソフトウェアエンジニアリング に対する考えが大きく変化し定義が広くなった 94
95. 95 “「ソフトウェアエンジニアリングとは時間で 積分したプログラミングである」〜略〜　ソフ トウェアエンジニアリングはプログラミングで はない。” “ソフトウェアエンジニアリング組織内では、 生産するソフトウェアと、ソフトウェアを生産 する組織、それら両方のスケールと効率に 関してより配慮しなければならない。” https://www.oreilly.co.jp/books/97848731 19656/
96. 96 “「ソフトウェアエンジニアリングとは時間で 積分したプログラミングである」〜略〜　ソフ トウェアエンジニアリングはプログラミングで はない。” “ソフトウェアエンジニアリング組織内では、 生産するソフトウェアと、ソフトウェアを生産 する組織、それら両方のスケールと効率に 関してより配慮しなければならない。” https://www.oreilly.co.jp/books/97848731 19656/ 以前まではプログラミングだけ をしようとしていたのかもしれない 生産するソフトウェアだけ に 関心を払っていた
97. 97 “ソフトウェア工学とは、ソフトウェアの現実的 な問題に対する効率的、経済的な解を見つ けるための経験的、科学的なアプローチの 応用のことである。” https://books.rakuten.co.jp/rb/17370467/ ただし技術的なアプローチ に限る
98. 98 “ソフトウェア工学とは、ソフトウェアの現実的 な問題に対する効率的、経済的な解を見つ けるための経験的、科学的なアプローチの 応用のことである。” https://books.rakuten.co.jp/rb/17370467/ ただし技術的なアプローチ に限る 技術的に限らず どんなアプローチも ソフトウェア工学なのでは
99. つまり “チームや組織を良くすること PJを前に進めるために枠にとらわれない活動全てが ソフトウェアエンジニアリング ” であると考えています 99
100. これが私が以前考えていた エンジニアリングとマネジメントの関係 100 マネジメントに近づくこと　＝　エンジニアリングと遠ざかるということ エンジニアリング マネジメント 距離がある・領域が重ならない
101. これが私が以前考えていた エンジニアリングとマネジメントの関係 101 マネジメントに近づくこと　＝　エンジニアリングと遠ざかるということ エンジニアリング （プログラミングだけ） マネジメント 距離がある・領域が重ならない
102. そしてこれがスクラム・アジャイルに出会った頃の 私が考えていた関係 102 マネジメント スクラム エンジニアリング プログラミング
103. 今考える私のソフトウェアエンジニアリング 103 ソフトウェアエンジニアリング スクラム・アジャイル開発 マネジメント
104. …ベン図のような重なりとかではなく 自分の考えはちょっと違う？ 104
105. 私の考えはこのような感じです 105
106. ソフトウェアエンジニアリング 106
107. ソフトウェアエンジニアリング 107 スクラム・アジャイル開発 マネジメント
108. ソフトウェアエンジニアリング 108 スクラム・アジャイル開発 マネジメント プログラミング
109. ソフトウェアエンジニアリング 109 スクラム・アジャイル開発 マネジメント プログラミング コミュニケーション
110. ソフトウェアエンジニアリング 110 スクラム・アジャイル開発 マネジメント プログラミング コミュニケーション NVC マインドフルネス EQ 教育心理学 モブプロ・ペアプロ XP TDD AI サーバントリーダーシップ デザインパターン 設計力 コンピューターサイエンス 心理的安全性 プロジェクトマネジメント ビジネス
111. ソフトウェアエンジニアリング 111 スクラム・アジャイル開発 マネジメント プログラミング コミュニケーション NVC マインドフルネス EQ 教育心理学 モブプロ・ペアプロ XP TDD AI サーバントリーダーシップ デザインパターン 設計力 コンピューターサイエンス 心理的安全性 プロジェクトマネジメント ビジネス 私にとってここの全てが ソフトウェアエンジニアリングの一 部 だという考えになりました。
112. マネジメントは本当にこわいのか？ 112
113. マネジメントへの抵抗感は恐怖だった 113 エンジニアリング マネジメント エンジニアリングが遠ざかる という恐怖
114. ソフトウェアエンジニアリング 114 スクラム・アジャイル開発 マネジメント プログラミング コミュニケーション NVC マインドフルネス EQ 教育心理学 モブプロ・ペアプロ XP TDD AI サーバントリーダーシップ デザインパターン 設計力 コンピューターサイエンス 心理的安全性 プロジェクトマネジメント
115. マネジメントは ソフトウェアエンジニアリングをうまくなるためのパズルの ピースに一つに過ぎないのかもしれない 115
116. そしてマネジメントに限らず範囲の外に手を伸ばしてみれば もっとソフトウェアエンジニアリングが上手くなれる かもしれない 今はこれを広げていく事に価値を感じてワクワクしています 116 開発 設計 テスト チームリード マネジメント PjM PdM 営業 企画 マーケティング 経営 法務 人事 範囲外の定数
117. まとめ 117 • エンジニアリングから離れたくなくてマネジメントを避けてた • 仲間との出会いでスクラム・アジャイル開発に学びの価値観に共感し た • アジャイルコーチ（Oyobeさん）との伴走でエンジニアリングの視野が 広がった • 扱える変数を広げられる事の面白さと手応え • マネジメント・スクラムは恐怖の対象ではなくエンジニアリングのため のパズルのピース でしかないという考えに変わった
118. 118 • アドリブで！
119. ご清聴ありがとうございました 119