こんにちは。freeeでDevBrandingチームに参加していたり、採用管理システムを作っている@noblejasperです。
今回組織変更をする社内アプリを開発して夢が広がってワクワクしている話と、Salesforceパッケージ開発して気づいた課題の話をさせて下さい。
本日から1週間 freee Developers Blog Week 開催
本日からfreee Developers Blog Weekと題してたくさんの記事をお届けさせていただきます。多くの方にfreeeの開発者の事を知っていただき、なにかのお役に立てればとても嬉しいです。freee Developers Blog Weekにかける想いや詳しい説明は下記の記事に詳しく書いてあるのでも気になる方はこちらもどうぞ。
freee Developers Blog Weekのようなイベントを不定期ではありますが継続的に開催し、freeeの開発の事をアウトプットしていく機会を作っていこうと思っています。
明日からの記事はきっと私の記事よりも読み応えがあって面白いはずなので、是非読んでいただけたらとても嬉しいです。
”組織変更”のためのSalesforceアプリ開発
今回私が取り組んだ開発は社内で定期的に行われる「組織変更」をスムーズに行える機能開発の話です。「組織変更」と言われてもピンとこない方も多いと思います。私も着手以前はそもそも誰がどんな作業をするのか知りませんでした。
freeeでは、3ヶ月に1度組織内の配属やチームの粒度、名称の変更などを行います。（3ヶ月の中で適宜行われることもあります。） 従業員にとって最適な配属や、事業の成長や変化に合わせて組織を最適化させていく作業です。
freeeの今までの社内フローとしては下記のような手順で進められていました。
- 各組織のオーナーが組織の構成を決める
- 各組織間をまたぐ異動者の配属をあわせて決める
- 1つのスプレッドシートに記入する
- 労務チームなど確認者がおかしな点がないかどうかチェックする
- 社内共有用の組織図や名簿を作成する
- 各種反映が必要なシステムに転記する
人数もチーム数も小規模だった時には、この運用で充分でした。専用のシステムを使う必要はなかったと私も思います。
会社規模拡大により、組織変更が重労働に・・・・
会社の成長と共に人数が増えチーム数も増えた現在では、組織変更の作業に多くの課題が発生していました。
- 毎回組織図や名簿を作るのに膨大な時間がかかる
- 組織図、名簿作成ともにミスが発生しやすく修正が発生する
- 各種システムへの転記もミスが発生しやすい
- 上の作業にそれぞれ時間がかかるため、各種システムへの反映が遅くなる
社外製のSaasツールなどを活用してみたり、スプレッドシートで効率化が出来ないかなど、試行錯誤を行っていましたが、なかなかうまくいきませんでした。
今回私が開発したツールで組織変更を実施する所まで進められました。どのように開発したのか、今後の展望と合わせて紹介させてください。
単体アプリケーションとして開発してみる
私はSalesforceエンジニアとして社内システム開発を行っています。今回もSalesforce上で開発を行いました。
今回私は組織変更を行うアプリケーションに「組織変更クリエイター」という名前を付けました。「組織変更クリエイター」はパッケージ開発モデルという開発手法で、Salesforce上で動作する単体のアプリケーションとして開発しました。パッケージ開発についてはSalesforce自体のヘルプに詳しく説明されていますので、興味がある方はそちらをご覧ください。
パッケージ開発を選択したのにはいくつか理由がありますが、主な理由としては開発したアプリケーション自体のSingle Source Of Truth (SSOT)を本番環境ではなくGitHubにしたかった為です。SSOTに関しての考え方はtalendのこちらの記事が詳しいので気になった方はご参照下さい。
本番環境のSalesforce上で開発を行ってしまう（詳細は省きますが、変更セットを用いた開発フローの事を指しています）と、SSOTがVCSではなく本番環境になってしまいます。Gitのmainブランチではなく本番環境が正になってしまいます。Salesforceの構造上仕方のない事ではあるのですが、最近ではSalesforce社から「Salesforce Developer Experience（SFDX）」という開発手法が提案されており、回避出来る方法が存在します。厳密な説明ではないですがそれがパッケージ開発です。
本番環境の全てをパッケージ化する手段も存在します。しかし多くの独自機能や設定が含まれている本番環境をパッケージ化するのは容易ではありません。とても時間がかかります。開発に携わるメンバーのキャッチアップも必要です。将来的には本番環境もパッケージ化に近い形で管理したいと考えています。しかし現時点ではまだ出来ていない状況です。パッケージ化されていない現在も日々開発は行われているため、本番環境は常に肥大化しています。
そのため本番環境に存在する既存機能と疎結合に出来る新規開発だけでもパッケージ化した形で開発したいと考えました。そのためには本番環境で直接開発を行うのではなく単体で開発を行い、パッケージングされたアプリケーションを本番環境にインストールするという手段を今回は採用しました。
これによって、開発したアプリケーションに含まれる全てがコードで管理され、SSOTをGitHubにすることができます。さらにCI/CDの恩恵を受けることが容易になり開発速度や品質も上げやすくなります。Webエンジニアである私にとっては馴染みのある環境で開発が出来るのでとても快適です。
しかしやってみて分かった大変な所やデメリットもあります。
パッケージ開発の課題/デメリット
今回新機能をパッケージ開発した事でデメリットや手間がかかる所も見えてきました。
現状分かっている課題、デメリットは以下です。
- Salesforce Administrator 担当者との協業がしづらい
- 手戻りでの修正がとても大変
- 本番環境との共存が大変
弊社独自な部分もありますが、本番環境のSFDX化（パッケージ化）が出来ていない組織だと発生しうる課題、デメリットだと感じています。簡単に内容を補足します。
Salesforce Administrator 担当者との協業がしづらい
Salesforce Administrator 担当者（以下Admin）は開発経験者ではないことがあります。そういった場合にシェルからコマンドを実行したり、GitHubの操作をするのは導入障壁が高い事があります。新たにキャッチアップしてもらうようには出来るかもしれませんが本来の業務に加え（大体Adminの方は多くのタスクを抱えている）、更に作業を増やす事になってしまいます。
Adminの方に依頼出来ない分、本番環境上で開発する方法に比べて開発者の手順や作業が多くなってしまいます。Adminの方にどれぐらい作業をお願いしているのかはチームによってまちまちだとは思いますが、いつも分業している作業を分業できなくなるのは思いの外大変だったりします。普段Adminの方が把握されている部分の知見が足りないため、不具合やミスも出やすくなってしまいます。
この課題の解決策としては、開発環境をAdminの方にも簡単に作成でき開発を行ってもらう方法を模索しています。自動デプロイなどの環境を整備し、GitHubを直接触らずに開発出来る環境を作りたいと思っています。
手戻りでの修正がとても大変
どんな開発でもそうなのですが手戻りでの修正が特に大変です。本番環境上で開発する場合に比べてパッケージ開発独自の手順がいくつも増えるためです。
具体的には、
- 開発環境の作成、コードの適用、サンプルデータの適用
- 開発後のパッケージング、公開作業
- パッケージのアップデートのテスト
- パッケージのインストールに関連する依存関係の確認と対応
などが必要になります。1つ1つの詳細な説明は割愛しますが、パッケージ開発特有の処理や手順などが存在します。
この課題の解決策としては、開発環境の作成からパッケージング、公開作業部分はCI/CDで自動化していきたいと考えています。アップデートのテストや依存関係の確認と対応に関してはまだ何も思いついていませんが、今後向き合っていく必要が出てくると認識しています。
本番環境との共存が大変
上のほうで疎結合と書きましたが、疎結合でも結合はしています。少しだけでもつながっている部分があります。パッケージ化したアプリケーションの導入では、Sandbox環境と呼ばれる「本番環境をコピーした開発環境」にインストールし、結合部分の動作確認やテストを行います。
情けない話ですが、私はとりあえず手を動かすのが好きで、事前に設計をしっかり作るのが苦手です。そのためSandboxでのテスト時に設計の不備から多くの手戻りが発生しました。前述の通り、手戻りには手間がかかります。自分の計画性のなさをとても悔いました。
この課題の解決策としては、アプリケーション開発時には結合部分の設計は丁寧に事前にやらなければいけなかったと反省しています。今後はチームのメンバーにも助けてもらって、不備が出づらいレベルまで設計してから取り組もうと考えています。
とはいえパッケージ開発は面白いので、チャレンジする価値あり！
まだまだ課題は山積みですが、パッケージ開発は面白いです。今回複数の機能が必要で、実際の業務に直接必要なパッケージ開発を行ってみましたが、アプリケーション自体の開発はとてもスムーズで快適でした。是非Salesforce開発者の方はチャレンジしてみてほしいと思います。そして知見を私にこっそり教えてくださいｗ
面白かったポイントはこんな感じです
- たくさんのノイズがある本番環境で作業しなくていい
- GitHubベースで開発出来るのは開放感がある
- CI/CDの恩恵に夢を感じれる
- 既存環境の状況に囚われづらい
組織変更クリエイターは4月デビュー
パッケージ開発の話が長くなりましたが、「組織変更クリエイター」の話に戻ります。組織変更クリエイターは簡単に説明すると、以下のようなアプリケーションです。
- 現組織からデータをコピーしてくる
- 次の組織変更後の配属やチームを作成、編集出来る
- 作成中の組織の名簿や組織図を表示、エクスポート出来る
- 現組織に対して組織を反映出来る
4月にある組織変更に向けて今まさに各オーナーが組織をポチポチ変更してくれています。今回初の利用なので戸惑いも伺えますが問題なく（多少の問題はありつつも）使っていただけているようです。
組織変更から繋がるバックオフィス業務の夢
組織変更クリエイターを開発しながらニヤニヤと妄想していた夢があります。それは高速統合型組織情報です。名前はダサいですが、今回の組織変更クリエイターが軌道に乗ることで広がる構想です。
組織変更クリエイターによって組織変更当日に従業員と組織の最新データがシステムに反映される事で、多くの社内システムに革新が作れます。
- 会計freeeと連携することで申請、承認などのワークフローの元になる組織情報
- 人事労務freeeと連携することで勤怠承認などの元になる組織情報
- 社内の評価システムの元になる評価者の設定
- 社内アカウント管理用データベースの設定
これらの情報や設定が常に正しい情報で即時反映される世界。何か作業をする時に「あれ？この情報古くない？」と確認する必要のない世界。夢が広がります。
まだまだ予測しきれていませんが、組織と従業員に紐づくマスターデータが一元管理され即時反映される事で得られるメリットは計り知れないと考えています。
高効率で、高精度なfreeeのバックオフィスを構築することでfreeeに関わる全ての人達が大きなインパクトや成果を出せるようになるはず。この構想の続きをまたBlogで報告させて頂けるように開発していきます。
