webpackerのアップデートをした

大変だった。

その一部始終と分かったこと思ったことを残しておく。

先に書いておくとアップデートできたからと言ってwebpacker理解できたわけではない。

ただwebpackerを扱うときどのあたりを触ったりどのあたりの記述が関係してるのかのあたりはつけられるようになったし、開発サーバー立ち上げるときに流れるログにもちゃんと意味があってそれがヒントになることがわかるようにはなった。

アップデートの手順

1. おもむろにwebpackerをアップデート
2. rails webpacker:init
3. 必要なnpm packageをインストール
4. 初期化前との差分があれば導入する
5. 動作チェック

見るべき場所

おもに見るべきは webpacker.yml と config/environment.js 

environment.jsがbabel他のloaderの設定になっている。

詳しいことは公式に書いてある。
主にはchunkのやり方が変わったこととerbに埋め込むタグ（javascript_packs_with_chunks_tag）を使うこと、画像などはmediaパスになったこと、webpacker.ymlに  extract_css: true を書くこと、が主な対応だった。

webpacker立ち上げるとログにjsやcssのパスが大量に表示されるところがあるけどあれが javascript_packs_with_chunks_tag で読ませるべきパスと実際のファイルの対応になっている。
あれがおかしければ読み込めないし、欲しい形のパスになっていないならenvironment.js内のloaderの設定を見直す、という感じで対応した。

それにしても、webpackerのググラビリティ低すぎ（勝手にwebpackとして検索される）

webpack自体もだいぶ辛いけどwebpackerはwrapされてるのもあって更に辛い。
世に脱webpacker記事が沢山あるのもうなずける。

そんな感じで四苦八苦しつつもなんとかアップデート自体は完了した(3系→5系)
…と思ったらそのプロダクトがサ終することが決まった。

この展開、前にも見た気が…。呪われているんだろうか*1

速習 webpack 第2版 速習シリーズ

*1:一応別のプロダクトにそのまま応用できるわけだから完全に無駄になったわけではない

マネージャーのマネごと

今の部署に来てからマネージャーみたいなことをしている。しかも3プロダクト並行で。実際は役職も権限もないけど。

入った当時の状況

この3プロダクトは毎週リリースをしないといけない。
しかし自分が入った当時、リリース当日朝にやっとレビューが出たり早くレビューが出ても指摘コメントが数十ついてリリース優先で別タスクに回して強引にリリースしたりとかしていた。

この3プロダクトに割り当てられたときに上司から与えられたミッションは「この毎週の定常3リリースがスムーズに回るようにしろ。やり方は問わない」というものだった。

方針

3プロダクトは兼任が多くて単純に人が足りない。 
とはいえ簡単に人が増やせるわけでもないので現状の人間でやっていくしかない。

自分がコード書けば早いとは思いつつ、それだと自分が抜けた時にまた元に戻ってしまうのでなるべく自分が手を動かさず今いるメンバーがやり方を変えたり成長することで対応できるようという方針に決めた。

また、自分が抜けてもそのやり方がある程度持続できるようになれば更に良い。

やったこと

タスクの共有

この状態になるのにありがちなことだけど、毎週のタスクを決める時に実装の方針や何をテストすべきかが共有されていなかった。

なので自分が入ったばかりでプロダクトのことよくわからないから教えてという体で全員いる場で内容と担当者が考える実装方針を説明してもらうことにした。
会話が発生すればそこで質問も発生するので結果として実装方針がより強固になるしテストパターンもある程度明確化される。

そしてそこで話してもらったこともきちんとチケットに書いて残してもらうことにした。

これをすることにより、一部のメンバーしか実装できなかった部分を少しずつビギナーにもやってもらえるようになった。

1on1の実施

今の会社は1on1MTGを積極的にやっていいみたいな空気があったのでそれを使って各チームで合計5人のメンバーと毎週30分ずつ面談をすることにした。

ちょうどこの直前くらいにスクラムフェス大阪で「信頼されるスクラムマスターとはよく相談される人間である」みたいなのを見かけたのでそれを目指そうと思ったのが始まり（スクラムマスターじゃないけど）

speakerdeck.com

結果としてこれはかなり効果が大きかった。
大人数で話している会話の輪に入るのがとても苦手な自分が、既にある関係性が出来上がってるチームに途中から入って信頼してもらう（話や相談を持ちかけてもらえる）状態になるのは普通にやってただけではかなり難しかったと思う。

気をつけていること

プロダクトの数が多いので型通りのスクラムみたいなやつは早々に諦めた（プロダクトの数×毎週のスクラムイベントをするのは時間的な意味で現実的じゃない）
前の部署で型通りを意識しすぎてプラクティス厨みたいになってしまっていたのを気にしていたのもある。

形は気にせず、まずは目の前の問題に確実に対処しようというのは気をつけていた。
出社日ができて近くでタスクに関する雑談や相談が発生してたら必ず首を突っ込むようにもした。

タスクについては毎週「チームで当たっていく」ということを念頭に置いて、最初は無理やりMTGをねじ込んででもタスクの内容や各情報を共有させるようにしていた。
完全在宅ワークなこともあって特に新卒や2年目のメンバーは全然キャッチアップができていなかった。ここは通常通りの出社ならもう少しマシだったんだろうなとは思う。

部署に入ったばかりの頃「必要なときは会話しましょ」というのが盛んにチャットに流れていて既に関係性が出来上がってる前提のやり方を続けてしまってるんだなと思ったのを覚えてる。

基本的に社風として改善を社員同士の仲の良さに依存してる感が強い。
だから既存の社員たちはこれまでのやり方の延長でやろうとするけど完全在宅になり新卒や中途が入ってくるとほころびが出てしまうという感じなんだと思っている。

個人的にはそういうコントロールができないものをあてにするのはよくないと思うのでなるべく仕組み化していく方向で進めるつもり。

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

お取り潰し

それは前回の記事を書いた翌営業日のこと

上司「この事業は撤退する判断をしました。部署は解散となります」

(　ﾟдﾟ) ・・・
　
(つд⊂)ｺﾞｼｺﾞｼ
　
(；ﾟдﾟ) ・・・！？

というわけで部署が解散になりました。当然、チームも解散です。

本当にこの前日に上記のふりかえりブログ書いたばかりだったのであまりのタイミングに笑えてきてしまって、あとで上司に「なんで笑ってたの…（ドン引き）」という反応をもらいました（実話）

というのが3ヶ月前の話。

現在3プロダクトでマネージャーのマネごと（権限はない）をしつつ2つくらいのプロダクトでコードを書くみたいなことをしてます。
プロダクト多すぎってレベルじゃねーぞ！！！

こっちはこっちでいろいろ大変になってたのでいろいろ直したりしてましたがブログ書こう書こうと思ってたら時間が経ってしまったのでそれは次の記事で。

転職して3ヶ月でやったこと・起こったこと

気づいたら転職して3ヶ月が経過していました。
一応3ヶ月は試用期間ということで一部の会議に参加できなかったり時々研修入れられたりしながら過ごしていました。

3ヶ月が経過して一部の会議にも参加が許可されそして特に試用期間中に問題があったとかいう話も聞かされていないのでこのままこの会社で働き続けることができそうです。
今回はコロナの影響で4月から完全リモートになったり業績への影響も少なからずあるはずなので万が一みたいなことあるかもなって少し身構えていたけどなんとかなったようです。

Webpackでディレクトリ下の画像ファイルを動的に読み込む

今担当しているサービスが画像を追加するたびにソースにも画像ファイル名を記述しないといけない記述になっていて、それは面倒なので特定のディレクトリ下にファイルを追加したらコード自体には一切手を加えずにできるようにしたい。

結論から言うと下記の通り(TypeScript)

function App() {
  const importAll = (r: __WebpackModuleApi.RequireContext) => {
    return r.keys().map(r).map(image => { return image as string });
  }

  const images = importAll(require.context('./assets/images', false, /\.(png|jpe?g|svg)$/));

  return (
    <>
      {images.map(image => <img src={image} key={image} alt={image} />)}
    </>
  );
}

webpack.js.org require.context()で読み込むファイルを探すディレクトリと正規表現を指定して対象ファイルのパスを取得できる。


RequireContextの戻り値がanyなので、return r.keys().map(r) の部分だけで見ると unknown[] となっている。
今回は画像を読み込んでいるためsrcに突っ込むために更にmapしてstringにしている。

参考記事

https://qiita.com/proudust/items/d716957e243f9e019fda

https://qiita.com/jkr_2255/items/d23e66323857d3189a00

実践TypeScript ~ BFFとNext.js&Nuxt.jsの型定義~

休み明け用メモ

レビュー指摘が多くてリリースが遅れることを「プランニングで決めなかったから」と言われて、そうはならんやろと思ったので考えをまとめておく

じゃないと休みの間中考えてしまいそう

まず、プランニングで決めなかったからと言って明らかに負債になるコードをマージするのはよくない（特に緊急な課題でもないし）

なぜプランニングで漏れたのか
→このくらいなら理解してると思ったから？

そもそもレビュー指摘されないようなコードを最初から書いてレビューに出せばいいのでは？
→このくらいは自分で考えて到達してほしいと思うが、それを各自の努力に委ねることはできない（博打と一緒だから。趣味ならともかく仕事である以上、品質・納期は守れるように努力するべき）*1
→まずこのレベルから予め周知しておく必要があるレベルであることを認識する

アクション？
→プランニングで逐一何をどこに書くか決める？
→どのようなことをどこに書くのかの方針を先に共有する？

お気持ち
→苛立ちが発生するということはそこに問題がありそうということなのでそれはいいけど苛立ちをそのままぶつけるのは勘弁してほしい
→ぶつけられる側もしんどいし、ぶつけたからといって問題は何も解決しないので

*1:個々人だけのやり方だと効率が良かったり良くなかったり本人の資質みたいなところもある。だから少なくとも仕事で使う部分は仕事中に担保したいというお気持ち

フロントエンドとバックエンドをチーム分けするのは合理的なのか

11月からプロジェクトが変わって、引き続きReactNativeでアプリ開発する仕事をしてるわけですが、今回のプロジェクトもアプリ側（フロントエンド）チームとサーバーサイド（バックエンド）を分けるチーム構成で進めている。

一つ前のプロジェクトもそうやってチームを分けていたけど、イマイチしっくりこないというか無駄が多かったなと感じたので書き残しておく。
フロント/バックの分け方としてはこんな感じ。

• フロント/バックでリポジトリは別
• それぞれのチームのみレビュー（承認）権限がある
• それぞれのチームのタスクのみを担当する

個人的にはフロントとバックが分かれていることで余計な作業が発生しているように感じている。少なくとも（アプリの大部分を占める）単純な機能についてはそう思う。

例えばバックエンドからユーザー情報を取得してその内容を画面に表示するようなユーザー詳細画面を作るとする。
フロント側は画面のレイアウトを、バックエンド側はユーザー情報を返すAPIをそれぞれ作ることになると思う。（既にフロント↔バック間の通信の仕組みは出来ているとする）

フロント側はAPIができていないのでまずはモックあるいはダミーデータで画面を作ることになる。
これらは最終的に消されることになるのでまずコレが無駄。

次にいざ結合してみると様々な問題が発生する。
例えば、

• 表示に必要なデータが取得されていない
• データの型が決まっていない（stringなのかnumberなのか）
• データがないときはnullなのか空文字なのか

ひとつひとつはもちろん大したことじゃないしすぐ直せる。

…と思うだろうけどフロント/バックが分かれている時の修正の流れはこう。

1. 修正してもらう
2. バックエンドチーム内でレビュー（指摘したフロントエンドの人はレビュー権限なし）
3. マージ・デプロイ
4. フロントとの結合再確認

フロントエンドの人にレビュー権限ないからバックエンドチーム内で更に別の人にレビューしてもらう時間を取る必要があるし、もしも修正方針のコミュニケーションがうまくいってなかったらもう一度このやり取りをする羽目になる。

そこはしっかりコミュニケーション取って決めておくところだろとかというのはごもっともだけど、経験則になってしまうけどそれでもやっぱり漏れや認識のズレは発生するしほとんどの人は「ちょっと言って直してもらえばいいことでしょ」と思っていると思う（実際は待ちの時間がかなり発生するわけだが）

とはいえ、たとえチーム分けをしない形にしたとしてもフロント/バックそれぞれのアーキテクチャとかについてはそれぞれの分野で得意な人・できる人がやる感じになっていくだろうし、ある時点ではスキル・知識的にフロント/バックどっちかのタスクをやることが多くなることもあると思うけどそれは別に構わないと思う。価値を届けられないよりはずっといい。

実際、今のプロジェクトはバックエンドが遅れ気味になった*1ためフロントチームの自分とかもバックエンドの機能実装をするようになっている。

1機能がフロント、バックエンドそれぞれの結合で完成するものならそれを分割するのはそれだけコストがかかることだなと感じた。

世の中ではこうやってチーム分け事例がたくさん紹介されているので、こういう問題をどう対処しているのかとても気になるところ。

*1:アーキテクチャ周りの調査が多かったとか、稼働の問題とかもあるけど