  |
はてなキーワード: RPAとは
タイトルの通り2018年に入社したNTTグループの某社を退職しました。
2019年１月中旬に正式退職したので、約9ヶ月間働いたことになります。
本記事では非常に主観的かつ局所的な話を書くつもりであり、一般性には欠けますのでご承知ください。
NTTグループの某SIer企業に2018年度の新入社員として入社しました。
前年度までは大学院に在籍しており、情報系の研究を行っていました。
入社してからの立ち位置としては一応システムエンジニアに分類されるはずですが、あまりシステムエンジニアらしい仕事は行いませんでした(これについては後述しています)。
2018年の4月に入社し、最初の2ヶ月間は新入社員研修を行っていました。
研修内容は大手企業あるあると言った感じで、挨拶練習や名刺渡し練習、ビジネス文章の書き方等を行いました。
周りは「研修が手厚くて良い」と言っていましたが、個人的には退屈なだけでした。
今振り返ってみると、この研修期間中が最もつらかった様に思います。
しかしながら研修自体は退屈であったものの流石に大手企業と言うべきか入社同期には優秀な方が多く、変な人間も少なかったため人間関係の面ではこれといった苦労はありませんでした。
6月になって研修期間が終わると正式に部署配属が行われました。
この時配属された部署に退職するまで在籍していたことになります。
部署自体の詳細についてはこのエントリでは伏せますが、元々配属を希望していた部署であったため、配属当初は安心した記憶があります。
何か1つこれが決め手になってといった明確な退職理由はありません。
インターネットで言われるようなSIer業界の悪評についても内定前から知っていて、実際に入ってみての感想としても「噂は真実だったんだな」くらいのものだったので特に入社したことに対する後悔もありません。
入社して詰まらない・つらい仕事であったら適当なところで辞めようと思っていましたし、その結果として詰まらない・つらい事象がいくつか重なったため退職するに至りました。
それらの事象を細かく挙げていくと切りがありませんが、そのうち幾つか分かりやすいもの(且つ社内機密や違法行為に当たらないもの)を以下に挙げます。
少なくとも自分が想像していたシステムエンジニアとしての業務は殆どありませんでした。
いわゆるSIerへの批判的な記事に挙げられるようなこと(Excelにスクリーンショットを貼り付ける作業、何に使われるのか分からない謎の資料作成、etc.)や、電話番等が主な業務でした。
新入社員に対して雑務を割り当てるというのはある種合理的な部分もあるとは思うので批判は控えますが、個人的には特に学ぶべきこともなく時間の無駄に感じました。
一方でExcelスクリーンショットに関しては批判するべき部分があります。
Excelスクショは「エビデンスを残す」という名目で行われることが多いと思いますが、システムが正しく動作したかを顧客に証明する目的であれば、結果ではなく検証をする方法を提供するべきではないかというのが私の意見です。
スクリーンショットなんてものはいくらでも改竄可能なもの(WebページなどであればDeveloper ConsoleでHTMLを書き換えれば良い)であり、普通に考えればエビデンスとしての効力はないと考えられます。
周りにはそれなりの年齢の方も多く、また社会インフラの構築を担うことの多い会社であるため、技術的な知識に造詣の深い方が多いと考えていたのですが、そのようなことはありませんでした。
大きな会社なのでそういった人も社内のどこかにはいるのかもしれませんが、少なくとも自分の周りでは観測できませんでした。
詳細は避けますが、技術的な知識に関してはその辺の情報系学部生の方が理解していると思います。
Linuxコマンドが分からない方向けにコマンドの打ち方をまとめた手順書(ターミナルエミュレータを立ち上げて、どこにユーザ名・パスワードを打ち込んで、どのボタンを押して...をスクリーンショット付きでExcelにまとめる)や殆ど問題を丸投げしている様な質問表等を作っていた時の心中は決して穏やかなものではありませんでした。
ファイル名の末尾に日付を付けるようなバージョン管理方法も噂では聞いていたものの本当に実在しているとは思っていませんでした。
また部署としては今後コンサルタントとなるような人材を増やしていきたいような雰囲気がありましたが、システムを殆ど理解していない人にコンサルが務まるのかはよく分かりません。
主に常用していた端末周りの環境についてです。
使用しているコンピュータのスペックがあまりにも低く(メモリ2G、ハードディスク50GB、32bitOS)、まともに作業ができるような環境ではありませんでした。
Excelを開いたり、酷い時はIMEの変換機能を使用した時にもコンピュータが固まっていました。
上で雑務が殆どと書きましたが稀に開発をすることもあり、そういった場合は特にスペックの低さによるストレスを感じていました。
私自身そこまで気合を入れて仕事をするような人間ではなく、むしろできることなら仕事せず遊んでいたい人間ですが、やるべき仕事がくだらない原因で阻害されるというのはそれはそれでストレスが溜まるものだなと思いました。
自分だけでなく周りの人達の環境でもそういったことは起こっていましたが、周りの人達はこの現象について好意的に感じている(コンピュータが固まるのを理由に仕事をしなくても済むため)ようでしたので、その辺りの温度差も退職の理由になっています。
計算すれば高スペックのコンピュータを導入するコストよりも、低スペックなコンピュータを使うことにより生じる人件費の無駄の方が大きいと分かるような気がしますが、あまり計算が得意な人がいないのだと思います。
昨今セキュリティが重要視され、セキュリティに関する施策に予算が付くようになったのは良い点だと思っています。
しかしながら、実施される施策が的外れなものと言わざるを得ないものばかりでした。
的外れならまだ良いですが、それはセキュリティリスクを高めるだけなのでは？と言った理解のない上の人間が思いつきで実施したとしか思えないものもあり大変疑問を感じました。
意味のない施策で業務環境が不便になるのも見てる分には面白いですが、その中で仕事がしていきたいとは思えませんでした。
パスワードの定期変更や、暗号化zipファイルをメールで送り続いてパスワードをメールで送る等のバッドノウハウが未だに存在していることも知りました。
またこれはSI業界全体に言えることだとも思いますが、RPAとかDX(Digital Transformation)とか10,20年前に言うならともかく、今更言っても時代錯誤感が強いです。
退職理由として不満点を挙げることになってしまいましたが、良い点もありました。
これは部署やプロジェクトに依る部分もあるみたいですが、少なくとも私の所属部署では早く帰ったからと言って咎められるようなことは殆どありませんでした。
最近は労働時間に関する制限がかなり厳しくなっているようで、残業が多い部署は上から注意されているようでした。
有給休暇についても申請して拒否されるようなことはなく、むしろ消化が推奨されていました。
休んだことにより後から文句を言われることもありませんでした。
上司や同僚から理不尽な扱いを受けるようなことは殆どありませんでした。
入社前のイメージがパワハラ・モラハラは当たり前といったものであったため、非常に驚かされた部分です。
また少なくとも自分の観測範囲では人種や国籍、性別による差別は行われていないように見えました。
色々ありすぎて私も全てを把握できていませんが、恐らく福利厚生に関しては国内企業ではトップクラスに充実していると思います。
少なくとも1年目の年収としては比較的高い方であったと思います。
業務内容の割に高いとも思いました。
私の場合は残業は殆どありませんでしたが、役職のない若手が残業をした場合残業手当が付くため(役職がつくと裁量労働制になる)、残業をした場合は更に貰えると思います。
もちろん残業手当は働いた分だけしっかり付くようでした。
ただどうやら年収の伸びはそこまで良くはなく、聞いた話では20~30年勤続し管理職になってやっと1000万程度らしいです。
ただ勤務中はかなりささくれ立った心境であったため、こうして比較的穏やかに振り返ることができて良かったなと思う次第です。
巷ではSIer崩壊説みたいなものもありますが、個人的にはSIerは今後も続いていくと考えています。
環境も改善していって数十年後に「あの時辞めなければ...」と後悔することになると面白いですね。
今後の身の振り方については決まっていて、ソフトウェアエンジニアとして転職をすることにしました。
具体的な企業名や待遇等について詳細を書くことができませんが、年収については前職であれば20~30年勤続し管理職になった場合と同程度になります。
Pythonやディープラーニングの本は沢山出ているが、入門書ばかりで終わってしまい、入門が終わったらどれも似たり寄ったりで読むのがなくなる。
実際に自分が抱えている処理をしようと思えば、それなりに咀嚼し応用しないといけない。
蛍光スペクトルからどうやって細胞を分類するかといった課題を解きたいとして、沢山本は出ているにも関わらず、バイオ系＋Pythonといった書籍は皆無だ。
他の学術書もそうだ。工学の数学なんてルベーグ積分あたりで終わりではないだろうか。
アンケートを取った結果を載せていたとしても、どのような質問をしたのか、処理はどうしたのか、集団はどう選んだのかなどの処理手順がかかれていることは稀であり、引用しようにも疑問符が付く。
国が出してる統計データですらデータ処理の方法やグラフの描き方などは書籍にない。（ネットにもないが）
ワードやエクセルの本も棚を埋め尽くすほど沢山あるにも関わらず、大半は同じ内容だ。
入門書しか売れないと、売れる本ばかり作った結果がこれなのだろうか。
効率化と題名がついているものが、どこにでもあるショートカット集であったり、
RPAだといってソフトのインストールとサンプル1つの実行方法で終わっていたりする。
電子回路の書籍も、ラズパイのインストールか、拡張ボードの使い方で終わる。
例えば温度を測定しようとするとオフセットつくのだが、水の三重点でキャリブレーションするのがいいけど、氷の融点と沸点でキャリブレーションしても、実用上そこそこあうといったことはなく、
数℃狂った値で、温度が測定出来たというので終わっており、測定データの不確かさをどうやって処理するかまでは記載されない。(GUMにおける不確かさ表現に合わせればいいが、そこまでは面倒くさいのはわかる）
自分より優れたるものを自分の周りに置きし者ここに眠る。カーネギー
できる人ばかり辞めていく会社が研修費用を出すようになったら、さらに退職が加速したというお話「人事に聞かせたい」 - Togetterまとめ
「従業員にトレーニングをして、よそへ行ってしまったらどうするのか」という疑問に対するStanger氏の答えは、「従業員にトレーニングをしないで、彼らが会社にとどまってしまったらどうするのか」ということになる。
従業員の才能を爆発させるには「会社に人を長く留める」戦略を捨てる必要がある
ttps://b.hatena.ne.jp/entry/s/gigazine.net/news/20171005-superboss/
「弱いつながり」理論でいうと、SNSでつながる友だちは、それこそFacebookの友だちが3,000人規模で、国内のスタートアップの経営者なら、たいていの人に直接または1hopでつながることができる。
ttps://s.nikkei.com/2vJsvYx
優れたマネージャーは自分より高い給与をもらう可能性のあるポテンシャルの高い部下を喜んで雇う
ttp://b.hatena.ne.jp/entry/www.masafumiotsuka.com/2015/11/the_peter_principle.html
人材は会社の資産として残らないが仕組みは会社の資産として永遠に残る
ttps://www.amazon.co.jp/dp/B010JM64M6/
ttps://employment.en-japan.com/engineerhub/entry/2019/11/07/103000
ttps://www.slideshare.net/yattom/ss-79372905
ttps://tinyurl.com/y8tkhuhz
ttps://bit.ly/2MylBjs
"競争優位につながるような戦略的なソフトを開発しようとするなら内製しかない。"
ttps://www.amazon.co.jp/dp/4822273784
ttps://medium.com/@kuranuki/aac6062adfb2
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるか
（中略）
ソフトウェア開発とは、経営的意思決定の集積なのだから、経営的意思決定を外部の会社に委託するというのは、「経営を外部の会社にやってもらうようなもの」だからだ。
もっと言うなら、自分の会社の今後のビジネス的ポジションを、他社に決めてもらうようなものだからだ。
外注を出された会社は、そのソフトウェアが未来に実現するであろうビジネス的価値を犠牲にして、できるだけ少ないコストで作ろうとする。
ttp://fromdusktildawn.hatenadiary.jp/entry/20061003/1159869683
ttps://bit.ly/2JzCggZ
「ソフトウェア業界（特に受託開発業界）は、基本的に正直者が馬鹿を見る世界である。顧客が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ」/分かるなぁ
「モダンな開発環境×技術顧問×内製化」Sansan×日経電子版 アプリ開発の最前線を語る夜
ボタンを1つ追加するだけで2週間。内製化によるスピードアップは必須だった。
「アプリ内にボタンを1つ追加するだけで、2週間の開発期間と、数十万円のコストが発生していました。それでは急な仕様変更に対応できないし、技術ノウハウも貯まらない。」
ネットサービスの肝は、開発にかける額の多寡というよりは、内製化するかどうかにあると思っています。
ローンチした後、そこからの追加・改善はものすごいスピードでやらなくちゃいけない。これは、内製体制でないと絶対に不可能です。
2017年1月、ネット証券大手のマネックス証券は証券基幹システムを刷新した。
お客様へ提供するサービスの開発スピード向上と、ノウハウの社内蓄積、開発コストの適正化を目的に、
（中略）
サービスの改善や新サービスの開発時に、ASPサービスの提供会社との会議に費やしていた時間を削減し開発のスピードアップを図ることで、競合他社への競争力を強化したいと考えました。
ttp://b.hatena.ne.jp/entry/s/quality-start.in/it-strategy/467
ttps://twitter.com/kanayang2009/status/129677947572465666
ttps://amzn.to/2ncDXrO
だから育てるんだ。
ABテスト デザイン OR ボタン OR 文言 - Twitter検索
外注でもA/Bテストでユーザの反応を計測してトライ・アンド・エラーでシステム開発ってできるもんなんだろうか。
できるとして、それって内製化した方がずっとクオリティ高くなるんじゃないの？
ttps://twitter.com/fromdusktildawn/status/874796380522336256
「外部委託すると細かい継続的な機能の改善が遅くなるので、自社採用でかなり優秀な人材をケチらずに採るべきだね。なかなか見つからなくても妥協せずに」ホリエモン
ttps://bit.ly/2QWMsoJ
外注はPDCAを回せないという致命的な欠点がある。ITスタートアップの感覚だと外注と内製には天と地ほどの差がある
ttps://bit.ly/2J5UCWQ
銀の弾丸ではないがリーンな開発は競争力の源泉。そのためにはPMFをコントロールできる開発チームが必須でそれは内製でしか達成困難。
ttps://bit.ly/2vkDd8E
正解に当たるまで回し続ける！3ヶ月で200回のA/Bテストから得た「意外な結果」とは
弊社のイベント一覧のページなのですが、単なるテキストの羅列のパターンと、リッチなレイアウトのものでテストすると、いつも必ずテキストの方が勝ちます。
海外テック情報局：eBayではダサいデザインのほうがコンバージョン率が高かった｜gihyo.jp … 技術評論社
デザイナと口論したいのではなく，見たいのは数字とお客さんの利用例。
そして何がうまくいっているのか突き止めたい。
選択の科学 ２４種類のジャムを売り場に並べたときと、６種類のジャムを売り場に並べたときでは、前者は、後者の売り上げの１０分の1しかなかったのです。
ttps://amzn.to/2I2V1O4
エンジニアでないファウンダーは最大一人まででお願いします | On Off and Beyond
理由１：変更につぐ変更を重ねられるようにする
最近 lean startup なる考え方がはやってますが、これはどういうことかというと、
東大合格者ランキングは正しいのか？――常に分母は何かを考えよ
何事にも閾値はある。そこに至らなければ、意味がないという数字だ。
「頭のいい人が成功しない理由」という本に、閾値の話があった。
だれもが中途半端にやめてしまう。それでは足りない。閾値を越えない。
ttps://ameblo.jp/chimu841/entry-10036171360.html
ttps://amzn.to/2Odv25b
①内製
②外注
フラクタルなレモン市場問題｜建築不動産クラスタ交流会の件その１
ttp://realtor-readyabooks.hatenablog.com/entry/20100515/1273919457
ttp://ledsun.hatenablog.com/entry/2016/02/28/014851
ttps://ja.wikipedia.org/wiki/情報の非対称性
ttps://ja.wikipedia.org/wiki/逆選抜
ttps://ja.wikipedia.org/wiki/取引コスト
「探索コスト」
時給制（時間を売る）が生産効率低いのって自明だよなぁ・・相当ボランティア精神ないと時給制で効率よくやろうって気持ちにならないよね
でも拘束時間で金額を決めてしまっては効率化を目指さなくなるんじゃないか
ttp://b.hatena.ne.jp/entry/b.hatena.ne.jp/entry/194800390/comment/redhornet96
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872820182883762176
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872822997106565120
ttp://getlife.hateblo.jp/entry/2013/09/10/015011
見積もりが人日で工数を計算していると、実際にはそれよりも短期間で実装できても見積もり日数になるまで納品を待ったりすることはある。
納期よりもかなり早い段階で実際には完成しているにも関わらず、
エージェントが利益相反行動をしていないかどうか監視するためのコスト。
自身の行動がプリンシバルの利益追求にかなっていることを証明するために
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1212240292
ttps://twitter.com/search?q=rails%E3%80%80%E9%A1%A7%E5%95%8F
「顧問プログラマ」再考 - Rails 雑感 - Ruby on Rails with OIAX
ttps://www.oiax.jp/rails/zakkan/rethinking_of_adviser_programmer.html
ITエンジニア採用に欠かせない原則とは (1/5)：IT人材ラボ
ttp://b.hatena.ne.jp/entry/s/itjinzai-lab.jp/article/detail/856
ttps://www.slideshare.net/fukumura1/fukuokarubykaigi-medpeer-ver1
【256人がリモートワークで回る仕組みを考える】後編
ttps://www.remotework-labo.jp/2015/10/interview_10/
