-
-
Takaya Deguchi
うん。
kudakurage
僕もまあ結構前に札幌の方に、まあちょっと長い間滞在していた。
まあ仕事したりとかしてたんですけど。
Takaya Deguchi
うん。
kudakurage
ワーケーション的に。
Takaya Deguchi
はいはい。
kudakurage
その時にはまあ六家庭のお店もあるから、札幌市内とかに。
だからまあ僕ももともとあのバターサンドも好きだったし、まあそれも買ったりとか。
まあちょっとしたお菓子買えたりとか。
まあそこのお店なんかアイス、ソフトクリーム的なやつもなんか売っちゃったりとか色々するんだけど。
うーん。
なんかその時に結構色々買っちゃったりとかしてた気がするな。
Takaya Deguchi
バターサンド美味しいっすよね。
kudakurage
美味しいよね。
美味しい。
Takaya Deguchi
僕北海道に住んでたからまあ比較的身近ではあるんですけど。
うんうん。
なんかね、店舗とかも結構オシャレじゃなかったですか。
うん。
kudakurage
そうそうそうそう。
うん。
札幌のやつとかはね。
あ、六家庭ってもともとどこなんでしたっけ。
うーん。
もともと札幌とかなんですかね。
どこだっけ。
Takaya Deguchi
箱立て。
箱立てかな。
kudakurage
あれ?のイメージもあったけど。
うーん。
Takaya Deguchi
まあ箱立てにはなんかいっぱい店、いっぱいでもないか。
あ、でも本社は帯広、帯広みたいっすね。
あ、帯広なんだ。
うん。
なんか箱立てに直営店があるんですけど。
うん。
なんかめっちゃいい、なんか桜、桜の季節になるとなんかこうめちゃくちゃ綺麗な場所にあるんですよね。
うーん。
一等地みたいな場所にあるんですよね。
kudakurage
あ、五稜角店ってやつかな。
Takaya Deguchi
そうそうそうそう。
kudakurage
箱立てとかは確かに場所広いらしい。
なんか札幌の僕行ったところはもう本当に市内のさ、都市の真ん中とかさ、中心地にあるからさ、やっぱそんなに、なんていうの。
うーん。
まあ結構施設としては大きかったような気がするけど、庭があるとかそういう感じじゃないわけですよ、やっぱり。
はいはいはい。
で、その道路に面してたりするわけだし。
Takaya Deguchi
だからこの五稜角店は、まあ五稜角っていう、まあなんか公園というかに隣接してるんですけど、なんかそこが庭みたいになっててめっちゃ綺麗です。
kudakurage
うーん。
良さそう。
Takaya Deguchi
これをバクバク一人で食ってますね。
めっちゃ太ると思うけど。
太りそう。
kudakurage
美味しい。
太りそうだなあ。
Takaya Deguchi
まあでも、毎月お届けと言いつつ、まあサブスクじゃないから、まあ結局2ヶ月、1ヶ月分届いたやつを2ヶ月ぐらいで食べてますけどね。
kudakurage
ああ、サブスクじゃなくて毎回頼んでみたいな。
Takaya Deguchi
そうそう、毎回頼むんですよ。
はいはいはいはいはい。
で、季節によって入ってるものがちょっと変わってくみたいなやつですね。
kudakurage
うーん。
Takaya Deguchi
雪屋コンコとかも定番だけど美味しいですね。
kudakurage
そうですね。
まあなんかだいぶ前に何だっけ、僕あれやってたけどね、あのお菓子のサブスクのやつ。
Takaya Deguchi
ああ、スナックミー?
kudakurage
ああそうそう、スナックミー。
あれもね、結構良かったけどね。
やめたんですか?
今はもうさすがにやってない。
やってないっていうか、多分引っ越しする時のタイミングでちょっとやめちゃったんだよね、1回。
Takaya Deguchi
うーん。
kudakurage
なんかゴタゴタするじゃないですか、その引っ越しのタイミングって。
その、こっちに送ってほしいだろうな、なんかなるからやめて、でもまあなんかそれからやってないって感じだったから。
なんかやってないみたいな感じになっちゃったんだけど。
Takaya Deguchi
スナックミー、なんか実店舗がうちの近くにあるんだよな。
kudakurage
あ、そうなんだ。
うん、まだ行ったことないですけど。
実店舗あるの?
Takaya Deguchi
あれ清澄だけなのかな、ひょっとしたら。
テスト的に出してるのかな。
なんか最近できたんですよね。
kudakurage
そうなんだ。
まあなんか結構いろいろね、たぶんもともとはいろいろなお菓子をたぶん詰め合わせてやるみたいな感じだったけど、
たぶん今は結構自社でいろいろ作ってとかも、お菓子を作ってとかっていうのを結構やってるっぽいからね。
うーん。
あ、そうなんだ。
そうそうそう。
やっぱりなんかね、その、まあその減価コスト的な部分もあるかもしれないし、
まあもっとこういうお菓子をなんかちゃんと安心して食べてもらいたいとか、たぶんそういうのもあるんじゃないですか、やっぱり。
Takaya Deguchi
えー、じゃあそのなんか、まあなんか工場も兼ねた店舗なのかな、清澄はひょっとしたら。
kudakurage
かもしれないですね。行ってみてほしいですね、それは。
Takaya Deguchi
口コミを見るとなかなか人気っぽい雰囲気。
kudakurage
あ、そうなんだ。
Takaya Deguchi
うーん。
kudakurage
まあ普通においしかったからね、スナックミーのお菓子とか。
うーん。
で、なんか別に甘いやつだけじゃなくてさ、なんか辛いやつ、ちょっと辛いっていうか塩辛いやつもあったりとかさ。
うーん。
またなんかこのドライフルーツ的なものもあったりとか、まあまあその辺は好みで選べたりするから、やっぱりその辺も。
Takaya Deguchi
なんかロカボっぽいのもなかったでしたっけ、確か。
kudakurage
あ、あった気がする、そうそう、そういうのも。
Takaya Deguchi
うーん。
kudakurage
なんかでも、もう一個好きな、まあお菓子、お菓子じゃないな、おやつというか、まあおつまみに近いものもあって。
うーん。
それはね、なんかね、たぶんセブンイレブンとか伊東洋門とか、あっちのほうでしか売ってないんですけど。
うーん。
なん、なん、まあなんていう商品だったかちょっと覚えてないけど、トリフナッツみたいな。
ほう。
トリフ、まあ、あ、でもトリフナッツであってんのかな。セブンプレミアムとかのトリフナッツとか多分出てくると思うけど。
うーん。
これがね、めちゃくちゃおいしいんですよ。超おすすめ。
Takaya Deguchi
ああ、なんか見たことあるな。
kudakurage
まあなんか誰かも確かすごいおすすめしてた気がするけど。
Takaya Deguchi
うーん。
kudakurage
このねトリフナッツ、いろいろまあこのトリフナッツみたいなやつは、あのまあいろんなメーカーが作って出してたりするんですよ。
Takaya Deguchi
うーん。
kudakurage
で、僕もなんかまあいろいろ試してこう食べてみたんだけど、このセブンプレミアムのトリフナッツが一番おいしい。
うーん。
って僕は思ってる。
Takaya Deguchi
売り切れ続出ってなんかネットニュースに書いてある。
ああ、そうなの。
kudakurage
うんうん。
まあ普通になんかいつも僕伊東洋稼働、まあいつもなんか伊東洋稼働の方が僕の家からちょっと遠いんで。
うん。
買い物だいたい行くときOKストアっていうスーパーの方に行くんだけど。
うん。
なんかどうしてもトリフナッツ食べたいなっていう時に伊東洋稼働に行ったりとか。
うんうん。
ちょっと遠くに行くみたいな。
Takaya Deguchi
そこまで。
kudakurage
まあでもそれだけじゃないけどね。
なんかそっちの方にどうしても用があってみたいな時についでにトリフナッツ買うとかっていうのあったりするけど。
でもやっぱりなんかそのOKストアに売ってる他のメーカーのトリフナッツとかもいろいろ試したけど、やっぱなんかあっちの方がおいしいなみたいな。
へへへ。
あって結構ねこれが好きなんですよ。
このセブンプレミアムでセブンのトリフナッツが。
まあお酒とかねバッツリ合うし。
Takaya Deguchi
うーん。
kudakurage
まあ僕なんか好き、その時一時期なんかすごい好きすぎて、自分でトリフナッツ作ってたからねなんか。
そんなに。
まあ作るって言ってもねそんな素焼きのナッツ、ミックスナッツが売ってんじゃないですか。
Takaya Deguchi
うーん。
kudakurage
まあそれ買ってきて、まあ僕はあのトリフジオ、トリフソルトみたいなやつ。
うーん。
もう持ってるんで、それをこううまくかけて調合していい感じにして食べるみたいなことやってましたね。
これもね、まあお酒好きな人とかだと特にめちゃくちゃもうなんかおいしくてバクバク食べちゃう。
これも。
Takaya Deguchi
ナッツ食べるんじゃないですか。
kudakurage
いやいやいや、ナッツならいいってことないと思ってる僕最近。
そのなんかね、僕もナッツならいいと思って、ナッツ結構買ってたんですよ。
よくそのあるじゃないですか、あのなんか素焼きのさナッツでさ。
うーん。
富沢商店とかでしたっけ。
まあちょっといいやつ。
Takaya Deguchi
うーん。
kudakurage
富沢商店のミックスナッツとか素焼きのミックスナッツとか。
うーん。
よく常備して買ってたんですよ。
うーん。
でもこれならいいかなと思ってバクバク食ってたら、まああれもね太るよねやっぱり。
質質だからね結局。
Takaya Deguchi
まあそう。
kudakurage
言ってみればね、もう質質だからあれは。
うーん。
食べ過ぎはやっぱり良くないですね。
まあでも最近はでもやっぱりどっちも、どっちもっていうかまあ結構控え、控えてるね。
うーん。
じゃあ今日は。
はい。
今日は前にも来ていただいて、よくちょいちょい話に出てくる池田さんからおすすめされた本。
Takaya Deguchi
うーん。
kudakurage
プロセスビジョナリーっていう本。
Takaya Deguchi
ああ、僕も買ったけど、済んでるなまだ。
kudakurage
うーん。
をまあちょっと読んでみたので、ちょっとその話をしようかなっていう感じですね。
うーん。
プロセスビジョナリー、2019年9月発売ですかね。
なのでまあちょっと前ぐらいのやつですけど、なんかその時池田さんが言ってたのは、まあ池田さんが一緒に、一緒にというかまあ手伝っている仕事の人がまあこのプロセスビジョナリーってやつに感銘を受けて、
まあなんかそういう働き方をしてるんだみたいな話をしてたかなっていうふうに思うんですけど。
Takaya Deguchi
うーん。
kudakurage
まあ僕もなんか正直どういうことなのかよくわかんないけど、なんか面白いって言ってるから買って読んでみるかみたいな感じで一応読んでみたんですが、
内容としてはですね、ビジネスアナリストっていう職種の人を紹介する本っていう感じですかね。
うーん。
でまあビジネスアナリストっていう人がどういう人なのかっていうことだとか、あとまあなんでそういう人が求められているとか、日本で今必要とされているのかとか、
kudakurage
具体的な仕事の事例とか、仕事とかその事例、まあなんか具体的にそれっぽい、そういう関係の人、仕事をしてる人にインタビューというかそういう話を聞いた、
インタビューの話とか、あとはなんかそういう人どうやったら育てられるのかとか、どういう環境が必要なのかみたいな話がまとまってる本っていう感じでしたね。
じゃあそのビジネスアナリストっていう人は何なのかっていうところなんですけど、
一応これ書いてあることをそのまま言うと、お客様、お客目線で全体最適のプロセスの姿を創造し、デジタル技術の知見を持って演じ屋に対して要求を支持できるプロセス、ビジネスプロセスマネジメントの専門家、みたいなことが書いてあった感じですね。
結構なんかビジネスアナリストって割と広い感じらしくて、ざっくりこういう感じの人たちは大体みんなビジネスアナリストですみたいな感じっぽいところがあるんですよ。
どういうことかっていうと、中にはわかりやすい例で言うと、ウェブサービスとかウェブサイトの使いやすさ問題点みたいなものをお客さん目線で情報分析収集して、施策を考えて立案して、機能要求とか仕様の策定考えして、それを開発する人たちに依頼して最後検証したりする人みたいな。
言ってみたら、IT業界、ITのウェブサービスとかそういうのを作ってる人からしたら、大体そういうのプロダクトマネージャーとかプロジェクトマネージャーっぽい人がやってそうだなみたいなイメージ。場合によっては会社によってはディレクターって呼んでたりするかもしれないですけど。
ぽい感じにも見えるじゃないですか。最近だとそういう系の人もいるらしいです。そのビジネスアナリストっていうのは。ただ、ちょっと多分、これは具体的に書いてなかったんで、僕が思うに、プロダクトマネージャーとかプロジェクトマネージャーとどういう違いがあるんだろうなっていうのを考えたときには、
どちらかといったら、プロダクトマネージャーとかPM、プロジェクトマネージャーがやってるようなことをもうちょっとサポートする人というか、多分PDMとかPMみたいな人だと、人とか進捗状況のマネジメントとかもっと広い範囲でやったりする業務があるわけじゃないですか、多分。
そこはやらないみたいな。それはマネージャーの仕事で、それをもうちょっと、そういうところじゃない問題点を分析するとか、施策を考えるとか、実際の仕様に落とし込むとか、それをサポートするような人みたいな感じなのかなっていう認識ですけどね、僕の中では。
Takaya Deguchi
なんかSaaS系だと、前の会社も言ってたんだけど、PMMっていう役割を最近置く会社結構あるんですよ。プロダクトマーケティングマネージャーっていう、プロダクトに関わるんだけど、どっちかというとビジネスサイドの、特にSaaSだと営業とかCSとかマーケターとかいろいろいるから、そういう人たちの要求を取りまとめるみたいな立場でプロダクトに向かうみたいな。
一方PDMは、エンジニアデザイナーとかの方を束ねるみたいな、そういう役割分担する会社は多くて。そういうような、そのPMMみたいなイメージなのかな、聞いてると。
kudakurage
うーん、まぁちょっと、それ言う人もいるかもしれないです。 ただなんか、一応本。
Takaya Deguchi
それよりも広いような。
kudakurage
いや本の中では結構、それプラスエンジニアの方もちょっと詳しいみたいな。 だから、なんだろう、そういう問題解決して、なんかこう、何かを改善していくプロセスを回す人のところを結構ざっくりこう、ビジネスアナリストって言ってるみたいですね。
なるほど。
今のは、その割と普通のウェブサービスとかサイトの話みたいな感じだったんですけど、多分これって割と最近っぽいんですよ。こういうことをもうビジネスアナリストの人が入ってくるみたいなのって。
元々は、その社内の中における業務の改善をする人みたいなところが結構最初の始まりというか、あったみたいですよ、そういうのが。
で、その業務改善って言ってもさ、大体そういうのを実際運用するとか、使う人っていうのはビジネス側のサイドの人っていうかさ、そういう人でやってるわけだけど、実際に何かそれを作る人はエンジニアだったりとか、
もしかしたらそのビジネスのプロセスっていう意味では、営業物流とか管理開発サポートとかいろいろな部門があって、それ全体としてビジネスの価値を届けているんだけど、そのビジネスのプロセスをもうちょっといろいろ分析して、なんかここもうちょっと改善できそうだよねみたいな問題があるよねみたいなところを、
結構各部門を飛び越えて業務改善するような変革をする必要性があるよねみたいな、それを取りまとめるような存在みたいなのがビジネスアナリストとして存在するみたいな。
そうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそうそう。
を作っていくっていうような方に振ってる人もいるらしいですよ。ビジネスアナリストの中でも。
だからなんか、もともとはビジネス側の要求みたいなものと、それを実際に開発するエンジニア側の視点みたいなものをうまく擦り合わせるような存在。
みたいなところが結構発端というか重要なところみたいな感じなのかなと思いましたけどね。
場合によってはそういうコミュニケーター的な存在がいないと、実際に上がってきた要求がわからないとか、どういうこと言ってるのかよくわかんないとか、
こういうふうにまとめてみたんだけど、それはちょっとビジネス側としては受け入れられないなみたいな。
例えば、新しいやり方をした方が改善できるよねって思って提案しようとして、作ろうとしてみたんだけど、
実際に業務を行う人を束ねる部長みたいな人は、新しい業務ツールを導入するにあたって、前にできたことはやっぱり全部できるようにしてほしいなみたいなこと言ってくるみたいなこととかも多分あると思うんだけど、
それやっちゃうと改善にならないよなみたいなこともあるわけですよ。
で、実際にそれをよく聞いてみると、やっぱり導入にあたって、実際に業務を行うその部下、その部長の部下の人たちが負担になるんじゃないかみたいな懸念をしていたらしくて、
そういうのをもうちょっと解きほぐすために、実際に業務を行うメンバーも含めていろいろ意見を聞いたりとか、改善後のイメージしてもらうための時間を設けたりみたいなそういうコミュニケーター的な存在としても働かなきゃいけないみたいな。
Takaya Deguchi
なるほどね。何にも導入してない営業の現場みたいなのがあって、そこに対してセールスフォース入れていくぞみたいな動きがあって、でも何も現状の営業の仕方とか分析せずに入れるといろいろ不満出てくるから、不満っていうか合わない状況が出てくるから、そこを冷静に分析して入れましょうみたいな、そういう人ってことを。
kudakurage
そういうのも一つ、ビジネスアナリストの仕事としてはあるかなというふうに思います。もう一個なんか、もう一個というか、まあ多分いろいろあるんですけど、もう一個大きなものっていうか大きな範囲として、もうちょっとさらに中長期的な経営者目線でビジネスプロセスというか、そういうものを改善するための試作を企画する人みたいな、
これはもうちょっと大きな単位な感じだと思うんですけど、そのセールスフォース導入するみたいなところよりはもうちょっと大きい視点というか。
それはビジネスアーキテクトみたいなことを言ってたりするらしいんですけど、肩書きとしては。
その人はもう本当にもっとビジネスアナリストよりももうちょっと大きい視点で、中長期的な視線でビジネスを改善する人みたいな感じで、その人が考えた企画とかに合わせてさらに個々のビジネスアナリストがより細かい流度の業務改善を行っていくみたいな感じの構造というかね、そういう感じらしいんで。
kudakurage
結構いろいろ範囲とか立ち位置によって、多分いろいろ同じビジネスアナリストっぽい人としてもやり方っていうのはどんどん変わってくるんじゃないか。
もしかしたら業種によっても、もろIT系の人たちともっと物理寄りというかさ、物理を単純にやってる人とかによっても結構変わってくると思うんで、やることとかどういうツールが必要になるのかとかっていうのは。
結構だから広い範囲なんだけど、一貫しているのは多分ビジネスプロセスみたいなものを改善する。しかも改善した上で、いろんな部門の人たちの橋渡しになるようなコミュニケーターであるみたいなところなのかなっていうふうに思いましたけどね。
Takaya Deguchi
なんかそれを聞くと、僕は前の会社でそれやってたんだなと今知りました。
kudakurage
結構ね、だからこの本読んでて、割と出口君はこのビジネスアナリスト的な役割を多くしてるんじゃないかなと思いましたね。
それは前の会社もそうだし、今ももしかしたらそうかもしれないなっていうふうに思いましたね。
実際に具体的なビジネスアナリストの役割みたいなのも書いてあったりするんですけど、さっきも同じように言ったんですけど、客観的な立場で業務サービスの問題分析を行う。
多くの関係者から上がる要求をまとめて、新たなビジネスプロセスを設計する。この辺は多分情報収集、分析、立案みたいなことですよね、きっと。
ソリューションを開発するエンジニアに要求を伝えて、要求通りのソリューションとなっているか検証する。
この辺は仕様に落とし込んで実際に作ってもらって、それがちゃんと要求通りになっているか検証するってQAの部分をやるみたいなことですよね。
あとは取り組みに関係する部門、組織のコミュニケーションハブになり、関係者の協力体制を構築する。
ここは本当に取りまとめるコミュニケーター的な部分みたいなことですよね。
みたいな感じが大きなビジネスアンタリストの役割っていうふうに言われてるみたいですね。
実際には仕事としては本当にいっぱいあるらしいんですけど、例えば導入、これを立案して作ってもらいました。
導入するにあたってお願いみたいな感じでも多分うまくいかないわけだから、マニュアル作るとか、導入をどういうふうにやったらいいかっていうための業務ルールを見直すとか、
生かすためのソリューションを生かすためのとか、場合によってはもしかしたら組織自体を改変するとか役割分担を変更するとか、
そういうことも必要になるかもしれないし、そういうことを考えるとかも場合によってはビジネスアナリストが考えてやるって提案していくみたいなことが必要になるかもしれないみたいな。
Takaya Deguchi
なるほどね。だから、もともとは自社の業務を改善するというか、そういう立場でいるんだけど、
それが最近SaaS企業とか増えてきて、そうすると立場が変わって、自社の製品、要はユーザーの業務改善をするための立場に変わりつつあるっていうことなのかな。
kudakurage
どうなんだろうな。
Takaya Deguchi
要はビジネスアナリスト自体が商品になってきているというか、SaaSの企業だったらプロセスの改善をするじゃないですか。
kudakurage
それはそうだと思いますね。
あらかるよりニーズが高まってますよっていう話なのかな。
それもあるかもしれないですね。
ビジネスアナリストは、言ってるようにビジネス側の視点とデジタルソリューションって言われてるエンジニアリング的な、ITソリューション的な方の両方の視点みたいなものを持つ必要性があるんですよね、基本的には。
Takaya Deguchi
技術とかデザインのこともある程度分かってるけど、でも自分では実行できるわけではないから、
だから僕らみたいなデザイン会社とかそういったところに依頼をする立場として立ってるみたいな。
kudakurage
そうだね。
Takaya Deguchi
なるほど。
kudakurage
最近だったらDX、デジタルトランスフォーメーションとか言われてますけど、
そういうのよくある失敗事例としては、そもそもデジタルソリューションを導入すること自体が目的化するみたいなのがよくあるんじゃないかなと思うんですね。
最近だったらAIって言われてるから、AI使わなきゃみたいので無理やり導入するみたいなのが何かで。
Takaya Deguchi
デザインシステム作るぞみたいなね。
kudakurage
それも一つあるかもしれないですよね。デザイン志向だ、デザインシステムだって言って、それをとりあえず入れてみようみたいなのが目的化して、
別に何かで必要だって言うわけでもないのに、無理やり入れることで何も生まれないというか逆に面倒なことが増えるみたいなね。
その辺は一方的なデジタルソリューションを入れるっていうだけになっちゃうんで、
多分そこにもうちょっとちゃんとビジネスのニーズがどこにあるのかっていうのを理解するとか、
ビジネス側のニーズがどこにあるのかっていうのをちゃんと正しく理解するとか、
その要求をうまく取りまとめて、それに合わせてちゃんとデジタルソリューションを選んで導入していくっていうのが必要だよねっていうのを
支難する役というかね、ビジネスアナリストっていう人ですね。
で、いろいろ書いてあったんですけど、詳しい仕事も書いてあったけど、
この本自体もやっぱりビジネスアナリストのやり方みたいなのを紹介する本ではないって言ってて、
ビジネスアナリストっていう人がどういう人なのかを紹介する本ですよぐらいの感じで、
割と導入本みたいな感じだったので、いろいろ役割とかそういうのは書いてあったりはしたんですけど、
結構面白いなと思ったのは、これ歴史的な話なんですけど、
どういうきっかけでこういう人たちが生まれていったのかっていう部分で、
始まりは1990年ぐらいかららしいんですけど、
なんでかって言ったら、1990年ぐらいから割とコンピューターというかね、
そういうITソリューション、デジタルソリューションみたいなものを使って、
会社をもうちょっと良くしていこうみたいなのが生まれ始めるというかね。
1990年ぐらいからビジネスプロセスに情報システムみたいなものを導入していこうみたいなのが始まっていくので、
その辺から結構ビジネスプロセスって言ってるんですけど、
どういうふうにしてお客様にサービスとかものを届けるのかっていう一連の流れをビジネスプロセスっていうんだと思うんだけど、
それに対して今までは人がアナログにこう全部いろいろやっていたのを、
その部分部分で結構システム導入していくみたいなことをやっていったことによって、
どんどん複雑化していったんだと思うんですよ。
人がやっていたり機械がやっていたり、しかも機械がやってることは場合によってはブラックボックス化していったりとかして、
どんどん複雑化していって難しくなっていってしまったんですよね、その辺が。
だからそれをもうちょっとうまく、
なんでこういうふうにやっているのかとか、なんでこうしたのかみたいな部分をもうちょっとちゃんと管理しておかないといけないよね。
その時はどういう要求があったのかみたいなことを。
その辺をちゃんと明らかにしていく人として、そのビジネスプロセスを分析する人として、
ビジネスアナリストみたいな人が生まれていったっていうような感じの経緯らしいですね。
大体のこういうふうにビジネスプロセスに情報システムを入れていくっていうにあたって、
結構アメリカの方とかでも最初の頃は失敗とかもいっぱいあったらしいんですけど、
その失敗っていうのは大体技術的な問題ではなかったらしいんですよね。
技術的な問題っていうのは普通にエンジニアリングとして失敗してて動かないとかそういうことではなくて、
どっちかっていうとビジネス側からの情報不足みたいなとか、
要求とか仕様が不完全だったりとか途中で変化しちゃってるけどそのままやり続けちゃった結果、
ちゃんと動かないみたいな、ちゃんと機能しないっていうかね、ビジネスとしては。
ものになっちゃったので、この辺やっぱりさっきも言ったようにビジネスとエンジニアをつなぐ存在みたいな人が必要になるんじゃないかみたいな。
ところからビジネスアナリストが生まれてきて、現状のビジネスプロセスの問題点とか、
そういう情報収集分析して全体最適になるように業務改善となる施策を考えて、
要求される機能とか仕様を適切エンジニアに伝えてちゃんと作ってもらって、
Takaya Deguchi
みたいなことをやる必要性があるよねみたいなところから生まれていっているらしいですね。
要求定義とか要求開発とかそういうやつか。
kudakurage
そうそうそうそう。
結構ね、要求のあたりは本の中でも要求管理とかそういう話とかいっぱい出てきた気がしますね。
それも最初はビジネス要求っていう企業全体の話ですよね。
その戦略的な要求とかから始まって、ステークホルダー要求に落とし込む。
これは実際にビジネス要求をやっていくにあたって、
実際にステークホルダーがもうちょっと仕様に落とし込めるような、
じゃあこういった項目が必要だよねみたいなのを表し出すような調査みたいなところですよね。
実際にそれをソリューション要求っていう、
Takaya Deguchi
それに当てはまるソリューションは何なのかっていうところを考えていくみたいなところをやるみたいな。
なんかいろいろ大学でやったわってめっちゃ思い出してきました。
kudakurage
こういう話。
Takaya Deguchi
はいはいはいはい。
kudakurage
なんかSIRでいうSEなんでしょうね。
そうそうそうそう。
もともとは多分こういう要求管理というかさ、
要求を分析、要求分析みたいなやつって多分エンジニアリング的なところから来てるはずなんですよね確か。
なので多分それに近いところはあると思います。
Takaya Deguchi
SIRでいうSEだし、デザインでいうサービスデザインとかそういう分野の話ですかね。
kudakurage
それを割とビジネスとか、ビジネスとソリューションをつなげる、
デジタルソリューションをつなげるためのところに当てはめているっていうような感じですよね。
まあビジネス要求とかもうちょっと大項目からブレイクダウンしていくっていう意味では
割とゴールダイレクテッドデザイン的な発想というかそういうところもあるだろうし。
Takaya Deguchi
いやでもこういう人いるといいですよね。
結局いないから、でもなんかデザインするってなったときに
でも考えなきゃいけないからこういうところを。
だからなんか僕らが多分そこをカバーすることになる気がするんですよ。
kudakurage
結構誰かがやってることは多いみたいなね、これに当たるのを。
もしかしたら一人じゃなくて複数人で分担してやってる可能性もあるかもしれないですね。
Takaya Deguchi
それをエンジニアがやる場合はその人をSEと呼んだりとか、
デザイナーがやる場合はその人をUXデザイナーなりサービスデザイナーと呼ぶみたいな話なんですかね。
kudakurage
場合によってはプロダクトマネージャーが結構ガッツリやってるっていう可能性もあるだろうしね。
でもこういうのを結構やってる人はいると思うんですよ。
例えば業務改善にしても社内でこういうことを考えてやってる人とかっていうのもいるかもしれないですけど、
割とこの職種、専門的な職種として置いてるっていうのが重要なところもあるんじゃないかっていう話がありそうで。
例えばプロジェクト単位で、この時は私がこのプロジェクトを率いて、
じゃあこういう役割をやりましたってなっても、
その知見が残っていかない可能性があるんじゃないかみたいな。
そういうことをやっていたっていうところの知見が。
そういう意味で、そういうビジネスアナリストみたいな職種を作って、
場合によってはそういう組織を作って、
そういう知見が溜まるようにしていく必要性はやっぱりあるんじゃないのみたいなのは結構、
海外とかだと割と積極的にというか盛んに今もやってるみたいな感じなのかなっていうふうな。
なんか結構今までも会社とかでも、
その業務改善的なことっていうのがいろいろあったりしたかもしれないですけど、
その時はこの人が担当してうまくそのプロジェクトを進めていくけど、
Takaya Deguchi
別にそれが終わったら別のまた仕事についていくみたいなことも結構多いんじゃないかなっていうか。
kudakurage
だからその辺のやり方というかね、そのプロセスというかさ、
その部分の知見みたいなものをどんどん貯めていくとか、
そこをちゃんと専門家として強化していくみたいな人っていうのが必要なんじゃないのみたいなところがあるのかなと思いました。
日本ではやっぱりまだまだ結構浸透してないと思うんですよね。
僕もあんまり聞かないし、ただ海外だとビジネスアナリストっていうのが重要な職種としてかなり定着してるらしいんですよ。
僕は知らなかったんですけど、普通にその募集採用職種みたいなところに普通に上がってくるし、
かなり人気度も高いしみたいなところらしいんですよ、ビジネスアナリストっていう職種が。
で、日本での認知度がいまいちな理由はこうなんじゃないかみたいな話がちょっと書いてあって、
特に大企業とかの社内でビジネスアナリストとして活躍する人はまだ多くなさそうだよなみたいな。
その理由として、おそらくですけど、特に大企業とかだったら、
IT の導入とか企画、要求の明確化、開発運用みたいなところって、
割と全般外部の人材、会社、ベンダーとかに頼る傾向があるよねみたいな。
SIR ですよね。
で、おそらくだけどそれっていうのは、さっき言ってた1990年代のIT導入の始まりの時代に、
日本がどういう状態だったかっていうと、バブル崩壊後の不況の時代だったわけですよね。
で、そういう状態だから、社内の、例えば IT 人材の育成みたいなところにかけられるリソースみたいなのもあんまりなくて、
とはいえ、IT カーに乗り遅れないようにしなきゃいけないよねみたいなところから、
外部の IT ベンダーみたいなものを結構積極的に活用していったんじゃないかっていう話があって。
で、社内の IT 部門みたいなのもあるんだけど、
それはどっちかっていうと、ベンダーとの調整を行うみたいな。
とか、予算管理するみたいな窓口的な役回りになっていって、
でもそれが状態化したことによって、システムの仕組みだとか構造について、
その担当者があんまり理解してなかったり、
場合によっては仕様についてもあんまりちゃんと把握できてなかったり、
人が増えたんじゃないかみたいな。
で、それがどんどん加速していっちゃってるんじゃないかみたいな、日本国内の場合だったらね。
kudakurage
時代がちょっと進んでいくと、
ただ、それをずっとやってると、IT 化が進んでいって、
それと時代とともに。
で、ビジネスプロセスの複雑さっていうのは、たぶんどんどん増していくと思うんですよ。
SNS で増えて、マルチチャネルだといって、情報もどんどん増えていくし、
どんどん複雑化していって、外部 IT ベンダーのエンジニアが、
その会社のビジネス要求を全て明確化するみたいなことがどんどん難しくなっていったと思うんですよ。
これ、どうしたらいいかわかんないみたいな感じになっていって、
でも作んなきゃいけない、こういうふうに物作れって言われてるから作んなきゃいけないって言って作るんだけど、
やっぱりなんか違うみたいな感じになって、結構トラブルもあったらしいんですよね、そういう。
だから、ベンダーとそれをお願いしているクライアントとの間の。
それは結局、依頼しているビジネス側にあんまり主体性がないから、
やっぱり本来必要だと思われる要求に沿ってないソフトウェアみたいなのが出来上がっちゃって、
プロダクトを迷走したりとか、コストが増えたりとかして、
IT 関連のそういう訴訟も結構一時期あったらしいんですけど、
それを受けて、ちゃんと機能要望を明確にしてベンダーに伝えたりとか、
ベンダーからの協力依頼は対応する義務をちゃんと追いましょうみたいな契約をするようになってたんですよね、段々と。
そうすると、突然依頼側のクライアント側のビジネスサイドが、
自分たちの要求をちゃんと明確にやらなきゃいけないみたいな、
ビジネスアナリスト的な仕事をしなきゃいけないみたいな風に言われるわけですよ。
でもみんな出来ないから、どうしようっていう風になった時に、
結局外部のビジネスアナリストにお願いするっていう風になって、
これがいわゆる日本で言うコンサルタントってやつなんじゃないかみたいな。
結局今だとコンサルタントと開発ベンダーにお願いして、
それを管理する人が社内にいるっていう感じになってんじゃないかみたいな話ですね。
Takaya Deguchi
あと何かよく言われるのは、会社の体質として、
Takaya Deguchi
日本の会社、結構大きい会社は特に組織に対してソフトウェアを合わせるっていうような考え方が強いっていう話は何かよく聞きますけど、
それこそこういう要求開発とか、そういう系の抗議とか大学で受けるとよくされる話で、
アメリカとかだとソフトウェアに対して組織を合わせていくみたいな、
大学みたいな、組織とかビジネスプロセスみたいなのを合わせていくから、
だからその結果型にしやすくて、SaaSみたいなものに発展しやすいんだけど、
日本の場合はそれが逆だから、だから個社にカスタマイズしなきゃいけなくて、
そうするとSIRみたいなオーダーメイドでソフトウェアを作りますよっていうようなオーナーが増えていったり、
あるいはいろんなSaaSを組み合わせて自分の組織のプロセスとか組織のフードに合わせなきゃいけなくなって、
結果すごくピタゴラスイッチみたいなシステムの全体像が出来上がるみたいな、
だからそうすると一個何か導入するにもSIRなりコンサルなりが必要になってくるみたいな、
そういうことはよく聞きましたけどね。
最近はSaaSが流行ってきてるからまた変わってきてるんだろうけど、
だから結構いかにソフトウェアの方を合わせるんじゃなくて、
組織の方を変えられるかどうかが大事だみたいな話は結構聞いたなって今思い出しました。
kudakurage
結構バランスなんでしょうけどね。
完全にソフトウェアに合わせて組織だけを変えていくっていうのも多分変な感じになっちゃいそうだから、
多分どっちかっていうとビジネスのやり方に合わせて組織もソリューションも合わせていくみたいな、
のが多分一番いいやり方なんだろうなと思いますけど。
Takaya Deguchi
バランスを見極める中、何ていうのかな、
例えば営業とかのやり方とかって結構セールスフォースとかがあることによって、
セールスフォースのやり方に応じて営業の仕方を変えましょうとかっていうのは、
結構SaaSのビジネスのやってる会社だと何か当たり前みたいになってるんですよ。
それによってセールスフォースがザモデルっていうような、
営業ってこういうふうに管理しましょうねみたいなことを提唱したりしてて、
それに合わせると難しいこと考えなくて済むというか、
でもそれで完全に賄えるわけじゃなくて、やっぱり個社ごとに何かしら独自の何かがあって、
それはまた別途何かカスタマイズしなきゃいけなかったりするんだけど、
そこの分岐点を見極めるっていうことを多分、
kudakurage
このビジネスアナリストっていう人がやるんでしょうね。
Takaya Deguchi
あとは会計とかそういうのって大体もう型になってるじゃないですか、そのやり方が。
だからそういうところはなるべく独自のやり方じゃなくて、
kudakurage
王道に合わせましょうね、それによってSaaSで置き換えやすいですよっていうような話だと思うんですよね。
そうですね。
Takaya Deguchi
だから日本の場合はそこをなるべくフェアのほうが合わせろっていうような風潮が、
昔は強かったっていう流れもあるみたいですけどね。
kudakurage
なるほどね。
Takaya Deguchi
だからビジネスアナリストっていうような職業も海外のほうが先行して確立されてるっていうのは、
多分そういう風土の違いもあるんだろうなと思いましたけどね。
kudakurage
結構読んでるとビジネスアナリストはコミュニケーターの素質がかなりでかいんじゃないかなっていう気はしましたけどね。
その求められる能力として。
Takaya Deguchi
なるほど。
kudakurage
やっぱりもちろんなんかね、新しい技術について知っておくとか、
kudakurage
経営上のビジネスのニーズみたいなものをちゃんと情報収集して分析して施策立案できるとかっていうのあるんだけど、
多分それ以上にいろんな部門の人に対面して、
うまくフィットさせる、全員がフィットして、全員を最適な感じに揃えるみたいなところをやる能力みたいなのが、
かなり求められそうな職種だなっていうふうには思いましたね。
Takaya Deguchi
そうですね。
kudakurage
ただなんかとはいえ、どういう人がビジネスアナリストに向いてるのかっていうと、
なんかね、必ずしもコミュニケーションが上手い人というか、
人当たりがいいとかって書いてあったかな。書いてなかったかもしれないけど、何だろう。
そういうのが上手い人とは限らないって書いてありましたね。
どっちかっていうとそれよりも安定を好まない人みたいな、ガンガン変えることを厭わない人みたいなことの方が結構向いてるって言ってました。
Takaya Deguchi
確かにね。なんか組織をガラッと変えるぞみたいなことができる人の方が向いてそうではある。
kudakurage
だから、ある程度いろんな人にいい顔をするだけじゃなくて、たまにはこれはダメだっていうノーっていうふうに突きつけなきゃいけないみたいな場合によってはね。
Takaya Deguchi
忖度しすぎない人が大事そう。
kudakurage
そうですね。忖度してたらたぶんね。
Takaya Deguchi
忖度しすぎると全ての幸せがエンジニアとかデザイナーに行くっていう話ですよね。
kudakurage
どこかには幸せは行くからね。それがもしかしたら自分かもしれないし、実際に開発する人かそれはわかんないけど、たぶんどこかには幸せは行くはずだから。
Takaya Deguchi
内政だと嫌々つって、シェアワーが寄った方から反発が来るんだけど、SIRとかに外注してると別の会社だから、クライアントワークだからそこはやりますみたいな話になって、難しいシステムが出来上がるんでしょうね。
kudakurage
うまくいかないみたいなね。
Takaya Deguchi
でもそういう話があって、とはいえコミュニケーターとしての能力が必要だから、やっぱり女性の方が海外とかでも活躍してる人は多いみたいなことは書いてあったかな。
kudakurage
あとどう、そういうスキルを磨くとか、どうやって育てたらいいのかっていうのも、なかなか、
まあでもどの職種も同じかなとは思ったけど、その論理的な部分と実践経験的な部分両方が必要だから、部門立ち上げるとして、いきなり何も無から始めるのはやっぱり無理だっつって。
まあそりゃそうだろうとは思ったけど、やっぱりなんかどっからか優秀な人を一人とってきて、その人を先生にして、生徒を育てていくというか、初めて新卒でとった人とかも育てていくみたいな感じにしないとうまくいかないよね。
それもやっぱりその最初はサポートから始めていって、ちょっと徐々にその経験、実践経験を積ませていってみたいな感じらしいですけどね。
まあでもそれはなんかだいたいどの職種もそうなんじゃないかっていう気もしたけど、割と。
まあでもそれが必要なのはやっぱりあれなのかもしれないな。エンジニアとかデザイナーとかでも、いわゆる本当の技術的な部分というかスキル的な部分とそれとは違う、もうちょっと違う、
定性的な部分というかさ、ふわっとしたコミュニケーター的な部分って多分あるような気がしていて。結局だからそのコミュニケーター的な部分がビジネスアナリストだから、そこはやっぱりなんか実践経験とかも積んでいかないとなかなかうまくいかないよねっていう話なのかなっていう気もしたけど。
Takaya Deguchi
あとなんかデザイン的な文脈で捉えると、そのコミュニケーションって言ってるのは要はインタビューみたいなことなのかなっていう気もして。
まあそれはインタビュースキルを高めましょうっていう、なんかそういう話なのかなっていう気もしましたけどね。
実際そのコミュニケーションって言ってるのって、ただおしゃべりするっていう話なのじゃなくて、多分その業務プロセスを引き出したりとか観察したりとかそういう話ですよね、きっと。
kudakurage
まあまあその引き出す部分と多分インストールする部分と両方あるんだと思うんですけどね。
Takaya Deguchi
インストールもかね、インストールもやるんだ。
kudakurage
インストールもこの人たちはやらなきゃいけないです。やっぱりその単純に作って終わりっていうわけじゃなくて、さっき言ったように、
導入どういうふうにじゃあ進めていこうかとか、導入するにあたって業務ルールこういうふうに変えようかとか、その辺も考えてやっていかなきゃいけないみたいな役割としては。
Takaya Deguchi
なるほど。
kudakurage
結構多岐にわたるよね。多岐にわたるというか、やることはたくさんあるなっていう印象では。
Takaya Deguchi
なるほど。
kudakurage
だからね、さっきのプロジェクトマネージャーとかプロダクトマネージャーと違って、そのマネジメント、実際にそれを推進していくとのマネジメントの部分はやらないんじゃないかなって僕は思ったんだけど。
その辺までやってる手間がないっていうか、やってられないから多分時間的に。
もうちょっと。
Takaya Deguchi
あれっすね、SaaSの会社だとセールスイネーブルメントみたいな職種があるんですよ。
それはセールスに特化して、セールスの営業の人たちの業務を効率化させるためにツール、それからサイフォースとか導入して、
それこそ営業の資料を型化するとか、マニュアル作るとか、それを浸透させる、インストールの仕事もそのセールスイネーブルメントが責任を持ってやるとか、
そういう人がいるんですけど、それの源流みたいな感じなのかもしれないですね。
kudakurage
多分今だったら、この本が言ってるやつだとビジネスアナリストの一つの職種として、専門的なビジネスアナリストみたいな人もいて、
kudakurage
多分そういう分類に入ってくる人なんじゃないかなと思いますけどね、そういうのって。
だから業務改善みたいなところで言ったら、もうちょっとテキ寄りというか、エンジニア寄りで、
エンジニアのためのエンジニアリングみたいなのあるじゃないですか、インフラの良くしていくみたいなところとか、
デザインとかでも同じように社内全体のデザイン能力を上げていくみたいなことを僕もやってたことがあったけど、
そういうのも一つのある種、もしかしたらビジネスアナリスト的な役割のアッシュ的なものたちなのかなみたいな気がするけどね。
デザインオプスとか、そういう言葉があったけど、そういうやつかな。
多分もうちょっとあれなのかもしれないですけど、ビジネスアナリストっていう人はビジネス寄りなのかもしれないけどね。
でも業務改善っていう括りで言えば、割と近いのかなっていう風に。
Takaya Deguchi
セールスエネブルメントはセールスの端だったけど、全然そこをエンジニアにもデザインにも置き換えられる話ではありますよね。
kudakurage
そうそうそうそうそうそうそう。
Takaya Deguchi
それは思うんだよな。デザイナー達も別にフィグマに詳しいわけじゃないっていうか、
フィグマの使い方とかバリアブルズが最近こう使うといいとか、
すごい追っかけてる人もいれば別に関心ない人もいていいわけじゃないですか。
それ自体が別にデザイナーの仕事じゃないと思うから。
そういうところをやってくれる人とかすごいいたらいいんだろうなって思いますけどね。
kudakurage
そもそもだってね、結構前だったらフィグマみんな使ってないみたいなさ、まだ。
とか時期もあったわけじゃないですか。
でもそこで今こういう技術があるからこういうふうにやると、
なんかより業務がはかどりそうみたいなところをうまく導入していく役割みたいなとかもね、
ある種そういう存在であるような気がするよね。
Takaya Deguchi
逆にイネーブルメントが遅れすぎて未だにいられフォトショーでデザイン、
UI作ってますみたいな人ばっかりだとやっぱさすがになんか組織にも影響が出てくるわけじゃないですか。
そのスピード感的な意味で。
そうね。
kudakurage
それこそフィグマで言ったらさ、単純にデザインというかインターフェースのデザインというだけの話じゃなくて、
もうちょっといろんなタブショーの人たちをつなげるような存在になってきてるわけだから、
かなりビジネスに影響する可能性はあるよね。
Takaya Deguchi
これは今のところは一部のツール周りに感度が高い人がこれ使ってみたいって言ってボトムアップ的に入れることが多いけど、
そういう役割を明示的に作るっていうイネーブルメント職みたいなのは今後出てくるかもしれないですけどね。
kudakurage
そうだね。でも実際にエンジニアとかだと結構多いような気もしますよね。
Takaya Deguchi
ありそうだし特にデザイン会社とか開発会社とかそういうクライアントワークやってる会社だと入れる価値はありそうだし、
入れる価値はありそうですよね。
それによって作業効率が上がったりとかしたらダイレクトに裏切りとかに響いてくるわけだから。
kudakurage
だから大企業っていうかそういう制作会社とかじゃない、
普通に自社でいろいろビジネスやってるっていう会社だったら、
多分どっちかっていうとやっぱりビジネス側のビジネスプロセスをいろいろ改善していくっていうような、
いわゆるビジネスアナリストっていう人たちの方がかなり求められるのかなっていう気がしますよね。
実例もまあまあ面白かったかな。
無印良品の人の話とか。
無印良品は全然知らなかったですけど、
業務改革部店舗サポート課っていう人の話が書いてあるんですけど、
そもそも業務改革部っていう部があるらしいですね。
今回この本に書いてあるインタビューの人は店舗サポート課っていう、
店舗の業務改革をサポートする人みたいな人で、
常にいろいろ店舗の業務をどう改善できるか、どこ問題点がありそうかみたいなのを常に見ながら、
いろいろそれをどう解決できるかっていうのを常にやってる人たちみたいな物色があるらしいですね。
Takaya Deguchi
売りアポスとかそういうのを改善すると、ダイレクトに売り上げに響いてきそうだから。
kudakurage
そうそうそうそう。
kudakurage
こういうのは結構多そうですよね。
僕ら結構割とどうしてもデジタルというかウェブサービスとかそういうところでしか見てないけど、
やっぱり世界にあるビジネスの多くはアナログが絡んでくる部分っていうのは結構多いと思うんですよね。
物流だとか人のマネジメントだとかいろいろ。
それへんとさらにデジタルソリューションみたいなものをうまく組み合わせて改善していくとか、
やり方を変えていくっていうのは、かなり年単位でいろいろ変えられる可能性があるよねっていう話を結構書いてあったような気がしますね。
最近だったらね、やっぱりそれこそAI、LLLみたいなのをうまく使うとかっていう話ももしかしたらあるかもしれないし、
そういう感じで多分年単位で新しい技術が来るから、ここをもうちょっと改善できそうだなみたいなところが多分どんどん出てくるみたいな。
でもなんかいろいろ、やっぱビジネスアナリストって言ってるところはあんまりないかもしれないですね、日本の場合はあんまり言うほど。
Takaya Deguchi
そうですね。あんまり聞き馴染みがない。
kudakurage
ただそれに近しいことっていうか、ほぼほぼそれやってるよねっていう人たちはなんかいるみたいな。
Takaya Deguchi
どこかで誰かがやってますよね、システムが絡むところでは。
kudakurage
そうですね。でも結構やっぱり、こういうビジネスアナリストみたいな人たちの、さっきの育成みたいなのがあったけど、
働く環境みたいなのを作るときに評価とか、そういうのも整える必要性があるよねみたいな話もあるんだけど。
デザイナーとかも近いかもしれないですけど、やっぱり成果がなかなか見えづらいらしいんですよね。
3セカンドで少なくとも見えづらいっていうかさ。
少なくとも2,3年かかるみたいな、これいけそうだなっていうところが見えるまで2,3年かかって、
で、ちゃんとこれは良かったって評価ができるまで、もしかしたら5年ぐらいかかる可能性があるみたいな。
そういうかなり長期のスパンでしか見えてこない取り組みっていうのが多いから。
そういう意味でもなかなかどういうふうな評価軸でやったらいいのかっていうのは、
結構みんな悩んでそうな感じがしましたけどね。
Takaya Deguchi
なるほど。
kudakurage
そうですね。最終的には何だったっけな。
ビジネスはそういう管理部門と、管理じゃなくて何だったかな。
業績を担う人材と変革を担う人材みたいなのが来たかな。
その2つのコラボレーションが必要になるよねっていう話をしてて。
業績を担う人っていうのは、いわゆる日々のオペレーションをやってる人ってことですね。
変革を担う人っていうのは、オペレーターのやり方っていうのを考えたりとか変えていくような人っていうような。
でもその両方がやっぱり実際に物を売っていくとか、サービスを提供していくっていうのは必要で、
でもその両方をやっぱり必要だよねっていうところなんだけど、
やっぱり日本の場合はどっちかっていうと変革を担う人材みたいなのが足りてないんじゃないのっていうようなことを言ってましたね。
Takaya Deguchi
なるほど。攻めと守りの人が必要っていう話。
kudakurage
そうそうそうそう。本当にそうですね。
やっぱり業務、オペレーターはどっちかっていうと守りっていう感じもあるし、
それはビジネスを守るっていうところもあるけど、保守的っていうところも多分あると思うんですよね。
でもそこを改革していくっていう人材もやっぱり必要で、
それをしないとやっぱり時代に取り残されるとか、
適切なチャンス、機会みたいなのを逃していくみたいな可能性があるので、
そういう時のためにやっぱりビジネスアナリストっていうのをちゃんと社内で育てていくっていう必要性があるんじゃないのっていう話でしたね。
Takaya Deguchi
なるほど。
kudakurage
もうちょっと具体的な役割、能力的な話もちょっと書いてあった気がしたんですけど、
でもとはいえビジネスアナリストになるには、ビジネスアナリストのための本っていう感じっていうよりは、
ビジネスアナリスト知らないっていう人がどういう人なんだろうっていうのを知るぐらいの本だったんで、
具体的にじゃあこういうツールを使ってとかこういう考え方をしてみたいなことを書いてある本ではないんだけど、
でもなんか面白い、あんまり考えたことがなかったところだなと思って。
似たようなことをやってたりとか考えたりしたことはあったんだけど、
もうちょっと違う範囲も引っかかってたりするなみたいなところがあって。
Takaya Deguchi
こういうのありますよね。
やってるけど名前がよくわかんなかったけど、名前がついてみると、
ああこういう考え方もあるんだみたいな、ちょっと開けてくれたり。
kudakurage
はいはいはいはい。
そうそうそうそう。
今までだったらなんか自分の視野でその範囲みたいなのを見てたけど、
実はなんかここの辺も入ってるとか、もっと大きい範囲で視野が広がるような触手なんだみたいな、
やってることなんだみたいな。
を知ることによって、ここも考えなきゃみたいなところがわかっていくみたいなところがあるような気がしますね。
Takaya Deguchi
確かにね。
なんか僕結構大学こういうSEというか、
なんかそういうコンピューターサイエンスっていうよりは、
どっちかっていうとそういうSE的なシステムをどう作るかみたいな、
なんかそういう大学だったんですけど、
なんかその時やった授業ってこういう話とかが割とあったんですよ。
でも最初何人に役立つのかよくわかんないなみたいな感じだったんですけど、
学生の時はね。
だけど今結局やっぱ何かサービス立ち上げるにしても、
なんかやっぱ結局その会社のことのビジネスとか理解しなきゃいけなくて、
ってなるとやっぱりやってることはこういうビジネスハナリストみたいなことっていうのは、
なんか捉え直すとやってるなみたいなのがあったりするから。
kudakurage
そうですね。
Takaya Deguchi
やっぱどこかで誰かをやってそうですね。
kudakurage
でぐちくんとかはよく、よくというか最近だと、
最近だけじゃなくてもうここ数年かもしれないですけど、
ある程度いろんな人を取りまとめて、
なんかこうプロジェクト進めるとかプロジェクト作っていくみたいなこともやってると思うから結構。
かなり近い立ち位置ではあるかなっていう気はしますよね。
Takaya Deguchi
そうですね。
なんか直近もやってるなって思いながら話を聞いてましたけどね。
kudakurage
ビジネスハナリストをやってたわと思った。
Takaya Deguchi
いやーでもね、なんかビジネスハナリストやっぱ、
なんかいてくれるとやっぱいいよなっていうのは思いますね。
そういう役割とか本当にちゃんとね。
kudakurage
いやー本当そう思いますね。
Takaya Deguchi
やってるけど、なんかデザイナーなりプロジェクトマネージャー的立場でやるけど、
Takaya Deguchi
やりたいわけじゃないなみたいなのあるじゃないですか。
kudakurage
でもね、僕はそうなんですよ。どっちかっていうとね正直言うと。
だから僕とかはねよく自分たちのサービス作るとかもあるけど、
どっちかっていうとクライアントのワークをやってることが多いから、
いろんな会社さんのお手伝いする立場とすると、
やっぱその会社にそういうビジネスハナリスト的な人がいるとめちゃめちゃ楽だなって思うよね。
Takaya Deguchi
楽だよね。絶対楽だよな。
大体いないから。
kudakurage
そうそう。たまにっていうか場合によっては丸投げされたりするわけじゃないですか。
なんかいい感じにしてほしいみたいなと。
丸投げされて、じゃあ自分がなんかいろいろ調査してとかやんなきゃいけないなみたいな感じになると、
結構やっぱりね、大変。やるんだけど大変じゃないですか。やっぱり。
Takaya Deguchi
あとなんかビジネスハナリスト不在かつ、
なんていうのかな。さっきも話した組織は変えないですみたいな。
組織を変えないことを前提としてサービスを組み立てるみたいなことを要求されたとき、
特にクライアントワークだとなかなかその組織を変える部分に対してアプローチもしづらいから、
そうするとちょっといびつなサービスとかにならざれなくて、
そこがちょっと難しくなるみたいなのはあるよなって思いますね。
kudakurage
僕もっていうか、これちょっと違う話かもしれないけどさ、やっぱりなんか、
ある程度新しいプロダクトを作るっていうのを手伝いますみたいなので入ったとしてさ、
いつまでも自分がそこにいられるとは思って僕はやってないわけですよ、やっぱり。
いつかは手放ししてその会社が自立してやっていくのがいいと思っているので、
そうじゃなければ僕が入るしかないんじゃないかみたいな感じになっちゃうから、その会社に。
で、それを考えると、どっかで手放していくみたいな、
その運用に乗せていくみたいなことも考えてやっていかないとなみたいなことを考えることもあるわけだけど、
それも自分たちでやっていかなきゃいけないのか、それとも社内にその辺を考えてくれて、
吉田にやっていってくれる人がいるのかで、全然仕事の進めやすさとか楽さみたいなのは全然違うから。
Takaya Deguchi
そうね。それこそデザインシステムとか作ったとして、
それ作るのはいいんだけど、それをちゃんと浸透させる人みたいなのがどうしてもいないとダメだし、
その浸透させるところだけをスポットでは手伝えるかもしれないけど、
続けるのは社外の立場だとできないですからね。
kudakurage
そうそうそうそう。じゃあちゃんとその辺を理解してくれて、
どういうものなのかとかどういう必要性があるのかっていうのを理解した上で、
その引き続きずっと運営として運用してやっていってくれる人っていうのがいた方がやっぱりいいよね、社内に。
Takaya Deguchi
結構なんかデザインの意味、何て言ったらいいのかな。
Takaya Deguchi
ビジネスアナリストの結構この本とかもシステムをどう入れるかみたいな話だと思うんですけど、
そこをデザインに置き換えると新しい仕事ができる、生まれる気もするな、何て言ったらいいのかな。
デザインシステムもそうだけど、デザインシステムはシステムだからそんなにこの本の内容とそんなに変わらないんだけど、
何て言ったらいいのかな。例えばブランドとかをシステムをブランドに置き換えたとして、
それを例えばリブランディングしました、ブランドガイドラインとか作りました、でもそれだけじゃダメじゃないですか。
ブランドを浸透させる役割が必要になってくるじゃないですか。
そうするとそれのインストール活動をし続ける人っていうのが必要になってみたいな。
それってビジネスアナリスト的な感じだと思うんですよね。
ブランドマネージャーとかそういう呼び方なのかもしれないけど、デザイン的な文脈では。
kudakurage
もしかしたらインストールするだけじゃなくて、それを受けてここはこういうふうに変えたほうがいいかもねみたいな。
別のもうちょっと細かい流度の業務、業務改善じゃないかもしれないですけど。
細かい流度のデザインインストールみたいなのが必要になってくる可能性もあるしね。
Takaya Deguchi
そういうインストールをやる、さっきの営業だとセールスイネーブルメントみたいな、
そういうイネーブルメント業みたいなのは結構デザインでも必要とされてくるんじゃないかなとは思いますけどね。
ツールにしろ、ブランド的なものにしろ、制作プロセスとかにしろ。
kudakurage
そうですね。
単純にさっき、もしいなかったら自分でやらなきゃいけないって言ったけどさ、
とはいえなかなか社外の人間が社内の人を巻き込んでいくのって結構大変じゃないですか。
難しいですね。
結構やろうとはするけど、やっぱりなかなかうまくいかない部分もあると思うんですよね、その間的には。
Takaya Deguchi
そういう意味でもやっぱり社内にそういう人がいた方が本当はいいみたいなところはあるんじゃないかなと思いますけどね。
一見、この本の概要を見ると全然関係ない話には見えるけど、
結構デザイナーとかそういう人にとっても身近な話なんじゃないかなとは聞いてて思いましたけどね。
kudakurage
まあそうね、割とまだ見えてないけどある職業みたいなのがあるような気がするね、やっぱりすごい。
Takaya Deguchi
なんか特に事業会社だとそういう人必要とされると思うんですよ。
いやだって今はフィグマ単に入れるだけでもどう運用していいかとかたまに聞かれるんですけど、
例えば結構レイヤーがあるじゃないですか、ファイルとかプロジェクトとかチームとかワークスペースとか。
どういう領土で使ったらいいんだみたいに聞かれるんだけど、
僕もそんな別に詳しくないっていうか、そんなにそこに対してモチベーションがないから何とも言えないんだけど、
なんかそういうのうまいことデザイナーの制作フローも鑑みていい感じに設計してくれる人とかね、
あといい感じにプラグイン導入してワークフロー作ってくれる人とか、
なんかそういう人はすごい必要とされるんじゃないかなとは思いますけどね。
kudakurage
そうですね。それもね、ちゃんとベストプラクティスもあるかもしれないけど、
ちゃんとその会社というかビジネスの組織に合わせた、うまくニーズを組み取った導入の仕方とかもね、
Takaya Deguchi
ちゃんとやってくれるみたいな。
なんかね、スタートアップだったらそんな細かく権限管理しなくていいっすよとかね、スピード重視やっていきましょうとか。
kudakurage
はいはい。
Takaya Deguchi
なんかそういうのあるじゃないですか。
kudakurage
ありますね。
あと逆になんか、さっきちょっとSaaSの話があったけど、
そういうのを意識したSaaSのサービス作りみたいなのもあるのかなというふうにも見てて、読んでて思いましたけどね。
こういうビジネスアナリストみたいな人たちに使ってもらいやすいにするとか、
わかりやすいようにそういう人たちにアプローチできるようなものにしていくとか、
逆にビジネスアナリスト的な人がそんなに強い人がいなくても導入しやすいものを考えるとか。
Takaya Deguchi
なんかいろいろ思い出してきた。
SaaSを作ってた時の話を。
なんかやっぱいろいろ要望が出てくるじゃないですか、そのクライアントから。
でもそれを全部組み取ってSaaSに実装してたら、まあ人も足りないしプロジェクトがめちゃくちゃになるんで、
ここは要望を受ける。
まあ要は汎用化できる。
ここは個別すぎるから要望を受けないみたいな線引きが必要なんですけど。
あとなんかその、やっぱその、キベラの時作ってた時のもそうだったけど、
なるべく設定なしで使える状態が目指しましょうみたいな話とか。
SaaSの細かい設定がないとインストールできませんとかになってくると、
イネーブルメーターがやっぱ大変になってくるから、
なるべく設定なしで使い始められるようにしましょうみたいな。
そういう思想を大事にしてプロジェクト設計するとかも、
こういう皆さんナレーション的な考え方って必要だったなとか。
kudakurage
あとなんか思ったのは、結構トップダウンで降ってくるのって、
最近AIが来てるからAI導入しろみたいなさ、そういう漠然とした何かが、
ソリューションが降ってくるわけでさ、ソリューション提案みたいなのが。
一方で現場ではそんなものを別に必要としてない可能性もあって、
現場で欲しいのはこういうのなんだけどみたいな、
そういう溝があるわけじゃないですか、そこに。
それを埋める存在としてはビジネスアナリストがいるわけだけど、
もしかしたらそれを楽に埋める存在としてのSaaSみたいなのも、
場合によってはあるかなっていうふうに思ってて。
AI使ってるし、しかも現場のこういう問題解決できますみたいな中間的な存在を
サービスとして表現するというかね。
そういう売り出し方をするっていうのもあるかもしれないけど、
することで、これはAI導入にもなってるし、
現場が欲しいものにもちゃんとなってるみたいなことにフィットさせていくというかね。
なるほどね。
そういうやり方もあるんじゃないかなっていうふうに思ったけどね。
Takaya Deguchi
確かにね。結構そういうAIとかDXとかビッグデータみたいな、
そういうところから物事が始まるっていうのはやっぱりよくあるんだなっていうのは、
クライアントワークをやればやるほど重いようになりました。
kudakurage
でも実際そうだよね。あんまりビジネスの根底というか、
その会社のビジネスのものってあんまり変わってないことの方が多いわけじゃないですか。
これを作って売るっていうところだったりするんだけど、
ただ時代に合わせて新しい技術が生まれるとか、新しいやり方が考えられるとかによって、
それを合わせていくというかさ。
それによって企業としてかビジネスのやり方を変えていくっていうことの方が多いと思うから、
だからそういうものがITとかビッグデータみたいなものが起点となって変わっていくっていうのは、
それはそうなんじゃないかなっていう気がするけどね。
Takaya Deguchi
そういう言葉があった方が特に大きい会社だとみんなが同じ方向向きやすいんだなっていう、
そういうAIみたいな言葉があると、
ベクトルとしてAIの方向に何となく向けるみたいな効果があるんだな。
でもそれをちゃんと落とし込むには、そういうビジネスアナリスト的な人が必要なんだろうなっていうのは、
割とグラフトワークをやって身近に感じるようになりましたね。
kudakurage
そうですね。
でもなんか、もともとの発端というか、この本を読む発端と思った池田さんの話に返ってくると、
もともとだから池田さんが相手にしてたそっちのクライアントの社内の人がこのプロセスビジョナリティ本に感銘を受けて、
いろいろとそういうそれっぽい立ち位置のことをやろうとしているみたいな話が確かあったような気がしたんだけど、
でもそういう視点で考えたことはあんま僕はなかったなと思って、やっぱりそれまで。
ある程度ちゃんと良いもの、ユーザーにとって良いものを作ろうみたいなのは考えたりするけど、
例えば社内の関係者の意見をきちんと聞いて、それを取りまとめて、それを要求に落とし込んで、
仕様に落とし込んで、それを実際にエンジニアなりデザイナーなりに仕様を説明して、
それを組んでみたいなことを考えるというか、もうちょっと全体最適化みたいな、
そういう視点みたいなものっていうのはある程度あったかもしれないけど、
かなり広い視点で見るっていう意味では全然多分なかったんだろうなと思っていて、
なんか結構新しいタイプな気はしたんだよね、そういう意味でも。
Takaya Deguchi
そうですね。
kudakurage
プロダクトを、一プロダクトを作っていくっていうふうに見ても。
でもやっぱりプロダクトマネージャーとかはそういう視点なのかもしれないけど。
Takaya Deguchi
あとは多分、池田さんが言ってたクライアントも多分SaaSの会社だったと思うから、
結構SaaSはやっぱりユーザーとの距離が遠いんですよ、デザイナーとかプロダクトマネージャーからしてみると。
営業とかCSとかを挟まないとクライアントにはアクセスできなかったりするから。
そうすると、ユーザーのことに関してはデザイナーよりも営業とかCSの方が詳しいっていうのはあるあるだから、
そうするとやっぱり社内の取りまとめみたいなのがより大事になるっていうのはあると思うんですよね。
kudakurage
確かにね。
Takaya Deguchi
そこがB2Cとの大きな違いかなとは思いますね。
kudakurage
確かに。
それはそうかもしれないですね。
B2B、そうか。
B2Bサービスにも結構こういう人材を求められるっていうことなのかな。
Takaya Deguchi
B2Bの中でも特にこうエンタープライズ寄りっていうか会計システムとかなんかそういうノーションスラックとかね、
そういうのは割とB2C寄りだけど。
kudakurage
確かに、そうかもしれないですね。
Takaya Deguchi
だからなんか冒頭も話したけど、最近はSaaSだとPMMっていうプロダクトマーケティングマネージャーっていう役割を明示的に置くっていう会社が何となく増えてる感じはしますね。
プロダクトマネージャーと分けて。
そこも含めてプロダクトマネージャーがやりましょうっていうのはなかなかしんどいんですよね。
なんか責任が大きすぎて、カバー範囲が広すぎて。
kudakurage
なんかでもそういう意味ではこのビジネスアナリストは割とその両方を見る。
まあマネジメントはしないかもしれないけど両方を見てこういろいろやっていくっていう立場の人っぽい感じなんですけど。
どっちがいいとかあるんですかね。
そういうビジネス側とデジタルソリューション側を分けて管理するって方がいいのか。
ある程度階層で見るというかさ。
プロダクトマネージャーは多分もっと全体を見る存在だと思うんですね。
それよりももうちょっとコアな部分というかさ。
その辺だけを見る。
ビジネス側もデジタルソリューション側もみたいな。
人っていうビジネスアナリストみたいな風な分け方。
プロダクトマネージャーとビジネスアナリストみたいな分け方。
どっちがいいとかっていうのはあるんですかね。
Takaya Deguchi
どうなんですかね。
横に分けるか縦に分けるかみたいな話。
ビジネスとプロダクトで横に水平に分けるのか。
kudakurage
意思決定者とアナリストっていう感じで縦に分けるのかみたいな。
そういうことですよね。
Takaya Deguchi
どっちがいいんだろうね。
kudakurage
時代的にはやっぱり横断できる能力を持った方がいいっていう感じなんだろうと思いますけどね。
もちろん敷居は上がっていくんだろうと思いますけど。
Takaya Deguchi
だいぶ敷居は上がると思う。
kudakurage
そうですよね。
Takaya Deguchi
プロダクトのことも分かって、ビジネスのこともすべて理解しているって。
それ社長じゃんみたいな。
社長ですらそこを全部分かってる人いないと思うけど。
kudakurage
でもやっぱり結構ビジネスアナリストになっている人たちって、
やっぱりもともと何かの専門職というか、エンジニアだったりとか、
そういう専門職だけど、やんなきゃいけないみたいになっていって、
結構横断的なスキルを持っていって、ビジネスアナリスト的な立場になっているっていう人も結構多いらしいんですよね。
そういう意味では、そっちのほうがいいんだけど、敷居は高いって感じなんでしょうね、きっと。
それができる人がいわゆるCPOとかになっていくんでしょうね。
Takaya Deguchi
ビジネスアナリスト増えてほしいな、確かに。
こういうところに苦労したわっていうのをいろいろ思い出しました。
kudakurage
前の会社とかで。
でもね、そういう人材は求められてるってことですね。
Takaya Deguchi
求められてると思います。
kudakurage
求められてるね、求められてると思うわ。
求められてるし、いてくれるとデザインがすごくしやすくなると思いますね。
デザイナーもエンジニアも多分みんな楽だもん、それは。
だからそういう職種が確立されて、ちゃんと評価されるっていうことが大事なんでしょうね。
アメリカとかの例だと、そういう人たちがめちゃくちゃ評価されるというか、
すごい大事な職業として扱われてて、普通に求人とかにも出てくらい、
日本でいうプロダクトマネージャーぐらい立派な職業というか、メジャーな職業になってるわけだから。
日本も多分そういうふうになっていると、本当はいいんだろうなっていうようなところですよね、きっと。
っていう本でしたね。
面白かったです。
結構何回も言ってるけど、出口君の働き方というか働いてることにはすごく合ってる気がしたんで、
ぜひ読んで、また軽くでもいいんで感想聞かせてみてください。
Takaya Deguchi
そうですね。読んでみます。積んでるんで。
kudakurage
では、そんなところですかね。
リサイズ編のご質問やご感想、リクエストなどは、Xにポストしていただくか、
書本にあるお便りのリンクから送っていただければ、配信内で取り上げたりしますので、どしどしいただければと思います。
リサイズ編は毎週金曜日に配信しています。
Spotify、Apple Podcast、YouTubeなどで配信していますので、よかったらチェックしてみてください。
ということで、今回はここまで。また次回お会いしましょう。さよなら。
Takaya Deguchi
さよなら。