ID:25724さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


組織に所属する全員のフォーカスを1つに定めてサービスを開発したい

様々な職種で構成される会社という組織の力をフルに使って、巨大な成果を作り出してみたいから。具体的にはOKRで描いた夢に一丸となって向かって、猛烈な達成感を得たい。

年収評価シート

2018年/1年以内

DMP作成プロジェクト

# プロジェクト概要 自社プロダクトの持つ各種データを集め、データドリブンな意思決定ができる会社にするための基盤となる、Data Management Platform(DMP)を作成するプロジェクト。 直近の目標は以下のデータを収集し、アナリストが分析可能な状態にすること。 - 各種データベースのデータ - Adobe Analyticsの行動ログ プロジェクト要員は11名で、メンバーの役割は分析と開発で半々ほど。 # 担当内容 サーバサイドエンジニアの1メンバーとしてプロジェクトに入り、以下を担当してきた。 ## プロジェクトの目標設定 私がプロジェクトに参画したタイミングでは、DMPをなんのために作成するのかが定まっていない状態であり、リーダ含め、各人の頭の中にのみやりたいことがある状況で、私がやるべきことすらない状態だった。 そこで、スクラム開発で利用するインセプションデッキの説明をチームに行い、チームでインセプションデッキを作成していくアクションを取ることで、定まっていなかった目標の明文化と、チームでの認識合わせを同時に行った。 その後、プロダクトバックログのテンプレートを作成し、チームに説明、運用サポートを行って、直近のやるべき作業を見える化した。 ## チーム教育 リーダがメンバーをサポートできておらず、各人が思い思いの作業をしており、チームの体をなしていない状態だったため、ここでもスクラムの手法を借りつつ、以下のように改善していった。 ### デイリースクラム実施 各メンバーの状況共有のため、デイリースクラムを実施した。 これによりタスクの抱え込みや、作業で詰まっているところが発見しやすくなった。 また、デイリースクラムのファシリテータをメンバーでローテーションすることで、チームへの参加意識を持って貰えるように工夫した。 そして、良くも悪くもチームが何の目標に向かって作業しているのかが不明確であることに気付くメンバーが出てくるようになった。 ### チームの分割 DMPプロジェクトのメンバーは、以下のような様々なバックグラウンドを持つ集まりで構成されたチームだったため、プロダクトバックログを利用したスクラムのやり方だと、作業の進め方・優先度を統一するのが難しかった。 - エンジニア(サーバサイド、インフラ) - アナリスト - データサイエンティスト - ディレクター また、同じ作業チームとして動くと意思決定が遅く、プロジェクトが前進しなかったため、分析と開発でチームを分け、それぞれで適した業務実施方法を行うようにした。 各チームはリーダ間で連携し、互いの進捗はスプリントレビューという形で週末にメンバーで共有し合うことで、互いの作業内容に認識齟齬が出ないようにした。 ### メンバー教育 報告を聞いているとコードレビューが行われていなかったので、 GitHubのプルリクエストの仕組みを説明しつつ、開発からデプロイまでの開発フローを作成・説明し、コードをチームのものにできるように取り組んだ。 また、データレイク開発中に採用したエンジニアが、開発業務にスムーズに入れるように、毎週1on1を実施し、業務中ではフォローがおざなりになりがちな、気になることや業務上の不安点、キャリアプランへのサポートを行った。 ## データレイクの作成 開発チームのリーダが兼務の業務で忙しく、プロジェクトの作業がほぼできない状態となっており、プロジェクトが進まなかったため、開発済みのシステムを保守するチームと、データレイクを基礎としたデータプラットフォームを作っていくチームに更に分け、私とディレクターでデータレイクから作っていくことにした。 ### 複数インフラ環境をまたぐシステム設計 当初GCPを想定してDMPのシステムが作られていたが、データを集める場合はAWSのS3が都合が良かったため、収集元データのあるオンプレミスとAWS、分析基盤を予定しているGCPを考慮して、データレイク、DWH、データマートのシステム構成を作成した。 極力開発工数と管理費を抑えたデータレイクの管理システムをAWSに用意するため、以下の工夫を行った。 - AWS Glue、AWS Athenaを使った、データのカタログとチェック機能の提供 - データ配備をLambda関数で定期チェックする機能の提供 ### Oracleのデータ収集 数百GBのデータをOracleからデイリーで収集するため、Embulkを利用したシステムをPythonで構築した。 作成後、試しにEC2のt2.mediumで70Gほどのデータ処理を実施したところ、1日では処理が終わらない試算が出た。 そこで、AWS Batchが利用できるよう、システムをコンテナ化し、更にジョブを並列で実施できるようシステムを書き換え、上記処理が2,3分で終わる状態を作った。

2017年/半年以内

ECモールのリプレイスと内製化プロジェクト

# プロジェクト概要 旧年来運用されてきた外注開発によるECモールのリプレイスと内製化を行うプロジェクトで、実働メンバー6名によるスクラム開発を行った。 # 担当内容 サーバサイドの開発メンバーとして参加し、以下を担当した。 - リプレイスまでのシステム変遷図の作成 - 既存環境を動作させるローカル環境をVagrantとAnsibleで構築 - スクラム開発のレクチャーと導入(実質的スクラムマスターとして、各スクラムイベントの初期ファシリテートと運用サポート) - リプレイス範囲の選定と利用するアーキテクチャの選定 - 参画したJavaエンジニアに対し、キャリアとして価値を持ちつつ、高速に開発できるようSpring Boot2とKotlinを利用したアプリケーションのシステム設計と導入、サンプルアプリケーション作成を行った - システム構成図の作成とローカル・開発・ステージング・本番環境の構築 - JOOQの導入検証と運用手順作成 - Jenkinsの導入とDangerを利用したGitHubとのプルリク開発連携を設定 - 現時点ではマイクロサービスアーキテクチャ(MSA)を採用する状況ではなかったが、将来的にMSA化できるように、Kotlinのパッケージ構成を機能単位にし、機能間呼び出しはinternalパッケージを経由して、行うように設計した - TSLintのDanger対応プラグインの作成 - Gatlingによる負荷テストの計画と実施サポート

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

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

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

マネージメント能力

チームが開発するプロダクト
プロダクトが常に体験可能で、プロダクトの提供する価値について細かくレビュー可能になっており、 プロダクトに対して必要なものが作られている状態。
まずは「他者がレビュー可能なものを、細かい粒度で作る」という意識を、メンバーに持ってもらう必要があると考えた。 そこでタスクを上げる際は、これは誰が求めていて、タスクが完了するとどういうことができるようになるのか、何ができていたらこのタスクは完了なのかを合わせて書くように指示し、記載の仕方をフォローしながら、全員でタスク出しを行った。 タスクを上げていると、1週間のような単位では開発が終わらないものが出てきたが、同時に上げていた完了の条件で分解して確認できるものがあれば、その粒度でタスクを分割し、短い期間で開発が行えるように工夫した。 こうしたことで、たとえ考慮していなかった問題が発生しても、それが判明するタイミングも早く、作業の大幅な手戻りや、問題の抱え込みによる作業進捗の深刻化は起きなかった。 そして、細かい粒度で作る意識を持ち、それを実行していったことで、開発メンバーはプロダクトが着実にできていく体験を得ることができ、チームとして高いモチベーションで作業することができた。 一方で、プロダクトが実現する価値に直接は関係しない、CI/CD環境の整備や開発ルールの制定も、同じタスクとして行い、プロダクトがレビュー可能であるために持つべき品質が保持されるようにアクションを起こした。

アピール項目


アウトプット

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

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

マイクロサービスとコンテナでアプリケーションを運用していくために、以下に注目しています。 - Kubernetes - Istio - Swagger - gRPC マルチプラットフォームのゲーム開発をしたいので、以下についても注目しています。 - Unity - C# Kotlinでの開発がやりやすく、楽しかったので、Kotlin周りのエコシステムも引き続き勉強が必要だと思っています。

エンジニアとして影響を受けた本を教えてください

- アート・オブ・プロジェクトマネジメント - Java魂 - エンジニアのための時間管理術 - サーバ/インフラを支える技術 - Webを支える技術 - モチベーション3.0 - あなたの話はなぜ「通じない」のか - ピクサー流 創造するちから - OKR シリコンバレー式で大胆な目標を達成する方法

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

# 単独でコーディングをする場合 プログラミングで達成したい目的に対する回答を持つメンバーが、気軽に話せるポジションにいて、目的を達成するまでの指定の期間があり、インフラ関連のシステム構築が自分の手で行なえ、一日を自分でスケジューリングでき、割り込みが入らず、HHKBが使える環境。

キャラクター

直近で一番やりたいこと
組織を作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 巻き込み力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
好きなプロダクトがある
やりたくない分野
SI / 金融 / 医療・介護 / 人材
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で30代後半
好きな Text Editor
ドキュメントはAtom、コーディングはVSCode
希望勤務地
東京都 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
未入力
ただいまの期間
ドラフト開催中

  • 参加者は企業から指名が入ります
  • ドラフト指名に返答できます
  • レジュメを更新できます
  • 審査は停止しています
ご意見箱

要望、不具合報告、使いづらい点や感想など、なんでもお気軽にご連絡ください。

ID:25724さん
今年で30代後半
ドキュメントはAtom、コーディングはVSCode
参加ステータス
不参加
転職意欲
参加回数
2回
累計平均提示年収
699 万円
SIGN UP
SIGN IN


このサービスを友人に薦めたいですか?