2022年の振り返りと開発プロジェクトの進め方について
気づけば2022年も年末。
犬の散歩をしたり大掃除をしながらふと今年を振り返りながら、プロジェクトの進め方や管理、特に"アジャイル"について少しだけ考えたり感じたりしたので、それのメモも兼ねて書きます。
前提
自社サービスのバックエンドサービスの開発・運用に携さわっている。
年齢は30代後半で、エンジニアとしては十数年働いており、現在の会社は2社目で4年超の在籍になる。
- 周りの元同期や年次が同じくらいのエンジニア界隈の方も、組織を率いていたりグループやチームなどをリードしていく立場にある人が多い
- 一方で自分の所属している会社では「スーパーフラット」という組織構成になっており、開発部隊ではCTOが居てその下は全員、上下関係といったヒエラルキーの無いフラットな組織である
チームは領域やサービスによって分かれておりチームごとに文化の違いはあるものの、基本的には開発方式はアジャイルで「スクラム」を基本としたものが採用されている。
最近感じていることや取り組んでいること
（これは以前からの課題であるが）"フラット"であるがゆえの自由さや物事の進めやすさがある。
- 一方でそこのいわゆる勘所が"経験"や"個々人の指向"などに依存している部分が多く、特に経験の浅い、いわゆるジュニアメンバーはここがつかめず苦労している印象がある
- さらにコロナでリモートワークがメインになり今後も続いていくことが決まっているので、この流れはさらに加速していくと考えられる
今までは「スプリント内の定期進捗MTG（週1程度）」や「振り返り」などでここをカバーしていたつもりだったが、なかなか報告・相談のタイミングがうまくつかめなかったりという状況が発生していた。
- 対策として最近は「デイリーハドル」を開催するようにしてみていて、一定の効果が出ているように感じている
- ただ、一方でデメリットとして全体の進捗が見えづらくなっているという面もあり、これは進め方の工夫が必要だと考えている
ジュニアメンバーで、自分でも課題を抱えている自覚はあるがどうして良いのか分からない状態に陥っているように見えるメンバーが居り、1on1で本人の課題感やアドバイス的なことなどをお話させてもらった。
- それを皮切りにせっかくなのでと考えて、メンバー全員と1on1をしてみた
- リモート中心になってから一緒に仕事をするようになったメンバーも多くいることなどから、メンバーの意外な面や抱えている課題、考えなどが聴けて個人的にはとても良い機会だったと感じている
その中で出てきたコメントの1つとして、担当プロダクトのカバー範囲が広くなってきており、途中からの参画などにより"すべて"の把握が難しいメンバーが居るということも分かった。
- これは自分も"そうなのかな"と感じていた部分でもあったので、あらためてここを確認できて認識の答え合わせが出来た
今までは「なるべくすべてカバーしよう」という雰囲気になっていたが、一方で「プロジェクト単位でメインで担当する範囲を区切る」という試みも行っている。
- 特に経験の浅いメンバーにはこの試みで"自信"と大まかでも"プロジェクトの進め方"について学んでもらえると良いなと感じている
また、あるメンバーとの会話の中で「アジャイルもっとちゃんとやっていきたい」という話が出ていた。
ここはチームとして「課題」を抱えていると同時に、「改善の余地がある」部分でもあるので、ここについて掘り下げてみたい
チームとアジャイルについて
チームでのアジャイルと課題について
- 先述の通り"スクラム"をベースとした開発手法を採用しており、"専任のスクラムマスター"が居らずローテーションで回している
- プロダクトオーナー（以下PO）が存在しており、POと開発チームで「リファインメント」によって"次スプリントでやること"が決められていく
- JIRAを利用しているがバックログの管理があまりちゃんとできておらず、自分や気づいた開発メンバーがメンテしていることが多い
- リファインメント前のタスク整理は、当番のスクラムマスターが担当している
- スプリント内にタスクが消化しきれず"持ち越し"が多い（=タスクの進捗が安定していない）
- さらに持ち越しが常態化しているメンバーも居る
なぜ問題が発生しているのか
- チーム全体（POも含めて）の「アジャイル」に対しての共通認識が持てていない可能性がある
- POの責務が広すぎて"バックログの管理やメンテ"といったことに対応できていない
- 特にジュニアメンバーに見られがちだが「自分のタスク」にフォーカスしすぎて、その結果何が起こるのか、そもそもなぜこの仕事をしているのかが見えていないのかなと感じることがある
- 結果としてタスクを持ち越してもいいや、となってしまっているように感じている
- これは個人的に感じたことだが、TeamGeekなど触れられているHRT(謙虚・尊敬・信頼)がチーム内で欠けてしまっているように見られた
- 自分としては"信頼"が薄らいでしまっているメンバーが居るように感じている
- もしかしたらメンバー間の"尊敬"も人によってまちまちだったりするのかもしれない
信頼について
"信頼"についてはこれもあくまで個人的な考えだが、いわゆる"社会人としての基本的なこと"がもっと大事にされてもよいのではと感じる場面がある。
結果そこが"信頼"の欠如につながってしまっている一因となってしまっているのではないかと考えている。
- 例えば、時間や約束を守る、敬語を正しく使う、他人に関心を持つ、貢献してくれた人にお礼を言う etc.
- この辺りを学ぶ機会に恵まれなかったという面もあるような気がしている
- 少なくとも"自分が感じている違和感"が、少なからずそのメンバーに対するマイナスイメージに繋がってしまっているという影響も多少あるような気がしており、この状況は良くない
我々は課題にどう立ち向かっていくのか
- スクラムに関するワークに関しては、あらためて「専任のスクラムマスター」を置くことも検討しつつ、少なくとも"シャドウワーク"はなくしていきたい
- 1on1のときにも話題に出たが、チーム感で「アジャイル」や「スクラム」の対する共通認識を持つ機会を作る
- 以前に実施したことがあったがその頃と今とではメンバーもだいぶ変わっており、時間も経過しているのでいまの状況やメンバーに合わせたカスタマイズが必要と思われる
- "社会人としての基本的なこと"について相互理解や、どこがお互いの着地点かを探る機会を持つ
- 自分の価値観が古い部分や正しくない部分なども大いにあるはずなので、お互いの相互理解を深めつつ、お互いにとって働きやすい関係性を構築したい
最後に
そんなことをふと考えた2022年末でした。
来年も色々と忙しく充実した一年になりそう予感なので、引き続き頑張っていきたいと思っています。
来年もよろしくお願いします！
p.s
こっそり会社主催のLTがありプレゼンをする機会がありました。もしよければご一読いただけますと嬉しいです。
API呼び出しをRestTemplateからWebClientに切り替えた話
どんな話？
spring-bootで作成されているマイクロサービス間のAPI通信のクライアントをRestTemplateからWebClientに切り替えてみましたという話。
なぜ切り替えたのか、どのように対応しているのかといった内容を書きます。
なぜ切り替えたのか？
ビジネスロジックの中でいくつか別サービスへの通信を行っているが、いくつか非同期で通信を行える箇所があった。
メッセージキューを利用したりと徐々に非同期化を図っていたが、今回のケースでは解決法としてWebClientを利用するのが適してそうなこともあり試してみた。
そもそもRestTemplateは2022年4月現在でメンテナンスモードとなっており公式でもWebClientの利用が推奨されていたため、近い将来切り替えたいという話も上がっていた。
切り替え前の状況
ビジネスロジック内の1処理としてhttp通信での別サービスの呼び出しを行っている。
この通信自体は即時性が求められるものではなく、非同期での連携で問題ないものではあったが同期的に通信処理を行っていた。
ただし連携開始してから、たびたび通信が不安定になるケースが発生しており、これに起因しての不具合が発生する事がわかった。
そのため非同期連携に切り替えようと思いどんな方法が良いかなと考えたところ、WebClientでノンブロッキングでの連携が適していると考え切り替えを実施した。
切り替えについて
実現したいこと
実装例
APIクライアントの定義例
@Component public class ServiceApi { private final WebClient webClient; public ServiceApi() { this.webClient = WebClient.builder() .baseUrl("URL") .build(); } public Mono<Void> create() { log.info("cacheUserPlan request={}", request); return this.webClient .post() .uri("URL") .retrieve() .bodyToMono(Void.class) .retryWhen( Retry.fixedDelay(2, Duration.ofSeconds(5)) // タイムアウトエラーが発生した場合には5秒間隔でリトライを行う(2回までAPI呼び出しを試みる) .filter( throwable -> throwable instanceof WebClientRequestException && (throwable.getCause() instanceof ConnectException || throwable.getCause() instanceof TimeoutException))); } }
API呼び出し側の実装例
今回はビジネスロジックからの該当のAPI呼び出し部分のみノンブロッキングにしたかったため呼び出し側でsubscriberを利用 （Monoのままプレゼンテーションでレスポンスはしない）
ServiceApi
.create()
.subscribe(
response -> {
// API呼び出しが成功した場合の処理
},
exception -> {
// API呼び出しでエラーが発生した場合の処理
});
参考にさせていただいた情報
リトライのテストについて
リトライ周りのテストをどう書くのが良いか分からず少しハマった。
調べてみた限りMockWebServerを利用してモックサーバにAPI接続して試す方法が良く紹介されていたのでそちらを利用してみることにした。
参考にさせていただいた情報
- How to test Spring WebClient retry when?(stack overflow)
- tokuhirom /java-handbook
- タイムアウトの場合のテストどうやってやるのかについてとても参考になった
今後について
切り替え後はしばらく様子を見てエラーハンドリングやリトライ設定などを今後必要に応じて見直していきたい。
リトライについてはjitterを利用したexponential backoffの利用なども考えていきたい。
RestTemplateを使ったAPI接続で並列処理数が上がらずにハマった話
どんな話？
RestTemplateを使ってのAPI呼び出しで複数スレッドでの並列呼び出しを行っているのに、なぜか呼び出された側で5並列まででしか処理をされていないという事象が発生して調査してみましたという話。
色々試してみたりで新たに学んだことがあったので備忘録兼ねてまとめた内容。
状況
※以下、API接続の呼び出し元のとなるサービスを「サービスA」、APIを提供しているサービスを「サービスB」と表記します
- サービスA、BともにJava&spring-bootで作成されているアプリケーション
- サービスAでは少なくとも10スレッドでリクエストしようとしているアプリケーションのログを確認
- サービスBでは5を超えるスレッド数で処理できているAPIも存在している様子
- サービスAではRestTemplateはデフォルトの設定で利用
- javaのHttpURLConnectionのhttpclientが使われる（と思っていた）
- 後述するがこれが大きく影響していた
- サービスAではサービスBと別のサービスへのAPI接続も行っており、そちらではapacheの httpcomponentsのhttpclientを利用していた
調査してみて分かったことと原因
- サービスAのRestTemplateでは「javaのHttpURLConnection」ではなく、「apacheのhttpcomponents」が使われるようになっていた
- debugでRestTemplateの設定内容などを確認してみて判明した
- ここは推測だがdependencyとして「apacheのhttpcomponents」が定義されている場合にRestTemplateをデフォルトで利用すると、「apacheのHttpComponents」のhttpclientが利用されるようになるらしい
- 試しにapacheのhttpcomponentsをdependencyから外してAPI接続してみたところ、サービスBの処理が10スレッドで走った
- RestTemplateでapacheのhttpcomponentsをデフォルト設定で利用する際に、connection poolの設定の中でmaxPerRoute)という値があり、これが5で設定されるようになっていた
- そのため、同一接続先への接続上限数が5になっており、サービスBで最大5並列まででしか処理されていなかった
- 上記のmaxPerRouteの設定を試しに10に変更してみたら、サービスBの処理が10スレッドで走った
まとめ
- 複数スレッド走らせる場合のテストはちゃんとやらないとダメ（特に今回はローカルでも再現可能な事象だったこともありこれに尽きる）
- IDEのデバッグ機能の活用大事
- RestTemplate理解したつもりになっていたけどよく分かっていなかった・・
- ドキュメント見たり、挙動見たり今回のことを通して学びました
その他参考になったページ
最近の仕事や環境で思っていること
昨年の2月中頃からリモートワーク中心になり1年強。
この1年で所属しているチームのメンバーが変わったり、様々なタスクやプロジェクトを進めたりと日々過ごしていく中で、当然ながら色々感じたことや思うところがあった。
近々チーム内での振り返りをしましょうという話があるが、まずは自分が感じていることなどを一度整理してみたいと思っていたこともあり、 思いついたことなどをつらつらメモがてら書いてみます。
ずっとアタマにはあったけどここで急にやってみようと思ったのは、アジャイルな開発とチームづくりの内容に触発されたのがきっかけの1つ。
チームとプロジェクトの進め方について
チームはバックエンドのAPI開発・運用を担当しているチーム。
メンバーは7人いて、ここ1年くらいで新しくチームに加入してくれたメンバーとそれ以前から在籍しているメンバーが半々くらい。
2週間スプリントでアジャイルで開発を進めているが、担当プロダクトはSoRでわりとウォーターフォールよりな開発が必要とされている部分が多いように感じている。
主要な登場人物としては、PO(Product Owner)と開発チームメンバーがおり、POは1人で複数プロダクトを兼任しているような体制。
開発は複数プロジェクトをチーム内で分担しながら進めているような状況。
チーム内でリーダーという役割・肩書の人はおらず、ファシリテート役をローテーションで回すなどしている。実質、リーダー的な役回りをしてくれている人がいたりもするが、その人にだけ負荷がかからないような仕組みづくりができるようチーム内で心がけている。
最近の取り組みや役割について
以前はチーム全体で複数プロジェクトで必要な対応をばーっと並べて、進めたいタスクを取っていきやっていくスタイルだったが、複数プロジェクトを並行して効率的に回していくための取り組みとして、プロジェクトごとに主担当とサブ担当みたいな割り振りをして、各自で担当プロジェクトの対応を中心にタスクを取っていき進めていく手法を採るようにしていきましょうという話になっている。
また所属チームは開発・運用はもちろん、プロジェクトの優先順位の調整や要件定義、プロジェクトリードのような立ち回りも担っていることが多い。
最近感じていることや課題
プロジェクトの進め方と役割分担
前述のようにプロジェクトに対しての関わり方を変えたことで、以前に比べてそれぞれのプロジェクトに専念できるような仕組みづくりとなってきた一方で、テックリードやマネージャーなど役割の人がいないため、プロダクト全体や他プロジェクトとの関係などに気を配る人、というのを役割として明示的に担っている人がいない状態となっている。
そのため中心的に動いてくれている人や、やれる人が全体の把握などを"暗黙的にしている"という状態になっている。
この暗黙的というのが難しく、出てきた課題をどうするか、ここからどうプロジェクトを進めていくかなどといった、プロジェクトを進める舵取りをしていく中での"関係者"を誰にするか、というところなどで頭を悩ませる場面もたびたびあり、結果としてチームがうまくスケール出来ていないのではと個人的に感じる場面がある。
かと言って、そこを完全に分業してしまうと、全体を把握できるメンバーが新たに出づらくなる、担当プロダクトの全体感が見えづらくなるという弊害もあるように感じているので、この辺りのバランスをどこに持っていくのか、というのが非常に悩ましい課題だと感じている。
プロジェクト内での役割と要求ハードルが高くなっているのではという危機感
次にプロジェクト内での役割についてだが、暗黙的かつ必要に応じて担当している"役割"みたいなものが大きく、あるプロジェクト内でのあるプロダクトの担当メンバーという立ち位置だけでなく、プロジェクトリード的な立ち位置も一緒にこなす必要が出てくる場面がたびたびある（というより増えてきている）。
これにより"主担当を持つこと"に対して心理的なハードルも高くなってしまっているように感じている。
今後について
プロジェクトの進め方と枠割分担については、今後も手探りで進めていきながら「ちょうど良いバランス」を模索して、調整しての繰り返しでやっていくのかなという感じ。
ここに書いていること、想っていることは個人的な主観たっぷりの考え方なので、他の人達がどう感じているのかなどはちゃんと聞いてみたい。
プロジェクト内での立ち位置などについても、個人的な考えなので、これが自分だけの意見か、他にも同様の課題感を持っている人がいるのかは一度ちゃんと確認しておく必要がありそう。
その上で"やっぱりこの課題があるしなんとかしなくては"となった場合は、「では、何がいま一番解決したい課題なのか」を探っていくところから地道に活動していくのかなと想像している。
年齢的にもそういった立ち回りをしていくことも求められていると思うので、よい"チームづくり"を実践していけるように取り組んでいきたい。
springアプリケーションのORマッパーの比較メモ
Kotlin + spring-bootのアプリケーションでのDBアクセスをどのライブラリを使って行うが良いかという課題があり、
簡単なコードを書いていくつか試してみたのでそれについてのメモ
Java ORマッパーの選定ポイントのスライドを参考にさせていただき、
の3つについて比較を、1:Nの2テーブルのみの簡単なCRUD APIを使って実施してみた
spring-data-jpa
spring-bootのORマッパー=JPAというイメージもあり、ちょっとしたwebアプリを書く際などに今まで利用していたのがこちら。
以前はspring-jdbcでゴリゴリSQLを書いていたことも合ったので「それに比べてDBアクセスが楽になった」という印象がある反面、アノテーションやマッピングの仕方、JPQLの使い方など使うにあたって学習が必要なものが多いことや、複雑なクエリを書こうとしてN+1問題などにぶち当たったりと使っていく上での課題も多く、自分が使いこなせるようになるにはハードルが高いなという感じがあった。
感想
- (利用経験での慣れが大きい気もするが)1:NやN:Nなどのマッピングがアノテーションで対応できる（ただし方法がいくつかあり、どういった場面でどれを使うのが良いのかの選択が難しい）
- ページングの実現も簡単
- (DDDを使っている場合)集約ルートから、関連エンティティをgetter経由で取得できるのでコード量が少なくできる
- N+1問題や3つ以上のテーブルのJOIN FETCHができない。意図していないクエリが生成されることもマチマチという課題がつきまとう
エンティティのコード例
1側
@Entity
data class Team(
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
val teamId: Long? = null,
val name: String,
val type: String,
@Version @NotNull val version: Int = 0
) : Serializable {
@OneToMany(mappedBy = "teamId", cascade = [CascadeType.ALL])
var members: MutableList<Member> = mutableListOf()
}
N側
@Entity
data class Member(
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
val memberId: Long? = null,
val firstName: String,
val lastName: String,
val teamId: Long,
@Version @NotNull val version: Int = 0
) : Serializable {
}
spring-data-jdbc
spring-data-jpaと似たような書き方で かつシンプルに使えそうという印象を持ったので試してみたのがこちら。
アノテーションやマッピングの仕方がほとんど同じことや、CrudRepositoryが使えるためfindByIdやfindAll,saveなどはそのまま使えるので新しく覚えることも少なくコード量もjpa同様に少なくて済みそうな感じだった。
感想
- spring-data-jpaと同じような感じで使えるため心理的ハードルが低い（個人的に）
- マッピングの仕方が違うことやLAZYフェッチが出来ないため、JPAに慣れている場合はそこの注意が必要になりそう
- LAZYフェッチがないなどJPAに比べてシンプルなためN+1問題などに悩まされることはなくせるor減らせそう
- (手元では試せていないが)ページングについては対応できていないような記述、記事を見かけたのでページングを手軽に使うことは出来無さそう
- 情報もまだ少なく、上記のページングの話も含めてまだ、これから機能や安定性が整ってくるという印象を受けた(シンプルなアプリであれば充分だとは思うが)
エンティティのコード例
1側
@Data
data class Team(
@Id
val teamId: Long? = null,
val name: String,
val type: String,
@Version @NotNull val version: Int = 0
) : Serializable {
@MappedCollection(idColumn="team_id", keyColumn="team_id")
var members: MutableList<Member> = mutableListOf()
}
N側
@Data
data class Member(
@Id
val memberId: Long? = null,
val firstName: String,
val lastName: String,
val teamId: Long,
@Version @NotNull val version: Int = 0
) : Serializable {
}
jooq
参考のスライド内では「クエリビルダー型」と分類されていたライブラリの1つ。
spring-data-jpaとかに比べると記述は増えるが、よりSQLに近い書き方ができる一方で、JDBCのように生のSQLを書く必要はないという感じなので、バランスがよくJPAで抱えていた課題を解決しつつ、エンティティの自動生成などを活用することでDBへの変更にも追随しやすい、というメリットがありそうと考えて試してみた。
DDD X CQRS - 更新系と三焦経で異なるORMを併用して上手く行った話などを見る限り、DDDにも活用できそうなことも試してみたいと思った理由の1つ。
感想
- spring-data-jpaに比べると記述量は多くなるが、クエリで条件や取得したい情報を明確に定義できるのは良いと思った
- エンティティの自動生成などプラグインを活用することで、開発や運用もだいぶラクにできそうという印象を持てた
- (自分の学習不足が大きいが)2つ以上のテーブルを結合する場合などの書き方がよく分からなかったし、それ専用のDTOクラスのようなものを用意する必要がありそうに感じた
- 1:NのテーブルでNの関連をどう定義するばよいのかが分からなかった
エンティティのコード例
1側(関連エンティティの表現はたぶん間違っている)
@Data
data class Team(
val teamId: Long? = null,
val name: String,
val type: String,
@NotNull val version: Int = 0
) : Serializable {
var members: MutableList<Member> = mutableListOf()
}
N側
@Data
data class Member(
val memberId: Long? = null,
val firstName: String,
val lastName: String,
val teamId: Long,
@NotNull val version: Int = 0
) : Serializable {
}
2021年1月の最近とやってみていること
2021年になって気づけば1月も2/3が過ぎた頃
去年からリモートワーク中心になって時間が増えた分インプットは少し頑張れた一方で、アウトプットが全然だった。
なので今年は月に1つくらいはブログなりのアウトプットを出せるようにしたい。
※2021/1/31追記あり。合わせてタイトルも少し変更
最近について
ここ最近、休日にうまく気分がのらないというか、気持ちが沈みがちであんまり何も出来ないみたいな日がたびたび出てくるようになってしまった。
持病でかかりつけの病院に行ったついでに、もし何かアドバイスもらえればくらいの気持ちで先生に相談してみたところ、
おそらくコロナ禍で生活が変わってきてしまい、「外に出ていたいタイプ」なのに外に出て行動出来ていないことがストレスになっているのでは、という話だった。
言われてみるとこの生活になって約1年が経過して、それまでと大きく変わってきたことなどで、少しずつたまってきていたものが「気分の落ち込み」という状態になって出てくるようになったという可能性が高いように思われる。
この1年での変化を振り返りつつ、ここ最近試してみていることなどを書き出して、自分の状況と気持ちについて整理してみる。
リモートワーク中心の生活になって
このコロナ禍で生活の仕方が大きく変わってきて、特に去年は外出どころか文字通り外に出ることもだいぶ少なくなってしまっていた。
去年は引っ越しがあったのでそれに伴う用事や、比較的落ち着いていたように感じていた夏〜秋あたりは休日にちょくちょく外出したりすることもあったが、
平日はほぼ毎日、自宅からの仕事で家から出ない日も多く、ジムなども春頃にやめてしまったので家で過ごす時間が格段に多くなった。
夏頃から週末にダンスのレッスンに行くことになり、かろうじて「誰かと会う」ということが出来ていたが、それ以外では友人・知人と直接会うことはほとんど無い1年だった。
特に12月くらいからはまた外出する機会も少なくなり、年末に入ってから「気分が沈む」ことが増えてきた。
平日の仕事をしているタイミングでなることは無く、週末や連休になるとそんな状態になるという感じなので、まずは気分転換が必要だろうと思い、自分なりにいろいろ試してみた。
やってみたこととこれからの過ごし方
なかなか人が集まるところへの外出はしづらかったりすることもあり、下記のような事をやってみたり、意識的に取り組むようにしてみている
- 散歩を習慣化する
- 落ち着いて何かを考えたりする時間が意識的に持てるようになった気がするが、30分程度の短時間であることもあってかあまり気分転換にはつなげられていないように感じている
- 休日に妻と別に過ごす時間を意識的に作る
- 12月頃はひとりで喫茶店に入って本を読んだりしたのは良い気分転換になったが、ここ最近は足を運びづらくなってしまった。落ち着いてきたらまた行きたい
- 近場に買い物に出かける
- あんまり物欲が無いのもあってか、これもうまく気分転換には繋げられてい無いような感じた
- youtubeを見ながら体を動かしてみる
- 先週末に妻に誘われてやってみたら意外に良かった
ちなみにやってみたのはコレ
まだこれだってものを模索中ではあるが、自分には心拍数を上げる運動が向いているのかなと思った。
あとは前々からたまに活用していたがアロマディフューザーでいい香りをかぎながら過ごすのもリラックス効果が高くわりと気に入っている。
以前のようにダンスのレッスンに行けるようになればそれも良い気分転換になると思うのだけど、 まだまだ外出しづらい状況が続くことが予想されるし、これを機に色々取り組んで新たな趣味や自分が夢中になれるものを探したい。
もし何かオススメの趣味やアクティビティ、気分転換などありましたらぜひ教えて下さい。
その後について
この記事を書いてから10日あまり（2回の土日）を挟んで自分なりにちょっと落ち着いてきた感じがあったので、備忘録と気持ちの整理を兼ねて追記
落ち着いてきた理由の考察
今後同じような状態になったときの備忘録として思いつくものをリストアップ
- 散歩の習慣化によるもの
外に出ること自体もあるけれども、podcastやyoutubeを聞きながら何かを考えたり感じたりを1人でする時間が良かったように思う
- "がんばりすぎない"ことを少し達成できた
この記事を書いていた辺りは主に仕事関連でやたらと悩んでいたが、そもそもそれほど悩まなくも良いことであったし、モノによっては自分の問題でないと切り離し、その事象から少し距離をおいてみれた結果、ストレスが緩和されたように思う。
あとは悩んでいた結果、「本を読んで解決策を得られないか」、「自分がもっとうまくできれば何とかなるのではないか」と自分に過度な期待とプレッシャーを掛けてしまっていて自分を追い込んでしまっていた部分もあったように思う。ゆっくり休日を過ごすのも"自己管理"と自分に言い聞かせて、無理せず休日を過ごすようにしたのも良かったと思う。
これについては自分ひとりでは客観的に見ることが難しく妻のアドバイスと協力が大きかったように思うので感謝しか無い。
- 両親や兄弟とオンライン上で話す機会があった
年末年始の状況では帰省するのが怖かったこともあり、両親や兄弟と会うこともなかったのだが、たまたまオンライン上でちょっと話す機会があって実家の家族や小さい子供とリモートとはいえ話せてこれもとても良かったのかなと思う
他にもあったのかもしれないけれども思いつくのはこんなところ
嫌われる勇気の読書メモ
この本を読み始めた経緯
妻が持っていてオススメされていた本。
コロナ禍でテレワークが続く中で、当然ながらオンラインでチームのメンバーや関係者と仕事でのやり取りをする場面が増えていきました。
対面ではないやり取りをしていく際にあれこれ考えてしまったり、必要以上に発言について気にしてしまい、うまくいかないなと感じることが度々あったので、
何か改善のヒントが得られないかなと思い読んでみることにしました。
読んでみての全体的な感想
まずは本のサイズ感、厚すぎず薄すぎず、文字が大きめで読みやすいと感じました。
内容自体も青年と哲人の対話形式で話が進んでいくため、青年と自分を重ね合わせて読んでいくことで、
自分の中での考え方とアドラー心理学を元にした考え方との違いを教えてもらいながらアドバイスを受けているような感覚になり、とても理解しやすい構成になっているように思いました。
自分の経験と照らし合わせても、痛いところ突かれたなと思う箇所も多々あり、少し苦しみながら読んだ場面もあったように思います。
以下で気になった箇所や印象に残った箇所などについて書いていきます。
各章の感想と気になったキーワードなど
第1章 トラウマを否定せよ
アドラー心理学とはフロイトやユングの心理学と違い目的論であるという説明から始まる章。
これまでの自分の考えとはまったく違う考え方、ここでガツンと頭を打たれたような感覚があった。
気になった箇所、キーワード
- 変われないのは「変わりたくない」という目的のために自分で原因を作っている
- 大切なのは「何が与えられているのか」ではなく「与えられたものをどう使うか」
- いまの自分を"受け入れる"こと。「もしも〜だったら」という可能性の中に生きている間は変われない
第2章 すべての悩みは対人関係
全体的に気になったキーワードが多かった章だったので特に気になった箇所のみを抜粋。
対人関係が苦手な方で今まで原因論に基づいた考えで「どうすれば良いのか」を考え悩む事も多かったが、目的論を元にした考え方で自分なりに"勇気"を出してもっと変えていかないといけないんだと認識させられた章。
この章を読み、"答え"はきっと「自分の中にあるもの」なのだろうなと感じた。
気になった箇所、キーワード
- 短所ばかりが目についてしまうのは"自分で自分を好きにならないでおこう"と決心してるから
- これは「〜でなかったらこうであるはず」といったような可能性の中に生きることが出来るから
- 今の自分を受け入れて、たとえ結果がどうであったとしても前に踏み出す勇気が必要
- これを「勇気づけ」と呼ぶ
人生のタスクについて
人生のタスクとは下記の3つ。
一人の個人が社会的な存在として生きていこうとする時に直面せざるをえない対人関係のこと
- 仕事のタスク
- 交友のタスク
- 愛のタスク
第3章 他者の課題を切り捨てる
昔、仕事で先輩に「何にでも首を突っ込みすぎ」だとか「それは君のタスクではない」といったような指摘を良く受けていたことを思い出しながら読んだ章。
その時に注意を受けたことで変えられた部分もあるけれども、根っこではまだうまく自分のものに出来ていないんだろうなと改めて痛感させられた。
気になった箇所、キーワード
- 他者の期待を満たす必要はない
- 「これは誰の課題なのか」という視点から自分の課題と他者の課題とを分離する
- 自分に出来るのは「自分の信じる最善の道を選ぶ」こと。自分がどうあるかを貫くことが「ほんとうの自由」につながる
第4章 世界の中心はどこにあるか
人の目を気にしすぎてしまうところがあるので「いかに自分が自己中心的であるのか」ということを認識させられたように感じた章。
他者への貢献をすること、そしてそれを自分で認めてあげることが「自分の幸せ」につながるという事なのかなと感じた。
ここの章の考え方は今の自分、特にオンラインでのやりとりが中心の今、とても大事にしていきたいと思った。
気になった箇所、キーワード
- 他者からどう見られているかばかりを気にする生き方は"私"にしか関心を持たない自己中心的な生き方
- 自らの主観によって「わたしは他者に貢献できている」と思えることで、自分には価値があると思える
第5章 いま、ここを真剣に生きる
もう一度読み返してみて"なるほど"と思えるような内容が散りばめられているなと感じた章。
1〜4の各章を自分の中に落としこんで実践できるようになってから読んでみると、また違う感じ方を出来るようになるのだろうなと感じさせられたまとめの章。
自分の弱いところ、出来ていないけど向き合っていかないといけないところが書かれているように感じた。
気になった箇所、キーワード
- 自分に自信がないからこそ自意識過剰になる
- 家事や育児、友人との交友や趣味などすべてに関心を寄せるべき
- 人生の調和を欠いてはいけない
- 人生とはダンスのようなもので「いま、ここ」が充実していればそれでよい。われわれは「いま、ここ」にしか生きられない
- 趣味でダンスをやっていることもあり、本の中で一番、印象に残ったキーワード
- ダンスでいうと見せるべき"いまここ"、"この瞬間"を精一杯、全力でやりきり生き抜いていくこと、の大切さというのがこの文から自分が感じたこと
- 人生の意味は、自分が自分自身に与えるもの。困難に直面した時「これから何が出来るのか」を考えるべき
