サクラエディタからVisual Studio Codeへ乗り換えたくて拡張機能を作った

本記事はエントリーブログを兼ねた、チームスピリット Advent Calendar 2019 の7日目の記事です。 adventar.org

こんにちは！
2019年7月にTeamSpiritにジョインした里石です。

弊社のSDチームでは、サービスの開発にEclipseまたはVisual Studio Code(VS Code)を用いています。
私は前職ではサクラエディタを多用していましたが、その上位互換なVS Codeも注目はしていたものの、カーソルの操作感などに違和感があって乗り換えには至りませんでした。
そこで今回、入社を機にその違和感を乗り越えるべく、勉強も兼ねてVS Code拡張機能を２つ作りました。

カーソル移動の改造（skr Jp Word Handler）

marketplace.visualstudio.com

VSCodeでの日本語圏向け拡張機能としては、Suguru Yamamoto氏の「Japanese Word Handler」という優れた拡張機能がすでにあります。

今回はそれを参考にさせていただきつつ、開発しました。

概要

Windowsのサクラエディタライクなカーソル移動を行います。
実際には、サクラエディタっぽい挙動に加えて、VSCodeのcursolWordPartLeftとcursolWordPartRightのカーソル移動の挙動も取り入れています。

下記のように、単語や文字種毎にカーソル移動を行います。

実装機能

• カーソル移動 および 選択
  

• 句切り文字毎削除
  

対応句切文字パターン

• VSCodeのSeparateWordに設定する区切り文字
• スペース
• 英字(大文字)
• 英字(小文字)
• 数字文字
• 記号
• タブ制御コード
• 日本語のひらがな
• 日本語のカタカナ
• 日本語の漢字
• 日本語の句読点
• 日本語の全角英字(大文字)
• 日本語の全角英字(小文字)
• 日本語の全角数字
• 日本語の全角記号

既知の制限事項

JapaneseWordHandler拡張機能と同様に一部制限があります。
拡張機能は、単語に関する以下の機能を差し替えることができません。

• ダブルクリックによる単語選択
• カーソルポジション上の単語の自動ハイライト
• テキスト検索時の「単語にヒット」

その他

ライセンスは、Suguru Yamamoto氏のJapanese Word Handler拡張機能を継承して、zlibライセンスです。

全角文字の強調表示（flexibleZenkaku）

marketplace.visualstudio.com

VSCodeでは、サクラエディタのように全角スペースをハイライトすることができません。
これを実現するには、mosapride氏の「zenkaku」というシンプル・イズ・ベストな拡張機能があるのですが、 個人的な不満として、ソースを直接編集しないと見た目のカスタマイズができないというのがありました。

それを「設定」画面上からできるよう改造したのが本拡張機能です。

実装機能

readmeにも記載していますが、「設定」画面から、色や線種・塗りのカスタマイズができます。

その他

ライセンスは、mosapride氏の「zenkaku」拡張機能を継承して、MITライセンスです。

終わりに

とりあえず、自分の思うようなカーソル移動を実現できたので、無事VSCodeに乗り換えることができました。
あとは、「矩形貼り付け」がまだ違和感があるので、そのあたりの拡張機能が作れないか検討中です。

よろしければ是非ご利用いただき、フィードバックをいただけると幸いです！

また今回の拡張機能の開発を通して、VSCode上におけるTypeScriptのテスト環境構築の方法も学ぶことができました。
引き続き、12/14のアドベントカレンダーではその方法について解説しています！

satoishi-ts.hatenablog.com

プロダクトマネージャーのTrends & Benchmarks Report 2019を読んでみる

この記事はチームスピリット アドベントカレンダー2019の20日目の記事です。 adventar.org

TeamSpirit Singaporeでプロダクトマネージャーとして奮闘しているNinoです。 最近インタビュー記事を書いてもらいました。 それが気づいたらSlackのemojiにされてました。愉快なメンバーと楽しく働いています。

（誰がやっているか知らんが、最近emoij増やされてる…。）

さて、プロダクトマネージャーとしてまだまだ勉強中の私ですが、今回は先日公開されたプロダクトマネジメントのTrends & Benchmarks Report 2019というレポートを読んでよりPMという職をより深く理解していきたいと思います。

レポート発行元、Product Management Festivalについて

---

このレポートの発行元はProduct Management Festivalという、世界的なプロダクトマネージャーを支援している組織で、スイスのチューリッヒに本拠地があります。 GoogleやFacebook、ATLASSIANのPMの方々も所属しており、現在はヨーロッパ中心に活動していますが、最近シンガポールなどのアジアでもカンファレンスを開催して勢いがあります。 日本ではまだ恐らく全くの無名ですが、1月に弊社で日本初のイベントを開催する予定です。 teamspirit.connpass.com ちなみに、この記事を書いてもいいかと問い合わせたところ快諾してくれました！（※無断転載ではないので悪しからず。） 日本にもこれから広めていきたいですね。

レポートについて

---

このレポートはPM Festivalが今年実施したアンケートをもとに作成されています。

回答者は世界中で働いてるPMの方々で、1011人、59カ国から回答を得ています。
（私も回答しました。）

本レポートはこちらから無料でゲットできますので興味ある方はぜひ。

それでは中を見ていきましょう！

PM歴

---

回答者がどれだけのPM歴を持っているか。

（グラフ左）約4割の人が6年以上のPMを歴を持っているんですね。
先輩たちから学ばないといけませんね。

キャリアパス

---

PMになる前はどのような職に就いていたか。直前の職は何か。今のジョブタイトル。

（グラフ左）プロマネ出身の人が一番多いですが、満遍なく色んな職種からPMになっているのが分かりますね。
自分のようなエンジニア出身が10%しかいないのは思ったより少ない。

プロダクトマネジメントの成熟度

---

回答者の組織でプロダクトマネジメントがどれだけ成熟しているか。

（円グラフ）8割の組織でプロダクトマネジメントがまだ成長段階にあると回答していますね。

コラボレーション

---

他の職種とどれだけうまくコラボレーションできているか。

(グラフ左)やはり、まずは現場のエンジニア、QA、デザイナーとうまくやることが大事ということですね。
BAとうまくやれているという回答が３割しかないのは意外でした。

PMの役割と価値

---

組織の中でPMという職がどのように認識されているか。

(グラフ下)PMの役割が完全に定義されていて、周りに理解されているという回答が２割しかないですね。
自分もPMの責務は広くて境界もあいまいな部分が多いなと感じています。
これはあるあるの悩みっぽいですね。

PMのスキルと価値

---

どのようなスキルが大事と思うか。一番の責務は。

(グラフ左)重要なスキルにコミュニケーションとチームワークが来てますね。PMはステークホルダーが多いので納得ですね。
(グラフ右)PMが感じている責務は次の3つが群を抜いてますね。1,プロダクトのビジョンとストラテジー、2,プロダクトの要件管理、3,ロードマップとリリース管理。

プロダクトビジョン

---

(グラフ右上)半数以上がプロダクトのストラテジーやビジョンを月に1回以上レビューしていると回答していますね。
固めるのではなく、常に状況に合わせてアップデートしていくのが重要ということですね。

プロダクトの成功とPMの評価

---

プロダクトの成功をどう計測するか。成功は誰に帰属するか。PMの人事評価。

(グラフ左上)プロダクトの成功を測るメトリクスは次の4つがメジャー。1,財務的な数値(売上/利益)、2,顧客数、3,エンゲージメント、4,顧客満足度/NPS。
(円グラフ)一方で、それらの指標はPMの個人的な評価にも使われるかは半々のようです。

フレームワークと手法

---

プロダクト開発に利用している手法。それらの満足度。

(グラフ左)9割以上がスクラム/アジャイル/カンバンを利用していることが分かります。我々もそうです。
(グラフ右)しかしながら、それらを満足に運用できているのは45%に留まっているが分かります。スクラム運営の難しさが表れているのかなと思います。

PMにとってのチャレンジ

---

PMにとってのチャレンジTop3。プロダクトに影響のある課題。

組織の目標を達成しなくてはいけない一方で、意思決定や責務が不明確、そもそも時間がない等の課題をPMは抱えていることが、この2つのグラフから読み取れますね。

業務

---

メインで取り組んでいてる仕事。主な成果。優先順位の付け方。

(グラフ左上)PMが日々何に一番時間を使っているかというと、実はデイリーの業務や突発的な依頼、トラブル対応なんですね。
PMでありながら、実作業としてはプロダクトに関する仕事に一番多くの時間を割けていないというのが現状のようです。
(グラフ右下)優先順位の付け方の結果も非常に面白く、大半の人が「経験と直感」でやっていると回答しています。

仕事の満足度

---

PM職に必要だと思う要素。満足度(レート)。満足度(ステータス)。転職志望度。

(グラフ左下)5割以上の人が、仕事の満足度に対して、10点中7点以上を付けていますね。これは平均的に高い数値と言えるのではないでしょうか。
(円グラフ右上)45%の人が「ワードワークだが楽しい」と回答しています。これはPMになるための一つの資質かもしれませんね。

PMの採用

---

直近6ヶ月のPMの採用予定。PMの採用方法。PMの採用難易度。

(グラフ左上)直近6ヶ月で半数以上の会社がPMを1人以上採用しようとしていることが分かります。去年に比べて需要が高くなっているのも見て取れますね。
(グラフ右上)驚くことに、採用の一番の手法はリファラルで60%となっています。これは日本に比べるとかなり高い割合ではないでしょうか。

おわりに

といわけで、ざっと2019年のPM Trends & Benchmarksを見てみました。
まだまだ勉強中の私ですが、共感できるところ、興味深いところが多くありました。
みなさんも、少しはPMに興味が湧いたり、理解が深まったりしましたでしょうか？
英語のレポートですが、全然難しくないのですべて見たい方はこちらからどうぞ。

ちなみに、2020年もこのアンケートは実施されます！PMの方はぜひ参加してみてください！
（この件で連絡した際に、Product Management Festivalから「日本語に訳すの手伝ってくれないか？」と言われたのでもしかしたら日本語Ver.もできるかもしれません。がんばります。）

スクラムチームで探索的テストをやったお話。

この記事はチームスピリット アドベントカレンダー2019の15日目の記事です。

adventar.org

Frohe Weihnachten!! …まであと9日。
こんにちは、チームスピリットのQAエンジニアのSumiです。

去年はドイツのクリスマスマーケットを紹介するという1ミリも仕事に関係ない話だったので、今年は仕事に関する話を書いてみようと思います（ドキドキ）。内容は、私がスクラムチームやほかのQAメンバーとともに行った品質保証の取り組みについてです。なお、弊社の品質保証の方法についてはQAリーダーの生井がJaSST’19北海道で登壇した資料がありますので、そちらをご覧ください。

speakerdeck.com

弊社の開発スタイルについて

弊社のプロダクトはSalesforceのPlatform上で動くサービスで、開発手法は2週間スプリントのスクラムを採用しています。これ自体はわりと一般的かと思いますが、他社と大きく違うのはリリースのタイミングです。通常スクラムの原則としては各スプリント終了時にリリースできるように開発などを進めていくとなっていますが、弊社はSalesforceの4か月に1度実施されるバージョンアップに合わせる形でスクラムを回しパッケージをリリースしています。*1
開発（テスト）体制については、勤怠・工数・経費などのモジュールごとにスクラムチームがあり、QAエンジニアが各スクラムチームの一員として日々ユーザーストーリーの機能テスト（手動）などを実施しています。1バージョンなので、開発、テスト、プロダクトマネージャーのレビュー工程が終わった後にコードをmaster branchにマージするという流れです。

課題

まだチームが勤怠・工数しかなく、日本にしかオフィスがない時代は特に問題はなかったのですが、去年夏にシンガポールの開発拠点ができ、また経費など新たなモジュールのチームが立ち上がったことで、徐々にmasterの品質を保証することが困難になってきました。
具体的には新機能開発や不具合修正の影響範囲の調査が不十分で、他機能や他モジュールに影響がでてしまうというような問題が起き始めていました。masterにマージする前のテストフェーズでできる限りの確認はしていましたし、レビューでも影響範囲の確認はしていますが、それでも…*2
そして、masterにマージしてからリリース作業まで時間がある場合はどこかで偶然的に発見されることがあったものの、リリース間隔が短くなったことでそのチャンスも減っていました。その結果、製品をリリースした後に不具合が見つかりパッチを出してしまうということが発生し始めていたため、いかにこのような不具合をリリース前に見つけつぶすかという対策が求められていました。

対策

この時求められていた"パッケージリリース前にmasterの品質をあげる"ということを実現するために、
①時間をかけず
②効率的に
③不具合（主にリグレッション課題）を見つける
という条件をクリアするアプローチが必要でした。それでかつ、リリースを遅らせないという…
そこで私たちQAが提案した方法は、リリース予定の開発物がすべてmasterブランチにマージされた後に開発チーム全員で探索的テストを実施するというものです。
具体的には、エンジニア1人当たり最低半日分の工数を探索的テストに使ってもらい、それぞれチャータに従いテストをするという感じです。ただのモンキーテストにならず効率的に不具合を発見できるようテスト分担、環境、テスト観点などのチャータを事前にQAが準備しました。またQAだけでなくエンジニアにもテストをしてもらった理由は、時間（期間）はかけられないという制約の中で工数を集中投下することで最大限の手厚いテストができるようにするためです。なお、探索的テストを通じてエンジニアにより品質への意識を高めてもらいつつ、他モジュールの製品についても理解してもらう狙いなども実はありました。

結果

エンジニアが発見した不具合をJIRAに起票してもらいQAが集計・分析を行ったあと、テスト計画に記載したリリース判定条件に照らし合わせながら、リリース可能な品質に達しているかどうかプロダクトマネージャーと議論しました。このときは残念ながら一度のテストでは十分な品質でないという判断になり、発見された不具合を修正しつつ手が空いたメンバーで追加テストを実施することになりましたが、当初の目的であった"パッケージリリース前にmasterの品質をあげる"ということは達成できたといえると思います。もし探索的テストをせずにそのままリリースしていれば、パッチにつながりかねない不具合も発見されていたからです。
ただ、もしかしたら一番の収穫は、テストを実施したことに対するプラスの意見がエンジニアから出てきたことかもしれません。このテストがエンジニアにとって、プロダクトの品質をどう高めていくかを考えるひとつのきっかけになったのであればQAとしてはとても嬉しいことです。

今後について

しかしながらこのリリース前の探索的テストはあくまで一時的な対策でしかないと考えています。
本来品質はもっと前から作りこむべきで、今この対策でギリギリのラインで品質を保証せざるを得ないということはどこかで打つべきアクションができていないということだと思われるためです。それはコードレビューの質の向上かもしれませんし、自動テストの拡充かもしれませんし、さらに適切な技法を用いた各ストーリーチケットベースのテストかもしれません。
QAとして引き続きプロダクトの品質向上と安定的な品質の保証ができるよう、そしてお客様に私達の製品を使うメリットをより享受していただけるよう、さらにいろいろ取り組んでいきたいと思っています。*3

メンバー募集中！

そんな私たちと一緒にプロダクトの品質向上を担ってくださるQAエンジニアを大絶賛募集中です！テスト設計や実施だけでなく品質保証全体に携わることができるので、興味がある方はぜひこちらから応募をお待ちしております！

*1:私が携わっている新製品の開発チームは現在、リリース頻度を高めお客様に早く価値をお届けできるよう2か月ごとのリリースを頑張っています。

*2:回帰テストとして必要最低限の自動テストは実施していましたが、リソース不足で自動テストの拡充ができていなかったという事情もあります。

*3:そのための1歩としてJSTQBのAL-TAを受検予定！

TeamSpirit Inc.の社内IT施策

こんにちは、ブログ初執筆の社内IT担当、小林です。
初登場ということで、社内IT部門でやっている&やっていくことを紹介します。

adventar.org

Self Introduction

事業会社で開発系のエンジニア、コンサル会社で官公庁/企業向けプロジェクトでコンサルタントとしてのキャリアを経て、TSI情シス部門の立ち上げ部隊(といってもまだ1人)として参画させていただきました。

なんちゃってだけど出身がエンジニアということもあり、LTとかテック系のイベントがけっこう好きです。
短期間だけどコンサルだったこともあり、プロジェクト進めたりドキュメント作ったりするのも好きです。
経歴関係ないけど、お酒とランニングも好きです笑

Mission

社内のITインフラの運用・保守だけでなく、ITのあらゆる側面から自社の成長をさらにドライブしていきます。
各業務ディビジョンには営業、導入サポート、カスタマーサポート、開発と各分野のキスパートの方々が日々活躍されていますが、社内を俯瞰して見られる立場だからこそ、全体最適の施策を提案して進めていきたいと思います！

What we do

ざっと3つの領域で活動してます。いくつか最近の例を紹介します。

1. IT企画関連

特に全社横断的な業務・システムの課題への対策を検討し、システム側で対処する場合は解決に向けプロジェクトの管理・ファシリテーション、関係各所との調整、サービス選定等をカバーします。

例えば、基幹システムのリプレースに向けて、業務側のヒアリングやベンダー選定をしたり(どちらかというと社内SE,PMO的な動き)、CRMの設定・活用を見直したりしようとしてます。

FYの施策として挙がっているものやメンバー個人からの問題提起ときっかけは様々ですが、解決につながればそれだけ会社全体へのインパクトが大きいので、いろんな人を巻き込んで着実に実行できるよう頑張っていきます。

2. ツール活用関連

業務効率化のため、主に各業務ディビジョンで利用予定のサービス・ツールの事前検証や、利用中のサービス・ツールの機能をさらに活用して作業時間を短縮する検証、現場展開のお手伝いをしています。

例えば、契約・会計業務で利用しているSaaSのサービスに、APIツールを使って会計データを流し込む方法を確立する、という具合です。直近では、受付システムの追加導入をしたり、電子署名ツールの導入に向けて運用・作業手順の整理を進めようとしてます。

SaaS企業として、流行りだったり遊び心のあるサービスを使っていることは対外的にも"イケてる"イメージにつながると考えているので、有効なものをどんどん導入していければと。

3. 情シスロジ関連

だいたい定期的に発生する、システムのハード/ソフト面での各種メンテナンスをやります。

例えば月に2回、新入社員向けのPC設定や各種アカウントの発行、初出社日のオリエンをやっています。PCの操作とかオリエン時にハンズオンでやるので、人数が多かったりすると内心ドキドキしますが…IT系出身の方が多いのでサクサクキャッチアップしていただき助かってます。

最近では、組織変更や業務実態に合わせて、勤怠システムのマスタや電子稟議の承認フローを変更しました。変更内容や事前検証の設計(一部を担当)から始まり、検証や設定変更と手を動かすところもやります。

特に設計面の、権限回りや承認ステップの条件分けがポイントで、承認者や組織階層などが変わってもシステムの変更が最小限ですむよう保守性の向上にはまだ改善の余地があると感じています。

Message

これまでは社内IT施策に割くリソース余裕がなかったという背景がある(とのこと)ので、まずは各ディビジョンの業務上マストな施策中心に取り組みつつ、「こんなこともやってみよう」と提案して各コア業務をより効果的に進められるようサポートしていければと思っています。

あとは…仲間が欲しい。特にでっかめの基幹システムやインフラの知見・経験を持った人、募集してます。社内IT関連のイベントに顔を出して発信したり、情報交換したり、地道にやっていきます。

>To TSI members

こんなかんじでまだまだ始動したばかりですが、PCトラブル起こった時でなくてもやりたいこと、困っていることあればぜひお声がけください！

よろしくお願いします！

【今更ながら】JaSST'19 Hokkaido 登壇レポート

こんにちは、会社のブログを書くのは半年ぶり、QAチームの生井(id:riririusei99)です。
今更ながら、8月30日に登壇したJaSST'19 北海道の登壇レポートです。

オフィスの引っ越し大名をやったり、カスタマーサクセスサポートの仕事をしたり、お披露目パーティの幹事をやっていたら登壇レポートが延び延びになっていました。

adventar.org

この記事はチームスピリットアドベントカレンダー２日目の記事です。

きっかけ・JaSSTとは

NPO法人ソフトウェアテスト技術振興協会（ASTER）が全国各地で開催しているソフトウェアテストシンポジウム（JaSST ： Japan Symposium on Software Testing）で、QAエンジニアであれば大抵名前を知っているシンポジウムです。

TeamSpiritのQAチームの活動を認知してもらうために、実例発表の公募に応募したりしていたのですが残念ながら不採択になったりしていた所、前回発表した勉強会（Agile QA Night!!登壇レポート - チームスピリットデベロッパーブログ）で東京以外の開催についての情報を教えていただきました。

ということで、当時一番開催が近かったJaSST'19 北海道を目標に定め事例発表を活動を始め、この度登壇する運びとなりました。

実際の発表

speakerdeck.com

「アジャイル開発✕品質保証」については、様々な企業が取り組んでいるテーマだと思っていて、チームスピリットでは2017年から取り組んでいます。
短いながらもこれまでの経験が貯まってきたこと、またそれを発表することで、これからスクラムを始めるQAの方に向けて気づきになる部分があるのではと思い、この度事例発表という形で登壇しました。

発表では、スクラム開発が始まっていたものの上手く行っていなかった・品質保証のプロセスがなかった状態に対して、QAとスクラムマスターの観点から改善を行ったこと、チームの成長に伴い課題感も変わったときの対応について発信しました。

実際の発表では詰め込み過ぎて、思った通り発信できなかった実感がありましたが…その後のブース等で個別に疑問点を答えることができたかなと思います。

発表で伝えたかったこと

当日緊張しすぎ＆詰め込み過ぎたため、
自分の想いみたいなのを乗せられたか怪しいので、ココで補足しておきます。

地道な積み重ね

当然といえば当然ですが、スクラムチーム内でも所属する人や状況によってチームの課題感は異なると考えています。
今回の事例発表は一つの例なので、課題の設定の仕方やどのようなアプローチを選択したかについて着目してもらえればと思います。

発表でとりあげた施策は個別に着目してみると、どれも当たり前だったり小さな施策が多いように感じるかと思われます。
私達のチームではスクラムのルールに則り、目指すべき姿に対して異なっている部分・足りない部分を一つ一つ改善・解決していくことにしています。
なぜなら、基礎や小さな改善の積み重ねた先に、強いチームがあると考えているからです。

ISTQBのテストプロセス

チームスピリットのQAチームではISTQBの知識体系を大切にしています。
主な利点としては、新メンバー含めた共通認識として使えること、チームやプロジェクトが増えた時にも転用しやすいことがあげられます。
共通の知識体系を使うことは意見の拠り所や楔になるので、変化が激しいチームには必要だと思います。オススメです。

おわりに

今後もチームスピリットのスクラム開発は継続していきます。
いろんな失敗をして、新たな気づきを自分のものにしながら強いチームに成長していけたらなぁと思います。

個人としては来年はもう少し、ブログ等で発信を頑張りたいと思います。

おわり

Salesforce Webinar 「Salesforce DX の始め方とパートナー様成功事例」（後編）

こんにちは、倉谷(id:a-kura)です。

「Salesforce DX の始め方とパートナー様成功事例」の発表内容を紹介した前編に引き続き、そこで挙がった課題に対して解決できた「DevHub移行」について紹介します。

teamspirit.hatenablog.com

DevHub の移行

当時の課題として、DevHub を開発者組織からプロダクション組織に移行することが残っていました。 ここでは、自社組織 PBO (Partner Business Org)の DevHub に移行したので、その際に検討した点や注意点についてまとめておきます。

検討事項：PBO とすべきか？それとも別の組織とすべきか？

当初、PBO (Partner Buisiness Org) では管理権限の問題で利用制限がかかったりする可能性があると考えて、別組織を購入しようと考えていました。 しかし、セールスフォース・ドットコム社とやりとりをする中で、PBO を利用する決断をしました。その決断をした経緯について、少しふりかえってみたいと思います。

PBO を利用する場合のメリット、デメリットを下記のように考えました。

メリット

PBO を利用した場合のメリットは、スクラッチ組織の作成数が増える、SalesforceDX用無償ライセンスが提供される、などのパートナー特典が受けられる点です。詳細はこちら。

developer.salesforce.com

デメリット

PBO を利用した場合のデメリットは、現行業務に影響を与えたり、制限を受けたりする可能性がある点です。PBO では内部統制上の問題もあるので、システム管理者権限は利用できません。この制限により DevHub の運用が滞るリスクがあります。

PBO の DevHub を利用することにした理由

セールスフォース・ドットコム社とのやりとりで、今後の機能拡張によって PBO の DevHub を利用する必要があることがわかりました。第2世代管理パッケージでは、一つの名前空間で複数のパッケージが作成できるようになったり、名前空間を持つ Scratch Org を作成できたりします。そのため、PBO と DevHub の関係が密接になってくるため、依存関係が出てくるようです。

このことが決め手となり、PBO を DevHub として利用することにしました。

PBO を DevHub として利用するために実施したこと

基本的には、こちらのページに記載してある内容で設定していきました。

developer.salesforce.com

組織の DevHub 有効化

情報システム担当の方に PBO に影響がないことを説明して、DevHub を有効化しました。 実際に業務が稼働しているので、影響を与えず利用できることが重要になります。

Free Limited Access ライセンス取得＆専用アカウント作成

CircleCI から接続するために専用のアカウントを作成します。そのライセンスとして無償提供される Free Limited Access ライセンスを利用しました。自動テストの実行などに利用するだけなので無償ライセンスがあるのは非常に助かります。

このライセンスは Partner Community からケースで依頼します。ライセンスの期限が短く設定されていますが、自動的に延長されるため問題ないそうです。ライセンス取得後、プロファイルを手順に沿って作成しました。

接続アプリケーション作成

CircleCI から JWT (JSON Web Token)で接続するために接続アプリケーションを作成しました。

手順通りに進めればよいですが、証明書の作成や秘密鍵の管理が必要になる、など黒い画面（コンソール）を使った対応が必要なため、情報システム担当の方と協力しながら進める必要がありました。

権限付与

こちらも手順通りに進めれば、問題ありませんでした。
設定する項目は多くなく、「API の有効化」とスクラッチ組織に関係するオブジェクトの操作権限を設定します。どのように設定すればよいか手順に書いてあるのでほぼ迷うことはないと思います。

制限事項

上記の設定で、Salesforce DX CLI を利用してスクラッチ組織を使った開発を行うことができるようになります。しかし、一つ制限があることを見つけました。

見つけた制限とは、スクラッチ組織の Limits を参照するコマンドが実行するには追加の権限が必要だとわかりました。

スクラッチ組織の1日の作成数と上限数、アクティブなスクラッチ組織の数と上限数を参照するために、force:limits:api:display を実行したかったのですが、別途「設定・定義の参照 (View Setup and Configuration)」の権限がないとコマンドを実行してもエラーとなってしまいます。

エラーメッセージは下記のものが出力されます。

API_DISABLED_FOR_ORG: limits resource is not enabled
Error: limits resource is not enabled at Object.exports.exitWithMessage(...)

PBO にあるユーザーなので与える権限は最小限にしたいため、弊社ではスクラッチ組織の作成数と上限数を参照することを諦めることにしました。

おわりに

後編では DevHub 移行について体験談を書きました。
ほぼ Salesforce DX 開発者ガイドに書いてある内容で問題ありませんでしたが、スクラッチ組織の作成上限を取得するためには別途権限が必要でした。フル機能で利用したい、継続的インテグレーションでスクラッチ組織の上限が近いときに警告を出したい、などの場合は PBO で権限を付与してもらえるか注意が必要です。

以上、DevHub を PBO に移行しようとする方はご参考にしていただければと思います。

エンジニア募集♪

チームスピリットでは、アジャイルなプロダクト開発を共に推進してくれるエンジニアを募集しています。どんな考えや想いで開発しているのか少しでも興味を持っていただいた方、ぜひご連絡ください！（直接メッセージでも、下記の応募フォームからでも構いません）

Enjoy DX!

Salesforce Webinar 「Salesforce DX の始め方とパートナー様成功事例」（前編）

こんにちは、倉谷(id:a-kura)です。

今さらな感じですが、Salesforce Webinar にゲスト登壇しました。そこで、前編では発表内容、後編ではその後に取り組んだDevHub移行の課題について紹介します。

はじめに

2019年8月30日に開催されたセールスフォース・ドットコム社主催の Webinar にゲスト出演しました。この Webinar では、Salesforce DX の活用事例を2社、co-meeting 木村さんとチームスピリット倉谷から話しました。こちらから資料と動画を見ることができますので、よろしければご覧ください。

developer.salesforce.com

Salesforce DX の始め方とパートナー様成功事例

私から Salesforce DX の活用事例として、CI環境構築における活用事例を話しました。 まず、背景として CI 環境が必要となる理由についてです。

チームスピリット社では、AppExchangeのOEMアプリケーションを開発・提供しています。 このB2Bサービスである TeamSpirit は1100社、17万IDに利用されています。

これだけのお客様に継続して利用していただくために開発に関わるメンバーも増えてきています。 そこで、サービスの品質を高いレベルで保ちつつ、チームで開発を進めるための基盤の一つが継続的インテグレーション (CI : Continuous Integration) です。