Moo

キャリアビジョン


ヒーロー文化を脱し、背中を預け会える仲間に出会う

私のキャリア課題は、能力そのものではなく、能力が組織に与える副作用の制御です。 複数領域を横断して成果を出せ、未経験の技術領域も短期間で戦力化できる。これらは客観的な事実として経歴が示しています。しかし、この特性が組織に「この人に任せれば解決する」学習を与え、結果として属人化・兼務過多・単一障害点化が常態化します。 組織は短期的に成功しますが、構造としては成長せず、私自身のキャリアも安定しません 次の環境では、キャリア課題で述べた構造が再現されないことを最も重視しています。具体的には以下の3点です。 1. 技術判断を委ねられる相手がいること アーキテクチャの意思決定を議論できる同等レベルの技術者、またはその判断を正しく評価できる技術責任者の存在を重視します。設計判断を独りで完結させ続ける環境では、組織にもに自分にも限界が来ることを経験上知っています。 2. 深さで貢献できるキャリア構造 インフラ・セキュリティ・非機能設計を横断できることが私の強みですが、それは「何でも屋」として消費されるためではありません。技術スペシャリストとしての深い貢献を正当に評価する制度(Principal Engineer、Staff Architect等)が構造として存在する環境を志向しています。 3. 認知的余白が設計に組み込まれていること 全稼働時間がチケット消化や障害対応に充てられる環境では、「まだ起きていない問題を視る」という最も価値の高い仕事ができません。技術調査・設計・先行検討に充てる時間が文化として認められている組織を希望します。

プロジェクト経験

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

2018年/1ヶ月以内

システムリソース管理台帳作成

# 概要 自社で保有しているシステムリソースが台帳管理されていなかったことから、台帳化を試みた # 要件 * 台帳化にあたってのデータ抽出は、プログラムにより自動化すること * 「繰り返し実施する定常作業は自動化すべき」考えから * 抽出プログラムはバージョン管理すること * 社内向けのプログラムであるが、要件変更やメンテナンスのために、変数定義やコメントは適当にしない * 棚卸しの運用ルールを策定すること * 当該の成果物は最新の状態を維持して価値があるため * 台帳の更新手順を設けること * 台帳管理を属人化させないため # 成果 以下のリソースについて、AWS CLIを呼び出し、取得できたJSONを整形し、csv形式で出力するプログラムを作成 * EC2インスタンス * RDSインスタンス * VPC * サブネット それぞれ抽出した項目は以下の通り * EC2 * インスタンスID * Nameタグ * インスタンスタイプ * ステータス * VPC ID * サブネットID * プライベートIPアドレス * パブリックIPアドレス * セキュリティグループID * RDS * Nameタグ * ステータス * DBエンジン * DBエンジンバージョン * インスタンスタイプ * マルチAZオプション * ストレージサイズ * VPC ID * サブネットグループ名 * パラメーターグループ名 * オプショングループ名 * セキュリティグループID * パブリックアクセス許可オプション * VPC * VPC ID * Nameタグ * CIDRブロック * DHCPオプションID * デフォルトVPCフラグ * サブネット * サブネットID * Nameタグ * CIDRブロック * VPC ID * アベイラビリティゾーン * AZデフォルト判定 当初はシェルスクリプトで実装したが、配列の扱いに難があったので、後にPythonへリファクタリングした # 申し送り セキュリティグループの台帳化についてもシェルスクリプトでの実装を試みたが、JSONの返却値にクセがあり、実装できなかった。Pythonで解決可能と思われるが、案件の優先度が変わり、実装には至っていない

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

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

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

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

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

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

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

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

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

マネージメント能力

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

アピール項目


アウトプット

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

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

Docker

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

技術判断を議論できる同等レベルの技術者、またはそれを正しく評価できる技術責任者の存在 技術的負債の解消に組織としてリソースを割く文化 設計・技術調査に充てる認知的余白が文化として認められている環境

生成AIの活用状況

日常的な情報収集・業務活用
ChatGPTやGeminiなどのチャットツールを、情報収集、ドキュメント作成、翻訳に日常的に活用

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
分析力 / 問題解決力 / 責任感
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
未入力です
その他の特徴
未入力です
その他のやりたいこと・やりたくないこと

アーキテクチャの意思決定に関与できるポジション

やりたい事

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

基本プロフィール

年齢
今年で30代中盤
好きなテキストエディタ
vim
希望勤務地
東京都
希望年収
1200万円
ご意見箱

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

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

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