Hikaru Wada

龍雲寺 涅槃堂#断食 #禅 #修行 はじめにこの記事は一週間の禅寺体験記の最終日（7日目）をお届けします。これまでの体験記をまだ読まれていない方は、ぜひ先にそちらをご覧ください。 一日目（初日） 二日目 三日目 四日目 五日目 六日目最後の朝を迎えていつもと同じ5時半の目覚め。でも、今日は少し違う気持ちで目が覚めました。「これが最後なんだ」という思いが、朝一番から胸にありました。朝の準備をしながら、部屋の掃除を丁寧にしていきます。一週間使わせてもらった部屋です。感謝の気持ちを込めて、できるだけ綺麗な状態で返したいと思いました。洗面台での朝のルーティーンも、「これで最後」と思うと、どこか特別な気持ちになります。毎朝書いてきた祈祷・供養依頼紙。最後の日は、誰の名前を書こうか、いつもより長い時間考えました。この一週間、いろんな人の名前を書いてきましたが、希望する全員の名前が書けるわけではありません。しばらく座って、自分の気持ちと向き合い、書く人の名前を決めました。外はまだ日の出前の薄暗い空でした。和尚に言われるがままに屋上に出てみると、黒々とした富士山のシルエットが見えました。冬は空気が澄んでいるので、天気がいいと見られることがあるのだそうです。その姿を見ていると、なんだか力が湧いてきました。最後の朝のお勤めいつもの場所に座って、最後の朝のお勤めが始まりました。供養祈祷の時、自分が書いた人の名前がはっきりと聞こえてきた時は、胸が締め付けられるような気持ちになりました。この一週間、毎朝同じ場所で同じように座って、でも今日が最後なんだと思うと、なんとも言えない気持ちでした。印象に残った法話この日の法話は、四十九日法要についてでした。龍雲寺のある地域では、亡くなった人のために七日ごとに供養をして、四十九日まで続けるそうです。最後の四十九日には、その人が極楽浄土に行けるかどうかの判決があるんだとか。面白かったのは、四十九日に餅を作る習慣の話です。地獄に行くと鬼に四十九の関節に釘を打たれるそうなんですが、残された人たちが餅を供えて法要をすれば、鬼が身体の代わりに餅に釘を打ってくれるんだそうです。でも大事なのは、その餅を供えることじゃなくて、法要の後に他の人に配ること。「施す」という行為が重要なんです。和尚さんが言うには、今は四十九個も餅を配れるほど参列者が来ないし、地域の人に配っても信用されなくて食べてもらえないことが多いそうです。結局、親族だけで持ち帰ることが多いんだとか。それと、「施す」ことについて、深い話がありました。見返りを求めないことが大切だと。「喜んでほしい」とか「お礼を言ってほしい」という気持ちも、実は見返りを求めているんだそうです。そういう思いもなく、ただ純粋に施す。挨拶も同じで、ただするだけ。そういう純粋な行いが大切なんだと教えてもらいました。思い出の場所で法話が終わって、いよいよ帰り支度です。多くの人が涅槃堂で最後の写真を撮っていきます。私はスマホを持っていなかったので、ただじっと眺めて記憶に焼き付けようとしていました。そんな時、同じ日に帰る方が声をかけてくれて、一緒に写真を撮ってくれることになりました。後でメールで送ってもらえることになった写真が、この連載の表紙になっています。本当にありがたい出会いでした。帰り道に向けて禅堂に戻って荷物をまとめます。毎日掃除をしていたので、片付けはすぐに終わりました。最後にもう一度、部屋からの景色を眺めました。屋上にも上がって、周りの風景を目に焼き付けました。広間では、同じ日に帰る人たちと話をしました。みんなそれぞれ違う人生を歩んできて、違う目的でここに来ていて、でも不思議なことに同じ日に帰ることになった。そんな偶然も、何か意味があるんじゃないかと思えました。最後に和尚さんから言われた言葉が心に残っています。「娑婆に出ると、外からの刺激がたくさんある。自分の思うようにならないことがたくさんある。だから5分でもいいから自分の心を見つめる時間を持って、自分を見失わないように」。一週間ぶりの日常へお寺を出て、まず困ったのは帰り道がわからないことでした。しばらく封印していたスマホを取り出して電源を入れると、たくさんのメッセージや通知が届いていました。昔の自分なら、すぐにそれらの通知に振り回されていたと思います。画面の向こう側ばかり見て、目の前の現実が見えなくなっていた。そんな生活はもう終わりにしたいと思いました。その場でスマホの通知設定を見直すことにしました。この一週間は、いろんな感情が湧き上がってきました。でも不思議と、帰るころには心が整理されていました。少なくとも、これからどう生きていくかの方向性が少し見えてきた気がします。これからは、もっと外の世界を大切にしたい。スマホの画面じゃなくて、目の前の景色をちゃんと見つめたい。そんな気持ちを強く持って、新しい一歩を踏み出すことができました。

禅と暮らす一週間。体験記 最終日 2024年秋

龍雲寺 涅槃堂#断食 #禅 #修行 #木魚はじめにこの記事は一週間の禅寺体験記の六日目をお届けします。これまでの体験記をまだ読まれていない方は、ぜひ先にそちらをご覧ください。 一日目（初日） 二日目 三日目 四日目 五日目最後の一日の始まり六日目の朝を迎えました。明日は朝のお勤めを最後にこのお寺を出ることになりますが、それ以外の活動は今日が最後となります。一つ一つの動作を丁寧に行い、初めてここに来た時の気持ちを常に忘れないようにしながらこの貴重な体験を心に刻んでいきたいと思います。毎日続けている坐禅も、だんだんと体が慣れてきました。呼吸に意識を向ける数息観も、以前より長く集中できるようになってきました。ただ、この静かな時間が終わってほしくないという気持ちが強くなればなるほど、あっという間に時が過ぎていくように感じます。昨夜の夕食時に集まったメンバーを見てわかったのですが、9名の新メンバーが増えていました。見知らぬ人でいっぱいになると次の世代への移り変わりを肌で強く感じました。法話 - 三毒との付き合い方今日の法話は「三毒」についてでした。三毒とは、貪欲（とんよく）、瞋恚（しんに）、愚痴（ぐち）の三つの煩悩を指します。三毒と上手に付き合っていく必要があります。お釈迦様でさえ、悟りを開くまでには長い修行の道のりがあったそうです。そして、三毒を完全に消し去ることができたのは、歴史上お釈迦様だけだとおっしゃいました。西遊記という有名な物語があります。三蔵法師の17年半に及ぶ天竺への旅は、三毒との戦いを表現していたのだそうです。孫悟空、猪八戒、沙悟浄という三人の個性的な仲間たちは、それぞれ三毒を擬人化したものだと教えていただきました。私たち凡人にとって大切なのは、これらの煩悩を完全になくすことではなく、上手にコントロールすることなのだと学びました。時には息抜きをしたり、欲に従うことがあっても、やりすぎず、かといってやらなさすぎもしない。その中庸を探ることが、仏教でいう「中道」の精神なのだそうです。デジタルデトックスの効果これまで6日間、スマートフォンやパソコンから離れて生活してきて、心の中に大きな変化を感じています。これまで常に気にしていた些細な心配事が、自然と薄れていきました。代わりに、目の前のことに集中できるようになり、一瞬一瞬を大切に過ごせるようになってきました。今悩むことがあるとすれば、この心をいかにして今後も持っておくのかということだけでした。一日一度は座って身と呼吸を整える習慣をつけておきたい。食事の時も貪るように食べるのをやめて、丁寧にゆっくり噛んで食べ、作ってくれる人や命に感謝していただきたい。そんなことを考えていました。木魚体験最後の仏教体験として、木魚について学びました。一見シンプルに見える木魚ですが、その歴史と意味を知ると、とても深い学びがありました。大きな木魚は製作に15年もかかるそうです。その時間のほとんどは、木材を自然乾燥させる期間だと伺いました。木魚の表面に彫られた龍の体と魚の顔、持ち手の二匹の魚が玉を咥えようとする姿は、悟りを目指していることを意味しているそうです。実際に木魚、小鏧（しょうけい）、大鏧（だいけい）を使った演奏体験では、その難しさを痛感しました。右手で木魚のリズムを保ちながら、左手で鐘を鳴らし、さらにお経を唱えるという複雑な作業は、想像以上の集中力と技術が必要でした。朝のお勤めや法事で毎日ミスなくこなせるお坊さんの凄さを感じました。お坊さんの修行は精神修行だけじゃないんだなぁ。明日の読経で参加者が木魚を叩くことになりました。その際に叩く曲をあみだくじで決めたところ、私の担当は般若心経に決まりました。ちなみに「あみだくじ」という言葉自体も、阿弥陀如来の後光に由来すると調べたら書いてありました。最後の夜を迎えてこの日の最後、シャワー後の浴室掃除をしながら、様々な思いが湧き上がってきました。次に使う人への思いやり、清掃員の方への感謝の気持ち。目に見えない心の繋がりの大切さを、改めて実感しました。荷物を整理し終えた後、窓から見える夜景を眺めながら、この六日間の体験を振り返りました。明日で終わってしまう寂しさと、新しい自分と日常生活への期待が入り混じる複雑な思いを抱きながら、静かに就寝をしました。この連載も次が最後になります。最後までお楽しみに。

禅と暮らす一週間。体験記 六日目 2024年秋

龍雲寺 涅槃堂#断食 #禅 #修行 #枯山水はじめにお寺での一週間体験記の五日目をお届けします。まだ過去の記事を読んでいない方は、そちらも併せてご覧ください。サムネが全部同じになってしまっていますが、デジタルデトックスで写真が少ないのでこのようになってしまいました。カメラを買っておけばよかったなぁ。 一日目（初日） 二日目 三日目 四日目夢五日目です。一週間の生活も折り返し地点を過ぎ、終わりが近づいています。普段と全く異なる生活リズムにもいよいよ慣れてきて、環境にも適応してよく眠れるようになってきました。しかし、この日は二度寝してしまい、二回目のアラームで慌てて起きました。油断は禁物です。禅堂に来てからは、普段はほとんど見ることのなかった夢をたくさん見るようになりました。初めての散歩この日は天気が良く、初めて佐鳴湖を一周することにしました。これまではスマホが手元にないため土地勘も無く外出に億劫になっていましたが、禅堂のメンバーから自由時間に佐鳴湖を一周したという話をよく耳にしていました。そこで、お寺の目の前に広がる佐鳴湖なら迷わず戻れるだろうと思い外に出ました。外に出ると、工事中の作業員、車、ランニングする人、散歩する人など、たくさんの人々がいます。禅堂にいた時は限られた人しか見かけなかったので、外界の情報量の多さに驚きながらも歩を進めました。湖畔では、カモや鳥がのんびりと泳いだり、くつろいでいる様子が見えました。木々の間を飛び交う鳥たちは、互いに様々な鳴き声を発していて、その音の多様さに驚きました。途中、季節ごとに現れる鳥やカモの一覧と特徴が記載された看板を見かけましたが、本当に多くの種類の鳥が生息していることがわかりました。散歩中、多くの人とすれ違いましたが、皆暗い表情で俯いて歩いていて気になりました。児童に挨拶しただけで不審者扱いされるような現代社会。知らない人を警戒し、信用しないことが当たり前になってしまいました。それでも私は、できるだけ笑顔で地域の人々に挨拶できる人間になりたいと思います。約5.5kmの散歩を2時間かけて終え、無事に禅堂に戻ることができました。めでたしめでたし。法話この日の法話は、晋山式についてでした。晋山式は、新しい住職が就任する際に行われる儀式で、近隣のお寺の住職が参列し、地域の子どもたちも稚児行列として参加します。住職は、私たちが普段の生活で、見えない人々の努力に感謝できているだろうかと問いかけられました。当たり前のように使っている電話、歩いている道、住んでいる建物など、すべては自然と生まれたわけではなくて、自分が目にしていない誰かが作ってくれたもの。その大地の上で自分の豊かな生活が成り立っていることを考えたことがあるか。自分の生活なんだから、自分の勝手だと我儘に暮らしてないか？命だって、みんなに支えられて繋いでいる。そんな思いで生活を見直してみるといいのかもしれません。仏教体験今日の仏教体験は、枯山水の線引きでした。お寺の玄関先の庭にある枯山水を作る体験です。龍雲寺の庭は本堂への入り口に面し、中央に通路があり、左右は龍と亀がイメージされています。説明を受けて、何気なく置かれている石や植物の全てに意味が込められていることを知りました。今度他の枯山水を見る機会があれば、考えてみたいなと思います。さて、枯山水の情報はこのくらいにして線引き体験ですが、最初は誰も名乗り出ないので、私が率先して線引きに挑戦しました。プライドを持っていても仕方ないし、下手な線を描き、恥をかいて後の人がやりやすくなればいいと思ったからです。地面の傾きや小石の量のばらつきがあり、直線を引くのが思いのほか難しかったです。その後、円を描く体験もありました。円の方が個人的にはやりやすく、結構上手に描けたような気がします。参加者全員が一回ずつ体験し、最後に描いた線が一週間後まで残されることになりました。振り返り佐鳴湖を散歩しながら見た光景は、スマホを触りながら街を歩いていたら気づくことができないものばかりだと感じました。この生活が終わっても、散歩するときはスマホを触らず、周りにある小さな感動に気づけるようになりたいです。明日は最後の丸一日。気合を入れて一つ一つを大事にやろうと心に誓いました。正直まだまだいたい気持ちはありますが、会社に戻って仕事もしなければと、現実を少しずつ思い出し始めています。

禅と暮らす一週間。体験記 五日目 2024年秋

龍雲寺 涅槃堂#断食 #禅 #修行 #写経はじめにお寺での一週間体験記の四日目をお届けします。まだ過去の記事を読んでいない方は、そちらも併せてご覧ください。 一日目（初日） 二日目 三日目生活に慣れてきて四日目ともなると朝6時前の起床にも慣れ、日課をスムーズにこなせるようになってきました。でも、一つ一つの行動を丁寧にしようと心がけています。床を掃く時も、心の塵を払うような気持ちで隅々まで掃除をしました。いつものように朝のお勤めが終わり、自由時間になると、チェックアウトする人たちが帰り支度を始めていました。お茶を汲みに広間に行くと、私と同じように一週間を過ごしていた方が大きな荷物を持って出発の時間を待っていました。この方とは二日目の水引体験をきっかけにして仲良くなったのですが、もうお別れの時が来てしまいました。四日目になると、私が来た時にいた人はほとんどいなくなり、新しい人ばかりになっていて、少し寂しく感じました。帰られる方は京都の綾部から来られた方で、介護の仕事をしているそうです。仕事のストレスや、これから始まりそうな親の介護のことで悩んでいたとのこと。でも、ここでの一週間で「介護以外の仕事にも挑戦してみたい」と考えられるようになったと話してくれました。お別れの時の表情は明るく、前向きな気持ちが伝わってきました。自分も三日後には同じように帰る時が来ますが、こんな風に前を向いて帰りたいなと思いました。法話についてこの日の法話は、人のプライドについてでした。境内には、ダウン症の天才書家・金澤翔子さんの作品がたくさん飾られています。世界一大きい般若心経を書いたことでも知られています。住職は翔子さんの家族と親しく、昔のエピソードを話してくれました。翔子さんと住職の子どもが遊んでいた時、小さな喧嘩で子どもが泣いてしまったそうです。その時、翔子さんは「素直になーれ、素直になーれ」と言いながら、子どもの背中をさすって一緒に泣いたとのこと。翔子さんはプライドがなく、意味もわからないので、なぜ泣いているのか分からなかったそうです。結局、泣いても問題は解決できません。その場にいるみんなが悲しい気持ちになります。素直にお互いが「ごめんなさい」と謝ってまた一緒に遊べば絶対に楽しいってわかっているのに、それができないのは、プライドが邪魔をするからです。大人になるとより頑固になって、自分の非を認めず、謝ったり感謝することができなくなります。今の時代は、プライドが高くても、お金とコンビニがあれば一人で生きていけます。老後の準備も、子どもに頭を下げなくてもできる時代。でも、お寺に自身の供養の相談に来る人の多くは、家族とちゃんと話し合っていないそうです。住職は必ず「家族と相談してから来てください」と伝えるとのこと。どうせ子供は自分の世話なんてしてくれないだろうと思い込み、話もせず自分のプライドを守っていてはいけない。どんな相手にも頭を下げられる人に、プライドを捨てて素直になれる人になろう―そんなメッセージが心に残りました。写経体験この日は写経を体験しました。般若心経を筆ペンで書いていくのですが、補助線はあっても慣れない漢字ばかりです。そんな時、住職が「どれだけ上手く書こうとしても字は上手くなりません。むしろ考えれば考えるほど字は曲がり、綺麗に書けなくなってしまいます。写経は一回きり、今書けるものしか書けません。一文字一文字に集中して書いて、自身で納得してください」と言ってくれたおかげで、筆が進むようになりました。最終的に１時間ほどかかりましたが、集中して丁寧に書き切ることができました。初めてだったので腕が疲れましたが、自分なりに納得のいく出来栄えでした。不思議な坐禅体験坐禅中は、いろんな妄想や記憶が浮かんできます。そんな時は「数息観」という方法で心を落ち着かせます。長く呼吸を行い、数を数えて10まで行ったら、また1から数え直すのを繰り返すのです。繰り返しているうちに何を数えているのかよくわからなくなってくるらしいのですが、まだその境地には辿り着けていません。もう少し練習が必要そうです。この日の坐禅では、始まるとすぐに視界が揺れ始め、頭がクラクラしてきました。気持ち自体は悪くないのに、フラフラする不思議な感覚。しばらくしてその感覚は消え、視界は安定し始め、むしろいつもよりも集中できました。20分の坐禅があっという間に感じられたほどです。今でもあの感覚がなんだったのか、よくわかりません。自分の中にある魂がフッと外に飛び出そうとするような、変な感覚でした。振り返りプライドが高いと、知らないことを「知らない」と言えなかったり、自分や相手にも素直になれないものです。いつも反省することがたくさんあります。ただ、すぐには直せなくても、日々の小さな積み重ねで少しずつでも改善していくことができるものです。もっと素直な人になりたい―そう考えた一日でした。

禅と暮らす一週間。体験記 四日目 2024年秋

龍雲寺 涅槃堂#断食 #禅 #修行 #茶道はじめにお寺での一週間体験記の三日目をお届けします。まだ一日目（初日）、二日目の記事を読んでいない方は、そちらも併せてご覧ください。朝の様子前日はよく眠れたのですが、この日は悪夢を見てしまいました。滅多に夢を見ないか、記憶に残らない自分が悪夢を見ると言うのは、もしかしたらそれなりに疲れが溜まっていたのかもしれません。でも、前向きに考えるように心がけました。寝坊はせず午前6時前には起きることができ、新しい一日のスタートを切れました。この日から朝の日課として、部屋の掃き掃除を始めることにしました。火曜日からは朝のお勤めが6時半から始まります。気温が下がってきたので、作務衣ではなく暖かい私服で本堂に向かいました。読経では経本を目線まで上げて読む必要があり、腕が疲れてきましたが、最後まで読み通すことができました。法話では、和尚さんの率直なお話を聞くことができました。このお寺は中級レベルなので上座に案内されることが多いそうです。でも和尚さんは、それを当たり前だと思わないように気をつけているとのこと。ただ、そうはいっても人はすぐにその思いを忘れてしまいます。だからこそ、日々の生活の中で常に考え続けなければならないんだと話していました。また、立場上、厳しい顔をしなければいけない時もあるけれど、できるだけ口角を上げて、ニコニコ笑顔でいるように心がけているそうです。常に不平不満を言い、どんよりした顔の人の周りには人は集まらない。口角を上げていると、不思議と人が集まったり苦が苦で無くなる。「常に口角を上げる」こんな単純なことでと思うかもしれないけど、案外そういうことでどんな問題も解決ができるという話もありました。自分の顔を鏡で見た時に、笑顔で幸せそうな顔をしているか？と意識してみると良いことが増えるかもしれない。そんな簡単なことからでいいから始めてみようと思えるきっかけを与えてくれました。自由時間の過ごし方自由時間は読書をして過ごしました。前日の本を読み終えて、次は「禅とジブリ」を読み始めました。普段は本を読むのが苦手なのですが、ここではすらすら読めます。気になったところはメモを取りながら読みました。昨日の朝は天気が良かったので屋上で本を読んでいたのですが、寒くなり、外で読めなくなりました。鳥の声や様子を見ながら本が読むのがとても心地よかったので少し残念に思いました。前日一緒に水引をした人と話す機会があり、私の作品が評判だったと教えてもらいました。作業に集中していて周りをあまり見られなかったので、もっと他の人の作品も見ておけばよかったなと思いました。茶道体験この日の仏教体験は茶道でした。私は以前「お茶を飲むだけなのに、なぜこんなに手間をかけるのだろう」と思っていました。でも実際に体験してみると、禅語があったり、禅の考えに通じる教えが今も変わらずに受け継がれていることを知り、とても惹かれました。お茶を飲む側も、ただお茶を飲むだけではないことを学びました。一つ一つ違う茶器の形や色を楽しんだり、部屋に飾られた花や掛け軸を見たりして、自然のアンバランスさや手作りならではの不完全な部分に趣を感じます。そうやってゆっくりとお茶を味わい、会話を楽しむ。それが茶道の醍醐味なんだと分かりました。体験では、先生が野に咲いた花を一輪活けて床の間に飾り、一人一人に合わせて茶器を選んでくださいました。丁寧にお茶を点てていただく様子からは、お客への思いやりが伝わってきました。お茶碗を横から眺めたり、手に取って重さを確かめてみると、想像以上にごつごつして重みがあり、手触り感もよかったです。昨日はひたすら水引を作ることに集中しましたが、今回の体験では先生や参加者との交流ができたことが楽しかったです。午後の出来事午後、部屋の窓から景色を眺めていると青空の中に長い雲が一本伸びていました。まるで龍のように見えて、禅堂に来た自分に会いに来てくれたのかのように思えて嬉しい気持ちになりました。普段ならスマホばかり見ていて気づかなかったと思います。これからは空や周りの様子をもっと見るようにしたいと思いました。夕方の鐘つき寒くなったため、朝の鐘つきは中止になり、代わりに夕方5時から希望者が鐘をつけることになりました。茶道で一緒だった人と二人で参加しました。この鐘は地域の時報代わりになっていて、1kmくらい先まで聞こえるそうです。子どもたちもこの音を聞いて帰宅するなど、地域の生活になくてはならないものになっているとのことです。夕方は25回鐘をつくそうで、これは108の煩悩から25個を選んでいるそうです。二人で分けて12回（13回）ずつ鐘をつきました。鐘の音を聞いた子供達が暗くなる前に無事にお家に帰っているといいな、と心の中で思っていました。一日の終わりこの日も精進料理を食べて、坐禅を組んで一日が終わりました。坐禅が少しずつ心地よく感じられてきました。スマホから離れる生活のおかげか、必要以上に悩まなくなってきた気がします。振り返り修行期間も半分が過ぎ、少し慣れてきた頃です。慣れてくると作業的になりがちで、雑になったり、気持ちを見失ってしまうことがあります。そんな自分にならないように、初心を忘れずに一生懸命に目の前のことに取り組むぞと言う気持ちで明日も頑張ろうと思います。

禅と暮らす一週間。体験記 三日目 2024年秋

龍雲寺 涅槃堂#断食 #禅 #修行 #水引はじめに禅寺での一週間体験記、二日目の記録です。まだ一日目（初日）を読んでいない方は、そちらもぜひご覧ください。さまざまな体験と気づきがあった一日をお伝えしていきたいと思います。朝を迎えて初めての夜は、慣れない場所で何度か目が覚めました。完全に起きるわけではなく、うとうとしながらまた眠る、その繰り返しでした。朝5時30分、セットしていた置き時計のアラームの音で目が覚めました。初日から無事に起きられて、正直ホッとしました。アラームがちゃんと動作したことも確認できました。こんな小さなことでさえも日々スマホに頼っているせいで、無くなると不安になることに気付かされます。朝の準備を済ませて、月曜日だけ特別に組み込まれているノルディックウォーキングに参加しました。6時30分に玄関前に集合し、ポールを両手に持ってみんなで佐鳴湖の外周を歩きます。朝の気持ちいい空気の中でのウォーキングはとても気分がよく、散歩やジョギングをしている地元の人たちと挨拶を交わしながら、佐鳴湖の4分の1を30分かけて往復しました。普段はこんな早起きをすることはないのですが、清々しい朝の空気と心地よい運動で、早起きはいいなと感じました。朝のお勤め7時30分からの朝のお勤めのために、寺から借りた作務衣に着替えて道具を用意します。集合時間の5〜10分前には放送で案内があるので、持ち物を忘れる心配はありませんでした。やはりここでもスマホがない状況なので予定を確認する手段がありません。アナウンスが非常に助かります。本堂での読経では、生活信条から始まり、信心のことば、般若心経、消災咒、大悲咒、四弘誓願文を唱えます。当然ですが、それぞれのお経には意味があります。おそらくほとんどの人はまず意味を理解したいと考えると思います。しかし、初めての経験で意味も作法も分からない中、和尚さんから「恥ずかしがらずに大きな声で唱えなさい」と言われました。最初は戸惑いましたが、周りの人の声に合わせて唱えていくうちに、少しずつ慣れていきました。これは一体どういうことなのか？その理由は後の法話で分かりました。全ての人間は、赤ちゃんとしてこの世に誕生します。赤ちゃんは生まれた時、意味も分からずオギャーと泣き声を上げます。それは生きるための自然な表現です。でも大人になると、プライドや欲が邪魔をして素直に表現できなくなります。読経することは、オギャーと泣く赤ちゃんの声を聞いて感動したあの喜びを思い出すことです。恥ずかしいとか、くだらない欲は捨てて何も考えずにただ大きな声で唱えるだけでいいのです。この考え方は、とても新鮮で心に響きました。その後の坐禅は、朝ならではの静かな空気が心地よかったです。鳥の声が聞こえ、車の音も少なくて落ち着きました。和尚さんが持つ警策で背中を打ってもらうこともできます。打たれたい場合は、前を通る和尚に手を合わせる合図をします。ちなみに、坐禅では目を閉じず、正面のやや下の一点を見つめるようにします。ちょうど半目のようになるのですが、それが正しい坐禅の時の目となります。仏像の表情も、この坐禅の時の目の状態を表しているそうです。法話で学んだこと法話では先祖についてのお話がテーマでした。先祖というと、何をイメージするでしょうか？多くの人は両親や祖父母のことを思い出したのではないでしょうか。でも実際には祖父母にも両親がいて、これには例外がありません。700年前まで遡ると1人あたり、68億人もの人数になるそうです。その全ての人々の命が途切れることなくつながって、今の自分がいます。もしかしたら、見知らぬ人ともどこかでつながる先祖がいるかもしれません。目に見える近い先祖だけでなく、自分を生み出した全ての命に感謝することの大切さを学びました。この話を聞いて、自分の存在の尊さと、この先祖の命を背負ってこれからどう生きていくか、よく考えるきっかけになりました。午前の過ごし方朝のお勤めの後は自由時間でした。早朝から不慣れな生活リズムで運動もしたので少し疲れていて、温かいジャスミンティーを飲みながら読書をすることにしました。禅堂には仏教の本や小説、健康の本などがたくさんあります。私は「ブッダも笑う仏教の話」という本を読むことにしました。難しい仏教の話も、笑いを交えて分かりやすく書かれていて、とても読みやすかったです。11時からは初めて酸素カプセルを体験しました。入って横になるとすぐに眠くなるような心地よさでしたが、試しに酸素濃度を上げてみたところ、気圧の変化に慣れるのに時間がかかり頭が痛くなりました。後で酸素カプセルを体験した方とも話したのですが、誰しも頭痛が起こるわけではなく個人差があるようです。30分の体験であっという間に終わってしまったので、また機会があれば1時間くらい入ってみたいです。午後の活動お昼頃になると、自然と食事のことが頭をよぎります。まだそこまで空腹感があるわけではありませんでしたが、無意識に何を食べようかと考え始める、そんな気持ちです。とはいえ夕食まではまだ6時間以上あるので、お茶を飲んで我慢しながら、13時からの水引体験に参加しました。参加する時には水引の意味すらもわからない、そんな状態でした。水引はご祝儀袋の飾り紐のことです。今となっては既製品で済ませてしまうことばかりですが、昔は相手のことを考えながら手作りしていたそうです。1時間で平梅結びを練習しましたが、本当に難しくみんな苦労していました。それでも先生が丁寧に教えてくださるので、なんとか大切な人へ贈る作品を作れて良かったです。細かい作業に没頭することで、食事のことも、嫌なことも忘れられました。最初に作ったもの。だが、帰ってから通し方を間違えていたことに気づき、再度解いて作り直している。ただ一度作ると紐がよれて作りにくくなる。2回目に作ったもの。2色で2本・1本の構成だと綺麗だと気づき、同じ割合で色味をガラッと変えてみた。2回目だから上手くなっていた。15時からは懺悔供養の時間です。初日の振替として本日の入門者と一緒に行われることになりました。昨日書いた懺悔紙を焚き上げて、数珠をいただきました。この時間はあっという間で、考える暇もありませんでした。普段の生活では味わえない、特別な体験でした。ご本尊様を間近でみることができたのもこの時が初めてです。その後は、初日と同じように有料のトレーニング教室があり、食事、坐禅、おやすみストレッチと続いていきます。この日のトレーニングはインナーマッスル・背骨調整メニューでした。この日の夕食の時、生飯（さば）を取り忘れてしまいました。この小さな失敗で、空腹のせいで目の前のことに集中できていない自分、食事への感謝をすっかり忘れかけている自分に気づきました。日々の生活の中で、当たり前になっていることの大切さを改めて考え、反省しながら食事を取りました。二度と同じ過ちを犯さなないように気をつけようと思いました。ふりかえってこの日、入門者の中に若者がいるのを見かけて少しだけ嬉しかったです。一方で、年代の違う参加者との交流も印象に残りました。普段の生活では関わることのない方々と、水引体験を通じて会話を楽しむことができました。スマートフォンがない生活をすることで、今起きていることや、一緒にいる人たちとのつながりをより深く感じられました。「今この瞬間」を大切にすることの意味を、実際に体験して学んだ一日でした。

禅と暮らす一週間。体験記 二日目 2024年秋

龍雲寺 涅槃堂#断食 #禅 #修行はじめに準備編と概要編に続いて、一週間の体験記を書いていきます。浜松市の佐鳴湖畔にあるお寺で、どんなことを感じ、何を学んだのか。まずは初日のことから書き始めます。出発の朝から到着まで朝起きてからごはんを食べました。必要なものはそこまでないはずなのですが、「あれもこれも必要かな」と迷い結局リュックがパンパンに。一週間後に帰ってきた時のことを考えて、部屋の掃除と整理もしておきました。12時頃に家を出て、電車を2回乗り換えて浜松駅へ。昼食は摂らないように言われており、とはいえそこまで空腹感はなかったのですが、お腹は食べ物を期待するようにグーグー鳴っていました。駅からバスに乗って30分くらい。バスを降りた時、大きなリュック背負った人がいないか見回したけど、降りたのは私だけでした。マップを見ながら坂道を15分くらい歩いて、ようやくお寺に着きました。禅堂訪問者の入り口。本堂は向かって左の屋根のところにある。お寺についてから14時きっかりに到着。本堂の隣にある待合室で説明を待ちました。デジタルデトックスを希望してたので、注意書きが書かれた紙を受け取り、本当にやるかどうかの確認をされました。部屋の金庫にしまうことも可能なので不安な場合はそちらでもできると言われましたが、不意に取り出してしまいそうで怖かったから、完全に預けることに。そのあと「懺悔紙」という和紙をもらって、裏に懺悔したいことを書きました。自分の気持ちを振り返りながら書いてたら、溢れる想いに涙が出そうになりました。その後、本当は懺悔供養があるはずだったんですけど、住職が別のお寺で晋山式に出席しているとのことで翌日に延期になりました。最後に誓約書にサインして、持っていた2台のスマホを預けました。懺悔紙。三宝印が押されている。裏側には懺悔の文をびっしり書いている。禅堂この日は私含めて3人が入門でした。15分くらいの説明ビデオを見てから、宿泊施設の禅堂に案内されました。部屋に入った瞬間、シンプルで落ち着いた部屋を見て、少しホッとしました。窓からは佐鳴湖が一望でき、部屋の広がりを感じる素晴らしい景色でした。玄関を入ってすぐのところに洗面台があって、右側にユニットバスとトイレがあります。奥の7畳の和室には置き畳が敷いてあって、押し入れには布団一式、窓際に机と坐蒲（坐禅用の座布団）が置いてありました。ベランダ側は壁一面が窓になっていて、湖畔が一望できます。邪魔なものが一切なく透き通って見える景色は本当に圧巻で、スマホが無くて写真に撮れなかったのが今でも心残り。いつかこういう景色が見える場所に住みたいです。夕方からの暮らし部屋に入ってすぐトレーナーが来て、一週間の過ごし方や体調管理などの相談を行います。別料金でマッサージやパーソナルトレーニングなどもあり、予約を行うことができます。ファスティングを目的として来られる方も多いみたいです。今回は私が若い男性で坊主だからか、特に目的を話さなくても有料メニューは勧められず、個人的に入ってみたかった酸素カプセルだけを予約しました。その後、夕方に有料のトレーニング教室があります。本教室は予約制ではなく、自由に参加することができます。初日はハタヨガでした。台北に住んでいた頃に何度かハタヨガレッスンに行ったことがあったので、なんとか付いていけました。体が硬いのでポーズがうまく取れないのですが、45分くらい身体を動かしたら、気持ちよく汗が出ました。夜ご飯は18時15分から。みんなで「一つには功の多少を計り…」と食事五観の偈（げ）を読んで、禅寺らしい作法で食べました。黙食で会話禁止のため、お盆に乗った精進料理を静かにいただきました。特におかずのおからが絶品で、今でも味が忘れられません。精進料理、作ってみたいなぁ…。19:30からは坐禅の時間です。初めてで本当に難しかったです。姿勢を正して20分間、「何も考えない」はずが、昔のこと、今日のこと、明日のこととか、仕事のこととか、次から次へと妄想が湧いてきてしまいます。外の車の音も気になるし、気付けば呼吸も浅くなります。終わった時は足が完全にしびれて、ふらふらでした。ただ、何も考えない時間を過ごすことがこんなにも難しいとは。坐禅が終わると、おやすみストレッチを行い、禅堂に戻ってシャワーを浴びて就寝です。一日を振り返って初日は「作務衣（さむい）」とか「絡子（らくす）」とか「坐蒲（ざふ）」とか、初めて聞くし読み方もわからない言葉だらけでした。いつもならスマホでササッと調べられるのに、それもできなくて焦りまくり。時間割も持ち物も記憶を必死に探りながら手書きでメモしていました。スタッフは優しかったけど、「基本は冊子を読んで自分で理解してください」という形で時間になると淡々と予定が進んでいきます。最初は知らない人ばかりだったし心細くて不安だったけど、これも修行の一つなんだなって。自分はホテルに宿泊に来た「お客様」じゃなくて、自分の意志でお寺に来た修行者として過ごさないといけないなと身が引き締まりました。夜寝る時、布団を敷きながら「明日はちゃんと起きて集団行動ができるだろうか」と不安になりました。でも、なるようになるしかないと思います。翌日は朝6時には起きないといけないので、いつもより何時間も早い22時前に就寝。不慣れなマットレスと環境で、なかなか寝付けませんでした。続編はこちら > 禅と暮らす一週間。体験記 二日目 2024年秋

禅と暮らす一週間。体験記 初日 2024年秋

龍雲寺 涅槃堂#断食 #禅 #修行はじめに先日、私はお寺に行って一日一食断食と仏教体験を行いました。前回は準備編として体験に行くまでをまとめましたが、今回は修行概要編と題して、実際に何をしてきたのか、具体的な内容についてご紹介しようと思います。龍雲寺 禅堂の概要前回も紹介した通り、今回体験させていただいたのは静岡県浜松市にある龍雲寺です。佐鳴湖のほとりに位置する龍雲寺は、鳥や虫の声が響く自然豊かな場所です。9千坪の敷地内には、庭園や本堂、涅槃堂（ねはんどう）、墓地、禅堂などが点在しています。参加者は禅堂に宿泊することになります。特に厳しい参加条件はありませんが、禅堂が崖の上にあることから、石階段の上り下りが頻繁にあります。足腰の弱い方は少し気をつける必要があるかもしれません。また冬場は室内以外かなり寒くなるので、しっかりとした防寒対策をお勧めします。寺内の随所には、ダウン症の書家・金澤翔子さんの書が飾られています。特に印象的なのが、涅槃堂の壁一面に描かれた般若心経で、世界一大きいものだそうです。本堂や涅槃堂の書は一般の方でも見学可能です。また、禅堂の廊下や各部屋にもさまざまな書が飾られています。私の部屋には「好日」という言葉の書が掛けられていました。"日日是好日" という素敵な禅語を思い出させてくれます。もしまた機会があって泊まることがあれば、別の部屋にはどのようなメッセージが飾られているのか見てみたいです。申し込みはウェブで受け付けていますが、一ヶ月を切ると予約が取りにくくなるので、早めの予約をお勧めします。私の場合、申し込みから2日後には入門書が届き、その速さに驚きました。入門書は入門日が訪れる日までに目を通しておきます。費用については6泊7日で約11万円かかりましたが、実際に体験してみるとその価値は十分にあると感じました。主な生活スケジュールここでの生活を通じて行うことは、一言で言えば「心と呼吸と身体を整える」ことです。世俗を離れ、豊かな自然の中で自分と向き合いながら過ごす一週間。そのために用意されたプログラムをこなしていきます。私が過ごした基本的なスケジュールは以下の通りです。table:一日のタイムスケジュール 06:00	起床 06:30〜07:00	朝のお経 07:00〜07:20	坐禅 07:20〜	梅湯茶礼・住職法話 08:30〜09:00	朝のストレッチ 09:00〜13:00	自由時間 13:00〜14:00	仏教体験 14:00〜17:15	自由時間 16:00〜	住職へのお悩み相談 17:00〜17:10	夕方の鐘つき 17:15〜18:00	夕方の運動教室（有料） 18:15〜	夕食（精進料理） 19:30〜19:50	坐禅 20:00〜20:30	リラックスストレッチ 21:00〜	就寝日中のプログラムは基本的に自由参加で、何も参加しない場合は8時30分から夕食前まで自由時間となります。早朝は少し忙しいのですが、日中はゆったりとした時間が流れます。私はデジタルデトックスも兼ねて電子機器を持ち込まなかったこともあり、ほぼ全てのプログラムに参加することにしました。坐禅お寺で断食道場と言ったら坐禅をして棒で叩かれる、というイメージをお持ちの方も多いのではないでしょうか。タイトルにも "禅と暮らす" とある通り、坐禅の時間があります。ただし、少しでも動いたらすぐに棒で叩かれるというような厳しい坐禅ではありません。ここでは、朝と夜の2回、それぞれ20分間の坐禅を行います。場所は涅槃堂か、滝の見える庭の前（渡り廊下）です。涅槃堂は空調が効いており、静かな場所なので冬には最適です。一方、音がある方が集中できる方は滝の見える庭の前で坐禅を組むのが良いでしょう。好みの問題ですが、朝の座禅では鳥の囀りも聞こえて心地よく座れることが多い気がしました。また、朝は警策もあります。身体や心が落ち着かない時は背中を棒で叩いてもらえます。自己申告制です。必ずしも叩かれることが良いわけではなく、心がリラックスして気持ちよく座れているのであれば叩かれない方が良いそうです。食事食事は全て精進料理です。天皇陛下が浜名湖花博の時お越しの際に料理番を務めた料理人が精進料理を作っており、野菜は全て地元浜松産のものを使用しているそうです。一日一食のため、慣れないうちはすぐに空腹が襲いかかってきます。そのため、空腹を紛らわすための炭酸水が提供されています。そのほか、カフェインを除いたお茶（緑茶・ジャスミン茶・ほうじ茶）も飲むことができます。本来の断食ではカフェインも断つ必要がありますが、コーヒーによるカフェイン中毒で頭痛がする方のために特別にコーヒーも置いてあります。部屋にタンブラーが置いてあるので、それを自由に利用することができます。運動・ストレッチ運動やストレッチの時間が適度に用意されています。有料・無料含めて基本的には全て自由参加です。朝と夜のトレーニングでは体を伸ばしたり呼吸を整える種目が多く、夕方の運動教室は曜日ごとにヨガ・ピラティス・ストレッチ・顔トレなどテーマ別に先生が入れ替わりで担当してくださいます。身体を動かすメニューが多くあるのは、実際生活してみるとわかるのですが、普段の姿勢の悪さや身体の硬さから坐禅の時に足が組めないとか、身体が動いてしまい落ち着かないという問題を抱える人が多いため、自分の身体も合わせて調整をできるようにと考えられているそうです。自由時間自由時間は基本的に何をしても良い時間です。禅堂の屋上は人工芝が引いてあり、椅子やヨガマットが用意されているのでそこで寝そべったり景色を眺めてもよし、佐鳴湖を散歩してもよし、自転車をレンタルしてあちこちへ行ってもよし。もちろん、部屋で本を読んだり、坐禅をしたり、境内を散策しても良いです。また、パーソナルトレーニングやマッサージ・酸素カプセル等の専用メニューも予約することができます。仏教体験通常であればお昼ご飯を食べるか食べ終わっている頃の時間帯の13時からは仏教体験があります。禅堂の広間にカレンダーが置いてあり、日毎の体験内容が掲載されています。具体的な数は忘れてしまいましたが、少なくとも7種類以上あるので、6泊7日の宿泊をして全ての仏教体験に参加したとしても全種類の体験ができるわけではありません。正直、全て体験してみたいです。私が体験したもので言えば、水引作りや枯山水線引き体験、木魚体験等です。詳細については別途感想や内容について書いてみようと思います。鐘つき体験公式の一日スケジュールでは朝のお勤めで鐘つきがありますが、冬は寒いのでやらないようです。そして、ちょうど私が入門した日から朝晩が冷え込む季節となり無くなりました。それとは別に、夕方の17時に地域の住民に時間を知らせるための鐘つきの時間があります。任意参加となりますが、集まったメンバーで計25回の鐘をつきます。私は2回参加しましたが、2回とも自分を含め2名の参加だったので、前半と後半で割と贅沢に鐘をつかせていただけました。参加しなかった時は、禅堂の自室から鐘の音が聞こえてきたりしてエモい気持ちになりました。全体を通してというわけで、今回はざっくりと全体のスケジュールと内容についてまとめてみました。このように、龍雲寺での体験は実に多岐にわたります。どれもこの場所でしか味わえない貴重な経験ばかりでした。ただし、これらの体験で得たものを一時的なものとして終わらせるのは勿体無いなと感じています。今後の生活の中で得ることができた気づきを日常生活に活かし、自分や周りの人たちの生活がより素晴らしいものになるように考えていきたいです。また、さらなる詳細を知りたい方に向けて禅堂での日々の暮らしについてまとめていきたいと思うので、次の記事をお楽しみに。続編はこちら > 禅と暮らす一週間。体験記 初日 2024年秋

禅と暮らす一週間。一日一食断食と仏教体験レポート 修行概要編 2024年秋

龍雲寺 涅槃堂#アドベントカレンダー #断食 #禅この記事は、モニクル Advent Calendar 2024 の3日目の記事です。昨日は、/wadata/nkzn.iconNkznの 開発合宿と技術同人誌即売会への企業出展にシナジーを見出した話でした。今回は @sugoi_wada が担当します。はじめに先日、私は個人的に一日一食断食と仏教体験を行いました。今回は準備編として体験に行くまでをまとめました。龍雲寺・禅堂に行ってきました静岡県浜松市にある龍雲寺（りょううんじ）を訪れました。このお寺には断食道場があり、禅堂に宿泊することができます。断食道場と聞くと、数日間一切食べ物を口にしない厳しいイメージがありますが、龍雲寺では一日一食の食事が可能です。身体に過度な負担をかけない形での断食は、初めての方でも参加しやすい特徴があります。最大で一週間の長期滞在ができる点も魅力的です。一週間のデジタルデトックス今回、私は一週間の滞在を予約し、デジタルデトックスも行うことにしました。これはオプションのプログラムで、入門から最終日の退出までスマートフォンなどの電子機器を寺に預けることができます。不測の事態がない限り、途中で取り出すことはできず、自分で部屋の金庫に入れるよりもさらに厳格な措置となります。龍雲寺ではテレワークも可能で、フルリモートで働く人は仕事をしながら滞在できます。そんな中、ソフトウェアエンジニアである私がデジタルデトックスを選んだ理由を率直に語りたいと思います。デジタルデトックスを行うきっかけ生活を振り返ると、常にスマートフォンを手放さず、暇さえあれば画面を眺める日々でした。フルリモートのため、同僚に直接会える機会はほぼなく、基本的に一人で仕事をしています。外出先でも自宅でも、リアルな人間より画面越しの人とのコミュニケーションが中心でした。常に誰かと連絡をとり続けている、そんな状況でした。また、料理、家事、掃除など、あらゆる作業中も音楽、テレビ、ニュース、スマートフォンの動画と常に何かを同時に行い、集中できない状態が続いていました。良くないと分かっていても、つい無意識のうちに手に取ってしまうスマートフォン。このデジタルデバイス依存の生活から一度離れてみたいと強く思うようになりました。自分の意思だけで行うのは難しいため、今回の体験を良い機会と捉えてやってみようと決意を固めました。当然ですが、デジタルデトックス中は仕事の連絡も取れなくなります。エンジニアリングマネージャーである私が一週間も休暇を取り、連絡が取れなくなることに不安もありましたが、CTOに相談したところ快く承諾を得られました。日程に関してはプロダクトの大きなリリースがないタイミングに合わせるようにしました。修行のための準備この貴重な一週間を有意義なものにするため、仏教に関する知識を深めることから始めました。最初に読んだ本は「反応しない練習」です。もともと抱えていた悩みに対して、仏教の教えを通じて解決の糸口を見出せる本だと知り、まさに私に必要な本だと感じて熟読しました。今でも、この本に出会えたことを感謝しています。興味があれば是非読んでみてください。他にも何冊かの本を読み、禅や仏教への理解を深めました。本に記載された瞑想法をいくつか実践してみると、少しずつ心が落ち着いていくのを感じました。仏教は「実践する宗教」とも呼ばれているため、知識を学ぶだけでなく、短時間でもいいから日常に取り入れることが大切だということを理解しました。この時点ではまだ入門していませんが、すでに心の中では始まっているかのような感覚でした。入門一週間前、自分にとって大きな決断をしました。理髪店に行って髪を剃り、人生初の坊主頭にしたのです。最初は躊躇していましたが、この体験を通じて自分に変化を与えたい、見た目へのこだわりや虚栄心、プライドを手放したいという思いが強くありました。数日悩み、最終的には「髪の毛はまた生えてくるし、やってみよう。」と決意を固め、覚悟を決めました。学生以来足を運んだことのない理髪店に行き「3mmの坊主でお願いします。」とお願いしました。短くないパーマスタイルだった自分がいきなり坊主にすることに対して担当のスタッフが心配してくださいました。坊主頭にしたことで、休暇までに残されたほぼすべてのミーティングで「その頭どうしたの（笑）」と話題となり、次週のミーティングに出られないことを説明しやすくなりました。仕事からしばらく離れるための準備デジタルデトックスの許可を得たはいいものの、一週間もの間、仕事の連絡を受け取れない状況には不安がありました。会社やチームメンバーが仕事を順調に進めていけるように、いくつかの準備を行いました。まず、関係各所へ事前連絡を行いました。家族はもちろん、会社のメンバーや管理部にも滞在期間、場所、連絡先を伝え、基本的に電話の発信・受信ができないことを説明しました。入門前の最終出勤日には、業務関連のメッセージをまとめてチームメンバーに伝えました。担当ミーティングのファシリテーションや進行上の観点を改めて整理し、各スクラムイベントの目的を文章化しておきました。曜日ごとにどんなことをすればいいかも想像して方向性をまとめておきました。最後に、メンバーには内緒で Slack に予約投稿を仕込みました。一週間、毎朝のデイリースクラム時に自動投稿されるよう調整し、挨拶と業務メッセージを用意しました。内容は概ね既に共有済みのものと重複していましたが、この通知でチームメンバーが温かい気持ちになったと後から聞きました。地味な作業でしたが、一つ一つ丁寧にメッセージを作成し、時空を超えて想いを伝えることができました。いざ、入門へこれで準備が整い、入門に向けて出発する段階まで来ました。しかし、このまま書き続けると記事が膨大になってしまうため、今回はここで一旦締めくくりたいと思います。次回は、実際の禅堂での暮らしや気づきについてレポートします。どうぞご期待ください。続編はこちら > 禅と暮らす一週間。一日一食断食と仏教体験レポート 修行概要編 2024年秋おまけ一週間後、寺を出てからすぐに関係各所に復帰の連絡を済ませ、浜松を観光しました。週末だったため、すぐに仕事のメッセージを確認することは避けましたが、最終的に1000件近くの未読メッセージがあり震えました。翌出勤日は、誰もいない早朝に出勤し、ゆっくりと目を通しました。ミーティングや作業をしながらではありましたが、全てのメッセージを読み終えるのに三日ほどかかりました。

禅と暮らす一週間。一日一食断食と仏教体験レポート 準備編 2024年秋

徳川園#Rails #eager_loading #autoloading #zeitwerkいきなり注意今回言及しているeager loadingは、ActiveRecordのModel.eager_load(:model)とは全く異なる内容なので気をつけてください。はじめにRails 7.2へのアップグレード時にbin/rails app:updateを実行し、サーバを立ち上げたところZeitwerk::NameErrorが発生しました。これをきっかけに、この問題について調査を始めました。問題の詳細エラーの内容は、lib/配下の一部のファイル名とモジュール名（またはクラス名）が一致していないというものでした。Zeitwerkは、Rails 6.0以降に組み込まれた、アプリケーションで定義されたクラスやモジュールを自動で読み込む仕組みです。Zeitwerkを使用する場合、ファイル構造がRubyのクラス名とモジュールに一致する必要があります。Zeitwerkのドキュメント今回のエラーは、これまで自動読み込みの対象ではなかったlib配下のファイルが、自動読み込みの対象となったことが原因でした。自動読み込みの種類Zeitwerkの自動読み込みには二種類あります： 1. autoloading: クラスやモジュールを利用する時に、動的に対象のファイルを読み込む機能。 2. eager loading: アプリケーション起動時に、事前に各ファイルを走査し、クラスやモジュールを読み込む機能。本番環境ではアプリケーション起動後のパフォーマンスを向上させるためになるべくeager loadingを行うことが推奨されますが、開発環境ではファイルの変更を頻繁に行うため、通常オフにすることが推奨されています。Railsアップデート時の変更内容アップデート時にconfig/application.rbに以下の設定が追加されました：code: (ruby) config.autoload_lib(ignore: %wassets hoge fuga piyo)この設定はlibディレクトリを自動読み込みのパスに含める場合に使用します。autoload_libというメソッド名ですが、eager loadingも有効になります。最終的な対応lib配下をeager loading対象から外すため、この設定を削除しました。余談: autoloadingだけしたい場合eager loadingを避けつつautoloadingだけ行いたい場合は、以下のように設定します：code: (ruby) config.autoload_paths += %Wlib/hoge lib/fuga lib/piyo参考詳細はRailsガイドを参照してください※ eager loadingに関しては日本語訳がないのかな…

今更Railsのautoloadingとeager loadingを理解する

くるくまカフェ#RailsはじめにRails で悲観的ロック（排他制御）を行った際に、それを Minitest のテストコードで確かめる機会があったので、簡単に紹介します。Rails で複数のリクエストが同時に処理される場合、データ競合が発生する可能性があります。悲観的ロックは、同時に1つのレコードに対して2つの更新リクエストが来た場合に、1つ目の処理が終わってから2つ目の処理が開始するようにして、競合を避けるようにする排他制御メカニズムです。Railsでは ModelName.with_lock do end などを用いて処理対象となるレコードをロックすることが可能です。きっかけは、とあるリクエストがエラーを吐いたことでした。そのリクエストでは、いくつかのモデルを作成するのですが、複合ユニーク制約が貼られています。エラーの内容を見てみると、ユニーク制約に違反するDBのデータ挿入エラーでした。原因を調査したところ、同一のエンドポイントに対して同一のリクエストが複数回連続で発生した場合に、後続のリクエストが失敗するという内容でした。その後の調べで、トランザクションは貼っていたものの、悲観的ロックがされておらず、ボタンにも連打対策がなされていなかったことが原因でした。テストを書くテストコードを書いてエラーが起こることを再現して、悲観的ロックをかけた上でテストがパスしたことを確認してみたいと思います。例えば以下のように Parallel gem を使うと簡単に非同期で複数回の処理を呼び出すことができます。code:parallel_test.rb require 'parallel'  test test_pesimistic_lock do   Parallel.each(1, 2, in_threads: 2) do     # 処理を実行するコードを書く   end endこのコードは、Parallel gem を使って、1 と 2 を要素とする配列の要素に対して、それぞれ別スレッドで処理を実行します（1と2そのものに意味はありません）。しかし、実際にこれでテストを回してみても、ブロック内部の処理のトランザクションが並列に実行されません。Minitestは各テスト実行時にトランザクションを張り、テストの終了時にロールバックを行うようになっており、これがテストが意図通りに動かない原因となっています。そこで、テストクラスに下記のコードを追加します。対象のテストクラス内で張られるトランザクションを無効にします。code:disable_transaction self.use_transactional_tests = falseその後、テストを実行します。この時、トランザクションを無効にしたテストは実行後、データベースが初期化されない（ロールバックされない）ため、DBのレコードを空にする必要があります。まとめてコマンド実行すると良いでしょう。code:run test rails db:migrate:reset RAILS_ENV=test & rails t path/to/test_file.rb:{テストメソッドの行番号}もし書いたテストコードを永続的に残しておきたい場合は、テストクラスを分けた上で、テストコードのセットアップでデータを空にする処理を書いておくと良いでしょう。参考 https://tech.hitomedia.jp/entry/2018/03/16/120249 https://zenn.dev/shuhei_takada/books/3ff66325f45adc/viewer/2bf43c#%E6%82%B2%E8%A6%B3%E7%9A%84%E3%83%AD%E3%83%83%E3%82%AF%E3%81%A8%E3%81%AF

Rails で Minitest を使って悲観的ロック（排他制御）をテストする方法

湯の山温泉 グリーンホテル#フルリモート #スクラム #モブプロ #モニクルはじめに2020年4月にモニクルに入社してから4年が経過しました。今回は、フルリモート環境、モブプロ、スクラムの3つの観点から、これまでの経験を振り返ります。フルリモート入社当初はコロナ禍の影響でフルリモートでの勤務が始まりました。当初はアフターコロナの時期が訪れたらある程度出社することも検討していました（とはいえ、たまに会いたいねくらいの温度感でした）が、半年後にはメンバーが各地域に散り散りになりました。かくゆう私は一番最初に東京から飛び出したメンバーの一人でした。当時の行動は勇足だったかもしれませんが、一ヶ月後にはCTOの塚田さんも北海道へ引っ越したことを考えると、おそらくあのタイミングで会社としてフルリモートでやっていくぞという覚悟が生まれた気もするので良かったのかなと思います。モニクルのフルリモート環境が成功している要因としては、経営陣のフルリモートに対する理解やプロダクトの迅速な改善やデリバリーを行い成果を示し続けていることもありますが、一番良いのは全員が毎日ビデオ通話アプリを立ち上げて顔が見える状態を基本としていることだと思います。常に顔を確認しているわけではありませんが、相手の表情ひとつで情報を読み取ることができたり、相手がそこにいる安心感があります。また、Gatherを使っていつでも誰でも同期的にやり取りができる状態を作っています。オンラインでも、雑談を含めたコミュニケーションが活発に行えるのはこのような文化があるからだと思います。今後はメンバーが増えていく中で、ある程度チームを横断して交流を深めたり、チーム間の良いところを共有して高めていく作業も必要になってくると思います。モニクルでは留学制度を導入したり、スクラムマスター同士の交流を経てその壁を乗り越えるための試みをしているところです。この辺りの試みについてはまた別の機会に。モブプロモブプロは、新メンバーがチームの一員としてすぐに活躍できるように、密度の高いコミュニケーションを促進します。リアルタイムで議論を行いながらコーディングを行うことで、すぐにドメイン知識を理解し、チームに溶け込むことができます。モブプロによるオンボーディングと最初の作業のことを「知の高速道路」と呼んでいます。入社当時はAndroidネイティブアプリ開発を得意とするソフトウェアエンジニアだった私ですが、モニクルではRailsやReactをベースとしたWeb開発が中心でした。不安を抱えていましたが、短期間でモブプロを通じて必要な知識を習得することができました。ドメイン知識についても同様です。今振り返ると、温かくサポートをしてくれた当時のチームメンバーには本当に感謝しています。現在も、新メンバーはモブプロから開発をスタートしています。しかし、モブプロ一辺倒で開発を進めるわけではなく、常にモブプロへの考え方に対するディスカッションを行いながら、柔軟に動いてより良い開発ができるよう努めています。スクラムを頑張った入社当初は、右も左もわからない状態の中で、とりあえずJiraやスクラムという開発スタイルを導入しました。当時は開発に必死で、正解もわからず、十分に機能させることはできていませんでした。それなりに開発は進むものの、初期の開発スタイルはCTOの塚田さんがリーダーシップを発揮して前に進めてくださったことが大きかったです。日々エンジニアとして仕事をする中で、次第にチームビルディングへの興味が湧いてきました。自分の力だけで生産性を50から100にするよりも、チームメンバー全員の生産性を引き上げることができれば、トータルとしてより大きな成果を生み出すことができると考えたのです。そこで、スクラムマスター研修に参加することにしました。研修を通して、スクラムの本質や、より効果的な運用方法について学ぶことができました。この時すでに入社初期と比べて組織も大きくなっていましたが、チームメンバーの安定化と複雑化を防ぐための仕組み作りが進められていき、取り組みやすい環境でした。現在、スクラムマスターとして以下の点に意識して取り組んでいます。 スプリントゴール達成へのサポート  チームメンバーが力を発揮し、スプリントゴールを達成できるよう、最大限のサポートを行います。 スクラム学習のための機会の創出  チーム全体でスクラムの考え方や手法を学び、より効果的に活用できるよう、読書会を開催しています。今は必ずしもスクラムに拘った選書をしているわけではありませんが、それ以外でも定期的に話し合うようにしています。 メンバーとの交流  各メンバーと1 on 1をしたり必要に応じてイベントを見直し、チーム内で改善が進むように小さな変更を取り入れながらふりかえりを進めています。まだまだ難しいなと思うことがたくさんありますが、今後も改善を進めていきたいです。終わりに最近、最近入社されたチームメンバーと話をする中で気づいたことがありました。それはモニクルにとって当たり前のことは、前職では当たり前ではなかった、ということです。思えば私自身も前職では当たり前でなかったことが山のようにあります。4年も経つと流石に慣れてしまい、忘れてしまった思いが、他のメンバーから思い起こされることがありました。4年間のふりかえりでは、そのような当たり前が他の会社やチームでは当たり前ではないかもしれないということを念頭におきながら、ぎゅっと凝縮して紹介させていただきました。今後も引き続き小さな改善を繰り返して組織にとって良い文化を作り上げていきたいと思います。ちなみに、このエントリは三重県の湯の山温泉グリーンホテルにて書いています。露天風呂が広く、とても気持ちよかったです。名湯百選にも選ばれています。では、また。

モニクルにジョインして4年が経ちました

大稻埕#台湾 #ワーケーション #モニクルはじめに弊社モニクルでは、全員が各地各国に居住し、フルリモートワークで働いています。（※内容は少し古いです）私自身は元々2020年10月より台湾の台北に居住していました。しかし、3年が経過したところで新たなライフスタイルを求め、日本へ帰国しました。3年ぶりに日本で生活を開始し、わずか3カ月ではありますが、再び台湾へ行ってみることにしました。とはいえ、今回の渡航は前回のように居住するわけではなく、わずか11日間の滞在です。モニクルではワーケーションをすることができます。特に補助がある訳ではありませんが、会社やメンバーに迷惑をかけしないよう事前に報告し、計画を立てれば問題ありません。休暇を取得することも可能でしたが、中国語を話せる私にとって、せっかくの機会なので台湾でのワーケーションに挑戦してみることにしました。どこで過ごすか島国である台湾とはいえ、台北と高雄の間には東京と名古屋間の距離ほどの距離があります。当然のことながら、事前に旅程を立てておく必要があります。私自身はすでに台北での居住経験がありますので、今回はなるべく台北以外の場所で時間を過ごしたいと考えていました。2023年に台湾鉄道で台湾一周を経験した時の記憶を思い返しましたが、台湾東部は都市規模が小さく、移動も便利とは言えません。また、せっかくの機会なので知り合いがいる地域を巡りたいと思い、今回は高雄から台北へ北上することにしました。コワーキングスペースをどう確保するかワーケーションをするには、作業場所の確保が不可欠です。また、宿泊先とコワーキングスペースの距離感（通勤時間）も意識しなければなりません。まずは、コワーキングスペースについて調べました。今回のコワーキングスペース選定地は、高雄、台南、台中、台北の4都市に絞りました。Google検索で「台南 工作空間」などのキーワードを入力すると、コワーキングスペースや比較記事などがヒットするので、それぞれ見ていきます。各都市ごとに時間・料金・場所を比較検討しました。日本と同様に、台湾にも数多くのコワーキングスペースが存在しますが、場所や料金は様々です。ドロップイン利用が不可な場所や、料金体系が不明瞭な場所も存在します。そのような場合は、Facebook MessengerやLINEで直接問い合わせると、詳細な情報を教えてくれる場合が多いです。当初は一つ一つ丁寧にメモを取ることも検討しましたが、早々に条件に合致するコワーキングスペースを発見しました。それがHour Jungleです。Hour Jungleの詳細については、別の記事で詳しくまとめる予定です。台南、台中、台北の主要都市に拠点を構えながら、低価格で快適な作業環境を提供している点が魅力です。各拠点には愛らしい猫が飼育されており、癒されること間違いなしです。スケジュールスケジュール（実績）は以下の通りです。 03月01日（金）  有給休暇を使い、飛行機で桃園国際空港へ  空港から台中へバスで移動  台中市内のホステルに宿泊 03月02日（土）  台中から高雄へバスで移動  高雄市内のホステルに宿泊 03月03日（日）  高雄から台南へ台鉄で移動  台南市内のホステルに宿泊 03月04日（月）  連泊のため、作業用の荷物だけを持って移動  HOUR JUNGLE TAINAN 台南中山館で作業 03月05日（火）  チェックアウトのため、すべての荷物を持って移動  HOUR JUNGLE TAINAN 台南中山館で作業  作業後、台中へ移動しホテルに宿泊    03月06日（水）、03月07日（木）  連泊、かつ独立した部屋を確保したため、自室で作業   WiFiは部屋ごとに用意されていて快適。しかし椅子が固かった 03月08日（金）  チェックアウトのため、すべての荷物を持って移動  ​HOUR JUNGLE TAICHUNG 台中館で作業  作業後、台北へ移動しホステルに宿泊 03月09日（土）  連泊 03月10日（日）  台北市内の別のホステルに宿泊 03月11日（月）  チェックアウトのため、すべての荷物を持って移動  HOUR JUNGLE TAIPEI 台北信義安和館で作業 03月12日（火）  深夜便で日本へ帰国私はいつも旅行の計画を立てるときにWanderlogを使ってまとめています。候補地や移動手段などを金額・URL・メモを残しながらまとめることができて非常に便利です。是非使ってみてください。まとめワーケーションにおいては、作業場所をよく検討する必要があります。ホテルの個室で連泊する場合、ホテルでの作業も可能ですが、場所によっては料金が高かったり、作業環境が整っていない場合もあります。いずれの場合も、代替案としてコワーキングスペースを調査しておくと良いでしょう。また、予期せぬ事態が発生する場合もあります。私の場合は中国語を話すことができ、Hour Jungleにも事前にLINEで連絡していたため問題なく利用できると考えていました。しかし、台中舘においては到着時にスタッフが不在だったため、手続きができず、朝の会議に間に合わないという事態が発生しました。このような想定外の事態が発生する可能性を常に念頭に置いておき、代替案や対応策を検討しておく必要があります。今回私が利用した各店舗とホテルの中には、快適にご利用いただける場所もあれば、そうでない場所もありました。経験を積み重ねることで、徐々に安定したワーケーション環境を構築できると考えています。今後も快適なワーケーション環境を追求していきます。

2024年03月の台湾ワーケーション 記録

ライムリゾート箱根#ライムリゾート箱根はじめに先日、ライムリゾート箱根で認定スクラムマスター研修に参加してきました。研修で感じたことは先日書いた記事をご覧ください。今回は簡単にライムリゾート箱根の様子をシェアします。なお、会議室など一部の設備は未使用です。行き方ライムリゾート箱根に行くためには、小田原駅から箱根登山バスで約40分かけて南仙石原駅まで行きます。その他の手段として、自転車や車で山道、峠道を駆け抜けるという方法があります。私の場合は名古屋駅から新幹線ひかりで小田原駅まで向かい、バスで行きました。ちなみに、施設周辺には何もないので注意してください。コンビニはGoogleマップで徒歩10分のところにありますが山道で車通りも多いのでそこそこ危険です（車があれば問題ないでしょう）。外観ライムリゾート箱根の外観。スロープを抜けて入り口に入ることができます。施設の形は丸みがかった大きな三角形をイメージするとわかりやすいです。建物の中央部は抜けていて、中庭になっています。通常館内を歩く時は三角形の辺伝いに歩きます。1階・研修兼ダイニングフロア玄関を抜けると大きなフロアがあります。奥の長いテーブルはダイニングとして食事をとるときに使用します。さらに奥には研修用のスペースとバーカウンター。手前には暖炉があります。ダイニングから暖炉と玄関を写すとこんな感じ。玄関のすぐそばまでデスクや椅子があります。ちなみに暖炉は実際に薪を焚べて火をつけることができます。冬の箱根はとても寒いので、ここで温まりながらメラメラと動く炎を見るとアガります。研修用スペースです。すり鉢状になっていて、講師が一番下に降りて話をします。ここの長椅子がかなり座りにくく腰が痛くなります。食事食事はビュッフェスタイル。テーブルに並べられた食事を自分で好きなように取ります。ご飯の上に自分で自由に刺身をおける勝手丼が個人的に一番美味しかったです。甘エビ大好きなんですよね…！！お酒のバックログです。BLUE MOONというホワイトエールビールが美味しかったなぁ…。ダントツで減ってますねwこちらはワイン・日本酒です。コインを入れてボタンを押すと蛇口を捻ったかの如く、水ではなくお酒が出てきます。研修では夕食の時間帯に飲み放題になっていました。ちなみに、箱根街道という日本酒がありますが、名前は箱根でも箱根で醸造された日本酒ではないということを後から知りました。隣町の足柄上郡大井町にある、石井醸造さんのお酒です。でも美味しかったです。やや辛口って書いてある通り、ほんのり辛口なので飲みやすい日本酒かと思います。部屋宿泊施設を兼ねているこの施設では、1階と2階に宿泊用の部屋があります。扉は大きいですが、引き戸でオートロックのような設備は備わっていません。この施設では不要でしょう。部屋の手前に洗面・トイレ・休憩スペースがあります。靴を脱いで上がると座敷があります。独特なレイアウトで布団（マットレス）が敷いてあり、4人まで泊まることができそうです。他の部屋は確認できていないため、同じレイアウトなのかどうかはわかりません。研修ではこの部屋を独り占めできたので、中央の机でまとめを書いたりしていました。押し入れのようなベッドルームはやや圧迫感があるため、背の高い方や慣れていない方は落ち着かないかもしれません。私はドミトリーなどに慣れており、逆にめっちゃ落ち着けましたwちなみに、館内着が上下分かれていてとても着心地が良かったです。見た目もいい感じです。CISCOルータが配備されていました。スピードは特に不便を感じない速度で快適でした。スピードテストをするのを忘れました。温泉1階に温泉があります。脱衣所に行くのに中庭を通る必要があるのですが、1月の箱根は超寒くてきつかった…。温泉は、内湯と外湯があります。広くてめちゃくちゃ気持ちよかったです。今回の研修で貸切だったため、内湯も混雑することなくくつろげました。夜、露天風呂に入ると冬の星座「オリオン座」が見えてとても贅沢な空間でした。その他写真に収めるのを忘れてしまいましたが、ランドリー（洗濯機と乾燥機）が無料で使えます。最後に素晴らしい研修施設でした。研修をする際に、ワークショップをしたり、交流を深めるのに最適な場所だなと感じました。ライムリゾートは新潟県の妙高にもあるので行ってみたいなぁ…。それではまた！！ > Xでシェア

ライムリゾート箱根はいいぞ

#CSM #スクラムマスターはじめに2024年1月24日から26日の二泊三日、オンサイト型の認定スクラムマスター研修に参加してきました。私は、モニクルでソフトウェアエンジニアとして主に社内向けのプロダクトの開発をしています。私はスクラムマスターを担当していますが、進めていくにつれて何が正しいのかわからないことが増えていきました。 スクラムをしているつもりだが、ミニウォーターフォールになってしまっている感覚がする スプリントゴールが設定できない ベロシティだけで数ヶ月間の未来予測をしており、リファインメントができていない作業を見積もらなければならない スクラムマスターが何をすればいいのかわからない ふりかえりで良いアイデアが出てこない 作ったものがなかなかリリースできない ステークホルダにマイクロマネジメントされてしまう社内ではスクラムマスター同士の情報交換をする場があり、困った時にアトラクタの書籍やWebの資料を目にする機会が多くありました。その後、アトラクタのメンバーから直接教えていただける認定スクラムマスター研修に参加すると体系的に学ぶことができて良いのではないかということで、参加してみることにしました。印象に残ったこと私が研修に参加した上で印象に残ったことを紹介します。アジャイルな開発が向いている領域現代はソフトウェア・ハードウェアともに進化の速度が早く、世の中で受け入れられるプロダクトも次々に変わっていきます。このような状況下でのプロダクト開発は未来予測が難しいため、素早く仮説検証を行って必要なものを無駄なく作る必要があります。問題を分類して意思決定をモデル化したフレームワークとして「クネビンフレームワーク」と言うものがありますが、カオスな領域・複雑な領域に属するものは問題を解決する方法が理解できないので（複雑な領域の場合は）試行錯誤を行ったり、（カオスな領域の場合は）まず何か行動してみる必要があります。ウォーターフォールの場合は作ったものが役に立つものなのかを知るのに時間がかかり過ぎるため、作ったものがムダになるリスクが高まります。このような領域ではアジャイルな開発が適しています。つまり、顧客が抱えている問題をするために、それを解決する（と思われる）を提供し、顧客の反応を見ながらのがアジャイルの本質です。間違いがあればすぐに修正し、変化を見ながら役に立つものを作っていく。現代のプロダクト開発では、そのような領域の問題が数多くあるため、各業界・各社・各チームが問題解決のためにアジャイルな開発手法（=スクラム）を導入しています。未熟なチームこそスクラムを導入すべき研修を受ける前は、優秀なチームメンバーでなければ良いスクラムはできないと思っていました。しかし、実際には未熟なチームこそスクラムを導入すべきと言われています。なぜなら、チーム結成当初からいきなり成熟した優秀なメンバーを十分に揃えることは稀だからです。また、スクラムでは全体の時間の約20%をスクラムイベントに費やすため、開発時間だけ考えれば非効率と言えます。しかし、この非効率さこそスクラムをうまくやるための仕掛けなのです。 を重視し、を作り、を通じてニーズや状況のしていく。アジャイルマニフェストにも示されているような価値観を大事にするために必要なエッセンスが詰まっています。仮に、チームが本当に未熟で成果が出せないとすれば、それは最初のスプリントレビューですぐに気づくことができ、対処するために動くこともできます。スプリントレビューで価値あるフィードバックを得るためにスクラムで最も重要となるのは、スプリントレビューで顧客から価値あるフィードバックを得ることです。顧客に成果を見せることで、その価値を判断し、次のスプリントの方向性を決定します。そのため、スプリントレビューで良いフィードバックを得られるよう準備することが重要です。鍵となるのは、です。明確なスプリントゴールがあれば、メンバーは目標達成に必要な行動を考えることができ、POをサポートできます。そして、実装を行ってインクリメントを作ります。結果として、スプリントレビューで得られるフィードバックはスプリントゴールを達成したインクリメントに対する価値判断になります。私の開発チームでは、スプリントゴールをどう設定すればいいのかわからず、「」として省略してしまっていましたが、それは間違いだということがわかりました。「」を考えながらゴール設定をすると良いということを教わりました。また、スプリントレビューのメンバーは必ずしも固定である必要はなく、「」ということを念頭に置いて招待すると良いとのことでした。タイムボックスを意識するスクラムにおいて、タイムボックスを意識することは重要なルールの一つです。これは時間内に話を終わらせることを意味します。たとえ話が終わりそうになくても必ず一度タイムボックスで区切り、その後必要に応じて再検討する必要があります。毎回話がまとまらない場合は、その理由を分析し改善方法を検討する必要があります。実際に私のチームではデイリースクラムの時間が30分以上かかってしまう問題がありました。原因として、デイリースクラムに直接関係のない内容を話しているということがありました。この問題を解決するために、デイリースクラムの時間まで話すのを待つのではなく普段から相談したい相手とコミュニケーションを取るように促し、デイリースクラムでは必要な報告だけを行うように努めてもらい、時間内に終わるようにしました。スクラムイベントのタイムボックスを守ることがルールを守ることになり、スプリントゴールを達成する目標を果たすことにもつながります。「時間がもっとあれば…」と言いたくなる気持ちをグッと堪えて、小さなインクリメントを積み上げスプリントゴールを達成することが重要です。一方で、研修中はスプリントレビューに最も時間を割いて（各チーム時間制限なしで）全チームの発表を聞きました。最も重要な時間であることの表れなのかもしれません。また、チームの調子がよくなれば良いフィードバックが増えるので、続けていくにつれて時間が短くなっていくのかもしれないなと感じました。研修で体感したスクラムの力研修では、その場で集まったメンバーでチームを組み、実際にプロトタイプの開発を行います。スクラムイベントを除いた開発時間は、たったの20分程度です。まだ知り合って間もないメンバーで息を合わせて作業を行うのは困難でしたが、それでもスプリントレビューで成果を発表しなければなりません。実際、初回のスプリントレビューでは厳しい意見が数多く出ました。しかし、チームは次のスプリントで軌道修正を図り、次の発表では「使ってみたくなった」とフィードバックをいただくことができました。ふりかえってみると、もし最初の段階でフィードバックをもらえていなかったら…と思うとゾッとします。楽しく楽に仕事できるようにするためのふりかえりスプリントレトロスペクティブは、開発プロセスそのものを改善するための場です。つまり、プロダクトやバグではなく、開発方法の問題に焦点を当て、より楽しく楽に仕事ができるように改善していくことが目的です。これまで、私のチームでは何のふりかえりなのか明確にしておらず、プロダクト改善や技術的な試みがしばしば議論されていましたが、これは誤りでした。プロダクトに関するレトロスペクティブは、「リリースレトロスペクティブ」など別の機会を作って、それに合わせてメンバーも調整して行うといいようです。また、成熟したチームは、レトロスペクティブ前に問題を見つけて改善できるため、次のステップとして、例えば「Slackで朝の挨拶をする」というような簡単で実験的な取り組みを入れてみると良いことを学びました。一見意味がないように思えるような取り組みでも、予期せぬ良い改善につながる可能性があります。良いと思えば続ければいいし、意味がないならやめれば良いだけなので、確かにデメリットはなさそうです。現在読んでいる「アジャイルレトロスペクティブ」には様々なゲームが紹介されているので、ユーモアのある面白いゲームを取り入れて、楽しいレトロスペクティブを開催し、チーム全体で楽しく楽に仕事ができる環境を作っていきたいと思います。スクラムマスターはチームを自立へと導く存在研修最終日では、「偉大なスクラムマスター」について考えました。スクラムマスターは、チームやメンバー、組織を支援する縁の下の力持ち的な存在です。サーバントリーダーとして、メンバーに指示をするのではなく、チームを注意深く観察し、自走できるよう支援します。メンバーのマインドセットを変えるのは容易ではありません。状況によって求められることも異なるため、一概にこれをやれば良いといったタスクリストはありません。その点でスクラムマスターは大変な仕事ではありますが、一つ一つ確実に原則を守ってやっていけば良いんだという一定の安心感と自信を得られました。さらに、チームが自立し始めると、スクラムマスターの存在は必要なくなり、「見えなくなる」という興味深い考え方も学びました。最終的に自分の居場所がなくなるというのはちょっと寂しい気持ちもありますが、開発でいう「属人性を排除する」イメージに近い気もします。ここまで到達できるように努力したいです。最後にこのワークショップを通してわかったことは、スクラムをうまく回すための「銀の弾丸などない」ということでした。チームとステークホルダーが良いプロダクトを作れるようにするために支援をし、プロセスを改善することで、短時間で効果的なプロダクトを生み競争に勝つことができます。スクラムにおける本当に大切なことを守りながら、まずはを持って小さなことから少しずつ改善していきたいと思います。 < XでシェアSpecial Thanks今回認定スクラムマスター研修に参加する機会を与えてくれた /wadata/モニクル.icon モニクルとCTO塚田さんに感謝申し上げます。スクラムマスターの育成にも力を入れている弊社では新しいメンバーを大募集中です。記事を見てもし興味がある方がいたらこちらから誰とでもカジュアル面談できます。お気軽にご連絡ください。

認定スクラムマスター研修に参加して印象に残ったこと

台南 / 神農街#アドベントカレンダー #Jira #FigJam #Scrapboxはじめにこんにちは、@sugoi_wada sugoi wada.iconです。この記事は、モニクル Advent Calendar 2023 の22日目の記事です。昨日は/wadata/yohei.kuji.iconによるでした。今回は弊社初のアドベンドカレンダーとして、最近自分が仕事をする上で意識しているJira、Scrapbox、FigJamのそれぞれの役割と使い分けについて書いていきます。ツールの導入経緯現在モニクルではJira、FigJam、Scrapboxの各ツールが導入されている状況ですが、私た入社した2020年4月当時はどのツールも使っていませんでした。その後、随時ツールの導入が行われていき、今の状態になりましたが、改めて導入に至った経緯をまとめておきたいと思います。まずはJiraの導入に至った経緯です。実は、私が入社する前は1人エンジニアの出来立てほやほやスタートアップで、マネイロのサービスもまだ存在していませんでした。そんな中、私と/wadata/ka2n.iconの二人が同時に参画しエンジニアが三人になったところでチームでの開発体制に移行するということで、私がJiraの使用を提案し、導入に至りました。この時期は創世記でまだ何も整備されていない状態でしたので、エイヤで入れた記憶がありますが、以下の点を考慮に入れました。 使い慣れたツールを使いたい（前職で使った経験がありました） スクラムが可能なツールを使いたい（ただのカンバン系ツールは避けたい） なんならドキュメントも書く場所が欲しい（当時はConfluenceも同時に導入しました）次にScrapboxです。上記にもあるように導入前はConfluenceを使用していました。Confluenceには以下のような課題がありました。 ドキュメントをカジュアルに書き残せない  どこにページを置くべきか悩んでしまい、雑にページを作るのが憚られる ドキュメントの更新がしにくい（編集画面に遷移する手間がかかる） 他人のページを編集・整理しづらい 階層構造を管理しにくいその後、/wadata/nkzn.iconが弊社にジョインしてScrapboxの導入を進めてくれました。Scrapboxは常に編集モードでドキュメントの更新がしやすく、ページに階層構造という概念が存在しないため置き場所に迷うことがありません。また、ページを[]で囲っておけばリンクが紐づいてくれるため社内wikiのような役割も果たすことができて大変便利です。ちなみに、[]で囲うことをブラケティングと呼ぶそうです。最後にFigJam（Figma）の導入経緯ですが、元々デザイナーがおらず業務委託先でSketchなどを利用したデータの受け渡しが行われていましたが、後にデザイナーが入社してからオンラインコラボレーションデザインツールとしてFigmaが導入される運びとなりました。その後、FigJamがFigmaの新しいツールとして公開された流れで、FigJamを導入することになりました。ツールをどう使い分けるか？そもそも、これらのツールは本来の使用目的がそれぞれ異なります。table:何をするためのツールか？ Jira	課題やプロジェクト管理をするツール Scrapbox	チームでリアルタイムに情報を共有できるツール FigJam	オンラインホワイトボードしかし、それぞれに共通する特徴として情報を残したり整理することができるため、プロダクト開発を進める上での要求・要件・設計などの情報がこれらのツールに集約される傾向があるように感じます。仕事でこれらのツールを使っていくうちに、各ツールごとに得意なこと・不得意なことがあることがわかってきたので今回はそれをまとめます。みんなで多面的なアイデアを出しあうならFigJam一択私の所属するチームでは実行計画を行っています。実行計画では、スプリントバックログに積まれた（積んだ）アイテムを実際に実装するにあたり、どのような作業が必要かを書き出して整理する会です。実行計画にはチームのエンジニアが参加します。実行計画を通じてスプリントバックログアイテムで具体的にどのような作業を行うかのイメージを膨らませ、メンバー全員で共通認識を合わせることができます。実行計画の詳細についてはまた機会があれば別の記事で書こうと思いますが、実行計画ではFigJamを開いて議論をしています。なぜ実行計画の場でFigJamが良いのかをまとめてみました。 メンバー全員でコラボレーションができる セクションや図形、付箋を色別に貼って線で結ぶことができるなど表現力が高くヴィジュアライズしやすい  さらに画像やテキストも自由に配置できる ページをスプリントごとに分割せず、同じページに書くことでスプリントを跨いだ課題に対し、継続的に議論ができるようになる 付箋の記入者が自動的に記録される スタンプやステッカーなどが豊富で遊び心が多く、テンションが上がる特に大きめのアイテムになるとどこから手をつければいいのかと悩むことがありますが、FigJam上であればまずみんなで付箋に情報を書いた上で整理していくことができるので、自然とアウトプットが進んで議論が捗るようになりました。みんなで同時に書いたとしても、コンフリクトしたりどこに書けばいいのかわからないという困り事が発生しないため、全ての意見や参考資料のリンクが残ります。みんなでアイデアを出し、頭の中を整理して情報を共有するツールとしてはFigJamが適しています。いつも同僚の/wadata/yohei.kuji.iconがステッカーをたくさん貼ってくれるので、ドキュメントをみた時のつまらなさもありません。ちなみに、Miroなどの類似ツールでも大丈夫だと思います。超お手軽な社内情報共有wikiとして最強のScrapboxFigJamがみんなで情報をアウトプットし整理するのに役に立つことを紹介しましたが、一方で検索機能は使いにくい、見辛いなと感じることがあります。そんな時はScrapboxが役に立ちます。FigJamで議論を交わして決めた設計に関する記録（Architecture Decision Record: ADR）や意思決定をScrapboxにサクッと1ページにまとめることができます。また、プロダクト固有の表現や単語にはブラケティングすることで、それらの解説は他のページに説明を委ねることができます。モニクルでは、社内共有目的で作成されたScrapboxのプロジェクトが一つ存在していて、そこを見れば他のチームメンバーにもADRを共有することができ、プロダクトを横断したナレッジのシェアができています。Scrapboxでは検索機能の他、ブラケティングによる検索性がとても高い割にメンテナンスコストが低いので、FigJamの内容をScrapboxでまとめる用途としては最適だと感じています。チケットとして課題をまとめて管理するJira最後はJiraです。Jiraはこれまでのツールとは性質が異なりプロダクトの課題を管理するツールですが、課題をチケットとして管理することができ、各課題に詳細を書くことができるため上記のツールに書くような内容をJiraにも書くことができます。ただ、Jiraを使ったコミュニケーションには以下のような問題があります。 チケットの順番を様々な尺度・粒度で並び替えてみることができない 詳細を書く時にコラボレーションできない 詳細やコメントを見る場合、一つ一つ開かないと中身が確認できない チケットの紐付けが面倒（紐付けるチケットの番号を選ぶ部分のUXが悪い）一方で、チケットのアトリビュートに値を付与することによって検索性が向上したり、スプリントに特化しているためやりやすい面があるのも事実です。なので、Jiraのチケットに対して細かな情報は記載せず、適宜URLを貼り付けたりコピーした内容を貼り付けることによって、Jira上で内容に関して細かな議論をしなくても良いようにしています。最後にツールにはそれぞれの特徴があります。目的に応じてうまくツールを導入し社内に広めることによって徐々に浸透していき、当たり前にそのツールを使ってくれるようになります。社内でみんながツールを活用して情報を残したり、オープンにしてくれることは嬉しい反面、使い方を間違えてしまっているんじゃないかと思うケースもよく見かけます。そんな時、ふと立ち返ってみて、今使っている様々なツールや世の中にある新しいツールを使ってみることで思わぬ新発見があるかもしれません。明日は、モニクルの神デザイナー大谷和宏さんの23日目の記事です。お楽しみに 👋 > X でシェア宣伝/wadata/モニクル.icon モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。もし私とお話したい方はこちらからどうぞ 🤝

JiraとScrapboxとFigJamの使い分けTips

鹿港 / 摸乳巷#GraphQL #Fragment_Colocation #Fragment_MaskingFragment ColocationとはReactのアプリケーションでGraphQLを使うときに使われるテクニックの一つです。Fragment Colocationによって、データのフェッチ処理と、データをコンポーネントに描画する処理を分離できることなどがメリットです。詳しくはこちらも参考にしてください。実装例を見てみます。なお、本記事のコードは関係の深い部分のみを抜粋したものになりますので、importや足りない部分を調整してください。code:Pokemon.tsx gql(`   fragment Pokemon on Pokemon {     number     name     image   } `);  export const Pokemon = ({ pokemon }: { pokemon: PokemonFragment }) => {   return (     <div>       <a href={/pokemon/${pokemon.number}}>         <h3>{pokemon.name}</h3>         <img width={100} height={100} src={pokemon.image} />       </a>     </div>   ); };実装時のポイントは、Fragmentの定義の側にそのFragmentをPropsとして受け取るコンポーネントを配置（colocate）することです。PokemonFragmentのような型を自動生成するのにGraphQL Code Generatorを使っています。PokemonコンポーネントはPokemonFragmentをPropsで受け取りJSX.Elementを返しますが、データの取得方法に関する詳細が書かれていません。このようにデータの取得と描画を分離することで、このコンポーネントの保守性が上がります。ただし、この書き方ではFragment Colocationを強制することができません。具体的には以下のようにデータの取得する場所でもFragmentのフィールドにアクセスすることができてしまいます。code:index.tsx const PokemonsQuery = gql(`   query pokemons($first: Int!){     pokemons(first: $first){       id       ...Pokemon     }   } `);  const Index = () => {   const data, fetching, error } = useQuery({     query: PokemonsQuery,     variables: {       first: 151,     },   });      return (     <ul>       {data?.pokemons?.map(         (pokemon) =>           pokemon && (             <li>               {/* Pokemonコンポーネントの外でPokemonFragmentのフィールドにアクセスできてしまう */}               <h2>{pokemon.number}</h2>               <Pokemon pokemon={pokemon} />             </li>           )       )}     </ul>   ); };Colocationされたコンポーネント以外でFragmentの値にアクセスしてしまうと、もしFragmentのフィールドを変更した場合に呼び出し側のコンポーネントが壊れる可能性があります。また、見かけ上Fragmentのフィールドを使用していることに気づきにくいという問題があります。これはFragment Colocationの実装が不十分で保守性を下げることに繋がります。この問題を解決するアイデアの一つがFragment Maskingです。Fragment MaskingとはRelayが提唱している、Fragment Colocationをカプセル化するための方法です。Relay のチュートリアルでは標準でFragment Maskingを使った流れが示されています。なお、Relayの文脈ではData Maskingと表現しているようです。GraphQL Code GeneratorにRelayスタイルのFragment Colocationが実装されているので、今すぐ使うことができます。ということで、今回はgql-tag-operations-presetプラグインを用いて実際に使ってみます。gql-tag-operations-presetでFragment Maskingを使ってみるgql-tag-operations-presetやGraphQLクライアントの導入自体は済んでいる前提で進めます。まずは、codegen.tsの設定で有効にします。といっても簡単で、presetConfig: { fragmentMasking: true } を入れてあげるだけです。code:codegen.ts const config: CodegenConfig = {   ...   generates: {     'graphql/__generated__/': {       preset: 'gql-tag-operations-preset',       presetConfig: {         fragmentMasking: true,       },       plugins: [],       config: {         ...       },     },   }, };Fragment Maskingを有効にしてコードを再生成すると、カプセル化が効いてフラグメントのフィールドにアクセスできなくなります。さらに、FragmentのオブジェクトをPropsに渡す部分でもエラーが出ています。生成したコードを読むとわかりますが、$fragmentRefsというキーをもつ型に変換されていて、直接PokemonFragmentへ参照できなくなりました。code:1. graphql/__generated__/graphql.ts // fragmentMasking: false（またはデフォルト）の場合 export type PokemonsQuery = { __typename?: 'Query', pokemons: Array<{ __typename?: 'Pokemon', id: string, number: string | null, name: string | null, image: string | null } | null> | null };code:2. graphql/__generated__/graphql.ts // fragmentMasking: true の場合 export type PokemonsQuery = { __typename?: 'Query', pokemons: Array<(     { __typename?: 'Pokemon', id: string }     & { ' $fragmentRefs'?: { 'PokemonFragment': PokemonFragment } }   ) | null> | null };これをカプセル化されたコンポーネントの中だけで参照できるように変えていきます。code:Pokemon.tsx import { FragmentType, gql, useFragment } from '../graphql/__generated__';  export const PokemonFragment = gql(`   fragment Pokemon on Pokemon {     number     name     image   } `);  export const Pokemon = ({   pokemon, }: {   pokemon: FragmentType<typeof PokemonFragment>; }) => {   const pokemonFragment = useFragment(PokemonFragment, pokemon);      return (     <div>       <a href={/pokemon/${pokemonFragment.number}}>         <h3>{pokemonFragment.name}</h3>         <img width={100} height={100} src={pokemonFragment.image!} />       </a>     </div>   ); };ポイントは、Propsの型をFragmentから、FragmentType<typeof Fragment>に変更していることです。この型のオブジェクトはそのままで使うことができないので、useFragment(Fragment, fragment)を使って使えるようにします。このuseFragmentはいわゆるReactのHooksではなく、ただの関数です。どのような関数かは生成されたコードを読むとわかります。非常に単純で、as any で戻り値の型を明示してキャストしているだけですね。code:graphql/__generated__/fragment-masking.ts // return non-nullable if fragmentType is non-nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: FragmentType<DocumentNode<TType, any>> ): TType; // return nullable if fragmentType is nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: FragmentType<DocumentNode<TType, any>> | null | undefined ): TType | null | undefined; // return array of non-nullable if fragmentType is array of non-nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: ReadonlyArray<FragmentType<DocumentNode<TType, any>>> ): ReadonlyArray<TType>; // return array of nullable if fragmentType is array of nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: ReadonlyArray<FragmentType<DocumentNode<TType, any>>> | null | undefined ): ReadonlyArray<TType> | null | undefined; export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: FragmentType<DocumentNode<TType, any>> | ReadonlyArray<FragmentType<DocumentNode<TType, any>>> | null | undefined ): TType | ReadonlyArray<TType> | null | undefined {   return fragmentType as any; }つまり、オブジェクトにデータはあるものの、TypeScriptの型の上でFragmentのデータを隠蔽（Masking）することでアクセスできないようにしています。そしてColocationしたコンポーネント内部でキャストして使えるようにします。テストやStorybookでモックのFragmentオブジェクトを入れたい場合makeFragmentDataメソッドを作りPropsでFragmentオブジェクトを渡してあげましょう。code:makeFragmentData.ts import type {   ResultOf,   TypedDocumentNode as DocumentNode, } from '@graphql-typed-document-node/core'; import type { FragmentType } from '~/generated';  export function makeFragmentData<   F extends DocumentNode,   FT extends ResultOf<F>, (data: FT, _fragment: F): FragmentType<F> {   return data as FragmentType<F>; }code:component.ts import { Pokemon, PokemonFragment } from '../components';  <Pokemon   pokemon={makeFragmentData(     {       number: '1',       name: 'ピカチュウ',       image: 'https://dummyimage.com/100x100',     },     PokemonFragment   )} />こちらもキャストしているだけですね。※ ちなみに、本題とはそれますが client preset を使う場合はmakeFragmentData(data, fragment)が生成されるコードに含まれているため、メソッドを作る必要はありません。Fragmentの中でも外でも使いたいフィールドはどうするかFragment Colocationされたコンポーネントの中でも、クエリの呼び出し側でも使いたいフィールドがある場合は、クエリ（ミューテーション）に直接フィールドを定義した上で、参照するFragmentにもフィールドを定義してあげましょう。まとめFragment MaskingはFragment Colocationを強制するためにとても便利な機能です。自動生成されたコードを読めばわかるように、実際に行っていることは型によるFragmentデータのカプセル化だけなのでGraphQLのクエリやミューテーションに影響を及ぼすことはありません。また、現在GraphQL Code Generatorではv3のロードマップが敷かれていて、client preset という便利なプリセットが作成されています。このプリセットは既にurqlのドキュメントで使われていたりして、今後のデファクトプリセットになる可能性があります。client presetでは今回紹介したFragment Maskingがデフォルトで有効になっていることからも、積極的に使っていくことは悪くない選択肢だと思います。参考 https://zenn.dev/mh4gf/articles/graphql-codegen-client-preset https://zenn.dev/takashima/articles/4c284439135a0c < Twitterでシェア宣伝/wadata/モニクル.icon モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちらから！

Fragment Masking で Fragment Colocation を強制する

大稻埕碼頭#GraphQL #Next.js #Apollo #Persisted_Queriesこちら（GraphQL の Persisted Queries について）の続きです。はじめに私が所属するモニクルのサービス「マネイロ」では、REST APIからGraphQLへの移行を進めています。フロントエンドはNext.jsを採用しており、REST APIのデータ取得にはSWRを使っています。これをApollo Clientで置き換えています。バックエンドではRailsにGraphQL Rubyを使ってクエリやミューテーションを作成しています。なお、Apollo Serverは使っていません。さて、マネイロは資産運用に関する悩みを解決するお手伝いをするために無料でオンライン相談ができるサービスを提供しています。そのために相談予約可能な日時や時間帯を取得するAPIがありますが、このAPIレスポンスはCDNにキャッシュしています。GraphQLに移行しても同じようにCDNにキャッシュしたいのですが、GraphQLはデフォルトでPOSTリクエストするためVercelのCDNでキャッシュすることができません。また、そもそもGraphQLクエリをブラウザに露出してしまうのも避けたいところです。そこで、Persisted Queriesを使ってこの問題を解決することにしました。Persisted Queries を使う方法として二種類のパターンを考えてみました。 Next.js（フロントエンド）からNext.js（API Routes）へのリクエストにのみハッシュ値を使う Next.js（フロントエンド）からRails（バックエンド）に至るまで全てハッシュ値でやりとりする今回は前者の実装だけで目的を達成することができるため、前者の実装を行うことにしました。クエリとハッシュ値を相互に変換するテーブルを用意するまず、今回の実装に必要となる変換テーブルを用意します。前回の記事でも紹介したgraphql-codegen-persisted-query-idsを使います。READMEを読みつつインストールした後、codegen.ymlに設定を記述します。名前やファイルパスは適宜読み替えてください。code:codegen.yml overwrite: true ... generates:   generated/server.graphql.gen.json:     plugins:       - graphql-codegen-persisted-query-ids:           output: server           algorithm: sha256   generated/client.graphql.gen.json:     plugins:       - graphql-codegen-persisted-query-ids:           output: client           algorithm: sha256その後、コード生成コマンドを実行します。code:console ./node_modules/.bin/graphql-codegen --config codegen.ymlこれで、generated/server.graphql.gen.jsonとgenerated/client.graphql.gen.jsonのファイルがそれぞれ出来上がります。どのような形式になっているかは、前回の記事が参考になります。Apollo Linkの設定Http Linkを使います。以下のように設定していきます。 url  BFFへのエンドポイントを指定する useGETForQueries  クエリにはGETリクエストを利用するためtrueにする fetch  GETリクエストの場合は query をハッシュ値に置き換えるcode:apolloClient.ts import { ApolloClient, from, HttpLink } from "@apollo/client" import queryHash from "generated/client.graphql.gen.json"  const endPointLink = new HttpLink({   uri: "/api/graphql",   useGETForQueries: true,   fetch: (uri, options: RequestInit) => {     if (options.method === "GET") {       // クエリをハッシュ値に変換します       const path, queryString = uri.toString().split("?")       const params = new URLSearchParams(queryString)       // params の中身についてはこちらが参考になります       // https://www.apollographql.com/docs/react/api/link/introduction/#the-operation-object       const { query, operationName, ...others } = Object.fromEntries(params)       const hashedParams = new URLSearchParams({         q: queryHashoperationName,         operationName,         ...others,       })       return fetch(${path}?${hashedParams}, options)     }      return fetch(uri, options)   }, })  export const apolloClient = (() =>   new ApolloClient({ link: from(endPointLink) }))() 上記の例ではfetchを独自にオーバーライドしていますが、graphql-codegen-persisted-query-idsはApollo Link用のアダプタも用意されていて、こちらを使うことでApolloの仕様に沿ったリクエストを書くこともできます。API Routesでの処理最後にAPI Routesの処理を書いていきます。主な観点は以下の部分です。 next-http-proxy-middlewareを使用すると、簡単にProxyするBFFが書けて楽 ハッシュ値をクエリに戻した上で、GraphQLバックエンドにPOSTリクエストする HTTP キャッシュヘッダーをセットするcode:pages/api/grpahql.ts import type opnameHash from "generated/client.graphql.gen.json" import hashQuery from "generated/server.graphql.gen.json" import type httpProxy from "http-proxy" import { NextApiHandler, NextApiRequest, NextApiResponse, PageConfig } from "next" import httpProxyMiddleware from "next-http-proxy-middleware"  export const config: PageConfig = {   api: {     bodyParser: false,     externalResolver: true,   }, }  const handleProxyInit = (proxy: httpProxy) => {   proxy.on("proxyReq", (proxyReq, req, res) => {     if (proxyReq.method !== "GET") return     const path, queryString = proxyReq.path.split("?")     const params = new URLSearchParams(queryString)      // クエリのハッシュ値からクエリを復元する     const { q, operationName, ...others } = Object.fromEntries(params)     const query: string | undefined = hashQueryq      if (!query) throw new Error(クエリが見つかりませんでした。 ${q})      // GETリクエストをPOSTリクエストとして送信する     proxyReq.method = "POST"     proxyReq.path = ${path}?operationName=${operationName}     const bodyData = JSON.stringify({       query,       operationName,       ...others,     })     proxyReq.setHeader("Content-Length", Buffer.byteLength(bodyData))     proxyReq.write(bodyData)   })   proxy.on("proxyRes", (proxyRes, req, res) => {    // ※ req オブジェクトからリクエスト情報が取得できるので、クエリに応じたキャッシュの設定などをすると良いでしょう     proxyRes.headers"Cache-Control" = "s-maxage=60, stale-while-revalidate"   }) }  const h: NextApiHandler = (req: NextApiRequest, res: NextApiResponse): Promise<void> =>   httpProxyMiddleware(req, res, {     ..., // ※ RailsバックエンドへのProxyの設定を書く     onProxyInit: handleProxyInit,   })  export default h これで完了です。Apollo Linkを使っているため、フロント側のuseQueryフックは変更する必要がありません。これでCDNでのキャッシュと、クエリをブラウザに露出させることを防ぐことができるようになりました。まとめPersisted QueriesはApolloが提唱する仕様通りに作ることもできますが、今回の例のように自分で変換処理を書くことで、最低限の仕組みだけで実装することが可能です。一方でApolloの仕様に則ったライブラリも豊富なので、そちらに実装に合わせておくと良い場合もありそうです。いずれにしても仕組み自体は難しくないので、覚えておくと何かと便利な仕組みだと思いました。 < Twitterでシェア宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

GraphQLクエリをCDNキャッシュに載せたい

林家花園#GraphQL #Persisted_QueriesGraphQL クエリの特徴GraphQLではクライアントとサーバ間のやりとりにGraphQLクエリを使うことで、一回のリクエストで必要な要素だけを取得することができます。code:sample_query  query GetCustomerQuery {    customer(id: "Customer001") {      id      email      profile {        id        name      }    }  }通常はこのようなクエリをPOSTリクエストのペイロードに含めて、{ "query": "query GetCustomerQuery {...}" }のような形でサーバサイドにリクエストします。サーバサイドではこのクエリを解釈し、必要なオブジェクトや要素だけをクライアントに返却します。このようにして、クライアントはクエリを記述することによって一度に複数のネストしたオブジェクトを最低限必要な要素だけ取得することが可能になります。なお、上記の"Customer001"のような値は引数（variables）として渡すことが一般的ですがPersisted Queriesではvariablesを取り扱わないため省略します。Persisted Queries とはPersisted Queiesは、リクエストのペイロードにGraphQLクエリの文字列を直接含めるのではなく、ハッシュ化した文字列（ハッシュ値）を使ってリクエストする方法です。クライアントはハッシュ値をペイロードに入れてリクエストした上で、サーバサイドではハッシュ値をクエリに戻し、必要なデータを返します。Persisted QueriesはGraphQLの機能を拡張したプロトコルです。そのため、Persisted Queriesに対応したクライアントでは以下のようなペイロードを送ります。code:extensions.json {   "extensions":{     "persistedQuery":{       "version":1,       "sha256Hash":"ハッシュ値"     }   } }クライアントはクエリをハッシュ化する必要があります。上記の例ではSHA256のハッシュアルゴリズムを使ってハッシュ値を生成しています。また、サーバサイドでは受け取ったハッシュ値をクエリに戻す必要があります。ここで、クエリとハッシュ値を変換する方法を2種類紹介します。クエリとハッシュ値を相互に変換するテーブルを用意するクエリとハッシュ値が相互に変換できればそれで良いので、クライアントとサーバ側でそれぞれ変換テーブルを事前に用意しておくことで対応させることが可能になります。変換テーブルはビルドステップで事前に準備したり、スクリプトを走らせて生成したりします。以下はJS環境で使うためにgraphql-codegen-persisted-query-idsという自動生成ツールを用いて作った json ファイルの例です。code:client.json {  "getCustomerQuery": "ハッシュ値" }code:server.json {  "ハッシュ値": "query GetCustomerQuery {...}" }client.jsonをクライアントで、server.jsonをサーバサイドでそれぞれ使用します。クライアントではハッシュ値をそのまま取り扱うことはしたくないですが、このツールを使えばgetCustomerQueryというクエリの名前を使ってハッシュ値を取り出すことができます。便利ですね。Automatic Persisted Queries で自動変換を行う前述したような変換テーブルを用意することなく自動的に変換を行ってくれるようにする方法としてAutomatic Persisted Queriesがあります。Automatic Persisted Queriesを使う場合は、Apollo のようなそれに対応したサーバとクライアントを使います。仕組みとしては、クエリと対応するハッシュ値をクライアントで動的に生成し、クエリの代わりにハッシュ値をサーバサイドに送ります。もしサーバサイドでハッシュ値に対応するクエリがわからない場合はエラーを返します。そこで、クライアントは再度同じクエリをリクエストするのですが、その時にクエリ文字列とハッシュ値を両方ともペイロードに含めます。サーバサイドではハッシュ値とクエリを登録した上で結果を返します。それ以降登録されたクエリはハッシュ値だけ送ればよくなります。これを自動的に行ってくれる仕組みがAutomatic Persisted Queriesです。Persisted Queries はどのような問題を解決するのかデータ通信量の削減GraphQLで複雑なクエリを使用するとクエリ文字列が長くなるため、ペイロードサイズが大きくなりネットワークのパフォーマンスが低下します。Persisted Queriesを使用すると長いクエリであっても文字列長が同じハッシュ値を送るため、ペイロードサイズが削減できます。さらに、サイズが小さくなることでGraphQLクエリをGETリクエストで送信できます。GETリクエストにできれば一般的なCDNで結果をキャッシュできるようになるため、パフォーマンスがさらに向上します。セキュアな通信の実現GraphQLのクエリはスキーマさえ正しければどんなクエリでも受け付けることができます。複雑なクエリの中には処理の重いロジックや、深いネスト、無駄なプロパティが含まれる場合があります。また、場合によってはクライアントから悪意のあるクエリや想定外のクエリ（ただしスキーマ上は正しいクエリ）を含めたリクエストがくる場合もあるかもしれません。通常のクエリであれば、このようなクエリでもあってもスキーマ上正しければ値を返すしかありません（※クエリの複雑度を計算して閾値を超える場合にはエラーを返す方法は存在しますが、閾値を超えなければ正しいレスポンスを返すでしょう）。しかしPersisted Queriesを使うことによって事前に決められたクエリのハッシュ値のみを受け付けることができるようになるため、想定していない複雑なクエリや悪意のあるクエリをクライアントから送られても破棄することができます。まとめPersisted Queriesそのものは非常にシンプルなんですが、GraphQLの拡張機能であるがゆえに体系だった解説記事が少ないなと思い今回まとめてみました。次回は、実際にやってみた例を紹介しようと思います。 < Twitterでシェア参考 https://relay.dev/docs/guides/persisted-queries/ https://blog.codecentric.de/en/2020/05/how-to-secure-a-graphql-service-using-persisted-queries/ https://developers.gnavi.co.jp/entry/frontend_improvement/ https://qiita.com/Quramy/items/b3943a0c27f3ade2c57d宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

GraphQL の Persisted Queries について

林家花園#Deno #Fresh 前回の記事で使ってみたFreshについての特徴と所感をまとめてみようと思います。もし前回の記事を読んだことがない場合は、先に読むことをお勧めします。Denoを初めて触ろうと考えている人やFreshを使ってみたい人に参考になればと思います。Fresh は Preact 依存のフレームワークFreshは内部実装でPreactが使われています。そのため、後ほど紹介するパッケージ管理システムの中にデフォルトで組み込まれているPreactを外すことはできません。前回はRSSフィードを作るだけだったので、特にPreactやJSXを使うシーンというのは無かったのですが、Preactを外してしまうとFreshサーバの内部実装でエラーになってしまいました。そういう意味では、今回はよりシンプルなHttpフレームワークを使うだけでも良かったのかもしれません。ゼロコンフィグでTypeScriptが使える私は普段から専らTypeScriptを使っていますが、Denoは何の設定をせずともTypeScriptを使うことができます。つまり、Node.jsでTypeScriptを書く際には必須となるtsconfig.jsonが必要ありません。この辺りの仕組みとしては、まずDenoを使うときに必須となるdeno-cliにTypeScriptが内包されています。そのため、下記のコマンドでどのバージョンが使われているのかを知ることができます。code:console deno --version  # deno 1.24.3 (release, aarch64-apple-darwin) # v8 10.4.132.20 # typescript 4.7.4tsconfig.jsonをカスタマイズすることもできます。カスタマイズする場合は、deno.jsonまたはdeno.jsoncというファイルを作成します。ただし、カスタマイズできるのはcompilerOptionsのセクションのみに限定され、そのほかは無視されるようです（Denoには無関係の機能や不完全な動きをするものが含まれるため）。Freshの新規プロジェクトにはdeno.jsonが含まれるため、そのままcompilerOptionsセクションを作成すれば良いですね。ちなみに、デフォルト値については公式ページにまとまっているため、目を通しておくと良いかもしれません。デフォルトでstrict: trueなのは最高ですね。ビルドステップがない昨今のNode開発環境ではほぼ確実に必要となるWebpackやesbuildなどのビルドツールも不要です。僕自身はビルドツールの設定に拘ったり全ての設定の意味を調べて必要なものを吟味することが好きなんですが、サクッとアプリを作りたいときにはそれが時間泥棒になってしまう場合があるので、何も設定が必要ないのはプロダクト作成に時間とエネルギーを割くことができて良いですね。Freshで作成したアプリをDeno DeployにデプロイするようにGitHub連携しておくと、mainブランチをプッシュした直後にアプリケーションがデプロイされReady状態になります。よくみてみると、Deno Deployのプロジェクトページにビルドの画面はありません。これがゼロビルドステップの力か〜と感動しました。Next.js風のファイルシステムルーティングFreshはNext.jsと同じようなファイルシステムをベースとしてルーティングを採用しています（Fresh公式でもそのように謳っています）。例えばroutes/hoge.tsxを作成したら、/hogeにアクセスできるようになります。Next.jsであればpages/配下ですが、Freshではroutes/配下であれば、APIリクエストをハンドリングしたり（一般的にはrouters/api/配下に定義しますが任意です）、JSXを返してHTMLのページをレンダリングするすることができます。公式ドキュメントの表がわかりやすいので参考にしてみると良いでしょう。import map を使ったパッケージ管理システムDenoではimport時に直接URLを書いてしまう方法の他、パッケージ管理を行う手法としてdeps.tsを使う方法とimport mapを使う方法の二種類があるようですが、Freshの新規プロジェクトではデフォルトでimport mapを使った方法が採用されています。これはプロジェクト内にimport_map.jsonファイルを置いて依存を解決する仕組みです。code:import_map.json {   "imports": {     "$fresh/": "https://deno.land/x/fresh@1.0.2/",     "preact": "https://esm.sh/preact@10.10.0",     "preact/": "https://esm.sh/preact@10.10.0/",     "preact-render-to-string": "https://esm.sh/preact-render-to-string@5.2.1?external=preact",     "rss-parser": "https://esm.sh/rss-parser@3.12.0"   } }インポートしたいESモジュールのURLに対して、任意の名前をキーとしたJsonを定義します。このようなファイルをプロジェクトルートに配置したのち、deno.jsonにファイルパスを明記してあげると、このファイルを使って依存を解決してくれます（実行コマンドの引数に--import-map ./import_map.jsonと指定する方法もあります）。code:deno.json {   ...   "importMap": "./import_map.json" }実際のコードでは以下のようにインポートして使います。code:main.ts import { HandlerContext, Handlers } from "$fresh/server.ts"; // https://deno.land/x/fresh@1.0.2/ import Parser from "rss-parser"; // https://esm.sh/rss-parser@3.12.0DenoはNodeとの互換性がないため、現状はNode用に作成されたnpmのパッケージをそのまま使うことはできません（3ヶ月以内には80%〜90%のnpmパッケージを簡単に使えるようにする計画がブログで公表されました）。そこで、npmパッケージを使いたい場合は以下の順番で試してみると良いです。1. https://deno.land/x にホスティングされていないか調べるdeno.land/x はDeno用モジュールのホスティングサービスです。lodashやdayjsなどの人気なパッケージはすでに公開されているようです。今回使ってみたFresh自身もここにホスティングされています。import_map.jsonのURLにhttps://deno.land/x/{パッケージ名}@{バージョン}と書いて使います。2. ESM形式で、Deno用にビルドされたパッケージを配布してくれるCDNを使う前回のRSSフィードを作成するときは、rss-parserというnpmパッケージを使うために https://esm.sh というCDNを利用しました。ブラウザでhttps://esm.sh/{パッケージ名}にアクセスすると、https://esm.sh/{パッケージ名}@{バージョン}にリダイレクトされるので、それをURLとしてimport_map.jsonに書いてあげましょう。実は、DenoにはNode互換のパッケージが存在しており、Node専用のモジュールをNode互換のモジュール呼び出しに置き換えることにより使える場合があり、その仕組みを使ってDeno用モジュールを配布できるCDNのうちの一つがesm.shです。ちなみに、依存パッケージの更新管理はdependabotやrenovateがよく使われますが、Denoではuddというツールがよく使われているようです。しかし、現状はesm.shのURL形式を完全にサポートできていないため、今回は使いませんでした。今後のアップデートが待たれるところです。クライアントサイドJSを動かすための仕組みFreshはインタラクティブなページを実装するための仕組みとしてアイランドアーキテクチャを採用しています。基本的に全てのコンポーネントはサーバサイドでレンダリングされますが、islands/配下に定義したコンポーネントだけはクライアントサイドで埋め込まれレンダリングされる仕組みです。動的なコンポーネントだけはファイルシステムで孤立・分離させることでクライアントサイドJSの量を最小限に抑えられますし、影響がそのコンポーネントに閉じるように工夫されています。まとめ一部の内容はFreshというよりDenoの良いところを語ってしまいましたが、Freshは軽量で薄いフレームワークのため、初めてDenoを触ってみたい方には最適なフレームワークのうちの一つではないかと思いました。次はislands/をゴリゴリ使ったアプリやPreactをガッツリ使うもの、ある程度大きめのページも作ってみたいです。Freshに関してより詳細な情報を知りたい方は、https://fresh.deno.dev/docs/concepts を眺めてみてください。Freshの考え方が簡潔にまとまっています。 < Twitter でシェア参考 Fresh - Deno の 次世代 Web フレームワーク Effective Deno Deno v1.15で導入されたNode.js互換モードについて宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

Fresh - DenoのWebフレームワークを触ってみた特徴と所感

大稻埕/迪化街#Deno #Fresh #RSS #Deno_Deployはじめに私が所属するモニクルでは、開発チームの各メンバーが書いた技術ブログをまとめたサイトがあります。https://developers.monicle.co.jp/まとめサイトを作るに至った経緯や、作成の流れについては同僚の/wadata/nkzn.iconnkznさんが書いたこちらの記事が参考になります。さて、私はScrapboxのまさにこのプロジェクトに記事を書いているのですが、オーナー（つまり自分自身）のアカウントでログインしていると、一般的に他のブログページにある、いわゆる「閲覧モード」が存在せず、記事の閲覧と編集を常に行うことができます。それがScrapboxのいいところの一つではあるのですが、カジュアルに記事を修正して行った時に起きてしまった悲劇と、それをDeno Freshで解決してみた話を紹介します。wada-blog が上位を独占？！ある日、ふと技術ブログまとめサイトをみたところ、自分が過去に書いた記事がすべて新着記事として上位に上がってきてしまう事態が起きていました。なぜこんなことになってしまったのかと考えてみたのですが、一つ心当たりがありました。それは「過去に書いた記事を一気に編集してしまった」ことでした。ちょうどこの時Scrapboxでカスタムのスタイルを当てて見た目を変更していたため、古い記事のタグの配置を変えたりしてレイアウトを整えていました。それが仇となり、過去記事が上位を独占してしまいメンバーに申し訳ない気持ちになりました。そこで、まずは根本的な原因を調査することにしてみました。Scrapbox の RSSフィード は RSS 2.0 ベース技術ブログまとめサイトでは、各個人のブログページのフィードを登録して新着記事を取り込むようになっています。RSS 1.0/2.0, ATOMの仕様が存在しますが、どの仕様に準拠したRSSでもパース可能なrss-parserを使ってJS Objectに変換した上で記事の発行日時にソートしています。また、ScrapboxのRSSはRSS 2.0を使っているようです（wada-blogのRSS）。RSS 2.0 の仕様を読んでみると、各記事を表現するitem要素の中にある日時はpubDate(発行日時）しかありません（ちなみに、ATOMの仕様には作成日時と更新日時という項目があります）。また、Scrapboxの記事を更新した場合はpubDateが更新されるということも判明しました。これを根拠にしてデータを定期的に都度作成している技術ブログまとめサイトでは、Scrapboxで編集した記事の発行日時が更新されて新着記事に上がってしまうということがわかりました。pubDate だけを上書きしたRSSフィードが欲しいここで、まずはこの問題を解決する方法を考えてみました。ScrapboxのRSS自体は、自分ですぐに触れるものではないのでどうしようもありません。また、技術ブログまとめサイトのロジックを変えることも検討しましたが、まとめサイト側で作成日時がわかるデータを保持していないため、すぐにはできそうになく諦めました。そこで、ScrapboxのRSSのうち、pubDateだけ作成日時に差し替えたRSSサーバを別途立ち上げることを検討しました。Scrapboxには、RSSとは別にAPIも存在していてページの一覧をGETで取得することができます（wada-blogのAPI）。このAPIレスポンスには各記事の情報の中に作成日時が含まれるため、発行日時だけ差し替えたRSSアプリを構築することができそうです。Deno の Fresh を使って爆速でRSSフィードを実装するそこで、今回はDeno用のWebフレームワークであるFreshを使ってRSSフィードを実装してみることにしました。Freshは2022/07/28 に1.0がリリースされたばかりの新しいフレームワークで非常に軽量です。クライアントに送信するJSはデフォルトで0KBで、リクエストに応じて edge サーバでレンダリングをして返すのが特徴です。まだ安定版がリリースされたばかりのため、プロダクションで使われているケースはあまり多く知りませんが、フレームワークの特徴からしても静的なLPや動きの小さなWebページには適していて、実際にDeno公式ブログでは使われているようです。今回作成するアプリは1ページのみで xml を返すだけなので、フレームワークとしてはなるべく小さくて開発体験が高速なツールがいいなと思っていました。その点でFreshはWebpack等のプレビルドを行う必要がないためアドバンテージがありました。また、ファイルベースルーティングを使用している点も気に入りました。私は普段Next.jsベースのアプリケーションを開発しているため、同じシステムを採用しているのは馴染みやすいです。もちろん、ただ単純にDenoやDeno Deployを使ってみたかったという理由もかなり大きいです。そして、です。https://rss-proxy.deno.dev/api/scrapbox/wada-blogソースコードはこちらにアップしています。https://github.com/sugoi-wada/fresh-rss-proxy作り始めてから数時間で無事に最低限の実装が出来上がりました。本当にpubDateを差し替えただけのミニマムな実装です。デプロイ先にはDeno Deployを利用しています。プッシュした後にビルドステップを踏まずにデプロイが終わるのは凄くいい体験ですね。RSSを切り替えてまとめサイトを再度確認してみると、wada-blogが元々あった場所に収まってくれていました。これで一安心。まとめ今回は、意外なところからRSSフィードを作ることになった経緯とその結果を中心にまとめてみました。次回は、Freshを使う上で調べたことについてまとめていきたいと思います。それでは！宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

技術ブログまとめサイトに wada-blog が上位独占してしまったので Deno Fresh で直した話

七海: https://ccklibrary.org.tw/w/zh_tw/index#Homebrew #Brewfileはじめに今まで利用していたPCはIntelのMacBookPro16インチでしたが、今回新たにM2のMacBookProを入手したので、セットアップについての備忘録を残したいと思いました。最近では多くの方が、タイムマシーン等を使ってSSDの中身を丸ごと移動するような方式をとっているかもしれませんが、私は綺麗な環境からスタートしたい気持ちが強く、そのような方法はとっていません。また、Intel版とApple Sillicon版の違いにより、別々に配布されているバイナリは丸ごと移行して欲しくない場合もあるでしょう。ということで、今回は Homebrew の Brewfile を使ったアプリの管理方法について紹介します。なお、初回の執筆時の環境はこちら。 旧: Intel MacBookPro 新: M2 MacBookPro Homebrew 3.5.9Homebrewのインストールはこちらから済ませておいてください。旧Macで準備することBrewbundleを使って新Macを使うためにはその元となるBrewfileが必要なので、それを準備します。Homebrew でアプリをインストールするまずは今使っているMacでインストールしているアプリをなるべくHomebrewでインストールしておくと良いでしょう。また、Macアプリの場合は--caskオプションをつけることでHomebrewにアプリを管理させることができます。code:zsh brew install app_name brew install --cask mac_app_nameちなみに、Macアプリの場合はUIからアップデートしないようにしておくと良いでしょう。Homebrewの管理が外れます。アップデートしたい場合は--greedyオプションを使います。code:zsh brew update && brew upgrade --greedyMac App Store のアプリについてmasというツールを使うことで、Mac App Store のアプリもBrewfileで管理できるようになりますが、認証面の問題で少し使いにくく、コツがいるため今回の説明からは省きますが、興味がある人はやってみてください。Brewfile の作成使っているアプリをHomebrewで管理することができたら、あとはbrew bundle dumpコマンドを使ってダンプファイルを書き出します。code:zsh brew bundle dump --global --forceホームディレクトリに .BrewfileができていればOK。中にはテキストでbrew installされているファイルが書かれています。ちなみに、masを使った人はMac App Storeのファイルも書かれています。GitHubのリポジトリ等に保存.Brewfileの保存先はどこでもいいですし、ファイル共有ソフトで管理するだけでもいいですが、今後も定期的にダンプして差分を更新していくことを考えるとGitでどこかのリモートリポジトリにプッシュしておくのがおすすめです。また、本題からはそれますが.zshrcや.gitconfigなども入れておくと良いでしょう。私はこれらのファイルを.dotfilesディレクトリに置いて、シンボリックリンクを使ってホームディレクトリに配置しています。Gitを使う場合は~/.dotfilesをコミットしてリモートリポジトリにプッシュすればOK。code:zsh mkdir ~/.dotfiles mv ~/.Brewfile ~/.dotfiles/.Brewfile ln -s ~/.dotfiles/.Brewfile ~/.Brewfile  # .zshrc 等を含む複数の隠しファイル（.から始まるファイル）をシンボリックリンクする場合は以下 ls ~/.dotfiles/.* | xargs -I{} basename "{}" | xargs -I{} ln -s ~/.dotfiles/{} ~/{}新Macで準備することさて、ここから新しいMacでのセットアップを始めます。Homebrewのインストールは済ませておいてください。Brewfile の取得と配置まずは保存した.Brewfileを新しいMacで取得します。git cloneをしたり、zipでダウンロードしたものを解凍したり、どんな方法でも構いません。その後、旧Macと同じ状態を作るため、ホームディレクトリ直下に.dotfilesを置いて、その中に.Brewfileを配置するのが良いでしょう。その後、同じようにシンボリックリンクを貼ります。Brewfile を元にアプリをインストールこれで準備は完了です。あとはbrew bundleコマンドを使ってインストールしていきましょう。code:zsh brew bundle --file=~/.Brewfileネットワーク状況にもよりますが、相当な時間がかかる場合があります。またたまにパスワード入力を求められて止まるので気にしてあげてください。以上！宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

新しい Mac を手に入れたらまずやること [Brewfile編]

#ベロシティ #スクラム #見積もり #アジャイル #ストーリーポイントはじめに私が所属するチームではスクラム型のソフトウェア開発（アジャイル開発と呼ぶかもしれません）を行っています。具体的には、各スプリントを始める前に、作業チケットにストーリーポイントで見積もりをしてスプリント内で終わらせることができそうな範囲を見極めます。見極めのためには過去のベロシティが参考になります。なぜなら、チームがこれまでのスプリントでどの程度のストーリーポイントを消化できたのかを確認できるからです。さて、今回はそんな指標として用いられるベロシティや見積もりについての考え方や、チーム内で実践していること・工夫していることをまとめます。この話は私が所属するチームにおける内容であり、一つの考え方・事例として参考にしてください。ベロシティは実績であるそもそもベロシティとは何か？というと、スクラムチームが1回のスプリントでDone（完了）にしたストーリーポイントの合計値です。言い換えると、1回のスプリントで見積もりした作業がどのくらいできたかの実績をあらわします。そして、各スプリントごとのベロシティを見てみるとある程度の傾向が見えてきます。安定・上昇・下降・乱高下くらいのパターンに分かれるでしょうか。この数値や傾向を見ると何がわかるのでしょうか？ベロシティを計測するワケは、不確実性の削減にあるベロシティの見方を考える前に、ベロシティを測る意味について考えてみます。その答えはズバリ「未来の予測可能性を高めること」にあります。ある機能を追加するとき、それが1週間で終わるのか、1ヶ月で終わるのか、3ヶ月で終わるのかは誰もが知りたいことです。アジャイル開発では、ベロシティがその役割を担っています。例えば、過去のベロシティ平均が15だったチームでは、各スプリントで15ポイントのタスクを消化できるので、ある作業を見積もった時に30だったのであれば、おそらく2スプリントかかるだろうと予測できます。私のチームでは1スプリントが1週間なので、2週間かかることが推測できます。このようにして過去の経験から未来の不確実性を少しでも削減するためにベロシティを計測します。この内容から以下のことがわかります。 ベロシティを計測するためには、見積もりが不可欠である ベロシティ（平均）が安定していなければ意味がない  ベロシティが乱高下している場合、次のスプリントでどのくらいのポイントが消化できるかがわからないベロシティは価値提供の速度である日々の業務をこなす中で、緊急対応を迫られる場合があります。クリティカルなバグが発見されて調査や修正が必要になったり、データの修正や集計が必要になった場合です。また、緊急ではないけれどリファクタリングをしたり簡単なバグ修正をすることもあるでしょう。このような作業チケット（ストーリー以外のチケット）にはストーリーポイントをつけないようにしています。この背景には、ベロシティは（顧客への）価値提供の速度であるという考えに由来しています。前提としてアジャイル開発ではバグの発生やリファクタリングの必要性を最小限に抑えるようなコーディングを心がけるように考えられているため、バグ修正やリファクタリングの作業は負債であると考えます。もしも、ベロシティが毎週のように下がっていた場合はストーリーチケットが消化できていないことになります。その理由をチームメンバーで考えます。例えば以下のような原因が考えられます。 バグが多く、バグの調査や修正に時間がかかっている  → アプリケーションの品質が下がっているなら、上げる工夫ができないか考える  → 設計に問題があるなら、改善案について話し合う  → 調査に必要なログ基盤が不完全なら、ログ基盤の強化について考える リファクタリングや設計の見直しをするのに時間がかかっている  → ベロシティを下げてもやることに理解が得られるように話し合う  → スプリントにどのくらいの割合で、直接価値提供をするわけではないが、後の業務が楽になるなどの利益があるチケットをやるべきかを話し合い合意する 見積もり以上に時間がかかっている  → 実際にやってみないと（調査してみないと）わからない作業チケットについては調査自体を別チケットにして、解像度を上げてから再度チケット分割する  → 影響範囲が見積もり時より広く時間がかかりそうな場合は、メンバーと共有した上でチケットの分割や再見積もりについて検討する スプリント中に作業の差し込みが多すぎる  → 作業の優先度に変更がないか確認する  → 差し込み作業をやることでスプリントの目標が達成できない可能性が上がることについて確認する  → スプリントを閉じて仕切り直しを検討する  → スプリントの期間を短くしてみるベロシティからこのような問題点を発見し原因を追求して改善していくことによってベロシティの安定化（障害が取り除かれ、自然と緩やかに上昇することも良いでしょう）に繋がります。終わりに元々は社内向けにまとめていた記事を改めて整理して大幅に加筆しました。ベロシティを考える上では見積もりも重要なトピックなのですが、また機会があれば書いてみようと思います。まだまだ手探りな点もありますが、一つの考え方として参考にしていただければ幸いです。

ベロシティを測ることの意味と見方の考察

#Ruby #Rails #トランザクションはじめに説明の内容や開発環境は Rails 7、PostgreSQL を前提としています。with_lock についてRailsには、モデルに行ロックをかける（クエリレベルで言うとSELECT ~ FOR UPDATEをする）方法として、model_name.with_lock(&block)というメソッドが用意されています。これを使うことによって、ブロックの内部では行ロックがかかり排他制御された状態で処理を記述することができます。code:with_lock_sample.rb book = Book.first book.with_lock do   # このブロックはトランザクション内で呼び出される   # bookはロック済み   book.increment!(:views) end引用: Rails ガイド - 悲観的ロックただし、引用した上記のサンプルコードにもコメントで書かれている通り、ブロック内部はトランザクション内で実行されることに注意してください。code:with_lock_sample2.rb book = Book.create!(title: "Book 1") pp "start" book.with_lock do   pp "with_lock start"   book.update!(title: "Book 1 Updated")   Paper.create!(title: "Paper 1")   pp "with_lock end" end pp "end"上記のサンプルコードを見ると、bookオブジェクトに対してwith_lockブロックを囲っているため、ブロック内部ではbookレコードに行ロックがかかり、それとは関係のないPaperモデルに関してはPaper.create!の直後にコミットされるように見えますが、実際にはそうではありません。実行結果は以下のようになります。code:with_lock_sample2_result.rb TRANSACTION (0.1ms)  BEGIN  Book Load (0.4ms)  SELECT "books".* FROM "books" WHERE "books"."id" = $1 LIMIT $2 FOR UPDATE    "with_lock start"  Book Update (0.2ms)  UPDATE "books" SET "title" = $1, "updated_at" = $2 WHERE "books"."id" = $3    Paper Create (0.5ms)  INSERT INTO "papers" ("title", "created_at", "updated_at") VALUES ($1, $2, $3) RETURNING "id"    "with_lock end"  TRANSACTION (0.3ms)  COMMITRailsのソースコードを読んでもトランザクションが作られていることがわかります。https://github.com/rails/rails/blob/04972d9b9ef60796dc8f0917817b5392d61fcf09/activerecord/lib/active_record/locking/pessimistic.rb#L92-L95試しに、with_lockのブロックが終わる前に別のスレッドからPaperレコードをクエリで呼び出してみると、コミットされていないのでエラーになることがわかります。code:with_lock_sample3.rb book = Book.create!(title: "Book 1") book.with_lock do   book.update!(title: "Book 1 Updated")   paper = Paper.create!(title: "Paper 1")   Thread.start {     pp Paper.find(paper.id)   }   sleep 1 endcode:with_lock_sample3_result.rb TRANSACTION (0.1ms)  BEGIN Book Load (0.5ms)  SELECT "books".* FROM "books" WHERE "books"."id" = $1 LIMIT $2 FOR UPDATE   Book Update (0.4ms)  UPDATE "books" SET "title" = $1, "updated_at" = $2 WHERE "books"."id" = $3   Paper Create (0.5ms)  INSERT INTO "papers" ("title", "created_at", "updated_at") VALUES ($1, $2, $3) RETURNING "id"   Paper Load (0.4ms)  SELECT "papers".* FROM "papers" WHERE "papers"."id" = $1 LIMIT $2   #<Thread:0x000000010a917480 (irb):5 run> terminated with exception (report_on_exception is true): /Users/username/.anyenv/envs/rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/activerecord-7.0.3.1/lib/active_record/core.rb:284:in `find': Couldn't find Paper with 'id'=6 (ActiveRecord::RecordNotFound)         from (irb):6:in `block (2 levels) in <main>' TRANSACTION (0.8ms)  COMMIT => 1 まとめ行ロックはトランザクションがコミットされるまでの間維持されるため、トランザクションを作ることを知っていれば当たり前のことですが、Railsのコードを読む時にはついついモデル単位でそのオブジェクトを捉えてしまい、思わぬ勘違いをしてしまうことがあります。今回はその一例を紹介しました。それでは楽しいRailsライフを！

Rails: with_lock のブロックはトランザクション内で呼ばれる

#Ruby いきなりですが、TypeScript で以下のような関数を書いてみました。実行結果はどうなるでしょうか。code:sample1.ts function sample1(array: number[]): { result: string[] } {   const result = array.map((num) => {     if (num % 2 === 0) return ${num} は偶数     if (num % 2 === 1) return ${num} は奇数      return ${num} は偶数でも奇数でもない   })      return { result } }  console.log(sample1(Array.from({length: 10}, (v, i) => i)))実行結果は以下のようになります。resultをキーとした、文字列配列（10件分）のオブジェクトが入っていますね。{  "result": [    "0 は偶数",    "1 は奇数",    "2 は偶数",    "3 は奇数",    "4 は偶数",    "5 は奇数",    "6 は偶数",    "7 は奇数",    "8 は偶数",    "9 は奇数"  ]} さて、これをそのまま Ruby に置き換えて書いてみました。しかし、一つ大きなミスを犯しています。どこが間違いかわかるでしょうか。また、実行結果はどうなるでしょうか。ちなみに、本記事の Ruby バージョンは3.1.2を使用しています。code:sample1.rb def sample1(array)   result = array.map do |num|     return "#{num} は偶数" if num % 2 == 0     return "#{num} は奇数" if num % 2 == 1      "#{num} は偶数でも奇数でもない"   end      { result: } end  p sample1(10.times)実行結果は以下のようになります。"0 は偶数"この実行結果を見るとわかることとして、10件分の文字列配列が出力されておらず、引数に渡した文字列配列の1件目のデータである 0 が map ブロックの引数に渡され、 return "#{num} は偶数" が呼ばれたところで処理が終わっています。つまりreturn句を関数内・ブロック内で呼び出した場合は、その時点でブロックと関数を中断してreturnに渡された値を返します。Ruby のreturn句はブロックも関数も抜けてしまうので、breakで書き直してみます。以下の実行結果はどうなるでしょうか。code:sample2.rb  def sample2(array)    result = array.map do |num|      break "#{num} は偶数" if num % 2 == 0      break "#{num} は奇数" if num % 2 == 1        "#{num} は偶数でも奇数でもない"    end        { result: }  end  p sample2(10.times)実行結果は以下のようになります。{:result=>"0 は偶数"}先ほどとは違い、resultをキーとしたハッシュオブジェクトが出力されるようになりました。ただ、値は相変わらず0は偶数という文字列のみです。つまり、break句を関数内・ブロック内で呼び出した場合は、ブロックを中断してbreakに渡された値を返しますが、関数は引き続き実行されます。中断する範囲がreturn句とは異なることに加えてbreak句が値を返すことができるというのも特徴的なポイントと言えます。break句で一歩前進したものの、依然としてresultの値が文字列配列になっていないのでnextで書き直してみました。code:sample3.rb  def sample3(array)    result = array.map do |num|      next "#{num} は偶数" if num % 2 == 0      next "#{num} は奇数" if num % 2 == 1        "#{num} は偶数でも奇数でもない"    end        { result: }  end  p sample3(10.times)実行結果は以下の通りです。{:result=>["0 は偶数", "1 は奇数", "2 は偶数", "3 は奇数", "4 は偶数", "5 は奇数", "6 は偶数", "7 は奇数", "8 は偶数", "9 は奇数"]}ようやくresultの値が10個の文字列配列をもつハッシュオブジェクトになりました。この実行結果を見るとわかることとしてnext句はブロックのループ処理は中断せず、呼ばれた際にブロック内部の後続処理をスキップします。また、breakと同様にnextも値を返すことができます。ここでわかったことをまとめます。 return: ブロックのループ処理も関数も中断して値を返す break: ブロックのループ処理を中断して値を返す next: ブロック内のループ処理結果として値を返し、次のループを開始する（ループ処理は中断されない）さまざまな言語に触れていると、このような微妙な条件の違いに混乱し時に思わぬ結果をもたらします。このようなミスを犯さないように、実務ではテストコードを書いていくことが大切です。冒頭のTypeScriptの例で言えば、breakやcontinueに渡せるものとしてラベルがあります。ラベルを使うことで、どの範囲のブロックを中断するかを明示的に指定することができます。TypeScriptのラベルについてはこちらを参照してください。Rubyには、breakやnext句にラベルを使って中断先を明示的に指定することはできませんが、代わりにcatchとthrowを組み合わせて似たようなことができます。code:label.rb catch (:done) do   5.times { |i|     5.times { |j|       puts "#{i} #{j}"       throw :done if i + j > 5     }   } endhttps://stackoverflow.com/a/1352143 より引用あまりこのようなコードを目にする機会は多くないかもしれませんが、覚えておくと良いかもしれません。

Hikaru Wada

禅と暮らす一週間。体験記最終日 2024年秋

禅と暮らす一週間。体験記六日目 2024年秋

禅と暮らす一週間。体験記五日目 2024年秋

禅と暮らす一週間。体験記四日目 2024年秋

禅と暮らす一週間。体験記三日目 2024年秋

禅と暮らす一週間。体験記二日目 2024年秋

禅と暮らす一週間。体験記初日 2024年秋

禅と暮らす一週間。一日一食断食と仏教体験レポート修行概要編 2024年秋

禅と暮らす一週間。一日一食断食と仏教体験レポート準備編 2024年秋

今更Railsのautoloadingとeager loadingを理解する

Rails で Minitest を使って悲観的ロック（排他制御）をテストする方法

モニクルにジョインして4年が経ちました

2024年03月の台湾ワーケーション記録

ライムリゾート箱根はいいぞ

認定スクラムマスター研修に参加して印象に残ったこと

JiraとScrapboxとFigJamの使い分けTips

Fragment Masking で Fragment Colocation を強制する

GraphQLクエリをCDNキャッシュに載せたい

GraphQL の Persisted Queries について

Fresh - DenoのWebフレームワークを触ってみた特徴と所感

技術ブログまとめサイトに wada-blog が上位独占してしまったので Deno Fresh で直した話

新しい Mac を手に入れたらまずやること [Brewfile編]

ベロシティを測ることの意味と見方の考察

Rails: with_lock のブロックはトランザクション内で呼ばれる

Ruby の return に注意しながら next と break をうまく使い分ける

禅と暮らす一週間。体験記 最終日 2024年秋

禅と暮らす一週間。体験記 六日目 2024年秋

禅と暮らす一週間。体験記 五日目 2024年秋

禅と暮らす一週間。体験記 四日目 2024年秋

禅と暮らす一週間。体験記 三日目 2024年秋

禅と暮らす一週間。体験記 二日目 2024年秋

禅と暮らす一週間。体験記 初日 2024年秋

禅と暮らす一週間。一日一食断食と仏教体験レポート 修行概要編 2024年秋

禅と暮らす一週間。一日一食断食と仏教体験レポート 準備編 2024年秋

今更Railsのautoloadingとeager loadingを理解する

Rails で Minitest を使って悲観的ロック（排他制御）をテストする方法

モニクルにジョインして4年が経ちました

2024年03月の台湾ワーケーション 記録

ライムリゾート箱根はいいぞ

認定スクラムマスター研修に参加して印象に残ったこと

JiraとScrapboxとFigJamの使い分けTips

Fragment Masking で Fragment Colocation を強制する

GraphQLクエリをCDNキャッシュに載せたい

GraphQL の Persisted Queries について

Fresh - DenoのWebフレームワークを触ってみた特徴と所感

技術ブログまとめサイトに wada-blog が上位独占してしまったので Deno Fresh で直した話

新しい Mac を手に入れたらまずやること [Brewfile編]

ベロシティを測ることの意味と見方の考察

Rails: with_lock のブロックはトランザクション内で呼ばれる

Ruby の return に注意しながら next と break をうまく使い分ける

禅と暮らす一週間。体験記最終日 2024年秋

禅と暮らす一週間。体験記六日目 2024年秋

禅と暮らす一週間。体験記五日目 2024年秋

禅と暮らす一週間。体験記四日目 2024年秋

禅と暮らす一週間。体験記三日目 2024年秋

禅と暮らす一週間。体験記二日目 2024年秋

禅と暮らす一週間。体験記初日 2024年秋

禅と暮らす一週間。一日一食断食と仏教体験レポート修行概要編 2024年秋

禅と暮らす一週間。一日一食断食と仏教体験レポート準備編 2024年秋

2024年03月の台湾ワーケーション記録