「スタッフエンジニアの道」を読んでの所感

僕は今の会社でテックリードという肩書きで仕事をしている。ただ、テックリードと言ってもその内実は会社によって、人によっても千差万別である。そんな混沌としたITエンジニア界隈において、今後のキャリアの指標とすべく読んでみたのが「スタッフエンジニアの道」だった。

スタッフエンジニアの道 ―優れた技術専門職になるためのガイド

想定される読者層

本書を手に取るべき読者層として個人的に想定されるのは、中堅やシニアといわれるようなエンジニアで、かつマネージャーではなく技術者としてキャリアを積んでいきたいと考えている人達だ。

スタッフエンジニアと一緒に仕事をする人達が、彼らを理解するために読むのもアリと言えばアリなのだが、本書は僕のような本職のエンジニアが読んでも結構抽象度の高い話が出てくるなぁという印象が強いので、そういう人達はある程度覚悟して読んだ方が良いと思う。

良かった所

実は、僕は本書を読む前に「スタッフエンジニア」というその名の通りの書籍を手に取ったことがあったのだが、その時はスタッフエンジニアがどういうものなのか今ひとつピンと来なかった。だが、本書については自分が今までに取り組んだことのある事柄からその延長まで具体的に書かれていることも多く、今の会社で課題となっていることに対してのアドバイスになるような話もあったりした。

中でも第II部「実行」は、プロジェクトにおけるスタッフエンジニアの立ち振る舞いについて事細かに書かれており、学びが多かった。あとは人生という観点からエンジニアとして何を大事にするかについて書かれた部分もあったりして、必ずしもマッチョでイケイケなエンジニアになるだけが正解というわけではないことも教えてくれて少し安心した。

苦しかった所

一方で、読んでいて苦しくなるというか、心がヒリつく場面も多々あったのも事実だ。僕はエンジニアにありがちな典型的コミュ障なのだけれども、本書において多くを占めるのがコミュニケーションの話だ。周囲のエンジニアの規範となったり、良い影響力を広げていくという過程においては、コミュニケーションは欠かせないのである。

カンファレンスで登壇するとか、社外へ出て行くのも内向的なエンジニアにはきっつい話だと思う。とはいえスタッフプラスともなれば内外である程度名が知られているというのもそりゃ必要だわなと思ったり、思わなかったり。

難しかった所

読んでいてなかなかピンと来ないこともあった。特に第I部の「大局的な思考」は、ここが抽象的な話が多い箇所なので読むのを止めてしまうのはありそうだけれども、それは勿体ないなと後から思った所だ。逆に言えば、ここを乗り越えれば後は我々のようなエンジニアからすると理解しやすい話が多くなってくるので、踏ん張り所である。

5章「大規模プロジェクトをリードする」については、僕が小さめベンチャーばかりを点々としているために若干の縁遠さを感じた部分だ。ただ、こちらは普段自分が関わっているプロジェクトの延長線上の話だし、いずれ自分も大規模プロジェクトに携わる日が来るかもしれないと思いつつ、気合いで読んだ。

結局、スタッフエンジニアとは何なのか

さて、本書を読み終えても、具体的にこれがスタッフエンジニアだという風に説明するのは正直難しい。

強いて言うならば、スタッフエンジニアというのは、組織を俯瞰しながら抽象度の高い課題解決に責任を持って立ち向かえる人だという一面はあるだろうか。一方で、一緒に本を読み進めていた社のマネージャーからは、スタッフエンジニアとマネージャーの違いは部下に責任を持つかどうかでしかないという意見を得られた。確かに、その分スタッフエンジニアは技術面で責任を持つということになるのかもしれない。

そう考えると、スタッフエンジニアにコミュニケーションが求められるのも当然といえば当然というわけで、苦手だけどやっていくしかないかという気持ちにさせられる。

おわりに

本書は正直抽象度の高い話が多くて読みやすいとは言い難いけれども、そもそもエンジニアという仕事も上位になればなる程抽象度の高い課題解決が求められるわけで、この内容を自分の糧にしてキャリアアップしていくのがスタッフエンジニアの道なのだと思うことにしたい。いやー、道のりは険しそうだ。

デプロイツールをHakoからecspressoに移行した話

長年デプロイツールとしてHakoが使われてきたプロダクトにおいて、この度ecspressoに移行したのでその所感を記しておきたい。

ecspressoとは

ecspressoは、ECS専用のデプロイツールである。読み方は「エスプレッソ」。Go言語で書かれたOSSだ。

github.com

ecspressoの良い所

• 日本語ドキュメントが充実している（作者直々にハンドブックを出されている）
• Go言語製なのでインストールが爆速
• ecspress init コマンドで現状のECSの状態を一発取得できる
• Hakoと同等の機能を概ね備えている
• メンテナンスが活発に行われている

ecspressoの導入について

ここで中途半端なチュートリアルを書いて読んでもらうくらいなら、ハンドブックの方が100万倍懇切丁寧なので、ecspressoの使い方についてはハンドブックを参照してほしい。Zennの決済で500円なのでとてもお手軽だ。

爆速エピソード

先日ecspressoのエラーでぬるぽが出た際に、Issueを上げたことがあった。この時は作者のfujiwaraさんが数分でリアクションしてくれて、1時間も経たない内に回答をいただき、しかもすぐに修正PRまで上げてくださる爆速ぶりだった。

OSSを選ぶ際は、メンテナンスが活発かどうかというのは結構重要な指標となるので、ecspressoはその点素晴らしいなと思えたエピソードである。

おわりに

ecspressoはHakoを使い慣れた人であればサクッと理解して導入できる上に、メリットも多いので、Hakoの代替としてもこれから導入するにしてもオススメしたいと思う。

RubyのDockerイメージ上でSeleniumを動かす

Ruby界隈ではSeleniumを動かすネタが少ないので、最近作った環境について書いておこうと思う。

ChromiumとChromiumDriverを追加済みのDockerfileを作る

巷ではChromeとChromeDriverのバイナリーをcurl等でダウンロードしてインストールする方法が一般的だが、バージョンを合わせる必要があったり上手く動かなかったりとハマりがちだったりする。その点、DebianベースのLinuxにChromiumとChromiumDriverの組み合わせであればaptから簡単にインストールすることができる。RubyのDockerイメージも多くがDebianベースなので、以下の例のように簡潔な書き方ができる。

#
# Builder
#
FROM ruby:3.3.5-slim as builder

ENV TZ=Asia/Tokyo

WORKDIR /opt/project

COPY Gemfile Gemfile.lock ./

RUN apt-get update && \
    apt-get install -y \
        g++ \
        gcc \
        make

RUN bundle install

#
# Main
#
FROM ruby:3.3.5-slim

ENV TZ=Asia/Tokyo
ENV RAILS_ENV=production
ENV RAILS_LOG_TO_STDOUT=1

WORKDIR /opt/project

COPY --from=builder /usr/local/bundle /usr/local/bundle
COPY . .

RUN apt-get update && \
    apt-get install -y \
        chromium \
        chromium-driver

CMD ["sleep", "infinity"]

CapybaraからSeleniumを操作する

あとはGemfileに capybara と selenium-webdriver を追加しておき、以下のようなCapybaraの設定ファイルを用意すれば良い感じにSeleniumを動かすことができる。

# frozen_string_literal: true

require 'capybara'
require 'selenium-webdriver'

Capybara.register_driver :chromium do |app|
  version = Capybara::Selenium::Driver.load_selenium
  capabilities_key = Capybara::Selenium::Driver::CAPS_VERSION.satisfied_by?(version) ? :capabilities : :options
  capabilities = ::Selenium::WebDriver::Chrome::Options.new.tap do |options|
    options.add_argument('--headless')
    options.add_argument('--no-sandbox')
    options.add_argument('--window-size=1280x960')
    options.add_argument('--disable-infobars')
    options.add_argument('--disable-extensions')
    options.add_argument('--single-process')
    options.add_argument('--disable-dev-shm-usage')
    options.add_argument('--homedir=/tmp')
  end
  Capybara::Selenium::Driver.new(app,
                                 browser: :chrome,
                                 service: Selenium::WebDriver::Service.chrome,
                                 capabilities_key => capabilities,
                                 timeout: 120)
end

Rails 7.1の切り戻しとALBのヘルスチェックで板挟みになった話

最近複数のプロダクトでRails 7.1への移行を行っているが、その中でRails 7.0へ切り戻しが必要になって苦労した事例があったので共有しておこうと思う。

キャッシュフォーマットの互換性について

Rails 7.1 から、キャッシュに値を保存するときのシリアライズフォーマットに新しいバージョンが追加された。Rails 7.1 は古いバージョンのキャッシュを読み取ることが可能だが、Rails 7.1 で保存されたキャッシュをRails 7.0が読み取ることはできない。

詳しくはRailsガイドの6.1から7.0へのアップグレードガイドを参照されたい（7.0から7.1へのガイドには記述が無いが、内容は概ね同様である）。

railsguides.jp

実際、Rails 7.0に切り戻した所、以下のようなエラーが発生した。

TypeError incompatible marshal file format (can't be read) format version 4.8 required; 17.1 given

ALBのヘルスチェックについて

さて、今回切り戻しで問題が発生したのは、ECSのステージング環境である。ここでRails 7.0への切り戻しをデプロイしようとした所、コンテナが立ち上がっては落とされるありがちなエラーが発生した。確認した所、ALBのヘルスチェックに失敗しているということだった。

このサービスでは、ヘルスチェックのパスを / に設定していたため、Railsのルートを参照して上記エラーで落ちていたということだ。Rails 7.1にすると問題があって、切り戻しすると今度はキャッシュの非互換で落ちるという板挟みになってしまった。

今回はこの問題を解消するために、ヘルスチェックのパスを /healthcheck.html という静的ファイルに変更して乗り切ることにした。そもそも、このサービスではRailsのルートに対してDatadogで死活監視をしているので、ALB側のヘルスチェックでも行う必要は無いと判断したからだ。ただ、もし同様の事例で死活監視を他で行っていない場合は、静的ファイルだとRails側のエラーに気付けない場合があるので注意が必要だ。

おわりに

今までステージング以上の環境でRailsを切り戻すということが無かったのでこうした非互換問題とは無縁だったが、実際遭遇してみたらヘルスチェックとも絡んでちょっと面倒な事態になってしまった。Rails 7系へのアップデートの際の参考になれば幸いである。

Rails 7.1に更新したらRSpecがフリーズする件

先の記事とは別のプロダクトでRails 7.0から7.1へアップデートしていたら、今度はRSpecがランダムでフリーズするようになったので、これまた備忘録がてら書き綴っておく。

何が起きたのか

RSpecのトランザクションを使用するテストがランダムでフリーズするようになった。

対応内容

rails_helper.rb の以下の行を書き換える。

- config.use_transactional_fixtures = true
+ config.use_transactional_fixtures = false

代わりにDatabaseCleanerを導入して、spec_helper.rb に追記する。

RSpec.configure do |config|
  config.before(:suite) do
    DatabaseCleaner.strategy = :transaction
  end

  config.before(:each) do
    DatabaseCleaner.start
  end

  config.after(:each) do
    DatabaseCleaner.clean
  end
end

これでひとまずテストが全て実行されるようになった。 体感的にも、DatabaseCleanerを使うか否かで特段の差は無かったので一旦良しとしている。

おわりに

Issueを立てようかどうしようかと思いつつネット徘徊していたら、同様の内容が既に上がっていたので、こちらも共有しておく。

github.com

Sentryで謎のエラーが起きたら外してみると良いかも

みんな大好きSentryだが、そのSentry自体がエラーを吐いて落ちるという珍しい？事態に遭遇したので備忘録がてら書き綴っておく。

何が起きたのか

Rails 7.0から7.1へのアップデート中に、ステージング環境でのみSentryが以下のようなエラーを吐いて落ちるようになった。

/bundle/ruby/3.3.0/gems/sentry-ruby-5.17.3/lib/sentry/utils/
argument_checking_helper.rb:8:in `any?': stack level too deep 
(SystemStackError)

検索しても類似の事例が全く出てこず、どうしたものかと思いながら試しにSentryのGemを取っ払ってみたところ、エラーが変わってあっさり答えが出てきた。

Uglifier::Error: (Uglifier::Error)

このUglifierのエラーに関しては、Uglifierの代わりにTerserを使おうということなので、粛々と置き換えに取り掛かった。

対応内容

Gemfile のUglifierをTerserに置き換える。

- gem 'uglifier'
+ gem 'terser'

staging.rb および production.rb も同様に。

- config.assets.js_compressor = :uglifier
+ config.assets.js_compressor = :terser

おわりに

何でこれでSentryが落ちるんだ…という疑問は残るものの、取り敢えずSentryを外してみればエラーの正体が現出するという知見が得られた。よくよく考えてみれば当然のことではあるが、ぱっと見だと混乱させられるので参考になれば幸いだ。

ところで今回のUglifierのエラーは、ES2020等の新しい構文を使うと出てくるものらしいが、何故Railsのアップデート中に発生したのかはこれもまた疑問が残る。まだまだRuby & Rails力が足りていないと思う今日この頃。

新電力から従量電灯に切り替えようとしてトラブった件

今の住居の電気はHTBエナジーと契約していたのだけれども、後述の経緯により東京電力の従量電灯Bに戻すことにした。ところが、その手続きの際に地雷を踏み抜いたので、注意喚起の意味も込めてここに記しておく。

TL;DR

• 新電力からの切替について、一般的には現契約の事業者への連絡は不要であると案内されている
• ただし、新電力から地域電力会社の規制プラン（従量電灯など）に切り替える場合、現契約の事業者へ解約日を連絡しなければならない
• 解約日の連絡を行わないと、地域電力会社から「現契約の事業者から切替の連絡が無かったから手続きできんかったわ」という通知が届く
• 結果、現契約の事業者との契約期間が1ヶ月延びる

切替の経緯

HTBエナジーは電気をよく使う住宅向けに安くなる料金プランを用意していて（現在は新規受付停止）、IHクッキングヒーターを使いまくる我が家には有り難い料金設定になっていた。ところが、昨年の4月に光通信系への株式譲渡が発表されたり、前後してマイページの不具合で請求情報が数ヶ月に亘って参照できなくなったりと、立て続けに不安になる出来事が起きていた。

そこへ来て、昨秋より市場連動型料金の部分導入が行われ、今年からは更にそれが値上げされるということで、流石にこのままでは茹でガエルだろうということで東京電力の従量電灯Bに戻すことにした。正直、改定が一度きりであればまだ我慢のしようがあったが、短期間に立て続けとなると信用が揺らぐというもので、短絡的に「高くなったから移るわ」というものではないことを断っておきたい。

手続きの流れ

さて、従量電灯への切り替えの場合、申し込むには地域電力会社への電話連絡が必須となる。今時ネットで申し込めないのかとは思いつつも、電力会社としては自由化以降の新プランを押し出しているので、そこは仕方ない。

東京電力に電話すると、住所や供給地点特定番号などを確認された上で、切り替え日時を案内される。その際、「現在契約している事業者へ切り替え日を連絡するように」と言われる。なので素直に従ってHTBエナジーの連絡先を探すために同社サイトを見に行った。すると、「解約のお手続き」の項目に、

お引越しが伴わない他の電力会社へ切替による解約の場合 電力会社の切替となります為、弊社へのご連絡は必要ありません。新しくご契約する電力会社へお申込みください。

と記載されている。なるほど、今回は引越ではなくて電力会社の切替だから、連絡は必要ないのか。であればこのまま待っていれば来月には切り替わるのだな、と理解して切替日を待つことにした。

変わらないステータスと東京電力からのお手紙

そして迎えた切替予定日。特に両社から連絡はないので、スムーズに切り替わったのだろうか。しかしHTBエナジーのマイページを見てみると、当日の電力使用量が依然として計測されている。ここで若干の不安を覚えたものの、以前のマイページ不具合の際も長期間放置されていた前例があるので、そういうものかもしれないと思うことにした。

そして翌日、東京電力より1通の封書が届く。なるほど、切替完了の通知かなと思って開いてみると。

弊社電気料金プランへの切替え手続きを行いましたが、切替期限日までに現小売り電気事業者さまからのご契約切替の申込みがなかったため、切替え手続きが完了せず、現在も現小売電気事業者さまとのご契約が継続しております。

＼(^o^)／

え！？HTBエナジーのサイトには連絡の必要はないって明記されてたやん！なんで？？？

HTBエナジーからの説明

当然、その旨をHTBエナジーに問い合わせるも、先方からの説明は以下のようなものだった。

「お切替え手続き方法」の掲載につきましては、 弊社では電気事業法のガイドライン沿った内容として、ホームページへ掲載させていただいております。 通常のお切替えは「検針日単位」であり、電力会社、もしくはお客様の任意指定は行えません。

そのうえで、論点である「東京電力様の特定プラン」へのお切替え方法については、 特定プランへのお切替えご指定日（スイッチング日）は東京電力様の独自判断であり、 本プランへお申込みされた時のみ、東京電力様よりご指定される日程であるイレギュラー範囲でございます。

その「ご指定日」に関わる後続対応を（aikawame）さまに対して「明瞭性のあるご案内」を行うことが 東京電力様の責任であると弊社では判断しております。

イレギュラーである受付、東京電力様の責任の範囲より、 弊社ホームページでは、電気事業法のガイドライン沿った内容を掲載しております。

要約すると、「東京電力側のイレギュラーな仕組なんやから、東京電力側で『何が何でも連絡しろ』って念押しせんのが悪いわ」ということだろうか。

再び東京電力へ

というわけで、いずれにせよ東京電力に再度の切替申込をしなければならないので、また電話すると。

ENEOSでんきさんとかは、サイト上や自動音声で「従量電灯への切り替え時には連絡してね」と注意喚起してもらっているようなんですけどね…（意訳）

と言われてしまい。どっちもどっちな気もしますけどね…とは言えなかった。

所感

一般消費者視点では、今回の僕の対応については特に問題があったとは思えない。強いて言うなら、東京電力側が「連絡してくれ」と言っていたのだから、念のため連絡しておくというのが最善の対応ではあったのだろうが、それは結果論だと思う。公式サイトのFAQがあるのならばそれに従うのは当然のことだろう。

詰まる所、東京電力側も、この契約はイレギュラーなので新電力が「連絡不要」としていても必ず連絡するように案内するのがベストだろうし、新電力側もENEOSでんきのように従量電灯への切替に関する注記をしておくのがベストだったと言えるのではないか。

まぁそもそも、規制料金プランを申し込んでるお前が話をややこしくしとるんじゃと言われてしまうかもしれないが、それなら規制料金プランは新規受付停止にするなり何なりやりようはあるだろうし。

おわりに

新年早々面倒な事案に巻き込まれてしまったが、ひとまず来月には今度こそHTBエナジーから東京電力へ戻れるはず。

HTBエナジーに関しては、今回の件については必ずしも落ち度があったとは言えないかもしれないが、せめて「うちのサイトでも注意喚起しておくわ」くらいの一言でもあれば良かったと思う。東京電力にしても、前例があるのならば「新電力の案内にかかわらず必ず連絡しろ」くらい強く言ってほしかった。顧客目線って何だろうみたいなことを考えさせられる一件だった。

今年買って良かったもの2022

年の瀬ということで、今年もまた買って良かったものを書いてみる。

キーボード（Logitech Ergo K860）

Logitech Ergo K860 Wireless Ergonomic Keyboard with Wrist Rest-US配列 [並行輸入品]

10年ほど愛用したREALFORCEに別れを告げて、こちらを購入。切っ掛けは肩凝りが年々酷くなっていること。少しでも肩に負担が掛からないような構成を検討したが、REALFORCE2台では幅が広すぎるし、HHKBだと変荷重ユーザーからするとキーが重い。

どうしたものかと考えていた時に、そういえばREALFORCEの前はLogitechのハの字キーボードをこれまた10年近く使っていたなと思い起こし、試しに買ってみたのがなかなか良かった。スイッチはメンブレンからパンタグラフ式に変わっているが、ハの字は相変わらず肩が開いて良い感じだ。静電容量方式で分割キーボードが出てくるまでは（出てくるのか？）一旦これで凌ごうと思う。

ドッキングステーション（サンワサプライ USB-DKM1）

サンワサプライ ドッキングステーション Type-C接続(USB3.2 Gen2対応) 電圧・電流チェッカー搭載 USB-DKM1

昨年Anker PowerExpand Eliteを購入して当初は気に入っていたものの、ACアダプターのコイル鳴きが結構うるさかったのでこちらに替えてみた。ドッキングステーション本体への給電もUSBなので、好みのアダプターを選べるのが良い。

Amazonだと価格も手頃だし、インターフェイスも有線LAN、HDMIにUSB-Aポートが3つと過不足ない。大型のドッキングステーションにありがちなオーディオ系インターフェイスは個人的には無駄でしかないので、むしろ丁度良い。欲を言えばSDカードスロットが欲しかったが、頻用するものでもないので専用のリーダーを使うことにしている。

USB充電器（Anker 711 Charger）

Anker 711 Charger (Nano II 30W) (USB PD 充電器 USB-C)【独自技術Anker GaN II採用/USB PD 対応/PSE技術基準適合】MacBook USB PD 対応 Windows PC iPad iPhone Galaxy Android スマートフォン ノートPC 各種 その他機器対応 (ホワイト)

仕事のお供であるVAIO Zが軽くて薄いので、充電器もどうせなら小さいものをと思い購入。iPhoneの充電器とほぼ同じ大きさで30W対応なのはやばい。VAIO Z純正の充電器は65Wだけれども、30Wあれば通常用途では事足りている。

唯一の欠点というか、利点の裏返しではあるのだけれども、小さすぎて挿していることを忘れてしまいがち。実際、旅先で一度紛失してしまい、同じ製品を買い直す羽目になってしまった。それでも小さくて軽いのは正義。

腹筋ローラー

【メーカー純正品】La-VIE(ラヴィ) スムース腹筋 3B-4010

プランクでは腹筋への負荷が物足りなくなってきたので購入。最初は膝コロ10回でも死ぬほどキツかったが、今では立ちコロで少しずつ床が近付いているので筋肉はすごい（小並感）。

番外編：みかん

僕は幼少の頃から口内炎がしょっちゅうできる体質で、1年の1/4くらいはどこかしらに口内炎がある状態が続いていた。もちろん通院してビタミン剤を処方されたりとか、改善策は色々打ってきたものの、期待した効果は得られなかった。それがアサヒの濃ーいみかんを舐めるようになってから改善されたのが一昨年のこと。

ただ、それでも季節によって出来やすさがどうにも違うことに気付いて、もしやと思い年中みかんを食べるようにしてみたら、見事に的中した。どうやら僕の口内炎には生のみかんが一番効くらしい。というわけで、今年は真夏でもハウスみかんを買って食べるようにしてみたが、口内炎とは無縁の生活が送れてQOLが爆上がりしている。

おわりに

今年は去年紹介したものが完全に否定されるという残念な結果が1件発生してしまった。とはいえ、逆に言えばその他は満足しているということなので勝率はまあまあということか。大物の無い地味な1年だった気はするけれども、こういうのは周期的にやって来るものなので、来年はぼちぼち家電やイケてるデジタルガジェットを紹介できるのではないかと期待している。

40歳になった

毎年恒例、今日が誕生日ということではないけれども。

とうとう不惑を迎えてしまった。いや、不惑は数え年だからもう既に迎えているのか。いずれにせよ大台突破である。 35歳から始めたこのブログももうすぐ5年。最近は若干放置気味になっているけれども、その分ここで吐き出していこうかと思う。

この1年で変わったこと

聴覚過敏に悩まされるようになった。今の自宅は幹線道路沿いではなくて、普段はトラックの音も聞こえてこない程度の静かな場所なのだけれども、休日や夜間帯に走ってくる大量の違法改造バイクの爆音が耳に付くようになってしまったのである。引っ越してきた当初はコロナ禍の入りだったせいか気にならなかったのが、年々増えてきて許容限界を突破したらしい。某県警は動かないのかとか、法規制は云々とか、言いたいことは色々あるけれども、ひとまずは現実的な措置として治療を続けている。

朝型生活が崩れた。聴覚過敏治療の副作用もあるが、とある事情で精神的に参った時期があったことも重なって、その治療の副作用も加わっての大崩壊となってしまった。今は23時に寝ても翌朝11時前まで起きられないみたいなこともあって、なかなか難儀している。もう暫く踏ん張れば副作用の地獄からは抜け出せるはずなので、今は辛抱するしかない。

鎌倉散策の頻度が減ってきた。回ってみると意外に鎌倉というのはこぢんまりとした街で、観光客を受け入れている寺社は巡り尽くして2周・3周目になってきたし、今年は大河効果もあって人混みを避けてという側面もある。それでも早朝の空いている時間帯に巡るという選択肢はあったものの、これも朝起きられなくなったために封じられてしまった。

変わらないこと

去年転職してから勤続1年を迎えた。久しぶりに職場でのドタバタを味わうことになったが、上長や今いるメンバーが優秀な人ばかりなので色々と助かっている。この面子が変わらない限りは頑張っていこうと思っているけれども、はてさて今後どうなるか。

仕事は引き続き週1出社であとはリモートワークとなっている。週1というのは丁度良い頻度で、行きは大船始発の湘南新宿ラインで座っていき、帰りは東海道線のグリーン車か特急湘南、はたまた新宿からロマンスカーと、週末の夜に優等座席で帰宅するのはちょっと良い気分になれるので、その選択肢の多さには感謝している。

体重は引き続き60kg台の前半を維持している。これを維持したまま体を絞っていかねばと思ってはいたのだけれども、思いとは裏腹に腹の肉はぷよぷよとしている。かといって体重を減らそうとすると筋肉も減ってしまうし、一体どうすれば良いのか。年を取ってきたら小太りになった方が良いとはよく聞くけれども、メタボにならない程度で腹の肉を諦めるしかないのか。いや、甘味と天一を控えれば済むのかとも思いつつ、生きている実感を失うのは辛いのでどうしたものかと日頃から逡巡している。

おわりに

前厄の1年、厄除祈願には参ったけれども、こうして振り返ると結構凸凹な1年になったものだと思う。ただ、何もしていなければもっと厄が降り掛かってきたかもしれないので、この程度で済んだと思うことにしている。

来年は本厄なので更に気合いを入れて厄除け祈願できればと思っている。来年こそ、余暇にはのんびりコーディングしながら年越しのことを考えていられることを祈りたい。

舌下免疫療法を始めて3年経った結果

花粉症根治を目指して舌下免疫療法を始めたのは2019年の6月のこと。 ひとまず当初区切りとしていた丸3年を迎えたので、状況を書き残しておこうと思う。

症状はほぼ出なくなった

治療を始める前のハイシーズンといえば、薬を飲んでいても1日でティッシュを1箱消費することもあったような重症度合いだった。頭もシーズン中ずっとボーッとしていた。

それが治療を始めて1年目のハイシーズン、多少のムズムズ感はあれ苦にならない程度にまで改善した。2年目は引っ越した地域によるものなのか、口腔アレルギー反応や朝の鼻水地獄に苦しめられつつも、肝心な花粉症の症状はやはり軽め。そして3年目、今年のハイシーズンは全くの無症状。

外出時に常時マスクをしているとはいえ、それでも今までは何らか症状が出ていたので、明らかに改善していると言える。まして今年は花粉の飛散量も多めだったので、その中で耐えきったのは心強い。

丸5年までやっていくことに

しかしながら、医師との相談の上で治療は継続することにした。というのも、僕が治療を始めた当時は3年を推奨と言われていたのが、最近では3~5年を推奨となっていて、長く続けるほど効果も長く続くとのことだからだ。

僕の場合はリモート受診で費用についてもそれほど負担に感じていないし、毎日の服薬も他のサプリの服用と一緒なので完全に日々のルーチンに組み込まれている。シダキュアは服用しやすいのも良い。

あと何より治療する以前の症状が重すぎたので、少しでも良くなる方策があるのであれば迷わず選択していきたいと思い、続ける次第となった。ただ、人によっては元の症状の具合や負担感を加味しつつ3年で区切りを付けるのもアリではないかと思う。

おわりに

いずれにせよ、3年間治療を続けたおかげで地獄の鼻水生活を脱出できたわけで、誰にでも必ず効果が出るとは限らないとはいえ、やってみる価値はあると思う。

舌下免疫療法を始めてみた的な記事はあちこちで見掛けたけれども、肝心な結果について見当たらなかったので、n=1ではあるものの状況を記してみた。この記事がスギ花粉症同志各位の参考になれば幸いだ。

過去の花粉症関連記事一覧

aikawame.hateblo.jp

aikawame.hateblo.jp

aikawame.hateblo.jp

aikawame.hateblo.jp