ID:43130さん

### 概要 コロナ禍におけるサテライトオフィスのデジタルツイン化 - ドローンで撮影したサテライトオフィスの画像を用いたフォトグラメトリ。 - ラズパイを使った人感カメラによるオフィス内の撮影画像と、`M5Stack` とセンサを用いた温度・湿度・気圧のSlack連携。 ### 成果 - 新領域の技術獲得 - IoTデバイス（OSやセンサーなど）の選定から `Rust` や `Blockly` を使った組み込みの実装といった普段の業務で使用しない領域の技術に触れることができた。 - 同様にドローンの操作やフォトグラメトリ技術についての知見を獲得した - 知見の社内共有 - M5Flowを用いて非エンジニアでもM5Stackを使った簡単なIoTの実装ができるハンズオンを実施。同時にIoTを取り巻くトレンドや技術の背景などを社内に共有した。 ### チーム規模・役割 リードエンジニア - フロントエンド2名、バックエンド3名、インフラ2名 - フロントエンド・バックエンドの一部・インフラの設計と実装

### 概要 『楽待アプリ』と『楽待加盟店アプリ』を使って、不動産投資家と不動産会社がビデオ通話できるようにした。 ### プロジェクトの目的 - 不動産投資家の支援 - 不動産会社の活動支援 ### 成果 - 2020年6月度社長賞を受賞 - [プレスリリース](https://www.rakumachi.jp/news/column/261843) ### チーム規模・役割 エンジニアメンバー（技術選定・アーキテクチャ設計・FE/BE実装・一部データパイプライン実装） 開発マネージャ2名、エンジニア5名、デザイナー1名 ### 時系列 #### 2020年4月 技術検証 - 調査の視点 - ビデオ通話とはどういう技術で成り立ってきたのか。 - 現在主流な技術は何か。今後どのような技術が主流になりえるか。 - リソースを考慮した場合、どの技術を選択することが最適解になるか。 - サンプルアプリ作成 - 20通りほどある実現手段のうち、`Agora.io` の `React Native` 用SDKを用いてサンプルアプリを実装した。 最終的に提案したサンプルアプリで実装することを社長と合意。採用に至った観点は以下の3つ 1. アプリに組み込んでデモ通話を作ることができた。 1. 通話品質に対して料金が非常に安かった。 1. 拡張性に優れていて、不動産売買のオンライン契約に必要な要件を満たしていた。 #### 2020年5月 - フロントエンドの実装（スマホアプリ） 要求仕様の各種機能と、エラーハンドリングなどの非機能要件を実装。具体的には以下。 - カメラon/off - マイクon/off - 通信状態の制御とエラーハンドリング - 通話記録のログデータ取得 - バックエンドの実装 ビデオ通話を要求するリクエストを受け取り認証/認可を行なうサービスを作成、主にAgora Cloudによって提供されるAPIの制御を実装した。 - ML Opsの実装 通話記録をビッグデータとして活用できるようにデータパイプラインを `Google Cloud BigQuery` を活用して作成した。また、通話の解析結果をMetabaseというBIツールを通じてマーケティング部が活用できるようにした。

### 概要 マーケティング部が企画した「楽待 大家さんデビュープログラム」のシステム部分を実装した。UIデザイナー１名と協力し、マーケティング部の要望に応えるシステムを実現した。 ### プロジェクトの目的 - 不動産投資家の支援 ### 成果 - 申込数1000件以上、不備のある申し込み0件 - アプリのDAU17%上昇 ### 時系列 #### 12月 1. 要件定義 2. システム設計 3. テスト設計 - 要件定義 期限は1/16リリース。解決すべき課題が大きく2つ存在した。 1. 「キャンペーン」の運用を恒常化 - 状況 これまではキャンペーンを行なうたびにハードコーディングしていたため、キャンペーン終了に伴って、ソースの削除を行ってリリースしなければならなかった。 - 小課題1 アプリのリリースは、「審査に時間がかかること」、「リグレッションテストで工数がかかること」、「ユーザーにとって負担になること」の3点を考慮して回数を極力減らしたい。 - 小課題2 次回以降のキャンペーンで設計を使いまわせず、知見、データが溜まらない。 - 小課題3 ソースの削除忘れなどでバグ、デザイン崩れのリスクを抱えることになる。 2. ディープリンクの実現 - 状況 マーケティング部の要望で、キャンペーンのLPへの導線としてディープリンクを実現したいと承った。 - 小課題1 直近で別のチームがディープリンクを実現していたが、特定の機能のために実装されおり、汎用化されていなかった。 - 小課題2 Firebase Analyticsで計測するパラメータの一貫性がなく、集計する際に不都合だった。 - システム設計 - 「キャンペーン」の運用を恒常化 主として使用した技術が `Firebase Remote Config`。既存システムに導入されていなかったため、技術調査から1人で行なった。`Remote Config`はJSON形式のデータストアで、これをアプリに組み込むことでソースリリースなしにクライアントに対して変更を伝えられるという特徴を持つ。キャンペーンに関する変数を設計し、`Remote Config` で管理することによって、ソースリリースなしでキャンペーンのon / offを実現することを目指した。 - ディープリンクの実現 主として使用した技術が `Firebase Dynamic Links`。11月に別チームが別の機能のために導入していたが、その機能に特化しており汎用化されていなかったため、「DynamicLinks関連のソースコードのリファクタリング」と「パラメータの再設計」の2つを行う方針にした。キャンペーンとしては自社サービス外の広告、WEBアプリのバナーに展開できるようURLを用意。 #### 1月 4. 実装 5. テスト 6. リリース - 開発環境 ホスト上に作業ディレクトリを作成し、Githubからソースをクローンして管理している。Xcode / Android Studioでシミュレータ / エミュレータ / 実機を立ち上げ各OS毎の挙動をデバッグしながら実装する。ソースを変更はホスト上のターミナルにバンドラ（Node.jsサーバ）を立ち上げて更新。 - バックエンド実装 - Remote Config `react-native-firebase` に `Remote Config` を使用できる仕組みがあったため、それを使用。すでに導入されている `redux-saga` と親和性を保ち、かつ今後Remote Configが別の機能でも活用できるようにフェッチする部分とデータハンドリングする部分を切り分けて実装した。その成果の副産物としてA/Bテストを実現できた。 - Dynamic Links `Dynamic Links` はURLを踏んだクライアントが、`Firebase` に登録されたデバイス情報に基づいてアプリに遷移させる仕組み。今回はハンドラの汎用化設計＋リファクタリングを行った（小課題1）。また、計測に関して（小課題2）はパラメータ設計に基づいて正規表現を当てるメソッドを作成し、そこを通過するようにした。 - フロントエンド実装 ランディングページの `HTML` / `CSS` 部分はデザイナーの方にタスクを振って担当していただいた。 自分は、申し込みフォームの作成とそのバリデーションを実装した。申し込みフォームは「フォームメーラー」という外部サービスを用いて仕組みを実現した。フォームのバリデーションは `HTML5` 標準のものと、`JavaScript` を組み合わせて作成。一番難しかったのは添付されたファイルサイズのバリデーション。フォームメーラーで求められるファイルの規格をバリデーションに組み込んで、滞りなく応募できるようにした。 - リリース 途中からデザイン要件が変わり、期日通りのリリースが間に合わなくなる可能性が浮上。キャンペーンとして運用が成立するために必須のタスクを洗い出し、優先度が高い順に取り組むことで期日通りのリリースを実現。 - 評価 キャンペーン実施中のため、社長賞は終了後に判断するとのこと。特に評価評価されたポイントは、システム設計の出来のよさと、要件の変更にもかかわらず期日通りのリリースができたことの2点。

### 概要 あるサービスに関する加盟店値上げプロジェクトを営業部の部長と2人で発足させ、ビジネス要件の企画をするところからシステムの実装、テスト、リリース、保守までを行った。 ### 成果 実施後1ヶ月でサービスの月次売り上げが前年同月比で+500万円を達成した。この成果によって11月度社長賞を受賞した。 ### 時系列 #### 10月 - 企画と要件定義 過去の売上推移や加盟店の契約状況を分析し、加盟店に対する値上げの内容を企画。それを社長に提案し承認を得た。また、独占禁止法、二重価格、事前告知の必要性など、法務的な観点から事前に想定されうる懸念点についても考慮した。 - 分析 要件を確定させる以前の仮説設定と分析は基本的に1人で行なった。 1. 他社の値上げ事例の調査 2. 当社の過去の売上・契約データ分析 - 他社事例の調査 類似したビジネスモデルを持つ企業の事例を海外の法人まで含めて20事例ほど調査。同様のプロジェクトの成否を有価証券報告書などを時系列順に追って比較、成功するプロジェクトの進め方とは何かについてまとめた。 - 過去のデータ分析 過去の売上推移データと加盟店の契約状況の分析、および市況調査アンケートの企画・実施・結果分析を行なった。実装としては`metabase` を使って `SQL` を実行しデータを取得。それらを用いてプロジェクトを行なった結果の売上推移をシミュレーションした。この際、`Python` を用いてごく簡単な機械学習でモデル作成を行った。 #### 11月 確定した要件に基づいて、システム側の実装を1人で行なった。 実務の流れは以下。 1. 業務フローの設計 2. システム設計 3. テスト設計 4. 実装 5. テスト 6. リリース 1. 業務フローの設計 営業部の部長と協力しながら、業務フローを設計、可視化。 ツールとしては、`draw.io`、`plantuml`を用いてアクティビティ図を作成した。 2. システム設計 システム全体は `Symfony1.4` / `Doctrine` のMVCを主体とした構成になっていた。ただ、課金に関するシステム設計は10年以上前にドメイン駆動設計（以下DDD）で行われており、全容を理解している人がいなかった。そのため、独力で『エリック・エヴァンスのドメイン駆動設計』を参考にしつつ仕様を理解した。複雑な課金体系と、テストマーケティングの新しい概念を組み合わせる難易度が高い設計だった。ツールとしてはplantumlを用いてクラス図の作成を行った。また他に、UIデザインをAdobeXDを用いて行った。 3. 実装 - 開発環境 `Virtual Box`で、実行環境（`Ubuntu12.04`）とreverse proxy（`Ubuntu14.04`）を用いた。開発環境の構築は既存社員が持つVMのデータをダンプして、それをもらってインポートするという秘伝のタレ的な構築方法。個人のreverse proxyに社内IPが割り当てられるため、プロキシサーバの `nginx` や証明書関連の設定は自分で行なった。 - ソースコード管理 `GitHub` を用いて行った。ソースの変更は`nfs`マウントを用いて、mac（ホスト）上の`VSCode`から行なった。 - バックエンド実装 「加盟店値上げ」に対応するシステムであるため、ドメイン本体には極力手を入れず、UtilityにDDD部分とMVC部分の緩衝材になるメソッドを実装した。ロジックの根幹になるメソッドを1つに集約し、全てのメソッドがその判定を通るようにしたことで、仕様変更に対する保守性を担保できる実装になった。 - フロントエンド実装 新しい契約と既存の契約で内容が異なるため、営業事務・加盟店の方々が操作を間違えないよう、各アカウント毎に表示する内容を変えた。 - 評価 開発部の部長から「適切な設計ができた」という評価をいただき、社長賞を受賞した。 #### 12月 - 障害 負荷テスト実行漏れによって数店舗の加盟店がプラン開始できない障害が発生した。自身で調査を行なった結果、バッチ処理実行時の `Doctrine` のメモリリークが主たる原因だということが判明した。調査の手段としては `rundeck` のログ解析、`Doctrine` の中身をステップ実行で確認するなどを採用した。 - 2020年問題 プランの実働開始が2020/01/01からだったので、2019/12/31の夜中から2020/01/01の明け方まで本社サーバにVPNで接続し、バッチ処理の監視を行った。