新卒エンジニア2年目のふりかえり
思っていたより読んでいた書籍が多すぎて見通しが悪いので簡略版作りました。
はじめに
まえがき
今年度は自分が大きく成長が出来たと同時に、自分の進むべき・進みたい道がはっきりと分かった（自覚することができた）年になります。
去年とは打って変わり、今年はさほど技術のことはやっていません。しかし、それでもっても自分が成長できた、という実感が持てています。
余談ですが、ふりかえりを書き始める前に「サナギ」「羽化」などの区切り方をしていたのですが、調べていると「ワラスの４段解説」というものが出てきて、ピッタリ当てはまるなぁと感じたので採用してみました。（本来はこういう用途ではないですが・・・）
今後自分と似たような方の参考になればなと思います。
2022年は自分の人生が大きく変わった年です。
その機会を作ってくれたチームのみんなやHajimariで採用に携わってくれた方、関わってくれた方々、そしてHajimariアドベントカレンダーがなければこのふりかえりは実施されなかったと思います。Hajimariアドベントカレンダーを作成して流れを作ってくれた草野さんや前日までの投稿者へ感謝を。
ありがとうございます!!
なぜふりかえるのか
自分の人生のMissionとして「みんなが楽しく働ける社会にする」というものがあり、そこからVisonとして「自分と関わる人が幸せになる環境をつくれる人になる」というものがあります。
そのVisionに向かって一年行動出来ているのか、という点でふりかえりをします。
そうすることで一年間の行動を「検査」できます。
もし行動がVisionに向かっていないことがわかれば「適応」が必要なことがわかりますし、軌道修正も早いほうがコストは最小で済みます。
自分のVisionに対して自分の行動を検査するのがこのふりかえりの目的です。
総評
「なぜふりかえるのか」に書いたVisionは今年の１月から持っていたVisionではありませんでした。
実際の話では、3月頃に漠然としたイメージが湧き、そこから時間を経ると共に認識が強まったというほうが的を射ていると思います。
ただ時間を経ただけで認識が強まったかというとそうではなく、スクラムを通してアジャイルの概念に触れ、自分が求めていたもの・自分が考えていたこと・自分が実現しようとしているものがアジャイルそのものだったのだと理解したときに一気に強まりました。
これまでははっきりとしたVisionがなく生きてきていて、がむしゃらに目に見える範囲で「技術力を高める」だとか「コミュニケーション力を高める」だとかに取り組んできました。
しかし、自分の心はやはり満たされることはなく、本当にこのままでいいのだろうか？という「焦燥感」を感じる日々でした。
そこで一変、今年はこのVisionというものがはっきりと分かったため、そのVisionを達成するために「自分に足りないものは何なのか」や「Visionを達成するのに効果的なことは何なのか」を軸に、限られた人生の時間を効果的に使えるようになったのです。
今年成長したかどうかは正直イマイチわかりません。
しかし、確実に言えるのは 「自分の行動１つ１つに自信を持てる」 ようになったためこれから歩んでいく道は 「確実に自分の人生を豊かで楽しいものにしていく」 道になっていくことを確信しています。
そして、これから自分のVisionを実現するためにコミットし続ける予定です！
ということで2023年もよろしくお願いします。
追記
時期に合わせて買ってた書籍や記事を書いていたら結構な量になってしまったので、言い訳というか自分の性質であるストレングスファインダーの画像を貼っておきます。
伊達に１番目に出てくる性向は嘘ではない。
準備期
1~2月 チーム開発と組織開発と無知の私
1月中は正直関わっていた案件が忙しかったのと、年末年始でたくさん稼働した結果、代休が多めに取れていた月でした。
折角できた時間を無駄にしたくないため、技術書が大好きな自分は本を色々漁っていました。
ちゃんとは覚えていないが、この時はある程度「人」の方に自分の興味が移り、問いかけの作法からチームの能力を引き出すためにはどうすれば良いのか？や誰もが黙っていて、主要な人１人が喋っている会議をどうすれば解決出来るのか？という点を考えていました。
同時に競プロアルゴリズム本やリファクタリング本、Rustの本を購入し積んでました。
このときもまだテストコードを追い求め、チームが楽しく開発出来るためにはどうすれば良いのか？という点を考えていました。
「チームを幸せにしたい」「幸せに開発をしたい」「チームが幸せじゃないのに良いプロダクトは作れない」ということに気づき、技術的分野からアプローチをすることによって解決しようと考えていたのだと思います。
テストコードがあればある程度ゲーム感覚で開発ができるし、規則もある程度決まっていたほうがスムーズに開発もできる。
設計も乱雑なもので保守が大変なものよりは、拡張しやすい・読みやすいコードのほうが修正コストが低く楽しく開発ができる。
この考えのもと突き進んでいた頃になります。
そして同時に「このままでいいだろうか？」という疑念も抱えていました。
関わっている案件は技術的負債が山積みで技術的な成長もさほど見込めない。そんな状況に身を置き続けていて本当に良いのだろうか？という疑念です。
毎日バグ修正とバグ原因調査を行う毎日、そもそも楽しくありません。
プロダクトの目的も「ビジネス」が前面プッシュされており、「人を不幸にしている」アプリな気がしてしまって内発的モチベーションを維持できなくなっていました。
「技術の力で世の中を便利にして幸せな人を増やす」という夢を持ってIT業界に入った自分が「人を不幸にしているかもしれない」アプリ開発に携わっていて、実際に目の見える範囲でチームメンバーが不幸になっていく姿を見てて辛いものがありました。
本当にこのままでいいだろうか？と。
この時期に書いていた記事
自分が内省好きなのが見て取れます。
この時期に買っていた本
問いかけの作法 チームの魅力と才能を引き出す技術
問いかけの作法は自分の考え方を新たな場所へ切り開いてくれました。
きっかけはfukabori.fmの会だったが、考え方が素敵な点で大きく心が惹かれました。
今も時に時間を作ってCULTIBASE のポッドキャストは聴いてまなびを得ています。
問題解決のための「アルゴリズム×数学」が基礎からしっかり身につく本
途中まで読み積んでしまった・・・。すまない・・・。
リファクタリング(第2版): 既存のコードを安全に改善する
非常に学びになる書籍。すべて実践できているとは言えないが考え方の礎にはなっています。
コンセプトから理解するRust
結局一度も読まずにメルカリでキレイな状態で売ってしまった。Rustに触れる日はあるのだろうか・・・。
孵化期
3~5月 心理的安全性とアジャイルと組織開発
疑念を感じてからひっそりと転職活動を行っていた時期です。
その転職活動の中で自分が感覚的に生きていたのだということを実感させられ、一冊の本に手を出しました。
それが「言葉にできる」は武器になる。 です。
表面上のコミュニケーションスキル（How）を鍛えたとしても、考え方や意見がなければ薄っぺらい人間として見られてしまう。
その「意見」の考え方をこの本は教えてくれました。
後半部分はHowが多めで前半部分しか精読はしていないが、自分が考えるクセを付くキッカケになった１冊です。
この時期のブログ記事を見るともろに影響されていますね・・・。
それと同時期に学んでいた心理的安全性から組織開発に繋がり興味が沸きました。
そして偶然、テストコードのことが載っているということで気になっていたGoogleのソフトウェアエンジニアリングという書籍を読んでいました。
ユニコーン企業のひみつという書籍も前から気になったので読んでいました。
おそらくここらへんで気づいた事実があります。
組織が悪くなってしまうのは仕組みのせいなんだと。
会社におけるVisionやValueが重要であることをここで強く意識しました。
みんな同じ人間ですからみんな楽しく生きて幸せを感じたいはずです。
なのにギスギスしてしまったり、上手くお互いに理解しあえなくて冷戦になったり。
人間は環境に左右されやすいです。生まれ育ってきた地域や周りの環境、そして信条やマネジメント。
少し前の話ですが、専門学校の時に初めての海外旅行でハワイに行った時、ハワイの人は「Thanks」「Mahalo」が挨拶のごとく飛び交っているところにカルチャーショックを受けました。
国が違うだけでこんなにも「ありがとう」の言葉が交わされる量が違うのだと。
海外旅行をする前はコンビニなどで「ありがとうございます」という言葉を恥ずかしくなかなか大きな声で言えなかったのですが、帰国後は相手にちゃんと伝わるように言うようになりました。（今もです）
これも日本が悪い！と言いたいわけではなく、おそらく「お礼を言うのが恥ずかしい」と感じてしまうような何かしらの社会の仕組みがあるのだと感じています。
そんなことを考えつつ、前職の会社で「心理的安全性を高めるチーム」のリーダー（明示されていたわけではないですが）として色々施策を考えていました。
チーム内での雰囲気は悪くはなかったのですが、チーム内で対話が本当にできていたのかどうかは今ふりかえってみると出来ていなかったと思います。
少し仲良しグループ的なチームになってしまったのかもしれません。そしてそのチームを運用してみて「自己組織化」の重要性を肌で実感しました。
「自己組織化」で促されていないチームでは「コラボレーション」は絶対に起こりません。
「誰かに何かをやるのをお願いする」では真のコラボレーションとは言えません。
チームのメンバーその人自身が自主的にチームの目指しているビジョンに対して「よくしよう！」と行動し、他の人と協力することこそが真のコラボレーションなのだと思います。
余談
こちらの４月の記事ですが、自分が受けていた「新卒」扱いから感じた興味深い文があったので余談として引用します。
ラベリングと役割
新卒で会社に入社し、上司を持ち、新卒の扱いを受ける、ごく普通の流れだ。
人間は無意識にラベリングをし、役割が人を作る。
つまり、新卒 というラベリングを受けて、新卒 という扱いを受けていると「自分は新卒らしく振る舞わなければいけない」「新卒なので会社のことを全く知らない」「新卒は学生気分」のような考えに近づいていく。
そうなってしまうと発言は減り、ある程度会社の内情を知るまでは黙ってしまう。負の連鎖である。
「新卒だから優しくしよう」だとか「新卒だからゆっくり伸びていってもらおう」というのもラベリングが悪さをしている。別に新卒じゃなくても優しく接するべきだし、新卒でなくてもゆっくり伸びていってもらえれば良いじゃないか。
会社の雰囲気・構造を変えようと思って新卒を雇い始めたが、新卒を新卒として扱っているようでは変わらない。そしてこの状況が多く起きると「新卒を雇うのは会社の考え方に染めるため」と言われてしまう。
そして、これは他の事にも言える。上司だから伝えづらい、PMは何もわかっていない、社長は末端のことを全く理解できていない。といったことだ。
新卒じゃないからイノベーションを起こせないのか、そうではない。誰にだって変えることはできる。 そのマインドが重要なのではないだろうか。
そして今自分は「新卒エンジニア２年目のふりかえり」と「新卒」ラベルを使っている。
なぜなら、人はラベリングである程度相手のことを推し量るので「新卒」と付けることで、多くの「新卒」に見てもらえることを狙って付けているからです。
そしてラベリング自体が悪いのではありません。ラベリングによって抽象化して見ることができますし、人間の習性になるのでここはしかたがないことです。
セカオワの曲でも言ってます（最近知りました）
問題はラベリングした結果のラベルとして人を見ることです。
この時期に書いていた記事
この時期に買っていた本
「言葉にできる」は武器になる。
なぜなぜ分析など巷でよく聞く手法の「なぜ？」がきちんと説明されている書籍で人生の糧となりました。
Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス
なかなかの分厚さがあり学ぶことがたくさんあります。
テストコードの章もかなり核心に近いことが書いてあり勉強になりましたが、それ以上にエンジニア文化について書かれています。
後半部分のブランチ運用などは飛ばしてしまったのですが、また機会があれば読み直したい書籍です。
プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで (Software Design plus)
TypeScriptをかくことになりそうだったのでTypeScriptにちゃんと入門しました。
良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
背伸びしてクリーンアーキテクチャやDDDに手を伸ばしていましたが身の丈にあったところから理解しようと購入して読んでいました。（めちゃくちゃ勉強になりました）
デジタルトランスフォーメーション・ジャーニー 組織のデジタル化から、分断を乗り越えて組織変革にたどりつくまで
DXという話題が身近にあり購入しましたが、自分にはかなり遠いところにある書籍だったと感じ前半部分で読むのをやめてしまいました。
ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics
ポッドキャストの影響で購入した書籍です。技術とマーケティングの間で「どうしたらマーケットで利益を生み出せる高品質なプロダクトを生み出せばよいのか」というマーキテクチャという考え方が書かれた書籍です。
買った当時は難しく読めなかったのですが、今の段階だと読めるし理解できる感じがしたので（めくった感じ）時間があるときに読んでみようと思っています。
失敗から学ぶRDBの正しい歩き方 Software Design plus
DB設計なんてしないのですがアンチパターンと聞くと気になってしまうのがエンジニアの性。「やっちゃいけないこと」を学ぶのは「失敗」を疑似体験できるのでとてもコスパが良いです。
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
アジャイルに初めて興味が湧いた書籍です。当時読んだときは「理解した気になっていた」ことが分かりました。（ユーザーストーリーマッピングとかもちゃんと書いてるのに後で見返して気づきました）
現在でも困った時は「むきなおり」や「インセプションデッキ」の参考にするため手に取ることが多いです。
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
カイゼン・ジャーニーの続編になります。こちらもかなり凝縮されているので読んでいて楽しく学びになります。
ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本
DDDを理解しようと努力をしていた時に購入した書籍です。（結局のところざっとしか読めていませんが・・・）
問いのデザイン 創造的対話のファシリテーション
問いかけの作法から派生して気になった書籍です。購入時はワークショップを実施する機会がほとんどなかったため優先順位を下げてしまって積んでしまっているのですが、最近はワークショップをして課題に向き合えるような環境づくりもしていきたいので近いうちに目を通したいです。
オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)
ピアソンショック時代に生まれた良書です。
オブジェクト指向を理解するにはこの頃の書籍を読まないと理解が深まらないとt_wadaさんがポッドキャストで言っているのを聞き購入しました。
読み勧めてみるととてもおもしろい本です。辞め時を失ってしまいます。
ですが、かなりカロリーを使う本でもあるので読むのであれば章区切りで読むのではなく、途中途中で区切りながら読むほうがよいでしょう・・・。
アジャイルな時間管理術 ポモドーロテクニック入門
ネットの記事にかかれているポモドーロのやり方だけで実施していましたがなかなか続かず・・・。
そこで、１冊書籍を読みHowだけではなく「なぜやるか」を理解しようと読みました。
結果、ポモドーロが達成しようとしている目的や背景を理解することが出来たので今ではポモドーロの虜です。
6~8月 迷い
この時点では明確なVisionを持っていなかったため、ただ漠然と「みんな幸せに働けるには？」という問いを基準に日々過ごしていました。
同時に自社開発プロダクトの部署に移動したのですが、受託とほとんど同じという実感を得ました。
基本的に修正タスクががあり、それを直していく。
「なぜ」このプロダクトが必要なのか、「なんのために」この修正が必要なのか。
それがいまいち分からず、ただただ単純作業としてこなしていました。
この時に技術的な成長があったとしても、マインドセット的な成長は一切なかったと思います。
日々降ってきたタスクをこなすだけの毎日。
その状態で自分の中で
「本当にこのままでいいんだろうか？」
「３０歳になった時、自分は漠然と思い浮かべている姿に鳴っているのだろうか？」
という疑問が頭の中を駆け巡っていました。
結局その場にずっと居ても理想の姿とは遠ざかっていくだけだと感じて転職を決意しました。
余談: 燃え尽きと鬱
この時心理的安全性ゼロの状態でのペアプロは絶対に成り立たないのだと理解しました。
自分が転職を決意した要因としてあるのが、心理的安全性ゼロのペアプロがずっと続くかもしれないと感じてしまったからかもしれません。
一時期はこの状態が続き、メンタル的に参ってしまった時期がありました。
自分の性格的に一日休むことで復帰することが出来たのですが、一番きつかった日は頭がボーッとしてしまい、何も考えることができませんでした。
一緒に支えてくれた彼女に感謝しています。
この時期に書いていた記事
技術的な記事をたくさん書いてました。張りすぎると埋まってしまうので詳しくはZennをご参照ください！
この時期に買っていた本
私たちはどう学んでいるのか ――創発から見る認知の変化 (ちくまプリマー新書)
人間が学ぶ仕組みを理解して効果的に学ぶことが出来ないか知りたくて購入しました。途中まで読んで積んでしまっています・・・。
最高のチームはみんな使っている 心理的安全性をつくる言葉55
心理的安全性が低い環境をもろに受けて育ったので、心理的安全性を高めるにはどうすればいいのかを模索している最中に購入した書籍です。
ここから得た問題が起きた時に「それちょうどよかった！」という言葉を使う運用は今でも重宝しています。
ユースケース駆動開発実践ガイド
DDDを学び、ドメインってどうモデリングすればええねん！ってなった際に読み始めた書籍です。これも結局中盤くらいで積んでしまっていますが考え方が非常に参考になるので気になる人は読んでみてもいいかもしれません。
エンジニアがビジネスリーダーをめざすための10の法則
実際DevとBizはどのくらい差分があるんだろう？とおもって見た書籍です。
なかなかエンジニアを下げているような気がしましたが、実際問題そう見えているのだろうと感じながら読んでいました。
印象的なのは「お母さんにも分かる言葉でしゃべる」です。
スクラムで、スプリントレトロスペクティブやスプリントレビューやらデイリースタンドアップみたいな語をそのまま伝えてしまうのが良くないんだろうなぁと思う反面、ある程度スクラムの理解が深まった今はあえてそのまま語を使って「認識のギャップを埋める」という用途では全然お母さんに分からない言葉でもいいのかなと感じています。
「ふりかえり」や「朝会」と伝えてもいいのですが、やはりどうしても人によって持っているニュアンスが異なっていたり、前提経験が異なるので齟齬が発生しやすいです。
意味わからない言葉を使って、そこから対話を始めるキッカケにしてもいいのかなぁと考えています。
Web API: The Good Parts
WebAPIの設計ちゃんと学ぼう・・・と思って購入した書籍ですが今は本棚の肥やしになっています。
恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす
心理的安全性を学んでいく上で外せない書籍だと聞いたので購入しました。興味がある章しか読んでいませんが学びになる書籍です。
More Effective Agile “ソフトウェアリーダー”になるための28の道標
「アジャイル」というものに対して興味を持った時に読んだ書籍です。このときはアジャイルは開発手法として見れていなかったため、イマイチ理解出来ていませんでしたが今見てみると全く違った内容に見えると感じています。
独学大全――絶対に「学ぶこと」をあきらめたくない人のための５５の技法
読書法でしっくりくる方法がなく、イマイチ読めている実感がありませんでした。その疑問を解消すべく購入して読んでいた書籍です。
体系的に様々な方法が乗っていたり、逆引きもできるので良い書籍でした。
めちゃくちゃ分厚い書籍なので電子版推奨です。
Clean Architecture 達人に学ぶソフトウェアの構造と設計
結局のところクリーンアーキテクチャを全く理解していなかったことを思い知る場面があったため購入しました。
しかし活用の場面と優先順位が落ちてしまったためコレクションになっています・・・。
EQトレーニング (日本経済新聞出版)
これからの時代はEQだ！という理由で買ったわけではないですが、心理的安全性を学んでいくうちにEQってめちゃくちゃ重要なんじゃないか？という疑問から購入しました。これも途中で積んでしまっています・・・。
啓示期
9月 決断
9月から転職を行い、株式会社Hajimariで働いております。
いろいろ紆余曲折があったのですが、自分の人生のVisionから共感できる会社はHajimariしかないと思ったのが決め手です。
入社後、最初の1ヵ月は前職で学んだことを上手くアンラーニングしつつ、Vueを触りつつ、自社プロダクトを開発していました。
前職は基本的にフルリモートだったので多くの人と一緒のオフィスで働く感覚に慣れるまで時間がかかりましたし、新鮮でした。
そして、プロジェクトの内容を理解しつつ、Vueの理解を深め、Notionの整備など行ってました。
最初は「どこまで自分がやっていいのだろうか」という気持ちがあり、なかなか能動的に動けていませんでした。（自己組織化できていなかった）（ここは仕組みでいうとデリゲーションポーカー・デリゲーションボードで解決できます）
そして段々慣れてくると同時に「受託開発」とやってることが一緒では・・・？と感じてくるようになりました。
自分は何のために開発をしているのか。
自分は降ってきたタスクを淡々とこなすだけなのか。
そしてこれはチームのメンバーも同じコトを感じていました。
このままだとまた自分は辛くなってしまい辞めてしまうような気がしました。
そこで上の課題を解決しようと模索した結果出会ったのが「スクラム」でした。
スクラム（とアジャイル）の概念はHajimariのVision, Valueを体現するようなものです。
スクラムは変化に適応するアジャイルの軽量フレームワークと理解されることが多いのですが、真価は自己組織化したチームを作ることにあります。
スクラムの柱として「透明性」は自己組織化するためにも必要な要素です。
目的・背景がいわゆる「上」の人だけで揉まれ、開発チームは「要件」だけをこなすようになってしまうと自己組織化は難しくなります。これが「透明性」が必要な理由です。
そして、スクラムでは様々な職種やステークホルダーとチームになって1つのプロダクトを創り上げていきます。
定期的にステークホルダーに実際のように触ってもらい、プロダクトが課題を解決するものから遠ざかっていないかを検査します。
これらの考え方は「Hajimariをジブンゴト化」「ユーザーと向き合い続ける」というValueと同じベクトルです。
そして自己組織化されているということは自立しているということです。
「チームが自立して、使う人が幸せになるプロダクトを開発する」
これはHajimariのVisionと同じベクトルです。
このVisionとValueが自分の背中をアトオシし、チームにスクラムを導入する決断に繋がりました。
ワイが…ワイがやるんや…！
— やむ🐶👉 (@yum3_tech) September 26, 2022
実はこの決意がその瞬間です。
この瞬間から自分の中のスクラムマスターが立ち上がったのです。
実証期
10~12月 スクラムマスターとアジャイル
9月の決意からスクラムの導入し、正しくスクラムをしていくために大量にインプットをしました。
下に記載している本一覧を見てもらうと分かりますが、めちゃくちゃ書籍を購入し読みました。
この書籍達1冊1冊が自分の糧になってくれています。
10月はスクラムイベントの進め方さえ分かっていない状況だったので「なんちゃって」スクラムにならないように注意していました。
またチームに伝播させていくときに「なんちゃって」でも良い雰囲気にして腐らせないように心がけていました。
スクラムを進めていく中で学んだことが3つほどあります。
それは「自己組織化」「傾聴」「効果的」です。
1つ目の自己組織化についてです。
初めてのふりかえりの時にふりかえりを進める雰囲気を全員で決めたり、テーマもみんなで決めるようにしていました。
これは書籍に書いてあったHowをそのまま実施する「守」だったのですが、今となっては理由が分かります。
こういうチームの決め事を誰かが率先して意思決定をしてしまうと自己組織化が阻害されてしまいます。
チームで決め、チームで責任を持つことで初めて真のコラボレーションが生まれます。
権限移譲では実現しない真のコラボレーションです。その状態を実体験で得ることができてとても良い経験でした。
その延長として、何か話すときに主語を「わたしたち」にすることを強く意識していました。
主語を「わたしたち」にすることで無意識のうちにチームであることの認識を強めるようにです。
そして、2つ目の傾聴についてです。
スクラムを進めていく上で自分がやっていきたいこととチームの活動の乖離がある程度目に付きました。
「スクラム的にやりたいもの」に対してどうしても否定的な人がいた時に「説得しよう」と思ってしまったのです。（実際に説得はしませんでしたが）
でもゆくゆく考えてみると、その人も何か否定的になってしまう経験を持っていて、そこから「やりたくない」に繋がっているのだと理解しました。
その人が持つ過去や経験、価値観を無視して説得する。今考えるととんでもなく失礼な行動です。
そこで気づいた概念が「傾聴」です。
どんなに言いたいこと、どんなに聞いてて指摘したいところがあったとしても反論や意見を述べることはなく、ただただ聞きます。
まずは相手のことをよく知り、理解する。
このステップの大切さを実感しました。
傾聴はまだまだ自分の中でもそこまで上手にできない点なのですが、これから「私」「私達」「世界」という3つの概念で傾聴ができるように努力していきたいところです。
そして最後が効果的にやることです。
以前まで自分は「効率的に」やることに囚われていました。
量より質、みんなが思っていることです。
ですが、組織で行われていることを「効果的」か「効率的」かのメガネで見てみると意外と「効率的」に行われているものが多くあります。
効率だけを考えるのであれば雑談は悪であり、意思決定もないほうが効率的になります。（意思決定をする人・仕様を決める人・コードを書く人・テストをする人みたいに）
しかし、効果的という面で見てみると「対話」を大切にしないと間違った方向に進む可能性があり、効果を高めるのであれば「対話」こそが重要な要素だと分かります。
これが「効率」にとらわれてしまうと大事なものを見落としてしまう可能性がある理由です。
少しずれますが、前職でフルリモートの時は「テキストコミュニケーションこそが至高」と思っていました。
テキストであれば漏れなく伝えることができ、文字として残る。そんな考え方です。
しかし実際には完璧に伝えることなんて出来ません。声の抑揚や素振り、そしてお互いのリアルタイムで行われる会話から連鎖して想像・思い出されることがたくさんあります。
ミーティングは非効率です。
でも、人と人がコラボレーションしていくには必要不可欠なアクティビティであり、効果的に物事を進めたいのであれば時間をかけるべき点だと思いました。
以上が自分が学んだ点になります。詳しく書き始めるとキリがないので必要最低限だけにします。
そんなこんなで3ヵ月スクラムを実施してきてチームはプロダクトと向き合い、ユーザーと向き合い、チームと向き合うことができるようになったと思います。
開発チーム以外にも実際に使うチームと関わるようになりましたし、プロダクトの方向修正も以前に比べて加速しました。
まだまだチームとして成長はできるポイントはあると思いますが、それはチームで気づき、チームで話し合い、チームで成長していくことです。自分から「してほしくて」提起することはありません。
「できない」前提でマネジメントするのではなく、「できる」前提で個性を引き出すように人と関わっていくように。
スクラムマスターとしてはそのように心がけています。
余談: 健康とアジャイル
以前から気になってはいましたが、11月頃から身体（おもに肩甲骨あたり）に疲労がたまりすぎていて業務に集中できない時期がありました。
このままではいけない、と思い「アジャイルで」健康をハックできないか考えていました。
そこでちょうど「健康とアジャイル」という完全に自分が狙われたタイトルの書籍があり、その本をベースに健康に向かうために時間を作り始めました。
めちゃくちゃ怪しいボッタクリ整骨院から猫背の重大度を理解し、良心的な整骨院からストレッチポールの有用性を理解し、本から栄養の大切さとNEAT（非運動性熱産生）の重要性を理解しました。
プライベートにおける習慣管理・タスク管理をスクラム的にまわしているため習慣化はさほど問題にならず、毎日ストレッチポールで決められたストレッチを行うようにした結果、今では悩まされることはなくなりました。
途中猫背矯正ギプスなども購入し、脳に正しい姿勢を理解させるなどの工夫もしていましたが、以前に比べると肩も開き別人のようです。
2年間のデスクワークで溜まった疲労（身体的負債）が解消されつつあります。
ぜひみなさんもストレッチポールを買ってストレッチしましょう！！
この時期に書いていた記事
アドベントカレンダーに参加していたのでそっち方面でのアウトプットが多くあります。
また、ある時から毎日のふりかえりをnoteでやろうと思ってから平日は毎日書いています。
この時期に買っていた本
アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット
ふりかえりをする上で今も参考にさせてもらっています。場の作り方から目的に合った手法紹介まで、とても助かっています。
アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
アジャイルの前提知識が必要な書籍から入ってしまったので、もう少しアジャイルに対する知識がなくても読める書籍を探して、他の人からはどう見えるのかを学ぶために買いました。いろいろな事例が載っていて面白いです。
SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ
スクラムマスターとして持っておくメタスキルやマインドセットが書かれているため参考になりました。今も時々手にとって目を通しています。
エッセンシャル スクラム
スクラムを「なんちゃって」で進めないために辞書・経典として持っていた書籍です。この本をベースにまずは型として実施していました。
エクストリームプログラミング
スクラムはどちらかというとソフトスキル面に絞られています。実際に技術的な面の品質担保などを支えるためにはどうしたらいいのか？という点で読み始めました。
世界№１プレゼン術
スクラムマスターとしてチームの障壁を退けられるスキルが欲しくて読みました。アジャイルの考え方に則っていて面白かったです。
アジャイルエンタープライズ
アジャイルを組織レベルに活用していくにはどうしていくかが書かれています。セールでやすかったので買いましたが手を付けられていません。
世界のエリートはなぜ「美意識」を鍛えるのか？～経営における「アート」と「サイエンス」～ (光文社新書)
マインドセットが大切という考え方から気になって購入しました。これも読みたいのですがなかなか手を付けられていません。
「アジャイル式」健康カイゼンガイド
ぼくの健康を作ってくれました。
アジャイルリーダーシップ: 変化に適応するアジャイルな組織をつくる
色々読んできた中で気になる分野の知識まで書かれている書籍です。
これまでの組織はどんなで、どんな問題があるのかということや、アジャイルリーダーとして何をしていく必要があるのかを具体的なHowと共に書かれています。
今年イチの書籍を決めろと言われたら、迷わずこれを選ぶかもしれません。
アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～
ベロシティが安定しなかったり、プランニングポーカーが本当に合っているのかどうかが気になり購入しました。また、リリース計画も立てて「遊びではない」スクラム実現のための糧にしました。
ゾンビスクラムサバイバルガイド
「なんちゃってスクラム」にならないようにする書籍です。ここからステークホルダーを交えてのスプリントレビューの重要性を理解しましたし、「なんちゃってスクラム」にならないためのアンチパターン本として役に立ちました。
ユーザーストーリーマッピング
「要件」は「黙れ」という言葉と同意義だ。という節から自分の中でブレイクするーを起こしてくれた書籍です。
「要件」はやることを簡潔にまとめられている事柄ですが、「なぜやるか」「なんのためにやるか」が削ぎ落とされている、ということを理解しました。
アジャイルコーチング
コーチングとは何かを教えてくれました。まずは自分でやって見せるのが一番コーチングだということを理解してなかったため、途中まで口だけマンになっていたのを理解しました。
カンバン仕事術
気になって買ったのに読めていない・・・。
エッセンシャル思考 最少の時間で成果を最大にする
アジャイルに通じる事があると思って買いましたが読めていないです・・・。
エフォートレス思考 努力を最小化して成果を最大化する
アジャイルに通じる事があると思って買いましたが読めていないです・・・。
マネージング・フォー・ハピネス——チームのやる気（モチベーション）を引き出すゲーム、ツール、プラクティス
Management 3.0という概念を知ってからもっと楽しくチームが動けるようにするにはどうすればいいか？と感じたため購入し読み進めています。
来年はここにかかれているプラクティスをやってみてもっとチームを楽しくしていきたいですね。
来年のTry
2023年はアジャイルの概念を自分のチーム以外にも伝搬させていき、自己組織化されたチームの数を増やし、複雑な物事に対しても対応していけるような状態にしていきたいです。
少しでも仕事を、楽しく、人生を豊かにするものに感じられる人を増やし、「やらされている」感でつらい思いをする人を0にしていきたいです。
おわりに
かなり長くなってしまいましたが、いろいろあった1年だったので考えることが多くなってしまいました。（しっかり読んでいただいた方はありがとうございます）
これを書いている中で週次・月次でふりかえりをしていかないといけないということも実感しました。
期間が大きくなればなるほどアクションが抽象的になってくるので、丁度いい期間で検査していきたいですね。
この記事が気に入ったらサポートをしてみませんか？