構造化スキルとその利点
CS Harmony Radio。今回のシリーズでは、カスタマーサクセスにおける構造化スキルの重要性ということで話しています。
前回が、そもそも構造化って何ですかっていう定義とか、業務の中でどんな形で使っているかっていう話をしていきました。
じゃあ、今回のテーマとしてはですね、構造化できるとスキルが身についていって、どんな形で業務上成果を出していけるのか。
改めて考える部分が多そうなところではあると思うんですけれども、それについて話していきたいと思います。
前回、構造化ってピラミッドのツリーの形や、マトリックスのような行列の話とか、フローの流れっていうので整理して、そういう要素を作り出していくっていうところがあると思うんですけど、
こういうのって、いわゆる四角い箱だったりだとかを線で繋いでいくとかっていう話にもかなり近いところだと思うんですよね。
だから、誰でもできるといえば誰でもできる話かなと思うんですけど、ある種、長けてる人とか、それを頑張って実践していくと身につくスキルってどんなものなんでしょうって話、それぞれ伺っていきたいなと思います。
まずはヤギさんからですが、ご自身で普段もいろんなの使ってやってると思うんですけど、これやってるとこういうスキルが身についてきてるなぁみたいな話、振り返って結構なんですが、どんなところが思い当たりますか。
いろいろありますけど、シミュレーションの話を何かの階に、モデリングの階に。
モデリングの階で、そうですね。
シミュレーションの一種ではあるんですよね。構造化できてるっていうことは、例えば、前回で言うとマトリックスの話しましたけど、証言が4つあったときに第3証言だけ物ないよねって思うと、そこって何だろうみたいなのを考えれたりする。
抜け漏れ見つけたりとかっていうのがある意味のシミュレーションの技術。
そうですね。
上手くできた場合ですよ。上手くできないと何かよくわかんなくなるんで。
上手くできてる風に構造化できてると、そういう予測が立てられたりとか、今後の方針が見通せたりとかっていうのがまず一つかなというところと、
あとはもう1つあるのが、多分パターン化であったりとかカタカみたいなことが上手くできるようになるんじゃないかなと思います。
で、それ何かというと、構造化ってある意味パターンを見つけに行く作業で、定義っていうのはやっぱり構成要素とその関係を整理なんですけど、
整理するときって共通項みたいな視点を見つけてそれによって括ったりとかってするじゃないですか。
例えばリンゴとみかんが果物であるっていうような括り方をしますけど、リンゴと例えばトマトを持ってきたときに、
これは赤いものが赤い食べ物だみたいな括り方もできますね。リンゴの1個の視点で。
これの切り方みたいなのって、なんかこうセンスみたいな部分の実感は若干あるんですけど、ある意味パターンみたいなのがあって、
例えば3Cで整理しましょうよとかっていうのはある意味パターンなんですし、そういったものを適用しやすくなるっていう部分もあって、
蓄積していくと自分とかその本人の中でもパターン画ができて、他にも応用できるというのにつながるのかなと思います。
丸山さんはどうでしょう?
丸山 今のお話に追加してというところで、構造化って要は分解と設計が頭の中できちんと抽象具体の域をしながらできることだと思うので、
CSと言うとドンピシャではないかもしれないですけど、問題発見解決だったりとか、そこから解決策の提案の中身を作るであったりとか、
そういうある種コンサルティングに近いスキルとかは、構造化できればコンサルティングできるわけじゃないんですけど、
その土台となる部分はできると思うので、そういうコンサルティングスキルとかにつながる部分の基礎はできるんじゃないかなとは思いました。
やっぱりお客さんに対してCSがやっていく活動の一つとして、サービスを使う上での問題解決であったりとか、
事業のKPIとかお客さんの成果を出していく上での課題解決とか、それに向けた提案とか、一定やっぱりやっている部分ではあるので、
そこにはすごく活かせるスキルになっていくんだろうなと思います。
構造化における言語化と品質担保
今、丸田さんからもコンサルティングって話がありましたけど、多分CSとコンサルティングの境界って決まってるようで曖昧な部分も結構あるとは思うので、
CSの領域としてもコンサルの能力が求められる部分では、今言ったような構造化っていうのが役立つっていうところかなと。
お二人の話聞いてても、多分、具体と抽象を行き来するだとか、観点の軸を切り取るとか、
そこからちゃんと抜け漏れなく要素を分解してみていくっていうところが、スキルとしては身についていくのかなと思って。
あと、前シリーズでも話してた言語化の話で言ったときに、結局そういうことができていた先に、
言葉の定義とか言葉に対するこだわりの感度が高まっていくみたいなところもありそうかなと思うんですけど、
前のシリーズでヤギさんそのあたりの話触れてたんですけど、どう思われますか?
それはそうじゃないかなとは…
構造化、前回からありますけど、構成要素と関係性。
言葉の定義って構成要素の箱なら箱だし、それになるんですけど、
それの定義が由来でると、実は関係性を繋ごうとしても何かいまいちよく分からないので、
その箱がしっかりするって非常に重要で、だからやっぱちゃんと構造化するっていうことをやろうとしていくと、
やはり言語化みたいなところはしっかりするし、定義もちゃんとするっていうことに繋がるんじゃないかなと思います。
ここ、個人的にもある、今言った通り、由来でるって意味ないって、
ある程度の品質担保しないと、このスキルってワークしないかなと思っていて、
なかなか品質レベル数字化をするのは難しいところはあるんですけど、
この構造化みたいなことがカチッとできるようになってくると、
今言ったような、舞台と中小の行き来もやりやすくなるし、
言葉に対する感動も高まるし、問題構造を発見して問題点を洗い出すこともできるし、
ながらゴール設定みたいな、イシューみたいな、やるべきことこれですよねみたいな話とかも、
お客さんとの話の中でうまく設定していくとか、いろんなところにワークしだしていくかなっていうところがあって、
イメージなんですけど、行くところの壁っていうのはちょっとあるんだけど、
壁越えるとかなりいろんなところに汎用的に使えるスキルなんじゃないかなっていうのが、
個人的感覚なんですけど、その辺りって、丸田さんどう思います?
CS業務の中で、たぶんある程度ここのスキルレベル高い人って、
かなりいろんなことを器用にできるんじゃないかなと思うんですけど。
特にですけど、CSの組織立ち上げだったりとか、最初の戦略設計フェーズぐらいのときとかは、
お客さんの業務理解を深めていくとか、どうCSとしてお客さんを支援していく、うまくいくんだっていう、
更新の策定とかをやっていくタイミングは特に、そういったきちんと物事の本質を見抜いていくとか、
そこにある壁をどう越えていくとか、どういうふうに業務を組み立てていくと成果が出やすいとか、
そういったことを考えるタイミングはすごく増えるので、やっぱりそういうときにはすごくいろんな場面でワークしますし、
逆に言うとたぶん、CS立ち上げフェーズのメンバーとか、
あとはCSの責任者クラスのメンバーとかは、こういったスキルがないと立ち上げだったり、
構造化と業務モデリング、言語化の関係
チームの運営とか業務改善がすごく厳しくなってくるだろうなと思います。
逆にそこでうまく仕組み化できてる人たちっていうのも一定のスキルレベルがあって、
それを活用してるっていうことかなとも、今の話聞いてても思いますね。
まさに多分おっしゃった通りかなっていうところで、これまで話してきたシリーズの話ともすごく密接に関係してると思っていて、
何を言ってるかというと、業務モデリングの話もそうですし、言語化の話もそうだと思うんですけれども、
構造化ってこの要素を繋いでいくようなものかなというところがあるかなと思っています。
モデリングって我々の話の中だと、ある程度物事を理解する行為として、
理解の仕方の捉え方とか、作法とか手法みたいなところの話をしてきていて、
その中で自分の頭の中でいかにそこを深ぶっていくかっていう話かなと。
それを今回の構造化で多分形にしていくと、その中でお客さんが分かりやすいとか理解しやすい形っていうのを作り出せるので、
自分たちの思考の深掘りっていうのを、ある種こういう形として表現しましたっていうところで非常に機能するスキルかなと。
そこからさっき言った表現したものって多分それだけ見せても分かりづらいんで、
お客さんのコンテクストとかをちゃんと踏まえた上で説明していくっていうところが言語化の中では大事な部分で、
そこは全シリーズでかなり話してきた内容だと思うんですけど、
そういったところで言うと、この辺りのモデリングの話と構造化の話と言語化の話っていうのは、
かなり密接につながっているところで、かつビジネススキル的にはベーシックだけどすごく大事な部分かなというふうに、
ここまで話してきて改めて感じるところですね。
ヤギさんからはあります?
逆説的な話をする。
ホットキャストモデリング大事だよねって話と、顧客理解大事だよねって話をCSにとって話をしてますけど、
なんかそれってやっぱり踏み落ちない部分はあるかなと、説明されないと思ってるんですけど、
構造化ってどうなんですかね。構造化っていうものってCSに結構重要かなと、個人的には思ってるんですよ。
なぜかというと、CSじゃなくてもいいんですけど、CSも特に。
言い方を変えると、何にも構造化されてない状態でカスタマーサクセスうまくいきますかって言われたらちょっと疑問があって、
構造化されてないものを提案されてお客さんが納得しますか、まずその1。
その次に構造化されてないのに、例えばCS組織としていろんな人が同じような品質担保できますかって言うと、
構造化観点としてのKPIツリーやコミュニケーションフレームワークの使用
構造化できてないんですよ、むちゃくちゃな状態でって言った時に、どうですか丸田さん、どう思います。
これはだいぶ厳しいと思いますね。
なので多分少なからず構造化って絶対していかないといけないものなのかなと思いますね。
そういう意味でモデリングって少し構造化を補助するというか強くするためのもので、
そういう意味合いの関連性なのかなとちょっと思って聞いてました。
僕はうまく言語化できなかったんですけど、まさに多分そういう部分が大事かなと思ってて、
構造作らないと仕組みができないよねっていう話なんだろうなっていうところで、
少し視点を変えて、じゃあ皆さんどういう観点で構造化やってますかって言い方変えると、
どういう要素分解してますかみたいな話かなと思ってます。
これ多分CSの業務の中でいろいろあるかなとは思うんですけれども、
まず一般的な話の内容からいくと、構造化の観点としては、
八木さんからも例でいくつか出してもらったものが当てはまるかなと思うと、
まずはやっぱりKPIツリーみたいに品質分解する構造化みたいなのはかなり業務的には使うかなと思っていて、
これが一つ大きいかなと思います。
あとはコミュニケーションをしやすくするとか、コミュニケーションを円滑にするには、
先人の知恵を生かしたフレームワークを使って構造化していくっていう、
フレームワーク自体は構造化のすでにテンプレートだと思うんですけど、
そういうふうにテンプレートによって構造化していくっていう話もあれば、
言語化の話とかもそうなんですけど、
相手がどう考えてるかみたいな、思考でモヤモヤっとしたものを形にしていく構造化みたいなところもあるかなっていうので、
主に性的な話の要素っていうのをかなり構造化する観点では、
いろんなところで例が出てきたと思うんですけれども、
ここからはヤギさんが専門なんで、少し聞いていきたいんですけど、
この性的な構造だけだと多分構造化としては捉えるのがちょっと難しいなと思ってるのがフローなんですけど、
構造モデルと3つのレベル（ユニバーサル、ワールドリー、アトミック）
これ構造の形としてはフローもみんな使ってるって言ったんですけど、
フローって動的なので、この辺の構造をどう捉えて考えていけばいいのか。
構造化より若干広い話をしますけど、構造モデル、
構造モデルっていうののもう一個上にモデルっていうのがあって、
モデルの中を構造化すると、構造モデルとする前モデルと、
あとは機能というか役割というか目的のモデルみたいな、
3つぐらい大体言われてるんですね。
特にシステムを考えるとき。
システムであったりとかソフトウェアであったりとかっていうものを考えるとき、
まず構造面。構造面って言ってるのは堀さん言ってくれた通りで、その場のスタッフみたいな。
例えばパソコンであるとデスクトップだったらディスプレイとキーボードとマウスと本体みたいな、
そういったものが構造の性的な状態。
振る舞いっていうのはそれらがどう動くのか。
例えばパソコンでWindowsとかだとボタンを押すとウェルカム画面が出てきて、
パスワードを入力するとかっていう処理的な作業が書かれるのが振舞い面のモデリングです。
あと機能っていう面は一体これは何のために使うのかっていう目的のほうを考えていく側面を持っていて、
例で言うとポッドキャスト撮りますみたいな目的があって、
そのために我々今Zoomで撮ってますけど、
Zoomっていう手段を使ってありますみたいな関係性を整理していくっていうのが目的面というか機能面みたいな。
構造モデルって基本的には性的なものを捉えます。
扱いが厄介なのがスローってやつで、
基本的に多くの場合は振る舞いで書かれるところがあります。
プロセスモデルのときに振舞いのモデルと構造のモデルが実は混ざるというのが言われています。
複述的な話になっちゃうんですけど、
一番領域が大きいところで言うと、
ユニバーサルレベルっていうのがあって、
例で言うと企業で言うところの営業と、
例えば製造業だったら製造がいて、
調達がいてみたいな関係性が書かれる業務スローで言うと。
例えば営業が営業してきて、部品買ってきて、調達が買ってきて、
製造して販売しますっていうのがユニバーサルレベルって言われます。
大体どの会社も一緒でしょみたいなぐらいのやつ。
だからユニバーサルなんですね。
そのレベルのやつは実はスローで、振舞いで書かれます。
時間の関連がそこに入っていく感じで書かれます。
1個下がるとワールドリーっていう領域があって、
ワールドリーっていうのは営業の中の業務を少し開いた上で、
フローの構造化と3つの領域（ユニバーサル、ワールドリー、アトミック）
例えば企業ごとにちょっとずつ違うと思うんですよ、営業の仕方って。
例えばホリゾンタルのサードやってるところとバーティカルのサードやってるところは
営業の仕方と違うんですね。
っていうところの違いのところまで踏み込んだやつ。
っていうのがワールドリーです。
ここは実は振舞いで書く場合と構造で書く場合が実際は存在していると思ってます。
実は構造で書いたほうが良さそうです。
何でかっていうと、作業まで落ちてないレベルなんですよ。
例えば見積もりの中はどういう構造をしてるのかみたいなところが書かれるべき。
この辺べき論の話になるとちょっと難しいですけど、そういう話です。
さらにもう1個下にアトミックっていう領域があって、アトミックはもう作業レベルです。
例えば各担当がどういう作業をしてきますかっていう領域になるので、
これ完全にここはもう時系です。
こういう手順でやりますっていう、
処理みたいなところで書いていくような領域。
フローって言ったときに、どこの領域の話をすべきなのかっていうのは非常に難しい。
例えばカタカの話をしようとすると、たぶんワールドリーで話したほうがいい。
何でかというと、処理の領域でフローの話をすると、実は振舞面ってパターン化しづらいんですよ。
動作なんでダイナミックじゃないですか、動いちゃうんで、同じことになりづらい部分があります。
構造面って同じになるんですよ。
パソコンって一緒じゃないですか、だいたい構造。
その領域だとあんまり差がないんですけど、流れてる処理って変わったりするんですか。
Windowsがアップデートされちゃうと起動の仕方変わったりすると思うんですけど、
アプリが変わったりすると言いますけど、あれって振舞が変わってるんですね。
構造は変わってないけど。
カタカとかそういう話をすると構造のほうが向いている。
フローを記述しようとしたとき、プロセスを記述しようとしたときは、
ワールドリーのところは構造で書いたほうがいいかなと。
我々がプレップモデルを使っているのは、ワールドリーの領域を構造で書く。
その辺の領域をやってますっていう。
ありがとうございます。一回確認しながら喋りたいなと思うんですけど、
まずはこのフローみたいな話は構造の話と振舞の話っていうのが混ざることが多くて、
これを意識して区別しないとまずいけないっていうところが前提にありつつ、
構造としてのフローっていうのは構造化の対象だけれども、
振舞に関してのフローっていうのはまた構造形が要は流れみたいなと。
本当にフローの話になってくっていうことですよね。
業務というか我々の仕事の中もそのフローっていうのを
3階層で分けると理解しやすくなるのかなと。
ユニバーサル、ワールドリー、アトミックだと思うんですけど、
これ多分CS文脈に置き換えて考えるとユニバーサルって言ってるのは、
いわゆるオンボーディングしてサクセスにするとかっていうそれぐらいのフェーズの
いわゆる一般的な形ですよね。
CSの活動だと普通にこういうことやるよねみたいなやつがユニバーサルっていうので、
業界常識みたいなところの話なのかなと思っていて、
これはもう別に構造的にもそうだし、これがいわゆる本当のフローの構造だと思うんですね。
そこはもうそういうものでしょうっていう形で規定されるので、
一方でそこからワールドリーになると個別になりますって話があったんですけど、
結局A社のオンボーディングフェーズやサクセスフェーズの中ってどうなってるとか、
B社どうなってる、C社どうなってくってなると、
ここに関してはそれぞれ手順が違うから、
多分パターン化しづらいっていう話があるのかなと思っていて、
ここを構造で整理すると良いですよっていうのが
研究の中でも言われているっていう話なのかなと思ってたんですけど、
ここまでは大丈夫?合ってますか?
その通りだと。一般的にはですね、フローっていった時に振る舞いを捉えやすいっていうのがあるので、
これも言われている話で、なんでワールドリーが大事って言われるかというと、
ユニバーサルからアトミックに急に落ちるっていうのが問題としてあるので、
長さとかないよねみたいな話が出てくる。
これでもまさに我々が理解できた話で、結局抽象と具体の話みたいな部分とかでいった時に、
ゴールとか目的みたいなところっていうのは大きくやっても、
そっから実際に移す時に急に細かくなるみたいな話とかって、
流度設計はむずいっていうところの話だと思うんですけど、
研究してる領域だとちゃんと3階層に分かれているって分けたほうがいいっていう話ですよね。
途中になっちゃいましたけど、ワールドリーの下にアトミックっていうのがあって、
作業レイヤーで、これは本当に行動的なものなので、
ここは構造化っていうよりは本当に手順だから、流れを書くか、
その手順でやることをリストアップして書いていくみたいな、
ワールドリーと構造化
多分そんな話なんかなというふうに思って聞いてると、
結局、接合点のワールドリーっていうのが非常に構造化する上でも難しいんだけど、
これを振る舞いとしてじゃなくて、構造面で構造化できるっていうところが、
業務的にうまくいくとか、業務を改善するポイントになってる気持ちで、
そこはプレップモデルっていう内容で我々アプローチしてるっていうところですよね。
だからそこの意味合いとか効果っていうのは、構造化するところの非常に難しい部分に対して、
改善提案できますよっていうところをやってるっていう、
そんなことかなというところまでは分かってきたんですけど、
音声だけで言うとかなり難しいんですけど、
混ざりやすい部分っていうのはすごくあるなとは思ってて、
変な話で言うと、CSの内容に照らさせて聞きたいんですけど、
まるささんたぶんCSやるときにカタカみたいな話あると思うんですけど、
この辺のカタカの話のときに、たぶんそれってワールドリーディレベルの、
要は業務のカタカだと思うんですが、
ここでどんだけ記述していいとか、どういうふうに書くべきかっていうのって、
結構現場で試行錯誤することが多いんじゃないかなと思ったりするところに、
振る舞いじゃなく構造を捉えていくっていうアプローチ入れるっていうのは、
カタカがうまくいきそうな気が個人的にはするんですけど、
その辺りってどう思われますか?
構造と振る舞いの違い
この3階層の分け方はすごく面白いですし、
今まで私の反省として間隔地でやっていたものが、
こういうふうにきちんと言語化されて分けることができたら、
よりカタカは進みやすいんだろうなっていうのはすごく思いました。
一方でヤギさんに質問なんですけど、
さっきの構造と振る舞いの違いのところで、
振る舞いのところは手順のようなもので、
流れに沿ってダイナミックに変わっていくとおっしゃってたんですけど、
振る舞いとか手順っていうのは、時間軸が付与された構造じゃない?
それで正しいと思います。理解として。
構造と振る舞いの違いとしては、
構造のほうが振る舞いをある種方眼していって、
振る舞いのほうはプラス時間軸の要素が入っているよっていうことですか?
方眼の関係がどっちがどっちかによりますけど、
そうですね。構造面のほうが自由度が基本は高いです。
振る舞い面っていうのはそこに時間とか手順とか順番が付与されるので、
基本的には。そうなると自由度が減る方向に行きます。
感覚的理解で言うと、自由度が減るということは型化しづらくなる。
なぜかというと手順、順番入れ替えたときに成り立たなくなっちゃうから。
そこを感覚値の話になります。
CSにおけるアプローチと悩み
だから構造のほうがパターン化しやすい理由はそこです。
なるほどです。
さっき手順とか振る舞いのほうはダイナミックに変わっていくよねっていう、
Windowsがアップデートされたら流れ変わっちゃうっていう例が出されてましたけど、
スタートアップ側でCSの型化をしていくときの悩みの大きなポイントがここで、
よくも悪くも事業もサービスもCSのやり方も例明記というか過渡期なので、
どんどん時間とともにやり方が変わっていったり、
より良いやり方とか出てきて変わらないといけなくなっちゃう部分がある。
それをどうオトミックレベルでどんどん変わっていくものを型に落としていくかですごく悩むんですよ。
こういうのってどうやってるんですか?
この場合にユニバーサルは何を採用しているのかっていうのがまず大事かなとは思いますね。
例えばザモデルのインサイドセールスみたいなやつを採用してますかどうかっていうのがあって、
それを実際現状の業務のアトミックレベルでどう回してるかっていうところから、
つまりどういう構造なんだろうって抽出していくことだと思います。
変わったら変わったで、ワールドリーム変えなきゃいけないので、
変わった範囲がワールドリームレベルが変わってるのかどうかのチェックを打つとして変わらなきゃいけないんじゃないですかね。
例えばユニバーサルっていうのはザモデルを採用していて、
その中のCSは一般的にオンボアダプション、エスパンションとかすごくオーソドックスな流れを組んでいる大枠があって、
その中でワールドリームの部分で、うちのオンボーディングってどうやって作ろうか。
例えばうちのオンボーディングは初期設定、データ入力、アカウント発行、サービス理解、一回使ってみるみたいな、
そんな感じの要素があって、これを順々にやっていく。
その中で例えばアトミックのレベルで言うとこういうことをやっていこうみたいなのがあって、
例えばワールドリームの初期設定とかデータ入力とかちゃんとサービス理解してねみたいな、
大枠の底の部分はあまり変わらないけど、アトミックの部分がコロコロ変わるってなった時に、
そこの変化が激しい中でアトミックをどう作っていくべきかっていう悩みですね。
それどちらかというと、プロセスモデルをどうやってマネージしていくかみたいな話だと思うんですけど、
そこはやり方多分いろいろあります。毎回毎回アトミック部分を生成するのか、
アトミック部分はナレッジとして取得しておいて、
例えばチップスみたいな形、ノウハウのチップスみたいな形で、
この場合こうですみたいなもののチップス収集を用意して、それを参照しながらやっていきましょうとか、
チームとしてそのノウハウを暗黙地を暗黙地として共有していくとかって、
多分いろいろやり方はあると思うんですけど、そういう感じですね。
アトミックは多分変わっていくのは必然だと思うので、
毎回毎回多分設計が必要ですし、やりながら変えなきゃいけない部分になるかなと。
ワールドリーはもうちょっと変わりづらいものを扱うんで、
ワールドリー作るところは結構頑張らなきゃいけないんですけど、
ワールドリーがある程度できると、それをベースにどう回すかは今度マネージメント、
そのプロセスをどう使っていくかってマネージメントの話。
おだしょー すごくよく分かりました。
多分、CSの中だとワールドリーみたいなのをサクセスジャーニーとかロードマップみたいなもので、
ある程度方向感を決めたり、
あとはお客さんにこういうものをこういうふうに提供してるから、
うちはこういうふうに支援していくんだよっていう大枠の構造設計をして、
アトミックの部分はお客さんがもしこうだったらこうしようみたいなのを、
ヘルススコアとかを混ぜながら、
遺憾をたくさん書いてTips中にして対応してるみたいなのが結構多いかもしれない。
おだしょー うまく回ってるとそれで良い感じですかね。
ワールドリーに入れ込むところに、
今で言ってる処理レベルのやつ、アトミックのやつが混ざり始めると厄介極まりなくなってくるので、
そこら辺ちゃんとどこで切るのっていうのをちゃんと決めといた方がうまく回りやすいんじゃないかなとは思いますね。
なんでかというと、アトミックレベルで解決する話とワールドリーレベルで解決する話が違うんですよ。
例えばですけど、CS領域でいうと、プロダクトフィードバックみたいな話があるじゃないですか。
プロダクトフィードバックみたいな話って組織をまたがうという話で、
ワールドリーって大体組織をまたがったりする領域を扱ったりするので、
そういうところの領域だと、うまく情報が受け渡せなませんよねっていうやつをアトミックレベルでやろうとすると、
すごく小手先の施策になっちゃうんですよ。
なんか、一緒に会議出ましょうよみたいな。
そういう意味じゃないですよ。
そういう意味になっちゃうんで。
うまく回ってない理由って、たぶんワールドリーレベルで起こったりするので、
そこの部分をうまくやろうとすると、その領域で話を締める、そういう感じですか。
これはあれですね。今、CS業務のカタカとかをやってるCSOpsっていう領域の人たちがいるんですけど、
CSOpsの人たちがこういうのを学ぶと、すごい喜びそうな気がします。
これソフトウェア開発を支援する人たちのための研究をされてるところがやってたので、
要はOps的な人たち向けですね。
逆説的に質問しちゃうと、車って時間軸の影響を受けるっていうことだというふうに理解したんで、
それだと構造って時間軸の影響を受けないと言えるのかなと思ったんですけど。
ただ難しいのは、時間をそもそも時間軸を構造としての一個の要素に入れ込んじゃうことができはします。
時間そのものを要素として捉えることができちゃうので、
そうするとある程度構造っぽく見えちゃうんですけど、
それただ言い方を変えると、箱の中に時間が書かれる場合があるんですよ。
例えば今、過去、現在、未来みたいなやつは、その中に時間が含まれるじゃないですか。
矢印の関係には時間はないんですよ。
矢印の関係性の中に時間軸が入ってると構造じゃなくて、それ振る舞いです。
よくわかりました。構造の中に時間っていう要素を入れ込めることはできるけれども、
基本構造っていうものを考えた時には時間っていう軸は多分影響を受けてないと思っていて、
さっきのカタカシやすい話って、逆に時間軸っていうのが結構厄介なんじゃないかなっていう風に話を聞いて思ったんですけど、
新しいテクノロジーが生まれましたって言ったら、それによって業務とかの振る舞いが変わるっていうのが起きるじゃないですか。
そうすると、それによって結局これまでは良かったんだけど、時間軸の変更を自分たちはするつもりがなくても、
他が変えちゃって、他がそれでいい変化を起こしちゃうと、水準をしなければならなくなるとか、
構造化スキルの重要性
そういう要素があってカタカが実は難しかったりするのかな、変わりやすいのかなって思ったんですよね。
技術が変わるみたいな話って、どっちかっていうとアトミックレイヤーよりもワールドリレイヤーで起こった時に影響が強くなるんですけど、
アトミックレイヤーで起こるやつって、例えば自動化しますとか、
RPA入れてExcelの入力作業を自動化しますとかはアトミックレイヤーなんですよ、作業なんで。
ワールドリレイヤーになると、例えばAIを入れてここの業務とここの業務を連携しますみたいな話がワールドリレイヤーになるんですけど、
そうなった時って、作業レベルで考えてしまうと、実は堀さんが言ってくれた通りで影響がめっちゃいろんなところに波及するので何か破綻するんですよ。
だけど、そこをプレップみたいな話で構造化した時だと、要はその変化の影響があるとて、その構造自体が変わりづらいんじゃないかな。
なるほど、それはその通りだと思います。アトミックレイヤー側で変わっている条件は、ワールドリレイヤー側には多分あまり波及効果は来ないので。
で、結局アトミックってプロセスっていう時にはもう多分振る舞いしかないじゃないですか、基本的に。
なので時間軸必ずいる話だと、手順があるので。
必ずいる。
そうなった時に、そこに関しての影響度は必ず受けるって話だとしたら、さっきマルザさんの質問にあった結局影響を受けるところの対応の仕方って、
今みたいに上手い最適解を見つけていくしかないってなると、やっぱりチップスとしてナレッジ共有するだとか、
暗黙地としてみんなが持つようにするようなチーミングするとか、何なら現場に権限以上して、達成することはこれだから、
それのやり方についてはアトミックレベルは裁量に任せますっていう。それで上手く回ればそれでいいんじゃないのかな、そんな風に思ったんですけど。
その通りだと思います。
なるほど。話を少し戻すと、構造化の観点としては、要素を分解していくとかのパターンがいくつかあるところの話から、
プロセスってとこに行ったときにかなり話が盛り上がったっていうところがあるので、要素分解のパターン、もともとは構造の中の話がありますと。
じゃあこういう構造化ってCSの業務だとどういうふうに具体的に使えるんだっていうところの話に、次回はですね、移っていきたいなと思います。
はい。
ということで今回は以上としたいと思います。ありがとうございます。
ありがとうございます。
