ID:47480さん

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

  • タックスナップがID:47480さんのレジュメを見ています。
    2025.07.28
  • GROWTH VERSEがID:47480さんのレジュメを見ています。
    2025.07.26
  • カカクコムがID:47480さんのレジュメを見ています。
    2025.07.26
  • GROWTH VERSEがID:47480さんのレジュメを見ています。
    2025.07.25
  • リセがID:47480さんのレジュメを見ています。
    2025.07.25
  • トリファがID:47480さんのレジュメを見ています。
    2025.07.25
  • カカクコムがID:47480さんのレジュメを見ています。
    2025.07.25
  • AlgoageがID:47480さんのレジュメを見ています。
    2025.07.24
  • BASEがID:47480さんのレジュメを見ています。
    2025.07.24
  • mentoがID:47480さんのレジュメを見ています。
    2025.07.24

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など調べながら自分で対応できるかを確認した。 今後企業として拡大の計画がありシステムもより本格的に運用されていること・私自身がインフラ経験が浅く現状では調べながらの構築しかできないことから、将来的にトラブルが発生しインフラ再構築になるリスクなどを考えると、本格的に専門知識のあるインフラエンジニアに構築を依頼した方が良いと判断した。 単にインフラエンジニアの参画を提案するだけでなく、自社内で技術力・コミュニケーション力などを考慮して対応ができるインフラエンジニアを抜粋し、自社営業などに該当エンジニアの稼働を確保できるかなどを確認した。 参画したインフラエンジニアに現状と要望を伝え、構築にあたりアプリ側でのエラーが発生した際はエラー解消に協力した。 ### 成果 デプロイエラーが解消がされ自動デプロイが動くようになった。 インフラエンジニアが参画したことにより、インスタンスの最適化、各種環境の構築など本格的なインフラ整備も始動することになった。 自社からの増員を斡旋し、自社営業にも貢献したと社内で大きく評価された。

2024年/2年以内

障害者福祉業界 社内運用システム

# 社内運用システムの改善・運用保守 ## 概要 オフィス利用者の勤怠や健康状態の管理をするシステムの運用保守と要望対応、改善 ## 担当 フロントエンド・バックエンド問わず基本設計からリリースまで一貫して1人で担当。 SE増員後はPLとしてタスク采配や優先順位決定、設計・開発サポートなども担当。 ## プロジェクト規模 2024年1月~ 全2名(PM1名,SE1名) 2025年3月~ 全5名(PM1名,PL1名,SE3名) ## 使用技術 Laravel8(Blade, JetStream), PostgreSQL, AWS ## 参画経緯 社外チームに外注して実装されたシステムだがその開発チームは解散。 1人の方が社内の他業務と兼務して運用保守されており、追加開発はほぼ行わず不具合には対応する程度だった。 フロントエンド / バックエンドの開発経験があり指示がなくても自ら効率化・改善を提案実施できると 弊社社長からの推薦によって参画が決定し、開発を一手に担うこととなった。 ## 課題 ``` 1. 管理スタッフ用画面の利用者一覧において、利用オフィスを列として示したい。 ``` ### 取り組み 利用者を所属会社ごとにグループ化して表示していたため、利用オフィスでの並び替えもしくはグループ化をした方が業務がしやすいのではないかと提案した。 その結果、利用オフィスでタブ表示をしたいと要望をもらい、列追加ではなくタブで実装をした。 ### 工夫点 利用オフィスを表示したい理由を考えた際、オフィスごとに利用者に対するアクションをしたいのではないかと思い、並び替え・グループ化を提案した。 提案をする際はより業務や実運用を想定しやすいように、文章だけではなく簡単なモックを作成してそのイメージを提出した。 改修対象画面を表示する際のSQLを確認したところN+1が発生していたため、納期に余裕があることを確認した上で合わせて課題を解消し、SQLの発行数を必要最小限に抑えた。 ### 成果 普段直接交流をすることのないスタッフから、画面がサクサク動く・業務がしやすくなったなどの複数の感謝のメッセージをいただいた。 スタッフ情報に普段管理しているオフィスを紐づけたい、企業とオフィスを関連づけたいなど追加の要望につながった。 ``` 2. 管理スタッフを都度SQL操作で追加しているため、登録画面を実装したい。 ``` ### 取り組み 既存である利用者登録画面などを参考にしつつ、Livewireを初めて利用して実装した。 登録画面のみの依頼ではあったが、登録済みの管理スタッフを確認する画面もなかったため一覧画面も実装した。 入力項目の必須表記を提案し採用され、新設画面だけでなく既存の登録画面にも反映した。 ### 工夫点 テーブル情報にて電話番号カラムがNOT NULLになっているが利用されている様子がなかったため仕様を確認したところ、必須である必要はないとのことだったのでNOT NULLを解除した。 参考にした利用者登録画面において入力項目が必須か任意か表記がなく登録ボタン押下時にバリデーションエラーが表示されて初めて分かる状態だったため、必須の表記をしたいと提案し採用された。 必須表記について、できるだけ多くの人が直感的に理解ができるようアスタリスクなどの記号ではなく必須と文字で表示するようにした。 ### 成果 管理スタッフ登録画面が実装されたことにより、管理スタッフからの依頼での開発者によるSQL操作ではなく管理スタッフ自身が任意のタイミングで登録できるようになり、開発者・管理スタッフ双方の作業軽減に貢献した。 必須項目が明確になったことにより、新規スタッフもバリデーションエラーを発生させることなく登録作業が行えるようになった。 ``` 3. カードを端末で読み取り、データ登録をしたい。端末とのシステム連携の実績はない。 ``` ### 取り組み 利用したい端末について、webで公開されている資料は自身で収集し、契約に紐づく独自情報は必要な内容を整理してプロジェクトマネージャーに依頼して該当資料を共有いただいた。 共有いただいたAPI仕様書を読み解き、要件に合わせたパス設計やI/Oの定義を実施した。 端末側の管理システムにて設定する必要のある項目を整理し、プロジェクトマネージャーに共有して設定を依頼した。 端末からのシステムアクセスについて、インフラにも連携をして、特定アクセスのみ許可するなどの設定を相談・確認した。 ### 工夫点 必要な情報や依頼する内容について、資料にある設定画面のキャプチャにマークをつけて添付するなど、できるだけプロジェクトマネージャーが悩まず単純作業できるようにした。 端末からはシステムへ直接アクセスするのではなく、外部連携用ドメインを形成して、外部連携用ドメインでリクエストをシステム向けに変換し、データ操作はシステムドメイン側で行うように切り分けをした。 端末都合の設定値とシステムでカスタマイズした値が分かるよう資料にまとめた。 端末資料を読み込む中で、将来的に利用できそうなステータス変更のAPI機能なども合わせて資料に記載をしておいた。 ### 成果 端末との連携は実現でき、リリース後運用を開始してからも大きな不具合は発生していない。 利用した上で追加の要望が出てきたが、仕様書を丁寧に記載していたことから別メンバーへ仕様書を見ながら改修をして欲しいと依頼ができ、ほぼ質問なく改修対応が完了された。 端末側の使えそうなAPI機能をまとめていた中から、これを利用した追加機能を開発して欲しいと新たな要望を受けた。

2019年/2年以上

障害者福祉業界 障害児福祉運営システム(社内向け拡張)

# 運営・請求支援システムの社内向け拡張開発 ## 概要 既存システムにおける社内専用機能の新規開発と既存機能の社内専用分岐の実装 ## 担当 フロントエンド・バックエンド問わず詳細設計から結合テストまで担当 フロントエンド・バックエンドを一貫して1機能丸ごと担当することもあれば、複数機能のバックエンドを一括で担当することもあった。 ## プロジェクト規模 全約25名(PM1名,PL4名,SE15名,PG5名) 在籍チーム構成約6名(PL1名,SE5名) ## 使用技術 Laravel(5.5), Nuxt.js, Go, MySQL, PHPUnit ## 参画経緯 外販向けに実装していたシステム開発に携わっておりシステムの構造を知っている 社内運用でどういった工夫がされているかなど大まかに把握している といった点からプロジェクトに新規参画するエンジニアの開発主導を見込まれ参画が決定した。 ## 実績 外部システムについて、システムに取り込むための項目の照合や検証・設計・実装(ダウンロード・インポート用のCSV形成を含む)・テスト・保守まで一貫して1人で担当した。 システムの初期開発から携わっていることにより実装の経緯などを知っており、それらを元にした意見や懸念などが重宝され、他メンバーよりも設計の早い段階から議論に参加した。 新規実装の際、関連する既存機能のメモリ負荷を検知し、工数に余裕があることを確認した上で負荷軽減・速度改善を実施した。それによりユーザーからの該当箇所の動作が重いという問い合わせが削減された。 開発環境やテスト環境での試験データについて、関連テーブルを紐づけた形でレコードを量産・管理できるExcelを自主的に作成した。個人やチーム利用を目的としていたが結果として他チームも利用するようになり、データ作成時間やデータ不整合のトラブルが削減した。 ## 課題 ``` 1. 大規模な開発として新規参画エンジニアを投入することになった。 別部署別システムを担っていた開発リーダー、外販システムに携わっていた既存エンジニア2名、新規参画エンジニア5名の体制。 開発リーダーは自身のタスク把握や他チームとの連携で手が回らないので既存エンジニア2名で5名の新規参画サポートをしなければならない。 ``` ### 取り組み 従来、開発ツールの導入手順や使用言語などの資料はあったがまとまっていなかったため 既存資料へのリンクをまとめたり稼働しているGitリポジトリの一覧を新規作成したりと、新規参画者対応の資料として整えた。 GitHubやコミュニケーションツールのアカウントなど、開発に必要な権限一覧を作成して事前に発行者へ依頼し 参画日までに必要な権限を全員分取り揃えた。 Windows,Macそれぞれの利用者がいる中で5人分の開発準備をサポートし、リモートでの開発が開始できる状態にした。 ### 工夫点 コミュニケーションツールの導入手順や各チャンネルの用途説明、参画前日までに迎える側が用意しておくべきアカウントや手続き一覧など 開発作業だけでなく新規参画者がオフィスへ初出勤されてからローカル環境での作業開始ができるまで、を考えて資料を参画日前までに作成した。 人数分のチェックリストを作成しておき、できた部分にチェックを入れてもらいつつ作業を進めた。 途中で発生したエラーなどはチームメンバー全員が見れるチャットですぐさま共有し、同様の事象での質問が減るよう努めた。 また、サポート完了後にそのチャットを遡り、参画準備中のトラブルシューティングとして資料に追加した。 ### 成果 新規参画者5名一括の参画サポート・環境構築だったが、事前に準備のおかげで約2日で全員がリモートでのローカル環境における作業が開始できた。 従来の新規参画者サポートの経験から3,4営業日はかかるのではと言われていた中で、迅速に開発着手できる状態にできた。 コミュニケーションツールの導入手順や事前アカウント発行リストなどはチーム外からも重宝され、プロジェクト全体の参画資料として利用されるようになった。 ``` 2. 非同期処理の実装に伴い、Go言語を利用することになった。しかしチームにはGo言語経験者が1人もいない状態である。 ``` ### 取り組み チームリーダーが文字列を返却するだけのGETメソッドAPIが動く状態は構築しており、そこから先はリーダー含めたチーム4名でモブプログラミングをすることになった。 一定時間ごとにドライバーを交代しつつ、1APIを協力して実装した。 ### 工夫点 通常開発がLaravelであり静的型付けに馴染みがなく型エラーがよく発生していた中で、誰よりも早くエラー箇所を特定し修正することが多かった。 頻発するエラーをトラブルシューティングとしてまとめたり、誤字を発見した際に開発は続行してもらい裏で類似誤字を探して修正したりと 自身がナビゲーターのターンであっても円滑に開発が進むようサポートを積極的に行った。 後からコミットログなどを見て実装順序が追えるよう、定期的にこの時点でコミットしませんかとこまめに促した。 ### 成果 開発リーダー含め全員が1APIの実装ができる程度まで理解をした状態でモブプログラミングでの実装を完了することができた。 その後他開発と並行するため全員がGo言語での開発はできないとなった際、Go言語の理解が最も早く高かったとして開発リーダーから残りのAPIの開発担当を任された。

2019年/1年以内

障害者福祉業界 障害児福祉運営システム(新規開発)

# 運営・請求支援システムの新規開発 ## 概要 全国の施設における利用者の管理や利用者・行政それぞれへの請求計算と書類作成を行うシステムの新規開発 ## 担当 フロントエンド・バックエンド問わず詳細設計から結合テストまで担当 大まかな機能ごとに小チーム開発を行い、画面単位でフロントエンド,バックエンドを一貫して担当することもあれば、機能のバックエンドを一括で担当することもあった。 ## プロジェクト規模 全約16名(PM1名,PL4名,SE10名,デザイナー1名) 在籍チーム構成約4名(PL1名,SE2名,デザイナー1名) ## 使用技術 Laravel(5.5), Nuxt.js, MySQL, PHPUnit ## 参画経緯 1つ前に参画していたシステムの初回リリースが完了し初期不具合も落ち着いたことから、大型プロジェクトに招集された。 数年前に中止・凍結されてしまった今回新規開発の前身となるプロジェクトに参画していたことから 参考にする予定の資料について、作成の経緯や背景などの情報も覚えている範囲で構わないので提供して欲しいと依頼された。 ## 実績 別機能からのデータ連携について、設計当初は当機能表示時に情報取得する形となっていたが、処理の負荷が高くなることやデータ不整合の可能性を提示し、別機能担当者とも議論して別機能でのデータ保存時に連携をする形式に変更した。 結果、設計に含まれていた情報取得時のデータ不整合への考慮処理など一部を削減でき、処理を向上させた。 テーブル設計について、懸念されるケースなどの例をあげなからデータ構造を確認した。その際、いくつか考慮漏れが発見され改善につながった。 複数画面におけるAPI開発をほぼ一手に担うことにより、他メンバーがフロント開発・機能制御に注力できるようにした。 DBテーブル作成や各環境への反映・環境変数の検討反映など開発着手前の環境整備を一手に担い、各メンバーの作業開始前に整備を完了した。 ## 課題 ``` 1. 過去凍結したプロジェクトで実現しようとしていた機能をシステムへ追加したい。 過去凍結したプロジェクトでの機能の設計・実装をメインで担当していたことからメンバーとしての開発だけでなく 育成目的として配置するリーダーのタスク采配などのサポートも依頼された。 ``` ### 取り組み 過去プロジェクトで利用していた資料の発掘・整備を実施し、資料に記載のなかった当時の設計意図なども含めてチームメンバーに共有した。 改修の必要な箇所とそうでない箇所をチームで決めた後、過去ソースと照らし合わせて担当箇所の分担を采配した。 ### 工夫点 過去プロジェクトでの要望と現プロジェクトでの要望を整理し、踏襲すべき設計と改善すべき設計を分けた。 各所へのデータ連携APIのコール実装を依頼する際、APIの実装仕様だけでなくどういった意図でいつどの様にデータが活用されるのかも説明に含めた。 ### 成果 過去プロジェクトの設計だけでなく実装も一部復活・流用できたことにより、0からの実装よりも工数を大幅に削減できた。 連携の仕様だけでなく意図も合わせて説明したことにより、連携元各所からもデータ連携タイミングの提案などをもらうことができた。

2018年/1年以内

障害者福祉業界 障害児福祉支援計画作成システム

# 福祉支援計画作成システム開発 ## 概要 児童福祉における1年間の支援の計画書作成システムの新規開発 ## 担当 フロントエンド・バックエンド問わず、詳細設計からリリースまで担当 開発メンバーとしての参画であったが設計も学びたいと志願し、画面設計 / データベース設計をメインの作業者として担当した。 ## プロジェクト規模 全約11名(PM1名,PL3名,SE6名,デザイナー1名) 在籍チーム構成約4名(PL1名,SE2名,デザイナー1名) ## 使用技術 Laravel(5.5), Vue.js, MySQL, PHPUnit ## 参画経緯 過去プロジェクトにおけるバックエンド開発において実装の早さと視野を広く持って開発する姿勢を評価され、修正業務より1から作る部分を担当して欲しいと声をかけられた。 ## 実績 ステータスによる画面制御が複雑な機能に対し、マトリクスを用いて整理をすることにより抜け漏れを防止し、確認者にも分かりやすくまとめた。 結果その機能でのパターン考慮漏れはゼロだった。また、確認者からも見やすいと評価いただき、他機能でも確認作業における雛形として採用された。 ## 課題 ``` 1. 参画当初、PLが設計を担当するということで設計を待つ状態であったが PLが前担当プロジェクトの対応に追われており設計に取り掛かることができておらず、スケジュール管理などもうまく回っていない ``` ### 取り組み プロジェクト運用について、スケジュール作成など私ができる範囲は代わりに動きたいと進言し、一部を担当するようになった。 設計についても、その当時運用されていたスプレットシートをもとに着手をしたいとPLに提案した。 システム全体のテーブル設計などは未経験だったが機能単位での複数テーブルの設計は経験しており、その際の能力を見ていたPMが任せても問題ないと判断してくださり レビューをしていただく前提でシステム全体のテーブル設計を任された。 テーブル設計完了後は作業の報告頻度や資料の完成度が評価され、そのまま画面やAPIの設計も担当した。" ### 工夫点 資料が何もない状態から作り上げるよりも、何かベースがあってそこに指摘修正をする方が労力が少ないと考え、PLの作業負担を軽減するためにベース作りを立候補した。 まず1テーブルずつ・基本的な認識齟齬がなくなって機能ごとの複数テーブルというように、作業依頼者の不安や作業後の手戻りが減るよう 最初は細かく確認依頼を出し認識を合わせた上で一定の作業を進めるようにした。 作業資料は共有しいつでも閲覧可能にしておき、PLが対応の隙間にわずかでも見て随時指摘ができる形を取った。 データベース設計においては、開発時にテーブル構造の変更が頻発する経験を過去にしていたため、そういった手戻りを削減したい思いから 何に着目して設計をすべきかなどを指導いただいた上で作業に取り組んだ。 ### 成果 PLが取り組む余力がなく設計スケジュールが遅れつつあったところを、予定通りのスケジュールまで戻すことができた。 開発中に何度か仕様変更があったが 設計時の動きやPLの負担が軽減された実績から、その後の開発においてもスケジュールなどの相談に乗って欲しいとサブリーダーとして任命された。 リリースを終えたのち、数年が経過するが大きなバグやシステム改修しなければならないという話は出ていない。 ``` 2. 従来運用されていたスプレットシートについて、マクロや関数を用いてアルゴリズムが構築されているような、単純なデータ形成だけではない複雑な構造をしている ``` ### 取り組み スプレットシートを作成し、利用するスタッフを統括されている方と直接お話する機会を設けていただき、現在の運用からシステムに期待することまで自らヒアリングをした。 ヒアリングの内容・内容を受けて設計の変更した箇所などを資料にまとめ、先輩方に自らの説明をしながらアドバイスをいただいた。 アルゴリズム解析用の質問・回答やそのグループが不定期に変更されると知り、質問を画面に固定文字列で実装するのではなく、データ保持してバージョン管理ができ過去質問・回答も復元できる構成にした。 ### 工夫点 マクロや関数の解析だけでなく、スプレットシートにおける入力方法や解析における意図や目的も合わせて確認をした。 連続する入力項目のずれや抜け漏れを防止するためにスプレットシートで適用されていた色付けなどはシステムにも適用した。 実装を担当するメンバーに、着手時に依頼内容だけでなく担当箇所の目的・用途についても説明をした。 ### 成果 利用するスタッフを統括されている方にアルゴリズムを取り入れ希望も叶え、よく実装してくれたとチームとして賞賛をいただいた。 リリース後、複数回質問のバージョンアップを経てもクリティカルな不具合は発生せず、兼務の運用チームでも安定して保守ができていた。 離脱してから数年後に、追加要望対応がありその際の開発チームから前任者として質問を受けたが、当時の資料を提示して的確に回答ができた。

2018年/半年以内

障害者福祉業界 教室運営スケジュール管理システム

# スケジュール管理システムの新規開発 ## 概要 児童福祉における施設利用スケジュール管理システムの新規開発 ## 担当 フロントエンド・バックエンド問わず詳細設計から結合テストまで担当 デザイナーもいなかったため、画面レイアウトや遷移構成まで担当した。 ## プロジェクト規模 全約6名(PM1名,PL2名,SE3名) 在籍チーム構成約2名(PL1名,SE1名) ## 使用技術 Laravel(5.5), Vue.js, MySQL ## 参画経緯 急遽優先度が上がった開発であり、他エンジニアは深い業界知識が必要な作業に携わっており手が空かない。 当開発は業界知識が少なくても着手できるということで経験・知識共に浅いが動きは良いということで任された。 ## 実績 Vue.jsの経験があるメンバーがいない中、カレンダー機能の実装について https://fullcalendar.io/docs/vue を自ら調べ導入から実装までを担当した。 Laravelにてデータ操作をするAPIを実装し、その値をVueの画面にて操作する実装を行なった。 ## 課題 ``` 1. デザイナーもいない中、スプレットシートを利用している運用をシステムに置き換えたい。 ``` ### 取り組み drow.io を活用して画面イメージ・遷移図を作成した。 作成した図について、プロジェクトの先輩方にレビューをいただき、何度も修正を行った。 ### 工夫点 先輩方にレビューをいただく際、その場で調整できる部分は即座に変更して確認をしていただき、何度もレビューの時間を割かないようにした。 どうしてその形にしようと思ったのか、意図や理由を明記もしくはレビュー時に口頭で説明した。 ### 成果 画面の設計を自分でやり遂げることができた。

2018年/半年以内

障害者福祉業界 就労支援システム

# 就労支援システムの新規開発 ## 概要 全国施設利用者の書類を管理するシステムの新規開発 ## 担当 バックエンドエンジニアとして、実装から結合テストまで担当 ## プロジェクト規模 全約6名(PM1名,PL1名,SE5名) 在籍チーム構成約4名(PL1名,SE3名) ## 使用技術 Laravel(5.5), Angular, MySQL ## 参画経緯 Laravelを使った新規開発プロジェクトということで、設計から知り経験を積めるであろうということと 過去現場での意欲・行動を評価いただき自社から推薦という形で参画が決定した。 ## 実績 Laravel初体験だったが、他メンバーに学びながら進める前提での採用だったにも関わらずわずか2週間ほどで1人で実装ができバックエンドの実装について相互レビューもするようになった。 画面仕様書ベースだと動きが想像できないというお客様の意見を受け、HTMLやJQueryを用いてモックを作成し、会議のその場で動作確認をできるようにした。 モック作成者として会議にも参加し、お客様の要望をできる限り会議の場で即座にモック反映・確認することにより、仕様検討の工数を削減した。

2016年/2年以内

産業ガスメーカー ECサイト

# 産業ガスECサイト開発 ## 概要 産業企業向けECサイトの要望対応、改善 ## 担当 フロントエンド・バックエンド問わず、実装から結合テストまでを担当 ## プロジェクト規模 全3名(PM1名,PL1名,SE1名) ## 使用技術 PHP, MySQL, EC-CUBE, HTML, CSS,JavaScript ## 参画経緯 既存メンバーの離脱などがあり、経験が浅くとも実装ができるエンジニアが求められた際 若手ながらも疑問点などを積極的に質問し、開発するものの意義を考えながら実装ができるとして採用された。 ## 実績 ECサイトの利用者動向を分析するためGoogleアナリティクスを導入することになり、分析できる項目の調査と整理・サイトへの導入・お客さまへ提出する分析結果の作成をすべて1人で行った。 他プロジェクトにおいてもお客様先訪問は原則プロパーのみの中、パートナー参画として初めて訪問に同行するようになった。 常駐先企業がホスピタリティ向上の勉強会をするということで、普段意識していることや取り組んできることを参考にしたいとインタビューされた。 ## 課題 ``` 1. 営業とPMが月次でお客様の要望を確認して、その月の改修を決定するが 実装工数などが分からないままお客様感覚の見積で受けてしまい、結果的に遅延してしまう事象が多発している。 ``` ### 取り組み 自身の担当タスクが無理なく完了できるようになってきたタイミングで、要件整理や見積と開発スケジュールの案作成を担当したいと提案した。 お客様からの要望をもとに、対応整理・見積算出・想定スケジュールを作成した。 ### 工夫点 要望と合わせて提示された見積から長い短い問わず変化がある場合、必ずその変化の理由を添えてお客様からも営業からも納得を得ることができるようにした。 1ヶ月契約分の工数が微妙に余る場合、お客様として無駄が発生しないようにとこちらが気になっていた点などを改善提案として出した。 実装を把握したうえで要件を整理し、全メンバーの並行タスクやバッファも考慮してスケジュールを組むようにした。 ### 成果 スケジュールの遅延と要望に合わない改修が削減された。 当初エンジニアは不参加だったお客様との定期打ち合わせに、是非参加して欲しいと依頼され出席するようになった。 営業との契約に関する打ち合わせとエンジニアとのシステム開発に関する打ち合わせが分けられ、より開発が本格化した。 ``` 2. プロジェクト中盤よりオフショア開発が採用され、実装は海外エンジニアに依頼する形になった。 オフショア開発のノウハウがある人員はおらず、当プロジェクトを含めた数件がオフショア開発を開始したが認識齟齬による想定以上の手戻りが発生している。 ``` ### 取り組み 日本語は理解できるとのことだったため当初は日本人エンジニアと同じ設計書を連携していたが、オフショア用の設計書を書き直した。 進捗について、満たすべき要素をチェックリストとして作成した。チェックリストを記載をしてもらい、できている/できていないを指摘した。 ### 工夫点 設計書の日本語を英語に翻訳してから再翻訳して、意味が変わっていないことを確認した。 日本語ならではの言い換えを極力統一した。(例:入力する、記入する、記載する = 書く) 求めている精度が伝わらない場合、工数は多少かかってしまうがサンプルを1つ作成して提示した。 ### 成果 1ヶ月ほど試行錯誤を重ねた結果、手戻りを削減でき、期限内に期待した品質の機能を完成させることができた。 他プロジェクトから依頼されてノウハウを共有した。その結果他プロジェクトでも手戻りが削減された。

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

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

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

マネージメント能力

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

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

アピール項目


アウトプット

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

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

未入力です

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

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

キャラクター

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

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

やりたい事

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

基本プロフィール

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

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

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

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