ID:66736さん

# 時期 2023年8月〜2024年11月 # 概要 会社のドライバー側利用率向上戦略の一環として、有料会員機能の改修を行うことになりました。 従来から有料会員機能(バリュープラス)は存在していましたが、有料会員への価値提供という点でコストパフォーマンスが合致していないことがアンケート等を通じて判明してきたためです。(有料会員の先行予約でも人気のある駐車場予約ができないことがある) ## 主な取り組み 基本設計、実装、テストが自身の主業務として割り当てられていたが、要件定義の点においてもPdMと協力しながら取り組むことになりました。 またPdMが多忙のためプロジェクトの進行管理等も行う、プロジェクトマネージャとしてタスクアサインされました。 ## メンバー - プロジェクトマネージャ 1名(自身) - バックエンドエンジニア 2名 (自身・業務委託1名) - デザイナー 1名 - iOSエンジニア 1名 - Androidエンジニア 1名 ## 主な仕様 - 有料会員は通常会員よりも数時間早く予約をすることができる - 常時、予約料金10%オフ - 新旧プランは併存する - 新プランに移行した時点で旧プランは解約となる - 旧プランで行っていたクーポン配布は廃止する - 旧プランで配布予定のクーポンは乗り換え時に一括配布する ## 対応、打ち手 - __主な仕様__にもある、乗り換え時にクーポンを一括配布する仕様については、自己提案を行い詳細な部分での仕様修正を行いました。当初要件は単純に、旧プラン残り月数から算出した枚数を配布すれば良いというものでした。 - しかしながら、旧プランクーポンは決済バッチ実行時に定期配布されるもののため、クーポン配布当日に乗り換えが行われると配布枚数に差異が生じることに気付き、その部分を考慮した仕様にするべきと提案し現在の仕様になりました。 - 新プランは旧プランと異なり、即解約とするとユーザーの不利益が大きいかつ継続して利用して頂きたいという趣旨に反するものでしたので__解約リクエスト__という機能を持たせました。__(個人としての対応)__ - 解約リクエストした後もプラン期限日までにユーザーに価値提供をして、継続したいとなるパターンもあると考えて__解約リクエスト取り消し__という機能を提案し受け入れてもらうことができました。__(個人としての対応)__ - 技術的な面では古いアーキテクチャで機能している関連コードを__コアレイヤパターン__に置き換えました。 - またそのリアーキテクチャ実現のためにバックエンド側のエンジニアだけでなく、アプリ側エンジニアにもエンドポイント設計やリクエスト、レスポンス設計の相談を積極的にするようにしました。__(チーム・組織としての対応)__ ## バリュー - 10%オフの点がユーザーに評価されており、有料会員入会数が旧プランと同月のものよりも伸長しました。 - リリースから継続して利益を上げることができている状態です。 - 予約利用率(10%程度)という点も同月旧プランと比較して向上しました。 - プラン刷新によってバリュープラスを基軸にプロモーション等を実施する基盤が整いました。 - 現在はこのプランプロモーションを成長の武器として検討しています。 - 一部のレガシーコードのリファクタリングと、現状でも残っているレガシーコードの箇所把握ができました。 - この点については個人としてもそうですが、チーム内でも共通で認識できたことが良かったかと思います。 ## 振り返り ### 所感、良かった点 - ドメイン知識のドキュメント化__(個人としての実績、チームとしての実績)__ - 従来は属人化していた知識をNotionやOpen APIを用いて共有化するようにできました。 - 技術的負債の返済__(個人としての実績、チームとしての実績)__ - 技術的負債となっているYiiフレームワークAPIをLaravelへリファクタリングすることができました。 - 一部要件の提案__(個人としての実績)__ - 旧プランクーポンの乗り換え時一括配布については自身からPdMに提案し、採用して頂くことができました。 - チームのプロジェクト進行スタイルの確立__(チームとしての実績)__ - 従来は社員エンジニアがチームにおらず、チームとして大型プロジェクトを進行させるということが難しかったのですが、本プロジェクトを契機に社員・業務委託関係なく積極的に意見を交わすスタイルをチーム内に確立することができました。 - プロジェクトに取り組むにあたっては年次に関係なくお互いに頼ることを大切にする、信頼関係の構築できたと思います。 - 下記反省点で記述した部分についての反省を得ることができました。__(チームとしての実績)__ - 現在は反省点をどうすれば無くせたのかをブレストして、Next Actionとして実行することができています。 ### 反省点 - 短納期でのリリースによるユーザーへの不利益の発生 - リリースへの期間が短く、バグによってユーザーにとって不利益が出てしまったので、問題が発生し得ることを主張すべきだったと反省しています。 - 要件定義への巻き込み力の不足 - PdMへもっと懸念点や意見を上げるべきだったと思います。 - リリースを優先する場合は負債を積み上げ、後々の開発負担の増加になってしまう点をもっと主張するべきでした。 - テストに対する意識についても将来的に問題になる可能性がある箇所は、もっとはっきりとお伝えすべきだったと思っています。 ### 反省点から現在行えるようになったこと、組織に影響を与えられた点 プロジェクト終了後に下記を個人としてもチームとしても認識として持つようになりました。 - 要件定義でクリティカルな仕様については徹底的に意見を出し合う。 - リリースを優先して要件定義や仕様設計にあやふやな部分を残したままスタートしてしまった結果、トータルのDeliveryコストやエンジニアの消耗につながってしまいました。そこへの反省として__看過できない種類の仕様(予約・検索・決済関連)__については、徹底的に詰めてからプロジェクトを開始するように、チームとして意識して取り組めるようになりました。 - プロジェクトのDeliveryのみで判断せず、将来的なコストやリリース保守性を保つようにする。 - 短期的リリースコストの削減に目が向きすぎて、結果的に技術的負債が大きくなるというような形になる部分がありました。 - そのようなことを繰り返さないようにリファクタリングできる箇所がプロジェクトである場合は、それが__将来的なコスト削減につながる旨__をビジネスサイドにも伝えて、工数を割かせてもらえるように提案しています。 - 仕様に対する理解差を埋めるためのペアプロ・モブプロを導入 - 自身含めて、プロジェクトにおけるドメイン知識に対しては各メンバー毎にばらつきがありました。それに起因するPRレビューでの手戻りや、テストにおける正しい挙動に対する理解差が顕在化してしまいました。 - 上記を解決する手法としてペアプロを一部実装では行っており、効果があることを確認できました。 - 現在はペアプロ・モブプロをタスクの大小に応じて、場合によっては仕様設計の段階から導入するように提案し、実際に別プロジェクトでも効果を発揮できています。

## 背景 従来の既存のレビュー機能では取得速度が遅く、表示時間が掛かっておりUXを損ねていました。 またレビューを通じユーザーの体験向上をチームの戦略の一つにしたいと考えており、そのための第一歩として既存レビュー機能改善を行いました。 ## 問題点 - SQLにおいて速度面が考慮されていませんでした。 - そのためレビュー投稿が今後増大した際に、ボトルネックになる可能性がありました。 - レビュー登録導線が駐車場詳細画面にしか存在せず、会社側から利用した予約に対するレビューへの誘導はメールのみという状態でした。 - そのため予約した直後はユーザーもレビュー記述の意識を持ってもらえたが、時間と共に忘れられてしまうことが多かったです。 ## メンバー - バックエンド 1名(自身) - デザイナー 1名 - iOS、Androidエンジニア 1名(外部委託) ## 対応 - SQLの初歩的ではあるが確実に速度改善に繋がる対応を実施 - 結合をinner joinへの変更、使用用途の少ないテーブル結合の解消を行いました。 - レビュー導線をトップページにも追加。 - ユーザーが該当の駐車場に対してレビューをしているかの判定を行い、くどくならない範囲でユーザーのレビュー登録への誘導を導線を追加しました。 ## 振り返り ### バリュー - レビュー投稿へページトップから遷移できるようにしたためか、投稿率が若干ではあるが向上しました。(従来比5%程度) - 率としては低いが今後の施策の布石となるタスクという位置付けのため、少しでも投稿率が向上したのは副次的な成果としては十分であるという評価になりました。 ### 個人としての体感 - ユーザーの体験向上プロジェクトとして初タスクだったので、モチベーションを高く持って取り組むことができました。 - 複雑なドメインの絡み合いが多く、プロジェクト初期は苦戦した部分もあったが、知見の向上と同時に自分からも理由を含めて改善提案をすることもできて達成感の大きいプロジェクトになりました。 - 会社にジョインして最初の改善案件でもあったので、なるべく自分一人で抱え込まないように、先輩エンジニアに積極的にドメイン知識の質問や相談をするようにコミュニケーションの部分でも心掛けるようにしました。 - 現在でも上記のことは心掛けるようにしています。

## プロジェクト概要 ### 参画期間 - 2022年4月〜現在 ### 目的 - 素材メーカーの工場現場での工程管理が複雑化しており、Excel等では管理に限界があるためシステム化による業務負荷軽減を目的とする。 - 案件自体はPhase1、Phase2の二段階に分かれておりほぼ連続して案件が進捗しました。そのため細かく見れば2案件分となります。 ### チーム構成と担当した役割 - 会社は2次請けとして案件に参画(受託開発)。当社のチーム構成は現在、私含め6名(うち1名はPM)となっています。 - 自身の担当した役割はいくつかの個別画面の詳細設計、コーディング、テスト作成および実施となります。 ### 使用技術、開発環境 - C#、JavaScript、asp.net WebForms、jQueryを使用しての開発となります。 - ソース管理はSVNになります。 ## 取り組んだ課題 - 一時請け取引先に要件定義や仕様を決める時間的余裕が少なかったため、当社での開発段階でも仕様変更が頻発しました。そのため当社側からも積極的に意見を上げて随時仕様を確認する必要があり、取引先が詰めきれていない細かい仕様についても、確認できるよう意識して業務に取り組むようにしました。 - 前職で工場現場に出入りすることも多かったため、現場作業者がどのような点をUI、UXとして気にするかを考慮して意見をするように心掛けました。(細かい機能よりもボタンの大きさ、分かりやすさが好まれる等) - 私よりも後にスポット的にアサインされるメンバーもいましたので、自分自身が経験した困ったことの解決方法などを伝えるようにしました。本件ではスポットになるとはいえ、会社やチームの今後の戦力向上に繋がると考えて積極的に声掛けをするように意識しています。 ## 技術的なアプローチ - web forms、jQuery等の置き換えが進んでいく可能性がある技術を使っているため後日、置き換えを行う必要が生じた際に変更コストを減らせるように意識しました。将来的なUIフレームワーク導入の可能性も考慮して、jQueryを使用せずにJavaScriptを実装などを行うようにしました。 - C#フレームワークの置き換えについてはBlazorの採用可能性があるためBlazorの学習も並行して、置き換え時にどのようにすれば良いかを考えながら実装をしました。 ## 取り組みの成果 - 上記のアプローチによって顧客への置き換え案件の提案に繋げることができました。現段階での技術的コストがどのくらい減らせるか等を具体的に提案できるようになっています。 - 本プロジェクトではテストコードを使用していませんが、将来的なフレームワーク置き換え時に自動テストを導入するメリットをチームに提案して、テストの自動化を改善案として受け入れてもらうことができました。チームにとっても自身にとっても改善のために自発的に動くことができました。 - SVNでの管理によるコードレビューの難しさ、ファイルロックに伴う開発速度の遅延についても上長と意見を交わし、次回以降のプロジェクトでのGitへの移行を担当することになりました。本案件でも部分的にテストとしてGit管理を行ったところレビューの行いやすさが向上し、チーム内コミュニケーションの活発化に寄与できました。