家志隆平

【プロジェクト概要】 SQL を使用して今までは見える化されていなかったデータを提供し、営業フローの改善・パフォーマンス評価、しいては企業の決算向上につなげる。 【担当業務】 - Redash と会社の基礎データを組み合わせて分析データを作成。 - 複雑な仕様を考慮して最も正確に数値が出せるクエリを実装。 - 作った分析ボードは以下。 - 営業フロー分析ボード - 架電分析ボード - 営業パフォーマンス分析ボード 【発揮したバリュー】 | Issue | Solution | | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | データの入力ルールが特にないところから正確な営業数字を取得する必要があった。 | ある程度まで精度高く分析できるように、営業の方のオペレーションを聞きながら信頼していいデータを決め切って、実装した。 | | 分析データの取得にはかなり複雑なクエリを書く必要があるが、当時は数行程度のクエリしか書いた事がなかった。 | 上司のクエリを見ながら 2 週間程度でサブクエリやインデックスや実行計画について学び、**100 - 200** 行程度のクエリをいくつか実装、最長で **500 - 600** 行のクエリを実装した。 | | 当時は分析データを使ってみないと「何が必要なデータなのか」がわからなかったため、後から追加案件がくる事が予想された。 | SQL も単一責任を意識して後から修正や新たなカラム追加があっても作り直さなくていいように設計・実装した。 | | データ入力が営業の方それぞれによって異なるためどれが正しい入力なのかの判断が付きづらい中で実装する必要があった。 | 数値の正確さを保証するために社内で「信頼できる情報」を探し、小さく検証しながら実装した。具体的には、「最も売上をあげている方」や「長年働いている方」が信頼できるデータであると考えた。 |

【プロジェクト概要】 不動産会社の CRM や物件管理・賃貸管理システムの開発。 【担当業務】 - 営業フェーズに関するステータスをリード顧客に付与するバッチを作成。 - 複数ユーザーによって同時に変更処理が行われても問題が起きないように排他制御を実装。 - Marketo とリアルタイムで顧客ステータスを連携。 - ORM では取れない複雑なリストを SQL を使用して取得。(サブクエリを使った処理など) - DB 設計を見直してテーブル結合を減らしたことで、クエリを高速化。 - 営業するためのリード顧客リスト画面の開発をフロントからバックまで一気通貫で担当。 【発揮したバリュー】 | Issue | Solution | | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 過去に商談に繋がらなかったリード顧客を抜け漏れなく、システマティックに掘り起こす方法がなかった。 | このプロジェクトが決まった期から企業はセールスフォースの営業戦略を採用するようになり、営業フェーズに応じてステータスを付与するのは企業の営業戦略を実現するための最重要課題であった。これを **1 ヶ月**という短期間で要件定義〜実装までやりきった事で、リード顧客のうち **33%** にしか営業できていなかったのが **95%** まで改善し、月の契約数が **3%** 上昇した。 | | 複数の営業の方が同時にデータを操作する事があるためデータ整合性を保つ仕組みが必要であった。 | 排他制御の方法はいくつか存在するが、業務内容を想定して解決法を選択し実装した。具体的には、上司からアドバイスもいただきながら検討し、最終的には楽観ロックを採用した。(排他制御の選択肢： 楽観ロック、悲観ロック、リトライ) | | Marketo を使用してマーケチームと営業フェーズステータスを共有するが、Marketo 側の Webhook が 2 回連続でトリガーされるなどのバグが発生した。 | 外部サービスとの通信時に「防御的プログラミング」を意識して API 側のバグが出た時にも業務が止まらないようにエラーハンドリングをした。 | | リード顧客リスト画面の表示が遅くて業務効率が悪かった。 | テーブルのカラムを移動させたりキャッシュを用いることで画面の表示時間を約 **1000ms** 速めた。 | | 営業戦略の実行はすぐに始まり、システムができ次第すぐに使用を始めると言われていた事から、速度と品質の両方を求められた。 | テストカバレッジを意識してパブリックインターフェースの単体テストは欠かさず、統合テストに関しても業務が止まれば企業にとって「致命傷」になる箇所を選別して実装した。(速度と品質のバランスを考慮) | | エンジニアチームは 5 名しか在籍しておらず、上司も他の案件と同時並行で進めていたため手厚く一つの案件だけを見る事はできなかった。 | テーブル設計・要件定義〜実際の開発まで自分が中心になってやり遂げた。 |