2022年の振り返り的な伺か
1月8日である。
年末年始の休暇もまもなく終わりを迎える。仕事始めにショック死しないために「明日から仕事が始まる妄想」をしてメンタルのソフトランディングを図りたい。（図りたくない）
さて、今年も重い腰をあげて振り返りを書いていく。2020年から書き始めて3回目となる。割と自分はちょっとした記事の執筆でも膨大な時間を費やし苦しみ喘ぐ方なのだが、後々見返すと達成感がありそれがギリギリ腰を持ち上がるウェイトに抑え込んでくれている。成功体験ヨシッ！
例によって、すでに2023年なのだけどわかりやすく「今年 is 2022年」のノリで書いていくぞ。
ざっくり仕事の話
今年も仕事の話から振り返る。
まず、メインのお仕事は変わらず引き続き年末調整のプロダクトを担当した。日々のスクラムイベントをこなしつつ、スプリントでプロダクトバックログアイテムを撃破していった。
自分個人が一番印象に残っているのは以下のテックブログに書いた事例で、解決を目指す課題の選択からそれを解決する手段まで何かと組み合わせ爆発気味で意思決定に悩むことも多かった。最終的にはうまくいってほっとした。
記事に対する反響はもうちょいあると思ったんだけどなぁ〜〜と思いつつ、 12月のアドベントカレンダーの時期はオーバーインプットになりがちなので、1つ1つの発信に対するコンバージョンが落ちるのはやむなしという気持ちもある。南無〜。
ちなみに、記事の趣旨から外れるので書かなかったのだけど、microCMSというサービスに触れていると「いちサービスのファンとなるユーザーの気持ち」が感じられる場面がいくつもあり勉強になった。まさに求めていた機能を見つけたときのテンション↑↑とか、新機能や改善のリリースがあったときのわくわく感とか、不具合に嵌って問い合わせるとシュッと回避方法を回答してもらえたときの安堵感とかとか。
たぶん、エンジニアあるあるだと思うんだけど、ユーザーからの問い合わせ対応のときに目線がバグの解析に向きすぎちゃうというバッドプラクティスがあって、ユーザーが求めているのは今直面している問題の回避策なのでバグそのものへの関心は薄いよなーと自身の体験を通してあらためて思った。
あとあとプロダクトのロードマップを一般公開しているのもとても素敵だな〜〜と思う。こういった本来の意味でのよきUXの積み重ねがファンを作るのだろう。
その他サイドプロジェクト的なお仕事もあれこれやっていた。
「全プロダクトのnpmライブラリの利用状況をスプレッドシートに出力する」ヤーツは去年の成果なのだけどちゃんと記事にしてみた。GASはめっちゃ便利なのだけどウェブフロントエンド開発のノウハウをそのまま持ち込むと何かとyak shavingの世界に引きずり込まれがち + GASの情報は少なくて”濁”りがちになるのでなんかそのへんの知見を書いた。
ヘルプセンターの開発では技術的にはNext.jsを採用した。自分は商用サービスでNext.jsを利用するのは初の試みだったのだが、SSGとリンク先データのprefetchあたりの恩恵に授かり爆速で動くようにできたのがとてもよかった。
最近のトレンドであるという理由だけで技術選定するつもりは全くないけれど、それはそれとして業務で利用できると楽しいし、プライベートの時間を捻出せずとも経験値が勝手にたまるのでお得である。
Todoist + GTDもどきで先延ばし癖と戦った
自分はいわゆる「夏休みの宿題は8月末くらいからはじめるタイプ」で、なんなら追い込んでからの方が結果的に短い時間で終わると正当化して生きてきたのだけど、実際に終わらんかったときの気まずさとか、先延ばし中はマインドシェアを奪ってMPへスリップダメージが発生するので、健全に生きるため真面目にどうにかしようと考えはじめた。（※社会人12年目です）
これ系の解決策についてググると大体「やる気が起きないときはまずは始めてみること。そうすればやる気が出てくる」といういわゆる「なるほど完璧な作戦っスね―――ッ 不可能だという点に目をつぶればよぉ～～ソリューション」が出てくる。
まぁでも始めてしまえばやる気が出てくるのは自分の体験としてもわかるので、いかに始めるための敷居を下げるかがポイントになってくる。そこで、色々試してみてそれなりに効果があったものが2つある。
1つ目は、「片足立ちで目を瞑って30秒数えるやつ」である。
いきなり嘘みたいなソリューションだがこれは効果があった。やりすぎると片足立ちスキルが上達して効果が得られなくなる可能性があるが、それはそれでなんか健康によさそうなのでヨシッ！
2つ目が正攻法で、タスクを小さく分割する方法である。
社の1on1でGTDを紹介してもらい興味をもったのではじめてのGTD ストレスフリーの整理術を半分くらい読んでみた。全部読んでないのは、各工程における具体的なプラクティスの話は実際に経験してみないと頭に入ってこなかったのと、いきなり全部をちゃんとやるのは絶対に無理だと思ったのでエッセンスを抑えたあたりでひとまず実践してみようと思ったためである。
なので「ただしいGTD」には程遠いレベルであろうがともあれ実践してみている。
ちなみに、Todoistを利用しているのは「GTD サービス」あたりでググると上位にでてきたので、触ってみたところユーザー体験が非常によかったのでそのまま採用した。
あんまり、GTDできてないけど、「インボックス」をTodoistに集約して、雑にプロジェクトに分類しておくだけでも、結構気持ちが軽くなって生きやすくなった感はある
— diescake (@diescake) September 2, 2022
ゴミ捨てとか、業務のルーチンワーク、とても苦手なんだけど、Todoistの繰り返し機能にブチ込んでおくと、
— diescake (@diescake) September 7, 2022
さほど精神的な疲労なくこなせることに気づいた。
「今日やらないといけないこと」を考えるタスクを先伸ばしにして半日くらい脳に居続けることがストレスだったのかも
というわけで、Todoistが超絶便利なのでストック情報（資料）もそのままTodoistに溜めていたのだけど、非力に感じる場面も増えてきたのでNotionやObsidianを試し始めている。来年はTodoist + いずれかを併用していく予定。
ひどい雹（ひょう）に見舞われた
https://nordot.app/907234865426841600nordot.app
6月という初夏のタイミングで突然雹に見舞われた。石が降り注ぐかのような事態でおそるおそる窓の外を覗くとこの世の終わりみたいな荒れ具合であった。いつ窓が割れてもおかしくない勢いで防風シャッターが大活躍した。
逆にこれほどのマップ兵器にあっても近隣の建物・屋根はダメージを受けているように見えず、世の中の建物は思っている以上に物理耐久値が高いのだと感心した。
ちなみに、後日カーシェアを利用すると車が雹害によってベコベコになっていた。これはつらい。
コーヒーを飲み始めた
何がきっかけだったかは記憶でないのだけど、甘いお菓子とコーヒーって相性がいいのでは！？とこの歳になって気づくきっかけがあったのだと思う。もともとお菓子は好きで日常的に甘いものを食べがちなのでコーヒーを嗜む機会が増えていった。
最初はハンドドリップでYouTubeを見ながら無駄に淹れ方にこだわったりしてそれはそれで自己満足していたのだけど、コーヒーメーカーという家電に興味を持ってツインバードのコーヒーメーカーを買ってみた。
https://www.amazon.co.jp/dp/B07HFP6H3Lwww.amazon.co.jp
いつかのアメトーークの家電芸人で紹介され記憶に残っていたのと、調べてみると評判がよかったり、見た目が好きだったりとかそのへんが理由である。不満がないわけではないが、概ね満足して利用している。
また、このコーヒーメーカーは電動ミルを備えていて豆から挽いてくれるので、PostCoffeeのサブスクも粉ではなく豆で届くように変更した。
PostCoffeeは届いたコーヒーの評価をすると、自分の好みが絞り込まれていってより自分にあったコーヒーが届くようになる仕組みがあり、これによって自分は浅煎りのコーヒーが好みなことをしれた。
ちなみに、ここ半年くらいはめんどくさくなって評価していない。
ねんがんのPS5をてにいれたぞ
去年、ELDEN RINGの存在を知ったあたりからPS5を入手すべくGEOとかTSUTAYAとかドンキあたりの抽選に何度も申し込んでいたのだけど祈られ続け挫折していた。
今年はすでに諦め、SwitchのDARK SOULS REMASTEREDに勤しんでいたころ、豪運の友人がPS5の抽選に2つ当選したと連絡があり1つを譲ってもらった。神か…
結局ELDEN RINGはやっていなくて積んだままなのだが、Ghost of TsushimaとかIt takes twoとか地球防衛軍6あたりをもりもりやっていて満足している。あとは、Tales of ARISEとDEATH STRANDINGを積んでいる。
ちなみに、Switchはこんな感じだった。
Factorioの時間が溶ける話は伊達じゃなかった。ド平日に何回徹夜したかわからない。
Switch版のFactorio、チュートリアルを含めてプレイ時間150時間くらいでロケット打ち上げ完遂しました。概ね2人でやっていたので、工数でいうと300人時です。
— diescake (@diescake) November 25, 2022
モチベーションが落ちてきたので日常に戻れそうです。
2022年ベストバイ
いきなりモノではないのだけど、一番QOLが向上したのは間違いなく「ヒゲ脱毛」だと思う。12月に1回目の施術をしたばかりなのでまだまだ脱毛進捗としては20%くらいだけど、1回だけでもめちゃくちゃ効果があって感動した。
1週間経ち、髭がぽろぽろ抜け始めてきた。
— diescake (@diescake) December 11, 2022
1wave（照射時に活性化していた毛根）は沈黙したっぽい。
効果は個人差が大きいからか、かなり控えめな説明を受け続けていたので、ここまで即効性があると思ってなかった
こんなんなら10年くらい前にやっておけばよかったわ〜〜、という話を脱毛に詳しい？友人にしたら、昔はそんな即効性なかった（単に体質の違いかもしれない）ので技術的に進歩してるのかも？とのことだった。
ちなみに、昔にヒゲ脱毛に対する懸念をネタツイしていて自分でちょっと笑ってしまった。
ヒゲの永久脱毛の懸念としては、今後、地球外の知的生命体と交流することになり、ヒゲを伸ばすのが地球人のマナーとかなると地球外資系等企業での出世は不可能になるがそれは諦めよう。
— diescake (@diescake) January 4, 2017
他に買ってよかったものとしてはこのあたりがよかった。
https://www.amazon.co.jp/dp/B08T5NQZD3www.amazon.co.jp
横向きに転がってだらだらしやすいとか、横寝やうつ伏せでSwitchとかスマホ操作しやすいとか、形状をシュッと変えられるのが思った以上に便利だった。
https://www.amazon.co.jp/dp/B099NBX9BXwww.amazon.co.jp
11年ぶりにテレビを買い替えた。
4K出力できるPS5やVODの用途をメインに考えていたのだけど、タイムシフト（いわゆる全録）は思っていた以上に便利だった。
もともと昔からテレビを見る習慣はないのだけど、YouTubeやVODと同じラインにTVのコンテンツが並ぶと興味が湧くものも結構あることに気づいた。「お、このバラエティ、ワイの地元特集やんけ！何がピックアップされてるんやろー」とか、「あ、なんかこのスタートアップが題材のドラマ、人間関係が地獄でバズってたやつだ」とか。
あとは、もともとChromecastを利用していたので、TVそのものがYouTubeやNetflixといったサービスをサポートする必要性はないと考えていたけど、リモコンから1ボタンで見れるとそれはそれで便利だった。
まぁYouTube TVなんかは能動的にあれこれコンテンツを探すことを想定していない（と思う）ので、コンテンツを探す場合はスマホからpushした方が早いのだけど…
総括
という感じの1年でした！
来年はというと、仕事としてはチーフというプレイングマネージャーのポジションになる。開発を継続しつつ1on1や評価のようなピープルマネジメント業が入ってくる感じで、働き方や考え方に変化があると思われる。
あと、コロナ禍に入りフルリモートになってからずっと物理的に人と会う機会が少ないままだったので来年はもっと人に会っていきたい。ひらたくいうと酒！酒を飲むぞ！
そうなると、ほぼ外出しない前提で引っ越したこの物件ももうちょい最寄り駅や都内へのアクセスがよいところを探すのもありかも〜という気持ちになってくる。賃貸ではなく家を買うという選択についてもちゃんと考えないと…考えないと…（先延ばし中）
では！今年も散ッ！！
契約中のサブスクを整理してみる
まさかの1年の振り返り以外の記事投稿である。
自分は割とオンラインだとカジュアルに課金してしまうタイプなので、契約中のサブスク（月/年額課金サービス）もそこそこあるのだけど、 契約している数・費用を把握していなかったので、ふとリストアップしてみようと思い立ったのだ。
というわけで、Gmail・AppleアカウントのSubscriptions・マネーフォワードのログあたりからピックアップした。
こんな感じだ。
| 分類 | サービス・会社 | プラン | 月額（円） | 年額（円） |
|---|---|---|---|---|
| 動画・音楽 | NHK | 地上波 + 衛生 | 2,220 | 26,640 |
| 動画・音楽 | Netflix | スタンダードプラン | 1,490 | 17,880 |
| 動画・音楽 | YouTube | Premium | 1,550 | 18,600 |
| 動画・音楽 | Spotify | Premium Duo | 1,280 | 15,360 |
| ゲーム | パズドラ | パズパス | 980 | 11,760 |
| ゲーム | PlayStation | PlayStation Plus プレミアム | 854 | 10,250 |
| ゲーム | Nintendo Switch | Nintendo Switch Online | 200 | 2,400 |
| 食料・飲料 | PostCoffee | 15杯x2回/月 | 4,925 | 59,100 |
| 食料・飲料 | Amazon | 水（定期便） | 4,000 | 48,000 |
| 食料・飲料 | BASE FOOD | 月毎に商品・数を選択 | 3,000 | 36,000 |
| 食料・飲料 | Amazon | 炭酸水（定期便） | 2,500 | 30,000 |
| ネット | UberEats | Eats Pass | 498 | 5,976 |
| ネット | Amazon | Amazon Prime | 408 | 4,900 |
| ネット | 食べログ | プレミアムサービス | 400 | 4,800 |
| ネット | Apple iCloud | 50GB | 130 | 1,560 |
| ツール | DeepL | DeepL Pro | 750 | 9,000 |
| ツール | Todoist | Todoist Pro | 492 | 5,900 |
| ツール | Money Forward ME | プレミアム会員 | 442 | 5,300 |
| その他 | GitHub | OSS Sponsorships | 716 | 8,592 |
| その他 | お名前.com | diescake.com | 117 | 1,400 |
| 合計 | 26,952 | 323,418 |
ふむり…
26,952円/月 は高いな！！
以下とりとめのない感想である。
- 「高いな！！」と思ったけど、食料・飲料が半分くらい占めるのでこんなもんか…？
- 動画・音楽系は安定して高い。NHK奴め…
- 意外にもネットサービスやツール系の費用はさほどでもなかった
- パズパス、こうやって比較するとPlayStation Plusプレミアムより高いのか…
- PostCoffee、自分の舌だと繊細な味の違いはわからないので、カルディーのキリマンジャロで満足説がある
- 水が高いのは利便性重視で500mlのペットボトル（つぶしやすいやつ）にしているせい
- 「お名前.com」は最後まで気づかなかった。年額課金系はメールでも見つけづらいので強敵
ちなみに、一番高いのはコーヒーだったわけですが、
以前ドリップコーヒーの銘柄を伏せて飲み比べしたときの感想はこちらです。
ドリップコーヒーの飲み比べをしてわかったことは、熱いコーヒーの方がおいしいでした。 pic.twitter.com/eBOeT09RbH
— diescake (@diescake) March 6, 2022
2021年の振り返り的な伺か
1年ぶりのブログである。
「おし、技術的な話をちゃんと書くか！！」としばしば極稀に思うのだけど、アウトプットする場としては会社のテックブログ・Zenn・Qiitaあたりに向いてしまうし、
技術以外の森羅万象はTwitterに垂れ流していて、改まってブログに書き出すほどのポエムもなかったりで、専ら振り返り専用スペースとなりつつある。
一応「うぇっぶふろんとえんど」をシノギにしていることもあり、「ポートフォリオも兼ねて遊べるブログシステム作ったろ！」という内に秘めた想いはあるものの内に秘めた想いのままである。
まぁまぁ、今年も色々と変化があったので記していくぞい！
（※ これを書いている時点で「2022/01/08」だけど、「今年 is 2021年」のノリで書いていきます！）
主な仕事とかスキルセットの話
去年に引き続き同じプロダクト開発に携わった。
去年は入社早々担当プロダクトのリニューアルというドエレー"HEAVY"なミッションがあり、そこにほとんどのコストを割いてしまったので、泣く泣く断念した課題・既知の不具合（a.k.a. 喉に刺さった小骨）がたくさんあったのだけど、今年はそれらを処しつつカイゼンに集中できた。
また、去年の開発スタイルは、ほぼカンバン運用 + コンポーネントチームで、自分はほぼ100%フロントエンドにコミットしたのだけど、今年の開発スタイルは、スクラム + フィーチャーチームで、その思想に沿ってフロントエンド以外にも、バックエンドやUIデザイン、文言検討、テスト（QA）など、幅広いタスクに手を出してこれた。
特に、バックエンドのコードを書いた経験がほぼ "無" で、ウェブアプリケーションを開発するエンジニアとしてずっと課題意識があったので、スプリントバックログの状況をみつつ必要に応じて「おし、バックエンドタスクやったるかー」くらいの動きができるようになったのはよかった。実際には、フロントエンド：バックエンド = 8:2くらいでやっていたと思う。
UIデザインや文言検討（UXライティング）については、何かしらの知識を体系的に身に着けたのではなくて、場数を踏んで経験的にレールに沿った設計やレビューができる場面が増えたくらい。
UIの体系的な知識といえば「オブジェクト指向UIデザイン」の輪読会に途中まで参加していて、ウェブUIに関して自分が経験的に感じていたことが言語化されていてとても学びがあってよかった。
文言に関しては、もしあなたが団長の手刀を見逃さなかった人くらい注意深い人であれば、この振り返りのタイトルが去年と異なっている点に気づいただろう。
元々、半角英数字と全角文字の間は半角スペースを空ける派だったのだけど、プロダクトのライティングスタイルに合わせて詰めるようになった。こうした理由は「このスタイルの方が優れているから」というわけではなくて、複数のスタイルを書き分けようとするとつい混在させちゃって ┌(┌՞ਊ՞)┐ｷｪｧｧｧｪｪｪｪｧｧｧ ってなるので統一したろー、という考えからである。VSCode以外でももっとtextlintの寵愛を受けていきたい。
というわけで、そんなこんなこともあって割とスキルセットは山型化して裾野が広がった1年だったように思う。
textlintの話
社内プロダクトの文言の揺れに対してtextlintで立ち向かった。
ふとしたタイミングでカジュアルに有志が集まって、あれこれ0➔1を推し進めていくムーヴはとてもベンチャーみがあってよかった。
チームに「エンジニア」という肩書のメンバーは自分1人だったので、共通ルールのプリセットの管理周りだったり、ソースコードを対象にlintした際の調査・検証だったり、各プロダクトへの導入をサポートしたりしていた。（とはいえ、エンジニア以外の人がごりごりコードにコミットしてくれるので実は大したことはしていない）
ちなみに、夏に一度この辺りの話をネタに【PLAID×SmartHR×Uzabase×OPEN8 】SaaSプロダクトのフロントエンド最前線で登壇させてもらった。
（この題材は）いうほどフロントエンド最前線なのか…？というのはありつつも、文言という要素はあらゆるアプリケーションに共通した概念なので、そこそこ多くの人に関心をもって聞いて貰えたみたいでとても嬉しかった。
ちなみに、リモート（ウェビナー形式）で勉強会に登壇したのはこれが初めてだったのだけど、視聴者のレスポンスが虚無なので、すべてのボケが滑った空気になることを学びました。強いハートとラヴをもって挑もうな。
さて、振り返ってみると自分がtextlint絡みで直接発信できた情報はこれだけなのだけど、チームメンバーは盛々記事を書いたり、textlintのOSSスポンサーになるために社内調整を進めたり、他社のUXW・デザイナーとコミュニケーションを取って情報交換会を開催したりしていた。とてもすごい。
ベンチャーみがあってよかった。（2回目）
スクラムの話
今年は割とがっつりスクラムをキメた。
周期的に振り返り（レトロスペクティブ）の場がありディスカッションするので、チーム・組織の課題とか、理想像みたいなものを考える機会が増えた。元々、チームビルディングにまつわるエトセトラは苦手な部分で、課題発見能力はなかなかプアーだと感じていたのだけども1年通して少しは経験を積めた気がする。
スクラムという仕組みを踏襲することは決して難しくはないけど「ちゃんとする」のがムズいと感じるのは即ちコミュニケーションの難しさだよなーと思うことが多かった。
コミュニケーションの話
去年は担当プロダクトの開発にリソースを極振りどころか120%くらい振っていて、特に繁忙期はそれ以外の全て削ぎ落とすような動き方をしていたけど、今年は1年通して組織を横断した活動が色々できたのでコミュニケーションの機会が圧倒的に増えた。よかった。
特にコロナが落ち着いた年末はオフィスに出社（a.k.a オフ会）して、たまたま居合わせていた人や、家路が同じ方向の人と話をしたりして偶発的な接点が産まれたのもよかった。
折角出社したのに仕事するのもったいないみたいな支離滅裂な思考
あと、リファラル採用で何人かに声をかけたのだけど、そのうちの1人は入社が決まって秋から同じ職場で仕事をしている。彼は高校時代の部活の同級生でずっと接点はあったものの、専攻が情報系ではなかったこともあって、まさか一緒に仕事をする機会が巡ってくるとは思わなかった。なかなか感慨深いものである…。
引っ越した話
夏に都内から千葉へ引っ越した。
理由としてはめっちゃありがちな奴で「仕事はリモート」+「コロナ禍でほぼ在宅」なので都内に住んでいるメリット無奴〜〜〜〜である。その上で仕事とプライベートのメリハリをつけづらいので、居住空間（寝室）と仕事部屋を分けてみたくなったとかもある。
メリハリについては一定の効果はあったと感じる一方で、プライベートでPCを触る機会が格段に減ったので学習の機会・敷居は高くなった気がする。ごろごろしながら、スマホでできる範囲のナニカに留まりがちかも。
ちなみに、立地の利便性は捨て去った。家⇔駅間の移動はバスor自転車だし、徒歩10分圏内にコンビニやスーパーもないので、飲食調達もAmazonやネットスーパー前提という割り切りだ。
そして、その結果がこの運動量である。
まぁ…元々さほど歩いていないものの、夏に引っ越してからはさらに半減したっぽい。
この冬は足先がやけに寒く感じるのだけど、どうも足の筋力（ふくらはぎ）が衰えると血液の循環が悪くなって足先が冷えやすくなるらしい。んなぁ〜
とはいえ、実際に健康診断に引っかかるとか何かしらのwarningくらいでないと、毎日散歩するみたいな周回プレイは実践できない気がする…。
ビールの話
去年に引き続き、軽やかでライトなビールを好んでよく飲んでいた。割と最近だけど、曽爾高原ビールのピルスナーとかケルシュとか、スターライトビールのゴールデンエールもおいしかった。彼らは水だ。（褒め言葉）
my new ふるさと納税’s beer... pic.twitter.com/gRUL6DSMOV
— diescake (@diescake) December 11, 2021
あと、高田馬場ビール食堂で飲んだサワーエールが撃滅的に美味しかった。元々、ランビックみたいな酸味の強いビールは苦手なので、「サワーエール…？うーん、君かぁ…。」くらいの心持ちだったのだけど、全然イメージが変わった。とてもまろやかでジューシー。
最高なビールをたくさん飲んできたんですが、やっぱりみんなお酒に弱くなってて、ウワアア的な葛藤との戦いでした pic.twitter.com/tZxkGF4Y7l
— diescake (@diescake) April 1, 2021
高田馬場ビール食堂で忘年会？でした！
— diescake (@diescake) December 14, 2021
食べ物もビールもおいしくてよいとこ。 pic.twitter.com/K6L24Y5EUg
総括
読み返してみると、仕事関連の話ばっかりでめっちゃ真面目な内容になってしまったけれど、割とそれは真面目に過ごしていたに違いない。うむ。
仕事以外の話もちゃんと書き残しておきたかったのだけど、すでに5000文字に達する勢い＆＆とっくに年が明けているしもう疲れたのでこの辺でpublish！
今の予定だと、来年はそんなに大きな変化はないんじゃないかなーと予測しているけど一体どうなるか！
では！今年も散ッ！！
2020 年の振り返り的な伺か
2年ぶりにブログを書いている。
今年は色々自身の生活に大きな変化があった。 通して気持ちの変化や、考え込むこともあったので吐き出しておこうとしている。
…が、何かしらの記事を書こうとすると、体裁を整えようと躍起になって超大作を作り出してしまうタイプなので、もう書くのに飽きた時点で投稿するぞ！ というか年越しそうだぞ！遅筆だぞ！😌
転職したぞ
開発の話
ちょうど今年の初め 2020/1/1 から新しい職場で働き始めた。早いものでもう 1 年になる。
1-2 月はオンボーディング的に新規プロダクト開発中のチームで力を貯めて、3 月からはウェブアプリケーションのリニューアルを行うチームで主にフロントエンドを担当した。このプロダクトには外部要因による明確なデッドラインがあり、リリース前の1-2ヶ月は熾烈を極めたが結果的には無事にローンチできた。
まだまだ色々と課題はあるものの、フロントエンドエンジニアとしてのアウトプットは出せたはず。ひとまずよかった。
それと、元々の転職の動機の 1 つである「様々な柵に囚われず、ちゃんとユーザに向いた開発をしたい」が無事叶ったのもよかった。 もちろんこれは叶ってからがスタート地点なんだけども。
コミュニケーションの話
コミュニケーションに関しては心疲労が絶えなかったと思う。
前職の会社は新卒で入社してから、あれよあれよと 10 年弱も働いていたので、大抵の社員は顔と名前が一致するし、異動やヘルプ(鎮火作業)を重ねるうちに自然と交友関係("戦友"と書いて"友")も広がっていたことで、いつからかコミュニケーションに要する MP も抑えられてのびのび過ごせていたというのがある。
それに比べるとまだまだ落ち着かないし、正直会社に馴染んでいるという実感はあまりないかもしれない。
今思い返すと、新卒で入社したときは割と相手を知って覚える努力をしていた気がする。
うん、もうちょっと行動せねば…！
日常生活の話
コロナの影響
元々引きこもり体質なので、コロナによる外出自粛で辛いということは特になかった。なんなら直接的な影響にのみ絞れば、リモートワーク中心の生活になって快適になったといえる。元々自宅の開発環境も充実している方(だと思う)で、補助が出ても買い足すものもあまりなかった。
天気の良い晴れの日に家に引きこもって PC 叩いていても、外出しなければならないという強迫観念に囚われることも減った。ただ、運動不足過ぎて早死しそうなので、もう少しちゃんとテニスしたい。あるいは、ロードバイクをオーバーホールして乗りたい。
ちなみに、1 人で過ごしている際の食に対する関心の薄さが極まって、大体いつも BASE BREAD をそのままかじりながら PC に張り付いていた。栄養面はともかく、何か精神的にとても不健康な感じがする…。
BASE BREAD 用に収納家具を配備した。 pic.twitter.com/XmXfAdwBhj
— 聞いてないぜ SORRY diescake IPA (@diescake) December 29, 2020
家にいることが多くなったこともあって、ゆったりな服を着ることが多くなった。T シャツは丈がジャストな M サイズ中心だったが XL でだるだるな服を着ている。スーパー銭湯とか健康ランドにあるような快適な館内着(≠ じんべえ) が欲しくて探してる。
ワークライフバランス
元々、業務時間以外でも予定がなければ趣味で開発(半分くらい仕事)しているような生活スタイルだったのだけど、今年は仕事自体が切羽詰まっていたことに加えて、プライベートでもやりたいことが多くて業務以外の開発・勉強時間が皆無に近かった。(Ruby を少し修練したくらい)
週末ほとんどコミットしてないのがわかる。
その結果、プライベート(主に switch ゲー説)はとても充実していてよかったんだけど、もうちょっと開発関連のインプットに時間振らないと成長感なくてエンジニアとしてやばいな、という漠然とした焦りを感じることが増えた。
ただ、結局インプット増やしたとしてどうなりたいんだっけ？という目的が曖昧なので、モチベーションの源泉として弱いようにも思う。
元々実務に使わない技術習得にはあまり手が伸びないタイプなのだけど、 その辺りは前職だと PoC で興味がある技術をカジュアルに採用できたので、それが新たな技術習得に向いていたのはありそうだ。 (PoC の開発で得た経験なんて表面的なものでしかないのもわかるんだけど)
ビールの話
今年は特に うちゅうブルーイング のビールをよく飲んだ。
my うちゅう beers... pic.twitter.com/CHSZEdNAjz
— 聞いてないぜ SORRY diescake IPA (@diescake) May 15, 2020
うちゅう戦争(発注競争)にもすっかり慣れて、新商品でもなければほぼ確実に購入できるようになった。 自身のツイートを見ると今年は7箱(6瓶/箱)も飲んだようだ。
流石に高頻度で飲みすぎて、うちゅうっぽさの飽きが進行していたところ、ある意味対極な感じもする繊細な味わいの StormBreaker Brewing のビールに感動したりした。
総括
自分でいうのもなんだけども今年は割と頑張ったぞ！
？？？「褒めてやりたいところだァ！」
その上で、色々と実を結んだと思っている。良い1年であった。
ただ、頑張ったことと頑張らなかったことの差が激しいので、もっと良い感じにフットワーク軽くタスクスイッチしてバランスよくできると良いなと思う。
何か別の作業を1 時間するために、5 時間力を貯める必要がある、みたいな立ち振舞ををなくしていきたいが、果たしてそんなことができるのだろうか…。
では！今年も散ッ！
Bonfire Frontend #3 に参加してきました（╹◡╹）
Bonfire Frontend #3 で ヤフーさんの LODGE へお邪魔してきました！
初 LODGE だったのですが、オープンで遊び心が感じられる自由な雰囲気の空間で、それはもうとても素敵なものでした。ずるいぞ。
さて、今回はブログ枠として参加してきましたので、本記事を書いています。発表スライドは connpass にアップロードされるようなので、 自分が特に印象に残っていることと、その所感を述べます。
最初は、見聞きした内容を中心に要約しようと思いましたが、いざ書き始めてみると、スライドのクローンを錬成している感があり方針転換と相成りました。
- Bonfire Frontend #3 パフォーマンス改善
Bonfire Frontend #3 パフォーマンス改善
- 場所: ヤフー株式会社 LODGE
- 日時: 2019/01/24(木) 19:30~
- URL: https://yj-meetup.connpass.com/event/114979/ (connpass)
- ハッシュタグ: #yjbonfire
アーキテクチャリニューアルから、考えるフロントエンドとデータモデリング
- Retty 株式会社: 竹野峻輔
- slide: https://
皆さんご存知 Retty さんの提供されるサービス Retty のリニューアル(リアーキテクチャ)に関するお話。 今回は具体的なベストプラクティスや、Tips といった話よりは、先を見据えた計画や、チームビルディング、心構えといった話が中心であった。
竹野さんはデータエンジニアとしても活躍されている様子。すごい。
プロダクトだけではなく、チーム自身も作り変える
特に印象に残っているのは、中長期的なパフォーマンス改善においては、 単にプロダクトを作り変えるという意識だけではなく、チーム自身も作り変えていく必要があるという話。
今回登壇された方々は表現は違えど共通して、パフォーマンス改善は(プロダクトの)一生続けるべきものであるという話をしていて、 そのために、継続的に改善を続けられるチーム作り(仕組み)が重要であると。
モノリシックからマイクロサービスへ
元々モノリシックに構築されているサービスをマイクロサービス化しているという話では、 モジュール化する上でどこに境界を引くかが設計の争点となるが、 この境界は横断的なチームコミュニケーションによって、必要に応じて各モジュールの責任範囲を改め、柔軟に変更しているという話であった。
これについて、コミュニケーションを綿密にとることが重要だという話に異論はないが、 それでも Retty ほど利用ユーザの多い商用サービスで、インパクトの大きい変更をガシガシ加えることは、それなりにリスクがあるように感じた。
先端を行く B2C サービスではそのくらいのアジリティが求められているということだろうか。 もしくは、production deploy 前の状況であったとか・・・？
チームで技術を選定する
リアーキテクチャにおいて、選定する技術は特定の領域のメンバーが決めるのではなく、 関わるメンバー全体で決定し、個々人が納得感を得ることが重要であるという話。
これには同意見でありながらも、現実では割とトップダウンで自分が選んでしまうことが多く、 仮に形式的であっても、議論する場を設けて決定した方が良いのかも、と反省。
形式的という表現をしたのは、意見を変える気がないという意味ではなく、 フロント経験者が少なく、未経験者や外注さんと組むことが多いため・・・。
また、その具体例として、クライアントとサーバ間の通信において、GraphQL を採用したという話は興味深かった。 確かに、チャレンジングな技術選択でノウハウを持つ人は少ない状況だと思うので、選定に納得していないと辛いフェーズは出てくるように感じた。
一休.com のフロントエンドパフォーマンス改善
今回は、ウェブフロントエンド全体における、マクロな観点におけるパフォーマンス改善の話。ベストプラクティスといった話から昨今の現状や経験談など、幅広く濃い内容で聴き応えがあった。
また、もう少しミクロな観点である、コード改善や Tips といった話については、 前回に話したスライド を参照とのこと。
一休.com と一休コンシェルジュ
パフォーマンスの計測
「推測するな。測定せよ。」とは良くいったもので、十分理解しているつもりではあったが、サイトの形態によって、どのメトリクスが重要視されるかというのは深く考えたことがなく頷くばかりであった。 (ECサイト、メディアサイトであればロード時間、ゲームであればプレイ中の FPS 維持など)
さて、自分の直近の仕事であった B2B サービスではどうかと思考を巡らせてみると、初回読み込み時間は重要でユーザ体験に直結はするが、離脱する種のサービスではないので、頻繁に利用する機能のパフォーマンス改善がよりよいユーザ体験に結びつくだろうか。
ただ、これらの改善は求められているわけではないのが現状で、逆に重要だという提案をするにしても、それと利益との相関関係を証明することは難しく、現実的には厳しいところだろう。うーむ。
計測ツール
ツールは多様であるが、Chrome DevTools (audit) を始めとして、そのバックエンドとしては Lighthouse が利用されていることが多いらしい。各人ローカルで DevTools を利用すると環境による影響が出るため、クラウドサービスを利用した方が良いとのこと。
恐らく、サービスであれば CI とも連携しやすく、定常的にパフォーマンスを計測することができるため、導入しない理由はないように感じる。想定外のパフォーマンスデグレードにも早い段階で対応ができそう。
PageSpeed Insight
- とっつきやすい
- 下り 1.40Mbps 環境で測定される
- お昼時の、格安 SIM (4G回線)がこのくらい
WebPageTest
- とっつきにくいが多機能、上級者向け
- locaton(region) の変更、繰り返し測定など
余談だが、サイトを探す際に googlability が低く勿体無いと思った。
Lighthouse のスコアと指標
- Lighthouse のスコアは他社サイトとの比較に便利
- EC サイトは目標 50〜
- メディアサイトは目標 70〜
- 自社サービスのチューニングの際は指標を見るべき
- スコアは算出方法が変わることがある
- 主要導線である複数ページを対象とする
この辺りも肌感が全く無かったため、実際運用されているサービスの体感速度とそれに対応するスコア感の話は非常に参考になった。
パフォーマンスの最適化戦略
かなり省いているので詳細はスライド参照。
遅い要素を減らしていくのが基本方針。
一休.com / 一休コンシェルジュ、共に画像リソースが非常に多いため、この最適化による影響が大きいという話であった。 ツールとしては imgix を利用して画像自体のサイズを削減すると同時に、ファーストビューに入らない画像は lazy load とする。
メディアサイトは Fastly のキャッシュ戦略が特に有効であるが、EC サイトは性質上長くキャッシュをもたせることができないデータも多いため、(価格、ユーザ情報など)メディアサイトに比べると TTFB が落ちるのは一般的。
全く関係ないが、"Above the Fold" という表現を初めて知った。ファーストビューと同じ？意味合いではあるが、かっこいいとおもいました。(小並感)
JAMSTACK と SEO
JAMSTACK というキーワードは初めて聞いたのだが内容としては馴染み深いもので、ざっくりといえば、ウェブアプリは SSR しないプリビルドされた SPA を利用する方式で、これは静的データであることから CDN で効果的にキャッシュできるという話である。(た、たぶん)
ただし、当然 SEO については色々と検討が必要になり、現在は Google bot 対策として、dynamic rendering で Rendertron を実験中とのこと。
この辺の用語もわからず調べたのだが、dynamic rendering とは、サーバサイドで Google bot からのリクエストの場合にのみ、事前にレンダリング済みの専用の HTML をレスポンスに返すという方式らしい。
当然この HTML は本来のウェブアプリ(SPA)と同等の内容が期待され、あからさまに異なる HTML を用意している場合はクローキングとして扱われてペナルティを受けることがあるそうだ。
個人的には、Google 側が「あからさまに異なる」という判定をどう行っているのか気になった。Chrome 41 相当の Google bot とは異なる一般ユーザと区別がつかない bot が存在してクローリングしているのだろうか。
その他所感
パフォーマンス改善にガチに取り組む姿勢に驚いた。パフォーマンス改善を目的としてサービスの構成から作り変える可能性も含めて検証し、積極的に production に取り込んでいくという意思を感じた。
私自身は B2B サービスの請負い開発が多いためか、銘打ってパフォーマンスが重要視されることはほぼなく、姿勢の違いに衝撃を受けた。
恐らく、B2C サービス(特に ECサイト)の世界では、パフォーマンス改善が利益に直結する世界であるため、こういった姿勢に差が生まれるような気がした。
実際に、一休.com 開いて、これだけ画像が多いのに確かにはえー、と盛り上がったりした。
パフォーマンス改善の具体例とサービスへの売上貢献
- ヤフー株式会社: 笹原翼
- slide: https://
自社サービスであるヤフーショッピングに対して、なぜパフォーマンスチューニングを行い、どう取り組み、どう成果がでたか、その一連の流れを丁寧にかつ、面白く話をしていただいた。また、参加者がすぐに実務に適用できるような Tips やチェックシートまでもが整理されていて、即効性が高く非常に参考になった。
パフォーマンスチューニングに取り組んだ結果としては CVR が 110% 向上したそうだ。
パフォーマンス改善のリソースを確保する
明確な回収見込みが提示できないとリソースを割くことが難しいという話。よくあるジレンマだと思っているが、ヤフーさん程の体力があっても変わらないというのは意外であった。
A/B テストによって、ページの初回ロード時間と CVR、各種指標への相関を示すことで、実際に偉い人を説得し、リソースを確保したそうだ。確かに、これ以上ない仕事の運び方だと思う。
ファーストビューの9割表示を指標とした
これが興味深かった。
先の一休.com さんの例でいうと Lighthouse の何かしらの指標を目標としておいていた(と記憶している)が、ヤフーさんの場合はエンドユーザ視点で、9割表示されれば体験を阻害せずサービスとして十分機能している状態であるという判断したのだろう。
私の社内の話だが、ページを読み込んだ後に、投機的にリンクの先読みを行う仕組みがあり、計測結果としては先読み完了後までの時間が得られてしまい実際の体験に即していないという悩みがあった(らしい)
その点でも、ファーストビューの表示率という観点は良いもののように思えた。
計測ツールは SpeedCurve を利用
- 強豪と比較がしやすい
- 継続的に確認してグラフ化する
- 有償だけど比較的手頃
- キャプチャを目視でグラフを見やすく加工している
ヤフーショッピングの場合は明確な競合があり、リアルタイムに競合と指標を比較し続けることができるという機能はとてもマッチしていたように感じた。
ただ、それ程高価ではないとはいえ、有償ツールで維持コストがかかるため、継続的に結果を出していかないと稟議の説明が苦しくなるのかな、とか思った。(弊社視点)
レスポンスの圧縮形式を gzip -> brotli へ変更
あくまで、紹介されていた施策のうちの1つでありこれ単体で大きな効果があったわけではなかったようだが、そもそも brotli という圧縮形式を知らなかった。ググってみたところ、Google の開発した近代的な圧縮フォーマットで、gzip に比べて2割くらい軽くなる傾向にあるという。Encode/Decode にかかる時間は若干増加するという情報もあるが、込みでスループットが向上することは多いようだ。
私が聞いたことすらなかったため、ブラウザが対応しているものなのかと疑問に思ったのだが、全てのブラウザは余裕で対応していた。(IE からは目を背けながら)
https://caniuse.com/#search=brotli
リクエストヘッダの Accept-Encoding では 'br' が追加されるようだ。
その他所感
CVR の計測について気になるのだが、サービス自体、目まぐるしく変わるであろうコンテンツと、加えて、運用としての様々な試みや、機能追加も色々とあるはずだが、パフォーマンスチューニングのみの成果を測定するというのはできるものなのだろうか。
チューニング期間全体の上がり幅を見るのではなくて、個々の施策の成果を合計値で見るとか？
あと、スライドのクオリティがとても高かった。こういったデザイン的にも内容的にも洗練されたスライドってどうやって作っているんだろう。エンジニアソロで完結しているように思えないのでとても気になる。
全体の所感
非常に勉強になった。
いずれも初回読み込み速度の短縮を指標として置いていたが、このチューニングを考えると、WebFrontend というよりは、もっと広くサービス全体の構成を抑えた上で、技術スタックやその特性を1つ1つ丁寧に理解していないと、適切な考察や改善策を打ち出すことが難しく、広く深い知識が求められるように感じた。
道中にも少し書いたが、私自身は B2B 向けの請負ウェブアプリの開発が多く、仕事として既存サービスに対するパフォーマンスチューニングが求められる機会というのは少ない現状ではあるが、新たにゼロベースでサービスの設計から入る機会は多いため、これらのナレッジを生かしていきたい。
「はじめてのペアプロ / モブプロ」を読んだメモ
去年の反省の1つであるが、一般的なパラレルに開発して上がってきた PR をコードレビューしてマージするという開発スタイルにあらゆる意味で限界を感じていて、ペアプロ、あるいはモブプロを取り入れるべく検討していた。
早速 Discord で頼れる有識者達に相談してみたところ、WEB+DB PRESS の特集を紹介いただき読んでみた。関係者間で要点をシェアするためのメモとして本記事を書いている。実際に実施して適宜加筆していきたい。
- WEB+DB PRESS Vol.102 (2018/1月号)
- はじめてのペアプロ / モブプロ
ペアプロ
効果的なタイミング
- 新メンバーがジョインしたとき
- キャッチアップする最速の方法
- 新機能を実装するとき
- デバッグや不具合修正を行うとき
- 複数の観点によってデグレ防止に有効
- 定期開催
- Daily / Weekly
- Daily なら 1h, Weekly なら 3h とか
- Daily / Weekly
- 技術的負債の返済日
進め方
1. コードを書く前に方向づけを行う
- 最終目標を決める
- 作業項目をリストにする
- 開発中も都度更新していく
- [x] 新規画面の追加
- [ ] データ取得 API の呼び出しと表示
- [ ] CSS を書いてデザインを実装
- [ ] リファクタリング
- [ ] 動作検証
- 最初の目標を決める
- リスト化して作業を開始
- 小さい作業項目から着手して流れを作るのがよい
2. コードを書きながら会話し、考えを共有する
- ドライバー
- 考えていることを口に出す
- 実況のように、よく喋ることが重要
- 思考をそのまま口にする
- ナビゲーター
- よく聞き、ドライバーを支える
- 実況に対してコメント、評価、盛り上げる
- 同時にコードレビュー
- 立ち止まって設計の共有
- 視野を広く持つことが大事
3. ロールを交代する
ドライバーの方が消耗が激しいため、ローテーションするのが基本
- 時間で交代する
- 15分くらいの交代が目安
- ステップで交代する
- Pair Programming Ping Pong Pattern
- 作業項目単位での交代
- 適宜自由に交代する
- ある程度慣れた人向け
注意点・コツ
- ドライバーの正面にキーボードを置く
- 定期的に休憩を取る
- ロール交代の際に適宜取ると良い
- 開発環境差異の問題
- メンタル的にペアプロが合わない人もいる
- 強要してペアプロハラスメントに陥らないこと
- ただし、単に食わず嫌いの人は多い
モブプロ
ペアプロでは、ペア以外のチームメンバーへ情報が伝達されにくいという問題がある。例えば、チケットや PR に試行内容とその結果、コードレビューのやり取り等が残らない。よし、ならば全員同席だ。 ➔ モブプロ
- 3〜5人が適正
- できる限り大画面を用意する
- 調べ物用の PC がもう1台あると良い
- ナビゲーターそれぞれが課題を調査する
正直なところ、ペアプロほどメリットがスッと頭に入ってこなかったが、とりあえずやってみて考える。
【2018 - 2019年】総括と抱負のような伺か
あけましておめでとうございます（╹◡╹）
今年もよろしくお願いします。(◜◡◝)
年末 Twitter の TL を眺めていると、技術的強者の方々がこぞって 2018年の総括をブログにアップしていたので、ワイも振り返りたいんじゃあ〜、と思いたち、ほぼ衝動でブログ開設にまで至った。
彼らのような目覚ましいアウトプットや輝かしい社外活動はないけども、それでも、自分にとって2018年は大きな転換期となったため、振り返ってく。
主な仕事の振り返り
2018/1〜2月
前年より引き続き、前部署で Chromium 製ブラウザの TV 向け拡張の開発と移植サポートを行っていた。主な言語は C++14 で、ビルドシステムは Ninja だが、Chromium において Ninja ファイルは generate されるものなので、エンジニアが向き合うのは専らメタビルドシステムである GYP/GN であった。(現在 Chromium は GN に統合)
この辺りの技術スタックは Chromium くらいでしか利用されていないため情報が少なく、ちょっとした嵌まりどころが致命傷でリリース遅延に繋がったり、リリース優先筋力回避によって即座に技術的負債化、暗黙知化したりと、本質的ではないリスクやコストが大きく、非常に厳しい開発環境だとつくづく感じた。
また、ネットに情報が少ない技術というのは習得しにくいだけではなく、一般的に需要が少ない(ピンポイントで刺さる場合はあるが)という意味でもあり、自身のキャリアを考えるとあまり習得にモチベーションが上がらず。
そんな頃、逃避エネルギー駆動で即興で書いたプログラムがウケたので記事にしたものが以下でございます。
うん、逃避エネルギーの有効活用は重要だな…。
2018/3〜5月
急遽別チームのヘルプで iOS アプリの機能開発を担当することとなった。Swift のバージョンはいくつかなー？、3.x 以降だったら速習しないとなーふふふ、などと思っていたところ、Objective-C であり、これはこれで結局1冊本を読んで速習するところから入ることとなった。
今思えば最初から Objective-C と言われていたら断っていたかもしれないが、結果的には久々の純然たるチーム開発で、iOS 開発も楽しく、そこからスムーズな異動に繋がったので、打診に対して迷いなく YES と答えたあのときの俺、偉いぞ。
総括としては、落ち着いた頃にこんな記事書いた。 qiita.com
また、逃避モチベにより登壇を決めた「Manabiya Teratail Developer Days」 の Web 枠で LT もした。
完全にネタ枠であったが、何回か笑いを取れたので目標は達成できた。
2018/6〜10月
先のブラウザチームから、種々請負開発がメインとなる部署へ異動。
私自身の担当はウェブフロントエンドの分野で、(とはいえ、必要に応じて色々手広くやるけども…)
早速とあるウェブサービスをフルスクラッチで開発するプロジェクトにジョイン。
今まで、自社ブラウザの上で動く特殊な用途のウェブアプリや、iOS/Android のハイブリッドアプリ向けウェブアプリの開発経験はあったが、もっとベーシックなウェブサービス(特に PoC ではない)という意味でのウェブアプリ開発経験はなかったため、その技術選定からローンチまで経験できたのはとても嬉しく、大きな経験値となった。
また、実際には諸事情で Lambda をメインで書くことになり、ウェブアプリはレビュワーとしての関わりが大半になってしまったが、これらのレビューはたぶん自分で書くよりも大変で、これはこれでチームビルディングに関する学びと多くの反省を得た。
下記は、相当数のレビューを行った知見から一部抽出して書いた記事。 qiita.com
他にもまだまだたくさんメモはあるけど、まとめられていない。
2018/11〜12月
続いて、別のウェブアプリ開発の案件へ。
自分の立ち位置としては PL よりで自身では直接コードは書かず、未経験者や新卒の教育とサポートが主な目的として参画。
フルスクラッチの開発ではあるものの比較的シンプルな要件で、かつ POC なので、正常系中心にある程度安定していれば問題ない・・・そう考えていた時期が私にもありました。
POC に対する品質の認識は関係者間でバラバラなので(特にディレクターと開発)、この認識をすり合わせておかないと、作業量感が合わなくなるの結構重要。(POC に限った話ではないかもしれないが)
それと「POC なのでこの画面の UI デザインはないよ！よくある無難な感じに作ってね！ლ(╹◡╹ლ)」という、恐らく見積り上のコストカットポイントがあったのですが、
皆が思う以上に「UI に興味がないエンジニア」は多く、ブナンッテナンダ？ウマイノカ？となりがちなことと、通常デザイナーが行う要件を UI に落とし込むための詳細化工程が1枚抜けていることによる手戻りもあり、とことん POC という甘美な罠に嵌った気がした。
UI に関しては PR でちょろっと指摘して対応できるものではないので、自ら Adobe XD で Bulma ベースのコンポーネントを想定した簡単なレイアウト・デザインを作ることになった。
おかしい…、こんなはずでは。
今年やりたいこと
さて、2018年の仕事は大まかにこんな感じであったが、やり残したことも多い。(エンジニアリング以外でも・・)
弊社フロアを VR 化して、仮想出勤するとか、社内 Slack にジョークボット作ったりとか、Nokia Sleep を利用した自動遅刻通知もサーバサイドは GAS に変更しよう、という状態のまま未完成で記事も下書きのまま。
Nightmare.js で書かれたテニスコートクローラーを Puppeteer で書き直したいし、REST API として切り出したのに、アプリ化もできていない。PWA にしたかった。
夏場に CSS 鍛錬のため、無作為に選んだ有名サイトのトップページの目コピをやろうとしたが、結局できていない。
技術の裾野を広げるために Hello World streak やってみるの凄い良さそうと、思いたったがこれも行動できてない。
ポチった技術書も無事積読済みだし、英語にもちゃんと向き合わないといけない。
…と、無限にやりたいことはあるわけだけど、先立つものは時間・・！！
勤務時間を減らす
今年はこれを一番大事にしたい。
2018年は、自分の仕事と身につけたい技術が合致したので、仕事と趣味の境界なく無制限に働いてしまったが、たぶん今見えてる感じ2019年はそんなことはなく、仕事の経験を通して学べることの密度はかなり薄くなると思われる。
同時に、へーしゃの報酬体系も変わるので、同じ時間働いたとしても結構な金額をロスすることになるので、逆に良いチャンスだと捉えて、引き受ける仕事を最小限に抑えて、極端に残業時間を減らしてみようと思う。
年末にちょっとトライした感じ、最大のポイントは仕事の進捗が遅れていようが構わず時間になったので帰る、ということみたいだ。
あとちょっとキリの良いところまでやる・・。は大体ダメな結果になった。
技術書を読む
先に書いたが現場で学べることが少なくなっている、ならどうしようかという話であるが、積読されている技術書を読んで体系的に学べという話である。(あるいは転職か・・)
技術トレンドや、商用実例、ノウハウ的なことを学んだりモチベーション維持には勉強会も良いのだが、それよりもレベルの高い人と話をしていると、自分が雰囲気でやっていて、基礎力が足りていないと感じることが多かったのも理由の1つである。
点と点を結んで線にして面を増やしていきたい。
ウェブサービスを作る
これよこれ。
やっぱり、フロントエンドエンジニアだもの。
ウェブサービスを作って、そして運営してなんぼよね。
ネタは色々あって、去年もあれこれ考えてたけど実現できてなかった。
まとめ
というわけで、最後の方雑になってしまったが、Qiita に技術記事を投稿するときとは違って、個人ブログは流入量は少ないしわざわざマサカリも飛んでこないと思うので幾分気が楽である。
このブログを書くこと自体は目標に挙げていないけれど、自分の思考を整理して吐き出したり、勉強会のメモ書きを投稿したりとか、必要に応じて便利なツールとして扱っていければと思う。
