ID:2020さん

2026年10月回 指名


まだ何もありません

あなたを気にしている企業

キャリアビジョン


社会貢献性のあるプロダクトに携わっていいたいです。

ITの価値が最も大きく出るのは、ITを専門としない人の課題を解いたときだと考えています。 現職で担当しているアクセシビリティ改善は、その問題意識と地続きです。キーボード操作への対応やスクリーンリーダーでの読み上げ修正を3年間継続して担当してきましたが、これは「そのままでは使えない人」を減らす仕事です。医療・福祉・教育といった領域のプロダクトは、利用者にITの専門知識を前提にできません。その前提のもとでUIを設計し実装してきた経験は、こうした領域で直接活かせると考えています。

プロジェクト経験

2023年/2年以上

自社システム開発(フロントエンド)

#プロジェクト概要 エンジニア向け技術情報共有サービス「Qiita」のフロントエンド開発・運用。既存機能の改善、共通コンポーネントの設計と移行、アクセシビリティ改善、年次イベント施策の開発を担当。2023年1月の参画以降、アサインされてクローズしたPRは約370件。 #チーム情報 5名体制。デザイナー・セールス・他エンジニアと部署横断で連携。フロントエンドはReact / TypeScript、バックエンドはRuby on Rails + GraphQL。GitHubでのPRレビュー運用。 #開発・実装内容A:共通コンポーネントの設計と既存実装の移行 【概要】稼働中のプロダクトに対し、散在していたUIコンポーネントの共通化と、旧実装から新実装への段階的な置き換えを担当。 【どのような機能の開発・実装か】記事ページに表示される複数のポップアップUIを、共通コンポーネントとカスタムフックに集約して再実装。あわせてDropdownコンポーネントの新旧実装の統合、Tooltip、Spinner、フォーム入力まわりの共通コンポーネントの作成を担当。いずれも自身が設計から実装まで担当。 【課題・問題点】ポップアップが種類ごとに個別の状態で表示制御されていたため、ユーザーが1つ閉じても別のポップアップが表示され続け、体験を損ねていた。またDropdownは新旧2つの実装が併存していて、どちらを使うべきか判断しづらく、参照箇所も広範囲に及んでいたため、一度に置き換えると影響範囲が読めない状態だった。 【打ち手・使用した技術】ポップアップは表示制御を担うカスタムフックを新規に設計し、どれか1つを閉じれば一定期間すべて非表示になるよう、判定ロジックを一箇所に集約。Dropdownは「旧実装の退避 → 新実装への参照の付け替え → 命名とディレクトリ構成の整理」と段階を分けてPRを出し、各段階で既存の参照を壊していないことを確認しながら進めた。コンポーネント単位だけでなくカスタムフック単位でも共通化を設計している。React / TypeScript。 #開発・実装内容B:アクセシビリティ改善の継続的な取り組み 【概要】2023年から継続して、各ページのアクセシビリティ改善を担当。デザイングループ起票のissueに対し、自身が調査・実装を担当。 【どのような機能の開発・実装か】検索ナビゲーション・フッターナビゲーションのキーボード操作対応、エディタのエラーメッセージへの aria-live 付与、タグページ・アカウントページ・2段階認証ページ・設定ページの改善、コントラスト比の修正、検索領域へのrole / aria-label付与など、計18件のPRを担当。 【課題・問題点】スクリーンリーダーで日付表記「2024/04/20(土)」が「ニセンニジュウヨン スラ ゼロヨン スラ ニジュウ ツチ」と誤読される問題があった。また、改善が単発対応になると同種の問題が他ページで再発する懸念があった。 【打ち手・使用した技術】日付の読み上げについては、画面表示はそのままに読み上げ用テキストを別途提供するスクリーンリーダー対応コンポーネントを作成し、再利用可能な形にした。個別ページの対応では、実際にキーボード操作とスクリーンリーダーで挙動を確認したうえで修正内容を決めた。React / TypeScript、WAI-ARIA。 #開発・実装内容C:年次イベント施策の開発(Tech Festa / Conference / Advent Calendar) 【概要】Qiita Tech Festa、Qiita Conference、Advent Calendarなど、公開日が固定された年次イベントのフロントエンド実装と運用対応。 【どのような機能の開発・実装か】Tech Festa 2026では、Organization対抗戦・記事・ユーザーの各ランキングページを実装。フロントエンドに加え、GraphQLのスキーマ定義、Rails側のランキング集計処理と実行用タスク、受賞者へのバッジ付与処理まで自身が担当。Conferenceでは、グローバルヘッダー・フッター・記事下への導線追加、開催告知ポップアップの更新を担当。 【課題・問題点】イベントは公開日時が動かせない一方、デザイン確定からリリースまでの期間が短い。また、公開前に本番環境へコードが入るため、意図しないタイミングで表示されるリスクがあった。 【打ち手・使用した技術】ランキングページは先にmockデータで画面を完成させ、GraphQLの実装完了後に本番データへ差し替える順序で進め、デザイン確認と集計ロジックの実装を並行させた。公開前に意図せず表示されないよう、公開日時に合わせて自動的に切り替わる制御を入れた。React / TypeScript、GraphQL、Ruby on Rails。 #開発・実装内容D:不具合調査と品質改善 【概要】ユーザー影響のある不具合の調査・修正、およびCIの安定化。 【どのような機能の開発・実装か】フォームの離脱確認を制御するカスタムフックの不具合修正、記事ページのstickyメニューの表示崩れ修正、flakyテストの解消、外部API呼び出しのエラーハンドリング追加など。いずれも自身が原因調査から修正まで担当。 【課題・問題点】離脱確認の不具合は、同一ページに複数のフォームがマウントされている状況で、片方が離脱確認を無効化またはアンマウントすると、もう片方に未保存の入力が残っていても確認ダイアログが出なくなるというものだった。各呼び出し箇所が同一のイベントリスナーを共有しており、互いに解除し合っていたことが原因。 【打ち手・使用した技術】カスタムフックの各呼び出し箇所が useCallback で自分専用のハンドラを保持し、自分が登録したリスナーだけを addEventListener / removeEventListener する実装に変更。テスト面では、非同期ジョブのenqueueをstubするなどしてflakyの原因を取り除いた。React Hooks、RSpec。 #その他の担当 プロジェクトオーナーの補佐として、複数施策が並行する中でのミーティング設定・レビュー依頼・QAスケジュール調整を担当。また2026年4月からは、チーム持ち回りの「数値深掘り会」で担当回のテーマ選定から分析・レポート作成・社内発表までを単独で完遂。Claude CodeをMCP経由でRedash / BigQueryに接続して分析を進める一方、数値の急変点は施策リリース履歴や季節性と突き合わせて外部要因を切り分け、断面比較で大差が出たケースでは逆因果を疑って同一ユーザーの前後比較へ設計を変更するなど、検証の妥当性は自分で判断した。

マネージメント能力

プロジェクトの進行をマネジメントしていました。対象は、Qiitaのイベント施策・キャンペーン開発における、デザイン・セールス・エンジニアと複数部署にまたがるタスクと情報の流れです。プロジェクトオーナーの補佐という立場で、人事評価や要員配置の権限は持たず、進行面の設計と調整を担当していました。
公開日が動かせない施策を、遅延なくリリースできる状態にすることが責務でした。具体的には次の3つの状態を維持することだと考えていました。 ・誰が何をいつまでにやるかが、関係者全員から見えている状態 ・レビュー待ちや確認待ちでタスクが止まらない状態 ・問題が起きたときに、公開日に影響が出る前に表面化する状態
複数の施策が同時に走る状況では、作業そのものにかかる時間より「誰かの確認待ちで止まっている時間」のほうがボトルネックになると考えました。実際に、デザイン実装やレビュー工程の遅れがそのまま公開スケジュールを圧迫していました。 障害は2つありました。1つは、各担当が自分の作業範囲しか見ていないため、依存関係のあるタスクに抜け漏れが生じること。もう1つは、レビューやQAの依頼が「手が空いたら対応」になりやすく、いつ着手されるか見通しが立たないことです。 前者に対しては、進行状況を共有するミーティングを設定し、朝会でも課題を早い段階で出せる場をつくりました。後者に対しては、依頼を出して待つのではなく、自分からレビュー依頼とQAスケジュールの調整を行い、「いつ誰が見るか」を先に確定させる進め方に変えました。工程の遅れを後から検知するのではなく、着手前に予定を埋めてしまう形にしたということです。 結果として、各イベント施策を大きな遅延なくリリースでき、チーム全体のタスク消化スピードの改善にもつながりました。

アピール項目


アウトプット

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

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

現在はJavaScript、React、TypeScriptをメインに仕事をしてて、バックエンドの知識が皆無なので少しずつでも身につけていきたいと思っています。

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

未入力です

生成AIの活用状況

日常的な情報収集・業務活用
ChatGPTやGeminiなどのチャットツールを、情報収集、ドキュメント作成、翻訳に日常的に活用
業務でコード補完系の生成AIを活用
GitHub Copilot等のコーディング支援ツール
業務でコード生成、コーディングエージェント系の生成AIを利用
コードレビュー、テストコード生成、デバッグに生成AIを活用

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
責任感
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
年収が第一
やりたくない分野
広告 / ゲーム
その他の特徴
使用言語にはこだわらない / 3年以内には海外で働きたい / 多職種のバックグラウンドがある
その他のやりたいこと・やりたくないこと

お金にまつわるサービスに興味があります。
年齢も中年と呼ばれる年代になり、どうやって資産運用していくかとかを考えるようになってから特にFinTechに対して興味を持ち始めました。
あとは漠然とWebを通じて社会貢献しているような会社で働きたいです。
エンタメやソシャゲなどは興味はありません。

やりたい事

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

基本プロフィール

年齢
今年で50代前半
好きなテキストエディタ
VSCode
希望勤務地
東京都 / 福岡県 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
500万円
ご意見箱

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

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

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