by ·0件のコメント
Ubie victory

2022年1月、Ubieにソフトウェアエンジニア (Site Reliability)として入社しました。入社して1ヶ月が経った今、Ubieに入社したきっかけや意気込みを書こうと思います。

マイクロサービス開発者からマイクロサービスプラットフォーム開発者へ

2018年9月、新しいお金のあり方を実現すべくリリース前のメルペイに入社しました。

freeeでの闘争を終え、メルペイで闘争します

はじめてのGo、GCP、Kubernetesなど、個々の技術のキャッチアップはもちろん、マイクロサービスの新規設計・仕様調整やテックリードとしての意思決定・チームマネジメントなど、精一杯背伸びする毎日でした。

テックリードとしての闘争

2020年1月、メルカリのMicroservices platformチームに異動しました。メルペイでのマイクロサービス開発経験を活かし、メルカリグループ全体でマイクロサービスをより開発しやすくしたいという思いからです。

1つの施策の影響範囲が数百ものマイクロサービスに及ぶ、とてもやりがいの大きい経験の連続でした。

また、在籍期間中は、海外やプロポーザルの必要な大規模なカンファレンスでの登壇、憧れのServerlessDays Tokyo/Fukuoksでのワークショップ開催、雑誌への寄稿や単著の商業誌発売など、はじめて尽くしでした。

自分だけでは手が届かないかもしれない挑戦のすべてを力強く後押ししてくれた組織、文化、驚くほど働きやすく従業員思いな制度、たくさんの強く優しい同僚には感謝してもしきれません。

とりわけプラットフォームエンジニアリングやそれを実装するチームは大好きで、何年も働いていくつもりでした。

人生を問う

2020年から2021年にかけ、業務上はメルペイからメルカリへの異動があった一方、日常生活はコロナ禍で激変しました。

リモート前提の勤務になり、住む場所も「会社に通勤しないのなら、日本のどこに住みたいか？」とこれまでと違った前提で考えました。現在の志向性においては足立区が最強という結論に達し、充実したサウナ生活を送っています。

エンジニアとしてキャリアの中で相対的に経験の浅いインフラ・SRE分野での修行的意味合いで取り組んでいる複業も、生活スタイルの変化が後押ししてくれた部分が多かったです。

複業SREとして広げる課題解決の幅と深さ。期待値以上の成果を上げるまでに何をしたか

さらに、「働かなくてもよいとしたら何がしたいか？」という問いに対して出てきた答えは「コンピューターサイエンスが学びたい」でした。働くのをやめなくても挑戦できることを知り、オンラインで3年半かけて学んでいくことにしました。

文系学部卒からGeorgia Techコンピューターサイエンス修士課程への闘争

大学院に出願するにあたって、志望理由書を書きました。必要とされる項目を書き上げるには、過去に学部で学んだことから現在に至るまでの学問・キャリア上の振り返りや、将来に思いを馳せることも不可避です。

キャリア上の損得勘定抜きで、単純にコンピューターの仕組みを学びたいというのが本音です。しかし、誰に強いられるものでもなく好んでプラットフォームエンジニアリングを行っているので、大学院ではコンピューターアーキテクチャー、OS、分散システム、クラウドコンピューティングの実装などを学ぶComputing Systemsを専攻し、ゆくゆくはGCP、AWS、Azureなどのクラウドそのものの中身を開発・運用できるエンジニアになりたい。そこに嘘はないし、この先転職するとしたらそういう会社だと思っていました。

では、クラウドを開発・運用できるようになった先に待っていること、それらを通じて自分が成し遂げたいものは一体なんなのでしょうか？自分が技術力を向上させてキャリアを積んだり、会社に貢献した結果、社会になにが残せるでしょうか？

日々クラウドを利用したさまざまなサービスが生み出され、人々の生活を支える基盤のひとつになっています。これに携わるのは、想像するだけでもワクワクします。問題解決する人が自律的に活動するためのプラットフォームを作るというのは、エンジニアになる前から持ち続けている明確な意志です。

一方で、クラウドの中の方含めいろいろな方とお話する中で、関わりたい事業領域はかなり限られていることに気づきました。特に、あらゆる人生にとってクリティカルな健康・医療領域です。歳を重ねるにつれて自身や家族の健康・医療に対する関心は高まり、コロナの猛威が世界の人々に与えた影響の甚大さが拍車をかけました。

新たな闘争の場としてのUbie

健康・医療といっても、エンジニアとしてどのような関わり方ができるのでしょうか。事業ドメインの土地勘があまりなかったので、以前GCP関連で助けてもらったUbie SREの@sakajunqualityのMeetyで話を聞いてみることにしました。

システム的には馴染み深いもので、プラットフォームエンジニアとして貢献できることがありそうでした。他にも、@nantani4にシンガポール事業の話を聞いたり、元同僚の@syu_creamに組織・文化について聞いたり、@empitsu88に学業との両立について聞いたりしました。

それと同時に、Ubieの事業・組織関連のnote記事やメンバーによるおびただしい数の入社エントリーを読み漁ったり、共同代表エンジニアの@quvo_ubieによるdevchat.fmを聞いたりしました。

Ubie Discovery カルチャーガイドに明文化された驚くほど鮮明な文化はさることながら、直接聞いた話や情報発信の姿勢そのものに狂気を感じました。

自分もユーザー（患者）として家から触れるサービスであるユビーAI受診相談は、妻の健康に大きな影響を与えました。これまで、「疲労」や「ストレス」に起因するのではないか以上の情報が得られず、ネクストアクションがとれず苦しんでいた症状に関連する病気の名前がわかりました。さらに、直接関係ないと思っていた別の症状とも重なったり、診てくれる近所の病院も提示してくれたりしたため、つぎの一歩を踏み出すことができました。医療機関の外で決まってしまう受診タイミングやマッチングへのアプローチは新鮮でした。

選考過程でも事業について話を聞き、患者のみならず身近な診療所や医療機関、さらには製薬企業も視野に入れて医療の全体最適を実現する構想に興奮を覚えました。

テクノロジーで人々を適切な医療に案内するというミッションを実現するための事業、戦略やそれらを推進するための組織と組織制度4本柱（ホラクラシー、スクラム、OKR、評価制度）は緻密で、みんなでより大きなことを成し遂げられそうです。

実際入社してみて感じたギャップは、想像以上にオンボーディングが手厚かったことくらいです。それだけ一人ひとりが事業の経営者たり、組織を運営し、文化を体現する難易度が高いということでまだまだ修行が必要そうです。しかし、それを乗り越えればもっともっともっと楽しくなる、夢中になるという確信があります。

ホラクラシーの特性上、プラットフォーム作りとそれをユーザーとして利用しプロダクト開発するのを行ったり来たりしやすい点も魅力的です。

まだまだ話は尽きませんが、ご興味を持っていただけた方はぜひMeetyでお話させてください！

そしてオマケの例のリストです！

by ·0件のコメント

freeeでの闘争と謝辞

2018年7月末を最終出社日としてfreeeを卒業します。

2015年1月に入社して以来、社内外関係なくいろんな人、コミュニティ、組織にお世話になりました。

freeeには職業エンジニアとしての経験のない僕を受け入れ、特に最初の1年くらいは自分でも引くくらい成長速度が遅かったにも関わらず見放さずに育ててもらいました。

やる気以外何もないところから、よい会社に移ってよい給料がもらえる程度の1人のエンジニアを育てる環境を提供できてそれだけで死ねる

長生きして欲しいですが、こんなこと言って送り出してくれる会社他に無いと思います。言われた後トイレで10分くらい泣いてたのは内緒です。

エンジニアとして育ててもらったのはもちろんなのですが、それ以上に学びが大きかったことがあります。それは愚直に課題に向き合って価値を届けるということとそれに必要なマインド（freeeでは価値基準という）です。

僕はコードを書いたり勉強したりするだけで楽しいし、力がついていってるような錯覚に陥ってしまいます。ただ、その結果として何が解決される？本当にそれは解決されるべき大事なこと？は常に考えないと、何をするにしてもよい流れにならなかったり、求める結果を得るのに膨大な時間がかかったりでうまくいかなかったです。

手段自体楽しいと思える方が人生楽しいとは思いますが、だからこそ一層意味のあるものにしたいという願いのような意味合いでもあります。

エンジニアとしても（働く、あるいは世の中に価値を届ける）人としても大事なことを学ばせてもらったfreeeに出会えて本当によかったし、今でもfreeeが大好きです。

そんな状態でもfreeeを去るのは、自分が届けたい価値に向き合った結果です。

これまでfreeeで対峙してきたデータや自分のお金に対する考え方（捕らわれ方）、これまでとこれからのお金が表現するすべきもの、価値の表し方を考えていたときに9月から働くメルペイのビジョンに出会いました。

メルペイが実現しようとしていることはまさに自分が解決に携わりたい思う分野での大きな社会的課題の解決です。

これまで扱ってきた技術スタックとはまた異なりますが、freeeで身につけた課題に向き合う姿勢を忘れずに価値を届けます。

約3年半、本当にありがとうございました。

これは例のリストです。

ふりかえり

新しい開発組織や自分がそんなに触れたことが無い技術になるべく早くキャッチアップできるように、freeeで携わったプロジェクトを出せる範囲でふりかえります。

Web

青色申告承認申請書メール送信サービス

入社3ヶ月目くらいのとき初めて自分メインでリリースしたサービス。今はもう別のサービスが包含してるのでありません。

リリース期限がどうしてもずらせないときは他の変数で調整してなんとかやり切るしかないというのを学びました。

電子証明書連携アプリ（Windows）

対応口座拡大と品質向上

入社7ヶ月くらいのときに電子証明書ログイン対応1行のときにWindowsデスクトップアプリを引き継ぎました。

まだRubyも覚束ない中、C# + Visual Studioに初めて触り対応口座数を増やしていきました。

  • 拡張できる設計とリファクタリング（当時テストは…）
  • 防御的プログラミング（確実なこととそうでないことの切り分けと制御）
  • ログ
  • エラー通知
  • サポートチーム、セールスチームと協力しながら問題解決
  • 優先順位、割り切り
  • 目の前の技術を一歩引いてみる（技術的マイノリティプロジェクトで幸せに過ごすための5つの方法）

を身につけました。

当初他のプロジェクトやりながら半稼働、という状態が1年弱あったんですが、社内的に知見があるわけでもなかった技術を身に付けるには思い切って全投入するのが真っ当なやり方だったみたいです。

この会社でC#…みたいな迷いも大きかったですが、何人の方にもアドバイスを頂いた通りまずは自分の目の前の技術をしっかり身につければ応用も効くから頑張れという言葉を信じ頑張ってみました。

あと、技術単体で解決できないときには他のチームの協力を得てできることもあるというのは大きな学びでした。

価値は技術だけでは届きません。

このプロジェクトだったり、得た知見を他の分野にも活かすことで大きな成果に繋がりました。

アプリ + Web UX改善

デスクトップアプリの品質がよくなってきたところで、本来使うと作業が効率化できるはずのユーザーさんに存在や利便性に気づいてもらえなければ意味がありません。

  • 問い合わせ内容分析
  • KPI設定
  • ユーザーさんへのインタビュー
  • サポートチームへのDemoやFAQ共有
  • Webの導線やアプリの使い勝手の改善、リニューアル
  • 保守しやすいコード（しにくいコード）

などを通して、Web上で登録する導線から問い合わせしてくださったユーザーさんに価値が届く（トラブルシューティングを含む）までの全フロー（の中で効果がありそうな順）に対して施策を打ちました。

サポートチームとの知見共有は（もともとの仕様共有が甘ければ）目先のやり取りが減りプロダクトの改善に割ける時間が増えます。駄菓子菓子、その後は問い合わせが減ったとしても

  • サポートチームのメンバーがユーザーさんからの問い合わせに精度高く答えてくれて単にエンジニアまで届く声が減ったのか
  • 「改善」の結果ユーザーさんが離脱してしまっていないか

など目に見える現象だけで判断せず、何か数字がよくなる代わりに他にしわ寄せが及んでいないか、本当に改善したいものは改善できているか、改善そのものの数値化が難しくてもなんとか可視化できないか、その数値が妥当かどうかベンチマーク取れないかなどいくつか考える必要がありました。

プロダクトマネジメントの文脈での「解決すべき課題に向き合う」を実感する日々でした。

この本にとてもとても影響を受けました。

Inspired: 顧客の心を捉える製品の創り方

プロダクトにどういう立場で関わるにしても忘れてはいけない視点として肝に命じています。

あと、改善の過程でフロントに保守しづらいコードを結構足した自覚はあるものの、じゃあどういう設計だったら保守しやすいんだみたいな理想形が全く見えませんでした。

そこからよい設計とは？を考える、学ぶ、意識して書く時間が増えました。

パフォーマンス改善

Windowsアプリといえども、サーバーサイドは他サービスと同じくRailsのサーバーです。

C#を書きつつ、サーバーサイドで必要な修正も行なっていました。

利用してくださるユーザーさんが増えるとAPIサーバーに問題が出て段階的に対応していきました。

非同期化の過程で色々と学びがありました。

  • 時間とコストを考えて段階的に理想的なアーキテクチャに近づけていくやり方もある
  • 問題に対する打ち手を複数考える（※結論ありきの比較にしてはいけないが、自分の推しは持つこと）
  • AWS Lambdaをきっかけにインフラを含めたアーキテクチャ（特にサーバーレスアーキテクチャ）に興味を持った
  • PaaSへの抵抗（食わず嫌い？）が激減
  • OSSヘのコントリビューションのきっかけになった

自分が携わるプロジェクトに対して新しい技術をまるっと（？）導入したこともなかったので大きめの粒度で設計・導入することは考えることが多い分学ぶことはめちゃくちゃ多かったです。

電子申告アプリ（Mac）

すでにリリースしているWindowsアプリのMac版を作って明確な期日までにリリースするプロジェクトです。

Macアプリ開発の知見が社内に無い中、色々なことにチャレンジしました。

Windowsアプリ資産を活用するためにXamarin.Macを採用し、技術検証期間も取りつつチームリードとしてプロジェクトマネジメントするなどです。

  • アジャイル風プロジェクトマネジメント
  • コミュニティから力を借りること、貢献すること
  • CI/CD環境作り
  • ビルド、コンパイル入門

リリースにこぎつけただけでなく、結果的に日本マイクロソフトさんの事例掲載、大型イベント登壇、商業出版（共著）、Microsoft MVP受賞、福岡やシアトル出張などこれまでになかったくさんの機会に恵まれました。

アジャイルはこの本にだいぶ影響を受けました。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アカウントアグリゲーションエンジンのリプレース

2018年はC#を完全に離れ、この記事にある「アカウントアグリゲーションエンジンのリプレース開発」に携わっていました。

Goも利用するプロジェクトで、2週間くらいGoも書く期間はあったものの、だいたいRubyを書いて過ごしました。

かつあまり読み書きできなかったRailsのコードやRspecも昔よりは理解できるようになっていたり、改めて追い直してみると理解できたり最後の最後まで発見が多い毎日でした。

  • 昔読めなかったコードが今も読めないとは限らない
  • データ移行に必要な計画とシミュレーション
  • 防御的プログラミング（困るデータができる前に徹底的に落とす、ロールバック）
  • テストと設計のよい関係（？）
  • インフラ構築やWebアプリのデプロイフロー

この本に出会って設計良くなったかはわかりませんが、Rubyの文脈でpublicメソッドとしてクラスが持つべき責務は何か？を考えることでテストがとても書きやすくなり、テストに助けられたことも何度もありました。

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

あと、個人的にGoに興味をもち、コマンドラインを作ってみたりAPIを書いてみたりもかなり楽しかったです。

コマンドラインを作ってみることでコマンドラインを使うときもどう使って欲しいかちょっと理解が及ぶようになったり、シェルスクリプトが書きやすくなったりいろいろいいことがありました。

教訓

最後に、自分がエンジニアとして働く上で今のところ注意したいなぁと思うポイントをまとめます。

デバッグ環境できるまでが環境構築

  • とりあえず対象のサービスがローカルで実行できるようになった、で環境構築を終えたことにしない
  • コーディングとテストを含むフィードバックサイクルを効率的に回せる状態にすることに最初に一気に投資する
  • 同じ文脈でIDE、エディタの使い方は暗記する、できる（使いこなせる）ことを増やす時間はとり続ける

担当する（マイクロ）サービスは全部追え

  • エントリーポイントへのアクセスからそれが返るまで
  • コードを増やしてからデプロイが終わって稼働するまで（デプロイスクリプトや設定を含む）
  • 依存するライブラリ
  • サービスの基盤の性質
  • どう動くかわかるが意味がわからんならドメイン知識を聞くか調べる

本当に無駄なことはするな

  • 議論のための議論
  • 議論したことは残して立ち帰れる状態にする、前提を必ず書く
  • 登壇のための登壇
  • 2回くらいキー連打したり面倒に感じたことはショートカット覚えたりするために立ち止まる
  • 適度に無駄っぽいことはする、脇道にそれる

思い上がるな

  • 時間を空けて読んだコードが読みやすいと思ったとき、自分が成長してるかもしれないし、自分の知らないところで他の人がいい感じに直してくれたのかもしれない（git blameしろとかそういう話でない）
  • 読みやすいと思って書いたコードもきっとそのうち…
  • 自分が過ごしやすいなと感じたとき、その環境を作ってくれた人がいる
  • いいものは偶然発生するかもしれないけど大体は誰かが作り、そういうものであり続けるように維持してくれている

by ·0件のコメント

ちょっと前の話になりますが、4月〜5月にかけてメルペイさん主催のGopher道場#1に参加し、2回LTしました。

業務で1〜2週間Go言語を触ったときのなんとも言えない幸福な日々がきっかけでGoもっと書きたい学びたいと思い参加することにしました。

※Go触ってない他の日々が幸福でないとは言ってない

講義を聴き、次の講義が期限（？）の宿題を解きながら、うんうん完全に理解したと思っていたことがいざ手を動かしてみると理解できてないことを実感する、というのを繰り返しました。

Goで作り直すgitignore生成コマンド

宿題は指定仕様のCLIやサーバーを書くものもあれば、hogehoge interfaceの意義など説明する系のものもありました。

その中でio.Writerを調べていると、自分もそれ使って書きたいという気持ちが高まり書いたのがこちらです。

toshi0607/gig

generate (or output) .gitignore using github/gitignore

.gitignoreを生成するためのコマンドです。

Usage:
  gig [OPTIONS] [Language]

Application Options:
  -l, --list      Show list of available language
  -f, --File      Output .gitignore file
  -q, --quiet     Hide stdout
  -v, --version   Show version

Help Options:
  -h, --help      Show this help message

もともとgiboというシェルスクリプトベースのコマンドがあったのですが、

  • git cloneベースでなくて、毎回最新のファイルをgithub/gitignoreから取得したい
  • コマンド書いたことない（Gopher道場の選考課題で初めて書いた）のでGoで一から書いて配布するところまでやってみたい
  • io.Writer interfaceを活用した柔軟な出力差し替えを体験したい

という動機のもとで書きました。

まだ機能比較でもgiboに追いついてないのはありますが、どちらかというとｼｭｯとリリースするためのスクリプトを準備する方が時間がかかった気がします。

https://github.com/toshi0607/gig/tree/master/scripts

このあたりの組み合わせです。

Gopher道場の最終回でLTする時間をいただけたのでお話してきました。

Goのinterfaceを使って外部サービスに依存しないテストを書く

AWS Lambdaが好きなので、今度は何かAPI書いてみようということで書きました。

toshi0607/release-tweeter

API to tweet the latest release tag version using AWS Lambda(Golang) & API Gateway

コマンドをアップデートするときに、そのコマンドのGitHubリポジトリの最新タグを拾ってきてtwitterに投稿してくれると楽だなぁと。

いかにも既存の何かしらだったり、連携機能やサービスで実現されてそうですがその辺は気にせず…

テーマはAWS Lambda使うという大前提がありつつも、

  • API GatewayとAWS Lambdaをローカル実行する
  • SAMのCLI使ってデプロイしてみる
  • direnv使ってみる
  • 外部サービスに依存する部分はモックしてテスト書く

というのを試してみたかったのでそうしました。

その最後の1つについてGopher道場#1 LT大会でお話してきました。

このLTについてはつぎのようなツッコミをいただいてます。

  • 「差し替えたい対象が複数になったら困る」が正しいのであれば、関数使うのがアンチパターンになってしまい、全部interfaceにすればいいよね？ってなる
  • 処理の差し替えであれば関数でいいし、抽象として扱いたいのであればinterfaceにすればいい

処理の差し替えであれば関数でいいし、抽象として扱いたいのであればinterfaceにすればいい、大賛成です。

差し替え対象が複数になっても困りはしないと思いますが、もし差し替えたい処理が増えてバラバラ1つずつ入れ替えないといけない状況になったら依存するサービスごとinterfaceで抽象化してしまった方が見通しいいかもくらいのテンションで当日はお話していました。

ただ、タイトルを「結論」としてinterface使わない方法はよくないみたいな資料の流れになっているのは間違いないので、資料単体で見返したときにも誤解を生まないかという観点でも見直すなり、資料に表現しきれない部分も記事にするなり改善方法はあるなぁと反省しています。

コメントいただけるのはとても嬉しいです。

振り返り

コードを書く

Gopher道場の影響を大きく受け、これも作りたいあれも作りたいみたいな思いが沸くことが増え（？）GitHubの緑化が進みました。

READMEしか直してないみたいな日もありますが、「作りたい！」ありきでその中で試したいこと、テーマがあるくらいのテンションだと愛着も増すし、手も動くのでいい感じです。

コードを読む

（すでにあるかどうかを度外視して）そのとき作りたいものを作ると大体選考実装や要素技術の実装例はGitHubに転がっているので、個人開発の文脈で人のコードを意識的に読む時間が増えた気がします。

これまではtwitterなどで流れてきた人気リポジトリをなんとなくたどることが多かったですが、自分が知りたいことを探しながら追うと吸収度や感情の振れ幅が変わりました。

発信する

これまでMicrosoft系のコミュニティでしか話したことがなかったので、今年はその外で話すというのが隠れ目標でした。
https://speakerdeck.com/toshi0607

発信する内容としては自分が初めて対外LTしたときみたいに特定技術（サービス）の使い方をなぞる系はやりたくないと思っています。

やるメリットももちろんあると思いますが、技術力をつけるという観点では

  • 何かしらの課題を解決すること
  • 何かをテーマに作りきること

を最重視すべきと思っていて、その過程自体や困ったこと、うまくいったことの言語化・発表を通じより前進できると考えます。

5月に行った2つのLTはたとえ入門レベルの内容であったとしても、信念は貫いたのでよい経験をさせていただいたなぁと思っています。

次はgolang.tokyoで発表できるか？と言われたらとてもハードルを感じているのが正直なところなので作りたいもの作るなり、解決したい課題を解決するなり積み重ねていこうと思います。

次

「こんなことやりたいと思っている」を書くと、書いたことで満足してしまう節がなくはないですが追い込めもするので書いてみようと思います。

Serverlessconf Tokyo 2018

去年参加してとても楽しかったので今年も参加しようと思っています。

ただ、今年はLTしたいなぁと。

CFP受付中ですが、それは尻込みしています…

サーバーレスなアーキテクチャの認証・認可どうやればええねんって思っていて、追っかけてると楽しくなってきたのでその辺の話をする予定です。

もちろんサンプルコードはGoで！

技術書典

前回はレビューと当日の売り子だけ参加で多少寂しかったので、今度はしっかり書きたいなぁと思っています。

技術書典3の『Extensive Xamarin』は強い方々におんぶに抱っこ感がすごかったので、今度はサーバーレスシングルページアプリケーションチュートリアル的な感じで丸っと自分の力で書いてみたい！

rejectされてもnoteで販売するぞ！