ID:2138さん

3年後の目標や野望


自分の開発力で人生をコントローラブルにしたい

これまでUXデザイナー -> エンジニア -> マネージャ -> 開発系役員といろいろ経験してきたので、小さな会社を作って小さなチームで大きな仕事を実現したい。

年収評価シート

2013年/2年以上

freee会計の開発・運用

2013年に入社して以降、10年間一貫してfreee会計というSaaSサービスの開発に携わってきました。 また、2016年からはfreee会計開発チームのマネージャ、2018年からは会計、人事労務、モバイル、QA、CRE等プロダクト開発組織の開発本部長として開発組織や採用課題にも対処してきました。 マネジメントポジションになっても、コードはこれまでずっと書いてきていたのでそこは安心してください。 主な役割と成果 # Webの開発エンジニア(フロント/サーバ/インフラ) サーバサイドはRuby on Rails(と一部Golang)、フロントエンドはJavaScript->TypeScript + React、インフラはEC2->EKSという構成で開発していました。 規模としては、https://speakerdeck.com/waka/da-kinapurodakutofalseyu-tefang?slide=9 が参考になりますが、コード規模はサーバ/フロント共にこのスライドの1.4倍程度になっています ## 会計機能周りの機能開発(主だったもの) ### 会計データを結果整合で集計する 利用事業所が増えたことで、会計データを集計して表示する機能が軒並みパフォーマンスが大きく劣化。 (BS, PLといったレポーティング系の機能) そのため、元になる入出金データの作成/更新/削除時にあらかじめ中間集計データを作るように変更。 この際、入出金データのトランザクションが長くなったため、ロックエラーが頻発するように。 欲しかったのは、事業所単位で直列に処理しつつ、分散させる仕組み。 そこで、EventStreamベースのアーキテクチャに変更して、集計処理をトランザクションから別プロセスに分割するようにした。 EventStreamにはAWSのKinesisを採用。当時はマネージドのKafkaがまだ無かったこと、SQSのFIFOキューは書き込み数の制限を超えてしまうため不採用とした。 ざっくりした流れとしては、変更ログ -> fluentdのoutでKinesisに流す -> コンシューマで集計処理、という感じにしました。 ### Ruby版Kinesisクライアントライブラリ Kinesisのクライアントライブラリ(Kinesis Client Library = KCL)は公式から提供されているものがJavaベースのものしかなく、コンシューマをSpringベースで作りました。 WebアプリケーションはRailsベースで作っているので、同じリソースを複数言語で処理しないといけないことに不満があり、公式のspecificationを満たすRuby実装を作ってみました。 https://github.com/waka/kcl-rb 詰まったときや再起動した際の復旧のため、チェックポイントの管理にDynamoDBを使っています。 その後、コンシューマからRailsのAPIを叩くような形にしたため、kcl-rbを使うことはなかったのですが、 社内の共通基盤としてPubSubを作ることになり、上記リポジトリをfolkしたものを使っています。 ### 会計データ登録の自動化 リリース当初、クラウド会計であること以上の機能的な売りが欲しくて開発した機能です。 自動で経理というオンラインバンクの明細データと連携してルール+推測ロジックで会計データを自動生成する機能 銀行口座の明細の文言に対して、ルールベースのフィルタをかけて、マッチしたものを登録した内容で会計データを作るようなもの 前方一致、中間一致、後方一致等のマッチングケースが書けます ルールのパターンが将来複数になっていくことを考慮してストラテジーパターンで作りました 工夫したポイントとしては、明細データが数億件溜まっていってもインデックスを使い切れるように設計した点 ### 各種インポート機能及び基盤開発 初期の頃に他社サービスから移行する仕組みがなかったため、提案して開発しました。 他社会計ソフトからのCSVインポート。データ量や行単位のチェック項目が多くバッチ処理にて実装 他社のソフトが出してくるCSVがCSVの仕様を満たしていないものが多く、腐敗防止層を作って本当にCSVに変換するのが大変でした 数千行以上のCSVを1トランザクションでActiveRecord化するとエラー時にメモリを使い切ってしまうリスクがあるので、1行ずつコミットしてトランザクションを小さくしつつ、エラー内容をユーザーがわかるような仕組みにしました ### 権限管理の導入及び基盤開発 ABACな権限管理の仕組みを導入。後続のサービスでも使えるようにgemとして切り出せる形で実装 デフォルトの権限セット+ユーザーが自由に権限を設定できるようなカスタム権限という感じです。 その後、利用プランによっても権限を変えたいケースが出てきたため、ABACな権限管理フィルタも実装しました。 ### 申請ワークフロー機能開発 Googleフォームのような自由に入力パーツを組み合わせ可能なフォームに申請プロセスをくっつけられるものを作りました。 自由なフォームを実現するために非定型なスキーマをMySQL上に作って開発。 入力フォームごとのテーブルを作って、表示時に結合するような作りにしました。 申請プロセスは会計領域以外(例えば人事労務での労務申請等)にも使うユースケースがありそうだったので、Golang + gRPCベースのマイクロサービスとして切り出す作業も合わせてやりました ### Rails, Rubyアップデート Rails5, Ruby2.7まではほぼ自分がバージョンアップをしていました。 ほとんど自社のコード起因の問題でしたが、パフォーマンス劣化が起きた点については、Railsのissueに報告等するようにしています ### 数えきれない不具合対応 ジョジョではありませんが、たくさんやりました。 普通のエラーからイレギュラーなデータ修正や、パフォーマンス改善(主にクエリ)など運用系の課題は得意です(得意になりました) # モバイルアプリの開発エンジニア(iOS/Android) ## iOSアプリの立ち上げ 会社の忘年会にて社長からモバイルアプリを作りたいと言われ、1ヶ月でストア申請まで完了 当時モバイルアプリ経験者がいなかったため、一から技術選定+機能開発+リリースまで 外で登壇して採用プレゼンスを上げたいという狙いもあり、当時はまだ少なかったリアクティブな構成で作りました ## Androidアプリの立ち上げ iOSと同じく一から技術選定+機能開発+リリース 構成もiOSと合わせてリアクティブなレイヤードアーキテクチャを採用 # プロダクトチーム及び開発全体のマネージャ 2016年に会社に初めてマネジメントロールが出来たタイミングから8年間従事していました。 まだ売上が厳しかった時代から上場、上場後のグロースフェーズまで一通り経験しています。 開発面では、取り組んでいたことの一部は発表資料に記載している「大きなプロダクトの育て方」スライドに詳しく書いてあります。 スタートアップ時代からパブリックカンパニーになっていく中で、品質面でのマインドセットやサービス品質をユーザーさんから求められる水準まで、サービスの成長を止めずに改善できるかに頭を使っていたことが多かったと思います。 大きなトピックとしては、会計という割とクリティカルなサービスで決算データの集計に結果整合性なアーキテクチャ(裏側はAWS Kinesis)を採用したというものがあります。マルチテナント且つ複数ユーザーで同時編集されることが増え、ロックエラーが頻発していたことに対する対策としてやったのですが、結果クリティカルな不具合を出すこともなく、その後のユーザー増にも耐えていってくれている感じでよかったです。 組織面では、役割上採用面の貢献を求められることが多く、これまで1000回以上面接を行い、100人以上の中途エンジニアのオファーから受諾獲得までやってきました。 その他、組織が大きくなるなかでエンジニアの成長/評価軸の目線を揃えていきたくなったので、https://jobs.freee.co.jp/engineers/ のページに載っている「freeeの開発文化」というのを中途のエンジニアたちにヒアリングもしながら社内/社外公開しました。マネージャがフィードバックする際のポイントに使われているので、意外と根付いてくれてよかったです。

2009年/2年以上

kintoneのUI設計とフロントエンド実装

kintoneという業務アプリケーションをGUIで作れるサービスの開発に、UIデザイナー兼フロントエンドエンジニアとして、開発チームの立ち上げ時からリリースまで参加していました。 メンバーは自分とサイボウズラボにいたフロントエンドエンジニアの2名(その後1名新卒が加わった)でした。 このサービスの売りとして、アプリケーションをドラッグ&ドロップでパーツを簡単に配置できるというのがあったのですが、縦にも横にもパーツを配置できる必要があったため、パーツとパーツの間へのドラッグ&ドロップやパーツのサイズ変更が複雑でした。 また、当時のブラウザ事情ではあるのですが、IEでiframeを配置しすぎるとメモリーリークが起きる問題があったり、当時はブラウザ間でピクセルパーフェクトに揃えるのが大変だった記憶があります(ドラッグ&ドロップの実装ではブラウザ間でサイズをなるべく揃えたい)。 フロントエンドがリッチになった結果、JavaScriptファイルのサイズが大きくなりすぎたため、当時としては多分珍しいJSDocで型情報を書いてコンパイラ(Google Closure Compilerを使用)で最適化することで、ファイルサイズを抑える工夫をしていました。 すべての関数にJSDocで型情報を書ききると、Advanced Compileという最高圧縮がかけられるようになるため、頑張ってJSDocを全部書いていました。 当時のことをDevelopersSummitで発表したときの記事が見つかったので、見てみてください。 https://www.publickey1.jp/blog/12/uijavascriptkintone2012.html

マネージメント能力

このマネージメント能力は公開されていません

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
あり
Zenn アカウント
未入力です
Speaker Deck アカウント
あり
SlideShare アカウント
あり
特にアピールしたいアウトプット
あり

今後、身につけなければいけないと思っている技術は何ですか?

零細企業で自社サービスを作っているので、どうデータ分析するかの勘所を身に付けていきたい

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

信頼して任せてくれる環境

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
金融 / アダルト / 仮想通貨
その他の特徴
趣味は仕事 / 起業/創業期のベンチャーにいた
その他のやりたいこと・やりたくないこと

特に言語やフレームワークのこだわりはなく、使ったことがないものであってもすぐキャッチアップするので問題ないです。

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で40代中盤
好きな Text Editor
vim
希望勤務地
東京都 / 神奈川県
希望年収
未入力
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
SIGN UPSIGN IN


転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?