contact

弊社がご提供している、MOMサービス「トランジット」の特徴は、作業の「鋳型」への流し込みと、その状況の逐次「可視化」だ。

そしてこれら作業は「ヒト」によって行われる。だから「作業」を無機質なものとして見てはいけない。完璧にビルドされた信頼感あるチームのもと「鋳型作業」が動けば、組織に計り知れないマーケティング効果をもたらす。これがトランジットの主張だ。

この記事では、この「チームビルドがなされていく状況の逐次可視化」ついて、その方法論を紐解くことにする。

 

新しいマーケティングツールが次々に登場し、マーケターは多くの事ができるようになった。ただし選択肢は増えたがマーケターがラクになったかというと、必ずしもそうではない。

多くの事ができるになったものの、自らやらなければならない事もふえてきている。特にデジタルマーケティングの領域において「営業をサポート」したり営業に適切な「リードを渡す」ため、ヒトの手で行わなければならないことがある。

それが「顧客とのコミュニケーション」をデザインすること。顧客との筋の通った仮説シナリオをコンテンツへと落とし込む一連の作業のことだ。これを着実に行えば大きな成果が目の前に見えているのだ。MOMで緻密なオペレーションを実践していこう。

明日から、あなたが責任者です

マーケティング・オペレーションというと何となく「まあ、こんなものかな。」といったイメージを浮かべやすい。

ところが、「明日から、あなたがプロジェクトを率いてやって下さい」という立場になったらどうだろう。業務の流れについては「大まかには想像できる」ものの、今、自分の組織内でやろうとすると結構手こずるのではないだろうか。

特に「誰が」、「いつ」、「どのようにして」、「何をする」という「作業の鋳型」の準備にかなり手こずることが予想される。

この「手こずり」について、トランジットでは業務フローの「鋳型」並びにその鋳型を動かす「原動力」の２つが両輪となっていることが原因と考えている。

前者が自社の作業工程の足場を確立させるもの。この「鋳型」だけで良さそうなのだが、実はこれでは不十分なのだ。それは何か。それが「チームビルディング」なのである。

確かに作業をするわけだから、「作業用の足場」業務フローの「鋳型」をつくることは必要だ。マーケティング・コンテンツの企画原案から書き起こし、デザインディレクション、納品管理、MA格納・設定に至るまでの一貫した工程がきちんと整備されている事は「業務」を回すためには不可欠だからだ。

しかし、これらの工程はそこにいるメンバーの「モチベーション」から成り立っていることを忘れてはならない。

どうして、「とにかくチームビルディング」なのか。

それは「関係者と友好関係を築くと、うまくいくから」
チームビルドを強調する理由は、たったこれだけだ。では一体なぜ、「うまくいく」必要があるのだろうか。

デジタルマーケティングは自社のサービス・製品に対する深い洞察が必要だ。
一見すると小さなアイデアだが、それが時として営業が顧客を説得するにあたり有効なキーワードとなり得る。そして、そのネタは現場が持っていることが多い。こういった重要なアイデアの吸い上げ。それが「うまくいく」ために、関係者と友好な関係を築かなければならない。これが理由だ。

このようにチームの協力によって現場からの有効な意見が吸い上げられなくなれば、いくら工程を確立したところで、効果は半減していく。

共通の目的や目標を共有する「チームビルディング」によって初めて業務がスムーズに回る効果が得られることを肝に銘じよう。
「工程（鋳型）の確立」とチームビルディング実現のための「逐次可視化」マネジメント、ここでもトランジットの両輪が必要ということがわかるだろう。

目に見えて何が変わるのか。

チームビルディングによって組織の集中力というべきものが身につき、また集中力によって作業が高速化していく。この一連の作業の高速化は何をもたらすだろうか。

１：打率の上昇

そもそもマーケティングにおいては、コンテンツ（資産）が「当たる」とか「外れる」という議論を抜きに語ることはできない。

これを単純な確率の問題として捉えてみよう。「ある１つの商品に対して考えられる「マーケティング施策」が１０通りあり、そのうち１つが『あたる』」としよう。すると１つ目の施策は「同様に確からしい」ため９０％の確率で外してしまう。＝マーケティングはうまくいかない。しかし、もし３通りの施策を実施した場合、「全てがハズレ」てしまう確率は、７２．９％にまで下げられる。

このとき、３つの施策が全てあたる確率を考慮すれば、少なくとも一つの施策があたる打率は、２割７分９厘にまで上昇する。もし３施策を５施策へと増やせば、打率は４割６分８厘を超えて上昇していくのだ。

この真理を拒む理由はない。ところが、

「ウチのやり方（施策）は、変えないで、このままいきます！」
「キャンペーンのたびにランディングページをコピーできれば十分ですので。」
という企業も多い。

このように思う事は、もちろん自由だ。
だが、さまざまな他の施策を試す事で『あたる確率を上げる』事は可能なのだ。

そのための手段が、MOMによる「作業高速化」
やらない手はない。これが1点目だ。

２：慣れによる精度向上

次に精度の向上について。

PDCAの「回転数」を確保できればひとまず安心だ。これによって一連の作業への「慣れ」が生じる。「慣れ」が生じると、メンバーに気持ちの余裕が生じる。余裕が生じれば、制作途中で「もしかして、これが『あたる』のでは？」といった、「カン」が冴えるようになってくる。

これは上記でいう「１０回に１回は当たる」というあたる確率を上げるこそすれ、下げるようなことには決してならない。

かくして「打率」が加速度的に上昇していく。

まとめ（なにが変わるか）

「作業の鋳型を作り、そこに流し込む。そして慣れてきたら速度を速める。」
→「打率がアップ（良質化）する」

これら２つの相乗的な効果として、マーケティング資産が良質化する。ここがポイントだ。

かくしてMOMを通じマーケティング資産の品質は、飛躍的に向上していく。

Q: ここで新たな疑問が湧きだす

チームビルドするために、なんらかの「モチベーション」が必要だと思うのですが？

 

モチベーションアップの方法：「すぐに効く薬」はない

ご推察の通り、自社のチームをモチベートさせなければ、チームビルディングはうまく完成しない。そして、モチベートさせる「万能」の方法論は存在しない。

しかしモチベーションアップについて、幾つかの方法は存在している。これらを自社に合わせて組み合わせていく必要があるだろう。

これらモチベーションの向上施策については第３弾の記事にて「ABC(Activity Based Costing)を用いた管理会計施策」として詳しく述べることとする。

 

チームビルドがなされていく状況を逐次可視化・マネジメントしていく

十分にモチベートされた組織において、オペレーションを回すことができたら、MOMによって行うのは「チームビルディングの状況を可視化」すること。

その前に、そもそもMOMとはどんなプロセスでデータを計測するのか、俯瞰してみることにしよう。

＜MOMのプロセス＞
    1. 　１．用意された業務フロー（鋳型）に沿って作業し、作業データを計測する

 

    1. 　２．データの加工を行い、作業マネジメントに必要な計数を見える化する

 

    1. 　３．時間が見える化するため（各人の単価が把握できれば）コスト計算を見える化する

 

    1. 　４．コストパフォーマンスを見ながら「内製か外注か」の等の選択を行える

 

単語が示す通り、MOMは「鋳型に沿った作業」の「データを取る行為」だ。
つまり、１が「鋳型」で行う作業そのものであり、２〜４がオペレーション改善のための取り出したいデータだ、ということとなる。
そして、いま「チームビルディングが確立する様子」を示す、取り出したいデータは、次の通りだ。

取り出すデータ１：PDCAを回しているかをみる

一番目は、「チームビルディングの状況を見える化」するため一定期間ごと（ここでは１ヶ月）のPDCA作業の総時間をメジャー（測定）したデータだ。

【一ヶ月のPDCA全ての作業の時間を足し合わせた「述べ時間」】

取り出すデータ２：自主的なアイデアを出しているかをみる

二番目は、「チームビルディングの状況を見える化」するため一定期間ごと（ここでは１ヶ月）の「自発的な」発案率を計算している。
社内内部の誰かが自ら気づき、「発案」した件数が全体に占める率だ。

【うち、現場からのアイデアを評価し、掛け目とする】

さいごに「掛け合わせる」

さいごに、それら２つを掛け合わせた数値をメジャーする。

【これを縦軸の数値、時間を横軸でグラフ化】

すると、時系列で次のようなグラフが完成していく。

【チームビルディング確立状況推移グラフ】

上図は、計測期間１年程度の結果データだ。徐々に内部からの発案率が上がって、チームビルディングが完成したことで、さらに議論が活発化し、PDCA作業が進んでいく様子が見ることができる。

本記事では、チームビルディングに焦点を当てて取得したデータの推移をることで、その「構築されていく様子」が可視化できることがわかった。

MOMで実施する「マーケティング資産づくりのオペレーション」は、ホワイトカラーの業務で効率的に行うことができる作業の最たる例だ。
「オペレーションをメジャーする」ことで議論を活発化させ、マーケティングオペレーションを円滑に進めていこう。

第三弾をお楽しみに。

MOMは業務フローにマネジメントの概念を取り入れたものだ。業務を確立することと、その業務を管理・マネジメントすること。これら２つを両輪としたものがMOMだ。シリーズ初回となるこの記事では、MOM（マーケティング・オペレーション・マネジメント）は何か について述べていく。同時にメリットは何かについても紐解いていこう。足元のオペレーションをマネジメントするマーケティング・オペレーション・マネジメント（”MOM”　英：Marketing Operations Management ）とは何なのだろうか。 

 

オペレーションマネジメントは日本のお家芸

あなたは昨日の仕事の流れを思い返せるだろうか。

仕事の流れは「確立した作業の型」に沿って行われる作業と「その進行度合いを常時確認する」作業で成り立っている。

「型は確かにあるが、監視などされていない」と思う方がいたとしたら、それは「to do 」を頭の中で管理しているだけで、やはり同じことをしている。

MOMも同じだ。マーケティング作業という一見曖昧と思える作業にも、確立した型に沿った作業の流れがある。そしてその流れを適切に管理することで、マーケティング効果は高まっていく。

この原則はほとんどすべての仕事に当てはまるであろう。
例えば工場の自動化を推進するファクトリーオートメーション然り。導入企業がオペレーションマネジメントを実践することで、業務の型の確立と効率を高めている。

作業フローの確立と、それを管理対象としてさらに作業を効率化するオペレーションマネジメント。この手法は本来、日本のお家芸なのである。

MOMの目的

オペレーションマネジメントの最初の目標は、作業を「難なく・自然に」できるようにすること。それはあたかも自転車が補助輪なく乗れるようになるのと同じだ。しかしこれだけでは済まないということは、わかっているだろう。マネジメントの対象とするからにはあなたは「自転車に乗れるようになる」だけでは不十分なのである。

自転車の話の延長で考えよう。あなたは自転車に乗れるようになるだけでは不十分でその先、例えばトライアスロンに出る、だったりセミプロの競輪選手になる、など「あなたが決めた目的」を設定することが求められる。

マーケティング・オペレーション・マネジメント(MOM)導入の目的も同じだ。MOM導入企業の最大の目的は「コンテンツディレクション力」のインハウス化。内製化のチカラをつけることだ。数々のオペレーションにかかるタスクを自社で作ったり、スキル配分の能力を向上が目的となるはずだ。

これを実現することによって、組織はマーケティング効果の極大化に向けて走りはじめる。

配分
【MOM最大の目的はスキルセットを自在に配分し「コンテンツディレクション力」をインハウス化すること】

さて、ここで混同されがちなのが「マーケティングの成功（成果が出ること）」と「MOMの成功（オペレーションが軌道に乗ること）」の違い。これらは強い関連性があるが、別物である。

先ほどの自転車の例で類比させて説明しよう。トライアスロンの訓練をルーティン化する事（「訓練への取り組み」に成功すること）と、トライアスロンでいい成績をとること、は全く違うことだけど強い因果関係がある、というふうに言えばわかりやすいかもしれない。

ただ、MOMは「自然に作業が流れる事」をもって初めて「軌道に乗った」といえるのだが、業務が流れ始めたらそれが完了か、というとそうではない。以下に掲げるとおりMOMのメリットを実現するため、飽くなき追求を実践しなければならないのである。

 

MOM３つのメリット：
  • 個々人が「作業」内容が明確だと思う
  • チーム（組織）として組織の成果に寄与できるようになっている
  • 予算算出のため、論理的な基礎データを提供できるようになっている

    •  

    なぜやるのか＝訓練のやりかたで成果が左右されるから。

    ここまでくれば、マーケティング業務をマネジメント対象とする理由は明白だろう。
    日頃の訓練のやり方がまずければ、トライアスロンでの成績がおぼつかなくなるのと同じことだからだ。

    日常業務におけるマーケティング作業、つまり業務フローのこなしかたがマズければ、「成果」は悪い方に大きく傾く。この点に気づくか、否か。これがデジタル営業を推進しようとしている組織にとって、大きな判断の分かれ目となる。

    「確立した作業の型」に沿って行われる作業と「その進行度合いを常時確認する」作業で成り立つMOMを実践すべき理由はたったひとつ。これだけだったのだ。

    では、なぜ業務をメジャー（測定）するのか

    MOMの実践が有益であり、また必要だとわかった。ところが後述する通り、次に「スキル毎のタスク管理」と同時に「タスクのメジャー（測定）」が必要という。これはなぜだろうか。

    競輪選手になる、トライアスロンで成果を出す。目的が違えばメジャー（すべき）対象も少しづつ違ってくる。

    筋力・睡眠・歩数・・いまやトレーニングメニューにおいて周辺データをメジャー（測定）するのは当たり前になっている。ではなぜあなたはそれらをメジャー（測定）しているのか？それは、「達成度に応じて機動的にトレーニング方法を変えた方が、早く目標に近づく」からだ。

    MOMにおいても同様だ。「業務そのもの」に着目し業務そのものをメジャー（測定）するMOMは「コンテンツディレクション力」のインハウス化という目的があるからだ。データを機動的に分析しながら、やり方を微修正しつつ最短時間で達成する。これを目指さなければならない。

    そこで、何をメジャー（測定）するかがカギとなる。「スキルに分解したタスク」。これをデータとしてどのように取り出し、どのように加工・活用するべきなのだろうか。

    以下、オペレーションの型に沿った流れ、ならびに進行度合いの常時確認について紹介していこう。

    オペレーションプロセスのやりかた：スキル分解がポイント

    背景：外注力（コンテンツディレクション力）がなぜ必要なのか

    まず、近年のデジタルマーケティングを取り巻く背景について考えてみよう。
    例えばクラウドソーシング。クラウドソーシングは今日に至るまで多彩でぶ厚いリソースに支えられ、日本における専門家のリソース調達市場というものを拡大してきた。

    このスキルセット、手を伸ばせばすぐに入手できそうだ。ところが実は「きちんと要件定義してディレクションできること」が要件となっていることを忘れてはならない。

    どういうことか。それは例えばあなたの組織が販売対象とするプロダクト・サービスが「営業を介して販売する」という場合において顕著に現れる。外部のクリエイターにいきなり「丸投げ」しても、良いアウトプットは得られないのだ。

    組織には適切な「外注力（コンテンツディレクション力）」を備えることが求められる。ディレクション力が高められれば、リソースを使う自由度が格段に高まるからである。

    実践プロセス１：タスクチャート

    MOMの実践に、何か特別なことがあるわけではない。一般的なプロジェクトと同じで、プロジェクトマネジャーがタスクチャートを描くところから始まる。

    「誰に何のタスクを消化していただくか」を決めていく作業だ。タスクについては「一人で処理できる粒度のタスク」「最低限の時間でアウトプットが出る粒度のタスク」などの取り決めをしながら調整して進めていくとうまく行きやすい。

    実践プロセス２：タスクをスキル別に分類

    次にこれらのタスクをスキルごとに幾つかの種類に分解し、ラベルをつけていく。たとえば、

  • クリエイティブスキル）アウトプットの質に評価の重点を置かれるスキル
  • 企画スキル）直接的なアウトプットの形がない企画力が評価されるスキル

    • など。

    配分
    【モザイク図】

    これらタスクを実践することでえられるデータをもとに作成した管理資料の一つが上記だ。横串に必要なスキル、縦の串が作業者または作業したエンティティを示している。

    横串：スキルセット
  • （スキルセット１）今の自社内で対応できるスキル
  • （スキルセット２）今後もどうにもできないスキル（例えば「絵を描く」など）
  • （スキルセット３）今はできないが、今後内製できそうなスキルセット
    • 縦串：作業担当
  • 自社（企画）→今後増やす
  • 外部（企画）→今後減らす
  • 外部（クリエイティブ）

    • このように、想定される「タスク・ワークの塊」を縦横を輪切りにすると様々なことが見えてくる。クリエイティブをアウトプットするデザイナーなどを「社内」に保持している会社はあまり多くないだろう。

    したがって縦串は３種というケースが多いはずだ。このようにスキルを分けて管理すれば、自社のリソースでさえどれくらいの時間を割いてこの作業に打ち込んだかが見えてくる。

     

    実例（模式図）

    【実際のモザイクシート（模式図）】

    以上のオペレーションに結果、上記のようなモザイクシート（模式図）が出来上がる。

    わかること：
  • 得意領域としているスキルセットが誰であるのかを管理できる
  • 正確な事務コストを算出・管理できる

    • これらのデータはリアルタイムに判明していくため、BI (Einstein Analyticsなど)で統合表示し、マネジメント層が管理していくことが可能だ。これらのデータを活用した管理会計施策の詳細は、第３弾にて案内していく。

     

    第一弾まとめ

    以上、第一弾「リソース配分」についてお伝えした。MOMにジョインしたチーム・メンバーの得意分野が明るみに出てくるのが興味深い。

    MAの持つ機能が自社の営業・マーケティングにとって価値の高いものであることを理解したご担当者であれば誰もがこの「足元のオペレーション」そのものをマネジメント対象にすることで解決へと導く方法を試すことができる。

    MOMの有用性を感じていただき、早速自社でもMOMへの取組みを始めてみよう。

    では、第二弾をお楽しみに。

    業種 官公庁
    業務・サービス Salesforce(Force.com)
    目的 短時間で作成する必要のある文書を、複数の担当者が編集する中で、漏れ、誤りなく、効率的に作成できるようにする。
    概要 Salesforce上で関係者が文書を作成し、更新された内容の差分を確認の上、内容をマージするとともに、最終版をword出力する。
    機能 【文書作成・編集機能】
    　wordに出力する文書の登録、各担当者での添削・修正。
    【作成文書の差分表示】
    　添削・修正内容の差分色分け表示。
    【word出力】
    　完成した文書のword出力（heroku経由）。
    特徴 拠点問わずどこからでも文書の作成・修正ができ、かつ、修正者単位での差分確認が可能に。
    構成 官公庁向け業務支援システム
    技術情報 【開発基盤】
    　 Force.com
    【技術要素】
    　 Apex, Visualforce, heroku, CakePHP

     

    こんにちは！

    以前、

    「MIXED_DML_OPERATION, 非設定オブジェクトを更新した後の設定オブジェクト上のDML操作

    （またはその逆）は、許可されていません」

    というエラーを回避する方法について記事にしましたが、対処方法がカンマ区切り化するという

    昭和的なものであったため、より良い解決方法について記載します。

    （追記）MIXED_DML_OPERATIONエラーの回避方法について

     

    public void save(){
    　// 設定オブジェクトレコード更新
    　update user;
    　// 取引先更新処理
    　List<Account> accList = new List<Account>();
    　accList.add(
    　　new Account(
    　　　Name = ‘テスト取引先’, // 取引先名
    　　　Phone = ‘000-0000-0000’, // 電話
    　　　NumberOfEmployees = 300 // 従業員数の順番
    　　)
    　);

    　accList.add(
    　　new Account(
    　　　Name = ‘サンプル会社’, // 取引先名
    　　　Phone = ‘111-111-111’, // 電話
    　　　NumberOfEmployees = 200 // 従業員数の順番
    　　)
    　);

    　// List<Account>型からJSON文字列に変換
    　String accListJSON = JSON.serialize(accList);

    　// 非同期メソッド呼び出し
    　insertAcounnt(accListJSON);
    }

    @future
    private static void insertAcounnt(String accListJSON){
    　// JSON文字列からList<Account>型に復元
    　List<Account> accList = (List<Account>)JSON.deserialize(accListJSON, List<Account>.class);
    　insert accList;
    }

     

    少し２１世紀的な対応となりましたね。

    ご参考ください。

    こんにちは！

    Salesforceでは、1トランザクション内で設定オブジェクトと非設定オブジェクトに対して、DML処理を行おうと

    した場合、以下のエラーが発生してしまいます。

     

    「MIXED_DML_OPERATION, 非設定オブジェクトを更新した後の設定オブジェクト上のDML操作

    （またはその逆）は、許可されていません」

     

    今回は、少し力技ではありますが、このエラーの回避方法についてです。

     

     

    MIXED_DML_OPERATIONエラーの回避について

     

    設定オブジェクトとは、ユーザオブジェクトや、ロールオブジェクトなどが該当します。

    非設定オブジェクトとは、取引先、取引先責任者、カスタムオブジェクトなどです。

     

    上記エラーは、設定または非設定オブジェクトに対するDML処理のどちらかを、

    futureアノテーションのついた非同期メソッドで実行することで、回避可能です。

     

     @future

     private static void insertAcounnt(){

         Account acc = new Account ();

         acc.Name = ”TEST取引先;

         insert acc;

    }

     

    しかし、非同期メソッドはプリミティブデータ型、プリミティブデータ型の配列、プリミティブデータ型の

    コレクション（List,Mpa）のみを引数に設定可能となっており、sObjectは引数に設定することができない

    ため、List<Account>などあらかじめ用意したsObject型のリストを非同期メソッドに渡してDML処理を

    実行・・・・といったことはできません。

     

    そこで、強引ではありますが、以下のように一度レコードの値をカンマ区切りで１つの文字列にして引数に

    渡し、非同期メソッド内でカンマで文字列に分割し、各項目の値として設定することで、対処することが

    できます。

     

    public void save(){

    　  // 設定オブジェクトレコード更新

      　update user;

      　// 取引先更新処理

      　List<String> accList = new List<String>();

      　String acc1 = ‘テスト取引先,000-0000-0000,300’;// 取引先名、電話、従業員数の順番

     　 String acc2 = ‘サンプル会社,111-111-111,200’;

      　accList.add(acc1);

      　accList.add(acc2);

      　// 非同期メソッド呼び出し

    　  insertAcounnt(accList);

    }

    @future

    private static void insertAcounnt(List<String> accList){

      　List<Account> accList = new List<Account>();

      　for(String str : accList){

      　　　　　Account acc = new Account ();

      　　　　　// カンマで分割してリストに格納

          　　　List<String> strList = str.split(‘,’, -1);

     

      　　　　acc.Name = strList[0];//取引先名

      　　　　acc.Phone = strList[1];//電話

      　　　　acc.NumberOfEmployees = Integer.valueof(strList[2]);//従業員数

      　　　　accList.add(acc);

         }

        insert accList;

     }

     

    引数を文字列のリストにすることで、複数件のレコードを処理することも可能です。

    ただし、引数項目が増えると、何番目にどの項目が入っているのか・・・・分かりにく

    いという問題はありますが、どうしても設定オブジェクト、非設定オブジェクトを同時に

    更新する必要がある場合は、検討の１つとしても良いと思います。

    あけましておめでとうございます。

    本年も当社および技術ブログをよろしくお願いいたします！

     

    久しぶりの技術ブログ更新となりましたが、今回は、DML文に関するガバナ制限

    回避方法の一つをご紹介します。

    DMLのガバナ制限とは？

     

    ガバナ制限上、1トランザクションでの実行できるDML文の上限は150（Winter’15時点）と

    なっており、150を超える処理を行う必要がある場合、制限の回避に苦労します。

     

    そういった場合に、1DMLで10オブジェクトまで一括でＩｎｓｅｒｔする方法を

    利用することで、DML数を減らすことが可能となることがあります。

     

     

    1DMLで複数オブジェクトInsertする方法

     

     下記のソースのように記述することで、1DMLでInsertが可能となります。

    但し、1度にInsertできるオブジェクトは10種類までとなります。

    10種類以上Insertするとエラーとなりますので、10種類で区切るような処理を

    入れるようにしてください。
    ※エラーメッセージは、添付画像の通りとなります。

    １ＤＭ１０オブジェクト超エラー

     

    なお、下記ソースは、10オブジェクト以上でもInsert可能な、サンプルコードと

    なります。

    List<Sobject> sobjList = new List<Sobject>();

    List<Sobject> insList = new List<Sobject>();

    //11オブジェクト、12レコードを追加
    Sobject sobj1 = new Account(Name = ‘aa’);
    sobjList.add(sobj1);

    Sobject sobj2 = new Account(Name = ‘bb’);
    sobjList.add(sobj2);

    Sobject sobj3 = new X1__c(Name = ‘bb’);
    sobjList.add(sobj3);

    Sobject sobj4 = new X2__c(Name = ‘bb’);
    sobjList.add(sobj4);

    Sobject sobj5 = new X3__c(Name = ‘bb’);
    sobjList.add(sobj5);

    Sobject sobj6 = new X4__c(Name = ‘bb’);
    sobjList.add(sobj6);

    Sobject sobj7 = new X5__c(Name = ‘bb’);
    sobjList.add(sobj7);

    Sobject sobj8 = new X6__c(Name = ‘bb’);
    sobjList.add(sobj8);

    Sobject sobj9 = new X7__c(Name = ‘bb’);
    sobjList.add(sobj9);

    Sobject sobj10 = new X8__c(Name = ‘bb’);
    sobjList.add(sobj10);

    Sobject sobj11 = new X9__c(Name = ‘bb’);
    sobjList.add(sobj11);

    Sobject sobj12 = new X10__c(Name = ‘bb’);
    sobjList.add(sobj12);

    Map<Schema.sObjectType,List<Sobject>> objMap = new Map<Schema.sObjectType,List<Sobject>>();

    for (Sobject sobj : sobjList) {
        Schema.SObjectType objType = sobj.getsObjectType();
        if (! objMap.containsKey(objType)) {
            objMap.put(objType , new List<Sobject>());
        }
        objMap.get(objType).add(sobj);
    }

    for (Schema.SObjectType sType : objMap.keySet()) {
        for(Sobject obj : objMap.remove(sType)){
             insList.add(obj);
        }

         if( insList.size() == 10 || objMap.isEmpty()){
            Insert insList;
            insList = new List<Sobject>();
        }
    }

     

     ただし、1トランザクション中で処理可能なレコード数10,000レコードのガバナ制限については、

    この記述により回避できませんので、別途気を付ける必要はあります。

     

    SOQLでは、SQLで使用可能な一部の集計関数が使用可能です。（APIバージョン18以上）

    今回は、その利用方法及び、注意事項です。

    SOQLでも使える！集計関数の利用について

     

     

    例えば、件数を取得する場合は、以下のような記述を行うと、取得可能です。

    public class hogeController{
        public Integer recCount {get; set;}
        public void recordCountTest(){
            AggregateResult a = [select count(Id) cnt from hogeObj__c];
            // AggregateResultはMAP型なので↓の様に取得する
            recCount = Integer.valueOf(a.get('cnt'));
        }
    }

     

    特定の項目で集約したい場合など（例：select hoge__c, count(id) cnt from hogeObj__c group by hoge__c）は、

    AggregateResult部分をリストで取得することで対応可能となります。

    ただし、AggregateResultの内容はString型で返ってくるため、変数に入れる場合は型に注意が必要となります。

    （valueOfを使用）

     

    なお、デバッグログを参照すると、countで1件に集約されたとしても、取得件数分Selectカウントされているので、

    ガバナ制限を超えた件数を取得する場合には、注意が必要となります。

    　例：2000件のデータをCOUNT関数で取得した場合
    　　クエリの結果→1レコード（Number of SOQL queries: 1 out of 100）
    　　ガバナ→Number of query rows: 2000 out of 50000

     

    また、注意事項として、

    集計関数を使うとLIMIT関数が使えなくなるため、ガバナ制限を超える件数をカウントする必要がある場合は、
    forループでSOQLを実行し、ガバナ制限に達する前にソースコード内でbreakする必要があります。
    public hogeController2{
         public void recordCountTest2(){
             Integer recCount = 0;
             for(hogeObj__c h : [select id from hogeObj__c]){
                 recCount++;
                 if(recCount == 45001){
                     // ※エラー処理等を記載
                     break;
                 }
             }
        }
    }
    こうなると、もうCOUNTを使用することができませんので、COUNTの用途は非常に制限された
    ものだと感じます。COUNT利用で、ガバナ制限を回避する方法をご存じの方は、是非ご連絡ください。

    お客様から、「項目変更履歴をレポートで出してほしい！」といったご要望を

    いただくことがあると思います。そういったときにご注意いただきたい事項です。

     

    主従関係オブジェクトの項目変更履歴はレポート表示できるの？

     

    項目変更履歴

    カスタムオブジェクトの場合、カスタムオブジェクトの編集画面から、「項目履歴管理」に

    チェックを付けることで、項目単位で変更履歴を管理可能となります。

     

    項目の内容が変更された際に自動的に履歴を残してくれる本機能は、

    非常に便利なものではありますが、主従関係のオブジェクトの従オブジェクトに

    ついては、１点気をつけなければならないことがあります。

     

    それは、主従関係の従オブジェクトについては、レポートタイプが自動でも、

    カスタムでも、項目変更履歴レポートの作成が行えないということです。

     

    どうしても従オブジェクトの項目変更履歴レポートを作成したい場合は、

    　・ApexDataLoaderから、該当の項目履歴情報をCSVエクスポートし、利用する

    　・Visualforceで履歴を表示させる画面（レポート）を作成する。

    　・Apexトリガを利用し、別のカスタムオブジェクトに変更履歴データを登録し、

    　　そのカスタムオブジェクトのレポートを作成する。

    といった方法がありますが、なかなか敷居が高いものとなります。

     

    是非、今後の機能改善で、従オブジェクトでも変更履歴レポートが出力できるように

    なって欲しいものです。

     

    今回は、トランスレーションワークベンチの利用方法、利用に関する注意点です。

     


       

      トランスレーションワークベンチの利用について

       

       

      設定手順

      （１）トランスレーションワークベンチを有効化する
      [設定]→[トランスレーションワークベンチ]→[翻訳設定]

      （２）使用したい言語を選択
      ※「翻訳者」は指定しなくても良い

      （３）翻訳を実施する
      ※翻訳を行うためには、複数のユーザ権限が振られている必要がある。翻訳の設定はコンポーネントによって異なる。
      【ブラウザ操作で実施】

      １）[設定]→[トランスレーションワークベンチ]→[翻訳]で設定可能なコンポーネント

      • Apex共有の理由
      • Sコントロール
      • Webタブ
      • カスタムアプリケーション
      • カスタムレポートタイプ
      • カスタム項目
      • カテゴリノード
      • データカテゴリ
      • データカテゴリグループ
      • ボタンとリンクの表示ラベル
      • ルックアップ検索条件
      • レイアウトセクション
      • レコードタイプ
      • ワークフローToDo
      • 選択リスト値
      • 入力エラーメッセージ
      • 標準項目ヘルプ

       

      操作手順

      1. 「翻訳設定」ページにアクセスし、言語・コンポーネント・オブジェクト（※コンポーネントによっては選択）をすると、一覧に翻訳可能な項目が表示される。
      2. 翻訳行いたい項目の「～の翻訳」セルをダブルクリックすると、入力可能になるので、翻訳後の文言を設定する。
      3. 「保存」をクリックすると設定が保存される。

      トランスレーションワークベンチ　翻訳

       

      ２）[設定]→[カスタマイズ]→[タブ名と表示ラベル]→[タブと表示ラベルの名称変更]で設定可能なコンポーネント

      • 各オブジェクトのName項目
      • タブ名

       

      操作手順

      1. 「タブと表示ラベルの名称変更」ページにアクセスし、オブジェクト名の「編集」リンクをクリックする
      2. レコード名（Name）と名前（タブ名）を修正する。（英語の場合はSingular、Plural）
      3. 「保存」をクリックすると設定が保存される。

      トランスレーションワークベンチ　タブ名表示ラベル１

      トランスレーションワークベンチ　タブ名とラベル２

       

      ３）[設定]→[作成]→[カスタム表示ラベル]で設定可能なコンポーネント

      • カスタム表示ラベル
      操作手順

      1. カスタム表示ラベルの一覧から翻訳設定を行いたいラベルの詳細画面を表示する
      2. 「翻訳」欄の「新規」ボタンをクリックする
      3. 言語と翻訳テキストを設定する

      トランスレーションワークベンチ　カスタム表示ラベル

       

      【翻訳ファイルのインポート】

      1. 設定ファイルを作成
        • １言語１ファイル
        • 拡張子は「.stf」
        • 複数言語をまとめてアップ可能
          →１言語１ファイルで作成し、ZIPファイルでインポートする

        サンプルファイル（新規設定も更新も設定ファイルの内容は同一）

        # 言語: 日本語
        言語コード: ja
        種別: バイリンガル

        ——————未翻訳—————–

        # 主要 表示ラベル

        CustomField.PostalCode__c.City.FieldLabel 都道府県
        CustomField.PostalCode__c.State.FieldLabel 市区町村
        CustomField.PostalCode__c.TownName.FieldLabel 町名

        ※「エクスポート」機能からファイルを出力後、出力したファイルを使用して翻訳を行うのが良い。

      2. 作成したファイルをインポート
        結果は実行者にメールされる

       

      注意事項

      • メールテンプレート（コミュニケーションテンプレート）は翻訳指定が出来ない。
        →カスタムラベル等を使用する（件名、本文ともにラベル参照は可能）
      • サイト（未ログイン時）の言語がユーザのブラウザ言語で翻訳されるようになる。
        →トランスレーションワークベンチ有効化前はゲストユーザの言語で翻訳が行われる。
        →カスタマーポータルを利用したログインを使用している場合、ログイン後はユーザの言語で反映される。

      Salesforceログインを効率化し、Salesforce開発を進めていくために、Salesforce自動ログインツールを探して、使う方は多いのではないでしょうか？ 代表的なものが「Force.com LOGINS」です。そこでSalesforce自動ログインツールを整理し、その１・その２として2つの記事構成で解説していきたいと思います。

      Force.com LOGINSでSalesforceログインが簡単に！

      Salesforce開発を行っていく中で、IDとパスワード覚えておき、わざわざ 入力するのが面倒と感じている方もいると思います。

      そういう時は、Salesforce自動ログインツールを導入し、IDとパスワード を記憶させておくことをお勧めします。 まず、ご紹介したいのがForce.com LOGINSです。

      ※ ※ただし、現時点ではchrome限定のアドオンツールとなります。

      Force.com LOGINS

      https://chrome.google.com/webstore/detail/ldjbglicecgnpkpdhpbogkednmmbebec

       google chrome Force.com LOGINS

      chromeにこのツールを導入することで、ブラウザ上にログイン情報を 記憶することが可能となります。 また、複数の環境を登録できますので、例えば本番環境とsandbox環境を それぞれ記憶させたい等、そういった用途にも使用できます。

       

      アカウントのエクスポート／インポートも可能ですので、非常に使いやすい ツールだと思います。

      Salesforceログインツール画面

      contact

      ご相談・ご質問等ございましたら、お気軽にお問い合わせください。

      お問い合わせ
      翻訳