Aquila

自己推薦一覧

自己推薦はありません

3年後の目標や野望


課題解決への意欲・組織改善への熱意・技術的に対応できる幅の広さ・ビジネス知識量・対人支援能力といった強みを更に活かし、最高にエキサイティングな仕事をし続ける

理由: 「価値を創る、価値のある仕事を創る」「人のポテンシャルが輝く瞬間を見る」「問題をみんなの力で解決する」そういう光景が好きです。 そして、それをより良い形で実現するために自己成長し続けることが、所属する組織にとっても私にとっても良いことだと認識しています。 具体的な将来像として想定しているもの: まず、対チーム・対人での支援を行うといった趣の強いEngineering ManagerやTeam Leaderとしての仕事をしていくことです。適性や志向性に照らして良いキャリア方針なのかなと考えています。 また、収益性とユーザー課題や社会課題の解決とを両立的に考え、真に価値のあるプロダクトを世に届けるためのアイデア・思考・方法知を、周囲の人に共有していくようなポジショニングをしてゆくのも方向性としてはあり得るかなと思っております。知識幅や新規事業開発経験から考えて、そうした動きにも幾らかの自信・自負があるためです。

年収評価シート

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

2022年/半年以内

HRTech - 新規事業 - 定収入状態の若者が苦境から脱出し、キャリアを考え始めるための求人媒体

# HRTech - 新規事業 - 定収入状態の若者が苦境から脱出し、キャリアを考え始めるための求人媒体 現職で、いま現在開発・運用しているプロダクトです。ひとつ前の項目として記載してあるプロダクトからPivotしての新しく取り組み始めました。課題意識・ビジネスプランへの共感を強く持ちながら日々業務に邁進しています。企画・仮説検証段階から実装、施策効果検証・データ分析まで携わっています。 バックエンド、インフラ、フロントエンドをいずれも触るエンジニアとして動いているほか、企画系のMTGに参加したり、たまにワークショップのファシリテーションなどもしたりしています。 以下、各領域での取り組みについて詳述します。 エピソードベースで書き切るのは難しい(ちゃんと書こうとすると守秘しておいた方が良い情報に行き当たる、単純に量が多い、等の理由によります)と判断しており、業務範疇およびそのなかで意識的に取り組んだことや思考・背景の説明といった少々抽象的な記述に留めました。詳しくはカジュアル面談でお話しします。 ## バックエンド 言語:PHP FW:Laravel API仕様:OpenAPI Specification VCS:git, GitHub ローカル開発環境の仮想化:Dokcer - Docker Compose ### 業務範疇 バックエンドはある程度リードすることを期待されつつやっています Webサービスのバックエンドエンジニアとしてやるようなことには大概取り組んでいるはずです (そのため詳細は略し、次の項目でアピールポイントを列挙しておこうと思います) ### アピールポイント - 依存関係が複雑な非同期処理のリトライ設計などを丁寧に行うファインプレー - DBスキーマに関わる設計について、Application, ETL, データ分析基盤それぞれの責務範囲を考慮し、開発ベロシティと保守性や分析での使い勝手を両立させる動きをしたりしました - ゴリゴリ過ぎないソフトウェアアーキテクチャを吟味し、その設計反映・保守に務めました - 凝集度を高めつつ、しかし「無駄にI/Oの多いLayerd Architecture」のような設計はあえて避けるといった塩梅での判断をしています(詳細は後述) - ドキュメンティングを積極的に行うことで、「経緯や意図のわからない判断とその残骸」を最小化していました ### アーキテクチャ概要 取り入れた思想・設計 - Eloquent(LaravelのORMです)には依存する - が、「そうした方がいい場合」に限りDTO的なクラスに詰め替える - ビジネスロジックはUseCase単位でクラスを作り、そこに概ね放り込む - アスペクト指向的・水平的に用いられる関数群はServiceに置く - 特に3rd Partyライブラリに依存する場合や外部のWeb APIにアクセスするコードである場合、ServiceInterface越しに利用、置換容易にしておく - レスポンスボディのJsonスキーマと対応するようなPresenter層はむしろ必要性が強いと判断し、導入 - OASの分割単位と完全に揃えることで、凝集性とメンテナビリティを担保した - 要はOASのスキーマ定義と完全に対応していれば、複数のエンドポイントでクラスを再利用しても原則的に困らない(OASの段階で、同時に変更するエンドポイントの組が既に考慮されている) やらなかったことに関する注記 - Laravel界隈にありがちなRepositoryパターンなどはあえて避けている - クエリの凝集はEloquentで概ね足りると判断し、その域を漏れる場合にはどうしたらいいかを都度チームで合議するといった設計体制とした - また、DDD由来のデザインパターンの類いも、Web APIのためのアーキテクチャとしてはtoo mutchと判断して避けている - 特にサービス初期には重いため、事業速度に影響しかねないと認識 - (そういう思想で設計するタイプなので、「うちはDDDです!」という開発組織にはopinion levelでマッチしない可能性があります) ### コードの治安面に寄与した行動 - PHPの緩さの美点は活かしつつも、基本的にはエディタ・IDEで補完・推論が利くような型宣言・注釈をしていく方針をチームwikiの記事として明文化しました - また、ペアプロなどを通して「何が嬉しいか」駆動説明を行い、チームに浸透させる+aの努力を常に心がけています - WhyやIntention、Noteなどのメタ記述を含むようなコメンティングを推奨し、そのコメントの役割を明確化することで、質の高いコメントがなされる開発文化づくりを推進しました - また、コメントが変更・破棄される条件までを記載することによって嘘ドキュメントの発生を抑制した - ログ出力の条件やレベリングの方針をチームwikiの記事として展開し、不具合等での調査時に事象のトレーサビリティが高くなるようなログ文化を作りに行いました - N+1検知のためのライブラリ導入、またコードスメルの人力検知などで不要なクエリを減らしました ## インフラ IaaS:Amazon Web Service, 一部GCP IaC:terraform ### 業務範疇 新規プロダクトのインフラ構築を主導しました 当時在籍していたもう一名のエンジニアと二人三脚で構築するために、ロードマップの整理や課題分解を常に行いながら、実作業にも入っていました ちなみに元々はクラウドインフラに関してさほど知識がありませんでした。この構築へのアサインをきっかけとして、本格的に学習を開始した、という経緯があります **※構築の具体作業についてはもうひとりの功績もかなり大きい**ので、以下そのあたり差し引いてお読み頂ければ幸いです #### 初期に取り組んだこと - ロードマップ作成 - いわゆる3層アーキテクチャをAWS上で構築(以下、触ったリソース例) - VPC - VPC Peering - Route 53 - Cloud Front - ACM Certificate - S3 - ALB - ECS(Fargate) - RDS - SQS - EventBridge(スケジューラとして動かし、ECSタスクを定期起動させる) - WAF - Cloud Watch - IP範囲・ネットワークアクセス制御系(NACL, SG)の設計 - WAFのルールセット設計・構築 - IaaS従量課金系のインシデントに対するポストモーテムと対応報告資料作成 - アプリケーション開発者が利用する際(ECS Exec)などの手順書作成 - ETL(trocco利用ではありますが)整備 - DWHサービス(BigQuery)の初期セッティング 現在も追加構築・運用・保守に携わっています。 - 開発都合で新規に必要となるリソースの追加構築 - ツール類のバージョンアップ対応 - terraformコードの一部リファクタリング - そのほか運用的な細かいタスク #### インフラ構築に際して重視したこと - IaC編 - コードがなるべく宣言的である状態を維持すること(手続き的コードを排除すること) - つまり「環境に何が存在し、どのような設定がなされているか」の事実伝達をコードの第一責務として捉える方針だということになるかと思います - 具体的には、外部入力(実行時引数、workspace差)による制御分岐が生じないようにあえて環境毎にコードを管理しています(議論の余地はある設計判断だと思いますが……) - prod, stgの同質性は、コードレベルでの(ともすれば安易な)共通化ではなく、管理体制・知識マネジメントによって維持することを選択したと言えます - リソースの明白性を損なわない範囲での凝集や抽象化(module機能利用等)を行うこと - 「IaCなんだから見れば分かる」が半分嘘であることを思い出しながら、文脈・意図をコメンティングする - 構築内容編 - サービスが跳ねた場合の水平展開に即応しやすいような構成を取ること - もはや一般化しているとも思いますが、以下を意識しています - ALBによるバランシング - ECS(Fargate)によるサーバーのスケールアウトの容易性 - RDSをclusterとして設置し、reader instanceの冗長構成が可能な管理とする - 自分にできる範囲でセキュアに構築すること - NACL, SGによるパケットフィルタリングで使途外のパケットをそもそも通さない - WAFを当てることによって悪意のあるペイロードを含むリクエストをある程度弾く - stg環境などではIPホワイトリストを管理し、オフィスやVPNからしか接続できないように制御する - ドキュメント文化編 - 他の作業者や開発者用にドキュメントを執筆した際には、「当該ドキュメントを用いて実際にオペレーションを行ってもらう」ステップをタスクゲートとして用意することで、使えるドキュメントにまで仕上げる - ちょっとしたこと編 - ssh key pairなど公開鍵暗号が必要になる場面ではed25519などの強度の高いアルゴリズムをできるだけ利用しています - まあそもそも被解読よりは「秘密鍵の漏出による正面突破」のほうが遥かにリスクとしては蓋然性も危険度も高いとは思いますが…… ## フロント 言語:JS, TS FW:React / Next.js UI Component Library:Chakra UI デザイン共有:Figma ### 業務範疇 プランニング都合でフロントの手が足りなくなったときや、自分がむしろフロント書きたいなと思ったときなどにタスクインする形で触っています。 toC媒体としてのプロダクト特性上、フロントの技術的解決幅が強く求められるため、今後ともキャッチアップしてゆこうと思っています。 ただ、現状は、プロパーに頼る部分は頼るといったバランスで取り組んでいます。 - 新規機能開発のコーディング - ビルド・レンダリング周りでの課題が生じた際の調査・解決 ### スキル面について 以下はあまり問題なくできると思います - Hooksの基本的な利用 - 必要に応じて、再レンダリング抑制を行う - コンポーネントをちょうどいい感じに分割(楽しい) - 状態管理ライブラリのプロジェクトでの使用方法を考慮する(濫用しない) - 基本的なHTML / CSSコーディング ただし、主領域ではないのもあって、困ったらフロントに強いエンジニアに(特にスタイルについては)割とすぐ頼っていました。 ## スクラム開発 - 1週間スプリントで行っています - 身贔屓を差し引いても、このチームでのスクラム開発は結構ワークしています - そのため、「ワークしているスクラム開発の知見」が自然と貯まる状態にあるはずです - ふりかえり手法 - 各種セレモニーでのファシリテーションの仕方・チーム単位での意思決定の仕方 - 次のスプリントをよりよくするためのマインド - 健全な議論・批判を活発化させるための場づくり、関係性構築 「スクラムガイド」に立ち返りつつ、より良いスクラムイベントを実施するように努めています 例えば最近だと「スプリントレビューDeep Dive」に触発されて、スプリントレビューの内容改善を行いました。アジェンダを大きく、「検査」「適応」に分けつつ、プロダクトゴールの共通認識を重視する形への変更です。検査では事業KPIチェックなども行いつつ、「ではそれに対して今回のインクリメントはどう影響を出していくのか」を説明しフィードバックをもらいます。適応では、「今後、どういう適応行動を取るとプロダクトゴールにより近づくことができるのか」をworking session的に話し合っています ちなみに[RSGT2023](https://2023.scrumgatheringtokyo.org/index.html)に現地参加しました ## 事業・プロダクトへの向き合い方 これは私がというよりも、事業組織全体が取り組んでいることです。 求人媒体というプロダクト特性上、CV(求人への応募)数の増大、そしてそれを広告費対で考えてROASの増大を狙っていくという大枠の方針が立ちます そうした事業KPIを認識した上で、 - いまどのような仮説が成立するか - 重要度は高いが我々の理解度・解像度が低い情報は何か - 足りていないアクションは何か - これから作る機能はどのKPIへのインパクトを期待したものか などの問いを常に発し、最適行動を取るための議論をみんなが楽しんで行っています また、そのように単に数字を追うだけではなく、 - ユーザーにとって本質的な課題・痛みはなにか - 現状の社会環境に不足しているものは何か - 行動や考察に、具体的な経験に根ざす洞察は紐付けられるか といった問いと向き合い、バーニングニーズを探り続けています ## チームビルディング 以下のような**自発行動**を行っています - 比較的気さくな人間かもしれません。BizDev間交流に貢献しています - 事業部長と1on1を設定し、部署やプロダクトの理想像について早期に意見交換をしました - 事業部の定例MTGで知見共有コーナーを設置し、色々と発表していました - 下記のような発表内容です(タイトルを一部抜粋) - 現代中国の金融事情 - embedded financeの潮流について - SFプロトタイピングについて - 世界はスローダウンしているのか - 聞くこと、聞いてもらうこと - 高原の見晴らしを切り開くこと - 元ネタ帳(チェックしている有料メディア) - What’s “Impro”!? - 世界情勢金融編 - 「プロダクト中心組織として成熟していくためのブックリスト」というドキュメントを執筆し、チーム内のPM知見底上げに寄与しました - 「Code of Conduct」をドキュメントとして執筆しました - 会社単位で掲げられている行動規範に即しつつ、その実装として理解できる規範を事業部のものとして定義した資料となります - 全体公開・合意形成してあり、かつ同意できない部分・改善したほうがいい部分にもフィードバックを常に募っています - ビジネスサイドのメンバーから依頼されたデータ取得等は、あえて「一緒に作業する」ことも - 本人が自力で触れるようになると理想、そうでなくとも信頼感・安心感を作れると思っています - 簡単なスクレイピングツール(Web Scraper)の使用方法共有会などもやりました ## 採用貢献 採用活動にも貢献しています - リファラル - カジュアル面談・一次面接 を好んで行っております。外部のさまざまなバックグラウンドをもつエンジニアといい感じに話すことができていたはずです ## ファシリテーション 開発内外を交えたMTGの事前準備やファシリテーションを行っています 安斎勇樹やアダム・カヘンの著書に学びつつ、自らの状況に引きつけて再解釈・改造、ファシリテーションの質的向上に活かしています ## 趣味範疇のキャッチアップ等 - CULTIBASE Labで動画観たりしています - 割とプロダクト関連の書籍を読んでいます

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

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

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

マネージメント能力

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

アピール項目


アウトプット

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

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

項目 理由(箇条書き) の順で記します ①OS /ネットワーク等、低レイヤー領域や標準化されたプロトコルについての深い知識 ・エンジニアとしての地力につながるはずだからです ・「Webの典型実装しかできない」ではエンジニアというより作業者に近くなってしまうのでは、という懸念があります ・仮にマネージャーになったとしても、ここはできる限り磨くべきではないかと思っています。例えばEMポジションに求められる技術理解観からすると、ツールや詳細実装を全部把握する必要はなくとも概要を素早く吸収するということが求められるはずで、そのためにはやはり基礎が重要だと考えるからです ②対人支援技能・コーチング・ファシリテーション ・必ずしもコーチ・クライアント関係のなかでのみ活かされるものではなく、より広範に応用できるコミュニケーション技能だと思っています ・質感としては「これから身につける」よりも「ライフワーク」とかに近い気がします ・MTGに限らず、出来事・場を賦活する総合技能としてのファシリテーションスキルは、あらゆる立場の人にとって重要だと認識しています ③先端技術動向に関して、数年後ないし数十年後を見据えたキャッチアップをする ・GPTなどもそうですが、「現在時における性能や応用」から「今後どのようなパラダイムシフトが起こり得るか」を考え、アイデアの糧にしたりキャリア構築の基準とする必要はやはりあると思っています ・また反面、過剰な喧伝に流されず、実相を捉えていくのも技術者としての社会的責務だと認識しています。前職のテックリードの方が、Hype Cycle(そしてDon’t Believe The Hype / Public Enemy)を引き合いに出しつつ、ブームのなかから本質を選り分けることの重要性を語っていたのを、時折思い出します ・個人的には「MLとロボティクスとの実用レベルの融合」が今後もっと来るのではないかと予想していますが、これは完全に余談ですね

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

negativeから語った場合: ・怒声をあげる人間がいない ・他人の勇気を挫く言動を憚らない人間(いわゆるブリリアントジャーク)が支配的な空間ではない 難しい人と向き合うのも重要なスキルではあると思いますが、なるべく避けたいです。また、コンピテンシーとして重要な要素や対人コミュニケーションの最低限の意識に欠落がある人物を評価しない・高い位置に就かせないといったマネジメントがまず必要かなと思っています。 positiveから語った場合: ・組織・事業・チームをSubjectとして動く ・心理的安全性があり、意見表明・批判が健全に行われる ・関係性がフラットであり、相互のリスペクトが存在する 本質に向かって突き進むという志向性を共有できている環境だと、さらにそれを良くしていこうという態度で夢中になって仕事をすると思います。

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
学習能力 / 分析力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
SI / アダルト
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す / 趣味は仕事
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で30代前半
好きな Text Editor
VSCode
希望勤務地
埼玉県 / 東京都
希望年収
750万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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