概要
この記事は去年５月に社内向けへ書いたものである。
システムオブシステムズという手段を通してそこに関わるステークホルダーが
製品ないし、サービスを体験することによって
どのようなコトを体験し、何をなし得たいのか？についての品質の考察内容である。
参考文献
・2030年の品質保証
・解像度を上げる
品質特性ISO規格
この図に記載されているのは、システムに求められる利用者視点の品質(Service視点)と
開発者視点の品質(Resource視点)である。
開発者と利用者は見ている視点が違うが、ざっくりいうと
利用者の方がマクロな抽象的視点でシステムを見ているのに対して、
開発者はミクロな具体的な内部のシステムの品質を見ている。
この規格はあくまでも１つのResourceシステムに求められる特性であり、
システムオブシステムズのようなさらに巨大なスケールのものに関しては、
自分たちでその対象のSoSにどんな特性が求められているのか？
という新たな品質特性変数(ISOにすらまだないもの)を探さなくてはならない。
各構成要素にはそれぞれ独自の異なる特性があるが、
全体として連携した際に「誰にとってどんな特性がそのSoSのもっとも強みとするものなのか？」を明らかにしなくてはいけない。
そしてその上でその変数が測定可能なのか？まで詳細に落とし込めるのか？
などまで考察しなくてはならないため、従来のシステム設計の専門家というだけでは
このような考察は難しい。
なぜなら専門家は従来の今までの品質の延長線上に新たな画期的な品質を見出す傾向にあるが、
そもそもの様々なステークホルダが絡んだ結果の落としどころを満たす新たな品質は。
その延長線上にそもそも存在しているとは限らないからである。
従来の型に慣れている人も初心者も新しいフィールドでは共に初心者だから、
お互いに対等に尊重しあえる関係性を常に意識しないといけない。
個人的な思い
ただ自分の中で、従来のやり方の型にはまった人から何度も壮絶ないじめやパワハラを体験してきた過去があり、
従来のやり方に固執する人＝悪人、価値を創造できない人という認知バイアスがかかってしまい、
プロジェクトでも原理主義者の方への口調がたまに荒くなってしまう場面があるし、
具体なところに視点がいき、抽象なマクロ視点で視られない人へ軽蔑してしまうこともある。
この過去の強烈なトラウマという従来の記憶に固執して、
新しいことへの足かせになっているのは自分も全く同じ立場であるので、
ここを乗り越えるという感動体験も一種のSoS×DXのプロジェクトで得られる品質価値に繋がっていくのかもしれない。
きっとこれがある案件の中で出てきた
「ユーザーと企業のエンゲージメントを高める」というものだと予想。
ただシステムの技術力を磨くだけでなく、
自分の過去や従来の型とも状況に応じてサヨナラして成長していくという
体験がこのSoSプロジェクトで本質的に求められていることなのかもしれない。
人材育成
あらゆるクリティカルシンキングやデザイン思考などを使いこなし、
ビジョンからトップダウンで新しい品質を見つけ出し、
それを実現手段として支えるリソースに求められる従来の品質特性と、
新たな品質特性の発見とに分けて、さらにそれらのトレードオフ関係を仮説を立ててから検証で明らかにしていく、
というスタイルが求められるため、
人材育成のスタイルも変化させなくてはいけないし、従来の100点中90点だったら
ダメなところを指摘するおじ様たちの減点主義なスタイルから、
「前回は50点だったけども、今回は55点だったね！どんな改善をしたのか聞かせてくれないかなwkwk」
という加点主義に変えていかなくてはならない。
これは大変なことかもしれないが、DXプロジェクトだけでなく、
これからのプロジェクトを進めていくうえでも常に意識しなくてはいけないところに感じた。
ハッキリ言って、DX系のプロジェクトでここがもっとも重要なポイントに感じている。
従来のやり方で新しい変化を生もうと無理にしているから、うまく行かない。
従来のやり方に慣れたプロのメンバーで無理に変革を生もうとしているからうまく行かない。
モノからコトへ
SaaSなどがいい例であり、シェアリングエコノミーなども進んできている昨今では、
これからもモノを【所有】することから必要な時だけ【利用】する流れが進む。
所有していた際に求められる利用者がモノの品質を重視していた過去と違って、
これからはコトの品質、つまりServiceビューの品質とその先にどんな目的を達成したいのか？
といったものへの品質へと観点を変えなくてはならない。
つまり、モノの品質の上で成り立つ、コトの品質の観点へと変換しなくてはいけないため、
全く異なる観点の品質特性まで考慮しなくてはいけない。
そのサービスを利用することによって
・どのくらい快適なのか？
・どのくらい安心して利用できるのか？
・どのくらい面白いと感じることができるのか？
・どのくらい自分たちが成長しあえたと感じることができるのか？
といった【感情を伴う価値】、いわば【感動体験】を満たす品質特性が重要視される。
自動車業界の変化
これまでの【所有】する時代では、
・高耐久性
・安定性
といった品質が重要視されてきたが、
【利用】する時代においては、耐久性といったものよりも
予期せぬ事態を予測できること、故障とかする前にメンテナンスできることが求められる。
つまり、コードの不吉なニオイと同様に
リスクの兆候が分析しやすい構造であることと、高いメンテナンス性が求められる。
そのため今まで以上に迅速に最適なアーキテクチャにすることが求められる。
田舎とかみたいな一家に数台車があるような状況下では、
【所有】が求められる品質になることがまだまだ続くと予想されるが、
都市部のようなそもそも車を【所有】ではなく、【利用】するような場合ではコトへの品質が強く求められる。
これはどのように計測するのだろう？と思ったが、
ユーザーからのフィードバック内容だけではないことに気づいた。
というのも、多くのユーザーは自分の内情になんて気づけてはいないから、
その瞬間にどの程度「うわ✨」て感動したか？だけでは、品質を十分に考慮できているとは言えない。
表面的なフィードバック内容だけでなく、製品を使った後こんな行動をするはずだよね、
仮にその瞬間喜んでいなくても、心の奥底でキッカケをつくることができれば、
昨日まで行動していなかった人が、さっそく別の行動をとり始めるかもしれない。
このような行動予測を事前に建てたうえでデータ集計によって検証したうえで、
そのユーザーがいまこの瞬間嬉しいではなく、ある程度時間をかけたうえで
「あのサービスを利用したおかげでいまのこの嬉しさがあるんだ」と実感できるという、
未来時点でのユーザーっていう観点での品質の考慮も非常に重要であると感じた。
これを用いてアナロジーに展開
自社プロダクトもヘヴィユーザーに対する製品の品質（所有観点での品質）と、
たまにしか利用しないライトユーザー向けの品質（利用観点での品質）とで
分けなくてはいけないことが予想できる。
現状の自社プロダクトの品質は、ヘヴィユーザー向けであるため、ライトユーザーは他の製品に浮気しがち。
かといって１つの製品にヘヴィユーザー向けの品質とライトユーザー向けの品質両方を
盛り込んでしまうのは、今の強みのとがった部分が削れてしまうため危険とみている。
競合相手たちと柔軟に手を取り合って、
ヘヴィユーザー向けサービスとライトユーザー向けサービスの両方を実現することが求められる。
もちろんそこへは「売り上げがどうの～～」とかいったリスクは絡んでいるが、
コトへの時代を生き抜くには競合相手達とお互いの強みを生かし合うように手を取り合わなくてはいけない。
これはSoSが表現している性質とまさにそっくりである。
さらにその組織を超えた体験を経て私たちがどんな感動体験をゲットするのか？
自社プロダクト使ったユーザーが使ってみてどんな嬉しい体験をするのか？
もっとモデリング初心者の人々も議論に参加できることでアイデアが拡がりやすくなるとか
そのような体験に関する品質まで考慮する必要があると考えられる。
SoSでの利用
システム同士も所有から利用へシフトチェンジ。
何でも１つのシステムで実現しようって考えるのではなく【ないものは外部のものを利用する】ていう思考へ。
めちゃくちゃ頻繁にしかも密に利用するサービスならばそれは所有サービスになるから、
自分のとこに統合してしまうって考えるのありだが、
そんなに高頻度でなく疎結合なサービスであるならば、外部のものを使って連携するって考える。
この時考えないといけないのが連携による障害である。
障害が起きる前提でリスク対策しておくことが必須で、
不確実性が非常に高い品質が安定してないものは、そもそも一部のシステムからしか繋がれないよう
APIのコントラクト設計をしておくなどしなくてはいけない。
組織同士のコラボレーション
通常のシステム以上にSoSでは、受託先と依頼先のコラボレーションが求められる。
というのも、SoSに異なる強み・特性が求められる者同士を連携させて１つの大きな目的を達成するのと同様に、
組織同士でもこのような連携をしてさらに大きな目的を達成するという体験を
アーキテクトチームだけでなく組織レベルで体感すること、
強いコラボレーションによって組織という壁を超えて顧客の成し得たいことをお互いに達成することに注目することが求められる。
プロジェクトというイベントを通して組織を超えて他のメンバーとの繋がり、
共に成長したという実感、大切にしてる価値観の共有といった感動体験を体感できること
がSoS×DXプロジェクトに求められる 感情を伴う品質 である。
未来のステークホルダー(フューチャーホルダー)
たとえば長期プロジェクトとかのような場合、いまの現状のステークホルダーだけ考えればいいというわけではない。
具体と抽象、以外に立体的なミクロ(構成システム)とマクロ(SoS全体)、
それ以外にも今と未来 という時間の視座で捉えることも重要である。
2050年の脱炭素という計画であればそのくらいの時期に成人になる人々、
つまりこれから生まれてくる世代もステークホルダーに入れた視点で考えなくてはいけない。
馬田隆明著の解像度を上げるでは、この未来のステークホルダーをフューチャーホルダーと呼んでいる。
この未来の視座で考えるというときに気を付けたいのが、
今の現状の視座から未来を想像していては、
今までの延長線上の未来やありきたりなものしか想像できない傾向にあるということ。
むしろ、将来の世代の視座に立って「あるべき姿」を考える際には、
それはいまの延長線上には存在していないと思った方がいい。
抽象的所から考え出す完全にトップダウンでの思考で、しかもそこには仮説マインドが前提にある。
解像度を上げるでは、「我々は祖先から環境や文明といった財産を受け取った相続品であると同時に、未来の子孫たちからの財産を預かっている受託財産管理人である。
その財産を運用する上でのスチュワードシップを意識すると、おのずとフューチャーホルダーも視野に入れた意思決定ができる。」と書かれている。
つまり先の世代が「あの人たちが懸命に脱炭素や改革、方法論の確立とかしてくれたから
今がある」と思ってもらえる、
後世が自分たち祖先に何をしてほしかったのか？という視点で
未来から逆算したトップダウンの考え方で、さらにはそれが今現在のステークホルダーにとって嬉しくないことである場合には、
リスクを取るか？ もしくは今現在のステークホルダーにとって嬉しいことをボトムアップで、
未来のステークホルダーにとって嬉しいだろうことをトップダウンで考えていき、
交わるところを探していくという方法が日本流の考えで現実的なのかもしれない。
ただ個人的には、未来のステークホルダーにとってめちゃくちゃ嬉しいことを実現するには、
今の我々世代がリスクを受け取るスタンスを示すってのも勇敢であり、
それが上記の感情を伴った品質にも繋がると考えている。
何が言いたいかというと、感情を伴った品質っていうのは、
何もその場で手にした時に抱いた品質(この体験できて嬉しいとか、微妙だなて品質)だけでなく、
いまこの瞬間とか直近の間に抱く感情の品質だけでなく、
未来に抱く感情を伴った品質まで考慮に入れなくてはならないと感じたのである。
未来のステークホルダーにとって心の底から「あなた方がいたから今がある」っていう品質と、
そこに対する未来の自分が抱く感情という品質。
だから将来世代をステークホルダーに入れることも大切であり、
将来自分がどんな風になっていたいのか？ということも視野に入れたうえで
【今の自分はステークホルダーに入らないが、20年後の自分はステークホルダーに入る】
ということが起こり得るということ。