ハタケ(システムエンジニア→ITコンサル)の日常とナレッジ展開ブログ

娯楽やお役立ち情報、人生で学んできた事やIT系(RPAメイン)の知識情報を気まぐれで発信していきます。twitter→@RPA_AI_it

人生で買ってよかったものを購入の決め手や判断ポイントとともに紹介【昭和60年代生まれの男性】

この記事では昭和60年代生まれの男性がこれまでの人生で購入したもので、購入して本当に良かったものをそれぞれどのような判断で購入し、何が決めてだったのかについて紹介していきたいと思います。家具や掃除用品、洋服、PC用品等幅広いジャンルを紹介していきますので、皆様がものを買う際の参考にして頂ければと思います。

 

 

簡単な自己紹介及び自分のものを買う時の思考の紹介

私は昭和60年代生まれの男性で学生の頃はスポーツに熱中し、新社会人からIT系の企業(SIer)に就職し、10年程経過後に現在はITコンサルタントになるべく転職をしてから勉強勉強の日々を送っています。30歳くらいで結婚して新築戸建てを購入して生活をしています。(学生時代や20代の頃に勉強していなかった部分を取り返すのにかなり苦労中)

 

私は物心付いた頃から節約志向でした。高校の頃は水分にお金を払うなんてもったいないと水道水で我慢したり、新社会人になって一人暮らししてからはお風呂にペットボトルを沢山いれて水かさを増したり、エアコンをいかに付けないようにしていたり、、そんな私でも徐々に高いものも買う経験をするにつれて、自分の中でのお金の使い方や高いお金を払うべき価値観が徐々に確立されていきました。

 

現在私がものを買う時の思考を整理してみると下記のようになりました。金額によって、検討や調べるのに掛ける時間が変わりますが、現在は1万円近くになってくると良く考えてから買っているかなと思います。1万円以下のものは買う判断基準が大体明確になっており、時間を掛けずに買うか買わないかを判断しています。

 

<図1:購入に至るまでのプロセスを外部/内部の視点で分けたもの>


<図2:モノやサービスの金額によって変わる視点>

 

 

図1の※1 現在の買い物の価値観を簡単に書くと下記の通りです。

 

普段の食品関連:できるだけ安く買うが美味しくないもの、身体に悪すぎるものは出来るだけ買わないようにする。お菓子は安いものを大量ではなく、多少高くても美味しいものを少量買います。少量でも美味しい方が感じられる幸福度が高いと感じるためです。

 

洋服:30歳までに流行に流されないような長く着れる洋服が揃っているので、Tシャツや消耗品で良いものをアウトレットやセールに行って買います。買う時はデザインや素材をチェックして、長く着れる質の良い物かを確認します。良く購入するブランドは「ABAHOUSE」「NOLLEY'S」「D/him」です。

 

インテリアや家具、家電:家を購入後に欲しいと思っていたものは徐々に揃えて現在は大体揃っていますが、まだ欲しいものは存在しており、高くても良いと感じるものを買います。高額なものが多いため、欲しいものリストで管理をして資金に余力ができたものから購入しています。在宅ワークに使用するものは関わる時間も多いため、椅子等には予算は高めに設定しています。家具は「かねたや家具店」のものがどうやら好みみたいです。

 

居酒屋:コスパ重視。安くて美味しいものに出会う事に幸せを感じます。鳥貴族LOVE。

 

お酒:日常的に飲まないため、買うものは少し高くても良いものを買います。最近は日本酒が一番好きで近所の酒屋で珍しいものを購入するのが多いです。

 

図1の※2 外部情報の信頼性判断に関しては、製造元の企業の信頼性は不良品等のサポートは問題ないかや知名度を確認します。友人やインターネット上の記事、SNSに対して発信者の情報については、情報を発信している人が本当にその商品の事を良いと思って発信しているのか、アフェリエイト等が主目的で発信しているのかを見極めます。また、発信されている良かった点は自分にも当てはまるものかを考えて判断しています。Amazonの口コミ情報はサクラチェッカーというサイトを結構信頼しており、重要な判断ポイントになっています。

 

sakura-checker.jp

 

 

前置きが長くなってしまいましたが、上記のような価値観を持つ人が、これまで買ってきたもので「これは買ってよかった!」といえるものをどのような判断で何が決めてで買ったのか、使ってみての感想を各商品に対して下記の項目別で説明していきます。商品やサービスについて、高額なものが自分にとって必ずしも良いものとは限らないのが、ものを買う時に大事な視点だと思います。高い商品も長持ちするものであれば、安い商品を何度も買い替えるよりもトータル的に安くなるものもあると思います。良いものを見分けるには、一度良いものを実際に見たり触れたり感じたりする経験も必要だと感じます。

 

Amazonでモノを買う時は「Keepa」等で価格推移を確認し、安いタイミングがあれば安い時に買った方が安く欲しいものを手に入れる事ができます。

 

 

<各商品の説明項目>

〇購入時期(※3):

〇どこでその商品やサービスを知ったか:

〇購入時の判断ポイント:

〇購入の決め手:

〇使ってみての感想:

 

※3 消耗品は複数回数買っていますが、その場合は初めて購入している時期になります。

【家具】

屋外用テーブル:IKEA  ÄPPLARÖ エップラロー

〇購入時期:2022年

〇どこでその商品やサービスを知ったか:屋外用テーブルを探して、インターネットや実店舗を色々探し回って発見。

〇購入時の判断ポイント:「大人数(6人程)にも対応可」「人が少ない時は場所をなるべく取らない」「椅子含めて予算は5万円以内」「不良品だった場合の対応がしっかりしていそうな事」「弱い台風の風でも動かない」

〇購入の決め手:価格が安い事と折りたたむ事が出来て場所を取らないようにできる点です。色々探し回ってこれ以上のものが見つからなかったので決断しました。他に欲しいデザインのものがありましたが、折りたためず常時場所を結構取るのでそちらの商品は候補から外しました。

〇使ってみての感想:折りたたんでいる時に風邪でバタンタンとうるさいのではないかという懸念もありましたが、その懸念も起きず屋外で食事や休憩する際にとても役立っています。購入してすぐにニスを塗ったところ、水や汚れもはじくし、ツヤがカッコよくお洒落になりました。初期購入時に塗装はされているようですが、追加で塗装して置いてよかったと感じます。今後も2年に一回はニスを塗って長持ちさせたいなと考えています。外に置く木材は塗装かなり重要です。塗装しないとすぐヒビが入ったり表面がボロボロになったりします。他の木材で塗装の重要性を認識しました。家の塗装もケチらずにちゃんとやろうと思います。

 

www.ikea.com

 

 

アウトドアチェア:XGEAR アウトドア チェア リクライニングチェア キャンプ ポータブルチェア カーキ

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:庭でくつろげる椅子を探して、Amazonのサイトで発見。

〇購入時の判断ポイント:「リクライニングができる」「キャンプ時にも使えそうで、折りたたんで持ち運びする事ができる」「予算は1万円程度」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:作りも丈夫そうな見た目をしており、長く使えると判断して決断。

〇使ってみての感想:足を乗っける場所も広く作られているのと、枕も存在していてリラックスして寝る事ができます。太陽が出ている時に庭でこの椅子でリクライニングして過ごす事で素敵な時間を過ごす事ができるようになりました。

 

 

カウンター下収納:[山善] カウンター下収納 薄型 奥行20 突っ張り 棚板可動式 こぼれ止め付き天板 幅90×高さ95-110cm キッチンカウンター 棚 ラック 組立品 ホワイト

〇購入時期:2022年

〇どこでその商品やサービスを知ったか:カウンター下収納がずっと欲しくて合計10時間以上検索し続けてAmazonのサイトで発見。

〇購入時の判断ポイント:「奥行が20cm程度(カウンター下に収まりがよいもの)」「埃が入り難いように扉付きがある」「予算2~3万円」「地震が来ても倒れない設計」「白に近い色でテーブルと合う風合いである事」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:長い時間を掛けて検索していたので、この商品の写真を見た瞬間に、今のダイニングテーブルとカウンターに合う商品はこれしかない!と決めました。決めた時に在庫切れの状態でいつ入荷するか分かりませんでしたが、他に欲しいと思うものが見つからないので、入荷を待っていると2か月後に購入する事ができました。

〇使ってみての感想:ダイニングテーブルとセットで売っているのではないかと思うくらい部屋にマッチしており、テーブルに置いていたティッシュ箱や小物もしまう事が来てテーブルの上をスッキリさせる事ができました。

 

 

戸建てのバリケード1:チェーンスタンド ホワイト 3本セット プラスチックチェーンホワイト5m付

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:家の駐車場と道路に仕切りがなく、たまに駐車場で休憩するような不法侵入者のような人がいたので、それを解決させるためのものを検索して、Amazonのサイトで発見。

〇購入時の判断ポイント:「自分の家の敷地と道路との境界を作れる事」「台風でも飛んでいかないようなもの」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:近所に同じものを使っている家があり、実物を確認できたことにより迷いなく購入。

〇使ってみての感想:中には砂を別で買って利用していますが、これを配置してから駐車場に侵入してくるような人はいなくなりました。車も敷地内に入ってくる事が無くなり、家に車がぶつかってしまう時が来るのではないかという不安も軽減する事ができました。台風が何回か来ましたが、移動する事は今のところ起きていません。

 

 

戸建てのバリケード2:WORTH GARDEN ガーデンエッジ 高さ30cmx幅120cm (ホワイト)

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:家の郵便ポストと道路に仕切りがなく、郵便ポストの下に犬のおしっこや糞がされる事があり、それをされないように何かできないかと考えて、まずは仕切りを作ってみるのを試そうと検索して、Amazonのサイトで発見。

〇購入時の判断ポイント:「予算5000円以内」「郵便物が取れなくならないような高さの仕切り」「郵便ポストの前にあっても違和感のない色」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:価格が1500円程度だったので、ダメ元でとりあえず購入。

〇使ってみての感想:これを配置してから犬のおしっこや糞を郵便ポスト前にされることはかなり減りました(ほぼゼロです)。 少ない金額で問題を解決する事ができて、とても感謝しています。

 

サイドテーブル:Kuai 折りたたみ サイドテーブル CJ72165 幅53cm×高さ69.2cm×奥行き36cm

〇購入時期:2016年

〇どこでその商品やサービスを知ったか:テーブルのスペースが足りない時に手軽に拡張できるものがないかAmazonのサイトで発見。

〇購入時の判断ポイント:「折りたたんでしまえる」「設置するのが簡単」「予算5000円以内」

〇購入の決め手:上の台の部分をものを乗せながら移動させる事もできる点と色がお洒落だったので購入。

〇使ってみての感想:食べ物や飲み物を2階に持っていくときや、テーブルだけのスペースで足りない時にとても活躍しています。購入してから5年以上経過していますが、まだ全然使えています。

 

【雑貨】

 

ライト:LUCHE ルーチェ 栽培ライト GROW LIGHT

〇購入時期:2022年

〇どこでその商品やサービスを知ったか:観葉植物にこだわりを持っている友人の家に行った時に見つけて一目ぼれしたした商品。

〇購入時の判断ポイント:「お洒落!」「光が落ち着くような光」

〇購入の決め手:お洒落!

〇使ってみての感想:リビングの端っこで苔テラリウムを飾ってあるのですが、そこには日光が当たらないので、日光の代わりにこの栽培ライトを使っています。お酒を置いてある所にも近くて、BARの様な雰囲気を作ってくれていてとても気に入っています。

 

ランタン:キャプテンスタッグ(CAPTAIN STAG) キャンプ LEDライト ランタン アンティーク 暖色 ハンマートン UK-4016 / UK-4017 / UK-4018

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:ランタンが欲しくてAmazonのサイトで発見。

〇購入時の判断ポイント:「火ではないこと(火事が怖いため)」「予算5000円以内」「アンティーク風でお洒落」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:お洒落でAmazonのセール中に買うと安かったため。

〇使ってみての感想:基本テレビ台の棚の所に飾っていますが、リビングのお洒落度を高めてくれていると感じます。

 

トイレの置物:southanshop】 マリンテイスト 地中海風 船舵 インテリア おしゃれな 雑貨 装飾 内装 外装に (マリンブルー)

〇購入時期:2018年

〇どこでその商品やサービスを知ったか:トイレ内を海の家のような雰囲気にしたくて、Amazonのサイトで発見。

〇購入時の判断ポイント:「予算2000円以内」「海の家っぽい雰囲気を出せる」

〇購入の決め手:見た目が可愛くて価格が安いので、迷わず購入。

〇使ってみての感想:海の家っぽい雰囲気を出す事ができ、満足しています。近くに貝殻も置いてより海の家っぽさを出しています。トイレに行くといつも見て癒されています。

 

蚊取り線香入れ:萬古焼 ミニ 蚊取り線香 豚 蚊遣り器 イラボ 蚊取り線香入れ ホルダー スタンド 黄色 高さ11cm 日本製 08852

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:夏っぽい雰囲気を増してくれる香取線香の入れものを探して、Amazonのサイトで発見。

〇購入時の判断ポイント:「予算3000円以内」「見ているだけで夏っぽさを増してくれる見た目」

〇購入の決め手:可愛くて趣を感じたため

〇使ってみての感想:夏にこの蚊取り線香入れを外に置いておくだけでも、夏っぽさを感じる事ができました。香取線香入れとしても活躍しています。

 

 

【家電】

ハンディクリーナー:アイリスオーヤマ ハンディクリーナー 掃除機 コードレス 車用 パワフル 吸引 コンパクト

〇購入時期:2022年

〇どこでその商品やサービスを知ったか:ハンディクリーナーが欲しくて、検索してAmazonのサイトで発見。

〇購入時の判断ポイント:「見た目がカッコいい事」「予算10,000円以内」「メンテナンスが楽」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:見た目がカッコいい。シ〇ークの コードレス掃除機が予算関係なければ欲しかったが、それに見た目が似ていた点。

〇使ってみての感想:見た目もカッコよく普段見える所に置いておいても、嫌な感じがしないです。メンテナンスも楽で実家にもプレゼントしようとしている商品です。

 

サーキュレーター:アイリスオーヤマ サーキュレーター 静音 左右首振り 8畳 パワフル送風 ホワイト PCF-HD15-W

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:サーキュレーターが欲しくて、ネットで探してAmazonのサイトで発見。

〇購入時の判断ポイント:「予算4,000円以内」「持ち運びが楽な事」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:Amazonの口コミの多さと評価の高さ。

〇使ってみての感想:上下が自動で首振りしないシンプルな機能ですが、夏に部屋の空気を循環させたり、暑いと感じる時に扇風機の代わりに使ったりするのには十分でした。価格もやすいため、追加で更に1個購入して、夏場はお風呂場の湿気が溜まらないように稼働させていたりします。

 

カーテン自動開閉:SwitchBot カーテン 自動 開閉 スイッチボット

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:Twitterの投稿で目に入った

〇購入時の判断ポイント:「朝日入れるために指定した時間でカーテンを開けてくれる」「予算2万円以内」「つけたい場所のカーテンレールに設置が可能」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:Amazonのセール中に7000円くらいで買えたので、失敗する可能性も考慮しつつ購入を決意。

〇使ってみての感想:レビュー内に音がうるさいや上手く動作しないというものがあったため、自分もそうなるのではないかという心配がありました。設置したばかりの頃は音がうるさかったりしましたが、滑りやすくしてみたり対応する事で音も静かになり、自動で夕方にカーテンが閉じて、朝に開く素晴らしさを実感しています。朝日がほしい時にカーテンが開く事で起きやすさも向上したと思います。

 

コーヒーメーカー:シロカ コーン式全自動コーヒーメーカー [真空二重ステンレスサーバー/予約タイマー/自動計量] SC-C121

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:コーヒーメーカーが欲しくて、検索していた所youtubeの紹介動画を見て知りました

〇購入時の判断ポイント:「メンテナンスのし易さ」「美味しいコーヒーが飲める」「見た目がお洒落」「場所をあまりとらない」「予算2~3万円以内」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:メンテナンスが簡単そうでお洒落でコンパクトでしたので購入。

〇使ってみての感想:美味しいコーヒーを飲みたい時に手軽にコーヒーを飲めるようになりました。来客時にも大活躍しています。メンテナンスも時間をあまり掛けずに行う事ができて、メンテナンスが面倒だから使わなくなることもなく、利用し続けられています。

 

電気ケトルティファール 電気ケトル 1.2L 温度調節 7段階 「ジャスティン コントロール ブラック」 保温 自動電源オフ 空だき防止 KO7558JP

〇購入時期:2020年

〇どこでその商品やサービスを知ったか:温度を指定できる電気ケトルを探して、Amazonのサイトで発見。

〇購入時の判断ポイント:「温度指定出来る事」「製造元が信頼出来る会社である事」「予算1万円以内」

〇購入の決め手:Amazonの口コミの多さと評価の高さ。

〇使ってみての感想:温度設定を出来るのが、こんなに良いものとは思いませんでした笑 お茶で適した温度がある場合、感覚で止めていましたが必要な温度で止まってくれるのは100度以外でお湯を沸かしたい事がある人にはとてもお勧めです。他にとても良い商品が出ない限り、ケトルはティファールで買うと思います。(ティファールは、世界で初めてコードレス式電気ケトルを発売したパイオニアだそうです)

 

 

 

【家の掃除用品】

トイレ掃除:ドメスト 除菌クリーナー 次亜塩素酸配合

〇購入時期:2009年

〇どこでその商品やサービスを知ったか:一人暮らしを始める時に、母が買ってくれてからずっと使用

〇購入時の判断ポイント:「トレイの掃除が楽にできる事」

〇購入の決め手:一回使用してからその洗浄力に驚いてリピートし続けています。こすらずにも汚れが落ちる驚異の洗浄力

〇使ってみての感想:便がトイレに付いてしまった時にも、ドメストを使えば相当しつこいもの以外、綺麗に流れていってくれます。これが非常に助かっています。(トイレットペッパーで直接触って処理するような事をしなくても済む)

 

お風呂掃除:ルック おふろの防カビくん煙剤 せっけんの香り 

〇購入時期:2020年

〇どこでその商品やサービスを知ったか:SNSの投稿

〇購入時の判断ポイント:「お風呂のカビの発生を抑えられる事」「手軽であること」

〇購入の決め手:SNSでの評価及びAmazonの口コミの多さと評価の高さ。

〇使ってみての感想:使用するのと使用しないでは、カビの発生が抑えられていると感じます。いっとき3か月以上感覚を空けてしまった事がありましたが、カビが発生し始めてしまいましたが、3か月でしっかり掃除とこの商品を使えばカビは発生していません。(毎日浴槽と床はお風呂の後に掃除している環境です)

 

脚立:ぼん家具 脚立 アルミ製 木目調 折りたたみ 軽量 ステップ おしゃれ 〔4段〕 ダークブラウン

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:手の届かない場所が掃除したりできるようにするために脚立を探していた所、友人にお勧めされたもの。

〇購入時の判断ポイント:「軽い」「お洒落」

〇購入の決め手:友人がとても良いと言っていた事。少し調べて問題なさそうだったので購入。

〇使ってみての感想:大掃除や外の木の枝を切る際に、使用しています。軽いくてお洒落な外観がとても高評価です。

 

【調理器具】

 

お菓子トング:スケーター トング 手が汚れない お菓子トング チェリーホワイト 18.5cm KTG1-A

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:SNSの投稿。

〇購入時の判断ポイント:「繰り返し使える事」「コンパクトである事」「手を汚さず様々なお菓子が食べれる事」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:価格

〇使ってみての感想:安いのでとりあえず購入してみて使っていますが、手を汚さずお菓子を食べれるので、とても買って良かったと思います。素手だとどうしてもパソコンのキーボードが汚れてしまうので、パソコンをやりながらお菓子を食べる事が多い人にはとてもお勧めです。

 

焼肉グリル:イワタニ スモークレス焼肉グリル やきまる CB-SLG-1

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:父親にイワタニのグリルは良いとお勧めされて知る

〇購入時の判断ポイント:「煙が出にくい事」「ガス缶の装着、脱着が簡単な事」「お手入れが簡単な事」

〇購入の決め手:煙が出にくい事がAmazonレビュー内に多かった事。

〇使ってみての感想:本当に煙が発生し難くて驚きました。暖かい季節にこのグリルで焼肉をやりながら、お酒を飲むのはとても幸せな時間となっています。この1世代目が壊れてしまったら、「やきまる2」が出ているので次は2を購入予定です。

 

野菜の保存:野菜 果物 鮮度保持袋 愛菜果 Lサイズ

〇購入時期:2015年

〇どこでその商品やサービスを知ったか:母が一人暮らしを始める時に買ってくれたもの

〇購入時の判断ポイント:「野菜の鮮度を長持ちさせる」

〇購入の決め手:野菜の鮮度を長持ちさせる効果がある事が使用して判明してからリピートを決定

〇使ってみての感想:野菜はとりあえずこの袋に入れて、冷蔵庫の野菜室に保管する事が我が家での当たり前の事として行っています。

 

 

在宅ワークやパソコン関連】

マウス:Lenovo Legion M200 RGB 5ボタン ゲーミングマウス

〇購入時期:2020年

〇どこでその商品やサービスを知ったか:購入したノートPCに合うマウスを探していた所、ノートPCと同じメーカーのLenovoのサイトで発見。

〇購入時の判断ポイント:「ゲーミングっぽく光る事」「カッコよい事」「予算1万円以内」

〇購入の決め手:他にこれよりもカッコいいと思えるものが見つからなかったため購入を決断。高額で転売?されており、定価で買えないので我慢していたが、定価と同じくらいの値段で買えるタイミングがあり、その時に購入。

〇使ってみての感想:見た目通りのカッコよさに加わって私の手にかなりフィットしており、ずっとこのマウスを使っていきたいと思っています。また安く買えるタイミングがあれば予備を1つ確保する予定です。

 

PCスタンド:BoYata ノート パソコン スタンド PCスタンド パソコンスタンド 人間工学設計 安定性 無段階高さ調整 姿勢改善 折りたたみ式 滑り止め アルミ合金製 在宅勤務 17インチ以下対応 BoYataのストアを表示

〇購入時期:2020年

〇どこでその商品やサービスを知ったか:SNSの投稿。

〇購入時の判断ポイント:「2か所高さを変えられる事」「壊れにくい事」「予算5,000円以内」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:SNSでの評価及びAmazonの口コミの多さと評価の高さ。

〇使ってみての感想:かなり丈夫な作りで重量が結構あって持ち運びはきついですが、安っぽくない作りで満足しています。気に入って2つ買ってます。スタンディングで仕事をしている時にも便利です。

 

 

持ち運びPCスタンド:【Amazon限定ブランド】 パソコンスタンド ノートパソコン スタンド ipad mac タブレット 折りたたみ式 高さ調整 角度調整 持ち運び ノートpc 軽量 10-17.3インチに対応

〇購入時期:2022年

〇どこでその商品やサービスを知ったか:会社の後輩が会社のオフィスで使っていて、存在を知る

〇購入時の判断ポイント:「持ち運び可能である事」「2か所高さを変えられる事」「壊れにくい事」「予算5,000円以内」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:見た目が丈夫そうで、デザインが良かったため。

〇使ってみての感想:上記のノートPCスタンドと使用感はあまり変わらないくらい安定しており、出先でPC作業をする際にとても重宝しています。

 

 

電源タップ:エレコム 電源タップ タワー型 延長コード 12個口 USB×5ポート 雷ガード ほこりシャッター 固定パーツ付 2m ブラック ECT-0720BK

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:様々な方向から差す事ができるタワー型の電源タップを探して、Amazonのサイトで発見。

〇購入時の判断ポイント:「予算5,000円以内」「USBも差せる事」「雷ガードが付いている事」「Amazon サクラチェッカーでのチェックで問題ない事」

〇購入の決め手:Amazonの口コミの多さと評価の高さ。

〇使ってみての感想:色々な方から電源を使いたい箇所がある場合はタワー型がかなり便利です。友達が遊びにきてもUSBの差し込み口が足りないとかにも対応できます。

 

電源タップ:Fargo 電源タップ 木目調 延長コード 1m 2m 雷サージ USB 急速充電 コンセント プラグ ほこり防止シャッター付 配線 一括スイッチ OAタップ AC6個口 3.4A USB 絶縁プラグ オフィス 出張 新幹線 旅行 ベージュウッド

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:人目に良く付く場所に置く電源タップとしてお洒落なデザインのものが欲しくて、探して、Amazonのサイトで発見。

〇購入時の判断ポイント:「複数の差し込み口がある事」「雷ガードが付いている事」「ほこり防止できるもの」「お洒落である事」「USBも差せる事」「予算5,000円以内」

〇購入の決め手:お洒落でAmazonセールの時に5000円を切って安く買ったので購入。

〇使ってみての感想:ダイニングテーブルの横の棚に置いていますが、他の家具と馴染んでおり、とても気に入っています。

 

 

【健康関連】

風邪の引き始め:【第2類医薬品】ツムラ漢方内服液葛根湯

〇購入時期:2004年

〇どこでその商品やサービスを知ったか:会社の中国出身の後輩がべた褒めしてお勧めしてくれた

〇購入時の判断ポイント:「風邪の効き初めに良さそうな事」

〇購入の決め手:物事をしっかり見て考えている後輩がお勧めしていたので、お試し感覚で購入。

〇使ってみての感想:風邪の効き初めやなんか体調が悪いなと感じたら、毎回飲むようにするほど、欠かせないものになっています

 

 

腕時計:Fitbit Versa3 Alexa搭載/GPS搭載 スマートウォッチ Black ブラック L/S サイズ [日本正規品]

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:振動の目覚ましや歩数、睡眠時間管理をするためにスマートウォッチが欲しくて、探して、Amazonのサイトで発見。

〇購入時の判断ポイント:「振動のアラーム機能がある事」「歩数が記録出来る事」「睡眠時間が記録される事」「電池が2~3日充電しなくても持つ事」「予算3万円以内」

〇購入の決め手:最後は他の有名なメーカーと見比べて、価格と電池持ちの良さが決めてとなり購入。

〇使ってみての感想:購入してから毎日身に付けていますが、お風呂に入っている間だけの充電で充電は完了しますし、4日間充電しなくても電池は切れません。朝うるさい音で起きるのではなく、振動で起こしてくれるため目覚めも良くなり、自分がどれだけ歩いているか睡眠時間を取っているか週に1回レポートが来るので、健康に悪い生活をしている事を数値で見る事ができます。

 

 

お酒飲み過ぎた後:永谷園 1杯でしじみ70個分のちから しじみわかめスープ&お吸いもの 160g(40食入)

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:飲み過ぎた時様にしじみのスープが欲しくて、探して、Amazonのサイトで発見。

〇購入時の判断ポイント:「オルニチンがしっかり入っていて美味しそうである事」

〇購入の決め手:永谷園というメーカーへの信頼性

〇使ってみての感想:手軽に飲めるしじみのスープの中で美味しく飲めて味も2種類あってお気に入りになりました。

 

肌荒れや口内炎:[指定医薬部外品] エーザイ チョコラBB ライト 100mL

〇購入時期:2004年

〇どこでその商品やサービスを知ったか:会社の後輩にお勧めされて知る

〇購入時の判断ポイント:「肌荒れへの栄養補給が出来る事」

〇購入の決め手:会社の後輩がかなり愛用していたので、お試し感覚で購入。

〇使ってみての感想:肌荒れが栄養不足によって、起きている可能性もあるので、ニキビや口内炎が出来た際には、飲むようにしています。

 

耳栓:MOLDEX 使い捨て耳栓 コード無し お試し8種エコパック ケース付

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:SNSの投稿。

〇購入時の判断ポイント:「素材が柔らかい素材である事」「色々なものが試せる事」

〇購入の決め手:お試しセットが安い価格で購入できるため、お試し感覚で購入。

〇使ってみての感想:耳栓は過去数個買ったことがあるのですが、どれも合わずに使わなくなっていたところ、この商品の中で自分の合うものを見つけることができて、いまは寝る時や周辺の音がうるさい時等集中したい時に頻繁に付けています。

 

氷枕(高熱時):アズワン ナビス 水枕大人用

〇購入時期:2021年

〇どこでその商品やサービスを知ったか:子供の頃から使っていた風邪で高熱を出した時に使っていた水枕をコロナで高熱なった時に必要だと感じ、ネットで探して、Amazonのサイトで発見。

〇購入時の判断ポイント:「水が漏れない事」「予算2000円程度」

〇購入の決め手:セール中に1500円程で買えた事。事前に持っていないとコロナの感染拡大で売り切れてしまうかもしれないと思ったため。

〇使ってみての感想:コロナに感染した時に、この水枕のおかげで頭を効率的に冷やす事ができ、順調に回復する事ができました。高熱になった時にこれがなかったと思うと怖いです。

 

ゆたんぽ:レンジでゆたぽん ぽかぽか快適睡眠

〇購入時期:2019年

〇どこでその商品やサービスを知ったか:薬局でリラックマとコラボしているのが目にとまり知りました。

〇購入時の判断ポイント:「レンジで温められる事」「繰り返し使える事」「予算2000円以内」

〇購入の決め手:価格が安く買ったので、お試し感覚で購入。

〇使ってみての感想:寒い時期になった時にお布団に入る10分前とかに事前に温めたゆたぽんを足の所に入れておくと、お布団がぬくぬくした状態から寝る事が出来て、寝やすくなったと感じます。お湯が漏れるかもしれないというお湯の湯たんぽで気にする事も気にしなくて良くて、冬に重宝しています。

 

足つぼマッサージ:アズマ商事の 足ツボマッサージ

〇購入時期:2018年

〇どこでその商品やサービスを知ったか:様々な銭湯や温泉に置いてあって存在を知っていた

〇購入時の判断ポイント:「足つぼを押せる事」「長く使えそうであること」

〇購入の決め手:様々な銭湯や温泉に置いてあり、その時に使っている事もあり、他の物を探す事は考えなかった

〇使ってみての感想:お風呂上りに毎日乗っています。健康に効果が出ているかは不明。痛気持ちいいです。

 

【美容関連】

顏の毛の永久脱毛:メンズTBC

〇購入時期:2013年頃

〇どこでその商品やサービスを知ったか:顔の毛を抜いていたら埋没症になり、傷跡が残るようになって、それを今後起こさないようにするために検索。ネットか電車の広告でサービスを知る。

〇購入時の判断ポイント:「お店に十分な実績がある事」「行きたい時に行けるような特定の期間に縛られない事」「家から1時間以内の場所にある事」

〇購入の決め手:初回お試し500円で、試すことができて、お試しで良さそうだったので本格的に永久脱毛する事に決めました。

〇使ってみての感想:髭剃りの頻度は減りますし、埋没症が起きてしまう事もなくなり、顔の肌が綺麗な状態になりました。私の周りで私に影響されて永久脱毛した人が数名いますが、皆やってよかったと言っています。一生やる髭剃りが楽になるのは、髭剃り代を考えてもお得かもしれません。

 

【洋服】

ダウンコート:水沢ダウンのオルテラインのブラックのアンカー

〇購入時期(※3):2015年頃(もう少し前かも)

〇どこでその商品やサービスを知ったか:行きつけのお店のブランドとコラボ商品として入荷されていた

〇購入時の判断ポイント:「暖かい事」「ポッケの中の肌触りが良い」「見た目がカッコいい」「スーツにもジャケットを着なければ合いそうで会社に来て行けそう」「水を内部に侵入し難くしている作り」「熱くなったら脇の箇所のジッパーで熱を逃がす事もできる」「有名なデサントの商品である」

〇購入の決め手:見た目がカッコ良く、長く着る事ができそうだと感じたため。当時10万円以上の洋服を買う事が初めてであったため、かなり悩みましたが、デザインがカッコよかったのと、1つくらい高いアウターを持っておいた方がデートの時にも役立つと思い購入。

〇使ってみての感想:天気が悪い時や風が強い時、寒い時に毎年かなりの頻度で来ていますが、とりあえずこれを羽織るだけでもお洒落感が出てかなり気に入っています。これまで購入してきた洋服の中で一番買って良かったと思っています。これからも大事にして後10年。持つのであれば数十年着ていきたいと思っています。

 

 

麦わら帽子:arthの麦わら帽子

〇購入時期:2015年頃(もう少し前かも)

〇どこでその商品やサービスを知ったか:阪急メンズ館の麦わら帽子のお店

〇購入時の判断ポイント:「カッコよい事」「長持ちしそうであること」

〇購入の決め手:ウサギのような動物の飾りとデザインや形が気に入った

〇使ってみての感想:夏はよくこの麦わら帽子を被る事が多いですが、数年経っても形が崩れる事がなく、長く使う事ができています。本当に見た目がカッコよくて気に入っています。

 

 

 

【旅行ブログ_2022年11月】草津温泉(湯畑周辺) 3泊4日 30代の男1人旅

今回ゆっくりと旅行する時間を確保する事ができたので、過去に一度1泊で行ってから大好きになった草津温泉に今回3泊4日(平日の火~金曜日)で行ってきました。事前に計画を色々立てるのに時間を使わず、行ってから何をするか、何を食べるか考える旅にしました。草津温泉3湯めぐりのそれぞれについての感想や立ち寄ったお店で美味しかったお店の紹介を入れつつ、4日間をどのように過ごしたかをご紹介します。

 

<もくじ>

 

 

【事前準備】

事前準備は3泊宿泊する宿の予約を数日前にやったのと3泊分の着替え、PC作業等の荷物を前日に1~2時間くらいで準備して出発の電車情報を調べたのみです。

 

【一日目】

~湯畑~

朝から東京方面から電車とバスを使って、草津温泉バスターミナルに13時頃に到着。まず初めにした事はとりあえず湯畑を見にいきました。それで「草津温泉にきた!」という感情を早々に感じる事ができました。私は温泉の硫黄のような匂いがとても好きで、その匂いも楽しむ事ができて到着早々に癒されました。


<お昼頃の湯畑>

 

 

宿のチェックインまで時間があるので、湯畑周辺をとりあえずひたすら歩いて散策。スーツケースを持ち歩くのが辛かったので、ちょっと早めに宿にいって荷物を預けようすると、もうチェックイン可能との事だったのでそのままチェックインしました。

~宿 草津温泉 千」


宿は3泊全て「草津温泉 千」という宿にしました。宿を別々に予約するやり方もありましたが、準備に手間を掛けたくなかったので同じ宿にしました。湯畑から草津のスキー場方面に少し歩いたところにある宿で、2022年8月に部屋がリニューアルされた事もあり、エントランスや部屋はとても綺麗で居心地がよかったです。

 

<草津温泉千の外観とエントランス。エントランス写真の後方にあるのがお風呂の建物>

 

 

シングルの部屋には作業用デスクもあり、勉強やPC作業がやり易く、ワーケーションにもいいなと感じました。この宿には3つの貸し切り風呂が存在しており、それぞれのお風呂の建物に内鍵が付いています。2Fからお風呂の建物に行けるのですが、外に出る前に各風呂の木札がぶら下げられており、ぶら下がっている札が今入れる(空いている)お風呂の目印になります。お風呂に入る時はその札を持って、お風呂の建物に入って内鍵を掛け、お風呂が終わったら木札を元の場所に戻すやり方です。平日という事もあり、部屋全体の稼働率は50%くらいだったのと、ピークになり得そうな時間帯(7:00~9:00、17:00~20:00)を避けていたので、私がいくタイミングで全てどこかは空いていて入る事ができました。お風呂は24時間入れるようになっています。お昼頃の誰も入っていない時に清掃を行っているそうです。

 

 

お風呂の建物はリノベーションされていないようだったので、古い作りになっており、蜘蛛や小さい虫とかが苦手な人には少し怖いと感じるような作りになっています。(必ず虫に遭遇するというレベルではありません) 。古い建物がお好きな方には最高だと思います。お風呂は源泉100% 掛け流しで「岩風呂」「檜風呂」「陶器風呂」の3種類があります。「陶器風呂」は壺風呂のように1名が入るような小さいお風呂です。詳細は下記に宿の公式ホームページのリンクを貼っているので、そちらを見て頂ければと思います。

 

<宿の公式ホームページ>

kusatsusen.com

 

 

この宿の貸し切り風呂が今回の旅行の楽しみなのもあって、チェックイン後にすぐに貸し切り風呂にいきました。初回は人気だと勝手に感じた「檜風呂」に入りましたが、檜の匂いを感じながらの源泉100%は最高でした! ドライヤーは各お風呂の場所にはなく、自分の部屋に付いていました。お風呂の建物にドライヤーを置くと髪を乾かしている時間も他の人が入れないので、そのため置いていないのかもしれません。お風呂は熱い時とぬるめの時が存在します。時間帯でそうなるのか、入った人の感覚が短くなるとそうなるのか、掛け流しているお湯の量を時間帯で変えているのかは不明です。初回は私にはちょうど良い温度でした。

 

 

~散歩「西の河原公園」

 

部屋でゆっくりした後に、西の河原公園に湯畑とは違った大自然と温泉の川?を見にいきました。大自然の空気と温泉が流れる川から出てくる湯気を見ながらの散歩はとても癒されました。


<お昼過ぎの西の河原公園>

 

~温泉「御座之湯」

その後、また湯畑に戻ってきて草津三湯と呼ばれる有名な温泉の一つである「御座之湯」へ。御座之湯は室内のみに浴室がある所で、二つの浴室を日替わりで男女交代制にしているそうです。夕方にしか入った事がないですが、少し暗い浴室で人が少ない時に入ると広い室内で立ち上る湯気と照明がとても癒される感じになっています。貴重品については大きな荷物は100円の有料ロッカーが脱衣所の外(フロントの横)にあり、お財布や携帯は脱衣所に小さなロッカー(鞄とかは入らない)がありました。私はこういう場所では、ものを万が一でも捕られたりされたくないので、必ず有料ロッカーを使います。せっかくの旅行も万が一何か盗まれたりしたら、気分がかなり落ち込んでしまうので、貴重品管理は大切です!上着もお気に入りの大切な洋服なので貴重品ロッカーにいれます。(3湯とも大きい方の有料ロッカーには少し大きいリュック(成人男性の背中くらい)と洋服が入るような大きさでした)

 

 

<御座之湯の外観>

 

「3湯めぐりの手形」というのがあったので、3泊もあるし全部入ろうと今回はこの手形を購入して入りました。3湯入るのであれば入浴券をそれぞれで買うよりも安くなります。

<三湯めぐり手形>

 

<御座之湯とは>

gozanoyu.com

 

~湯畑周辺で晩御飯探しから宿~

その後、晩御飯を探しながらうろうろしながら、初めて草津に来た時に飲んだ地ビールがとても美味しかったので、部屋で飲もうとまずはビールを購入。「湯あがり涼風 」というものです。Amazonでも買えるようですが、送料が掛かるようです。

 

<お気に入りの地ビール 「湯あがり涼風 」>

 

<夜の湯畑>



その後、お団子を焼いていたのでそれを買って食べて、どこかのお店に入ろうとしましたが、何故か突然面倒になり、セブンイレブンでお弁当を買って、宿の部屋でお酒飲みながら晩御飯を食べました笑 セブンイレブンのお弁当美味しいなと思いつつ、せっかく来たんだし明日から晩御飯はお店で食べようと誓いつつ、宿の「陶器風呂」に入って就寝。一人だからこそ自分の気分で行動を変えられるのは一人旅行の良い所ですね。


<部屋で飲む地ビール>

 

 

この宿は部屋が暗証番号のみで開けられるようになっており、1日目は少し心配していましたが、部屋に入った後に内鍵と家に付いているドアが途中で空かなくなるやつ(チェーンだったり鉄の棒だったりするやつ)を全て掛けて寝ましたが、まだ少し警戒しつつ熟睡はできずでした(警戒しすぎ笑)2日目以降は熟睡しました。トイレが部屋についてないので、廊下の音とか気になる方は耳栓を持って行った方が熟睡できそうです。私は耳栓を2日目から装着しました。すごいうるさいわけではないです。

 

 

ちなみに私は「MOLDEX」という使い捨ての耳栓を使っています。「お試し8種エコパック ケース付」から自分の耳に合うものを探せるため、1個買って合わないから次を探すというような事を避ける事ができてこの中に合うものが見つかればお勧めの商品です。(この商品に出会うまで何回も買っては、自分に合わなくて捨ててを繰り返して耳栓を諦めていました。柔らかい素材なので寝ながらつけても耳が痛くなり難いと思います)

 

 

【二日目】

~宿で朝風呂と朝ご飯~

6:00に起きて、宿の「檜風呂」に入り、7:30から宿の朝食!釜の炊き込みご飯が朝食で出てくるプランにしたのですが、とても美味しかったです!味噌汁とお漬物もついていました。(7:30、8:00、8:30で食べる時間を事前に伝えて置いて、その時間にいくと食べられるものです)

 

<宿の宿泊プランに付いていた朝ごはん>

 

~食後の散歩 「湯畑」「西の河原公園」~

美味しいご飯を食べて旅行にきた感を味わいつつ、朝の湯畑と西の河原公園の様子を見に食後の散歩。2つとも朝は夕方とまた違って景色が広がっていて最高です!湯畑は足湯にも入りつつのんびりしました。

 

~温泉「大滝乃湯」とお昼ご飯~

宿に戻ってPC作業をちょっとやってから、貴重品系とタオルだけ持って次は草津三湯の「大滝乃湯」へ。1日目に購入した手形を使って入りました。大滝乃湯は脱衣所の外に小さなロッカー(鞄とかは入らない)があり、大きな貴重品ロッカーは脱衣所にありました。御座乃湯は初めて来ましたが、正直3湯の中で個人的に一番お勧めの温泉でした。室内にも大きめのお風呂があり、露天風呂は岩の壁を流れる小さな滝のようなものと紅葉の季節であれば、紅葉を一緒に見る事ができます。昼間に入るとこの滝のようなものを流れる温泉に光がキラキラ反射してとても綺麗でした。露天風呂から下の降りていくと「合わせ湯」の部屋があり、湯気の匂いをとても感じる事ができるような場所でした。「合わせ湯」は5段階ある段々熱いお風呂に移ってはいるものですが、私は3つ目から熱くては入れませんでした笑 合わせ湯の場所に、打たせ湯もあって、そこで滝修行のように人が少なければ無心になれるくらいリラックスできます。温泉にも看板がありますが、浴室の床がかなり滑りやすくなっているので、滑らないように超要注意です!! ちょっと油断すると滑ります。

 

<大滝乃湯の施設と合わせ湯の説明>

ohtakinoyu.com

 

お昼ご飯は大滝乃湯でご飯を食べれる場所があったので、そこで昼ご飯。「くま笹ざるうどん」と「ソースヒレかつ丼」がお勧めとネットで見ましたが、ソースヒレかつ丼が好きすぎてソースヒレかつ丼を選択。ソースヒレカツ丼 とても美味しかったです。間違いない選択でした。

 

<大滝乃湯の外観とソースヒレかつ丼>



 

~散歩から温泉 「西の河原温泉」~

また湯畑周辺を散歩しつつ、宿に戻ってPC作業。夕方から西の河原公園の近くにある3湯の「西の河原温泉」に行きました。「西の河原温泉」はドライヤー無し、身体を洗う場所無しの温泉になるため、綺麗好きな方や宿が遠い方は髪を濡らさないように注意が必要です。ここの貴重品ロッカーは脱衣所に入る前に小さいロッカーがあるのと、脱衣所の中に大きな貴重品ロッカーがあります。夜の「西の河原温泉」は周りの大自然はあまり楽しめませんでしたが、かなり広い露天風呂から出ている湯気が照明で照らされていて、2つの温泉とはまた違った良さがありました。奥の方に木(多分素材は檜)で出来た屋根がある場所があり、近づくと木の匂いを感じる事ができました。広い露天を色々移動してみて、様々な景色を見るのがお勧めです。(ここは日によって混浴もやっているそうです)

 

sainokawara.com

 

~晩御飯 「手打ちそば あおやま 湯畑店」~

 

温泉に入った後、晩御飯の場所を探してうろうろ。1日目も入ろうとした居酒屋さんが2日目も予約で満席の状態になっており、ここは夕食時予約しないと入れなそうだなと思いました。「水穂」というお店です。気になっている方は予約した方が良さそうです。

 

更にふらふらしていると美味しそうなお蕎麦屋さんを発見し、2日目の晩御飯はそこにしました。お勧めの舞茸天丼セットとビール、温泉卵を注文。温泉卵上手い!舞茸天丼上手い!ビール上手い!お蕎麦上手い!と大満足でした!大満足すぎて、ビール追加、生湯葉追加しましたが、それも美味しくて、また来たいと思うお店でした。とても落ち着いた雰囲気のお店で、コロナ感染対策も万全!


<「手打ちそば あおやま 湯畑店」メニュー、温泉卵、生湯葉、舞茸天丼セット>

 

~宿~

宿に帰り、少し部屋でゆっくりしてから、宿の「陶器風呂」に入って、早めの就寝。1日目よりもお風呂が熱く感じて、入れなかったのでめっちゃお湯を搔きまわして温度を下げました笑 宿の人に確認したところかけ流しの水量とかによって温度は変わるみたいです。頑張って掻きまわしたらなんとか入れました。

 

【三日目】

~宿で朝風呂と朝ご飯~

6:00に起きて、宿の「檜風呂」に入り、また美味しい炊き込みご飯の朝食。この時は熱くは感じましたが、少しお湯を掻きまわすくらいで入れるレベルでした。

 

 

~散歩 湯畑周辺で足湯、温泉「大滝乃湯」~

朝食後に湯畑を散歩して足湯してから、9:00にまた「大滝乃湯」へ。平日の午前中の早い時間は空いてるようで、人が少なくゆっくり寛ぐ事ができました。(合わせ湯の1段階目と打たせ湯と露天風呂が本当に最高です)

 

~散歩とカフェ 「カフェ キャトルフレール」~

「大滝乃湯」の後にまた湯畑方面に戻り、ちょっと気になっていた湯畑の坂の下にある喫茶店へ。アイスロイヤルミルクティーが好きで色んなお店でアイスロイヤルミルクティーを飲むのですが、ここのアイスロイヤルミルクティー美味しかったです。値段もお手軽で量も結構入っていました!空いている時間に行った方が良いそうです。私が行ったときは私一人でした。

 

 

 

~お昼ご飯  洋食屋「どんぐり」~

お土産やらを買って宿に戻ってPC作業して、宿の近くにある洋食屋さんの「どんぐり」へ。OPEN時間直後に行きましたが、既にお客さんもそこそこ入っており、自分が入った後は待ち列ができていました。待ちたくない人は早めに行った方が良さそうです。

 

ここではお店の名前である「どんぐり」が料理名に入っている「どんぐり風ハンバーグ」を注文。チーズが乗ったハンバーグですが、ハンバーグソースが洋食屋さんならではの美味しいソースでここも来てよかったと思いました。


<どんぐりの「どんぐり風ハンバーグ」とライス(単品)>

 

~宿で休憩~

その後、また宿に戻りPC作業して宿の「岩風呂」に入ってみました。これで3種類の貸し切り風呂を制覇。「岩風呂」は開放感が一番あったお風呂でした。この時はちょっとぬるいかなと思うような温度でした。ゆっくり入れるので私は好きな温度。

 

 

~晩御飯 居酒屋「キッチン笑りぃ」から宿に帰りPC作業して就寝~

その後は15:00くらいから居酒屋に入って、早い晩御飯にしました。16:30くらいまで多分呑んでましたが、ほぼ一人の時間が多く、貸し切り状態でした。焼き鳥や1日限定5食と書いてあった馬刺しユッケとビールを堪能し、湯畑周辺でお土産を買って、宿に戻り、PC作業して、「陶器風呂」に入ってまた早めに就寝。1Fのフロントにはコーヒーメーカーと水が常備されており、PC作業する時は結構コーヒーを頂いてました。

 

 

【四日目】

~宿で朝風呂と朝ご飯~

6:00に起きて朝風呂「岩風呂」に入って、また朝食で炊き込みご飯を食べてそのままチェックアウト。この時の「岩風呂」は熱すぎて、5分くらい湯を掻きまわし続けても私は熱くては入れませんでした。しぶしぶ部屋に戻ろうとした所「陶器風呂」が開いていたので、そこも熱かったですが少し湯を掻きましたら入れました。エントランスにグループで来ている人が話していましたが、「あの熱いのがいいのよ。草津は」という人と「でも熱すぎるよー」という人がいました。人によって好みの温度が変わるので難しいですが、熱いのが苦手な方は髪を洗った後に入ろうとして、熱すぎては入れないと身体を冷やしてしまうため、体や髪を洗う前に入れそうか熱さチェックした方がよいかなと思いました。

 

~バスターミナルでバスと電車の券を購入後、お土産購入と足湯~

湯畑周辺の温泉まんじゅうで有名な「本家ちちや」で温泉まんじゅうを購入し、草津バスターミナルで長野原草津口駅に向かいました。次のバスが9:20発という事で1時間程暇でしたので、湯畑に戻って足湯と湯畑の風景を堪能して帰路に着きました。特急電車は利用しないで帰りましたが、平日で電車は空いており、ゆっくり座る事ができました。長時間座り過ぎてお尻が最後の方は痛くなりましたが笑

 

www.honke-chichiya.com

 

【まとめ】

振り返ってみると「温泉、散歩、食事、PC作業、寝る」の繰り返しのような4日間でしたが、ずっと忙しかった日々を忘れてゆっくりする事ができる非日常的な生活を味わう事ができて、1日目に「一人で3泊は長かったかな?」「3泊楽しめるだろうか?」と思いましたが、ゆっくりしまくる目的としては3泊でよかったと思います。(温泉に入っていると一日があっという間に過ぎていきます) 

 

私は頭や顏に脂漏性皮膚炎のような症状(白い膜ができてぽろぽろ落ちてくる)が10年くらい前から続いており、薬や高額な漢方での治療を試してきましたが、寝不足や食べ過ぎ&飲みすぎ、カップラーメン等を食べると症状が出るのがいまだに治っていません。草津温泉は皮膚病に良いと聞いていましたが、温泉に入っているうちに症状が出る顔の部分が赤く張れてきて、三日目には日焼け後のような白い皮膚の皮がぽろぽろと落ちていくようになりました。張れやぽろぽろと落ちている箇所が症状が出ていた場所だけなので、殺菌されて症状が良くなる前兆?と現在経過観察中です。どうなったか数か月後に結果を更新しようと思います。皮膚が弱い人は入る温泉や入る時間には気を付けた方が良いです。

 

(2022年11月末追記)

肌荒れの症状は4日間後には収まりましたが、脂漏性皮膚炎のような症状は残念ながら治りませんでした、、

 

~結論~

草津温泉は温泉好きであれば、男一人でも3泊十分楽しめる

〇温泉がメンテナンスしている日があるので、自分が行きたい日にメンテナンス予定がないかは公式サイトでチェック!絶対いきたいお店あるのならお店もチェック!

〇温泉に入る際、貴重品管理をしっかりと!ロッカーの壁際にスマフォが隠れる等全部取り出したと思っても、取り出し漏れが起きたりするので指刺し確認!

〇宿の貸し切り風呂は事前に温度をチェック!扱ったら掻きまわして冷ます!

〇温泉は入りすぎ注意!草津のサイトでは一日3回ぐらいが無難の記載有。自分の肌の様子を観察!

〇本家 ちちやの温泉まんじゅうはとても美味しいけど、生もので日持ちしないのでお土産にする場合は注意!


<草津温泉についてや正しい入浴方法>

www.kusatsu-onsen.ne.jp

 

 

業務側も知っていると役に立つ情報 第2章 ~会社の業務や部署、フロント・バックオフィスの違い~

今回は「業務側も知っていると役に立つ情報」について、書いていこうと思います。何故これを書こうと思ったかというと、私が仕事をしている中で業務担当者とシステム担当者の話が噛み合っていない場面に多く遭遇しており、その原因として双方がお互いの事を知らな過ぎている事が大きな要因であると感じているためです。そのために業務部門の方がシステム部門が考えている概要を知れたり、システム部門側が業務部門側が考えている事の概要を知れたらいいなと思い、書く事にしました。今後、市民開発と呼ばれる業務部門側でアプリケーション開発を行っていくための役割や業務部門側で扱うシステムやツール検討に深く関わるビジネステクノロジストという役割の人に必要な知識になると考えます。

 

「システム部門の人とよく話が噛み合わない」「システム部門が何を考えているのか分からない」「市民開発者として今後活躍していきたい」という方には是非このブログを読んで頂ければと思います。

 

 

下記の内容を順番に書いています。この記事は第2章です。下記3点を知ることで、自分が担当している範囲やその他の繋がりがある部分の仕事の流れを想像できるようにするための知識の説明記事となります。何故この記事を書いているかや、各章で説明している内容が何の役に立つかは別の資料で説明しているので、まずはこちらを見て頂ければと思います。

 

 



<第2章の内容>
①自分が働いている会社とはそもそもどういう組織なのか
②会社の中にはどんな業務が存在しており、関係性を持っているのか
③部署や課はどんな必要性があって存在しているのか

 

ブログ連載内容】

 

【目次】

 

第1章は下記の記事です。会社内のシステム構造(アーキテクチャ)とその歴史について説明しています。昔から今を辿る事で、将来の予測に役に立ちます。1章を読んでいない方は是非1章から読んで頂ければと思います。

 

syachiku-inu.hatenablog.com

 

株式会社とは

まず会社の業務を説明していく前に株式会社について説明していきます。株式会社は株式を発行して、投資家から資金を集めて事業活動を行う会社です。よく会社は船事業を航海で例えられる事があります。航海の指揮を取る船長が社長、船員が社員、船の設備等を出資する人達(オーナー)が投資家であり、航海の先で宝を見つけたり、魚を捕獲したり、物を運んで届けたりと事業の結果で得た収益から費用(従業員の食料や船の燃料)を引いた利益を従業員や投資家達に分配して、活動が成り立っています。投資家は航海に必要な資金を出資するために一時的に資産が減りますが、自らが危険な航海をする事無く、他の投資家と協力する事もでき、利益が出れば出資した資金以上の報酬が得られます。航海には海賊に襲われたり、難破したり、何も収穫が無かったりと様々なリスクが存在します。

 

レッドオーシャンブルーオーシャンという言葉を聞いた事がある方も多いのではないかと思います。レッドオーシャンは市場(宝や海産物がある海の場所)に船が大量に存在し、競争が激しい既存市場の事で、ブルーオーシャンは競争のない未開拓の海(市場)の意味を持っています。株式会社の起源が貿易の会社だったため、市場を海で例えられて生み出された言葉なのではと思います。

 

 

現在会社を含む企業には、社会的責任(CSR)というものが存在し、過去の世界的な人権や環境問題を是正するために利益の追求だけではなく、社会や環境に対する責任が強く求められられています。


<社会的責任(CSR) の定義>

①健康及び社会の繁栄を含むを自足可能な発展に貢献
②ステークフォルダーの期待に配慮
③関連法令を遵守及び国際行動規範の尊重
④組織全体に統合され、組織の関係の中で実践する行動

 

 

また、会社については日本では2007年に会社法という、会社の設立、組織、運営および管理について定めた法律(会社法第1条参照)が全面施行されており、不正な取引や虚偽の報告、賄賂等違反している企業に対して、罰則が課せられて、社会的信用が落ちたりと不利益が生じる仕組みが存在しています。

 

会社内の主な業務や部署について

続いて多くの会社に存在する業務について、説明していきます。会社の事業(漁業や情報通信業等)毎に業務内容が変わってくるものがありますが、多くの会社に存在する主な業務は下記のものがあります。

 

経営企画・・・経営計画の立案や進捗管理、組織再編、業務提携等経営課題に取り組む業務

財務・・・企業が成長を続けるためにはどうすればいいか具体的な資金計画を立てる業務

企業会計・・・企業内のお金の出入りを管理、報告する業務

 財務会計・・・株主や投資家等外部利害関係者宛の報告目的の会計業務

 管理会計・・・企業内部の経営管理者を対象として、意思決定や経営管理に役立つ情報提供を目的とする会計業務

人事・・・給与や労務、採用等人に関わる業務

法務・・・契約書のチェックや法的手続き企業の法律に関わる業務

総務・・・会社の人が働く場所や、事務机や椅子といった備品管理や雑務をする業務

営業・・・新規・既存顧客とのコミュニケーションを行い、自社のサービスの購入や拡大に繋げる業務

販売管理・・・受注、請求、発注、仕入、在庫管理等、販売に関わる業務

購買管理・・・適切なタイミングで必要な分のみ購入する等、資材の購入に関する業務

情報システム・・・情報システムの企画、構築、運用・保守、サポート・ヘルプデスクの業務

 

上記のような業務は、情報の流れが下記図のように関係性(※1)を持っており、企業会計は事業状況(※2)を外部公開向けの決算書として見える化するために、様々な業務の情報が集められてきます。上場企業に対しては、この公開する会計情報が正しいかどうか外部監査人によってチェックされます。

※1 流れのイメージであり全ての会社がこの流れの様になっているわけではありません

※2 事業のためにどれだけお金を使ったか、他人から借りている資産(負債)、株主からの出資と利益の蓄積状況、どのような収益や費用があって、結果としてどれだけ利益がでたかや、会社の現金の増減状況等の情報

 

出典:ITによる変革の方法論集あるITコンサルタントツールボックス ITマネジメント編(https://www.itgi.jp/application/files/7316/0862/6794/14IT.pdf)

 

 

業務には「製品・サービスを開発して製造する流れ」「セールス活動して製品・サービスを販売する流れ」「戦略を考えて実行する流れ」のような流れが存在し、複数の人や部署が関係してくる事があります。この特定のアウトプットを作り出すための一連の活動・工程をプロセス(業務プロセス)と呼ばれています。私は企業内のプロセスを見る時に、川の流れのようにどんなプロセスが存在し、それぞれどのように始まって、どこで活動は終わり、何がインプット・アウトプットされて、その際に扱われるデータはどんな媒体(紙やデータ)、形式(Excelやデータベース)なのか、その時点や最終的にどんな価値があるのか考えてみています。

 

自分の担当している業務プロセスの上流はどうなっているのか、下流はどうなっているのか知るだけでも業務の改善ポイントや間違いに気付きやすくなります。具体例をあげると「作成しているレポートが実は誰も見ていなかった」のような事に気付きやすくなります。業務担当者目線では、まずは自分の川はどういう流れになっているのか、自分の関係している他の川は何があるのか抑えて、自分の担当している川の流れの前後と最後の部分から詳細理解していくのが良いと思います。

 

【⇩プロセスの川のイメージ】

 

 

続いて部署に関して説明します。部署のように組織を分けるのは上記の業務の専門性や効率を高めたり、組織の指揮命令系統を確立したり、責任者を設けて部署毎にリスク対策をできたり、責任範囲を分けたりする事が可能になる利点があり、多くの会社が複数に明確に分けて組織を作っています。「私の部署は人事部だから人事の仕事をやるんだ!」と担当になった人やチームも自分達の役割を理解し易いですよね。

 

出典:部・課・室・係など組織図の種類と違い - 社会人の教科書 (business-textbooks.com)

 

 

バックオフィスとフロントオフィスとの違い

フロントオフィスは「顧客と直接やりとりする部門」を意味しており、営業や窓口担当者、コールセンターのオペレーターの業務が該当します。バックオフィスはフロントオフィスではない、人事、経理、法務、財務、総務の業務が該当します。会社は顧客とやり取りをする人も経理のような業務を行う人も必要であり、それぞれで必要な知識やスキル、役割が異なっており、必要な役割をそれぞれが業務遂行する事で会社は存続していく事ができています。

 

バックオフィスのシステムが進んでいる世界観

バックオフィスの業務で使われているシステムには、財務会計システム、管理会計システム、生産・在庫管理システム、人事管理システム、購買管理システムが利用されていたりします。フロントオフィス側にも顧客管理システム、問い合わせ対応用のシステムがあったりと、現代社会ではほとんどの部署や人が何かしらのシステムやツール等の情報技術を扱う事が一般化してきています。それに伴い情報システム部門の業務務範囲は拡大、業務量は増加しています。第5章でも説明していきますが、市民開発やビジネステクノロジストが求められる背景の一つに誰もがシステムを使うようになり、更に求められるビジネススピードも速くなってきており、既存の情報システム部門の体制ではついていくのが難しくなってきている事が挙げられます。

 

 

システムは第1章で説明したように業務を効率的に改善したり、従来の手法では出来なかったことを実現するために主に使われ、現在では効率化や改善に留まらず利益を生み出す所まで活用が広がり、進化を遂げてきました。今後は、AIやデータ連携、各作業のワークフローの自動化の分野が更に進んでいく事で、情報を紙や画面経由で人が手作業によって連携したり、データを集めて整理・分析する業務は、人がやるべき箇所以外は様々なシステムや自動化技術によって自動化されていく流れが加速していくと考えます。自動化されない人がやるべき(人に任せる)仕事とは何だろうかと考えた時に、私は下記のような視点があると考えます。

 

①人にしかできない視点

AIやその他の革新的な技術に置き換える事ができない作業。人が考えて、創意工夫して都度柔軟な対応が必要になる作業。

②監査や内部統制に関わる視点

⇒リスクを効果的に低減させるコントロールしている部分に人の確認や承認や判断が必要な作業ではないか、人以外に置き換えても説明責任を果たせるか。

③社員の成長に関わる視点

⇒社員の成長ステップに問題を起こすようにならないか。成長していくためには必要な作業ではないか。

従業員満足度を高める視点

⇒従業員の満足を高める、維持に繋がる作業か。社員がいきいきと働ける作業か。

顧客満足度を高める視点

⇒人が行う方が顧客の満足度向上に繋がるか。

⑥雇用創出の視点

⇒企業の社会的責任の一つである雇用創出が失われ、責任を果たせなくならないか。

 

書き出してみると人間中心の設計が重要であり、人を幸せにするためにシステム(技術)を活用するんだと感じました。単純に人にしかできない視点だけで人に仕事を任せるだけでは事業の成長にいずれ支障をきたしてしまうと考えます。

 



まとめ

会社の各業務概要や部署の全体像を知る事で、自分が所属している部署や担当している作業が会社全体で見た時に、どこに位置しているのか、扱っている情報はどこから入ってきて連携や変換、蓄積されて、そこにはどんな部署や人、システム、技術が関わっているのか、自分の後はどのように処理されるのか、概要からでも抑えておく事で、広い視点で業務改善が行えるようになったり、後続処理で問題になる事に未然に気付けたりすることができます。

 

人もシステムも業務は基本「インプット⇒処理⇒アウトプット」の構造になっており、前後を気にする事が創意工夫するために重要な事です。そうする事でアウトプットで必要な情報は何かを明らかにして、本当に必要な情報を揃える作業に集中する事が可能になり、生産性を向上させることに繋がります。可能であれば、プロセスの最終地点で誰(顧客や投資家、経営判断)のための作業なのかまで抑えるのがお勧めです。

 

第3章について

次は「人の働き方とシステム開発の変化、BPR・BPM・DXの違い」について、説明していきます。第1章で会社のシステムアーキテクチャ(構成)の歴史と第2章で会社全体、他の部署との関連性やデータの流れの概要を抑える事で第3章での改革、改善活動の取り組みの意味や考え方、具体的なやり方への理解度が高くなっていると思います。

 

第3章は作成中、、、

 

 

参考サイト

産業の定義。産業は企業の集合体である。 (fujitsubame.com)

経営の原理原則その1 「会社とは何か」 : ビジネスとIT活用に役立つ情報 (asobou.co.jp)

会社法に違反する行為とは? 罪に問われる行為や罰則、逮捕の可能性を解説 (vbest.jp)

ISO26000 (国際標準化機構の社会的責任規格) | CSOネットワーク

総務省|統計基準等|日本標準産業分類(平成25年10月改定)(平成26年4月1日施行)-目次 (soumu.go.jp)

会社や法人、企業の違い - 社会人の教科書

部・課・室・係など組織図の種類と違い - 社会人の教科書 (business-textbooks.com)

キーコントロール(統制上の要点)/オペレーショナルリスクに関する用語一覧|オペレーショナルリスク|デロイト トーマツ グループ|Deloitte

ビジネスプロセスの教科書 こぼれ話第1回:ビジネスプロセスは業務プロセスじゃない! | CLOVER Light (lt-s.jp)

業務側も知っていると役に立つ情報 第1章 ~ITアーキテクトの基礎知識編~

今回は「業務側も知っていると役に立つ情報」について、書いていこうと思います。何故これを書こうと思ったかというと、私が仕事をしている中で業務担当者とシステム担当者の話が噛み合っていない場面に多く遭遇しており、その原因として双方がお互いの事を知らな過ぎている事が大きな要因であると感じているためです。そのために業務部門の方がシステム部門が考えている概要を知れたり、システム部門側が業務部門側が考えている事の概要を知れたらいいなと思い、書く事にしました。今後、市民開発と呼ばれる業務部門側でアプリケーション開発を行っていくための役割や業務部門側で扱うシステムやツール検討に深く関わるビジネステクノロジストという役割の人に必要な知識になると考えます。

 

「システム部門の人とよく話が噛み合わない」「システム部門が何を考えているのか分からない」「市民開発者として今後活躍していきたい」という方には是非このブログを読んで頂ければと思います。


この記事はUiPathブログ発信チャレンジサマー!2022の31日目の記事です。前日の30日はw.wackさんとyamasaki_aaaaさんの記事です。

note.com

 


下記の内容を順番に書いていく予定です。内容が濃いため回数を分けて書いていこうと思います。この記事は第1章です。何故この記事を書いているかや、各章で説明している内容が何の役に立つかは別の資料で説明しているので、まずはこちらを見て頂ければと思います。

 

 

 

ブログ連載内容】



【目次】

 

ITアーキテクトとは

まずはITアーキテクトって何?から説明していきます。アーキテクトという言葉は構築家や設計者の意味を持つ英単語で、ITアーキテクトはビジネスの方向性やこうしていきたい等の要求(思い)に対して、ITシステムを使ってどう実現できるかを考えて、構成を考える役割です。会社で扱っている主要なシステム達はITアーキテクトの役割の人が、どの製品や技術を組み合わせて、実現したい要求を満たすかを考えて構築されています。ビジネスの戦略立案や要求の整理はITアーキテクトではなく、コンサルタントの人が行ったり助言に入ったりする事がありますが、コンサルタントではなくITアーキテクトやビジネスアナリストが要求整理部分を行う事もあります。情報システム部門で働いている人の中でも会社全体のシステム構成を検討できる人は多くはいないケースがありますが、どのように構成していくかはITアーキテクトの人が関わって作られています。

 

 



IT・社会(ビジネス)の変遷から見るITアーキテクチャ

続いて昔と今のITアーキテクチャーの違いを見ていきます。「何故歴史を知る必要があるのか?」という点において、私は3つ大きな効果があると考えています。


【歴史を学ぶ事で生まれる効果】
1.過去と同じ失敗を回避できる
2.昔から今を辿る事で将来の予測に役に立つ
3.何故その技術や製品が生まれたかの設計思想の把握に役立ち、製品や技術を正しく扱う力が身に付く

 

では、早速歴史の説明に移ります。ひと昔前は技術革新スピードは比較的緩やかでありましたが、インターネットの普及によって、会社のシステム構成(アーキテクチャー)や開発手法、セキュリティ等の技術革新が速いスピードで進んでおり、2022年の現在では全ての技術や製品の詳細を一人のITアーキテクトが把握する事がとても難しくなってきています。また、オフィスワークの多くの方は様々なシステムを既に扱っていると思いますが、IT自体が多くの人の仕事にとっての重要性が増して来ています。大枠は下記の図のような流れで進んでいますが、ポイントを絞ってパソコン(個人向け小型コンピューター)が日本に普及し始めたとされる1990年代の少し前の1980年代から説明していきます。

 

(筆者は2010年頃から社会人として働いており、様々な文献やサイト、人等から情報を収集して書いています。もし事実と違う部分がありましたらご指摘頂けると幸いです。かなり長いのでポイントをより理解し易いように簡略版を別途作成しようと思います(-_-))

 

出典:経済産業省 「デジタルトランスフォーメーションの加速に向けた研究会 中間とりまとめ、対話に向けた検討ポイント集 第1章(デジタルトランスフォーメーションの加速に向けた研究会 中間とりまとめ(METI/経済産業省))」

 

1980年代:ワープロ専用機とパソコン、汎用機の説明 

 

1980年代初期にワープロ専用機が普及し、それまで手書きだったものがデータで処理されていく事が増えていきました。1985年頃にはパソコン対してWindows OSが発売され、GUI(Graphical User Interface)を使用して画面上のアイコンを操作する事が可能になり、次第にパソコンが普及していきます。この頃の会社のシステム構成(アーキテクチャー)はメインフレーム(汎用機やホストコンピュータ)という物置のような大きさのコンピューターに給与計算や在庫管理等多くの業務システムを一括(バッチ)処理させていくのが主流の時代でした。日本でパソコンが一人に一台割り当てされ始めたのは1990年代頃との事です。

 

 

パソコンが普及していくとEUC(エンドユーザーコンピューティング)という情報システム部門以外の人が自主的にコンピュータを操作して、自分あるいは自部門の業務に役立てる活動が始まりました。当時は誰もが手を出せるものではなく、一部の人が少し手を出していた程度だったそうです。

 

1990年代:クライアントサーバ、インターネット、VBA(EUC本格化)、アウトソーシングERPの説明

 

1990年代に入りパソコンの性能向上と価格の減少により、パソコンとパソコンをLAN(※1)接続する優位性が認識され始め、ネットワークを利用して処理を分散していくアーキテクチャーとして、メインフレームでの集中管理モデルから徐々に処理をクライアント(パソコン)とサーバ(※2)で分けて行うクライアントサーバモデルが主流となっていきます。クライアントサーバ時代から関係データベース(リレーショナルデータベース)というデータを表に似た構造に蓄積するようの技術が広く活用されるようになりました。データの場所が分散されたものを纏めて分析するためにデータウェアハウス(※3)という技術や1つのシステムで扱っているデータを他のシステムでも扱いたい場合にデータを移動したりする必要が出てきて、これを容易にしやすくするために、ETL(extract=抽出、transform=変換、load=ロード)ツールが普及していきました。


※1 ローカルエリアネットワーク。限られた範囲内にあるコンピュータなどをケーブルや無線電波などで接続し相互にデータ通信できるようにしたネットワーク

※2 利用者の要求(リクエスト)に対して、それに応答したデータを提供するコンピュータやプログラム

※3 複数システムから大量のデータを時系列で蓄積するシステム

 

 

1989年時点では、ワープロがなくなると予想している人は多くなかったそうですが、パソコンの方が文書作成に加えて、他の用途でも利用する事ができ、性能や機能の進化も早かった事から徐々に市場を奪われ、2002年に日本国内でのワープロ専用機の生産が終了しています。技術の進歩によって、当時の当たり前や世界観は時代と共に変わっていきます。

 

 

1991年に日本のバブル景気 (バブル経済)が崩壊し、経済が高度経済成長期から、後退期へと転換していきます。

 

 

1990年代の半ばからインターネット(※4)利用の爆発的な普及によって、Webシステムが広く使われるようになり、インターネット経由で様々な場所から処理を行えるようになっていきます。この頃にVBAVisual Basic For Applications)がExcelに搭載されて、前述で説明しているEUCによってVBAのプログラムが様々な場所で開発されて、作成者以外がメンテナンスできないが、なくてはならないものとなってしまったりして情報システム部門に面倒を押し付けられたり、そのツールがないと業務が回らないが止まった時に直せる人もいないので業務に支障が出る問題が多発したそうです。現在は市民開発という言葉も出てきていますが、情報システム部門側はまた過去と同じ過ちが発生するのではないかと市民開発を行う事に慎重になっている人が多くいます。市民開発については、第5章の記事でEUCとの違いも含めて深く説明や考察していきます。技術は上手く扱えば、会社にとって有益なものになりますが、使い方を誤ると不利益を与えるものになってしまいます。

 

※4 通信回線を介して世界各地の個人や組織のコンピューターがつながっている、地球規模の巨大なネットワーク。wwwというインターネット上に散在する文書同士を相互に参照可能するシステムの登場も普及した要因の一つとされる

 

 

同じ頃に日本でアウトソーシングという言葉が使われ始めてブームの様に推進されていきました。アウトソーシングは「社内の業務を外部の企業に委託すること」です。日本ではアウトソーシングという言葉が流行り始める前から外部委託をしている所があったそうですが、更に業務領域を拡大したり、大きな会社はグループ内の業務を集約して行うシェアードサービスを作ったり、海外の企業に委託したりするケースが増えていきます。

 

 

1990 年代の終わりごろには、ERP(Enterprise Resource Planning(エンタープライズ リソース プランニング))という手法が登場します。ERPは主に企業のヒト、モノ、カネ、情報を効率的に管理・配分して全体最適を目指す手法です。ERPは具体的には下記の図で表すと「財務会計」「管理会計」「生産/在庫」「人事管理」「マーケティング管理」「物流およびサプライチェーン管理」部分で扱われます。単一のシステムで基幹業務を集中管理しようする考え方で当時は設計されていました。よく同じようなもので登場するCRM(Customer Relationship Management(カスタマーリレーションシップマネジメント))は顧客管理に特化して扱われるもので、SCM(サプライチェーンマネジメント)はERPの中の「物流およびサプライチェーン管理」に含まれます。

 

黄色のオブジェクトがシステムで白の□内が業務を表している概念図です。

出典:日本ITガバナンス協会 ITによる変革の方法論集ある ITコンサルタントツールボックス ITマネジメント編 ITのアーキテクチャマネジメント(https://www.itgi.jp/application/files/7316/0862/6794/14IT.pdf)

 

 

ERPを行うためのソフトウェアパッケージとしてERPパッケージが売り出されました。(パッケージという言葉が出てきたら大体袋に色々入っているセットをイメージすると良いです。ERPパッケージはERPを行うためのシステム群を1つに纏めて提供しているセットです)

 

 

ERPパッケージが登場する前は様々な企業が独自に「財務・会計、人事管理、販売管理、調達・購買...etc」のシステムを作っていたところに、各企業が共通して使えるような機能を汎用的に利用できるパッケージングされたものを提供する企業が登場したのです。現代でいうとSAPやオラクルが代表例です。ERPパッケージを扱う事で一から開発しなくても良くなり、開発や運用を効率的に行う事ができました。「システムは作るもの」という考え方から「システムを買う」という考え方ができました。しかし、日本はこのERPパッケージ導入で当時失敗している企業が多くあると言われています。業務は時代によって、自社が提供するサービスや製品、考え方や法律が変わる事によりシステムも一緒に進化していく事が求められます。ERPパッケージで実現できない部分を独自に追加で開発を行う事を「アドオン開発」といいますが、日本はアドオン開発が他の国に比べて多いと言われています。アドオン開発部分が多いと、時が経つにつれてERPパッケージ自体は進化をしていくのに対して、アドオン開発部分への影響が出てしまったりして維持していくのに膨大な運用コストを消費してしまいます。日本はサービスレベルが高かったり、他社との差別化の部分が多かったため、グローバルで開発されたERPパッケージだけでは要件を満たせず、アドオン開発が必要な企業もあったと思われますが、ERPパッケージ導入前の働き方をそのままERP移行後も考え無しにやろうとして、余計なアドオン開発をしてしまった企業も多くあるとされています。

 

 

製品や技術を購入する側は企業存続及び利益拡大していくためにどうしていくか、何のためにその製品や技術を扱うのか、導入後の事も考慮して販売側の営業トークの言いなりにならずに使い方を考える必要があります。考え無しに特定の製品を導入するだけでは上手く扱えません。言いなりにならない様にするためにも今回説明していく知識が役立ちます。

 

 

2000年代:エンタープライズアーキテクチャー、SOAクラウドの説明

 

2000年頃にEA(エンタープライズアーキテクチャー)という企業構造を最適な姿に変革するために企業やシステムの全体構造を示す方法論、全体最適化を図るための全体設計図として流行していきました。「ビジネスの視点」「データの視点」「アプリケーションの視点」「情報技術の視点」から業務フローやシステム、ネットワーク、ソフトウェア、ハードウェア構成図等を用いて会社のITの現状を整理し、将来のモデルを作成するの使用されます経営部門や利用部門が全体や部分的な把握ができないと現状把握や将来のモデル設計がし難くくなるため、現在どのような業務があって、システムがどのように使われているかが可視化されている事は非常に重要です。

 

出典:DX白書2021_第4部 DXを支える手法と技術(https://www.ipa.go.jp/files/000093702.pdf )

 

 

EA(エンタープライズアーキテクチャ)の流行と合わせて、利用者側から見たソフトウェアの機能単位である「サービス」の組み合わせによってシステム構築していくアーキテクチャとしてSOA(サービス指向アーキテクチャ)というものが注目されていきました。サービス単位というは「請求書を処理する」のように利用者側の視点からみた作業単位を指します。サービスを部品のように細かく分ける事で様々な製品と結合させてシステム全体を組み立てる事が可能になっていきました。修正が必要な時にそこのサービス以外は影響を受け無くしたり、いらなくなったらそのサービス部分だけを切り離したりする事もできます。このような作り方を疎結合させて作ると言います。

 

 

2000年代後半からクラウド(※5)というものが登場しました。Amazonが2006年に企業向けのクラウドサービスの提供を開始し、クラウドの普及と発展は爆発的に進んでいきました。2010年頃までは、今までデータを社内の閉じたられたネットワークで管理する方が安全であり、クラウドは情報漏洩が怖い、使えないと考える人が多くいましたが、クラウドの技術が発展し、セキュリティレベルも高くなり、大手の企業も積極的に利用していくようになっていきました。2022年現在では日本政府もクラウドを積極的に利用していく方針が出ています。2010年以降は「エッジコンピューティング」という考え方に更に進化し、エッジサーバや操作デバイス側にデータ処理や分析を行う事で、通信の遅延やリアルタイム性を高めています。エッジサーバはクラウドと利用コンピューターの中間に位置するサーバです。


※5 ユーザーがサーバーやデータ保存場所やソフトウェアを持たなくてもインターネットを通じて、サービスを必要な時に必要な分だけ利用する考えや利用形態

 

2010年:マイクロサービスアーキテクチャー、バイモーダルIT、iPaaS、RPAの説明

 

2010年中頃にはビジネスや技術の進化スピードが速く、システム新規開発や改修に「変更容易性」「スピード」「拡張性」がより求められてきており、それを解決するための考え方として、マイクロサービスアーキテクチャーという、小さなサービスを組み合わせて構築する考え方が広まっています。前述で出てきたSOAと似ていますが、大きな違いは「サービスの粒度が更に小さい」「API(※6)を介した通信(SOAは複数の通信方式があり複雑)」「各サービスが独立したデータ保存場所を持つな点です。マイクロサービスとは別のアーキテクチャーでモノシリックというものがあります。モノシリックはサービス毎に切り出さずに1つのシステム内で機能を充実させて作る考え方です。どこかを修正すると他に影響が出ていないか確認やテストに多くの工数が掛かってしまったり、サービスが丸ごと異常で使えなくなってしまう作りですが、管理がしやすい(単純な構成)や大量明細を処理し易いメリットがあります。一つの大きなシステムに少しの改修をする場合も、他に影響がでないかの影響調査やテストが大変で、それを疎かにすると間違った処理をしてしまったり、システムが止まってしまう原因に繋がります。「少し直すだけじゃん」と業務部門側の方でたまに発言する人がいますが、問題を起こさないようにするための作業があり、時間やコストが掛かるのです。

 

※6  アプリケーションプログラミングインターフェース。ソフトウェアの機能や管理データなどを、外部の他のプログラムから呼び出して利用可能とする仕組みや規約

 

出典 IPA エンタープライズシステムへのマイクロサービスアーキテクチャー適用の実践(

https://www.ipa.go.jp/files/000064276.pdf)

 

 

全部のシステムをマイクロサービスにすれば、追加開発や切り離しが簡単にできると思われた方もいるとおもいますが、マイクロサービスも万能ではなく、運用が複雑になったり、設計の難易度が高かったりする面もあり、今後どこをクラウドやマイクロサービスで構成するのか、どこをERP等パッケージを使うのか、どこを自社で独自に開発するのか、それぞれをどのようにデータで繋ぐのか、分析させるのかを考えて設計していく必要があり、とても難易度が高くなってきています。ERPも必要な機能を絞り込んで利用して、足りていない部分は他のアプリケーションを組み合わせたり、個別開発していくようなポストモダンERPという考え方が登場してきています。この複雑化しているシステム設計を考えるためにそれぞれの領域に適した技術を用いる考え方として、「SoE」「SoR」「SoI」という考え方(バイモーダルIT)が誕生しています。安定が求められるシステムとスピードが求められる箇所で開発手法や技術の使い方を変えるというものです。様々な場所にデータが散らばってしまう課題を解決するために、データを処理できるように様々な場所から大量に集めて貯蓄しておく技術であるデータレイクが再注目されてきていると感じます。(前述のデータウェアハウスとデータレイクのいいとこ取りをしたデータレイクハウスというものが誕生しています)

 

出典:第1回 DX時代のITアーキテクチャとグランドデザインによる展開:株式会社 日立コンサルティング (hitachiconsulting.co.jp

 

 

また、様々な複数クラウド間と自社システムを繋いだりする技術として、iPaaSが2010年頃から注目されていきます。前述に出てきたETLやELT(Extract(抽出) Load(書き出し)Transform(変換))、EAI(Enterprise Application Integration)、ESB(Enterprise Service Bus)を含む広い概念で、iPaaS製品毎に特長があったりします。ELTEAI、ESBの説明の詳細は今回省きますが、大量データの処理に向いていたり、少ないデータでリアルタイムの処理に向いていたりで扱う場所に違いがあります。データ連携の方法が他にあるんだなと存在をまずは知って頂いて、深く関わる時がきたら違いについて調べて貰えたらと思います。

 

出典:iPaaS といってもいろいろな種類があるので分類してみよう~レシピ型、ETL/ELT、EAI、ESB~ - CData Software Blog 

 

 

2018年には日本でRPAが急速に拡大していきました。日本国内で様々なRPA製品がリリースもされています。RPAはRobotic Process Automationの略称であり、ソフトウェアのロボットが作業を自動化するツールや技術の事を言います。人がパソコンで行う操作を模倣する事ができるため、APIやiPaaSで自動化できない部分も自動化を行う事も可能です。近年ERPパッケージのSAPやCRMのSalsesforceもRPAの機能をRPAベンダーを買収して独自に持ち始めたり、RPAベンダーがiPaaSを扱えるようにしたりと、各製品ベンダーでiPaaS(API連携)、RPAの分野への競争が激化してきています。これは人の手を介さないで良い箇所はできるだけ自動化可能にしていくのと、変化への対応スピードが求められる箇所に柔軟に対応可能にしていく流れが背景にあり、iPaaSだけではなくRPAの技術も拡大し続けているのだと思います。システム開発を待っていたら現場が崩壊してしまうシーンでRPAが活躍した事例があります。ですが、RPAも万能ではなく、複雑すぎるものや画面変更が多いシステムに弱い等弱点はあります。また、RPA以外でもプログラミングをたくさん書かなくてもシステムを作れるローコード、ノーコードツールも同じように徐々に活用が広がってきています。業務部門が開発するものは、VBAもRPAもローコード系も全て前述の過去のEUCのような問題を回避して失敗を繰り返さないようにする必要があります。どのように回避していけば良いかは第五章に書いていこうと思います。

 

まとめ

 

これまで説明してきているもの以外にもAIやビッグデータ、5G、ブロックチェーン、ロボティクス等これまでの仕事の常識を変えていく破壊的な技術革新が次々起きています。IT自体そのもので利益を拡大していく事も可能な時代となり、ITの活用は効率化だけに留まらなくなってきています。ITアーキテクトはこれらの技術の進化に合わせて、自社のシステムの現状を把握しつつ、どのように構築していくかを考え、管理を行っています。本質的な問題を把握し、解決策を考え、判断を行い、技術者や経営側にわかり易いように説明を行い、最新技術動向を抑え、様々な価値観や視野を持ち、問題を予見できる人達が考え抜いて社内のシステムは構築を続けているのです。更に近年、データを上手く使ってビジネス戦略やマーケティングに活用していく企業が増えており、データの重要性がこれまで以上に重要と言われてきています。それに伴い、システム構造を検討するITアーキテクトにもビジネスやデータサイエンスの知識や能力も求められるようになってきています。(幅広すぎぃ...)

 

 

今回触れていない用語やイベントもありますが、説明してきた歴史を年表に纏めたものは下記の通りです。年表はそれが誕生した経緯や他との関係性、これからどうなっていくのかを考えるのに良い情報だと思います。業務改革や改善の用語は第3章で触れていきます。

 

(それぞれの技術についての情報を筆者が年表にしたもの)

 

 

システムアーキテクチャーの考え方の流れは「集中⇒分散⇒集中⇒現在(2022年)はまた分散」とされています

 

出典:システム構成(集中と分散)の歴史<経営とIT<歴史<木暮仁 (kogures.com)

 

 

 

歴史の纏めです。大きなコンピュータ(汎用コンピュータ)が登場してそこに処理を集中していましたが、パソコンが高性能且つ安価になったのとサーバーの登場で処理を分散して設計していくようになりました。その後、データーベースやシステム間の連携を効率的に行えるような技術が次々誕生し、クラウドが登場してからはクラウドを上手く扱っていくのが当たり前となり、クラウドと社内システムの連携を効率的に行う必要が出てきました。クラウドを上手く扱っていくためのクラウドネイティブという考え方の重要性が増し、様々なデータベース、データ連携技術、ERPCRMがそれぞれ進化しており、それらを上手く活用して、近年会社内のシステムが再構築されていっています。クラウドの活用により、これまで社内の環境にだけ存在していた重要なデータが社外のネットワーク上に所持する使い方も増えており、セキュリティの考え方も併せて見直しがされています。

 

 

情報漏洩は自社ビジネスに与える影響が大きいため、各自特に気を付けましょう。新しい技術やツールを使いつつ情報漏洩を防ぐためにはセキュリティや技術に関する知識が一定必要になります。また、自分が時間を掛けて改善しようとしている事が、システム部門側で新規開発や改修している最中だった、、となってしまう事もありますので、会社の状況や方針を把握したり、システム部門と連携を取って進める事と新しい技術や製品を導入する際には、導入する事を目的とするのではなく、「解決したい課題や目指したい姿が何で、そのために製品や技術を使って解決する」という考え方が大切です。

 

 

 

 

第2章について

次は「会社内の主な業務や部署について」「バックオフィス、フロントオフィスの違い」「バックオフィスのシステムが進んでいる世界観」について説明していきます。会社のデータの流れや他部署との関係性(部門横断の視点)を把握するために必要な知識となります。

 

 

syachiku-inu.hatenablog.com

 

 

参考サイトに第1章で説明している情報の詳細情報が書かれていたりしますので、興味がありそうなサイトがあれば、是非確認して理解を深めていってください。

 

 

これまでの内容に関わるお勧めの書籍紹介

ITの歴史や上記の説明に関わるものでお勧めの書籍を紹介します。

 

①コンピューターってどんなしくみ?:デジタルテクノロジーやインターネットの世界を超図解 (子供の科学★ミライサイエンス)

コンピュータの仕組みやコンピュータ同士が繋がる仕組みや簡単な歴史、コンピュータの何が危険なのかわかり易いように書かれている子供向けの書籍です。コンピュータやネットワークの仕組みが全然分からないという方にとてもお勧めです。メモリ?CPU?OS?という方でもついていけます。楽しみながらITの基礎知識を学べます。ここに記載されている事が理解できると、ITパスポートの参考書に書かれている内容も理解し易くなるため、ITリテラシー向上の入り口としてお勧めです。

 

 

 

参考サイト

「IT関連の歴史」目次<木暮仁 (kogures.com)

IT部門の歴史的変遷<経営とIT<歴史<木暮仁

アーキテクチャ主導の企業情報システムへ~2014.3.3 第8回要求シンポジウム~(ipa.go.jp)

現場を極めたITアーキテクトが語る!「成功へ導く極意」 | 株式会社アイ・ティ・イノベーション (it-innovation.co.jp)

インターネット歴史年表 - JPNIC

monthly_somu2013_06.pdf (jmac.co.jp)

〇民間及び行政のアウトソーシングの考え方について

(http://www.ecpr.or.jp/pdf/ecpr10/32-37.pdf )

ワープロ専用機はなぜ廃れてしまったのか | kako blog

JPCERT/CCセキュリティインシデント年表
安全なウェブサイトの作り方 - 1.6 CSRF(クロスサイト・リクエスト・フォージェリ):IPA 独立行政法人 情報処理推進機構

IPA:IT アーキテクト育成ハンドブック第2版 (https://www.ipa.go.jp/files/000010253.pdf)

IPA 独立行政法人 情報処理推進機構:超上流から攻めるIT化の事例集:各社資料一覧

〇日本ITガバナンス協会:ITのアーキテクチャマネジメント(https://www.itgi.jp/application/files/7316/0862/6794/14IT.pdf)

読者10人と考えた「Excelレガシー」再生への道(2ページ目) | 日経クロステック(xTECH)

業務システムの歴史から考える RPA の未来①(1960年代~1990年代) - Enterprise Blue Ocean ◮ (ebocean.work)

ERP とは | エンタープライズリソースプランニングの定義 | SAP Insights

ERP導入の羅針盤 | JSUG -Japan SAP Users’ Group-

ビジネスとITを全体最適に導くEA(上):ビジネスモデリング事始(2) - ITmedia エンタープライズ

デジタル経営時代のEA(エンタープライズ・アーキテクチャ) - KPMGジャパン (home.kpmg)

ソフトウェア・シンポジウムのテンプレート (sea.jp)

総務省|令和元年版 情報通信白書|情報システムの進化

総務省 平成の情報化に関する調査研究

(https://www.soumu.go.jp/johotsusintokei/linkdata/r01_01_houkoku.pdf)

iPaaS といってもいろいろな種類があるので分類してみよう~レシピ型、ETL/ELT、EAI、ESB~ - CData Software Blog

Web発展の歴史とRESTの躍進 - 研鑽の日々 (hatenablog.com)

iPaaSの動向と将来予測|アクセンチュア

データベース 歴史 snowflake - Bing video

【シリーズ】知られざる、サイバーセキュリティの歴史 #1

トヨタ企業サイト|トヨタ自動車75年史|トヨタ生産方式|トヨタ生産方式の変遷

クラウド・ネイティブという考え方――これからのIT基礎知識 Vol.1 | Think Blog Japan

SOAとマイクロサービスアーキテクチャーの違い - Talend | Talend

18年後の惨状を完璧に予言したのに失敗したe-Japan戦略、DXも二の舞いだぞ | 日経クロステック(xTECH) (nikkei.com)

デジタルトランスフォーメーションの加速に向けた研究会 中間とりまとめ(METI/経済産業省)

ITR Market View:ERP市場2022 | ITR

【RPA(UiPath)】RPAの推進組織 CoE(Center of Excellence)について徹底解説!

今回はRPAを推進していく中央組織であるCoE(Center of Excellence)について、解説していこうと思います。CoEって何?どんな事をしているの?何故必要なの?どうやって作ればいいの?失敗事例は?成功のコツは?を知りたい方向けの内容となっております。現在CoEに関わっている方もCoEに携わっていない方も視野を広げる事ができると思いますので、是非今後の活動のご参考にして頂ければと思います。

 

f:id:syachiku_inu:20211211215136j:plain

 

【目次】

 

CoE(Center of Excellence)とは?

CoE(Center of Excellence)とは、組織を横断する取り組みを継続的に行う際に中核となる、部署や研究拠点の事です。RPAだけを横断的に取り組む組織ではなく、RPA以外の分野も中核として担っているケースもあります。また、組織横断的なクラウド管理や運用を行う「クラウドCoE」やAIに特化した「AICoE」やデータ管理に特化した「アナリティクスCoE」といったものも登場してきており、組織間の連携やナレッジ共有の重要性が新たな技術の進化によって、これまで以上に重要となっており、今後更に重要性が増してくる組織(役割)だと思います。CoEをインターネットで検索すると企業だけの情報ではなく、大学の研究機関のCoEが出てきたりします。

 

f:id:syachiku_inu:20211212140408p:plain

RPA CoE(Center of Excellence)の仕事内容

続いて企業におけるCoEの仕事内容をRPA版で説明していきます。現在のRPA CoEの仕事内容を私が全て書き出したものが下記のものになります。

 

f:id:syachiku_inu:20211211222541p:plain

RPA CoEの場合、RPA化を検討する際に、RPAでやる必要があるのか?システム改修や他の手段で解決した方が良いのではないか?を検討するため、BPR(ビジネスプロセスエンジニアリング)やBPM(ビジネスプロセスマネジメント)に関わる事もあります。「なんのためにRPAを使うのか」「自社のIT戦略にどう紐づくのか、達成基準は何か」の戦略検討からリスク対策、必要なルール作りや組織運営、各種管理や啓蒙活動、開発者のフォローまでかなり多岐に渡る業務内容を多くの関係部署とコミュニケーションを取って進めていく必要があります。一人でこれらを行っている猛者もいらっしゃるようですが、規模の大きさに応じて適切な人のリソースを割く事が必要となります。

 

上記作業を行うのにどのような職種の人達が必要になるかは下記UiPathの公式サイトに説明ありますので、こちらをご参照下さい。

 

www.uipath.com

 

推進者がいない/不足しているとどうなってしまうか

上記のような推進者がいない又は組織がない場合どのような事になってしまうのかを説明していきます。下記によく起こる問題を8つ例で記載しておりますが、複数部署で同じ失敗を繰り返す等問題が発生して、導入や運用が上手くいかなくなったりします。最終的にはこれらの問題が積み重なってくると、RPAを上手く活用する事ができず、取り組みが一旦中止や終了してしまう事に繋がります。

 

f:id:syachiku_inu:20211211224823p:plain

 

上記のようなケースを事前に防ぎ、発生し始めた際に事後対策を行い、部門横断的に成功/失敗事例の共有や管理を行っていく事で、RPA導入を成功に導く人や組織が必要となってきます。それがRPAを推進する組織であり、CoEとしての役割・責任となります。

下記に上記の問題に対する対応例を赤字で紹介します。真の原因や状況によって、対応の方法は変わってくるため、この対応例が絶対の正解というものではないです。対応の例として参考にして貰えればと思います。

 

f:id:syachiku_inu:20211211225436p:plain

 

RPA CoEの組織の構築パターン

RPA CoEの組織をどうやって作っていくかのパターンについて、説明します。構築パターンは大きく下記のパターンが存在します。

 

モデル① ボトムアップモデル(部門主導・分散型) 本来CoEとは呼べないもの

各部門が主体となって、業務改革を実施しその手法の一つとしてRPAを利用。全体管理している組織は存在しておらず、各部門間で連携が必要な部分は連携していく必要があるモデル。

 

モデル② トップダウンモデル(CoE主導・集中型)

情報システム部門や専門組織が業務改革を部門横断的な視点も持って行い、その手法の一つとしてRPAを利用。CoEが開発、運用、保守などを全て行うモデル。

 

モデル③ ボトムとトップダウンのハイブリットモデル

上記①に加えて情報システム部門や専門組織が業務改革を部門横断的な視点も持って行い、その手法の一つとしてRPAを利用。CoEと各部門間で役割と責任を分担して、開発、運用、保守をしていくモデル。

 

【各モデルのメリット・デメリット】

f:id:syachiku_inu:20211219180405p:plain

 

各部門主導のみに任せていると、部門毎にルールが統一されていなかったり、成功/失敗事例が共有されていなかったり等の問題が起きるため、全社CoEを設置しない場合はナレッジ共有やコミュニケーションが取りやすい環境を早い段階で用意する事は重要です。モデル①は冒頭のCoEとは?で説明している「CoE=中核となる、部署や研究拠点の事」とは言えないので、CoEのモデルとは言えないと考えます。

 

RPAを自由に扱わせる事にセキュリティ面等で懸念がある場合は、仕組み的に事故を起こさないように機能を制限を行う、又は監視する仕組みが整備できるまでは、全社CoEのプロ開発者が開発を行う方法を取る選択肢の候補が高くなる傾向があります。RPAを従業員のITリテラシー向上や組織文化の改革の一環で使ってもらう事を目的としている場合、ハイブリットモデルで、全社CoE側でトレーニングやリスク対策を行うか、部門内でもこのような活動が行える人の下で利用を許可する等が必要になってきます。

 

最初はモデル①で始めるのは良いと思いますが、他の部署でも使っていこうという動きがあったり、他の部署も使った方が良いという判断になったりした場合は、全社CoEの役割を会社内に持たせる事は、RPAの取り組みを成功させるためには非常に重要なポイントになります。全社CoEが無い場合、前述で記載されているような問題が発生し、会社内で混乱や問題が起きてしまう事に繋がります。ずっとモデル①のままでは、CoEとしての役割を果たす事は非常に難しいため非推奨と考えます。

 

上記のパターン以外の観点として、全社CoEを立ち上げる場合に新規の組織として立ち上がるか、既存の部署に役割を追加するかの判断が必要になってきます。既にDX推進組織がある場合や情報システム部門に最新技術の推進の役割を持たせる組織構成にする場合、既にある組織内に役割を追加する事もできます。新規組織として立ち上げた方が新しい取り組みは進めやすい一面がありますが、情報システム部門と密接な連携がRPAのCoEは必要になってくる場合が多いため、情報システム部門との関係性が良好である必要があります。新規か既存組織かどちらにCoEの役割を持たせるかは、CoEの仕事内容紹介で上げているような作業を自社だと新規と既存のうちどちらの方が上手くやっていけるか考えて決めていく必要があります。


下記キーマンズネットさんの記事の中で、RPA推進をどこの部署が担っているかのアンケート結果の記事があり、その中では情報システム部門が半数以上で一位、続いて利用部門が3割の結果となっています。利用部門に全て任せるモデル①のままでいるのは前述で記載している通り非推奨となります。ある程度の規模になり、部門横断的な役割が必要なタイミングでCoE機能を組織に取り入れる事を開始する事をお勧めします。「Power Automate for desktop」の登場で、RPAのルールについてや扱い方の問い合わせが現場から上がってきている企業は多くあるのではないでしょうか。今後これらのツールを上手く扱っていくためには、どこかにCoEの役割を持たせる必要性が出てきます。

 

RPA導入成功と失敗の差はどこで生まれる? 導入企業から学ぶ“転落ポイント” - キーマンズネット (itmedia.co.jp)

 

 

上記のモデル②、③を決めたら、更に何を誰がどこまでやるのか、許可させるか、責任を持たせるかを決めていく必要があります。決めずに運用していくと、プロセス毎に運用のやり方や責任範囲が違ったりして、保守・運用が複雑化して属人化の原因になったりかなり大変になったりします。結局再整理しないとどうにもならない状態に最終なってしまう可能性が高いため、早い段階で関係者の役割や責任範囲を定義して進めていく事が重要です。一度決めたルールに修正が必要であった場合、見直せばよいのですから。一番初めから完璧な組織やルールを作る事はほぼ無理なのではないかと思います。モデル②からモデル③に徐々に広げていくやり方もあります。

 

役割の決め方のサンプルはRPA 総研さんの下記記事に存在しておりますので、こちらを参考にして頂くのが良いと思います。

rpasouken.com

 

f:id:syachiku_inu:20211219184534j:plain

 

起きやすいCoE構築の失敗事例

起こりやすいCoE構築の失敗事例を紹介していきます。

 

事例①:必要なスキルを持った人材が揃ってなく、どこかで重大な問題が起きる

例えばOrchestrator導入をオンプレ環境に構築したが、サーバーやこのようなアプリの扱いに慣れている人(インフラの知見や技術を持った人)をチームに参加させなかったり、基盤チームに依頼しなかったりして、初心者にやらせて問題が起きてしまう事があります。

⇒やりたい事に対してどんなスキルが必要になるのか検討して不足している役割がある場合、人が育つまでに一時的にも詳しい人に参画して貰うか、外部の力を借りるか検討が必要ですプロセス数が増えてから、整備していく事はとても労力が掛かります。

 

事例②:CoE推進リーダーが他の業務と兼務して、多忙になり問題が起きる

⇒部門CoEは規模と役割に応じて、兼務も可能かもしれませんが、全社CoEとして本気でRPAに取り組んでいくのであれば、リーダーを兼務させる事はマネジメントが疎かになったり、スピード感が落ちたりするため、お勧めしません。またリーダーはプロジェクトマネジメントの経験者であることが望ましいです。

 

事例③:部門との役割や責任範囲が不明確で、CoE業務が複雑化する

⇒開発のフェーズでCoEと業務担当者は何の作業を行うのか、何に責任を持つのか、ロボットをリリースした後、誰が正常/異常の確認を行うか、障害時に誰がどこまで何を対応するのか、標準を整えていかないと、プロセス数が増えていくにつれて運用が複雑化し、保守/運用に多くのリソースが取られていくようになってしまいます。

 

事例④:開発を担当(実施者)のエンジニアに丸投げする

丸投げにより、各開発者に好きなように開発や運用をさせて作業が属人化する。

CoEは品質を一定に保つ事や、標準化する責務があります。丸投げはやめましょう。   

 

事例⑤:ルールやガバナンスを厳しくし過ぎて開発が進まない、工数が多く消費される

一番始め方から完璧な姿を目指し過ぎて、ルールや制約が多すぎて新規参画者が増えなかったり、自分には無理だと諦めてしまったりする人が続出して、広がっていかないケースです。

⇒一番始め方から最適解のルールや運用を作る事はほぼ不可能だと思います。ですが、何も考えずにツールだけばら撒く事もリスクだらけになるため、非推奨ですどんなリスクがあるか考えて、ここだけは死守する。そのために何が必要か更に考えて、対策を実施しつつ最適なルールや運用を作っていく事が重要になります。開発者のレベルに応じて扱っていい業務範囲を絞り、レベルに応じて守るべき規約やドキュメント粒度を変える等の工夫が必要です。

 

RPAの開発や実行時によくあるリスクの情報を別の記事で纏めていますので、どんなリスクが起こりうるのか詳細知りたい方はこちらの記事も参考にして頂ければと思います。

 

syachiku-inu.hatenablog.com

 

 

 

事例⑥:反対意見を基本無視して無理やり推進していく

改革や改善を行う際に、反対勢力は必ずといって出てきます。しかし、この反対勢力は全てが敵ではなく、反対勢力の中には、ちゃんとした理由を持っていて、会社をよくするための意見を持っている事があります。これらの意見を全く聞かずに無理やり導入していくと、意見を聞いていたら事前に対策できた事で大きな失敗をしたり、中々広がっていかない原因にも繋がってきます。それが原因で優秀な人材が会社を離れていってしまうケースもあります。反対している勢力は何故反対しているのか、反対理由を何か対策する事によって、肯定的に変える事はできないのか、向き合う事でより良い結果に繋がる可能性が高まります。

 

IT分野を中心とした調査/助言を行う企業で有名なGartnerが避けるべき自動化の誤りを10個公開しておりますので、こちらの情報も参考にして頂けると良いと思います。

 



www.gartner.com

 

 

f:id:syachiku_inu:20211219184853j:plain

大きく成功しているCoEの共通成功要素

続いて私の考える大きく成功している企業の共通成功要素を紹介していきます。

 

成功要素①:RPAを使った明確なビジョンや目的が存在し、関係者に浸透している

これは様々なメディアが口を揃えていっている事ですが、私も一番大事な事だと思います。「RPAを使って、現状をどう変えたいのか、将来どうなりたいのか、そのために何をするのか」を考え、その目的が伝わっていないと、人はついてきません。また間違った目的で使い始めていく人達もでてきたりもします。RPAに関わる人達が「RPAの取り組みを成功させたい」という気持ちを持っているか否かは非常に重要なポイントになります。全員は難しくても各現場のキーマンは必ず目的意識を持っている必要があります。概念検証や事例を参考に現状のRPAでやれる範囲、やれない範囲を見極める事も重要です。扱いになれていないのに、いきなり大きな最適化やリスクの高い業務を自動化しようとすると高確率で失敗します。

 

 

成功要素②:優れたリーダー、PMの存在

優れたリーダーやPMがいる場合、起きやすい失敗事例を事前に対策して防いだり、上手くいかなくなり始めたら、軌道修正したり、成功要素を知らずとも軌道修正できていたりします。この優れたリーダー、PMはITにすごく詳しい人でなければいけないわけではなく、ビジョン/目的等戦略を考えられ、時代の流れに対してのアンテナが高く、会社/組織の事を真剣に考えていて、コミュニケーションや交渉力に長けており、情熱を持っている人であると考えます。会社内で人望が厚い、各所のキーマンと直接話せるような人だと更に適任です。(チーム内にITに詳しい人は必要です)

 

成功要素③:成功要素①を達成するために必要な人材を定義して組織を作っている

決めた目的を達成するためにどんな人材が必要であるかを考え、CoE組織を作っていく必要があります。成功している企業は、現状と将来に必要になる人材を考えて、採用や育成をして、外部に任せる部分を定義してパートナーやコンサル企業に上手く利用しています。重要な作業が自社だけの力で解決できない場合、外部に早めに頼った方がトータルのコストは安く収まるケースが多くあると感じます。

 

成功要素④:現場に寄り添っている、組織間の風通しが良い

現場から自動化要件をヒアリングするにしても、現場に開発できる存在を育成して市民開発の取り組みを始めていくにしても、現場の状況を考慮したり、相談し易い環境を整えたり、現場の人の事を考えて推進したり、ちゃんと現場の人と接する事で信頼も得られ、協力的になり取り組みを上手く進んでいる組織は多いと感じます。自動化の依頼をくれる人達(業務担当者)を「内部顧客」として定義し、内部顧客の満足度を向上させる事に意識していく事で、上手く連携や関係者のバランスが取れていけたりもします。社員全員が顧客志向で働く事は難しいため、この業務担当者を「顧客(内部)」と見立てるのは良い対応だと思いました。内部顧客の満足度が高くなる事で、結果として外部顧客へのサービスの質の向上にも繋がると思います。

 

成功要素⑤:各関係者が情報共有やコミュニケーションが取れる場所が存在する

どこかの部署で困って解決した事は他の部署でも同じように困っているケースが多いです。Windows等のOSや共通で使っているシステムが絡んでいると、同じ問題が起きます。この時に情報を共有し合ったり、どこかで解決した内容をナレッジとしての共有する事で、生産性が向上します。「このまま進んで大丈夫かな?」と担当者が悩んだ時に相談できる環境が整っている事で、そのまま進んでいたらセキュリティ事故やその他のリスクを起こしてしまう可能性がある事を未然に防ぐ事ができている組織のケースもあります。リスクを未然に防ぐ観点でも、相談できる環境がある事は重要です。

 

f:id:syachiku_inu:20211219185013j:plain

これからのRPA CoEの行方

これまでパソコンやインターネットの登場で技術革新が起き、働き方が大きく変わっていった時代がありました。現在ここに更に新しい技術の登場により、また働き方が変わってきている時代になってきています。

 

f:id:syachiku_inu:20211215231227p:plain

 

RPAについては、AIとの連携がもっと進む事で下記のクラス3へ進化していく事が予想されます。RPAのCoEチームは今後このような更に高度なRPAをどう扱っていくか考え、導入の推進をしていく役割を担っていくと考えられます。UiPath社は2021年の自社イベント「UiPath Reboot Work Festival」でロボットが業務を自己学習する「セマンティック・オートメーション」の世界観を発表していました。今後自動化可能な範囲や開発の容易さが更に向上していくかもしれません。UiPathはこれまでずっと製品成長スピードが速かったですが、今後もしばらくはこのスピードに付いていくのがCoEとしてまず必要な事かなと思います。バージョンアップを無理に急がず状況を把握して、追加された機能は必要なものなのか判断したり、利用タイミングを調整したり他の技術や製品の状況を把握して、ソリューションを見直す事が必要になってきます。

 

f:id:syachiku_inu:20211215232017p:plain

【引用元:総務省|情報通信統計データベース|RPA(働き方改革:業務自動化による生産性向上) (soumu.go.jp)

 

技術革新はRPA以外にも起きており、RPAのCoEと同じような先端技術を推進していく組織が複数新たに立ち上がったり、既存の組織に役割として追加されていったりする事も考えられます。直近でいうと2022年のガートナーの戦略的テクノロジーのトップ・トレンドで上がってきているような技術を推進していくような役割が新たに追加されていく流れになっていくと思います。いきなり難易度の高い事は失敗する可能性が高いので、これからRPA以外でも必要になってくる可能性が高い、CoE(役割)の組織を予め作っておく事は、今後の先端技術活用の部分でも優位に立つ事ができる部分だと思います。

 

f:id:syachiku_inu:20211215232538p:plain

 

RPAは上記のトレンド内の中では「ハイパーオートメーション」の中に位置しています。ハイパーオートメーションとは「可能な限り多くのプロセスを迅速に特定し、検証し、自動化することにより、成長の加速とビジネスのレジリエンス向上を実現する取り組み」の事で下記の様な技術要素で構成されると言われています。UiPathを軸に考える事ができるものも多くあるため、今後RPA CoEに関わってくる可能性が高いもの(既に他チームが推進している可能性も有)と考えられます。ハイパーオートメーションの世界観やどれが現在のUiPathに存在しているものなのか等は別途解説の記事を書こうと思います。将来的に全てUiPathのカバー範囲となる事は可能性としてゼロではないかと思います。

 

f:id:syachiku_inu:20211220115041p:plain

 

RPA CoEのお役立ち情報

RPA CoEを既に推進されている方やこれから作っていく方、チームに参画する方が知っておくと便利なお役立ち情報を紹介していきます。(無料で凄い情報が手に入る恐ろしい時代、、)

 

①「UiPath公式 導入メソドロジー2.0」 おすすめ度 ★★★★★(5)無料

UiPath社の公式が出している方法論とドキュメントテンプレート集です。UiPathを導入した先人達のナレッジをUiPath社公式が集約し、「同じ苦戦をする企業を減らしたい」「ドキュメント部分の時間を効率化したい」という思いで作られているドキュメントだと思います。下記のようなフォルダ構成に分かれており、戦略立案やガバナンス構築、PoCからプロ開発、EUCそれぞれで役に立つ情報が纏められています。これが無料で提供されているのはすごい事だと思います。ヒアリングや自動化した業務を管理する一覧や課題管理表まで揃っています。これらのドキュメントをカスタマイズして使っていくのがお勧めです。足りない観点やドキュメントも存在したりするケースもあるため、現場に応じて新規で新たに作ったりする事や必要なドキュメントを取捨選択する事も必要です。UiPath以外の利用は規約で禁止されているので、注意が必要です。

 

 

【UiPathメソドロジーフォルダ構成】

f:id:syachiku_inu:20211219114827p:plain

【03_UiPath導入メソドロジー(プロフェッショナル開発)フォルダ内】

f:id:syachiku_inu:20211219114758p:plain

 

「参考資料」内に入っている資料は戦略的にRPA展開していく事について説明されているドキュメントが入っています。UiPath TodayのPick UPコンテンツにずっと配置されているアーカイブ動画の下記2つの内容がドキュメント化されて格納されています。CoEのチームに入る方は是非見て頂きたい内容です。資料だけではなく説明も聴きたい方はUiPath Todayを参照下さい。

f:id:syachiku_inu:20211219115322p:plain

 

www.uipath.com

 

 

②「UiPath公式 RPAガバナンスガイドライン(第二版:2020年12月)」 おすすめ度 ★★★★★(5)無料

RPAを安全に導入や運用していくために気にすべき事や対策の立て方について、細かく説明されているRPAガバナンス(管理)構築のためのガイドライン(指針)です。UiPath社とPwCあらたという有名な監査法人の企業が共同で発行したものです。UiPathメソドロジーはこれからの観点を考えて作られているドキュメントではありますが、メソドロジーのドキュメントを修正したり、ルールを変更したりしていくためにはこれらの大本の知識や考え方も必要になってくる事もあります。CoEのルールやドキュメントを管理するような役割の人には読んで頂きたいものです。これを理解する事でリスク対策やコントロール能力を結構上げる事ができ、今後RPA以外の仕事についた時も役に立つと思います。RPAに関わる全員に知って貰いたい内容を「2_RPAガバナンス-ハンドブック_v2.0.pdf」に絞って纏められていますのでそれだけでも読んでみると良いかもしれません。

 

【RPA全体】

f:id:syachiku_inu:20211219120431p:plain

【UiPath活用時のサンプル】

f:id:syachiku_inu:20211219120725p:plain

 

www.uipath.com


③「日本ITガバナンス協会 -ITGI Japan」 おすすめ度 ★★★☆☆(3)無料

ITガバナンスのベスト&グッドプラクティス及び知識や研究成果を公開しているITガバナンス協会(ITGI, IT Governance Institute)のサイト。RPAガバナンスだけではなく、そもそもITガバナンスを知らず、既存のガバナンス把握から必要なような方向けにITガバナンスの理解をより深めるのに役に立つ情報です。

 

itgi.jp

 

④「UiPath公式 RPA導入プロジェクトの品質評価キットUiPathデリバリーアセスメント」おすすめ度 ★★★★☆(4)無料

自分達の会社のプロジェクトは考慮すべき観点を考えて、計画して実践できているのか、開発において一定ベストプラクティクスに近い状態で開発できているのか、を自己チェックするためのドキュメントです。こちらも観点足りないと思えばカスタマイズする事でより詳細なチェックを行う事もできます。定期的(半年~1年)くらいにチェックして、どこを改善したら良いのか、優先すべき整理検討事項はどこなのか、以前と比べてどこが成長したか等を確認していくと、目に見えて改善された点や足りていない部分の可視化を行う事ができます。

 

「チェックしてみたけど、どう改善していけば良いか分からない」や「現在の状態を見直す時間が取れない」ような状況である場合、パートナー企業やUiPath社の担当営業の方に相談すると費用は掛かってしまう可能性がありますが、チェックして改善点を提示してくれる事が可能だと思いますので、外部の力をここで使うのは、お金があれば結構お勧めです。

 

www.uipath.com

 

⑤「UiPath公式 UiPath Today (公式ウェビナー。アーカイブ配信有) 」おすすめ度 ★★★★☆(4)基本無料
UiPath社の公式ウェビナーサービスです。最新製品やRPAの進め方説明や事例展開等幅広い事を説明やディスカッションしているウェビナー公開サイトです。CoEに役に立つ有益な情報も公開される事があるため、月一位でチェックしてみると良いかも知れません。現在は無料動画だけの公開になっていますが、今後有料動画の公開も出てくるかもしれません。

uipath-today.eventos.tokyo

 

⑥「UiPath公式 オートメーションの百科事典(英語) 」おすすめ度 ★★★☆☆(3)無料

UiPath本社のCoEが自動化した事例を整理して公開しているものです。各部署毎に事例が整理されており、CoEや各部署ではどんな事を自動化しているのか、を把握するのに非常に役に立ちます。四半期毎に情報を更新されていく予定だそうです。

 

view.highspot.com

 

上記のサマリーは四半期毎に公式ブログに公開されていっています。

www.uipath.com

 

⑦「政府CIOポータル デジタル・ガバメント推進標準ガイドライン」おすすめ度 ★★★★☆(4)無料

日本の政府のドキュメントになりますが、そもそもRPAガバナンスの前にITガバナンスって何?とかどんな事を考えて中長期計画立てていくのかや、各フェーズの進め方や注意点が纏められており、基礎知識や考え方の部分でとても参考になるドキュメントです。プロジェクト管理をするCoEのリーダークラスの方にお勧めです。リーダークラスではない人はITの導入部分のポイントを絞って実践的に使えるように用意された「デジタル・ガバメント推進標準 ガイドライン実践ガイドブック」をまずは読んでみると良いです。リーダーの人が何を気にしているか上位視点を知る事もできます。

 

「デジタル・ガバメント推進標準 ガイドライン実践ガイドブック」の中に「RPA導入実践ガイドブック」というものも存在します。RPAの概要や特徴、他技術との違い、導入の方法論が一つのドキュメントとして纏められています。誰かに教えたりする際や、自分の理解を深めるのに活用すると良いと思います。

 

これらはUiPath関係なく全RPA共通の事項が纏められている情報ですが、UiPath社はこの「RPA導入実践ガイドブック」に記載されている考慮事項に対して、UiPath社自体や展開している製品群がどのように対応しているかの見解やUiPathの詳細情報を調べられるようにリンク情報を付けた対応一覧の情報を公開しています。UiPathはどう対応しているのか調べる時に役に立つ情報です。気になる方は見てみると良いです。

 

www.uipath.com

 

cio.go.jp

 

⑧「リエンジニアリング革命」おすすめ度 ★★★★★(5)有料

BPR(ビジネスプロセス・リエンジニアリング)とは何なのか、リエンジニアリングについて最初に定義されたと言われている書籍です。内容は色あせない原理・原則が中心に説明されており、「古い原則から離れて、新しい原則を取り入れる」というリエンジニアリングの考え方は現在のDXとも共通する部分は多くあり、その概念・本質を理解する事ができるもので、業務改革や改善に関わる方は知識としてINPUTとしておいて損はない書籍だと思います。かなりお勧めです!

 

 

⑨「プロセス・イノベーション」おすすめ度 ★★★★★(5)有料

⑧「リエンジニアリング革命」の邦訳が発刊された翌年に邦訳された書籍。そもそもプロセスとは何なのか、現行プロセスの把握と改善方法や代表的なプロセスのイノーベーション戦略例の紹介があったりと、実践的な内容が多く記されています。個人的に⑧「リエンジニアリング革命」を読んでから更にこちらの「プロセス・イノベーション」を読む事で、リエンジニアリングについての理解や自分がこれからどう活かしていくか考えが整理しやすいと感じました。こちらも業務改革や改善に関わる方は知識としてINPUTとしておいて損はない書籍でかなりお勧めです!

 

 

⑩「図解CIOハンドブック 改訂5版」おすすめ度 ★★★☆☆(3)有料
企業の情報システム担当者(責任者)、経営者向けのIT活用の最新実務書です。RPA CoEよりも上位の組織や人がどんな役割を持っていて、どんな事を考えているか概要を抑える事ができます。CoEリーダーレベルの人が更に上位視点を知るために活用すると良さそうな書籍です。

 

 

⑪「抵抗勢力との向き合い方」おすすめ度 ★★★☆☆(3)有料
改革や改善を行う際に、必ずといって存在する抵抗勢力。この勢力との向き合い方について、説明されている書籍です。抵抗勢力に何故ちゃんと向き合う必要があるのか?やどう対処していけば良いかの参考になる書籍です。

 

 

 

⑫「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」★★★☆☆(3)有料
CoEのリーダーにアサインされたけど、どうやって組織を作り、管理していけば良いか分からない。ITプロジェクト経験した事がない!という経験が浅い人向けにチーム作りの進め方を実践的に説明している書籍です。組織作りの参考に良いです。

 

 

⑬「人事・教育担当者のための 能力開発・教育体系ハンドブック」★★★★☆(4)有料

RPAを展開していこうとした時に、どう教育していくかを考える時があります。全社的な取り組みで人事部も巻き込んで、人事制度を変えるところまで進んでいない場合は、CoEの誰かが研修プログラムを作ったり、教育体系を整理したりする役割を担う事が多いです。こちらの書籍は人材育成方針、能力開発・教育体系、教育計画づくりのための取り組み方や具体的な進め方・手順等の概要を抑えられるような構成で作成されており、一通り読んでおく事で、優れた研修プログラムや先を見据えた教育計画を立てるのに役に立ちます。教育担当の方やCoEリーダーの方にお勧めの書籍です。

 

 

⑭DX白書2021

情報処理推進機構が公開しているIT社会の動向を調査・分析して情報を整理してくれているレポートです。世の中のIT活用はどうなっているのか把握したり、RPAやローコード、ノーコードの活用目的をどうしようか考えたりするための知識として有益なものだと思います。

 

www.ipa.go.jp



f:id:syachiku_inu:20211219185055j:plain

 

さいごに

RPACoEのリーダーには、既存組織に役割を追加する場合も、新規組織で立ち上げる場合も、組織作りやチーム作りの能力がリーダーには求められてきます。また、業務の人に開発まで任せていきたい(市民開発)場合、教育の観点やこれまでの企業文化の改革が非常に重要になってきます。今回紹介している内容は概要レベルで、推進をやっていると様々な細かい課題や問題に遭遇します。小さな失敗をしないで、完璧に進める事は非常に困難であるため、致命的なリスクを避けつつ思考錯誤しながら推進し、自社にとってのベストな推進の形を目指すための参考情報として、これまでの情報を活用して頂ければと思います。

 

難易度が高いお仕事ではありますが、人の成長に関わる事ができ、自分自身も様々な能力やスキルを身に付けたり、伸ばす事ができる、とてもやりがいを感じられるお仕事だと思います。チャレンジできる環境があれば、是非チャレンジしてみると良いと思います!

 

自動化を専門の仕事をやっていると人によっては自動化第一主義になってしまう事もあるため、「仕事(プロセス)」と「人」と「テクノロジー」にそれぞれちゃんと焦点を当てて、どれかに思考が偏りすぎないように注意しましょう!「なんでもかんでも自動化!自動化が偉いんだ!協力しろ!」では人はついてきませんし、達成したい目的もおそらく達成する事は難しくなってきます。

 

 

「推進者の仲間がほしい、、」「孤独でつらい、、」という方は、UiPathのユーザー有志によって運営される非営利の公式ユーザーコミュニティであるUiPath Friendsに参加してみるのをお勧めいたします。私も所属しています。下記の記事にコミュニティとしてどんな活動をしているか把握できるものがあります。2022年からCoEトークという取り組みが開始されるみたいです。

 

note.com




CoE以外にもUiPathに関わるノウハウを記事で纏めていますので、気になるものがあれば、是非参考にして貰えればと思います。

 

syachiku-inu.hatenablog.com

 

参考サイト

・RPA総研:RPAプロジェクトに必要なCenter Of Excellence (COE)組織とは? (rpasouken.com)

 

・デロイトトーマツRPA and Intelligent Automation|アナリティクス&コグニティブ|デロイト トーマツ グループ|Deloitte

ZDNet Japan:DXマネジメントオフィス入門 - ZDNet Japan

【RPA(UiPath)】障害対応のノウハウを知り、障害対応レベルをあげよう! 調査~対処編

今回はRPAの障害発生時に調査方法が分からないから詳しい人に頼るしかない方や、調査方法のコツを知らなくて手探りで調査をして中々原因にたどり着く事ができないという方向けの記事となっています。

 

原因にたどり着ける人は何故それができるのかを説明していきます。できる人が行っているコツやノウハウを知れば、システムにそこまで詳しくなくても難易度の高い障害以外は原因特定までたどり着く事が可能だと思います。

 

障害は「モノ・ヒト・コト」起因で発生するものがあり、実際にシステムを使っている側の方が障害の原因に早く辿り付く障害パターンも存在します。コツを知り、システム担当者-業務担当者間で協力して障害に対処できる現場は障害解決速度が早いです。この記事を見て調査協力できるようになったり、自身の障害対応レベルをあげていく事に繋がったりして貰えればと思います。

 

f:id:syachiku_inu:20210904224105j:plain

 

【目次】

 

障害発生から対応までの基本的な流れ

まず、障害発生からの基本的な流れを説明します。障害は発生直後に、調査や業務に影響を出さないように一次対応を行います。その後、原因を調べて対策を検討及び対策実施して事象改善されれば完了です。今回は調査から対策実施までを中心に説明していきます。再発防止策も気になる方は最後の参考サイト一覧にリンクを貼っておくので、リンク先の詳細情報をみて頂ければと思います。

f:id:syachiku_inu:20210904224330p:plain

 

障害が起きる前の事前準備について


障害の調査や対処ができる人は、自身が関わるシステム関連の下記記載の事について事前に調べて整理しています。自身が関わった事のないシステムの保守・運用担当になった時に下記が分かっていないと対処が遅れるため、障害に備えて事前に把握しています。

 

<最低限必要な事>
①関連システムと確認すべきログの場所と見方を把握
②関係者や業務への影響を把握

 

関連システムと確認すべきログの場所と見方を把握

下記は一例ですが、どのようなインフラ(パソコンやサーバー、ネットワーク)が関連し、どのような流れでデータのやり取りがされているかを把握します。これを把握している事によって、影響範囲を特定可能にします。障害調査には問題が起きている状態とログに書かれている内容から原因を探る事が多いです。

 

f:id:syachiku_inu:20210904224728p:plain

 

問題が起きている状態とは操作しているパソコン上でエラーが起きているなら、その時のパソコンの画面や起動中のアプリケーション等の状態の事を指します。システムは異常時にエラーである事を調査可能にするためにログ(文字)に出力しています。ログに出力されない障害もありますが、「まず状態確認とログを見る」が基本的な対応方法であるため、状態に加えログが出力されている場所と確認方法を事前に把握します。

 

業務担当者の方は、パソコン側の概要知識と確認すべきログの場所と見方だけ把握していれば十分だと思います。これから詳細説明していきますが、業務担当者で実際に修正に関わっていない人は「そんなことをやっているだな」感覚で見て貰えればと思います。システム担当者は自身が関わる部分は全て把握しておく事をお勧めします。

 

関係者や業務への影響を把握

障害が起きた時は、業務担当者や複数のシステム管理担当者と連携して対処する事が求められる事があるため、誰に連絡を取れば良いか把握を行います。また、どれくらい影響が出るもので、いつまでに復旧しないといけないのか、業務への影響も把握します。これを把握する事で、一次対応をどう進めていくか適切に対処する事ができます。業務担当者は急いで対処しないと大変な事になると思っているのに、システム担当者はゆっくり対処しても問題ないと思っていると温度感の違いによって、対処に失敗してしまう事があるためです。

 

お互いの認識があっているか確認ができていない場合は、障害前に確認を行いましょう。本来はRPA化を検討する際に障害時にどうするかの認識はあわせておくべきです。


業務担当者とシステム側でこのようなサービスレベルの認識合わせをする項目は復旧優先度以外にも存在します。詳細を知りたい方は下記非機能要求グレードを見ると何を気にしないといけないのか把握できます。システム担当者は必ず知っておいたほうが良いです。

 

www.ipa.go.jp

 

最低限抑えるべき事を説明しましたが、障害対応レベルを更に向上させるためには下記のような事を更に行います。習得に時間が掛かるためシステム担当者向けです。業務担当者の方は「ここまでやると更に詳細まで調査できるのか」と流し読みして貰えればと思います。

 

<障害対応レベルアップに必要な事>

①関連システムとの通信や連携の流れと技術を知る

②事例と対処の例を知る、経験する

 

関連システムとの通信や連携の流れと技術を知る

関連システムとログの場所だけではなく、更にどのように連携されているのか、どんな仕組みなのかを知る事で、ログに書かれているエラーメッセージをインターネットで検索して対処が見つからない場合でも自身で原因を調査して対応を進める事ができます。第一段階は流れを知る事です。その後パソコン側を中心に仕組みの概要を知り、最後に詳細を理解していくと良いです。そうする事で障害原因がパソコンから見て外部にある問題である事に気づけたり、どこで問題が起きているのかまで特定可能になります。仕組み的に考えておそらくこういう問題が起きているだろうという予測もできます。かなり詳細まで把握していくと頭の中でトレース(追跡)して、異常が起きそうな所を特定するような事ができるようになります。幅広い基礎知識が前提として必要になるためITパスポートや基本情報技術者の学習をすることで基礎部分を理解できるようになります

 

f:id:syachiku_inu:20210905180131p:plain



事例と対処の例を知る、経験する

関わるシステム障害の事例を知る事で、同じ事象であればすぐに原因まで辿り着き、類似事象である場合はその事に気づく事ができます。UiPathであれば、コミュニティフォーラムに障害事例と対処の情報が大量に存在しています。一通り目を通すと問題解決までの思考力がかなり向上します。また、障害を未然に防ぐ対策力もあげる事ができます。

 

forum.uipath.com

 

 

f:id:syachiku_inu:20210904230615j:plain

調査、情報収集及び一次対応

 

障害が起きたら、事象と影響を確認して業務に極力影響を出さないように一次対応を実施します。一次対応は発生した時に「どうしよう」と考えるのではなく、「このシステムが止まったらこういう対処をしよう」「この処理で止まったらこういう対処をしよう」と予め決めておかないと一次対応が求められる場合に、誤った判断や対処をしてしまいます。このような事にならないように、事前に方針や手順を決めておきましょう。細かく決めすぎると作成に時間が掛かるため、障害時に業務影響出さないレベルの粒度を考えて作成しましょう。

 

 

過去発生した障害の事象と対応結果を障害一覧に残しておく事も非常に重要です。その一覧があれば同じ障害が起きた際に、過去起きていないか一覧を検索し、対処方法も残しておけば、すぐに対処する事が可能になります。担当者が会社を休んでいない時もどのような時にどう対処するか他の人が分かるようにしておく事で対処を進める事や過去の障害傾向から同じ障害を起こさないようにするための対策を検討する事もできます。

 

 

先ほど説明している通りに状態を後で確認できるようにしておく事も大事です。RPAではエラー発生時の画面全体をキャプチャで取得しておくと、原因特定に役に立ちます。RPAのプログラム内でエラーが起きたらキャプチャ取得まで自動でするように作っておくと良いのですが、重要情報がキャプチャに移り込む可能性がある業務に対しては、キャプチャ取得を自動でしない作りにあえてしているものもあるため、自動取得できていないようであれば、取得できる人がしておきましょう。調査依頼する時にキャプチャと対象ログを一緒に送ってあげると原因に早く辿り着けます。

 

UiPath、Windowsのログの出力場所

UiPathのログは規定を修正していなければ、「%LocalAppData%\UiPath\Logs」に出力されます。%%で囲われているものは環境変数といって、パソコンにログインしているユーザ等によって値が変わるものに対応するためのものです。この%%のまま検索して選択するとログが保存されている場所に移動できます。移動先の「Execution.log」が実行された時に出力されるログです。

 

f:id:syachiku_inu:20210905001143p:plain

実際に開いてみると下記の情報が出力されています。エラーの場合はErrorとしてログが出力されます。

f:id:syachiku_inu:20210905001945p:plain

 

ログは「,」区切りで内容を分けているため、見難い場合はカンマ区切りで縦に並べ変えましょう。そうすると下記のようになります。メッセージの箇所を見るとどのアクティビティ(プログラムの命令)で何が起きたかが分かるようになっています。このエラーの場合「"exploああああrer.exe"で開いているウィンドウが見つかりません。アプリケーションが起動しているかどうか確認してください。」というエラーなので、「exploああああrer.exe」がなんらかの理由で見つけられなかったという事が分かります。

【エラーログの出力項目(標準)】

f:id:syachiku_inu:20210905003943p:plain

【メッセージ内容】

f:id:syachiku_inu:20210905004322p:plain

 

画面の状態とこのエラーメッセージだけではどこの処理でエラーが起きたか分からない場合は、エラー前のログを見ます。それでもたどり着けない場合はプログラム(XAML)を確認します。ログにXAML(プログラムのファイル拡張子)名も出力されるので、対象のXAML内でアクティビティ検索すれば辿り着けます。アクティビティ名称を重複させてはいけない理由の一つがこの障害対応時の調査がし難くなるためです。重複しているとどこのアクティビティでエラーになっているか特定が難しくなります

 

また、このエラーログはUiPathの標準で出力されているものですが、Try Catchというアクティビティで囲った後に標準エラーメッセージを出力しないようにしていると標準エラーログが出力されない作りになり、非常に障害分析が難しくなります。現在そのような作りになっていて、エラー特定に支障をきたしているなら、出力するように修正を入れた方が良いです。

 

本来出力されるはずのログが途中から書かれていない場合は、UiPathのソフトウェア自体が内部処理異常で強制停止している場合があります。原因は内部異常(バグや.NETレベルで異常)が考えられ、この事象の時に初めに疑うのはメモリが足りなくなって異常終了したかです。このように「Execution.log」でエラー内容が分からない場合はWindowsのイベントログも確認する事で原因特定ができる場合があります。「ソース」列がUiPathでUiPathのログが出力されます。メモリエラーの場合は「Out of memory」という文言が出力されます。イベントビューアーは問題が特に起きていない時にもERRORとして出力している時があるので、問題なく動作している時には出力されていないものかを確認すると良いです。

f:id:syachiku_inu:20210905045508p:plain

Out of memory」の他に現在は発生しないようですが、Excelアプリケーションスコープを多重で起動すると稀に内部エラーで異常終了するケースがあります。メモリエラーではない内部エラーはこのようなエラー可能性を疑い、ログが途切れている直後の処理を確認しましょう。

 

 

UiPath公式ドキュメントにログレベルやログフィールド(出力内容)について、説明されている所があるので、より詳細理解したい方はこちらも参照下さい。docs.uipath.com

 

f:id:syachiku_inu:20210905025552j:plain

原因分析

状態やログの内容を確認したら、なぜそうなってしまったかの原因を特定していきます。原因を特定する際のポイントとして下記があります。

 

<原因特定の観点>

①表面的な事象だけにとらわれない。根本原因や背後要因を視野に入れる

②事実を書き出して整理する

③事実から仮説を立て、対策から検証を繰り返す

④同じ問題の解決策情報がないか確認する

 

表面的な事象だけにとらわれない。根本原因や背後要因を視野に入れる

障害は複数の問題が絡んで発生するケースがあります。下記の例では問題事象が起きているのはパソコンで「セレクターが見つかりません」というエラーメッセージが出ていますが、原因はパソコンではなく、サーバー側で異常が起きていて、結果画面遷移が正常に行われず、「セレクターが見つかりません」となるケースもあります。パソコンで問題が起きているからといって、パソコンだけの視野でいると原因を特定する事ができません。これはパソコンとサーバだけの話ではなくパソコン内の起動しているアプリケーションでも同じことが言えます。初めから視野を狭くし過ぎてはいけません。後述で説明しますが視野は原因に関係ない事が確認できている所から狭めていくものです。

 



事実を書き出して整理する

これは非常に大事なポイントです。障害対応時に実際に確認している事と推測や予想が混ざってしまい、まだ実際に確認していない事を確認したと勘違いしたり、起きていない事を起きたと思い込んでしまったりします。このような事にならないように事実と推測は明確に分けて、書き出しておくと良いです。自分で解決できない場合に誰かに助けを求める際、事実ではない事を事実だったとして伝えると原因特定がかなり遅れる事があります。また、確証があまりない事を予想で伝えるのも混乱を招くことがあるため、思い付きで発言して障害対応現場を混乱させてしまう事は避けましょう

 

事実から仮説を立てて対策から検証を繰り返す

実際に起きている事、確認した事、当時の状況から「こうなったから障害が起きたのではないか」と仮説を立てます。仮説の観点では冒頭で説明した「モノ・ヒト・コト」の視点で考えると良いです。午前8時にロボットが特定のファイルを上書きしようとした所、エラーが起きたケースで考えると、なぜエラーになったかの原因として、「モノ」はファイルがそもそも壊れていたという仮説になります。ファイルが壊れてなければ、「ヒト」によって、ファイルのフォーマットが削除や変更されていないかという仮説を立てます。「コト」は午前8時に誰かがファイルを掴みっぱなしにして保存できずエラーになったかのような仮説になります。

 

このように「モノ」「ヒト」「コト」が起因して障害を起きたのでないか仮説を立てて事実確認をしていきます。

 

f:id:syachiku_inu:20210905033847p:plain

 

上記の観点で確認しても原因が特定できなかった場合、更に切り分けを行い特定していきます


<切り分けの観点>

①手動でやった場合はエラーになるか

②この事象は開発中に起きていたか(初めての事象か)

③再現率は100%のものか

④開発機と本番機が異なる場合、本番機だけで起こるものか(他では起きていないか)

⑤本番機でデバッグ実行した場合に発生するか

 

手動でやった場合はエラーになるか

RPAでやらずに人がやっても処理がエラーになり結果、障害になっている事があります。これを確認する事でRPA特有の問題なのかそうではないのかを切り分けます。

 

この事象は開発中に起きていたか

元々動いていたものが動かなくなった場合、処理対象に何かしらの違いが起きているか設定値やバージョン等の状態が変わっている可能性が高いため、新たなにポップアップが出るようになっていないか、セレクターが変更されていないかを確認します。

 

再現率は100%のものか

再現率が100%ではない場合は、処理遅延や正常終了する場合と異常終了する場合の違いはないか、関連システム側に問題はないか確認を行います。特定の文字が入力に含まれていると上手くいかないケースや特定の分岐処理の場合に上手くいかないケースがあります。また、まったく再現しないものに対して、確認するとたまたまネットワークがその時切れていたから発生していたものであったケースもあるため、再現性があるかどうかは確認して再現しない場合は二度と同じ異常が許されない場合を除き、事象再現待ちとした方が良いです

 

他では起きていないか

特定の端末やログインユーザのみ発生するかしないかを確認する事により、環境の差分(各設定値等)で問題が起きていないかを切り分けられます。Excelのリボンの表示内容がAとBの端末で違っていてBは正常に動くけどAは動かない場合は設定を揃ってないのが原因というように特定できます。

 

本番機でデバッグ実行した場合に発生するか

デバック実行だとエラーが起きる時の操作対象の状態や変数にセットされている値まで確認できるため、原因の特定がし易いです。デバッグは上手くいくのに本番機での実行は上手くいかないケースは処理が空振りしているか、URの場合はOrchestratorが展開している画面サイズや解像度によって問題が起きているケースもあるため、人がリモートデスクトップで接続している状態とOrchestratorが実行している状態のエラー前後画面の比較のスクリーンショットを取り確認すると良いです。

 

同じ問題の解決策情報がないか確認する

「エラーメッセージ UiPath」でインターネット検索すると、過去誰かが対応を行い、その情報がインターネット上で公開されていれば、切り分けして問題特定までしている情報にたどり着ける時があります。見つからない場合はエラーメッセージだけで検索するのも有効です。他プログラム言語や製品でも類似の対処方法が見つかる事があります。

 

以上のように障害の原因はヒト(ファイルを消す、変更する)やモノ(設定値、ネットワーク、処理遅延、他システム障害、システム側のUI変更、バージョン)やコト(どんな状況で起きたか)で様々存在します。どこから確認していくかはエラー内容と状況によって怪しいと思われるところが変わってきます。この感覚の部分はわかり易く説明できるように整理できたら別途記事を書こうと思います。

 

自身やチーム内で原因に辿り着けない、早く対処が必要な場合はライセンスを有償契約しているのであれば、UiPathのカスタマーサポートに問い合わせする事で解決する事が多いです。私自身正解に辿り着けない場合はUiPathやMicrosoft(Windows)のカスタマーサポートに問い合わせをして専門家のアドバイスを貰います。

 

www.uipath.com

 

f:id:syachiku_inu:20210905042500j:plain

 

対処の実施

原因が特定できたら対策を行っていきます。下記に対処の例を記載していきます。本番で実際に動かしてみて解決したか確認が取れるまでは、「結果確認⇒再度調査⇒原因分析⇒対処⇒結果確認」を繰り返します。

 

【障害対処の例】

〇処理対象のUIが変更になっていた

⇒アクティビティを取得し直す

 

〇処理遅延で空振りしている様子だった

Find Elementやセレクターのオプションの待機時間、準備完了まで待機を見直す

 

〇アプリケーションの設定が誤っていた

⇒正しい設定に揃える。正しい設定が何かを設計に残しておく

 

〇人がロボットを更新するファイルを掴んでいた
⇒ロボットの更新付近は触らないように運用を徹底させる。又は、該当のエラー時に閉じるように人に連絡して処理を一時停止するように作り込む

 

ワークフローが安定しないような障害の場合、安定化させるためのノウハウをUiPath公式が公開しているので、こちらを参照して対策を実施すると良いです。

www.uipath.com

 

クレスコという会社のこちらの技術ブログも人気です。

www.cresco.co.jp

 

f:id:syachiku_inu:20210905050112j:plain

まとめ

原因の特定や対処の実施について、これまで少し詳細に説明をしてきましたが、障害対応ができる人が抑えている事は下記の通りです。長々と書いてしまいましたが「確認すべきログの場所と見方を知る」と「発生状況から判断」、「インターネットで検索」で解決可能な問題は多くあります。下記図のLevel1の部分をまずはできるようになりましょう。業務担当者の方は、エラーが起きた際に試しに自分で原因特定できるかチャレンジしたり、システム担当者の調査に協力可能な範囲で協力したりして頂ければと思います。

 

f:id:syachiku_inu:20210905143013p:plain

 

f:id:syachiku_inu:20210905150918j:plain

 

障害対応レベルを上げるために役に立つ情報

障害対応レベルをあげるために役に立つ記事や書籍を最後に紹介します。

 

コンピューターってどんなしくみ?:デジタルテクノロジーやインターネットの世界を超図解 (子供の科学★ミライサイエンス)

コンピュータの仕組みやコンピュータ同士が繋がる仕組みや簡単な歴史、コンピュータの何が危険なのかわかり易いように書かれている子供向けの書籍です。コンピュータやネットワークの仕組みが全然分からないという方にとてもお勧めです。メモリ?CPU?OS?という方でもついていけます。楽しみながらITの基礎知識を学べます。ここに記載されている事が理解できると、ITパスポートの参考書に書かれている内容も理解し易くなるため、ITリテラシー向上の入り口としてお勧めです。

 

 

ゼロから理解するITテクノロジー図鑑

これまで書いてきている単語がそもそも分からないものが多く、調べてもよく分からない人にお勧めの書籍です。IT基礎の単語の意味をイラスト付きでわかり易く説明されているので、ITに苦手意識がある人も理解し易いと思います。上記の子供向けの本を読んだ後だと、こちらも抵抗なく読み進める事ができると思います。

 

エラーメッセージの読み方と対処, 検索や質問の原則 Qiita


エラーメッセージ自体の読み方や検索や質問時の注意点が纏められている記事です。検索する際の文字をどこから選択すればいいか分からない場合や、質問しても何度も聞き換えられてしまっている人はこちらを参考にして頂く事でレベルを上げられると思います。

qiita.com

 

アメリカの中学生が学んでいる 14歳からのプログラミング

「コンピュータの仕組み⇒プログラム基礎⇒Scratch⇒Python⇒インターネットの仕組み⇒サイバーセキュリティ⇒Webページ構築」の順番でプログラミングに必要な知識をわかり易いイラスト付きで説明している書籍です。子供向けの書籍ですが、義務教育でプログラミングを学んでいない世代には、わかり易く必要な基礎知識の概要を身に付ける事ができるためお勧めの書籍です。ここに記載されている知識をわかり易い教材で理解するか、理解しないかは今後の学習や開発でのスキルの習得速度にも影響してきますので、この基礎はRPAやノーコード開発者も身に付けておく事をお勧めします。

 

 


公式ガイド UiPathワークフロー開発 実践入門

 

UiPath公式が出版している書籍です。UiPathの製品について全体的に抑えるべきポイントをわかり易く知る事ができます。公式のホワイトペーパーからサンプルをダウンロードできるため、サンプルを確認して良さそうであれば書籍を持っておくのが良いです。現場に1冊置いて皆で読むのも良さそうです。

www.uipath.com

 

OSの仕組みの絵本

 

WIndowsの仕組みやメモリ、ディスク、ネットワーク、CPU、プロセスについてわかり易いイラスト付きで絵本の様に学習できる書籍です。私は同じシリーズのJavaの絵本を購入し、わかり易いため他のシリーズもほとんど所持していますが、これと自分が理解したいプログラム言語の絵本さえあれば他は購入しなくても良いかなと思います。プログラム言語は似ている記載が多いため1冊あれば他は他書籍やインターネット情報で十分です。詳しくない人への説明が苦手なプロの方にもお勧めです。

 

 

Web技術の基本


ブラウザを使った自動化で問題が多く起きる場合にWebの仕組みを知っていると原因特定や対応の役に立ちます。この書籍は仕組みの概要が説明されており、お勧めです。記載レベルは基本情報技術者くらいのものです。

 

 

IPA:情報処理システム高信頼化教訓集 ITサービス編 別冊Ⅱ:障害分析手法


障害分析の手法の知識を身に着けたいという方にお勧めの情報です。

https://www.ipa.go.jp/files/000071988.pdf



トラブルシューティング(デバッグ)について実体験から学んだこと Qiita

デバッグのコツについて纏められている記事です。デバッグ慣れしていない方やデバッグが苦手な人は参考にすると良いです。

qiita.com

 

 

 

その他UiPathについての記事纏めリンク

UiPathの事について、色々と他にも記事を書いています。知っておくと良い情報を纏めていますので、参考にして貰えたらと思います。

 

syachiku-inu.hatenablog.com

 

 

【RPA(UiPath)】RPA導入のリスク概要と具体的な発生事例や対策例、洗い出し方の解説(開発・実行編)

今回はRPA導入についてのリスク(※)について、洗い出し方の説明と具体的な例をあげて気を付けなくてはいけない点を説明していこうと思います。今後ユーザがよりローコード、ノーコード開発への参入が活発化してきた際に、リスク対策を講じていないと、セキュリティ事故等の大きな問題に繋がってしまう可能性があります。

 

※リスク・・・将来のいずれかの時において何か悪い事象が起こる可能性と影響

 

この記事でどういう事に気を付けなくてはいけないのかを知って頂き、各自がリスクに対して意識しながら、開発やロボットの実行をして頂ければと思います。リスクは存在を知り、適切に事前対策を講じておけば、重大な問題発生までは防いでいく事ができます。

 

f:id:syachiku_inu:20201211223845j:plain

 

【目次】

 

RPA導入でのリスクとは

リスクとは、冒頭で注釈している通りのもので日本では「危険」や「危機」という意味で使われている事が多い言葉です。RPA導入でのリスクというのは、RPAを開発、利用していく際に発生する「危険」や「危機」というものです。これまでのシステム開発はITの前提知識を持っていなければ、開発する事が難しかったですが、開発自体が簡略化される事により、前提知識がない人でも開発自体ができるようになってきています。こちらに関して開発への敷居が下がったと同時に、開発や利用時に起こりうるリスクの一部分の発生確率が高まっていると考えています。怖いと思う方もいるかと思いますが、正しい基礎知識を身に着け、気を付けるべき事に気を付けていれば発生確率を下げる事ができますので、ここのポイントについて学んでいきましょう。

 

RPA導入でのリスクの大項目

RPA導入のリスクはどのようなものがあるかの概要について、説明していこうと思います。世間でよく言われているリスクは下記の通りです。

 

〇業務がブラックボックス化するリスク

自動化前で完璧な業務フローと業務手順書が揃っている場合は良いですが、自動化対象の業務フローや手順書が不十分な状態でRPA化をした場合は、担当者の異動や退職により、将来業務の知見を持っている人がいなくなった時に問題が発生します。再度業務の見直しが必要になったり、人手で対応しないといけない状態になったりする際に、業務を知っている人がおらず、ドキュメントもなくRPAのプログラムから業務把握を行わなければならないという事態になってしまうリスクがあります。そうならないようにドキュメントをしっかり整備しておく対策が必要になります。(RPAのプログラムを見て万事の際は人手でも対応できる体制であれば、ドキュメントはそこまで力入れなくても大丈夫なケースはあります)

 

〇不正使用や誤った利用により情報が漏洩するリスク

RPAが各システムにログインする用のIDやPWを悪意のあるものに利用されてしまったり、RPA利用自体を不正な処理に使われたり、誤った相手に重要な内容を誤送信してしまったりするリスクです。こちらはIDとPWは全員が見えないように権限を絞った場所で利用するか暗号化するかして対応する事ができます。RPAを開発できる人は知る術を持っているので、誰が不正利用したか追えるようにより厳重にする場合はアクセス履歴から追える仕組みを構築したりする必要があります。RPAが使うアカウント情報(ID/PW)と業務担当者が使うアカウントが同じである場合、RPAによって操作されたものか、業務担当者によって操作されたものか判別が難しかったり、共有IDを作ると誰が共有IDを使って、操作したか対策をしっかりしないと問題になる事があるため、情報システム部門とアカウントの運用ルールは相談する事が必要です。

 

RPAで誤作動を起こすリスク

RPAを誤って実行してしまい、2重でデータを登録してしまったり、開発環境向けの作業を誤って本番環境向けに動かしてしまったりして問題がおきるリスクです。RPAの開発では連携システムへの本番環境へ影響を与える事が多いため、ここはかなり気を付けておかなければいけないリスクです。本番と開発で切り替えした後に動かす際は動かしたい対象のURLや設定内容になっているか、指差し確認をする等動かす人が注意を払っておく事が重要です。

 

〇RPAの誤った処理に気づけないリスク

テストで全バリエーションを実施しなかったり、テストの時に誤りを見逃してしまっていたりして、RPAが誤った処理を実施していても気づけないリスクです。RPAが処理した結果をRPA処理後の方で誤りに気付けるような仕組みになっていない場合は、正しい動きができているか念入りに確認をする必要があります。ミスが許されないような業務は想定されるパターンが全て対応できているか本番で確認できるまでは結果を確認しておくことをお勧めします。更新や登録処理はボタンを押した後に、エラー画面に遷移したり、エラーメッセージが表示される可能性がないか絶対気にしてください。処理は正常に終わったのに、登録できていないとかが起きてしまいます。

 

〇RPAが動かなくなるリスク

このリスクはRPAが動かなくなってしまうというリスクです。RPAは画像やプログラム認識を作成された順番通りにしか動く事ができませんので、処理対象の見た目やプログラム内容が変わったり、処理途中に操作が増えたり(セキュリティポップアップ等)、処理が遅延してタイムアウトしてしまったりすると止まってしまう事があります。止まってしまった時どうするかを予め考えておく必要があります。自社内のシステムの場合は変更を気付けるようにシステム変更時にRPA利用チームに連絡がいくようにすると急に止まるリスクを軽減する事ができます。稀ですが端末やサーバが故障してしまい動かせなくなるリスクも存在しています。

 

〇野良ロボットの発生リスク

どこの場所でどのようなロボットが使われているか、使っていないか把握できなくなり、不要なライセンス費用を払い続けてしまったり、リスク対策の対象から漏れてしまったり管理上問題となってしまうリスクです。こちらは各RPA製品のサービスである管理サーバや個別の管理台帳にどこで利用できる環境が揃っているか、利用されているか定期的に確認することで防ぐ事ができます。

 

概要だけでは理解し難い部分もあると思いますので、実際のリスクの発生事例を次に見ていきましょう。

f:id:syachiku_inu:20201212213201j:plain

 

リスク発生事例

<ケース①:本番のデータを誤って更新、削除してしまった>

こちらは本当に起こりやすく影響の大きいものになっており、幅広い人が注意しなくてはならないものです。自身が開発中に動かした時に誤ってRPAにより更新や削除してしまう事もありますが、誰かが作ったロボットの引継ぎを受けて理解できていないまま実行して、問題を起こしてしまう事もあります。このリスクへの対策で有効なものは2つ。1つ目は更新や削除等周りに影響を与える処理がどこにあるか、必ず気にして対応する事。2つ目は自分が理解できていないコマンド等の箇所が登場した際、必ずどのような事がされるか調べる事。自分がこれから動かそうとしているものが、操作の結果周りにどんな影響を与えるか理解する事が重要です。開発経験者はデータが消えてしまう事件等を近くで見ている人が多いため、このような点には常に細心の注意を払っています。そのためこのリスクを発生させない事ができるのです。皆様もここは常に細心の注意を持って頂ければと思います。(本番というのは開発やテスト環境ではなく、実際の業務で扱っている環境やシステム、ファイルの事です)

 

<ケース②:誤った宛先にメールやチャットを送信してしまった>

こちらは外部の宛先も絡んでくる場合、非常にリスク影響が高いものとなります。高すぎるためにメールやチャットの送信をRPAだけで完結するのはルールとして禁止している企業がある程です。もし仮にRPAで送信を試みる場合は、チェック機能(アドレスチェック等)を合わせて実装する事でリスク発生確率を下げる事ができますのでチェック機能を搭載させることをお勧めします。

 

<ケース③:誤ったバージョンをリリースしてしまった(デグレ)>

こちらもよく発生するもので、幅広い人が注意しなくてはならないものです。どこに最新の資源を配置してどこに過去のバージョンを管理するかのルールを決めて、決められた箇所で決められた運用を徹底していく事が重要です。複数人が同じ資源を修正したりし始めるとこのデグレのリスクは人数に比例して高まります。共通ルールの認識を持つか、どうしてもデグレの発生率を抑える事ができなければ、バージョン管理システムの導入を検討しましょう。(但し、このシステムを扱うための運用ルールを決める必要もあります)

 

<ケース④:実行するロボットやプロセスを誤ってしまった>

同じ端末に複数プロセス選択できるようになっていたり、管理サーバから実行できるようになっていたりする場合、実行する対象を誤ってしまうリスクがあります。実行時は間違うと問題おきてしまう可能性があると意識して、集中する事と実行対象の名称を間違いにくい命名規則にしておくなり対策することで発生リスクを抑える事ができます。検索機能を使い検索して対象を1つに絞ってから実行すると選択できる対象が一つになるので間違える可能性を限りなく低くしてくれます。

 

<ケース⑤:ロボット端末や管理サーバの容量が逼迫して異常終了>

ログを細かく出力するような設定にしていると、ログで結構な量のディスク容量を消費する場合があります。容量が一杯になるとログ出力できずエラーとなったり、生成するファイルの出力や更新に失敗したりしています。各端末やサーバの残りディスク容量が残りいくつあるか定期的に気にしておき、容量が一杯になりそうになる前に不要なものを削除したり、移動したりする対応を行うことでこのリスクを回避する事ができます。

 

<ケース⑥:外部から送られてきた不正なメールを開いたり、添付ファイルを実行したりしてしまい、ウイルスに感染した>

ロボットが外部から送られてきたファイルを無条件に開いたり、添付ファイルを実行する仕組みのものを作ってしまったたりする場合、このような事態が起きてしまいます。最悪の場合、ウイルス感染して感染を広げてしまう等のリスクに繋がります。このような機能を実装する際は、信頼できるメールやファイルの内容しか操作しないようにチェック機能を搭載する事をお勧めします。無条件では決して添付ファイル実行の操作はしてはいけません。

 

<ケース⑦:ロボットが操作するファイルを人が同時に操作して更新失敗してしまった>

基本的にロボットがファイルを操作している時は人が操作しないように運用を徹底させるか、ロボットが操作するときは一時フォルダに移動して更新が終わったら名前を変えて保存し直すようにするか検討が必要です。共有ファイルを人もロボットも使わせてしまう運用をと取らざる得ない運用になっているケースもありますが、その際は必ず操作前にバックアップを取得する仕組みを入れておいた方が良いです。ファイルサーバ上の共有ファイルは特に注意が必要です。人の速さでもファイルが破損したりするときがあるので、ロボットの更新スピードではより破損確率が高くなっていると思われます。

 

<ケース⑧:メモリ不足によりロボが異常終了>

メモリというのは、パソコンが扱うデータの一次領域の事で作業場所のようなものです。このメモリ内で使用できる限界容量というのが決まっており、その容量を超えると異常終了してしまいます。該当の事象は容量が大きいファイルを操作したり大量のデータを操作したりする時に発生します。大量データを操作するようなものを自動化する場合、メモリ不足になる可能性がないか気にして、本番で想定される最大データ量でテストを実施してエラーにならない事を確認するといった対策をとることで本番での発生を防ぐ事ができます。この負荷テストの際にどうしてもメモリエラーとなってしまう場合は、不必要に引数でデータを渡していないか確認してMainに返す前に不要な列や行を削除できるものがあれば、削除しておく対策をしてそれでもダメな場合はVBA等の違う対応を検討したりすると良いです。大量データを扱う場合はVBAやDBで処理させた方が速度も速く、扱えるデータ量も多くなると思います。

 

<ケース⑨:徐々に実行時間が長くなり、後続のスケジュールに影響がでたり処理がタイムアウトになったりしてしまった>

自動化対象の普段皆様が扱っているシステムはデータ量が年々増えてきたりする場合が多いです。そうなると今までは登録ボタンを押したら3秒で応答が返ってきていたものが5秒、10秒と掛かるようになり、実行時間が伸びて他のプロセスの実行が遅延してしまったり、処理が遅いことにより処理がタイムアウトになってしまい、失敗してしてしまいます。これを防ぐには月次程度で実行時間の伸びを監視して、後続に影響が出そうな場合、処理を高速化できないか検討したり、スケジュールを組みなおしたりする対策が必要です。また、処理のタイムアウトに関しては、待機時間の値を全て変数にして、その変数を設定ファイルから読み込むようにしておけば、時間が伸びてきたらその設定ファイルを更新するだけで対応できるようにしておくことで柔軟な対応をとる事ができます。

 

<ケース⑩:不要なプロセス(Excel等)が立ち上がっており、ロボットが異常終了してしまう>

ロボットが動く前に不要なプロセスが立ち上がっているとそれが邪魔をしてエラーになってしまうケースがあります。これにはプロセスKILLが有効ですが、プロセスKILLは強制的にプロセスを落とす手法ですので、極力動作させないように普段からロボットが実行可能な状態を意識して、動かすことが重要です。無人ロボットの場合、前のプロセスが異常終了してそのプロセスが使っていたプロセスが悪さをしてしまう事もあります。対策としては異常終了した時に、使っていたプロセスを正常に落とす処理をエラー時の処理に組み込んでおくのが一番良い対策と考えます。(サーバでプロセスKILLを利用する場合、メモリ領域を複数アカウント共通利用しているとUiPath標準のプロセスKILLでは失敗してしまう事があるのでご注意ください)

 

<ケース⑪:テストと本番で動かす端末が違うのが原因でロボットが異常終了してしまう>

これもよくあるケースです。ロボットは繊細で設定内容が少し違うだけでも異常終了してしまう事があります。ここでの対策は扱う関係する各種設定を抑えておいて、極力設定を統一化させる事です。会社のPCだと一度設定を変えても再起動したら元に戻ってしまったり、一定のタイミングで設定が元にもどったりする場合があります。これは会社毎に共通設定を情報管理部門が決めて運用しておりその設定が再適用されているためです。これに対する対策は各種設定の内容を押さえておき、何が正しい設定なのか分かるように情報を整理し、比較を簡単にできるようにしておく対策が有効です。また設定を一括で正しいものに変えてくれるバッチを作っておくことも有効な手段です。この辺りはまた別の記事でやり方を纏めて紹介していこうと思います。

 

<ケース⑫:ファイルサーバや各システムのPW有効期限切れで異常終了してしまう>

IDとPWが必要なものの多くには有効期限が設定されている事が多いです。こちらを気にしておかないと有効期限切れのポップアップが出てきた際に異常終了したり、ログインできなくて異常終了したりしてしまいます。対策としてはPWの有効期限を切らさないように運用をする事です。またPW変更作業自体もプログラムに組み込んでしまったりする対応が有効です。処理の途中でこのエラーが発生すると対策が面倒になったりしますのでそのようなプロセスの場合、処理の一番初めにファイルサーバに接続可能か利用予定のシステムにログイン可能か確認してから処理を始める作りにするのも有効な対策です。

 

<ケース⑬:処理対象のファイルやフォルダがなくて異常終了してしまう>

処理対象のファイルやフォルダが誰かに消されたり、名前を変えられたりしてしまい異常終了してしまうものです。これもケース⑫と同じように処理の途中でエラーとなると復旧が面倒である場合が多いので、処理の一番初めにファイルが存在しているか、フォルダが存在しているか確認してから処理をする仕組みにすることが有効な対策です。

 

<ケース⑭:設定ファイルの更新内容を誤って異常終了または誤った動作をしてしまう>

設定ファイルの更新を人が誤って、その結果ロボットが異常終了又は誤った動作をしてしまうものです。重要なロボットである場合は、更新内容をチェックする仕組みを構築したり、他の人に確認してもらう事が有効な対策となります。

 

<ケース⑮:他システムに障害が起きてロボットが異常終了してしまう>

障害が起きるのはRPAだけではありません。利用している端末やサーバ、業務システムやクラウドシステムでも障害が起きる事があります。人でやっている時もエラーとなるようにロボットでも異常終了します。そのようなときは復旧後にどのように対応するかどのロボットに影響があるのか調べて対策を実施する必要があります。各ロボットで利用しているシステムが一覧上で確認できるようにしておくと各システム障害時に影響調査は容易になります。または利用システムをログに出力しておいて、ログから影響調査を可能とする手段もあります。

 

<ケース⑯:大量の処理を高速で行ったもしくはやり続けた事により対象システムがダウンした>

これまで人の速さや操作量でしか、考慮されていなかったシステムがRPAの処理速度や処理量に耐え切れず、ダウンしてしまうというものです。内部システムでも問題ですが、外部(他社)のシステムに対して問題を起こした場合、賠償請求される可能性もあります。これまでの速度よりも大きく速さやデータ量が変わる場合は扱うシステムも問題ないかは確認をとりましょう。(外部システムはそもそもRPAやプログラムによる操作を禁止しているサイトもあるので、利用規約を良く読んでおく必要があります)

 

<ケース⑰:予測変換機能が機能して想定外のデータが登録されてしまった>

IEやクライアントアプリに登録を行う際に、予測変換が機能してしまい想定外の値が登録されてしまう事があります。予測変換は基本されないように設定を変更しておくのがお勧めです。又は、UiPathの場合は、文字入力アクティビティではなく、張り付けをしたりして対応する事も代替手段の一つです。(他製品でも同様な手段を検討して下さい)

 

<ケース⑱:他の人が保守困難な状態になり、保守不可やミスが起きてしまった>

これまであげているようなリスクがそのロボットに存在しているため注意すべき事項や開発と本番機で切り替えが必要な場合はその手順等他の人が再度修正やテストを行う際に存在しないと一から調べなおしたり、誤った認識で修正や実行をしてしまうものです。他の人が任された時にないと困るだろうと思うものを残しておく事は非常に重要な事です。どんな情報を残すべきかは下記別のブログでも紹介しているのでこちらも見て貰えればと思います。

 

syachiku-inu.hatenablog.com

 

 

上記でご紹介したリスクはよく発生する初心者でも気にするべきものとなります。このようなリスクをどのように洗い出していけば良いかについて、次は説明していきます。

f:id:syachiku_inu:20201212213536j:plain

リスクの洗い出し方

リスクの洗い出し方についてですが、事例を知る事と経験により培われていくのが多いです。実際に普段から気を付けるようにしておくと、他にも気を付けなくていけない事に視野が広がっていきます。経験で培われる部分は各皆様が作業していく中で備わっていくものですので、ここでは知識的な所で参考となる情報を記載します。

 

PwCあらたとUiPath社のRPAガバナンス構築ガイドライン

こちらにRPA関連のリスクとコントロールのポイントをAppendix1の箇所で纏められている無料公開されているドキュメントが存在します。これまでの事例で紹介していないプロジェクトを遂行していく上でのリスクも含めて全体的なリスクへの考え方が説明されています。プロジェクトマネジメントレベルを実施する方は見ておくと良いです。

www.pwc.com

 

IPA:ITプロジェクトのリスク予防への実践的アプローチI

こちらはプロジェクト管理よりのリスクについて説明されていますが、ITプロジェクトでのリスクとは何か、洗い出しと対策の立て方について参考にする事ができます。こちらもプロジェクトマネジメントを目指すような方は見ておくと良いです。

https://www.ipa.go.jp/files/000026834.pdf

 

IPA:非機能要求グレード

非機能(機能以外の性能、信頼性、セキュリティ、運用性等)についての評価観点やレベルが定義されているものです。今回開発する対象のもので各評価項目でどのレベルの非機能要件になるのか次第でリスクの対策をどれくらい実施するかや、非機能要件観点でリスクがないか洗い出すのに役に立ちます。

www.ipa.go.jp

f:id:syachiku_inu:20201212215137j:plain



さいごに

事例いくつか紹介させて頂きましたが、それ以外にも細かいリスクというものが存在します。IT開発初心者の方は紹介したリスクが存在するという事を覚えて頂き、「本番環境に問題を起こさない!」「セキュリティ事故を起こさない!」の2つの大きな観点をまずは気にして頂ければと思います。

 

誰かが作った手順(RPA)の中身を理解しないでその通りに実施していると、手順(RPA)の中のどこで注意しなくてはいけないか分からず、集中すべき所で集中しないでミスを起こしてしまう事があります。コマンド一つ発行するものでもそのコマンドによって、何が行われるか調べて覚えていく事でリスクの高い作業の勘所が養われてきます。日々分からない事をそのままにせず覚えていく事が自分でリスクに気付けるようになる確実な一歩となると思います。皆様が事故を起こさずRPA開発や運用ができるようになるためのご参考情報となっていれば幸いです。

 

 

RPAのUiPathの事を知りたい場合は、下記に私が纏めている情報のリンク一覧の記事がありますので、そこから気になる箇所の記事をみて頂ければと思います。

syachiku-inu.hatenablog.com