tomoya

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

キャリアビジョン


プロダクトと技術の両面から事業とチームの土台を作り、メンバーと一緒に事業を伸ばし続けたい

## 【理由】 ### ① 事業を伸ばすには、技術だけでは足りないと痛感したから 2人の会社でCPOとして、プロダクトの方向性から実装まで担いました。 その中で、「何を作るか」と「どう作るか」を両方見られることの重要性を学びました。 自分が最も価値を出せるのは、**技術が事業の中心にあり、その仕組みを作り育てられる環境**だと考えています。 ### ② 良い土台は、チーム全体の成長速度を上げるから Contreaでは、開発基盤・コーディングルール・レビュールールを一から作りました。 メンバーから「エンジニア人生で一番速く成長できた期間だった」と言ってもらえたことは、大きな原体験です。 **基盤が良くなると、開発体験と生産性が上がり、挑戦し続けられる組織になる**と実感しています。 ### ③ チームで課題を解くことが、自分の原動力だから 1人で技術を深めるよりも、**周りと一緒に成長している実感**があるときに、最も力を発揮できます。 そのため、1つの環境に腰を据えて、中長期で事業とプロダクトの成長に関わりたいと考えています。 ## 【具体的にやりたいこと】 ### プロダクトの方向性づくり(PdM寄り) - 商談同席・導入後のサポート・ユーザー業務の体験など、一次情報から課題を掴む - データやユーザーの声をもとに、何を作るか・何をやらないかを決める - 施策の効果を検証し、次の打ち手につなげる ### ビジネスサイドを含めた要件定義 - 課題 → 要件 → 実装まで一気通貫で落とす ### プロダクトに適した技術選定 - 事業フェーズ・チーム規模・AI活用を前提に、流行りではなく**プロダクトに合う技術**を選ぶ - 選定理由を言語化して残し、チームが判断を引き継げるようにする ### アーキテクチャ・開発基盤づくり - 変わりにくい基盤と変わりやすい施策を切り分け、すぐ試せてすぐ消せる設計にする - 実装ルールのスキル化・lintで品質を仕組みにし、AIが書いたコードも設計面から判断する ### 導入・定着まで技術で責任を持つ - 周辺システムとの接続など、「作って終わり」にしない ### チームを育てる - 進め方やルールを言語化し、1on1などでメンバーの成長を支える

プロジェクト経験

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

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

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

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

2021年/3ヶ月以内

Ability(アプリケーション版の食べログのようなもの) 【個人開発】

■技術選定 バックエンド:PHP/Laravel フロントエンド:Vue.js ,Bootstrap 開発環境:Docker/Docker-compose インフラ:AWS CI/CDツール:CircleCI ■アプリ概要 https://github.com/tomoya-kamaji/ability ■レコメンドの実装についての記事 https://qiita.com/tomoya_sakusaku/items/8a3ef360b68ef0644e83

2022年/3ヶ月以内

適性検査サービス:CABOS 【複業】

### プロジェクト概要 適性検査サービスCABOSのサーバサイド開発 https://cabos.jp ■開発において意識している点 基本的に非同期でのコミュニケーションなので、ドキュメントに情報を残すことを心がけています。 例) コミットメッセージを丁寧に書く Githubのプルリクに情報を詳細に書くなど

2018年/2年以上

京セラ基幹システム【正社員】

## ✅京セラ基幹システム 運用保守業務 ■業務内容 京セラ基幹システムのプロジェクトメンバーとして並行して複数の案件に参画。要件定義や基本設計を開発チームへ共有。その後実装されたモジュールに対して様々な観点からテストケースを作成し問題が無いかを検証を行った。また、客先からの問い合わせ対応、障害対応を行いました。 ■ ログファイル整形ツールの作成。展開 【課題と要因】 システムに障害が発生した際、原因の調査に時間がかかってしまうことがチームの課題でした。 (平均対応時間:約50分) 要因の1つとして、サーバから出力されるログファイルが見づらく何が起因して障害が起こったか即座に判断ができないことだと私は考えました。 【上記課題に対して以下を実施】 テキストエディタのマクロ機能を用いて、ログファイル整形ツールの作成 1.ログファイルの規則性を把握して、調査に必要な情報の取捨選択 2.不要な情報は削除、必要な情報を調査しやすいように正規表現を使用して整形  ※必要な情報はSQLやSQLにかかった時間、トランザクションIDなど 3.チームメンバーに配布し、使用感をヒアリングしながら修正 【功績】 上記の整形ツールを用いることで調査にかかる時間を1回あたり約10分削減することができました。 このツールはチームメンバーだけでなく基幹システムプロジェクトメンバー全体の約80人で使用されることになり、プロジェクト全体の生産性向上に寄与しました。 【学んだ点】 問題点を考察する分析力と、小さな身近な改善が大きな改善に繋がることを学びました。私の強みである、課題点を分析して改善をやり切る「課題解決力」が活かすことができたので、転職した際もチームの課題を定義し、解決していきます。 --- ## ✅ 7人規模のチームにドキュメントツールNotionを導入 【課題と要因】 チームのドキュメント管理の手段として15年以上前からExcel,Wordを使用しており、下記の課題を感じていました。 ・ドキュメントの最新のバージョンがわからず、どの情報が正しいかわからない ・容量が大きくなると、起動に時間がかかる ・検索、共有に時間がかかる 【上記課題に対して以下を実施】 1.ドキュメント共有ツールについて比較検討(Notion,Kibera,QiitaTeamなど) 2.編集までのリードタイムが短く多機能であるNotionに選定。個人プランで使用して操作感を覚える 3.自身が所属する部署の上長や事業部長に対してプレゼンテーション(提案)を実施。チームに導入 4.社内で浸透させるため、他部署も巻き込み約15名に対して勉強会に実施 【功績】 Notionを導入することで、ドキュメントの最新バージョンがわからないという課題を解決することができ、 ドキュメントの検索に使う時間を「1人・月:約90分」減少させることができました。 また、リアルタイムでドキュメントを共有することができチーム全体の生産性が向上したと感じており、メンバーにも「提案してくれてありがとう」と感謝の言葉をいただきました。 【学んだ点】 自分が行動を起こせば周りの環境を変えることができることを学びました。 転職した際も、現場の非効率な点に目を向け積極的に改善していきます。

マネージメント能力

医療系SaaS(電子同意書・説明動画配信サービス)の開発チームにおいて、テックリードとして計5名の設計・開発プロセス・コード品質・1on1をマネジメントしていました。
要件の認識ズレによる手戻りや、肥大化したPRによるレビュー滞留・リリース後の不具合再発をなくし、チーム全員が一定の品質を保ちながら、自律的かつ安定したスピードで機能を継続リリースできる状態にする責務がありました。 また、監視やアラートを含めた運用基盤を整え、障害発生時にもチームで素早く検知・対応できる体制を作る役割を担っていました。
■ どのように考えたか(マネジメントの基本方針) 書籍『リーダーの仮面 ——「いちプレーヤー」から「マネジャー」に頭を切り替える思考法』などの考え方をベースに、「チームに一定のシンプルな方針・ルールを作り、それ以外はメンバーの裁量に任せて自由にやってもらう」という方針を立てました。 細かい管理や重厚なプロセスを押し付けると形骸化しやすく、メンバーの主体性も損なわれます。 そのため、守るべき最小限のルールだけを明確に定義し、その枠内では各自が迷わず自律的に判断・実装できる環境を作るべきだと考えています ■ 途中であった問題・障害 1. 設計フェーズがなく、要件・仕様の認識差が実装段階やPR提出後になってから発覚し、手戻りが多発していた。 2. 1つのPRの変更規模が大きく、レビュー負荷の高さからマージまでのリードタイムが伸びていた。 3. テックリードである自分に設計相談やコードレビューが集中し、自分がチームのボトルネックになってしまう場面があった。 ■ どう工夫したか(具体的なルールと運用の仕組み化) ルールはあえてシンプルにし、以下の基準を定めて推進しました。 - 実装前の軽量な設計すり合わせ 重い設計書は定着しないため、実装前に作るドキュメントを「API仕様」と「データモデル」の2つだけに絞りました。また、設計レビューの観点として「影響範囲」と「代替案」をテンプレート化し、実装前に認識を揃えるようにしました。 - コーディング・PR運用のルール化 共通のコーディングルールを元に実装を行うこと、PRは小さく分けて早く出し、未レビューのものはマージしないことを徹底しました。 - 自分がボトルネックになっている箇所の最優先解消 「チーム全体のスループット最大化」を自分の責務と捉え、レビュー待ちや仕様確認で自分がボトルネックになっているときは、自身の実装タスクを止めてでもレビューや相談対応を最優先で行うようにしました。 - 月1回の振り返りと1on1によるルールのアップデート ルールは作って終わりではなく、月1回の振り返り(レトロスペクティブ)や定期的な1on1を通じて、「今のルールでやりづらい点はないか」をチームで見直し続けました。 ■ 結果とやりがい 運用を回しながら方針やルールがブラッシュアップされ、要件起因の手戻りやPRの肥大化が解消されました。 月次の見直しを重ねるごとにチーム自体の自走力が高まり、強い開発チームへと変わっていく過程に大きな面白みと楽しさを感じました。

アピール項目


アウトプット

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

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

- パフォーマンス・チューニング(SQLやコーディング) - 複雑な仕様を設計に落とし込む力 - プロジェクトマネジメント

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

- チーム内で気軽に話しかけ、切磋琢磨できるメンバーがいること - マウンティングされないこと

生成AIの活用状況

日常的な情報収集・業務活用
ChatGPTやGeminiなどのチャットツールを、情報収集、ドキュメント作成、翻訳に日常的に活用
業務でコード補完系の生成AIを活用
GitHub Copilot等のコーディング支援ツール
業務でコード生成、コーディングエージェント系の生成AIを利用
コードレビュー、テストコード生成、デバッグに生成AIを活用
サービス・プロダクトへの応用
既存のサービスやプロダクトに生成AI(API利用など)を組み込み、LangChainやLlamaIndexなどのフレームワークを使った開発経験
生成AIをコアとした開発
生成AIを主要技術としたサービス・プロダクト・機能の企画や、RAGなどの高度な手法を用いた開発経験

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 責任感
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
SI
その他の特徴
新しい技術はとりあえず試す / 勉強会でLTをよくする / 趣味は仕事 / 起業/創業期のベンチャーにいた
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で30代前半
好きなテキストエディタ
Cursor
希望勤務地
京都府 / 大阪府 / 兵庫県 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
未入力
ご意見箱

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

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

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