3回目です。
前回やこの長編全部を確認する場合は、タグから選んでください。
前回はSoRとSoEは密接に繋がっていて切っても切れない、だから両方とも大切なんだ、というお話でした。
今回は密接に繋がってるけどワンパッケージにしちゃいけないって話です。
もうお気付きの方もいるかもしれませんが、SoRとSoEは役割が違うので一緒にしちゃいけないんですね。
なんでかというと、SoEは追加開発、変更が当たり前だから。まぁ、これはギョーカイ長い人ほど頷いて下さると思いますが、変更を繰り返すと変なところから綻びが出ます。
よく老舗の温泉旅館だと言われますが。増改築を繰り返したためになんか変な段差ができた、とか。ぐるっと回る廊下があったりとか。
よく言うじゃないですか。1行のコードを変更するのに半年かかる、とか。
なぜこんなことになるか。記録するってことに影響が出ないかを確実にしないと企業の存続に話が及ぶからです。SoRに影響を与えることは最終的に企業の首を絞めるからです。
だから、１つのサービスを１つのシステムで提供しようとするとドエラいことになります。
正確に言えば、今の時代は。
昔は良かったんです。それ（１つのサービスを１つのシステムで作って）でも。だって、差別化の手法に顧客満足度を上げるって選択肢がなかったから。
その名残が残っているのがいわゆる「社内システム」ってやつじゃないですか。今でも顧客満足度を上げるって選択肢ないですもん。サラリーマンの方にお伺いしたいのですが、今あなたが務めている企業でしか使わないシステム、外に売れるって思います？これ便利だから、他の企業の人に使ってもらおうよ！って言う人います？
前回申し上げたEaaSの話にまたなっちゃいますけど、社内システムから見れば、利用者は顧客なんですよ。顧客が満足しないシステム作ってるのがいわゆる社内情シスですからね？私が言うのもなんですけど。（社内情シスでした）
これ（社外に売れない社内システム）はSoRを重視するあまり、SoEに無頓着になってしまった典型だと思います。
働き方改革が叫ばれ生産性向上が急務と言われても、実は働いてもらう環境が生産性を上げてない。これは社内システムだからこうなっているだけで、お客様、最終消費者から見れば関係ありません。新しくかつ充足感のあるエンゲージメントを提供してくれるプラットフォームに乗り換えます。別の言い方をすれば、消費に関わる行動を効率化するために、新しいプラットフォームに乗り換えるってことです。
あ、やべ、これじゃない！と提供側が感じたらすぐに切り替える俊敏さが必要です。そこで記録に与える影響を精査するからと半年も待ってたら企業の収益力が低下する。ゆえに、SoRとSoEはしっかり分けないといけないんです。
OK、わかった。でも、ウチは関係ないよ。と思った方。SoRとSoEをワンパッケージにしてはいけない理由はもう１つあるんです。
それは、SoRも変化を求められるってことなんです。は？と思った方。
例えば、労基法が改正されました。それと同時に安衛法も改正されましたよね？働き方改革関連法の改正って一絡げにされてましたけど。
その中で、労働時間の把握が自己申告だけではダメになってます。簡単に言えば、タイムカードをガシャコンッとして把握するだけじゃダメよ、と。客観的事実で労働可能だった時間を把握しなさい、というルールが追加になってます。ハイ、新しく記録しなきゃいけないものが増えたんです。この是非はさておき（個人的には意義は理解するけどやらんでもよくない？と思います）、こうしてSoRも変化を求められる時代になったんです。追加要件だ〜って丸投げしますか？さらに言えば、この新要件対応のためにしばらく勤怠管理システム使わないでくださいって言えますか？言えませんよね。今までのやり方で考えれば、土日や時間外にリリースする、でしょうか。でもその時、担当が育児のために土日出られませんってなったらどうします？いや、今のご時世普通に起こりえますよね、そんなこと。
今回は一例として社外からの要求（法令対応）によるSoRの変更にスポットを当てましたが、VUCAの時代、企業は生き残りをかけて変革をしないといけない時代です。新しいビジネス（サービス）を見つけたら、やっぱり新しいSoRが必要で、儲けるためにSoEも作られ、かつ刻一刻と変化成長していきます。
例えばトヨタが自動車製造販売業からモビリティカンパニーに舵を切ったように。
富士フィルムが化粧品作ってるように。
電気やガスが自由化されエネルギー提供業界として大きく変化したように。
企業の生業が変わると言うことは、それに伴って記録すべきものも変わる。
こうして SoRもアジリティを求められる時代になりつつあります。顧客とのインターフェースとしてたつSoEを前面にして、確実に記録するシステムSoRをメンテする。そんな時代なのです。新機能を取り入れるためにシステム全体を止めてしまう。それはナンセンスだ。そんな時代なのです。
故に、SoRとSoEはワンパッケージにしてはならない。密結合にしてもいけない。すぐに切り離せるような疎結合にしておかないと俊敏な（正確に言えば俊敏に見える）変更ができないのです。
そんなシステム、どうやって作るのよ？
それは、第4回に譲ります。
覚えておいででしょうか？SoRとSoEを考える上で重要なこと、その3。
「プロダクトオーナーとプロダクトバックログしっかり作ろうね、ただ、大体のプロダクオトーナーはわかってないのでスクラムマスター頑張れ」
スクラムマスターはどう頑張るの？それを私なりの見解ですがお話しできればなと。
