好きなことを仕事にするということ

この記事は SHIROBAKO Advent Calendar 2020 の15日目です．

今年は劇場版が公開されたと思ったのも束の間，その前後から他作品の公開延期や映画館の休館などが相次ぎ，周囲の状況も気にしながらいつ見に行けるのかとハラハラさせられた一年でしたね．今回はその劇場版から，丸川元社長のセリフについて考えてみたいと思います．

みゃーもりが思い悩んで丸川元社長に会いに行ったとき，みゃーもりに次のような言葉を投げかけます．

「好きなだけでは続けていけない。作ることで何をしたいのか考えないと。」

(画像は劇場版『SHIROBAKO』本予告より引用)

最初に劇場版を見たとき，最も印象に残ったのがこの言葉でした．

私は Web エンジニアとして働いていますが，もともとプログラミングを始めたのは13歳の時で，楽しさにハマってずるずる続けた結果そのまま仕事になってしまったパターンです．社内の目標設定でその四半期にやることは決定できても，数年後に自分がどうなっていたいのかという中長期な目標は曖昧で明確なものがありません．直近ではパフォーマンスチューニングに興味を持ち，ありがたいことにそれを専任でやるチームを任せてもらっています．楽しくて好きなことを自由にできる環境をいただいているのでとても幸せなことなのですが，そうであるからこそ丸川さんの「作ることで何をしたいのか考えないと」という言葉が深く刺さったのでした．

みゃーもりは TV アニメ24話で，「これからどうしたいのか」という問いに対して「アニメを作ることとアニメを作る人が好きだから，アニメを作り続けたい」という思いを発見しました．劇場版のこの言葉は，それをさらに一歩進めるものといえそうです．劇場版でのみゃーもりは入社6年目でラインプロデューサーを任され，厳しいことや辛いこともはじめの頃の比ではなく襲いかかってきます．そんなときに最後までやり抜く力を発揮するには，「好き」という気持ちだけでは足りず，「成し遂げたいこと」「届けたいこと」というより強く根源的な思いが必要だと諭してくれているのではないでしょうか．

「サービスを速くしてより快適な体験をユーザーに届けたい」「界隈で有名になりたい」「技術力を上げてたくさん稼ぎたい」... 「何をしたいのか」という部分は依然として私の中で定まりきっていないところがあります．常に目標に向かって走り続けるのは疲れてしまいますが，せめて「何をしたいのか」という軸だけでも引き続き探していきたいと思います．

劇場版SHIROBAKO 通常版 [Blu-ray]

伊豆大島へ一週間ワーケーションに行ってきた話

東海汽船が出した，5万円で伊豆大島に7泊8日できるリモートワークプラン

www.tokaikisen.co.jp

を使って10月最終週にワーケーションしてきたので，記録がてらどんな感じだったかを書いてみようと思います！

残念ながら執筆時点でこのプランはもう完売御礼とのことですが，そもそもワーケーションってどうなの？いろいろなところがプラン出してきてるけどどんなことに気をつけて選べばいいの？という疑問にも答えていきます．

伊豆大島とは？

伊豆大島は東京都の伊豆諸島のうち，最も本州の近くにある大きな島です．自分も今回申し込むまで知らなかったのですが，竹芝桟橋からジェット船で2時間足らずと割と気軽にいくことができる島でもあります．

Map provided by OpenStreetMap

椿と明日葉が有名で，大島椿の黄色いパッケージを見たことがある方もいるのではないでしょうか？

www.oshimatsubaki.co.jp

他には，最近ブラタモリでも紹介された三原山という火山がよく知られています．

www.nhk.jp

そこそこ活発に活動している活火山で，直近では1986年に大きな噴火を起こし全島避難したそうです．

プランの詳細

今回宿泊したのはそんな三原山の7合目あたりにある大島温泉ホテルというホテルです．

www.oshima-onsen.co.jp

竹芝桟橋からの往復ジェット船と朝夕の2食つきで5万円，GoTo キャンペーン適用で 32,500 円 + 地域共通クーポン 8000 円だったので実質交通費込み一泊3,500円で泊まることができました！

島への往路

浜松町駅から徒歩8分，独特の形状をしている竹芝桟橋から出発しました．

2階建のジェット船に乗り込みます．

中はこんな感じ．

出発前に撮った桟橋周辺の様子です．天気に恵まれました！

ジェット船は海水を船の下から吹き出すことで船体を浮かせながら航行するため波の影響をほとんど受けず，しかも大島への航路は大半が東京湾内なので全然揺れませんでした．波から波へとジャンプするいわゆる高速船を思い浮かべていたので驚きました．

うとうとしているうちに予定どおり2時間弱で大島に到着です．

ホテルの様子

ホテルは年末まで外装工事を行っており，ぐるりと足場が取り囲んでいる状況でした．

本来は三原山が綺麗に見えるであろう食堂にも足場がかかっていたので，この辺りも今回の格安プランを提供するきっかけになったのではないかと思います．

お部屋は純和室です．ここにも足場が設置されています．

お食事

このプランのすごいところは二食付きなところです．ワーケーションプランでは大抵安い代わりに食事なしなことが多いからです．例えば星野リゾートに一泊3000円で泊まれる！と話題になった OMO7 旭川 も食事なしです．

しかも，内心「安いプランだから通常の場合よりも簡素な食事になるんだろうな...」と思っていましたがそんなことはなく，他の宿泊客と変わらないクオリティの食事が出ました！

海鮮や明日葉を椿油で揚げて食べる椿フォンジュとサザエご飯

刺身舟盛り

金目鯛のしゃぶしゃぶ

金目鯛の煮付け

朝食も毎朝豪華でした！

毎日ちょっとづつメニューが変わるので飽きませんでした．

また，仕事するにあたって気になる昼食ですが，フロントでお弁当を予約することができたため山を降りて調達する必要もありませんでした（別料金700円）．

工事をしている職人さんにも出しているのでは？と思ってしまう山盛りの弁当だったので，座り仕事のエンジニアにはちょっと多い気もしましたが，朝晩が基本的に海鮮なので肉が入っている弁当はまた新鮮な気持ちで食べられました．

仕事環境

さて，本題の仕事環境ですが，まず気になるのはネットワーク環境です．

出発前に

来てみてわかったこととしては、Wi-Fi激弱。
すぐ行方不明になるので、モバイルデータ通信機能を備えていない端末でくるとワーケーションは無理ぽ。
Wi-Fi完備はちょっと看板に偽りありだなぁ。#伊豆大島 #ワーケーション #大島温泉ホテル

— アヤ (@aja_3204) 2020年10月12日

ちなみにこんな感じ。激弱どころか死んでいる上にオープンネットワークな件。 pic.twitter.com/buKnHSVDjE

— アヤ (@aja_3204) 2020年10月12日

というツイートを見ていたので心配していました．ただ，このツイートからは単に WiFi の電波が弱いだけとも読めるので，部屋ガチャによってはルーターに近く安定して通信できる可能性もあります．

自分が泊まった部屋は 208 でしたが，

の写真からもわかるとおり扉を出てすぐのところに WiFi ルーターがあるというかなり高ポジションをツモることに成功しました．

ではネットワークが安定していたのか？というとそれが微妙なところで，

のとおり電波は強めで運がよいと 32 Mbps くらい出るときもありました．

しかし，接続状況はわりと不安定で1時間安定して繋がることもあれば10-15分に一回途切れることもあり，特にルーターから離れる部屋の奥で顕著でした．Zoom での会議もできなくはないのですが頻繁に映像や音声が止まるため，安心してミーティングができるという環境ではありませんでした．

また，和室なのでどうしても座椅子での作業となって腰や首が辛いという問題もあります．テレビの下が収納になっていたので広縁の椅子を持ってきてマシな作業スペースを作ることもできましたが，前述のネットワークの問題で結局ほとんど使わずじまいでした．

ネットワーク環境さえよければ HDMI ケーブルを持ってきて TV をディスプレイ代わりにできた可能性もあるだけに残念です...

ただ，一人で作業している分には部屋に篭る必要もないですし，大自然に囲まれているという利点を生かして気分転換も気軽にできます．

ロビーに PC を持っていって作業したり...

行き詰まったら温泉に浸かって三原山を眺め，

(上記画像は 大島温泉ホテル 公式サイト からの引用)

風呂上がりにアイスを食べたり...

朝はホテルのすぐ裏から三原山山頂まで続いているトレッキングコースを散歩して，爽やかな気持ちで仕事を始められました．

最終日はちょっと早起きして，日本唯一の砂漠「裏砂漠」を散策してから部屋に戻って朝会に出席しました！

2枚目で遠くに見えるのが温泉ホテルです．ちなみにこの裏砂漠はモバイル回線の電波がフルで立っていたので，ここに PC を持ち込んで仕事をすることも不可能ではないと思います（国立公園の特別保護地区に指定されているので派手なことはできませんが）．

清掃面では，仕事中に掃除に来られてしまうと困るので基本的に Please Do Not Disturb を扉にかけていましたが，毎日扉の脇に替えのタオル，浴衣，水，アメニティ，そしてお菓子まで補充して置いていただけたので快適に滞在できました．

観光

土曜日の到着だったので翌日の日曜日と，余っていた代休を取った水曜日の計2日間を観光に充てました（同じプランで滞在していたと思しき他の人はミーティングだけ出てもっと観光している人もいたようです；）

自転車を借りて海辺を漕いだり

地層切断面を見にいったり

名物べっこう寿司を食べにいったり

山頂までトレッキングにいったり

しました！

ワーケーション滞在先の選び方

シティホテル，ビジネスホテル，温泉宿などいろいろなところがワーケーション・リモートワークプランを提供し始めており，今後もじわじわとワーケーションは広まっていくのではないかと思います．今回自分は東海汽船のリモートワークプランを Twitter で発見してから即申し込みをしてしまいましたが，この経験を踏まえてどのような観点で滞在先を選べばよいかまとめてみました．

WiFi 環境

東海汽船のアナウンスには 館内Wi-Fi設備も充実しております と書かれていました．わざわざ「リモートワークプラン」と銘打って出すくらいだから高速で安定した回線を用意したのだろう，と鵜呑みにしてしまいましたが，蓋を開けてみるとビデオ会議をするには厳しい環境でした．

• 全ての部屋，部屋のどの位置からでも安定して接続できるのか
• 複数人がビデオ会議をしても遅延が起きない高速な回線が用意されているのか

などは仕事をするには重要な観点ですが，公式サイトには明記されていないことがほとんどです．もともとビジネス用途を多く受け入れてきたシティホテルやビジネスホテルはネットワーク品質も安定している可能性が高いですが，この度のコロナ禍をきっかけに新しく始めた温泉宿などを検討する際には，直接ホテルに問い合わせたり口コミを調べるなどして情報収集に努めた方がよいでしょう．

和室か洋室か

エンジニアなど PC に向かってキーボードを叩くことが主な仕事の場合，和室は作業にあまり向いていないと言えます．テーブル・椅子など快適な作業空間が確保できるのか，事前に館内設備や間取りを調べておくことをお勧めします．

都会か田舎か

都会であれば食事の調達に困りませんし，急な出費など何かあった場合でも対応できる可能性が高くなります．一方で田舎は自然豊かでリフレッシュできますが，利便性には劣ります．食事の有無と絡めて目的地を考えるとよいでしょう．

仕事の予定を見極める

今回は重要なミーティングが詰まっているという状況ではなかったため，ネットワークの問題もさほど影響を受けずに仕事を進められました．また，極端な話ですが急に出社の必要が出た場合でも旅先ではなかなか難しくなります．諸問題が発生しても影響を抑えられるよう，あまり多忙な時期は避けた方がよいでしょう（問題が起こらなくても現地に行くと観光したくなりますし）．

持っていくと便利なもの

持っていったものと持っていけなかったものがありますが，あると便利と感じた品々です．

• モバイルルーター，あるいは充分な通信量の余裕があるモバイル回線を契約しているテザリング可能なスマホ
  • 現地で用意されているネットワーク環境に問題があった場合にバックアップとして利用できます
• HDMI ケーブル
  • 備え付けのテレビをサブディスプレイとして使うことができるようになります
• 外付けキーボードとトラックパッド (またはマウス)
  • MacBook Pro のディスプレイの位置を調節して作業ができます
• イヤホン
  • 宿の壁が薄い可能性があるので，イヤホンをしてミーティングに出ると安心です

おわりに

しょっちゅう映像が止まる状況にも協力していただいた同僚には感謝しきれません．本当にありがとうございました！

観光も仕事も中途半端になるのではないかと初めはワーケーションに懐疑的でしたが，結果として今回のワーケーションはとてもいい気分転換になりました．GoTo トラベルが残っているうちに試してみてはいかがでしょうか？

vendor.js の終焉と Granular Chunks

webpack を使った code splitting のベストプラクティスとして，v3 以前の CommonsChunkPlugin の時代から node_modules 以下に置かれている依存ライブラリを vendor.js という単一の chunk にまとめる方法が紹介されていました．

これは webpack の公式ドキュメント Caching | webpack や Google の Make use of long-term caching  |  Web Fundamentals  |  Google Developers でも説明されている通り，「ライブラリのコードはアプリケーションコードに比べると更新頻度が低い」という仮定のもと vendor.js にライブラリコードを切り出すことで，キャッシュ効率をよくすることが主な目的でした．

しかし時は流れ，いつしか「ライブラリのコードは vendor.js に切り出すもの」という習慣だけが根付き，特に理由を考えずに盲目的に実施するものになってしまったように思います（少なくとも私はそうでした．webpack v4 から導入された SplitChunksPlugin の Examples には全てを vendor.js に固めるのはやめた方がよいと書かれているのできちんとドキュメント読みましょうという話ではあるのですが...）．SplitChunksPlugin のデフォルト設定が vendor.js を生成するようになっていることもそうした習慣を後押ししたかもしれません．

その間にパッケージの更新を取り巻く状況は大きく変化しました．Greenkeeper，Renovate，Dependabot といった依存パッケージの更新を Pull Request の形で通知してくれるサービスが広まり，場合によっては automerge 機能で半自動的なパッケージ更新まで行えるようになったことで，ここ数年で毎週や毎日などの高い頻度でパッケージを更新する習慣が急速に普及しました．

このような環境では，前述した「ライブラリのコードはアプリケーションコードに比べると更新頻度が低い」という仮定は全く成り立たなくなります．スプリントごとにリリースしている場合にはほぼ確実にリリースごとに vendor.js のキャッシュが無効化されることになりますし，Continuous Deployment で一日に何度もリリースしているプロダクトでもアプリケーションコードと同等以上にライブラリが更新されるでしょう．

vendor.js の利点であったキャッシュ効率のよさがなくなってしまうと，今度はその欠点が目立つようになってしまいます．それは「特定のページでしか使われていないライブラリも vendor.js に固められることで，すべてのページで読み込まれるようになってしまう」という点です．せっかく routes ごとにアプリケーションコードを分割していても，依存ライブラリが同じところに固まっていては片落ちといえるでしょう．

この問題を解決する一つの方法が，Next.js 9.2 で導入された Granular Chunks と呼ばれる設定です．これは Google の Chrome チームによる研究に基づいたより効率的な chunk splitting の方法で，以下のような戦略からなります:

• 160 KB 以上の依存パッケージは個別の chunk に分ける
• react, react-dom などのフレームワーク（≠ライブラリ）を一つの chunk にする
• そのほかの共通モジュールを必要な分だけ切り出す（デフォルトよりもかなり多くの chunk を生成する設定になっている）

実装のより細かい部分や誕生の背景などを含めた詳細については Improved Next.js and Gatsby page load performance with granular chunking を参照いただきたいのですが，これだけでも Granular Chunks が依存ライブラリを過度に特別視することなく可能な限り chunks を分割することで，各 route において必要最小限のコードを読み込むようにしようとしていることがわかるかと思います．

まとめ

• 依存パッケージを高頻度に更新しているプロジェクトにおいては，vendor.js に依存パッケージを固めるのは却って悪手となる
• vendor.js のように「一つの chunk に共通モジュールを全てまとめる」という戦略は非効率であり，Granular Chunks はそれに対する一つの解である
  • しかも Google Chrome チームの研究という裏付け付き

Differential Serving の実装に module-nomodule pattern を使うべきではない

タイトルはやや誇張気味ですが，最近某所で differential serving を導入しようとして考えたことのまとめです．

なお，differential serving の概念には CSS や画像なども含まれることがありますし，実現方法にも polyfill.io などの外部ソリューションが存在しますが，本稿では JS の bundle を自前でなんとかする場合に絞って議論することをあらかじめお断りしておきます．

TL;DR

• module-nomodule pattern は differential serving を始める一歩としてはよいが，長期的には負債になる可能性がある
• きちんとやるなら UA sniffing なり feature detection なりで分岐させるべき

Differential Serving とは

そもそも differential serving とは何かについて簡単に説明します．知っている方は読み飛ばして大丈夫です．

Differential serving とは Progressive Transpilation, Smart Bundling などとも呼ばれるテクニックで，ES2015+ を解釈できるブラウザと解釈できないブラウザとで配信する JS を変えるというものです．

2016年，@babel/preset-env の登場によって我々はターゲットブラウザを指定して柔軟にかつ自動的にトランスパイルの度合いを変更できるようになりました．

しかしながら @babel/preset-env は spec のサポートが最も貧弱なブラウザに合わせてトランスパイルを行うため，サポート環境に Internet Explorer のような古いブラウザが含まれているといくら Firefox/Chrome/Safari が最新の spec を実装しても最終的に ES5 のコードへ変換されてしまう状況が続いてしまいます．

すると本来は不必要なトランスパイルによりコードサイズが増えたり ES2015+ に合わせた JS エンジン側の最適化の恩恵が受けられなかったりなどの問題が発生し， @babel/preset-env の smart さを充分に発揮できなくなってしまいます．

そこで考えられたのが なんとかして ES2015+ のコードが実行できる環境なのかどうかを判別し，使えるブラウザには最低限のトランスパイルだけしたバンドルを配信すればいいのでは？ というアイデアです．

これにより Netflix では 20-40%, Google のエンジニア Philip Walton の実験では minified & gzipped で 50% 以上もバンドルサイズを削減できたと報告され，注目が集まりました．

Module-nomodule Pattern とは

Differential serving を実装する方法はいくつかありますが，その中でも "module-nomodule pattern" と呼ばれている手法は Deploying ES2015+ Code in Production Today — Philip Walton にて紹介されたもので，その実装の簡単さから広まりつつあります．

そもそも differential serving の実現には次の二つの課題を解決する必要があります．

1. ES2015+ が実行できるかどうかをどう判別するか
2. 判別した結果に応じて異なるバンドルをどう配信するか

Module-nomodule pattern では ESModules をサポートしているブラウザと主要な ES2015+ の構文をサポートしているブラウザがほとんど被っていることに注目し，<script type="module"> と <script nomodule> を使って a., b. の両方の問題を同時に解決します．

上記二つの script 要素があった場合，ESModules のサポート状況によってブラウザは排他的にどちらかを読み込みます．例えば

<script type="module" src="modern.mjs" />
<script nomodule src="legacy.js" />

という二つの要素があると，読み込まれるスクリプトは以下のようになります．

ESModules のサポート	modern.mjs	legacy.js
🙆‍♂️	読み込む	読み込まない
🙅‍♂️	読み込まない	読み込む

ここで，ES2015+ のサポート状況を合わせるとこうなります．

ES2015+ のサポート	ESModules のサポート	modern.mjs	legacy.js
🙆‍♂️	🙆‍♂️	読み込む	読み込まない
🙅‍♂️	🙅‍♂️	読み込まない	読み込む

つまり，判別問題と配信問題を一挙に解決できるのです．

あとは modern.mjs を「ESModules をサポートしているブラウザが理解できる構文だけになるようトランスパイルする」ように設定して生成するだけです．幸いなことに @babel/preset-env の targets にはこのための専用の設定である targets.esmodules が実装されているので，設定を true にするだけでよくブラウザを列挙する手間はかかりません．また上で説明した ESModules 読み込みの排他制御部分にバグがあるブラウザが若干存在するのですが，それを自動的に解決する Webpack プラグイン webpack-module-nomodule-plugin もあります．

まさに至れり尽くせり！これで全て解決！といきたいのですが，この方法には長期的な視点で見ると問題があります．

Module-nomodule Pattern の問題点

お気づきの方もいると思いますが，この方法ではターゲットブラウザが「ESModules をサポートしているブラウザ」に固定されてしまいます．具体的には https://github.com/babel/babel/blob/master/packages/babel-compat-data/data/native-modules.json で定義されているブラウザです．

これらブラウザの下限バージョンは，原理上今後どんなに新しいブラウザがリリースされようと変わることがありません．つまりこれでは新たな "babel-preset-es2015 問題" あるいは "last 2 versions 問題" とでも言うべき状態になってしまいます．2 年後の 2022 年，Chrome のバージョンが 100 の大台に乗る頃になってもずっと Chrome 61 をサポートし続けなくてはならないということはないでしょう．

せっかく @babel/preset-env と differential serving でターゲットを柔軟にカスタマイズして配信できる体制を整えようとしているのに，歴史を繰り返す必要はありません．

Module-nomodule Pattern を使わない Differential Serving の実装方法

では module-nomodule pattern を使わない場合にはどのように differential serving を実装したらよいでしょうか？ これには二つのアプローチがあります．

Feature Detection

Netflix にて紹介された 方法で，以下のような ES2015 で導入された構文を使ったコードを eval で実行して a. の判別問題を解決します．

この方法は，テストに使用するコードを変更することで柔軟に feature detection を行える点，および一般にアンチパターンとされる UA sniffing を避けられる点が利点です（Netflix では sniffing と併用していたようですが）．

一方で欠点としては browserslist ベースのツール (@babel/preset-env や autoprefixer など) との相性があまりよくない点が挙げられます．これらのツールは「サポートするブラウザーのリスト」を指定する必要があるので，「ブラウザーリスト→ ES の構文」という順序で判断が行われます．一方 feature detection では変換対象の ES の構文を決めてビルドしておき，その構文をブラウザがサポートしているかどうかを実行時に判断します．つまり，考える方向が真逆になっているのです．（反対に，TypeScript のコンパイラ tsc のように出力先の ES version を指定して変換するようなツールでは feature detection と相性がよいと思われます）

一方で b. の配信問題についてはスライド中で特に紹介されていませんが，Cookie を使った制御が出てくるところからおそらくバンドル生成時に app.bundle.es5.js と app.bundle.es6.js のようにファイル名を分けておき，Cookie や feature detection の結果からどちらを配信するか判断していたものと考えられます．

User-Agent Sniffing

愚直に User-Agent を見て出し分ける方法です．Feature detection の項で説明したとおり browserslist ベースのツールと相性がよい一方，tsc と一緒に使うには少し工夫が必要と思われます．

ビルド時に指定したターゲットブラウザと同じ分け方でファイルを出し分けるようにすれば a, b の問題はともに解決できることになります．

具体的には，CDN・サーバーサイド・クライアントサイドのいづれかの場所で browserslist に指定したクエリと同じブラウザ振り分けを UA ベースで実現すれば OK です．Node.js や クライアントサイドでは ua-parser-js などが，VCL では @financial-times/useragent-parser または @financial-times/polyfill-useragent-normaliser などが使いやすいと思います（これらの parser や normaliser では browserslist の "last 2 versions" のような指定ができないため，ターゲットブラウザの更新方法など運用を工夫する必要はあります）．

github.com github.com github.com

おわりに

Feature detection や User-Agent sniffing と比べると配信部分にほとんど手を加える必要がないという点で module-nomodule pattern の手軽さは際立っています．そのため「まず differential serving を使ったチューニングの第一歩として導入する」というケースでは重宝されるでしょう．

一方で長期的な視点ではこの記事で書いたような問題を孕んでいるため，数年後に技術的負債となる可能性も考えられます．今後も継続的に differential serving によるアプリケーション提供を続けていく予定があるのであれば，運用を含めたより堅牢な実装を検討するメリットはあるのではないかと思います．

---

超速！ Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる WEB+DB PRESS plus

『エンジニアのためのマネジメントキャリアパス』から見る SHIROBAKO

この記事は SHIROBAKO Advent Calendar 2019 - Adventar 24日目の記事です．

はじめに

はじめに少し自分語りをさせてください．

このアドベントカレンダーには初参加ですが，歴代の多くの参加者と同じく，私も学生の時に SHIROBAKO を見て今は社会人となった人のうちの一人です．社会人二年目で Web フロントエンドエンジニアとして働いています．

チームリーダーから割り当てられた案件をこなすことで精一杯だった一年目と異なり，二年目の今年は2-3人の小規模なチームを率いての開発や，インターン生のメンター，同じチームに配属となった新卒のトレーナーをするなど，マネジメントスキルも問われる一年間でした．

そんな中で出会ったのが『エンジニアのためのマネジメントキャリアパス』という本（以下単に「本」と略します）です．発売されてから界隈で話題になったのでご存知の方もいらっしゃるかもしれませんが，この本には書名の通り「エンジニアがジュニアエンジニア→テックリード→ CTO とマネジメントのキャリアラダーを上がっていく場合，どのようなスキルが必要なのか？」が書かれています．初耳だという方には， 『エンジニアのためのマネジメントキャリアパス』読了 に内容がよくまとめられていますが，ぜひ書籍も手にとってみてもらいたい本です．

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

五年間にわたる SHIROBAKO Advent Calendar でも繰り返しテーマとなってきたエンジニア（ディベロッパー）と SHIROBAKO の類似性ですが，「マネジメントキャリアパス」という観点から各登場人物を分析してみるとどうなるのか，新人（第一章）とメンター（第二章）に絞って試してみたいと思います．

新人（第一章）

本の第一章では新人が上司とどのように関わっていけばよいかについて書かれています． SHIROBAKO では，我らが主人公おいちゃんを筆頭として，太郎，絵麻，ずかちゃん，みーちゃん，つばき，沙羅，愛など数多くの新人が登場します．

本で新人が上司に対して求めるべきこととして掲げている「1on1」「フィードバック」「トレーニングとキャリアアップ」についてそれぞれ見てみましょう．

まず，Web 業界ではそれなりに浸透してきたと思われる「1on1」ですが，武蔵野アニメーションやスーパーメディア・クリエイションズには導入されていないようです．1on1 は主に「上司と部下の間の信頼関係を築くこと」「要検討事項について上司と定期的に1対1で話す場を設けること」を目的として実施されます．太郎が胸の内に秘めてしまった案件のこじれ，おいちゃんやみーちゃんのキャリアパスに関する悩み，絵麻の作画に関する悩みなどは 1on1 が有効な場面といえそうです．作中では別の方法で解決していましたが，仕組みとして 1on1 を導入できれば悩みをもっと気軽に相談できるようになるかもしれません．特に，矢野さん-おいちゃん，井口さん-絵麻，平岡-太郎のコンビはよい 1on1 ができそうです．

「フィードバック」については，矢野さん→おいちゃん，瀬川さん→絵麻，小笠原さん→井口さんなど数多く描写されています．特に7，8話での瀬川さんから絵麻への原画に対するネガティブフィードバックは好例です．本にもある通りこれは「自分の態度や行動に関するフィードバックをもらうことに慣れていない新入社員にとっては相当居心地の悪い経験」だったと思いますが（絵麻は真面目なので「居心地の悪い」どころではなさそうでしたが），井口さんに相談した経験や，その後の瀬川さんから直接もらえた修正に対する褒めの言葉は，絵麻を大きく成長させたことと思います．

「トレーニングとキャリアアップ」については，職種や人物によって異なりそうです．

もっともしっかり考えられていそうなのはアニメーター陣です．ポジション（動画・原画・キャラデザ・作画監督など）やカットに要求される能力の有無が仕事内容に直結するある意味「技術職」だからというのもあると思いますが，個々人の能力や得手不得手を，アニメーター間のみならず監督・制作進行・ラインPなど他職種の人もしっかり把握している印象を受けました．例えば，井口さんをキャラデザに任命するときの小笠原さんとおいちゃんによる説得や，SHIROBAKO イントロダクション (JUMP j BOOKS)で描かれた絵麻の原画昇格試験のシーンから，個人の持っている能力と成長見込みを丁寧に評価して担当を割り振っていることがわかります（杉江さんの場合は社内の誰も把握できていなかったようですが...）．さらに，小笠原さんの「微力ながらサポートさせていただきます」「井口さんを抜擢したのなら，ちゃんと相談に乗ったりアドバイスしてあげて下さい」という言葉は，アニメーター陣に普段から育成の文化が存在していることを示していそうです．

一方，制作進行組についてはあまりよくわからないというのが正直なところです．キャリアパスについて悩んでいるおいちゃんに対してメンタリングしたり，漠然と「監督になる」と宣言しているだけの太郎に対して具体的に今どのような能力を伸ばすべきかという詳細なアドバイスをしているようには見えません．ただ，本田さん，矢野さん，ナベ P が適宜仕事の進め方について助言をしたり，（人員不足という側面もあるにせよ）おいちゃんにデスクを任せたりしているように，（主人公＝おいちゃん目線ではわからないだけで）先輩陣は後輩のキャリアアップの道を考えてくれていそうです．

また，みーちゃんのいたスーパーメディア・クリエイションズでは残念ながらあまりキャリアについて考慮されている様子はなさそうに思えます．第9話の「私なんて三年くらいずーっと車の内装ばっかりやってる」「俺は五年．車の外装だな」という先輩達の言葉から，車の中でもさらに一つの部分に特化したスペシャリストを育成するような人員割り振りを行なっているのだと思われます．立石社長は「この先，能力や適性に応じて他の CG も作ってもらう」とみーちゃんに話しているように，能力が上がれば他のことも任せられるようになることを示唆してはいるのですが，おそらく適性を見極めた後は同じ部品の制作に特化するようになるのではないでしょうか．このことは会社自体の「車の 3D に特化する」という戦略とも一貫性があるものの，自身の対外的なスキルアップという点では厳しそうです．実際，タイヤ CG に関する技能があることがスタジオカナブンの中垣内社長に伝わっていなかったことからも，前職のスキルを元にした転職活動ではなかったことがわかります．しかし，これはいわゆるブラック企業的発想（人的リソースは使い潰すもの）というところからきたわけではなく，あくまで会社の生存戦略として意図的にそうしており，福利厚生も手厚い企業であることが立石社長を含めた複数人から語られています．みーちゃんがキャリア相談を立石社長に直にしたときにも，立石社長は親身になって相談に乗り，みーちゃんが本当は何がしたいのか？ということを考えるきっかけを提供してくれています．

この「本当は何がしたいのか？」「最終的に自分はどうなりたいのか？」という自分のキャリア上の望みは，上司に頼るべきキャリア上の相談と異なり，自分の責任で考え抜いて明らかにするべきことだと本に書かれています．この点は SHIROBAKO の作品全体を通したテーマである「何のためにアニメを作るのか」と重なることもあって，作中でも多くの人物の「望み」が描かれています（2年前の Advent Calendar 参加記事 キャリアパスどうするねん問題 - アナログ金木犀 の分析が詳しいです）．個人的には，パティシエという夢を叶えた本田さん，自分のやりたいことと業界のミスマッチから去っていった竹中・辻（どちらもSHIROBAKO イントロダクション (JUMP j BOOKS)より）など，必ずしもアニメ業界に留まる人ばかりではないというところが作品の魅力をあげていると思います．

メンター（第二章）

第二章ではインターンシップ生や新人のメンターになったときの心構えについて書かれています．どちらかというとインターンに関する記述（タスクの選び方など）の比重が大きいためそのままムサニに適用できることが多いとは言い難いですが，新人への接し方には共通点を見つけられそうです．

まず，「新人の目を通して業務を見直す」という点について，若干意味は異なるものの近い場面として杉江さんが絵麻に「人に教えるということは、自分にも教えるということ」「言葉にして伝えることで、改めて分かることもあるし」「自分がちゃんと理解してないと、教えられないからね」と話すシーンが挙げられます．今まで教わってきたこと，やってきたことを後輩に言語化して伝えることで，自分の中でも業務内容や大事にしていること（コアバリュー）を整理できたことでしょう．作中では明確に描写されてはいませんが，おいちゃんもつばきと沙羅に指導していて同じような気持ちを抱いたに違いありません．

また，多人数が関わるクリエイティブな業務であるため，「傾聴」の大切さはメンター・メンティー間に限らず繰り返し登場していました．2話でおいちゃんが監督へあるぴんの嗜好を尋ねるシーン，9話で舞茸さんが監督と言葉のキャッチボールをしながら最終話の展開を詰めるシーン，13話でおいちゃんが真っ先に監督へ作品の方向性や表現したいことを尋ねるシーン，絵麻と愛との全体的なやりとりなど，挙げればキリがなく，どの人も傾聴力が高くて羨ましい限りです．反対に，20話までの平岡は，傾聴力が足りずに失敗したケースと言えるでしょう．平岡はおいちゃんが指摘した通りアニメーターとのコミュニケーションが不足していましたが，周囲の人物もまた，ムサニ内外に関わらず平岡とのコミュニケーションが不足していたと考えられます．

おわりに

年末進行で SHIROBAKO をじっくり見返す時間が取れなかったので薄い考察になってしまったのは否めず，年末年始の時間でまた見返したい欲が高まりました．テックリード（第三章）と本田デスクや作画監督，組織のリーダー（第四章〜）と丸山社長，立石社長などの社長陣の関係についても，時間ができたらぜひ考察してみたいと思っています．

ありがとうございました！

個人のポータルサイト nodaguti.github.io を作りました

各種アカウントへのリンクをまとめたポータルサイトとしてずっと about.me というサービスを使っていたのですが，発表スライドなども載せたくなったのと，フロントエンドエンジニャーとしてはこれくらい自前で作らないといけないのではという思いがずっとありました．

何回か作りかけては面倒になって放置していたのですが，今回やっと完成しました．

nodaguti.github.io

Next.js と GitHub Pages でシンプルに作りました．各サービスに載せていた URL も更新しています．

ブログまで引っ越そうとすると Blosxom で作っていたときのようにまた無限に時間が溶けてしまう予感がしたので，一旦はポータル用のペライチだけとなっています． i18n 対応は気が向いたらするかもしれないです． i18next & react-i18next あたりがよさそうに感じています．

作りが簡単なので苦労した点も特にはありませんが，とりあえず完成したというご報告でした．

【電子版あり】RxJS 6に対応した問題集を本にして技術書典7で頒布しました

先日開催された技術書典7にて AbemaTV の有志が集まって出版した AbemaTV Tech Book に参加し， AbemaTV で学ぶ RxJS と題して RxJS の記事を寄稿しました！

techbookfest.org

非同期処理やイベントを効率的に，かつ宣言的に処理することのできる RxJS は，Angular にとどまらず React など他のフレームワークを使用した Web アプリケーションを構築する際にも便利なライブラリです．

しかしながら，RxJS には 100 以上の operator と呼ばれるストリームを操作するためのメソッド群が存在するため，学習コストが高めであり，興味はあってもなかなか RxJS の世界に足を踏み入れられていない方も多いのではないでしょうか．

それらの膨大に存在する operator を使いこなせるようになるためには，さまざまなロジックを RxJS で自ら表現してみる経験を積むのが一番です．ところが，RxJS について解説している記事はそこそこ存在するものの，個々の operator に関する説明が多く，それらを組み合わせて一つのロジックを構築する部分の学習題材が不足しているのではないかと感じていました．

そこで今回，実際に開発の現場で遭遇したシチュエーションを問題形式に仕立て，練習問題集としてみました．ひととおり operator についてざっと学んだ後，手に馴染ませるための補助として活用していただければ嬉しく思います．

書典の会場では完売となったため，BOOTH にて電子版を販売しています．下の「試し読み版」では1問目をみることができますので，まずはそちらに挑戦してみてください！（該当の記事は第2章です）

speakerdeck.com

abematv.booth.pm

願わくば，他の章もご覧いただき，AbemaTV のエンジニアの幅の広さを感じ取っていただけるととても嬉しいです．