初っ端から引用。
このお二人の対談は非常に考えさせられます。
ちょっと昔の記事なので、会員登録しないと全文見られませんが。。
この対談ではEMSについて述べられています。このEMSを発展させたものがEaaSです。発展させたといっても、EMSをより咀嚼し理解しやすくし、かつ、対象を社内サービスという考え方から組織が他組織へ、または個人が別の個人へサービスを提供するという考え方に変えたものです。なので、本質的には同じ事を言っておりそれを別の切り口から述べたもの、そう解釈しています。
さて、本題。
個人的に全ての物事はサービスマネジメントに通じると考えています。何をサービスとするのか、どうサービスにするのか、それに対するコストをどう考えるか。それらを咀嚼し決定したものがサービス憲章（Service Charter）と呼ばれ定義されます。この単位（規模感です）を大きくすれば会社組織になりますし、小さくすればワンチーム、個人になっていきます。
今、私が取り組んでいることは、まさしく、チームとしてどのように「定義したサービスやモノ」を提供するのかを考えるのがお仕事です。
プロセス改善と言い換えてもいいかもしれません。どのように提供するのか？すなわち、トリガに基づいてプロセスが始まり、最後にアウトプット（提供する価値を体現したサービスやモノ）をどの程度のコスト（金、人、時間）をかけて提供し続けるのか。
これが明確になって初めてマトモなサービスが提供できる。
小難しいことを言ってますが要は売上原価を決めないとマトモなものは売れないとそう言ってるだけなんです。
ここでいう「マトモ」とは目標とする原価を達成して継続的に提供できるサービスにする、ということです。しかもそこには働く人たちの幸せまで入ってる。
儲けるとか相手の要求を満たすだけのサービスを追求するとか高品質なものを提供するということではないです。（とはいえ、赤字続きだったらダメですが）
そうだったら、今の時点でAmazonはこんな企業になってないですし、Googleもそうなってないでしょう。
最初っから目標とする利益を出せません。そもそも何がバズるかわからないんですから。
なので、これ（サービスやモノ）をこれぐらい（売上原価）で提供する！と決めてそこに向けて原価を調整する（カイゼン）する。
そうしないと、いわゆる「カイゼン疲れ」を引き起こし終わりがないドロ沼にはまります。
実はEMSやEaaSもそうではないかと思っています。例えば社内サービス。儲けは判断できませんが（売上がありませんが）、原価は計算できます。最初は原価でなくても良いです。例えばまずは提供時間から始めてみる。ユーザの満足度を測り適切な時間を決める。その上でそれを提供するのに必要なコストを測り、後は何円で提供するのかを決める。それの計算式を定義して変数を解き明かし、その変数が何なら目標となる原価になるのかを皆で考え進めていく。
そんな方法もありうります。
じゃあどうやって適正な売上原価を決められるのかってのは正直わかりません。
ですがこれは算数の問題であることだけはわかります。
方程式を構成する四則混合があり、そこに変数が複数あり、解（つまり目標となる原価ですね）が埋まっているただの計算問題です。
要は(x+y-z)/a×b=10みたいなもんです。
売上原価の構成要素は、簡単に一般管理費と仕入原価と販促費の集合体と捉えれば。
この時、気をつけなければいけないのは自分たちの給与や仕入れ元の生活です。
社内サービスとは言え、自前主義な事は今の時代ありえませんからパートナー企業あってサービスやモノの製造は成り立ちます。
つまり、「いくら払うべきか」には当然注意を向けるべきですし、サプライチェーン全体を見渡さなければ適正な原価にはなりえないという事です。
先ほどの適当な方程式で言えば、12>x>5みたいな。ここではxをパートナー企業に払う対価と考えていただければ。
要は、方程式を定義すると、その変数に対する制約条件をさらに決める必要がある。しかし、これをしようとすると究極の透明性が求められるはずなんです。
つまり……自分たちだけではなくパートナー企業の原価率、利益率をある程度（笑）把握、コントロールする、または究極の信頼性をもって信じるか。
これもトヨタ生産方式で体現されている事ですし、真のDevOpsで言われている事です。ここには究極の透明性が求められます。つまり、目標売上原価を合言葉に、誰がどの変数に責任（アカウンタビリティ）を持ち、チームとして全ての変数を目標に近づける努力をする。そして、それを実現するためには、現地、現物を確実に計測し、現実を可視化する。
計測することを怠っては、何も現実がクリアになりません。
そして、現実がクリアになれば、自ずと目標との差が見えてくる。
個人的には究極の信頼性と透明性を確保する方が将来にわたって盤石なチームになるように思います。
誰かが誰かにサービスを提供する。しかし、慈善事業ではないので、飯は食わねばならぬ。ということはサービス提供する側が売上原価と根拠を示す。
こういう努力を怠って、やれイノベーションだやれディスラプターの脅威だ、やれ働き方改革だ、とかいっても、誰もついてこないんです。
竹槍でB29は落とせません。必要なのは涙ぐましい努力や血と汗（プロジェクトX的な）ではなく、現実的な努力と楽しさなのです。
過去、こういった主張は、戦場の真ん中で「戦争はいけない！やめるんだ！」と叫ぶようなものだと私の主張を全否定された方がいました。
まぁ、それはそうです。けれど、その理想を語る努力を怠っては、戦争は終わりません。まずは気がつくことから始めないといけない。自分やチームは誰かにサービスを提供している機能である。そういう気づきから始まり、全体のプロセスを知り、改善へと走る。EaaSはそういう概念だと私は思います。
