なにしてみよっか

サービスってなんだろな?を細々と。基本マニアックなネタが多いです。トヨタ生産方式を信奉してます。某製造業の営業と社内SEをやってました。

ITILとトヨタ生産方式(訂正版)

2019年8月21日の未明に投稿しましたが、内容が伝えたいこととずれていたため、同日朝訂正版として再アップしております。

 

 

ふと、何かがつながった気がしたので。

 

いつも通り脈絡もなく、話は飛びますがお付き合いいただければ。

 

ITILの確かSOA(サービス提案と合意)とMALCで出てきたと思うのですが、サービスポートフォリオ管理プロセス、ならびにITサービス財務管理プロセスってのがあります。

 

私が学んだ時は、これらの理念だけ学び、講師の方曰く、「ま、理想論ですけどね(実際しようがないけどね)」というニュアンスのことをおっしゃっていました。

 

試験対策という意味で当時お勉強してそのままにしていたのですが、果たして本当にそれで良かったのかと、突然夜中に風呂に入ってて思いました。

このプロセスは……あー。やはりITIL Expertらしく、ちゃんと答えるべきでしょうか。。

ざっくり説明すれば、適切なコストで、必要なだけの成果を出せるサービスを設計しましょうって言うプロセス(サービスポートフォリオ管理)と、それに必要となるお金を確保しようねと言うプロセス(ITサービス財務管理)です。

とはいえ、やはり間違ったことを書いてもあれなので。。

‎「ITIL 2011 用語辞典」をApp Storeで

ご興味があればダウンロードを。

 

これ、1サービス提供あたりの売上原価を出せって言ってるだけです。別の言い方すれば、物一つの限界利益率を腹のなかに持っておいて、利益出してこいって言ってるだけです。

 

「営業職」と呼ばれる方、特に、物の卸や販売をしている方って絶対やってる。そうでなくても皆さんなにがしかこれを考えて生活しているはずです。だってそうでしょう。要はコレ「コスパ」ですよ。

 

主観的か客観的かの違いだけで絶対やってますって。

 

コスパを考えているから、より安い、またはより効用の高いものを求めて探し回るわけで。

 

このコスパを定める「軸」が実は原価ではないかと思うのです。

そして、原価とは、決めたら動かないものかといえばそうではない。

原価低減という言葉があるように、原価は無理せず、妥協せず下げるものなのです。その低減の手段が、工程で品質を作り込む、無駄を省く、省人化(≠省力化)ではないかと。

 

そうなんです。実はITILは、原価低減活動をちゃんとプロセス化していたんだって初めて認識しました。

 

コスト低減活動と思っていましたが、実は違っていて原価低減なんだと。そのために今の品質の原価を明らかにして、事業と確認する。それがちゃんとITILのブロセスには明記されていた。

 

これ、似たようなことを言っているように見えますが、違うんです。

 

コスト低減は、品質や働く人の幸せレベルをを落としてもいいからかけるお金を削減することです。

原価低減とは、品質は保ちつつ、働く人の幸せレベルを保ちつつコストを低減させることです。

 

これは明確に異なります。

この発想をサービスマネージャーをやった時に気がついていれば、もっと良いサービスが作れたかもしれない。少しだけ悔しいです。

業務とプロセスとフローとタスクを勘違いした話(長編の派生)

最近、小難しくマニアックな話をたくさんしてきてしまった気がするので、ちょっとお茶請けにでも。

 

私の仕出かした(いや、現在進行形なので、仕出かしてる)失敗談の話。

 

よくある話。

「今これに困ってるんです!」

「このデータを加工したいのにできないんです!」

「この作業にこれだけ時間がかかってて、困ってるんです」

「もっといい方法があるかもしれないんですけど、私にはこれしかできないんです。」

 

などなど。

 

よくある(ありますかね?)ギョームカイゼン、プロセス改善の時の課題発見のトリガーになる言葉たち。

 

ほんと、ほんの少し前に気がついたのですが、これって、あまり役に立たないなって認識しました。

 

例えば、RPAが始まり出した時ぐらいにノラロボット問題とか、メンテに時間がかかる問題とかがとりだたされてました。

 

最近はRPAの使われ方も結構マトモになりつつあるのかなぁと思います。よく言うじゃないですか。RPAを使う前にプロセスを整理しましょう!業務を整理しましょう!とか。

 

他にも無駄を省こう!とか。

 

だけど、よーく、考えて欲しい。

 

それ、タスクの整理になってませんか?

それ、フローの整理になってませんか?

 

いえ、いずれも業務の整理であることは変わらないのです。ただ、本質的にはプロセスを整理しないといけなくて。

 

余談ですが、私の得意な戦術にフローと登場人物を書き出して役割を記載し、役割を再度割り当て直して登場人物を減らしフローの流れを早くする、というテクニックがあります。

ちなみに、これを使った活動で最高に効果が出たのは、1サービスの提供までに15営業日かかっていたものを、リードタイムを5営業日にまで縮めた事があります。

 

TMSで言う7つの無駄のウチ「移動の無駄」を省く、と言うものかなと思ってます。

 

ただ、これは、フローの整理に過ぎず(フローの整理を突き詰めるだけでもこれだけ早くなるってのもどうかと思うのですが)、実際のところ、本質的なプロセス改善には至っていなかったのです。

 

少し混乱してきそうなので解説すると。

プロセスとは、抽象化されモデル化された大枠のものです。極端なことを言うと、

仕入れる」→「作る」→「売る」→「仕訳る」これがプロセス。

要は、組織間の関係性を可視化して、最終ゴール(≒儲ける)に持って行くまでのモデル図。

フローとは、これらプロセスの中のものや情報の流れ。

誰が、誰に、何を、何して、渡すのかを図式化したもの。

例えば先ほどの「仕入れる」であれば、仕入れるものを探してきて、上司に稟議書を切って、承認されたら発注して〜となるはずです。

これを表したものがフロー。

 

じゃあ、タスクは?

そのフローの中に表現される一つ一つの作業、といえばよいでしょうか?

例えば、先ほどの仕入れるものを探してくるというフローの一要素がありましたが、これ、探すためには目的の素材を定義したり、仕入価格を決めたり、その素材でいいのか、仕入れ元は仕入れ元としての基準を満たすのか調べるとか色々やらなきゃいけないことありますよね。これら一つ一つのものがタスクです。

 

お気付きの方もいるでしょうか?RPAは使う前に業務を整理する、プロセスを整理することを大切だと言ってます。

RPAはタスクを省力化するもののはずなのに、何故かプロセスを整理するんです。

 

悪い営業が、テキトーなこと言ってるパターンもあるかもしれませんが、これは本質的に痛いところをついてくるなぁと思うわけです。

 

その仕事、業務、プロセスに、そのフロー、タスク、必要ですか?をまず考えましょう!って言ってるんですね。それをしないと、ノラロボットやメンテが大変なロボットが生まれると。まぁ、他人が作ったエクセルのマクロだと思えば大体あってるのでは?と思います。

 

ああ、話がすっ飛びました。

 

私がした失敗ってのは、最初の言葉「これに困ってるんです!」を真に受けて、タスクを整理してしまい、プロセスにたどり着けなかったってことなんです。

 

言い訳ですが違和感は感じてたんです。なんか違うなと。頭は痛くなるし、自分のやっていることや考えていることに違和感も感じてました。でも、止まれなかった。で、ある日同僚と喋ってだときに気がつかされました。

あれ?これってプロセスの改善してなくないかと。タスクやフローの可視化には繋がってた。けど、けど、プロセス。つまり、モデリングされた大きな流れに全くたどり着けてないと。

 

それからは、まず今まで集めてきたタスクが、どのプロセス、またはフローに準ずるものかを必死に書き出しています。タスクなのかフローなのかは気にしてません。つまり、どんなプロセスが存在するのか?を理解するために、今目の前にある事実を書き出していってます。

 

で、これまたつい最近気がついたのです。

あ、これ、社長だと。

当ブログの最長シリーズ「SoRとSoE」の第5回で申し上げた「社長」の話です。一つのサービスを提供する上で必要となる機能をバックログに取り込むためには社長やって肌感覚を身につけないと難しいんじゃない?という話です。

 

どうも、社長にならなくても、ビジネスプロセスを作ること、可視化することは出来るんじゃないか?そう思ったわけです。

 

今の取り組みが成功すれば、社長にならなくてもピジネスプロセスを理解し、可視化するコンサルタントにはなれるんじゃないかな?と思ってます。要は、あるべきプロダクトオーナーになれる。ただ、この取り組みをする上で最大の障害があって。。

日常オペレーションにかなり時間を取られそうな上に、私はこの「ルーチン」を行うということが死ぬほど苦手なんです。総合職としての立場上、PMだけをやりたいというのもはばかられ。。うーん。ルーチンに忙殺されるほど本末転倒なことはないはずなのですが。。

 

 

働いてもらう環境、整ってますか?(長編の派生)

ちょっと特別編。

ちょうど3回目を書いた時に、ん?もう一つあるな、と思いついたので。

 

長編SoRとSoEの3回目でこんなこと書きました。

(前略)

前回申し上げたEaaSの話にまたなっちゃいますけど、社内システムから見れば、利用者は顧客なんですよ。顧客が満足しないシステム作ってるのがいわゆる社内情シスですからね?

(中略)

働き方改革が叫ばれ生産性向上が急務と言われても、実は働いてもらう環境が生産性を上げてない

(後略)

(太字は今回改めて強調)

今所属している企業もそうなのですが、いわゆる基幹系と呼ばれるシステムって「お客様」が管理する側なので使いにくいシステムが仕上がります。最近はもっと悪い方にシフトしているような。

ただ、ここまで書いておきながら悲観していません。

いわゆる社内情シスが「お客様」を見るという意識になってきているのは肌感でわかります。

ただ、本当のお客様はユーザーであり、SoRで記録する側ではないはずなのです。

いわゆる社内情シスが「お客様のために」より効率を、より効果を求める姿勢は進展しつつあると思いますが、残念ながら顧客を「SoR使う」側(SoRに使われる側ではなく)にしているため、どうやって効果効率的に記録を取るかに焦点が当たっていて、余計残念なシステムの出来上がりです。

ですが、いずれ変化します。システムは今まさに外部との競争にさらされ、本当に必要なシステムのあり方について徐々にですが舵を切っています。企業が残っていれば、ですがいずれ変化すると思っています。

 

それよりも。

これらシステムが乗るいわゆるインフラストラクチャ、簡単に言えば、ネットワークからハード、MW、OS層ですが、これらが本当に働いてもらう環境として生産性を上げることを意識しているかと言われると疑問が残ります。特にネットワーク。

今のネットワーク層は社内と社外を明確に区別し、守ることが至上命題になっています。

 

勿論、それは正しいです。ただ、それだけが正しいわけではなく、区別しつつ、必要なところと必要な時につなぐ事、それが本来のあるべき姿だと思うわけです。

 

先ほども申し上げた通り、「お客様」に寄り添ったシステムは積極的に社外から社内につながって来ようとしています。

また、SoEは社外の方が何かと都合が良い上に、お客様は社外にいるので自然、社外にシステムというか窓口は置かれていきます。従って、お客様と繋ぐものは外、記録するものは内、という流れができてきます。今はまさにその過渡期。余談ですが最終的には「社内」「社外」という区別のない世界になるでしょうし、していきたい。

 

しかし、そうなってくると困ったことになります。

今の過渡期のタイミング、社内のシステムに記録する方法が無い、または、記録する際に必ずGWを通るが故にGWの通信が逼迫する、または、記録するためには必ず人手の加工が必要になる。など。簡単に言えば、「人手を介するので調整先が増える」

 

本稿通じて何度も申し上げますが、エンドツーエンドのサービス、つまり、「お客様」からお客様が支払ってくださったものやお客様の情報などを記録するところまでをワンサービスと考えると今の内外を区別し、審査するインフラの考え方では絶対に自動化できず、働き方の改革なんてできないんです。

どこかでモノや情報は滞留し、どこかでバッチ処理をするか通信が破裂して全体影響が出ます。

例えば、バッチ処理は特定の時間になるまでWIPとして溜まり、かつそのデータが不良か否か(正確には欲しい情報になっているかは分からないとも言いますかね)は処理するまではわかりません。つまり、確かめる方法がない。

また、GWに流れる通信量の肥大はどのような通信をしているのかを追いかけ続けないとわかりませんが、それだけのリソースや予算はあり得ないので、破裂するまでは理解できないはずです。

 

実はこれらシステムやインフラが、「バッチ処理」や「とりあえず集中監視」をしている状況が効率化できない働き方の原因なんだという事を認識せねばならないと思います。

 

余談ですが、社内情シスとしてこの懸念を発信しておりましたが、受け入れてはもらえませんでした。致し方ないと思います。私の言い方も悪かったです。社内情シスを離れ、こういう発信手段を手に入れるまでは私もちゃんと説明できませんでしたし。もっとも、「社内」と「社外」の境界が曖昧になることは失礼ながら馬鹿でもわかる事なので、何か別の理由があるのかもしれませんが。

 

いずれにせよ、日本に足りていないのは、実はSRE(Site Reliability Engineering)ではなくて、今作った造語ですがSIE(Service Infrastructure Engineering)ではないかと思います。

つまり、サービスを提供する上で必要となるインフラにおいて論理的にも物理的にも全世界でエンドツーエンドで物事を見られるエンジニアです。

 

インフラ領域を仮想化して抽象化し、ビジネス(アプリ)に影響が出ないようにすることは非常に難しいですが、それが理想です。サービスに必要なアプリの設計に気が回っても、それがどのようにインフラに影響が出るか分からないためです。というか、わかりようがないです。論理構成図と物理構成図、さらに言えばどのような通信や処理がインフラそうで行われているかなんて可視化する仕組みないですから。

そして、仮に分かったとしても、そこを通すために調整する時間なんてビジネスサイドからすればもったいなくてやってらんない。要は、安心安全に通してくれ、それ以外求める要件なんかないのです。

ではどうするかというと、抽象化を維持するためにリアルな世界を知っているエンジニアが必要ですが……いると思います?

どのような通信、どのようなインフラが存在し、そこで何が行われているかを肌感で分かっているエンジニアです。そして、そんな彼ら彼女らはビジネス側に精通し、ビジネス側のスピードに合わせてインフラを増強し、かつ何がバズるか分かってる人。いませんよ。

わかりますか?外部から人持ってくる。運用エンジニアを外出しする。そんなやり方をしてきた結果、自社内で通用する社内SEいなくなるんです。

今までのような長い時間をかけてジェネラリストを養成するようなことをしていては間に合いません。そして、アウトソースしまくった結果、社内にいません。

システムや構成を知っていて、その上のレイヤに既存のサービスやシステムを重ねることが出来て、かつその役割を知っていて表現できて、そのさらに上に新しいサービスやシステムのトポロジを乗せて危機感に対するアンテナを張れる人材。私が知る限り、そんなのいないです。

 

だから抽象化し、俊敏なインフラに変える必要があるんです。さらに、サービスが立ち上がるときに肌感でこういうサービスを組むならこんな仕組みにしないと危険だぞ?と思えたり、可視化できる人材も。

 

もしくは、極論ですが、WANなんてものはなくしてしまえばいい。そうすれば、少なくともネットワークのインフラエンジニアは不要です。守るべきWANがないので。

 

こういう時、一般的なITサービスマネージャなら、「SKMSやCMSを作りましょう」となるのでしょうが。

SKMSはあくまで概念に過ぎないと思っているのでまぁ、それはおいておきましょう。

 

話が予想以上に長くなりましたのでちと強引にまとめますが。

 

働いてもらう環境、整ってますか?仕事をしたいと思っている人間が社内調整に駆け回っていませんか?

本来為すべきことを出来る環境、整えてあげてますか?

アプリ、つまりビジネスを支える直接的な物は今後もっと自動化、ローコード化が進むでしょう。そうなった時、インフラはそのカオスを支える仕組みを持たねばならない。それを人手で回すのは絶対的に不可能なのです。

人の神経回路と同程度のスピードで流れ、かつ人の脳みその容量(記憶によれば5テラ?ギガ?バイトだったような)を超えるデータを支える仕組みを人が保守運用することなんかできるわけがないのです。それは人間の限界を超えている。

人間で処理できる限界を超えたものを人手で回すことなどどう考えても不可能です。これは人手不足などという話ではありません。人の限界を超えている話なのです。

 

故に、インフラストラクチャは抽象化し、仮想化し、ビジネスの成功を願う者たちを影で支える黒子に徹する仕組みに変える。黒子なので、表舞台の調整ごとなんぞに出てきません。調整する時間もムダなのでムダなことをしないように変化する必要があるのです。

「仕事」を表舞台の人間にしてもらうために、調整などというその人間達の「業務」をなくして差し上げる。それこそが、社内情シスに求められる「仕事」なのだと思います。社内から調整ゴトのメールが送られてきた時点で、インフラの職責を果たしていない。そういう時代なのではないかと思います。

 

ちとトゲがありすぎます気もしますが、今、まさにインフラを守る方々の仕事を揶揄しているわけではありません。インフラの仕事が変わったということを申し上げたいだけです。今までのように調整ごとやCABを開く事が仕事ではないと。アプリを扱う人々に調整ごとを投げかけない環境を守る事が、インフラの仕事なのだと。そういう意味では、SREに似ていなくもないのですが。ただ、私の唱えるSIEは、それらSREが面倒見るサービスの維持というよりも、もう少し大きく、全社的な意味合いでの調整役(対人間ではなく、対システム間の調整という意味で)です。

そして、それをできていない企業のインフラは、インターネットに飲み込まれ、職場を失う。そう思います。

 

そして、アプリの方々にも言いたい。今、「お客様」を見たサービス設計できてますか?企業の最終目標は、決算として表現する事です。つまり、会計仕訳を施して、記録する事で、本来のサービスの成果が見えてきます。

お客様の支持を獲得しているか否かは、究極的にはこれでしか測れません。

いわゆるビッグデータや分析基盤とうたわれるようなものを作っても、所詮は数字(でデータ)遊びに過ぎず、お金がどれぐらい儲かったか。これにつきます。

したがって、全ての仕事はこの会計仕訳に向かって進んでいくはずです。裏を返せば、この方向に向かって進む限りにおいては、「調整ゴト」は全て無駄です。もっと言えば、会計仕訳を作る作業なんて無駄の極致です。(決算書を作るというお仕事を言っていません、仕訳を作る作業そのものです)

本来は、何かを売りそれが確定すれば、次の瞬間には会計仕訳として記録されてなければいけない。ムダを究極に排除するならば。

 

いやいや、売るだけが仕事じゃない?そうですね。でも、なにがしかの作業をして給与という対価を得ているなら、そこに人件費かかってますよね?つまり、一ヶ月に一回は会計仕訳に貴方に支払った給与は記録されるべきですし、そこにかかったコスト(光熱費やパソコンのリース料、または減価償却などなど)が乗ってくるはずです。マイナスの記録が。つまり、一般管理費が乗っかってくるということです。売上総利益(粗利)をどこまで精緻に出すかによりますが、今回たとえにあげた人件費なんてものは、月末締めの翌月払いであれば、支払い日前には確定しているはずです。一般管理費仕入原価と雑経費と人件費と仮定すれば(そんなわけないのですが、あくまで例として)、少なくとも翌月第一営業日には確定できるはずなのです。なぜできないんでしょうか?

それが、サービスを使う目的であり、理由であると思うのです。

SoRとSoEはちゃんと考えようって話(5/5)

ついに最終回。

前回やこの長編全部を確認する場合は、タグから選んでください。

 

今まで、SORとSOEの違いやどうシステムを作るのか、といった話をしてきました。長々とお付き合い、ありがとうございました。

 

最終回は、じゃあどうやったら、そういうサービスを考え、システムを作り、ビジネスとしてなりたたせる、そんな人材になれるのか。それを私なりの解釈でお話しできればと思います。

 

端的に言えば、スタートアップ企業の社長になるしかありません。(笑

 

何かを仕入れ、作り、売り、儲けを記録する。その一連の流れを把握しない限り、ちょっとそんな人材作れないんじゃないかと思います。

 なので、やはり自分が経営者になるしかないと思うんです。副業とかでもいいですが。

 ハンドメイドでもいいと思いますし、自分の経験でコンサルするのでも良い。とにかく商いを一つやってみる。

そうすると、嗅覚というか勘所というかそういったものが身につく。

 

とはいえ、いきなり自営業始めるって難しくない?そもそも雇われだし、そんな時間あるの?リスク高いよ、無理無理。

うん、私もそう思うんです。(笑

で、じゃあ次善の手って何があるかなぁと考えたのですが、作る(または仕入れる)事から売り、お金を回収するところまで全部体験して学ぶ事なんじゃないかなぁと。一つの会社で学んでもいいですが、なかなか人事な事なので、かなり恣意的に進めないと難しいです。そうなると、もう、この際アルバイトでもして学んでもいいんじゃないかなと。

ただ、これにも弱点があってですね。スーパー時間がかかる事と、主力事業がある会社ならまだしも、これから新規事業起こそうって段階だと経験のしようがない。さらにはアルバイトでも〜と書きましたが、アルバイトにそんな経験をさせる企業が多分いない。

ちなみにここでいう経験ってただ単にラインに立って実際に物を作るってことではなくて、お金が物に変わり、またさらにお金に変わるという計数管理の話なので、ただ漫然とアルバイトしてりゃあいいってもんでもないんです。

 

じゃあ、ただ単に数字を集めて眺めてりゃいいのかってことでもなくて。

お金→物(仕入れ、仕掛かり)→加工(工数付加)→物(製品)→お金→仕訳

に流れていくので、ものを見たらお金に変えて、お金を見たら物に変える。そんなセンスを身につけるための経験になります。で、物だったらまだましなんですが、サービスになるとそもそも無形になるのでサービスを有形のナニガシカに見せ方を変えるってセンスも要ります。

一言で言うと、カオス。

 

このセンスを磨こうとすると、大企業はかなり難しいです。知る前に定年が来る。人が多い分、その中に入り込んで実務やりながらこれを学ぶと言うのはそんな人材に育てるんだと強い意志を持って人材育成しないと大変だと思います。それこそ、雇用の自由を奪う契約じゃないと。

ジャストアイデアですが、大企業でもできないことはないと思うのですが……ただ、それは理想すぎて無理かなぁ。理想的にはティール組織的な上も下もなく、かつ8人で一チームにすればできなくもない……はず、多分。

 

ただ、こう言う働き方をしようとするとそれに乗れない人も出ます。そういう方はノードになってもらうしかないので、人間性を捨てて働いていただく形になります。まさしく、替えがきく人材として。

ノードと例えたのは意味があります。ノード、つまり通信における接続装置ですが、要はSoRやSoEとダイレクトに接続させられないが故にそこに接続装置として存在するという事です。

例えば、経理システムに数字を打ち込む行為は請求書や領収証という紙で届けられたナニガシカの値をシステムで処理できるように変換している行為と考えられます。要は、紙というシステムでは食えない通信手段をシステムに食わせるための変換とデータ接続の役割を果たしています。故にノードと、そういう事です。

いや、わかりやすいと思ったので例にしましたが、この仕事そのものを揶揄したいわけではありませんので誤解なく。

 

なので、「仕事をする」という意味では1サービス8人で良く、ノードを含めれば8人にこだわる必要はありません。

 

これを極言すれば、「仕事をする」をexecutionと読み替えるとピンと来るかと思います。

 

執行役員は8名以下であるべきで、それ以下の人は全てノードです。

 

ふむ、と考えると、やっぱりそういう人材になるためには、自分が社長やるしかないってことですよ。とはいえ、家族や自分の飯を食うってのも大切なので、やっぱり複業、になるんでしょうね。

最近、Microsoft社が週4日勤務に変更しましたが、アレもこのロジックで考えると面白いですね。要は1日自分のために働いて良いって事ですから。

 

でも、そんなに社長になれる人は早々いません。そうなると、複数人、各々のスペシャリストが信頼しあってマイクロサービスを考えるべく、ワイガヤする。

難しいですねぇ。コードをかけつつ、サービスを考える人材。

コードを書くという特殊技能は、いずれローコード化が進みもっと万人にウケるものに変化するとしても、マイクロサービスを想起することのできる人材を作るために、サービスを考えるのではなく、サービスに分解できる人材が求められる。どういう学びを繰り返せばそういう人間になれるのか。

少なくとも漫然と生きていては達成できないような気がします。

 

まとめます。

今の世の中SoRとSoEを意識したシステムを作る必要があります。SoRとSoEは各々疎結合であるべきで、そうするために開発部隊はビジネス側のしたいことをより細かく小さいサービス単位に分解してシステムとしてなりたたせる必要があります。そして、その細分化された各種サービスを組み合わせて一つのシステムとして成立させるためには、物事をお金という数字に読み替えて、川のように流すこと。留まらず、滞留せずにストーンと流す。

そんな流れを実現することを意識してマイクロサービスに分解するってことをできる人材になりたいなら、自分でやってみるしかない。

ということかな。さて、そうと決まれば、私は何を提供できるんだろうか?

 

 

このような流水化される仕組みを実現すると可視化が進みます。嘘やごまかしが存在しない値になる事で、どう見せるかという議論だけになります。要は、よく言われるダッシュボードになります。

因みに、蛇足ですが、なぜここまでお金にこだわるかというと、今まで述べてきた通り、それが最終的に企業の決算にハネるからです。そして、お金はお客様からの支持の証になるためです。

どれだけお客様から支持を得たのか。それを確認する手段がお金である。と言うことです。

SoRとSoEはちゃんと考えようって話(4/5)

4回目です。

前回やこの長編全部を確認する場合は、タグから選んでください。

 

前回まででSoRもSoEも大切であり、でもそれぞれの役割の違いと求められる俊敏さの兼ね合いから疎結合なシステムでなければならないという話をしました。

余談になりますが、それはお客様向けのシステムであっても、従業員向けのシステムであっても変わらないという話もしました。

 

今回は、じゃあそんなシステムってどうやって作るの?って話です。

 

実は前々回のAmazonでお買い物する例えにヒントはあります。

こう書きました。

SoRに記録されている購買履歴とSoEの欲しいものリスト、閲覧履歴、さらにSoRの他の顧客の購買履歴とを突合させ、SoEとして「この商品を見た人はこんなものも買っています」(レコメンド)機能を出します。

欲しいものをSoEのカートに入れ、SoRで決済します。

SoRとSoEを行ったり来たりするもいうことを伝えるためにかなり端折ってるのは申し訳ありません。

この顧客体験を究極にシンプルにすると、

  1. 買い物に来る(アプリの立ち上げ)
  2. 商品を検索する
  3. カートに商品を入れる
  4. お届け先を入力する
  5. 決済する

以上。これら各々SoEのサービスです。いいですか?これから各々個別のSoEです。

 

前々回は決済はSoRって言ってました。すいません。実は正確に言えば決済した後、会計上の仕訳を行うフェーズがSoRです。しかし、お客様が決済を行うフェーズではSoEなんですね。

 

今回は端折らず正確に書きましょう。(と言いつつ、抜けてるかもしれません)

 

決済するってのは、こういうことなんです。

 

例)お客様がご自身のクレジットカードで決済する場合

  1. お客様がクレジットカードの番号を打ち込む
  2. 信販会社に問い合わせる。
  3. 信販会社が与信枠を確保する
  4. 信販会社が仮売上を立てる
  5. OKがカートシステムに返ってくる。
  6. 在庫が引き当てられる
  7. 理論在庫が1つ減る
  8. 「注文ありがとう」画面に変わる
  9. 購入履歴に記録される
  10. 売上、経費(輸送費、手数料など)のお金が仕訳られる

 

うーん、今思いつくのはこんなところでしょうか?

 

私の認識では、SoRは6,7,9,10で、それ以外はSoEです。とはいえ、これを一個ずつ作って疎結合にするのはナンセンスだと思います。

個人的な意見ですが、これらの手続きというかタスクを洗い出したら、「誰が」「誰に」を意識し、fromとtoが一緒なら1つの機能にまとまるかなと思います。今回の例なら2と3と4、6と7かなと。

そうすると決済に関わるプロダクトバックログは、SoEが4、SoRが2。合計6つになります。

これがシステムの作り方、だと思います。

 

今回はあくまで一例でかつ、現実的ではありませんが、イメージは掴んでいただけたでしょうか?

 

今回お伝えしたかったことは、今回の例のような1つのサービスを考えた時、プロダクトオーナーは、5つのバックログを考えるでしょう。しかし、スクラムマスター(とそのチーム)はその5つのうちのたった1つを6つにより深く分解し、バックログに登録する。

つまり、○○を提供したい!をバックログに落とし込むためには業務フロー、業務タスクをより小さく選り分け、かつどれをシステム化するのか仕組みでカバーするのはどれかなんてことをプロダクトオーナーと決めていかないといけないということです。

そしてその中にはSoRもSoEもある。

 

これをマジのガチでやろうとすると今までのような会議体では絶対にできません。

チームで寄り集まり、何を作るのかを全員が同じ目線で認識し、ワイガヤでやらないとバックログはできませんし、減ることもないでしょう。

 

そして、プロダクトオーナーは元より、スクラムマスターもサービスの内容を熟知した上で、かつ、サービスで儲ける内容をエンドツーエンド(顧客に届けることからビジネスの成果を記録するところまで)を認識していないとどのシステムを作り、どの既存システムを活用するのかを判断できません。もっといえば、記録したデータに基づくKPIを設定する事で、経営から現場までゴールに向けた即断即決のビジネスプロセスが生まれます。

 

スクラムマスターはどう頑張るか。

チームとともにサービスを構成する業務プロセスを細かく分析し、細かいサービスに分解し、それをプロダクトオーナーに理解させる。チームを鼓舞し、ティーチング、コーチングし、自分たちの提供するサービスの中で作るのか、それとも外部のサービス(既存のシステムを含む)を使うのか、仕組みでカバーするのかを決めるまたは決めるための判断材料を整え交渉する。つまり、社内を渡り歩くだけの知識を持った人間として立つ。

これが、スクラムマスターが頑張らなければいけないことだと私は思います。

 

今は、サービスをお客様に提供することにフォーカスが当たっていますが、近いうちにそれを記録するところまでを見据えて仕組み化(あえてシステム化とは言いません。なぜなら、システムとして構築するのは手段に過ぎませんから)する事にチャレンジしなければなりません。

なぜなら、経営はそれを欲しているからです。自社の成果を見えるようにするためには記録することをサボっては即断即決になりません。

経営は現場から一番遠いです。でも判断は経営がしないといけない。現場で起きていることを目の前に。そのためには、リアルタイムでのデータの記録と可視化。

 

今、企業にある記録するための基幹システムはおそらくそんな機能は備えていない。それだけはちょっと悲しいことなんですけどね。

 

 

さて。

SoRもSoEも大切であり、密接に絡むものでありながら疎結合でなければならない。ユーザー企業の担当者(プロダクトオーナー)はもっと全体(お客様から成果を記録するところまで)を俯瞰して価値を提供するという考え方にならないといけない。そんなことをお話ししてきました。

 

では、そんな人間にどうしたらなれるのか。今の私が一番苦しいところを共有できればなと。

SoRとSoEはちゃんと考えようって話(3/5)

3回目です。

前回やこの長編全部を確認する場合は、タグから選んでください。

 

前回はSoRとSoEは密接に繋がっていて切っても切れない、だから両方とも大切なんだ、というお話でした。

今回は密接に繋がってるけどワンパッケージにしちゃいけないって話です。

 

もうお気付きの方もいるかもしれませんが、SoRとSoEは役割が違うので一緒にしちゃいけないんですね。

なんでかというと、SoEは追加開発、変更が当たり前だから。まぁ、これはギョーカイ長い人ほど頷いて下さると思いますが、変更を繰り返すと変なところから綻びが出ます。

よく老舗の温泉旅館だと言われますが。増改築を繰り返したためになんか変な段差ができた、とか。ぐるっと回る廊下があったりとか。

よく言うじゃないですか。1行のコードを変更するのに半年かかる、とか。

なぜこんなことになるか。記録するってことに影響が出ないかを確実にしないと企業の存続に話が及ぶからです。SoRに影響を与えることは最終的に企業の首を絞めるからです。

 

だから、1つのサービスを1つのシステムで提供しようとするとドエラいことになります。

正確に言えば、今の時代は。

昔は良かったんです。それ(1つのサービスを1つのシステムで作って)でも。だって、差別化の手法に顧客満足度を上げるって選択肢がなかったから。

その名残が残っているのがいわゆる「社内システム」ってやつじゃないですか。今でも顧客満足度を上げるって選択肢ないですもん。サラリーマンの方にお伺いしたいのですが、今あなたが務めている企業でしか使わないシステム、外に売れるって思います?これ便利だから、他の企業の人に使ってもらおうよ!って言う人います?

前回申し上げたEaaSの話にまたなっちゃいますけど、社内システムから見れば、利用者は顧客なんですよ。顧客が満足しないシステム作ってるのがいわゆる社内情シスですからね?私が言うのもなんですけど。(社内情シスでした)

 

これ(社外に売れない社内システム)はSoRを重視するあまり、SoEに無頓着になってしまった典型だと思います。

 

働き方改革が叫ばれ生産性向上が急務と言われても、実は働いてもらう環境が生産性を上げてない。これは社内システムだからこうなっているだけで、お客様、最終消費者から見れば関係ありません。新しくかつ充足感のあるエンゲージメントを提供してくれるプラットフォームに乗り換えます。別の言い方をすれば、消費に関わる行動を効率化するために、新しいプラットフォームに乗り換えるってことです。

あ、やべ、これじゃない!と提供側が感じたらすぐに切り替える俊敏さが必要です。そこで記録に与える影響を精査するからと半年も待ってたら企業の収益力が低下する。ゆえに、SoRとSoEはしっかり分けないといけないんです。

 

OK、わかった。でも、ウチは関係ないよ。と思った方。SoRとSoEをワンパッケージにしてはいけない理由はもう1つあるんです。

 

それは、SoRも変化を求められるってことなんです。は?と思った方。

例えば、労基法が改正されました。それと同時に安衛法も改正されましたよね?働き方改革関連法の改正って一絡げにされてましたけど。

その中で、労働時間の把握が自己申告だけではダメになってます。簡単に言えば、タイムカードをガシャコンッとして把握するだけじゃダメよ、と。客観的事実で労働可能だった時間を把握しなさい、というルールが追加になってます。ハイ、新しく記録しなきゃいけないものが増えたんです。この是非はさておき(個人的には意義は理解するけどやらんでもよくない?と思います)、こうしてSoRも変化を求められる時代になったんです。追加要件だ〜って丸投げしますか?さらに言えば、この新要件対応のためにしばらく勤怠管理システム使わないでくださいって言えますか?言えませんよね。今までのやり方で考えれば、土日や時間外にリリースする、でしょうか。でもその時、担当が育児のために土日出られませんってなったらどうします?いや、今のご時世普通に起こりえますよね、そんなこと。

今回は一例として社外からの要求(法令対応)によるSoRの変更にスポットを当てましたが、VUCAの時代、企業は生き残りをかけて変革をしないといけない時代です。新しいビジネス(サービス)を見つけたら、やっぱり新しいSoRが必要で、儲けるためにSoEも作られ、かつ刻一刻と変化成長していきます。

例えばトヨタが自動車製造販売業からモビリティカンパニーに舵を切ったように。

富士フィルムが化粧品作ってるように。

電気やガスが自由化されエネルギー提供業界として大きく変化したように。

企業の生業が変わると言うことは、それに伴って記録すべきものも変わる。

 

こうして SoRもアジリティを求められる時代になりつつあります。顧客とのインターフェースとしてたつSoEを前面にして、確実に記録するシステムSoRをメンテする。そんな時代なのです。新機能を取り入れるためにシステム全体を止めてしまう。それはナンセンスだ。そんな時代なのです。

 

故に、SoRとSoEはワンパッケージにしてはならない。密結合にしてもいけない。すぐに切り離せるような疎結合にしておかないと俊敏な(正確に言えば俊敏に見える)変更ができないのです。

 

そんなシステム、どうやって作るのよ?

 

それは、第4回に譲ります。

覚えておいででしょうか?SoRとSoEを考える上で重要なこと、その3。

「プロダクトオーナーとプロダクトバックログしっかり作ろうね、ただ、大体のプロダクオトーナーはわかってないのでスクラムマスター頑張れ」

 

スクラムマスターはどう頑張るの?それを私なりの見解ですがお話しできればなと。

SoRとSoEはちゃんと考えようって話(2/5)

2回目です。

前回やこの長編全部を確認する場合は、タグから選んでください。

 

前回、SoRとSoEを使う上で3つ重要な概念を書きました。今日はその中の1つ目、どっちも大切について説明します。

 

企業の活動を記録するためのシステム(SoR)はなんとなくわかると思いますが、とても大切です。ここでいう活動、とは究極的に言えば、企業の信用に関わることです。

企業の信用とは何によって培われるか。

色々なご意見があるのはわかりますが、その上で最もといえば、やはりお金(決算)に関わることだと思います。

買う、作る、売る、雇う、それぞれの企業の生業によって変わりますが、「お金」という共通の対価をもらい、支払い、それによって社業を推進し、顧客から収益を上げてどんだけ儲けたのかをちゃんと説明する。

それは誤ってはいけない(結果的に誤魔化しや嘘になってしまうから)ですし、そうならないためにも正確であり確実であることが求められます。

 これがSoRの達成目標です。

SoRに指定されるものは実は多岐にわたると思います。そしてシステム化できない部分もあります。極端なことを言えば、小売業が毎月行う「棚卸」。電子タグなどで負荷を軽減する取り組みは始まっていますが、少なくともSPAでは聞いたことはあってもスーパーなんかでは聞いたことありません。しかし、毎月愚直に行っています。現物をシステムに落とし込む行為、これもSoRに含まれると思います。

 

では、翻って、SoE。これも今まさに大切といわれているものです。

エンゲージするためのシステム。つまり顧客の満足度を高めたり、顧客の期待を受け止めて顧客が受け取る価値を最大化するためのシステムです。わかりにくいので私の理解で一例をあげると、顧客に便利さを提供するものです。(あくまで一例です。)

ただ、この顧客も曲者で、誰を顧客にするかで意味合いが大きく変わります。

一般的にはお客様(売上の一部となるお金を渡してくれる最終消費者)になりますが、前述のスーパーに例えると、POSシステムの端末を使ってお客様からお金を受け取る「役務を提供してくれる」店員さんもPOSシステムから見れば顧客になります。

そうなんです。この「してくれる」相手が顧客になりえるのです。

この発想をEaaS(Everything as a Services)といいますが、本稿とは若干ズレるので、いったん割愛。

話が発散しないようにここでいう顧客は、最終消費者に絞りましょう。

もう一度書きますが、SoEとは、顧客の満足度を高め、顧客からお金を頂く機会や時間、総量を増やす(その点では、LTV向上と似ています)ためのシステムです。

いや、どう考えても大切ですよね。

なので、どっちも大切……というのは今回の話の半分です。

 

ここから、もう半分の理由です。

ちょっと疑問が出てきませんか?

だって、SoEのシステムたちが成功し顧客の受けとる価値を上げると企業が得られる対価が増える。つまり、SoRに記録しなきゃいけないじゃないですか。まるで真反対なイメージが付きまとうSoRとSoEなのに、連携しなきゃいけないの?

SoEを追加開発すれば、それは状況によって無形固定資産や建仮に組み入れないといけないんじゃない?

そうなんです。SoEとSoRは密接につながってるんです。

図にすると↓こんな感じ。

f:id:ficus-wightiana:20190717201128p:plain

この図を、一つのサービスだと考えてみてください。そうするともう一つ見えてきます。一つのサービスを提供するためにはSoRとSoEを行ったり来たりするんです。

例えば、Amazonでお買い物したとしましょう。

SoEであるアプリを立ち上げると、SoRの個人情報を取りに行きます。

SoRに記録されている購買履歴とSoEの欲しいものリスト、閲覧履歴、さらにSoRの他の顧客の購買履歴とを突合させ、SoEとして「この商品を見た人はこんなものも買っています」(レコメンド)機能を出します。

欲しいものをSoEのカートに入れ、SoRで決済します。

と、まぁこんな感じで。

何かお買い物をするだけで、SoRとSoEを行ったり来たり。

そうなんです。SoRもSoEもどっちも大切な理由は、それぞれが企業の記録や成長のために必要だ、というだけではなくて、密接に絡んでいてどっちが大切かという議論を超えたところにある、ということなんです。

 

DevOpsが言われ始めたころ、SoRはウォーターフォールSoEAgileなんて言われたものです。SoRの時代は終わり!これからはSoE!なんて思ってた私もいました。

違うんです。SoRもSoEもそれぞれ役割が違うだけで、大切なんです。そして、両者は切っても切れない。エンゲージメントだけを高めても企業としては破綻するし、記録だけやってても満足を提供できない以上市場から淘汰される。

 

もう一回だけ、EaaSの話をすると、記録するために従業員に苦労を強いてると従業員が辞めるんです。かといって、記録を取らないと企業が潰れます。説明できないから。

 

SoRとSoEはどっちも大切なシステム。

密接だけど、密結合にしちゃいけない。ワンパッケージにしちゃいけない。

次回は、このワンパッケージじゃダメよ議論をしたいなと思います。

 

あー、、やっぱりこの回だけでも長くなったか。。