  |
はてなキーワード: メンテナンスとは
増田で書くのも何だが、子供の幼稚園選びに本気に迷ったという話を書いておく。
自分の住んでいるところは11月1日に全ての幼稚園が面接を行うので、併願が非常にしにくい環境にある。頑張って併願したところで、面接代を両方に払って問題を先送りしてるだけなのでやめた。
親が決めにくいからと子供に聞いてみたら、3歳児が要領を得る答えをするわけも無く、どの園に行きたいかは毎日変わり、ますます混乱する。そもそも、語彙力があまりないので紛らわしい名前の幼稚園を混同していたり、記憶が混濁しているとしか思えないことを言ったりする。
結局我が家で子供の行く園が決まったのは11月1日になってからだった。選ぶ時の比較要素はこんな感じだった。
家庭は社会からの逃げ場で無くてはいけないという想いがあるので、子供の嫌がる食事はあまり出さないようにしているが、それだと子供の経験できる食事の幅が狭まるので給食があるところにしようと思った。
人間が認識できる人数は数百人程度という話をどこかで聞いたことがあるので、園児数が多すぎるマンモス園は避けることにした。
この条件ですでにかなり絞れていたのだけれど、それ以外はどちらにもいいところ・悪いところがあると悩むことになる。
10月31日は日付が変わるまでけんけんガクガクの平行線の議論をした上で、見学に行った時に児童の雰囲気がよく、生活リズムが想像できた幼稚園を選んだ。
幼稚園によって児童の雰囲気は面白いくらい違う。見学に来た人たちに絡んでくるところもあれば、認めてはいるもののシャイになって絡んでこないところ、排他的な態度をとるところと様々。
どこで経済を学んだのか知らないが、まるで違う。
あのな。職人が機械を使って生産した製品は「職人が一人で生産した」のと同じだ。
給与労働者である従業員は、会社の経営上は「機械」と同じ。ある程度自分で考えて動くかもしれないが、経営責任をとる主体ではない。
対価（エネルギーor賃金）をもらって命令（電気的にor書類で）に従い、規定の時間だけ仕事に従事する。
会社と従業員の取引は「賃金」対「労働力の提供」で終了しているのだから、その先のことは従業員には関わりない。
たまに「君達のおかげで…」などと従業員に向かって涙を流す経営者もいるが、あれは道具を愛する職人が道具に話しかけたり、機械に油を指すのと同じメンテナンスに過ぎない。
つまり、企業の富は「経営者が」「従業員を使って」「一人で」生産したものだ。
従って、資本主義において経営者（資本家）に富が偏在するのは当たり前だ。もっとも、極論、経営者（資本家）もまた、拡大しつづける金（資本）の奴隷として果てしなく事業を拡大していくだけの存在に過ぎない。そこでは、真の主人は金、つまり資本である。
意味不明なものが多いし何かとケチつけないと気がすまない性格だから面倒なことを一々と
直接のユーザからの意見なら多少は変でもそのユーザが必要としてるなら納得できるし、イライラすることもない
社内でそんなことこだわったところで実際には気にされないことが多いのにだ
まだデザイナーがデザインについてこうした方がUXがいいねみたいなことをいうならわかる
専門の人の意見だし
そうでもないのに何かと文句をつけてくる
CSS すらまともに使いこなせずマージンもパディングもないような酷い作りのものしか作らないのにソッチのほうが良いという
色は red, green, yellow と標準のペイントのデフォルトカラーかよというような色を指定してくる
#fcfcfc や #0a0a0a なんて使おうものなら白と黒にしろと
max-width を指定せずに画面の端から端まであるようなものがいいという
今の時代のアプリやサービスを全く見てないのか？としか言えないようなセンスだ
自社サービスなんて手を出したらこれは酷いと話題になりそうなものだ
見た目にあまりこだわれない社内用サービスしか作ってないからと言って、その他サービスをみてる人からすれば明らかに
しかもデザインに限ったことではないがまだ序盤の時点で言っておけばいいものの完成後にいまから変えるなんて難しいのが
わかりきってるようなときになってからああしろこうしろ言い出す
先に書いたようにユーザの要望ならまだ仕方ないと言えるがなぜこんな無意味なことに付き合わなければならないのか
わりと自分が完璧主義なところもあるので作るならちゃんと作ろうとしてるんだが
こういうのを相手にしないといけないせいで結局グチャグチャになってくる
色のバランスやレイアウトを考えたところで一瞬でそのバランスが無意味になるようなことになる
プログラム側だって全然関係ないものを無理やり入れ込まないといけないようなことになることも多い
疎結合だとかグローバルをつかわないとかそういう作りやすくするためのことをしていても
それが維持できないような無茶で無意味な指示が出る
根本的に変えたり対処するためのものを作るとかすればなんとかできなくはない
過去のプロジェクトでもそういうのが多いから自分で作るのくらいは扱いやすくしたいと考えていたのだが
過去に言われたものだと速度を優先だとか言って自分で作ったものよりは遅くするなと言う
しかしながら関数は使わずコピペだわforeachなどは使わずループ変数を使って地道にやるなどメンテナンスが
できる気がしないが速度においては早いと言えるものだ
当たり前のようにグローバル変数がいっぱいあるしライブラリの使用箇所はカスタマイズするための仕組みがあるのに
便利で読みやすいような書き方だと速度的にはそれに劣る
だがわざわざそんな扱いづらいし見づらいコードは書きたくない
そんなに速度にこだわるなら勝手に一人で機械語でも書いてろよって思う
どちらか取捨選択すべきものなのに両方みたせとか無理なことを言う
ちなみに便利なライブラリは基本無駄が多い遅いものだからライブラリ頼みのベンダはクソだとか
能力がないだとか言っていた
そういえば昔先輩社員と仕事したときには変に凝ったものとか必要以上に作り込んだりはしないほうがいいとか
言っていてそれなりに手抜きでさらっと一応は動くようなものを作っていた
私はそういうやり方が嫌いだったのだが今ではこういう環境に長くいた結果仕事のものにこだわって作り込んでも無駄
ということがわかってそうなったのかなと感じた
自分でもサビ残や休日に無償出勤してまでいいものにしようと努力はしていたが謎の指摘に合わせていると
愛着もなくなってきたし後は適当に済ませてしまおうかなという気持ちだ
ちゃんとした自分なりの完璧なものを作ろうとするなら仕事ではなく趣味で作ってるツールやライブラリで
やればいいかと思う
作ったもの次第でユーザが集まる自社のウェブサービスやパッケージの商品やゲームなどは作り込む方が
良いと思うが先に値段が決まって受注して作るようなものだと最低限の要望さえ満たしていればあとは
どうでもいい
むしろ不便な方が改修依頼が来て稼げる
さらには綺麗で完璧な作りで大抵の想定できる改修は１日とかからないようなものに仕上げるよりも
どこ変えればいいかや影響範囲すらわからないくらいモノのほうが実作業時間が多いのでそれだけ請求できる
先に作り込むメリットがない
ストレスが溜まってきたので発散がてら書いてみたけど疲れてるのかわりと分かりづらい文章になった
けどまぁいいか
そろそろ転職でもしたいなーと考え始めた
