00:01
では、こちらのガチャを今度は浜中さんに 聞いていただきたいと思います。
SFAレコード更新問題 営業現場を知るからこそスピーディーに解決
とある問い合わせ対応をしてたんですよ。 SFAのシステムと機関システムは別で分かれていて、
データ同期をしてたんです。 SFAのシステムとSFAのデータをやり取りしてたんです。
そこで、すごい超高頻度連携してるんですよ。 機関とSFAのシステムの連携が高頻度なんですね。
そう、めっちゃ高頻度になっていて、 SFAから機関側に行って帰って1位連携なんですね。
行って戻って1位連携。
その行って戻ってくる間に SFAがもう1回更新かけちゃうと、
その更新かけたのが先祖返りするんですよ。 なるほど。
っていう仕様になっていて。 発発しそうですね。
そもそもSFAのレコード更新をする時に 連携頻度って1分連携なんですよ。
早いね。
1分連携なんですけど、 普通の使い方を想像すると、
1回保存ボタンを押して、1分も経たずに もう1回何か編集して保存を押すか想像できなかったんですよ。
そうですね。1回何か入力の携帯作って、 保存したら結構それで終わりですよね。
ずっと思ってたんですけど、別件の問い合わせ対応で 現場の書務さんと話をしてる時に、
今って営業担当が顧客データの 要は管理をしてないんですよ。
よくあるお客様アンケートみたいなものを 書いてもらって、
その紙のSFSシステムへの打ち込みって 書務さんがやるんですよ。
画面を今編集してるユーザーが レコード所有者になっちゃうんですよ。
書務さんがレコードを入力したから、 このレコードは書務さんが作ったよっていう情報が残りますね。
要は担当さんに変えなきゃいけない。
営業担当さんに変える。
やった結果、何が起きたかというと、
要はあのツーサービスって、 初回保存の時に所有者変えられないんですよ。
強制的に自分が入って…
そう、になっちゃう。
しょうがないからもう一回開いて…
そう、所有者だけを変更かけて 保存ボタンを押してたっていうのが分かって…
一回二回やりますね。
っていうのが分かって、これだっつって。
でも今のって現場の話とか実際見て、 聞いて考えないとわからない状態ですよね。
ベンダーさんとかだとなかなか…
03:02
絶対にこの発想にはたどり着かないですね。
やっぱりシステム管理って、 システム側だけ見てるっていうのは間違いで、
たまには現場の人と話して、
何困ってます?っていうのは聞いた方がいいんでしょうね。
結局コーコレットのIT部門って、
結局現場の話が理解できるが最大の利点だと思う。
むしろそこが市場命題だと思ってるので、
システム屋さんと事業会社って言葉通じないですよ。
ベンダー側は会社特有の業界文化とかに明るくないです。
システム側は当然詳しいですけど。
事業会社側は独自文化というか…
事業界の文化。
もちろんプロですから精通してるけど、
システム屋さんが理解できるように説明できない。
ここで結局生まれるのがギャップなんですよね。
ここを適当にやっちゃうと、出来上がった後に、
こんなはずじゃなかったりなるんですよ。
この中で非エンジニア、エンジニアSEあかりじゃなくて、
今上出していらっしゃって、
現場に対しての思いも強くて、
現場の人と会話をする。
かつ、自分でプログラムとかを作るわけではないけど、
勉強をしてシステム会社の人と交渉がしっかりできる
っていうタイプじゃないですか。
やっぱりこれだけ大きな機関システムのリプレイが
実際成功できたのも、
こういうところがすごく徹底されてうまくできた
田中さんの力ってすごく大きいんじゃないですか。
いいんですけどね。
はい、椎茸の唐揚げが到着しました。
レモン汁つけて。
ほんと椎茸好きなんですよ。
たくさん食べてください。
うまいな、やっぱ椎茸。
ここでまた2人に到着しました。
ホルモンの青唐辛子炒め。
うまっ。
唐辛子のピリッとした辛さと、
ホルモンの感触がまた美味しいんですよ。
うん。
これは辛い。
はい、じゃあ次のガチャ回していきたいと思います。
ちょっとシステム的な話。
リプレイスを邪魔する厄介者、
誰も使わないゴミデータとは。
リプレイスをやったシステムって、
実はこの子も全身からのデータを
引き継いでスタートしてるんですよ。
ご経験あるんじゃないかと思うんですけど、
事業部門があって、
06:00
なんかどこで使うか分かんないから、
そのデータもずっと取っておいてって言うんですよ。
取っておける分だったら取っておきたい。
今回リプレイスをやるにあたって、
移行作業のテストをすごい3回やったのかな。
3回やって、1回目がまあひどくて、
移行ツールで対応ができないデータが大量に出たんですよ。
なんだこれって。
調べていったら、
ご先祖様のデータがあったんですよ。
さらにその前のシステムのデータですよ。
だから現在のレコードのバリデーションチェックだと、
もうエラーばっかりで入れらんないデータ。
そのデータが4桁単位で出て、
4桁って。
じゃあこれ本当にいるのいらないの?
っていう精査が始まるんですよね。
分かるんですよ。
会社のデータは財産です。
間違いないです。
それは間違いない。
それは間違いないけど、
使うこれっていうのは、
やっぱりどっかで定期的に、
特にIT部門なりが温度を取ってやっぱりやるべきですね。
どうしても残しておくなら、
データベースをいじったり拡張したりするときに、
ここまで含めての対応をするべき。
その1回目のリハーサルで出てきた問題を潰して、
2回認むじゃないですか。
別の問題が出てくるんですよ。
そのときは1回目があれすぎてて、
細かい類似の別のものとかに気づけない。
大きくダメ。
そうそう。
ちっちゃくダメみたいなのが2回目で出て、
3回目で大体これでいけるよねみたいな感じになるんですけど、
自分の会社の財産、
財産と言うからには目録じゃないですけど、
何を持っているか分かるようにしておいた方がいいですよ、
っていうのはみんなに言いたい。
それはありますね。
そもそもこのデータは何のために移行するんだとかの、
最初の冒頭の部分をしっかりと固めておかないと、
いろんなトラブルが出ちゃうんですよね。
そうですね。
DI側がよくあったりするんですけど、
データライフサイクルマネジメント。
何年間放送させてもらう。
何年前のデータはどっかにロケットとか、
システムの中から消してしまう。
せめて退避とかね。
そうそう。
引き出しが鳴ったときにバックアップから戻せるとか、
そういう仕組みを考えておきたいなっていうところですね。
ですね。
はい、ありがとうございます。
じゃあ、はい、次また、
河村さんにお願いしてもらえますか。
これは?
ユーザーのリテラシー格差、
求められるサポートは人によって異なる。
おお、なるほど。
今回、大規模システム改変だったので、
当然ユーザー教育ってやるんですよね。
09:02
ユーザー教育の内容が、
要はほぼ全社員に使うシステムなので、
当たり前ですけど、
人によって理解できるレベルって違うんですよ。
説明会も先にタイムスケジュールとか全部出して、
この時間帯にこの話するから、
もうデイリー自由にして聞きに来なさいと。
あと配信もするからって言ってやりましたね。
多分それでも稼働後問い合わせは当然起きる。
その起きた問い合わせも、
今問い合わせが来てる人と、
つい先問い合わせが来た人で、
同じ内容なんですよ、来てるのは。
来てるのは同じ内容で、
答えも当然同じになる。
同じになるんですけど、
Aさんに送った内容をBさんにコピペして送っても、
Bさん分かんないんですよ。
Aさんは理解した文章だけど、
Bさんはリペテンションしない。
これがやっぱり小事務と格差、レベル差になるので、
ヒントって少ないんですよ。
問い合わせの時に取得できるのって、
名前とメールアドレスと社員番号ぐらいなので、
そこから、例えばこの所属、組織の人だったら、
業務上ここまでは多分理解できるとか、
こっちの所属の人だったら、
こういう言い方しないと多分分かんないとかが、
結構センスが問われると思うので、
その初期の見定め想定を思った上で、
最初かからないと、
必要以上に手間かかっちゃったりとか、
結局その人が1回で解決しないで、
2回目、3回目に伝えてきたりとかになるので、
本当にコストが高い。
になるので、あんまり言い方好きじゃないんですけど、
見てなしレベルに合わせて、
言い方、説明の仕方を変えるっていうのは、
やっぱり重要だなっていうのは、
特に今回思いましたね。
なるほど。
例えばエグセクティブな人たちに、
メールとかで質問の回答したってダメなんですよ。
もう席とやってやれぐらいの勢いなんで。
文章だけじゃなくて、ちゃんと会って話して、
操作して。
やっぱり相手が何求めてるのっていうのは、
汲み取る力必要ですよね。
社内ヘルプデスクとか、
外中の支援先とかは、
言い方悪いですけど、
マニュアル通りなので、
マニュアル以上のことはできないし、
求めちゃいけないので。
だからここでこの一言が言えてれば、
1往復で終わったのになとかってやっぱりあるんですよね。
自分というか相手とシステムの間の中で、
いかに適した情報を与えるかっていうのが、
12:03
この腕の見せ所にもあるし、
これってやっぱり目に見えないスキルになってると思うんですけど、
もっともっとこの翻訳力って言いますか、
適応力っていうのは、
これもう、ちゃんとしたスキルとして
世の中に定義されてもいいと思うぐらいの。
そうですね。
これ何て呼ぶのって単欲しいですよね。
システムだけではなく、いろんな経営でも何でも、
いろんな人と会話する上で必須な力だと思うぐらい。
そうですね。
これっていうのが、
ぜひともこれから伸ばしていきたいところだし、
そもそもAIとか、
先生AIとかの回答に対して、
いかに自分がさらに感情を乗せて答えるかとか、
相手の状況において答えを変えていくか、
これからまた必要なスキルになってくるんじゃないかなっていうのを
聞いておりました。
じゃあ今日の学びということで、
またホワイトボードの方からお互いにコメントを書きながら、
最後の一言ずつを話せたらいいなと思います。
はい、じゃあ本日の学び、気づきでございますが、
じゃあまず私の方から発表させていただきます。
はい、こちら。
巡活員を巡活する。
はい。
昔、特に僕らの世代の就職の時って、
よく会社の巡活員になりますとか、
まさに僕はこの濱中さんの存在自体が巡活員だなって思う。
現場の人やシステム会社の人といかに交渉、
コミュニケーションを円滑に取るかっていうところを徹底して考えて、
現場側の意見を聞く。
システム側のことを勉強してシステムの会話ができる。
お互いの中立に立って、
ちゃんと会社が良くなる方向性で皆さんを持っていくことができる。
これまさに巡活員の存在だなと思って、
改めてこの現代で巡活員っていうのが
必要なものになるんじゃないかなと思って、
今日学びとしてかかつていただきました。
ありがとうございます。
じゃあ僕ですよね。
ちょっと長いんですけど、
あなたの苦労は中では理解されなくても、
外なら分かってくれる人はいる。
上質ってあんまり恵まれないんですよ。
何もなくて評価Aにはならない。
何もなくて評価Aにはならない。
運用って何もないのが一番いい状態なはずなんですよね。
それだと評価ってされないんです。
今日僕もだいぶりょうさんに付き合ってもらって、
今回の苦労とかをあんまり社内で言ってないんですけど、
そこに共感なり賞賛なりをもらえて、
報われたという気がします。
こういう人って社内にあんまりいないんだと思うんですよね。
15:03
最近サーズクラウドサービスとか、
ツールごとのコミュニティみたいのがあって、
ウィングワークさんもネストさんとかのコミュニティがあって、
僕も参加してて、そこでもかなり助けられた経験があって、
承認欲求を満たすとかでもいいと思うんですよ。
何かこれ自分で頑張りました、苦労しました、
というのを社内だと誰も褒めてくれないんだったら、
こういうところに行くと同じ苦労を分かる人は絶対いるので。
同じ苦労をやってらっしゃる人は各社にいるから。
そう、必ずいるから。
いるところに行けばいいんです。
そういうのがあるので、一人常設の人は一人で泣いていないで、
こっちおいでと。
コミュニティとかでみんなで研鑽して励まし合いながら進もうと。
そこで会社に持って行ったら会社だってプラスなんですから、
やったらいいじゃんということで、
ちょっと長かったですけど、
今日の気づきというか、
皆さんに広まってほしいことって感じです。
なるほど、コミュニティとかでみんなで理解し合いながら、
こういう製品導入とかシステムの構築を進めていくということが重要ですよね。
重要だと思います。
ありがとうございます。
それでは本日のデータ判定は以上でございました。
皆さんご視聴ありがとうございました。
ありがとうございました。
