Aquila

# 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由来のデザインパターンの類いも、サービス初期のアーキテクチャとしてはtoo mutchと判断して避けている - ただ、事業成長とともにドメインの解像度が上がり、戦略レベルから導入できるならアリだとは思います ### コードの治安面に寄与した行動 - 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へのインパクトを期待したものか などの問いを常に発し、最適行動を取るための議論をみんなが楽しんで行っています また、そのように単に数字を追うだけではなく、 - ユーザーにとって本質的な課題・痛みはなにか - 現状の社会環境に不足しているものは何か - 行動や考察に、具体的な経験に根ざす洞察は紐付けられるか といった問いと向き合い、バーニングニーズを探り続けています ## チームビルディング 以下のような**自発行動**を行っています - 比較的気さくな人間かもしれません。ビジネスメンバー・開発メンバー間の交流に貢献しています - 事業部長と1on1を設定し、部署やプロダクトの理想像について早期に意見交換をしました - 事業部の定例MTGで知見共有コーナーを設置し、色々と発表していました - 下記のような発表内容です（タイトルを一部抜粋） - 現代中国の金融事情 - embedded financeの潮流について - SFプロトタイピングについて - 世界はスローダウンしているのか - 聞くこと、聞いてもらうこと - 高原の見晴らしを切り開くこと - 元ネタ帳（チェックしている有料メディア） - What’s “Impro”!? - 世界情勢金融編 - 「プロダクト中心組織として成熟していくためのブックリスト」というドキュメントを執筆し、チーム内のPM知見底上げに寄与しました - 「Code of Conduct」をドキュメントとして執筆しました - 会社単位で掲げられている行動規範に即しつつ、その実装として理解できる規範を事業部のものとして定義した資料となります - 全体公開・合意形成してあり、かつ同意できない部分・改善したほうがいい部分にもフィードバックを常に募っています - ビジネスサイドのメンバーから依頼されたデータ取得等は、あえて「一緒に作業する」ことも - 本人が自力で触れるようになると理想、そうでなくとも信頼感・安心感を作れると思っています - 簡単なスクレイピングツール（Web Scraper）の使用方法共有会などもやりました ## 採用貢献 採用活動にも貢献しています - リファラル - カジュアル面談・一次面接 を好んで行っております。外部のさまざまなバックグラウンドをもつエンジニアといい感じに話すことができていたはずです ## ファシリテーション 開発内外を交えたMTGの事前準備やファシリテーションを行っています 安斎勇樹やアダム・カヘンの著書に学びつつ、自らの状況に引きつけて再解釈・改造、ファシリテーションの質的向上に活かしています ## 趣味範疇のキャッチアップ等 - CULTIBASE Labで動画観たりしています - 割とプロダクト関連の書籍を読んでいます