ID:62847さん

# 背景 以下のような課題を持っていた開発組織にマネージャーとして就任しました。 ## 当時の組織状況 入社した当時は、プロダクト開発組織は職能別に分離され、職能横断で行うべき課題は都度プロジェクトが組閣されて対応に当たる状態でした。 また、画一的なプロジェクト管理体制も敷設されておらず、プロジェクトクローズ時には引き継ぎが、新規プロジェクト立ち上げ時にはアサイン調整などがかなりの負荷としてかかっていました。 ## 当時の採用状況 プログラミング初学者向けのSaaSということもあり、なかなか経験のあるエンジニア層に会社のプレゼンスが届いておらず、採用に苦戦している状況が続いていました。 また、採用プロセスも試行錯誤の成長期で、採用した人の定着率が低いという課題もありました。 # 取り組んだこと 大きくは組織上の課題、採用の課題が重要度・緊急度共に高いと考えられる中で、いくつかの改善施策を実施しました。 ## 組織構成 エンジニアマネージャー：1人（当方） エンジニアメンバー：〜20名 - フロント/バックエンド：〜15名 - SRE：2名 - DRE：2名 - アプリ：1名 ## 組織上の課題 職能別に分離されていたプロダクト開発組織を、Feature別に分離する試みのを主導しました。 開発対象のサービスは大きなモノリシック構成の下で、ソフトウェア境界と組織境界をどこに設定するのが最も各チームの認知負荷を下げ、開発生産性向上に寄与するのかを考えて組織デザインを行いました。 また、エンジニアにおいてはどのチームにも落ちない課題のハンドリングや横断での知見共有も重要であるため、2つの取り組みを立ち上げました。 1. Engineer Libero制度 - エンジニアチームメンバーが週替わりでエラー対応や他チームからの問い合わせの一次窓口となり、Featureチームの間に落ちるボールを拾いやすくするための制度です。 - 下記登壇イベントに概要を記載しています。 - https://speakerdeck.com/progate/progate-icare-devmeetup 2. Engineer横断会 - 各Featureチームが対応している課題の共有や技術的に他チームに困っていることの相談ができる場を隔週で実施しています。 - この会をきっかけにチームを跨いだ協業を促したり、普段触れないドメインで利用されている技術に関する知見を得たりしています。 ## 採用の課題 採用においての目下の課題はプレゼンス向上とプロセスの進化でした。 採用プレゼンス向上のために、下記の取り組みを実施しました。 - TechBlogの開設 - 社内のエンジニアがどういう開発を行なっているのか、趣味でどんな技術に触れているのかを発信するためのブログを開設しました。 - 平常時は月に1本程度の頻度ですが、advent calendar期間にエンジニア全員で寄稿して記事を作り溜めたりなどし、採用候補者の方に見てもらうことで組織のメンバーになるイメージを持ってもらいやすくなることを目指しています。 - イベント登壇 - 元々AWS系のコミュニティ運営をやっていた経験があり、その繋がりでいくつかのイベントに登壇してエンジニア向けに会社のアピールを行なってきました。 - 大きめのイベントだと、 AWS Dev Day 2021 や DevRel Conference 2021 などに登壇しています。 また、採用プロセスの進化のために、下記の取り組みを実施しました。 - 採用フローの見直し - 元々は　カジュアル面談→技術選考→最終選考　という選考フローでしたが、頑張って採用した人がカルチャー上のミスマッチなどで早期に離職するケースが相次いでいたため、技術選考の前にコンピテンシー選考のフローを追加するようにしました。 - また、その際に確認すべきコンピテンシーについて、ボードメンバーや採用チームとすり合わせを行い、型化された選考手法として手離れしていける状況を目指しています。 ## 経営の課題 上記の既存の組織・採用課題への対処に加え、より長期を見据えた時に必要となる組織の発足や、ビジネスメトリクスの収集方法立案など、より経営目線での課題解決に対処してきました。 具体的にはデータ分析専門のチームの立ち上げや、プロダクト開発グループ全体ミーティングの設計などにも主体的に関わってきました。 # 成果と課題 組織においても採用においても、2020年初期ごろに比べると当時の課題はかなり解消して来れていると言ってもらえることが多いです。 一方で、まだまだ最適解とは程遠い状況にあるので、今解像度が上がってきた課題に対して引き続きどのように対応していくかを模索していく予定です。 具体的に上がっている課題の一例を下記に記載します。 - エンジニア横断での長期的な課題（DevExの向上や大規模なリアーキテクチャなど）を進める体制がない - ソフトウェア境界と組織境界が最適化されていない箇所が存在し、チーム間のコミュニケーション・認知コストが高い - 採用プレゼンスをさらに一段引き上げないと、より好ましい候補者層にアトラクトしきれていない

# 背景 社内の共通インフラ基盤（オンプレミス）上で稼働しているサービスの開発チームにジョインした際、当サービスは事業上スケーラブルに成長させることが望まれる一方、共通インフラ基盤ではそのスピードに耐えられないという課題に直面しました。 そこで、システム全体をクラウド（AWS）上に移行するプロジェクトを立ち上げました。 # 取り組んだこと プロジェクト的な取り組みであったため、行なってきたことを時系列で記載していきます。 （インフラのマイグレーションプロジェクトなので、所謂アジャイルな手法より、堅実なウォータフォールプロセスの相性がいいと判断し、時系列に忠実にプロジェクトを進めていきました） プロジェクトの概要は下記です。 - 期間：9ヶ月 - 人数：10人程度（Phaseによって多少の増減あり） ## マイクロスコープ検証 まず、オンプレミスからクラウドに移行する際に何が技術的な課題になるのかの検証を1ヶ月で実施しました。 アプリケーションコードと大枠のアーキテクチャをヒアリングし、テスト構築したAWS上の環境にデプロイしてみることで、動く箇所、動かない箇所の特定をしました。 その結果、移行に際しては下記が大きな課題として対応が必要そうであることがわかりました。 - 社内の基幹システムとの接続 - Oracleのバージョン・エディションが維持できない事によるアプリ互換性担保 - 共通インフラ基盤が提供しているサービス（メールゲートウェイや踏み台、ログ監査など）の利用不可 また、運用チームへのヒアリングを行いながら社内外の外部連携含めた全体アーキテクチャを明らかにし、プロジェクトにかかりそうな工数を概算しました。 ## プロジェクト立ち上げ 所謂プロジェクト憲章を作成し、QCDSのトレードオフスライダーやリスク管理手法などをPOに承認してもらいました。 また、マネージャーに協力してもらいながら対応メンバーを集め、プロジェクト体制を構築していきました。 プロジェクトのコアとなるメンバーに、前期のマイクロスコープ検証の結果をシェアし、クラウド上でのアーキテクチャや必要となるタスクの洗い出し、前後関係の明確化などを行いつつ、プロジェクトの全体感を明らかにしていきました。 最終的に、プロジェクトの最大の目標はスケーラビリティの担保であり、DeliveryやCostはトレードオフの対象となりうることも含めてPOと合意を取り、正式にプロジェクトを開始しました。 ## プロジェクト管理 プロジェクト期間は、初期のマイクロスコープ検証の結果から見えていた対応課題ごとにチームを分けており、私自身は個々の課題に強くフォーカスするよりは、より大きなリスクポイント（マイクロスコープ検証で述べた課題です）の対処に注力するようにしました。 具体的には、下記のような対応・調整を行なっています。 - 社内の基幹システムとの接続 - AWSと社内のインフラで、DirectConnectを用いた専用線を敷設しました。 - 正確には、物理的な専用線自体はすでに他のところで利用されていたものがあったので、今回はVIFやVLAN追加がメインのではあったのですが、基幹システムの情報をクラウドに流すことは前例がなかったので、調整含めてスケジュールは長めに引き、有事に備えました。 - Oracleのバージョン・エディションが維持できない事によるアプリ互換性担保 - オンプレ上ではEnterpriseEdition、ver11のOracleが共通DBとして稼働していたのですが、AWS上に移行し、かつRDSを用いるためにはStandardEditionで、バージョンも少し差異があるエンジンの選択が必要でした。 - そこで、Enterprise→Standardへのダウンエディションで発生しうる問題の洗い出し（機能の利用状況など）と、バージョン差異によるParameter Groupの調整など、社内のDBA専門チームに協力を仰ぎ、一つ一つの差異を取り除けるよう検討を進めました。 - 共通インフラ基盤が提供しているサービス（メールゲートウェイや踏み台、ログ監査など）の利用不可 - 最も苦労したのはメール送信手法の担保でした。オンプレミス環境では商用のメールゲートウェイを用いてメール送受信を行なっていましたが、AWSマネージドのSESを用いる場合は確実なバウンス管理や受信ロジックの自前実装が必要となることが判明しました。 - これについてはプロジェクトメンバー内の想定リソースでは対応できないことが確実だったので、社内のクラウド専門チームに協力を仰ぎ、汎用メールゲートウェイ相当のサービスをサーバーレス構成で構築してもらいました。 ## クローズ・運用 プロジェクトの開発Phaseで必要なものはほぼ納期内で対応が完了しました。 最終的なデータ移行含めたサービス切り替えは夜間メンテナンス枠を取り、サービス停止の元で慎重に行いました。 確実に移行できる状況を担保するため、入念な移行リハーサルと当日対応手順のブラッシュアップを行い、一度のデータ移行で無事にクラウド上でのサービスを稼働させることができました。 プロジェクトの途中で発覚した問題については、トリアージの結果リリース後の対応にすると決めたものもあったので、リリース後の2ヶ月ほどは申し送り事項の対応を行い、全てクリアになったところで元の運用チームに運用を引き渡すことができました。 # 成果と課題 概ねQCDSを外すことなく、プロジェクトを成功させることはできたと思います。 一方で、このサービスへのジョイン直後にプロジェクトを立ち上げたため、サービスに対するドメイン知識が不足しており、初期のマイクロスコープ検証期間中に本来であれば拾えたはずの課題を拾いきれず、開発期間中に問題として発生することが多々ありました。 システムリプレイスのようなリスクの伴う大きなプロジェクトは、十分なドメイン知識を持った状態で取り組むことが好ましいと学び、以降はラフにリプレイスを提案することはよっぽどのことがない限りは避けるようにしています。

# 背景 スタートアップで新規プロダクトの開発に関わった際、プロダクトで生成されるデータを簡単に分析するための基盤構築に携わりました。 当初データエンジニアが誰もいない状況の中、初期の基盤を1人で作り、サービス成長に伴って蓄積される課題に対応するためにデータ基盤の進化も行なってきました。 # 取り組んだこと ## 最初のデータ基盤設計・実装 ### システム概要 データソースとしてDynamoDBにあるデータを、分析用SQLエンジンであるAthenaから分析できる状態を作りました。 データマスキングなどのセキュリティ強化対応や、スキーマチェックのためにETLレイヤとしてAWS Glueを利用してパイプラインを構成しました。 ### アーキテクチャ・選定技術 - アーキテクチャ - [DynamoDB] -> [Lambda] -> [S3] -> [Lambda] -> [GlueJob] -> [S3] -> [Crawler/DataCatalog] -> [Athena] - 選定技術 - パイプライン管理：StepFunctions - ジョブ実行トリガー：CloudWatch Events ( cron event ) - 基盤IaC：Terraform - CI/CD：Github Actions ### 課題と解決方法 #### 1. 必要なデータのみの抽出 対象のデータ量が多くなることを想定して、ユーザーの行動に起因するデータはDailyでPartitioningされた形式で保管することを検討しました。 しかし、ユーザーの固有データとの突合を考慮すると、ユーザーテーブルはDailyでフルダンプを取る必要があり、データ量的にも無駄が多く、なるべく避けたいという課題がありました。 そこで、ユーザーの行動に起因するDailyの一次データを収集するstepと、そのstepで生成されたデータに含まれるユーザーIDのユーザー情報だけを収集するstepに分けてデータ抽出Lambdaを実装し、DailyでPartitioningされたデータに必要なユーザーデータのみを抽出できるようにしました。 また、Lambdaでデータ抽出を行う処理はLambdaのリソース上限と実行時間上限制約で失敗するリスクがあるので、Lambda上でPythonのProcessを用いた並列処理を実装し、効率的にデータ抽出できるようにしました。 #### 2. 分析用のデータ整形 SQLに明るくない人でもユーザーの行動に起因するデータと、ユーザーの固有データを突合して分析できるようにする必要がありました。 Pipelineではデータソースのテーブルごとに分析用テーブルを作成し、分析用のデータマートはViewなどで実現するのが一般的には好ましいと思われますが、当時のAthenaではCTASがサポートされておらず、データマートをどのレイヤで生成するかが課題になりました。 採用した解決手法として、ETL処理を行うGlueのTransform処理の中でテーブルJoinを行うようにしました。 具体的には、GlueJob内で抽出したデータに対して、DropFieldやDataMaskingなどの前処理を行った後に生成されているDynamicFrameに対して指定KeyでのJoinを行い、一連のParquet形式データとしてS3に出力することで、DynamoDB上のいくつかのテーブルを分析用に結合したDatamartを生成しました。 ### 成果と残存課題 マネージドサービスの組み合わせで、自動化されたデータ処理パイプラインの実装を行い、容易にプロダクトデータを分析できる基盤を構築しました。 しかし、テーブルごとにデータ抽出処理用のLambdaとStepFunctions上のパイプラインを増やさないといけないという運用上の課題や、データ鮮度が1日であるという課題が残り、後に対応することになりました。 ## リアルタイムデータ処理基盤設計・実装 ### システム概要 上記で作成したデータ基盤において、データの鮮度がDailyであり、よりリアルタイム性の高いデータ分析を行えないという課題があり、ニアリアルタイムでDatalakeに連携するシステムを構築しました。 既存のパイプラインはバッチレイヤとして残し、新規のパイプラインをスピードレイヤとして活用する方式です。 ### アーキテクチャ・選定技術 - アーキテクチャ - [DynamoDB] -> [DynamoDB Streams] -> [Lambda] -> [Kinesis Firehose] -> [S3] -> [Crawler/DataCatalog] -> [Athena] - 選定技術 - パイプライン管理：イベントドリブン - 基盤IaC：Terraform - CI/CD：Github Actions ### 課題と解決方法 #### 1. 同期実行されるLambdaのハンドリング DynamoDB Streamsから呼び出されるLambdaは同期的に呼び出され、DynamoDBのレコードに対する変更がキャプチャされると、変更イベントに紐ついて実行コントロールされる仕様です。 通常フローではそこまで問題にならないことが想定されたのですが、同期実行Lambdaが失敗したときの挙動次第ではパイプラインが安定的に稼働しないため、意図的に失敗するLambdaを実行して検証しました。 検証の結果、失敗したLambdaは同期イベントの中でかなり長い時間retryを繰り返しているように見え、調べたところデフォルトで10000回のretryを試す仕様になっていました。 そこで、eventSourceMappingの中でretry回数を制限することを検討しました。 しかし、Streamsの中でどのシャードにLambdaのタスクを配置するかはHashによってランダムに決められ、滞留しているシャードに対して後続のタスクが流れてくる可能性もあり、retry制限だけでは更新が頻繁に発生するテーブルにおいて正しくStreamsによるデータ連携ができない恐れがありました。 そこでStreamsの並列度を上げて確保するシャードの数を増やし、上記の滞留リスクを避けるようにしました。 本来は非同期的に実行されるLambdaにおいてSQSなどキューイング層を挟むことが好ましいと考えられますが、Streamsの仕様と対応コストのROIを鑑み、上記の対応でリスク発生可能性を下げる対応を取りました。 #### 2. Kinesis Firehoseの裏で稼働するETL Lambda バッチレイヤではETLにGlueJobを用いておりましたが、スピードレイヤではGlueJobの起動時間や実行コストが割りに合わないことから、Kinesis Firehoseの裏のLambdaでETL処理を実行するようにしました。 Kinesis Firehoseの裏で実行されるデータ変換Lambdaにはpayloadに対する制約がいくつか存在し、データハンドリングの工夫が必要でしたが、ここでの知見に関しては下記に記載しております。 https://blog.kzk-maeda.work/2021/01/08/ddb_stream_with_kdf/ ### 成果と残存課題 更新頻度の高いテーブルに対して、ニアリアルタイムでデータ連携する基盤を構築しました。 しかし、今回対象としたのはトランザクショナルな追記型のテーブルがメインになっており、UPDATE/DELETEも頻繁に走るテーブルに対して厳密なCDCを行うことは当時実施しませんでした。 CDCを行う場合、Datamart作成の箇所でのデータマージ対応も課題になってくると思いますが、そこまでの対応はこの時できておりません。