自己紹介
こんにちは！AnyMind GroupでProject Managerをやっている奈良です。主に社内システムの導入・開発プロジェクトに従事しています。バンコクオフィスで勤務しており、タイ3年目です。
今回の記事では、社内の開発プロジェクトの事例として、HubSpotとNetSuiteのインテグレーションプロジェクトについて紹介したいと思います。
HubSpotとNetSuiteのインテグレーションとは
このプロジェクトは、業務効率化と精度向上を目的としてスタートしました。具体的にはAnyMind全体で採用しているSFA(営業支援システム)である”HubSpot”と、会計システムである”NetSuite”を統合することで、この目的を達成するものです。
これらのシステムは以下の様な関係性を持っています。HubSpotはSFAツールとして、セールスチームのパイプラインを管理しています。イメージとしては、セールスチームが与件を獲得したら、HubSpotに入力していきます。対してNetSuiteは会計システムとして、会社の会計処理を担っています。
この二つのシステムを跨ぐフローとして、クライアントと合意が取れたら顧客情報・取引のデータをNetSuiteに入力する業務があります。この作業は今までファイナンスやセールスアドミンによって入力されていました。しかし、組織が拡大するに比例して対応量が増えて行ったのと、伝達ミスによる誤入力・修正などが発生しているという問題がありました。そういった背景から社内の要望として、HubSpotとNetSuiteを上手い具合にデータ連携したい…というリクエストが強まっていきました。
こうした理由を踏まえて、このプロジェクトはスタートしました。
要件定義編
HubSpotとNetSuiteを繋ぐというざっくりした構想を元に、要件定義から取り掛かりました。私はTechチーム所属なので当然セールスアドミン・ファイナンス業務に関しては全く知見がなく、ファイナンスチームから社内業務を把握しているメンバーを要件定義担当としてアサインしてもらい、まさに二人三脚で要件定義を開始しました。
このプロジェクトにおける要件定義の肝は、各国で行われている現行業務をいかに吸い上げて、いかにシンプルなフローとしてまとめることが出来るかでした。例えば、NetSuiteに情報を入力するという1つのオペレーションを取っても、国によってタイミングだったり入力する役割の人が異なる事があります。そういった事象はオペレーションを統一出来ていないというより、各国によって異なる人員配置や業務量、何より国によるファイナンスのルール・ビジネス慣習の違いによるもの、という場合が多いです。
例えばセールスアドミンの有無が大きな違いの分かれ目となってきます。 アドミンがいる場合はファイナンス・アドミンで完結する事が出来ますが、不在の場合は承認工程だけセールスヘッドに依頼するなどアドホックな調整が必要でした。またとある国では契約書より前に確認書を送る商習慣があったのですが、そこはNetSuiteとの関連付けは不要なので、システム連携いらないねという判断もありました。 そういった各国の背景を汲み取る必要があるのが、このプロジェクトの難しいところだったりします。
各国の業務オペレーション・業務フローについてある程度情報が集まってから、連携イメージを持ちやすくするため、ワークフロー図を作成しました。このプロジェクトは全拠点のセールス・ファイナンスに関係があるものになるので、関係者やヒアリングをするべき人も多数存在するものとなっていました。ヒアリングをするにしても、そこに至るまでの説明をする時間も相当かかってきます。そこで、ワークフロー図を作成する事で事前説明の時間の効率化を図ることにしました。この様に要件定義の段階で図式化しておくことは、後の説明にも役立ったり、プロジェクトメンバーの理解の整理にも大きな助けとなりました。
このような工程を経て大枠のフローが出来たら、次はHubSpotのNetSuiteのプロパティのマッピングを行いました。両システムは概念として似たようなデータ構造を持っていますが、あくまで別のシステム同士なので、必要な項目に関して対応表を作成する必要があります。特に業界や支払いタームといった属性値の対応表作成はなかなか膨大になりました。幸いHubSpotもNetSuiteも柔軟に新規プロパティを作成する事ができたので、足りない項目があった場合は作成して対応する事が出来ました。
そして要件定義パートの最後の重要なポイントとして、金額の根拠がこの連携において明確である事・そして意図していない数字にならないことという点がありました。特にNetSuiteは会計システムなので、入力される数値は正確である事が求められます。ここでは、こちらが予期せぬオペレーションをされないようにする・されたとしても影響がないように気をつける必要がありました。例えばNetSuiteにOrder(入力)のリクエストが送られるときに、複数回実行されても単一のものとして処理出来るようにしました。他にも、一つのDealから複数のOrderが作成されることがあってはいけないので、ID管理を徹底してそういった問題が起きないようにしました。要件定義の段階では入力経路を洗い出して、それぞれのパターンに対してどう対応するかを定義しました。
このようなポイントを特に気にかけつつ、要件定義を行なっていきました。
開発〜運用開始編
開発フェーズが始まってからは、小分けにチケットを切って開発を進めていきました。
開発を進める上で要件定義にて想定できていない箇所がいくつかありましたが、それらは事前調査をしっかり出来たこともあり大きな変更をせずに対応出来ました。
実装自体はスムーズに進めることが出来たので、実際のところこの開発フェーズにおいて一番工数をかけたのはテストを通した開発物の確認でした。テストでは要件定義で想定したパターンが想定通りに動くのかの確認はもちろんのこと、実際にテストを実施して見つかったポイントに対して対応策を練っていきました。
加えて要件定義でも考慮したような、想定していない運用を行った場合どうシステムが作用するのかを念入りにチェックを行いました。このチェックを通して、会計システム連携に求められるデータの正当性を担保していきました。
開発とテストが終わったらいよいよ運用に入っていきますが、AnyMindは拠点が多く今回のような多くのメンバーが関わるプロジェクト場合、一度に運用を始めるのはかなり難しいです。そこで、いくつかの拠点を選んで先行運用を行う、プレ運用という形をとりました。プレ運用のメリットは、対象者を絞ることでしっかりサポートを行えるのと、もし仮に問題や大きな追加変更が必要な事項が見つかったとしても、柔軟に対応する事が出来ます。また、ここで最後の念入りのチェックを行う事で、来たる全拠点での運用を開始する際の心配材料を極力減らすことも可能です。
プレ運用のフェーズに入ったら、最後の役割として問い合わせ対応といったサポートを行いました。あらかじめマニュアルだったり説明会を通して連携のやりかたやルールについてはある程度伝える事が出来ても、実際に手を動かしてもらうまでは分からないことは多々あります。
そのため、セールスやファイナンスメンバーに手を動かしてもらい、その上で発生したケースに関してはしっかりと検証するのが重要になります。それが考慮するべきケースなのか、それともシステムに合わせてもらう事で解決できるのかの判断していきます。こうした検証をプレ運用期間のうちに繰り返して、本番運用を始めた時に起きうるギャップを埋めていくのが非常に重要です。こういったプレ運用の期間を経て、本番運用にこぎつける事が出来ました。
まとめ
昨今DXが話題に上がることも多く、社内の業務をシステム化・自動化しようという事例は多くなっていくと思います。
AnyMindもその例に漏れずなのですが、複数の国に拠点があり関わるメンバーが多様であることから、難易度の高いミッションが多い環境だと思います。(ここまで言及していませんでしたが、ヒアリングや資料作成諸々は基本的に英語で行いました)
グローバルな環境での社内ITプロジェクトに挑戦してみたい方は、是非一緒に働きましょう！
グローバルな課題を技術力で解決していきたい方は、こちらのページから「Product Development」を選択して募集職種をご覧ください。
https://anymindgroup.com/career/
また、こちらはAnyMindのエンジニア達が書いているブログです。よろしければこちらもご覧ください。
