日記6日目。
1日空いてしまったが、まぁ良しとしよう。
今日は義姉夫婦が遊びに来た。
甥っ子は可愛いものだ。
友人から色々と頼まれたが、案外みんなIT技術に疎いというか、基礎的な知識がなくて少しカルチャーショックだった。
案外、私は知識があるのかもしれない。
AIに仕事が奪われる日は遠そうだ。
以上
生活に関する内容を記載する
– 時間術
– 掃除
– ライフハック

日記6日目。
1日空いてしまったが、まぁ良しとしよう。
今日は義姉夫婦が遊びに来た。
甥っ子は可愛いものだ。
友人から色々と頼まれたが、案外みんなIT技術に疎いというか、基礎的な知識がなくて少しカルチャーショックだった。
案外、私は知識があるのかもしれない。
AIに仕事が奪われる日は遠そうだ。
以上

日記5日目。
今日は9時間寝たので調子が良かった。
きちんと睡眠は取らないと駄目だな。
日中は子供がいるのでなかなか自分の時間が作れない。
明日は予定を立てて妻とシフト制で対応しよう。
AWSのアカウント周りの話を読んでいて、複数アカウントでの運用を試してみたくなった。
幸い、AWSアカウントは2つ存在するので簡単なテストはできそうだ。
SREは、エンジニアの安眠を守るための有意義な仕事のようだ。
窓口対応は一旦、PMに依頼して現在開発中のプロジェクトを安定した保守案件にしたい。
以上

日記4日目。
日記を書いている横で子供が遊んでくれている。
こんな幸せはないな。
今日はママ友会だったらしく、終日やかましかった。
寝不足だと一日が無駄に過ぎてしまう。きちんと寝て、明日は有意義に過ごそう。
職場の管理者は土日でも仕事をしているようだ。
それはお金をもらって当然だけど、家庭は大丈夫かな?と心配になった。
以上

日記三日目。
仕事の愚痴は言いたくないので、反面教師にしよう。
必ず画面の向こう側には誰かがいて、それに対応していると思って生きることにする。
息子と夜みっちり遊んだ。子供は本当にかわいい。
気づけば父の死から、3ヶ月以上が経過していた。
心のどこかで息子と自分を幼い頃の自分と父に重ねている。
先日、毎晩読んでいる「おまえ うまそうだな」という本で、ふと泣きそうになった。
いつか、君を見送る日が来るんだろう。
その日まではずっと一緒だ。
仕事のことで少しモヤモヤしていたけど、どうでもいいな。
俺には、家族も友達もいるもの。
以上

日記を書くのが連続記録二日目。
このまま続けたい。
早起きは失敗したけど、しっかり仕事をしたので調子がいい。
VR会はインポスターをした。
rooms5.netというブログを作っているんだけど、少しずつ話しながらコンテンツを増やしていきたい。
筋トレと掃除に成功。毎日のルーティーンにしたい。
勉強時間は捻出できなかったので、明日はきちんと捻出したい。
以上

毎日、日記を書くのが良いとどこぞの本かAudibleで言っていた気がするので書いてみる。
転職活動が終わり、なんとか一段落している今日このごろ。
嬉しい気持ちと不安な気持ちで、毎日をふわふわと過ごしている。
つい先日のオファー面談で少しだけ大きなことを言って自分を追い込んでみた。
所謂、背水の陣というやつだ。
自分の性格的に、人の期待を裏切ることが異常なほど怖いので良い戦略だったと思っている。
とりあえず、DOPに合格してCFNを使用してちょっとしたものを作ってみるつもりだ。
ストレスが溜まったら、また煙草が吸いたくなりそうだ。
努力は裏切らない。きちんと戦略を立てて積み重ねていきます。
以上。
![情報や思考の[整理]に関して](https://sattva-improve.com/wp-content/uploads/2026/07/eye-catch.png)
私の実家は禅宗のお寺です。
私なりの解釈ではありますが、「シンプルに生きよ」というのが「禅」の基本的な教えだと考えています。
しかし、私の実家は「モノ」や「しがらみ」が多く、私が思う「禅」とはけはなれてしまっています。
私は「シンプル」なものが好きです。
そして、情報過多の社会の中で「シンプル」に生きる秘訣はこの投稿でまとめた「整理」にあると考えます。
この投稿を禅僧であった父へと送りたいと思います。
整理とは、一言で言うと「”要”と”不要”を仕分けること」です。
まずは、この「仕分ける」という行為の恩恵について考えていきます。
「パレートの法則」という法則があります。
別名[80:20の法則]とも呼ばれており、簡単に説明をすると
「わずか20%の要因が、全体の80%の結果を産み出す。」という法則です。
もしも、「仕分ける」ことを軽んじて作業を開始してしまった場合、
作業時間の80%を「ほとんど結果を産み出さない80%の要素」に対して使用することになります。時間や集中力を無駄にしてしまうでしょう。
まずは「仕分ける」ことで「重要な20%の要素」に対して、時間や労力を使うことができるのです。
この章では「整理」の具体的な手法について考えていきます。
先述した通り、「整理」とは、「”要”と”不要”を仕分けること」です。
基本的な考えとしては、「必要なものを抽出する」ではなく「不要なものを排除する」にフォーカスを当てていきます。
「創ること」よりも「捨てること」は苦しく、労力が必要です。
以下のような例です。
生きている限り、人間は「モノ」や「執着」を集め続け、何かを産み出し続けます。仏教用語で言う、「集諦」です。
「創ること」は容易く、「捨てること」は苦しいのは世の常かもしれないですね。
前段がかなり長くなってしまいましたが、具体的な「整理」の方法について紹介をしていきます。
整理については、「DDC」(あるいはD2C)という方法を提案します。
まず、「定義する(DEFINE)」です。
このステップでは「不要なもの」について定義をします。
「仕分ける」すなわち「不要なものを切り捨てると判断する」ための一つの方法として、 「不要」の軸をきちんと持つことが大切です。
この「不要」の軸がしっかりしていれば、案外すんなりと苦しむことなく捨てることができます。
先に挙げた通り、「捨てる」という判断はとてもエネルギーのいることです。
自分の決めた「不要」の軸に従って80%を捨て、重要な20%に対して、そのエネルギーを遣うべきです。
次のステップは「廃棄する(DISCARD)」です。
このステップでは、軸に従って「不要」と判断したものを廃棄していきます。
廃棄する際は、いきなり削除してしまうのではなく、
一時置き場を用意しておくと良いでしょう。
(ただし、この一時置き場は最後まで終わったら必ず削除しましょう。)
また、廃棄する順序としては、「思い入れのないもの」、「明らかに価値のないもの」から対応をしておくと良いです。
最後のステップは「分類する(CATEGORIZE)」です。
このステップでは、自分で決めた軸に従って【分類】を行い、整頓して入れ直しましょう。
前の手順の【廃棄】の最中に、大枠のカテゴリーは頭の中で整理できていると思うので、先に箱(置き場)を準備して、放り込むのが良いです。
「分類する」と一言に言っても、「軸」がなければ分類ができないと思います。
この章では、「分類」に関するアイディアを記載します。
1つ目は、「時間」による[分類]です。
業務や家事などのタスクの整理に有効なアイディアになります。
具体的には「日次」, 「週次」, 「月次」、「年次」の4つの軸で分類を行います。
タスクだけでなく、モノやPCのディレクトリ、ファイルにも活用することができるでしょう。
例: PCのファイルの整理:
2つ目のアイディアは「大項目、中項目、小項目による分類」です。
何から手を付けたりいいのか分からない時にこのアイディアを使用してください。
方法としては、「まずは大きく分類」を行い、
そこから「中項目」、「小項目」と細分化していきます。
私の本業はシステムエンジニアなのですが、テスト仕様書を作成するときにはこの整理法を使用します。
まずは、目に見える「画面」や「利用者」による分類(大項目による分類)を行った後に、「機能」による分類(中項目による分類)、最後に分岐などのパターンによる分類(小項目による分類)という風に整理を行っていきます。
例: テスト仕様書の作成:
最後に整理を行う上で役に立つ技術やツールを紹介します。
markdown記法とは、ITの世界ではデファクトスタンダードとなっている記法の一つです。
簡単に構造化した文章を書くことができる記法のため情報や頭の整理役に立ちます。
先述した大項目、中項目、小項目の手法で整理するときに使用するとよいです。
くわしい書き方は、Webで検索するとよいです。
スプレッドシート(ソフトウェア)とは、行と列に分かれたセルに対して数字や文字などのデータを入力するソフトウェアの総称です。
有名なところで言えばExcelです
ライセンスがなくてもGoogleスプレッドシートは無料で使用することができます。
Excelは、ITの業界では神Excelと揶揄されるほど汎用性の高いソフトウェアで、
仕様書や要件定義書や、プレゼン資料までExcelで作成してしまう現場もあるほどです。
行と列という2つのベクトルで直感的に操作ができるので、整理にも役立ちます。
AIを利用して、雑多にまとめた内容を箇条書きにしてAIにまとめを依頼することで、
簡単に情報を整理することができます。
懸念点としては、楽にまとめたものは記憶にも残らないし、自分の中で整理がしきれていないので役に立たないことです。
まさしく、「Easy come, Easy go」です。
最後に、情報の整理をするために有効なフレームワークについて解説します。
といっても、ほとんどの誰もが知っている当たり前の手法です。
これは持論ですが、目新しい考え方や、手法なんてものは存在しないし、
大抵のメソッドやフレームワークは過去の発明の焼き直しでしかないです。
5W1Hは実は、紀元前から使用されているフレームワークです。
それだけ汎用性と有用性が高いということです。
整理を行う前に背景や目的などを明確にする。
対象を明確にすることで、不要な考察などを排除することが目的である。
まずは、[なぜ?]について考えます。
この問いに答えることで、背景が明確になるし、そもそもこの問いに答えられないものは整理するに値しないです。
また、目的を明確にすることで、ゴールを意識することができます。
この際に、目的はシンプルで単一にしておくとよいです。
7つの習慣の[終わりから考える]の考え方に通じます。
次に、[誰のため?]を明確にします。
対象が、自分、なのか、玄人、なのか、3才児なのかで残すべき情報、モノは変わっていきます。
ステークホルダを明確にして、それぞれのポジションで俯瞰的に考えると良いでしょう。
一つの視点ではなく、それぞれの視点に立って考えるようにしましょう。
次は、[何を?]に関する質問です。
「何を対象にするのか?」を明確にすることで、目的達成への筋道がはっきりとしてくるはずです。
最後に「どのように?」に関する質問です。
具体的な方法を考えることで、作業完了までスムーズに整理を終えることができます。
方法を考える際に「どこに?」について考えます。
分類を終わらせた対象の置き場所を事前に準備しておくことで、
効率的に作業を進めることができるでしょう。
最後に「期限」に関して考えます。
「整理」という作業は終わりのない行為です。
作業に割ける作業時間が決まったら、タイマーなどをセットして開始すると良いでしょう。
この記事では整理に関する内容を記載しました。
自戒のために記載した部分も多いです。
今後の人生に活かせていけたらと思います。
誰かのお役に立てれば幸いです。

交換後、バッテリーレポートの結果がDESIGN CAPACITYをオーバーしていた笑
ちょっと得した気分だけど、爆発しないよね?笑



CloudLicenseの模試の結果が直近2回は80%前後取れてきているので、
恐らくSAP受かると思います。
まぁ、受かったからどうという話ではないが…。
以前、「資格取得の意義」について書いたけど、その話の補完。
私の周りの大人は大抵「運転免許」を所持していて、皆運転ができる。
この間のハワイ旅行で運転中に、
車内の友人達が「アメリカは黄色信号は止まれ。だってさ。日本と違うんだね。」と言っていたので、
私が「日本でもそうだよ」と話したら信じてくれなかった。
※ 調べたらやはり、「日本でも停止線で止まれ」だった。
信号の正しい意味すら知らなくても「運転をする資格」は、彼らにあるのだ。
似たような話で、私はAWS資格を集めているが、AWSの案件に携わったことがない。(個人では触るし、デプロイくらいはする。)
AWS 認定 ソリューションアーキテクト – プロフェッショナルという仰々しい名前の資格を取っても、正直、AWSの案件を回せる気はしていない。
だったらなぜ、時間をかけて資格を取るのか?
ここで一つ質問をしよう。
以下の二人のドライバーを選べるならどちらを選ぶだろうか?
よっぽど、天邪鬼じゃない限り後者を選ぶだろう。
では以下ならどうか?
この質問なら人によっては、前者を選ぶかもしれない。
では、以下ならどうか?
また、ほとんどの人が後者を選ぶだろう。
長く続けていれば、誰もが「ベテラン」にはなるが、
免許は取らない限り、取得できないのだ。

相互フォローしている方が以下の様に呟いていた。
もうCloud Licenseかクラテクか使うか……? いやうーーーーーーん流石に最後の手段だよなあ そっちに手を出したら自分のなかで資格取った意味が薄くなる でも受かりたいよ もう落ちたくない うう
— もけ (@m_k__77) April 5, 2026
私は今、AWS全冠を目指して学習を進めているが、
学習は基本的に(というか100%)、Cloud License頼りだ。
このまま、全冠を達成したところでAWSで何かを作れる気はしない
(AIに依頼をして作ることはできるだろうけど…)
ちなみに、このTweetに対して、「物申す!」だとか、「憤りを感じています!」だとか、そういう意図はないので安心してください。
実は新卒1年目に、基本情報に2回落ちた。
当時の勉強方法は「ひたすら参考書を書き写して理解する」という方法だった。
あの頃の自分はやる気に満ち溢れていて、
アホなりに「きちんとした知識が欲しい」という熱い想いがあった。
2回落ちたあと、3回目の受験時に「過去問道場」の存在を知り、
ひたすら過去問を解いていたらすんなり合格してしまった。
同じ様な勉強方法で応用情報は、ついに参考書も買わずに合格してしまった。
正直、IT資格を取ったからといって自分の技術力が上がるわけでもなかった。(当たり前だけど)
世間の言う「IT資格なんて意味ないよね」というのも一理あると思う。
私が思うに、技術研鑽と資格取得の勉強は全くの別物だし、
その意義も別だと思う。
持論だが、
「技術研鑽は自分のための勉強で、資格取得は他者のための勉強だ。」
本来であれば、技術研鑽を続けるのが技術者としてあるべき姿だと思う。
だがしかし、技術力というのはなかなか他者には伝わらない。
例えば、私は結構シェル芸が得意だ(と思っている)。
洒落たワンライナーを作ることができるし、ログ調査はかなり上手いと思う。
AIへのプロンプトも作りも得意だし、資料を作るもの結構上手い(と自分では思っている)
料理を作るのは上手いし、子供の相手は上手い。
運転も運動も得意だ。
しかし、「俺はこんなことができるぞ!」と言ったところで結局、誰にも信じてもらえない。
誰かに「俺はこんなことができるぞ!」とアピールするための手段が「資格」だと思う。
長々と書いたが、言いたいこととしては、
「自分は資格取得のための勉強と技術研鑽は別物だと思っているので、今は資格勉強のための勉強をしています。」ということだ。
テクニックや暗記で受かろうが、合格は合格だし、
いくら技術力や実績があろうが、不合格は不合格だ。
全く別物だと思っているから、
該当Tweetを呟いている「もけ」さんも、技術研鑽とは別に資格対策をしても良いとは思うが、
若い方の熱い志に水を差す気はないので、「おじさん応援しているね。」という薄ら気持ちの悪い言葉で締めたいと思います。
おじさん応援しているね。
以上。