こんにちは！ ニーリーアドベントカレンダー11日目を担当するPDBiz開発グループの古庄(@k_furusho)です。
私は10月16日にニーリーへ入社し、「PDBiz（Park Direct for Business）」開発グループにジョインしました。 このPDBiz、社内では主力事業であるPark Directに続く「第二の矢」として、強烈な事業成長が期待されているフェーズにあります。
今回は、入社から短期間で「法人車両の月極駐車場管理」というドメイン業務の解像度を一気に高め、システム戦略を描くために実践したアプローチについてお話しします。
コードの外側に広がる「複雑性」
まず、PDBizというプロダクトの特性について触れておきます。 私たちは「法人車両の月極駐車場管理」というソリューションを提供していますが、その裏側には、システムと複数のコンテキストが密接に絡み合った巨大なオペレーションが存在しています。
現状、コードベースで表現されているのは氷山の一角です。その周囲には以下のような複雑なエコシステムが存在し、その上で業務フローが形成されています。
- JIRA、GAS、Amazon Connectなどの複数ツール
- 形式化されていない多種多様なフォーマットの書類
- 熟練オペレーターの属人的な業務判断
入社してすぐに「これはコードや資料を読んでいても、クリティカルなボトルネックを正しく理解できないだろう」と直感しました。
Phase 1: 現場の解像度を上げる
そこでPDBizの開発に関わるエンジニア全員が、ビジネス職のOJTに参加し、「現場の業務そのもの」を経験することにしました。
エンジニアとして横で観察するのではなく、実際に管理会社に架電して駐車場の申し込み、社内の申請ワークフローを実行や、システムへのデータ登録業務を経験しました。
実際にやってみて感じた「ツラさ」
自ら手を動かすことで、システムの「隙間」にあるツラさを肌で感じることができました。
- 「なぜここで目視確認が必要なのか？」
- 管理会社ごとに異なる請求書フォーマットを目視で確認しており、システム的な正規化が行われていないため、心理的な負荷が高い。
- 「紙」の書類をPDFやJPG形式で格納していて、解像度もバラバラです。目を凝らして確認することが多く、何度も点眼しました...w
- 「正しい最新の状態・データはどこにある？」
- 複数のシステムを駆使して業務が成立しており、これらのシステム連携のために、様々なスプレッドシートで関数を駆使して整合性を保つ「ビジネスロジック」が分散して築かれている。
これらは単なる作業負荷ではなく、「運用でカバーすることの限界点」であり、ここを解消しなければ事業の成長スピードにブレーキがかかると確信しました。
Phase 2: オペレーションを構造化する
現場の業務経験を得た後は、それをエンジニアリングの課題として定義するフェーズです。 ここでは、MiroとRDRAを用いて「業務の流れの可視化」と「業務分析・構造化」を行いました。
Miroに全てを吐き出す
OJTで得た一次情報を、記憶が新鮮なうちにMiro上に書き出していきました。 「契約IDが発行されるロジック」「ステータスが遷移するタイミング」「裏で動いている隠れたGASの存在」、そして「時系列ごとのアクターの業務イベント」。
これらをチームメンバーと同期しながら書き出すことで、暗黙知となっていた業務フローを徹底的に可視化していきました。
RDRAで現状の「ビジネス」と「システム」の境界を明確にする
次に、可視化した情報をRDRA 3.0のフレームワークを用いて整理しました。 RDRAは「要件を構成する要素（アクター、業務、情報、状態、システム外部環境など）のリレーションを明らかにして要求分析をするためのフレームワークです。
RDRA3.0では、RDRAZeroOneツールというツールがリリースされていて、叩き台作成が圧倒的に快適になっています...!!!
この工程を通じて、「どこまでがシステムで、どこからが外部ツール（Jira等）で、どの状態モデルでビジネスルールが満たされているのか」という境界線が明瞭になりました。「要素間の不整合」を機械的にあぶり出せる点がRDRA3.0の大きなメリットだと感じています。
結果として、以下のような課題が明確になりました。
コンテキスト境界の不整合: 複数ツール間でのデータ定義が曖昧で、繋ぎ込み部分が暗黙的に運用されている箇所がある。
SSOT（Single Source of Truth）の不在: 最新情報がシステムに集約されておらず、複数媒体に重複登録が発生している。
ビジネスロジックの分散: 所謂ビジネスロジックがGASやスプレッドシートに分散している。
Phase 3: 分析から実行へ。走り出した改善プロジェクト
OJTによる現場理解と構造分析によって、漠然とした「オペレーション工数削減・データ精度向上」という課題は、具体的なエンジニアリング課題へと分解されました。 現在は、それぞれの特性に合わせたアプローチで、複数の改善対応が並行して走り出しています。
1. 「法人車両の月極駐車場管理 × BPO」という事業特性へのアプローチ
BPOという特性上、完全に人を介在させないことは難しいですが、認知負荷を下げることは可能です。 熟練オペレーターの「注意点」や「判断基準」を、システム上のバリデーションやステータス制御としてコード化していく設計を進めています。 業務全体を俯瞰してシステムに集約していくことで、将来的な AI×BPO としての新たな価値提供に繋げていきたいです。
2. データと業務フローへのアプローチ
データが複数のツール（Jira, GAS, Spreadsheet等）に分散し、SSOTが存在しないことで発生するデータ不整合に対しては、既存の複雑なデータ連携に引きずられないよう、腐敗防止層（Anti-Corruption Layer） を採用しました。 これにより、外部ツールの仕様変更や利用ツール自体の変更からドメインロジックを守りつつ、システム内を正しい状態に保つアプローチを画策しています。
まとめ：ニーリーのプロダクトエンジニアとしての在り方
入社から短期間で複雑な業務の解像度を上げ、具体的な改善プロジェクトを始動させることができたのは、「実業務の経験」と「エンジニア間での構造可視化・分析」のサイクルを高速に回せたからです。
ニーリーでは、プロダクトエンジニアが「PdM(プロダクトマネージャー)の人格」と「エンジニアの人格」の両方を担い、事業成長にコミットしています！
今回のアプローチはDiscovery フェーズとPlanningフェーズの事例でした！
明日のニーリーアドベントカレンダーもお楽しみに！
