転職理由としてのSIer転職者が言う「顧客の顔が見たい」、自社サービス転職者が言う「社内受託感」
私が自社サービスで採用をしていた8年間、SIerやSESからの転職希望者の多くは「顧客の顔が見たい」「顧客の声を聞きたい」という転職理由を挙げられることが多いです。
一方で、とある自社サービス企業から尋常ではないほど退職が続いておりまして何名かを呼び止めて話を聞いてみました。すると押し並べて出てくるのが「社内受託感」という言葉でした。「社内受託感」というのは自社サービスでありながらも外注であるかのように他部署から、あるいは上長から一方向で指示が降ってくるためやらされ感が強いというものです。
SIerやSESにおける顧客の声を聞きたい。自社サービスにおける社内受託感。この2つは何者であり、企業とエンジニアはそれぞれどうするべきなのかをお話します。
「顧客」って誰？
本題に入る前に「顧客」について整理をしておきます。
特に商流が深いSIerの方にたまに居られるのですが、toC向けサービスしか顧客が居ないように誤解されている方を見かけます。
toBなら契約先。
社内システムなら社内の利用者。
私は6年ほどtoCに関わっていましたが、物理的な顔の見えなさで言うとtoCが一番見えないです。何かしらの不具合や仕様変更を前に激昂して好き放題罵倒する匿名のレビューを「顧客の顔」とは呼ばないでしょう。
また、顧客がまだ居ないのはこれから売り始める新規の自社サービスくらいのものです。このあたりが理解されずに自社メディア>>SIer>SESという図式ができあがる傾向にあります。
そもそも何故顧客の声が聞きたいのか？
私が過去に手掛けていた自社サービスはありがたいことにユーザーから感謝の手紙を頂くことがありました。社員一同励みとなるお便りであり、サービスを離れた今も感謝しております。
一方でユーザーが増えてくるとサービス内容を問わずに直面する内容として、サービスが不安定だったり規約を変えるとAppStoreなどで「クソアプリ」「金返せ」「詫びアイテムを出せ」と荒れがちです。顧客の声の数をカウントすると圧倒的に罵倒が多いです。直接見るとビョーキになります。カスタマーサポート（CS）部門は本当に尊敬しています。
そのため個人的には「顧客の声を率先して聞きたいなんて酔狂だな」と思ったりしていましたが、論文でも証明された内容なようです。社会に役立つ行為をした直後には、頭の中にドーパミンが溢れ出すという研究があります。他人に親切にすることによって自身の幸福度がアップするということです。
こちらの論文に言及されていたのが下記の著書になります。こちらでは「貢献」と称されていました。
「自分の働きが他人にどう貢献しているのか？」が見えにくい
と幸福が下がってしまいます。
「その仕事がどれぐらい他人の生活に影響が与えられるか？」
というタスク重要性が求められるとのことです。
以前のコンテンツでもお話しましたが、元来何かしらのキャッシュフローがある以上、誰かへの貢献が成立しているはずです。しかしこの貢献が分かりにくかったり、感謝の言葉がリレーされる過程で途中で伝達されなかったりすると「誰のために働いているのか」という疑問に繋がり、より分かりやすい貢献が説明されていそうな企業に転職していきます。
エンジニアと顧客志向性: エンジニア→企業
まずは被雇用者であるエンジニアはどう動くべきでしょうか。転職する前に是非試していただきたいのが顧客志向性です。
権利ばかり主張しても優遇されるとは限りませんし、永続的に優遇されるようなことはありません。企業やサービスに対して言われたものに対する納品だけでなく顧客にプラスαの価値を提供することで指名される人材になりやすいです。
何も企画部署と張り合って企画提案する必要はありません。ログ解析から分かるユーザーの振る舞いを報告したり、システムの観点から施策に意見してロジックを変更し速度改善・UX改善したり、他社のシステム分析をしている人も居ます。
ロジックが通り、周りも賛同してくれた提案内容をいくつか出してみて相手にされなかったことを確認してから転職活動をしても遅くはありません。何も提案を試みない状態で「意見が通らなそうだったから辞めたい」というのは猫パンチにも劣りますし、面接でも不利です。
下記のコンテンツは就活・転職対策ではありますが、こうした活動の第一歩として有効ですのでご覧頂ければと思います。
エンジニアと顧客志向性: 企業→エンジニア
企業側はどう動くべきでしょうか？「お金を出すんだから動け」「良いからやりなさい」と指示するのは反発を産みます。その言葉の対象の人は、多くの場合転職が容易な人材です。1社目、微経験でも多くの場合は1年も経験があれば転職できてしまいます。
ディズニーの場合、必ず指示には理由を紐付けるようにしているとあります。そうすると指示された側には納得が生まれ、そこから工夫を凝らすようになるとのことです。逆にこれを省くと反発が生まれ、指示をこなすだけになり成果が縮小すると言います。
これはエンジニアであっても同じで、施策の意味合いなどをセットで伝えないと腹落ちせず、ただの作業者になってしまいます。私が見てきた範囲でも、忙しくてこの理由付けを怠ったチームは大体離反していくか雰囲気が悪くなります。また、極端な事例では、4次請けくらいのSIerの方に対して「何を作っていたのですか？」と質問した際、「飛行機の予約システムだと聞いているが上から来た詳細設計に基づいて実装していただけなので何を作っていたかは分かりません」と言われたことがあります。先の貢献のお話で行くと非常にまずい状態です。
また、顧客の声という観点では（多重の商流では難易度が高いですが）顧客のリアクションを回収して伝えるという一種の営業努力が必要です。良かったのか悪かったのか。私の場合も開発拠点が国内・海外を問わず、顧客から回収した感想や感謝の言葉は努めて伝達するようにしています。可能であれば発注元との会議テーブルに定期的にカメラオンにして同席させるのが望ましいですね。
特に自社サービスの場合はエンジニアがBizサイドに興味を持つように促す教育制度づくりをする必要があるでしょう。私が今取り組んでいるものにエンジニア向けのリーダーシップ研修作成がありますが、視座は大きなトピックスの一つに据えています。自身の仕事がどこからやってくるのか、何をすれば指名されるようになるのか、そのようなお話で組み立てています。
採用コストが増加する一方で定着率も低くなっている現状を踏まえると、指示に基づいたアウトプットが出れば良いというだけが企業としてのゴールであれば、どこかの受託企業に投げたほうが結果的には望んだ結果になるでしょう。なお、そのスタンスは現在はフリーランスでも厳しく、正社員と同等の配慮が必要です。
執筆の励みになりますので、記事を気に入って頂けましたらAmazonウィッシュリストをクリックして頂ければ幸いです。
https://www.amazon.jp/hz/wishlist/ls/COUMZEXAU6MU?ref_=wl_share
頂いたサポートは執筆・業務を支えるガジェット類に昇華されます！