「◯◯ではなく」のパワー、あるいは曖昧さの排除方法
プロジェクトのコンセプトとか、会社の経営方針を作る際に僕はよく「AではなくB」みたいな表現をする。
例えば・・
・生産量でNo1になるのではなく、品質でNo1になる
・ユーザーの使い勝手を上げるプロジェクトではない。事業全体の生産性を上げるプロジェクトだ
みたいな感じだ。
この様に、プロジェクトにおいて「◯◯ではなく」と明記する大切さを学んだのは、ケンブリッジのFMという方法論からだ。
FMは言ってしまえばシステムの機能一覧なのだが、FM自体にも、FMを作るプロセスにも、システム構築プロジェクトの失敗を防ぐ工夫が織り込まれている。
「作らないものをわざわざ明記する」もその工夫の一つだ。あまりに重要なことなので、工夫という言葉だとちょっと軽すぎるかな。
このままFMの工夫について書き始めたが、似た話を「システムを作らせる技術」にも書いたし、そこから抜粋したブログ記事も上げたことを思い出した。
https://blogs.itmedia.co.jp/magic/2021/08/fm.html
このブログに
★FMの効果②やらないことが書いてある
という段落があるが、これですよ。やらないことをわざわざ書くことで、起こりがちなミスを防ぐことができる。
僕は25年前にこれを知り、FMだけでなく、仕事全般にこの考え方を応用してきた。
プロジェクトゴールや方針を決める際に、わざわざ「◯◯ではなく」と書くのもその一例でしかない。
なぜ「AではなくB」という表現が重要か。
「Bをやりまーす」と言うだけだと、何も言ってないのとほとんど同じだからだ。
たとえばケンブリッジの経営方針書に「社員>顧客>>>株主」と書いてある。「社員ファースト経営」にも書いた、「まずは社員を第一に経営しないと顧客に価値を提供できないし、顧客に価値を提供しないと、株主に還元もできないよ」という当たり前のことを書いた項目だ。
このステートメント「社員>顧客>>>株主」は、このブログの文脈に照らすと「顧客や株主よりも、まず社員を大事にします」という意味だ。
これが単に「社員を大切に」だったら、昭和の日本的経営と何も変わらない。同じ人が「顧客満足度第一主義」とか言い出しそうだ。
だから、わざわざ「Aではなく」という意味もはっきりさせたうえで「社員>顧客>>>株主」と書いた。
さて、この様な理由で「AではなくB」みたいな表現をすると、「Aではなく、が表現としてキツすぎる」だの「誤解を招く」だの、「Aだってちょっとはある」だの、あらゆる理由で「Aではなく」を削ろうとする人が現れる。
こういう人は「Aではなく」と発表した際に発生するコンフリクトがありありと想像できるから、良かれと思って忠告してくれるのだ。
いや、そんなものは承知の上なんですよ。知ったうえで、削るくらいなら何も言わないほうがマシ、と言っているのですよ・・。当り前過ぎるステートメントはタダのノイズだから。
ちゃんと比較することで、はじめてオピニオンになる。「社員>顧客」と書けば、それは一般とは違うことが一目で分かる。質問や議論が起こる。
そうすればしめたもの。「そうじゃないと、むしろ顧客に良いサービスを提供できないんですよ」という話ができる。
（多少極端な）オピニオンをバン、と示して、深い議論に誘うのは、大事なファシリテーション技術の一つだ。
同様に「育成>売上」と書くこともある。
こう書くと「企業は売上がないと存続できないんですよ！」とか言ってくる人もいる。
そうですね。
そこから議論をすれば良い。まあ、そんなことすら分からないアホだと俺は思われているのか。。とは思うけどね。
最初に例として挙げた「ユーザーの使い勝手を上げるプロジェクトではない。事業全体の生産性を上げるプロジェクトだ」についても考えてみよう。
もちろん、使いにくいシステムよりも使いやすいシステムのほうが良いに決まっている。最近はUI、UXが重視されているし、僕だって駅ねっととか使いながら「くそUI！！」とか悪態ついている。
でも業務改革のプロジェクト、特に社内システムを作るプロジェクトでは、ユーザーの操作性が良いことの優先順位が低いことは多い（もちろん逆の場合もある。何事もケースバイケース）。
経営全体を見渡してユーザーの使い勝手の優先順位が低い状況でも、プロジェクトへの要望を集めると必ず「使い勝手の良いシステムが欲しい」がたくさん集まる。
そういう時は最初からちゃんと「あなたが楽になるためのプロジェクトじゃないんですよ、こういう風にして事業を良くするためのプロジェクトなんですよ」と宣言し、期待値を下げておくしかない。
「使い勝手」はいついかなるときでも目指すべきゴールなんかでは全くなく、事業を良くする有効な手段になることがある、というだけの話なのだ。
ということで、何億も何ヶ月もかけてシステムが出来上がった後でがっかりされたり、プロジェクトコアメンバーが猛烈な批判にさらされるくらいなら、最初から「ユーザーの使い勝手を上げるプロジェクトではない。」と言い切っちゃった方が良いのだ。
僕らのお客さんは紳士的な方が多いので、そう宣言することにためらいがあるのはよく分かるのだが。