COVID-19の3回目のワクチン接種記録


はじめに & おことわり

このBlogではあまり時事ネタ的なことは書かないんですけれども、執筆時点(2022/2/19)では、COVID-19に対する3回目のワクチン接種がまだ始まったばかりであり、特に交互接種について不安を持たれている方がたくさんいらっしゃると思いますので、私の場合こうだったということで、3回目のワクチン接種以降、体調がどう推移していったのかを、記録を兼ねて書いていこうと思います。

そして、この記事はあくまでも私のCOVID-19の3回目のワクチン接種記録を、接種を検討されている皆さんの参考になればと事実ベースで書いているもので、交互接種や、そもそもCOVID-19のワクチン接種を強く強制するものではないことを、ここに明記します。(いやもちろん接種した方がいいに越したことはないですが)

前提

  • 基礎疾患あり。平熱は36.5度
  • 1回目のCOVID-19ワクチン接種: 2021/7/25 ファイザー社製(コミナティ筋注)
  • 2回目のCOVID-19ワクチン接種: 2021/8/16 ファイザー社製(コミナティ筋注)

2/14 ワクチン接種予約までの経緯と流れ

仕事に関するスケジュールの関係上で、3月までには3回目のワクチン接種を完了させておきたかったのですが、居住地の市役所からの接種券の発送時期が、2回目のワクチン接種から6か月経過して以降の発送になることをWebサイトであらかじめ確認はしていました。

もちろん接種券の発送まで待つという選択肢もあったのですが、それだとちょっと3月以降のスケジュールにどうしても影響が出てしまい、関係する方に迷惑をかけてしまうこともあって、とりあえず市役所の担当部署に電話をしてみました。

電話をしたところ、氏名と生年月日と2回目のワクチン接種日の確認を受けた上で、

あなたの場合は接種券を前倒して発行することが可能なので、まず先にワクチン接種の予約をしてください。

ということを言われたわけです。いやいや、接種券番号がないのに接種予約なんてできないでしょ、って思っていたところ、3回目のワクチン接種の接種券番号は、1回目 & 2回目のワクチン接種の接種券番号と同じであることが判明。それ先に言ってくれないとわからないよ〜。

そのタイミングでワクチン接種場所として候補に上がったのは、千葉県が運営する「千葉県新型コロナワクチン追加接種センター」と、防衛省・自衛隊が運営する「自衛隊大規模接種東京会場」の2つでした。ちなみに、使用するワクチンはどちらもモデルナ社製です。

元々ファイザー社製のワクチンに関しては供給量が少なかったことと、個人的には交互接種をすることによるデメリットよりもメリットの方を重視していたこともあって、上記のどちらかの接種場所で受けることを決めたのですが、千葉県の方は残念ながら3月まで完全に埋まっており、賭けるのは防衛省・自衛隊の方。早速Webサイトに入ってみたところ、希望日の予約状況が「予約一旦満了」というステータスになっていました。

まぁそれでも予約方法だけでも確認してみようということで、1回目 & 2回目の接種券情報をもとに、自治体コードと接種券番号を入力してみたところ、希望日に何故か3枠の空きが! 多分何かしらの事情でキャンセルされた方がちょうど出たんでしょうね。ありがたく予約を入れさせていただき、その情報を市役所に連携したところ、その日のうちに接種券を発行していただけることに。午後に少し空いた時間があったので、サクッと市役所まで行ってきて、接種券を発行していただきました。ここまでが2/14の出来事になります。

2/16 ワクチン接種当日の流れ

2/16のワクチン接種当日。自宅からだと接種会場のある竹橋まではそれなりに移動時間がかかるため、この日は大手町のコワーキングスペースでギリギリまで勤務することにしました。ちょっと仕事が佳境に入っており、できるだけ効率的に時間を使いたかったためです。

必要な打ち合わせ等をきっちり終わらせて、大手町駅から東京メトロ東西線で竹橋駅まで移動。4番出口の階段を登り切ると、報道でよく出てくる「自衛隊東京大規模接種会場」の看板が。

予約時間までには必ず到着しているようにしてくださいという注意事項が書かれていたので、少し早めで20分前に到着していたのですが、その時点で既に自分の予約時間分も受付開始になっていました。そのまま会場へ入ります。

報道でよく見られるプレハブとテントで設営された仮設棟は、主に手荷物検査、当日の体温測定、問診票記載事項の確認、事前問診に用いられており、内部は想像以上に広くて整然としています。迷いそうになってもあちらこちらに係員の方がいらっしゃって丁寧に誘導してくださるので、指示に従っていれば流れ作業のような形でスルスルと事前の手続きが進んでいきます。事前問診で、基礎疾患の内容や1回目 & 2回目の副反応の状況について、僕の場合は結構細かく確認されましたが、結果的にはOKが出ました。ここまでで約10分。

ここから先は、元々税務署か何かで使われていたと思われる本館の方に誘導されます。エレベーターでの移動になるのですが、きちんと余裕を持った人数が利用できるようにコントロールされていて、エレベーターの中にも案内係の方がいらっしゃいます。もちろん入口と出口の動線は完全に分離しています。このエレベーターで、実際に接種を受ける7階まで上がります。

7階に上がると、まず最初に医師(医官)の方の最終問診が入ります。ここで問診票の内容の再確認と、接種を希望する腕の確認(私は左利きなので右腕を希望しました)を受け、接種後の待機時間が記載されます。そしてそのままの流れで別の部屋に案内されて、看護師の方に実際にワクチンを接種していただきました。接種してくださったのは、東京大学病院から応援でいらしていた方でした。

2回目の接種の時は多少の痛みを感じたのですが、今回は、何かが腕に触れたかな? という程度で何の痛みもなし。本当に接種を受けたのか? と一瞬思ってしまったくらいです。筋肉注射と聞くと結構痛いイメージがあるものなのですが、そう言ったイメージとは全くかけ離れたあっさりとしたものでした。

ここでさらに別室に移動して、15分間待機。ここでも多くの医師(医官)のかたが見守りをしており、もしも何かあった場合でもすぐに対応していただける体制が整っています。幸いにも何の体調の変化もなく、15分が経過したため、また先ほどのエレベーターで1階に降りて、仮設棟の方に移動し、問診票の回収と接種券への証明証の発行をいただいて無事に接種は終了。ここまででかかった時間は僅か35分。本当にスムーズでした。そのまま徒歩で竹橋駅まで戻り、混雑を避けて着席するために敢えて各駅停車で帰途につきました。

ちなみに、大規模接種会場の内部は、静止画・動画撮影は禁止です。なかなか経験できないだけに、撮影したくなってしまう気持ちもあるのですが、そこはルールを守りましょう。

2/17 副反応の記録

朝の時点で副反応の兆候はあまり感じられず、確かに右上腕部の接種部分を中心とした痛みはあったものの、腕が上がらないようなことはなく、体温も平熱にほぼほぼ近い状態だったので、通常通り在宅勤務を開始したのですが、何だか熱っぽいなと感じてきた12時過ぎの段階で37.5度まで上昇。このタイミングで解熱剤を投入することも考えたのですが、熱っぽさだけだったのでそのまま在宅勤務を続行してしまいました。これがちょっと良くなかったかもしれません。

そのうちだんだんと身体がしんどくなってきて、寒気を感じてきたので、14時過ぎに再度体温を測ったところ、38.1度まで上昇。これは流石にいかんと思い、解熱剤を投入してその時点で在宅勤務を中止し、休息することに。ちなみにこの時点でも右上腕部の痛みが強くなることはありませんでした。ただ、何故が肩から背中の上部にかけてがバリバリな状態。もちろん右腕を無意識のうちに庇っていたという事情もあったのかもしれませんが、発熱よりもそっちの方が辛かったかもしれません。

軽く眠った後、17時には解熱剤が効いたのか、37.3度まで下降。何とか夕食をとって眠りについたのですが、どうもうまく眠れずに23時過ぎに起き出して再度体温計測したら、38.7度まで上昇。寒気と背中の上部の違和感は続いています。ここで再度解熱剤を投入して再度睡眠。

2/18 副反応の記録

5時に目が覚めたのでまずは体温の測定から。37.0度。身体も少し軽くなり、右上腕部の痛みも悪化することがなかったので、一旦様子見をして、7時前に36.7度まで熱が下がっていることを確認してからこの日は出社。移動には念には念を入れてグリーン車を使用しました。

出社の必要な要件は午前中のみだったので、やはり帰路もグリーン車を使って移動し、帰宅してしばらくさまざまな細かい仕事を済ませ、18時になって体温を測ったところ、37.2度まで上がり、インフルエンザの時のような節々の痛みを感じたので、この日は夕食をとらずに就寝。

2/19 副反応の記録

日付が変わって1時に目が覚めたので、ここでも体温の測定。ようやく平熱にほぼ近い36.6度まで下がりました。右上腕部の痛みもほとんどなくなりました。そして落ち着いている状態で現在に至っています。おそらく、一連の副反応としてはほぼほぼ終息したのではないかと。

大規模接種会場の運営に驚いた

報道ではなくとなく見ていた大規模接種会場ですが、実際に体験してみて、設営や運営の機動力や動線設計のスムーズさと、対応してくださった皆さんがとにかく丁寧で親切だったのには本当に驚きました。災害派遣を中心として、自衛隊の皆さんの活躍がクローズアップされることは多いですが、こういった形でも普段の訓練の成果がしっかりと発揮されているものなんですね。本当に、自衛隊と、携わってくださっている医療関係者の皆さんのご尽力には感謝しかないです。

そういった方々のご尽力に応えるためにも、COVID-19が無事に終息してくれることを願って、引き続きCOVID-19の感染対策に自分ができる限りの範囲で気を付けていきたいと思います。

カテゴリー: Private | タグ: | コメントする

私なりの通知機能との付き合い方 番外編


はじめに

前回の記事ではSlackとメールを中心に、飛び込んでくる通知をいかに絞り込んで仕事や作業の効率を上げるための工夫をしているのかを書いたのですが、通知に限らず、流れてくる情報は他にも色々あるわけで、その流れてくる情報をコントロールするためにどんな工夫をしているのかをもうちょっと加筆したいと思って、別の記事に仕立てました。

なお、前回の記事と同じなんですけれども、前提条件を書くのを忘れていました。ここでは在宅勤務化で圧倒的に向かい合うことの多くなった、MacBook Air (M1, 2020)上でどうコントロールしているかについて書いています。

というのも、私の場合ですが、この状況下で家にいることが多くなってから、スマートフォン(iPhone 12 mini)を見ることがほとんど無くなっちゃったんですよね。下手をすると平日は1日30分も見ていないかも知れません。そんなわけで、スマートフォンの通知に関するコントロールは今回はバッサリ割愛しているのでご了承ください。

Twitterから流れ込んでくる情報のコントロール

多くの人が利用しているであろうTwitter。もちろん私も利用しています。多分2008年くらいから使い始めて、2012年3月に一度リセットをかけているので、フォロー数/フォロワー数もそんなに多くありません。ミニブログという表現があるように、日頃考えたり思いついたことなどを投稿している一方で、ものすごく大量の情報も流れてくるわけで、これを全部読み始めるとキリがないのに加えて、公式Retweetの機能が実装されてからというもの、とにかくRetweetの量が多く、その中には時期によっては特定の(と、敢えて濁して書いておきましょうかね)バイアスのかかった情報も入ってくるのも事実です。

これはあくまでも私の考えですが、その人自身が(直接的にも、間接的にも)書いたTweetを読みたい人なので、結構ばさっとフィルタリングをかけています。

Twitterのタイムタインを読むためのアプリケーションは多数出ていますが、私は流れてくるTweetの仕分けのためにも、ここ数年間Updateがないのですが、TweetDeckを使用して、リスト化したタイムラインが表示されるようにしています。けれども、この状態だけでは公式Rtweetや、特定のキーワードを含むTweetが流れ込んできてしまうので、フィルタリング機能を使用して公式Retweetや特定のURLを含むTweetがタイムライン上に表示されないようにしています。

これをするだけでも心理的な安全性はかなり高まりますね。何か特別なことがあった時には情報を収集するためにもフィルタリングの条件を少し変えたりしますし、夜の遅い時間でもタイムラインを見ることがありますが、最近は20:00以降は見ないようになってしまいました。Tweetから受ける心理的な負担が睡眠に影響を及ぼすのをできるだけ避けようという意味合いもあります。それに睡眠大事ですからね。

もちろん、Tweetする権利もしない権利もアカウント持っている人だったら当然持っているのは当たり前ですし、その人がどのような使い方をするのかも、法令に反しない限りでは自由なので、受け手側がコントロールすればいいわけで、たまたま私の場合はこういうコントロールをすることによって精神的にも気持ち良く使わせてもらっています。TweetDeckなくなったりしたら結構困っちゃうかも知れませんねぇ。

情報のコントロールと分類も精神衛生維持のためのTips

通知機能との付き合い方、という本来の趣旨からはだいぶ外れてしまうかも知れませんが、インターネット(World Wide Web)の普及とともに、流れてくる情報の量が膨大になってきたのは事実で、それが結果として通知の多さにもつながってくるわけで、その便利さを享受しているのも事実なのですが、享受している分、そのまま飲み込むのではなくて、自分にとって(都合が良いか悪いかは別として)本当に必要な情報なのか、どんな情報として分類すればいいのかをきちんと整理する能力がだいぶ求められるようになったよなぁ、ということを日々痛感しています。

そしてそのことが、自分自身の精神衛生をできるだけフラットに保てるようにするためのTipsにも繋がるのかな、なんていうことを思っているのでした。

この記事を書くきっかけを作ってくださったみやひろさんに、改めて感謝。

カテゴリー: Private | タグ: | コメントする

私なりの通知機能との付き合い方


はじめに

このエントリーを書こうと思ったきっかけは、普段オンライン上で懇意にしてもらっているみやひろ@webディレクターさんからのこんなTweetでした。

確かに、ことコロナ禍に入ってオンラインでのツール群をコニュニケーション手段として使うようになってからは、通知地獄、とまではいかないけれども、ひっきりなしにやってくる通知に自分の作業の手を止めなければいけないというパターンは増えてきましたね。実際に、自分もメールの通知、Slackの通知、Teamsの通知がひっきりなしにやってきていて、おまけに現職ではミーティングの数が1日平均して3〜4件と多いので、それも含めて自分自身の作業が滞ることもしばし。

とはいえ、もうこれからの時代通知機能を完全に切る、というやり方はコニュニケーションロスが生じてしまうので、自分なりにどのようにしてうまく通知機能と付き合っていくのかをまとめてみることにしました。

コニュニケーションツールの通知とどう付き合うか

私が所属しているプロジェクトではSlackをコニュニケーションツールとして使用しているので、それを前提にして書いていきます。

まず、現時点で自分がどのくらいのチャンネルに所属しているのかを数えてみたら、32チャンネルもありました! 人によってはもっと多くのチャンネルに参加しているのかもしれないですが、これだけのチャンネルから通知が来てしまうとそりゃ大変です。なので、こういう風にして主としてウォッチするチャンネルを絞り込んでいるのと同時に、逆に相手を通知で困らせないようにコントロールをかけています。

宛先を絞り込む

つまり、Slackでいうところの@channelや@hereを可能な限り使わず、連絡を取りたい人に対してあくまでもチャンネル上で呼びかける、ということです。ポイントとしては以下の通り。

  • @channelや@hereを使わないことにより、無用な通知を増やさない
  • かつ、チャンネル上(≠DM)でコンタクトを取ることにより、属人化を防いで誰でも横から会話に参加できるようにする

スター機能を使って、常時確認するべきチャンネルを絞り込む

先ほど32チャンネルに所属しているというお話を書きましたが、そのうちにどうしてもみなければいけないチャンネルって大概限られているんですよね。なので、Slackのスター機能を使って常時確認する対象にしているチャンネルを、担当している案件によって常時最大5つくらいまで絞り込んでいます。以下のような感じで。

これだけでも結構負担は軽減されますね。それ以外のチャンネルは、メンションが飛んできたら応答するけれども、そうでない限りはさらっと読み流す程度にしています。

メールの通知とどう付き合うか

次に多いのはメールの通知。これもまた大変ですよねぇ。流石に仕事メールの画像を公開するのは厳しいので、プライベートでの工夫を中心に書きます。

ちなみに、プライベートでも1日あたりでメールは平日30通くらい受け取っているのですが、そのうちにやりとりとかしなければいけないメールの数って1/10くらいなんですよね。なので、こういう形で対応しています。

メールソフト(MUA)を2種類併用する

これってすごーく非効率なように見えるのですが、特にGmailなんかを使っている人だと、とにかくありとあらゆるメールが流れ込んでくるので、とてもじゃないけれども全部のメールを読んでいる暇がないわけです。

なので、メールソフト(MUA)を、

  • 通知を見るためだけのもの
  • きちんと仕分けをして本文をきちんと読んだり返信したりするもの

に分けています。私の場合、前者にはSparkを、後者にはGyazMailを使用しています。Gmailアカウントには、個人で保有しているすべてのメールアカウントから転送をする設定にしているので、Sparkには事実上すべてのメールが流れ込んできます。とにかくこれを通知機能でちらりと見るだけ。即時返信が必要なものを除いては基本的に返信しません。

で、GyazMailの方で実際にちゃんとメールを読んだり必要に応じて返信したりするわけですが、メールのやり取りをしている方はご存知の通り、返信する時間を基本的に7:00台から8:00台にルーチンとして決めています。もちろん緊急でやりとりしなければいけない場合は別ですけれども。そのようにして、タスクを行う時間を自分の中であらかじめ決めておくことによって、コントロールをかけています。直接的には通知とつきあうTipsとは関連しないかもしれませんが、そのタスクを行う時間を決めるというのも大事なのかなと。

通知音を出さないという心理的安全性

そうそう、個人的にはこれが一番大事なんじゃないかと思っているんですが、仕事用のPCでは基本的にスピーカーの音量をゼロにして、あらゆる通知音を出さないようにしています。でないと通知音そのものがだんだんストレスになってくるんですよねぇ。どうせ通知は視覚でわかるものだから、視覚で済むものに関しては視覚から得る情報で済ませてしまえと。これだけでも通知に対する心理的安全性はかなり高まります。

もちろんですが

もちろんですが、通知されてくる情報にはなんらかの意味があって通知されてくるので、それに対して完全に無視を決め込むことはできないというのは自明です。ただ、その人に対して関係性のない情報まで何でもかんでも流されてしまうと、本当に通知に埋もれてしまう生活になるので、そこのところは、各々うまくコントロールしながら対応していくと、リモートワーク生活もだいぶ楽になるんじゃないかなと思います。

あくまでこれは私が実行している例なので、皆さんそれぞれ、皆さんなりの工夫をしていただければと思います。そしてそれを是非共有してもらえると嬉しいかな。

カテゴリー: Work | タグ: , , | コメントする

Amazon EventBridge + AWS Lambda + Amazon DynamoDBでTwitterのbot機能を実装してみた


はじめに

これまでに幾つか、AWS上で動くリソースを制御するための自動化便利ツールを作ってきましたが、これをきっかけに日常の色々な作業を自動化するための布石として、なんかいいネタないかなぁと考えながら、builders.flashを眺めていたら、よくあるパターンのTwitterのbotをAmazon EventBridge + AWS Lambda + Amazon DynamoDBで実装してみるというちょうど良いネタがあったので、サクッと実装しつつ、若干のカスタマイズをしてみました。

シリーズものなのでまだまだ途中段階ですが、元記事は以下のリンクに示されているので、ここでは自分なりにカスタマイズした箇所のみを紹介していこうと思います。

カスタマイズしたところ

主に第2回に書かれている箇所が中心になるのですが、私の場合は過去に投稿した記事をランダムにTweetさせるように作りたかったため、まずはDynamoDBのテーブル項目に、パーティーションキーとして”Id”を設定しました。こんな感じ。これがまずは下準備になります。

次に、以下のコードのline.32のように、その時にTweetさせたい過去の記事のidを、random.randomint()関数を用いてランダムに生成させ、line.35で生成させたidをキーにしてget_itemさせるようにしました。もちろん、記事の数は(多分)これからもどんどん増えていくので、ここでidの数をハードコードせずに、一旦line.13でLambda関数の環境変数から取得するように実装を追加しています。

また、記事のコードでは現段階ではエラー処理が実装されていないので、エラーハンドラも仮で実装しています。その全体像がこんな感じ。なんか一部余分な処理が入っていますが、そこは大目に見てください。。。

import json
import os
import boto3
import logging
import traceback
import random
from requests_oauthlib import OAuth1Session
from datetime import datetime, timedelta, timezone

logger = logging.getLogger()
logger.setLevel(logging.INFO)

ids = int(os.environ.get('POST_ID'))

dynamodb = boto3.resource('dynamodb')
twitter_bot_message_table = dynamodb.Table('TwitterBotDailyMessage')

JST = timezone(timedelta(hours=+9), 'JST')

# API Key, Access Token(元記事にも書かれているとおりで本来はハードコードしてはいけないです。連載が進んだ時に直します)
consumer_key = "Twitterから取得したAPI Key"
client_secret = "Twitterから取得したAPI Key Secret"
access_token = "Twitterから取得したAccess Token"
access_token_secret = "Twitterから取得したAccess Token Secret"

oauth = OAuth1Session(consumer_key, client_secret, access_token, access_token_secret)


def lambda_handler(event, context):
    
    text = ""
    id = str(random.randint(0, ids))

    try:
        response = twitter_bot_message_table.get_item(Key={'Id': id})

        if ('Item' in response):
            text = response['Item']['Message']
        
        payload = {'text': text}
        response = oauth.post(
            "https://api.twitter.com/2/tweets",
            json=payload
        )
    
        if response.status_code != 201:
            raise Exception(
                "[Error] {} {}".format(response.status_code, response.text)
            )

    except Exception as e:
        logger.error(e)
        logger.error(traceback.format_exc())
        return {
            "statusCode": 500,
            "message": 'An error occured at tweet old Blog post.'
        }

EventBridgeの設定はお好きなようにという感じで。私の場合は、あまり頻繁に過去記事を投稿するのもなんだかなぁ、ということで、以下のcron式を設定。とりあえず週末だけ動かします。

cron(5 5 ? * SAT-SUN *)

で、EventBridgeを発火させたらこんな感じで無事にTweet成功。

今後やりたいこと

ここまで実装した段階だと、Blogの記事を投稿する度にDynamoDBに項目追加をして、Lambda関数の環境変数も手作業で修正しなければいけないのが面倒なところなので、記事を投稿したタイミングをトリガーにしてDynamoDBに項目を追加しつつ、環境変数もさらに外出しして完全自動化していきたいところ。やり方はたくさんあると思うのですが、まだ絶賛連載が進行中のようなので、ゆっくり機能拡張していきたいと思います。

カテゴリー: AWS | タグ: , , , | コメントする

Violaレッスン2回目


今日は朝から、りきひさみねこ先生のViolaレッスン2回目でした。いやぁ楽しい。

先々週のレッスンでは、まずは右手と右腕を大改造しましょう! というところから始まったのですが、今回もその続き。弓の持ち方とボウイング(特にダウンボウ)の時の腕の伸ばし方を徹底的に大改造という感じで進行しています。

やはり長きにわたっての慣れというのは怖いもので、ダウンボウで弾き切った時に肘が完全に伸び切っていない状態に、いつの間にかなってしまっていたようです。というわけで、まずは弾き切った時に腕と楽器と身体が三角形の形になるように、またその時に弓の向きが逆方向に反ってしまうので、可能な限り弓の毛の向きを自分の身体側に向けられるようにとひたすらボウイングの練習です。これがなかなかきついというか、手首の関節が硬すぎて、肘を伸ばし切った時にうまく関節を使うことができていないみたいです。これはちゃんと手首の関節を柔軟に曲げられるようにしないといけないな。

合わせて親指の位置も大幅に修正。弓に対して直角になるように意識することと、今までは親指の腹の位置で弓を持ってしまっていたので、腹の中ではなくてできる限り爪に近いところで弓に指を刺すようにして持つように修正。こちらはなんとかうまくいけそうです。

まぁそんな感じで今回もあっという間にレッスン時間が過ぎていったのですが、りきひさ先生がポジティブな雰囲気で指導してくださるので、こっちも俄然やる気になってくるものですね。

元々基礎を見直すためにレッスンを再開したので、当面の間は基礎を見直すことに集中していこうと思います。実際に曲を弾いていくのはもう少し先になるかな。それでもこれまで当たり前のように続けてきたことを最初から見直して修正していくのって、なんだか楽しいですね。

レッスン後には先生から今回のレッスンのポイントのメモが送られてきて、ありがたや〜。

次回のレッスンも楽しみです。

カテゴリー: Private | タグ: , | コメントする

JBUG広島 #9 x Agile Japan HIROSHIMAに参加しました


JBUG(Japan Backlog User Group)は、ヌーラボさんのプロジェクト管理ツールであるBacklogのユーザを中心としたコミュニティなのですが、単純にBacklogだけではなく、より良いプロジェクト管理やタスク管理の仕方など、さまざまな分野に視野を広げて、プロジェクト管理を民主化できるようにしよう! という目的で活動しています。

最近はもっぱらオンラインでの勉強会が主体となっていますが、逆にオンラインになったことで、物理的な距離を超えてさまざまな場所の勉強会に参加することが可能になりました。

今回は、「JBUG広島 #9 x Agile Japan HIROSHIMA」ということで、Agile Japan HIROSHIMAさんとの共催という形でオンラインで勉強会が開催されたので、ちょっとここのところ本業の関係でサボり気味だったのですが、久しぶりに参加することができました。

敵は敵の顔をしては向かって来ない(福井 桂太さん)

何か新しいことを始めようとする時には、組織の中にいる「抵抗勢力」と1対1で勝負をするのではなく、たとえ劣勢でもいいから公開の場でやりとりをしていくのがいいというお話。

もちろん「抵抗勢力」側の人も正論をぶつけてくるんだけれども、お互いに正論をぶつけ合ってもなかなか幸せになれるとは限らないんですよね。なので、賛成派4割を作らなくても、あえて劣勢派側に回ってオープンに議論を重ねていく方が、結果としてはみんな幸せに新しい物事が進んでいくんだよね、っていうことを感じました。

やさしいBacklogの使い方(待島 亘さん)

クライアントさんに向けてBacklogを使ってもらう際に、こういう形で導入していくといいよというベストプラクティスに関するお話。

Backlogを快適に使用してもらうためのエッセンスが満遍なくお話の中で散りばめられているだけでなく、それをわかりやすくまとめてくれているスライドがとても素晴らしかったです。きっと、待島さん、相当Backlogの良さを理解されていて、理解されているがゆえにとてもやさしい解説ができているのではないかというところが素晴らしかったです。穏やかなお話の仕方がそれに相乗効果をもたらしてくれたというか。とても眼福なお話でした。

「google/zx」と「Backlog API」を組み合わせたJavaScriptのプログラムからのBacklog操作(豊田 陽介さん)

Backlog APIをうまく用いて、Backlogに関する操作を自動化していこうというTipsに関するお話。

Backlog APIは以前から気になっていたのですが、なかなか使う機会がないまま時間だけが過ぎていったという経験を持っているので、Node.jsや、google/zxを用いて簡単に実装ができるということをわかりやすく解説していただき、これなら自分も実装できるかも! という良いヒントになりました。これAWS Lambdaを使っても十分に何か実装できると思うので、ぜひ実装してこのBlog上でこんなの作ってみたというのをFBしてみたいですね。

小学生がBacklogのプロジェクト管理を参考にして、夢に一歩だけ近づけた話(吉田 彩さん)

Backlogの考え方やエッセンスを応用して、娘さんの学習に活用しているというお話。

正直、初めは娘さんがBacklogを実際に使うのかなというお話だと思ったんです。けれども実際に出てきたのはホワイトボード。なるほどホワイトボードを使ってタスクをコントロールしていくというのは、小学生でもできますし簡単に可視化できるのでいいですね。手段ではなく、あくまでも目的を明確にしてゴールに向かってやるべきことをこなしていこうというアイデアが純粋にすごいなぁと思いました。これうちの娘にも教えてあげたい。

アジャイルの心と未来の働き方(アリスター・コーバーンさん)

Agile Japan 2021の基調講演の中から、アリスター・コーバーンさんの講演を振り返るという内容だったのですが、これもまた素晴らしかったです。

アジャイルって、単純にソフトウェア開発に適用されるメソドロジーであるということに限らず、コラボレーションがとても大事であることとか、信頼関係とオーナーシップが大事だよということとか、これからVUCAの時代の中で仕事を進めていくにあたっての良いエッセンスを得られただけでなく、これから仕事を続けていくということそのものに対して大きな勇気をもらったような気がしました。可能であればこの基調講演の内容、何回か見直して身に染み込ませたいですね。

オンライン勉強会を通して得られる気づきの多さ

ひとつの組織の中でももちろんさまざまな人が働いているわけですけれども、やはり組織という単位ではあくまでもひとつなので、だんだん考え方がサイロ化してしまってなんだか行き詰まるなぁという状況が出てくるわけです。

そんな時に、今回のJBUG広島 #9 x Agile Japan HIROSHIMAにしてもそうなんですけれども、オンライン勉強会に参加すると途端に世界観が広がり、自分の仕事の仕方に対するたくさんの気づきやFBがいただけるんですよね。それがとても心地よいというか、私的探究心を深めていく上で本当に勉強になります。

改めて登壇者の皆さんと、JBUG広島やAgile Japan HIROSHIMAの運営を支えてくださっている皆さんに感謝です。

カテゴリー: Work | タグ: , , | コメントする

Violaのレッスンを受けるのを再開しました


はじめに

ご存知の方はご存知の通り、私は大学入学と同時にViolaを始め、大学オーケストラで4年間活動した後、他大学のオーケストラの賛助活動などを経て、市民オーケストラを中心としてViolaを弾いています。

ですが、このコロナ禍に入ってからオーケストラ活動が完全に停止してしまい、さらに在宅勤務の忙しさも相まってViolaに触る機会がめっきり減ってしまったことと、大学オーケストラ時代にはトレーナーとしてみてくださっていた、元日本フィルハーモニー交響楽団の先生に師事していたものの、社会人になってからは完全に自己流に近い形で演奏を続けることになり、そろそろ基礎力を見直しつつ、定期的にViolaを弾く機会をなんとか作らなければなぁと思っていたのでした。

まぁそこで個人レッスンを引き受けてくれる先生を探そう! ということになったのですが、Violinに比べるとViola人口というのはやはり少ないので、自宅で近いところにあるのかなぁと思いつつも探してみたところ、速攻で見つかり、まずは体験レッスンからということで、りきひさみねこ先生と連絡をとらせて頂き、体験レッスンに行ってきました。

右手の大改造に着手

りきひさ先生、本当に初めてお会いしたのですが、とても明るくてハキハキした方で、レッスン開始前からリラックスできました。とはいえ流石に最初、まずは何かしら弾いてみましょうということで、持参したViolaの教本”SITT”のとある練習曲を弾いた時にはだいぶ緊張するし、突っかかるし、弾きながら辺な汗が大量に出てくるという状態。それでも先生は丁寧に弾く様子を見てくださり、

右手の改造をすればきっと楽器が持っている力が十分に発揮されますよ!

とおっしゃってくださいました。別に右手を手術するというのではなく、弓の持ち方をまずは修正していきましょうということですね。

弓の持ち方や楽器の構え方のような基本的な奏法に関することは、大学オケの先輩だけではなく、学生時代に師事していた先生からも教え込まれていたのですが、そこから20年も経過すると流石に崩れていくるものですね。なんだか変な弓の持ち方で慣れてしまっているので、逆に右手の変なところに力が入っていたり、手首の曲げ方もおかしくなっていたり、そういったところを丁寧に修正してくださいました。とはいえ、簡単に修正できるわけではないので、ここでも先生に教えていただきながら大汗。

少し期間を要することにはなると思いますが、まずは右手の使い方の改造に着手をして、そこから本格的に曲を見ていただくという形になると思います。

確かに何をするにしても、その時の姿勢ってものすごく大事で、ちゃんと往々にして修正していかないとだんだん崩れていくわけで。その点から着手してくださるところ、とても感謝です。

というわけで、これから2週間に1回、継続して先生のレッスンを本格的に開始することにしました。自分の弾き方がどんな風に変化していくのか楽しみであります。

カテゴリー: Private | タグ: , | コメントする

娘と一緒に福岡 & 太宰府へ


すごく珍しいね、と言われることが往々にしてあるのですが、父娘で旅行に出ることが多いです。

コロナ前の2019年11月には韓国ソウルへ行きましたし、コロナに入ってからも、感染状況の谷間を見ながら、特に福岡県を中心に飛行機で旅行に出ています。

そんなわけで、フライトログをかねて簡単に記録。

フライトログ

  • 2022/1/15 NH245 HND → FUK 788 JA802A 4H
  • 2022/1/16 NH258 FUK → HND 788 JA831A 1C

往路のCAさんに、娘が高校に合格してそのお祝い旅行なんですよ、という話をしたら、素晴らしい神対応をしてくださいました。本当にこのような細やかな心配りをしてくださるANAさんは大好きです。

簡単に旅行記録

福岡空港からは地下鉄と11番の西鉄バスを乗り継いで渡辺通にあるホテルに一旦荷物を預け、68-1番の西鉄バスで天神へ向かい、前回食べてとても美味しかった「おむや」さんのオムライスを堪能。相変わらずボリューミーで美味しかったです。

その後西鉄福岡(天神)駅13:00発の大牟田行き特急と太宰府線普通を乗り継いで太宰府天満宮へ。娘が3年間お世話になってきた家庭教師の先生が、今年医師国家試験を受験するため、その合格祈願をしてきました。おみくじは小吉だったなぁ。

で、参道に戻ろうとした時に、カフェの看板がこじんまりと立っているのを見て行ってみようということになり、行ってきたんですが、これが当たりで、居心地が良くとても良い空間でした。イチゴのタルトも美味しくいただきました。「CoRicco」というカフェです。店主さんとリノベーションの話についても盛り上がったり。素敵な店主さんでした。

太宰府からは太宰府線普通と西鉄福岡(天神)ゆき特急を乗り継いで薬院駅で降り、夜に16番の西鉄バスと214番の西鉄バスを使って博多で軽く晩御飯を食べて1日目は終了。

2日目は、どうしても行きたいカフェがあるという娘からのリクエストを受けて、一旦タクシーで博多駅まで出て荷物を預け、JRの線路沿いをてくてく歩いて「AIMAI」というカフェへ。娘はその空間にどハマりしていて、僕はカウンターの窓越しを走るJR九州の電車に見惚れてました。

そうこうしているうちに復路のフライトの時間が迫っていたので、博多から地下鉄で福岡空港へ向かい、サラッと帰ってきました。

娘との二人旅もいいもんだ

何故かわからないけれども、娘とは嗜好とか空気感が似ているところがあるようで、二人旅していても飽きないんですよね。いや父親冥利に尽きるものです。いいもんですよ。これからも感染状況を見つつ、娘と国内色々なところを巡ってみたいですね。

カテゴリー: Private | タグ: , , , | コメントする

AWS請求関連の情報を表示できないようにするためのIAMのカスタマー管理ポリシーを書いた


はじめに

この記事は2022年1月12日現在で発生している現象を元に作成したものです。Amazon Web Services側の仕様変更により記述した記事の内容に変化があるかもしれない点についてはご了承ください。

AWSマネージメントコンソールのホーム画面がカスタマイズできるようになったという知らせを知ったのですが、その影響なのか、元々実装していた、見せてはいけない人に請求関連のサービスの情報を見せないという内容のカスタマー管理ポリシーが効かなくなっていたので、急遽該当するカスタマー管理ポリシーを、以下のように書きました。

作成したカスタマー管理ポリシー

こんな感じです。要点としては、

  • AWSマネージメントコンソール上で請求に関する情報を見せることを明示的に拒否する
  • AWS Budgetsのすべての権限を明示的に拒否する
  • AWS Cost and Usage Reportsのすべての権限を明示的に拒否する
  • Amazon Cost Explorerのすべての権限を明示的に拒否する

という内容になります。もっとこうした方がいいんじゃないのという意見もあるかもしれませんが、結構緊急避難的に90分くらいで仕様確認と実装と動作確認をしたので、その辺は何卒ご容赦を。。。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "aws-portal:*Billing",
                "aws-portal:*Account",
                "aws-portal:*PaymentMethods",
                "budgets:*",
                "cur:*",
                "ce:*"
            ],
            "Resource": "*"
        }
    ]
}

なんか、AWSさんの作り込んだバグなんじゃないかという情報もちらほら聞こえてきて、しれっと仕様変更が入ってまたこのカスタマー管理ポリシーを直さなければいけないという可能性もあるのですが、その時はその時で、このエントリー上で修正版を共有しようと思います。

カテゴリー: AWS | タグ: , | コメントする

“会社は「仲良しクラブ」でいい”を読んだ


はじめに

株式会社ヌーラボといえば、プロジェクト管理ツールとして課題をわかりやすく可視化しながら共有することのできる“Backlog”や、構成図やワイヤーフレームを共有しながら作図することのできる“Cacoo”のような、チームやステークホルダーの人たちとコラボレートしながら快適に仕事を進めていくことのできるプロダクトを世に送り出している、福岡発のベンチャー企業として多くの人々に知られています。

ただ単純に知られているといえばよくあるベンチャー企業のひとつとして捉えられてしまうかもしれませんが、「知られている」だけでなく、送り出しているプロダクトを通じて「愛されている」のもこの企業の特徴なのかもしれません。実際にBacklogやCacooには、企業が出しているプロダクトであるにも関わらず、それらを使用する人のコミュニティが存在し、活発に活動が行われているように、企業が開発したプロダクトを通じてより良く仕事ができるようにナレッジを共有している事例が多数あるのも特徴的なのではないかと思います。

そんなヌーラボを率いているのが橋本正徳さん。ベンチャー企業だと、創業者の顔がものすごく際立つという傾向があるのですが、私の知る限りでは、「ヌーラバー」と呼ばれるヌーラボの社員の方々が自律的に活動していく中で、一歩引いてその姿をやさしく穏やかに見守っているようにも見えます。

そんな橋本さんが「会社は「仲良しクラブ」でいい」という本を出されるという話を聞いて、橋本さんの人となりだけではなく、どうしてヌーラボという会社を立ち上げたのか、その中でどんなことを大切にしながらチームを率いているんだろうかというところに興味を抱いて、早速手にとったのでした。

プロジェクトや組織をポジティブに進めることのヒント

組織やプロジェクトには、実際にさまざまな属性の方がいます。プロパーやビジネスパートナーといった所属会社の違い、役職の違い、各々が持っているスキルの違い、考え方の違い、挙げていったらキリがありません。けれども組織やプロジェクトという「集団」として考えるとひとつのまとまりのようなものであって、それがとある目標に向かって進んでいくというミッションを持っています。

とはいえ前述の通り、そこに所属している方たちにはさまざまな個性があるわけで、時にはその個性を押しとどめても集団のために動かなければいけないという状況が往々にしてあるということも、私自身のこれまでの勤務経験の中で痛感してきたというのもまた事実です。

問題はその個性の部分を集団の中でどのように生かしていくと「新しい想定外の1」に変わるのかという、ある意味ポジティブな工夫やマインドの持ち方のヒントが数多く、しかも余すことなくオープンに書いていただいているところが本当に勉強になりました。

特に、私がどちらかというと自分のウィークポイントとして認識しているアンガーマネジメントに関する考え方だけでなく、この状況の中でオンラインでのコニュニケーションが中心となっている中で、「コミュニケーションは上手くいかなくて当たり前」という前提のもとで、「まず相手を信用する」というところから対話や仕事上でのタスクを渡すというアプローチは、現在の仕事の中でも活かすことができる部分が多くあり、自分のこれまでの仕事の仕方を省みてこれは改善できるかもしれないという形で、自分が変えたい側面に対して背中を押してもらうことができました。

きっと、この本を読むと、私だけでなく誰もがこのような気づきを感じるのではないかと思います。橋本さんのことなので、「金言」と書いてしまうといやいやそんなことはないよと言われてしまいそうですが、色々な属性や個性の方々と仕事(だけではないかもしれません。オーケストラなんかもそうかもしれませんね)をしていく中で、どのようにコラボレートしていけば物事が上手く流れてくれるかというエッセンスをたくさんいただいたような印象を持っています。

「偏愛家」というキーワードに関してもとても興味深く思いました。「偏愛家」というと、世間的にはオタク的なちょっとネガティブともとられてしまうかもしれない印象を持たれてしまいがちですが、それも実は個性の一部で、誰もがそのひとつやふたつは持っているのではないかと思うんですよね。

その偏愛的な部分を自律した個性やスキルのひとつとして尊重して生かしながら、集団としてのアウトプットにポジティブに反映するにはどのようにすればいいのかという点に関しても非常に興味深く読みました。

他にも組織やプロジェクトの価値をボトムアップしていく上でのさまざまなエッセンスが詰まっているのですが、これ以上書くとネタバレになってしまうので書くことはやめておこうと思いますが、全体的に思ったのは、これまでプロジェクトの中で働いていくことに対する閉塞感やモヤモヤ感を意外な形で払拭してくれた本でした。

組織論やチーム論に関する書籍は数多く出ていますが、これまで読んできたものに比べて非常に読みやすい印象を受けました。この本をこのタイミングで執筆してくださった橋本さんには心から感謝です。

カテゴリー: Work | タグ: , | コメントする