チームスピリットデベロッパーブログ (original) (raw)

はじめに

こんにちは！開発チームの古厩（ふるまや）です。

今年の4月に新卒で入社したばかりの私は、IT業界の基礎をしっかり固めるために「ITパスポート試験」にチャレンジし、無事に合格しました！今回は、試験内容や私が実際に活用した学習方法、そして受験後の感想について、新入社員の視点から詳しくお話しします。

ITパスポート試験とは？

ITパスポート試験は、ITに関する基礎知識を幅広く問う国家資格です。IT業界だけでなく、さまざまな業種で活用されるITの知識、経営に関する知識、さらには情報セキュリティや法務に関する知識も問われます。入社直後に受験することで、IT業界の基礎をしっかりと学ぶ良い機会になりました。

試験内容

ITパスポート試験は、以下のような形式で実施されます。

試験概要

項目 内容
試験時間 120分
出題数 小問：100問（*1）
出題形式 四肢択一式
出題分野 ストラテジ系（経営全般）：35問程度
マネジメント系（IT管理）：20問程度
テクノロジ系（IT技術）：45問程度
合格基準 総合評価点600点以上であり、かつ分野別評価点もそれぞれ300点以上であること

試験方式

ITパスポート試験はCBT方式（Computer Based Testing）で実施され、試験会場のコンピュータで解答します。画面に表示される問題に対して、マウスやキーボードを使って選択肢を選ぶ形式です。この形式は、パソコン操作ができれば誰でも対応できるので、初めての方でも安心です。

採点方式

採点はIRT方式（項目応答理論）に基づいて行われ、問題の難易度に応じて評価されます。公平な採点が行われるため、試験の難易度に左右されず、受験者の実力が正確に反映されます。

（*1）100問のうち92問が評価対象で、残りの8問は今後の出題評価用として含まれています。

出題範囲

ITパスポート試験では、以下の3つの分野から幅広い内容が出題されます。

1. ストラテジ系（経営全般）
2. マネジメント系（IT管理）
3. テクノロジ系（IT技術）

学習方法：過去問道場をフル活用！

私は、「過去問道場」 というウェブサイトをメインに試験対策を行いました。以下で、その具体的な学習方法について説明します。

www.itpassportsiken.com

過去問道場を使った勉強法

1. 過去問を解いて全体の傾向をつかむ

まずは、過去問道場で過去問題を解いて、どのような問題が出題されるのかを理解することから始めました。ITパスポート試験は広範囲にわたるため、まずは全体像を把握することが重要です。私は毎日1時間を目安に過去問を解き、徐々に問題の傾向に慣れていきました。

2. 間違えた問題を徹底的に復習

過去問道場では、問題ごとの解説がついており、間違えた問題についてはその都度詳しく確認しました。苦手な分野を重点的に学習し、関連する問題を集中的に解き直すことで、知識の定着を図りました。この復習が、最も効果的な学習方法でした。

3. 模擬試験で本番の感覚をつかむ

試験直前には、過去問道場の模擬試験機能を活用し、本番と同じ120分で模擬試験に挑戦しました。時間配分の感覚を養い、焦らずに問題を解く練習ができたことで、本番でも落ち着いて対処できるようになりました。

試験当日の感想

試験当日は、過去問道場での練習の成果を発揮することができましたが、思っていたよりも新しい問題が多く、少し驚きました。そのため、結果は700点程度でした。合格ラインはクリアしたものの、より高得点を狙うには最新の出題傾向も把握しておくことが重要だと感じました。

ITパスポート試験は幅広い知識を求められるため、確実に合格を目指す場合には、IPAから公表されている「ITパスポート試験」シラバスも活用して学習することをおすすめします。シラバスには、出題範囲が詳しく記載されており、最新の出題傾向や学習すべきポイントを理解するのに非常に役立ちます。

www3.jitec.ipa.go.jp

まとめ

「過去問道場」を活用した学習は、ITパスポート試験対策として非常に効果的ですが、確実に合格するためには、最新の出題傾向を把握することが重要です。IPAが公表するシラバスを併用し、学習内容をアップデートすることで、より高得点を目指すことができます。これから受験を考えている方も、過去問道場とシラバスをうまく組み合わせて、着実に合格を目指してみてください！

こんにちは、Salesforce Saturday 京橋 の運営を行っている チームスピリットの田中 (id:mh-tanaka)です。
数回にわけて Salesforce Saturday 京橋の活動を報告しています。
2022年をこちらでふりかえりました。
今回は2023年の活動をふりかえっていきます。

2023年の活動

2023年のSalesforce Saturday 京橋の活動は
毎回十数名程度の参加があり、計9回実施することができました。
私達は年初に一年間の開催計画を決めています。もともとは7回実施予定でした。
しかし、他のコミュニティグループで開催ができなかった時があり、我々のグループがオンラインで突発開催をしました。
オンラインであるからこそフットワーク軽く実施できたように思います。
9回のうち2回はオフラインで開催することができ、
昨年同様Salesforceを学び始めたばかりの方が多く参加してくださりました。

2023年7月のオフラインSaturday

2023年7月に開催したオフラインSaturdayは特別な意味を持っていました。
なぜなら、2023年9月に京橋から日比谷のWeWorkへのオフィス移転が決定していたため、京橋オフィスでの開催が最後だったからです。
そんな最後の京橋オフィスで、12名の参加者のみなさんがのびのびとスペースを使いながら
参加者同士での交流をとってくださりました。
Salesforceの情報交換をしたい人たちで会議室に集まって話したり、もくもくと集中したい人はカウンター席などを使うなど空間の使い方に工夫ができました。
私事になりますが京橋オフィスの改装プロジェクトに関わっていたので、最後に心温まるイベントを主催できたのはとても嬉しかったです。

2023年京橋オフィスにて

さいごに

私たちは現在も、オンライン・オフラインを問わず、Salesforce Saturday 京橋のもくもく会を実施しています。
オフラインで行う場合は、京橋付近のレンタル会議室を利用しています。
Salesforce Saturday 京橋のメンバーになると、新しいイベントがオープンした際に通知を受け取ることができます。ぜひご登録ください。
初心者でもベテランでも、Salesforceを学びたい方をお待ちしています！

こんにちは、チームスピリットの田中 (id:mh-tanaka)です。
Pardot (Account Engagement) のランディングページを作成した時に、珍しくハマってしまったことがあったのでメモとして残しておきます。
なお、Pardotは旧称で、現在はAcount Engagement という名称になりました。このページでは呼び慣れている Pardot で統一します。

ランディングページとは

Salesforce のヘルプページによると以下のように記載があります。

ランディングページは、ビジターがリンクや広告をクリックした後にたどり着く Web ページです。一般的に、このページには広告、検索キーワード、クリックされたリンクに関連した固有のコンテンツが表示されます。関連性の高いアクション可能なコンテンツを提供することで、ランディングページのビジターのコンバージョンの可能性が高くなります。

要はWebページのことですが、Pardotではテンプレートを利用することでデザインが統一されたページが作りやすく、メンテナンスも容易にできるところが特徴的です。
今回は、ランディングページを利用したWebページをリニューアルしようとしている時に出会った制限事項でした。

ランディングページ作成手順

Pardot でランディングページを作成する手順は以下のようになります。

① 名前を設定

ランディングページの属性情報を設定します。

ランディングページ作成手順1

ランディングページ作成手順1

② フォームを選択

問い合わせフォームの有無を設定します。問い合わせフォーム不要の「フォームなし」を選択します。

ランディングページ作成手順2

ランディングページ作成手順2

③ ページレイアウト(テンプレート)を選択

テンプレートを選択します。
テンプレートにWebページのフレームワークやデザインを記載しています。 HTML, CSS, JavaScript が書けます。 テンプレートには差込可能な場所を用意しているため、差し込み箇所に入るコンテンツを次のステップで入力します。

ランディングページ作成手順3

ランディングページ作成手順3

④ ページコンテンツ(差し込みするコンテンツ)を作成

差し込みするコンテンツをランディングページエディターを利用して入力します。文章や図など、作りたいページの内容を入力します。

ランディングページ作成手順4

ランディングページ作成手順4

⑤ 確認して保存

入力した内容に問題がないか確認して保存します。

ランディングページ作成手順5

ランディングページ作成手順5

ハマってしまったこと

上記の手順でページを作成して、⑤の最後の保存まで行いました。ところがプレビュー表示をすると、コンテンツが途中までしか表示されませんでした。
④のエディターでページを開くと、入力したはずのコンテンツが途中から消えていることがわかりました。
何度入力し直しても必ず途中から消えてしまったので、これはなんらかのサイズ制限があると判断しました。
入力文字数を削減するために空白や改行などを削除するminify 化を行ってみました。
しかし、minifiy化した内容を保存しても、④のエディターでページを開くと自動でフォーマットされて空白や改行が元に戻ってしまいました。

後にSalesforce に問い合わせして判明しましたが、
④のランディングページエディターには文字数の制限があり、最大 65000 文字までが編集可能とのことでした。

解決方法

④のエディターで編集するコンテンツのサイズを65000文字にするために、ファイルを分割することにしました。 CSS, HTML, JavaScript でファイルを分割しても、HTMLの量が多く65000文字で収まらなかったので、
今回は、③のテンプレートを活用することにしました。

デザイン部分だけではなく差込するコンテンツすべてをテンプレートとして作成して ③で選択するようにして
④のエディターで差し込みを一切行わないという形にしました。 そう、テンプレートファイルはエディターで編集しないため、文字数制限にひっかからないのです！

最後に

通常であれば、ランディングページエディターの文字数の制限を気にすることはないでしょう。 もし制限にひっかかってしまったら、テンプレートを活用することを検討してみてください。

こんにちは、Salesforce Saturday 京橋 の運営を行っている チームスピリットの田中 (id:mh-tanaka)です。
2021年末のふりかえり以来、活動をご報告していなかったので
数回にわけて Salesforce Saturday 京橋の活動を報告したいと思います！

2022年の活動

2022年のSalesforce Saturday 京橋の活動は
毎回十数名程度の参加があり計7回実施することができました。
そのうち、最後の2022年12月は京橋初のオフラインで開催しました！

Salesforce Saturday 京橋初のオフライン開催

2022年9月頃からいわゆる「With コロナ」の方針が打ち出され、あらゆる活動の制限が緩和されてきました。
対策をとりながらであれば、私達もオフラインで開催できるのではないかと考えるようになりました。
2022年12月に初めてのオフライン開催を実施することができました！

以下に、当時の対策を書き残しておきたいと思います。

京橋のチームスピリットオフィスを利用する予定で準備を始めました。
利用するスペースに対して募集人数を少なめに設定しました。
また、当日は分散して座れるように机の配置を行い、飲食は決められた場所でとっていただくようにしました。

参加者の方々には「オフラインイベント健康状態申告・誓約書」の記入と提出をお願いしました。 当日の健康状態だけでなく、イベント参加後に新型コロナウィルス感染症を発症した場合は、
速やかに参加者の方から連絡をいただき他の参加者に連絡するため、連絡先も入力いただくようにしました。
また、参加者全員に手指消毒とマスク着用をお願いしました。
(2024年の現在は、申告書の仕組みは廃止しており手指消毒とマスク着用は利用施設の条件に合わせています。)

当日は画面越しでしかお会いしたことがなかった方と直接お会いできたうえに、 Salesforceを学び始めたばかりの方が多く参加してくださり、大変嬉しかったです。
運営側の準備だけでなく、参加者の方々の多大なるご協力をいただき
京橋初のオンライン開催を成功させることができました。
無事に終了した時は、運営メンバー一同ホッと一安心しました。

#13の参加者のみなさん

さいごに

私達は現在も、オンラインオフライン問わず もくもく会を実施しています。
Salesforce Saturday 京橋 のメンバーになると
新しいイベントをオープンした際には通知でわかるので、ぜひご登録ください。
初心者でもベテランでもSalesforceを学びたい方をお待ちしています！

はじめに

こんにちは。QAマネージャーの石原（id:m-ishihara）です。

TeamSpirit Family製品開発チームの紹介記事が本ブログにアップされてから3年近くたちました。

teamspirit.hatenablog.com

2024年3月現在、開発チームのメンバーが増え、チーム構成は大きく変化しています。
そこで今回の記事では、TeamSpirit Family製品開発チームを中心に、最新のミッドマーケット向け製品の開発体制と開発における取り組みについてご紹介します。

Service Development Divisionについて

TeamSpirit Family製品開発チームを紹介する前に、まずは、株式会社チームスピリットの開発部門であるService Development Division（略称：SDD）の現在のチーム構成について説明します。

前回記事の2021年時点では、SDDは製品別に大きく2チームに分かれていました。1つは、エンタープライズ向け製品を開発するTeamSpirit EX製品開発チーム（通称：TEXチーム）、もう1つはミッドマーケット向け製品を開発するTeamSpirit Family製品開発チーム（通称：TSFチーム）です。

現在は、TEXチーム、TSFチーム、そして新たに発足したCustomer Reliability Engineeringチーム（略称：CREチーム）の3チームとなりました。
CREチームは、お客様からの問い合わせを担当するテクニカルサポート、マニュアル作成などを行うライター、アドオン（製品外で動作するオプション機能）の開発を行うエンジニアがTEXチームおよびTSFチームから集結して独立したチームです。

ServiceDevelopmentDivisionの体制

以降では、ミッドマーケット向け製品の開発に携わるチーム（図の赤い点線部分）について説明していきます。

ミッドマーケット向け製品の開発チームについて

ミッドマーケット向け製品の開発には、TSFチームとCREチームの一部のメンバー、合わせて約30名が携わっています。前回記事ではサブチームは3チームでしたが、現在は7チームとなりました。

TSFチームは、新機能開発チーム1、新機能開発チーム2、品質改善チーム、勤怠計算リファクタリングチーム、リグレッションテストチームの5つのサブチーム、CREチームはテクニカルサポートチーム、CRE開発チームの2つのサブチームに分かれて活動しています。

ちなみにTSFチームは、組織図上はProduct Management（PM）チーム、エンジニアチーム、QAチームと職種別に分かれていますが、実際の開発に携わるサブチームは職種別のチームを横断したスクラムチームとなっています。

TeamSpirit Family製品の開発チーム体制

各サブチームの役割

ここで、各サブチームの役割を簡単にご紹介します。

新機能開発チーム1、新機能開発チーム2
経費精算やモバイル機能などの新機能の開発を担当するサブチームです。スクラム開発を行っています。

品質改善チーム
勤怠管理や休暇管理などに関する機能改善や品質改善を担当するサブチームです。スクラム開発を行っています。

勤怠計算リファクタリングチーム
勤怠計算機能のリファクタリングを担当するサブチームです。
勤怠計算リファクタリングについては別の記事で紹介していますので、よろしければ合わせて読んでいただけるとうれしいです。

teamspirit.hatenablog.com

リグレッションテストチーム
QAエンジニアのみで構成されているサブチームです。リグレッションテストの実行やメンテナンスの他、他チームのサポートなども担当します。

CRE開発チーム
CREチームに所属するソフトウェアエンジニアで構成されているサブチームです。製品外部で動作するアドオン機能の開発や、お客様向けサポートサイトであるTS Circleのメンテナンスなどを担当しています。

テクニカルサポートチーム
CREチームに所属するテクニカルサポートで構成されているサブチームです。ミッドマーケット向け製品を利用するお客様からの問い合わせの解決を行っています。

CRE開発チーム、テクニカルサポートチームの変遷や活動については note の記事で紹介していますので、よろしければ合わせて読んでいただけるとうれしいです。

note.com

note.com

note.com

サブチームの人数はおおむね2〜6名です（一部のチームは協力会社の方にも参画いただいています）。
スクラム開発を行っているチームにはスクラムマスターがいます。なお、スクラムマスターは専任ではなく、ソフトウェアエンジニアやQAエンジニアが兼任しています。

ミッドマーケット向け製品開発における最近の取り組み

ここからは、ミッドマーケット向け製品開発において、最近取り組んでいることのうち大きなものを2つご紹介します。

リグレッションテストチームの新設

1つ目は、前述のリグレッションテストチームを新設したことです。

ミッドマーケット向け製品はローンチしてから10年以上たっています。継続的に開発していると、リグレッションテストはどんどん増大していきますが、テストの整備が追いつかず手薄になるところも出てきました。そこで、戦略的にリグレッションテストを実施する、そのための基盤を整備するために、チームを新設して集中的に取り組むことにしました。

リグレッションテストチームは、チームトポロジーにおけるプラットフォームチームを目指しています。各サブチームが新しい機能の開発に専念できるようにすることがミッションです。

リグレッションテストの実施やメンテナンスだけでなく、スクラム開発を行っているチームやQAエンジニアが不在のチームがスムーズに開発を進めることができるように、QA作業のサポートやテストに関するお悩み解決の伴走もしています。

リリーストレインの導入

2つ目は、リリーストレインを導入したことです。

リリーストレインは、書籍『エッセンシャルスクラム』（Kenneth S.Rubin 著、岡澤 裕二 訳、翔泳社、P.209）では以下のように説明されています。

リリーストレインは、ビジョンやプランニング、そして複数チーム間の依存関係などの調整をするための手法のひとつで、各チームの歩調を揃えて、チーム間での同調ができるようにするものだ。

「トレイン」という言葉のとおり列車のメタファーで、あらかじめ時刻表（リリーススケジュール）が決まっており、時刻表に従ってサブチーム間で同期を取りながらタイミングを合わせてリリースを行います。
列車の発車時刻（リリース日）までに貨物を列車に載せ（機能をリリースできる状態にする）、発車時刻定刻になれば列車は出発します（機能をリリースする）。もし乗り遅れた（間に合わなかった）場合は、列車を遅らせる（リリース日を遅らせる）ことはしません。次の列車がいつ出発するかはわかっているので、次の列車を待ちます（次回のリリース日にリリースできるようにする）。

パッチリリースの頻度を上げるチームが出てきたことがきっかけで、調整コストやトラブルを減らすために導入することになりました。 現在、運用を行いながら、ルールのブラッシュアップを行っています。

最後に

最後までお読みいただきありがとうございました。
いかがでしたでしょうか。
記事を書いてみて、3年前と比べて組織の大きさもカタチもだいぶ変わったなとあらためて感じました。
今後も変化があったときには、このブログでご紹介していければと思います。

チームスピリットでは、一緒に働く仲間を募集しています。
ご興味を持ってくださった方がいらっしゃいましたら、ぜひ弊社の採用サイトからお問い合わせください。recruit.teamspirit.com

Mac から Windows へ乗り換えました！

皆さんこんにちは。Joeです。 この度 3年ぶりに開発端末を Mac から Windows に乗り換える事にしましたので その時の感想を記載したいと思います。

この投稿はチームスピリット Advent Calendar 2023 - Adventar の3日目の投稿になります。

なぜ Windows か？

これまでの約3年間、自分は開発端末としてMacを利用していました。 当時は WSL がまだ未検証で 開発では Mac の方が Bash が使える事や HomeBrew で簡単に依存ライブラリをインストールできるなどのメリットがあったため、「開発には Mac」という感覚がありました。

しかし実際のお客様の環境はほとんどが Windows 環境であり、 Windows を利用していた方がお客様の環境に近い状態で確認する事ができるメリットがあります。

これまで公式のWindows上で Bash を利用できる環境はありませんでしたが、 WSL(Windows上でLinuxを動かす仕組みの事です) が安定して稼働していることをきっかけに端末の更新時に思い切って Windows 端末に変更をお願いする事にしました。

Windows への移行

Mac端末から Windows 端末への開発環境の移行はスムーズに行う事が出来ました。 wsl を有効化すれば、後は Ubuntu 上で環境構築を行う事ができるので後はUbuntuの apt-get コマンドを利用して必要なライブラリをインストールできました。 最後に開発で利用している vscode の設定ファイルを移行してサクッと完成させる事ができます。

Mac 時代に作成したシェルスクリプトも難なく動作し、 今では Mac と遜色なく動作するようになりました。 キーボード・マウスも以前利用していた私物の物をそのまま利用できるので開発環境の移行はそれほど困難ではありませんでした。

乗り換えた結果

良かった事

最大のメリットはなんと言っても Windows 環境でプロダクトの確認を行う事ができる点です。 特にスクロールバーや選択ボックスといったOSのデザインに依存する要素は Mac で確認するのは困難を極めました。 Windowsではスクロールバーが常に表示されるので、 Macで開発してWindows 環境で動作させると、 「あれ？デザインが崩れている」と言った事がしばしばありました。 Windows 環境なら最初からWindowsで確認できるので、 デザインがどうなっているかを開発段階の初期から確認する事ができます。

次点として、 Mac と比較すると 性能が高い物を利用する事ができる事です。 この部分については詳細はお話できないのですが、以前よりも快適に開発ができるようになりました。 (もちろんMacでも問題はありませんよ！)

良くなかった事

一つは vscode について、一部の拡張機能は利用できないものがあります。(特にアトラシアンの拡張機能など) これについては WSL が Windows 内部の仮想環境で動いている事に起因するものでvscodeでアカウントにログインできない等の問題が発生する事があります。

二つ目は npm のビルドがまれに OOM killer によってキャンセルされてしまう問題が発生しました。 恐らくなのですが、 ubuntu だと npm でフルコンパイルを行うライブラリがあるのかもしれません。 npm の OS 差異によるライブラリは注意した方が良いと思います。

まとめ

まとめとして チームスピリットでは Win / Mac 両方で開発する事ができ、 私のように Mac -> Win に移行した場合でも同じように開発を行う事が可能です！

タイトル：Salesforce組織がたくさんあってブラウザのタブが迷子になる

こんにちは、この9月から新規事業推進室に異動になった倉谷 (id:a-kura) です。

今年も技術系アドベントカレンダーの季節ですね。最近アウトプットできていないので、年に1度でもこういった機会があるのは良いですね。

はじめに

さて、皆さんは複数のスクラッチ組織や本番組織で並行して作業することはありませんか？

ソースコードをデプロイして開発しているスクラッチ組織
パッケージをインストールしてパッケージのテストをしているスクラッチ組織
QAエンジニアやプロダクトマネージャーに渡すためのスクラッチ組織
そして、普段使っている本番組織など開発するためには多くのスクラッチ組織に接続しながら作業することがあります。

その際に、どのブラウザのウィンドウやタブがどのSalesforce組織に接続されたものなのか分からなくなってしまいます。

そこで、どのSalesforceに接続されたブラウザのタブなのか整理しやすくするためのTipsを紹介します。

目次

続きを読む