「アーキテクチャの基礎」を読んだ感想
「アーキテクチャの基礎」という本を読んでみました。 www.oreilly.co.jp
読んだきっかけ
最近は設計やアーキテクチャといった領域に興味をもっています。
この本を読むことでアーキテクチャに関する知識向上につながるのではないかと思い、読んでみました。
特に学びになった点
アーキテクトは技術の「深さ」よりも「幅」が価値を生む
知識のピラミッドには3つの階層があります。
アーキテクトにとって最大の資産は、上から2つ目のレイヤーを伸ばしていくこととのことでした。解決策を複数知っていれば、その中から最適なトレードオフを選択できるためです。 技術の幅という考え方をあまり考えてなかったので、印象に残りました。
すべてはトレードオフ
デプロイ環境やビジネスドライバー、企業文化、予算、期間、開発者のスキルセット、その他多くの要因に依存する。環境や状況、問題点はそれぞれに異なるものだ
「銀の弾丸」も「不変の正解」もない。こうした曖昧な状況での判断は、少なくともしばらくはAIではなく人間が行う領域だと感じ、今後意識していきたいです。
少なくとも最悪ではないアーキテクチャ
これも「すべてはトレードオフ」に関連する話です。 完璧な正解を見つけることが目的ではなく、現在のビジネス制約、予算、技術スタックといった複数の制約の中で、「少なくとも最悪ではないアーキテクチャ」を選ぶことが重要だと書かれていました。
この「少なくとも最悪ではない」という言い方が個人的には良かったです。最適解を探そうとしてものすごく時間をかけるより、まず最悪を避ける判断の方が現実的だと思いました。
おわりに
これからは様々な場面でトレードオフを意識しようと思います。これはソフトウェアに関することだけでなく、人生のあらゆる選択で意識できることだと思います。 私は完璧主義的な面があるので「絶対的な正解」が欲しくなります。でも、「絶対的な正解」は誰にもわからないし、本にも書いてあるように状況によります。 「トレードオフ」を意識して、「その時点で、最悪を避けつつ最善を目指す選択」を意識していこうと思います。
「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」を読んだ感想と学び
最近この本を読んでみたので学んだ点や感想を書きます。 www.shoeisha.co.jp
読んだきっかけ
最近は設計やアーキテクチャといった領域に興味をもっています。
設計力を向上したいため、ドメイン駆動設計を知ることで設計力の向上につながるのではないかと思い、読んでみました。
特に学びになった点/面白かった点
値オブジェクトとエンティティ
| 値オブジェクト | エンティティ |
|---|---|
| ドメインモデルを実装したドメインオブジェクト | ドメインモデルを実装したドメインオブジェクト |
| プリミティブ型ではなく、システム固有の値を表現するために定義されたオブジェクト。ライフサイクルは持たない | ライフサイクルを持つ可変なドメインオブジェクト |
| 性質1. 不変である | 性質1. 可変である |
| 性質2. 交換が可能である | 性質2. 同じ属性であっても区別される |
| 性質3. 等価性によって比較される | 性質3. 同一性により区別される |
値オブジェクト
3つの性質の詳細
- 不変である
- 値の書き換えをしたいときは、新しいインスタンスを作り直す
- 値オブジェクトクラスにchangeToxxxみたいな値を変更するメソッドは持つべきではない
- 交換が可能である
- 1にも関連するが、値の交換(新しいインスタンス生成)以外で値を変更できない
- 等価性によって比較される
- 値オブジェクトはシステム固有の値、あくまでも値。その属性を取り出して比較をするのではなく、値と同じように値オブジェクト同士が比較できるようにする方が自然な記述
- 値オブジェクト同士を比較する際には値オブジェクトの属性を取り出して比較するのではなく、Equalsメソッドを利用して比較を行う
値オブジェクトを使用するモチベーション
- 表現力を増す
- 例えば製品番号を扱いたい場合、stringというプリミティブ型だけだと、xxxxx-xxx-xのような特定の規則性がすぐにわからない。無口な文字列となってしまう。
- ModelNumberクラスの定義を確認してみれば、製品番号はプロダクトコード(productCode)と枝番(branch)、そしてロット番号(lot)から構成されていることがわかる
- 値オブジェクトはその定義により自分がどういったものであるかを主張する自己文書化を推し進める
- 誤った代入を防ぐ
- 🤔筆者の理解メモ：恐らく代入時にシステム固有の型を期待し、もし違うときはエラーを返せるという点だと思う。となる前提として静的な言語か、動的な言語で型ヒントを使う必要がありそう
エンティティ
3つの性質の詳細
- 可変である
- エンティティの属性を変化させたいときにはエンティティクラスのメソッドを通じて変更する
- すべての属性を必ず可変にする必要はない。エンティティはあくまでも、必要に応じて属性を可変にすることが許可されている。可変なオブジェクトは基本的には厄介な存在なので可能な限り不変にしておくことがよい
- 同じ属性であっても区別される
- エンティティ同士を区別するためには識別子(Identity)が利用される
- 同一性により区別される
- 属性を変更しても変更前と変更後のオブジェクトは同一として扱われる
- Equalsメソッドでは、idでだけで比較するイメージ
🤔筆者の理解メモ：ActiveRecordを継承したモデルのidと似てそう。エンティティがライフサイクルを持つものであること、そしてCRUDのようにDBの1レコードがライフサイクルを持っているからかもしれない。
ドメインオブジェクト定義するメリット
- コードのドキュメント性が高まる
- ドメインにおける変更をコードに伝えやすくする
ドメインサービス
- システムには値オブジェクトやエンティティに記述すると不自然になってしまうふるまいが存在し、それを解決するオブジェクトのこと
- ドメインサービスにはデータストアといったインフラストラクチャが絡まないドメインオブジェクトの操作に徹したのが本流
🤔筆者の理解メモ：アプリケーションサービスはクリーンアーキテクチャならばいちばん外側のレイヤーだろうか？
アプリケーションサービス
- アプリケーションサービスは、ユースケースを実現するオブジェクト
- アプリケーションサービスで結果を返却する必要がある場合について、「ドメインオブジェクトを返却する」「ドメインオブジェクトを返却しない」2パターン存在する。ドメインオブジェクトを公開するかしないかは大きな分岐点
🤔筆者の理解メモ：アプリケーションサービスはクリーンアーキテクチャのUse caseに似てそう
クリーンアーキテクチャへの関連
おわりに
値オブジェクト、エンティティなど、名前は知ってたけど詳しく知れて、使用するメリットをしれて良かったです。
特に値オブジェクトは誤った代入を防いだり、コードの表現力が増えることでバグの防止に役立ちそうだと思いました。
今回ドメイン駆動設計に関する技術書で初めて読んでみました。ドメイン駆動設計初心者に向けて分かりやすい本だと思いました。
また、ドメイン駆動設計の雰囲気をはつかめたものの、詳細を理解できていない部分もあるました。ただ、第一歩として知れて良かったです。
ドメイン駆動設計の入門書を探している人にはおすすめです。
引き続き設計やアーキテクチャのことを学んでいきます。
たくさんの後悔をまとって味のある人になるさ
『たくさんの後悔をまとって味のある人になるさ』 これは『NARUTO』のエンディングテーマ「ALIVE」の歌詞から取った言葉です。 この曲が好きで、今回の自分の考えに重なる部分があったので、今回のタイトルに選びました。
はじめに
年齢について、「ただ年を取りたくないな」と思うことがあります。でも、それにあらがうことはできないので、どうしたものか…と漠然と考えていました。
最近は揚げ物を多く食べれなくなってきていて年齢を感じています...
「若い方が良い」「年を取るのは嫌だ」という風潮が、世の中にはあると思います。
年齢を重ねることを、ポジティブにとらえてみたいなと思って自分なりに考えてみました。
年を重ねることに意味を持たせるには？
年齢が若ければ、知識や経験が少ないはずです。
年齢を重ねていれば、知識や経験が増えているのが1つのメリットだと思います。それを他の人に伝えていくことで、価値を届けられる場面が増えていくのではないかと感じました。
一方で、年齢を重ねていれば必ず経験と知識は多くなるのかというと疑問が残ります。年齢（時間）の経過と、知識や経験の量・質は必ずしも比例しないと思います。
年齢を重ねる上で知識や経験を少なくするような選択をとっているとしましょう。やるべきことややったほうがよいことをやらないことが該当します。（例：本を読んだ方がいいけど読まない、とか）
それらは今すぐは楽な選択かもしれません。でも、ただ年齢を重ねただけで、知識や経験が少ければ、人としての魅力が減ると思う。
今後、どう生きていきたいか
年齢を重ねる上で知識や経験を増やして、知識や経験を他の人に伝えて、価値を提供していきたいです。それによって、より良いチーム、組織、ひいては社会に貢献できればなお良いなと思う今日この頃です。
知識や経験を得ていくために、1日1%でもいいから学びを続け、経験がより増えそうな選択をしていこう、という気持ちです。もちろん、自分が進みたい、やりたい方向のなかで無理せずに。
もし失敗しても、後悔しても、その一つ一つを糧にして、味のある人になっていきたいです。
そして、そういう自分でいられることに、少しずつ誇りを持てたらいいなと思います。
「Clean Architecture」を読んだ感想
最近この本を読んでみたのでアウトプットとしてブログを書きます～ tatsu-zine.com
読んだきっかけ
最近は内部品質として設計やアーキテクチャの知見に興味あるため、読んでみました。
具体的には、プロダクトが成長するにつれて認知負荷が高まり、それによってバグや仕様漏れ、生産性の低下につながっているのではないか、とここ最近気付きました。こうした課題に対処する手段として、認知負荷を抑えるような設計やアーキテクチャの工夫が重要であり、その部分に関わっていきたい気持ちがどんどん強くなっているためです。
特に学びになった点/面白かった点
アーキテクチャの目的、アーキテクトの目的、ソフトウェア開発者の目的を知れた点
- アーキテクチャの目的
- それらを容易にするための戦略は、できるだけ長い期間、できるだけ多く選択肢を残すこと。
- アイゼンハワーマトリクスに当てはめると、アーキテクチャは"重要"、振る舞い"緊急"に該当する。
目的について、特にアーキテクチャは短期的な視点だけでなく、長期的な視点を持って全体の構築を考えなければならない、と理解しました。
クリーンアーキテクチャの図の理解
クリーンアーキテクチャと言えば、4つの同心円の図が有名ですよね。
- エンティテイはビジネスであり、それ以外の何者でもない。外部で何か変化が起きても、それが変化する可能性は低い。(p.191)
- ユースケースとは、自動化されたシステムを使用する方法を記述したものである
4つの円について、私の理解としてはクリーンアーキテクチャは動かないものに中心に据えてそこに依存すべき という考え方と理解しました。 その境界線を境界を考えていくことの重要性もこの本では解かれていたと思います（現時点で、境界に関する詳細をあまり理解できてませんが...）
フレームワークとの結婚するな
- フレームワークがあくまで詳細であること、そして、いかなる状況においても、フレームワーク作者から我々に何らかの約束をすることはなく、これは一方的な結婚であること。つまり、すべてのリスクと負担を背負うのは我々であり、フレームワークの作者は何ひとつ背負うことはない。
- 「フレームワークなんかと結婚するな！」そのためには、フレームワークとは一定の距離を保つこと。フレームワークは、アーキテクチャの円の外側にあるものとして扱い、円の内側に組み込んではいけない。
「フレームワークなんかと結婚するな！」という言葉が強くて面白かったこと、そして適切なフレームワークへの付き合い方を学ぶことができ、依存しすぎないようにしようと思いました。
まだまだ理解ができていない点
読み終わったのですが、以下の内容はあまりまだ理解できていません。 - SOLIDの原則の特にOLIの詳細の理解 - コンポーネントの原則の詳細の理解 - 境界線の付け方
おわりに
今回アーキテクチャに関する技術書をで初めて読んでみました。雰囲気はつかめたものの、詳細を理解できていない部分も多かったです。
この本を読んだだけではまだ完全に理解するものではなく、実務経験や他の技術書の知識が必要なのだろうと思っていて、将来またこの本に戻ってくると理解がより深まるのかなと思いました。
DDDにも絡みそうな感じがするので、その辺も今後学んでいきたいです。
楽しく過ごすためにどうするのか
はじめに
楽しくないと思ってるけども、「楽しくない」という認識を変えているよ、という内容になってます。
楽しく過ごしたいなと思ったきっかけ
最近楽しくないなあ、と思うことが増えてきたと思います。例えばこんな感じです。
- 未来に対しての不安からたくさん考えてしまいがち
- 「悪い出来事につながったらどうしよう」「これはうまくいかなそうな気がするなあ」「そのために何をすればいいのか」など...
- そして日中色々考えて、夜寝る前まで考えてしまい入眠が遅くなってきている
- 誰かの意見に左右されがち
- 「これはよくない」「それはやりたくない」といったことを言われると、1につながる
- やりたくないことを「やりたくない」と思いながら進めがち
- 仕事だと、例えば調整業務やその他自分が興味のない業務
- 自分の思い通りにうまくいかないときに「楽しくない」と思いがち
- 何かしらの技術の内容を理解できないときや自分の思い通りのプレーができないとき
そもそも、もともと物事に対して基本悲観的に考えて生きていて、楽しく生きてる人ではありません。何か新しいことを始めるときも、良いことよりも悪いことばかり想像してしまいます。
ただ、「今のまま楽しくないと思いながら生きるよりも、楽しんで生きていく方がお得ではないか」と思い始めました。人生は一度きりなのに、もったいないなと。
そして、そう考えるうちに、発生した出来事に対して「楽しくない」と思うのは自分の認識だと気づきました。発生した出来事は変えられないですが、その事実からの自分の認識は変えることができるはずです。
以前書いたブログに「自分の機嫌は自分でとるということ」をどうやって実現できるのか？というのが頭のなかで引っかかっていて、認識を変えることで実現できるのでは？と思いました。
そういった思いから、「どうすればいいのか？」を考えました。
自分の認識を変えるために始めたこと
- 世界のエリートがやっている 最高の休息法
- 幸せになる勇気
- あなたはあなたが使っている言葉でできている
- 夜と霧
- 神経科学者「シンプルだが、確実に努力が楽しくなる方法」アンドリュー・ヒューバーマン 和訳・解説
このような本や動画を参考に、以下の内容をし始めました。
心のざわつき・不安感を抑える
「世界のエリートがやっている 最高の休息法」を参考にマインドフルネスをやっています。タイミングとしては朝起きてすぐ、退勤後、寝る前。あとは自分の心が動揺しているときです。
過去や将来に対して意識を向けるのではなく、今この瞬間に集中できるようにしています。
努力自体を楽しいと思える
『神経科学者「シンプルだが、確実に努力が楽しくなる方法」アンドリュー・ヒューバーマン 和訳・解説』より
この努力自体が、自分にとって価値があることなんだ
それでも私は今、この努力に集中しているんだ
この反復練習が、確実に自分の技術を積み上げている
これはかなりキツイが、この辛さのおかげでこの後に達成感が感じられ、これから先もこの努力が楽しくなるんだ
私は自分でこれを選んで、自分の意思でこれをやっている 好きでやっているんだ
自分が自分の価値を認める
「幸せになる勇気」より
「わたし」の価値を、他者に決めてもらうこと。それは依存です。一方、「わたし」の価値を、自らが決定すること。これを「自立」と呼びます。
「あなたはあなたが使っている言葉でできている」より
「私にはできる！」
ありのままを受け入れる
「世界のエリートがやっている 最高の休息法」より
『（世の中はそういうものだ）』
『（どんなこともありのまま受け入れられますように）』
と心のなかで唱えて瞑想しています。
「あなたはあなたが使っている言葉でできている」より
私は何も期待せず全てを受け入れる
人生は予測がつかないという事実を受け入れ、実際の状況と向き合うほうがずっとバワフルだ。
やる気がなくなったり、何もしたくなくなったとき
「幸せになる勇気」より
人間は、過去の「原因」に突き動かされる存在ではなく、現在の「目的」に沿って生きている
つまり、われわれは過去の出来事によって決定される存在ではなく、その出来事に対して「どのような意味を与えるか」によって、自らの生を決定している。
「あなたはあなたが使っている言葉でできている」より
望みをかなえたいなら、とにかく粘り強く前へ進み、自らの権利を主張し、必死でがんばることだ。 がむしゃらになるコツは、目の前の問題に集中すること。全神経を注ぐことだ。
「夜と霧」より
人生から何をわれわれはまだ期待できるかが問題なのではなくて、むしろ人生が何をわれわれから期待しているかが問題なのである。
「幸せになる勇気」より
彼らの「目的」に注目し、彼らと共に「これからどうするか」を考えること
やってみて変化を感じたこと
これらを取り組みはじめてから、少しずつですが、自分の内面に変化を感じはじめています。以前と比較すると、メタ認知のように「今、自分は動揺しているな？」と気づく瞬間が増えました。そう気づいたときに、マインドフルネスを実践して一旦心を落ち着かせられます。このおかげで、以前よりも不安に囚われる時間が減り、気持ちが楽になったと感じるようになりました。
また、以前の私であれば、「どうせ失敗するだろう」とネガティブな考えに支配されがちでしたが、最近は自分で自分を鼓舞できるようになってきたと感じています。たとえネガティブな考えが浮かんできても、「できる」と上書きするように意識することで、ネガティブな言葉だけに引っ張られずに済むようになりました。自己暗示や、自分で自分を励ますことについて、本当にコスパが良いなあと感じています。そして、努力自体に意味を見出せるようになり、以前よりも物事に取り組むことが楽しみになってきました。
さらに、たとえ物事が辛く感じられる状況でも、「まあ、殺されるわけでもないし、死ぬわけでもない」と、冷静に捉えられるようになってきました。以前は些細なことでも深く考え込んでしまいがちでしたが、本当に深刻な状況はごくわずかだと気づき、あまり考えすぎなくても良いと思えるようになりました。
終わりに
今回の学びを通して、自分の考え方や捉え方次第で、少しづつでも変化を感じることができました。もちろん、これですべてが解決したわけではありませんし、これからも色々な壁にぶつかることもあるはずです。
それでも、今回得た学びをもとに、試行錯誤しながら少しずつでも良い方向を目指していきます！
JSQTB AL テスト自動化エンジニア 5章(特にメトリクス)の学び
最近資格取得に向けて頑張ってるので特に学びになったものを書きます。
学んだこと
5.1 TASメトリクスの選択
→後述するEMTEのためにも必要なメトリクスですね。
- テストケース全体に対する自動テストケースの比率（ただし、自動テストケースと手動テストケースの比較は容易ではない）
- カバレッジの増加（要件、機能、構造）
- TASによって早期に発見できた欠陥の数（欠陥の早期発見による平均的な利益がわかる場合、これを「計算」して予防されたコストの合計を導き出すことができる）
- TASによって発見できた欠陥のうち、手動テストでは見つからなかったと思われるものの数（信頼性の欠陥など）
→「TASによって早期に発見できた欠陥の数」は、コストの合計値を導き出せるので、上長だけでなく上層部にも伝えられそうなので、特に有用化も知れないと思いました。 とはいえ、その数をどうやって貯めていくのか、というところを考えないといけないかもしれません。今まで計測してきたことが無いからイメージできてないのかもしれないです。
- 成功結果および失敗結果の数
- 誤った失敗結果および誤った成功結果の数
→「誤った失敗結果および誤った成功結果の数」は、おそらく偽陰性偽陽性通づる話だと思っています。 これらはTAS、自動テストの信頼につながる部分なので特に重要だなと思いました。成功結果数を上げて誤った偽陽性偽陰性の数を増やしていく必要があります。 思い付きですが、これらの数値を比率にして「信頼率」みたいにしてもいいかもしれないですね。
- 自動テストコードの欠陥密度
- TASコンポーネントのスピードと効率性
→欠陥密度は、失敗結果の数の話と通づるかもしれません。 スピードと効率性については、いつもと同じ時間でテストが完了しないとSUT(テスト対象システム)の問題が明らかになる場合があるとのことです。 言われてみればこの視点は大事だなと思って、今まであまり意識してなかった次第です。
EMTE 同等の手動テスト工数（Equivalent Manual Test Effort）
実際に自動テストの内容を手動テストで行う場合の工数を計算したことはあるのですが、EMTEというこういう名前があるとは知りませんでした。
感想
「推測するな、計測せよ」という言葉もあるし、メトリクス大事ですよね。 定量的に伝えるのはすごく得意ではないけども、メトリクスを使って成果を伝えていく必要性は理解しているので、 自分が知らなかった「こんなメトリクスがあるんだな」という学びになりました。 他にもメトリクスはあったのですが、知ってた or イメージ通りだったの割愛してます。
実際にメトリクスを出す必要がある時はこのシラバスを参考にして考えてみます！
「運転者 未来を変える過去からの使者」を読んで学んだこと
この本を読んだので、学んだことをまとめます。
運転者 未来を変える過去からの使者 | ディスカヴァー・トゥエンティワン - Discover 21
読んだきっかけ
ある日、妻から「この本、すごく良かったからぜひ読んでみて」と勧められました。しかし、忙しさにかまけてしばらく読まないでいたところ、だんだんと妻が不機嫌になってきました。
ご機嫌取りもありますが、最近、自分の人生を豊かにするための学びを得たいと思っているから読んでみました。
余談ですが、この本では「いつも機嫌良く」と書かれているのに、読まないと「不機嫌」になるなんて、おすすめしてるのに実践できてないな...wと、私は読み終わって感じました。
このブログで書かないこと
あらすじや物語の詳細はこの記事では触れません。そのため詳細をもし知りたければ実際に読むか、他の記事を参考にしてください。
学んだこと
いつも上機嫌でいよう
運が劇的に変わるとき、そんな場、というのが人生にはあるんですよ。それを捕まえられるアンテナがすべての人にあると思ってください。そのアンテナの感度は、上機嫌のときに最大になるんです。逆に機嫌が悪いと、アンテナは働かない。最高の運気がやってきているのに、機嫌が悪いだけでアンテナがまったく働かないから、すべての運が逃げていっちゃうんです。
どんな仕事をしている人でも、不機嫌な人が成功したことなんてないですよ。逆に、上機嫌でさえいれば運が好転する場面が自分でわかるのに。
この文章を読んで、自分は「運」というよりも「機会」や「チャンス」という単語として認識しました。そちらの方が具体的な言葉でしっくりきたため、このブログでは「機会」や「チャンス」として記載します。
そして、よくよく考えてみると私はあまり機嫌よく笑顔でいることが少ないなと思いました。
確かに、機嫌が良い人と一緒にいる方が会話しやすく、相談もしやすい。そんな人は信頼を築きやすくなるので、自然とチャンスが増えるのだと思います。逆に、機嫌が悪い人は圧迫感を覚えますね。
これからは、できるだけ機嫌良く、笑顔で振る舞おうと思いました。もちろん、無理のない範囲で。
自分の機嫌は自分でとるということが、今後の課題になりそうです。本の中では「未知のものに対して何が楽しいのか、面白いのか、と興味を持つこと」というアドバイスもありましたが、そこはあまり私には刺さりませんでした。それでも、自分なりに機嫌良く過ごす方法を見つけることが大切だと感じました。
結果が出るまで時間がかかる
なかなか結果が出ないと言って苦しんでいるんです。人によっては自分は運が悪いとか思い始めます。頑張ってるのに報われないって言う人はみんな、種を蒔いてそれを育てているんですが、ちゃんとした収穫時期の前に『まだ育たない』と言って嘆いているようなもんです。もっと長い目で見たら、報われない努力なんてないんですよ。あまりにも短い期間の努力で結果が出ることを期待しすぎているだけです。今日頑張って明日実になるなんてどんなに早く育つ種でも無理なことですよ。
この内容を読んで幾つか胸が痛くなりました…というのも、昔、チュートリアルや入門書を読んだだけで終わってしまったことが多々ありました。学んでもすぐに実務で活かす機会がなくて、非常に悔しい思いをしました。
具体的には、デザインパターンの入門書、RailsやAWS、GitHub Actionsのチュートリアルの実践、pytestやインセプションデッキや基本情報技術者試験や応用情報技術者試験などの学習です。特に当時はレガシーな環境にいたため、モダンなWebアプリケーションの開発に携わりたかったので、辛かったです。
しかし、今振り返ってみると、当時の学びが後々に役立っていることに気づきました。例えば、
- CircleCIの修正を依頼された時、CircleCIよくわからないけどもGitHub Actionsの知識があったおかげで、CircleCIを素早く理解できたこと
- コードを読めるので、単体テストのレビューができること
- 各レイヤーの責務を分けることや、抽象化の重要性の理解。これをE2Eテストの自動化にもいかせていること
- テストツール選定をリードして、pytestの説明をすることができて、それが採択されたこと
- インセプションデッキは現職で使っているので、スムーズに意見が出せること。そして、自分が進めているポッドキャストでも役立っていること
そういったことも改めて認識することで、すぐに結果が出ないときも多いかもしれないけども、将来のために学び続けることが大切だと改めて認識しました。そして、それをふりかえることで、当時辛かったことが少し報われた気がします。1％でもいいから日々学ぶ姿勢を持って、日々学んでいこうと思います。
ちなみに、唐突な宣伝ですが今やっているポッドキャストについてはこちらからどうぞ！！！
無駄な経験はない
自分の人生にとって何がプラスで何がマイナスかなんて、それが起こっているときには誰にもわかりませんよ。どんなことが起こっても、起こったことを自分 の人生において必要な経験に変えていくというのが〈生きる〉ってことです。だから、どんな自分に都合のいいことをイメージしていれば、それが起こるなんて、プラス思考じゃないですよ。本当のプラス思考というのは、自分の人生でどんなことが起こっても、それが自分の人生においてどうしても必要だから起こった大切な経験だと思えるってことでしょう
この部分は新しい学びというよりも、自分の考え方が間違っていないと確認できた箇所です。「無駄な経験はない。だからどんな経験でも、それをどう活かすかがより重要」という考え方を持っています。
自分の記憶が正しければ、『絶対可憐チルドレン』に「無駄な経験はない」と描かれてたように思います。それに影響されて、この考え方を持つようになりました。
当時自分は「どうせ経験するならネガティブなことは活かしたほうが得」、「ポジティブな経験だとしても、その経験を殺してしまう時もある」とも思いました。
自分が大切にしている価値観を忘れがちですが、この本を読んで思い出すことができて良かったです。
おわりに
今回の読書を通じて、日々の生活や仕事における大切な考え方を再認識できました。
今後もエンジニアリングだけじゃなくって、人生を豊かにするためにも日々学んでいこうと思います〜！
