いろはまるのブログ

ローコード、市民開発、RPA、雑談など気ままにつぶやくブログです

失敗をエンタメ化したい

「失敗」という言葉はネガティブな印象があるけど、その「失敗」をエンタメ化したいという思いがここ最近強くなってきている。

 

RPA界隈の技術記事をネットで見てても、成功パターンはいっぱい公開されるが失敗パターンは積極的に公開されていないように見える。

失敗したことばっかり書いてたら自分のキャリアに傷がつくんじゃないかとか、取り返しがつかないことになるんじゃないかとか、そういう漠然とした不安があったり、

周りの人の記事に影響されて、しっかり調べて確実に正解が見つかるまではうかつに記事にできない!という強迫観念?みたいなものに縛られていたり。

 

そもそも「失敗」=トライなので、どんどん表に出して、自分は前に進んでいるということを前面アッピールすべきだと思う。経験したことがある人多いと思うけど、成功体験よりも失敗こそが後に役に立つ。何度も失敗してて記憶に刷り込まれているから、思い出すのも早いのだ。

成功体験は周りから見て分かりやすいけど、失敗体験をどれだけしているかなんて周りの人は分からない。失敗を隠そうとする人すらいる。成功を裏付けるのは失敗経験だ。

失敗経験の多さこそ、その人のポテンシャルを測る最も信用できる指標である。

 

で、この「失敗をエンタメ化する」というテーマ。

これをいろいろと応用して面白い事業ができないかなーと日々考えている。事業というほどでもなく、例えばブログで「いっぱい失敗してみた」系の記事を書いてみるとか、

オフラインイベントでみんなで一つの課題を試行錯誤してやってみる。その様子をドキュメンタリー風にエンタメ化してみる、とか。とにかく「失敗」を笑い飛ばせるような企画をバンバン出す。

 

もっと失敗に寛容な社会になって、年齢関係なくチャレンジしようと思える人を増やしたいなーという思いがある。

自分の娘を見てても思うことだが、学生の頃から将来〇〇になる!と決めるのは素晴らしいことなんだけど、一方で学生の頃に知った知識で将来を決めるのはどうなんだろう?社会に出てから分かったことで都度方向転換してもよくない?とも思ったりする。

柔軟に方向転換できる社会の方が健全だと思うのだ。そのために「失敗をエンタメ化する」事業を起こすのは悪いことじゃないと思うし、社会をもっと元気にできると思ってる。

 

ちょうど日経平均も史上最高値になって、また活気が出そうな雰囲気になってきたので、便乗して僕も頑張ろうかなーと思った。

 

よし、グアムで着る水着でも買いに行くか。(雪降りそうだけど)

終わると分かってて始まった仕事

自分の特徴を、良い悪い関係なくいかにも特殊技能であるかのように第三者目線で説明してみる。

この作業、意外と楽しいのでおススメしたい。就活や転職のときの自己分析にもおススメ☆

 

・運転士

車の運転が好きである。車種はどうやら関係ないらしい。軽トラでも外車でもとにかくタイヤとエンジンとハンドルがついていれば何でも良い。ただ、人がたくさん乗れるに越したことはないらしい。

おそらく、守られている空間にいながら景色が変わっていくことが楽しいのだと思われる。昔は東京-名古屋間を平気で車で移動しようとし、移動時間中に妻と子がどれだけ暇になるか考えていなかったのだが、最近は時間重視になり、おとなしく新幹線や飛行機を活用することを覚えた。

 

・人口当て士

日本全国の主要都市(各都道府県Top3くらいまで)のおおよその人口を当てられる。学生の頃に地図帳が好きで、最後のページあたりにあった人口表を見ていたらいつの間にかこうなったらしい。

 

・スポ士

自宅のディスポーザーがぶっ壊れて水が流れなくなったときに一時的にあの"スッポン"を使ってた時についた異名。やるたびに作業効率が上がっていき、最終的にはスッポンを持って念じるだけで水が流れるようになったという。ディスポーザーの修理までの間の、まさに"終わると分かってて始まった仕事"である。

 

・オム士

娘のおむつを高速交換できる特殊技能。サイドギャザーを立たせる速さは異次元で、常人が肉眼でとらえるのは至難の業だ。

 

・ねむ士

ふとんに入って3分以内に眠れる。

 

・謝罪士

家庭内では謝れば何でも解決すると思っている。

 

・缶士

車の中にコーヒーの空き缶を溜められる特殊技能。だいたいパーキングエリアかイオンモールで捨てる。まとめて捨てると品がないと思い、2個ずつくらいに小分けにして捨てるように心がけている。コンビニで捨てるときは必ず何かを買う。

 

モーニングショット

自販機で迷ったらとりあえずモーニングショットを買っておく。

 

・服士

意外と服が好き。最近は素材を気にするようだが、レーヨンが入っていたら大概買っている。ポリ100%とかアクリルは避けているらしい。

 

・なるほど士

なんでも「なるほど~」と言って一旦飲み込んでみる。たぶん口癖。仕事上、何かと便利らしい。

 

技術士

飯を食うためにやっているらしい。できれば毎日祭りでも開いてドンチャカしてたい。

 

どこでも通用するスキル

あぁ、10年以上前の自分と重なるなぁ。。。と

qiita.com

 

「どこでも通用するスキル」って何だろう?どこまでそのスキルを伸ばしたらいいんだろう?っていう漠然とした不安は常にずっと持っていたような気がする。

 

ITエンジニアの世界で言えば、学生の時みたいに偏差値のような基準があれば良いのかというとそうではなく、知っててもモノを作れなきゃ意味がないわけで。。。

知識があるのは前提で、その知識を道具としてうまく活かせる人(たぶんこれが俗に言う"実務経験"と言われている?)にニーズが集まる。

 

案件参画のための面談を経験して思うのは、面談の場では知識や経験を問うことはできても、道具をうまく活かせるかどうかを判断するのはとても難しいということだ。

例えば料理できるスキルを求められている現場で、この人はめっちゃ包丁について詳しいなぁ。。。よし、採用しよう!…で採用した人が実は全然料理できませんでした

といったケースがたくさん起こっている。

これは包丁の知識で採用してしまった会社がそもそもの問題なのだが、かといって料理できるスキルをどうやって判断するのか。しかも短時間で。

 

よく使われるのはGitHubにアップされている成果物(ほとんど残骸だったりするんだけど)を見てコーディング力を判断したりする。けど、モノを作ることには興味がない人もいるわけで…。実際そういう人が9割9分だと思う。

どこかのレシピ本に載ってた料理をそのまま流用してたりもするしw まぁ工夫した点とかをヒアリングすれば暴けるかもしれないけど。。。

 

あれ、いつの間にか採用する側の話にすり替わってしまったw

いかにも夜中に書いてる記事っぽいw

何が言いたいのかよく分からなくなってしまったが、基本情報を取ったからと言ってそれを知識アピールとして使うには物足りない風潮はあるので、"実務経験"重視になってしまっているものの、どこまでその"実務経験"を求められているのか、経験すればいいのかは相手によるなぁ、、、難しいなぁと常々思っている。

「おすすめのDXツールありますか?」

「おすすめのDXツールありますか?」

 

と聞かれ、一瞬絶句した。RPAに関わる仕事をしている人ならこの質問に免疫がついているかもしれない。当たり前のことだが、"何をしたいのか"が明確でなければツールをおすすめすることはできない。

 

こういう問いをすること自体は悪いことだとは思わなくなった。というより仕方ないんだろうなぁ、と。

なぜこういう質問が出てしまうのか10秒ほど考えてみたけど、たぶん課題が多すぎて頭が整理できていないんじゃないか、と。僕も同じ状況ならきっとパニックになるので「じゃあ整理したらいいじゃん」とは強くは言えない。

 

壁打ち相手を求めているのだ。別に壁打ち相手はDXのプロじゃなくてもいいんだと思う。自分の思っていることを誰かに吐き出すことで頭が整理できる、なんてことは普通にあるわけで、その作業を行うフェーズだと思えばいいだけなのだ。

 

だから、「おすすめの~」の質問が来たときは相手に溜まっている不満、意見、愚痴をたんまり吐き出してもらうことを狙いとした会話をする。ヒアリングというかカウンセリングに近い。繰り返すがこの作業を行うのに特段特別なスキルがいるかというと、そんなことはないと思ってる。

意識するのは洗い出しと優先度。優先度を決める軸としては業務の重要性だけでなく、その業務に関わる人たちの熱量もしっかり考えること。特に1発目の自動化案件としてはその"効果を知ってもらうこと"が大事だと思ってる。業務担当者の熱量が高ければ高いほど感動も大きくなる、というわけ。そうなれば雪だるま式に熱量が上がっていく。

 

全社的にインパクトのあるような重要な業務を選定するのも悪くはないが、誰も自分ごととして考えにくく、"確かに大事な業務だよなぁ~自分はよく分かんないけど…"という思考になりがち。重要な仕事をしているはずなのにイマイチ気持ちが乗ってこない。熱量はバカにできない大事な指標の一つだと僕は思う。

 

ちょっと話がそれたが、「おすすめのDXツールありますか?」と聞く時点で業務自動化に対する熱量は果たして高いのかどうか、ちょっと怪しい。

上が突っついてくるから仕方なくやらないといけない、みたいな。

どんな仕事も同じだと思うけど、気持ちが入らないと何事もうまくいかない。理屈で何もかもうまくいくわけではないのがこの仕事の難しいところでもあり面白いところでもあるのだと思う。

 

 

誇り

なんか何も考えず見入っちゃったなぁ。。。

 

youtu.be

 

やっぱ自分の仕事に誇りを持っている人はカッコいい。

誇りを持てるくらい1つのことに莫大な時間を投資して、自信を作り上げている。

したがって、誇りを持つためには腹をくくって投資し、とっとと自信を手に入れてしまうこと。

 

問題は「やりがい」だ。

この動画の店主さんは、自分の作った料理を食べて「おいしい」という前に笑顔になってくれる。それが嬉しいから続けている。そんなことを言ってた(別の動画だったらごめんなさい)

何が自分にとって嬉しいのか。原動力になるのか。

 

自分が情熱大陸に出演したとして、視聴者にどんな話をするのか。なぜこの仕事を続けているのか?

そんなことを妄想すれば道が開けるかもしれない。。。

妄想だけで人生終わっちゃいそうだけどw

【RPA】UiPath vs Blue Prism

※RPAを知らない人にはあまり面白くない記事なので読み飛ばしてもらった方がいいかもです。

 

今となっては様々なRPAツールが出回っているが、数年前は5大RPAツールと呼ばれるシェア率の高いツール群がRPA業界を牽引していた。

 

その中でも僕がよく使っていたものとして、UiPathとBlue Prismというツールがある。

仕事上、Blue Prismを使う機会が多かったが、最近になってUiPathのPoC支援などのお仕事もいただく機会が増えてきた。

UiPathはもう3~4年ぶりに触るツールなので、かすかな記憶を頼りに機能を思い出していこうと思ったが、あまりの変貌ぶりに、これはちょっと腰を据えてやらないとまずいなーと。。。

 

一昔前はツール同士の比較記事が公開されれば必ずといっていいほど炎上していたが、もう今は誰も気にしないだろう。ということで割とがっつりUiPath触ってみたので比較記事を…と思ったが、骨が折れるw

僕の感想だけ書こうと思う。

 

一言で言うなら、手数のUiPath、男気一本のBlue Prismといったところだろうか。(全然意味が分からない)

 

前述したように、UiPathはRPAだけに留まらず、Automation Cloudの中で、RPAロボットの統合管理を担うOchestrator、ローコードツールであるApps、データストレージサービスのData Service、業務プロセスの文書化やプロセス化を支援するTask Capture、サードパーティーアプリケーションとの連携を行うコンポーネント群を提供するIntegration Serviceなどなど、業務効率化をいろんな形で支援する機能が揃っている。完成度にバラつきはあるものの、ユーザーにいろんな可能性を提示してくれる点では素晴らしいと思う。RPAにこだわらず、"業務効率化"を支援するという目的とニーズに沿ってあれこれトライしているのがとても好印象。

 

Automation CloudやOchestrator、Appsなどのアクセス権の設定は操作に慣れは必要なものの、結構細かいところまで設定が可能である。Data Serviceのフィールドごとにアクセス権が設定できるのは正直驚いた。管理者以外の人がAutomation Cloudを触ることを考慮し、いろいろと配慮しているのが感じられた。機能として仕上げるのはかなり苦労したと思う。。。

Appsはこれからに期待といった感じ。今の完成度で十分アプリは作れるけど、コードに頼らざるを得ない場面がちょっと多いかなぁ…という印象がある。エンジニアでない人が作る前提であれば辛うじて扱える、かも。他にもまだ改善の余地はありそうなのでブラッシュアップしていってもらって、ゆくゆくはkintoneに並ぶ完成度になればもっとシェアが広がるのかな、と。。。

 

対するBlue Prismは男気一本。手数よりもRPAそのものに特化している感じ。

"RPAを卒業する"と謳っているが、堅実に細かい改修を重ねている。個人的にはこの方針でいいと思ってる。僕は2019年頃のv6.5あたりから触り始めているのだが、それから5年ほど経った今でも基本のアーキテクチャは変わっておらず、UI自体も劇的に変わっているわけではないので、メジャーバージョンアップしても使い勝手はそれほど変わらない。変わらないのだが、確実にユーザーの声を聞き、必要とされる機能をきちんと絞って改良している印象がある。

 

いや、意見や要望がないわけではないよ?

UiPathやAutomation Anywhereでは当たり前に実装されている"トリガー"はほしい。Blue Prismはロボットの同時実行数=ライセンスコストとなるため、ライセンス消費率を下げるような機能を作ってしまうとカニバるのであえて作っていないのかも、と勘繰ったり。。。

最近はnoteの記事のおかげでだいぶ改善されてきてると思うけど、日本語ドキュメントをさらに充実させてほしい。(note記事の中の人、お世話になっております。とても丁寧で分かりやすい記事です。これからも頑張って執筆お願いします)

あと、Chorusは果たして必要なのか?…などなど。

ただ、堅実に昔からある機能をブラッシュアップしてきているのはとても好印象なので、多くは求めない。これからもユーザーの声に耳を傾けていってほしいなーと思ってます。

 

というわけで、例えるなら

UiPathは多彩な光線技でバリアしたり絞めあげたり切り刻んだりして攻めるウルトラマンエースで、Blue Prismは足技一本で果敢に攻めるウルトラマンレオみたいな。

UiPathは変化球の魔術師・ダルビッシュで、Blue Prismは直球とカーブでゴリ押す江川みたいな。

そんな感じです。

僕はDX人材を諦めた

たまにはRPA関係のお話でも←

 

logmi.jp

 

面白い記事だった。

業務改善とかDX推進を担う人材の適性って何だろう?…と思って必要なスキルを洗い出してマッチした人材を選びがちなんだけど、

本人のやる気とか、人から助けてもらいやすい性格だったりとか、結局本人のヒューマンスキルによるところがかなり大きいなーと思ってる。

 

もちろん一人の力では何もできないわけで、たくさんの人の協力を得られるかどうかがカギとなる仕事。人を巻き込む力があるかどうか。困ったときにすぐに人に助けを求められるか。助けてもらえる人徳?があるか。

DXに役立ちそうな資格を取ったとか、業務改善の本をがっつり読んだとか、コンサルファーム出身とか、そんなことよりも(それはそれで役に立つけど)社内で培った人間関係や本人の性格に依存するという事例を今まで幾度と見てきた。

DX人材に必要なのは人から助けてもらえる人であること。まずはこれである。

孤立しがちな学級委員タイプだった人は向いていない。

 

僕のクライアントで、RPAの主担当者で人の力を借りるのがうまい人がいる。

その人はもう50歳を超えるベテラン社員なのだが、ベテラン社員がDX人材として活躍する事例は多い。会社の歴史を知っており、社内システムに精通し、人脈もある。部署またぎの連携もフットワーク軽く実行できる。

歴史を知っているのは意外と重要で、例えば社内システムが乱立してしまった経緯、社内システムの担当ベンダーとの関係などを把握していることで、むやみやたらな策を打って社員の反感を買わずにすむ。ちゃんとした背景、経緯、状況を理解して有効な策を考えるのが肝要だ。

 

僕もうまく人に頼って、頼られる人になりたいなーと思いながら、技術顧問の仕事を受けている。正直技術なんて勉強すれば誰でも身につくけど、ヒューマンスキルはその人の生きてきた環境がものをいうわけで、一朝一夕に身につくものではないと思ってる。

 

僕は優秀なDX人材には到底なれそうにない。

僕はあまりにも独りよがりな人生を歩みすぎた。もっと人にうまく頼れる人になれていれば…。

小中までは学年で成績はそこそこ勉強はできていたのに高校以降で叩きのめされ、それでも小中の頃の得体の知れないプライドだけが残り、余計な見栄を張り、負けず嫌いな性格のままズルズルと生きている。自業自得だし、客観的に自分を見て絶対友達になりたくないw 

仲間に頼らない。頼れない。RPA関係の仕事を始めてから自分の性格と向き合う機会が増えたことには素直に感謝したい。RPAは僕自身が変わるきっかけになるかもしれない。

 

今は、エンジニアがちょっとだけDXに足突っ込んでるだけというポジションでご飯を食べてきている。楽だけどエキサイティングはしないw

コロナ禍ではこれで良かったけど、そろそろ画面相手ではなく、"人"と熱い仕事がしたい。

自分自身が変わっていかなければ。