sigo.tosite

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

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

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

はじめに 今年のGWはコロナも多少なりを潜めている状況だったので、外出する人が多いと予想していた。 そのため近場で、かつ雑踏を避けられるようなアクティビティを中心に何かやりたいと考えていた。 元々自然が好きで登山に力を入れたいと思っていたところだったため、気候も丁度いいこの季節に色々やっておこうと思ったのがきっかけ。 また、バックパックはキャンプ用に60Lと80Lを持っていたが、日帰りにはあまりにも大きかったためこれを機に28Lを新調した。 それでも大きいと感じる場面もあったため、道具選びは難しい。 新調したいと思っていたバックパック。 MOUNTAIN HARDWARE というコロンビアの子会社メーカーで、一目惚れして購入。 立花山・三日月山 会社の同僚である @たにわき あきら さんと行った。 酒の席で戯れに「山でポートレート撮影したいね」と話していたことが実現した結果だが、とても楽しかった。 撮影してもらった写真を載せておくので、気が向いたらご覧ください。 大体6km程度の山行。 3つの山を縦走した。 立花山はクスの木が多く叢生しており、その大きさに驚かされる。 立花山からの風景。 香椎・海の中道が一望できる。 風が心地よかった。 解散してからは一人で薬師寺温泉で疲れを癒やした後、福津のほうにあるお気に入りの居酒屋へ。 5月中には同じ市内ではあるが移転するとのことだったので、一言お祝いを言いたいと思い顔を出しに行った。 前と変わらず、むしろ前よりもおいしくなっており、移転した後も定期的に顔を出したいと思った。 やはり僕は馴染みが好きなんだなぁ。 桜鯛の刺身。 身が甘く口触りがよい。 生野菜のサラダ。 こんなにおいしいサラダを食べたのは初めてだった。 大将の腕が光る。 おそらく豚のカシラの漬け焼き。 大事に食べるつもりが、おいしすぎてすぐなくなってしまったのが心残り。 油山 会社の同僚とライトな登山をしようという話になって油山にも行ってきた。 事前に調べたところ、初心者向けの負荷が低いコースだと聞いていたが、入る道を一本間違えて引き返す羽目になってしまった。 こういうのも登山の楽しみの一つではあるが、無理のないタイミングで引き返す勇気も必要だと思った。 途中で行って戻った形跡があるところが例の地点。 こちらはトータル5km程度。 道を間違えたからこそ見つ

コミュニティから学ぶエンジニアリング from naoto teshima 先日、社の先輩より打診がありFGNのイベントで登壇することになった。 急なお誘いだったので少々びっくりしてしまったが、久々のオフライン登壇と聞いて楽しみな気持ちが強かった。 FGN とは福岡市のスタートアップ企業支援に特化した施設で、イベントスペースとしても開放されているのでエンジニアイベントではお世話になることが多い。 社のメンバーがキャリアチェンジしてFGNの事務局に転向したのもあり、一登壇者としてではあるがイベントを盛り上げることで応援したいと思った。 「 コミュニティから学ぶエンジニアリング 」ということで、初学者向けに自分がかつて辿ってきた道のりをベースに、コミュニティとの関わりを通じて自分のキャリアと向き合っていけるといいねという話をした。 登壇資料を作っていく中で当時と比較して成長したなあと実感し、当時の頑張りを思い出してあの頃の自分には負けてられないなと思うなどした。 と同時に昔同僚だった方々のイケてる登壇を聞いて、自分も頑張らねばと気持ちを新たにしたのだった。 その後は韓国料理の Lock Stock で打ち上げだった。 イベントや技術のことについて話しつつ雑多な話をする体験そのものが久々だったのもあり、最高の夜を過ごすことができた。 言うまでもなく料理は最高に美味しかった。 韓国料理をちゃんと食べたことがなかったので新しい扉を開くことができた。 そのような体験を通してやはり自分はオフラインで何かをやることが好きなのだなということを実感したので、今後も機会を見つけて積極的に参加していこうと思う。 と同時にコミュニティを運営する人間としてそういう場を提供していき、たくさんのコミュニティから受けてきた恩を返していきたいと思った。 追伸: Notionは最高です。