2025年9月6日から11日まで、ウズベキスタン（サマルカンド、ブハラ、タシュケント）を旅しました。その旅行記の2日目です。2025年9月ウズベキスタン旅行記 【準備編】2025年9月ウズベキスタン旅行記 【1日目 タシュケント】2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】 ← ここタシュケント駅そばのカフェ早朝4:30に起床。まだ日は明けてない。シャワーを浴び、荷物をまとめてチェックアウト。昨日頼んでおいた朝食を受け取り、駅までの道を教えてもらう。ホテルを出ると、外は明るくなり始めていた。駅までは歩いて10分ほどで到着。駅の入口には、空港のような手荷物検査があった。荷物をX線装置に通し、金属探知のゲートを通過する。すごく厳重だ。ソ連時代の名残りなのかな？駅の中のコーヒースタンド駅の中にコーヒースタンドがあったので、列車に乗り込む前にコーヒーを買った。ドリップコーヒーが飲みたかったが、「カプチーノ？アメリカーノ？」と聞かれたので、アメリカーノを頼む。ウズベキスタンではドリップコーヒーはあまり飲まれないのかも。改札で、印刷しておいたチケットを駅員に見せてプラットフォームに出ると、これから乗る列車が停車していた。車両を確認して乗り込む。しかし、予約していた座席には別の人が座っていた。「あれ、車両を間違えたかな？」と戸惑っていると、通りかかったおばさんが「チケットを見せてごらんなさい」と助けてくれた。「あっちの車両よ、あっち」と教えてくれたので、お礼を言って隣の車両に移動する。しかし、そちらの車両の席にもすでに他の人が座っている。混乱してたら、そのおばさんがまたやってきて「もう一つ隣の車両じゃない？」と言う。しかし、近くに座っていた若者は「いや、反対の車両だよ」と言う。困っていると車掌が通りかかった。チケットを見せると「あっち（元の車両）だ」。車掌と一緒に元の車両に戻る。やはり予約している席に座っている人がいる。車掌が声を掛けると、座っていた人たちが一斉に立ち上がり、「ほら、やっぱり言ったじゃない」といった感じで別の車両に移動していった。そんなこんなでようやく腰を落ち着けることができた。ふぅ、やれやれ。さっきのおばさんが通りかかって、申し訳なさそうに「ごめんなさいね」と謝ってきた。いえいえ、親切にありがとうございました。ウズベキスタンの人たちは、少し控えめだけど、とても親切で、どこか日本人と通じるところがあるような気がした。プラットフォームの様子程なくして、列車は音もなく動き出した。朝日がまぶしいしばらくすると、ワゴンがやってきて、無料のお茶と軽食が配られた。こんなことなら、コーヒー頼まなくてよかったな。緑茶（Green Tea）と紅茶（Black Tea）が選べたが、ウズベキスタンでは緑茶が好んで飲まれるという話だったので、緑茶を選んだ。緑茶をチョイス軽食が入った袋。中にはデニッシュとチョコレートが入っていたホテルでもらった朝食の紙袋をあけると、サンドイッチが入っていた。食パン2枚でかなりボリュームがある。野菜もたっぷりで美味しい。お腹いっぱいになったので、列車で配られたデニッシュとチョコレートは、非常食として取っておくことにした。ボリュームたっぷりのサンドイッチ朝が早いということもあり、車内はのんびりとした空気が流れている。約4時間の長距離移動なので、時間を持て余すかなと思っていたが、車窓の景色が素敵すぎてまったく飽きることがない。ずっと眺めていた。定刻通り、10:00過ぎにブハラ駅に到着。プラットフォームに降り、みんなが歩いていく方向について行く。みんなについていけばなんとかなるでしょう出口のゲートを過ぎると、タクシーの客引きがたくさん待ち構えていた。タクシーの客引きが待ち構える「タクシー？タクシー？」という声を振り切って、Yandex Go でタクシーを呼ぶ。配車アプリは日本でも使ったことがないので、なんとなく緊張。一番安いのを選んで10分ほど待つ。地図にタクシーの位置がリアルタイムで表示されるのでわかりやすいが、到着地点に他の車がたくさん停まっているので焦る。ナンバープレートを頼りになんとか見つけたら、すごく小さく、トランクもないような車だった。ま、いいでしょ。助手席にスーツケースを載せて、後部座席に体を押し込む。クーラーはないけど、窓から吹き込んでくる風が気持ちいいブハラ駅から旧市街にあるホテルまで30分ほど。25500 UZS（300円くらい）だった。ホテル周辺はかなり細い路地で、車での通行は厳しい感じだ。図らずも小さい車がこんなところで活きるとは。Minzifa Boutique Hotelの外観予約していたホテルは、Minzifa Boutique Hotel。レギスタン広場の南側にあるゲストハウス街の中にあるホテルだ。高い壁に囲まれていて、門をくぐると、古いけど趣のある建物が並んでいた。レセプションにいた若者に声をかける。英語が通じるので安心。チェックインは14:00からとのことなので、荷物を預かってもらい、さっそくブハラの街を散策することにした。（つづく）関連記事【ウズベキスタン旅行】両替の悩みをWiseで解決した話【ウズベキスタン旅行】持っていってよかったものと持っていかなくて後悔したもの【ウズベキスタン旅行】クレジットカードが使えた場所、現金しか使えなかった場所2025年9月ウズベキスタン旅行記 【準備編】2025年9月ウズベキスタン旅行記 【1日目 タシュケント】

2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】

2025年9月5日から11日まで、ウズベキスタン（サマルカンド、ブハラ、タシュケント）を旅しました。その旅行記の1日目です。2025年9月ウズベキスタン旅行記 【準備編】2025年9月ウズベキスタン旅行記 【1日目 タシュケント】 ← ここ2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】今回の旅のために新調したバックパック関西国際空港から仁川国際空港へまずはアシアナ航空OZ111便で、関西国際空港から韓国の仁川国際空港に向かう。前日から台風15号が近づいており、ちょうど出発の時間に近畿地方に近づく予報だったため、フライトが遅延したり、最悪欠航になるのではと心配していたが、特に影響もなく定刻通り10:50に出発することができた。フライト時間は1時間50分。乗り換えだけだが、初めての韓国なのでちょっと楽しみ。機内食はプルコギ丼っぽいやつ。日本人の舌にもあう味付けで美味しかった。ぼんやりと外を眺めていると、あっという間に仁川に到着。12:40着。飛行機を降りて、空港に入った途端、見知らぬ文字が目に飛び込んでくる。「異国に来たぞ！」という高揚感に包まれる。たぶん間違いなく消火栓って書いてありそう乗り継ぎの搭乗ゲートに向かうと、これから乗る飛行機がすでに止まっていて、出発のために準備をしている。これから乗る飛行機。よろしくお願いします乗り継ぎ時間は3時間30分もある。コンビニでバナナとサンドイッチを買って食べたりしながら、まだ人気のない搭乗ゲート付近の待合スペースでのんびりと過ごす。緑が多くてゆったりとした待合スペーストイレがかわいいアジア有数のハブ空港だけあって、いろんな目的地に向かうフライトがある仁川国際空港からタシュケントへ出発時刻（16:10）に近づくと、続々と搭乗ゲートに乗客が集まってくる。ウズベキスタン人が6割、その他4割といった感じ。ウズベキスタンを知るための60章によると、「ウズベキスタンには在外朝鮮人（高麗人）が多く住む関係で、韓国政府はウズベキスタン政府との間で労務輸出に関する覚書を結んでいる。韓国では、2007年から2012年までで累計1万8千人の労働者をウズベキスタンから受け入れている」とのこと。もしかしたら、多くの乗客は、帰郷する出稼ぎ労働者なのかもしれない。ある若者は、大事そうにPS5の箱を抱えていた。がんばって働いて、誰かへのおみやげとして（あるいは自分へのご褒美として）PS5を買って地元に帰るところなのかもしれないな、と勝手に妄想しながら、飛行機に乗り込んだ。離陸してから1時間ほどで夕食が提供された。チキンを選ぶとクリーム煮だった。アシアナ航空の機内食は、どれも慣れ親しんだ味で美味しい。飛行時間は7時間50分。結構長い。食事の後、1時間ほどウトウトしたが、まだまだ着かない。外を眺めていると、いつもよりゆっくりと夜が近づいていく。地球の自転に逆らって飛んでいるので、なかなか日が暮れないマジックアワーが長いタシュケントに近づきようやく日が暮れた。タシュケントは想像以上に大都会だったタシュケントに到着。eSIMと現金を入手定刻通り、20:00にタシュケント国際空港に到着。荷物は機内持ち込みのみなので、そのまま入国審査に向かう。パスポートを係員に渡して、カメラに顔を向ける。あっさりと通過。入国後に空港でやるタスクは2つ。eSIMの購入と、現金（UZS）の入手だ。入国ゲートを抜けるとすぐ、通信会社のカウンターがいくつか並んでいる。その中から Beeline のカウンターを選ぶ。（蜂をイメージしたロゴがかわいかったので。）丸いカウンターを観光客が取り囲んでいて、列があるのかないのかよくわからない。手が空いた店員と目があったので、すかさず声を掛ける。一番安いプランを選ぼうとしたら、「お二人は一緒に行動されますよね？だったら、最安のプランを2つ契約するより、こっちのプランを1人が契約して、テザリング（インターネット共有）する方が安くつきますよ。」という提案を受ける。なんて親切な店員。購入したプランの細かい内容は忘れてしまったが、確か150GBで10万UZS（1300円くらい）だった。契約をしてスマホを店員に渡すと、ややこしいセットアップをすべてやってくれた。ありがたい。（ただ、実際に使ってみると、ホテルなどのWiFiにつなぐとテザリングが勝手に切れてしまい、毎回設定し直す必要があって面倒だった。これだったら2人分契約したほうがよかったなと後悔した。）無事に通信手段を手に入れ、次は現金の入手。【ウズベキスタン旅行】両替の悩みを解消するWise活用法で紹介したように、Wiseカードを使ってATMから引き出す。ATMは入国ゲートを背にして左手にあった。100万UZS（12000円くらい）を引き出そうと思っていたが、50万UZSまでしかメニューに出てこなかったので、50万UZS（6000円くらい）を引き出した。ホテルへ移動空港でのタスクを終え、ホテルへ移動する。翌日の早朝に高速鉄道（アフラシャブ号）でブハラへ移動することを考慮して、タシュケント駅（北駅）近くの Corner Hotel を予約していた。このホテルは空港からの無料送迎サービスがあり、予約の際に申し込んでいた。ただ、どこで車を待つのか何も案内がなかったので、「大丈夫かなぁ」と若干不安だったのだが、空港の出口近くのカウンターで自分の名前が書かれたボードを見つけた。声を掛けると、運転手が現れて、ジェスチャーで「ついてこい」と手招きされる。人だかりになっている空港出口を早足で突っ切っていくので、見失わないように急いでついて行く。車はすごくきれいな BYD の電気自動車（EV）だった。運転手は一言も発さないが、親切に荷物をトランクに載せてくれた。運転は少し荒く感じたが、周りの車もそんな感じだったので、たぶんこれがウズベキスタンのスタンダードなんだと思う。初めてのウズベキスタンの街の風景を楽しみたかったが、夜で暗いのであまりよくわからなかった。ただ、開けた窓から入ってくる風が涼しくて気持ちよかった。15分ほど走ってホテルに到着。結局運転中も一言も話さず、「機嫌が悪いのかな」と思ったが、トランクから出してくれた荷物を受け取り、別れ際にウズベキスタン語で「ラフマット（ありがとう）」と言うと、少し驚いたような嬉しそうな顔をしてくれたので、たぶんシャイなだけだったと思う。ちょっと日本人の感覚に似てるのかも。Corner Hotel はその名の通り、交差点の角にあるホテルだった。Corner Hotel の玄関ホテルのフロントには英語が堪能な若者がいて、スムーズにチェックインできた。朝食が無料でつくと言われたが、明日の朝は5:30くらいに出発しなければならず、朝食の時間に間に合わない。takeaway breakfast を用意してもらえるかと頼むと、ボックスを用意しますよと快諾してくれた。部屋は天井が高くて広く、清潔。隣の部屋のテレビが少しうるさかったが、まあいいでしょう。疲れていたし、翌朝も早いので、シャワーを浴びてすぐに寝てしまった。さあ、明日から本格的に旅がはじまる！次の記事2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】関連記事【ウズベキスタン旅行】両替の悩みをWiseで解決した話【ウズベキスタン旅行】持っていってよかったものと持っていかなくて後悔したもの【ウズベキスタン旅行】クレジットカードが使えた場所、現金しか使えなかった場所2025年9月ウズベキスタン旅行記 【準備編】2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】

2025年9月ウズベキスタン旅行記 【1日目 タシュケント】

2025年9月5日から11日まで、ウズベキスタン（サマルカンド、ブハラ、タシュケント）を旅しました。その旅行記の準備編です。2025年9月ウズベキスタン旅行記 【準備編】 ← ここ2025年9月ウズベキスタン旅行記 【1日目 タシュケント】2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】航空券まずは、航空券の予約から。大阪からは直行便がなく、ソウル（仁川）経由が一般的なルートのようです。Google Flights で調べると、アシアナ航空の比較的安いフライトが残り2席で見つかったので、即決。値段は2人で往復約20万円でした。細かい旅程を考える行きと帰りのフライトが決まったので、次に Gemini に相談しながら細かい旅程を考えます。ウズベキスタンで有名な観光地は、サマルカンド、ブハラ、ヒヴァ、タシュケントの4都市。日程上、すべてを訪れるとなると、一つ一つが慌ただしくなって十分に楽しめないので、移動時間がかかるヒヴァは泣く泣く諦めて、サマルカンド、ブハラ、タシュケントの3都市を訪れることにしました。回り方としては、東から西へ（タシュケント → サマルカンド → ブハラ → タシュケント）西から東へ（タシュケント → ブハラ → サマルカンド → タシュケント）の2つのルートが考えられます。Gemini のおすすめは東から西へ向かうルートで、以下のメリットがあると教えてくれました。初日の負担が少ない: タシュケントに到着した翌日、まずサマルカンドに向かいます。高速鉄道で約2時間10分と移動時間が比較的短いため、旅のスタートを無理なく切ることができます。旅のハイライトを早めに楽しめる: サマルカンドの壮大な世界遺産を旅の早い段階で見ることができるため、旅全体の満足度が高まりやすいです。移動の負荷分散: サマルカンド→ブハラ→タシュケントと移動するたびに、徐々に移動時間が長くなっていきます。一方、西から東へ向かうルートは、以下のメリットがあるとのこと。歴史の逆行を体験できる: ブハラはサマルカンドよりも古い歴史を持つ街です。古い時代から徐々に近代的な街へと遡っていくような、歴史の流れを逆行するユニークな体験ができます。後半の移動が楽になる: 旅の後半、サマルカンドからタシュケントへの移動は高速鉄道（アフラシャブ号）で約2時間10分と短いため、最終日の移動が楽になります。お土産の買い物など、タシュケントでの時間をゆっくりと取ることができます。フライトスケジュールとの親和性: 最終日はタシュケントからのフライト（夜21:40発）ですので、日中にサマルカンドからタシュケントへ戻るこのルートは、時間の使い勝手が良いと言えます。ただ、このルートには、初日の負担: タシュケントに到着した翌日の早朝すぐに、高速鉄道でブハラへ向かうことになります。国際線フライトの疲れが残る中で、さらに3時間40分程度の鉄道移動が必要になるため、初日の負担が大きくなります。旅のハイライトが後半に集中: サマルカンドのレギスタン広場や壮大な建築群は、多くの人にとって旅のハイライトとなります。このルートでは、これらの見どころが旅の後半に集中するため、人によっては「後半までお楽しみを待つ」感覚になるかもしれません。というデメリットもあります。一長一短といった感じですが、考えた結果、西から東へ向かうルートにしました。1日目：大阪 → ソウル → タシュケント（タシュケント泊）2日目：タシュケント → ブハラ（ブハラ泊）3日目：ブハラ → サマルカンド（サマルカンド泊）4日目：終日サマルカンド5日目：終日サマルカンド6日目：サマルカンド → タシュケント → ソウル（翌日）7日目：ソウル → 大阪初日の負担は気になりましたが、こちらのほうが6日目にタシュケントでの滞在時間を確保できるというのが大きな理由です。結果的には、旅の疲れが溜まる後半ほど、時間的に余裕のある旅程だったので、このルートで正解だったと思います。高速鉄道（アフラシャブ号）の予約これが一番の鬼門でした。高速鉄道はとても人気で、観光シーズンはすぐに売り切れとなってしまうという情報を得たので、慌ててパソコンで予約サイトを開きました。https://eticket.railway.uz/lang-en/出発1ヶ月前でしたが、タシュケント発着は、ちょうどいい時間帯の便はすでに売り切れ、早朝の便しか残っていませんでした。急いで席を確保しようと、アカウントを登録し、予約しようとするのですが、何度やっても、座席指定の画面から先に進めません。（エラーも出ず、トップページに戻される。）3便分の予約をしなければならないので焦ります。一日置いてみましたが、やはりだめです。何なんだ、この不安定なシステムは...よく見たら、ロゴの横に「BETA」というラベルが。ベータ版なら不安定でもしょうがないかー、とはなりません。鉄道のチケットサイトがベータ版ってどういうことよ。BETAじゃないんだよいろいろと調べてみたら「アプリなら予約できた」という情報を見つけたので、Webサイトでの予約は諦めて、Androidアプリをインストールします。ログインを求められたので、メールアドレスとパスワードを入れたところ、user not found という文字が...まさかWebサイトで作ったアカウントがアプリでは使えない？そんなことはないよなぁ。一日様子を見ましたが、状況は変わらず。覚悟を決めて、アプリでアカウント登録して、座席指定をすると...先に進めます！！やった！！名前やパスポート番号を入力し、確認画面を挟んで、決済画面に進むのですが、今度は読み込みエラーでなかなか決済画面が開きません。何度か試して、なんとか開くことができました。決済方法は、Stripe かクレジットカードを選べますが、恐ろしくてクレジットカード決済なんか選べません。Stripe 一択です。これを3便分繰り返して、ようやくチケットが確保できました。疲れた...ネットでは「簡単だった」という情報もあるので、単に運が悪かったのかもしれません。もし自力でうまくいかなかったら、旅行会社に手配代行を依頼するのも手だと思います。（手数料はかかりますが、これだけ苦労するのであれば払う価値はあるんじゃないかと。）現金の準備ウズベキスタンではクレジットカードが使えない場所が多いので、現金を用意する必要があります。日本円より米ドルのほうが両替に適しているとのことなので、【ウズベキスタン旅行】両替の悩みを解消するWise活用法で紹介した Wise を利用して、70,000円分の米ドルへの両替をしておきました。（キャッシュレス決済 + ATMでの現金引き出し分）ウズベキスタンについて調べる実は、ウズベキスタンに行こうと決めたときには、「サマルカンドには美しいイスラム建築がある」という程度の知識しか持っていませんでした。せっかくなら、歴史や文化、政治など、ウズベキスタンの昔と今について知っておくと、旅をより楽しめるのではと思い、ウズベキスタンを知るための60章という本を購入しました。アレクサンドロス大王の時代から、イスラム化、ソ連時代、ソ連解体後の建国まで、歴史の流れを追うことができます。また、結婚や恋愛、ファッションなど、現代のウズベキスタンの人々の暮らしについても触れられています。タイトルにあるように、第1章から第60章まであり、1章あたり4〜5ページ程度なので、テンポよく読むことができます。この本を読んだことで、出発前からウズベキスタンに対する興味が高まり、旅の最中にも、多面的な視点でウズベキスタンを見ることができました。また、帰国してからあらためて読み直すことで、あとから新しい気づきを得ることもできて、とてもお得な本でした。次の記事2025年9月ウズベキスタン旅行記 【1日目 タシュケント】関連記事【ウズベキスタン旅行】両替の悩みをWiseで解決した話【ウズベキスタン旅行】持っていってよかったものと持っていかなくて後悔したもの【ウズベキスタン旅行】クレジットカードが使えた場所、現金しか使えなかった場所2025年9月ウズベキスタン旅行記 【1日目 タシュケント】2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】

2025年9月ウズベキスタン旅行記 【準備編】

2025年9月5日から11日まで、ウズベキスタン（サマルカンド、ブハラ、タシュケント）を旅行しました。ウズベキスタンでは徐々にキャッスレス決済が普及しているとのことですが、実際に行ってみると、現金しか使えないという場所もまだまだ多かったです。この記事では、今回の旅行の中で、クレジットカードが使えた場所、現金しか使えなかった場所をリストアップします。よかったら参考にしてください。（2025年9月の情報です。）なお、私が利用したカードのブランドは Mastercard です（Wiseカードを利用しました）。ウズベキスタンでは Visa が最も普及しているそうなので、Mastercard が使えた場所であれば Visa も使えると思います。ホテル次の3つのホテルに宿泊したのですが、どのホテルもクレジットカードが使えました。Corner Hotel（タシュケント・4つ星ホテル）Minzifa Boutique Hotel（ブハラ・3つ星ホテル）Mumtoz Hotel（サマルカンド・3つ星ホテル）レストラン・カフェ店の雰囲気がおしゃれだったり、ウェイター・ウェイトレスがおそろいの制服を着ているようなレストラン・カフェでは、クレジットカードが使える印象でした。わかりやすく「ローカルな食堂」といった雰囲気や、家族経営っぽいところは、現金のみでした。💳 クレジットカードOKLabi Hovuz（ブハラ）Cafelova（ブハラ）Afsona（タシュケント）💵 現金のみZargaron Plov（ブハラ）Manti na Zakaz（サマルカンド）Shokhrukh Nur（サマルカンド）Munis Shashlik（サマルカンド）Sayqali Samarkand Chayhana（サマルカンド / 別のお客さんが Visa はOKって言われてるのを聞いたけど、Mastercard を出したらダメって言われたので、Visa だけ対応しているのかも）観光スポット・美術館の入場料クレジットカードが使えたり、使えなかったりと、いまいち傾向がつかめませんでした。💳 クレジットカードOKアルク城（ブハラ / 60,000スム）シャーヒ・ズィンダ廟群（サマルカンド / 50,000スム）レギスタン広場（サマルカンド / 100,000スム）アミール・ティムール博物館（タシュケント / 40,000スム）💵 現金のみカラーン・モスク（ブハラ / 金額は失念）アフラシャブ博物館（サマルカンド / 80,000スム）ビビハニム・モスク（サマルカンド / 75,000スム）グル・アミール（サマルカンド / 75,000スム）交通タシュケントの地下鉄では、改札でカードをタッチするだけで乗車できました。一度入場すると、出場するまでは何駅でも乗車できます。しかも1回あたり20円くらい。安い！ショッピング💳 クレジットカードOK空港の eSIMスーパーマーケット土産物屋（クレジットカードOKのサインを見かけるところが多かった）💵 現金のみバザール街なかの小さな商店これからウズベキスタンにいく人の参考になれば幸いです。関連記事【ウズベキスタン旅行】両替の悩みをWiseで解決した話【ウズベキスタン旅行】持っていってよかったものと持っていかなくて後悔したもの2025年9月ウズベキスタン旅行記 【準備編】2025年9月ウズベキスタン旅行記 【1日目 タシュケント】2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】

【ウズベキスタン旅行】クレジットカードが使えた場所、現金しか使えなかった場所

2025年9月5日から11日まで、ウズベキスタン（サマルカンド、ブハラ、タシュケント）を旅行しました。持ち物の中で、持っていって大正解だったものもあれば、「持ってくればよかった」と後悔したものもありました。この記事では、それらを紹介します。持っていってよかったものリップクリーム滞在した期間、気温は連日30度を超え、湿度は10%台でした。外を歩いていると一瞬で唇がカサカサになってしまいます。こまめにリップクリームを塗ることで、唇の乾きを防ぐことができました。なかったら大変なことになっていたんじゃないかなと思います。日傘日本では、男性も日傘を持つことが多くなってきましたが、ウズベキスタンでは、女性でも日傘を使っている人はそんなに見かけませんでした。男性にいたっては、観光客を含め皆無。でもいいんです。日差しが強烈すぎました。日傘はマストアイテムです。ドライバッグ（ドライサック）買ったのはこれ。落ち着いたグレーで見た目も好み。7日間と少し長い滞在だったので、1度だけ洗濯をするつもりでした。しかし、ホテルの洗面台やバスタブでの手洗い洗濯は、非常にめんどくさいものです。なんとか楽ができないかということで思いついたのが、防水性のあるドライバッグ（ドライサック）でした。ここに水、洗剤、洗濯物を入れて、ガシャガシャと振れば、洗濯ができます。水を入れすぎるとすこし重くなるのが難点ですが、数日分の靴下や下着をまとめて一気に洗えたので、とても楽に洗濯ができました。2L、4L、8Lの3枚セットを購入したのですが、洗濯袋として便利だったのは一番大きい8Lでした。残りの2Lと4Lは、着替えをパッキングするのに使いました。空気を抜いて開口部を閉じると、圧縮されてとてもコンパクトになるので、パッキングのスペースを有効活用できます。思いつきで買ってみましたが、持っていって大正解でした。ちなみに、温泉や銭湯で濡れたタオルを入れたり、ジムで汗をかいたウェアを入れたりと、普段でも活躍します。セームタオルセームタオルの中には乾くとパリパリになるものがありますが、これは乾いても柔らかいまま水泳やフィットネスでよく使われる、吸水性、速乾性のあるタオルですが、これも洗濯グッズとして利用しました。手洗いで洗濯をしたとき、「脱水」もまた頭を悩ませる問題です。洗濯物を強く絞りすぎると生地が痛む、かといって水分が残っていると、なかなか乾かなかったり、干しているうちに水がポタポタとたれてきたりします。バスタオルにくるんで吸水するとよい、という話を聞いたことがありますが、洗濯物が多いと吸水しきれないし、そもそも体を拭くためにバスタオルは残しておきたい。だったら、吸水性にすぐれ、かつすぐに乾いてくれる「セームタオル」を使えばいいのでは？と思い、試しに持っていきました。洗ったあとの洗濯物を軽く絞り、このタオルに挟みながら水分を吸い取ります。軽く握るだけで、ぐんぐん水分を吸い取ってくれるのがわかります。濡れたタオルは、絞ると吸水性が復活するので、これを何度か繰り返します。持っていったのは、少し大きめのハンドタオルくらいのMサイズ。Tシャツなんかだと、何回かに分けて使う必要がありましたが、一回り大きいLサイズ（バスタオルサイズ）だと、濡れたタオルを絞るのが大変そうなので、こちらにして正解だったと思います。ハンガーピンチセット洗濯グッズはグレーで統一またまた洗濯グッズですが、ハンガーやクローゼットのポールに巻き付けて使える洗濯バサミのセットです。（ハンバーは付属していません。）これも持っていって正解でした。ホテルで靴下や下着を洗ったときって、どこに干すか問題になるんですよね。デスクや椅子、バスタブなんかにひっかけておくことが多いんですが、それだとなかなか乾かない。この洗濯ばさみをホテルのハンガーに取り付けて使ったら、すぐに乾きました。数日分の洗濯をするつもりだったら、2つ以上持っていくのがよいと思います。折りたたんでコンパクトになるのもよかったです。上記のセームタオルと一緒に「洗濯セット」としてジップロックに入れて持ち運んでいました。ポケットティッシュ宿泊したすべてのホテルで、部屋に備え付けのティッシュはありませんでした。また、公共（駅や美術館など）のトイレにはトイレットペーパーがなく、ポケットティッシュが必要でした。1日ひとつのペースでなくなったので、多めに持っていってよかったです。持っていかずに後悔したものハンドクリームリップクリームは持っていったのですが、ハンドクリームを忘れてしまいました。乾燥で次々と指にささくれができてしまい、地味だけど痛くてストレスでした。乾燥対策はしっかりと。シャンプー、コンディショナー予約したホテルにはバスアメニティがあると書いてあったので持参しなかったのですが、シャンプーとボディソープだけで、コンディショナーがないホテルがほとんどでした。髪の毛がギシギシになってしまったので、普段使っているシャンプーとコンディショナーを持っていけばよかったと後悔しました。関連記事【ウズベキスタン旅行】両替の悩みをWiseで解決した話【ウズベキスタン旅行】クレジットカードが使えた場所、現金しか使えなかった場所2025年9月ウズベキスタン旅行記 【準備編】2025年9月ウズベキスタン旅行記 【1日目 タシュケント】2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】

【ウズベキスタン旅行】持っていってよかったものと持っていかなくて後悔したもの

2025年9月5日から11日まで、ウズベキスタン（サマルカンド、ブハラ、タシュケント）を旅行しました。ウズベキスタンの現地通貨である「スム」の両替については、いろいろと悩ましいことが多いのですが、今回の旅行では Wise を使うことでとても楽にできました。この記事では、Wise とはどのようなサービスなのか、どのように Wise を活用できるかを紹介します。ウズベキスタンでの現金入手がややこしい問題ウズベキスタンでは都市部を中心にキャッシュレス決済が広がりつつあるものの、まだクレジットカードが使えない場所も多く、現金（スム）の用意が必須です。スムを手に入れる方法としては、主に以下の2つが考えられます。1. 両替所で両替する空港や銀行、ホテルの両替所で両替する方法。しかし、ウズベキスタンでは日本円を両替できる場所が少ないため、事前に米ドルやユーロを準備しておき、それをスムに両替するのが一般的です。まとまった現金を持ち歩くリスクがあり、また両替所を探す手間もかかります。2. クレジットカードを使ってATMでキャッシングする1よりも手軽な方法。クレジットカード1枚を持ち歩くだけで済みますし、ATMも街のあちこちで見かけるため困ることはありません。しかし、次の点に注意が必要です。「借り入れ（いわゆる借金）」なので利息がかかる事前に「海外キャッシング枠」を申し込んでおく必要がある利用可能枠（上限金額）が定められている海外事務手数料や海外ATM手数料（利用1回あたり220円程度）などの費用が発生するカード会社が定める両替レート（それほど良くない）が適用されるスムの再両替がほぼ不可能さらに厄介なのが、余ったスムを米ドルや日本円に再両替するのが非常に難しいという事情です。（手続きが煩雑で、対応してくれる場所もほとんどないそうです。）そのため、現金（スム）が余らないように、必要最低限だけをこまめに両替する必要が出てきます。まとめると、レートが安定している米ドルを使って両替したい各種手数料を抑えるため、両替やキャッシングの回数は最小限にとどめたいスムが余らないように、こまめに両替したいという3つの悩みを同時に抱えることになります。Wise が大活躍この3つの悩みを、今回の旅行では Wise を使うことですべて解決できました。鮮やかなグリーンのWiseカードWise は海外送金サービスとして有名ですが、海外旅行でも大活躍します。主な特徴・メリットは以下の通りです。Wiseの口座で、日本円や米ドルなど複数の通貨を保有できるアプリを使って好きなタイミングで入金や両替ができる両替では手数料が上乗せされていないミッドマーケットレートが適用される「Wiseカード」という物理的なデビットカードで、キャッシュレス決済ができるWiseカードで海外ATMから現金引き出しもできる。両替手数料も海外ATM手数料も安い今回の旅では、日本円から米ドルへの両替ATMからの現金引き出しキャッシュレス決済（カード払い）をすべて Wise で完結させることができました。詳しく見てきましょう。1. 日本円から米ドルへの両替出発前に銀行口座から日本円を入金し、為替の動きを見ながら米ドルに両替しておきます。アプリ内で両替レートや手数料をリアルタイムで確認でき、拍子抜けするぐらい簡単に両替ができます。少し円高になったタイミングで、まとまった額の米ドルを日本円から両替しておいた手数料も含めて、両替のレートがすぐにわかるここで用意した米ドルが、後述する「ATMからの現金引き出し」および「キャッシュレス決済」の残高となります。少し多めに両替しておくと安心です。（余ったら次の旅行で使えますし。）2. ATMからの現金引き出し現地では、Wiseカードを使ってATMから現金（スム）を引き出しました。自分のWise口座から単にお金を下ろすだけなので、キャッシングのように利息はかかりません。やりかたは次の通り。ATMにWiseカードを挿入言語を「English」に設定4桁のPIN（暗証）コードを入力メニューから「Withdrawal（引き出し）」を選択引き出したい金額（スム）を選択もしくは入力ATM引き出し手数料ですが、1か月に2回まで、かつ合計30,000円相当額まで無料で引き出すことができます。3回目以降の引き出し手数料も70円程度なので、これなら回数を気にせずに利用できますね。また、クレジットカードのキャッシングは、自国通貨（日本円）でしか決済できませんが、Wiseの場合は保有している通貨のうち最も手数料が安いものを自動的に選んでくれるというメリットもあります。今回は日本円と米ドルを保有していましたが、常に手数料が低い米ドルで決済されました。今回の旅行では、様子を見ながら50万スム（6000円くらい）ずつ、計4回引き出しました。最後に残ったのは2万スム（200円くらい）程度だったので、ほぼほぼ使い切れたと言えるのではないでしょうか。（残ったスムは空港の募金箱に寄付しました。）クレジットカードのキャッシングのような手軽さと、手数料の安さ・レートの良さを両立できるのが、Wiseの最大のメリットだと思います。3. キャッシュレス決済（カード払い）キャッシュレス決済に対応している場所では、Wiseカードを利用しました。（配車アプリの「Yandex Go」もWiseカードを登録して支払いました。）デビットカードなので、支払いと同時にWise口座から引き落とされます。ここでも、最も手数料が安い保有通貨（つまり米ドル）が自動的に選ばれます。決済が完了すると、すぐにスマホに通知が飛んでくるので、怪しい取引に使われていないか確認できて安心です。まとめ個人的には、ウズベキスタン旅行での決済手段として、Wiseは最適な選択肢だと感じました。ほぼすべてアプリで完結するのがとても便利でした。もちろん、他の国を旅行するときにも、Wiseは同じように活躍します。（台湾でも一度使いましたが、その時もとても便利でした。）これからいろんな国に旅行しようと考えている人は、アカウントを持っておいて損はないと思います。（アカウント開設は無料ですし、月額や年会費は一切かかりません。）最後に、Wiseの招待リンクを置いておきます。こちらのリンクからアカウントを作成すると、1,200円かかるWiseカードの発行手数料が無料になります。ぜひご利用ください。https://wise.com/invite/dic/yoshihidej関連記事【ウズベキスタン旅行】持っていってよかったものと持っていかなくて後悔したもの【ウズベキスタン旅行】クレジットカードが使えた場所、現金しか使えなかった場所2025年9月ウズベキスタン旅行記 【準備編】2025年9月ウズベキスタン旅行記 【1日目 タシュケント】2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】

【ウズベキスタン旅行】両替の悩みを解消するWise活用法

旅行中、愛用している無印良品のハードキャリーケースのハンドルが、上部・サイドとも割れてしまった。帰宅後にネットで調べてみると、自分で簡単に修理できることがわかった。かれこれ6年以上愛用しているこのキャリーケースを復活させた、ハンドル交換の全記録を記しておこうと思う。Amazonでパーツ探しまずは交換用のパーツ探し。Amazonで検索すると複数の商品が見つかった。ここで一番気をつかったのが、サイズが異なるパーツを買わないこと。交換作業自体は簡単そうなのはわかっていたが、サイズが違うものを買ってしまうと元も子もないので、慎重にチェックした。壊れたハンドルを外してメジャーで測り、商品説明やAmazonのレビューを徹底的に確認した。「無印良品にぴったりでした！」という複数の口コミを見つけて、ようやく安心して購入に踏み切れた。購入したのは21cmと書いてあるこちら。2本セットになっていて、色はもとのハンドルと同じ黒を選んだ。上部のハンドルもサイドのハンドルも同じサイズなので、もし片方だけ壊れていたとしても、同時に交換してしまうのが懸命だと思う。  Leap Raupe スーツケース 交換用ハンドル 21cm (黒 A 2本)必要なのはプラスドライバー1本だけ新しいパーツが届いたら、いよいよ交換作業だ。必要な道具は、プラスドライバー1本だけ。作業は拍子抜けするほど簡単で、壊れたハンドルのネジをドライバーでゆるめて外し、新しいパーツを取り付けて、再びネジを締めるだけ。ネジにはカバーのようなものがかぶっているが、指で簡単に引き上げられる。ネジにカバーがかぶっているのでパカッと引き上げますもとのパーツと新しいパーツを比較する。高さが少し違うけど、設置してみたらまったく問題なかった。上がもとのパーツで、下が新しいパーツ。幅は全く同じ。古いパーツのうちまだ無事な部分を再利用しようかとも考えたが、ネジ穴がうまく合わなかったり、経年劣化も気になったので、新しいパーツをすべて利用することにした。まるで新品。違和感なく使えるように作業時間は、両方のハンドルを交換して20分ほど。新しいハンドルを取り付けたキャリーケースは、ガタつきも違和感もまったくなし。まったく違和感なし6年以上使い続け、たくさんの思い出が詰まったこのキャリーケース。壊れてもう使えないかと諦めかけていたが、自分で簡単に修理できて本当によかった。もし同じように無印良品のキャリーケースのハンドルが壊れてしまった方がいたら、ぜひ自分で交換にチャレンジしてみてほしい。驚くほど簡単に、愛用のキャリーケースを復活させることができるはずだ。

無印良品 ハードキャリーケースのハンドルを自分で交換してみた

2023年を振り返る。藤井風のライブ2月に藤井風のライブに行った。ライブ自体が人生で2回目だったけど、最高によかったので、2024年もいろんなアーティストのライブに行きたい。演劇なんかも観に行きたいな。台湾旅行3月に台湾旅行に行った。台湾は食べ物がおいしいし、人も親切だし、ほどよい異国感があってとても居心地がよかった。また行きたい。キャンプ5月に山中湖の近くで会社の同僚たちと、8月には家族でキャンプに行った。キャンプブームは去ったようだけど、やっぱりキャンプは楽しい。今月、車を買ったので、2024年はもっといろんなところに行きたい。新型コロナウイルスに感染9月に新型コロナウイルスに感染してしまった。逃げ切れるかなと思っていたけど、だめだった。しかも発症したその日にワクチン接種券が届くという不運。一週間程度で症状は収まり、家庭内感染も発生せず、心配していた後遺症もなかったのは不幸中の幸いだった。車を買った人生で初めて車を買った。前から欲しいと思っていたけど、マンションの駐車場に空きがなくて買えなかった。今年になってようやく空きができたので、思い切って買った。買ってから1ヶ月経ったけど、やっぱり車は便利だし、運転は楽しい。仕事Ubieで働きだしてから丸4年目が過ぎた。この4年で会社は大きく変わったが、今年は特に変化が激しかったし、事業的にも大きく飛躍した年だった。自分が作っているプロダクトが多くの人に届いているのを実感できるのはとてもやりがいがある。来年もこの勢いのまま突き進んでいきたい。2024年にむけて仕事は引き続きやっていく。プライベートでは、車を買ったので、フットワーク軽くいろんなところに行って人生を楽しみたい。

2023年振り返り

2023年7月より、Ubieのソフトウェアエンジニアの募集職種が大きく見直され、細分化されました。この記事ではその内容と背景についてご紹介します。今回の話は、Ubieの中でプロダクト開発を担う「Ubie Product Platform」に関するものになります。続きをみる

「専門性を活かす」Ubieのソフトウェアエンジニア募集が細分化しました

Ubie Discoveryでプロダクト開発をしている@jimboです。今回は症状検索エンジン「ユビー」のCSSファイルを改善した話を紹介します。 きっかけある日、社内のSlackにこんなメッセージが流れてきました。自分の中ではある程度レイアウト関連やテキスト関連にグループ化して書くようにはしていたのですが、こういう類のものは、個人個人が気をつけるのではなく、自動的に並び替わるほうがいいに決まっています。いうことで、Stylelintとstylelint-config-recess-orderを導入することにしました。Pull Requestでは、400を超えるCSSファイ...

CSSプロパティを自動ソートしただけで、CSSのファイルサイズを（少しだけ）減らせた話

2022年を振り返る。プライベート去年は引きこもってばかりだったが、今年はその反動で少しずつ気持ちが外に向かっていった1年だった。長女の高校受験が無事終わり、ようやく一段落したことも大きかった。7月に家族で北海道旅行に行ったが、それ以外では家族でいっしょに出かけるという機会はあまりなかった。長女も次女も少しずつ親から離れて自分たちの世界を構築しだしていて、子育てが終わりに近づいているんだなぁと実感する。これからは自分自身のために使える時間が増えると思うが、と同時に残りの人生が徐々に目減りしていってるのも感じる。やりたいことは今やらないとという気持ちがこの1年で強くなったように思う。あと、去年の振り返りで努力しないと体がどんどん老けていくのを年々実感するので、健康維持のために投資することを惜しまないようにしたい。と書いたが、8月からジムに通いだした。今のところ週2回、継続的に通えているので、2023年も続けたい。仕事去年の10月から所属していたグローバルチームを4月に離れ、日本のプロダクト開発チームに戻った。グローバルチームでの経験は得難いものだったが、今のチームも会社の事業を支えるチームなので、とてもやりがいがある。会社自体もますます進化している。まだまだ走り続けるぞ。2023年にむけて2023年のテーマは「好奇心は高く、フットワークは軽く」。やりたいことはやる。行きたいところには行く。会いたい人には会う。いろいろあると思うけど、楽しい年になりますように。

2022年振り返り

Webサイトを構築するアーキテクチャとしてJamstackを導入する際、Static Site Generator (SSG) としての選択肢は豊富にあります。HugoやGatsby、Next.jsあたりが定番だと思いますが、2022年8月にv1.0がリリースされたAstroが個人的に気になったので、Next.jsとビルドのパフォーマンスを比較してみることにしました。中〜大規模サイトでの利用を想定して、API経由でコンテンツ取得する1000ページ分のサイトをNext.js、Astroそれぞれで生成して比べてみます。なお、Next.jsはStatic Generationを利用します...

SSGとしてのAstroとNext.jsを比較してみた

!Ubie Engineers & Designers Advent Calendar 2022 6日目の記事です。Ubie Discoveryでプロダクト開発をしている@jimboです。Ubieでは現在、デザイン生産基盤整備の一環として、プロダクト上のUXライティングを改善する取り組みを行っています。この記事では、これまでの活動内容について紹介します。 UXライティングとはユーザーは、プロダクトやサービスを利用する際、あらゆる場面で「言葉」を目にします。タイトルや説明文、ボタンのラベル、通知、エラーメッセージなどなど。UXライティングでは、これらの「言葉」に注目...

症状検索エンジン「ユビー」のUXライティングを改善している話

@masuP9のブログ記事「BudouXを使ってフレーズ単位で改行する」にインスパイアされて、本ブログのOGP画像にBudouXを適用してみた。結果適用前適用後よさそう。実装まず、ローカルにテンプレートファイルを用意する。パフォーマンスを考慮する必要がないので、Tailwind CSSのPlay CDNを使っている。<!doctype html><html lang="ja">  <head>    <meta charset="UTF-8" />    <meta http-equiv="X-UA-Compatible" content="IE=edge" />    <meta name="viewport" content="width=device-width, initial-scale=1.0" />    <script src="https://cdn.tailwindcss.com"></script>  </head>  <body class="antialiased tracking-widest">    <div class="relative w-[1200px] h-[630px] flex items-center px-36">      <h1 id="title" class="mb-8 font-bold text-6xl leading-relaxed text-gray-900">Hello!こんにちは！</h1>      <img class="absolute bottom-16 right-20" src="../../../public/icon.svg" width="82" height="82" />    </div>  </body></html>メインとなるスクリプトでは、テンプレートファイルをPuppeteerで開くh1要素のinnerHTMLをBudouXを適用したタイトルで置き換えるスクリーンショットを撮るというステップでOGP画像を生成している。import fs from 'fs';import { join } from 'path';import matter from 'gray-matter';import puppeteer from 'puppeteer';import { loadDefaultJapaneseParser } from 'budoux';const postsDirectory = join(process.cwd(), 'src/_posts');function getPostTitle(filename: string): string {  const fileContents = fs.readFileSync(join(postsDirectory, `${filename}`), 'utf8');  const { data } = matter(fileContents);  return data.title;}async function main() {  const postFiles = fs.readdirSync(postsDirectory);  const parser = loadDefaultJapaneseParser();  for (const mdFilename of postFiles) {    const title = getPostTitle(mdFilename);    const browser = await puppeteer.launch();    const page = await browser.newPage();    // テンプレートファイルを開く    await page.goto('file:///' + join(process.cwd(), 'src/scripts/generateOGImage/template.html'));    // BudouXを適用したタイトルを取得する    const parsedTitle = parser.translateHTMLString(title);    // h1要素のinnerHTMLを置き換える    await page.$eval(      'h1',      (el, parsedTitle) => {        el.innerHTML = parsedTitle as string;      },      parsedTitle,    );    // スクリーンショットを撮る    await page.screenshot({      path: `public/og-images/${mdFilename.replace('.md', '')}.png`,      clip: { x: 0, y: 0, width: 1200, height: 630 },    });    await browser.close();  }}main();次は、元記事と同じように、記事タイトルにもBudouXを使ってみようかな。追記：記事タイトルにもBudouXを適用した。こちらもよさそう。

BudouXを使って記事のOGP画像を見やすくする

2021年を振り返る。プライベート休日は引きこもってばかりの1年だった。新型コロナの影響も当然あるし、長女が高校受験の年なので、家族で出かける機会がほとんどなくなってしまったのも大きい。新型コロナウイルスのワクチン接種を行ってからは、気分的にだいぶ落ち着けたが、それでもあちこち出かけることはなく、気づいたら一年が終わってたという印象。唯一、11月に会社のメンバーとキャンプに行けたのがいい思い出。自分以外は全員東京からの参加だったので、中間地点ということで静岡県浜松市のキャンプサイトに集まったのだが、ひさびさの長距離運転も楽しかったし、みんなで焚き火を囲んでまったりできたのはよかった。あと、今年は原因不明の体調不良に悩まされて、何度も病院に通った。医療費も時間もかかったうえに、結局原因ははっきりせず、もやもやだけが残った。（これが年を取るということなのかもしれない。）ただ、患者としての体験もでき、また医師への理解も深まったので、仕事をする上ではいい経験となった。初めての検査も多く、特にCT検査は宇宙船の冬眠装置みたいで興奮したし、造影剤を体内に入れた瞬間、体内が一気に熱くなって「ち、力が解放される...」という感じがしてちょっと楽しかった。（ちなみに検査結果はまったく異常なしだった。）仕事5月末に、それまで所属していたユビーAI受診相談の開発チームから離れた。1年8ヶ月という長い間、いろいろな施策を試行錯誤する日々だったが、自分が抜けた途端、ユーザー数が一気に増えて、いまや会社の中心となるサービスにまで一気に成長した。（ちょっとだけ複雑な気分。うそ。とても喜ばしい。）6月からは新規事業にゼロから携わり、0→1の難しさと楽しさを体感することができた。この経験から得た知見を「0→1」フェーズにおける技術的負債との向き合い方という記事にまとめた。10月からはグローバルチームに異動して、グローバル向けのBtoCサービスの開発に携わっている。メンバーの半数はシンガポール、残りは日本とインドというメンバー構成。コミュニケーションのほとんどが突然英語になって大丈夫かなと思ったが、今のところなんとかなっている（と思いたい）。DeepL と Grammarly と Google Meet の自動字幕というテクノロジーに助けられている面もかなりあるが、それより「ちゃんとした英語を話さなければ！」という思いがなくなり、「文法が間違っていてもいいから、とにかく伝えたいことを伝えるのだ！」とメンタル的に図々しくなったのが大きいように思う。（これも年を取るということなのかもしれない。）とにかく異なる文化を持つ同僚たちと一緒に仕事をするのがとても楽しい。2022年にむけてプライベートでは単調な一年だったので、状況が許す限り、たくさんの人と会い、様々な土地を訪れて、いろいろなものを見て、食べて、飲んで、楽しめるといいなと思う。（シンガポール出張したいなぁ。）あと、努力しないと体がどんどん老けていくのを年々実感するので、健康維持のために投資することを惜しまないようにしたい。仕事では、放っておいても刺激的なことが日々起こる会社なので、今年同様、変化の渦を楽しもうと思う。2022年もいい年になりますように。

2021年振り返り

2018年に Nuxt.js を使ってブログを新しくしたが、最近は仕事でも React しか触っていないので、Next.js に移行した。作業ログ：https://zenn.dev/jimbo/scraps/4226bd96c51c751日足らずで移行作業がほぼ終わり「余裕余裕」と思ってたけど、Netlify の不具合を踏んで sitemap.xml と atom.xml の生成がうまくいかないことがわかり、そこから数日ハマってしまった。時間はかかったが、おかげで remark を使った Markdown の処理に少し詳しくなれたのでよかった。パフォーマンスも上々。

ブログを Nuxt.js から Next.js に移行した

以前から「スタートアップのなかで『技術的負債』というものをどう扱うべきなのか」というテーマに対して関心が高かったのだが、今年の6月から「0→1」の新規事業に関わるようになって、自分の中でなんとなく考えがまとまりそうなので、雑に吐き出してみる。最近、社内でも「技術的負債」が話題にあがることが多く、その中で同僚のエンジニアからあがった意見も参考にしている。そもそも技術的負債とは@t_wada さんの次の記事に答えが書いてある。【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wada のブログ個人的には次のように解釈した。「手を抜いた雑なコード」は技術的負債とは呼ばない。それはただの低品質なコードである仮説検証や経験からさまざまな学びを得ることは正義そこで得た「学び」と「現状のソフトウェア」とのギャップを「技術的負債」と呼ぶこのような「学びから生まれる技術的負債」に加えて、仮説検証を最速で行うために（あとで返済する前提で）わざと作り出す「計画的な技術的負債」と呼ぶべき類の負債もあるように思う。いずれの負債も基本的にはポジティブに捉えてよいと考えている。「学びから生まれる技術的負債」はそれだけ多くの学びを得ているということだし、「計画的な技術的負債」もそれによって仮説検証を加速させることができるからだ。難しいのは、そのようにして生まれた技術的負債を「いつ」「どのように」返済していくかということだ。これらの技術的負債のほかに、特定の顧客からの要望やビジネス上のやんごとなき事情によりプロダクトに組み込まれた「大人の事情による負債」というのもありそうだが、こちらはあまりポジティブに捉えるべきではないように思う。それらの対処法にも興味はあるが、「0→1」フェーズでは発生することは考えにくいため、この記事ではスコープ外とした。「0→1」フェーズにおける技術的負債「0→1」フェーズでは必然的に「技術的負債」が大量に生まれやすい構造になっている。まず「0→1」フェーズについて整理しておく。現在所属している Ubie株式会社では、事業フェーズを次のように定義している。（ちなみにUbieは、担当するフェーズごとに「Ubie Discovery」と「Ubie Customer Science」という2つの組織に分かれている。私は 「0→10」を担う「Ubie Discovery」に所属している。）「0→1」フェーズでは、PSF（Problem/Solution Fit）を目指す。PSFとは、ユーザーが抱える課題（= Problem）を発見し、それらを解決する「MVP（Minimum Viable Product）」（= Solution）が特定できている状態である。言い換えると、「仮説はある。だが実際はどうなのか、何もわからん」状態から、仮説検証を何度も繰り返し、そこから学びを得てユーザーの課題やプロダクトのあるべき姿を探っていくフェーズである。「新たな学びを得ること」こそが「0→1」でやるべきことなので、多くの「学びから生まれる技術的負債」が発生するのは当然であり、健全に検証サイクルが回っている証とも言える。また、いかにすばやく仮説検証が繰り返せるかが重要になってくるため、「計画的な技術的負債」も効果的に利用していきたいところである。とはいえ、技術的負債は必ず「返済」する必要がある。「学びを得ることは正義」とはいえ、なんでもかんでも負債として抱えると、のちのち返済に苦しむ未来は容易に想像できる。また、積み上がった技術的負債によって、仮説検証のスピードが落ちてしまっては本末転倒である。したがって、生み出される負債の量をうまくコントロールする必要がある。どのように技術的負債を取り扱うか「学びから生まれる技術的負債」の場合「学び、学び」と書いているが、プロダクト開発をしていると様々な種類の学びが得られる。新たに獲得したドメイン知識ユーザー調査などから発見した解決すべき課題その課題を解決するための新たなソリューションアーキテクチャに関するベストプラクティスライブラリやフレームワークのAPIや機能に関する知見コードレビュー、勉強会、SNSなど様々な経路を通じて知った「もっといいコードの書き方」シャワーを浴びながらひらめいた実装アイディアもっとたくさんあると思うが、次の2つに大きく分けられそうである。仮説検証による学びエンジニアリングに関する学び前者の「仮説検証による学び」は多ければ多いほどよい、というのは自明だろう。後者の「エンジニアリングに関する学び」は、エンジニアとしての成長を意味するのでよいことではあるのだが、「0→1」フェーズにおいては、そこから生まれる技術的負債が、仮説検証を妨げる要因になりがちではないかと感じる。ソースコードの品質が低すぎると、バグフィックスに追われてそもそも検証が進まないというのは想像しやすい。例えば、安易な例だが「使ったことはないけど、このフレームワークは流行ってるし今回の要件に向いてそうなので採用！」というような意思決定は、仮説検証による学びよりも、新しい技術を使うことによる学び（とそこから生まれる技術的負債）に多くの気を取られてしまうためリスクが高い。すでに利用実績があって、知見が溜まっているものを選択したほうがよいだろう。（では「手に馴染んだ枯れたフレームワーク」を採用すればよいかというと、「0→1」に成功してその先のフェーズに進んだときに「時代遅れのフレームワーク」になっていて、世の中に広まっている新たなベストプラクティスを採用しづらい状況になっている、というようなこともありうるので難しい。）また、「0→1」フェーズでは細かな単位で「作っては捨て、作っては捨て」を繰り返す。未熟なアーキテクチャや全体設計になっていると、一回一回の変更に時間がかかってしまう。経験を積むことでよりよい設計が見えてくることも当然あるが、最初から仮説検証のスピードを維持するためには「ある程度の安定性はありつつ変更も加えやすいようなアーキテクチャ」といったものを初期の段階からしっかりと組めるに越したことはない。（が、初期構築に時間をかけすぎると、そもそも仮説検証をスタートできないので、こだわりすぎるのもよくない。難しい。）「技術力が高くなければ『0→1』の開発はするべきではない」と言うつもりは毛頭ないし（そんなことを言えば自分にブーメランが返ってくるだけだ）、たとえ何かを妨げる結果になったとしても、何かしらの学びを得ることはそれ自体尊いことだと思う。しかし、特に「0→1」フェーズに限って言えば「エンジニアリングに関する学び（とそこから生まれる技術的負債）」は、極力小さくなるようにコントロールするべきではないだろうか。（別の言い方をすれば、エンジニアリングに関する不確実性は、できるだけ小さくしておくほうがよい。）「計画的な技術的負債」の場合「計画的な技術的負債」というのは、例えば「将来的には自前のバックエンドが必要になりそうだけど、今はひとまず SaaS で検証を進める」とか、「このコンポーネントは共通化できそうな気がするけど、そもそも検証したら要らなくなるかもしれないし、いったんコピペで対応する」といったものをイメージしている。「計画的な技術的負債」に関しては、仮説検証を加速させるブースターのような役割があるので、積極的に利用したほうがよさそうだ。ただし負債としてたまり続けると、腐臭を漂わせることになるので、返済することは絶対に忘れるべきではない。「計画的な技術的負債」の場合は「学びから生まれる技術的負債」とは違い、それを積んだ背景やコンテキストが明確で、返済すべき条件やタイミングがあらかじめ想定できているはずだ。したがって、ADRやTODOファイル、コメントアウトなど（フォーマットは何でもよいが）記録を残し、いつでも確認できるようにしておくことが大切だろう。また、「返済のしやすさ」もある程度考慮したうえで負債を積むこともできるはずである。例えば「自前のバックエンドにデータを移しやすいような SaaS を選定する」とか、「フロントエンドのインフラストラクチャ層でデータアクセスを抽象化しておいてバックエンドのリプレイスの影響を受けにくいようにしておく」とか、「共通化しそうなコンポーネントは名前のプレフィックスを合わせる」とか、やれることはたくさんある。さいごにあくまで個人的な経験から得た「学び」をまとめたものである点はご了承ください。みなさんの意見も聞かせてもらえると嬉しいです。

「0→1」フェーズにおける技術的負債との向き合い方

こちらに移動しました。https://zenn.dev/ubie/articles/fe845089489229

private な npm パッケージを Dockerfile でインストールして GitHub Actions でビルドする

2020 年を振り返ってみる。ポルトガル旅行の中止長女も中学生となり、家族で海外旅行ができるのも今年がラストチャンスになりそうだと思い、年初からポルトガル旅行の計画を立てていた。フライトを予約し、宿泊先を Airbnb で確保し、あとは行くだけと楽しみにしていたが、2 月半ばから新型コロナウイルスの影響で雲行きが怪しくなってくる。3 月頭にはヨーロッパでも感染が広がり、フライトもキャンセルとなってしまった。次はいつ行けるのか...小中学校の休校3 月 2 日から臨時休校となり、6 月になってようやく再開となった。長女が通っている塾ではしばらくしてオンライン授業がはじまったが、公立の小中学校では 3 ヶ月間自宅学習のみ。対応力の差を如実に感じた。子どもたちにとっては、早起きしなくていいし、わからないところは親に聞いたり YouTube の映像授業で調べれば済むしで、そんなに困ることもなかったっぽいが、親にとっては非常事態でいろいろ気を揉むことが多かった。体づくり去年の振り返りで「2020 年は体を鍛えたい。」と書いたが、今年は家にいる時間が長かったので、継続的に体づくりができた。2 月には家族全員で「1 ヶ月プランクチャレンジ」をやりきったし、その後も YouTube でお気に入りのパーソナルトレーナーのチャンネルを見ながら定期的に体を動かせた。その結果、ずっと悩まされていたぎっくり腰も今年は 1 回もかからずに過ごすことができた。仕事ヘルステック（医療 x テクノロジー）のスタートアップである Ubie にとって、新型コロナの影響は非常に大きかった。現在開発を担当している生活者（toC）向けサービス「AI 受診相談ユビー」は、感染拡大をうけて、当初の計画を大幅に前倒して 4 月 28 日に緊急リリースした。その後も、いくつかのニュース番組で取り上げられて喜んでいたらアクセスが集中して冷や汗をかいたり、リリースしたものの思うように数字が伸びず苦しんだり、4Q は逆に施策がはまって数字がどんどん伸びたりと、プロダクトづくりの面白さを実感する 1 年だった。会社自体も、社員数が 3 倍になり、さまざまな組織づくりも進められ、アウトプットの多い 1 年となった。2020 年、20 億円の資金調達からグローバル進出まで。Ubie の 1 年間ふりかえり。｜ Ubie (ユビー)｜ note来年にむけておかげさまで仕事は順調だし、まだまだやることがたくさんある。この勢いのまま、来年も突き進みたい。日常生活では、人に会う機会は激減してしまったし、常に新型コロナにおびえながら生活するのはなかなかしんどい。正月の帰省も諦めた。来年の今ごろはどんなふうになっているのか想像できないが、1 日でも早く安心してみんなで集まって騒げる日が戻ってくることを願ってる。

2020年振り返り

これは何Ubie Advent Calendar 2020 6日目の記事です。続きをみる

地方で暮らしながら都内のスタートアップでのびのびと働くソフトウェアエンジニアの話

2019 年を振り返ってみる。仕事約 6 年間勤めた Kaizen Platform を退職して、Ubie 株式会社に転職した。（人生 3 度目の転職）1 月末が Kaizen Platform の最終出社で、有給休暇を消化しながら、2 月から Ubie で働き出した。2 月の 1 ヶ月間は、東京に滞在してオンボーディング。普段会えない友人たちともひさびさに会うこともできた。最初に担当したのは、AI 問診 Ubie のタブレット問診機能のフロントエンド開発。当初は Rails の上に React の SPA が乗っかっていたので、脱 Webpacker をし、 Rails への依存をなくした。また、JavaScript と TypeScript が混在している状態だったので、こちらも TypeScript へ完全移行した。コードベースの整備はうまく進められたが、プロダクトの機能開発は、チームとしてあまりうまく進めることができずにいた。しかし、スクラム開発を導入し、チーム構成とプロジェクトの進め方を見直したことで、状況は劇的に改善された。（詳しくは、こちらの資料を参照。）ちゃんとしたスクラム開発ははじめてだったが、こうも変わるものかとちょっと感動した。6 月から 9 月までは、品質をあげつつ、高齢者向けの UI 改善施策を多く行った。その内容は FRONTEND CONFERENCE 2019 で発表することができた。9 月からは Vue.js（Nuxt.js）を使った別プロダクトを担当している。「AI 問診 Ubie」が拡大フェーズに入ってきた一方、こちらのプロダクトはまだまだ検証を進めているフェーズなので、より緊張感を持ちながらも毎日楽しみながら過ごしている。Vue.js はほぼ初めて触るが、正直、まだ手に馴染んでこない。Composition API も試験的に導入してみたので、もう少し様子を見てみたい。また、Firebase もがっつり触ることができてよかった。会社自体は、自分が入社したときには 20 名くらいだったが、12 月には 2 倍近くに増えた。東京オフィスに行くたびに知らない顔が増えていて、勢いを感じる。人が増え、プロダクトが拡大していくなか、当然問題もいろいろ出てくるが、それらをすばやく解決しながらさらに前に進んでいくという体験は、スタートアップならではの面白さだと思う。2020 年も大いに楽しみたい。プライベート3 月に福岡へ旅行に行った。夏休みには青森へ旅行に行った。キャンプは 3 回行った。ガンバ大阪の試合はホーム最終戦だけスタジアムで観戦した。頻繁に腰を痛めるようになってきた。2020 年は体を鍛えたい。

2019年振り返り

11/3 にグランフロント大阪で開催された FRONTEND CONFERENCE 2019 で「高齢者でも使えるプロダクト UI の挑戦」というタイトルで発表しました。高齢者でも使えるプロダクト UI の挑戦 / Designing User Interfaces for the Elderly - Speaker Deck高齢者にも使ってもらえるプロダクトにするために、これまで地道に改善を続けてきたことを事例として共有するという内容でしたが、ありがたいことに、発表後たくさんの質問をいただきました。その場でうまく回答できなかった部分もあったので、あらためてこの場で回答をさせてもらいたいと思います。「色覚障害の見え方をチェックするためのおすすめのツールは？」スライドの中でも紹介した NoCoffee という Chrome 機能拡張以外に、Mac アプリでは Sim Daltonism が使いやすくおすすめです。「50px ってどうやって決めた？」このスライドにある「50px」という数字はどのように決めたのかという質問でした。その場では「えいやで決めました」と回答してしまったのですが、過去のチケットを探ってみたら、ちゃんと経緯が書いてありました。Apple の Human Interface Guidelines では、コントロール要素のタップ領域を 44pt 以上の大きさにするよう定められています（参考）。この数字をベースに、指の揺れ幅を加味した結果「50px」にしたとのことでした。（ちなみに、この数字をあまり大きくしてしまうと、今度はスクロールがうまく効かなくなってしまうので注意が必要です。）「高齢者のユーザービリティをあげると、他の年代の人にとって使いにくものにはならないか？」高齢者にとって使いやすいものが必ずしも他の年代の人にとって使いやすいものにはならないかもしれないが、どのように考慮しているか、という質問でした。例えば、パソコンやスマホを日常的に利用している人にとっては、「あいうえお配列のキーボード」で入力するよりも、普通にテキスト入力をするほうが使いやすいというのは間違いないと思います。ただ、そういったユーザーでも「あいうえお配列キーボード」が使えないということはないはずです。今のフェーズでは、あらゆる年代の方が自分の症状をタブレットで正確に伝えきるというタスクを遂行してもらうことが最も重要であり、若年層は多少回りくどい操作であっても使いこなせてしまうので、現時点では「使いやすさ」を追求するよりは、高齢者でも「使える」レベルにプロダクトを引き上げることに注力しています。このレベルをクリアできるようになったら、「使いやすさ」や「使って心地よい体験」というさらに上のレベルを目指していければと思います。「左右の入れ替えで左利きのひとの考慮は？」レイアウトを左右に入れ替えたというこのスライドについて、左利きの人だと問題が解決しないのではというご指摘でした。まさに仰るとおりで、利き手に関係なく使えるようなレイアウトにするべきですし、そもそもこの画面は、他と比べて行うべきタスクが多く、ユーザーが最も難しさを感じる箇所でもあるので、まだまだこの画面には課題が多くあるとチームでも認識しています。引き続き改善をしていきたいと思います。「チームがうまく機能しているように感じるのだが、どういう工夫をしているのか？」その場では簡単に「スクラムがうまく機能しているおかげ」と回答しましたが、他の社員が別のイベントで発表した資料に、チームづくりの話が詳しく出てきますので、ぜひご覧ください。（前半は、今回の私の発表と重複した内容になっています。）高齢者 UI への取り組みと自発的改善チームの作り方 / Elderly UI and Scrum Team - Speaker Deck最後に自分の発表を聞きに来てくださった方々、ありがとうございました。何か一つでも普段の業務に生かせるヒントとなれば幸いです。FRONTEND CONFERENCE には毎年参加しているのですが、エンジニアリングとデザインの話がバランス良く聞けて、いつも刺激をもらえます。今年も多くの素晴らしい発表がありました。運営スタッフの皆さん、ありがとうございました。来年も参加できることを楽しみにしています！

FRONTEND CONFERENCE 2019 に登壇しました

lit-html が v0.9.0 で ShadyCSS をサポートするようになったということなので、いろいろと調べてみた。TL;DR現時点では、Shadow DOM のスタイルカプセル化に対応するには ShadyCSS を使う必要がある。lit-html 経由で ShadyCSS を使うと便利。Shadow DOM の Polyfill2018 年 2 月現在、各ブラウザの Shadow DOM v1 のサポート状況は次のようになっている。Chrome と Opera は済み 🙆‍Safari と iOS Safari は一部バグあり 🤔Firefox と Edge はまだ 🙅‍（参考：https://caniuse.com/#feat=shadowdomv1 ）したがって、幅広いブラウザに対応するには、 現段階では Web Components の Polyfill (webcomponents.js) の利用が前提となる。Polyfill には webcomponents-lite.js や webcomponents-sd-ce.js などターゲットブラウザとサポートしたい仕様に応じていくつかのファイルが公開されているが、これらのうち「Shady DOM/CSS をサポート」となっているものには、実は「Shadow DOM のスタイルがカプセル化されない」という問題がある。（Shady CSS をサポートって書いてあるのに！！）Shadow DOM のスタイルカプセル化とは例えば <my-avatar> という次のような Custom Element があったとする。import { html, render } from 'lit-html';class MyAvatar extends HTMLElement {  //...  _render() {    const template = html`      <style>        img {          border-radius: 50%;          border: 1px solid #ccc;        }      </style>      <img src="${this.src}" width="160" height="160" />    `;    render(template, this.attachShadow({ mode: 'open' }));  }}element.attachShadow() で Shadow DOM を生成しているので、ここで定義した <img> のスタイルは Shadow DOM 内にのみ適用される = カプセル化されているというのが期待する挙動だ。それを確認するために、次のような HTML を用意してみる。<img src="https://randomuser.me/api/portraits/lego/7.jpg" width="160" /><my-avatar src="https://randomuser.me/api/portraits/lego/7.jpg"></my-avatar>Chrome 64 と Firefox 58 でそれぞれ確認した結果がこれ。Chrome 64 での結果（左：<code><img></code>　右：<code><my-avatar></code>）Firefox 58 での結果（左：<code><img></code>　右：<code><my-avatar></code>）Chrome では、期待どおり <my-avatar> にだけスタイルが適用されているのがわかる。しかし、Firefox の場合、<my-avatar> で定義したスタイルが通常の <img> にも適用されてしまっている。Shadow DOM 内のスタイルが外に漏れ出しているのだ。逆に Shadow DOM の外で定義されたスタイルも Shadow DOM 内を汚染することになる。ShadyCSS とはこの問題を解決するためのライブラリ（Polyfill）が ShadyCSS だ。「スタイルのカプセル化」をサポートしたい場合、webcomponents.js の Polyfill に加えて、ShadyCSS も使う必要がある。https://github.com/webcomponents/shadycssShadyCSS の処理を通すと、Firefox などのブラウザでは、上記の <my-avatar> のコードが次のように擬似的な Scoped Style に変換される。<head>  <style scope="my-avatar">    img.kz-avatar {      border-radius: 50%;      border: 1px solid #ccc;    }  </style></head><body>  <kz-avatar src="https://randomuser.me/api/portraits/lego/7.jpg">    <img class="style-scope kz-avatar" src="https://randomuser.me/api/portraits/lego/7.jpg" height="160" width="160" />  </kz-avatar></body>ただ、Usage にあるように素で使おうとすると結構めんどくさいコードを書く必要がある。でも、lit-html 経由で ShadyCSS を利用するととても簡単に書くことができる。lit-html で ShadyCSS を使うというわけで、ようやく本題。lit-html で ShadyCSS を利用するには、 lit-html の render() の代わりに lit-html/lib/shady-render.js の render() を使う。import { html, render } from 'lit-html/lib/shady-render.js';class MyAvatar extends HTMLElement {  static get is() {    return 'my-avatar';  }  //...  _render() {    const template = html`      <style>        img {          border-radius: 50%;          border: 1px solid #ccc;        }      </style>      <img src="${this.src}" width="160" height="160" />    `;    render(template, this.attachShadow({ mode: 'open' }), MyAvatar.is);  }}window.customElements.define(MyAvatar.is, MyAvatar);lit-html の render() との違いは、第三パラメータにスコープ名を渡す必要がある点。ここで渡した値が <style> の scope 属性にセットされる。これは、タグ名と一致している必要がある。いずれにせよ、最小限のコードで ShadyCSS が使えるのはうれしい。ただし、制約もあって、例えば、const template = html`  <style>    img {      width: ${this.size}px;    }  </style>  <img src="${this.src}" width="160" height="160" />`;というように、 <style> の中で変数を展開しようとすると、<style scope="my-avatar">  img.kz-avatar {    width: <!-- {      lit-8364277839110217    }  }</style>というように変換されてしまってうまくいかない。こういうユースケースに対応したいならば、おとなしく Polymer などのライブラリを利用するほうがよいだろう。まとめというわけで、Firefox と Edge が Shadow DOM をサポートするまでは、lit-html + ShadyCSS の組み合わせが有力な選択肢になりそう。

lit-html と ShadyCSS

この記事は「Nuxt.js で Markdown ベースのブログを構築する」シリーズの一部です。Nuxt.js で Markdown ベースのブログを構築する（Markdown 編）Nuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編）Nuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編） ← ここ今回はサイトのパフォーマンスをあげるためにやったことをまとめる。サイト構築初期の状態サイトを構築したばかりの頃の Lighthouse のスコアは次のような感じだった。サイト構築初期の Lighthouse のスコア「Progressive Web App」のスコアが低いのは、Service Worker を使っていなかったのが要因で、「Accessibility」と「SEO」のスコアが低いのは、単に自分が書いたマークアップの品質が低かったため。注目すべきは「Performance」と「Best Practices」の 2 つだ。特別なことはそれほどしていないにも関わらず、はじめから非常に高いスコアが出ていた。Nuxt.js と Netlify を使ったおかげと言える。Nuxt.js の恩恵Nuxt.js は、特に設定しなくても、コード分割（Code splitting）CSS の HTML へのインライン展開Resource Hints によるリソースの事前取得の設定といった、Web フロントエンドの最新のベストプラクティスを自動でやってくれる。この点は、Web フロントエンド界隈から生まれたフレームワークの強みで、以前からある Jekyll や Hugo といった静的サイトジェネレーターとの決定的な差だと思う。Netlify の恩恵Netlify は、HTTP2SSLといった、サイトパフォーマンスには欠かせない機能を無料で提供してくれるのがありがたい。しかも設定がとても簡単で、SSL なんかはボタンを 1 クリックするだけで作業が完了して感動した。追加でやったことというわけで、あとは細かい点をチューニングするだけだった。主にやったことはこんな感じ。バンドルファイルの最適化nuxt build --analyze（または build プロパティの analyze オプション）を使って、バンドルファイルの中身を分析Qiita API のレスポンスをまるごと含まれた巨大な JSON ファイルがバンドルされていたのを発見。最小限のフィールドのみを保存するようにした。PWA 化（Service Worker の導入）Nuxt.js の PWA モジュール を利用した。アクセシビリティ対応SVG のアクセシビリティ対応テキスト色のコントラストを調整した。Chrome 64 から使える DevTools の新機能が便利だった。アクセシビリティについては、まだまだ勉強不足。。。HTTP/2 Server PushHTTP/2 Server Push on Netlify | Netlify を参照。自前の Nuxt.js モジュールを書いてやってみた。けど、ほとんどパフォーマンス上の変化はなかった。結果ほぼ 100 点になった 🎉 （Performance は計測するごとに多少のばらつきがあるが 90 点以上は出てる。）チューニング後の Lighthouse のスコアまとめシンプルなサイトだということもあるが、Nuxt.js と Netlify のおかげで、わりと簡単にパフォーマンスの高いサイトを構築することができた。とはいえ、時間の経過とともに、問題も出てくるだろうから、定期的にチェックしていきたい。ちなみに、サイトパフォーマンスの改善方法については、超速! Web ページ速度改善ガイドがとても参考になる。基本的な知識から最新の Web 技術まで体系的に学べる良書でおすすめです。

Nuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編）

この記事は「Nuxt.js で Markdown ベースのブログを構築する」シリーズの一部です。Nuxt.js で Markdown ベースのブログを構築する（Markdown 編）Nuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編） ← ここNuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編）今回は Nuxt.js 側の実装について紹介する。記事ページの実装本ブログでは、記事ページの URL を /posts/YYYY-MM-DD/xxx-yyy-zzz/ というルールにしている。このような動的なルーティングを Nuxt.js で実装するには、pages└── posts/    └── _date/       └── _slug/            └── index.vueというディレクトリ構造にするだけで済む。_ で始まるディレクトリ名はパラメータとして扱われる。つまり、 _date と _slug がそれぞれ YYYY-MM-DD と xxx-yyy-zzz に該当する。pages/posts/_date/_slug/index.vue の中身を見てみよう。<template>  <div>    <h1>{{ title }}</h1>    <div class="post-meta"><time>{{ params.date }}</time></div>    <div v-html="bodyHtml"></div>  </div></template><script>  import { sourceFileArray } from '../../../../content/posts/json/summary.json';  export default {    validate({ params }) {      return sourceFileArray.includes(`content/posts/${params.date}-${params.slug}.md`);    },    asyncData({ params }) {      return Object.assign({}, require(`~/content/posts/json/${params.date}-${params.slug}.json`), { params });    },    head() {      const title = `${this.title} - jmblog.jp`;      const url = `https://jmblog.jp/posts/${this.params.date}/${this.params.slug}/`;      return {        title: title,        meta: [          { hid: 'og:url', property: 'og:url', content: url },          { hid: 'og:title', property: 'og:title', content: title },        ],        link: [{ rel: 'canonical', href: url }],      };    },  };</script><style>  @import 'assets/tomorrow-night-bright.css';</style><style lang="scss" scoped>  .post-meta {    font-size: 0.8em;    color: #888;    margin-top: -1rem;    margin-bottom: 2.4rem;    text-align: right;  }</style>Vue.js の単一ファイルコンポーネントになっていて <template>、<script>、<style> の 3 つで構成されている。<template><template> の中はすごくシンプル。後述する <script> の asyncData メソッドで用意したデータ（タイトルと投稿日と Markdown から変換した HTML）を流し込んでいるだけ。<script><script> がこのファイルのメインとなる。まず validate メソッドで、アクセスされたページが実際に存在しているかをチェックしている。ここでは、前回の記事で紹介した summary.json の sourceFileArrayフィールドに、対象の Markdown ファイルのパスが含まれているかどうかで、ページの存在を判定している。ちなみに params という引数が渡ってきているが、ここには先ほど説明した pages/ 以下の _ で始まるディレクトリ名とその値がセットされている。つまり、/pages/2018-01-01/new-post/ という URL にアクセスした場合、params の中身はparams = {  date: '2018-01-01',  slug: 'new-post',};のようになる。asyncData メソッドでは、該当する記事ページの JSON ファイル（Markdown ファイルから変換したもの）を読み込んでいる。JSON オブジェクトだし、Markdown で書いた本文も HTML に変換済みなので、そのまま return して <template> に渡すだけで済む。最後に head メソッドでは、<head> の中身（title とか description）をセットしている。<style><style> で import しているのは highlight.js 用のテーマ CSS。ちなみに、以前私が作って、本家のリポジトリに取り込まれたファイルだったりする。静的ファイルの書き出しNuxt.js では nuxt generate コマンドで HTML ファイルが生成することができるが、動的なルーティングは無視されるため、そのままだと各記事ページは生成されない。これらの HTML ファイルも生成するには nuxt.config.js の generate オプションを使う必要がある。ここでも summary.json が活躍する。const { sourceFileArray } = require('../content/posts/json/summary.json');const sourceFileNameToUrl = require('./sourceFileNameToUrl');const generateDynamicRoutes = (callback) => {  const routes = sourceFileArray.map((sourceFileName) => {    return sourceFileNameToUrl(sourceFileName);  });  callback(null, routes);};module.exports = {  //...  generate: {    routes: generateDynamicRoutes,  },  //...};これで dist ディレクトリには posts/2018-01-01/new-blog/index.html といったファイルが生成されるようになる。sitemap.xml の生成sitemap.xml は @nuxtjs/sitemap を使えば簡単に生成できる。npm か yarn でインストールしたあと、nuxt.config.js に追加する。module.exports = {  //...  modules: ['@nuxtjs/sitemap'],  sitemap: {    path: '/sitemap.xml',    hostname: 'https://jmblog.jp',    generate: true,    exclude: ['/404'],    routes: generateDynamicRoutes,  },};動的ルーティングはやはりデフォルトでは無視されるため、routes オプションに、上で説明した generate と同じものを渡す必要がある。まとめというわけで、かなりお手軽に Nuxt.js で Markdown ベースのブログシステムを構築することができた。Nuxt.js は公式ドキュメントが充実していてほとんど迷うことがなかったし、Vue.js の単一ファイルコンポーネントもかなり書き心地がよかった。（もう少し複雑な Web アプリケーションになると違ってくるかと思うが。）Nuxt.js といえば、サーバーサイドレンダリングのためのフレームワークだという印象だったのだが、静的ファイルジェネレーターとしてもかなり使いみちが広いんじゃないかと今回感じた。機会があればまた使ってみたいと思う。サイトパフォーマンス編 に続く。

Nuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編）

この記事は「Nuxt.js で Markdown ベースのブログを構築する」シリーズの一部です。Nuxt.js で Markdown ベースのブログを構築する（Markdown 編） ← ここNuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編）Nuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編）本ブログは、Markdown で記事を書き、Nuxt.js の静的ファイル生成機能を使って静的ファイルを書き出し、Netlify を使ってホスティングするというシステム構成になっている。具体的にどのようにしているか簡単に紹介する。processmd を使った Markdown ファイルの変換処理それぞれのブログ記事は YYYY-MM-DD-xxxxx.md という Markdown ファイルに書いている。ファイルの先頭に YAML front matter でメタ情報を記述するという、ブログ記事によく見られるフォーマットになっている。---title: 記事のタイトルcreated_at: 2018-01-01---## 見出し 2本文です。```javascriptconst f = () => {};```この Markdown ファイルは、Nuxt.js の中で変換処理を行うと複雑になるので、あらかじめ Nuxt.js（というか JS）で扱いやすいように、JSON ファイルに変換している。この処理に使っているのが processmd という CLI ツールで、これがとても便利だった。例えば、上にあげたような Markdown ファイルを processmd コマンドに渡すと{  "title": "記事のタイトル",  "created_at": "2018-01-01T00:00:00.000Z",  "bodyContent": "## 見出し 2\n\n本文です。\n\n```javascript\nconst f = () => {};\n```",  "bodyHtml": "<h2>見出し 2</h2>\n<p>本文です。</p>\n<pre><code class=\"hljs\"><span class=\"hljs-keyword\">const</span> f = <span class=\"hljs-function\"><span class=\"hljs-params\">()</span> =&gt;</span> {};</code></pre>",  "dir": "content/posts",  "base": "2018-01-01-test.json",  "ext": ".json",  "sourceBase": "2018-01-01-test.md",  "sourceExt": ".md"}といった JSON ファイルに変換してくれる。Front matter で書いたメタ情報はそれぞれフィールドとなり、bodyContent には元の Markdown が、 bodyHTML にはそれを markdown-it で HTML に変換した値が含まれる。よく見てもらえばわかるように、コードブロックは highlight.js が適用された状態の HTML で書き出されるので、あとは highlight.js 用のテーマ CSS を読み込むだけで、簡単にシンタックスハイライトが導入できる。また、--stdout というオプションをつけると、同時にサマリーファイルも書き出すことができる。$ processmd content/posts/**/*.md --stdout --outputDir content/posts/json > summary.jsonsummary.json はこんな感じ。{  "fileMap": {    "content/posts/json/2007-09-25-link-visited-hover-active.json": {      "title": ":link、:visited、:hover、:active の記述順序とその覚え方",      "created_at": "2007-09-27T00:00:00.000Z",      "dir": "content/posts/json",      "base": "2007-09-25-link-visited-hover-active.json",      "ext": ".json",      "sourceBase": "2007-09-25-link-visited-hover-active.md",      "sourceExt": ".md"    },    "content/posts/json/2012-12-05-sass-if-function.json": {      "title": "Sass の if 関数",      "created_at": "2012-12-05T00:00:00.000Z",      "dir": "content/posts/json",      "base": "2012-12-05-sass-if-function.json",      "ext": ".json",      "sourceBase": "2012-12-05-sass-if-function.md",      "sourceExt": ".md"    },    "content/posts/json/2011-03-21-innerHTML-returns-serialized-html.json": {      "title": "innerHTML や jQuery.html() は HTMLをそのまま取得できるわけではない",      "created_at": "2011-03-21T00:00:00.000Z",      "dir": "content/posts/json",      "base": "2011-03-21-innerHTML-returns-serialized-html.json",      "ext": ".json",      "sourceBase": "2011-03-21-innerHTML-returns-serialized-html.md",      "sourceExt": ".md"    }  },  "sourceFileArray": [    "content/posts/2007-09-25-link-visited-hover-active.md",    "content/posts/2011-03-21-innerHTML-returns-serialized-html.md",    "content/posts/2012-12-05-sass-if-function.md"  ]}Markdown ファイル名に日付（YYYY-MM-DD）を使っておくと sourceFileArray は日付順に並ぶので、記事一覧リストの実装にそのまま利用することができた。また、本ブログでは使っていないが --preview オプションを使うと、指定した文字分だけコンテンツの先頭をテキストで書き出してくれる。「記事一覧リストに本文の概要を載せたい」といった場合に便利だと思う。{  "title": "記事のタイトル",  "created_at": "2018-01-01T00:00:00.000Z",  "bodyContent": "## 見出し 2\n\n新しいブログ記事です。\n\n```javascript\nconst f = () => {};\n```",  "bodyHtml": "<h2>見出し 2</h2>\n<p>新しいブログ記事です。</p>\n<pre><code class=\"hljs\"><span class=\"hljs-keyword\">const</span> f = <span class=\"hljs-function\"><span class=\"hljs-params\">()</span> =&gt;</span> {};</code></pre>",  "preview": "見出し 2\n\n新しいブログ記事です。\n\nconst f = () = {};\n`"}Nuxt.js 編 に続く。

Nuxt.js で Markdown ベースのブログを構築する（Markdown 編）

2013 年から長らく放置していたブログを新しくした。以前のブログは WordPress を使っており、時折 WordPress 自体のアップデートはしていたものの、ほとんどの記事は古くて役に立たなくなっていたし、HTTPS 化もしていなかったし、スパムコメントも届いていたしで、インターネットを汚しているなぁという罪悪感がずっとあった。昨年末の休みに、ようやく重い腰を上げて作り直した。今回は WordPress をやめて Nuxt.js を採用した。詳しくは別途投稿しようと思う。古い記事については、アクセスがあって、内容もまだ賞味期限が切れていなさそうなものだけピックアップして移行した。また、最近は Qiita へもいくつか投稿していたため、API で取得して記事一覧に追加した。ホスティングは Netlify を使っている。いいサービスだと聞いていたが、実際に使ってみると UI もわかりやすく、デプロイも驚くほど簡単で感動した。HTTPS 化もあっけなく完了。長年の懸念をようやく払拭できて、すっきりした。2018 年もがんばっていこう。

Nuxt.js を使ってブログを新しくした

Vanilla JS や TypeScript を使って Web Components の Custom Elements を書いてビルドした結果、ブラウザのコンソールにFailed to construct 'HTMLElement': Please use the '...

Vanilla JS や TypeScript で Custom Elements を書く際の注意点

WebdriverIO からヘッドレス Chrome を起動してブラウザテストを実施する手順をまとめます。必要条件Chrome 59 以降がインストールされていることWebdriverIO およびブラウザテストについてSeleniumアレルギーのための処方箋...

WebdriverIO + ヘッドレス Chromeでローカルブラウザテスト

moment.js を利用する際、const moment = require('moment');と書いて webpack でビルドすると、**生成される bundle ファイルのサイズが非常に大きくなってしまいます。**これは、moment.js が持つすべてのロ...

webpack で moment.js の無駄なロケールファイルを除去する

CI（継続的インテグレーション）のビルド処理の中で patch の適用を実行する際の注意点です。問題点CI（継続的インテグレーション）のビルド処理で cache に前回のファイルが残っていると、2回目のビルドで Reversed patch と判断されて元に戻ってしま...

CI のビルド時に patch を適用する際の注意点

これは CSS Preprocessor Advent Calendar 2012 の 5 日目の記事です。今日はあまり知られていない Sass の if 関数について紹介したいと思います。Sass には、条件分岐のための制御構文として @if ディレクティブ（いわゆる if 文）が用意されています。$type: ocean;p {  @if $type == ocean {    color: blue;  } @else {    color: black;  }}Sass の紹介記事の中では必ずと言っていいほど出てきますし、皆さんも一度は使ったことがあるのではないでしょうか。実はこの @if ディレクティブ以外に、Sass には if 関数が標準で用意されています。上のコードを if 関数を使って書き直すと、次のようになります。$type: ocean;p {  color: if($type == ocean, blue, black);}1 行で非常に簡潔に書くことができました。🙂@if ディレクティブとの一番の違いは、値でしか利用できない点です。例えば、次のようにプロパティごと返そうとしてもエラーになります。$type: ocean;p {  if($type == ocean, color: blue, color: black);}複数の条件分岐があるケースはこのようになります。ただし、コードの可読性が落ちるので、素直に @else if を使ったほうがよいように思います。$type: monster;p {  color: if($type == ocean, blue, if($type == matador, red, black));}このように、使い道は @if ディレクティブよりも限定されますが、うまく使うと、スマートにコードを書くことができます。例えば、以下は Compass の中で実際に使われている事例です。@mixin transform-origin(  $origin-x: $default-origin-x,  $origin-y: $default-origin-y,  $origin-z: false,  $only3d: if($origin-z, true, false)) {  $origin: unquote('');  @if $origin-x or $origin-y or $origin-z {    @if $origin-x {      $origin: $origin-x;    } @else {      $origin: 50%;    }    @if $origin-y {      $origin: $origin $origin-y;    } @else {      @if $origin-z {        $origin: $origin 50%;      }    }    @if $origin-z {      $origin: $origin $origin-z;    }    @include apply-origin($origin, $only3d);  }}第 4 引数 $only3d の初期値は、第 3 引数 $origin-z の値によって true か false がセットされるようになっていますが、if 関数を使うことで非常にわかりやすいコードになっているのが見てわかるかと思います。というわけで、if 関数の紹介でした。

Sass の if 関数

element.innerHTML を使うと、その要素内の HTML を取得することができます。Mozilla Developer Network (MDN) には次のように書いてあります。innerHTML は、与えられた要素に含まれる全てのマークアップ と内容を設定または取得します。-- element.innerHTML – MDC Doc Center よりまた、jQuery.html() も、innerHTML と同様、HTML を取得することができます。Get the HTML contents of the first element in the set of matched elements.-- .html() – jQuery API よりでも、これらのメソッドを使っても、HTML のソースをそのまま取得できるわけではないことをご存知でしたか？私は知らずにハマってしまいました。ということで、以下、調べてみた結果です。例 1<div id="main">  <ul>    <li>coffee</li>    <li>coke</li>    <li>red bull</li>  </ul></div><script>  var html = document.getElementById('main').innerHTML;  console.log(html);</script>この例では、次のような期待通りの HTML が返ってきます。<ul>  <li>coffee</li>  <li>coke</li>  <li>red bull</li></ul>例 2しかし、次の場合はどうでしょうか？<div id="main">  <p><div>foo</div></p></div><script>  var html = document.getElementById('main').innerHTML;  console.log(html);</script>コンソールに出力されるのは<p><div>foo</div></p>だと期待するかもしれませんが、実際は<p></p><div>foo</div><p></p>という文字列が返ってきます。jQuery.html() の場合も同じ結果になります。なぜこのようなことが起こるのでしょうか？不思議に思い、Quora で質問を投げてみました。すると、すぐにどなたかが答えてくれました。（Quora すげー！）また、Twitter でも同様の質問を投げてみたところ、@hogenishi1122 さんが答えてくれました。（感謝！）innerHTML や jQuery.html() は HTML のソースをそのまま返すわけではなく、ブラウザが一度 DOM ツリーに変換したものを返すとのこと。従って、invalid な HTML コードだと、ブラウザが解釈した DOM ツリーが返ってくるというわけでした。invalid な HTML を書かなければ、さほど問題にはならないかもしれませんが、必ずしも世の中がすべて valid だとは限りません。記憶の片隅に留めておけば、無用な苦労をすることもないかと思います。

innerHTML や jQuery.html() は HTMLをそのまま取得できるわけではない

cron が crontab で設定した時間どおりに実行されないという現象に出くわして困ったのですが、何とか解決できたのでその方法を紹介しておきます。まず、以下のような設定（1 分ごとに実行）をしてみると、期待したとおりに動いている様子。* * * * * date >> /path/to/cron_check.txt次に、以下のような設定（14 時台で 1 分毎に実行）をしてみると、14 時台にも関わらず実行されません。* 14 * * * date >> /path/to/cron_check.txtもしかしてタイムゾーンがズレているのかも、と思い、次のように仕込んでみました。* 0 * * * echo '0' >> /path/to/cron_check.txt* 1 * * * echo '1' >> /path/to/cron_check.txt* 2 * * * echo '2' >> /path/to/cron_check.txt* 3 * * * echo '3' >> /path/to/cron_check.txt　　：* 22 * * * echo '22' >> /path/to/cron_check.txt* 23 * * * echo '23' >> /path/to/cron_check.txtすると 14 時台なのに、cron_check.txt に出力されたのは「0」。やはりタイムゾーンが狂ってるっぽいです。NetBSD で cron の動作時間がずれる - CORY's twilight zone を参考にして、crontab の先頭にTZ="Japan"を追記してから$ sudo /sbin/service crond restartで cron のサービスを再起動したところ、無事、時間通りに実行されるようになったのでした。（TZ="Japan" の代わりに CRON_TZ="Japan" としてもうまくいきました。）もし、同じような問題に出会った方は試してみてください。

cronが設定した時間どおりに実行されない場合の対処法

スタイルシートでa要素のリンクのデザインをする際に、次のように 4 つの擬似クラスを用いることが多いと思います。a:link {  color: blue;}a:visited {  color: purple;}a:hover {  color: red;}a:active {  color: yellow;}実はこの 4 つの擬似クラスの記述順序には注意が必要で、linkvisitedhoveractiveの順番で記述しないと意図した結果にならなかったりします。この順序についてちょっと調べてみたので、まとめてみたいと思います。なぜこの順番じゃなければダメなのか？実践 Web Standards Design には、次のように書かれています。:hover 擬似クラスと:active 擬似クラスは一連の動作であるので、スタイルシート内でもこの順番で記述しないと有効にならない点に注意してください。--「3 章 3.3/CSS 管理のコツ」より擬似クラスの記述順序には注意が必要です。（略）常に最後の指定で上書きされるということに注意し、link、visited、hover、active の順番で記述しておくと問題ないでしょう。逆に、すでに訪問済みのリンクは背景画像を変えたくないということであれば、visited を最後に記述するとよいでしょう。-- 「7 章 16/背景画像を利用して訪問済みリンクを一工夫する」より擬似クラスの記述順序にルールがあるというのを知ったのは、実はこの本がきっかけでした。それまでは「hover が効かない！」とか「訪問済みのリンクの色が変わらない！」とかいった問題に出くわしてハマッた経験が何度かあったので、書く順番が原因だったことがわかったときは思わず「そうだったのか！」とひざを打ってしまいました。で、勢いづいてもう少し調べてみると、CSS の権威である Eric Meyer 氏のサイトでも同じ内容に関する解説を見つけました。🔗 Link Specificity – meyerweb.comカンタンにまとめてみると、セレクタの固有性（specificity）は 4 つとも同じ。なので、最後に書かれたものから優先的に適用される。例えば、link、active、hover、visited の順番で記述しているとすると・・・未訪問リンクの場合は、active を hover が打ち消すので active は無効になる。従って、active は hover の後ろに記述しなければならない。訪問済みリンクの場合は、active も hover も一番最後の visited が打ち消してしまって無効になる。従って、visited は hover や active の前に記述しなければならない。つまり、link、visited、hover、active の順番で書くべし。ちなみに、link と visited は打ち消しあうことがないので順番はどっちでも OK。link はあくまで「未訪問（unvisited）」のリンクのみに適用される擬似クラスで、「リンク全般」に適用されるものじゃないので要注意。link じゃなくて unvisited にすればいいのにね。順番の覚え方海外では、この記述順序ルールを link-visited-hover-active の頭文字をとって「LVHA」と言うようです。ちょっと覚えづらいなぁと思っていたのですが、たまたま見かけた海外のブログにうまい覚え方が紹介されていました。🔗 How To Remember The Order of Selectors: LOVE and HATE – CSS TricksJust think 'LOVE' (LV) and 'HATE' (HA)....LOVE and HATE かぁ。ちょっと意味深だし覚えやすいですね。

:link、:visited、:hover、:active の記述順序とその覚え方

ブラウザには、ログイン画面などのフォームで入力した内容を保存して、次回の入力時に自動で候補リストとして表示してくれる「オートコンプリート」という機能があります。とても便利な機能なのですが、一度間違って入力してしまった場合でも候補リストに残ってしまうのが、ちょっと困りものです。Firefox では、次のキーを押すことでオートコンプリートの候補リストから削除することができます。MacOS の場合： Shift + DeleteキーWindows の場合： Delete キー下記のサポートページに詳しい方法が載っているのでご参照ください。すべての入力履歴を消す方法や、オートコンプリートの機能を無効にする方法も紹介されています。参考：フォームの自動補完 | Firefox ヘルプ

jimbo

2025年9月ウズベキスタン旅行記【2日目ブハラ(1)】

2025年9月ウズベキスタン旅行記【1日目タシュケント】

2025年9月ウズベキスタン旅行記【準備編】

【ウズベキスタン旅行】クレジットカードが使えた場所、現金しか使えなかった場所

【ウズベキスタン旅行】持っていってよかったものと持っていかなくて後悔したもの

【ウズベキスタン旅行】両替の悩みを解消するWise活用法

無印良品ハードキャリーケースのハンドルを自分で交換してみた

2023年振り返り

「専門性を活かす」Ubieのソフトウェアエンジニア募集が細分化しました

CSSプロパティを自動ソートしただけで、CSSのファイルサイズを（少しだけ）減らせた話

2022年振り返り

SSGとしてのAstroとNext.jsを比較してみた

症状検索エンジン「ユビー」のUXライティングを改善している話

BudouXを使って記事のOGP画像を見やすくする

2021年振り返り

ブログを Nuxt.js から Next.js に移行した

「0→1」フェーズにおける技術的負債との向き合い方

private な npm パッケージを Dockerfile でインストールして GitHub Actions でビルドする

2020年振り返り

地方で暮らしながら都内のスタートアップでのびのびと働くソフトウェアエンジニアの話

2019年振り返り

FRONTEND CONFERENCE 2019 に登壇しました

lit-html と ShadyCSS

Nuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編）

Nuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編）

Nuxt.js で Markdown ベースのブログを構築する（Markdown 編）

Nuxt.js を使ってブログを新しくした

Vanilla JS や TypeScript で Custom Elements を書く際の注意点

WebdriverIO + ヘッドレス Chromeでローカルブラウザテスト

webpack で moment.js の無駄なロケールファイルを除去する

CI のビルド時に patch を適用する際の注意点

Sass の if 関数

2025年9月ウズベキスタン旅行記 【2日目 ブハラ(1)】

2025年9月ウズベキスタン旅行記 【1日目 タシュケント】

2025年9月ウズベキスタン旅行記 【準備編】

【ウズベキスタン旅行】クレジットカードが使えた場所、現金しか使えなかった場所

【ウズベキスタン旅行】持っていってよかったものと持っていかなくて後悔したもの

【ウズベキスタン旅行】両替の悩みを解消するWise活用法

無印良品 ハードキャリーケースのハンドルを自分で交換してみた

2023年振り返り

「専門性を活かす」Ubieのソフトウェアエンジニア募集が細分化しました

CSSプロパティを自動ソートしただけで、CSSのファイルサイズを（少しだけ）減らせた話

2022年振り返り

SSGとしてのAstroとNext.jsを比較してみた

症状検索エンジン「ユビー」のUXライティングを改善している話

BudouXを使って記事のOGP画像を見やすくする

2021年振り返り

ブログを Nuxt.js から Next.js に移行した

「0→1」フェーズにおける技術的負債との向き合い方

private な npm パッケージを Dockerfile でインストールして GitHub Actions でビルドする

2020年振り返り

地方で暮らしながら都内のスタートアップでのびのびと働くソフトウェアエンジニアの話

2019年振り返り

FRONTEND CONFERENCE 2019 に登壇しました

lit-html と ShadyCSS

Nuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編）

Nuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編）

Nuxt.js で Markdown ベースのブログを構築する（Markdown 編）

Nuxt.js を使ってブログを新しくした

Vanilla JS や TypeScript で Custom Elements を書く際の注意点

WebdriverIO + ヘッドレス Chromeでローカルブラウザテスト

webpack で moment.js の無駄なロケールファイルを除去する

CI のビルド時に patch を適用する際の注意点

Sass の if 関数

2025年9月ウズベキスタン旅行記【2日目ブハラ(1)】

2025年9月ウズベキスタン旅行記【1日目タシュケント】

2025年9月ウズベキスタン旅行記【準備編】

無印良品ハードキャリーケースのハンドルを自分で交換してみた