2025年の振り返り - 求人管理機能開発の1年間
投稿日: 2025/12/30
職務経歴書に書こうとしたら量が多すぎたので、ブログ記事として1年間の学びをまとめました
はじめに
2025年、求人管理機能の設計・開発プロジェクトに携わりました。振り返りをしようと職務経歴書に書き始めたところ、書きたい内容があまりにも多く、職務経歴書に収まる量ではなかったです。
なので「ブログ記事として書いた方がいいのでは？」と思い、この記事を書いています。
職務経歴書としてはまとめきれなかった、データベース設計、アーキテクチャ設計、チーム連携、ユーザー価値の追求など、1年間で取り組んだ20個以上の実績を、できるだけ正直に、ありのままに記録しました。
長い記事になりますが、1年間の学びと成長の記録として、お付き合いいただけると嬉しいです。ほぼ見る方いないと思いますが笑
プロジェクト概要
採用プラットフォームの開発で求人機能をリリースするため、データベース設計から実装、チーム連携まで一貫して担当しました。労働時間制度や求人プロパティなど複雑な業務ドメインに対し、法的要件とユーザーニーズを両立する設計を目指しました。
担当した主な領域は以下の通りです：
- データベース設計・実装
- アーキテクチャ設計とエラーハンドリングの統一化
- チームファシリテーション・技術的意思決定支援
- 開発プロセスの改善・効率化
- コードレビューとメンバーサポート
データベース設計での学び
1. 労働時間制度DB設計における意思決定支援と設計停滞の解消
労働時間制度の仕様検討を進める中で、休憩時間の表記方法について議論が長期化していました。制度ごとに法的な取り扱いが異なるため、チーム内での議論が収束せず、このままでは意思決定が停滞し、後続のマイグレーション実装タスクにも影響が出るリスクがありました。
チーム内で議論を重ねても結論に至らないのは、意思決定に必要な材料が不足しているか、判断軸が曖昧なためだと考えました。完璧な情報が揃うのを待つのではなく、現時点で整理できる情報を言語化し、不明点は専門家に確認する判断をすることで、意思決定の質を高めながらも停滞を防ぐことを優先しました。
まず、制度ごとの法的な取り扱いの違いを整理し、ドキュメント化しました。休憩時間の表記に関する複数の選択肢を洗い出し、各選択肢のメリット・デメリットを明確化し、「どの制度で休憩時間の入力が必要か」「不要な場合はどの表記が妥当か」といった論点を明確に整理しました。
次に、停滞している議論を前に進めるためにハドルを提案しました。プロダクトオーナーやメンバーを巻き込み、各制度の法的要件とDB設計の両面から検討する場を設定しました。不明点については社労士への確認を依頼し、専門家の知見を適切なタイミングで取り入れました。
また、UI都合に引きずられない、データとしての本質的な意味を重視した設計を提案しました。現時点での要件を満たしつつ、将来の拡張性も考慮した設計方針を提示しました。
議論が停滞している原因を「材料不足」と「判断軸の曖昧さ」と分析し、それぞれに対応したこと、完璧な情報を待つのではなく、現時点で整理できる情報をドキュメント化して意思決定を前進させたこと、チーム内だけで解決しようとせず、専門家（社労士）を適切なタイミングで巻き込み、品質と速度を両立したことを工夫しました。
その結果、ハドルを通じて、制度ごとの法的要件とDB設計の整合性を確認し、チーム全体で納得感のある意思決定を実現できました。設計の停滞を解消し、後続のマイグレーション実装タスクへスムーズに移行できました。議論が長期化するリスクを回避し、プロジェクト全体の遅延を防止できました。
意思決定のプロセスをドキュメント化しました。「不明点は専門家に確認する」という判断パターンがチーム内で共有され、今後の設計検討でも活用される運用を確立できました。下期の目標にしていた「自分の判断プロセスを言語化・共有することで、意思決定の質を高める」を実践し、チームの意思決定文化の向上に貢献できたと思います。
2. DB設計の包括的レビューによる設計品質向上と知識共有
DB設計を一人で完結させると、視野が狭くなり設計の質が下がるリスクがありました。また、普段DBに触れないメンバーが多く、チーム全体のDB理解度を向上させる必要性も感じていました。
一人で設計を完結させるよりも、多様な視点を取り入れることで設計の質が高まると考えました。また、DBに触れる機会が少ないメンバーにも理解を深めてもらうことで、将来的なチームの技術力向上につながると判断し、チーム全体でのレビューの場を設けることにしました。
チームへテーブル名のレビューを依頼し、技術レベルに関わらず誰でも意見を出しやすい雰囲気づくりを意識しました。専門用語を避け、設計の意図を分かりやすく説明することで、DB初心者も参加しやすい環境を整備しました。
メンバーから命名の指摘だけでなく、「意味がテーブルごとに違う」「固定残業と通常残業の区別が曖昧」など設計そのものへの質問が生まれました。自分の判断理由を一つずつ言語化して説明し、設計の背景や意図を共有しました。疑問が出るたびに具体例を示して補足し、理解を深めてもらうことを重視しました。
都道府県マスタの順序に関して「公的コードを持つ選択肢」という新たな視点を得られました。他者の視点が学びを引き出してくれた瞬間を共有し、チーム全体で知見を深められました。
専門用語を避け、誰でも参加しやすい説明を心がけ、属人化を防止すること、質問が出やすい雰囲気づくりを意識し、心理的安全性を確保すること、一方的な説明ではなく、対話を通じて相互に学び合える場を設計すること、具体例を示すことで、抽象的な設計概念を理解しやすくしたことを工夫しました。
その結果、命名の改善だけでなく、設計の明確さも高まり、誤解が生まれにくい設計を実現できました。普段DBに触れないメンバーも積極的に議論に参加し、チーム全体のDB理解度が向上しました。手戻りが減り、実装時の認識齟齬が発生しにくくなりました。
DB設計をチーム全体でレビューする文化が定着し、設計の質と透明性が継続的に向上しています。設計の背景や意図を共有する習慣がチームに根付き、メンテナンス性の高い設計が維持されています。学習する文化を育てる姿勢を実践でき、知見を相互に行き交わせる環境を構築できました。
3. 都道府県番号のDB保持に関する本質的な議論とデータ設計の最適化
都道府県番号をDBで持つべきかという議論が発生しました。単にUIのソート順のためだけにDBに番号を持つことは、データとしての本質的な意味を欠き、設計の複雑さを増すだけではないかという懸念がありました。
UI都合だけで設計すると、データとしての本質的な意味が失われ、将来的な拡張性や保守性が損なわれると考えました。一方で、自分の仮説に固執するのも危険だと判断し、メンバーとの議論や外部調査を通じて前提を更新しながら判断を磨くことを重視しました。
「この番号はデータとしてどんな意味を持つのか？」という根本から考え直しました。UIのソートにしか使わないのであればアプリ側で処理すれば十分で、不要なデータを抱えることは設計の複雑さにつながると仮説を立てました。
自分の仮説のまま決めてしまうのは危険だと感じ、メンバーと議論しながら検証しました。外部APIを使う案や行政コードの安定性など、自分では気づけていなかった視点を積極的に取り込みました。
他サービスのAPIまで調査し、同じ番号体系が広く利用されていることを確認しました。「この番号を保持する意味」について解像度が一段上がりました。
「なぜこのデータが必要なのか」という本質から問い直し、UI都合に引きずられない設計を追求すること、自分の仮説に固執せず、オープンな議論を通じて前提を更新する姿勢を維持すること、外部サービスの実例まで調査し、業界標準や実績を考慮した判断を実施すること、データの安定性と将来の拡張性を両立する設計を目指したことを工夫しました。
その結果、UUIDではなく安定した連番をIDとして採用する設計のほうが、シンプルで扱いやすく、設計としても納得いく形にできました。データとしての本質的な意味を重視した設計を実現し、将来の拡張性も確保できました。不要な複雑さを避け、メンテナンスしやすい設計を達成できました。
「データとしての本質的な意味は何か」を問う設計思想がチームに共有され、以降の設計でも同様の視点が活用されています。仮説を立てて検証するアプローチが定着し、思い込みによる設計ミスを防ぐ文化を構築できました。卓越性とシンプルさを追求する姿勢を実践し、チームの設計品質向上に貢献できました。
4. メンバーのDB操作サポートと技術理解の促進
メンバーから「DB操作が難しい」と相談を受けました。今回のタスクは新規テーブル作成ではなく既存カラムの変更で、いつものフローと異なるため、イメージが曖昧なまま手が止まってしまっていました。さらに「既存マイグレーションを修正すべきか、新しいマイグレーションを作るべきか」という迷いも抱えている状態でした。
答えだけを教えると、その場は解決しても次回同じ問題に直面した時にまた困ってしまうと考えました。メンバー自身が理解を深め、次回以降は自律的に対応できる状態を作ることが、長期的にはチーム全体の生産性向上につながると判断し、一緒に考えるアプローチを取りました。
まずはどこができていないのかを一緒に確認しました。進捗状況を改めて確認し、まだマイグレーションの実行前であることを把握しました。
変更後のスキーマを一緒に整理し、差分検知によって新しいマイグレーションが生成されることを確認しました。手順を理解できるように説明しながら進めていきました。
自分が答えだけを示すのではなく、実際に手を動かしてもらうことで一つずつ理解を積み上げてもらいました。「なぜそうするのか」を理解してもらうことで、次回以降は自分で判断できる状態を目指しました。
答えを教えるのではなく、一緒に考える姿勢を維持し、属人化を防止すること、「なぜそうするのか」を丁寧に説明し、単なる手順ではなく理解を深めることを重視すること、実際に手を動かしてもらうことで、体験を通じた学習を促進すること、心理的安全性を保ち、気軽に相談できる関係性を維持することを工夫しました。
その結果、メンバー自身が納得して前に進める状態をつくれました。次回以降、同様のタスクに対して自律的に対応できる知識を身につけてもらえました。相談のハードルが下がり、困ったときに早めに声を上げてもらえる関係性を構築できました。
「答えを教えるのではなく、一緒に考える」サポート文化がチームに定着しました。メンバーの自律的な成長を促す教育アプローチが他のメンバーにも展開され、チーム全体の技術力向上につながっています。HRTの姿勢で「尊敬と信頼で、一つのチームになる」を実践し、心理的安全性の高いチーム環境を維持できていると思います。
5. DB設計の不確実論点のオープン化による設計品質向上
DB設計を進める中で、未確定事項の扱いや境界の切り方、データ表現の方法など、曖昧な点が多く存在していました。設計者の頭の中だけで進めると、後から前提が崩れたり、手戻りや運用負債につながるリスクがありました。また、個人判断に寄ると、「何が未確定で、どこにリスクがあるか」が共有されず、チームとしての意思決定になりにくい状態でした。
DB設計に未確定事項があるまま進めると、後から前提が崩れた際に大きな手戻りが発生するリスクがあると考えました。また、個人の頭の中だけで判断すると、チーム全体で「何が未確定で、どこにリスクがあるか」が共有されず、意思決定の質が下がると判断しました。不確実性を可視化し、オープンな議論を通じてチーム全体で認識を揃えることを優先しました。
疑問点を付箋に書き出し、技術的な設計・実装課題を言語化しました。不安点・未確定点を"言語化して外に出す"ことで、議論可能な状態にしました。「わからない」をそのままにせず、論点を開いてチームで考える場を作りました。
メンバーとオープンな場で議論し、前提と方向性を揃えました。議論の中で設計の観点が不足していたことを指摘してもらい、自分では見落としていた課題に気づくことができました。
将来リスクやユーザーへの影響を整理し、責務をどう切り分ければ複雑さを減らせるかを検討しました。関心の分離、将来リスクといった観点を踏まえ、複雑さを抱え込まない方向へ整理しました。議論で得た観点を取り込み、設計の指針をシンプルにまとめました。
付箋を活用して不確実な論点を可視化し、抽象的な不安を具体的な議論に落とし込んだこと、「わからない」を隠さずオープンにすることで、チーム全体で解決する文化を醸成したこと、自分の視点だけでなく、他者の意見を積極的に取り込み、設計の盲点を減らしたこと、将来リスクを先回りして整理し、後戻りを防止したことを工夫しました。
その結果、不確実性が"個人の悩み"から"チームの論点"になり、同じ前提で設計を進められる状態になりました。何を課題として設計したのかが明確になり、次に進むための方向性をチームで決めることができました。議論を通じて複雑さを削ぎ落とし、よりシンプルな設計方針へ収束できました。以降の実装・運用判断におけるブレが起きにくい土台になりました。
「不確実な論点を可視化して議論する」プロセスがチームに定着し、設計時の手戻りが減少しています。付箋やFigJamを使った可視化手法が他のメンバーにも展開され、チーム全体の議論の質が向上しています。技術課題を言語化し、オープンな議論を通じて設計の問題点を整理する文化がチームに根付きました。
アーキテクチャ設計・技術的問題解決
1. エラーハンドリングの統一化プロジェクトによる開発体験の向上
アプリケーションごとに異なるエラーハンドリングが存在し、運用上の課題になっていました。開発者がアプリケーションごとに異なるエラー処理を覚える必要があり、一貫性のないエラーハンドリングがメンテナンス性を低下させていました。
完璧な型保証を追求すると、技術的な複雑さが増し、チーム全体の理解が難しくなるリスクがありました。また、完璧な設計に固執すると価値提供が遅れるため、「実用的な一貫性」を優先することで、チーム全体が迷わず開発を進められる体制を構築することを重視しました。
型付きでエラーを返す設計を目指し、複数のアプローチを検証しました。tRPCやHonoの型推論を試したが、完璧な型保証には技術的な限界があることを確認しました。理想を追い求めすぎるとプロジェクトが停滞すると判断しました。
完璧な型保証より「エラーハンドリングの一貫性」を優先しました。シンプルな構成に切り替え、チーム全体が理解しやすく保守しやすい設計を実現しました。「まず動いて価値を届ける」ことを選択しました。
目的ごとに差分を切り分け、独立したPRとして対応しました。Devinを活用して実装効率を向上させ、自分の時間を設計やレビューに集中しました。レビュワーの認知負荷や修正コストを軽減する工夫を徹底しました。
複数の技術的アプローチを検証し、理想と現実のバランスを見極めたこと、完璧さを追求しすぎず、チーム全体が理解できるシンプルな設計に落とし込み、属人化を防止したこと、Devinを活用して実装効率を向上させ、自分の時間を設計やレビューに集中し、開発体験を改善したこと、PRを目的ごとに切り分け、レビュワーの認知負荷を軽減し、レビューの質を向上したことを工夫しました。
その結果、エラーハンドリングの一貫性を実現し、チーム全体が迷わず開発を進められる体制を構築できました。他メンバーがユーザー価値に直結する開発に注力できる環境を整備できました。レビュワーの負荷を軽減し、レビューの質も向上しました。完璧さより実用性を優先する判断により、プロジェクト全体のスピードを保てました。
エラーハンドリングの統一的な実装パターンがドキュメント化され、新規開発でも一貫性が保たれています。「完璧さより実用性」を優先する判断基準がチームに共有され、過度な理想主義を避ける文化が定着しています。PRの切り分け方がチームのベストプラクティスとして共有され、レビュー品質が継続的に向上しています。
2. 画像カルーセルのちらつき問題の原因特定と解決
メンバーが実装した画像カルーセルで、画像切り替え時にちらつきが発生していました。ユーザー体験を損なう問題であり、早急な解決が必要でした。
問題を解決するだけでなく、メンバーが「なぜ起きているのか」を理解することで、今後同様の問題を未然に防げると考えました。技術的な理解を深めることで、チーム全体の技術力が向上すると判断し、単なる修正提案ではなく、学びの共有を重視しました。
LazyLoadImageとprefetchの競合を特定しました。ライブラリの動作を理解し、なぜちらつきが発生するのかを分析しました。
<img>タグへの差し替えを提案しました。参考コードを添えてレビューし、「なぜ起きているのか」を理解してもらうことを重視しました。
単に問題を解決するだけでなく、今後同様の問題を未然に防げるよう、背景を丁寧に説明しました。
ライブラリの動作を深く理解し、根本原因を特定することで再発を防止したこと、修正案だけでなく参考コードを添えることで、メンバーが理解しやすい形で提案したこと、「なぜ起きているのか」を丁寧に説明し、問題解決と学習機会を両立したこと、今後同様の問題が起きないよう、知見をチームに共有したことを工夫しました。
その結果、画像カルーセルのちらつき問題を解決し、ユーザー体験を改善できました。メンバーの理解促進により、今後同様の問題を未然に防げる知見を共有できました。問題が発生した際の原因分析と解決のアプローチがチームに伝わり、技術力向上に貢献できました。
ライブラリ使用時の注意点がドキュメント化され、同様の問題が再発しない体制を構築できました。問題解決時に「なぜ起きたか」を共有する文化が定着し、チーム全体の学習効果が向上しています。
3. リリース時のフルスクリーン表示バグのHotfix対応
リリース直前にフルスクリーン表示のバグが判明しました。リリースを予定通りに完了させるため、迅速な対応が必要でした。
リリース直前のバグ対応は、誰かが迅速に動く必要がありました。他メンバーが本来のタスクに集中できるよう、自分が障害を取り除くことで、チーム全体のゴールを達成できると判断しました。
他メンバーが時間を取られないよう、自分からHotfix対応に手を挙げました。問題を即座に解決し、リリースを予定通りに完了しました。
他メンバーが本来のタスクに集中できるよう、障害を取り除くことを優先しました。リリースを成功させることをチーム全体のゴールとして捉えました。
リリース直前という緊急時に、自ら率先して対応に手を挙げ、チーム全体のリスクを軽減したこと、他メンバーのタスクへの影響を最小限に抑え、チーム全体の生産性を維持したこと、柔軟に優先度を変更し、チーム全体のゴールを第一に考えた行動をしたことを工夫しました。
その結果、リリースを予定通りに完了し、チームで成果を出す姿勢を実践できました。他メンバーが本来のタスクに集中できる環境を維持できました。リリースの遅延を防ぎ、ユーザーへの価値提供を予定通りに実現できました。
緊急時に率先して対応する文化がチームに定着し、リリース時のトラブル対応がスムーズになりました。チーム全体のゴールを優先する姿勢が共有され、個人のタスクよりもチームの成果を重視する文化が醸成されています。
チーム連携・コミュニケーション・プロセス改善
1. レビュー優先度の見直しとチーム生産性の向上
作業を中断したくない気持ちからレビューを後回しにしていたところ、メンバーのPRがレビュー待ちで滞る状況が発生しました。自分の作業効率を優先することで、チーム全体の生産性を下げている可能性に気づきました。
自分の作業を中断したくない気持ちは理解できるものの、レビューが遅れることでメンバーの作業がブロックされ、チーム全体の生産性が低下することを重視しました。個人の効率よりもチーム全体の流れを優先することが、最終的には価値提供のスピードを高めると判断しました。
レビューが遅れることでメンバーの作業がブロックされ、チーム全体の生産性が低下することを認識しました。自分の作業効率よりもチーム全体の流れを優先すべきだと判断しました。
「PRが来たら迷わず動く」という基準を自分に設定しました。レビューを最優先タスクとして扱う習慣を確立しました。
設定した基準を継続的に実践し、レビューへの着手を大幅に早めました。
自己の行動パターンを客観的に振り返り、チーム全体への影響を分析したこと、明確な行動基準「PRが来たら迷わず動く」を設定し、迷いを排除したこと、継続的に実践することで習慣化し、レビューの質とスピードを両立したこと、個人の生産性よりチーム全体の流れを優先する価値観を実践したことを工夫しました。
その結果、レビューへの着手が大幅に早くなり、メンバーのPRがレビュー待ちで滞る状況を解消できました。チーム全体の生産性が向上し、価値提供のスピードが高まりました。メンバーが安心してPRを出せる環境を構築し、開発の流れがスムーズになりました。
「PRが来たら迷わず動く」という行動基準が習慣として定着し、継続的に実践されています。レビュー優先の文化がチーム内で共有され、他のメンバーもレビューを優先する姿勢が広がりました。チーム全体のレビュー速度が向上し、開発サイクルが加速しています。
2. 設計レビューの結論整理によるチームの流れの維持
メンバー間で進めていた設計レビューで、議論が生まれたものの結論がどこに落ち着いたのかが共有されておらず、周囲のメンバーが判断できない状態になっていました。メンバーから結論を知りたいと声が上がったものの、本人は別タスクで手が離せず対応が止まっており、このままでは周囲の作業が滞る状況でした。
直接の依頼ではなくても、背景を把握している自分が動くことで、チーム全体の流れを止めずに前へ進められると判断しました。忙しいメンバーに無理をさせず、かつ結論を求めているメンバーの不安を解消することを優先しました。
自分への直接依頼ではなかったが、背景を把握している自分が動いたほうが早いと判断しました。代わりにチケットへ内容を整理して記載し、メンバーが次へ進める土台を即座に提供しました。
忙しいメンバーに無理をさせずに済むようにしつつ、結論を求めていたメンバーの不安も解消しました。双方に配慮したコミュニケーションを意識しました。
直接依頼されていなくても、チーム全体の流れを優先して主体的に動いたこと、議論の結論を簡潔に整理し、誰が見ても理解できる形でドキュメント化したこと、双方のメンバーの状況に配慮し、誰にも無理を強いない形で問題を解決したこと、迅速に対応することで、待ち時間を最小化し、プロジェクトの遅延を防止したことを工夫しました。
その結果、チーム全体の流れを止めずに前へ進めることができました。忙しいメンバーの負担を増やすことなく、必要なメンバーへ最速で情報を届けられました。待ち時間がなくなり、開発のスピードが維持されました。
直接依頼されなくてもチーム全体の流れを優先して動く文化がチームに定着しています。議論の結論をドキュメント化する習慣が広がり、情報の透明性が向上しています。HRTの姿勢で「尊敬と信頼で、一つのチームになる」を実践し、互いに助け合うチーム文化を醸成できています。
3. スキル値決め議論の停滞解消とたたき台の作成
「スキルの値決め」に関する議論が長く停滞しており、このままでは意思決定が進まない状態でした。議論が進まない原因は、意思決定に必要な材料が揃っておらず、何を基準に話すべきかが曖昧なままだったためです。
議論が停滞している原因は、意思決定に必要な材料が不足していることだと考えました。完璧な情報を待つよりも、現時点で整理できる情報をたたき台として提供することで、議論を再び動かすことができると判断しました。
完璧な情報が揃うのを待つよりも、まずは前進するための土台をつくることを優先しました。自らスキル情報を整理する判断をしました。
Dodaの情報からスキル一覧を抽出し、重複や分類を整理しました。チームが再び議論に戻れる最低限の共通材料を整えました。
ステークホルダーに持ち込む前に認識ズレが生じると再び議論が停滞すると考え、事前にメンバーへレビューを依頼しました。参照リンクや背景とともに判断過程を共有し、「問題なさそう」という確認を得られました。
完璧な情報を待つのではなく、現時点で整理できる情報をたたき台として提供し、議論を前進させたこと、認識ズレが発生しないよう、事前にメンバーへレビューを依頼し、判断過程を共有したこと、参照リンクや背景をセットで共有することで、判断の透明性を確保したこと、「自分の判断プロセスを言語化・共有することで、意思決定の質を高める」を実践したことを工夫しました。
その結果、停滞していた議論を再び動かし、意思決定の土台をチームとしてそろえることができました。たたき台を作成したことで、同じ前提に立って次の意思決定へ進める状態をつくれました。チーム全体が同じ材料を見ながら議論できる状態を実現できました。
たたき台を作成してから議論を進めるアプローチがチームに定着し、意思決定のスピードが向上しています。判断過程を言語化して共有する習慣がチームに広がり、意思決定の透明性が高まりました。「完璧を待つより前進する」という文化がチームに根付き、停滞しにくい体制を構築できています。
4. プランニングでのファシリテーションと完了定義の明確化
プランニングでチケットの完了定義が曖昧な状態がありました。このまま進めるとスプリント中に認識のズレが発生し、手戻りが生じるリスクがありました。
曖昧な完了定義のままプランニングを進めると、スプリント中に認識のズレが発生し、手戻りが生じるリスクがあると考えました。事前に対話を通じて認識を合わせることで、スプリント中のズレを未然に防ぐことを優先しました。
チケットの完了定義について、メンバーと対話を通じて認識のズレをその場で解消しました。曖昧な表現を具体化し、誰が見ても同じ理解ができる状態を目指しました。
完了定義を再整理し、チケットに明記しました。スプリント中に「これは含まれるのか？」という疑問が生じないよう、事前に明確化しました。
曖昧な表現をその場で具体化し、認識のズレを早期に解消したこと、完了定義をチケットに明記することで、誰が見ても同じ理解ができる状態を実現したこと、対話を通じて透明性を高め、心理的安全性を確保したこと、スプリント中に疑問が生じないよう、事前に論点を明確化したことを工夫しました。
その結果、チームが自信を持って見積もれる環境を整備できました。スプリント中の認識のズレを未然に防止し、手戻りを削減できました。対話を通じて透明性を高め、チーム全体が同じ理解を持てる状態を作れました。
プランニング時に完了定義を明確化する習慣がチームに定着し、スプリント中の手戻りが減少しています。対話を通じて認識を合わせるアプローチがチームに広がり、透明性の高いコミュニケーション文化を醸成できています。チケットに完了定義を明記するプラクティスが標準化され、誰が見ても同じ理解ができる状態が維持されています。
5. 開発環境の効率化とチーム全体への展開
プレビュー環境にアクセスするたびにBasic認証を毎回入力する必要があり、確認のたびに新しく入力するのは手間で、時間がもったいないと感じていました。この手作業を減らすことができないかと考えました。
日々繰り返される小さな手間が、積み重なると大きな時間のロスになると考えました。開発体験を向上させることで、本質的な開発業務に集中できる時間を増やすことができます。また、自分だけが解決するのではなく、チーム全体の効率化につなげることが重要だと判断しました。
毎回のBasic認証入力が開発体験を損なっていることを認識しました。Chrome拡張機能で解決できないかを調査開始しました。
Basic認証を自動入力できる拡張機能を発見しました。preview用URL全体に適用できるよう、正規表現でドメインパターンを組み立てました。実際に新しい環境でも認証情報の入力が不要になることを確認しました。
「自分だけが楽になるだけではもったいない」と判断しました。同じ悩みを持ちそうなメンバーもすぐ導入できるよう、設定方法と正規表現をセットで共有しました。チャンネルに投稿し、誰でも簡単に導入できる状態を整備しました。
小さな手間でも積み重なると大きなロスになることを認識し、改善に着手したこと、正規表現でドメインパターンを組み立て、新しい環境にも対応できる汎用的な設定を実現したこと、設定方法と正規表現をセットで共有し、メンバーが迷わず導入できる状態を作成したこと、自分だけでなくチーム全体の開発体験を向上させることを重視したことを工夫しました。
その結果、プレビュー環境へのアクセスが大幅にスムーズになり、確認作業の手間を削減できました。設定方法と正規表現の共有により、メンバーも同様の効率化を実現できる状態を作れました。日々の何気ない手間を削り、チーム全体の開発体験を良くする動きにつなげられました。
Basic認証の自動入力設定がチーム全体に展開され、新規メンバーにも引き継がれています。開発環境の小さな改善を見つけたらチーム全体に共有する文化が定着しています。継続的な改善を行う姿勢がチームに広がり、開発体験が継続的に向上しています。
意思決定・判断
1. スプリントゴールの見直しと確実な価値提供の優先
前スプリントで解決に至らなかったバグタスクを再びゴールに設定する動きがありました。しかし、このバグは技術的な難易度が高く、見通しが立たない状態でした。このままゴールに設定すると、再び達成できないリスクがあり、チームの信頼やモチベーションが損なわれる可能性がありました。
不確実なタスクをゴールにすると、再び達成できなかった場合にチームの信頼やモチベーションが損なわれると考えました。確実に価値提供できる形に整理することで、チームが自信を持って取り組める環境を作ることを優先しました。
バグの技術的な難易度と見通しの不確実性を整理しました。ゴールに設定するリスクを言語化し、チームに共有しました。
「調査タスク」として切り出し、技術的な見通しが立ってから次スプリントで実装する方針を提案しました。確実に価値提供できる形に整理することを優先しました。
提案を通じて、チームが「今できること」に集中する体制を構築しました。不確実なタスクをゴールにしないことで、チームの信頼を守ることを重視しました。
リスクを具体的に言語化し、チーム全体で判断材料を共有したこと、「調査タスク」として切り出すことで、不確実性を明示しつつも前進する道筋を確保したこと、チームの信頼とモチベーションを守ることを優先し、確実に価値提供できる形に整理したこと、「今できること」に集中する体制を構築し、チームの自信を高める判断をしたことを工夫しました。
その結果、確実に価値提供できる形に整理し、チームが「今できること」に集中する体制を構築できました。不確実なタスクをゴールにしないことで、チームの信頼とモチベーションを維持できました。スプリントゴールの達成率が向上し、チーム全体の自信につながりました。
この経験を通じて、不確実なタスクは切り出して、確実に価値を提供できる状態にすることの重要性を学びました。成果物を確実に提供できる状態にすることで、POは確実に成果物が届けられるという安心感を得られ、開発者は不確実なタスクで時間を奪われることなく、確実に価値を届けることに集中できる、双方にとって嬉しい状態を作ることができると実感できました。
2. typebaseパッケージ構成の整理と可読性の向上
typebaseパッケージで相対パスでの参照が多く、可読性が低い状態でした。また、責務の分離が曖昧で、メンテナンス性が低下していました。
相対パスでの参照は可読性を低下させ、将来的なメンテナンス性を損なうと考えました。メンテナンス性や可読性を意識して構成全体を見直すことで、チーム全体が理解しやすく、保守しやすいコードベースを作ることを重視しました。
ワイルドカード方式を採用し、@repo/typebase/schemas/*形式で統一しました。相対パスを排除し、可読性を向上しました。
CI環境でビルドが失敗する問題を調査し、解決しました。安定したビルドを実現しました。
パッケージ構成を整理することで、責務の分離を明確化しました。メンテナンス性の向上を実現しました。
ワイルドカード方式を採用し、パス指定を統一することで可読性を大幅に向上したこと、CI環境での問題を徹底的に調査し、安定したビルド環境を構築したこと、責務の分離を明確化し、将来的な拡張性とメンテナンス性を両立したこと、チーム全体が理解しやすい構成に整理し、属人化を防止したことを工夫しました。
その結果、可読性が向上し、統一感のある構成を実現できました。CI環境でも安定したビルドを達成できました。責務の分離が明確化され、メンテナンス性が向上しました。
ワイルドカード方式でのパス指定がチームの標準となり、新規パッケージでも同様の構成が維持されています。パッケージ構成のベストプラクティスがドキュメント化され、チーム全体で共有されています。可読性とメンテナンス性を重視する設計思想がチームに定着しています。
ユーザー価値・UX
1. 求人媒体の運用理解を深めるチーム全体での確認会
求人媒体ごとの運用イメージが曖昧で、実際にどのように使われているのかがチーム全体で共有されていませんでした。運用イメージが曖昧なままでは、ユーザーファーストな設計ができないリスクがありました。
実際の運用イメージを理解することで、ユーザーファーストな設計ができると考えました。チーム全体で共通認識を持つことで、設計の方向性がブレず、ユーザーにとって本当に価値のある機能を作れると判断しました。
実際の管理画面を共有してもらいながら、チーム全体で確認しました。積極的に質問し、運用の詳細を理解しました。
チーム全体で運用イメージを共有し、共通認識を構築しました。ユーザーファーストな設計の土台を整備しました。
実際の管理画面を見ながら確認することで、具体的な運用イメージを共有したこと、積極的に質問することで、表面的な理解ではなく深い理解を促進したこと、チーム全体で確認する場を設け、共通認識の構築を重視したこと、ユーザーファーストな設計の土台を作ることを優先したことを工夫しました。
その結果、チーム全体で共通認識を持ち、ユーザーファーストな設計の土台を構築できました。運用イメージが明確になり、設計の方向性が明確化されました。ユーザーにとって本当に必要な機能を見極める基準を整えられました。
新しい機能を設計する際に、実際の運用イメージを確認する習慣がチームに定着しています。ユーザーファーストな設計を重視する文化がチームに根付き、設計の質が継続的に向上しています。運用イメージを共有するドキュメントが整備され、新規メンバーも迅速にキャッチアップできる体制を構築できています。
2. 労働条件デザインの確認とユーザーファーストな判断
メンバーがFigmaでまとめてくれた労働条件のデザインを確認する際、自分との認識にズレがないかを確認する必要がありました。また、ユーザーにとって本当に必要な情報を見極める必要がありました。
デザインを確認する際、自分との認識にズレがあるまま進めると、実装時に手戻りが発生するリスクがあると考えました。また、ユーザー視点で本当に必要な情報を見極めることで、ユーザーファーストなデザインを実現できると判断しました。
自分の認識とメンバーの意図にズレがないかを質問しながら進めました。契約期間や派遣期間といった項目も、どういう意図で書かれたのかをすり合わせました。
喫煙に関する表記について、資料をもとに「全面喫煙」「喫煙専用室」「加熱式たばこ専用喫煙室」などの区分を整理しました。喫煙者として求職者目線に立ち、「正確な喫煙場所の位置まで気にしない」といった意見を共有しました。ユーザーにとって本当に必要な情報に絞り込むことを重視しました。
認識のズレを早期に発見するため、質問しながら確認を進めたこと、資料をもとに整理し、曖昧な表現を具体的な区分に落とし込んだこと、自分自身の求職者目線を活かし、ユーザー視点での意見を共有したこと、本当に必要な情報に絞り込むことで、ユーザーにとって伝わりやすいデザインを実現したことを工夫しました。
その結果、認識のズレを最小限にし、実装時の手戻りを防止できました。ユーザー視点で必要な情報に絞り込み、より伝わりやすいデザインに近づけました。オープンな対話を通じて透明性を高め、同じゴールに向かううえでの認識のズレを解消できました。
デザイン確認時に認識のズレを確認する習慣がチームに定着し、実装時の手戻りが減少しています。ユーザー視点で本当に必要な情報を見極めるアプローチがチームに広がり、ユーザーファーストな設計が継続的に実現されています。オープンな対話を通じて透明性を高める文化が根付き、チーム全体の協働の質が向上しています。
3. 媒体ごとに異なる求人プロパティの整理と構造化
媒体ごとに求人プロパティ（項目）が異なり、項目名や粒度、意味の揺れがある状態でした。そのまま統合しようとすると「何を標準にするか」の正解が定まらず、議論が発散しやすいテーマでした。また、求人の情報設計としては、単に項目を揃えるのではなく、求職者が意思決定しやすい形に落とし込む必要がありました。
媒体ごとにバラバラなプロパティをそのまま実装すると、設計が複雑になり、ユーザーにとっても分かりにくくなると考えました。ユーザー視点で本当に必要な情報を見極めることが重要だと判断しました。また、完璧な手順がなくても、まず手を動かして可視化し、チームで同じ材料を見ながら議論することで、前進につながると考えました。
媒体ごとに存在するプロパティを列挙し、まず「何が違うのか」を見える状態にしました。FigJamを使い、各媒体から洗い出したプロパティを付箋に書き出して並べるところから始めました。似たもの同士を近づけたり、表記の違いを都度確認しながら進めました。これにより、議論が「記憶ベースの会話」ではなく「同じ材料を見ながらの会話」になりました。
「この情報は求職者にとって本当に必要か？」を繰り返し問い、項目を"情報量"ではなく"価値"で仕分ける進め方に寄せました。「媒体にあるから入れる」ではなく、「求職者の理解・比較に寄与するか」で議論できるようにしました。実際の媒体事例も参照しながら、「概要」は主観的な要素が入りやすく、「写真」も使い方によっては求職者にとってノイズになりかねないことに気づきました。
個別プロパティを、求職者の理解の順序に沿うようにグルーピングし、情報設計としての骨格を作りました。分類が進むにつれて、単なる情報の羅列ではなく、仕事内容・労働条件・募集条件などのカテゴリとして構造化できる形が見えてきました。
FigJamを活用し、複雑な情報を可視化して誰もが理解できる状態を作成したこと、「求職者にとって本当に必要か」という明確な判断軸を設定し、議論の焦点を絞ったこと、実際の媒体事例を参照し、理論だけでなく実践的な視点を取り入れたこと、求職者の理解の流れに沿ってグルーピングし、ユーザーファーストな情報設計を実現したこと、完璧な手順がなくても、まず手を動かして可視化することで前進を促進したことを工夫しました。
その結果、単なる項目の集合ではなく、理解しやすい構造（仕事内容／労働条件／募集条件など）に整理できました。求職者が求人情報を読むときの"理解の枠組み"ができ、説明や表示の前提が揃いました。洗い出しと判断軸の固定により、議論が前に進み、設計の前提がチーム内で共有されました。「何を目的に整理しているか」が合い、以降の検討・実装で迷いにくい土台になりました。
求人プロパティの構造化されたフレームワーク（仕事内容／労働条件／募集条件など）が標準として定着し、新規機能開発でも活用されています。「求職者にとって本当に必要か」という判断軸がチームに共有され、ユーザーファーストな設計が継続的に実現されています。FigJamを使った可視化手法がチームのベストプラクティスとして展開され、複雑な議論の質が向上しています。
4. 勤務体系の再整理による定義の明確化と仕様の確定
「シフト制」「日勤・夜勤」など、日常語としては通じる一方で、仕様としては曖昧な言葉が多く、解釈がぶれやすい領域でした。言葉のまま進めると、チーム内で同じ単語を違う意味で使うリスクが高く、求職者が迷わず選べる情報設計にするには、用語の定義・境界条件・表現方法を固める必要がありました。
日常語としては通じる言葉でも、仕様としては曖昧なまま進めると、チーム内で認識のズレが生じ、実装時に大きな手戻りが発生するリスクがあると考えました。また、法的な厳密さとユーザーにとってのわかりやすさをどう両立するかが課題であり、外部の定義や実例を調査することで、曖昧な言葉を"扱える論点"に落とし込むことができると判断しました。求職者視点で本当に必要な情報を見極めることで、ユーザーファーストな設計を実現できると考えました。
勤務時間帯の仕様整理を進める中で、「勤務形態（固定制・シフト制）」と「勤務時間帯（日勤・夜勤）」の区分けが曖昧なままでした。労働基準法上の定義や、他媒体（Indeedなど）の方式を調べ、用語を「雰囲気」ではなく「前提」へ寄せました。フレックス制と裁量労働制の両立可能性についても議題に上がったが、時間管理上の矛盾が生じるため不可と判断しました。他媒体の事例も参照しつつ、勤務時間の種類ごとに共通点や差分を洗い出し、曖昧な点を一つずつ言語化しました。
問題を整理するため、自らNotionにまとめ、メンバーとの認識合わせの場を設け、最終判断はPOに相談しました。単に「シフト制かどうか」ではなく、CXCとしてどう扱うかといった"設計・運用の論点"として置き直しました。何を決めると仕様が固まるのか（意思決定ポイント）をはっきりさせ、会話の焦点を作りました。議論を整理するため、自分でも積極的に発信し、論点を構造化することを意識しました。
議論を通じて、ユーザーが本当に知りたいのは「何時から何時まで働くのか」であると確認しました。「求職者が求人を探す際に迷わず自分の働き方を選べるか」という視点を軸に話を進めました。日勤・夜勤といった区分は用いず、勤務形態と時間で表現するシンプルな仕様に確定しました。労働基準法上の分類（固定時間制・変形労働時間制など）と「シフト制」という表現の関係を明確化しました。プロダクトとして「CXC視点の正確さ」と「求職者視点のわかりやすさ」を分離して設計する方向で整理しました。
労働基準法や他媒体の実例を徹底的に調査し、曖昧な言葉を具体的な論点に落とし込んだこと、Notionにまとめることで、複雑な論点を整理し、チーム全体で同じ理解を持てる状態を作成したこと、意思決定ポイントを明確化し、議論の焦点を絞ることで前進を促進したこと、法的な厳密さとユーザーのわかりやすさを両立する設計を追求したこと、求職者視点に立ち戻り、「本当に必要な情報は何か」を常に問い続けたことを工夫しました。
その結果、用語の揺れが減り、チームが共通認識を持てる状態に近づき、議論が前進しやすくなりました。仕様検討の前提が整理され、「何を決めれば次に進めるか」が見えやすくなり、迷いが減りました。未確定だった論点を整理・明確化することで、DB設計に必要な前提や仕様を固めることができました。曖昧だったテーマを「CXCとしてどう扱うか」という具体的な次の議論へつなげられました。
勤務体系の定義がドキュメント化され、チーム全体で共有される標準となっています。曖昧な言葉を鵜呑みにせず、外部の定義や実例を調査するアプローチがチームに定着しています。「CXC視点の正確さ」と「求職者視点のわかりやすさ」を分離して設計する考え方がチームに根付き、ユーザーファーストな設計が継続的に実現されています。
学習・技術探求
1. 輪読会でのAtomフィードの実例共有
輪読会で技術的な説明が中心となり、実際にどのように活用されているのかのイメージが湧きづらい状況がありました。
技術的な説明だけでは活用イメージが湧きづらく、学びが定着しにくいと考えました。実例を共有することで、学んだことをチームに還元し、学習する文化を育てることを重視しました。
GitHubでAtomフィードの実例を調査しました。実際にどのように使われているのかを確認しました。
調査した実例を輪読会で共有しました。参加者全員が具体的な活用イメージを持てるよう工夫しました。
理論だけでなく実例を調査し、具体的な活用イメージを提供したこと、輪読会で共有することで、学びをチーム全体に還元したこと、技術的な理解を深めるだけでなく、実践に活かせる知識の共有を重視したことを工夫しました。
その結果、参加者全員が具体的な活用イメージを持てました。学んだことをチームに還元し、学習する文化を育てられました。技術的な理解が深まり、実践に活かせる知識を得られました。
輪読会で実例を共有する習慣がチームに定着し、学習効果が向上しています。学んだことをチームに還元する文化が根付き、継続的な学習が促進されています。技術的な理解を深めるだけでなく、実践に活かせる知識を共有する姿勢がチーム全体に広がりました。
2. BFF側のエラー型推論の検証と設計方針の見直し
BFF側のエラー型推論について、見かけの型安全性に頼ったヘルパー関数の構造になっており、実際には型が正しく伝播していない可能性がありました。
見かけの型安全性に頼った設計は、将来的な技術的負債になると考えました。実際に型が正しく伝播する設計を優先することで、開発体験やメンテナンス性を向上させることを重視しました。
環境をリセットして再検証し、型が正しく伝播することを確認しました。ヘルパー関数が必要ない場合は排除する判断をしました。
見かけの型安全性よりも、実際に型が正しく伝播する設計を優先しました。開発体験やメンテナンス性を意識した設計方針への切り替えをしました。
環境をリセットして徹底的に検証し、思い込みを排除したこと、見かけの型安全性に惑わされず、実際に型が正しく伝播するかを確認したこと、不要なヘルパー関数は排除し、シンプルで保守しやすい設計を追求したこと、開発体験とメンテナンス性を両立する設計を重視したことを工夫しました。
その結果、型が正しく伝播する設計を実現し、開発体験を向上できました。将来的な技術的負債を予防できました。開発体験やメンテナンス性を意識した設計方針への切り替えを実現できました。
見かけの型安全性ではなく、実際の型伝播を検証するアプローチがチームに定着しています。徹底的な検証を行う文化が根付き、技術的負債を未然に防ぐ体制を構築できています。シンプルで保守しやすい設計を追求する姿勢がチーム全体に広がりました。
その他の主要な実績
1. 労働時間制度の休憩時間表記に関する専門家への確認依頼
労働時間制度に関する仕様の検討を進めていた際、休憩時間の表記をどう扱うべきかがメンバー間で議論になりました。制度ごとの法律的な扱いが絡むため、チーム内だけでは結論を出せず、議論を続けても進まないと判断しました。
チーム内で議論を続けても結論が出ない場合、専門家に確認することで意思決定の質を高められると考えました。判断を先送りして進行が停滞する状況を避け、早期に解決へつなげることを優先しました。
確認したい論点を自分で整理し、「どの制度で休憩時間入力が必要なのか」「不要ならどのような表記が適切なのか」を明確化しました。整理した論点をPOへ共有し、社労士への確認を依頼しました。
論点を明確に整理してから確認依頼を行い、専門家が回答しやすい状態を作成したこと、チーム内だけで解決しようとせず、適切なタイミングで専門家を巻き込む判断をしたこと、判断を先送りせず、早期に解決へつなげることを重視したことを工夫しました。
その結果、判断を先送りして進行が停滞する状況を避け、プロセスを前へ進めることができました。迷いを抱えたまま立ち止まらず、他者を巻き込みながら必要な判断を早期に解決へつなげました。
この経験を通じて、専門家に確認すべき論点を明確に整理してから依頼することの重要性を学びました。チーム内だけで解決しようとせず、適切なタイミングで専門家を巻き込むことで、判断を先送りせず、早期に解決へつなげられることを実感できました。
2. ドメイン設計レビューでのオープンな対話
デザイナーが作成したドメイン設計のレビューを行う際、多様な視点を取り入れることで設計の質を高めたいと考えました。
一つ一つの設計要素について本質的な意味を問うことで、設計の質を高められると考えました。オープンな対話を通じて、設計の解像度を高めることを重視しました。
「これは必要なのか？」「これの役割は？」など細かな論点も率直に質問しました。オープンな対話を促進し、設計の背景や意図を深く理解しました。
遠慮せず率直に質問し、設計の本質的な意味を問い続けたこと、オープンな対話を通じて、多様な視点を取り入れることを重視したこと、細かな論点も見逃さず、設計の解像度を高めることに注力したことを工夫しました。
その結果、ドメイン分析の解像度を一段深め、設計の土台を強固にできました。オープンな対話で透明性を高める姿勢を実践できました。
この経験を通じて、オープンな対話を通じて設計の質を高めることの重要性を学びました。細かな論点も率直に質問することで、設計の解像度を高められることを実感できました。
3. PR構成と進め方の最適化
エラーハンドリング実装で目的外の差分がPRに混在する懸念がありました。目的が混在したPRは、レビュワーの認知負荷を高め、レビューの質を低下させるリスクがありました。
目的が混在したPRは、レビュワーの認知負荷を高め、レビューの質を低下させると考えました。目的ごとに差分を切り分けることで、レビューしやすく、修正コストも低減できると判断しました。また、Devinを活用することで、実装効率を向上させつつ、自分の時間を設計やレビューに集中できると考えました。
目的ごとに差分を切り分け、独立したPRとして対応しました。Devinを活用して実装効率を向上させ、自分の時間を設計やレビューに集中しました。レビューの認知負荷や修正コストを軽減することを重視しました。
目的ごとにPRを切り分け、レビュワーが理解しやすい構成を実現したこと、Devinを活用して実装効率を向上させ、自分の時間を設計やレビューに集中したこと、レビュワーの認知負荷を軽減し、レビューの質を向上させることを優先したこと、実装効率とレビュワーの負荷軽減を両立する進め方を追求したことを工夫しました。
その結果、自分の実装効率とレビュワーの負荷軽減の両立を実現し、チーム全体のパフォーマンスが向上しました。レビューの質が向上し、修正コストが削減されました。チーム全体の開発サイクルが加速しました。
この経験を通じて、目的ごとにPRを切り分けることでレビューの質を向上させられることを学びました。Devinを活用して実装効率を向上させつつ、レビュワーの認知負荷を軽減できることを実感できました。
1年を通して学んだこと
この1年間、求人管理機能の開発を通じて、5つの大きな学びを得ることができました。
1. ユーザーファーストな設計判断と本質的な課題解決
単にUI都合で設計するのではなく、「データとしての本質的な意味は何か？」「ユーザーにとって本当に必要な情報は何か？」を常に問い続けることの大切さを学びました。都道府県番号のDB保持に関する議論では、他サービスのAPIまで調査し、データの安定性や拡張性を考慮した設計判断を行いました。また、求人プロパティの整理では、求職者の視点に立ち、本当に必要な情報に絞り込むことを重視しました。
2. 意思決定の質を高める言語化と透明性の向上
議論が停滞した際には、問題の背景、選択肢、判断軸、理由を整理し、自分の判断プロセスを言語化して共有することの重要性を実感しました。労働時間制度のDB設計では、制度ごとの法的要件を整理し、ハドルを通じてチーム全体で納得感のある意思決定を実現しました。また、スキル値決めの議論では、たたき台を作成して議論を再び動かし、意思決定の土台をチームとしてそろえることができました。
3. チーム全体の生産性向上への貢献
レビュー優先度の見直しでは、自分の作業を中断してでもレビューを優先することで、メンバーのPRがレビュー待ちで滞る状況を解消しました。また、開発環境の効率化では、Basic認証の自動入力設定をチーム全体に共有し、全員の開発体験を向上させました。PRの構成最適化では、目的ごとに差分を切り分け、レビュワーの認知負荷を軽減しながら実装効率も高めました。
4. 技術的な課題解決能力とメンバーサポート
エラーハンドリングの統一化では、完璧な型保証よりも実用的な一貫性を優先し、チーム全体が迷わず開発を進められる体制を構築しました。また、メンバーのDB操作サポートでは、答えだけを教えるのではなく、一緒に考えながら理解を深めてもらうことで、次回以降は自律的に対応できる状態を作りました。
5. 継続的な改善と学習文化の醸成
DB設計のチーム全体でのレビューでは、普段DBに触れないメンバーにも参加してもらうことで、設計の質を高めつつチーム全体のDB理解度を向上させました。また、輪読会での実例共有では、学んだことをチームに還元し、学習する文化を育てることを実践しました。
今後に向けて
テックリードとして、サービス開発を主導できる人材を目指しています。技術的な専門性を深めつつ、事業に必要な知見を積極的に学び、チームを牽引し、サービスを成功へと導く力を身につけていきたいと考えています。
関係者と円滑にコミュニケーションを取り、チームの力を最大限に引き出して目標達成に貢献できる人材を目指しています。リーダーシップを発揮し、チームをまとめ、プロジェクトを成功に導く力を備えたいと考えています。
技術だけでなくビジネスの視点も持ち合わせ、プロダクトの成功に貢献できる人材になりたいと考えています。ユーザーファーストな視点を持ちつつ、事業の成長に貢献できる技術的判断を下せる力を磨いていきます。
おわりに
1年間の振り返りとして、職務経歴書に書ききれなかった実績をブログ記事としてまとめてみました。
改めて振り返ってみると、データベース設計、アーキテクチャ設計、チーム連携、ユーザー価値の追求など、本当に多くのことに取り組んできたなと感じます。
一つ一つの実績を正直に書くことを心がけました。嘘になるようなことは書かず、できるだけありのままに記録しています。
自身で書いた職務経歴書は、記事にするには言葉が硬いのと、あまりにも量が多かったので、AIに変換を手伝ってもらってます。嘘が書かれないように精査はしてますが、事実と異なる部分があるかもしれません🙏
この1年間で学んだことを、これからのキャリアに活かしていきたいと思います。