
# i18nあるある

[json ファイルの typo を防ぎたい](https://zenn.dev/itizawa/scraps/c68fe774fd6f9b) を読んで、あるある、と思った。

翻訳リソースファイルを複数用意する場合に、キーが微妙に一致してなくて...みたいな問題が起こりがち。片方には作成済みだがもう片方には漏れていて、みたいなのもありがち。

なので、TypeScriptでキーが一致することを検証するようにしている。

（ただし、２ヶ国語対応だからできているという面もある。大量の言語、大量のJSONファイル、大量のキーがある場合にワークする方法ではないと思う。）

# TSファイルの動的生成

翻訳ファイルが存在しているディレクトリを読みに行き、以下のようなファイルを生成している。

(`genI18NextDts.js` の詳細は省略。普通に、`fs` でディレクトリを読んで、いい感じにテンプレートリテラルなど使って内容を組み立てているだけなので。)

```ts
/** This file is generated by scripts/genI18NextDts.mjs */
import authJa from '../../../public/locales/ja/auth.json';
import commonJa from '../../../public/locales/ja/common.json';
//...
import authEn from '../../../public/locales/en/auth.json';
import commonEn from '../../../public/locales/en/common.json';
// ...
type IsEqual<T, U> = (T extends U ? (U extends T ? true : false) : false) &
  ([T, U] extends [{[k: string]: unknown}, {[k: string]: unknown}]
    ? {
        [K in keyof T | keyof U]: K extends keyof T
          ? K extends keyof U
            ? IsEqual<T[K], U[K]>
            : false
          : false;
      }[keyof T | keyof U] extends true
      ? true
      : false
    : true);
// eslint-disable-next-line @typescript-eslint/no-unused-vars
function assertTypeIsEqual<T extends true>(): void {}

// Check that all locales have the same keys
assertTypeIsEqual<IsEqual<typeof authJa, typeof authEn>>();
assertTypeIsEqual<IsEqual<typeof commonJa, typeof commonEn>>();
// ...
```

こうしておくと、ビルド時にチェックが走る。えらい。
ただし、「どのキーが漏れているか」まではエラーとして出せていないので、改善の余地はある。
また、そもそもTSの型チェック機構に乗っかるのではなく、普通に動的なテストとして実装してしまうのもありだとは思う。



埼玉県は大宮にて開催されました、[Saitama.js vol.5](https://saitamajs.connpass.com/event/272660/)で登壇してきました。

Saitama.jsは、はぜさん（[@haze_it_ac](https://twitter.com/haze_it_ac)）とりゅーそうさん（[@ryusou_mtkh](https://twitter.com/ryusou_mtkh)）が主催・運営されているJavaScript関係ならなんでもありな初心者歓迎イベントです。オフラインでの開催は初とのことで、今回はりゅーそうさんの所属先でもあるmicroCMSが会場費等サポートしてくださったとのことです。ありがとうmicroCMS。インターネット最高～。

私は、「**【React】Jotaiで作ったフォームをApollo Clientで投げてみたら良さそうだった件**」というタイトルで発表しました。いわゆるやってみた系です（？）。  

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/37b2aa2c2bf94e908db2aff67abdb5c4" title="Jotaiで作ったフォームをApollo_Clientで投げたらいい感じだった件.pdf" allowfullscreen style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>

（サブリミナル春日部つむぎ。埼玉県民の基礎教養だと思ってたら、そう思っているのはインターネットのオタクだけだったてなワケ。布教完了です。）

---

現在、本業でもこのスタイルに近しい形でフォームを実装しています。実際の画面はより複雑度が増すのですが、状態に応じてフィールドを入れ替えたり..とかも簡単に実装できて、個人的には気に入っています。（比較的ワークしている印象はありますが、資料の中で指摘されている問題も同時に普通に抱えている...という感じですね）  

フォームの作成はフロントエンドの中でも頻出であるにもかかわらず、「これが圧倒的正解だな～」と言えるパターンがまだ存在しない分野な気がしています。なんかこの方針でラッパーライブラリでも書けたらいいわね、という感じです。

が、変にラップしてしまうとJotaiの持つ柔軟性を棄損してしまうよなァという気もしています。難しいところ。「結局木の棒がなんにでも使えていいじゃん。なんで切り出してナイフにするの？」みたいな話かもしれません。下手なたとえ話なので気にしないでください。

---

他の方々の発表もメチャ良く、また全然本筋と関係ないですがVの音楽のオタクが炙り出されたりしたのがとても良い感じでした。ぜひまたやりましょう。



すでに参加枠を超える応募をいただいているので、今更な告知ですが一応。

```twitter
1602945340369698816
```

「[フロントエンドLT新年会 - 20代の現役エンジニア5人が語る](https://thecoo.connpass.com/event/269188/)」というイベントにて登壇します。 

以下は公式サイトからコピペ。 

---

## イベント概要　
各所で活躍中の現役フロントエンドエンジニア５人をお迎えしてゆるLT会を開催します。  
また、LT会の後は新年会を兼ねて懇親会を行います。  
登壇者の発表を聞いたり、お酒や軽食を片手に交流して、フロントエンドエンジニアの皆様と共に2023年の良いスタートを切れればと思います。  
軽食やお酒は無料にて提供させて頂きますので是非お気軽にお越しくださいませ。  
※本イベントはオフラインでの実施となります。マスクをご着用の上会場までお越しいただけると幸いです。  

## 詳細
【開催日時】 1月18日（水） 19:30〜22:00予定 【会場】THECOO社のイベントスペース  
　東京都渋谷区神宮前2-34-17 住友不動産原宿ビル9F  
　※東京メトロ副都心線『北参道』駅 出口より徒歩5分  
【参加方法】connpassページからお申し込みください  
【参加枠】50名  
【イベントハッシュタグ】「 #thecoo_frontend 」をつけてぜひSNSなどに投稿をお願いします  
【主催】THECOO株式会社  

---

Asazuは「副業やってみた」というそのまんまのタイトルで登壇予定です。  
（フロントあんまり関係ないがいいのか？　いいか。） 

こんなにたくさんの人の前で話すのは初めてなので緊張しますが、LTだしあんまり気負わずやります。わいわい。

---

【追記】

せっかくなので資料を貼っておきます！

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/f5ce7850378d4b86932839e71af34687" title="副業やってみた" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>


あけましておめでとうございます。  
今年はブログを書け、特に技術記事を書け。そういう気持ちですが、焦らずやっていきます。

# 2022振り返り with my tweets

Twitterを眺めながら振り返りをしていきます。  
ちなみに、Twitter検索では、以下のようなクエリで、当該期間のtweetを拾い上げることができます。  
（ただ、ヒットしてくれる件数に上限があるようなので、適宜期間をずらしながらdigりました）


```txt
from:@asazutaiga since:2022-01-01 until:2022-02-01
```

また、Tweetの埋め込みの実装については、[catnoseさんのzenn記事](https://zenn.dev/catnose99/articles/329d7d61968efb)を大いに参考にさせていただきました。ありがとうございます。

## 1月

```twitter
1486334718090317825
```

そうらしい。インターネットはほどほどに。現実世界も大事にしましょう。  
全然関係ないですが、去年の正月明けすぐぐらいに、銀山温泉に行きました。とても良い場所でした。

## 2月

```twitter
1495035575006826497
```

「フロントエンドエンジニア」を自称するためにフロントエンド以外には目もくれずフロントエンドだけ頑張る、みたいなのは意味なくない？と思ってたんでしょうね。多分当たってます。  
結局、Figmaなどを触り、Node.jsのBFFのコードも多少は書き...みたいな感じで、何でもやるぞーっという感じの1年でした。  
今年はいきなりGo言語の勉強を始めたりGCPの勉強を始めたりしています。強みはある程度保ちつつ、さらになんでもできるようになっていきたい。  


## 3月

```twitter
1508698117235179529
```

何回目接種だろう。とにかく新型コロナウイルスのワクチンを打ってたらしい。  
いつまでたっても終息する気配がなく、いよいよwithコロナ時代を生きていかねばなりません。幸いにして私はまだ新型コロナに罹患していないのですが、不安。


## 4月

```twitter
1517485285852184576
```

はい（吐血）  
SQLもNoSQLもちゃんとやっていきましょう、2023。

確かこのへんからJADEでの副業を始めました。

## 5月

```twitter
1523203564285218817
```

そうそう、この時期はfirestoreのTypingでめっちゃ悩んでた...  
ある程度進んだ段階で、 `FirestoreDataConverter` を使っていい感じに型を処理する方法を会得しはしたのですが、やっぱりReactとの相性とかいろいろ辛いなってなることが多かったです。Cacheの扱いとかね。

結局、今のプロジェクトではGo製のGraphQL BFFを挟んでもらうことになりました。敗北感はありますが、Go触れると思うと吉か？ がんばりましょう。

## 6月

```twitter
1533811107600961546
```

これはマジで相変わらず思っています。静的サイトジェネレータの需要増もあいまって、Webアプリを作るフロントエンドエンジニアと、Webサイトを作るコーダー、みたいにがっつり線引きするのも怪しくなっている今日この頃。   
いい感じに越境できるといいね...いいね...

## 7月

```twitter
1545034362894585856
```

苦しんでますね～。いい意味でも悪い意味でも、初めての副業と格闘した2022という感じでした。  
結果として今につながっているので、まあ良いのでしょう。しかし、パフォーマンス出せなくてマジで申し訳ないなと思いながら土日を過ごすのは、精神衛生上あんまりよろしくなかったですね...。  
収入面で大変助かったのは事実ですが、あまりにも大変だったので、ぜひこのお話にはのっかりたい！とかなければ、今後はあんまり副業とかやらない可能性が高いです。

## 8月

```twitter
1558413830933209088
```

Astroと出会いましたね。なんだかWebの未来をいろいろと感じさせてくれる素敵なFWだと思っています。  
Docsの翻訳作業にも参加しているのですが、最近できていない。今年も何本かやろう。焦らず。

## 9月

```twitter
1569355123998216192
```

なんかメンタルと体調がひたすらよくないみたいなtweetばかりが目につきます。  
いや、たぶん過労なんですよねこれ。わからんけど。（所属先がブラックとかでは全くなくて、単に本業と副業を両方ガチると死ぬみたいなのを自覚しつつも無理してた）  
もう少し自己管理をちゃんとしていきたい...。


## 10月

```twitter
1581198220536868864
```

これは結構的を射た表現だと自分では思っていて、「自分の行動一つで世界が変わるわけではないかもしれないが、意思表明とちょっとした干渉をすることによる達成感を得る」みたいな点が共通しているなと思っています。  
ただ、技術記事の場合は実際に読んでくれた人の声がダイレクトに伝わってくるケースとかバズが発生するケースもあるので、一概に同じとは言えないのですが。（あと、手間も結構差があるか...）  
「選挙には行ったほうがいいよね」と思う人なら、それ以上に人々に対して影響を与えうる行為として「技術記事は書いたほうがいいよね」という結論に至れるんじゃないかな？　そういう気持ちで書いた気がします。

## 11月

```twitter
1597777329563963393
```

バタバタとtoridoriを去りました。元弊社の皆様、お世話になりました！！  
フロントエンドエンジニアという肩書でちゃんと仕事をすることになったのがtoridoriが初めてで、本当にたくさんの経験をさせてもらえました。上場前のクソ忙しい時期に去ることになりすみません...
。  
入社当初やりたいと思ったことはだいたいできたかな、って感じだったのと、より自分が身を置いたほうがよさそうな環境が見つかってしまったというのが大きかったです。未練はありませんが、本当に良い会社だったな...。

## 12月

```twitter
1606953626794364928
```

無職編です。この間、前半はJADEでの副業をしていたのですが、疲れがたまっていたこともあり、後半はがっつり休もうという感じで過ごしました。  
ですが、メンタルがどんどん調子を崩していき、大事な人に迷惑をかけてしまいました...。悔やんでも悔やみきれない。  
Awarefyという認知行動療法のアプリを使いながら、最近はなんとか持ち直してきた＆仕事が始まったことによりある程度充実感も得てきたので、2023はしっかり理性を保てるようにしていきたいです。健康第一。

# まとめ

働きすぎはよくない。無理をせず、自分が出せる最大のパフォーマンスを見極めたうえで、2023もいろいろなことにチャレンジしていきたいですね。

# 追記（ご報告）

というわけで[JADE](https://ja.dev/)に正社員としてジョインしました。よろしくお願いします。


長らくブログをさぼってしまったので、まとめっぽい記事を出すなどしてお茶を濁します。

# 仕事

## 本業

引き続き、[株式会社トリドリ](https://toridori.co.jp/)でフロントエンドエンジニアをしています。

（弊社はリファラル採用を実施しています。興味がある人はぜひ、[@AsazuTaiga](https://twitter.com/AsazuTaiga)までご連絡くださいませ。リファラルボーナスが出るので一緒に肉を焼きましょう。）

入社当初は「モダンフロントエンド開発をやってみたい！」という（今思えばかなり浅薄な、しかし切実な）欲求が強かったのですが、入社から一年が経とうとしている現在、その欲求はかなり満たされました。TypeScript、Next.js、GraphQL、Storybook、Vitest etc...を使用して、Webアプリケーション開発をしています。

また、ほとんどバックエンドを触ったことはないのですが、自分なりにデータモデルの話はできるので、フロントにとどまらないシステム全体に亘る機能の設計なども最近はしています。（というか、こっちをやっている時間が多くなっています。）「RDBのことはよくわからないので聞きたいのですが……」が口癖になりつつあり非常にまずいので、もうちょっと真面目にRDB、NoSQLの話ができるようになりたいですね。

まあ、あんまり正解らしい正解がある世界でもないと思うので、周りのエンジニア全員が納得感を持てる提案ができている間はそれでいいのかもしれませんが。設計の勘を掴むには、バックエンドのコードをガリガリ書いていくしかないんだろうな、と痛感しています。机上の空論ですべて片づけるザ・上流SEにだけはならないように気を付けます。

……などと言いつつ、今の自分の関心は、より根本的な問題解決に向かっています。

### 関心① ビジネス自体およびビジネスに対するシステムの妥当性

- このビジネスが解決しようとしている問題と、その手法は何か？　それは適切か？
- このビジネス要求に対して、技術選定を含めたアーキテクチャは適切か？　問題があるとしたらどこか？　どう解決するか？

当たり前のような話ではありますが、日々変わりゆく状況・舞い込んでくるビジネスサイドからの要求に対して、どう答えるか、どうほかのメンバーの力を借りるか、どういう仕様を切るか...そういうことをずっと考えています。（また、こういったビジネス方面の話を考えるばかりで、手元の専門性をおろそかにしていないか？　というのも、常に自問自答しています。）

### 関心② ユーザー視点

- この画面を提示したときにユーザーはどういう心理的な変化を起こし、どういう行動をとるか？

ワイヤーベースの観点と、もう少し踏み込んだインタラクションデザイン部分の観点、そして実装観点で、最適なUIを実現するにはどうすればいいか？　日々頭を悩ませています。

## 副業

先月から[@Ikazuchis_diary](https://twitter.com/Ikazuchis_diary)の紹介で、[インターネットをよくする](https://ja.dev/)副業をしています。こっちはこっちでとても面白いことをやらせていただいている、かつフロント周りに関してはかなり自由に作らせていただいているので、本業と良い相互作用を生み出してくれることを期待しています。（Vitestの導入も、実はこちらの方が本業に先立っていたり。）

# 趣味

## アニメ

今期はパリピ孔明とSPY FAMILYが毎週楽しみで見ています。そのほか、

- かぎなど
- であいもん
- 勇者、辞めます
- 史上最強の大魔王、村人Aに転生する
- 骸骨騎士様、只今異世界へお出掛け中
- このヒーラー、めんどくさい

などを見ています。下に行くにつれて「う～んｗ」という顔をしながら見ていますが、決して嫌いなわけではないです。ただ、最後まで見るのかはかなり怪しいと言わざるを得ません……。

## 俳句

俳句雑誌「奎」への投稿だけはなんとか続けています。それ以外の句会参加などは、コロナで身近な句会がなくなって以来、行っていません。

俳句自体への熱量がそれほど今のところ高くはないのですが、引き続き細々とやっていけたらと思います。たとえ少しであっても、芸術的な表現行為を続けることは、自分の人間としての在り方にかかわる部分なので、消し去りたくはないものです。

> 残雪や未満の語彙を搔き抱く 淺津大雅　『奎』21号「未満の語彙」

## 読書

こういったものを読んだり読まなかったりしています。まあ大体は読みかけです。通読の元気が欲しい。

- 吉田篤弘『ブランケット・ブルームの星型乗車券』
- 小泉悠『現代ロシアの軍事戦略』
- 東浩紀『動物化するポストモダン』

技術書もいろいろ買って積んでいますが、Mike Julian著・松浦隼人訳『入門 監視』の以下のまとめがフロントエンドエンジニア的にはとても刺さったので、引用しておきます。

> ここまで学んだように、フロントエンドの監視は見落とされることが多い一方で、単に監視ができるというだけでなく、その実現も比較的簡単です。あらゆる監視と同じように、永遠に続くかのような興味深い分野ですが、その基礎はシンプルです。
> - 実際のユーザが見ているページのロード時間を監視しましょう。
> - JavaScriptの例外を監視しましょう。
> - ページのロード時間をCIシステムから計測し続け、ロード時間が許容範囲内に収まるようにしましょう。

# 私生活

なんだか、これ以上自分の暮らしはよくなっていくべきなのだろうか、よくなっていくのだとして、それは自分一人のためによくなってもよいのだろうか、という不安感が常にあります。要は孤独なのだと思います。え、この人暗すぎて怖い。

# 世界情勢

こんな風に身近なことを書いた後で、この話を書くのはいささか行儀が悪いというか、こういったものは分けて出すべきなのかもしれませんが。

## ロシアによるウクライナ侵攻

一夜にしてプーチンが悪鬼のごとく報道されるようになり、非常に驚いたというのが最初の感想でした。破壊された都市や生活を奪われた人々の様子がリアルタイムに伝わってきて、なぜ21世紀にもなってこんなことが起こってしまったのかと、かなり精神的に参りました。

プーチンと対照的に、英雄的に報道されるゼレンスキーを見ても、何か違和感ばかりを覚えてしまいます。緩やかな抑圧に対してはガンジー的な解決も（ほんのわずかな可能性として）ありえたのかもしれませんが、ほとんどの侵略はこのようにしてある日突然行われ始めます。日本が同じ状況に立たされた時に、どういう態度を取るべきなのか、いまだに自分の中でも整理がついていません。ただ、自分と周りの人だけでも守れる選択肢を常に持っていたいとは思います。（世界中が戦争になってしまえば、それこそ、逃げ場などどこにもないのでしょうが。）

この状況に対して、私たち一般市民ができることはあまりにも少ないですが、最低限この歴史的犯罪を胸に刻み付けておくことはしておきたい……といった感じで、まあリベラルというのは本当に有事に弱い思想です。平時において平時を守るのが本懐でしょうから、仕方ないのですが……。

# まとめ

つねに心身ともに健康でありたいですね。あ、親知らずを全部抜いてすっきりしました。



この記事は[エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/design-code)の13日目です。

アドカレ経由で興味を持ってくださった方のために自己紹介をします。[asazutaiga](https://twitter.com/asazutaiga)です。フロントエンドエンジニアをしています。

私が特に興味を持っているものは、人とシステムの境界面、すなわちユーザインターフェース一般です。もちろん、境界面を考えるにあたっては【人（あるいは使われ方、ビジネス）】と【システム】という「境界面で接する二項」についても熟知する必要がありますが、その圧倒的に異なる二項を境界面でどのように協調させてより高い効果を得るか、ということに一番関心があります。

アドカレの趣旨的には、より実務方面に依った「エンジニアとデザイナーの協働・歩み寄り」「エンジニアが画面デザインをどう勉強するか（あるいはその逆）」系のお話が多そうなので、また別の角度からデザインやエンジニアリングということについて切り込めないかなと思い、この記事を作成しています。（と言いつつ、読書ノートにいい感じの理由付けをしただけって感じもしますが…）

この記事では、樽本哲也『ユーザビリティエンジニアリング - ユーザエクスペリエンスのための調査、設計、評価手法』（2005初版, 2014第2版, オーム社。以下「本書」）を読んで、私なりに参考になったなと思う内容をメモふうに書いていきます。なお、引用は末尾括弧内にページ数を示します。その他の引用がある場合は適宜出典を示します。「いわゆるデザイン」（視覚的なデザイン）の話はほぼ出てこないのですが、ひとつのシステムを作っていくうえでの不易として、特にUI・UXに興味がある人にとっては充実した内容となっているので、読む価値はあるなと思いました。

# Notes

## ユーザビリティ

> ユーザビリティの訳語として「使いやすさ」がよく使われます。ただ、「ユーザビリティ＝使いやすさ」と捉えていると、“ユーザに対する思いやり”や“ユーザフレンドリ”といった主観的な概念と混同してしまいます。つまり、ユーザビリティとはユーザにとって「あれば嬉しいけれど、なくても困らない」というレベルの要求であると誤解してしまうのです。（中略）しかし、ユーザービリティはもっと重大な意味を持っています。それは「使える」という意味です。つまり、**「ユーザービリティに問題がある」ということは「使えない」という意味でもある**のです。(3-4)

きわめて重要な認識であるにもかかわらず、言われるまで強くは意識していませんでした。Usable=使えるなので当たり前なんですが、なんとなく「使いやすさ」の意味で使ってしまいがちなので、あるあるネタかもしれませんね。

ISO 9241でのユーザビリティの定義では、「効果＝ユーザが目標を達成できるかどうか」、「効率＝なるべく最短経路で目標を達成できるかどうか」、「満足度＝ユーザに不愉快な思いをさせていないかどうか」の3つを満たして、初めてユーザブルであるそうです（参考： [ISO 9241-11のWikipediaリンク（英語）](https://en.wikipedia.org/wiki/ISO_9241#ISO_9241-11)）。この3項のいずれも欠けてはならないというのが重要そうですね。

システム要件の分類でよくつかわれる機能要件・非機能要件という分類よりも、この「効果」「効率」「満足度」のどれに対してどの要件が紐づくのか、といった脳内整理をする方が、最終目標を意識しながらより良いシステムを作れそうだなと感じました。

## ユーザエクスペリエンス（UX）

> （前略）仮に**ユーザビリティが満点であっても、その製品への評価は中程度にとどまる**ということです。（12）

> ソフトウェアの場合も、見た目が魅力的な製品の方がユーザは使いやすく感じます。皮肉にも、どんなにユーザビリティを追求したとしても、それだけでは最高のユーザビリティは得られないということです。（12）

> **UXとは製品の開発が終わってから“上”に被せるものではありません。** 製品開発の一番最初（企画段階）から地道に積み重ねていかない限り、優れたUXは実現できません。（16）

今となっては当たり前の知識のような気もしますが、改めて本書が2005年に国内で出版されているという事実に驚きを禁じえません。

## ユーザの声

> ユーザの声を聞くというのは、極論すれば単なる“ユーザ任せ”に過ぎません。ユーザから出された「〇〇が欲しい」といった明示的な要求にこたえるだけでは不十分です。ユーザ自身が気づいていないような暗黙の要求まで満たしてこそ、プロの設計者としての存在価値があるのです。（25）

本書はここ以外でも、徹底してエンジニア／デザイナーがユーザの言いなりにならないよう戒めます。

現実世界では、「ここを少し変えてくれたら良くなりますよね？」という類の具体的な要望がやってくることが非常に多いです。仮にそのような要望があったとしても、一度エンジニア／デザイナー目線で根本にある問題へと立ち返り、それを解決する方法を考える、というプロセスを挟むのは大事だということですね。

## アンケート

> アンケートは量的調査の手法です。自社製品に対するユーザ全体の満足度などを調べるためには適した手法ですが、個々のユーザの個別の体験をこと細かく調べるための手法ではありません。（27）

直近でとある社内システムのリプレイスを担当しているのですが、先日、「既存のシステムの中で、どの画面を眺めている時間が長いか？」というアンケートをユーザに対して投げかけました。これは、機能開発のロードマップを作っていくうえで、まず一番利用頻度の高い機能を作って、触ってもらいながら改善していくのが適切であろうと考えての内容です。システムのコアな部分の設計にアンケートを用いるのは恐らく間違いですが、こうした開発計画の方針を立てるような場面ではアンケートも使えるなという印象を持ちました。（要するに、どんな調査手法も使いどころを間違えてはいけないということですね）

## 「師匠と弟子（Master/apprentice）」

「師匠と弟子」という人間関係モデルに基づいたユーザインタビュー手法の解説です。

> この手法ではインタビューアを弟子、ユーザを師匠と見立てて、師匠の体験を弟子に“継承”します。基本プロセスは以下のようになります。
>
> 1. インタビューアはユーザに“弟子入り”する。
> 2. ユーザは仕事を見せながら説明する。
> 3. インタビューアは、不明な点があればその場でどんどん質問する。
> 4. 一通り話を聞いたら、インタビューアは理解した内容をユーザに話して、間違ってないかどうかチェックしてもらう。(31)

私の職場でも、エンジニアがユーザ（＝オペレーションスタッフ）にある意味で「弟子入り」する業務体験を実施しています。ただし目的は少し違って、「業務知識を得て、システムの理解に役立てよう」というのが趣旨になっています。それはそれで（例えばジョインしたばかりのエンジニアが業務について知るためなど）有効だなと感じています。

ただ、長く勤めてから同じような業務体験、あるいはユーザインタビューを実施する場合、エンジニア／デザイナーは当然そのシステムを作っている側なので、詳しくて当たり前だという前提ができてしまいそうなのが、この手法の難しいところです。エンジニア／デザイナー側は、無知のベールと言いますか、一度自分の知識を横に置いてはじめてそのシステムを触る人のつもりで教えを請うのがよさそう。難しいですが。

## インタビュー

> ユーザに会って、いきなりインタビューを始めようとしても上手くいきません。ユーザとインタビューアの間にまだ **「信頼関係（ラポール）」** が構築されていないからです。(53)

> ユーザが心配しているのは、「果たして自分は役に立つのだろうか？」ということです。（53）

これは、社内で既に気心の知れている相手に対してインタビューする場合であってもそうなんだろうなと思います。イントロで、インタビューの目的と、どういうスタイルでインタビュー進めるのか（つまり、根掘り葉掘り聞いていきますよ、ということ）を説明して、不安を払拭する必要がありそうです。

> ディティールの度合がわからないと、ユーザは差し当たり抽象的なレベルで話を終えてしまいます。そんな時はディティールの度合を具体的に指示すると、ユーザはインタビューアの要求水準を理解して具体的な話を始めてくれます。
> 
> ＜質問例＞
> - 「一番最近〇〇したときのことを教えてください」
> - 「差し支えなければ、ここで△△を見せていただけませんか」
> - 「最初はどうするのですか。その次は（その前は）どうするのですか」
> - 「××ができないときはどうするのですか」（56）

消化不良のインタビューにしないために大事なコツだと思います。
 
## Tプロトタイプ

> 『水平プロトタイプ』とは、ウェブサイトのトップページと第一階層のページだけを用意するようなプロトタイプです。（中略）一方、『垂直プロトタイプ』とは、特定の機能だけを持ったプロトタイプのことです。（中略）この2つを組み合わせると、実際にユーザが作業を行ってみることができるようになります。このように、 **ある程度の質と深さを持ったプロトタイプを『Tプロトタイプ』** といいます。(104-105)

> このようなクリック操作中心のプロトタイプを制作するときに一番大切なのは、「すべてのリンクやボタンをクリックできるようにすること」です。（109）

これはめちゃくちゃ良いプロトタイピングの具体的な方法論ですね。プロトではどうしても単機能に絞って開発をすることになりますが、実際にユーザに触ってイメージをつかんでもらう上でこうした配慮は必要そうですね。（なお、クリック後の遷移先は、共通のダミーページでもよいそうです。）

## ヤコブ・ニールセン

ヤコブ・ニールセンが提唱した「10ヒューリスティック」と呼ばれるユーザビリティについての一般的なルールについても評価手法の中で触れられています。

外部の評価者が綿密にこれらの基準をクリアしているかを評価する、というのはあまり現実的ではないので、エンジニア／デザイナーが自分の普段作っているシステムを見つめなおす際の「眼鏡」として使うくらいがいいかもしれませんね。

> 1. システム状態の視認性を高める (Visibility of system status)
> 2. 実環境に合ったシステムを構築する (Match between system and the real world)
> 3. ユーザーにコントロールの主導権と自由度を与える (User control and freedom)
> 4. 一貫性と標準化を保持する (Consistency and standards)
> 5. エラーの発生を事前に防止する (Error prevention)
> 6. 記憶しなくても、見ればわかるようなデザインを行う (Recognition rather than recall)
> 7. 柔軟性と効率性を持たせる (Flexibility and efficiency of use)
> 8. 最小限で美しいデザインを施す (Aesthetic and minimalist design)
> 9. ユーザーによるエラー認識、診断、回復をサポートする (Help users recognize, diagnose, and recover from errors)
> 10. ヘルプとマニュアルを用意する (Help and documentation)
> 
> （出典：<https://ja.wikipedia.org/wiki/ヤコブ・ニールセン>

また、本書の後半では、ニールセンの以下のような面白い別の経験則も語られます。

> ヤコブ・ニールセンはテストする人数と発見できるユーザビリティ問題の数に関する公式を明らかにして、 **「5人のユーザでテストをすれば、ユーザビリティ問題の大半（約85％）を発見できる」** という説を唱えました。（171）

「じゃあ5人分だけテストして見つかった問題をすべて直せばいいよね」という単純な話ではないようですが、ユーザテストを実際に実施していくにあたってはかなり前向きになれる数字ですね。（わりと経験則での数字なので微妙な気持ちになるのも事実です。）

# 感想・まとめ

後半、ユーザテストの具体的な手法についての部分は現代だと実際に適用するのは難しいかもしれませんが（なんなら[LogRocket](https://logrocket.com/)とか道具の面では発達しているので選択肢は圧倒的に増えてますね）、特に前半部の理論面で勉強になることが多かった印象です。より現代的手法に寄せたUCD言論がそろそろ登場してきてもいい頃なのかなみたいなことも感じました。

あと、ニールセンの話は面白そうなので、本人の著作も読んでみようかなと思います。（訳書は『[モバイル・ユーザビリティ](https://www.amazon.co.jp/%E3%83%A2%E3%83%90%E3%82%A4%E3%83%AB%E3%83%BB%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3-%E4%BD%BF%E3%81%84%E3%82%84%E3%81%99%E3%81%84UI%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%81%AE%E7%A7%98%E8%A8%A3-%E3%83%A4%E3%82%B3%E3%83%96%E3%83%BB%E3%83%8B%E3%83%BC%E3%83%AB%E3%82%BB%E3%83%B3-ebook/dp/B00G9QJTSS/ref=sr_1_3?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=%E3%83%8B%E3%83%BC%E3%83%AB%E3%82%BB%E3%83%B3&qid=1639410727&s=books&sr=1-3)』くらいしか現行でぱっと安く読めるのがなさそう。原著のほうが安い）




2021年は世間的にもいろいろありましたが、私自身にとっても身の回りに大きな変化のあった年でした。

とりあえず雑に振り返っておこうと思います。

あ、全然関係ないのですが雪を降らせてみました。[react-snowfall](https://github.com/cahilfoley/react-snowfall)お手軽だしおしゃれだし神です

# 転職

もはや誰も彼も言っていることなのでアレですが、受託・SIerとWeb系の毛色の違いは大きいです。個人的にはWeb系の今の会社の方が何を作るにも身軽だし、裁量も大きいので好きです。

## 前職でなにをやっていたか

入社3か月後までは新卒研修でした。プログラミング初心者の文系大学生が最低限オブジェクト指向とはなんぞやというところまで理解できるレベルへ押し上げてくれたので、とても助かったし感謝しています。新卒一括採用で大量に雇用してエンジニアを自社で育て上げ、以降は（**パートナー会社のメンバーを組み込んだチームで利ざやを確保しつつ**）外で稼いで来させるというビジネスモデルなので、なんだかおいしい部分だけフリーライドしてしまった感じでやや申し訳ないです。

その後、1年目の年末ごろまでAndroidカーナビのUIライブラリ開発をしばらく行いました。以降は2案件ほどWebフロントエンドの仕事をしました。

……というと聞こえは良いですが、AndroidはJavaでの開発だったし（が世間にはKotlin旋風が吹き荒れており結構焦りました）、フロントに至っては手探りでjQueryを勉強する哀れな仔羊が一匹生まれていました。（世間ではReactとTypeScriptがもてはやされており、Webアプリケーション開発目的でjQueryを使う奇行をするものはもはや消え去っていました。）

ただ、まったくReact等のモダンな開発と無鉛だったわけではなく、自分で勉強した成果を別の部署の人たちにレクチャーする会をやったり、React + TypeScript + CSS Modulesというそのタイミングで自分では行けてると思ってた組み合わせのテンプレを作って社内にばらまいたりしてました。結果的に後輩の方が私よりも先にjQueryしんどみ現場を脱出するなど面白イベントも多々ありました。面白いですね。

## 転職活動

やはり**まごころのこもったドラッグアンドドロップによるデプロイ**はよいものですが、個人開発でVueやReact等を触り始めるにつれて「自分は今まで何の苦労をしてきたんだ……」「これからも自分はどこにあるともしれないCSSクラスを`$`して`on`するのか……「もう型のない開発に耐えられない、全てを静的型で表現したい」となってきます。しんどいことは良くないことです。

リモートワークで浮いた時間をWantedly経由の面接などに充てる形で1月から転職活動を開始し、複数社との面談等を経て、3月に今働いている会社で内定を頂くことになりました。

やはり成果物を普段からまとめておくことと、自分が仕事の中で何を考え、どういう行動をしてきたかを語れるようになることはとても大事だと思います。前職の現場で経験できたこともひとつひとつ説明すれば共感してくれる方は多かったです。

仮に今転職していなかったとしても、転職活動を通じてベンチャーのボードメンバー層の方々や大小さまざまな企業のエンジニアの皆さんとお話しできたことは、大きな経験だったなと思います。カジュアル面談はいい文化。


## その後

楽しくフロントエンド開発をしています。楽しい！楽しい！

あと、あまり驚きでもないのですが、ベンチャーは人の入れ替わりが激しいです。私が入社したのが半年前なのですが、エンジニアメンバーのうち半数は私よりも後に入社したような形になっています。日々変化する組織がまとまっていく様はなかなか面白いです。

直近では社内システム刷新計画のリーダーをさせてもらったり（**ここでの「リーダー」とは、何もわからいので周りの人にあれこれお願いして助けてもらいながら自分が一番じたばたがんばらないといけない人のこと**）、なかなか刺激的です。Next.js + TypeScript + ApolloClientというめちゃくちゃモダンな技術選定もさせてもらえたし、何より事業部のメンバーと交流しながらドメインを理解してシステムに落とし込んでいくのが、「ああ～ちゃんと役に立つ（予定の）道具を作れてる～」という感じでめちゃくちゃ脳汁が出ます。

急拡大していく組織に耐えうるユーザビリティを持ったシステム開発に対して、全力でコミットしてやるぜ～という感じで来年もやっていきましょう🤞進捗ヤバい



# 2つの方向性 ―ユーザビリティ・ファーストとデータモデル・ファースト―

GUIのデザインには2つの方向性が存在すると筆者は考えています。ユーザビリティ・ファーストと、データモデル・ファーストです。この2つは排他的存在ではなく、常に双方の考え方を取り入れながらデザインが進行されるべきであり、また現実に存在するGUIはすべてそのようになっていると思います。

## ユーザビリティ・ファーストのGUIデザイン

ユーザービリティとは、「そのGUIを使う人から見て、いかに使いやすくするか」という観点でのデザインになります。場合にもよりますが、プログラマーよりはデザイナーの方が、こちらの分野のデザインを得意とする人が多いように感じます。

ユーザビリティを第一に考えてデザインする場合、私たちはそれを使う人――不特定多数のエンド・ユーザー、あるいは特定の社内業務のツールを必要としているスタッフ・ユーザー――をよく観察し、理解する必要があります。使い手のことを知り、使い方を知ることが、使い勝手の良い道具をデザインする上で非常に重要です。

ユーザビリティ・ファーストなデザインとはどういうものかを考えるための例として、一般の人向けの、ショッピング・サイトのデザインを考えてみましょう。

### 使い慣れたフォーマットの存在

ショッピング・サイトはすでに多くの人から支持を受けているフォーマットが存在します。

- 検索ボックスで商品名やメーカー名、ジャンル名をユーザーは入力し、それに該当する商品が一覧で表示されます。
- 商品の特徴（色、価格、サイズなど）によってフィルターし、目的の商品にたどり着きます。
- 商品画像をクリックします。
- 詳細ページに遷移し、複数まうぃの商品画像と詳細情報、「カートへ追加する」ボタンが表示されます。
- 十分に商品の詳細情報を吟味して、ユーザーはカートへ商品を追加し、画面の右上にあるショッピングカートのアイコンをクリックします。そして決済画面へ…。

こうした行動はすでに私たちの体に染みついています。また、ショッピングサイトを始めてみる人であっても、おそらくはそれほど迷わずに操作を行える程度に洗練されたフォーマットです。ですから、同じ目的のサイトを作る場合には、なるべくこれらの見せ方から外れないようにすることが、「誰にとっても使いやすい」を実現する上で非常に重要になります。

### 段階的な改善プロセス

ものを作る人は誰でも、そこにオリジナリティを付け加えたいという色気を出してしまいがちです。例えば次のような。

- 商品の数量を、スライダーで選択できるようにしたらどうだろう・・・？

しかし、現実には、数量のボックスの左右にプラス・マイナスアイコンを設置する方が、はるかに操作は簡単であったりします（水をミリリットル単位で注文するような場合以外は！）。

いくつかの実現方法を考えたうえで、「本当にユーザビリティに資するのはどちらだろうか？」ということを考え、私たちはボタン・テキスト・画像などの既存のパーツを組み合わせながらGUIをデザインします。

時には使いづらいというユーザーのクレームを引き受け、また時にはロギングツールから得られたユーザー行動を分析したうえで、使いやすさを段階的に改善していくことも、ユーザビリティ・ファーストなデザインの重要な領分になります。

一方で、全く異なる考え方をするのがデータモデル・ファーストのGUIデザインです。こちらはデザイナーよりもプログラマーの方が得意である傾向がより顕著だと思います。

## データモデル・ファーストのGUIデザイン

データモデル・ファーストとは、ドメインを表現するデータモデルをより直接的にGUIに落とし込む方針です。この考え方のメリットは、そのシステムの在り方の根幹をなす知識が積極的に見た目のうえで表現されることと、それによる構造のわかりやすさです。

同様に、例えば、次のようなデータを作成するためのUIはどのような形になるでしょうか？

```tsx
type ShoppingUser {
  email: string
  name: string
  age: number
  phoneNubmer: string
  address: string
  creditCards: CreditCard[]
}
```

当然のことながら、「メール」「名前」「年齢」「電話番号」「住所」「クレジットカード情報」を入力するフォームになることでしょう。

### 保守する上での分かりやすさ

デザインを直接的に表現したシステムは、ある意味で単純明快であり、また依存するバックエンドのAPIやテーブルの数も非常にシンプルなものになります。フロントエンドとバックエンドが「密結合」である、という言い方をすると非常にプログラマーからの評判が悪そうですが、厳密にこの方向性を適用している限り、バックエンドで1か所の修正を行えば、フロントエンドでも同様の1か所の修正を行うだけで済むことでしょう（例えば、上記の `ShoppingUser` にプロパティが1つ増えたならば、フォームの要素を1つ増やす、といった具合に）。

# まとめ

これら2つの方向性は、それぞれ人によって、また組織内での役割によって得意・不得意があるものであり、複数人でデザインについて議論することは、これらの方向性をうまく止揚させるのに役立つ場合があります。デザイナーとプログラマーのそれぞれが画面デザインについて口を出すことは、この意味で時として重要です。

一般に、一方についての知識を持ちすぎるともう一方についておろそかになるということがよく起こりますが、デザインの2つの方向性についても同様のことがよく起こります。（一人でデザインを黙々と作っているとよくわからないものが出来上がりがちな原因もこのあたりにあるのかなと考えています。）


# はじめに

所属組織にてスクラム開発が導入され、開発者（たまに兼スクラムマスター）としての経験をすることができたため、知見・感想・課題感などをメモしておきます。

# 用語

ここでは敢えて「スクラムガイド」における原義に拠らず、私の理解で用語を整理します。（どうしても自分が所属している組織の肌感で書いてしまうので、原典のリンクも載せておきます！）

スクラムガイド™： <https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf>


## 基本概念

### スクラム開発

製品にかかわる各役割の人たちが、自己組織化しながら最大効率を目指す開発手法。

### スプリント

一定の期間で区切られたスクラム開発の実施単位。

---

## 役割

### スクラムマスター

スクラム開発において、開発が効率的に進むような仕組みづくりをする人。

基本的にはスクラムイベントの司会が主な作業になるが、バックログの整理をするようプロダクトオーナーを小突いたり、レトロスペクティブで決まった改善作業をやることもある。

### プロダクトオーナー

製品およびプロダクトバックログに対して責任を負う人。

ストーリーを作成して、開発者にタスク分割を依頼したりする。また、バックログの優先順位や、タスクのやる・やらもこの立場の人が決定権を持っている。

### 開発者

実際に手を動かして物を作る人。

詳細仕様については、プロダクトオーナーと相談のうえで開発者側が作成することが多い。

---

## 道具

### ストーリー

開発により実現されるひとつのユーザー体験を表現したもの。

### タスク

ストーリーを分解して見積もり・実施可能な最小単位にしたもの。

### プロダクトバックログ

優先度順にストーリーおよびタスクをならべたリスト。

### スプリントバックログ

毎スプリントごとに作成される、スプリント期間内に実施するタスクのリスト。

### プランニングポーカー

タスクエスティメーション（後述）時に、開発者全員でタスクのコストを見積もるための仕組み。

---

## スクラムイベント

### スプリントプランニング

そのスプリントでやるタスクをプロダクトバックログ→スプリントバックログへ移動させる場。

### デイリースクラム

日々の進捗共有をおこない、ブロッキング要素などがあれば相談する場。

### バックログリファインメント

プロダクトバックログの優先度・タスク内容を見直す場。

### タスクエスティメーション

プロダクトバックログのうち、分解済みのタスクのコストを設定していく場。

### タスクブレイキング

プロダクトバックログのストーリーをタスクに分割する場。

### スプリントレトロスペクティブ

そのスプリントを通じての振り返り・改善点の洗い出しと次へのアクションを決める場。

# 気づきと感想

## 大変だなと感じたところ

### 開発者とスクラムマスターの兼任

優秀で熟練したスクラムマスターがひとりチームにいるだけで、圧倒的に安心感があります。「スクラムとはどういうものか？」という指針を与えてくれるのも大きいですが、それ以上に「開発以外のいろいろ」を意識の埒外に置くことができるので、本質的な開発タスクに集中しやすくなる効果が大きいです。

ただ、多くの組織は常にその体制を組めるともいかないのですよね。私の所属先でも、スクラムマスターと開発者を兼任体制へとチームが移行してしばらく経過しました。2スプリントに1回程度の頻度でスクラムマスター作業を担いましたが、やはりスクラムイベント関連の作業が開発の時間を多少圧迫する側面はあると思います。

また、本来的に言えば、スクラムマスターの責務はスクラムイベントのMCだけであるべきではなく、もっと改善系のタスクにしっかり時間を使えるべきなので、余裕のある組織には専任スクラムマスターがいるべきだなあ……というのは実感しました。複数スクラムチームがある場合などは、専任スクラムマスターというポストを開発組織の中に設置するのも、少し現実的になるのかなという印象です。

### タスクの作り方で全てが決まる

スクラムの前提として、タスクは「その内容を見るだけで誰でも取り組める」ような記述になっている必要があります。これには、「全員でエスティメーション（見積もり）をする以上は、誰にでもわかる形で記載されていないといけない」という側面と、タスクおよびサービス自体の属人化を防ぐ狙いがあります。

変化に強い組織を目指していくのであればとても大事なことではありますが、慣れないうちは「これでも詳細度足りないのか……」とか「ここまで書くなら実装しちゃったほうが早いんじゃね」みたいな安直な考えに向かってしまいがちです。ここをこらえて、しっかりとしたドキュメンテーションの文化を組織内で育てていかなければいけないと感じました。

また、ストーリー→タスクへと分割する粒度についても、極めて重要かつ難しいです。粗すぎればエスティメーションしようにも曖昧さが大きすぎてできない、という話になりますし、細かく分けすぎると1つのプルリクで5タスク分の内容です！みたいなことになりかねません。

ここは経験則で、もっとブレークダウンすべきタスク・逆にもっとまとめるべきタスクみたいなものが見えてくるようになるので、エスティメーションなどの際に粒度に違和感があったら口を突っ込むのも大事だなと思います。

---

## やってよかったと感じたところ

### 毎スプリント「小出しの達成感」を味わえる

単純な話ですが、ニンゲンは明確な締め切りがあるとお尻に火が付く生き物です。そして、締め切りは近ければ近いほど、またひとつひとつの作業単位は小さければ小さいほど、頑張りやすくて小出しの達成感を得られます。

タスクが速く片付けば、その分の時間を来スプリントからの仕様の作成や、より長大なリファクタリング構想に充当できたりもするので、早く終わらせようというインセンティブが働きやすいと思います。

逆に、タスクが終わり切っていない場合は（基本的にスプリントプランニングはPOと開発者の間で交わされる「確約」という性質を持つため）そこそこの心理的負荷を感じます。これについてはデイリーでの共有で状況を周りにしっかり伝える必要がありますが、いい意味での焦燥感だなという実感もあるので、スプリントを短く・タスクを小さくという基本的な発想自体は、とても良いものだと感じています。

### 仕様を記述する際に担当領域が異なるメンバーを巻き込みやすい

「次のエスティメーションに間に合わせるために、このストーリーを分解したいのですが、バックエンド周りでの不明点の調査とタスクのレビューお願いできますか？」みたいな感じで、いろいろと道具と理由が存在してくれるので、コミュニケーションが円滑になった気がします。

（現実的にはフロント→バックエンドという感じでお伺いを立てることが多く逆は割と少ないので、私が単にめっちゃ周りのバックエンド担当者にお世話になっているという話でもありますが…）

仕事を前に進めていくうえで、どれだけ関係者を巻き込めるか（自分だけではできない部分をどう埋めるか）は大事だと思っているので、道具立てとしてのスクラムは非常にありがたいと感じています。

### 大きなテーマでの開発を進められるようになった

タスクの優先度が明確にプロダクトバックログで測れるようになったことで、例えばリファクタや不具合修正がもっと大きなユーザー体験の実現を目指した開発タスクよりも上に来てる！みたいな状況にも気づくことができるようになりました。

また、タスクに分割していかなければ作業に着手できないという制約上、曖昧かつ巨大な問題に対しても、とにかく分解できる箇所から分解してはスプリントに入れる、という方針が実現できるので、「基本設計が網羅的に完了していないのでペンディングです…」みたいな状態がずっと続くということは避けやすくなったかと思います。

# 総括

スクラムってやってみないとわからないことがあまりにも多すぎるのですが、短絡的に始めると「形だけスクラム」になってしまいかねない、という怖さを持っている手法でもあります（特に、ウォーターフォールが板についた組織では）。だから、スタート初期には有資格あるいは経験者のスクラムマスターを引き連れてくるのが、成功のコツの一つではあると思います。

ただ、チーム自体がより「スクラム的」に改善を積み重ねていかないことには、すぐに陳腐化してしまうので、常に何らかの形で（ときには意図的に）変化しながら動いていくのが理想な気がします。


# 追記（2024/04/01）

このブログのホットリロード方法を、`next-remote-watch` から、自前の（といっても[Dan先生が使っているもの](https://github.com/gaearon/overreacted.io/pull/797)をほぼパクった）スクリプトでwebsocketを使ってやる方法に置き換えてます。

以下の記事はアーカイブとして残しますが、同様の方法を推奨するものではありません。

---

ローカルのmarkdownファイルをSSGする形でブログを書いていると、こんなことを思いました。「mdファイルを更新したら画面がリロードされてほしいな～」と。書くのが楽になることは、ブログを続ける秘訣かもですし。

調べてみたら、`next-remote-watch`というライブラリを使用することで簡単に実現できたのでご紹介します。

[hashicorp/next-remote-watch: Decorated local server for next.js that enables reloads from remote data changes](https://github.com/hashicorp/next-remote-watch)

今のところmarkdownファイルの変更検知以外の使い道を思いついていませんが、Next.jsがデフォルトでホットリロードしてくれるjs/ts/css等以外のファイルベースでホットリロードをしたいときには、役に立つかもしれません。

# 環境

```json
{
  "name": "tailwind-headlessui-next-blog",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "@headlessui/react": "^1.4.0",
    "axios": "^0.21.1",
    "dayjs": "^1.10.6",
    "markdown-yaml-metadata-parser": "^3.0.0",
    "next": "11.0.1",
    "react": "17.0.2",
    "react-dom": "17.0.2",
    "react-markdown": "^6.0.3",
    "react-syntax-highlighter": "^15.4.4",
    "remark-gfm": "^2.0.0"
  },
  "devDependencies": {
    "@types/react": "17.0.15",
    "@types/react-syntax-highlighter": "^13.5.2",
    "autoprefixer": "^10.3.1",
    "next-remote-watch": "^1.0.0",
    "postcss": "^8.3.6",
    "tailwindcss": "^2.2.7",
    "typescript": "4.3.5"
  }
}
```

# 導入

## パッケージインストール

```json
npm i -D next-remote-watch
```

## `next dev`コマンドを置き換える

```json
   "scripts": {
 -   "dev": "next dev",
 +   "dev": "next-remote-watch md"
```

`md`の部分は、検知の対象にしたいディレクトリ or ファイルを指定して下さい。
これで導入はあっさり完了。後はいつも通り`npm run dev`して記事を書きながらブラウザでプレビューしてけばよいです。

---

# 余談

## 内部的には`chokidar`を使ってるっぽい

`chokidar`は、ファイルの変更を監視するNode.jsライブラリです。

以下の箇所で、`chokidar`によるファイル監視と、イベント駆動でのホットリロードの発火がざっくりつかめる気がしますね。

[next-remote-watch/next-remote-watch at 6767289c23368ce5d604bd6c60aa0deb63588403 · hashicorp/next-remote-watch](https://github.com/hashicorp/next-remote-watch/blob/6767289c23368ce5d604bd6c60aa0deb63588403/bin/next-remote-watch#L44)

```ts
app.prepare().then(() => {
  // if directories are provided, watch them for changes and trigger reload
  if (program.args.length > 0) {
    chokidar
      .watch(program.args, { usePolling: Boolean(program.polling) })
      .on(
        program.event,
        async (filePathContext, eventContext = defaultWatchEvent) => {
          app.server.hotReloader.send('building')
          // 中略 by @asazutaiga
          app.server.hotReloader.send('reloadPage')
        }
      )
  }
  // 以下略 by @asazutaiga
```

この場合は、Next.jsのアプリケーション全体を再ビルドしているみたいですね。

## `zenn-editor`のプレビューって爆速だしなんか違うのかな？→websocketだった

`zenn-editor`のmd保存時のプレビュー反映がめっちゃ速くて心地よいと常々思っていましたが、`next-remote-watch`をポン載せしてアプリ全体を再ビルドしている場合と比較してみると一目瞭然でした。
どうやら、こちらも`chokidar`でファイル監視をしつつ、変更があった場合にはNext.jsの再ビルドを走らせるのではなく、`socket.io`を使ってwebsocket経由で変更反映しているようです。そりゃ速いわけだ！なっとく。

[zenn-editor/index.ts at 7711dac082923a409713d1f17514949f3f8bfa31 · zenn-dev/zenn-editor](https://github.com/zenn-dev/zenn-editor/blob/7711dac082923a409713d1f17514949f3f8bfa31/packages/zenn-cli/cli/preview/index.ts#L54)

```ts
  if (shouldWatch) {
    const watcher = chokidar.watch(`${process.cwd()}/{articles,books}/**/*`);
    const io = new Server(server);
    watcher.on('change', () => {
      io.emit('reload');
    });

    process.on('SIGINT', function () {
      // `Ctrl-C`の signalを奪って正常終了させる.
      io.close();
      watcher.close();
      process.exit();
    });
  }
  if (shouldOpen) open(previewUrl);
};
```

## ホットリロードってすごいよね

もはやWebフロントエンドの開発では当たり前になっているホットリロード。というか、HMRやらFast Refreshの登場でむしろ愚直すぎるような気もするホットリロード。

jQueryをCDNから読み込んでHTMLを直接操作していた右も左もわからないフロント迷子のころ（といっても1年半前くらい）は、「ホットリロードってスゲー！」という感動がありました。だって、エディタでファイルを保存した後に、わざわざブラウザの更新ボタン押さなくてよいんですよ？

私がホットリロードに最初に触れたのは、VSCodeの[Live Server](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer)という拡張機能です。素のHTML＋JSやjQueryで作られたLPをちょっと触るときとかに、あると便利です。

これに、同じ作者の[Live Sass Compiler](https://marketplace.visualstudio.com/items?itemName=ritwickdey.live-sass)を組み合わせてもいい感じに作業ができた思い出。

（……まあ、前職で最後にいたjQuery製Webアプリの現場は、認証の関係でAPIからデータを取ってくる手段がないのでローカルサーバでの作業ができず、いちいち開発用のサーバのディレクトリを作っては手動アップロードする必要があるとかいう激ヤバ環境だったんですが。）

# React開発環境におけるホットリロード（および類似機能）にかかわるリンク集

3連休だし、読もう。

## Hot Module Replacement (Webpack)

[Hot Module Replacement | webpack](https://webpack.js.org/concepts/hot-module-replacement/)

## React Refresh

ドキュメント見当たらず。Fast RefreshについてのDan先生のIssueコメントのリンクが[npmのreact-refreshのページ](https://www.npmjs.com/package/react-refresh)に貼られてた。

["How should we set up apps for HMR now that Fast Refresh replaces react-hot-loader? · Issue #16604 · facebook/react #issuecomment-528663101](https://github.com/facebook/react/issues/16604#issuecomment-528663101)


## Fast Refresh（Next.js）

[Basic Features: Fast Refresh | Next.js](https://nextjs.org/docs/basic-features/fast-refresh)







# `Ｔ`を指定しないと`any`になる`axios.get`

いつも通り`axios.get()`を書いているときにふと思いました。「型引数の`T`を必須にすれば、この`any`を消せるのでは？」と。

```tsx
const asyncFunction = async () => {
  const response = await axios.get('/path/to/endpoint')
  const data = response.data // any 😢
  const foo = data.foo // 型エラーにはならないけど、fooはundefinedかもしれない
  // ...
}
```

`Ｔ`を指定し忘れたのか、意図的に指定しなかったのかは分かりませんが、`data`が`any`になってしまいました。これを防ぐためには「`Ｔ`を指定し忘れたらエラーになるようにする」のが手っ取り早そうです。

## 型引数を必須にする方法（横道）

※ここではaxiosのことは一旦忘れてください。

「typescript require generic」でググったら、以下のStackOverflowを見つけました。

[javascript - TypeScript require generic parameter to be provided - Stack Overflow](https://stackoverflow.com/questions/51173191/typescript-require-generic-parameter-to-be-provided)

最も票を集めているのは以下の回答です。（執筆時点）

> There is no built-in support for this, we can however engineer a scenario where not passing in a type parameter will generate an error, using default generic type arguments and conditional types. Namely we will give U a default value of void. If the default value is the actual value of U, then we will type the parameter to the function as something that should not really be passed in so as to get an error:
>
> （拙訳）この問題に対する（TypeScriptの）組み込みのサポートはありません。しかし、型パラメータが渡されたなかった場合にエラーを生成するシナリオを、デフォルト型引数とconditional types（条件付き型付け）を使って作ることができます。（以下の例では）デフォルト値がUの実際の値である場合、関数のパラメータを、実際には渡すべきでないものとして型付けし、エラーになるようにします。

```tsx
async function get<U = void>(url: string & (U extends void ? "You must provide a type parameter" : string)): Promise<U> {
    return null as any;
}

get('/user-url'); // Error Argument of type '"/user-url"' is not assignable to parameter of type '"You must provide a type parameter"'.

class User {}
get<User>('/user-url');
```

日本語だと「型 '"/user-url"' の引数を型 '"You must provide a type parameter"' のパラメーターに割り当てることはできません。ts(2345)」みたいなエラーになりますね。

なるほど。泥臭さはあるけど、悪くないかも……って感じですね。

# `<T = unknown>`という小技

さすがに↑みたいなやり方を`axios.get()`に求めるのはなんか違う気がします。というかそもそもの話、「型引数を必須にする」という考え方よりは、「正しい型引数が指定されるようにする」という考え方をすべきなのでしょう。

axios.getはAPIレスポンスの型なので、ユーザがどんな形にでも型を定義できるはずですから、「正しい型引数」とはなんやねん？という感じですが。 `<T = unknown>`が落としどころなんじゃないかと思います。 

```tsx
const asyncFunction = async () => {
  const response = await axios.get('/path/to/endpoint')
  const data = response.data // unknown
  // const foo= data.foo // type error
  if (hasFoo(data)) { // 型検査が必須になる😄 
    const foo = data.foo
    // ...
  }
}
```

# Issueを立てたよ

※あとで書きますが、すでにクローズ済み。

axiosの気持ちを想像してみたのですが、「なぜ`<T = unknown>`にしないのか？」が分かりません。`unknown`型はプロパティアクセスをする前に型の検査が必要となるので、より型安全です。もし使われていない理由があるとしたら、`unknown`がTypeScript 3.0移行に導入されたものだから対応が漏れている（あるいはbreaking changesになるから入れられていない）くらいしかないかな、と予想しました。

疑念を持ちつつGitHubのissueを覗いてみたら、過去に同じことを考えている人がいたみたいです。ただし、残念ながらプロジェクトテンプレートに従っていないので、botによりcloseされていました。

[Use unknown type instead of any for Typescript definitions of response types #3313](https://github.com/axios/axios/issues/3313)

着眼点はいいのにこれはもったいないと思ったので、せこせこと文章とサンプルコードを用意し、issueを立てることにしました。

[Use unknown type instead of any for Typescript definitions of response types #3933](https://github.com/axios/axios/issues/3933)

これがどういった経過をたどるか分かりませんが、しばらく観察してみようと思います。
ここ何日か、日本のTwitterを中心に「[Project dead? #3930](https://github.com/axios/axios/issues/3930)」というissueが話題になったりもしているので、回答が来るかは分かりませんが。。。
botにcloseされたらそれはそれで残念ですが仕方ないな…って感じです。

（参考）

[TypeScript: Documentation - Generics - Generic Constraints](https://www.typescriptlang.org/docs/handbook/2/generics.html#generic-constraints)


## Issueについて追記①

ちゃんと調べたつもりだったんですが、out of dateになってるPRの中でちょうど「`unknown`がいいんじゃない？」っていうやりとりを見つけたので、Issueの方にも追記しておきました。

こちらはデフォルトの型引数を`never`にするという提案でしたが、当時はTypeScript 2系にaxiosが依存していたようで、`unknown`が使えなかったみたいです。

[Make the default type of response data never #3002](https://github.com/axios/axios/pull/3002)

これ見ると、`extends`じゃなくてデフォルト型引数でいいかもしれないですね…。=> 本文を修正しました。

## Issueについて追記②（このIssueはクローズしました。）

サンプルコードを少し修正しました。（型ガードが必要であることを明示）

それと、Carlos Chida([@carloschida](https://github.com/carloschida))氏が[Improved type-safety for AxiosRequestConfig](https://github.com/axios/axios/pull/2995)というPRを作ってくれているとコメントをもらったので、issueはとじました。`AxiosRequestConfig`で指定できるようにする、という後方互換性も考えられためっちゃスマートな回答。めっちゃ勉強になりました。



# ブログを作りました（N回目）

適当な技術を試したり、SSGするのにブログというコンテンツは無茶苦茶向いている気がします。
なので、何回もブログを作ってしまうのですよね。許してくれ。

## 使っている技術

Next.js + TypeScript構成はいつもの感じですが、tailwindcssを使ってます。

tailwindcssはgradientを簡単に作れるのも魅力の一つですが、今回はそもそもフラットなデザインにしたかったのでgradientは使っていません。残念。
ただ、やっぱりユーティリティの組み合わせでデザインデータにある程度近いものを作れるのは便利。
tailwind.config.jsをうまく使えば、それだけでtailwindを土台にデザインシステム的なものを作れるっぽいので、いいですよね。

コンテンツについては、CMSは使わず、リポジトリ内にそのままmdファイルを置いてビルド時にSSGしてます。
いろいろ構成考えましたが、結局これが一番シンプルでいいですね。

コードブロックのシンタックスハイライトはまだ入れてないので、そのうち入れます。

markdownのmetaの部分に、絵文字やタイトルや作成日を入れているのですが、これを変換するために[markdown-yaml-metadata-parser](https://github.com/ilterra/markdown-yaml-metadata-parser)というライブラリを使わせてもらってます。ミニマムな機能が提供されていてとてもいいのですが、型情報がないので、d.tsを自分で書きました。[このブログのリポジトリ](https://github.com/AsazuTaiga/tailwind-next-blog)の中に置いているので、どうせなら@typesとかにPR送ってみようかな……と思いつつ結構めんどくさそうなので二の足を踏んでます😢

（何か他に書くべきこと思い出したら追記します）

# 追記

シンタックスハイライトできるようにしました。
markdownのレンダリングは[react-markdwon](https://github.com/remarkjs/react-markdown)を使っていて、これに[react-syntax-highlighter](https://github.com/react-syntax-highlighter/react-syntax-highlighter)を組み合わせてます。

ほぼ公式で紹介されてるやり方そのままですが、力業感がありますね。

```tsx
// CodeBlock.tsx
import { PrismLight as SyntaxHighlighter } from 'react-syntax-highlighter'
import { vs, vscDarkPlus } from 'react-syntax-highlighter/dist/cjs/styles/prism'
import tsx from 'react-syntax-highlighter/dist/cjs/languages/prism/tsx'
import json from 'react-syntax-highlighter/dist/cjs/languages/prism/json'
import { useTheme } from '../hooks/useTheme'

type Props = {
  language?: string
  value: string
}

SyntaxHighlighter.registerLanguage('tsx', tsx)
SyntaxHighlighter.registerLanguage('json', json)

export const CodeBlock: React.VFC<Props> = ({ language, value }) => {
  const { theme } = useTheme()
  const style = theme === 'light' ? vs : vscDarkPlus
  return (
    <SyntaxHighlighter language={language} style={style}>
      {value}
    </SyntaxHighlighter>
  )
}

```

```tsx
// [slug].tsx
// いろいろ省略
// ...
    <Markdown
      components={{
        code({ inline, className, children }) {
          const match = /language-(\w+)/.exec(className || '')
          return !inline && match ? (
            <CodeBlock
              language={match[1]}
              value={children.toString().replace(/\n$/, '')}
            />
          ) : (
            <code className={className}>{children}</code>
          )
        },
      }}
    >
      {post.content}
    </Markdown>
// ...
```