社員を顧客とみなす潮流
顧客というと通常は社外を指しますが、社員(社内)に対してもそのように扱う潮流が見られます。
親しき仲にも礼儀あり、ではなく、ビジネスライクな関係でもない、第三の関係と言えるでしょう。顧客として扱うからこそ、選ばれる関係となって仕事も上手くいきやすくなります。
本記事では、このような潮流の例を整理します。
Platform Engineering
ITの話ですが、開発者は高度なIT環境を使っています。Teams のようなツールではなく、書いたプログラムを動作させる・管理するための基盤(プラットフォーム)です。
開発者は言わばIT備品をたくさん使っていると言えます。各個人で好き勝手に調達・整備しているときりがありませんから、通常の備品がそうであるように、会社として一律で管理してますよね。
ですが、一律管理だと融通が利かず、あまり役に立ちません。結局、開発者は自分たちで独自に整備することになります。
このような流れを変えるのが Platform Engineering です。
開発者のためのIT備品をちゃんと整備しよう、という考え方です。専用の部門やチームで統括する点は変わらないのですが、開発者をお客様と見立てて、本当に彼らの役に立つような整備を心がけていきます。
IT備品は、ただの備品であり、適当にやればいい、ではないのです。開発者達が常用しているものだからこそ、全社的にガチで取り組み、かつ寄り添っていくべき――そう考えます。
参考:
https://www.gartner.co.jp/ja/articles/what-is-platform-engineering
https://learn.microsoft.com/ja-jp/platform-engineering/what-is-platform-engineering
(日が浅くて、マニアックな解説しかないのでわかりづらいと思います)
デファクト・クライアント
新規事業において、なぜか上司が審査や承認を担当することがあります。
新規事業は顧客(あるいはその候補)の検証が大事であり、顧客でない者の意見はどうでもいいか、せいぜい参考程度にしかならないはずです。なのに、なぜか立ちはだかってくるのです。
これを当サイトではデファクト・クライアントと呼んでいます。デファクト(事実上の)お客様、というわけですね。
デファクト・クライアントは不毛なので、やめるべきですが、文化的・あるいは上司側のプライド的に、そうもいかないことが多いです。
この場合、実際にお客様のつもりで対応してしまうのが、なんだかんだ早かったりします。結局そこを越えないと始まらないので、お客様のつもりで対応してさっさと越えてしまいます。
BtoA
BtoC や BtoB の亜種として、BtoA を提唱します。
BtoA の A は Association であり、同社や関連会社を指します。
企業は社外の顧客を相手にビジネスをします。相手も企業だと toB、相手が消費者だと toC ですよね。
しかし、そうではなく、同じ社内の部門だったり、関連会社(親会社や子会社や兄弟会社)の部門を相手にすることも多いはずです。ここの結果が仕事に直接通じることも多いと思います。
であるならば、いっそのこと、Association もお客様扱いすれば良いのです。そうすれば彼らが持つ仕事や予算を分けてもらえます。
一見するとゼロサムゲームで不毛に見えますが、ゼロサムであっても関係性をつくれれば今後に生きますし、お互いが toB や toC の顧客を持っているはずで、でも自分達だけだと上手く仕事にできないところを、Association に頼ることで仕事にできるわけです――この場合はゼロサムではないですよね。
また、BtoA により、働き方を助けるといった視座にも立ちやすくなります。上述した Platform Engineering の、一般化バージョンですね。
先日、当サイトではワーク・ゲーミフィケーションをお伝えしましたが、これも BtoA の一種と言えるでしょう。
要は社員間で自由に仕事のマッチング(実際にお金もうごく)を行えるようにします。
経営者「社員はお客様」
ソースは失念しましたが、社員をお客様と扱う経営者もいると聞きます。
経営者だから偉いんだ的に傲慢になると当然社員はついてきませんし、勝手に「うちの社員はこうあるべき」「あなたにはこうなってほしい」的な期待を抱いても裏切られます。
ですので、いっそのことお客様と考えて「自分が合わせていくようにしよう」と考えるわけです。それが結局社員に寄り添った組織づくりにもつながって、会社自体も強くなっていきます。