ID:72708さん

3年後の目標や野望


名の知れたプロダクトの開発に関わるか、面白いプロダクトを有名にして「あれは自分が作った」と自慢できるようになりたい

人に使ってもらえる、褒めてもらえる、そして自分が作ったプロダクトがお金を産むというサイクルによって自分もそのプロダクトを好きになれる、プロダクトを好きになれたらさらに良くなるようにもっと使ってもらえるように、開発を頑張るというエコシステムが完成すると思っているからです。「好き」「面白い」というのは何にも勝る原動力だと思いますし、もっと言うと継続的に開発を続けていかないといけない身として、自分の関わるものを「好き」「面白い」と思えることは必須だと思います。 具体的には、バックエンドエンジニアとして高トラフィックなサービスのパフォーマンス改善にチャレンジしたり、アーキテクチャを見直したり、技術的負債を返済したりすることで、要望される機能拡張を行う際のスピード感を高めたり、エンジニアリングマネージャーとしてそうしたことを組織として積極的に行える文化を構築したり、プロダクトマネージャーとしてユーザーの求めているものを分析してアプリに落とし込めるようアクションしていったりといったことがしたいです。 プロダクト・アプリがユーザーに喜ばれるようになることであればなんでもやりたいと思っています。

年収評価シート

2023年/1年以内

日程調整アプリ開発プロジェクト

## プロジェクト概要 ### 背景・目的 - 利用ユーザーと健康指導を担当する自社の医療従事者が面談を行う際、日程の調整において日程管理が手動になっており、50人以上と面談を行う医療従事者にとって大きな負担となっており、そこの業務負担を下げたいという話があった。 - 利用ユーザーには50代後半以降の高齢な方が多く、ITリテラシーが低いことが予想されるため、既存の日程調整ツールやSaaSで必要となるメールアドレスや名前の入力の際に離脱や打ち間違いが予想され、その調整で医療従事者の業務負荷がさらに増えてしまう懸念があったため、**自社のユーザーデータをうまく使うことで認証が必要のない日程調整アプリを自作する**という話が浮上した。 ### 規模感・チーム構成・担当した役割 - PdM1名、フロントエンド1名、バックエンド1名、デザイナー1名の4名で開発を行い、適宜医療従事者1名にステークホルダとして参加してもらっていた。 - 私はバックエンドエンジニアとして、要件の定義とバックエンドAPI開発およびインフラ構築に関わった ### 使用技術・開発環境 - バックエンドではGoを使用し、echoとgqlgenを使ってGraphQL APIを構築した。(※それぞれの役割については課題へのアプローチの項目で後述) - インフラはAWSを使用して、ALB+ECS+RDSの構成で作成した。 - また、既存プロダクトとの連携を行うためにVPC Lambda+APIGatewayを用いたREST APIの作成も行った。 - 構成は全てTerraformを用いて行った。 ## 取り組んだ課題とそれに対するアプローチ ### 課題 ビジネス課題としては以下のようなものがあった - 医療従事者はGoogleカレンダーで日程管理しているため、**Googleカレンダーと連携**したい - ユーザーのリテラシーを考慮し、**ユーザーが日程を提出する際の認証は不要としつつセキュリティは担保しなければならない** 開発課題としては以下のようなものがあった - 既存のAPIのインフラ環境はコンソールで作成されているか、その環境でしか使えないようなterraformコードになっており、参考にするにしてもAWSコンソールを毎回見に行く、terraformコードを都度新環境に読み替えるなどの手間がかかっていた - プロダクト間の連携が定期実行のバッチ処理依存となっており、開発当初の工数がなかったことのみがそうなった事情であるという話を社内でヒアリングできていたことから、**APIでのプロダクト間連携ができるように環境を整える必要があった。** ### アプローチ - Googleカレンダーを使用する際に必要なアクセストークンが取得でき、かつ認証周りの実装もカットできるGoogleログインを採用した。これにより、Google認証レイヤとGraphQL APIレイヤが分断されてしまったので、echoを使用しmiddlewareでこれら2つの橋渡しをすることでGoogleログインとGraphQL APIの両立を実現した。 - 認証については自社にユーザーのデータがあることを活かし、期限付きのトークンを発行しユーザーと関連づけることでセキュリティを担保しながら認証を不要とした。 - terraformコードを今後の新規開発の際の参考にできるように作ることを意識した。既存のterraformコードではECSとRDSなど大まかな構成のみコードかされていたが、このPJにおいてはVPCやサブネット、セキュリティグループなどのネットワーク周りやCodePipelineなどのCD環境も全て含めてterraform apply一回で構築できるように作成した。 - API GatewayとLambdaを用いて、プロダクトのデータをCRUDするAPIを作成して既存プロダクトとの連携にはそれを用いた。RDSアクセスのためにVPC Lambdaとし、コネクションが枯渇しないようRDS Proxyを用いた。またこれらをあらゆる環境で使えるように意識したterraformコードを作成した。 ## 成果 新規ツールを使って業務を改善するところまでいけないほどに医療従事者の業務負荷が高く、運用開始に至ることができていない。 しかしながら、アプリについては、トライアル段階で「面白いくらいに自動化できる」と高評価を得ることができている。

2023年/1年以内

報告書校閲プロジェクト

## プロジェクト概要 ### 背景・目的 - 医療従事者の業務負荷が高いことが課題となっており、中でも健康保険組合に提出する報告書の校閲業務に大幅に時間を取られているという背景があり、医療従事者の業務効率改善のためPJが立ち上がった ### 規模感・チーム構成・担当した役割 - PdM1名、PM1名、フロントエンド1名、バックエンド1名、の4名で開発を行い、医療従事者4名にステークホルダとして参加してもらっていた。 - 私はPMとして、課題のヒアリングからプロジェクトの立ち上げ、要件の定義と一部のバックエンド実装に関わった ### 使用技術・開発環境 - Go, Typescript, Vue.js, GraphQL ## 取り組んだ課題とそれに対するアプローチ ### 課題 - 校閲プロジェクトとして大きく一つのプロジェクトが立ち上がったが、状況をヒアリングしたところ、課題は大きく2つに分けられることが判明した。 - 社内システムで報告書作成 -> Dropbox共有ファイルで共有 -> 社内システムに戻って修正というフローが手間であること - そもそもの校閲業務に対し、かかる時間と質に個人差があること これら2つの大きな課題に対し、それぞれ社内システムの機能追加とGPT4の導入によって解決する方向で進めることになった。 ### アプローチ - 校閲機能の追加では、GithubのコードレビューとMiroというホワイトボードアプリをイメージしながら、報告書のプレビューに対しコメントを残せるような機能を検討。業務の実情に合わせて必要な機能のみに絞って実装をしていくよう意識した。 - 特定のメンバーに校閲業務が偏ることがないよう、校閲実績を可視化できる画面を追加するなど、管理者視点での機能作成も行った。 - AIによる校閲では、医療従事者が使いやすいものにできるかトライアルを行った。私の方でtypescriptを用いてGUIで文章を校閲できる簡易アプリをトライアル参加者に共有しフィードバックを集め、報告書のような厳格な文章が必要なシーンではGPT4でないと精度が足りないことがわかったためGPT4を導入する運びとなった。 - のちにこのAI校閲の企画はペンディングとなったのだが、トライアルで試し続けたことをサンクコストとしてしまいAI校閲を無理に実現しようとするというようなバイアスに陥ることなく事業インパクトを考えて別のPJ優先のためにペンディングを選択できたのは良かった点と言える。また、今後AIを導入する際のノウハウを社内に残せたことも大きかった。

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

マネージメント能力

校閲に関するPJ
校閲の業務を効率化し、医療従事者の業務負荷を下げる責務があった
当初AIを使って校閲をやってもらえばいいという仮説ありきで進められていたが、ヒアリングすると課題は単純にAI導入だけで解決できないことに気がついた。 報告書作成をシステムでやっていることからそのシステム自体の改修のインパクトの方が大きく、また校閲自体は報告書作成と同じ管理システムにその機能がないことは校閲業務のボトルネックになっていた。 AIを使うというそもそものアプローチから一旦白紙にし、フラットに何をすれば業務効率を改善できるかだけを見据えてやるべきことを整理しなおした。この一工夫がなければ校閲機能を管理システム内部に追加するという話は出てこなかったのでこの点が工夫できた点と言える。

バックエンドエンジニアチーム
少ないリソースでロードマップをなるべく多く遂行する必要があった
自身がやるべき箇所と、メンバーに任せるべき箇所について、メンバーの得意不得意を適切に認識し指示した。 ただ、毎度細かく指示してマイクロマネジメント気味になるとメンバーが指示を待ってしまうという問題に直面した。なので、指示や依頼をする際にはどういった背景でそれを他でもないその人に依頼しているかを可能な限り伝えるようにしたところ、別解でのアプローチをとってくれたりとメンバーの自走力が上がった。

アピール項目


アウトプット

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

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

マイクロサービスでの実装に関する知識(gRPCなど) 組織マネジメントのノウハウ (Goを使ったAPIを実装していく上で最低限必要な)TypeScriptなどフロント側の知識

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

裁量権が高い 思考・計画する際に縛りがない

キャラクター

直近で一番やりたいこと
マネジメント力を上げたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
未入力です
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
好きなプロダクトがある
やりたくない分野
SI / 金融 / 医療・介護
その他の特徴
レガシーな環境を改善できる / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと

- Go言語を使った開発がやりたい
- その他の言語のキャッチアップが必要なら、静的型付け言語がいい(Ruby, PHPなど動的型付け言語のキャッチアップはやりたくない)
- 短期でユーザーの需要を全て満たすプロダクトは作れない&長期目線での開発効率が静的型付け言語の方が高いと考えているため。たまに「言語にこだわりがある」と誤解されてしまうが、開発効率向上のための手段として型のある言語を採用したい思いがあるだけで根っことしては使う人のためを思っている

- マイクロサービスアーキテクチャで開発したい
- 事業は掛け算で強みをつくるもの。そういう事情もあって複数プロダクトがあるところではそれらを連携させることが多いと感じる。こうしたケースでプロダクト間の疎通を容易にするにあたってマイクロサービスは非常に有用だなと感じるシーンがこれまでの経験上多かったのでチャレンジしてみたい

やりたい事

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

基本プロフィール

年齢
今年で30代前半
好きな Text Editor
Visual Studio Code
希望勤務地
リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
700万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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