次の世代に残せるプロダクトづくりに携わっていたいです
自分の子どもが大きくなる時代にできるだけ社会負債を残したくないため、自ら関わるプロダクトにはそれが10年後の社会にどれだけポジティブな影響を与えるポテンシャルがあるかを重視します。
このプロジェクト詳細は公開されていません
以下のような課題を持っていた開発組織にマネージャーとして就任しました。
入社した当時は、プロダクト開発組織は職能別に分離され、職能横断で行うべき課題は都度プロジェクトが組閣されて対応に当たる状態でした。
また、画一的なプロジェクト管理体制も敷設されておらず、プロジェクトクローズ時には引き継ぎが、新規プロジェクト立ち上げ時にはアサイン調整などがかなりの負荷としてかかっていました。
プログラミング初学者向けのSaaSということもあり、なかなか経験のあるエンジニア層に会社のプレゼンスが届いておらず、採用に苦戦している状況が続いていました。
また、採用プロセスも試行錯誤の成長期で、採用した人の定着率が低いという課題もありました。
大きくは組織上の課題、採用の課題が重要度・緊急度共に高いと考えられる中で、いくつかの改善施策を実施しました。
エンジニアマネージャー:1人(当方)
エンジニアメンバー:〜20名
職能別に分離されていたプロダクト開発組織を、Feature別に分離する試みのを主導しました。
開発対象のサービスは大きなモノリシック構成の下で、ソフトウェア境界と組織境界をどこに設定するのが最も各チームの認知負荷を下げ、開発生産性向上に寄与するのかを考えて組織デザインを行いました。
また、エンジニアにおいてはどのチームにも落ちない課題のハンドリングや横断での知見共有も重要であるため、2つの取り組みを立ち上げました。
Engineer Libero制度
Engineer横断会
採用においての目下の課題はプレゼンス向上とプロセスの進化でした。
採用プレゼンス向上のために、下記の取り組みを実施しました。
また、採用プロセスの進化のために、下記の取り組みを実施しました。
上記の既存の組織・採用課題への対処に加え、より長期を見据えた時に必要となる組織の発足や、ビジネスメトリクスの収集方法立案など、より経営目線での課題解決に対処してきました。
具体的にはデータ分析専門のチームの立ち上げや、プロダクト開発グループ全体ミーティングの設計などにも主体的に関わってきました。
組織においても採用においても、2020年初期ごろに比べると当時の課題はかなり解消して来れていると言ってもらえることが多いです。
一方で、まだまだ最適解とは程遠い状況にあるので、今解像度が上がってきた課題に対して引き続きどのように対応していくかを模索していく予定です。
具体的に上がっている課題の一例を下記に記載します。
社内の共通インフラ基盤(オンプレミス)上で稼働しているサービスの開発チームにジョインした際、当サービスは事業上スケーラブルに成長させることが望まれる一方、共通インフラ基盤ではそのスピードに耐えられないという課題に直面しました。
そこで、システム全体をクラウド(AWS)上に移行するプロジェクトを立ち上げました。
プロジェクト的な取り組みであったため、行なってきたことを時系列で記載していきます。
(インフラのマイグレーションプロジェクトなので、所謂アジャイルな手法より、堅実なウォータフォールプロセスの相性がいいと判断し、時系列に忠実にプロジェクトを進めていきました)
プロジェクトの概要は下記です。
まず、オンプレミスからクラウドに移行する際に何が技術的な課題になるのかの検証を1ヶ月で実施しました。
アプリケーションコードと大枠のアーキテクチャをヒアリングし、テスト構築したAWS上の環境にデプロイしてみることで、動く箇所、動かない箇所の特定をしました。
その結果、移行に際しては下記が大きな課題として対応が必要そうであることがわかりました。
また、運用チームへのヒアリングを行いながら社内外の外部連携含めた全体アーキテクチャを明らかにし、プロジェクトにかかりそうな工数を概算しました。
所謂プロジェクト憲章を作成し、QCDSのトレードオフスライダーやリスク管理手法などをPOに承認してもらいました。
また、マネージャーに協力してもらいながら対応メンバーを集め、プロジェクト体制を構築していきました。
プロジェクトのコアとなるメンバーに、前期のマイクロスコープ検証の結果をシェアし、クラウド上でのアーキテクチャや必要となるタスクの洗い出し、前後関係の明確化などを行いつつ、プロジェクトの全体感を明らかにしていきました。
最終的に、プロジェクトの最大の目標はスケーラビリティの担保であり、DeliveryやCostはトレードオフの対象となりうることも含めてPOと合意を取り、正式にプロジェクトを開始しました。
プロジェクト期間は、初期のマイクロスコープ検証の結果から見えていた対応課題ごとにチームを分けており、私自身は個々の課題に強くフォーカスするよりは、より大きなリスクポイント(マイクロスコープ検証で述べた課題です)の対処に注力するようにしました。
具体的には、下記のような対応・調整を行なっています。
プロジェクトの開発Phaseで必要なものはほぼ納期内で対応が完了しました。
最終的なデータ移行含めたサービス切り替えは夜間メンテナンス枠を取り、サービス停止の元で慎重に行いました。
確実に移行できる状況を担保するため、入念な移行リハーサルと当日対応手順のブラッシュアップを行い、一度のデータ移行で無事にクラウド上でのサービスを稼働させることができました。
プロジェクトの途中で発覚した問題については、トリアージの結果リリース後の対応にすると決めたものもあったので、リリース後の2ヶ月ほどは申し送り事項の対応を行い、全てクリアになったところで元の運用チームに運用を引き渡すことができました。
概ねQCDSを外すことなく、プロジェクトを成功させることはできたと思います。
一方で、このサービスへのジョイン直後にプロジェクトを立ち上げたため、サービスに対するドメイン知識が不足しており、初期のマイクロスコープ検証期間中に本来であれば拾えたはずの課題を拾いきれず、開発期間中に問題として発生することが多々ありました。
システムリプレイスのようなリスクの伴う大きなプロジェクトは、十分なドメイン知識を持った状態で取り組むことが好ましいと学び、以降はラフにリプレイスを提案することはよっぽどのことがない限りは避けるようにしています。
スタートアップで新規プロダクトの開発に関わった際、プロダクトで生成されるデータを簡単に分析するための基盤構築に携わりました。
当初データエンジニアが誰もいない状況の中、初期の基盤を1人で作り、サービス成長に伴って蓄積される課題に対応するためにデータ基盤の進化も行なってきました。
データソースとしてDynamoDBにあるデータを、分析用SQLエンジンであるAthenaから分析できる状態を作りました。
データマスキングなどのセキュリティ強化対応や、スキーマチェックのためにETLレイヤとしてAWS Glueを利用してパイプラインを構成しました。
対象のデータ量が多くなることを想定して、ユーザーの行動に起因するデータはDailyでPartitioningされた形式で保管することを検討しました。
しかし、ユーザーの固有データとの突合を考慮すると、ユーザーテーブルはDailyでフルダンプを取る必要があり、データ量的にも無駄が多く、なるべく避けたいという課題がありました。
そこで、ユーザーの行動に起因するDailyの一次データを収集するstepと、そのstepで生成されたデータに含まれるユーザーIDのユーザー情報だけを収集するstepに分けてデータ抽出Lambdaを実装し、DailyでPartitioningされたデータに必要なユーザーデータのみを抽出できるようにしました。
また、Lambdaでデータ抽出を行う処理はLambdaのリソース上限と実行時間上限制約で失敗するリスクがあるので、Lambda上でPythonのProcessを用いた並列処理を実装し、効率的にデータ抽出できるようにしました。
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 Streamsから呼び出されるLambdaは同期的に呼び出され、DynamoDBのレコードに対する変更がキャプチャされると、変更イベントに紐ついて実行コントロールされる仕様です。
通常フローではそこまで問題にならないことが想定されたのですが、同期実行Lambdaが失敗したときの挙動次第ではパイプラインが安定的に稼働しないため、意図的に失敗するLambdaを実行して検証しました。
検証の結果、失敗したLambdaは同期イベントの中でかなり長い時間retryを繰り返しているように見え、調べたところデフォルトで10000回のretryを試す仕様になっていました。
そこで、eventSourceMappingの中でretry回数を制限することを検討しました。
しかし、Streamsの中でどのシャードにLambdaのタスクを配置するかはHashによってランダムに決められ、滞留しているシャードに対して後続のタスクが流れてくる可能性もあり、retry制限だけでは更新が頻繁に発生するテーブルにおいて正しくStreamsによるデータ連携ができない恐れがありました。
そこでStreamsの並列度を上げて確保するシャードの数を増やし、上記の滞留リスクを避けるようにしました。
本来は非同期的に実行されるLambdaにおいてSQSなどキューイング層を挟むことが好ましいと考えられますが、Streamsの仕様と対応コストのROIを鑑み、上記の対応でリスク発生可能性を下げる対応を取りました。
バッチレイヤでは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作成の箇所でのデータマージ対応も課題になってくると思いますが、そこまでの対応はこの時できておりません。
開発チーム
開発生産性の高い状態
開発組織のリファクタリングに関してはプロジェクトの方に記載したので、ここでは日々のマネジメント業務について記載します。
20名弱のエンジニアメンバーからなる開発組織のマネジメントに当たって、個々のエンジニアメンバーが如何にパフォーマンスを発揮できる状況で仕事に臨んでもらえるかを意識してきました。
これまでのマネジメントでは、期限付きの明確な目標が設定されていなかったり、どうすれば次のステップに挑戦できるのかが不明瞭だったりしており、私がマネージャーになって最初にメンバーと1on1を行う中で、これらに起因するキャリア上の不安が大きいことがわかりました。
そこで、MBOの導入と定期的な1on1を行いました。
MBOの導入においては、半期ごとに期待されるアウトプットや、その中で自身が身につけたいスキル(技術、非技術問わず)を期初にすり合わせし、期中折を見て振り返ることで、自分が今どこに立っていて、何を目指せばいいのかがわかりやすい状態を目指しました。
定期的な1on1は上記のMBOの補佐でもあるのですが、加えてポジティブマインドを醸成するための話題作りや、相互フィードバックの場として浸透させることで、仕事に向かう上での不安を払拭できる場にするように努めました。
VPoEとして、開発組織全体
採用を全方位で行っているわけではないので、現組織でのアウトカムを最大化するための組織設計や施策の実施
まずは開発組織全般についての組織戦略を策定し、全社に展開して宣言しました。
その後の実行施策において、「組織課題」へのフォーカスだけではエンジニアリングのアウトカムを最大化することが難しいという課題に直面し、VPoEとして組織管掌の責務があるものの、その枠を超えて、技術戦略やプロダクト戦略にも価値を出していく必要性があると感じました。
CTO役割がいない体制だったため、自ら技術戦略の策定や新機能開発チームのリードを行い、エンジニアリング組織のアウトカムやモメンタムも向上を図りました。
結果として、新技術を活用した実験的な機能をリリースし、プレスリリースや特許出願にまでこぎつけました。その中でエンジニア組織だけでなく、この活動を見ていた周辺組織も含めてモメンタムを形成することに成功しました。
https://prtimes.jp/main/html/rd/p/000000102.000037602.html
プロダクトビジョンの達成のために切磋琢磨している環境
心理的安全性の高い環境