ID:64366さん

2025年11月回 指名


まだ何もありません

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

  • OLTAがID:64366さんのレジュメを見ています。
    2025.11.19
  • 合同会社DMM.comがID:64366さんのレジュメを見ています。
    2025.11.19
  • フリーID:64366さんのGitHubを見ました!
    2025.11.19
  • フリーがID:64366さんのレジュメを見ています。
    2025.11.19
  • TRUSTDOCKがID:64366さんのレジュメを見ています。
    2025.11.19
  • noteがID:64366さんのレジュメを見ています。
    2025.11.19
  • LectoがID:64366さんのレジュメを見ています。
    2025.11.19
  • Macbee PlanetがID:64366さんのレジュメを見ています。
    2025.11.19
  • kickflowがID:64366さんのレジュメを見ています。
    2025.11.18
  • タノムがID:64366さんを検討中に入れました。
    2025.11.18

キャリアビジョン


社会貢献や将来性のあるサービスに技術やマネジメントで貢献しつつ、60才以上になっても働くためのスキルを身につけていきたい。

家庭を持ち、いくつかの企業で働いていった結果、子供の未来や日本の社会に良い影響の与える様な何かを残していきたいのが理由です。 今までの経験を活かして、システムやサービスの立ち上げや改善または課題解決をやりつつ、それを将来担っていける人材育成も並行してやっていきたい

プロジェクト経験

2024年/2年以内

ネットショップ作成サービス

## プロジェクト概要 システム運用の安定化と組織のスキル向上を目的に、SREチームの体制整備と暗黙知の形式化に取り組みました。 ## 役割・体制 ### 自身のポジションと役割 - 最初はエンジニアリングマネージャ兼SREエンジニアとして、5名のチームの運営と管理を担当し、システムの可用性向上と運用効率化を推進しました。 - 半年後にはSREマネージャとして正式に稼働し、運用・監視体制の整備、課題管理、他部署との折衝、運用設計をリードしました。 - 具体的には、サーバー負荷対策やアラート監視の基準策定、運用手順の標準化、そして組織内の知識共有やスキルアップ施策(例:SRE留学制度)の導入を推進しました。 - また、暗黙知の体系化とドキュメント整備を通じて、属人化解消と継続的な運用改善に寄与しました。 ### チーム規模と構成 - 5名のSREエンジニアチームの中で、私は最初はエンジニアとして、後にマネージャとしてリードし、運用管理、改善活動、関係各所との調整を担当しました。 ## 背景・課題 - 開発組織全体が、従来の運用や設計に関して「なぜこうしているのか」の根拠や背景を文書化せずに属人的に進めており、情報の暗黙知化と属人化により、運用の効率性とシステムの安定性にリスクが生じていました。 - 具体的には、サーバー負荷対策やアラート対応の対応基準が明文化されておらず、個々のエンジニアの裁量に依存していたため、システムダウン時の対応速度や品質のばらつきが問題となっていました。 - このため、属人化による対応遅延や、運用ノウハウの継承難が最大の課題となっていました。 - また、組織内の情報共有不足から、異なる部署間での連携が進まず、インシデント時の対応や改善策の実施に遅れが生じていました。 ## 実際の取り組み ### 開発環境 - 具体的な開発環境の言及はありませんが、システム監視や運用管理にはAWSを中心としたクラウドインフラを利用し、サーバー負荷監視やアラート設定の基盤を整備しました。 - 運用や監視に関しては、属人化を解消し、継続性を確保するために、標準化された運用手順やドキュメントを整備しました。 ### 設計・改善内容 - 本プロジェクトの最大の改善施策は、属人化していた運用や設計の背景を体系化し、誰もが理解しやすいドキュメント化と標準化を実現したことです。 - 具体的には、運用ルールや対応フローを整理し、関係者が誰でも参照できる状態に整備し、業務の属人化と暗黙知の解消に寄与しました。 - さらに、サーバー負荷対策やアラート対応に関して、明確な対応基準を策定し、迅速な問題解決とシステム安定性の向上を実現しました。 - 組織の文化として、「なぜその運用方法を採用しているのか」を問い直す風土作りを推進し、属人化を防ぐ組織的な取り組みを進めました。 ### その他アピールポイント - 組織全体のスキルアップを目的に、SREエンジニアチーム留学制度を整備し、エンジニアの専門知識と運用能力の底上げ』を図ったことも重要なポイントです。 - 実務だけでなく、属人化した運用知識を体系化し、継続的な改善と知識共有の仕組みを構築したことで、運用の効率性とシステムの安定性を持続的に向上させる土壌を作り出しました。 ## 成果・価値 - 明文化と標準化により、サーバー負荷対策や監視・アラート対応の対応基準を整備した結果、システムの安定性が向上し、運用の対応速度と品質が大幅に改善しました。 - 具体的な数値は不明ですが、対応のスピード向上により、障害対応やインシデント解決までの時間が短縮され、システムダウンの頻度や長時間停止のリスクを低減しました。 - 組織内の情報共有と運用改善の取り組みを通じて、属人化の解消と継続的なナレッジ蓄積に成功し、他部署との連携も強化されました。 - SRE留学制度やドキュメント整備により、エンジニアのスキル向上と組織の運用能力の底上げを実現し、長期的なシステム運用の安定化と組織の成熟化に寄与しました。 - これらの取り組みを通じて、システム運用の効率化と安定性向上により、ビジネスの継続性と信頼性を高め、間接的に顧客満足度向上に貢献しました。

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

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

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

マネージメント能力

開発チーム2つのメンバー管理を主に行っていました。
ローコード開発を主体としたチームを、GCPをベースとした開発チームに変革を行う必要がありました。 今期から追加で見るようになったチームに関しては、エンジニア視点での運用・保守における体制および環境づくりに不安があるとのことで声がかかり、そちらの改善を行う必要がありました。
私以外、Gitを使った開発自体をしたことがないメンバーだけだったので、 CI/ CDの整備やルールの策定など、まずは環境を整えなければならない状態でした。 本格的な開発をしたことがないメンバーに対して、何から身につけてもらうか? どういったツールや技術を採用すべきかを、メンバーがエンジニアとしてやっていける様にチーム運営計画を作る必要があると考え、まずputhon、CloudFunctionsといった組み合わせれば大抵の事が実現できるスキルを優先してレクチャーするといった工夫をしました。 今期から追加で参画したチームに関しては、若手エンジニアメインである為、何が足りていないかを整理しました。その結果、チームに足りていない - クライアントに提供するサービスを運用するための意識 - 可用性や運用フェーズを視野に入れたシステム設計、現行システムの改善 - システムの監視ルールや対応の属人化 これらをまず整備する事を優先することにしました。 実践にあたり、まずは私の方でサンプルやルールや設計の叩きを作成し、レクチャーを兼ねてそれを肉付けしてもらうという形ですすめました。また、その成果物に対してのレビューと認識合わせをこまめに実施しました。

キャリア会員向けポータルサイトの開発チームおよびプロジェクトのマネジメントを行っていました
プロパ、業務委託、ニアショア、社外といった多くの関係者がいるため、それらの橋渡しや連携を行い、かつ開発計画の策定および進行をする必要がありました。 また、大規模なシステム刷新プロジェクトの際には、As IsとTo Beを整理し拡張性や安全面を決裁者に対して説明する必要があり、かつ様々なリスクを考慮して開発進行をする必要がありました。
とにかく多くのユーザーが利用しているサービスである為、システムを止めず安定稼働をさせる事が最重要でした。 その条件でのシステム刷新では、あらゆるリスクの洗い出しを行い、かつ対策を立てる必要があると考え、まずは会議体を整備し、情報の共有を徹底することに注力しました。 システム刷新は数ヶ月以上のスパンでの開発ですが、その間もサービスは様々な施策や改良を行う必要がある為、新旧システムの開発を同時に行わなければならない時期がありました。 その時は、AWS環境であることを活かし、新旧システム並列開発用環境の整備をインフラエンジニアと密に連携して行ないました。そのおかげで、新旧システムの開発者同士がぶつかることなく、スムーズに進行させることができました。

SREグループのマネジメントを行っていました。
- システム保守などに関して組織全般的に慣習的・属人的になっていました。その為、目標として暗黙知から形式知への移行と、SREとしての業務整理の上で適切な組織に運用してもらう環境づくりを行っていました。 - システムのサービス・機能は組織に紐づいておらす、誰が主体的に開発・保守しているかが明確になっていなかった為、SREグループの性質上その辺りの整備も行う必要がありました。 - 同様にAWSリソースも同様の課題と対応が必要でした。 - アプリケーション開発エンジニアにSRE的視点が不足していることが開発組織としての課題でした。その解消の施策として、SREグループに一時的にメンバーとして参加する留学制度の整備を行いました
- 地道に現状整理と課題の抽出を行い、一つ一つ解決をしていく方法を取りました。 - いきなり全てをやると、作業を行う人間にはかなりの負担とモチベーションの低下となる為、少しずつでも良いので持ち回りでこなしていく形にすることで、それを軽減するようにしました。 - 慣習となっている運用やルールについては、私自身が会社のSREチームの人間としては一番新参ということもあり、疑問を投げかけて回答・それをドキュメントにすることで形式知にしていくといった流れを作ったりもしました。

アピール項目


アウトプット

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

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

- Go - Vue.js - kubernetes - AI関連

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

未入力です

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
分析力 / 問題解決力 / 営業力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
金融
その他の特徴
未入力です
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で40代後半
好きなテキストエディタ
vscode
希望勤務地
埼玉県 / 東京都 / 福岡県 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
900万円
ご意見箱

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

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

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