CRM移行プロジェクトの開発リードをした振り返り
はじめに
この記事はツクリンク プロダクト部 Advent Calendar 2023 21日目の記事です。もうそろそろクリスマスですね✨🎄✨
ご無沙汰しております。ツクリンク株式会社でソフトウェアエンジニアとして働いていますA作です。
昨年の夏から社内のCRM移行プロジェクトに開発のリードとして参画しており、今回はこのプロジェクトに携わってみて出来たことや次回に活かしたい反省点を振り返ってみようと思います。
何してたの？
社内で利用しているCRM（顧客管理システム）を別のSaaSへ移行して運用するために、移行元CRMの既存データを新CRMへ移行する機能と弊社システムのDBから新CRMへのAPI連携機能を実装する必要がありました。そして今回自分はその機能開発の責任者として要件定義、課題の起票、担当者への割り振り、開発スケジュールの管理などしていました。
現状
データの移行機能もAPI連携機能も実装は完了しています。データは移行が完了し、API連携機能もリリースされ新CRMへのAPI連携は稼働している状況です。ただ運用としては全ての業務を新CRM上で行い旧CRMから脱却することはできていない状況です。これには様々な要因がありますが、現状を踏まえて振り返ってみたいと思います。
今回上手くできたことはある？
先ず、必要な機能のヒアリングから要件定義・設計を行い、諸々の機能をリリースして本番環境で稼働させることが出来たことは評価できるのではと考えています。真っ白な状態から形にできたので一安心しています。
また、他部署へのヒアリングや開発の現状共有をする週次の定例を開催したことでプロジェクトが上手く進むようになったと感じています。定期的にコミュニケーションを取る場を確保したことで、常に変化する他部署の運用にも対応できましたし開発チームが今何に取り組んでるかも理解してもらうことが出来たと思っています。（個人的には、普段一緒に業務をしていない他部署の人達とコミュニケーションを取れたことでチームとしてまとまりが出たかなと感じています。）
上手く出来なかったことや次回以降に活かせるものはある？
とはいえ、開発リードのような役割を今まで担ったことがなく、任命されてからがむしゃらに進めてしまった感は否めないです。振り返ると反省の方が多いです。次回また同じような役割を担うことになるのであれば以下に書いたようなことは意識したいなと考えています。
関係各位の役割と責任を明確にする
今回のプロジェクトは社内の開発チームのリードとして参画したのですが、実際には新CRMのSaaSの開発を依頼している外部の会社の進捗管理や全体の運用スケジュール策定など機能開発とは関係ない部分の役割も担っていました。
プロジェクトが進行していくにつれて徐々にそれらの役割を担うようになっていったのですが、自分の役割と責任が明確であればもっと自覚を持って最初から動けていたと思うし、各人の役割や責任を他の人に委譲したり、欠けていた役割が追加されてもすぐに対応できたと考えています。
プロジェクトのゴールに到達しなくても運用開始できる
これは個人的には一番大事だと考えています。プロジェクトのゴール（ここまで出来れば終わり！）を明確にすることの必要性は言うまでもないかもしれませんが、ゴールは必ずしも運用開始できる地点とイコールにはならないと考えています。自分は開発中は0か1で物事を考えてしまっていて全て完了しないとリリース、運用開始できないと思っていました。ただ現状、リリースができても運用に乗っていない機能も少なからずあり。。。
今思い返すと、もっとユーザー（今回の場合CRM運用者である社内の営業部のメンバー）とコミュニケーションを取り、先行して運用開始できる機能はあるかヒアリングを行うべきだったと思います。それに基づいて開発タスクの分割と優先度付けを行えば、より早く運用開始しフィードバックを得て改善を重ねることもできたと考えています。
ドキュメントは無闇に作りすぎず、メンテナンスして大切に育てる
プロジェクトのキーワードでドキュメントを検索すると関連するものが無数に出てきます。しかしその多くはメンテナンスされていない古いものになっています。部外者や新規参画者がプロジェクトのことを理解する妨げにもなるし、作成者の自分でさえ古いドキュメントに騙されてることもあります。ドキュメントは必要最低限のもの以外は作成せず、それらをメンテナンスしていくようにするべきだと痛感してます。
持続可能な開発目標はやっぱり大事（SDGs！）
開発を進めていく中でスケジュールから遅れ気味になったとき、次スプリントで挽回しようとしたことがありました。スプリントに多めのタスクを設定して開発メンバーには遅くまで作業してもらいました。しかし1週間にさばけるタスクには限界があり、キャパシティを超えた作業量は将来に影響します。（自分のチームではハードワーク後に体調不良者が続出する時期がありました。。。）そして何より今回は開発以外の要因でリリースや運用開始が後ろ倒しになり徒労に終わってしまいました。
定められたスケジュールの中でタスクを終わらせることは大切です。ただ、そのスケジュールは根拠のあるものか、妥当なものか、を見極め、優先度を設定し、持続可能な作業量を考慮して現実的なスケジューリングすることが重要だと思いました。非現実的なスケジュールの場合、優先度の低いタスクを削り落とすか、期限を延ばす外に方法はないように思います。
最後に
色々と書き連ねましたが見返すと当たり前のことかもしれませんね。。。とはいえ初めてこのような役割を担ってみて学ぶことは多かったと実感しております。また次回同じような機会があったら今回の経験を活かしたいと考えてます。
最後まで読んでいただきありがとうございます。明日以降も記事が投稿される予定なので是非読んでみてください。メリークリスマス！ミスターローレンス！🎅