2025年の展望について
今年というか日々の心構え的なこと
少し前に読んでいたブログでこんなことが書かれていました。
自分はプロダクトオーナーでもなく、マネージャーというポジションでもないので、議論の場で意見を出すことは出来ても、最終決定権はない。いち担当者としてのベストは尽くしているつもりだし、自身の担当領域を限定しないで、やれることは全部やるくらいの高いモチベーションで接してもいる。 〜中略 当事者意識が強すぎると、ストレスの蓄積スピードが自分のコントール範囲を超えてしまうので、適度に「役割に徹する」ことが必要だなと感じている。 https://bump.hatenablog.com/entry/2024/11/14/090115
ブログ書いてる方と立場、環境は違えど、当事者意識が強すぎることによって感じるストレスっていう意味ではすごく共感できるなぁと思っています。
実際このブログを読んで以降、日々の仕事のスタンスみたいなものを自分なりに調整してみたことでストレスを感じることが減ったように思っています。
なので今年というか日々の心構え的なこと
- フリーランスだけど当事者意識は持つ
- 適度に自分の役割に徹する。
- 自分ならこうするのになぁという考えは持ちつつも、出しゃばらない
という形で過ごそうと思っています
小さい目標
2025年を通した1年の目標みたいなものは考えない＆また数値的な目標も設定しないのですごく消極的だけど、何もかかげないよりはましかなと思うので書いておくことにします
- 自分の振り返りのためにブログを書く
- 仕事で関わってる周辺の技術について深堀りして学ぶ
- 読書のジャンルの幅を少し広げる
それぞれ少し掘り下げていきます
自分の振り返りのためにブログを書く
実は昨年のGWに急に体調悪くなってそれがきっかけで、毎日体調について1行日記のようなものを付けています。
日記を書く時にその日の起床時の気分を4段階で記録を取ってるので、こんな↓感じで気分の変化も把握できるようにしています
やっぱりこういう記録があって、適度に振り返ることで 「あーこの時はxxがあったからこういう感じだった」 とか 「この頃から◯◯を意識して習慣にしたから安定してるのかな」 という気付きも得やすいかなと思っています。
1行日記での体験も踏まえて自分の振り返りのためにブログを書いていこうと思っています
仕事で関わってる周辺の技術について深堀りして学ぶ
仕事で久しぶりにVueに振れる機会が出てきたことがきっかけで少し深堀りして理解したいなぁと思っていたら、以下のような素敵な情報に行き着きました
Minimum Exampleの章は写経しつつ読み終えたので、Basic編の章を学ぶ予定でいました。
ただ途中のテンプレートコンパイラの所の内容を読んでる時に 抽象構文木（AST）について触れる箇所がありました。
以前からこの言葉を見た時のアレルギーみたいなものがあってテンプレートコンパイラ以降の内容は正直消化不良気味で読み終えた感じでした。
この消化不良気味の理解をどうにかしたいという気持ちになっていたタイミングでたまたま以下の本に出会って昨年からコツコツ勉強しています
自分の理解度が足りないこともあって、適宜ChatGPTに概念説明をしてもらいながら読んでることもあって、まだ1/3 しか読み進めてないのですがおかげさまで、字句解析（Lexer）とか抽象構文木（AST）という言葉が出ても全く怖くなくなりました 😁
小さいながらも成功体験を得ることが出来たので、今年も仕事で関わってる周辺の技術について深堀りして学んでいこうと思っています。
読書のジャンルの幅を少し広げる
以前書いたブログで小説、数学、歴史に関する本を読むようになったと書きました
歴史の本がきっかけで
- 歴史→食に関する歴史に興味を持つようになった
- 食に関する歴史→特定の地域や国の食について興味を持つようになった
- 特定の地域や国に興味を持ってそこを深堀りしたくなった
- 「テヘランのすてきな女」がきっかけで、自分がしらない地域のことに関心を持てるようになった
- 元々食に関しては興味があるので、エッセイ的なものも含めて広く読みたい
こんな感じで読む本のジャンルを増やすことが出来たので今年もこれを継続していこうと思っています！
50歳を超えて改めて自分のキャリアを考える
はじめに
ここ数年の自分の経歴を振り返りつつ、50歳を超えて改めて自分のキャリアを考えてみたいなぁと思います
45歳〜50歳くらいまでやっていたことを振り返る
| 項目 | 内容 |
|---|---|
| 関わっていた業界 | ・飲食系サービス（モバイルオーダー。BtoC） ・交通系サービス（デジタル乗車券。BtoBtoC） ・オンライン診療（小児科。BtoC） |
| チーム規模 | ・基本的に7〜10名前後（2チーム） ・1年弱だけど0→1のサービスやったのでそれは基本1人 |
| 仕事の進め方など | ・基本的にはおおまかな企画の方向性を共有してもらったうえで、仕様調整しながら機能開発 ・後述する技術要素を満遍なく使った開発。（特にバックエンド/フロントエンドだけという開発はほぼなし） ・時折非機能面に関する開発とかも行う（パフォーマンス面。GraphQLのfield定義の見直し〜移行とか） |
| 関わっていたバックエンドよりの開発 | ・ほぼRuby/Rails ・Firebase ・GraphQL。変わった所ではHasura（PostgreSQLだけを準備すればGraphQLなAPI＋αを提供できるSaaS） |
| 関わっていたフロントエンドよりの開発 | ・React/Next/React Native/TypeScript ・Vue/TypeScript ・Flutter |
おおよその経歴としては
- だいたい1年
- 長いものは4年半
という感じでこれまで通り複数案件を並列で関わっていました。
振り返るとその時点ではすこし安定して色々と情報が入手しやすいものをずっと使った開発のお手伝いをしてきています
50歳を超えてキャリアの考え方変わった？
これまでと変わらない部分が大半だけど、少し変わった所も出てきたのでまとめます
- 変わらない
- 仕事のスタンスは変わず。
相手の人/会社にとって都合よく使ってもらえるような普通のWeb系エンジニアとして生きていくのが自分なりの戦略かなと思ってます
- 仕事のスタンスは変わず。
- 変わった
- 仕事の量
- 病気発覚の少し前から業務量減らしてた（2023年は毎月120〜140時間稼働。今年は2024年は120時間前後）
- 収入源
- 以前は分散させていたけど今後はそこはこだわらない。（上記のような稼働時間考えると複数案件こなすのは現実的に不可）
- 仕事の量
何かきっかけがあったか
特にこれといった明確なきっかけがあったわけではないですが
- 子育てに関連して色々な出来事があったけど、それも考える事がだいぶ減ってきた
- 数年前に母親が突然亡くなる＆相続も無事終えた
というような出来事（局面）が50歳前後にありました。
そんな状況で年齢的に区切りとなる50歳を意識した時に、何となく今後の生き方みたいなものも考えるようになっていました。
結局どうするか？
フリーランスとして活動してることもあり、余計に定年という概念はないもののビジネス系の雑誌とかで出てくるライスワークとライフワークを意識したいなぁと思っています。
ライスワーク＝ご飯を食べるための活動
https://diamond.jp/articles/-/189534
ライフワーク＝夢や自分の好きなことを追い求める活動、です。
ライスワーク
今はWeb系の開発のお手伝いを100％にしています。
ただ知り合いが数年前からDevRelな仕事をしてる＆元々自分は前職Web系を専門としたキャリアカウンセラーをやっていたこともあり、少しそっちの要素/役割を増やしたいなぁとぼんやり考えています。
ライフワーク
具体的なライフワークが何かっていうのは得にはないですがここ最近意識してるのは視野/世界を広げる事だけは意識しています
- 仕事では普段関わるライブラリの内部を深く知りたくなった
- 仕事でRailsのCarrierWaveを利用する時にダイレクトにS3でコピーをする処理を書いた時にCarrierWaveの内部実装を頑張って読んだ
- ChatGPTのおかげでこういうコードリーディングがやりやすくなってるのを実感してる
- 仕事以外では以前は全く読まなかったジャンルの本を読むようになった
少しまとまりにかけてますが、最近はこんな事を考えて日々過ごしています
甲状腺のガンが見つかって今年の1月に人生初の手術＆入院をしていました
再開最初の一発目が重たい内容ですみません。。。
書こうとおもった理由
フリーランスとして、Webアプリケーション開発に関することに関わっているのですが、仕事内容的に、一緒にする人たちが自分よりも一回り（下手すると2回り）下の人と一緒に仕事をする事が圧倒的に多くなってきました
そのため、一緒に働く30代、40代の人が、今後直面するかもしれない出来事について少しでも参考になることを書いておければと思ったので書くことにしました
発見までの経緯
コレステロール値が高いので数年前から定期的に病院に通っているのですが、先生から
「血管の詰まりとかを調べるために頸動脈エコーをしましょう」
と提案を受けて2023年10月下旬に検査
エコー検査→その後に専門病院を紹介される
検査結果をした時に
「血管自体は問題なし。ただそれとは別にちょっと気になる箇所があるので一度大きな病院で見てもらったほうが良いかも」
となり、紹介状を出してもらって甲状腺疾患専門の病院に行きました
検査結果、ガンが発覚。
不幸中の幸い
- 冒頭で書いたように自覚症状があったわけではなく、普段通ってる病院でたまた進められた検査の延長線で偶然発見
- 専門の病院での検査結果を受けて入院＆手術が必要となる。
- ただ見てもらっていた病院だと最短で2024年の4月末頃になると言われてとりあえずそのまま手続きを進めようと思った
- ただこの日の午後にたまたま大学病院から来る先生が来るので一旦相談してみましょうとなる。
- しばらく待ってから改めてその先生に診てもらい、結果2024年の2月頃に手術出来そうのことで目処がつく
- 後日、改めて大学病院に来院。
- 当初予定していた方の枠が空く
- 2024年の2月という予定がさらに前倒しになり1月末で手術予定日確定
という感じでいくつか不幸中の幸いとなる出来事が積み重なりました
手術前の心境
甲状腺を全部摘出するので
- 術後にどの位で体力が復活するのかとか
- 今後ずっと薬を飲み続けることになるのか
などもちろん多少の不安があったのは嘘偽り亡く事実でした。
ただ病院での入院準備の時に何か不安なことがありますかと聞かれてその時にも担当の方にも話したけど
｢なるようにしかならない｣
というのが正直な心境でした。
何となく達観してたのは自分の特性
話が前後しますが、たまたま縁があって自分のキャリアを振り返るきっかけにしたかったこともあり少し前にコーチングを受けていました。
その一貫で特性アセスメントを受けたのですが、自分は情緒安定性（時々の感情に左右されず、不快なことも冷静に受け止める特性）の項目が比較的高かったので何となく達観して感じだったのかなぁと思っています。
なので、自分でコントロール出来ない事についてはあれこれ考えず、手術の日まで淡々と過ごそうという心境でした
入院前の準備
こんな感じのチェックリスト作って準備
これとは別にToDoで入院前にやることを書き出してましたが、これは完全に職業病ですね😅
そして今年の1月に手術
当初は当日お昼すぎ位と言われていたけど、実際は夕方5時に開始。
以前メモっていたことを時系列で振り返ります
手術前
よく医療系のドラマで見るような手術室のイメージとは全く違って想像していたよりもすごく綺麗でめちゃくちゃ広い！
（印象としては都心のオフィスビルに入居してるコンビニ位でした）
あと、手術するスタッフの人達がなんか雑談してて普段と変わらないスタンスだったのが逆に気が紛れて、結果、特に緊張することもなかったかなぁというのが心境でした。
手術を終えて
入院前にレクチャー受けていたんだけど
- 全身麻酔から回復する時に徐々に意識が戻る
- 自分が話をする
- 話が出来るということは意識が戻ってるという状況なのでそれを確認してスタッフの方が管を抜く
という流れだったけど、その当たりの記憶がまったくない。。
手術を終えて部屋に戻ったのが9時前後だったはずなのですが、気づいたら手術室から横たわったままどこかに移動中
結構揺れる感じがあって車酔いみたいな感じがしてそれでだいぶ意識がはっきりした気がする
手術後～2日後くらい
思っていたよりも辛かったです。
何が辛かったかというと
- 首の下を切ってるので術後は一定時間うごけない（寝返りも不可）
- 術後〜6時間の間は1時間おきに血圧とか諸々チェックするので正直寝れない
- おしっこも管を通して行う
特におしっこが今でも思い出すと一番辛い思い出。
肝心の術後のひまつぶしは役に立った？
これも振り返ります。
- 本
- 小説。最近ハマってる反社とかを扱うようなテーマのやつで前から読みたかった本が中古で安く買えた
- 雑誌のNumber
- 事前に購入しておいた電子楽器のエレフエ
- あらかじめダウンロードしておいた動画
- Radiko
・・という感じでそれなりに準備してました。
でも結局は
という感じに落ち着きました。
せっかく購入した電子楽器が活躍しなかった理由
元々、手術前に説明を受けていたのですが、術後は一時的に低カルシウム血症の症状が出て、頻繁に手足がしびれる症状が出ていました
別にこれ自体は深刻な状態ではなかったけど何となくエレフエ使って演奏しようという気分になれなかったので結局活躍せず。。
入院中の食事について
術後しばらくして、ほぼお水のようなおかゆ→おかゆ→ご飯という感じで日常に近い食事に戻っていくのは地味に嬉しかった！
低脂肪＆毎日1500カロリー程度に抑えられていたけど、しっかりタンパク質は取れて味付けも普段の自分が食べる食事と大差なかったので食生活のストレスはほぼ感じなかった。
このときの食事を受けて退院後の食生活も見直した
加えて、低脂肪の食事を続けてて体調が良かったのもあったこともあり、退院後の食事もこれを機会に見直しました。
これまでずっとおやつにデニッシュ系のパンを食べていたのですが、代わりに和菓子を食べるようになり
入院中大事だと思ったこと
自分の場合は、低カルシウム血症の症状を除くと予定通り回復して行動の制限も少なかったこともあり割と持て余す感じでした
- 普段の生活でも環境音代わりに使ってるテレビを付ける
- なんとなくテレビを見つつ、お笑い動画を見る
- 飽きたら小説を読む
- 無理ない範囲で、持参したチューブトレーニングの機器で足の筋肉だけ鍛える
という感じで、普段の日常となるべく同じリズムで過ごしたほうが精神的に落ち着いたという結論に至りました。
最後に
人生初の手術＆入院。
どうなることかと思ったけどこういう↓感じの予定表をもらっていたので自分の体調の回復次第でどういうタイミングで食事内容、行動制限が解除されていくのか展望が見えるのはありがたかった。
ずっと更新してなかったブログ再開します
途中からWebサービスを多言語対応した苦労話
はじめに
世の中の多言語対応してるWebサービスは
- パターン１：ここ最近のインバウンドのニーズを踏まえて最近立ち上げた
- なのでサービスローンチして1,2年程度
- パターン２：最初に日本語版を始めていた。サービス継続してく中で、多言語対応の親和性がありそうで横展開を狙い、結果、対応言語が増えた
という形なのかなと推測してます。
自分が関わっているお店の予約代行をするようなサービスで、上記の自分の分類でいうと、パターン２になります。
どういう形で対応したのか大まかに書くと
- 日本語版を開始
- その後、英語版を追加
- 英語版をベースに外部の機械翻訳のサービス（ググるととすぐに出てくる割と著名なやつ）を使って中国語版対応
- 機械翻訳の文章は違和感あり翻訳データーを環理できる管理機能を作った上で、多言語対応（日本語、英語、中国語の3言語）
という形でちょっとづつ多言語対応してきてます。
自分は、上記の３の頃から開発に関わってますが、当初から多言語対応をするという前提ではないため
- Webアプリケーション含めてサービス全体の設計として当初のターゲットユーザーの言語設定がベースにになってる
- ある意味後付で多言語対応なので、システム含めてトータルで色々考えないといけない
という形で、色々苦労しているので、そこでの学びとして以下の2つについて簡単にまとめようと思います。
- 多言語対応に伴い電話番号の仕様再検討
- 全ての機能について多言語対応を最初から全部行うとは限らない
多言語対応に伴い電話番号の仕様再検討
サービス利用する申請フォームでユーザーさんに電話番号を入力いただくようになってます。
※ 予約代行というようなサービスの特性上、こちらからユーザーさんに連絡を取りたい状況が発生するために、入力いただいてます。
当初は日本人だけだったので、仕様はシンプルだった
日本人を当初ターゲットにしていた時は、そんなに深く考えることなく
- 携帯電話
- 固定電話
のいづれかを入力してもらうだけでOKでした。
多言語対応すると考慮ポイントが増える
ここからが今回のテーマに関連する話題なのですが、多言語対応によって、電話番号についての仕様が途端に難しくなりました。
具体的には
- 日本人以外のユーザーさんの場合、申込時に入力いただく必要があるのは 日本に滞在中に連絡がとれる連絡先 である必要があります。
- 相手の電話番号がわかっても その人がどこの国の人 か判別できないと、こちらから連絡取れないため、国番号を入力いただく
というあたりです。
国番号が必要になる理由
Softbankのサイトから関連する情報をちょっと引用します
日本から海外事業者の携帯電話・一般電話へ電話をかけた場合は、「国際電話」の扱いになります。 Softbankのサポートページより
自国で所有してる携帯電話を滞在先の日本でも利用するケースがほとんどだと思うのですが、そういう人に対して、こちらから連絡を取る時には
国番号＋携帯電話の番号
で発信しないと、電話がつながらないため、画面上では、セレクトボックスで出身国を選択していただき、実際の値は、出身国に紐づく国番号が登録されるようにすることでこの問題を解決しました。
全ての機能について多言語対応を最初から全部行うとは限らない
冒頭のパターン２のケースの場合についていうと、最初から全部を多言語対応するのは現実的に難しいと思います。
理由としては開発に関わるエンジニアのリソースが足りないのもあるのですが、全ての取引先が多言語対応の業務ができる体制になってない or その体制作るのに凄く時間かかるということも考慮しないといけないためそのあたりが大きな要因になります。
最初は限定して、その後に増やすというアプローチになるかと思い実際、自分のケースでも
- Webサービス側の翻訳が全部対応しきれない
- お店の予約代行という特性上、お店側の事情で対応出来ない
というようなことがあり、ちょっとすつ多言語対応していくという形になりました。
ちょっとづつ多言語対応は意外とやっかい
システム開発の観点で
- toC向け
- 管理機能
- 多言語対応のための管理機能はどこまで作り込まれてないといけないのか？
- 英語の情報をベースに中国語に翻訳していく業務フローだったので、中国語版で、部分的に英語の情報が混じっていても許容できる仕様にしてよいか
- 多言語対応のための管理機能はどこまで作り込まれてないといけないのか？
というような点について、どういう仕様なら現実的なのかを考慮しないといけませんでした。
実際の業務を考慮しつつ、プロトタイプとなる機能を作る→試してもらう→問題点ありそうなら改修→再度チェック・・・という繰り返しをしながら対応していきました。
事前には想像出来なかった追加仕様も出た
3言語の対応をできるように開発を進めていたのですが、取引先は3言語全て使うものだと思いこんでいたのですが、取引先によっては
「折角なのでこれを機会に、xx の言語だけにしたい」 「出来れば、xxと○○の2言語だけにしたい」
など地味に細かい要望が出てきました。
今となってはそのあたりの背景は理解できるのですが、作ってる当初は当然ながらそんなことは想像出来ず、当初作っていた処理を見直すことになりました。
その追加仕様に対応できる構造にしていおいたことで、柔軟な運用ができるようになったので、結果的に良かったのかなぁと思います。
どうしても非効率なことが出るのは仕方ない
上記アプローチだと翻訳する人はシステム開発が終わるまで何も出来なくなります。
そのため並行して翻訳対象データーをGoogleスプレッドシートに登録＆翻訳データー作る作業をしていたのですが
- 翻訳データは、実際のDBの構造を反映した形になってなかった
- そのため、機能開発終わったら、１つづつデーターをコピペする形になった
という感じで、今思うともう少し効率的なやり方があったのかなと思います。
最後に
企画段階では他の要望（例：言語ごとにページのレイアウトを変更したい等）があったのですが、社内・社外の各種事情を考慮しながら、実現可能なものから多言語対応着手するのを考えるのは、今振り返っても難しい問題だなと改めて思います。
1on1コーチング体験をしてきました。
思考と現場の間でのid:tsuyokさんのファンで、いつか機会があれば、中の人にお会いしたいなぁーと思っていました。
少し前に「1on1コーチング体験」参加者募集という記事を書かれていたので、申込んで先月にお会いしたので、どんなことをしてきたのか振り返りつつまとめようと思います。
- 何故1on1コーチング体験を申込んだのか？
- 当日の流れ
- 実は凄くモヤモヤするきっかけがあった
- 1on1した時の違い
- 別の会社で日本人の方に1on1してもらった時のことも振り返ってみた
- 1on1コーチング体験を通じて得られた「 1on1 って何なのか？」という自分なりの気付き
- この気付きを自分なりにどう活かすか？
何故1on1コーチング体験を申込んだのか？
私自身は、1on1 を受ける立場なのですが「そもそも 1on1 って何なのか？」ということについて凄くモヤモヤしたものを感じていました。
専門的に対応されてる方がどのように考えてるのかヒントをもらえればと思い申し込んで見ました。
当日の流れ
- アイスブレイク的に雑談
- 雑談後に、今回申し込んだきっかけなどから入り、徐々に革新の話題について、問いかけをもらう
- 自分が話す→問いかけしてもらう→そこについて考えつつ話す・・・繰り返し
- クロージング
という感じで約1時間ほどでしたがかなり濃密な時間を過ごせました。
余談ですが前職のキャリアカウンセラー時代にこういう1対1の対応を毎日のようにしていたのですが、自分の経験上1時間が限界＆体内時計でなんとなく時間がわかるので今回久しぶりにすごく集中したなぁと終わってから気づきました。
話を戻すと徐々に革新の話題について問いかけをもらう中で実は凄くモヤモヤするきっかけがあったことに気付かされたのでその辺りからちょっとづつ振り返ろうと思います
実は凄くモヤモヤするきっかけがあった
- Aさん：つい最近（2,3ヶ月前に）経験した1on1
- 責任者が外国の方（フランス系）で英語は話せるけど日本語は全く出来ない
- Bさん：凄く昔（10年以上前の派遣先の外資系の企業）に経験した1on1
- 当時のマネージャーがオーストラリア出身の方で日本語は全くできない。（ネイティブの方が半分冗談で、その人の英語がたまにわからないとイジっていた）
自分自身は、技術的な話だけに限定すれば、ある程度口頭で説明できる程度の英語スキルであるのに対して、対応してもらった人の属性が
- ともに外国籍の人で文化/習慣など自分とは全く異なる
- 日本語が話せない
という感じで基本的には同じような状況だったにもかかわらず、前者の人との1on1は、淡々と話が進み特に何も印象に残ることがありませんでした。
一方で、後者の方は、未だに彼の1on1はとても良かったという印象が強く残ってます。
後者については凄く昔のことなので、美化されてるというのは一定の割合であるとは思います。
ただそういうのを考慮しても1on1を受ける側にとって印象に残るケース/そうでないケースの要因としてどのようなものがあるのかなと話しながら気付かされました。
1on1した時の違い
ここから、更にいくつか問いかけしてもらったのですが振り返ってみると
- Aさん
- 淡々と話しが進んでいった
- 何となく面接（悪い言い方だと尋問っぽい）形で話が進む
- Bさん
- こちらの拙い英語でもしっかり聞こうとする姿勢が強く感じられる
- 困ってることがあれば、遠慮なく言ってくれれば助けてくれるというスタンスを常に出してくれていた
- 関係する人が多そうで、かつ、実際に会ったことがない人も含まれそうな社内的に込み入った面倒な出来事があったけどBさんに相談したら、その場で関係する人に電話して一発で解決してくれた
という感じで、対応する時の姿勢とか心構えが根本的に違うことに気付かされました。
別の会社で日本人の方に1on1してもらった時のことも振り返ってみた
別の会社でも日本人の方に1on1 をしてもらった経験が何度かあるのですが、あらかじめ決めておいた質問事項に沿って対応してくという雰囲気だったことも有り、その時も 1on1が終わってから特に何も自分で感じることはありませんでした。
1on1コーチング体験を通じて得られた「 1on1 って何なのか？」という自分なりの気付き
- 対応してもらう人が話す内容自体は大きく変わらない
- 前述のBさんの場合も正直どんなことを当時話していたのかは全く覚えてない
- ただ1on1をしてる時の姿勢とか心構え含めた 空気感 みたいなものが大きく異なる
- これが決定的に異なっていそう。
- 1on1終わって、印象に残ってるのは、自分なりの気付きだったり次に向かって頑張ろうというというモチベートされた状態で終わっていた気がする
というようなものが気がします。
この気付きを自分なりにどう活かすか？
フリーランスという自分の立場上、1on1を受けることはあっても、自分で1on1をする機会は基本的には作れません。
ただ、最近は、就活相談の対応ができるMatcherというサービスでキャリアカウンセリングのようなことを不定期に行ってるのでそういう対応をする時に今回の学びとか気づきを活用していこうと改めて思いました。
テストがほとんどなかった状況からチーム全体でテスト書く習慣が身につくまでの課程を振り返る
はじめに
先日小〜中規模のWebサービスを数年運用して学んだことをまとめていきます。と書いたので、まずはテストに関する話題を今回まとめようと思います。
この記事の全体像
最近はチーム全体でテスト書く習慣が完全に身についてるのですが、そこに至るまでの過程を振り返ると色々あったことに気づいたので以下まとめていきます。
なお、過去3年を振り返ってみて、以下の3つに分類できそうなので、この区分で以下整理して書いていきます。
- 初期
- 2016年5月〜
- 中期
- 2017年6月〜
- 最近
- 2018年10月頃から
初期
お仕事関わった当初、そのサービスのテストの充実度についていうと
- ちょっとだけrequestスペック書かれていた。
- 基本的にテストを書くという習慣がない
- CI環境も当然ながら無し
という感じでした。
また、この頃の初期の自分のテストに関するスキルについて言うと
- 別の案件でRails/RSpecという組み合わせで、request/controller/model specは一通り書いていた
- ただ、別の人が書いたものを見よう見まねで書いてるレベルだったので、ふんわりとした理解で書いていた。
という感じでした。
初期の問題踏まえて取り組んだこと
- 自分自身のテストに関するスキルが正直大したことがない状況だった
- ただその状態で、今後新しい機能の開発をしたり、不具合対応をするのが不安だった
- （きっかけは覚えてないのですが）この時期からPRのレビューをしっかりする習慣が出てきたことで、コードの改善について、当時の開発メンバー全員が割と意識を持つようになった
というようなことが重なり、現場の責任者の方に提案してちょっとづつ改善してきました。
具体的には
- GitHubにテスト改善的なラベルを作る
- そこで、当面の目的・目標を書く
- 既存仕様がよくわからない所が多いので、コードの現在の振る舞いを確認する 仕様化テスト を頑張って書く
ということをしていました。
初期の限界
仕様化テストでちょっとだけ安心を得たけど、それほど大きな改善につながってる感じがしてませんでした。
というのも
- その処理のControllerに色々な処理が入り混じってる
- テストを実行しづらい構造になってる
という状況だったので、この複雑な処理の全体像がざっくり見えてきても、根本的な所は何も解決しないので、その処理の見直しを考えるというIssueを作って、さらなる改善をしようと考えました。
ところが、そのタイミングで売上を伸ばすための企画よりの仕事をちょっと頼まれてそこからしばらくの間、改善系の作業に着手できなくなった 😥 ことで、そのままこの初期が終わったという感じです。
中期
企画よりの仕事が一区切りついた2017年の6月頃に新しい機能開発の話がでました。
この頃のGitHubのIssueを見てると
- 新規開発する処理はRailsEngineの仕組みを使って開発する前提だったので可能な限りcontroller/model specは書く
- なぜRailsEngineだったかは別に書きます
- CircleCI+NightwatchでUI自動化テストするプロトタイプ作る
- エンジニア経験が浅い人（しかも外国の方）がチームに加わったので、既存実装理解をしてもらいつつ、これまでカバーしてない処理のテストを書き溜める
という感じで作業を進めてました。
なぜCircleCI+NightwatchのUI自動化テスト？
初期（2016年5月〜）には、CIとかUI自動化テストという発想が全く持てない位に、各種リソース（人＆時間）余裕がなかった気がします。
ただ中期の時は時間的な余裕が多少あったことに加え
- 個人的には、この仕事に関わる前に一時期クローラーを作る仕事をたくさんしていたので、Nightwatchみたいなものを使うのは得意だった
- 新しい機能開発で毎回手動テストは辛いのは明白だった
- UIを刷新する上に PC/スマホ ｘ ユーザー属性 ｘ 申込み方法 という組み合わで考えると20パターン以上あった。
ということを踏まえて、CircleCI+NightwatchのUI自動化テストを整備しました。
※ 完全な余談ですが、クローラーを作ることに比べると、自分たちでマークアップしたHTMLは当然ながらスクレイピングしやすい構造だったので作業しやすかった 👍
中期の限界
- 単純にテストコードの数は増えていったのですが、ビジネス的に重要な処理について、テストコードの充実度はまだまだ改善の余地がある
- CircleCI+NightwatchのUI自動化テストとかが出来たのは嬉しい反面、だんだん CircleCIの実行時間が長くなっていった
というような課題が出てきました。
最近
2018年10月頃から一定期間だったのですが、とても頼りになるエンジニアが2名チームに加わりました。
最近の成果その１
その人達が本来やるべき開発の合間に
- CircleCIの処理の見直し等
- FactoryGirl (Bot)のcreate/ build / build_stubbed を正しく使い分ける
- その他細々としたもの
という改善をやってくれたおかげで、現在は
- RSpecの方は600弱のテストケース（CircleCIの並列実行の仕組みを利用）
- UI自動化テストのほうは350個程度のテストケース
がCircleCIでそこまでストレスを感じない時間で実行されるようになりました 💪
最近の成果その２
こちらは、テストだけにとどまらない話なのですがapp配下のディレクトリ単位でREADME.mdを作って、それぞれの処理の大まかな設計方針を言語化しておくようにしました。
※ 外国の方がチームにちょっとづつ増えていく傾向にあるので、出来る限り英語化もしてる
設計方針を書いてる処理についてはすでにいくつかのパターンでテストも書かれてるため、
- Ruby/Railsにそこまで精通してない人に対して
- ある程度お手本となる実装サンプルがある
- 経験豊富な人
- 過去の経緯を説明しつつ、現状の設計方針でより良い方法があればそれを前提に設計考えなおして、実装＆テストも改善しやすい
という効果が得られてます。
最後に
テストがほとんどなかった3年前の状況から今に至るまでを振り返ってみました。
振り返りついでに、もしも今の自分が３年前にアドバイスするとしたらおそらく以下のようなことを話すかなと思うので最後に触れておこうと思います。
- ほとんどテストコードが無い状況でCapybara使ってrequestスペック書くのは割と良かった。
- 当時、一番ヤバいなぁと思っていた所から着手していた。
- t-wadaさんの組織にテストを書く文化を根付かせる戦略と戦術（2019夏版）でちょうどそんなことが書いてある
- 当時は選択肢としてNightwatchで良かったけど、その後の情報はキャッチアップしたほうが良い
- ある程度、テストを書く＆PRのレビューの習慣が身についてきたら、レビュー目的は言語化しておくのがベター
