sigo.tosite

はじめに こんにちは。そろそろ17歳JKキャラがつらくなってきたtositeと申します。 でも概念としてはJKでいたい、そんな思春期の学生のような二律背反したモラトリアムを甘受したい今日この頃です。 最近はコロナも少し落ち着いてきて、徐々に新様式とは言え制限の少ない世界になってきつつあるのかなと思いますが、毎年恒例の振り返りをつらつらとしたためていこうと思います。 去年のKPT ブログを作り変える 本ブログに転生させることができました 結構自分なりには記事も書けていていい感じ 継続的にやっていきたい 丁寧な暮らしをする なんとか人間らしい暮らしはできています 最近料理が手抜きになりつつあるので頑張ろうと思いました でも「物を増やさないようにする」ミッションは達成できていない模様 トレーニングを始める ダイエットを始めたこともあり食生活には気をつけるようになりました 大濠公園を走ったり、登山したり 健康的な生活はできているんじゃないでしょうか スキルアップ 進捗だめです・・・ 周りでSEO検定受けてたりする方がいるから今年は何か資格を取りたいと思っています 今年のテーマ 今年は「やらないことをやる」をテーマに生きていきたいと思っています。 長い人生、やりたいことはたくさんあります。 慣習化していて惰性でやり続けていることもあるでしょう。 あるいは「やらなきゃいけない」というある種の強迫観念に追われることもあるかもしれません。 人間17年と180ヶ月も生きていると、色々な常識という名の偏見に囚われることもあるもので、どうやら僕はそういった「やらなければならないこと」に気づけば雁字搦めになっていたように思います。 例えばそれは私生活だったり、生き方だったり、思想だったり。 あるときふと、色んなものを持ちすぎていて気づけば身動きが取れなくなっていることに気づいたので、今年は意識的にやらないことや、自分の中の凝り固まった固定観念を見つけて削ぎ落としていく作業をしようと思っています。 特に「もういい歳なのだからバカをやってはいけない」という意識を捨てるようにしました。 その結果の一つが ママチャリで志賀島までポタリングする というものなのですが、なかなかどうして高揚感に包まれた楽しい時間だったので、積極的にバカをやっていこうと思っています。 もちろん、人様に迷惑をかけない範囲で

  僕はおいしいものを食べることが大好きだ。 そもそもおいしいものを食べることが嫌いな人類はいないのではないだろうか。 最近はGoogle Mapsのピン機能を使って、「行きたい」「行った」「殿堂入り」のようにラベルごとにお気に入りの店舗を管理するようにしている。 その中でも、以前 馴染みが好きだという話 でも書いたとおり、昔からお世話になっているお店を再訪することもままある。 特に福岡に戻ってきたこともあり、大学時代によく訪れていた店舗に足を運ぶことが増えた。 久々に行ったお気に入りのお店で、昔自分が好きだったメニューをオーダーして、心を踊らせながら提供されるのを今か今かと待つわけだ。 待っている間、当時のことを思い出し、何とも言えない感慨深い気持ちを噛み締める。それは大抵の場合、悪友との他愛ない会話だったり、甘酸っぱい気持ちだったり、ほろ苦い思い出だったりする。悪くない時間だ。 いよいよ料理が運ばれ、あの頃と変わらない盛り付けが視覚を刺激し、食欲をそそる匂いが鼻腔をくすぐった瞬間、僕のテンションは最高潮に達する。 約束された味を想像し、待ちきれず口に入れ、噛み締めた瞬間こう思うのだ。 「あれっ？」 確かに味はおいしい。懐かしい味がする。 だがこれはあのとき食べたあの味だろうか？ あのときはもっと感動的な味だったのではないだろうか？と。 一店舗だけなら味が変わったのだと感じるだろう。 全ての店舗でそう感じるのであれば僕の味覚が変わったのだと得心もしよう。 だが、そうではないのだ。 昔のままおいしいと感じるお店もあるし、おいしいけど何が何でも再訪したいと思うほどではないなと感じるお店もある。 なんでだろう、と考えた。 確かに10年も経てば自分の味覚も変わって、おいしいと感じるものが移ろいゆくだろう。 思い出という名のスパイスが、味付けを何段階も上のものに昇格させているかもしれない。 お店のキャストが変わったり、店主の味覚が変わったりして残念ながら求める味ではなくなっていることもあるかもしれない。 未だにこの疑問に対しての答えは出ていないが、最近味が期待していたものと違ってしょんぼりする（お店のかたに対して大変失礼な物言いであることは承知しているが）ことが何回かあったので言語化してみた。 やはり自分が好きなお店、馴染みのお店には定期的に通うのがいいのかなと思った。

 ニーバーの祈り なるものを知った。 神よ、変えることのできないものを静穏に受け入れる力を与えてください。 変えるべきものを変える勇気を、 そして、変えられないものと変えるべきものを区別する賢さを与えてください。 一日一日を生き、 この時をつねに喜びをもって受け入れ、 困難は平穏への道として受け入れさせてください。 これまでの私の考え方を捨て、 イエス・キリストがされたように、 この罪深い世界をそのままに受け入れさせてください。 あなたのご計画にこの身を委ねれば、あなたが全てを正しくされることを信じています。 そして、この人生が小さくとも幸福なものとなり、天国のあなたのもとで永遠の幸福を得ると知っています。 アーメン 基本的には僕は何でも自分の手の届く範囲にあるものが好きだ。特に車なんかは自分で操作している感がほしくてMTに乗っている。 が、世の中には自分の力でコントロールできるものとできないものの二種類があると思う。 大樹を動かそうと躍起になって力を込めても疲れるだけなので、これからは変えられないものと変えるべきものを区別することに心を砕き、変えられないものについては穏やかに受け入れて行きたいと思う。 この辺は他人を変えることはできないが、自分が変わることはできるのと同じような話だと思う。自分自身がどういう状況下でストレスを感じるのかを把握し、適切に対処できるようになりたいと思った。

 先日、 胃がんリスク検査を受けた話 でも書いたとおり、僕の体にはピロリ菌がいた。 しかもピロリ菌は母子感染する可能性が高いとのことで、子が感染している場合、親も感染していると思ったほうがいいとのこと。 （ 参考:  病気の話 杉並区医師会 【第16回】ピロリ菌について  ） これはまずいということで両親にピロリ菌の怖さを説くつもりだったが、両親の性格上、検査キットを自ら手配して取り寄せ、検査することはないだろうと思った。 そこで両親の分の検査キットを購入して郵送した（僕は会社が関東ITソフトウェア 健康保険組合に加入していたおかげで無料で受けることができた…本当にありがたい）。 それなりの費用になったが、家族の健康を守るためだと思えば是非もない。 結果的に両親ともにピロリ菌がいる可能性が高いとのことで、除菌治療を行うこととなった。 が、父のほうはそれ以外にも腫瘍のようなものが見つかり、そちらを治療しなければピロリ菌の除去ができないと診断されたそうだった。 私の祖父、父の父が胃がんで亡くなっているので、検査結果が出るまでは不安だったようだが、幸いにしてがんではなかったため、治療を進めつつピロリ菌の除去もできることになって一安心だった。 自分が受けた検査から思いがけず家族の健康を守ることができたので、意図せず親孝行ができて本当によかった。 人生にはいつか終わりが訪れることは普遍の理ではあるが、せめて両親にはその時がくるまで、健やかに余生を過ごしてもらいたいと思っている。

はじめに エンジニアリングをする中で「時間を取って後でドキュメントを書こう」と思う瞬間がある。 これは自分もたまにやってしまうことで、特にゾーンに入っている場合だったり、ガッと実装してしまったほうが早い場合だったりに起きているように思う。 しかしながら当然、ドキュメントを書かないことによる弊害というのも存在することは明白で、短期的に見るとスピードが出るのは間違いないのだが、長期的（と言っても状況によっては1ヶ月、2ヶ月と全然遠くない未来だったりする）に見て様々な問題が発生する。 ドキュメントがないことに対する弊害 例えば新機能の開発について考えてみる。 ドキュメントを整備しないまま実装した場合、実装した瞬間から「動いているものが正しい」状態になってしまう。仮にリリース前に仕様変更があった場合、ドキュメントがないと動いているものから仕様を読み解き、修正する必要があるかもしれない。 例として契約プランと契約年数で割引率が変わるロジックに手を加える場合、マトリクス表を一個書いておけば仕様把握は一瞬ででき、「パターンBをB'に変えたいんです」といった話がスムーズに行えるだろう。 だがマトリクス表がない場合はどうだろうか？どういう条件で分岐しているかコードリーディングした上でまとめ、どこをどうするか検討する必要が出てくるかもしれない。 この場合のコストは実装時にドキュメントを書くよりも工数が発生するように思うのは僕だけだろうか。 例えば新メンバーが加入した場合について考えてみる。 ドキュメントがないままオンボーディングするとなると毎回アーキテクチャやデータベース、システム構成について図を使って説明する必要があるだろう。 既存の仕様についても同様で、コードリーディングするかテストコードから挙動を追う必要があるかもしれない。 この辺りのキャッチアップは非常に時間がかかるもので、サービスが成長すればするほど、ドキュメントがない場合の工数は指数関数的に増えていくと思っている。 あるいはドメイン知識が浅いままに既存機能の修正を行った場合、考慮漏れが検知できず思わぬエンバグにつながるおそれもある（それを回避するためにコードレビューがあるが、コードレビューも万能ではないので）。 例えば既存機能の修正について考えてみる。 言わずもがなだが、ここがドキュメントがない弊害が一番大きく出る