ID:47480さん

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

  • GROWTH VERSEがID:47480さんのレジュメを見ています。
    2025.07.01
  • キャディがID:47480さんのレジュメを見ています。
    2025.07.01
  • シャペロンがID:47480さんのレジュメを見ています。
    2025.06.30
  • FaciloがID:47480さんのレジュメを見ています。
    2025.06.30
  • RevCommがID:47480さんのレジュメを見ています。
    2025.06.29
  • シャペロンがID:47480さんのレジュメを見ています。
    2025.06.29
  • GROWTH VERSEがID:47480さんのレジュメを見ています。
    2025.06.29
  • ブリングアウトがID:47480さんのレジュメを見ています。
    2025.06.27
  • RightTouchがID:47480さんのレジュメを見ています。
    2025.06.27
  • ラフールがID:47480さんのレジュメを見ています。
    2025.06.26

3年後の目標や野望


自分も周囲も活き活きと楽しく、力を引き出して期待以上の成果を出す

仕事は私にとって、人生の中心ではなく人生を豊かにするための手段のひとつです。 手段の一つに過ぎないとはいっても仕事は人生において大きな時間を割くものです。 主軸ではなくても大きな割合を占める仕事は、有意義に楽しく取り組みたいと考えています。 この楽しく取り組みたいという野望は、私だけが快適であっても満たされません。 一緒に働く仲間やお客様も心地よくあってこそ、私にとって理想の状態であると考えます。 まだまだ精進途中ですが、お客様・仲間・自身それぞれに対して以下の意識・取り組みをしています。 ## お客様に対して ``` ご提案された内容をそのまま受け取るのではなく、要望の本質は何かを常に考える システム内部構造やプログラムとしての難易度などは考慮されていないと考え そうした懸念がある場合は、極力専門用語を用いない形で懸念点を伝える 口頭や文章のみの説明ではなく図や具体例を含めて理解しやすさを向上させる ``` ということを意識して取り組んでいます。 そうした行動が実績・成果として評価されることもあります。 ですが、自身としてはまだまだ伸び代はあると思っており 携わるシステムやその業務・業界の知識も学びながら日々改善を試みています。 ## 一緒に働く仲間に対して - 実装の数をこなして技術力を伸ばしたい - 設計などを経験して能力の幅を広げたい - プライベートを重視した無理ない働き方をしたい というようなひとりひとりの理想を知り それぞれの理想を叶えや強みを活かすことのできるタスクの采配をしたいです。 理想をすべて実現することは難しいことであると理解する中で、私にできるベストな采配を試行錯誤しています。 自分自身に対して ``` お客様や周囲を優先しすぎて自分を酷使しない あらゆる物事に対して、自分ならどう受け止めるか・どう動くかを考える すべてを自分で対応するのではなく、適材適所を見極め適切に周囲を頼る ``` ということを意識しています。 学生時代や若手の時は自分が成長しなければという思いから、自分で抱え込むことが幾度かありました。 ただ、 - 自分のキャパシティにはどうしても限界があること - 自分で抱えきれなくなると結果的に周囲に負担をかけてしまうこと を学び、周囲をよく見て相手の負担にならない形で助けを求めることを意識するようになりました。 そうして助け・助けられの関係が構築されると上下関係であってもお互い様という形で距離が近くなることも経験しました。 また、さまざまな経験をする中において `自分より優れている人が周囲にはたくさんいる。だが、その人たちの真価が発揮できていない。` という状況を目の当たりにすることが幾度となくありました。 そうした状況を看過することができず、自分が少しでも変えることはできないかと常に考えています。 就職活動時にIT業界を志すにあたり、エンジニア職を選択した理由も エンジニアの力を最大限引き出すにはまずエンジニアの業務内容が理解できなければならないと考えたからです。 常に驕らず日々改善・向上を意識しながら、システムの効率化やプロジェクトの健全運用、そして関わる人々の真価発揮・快適な仕事を実現していきたいです。

プロジェクト経験

2024年/2年以内

障害者福祉業界 求人検索サイト

# 求人検索システムの改善・運用保守 ## 概要 障害者向け求人検索サイトの運用保守と要望対応、改善 ## 担当 フロントエンド・バックエンド問わず基本設計から〜リリースまで一貫して1人で担当 ## プロジェクト規模 全2名(PM1名,SE1名) ## 使用技術 PHP, MySQL, HTML, CSS, jQuery, AWS ## 参画経緯 1人の方が社内の他業務と兼務して運用保守されており、追加開発はほぼ行わず不具合には対応する程度だった。 フロントエンド / バックエンドの開発経験があり指示がなくても自ら効率化・改善を提案実施できると 弊社社長からの推薦によって参画が決定し、開発を一手に担うこととなった。 ## 実績 運用スタッフからの掲載文や画像の変更に対して、対応箇所の精査から改修そしてリリースまで1人で担当している。 定期作業として、複数の外部システムからのデータ取り込みとその反映を実施している。 ## 課題 ``` 1. 外部システムから求職者情報は連携できているが、求人情報の連携が実装できておらず手動登録をしている状態だった。 外部システムの求人情報を当システムの求人情報として取り込みたい。" ``` ### 取り組み 当システムの求職者登録API呼び出し処理と外部システムのAPIドキュメントをもとに、求人情報取得APIの呼び出しからデータ登録までを実装した。 ### 工夫点 まず必須パラメータのみで実データを数件取得してレスポンス形式を把握し、当システムのどのテーブル・どのカラムに当てはめるべきかマッピング表を作成した。 足りない要素についてはカスタマイズ項目があるかなどを外部システム運用者に確認、当システムでの表示フォーマットの要望なども合わせてヒアリングした。 外部システムのユニークIDを保持するカラムを新設し、照合して新規登録 / 更新 / 削除の処理を分岐した。 SQL負荷軽減のため1件ずつSQLを発行するのではなく、それぞれの対象リストを形成し一括SQLを作成した。 新規登録 / 更新 / 削除の一括操作について、テーブルや対象カラムを変更し他処理でも利用できる共通メソッドとして実装した。 SQLの最大文字数超過を防止するため、各カラムの最大文字数をもとに一括操作可能件数を定義、制御を追加した。 取り込み実行完了後、取り込み総数、新規登録 / 更新 / 削除それぞれの実行件数を画面に表示した。" ### 成果 平均約1500件の求人情報について、1分弱で取り込みが完了できるようになった。 ``` 2. GitHubへのマージ後に自動デプロイを構築していたが、現在エラーが発生してしまいデプロイが実行されない。 エラー原因の特定・解消 または 新規の自動デプロイを構築して欲しい。 ``` ### 取り組み 将来を考えた上で専門外が安易に構築するのは危ういと考えインフラエンジニアを参画させたいという提案し、自社の技術に信頼がおけるインフラエンジニアを斡旋、参画につなげた。 ### 工夫点 依頼があった際、まずはEC2など調べながら自分で対応できるかを確認した。 今後企業として拡大の計画がありシステムもより本格的に運用されていること・私自身がインフラ経験が浅く現状では調べながらの構築しかできないことから、将来的にトラブルが発生しインフラ再構築になるリスクなどを考えると、本格的に専門知識のあるインフラエンジニアに構築を依頼した方が良いと判断した。 単にインフラエンジニアの参画を提案するだけでなく、自社内で技術力・コミュニケーション力などを考慮して対応ができるインフラエンジニアを抜粋し、自社営業などに該当エンジニアの稼働を確保できるかなどを確認した。 参画したインフラエンジニアに現状と要望を伝え、構築にあたりアプリ側でのエラーが発生した際はエラー解消に協力した。 ### 成果 デプロイエラーが解消がされ自動デプロイが動くようになった。 インフラエンジニアが参画したことにより、インスタンスの最適化、各種環境の構築など本格的なインフラ整備も始動することになった。 自社からの増員を斡旋し、自社営業にも貢献したと社内で大きく評価された。

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

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

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

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

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

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

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

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

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

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

マネージメント能力

自社エンジニア
1. 理念と行動指針を浸透させる 2. 人事評価制度における目標設定のサポートを行い、メンバーが自己成長して会社に貢献している状態を作る 3. 業務や社内における不安などを解消し、帰属意識を高める(離職を防ぐ)
# 1. 理念、行動指針を浸透させる ## 考えたこと 全社集会など経営陣と定期的に交流する環境がなく、エンジニアが理念や行動指針について見聞きする機会が少ない。 概念的な内容であるため、日々の具体的な行動と結びついていない。 ### 工夫したこと 人事評価において利用するキャリアシートの別紙資料として、理念と行動指針を添付することを提案し採用された。 行動指針について説明する際、具体的な行動例を伝えた。 理念や行動指針に沿った行動があればこれが合致していると都度伝えた。 「理念をすぐには思い出せない、自分がどのような行動をとるべきか分からない」 と話していたメンバーが、 「理念や行動指針について一字一句とまではいかなくてもすぐに思い浮かぶ、自分のどのような行動が理念や行動指針に沿っているのか判断ができる」 と変わった。 上記事例を見て、キャリアシートの別紙資料に行動指針に沿う行動の具体例も添付することとなった。 # 2. 人事評価制度における目標設定のサポートを行い、メンバーが自己成長して会社に貢献している状態を作る ## 前提 自社の人事評価制度は、等級などによる厳格な基準はなく個人それぞれが成長したい事柄を記載してそれを達成できたかどうかを評価する。 給与・賞与のための評価ではなく、個人それぞれが思い描くキャリアへの計画を目標を達成した結果を評価したいという社長の思いがある。 ## 考えたこと 人事評価が導入される際、メンバーからは今までの業務に加えて新たな何かをしなければ評価されないのではと不安の声があった。 そこでキャリアシートの書き方以前にまず、この制度は会社の都合ではなくメンバー自身のやりたいことを評価に反映するためのものである、と理解してもらうことが大切と考えた。 また、メンバーによって記載の質量に差があり、記載が少ないことにより成長が見られないと判断される危険性がある。 ## 工夫したこと キャリアシートを書くタイミング(目標設定時・中間面談時・評価面談時)に以下を伝えた。 ``` ・個人のやりたいことや伸ばしたいことを目標にして、それに対する頑張りを会社が評価に反映するための制度である ・常駐先が異なるなどの理由で業務で意識していることや頑張っていることをすべて見れているわけではないので、その頑張りを伝えて欲しい ・常駐先が同じであっても記載のないことを勝手に補足して評価するのは不公平につながるため、原則記載のないことは評価ができない ・どんなに些細なことでも記載がないと評価できないため、自分にとっては当たり前の行動でも遠慮なく書いて欲しい。もし評価に関係ない記載があっても、評価者としてこちらで判断するので任せて良い。 ``` 経験が浅く具体的な目標が書けないと悩むメンバーに対しては「1年後・3年後くらいの自分をイメージして、そこにたどり着くまでに必要なこと、今できることを書いて欲しい」とアドバイスした。 共通して「あなたの今まで・これからの成長を、会社として評価をするために協力して欲しい」と繰り返し伝えた。 結果、会社からも メンバーの目標設定に対する意欲が明らかに変わった。自らの成長を意識した目標を設定できており、それを達成することにより会社への貢献も実現できている と高く評価されている。 # 3. 業務や社内における不安などを解消し、帰属意識を高める(離職を防ぐ) ## 考えたこと 基本的に常駐先勤務であり、フルリモートもしくは出社しても常駐先であることがほとんどのため 機会を作らないと会社と関わることが少ない。 会社行事や役割を無作為に増やすと、常駐先との時間調整が発生したり業務外でやることになったりしてしまい それはメンバーの負担になってしまう。 常駐先が同じでない限り他エンジニアと交流する機会がないためか、会社内に知っている人が少ないと答える人が多い。 ## 工夫したこと 月1でリモートでの状況報告兼雑談会を設定した。 雑談会開始当初は都度メンバーに都合の良い日を聞いて調整していたが、 返答が待つことにより確定に時間がかかる・都度回答が必要になることから各人への負担が大きく参加率も悪かった。 そこで開催日を毎月第二木曜日の固定開催に変更した。ただし参加は必須にせずあくまで任意として参加ハードルは下げた。 雑談会に慣れるまでは私が進行役をしてできるだけいろんな人に話が回るように意識して声をかけた。 雑談会の開催が定期化した頃合いを見て、進行役をメンバー持ち回りに変更した。 メンバー持ち回りに変更するにあたって、おおよそのタイムスケジュールの用意・雑談のテーマを揃えておくなど 会話や進行が苦手な人でも負荷が少なく担えるようにした。 チャットツールにて月次で 稼働負荷は高くなっていないか、心身の調子は良いか、面談を希望するか のアンケートを取るようにして、雑談会に参加できず状況報告を聞けないメンバーも声を上げることができるようにした。 メンバーとの会話の際は、話を遮らない・指摘の前にまず褒めることから入る・些細なことでも少し大袈裟なくらい褒めるを意識している。 自社に複数あるエンジニアチームにおいて私の率いるチームは安定して離職率が低く、人事評価での伸びも良いということで社内での評価は高い。 その評価から、チーム配属を問わず新卒や中途でも伸び悩んでいる人のメンタルケアや相談なども依頼されることがある。

このマネージメント能力は公開されていません

アピール項目


アウトプット

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

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

未入力です

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

# 自ら考え自ら行動することが評価される環境 どのような業務においても自身が理解し、納得してから作業をしたいと考えています。 そのため、言われたことをそのまま実行するのではなく以下を意識しています。 - 本当に求められていることは何か - 求められていることに対する現状できる最適なアプローチかどうか - 優先すべきは質、時間どちらか ただし、理解ができないとまったく動かないということはありません。 自身の理解が追いつかない物事もあるはと思っているので その際は作業の合理性が分かることを重要としています。 基本的には質の向上を常に目指していますが、時間がない取り急ぎ実現したい といった場合は時間に合わせて検討・提案をします。 そうした意見やアプローチについて、正誤以前にまず受け止められる環境においては 様々な提案・質問をすることで活躍を評価されています。 受け止められた上で誤りがあれば取り下げますし、無理に自分の案を絶対視して押し通すことはないです。 # 経験年齢など関係なく意見を出し合える環境 常に自分ならどうするか、自分としては何がベストかを考えて動いていますが その考えが常に正しいとは思っておらず他者の視点や指摘を受けてさらに良い形になることも多々あります。 ですので自身が立場が上の方に意見することはもちろん、自身より若手の方々からも指摘も喜んで受けたいと考えています。 そうした多様な視点を交えて業務に取り組むことができる環境において - 自身の意見を発信すること - 他者の意見を引き出すこと を高く評価されています。 # 気軽に褒め合う環境 レビューなどで指摘をすることは日常であっても、褒めるという行為は意外としていないのではないでしょうか。 指摘はすべてが正論であっても数が多くなると受け止める体力も必要だと思います。 ですので私は ``` 指摘をする際は必ず褒めや感謝を添える 些細なことであっても良い・素晴らしい・素敵・助かったなどを伝える 依頼に対応してもらえた際は少し過剰かと思っても素直な感謝を伝える ``` ということを意識しています。 褒められることを嫌がることは稀でしょうし 嬉しい、感謝されるのであればまた動きたい、と思ってもらえればより良い流れを生むと考えています。 私がリーダーを務めるプロジェクトにおいてはこの意識がメンバーへも波及し 気軽な感謝の伝え合いが発生しておりメンバーのモチベーションも高く維持ができています。 こうした気軽に褒め合う環境において 私自身だけでなく周囲のパフォーマンスも向上させることができていると評価を得ています。

キャラクター

直近で一番やりたいこと
マネジメント力を上げたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / プレゼン力 / 巻き込み力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
プライベートとの両立
やりたくない分野
金融 / アダルト
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 勉強会でLTをよくする
その他のやりたいこと・やりたくないこと

言語に対して選り好みは特になく、どれでも学んでみたい

やりたい事

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

基本プロフィール

年齢
今年で30代中盤
好きなテキストエディタ
VSCode,PhpStorm
希望勤務地
リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
未入力
ご意見箱

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

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

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