はてなキーワード: excelとは
Excelの印刷、WindowsUpdate、山法師、これぞ我が心にかなわぬもの
ワイくんの自認はフェミニストである。ワイくんの定義するフェミニストとは下記
1. the theory of the political, economic, and social equality of the sexes
https://www.merriam-webster.com/dictionary/feminism#kidsdictionary
なお、性別に進化の過程で有性生殖になった以上の意味は無い、役割ロール廃止しよう、ジェンダーレスでいこう派だが、
敢えて、フェミニストを自称しているのは、明日から男女の枠組みを無くしますが今の段階では不可能で、
フェミサイド、性被害、地方の長男の嫁、本家の嫁、ガラスの天井などの現実があるからだ
ついでにキャリアの中断は起きていても、キャリアの断絶は起きていないことが厚生労働省が発表している平均月収を見てわかる
(月収40万後半50万超えてるのに、キャリアの断絶とか言われましても・・・ね)
性別 | 年齢階級 | 高校:賃金(千円) | 専門学校:賃金(千円) | 高専・短大:賃金(千円) | 大学:賃金(千円) | 大学院:賃金(千円) |
---|---|---|---|---|---|---|
男 | ~19歳 | 188.2 | - | - | - | - |
女 | ~19歳 | 178.7 | - | - | - | - |
男 | 20~24歳 | 211.4 | 214.6 | 220.4 | 235.1 | 260.5 |
女 | 20~24歳 | 193.5 | 224.1 | 213.9 | 232.1 | 248.5 |
男 | 25~29歳 | 239.2 | 244.9 | 256.6 | 272.8 | 289.9 |
女 | 25~29歳 | 205.3 | 244.4 | 237.3 | 255.9 | 278.8 |
男 | 30~34歳 | 263.8 | 275 | 290 | 319.3 | 357.3 |
女 | 30~34歳 | 214.4 | 248.4 | 244.6 | 279.2 | 343.3 |
男 | 35~39歳 | 287.2 | 300 | 335.6 | 375.5 | 435.5 |
女 | 35~39歳 | 220.2 | 267.2 | 255.6 | 307.2 | 393.2 |
男 | 40~44歳 | 311.2 | 324.6 | 366.5 | 414.8 | 516.5 |
女 | 40~44歳 | 229.2 | 275.2 | 277.3 | 327.6 | 408.6 |
男 | 45~49歳 | 335.4 | 352.4 | 398.4 | 455.4 | 558.8 |
女 | 45~49歳 | 234.7 | 291.5 | 283.5 | 343.4 | 454.4 |
男 | 50~54歳 | 346.4 | 377.9 | 418 | 500 | 632.4 |
女 | 50~54歳 | 240.2 | 294.4 | 297.8 | 364.2 | 528.9 |
男 | 55~59歳 | 350.3 | 387.2 | 434.8 | 513.8 | 645 |
女 | 55~59歳 | 242.1 | 306.2 | 300.9 | 375.7 | 585 |
男 | 60~64歳 | 279.2 | 302.7 | 318.2 | 377.3 | 558.8 |
女 | 60~64歳 | 211.4 | 271.6 | 251 | 312.4 | 564.6 |
男 | 65~69歳 | 241.2 | 269.3 | 288.8 | 332.2 | 610.2 |
女 | 65~69歳 | 197.2 | 250.7 | 251.1 | 318.2 | 533.8 |
男 | 70歳以上 | 220.7 | 221.3 | 310.3 | 339.3 | 498.2 |
女 | 70歳以上 | 204.7 | 254.1 | 271.8 | 319.6 | 500 |
https://www.mhlw.go.jp/toukei/itiran/roudou/chingin/kouzou/z2022/dl/03.pdf
そもそも労働参加率、73%くらいなんですよね。あと男より月40時間労働時間短いし、非正規率も高い
女性の就業時間 男性より月40時間短く
日本では働く女性の数が増える一方、就業時間の男女差が大きい。総務省によると、女性の労働力人口(15~64歳)は2021年で2679万人、労働参加率は73%と10年で約10ポイント上がった。結婚や出産を機に職を離れる人が多かったが、育児休業などで女性が働き続けやすい環境に力を入れる企業が増加。30歳代など子育て世代の労働参加率が下がる「M字カーブ」の問題は改善しつつある。
ただ労働時間をみると課題はある。総務省によると女性の平均月間就業時間は男性より40時間ほど短い。最も多いのは男性と同じく月121~180時間働く人で全体の4割強を占める一方、月120時間以下の人が3割以上で男性(約1割)より多い。パートや派遣など非正規雇用で働く人の割合が女性は約5割と男性(約2割)より高いことが背景にある。
国際労働機関(ILO)によると、日本の労働時間の男女差は主要7カ国(G7)で最も大きい。週平均の差は10時間を超えており、米国の約2倍、スウェーデンの約3倍だ。
https://www.nikkei.com/article/DGXZQOCA19B3I0Z11C22A0000000/
ついでに、独立行政法人労働政策研究・研修機構『国際労働比較2022』229頁 によると、欧米に較べたら日本の女は長時間労働(週49時間以上の労働)してる方らしいですが、
(逆に言えば下方婚増田は、インドネシア22%、フィリピン20%あたりへ移住すればいいと思うよ)
https://www.jil.go.jp/kokunai/statistics/databook/2022/documents/Databook2022.pdf
女がイージーってのは、自立・家族を養うべく職業経験を積む必要性が無いってだけで、それなりの規模感の会社で本部長以上の役職を目指すというか役員目指すとか言ったら、
女は自立せずとも良いと教育されてきたお嬢様方が、ただ単に働く気がない・職業経験を積む気がないだけ
バカに至ってはせっかく先進国に生まれたのに、自ら性や若さを売って、水商売や風俗したりね
あと、女性の活用とか騒がれる前から不適切なポジションに女を置くことはあった
うっふんあっはんしている女を可愛い可愛いしたいバカが絶滅しない限りはどうにもならないね
令和では職場にセックスを持ち込むやつは滅ぼそう、会社で愛されメイク・ファッションとか言ってるやつも当然滅ぼそう
(プライベートで女性の性表現を追求・楽しむのは好きにしてだけど、職場に持ち込むバカはフェミストを自称する人は積極的に弾圧して欲しい)
いったい何だったらするんだ?以前に、日本のお嬢様がたは平等の言葉の意味を知っている?
これはフェミニズム(社会平等)とは関係なく、単なる母ちゃん教の話なんですけど、母ちゃんがキリキリ働いてるとこ見たい?って言われたら見たくないですね
ようやく、どこのご家庭のおっかあのことも『お姫様』として『母上』としてを扱うことが出来る時代になった、
大切なおっかあを想っても極貧故に報えず涙した先人が報われた時代になったのに、なぜ、わざわざ逆戻りを?って思います
実際、欧米でも女は長時間労働してないですよね?(アジア圏はしている)
人間は幸福になるために生きているのであって、資本家に仕え働くために生きているわけではないので・・・
お金がないので子どもを作るのを躊躇っているご家庭は、積極的に生活保護や各種公助を受ければいいと思います
成り行きに任せたら?子ども作る人は何しても作るので堕胎数が10万割ったことも無いし
(20~24歳の堕胎数が最も多く、次いで25~29歳、30~34歳、35~39歳)
https://www.mhlw.go.jp/toukei/saikin/hw/eisei_houkoku/21/dl/kekka5.pdf
どうせ コロナを経ても世界的には人口増加かつ、AIで人あまりの時代になるのだし
ただ人間がやった方が安い分野って結構力仕事多いと思うので、男の労働者の方が有利にはなるでしょうね
この前、職場の事務職(月21.7万円)の面接に無職のおっさん(48)が来たんだが
そのおっさんが「パソコン得意です。Excelできます」ってドヤ顔で言ったんだよね
おっさんが「できません…」って言い出して呆れた😅
ExcelなんてそれこそパワークエリやVBaできてなんぼなのに
じゃあ何ができるんですか?って聞いたら関数とか…って言い出してドン引きしたわ
そんなん教えたら誰でもできるもんやん
DB直じゃなくてPowerBIのセマンティックモデルとしてAzureADと紐付いた認証認可付きでデータ公開してExcelからPowerQueryとかで接続するのが今時じゃないかな。
他人のことは放っておけ
手作業頑張った感が出る中間ファイル生成させるとかやって、空いた時間で勉強するんやぞ
ExcelVBAの後にどうせだから他のVBAもやっとくかと遊んでたら、OutlookVBAで名前空間と出会って衝撃的だった
会社から365移行するとか言われたんでOfficeScript触って連想配列とかいう素晴らしいものと出会った
GraphAPI使って、メールも含めて仕事してるフリが出来るようになってだいぶ満足感出てきた
さぁ次は何しようかなー
VBA嫌いのExcel師(営業事務)なんだけど、その程度のことをVBAでやろうとするヤツを駆逐したい。
お前は営業や他のユーザーの理解度を自分レベルだと勘違いするのをやめるべき。
うちの会社はVLOOKUP(最近はINDEXとMATCH)組めるのが「Excelできる」と名乗っていい最低限のラインで、営業と営業事務では名乗れないやつはほとんどいない。でもVBAは使える人は稀。
基本はその「難しくてもVLOOKUPの知識を駆使すればなんとかなるレベル」でExcelを組まないと破綻する。
うちの会社の一事業部は複数の会社に発注をしていて、そうすると会社ごとにデータを比較して見たいのに項目や項目順が違って簡単に比較できない、ということがよくある。
その場合マッピングと呼ばれるデータ項目の統一化が必要なんだけど、会社によって合算したいデータがそれぞれ別の方法でしか取れないとか、合算値に余計なデータが入ってるからrawデータ取ってきて件数はレコード数でカウントしないといけないとか、まぁ色々出てくる。
全取引に対してのデフォルト対応としての統一マッピングはしてるけど、そういうのはVBAでやらずにSaaS使ってるし、ものによって重視する値が変わるので例外が2割くらいある。うちの会社はその辺りの裁量が営業に認められているので例外も多め(なおオンリーワンになりたいためだけに特殊対応した奴は一人を除いて矯正or自滅済)
そういう融通をきかせるのにExcelの計算シートでマッピングするのは絶対。
あとVBAだと営業側が「どういう計算をしてるのか」とか「正しい数値が出てるのか」が確認できない。
っていうのは例えば100円3件と150円2件の仕入れにうちの取り分2割乗せて720円として見せたかったのに、『=100*3+150*2*1.2』って数式書いたせいで660円になっとるやんみたいな。こんなんよくある眠い時のヒューマンエラーで、VBA書く人ならやらかさない、なんてことは絶対ない。
しかも営業がこういうのの修正とか提案用にちょいちょいと列増やして数式入れようとしても「マクロ壊れるからやめて」とか言われる。営業が自分で調整可能なら1時間以内でできるものでも、VBA書いた人に依頼しなきゃいけないんだと、書いた人の通常業務との兼ね合いで1週間待たされたりする。
営業に金稼がせるためには営業の利便性と裁量は必須で、Excel利用者に裁量権が認められてないVBAのツールなんか全体最適化されてないクソ。
※なお裁量大きいからってあんまり好き勝手するとやらかした時に他の助けも得られず(やれることに限界がある)自滅ルート
自分も軽くVBA習得してるんだけど、フォルダ内のデータ一括読み込みとシートの分割統合の関数代わりにしか使ってない。しかもただの効率化なのでVBAが死んだところで手作業に戻せる範囲。
他人が保守できるように作るのならVBAなんか入れるべきではないし、VBA入れないなら計算シートは必須。あと計算周りを大掛かりにやるならSaaS入れてDX検討すべき。
原則関数とピボットテーブルのみで完結させ、マクロは使わない。ってのが良いと思う。
DBからデータぶっこ抜いたり(今のご時世は出来ないと思うが)、外部ファイルを読み込むとかしないで、ブック内のデータを処理するだけならマクロいらんやろ。
数十万以上のデータ件数になるとさすがにきついけど、そうでもなければ関数駆使すればだいたいいける。
てか、Excelはお絵かきソフトであって、表計算として使うんならGoogle Spreadsheetの方が絶対に良いわ。
EXCEL原理主義からするとマクロを入れる時点でワークシート関数は入れない。
複数行コピペでやりたい時だけ、入力用の空シートにするけど、それだったらCSVのファイル連携。
1ファイルを配列に突っ込むのはメモリが怖いのでやらない。今ならほぼ大丈夫だと思うけど、ストリームで処理する呪いにかかってる。
商品マスタとか参照するときに、外部データ範囲でDBからマスタをシートに張り付けて使う。1万件ぐらいまでならデータをADOとかで取ってdictionaryに入れて検索するより、シートからVLOOKUPで取るほうがよっぽど早い。
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて(キラキラ)」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
3行でまとめます。
〇 エクセルシートはユーザーインターフェース(インプット)か出力結果(アウトプット)のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列(連想配列)に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
(もちろん、ユーザーインターフェースの別の欄(セル)に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。)
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
(これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…)
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
1.元となるcsvファイルをエクセルに読み出してシートに格納
2.そのデータは日付が数値型になっているので、日付(数値型)の入った列を文字列に変換した日付(文字列型)列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず(あるいはエクセルのセルオブジェクトを変数のように扱い)、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか?。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列(連想配列)と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
(逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・)
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列(連想配列)で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
(参考)【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
(参考)Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ(VBA)から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列(連想配列)のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある(ローカルウィンドウやDebug.printを使うなど)ので、リハビリに取り組んでほしいです。
(参考)VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
(最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。)
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用(加工用)のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ(VBA)は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
(あと、コマンドプロンプトの真っ黒な画面が怖かった)
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
(そのやさしさが上述したとおり悪魔の罠なわけですが。)
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
冠婚葬祭以外でスーツもろくに着たことのない人間が、まともな職業に転職することは可能ですか?