アーカイブ動画

■登壇者プロフィール

株式会社JSOL　飯田 博記氏
JSOL認定プロフェッショナル ITアーキテクト
Salesforce認定 システムアーキテクト・アプリケーションアーキテクト

全社横断型で状況に柔軟に対応できるITシステムが求められている

今回登壇した飯田氏はSalesforce歴7年、Salesforce認定資格を15個取得しており、コミュニティグループリーダーも務めるJSOL認定プロフェッショナル ITアーキテクトである。その活躍は、Salesforce版A-gate®の導入事例を紹介するマンガに登場していることからも伺える。

飯田氏は1999年にJSOL（当時は日本総合研究所）に入社以来、製造・流通・サービス等のドメインにおいて、コンサルティングからシステム開発まで一連の業務を経験してきた。社内業務についても、コーポレートICTから、顧客接点となるビジネスICTまで幅広く携わってきたという。

「スクラッチ開発の時代から、SaaSのクラウドサービスを活用したシステムやアプリケーション開発まで、さまざまな業務や開発案件を担当してきました。特に最近では、DXやコロナ禍対応を求められることが多くなり、事業部単体のシステムではなく、全社を横断したデータ活用や、状況に応じて改変できる柔軟性などが求められていると感じています」（飯田氏）

技術やシステムの仕組みをしっかりと理解することが大事

続いて飯田氏は、スクラッチ開発でシステムやアプリケーションを構築していたSE時代から、20年以上に渡って大切にしてきたことを、実務と照らし合わせながら説明した。

スクラッチ開発の全盛時、飯田氏の得意領域はデータベース（以下、DB）領域であり、多くのDBパフォーマンスチューニングや、原因不明のトラブルシューティングなどを経験してきた。

例えば、設計・開発段階では問題はなかったのに、テストを行うと大量データをSQLクエリで検索する際に時間がかかり、思ったようなパフォーマンスが得られないこともあった。

「CPU・メモリの不足を疑うなど、場当たり的な対策をしがちですが、対応を誤るとさらに状況が悪くなるので注意が必要です」（飯田氏）

システムの中ではどのような動きがあり、何が起こっているために遅いのか。飯田氏は、「一つひとつ原因を紐解いていくことが大事であり、事実と仮説（推測）を混ぜないことが重要」だと補足した。

そして事実を確認し、なぜパフォーマンスが発揮されていないかを理解するには、技術やシステムの仕組みを知ることが必要だ。この事例であれば、DBやシステムに関する知識やロジックである。

実際に、DBからレコードを取得する仕組みも紹介された。以下のように、クエリが出されると、多くのデータ構造をたどり、目的のレコードに達している。データが挿入・更新されるたびにインデックスはメンテナンスされていることがわかる。

このように、「技術やシステムの背景を知った上でログを見ると、なぜ遅かったのかが理解できる」と飯田氏。スライドの右図のように、たくさんのブロックを読んでいるシステム構造となっているために、遅いことが見えてくるのである。

やみくもにインデックスを作っても事態は解決せず、そればかりか効果のないインデックスはコストがかかる。場合によってはデータをフルスキャンした方がパフォーマンスが良いケースもある。飯田氏は、技術やシステムの背景をしっかりと理解することが重要だと強調する。

「DBベンダーからはハッシュインデックスなど、さまざまな機能が提供されていますが、システムの仕組みを知った上で導入することで、結果としてパフォーマンスの向上が実現します。言い方を変えれば、やみくもに機能を追加しただけではパフォーマンスが向上するどころか、逆効果になる場合もあるのです」（飯田氏）

スクラッチ開発からSalesforceの利用へ

「DBの仕組みは今でも変わらず重要」と前置きしつつも、時代の変化に伴い、飯田氏が注力・活躍する領域も変化していった。2010年頃からは仮想化技術やソリューションを採用するようになり、2015年からは全世界で15万以上の企業が導入するCRM（顧客管理）プラットフォーム、Salesforceとの関わりが中心となってきた。

Salesforceを利用することで、従来注力していたハード・ミドルウェアといった基盤領域は、Salesforceのプラットフォームに任せるとの考えにシフトしていく。一方で、顧客独自のアプリケーション開発に注力するようになっていった。

Salesforceの主なSaaS・PaaS機能も紹介された。ベース層へのログインやAPI連携など、プラットフォーム標準機能を備え、その上に、商談管理やナレッジの共有といった各種アプリケーションが機能として用意されている。

さらにはノーコード・ローコードで顧客自身が、ページレイアウトなどを変更できるカスタム機能も有する。よりカスタマイズしたい場合には、JavaScriptを使った独自のアプリケーション開発を行うことができる。

スクラッチ開発とSalesforceを利用した開発の違い

次に飯田氏は、紙であった日報を電子化するアプリケーションにおいて、従来のスクラッチ開発とSalesforceによる開発の違いを紹介した。

一般的なWeb開発におけるスクラッチ開発であれば、要求事項にあったフレームワークやライブラリを選定して設定する。さらにDBの設計や実装をした上で、アプリケーションを開発する必要がある。

対してSalesforceによる開発であれば、要件事項を定義する業務は変わらないが、フレームワークの選定や設定、DBの設計、アプリケーションの開発といった業務がなくなる。SalesforceのPaaS・SaaS上に用意されているからだ。

そのため開発者が行うことは設定のみとなり、ノーコードによる開発も可能となる。スクラッチ開発における必要領域と比べると業務量の改善は歴然である。

「開発現場において、フレームワークの選定は難しい業務です。さらには導入したら終わりではなく、バージョンアップの管理や脆弱性対応などの後業務も発生します。一方、Salesforceであれば選定はもちろん、その後の管理業務もありません」（飯田氏）

Salesforceはプラットフォームでアクセス権限管理が行える機能、「マルチテナントアーキテクチャ」という機構を持つため、アクセス権限機構を開発する必要がないのだ。

続いては利便性を考え、モバイルでの使用、ID・パスワードの入力省略化といった機能を追加する事例だ。一般的なアプリ開発の場合は、SAMLやレスポンシブル対応といった機能を組み込む必要があるが、Salesforceであれば既に同機能を備えているので、有効化して設定すればいい。

このようにSalesforceを利用すれば、開発スピードが早くなるというメリットがある。一方で、エンジニアに求められているのはSalesforceを使った開発スピードや利便性だけなのか、改めて考えてもらいたいと、飯田氏は語りかける。

「私たちがシステムやアプリケーションを開発する真の目的は、お客様のビジネスの成功です。顧客のビジネスを成功させるためには、日報共有アプリ開発の先のステップが必要なのです」（飯田氏）

マルチテナントアーキテクチャを理解する

Salesforceしかり、世にあるSaaS・PaaSの多くは、誰でも使える優れた標準機能を有している。だがその一方で、利用する際には注意が必要なこともある。飯田氏は、マルチテナントアーキテクチャを例に挙げて説明した。

マルチテナントアーキテクチャとは、複数ユーザーが共通のシステムやプラットフォームを利用する仕組み。物理的に説明すればハードウェアやサーバーを共有するとも言える。

そのため、特定の利用者がアーキテクチャを独占しないよう、さまざまな制約が設けられている。その一つが、トランザクションあたりのクエリ合計数を制限する、ガバナ制限である。飯田氏は、制約における見解を次のように語っている。

「利用者によってはガバナ制限があるために開発しづらい、自由が制限される、データの転送速度が遅いなど。制約を悪者に捉えている場合もあるようですが、私はそうは思いません」（飯田氏）

というのも、制約があるからこそ従業員数十人の中小企業でも、エンタープライズ企業と同等のプラットフォームを使えるからだという。加えて、制約は事前に示されており、オーバーヘッドなどのトラブルを回避・改善するナレッジも提供されている。

つまり開発担当者は、「事前にどのような制限があるのか」「どうすればトラブルを回避できるのか」を開発段階で把握し、テストしておくことが重要だと述べた。

飯田氏は、SIerにおいて必要なシステム思考とは、個々の機能や仕組みを理解すること。加えて、全体のシステムや機能が提供された背景にも目を向けることが重要だと語っている。そして、「顧客のビジネスの成功が最も優先すべきことであり、開発したシステムやアプリで何を成すかが重要だ」と、総括した。

そして、Salesforceなどのサービスを開発者が正しく使う責任をしっかりと意識・理解することも大切だと加えた。セキュリティ機能などにおいては使い方を間違えてしまうと、最悪、情報漏洩の危険性があるからだ。

機能追加などのバージョンアップへの対応も重要であり、Salesforceであれば年に3度行われており、その際のリリースノートをじっくりと確認することが求められる。

飯田氏自身、常にSalesforceについての学習を継続しており、数々の資格を取得。現在は日本で17名しかいない最上位資格である認定テクニカルアーキテクト、通称「CTA」を目指し研鑽中とのこと。

現在、Salesforceエンジニアである人はもちろん、これから目指そうと考えている人に「コミュニティなどを通じて共に学びましょう」と熱い言葉を投げ、セッションを締めた。

【Q＆A】参加者からの質問に答えるセッション

視聴者からの質問に答えるQ＆Aセッションも設けられた。その一部を紹介する。

Q．SaaSに限らず、インフラよりアプリケーション領域のスキルを持つエンジニアニーズが高まっているのでは？

Salesforceであれば、コンサルタントやデベロッパー領域で活躍する人が多い印象です。ただし、セキュリティやアクセス権限、データまわりなど、インフラに関する知識が必要であり、実際に知識を持つメンバーが一定数必要です。そのため視点を変えれば、インフラ知識を持っている人が活躍できる環境でもあり、求められているとも言えます。

Q．インフラエンジニアにとって、Salesforceのキャリアを選択することのデメリットとは

私自身もインフラ出身ですが、デメリットや不安は特に感じていません。Salesforceに関わる利用者やパートナーのコミュニティの広がりが大きいからです。

Salesforceエンジニアには、ビジネス領域・アプリケーション領域についての理解も求められ、自身の視野が広がりました。また、インフラ領域の専門性はSalesforceでも活きると考えています。

Q．Salesforceが苦手とする業務や機能

私はコーポレート、ビジネスどちらのシステムやアプリケーションも開発していますが、顧客接点となるビジネスICTのほうが、向いていると感じます。というのも年に3度バージョンアップがあり、ビジネスの実情にも合っているように思います。一方のコーポレートICTは仕様通りに正しく機能することが重要です。

また、システム的観点から見ると、大型のストレージなどで備えているバックアップ機能がありません。具体的には、ロールバックやスナップショットといった機能です。そのため、夜間バッチ処理などは十分に考慮することが必要でしょう。

Q．CTA取得に向けたアドバイスがほしい

試験の内容は受験ガイドに公開されています。受験ガイドによると、Salesforceに関する十分な知識はもちろん、なぜこの機能を使うのか、なぜ選択したのかといった観点がポイントのようです。コミュニティではCTAの方も参加していることがありますので、実際に話を聞いてみるのもいいと思います。

Q．Salesforceエンジニアに向いているタイプとは？

コンサルタント、デベロッパーなど、さまざまなロールで活躍できるので、どんなタイプでも活躍できる場はあると思います。あえて挙げるとすれば、継続的に進化していくプラットフォームに対して、柔軟に対応できるタイプが向いていると思います。

Q．関係各所から要望があがる中、本当に必要なものを見極め開発をしていくため心がけていること

なぜ必要なのかを何度も繰り返し聞くことを意識しています。つまり、対話コミュニケーションを重ねることで、最終的な解決策にお客様自身が気づくことが多いと、これまでの経験から感じています。

株式会社JSOL
https://www.jsol.co.jp/

株式会社JSOLの採用情報
https://career-jsol-recruit.com/