【ゴールデンウィーク営業のお知らせ】 2025年4月29日(火)~2025年5月6日(火)の期間を休業とさせていただきます。 ※4月30日(水)、5月1日(木)、2日(金)は通常営業いたします。 ※休業期間中にいただいた審査申請については、結果をお返しするために数営業日いただくことをご了承ください。

ID:39200さん

2025年4月回 指名


まだ何もありません

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

  • クラフトバンクがID:39200さんのレジュメを見ています。
    2025.04.25
  • コントロールテクノロジーがID:39200さんのレジュメを見ています。
    2025.04.24
  • イオンネクストがID:39200さんのレジュメを見ています。
    2025.04.23
  • LectoがID:39200さんのレジュメを見ています。
    2025.04.22
  • SpeeeがID:39200さんのレジュメを見ています。
    2025.04.21
  • LayerXがID:39200さんのレジュメを見ています。
    2025.04.21
  • delyがID:39200さんのレジュメを見ています。
    2025.04.21
  • ログラスがID:39200さんのレジュメを見ています。
    2025.04.21
  • コドモンがID:39200さんのレジュメを見ています。
    2025.04.21
  • Sparkle AIがID:39200さんのレジュメを見ています。
    2025.04.19

3年後の目標や野望


技術に尖ったエンジニアでありたい。

技術に尖っていたい。 何が問題 / 課題なのか、何を解決すればよいのか、 解決すると何が嬉しいかを意識していく。 技術で、世の中の何か少しでも便利 / 快適になれば嬉しい。 機械学習 / AI に興味があり、関わりたい。 機械学習 / AI は、これから世の中を変えるインパクトがあるはず。 生成系のAIを使用すると効率が上がるが、任せてよいところ、人がもっと介入しないといけないところがあると感じる。 うまく使っていきたい。

プロジェクト経験

2024年/2年以内

金融会社 DQM(Data Quality Monitor) システム運用

## 2024年1月~現在 ### [システム概要] DQM(Data Quality Monitor)システム: AML(アンチ・マネー・ロンダリング)に関するチェック状況を可視化するシステム。 やり取りされた電文に対して、どの程度チェックが実施され、どの程度エラーが発生しているかを把握する目的で構築。 ### [技術] ・Tableau ・Alteryx ・JP1 ・Oracle ・GitLab ・SVN ・Jira ### [規模] 10名 ### [主な役割] ・顧客要望に応じたダッシュボードの修正およびリリース対応 ・データ処理フローの修正 / 改善 ・運用ドキュメントの整備  ・フロー一覧 ( 入出力の明確化 )  ・データソース一覧( 参照関係 / 影響範囲の明確化 )  ・ジョブフロー図 ( 品質基準ごとの処理内容とデータ流れを俯瞰 )  ・フロー障害発生時のリラン手順書( 障害ポイント別の対応フロー整理 )  ・各フローの詳細 ( フロー内にコメント記述 ) ・Tableauフローのパフォーマンス改善  ・夜間バッチ処理が従来の 約3時間から 8時間以上に増加  ・圧縮処理に時間がかかっていることを特定し、スペースのみのデータ項目をトリムすることで処理時間を約3時間に短縮 ・Alteryx Worker Nodeの追加導入と環境構築  ・処理多重化のため、Alteryx Serverに加えてWorker Nodeを構築  ・実行可能数を2多重 → 6多重( Server 2 + Worker 4 )に拡張 ### [課題 / 問題点] ・Tableauフロー異常時のリラン対応が煩雑で、復旧まで時間を要する ・処理フローが複雑で、全体像が把握しづらい  → ドキュメント整備を通じて、可視化 / 標準化を推進中。    障害時や問合せ時の対応迅速化 / 品質向上に貢献

2022年/1年以内

保険会社 時価評価システム

### 保険会社 時価評価システム ### [期間] 2022年8月~2023年6月 ### [システム概要] 徴収した保険料や支払保険金などの実績データをもとに、将来発生する保険金やCSM(Contractual Service Margin / 契約サービス・マージン)を予測するシステム。 予測データは集計後、経理部門に提供され、損益計算書や貸借対照表の元データとして活用される。 ### [プロジェクト概要] 国際財務報告基準( IFRS :イファース )対応の一環として、既存システムのリプレースを実施。 本番稼働は2025年を予定。開発は外部ベンダが担当し、フェーズ1〜3の開発は完了。 本プロジェクトはテスト工程をフェーズを4段階に分けて進行しており、フェーズ2のテストからフェーズ3である顧客テストまで参画。 ### [技術要素] * SAS * JP1 ### [チーム規模] 4名 ### [担当業務] ・顧客との調整 / 進行管理( 本番稼働を見据えた課題整理と対応 ) ・JP1ジョブの登録 / 管理 / 実行 ・J-SOX対応:会計監査向け内部統制チェックリストの作成 ・外部ベンダが作成した各種ドキュメント / テストケース / テスト結果エビデンスのレビュー ・データ復旧作業 ・リリース準備 / 申請業務 ・問合せ対応およびその他の周辺業務全般

2021年/2年以内

Salesforceを主軸とした事業拡大

###  Salesforceを主軸とした事情拡大 ### 2021年7月~2022年7月 --- ### [主な業務] 1. スキル習得と資格取得 ・Trailheadおよび社外セミナーへの参加によるSalesforce知識の習得 ・以下の資格を取得:  ・Salesforce 認定 上級アドミニストレーター ( 2021年 9月 )  ・Salesforce 認定 Platform デベロッパー ( 2021年11月 )  ・Salesforce 認定 Platform アプリケーションビルダー ( 2022年 4月 ) 2. 工数算出と技術検証支援 ① Salesforceによる学習塾システム構築時の工数算出方針の策定  - 画面設計書やDBレイアウトをもとに、約700画面から約200画面を抽出し、画面規模 / アクション数 / アクション難易度に基づく工数モデルを構築  - テーブル数 / 画面数や、オブジェクト構成の仮定により算出 ② Salesforceとkintone間の連携実装時の工数算出  - REST APIを想定し、シーケンス図の作成 / 障害対応設計 / 他制御設計等を含む検討を実施  - 管理項目や機能定義も合わせて整理 ③ API参照名辞書の構築方針整理  - キャメル式 / スネーク式に対応したAPI名の統一と命名ルール整備  - 辞書項目:API名、ひらがな読み、意味、略称、案件プレフィックスなど  - 運用方法、辞書格納場所( Confluence or box+Excel )の整備方針も定義 3. 社内業務整備 ・作業票の分類整理( 業務内容別の時間分析用 ) ・IPA「DXアセスメント指標」の社内用翻訳 / 整理( 顧客向け回答支援 ) ---

2007年/2年以上

家電修理コールセンターシステム開発 / 保守 / 運用

### 1. コールセンターシステムCRM初期開発 ### [期間] 2007年6月 ~ 2008年11月 ### [プロジェクト概要] 大手家電メーカーの修理受付向けコールセンターCRMシステムをフルスクラッチで開発。 コールセンター2拠点( オペレータ数:約500名 )での運用を想定した、業務支援 / 顧客対応履歴管理を行うフロントシステムを開発。 ### [担当フェーズ] ・フェーズ1:基本設計 ~ 総合テスト ・フェーズ2:機能追加( 改善要望対応 ) ### [開発規模] 約100Kstep(全体:150Kstep) ### [規模] コールセンタ拠点数:2拠点 オペレータ数:約500名 ### [役割] プロジェクトリーダー( PL ) 開発メンバー15名を統括( 全体30名 ) ### [主な業務 / 成果] ・CRMシステムの設計 ~ 総合テストまで一貫して管理し、期日通りの品質あるリリースを実現 ・拠点ごとに異なる運用方法をヒアリングし、現場運用を標準化することで、業務統一と開発工数の削減を実現 ・技術選定では開発メンバーのスキルに配慮し、C#.NET( Visual Studio )を採用。習熟度に即したスムーズな開発環境を整備 ・フェーズ2では、現場SVやオペレータからの声を元に改善点を反映。現場からの高い評価を得た ### [工夫 / 取り組み] ・CTIやコールセンター運用の知識がなかったため、現場SV / CTIベンダとの定例会等を通じて業務理解を深めた ・東西の運用差異をヒアリングし、業務の統一化を推進( 西日本の拠点の方式をベースに標準化 ) ### [反省点] 担当範囲がCRMに限定されていたため、CTI管理ツールの運用設計には関与できず、全体最適の観点での支援ができなかった点が課題 ### [使用技術 / 習得知識] ・開発言語:C#.NET ・理解を深めた技術:  ・Oracle  ・CTI( サーバ / 通録 )  ・VMware  ・Active Directory  ・WSFC ----- ### 2. コールセンターシステム バックエンド部分初期開発 ### [期間] 2008年12月 ~ 2011年9月 ### [プロジェクト概要] 家電修理向けコールセンターシステムのバックエンド処理をフルスクラッチで開発。 全国約100拠点:1,500名のサービスセンター作業者が利用する、売上 / 請求 / 支払処理を中心としたバッチ処理の設計 / 実装を担当。 ### [担当フェーズ] 基本設計 ~ 総合テスト ### [役割] プロジェクトリーダー( PL ) 開発メンバー8名を統括( 全体35名 ) ### [開発規模] 担当工程:約80Kstep( システム全体:約400Kstep ) ### [規模] 拠点数:約100 サービスセンタ作業者:約1,500名 ### [主な業務 / 成果] ・バッチ処理の設計において、コミットタイミング / リラン方式 / 排他制御等を丁寧に設計し、安定したデータ連携を実現 ・金銭に関わる売上 / 請求 / 支払処理については、要件の深掘りや重点的なクロスチェックを実施。結果として、リリース後も大きな問題なく運用 ・オンライン処理 / 他バッチとの競合リスクに備え、更新順序 / 排他制御などを明確化し、デッドロックの発生を未然に防止 ・連携先6システムとの連携設計を主導。汎用機を含む異種環境との調整にも柔軟に対応し、整合性のある連携仕様を確立 ### [工夫 / 取り組み] ・各バッチ処理の特性や業務影響を考慮し、エラー時の処理方針( 継続 / 中断 / スキップ )を明確化し、顧客と合意形成 ・画面処理とバッチ処理が同時実行されるシナリオを想定し、レコード単位での排他制御や更新順序ルールを設計に反映 ・顧客との信頼関係を築き、仕様未確定領域についても適切な質問 / 調整を実施し、手戻りを最小化 ### [PRポイント] システム間連携が多岐に渡るプロジェクト( 6システム )であり、顧客および他チームとの連携 / 調整力が求められる中、リーダーとして円滑な進行に貢献 ### [反省点 / 学び] 連携先システムとの結合テストにおいて、追加テストの必要性を明示せず依頼したため、実施されずに本番で問題が顕在化  → 改善策:次回以降は「どのような観点 / リスクに備えるためのテストか」を明確に提示した上で、追加テストを依頼することの重要性を学んだ --- ### 3. コールセンターシステム CTIリプレース ### [期間] 2013年3月 ~ 2014年4月 ### [プロジェクト概要] 老朽化したコールセンターCRMシステムのCTI部分を、CTStage( 沖電気製 )からiCTNET( 日立製 )へ移行。あわせてOracleのバージョンアップ等のインフラリプレースも実施。拠点数も従来の2拠点から6拠点へと拡大。 ### [担当フェーズ] 要件定義 ~ 総合テスト ### [開発規模] 約15Kstep ### [規模] コールセンタ拠点数:2拠点=>6拠点 ### [役割] プロジェクトリーダー( PL ) 担当メンバー5名を統括( 全体:20名 ) ### [主な業務 / 成果] ・CTI製品変更による設計リスクを軽減するため、iCTNET開発元( 日立 )と密に連携し、要件 / 設計段階で仕様を明確化。大きな手戻りを回避 ・CTI機能の移行に際して、CTStageとiCTNETでの考え方( イベント制御や設定方式 )の差異を事前に整理し、開発への影響を最小化 ・運用上実現困難な仕様( オペレータのグループ所属設定 )の問題を総合テスト工程で特定し、運用ツールを新規開発することで回避。リリース延期なしでの解決に成功 ### [工夫 / 対応事例] ・問題発生への迅速な対応:  総合テスト中に、オペレータが複数のグループに所属する運用が現実的でない仕様であることが判明。  → 独自の運用ツールを開発し、顧客に運用手順を追加してもらうことで仕様の制約を解決  → 製品仕様変更に依存せず、コスト / 納期を抑えた柔軟な現場対応を実現 ・要件定義:  CTI製品変更により可能となる機能の提案や、顧客の潜在的なニーズを掘り起こし、CTStageにはなかった利便性の高い仕様を導入 ### [各工程での役割] 要件定義:  新旧製品の仕様差異、メリット / デメリットを整理し、顧客へ提案 基本設計:  設計書作成およびレビューを主導 詳細設計~組合せテスト:  スケジュール作成 / 進捗管理、設計書 / 成果物のレビュー、テスト方針 / バグ票管理、品質評価 総合テスト:  テスト項目チェックリスト作成、バグ票 / 課題管理、連携先とのテスト日程調整、品質報告 ### [PRポイント] ・製品差異による仕様上のギャップを技術的 / 運用的にカバーする解決力を発揮 ・顧客調整 / ベンダ連携 / 工程管理を一貫してリードし、スムーズな移行を支援 --- ### 4.コールセンターシステム 保守・運用 ### [期間] 2014年4月 ~ 2019年12月 ### [プロジェクト概要] コールセンターシステムの維持 / 運用を担当。システムの機能追加や改修を行い、安定した運用を支援。定期的な機能追加や新規要求に対応しながら、品質管理と顧客対応を実施。 ### [担当フェーズ] 保守 / 運用および機能追加 ### [役割] プロジェクトリーダー( PL ) / プロジェクトマネージャー( PM ) チームメンバー5名を統括 ### [主な業務 / 成果] ・顧客要望の抽出・整理、機能追加要件の調整を実施し、システムのアップデートを継続的に行い、顧客満足度を向上 ・定期的な機能追加( 1回 / 月ペース )に対応し、システム運用における高い信頼性を維持 ・プロジェクトチームへの指導 / 教育を実施し、チーム全体の能力向上に貢献 ・新機能追加時にはテストの自動化を実施、NUnitを導入してテスト効率を向上 ### [工夫 / 対応事例] ・品質確保のための積極的な関与:  機能追加や改修の際、必ず顧客との打合せに出席し、要件ヒアリングから設計書 / ソースコード / テスト項目のレビューを行い、「丸投げせず責任を持って関与」することで品質を確保 ・新人教育 / テストの自動化:  新規機能追加時に、テスト自動化の導入( NUnit )を推進し、テスト効率の向上に貢献。新人教育も兼ねて、テスト工程での学びを深めてもらう機会を提供 ・海外チームの管理:  オフショア( 中国 )チームを含むメンバーの管理と調整を行い、グローバルチーム間でのスムーズなコミュニケーションと進捗管理を実現 ### [PRポイント] ・機能追加を頻繁に実施し、顧客からの継続的な信頼を獲得。 ・顧客と密接に連携し、リリース後もスムーズに機能追加を行い、常に最適な運用を支援 ・新機能追加に際して、テストの自動化を実施し、品質向上と開発効率化を実現 ### [反省点] ランサムウェアの被害とシステム復旧:  PMとして引き継いだ際、以前からパッチ更新が遅れており、ランサムウェアによりシステム復旧に1週間を要した。  → その後、月次でのパッチ更新を徹底し、リスク管理の重要性を再認識。早期対応の必要性を痛感し、システムのセキュリティを強化

2019年/2年以内

家電修理コールセンターシステム システム移行支援

### 5.家電修理コールセンターシステム リプレース ### 【期間】 2019年6月 ~ 2020年12月 ### 【プロジェクト概要】 自社で開発した家電修理コールセンターシステムをSalesforceに移行するプロジェクトに参画。現行システムのユーザ側有識者として、要件定義から総合テスト、運用テスト、移行設計、移行作業に至るまで、さまざまなフェーズで支援。 ### 【担当フェーズ】 要件定義 ~ 総合テスト、運用テスト、移行設計、移行 ### 【主な業務 / 成果】 ・現行機能の調査 / 調整:  開発ベンダからの現行機能調査依頼に対応し、画面処理やバッチ処理、テーブル定義項目などの調査結果を提供。業務フロー、ER図、機能一覧のチェックを実施し、新システムへの移行をスムーズに進めた ・オブジェクト定義とデータ移行:  Salesforceへの移行に向けて、OracleテーブルからSalesforceオブジェクトへのマッピング作業や、データ抽出クエリの作成を実施 ・設計書 / スクリプト設計書レビュー:  オブジェクト定義、画面処理設計書、バッチ処理設計書などをレビューし、移行作業の精度向上に貢献 ### 【工夫 / 対応事例】 ・CTIとの連携提案:  iCTNET( CTI )やライトニングFAXとSalesforceの連携方式を提案。責任分界点を明確にするため連携サーバを設置し、データ連携を効率化 ・オペレーションの簡素化:  現行システムと新システムで異なるオペレーションフローを整理し、ユーザに新システムでの操作方法を理解させるサポートを実施 ・品質向上への対応:  開発ベンダに対して早期に現行処理の理解を促し、影響の大きい処理や複雑な処理については設計書を複数回レビュー。設計段階で品質確保を徹底 ### 【PRポイント】 ・貴重なユーザ側の経験:  当初は設計フェーズのみの参画予定だったが、顧客からの要望で本番移行まで参加。ユーザ目線での対応を通じて、システム移行における重要な視点を得ることができた ・移行元システム開発者としての知見活用:  自社で開発したシステムの移行において、開発ベンダと密接に連携し、ユーザ側の視点から機能移行の調整を実施。システム移行のスムーズさと品質向上に貢献

2005年/2年以内

伝送パッケージ開発~再開発

### 1.伝送パッケージ開発 ### 【期間】 2005年3月 ~ 2005年8月 ### 【プロジェクト概要】 別部署で受託した伝送パッケージ開発が炎上し、プロジェクトにヘルプとして参加。伝送するServer部分と、Serverへの指示や状況確認を行うManager部分で構成され、担当はManagerの1機能。 ### 【担当工程】 詳細設計 ~ 組合せテスト ### 【役割】 詳細設計: 詳細設計書の作成 製造: スケジュール作成、コーディング 単体テスト / 組合せテスト: スケジュール作成、チェックリスト作成、テスト実施、プログラム修正 ### 【工夫・対応事例】 ・主業務との両立: 別のプロジェクト( 酒造メーカー業務システム保守 )を担当しつつ、炎上案件のヘルプ要請を受けて対応。自分の担当していた窓口業務( 要件確認、打合せ、設計 )は他社に委託し、ヘルプ作業に専念 ・再帰処理の採用: 伝送経路の表示時、全体の伝送経路を可視化するために再帰処理を使用し、ディレクトリ階層を末端まで検索する処理を実現 ・描画処理の性能改善: 伝送状況のモニタリングで、全体表示リストの再描画におけるパフォーマンス問題を解決。前回の表示状況を保持し、差分だけ更新する方法を導入して、表示時間を短縮し、処理の固まりを防止 ### 【PRポイント】 ・設計書なしの案件対応: 設計書が不十分な状況でプロジェクトに参加し、要求事項を確認しながら進行。厳しい工程ながら、3カ月で納品に間に合わせ、品質を確保した ・品質確保: 担当した機能については品質を確保し、顧客からはバグよりも要望が多かった ・ヘルプ作業での貢献: 他社が進めていた難易度の高い処理部分を引き継ぎ、進捗の停滞を解消した ### 【反省点】 オブジェクト指向の経験不足: C#で初めてオブジェクト指向の開発を経験。プログラム自体は問題なかったが、構造化プログラミング的な実装となり、オブジェクト指向的なアプローチが不足していた点に反省 --- ### 2.上記伝送パッケージの再開発 ### 【期間】 2005年9月 ~ 2007年4月 ### 【プロジェクト概要】 伝送パッケージ開発案件で、品質の問題が多かったため再開発が決定。Manager部分のPLとしてプロジェクトに参加。 ### 【担当工程】 基本設計~総合テスト ### 【役割】 基本設計: スケジュール作成、基本設計書作成、レビュー 詳細設計: スケジュール作成、進捗管理、詳細設計書レビュー 製造: スケジュール作成、ソースコードレビュー 単体テスト / 組合せテスト: スケジュール作成、チェックリストレビュー、テスト実施、プログラム修正レビュー 総合テスト: チェックリスト作成、実施、バグ票管理 ### 【役職】 プロジェクトリーダー( PL ) ### 【PRポイント】 ・品質改善に注力: 品質に問題があったため、基本設計から再スタート。PLとしてプロジェクトの再建を担当し、品質の向上に向けた取り組みを行った ・プロジェクト優先度: 本プロジェクトは他の案件を差し置いて優先的に進めることとなり、PLとして積極的にクローズに向けた取り組みを実施

2015年/2年以内

保険会社CRMシステム 保守

### 保険会社様CRMシステム 保守 【期間】 2015年1月 ~ 2017年10月 ### 【プロジェクト概要】 保険会社様のCRMシステムの保守および機能追加を担当。ホストと連携し、データ蓄積、オペレータが参照、帳票出力するシステム。パッケージとしてDynamics CRMを使用したシステムの保守を引き継ぐ。 ### 【【役職】 プロジェクトマネージャー( PM ) 2名 ### 【担当フェーズ】 詳細設計~組合せテスト(要件定義、基本設計、総合テストは顧客にて実施) ### 【役割】 ・詳細設計: 詳細設計書の作成 ・製造: コーディングレビュー ・単体テスト: チェックリストレビュー、バグ票管理、品質評価 ・組合せテスト: チェックリスト作成、テスト実施、バグ票管理、品質評価 ### 【工夫・対応事例】 ・手順書等の可視化: システムの保守フェーズに入った際、作業が俗人化していることを課題として認識し、顧客要望からリリースまでの作業手順書を作成。月ごとの作業報告方法や手順を明文化し、チーム全体の作業を可視化 / 標準化 ・組合せテストの可視化: 顧客環境で実施される組合せテストにおいて、テストデータの作成から環境構築、バックアップ取得、テスト実施までの手順を詳細にまとめ、テスト観点やエビデンスの取得方法を整理。効率的なテスト運営と品質の担保を実現 ### 【PRポイント】 ・保守引き継ぎからのPMとしての貢献: 初期開発リリース後のエンハンス開発が終了したシステムの保守フェーズにPMとして参画。パッケージとしてDynamics CRMを使用していたシステムの保守を引き継ぎ、品質向上や運用効率化を実現

1998年/2年以上

酒造メーカー業務システム保守 / 運用

### 酒造メーカー業務システム保守・運用 ### 【概要】 酒造メーカーの業務システムを保守し、機能追加を行いました。 ### 【技術】 ・COBOL ・CORAL( 汎用機用のプログラミング言語。日本語カタカナでのコーディングに近い形式 ) ・ADM( RDB ) ### 【規模】 5名 ###【役職】 担当、PM( 後半2年 ) ### 【担当での役割】 詳細設計: 詳細設計書作成 製造: スケジュール作成、コーディング 単体テスト: スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正 組合せテスト: スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正 ### 【PMでの役割】 顧客対応: 顧客からの要望を確認し、基本設計から組合せテストを実施。総合テストは顧客が実施 作業全般: スケジュール作成、設計書作成、コーディング、チェックリスト作成、テスト実施、リリースまでほとんどの作業を担当 課金処理や端末追加対応: 顧客要望の確認と、定義グループへの要望をまとめ、実際の定義は定義グループが実施 ### 【PRポイント】 PMとしての貢献: 後半2年間は、大きな追加要望がなくなり人員削減され、1人で運用 / 保守を担当。追加要望があれば、仕様確認、設計、実装、テストまで一貫して対応 汎用機での開発経験: 入社時から汎用機の開発を担当し、アセンブラなどの低級言語を使用。制御系の開発にも携わり、OSに近い部分でのデバッグ経験がある 高難易度プログラム対応: 画面処理のプログラムでは、1本あたり5,000Step以上の大規模なものも多く、現状の動作や追加する影響を慎重に確認しながら作業を進めた ### 【その他】 機能追加: 既存機能への機能追加がメイン。大規模なプログラムに対応し、動作確認や影響範囲のチェックを徹底しながら作業を進行

1995年/2年以上

ヘルスチェックシステム開発

### ヘルスチェックシステム開発 ### [概要] TCP/IPソケットを使用し、他システムの稼働状況を取得・監視、他システムへのコマンド支持を行うシステムの開発。 ### [規模] 5名 ### [役割] 詳細設計:詳細設計書作成 製造:スケジュール作成、コーディング 単体テスト:スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正 組合せテスト:スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正 ### [その他] * システム起動時に立ち上がり終了時まで動作するデーモンとしての処理も作成した。 * デーモンとして行う処理、signal処理、syslogなどの知識を習得できた。

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

マネージメント能力

・問題点 / 課題管理 ・リスク管理
問題点の状況を共有できる状況にする。 解決しないといけない問題点の状況や、未解決問題の把握。 次工程に影響のあるものは解決(もしくはいつ解決するか目処をたてる)するが、 影響のないものは、リリースまでに解決するのか、課題として管理すればよいなどの色付け。 問題点をいつまでに解決しなければいけないのか期限、優先順位、担当、進捗状況など。
顧客向けと内部向けと2つで管理していた。 2重管理になるのは良くない。 が、顧客に関係ないものや、伝えたくない内容のものがあるため。 プログラムの内部的な作りなど、顧客に伝えてもあまり意味を持たない。 抜け漏れがないように、まずは内部向けに、内容によって顧客向けに記載していた。 致命的でなく、見直し範囲が広いものなどの扱いに困ることがあったりした。 (操作方法や、統一性がないなど) 問題点としてあがると、できるだけ早く解決したいし、フォローが入る。 修正しないといけないものの対応を優先し、 ある程度品質が確保できる組合せテストの後半で実施した。

品質管理
開発したアプリケーションの品質を上げ、リリース可能な状態にする。
・発生不具合の分析、類似見直しの策定を実施。  発生した不具合の原因、対策、直接原因、間接原因などから、類似見直しを策定し実施した。  規模の大きい開発の時、単体テストのバグもそれなりの数が出る。  そのため、発生した問題を修正した方に類似見直し~実施をしていただいていた。  が、個人によってかなり差異が出た。  慣れていて大丈夫な方のは軽めにチェック、慣れてなさそうな方の分を細かく見るようにした。  (とくに類似見直しの観点、範囲) ・品質評価、品質向上施策の策定~実施  工程後半で品質評価、状況により品質向上を実施した。  (単体テストや組合せテストで実施することが多い)  品質評価で、以下苦労した点。   ・不具合発生時、バグ表に現象、原因を分類するためのコードがあり、使用して分析した。    が、コードの振り方が、個人により差異があるのが分かった。    結局、1つづつ不具合を見てコードを振り直した。   ・単体テストでは、単純ミスのコードが多く振られていた。    (確かに、単純なミスのものが多かった。)    単純ミスだと分析できないので、極力別のコードに振り直し単純ミスを使用しないようにした。

アピール項目


アウトプット

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

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

・AI / 機械学習 / 深層学習 ・プロンプト(生成系AI) ・テスト自動化 ・クラウドを使用した開発、コンテナ、コンテナオーケストレーション

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

・顧客から感謝されている。 ・興味が持てる業務に就ける。

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
未入力です
その他の特徴
使用言語にはこだわらない / 新しい技術はとりあえず試す
その他のやりたいこと・やりたくないこと

・自動テスト
・リファクタリング
※ 自分で、ここまでやってこれていない。が、必要なことだと考えているため。

やりたい事

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

基本プロフィール

年齢
今年で50代後半
好きな Text Editor
サクラエディタ
希望勤務地
東京都 / 神奈川県
希望年収
800万円
転職ドラフトスカウトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトスカウトに参加すると、企業から年収付きの指名を受け取ることができます。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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