人事異動の時期

期の変わり目でそこそこ大きめの人事異動が発生している。

人員配置の最適化といえば聞こえはいいけど個人的な感想だけ言えば、半年かけて作ってきたチームや文化がリセットされてたまったもんじゃないと思う。

一般的にチームが機能し始めるようになるには3ヶ月〜半年程度かかると言われている。
んで、自分が今期面倒を見てきたチームも半年経ち今は技術的な相談くらいしか面倒を見ていない。要するに自律的なチームになれている。

しかし今回の異動で6人チームから3人が異動になったのとチームの事業的な役割も変わった。
新しい人が入ってきたわけじゃないというのは若干マシだけどまたここが機能するようになるまでの数ヶ月、模索の期間が続くはず（形成期、混乱期）

ちなみに自分は今回の異動とは別にひとあし先に異動になっている。
自分の異動の話を打診されたときは、既にチームは機能していたしこのような大きめの人事異動の話は全く出ていなかったので安心して承けたつもりだったんだけど…。*1

とはいえこれはあくまで会社全体のうちの一部署一組織しか見てない自分の感想なので、全社レベルの視点で見ると正しいのかもしれない。今の自分にはわからないけど。

そういえば評価面談をしたとき、現場レベルでのマネジメントは問題ないからもう一段上の視点（？）でのマネジメントを学んでほしいというようなことを言われた気がする。

これはいわゆる「経営者視点を持て」というアレだと思ってるので避けたいんだけど、それとは別に上が何を考えているのかは知っておいたほうがいいのかもしれない。
けどこれって社内政治とかそういうのに繋がりそうという気もしている。

求められていることをもう少し明確にしたほうがいいかもしれない。
その中から汎用的なものを探すという道筋が良さそう。

*1:あと、入社当時に上長になるはずだった人のところに行けるということで喜んで承けた

スクラムしてないのにスクラムマスターと呼ばれて

2020年も終わりですね。

部署が変わってからの仕事上の役割を決めるときになぜかスクラムマスターという名前の役割を与えられていた。

ただしチームはスクラム開発はしていない*1

これには理由があって、

• もともと配属されるはずのチームでアジャイル・スクラム開発の経験をチームに広めてほしいという話があったこと
• （手を動かす以外に）改善の活動をやりますよということをチーム内外へ明示すること

これらのことを上司が配慮してくれたことによる（と理解している）
とはいえ実際にそういう役割だと認識してくれたのは上司2人だけだったけどｗ

自分としては手を動かして成果物を作る以外の活動をする大義名分を得たと解釈して思う存分やらせてもらいました。

具体的なことは過去記事に書いてますが、いろいろ失敗しつつも経験や考えをもとに試したことが奏功したことは自分にとって大きな経験だったと思います。

来年やることはこれを自分のスキル・知識として明確化することですね。
これをやらないと今回の経験がただのラッキーパンチで終わったり自分がボトルネックになる可能性があるからです。

あと、問題・課題はきちんと捉えられているのに解消するための表現が下手くそという指摘もされてるので…。もう少し伝える力を身に着けなければ。

激動の2020年お疲れさまでした。

*1:スクラムしてるとは？という話はあるが少なくともチームはスクラム開発しているという意識はない状態

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の型定義~