その先へ

setohの色々殴り書き

2月振り返り

ハロー、 @seto_hi です。または@setoh です。

育休もあっという間に1ヶ月が過ぎて2月も終わりなので(と言いつつこの記事を書き始めたのは2/20)、今月を振り返ろうと思います。

やったこと

寝た

今日も僕は元気です。
この数年XiaomiのSmart Bandで睡眠データを取っているんですが、今月だけ睡眠の内容が大きく変わってレム睡眠が大幅に増えていました。今まではレム睡眠が増えると頭のスッキリ感が増す傾向にあったんですが、今月はあまり体感できていないです。不規則な睡眠で体感できていないだけかも。

Mi FitnessがGoogle Fit連携したということで昨日Smart Band 7から8に買い換えたので、来月末にどうなるか見てみようと思います。

スクリーンタイム制限

時間の有効活用をしようと思い、スマホ2台(iOSAndroid)にスクリーンタイム制限(AndroidだとDigital wellbeingのアプリタイマー)を設定しています。
両OSで結構違いがあって面白いです。

iOSは制限を1分単位で設定でき、時間をオーバーした際に制限を無視してアプリを使うかが選択できます。Androidは制限が5分単位で、時間をオーバーしたら制限を消さない限りはそのアプリを当日中は使えないです(wellbeingという割に厳しい...)。

iOSの方が休日とかのイレギュラーな場合に臨機応変に対応できるし、制限を厳しめに設定しておいて精神的なハードルにできるので好きです。
Androidは残り時間が1分になると通知が出てアプリがモノトーンになるのでわかりやすいです。iOSは制限を無視して1分使えるので精神的に若干悪いことをした気持ちになりますが、Androidは制限時間内で最後の1分で収めるぞという気持ちになるので、この点はAndroidの方が好きです。両OSがいい感じにmergeされるともっといい感じになってくれるなぁと思っています。

結果として、2月の最初の週よりも1日で1/3くらいスクリーンタイムが減ったので今のところはかなり効果はありそうです。ダラダラとスマホをを見ず、調べごとはPCでやるという意識が出てきました。
しかしそのうち慣れてきたら制限を無視しまくりそうな気はしています。

確定申告

色々と初めてのことがあったので大変でした(と書きつつほとんど終わっただけでまだ完全には終わっていない)。

インボイス対応も大変だし、副業する余裕もないので今年で個人事業主を廃業すると思います。

読んだ本

移動時間や元気なタイミングではできるだけ読書するようにしてます。

フロントエンドの知識地図

フロントエンドの開発について薄く広く書かれていて、あまり詳しくなかった点へのとっかかりを作れて良かったです。1年くらい前のフロントエンド始めたときに読みたかった本。

余談ですが、著者のひとりが高校時代の部活の先輩で驚きました。内容で買った本ですがそんなことあるんですね。

フロンエンド開発セキュリティ入門

セキュリティ系は実務だけではなかなか体系的に身につかないので、この本で学べて良かったです。セキュリティの懸念事項を全部に完璧に対応するというのは難しいので、プロダクトの特性によって手厚くする点を考えるというのを再認識できました。
時間がなくてハンズオンはできていないので後日やるぞ...

入門朱子学と陽明学

有名な「論語と算盤」を読んだときに論語の知識が薄くてしっくり来なかったので、論語とか近いあたりの知識を身につけようと思って読んだ本。宗教なので抽象的かつ体得的な知識が前提の話が多くて、朱子学陽明学も知らない人からすると1回で理解するのはかなり難しかったです。読み返したらもうちょっと理解できるかもしれない。

現代論理学入門

現代論理学というタイトルだが1960年代の本。この本も1回で理解するのはかなり難しい。けど多分しっかり内容を理解できれば形式手法の理解もしやすくなりそうな気がするのでもう一度読み直したい。
結構記号論の内容も多かったんですが、記号論への招待 は数年前に読みかけ途中で放置してしまったことを思い出したので、こちらも読み直したい。

批判理論入門

自分は小説をあまり読まないんですが、楽しみ方をあまりわかっていないので読まない部分もあるので、理論として学んでみようと思って読みました。
批評には本当に色んな切り口があることは面白かったですが、結局は一周して普通に読んでみようと思いました。趣味では他の人の批評は気にしない方が幸せですし。
続編として小説読解入門もあるので読んでみたいと思います。

 

今月はちゃんとブログ書けました。来月もちゃんと書けるといいですね。

以上!

ここ1年くらいの振り返り

ハロー、@seto_hi です。

2月からしばらく育休を取得するので(と1/31に記事を書き始めたのですが2月の半ばになってしまった)、いい機会として転職してフロントエンドエンジニアに転向してからの1年ちょっとを振り返ります。

どうだったのか

率直に言うと、なかなか思い通りにいっていないです。

2023年の4月の段階でEMと「2024年の4月くらいにtech leadになれるくらい成長を(やや高めの目標として)目指しましょう」と言っていたんですが、全然そんなレベルでないという感じです。しばらくお休みするので、2026年4月くらいが現実的な目標じゃないかなと。想定の3倍くらいの時間がかかりそうです。
評価してもらってる点もありますが、それはさておき自分では全然納得いく実力ではないという感じです。

1年以上やってきたので、普通の難易度のコードを普通に実装するのは普通にできます。しかしまだまだ基礎が欠けている点があり、経験も足りておらず、自分が面接官をした時にフロントエンドエンジニアとして採用するレベルではないなぁという感じです。

現状フロントエンドエンジニアとしては実力不足で、Androidエンジニアとしては知識が1.5年遅れくらいという何者でもない感じになりました。しばらくは転職を考える状況ではないので、良くない現状を堂々と書けます。いいですね。

原因分析っぽいもの

1年前の想定と乖離した原因を考えると、想定よりも覚えることが倍あって、自分の覚えるペースが想定の2/3だったみたいなイメージです。

フロントエンドはReactとTypeScriptを使おうが結局のところHTMLとJavaScriptなどの基礎の知識がなければ高品質なコードは書けないと感じており、そこの学習コストは想定よりもだいぶ高かったです。
その他にも、実際にフロントエンドやってみないと学習すべきだとわからなかった分野が多々あり、とにかく学ぶことが多くて時間が足らないという状態です。

特によくなかったところ

一番大きな反省は、今年の途中から目標に対してビハインドしていることへの焦りからか、簡単に成果が出ることを多めにやってしまった点です。とにかく手を動かさないと身につかないものもあるのでそれはそれで良かった部分もありますが、tech leadレベルの知識を身につけるというゴールへ必須なアクションではなかったと思います。
せっかく挑戦させてもらっているので、ダメ元で難しい問題に取り組むチャレンジしたりしても良かったかなと。あとせっかく素晴らしい実力を持つ同僚に恵まれているのに、あまり生かせずに勿体なかったとも思っています。

そのあたりから「なんでフロントエンドをやることにしたのか」とかも忘れてコーティングに力を入れすぎていた気もします。大局を見て行動するのは苦手ではなかったはずですが、ちょっと視野が狭くなっていました。もっと大きい成果を狙っていかないといけないですね。

あと所属しているプロジェクトはバックエンドがKotlinなんですが、全くKotlinを書くことなく1年以上過ぎました。入社時点では社内でもかなりKotlinの経験が長い方だったので、もっと生かせば良かったという反省があります。

やらないと忘れる

あとはやっていないことを忘れまくっているなと感じました。

プロジェクトで出てきた課題が過去に経験した課題と似ており、できるだろうと高をくくっていたら、やり方を忘れており手も足も出ないということがありました。
技術的なことでもそうでなくても、やらないと錆び付くし忘れてしまうなと(そして実際に着手しないと忘れていることに気づけない)。

そんな感じでAndroidもかなり忘れています。副業でやりたかったんですが、人生は時間の取り合いなので難しい。
酒を飲む量と頻度がかなり減ったので日本酒の知識もかなり忘れました。

忘れるのはまだ年齢のせいではないと思っているので、色んな分野を勉強しつつリハビリしていきます。

とはいえ悪いことばかりではない

自分の実力には納得いかないと思いつつも、現時点で足りていない部分と今後学ぶべきものはかなりしっかりと見えています。
フロントエンドの学習の方向性は間違っていないとEMからも言われており、時間はかかるかもしれませんが着実にレベルアップしていこうと思います。

フロントエンドでもテスト関連についてはチームに貢献できており、以前よりも解像度が高く掘り下げることができました。
会社のブログに書いた「テストから知識を深める」「テストから知識を広げる」というのは意図したとおりに実践できていると思います。

tech.bm-sms.co.jp

方向性が間違ってなくて気力はあるので、そのうち結果も出るでしょう。
人生という大局で見たら、新しいことの学習が想定通りにいかないのもいい経験ですね。

さいごに

こんな感じで今日も僕は元気です。

育休中は会社のslackからログアウトしているので、生存報告として月1回くらいブログを書きたいと思っていますが、果たしてどうなるか。そろそろ書き始めないと来月に間に合わない。

以上!

自分探し2023

ハロー、@seto_hi です。

ライフワークとして自分探しの旅をしていますが、今年も自分探しをしたのでその記録です。

seto-hi.hatenablog.com

これは去年見かけたワインの箱です。いつかは飲んでみたいですね。

1月

数年ぶりにサンライズのチケットを取りました。

記念写真を撮りまくろうと思っていましたが、運休しました。自分探し失敗です。

4月

自分探しといっていいか怪しいですが、秋田の玉川温泉の近くにあるプレイパーク戸瀬に行こうとしました。
盛岡側から八幡平を越えて行こうとしたのですが、4月中旬にもかかわらず積雪で通行止めでした。

今年は自分探し受難な年です。

5月

しまなみ海道に行きました。
サイクリストの聖地と呼ばれていますが、瀬戸が付く地名が多くて瀬戸の聖地でもあります。

尾道駅には大衆食堂せとがあります。

特に瀬戸内の大三島には瀬戸という地名があり、瀬戸にとってはたまらない土地になっています。
大三島にはブルワリーもワイナリーもあり、お酒好きにとってもたまらない土地だと思います。
自分はお酒好きの瀬戸なのでものすごくたまらない土地でした。

舞いましょう。

瀬戸というバス停があるので行きました。
まわりに何もないバス停に2年連続で行ったのですが、今年はちゃんと瀬戸酒造のTシャツを着ていきました。

時刻表がないと思ったらなんと廃止になっていました。しばらくしたらバス停も撤去されてしまうと思うので最後に訪問できて良かったです。

名所もあります。

押寿司もありました。

12月

鎌倉に瀬戸小路というワッフル屋がありました。鳩サブレーでおなじみの豊島屋さんのお店です。おいしかったです。

ちなみに店名はの由来は昔に鎌倉にあった瀬戸という地名だそうです。

いかがでしたか?

自分のGoogle Mapにはまだまだ自分探し候補がメモしてあるので来年も自分探しを続けていきます。

自分探しによっていつもの旅行がちょっとだけ楽しみが増えますね。

以上!

Testing pyramidとTesting trophy

ハロー、@seto_hi です。

この記事は株式会社エス・エム・エス Advent Calendar 2023の1日目の記事です。

qiita.com

自分は1年前からフロントエンドエンジニアとして働いており、最近はプロダクト開発と並行して、フロントエンド開発のテスト関連の方針を考えています。

テストのバランスについて考えた

Unit testやIntegration testなどの各種テストのバランスについて、Testing pyramidとTesting trophyという有名な考え方があります。一見するとこの2つの考えは相反しているように感じ、どちらに従うべきか迷いました。
調べていくうちに自分なりに納得のいく結論が出たため、そのことについて書きます。

Testing pyramid

自分がTesting pyramidを知ったのはAndroid開発をしていたときで、テストの基礎というドキュメントで言及されていました。

developer.android.com

元々はMike Cohnが著書 Succeeding with Agileの中で書いたコンセプトのようです。

実行時間が短く保守が簡単なテストを多くし、実行時間が長くて保守が大変なテストを少なくし、テストのバランスをピラミッドのようにしようという考えです。

Testing trophy

フロントエンド界隈では有名な考え方で、恐らく以下のブログ記事が一番見られているのではないかと思います。

kentcdodds.com

生産性を高めるために、複数のユニットを結合したテストを多く書こうという考えです。
(Unit testよりも速度に優れたStaticが追加されていることも特徴的ですが、この記事では触れません)

Testing pyramidとTesting trophyは相反する考えなのか

Androidの「テストの基礎」ではTesting pyramidに沿うためにIntegration testよりもUnit testを多くするように書かれ(UI test 10%, Integration test 20%, Unit test 70%)と書かれています。
一方、Testing trophyではUnit testよりもIntegration Testを多く書くするように書かれています。

このことからTesting pyramidとTesting trophyは相反する考えのように感じましたが、背景にはテストの分類の違いがあるということに気付きました。

そもそもUnit testとIntegration testとは

下記の記事に書かれているようにUnit test とIntegration testという用語は使う人によって定義が異なる曖昧になっており、混乱の原因はそこにありました。

Testing pyramidでは依存オブジェクトのあるsociable testと依存オブジェクトのないsolitary testをUnit testと呼び、Testing trophyではsolitary testのみをUnit testと呼び、sociable testはIntegration testと呼んでいるようです。

何がUnit test/Integration testであるかという前提が異なっていれば、テストのバランスが異なるのも納得ができます。

martinfowler.com

また、SWETチームの下記の記事には「テストスコープで分類するとトロフィーになるものが、テストサイズで分類するとピラミッドになる」というt_wadaさんのコメントが書かれており、リンクされていたスライドと合わせて自分には腑に落ちました。

swet.dena.com

結論

これらの記事を読み、自分の考えはTesting pyramidとTesting trophyはテスト分類の考えは異なるが、テストのバランスについて相反する考えではないという結論になりました。

また、solitary testとsociable testというより細かい分類を意識することでTesting pyramidとTesting trophyの両方を満たすこともでき、より良いテストバランスにすることもできると思っています。

おまけ

文中に貼った記事で何回か言及されていたポストにも触れておきます。

最も重視すべきことはプロダクト開発に有用なテストを書くということで、テストの分類や割合はあくまで補助的な指標であることを忘れてはいけません。

自分もTesting pyramidとTesting trophyなどのテストバランスはひとつの指標として参考にしつつ、開発中のプロダクトに有用なテストについて考えを深めていきたいと思います。

最後に

明日のAdvent Calendarは @k12u が記事を書きます!

また、株式会社エス・エム・エスではソフトウェアエンジニアを募集しています。

自分と一緒にフロントエンドの開発をしたり、スケールするフロントエンドのテストの方針を考えませんか?
採用情報はこちら

株式会社エス・エム・エスに入社しました

ハロー、@seto_hi です。

半月という短い無職生活を終え、12/1から株式会社エス・エム・エスで働いています。
介護系のサービスのフロントエンド開発チームで働いています。

なぜエス・エム・エスを受けたのか

今回の転職の軸として、何か新しい経験ができることを重視していました。
Android開発を業務で10年以上やっていることは自分のかなりの強みだと思っていますが、それ以上にAndroid開発以外を全然やったことがないというのは最近の自分の性格的に目指す方向と違うなと思っていたのが理由です。

転職を考え始めたタイミングで @soranakk と話したときに誘われたんですが、多分バックエンドの枠ということで、どうせカジュアル面談で「バックエンド未経験ですね〜」からの「今回はミスマッチですね!」で終わりになるだろうなと思い数ヶ月放置していました。
別の機会で @soranakk と話していたら「経験ない分野でもAndroidの経験を見てくれるので大丈夫だと思う!UI系詳しそうだしフロントエンドでいけるんじゃない?知らんけど」と言われたので半信半疑*1*2でカジュアル面談を受けてみました。

面談の中でもフロントエンド未経験であることが理由で落とされないかをしつこく聞いた気がしますが、全然大丈夫と言ってもらえたので選考を受けました。実際内定ももらえました。

面接の時にはコーディング試験はありませんでしたが、Android開発とかその他の経験の話をかなり深掘りで聞かれたので、真面目に色々な仕事していてよかったと思いました。

転職の決め手

何社か内定をいただき非常に悩んだのですが、やはりフロントエンドエンジニアに100%振り切れるというのが最大の決め手でした。Androidと平行してやるとどうしてもキャッチアップが遅れたり、自分の中で「専任じゃないからここは一旦理解しなくていい(そして永遠に理解する機会がない)」みたいな甘えが生まれてしまいそうだなとか。

オファー面談のときに自分の重視している点を色々と率直に話したのですが、しっかりと受け止めてもらえた点も大きかったです。

ビジネスとして福祉介護系に興味があるかと言われれば正直そこまで強い思いはないです。しかしながらカジュアル面談で日本の介護の将来の話を聞いたときに、思っていたより近い将来で人手不足などの問題が発生しそうだと知り、この事業に関わらないで後悔したくないなと感じました。この点も決め手の一つです。

フロントエンドチームについて

どんなチームかとか実際フロントエンドのコード書けてるの?みたいな話は別途記事にしようと思います。書き出してみたらなかなかのボリュームになってしまったので。

今後の目標

チームとしてはまだまだ人が足りておらず、来年度もどんどん人を増やす予定があります。
フロントエンドエンジニア経験者の採用もなかなか難しく、フロントエンド開発に興味があるAndroidエンジニアを採用して、一緒にコンバートしていこうぜ!という採用アプローチを考えています。
そのために自分が人柱になってAndroidエンジニア→フロントエンドエンジニアになるための高速道路を考え、少しずつドキュメント化している最中です。すごいボリュームになりそうですが、遠くないうちに一部でも公開できたらと思っています。

やるぞ!

以上!

*1:@soranakk とは新卒時代から10年以上の深い付き合いがあり、仕事ではそれなりにしっかりしているみたいですがプライベートは色々テキトーで振り回されているので

*2:冗談です、知らんけど

株式会社ノハナを退職しました(3年5ヶ月ぶり2度目)

ハロー、無職です。@seto_hi です。

今回は1年7ヶ月半、通算で5年9ヶ月半働いたノハナを2022/11/15で退職しました。

退職理由

長く働いていれば色々ありますが、一番の理由はもっと成長したいという気持ちかなと思います。
同じ会社でも成長し続けることはできますが、今の自分の課題感だと違う環境で経験を積んだ方が良いと感じたので、今回は手っ取り早く環境を変えて成長強制ギプスを装着するような感じです。

ノハナでやったこと

Android 5割、データ系4割、その他1割くらいの割合で仕事していた気がします。

Android

少ない人数で効率的にできるように色々やりました。
テストを書きやすい設計に変えたり、スクリーンショット画像のVisual Regression Testを入れたり、フォトブックの組版画像もVRTできるようにしたり、QAチームと協力して(というかほとんどQAチームの力で)回帰テストが毎日回るようにしたりしました。
おかげで放置されまくってたライブラリのアップデートもゴリゴリ進めることができて、モダンなAndroidアプリ開発への追従もできたと思います。
Jetpack Compose導入はペアプロで勉強しながら進めつつ、最後の最後で設計方針の決定までできたので良かったかなと。Compose導入のためにHilt化してMulti module化する方が大変でした。

データ分析基盤の整備

基本的なデータが自動更新されて、KPIやKGIの進捗がいつでも最新で見れる状態になり、データのソースの一元化もできたので、データの民主化として最低限はできたかなと思います。
初めての経験だったので改善点は色々ありますが、果たして今後のキャリアで生きることはあるのだろうか。

価格改定時の試算

業務でデータ分析も少しだけしていたので白羽の矢が飛んできたのですが、当然試算の経験はないし粗利営業利益って何それ状態からのスタートでした。
締め切りが決まった中でまずは何をやったらいいかを洗い出して計画を立て、色々勉強しつつ過去と現在の分析をしまくって社運が懸かる試算を出すというのはなかなかタフな試合でした。
試算結果はいい線いっていた部分もあれば分析が甘かった部分もあって、振り返りしながらめちゃくちゃ冷や汗をかきました。会社潰れなくて良かったです。
在籍中で一番勉強になったしいい経験が積めたと思っています。

改めて振り返るとよく働いたような気もするし全然働いていないような気もします。

よかったこととか

自分がユーザーのアプリを作ることは楽しいという原点に戻ることができたのは良かったなと思います。
第一次ノハナ期はそんなにフォトブック作ったりしなかったんですが、復職後はほぼ毎月フォトブックを作るようになりました。その中での不満をアプリ改善に繋げることができて、新卒の頃に感じていたtoCアプリを作るワクワク感を少し思い出すことができました。
色々な所を高速化したので使う上でのストレスは少し減ったように感じます。

自分の守備範囲を決めずに幅広いタスクをやったのも良かったかなと思います。
エンジニアリングに限らず、人が足りないタスクを拾って経験を積んだのは今後強みになってくると思ってます。それでもまだ幅が足りないと思うので広げていきたいですね。

あとは自社商品を使ってプロポーズしたのは貴重な体験でした。
ノハナのプレミアムフォトブックは人生の大事な場面にも使える素敵な商品です。プロポーズも成功しました。これは宣伝であり個人の感想です。
(その中で印刷後の画質あんま良くないなと思って自分でコードを修正したのは中々シュールな体験でしたが。)

nohana.jp

次の職場

ずっと無職でいたいところですが、悲しいことに12/1から会社員に戻ります。
次の職場では12年くらいやってきたAndroid開発を完全に捨ててフロントエンドエンジニアになります。
りあクト!を読んで完全に理解したような気持ちになっているので早く何もわからなくなりたいですね。
詳細はまた後日。

以上!

「チームで育てるAndroidアプリ設計」を読んだ

ハロー、@seto_hi です。

「チームで育てるAndroidアプリ設計」を読んだので感想です。
この気にはPR記事です。*1


アフィリンクも置いておきます。みなさんもう買ったと思いますが。
https://peaks.cc/BBA7C06D/architecture_with_team

 はじめに

 筆者の釘宮さんも横幕さんも仕事で接点がありネット上でもよく絡んでいるので、この本の発売はとても楽しみにしていました。

釘宮さんは自分がDMMに入社するきっかけになった人で、釘宮さんがどんな風に仕事をしてどんなことを考えているかを知りたくてずっと観察していました。この本を読めば入社しなくてもその一部がわかるのはちょっとずるいなと思っています。この本はお得です。

横幕さんはmixi在籍時にノハナのAndroidアプリをゼロから作った人なので、自分の1回目のノハナ入社時にはモダンなAndroidアプリの勉強として非常に参考にさせていただきました。(だいぶKotlin化したのですが、まだ横幕さんのコード残ってます)

本の内容

釘宮さんの章

釘宮さんがDMMでやっていたことの一部が具体的な情報付きで文章化された、という印象です。新規事業や横断的な仕事をやる前にはこの本を読んでおきたいです。いやなんで自分が横断的な仕事をする前にこの本がなかったのか、もっと早く書いて欲しかった。*2

アーキテクチャの話を通して、チーム全体で決めると良いことが書かれてあり、チームで輪読会をするとチームのレベルが数段上がりそうだなと感じました。というかチーム全員が読まないと効果が薄くなりそうです。

2~4章はTech Leadなどのポジションの人が考えること・意識して行動することが文章化されていて身に染みる内容です。
メンバーレベルの人でもTech Leadなどの考えることを知れて視座が上がると思いますし、実装のアンチパターンなども載っているので得るものがある内容なのかなと思います。

横幕さんの章

横幕さんが大規模なアプリ開発で得た知見を知ることができ、自分の想像を超えた世界とそれに技術や仕組みで対抗する内容でとても勉強になりました。

5~7章は雑に流し読みしてしまうとアプリエンジニアが多い会社以外には関係のないように見える内容かもしれませんが、将来的な増員を考えるとどの会社にも当てはまる話かなと思います。書籍内で書かれているような仕組みを知った状態と知らない状態ではドキュメントの充実度なども大きく変わってくるのではないかと思います。

 実装については自分の能力不足で正直1度読んだだけでは理解にまで落とし込めませんでした。穴が空くくらいまで読み込んでいきたいと思います。

 さいごに

この本の全体の内容を見返すと、チーム全員で輪読会をして、それを元にチームをより良い状態に持っていくのに使える本だと感じました。チームで育てる本ですし。
知見がありすぎて1度読むだけでは脳から溢れてしまうくらいの密度なので、GW中に繰り返し読んで情報を得られるだけ得ていこうと思っています。

以上!

*1:献本いただけるって言われたんですがその前に普通に自腹で買ってたので断りました

*2:冗談です