プレスリリースが出ましたが、先週18日にScalebaseとSalesforceを繋ぐアプリケーションの「Scalebase Connect for Salesforce」をリリースしました。そして気が付けが2/19でアルプに入ってから丸1年経っていたので、振り返りを兼ねて開発日誌を書いていきます。プロダクトリリース後から開発を始めて、約半年間でなんとかリリースまでいけました。
半年前の9月頭に「Salesforce向けのアプリケーション開発を専任で進めてほしい」と言われ、SalesforceってアメリカのTwitter社の近くにあった会社ですよね？みたいな何もわかってない状況から始まりました。前職はAndroidアプリエンジニアとして働いていたので、AppExchangeというGooglePlayストアのようなものがあってそこに載せればいいのね。くらいの気持ちでスタートしました、が、正直めちゃくちゃ大変でした。精神的に滅入ることはない性格なのですが、自分だけではうまく進められない部分、ヒアリングしないとわからない部分、実装しないとわからない部分など不確定要素が多かったので、自分の感覚ではまだまだ経験不足だなあと思う開発でした。結果としては、まだまだ改善中ですが、営業でインパクトが大きかったり、Salesforceの社員からも「すごくいいデザインですね。みたことがない！」と言われるようなアプリケーションになったので開発チームの皆さんには本当に感謝です。
約半年間作っていたScalebase Connect for Salesforceについては、プレスリリースや代表の記事を見ていただくほうが概要を理解しやすいと思います。
注意: 記事中に何度もScalebase(スケールベース)とSalesforce(セールスフォース)が登場して読みにくいかもしれませんがお付き合い下さい。
やってたこと
- Salesforce向けアプリケーション開発の要件決め
- プロジェクトの進行管理
- 外部サービス向けAPIの開発
ざっくりと 3 : 1 : 6 くらいの割合で作業していました。今思うと 3 : 2 : 5 くらいでも良かったかもしれません。
開発振り返り
前回と同様に概算だけみるとコードを書いている量とスピードはそんなに変わってないです。9-10月は設計フェーズが多くあまりコードを書けていませんが、その後は正月以外はコード書いてました。
体感としては前の半年に比べてより要件やユースケースが複雑化していて、後は手を動かせばいいだけだよね！みたいな状況が少なく、忙しかったと言えそうです。また考えるフェーズや調整も増えてきてコード書きたいけどそれ以外もやらんといけないみたいな状況が増えました。念の為ですが、これはGitHubでみれる概算なので大した意味はありません。自分のファンクションポイントを確認する感覚に近いです。その意味で、まだまだ足りませんがベストを尽くし続けている状況です。
リリースまでの大まかな流れは以下でした。
- 設計(9月)
- 設計、API、アプリケーション仮実装(10 - 11月)
- セキュリティレビュー、要件の再定義(12月)
- 実装、パッケージ作成、テスト、リリース(1 - 2月)
また今回も未体験ゾーンばかりで学びが多く楽しめました。
- プロジェクトマネジメント
- 期待値コントロール、経過コミュニケーション、役割の分離
- Salesforceの世界
- 営業観点やTHE MODELなど実体験として知らないがビジネスとして大きい世界
- 管理パッケージ開発、SFDX、Salesforceのドメインモデル
- API開発
- 公開されうるAPIの設計方針とバージョニング
- APIドキュメントの重要性とメンテナンス
- 使用者からみたリクエスト・レスポンスモデリング
- Postmanを使ったより複雑なe2eテスト
これまでの感覚と大きく違ったのはAPI開発でした。モバイルアプリ開発には伝家の宝刀「強制アップデート」があるし、これまでのフロントとの開発は社内の会議で「じゃあこのように変更しましょう」と決めればどんな破壊的な変更でもリファクタという正義のもとにできましたが、アップデートの与奪を握られた外部サービスアプリケーション向けのAPIはそうはいかないというのが難しいポイントでした。気軽にAPIの更新をしたら客先のアプリがクラッシュしましたみたいな状況が生まれやすい世界にきてしまいました。今後もリリースが難しくなったりしないよう改善を続けていきます。
Salesforceプロジェクト
Scalebaseの営業提案の最中に一番大きく上がる声がCRMサービスとの連携、つまりSalesforceと連携したいということだと9月に聞きました。そのタイミングで作成しているScalebaseは契約、請求管理と顧客もありましたが、Salesforceとの連携によって更に強い基盤が生まれるという確信がありました。それを推し進めるべくスタートしたのがこのプロジェクトです。
チーム体制
バックエンドは僕、フロントに業務委託のメンバーが一人、デザイナーが一人からスタートしました。その後フロント二人、バックエンドも二人、デザイナーが一人、プロダクトオーナーが一人という体制で今日まで走り抜けました。後半はフロントに関しては業務委託＋バックエンド一人も入るような形でフロントの開発が足りないような状況が生まれたので、開発の進め方など改善点だらけでした。ですが、いいものを作れたという点ではこのチームでよかったと思っています。
アプリケーションの全体構成決め
ユーザーストーリーマッピング、概念図、ドメインオブジェクトの対応表をまず作成しました。ここはScalebaseのときと同じく、スピード感とチームの共通認識をざっくりと合わせるために有効でした。
振り返るとScalebaseの進化に合わせてドメインオブジェクトの対応はもっと綿密にやっておいても良かったかもしれないです。
APIデザイン
これまで自分ではScalebase向けのinternalなAPIしか作成した経験しかなかったので、基本的な考え方や設計についてまずは調べました。オライリーのこの本は持っている、読んでいる人も多いので最初の一冊として選びました。
これを読みつつ、僕らが今から作るならどんなAPIがいいだろうかということを考えました。GitHubのこのRepositoryを見るだけでも世の中には数え切れないくらいAPIがあって、正しい設計というのは「サービスによる」としか言いようがなさそうです。
それでも自分なりにいろいろなAPIデザインについて調べてチームで共有し、どれでいってみようという決定をしました。
いろいろ調べていると二つの大きな問題があると思いました。
- ドメインが複雑な場合、REST APIでは表現しにくいendpointがある
- 進化の早いフェーズではモデルへの変更も大きくその追従が難しい
Scalebaseのフロントではprotoを使ったモデルの共有を最初からやっており、かつ時雨堂のブログとかも見ていて、gRPCでいきたい気持ちはあったのですが、二つ目の問題にはあまり効果がないと考えました。GraphQLはかなりいいアプローチだと思っていますが、より一般的なAPIでClient側のコードへ工夫が小さいものをまず作りたかったので、RESTを踏襲しつつ柔軟なendpointを表現できるものを探しました。モデルへの変更については今のところこの設計ではAPIバージョンを分けるしかないかなと考えています。
最終的には Slack Web APIに近いものを作成しています。RESTのようなリソースアクセスではなく、RPCライクなendpointで複雑な呼び出しを直感的にできるようにしています。 model.listやmodel.getがあれば普通のRESTにも戻せるので困らないうちはこのままいくつもりです。また、GraphQLバージョンのAPIも順次対応していきたいと思っています。全然知見がないので詳しい方是非お話聞かせてください。
宣伝になりますが、上記のAPIデザインについてアーキテクチャを踏まえてより詳しく話すべくScalaMatsuri 2020のセッションで、プロポーザルを出しているので応援よろしくお願いします！
https://scalamatsuri.org/ja/proposals/J13
アプリケーション開発、バックエンド開発
Salesforce特有の制約に結構悩まされました。データモデルの作成に癖があったり、そもそも僕にSalesforceの世界のドメイン知識が少なすぎて的確な意思決定が難しかったです。営業メンバーのサポートやSalesforceエンジニアがいないと開発が難しいなあと改めて思いました。早めにやっておくべきだったなと感じたのは、開発する上で個人ではない限りSalesforce社員のアライアンスの方がいるはずなので、その方ともっと情報交換や意見を求めるべきでした。リリースの直前にこれまで考えてなかった正しい使い方を教えてもらえたりしたので早めに相談すべきでした。
セキュリティレビュー
SalesforceのAppExchangeに自分たちが開発したアプリケーションを載せるにはセキュリティレビューというものをパスしないといけません。具体的にはアプリケーションの静的コード解析を通したり、テストコードのカバレッジを一定数以上にしたり、外部サービスへの連携がある場合は、その外部サービス側のAPIの脆弱性診断みたいなものが必要になります。これも一ヶ月ほどで準備、修正などを行いバタバタでした。
公式ドキュメント: developer.salesforce.com
セキュリティレビューの流れは、
- Salesforceとのパートナー契約を結ぶ
- Salesforceアカウントでパートナーコミュニティに参加
- アプリケーション開発
- リスティング情報を入力
- アプリケーションのコードスキャンとレポート作成
- 外部サービス（ここではScalebase）をOWASP ZAPを使った脆弱性診断とレポート作成
- セキュリティレビュー申請のケースを上げる
- セキュリティレビューの請求支払い
- アメリカ本国のレビュアーによるレビュー
- レビュー指摘項目の修正
- リリース
というものです。アメリカ本国でのレビューに最低4週間程度かかるのが当初のスケジュール的にかなりタイトだったので相当Salesforceの方と密に連絡し、優先度を上げてもらったりしました。この辺はアライアンス担当者に直接聞くのが早いと思います。また、セキュリティレビュー中もアプリケーション開発が続くなら、レビュー用のバックエンド環境などを用意する必要があります。一度レビューで修正指摘があった場合、二営業日以内に返信すると同じレビューアーにアサインされるらしく、結果が帰ってくるのが早いという知見もありました。
OWASP ZAPを使った脆弱性診断では、普段使わない筋肉というか、これくらいは知っておくべきだよねという対策とかもできて楽しかったです。ソフトウェアで擬似攻撃を仕掛けるようなもので、その結果をある程度網羅的に見てくれますが、サービスの性質などでは脆弱性というより仕様みたいな部分もあるので、そこはレポートと一緒に文面で伝えることで柔軟に対応してもらえました。
失敗談
このままだといい感じにリリースできたという話で終わってしまうので、今後のためにも泥臭い部分も書いておきます。セキュリティーレビューをなんとか切り抜けたのですが、提供するアプリケーションのゴールをうまく認識合わせできておらず、結果として多くの追加機能開発や修正を行うことになりました。
- 要求ヒアリングや認識合わせ
- ロードマップ作成、メンテナンス
- デモ
- 修正と受け入れテスト
そういった認識齟齬をなくすためにも上記のようなことを定期的に行い、合意をとるべきでした。そのほかにもScalebase側の開発とテンポがずれているので何をどこまでやるか？というのを調整するのがうまくいかなかった印象です。プロジェクトマネージャー不在問題ではあるんですが、マネジメント専任を付けれるほどリソースがないので、いないときにどうしなきゃいけないのかというのはアルプ全体で意識しています。今回もマネジメントに徹するのではなく、セルフマネジメントと実装をしやすい仕組みを作るようにすべきでしたが、業務委託メンバーと社員ではなかなか時間的制約やコミュニケーションロスがありうまく行ってない感覚がありました。今後の改善点です。
開発環境差分の地獄
Scalebaseではフロントとサーバーの構成はほぼ同じで、みんなで一緒にリリース！みたいなことが普通なので、これまで意識してなかったミスがたくさんありました。これまでは以下を用意していました。
- エンジニアが触る開発用DEV環境
- 詳細なテストなどを行うQA環境
- プロダクションとサンドボックス環境
これに加えて、
- 営業チームが使うデモ用環境
- セキュリティレビュー用の一時的な固定環境
- クライアントにお試しとして渡しているSalesforceアプリケーションのSandbox環境
などなど一時的にどんどん環境が増え、デプロイの独立性を疎外したり、チェック漏れによる不具合などが起きて一瞬カオスになりました。そんな中でもSalesforceアプリケーションからすると「なぜ早くAPIが固定されないのか、追従するのが大変」という意見がありました。自分も経験したことがあるので理解はできますし、サービスの進化が激しい時期にはどうしてもモデルの変更などが起こり得るので歯痒い気持ちでした。これまで対応していただいたサーバーサイドのエンジニアのみなさん、本当にありがとうございます。
APIを公開した今、プロダクションで使われる可能性があるので、かなり変更には慎重になりつつも、サービスの急速な進化に耐えうるAPIデザイン、システム設計が求められるのでやることはまだまだ尽きないです。がんばっていく。
もろもろを乗り越えて、なんとかリリースまで持ってこれました。改善点多すぎるのでKPTしたりして徐々にいい方向へ向かいそうです。アルプにはバックエンドやアーキテクトもメンバーとして増えたので、より洗練されたプロダクトを目指して改善していけそうです。Salesforceエンジニアがチームにいればもっといいのですが、市場でも少ないのが体感としてあり、Salesforce社員にヒアリングする中でも本当にいないので困っていると伺いました。開発チームメンバーが育てていくのがいいですが、よりメタな視点で開発を見れる経験を持った人を切実に探している状況です。
入社から半年でバックエンド開発でのScalebaseリリース、次の半年でSalesforce向けアプリケーションリリースなど面白い日々を過ごせているので、次の半年もまた面白いミッションをやりつつ、いい報告ができるようがんばっていきます。
アルプタグで開発日誌公開中
アルプの開発現場のリアルを綴っています。どんなチームが何をしているのか、ぜひ御覧ください。
Salesforceエンジニアも募集中なので何卒！
アルプで一緒にやっていきたいというメンバーを募集しています。興味のある方はぜひご連絡ください。
