t-keshi

自己推薦一覧

自己推薦はありません

3年後の目標や野望


「エンジニアという枠に留まらず、とにかく良いプロダクトを作れる人」というのが目標。

プログラムが正しく綺麗に書けているというのはもちろん大事で欠かせないことだが、それだけでユーザーが使ってくれるわけではない。 ユーザーが本当に欲しているのはどんなサービスか、どうしたら使いやすくなるかチームで悩み、四苦八苦しながら、本当に良いプロダクトを作りたい。

年収評価シート

2020年/1年以内

Web問診票

### プロジェクト概要 このプロジェクトは歯科医院向けに問診票の作成機能を提供し、予約時に患者さんのメールアドレス(またはSMSやネイティブアプリ「私の歯医者さん」)を通じて問診票を送付できるサービスである。 ### 人数 フロントエンドエンジニア2名(自分を含む)、バックエンドエンジニア2名、プロダクトオーナー1名。 フロントエンドを担当した。 ### 使用技術 Amplify, Apollo, GraphQL, graphql-codegen, TypeScript, React, ContextAPI + useReducer, emotion ### 課題1-ドラックアンドドロップ 【背景】 操作性の観点から、問診票の個々の質問項目の順番をドラックアンドドロップで入れ替えらるようにしてほしいという要望が上がっていた。プロジェクトの納期を考えると、ドラックアンドドロップによる入れ替え操作の機能をいちから作る時間はなかった。 【取り組み】 GitHubのスター数、ドキュメントの整備具合、ReactHooksへの対応の有無などの観点から総合的に判断し、ReactDnDというライブラリを用いることでドラックアンドドロップでの入れ替え機能を実装した。さらに、ホバーした時に{cursor: 'grab'}当てるなど、操作性の面でも工夫を凝らした。 【結果】 この問診票はGoogleFormにも近いUIを実現し、医院様からも他社製のものよりも使いやすいという喜びの声をいただいた。 ### 課題2-複雑なデータ構造 【背景】 問診票のデータは、①1つの問診票が複数の質問を配列で持つ、②各質問は回答形式のタイプ(短文、長文、ラジオボタン、チェックボックス)と、選択肢がある場合には選択肢を配列で持つ、③各選択肢は選択肢とともに、フリーフォーム(その他、病名を記入(”ここがフリーフォーム”))をネストしたオブジェクトで持つことができる、という三重にネストした複雑な構造を持っていた。 【取り組みa】 こうした複雑な構造を持つ問診票を作成するため、フォームのstateをContextAPI✖️useReducerというReduxライクな状態管理の仕組みで管理した。さらに、ネストの深いデータをimmutableに変更する際にコードが冗長になるのを避けるために、immerを活用した。 【取り組みb】 データの複雑さによってバグが生じたりコードが難読化するのを避けるため、型安全性について心を配り、型がドキュメントの役割を担うようにした。また、graphql-codegenを用いてAPIからTypeScriptの型を自動生成することでAPI周りの型の記述ミスを防いだ。 【結果】 データ構造は複雑であるものの、データの流れを単方向で動きの把握しやすく、型安全な設計にすることができた。Web問診票ではリリース後も継続的に機能追加の要望が上がったが、この土台があったため改修が容易になった。

2021年/半年以内

MedicalBox

### プロジェクト概要 このプロジェクトではVue.jsで書かれた画像管理機能をReactにリプレイスした。 歯科治療の過程で撮影する口腔内の写真を管理しやすくするサービスである。 ### 人数 フロントエンドエンジニア3名(自分を含む)、バックエンドエンジニア2名、デザイナー1名、プロダクトオーナー 1名 フロントエンドを担当した。 ### 課題1 -コンポーネント化 【背景】 旧版は短納期の中で急ピッチで作成された経緯があり、1つのファイルに膨大な量のコードが詰め込まれ、見通しが悪いものだった。メンテナンスしやすく書き直すことが求められた。 【取り組み】 Reactの流儀に基づいて、UIをコンポーネントの階層構造に落とし込むことからはじめた。 例えばCardImageとCardActionButtonsからなるCardのコンポーネントを作成し、それをImageListPageの中でmapするといったように、役割の詰め込まれすぎたコードを、単一の責任を持つコンポーネントに切り分けていった。 【結果】 影響範囲が特定しやすく、機能追加・改修の手を入れやすい構成になった。 ### 課題2 -単体テスト 【背景】 既存の仕様を壊さないでリプレイスすることが難しかった。写真を組むレイアウトを変更する機能や、組んだ写真を単一のJPGに変換し出力する機能などロジックが多かった。 【取り組み】 開発された方に旧版の仕様について確認しながら、Jestでその仕様を満たすテストを書いた。そのテストが通るように実装していった。 【結果】 仕様がテストコードとしてまとまり、メンテナブルになった。バグは0というわけではなかったが、致命的ではないもの1つに留めることができ、堅実なアプリケーションがリリースできた。

2021年/1年以内

ユーザーサービス

### プロジェクト概要 このプロジェクトは、歯科医院の経営者がシステム上でスタッフの権限管理をできるようにするプロジェクトである。 ### 人数 フロントエンドエンジニア1名(自分を含む)、バックエンドエンジニア1名、デザイナー1名、スクラムマスター1名、プロダクトオーナー1名。 フロントエンドを担当した。 ### 課題1-デザイン 【背景】 同様のシステムを作っている他社と比較して、ストランザのシステムは機能が多いものの使い勝手が悪いという声もあった。一方、デザインチームは発足したばかりであり、デザインの改善フローは確立されていなかった。 【取り組み】 デザインに統一感をもたせつつ実装のスピードを上げるためmaterial-uiを導入した。さらに、Storybook+chromaticという環境で、継続的にデザインをブラッシュアップしていけるワークフローを構築することを狙った。 【結果】 フロントエンドエンジニアの実装したUIはデザインチームによってレビューされ、アジャイルに改善されるという仕組みづくりをすることができた。新しい仕組みの導入により、例えばバラバラだった色の使い方には、プライマリカラー/セカンダリカラーといった名前が付けられ、色数が絞られ、整備された。待機中のUIは、スピナーからスケルトンに変わり、ストレスの少ない快適なものになった。 ### 課題2 -バグ監視、エラー対応 【背景】 バックエンドではNewRelicを用いながらバグ監視を行なっていたが、フロントエンドではそうした仕組みを導入しておらず、QAが上がってきてから修正する後手の対応となってしまっていた。 【取り組み】 NewRelic, DataDog, Sentryなどのバグ監視・ログ管理のSaaSを調査し、収集できるログ・料金体系・サポートなどの観点から比較・提案した。チームのリーダーとの話し合いの上で、バグ監視システムをDataDogに統一した。さらに、ErrorBoundaryを用いて、エラーが発生したリクエストのパタメーターやスタックトレースなどのエラーの詳細なログをData Dogに送りつつ、真っ白な画面になる代わりにフィードバックを表示する仕組みを実装した。 【結果】 バグが上がってくるよりも先に、エンジニアがそれに気づき対応できる環境を構築することができた。また、フロントエンドにもエラー監視を導入することで、どのようなケースでエラーが発生しがちなのかナレッジを蓄積し、今後の開発に役立てることができるようになった。

マネージメント能力

アピール項目


アウトプット

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

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

## デザイン デザイナーさんと良い連携を取るためにはある程度デザイン工程への理解が必要だと感じている。 Google UX Design Certificateを使って、デザインを勉強中。 ## AWS Amplifyは業務で使っているが、サーバーレスなフレームワークへの理解はまだ弱い。 AppSync, DynamoDB, Cognito, Serverlessという技術スタックで個人開発を計画中。 ## 伝える力 他部署との連携をスムーズにするため、ファシリテーションや説明のスキルを高めたい。 最近は、zennと技術ブログでの発信をはじめ、説明力の向上を図っている。

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

- うるさすぎない環境(普通の話し声などを大丈夫) - リモートワークはマストではない

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 企画立案力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
好きなプロダクトがある
やりたくない分野
未入力です
その他の特徴
使用言語にはこだわらない
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で30代前半
好きな Text Editor
Visual Studio Code
希望勤務地
埼玉県 / 千葉県 / 東京都 / 神奈川県
希望年収
450万円以下
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
t-keshi
今年で30代前半
Visual Studio Code
参加ステータス
不参加
参加回数
2回
累計平均提示年収
543 万円
SIGN UPSIGN IN


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