JayGatsby

自己推薦一覧

自己推薦はありません

2021年11月回 指名 (未返答 : 0/40件)


1位指名
Creww
リモート可(週4日以上)
正社員
ウィザード
承諾
Alpha
リモート可(週4日以上)
正社員
プチリッチ
承諾
リンカーズ
リモート可(週4日以上)
正社員
プチリッチ
承諾
Algoage
リモート可(週3日以上)
正社員
ウィザード
承諾
エブリー
正社員
プチリッチ
承諾
BRANU
正社員
プチリッチ
承諾
プレイド
リモート可(週4日以上)
正社員
スター
承諾
ロジクラ
リモート可(週4日以上)
正社員
プチリッチ
承諾
マネーフォワード
リモート可(週3日以上)
正社員
プチリッチ
承諾
アルダグラム
正社員
プチリッチ
承諾
Baseconnect
リモート可(週3日以上)
正社員
プチリッチ +変動残業代 
承諾
ロコガイド
正社員
プチリッチ
承諾
スタディプラス
リモート可(週4日以上)
正社員
プチリッチ
承諾
MICIN
リモート可(週3日以上)
業務委託
プチリッチ級/月(税抜)
承諾
東京通信
正社員
プチリッチ
承諾
リブセンス
リモート可(週4日以上)
正社員
プチリッチ
承諾
MIXI
リモート可(週3日以上)
正社員
プチリッチ
承諾
クリエイティブサーベイ
リモート可(週4日以上)
正社員
プチリッチ
承諾
freee
正社員
プチリッチ
承諾
1位指名
WAmazing
リモート可(週4日以上)
正社員
プチリッチ
承諾
ユーザベース
正社員
プチリッチ
承諾
MUGENUP
リモート可(週3日以上)
正社員
ノーマル
辞退
FLUX
リモート可(週4日以上)
正社員
プチリッチ
辞退
ブレインパッド
正社員
プチリッチ
辞退
フクロウラボ
提示金額100%保証
正社員
プチリッチ
辞退
アイモバイル
正社員
プチリッチ
辞退
Seibii
リモート可(週4日以上)
正社員
プチリッチ
辞退
グロービス
リモート可(週4日以上)
業務委託
ウィザード級/月(税抜)
辞退
Grill
リモート可(週4日以上)
正社員
スター
辞退
スプリームシステム
リモート可(週4日以上)
正社員
プチリッチ
辞退
PIGNUS
正社員
プチリッチ
辞退
JMDC
リモート可(週4日以上)
正社員
プチリッチ
辞退
サイバーエージェント
(グループ会社所属)
正社員
プチリッチ
辞退
オープンエイト
リモート可(週4日以上)
正社員
プチリッチ
辞退
ZENKIGEN
リモート可(週4日以上)
正社員
プチリッチ
辞退
LIFULL
リモート可(週4日以上)
正社員
プチリッチ +変動残業代 
辞退
BASE
正社員
プチリッチ +変動残業代 
辞退
プロトソリューション
正社員
ノーマル
辞退
LIFULL senior
リモート可(週4日以上)
正社員
ノーマル +変動残業代 
辞退
ランサーズ
リモート可(週4日以上)
正社員
プチリッチ
辞退

3年後の目標や野望


技術力でユーザーの課題解決に貢献したいです。

ビジネスにおいて技術は手段なので、プロダクト・チーム規模に合わせてベストな技術を用いることで、ユーザーの課題解決・スケールアップに貢献したいです。 もちろん僕は技術が大好きで、日々研鑽を積んでいます。 しかし「ビジネスにおいて技術は手段であり、ユーザーの課題解決が目的である」ことを常に意識しています。 自己満足の技術に偏らず、ユーザーに貢献できるようになりたいです。

年収評価シート

2019年/2年以上

採用CMS開発プロジェクト

<!-- ================================ --> # 「トルー」プロジェクト概要 ## プロジェクト内容の要約 採用CMSアプリ「[トルー](https://toroo.jp/)」の開発・運用をしている。 一言で言うと、**企業の採用活動を効率化**するWebアプリケーション。 具体的には、以下の機能が強み。 - 求人情報と応募者情報を一元管理 - 自社専用の採用サイトを簡単に構築 - IndeedやGoogle For Jobs、Facebook Jobsなどの求人サイトとAPI連携 ## プロジェクトの規模 開発メンバーは現在4人(私とオフショア3人)。 多い時で7人(私を含めた日本人4人、オフショア3人)。 2020年度の売上は1.2億円。 ## 技術スタック - フロントエンド : Slim, jQuery, Vue.js - バックエンド : Rails, MySQL, Nginx - インフラ : AWS, Docker, CircleCI - 開発支援ツール : GitHub, Slack, Chatwork ## 担当した役割 プロジェクトマネージャー、およびフルスタックエンジニアとして**企画以外を全て担当**している。 プロダクトの方向性・コンセプトや新規機能追加などの大きな"企画"と言われる部分はプロダクトマネージャーが担当し、それ以降の要件定義・設計・コーディング・テスト・運用保守・データ分析を全て担当している。 # 出したバリュー ## パフォーマンス編 1. N+1問題を解消して、DBのCPU使用率を90%から60%に改善 - **課題 :** N+1問題が散見されていたが誰も修正せずに放置されていた。 様々な負債と相まって、DBのCPU使用率が90%に達してパフォーマンスが著しく低下していた。 - **工夫点 :** `bullet`というgemを提案・導入して、**N+1問題を解決・再発防止に成功**した。 <!-- また、データ肥大化に伴い上記解決方法ではメモリ効率が悪いケースもあったので、`pluck`も駆使してメモリ効率を考えながら解決した。 --> 2. 処理時間4時間 && メモリ使用率100%のバッチ処理を、処理時間20分 && メモリ使用率30%に改善 - **課題 :** 初期トルーでは求人データの登録手段は手作業のみだったが、CSVファイルを用いた一括登録機能を実装したことにより、**従来の50〜100倍のペース**で登録される様になった。 また、トルーはXMLファイルを用いてIndeed, Facebook, 求人BOXに求人掲載しているが、掲載する求人データを1回のSQLで全て取得していた。一括登録機能の実装後は求人データ急増により、**メモリ使用率が100%に達しXMLファイルを作成できなくなった**。 - **解決方法 :** スロークエリログから根本原因がインデックスの貼り忘れであることを特定し、インデックスを貼ることで処理時間を20分に改善した。 データ取得処理・ファイル書き込み処理を小分けに処理することでメモリ使用率を30%に改善した。 - **工夫点 :** `lol_dba`というgemを提案・導入して、**DB全体のインデックス貼り忘れを修正・再発防止に成功**した。 SQLを小分けにするだけでなく、**ファイル書き込み処理も小分け**にすることでメモリパンクを半永久的に再発防止した。 CloudWatchを用いて**CPU・メモリ使用率の監視・通知を実装することで早期発見・再発防止に貢献した**。 3. ループ処理中にメモリ使用率が100%に達してサーバーが動かなくなった不具合の修正 - **課題 :** 上記とは別の課題。 大量のデータを一度にメモリ展開していた(100万レコードに対して`each`を使っていた)。 - **解決方法 :** データを1,000件ずつ取得することでメモリパンクを修正した。 - **工夫点 :** メモリパンクした箇所に留まらず、**プロジェクト全体で同じ脆弱性のあるコードを全て修正した** (`each`を`find_each`や`in_batches`に置換)。 `pluck`を用いて、無駄なデータを取得しないようにデータ取得サイズを軽減させた。 4. BULK INSERTを実装して、処理時間を20分から7分に改善した。 - **課題 :** 従来のバッチ処理では大量のデータを1行ずつINSERTしていたので処理速度が遅かった。 - **解決方法 :** `activerecord-import`を用いてBULK INSERTを実装することで、処理速度を半分以下に改善した。 - **工夫点 :** BULK INSERTの際はActiveRecordを経由せず直接SQLを実行するので、バリデーションやコールバックが発火されない。データの不整合が起こらないように気をつけた。 プルリクエストのテンプレートにチェックリスト作成を提案・導入することで、今後実装されるバッチ処理の再発防止に貢献した。 <!-- 4. 求人データが約1万件を超えるとトルーで作成した採用サイトが一切見れなくなる不具合の修正 - **原因 :** MySQLの`order`で使用できるメモリの上限を超えて並び替えができなくなていた。 - **解決方法 :** `order`するときに使えるメモリの最大容量を増やすことで解決しました。 - **工夫点 :** AWS RDSに設定しているパラメータグループがデフォルトパラメータグループだったので、カスタムパラメータグループに変更する必要がある。しかし、パラメータグループを変更するにはDBを再起動する必要があるので、トルーをメンテナンスモードにすることで、ユーザー対策を行なった。 --> <!-- 6. リードレプリカの導入 **- 課題** 求人数の急増に伴い、データベースのCPU使用率が80%を超えた。 # リードレプリカ # 求人インポートの処理を大量・少量で分けた 公開・非公開・削除を作った --> ## セキュリティ編 1. SQLインジェクションやXSS、CSRFなどの修正 - **課題 :** SQLインジェクションの脆弱性があるコードが散見されていたが、誰も修正せずに放置されていた。 - **工夫点 :** `brakeman`というGemを提案・導入して、**脆弱性のあるコードを全て修正・再発防止に成功** した。 2. `Googleデータポータル`を用いてDBの情報をエンジニア以外に共有 - **課題 :** トルー全体の現状把握のために、エンジニア以外の社員もDBを閲覧していた。DBに接続する人が多くなるほどセキュリティリスクは高まるが、代替案の状態が続いていた。 - **工夫点 :** Googleデータポータルを提案・導入することで、DBに直接接続することなく必要な情報のみ閲覧できる様にした。 3. AWS Trustred Advisorを用いてセキュリティ強化 - **課題 :** トルーはAWSを使っているが、網羅的セキュリティチェックする方法を誰も知らず、「本当に安全なのか?」を評価できない状態が続いていた。 - **工夫点 :** Trusted Advisorの提案・導入することで、セキュリティ堅牢度の向上に貢献した。 具体的には、AWS WAFの導入、S3のバージョニング、ELBのログ保存、Cloud WatchでCPU/Memoryの監視を設定した。 <!-- 会社の人は誰一人、Trusted Advisorの存在を知らなかったが私はAWSについて勉強をおこたrなかったので偶然このサービスを知り、Trusted Advisorが指摘・推奨する内容をの実装した。 --> <!-- 4. AWS WAFの導入 --> ## コスト削減編 1. ELB と ACMの使い方を見直して、**年間50万円のコスト削減** に成功。 詳細は以下URLを参照。 https://qiita.com/Gatsby/items/933c5a93e5900865b7d2 2. 未使用ドメインを解約して、**年間20万前後のコスト削減** に成功。 - **課題 :** トルーでは企業毎に独自ドメインを発行しているが、解約済み企業のドメインを解約せずに毎年自動継続更新をしていた。誰もドメインの管理をしていない状態だった。 - **工夫点 :** 解約してもすぐ再契約する企業もチラホラ存在した為、トルー解約から1年経つ企業のドメインを解約するように実装した。 ## リファクタリング編 1. モデルにschema情報を記載 - **課題 :** Railsではモデルとテーブルが密結合にも関わらず、テーブルのSchema情報がモデルファイルに記載されていない。「モデルにどんなカラムあったっけ?」となった際はDBかSchemaファイルを確認するしかなく少し面倒な状態だった。 - **解決・工夫点 :** 手作業では口数もかかり、ヒューマンエラーが発生しかねないので、`annotate`というGemを提案・導入することで、漏れなく全てのモデルファイルにSchema情報を記述した。 2. 1000行あった`Fat Model`を400行に縮小 - **課題 :** トルーのコアドメインに当たる`Company`や`Recruitment`などの`Model`, `Controller`, `View`が`Fat`になっていたが、規模が大きすぎて誰も手を出さずにいた。更にコールバック関数やアソシエーション、メソッド、スコープの記述位置がバラバラでどこに何があるか把握しにくい状況になっていた。 - **解決方法 :** - `ActiveSupport::Concern`を用いて`Module`に切り出し - Viewでしか利用しないロジックを`ViewModel`に切り出し - `Controller`でしか利用しないロジックを`Form Object`に切り出し - `Model`に限らず`View`, `Controller`, `Model`, `Mailer`, `Presenter`など広範囲に使うメソッドは`Utility`として`Class`に切り出し - どのアーキテクチャにも属さない特定の処理は`サービスクラス`に切り出し - 変数・定数・`enum`を用いてハードコーディングの撲滅 - コールバック関数の利用 - **工夫点 :** - リファクタリング前に、テストを実装 - また、`before_action`などのコールバック関数は使いすぎると処理がブラックボックス化するので、意図的に使わない様に実装 - コールバック関数やアソシエーション、メソッドの記述位置を統一 ## タスクマネジメント編 1. オフショア開発と密にコミュニケーションを取ることで、タスクの遅延率を80%から20%に削減。 - **課題 :** **私が担当する以前は、オフショアメンバーとのMTGは週1回の15分だけだった。** 更に、依頼するタスクの仕様が雑 && オフショア側も質問してこないという地獄のような状況だったので、**ほぼ全てのタスクで手戻り・闇の工数が多発**していた。「タスク完了日」が「納期」としての役割を果たしていなかった。 - **解決方法 :** 毎日15分MTGと毎週1時間MTGを行い、認識に齟齬がないか・仕様の理解度・進捗のチェックを行い徐々に改善していった。現在では20%に削減することができた。 - **工夫点 :** 以下の取り組みをすることで、オフショアメンバーに自発性・主体性を芽生えさせた。 - 依頼したタスクがそもそもなぜ必要なのか、背景と理由を説明 - 依頼するタスクのゴールを明記(何を実装するのか・しないのか) - 1度犯したミスを逐一チェックリストに追加し、再発防止をした - 相手に敬意を払い、発言・質問・提案を褒め、感謝をする。 2. 要件定義書を作成し、手戻りを防止 - **課題 :** 営業・カスタマーサポートが、クライアントの要望をそのまま企画に出すことが多く、企画に上がる要望と達成したいゴールが異なる問題が発生していた。 また、MTGや口頭でのやり取りをチャットやドキュメントに残さないので、認識の齟齬が発生していた。 - **工夫点 :** 以下の取り組みをすることで上記問題の再発防止を心がけている。 - 「そもそもその機能は本当に必要なのか?」と前提を疑う ここをしっかり議論することで無駄な機能を作ったり、仕様変更をしたりといった手戻りを発生させない様にしている。 - その機能が必要となった背景・目的を明確に理解 「目的を達成する為にはこの企画がベストなのか?」を常に意識・議論することで無駄な手戻りを防いでいる。 - 建設的議論ができる雰囲気・信頼の構築 相手を頭ごなしに否定・きつい口調で話すなどの愚行をしない様にしている。幸い、社内では年下ということもあり、雰囲気・信頼の構築は容易にできている。また、曖昧な表現は避けるなど、意思疎通には細心の注意を払っている。 - ログ記録 「言った・言ってない」の水掛け論を防ぐために、チャットやドキュメントなどにログを残し、必ず確認を取り、認識の齟齬を最小限にしている。 <!-- 他にも頑張って実装したこと - 契約・請求周りの実装、運用保守 - 画像一括アップロードの実装 - ATS - Facebook API連携 - facebook, google, indeed, job boxをXML化 - mimemagick - ライン応募、Pythonサーバー、MessagingAPIで急にNgrokが使えなくなった。 - 営業日 - OEM - 価格改定、コアドメインの仕様変更 - MySQLをバージョンアップ - RSpecでGETメソッド - -->

2021年/1年以内

会員制動画配信サービスの新規開発・運用

# 「Icey」プロジェクト概要 ## プロジェクト内容の要約 会員制動画配信サービス「[Icey](https://icey.jp/)」の新規開発・運用をしている。 一言で言うと、**自身の動画コンテンツを限定公開・売買する**Webアプリケーション。 イメージとしては以下の様な感じである。 - Udemyの様に、自身の動画コンテンツを販売できる。 - CMSの様に、自分専用のサイトを簡単に構築できる。 ## プロジェクトの規模 開発メンバーは4人(全員日本人)。 ## 技術スタック - フロントエンド : Slim, jQuery - バックエンド : Rails, MySQL, Nginx - インフラ : AWS, Docker, CircleCI - 開発支援ツール : GitHub, Slack ## 担当した役割 インフラ・バックエンドのテックリードとして参画した。 具体的には以下を担当 - インフラの設計、実装、運用 - `Rails`のパフォーマンス・セキュリティ系の処理見直し・修正 - `CircleCI`を用いた自動デプロイの実装 - `RSpec`テストの実装 # 出したバリュー ## AWSを用いたインフラ設計・実装・運用 私以外がインフラ未経験だったので、**全てのインフラ設計・実装・運用を担当**した。 具体的には、以下のサービスを利用 - VPC, Route53, ACM, EC2 - ELB, Athena, AWS WAF, Kinesis - CloudWatch, SNS, Chatbot - S3, CloudFront - RDS, Redis - ECS/ECR, CloudFormation, AutoScaling - Lambda, MediaConvert **工夫点 :** - ### `CloudWatch`を用いてパフォーマンス悪化のリアルタイム通知を実装 新規開発サービスなのでリリース時のアクセス数に予測がつかない。 そこで、`CloudWatch`を用いて`CPU/Memory使用率` や `ELBのレスポンスタイム`, `ステータスコード`などが一定の閾値を超えると`Slack`に通知するように設定することで、**チーム全員が即座にパフォーマンス悪化を確認できる様にした**。 - ### `AWS WAF`を用いて、SQLインジェクションやDDoS攻撃への対策を実装 新規開発サービス && toC事業なのでリリース時に何が起きるか分からないので、 `SQLインジェクション`や`DDoS攻撃`などの悪意ある攻撃からプロダクトを守る為に、`AWS WAF`を提案・導入した。 実際、**海外からの`Bot`を防御することに成功**した。 また、定期的に`ELB`のリクエストログを解析して、悪意あるリクエストが`WAF`を潜り抜けて到達していないかチェックも続けている。 - ### `Route53`のCLIを用いて、リアルタイムにサブドメインを発行する処理を実装 サービスの仕様として、動画コンテンツを配信するユーザーは各々`test.icey.jp`のようにサブドメインを発行して自分専用のサイトを作る。初期仕様ではユーザーがサブドメインをリクエストし、管理者側で都度サブドメインを登録するフローになっていた。 しかしそれではスケールしない && ヒューマンエラーの温床になるのでので、**ドメイン発行処理をCLIで実装して無駄な手作業の削減に成功**した。 ## パフォーマンス・セキュリティ系の処理見直し・修正 **私以外のメンバーが`Rails`歴1年未満だったので、パフォーマンス・セキュリティ的に良くないコードが散見されていた**。これらを全体的に見直し・修正を行った。 **工夫点 :** - ### SQLインジェクション・XSSなどの脆弱性を修正・再発防止 `brakeman`というGemを提案・導入して、**網羅的に上記の脆弱性を修正・再発防止を達成**できた。 - ### N+1問題の修正・再発防止 `bullet`というGemを提案・導入して、**網羅的に`N+1問題`を修正・再発防止を達成**できた。 - ### インデックスの貼り忘れを修正・再発防止 `lol_dba`というgemを提案・導入して、**DB全体のインデックス貼り忘れを修正・再発防止に成功**した。 - ### ループ処理のメモリ展開を修正・再発防止 ループ処理するデータ全てを一度にメモリ展開する様に実装されていたので、小分けにメモリ展開する様に修正した。また、**チェックリストを作成し、プルリク作成時点でメモリ展開の方法が間違っていないかチェックする習慣を付けて再発防止に成功**した。 ## `CircleCI`を導入し、開発スピード向上に貢献 私は副業として本プロジェクトに参画しているが、**私以外メンバーはインフラ・デプロイ周りの知見が無いので、デプロイの時間帯は私の作業時間に依存していた**。 このままでは開発スピードが属人化するので、**`CircleCI`を提案・導入し、開発スピードの向上に貢献**した。 ## テストを実装し、品質保証・開発スピード向上に貢献 **テストが一切実装されておらず、プロダクトの品質を保証する根拠が全くない状態だった**。なので現在は`RSpec`を用いて、徐々にテストを実装している。 **工夫点 :** - ### コアドメインの単体テストに限定して実装 新規開発プロジェクトでは、品質よりスピードに重きが置かれる。本プロジェクトも同じで、品質を少し犠牲にしてでも早いサイクルで機能追加・改善を繰り返したいというのがプロダクトオーナーの要望だった。とはいえ、全くテストを実装せずに開発を続けるのは危険なので、プロダクトのコアドメイン(動画やユーザーのCRUDなど)に限定して、テストを実装した。これにより、**最低限の品質を担保しつつ開発スピードを維持できるように貢献**した。 これらの工夫により、現在は安定稼働・バグの早期発見に成功している。

マネージメント能力

タスク
タスクを納期までに実装する責務がある。
タスクを納期までに実装するために、要件定義・設計・コーディング・テスト・運用保守を行う。 1. **要件定義書の作成** 抽象的な企画・要望を具体的な機能要件へと落とし込み、レビュー承認を貰う。 **問題点 :** - クライアントの要望をそのまま企画に出す営業の方が多い。 - 企画に上がる要望と達成したいゴールが異なることがある。 - 「言った・言ってない」の水掛け論が発生した。 **工夫点 :** - 「そもそもその機能は必要なのか?」ここをしっかり議論することで無駄な機能を作ったり、仕様変更をしたりといった手戻りを発生させない様にしている。 - その機能が必要となった背景・目的を明確に理解し「目的を達成する為にはこの企画がベストなのか?」を常に意識・議論することで無駄な手戻りを防いでいる。 - チャットやドキュメントでログを残し、必ず確認を取り、認識の齟齬を最小限にしている。 2. **設計書の作成** 要件定義書を基に、実装内容を決める。 - どこまで・どのようにフロントで実装するのか - どこまで・どのようにバックエンドで実装するのか - DB設計 - インフラ設計 - テスト設計 などを決めて、CTOレビュー承認を貰う。 3. **タスクの細分化・工数見積もり・スケジューリング** 設計書を基にタスクの細分化。 自分が実装する部分・オフショアに依頼する部分を分け、スケジュールを出して、CTOレビュー承認を貰う。 **問題点 :** - 現状では、オフショアメンバーはトルーの仕組みを網羅的には理解できていない。この状態で基本設計を依頼しても手戻りが発生する **工夫点 :** - DB設計やインフラ設計、モデルやコントローラーの基本設計など土台の部分は私が担当 現状のオフショアメンバーに基本設計を依頼しても手戻りが発生するだけなので私が担当してる。とはいえ、私の稼働時間も有限なので、少しずつトルー全体の仕組みを説明して、ゆくゆくは基本設計も任せられるように教育もしている。 4. **コーディング・タスクマネジメント** 私自身・オフショアメンバー両方のタスクを管理している。 **問題点 :** - オフショア(外国人の方々)なので、日本人の感覚とは異なる。自分の大前提が他人の常識ではないことが多々ある。例えば「お問合せフォームを作ってください。」と依頼した場合、バリデーションが実装されず(質問もされず)に納品されることがあった。 **工夫点 :** - 毎日15分のMTG・毎週1時間のMTG 認識に齟齬がないか・仕様の理解度・進捗のチェックをしている。 私の説明不足で認識の齟齬が発生していたので、認識の統一を心がけている。 - 失敗をドキュメント化 お互いの失敗からチェックリストを作成し、プルリクえすと作成前に再発防止を心がけている。 5. **品質チェック** 自動テスト・マニュアルテストを実行して、プロダクトの品質をチェックする。 **問題点 :** - テストを書く文化が無く、また全ての処理に対してテストを実装するリソースが無い。 - 経営層は、品質よりスピードを重視したいと考えている。とはいえ、システムの規模も大きくなりマニュアルテストではカバーしきれない。 **工夫点 :** - GETメソッドのテストとコアドメインのテストのみ実装 テストカバー率100%にするリソースはないが、最低限の品質は保証する必要がある。よって、最低限、画面が表示できることを確認するGETメソッドのテストと、コアドメインに当たる処理は全て実装し、複雑な処理やコアドメインでない部分の処理はマニュアルテストで品質チェックするという折衷案を提案・実装をした。 これにより、最低限の品質を保証しつつ開発スピードを保つことができた。 6. **コーディングレビュー** OKなら7番、NGなら修正箇所をタスクに細分化し、3番からやり直し。 **問題点 :** - コミットメッセージが「wip」「fix」ばかりで、他人に説明する文化がない。 - プルリク本文に説明がない。 **工夫点 :** - プルリクレビューしやすいように、1行目に何をしたの概要、2行目以降に詳細と理由を必ず記述するようにルール付けして、プルリクレビューをしやすくした。 - プルリク本文のテンプレートを作り、最低限の説明を記述するように強制した。 7. **全体レビュー** 依頼内容と実装内容に乖離がないか・UI/UX的に不便はないかを、企画者・社内利用者の方々にチェックをしてもらう。 OKなら8番、NGなら修正箇所をタスクに細分化して3番からやり直し。 **工夫点 :** - この時点で仕様を理解できているのは企画者と開発メンバーのみ。社内利用者が仕様を理解しチェックできるように、操作手順書の様なものを作り、チェックしやすい様にしている。 8. **リリース日を決めてリリース** 大きな機能追加でない限り、7番でレビュー承認された2営業日後にリリースする。

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

アピール項目


アウトプット

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

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

静的型付け言語 パフォーマンスチューニング セキュリティ 人の教育・マネジメント プロダクトのマネジメント iOS・Androidアプリ 競技プログラミング・アルゴリズム

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

# 組織・文化面 - 組織の同質性が強すぎず、かつ開発現場の風通しが良く(政治的な動きが少なく)、外部からの参画者でもリーダーシップが取りやすい環境 - エンジニアを尊重する文化 - ペアプロ・モブプロ - コードレビュー - 技術向上支援制度(書籍購入補助・勉強会参加補助など) - 休憩時間が自由 - イヤホンOK # 物理的環境面 - 昇降デスク - 体にフィットした椅子 - 静かな場所 - MacBook(メモリ32GB以上) - USキーボード - サブモニター1個以上

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 人を集める力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
SI
その他の特徴
レガシーな環境を改善できる / 新しい技術はとりあえず試す / 勉強会でLTをよくする / 趣味は仕事 / 起業/創業期のベンチャーにいた / OSSのコミッターである
その他のやりたいこと・やりたくないこと

## 希望する技術スタック
フロントエンド:Typescript, React
バックエンド:Ruby, Golang, Rust, Kotlin
インフラ:AWS, GCP, Terraform

## 事業内容に求めること
社会的意義の大きいサービスの開発に携わりたいです。

## 組織/開発スタイル
社員がお互いに尊敬しあっているチームで働きたいです。

やりたい事

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

基本プロフィール

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

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

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

  • {{error}}
JayGatsby
今年で20代後半
vscode
参加ステータス
不参加
参加回数
2回
累計平均提示年収
617 万円
SIGN UPSIGN IN


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