  |
はてなキーワード: 発注とは
上野東京ラインの川口駅停車が正式決定されて「あそこは乗降客多いから当然」とか「停車駅増えるのヤダ」とか巷間喧しいところであります。
そこで川口駅の事をちょっとだけ知っている増田が川口駅のあれこれを少しだけ説明するよ。
川口駅の西側は1980年代までみっちりと町工場が密集していて、特に線路に面したところは国の燃料研究所（後に公害研究所）という大工場があったので、西口広場ってものは無かったのよ。
この公害研が廃止され環境研に改組されたのでその空き地に西口ロータリーを造る事になった。
だがこの当時に、今の湘南新宿ラインの元になる東北本線池袋乗り入れが開始されたってわけ。
そこで川口市は駅の西側にこの列車用のホームが増設できるように何も建てない土地をワザワザ造って、「池袋支線停めてよ」アピールをする事にしただった。
場所はここ。https://maps.app.goo.gl/eiJk19EmifLCYrzCA
しかし、これ無理だろ？と気が付いた人も多いかと思う。現在の湘南新宿ラインは15両編成だから隣の10両用京浜東北線ホームの1.5倍になり、ホームを造るには全然長さが足りないんだ。
なんでこうなったの？というとその後の川口市がいけないのだ。
実はこの「川口西口緑地噴水」の場所は駅前ロータリーだった場所なのだ。つまりは道路。こんなせせこましい場所でバスの方向転換とかどうやってたんだか？
で、ここは大きなロータリーを別に造るから廃止になるんだけど、池袋支線のホーム用地にしよう、という事で期待を残して建物を建てなかった。
だけども公害研跡地再開発では人工地盤の巨大公園、更にその下の1階と2階にはコンクリート製の駐輪場を造ってしまったのだ。ホーム用地にすんのかしねえのかで全く平仄が取れてねぇ。やる気に統一感がなかったのだ。
だからホームを造る為に線路敷きを拡幅するには立体駐輪場と公園を一部破壊する超高額な工事をせにゃならん。
詰んでるじゃん。…ところがそうではないのであった。
駅の東側線路際に大きな駐車場が見えるだろう。ここ、実は川口市の土地なんだな。だからここを利用して線路全体の線形を変えるって方法でも行けるって訳だ。
なんで川口市がこの土地持ってるの？かというと、ここは川口貨物駅だった場所なのだ。正確には貨物駅は東口のきゅぽらという高層建物、その隣の駐車場、タワマンの場所にあった。駐車場の場所は貨物駅に入る為に線路が輻輳してあった場所だな。
国鉄は超大赤字を積み上げており、特に貨物営業に人が多すぎで、人件費が莫大だった。
そこで国は思い切って貨物営業をほぼ全廃してしまう事にした。石油の直通便とかコンテナだけ残す。
それで全国の貨物駅は遊休施設となった。例えば都心部だと新宿の高島屋スクエア、渋谷の南口オフィスビル群、汐留の電通とかあのあたり、秋葉原のヨドバシなど、飯田橋3丁目のオフィスビル群などは貨物駅だった所だ。
次に国鉄を民営化する事になり、その遊休土地は国鉄清算事業団に移管される。売却益を赤字補填にするというスキームやね。
それで川口貨物駅の施設は川口市ががっぽりと全取りしたってわけ。
んで駅南側は立体公共駐車場とか貸しビル＆図書館＆市役所出張所のきゅぽらなんかを建てた。そして北側はそのまんま。何分元が複々線線路だから狭くてビル建てるには手狭。でも元が線路だから線路用地にするのが一番やね。
但しそうなると駅全体を改造する事になるから工費はかなりのものになる。新駅ビル建造込みの工事になるかと。
因みにこういう時、JR線路部分の工事は他社にやらせないで自ら発注するのしか認めないのね。事故があるとヤバいから。だから自治体に金だけ貰うって形になる。
ただ、この全体線形変更案は増田の予想なんで、実際はどうなるかは判らん。立体駐輪場と公園を壊してホーム用地を西口方に確保するかも知れないし、南の方へ伸ばして途中の家屋を買収するかも知れない。そこはまだ全然決まってない。
あと、東口の駅舎（と言っても階段があるだけ）と京浜東北線ホームとの間に隙間のデッドスペースと飲食、床屋店舗群があるけど、そこも川口市有地でここも活用できる。
とするとやっぱ全体を東に移して駐車場活用案にあるんじゃないかと思われる。
電車に乗ってると気になるこれだけど、 https://maps.app.goo.gl/uPyzTQ8tn1QQhPTQA
これはなにかというと、貨物駅に入る為の乗越線だったものだよ。
貨物駅が貨物線（現湘南新宿ライン線路）と反対側にあるから、貨物列車が駅に入る時には東北本線、京浜東北線を全部横切らなきゃならない。その為には全部赤信号にして止めなきゃならないから大遅延の元になる。
そこで乗越線で立体交差にした。
昭和43年まで赤羽から大宮は京浜東北線と東北線の複々線だったんだけど、東北線と高崎線の特急を増発する際のボトルネックになっていた。貨物列車が多いし、新幹線が無い時分だから新潟行きも仙台行きも秋田行きも青森行きも全部ここを通る。
そこで貨物線を増設して貨客分離する事にしたんだが、問題になったのが川口貨物駅。貨物線と反対側にあるこの駅に線路を全部渡って行くったって、既に京浜東北線は通勤ラッシュ常態化で、東北線も列車増発の為に線増したのにボトルネックを造ってどうする。
ってことでこんな大がかりなものをこしらえた。
因みに運転は結構大変で、なにぶんにも片方しか入れない。そこで下り列車であれば、一度蕨駅まで行く。そこで機関車を後ろに付け替えて今来た方に出発。西川口付近で乗越線に入って川口貨物駅に到着。
逆に上りでは駅に着くのは普通でいいが、出発後はやはり蕨駅まで行ってから、機関車を付け直して赤羽方に出発という何とも迂遠な方法を取っていた。
貨物駅廃止で不要になった筈だが、廃止された線路の一部を保線用基地に転用した為に、この乗越線を使って湘南新宿ラインの方にレールを輸送するので残されている。
そもそも貨物駅が貨物線と反対側にあったのがいけないのだけど、川口アリオの場所にビール工場があったのでこっちに造られた。ビール輸送は鉄道貨物の大お得意さんであったので無視できないのだ。
因みにビール工場がここに設置された理由は、見沼代用水の分水が取水できた為で…（以下略
鉄の製造には3種類あって、
1.鉄を融点以上に加熱して砂型に入れて固める鋳造（出来るのは鋳鉄）
3.圧延ロールで押しつぶして板状に、またはパイプ状や棒状にする圧延
というのがある。今一番使わているのは圧延で、何段にも圧延ローラーを掛ける為に長いラインが必要になるので工場も資本も巨大になる。量産効果で製品単価は低くなる。
キューポラ炉はたたら製鉄の応用で、コークス（石炭を乾留して硫黄分などを飛ばしたもの、結構高い）→鉄→コークス→鉄とウエハース状に重ねて入れて鉄が溶ける温度を確保する。
投入口が2～3階にあって取り出し口は1階という結構大がかりなものです。
鋳鉄は炭素が多いので、コークスは温度を上げるだけじゃなくて鉄に炭素を含有させる働きもあるのだ。
このキューポラが沢山稼働していたから昔の川口は大気汚染がすごかった。炭塵だけじゃなくて鉄が溶けた蒸気（ヒューム）も混じってるから健康には悪い。
あと一つ入らないのでその二に続く
IT職が何を指してるかはわからないけど、今ある他のリソースに割いてる労働力を消して、車椅子運んで補助するくらいすればいいとは思ってる。
・ポップコーン売ってる店員、食べ物は汚れるから廃止した方がいい。キャラメルなんてもってのほか。
・飲み物も清掃の観点から糖分なし、アルコールなしにすればいい。自販機で十分。
・グッズ販売、品番だけ揃えてアプリから購入して後日家に届くようにしろ。
・映画パンフレット、アプリでDLすればいい。物理的に持つなんて邪魔。不要。
ここで必要になるのは清掃と警備くらい。顧客動線のサービス、不要すぎるもの多すぎ。
ここで空いた労働力を車椅子移動の補助やベビーカー補助に回す。リソースが足りないならこれくらいすればいい。
映画館にスナックやドリンクの動線はいらない。どうしても必要ならアプリで専用の自販機で発注して受け取ればいい。
補助される客がいない時は、浮いてる労働力には道案内的にその辺に立ってもらうとかでいいと思う。
「スケジュール管理等の秘書業務を外注しようと思う」というツイートをした。
「夫はフルタイム正社員だし、せっかく今うまくいってる夫婦関係に仕事を持ち込むとこじれそうだから、その選択肢は無いなぁ」と返した。
何らかの制作を依頼する…とかならまだしも、私が外注したいのはスケジュール管理をはじめとする秘書業務だ。
ただでさえ〆切に追われているうえに、夫とはおなじ部屋でリモートワーク。
進捗確認でピリつく未来が想像できるので、夫婦から仕事仲間になることで関係が悪いほうに変化するリスクもある。
もちろん夫は協力してくれるだろうが、
精神的に疲れていて今は薬を服用していることもあり、退勤したら休ませたい。
…といううちの家庭内事情・ワークスタイル事情も知っているはずの友人Aは
「仕事を持ち込んでこじれちゃうなら、それまでの関係だよ」と言ってきた。
瞬間、自分の脳は一瞬キレた。
・私は仕事と家庭を分けたいから夫に自分の仕事を任せるわけがない
・という様々なことも頭に浮かばず「こじれるならそれまで」と説教するのか。無責任な発言をする奴だな…
仕方がないので「私が仕事と家庭を混ぜて生活できないんだ」と返した。
友人は「あぁｗそっちねw それだと育児大変そうだなぁ」と言ってきた。
私はしばらくは子供の予定はないが、今は仕事に専念し3年後あたりに作ろうと夫と決めている。
きっと友人Aはうまいこと再婚できたら、私と違ってすぐ子供作って育児に専念するんだろう。
毎月5万程度しか稼がず、28歳になった今でも親の仕送りで家賃を払って、私を誘い三越伊勢丹でスイーツを買っている。
ざっくり調べた所発端は一か月前くらいに自分の動画を元ネタにしたグッズを出す際に
動画で使ってるイラストが商用利用不可だったからなのかイラストレーターに話を通さずに
別のイラストレーターに「似たような絵」を発注して製作したのがあまりにも仁義を欠いているとされて炎上したらしいな
それが今まで鎮火せずにコラボした投稿者への誹謗中傷や個人情報掘りまで起きてるので
コラボした投稿者が声明発表を求めるも無下にされたのに怒って真偽不明の暴露というのが昨日の話か
個人的にはファミレスや焼き肉屋の動画で食わずに捨ててたりしてたらもっと早くから炎上してただろうし
岸田首相が建設業界に賃上げを要請したニュースが飛び込んできました。
まずは岸田首相，ありがとうございます。
しかし，事情はもっと複雑で，労務単価の引き上げで救えるのは全国規模のゼネコンと全国規模の専門業者だけです。
そもそも「労務単価」とは何か。ざっくり言えば，現場で作業している人たちの1日分の給料の基準です。
公共工事はこの基準をもとに金額を計算するので，労務単価が上がれば公共工事をやるときに建設会社がもらえる金額が増えます。
だから「労務単価を5.9％上げたから，その分給料も上げてくれ」と言っているわけですね。
ごもっともです。素晴らしい。おそらく全国規模の業者は初任給がかなり上がることでしょう。
しかし真に人手不足に苦しんでいる地方の中小建設企業は助かりません。
技能者の不足も深刻なままでしょう。
中小建設企業が人手不足なのは，単純に「給料が低いから」ではありません。
私は田舎の中小建設会社で監督をやっていますが、建設業は比較的賃金が高い部類です。おそらくこの傾向は都会でもそう変わりません。
加えて，近年の建設業界は未経験者に優しい傾向にあります。施工管理技士の試験制度が改正され，資格取得の際に学歴がほぼ関係なくなりました。
試験に受かれば，現場で必要な経験年数は高卒も大卒も建設学科出身者もそれ以外も皆平等です。
人材にわがままを言える全国規模の建設会社は別として，中小の建設会社は未経験者や畑違いの人間も大抵は採用しています。
しかしながら求人は埋まりません。新卒が毎年入社するのはもはや珍しい事態です。
非正規雇用や正規雇用でも給料の低さに苦しむ方はいる。建設業はそこそこ給料が良く未経験者でも採用される確率が高いのに人手不足に苦しんでいる。
結論から言うと，全国規模の大企業は別として，多くの中小建設企業や技能者は「労力に給料が見合ってない」から不人気なのでしょう。
建設業の給料は相対的に高いが，「こんなきつい仕事はその程度の給料でやりたくない」というのが実態ではないでしょうか。
ではどうすればよいのか。
法外なほど給料を上げれば建設業は息を吹き返すでしょう。しかし，国の予算は有限で，ある程度は公共工事を安くしないと文字通り国が滅びます。
給料を上げると同時に，もう1つの要素をなんとかしなくてはなりません。
これから先建設業界が生き延びるには，労力を下げ，給料を上げなければならない。
労力を下げ，給料を上げなければならない。しかし，建設業界は労力を下げる努力を怠っていました。
資料によると，建設投資は平成4年をピークに平成23年まで下がり続け，それ以降は上昇に転じています。
一方，建設業就業者数は平成9年をピークに平成23年まで下がり続け，それ以降はほぼ横ばいです。
平成9年から平成23年までの間は，「仕事は少ないが人は多い」状態にありました。
10ある仕事を5に減らせる技術があったところで今は20人いますから必要ないです，と省力化は進みませんでした。
業界全体が真面目に省力化を始めたのは，建設投資が増加に転じたここ10年くらいの話です。
しかし遅すぎました。15年のビハインドを取り返せる体力は中小建設企業にはもう残っていません。
他業が5年〜10年前には既に使っていたような技術を最新技術のように持て囃す有様です。
「建設業は安全第一だから枯れた技術を使う」とか関係ありません。単純に公共工事の基準の整備や業界の人間の知識が遅れているだけです。
そして人手不足がさらに技術の導入を遅らせる，負の連鎖から抜け出せていません。
建設業の現場を地獄に等しい状態にしている黒幕は民間工事です。民間建築工事は地獄です。
国の工事は土・日・祝日を休む前提で工期の計算や賃金の計算が行われています。
都道府県レベルでも少なくとも土・日は休む前提です。ですから，国や地方自治体が発注する工事は，かなりホワイトな工事です。
やばいのは民間企業の建築工事です。発注する人の頭には「いつから建物が使えるか」しかありません。
発注者も営利企業である以上，早く建物を使いたい，工期を短くして安くしたいというのはごく自然な考えです。
しかし4週間で6日休みを前提で考えています。「ちょっと頑張ってもらって日曜以外は工事してもらおうか」なんて考えてます。
自社の社員にはやらせないことを，平気で建設業に要求する奴らです。
「不当に短い工期設定の禁止」などと言われていますが，仕事を頼む側が圧倒的に強い力を持つ以上，どうしようもありません。
建設業自身の問題や建設業を取り巻く環境の問題が建設業を崩壊へと導いています。
今までの建設業界の怠慢と，建設業を軽んじる風潮とが原因ですが，これらは今さらどうしようもありません。
建設業が少しでも長く生き延びることを祈ってください。
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検討すべき。
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
https://anond.hatelabo.jp/20240227112810
の続きです。
今回は壁紙について。
じゃあなんで壁紙をテーマにしたかっていうと、壁紙の張替え費用は退去トラブルの原因になりやすいからだ。はてなブックマークでもたまに「退去費用を、取り戻す。」みたいなテクニック集が上がってくるよな。
俺は自慢じゃねえが、自主管理を始めてから退去時の敷金返金についてお客さんからクレームをもらったことが一回もない。そのカラクリはめちゃくちゃ簡単で、敷金を全額返しているからだ。
賃貸住宅の退去時の費用負担については国土交通省からクッソ細かいガイドラインが出ている。壁紙についてだと、6年で価値がなくなるものとされている。これを言葉通り解釈すれば、6年以上住んだら、お客さんが壁紙をどんだけ汚していたとしても、壁紙の張替え費用は請求できないという事になる。
じゃあ、2年とか3年で出ていくお客さんだった場合、どの程度汚したら、どれくらい原状回復費用を請求すればいいんだ？
いちいち全部お客さんと現場で対面で話し合って、「うーんここが汚れてますね。国土交通省のガイドラインを一緒に見てみましょう。こういうルールになってるんですよ～。◯◯円負担してください。こういう計算式になってまして…」なんてやるのか？
めんどくせえ！！
そんなのいちいちやってられっかよ。
俺のやり方はクッソシンプルだ。
退去立会いはやらねえ、引っ越しが終わった後のカギの返却もいらねえ。そのまんま捨ててもらってる。
カギは俺んとこに緊急用のが1本ある。だから、契約期間が終わったらその翌日か翌々日にはそれを使って中に入り、カギはその場で俺が新しくシリンダーを交換して従前のカギでは中に入れなくして、古いカギは捨てちまう。まあ、契約期間が終わってから室内に入ろうとするお客さんはいないと信じているが、いちおうな。
あとは室内の汚損状態や設備の状況を確認して、次のお客さんを募集するにあたり直すべきところは、馴染みの業者さんに修理や交換を発注する。
そこまで終わったら、その日か翌日には預かってた敷金をお客さんに全額振り込んでいっちょあがりだ。ここまで、契約終了日から1週間もかからない。
全部返ってくるならトラブルになりようがないよな。
ただまあ、これには俺なりの考えがある。
仮にこれを折半してお客さん5万、俺5万の負担にしましょうって事で話をまとめたとしようか。ほとんどのお客さんの場合、その5万円の原資となるのは勤め先からもらってる給料って事になるんだけど、これは税引き後の金だ。
だから壁紙の張替え代5万円を業者に払っても、その金額が今年の所得から控除されて、その分来年の税金が安くなったりするわけじゃねえんだな。ここが大きく違う。
一方で俺の場合は、壁紙の張替え費用は今期の不動産所得を計算するのに費用として計上できる。その分所得が減るので、早い話が来年の税金も減る。そういう意味で、同じ費用を負担するにしても所得から控除できる分、制度的に俺の方が有利なのよ。
それなら、負担区分をいちいち話し合うのもめんどくせえし、俺が負担するって事でいいよ、ってのが俺の考えだ。
理屈はわかるが、そんなやり方で大丈夫なのか？って思う人も当然いると思う。ほとんどのお客さんの場合はこのやり方で全然大丈夫だ。
もちろん、中にはすげえ汚く使う奴もいるよ。「これ、次のお客さんに貸せる状態に戻すのにいくらかかるんだよ……」って冷や汗をかいた事もある。たとえば俺んとこはペット禁止だが、過去には勝手に犬を飼っていて退去時にその犬を室内に残していった超クソ野郎や、ゴミ屋敷にしたまま出ていった超バカもいた。世の中にはこういう人間のクズがいる。
確かにそういう客ばっかりだと、所得が減れば税金も減るからオッケーオッケーなんて悠長な事は言ってられなくなる。場合によってはこっちが破産しちまうから、そういう奴に対しては入居者負担分の原状回復費用をルール通り適用して、きっちり回収する。
だが、しばらくこの仕事やってると、そういう「ルールを守れないクズ」には職業や特性に一定の傾向がある事が見えてくるんだな。
だからそういう奴が今後入ってこないように、一回痛い目を見たらきっちり記録を残し、以後に似たような属性の奴らから申し込みが来た時は入居審査時に断るようにしている。
そうするとだんだん入居者層が洗練されてくる。
そしたら、契約終わったら敷金は速攻で全部返してオシマイ！なんていうイージーな方針でやってても、全然ビジネスとして回る。
（ちなみにそのあたりの入居審査ウラ話を去年の夏ごろに増田に書いたら、差別だあ！とか言われてぴえんになりました。チッ、反省してまーす）
俺のこのサッパリしてるやり方は、お客さんにはそれなりに好評だ。なので、転勤で俺の物件から引っ越す事になったが、また何年かしてこっちに戻ることになり、その時に「空いてる部屋があるなら増田さんとこで」って客付けの不動産屋で俺の物件を指名して、また入居してくれる人もいる。ありがたいことだ。
あと、全国に支店のあるような超大手企業が、単身赴任者のための部屋を借りる事がある。そういう場合、社宅代行会社という代理人的な会社がいて、そいつらがその大手企業の代わりに諸々の手続きを代行することが多い。
で、社宅代行会社なんてのはなるべく多く敷金を取り戻して、クライアントの大手企業様にお褒めいただくのが仕事だ。だから解約通知を入れてくる時などは「解約じゃ！戦争じゃ！このクソ大家かかってこいや！」って感じでもう鼻息がフンフンしているのがわかるw
そこに対して、俺なんかは早けりゃ契約終了日の翌日には全額返しちまうので向こうもだいぶ拍子抜けしている。
ただ相手にしてみれば話が早くてこりゃいいわって事なんで、そういうとこを気に入ってくれた法人のお客さんが、俺の物件を指名してくれて何部屋かまとめて借りてくれる事もある。そういう大手企業のお客さんなんかは当然滞納なんてないし、実際に入居する社員の人もまともで入居中のトラブルはまったくないしでこっちも前前前世、じゃなくて大大大歓迎だ（おもしろくねえな、スマン）
俺のやり方だとこういうメリットもあるし、さっき書いたみたいなクソ客に思わぬ損害を与えられるというデメリットもあるということだな。
ただ、こういうやり方ができるのは自主管理であるがゆえにスピーディに決断ができるからで、他の大家に同じようにやれって言ってもなかなか厳しいと思う。でも世の中的には退去時の諸々の費用はどんどん貸主が負担する方向になっていってるから、こっちもそれなりに対応していかないとね。壁紙なんかはめんどくせえから、俺なんかはもう全部大家負担にしといていいんじゃねえのって思っちゃうけどね。
壁紙はこんな感じ。申し訳ないがリフォーム全然関係なかったな。
色々開発に携わってきたが大体2パターンある
Case month when 1 then ~って感じのコード。thenの後にif文や更にCase文がある。この辺りに28日までとか書いてある。
ソースレビューがあったら指摘する内容だが機能していない場合はこのレベルが来る。オフショアで海外に出すとマジでこんなの書いてくる。指摘するとはいはい言うけどどうすれば良いのか悩む。
アーキテクチャ次第だが単に29までに変更すれば良い場合もあるが、たまに他にも影響したりして結構絶望する。月末日取得で書いてたら説教レベル
大体Case文パターンでロジックが考えられない場合国内外が提案してくるのがマスタ化だ。発注元も何故か柔軟な対応が出来るからと賛成してくる
結果年1や月1のマスタ設定が必要になり運悪いタイミングで担当者が閏年を忘れてると大体起きる。賛成した人らは運用しないので気楽だ。
こっちはマスタ設定すれば良いのだが、閏年ですよ忘れていませんかチェックは無いくせに登録出来るのは翌日以降チェックはしっかり入ってたりする。
設計段階で考慮すれば良いのだがマスタは何故か新人の仕事となり結果糞仕様にスキル不足が重なって復旧に時間がかかったりする。もちろん新人に罪は無い。日付をキーにするマスタなんて要件で考えた奴が悪い
閏年に影響されない業務やフローにする。そもそも年月日を指定するか2/28の次は3/1だと明示しない限りはシステムは閏年でバグを起こさない。
もし日付チェックを自作の変なロジックで作って発生させてたら20代なら許すが30代以上は即引退して他の仕事探したほうが良い。変に生き残って上流に行くと出来上がるのは意味の分からない事を言うステークホルダーという老害で将来はコンサルとか名乗って中小零細で惨めなシステム論を語る粗大ゴミだ
