Audio

89. 複数社のCTO経験から学ぶエンジニア組織マネジメント w/ BTO - fukabori.fm

Book

メンバーが勝手に動く最高のチームをつくる プレイングマネジャーの基本

![image](https://user-images.githubusercontent.com/5629074/216478543-953ecab4-a89c-4569-83eb-9b41bf18fdb7.png)

https://www.audible.co.jp/pd/B07WRVZQ8L

「ついていきたい」と思われるリーダーになる51の考え方

![image](https://user-images.githubusercontent.com/5629074/216337731-332a9f16-a539-454d-bd2b-2cdef057ec00.png)

https://www.amazon.co.jp/dp/477419039X


かんたん UML 入門 [改訂2版]

## ISO

- https://www.jqa.jp/service_list/management/management_system/
- https://ja.m.wikipedia.org/wiki/国際標準化機構

> ISOとは、スイスのジュネーブに本部を置く非政府機関 International Organization for Standardization（国際標準化機構）の略称です。ISOの主な活動は国際的に通用する規格を制定することであり、ISOが制定した規格をISO規格といいます。ISO規格は、国際的な取引をスムーズにするために、何らかの製品やサービスに関して「世界中で同じ品質、同じレベルのものを提供できるようにしましょう」という国際的な基準であり、制定や改訂は日本を含む世界165ヵ国（2014年現在）の参加国の投票によって決まります。身近な例として、非常口のマーク（ISO 7010）やカードのサイズ（ISO/IEC 7810）、ネジ（ISO 68）といったISO規格が挙げられます。これらは製品そのものを対象とする、「モノ規格」です。



Scrap

ISOとかJISとか

## できごと

### なにかを継続することができた

今年こそは何か継続したいと思って毎年意気込むものの、長くて1週間続けばよかったものが、今年まずは1ヶ月いろいろなものを続けることができた。なにか継続しようと思って1ヶ月の間続いたのは人生初じゃないかとおもう。[ジェームズ・クリアー式 複利で伸びる１つの習慣](https://www.audible.co.jp/pd/B087FDQBK4) を読んだのは習慣を身につけるテクニックを得るものとしてとてもよかった。ただ、一番良かったのは、まず「継続する自分」を継続してみようと思ったことかなと思う。

何かしら大きな目標を立てて、それを細分化していき小さな習慣として継続していきましょう、というのがよくある方法だと思う。それとは逆に目標や結果は考えすぎず、継続してみたいと思ったものをどんな形でもいいから継続する、と考えてみて功を奏した。「痩せたいから運動を継続しよう」ではなく、「運動することを継続する自分」を継続しようというイメージ。どこまで続くかはわからないが、とりあえず次は2月末を目標に続けていく。

### CSS が楽しくなってきた

Every Layout という本を読んですごく勉強になった。画面全体を Layout として捉えて分解して組み立てていく CSS のおもしろさを感じることができて、 CSS をもっと勉強したいと感じたし、Stack や Cluster はすでに今の現場に持ち込んで実装して伝授したりした。インクルーシブHTML や HTML解体新書といった本でアクセシビリティの片鱗に触れることができたし、フロントエンドエンジニアとして少しだけ成長を感じることができた。まだまだ先は長いが・・

### 家族全体で新型コロナに罹患した

とにかくめちゃめちゃキツかったし、なんなら今も全快していないのでめんどい。
https://kimromi.com/notes/74

Blog

2023年1月まとめ

![image](https://user-images.githubusercontent.com/5629074/216338157-8b7c3b7f-4519-448f-b933-b08462fb8cfb.png)

https://www.amazon.co.jp/dp/B0728K5JZV

WEBフロントエンドハイパフォーマンスチューニング

![image](https://user-images.githubusercontent.com/5629074/216337983-f19cb3e0-4554-440c-bde2-37ada61148f6.png)

https://www.amazon.co.jp/dp/B09LH1NKGV

問いかけの作法 チームの魅力と才能を引き出す技術

## まとめ

- 喉の痛みがなかなか収まらないのでのど飴は継続的に必要そう
- 頭痛は暫く続くが次第に収まった。ひどいときはバファリンをいただく
- キツいときは眠りもかなり浅かった。とにかく横になるのが一番
- 自分は鼻水と咳も出だした。薬も特に効かなかったので休もう
- 水分をいつもより多めに取るとよさげ
- しばらくは倦怠感が続きそうなので無理せず


新型コロナ罹患した

<img width="230" alt="image" src="https://user-images.githubusercontent.com/5629074/213902681-0d6bb5fa-af4b-41a4-a38e-4995fa58e791.png">

https://www.amazon.co.jp/dp/B00LIQMVLQ


センスは知識からはじまる

<img width="242" alt="image" src="https://user-images.githubusercontent.com/5629074/213723156-c8b8f1a1-3c4a-4714-8657-6a5931039566.png">

https://www.amazon.co.jp/dp/B08W51KLQJ


プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

<img width="239" alt="image" src="https://user-images.githubusercontent.com/5629074/212674812-c946cdcd-1732-4c23-ba0c-fbba752467e4.png">

https://www.audible.co.jp/pd/B08TM5G1PV
再生速度 1.6x


1440分の使い方 成功者たちの時間管理15の秘訣

Audible で[ジェームズ・クリアー式 複利で伸びる１つの習慣](https://www.audible.co.jp/pd/B087FDQBK4)を読んでいて、最後の方に自分の強みや向いているところで習慣を積み上げることによって長期的に大きな成果がつながる（かなり要約している）とあった。

自分はダーツが好きで、社会人になってから猛練習した。仕事が終わってから1人でネットカフェに行き、黙々と2〜3時間練習して帰るみたいなことを毎日ではないがおそらく2年くらいやっていた。ネットで見つけたダーツバーに1人で入り、そこにいた人たちと対戦して勝ったり負けたりを繰り返して仲良くなったりしながら、また勝つために黙々とネットカフェで練習していた。そのうちたまにカウントアップは1000点(まぁまぁすごい)を超えられるようになって、どんどん成長していった。最近はできていないけど。

ダーツはものすごくわかりやすい。点数を増やしていき最終的に点数が多い人が勝ち、または点数を減らしていき少ない回数で相手より先に0点にするかのゲームがほとんどである。そしてみんながそのルールの中で相手に勝つために練習をし試合をする。要するに目指すべきものがわかりやすい。もちろんゲームによって作戦はいろいろあるが、自分の思ったところにいかにミスなく投げることができるか、というところがすべてである。だからものすごい量の反復練習をして自分の思ったところに投げられる確率を上げていくことで、ゲームに勝てる確率を上げていく。プロレベルになると点数の増やし方減らし方や作戦による心理戦などで差が出る部分もあるが、基本的には自分との戦いになることが多い。

そして現在、Webエンジニアをしているがどうだろうか。誰かに勝つような勝負があるものではないし、点数が出るものでもない。営業職のようにアポイントメントや成約などの件数が明確に出るわけでもない（決してどちらが良い悪いという話ではない）。コードを多く書いた方が良いわけでもないし、早く書いたほうが良いわけでもない。

職能もたくさんある。バックエンド、フロントエンド、モバイル、SRE、QAなどなど...。その他マネジメントや組織をリードするような職種も加えるとPdM、PjM、EM、TL、VPoE、CTOなど...。関連する領域に関しても開発言語、設計手法、テスト手法、セキュリティ、開発プロセス、チーム、組織設計などなど...めちゃくちゃたくさんある。その中でどこを目指していくといいのだろう。何が自分に合っているのだろう。

前述したダーツの例でいくと、なにかわかりやすい指標に対して反復的に訓練して人よりわかりやすく秀でて勝負に勝つ場面があるということがもしかしたら向いているのかもしれない（わからないけど）。これをWebエンジニアに照らし合わせて考えたときに、同じようなことが達成できるような職種や領域がないかどうか考えてみるというのは手である。

以下は完全に仮定であるが、人事評価が数値の点数制になっていてかつオープンになっており、他人との成果やスキルの差が数字で明確に示されているほうがモチベーションが上がるのかもしれない。詳細なスキルマップが定義されていて、自分にできないことが他人はできるというのが明確に見える方が訓練が進むのかもしれない。また自分と同じように悩んでいる人のために、指標を明確にするためにどんなことができるかを考えて取り組んでみるのがいいのかもしれない。

Findy や LAPRAS のような転職サイトで、 GitHub のコードやブログのアウトプットなどを判定しスコアをつけるサービスがあり、一つの他人と比較できる点数付けのようなものであると思う。完全にはオープンではないので比較できるものではないが。ただ、外部に出ている情報だけですべてを測定できるかというと、マネジメントやチームリーディングのようなスキルはなかなか難しいのだろうなと思う（今後進んでいってほしい！）。

...などといいつつ、自分がどこを目指していくといいのだろうというのはまったくもって霧中なので泣きたい。ダーツ以外からも自分の性質や性格を理解しながら、どういった環境や働き方が自分に向いているのかはこれからも模索し続けていかねばと思う。

Webエンジニアってどこを目指したらいいか難しくないか、という話

毎日自動で日記issueを作成する

![image](https://user-images.githubusercontent.com/5629074/211688369-7f011cd8-eb22-4f21-bac7-2c4e7d06d894.png)

https://www.amazon.co.jp/dp/486246517X


Every Layout-モジュラーなレスポンシブデザインを実現するCSS設計論

SvelteKit で Svelte を理解しながら todo アプリをつくる

<img width="240" alt="image" src="https://user-images.githubusercontent.com/5629074/212676895-149e82be-ff20-417a-995d-e4a5ef99d41d.png">

https://www.audible.co.jp/pd/B087FDQBK4
再生速度 1.5x

初めて Audible で本を聴いてみる。

ジェームズ・クリアー式 複利で伸びる１つの習慣

https://anchor.fm/em-fm/episodes/Re18-e1sigrv

Re18. 開発者体験とフェイルファスト - EM.FM

PostCSS とは

Next.js v13 のリリースと一緒に og 作成できるライブラリが発表されているので試してみる

- https://nextjs.org/blog/next-13#og-image-generation
- https://vercel.com/docs/concepts/functions/edge-functions/og-image-generation

@vercel/og を試す

README を修正

https://github.com/kimromi/notes/issues/43

React / CSS Modules に触れてみる

https://github.com/css-modules/css-modules

> **modular** and **reusable** CSS!
> - No more conflicts.
> - Explicit dependencies.
> - No global scope.

実装は [css-loader](https://github.com/webpack-contrib/css-loader) でされている。

CSS Modules に触れてみる

## create 時に ESLint を含める

```console
npx create-next-app@latest . --eslint
```

TypeScript も含める

```console
npx create-next-app@latest . --typescript --eslint
```

create-next-app で Next.js を立ち上げて ESLint と Prettier で自動コードフォーマットする

- https://nextjs.org/docs/upgrading
- https://nextjs.org/blog/next-13

```console
npm i next@latest react@latest react-dom@latest eslint-config-next@latest
```

kimromi.com を Next.js v13 にアップデートする

<img width="246" alt="image" src="https://user-images.githubusercontent.com/5629074/195956488-5dcf2635-96e1-42ae-9e42-0733ee47bcb9.png">

https://www.amazon.co.jp/dp/4478490279/

考える技術・書く技術

個人のポートフォリオサイトを作りたいと思いたち、2022GW前から作り始めてとりあえず動くところまでできた（このサイト）。今までブログを Notion などに移転してきたが、ポートフォリオサイトの一部にさせることで育てていきたいというモチベーション。開発リポジトリは[こちら](https://github.com/kimromi/kimromi.com)。

ポートフォリオサイトを作った

もう2022年になってしまい遅ればせながら2021年をふりかえってみているけど、思い返してみるといろいろあった年だった。

2021年のふりかえりと2022年に向けて

![image](https://user-images.githubusercontent.com/5629074/190898877-2b420920-9f68-41e3-8d9b-986029978d35.png)

別のチームでドラッカー風エクササイズをしていたので、今のチームでお試しでやってみた。

結構長く一緒に開発しているチームメンバーなので、あまり効果はないのかなと思いつつ、やってみると意外に新たな発見があったり、実はメンバー間で期待したりされていることがズレてたりして、とても良かった。

- 自分の得意なこと
- 仕事をする上で大事にしていること
- 自分が大事にしている価値
- 周りから期待されてると思っていること

を15分くらいで各自書いてもらって、1人ずつ発表してもらい、そのあと他のメンバーから意外だったことや期待してることについてフィードバックする、という流れで進めた。

今日はたまたまオフィス出社日でみんな顔を合わせながらやったけど、今後リモートでやる機会もふえるかなと思いツールとしてはmiroをつかった。miro便利。

自分の考えを話したり周りからどう期待されているのかを改めて会話すると照れるけど、それも良いスパイスになっていい感じの空気感になっていたと思う。

なかなか好評だったので、半年ごととかメンバーが変わったタイミングでやれるといいね、という話をしていた。

ドラッカー風エクササイズをした

今日、とあることがあり自分が防衛的になってしまい、何も喋れなくなったのを感じたので反省。この現象に時々なるのだけどどういうときに起こるかというと、今進んでいることに関して「これが正しい」とガッと指摘されたり、自分がそう感じたときによくなる。

なぜ防衛的になるのかを考えてみると、

- 自分や誰かががそれまでに考えてきた背景や状況をないがしろにされる悲しみ
- 正しい方法にたどり着けなかった自分の不甲斐なさ
- 今やっていることは正しくないかもしれないという疑問に対してえぐられる感じ

結果がすべて、かもしれないけど、そこにたどり着くまでにはいろんな人の考えや行動や感情が詰まっていて、そこからはじき出された1つのプロセスなだけなのでは？と思っちゃう。

「正しい」ってなんだと考えたとき、自分は答えがない。自分の言動の中に「正しい」と思っているものは1つもなくて(本当はあるだろうけど)、今までの自分の経験からはじき出されたただの1つの考えとしか思っていない。自分の中の「正しい」は誰かの「正しくない」かもしれない。どの言動に対してもこれは正しくないかもしれない、ただトライしてみることで何かが得られあのときはこんな失敗をしたな、もっとこうすればよかったな、という記憶が糧になって次の行動をつくる、みたいな感じ。

ただ、上記のような考えも自分の1つの「正しさ」であって、他の人はそうでないかもしれない。だから防衛的な反応をしてしまったときに自分の中の「正しさ」を守ろうとしているのだな、と逆に悲しくなる。

まだまだ圧倒的に鍛錬が足りないし、これを解消するには少しでも手を動かしたり考えたりして、より「正しい」道に進める確率を上げるしかない。

ただそこが大変なのよねー。がんばろー。
(この文章は決して誰かを咎めるものではなくて、反省のために書き記しています。)

「正しさ」に対して過剰に反応してしまう

どんなにポジティブな人（に見える人）にもネガティブな部分は当然あって、ポジティブに見える人はネガティブな部分を人に見せていないからポジティブに見えるだけであって、ネガティブを隠す技術を持っているのではないかと考えるようになった。最近は僕もチームをまとめる立場が多くなってきて率いる立場として、この発言は士気を下げそうだ、のような発言前にストップすることが多くなってきた。

以前は言いたいことが言えない・・とか思っていたところもあるけど、最近はそういうのもなくなってきて、人にすべてを見せる必要ないし共感を求めることも減ってきた。

「リーダーは弱い部分も見せるべきだ」みたいなのもよくみるけど、思ってることを言って弱音を吐くということではなくて、わからない部分や不安に思っている部分はきちんと伝えて誰にでも教えを乞うみたいな姿勢が大事なんだと思う。

なにかのYouTubeでみた覚えがあるのだけど、感情が言葉をつくる、は当然なんだけど、逆に、発した言葉が感情に作用するみたいことを言っていて、たしかにあるなと思った。キツイときにあえてハチャメチャなことを言ってみるとそれがなんか余裕につながってくるとか、なにか発言したときに「言うべきじゃなかったな〜」とか「言い過ぎたかな〜」とか考えすぎてしまって自分が一番ダメージを受けているとか。よくあるので、この発言によって自分の感情がどうなるのかを考えてから発言するようにするのもいいなと思った。

最近は特にテキストでのコミュニケーションが増えてきて、文字面で判断しないといけない場面が増えているので、語尾に絵文字や「！」や「〜」をつけたり、「？？」を2つつけてみたりすることで少しでも強い口調にならないようにしてる。ただ本当に余裕がなくなってきたときはこれもできなくなるので、そうなったときはよっぽどなんだなと自分でも気づくようになった。

あと今の会社はtimes(分報？)チャンネルの文化があるけど、そこに特定の誰かや何かを卑下するようなことを書いたり、会社の不満を書いたりはしないようにしてる。会社だって動かしているのは人間だし、それがいつか回り回って伝わったときにそれは単なる悪口だし、人にも自分にもいい影響は一切ないのでやらないようにしている。

あとは逆に自分をポジティブ側に無理して振りすぎないというのもある。何か盛り上げるために無理にテンションを上げすぎないようにするというか。もともとテンション高くないほうなので上げすぎると逆にその後の跳ね返りがすごくてどっと疲れがくるので、あんまり無理しすぎずできるだけ普段の感じでやれるようにする（なりたい）。

まぁそんなことを言っておきながら、ネガティブ発言してしまうことは当然あるし、言ってしまったらそれを取り戻すために何か違う行動に出たりもすることもあるので、それはそれでいいかなとも自分を責めすぎないようにしよう〜。

ネガティブを人に見せない技術(がほしい)

ここ2年くらいはミニマルに生活しようと思って家のものをどんどん捨てたり、洋服もできるだけ少なくして制服化していたけど、デジタルなものに関してはできていないなと思い立ったのがきっかけ。

技術的なtipsはQiita/zenn.dev、ちょっと長文ははてなブログ、日記的なものはnoteみたいな感じにしようかなと思っていたけど、あれこれ管理するとその分脳内コストも掛かるので1つにまとめるためにブログを立ち上げ移行した。あとは各サービスにいいね機能などもあるからいいねが欲しくなってしまうし、あまり気にせずいろいろ書きたいというのもあった。

SNSやツールなどのアカウントも残っていたものもあまり使っておらずなくても困らないだろうというものはできる限りアカウント削除した。

- Facebook
- Instagram
- Tumblr
- Foursquare
- Qiita
- Zenn.dev
- note
- Notion
- Pocket
- Todoist
- Trello
- 転職系のサービス

Twitterは連絡をとったりすることがあるので残している。メモはGoogle Keepに雑多に残すで全然大丈夫そう。

デジタルミニマライズ

```ts
const { pathsToModuleNameMapper } = require('ts-jest/utils');
const { compilerOptions } = require('./tsconfig.json');

module.exports = {
  moduleNameMapper: pathsToModuleNameMapper(
    compilerOptions.paths,
    { prefix: '<rootDir>/' }
  )
}
```

tsconfig.jsonのcompilerOptionsにpaths設定をしているので、pathsToModuleNameMapperを使ってみたいな感じで書いていた。

svgファイルをimportするコードがあったので https://jestjs.io/ja/docs/webpack を参考にfileMockさせようと思いこんな感じで書いた。

```ts
const { pathsToModuleNameMapper } = require('ts-jest/utils');
const { compilerOptions } = require('./tsconfig.json');

module.exports = {
  moduleNameMapper: pathsToModuleNameMapper(
    {
      "\\\\.(jpg|jpeg|png|gif|svg)$": ["./src/tests/mocks/fileMock.js"],
      ...compilerOptions.paths,
    },
    { prefix: '<rootDir>/' }
  )
}
module.exports = 'test-file-stub';
```

するといっこうにfileMockが効かない。。。2時間くらい格闘したけど、結論pathsToModuleNameMapperの中にいれていたのが間違いで、外に設定すれば動いた。

```ts
const { pathsToModuleNameMapper } = require('ts-jest/utils');
const { compilerOptions } = require('./tsconfig.json');

module.exports = {
  moduleNameMapper: {
    "\\\\.(jpg|jpeg|png|gif|svg)$": ["<rootDir>/src/tests/mocks/fileMock.js"],
    ...pathsToModuleNameMapper(compilerOptions.paths, { prefix: '<rootDir>/' }),
  },
}
```

[pathsToModuleNameMapperのソースコード](https://github.com/kulshekhar/ts-jest/blob/f1f3945b483fb9e01821909b227168ab26394b5f/src/config/paths-to-module-name-mapper.ts#L17)を見てみるといろんなエスケープ処理が入っていて、tsconfig.jsonのcompilerOptions.paths用に作られていた。（そりゃそうだ）

pathsToModuleNameMapperにいれると↓みたいになっててそりゃ一致しないよねってことでした。

```json
{
  '^\\\\\\\\\\\\.\\\$jpg\\\\|jpeg\\\\|png\\\\|gif\\\\|svg\\\$\\\\$$': '<rootDir>/./src/tests/mocks/fileMock.js',
}
```

JestのmoduleNameMapperで画像のfile mockができなくてハマった

最近、承認欲求の向こう側にいけないかどうかをちょっと考え中。

かつてはmixi、それからFacebook、Twitter、InstagramとかたくさんのSNSが出てきてなまじっか簡単にいいねしたりされたりができるようになったもんだから、欲する者としてはいいねしてほしくなっちゃう。

ブログ書くのにも技術系のことはこっちのブログに書いたほうがいいとか、何時に投稿したほうがいいとか、どういう形式に書いたほうが読まれるかとか、もうそういうのもありふれて普通になってて差別化できない。

なんかそういうものを考えずにどんどんなんか好きなように発信して、誰も読まなくても自分の糧になればいいと思っている一方で、ただそれなら自分のメモに書けばいいよねという話で、完全に矛盾してしまっている。まぁ、うん、何かしら誰かが読んだら嬉しいくらいの気持ちがちょうどいいのかも。

まずアウトプットでもなんでも、何のためにするのか考えるときに、承認欲求が満たされる以外のなにかで言語化できるとよさそうというメモでした。おわり。

承認欲求の向こう側

特に出典とかはありませんが僕の経験から大事にしていることなどを書きました。社内向けのドキュメントに書いていましたが、外にも出せるかなと思い少しだけ修正しつつ記事にしました。

## 全体像をきちんと理解する

- 全体像を理解するとはプロジェクトの5W1Hを理解するということ
    - Why: なぜそれが必要なのか、誰が喜ぶのか
    - What: 何をつくるのか、何が必要なのか
    - When: いつまでにつくりたいのか
    - Who: 誰が関わり、誰がつくるのか
    - Where: どこにつくるのか、どこでつくるのか
    - How: どういう方法でつくるのか
- 全体像を把握しないと詳細に落とし込むことができない
    - 理解してない状態で詳細に落とし込むと認識違いの手戻りや仕様変更の確率があがる
    - 疑問点は知ってる人に聞きまくって理解する
- 把握した上でだいたいのスケジュール感でどこまでのものが提供できるのか想像する

## なぜ自分がこのプロジェクトに参加しているのかを考える

- どういう役割を求められているのか
- 自分の何がプロジェクトに活かせるのか
- 自分がこのプロジェクトを完了させたときに何が得られているのか
- 何をモチベーションにしていくか
- 「自分のやりたいこと」と「リリースまでのスケジュール」の交わる点がプロジェクトのゴール
    - 「自分のやりたいこと」だけやってもスケジュールが伸びるだけ
    - 「リリースまでのスケジュール」だけを優先してもモチベーションが上がらない
    - ちょうどいい感じのポイントを探す

## 管理する = 偉いではない

- プロジェクト管理することは偉いことではない
    - 単純にそういう立場であるだけ
    - 求められているものがプロジェクトを管理することであるだけ
- 人を管理するではない、タスクを管理する
- 上からの操り人形みたいなイメージではなくむしろ下から押し上げていくイメージ

## 不確実性コーンを意識する

[こういうやつ](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F35671%2F10a77273-247d-f12b-8d09-076ec87a5064.png?ixlib=rb-1.2.2&auto=format&gif-q=60&q=75&s=b560b10ec973971327053318b233c10c)

- どんなに仕様を理解して全体を把握していても考慮漏れや仕様変更が必ずどこかである
    - 今まで完璧にタスク分解できて考慮漏れがなかったことは一度もない
- 人間はリリースが先であるほど余裕をカマすのでスケジュールが巻くことはまずない
    - 不確実性コーンで言えば下半分はほぼない
- もし余裕があれば（だいたいないけど）
    - テストの拡充や自動化で品質を上げる
    - リファクタリングなどで技術的負債を少なくする

## 定期的にスケジュールを見直す

- スケジュールは基本遅れるものとして考える
    - スケジュールをわざと遅らせてやろうと思っている人間はいない
    - 遅れることは仕方がないのでそこから未来のことを考える
- 遅れが発生した時に都度スケジュールを見直す
- 「スケジュールを見直す」とは
    - プロジェクトの開始から見て見積り精度がどうだったかを見直す
    - タスクの漏れがないかどうか見直す
    - タスクの優先度を見直す
    - メンバーのアサインを見直す
    - スケジュールを引き直す
- 見直しをしないといつまでも不確実性が小さくならない
- 見直したスケジュールは共有する

## ツールはなんでもいい

- 定期的に見直すことさえすれば正直なんでもいい
- ツールにこだわりすぎるとツール自体に時間をかけてしまったり逆に制限がかかったりする
- 要は第三者に遅れているのか、順調なのか、間に合うのかが説明できればいい
- あとは自分が見直しやすい感じで

## 決して無理をしない

- 今いるメンバーで可能な範囲でつくる、スケジューリングする
    - リリースまでに間に合うか
    - レビューが可能か
    - リリース後のメンテナンスが可能か
- 背伸びしすぎない
- 「今流行りらいしこれ使おうぜ」
    - 誰もメンテナンスできなくて最悪みたいなことが起こる
    - 今いるメンバーがちょっと学びがあるくらいがちょうどいい
- 人間がこなせるタスク量は限界がある
    - 無理をすると絶対にどこかがほころぶ
    - 身体的、精神的な疲労は慢性的に蓄積する

## 情熱みたいなものも時には必要

- 人間は感情で動く生き物
- 情熱や熱意は人に影響を与える
- 「あなたがそう言うなら」といかに人に思ってもらえるか
- スキルも大事だけど最終的には人間性がものをいう

プロジェクトを管理するときに大事にしていること

だいたい月に1回ほど福岡拠点のエンジニアが集まってtech talkというイベントをしていて、今回エンジニアのアウトプットというテーマで発表した。

前職はアウトプットすることが企業理念の1つとして入っている会社だった。社員みんなアウトプットを意識している中で私も働き、アウトプットすることで成長してきた部分もあると感じているので、今一度アウトプットの良さについて自分なりに噛み砕いて資料にしてみた。

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/dd507474f1ae429587eb16b5887e51bb" title="エンジニアにとってのアウトプットとはなにか考えた / what-is-output" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="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: 560px; height: 314px;" data-ratio="1.78343949044586"></iframe>


[https://speakerdeck.com/kimromi/what-is-output](https://speakerdeck.com/kimromi/what-is-output)


今のところアウトプットは自己成長を目的にするというのが根底にある思っている。自己成長の効率をより高める手段として、他人に見えやすいようにアウトプットすることでフィードバックをもらったり評価を受けたりすることが良いのではないかという話。

周りの同僚の反応はなかなかよかったが、自分としてはもう少しデザインをよくしたかった。個人的に、エンジニア向けの登壇資料だから字ばかりでも伝われば大丈夫みたいなのは今後はあまりやらないようにしようとしていて、何か発表するならできるだけデザインもこだわって資料を見ただけで伝わるように作っていこうと思っている。デザイナーさんにデザインを教えてもらうぞー。

エンジニアのアウトプットについて社内勉強会で発表した

Reactのスタイル管理、どうしていますか。

いろいろな方法があると思いますが、大規模なReactでのフロントエンド開発においてCSSをどう管理するかとても悩みました。私の所属しているチームでは、styled-componentsのThemeProviderを使ってスタイルを管理することにしましたので紹介します。

## コード例

例えば簡単なButtonコンポーネントを実装し、propsで背景色を変えたい場面があったとします。

```tsx
import React from "react";
import styled from "styled-components";

const StyledButton = styled.button`
  background-color: ${props => (props.color === "primary" ? "blue" : "gray")};
`;

export default *function* Button({ color, children }) {
  // わかりやすいようにpropsを分けて渡しています
  return <StyledButton color={color}>{children}</StyledButton>;
}
```

この実装だとcolor propsの種類が増えたときに分岐の実装が増えていくため、objectに設定を切り出して書いたりします。

```tsx
const backgroundColor = {
  default: "gray",
  primary: "blue",
  warning: "orange"
}

const StyledButton = styled.button`
  background-color: ${props => backgroundColor[props.color]};
`;
```

上の実装でだいぶ変更には強くなります。ただ、もしcolorのprimaryやwarning設定をある一部分だけ違う色に変えたいという場面があったとします。Buttonコンポーネント内で色を固定してしまっているため、propsを追加するか、styled-componentsのcss propsを渡すか、もう一つButtonをラップしたコンポーネントを作るなどの方法を取らねばなりません。

そういった場合にThemeProviderを使って実装すると便利なことがあります。

```tsx
import React from "react";
import { ThemeProvider } from "styled-components";
import Button from "./Button";

const theme = {
  button: {
    backgroundColor: {
      default: "gray",
      primary: "blue",
      warning: "orange"
    }
  }
};

export default *function* ButtonGroup() {
  return (
    <ThemeProvider theme={theme}>
      <Button color="default">Default</Button>
      <Button color="primary">Primary</Button>
      <Button color="warning">Warning</Button>
    </ThemeProvider>
  );
}
import React from "react";
import styled from "styled-components";

// ThemeProvider内のコンポーネントはpropsにthemeがセットされている
const StyledButton = styled.button`
  background-color: ${props => props.theme.button.backgroundColor[props.color]};
`;

export default *function* Button(props) {
  return <StyledButton {...props} />;
}
```

Buttonコンポーネントを使う側(ButtonGroup.js)でThemeProviderを使い theme propsで色を設定しているobjectを渡します。ThemeProviderで囲まれた全コンポーネントには theme というpropsが自動で追加されており、 props.theme にはThemeProviderで渡したobjectが入っています。

これでコンポーネントを利用する側からスタイルをカスタムしやすくなりました。同時にButtonコンポーネントではCSSとしてThemeProviderからの値をセットするだけで、背景色自体の管理はしなくなっています。

以下のようにobjectを書き換えれば、一部分だけ設定を変更することができます。

```tsx
import React from "react";
import { ThemeProvider } from "styled-components";
import deepmerge from "deepmerge"
import Button from "./Button";

const defaultTheme = {
  button: {
    backgroundColor: {
      default: "gray",
      primary: "blue",
      warning: "orange"
    }
  }
};
const customTheme = deepmerge(defaultTheme, {
  button: {
    color: {
      primary: "green",
      warning: "red"
    }
  }
});

export default *function* ButtonGroup() {
  return (
    <ThemeProvider theme={defaultTheme}>
      <div>
        <Button color="default">Default</Button>
        <Button color="primary">Primary</Button>
        <Button color="warning">Warning</Button>
      </div>
      <div>
        <ThemeProvider theme={customTheme}>
          <Button color="default">Default</Button>
          <Button color="primary">Primary</Button>
          <Button color="warning">Warning</Button>
        </ThemeProvider>
      </div>
    </ThemeProvider>
  );
}
```

ThemeProvider自体はReactのContextの仕組みを使っているので、一番近いところで渡されているThemeProviderの値がセットされるようになっています。カスタムしたい場合は、デフォルトのテーマ設定objectからマージして書き換えたい部分のみ上書きするようにします。

これでcustomThemeを渡した方のみカスタムした背景色が当たるようになりました。

試してみたソースコードはこちらに置いています。 https://codesandbox.io/embed/strange-http-1uhlf?fontsize=14&hidenavigation=1&module=%2Fsrc%2FApp.js&theme=dark

## ThemeProviderを利用するメリット

### コンポーネントとスタイル管理を切り離して管理できる

上記の例ではButtonコンポーネント内で背景色のスタイル管理をしなくなりました。つまりスタイル変更のためだけにButtonコンポーネントを修正する必要がなくなるということです。背景色だけでなくサイズやテキストの色などもThemeProviderで管理するようにすることですべてコンポーネントを利用する側でスタイル管理ができるようになります。

ただStorybookでコンポーネントカタログを作るときなど、ThemeProviderを利用せずコンポーネントのみで表示させたい場合、 props.theme がセットされないためundefinedになりJavaScriptエラーが発生してしまいます。その場合[ReactのdefaultProps](https://ja.reactjs.org/docs/react-component.html#defaultprops)を利用するとよいと思います。

```tsx
import React from "react";
import styled from "styled-components";
import { defaultTheme } from "./defaultTheme"

const StyledButton = styled.button`
  background-color: ${props => props.theme.button.backgroundColor[props.color]};
`;
StyledButton.defaultProps = {theme: defaultTheme}

export default *function* Button({ color, children }) {
  return <StyledButton color={color}>{children}</StyledButton>;
}
```

これでThemeProviderを利用しない場合でもdefaultPropsによりデフォルトのテーマ設定で props.theme が渡された状態になります。

### CSSの詳細度の戦いになりにくい

コンポーネント内でCSSを設定していた場合、そのCSSを上書きするためには利用するコンポーネント側でCSSの詳細度を考えながら書かなければなりません。ときには !important を使わないといけない悲しい場面もあるかもしれません。

ThemeProviderを利用した場合、セットするthemeはJSのobjectなのでobject自体を上書きして渡してしまえば詳細度の戦いになりません。styled-componentsの仕様として、CSSの値にundefinedを渡せばプロパティ自体出力されなくなるので、無駄なCSSが出力されないというメリットもあります。

### TypeScriptでも書ける

https://github.com/styled-components/styled-components/issues/1589#issuecomment-456641381 を参考にtheme props型をつけることができます。@types/styled-components の実装でDefaultThemeのinterfaceを拡張するとthemeに型をつけることができるようになっています。テーマ管理しているobjectのtypeofをとり以下のようにDefaultTheme interfaceに適用します。

```tsx
import { defaultTheme } from "path/to/defaultTheme";

type ITheme = typeof defaultTheme;

declare module "styled-components" {
  interface DefaultTheme extends ITheme {}
}
```

少しロジックが入ったりする場合は、styled-componentsのテンプレート文字列全体を関数にして最後にcssを使って文字列を返すような実装もできます。

```tsx
import React from "react";
import styled, { css } from "styled-components";
import { defaultTheme } from "./defaultTheme"

type Props = {
  color?: "default" | "primary" | "warning";
  disabled?: *boolean*;
  children: React.ReactNode;
}

const StyledButton = styled.button<Props>`
  ${({theme, color, disabled}) => {
    let backgroundColor = disabled ? "darkgray" : theme.button.backgroundColor[color];
    return css`
      background-color: ${backgroundColor};
    `
  }}
`;
StyledButton.defaultProps = {theme: defaultTheme}

export default *function* Button(props: Props): React.ReactElement {
  return <StyledButton{...props} >;
}
```

## 最後に

デフォルトのテーマ設定objectを別のobjectに切り替えるだけで、ユーザーごとのテーマ切り替えやダークテーマの対応がしやすかったりするメリットもあると思います。

直感的なCSSファイルでの実装ではないため、デザイナーがコードまで修正しているチームの場合修正しにくいデメリットはあると思いますが、エンジニアが管理しているチームでは管理しやすくなると思いますのでぜひ試してみてください。

## 参照リンク

[公式のドキュメント](https://styled-components.com/docs/advanced#theming)
[theme propsに型をつけるには](https://github.com/styled-components/styled-components/issues/1589)

styled-componentsのThemeProviderをつかってReactのスタイルを管理する

最近Reactコンポーネントを実装、修正する機会が多い。コードレビューのときにコード的には大丈夫そうだけど見た目がどんな動きをするか気になるときがあり、レビュー時にStorybookを確認したい場面が増えた。

branchをcheckoutすれば手元で見れるが、自分も修正途中のときに面倒くさい。

https://circleci.com/docs/2.0/artifacts/ 現在利用しているCircleCIにはartifactsという成果物を一定期間永続化できる機能がある。

解決方法として、StorybookをビルドしたHTMLファイルをartifactsに置き、index.htmlまでのURLをプルリクエストにコメントするという方法をとった。

ほぼこちらを参考に実装。https://qiita.com/resessh/items/38ef6492d0cf21facec8

手順としては以下。

- 環境変数からPull Request番号を取得
- GitHubのAPIからPull Requestのターゲット(マージ先)ブランチを取得
- ターゲットブランチとのgit diffにコンポーネントの修正があるか判断
- 修正があればStorybookをビルドする
- GitHub APIを叩いてStorybookまでのURLをPull Requestにコメント

上記のリンクではPull RequestへのコメントはJavaScriptで行っているが、全部shell scriptで書いた。

```yaml
#!/bin/sh
set -eu

PULL_REQUEST_ID=$(echo ${CIRCLE_PULL_REQUEST} | awk -F'/' '{print $NF}')if [ -z "${PULL_REQUEST_ID}" ]; then
  echo "Skip building storybook."
  exit 0
fi

# Get pull request target branch
TARGET_BRANCH=$(curl -H "Authorization: Bearer ${GITHUB_TOKEN}" "<https://api.github.com/repos/${CIRCLE_PROJECT_USERNAME}/${CIRCLE_PROJECT_REPONAME}/pulls/${PULL_REQUEST_ID}>" | jq '.base.ref' | tr -d '"')# Check fixed components in git diff
git fetch origin ${TARGET_BRANCH}
COMPONENT_FIXED=0
git diff origin/${TARGET_BRANCH}...HEAD --name-only | grep 'client/components/' || COMPONENT_FIXED=$?

if [ "${COMPONENT_FIXED}" != "0" ]; then
  echo "Skip building storybook because components not fixed."
  exit 0
fi

# build Storybook
$(npm bin)/build-storybook -c client/.storybook -o public/storybook --quiet

# add comment to pull request
COMMENT=":link: [Storybook](<https://$>{CIRCLE_BUILD_NUM}-${REPO_NUMBER}-gh.circle-artifacts.com/0/storybook/index.html)";
curl -X POST \\
  -H "Content-type: application/json" -H "Accept: application/json" \\
  -H "Authorization: Bearer ${GITHUB_TOKEN}" \\
  -d "{ \\"body\\": \\"${COMMENT}\\" }" \\
  "<https://api.github.com/repos/${CIRCLE_PROJECT_USERNAME}/${CIRCLE_PROJECT_REPONAME}/issues/${PULL_REQUEST_ID}/comments>"
version: 2.0
jobs:
  build_storybook:
    docker:
      - image: circleci/node:10.13.0-browsers
    resource_class: small
    steps:
      - checkout
      - run:
          name: Build Storybook
          command: |
            npm install
            client/bin/build_storybook.sh
          environment:
            REPO_NUMBER: [CircleCI repository number]
      - store_artifacts:
          path: public/storybook
          destination: storybook
workflows:
  version: 2
  build:
    jobs:
      - build_storybook
```

ちなみにGitHub Actionsはartifactsはあるもののzipでのダウンロードにしか対応していないので今のところ実現できない。今後に期待。https://github.com/actions/upload-artifact/issues/3

StorybookをCIでビルドしてPull Requestにコメントさせたらレビュー効率がアップする

こちらは[Money Forward Advent Calendar 2019](https://adventar.org/calendars/4136)の13日目の記事です。[マネーフォワード クラウド経費](https://biz.moneyforward.com/expense)というBtoB向けサービスのフロントエンドエンジニアとして2019年9月に入社し3ヶ月が立ちました。開発はすべて福岡支社で行われており、私も福岡で働いています。試用期間を終えちょうどアドベントカレンダーの時期であったので3ヶ月で取り組んだことと所感を残しておこうと思います。

まずは取り組んだことについてまとめていきます。

## フロントエンド開発環境の改善

### 👉 既存の問題発見と解決策・ロードマップの共有

まずは既存のフロントエンドにおける開発の問題点についてヒアリングし、解決する方法を考えチームに共有しました。

現在のフロントエンド開発における問題点として大きく2つありました。

- Ruby on Rails(以下Rails)アプリ内のJavaScript(CoffeeScript)が複雑でメンテナンスしにくい
- フロントエンドのソースコードをRailsから切り離してReact.jsにしていこうとしていたが担当者が退職し進まなくなった

これらの問題の解決のため、まずは開発基盤の整備によるメンテナンスしやすさの向上を進めていくことにしました。フロントエンド改善における意義と、全体として何をいつまでに取り組んでいくかのロードマップやをドキュメントに残しておくことで「なぜ改善が必要なのか」に迷ったときに立ち戻れるようにしています。

今時点の最終ゴールとしてはRailsはWebAPIのみ、フロントエンドはSPAとして独立したものにすることを目標に進めていますが、既存機能もたくさんあるのでとても長いプロジェクトになると思います。

また、前述の通りReact.jsでの開発が一部導入されていたため、より開発が進めやすくするためにコンポーネントの粒度やディレクトリ構成などのルールを考え、共有し議論しながらまとめていきました。

当然進めていくなかで思った通りに進まないところもあるので、臨機応変に対応しつつチームに共有し合意を得ながら進めています。

### 👉 開発基盤の整備

#### ・ディレクトリ構成の変更

SPAではなくRailsのView上で部分的にReact.jsのコンポーネントを利用していますが、一部汎用的なコンポーネントはあるものの、画面ごとに独自に作られたコンポーネントが多くメンテナンスしづらい状態でした。できるだけ汎用的にコンポーネントを実装しやすいようにRailsのそれに近かったディレクトリ構成をフレームワークに近い形に変更しました。現在のディレクトリ構成は以下です。

```
client/
 ├─ .storybook/ ... Storybookの設定ファイル
 ├─ assets/ ... 画像などの静的ファイル
 ├─ components/ ... React.jsのコンポーネントを置く
 ├─ consts/ ... 各種定数をまとめる
 ├─ docs/ ... 各種ドキュメントをまとめる
 ├─ lib/ ... 共通処理などを実装する
 ├─ locales/ ... I18n用の設定ファイル
 ├─ pages/ ... pageコンポーネント(Atomic Designのpagesレベル)
 ├─ stores/ ... Reduxのソースコード
 ├─ tests/ ... テストコード
 └─ types/ ... 型定義ファイルを置く
```

components/以下はAtomic Designの考えにもとづいて整理し抽象化することでより汎用的に使えることを目指しています。Atomic Designを採用したのはチームに経験者がいたというのと、これからチームで開発する際に意思を統一しやすい概念であるというところから採用しています。

#### ・react_on_railsの導入

しばらくはRailsのView上でのコンポーネント利用になるため、できるだけRailsからReactコンポーネントを使いやすくするためのライブラリとしてreact_on_railsというgemを導入しました。react-railsというライブラリもあったのですが、Webpackerを利用する前提のものだったので見送りました（Webpackerはもともと使われていませんでした）。

簡単な使用方法としてはReactコンポーネントが実装されているビルド後のJavaScriptを読み込んだ状態で、Railsのview(controllerも可)内でreact_componentメソッドで使用したいコンポーネント名を文字列で渡すと使用することができ、Propsとしてサーバーサイドのセットすることができます。

```
= react_component('FooComponent', props: {bar: 'baz'})
```

やっていることとしてはHTMLのdata属性にJSONに変換したサーバーサイドのデータをセットしておき、コンポーネントのPropsとして渡す際にObjectに変換しているようです。

また、Rails側のI18n設定（config/locales）をJavaScriptに変換しクライアント側で使えるようにする機能も持っているのでこちらも使用しています。

reactonrailsの導入により部分的にReactコンポーネントに置き換えることが容易になりました。サーバーサイドレンダリングにも対応しているので必要な場合は利用することも想定しています。

#### ・クロスブラウザE2Eテストの導入

フロントエンド環境をドラスティックに変更していくにあたり、意図せずIE11で動作しないということが発生したため、クロスブラウザでのE2EテストをGitHub Actionsを利用し自動化しました。詳細は社のエンジニアブログに書いています。

#### ・TypeScriptの部分導入、既存実装のFlowからの全移行

既存ではFlowでの型チェックが導入されていました。私の入社以前からTypeScirptへの移行は検討されていましたが、進んでいなかったこともあり移行しました。TypeScriptのアドベントカレンダーで書いたのですが、まずは新しく実装するコンポーネントはTypeScriptで書けるよう並行運用ができるようにしました。

その後、既存のソースコードをすべてTypeScriptに移行し先日リリースすることができたので、Railsと切り離しているJavaScriptに関してはすべてTypeScriptへの移行が完了しています。（any使ったところもたくさんあるけど）

#### ・その他

あとは以下のような修正も行ないました。

- テストランナーをmochaからJestに変更し、容易にスナップショットテストができるようにした
- CommonJS形式のモジュールのexport/import方法が混在していたためES Modules形式に統一
- Storybookの導入

コンポーネント開発をチームとしてやっていくぞということでAtomic Designの読書会を始めました。書籍は「[Atomic Design ～堅牢で使いやすいUIを効率良く設計する](https://www.amazon.co.jp/dp/B07CJ5TLK2)」です。デザイナーも参加しており、スキルアップのみならずコンポーネントで開発することのメリットを共有することでモチベーションアップにもつながっていると感じています。読書会のメンバー内でコンポーネントの粒度設計のレビューをするなど実際のプロダクトに活かされていきています。

また週1回のフロントエンドの座談会も始め、日々の開発で困っていることの相談や新しい知識のインプットなどを行なっています。

### 👉 今後について

開発基盤を整備し既存のコードを少しリファクタリングしましたが、これからが本番で、Rails上のCoffeeScriptやSassをReact.js側に移行していきながらUI自体の改善も行なっていく必要があります。既存のデザインもリニューアルしていくプロジェクトも動いているので、便乗しつつReactコンポーネントへのリファクタリングを今後進めていきます。

さらに昨今はデザインやアクセシビリティ向上の重要性も高まっているため、デザイナーと連携しながらデザインシステムの構築などの技術的支援もやっていきたいと考えています。

## マネーフォワード福岡オフィスに入って3ヶ月の所感

入社して3ヶ月、仕事をしてきて感じていることを書きます。

### 裁量を持って仕事ができる環境

これまでの体制としてRailsのエンジニアが中心で、フロントエンドに課題感を持っていたもののなかなか進まない状態でした。その課題感と私のやりたいことが合致したこともあり、提案したことに対してすごく前向きに捉えていただきすごく仕事が進めやすい環境です。同時に責任感もすごく感じるので、やりがいを持って仕事に取り組めています。

### 裁量労働制ありがたい

裁量労働制なので、2人の子供を育てている身としてとてもありがたい環境です。私はだいたい朝9時半ごろ出社して18〜19時前後に退社していますが、家族の体調不良などあれば臨機応変に対応できます。試用期間が終わればリモートワークもできるのでこれから利用していきます。

### エンジニアチーム全体で技術に貪欲

興味がある技術はどんどん触れてみようという意思を感じます。私自身もすごくいい影響を受けています。Tech Talkという福岡オフィスのエンジニアが不定期に集まり、開発環境の効率化やスクラムの話などなんでもよいので技術共有する会があります。私も https://qiita.com/kimromi/items/0a690856051b5bf11766 でお話しました。バックエンドのエンジニアもReact.jsやTypeScriptのキャッチアップも各自やっていてありがたいです。

### Slackなどの非同期コミュニケーションが少ない

社内ドキュメントツールとして [esa.io](http://esa.io/) を使っていて、全職種がドキュメントを残す文化があります。必要な情報は結構まとまっているので、まずesaで検索してみると大概の情報はあります。そのためか、Slackなどでの非同期のコミュニケーションが少ない（前職が多めだったのかもしれない）と感じました。最初は少し寂しさもあったのですが、最近は慣れてきて逆に仕事に集中できているなと感じます。

### フロントエンドエンジニア、デザイナーが少ない（福岡）

現在福岡オフィスにはフロントエンドエンジニアはインターンシップの学生さん含め3人、デザイナーは1人しかいません。ちなみに私は2019年12月からフロントエンドとデザイナーをまとめるチームのリーダーになりました。バックエンドエンジニアを巻き込みつつ仕事していますが、フロントエンド、デザイナーは足りていません！興味を持った方は是非こちらからよろしくお願いします。

- https://www.wantedly.com/projects/124517/
- [https://www.wantedly.com/projects/233776/](https://kimromi.microcms.io/apis/articles/[object%20Object])
- [https://corp.moneyforward.com/recruit/](https://kimromi.microcms.io/apis/articles/[object%20Object])

ということで引き続き頑張っていこうと思います。

マネーフォワードにジョインして3ヶ月で取り組んだフロントエンドの改善と所感

この記事は [TypeScript Advent Calendar 2019](https://qiita.com/advent-calendar/2019/typescript) の 3日目の記事です。

私の所属する[マネーフォワード クラウド経費](https://biz.moneyforward.com/expense)ではフロントエンドの基盤整備が進んでいます。もともとFlowでの型チェックが入っていたJavaScriptのソースコードをTypeScriptへ移行しましたので知見を共有します。この記事ではなぜTypeScriptへ移行するのかの理由などは紹介せず、段階的に移行する方法について紹介します。

## なぜ段階的に移行する必要があったか

既存のJavaScriptのソースコードの数がそれなりに多く、一気に移行し不具合が発生するリスクを抑えるため、少しずつ段階的に移行する戦法を取ることにしました。

```
% find client/ -name '*.js' | wc -l
384

% wc -l `find client/ -name '*.js'`...
57075 total
```

JavaScriptのファイル数は384、行数は57075でした。コンポーネントのテスト自体はある程度書かれていて、テストが通り軽く打鍵テストをすれば問題なく移行できそうなのは幸いでした。

## どうやって移行したか

TypeScriptに段階的に移行するということは、.js, jsxファイル(以下.jsx?)と.ts, .tsxファイル(以下.tsx?)を混在させるということです。.jsx?は既存の方法でビルドをしつつ、.tsx?はTypeScriptとしてビルドなどをするという拡張子別に処理を分ける戦法です。

以下について、拡張子別に処理を分ける方法を紹介します。

- Webpackでのビルド
- Jestによるテスト
- ESLintでのlint

### Webpackでのビルド

もともとBabelを使用していたので.jsx?はBabel(babel-loader)を使用し、.tsx?はts-loaderを利用してビルドする戦略をとりました。Babelの7から対応したTypeScriptのプリセットを使うと既存の.jsx?にまで影響が及んでしまうため、loaderを分けています。

webpack.config.jsのmodule設定は以下の感じです。

```
module.exports = {
  ...

  module: {
    rules: [
      {
        test: /\\.jsx?$/,
        exclude: /node_modules/,
        loader: 'babel-loader',
      },
      {
        test: /\\.tsx?$/,
        exclude: /node_modules/,
        loader: 'ts-loader',
      },
    ],
  },

  ...
}
```

### Jestによるテスト

テストランナーとしてJestを利用しており、.tsx?のテストは[ts-jest](https://github.com/kulshekhar/ts-jest)を利用することでテスト時にビルドと型チェックをしてくれます。ts-jestを使うにはJestのtransform設定に.tsx?はts-jestを使う設定を追加します。(下記はpackage.jsonにJestの設定を書いた例)

```
  "jest": {
    "transform": {
      "^.+\\\\.tsx?$": "ts-jest"
    },
    "moduleFileExtensions": [
      "ts",
      "tsx",
      "js",
      "jsx"
    ],
  },
```

しかし、上記の設定を追加すると.jsx?ファイルのテストがうまく動かなくなります。Jestはデフォルトでは[babel-jest](https://github.com/facebook/jest/tree/master/packages/babel-jest)というプラグインを利用して.jsx?をビルドしています。transform設定に.jsx?はbabel-jestを使用する設定を追加すると動くようになります。babel-jestはJestに依存してインストールされているため、あらたにnpm installをする必要はありません。

```
  "jest": {
    "transform": {
      "^.+\\\\.tsx?$": "ts-jest",
      "^.+\\\\.jsx?$": "babel-jest"
    },
    "moduleFileExtensions": [
      "ts",
      "tsx",
      "js",
      "jsx"
    ],
  },
```

また、ts-jestにはJestのpreset設定用に[3つのPresetが用意されています](https://kulshekhar.github.io/ts-jest/user/config/)。ts-jest/presets/js-with-babel のPresetを利用すると.tsx?はts-jest、.jsx?ばbabel-jestを使ってビルドしてくれるので、transform設定ではなくpreset設定でも同じことができます。

```
  "jest": {
    "preset": "ts-jest/presets/js-with-babel",
    "moduleFileExtensions": [
      "ts",
      "tsx",
      "js",
      "jsx"
    ],
  },
```

### ESlintによるlint

ESlintを利用していますが、ESLintの実行時に設定ファイルの指定と拡張子の指定ができます。.tsx?用の.eslintrcと.jsx?の.eslintrcを別々に用意し、eslintコマンドを別々に実行することで別々にlintすることができます。

```
  "scripts": {
    "lint": "npm run lint:ts && npm run lint:js",
    "lint:ts": "eslint -c .eslintrc.ts.yml --ext .ts,.tsx src/",
    "lint:js": "eslint -c .eslintrc.js.yml --ext .js,.jsx src/",
  },
```

ただlintは最悪あとからでも修正できるため、移行した.tsx?だけlintをかけるとか、後で全ファイルまとめて対応するでもよいと思います。私はlintはあとでまとめて全ファイルにかけるようにし、まずは移行を優先で進めるようにしています。

## あとは気合で少しずつ移行していく

FlowからTypeScriptへ移行する際のビルド、テスト、lintを拡張子別に分けて段階的に移行していく方法を紹介しましたが、ここからFlowで書かれているコードを正規表現などで置換していき、TypeScript導入により厳密になった型チェックで怒られる部分を修正していく作業が待ち受けます。移行の際には[niieani/typescript-vs-flowtype](https://github.com/niieani/typescript-vs-flowtype)などを参考にしつつ移行を進めました。

2019年11月頭頃から移行を始め、実はこの記事を書くまでにはすべてTypeScriptへ移行してリリースまでしている予定でしたが、思ったより手こずりまだリリースまでこぎつけていません。引き続きがんばります。

FlowからTypeScriptに段階的に移行する

<img width="234" alt="image" src="https://user-images.githubusercontent.com/5629074/190892009-876cd815-53ce-44b0-ac16-b7ef1b1ab535.png">

https://www.amazon.co.jp/dp/B0B12CGCR9/

場をつくる　チーム力を上げるリーダーの新しいカタチ

[組織の心理的安全性をどうやって高めるか？ w/ raykataoka - fukabori.fm](https://podcasts.apple.com/jp/podcast/45-%E7%B5%84%E7%B9%94%E3%81%AE%E5%BF%83%E7%90%86%E7%9A%84%E5%AE%89%E5%85%A8%E6%80%A7%E3%82%92%E3%81%A9%E3%81%86%E3%82%84%E3%81%A3%E3%81%A6%E9%AB%98%E3%82%81%E3%82%8B%E3%81%8B-w-raykataoka/id1388826609?i=1000512454859&l=en)

特に「組織の心理的安全性をどうやって高めるか」の観点では聞いていない。心理的安全性についての考え方や他社ではどのようなことを取り組んでいるかを聞きたかった。

心理的安全性を勘違いしていた。他人へのリスペクトやアサーション、不安を煽る可能性などを考えすぎて発言をクローズにしすぎる傾向が自分にはあって、それがストレスとして爆発してしまい他人をネガティブに巻き込んでしまうということがある。ポジティブ/ネガティブ関わらず自分の考えていることをうまく伝えられるようになると良いなと思った。まずは times チャンネルで自己開示してくのがよさそうなのでう少しずつ取り組んでみる。

アサーションやアンガーマネージメント = 我慢になってしまっていそうなので、もうちょい掘り下げて正しいコミュニケーションをとったほうが良さそう。

組織の心理的安全性をどうやって高めるか？ w/ raykataoka - fukabori.fm

<img width="244" alt="image" src="https://user-images.githubusercontent.com/5629074/190892913-131b8a1e-073c-47ad-a006-be8097a88742.png">

https://www.oreilly.co.jp/books/9784873118864/

レガシーを改善したい、そんな想いからこの本を手にとった・・・！

## 事前インプット

- https://www.ryuzee.com/contents/blog/7149

レガシーコードからの脱却

<img width="244" alt="image" src="https://user-images.githubusercontent.com/5629074/190892876-d3a4aa23-2b52-4041-8787-9222e6ad29e6.png">

https://www.amazon.co.jp/dp/B09MS8BML8/

1回読んだけど再度読んでみる。2022年4月で自チームの組織改編が携わって、その際に参考にした本。この本のおかげでEnablingチームが立ち上がって、プロダクト開発とは別軸に改善をしたり開発チームとコラボしたりできるようになった。もうちょっと深堀りしてみたいので読む。

## 事前インプット

- [チームトポロジーによるエンジニアリングチーム構造の負債解消(YouTube)](https://www.youtube.com/watch?v=K96ff87RVho)
- [コンウェイの法則とはなにか](https://hichew-gaburichu.hatenablog.com/entry/2021/02/28/022602)
- [コンウェイの法則と逆コンウェイの法則から組織構造を考える](https://medium.com/i35-267/%E3%82%B3%E3%83%B3%E3%82%A6%E3%82%A7%E3%82%A4%E3%81%AE%E6%B3%95%E5%89%87%E3%81%A8%E9%80%86%E3%82%B3%E3%83%B3%E3%82%A6%E3%82%A7%E3%82%A4%E3%81%AE%E6%B3%95%E5%89%87%E3%81%8B%E3%82%89%E7%B5%84%E7%B9%94%E6%A7%8B%E9%80%A0%E3%82%92%E8%80%83%E3%81%88%E3%82%8B-bf3f32ebb022)
- [存在を約束する言葉「トポロジー」—不可能を可能にするドーナツの輪—](https://www.kyoto-su.ac.jp/project/st/st12_01.html)

## まえがき

ソフトウェア開発には「システム設計」と「組織設計」が重要で、コンウェイの法則を踏まえて開発組織の設計に取り組む本。明確な責任と境界を持つチームにすることで認知負荷を減らしていこう、というのが肝。無限の認知負荷というのをどこかでみたな。

チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計

<img width="243" alt="image" src="https://user-images.githubusercontent.com/5629074/190892838-a4174cde-cb13-4ad6-97ef-09fda2378cba.png">

https://www.amazon.co.jp/dp/B07L2R3LTN/

## 事前インプット

- [『LeanとDevOpsの科学』まとめ](https://qiita.com/takeshi_nozawa/items/c115379fafeb263ed807)
- [texta.fm - 5. Accelerate](https://anchor.fm/textafm/episodes/5--Accelerate-ethnjo)

Notes