ID:69026さん

プロジェクトの詳細

チーム情報

ネイティブエンジニア（3人）
バックエンドエンジニア（自分含め2人）

プロジェクトの詳細

スタートアップのバックエンドエンジニアとしてライブ配信アプリの立ち上げと新機能開発を担当しました。ネイティブアプリの上流設計も担当しました。

プロジェクトにおける自身の役割

• 要件定義
• 全体アーキテクチャの設計
• API開発
• バックエンド、ネイティブ開発のリードエンジニア
• エンジニアリングマネージャー

マネジメント、リーダー経験について❶

プレイングマネージャーとしての業務

課題

プロダクトの年数に比べて技術的負債がかなり多いことが課題として上がっていました。
原因としては

• 明確な設計指針が決まっていない
• コーディング規約がない
• とりあえずリリースすることが目的になっている（それを保守していくという意識がない）

の三つが挙げられました。

工夫

まず短期的にできる施策としてコーディング規約の明確化や設計指針の明確化を行いました。メンバー全体のmtgで自分の設計を発表しメンバーからも賛否の意見をもらうことで自分がこの決定に携わったという意識を各々に持ってもらいました。保守意識の向上については、中期的な施策にはなりますが、機能を作るときに負債が原因で工数が増える例を毎日の定例で取り上げることで後々困るのは自分たちという意識づけも行いました。

成果

その結果、レビューでも規約に沿っていないなどの指摘が飛び交うようになるなどポジティブな変化が見られました。また、見積もりの際にも既存の負債の解消や新たに余計な負債を生まない工数も含まれるようになり、保守性の向上の意識がチーム全体に浸透していきました。ネガティブな側面としてはとりあえず設計とか気にしずに作りたいというモチベーションのメンバーが離れていくきっかけにもなってしまいましたが、プロダクトの成長という観点で言えばポジティブな面が多かったと思います。

プレイングマネージャーとしての業務❷

開発フロー全体を見直し、デグレを８割減

課題

リリースの度に大きめの不具合が出てしまっていました。前述のユニットテストの不足もありますが、１番の問題はQAが十分になされていないことが問題でした。技術的負債がかなり溜まっていたので、デグレがかなり起きやすい状況になっていましたが、それをカバーしうるだけのQAができていませんでした。また通しテスト中に数多くの不具合が出てきて、特定機能のRevertやリリースの延期などを余儀なくされる状況でした。

工夫

マージ前の機能ごとのQAとリリース前の通しQAを積極的に行うことにより、開発時にデグレが起こらないようにするフローを組みました。また通しQAの項目も不足していたので全機能を洗い出し、それぞれの項目に強弱をつけ全体への影響があまり出ないようにもしました。

成果

リリースの度に起こっていた不具合を約８割減少させることに成功しました。また、マージ前のQAを実施したことにより、リリース時の通しテストで報告される不具合もかなり減らせたおかげで安定したリリースフローの実現ができました。

バックエンドとiOSチームのテックリードとしての業務

課題

上記の技術負債の他に技術的な知見が少ないこともチームの課題として挙げられました。CTOが技術的にそこまで深ぼった経験がない方ではあったので致し方のないことでもありました（それを悪とは思っていないです）が、プロダクトの成長には技術的な専門性の向上を各チームで行う必要があると感じました。

工夫

バックエンドとiOSのそれぞれでお手本となるようなものを作るため、ある機能のリファクタリングを企画しました。これに準えて実装すればある程度の質は担保されるというものを目指しました。iOSについては実装は他の方に任せることで属人化を防ぐ取り組みもしてみました。

成果

その結果、他の機能もお手本の機能に倣ってリファクタしていきたいという声がチーム内から出るようになりました。実際のリファクタについても、自分の指摘を元に他の方が似たような指摘をまた他の方にしていくという流れが作れ、チーム全体としての技術力の底上げを図ることができました。

代表的な施策

長期の運用を見越した堅牢な設計技術の導入

課題

Laravelを使用しており、特定の範囲への責務の肥大化やコードの継ぎ足しによる複雑化が進んでおり、ある機能を修正すれば別の機能の不具合が高い確率で発生する状況でした（当然ユニットテストもほぼありませんでした）

工夫

ドメイン駆動開発の一部とCleanArchitectureを導入し、一つ一つのクラスの責務を整理し配置し直すことで修正による影響範囲を限りなく小さく納めることにしました。その結果、機能改修時に別の機能がバグを起こすということはほぼ起こらなくなり、ユニットテストも十分に実装することができました。またバックエンドだけではなく、ネイティブチームへも助言を行い、バックエンドと同じような設計の見直しやユニットテストの導入も進めていました。

成果

変更箇所が局地的になったことによる他の箇所でのバグの発生を少なくすることに成功しました。また、CleanArchitectureを採用したことにより、ビジネスロジック、アプリケーションロジック、プレゼンテーションロジックを実装前に考える必要性が出てきたことにより、実装の抜けもれや仕様の抜け漏れの指摘などが各エンジニアが自分でできるようになりました。

大規模施策の推進

課題

リソースが少ない中で事業計画に沿った機能開発をするために、スピード感を持って機能の開発にあたる必要があった。技術的負債が多い中で複雑な機能をその上に作っていく必要があった。

工夫

自分がPMを兼任することでPdMからの仕様の吸い上げから実装までのリードタイムをなるべく少なくするようにしました。またネイティブ開発も一部兼任したことでAPIの仕様などをスピード感を持って決めることができました。既存の箇所に新機能を実装していく部分については、納期と相談しながら適時技術的負債の解消にあたった。技術負債の解消には自分がバックエンドとクライアントサイドの一部を両方兼任することで余計なコミュニケーションロスを減らし、数時間から数日で解決するようにしました。リリース遅延をなくすためにQAの方と協力して境界値テストや既存のデグレチェックなどをかなり手厚くしてもらいました。

成果

ファンランキング機能や課金システムと連携したいいね機能の拡張などの複雑な機能を事故なく遅延なくリリースすることができました。ユーザーからの評判の声もかなり良く、文字通りやって良かったと言えるプロジェクトになりました。

DBパフォーマンスの向上

課題

リアルタイムの通信が多く行われる状況下でDBのパフォーマンスの問題が顕著になっていました。特にランキングの集計に負荷がかかっており、その度にサーバーリソースが枯渇するという問題があった。

工夫

スロークエリの発見と実行計画をもとにしたインデックスの付与などを行いました。またランキングの集計については、そもそもの設計から見直しました。具体的にはランキングを取得する際に毎回集計処理をしていた部分を、redisのzindexの機能を使い集計を都度行うようにすることで、サーバーに負荷を与えすぎずに要件を満たせるようにしました。

成果

スロークエリの解消により、全体のDBのパフォーマンスが目に見えてわかるくらいに改善しました。またランキングの集計も毎回サーバーが落ちていたところから、大規模イベントのランキング集計にも耐えれるようになりました。

プロジェクト概要

チーム情報

ネイティブエンジニア（自分含め、5人）
フロントエンドエンジニア（自分含め、6人）
バックエンドエンジニア（自分含め4人）

プロジェクトの詳細

サイバーエージェントのDX事業部で外資系小売企業のアプリ開発とバックエンドの認証基盤を実装しました。内定者インターンという立場でしたが、リーダー業務を任せてもらえるなど正社員と遜色ない働き方をしていました。

プロジェクトにおける自身の役割

• 要件定義
• シーケンスの設計
• API開発
• Flutterのリードエンジニア
• 会員統合プロジェクトのプロジェクトリーダー
• DevOpsの推進

マネジメント、リーダー経験について

会員統合プロジェクトのプロジェクトリーダー

課題

開発期間が少ない中で複雑な要件である認証周りの機能を事故なく完遂しなければいけなかったことが大きな課題です。認証には既存の会員情報を統合する要件も含まれており、外部の認証サーバーを考慮する必要がありました。また、LINEアプリについてもOAuthを用いたLINEの認証を通す必要がありました。

工夫

認証自体を難しくしているのが外部の認証基盤との連携であり連携方法にも色々なパターンがあるため、まずはパターンの全洗い出しを行い視覚的にみやすくまとめることにしました。また自分自身がOIDCや認証周りの知識を得るために休日をフルに使って関連書籍を読み漁りプロトタイプを作るなどして認識漏れによる遅延が出ないようにしました。まとめたことをドキュメントにし、チームメンバーが迷子にならないような工夫もしました。

成果

上記の工夫のおかげか遅延をすることなく要件を満たす機能を作れました。また、認証機能自体の理解が深まったおかげでコード自体も綺麗に記述することができました。LINE認証についても不具合を一つも起こさずにリリースをすることができました。

Flutter開発のテックリード

課題

世の中の情報が少ない中で複雑なアプリの保守に耐えうるようなアーキテクチャを選定する必要がありました。

工夫

新技術のFlutterといえども、中身は宣言的UIを基盤としたクライアントサイド開発なので、すでに濃い情報が出回っていたReactのアーキテクチャに関する記事や、iOSのSwiftUI、AndroidのJetpack Composeのアーキテクチャの記事を色々見て知見を集めたり、プロトタイプを作ってみて実際に肌感でメリットデメリットを体験するようにしました。

成果

宣言的UIのメリットを多く受けれるMVVMの構成と複雑なビジネスロジックを吸収できるCleanArchitectureの構成に強いメリットを感じMVVM+CleanArchitectureの構成を採用しました。実際の開発でも途中で要件が変わることが数多くありましたが、レイヤードアーキテクチャを使用していたことにより、変更箇所を限定的にすることができたりなどかなり多くの恩恵を受けることができました。

代表的な施策

DevOpsの推進

課題

protobufの成果物の手動更新に課題がありました。
サーバーとの通信プロトコルにgrpc+protobufを使用しており、当時はバックエンド側で生成したprotobufの成果物をコピペで クライアント側に移す運用をしていましたが、非効率的でミスが多発していたり、バックエンド側の変更にクライアント側が追随できずに開発生産性の低下が見られました。

工夫

上記のことからproto定義とprotobufの更新の自動化が必要であると判断しました。複数リポジトリを跨いだ運用になるので、github actionのworkflow_dispatchを導入し、protoファイルに更新があったら自動で各リポジトリにprotobufの自動生成を含めたPRを作成するようにしました。DevOps系の知識があまりなかったのですが、持ち前のキャッチアップ力を活かしサンプルを自作するなどして実際の運用をシュミレーションするなどしました。

成果

github actionの活用により、自動生成にうまく成功し、更新があるたびにPRを自動で作るようにしたことでprotobufの成果物の更新漏れがなくなりました。その結果、クライアント側でのAPIの繋ぎ込み作業もかなりスムーズになり全体の開発生産性の向上に努めることができました。

フロントエンド開発

納期がかなりギリギリだったということもありフロントエンド開発にも携わる必要が出てきました。フロントエンド開発は初めてでしたが、ネイティブ開発でサーバー間の通信や受け取ったデータの加工、保持などについては共通の考えがあるので最初からかなり高いレベルで貢献できていました。2ページ分の機能をまるまる実装し、フロントエンドの勘所を得ることができました。

※新卒入社後はメディア事業部に配属となり、AbemaTVのiOSエンジニアとして就業していました。

プロジェクトの詳細１

プロジェクト概要

新規事業サービスの立ち上げ

チーム情報

ネイティブエンジニア(2人)
バックエンドエンジニア(自分のみの1人)

使用技術

Ruby on Rails

プロジェクトにおける自身の役割

• 要件定義
• DB設計
• API開発
• テスト
• プロジェクトマネジメント

新規プロダクトに充てられる会社のリソースが限られており、バックエンドのエンジニアが自分のみであったため、バックエンドの全機能の設計や実装、他にはクライアントアプリを含めたプロジェクトマネジメントを行いました。

課題

要件が不明確というのが大きな課題でした。このプロダクトによって、何をどこまで解決したいのかという目的が曖昧で要件もブレブレでした。テーブル設計やAP開発といったバックエンド開発も初めてであったので技術スキルの課題も自身にありました。

工夫したこと

上記の課題の解決のために、まず自分が要件定義に参加することを決めました。そのために、東京の営業所に向かい、実際の従業員の方がやっている作業を体験させてもらうことでどこに課題があり解決できそうかということを肌で感じ、要件に落とし込むように工夫しました。
バックエンド開発についてはRailsのサンプルアプリを自身で作ってみたり、本番プロダクトのアーキテクチャに近づけてみることで勘所をなるべく早く掴むことにしました。まだDB設計については、書籍を読み漁ったり、CTOとの壁打ちをなるべく多くすることで完成度の高い設計を目指しました。また、一般論と並行して要件定義も自分が行ったことでドメイン知識を誰よりも深め、実際の設計に落とし込むようにもしました。

成果

綺麗に正規化したテーブルを実装することができました。（null許容をなるべく無くし、アプリケーション側で余分なハンドリングを行わなくても済むような工夫もしました）またAPIの実装についても本体のプロダクトとの繋ぎ込みも工夫し実装し切ることができました。プロダクト自体については、実際の現場作業を体験した要件定義を行なったことで、現場との認識乖離を防ぐことに成功し、大変良かったという声をいただくことができました。

プロジェクトの詳細２

プロジェクト概要

ジモティーiOSアプリの保守運用

使用技術

Swift、RxSwift、Moya

自分の担当領域

iOSアプリ全体のアーキテクチャ設計

課題

APIとの通信部分のコードが全て別々に書かれていてDRY原則から離れていた。そのせいでAPIの改修があった時にアプリ側の修正範囲も多くなっていた。

工夫したこと

通信部分のコードをまとめるAPIClientを作成することで通信そのものの処理を共通化した。また大規模な改修になるためチームのリソースをヒアリングし、施策が中途半端にならないような工夫をした。他の人が置き換え作業をできるようにInterfaceは全く変えずに内部のみを変換するようにした。（元々がCleanArchitectureを採用していたので、Repositoryの中身を置き換えるだけで済みました。）

成果

Moyaというライブラリを取り入れることでAPIの仕様をクライアント側で宣言的に記述できるようにし、見通しをよくすることに成功した。また、全APIの置き換えも他の方に引き継ぎ、２ヶ月程度で事故なくリプレイスすることに成功した。