ban

自己推薦一覧

自己推薦はありません

2022年9月回 指名 (未返答 : 0/1件)


3年後の目標や野望


【本業】技術領域を軸にビジネス領域へ仕事の範囲を広げる 【副業】自分の会社の売り上げを1億円以上にする。

【本業】技術は好きだがあくまでビジネスの手段であると考えている。ビジネスの成功に寄与する為に・技術をより効果的に使用する為に、ビジネス(技術外)領域へ仕事の範囲を広げたい(現在でも徐々に取り組んでいます) 【副業】まずは一億円台を突破したいから。

年収評価シート

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

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

2019年/2年以上

3PLシステムの機能改善

新規開発を終えた3PLシステムについて、機能追加を行うために企画フェーズから参画し、要件定義~開発・テストまで一貫して行った。 開発した機能としては以下がある。 - 大手ECサイトと連携し、注文情報を自動連係、自動出荷する - D2Cサイトと連携し、注文情報を自動連係、自動出荷する - 3PLシステム内の在庫や入出荷等のトランザクション情報から請求金額を自動算出する - 自前で基幹システムを持つ大規模顧客のシステムと連結し、出荷情報の取得やその実績の返却等を行う 開発フェーズにおいて、私はPMOとして参画してプロジェクトの牽引を行いつつも、自身で開発やテストにもかかわった。開発チームの規模は2~10名程度。

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

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

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

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

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

2019年/2年以上

3PLシステムの立ち上げ

ロボットを強みとした物流倉庫でのサービス(フルフィルメントサービス)立ち上げから参画し、その後の保守運用まで行った。 システムは主にユーザーが荷物を預けたり出荷するために使用するユーザー側のWebシステムと倉庫内の物品・作業管理や自動化を制御する倉庫側のバッチシステムに分かれるが、私はユーザー側のWebシステムを担当した。 マネージャーポジションではあるが、自身でもアーキテクチャデザインから開発・構築を主導している。参画当初はシステムの設計不備(主に選定したパッケージによるもの)によりほぼ破綻していたプロジェクトを再設計しなおし、内製開発チームを立ち上げ、リリースまで導くことができた。 担当するWebシステムはクラウドサービス"Microsoft Azure"のAzure Functionsというサーバレスアーキテクチャを採用し、スケールしやすく、システムを疎結合に保っている。これにより、OMS(Order Management Sysytem)やECサイト、ユーザー企業の基幹システム等に柔軟に連携することが可能になっている。小規模ユーザー向けにWebブラウザから利用できるポータルサイトも用意している。加えて、システムを疎結合にしたことでサブシステム単位で開発者に業務割り振りができ、効率の良い開発作業を行うことができた。 主な使用技術はNode.js、MySQLが主で、その他フロントエンドにVue.js、自動テストにkarateを採用した。 サービスローンチ後は私のほかのPMポジションが1人、開発担当者が10~20名程度いた。私は開発プロジェクトのマネジメントのほか、非技術部門とのコミュニケーションも行い、会社のサービスの提案・設計・要件策定を行っている。ここでの要件策定後、自部署に展開し、私がプロジェクト担当になれば開発者のマネジメントをしたり、場合によっては私自身が設計・開発・試験からリリースまでを行う。ただし、私は担当システムの専任アーキテクトであるため、担当外のプロジェクトであっても私が設計のレビューを必ず行う。 サービスの初期リリース後も、自動で請求金額の算出・請求書の送付等を行える請求システムを開発したり、Yahoo!ショッピング・Shopify等のショッピングモールや個別顧客のECサイトとの連携を連携先企業担当者とやりとりしながらAPI連携したりと様々なシステム拡張を主導した。

2022年/半年以内

旅行サービスのWebサービス開発マネジメント

航空券やホテルなど、複数の旅行関連のサービスを運営している会社(Online Travel Agent : OTA)にエンジニアリングマネージャーとして参加した。 内製による開発を行っているが、私の入社前はドキュメントが全くなかったり、試験が部分的に・場当たり的にしか行われていなかったり、プロジェクト管理を行う者が不在だったりと開発チームの運営がほぼ機能不全に陥っていた。結果として新規案件は全面開発停止するものの、既存バグ改修でさらなる障害が発生したり、新規入場者がシステムを理解不能でパフォーマンスを発揮できずと大きな問題が多発していた。 私はこの立て直しのために入社した。 入社後すぐに各サービスを開発する各開発チーム全体を横串で支援するチームを発足させ、開発部全体の立て直しを図った(人選自体は入社前にお願いしておいた)。主に取り組んだことは以下である。 ・PMOチームの発足 これは一般的な意味でのPMOではなく、実際のプロジェクト管理を直接的に支援するというより、規定・方針・ツール類の整備等を行い間接的にプロジェクト管理を支援するものである。 具体的には以下のことを行った。 ① プロジェクト管理ツールの使用方法について整備した。 プロジェクト管理ツールが導入されていたが、単なる備忘録としか使用されておらず、各人がバラバラな場所でタスクを起票していたので、プロジェクト管理ができていなかった。 まずはタスクを管理するプロジェクトを管理単位(各サービス単位)で統合し、タスク状態が見えるようステータス管理や担当者アサイン状況、見積もり工数の入力の徹底を行った。 これにより、いつだれが何をやっていていつ終わるのか、次に取り組む案件は何でいつから開始できるのか、等の見える化ができた。その結果、依頼元のビジネスサイドに状況の共有ができるようになり、また人員計画の適正化ができるようになった。 ② ドキュメントの標準化を行い、各チームでどのようなドキュメントをどのように作成したらよいかを提示した。 従来はドキュメントの作成がほぼ行われておらず、また退職者からの引継ぎも完全とは言えずに、現行システムの要件・仕様・設計等を知ることはソースコードを読み解くしかなかった。このため、開発スピードに大きな悪影響を与えていたし、新規入場者も開発参加までに非常に時間がかかっていた。 とはいえ、ドキュメント作成には非常にマンパワーが必要であるし、ドキュメント作成後もメンテナンスのコストがかかる。そのため、開発現場にヒアリングして必要性の高いドキュメントを洗い出し、特に優先度が高いドキュメントからテンプレートを準備して配布し、各開発チームの負担を極力少なくドキュメント作成に取り掛かれるようにした。 これによって開発チーム間の技術交流も図れるようになった。 ③ プロジェクト体制の明確化を行い誰がどんな役割を持っているかを容易に確認できるようにした。 これまでは開発組織外も含めて誰がどんな役割を持っているかが不明確で、何かしら問題が起こった際に誰に確認すればよいかが不明確であった。責任も不明確で、要件や仕様があいまいなまま開発が始まり、リリース後に想定と違うために再改修を行うということが多々あった。 組織の歴史的な経緯からビジネス要件を考える部署が二つに分かれてしまっていたのも責任の希薄化の一端があった。 開発部外の役割の定義まで私が行うのは無理があったので、反対にどういった役割が必要か(プロジェクトオーナー、開発PM、UX担当など)から定義してテンプレート化し、プロジェクトあるいはプロダクト毎に役割を埋めてもらうことにすることで、責任の明確化ができ、担当者の確認もスムースにできるようになった。 ・QAチームの発足 システム開発においてこれまで試験は俗人的・場当たり的に行われており、品質が非常に低い状態であった。しかし、システムに関するドキュメントもなく、設計方針もないまま長年保守されてきたのでシステムは読み解く(リバースエンジニアリングする)には複雑すぎて単体試験始め試験をしっかり行うにはかなり難易度が高かった。そこで、最低限エンドユーザーから見える部分だけは正常化しようとまずはエンドユーザー目線で要件通り動作するかの試験を行うQAチームを発足した。 ただし、まずは要件の確認から必要であったり、体系的に試験を行う知見がなかったので外部ベンダーに委託して試験実施を依頼した。現状は一部プロダクトの限定的な範囲での試験実施を行えているのみであるが、リリース前にエンドユーザーから見えてしまう障害を概ね除去できるようになってきているので、リリース後のロールバック回数は減りつつある。 ・インフラの見直し インフラ起因での障害が多発していたものの、専任担当者が不在で対応が後手になりがちであった。インフラ自体、マネージドサービスはほぼ使用せずにLinux仮想マシン上で構築・運用されていたので、インフラ使用のコストは抑えられていたが、運用コストは非常にかかってしまっていた。 まずはクラウドネイティブなシステムにする方針は立てたものの、アプリケーション側の対応だったりと長期的な計画にならざるを得ないので、まずはApacheやMySQLといったミドルウェアのパラメータの見直しと監視システムの閾値の調整を行い、ある程度はパフォーマンスの向上が出来たとともに、障害が起こる前になるべく検知できるようにした。 上記のほか、プロジェクトマネージャーとして5つのサービスの開発チームを管理した。チーム規模としては業務委託を含めて10名程度。ビジネスサイドからはそれまで統制がとられずに場当たり的に依頼がされていた状態であったので、一旦依頼は私が受けて、要件や依頼の優先度等を確認し、開発チームとの橋渡しを行うようにした。また、そもそもの依頼目的が不明瞭であったものが多かったので、ビジネスサイドに依頼のビジネスインパクトの確認をしたり、場合によってはビジネスサイドと一緒にサービスロードマップを検討しなおしたりした。 その結果、真に優先度の高い、会社(エンドユーザーやビジネスパートナー)への貢献度の高い案件に集中できるようになった。

マネージメント能力

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

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

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

アピール項目


アウトプット

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

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

フロントエンド技術 Google Analytics コンテナ技術

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

組織全体の情報の獲得が容易で、積極的に提案や改善実行に取り組める環境。 担当領域が決まっているかどうかにかかわらず、組織の業務について改善の提案や実行、仕組みづくりができるとなおよい。

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 企画立案力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
好きなプロダクトがある
やりたくない分野
ゲーム
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 趣味は仕事 / 起業/創業期のベンチャーにいた
その他のやりたいこと・やりたくないこと

技術的なことは好きですが、技術はビジネスツールの1つとして考えていますので、技術を軸に技術でどうビジネス貢献するかということに興味があり、取り組みたいです。

一人で開発チームをスタートし、後に20名超に拡大したチームのマネジメントをした経験があります。ポジションに強いこだわりはありませんが、マネジメントから実際に自分で手を動かす開発・運用までフェーズによって最適な(より貢献度の高い・より効果的な)ポジションに就きたいです。ただし、技術領域に閉じた仕事よりビジネス領域(他部署)と一緒に仕事を進めたいです。

技術領域においては分野によっては経験値の多寡はありますが、フロントエンドからバックエンド、インフラまで一通りの経験がありますので、強く求められる(課題のある)分野につきたいです。未経験の製品(フレームワーク、ライブラリ、プログラミング言語等)でも早期にキャッチアップ可能です。実際に当初は未経験であった言語やフレームワークを使用して新規サービスの設計、開発を行った経験があります。

やりたい事

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

基本プロフィール

年齢
今年で30代後半
好きな Text Editor
sakura
希望勤務地
東京都 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
1400万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
ban
今年で30代後半
sakura
参加ステータス
不参加
参加回数
17回
累計平均提示年収
918 万円
SIGN UPSIGN IN


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