はじめに
「kintoneの開発だけお願いしたいです」
最初は、そう聞いていた。
既存の「基幹業務アプリ」を、新しい「顧客管理アプリ」「案件管理アプリ」へリプレイスする案件。
さらに、外部システムとの連携もある。
僕は、kintone側の実装担当として参画した。
話としては、
- 要件定義は済んでいる
- 必要な内容は整理済み
- あとは実装中心
という前提だった。
しかし、実際に案件へ入ってみると、そこにあったのは「完成した要件定義」ではなく、
“まだ誰も全体像を整理できていないプロジェクト”
だった。
今回は、この案件で実際に起きていたことを通して、
- PM不在案件で何が起きるのか
- 要件定義不足が現場へどう影響するのか
- データ移行を軽視すると何が起きるのか
について、実体験ベースで書いてみたい。
「要件定義済み」のはずだった
最初に共有された資料には、
- 必要そうなアプリ
- 必要そうなフィールド
- 実現したい内容
は書かれていた。
しかし、実際には、
- 現行アプリとの差分整理
- 外部システム連携仕様
- 主キー設計
- データ移行ルール
- 責任分界
- 運用フロー
などの重要な部分が整理されていなかった。
つまり、「やりたいこと」は存在していたが、
“どう成立させるか”
が定義されていなかった。
そして、この状態のままプロジェクトは進み始めた。
タスクも指示も「空中戦」のまま
プロジェクトにおいて驚いたのは、明確な指示も、進捗を管理するためのタスク（チケット）も一切作られなかったことだ。
本来、これほど複雑なデータ移行やシステム連携が絡むなら、一つひとつのタスクを切り出し、誰が、いつまでに、何を行うかを可視化しなければならない。
しかし、そこにあったのは「なんとなく話が進んでいる」という空気感だけだった。
結局、僕は開発担当でありながら、自らBacklogを立ち上げ、散らばった情報を拾い集めてチケット化し、リスクを可視化する作業から始めざるを得なかった。
指示を待っていれば、プロジェクトは1ミリも前に進まない。
そんな状況だった。
フィールドを確認し始めて気づいた違和感
僕はまず、既存アプリと、新アプリ設計を見比べ始めた。
すると、すぐに違和感が出てきた。
例えば、
- 現行アプリに存在する項目が新アプリにない
- 外部システム連携に必要なフィールドが存在しない
- フィールド名は同じでも用途が違う
- データ型が合っていない
- 必須条件が整理されていない
など。
さらに問題だったのが、「顧客管理」の概念だった。
元々の運用では、顧客マスタが存在していなかった。
つまり、
- 顧客IDがない
- 顧客を一意に識別できない
- メールアドレス頼み
- 同一人物判定が曖昧
という状態だった。
データ移行では、この“ID設計”が極めて重要になる。
しかし、この時点ではまだ、そこまで深く認識されていなかったように感じた。
PM不在案件で起きること
この案件で一番大きかった問題は、「誰も全体責任を持っていない」ことだった。
もちろん、個々の担当者は動いている。
しかし、
- 誰が最終判断するのか
- どの順番で進めるのか
- 何を優先するのか
- どこまでを今回やるのか
が曖昧だった。
すると、何が起きるか。
現場の技術者が、自然と“PM役”をやり始める。
例えば僕は、
- フィールド差分確認
- 外部システム連携の仕様確認
- タスク分離
- Backlog起票
- 実装可否確認
- 外部システム連携の技術的確認
などを行うようになっていた。
本来、僕は「開発担当」として入っていたはずだった。
しかし気づけば、
「このままだと危ない」
を検知する役になっていた。
「顧客ID」が消えた瞬間
この案件で象徴的だったのが、「顧客ID」の扱いだった。
最初に共有されていた資料には、顧客ID項目は存在していた。
つまり、本来は、
- 顧客ID
- ログインID
- メールアドレス
は別概念として扱われる前提だったはずだ。
しかし、プロジェクトが進むにつれて、いつの間にか、
「ログインID（メールアドレス）＝顧客ID」
という認識に置き換わっていた。
明確に誰かが決めたわけではない。
ただ、会話や運用イメージの中で、徐々にそうなっていった。
しかしこれは、データ移行やシステム連携では非常に危険だった。
メールアドレスは、
- 変更される
- 家族共有される
- 同一人物で複数存在する
- 空欄がある
など、“識別子として不安定”だからだ。
一方、顧客IDは本来、
「システム内で顧客を一意に識別するためのキー」
として存在する。
つまり、
- ログインID
- 連絡先
- 顧客識別子
は、本来別管理すべきものだった。
しかし、全体設計を整理する人が不在だったことで、
“概念そのもの”
が徐々に崩れていった。
そして僕は、
「メールアドレスを主キー扱いすると危険ではないか」
と確認することになった。
一番危険だったのはデータ移行
特に危険だったのが、データ移行フェーズだった。
今回の移行は、単純なCSVインポートではない。
- 複数システム間
- 旧アプリ → 新アプリ
- 顧客データ
- 案件データ
- 見積データ
- 注文データ
- 添付ファイル
- コメント
- 外部システム連携
などが絡む。
つまり、
“全部つながっている”
状態だった。
しかも、
- 名寄せルール未確定
- クレンジング基準未確定
- マッピング変更発生
- 仕様変更継続
- テストデータ変化
という状況。
データ移行は、「最後にやる作業」に見えやすい。
しかし実際には、かなり早い段階から設計しておかないと危険だ。
なぜなら、
“運用設計そのもの”
が出るから。
「やるしかない」は危険な言葉
案件中、何度も出てきた言葉がある。
「やるしかない」
確かに、現場では必要な場面もある。
しかし、この言葉は時々、
“未整理のリスクを現場へ押し込む言葉”
にもなる。
例えば、
- スケジュール未整理
- 責任未定義
- 手順未確定
- データ未確認
でも、
「なんとか進める」
になってしまう。
すると最終的に、負荷は現場へ集中する。
特に、
「問題に気づいてしまう人」
ほど負荷を抱えやすい。
それでも、整理は必要だった
僕は途中から、
- 移行手順書
- クレンジングルール
- マッピング整理
- 作業ディレクトリ整理
- チケット化
- リスク共有
などを進めていた。
これは、「完璧にしたかった」わけではない。
最低限、
“何をやっているのか分かる状態”
にしたかった。
データ移行は、勢いでやると事故が起きる。
特に、
- 誰が
- 何を
- どの順番で
- どのデータを
- どこへ入れるか
が曖昧なまま進むと、後から復旧できなくなる。
だからこそ、整理が必要だった。
最後に
今回の案件で強く感じたのは、
「PMがいるかどうか」
よりも、
“誰が全体を見るのか”
が重要だということだった。
特に、
- ローコード
- SaaS連携
- データ移行
- 外部システム連携
が絡む案件では、
「なんとなく進める」
が一番危険になる。
開発だけなら、後で修正できることも多い。
しかし、データ移行や運用設計は、後戻りコストが大きい。
だからこそ、
- 要件整理
- 責任整理
- 優先順位整理
- 手順整理
は、本当に大事だと思う。
今回の経験はかなり大変だったが、同時に、
「プロジェクトが崩れる時、現場では何が起きるのか」
を、かなりリアルに学んだ案件でもあった。
補足
ローコードだから簡単になるのではなく、
「設計を曖昧にしたままでも動いてしまう」
からこそ、むしろ全体設計が重要になる。
今回の案件は、それを強く実感した経験だった。