2021年振り返り

2020年

スキル変化

• +Clojure
• +Microservices:Tracing, Kubrnetes, Helm, AWS integration
• +Terraform
• +Web App development
• +Design Web App Backend from scratch
• +Collaboration
• +(a little bit)React
• +American English
• -Node.js
• -TypeScript
• -CloudFormation, CDK
• -Design system for a medium scale project

Updates

• アメリカの会社で働き始めました
• 4ヶ月くらい福岡、広島など自宅以外で過ごしました

アメリカの会社で働き始めました

日本でInternationalなチームで働いていて忙しくも楽しかったのですが、やむをえない事情でアメリカの会社に転職しました。転職のきっかけは誘いがあったことから。非常に感謝しています。前職は仕事はさておきこれまで史上最高のチームメンバー達でした。チームメンバー達がみんな幸せになってくれたら最高だなって祈り続けています。 いつか結婚のためにスウェーデンにいった同僚の家に遊びに行きたい。

前職では大量の重いリクエストを捌くためのシステムをメンテナンスしつつ刷新するプロジェクトに従事しており、新システムのデプロイをすませた段階で退職。システムデザインを0からできたことやキューを使った複雑なシステム連携について学ぶことができました。

現職はMicroservices上で動くWebアプリを作る仕事をしています。作るサービスの規模は下がったもののMicroServices特有の課題を学ぶことができたり久しぶりにWebアプリ作成を楽しんでいます。

現職でのチームは非常に優秀な人が多く、日々学ぶ事が多いです。前職で苦しんでたことの一つとしてシニアエンジニアとしてのロールモデルがいないことが挙げられますが、現職ではロールモデルばかりで楽しいです。

前職ですごく仲の良かった同僚も入社してきてSlackのDMで突然Hi!って言われたときはおもしろかった。

2020 Try

• ✔ 仕事を選択・集中し、考える時間を増やす：ビジネスに貢献する中規模以上のタスクのみに集中する。インフラ管理は今やっているCDKの移行にとどめ、新規のタスクはチーム内のサポートのみにする。よい学習ができそうなタスクは移譲するようにする
• クリティカルな貢献チャレンジをする: 2020年はシステム的な貢献だったが、ビジネス的にクリティカルなものを達成する、忙殺されない状態で 転職したため
• ✔ 英語pairingを問題なくできるように：オンライン英会話の継続、特にNativeの人との英会話を問題なくできるようにする
• チームの学習機会を増加させる：自分で手を動かすかわりによりチームにフォーカスし、こちらの芝はとても青いものだよという状態にする 転職したため

Keep

Infrastructure work

相変わらずクラウドインフラに関する仕事が人より速くてよくできている実感があります。強みは保持しつつチーム全体の底上げができたら幸い。

• インフラチームが管理してるTerraform repositoryへの貢献
• CI/CD
• Observability向上

Collaboration

現職ではチームワークを重視していて、 - できるだけ限られたチケットにみんなでフォーカスすること - リモートワークでの仕事なのでオーバーコミュニケーションをすることで認識の齟齬を防ぐこと

などからよくペアプロする機会が増えました。チームの特性にもよりますが自分にはあってる働き方なのでチームで課題を解決することをより意識していきたいです。

ロールモデルが多い

Cross Team Collaboration god

彼は他チームの人との調整がとても迅速、上手です。なおかつ他チームへのヘルプも積極的に行っており、彼と他チームの間にある助け合いの循環がとても良く回っています。今後彼の動きを模倣していきたい。 これを達成するために阻害となっている英語力もできれば上げていきたい。

Team work god

Team workの管理が非常に上手な同僚がチーム内にいます。彼は情報をできるだけ明確にしチーム内に共有することやチーム内でのコミュニケーションの促進が非常にうまいです。チーム内での会話の時間が足りない問題に対しCoffee Chatの時間を設けたり、Onboardingや他チームが参照できる非常にわかりやすいドキュメントの作成してくれてありがたいです。

またペアプロがとても上手で不明点を明らかにし、その中で問題点と改善点を必ずとりあげてくれます。

PdM/PM god

PdMに必要な能力の一つとして迅速かつboldで良い意思決定ができることが挙げられるかと思いますが、非常にうまい同僚がいます。彼女はPMも兼任していてその問題定義能力、進捗管理や他の人へのプレゼン力など見習うところが多いです。とにかく頭の回転がめちゃくちゃ早い。

EM god

チームをうまく監視し自立的に動けるようにサポートしてくれるEngineering Managerがいます。必要なときはチームを助けてくれ、普段はチームメンバーの学びを最大限に高めてくれるための課題や助言を提供してくれます。彼がいるからチームがうまく回ってると思う。

英語

英語で仕事をしはじめてから2年、そこそこできるようになったかなと思いましたが、アメリカ出身の同僚達に囲まれてネイティブEnglishとほぼフルタイムで触れるのは今年からです。レベルが一段回上がったのを感じており、ネイティブの英語を聞く、読む機会を増やす必要があると感じています。

割とつらいのが相手のマイク環境によって難易度が上がるところ。とはいえネイティブ同士だと普通に会話できているので頑張って聞き取るしかないです。

英語むずいと感じる日々を送っていますがそれでも着実にレベルアップはできていると感じています。

広島にいたときの学習方法として映画を字幕なしで見るというのがありますが、割と良い気がしています。長時間英語にさらされつつも楽しくて続けることができるため。一人で映画をみる機会をもう少し増やしていきたい。

Clojure

Clojure、最初にやり始めた頃は読みにくいと思っていたのですが慣れるとすごい読みやすいです。

自分が思うClojureのPros and Cons

Pros:

• 慣れるととてもわかり易い
• 一度コードを作成するとそんなに修正しないで保ち続けられる(なぜだろう、シンプルにかけるからかな)

Cons:

• ライブラリまわり
  • ドキュメント不足していることが多い。なぜか知らないがGitHub Wikiを多用している
  • デファクトが存在しない分野がありどれを使うがでために揉める

あとは以下観測していますが、言語とは関係ないかも。

• シンプルに書かない傾向の人がいるとやばいコードができがち。Clojureでも防ぎきれなかったかという印象。
• 古い巨大コードだとエディタプラグインが機能しない時がある(VSCode/Emacs/Vimで確認)

その他よいこと

• 6kgやせた

Problem

弱い

優秀な人に囲まれることで色々問題点が浮き彫りになるのがとても良い。

以下あたりが課題

• Cross Team Collaboration
• 迅速な意思決定
• 対象の求めていることを意識し、それに沿った説明をする
• WhatとWhyへの意識
• 英語
• 改善案の継続的な提示
• Kubernetes

特にCross Team CollaborationはStaff Software Engineerのロールで動いている自分としては必須だと思っている。2022年度はこの点を向上していきたい。そのためには普段から他のチームの人達とコミュニケーションをとることとヘルプが必要なときにヘルプをする必要がある。そのためには英語力が必要。

Try

• 英語字幕なしで映画を見る
• 普段から英語でしゃべる機会を増やす、e.g., ペアプロを積極的に誘う
• ほかチームのヘルプを行うためにSlackのPublic Channelをちゃんとみる
• 相手の求めていることを意識した行動をする
• WhatとWhyフェーズへの積極的な関与
• タスクを定義するときはスコープを広げすぎないよう注意すること
• PdMのヘルプ
• Kubernetes Udemy講座の終了
• 自宅k8s環境へのHelm導入

OSS

https://github.com/nanonanomachine/vim-ref-clojuredocs

AWS CDKメモ: ディレクトリ構造、CI/CD、共通コンポーネント

AWS CDKのディレクトリ構造についての備忘録。マルチリージョン、マルチアカウントで管理する必要があったが今のところ安定して運用できている方法を記す。

前提

• CDK version: 1.94.1
• マルチリージョン e.g, ap-northeast-1, ap-southeast-2など
• マルチアカウント e.g., productionアカウント、stagingアカウントなど

マルチリージョンではない場合は以下でも良いと考えている

github.com

構造

▾ bin/
  ▸ serviceA/
      jp-production.ts
      jp-staging.ts
      au-production.ts
      au-staging.ts
  ▸ serviceB/
▾ lib/
  ▸ serviceA/
    ▾ policies/
          policyA.ts
          policyB.ts
      buildApp.ts (or index.ts)
      stackA.ts
      stackB.ts
      IAMStack.ts
  ▸ serviceB/
▸ test/
  ▸ serviceA/
      buildApp.test.ts
      stackA.test.ts
      stackB.test.ts
      IAMStack.test.ts
  ▸ serviceB/

• lib AppとApp内のStackを定義。IAMのStackは複雑になりがちなので policies　ディレクトリに各policyを定義。buildAppでAppを返す関数を定義する
• testテストを定義
• bin buildAppで定義された関数をステージ、リージョンの引数を与えて呼び出し、App#synth()を呼び出す

CI, CD

• PRが送られてきた際にはcdk diffを呼び出しdiffがわかるようにする
• production, stagingブランチにPRがマージされた際 cdk deployを呼ぶようにする。App内のStackの依存関係はCDKに自動解決してもらいたいので、-no-executeオプションをつけChangeSetを作るとChangeSetの管理や実行順序の管理が難しくなる。そのためCircleCIやGitHubActionsのapprovalステップを追加すると良いと思う。
• マルチアカウントの切り替えはAssumeRoleを使って頑張る。自分の場合はよりアクセス権の厳しいRoleを各アカウント下にプロジェクトごとに用意してAssumeRoleするようにし影響範囲を狭めている。

共通コンポーネント

同一ディレクトリで管理しても良いが、自分の場合は複数レポジトリで管理する必要があったためCDK Construct Libraryとして単独レポジトリで管理している。その際projenのAWSCDKConstructLibraryを用いた。

projen/projen

projenはjsiiを使い多言語でのライブラリを提供することを想定しているため一部のTypeScriptのシンタックスが使えなくなる点に注意。

共通コンポーネントして自分の場合は以下を定義している

• enum...アカウント、ステージ、国などをenumで定義
• BaseStack...会社の基本Stackを用意。会社のStackを使うと自動的に会社標準のtagが付与されるようにしていたり、Aspects を利用して会社のデフォルトのセキュリティバリデーションがかかるようにしている。

改善点

• プロジェクトに関わらずCDK bootstrapをしているがプロジェクトごとに—toolkit-stack-nameをすると各プロジェクトごとのChangeSetの管理用のRoleが作成され、よりセキュアなChangeSetの管理ができるようになる。

好ましくない事実から根本原因を抽出しJob Storyを作るプロセス

仕事でチームやチームの管理するシステムの根源的な問題を効率的に抽出する必要があった。カネビン・フレームワークやJobs To Be Doneフレームワークなど、既存の複数のフレームワークを組み合わせて独自プロセスを試したら割と手応えがあったので共有する。

きっかけ

私が所属しているチームではFeature(新規機能追加)、Support(既存コードベースの問題に対する対応)、Project(長期目線でのシステム修正)という３つの種類のタスクがある。 組織体制が変更され、今一度Projectをやっていく上でのチームやチームのシステムに対する問題の洗い出しをする必要が生じた。この際以下を必要とした:

• 問題の網羅
• 問題の掘り下げ

マネージャのマネージャからは「問題が明確であれば解決策は自ずと明確になるので問題に注力しろ」との言葉をもらい、最終的な形としてできるだけ解決策が明確に想像できるように意識しようと考えた。またチーム内で問題のインパクトの大きさについて議論されるケースが少ないと自分は感じていたため、問題とそれに対するインパクトを明確にしたいと考えた。

最終形

友人や同僚と相談しつつ最終的に以下の形でチームの問題を抽出した。

1. 好ましくない事実の列挙
2. カネビン・フレームワークを用い単純系・困難系・複雑系・カオス系に分類する
3. 困難系の事実に対して"なぜ"を繰り返し根本原因を抽出する
4. 根本原因を分類する
5. Jobs To Be Doneフレームワークと某社で採用されているフレームワークを用い、Issue (Job story)、Loss 、Problemsの表を作る

1. 好ましくない事実の列挙

問題と解決策はいくつか頭の中で思い浮かぶが思い込みなどで間違っていないようにするため、事実からスタートするようにした。 例えば以下は弊チームの好ましくない事実の抜粋である:

• リソースが足りない
• ユーザーから問い合わせがない限りシステムの問題に気づかない
• システムに問題が生じた時に根本原因を探すのが難しい
• 古いシステムのスクリプトを直すのが難しい
• システムに関するドメイン知識を取得するのが難しい

この際認識の齟齬がないよう複数人によるレビューをして共通認識であることを確認した。

2. カネビン・フレームワークを用い単純系・困難系・複雑系・カオス系に分類する

1.で事実を列挙したが、解決策が自明な問題より解決策がわからないような事実を深掘りしたい。 カネビン・フレームワークの存在があることを先輩から教えていただいた。

successpoint.co.jp

www.mindtools.com

カネビン・フレームワークによると問題は以下の４つのカテゴリに分類することができる:

1. 単純系...誰でも簡単に解決できる
2. 困難系...専門家の知識が必要。不具合原因追及型の問題解決を使います。題が起きるのか、なぜなぜ問答を繰り返し、追究すると真の問題が見つかる。
3. 複雑系...原因が明確にわからない問題。人や組織に起こりがちな問題。仮説検証が必要。
4. カオス系...突発的に発生して、すぐに何らかの対応をする必要がある問題

これを利用し事実のうち困難系にフォーカスし問題を深掘りしていく。 1.の事実の場合以下のような分類になった。

1. 単純系... "リソースが足りない"
2. 困難系..."ユーザーから問い合わせがない限りシステムの問題に気づかない"、"システムに問題が生じた時に根本原因を探すのが難しい"、"古いシステムのスクリプトを直すが難しい"
3. 複雑系..."システムに関するドメイン知識を取得するのが難しい"

"システムに関するドメイン知識を取得するのが難しい"については単純に学習機会を増やせば良いと単純系に分類していたが、マネージャと相談した結果複雑系に分類した。これはある程度取り組んでいるにもかかわらずチームとして知識共有が十分にできていないためこのようになった。

3. 困難系の事実に対して"なぜ"を繰り返し根本原因を抽出する

カネビン・フレームワークでの困難系での解決策でも触れられているようになぜなぜ問答を繰り返すことで真の問題を探る。自身に専門知識がない場合は専門家にインタビューを行った。 2.で困難系に分類された事実"ユーザーから問い合わせがない限りシステムの問題に気づかない"は以下のようななぜなぜ問答を繰り返すことができる。

ユーザーから問い合わせがない限りシステムの問題に気づかないに対するなぜなぜ問答

このように事実からなぜなぜ問答を繰り返すことによって問題の細部に気づくことができる。この場合アラートシステムに改善点がありそうなのと、エラーの取り扱いに対して改善点がありそうだ。

4. 根本原因を分類する

困難系に分類された事実からなぜなぜ問答を繰り返すとかなりの量の"なぜ"が溜まっていく。この"なぜ"をカテゴリに分類することによって頻出する根本原因を抽出する。 自分が取り組んだ際にはObservability, Process, System complexityと３つの大分類ができた。さらに各大分類をサブカテゴリに分類した。 例えばObservabilityについては以下のようなサブカテゴリが出現した。

• エラー詳細がない
• データが壊れた時のアラートシステムが存在しない
• そもそも問題が発生した時のインパクトがわからない

5. Jobs To Be Doneフレームワークと某社で採用されているフレームワークを用い、Issue (Job story)、Loss 、Problemsの表を作る

4.で分類した根本原因をJobs To Be Doneフレームワークを用いて表現する。

jtbd.info

具体的には When _____ , I want to _____ , so I can _____ .で表現する。これにより対象ユーザーの欲求に対応した解決策を考えることができるようになる。

またこれに加え某社で使われている問題と解決策定義のフレームワークの一部を用いる。これは問題を以下のような形で定義する

• Issue...課題
• Loss...Issueにより被る損失を書く。
• Problems...Issueを引き起こしている様々な問題を書く。

Lossを書くことにより課題のインパクトを明確にできる。

上記を踏まえて表を作ると、Observability "エラー詳細がない"という分類に対しては以下のように書ける

Issue (Job Story)	Loss	Problems
私がSupportチケットに取り掛かる際エラー詳細が知りたいです、そうすることにより早く根本原因を見つけ修正できます(When I work on a support issue, I want to know the detail of the error, so I can detect the root cause faster and fix it earlier)	1人の問題調査専任エンジニア工数、早いレスポンスタイム	問題の重要度がエラータイプからわからない,そもそもエラーが曖昧だ, etc...

これにより最終的に根本原因一覧とそのインパクト(Loss)が明確になる。 英語でJob Storyをかくとしっくりくるのだが、日本語で書くとちょっと変になるかもしれない。その場合はCookpadの価値仮説シートが参考になると自分は思う。 以下URLに価値仮説シートの言及あり。 logmi.jp

やってみた感想

"5. Jobs To Be Doneフレームワークと某社で採用されているフレームワークを用い、Issue (Job story)、Loss 、Problemsの表を作る"の時点である程度解決策が想像できる課題にまでなっていることが多かったのが良かった。

また表を作成する際Lossをうまく書けないIssueが出てきた。メトリクスが不十分な場合が明確になる点が良かった。ただエンジニアの生産性のように、数値化が難しいLossに対してはどのように取り組むべきかまだわかっていない。

自分のチームではこれまで問題が発生した際にProjectを作成し対応してきたがこのような棚卸しはしていなかった。 棚卸しをすることにより以下の良い点を感じた:

• 特に"1. 好ましくない事実の列挙"、"2. カネビン・フレームワークを用い単純系・困難系・複雑系・カオス系に分類する"、"3. 困難系の事実に対して"なぜ"を繰り返し根本原因を抽出する"をすることにより議論と共通認識の醸成ができたこと
• チームとして解決策に注意が行きすぎるので問題とそのインパクトについてちゃんと議論する時間が取れたこと

おわりに

今後作成した表を元にMVPを作成し問題を検証しつつ最終的に本番環境に解決策を反映していくことになると思うが、また知見が溜まった際には共有できればと思う。

2020年振り返り

2019年

スキル変化

• +AWS: IAM, CloudFormation, Lambda, StepFunction
• +Node.js
• +TypeScript
• +Design new system
• +English both verbal and written
• -Ruby on Rails
• -API development

Updates

• Internationalなチームで英語メインに仕事して1年が立ちました
• WFHで2月から2回くらいしか会社にいきませんでした
• 広島で1ヶ月働きました、地方でWFHは実現可能だということを確認しました
• 近くに引っ越しました

Keep

Infrastructure, DevOps

• チームごとにインフラ触れるので触りまくる
• チーム/国横断でインフラ管理しまくる(そのせいで忙殺)
• IAMの詳細な権限管理手法習得
• CloudFormationつらすぎてCDK移行プロジェクトを実施(CDKの情報交換したい)
• チーム内のインフラ案件ほぼ関わる

中規模プロジェクトのデザイン from scratch

• フレームワークデザイン&構築： 調査、機能要件、非機能要件の整理、UMLを書いてプロトタイプで実現可能性を確認。その後ある程度簡素化されたが最終的には良い形ものになりますた
• インフラデザイン&構築：複数案提案、コスト計算、既存システムの知識も必要でほぼ一人で構築(そして忙殺)

Clear NotebooksWeb版の成長

• 今年もなんとか成長できました、これで入社したときからユーザー数n * 100倍くらい増やしました
• ログインユーザーのための施策を今年はやりました、こちらもいい感じに増加
• 一部ユーザーとのつながりもできてうれしい

英語

• 英語で仕事して1年、ある程度きける&しゃべれるようになった。具体的には電話で英語かかってきても普通に喋れるレベル
• Nativeの英語はまだ難しい
• 聞き取りはできるが、他の同僚と比べてまだ聞き取れるレベルは低い
• 語彙力なさすぎて "It would be great..." 使いすぎ問題

その他良いこと

Team culture

• 心理的安全性が高く素晴らしい、これはみんなが努力しているおかげ
• チャレンジできる環境がありみんなチャレンジしている
• ポジティブなことは明確に言ったほうがよい
• team culture > 年収 to me

引っ越し

• 10ヶ月くらい探したがとても大変であった
• 脱ベッドと机の行き来生活
• 近くに御飯食べれるところがある！

Problem

忙しすぎ

• ジュニアエンジニアのサポート/新システムのデザイン/新入社員のメンタリング/インフラ管理を同時進行
• 一時期意図的に仕事を絞ったこともあったが、それはそれで問題がおきた、いい方法がないものか...

いそがししゅぎ龍

— んむて (@nnm_tech) 2020年4月1日

GWやたら、忙しくて調べたら7プロジェクトくらい会社またいでやってたのでやめよう、明日は休む

— んむて (@nnm_tech) 2020年5月4日

今日は同僚からやっておくって言われて放置されてる積みタスクをいっぱい解消してます

— んむて (@nnm_tech) 2020年8月9日

今週は突然降りかかってきた某所投稿記事の翻訳作業、若者達のサポート(これは良い)、知ってるからと言って狩り出された突然の技術負債解消タスクにインシデント対応で非常に厳しい

— んむて (@nnm_tech) 2020年9月2日

やっと時間に空きが出たので個人的にやりたい作業してるけど２ヶ月前のこと完全に脳から消えてる...

— んむて (@nnm_tech) 2020年10月1日

mentoring

• 新入社員のmentoringも担当したが改善点多い。WFH下でのコミュニケーションのうまいやり方は未だに模索中。
• 人の文化的な特性や性格によって動きを変える。例：アメリカから来た同僚なので明確に物事を伝える必要がある
• 詳細に気をつける
• すべての人間が技術的に長けている仮定で動かず、説明をちゃんとする

英語でpairing

• 基本的にはなにかを説明する側になることが多いのだが、英語で説明しつつコーディングが今のスキルだと難しい。問題のディスカッションはできる。日本語ではできていたので自分の基礎英語力が原因かと思う。

Cultivating team culture

• チーム内に聖人が多いので頼りがちだが、能動的に良い影響を与える必要がある。忙しさも原因の一つと考える。

Clear Notebooks degradation

• ユーザー増加に対するシステム変更、フロントエンドのReact化による障害の多さ
• Wordpressを雑に作ったつけがいっぱい回ってきた
• すでに施策はいっぱい策定してるのでとにかくやる時間の確保が必要

Try

• 仕事を選択・集中し、考える時間を増やす：ビジネスに貢献する中規模以上のタスクのみに集中する。インフラ管理は今やっているCDKの移行にとどめ、新規のタスクはチーム内のサポートのみにする。よい学習ができそうなタスクは移譲するようにする
• クリティカルな貢献チャレンジをする: 2020年はシステム的な貢献だったが、ビジネス的にクリティカルなものを達成する、忙殺されない状態で
• 英語pairingを問題なくできるように：オンライン英会話の継続、特にNativeの人との英会話を問題なくできるようにする
• チームの学習機会を増加させる：自分で手を動かすかわりによりチームにフォーカスし、こちらの芝はとても青いものだよという状態にする

NeoVim + coc-solargraph + docker

Neovimではcoc.nvimという便利なLanguage Serverがある。ruby用にはcoc-solargraphが使える。Rubyが古くてローカルへのインストールがめんどくさいなどの理由でDocker経由でsolargraphを利用するときの設定群を以下記す。Linuxを使っているとDockerがはやすぎて開発環境すらDockerで整えたくなる。

Dockerfile

FROM ruby:2.3.8-stretch

RUN gem install solargraph -v 0.38.0

ENTRYPOINT ["solargraph"]
CMD  ["socket", "--host", "0.0.0.0", "--port", "7658"]

$ docker build -t solargraph-2.3.8 .
$ docker container run -d -p 7658:7658 solargraph-2.3.8

cocs-settings.json

{
  "solargraph.externalServer": {
    "host": "localhost",
    "port": 7658
  },
  "solargraph.transport": "external",
  "solargraph.diagnostics": true,
  "solargraph.hover": false,
  "solargraph.checkGemVersion": false
}

ref:

Using the configuration file · neoclide/coc.nvim Wiki · GitHub

2019年振り返り

2018年はインフラ整備、台湾旅行、英会話の勉強などをした。2019年は副業の開始、２回の転職、英語環境で働き始めるなどをした。

副業

2018年まで2年半ほど勤めていた会社を副業という形でサポートした。在籍中エンジニアとしてはかなりやりきった感があり、開発やインフラ管理の方はジュニアエンジニアの成長の場として譲りたい気持ちがあったため。一方サービスの成長としてはまだ自分にできることが残っていると感じており、開発しているサービスのWeb版の成長に責任を持つProduct Manager的な立ち位置でサポートを始めた。

良い結果:

• 客観的に会社の良い点悪い点が見え、指摘・改善ができた
• エンジニアリングではなくサービス成長に主眼をおいた活動が実を結んだ
• エンジニアと結構いいかんじで協調できた
  • 熱く優秀な人が多いので基本ガンガンいこうぜで信頼してまかせている

特に今年は色々な施策が実をむすび、国内、国外の多くの学生が利用してくれるサービスになったといえるくらい成長した。現在はWeb版をよりユーザーの習慣に沿って使いやすくするために頑張っています。

副業開始直後つらかったこと（年末くらいには慣れた）:

• メインの仕事を終えてからのコンテキストスイッチに時間がかかりすぎる
  • クオーターはじめにCEOと相談し計画を立て、あとは実行するだけにする
  • クオーターはじめに細かな計画表を自分向けに作成しておく
• 休日が潰れる
  • 平日に分散する

課題:

• コミュニケーションの時間がどうしてもかかる
  • 開始時刻が平日夜や休日になるので時差のある働き方みたいな状態になる
• 常にアウトプットしている状態が続き、インプットに時間がとれない

副業は独身の方だとやりやすいと思うが、家庭を大事にしたい人にはあまりおすすめできないかもと自分は思う。時間って大事だなと再認識した１年でした。

転職x2

2019年は転職を2回した。

1社目:

前述の通り前職ではエンジニアとしてやりきったので、次の会社ではエンジニアとしてのさらなる成長を期待し転職した。メインとしてはRailsやRubyに関する仕事をしていた。優秀な方が多くgRPCを使ったプロジェクトなどに参加させていただいた。また後半はベトナムのエンジニア達と一緒に開発をした。ベトナムのエンジニアたちとは基本的に英語でのコミュニケーションとなるが、GitHubやSlack上での会話がメイン。

前職も台湾、タイ、インドネシア、アメリカなどの同僚と一緒に仕事をしていたが、どうもそういう環境のほうが自分にとって仕事がしやすいことを再実感した。ベトナムの人たちとの仕事はとても楽しかった。今でもFacebookでつながりがあったりして良い。

2社目:

とある理由でさらに転職をした。Node.jsに関する仕事をしている。今の会社は完全に英語環境で、多国籍な人たちとともに一日中英語で会話、ペアプロ、テキストでやりとりをしながら仕事をしている。なお入社時点ではTOEIC 850前後程度で、英会話は完全に苦手。幸い本当に同僚に恵まれており、つたない英語でもなんとかやっている。

これまで一度も英語圏の国に留学どころか旅行したことすらないので文化的な慣れが必要だなということを感じている。記憶が新鮮なうちに現在自分が感じている日本語、もしくは日本語環境での働き方との違いを記すと、

• 会話の速度と意思決定のスピードがはやい
• 会話をする際、自分である程度まとまった量の文章を話す必要がある。会話のキャッチボールというよりかは、主張をぶつけあうディベート的な？
• ストレスを感じているときは素直にストレスを感じている振る舞いをする

価値観は共感できる点が多く、働きやすい。

ランチのときには同僚と仕事以外の話をよくする。週末はどうだったか、クリスマスはどうするか、年末はどこにいくのか、など。2019年は忙しすぎてプライベート虚無だったので返答によく困る。2020年は楽しい生活も送っていきたい。

英語学習

2019年は時間のあるときはオンライン英会話サービスとしてDMM英会話とBizmatesの両方を利用していたが、現在はBizmatesのみ利用している。理由としては日常会話は普段からしているため、ビジネス英語を喋れるようになったほうが効率的だと思ったため。現在Bizmatesのレッスンでは自社サービスの紹介、自社の歴史の紹介など社外の人とオポチュニティを発生させるための英語を勉強している。しかし普段エンジニアとしてオポチュニティ的な会話を仕事で全く使わないことに最近気づいた。2020年はDMM英会話に戻そうかなと考えている...

2018年の目標

• Gemを5つつくる: GitHub - nanonanomachine/ruby_snooper: Poor man's debugger heavily inspired by PySnooper

• 英語学習を続け、夏から秋にかけてアメリカに遊びに行くときに快適に過ごす: 前述の転職でも触れた通りなんかすごいことになってしまった

• Clojure触ってみる: @meganehouser氏と Meguro.LYAHGGを開催しHaskellを学習中

• OKRがあれば達成する: 副業、3, 4Q以外は達成できた。全体的な成長的にはよかった

2020年の目標

• 年末にはネイティブの人に速度下げてもらわない状態でも会話できるようになる
• 家庭と健康を大事にする
• 仕事を楽しみながらLong termで学習し、成果を一つだす

第41回 Pythonもくもく会 TensorFlow Object Detection API メモ

第39回参加時の「Object Detection APIでドラえもんをDetectしたい」というテーマの続きを@meganehouser氏と一緒に取り組みました。2019年7月21日に行われた第41回Pythonもくもく会でのはなし。開催していただいたSQUEEZEさんいつもありがとうございます！

3行で:

• Amazon SageMakerからGoogle Colaboratoryに移行
• 寿司DataSetをつかってTrainしてみるとそこそこ
• ドラえもんDataSetをつくってTrainしてみたらいい感じ

何がしたいか

ドラえもんのObject Detection

著作物を著作者の許諾を得ず無断で利用していることがあります。 自分の関わっている会社の場合、人力でそのようなケースを検知しているのですが、 一定の有名な著作物を自動検知することで効率化できないかなと考え試しています。

何をしていたか

第39回では以下用いてためしました。

1. 学習画像収集: 独自スクリプト by meganehouser 400枚くらい
2. Augumentation: imgaug crop, horizontal flip, blur
3. アノテーション: VOTT、ラベル一つ(doraemon)
4. 学習: Amazon SageMaker, resnet-50

アノテーション方法：ドラえもんの全身画像

参考URL: https://dev.classmethod.jp/cloud/aws/sagemaker-umaibo-object-detection/

結果としては全然識別できず。敗因としては全身画像をアノテートしたことかと。

全身画像のアノテーション

ドラえもんの場合、服装、ポーズなどバリエーションがありすぎるため一定した情報をアノテートできていないと考えました。

何を今回やったか

1. 学習画像収集: https://github.com/hardikvasa/google-images-download 最終的には50枚くらい
2. Augumentation: なし
3. アノテーション: VOTT、ラベル一つ(doraemon)
4. 学習: TensorFlow Object detection, resnet-50

アノテーション方法：ドラえもんの顔画像

また今回はColaboratoryを使用しました。

Google Colaboratoryに移行

これまでは会社の研究用アカウントでAmazon SageMakerを使っていましたが、共同作業者が別の会社に所属しており使用できない点がありました。 手軽に共同編集できるGoogle Colaboratoryに今回移行し、Object DetectionもTensorFlow Object Detection APIを利用する形に移行しました。

ColaboratoryはipynbでNotebookを共有でき、かなり参考になる資料が多くそれらを参考に進めていきました。 具体的には以下

www.dlology.com

寿司DataSetをつかってTrainしてみる

有志が寿司のDataSetを公開してくださっているので、先程述べたTrainするサンプルにDataSet中のTFRecordを指定しTrainしてみました。

https://qiita.com/watanabe0621/items/0b1cfa2d89c8321767e2 https://github.com/Jwata/sushi_detector_dataset

大体1分/100ステップくらいの学習速度で1000ステップほど学習。

学習したモデルの評価

寿司DataSetは1.中トロ、2.サーモン、3.いわしの３クラスのデータになっています。 いくつかの寿司画像の検出を試してみた際、以下の性質があるように感じられます。

1. 単一種の寿司画像は検知できる
2. 複数種類の寿司画像が存在する際の検知が難しそう

sushi1

sushi2

とりあえず検知はできそうだぞ、ということがわかったのでドラえもん画像で同様のことをしていきます。

ドラえもんDataSetの作成

google-images-downloadを用い画像を収集しました

github.com

公式ではjsonを渡せばうまくいくそうですが、うまくいかなかったので以下のようコマンド引数を渡すことで解決

googleimagesdownload --keywords="ドラえもん"  --limit=1000 -o="output_directory" --chromedriver="location_of_chrome_driver"

前回と違い、今回はできるだけシンプルなドラえもん画像を利用し、なおかつ枚数は最初は少なくあとから増やしていく戦略にしました。 最終的に50枚程度に落ち着きました。

VoTTを用いアノテーションを粛々と行います。

github.com

今回は前述の通り、顔をアノテーションしていきます。

ドラえもんの顔をアノテーションする

その後.tfrecordを出力します。 以前は単一の巨大な.recordを利用されていたようですが、VOTTから出力すると複数の.tfrecordに分かれて出力されます。

Train&結果

Trainするサンプルでは単一の.recordを受け取ることを想定していますが、 以下を参考にNotebookを修正していきます。

Training object detection model with multiple training sets · Issue #3031 · tensorflow/models · GitHub

というわけで最終的にできたのが以下。 かなりコードなど汚いので公開していません。興味あるかたはメッセージください。

https://colab.research.google.com/drive/1tH-Uk4wm71LN8XolA80NdIbU96gb5YQi

結果

学習に使用していないデータを用い認識させてみます。

とてもいい感じ。特に最後の画像ではどらえもんが帽子をかぶっているのですが、それでもうまく認識できています。

うまく認識できなかった例

ビルをドラえもんを誤認識

ジャイアンをどらえもんと誤認識

誤認識はおそらくデータセットを増やすことで解決できそうだなとなんとなく感じました。

まとめ

今回以下の良い結果を得られました

1. 顔をアノテーションすることで認識精度が高まりそう
2. Colabolatoryを使うことで無料でGPUがつかえ複数人と共同作業ができる

アニメのキャラクターのキモとなる部分が顔で、顔をアノテーションすることでかなり認識精度がたかまりそうです。例えばアンパンマンなど他のアニメキャラクターに関してもこの傾向は同じな気がするので、これから別のアニメキャラクターでも試してみたいと思います。今回作業してやはりデータを集めることが大変だなというのは痛感しました。著作権をもつ会社がこういうことするとなんだか色々面白そうだよなと感じました。