Yuki Watanabe's Blog

Yuki Watanabe's Blog

エンジニアリングと子育てについて

日立の洗濯乾燥機ビッグドラムの乾燥時間が長くなったらやること

日立の洗濯乾燥機「BG-100GL」を購入して5年が経つ。乾燥機能付きの洗濯機は素晴らしい時短道具である。 一方で、メンテナンスを怠ると機能不全に陥り、中でも頻発するのが「乾燥時間の長期化」だ。

一時は業者を呼んでいたが、ある程度自分でこなすことができる事がわかった。非定期のメンテナンスは年に1度程度しかやらないため、次に作業する際に忘れてしまわぬよう記録しておく。

日々の掃除

まず、日々のメンテナンスは欠かさず行っていることが前提となる。 具体的には、乾燥フィルターと糸くずフィルターのクリーニングは、表示ランプが点滅する都度行っている。

乾燥フィルター奥の掃除

乾燥フィルター奥(差込口)には、想像以上にホコリが溜まっているので、定期的に掃除する必要がある。 形状記憶のピックアップツールを使ってホコリを取りつつ、取れない分は下側の乾燥経路に落とす。

ピックアップツールで取り出せない場合は、素手を使う場合もある。

乾燥フィルターの掃除は下記が参考になる。 kajikko.b-engineer.co.jp

排水エラーの対処(排水ホースの掃除)

乾燥フィルターの奥を掃除すると、ホコリが排出され排水ホースに溜まり、頻繁に排水エラーが起きる。 この場合、下記の動画のように排水ホースを取り出し、中のホコリを取り出す必要がある。

ペットボトルに水を入れ、排水ホースに水を注入し出すといった工程を数度行うことで解決できる。

www.youtube.com

参考

詳しくは、下記の取扱説明書を参考にされたい。

苦手だった英語のリスニングを克服した

先日2年ぶりに受けたTOEICの結果が出た。

リスニングのスコアが前回より140点ほど上昇し、365/495点となった。 もちろん自慢できる点数ではないが、これまで英語のリスニングが大の苦手だったことを考えると、大きな成長を感じる。

せっかくなので、どういった過程を経たのかを記事にしてみようと思う。

これまでの英語リスニングスコア

大学受験をしたのはもう14年前。当時はリスニングがセンター試験と国立の二次試験で課されるくらいで非常にウェイトが少なかったため、学習時間をほとんど投下しなかった。 結果、センター試験のリスニングが26/50だったのを記憶している。

大学2年目と社会人8年目でTOEICを受けたが、リスニングのスコアはそれぞれ275/495, 225/495だった。 試験では音声をまったく聞き取れず、ほぼ勘でマークをするしかなかった。

自分は英語のリスニングができないのではなく、根本的に耳が悪いのではないかとすら思っていた。

2022/10~11: 転機 "英語喉"との出会い

英語は喉で発音するとクリアに発音できる、発音できると聞き取れるようになるという"英語喉"というメソッドを、Twitterでたまたま見かけた。

英語喉を提唱されている"KAZ先生"の動画を見ると妙に納得感を得て、もしかしたらリスニングを克服できるかもしれないと感じた。

さっそく著書を2冊読み、喉を使った発音やシラブル(音節)について学んだ。 特にシラブルを知れたことは大きく、英語の音の繋がりやリズムに理論があることに驚いた。

書籍を読んですぐにリスニング力が上がったという感覚はなかったけど、今後のインプットを通じてリスニング力を鍛えられたのは、英語喉のメソッドを知れたからこそだった。

2022/12~: 音読、オーバーラッピング、シャドーウィング

次は英語喉を実践するため、ひたすらオーバーラッピングやシャドーウィング、音読をした。 昔からフレーズで覚えるタイプの英単語帳*1が好きだったので、教材は『ALL IN ONE TOEIC テスト 音速チャージ!』を選んだ。

はじめは音声のみを数回聞き、その後テキストを読んで、さらにシャドーイングを繰り返すといったサイクルを、すべての251英文で実践した。 ここでのシャドーイングは、できるだけ英語喉のメソッドに倣うように意識した。

単語帳を進めるにつれて徐々に聞き取れるようになり、リスニング力が少しずつ上っている感覚を持った。

ちなみに、オーバーラッピングやシャドーウィング、音読という学習法は、英語学習について体系的に知りたいと思い手にとった『英語上達完全マップ』でも推奨されていたので、納得感を持って進めることができた。

2023/01~: 英会話

英語学習の目的は、英語を話せるようになることなので、オンライン英会話に入会した。

nativecamp.net

英会話自体がリスニングにどれほど貢献したかはわからないが、講師の先生から発音に対してネガティヴなフィードバックをもらうことは少なく、自分のやり方の方向性が悪くはないことを認識できた。

2023/02: TOEIC

せっかくリスニング力が上がってきたので、実力測定のためにTOEICを受けることにした。

事前に解き方のコツを掴もうと考え、試験1ヶ月前に『TOEIC(R) L&Rテスト 直前の技術(以下、直前の技術)』を購入し、3回解いた。

しかし、リスニングのPart3, Part4はやはり難しく、問題文に気を取られて音声に集中できず、リズムを崩してパニックに陥るということが多々あった。 YouTubeでリスニングの問題の解き方やマインドを学び自分に合った方法を確立して、試験本番でもできるだけ冷静に回答できるように心がけ、以下の方法を採った。

  • 問題の先読みは、基本設問だけで解答は読まない
  • リスニングでは、聞くことのみに集中する
  • 解答は、リスニング後に行う

www.youtube.com

試験1週間前に公式問題集を購入した。時間がないため問題は解かずに、リスニングのPart3, Part4の音源でオーバーラッピング、シャドーウィングを繰り返した。 限られた時間で、各国の話者の声に効率よく慣れることができたように思う。

試験当日は、緊張もあり、練習通りには全然聞き取れなかった。 しかし、できるだけ自分のペースを崩さずに、冷静に対処するようにした。 解き方をある程度確立できていたことが大きかったように思う。

そして、冒頭にも書いたとおり、TOEICの結果が発表され、リスニングのスコアが365/495点まで上昇していた。 いつのまにかリスニングへの苦手意識が払拭でき、そこそこ聞き取れるようになってきたのが嬉しい。

2023/03: 今後

今後はテスト対策などを目的とせず、生の英語に触れていきたい。 YouTubeの「ByteByte Go」というチャンネルは、システムデザインに関する動画がメインで非常に面白く、かつスピーカーの方の声も聞き取りやすいため、当分はこのチャンネルを見ていきたいと思っている。

www.youtube.com

*1:DUO3.0

[改訂新版]プログラマのための文字コード技術入門』を読んだ

『[改訂新版]プログラマのための文字コード技術入門』を読んだので、感想を書く。

結論としては、文字コードにまつわる話題が1冊にまとまっており、仕事でプログラムを書く人にとっては1度読んでおくと長期的に役立つことが多い書籍だと感じた。

読み初めの動機

テキスト処理をする際に、文字コードについてハマることが度々あり、その都度調べるもののすぐ忘れてしまうため、一度体系的に学ぼうと考えた。

感想

文字コードに関連する話題がわかりやすくまとまっていてよかった。リファレンス的に今後も読み直すことだろう。

本書を読むことで下記について理解できた。

いつものことながら、基本用語をMarkdownでまとめた。

github.com

今後

今回の文字コードのように、都度調べては忘れてしまうことは一度体系的に学ぶと知識の定着率が高くなる。こうしたトピックがあれば今後も短期集中で学んでいきたい。

『[試して理解]Linuxのしくみ』を読んだ

『[試して理解]Linuxのしくみ』を読んだ。

過去に第1版を読んだことがあり、Linux OSの知識が業務で役立つ機会に何度も遭遇したため、第2版も楽しみつつ読めた。

これまで

低レイヤーの技術は定期的に学習し、これまでにいくつか書籍を読んだことがあるため、メモリやCPU、プロセス、スレッドについてはなんとなくわかる状態だった。

  • プログラムはなぜ動くのか
  • なるほどUnixプロセス
  • Goならわかるシステムプログラミング
  • ふつうのLinuxプログラミング

感想

第2版も自分にとって役立つ内容が多かった。 カラフルなイラストが豊富で読み進めやすく、サンプルコードを動かしながらハンズオンで理解できる点が自分に合っている。

低レイヤーの用語は忘れてしまいやすいため整理しながら読んだ。今までGistで管理していたけど、ファイル数が増えGitHubに1リポジトリにまとめたほうが管理しやすくなってきたため、GitHubに移行した。

github.com

ここからは、本書の特に良かった点について書く。

バックエンドエンジニアにとって活かせる点が多い

私は主にバックエンドエンジニアとしてアプリケーション開発やインフラ監視に携わっている。 普段の業務で毎日OSのしくみを意識しているかといえばそんなことはないが、とはいえOSのしくみの理解が必要な業務もそこそこにある。

  • SLIを満たせるか検証するために負荷試験をする
  • サービスのパフォーマンスの低下原因をDATADOGから読み取る
  • サービスへの膨大なリクエストを効率的にさばけるようにする

これらの業務をこなすために、都度OSの勉強をするのはあまりにも時間がかかってしまうので、1つの書籍で体系的に学べるのは本当にありがたい。

書籍に収まらない内容でも、著者の記事が紹介されているため書籍の延長として知識を拡充できるのも良かった。

手を動かしながらOSの挙動を理解できる

サンプルコードが公開されているため、Cloneして手元で動かせるのは親切で、字面だけだとわかったようなわからないような曖昧になりがちな点を手を動かしながら理解できる。

github.com

使用されている言語は第1版はC言語であり、第2版からPythonやGoがメインとなった。Go使いの自分にとってはありがたい限り。

書籍で紹介されていた、各種コマンドは普段はあまり使わないものもあけど、しかるべき時にサクッと使えるよう慣れておきたいと思っている。

  • ps←これはよく使う
  • time
  • free
  • sar
  • top

(参考)Ubuntuの動作環境

実験プログラムは、物理マシン上にインストールしたUbuntu20.04/x86_64上で動かすことを想定しています。

と本書にある通りUbuntuの環境を想定している。

私はM1 Macを利用しているため、仮想環境を利用してUbuntuの環境を用意した。初めはVirtual Boxを使ってみたがうまく動かせなくて他のツールを探したら、UTMというツールを知った。

UTMはとても使いやすい。 UTMでUbuntu環境を起動し、MacからSSHで接続をして、本書のサンプルコードを動かした。

しかし、Pythonとライブラリを使ってグラフを描画するサンプルコードに限っては、自分の環境ではうまく動かせなかった。デバッグに時間がかかりそうだったため書籍に掲載されているグラフを読んで理解するにとどめ、グラスを作成することは諦めて先へ進めることにした。

UTMのセットアップで参考にした記事はこちら。

oopsoop.com

今後

今後も低レイヤーの技術の学習は定期的にやっていきたい。 興味のある分野としては、システムのパフォーマンス改善や並行処理に関するテーマであり、それぞれ気になっている書籍があるので、また時間を見つけて読んでいく。

他にも、ハンズオン系の学習が好きなのでミドルウェアの自作に興味がある。

エンジニア3年目 2022年振り返り

エンジニア3年目の振り返りをする。

昨年までは、プライベートでの技術的な取り組みをテーマにしていたけど、今年から振り返りの内容を広げてみる。

過去の振り返り

仕事

1-6月: 前職

前職では、Ruby, Rails, Vue.jsによる開発をメインとにしつつ、以下の機能開発などをやらせてもらった。

  • Auth0による認証機能
  • WebSocketによるチャット機能

特定の言語やフレームワークによらないWebに関する技術の知見を深める良い機会となった。 初めて深夜作業をしたのだけど、エンジニアっぽい経験ができて楽しかった。

7-12月: 現職

現職では、GCPKubernetesクラスタ上の会計マイクロサービスをGoで開発している。 はじめて自社開発企業で働いているため、立ち回り方がよく分からなかったが、とにかく主体的に、どんなボールでも拾うことを意識している。

現職では半期ごとにチームメンバーからレビューを貰える制度があり、「キャッチアップが早い」「積極的に改善提案をしてくれて助かる」といった肯定的なコメントを多数もらえて、順調に馴染めてきてきたことがわかった。

機能開発以外にはいくつか開発フローに関する課題感を共有し、実行までやりきってチームに一定貢献できた。

  • 会計ドメインの知見共有
  • 開発フローの策定
  • タスクのレビューフローの改善
  • ログ・監視基盤の改善
  • 振り返りの改善

技術学習、キャリア編

1~3月: 転職活動

前職で2年が経ち、新しいことをやりたくなったため転職活動をした。

必須条件として「Goを使えること」「FinTech領域であること」を掲げ、自社開発企業に絞り選考を受けることに。

結果6社ほど内定をいただき、メルカリへの入社を決めた。

当時はエンジニアの経験としては2年程度だったため転職活動は難航することが想定されたが、スムーズに進んでよかった。

転職活動の振り返りはこちら。

yuki0920.hatenablog.jp

4~5月: コンピューターと向き合う

定期的にコンピューターサイエンスの知識増強をしている。 今回はゴールデンウィークを使って、名著との呼び声高い『コンピュータシステムの理論と実装』を読んだ。

コンパイラやバーチャルマシン、アセンブラをハンズオンで作る過程で、プログラミングがコンパイルされ、機械語へ変換されてCPUやメモリがどのように動くのか手触り感を持って理解できたのはよかった。

2ヶ月間集中し100時間以上かかったけど、大量の時間を投下するに相応しい価値のある書籍だったと思う。

読んだ感想はこちら。

zenn.dev

6月: 新しい技術のキャッチアップ

新しい会社で使う技術は、次のような未経験の技術ばかりだったので、入社前に基本を抑えておくことにした。

  • Go
  • GCP
  • Kuberentes
  • React
  • GraphQL

公式ドキュメントや技術書、Udemyを利用してざっと基本を学んだくらいではあるけど、結果的には入社後にとても役立った。

なお、ReactやGraphQLはまだ業務で使えていない。

7~9月: 入社 & キャッチアップ

7月に入社し3ヶ月かけて、事業面、技術面のキャッチアップに注力した。 入社してすぐは、膨大な情報があることに驚いた。リリースから10年が経っている大規模サービスとなると、こんなにも情報に溢れているのかと。

ドキュメントとソースコードを読む、知ったことをドキュメントにまとめる、のサイクルを高速で回し続けていたらいつの間にかキャッチアップが完了した。 今までの経験で、スタートアップのような少人数のエンジニア組織でバリューを出せる自負はあったけど、大規模組織でもバリューを出せることがわかって大きな自信となった。

エンジニアとしてのオンボーディングについて意識していることを詳しく書いた。

yuki0920.hatenablog.jp

10月: ソフトウェアアーキテクチャ

この頃から今後のキャリアとしてテックリードを目指したいと考えるようになり、アーキテクチャ設計に関する知見を深めたいと考えるように。 マイクロサービスを含めたさまざまなアーキテクチャについて学習するために、『ソフトウェアアーキテクチャの基礎』を読んだ。

yuki0920.hatenablog.jp

12月: 英語

10月より週に1度英語のミーティングが開催されることとなった。

この日から自分の英語へのモチベーションは急激に上がり、少しずつ英語の学習量を増やしてきた。 そして将来的には、英語で技術的なディスカッションができるようになりたいと思っている。

現在はリーディングとリスニングに注力しており、英単語帳を使って学習をしているところ。

私生活

子供が0歳から1歳になり、日々の成長を見守るのがとても楽しい。

今年だけでも、いろいろなことが出来るようになった。

いつかは子離れしなければならない時が来るので、今はできるだけ多くの時間を子供と一緒に過ごすようにしている。

また、9月にスプラトゥーンが発売されて、めちゃくちゃはまり、1ヶ月100時間くらいプレイしていた。とても面白いのだけど、ある程度のレベル(ウデマエS+)まで上がると急に勝てなくなり、ここ最近は幸いゲームへの熱が落ち着いてきた。

まとめ

2022年を振り返った。

例年通り興味のある領域が数ヶ月単位で遷移しているけど、これが自分のスタイルなのだなと思う。 来年も興味駆動でいろいろなことに挑戦していきたい。

2022年買ってよかったもの

2022年も例年通りデスク周りの環境を改善し、理想の環境に近づいた。

デスク・仕事用

オカムラ バロンチェア

ニトリの5000円ほどのチェアを3年ほど使っていて、かなりヘタってきたので買い替えを検討していた。 予算を10万円に据えてWORKAHOLICに行ったら、20万円近くするバロンチェアに魅了され、もはやバロンチェア以外考えられなくなった。さすがに20万円は払えなかったため、オフィスバスターズで中古品を購入。

あたりが特に気に入っている。1日10時間以上椅子に座っても疲れないので、本当に良かった。

Logitech MX ERGO

これまでApple Magicpadを使っていた。

操作性には何の不満もなかったものの、充電が頻繁に切れるのがストレスフルで、充電の持ちがよいポインタデバイスが欲しくなった。

エンジニア界隈で使っている方が多いMX ERGOを買ってみたら、めちゃくちゃよい。

腕を動かす必要がないため、かなりスムーズにポインタの移動をすることができる。 多数のボタンがあるため、Magic Trackpadの操作性も兼ねられているのもポイントが高い。

  • ブラウザの次へ/戻る
  • タブの右/左の切り替え
  • Mission Control

Apple iPad mini

iPad miniによって気軽に学習できるようになり、学習時間が増えた。 ソファに座りながら、技術書を読んだり英語学習アプリをやったりなど、1日1時間以上使っている。

実は5月頃に学習用途でFire HD 10を購入したけど、

  • 指紋認証、Face IDが使えず、1Passwordの認証が非常に手間
  • 物理的に重い

との理由で全然使わなくなってしまった。

iPad miniはこれらの課題を一気に解決した最高のプロダクトであり、常用している。

Jabra スピーカーフォン

スピーカーフォンは昨年Ankerのものを購入したけど、マイクの音質がかなり悪く使い物にならなかった。

Jabraというメーカーは定評があるらしく、値は張るものの購入してみた。 マイク音質が劇的に良くなり、長時間ミーティングを快適に過ごせるようになり満足度が高い。

Bose PC スピーカー

Netflixを見るようになり、迫力あるサウンドが欲しくなった。 やはりBoseなだけあって音質が良い。

Shokz OpenRun 骨伝導イヤホン

かねてより骨伝導イヤフォンに興味があったけど、やっぱり良かった。 イヤフォンを耳にかけても生活音が耳に入ってくるため、リビングにいながら英語などの音声を聞きたいときに重宝している。 主に英語学習用。

Apple AirPods 第3世代

AirPods第1世代からの買い替え。

カナル型イヤフォンは苦手なため、Proではなく無印版を購入。 空間オーディオ機能により立体的な音を感じられたり、オーディオの制御がしやすくなっって、使いやすさが向上した。

Nintendo Switch 有機ELモデル

我が家は元々Switchを1台所有していた。 しかし9月にスプラトゥーンが発売されてからは、妻とSwitchの争奪戦が繰り広げられるようになったため、自室へ追加で1台購入。 あまりゲームはしないけれども、やりたいときに出来るのはやっぱり良い。

私生活用

Panasonic 49インチ 4K TV

10年以上使っていたリビングのテレビを買い替えた。

リビングに設置する都合上、視野角が広めで、かつ音質がそこそこ良いものを購入。 コロナ渦で外出頻度が減り妻とテレビをみて過ごす時間が増え、テレビは夫婦の貴重な娯楽の1つとなっているので、満足度を上げられてよかった。

Panasonic ブルーレイレコーダー

我が家はテレビをリアルタイムというよりは、録画でまとめてみることが多い。

全自動で全チャンネルを録画してくれる全録機能のあるレコーダーを購入し、快適なテレビ環境が整った。

炭酸水

お酒を飲むことが多くなっていたのだけど、翌日の寝起きが悪くてどうにかしたいと思っていた。 お酒の代わりに炭酸水を飲むことにしたら、晩酌の頻度が減って体調も良好に。

僕が欲しかったのは、お酒と言うよりシュワシュワだったのかもしれない。

500mのペットボトル1本50円くらいなので、気軽に飲めるのも良い。仕事の気分転換にもなる。

今のデスク環境

こんな感じ。

エンジニアとして爆速でオンボーディングするために実践していること

新しい会社に入社して3ヶ月が経過した。

所属先はクオーターごとに評価のフィードバックを得ることができる。マネージャーや複数のチームメンバーからは、スムーズにオンボーディング(ないし、キャッチアップ)ができたという意見を貰った。 オンボーディングに関してやったことは前職のときから実践しており、今の会社で目新しいことはやっていないのだけど、評価をしてもらうことができた。

エンジニアになった当初はどのようにオンボーディングしていくかかなり悩んだので、スムーズにできるようになったことは嬉しいし、せっかくなのでノウハウを書き留めておく。

前置き:昔の自分はどうだったか?

自分は3年前にIT業界未経験、エンジニア未経験の状態でこの世界に入った。

ビジネスのことも技術のこともわからず、仕事をまともに進めることができなかった。

アサインされたタスクを自分なりに進めてみるものの、最後の方までやったあとで仕様と齟齬があることが判明し、1からやり直しになることもあった。 とにかく戦力になれている感覚がなく、周りに迷惑をかけてばかりで、無性に申し訳無さと恥ずかしさを感じていた。エンジニアになったことを後悔すらしたこともあった。

この申し訳無さと恥ずかしさをできるだけ短期間で解消するべく、試行錯誤をして今の考えに至った。

オンボーディングについては昔から考えていて、エンジニア1年目の前職時代に記事を書いた。

blog.agile.esm.co.jp

この記事の内容と今の考えに乖離があるわけではないが、当時より少しパワーアップした現段階で同じテーマについてより深く書いていきたい。

初めの3ヶ月は負荷を上げる

初めの1~3ヶ月のオンボーディング期間で、チームメンバーから得られる信頼が決まると言っても過言ではないと思う。この信頼によってこの後の仕事の進めやすさが絶大に変わる

そのため、オンボーディング期間は業務外の時間もキャッチアップに充てることがある。短期的な負荷は高まるが、オンボーディングがスムーズにできれば長期的に働きやすくなる実感があるため、そこは割り切ってやっている。

もちろん、業務時間内だけで完結できればよいのだけれども、自分は要領が悪い方なので、要領が悪いなりに周りの人より時間を多く注ぐというアプローチで解決している。

膨大なインプットとアウトプットを意識する

オンボーディング期間は新しい知識が膨大に必要となる。このために、参画したプロジェクトのドキュメントや担当サービスのソースコードはすべて読んでおく

これらのインプットは今後のために重要ではある一方、加えてアウトプットをすることで高いインプットへ昇華できる。

環境構築のドキュメントを例にすると、

  • 環境構築で詰まった点と解消法を追記する
  • 公式のドキュメントやわかりやすい解説記事のリンクを貼る
  • リンク切れのリンクを貼り替える

など、色々とできることはある。これらを修正した旨をチームメンバーへ共有し、自分の対応の方向性についてフィードバックを得ることで、環境構築に対してより高い解像度で理解をできる。単にドキュメントを読むよりもインプット効率が高いし、チームへのアウトプットも兼ねられる。

こまめに作業方針の相談をする

新しい会社では、自分の携わってきた業務とは異なる前提が適用されていることが多い。 特に初期のタスクでは認識の齟齬が起きやいため、タスクがアサインされたら作業を棚卸して、チームへ方針の相談をする。

「この方針で進めようと思っておりそのためにはA,B,Cの3つの作業が必要と認識しているが、齟齬ないでしょうか?」

といった形で確認する。すると、チームメンバーからは作業漏れや方針のズレを指摘してもらえたり、会社固有のお作法を教えてもらえたりして、このあとの作業の手戻りを大幅に減らすことができる。

今の会社の場合、大きな機能開発の場合はDesign Docを作るという文化があり、こうしたことを教えてもらった。

データとドメインの関係性を理解する

データストア(RDBやNoSQL)のデータ構造とドメインの関係性を理解しておくと、仕様や実装面からディスカッションに参加しやすくなる。 Graphvizなどを使って、DBスキーマからER図を自動で生成するのもおすすめ。 スキーマファイルからテーブル構造を把握し、テーブル間のリレーションやテーブルやカラムの持つドメイン的な意味を一通り理解しておく。

自分の場合は、理解したことをアウトプットとして残すためにTable Listというドキュメントを社内向けに作成した。このドキュメントは、対象のアプリケーションのすべてのテーブルを網羅しており、

  • カラムとドメインの関連性
  • テーブルを操作・参照するビジネス要件

などを記載したもので、自分の次にオンボーディングをする方にとって有用であると考え作成した。 チーム内からの評判は概ね良好で、「このドキュメントを参照したら他チームからの問い合わせにすぐ応えられた」、なんていうフィードバックをもらうことまでできた。

依存ライブラリの調査をする

アプリケーションを開発する場合、依存ライブラリを使用するケースが多い。 機能改修をする際に、ライブラリの使い方がよくわらかない、誤認していた等によって開発を効率的に進められないと困る。 なので、使い方がわからない依存ライブラリはすべて調べておく

Goならば、 go.modファイルを見ればすべての依存ライブラリが記載されているので、一通り公式ドキュメントを読み、よくわからなければ解説記事を読み、また公式ドキュメントを読むといったこと繰り返す。 依存ライブラリの使い方がわかった上で、アプリケーションにおいてどのように使うのかがわからないときは、同僚を捕まえて根掘り葉掘り聞く。

特に、

  • Test
  • Mock
  • Lint
  • Web Framework
  • Generating Code

あたりのライブラリを知っておく効用は高い。

Goだと、godocコマンドでlocalにドキュメント用のサーバーを立ち上げて全体感を把握するのもよい。

技術スタックについて幅広くインプットする

幅広く技術を知っておくことで、既存のソースコードに対して今後のリアーキテクチャ案やリファクタリング案が浮かぶことが多い。これによって、技術的なディスカッションに深く入っていくことができる。 これは、自分が今後テックリードのロールを目指しているために実践していることとも言える。

自分の場合は、下記の技術についてそれぞれ技術書数冊と関連のドキュメントを読んだ。

改善提案をする

新規参画者ならではの視点で、改善提案できることはいくつもある。 もちろん、既存のやりかたにもメリットはあるので、伝え方には気をつける。 自分の場合はスクラムイベントの振り返りの場でこうした課題やアイディアを共有するようにしている。

すでに、

  • Jiraのチケット運用
  • ドキュメントのレビューフロー
  • GitHub ActionsによるCI/CD

などについての課題感を共有し、改善までやりきった。

ペアプログラミングをする

ペアプログラミングによって開発プロセスを効率的に共有できる。

会社やチームごとにソフトウェアの開発プロセスは異なることが多い。そこで、ペアプログラミングをしてもらい機能開発からデプロイまで含めた一連の開発フローを体験させてもらう。

今のチームではペアプログラミングが常習化していなかったので、「このデプロイ作業一緒に見させてもらえないですか?」といった具合に、先輩の作業を見させてもらう場を積極的に作ったりした。 Kubernetes環境にSpinnakerを利用してデプロイする作業があるのだけど、ペア作業で見させてもらったおかげで、「デプロイするのは案外簡単だな」ということがわかった。

参考

エンジニアのオンボーディングというテーマを考えるにあたり、特に参考にさせてもらった記事はこちら。

https://qiita.com/jnchito/items/017487cd882091494298 https://note.com/hik0107/n/n1d7b93c57cdd

最後に

エンジニアとしてのオンボーディングについて、複数の会社で通用するような再現性の高いやり方が定着してきた。 今のやり方に執着せず、常にアップデートしていきたい。