一度は読んでいただきたい社内システム管理の教科書——システム管理に必要なのはスキルよりマインド

あなたはSalesforceを利用していますか？

Salesforceは利用していなくても、何かしらの業務系クラウドは利用していますか？

本記事は業務系クラウド製品を管理するにあたり、“設計書が正しい” という固定観念を取り払い、今の時代に求められている必要なマインドとSalesforceを例にしたちょっとしたコツを紹介する記事です。

以下のどれか一つでも該当する方には、ぜひ読んでいただきたい記事となっております。

• エンジニアではないが、社内のシステムを管理しなければならない
• Salesforceを導入しようと悩んでいるが、メンテナンス出来るか不安
• Salesforceを利用しているが、上手な管理の仕方が分からない

本記事をきっかけに以下のポイントを意識してもらい、今後のシステム管理業務に反映してもらえると幸いです。

• システム管理の良し悪しは、エンジニアスキルではなく誠実に向き合う心で決まる
• 誠実なマインドで向き合うことで、ビジネスを成功させるシステムに変革する
• 変革を実現させるコツとして、システム管理はドキュメントベースではなくシステムベースにする

Salesforceだけでなく、社内の業務系クラウド製品を管理するために必要となるマインドを作り上げる一つの教科書として最後までお読みいただければと思います。

なぜ「使いやすいはずのシステム」が負債になるのか

あなたが利用しているシステムは資産（ビジネスを成功に導く重要なツール）ですか？

それとも負債（ビジネス拡大や業務を妨げるお荷物）ですか？

世の中には多くのシステムが存在し、機能や製品テーマ、得意分野などはそれぞれ異なるものの、「便利にさせるため」ということは共通しています。しかし便利さを追求しているシステムが、あるタイミングをきっかけに「使いづらい」と感じてしまうのはなぜでしょうか。もちろん、アップデートで画面の構成が変わり直感的に分かりづらくなったなど、システムに原因があることもあります。

ただしシステムの原因だけでなく、利用していく中で私たちのようなユーザが使いづらくしていることも多くあります。

例えば、上図のような営業月報がある場合、本当に最新のExcelファイルはどれなのか分からなくなりますよね。こうなってしまう原因は、Excelを提供しているMicrosoftでしょうか？いいえ、違いますよね。

業務系クラウドも例外ではございません。

実際、弊社の社内システムにて「この入力項目は利用していないだろうから削除しよう」となりました。項目を削除するだけなら10分あれば充分な作業時間です。

しかし削除するにあたって「同じ名前の項目が複数ある」「どのような目的で作られたのか不明」「影響を受ける機能はないか」「外部連携している項目ではないのか」など多くの疑問が発生し、関連システム含めて調査する必要が出てきました。

結果的に、入力項目を削除するというシンプルな要望でありながら、実際の作業は14時間以上もかかってしまいました。（時給換算にして14万円以上の損失が発生…！）

システムを資産にするか負債にするかは、私たちユーザの使い方次第でもあるのです。

目指すべきは「ドキュメント不要」の自己説明的なシステム

ではシステムを資産にするためには、どのように管理するべきでしょうか。

それは“ドキュメントベースでの管理からシステムベースの管理に移行すること”だと思います。

システムを構築するにあたって設計書は必要なドキュメントの一つですが、これらは常に更新されており、どんな時も信用できる内容が記載されていますでしょうか。本来のドキュメントのあり方としてはそうあるべきですが、現実的には厳しい状態がほとんどだと推測します。

ならば、機能一覧書やER図（データの関係性を示した図）などのシステムの全体像を把握するドキュメントは継続的に管理し、各機能の細かい内容はドキュメントではなくシステム内で管理することが望ましいと思います。

特にノーコード・ローコード開発が可能な業務系クラウド製品は、「機能開発の容易さ」「改修のしやすさ」もメリットであるため、毎回全てのドキュメントを確認して修正するのは、非常に大きな手間です。

ただしこれは “システムの改修を思慮せず行なってよい” ということは意味しておりません。むしろ反対の意味です。

簡単な設定変更であったとしても、「負債になる設定ではないか」「今後自分が管理しなくなっても “うまく管理出来るシステム” であるか」を検討してから行動に移すべきだと感じます。

「システム内の機能 = 今までのシステム開発と同等の設計書」となるように心がけることで、細かいドキュメントが不要でありながらも、”資産化されたシステム”へと近づくことが出来ます。

明日から実践できる「管理品質」を高める5つのTips

ここまでは業務系クラウドを中心とした社内システムの現実と目指すべきシステム像についてでした。では「資産化されたシステム」を実現するために必要なポイントを5つ紹介します。 今回はSalesforceを代表とした説明になりますが、多くの業務系クラウド製品にも通じるポイントになりますので、非Salesforceユーザの方もご一読いただけると嬉しいです。

「資産化されたシステム」を実現する5つのポイント

①項目名は子供やペットと同じように命名する

②項目をグループ化するなら名字を付ける

③目にうつらない全てのことをメッセージにする

④伝えたいメッセージは適切な場所に記す

⑤あなたのマインドとシステムは一心同体

①項目名は子供やペットと同じように命名する

ユーザが独自に作成する項目をカスタム項目と言いますが、この項目を作成する際には2つの名前を設定します。

• 表示ラベル
  • Salesforceを通常利用する際に画面に表示される名前
  • 日本語入力も可能
  • 対象者：一般ユーザ
• 項目名（API参照名ともいう）
  • 入力規則や自動化処理などでシステムが利用する名前
  • 半角英数字のみ可能
  • 対象者：管理ユーザ、システム

付ける名前はユーザが自由に決めていいですが、自由だからこそ分かりやすい名前にすることが重要です。

私たち人間が子供やペットに名前を授ける際に（こういう子に育ってほしい）（可愛らしい名前にしたい）など考えるように、項目にも同じように「誰もが分かりやすく意味がある名前」を付けてあげてください。大袈裟な表現かもしれませんが、システム管理においては非常に重要なポイントです。

表示ラベルは一般ユーザが利用する際にどのような入力をするべきなのか分かりやすい名前、API参照名は管理ユーザや（今後出てくるかもしれない）エンジニアが分かりやすい名前にすることで、運用定着化と未来の環境調査時間削減につながります。

例えば「契約開始日」という項目を作ろうとした場合、下表ではどれが分かりやすいでしょうか？

	パターンⒶ	パターンⒷ	パターンⒸ	パターンⒹ
表示ラベル	契約日	開始日	契約開始日	契約開始日
API参照名	Field01__c	StartDate__c	contractstartdate__c	ContractStartDate__c
所感	契約の開始日を指すか、終了日を指すか不明 API参照名だけ見ると何の項目か分からない	表示ラベル / API参照名どちらも何の開始日なのか分からない	表示ラベルは問題なし API参照名が全て小文字で単語の区切りが分からず読みづらい	表示ラベルは問題なし API参照名は単語が大文字で 区切られていて読みやすい

私はパターンⒹが一般ユーザにも管理ユーザにも分かりやすい名前かと思います。もし適切な名前のイメージがつかなければ、上表やSalesforceがもともと用意している項目（標準項目という）を真似してみるところから始めてみるのが良いかと思います。

補足にはなりますが、標準項目のAPI参照名は単語ごとに大文字で区切っているため、そちらに倣うことで統一感が出て、一覧化した際にきれいに見えます。

（標準項目の例：商談のフェーズは[StageName]、最終更新者は[LastModifiedBy]）

②項目をグループ化するなら名字を付ける

Salesforceには項目をグループ化する機能がないため、「○○と△△と◇◇は、こんなところで使う項目たち」と、まとめる時に不便に感じることがあります。

それを解決するための手段として、名字を付けて疑似的なグループ化を行うという工夫があります。

例えば引っ越しの際、段ボール箱に何が入っているかを油性ペンなどでメモすると思います。その時に「キッチン：食器、グラス」「キッチン：調理器具」「キッチン：調理家電」とそれぞれの段ボールに “キッチン” と明示的に書くことで、だれが見ても「この段ボールたちはキッチンの近くに置いておけば、荷解きが楽になるな」と推測できます。

Salesforceでも同じようにすることで、項目の管理が楽になります。

例えばスーパーバイザー（SV）のみが記載する項目が複数ある場合、以下のように名字として「SV」を付けることで、項目一覧で見つけやすくなります。

#	表示ラベル	API参照名	目的
1	SV：判断区分	SV_DecisionCategory__c	オペレータの対応の妥当性を判断
2	SV：確認状況	SV_ReviewStatus__c	SVの確認状況を記録
3	SV：コメント	SV_ReviewComment__c	オペレータに対しての評価を記載
4	SV：優先度高	SV_HighPriorityFlag__c	SVの判断で優先度が高いと判断する場合に✓をつける
5	SV：アナウンス要	SV_AnnouncementRequired__c	SVの判断で全体アナウンスが必要なケースの場合に✓をつける

NGなこととして、名字のつけ方がバラバラになると逆に混乱を招くため注意しましょう。

• SV判断区分、（SV）確認状況、SV用コメント
• SvDecisionCategory__c、sv_ReviewStatus__c、ReviewCommentForSV__c

■表示ラベルは、検索窓を利用してSalesforceの項目一覧から絞り込めます。

■API参照名は検索できないですが、並び替えることでまとまりに出来ます

ブラウザのページ内検索を利用することでも利点を発揮します！

※注意点

これはあくまで「ちょっとした整理術」です。もしSVの項目が50個、100個と増えていくようなら、項目の作りすぎか別のオブジェクト（データの箱）に分けるべき合図かもしれません。

③目にうつらない全てのことをメッセージにする

もしも友人から「私のペットを2週間預かっててほしい」と言われたとしたら、あなたはなんて返答しますか？

そのペットを預かれるか否か、エサはどうすればいいのか気になることは出てくると思いますが、まずは「なんで預かる必要があるの？」と理由や目的を聞きたくなると思います。

「なんで」という疑問は動物を管理するだけではなく、システムを管理することでも同じです。

あなたが作成した項目は、5年後も10年後もあなたが管理し続けるでしょうか。もしかしたら、1か月後には違う人に管理を任せる可能性もありますよね。その際に、後任者があなたと同じ品質で管理するためには「あなたが作った項目はどういう目的があるのか」をきちんと理解する必要があります。

そのために項目の設定内容にある「説明」を用いて、後任者へのメッセージとなる内容を記載しましょう。

■カスタム項目作成時の画面

例えば「解約日」という項目がある場合、説明に書く文章はⒶとⒷのどちらが良いでしょうか？

Ⓐ解約をした日付を入力する

Ⓑ解約が多い時期をレポートで集計し対策を図るための項目。本項目は外部の経理システムにも情報連携し、解約通知書に利用している。

後任者がⒶの説明文を読んだら（項目の名前見ればわかるよ！）と困ってしまいます。知りたいのは、この項目が “どうして存在しているのか、どういう目的なのか” です。そのため記載すべき文章はⒷのような「項目の名前だけでは分からないこと」を書くべきです。

つまり説明には、見れば分かる「この項目がどういうものなのか」というwhatではなく、見ただけでは分からない「この項目の意図 / 目的 / 作成理由は何なのか」というwhyを記載しましょう。

④伝えたいメッセージは適切な場所に記す

項目の設定には「説明」と似た機能で「ヘルプテキスト」というのがあります。これはSalesforceのレコードページで、項目名の横に「i」のマークで記される “ユーザの入力を補助する機能” です。

この「iマーク」の上にマウスカーソルを置くと、各項目に設定した文章が表示されます。これにより「どのような内容を入力するべきなのか、注意するべき内容は何か」を一般ユーザに知らせることが出来ます。

“この項目がどういうものか” という点は「説明」と似ていますが、書くべき内容と対象者が異なります。ヘルプテキストと説明のそれぞれの役割を下表にまとめました。

	ヘルプテキスト	説明
役割	入力をサポートする内容が記載される	項目そのものに対してのwhyが記載される
記載する内容	何を入力する項目か 入力する際に注意すること 入力内容のサンプル	どのような目的なのか その項目が存在している理由や経緯 最終的にどのような使われ方をするのか
対象者	一般ユーザ	管理ユーザ
記入例： 「解約日」の場合	顧客から解約依頼を受けた日付ではなく、 両社が合意した契約終了（解約）となる 日付を入力すること。	解約が多い時期をレポートで集計し、対策を図るための項目。本項目は外部の経理システムにも情報連携し、 解約通知書に利用している。

一般ユーザにその項目が作られた目的や経緯を伝えるより、どのように入力してほしいかを伝えることの方が、一般業務においては必要な要素だと思います。“この項目がどういうものか” を伝えたい相手に正しく伝えるには、きちんとそれぞれの機能の役割を理解して書き分けることが重要です。

ヘルプテキストは一般ユーザの業務習熟度やリテラシーによって左右されるため、必ず設定するべき機能ではございません。ただし、説明は前章の通り「後任者に向けたメッセージ」になるため、必ず記載しましょう。

⑤あなたのマインドとシステムは一心同体

最後は、①～④のようなSalesforceの機能を活用したコツではなく、あなた自身の思想やマインドを醸成することです。

今まで項目作成を例に4つのポイントを説明しましたが、「そもそも、その項目本当に必要か？」と立ち止まって、冷静に未来を考えることが大切です。

項目を作るということは、資材が増えるということです。資材が増えるということは、一般ユーザと管理ユーザの負担を増やすということです。負担を増やすと当初の目的である「資産化されたシステム」から離れてしまう可能性が高まります。

以下の3つを事前にチェックし、余分な資材を増やすことを避けましょう。

• Salesforceが最初から用意している「標準項目」で代用できないか
• 活動記録やChatter、Slack連携などを用いて、項目以外で代用できる機能はないか
• 「とりあえず」で用意した項目ではないだろうか

「資産化されたシステム」を実現するためには、あなた自身のマインドを変革させることが重要です。持つべきマインドと捨てるべきイメージを明確にしましょう。

持つべきマインド

• システム管理の主体はシステムそのもので、ドキュメントは補足を行うもの
• 作業一つ一つが、将来の負債になる可能性があること
• 属人化の可能性は極力排除し、常に後任者が出てくる可能性を考慮する

捨てるべきイメージの例

• 詳細な設定内容もドキュメントで管理するべきという考え方
• システム管理は”なんとなく”でうまくいく
• 困ったことが出てきたら、その度に暫定的な対応すればよい

上記を心掛けていくことで「システムに向き合うマインド」が醸成されていき、そのマインドが反映された「資産化されたシステム」が作られていくのです。

最後に：システム管理はスキルではなく「誠実さ」

ここまで、長い文章をお読みいただきありがとうございました。Salesforceやシステムに対しての熱が高まり、ボリューミーな文章になってしまいました。

「⑤あなたのマインドとシステムは一心同体」にて記載しましたが、「資産化されたシステム」を作るために大事なことはマインドです。そのマインドを反映させるための手段として、①～④のようなコツや工夫が必要となってくるのです。

管理の良し悪しはエンジニアスキルでは決まりません。

そしてシステムを資産とするか、負債とするかは、私たちユーザの日頃の使い方で決まります。

負債とならないために、運用ルールの徹底や今回紹介したコツを実践するなど、誠実にシステム管理に向き合うことが重要です。

何から手を付ければ良いか分からないという方は、まずは今ある項目の説明欄に、なぜそれが必要か（Why）を3行ほど書いてみることから始めてみませんか？