マネジメントは怖くない？〜エンジニアが“チームリード”になるまでの葛藤と成長〜

by sho14kim

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介 ● Shogo Kinjo ● Software Engineer@Rakuten Rakuma ● @ATOM03151 on X ● 一児（もうすぐ二児）の父 2

Slide 3

Slide 3 text

制御不能なアジャイルモンスター及部敬雄 @TAKAKING22 AGILE-MONSTER.COM アジャイルコーチ株式会社ホロラボ執行役員 ● Silver Bullet Club（チーム）でチーム転職 ○ 楽天→デンソー→現職 ● 2025年4月に福岡に移住したよ！

Slide 4

Slide 4 text

KinjoとOyobeの関係性 4 ● 2024年7月からアジャイルコーチとしてRakuten Rakumaを支援 ○ 組織へのアプローチ、チームコーチング、パーソナル1on1 ● 活動の中でKinjoさんとアジャイル開発の推進について一緒に取り組んだり、 Kinjoさんのチームへの支援をするようになった

Slide 5

Slide 5 text

今日のお話 5 ● エンジニアがマネジメント（そしてアジャイル開発やスクラム）に携わる際に感じる葛藤のリアル ● N=1かもしれないが、Kinjo-sanの話のどこかに共感して、誰かと話すきっかけになる人が一人でもいたらとても価値があるお話アジャイルコーチのガヤ・・・解説付きでお届け！！

Slide 6

Slide 6 text

最初に話しておきたいこと 6 • 私は現在Individual Contributorでマネジメントの経験はない ○ Individual Contributor（IC）とは、一般的に「管理職ではない専門職」を指す言葉 • チームリードの経験 • 私の体験・経験ベースで話しますので、方法論やプラクティスではありません。 • 「ソフトウェアエンジニアリング」と「エンジニアリング」という言葉を入れ替え可能な形で使います

Slide 7

Slide 7 text

アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁・チームや組織の壁との遭遇 3. 仲間・スクラムとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

私はキャリアを始めた時から「一生現役エンジニアとして生きていきたい」と思っていました 9

Slide 10

Slide 10 text

つまりマネジメントの道は選ばずにキャリアを歩んで行きたいということです 10 マネージャーエンジニア

Slide 11

Slide 11 text

なぜそう思っていたのか 11

Slide 12

Slide 12 text

マネジメントに近づくことはエンジニアリングと遠ざかることだと考えていた 12 エンジニアリングマネジメント

Slide 13

Slide 13 text

マネジメントに近づくことはエンジニアリングと遠ざかることだと考えていた 13 エンジニアリングソフトウェアエンジニアではなくなってしまうのではないかそうだとすると自分にとっては恐怖マネジメント

Slide 14

Slide 14 text

その時の自分にとってエンジニアリングとマネジメントの距離 14 マネジメントに近づく　＝　エンジニアリングと遠ざかるエンジニアリングマネジメント距離がある・領域が重ならない

Slide 15

Slide 15 text

じゃあなぜエンジニアリングから遠ざかりたくないのか？ 15

Slide 16

Slide 16 text

エンジニアリングから遠ざかりたくない二つの理由 ● 内発的な動機 ○ エンジニアという仕事が楽しくて好き ● 外発的な動機 ○ 遠ざかることで周りから置いていかれてしまう恐怖

Slide 17

Slide 17 text

エンジニアという仕事のどんなところが好きか 17 • 考え過ぎることが評価される世界 • 自らの手でモノを作る部分に触れている点 • 学び続ける文化自体が好き

Slide 18

Slide 18 text

私のエンジニア歴 18 新卒(2011年4月) 2020年 2025年現在営業や運送などの職種エンジニアとして働いた歴この期間の分他の人と比べて遅れを取ってるのではないかという消えない焦り

Slide 19

Slide 19 text

つまりまとめるとこういう事です 19 マネジメントはしたくないマネジメントに近づくことはエンジニアリングと離れることエンジニアの仕事が好きだし職歴の短さから来る焦りで少しでも離れると置いていかれる恐怖

Slide 20

Slide 20 text

20 ● 約10ヶ月前に一緒に飲んだときに、「マネジメントに手を出すことを躊躇している」とKinjo-sanが語っていたことを覚えている ● でも自分から見えるKinjo-sanは、スクラムコミュニティもいたし、組織やチームでスクラムの実践や普及に積極的に関わっていた ● 自分もエンジニアとしてアジャイル開発やスクラムに出会って、関わり続けてきたので、その矛盾した葛藤の気持ちがよくわかる

Slide 21

Slide 21 text

アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁・チームや組織の壁との遭遇 3. 仲間・アジャイルとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 21

Slide 22

Slide 22 text

技術だけでは解決できない壁との遭遇 22 キャリアを重ねる中で技術だけでは解決できない問題やチーム・組織の壁に何度も遭遇またお前か...

Slide 23

Slide 23 text

一つ目の壁：信頼の壁 23 信頼の壁技術的に妥当で低コストのソリューションを提案したが高コストだが信頼とサポート体制がある他社のソリューションが採用された時技術だけで物事は動かないと痛感

Slide 24

Slide 24 text

二つ目の壁：チームとチームの壁 24 私が所属する組織は大きなプロダクトを開発していて、複数のチームに分かれて開発しています。機能別にチームが分かれた構成になっているのですが、チーム間に落ちたボールやチーム間の協働が想像していたより簡単ではなかったです。

Slide 25

Slide 25 text

例えば二つのチームがあります 25 機能A 担当チーム機能B 担当チーム

Slide 26

Slide 26 text

例えば間に問題が落ちてきたとします 26 機能A 担当チーム機能B 担当チーム

Slide 27

Slide 27 text

たまたま両方のチームの間にあって自分のチーム担当じゃないと思った場合 27 機能A 担当チーム機能B 担当チーム Bチームのものだな Aチームのものだな

Slide 28

Slide 28 text

これは誰にも拾われないボールとなるという例です 28 機能A 担当チーム機能B 担当チーム Bチームのものだな Aチームのものだな誰にも拾われない

Slide 29

Slide 29 text

これは誰にも拾われないボールとなるという例です 29 機能A 担当チーム機能B 担当チーム Bチームのものだな Aチームのものだな誰にも拾われないこの状態やチームを責めたい訳ではなくこのボールを拾えるようになった方がみんな幸せなのではと考えじゃあどうすれば拾えるようになるのだろうと考えました

Slide 30

Slide 30 text

三つ目の壁：開発とビジネスの壁 30

Slide 31

Slide 31 text

当初対面のビジネスチームと細かくやりとりをしていた 31 開発ビジネス直接やりとりをしていた

Slide 32

Slide 32 text

組織が大きくなるにつれ直接やりとりが減った 32 開発ビジネス間に立つ役割

Slide 33

Slide 33 text

33 組織が大きくなってきたからこそビジネスチームも効率化したいのだろう。じゃあその思いを無視はできない事情が理解できるからこその葛藤

Slide 34

Slide 34 text

壁を感じてどう思ったのか 34 技術だけではプロダクトを成長させるには片手落ちな気持ち

Slide 35

Slide 35 text

壁を感じてどう思ったのか 35 技術だけではプロダクトを成長させるには片手落ちな気持ちもちろんそれは別の職種が担ってくれる部分であってエンジニアが集中する部分は他にあるのかもしれない

Slide 36

Slide 36 text

壁を感じてどう思ったのか 36 技術だけではプロダクトを成長させるには片手落ちな気持ちもちろんそれは別の職種が担ってくれる部分であってエンジニアが集中する部分は他にあるのかもしれないただこの壁を感じてしまった以上無視することができなくなってしまった

Slide 37

Slide 37 text

壁を感じてどう思ったのか 37 技術だけではプロダクトを成長させるには片手落ちな気持ちもちろんそれは別の職種が担ってくれる部分であってエンジニアが集中する部分は他にあるのかもしれないただこの壁を感じてしまった以上無視することができなくなってしまった壁を超えられるようになりたい

Slide 38

Slide 38 text

38 ● 壁を感じたときに、なぜ「◯◯がもっとちゃんと仕事すればいいのに」という他責思考ではなく、自ら壁を超えられるようになりたいと思えたのか

Slide 39

Slide 39 text

アジェンダ 1. 「一生現役エンジニアとして生きていきたい」思いとその背景 2. 技術だけでは解決できない壁との遭遇 3. 仲間・スクラムとの出会いと価値観の変化 4. アジャイルコーチとの伴走と新たな挑戦 5. ”チームをリード”することの葛藤と気づき 6. 今自分が考える「ソフトウェアエンジニアリング」とは 39

Slide 40

Slide 40 text

そんな中での出会い 40 今の組織で多くの貴重な出会いをすることができました。

Slide 41

Slide 41 text

今の組織での刺激的な仲間との出会い 41 ● スクラムコミュニティに参加してる人 ● 組織に問題提起を投げかけ続ける思いを持つ仲間 ● 一緒に学び続けてくれる仲間多くの気付きと学びを与えてくれました

Slide 42

Slide 42 text

それをきっかけにコミュニティとも出会う 42 ● 自分が所属してる組織以外で、同じように戦い続けてる人が集まる場所 ● 学びを大切にする同じ思いを持つ仲間たち ● 会社外でも刺激を受けるようになった組織の外に同志がいると思うと組織の中でちょっと無理をしてみようとなる安心感がある

Slide 43

Slide 43 text

既にスクラムとは出会っていて、その時の理解 43 ● 前職時代にスクラムとは出会っていた ○ その時は「ただのフレームワーク」ぐらいの解像度 ● 「流行ってるもの」という感覚 ● MTGが多く開発の時間が減る

Slide 44

Slide 44 text

当時の私にとってのエンジニアリングとスクラムの距離感 44 エンジニアリングマネジメントスクラムマネジメント同様距離は遠い

Slide 45

Slide 45 text

コミュニティに参加してからスクラムに再会 45 ● スクラムはより上手く開発するためのHow ● ただ学ぶのではなく失敗や他者から学ぶ価値観に共感共感はできてもエンジニアとしては抵抗があるんだよな..

Slide 46

Slide 46 text

少し変わったエンジニアリングとスクラムとマネジメントの距離感 46 エンジニアリングマネジメントスクラム少し距離は縮まったマネジメントまでの間にあるもの

Slide 47

Slide 47 text

そんな矢先に仲間との別れ 47

Slide 48

Slide 48 text

新しいチャレンジのための旅立ち 48 当然ずっと同じ仲間と働いていけるわけもなく、新しいチャレンジをしていく仲間との別れを経験することになります。

Slide 49

Slide 49 text

そして組織の変化 49 自分自身も組織の再編で同じプロダクト組織内での別チームへの異動組織が優先すべきミッションが変化していく

Slide 50

Slide 50 text

奔走するも無力感を感じる日々 50

Slide 51

Slide 51 text

自分は仲間たちの代わりになれないという無力感 51 別れた仲間は組織に火を起こす人物だったその仲間がいなくなった組織でどうやって火を起こせばいいのだろうか自分自身は火を起こせる人物ではなかった

Slide 52

Slide 52 text

52 ● アジャイル開発やスクラムへの認識が多少変わったとしても、エンジニアリングとは別の領域のものだという認識を持ちながら、コミュニティに参加したり興味をもって行動していたのはなあぜなあぜ？

Slide 53

Slide 53 text

Slide 54

Slide 54 text

そんな中組織にアジャイルコーチとして参画したOyobe さんと出会う 54

Slide 55

Slide 55 text

Oyobeさんとの伴走の始まり 55 コミュニティ繋がりをきっかけに毎週1-on-1を実施してもらうことになる組織での無力感についてチーム活動の悩み自分自身のキャリアの悩みコミュニティの雑談育児と仕事について

Slide 56

Slide 56 text

そんな時にたまたま大きなプロジェクトが始まりチームリードとしてアサインされる 56

Slide 57

Slide 57 text

が、そのプロジェクトは始まった時点で難易度がとても高いものだということが見えていた 57

Slide 58

Slide 58 text

そのプロジェクトの難易度が高い理由 58 組織の戦略において優先度が高く期待も大きいサービスインの日付が動かせない開発チームは今までチームとして動いたことがないメンバーが集まる複数の他部署と連携が不可欠

Slide 59

Slide 59 text

Oyobeさんにもプロジェクトの活動に入ってもらうことに 59 ● イベントにOyobeさんにコーチとして参加してもらう ● 普段のイベントをみてもらいながらその都度Feedbackをもらう ● 毎週続けてた1-on-1でさらにFeedbackをもらいつつ、今後について壁打ちをしてもらう

Slide 60

Slide 60 text

このプロジェクトを通して Oyobeさんとの壁打ちで得た気付き 60

Slide 61

Slide 61 text

自分の扱える範囲内にある変数と範囲外の定数があった 61 開発設計テスト自分が扱える範囲の変数チームリードマネジメント PjM PdM 営業企画マーケティング経営法務人事範囲外の定数

Slide 62

Slide 62 text

「私がこの範囲に閉じていたらこのプロジェクトは成功しないかもしれない」 62

Slide 63

Slide 63 text

思い切って範囲の外に手を伸ばしてみた 63 開発設計テスト自分が扱える範囲の変数チームリードマネジメント PjM PdM 営業企画マーケティング経営法務人事範囲外の定数

Slide 64

Slide 64 text

「手を伸ばしてみたら思った以上により上手くやれてる気がする！？」 64

Slide 65

Slide 65 text

そして範囲外にあった定数が自分が扱える変数になった 65 開発設計テスト自分が扱える範囲の変数チームリードマネジメント PjM PdM 営業企画マーケティング経営法務人事範囲外の定数

Slide 66

Slide 66 text

扱える範囲は広げられるし、広げることでよりソフトウェア開発が上手くなれたという気付き 66 開発設計テストチームリードマネジメント PjM PdM 営業企画マーケティング経営法務人事

Slide 67

Slide 67 text

ソフトウェア・プロダクト開発に更なる手応えを感じた 67 開発設計テストチームリードマネジメント PjM PdM 営業企画マーケティング経営法務人事

Slide 68

Slide 68 text

今後もっとこの範囲は広げられるのでは？？ 68 開発設計テストチームリードマネジメント PjM PdM 営業企画マーケティング経営法務人事範囲外の定数

Slide 69

Slide 69 text

扱える変数が増えるとソフトウェア開発が楽しくなる 69 これが私が技術以外の領域にしっかりと足を踏み出したきっかけとなった気がします。何となく技術以外の領域について色々理由をつけて蓋をして見ないようにしていただけなのだと気付いた。技術領域以外の変数を持ち合わせることで、もっと良いプロダクトを作れるようになるし、チームをもっとよくできるようになるのでは？

Slide 70

Slide 70 text

「チームを良くする」「コラボレーションする」ことへの意識の変化 70

Slide 71

Slide 71 text

それぞれが価値を感じてるものがある 71 チームコラボレーションエンジニアリングエンジニアリングコスパ省エネ

Slide 72

Slide 72 text

それは人それぞれの変数でしかない 72 チームエンジニアリングコラボレーションエンジニアリング省エネコスパ

Slide 73

Slide 73 text

それは人それぞれの変数でしかない 73 チームエンジニアリングコラボレーションエンジニアリング省エネコスパだからもっとみんなチーム活動をしようよ！チームを良くすること、コラボレーションすることに価値を持つのは当たり前だよね！！

Slide 74

Slide 74 text

相手から見ると変数ではなく定数なのかもしれない 74 チームコラボレーションエンジニアリング省エネコスパ自分にとっては当たり前じゃないんだけどな。。エンジニアリング

Slide 75

Slide 75 text

「チームを良くする」「コラボレーションする」は押し付けず観察から始まるものだった 75 チームコラボレーションエンジニアリング省エネコスパエンジニアリングここを観察する

Slide 76

Slide 76 text

プロジェクトを通してアジャイルコーチと伴走しての気づきと学びまとめ 76 ● 自分が扱ってた変数の範囲の外に手を広げる事の手応えと面白さ ● 「チームをよくする事」と「コラボレーションする」は押し付けるものではなく観察から始まること ● 上記二つから今まで自分が思っていたソフトウェア開発やプロダクト開発から大きく解像度が上がった

Slide 77

Slide 77 text

77 ● アジャイルコーチとしてチームや組織に関わるときは、最初からコーチがいなくなったあとのことを考えて支援のかたちを考える ● 役職やロールに関わらず、チームの核となっている・なりそうな人を中心にサポートをすることが多い（今回の場合それがKinjo-sanだった） ● Kinjo-sanの場合は、答えやそれにつながる情報はKinjo-sanの中にあることが多かったので、一緒に探索して認知する壁打ち相手になることが多かった無印の “コーチング ” に近い関わり方

Slide 78

Slide 78 text

Slide 79

Slide 79 text

チームリードをする前自分は「人をリードするタイプ」じゃないと思っていた 79

Slide 80

Slide 80 text

「自分は人をリードするタイプじゃない」とは 80 チームや組織に火をくべるリードをする仲間たちすごい、、真似できないなぁ。。

Slide 81

Slide 81 text

仲間との別れを経て代わりになろうとしたが 81 あの人達の代わりは自分にはできなかった。。

Slide 82

Slide 82 text

そんな時ある発表を思い出す 82 “チームにノリをもたらした時にいた「二人目に踊る人」の共通点 ” by piyonakajima-san Scrum Fest Osaka 2023 https://speakerdeck.com/piyonakajima/timuninoriwomotarasitashi-niita- er-ren-mu-niyong-ruren-nogong-tong-dian?slide=144 これは私がいつも思ってることだ

Slide 83

Slide 83 text

二人目に踊る人になろう 83 https://youtu.be/OVfSaoT9mEM 私火を起こす人を探したり背中を後押しするような場を作ることに注力しよう自分はファーストペンギンではなく二人目に踊る人だった

Slide 84

Slide 84 text

具体的にどんな事をしたのか 84 ● スクフェスやRSGTなどの視聴会を社内で多い時は週に一回開催 ● 有志で集まれるスクラム・アジャイル関連の輪読会を開催 ● 組織のブログ文化を復活させる活動

Slide 85

Slide 85 text

チームリードも誰かの火を大きくするために動こう 85

Slide 86

Slide 86 text

プロデューサー：楽天の職種でPdMとPjMの役割をしてくれる Oyobeさんと伴走した時のプロジェクトのメンバー構成 86 経験豊富なエンジニアプロデューサー私

Slide 87

Slide 87 text

私以外の人全員のために動こう 87 私 ● 皆がスムーズに仕事をやれる環境を作ろう ● プロジェクトを前に進めることであればなんでもやろう

Slide 88

Slide 88 text

具体的に何をしたのか 88 ● チームのスピードを緩めてしまうものを排除する ● チームが働きやすい場を整備する ● エンジニアと他職種とのハブになる全てキャリアを開始した時にはエンジニアの仕事ではないと思っていたもの

Slide 89

Slide 89 text

チームリードだからやらされていたのか？ 89 全て自分が必要だからという気持ちで行動していたので、やらされていたとかは全くなく、振り返ると自発的だったからなのか楽しかった記憶です。チームのために走り回るのも楽しいな

Slide 90

Slide 90 text

プロジェクトは予定通りサービスイン、大きなバグもなし 90 プロジェクトは成功だったのかなと思います。個人としては学びも多く、視野が広くなるきっかけだったと強く感じています。

Slide 91

Slide 91 text

振り返った時の反省点 91 チームを自律的にするための機会や学び成長は私が奪っていたかもしれない次はもっとチームの学びも重視しつつやれるようになりたい

Slide 92

Slide 92 text

92 ● Kinjo-sanは「一人目になれない」「二人目に踊る人だった」と言っているが、チームや組織にいる他の人から見たらKinjo-sanが一人目になっている ● おそらくKinjo-sanにとっての「一人目」も同じようにバトンを受け取っている ● Kinjo-sanが急に進化して新しいなにかをはじめたわけではなく、もともとやっていたことを、「それでいいんだ」と自分の中に腹落ちさせることができるようになったのでは？自分を認知して受け入れる

Slide 93

Slide 93 text

Slide 94

Slide 94 text

以前と比べてソフトウェアエンジニアリングに対する考えが大きく変化し定義が広くなった 94

Slide 95

Slide 95 text

95 “「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」〜略〜　ソフトウェアエンジニアリングはプログラミングではない。” “ソフトウェアエンジニアリング組織内では、生産するソフトウェアと、ソフトウェアを生産する組織、それら両方のスケールと効率に関してより配慮しなければならない。” https://www.oreilly.co.jp/books/97848731 19656/

Slide 96

Slide 96 text

96 “「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」〜略〜　ソフトウェアエンジニアリングはプログラミングではない。” “ソフトウェアエンジニアリング組織内では、生産するソフトウェアと、ソフトウェアを生産する組織、それら両方のスケールと効率に関してより配慮しなければならない。” https://www.oreilly.co.jp/books/97848731 19656/ 以前まではプログラミングだけをしようとしていたのかもしれない生産するソフトウェアだけに関心を払っていた

Slide 97

Slide 97 text

97 “ソフトウェア工学とは、ソフトウェアの現実的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことである。” https://books.rakuten.co.jp/rb/17370467/ ただし技術的なアプローチに限る

Slide 98

Slide 98 text

98 “ソフトウェア工学とは、ソフトウェアの現実的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことである。” https://books.rakuten.co.jp/rb/17370467/ ただし技術的なアプローチに限る技術的に限らずどんなアプローチもソフトウェア工学なのでは

Slide 99

Slide 99 text

つまり “チームや組織を良くすること PJを前に進めるために枠にとらわれない活動全てがソフトウェアエンジニアリング ” であると考えています 99

Slide 100

Slide 100 text

これが私が以前考えていたエンジニアリングとマネジメントの関係 100 マネジメントに近づくこと　＝　エンジニアリングと遠ざかるということエンジニアリングマネジメント距離がある・領域が重ならない

Slide 101

Slide 101 text

これが私が以前考えていたエンジニアリングとマネジメントの関係 101 マネジメントに近づくこと　＝　エンジニアリングと遠ざかるということエンジニアリング（プログラミングだけ）マネジメント距離がある・領域が重ならない

Slide 102

Slide 102 text

そしてこれがスクラム・アジャイルに出会った頃の私が考えていた関係 102 マネジメントスクラムエンジニアリングプログラミング

Slide 103

Slide 103 text

今考える私のソフトウェアエンジニアリング 103 ソフトウェアエンジニアリングスクラム・アジャイル開発マネジメント

Slide 104

Slide 104 text

…ベン図のような重なりとかではなく自分の考えはちょっと違う？ 104

Slide 105

Slide 105 text

私の考えはこのような感じです 105

Slide 106

Slide 106 text

ソフトウェアエンジニアリング 106

Slide 107

Slide 107 text

ソフトウェアエンジニアリング 107 スクラム・アジャイル開発マネジメント

Slide 108

Slide 108 text

ソフトウェアエンジニアリング 108 スクラム・アジャイル開発マネジメントプログラミング

Slide 109

Slide 109 text

ソフトウェアエンジニアリング 109 スクラム・アジャイル開発マネジメントプログラミングコミュニケーション

Slide 110

Slide 110 text

ソフトウェアエンジニアリング 110 スクラム・アジャイル開発マネジメントプログラミングコミュニケーション NVC マインドフルネス EQ 教育心理学モブプロ・ペアプロ XP TDD AI サーバントリーダーシップデザインパターン設計力コンピューターサイエンス心理的安全性プロジェクトマネジメントビジネス

Slide 111

Slide 111 text

ソフトウェアエンジニアリング 111 スクラム・アジャイル開発マネジメントプログラミングコミュニケーション NVC マインドフルネス EQ 教育心理学モブプロ・ペアプロ XP TDD AI サーバントリーダーシップデザインパターン設計力コンピューターサイエンス心理的安全性プロジェクトマネジメントビジネス私にとってここの全てがソフトウェアエンジニアリングの一部だという考えになりました。

Slide 112

Slide 112 text

マネジメントは本当にこわいのか？ 112

Slide 113

Slide 113 text

マネジメントへの抵抗感は恐怖だった 113 エンジニアリングマネジメントエンジニアリングが遠ざかるという恐怖

Slide 114

Slide 114 text

ソフトウェアエンジニアリング 114 スクラム・アジャイル開発マネジメントプログラミングコミュニケーション NVC マインドフルネス EQ 教育心理学モブプロ・ペアプロ XP TDD AI サーバントリーダーシップデザインパターン設計力コンピューターサイエンス心理的安全性プロジェクトマネジメント

Slide 115

Slide 115 text

マネジメントはソフトウェアエンジニアリングをうまくなるためのパズルのピースに一つに過ぎないのかもしれない 115

Slide 116

Slide 116 text

そしてマネジメントに限らず範囲の外に手を伸ばしてみればもっとソフトウェアエンジニアリングが上手くなれるかもしれない今はこれを広げていく事に価値を感じてワクワクしています 116 開発設計テストチームリードマネジメント PjM PdM 営業企画マーケティング経営法務人事範囲外の定数

Slide 117

Slide 117 text

まとめ 117 ● エンジニアリングから離れたくなくてマネジメントを避けてた ● 仲間との出会いでスクラム・アジャイル開発に学びの価値観に共感した ● アジャイルコーチ（Oyobeさん）との伴走でエンジニアリングの視野が広がった ● 扱える変数を広げられる事の面白さと手応え ● マネジメント・スクラムは恐怖の対象ではなくエンジニアリングのためのパズルのピースでしかないという考えに変わった