ソレはきっと、ビューティフル・ドリーマー

直近、インスパイアされたのはこの記事なのですが。
https://www.fnn.jp/posts/00417790HDK

――なぜログインパスワードは暗号化されていなかった？

宅ふぁいる便は20年ぐらい前から動いているサービスで最初から暗号化はされていませんでしたが、いつか暗号化しなければならないという予定はありました。
ただサービスが大きいことと資源の問題などもあったため、計画を立ているところで今回の漏えいが起きてしまいました。

うんうん「ありがちだなぁ」と。

「収益に直接的にプラスに直結する実装」以外について、割とよく見かけるのですが………特にセキュリティホール関連。次点として「おウンコ汚い書き方のコード」とか「マジックナンバー埋め込みまくり」とか。
諸々に曰く「後でやります」。

後で、って、いつ？

おいちゃんがまだ若かりしころにあった「うる星やつら2 ビューティフル・ドリーマー」という映画がありまして。
まぁ端的には「繰り返される今日、永遠に来ない明日」という感じが、物語の主軸の一つになるのですが。

「明日やります」って、大体こないんですよねぇなんかしみじみ思い出すんですよこの映画を*1。

んで、まぁ重い腰を上げて「んじゃ、着手しますか」となっても、多分手始めに「まず全体の調査*2」が必要で。
それにもそこそこコストがかかるんで、一定確率で「ここで零れ落ちる」んですよねぇ気力とか財力とか諸々が。

んでまぁ結局「じゃぁいったん今はなしで。後日、対応しましょう」で以降永遠にループ。
「明日」っていいよねぇ永遠に来ないんだから(笑

いやまぁ真面目なお話をしますと。
実際問題「今、直近に最優先で」やるべきかどうか？ ってのに疑問符が付きつけられるのはまぁ、色々とわからんでもないのですが。
ただそうやって「いつまでも後回し」にすると「そのうち痛い目にあうよ？」という現実は、宅ふぁいる便さんが「これでもか！ これでもか！ えいっ！ えいっ！」ってほど思いっきり、実現化してくださいましたので。

恐らく「後回しにしたタスク」は、重要度をインクリメントしていって、ある程度までは後回しにしても「ある程度以上」は後回しに出来ない、くらいのなんかギミックがあったほうがいいんじゃなかろうか、って思うんですよねぇ。

なんてことを、色々な諸々を思い出しながら。

*1:映画は多分「傑作」の部類だと思われるので、ご覧になったことがない方は、一度くらい見ておいてもよいんじゃないか、と思われます

*2:映画だと、ハリアー戦闘機と戦車の大砲で「全体把握」を試みてましたねぇ

静的変数について調べてみた

マニュアルに「静的変数(static variables)」って書かれてるやつ、ですね。
端的には、関数(含むメソッド)の中で

function hoge() {
    static $i = 0;
}

とか、ってやつです。

で、これ、メソッドでも書けるのですが。
その時の「staticで保持している単位」が今一つ不明だったんで、ちぃと興味があって。
マニュアルに書いていない(と思う。記載があったら、箇所を教えていただけると幸い)内容なんで。
一端、PHP PHP 7.3.1(と、別環境で手持ちにあった7.2.13) で動かしてみた結果でございます。

コードは、こんなん。

class Hoge
{
    public function h()
    {
        static $class = null;
        static $i = 0;
        $class = $class ?? get_called_class();
        $i ++;
        echo "{$class}:{$i}\n";
    }
}

class Foo extends Hoge
{
}

class Bar extends Hoge
{
}


$h_obj = new Hoge();
$h_obj2 = new Hoge();
$f_obj = new Foo();
$b_obj = new Bar();

$h_obj->h();
$h_obj2->h();
$f_obj->h();
$b_obj->h();

$h_obj3 = clone $h_obj2;
$h_obj2->h();
$h_obj3->h();

結果は、こんなん。

Hoge:1
Hoge:2
Foo:1
Bar:1
Hoge:3
Hoge:4

何となくだけど、staticの変数の中身、class単位で持ってそうな感じだなぁ。
だから、Hogeについては「別インスタンス」だろうが「cloneでのcopy」だろうが、同じ値を地続きで持ってる。
な～～んとなく、privateなメソッドを「同じclassの、別インスタンスからcallできる」あたりとの関連性を想起するんだけど、実際、ど～なんだろ？？？

ちょいと興味があったのと、思ったより興味深い結果になったので、メモり。

魔力干渉系魔法と魔法干渉系魔法

一般に「魔法干渉系」と呼ばれる魔法が、いくつか存在する。
例えば「魔法吸収」であったり「魔法発動阻害」であったり、或いは「魔法分解」や「解呪」といった類いのものや、このあたりの行き着くところが絶対魔法防御(アンチ・マジック・シェル)である。
しかし、これらは厳密には「魔法が効果を成す前の、魔力の流れに干渉をする」呪文であり、正しくは「魔力干渉系」と呼称されるべき呪文群、になる。
故に「魔法が効果を発した後の結果」に対する干渉は、原則として出来ない。

端的には「治療呪文を解呪」しても、治療効果がなくなりはしない。
これは、治療呪文自体は「(ほぼ)瞬時に効果を発揮する」ため、に、解呪対象となる「魔力」はすでに「結果を成した後なので霧散しているから」である。

一方で、いわゆる「呪いなどの解呪」や「永続呪文の解呪」については、正確には2種類の作用のどちらか(ないしその複合)となる。

一つは、多くの「呪いや永続呪文」は、ある程度ループするように「魔力を周囲から吸い取って効果を成す」回路が組み込まれており、その回路の動作自体にも(当然だが)魔力が使われる。
そのため「対象の呪に対する一切の魔力供給を、一瞬でも完全に破壊する」事で「回路の維持が不可能」となり呪文が壊れる。その「魔力供給の遮断」を行うのが、一般的な「解呪」の一つの手法である。
これに対抗するために、特に「呪い」の場合は「魔力を蓄える」「偽装する」など、様々な方法で「魔力供給の瞬断」に対抗するような術式が組まれている、事が多い。

もう一つが、端的には「熱を発し続ける」術式に対して「冷却し続ける」術式を重ねて「効果を対消滅させる」事で、実質的に「解呪」と同じ効果を生み出す、という方法がある。
この場合は「対象術式の解析」の精度が重要なファクターになるため、どちらかというと「魔力制御と魔力分析に長けた」タイプの術者が、この方法を得意とする。
対抗手段は「術式の解析を阻害する」等があり、これも一部の術式では、そういったものが組み込まれている。

魔法吸収系などについては簡単で。効果が成ったにしても「成りきれない魔力」というのは大概、魔法事象の周辺に漂っているもの、なので。
吸収系は、基本的にそれらの「成りきれなかった魔力」を吸収しているだけ、である。

魔法発動障害は、単純に「集約している魔力を散らしている」事が多い。
亜種として「集約している魔力に(使う術式にとって)使いにくい色(ベクトル)を付けて」魔法発動を阻害している、ようなケースもある。

これらの究極である「アンチ・マジック・シェル」は、周辺の魔力に干渉をして「魔力が効果を成す前に全ての魔力をジャミングする」術式である。
よく「効果範囲外からのマジックミサイルなども打ち消せる」などの事象から「魔力干渉系」とは見なされないようだが、あの術式は、実際には「範囲：ほぼ無限」であり、術者を標的にしてきている魔法について「魔力干渉をしている」だけに過ぎない。
アンチ・マジック・シェルの「範囲：ほぼ無限」については、その性質から「因果律作用系」が一部混ざっていると思われるが、そのあたりの考察はまた後日。

しかし、あまり知られていないが、真に「魔法干渉系」と呼ばれる術式が、存在しないわけではない。
一般的な魔術師程度では噂すら聞いたことがないであろうが、超が付くほど一流の術者であれば、噂くらいは聞いたことがあるかもしれない。

「真の」魔法干渉系は、「すでに成った」魔法に干渉をする事が出来る。
理屈は単純で、端的には「魔法そのものに時間干渉し、その魔法が成る前の魔力に戻した上で魔力干渉をする」というのが、その根本原理である。
故に、「すでに成った魔法」についても、普通に干渉をしてくる。

この術式が怖いのが、「一般的には知られていない」為に「この術式に対する防壁が組み込まれた術式」はあまり存在せず、そのため「大半の術式が、抵抗の余地もなく解呪される」事にある。
かつ、もし干渉時間を長くすると「治療呪文をキャンセルする」といった、今までの常識を根底から覆すような術式すらも、組む事ができる。

「超」が2つ以上程度つく術者どうしの術式の場合は、最低限これらに「ある程度」抵抗するような呪文回路が組み込まれている事が多く、それがない術式は基本的に「無防備すぎて、一切の効果を及ぼさない」と考えてよい。
ちなみに、いくつかの上位種が持つ「低レベルの呪文に対する完全防御」は、この「真・魔法干渉系」の亜種である、と考えられている(「低レベル呪文」だけ、なのは、「時間に干渉できる」魔力量に(かなり低いところで)上限があるため、である)。

「真の魔法干渉系」術式の会得は、普通に「才能がある」程度では、星のごとき高さの難易度ではあるが。
それでも「知っている」か「知らないか」は、それなりに重要な「違い」になると思い、ここに記す。

「空っぽのPHPバッチ」の処理コスト

ちょいと故があって、LaravelとplainなPHPとでの、バッチの処理コストを確認してみたんだけど………思ったより差異があって、幾分、びっくり(苦笑
なので、参考とmemo程度に、記録を残しておきます。

環境その他によると思うので、参考値程度に。
PHPのバージョンは、ちょいと古くて7.1系で試してます。

端的には

echo memory_get_peak_usage(true), "\n";

の処理だけ、のバッチを

<?php

$t = microtime(true);

for($i = 0; $i < 10; ++$i) {
    $s = `php artisan Test`;
    //$s = `php batch.php`;
}

$te = microtime(true);
var_dump($te - $t);
var_dump($s);

ってな感じで回していきます。

なので
・処理時間は「10回処理した時」の時間
・食ってるメモリは「1回のバッチで食う」メモリ
ってな感じ。

勿論、処理時間はコロコロぶれるのですが。
大まか
・Laraveで、処理時間1.48秒、メモリは14680064バイト
・palinで、処理時間0.34秒、メモリは2097152バイト
ってな感じ。

処理速度が4倍、メモリが7倍。
ふむ……普通の処理なら「そんなに気にするほどのものでもない」し、実際にもうちょっと「中身のあるバッチ」を組むと差異は恐らく縮んでいく可能性が想起されるし、plainなPHPで組むとそれはそれで色々と懸念とか課題とか山積みではあるんだけど、とはいえ「状況によっては無視しにくい」ような気もするなぁ。

「出来る」って、なに？

元ネタは
https://gallu.hatenadiary.jp/entry/2018/12/30/102130

ん………そもそもとして、まず「出来るか？」って質問に三軸あって。

のあたり。

この辺、割と大事だし重要なんで、ちょいと噛み砕いていきたいかなぁ、と。

「出来る」って単語は割と「便利な言葉 https://gallu.hatenadiary.jp/entry/20090714/p2 」なので。
ちゃんと噛み砕いていかないと、割と大きく齟齬が起きる上に、齟齬った時にあんまり幸せにならないので、ちょいと言及してみたい、かと思います。

先にまとめると
・技術的に可能か
・コスト(費用 / 工数)的に可能か
・期限的に可能か
の３軸があろうか、と思うのですが*1。
その辺を、もう少しかみ砕いて。

技術者が考えがちなのが「技術的に可能か？」という軸。
ここはさらに細分化されて
　→ そもそも「可能」か？
　→ 「現実的」か？(重さとかメモリとか前提条件とか諸々)
ってのがあります。

まず「そもそも可能か」どうか。
「技術力が低いと可能なものでも不可能と断じる」方向のほかに「技術力が低いと本当は不可能なのに可能だと思ってしまう」ってのもあるので、色々と勉強やら学習やら修練やら仲間やら、必須科目は増えていく一方でございます。

もう一つ「技術的に不可能ではないんだけどものっそいCPU使ってメモリ食って処理時間が１年かかる」とかいういものを「できる」と言い切ると色々と齟齬があるので。
「現実的な範囲で可能かどうか」、或いは「どれくらいのスペックを前提にどれくらいの入力量であればどれくらいの処理時間で動くもんなのか」あたりは、ちゃんと明示しておいたほうが無難です。
入力データ量については。1kBのデータが処理できれば理論的には1EB*2の処理だって可能ではあるんでしょうが*3、あんまり現実的な数値にはなりませんよね？
分からなければ「不明なんで一回、簡単なプロトタイプ作って実験してみませんか」って持ちかけるのも一つの手段です。
相手によっては「プロトタイプで作ったコードは渡さないように気をつける」とか色々あるのですが、まぁ。

とまぁ、「技術」切り口でも、これくらいはあるのですが。

特に「営業さん」とか「顧客さん」とか「上司さん」とか「マネージャさん」とか「上流会社さん」とかが「できるかできないか」って質問の時は、どちらかというと「技術以外」のお話ががっつりと絡んでくるんですよねぇ。

割とありがちなのが
営業「出来ますか？」
技術「(技術的には)可能ですよ(お金、たっぷり追加がかかりますが)」
営業「(追加金額無しで)可能なんですね」
的な会話。
あんまり「幸せになれる」絵図は見えてこない感じですよねぇ正直。

出来る、って単語には「コスト(費用 / 工数)的に可能か？」って切り口が、これは必ず存在していて。
単純に「できる？」って聞かれた時は、コストの話が「入ってるのか入ってないのか」くらいは、確実に確認をしておいたほうがよいです。
んで。コストの話も「作成にかかる金額」だけではなく、場合によっては*4「納品にかかる工数」「運用とか保守とか引き継ぎとかまで見込んだ工数」まで見込んでおかないと、色々と面倒が厄介です。

あと、もう一つ。
・技術的に可能だし本人にそのスキルや知識もあるし
・お金も出る
んだけど
・作業者当人のタスクがパッツンパッツンで、今は手がでない
ケース、なんていうのもあるので注意。端的には「締め切り」ですね。
どっかでチームでやっていて上にPMさんがいれば大丈夫………だと思いたいのですが、例外的に「適切なマネジメントが十分に行われていたか？ という観点に幾分の疑問があり*5、あんまり*6大丈夫ではなかった」事例が、ごくわずかに、誤差程度ですが、全く皆無とも言えない状況で*7。
そんな時には、自衛手段として「自分のタスク量は自分で管理する」事が必要なケースも、無いわけではないのです。

いやまぁ「納品が10年先でよい」んならまた色々と考えてみてもよいんでしょうが*8。
速度が割と大きく重視されるIT業界において、そこまで締め切りが延ばせるか？ ってのは、なかなかに微妙なので*9。

その辺を考えると
・締め切り日
・「そのタスクをアサインする人」の現在のタスク状況
ってのも、割と重要なんですよ。

その辺をすっ飛ばすと
営業「出来ますか？」
技術「(技術的には)出来ますよ(大体一ヶ月くらいかなぁ……」
　一週間後
営業「出来てますか？」
とかいう、やっぱりお互い幸せにはなれなさそうな会話が、ですね、えぇ。

ちなみに、こーゆーケースがあるのでおいちゃんがよく使うのは
「技術的には可能です。あとは工数(＝追加金額)と納期(と、忙しかったら他のタスクとの兼ね合い)とのご相談ですかねぇ」
ってな感じのお話。それ以降は、営業さんがいればそっちにふったり、自分が営業も兼ねてるんならご予算と納期のお話に移ったり。

「技術的には可能です」だけだと「じゃぁナニが足りないんだろ？」ってのが伝わらなかったりするので、「お金と期間」って言う話をちゃんと明示するのがポイント、ですかねぇ。

なお、時々「技術的には可能なんですよね？」で妙に言質を取ろうとする営業さんが、少なくとも昔は「いた」ので。
「技術的には可能ですがお金と納期は別問題なんで言及していませんので具体的に実装をするのであればまずお金と納期の話を片付けましょう」までを、息継ぎ無しで*10一気にぶち込みましょう。

この辺。
「火傷をしてから覚える」でもよいんですが、火傷が時々、深達性II度熱傷とかIII度熱傷とかまで行くと色々とシャレにならないので。

*1:これ以外であったら突っ込んでください速攻で記事修正しますｗ

*2:エクサバイト………流石にまだ見た事がないですなぁこの単位ｗ

*3:本当に可能か？？ 処理内容にもよるだろうけど

*4:つまり、割と多くのケースにおいて

*5:つまり「出来ていない」

*6:物凄く

*7:つまり「しょっちゅう」

*8:内容次第だよねぇ、ってのはおいといて

*9:なお、おいちゃんは一度だけ「締め切り日が過去に設定された」事がありましてね………

*10:いや息継ぎしていいんだけどさ

依頼の仕方？？

ちょいと気になるツイッターが入ってきたので、軽く言及。

https://twitter.com/1tatyo/status/1078122287000211457

職人気質の人には「これってできますか？」でなく「これって無理ですよね？」と聞くようにしている。 個人的な経験だと、前者の聞き方だと彼らは「出来ない理由」を探す思考に向かっていくことが多い。 しかし、後者の聞き方だと「出来る理由」を探す思考に向いていく。 面白いくらいに違う。笑

https://twitter.com/1tatyo/status/1078283184645623811

「人が動く理由」って様々あるけど、人のプライドや承認欲求をくすぐることで動かす考え方は本当に大事にしてます。 これを言うと、相手はどういう風に思考が転じ、結果どうなるか？ 事業会社のマーケターは、支援会社の働きを最大化させることで結果的に自分の利につながるので、このスキル必須説！

https://twitter.com/1tatyo/status/1078437318468354049

応用技。 職人気質な人に「これって無理ですよね」と聞いて「無理です。」と言われたら。 近くの別の人に「これって無理ですよね」を聞くという手法がある。笑 その人が「できますね」と言うと「無理です」と言った本人が無能ということになる。 プライドと競争心を存分に利用し職人を活用せよ！

肯定否定が入り交じっているっぽいのですが、まぁその辺も込み込みで。

まず、先に。

「人が動く理由」って様々あるけど、人のプライドや承認欲求をくすぐることで動かす考え方は本当に大事にしてます。

これはまぁ「これが全て」ではないにしても、ある程度大事です。

これを言うと、相手はどういう風に思考が転じ、結果どうなるか？ 事業会社のマーケターは、支援会社の働きを最大化させることで結果的に自分の利につながるので、このスキル必須説！

これは、個人的には幾分微妙。
「支援会社の働きを最大化させることで結果的に自分の利につながるので」だと、ちょっと相手のことを考えず、局所最適のようにも見えるんですよね。
ちゃんと、お互い「Win-Win」になっていればよいのですが。より理想的には「三方良し」。

なんていうジャブを打ちながら、本題。

職人気質の人には「これってできますか？」でなく「これって無理ですよね？」と聞くようにしている。 個人的な経験だと、前者の聞き方だと彼らは「出来ない理由」を探す思考に向かっていくことが多い。 しかし、後者の聞き方だと「出来る理由」を探す思考に向いていく。 面白いくらいに違う。笑

ん………そもそもとして、まず「出来るか？」って質問に三軸あって。
技術者は大体「実現可能か？」っていう点だけを考えがちなのに対して、非技術者のこの手の台詞って「納期と工数」が含まれるので、その辺で色々と齟齬があり以下略、って話にもなりがちなんですよねぇ、的なのがあって、(社会戦的に)練度が高いエンジニアは一端「警戒」から入りやすい、ってのもまぁ「生活の知恵」レベルなんだよなぁ、的な。
この辺の詳細はまた後日。

とりあえず「上述が比較的、是」な方向で考えると。

「これってできますか？」って質問は、「技術的＋工数＋納期」ってのが脳裏に浮かぶのと「ニーズを100%満たす前提」ってニュアンスになる可能性が高いように思われて。ってのが「できる」前提で質問をされているので。
一方で「これって無理ですよね？」って質問は、「無理である前提」で質問がされている、と仮定をすると「技術ベース」で「ニーズを80%程度満たす、でも提案が可能」な雰囲気が漂う、って思う事が可能、な可能性もあるので。
もしそうだとすると、「無理ですよね？」って質問のほうが、幾分、理があるようには思われます。
まぁ、個人的には「無理です"よ"ね？」よりは「無理です"か"ね？(難しいですかね？)」ってほうが、ニュアンスとして好印象になりますが。

もちろん、上述を「非」としてとらえる見解は山盛りで可能で。
・そもそも「できるか無理かを素人が判断すんな」(無理です"か"？ ではなく、無理です"よね"？ だと、そういうニュアンスになる)
・本当に「無理」なら、なぜ質問をしてくる？(同上)
・依頼がおおざっぱすぎて是も非も答えられないのにいきなり是非を問われても困惑する
・「無理だ、って思われてる程度に信用されてないんだろうなぁ」って思うから断る
等々。

あと、上述のつぶやきについては、「面白いくらいに違う。笑」の部分に色々と気になったり引っかかったりするところが多少*1なりあるのですが。
とはいえ、まぁ、一応、是非交々。

ちなみに個人的には、上述のような聞かれ方は「よっぽど信頼が構築できている関係性」以外なら「無理だと思うんなら無理なんだろうと思いますので無理だと思います」ってそっけなく対応して終了、かなぁ。「できるかできないか判断できる頭があるんなら自分で判断しろ、判断できないんなら判断すんな」って思うので*2。
「信頼関係が構築できている」場合、最低限「無理です"か"ね？」くらいの物言いが出来る人しかいないので。とりあえず「ニトロブースとしてでもやった方がいいか」等、依頼の背景を聞いてからの回答、かなぁ。

一方で

応用技。 職人気質な人に「これって無理ですよね」と聞いて「無理です。」と言われたら。 近くの別の人に「これって無理ですよね」を聞くという手法がある。笑 その人が「できますね」と言うと「無理です」と言った本人が無能ということになる。 プライドと競争心を存分に利用し職人を活用せよ！

については、基本「いただけない」なぁ、と。

まず「無理だといったAさん」が無理な理由としては
・技術的に不可能(だとAさんが思う)
・仕様が曖昧すぎる
・Aさんのタスクの詰まり的に無理
・納期的に無理
・作成コストや運用その他の見地から、やめておいたほうがよい
等々、が想起できるのですが。

で、上述を踏まえて「近くのBさんが」できる、って答えた場合。
以下の色々な可能性が想起できるです。

・Aさんは技術的に不可能だと思ったが、Bさんは技術的に可能だと思った
これ、多分、一番、根が深い。
単純に「AさんよりBさんのスキルが高い」可能性、もあるのですが。
まぁまぁの確率で「AさんよりBさんのスキル(と知識レベル)が低い」可能性、が、少なくとも技術の世界だと、存在するんですねぇ。

過去に会ったわかりやすい事例を一つ。
ニーズ「e-mail(SMTP)を、100%到達させるようなシステムを組んでほしい」
Aさん「不可能」
Bさん「可能です」

これで「Bさんに頼む」って思った人は、存分に地獄を味わってください、としか。
発注者としての基本スキルに欠けがあるので*3。

・仕様が曖昧すぎる
についても。「Bさんにとっては十分であるように見えるんだけど、Aさんの鋭い目線で見るとあちこちで曖昧さや矛盾があった」なんてケースは、少なからず。
まぁその場合、Bさんが悲鳴を上げるか、発注者が後日悲鳴をあげるか、大体がどちらか、なので。「こちらにしりぬぐいの依頼が来なければ」冷やかに放置いたしますが。

・作成コストや運用その他の見地から、やめておいたほうがよい
についても大体同様。「Bさんはそこまで考えていなかった」とか、まぁ色々。
この辺も、あとで悲鳴が上がってくるケースとか、ありますな。

・Aさんのタスクの詰まり的に無理
・納期的に無理
の２つは割と関係性があるので、まとめて。
いや単純に「AさんよりBさんのほうが手が早い」可能性もあるのですが、一方で「Bさんのコードは保守メンテナンス性に激しく欠落がある」ような場合、ちょっと色々と思案したりしますよねぇ、的な。とりあえず「しりぬぐい、こっちにもってくるなよ」と、しか。
「Aさんのタスクがぱつんぱつんだから無理(余裕があれば可能)」な場合、そもそも「依頼者が適切にタスク管理できていない or 適切なルートで依頼をしていない」ので、有能無能以前っていうか依頼者が無能なだけ。「「0.2+0.2+0.2+0.2+0.2」は1.0であって0.2ではないんだよ？ https://gallu.hatenadiary.jp/entry/2018/09/18/170115 」あたりを、熟読してくださいませ。

……とまぁ、色々。
これらを踏まえた上で

その人が「できますね」と言うと「無理です」と言った本人が無能ということになる。

とか、エンジニアにすべての責任をおっかぶされても「……………で？」って感想しか出てこないかなぁ正直。
多分、発注者に対する信用が地面に食い込むだけ、なので。以降のお仕事でかかわりがなくなるんであればどうぞ、的な。
関わる場合は「会員ランクが上がる https://gallu.hatenadiary.jp/entry/2018/10/11/234610 」ので、相応の対応をご期待いただければ、と思います、的な。

というかじゃぁ「Aさんが無能」だと判断した、と仮定して、その先どうするんですかねぇ？
まぁ実際「無能だと思ってしまったAさん群を値切ってその結果Aさん群が辞めていってしまって生体濃縮が始まってびみょ～なのがそろってしまった会社さん」とかあったりして以下検閲削除*4

閑話休題

なので。

プライドと競争心を存分に利用し職人を活用せよ！

とか言われても「プライドと競争心」以前の問題ですし。
人によっては「職人を活用」ってあたりにも、色々ともにょる感想を持つ人が多いんじゃないかなぁ、と。

でまぁ。書かれた方のプロフィール。

個人のブランド化を支援する。本格的な撮影セットを用いたシックなビジュアル作り「plan J」はじめました。本業はto Bメーカーのマーケッターです。 ▼【Bio】中大法学部卒。ITベンチャーや博報堂を経て、to Bメーカーのマーケティング職。 #田端大学

こんな感じ。

「実際がどうか」は不明なのですが。
上述から「技術者を軽視して見下している(利用できるコマだと思ってる)」って感じる人は、一定数、いるのではないかなぁ、と思われるのです。
もちろん「自分の印象をそういう方向にもっていく」マーケティングをしている、のであれば、特段として留め立てする義理も理由もないのですが。

技術者諸氏としては「こーゆー文章に納得した人たちの手ごまとして摩耗される事がないといいですねぇ」という感想を持ってしまうかなぁ、など、と。

*1:多大

*2:これが営業１～３年生あたりが、おずおずと聞いてきたら、接客で鍛えた柔らかく丁寧なやりとりで、にこやかに優しく対応しますがねｗ

*3:「受注者のスキルの高低を判断する」のは、本来的に、発注者のお仕事ですよ？

*4:「営業さんにとって使いやすい」と「技術レベルが高い」って、相関性がないもんですからねぇ……そこで「営業さんにとって使いやすい」技術者を集めると、まぁ、スゴい事にもなろうってもんです B-p

一人暮らし用 簡単な「予算制限法」

大分前に書いた駄文が「ふらっ」と出てきたので、もったいないんで公開します(笑

• • • • • • • • • • • • • • -

とりあえず「一ヵ月毎に(多少揺らぐにしても)定期的な収入がある」前提とします。
給料日にやるべきことは、以下。

まず「固定費」を給料から抜く

家賃、光熱費(予想)、通信費(携帯とかあるでしょ？)、交通費、その他「毎月定期的にかかるお金」を、給料から抜き取ります。これはすでに「支払われたもの」なので、存在しないお金です。
もし「がんばって貯金をする」場合、貯金額も「このタイミングで」抜き取ります。
電気代が結構注意。エアコン使うと結構跳ね上がります。夏はともかく、冬は「厚着で乗り切る」とベター。
初めての月は、結構多めな事前提で「実家の光熱費」をそのまま抜いておきましょう。余る事はあっても足りなくなる事は少ないと思われます。

自炊するんなら米代

自炊は後で書きますが。自炊するんなら、このタイミングで「米代」抜いておくとよいです。
大体、5kgで33合ちょい。大体、１合で普通の飯茶碗２杯分、なので。5kgで「66杯の飯」って考えると近似値。この１杯はどんぶりぢゃねぇぞいいなｗ
どんぶりだと、大体１杯で１合くらいなので。普段「どんぶり換算」なら、5kgで33杯。
「一人暮らし初期」なので若いことを想定して「３食くって、１食あたりどんぶり１杯」とすると、一ヶ月に15kgくらいの米があると安心。
5kgで1500円くらいだとわりと安いので(がんばると1200円くらいのもあったりする)、がんばって見つけて15kgで4500円。

残りを日割り

30ないし31で割って、１日あたり「使っていい金額」を算出。
しかる後に…できたら「１日分づつ封筒に入れて」、毎日１つづつ封筒をあけて財布に金を入れる。
これをやると「絶対にオーバーできない」ので、とりあえず「給料日前日に干からびてる」状況だけは回避できます。

ちなみに「突発的な出費」と「意識してなかった固定費」の問題があるので、特に「初手の３ヶ月」は、余裕をもっておくか(具体的には、固定費から２～３万くらいさらに抜いておく)、親その他に泣きつく準備をしておくとよいです。

雑貨まわり

家電とかは「親と周囲になきつこう」以上終了(笑
冷蔵庫はあったほうがいいんだけどサイズ次第。自炊はがっつりやるんなら炊飯器必須。なくてもいけるけど。
電子レンジは微妙にぜいたく品なので、なきゃないで。
「自費での購入」が必要な場合、中古狙いもあり。ただ冷蔵庫は古いと「電力を容赦なく食う」ので、ここは気合でなきついておきたいところ。

洗剤とか、初期に必要なものは結構多い。
「安くていい」ものは、100円ショップその他、安いところを足で探してゲトりましょう。
いやでなければ、「重曹と酢」か「クエン酸」で大体の「掃除と体洗い」は片付くので、そういう知恵をあさるのもあり。

食事

自炊は「しっかりやる」か「すっぱりあきらめる」かの２択。
中途半端にやると金が駄々漏れにかかるので、やるなら覚悟をきめて、やらないんならすっぱりとあきらめて。

やる場合はとりあえず「主食の確保」。
米、パスタ、小麦粉あたりが選択肢としては優秀な可能性が高いかなぁ。グラム単価ベースだと小麦粉が最安値になりやすいんだけど、小麦粉で一ヶ月とか一年とかやっていけるか？ ってあたりが問題点。
おかずは、コストパフォーマンスも大事なんだけど「腐らせない事」も大事なので、食える量を、食える範囲で。
調味料は、一端は100円ショップで。「明らかに確実に使うもの」は、普通の量をスーパーで買ったほうがコストパフォーマンスがよいので、その辺は適宜。

やらない場合、インスタントラーメンの類はわりと生死を分けるので(笑)、ポットないし鍋の類は１つ所持しておきましょう。
18cm直径くらいの鍋、が、とりあえずサイズ的によい塩梅です。運がいいと100円ショップに、14cmくらいの小さいのですが、あったりするので、それもよし。
実家あたりから「使ってないの一個頂戴」とかガメてもよし。
インスタントラーメン自体は、スーパーとか量販店とかで「安売り」の時期を狙って買い込むとお買い得。

どっちにしても「炭水化物メイン」の食事になりやすいんだけど、まぁ廉価にいくなら仕方が無い。
タンパク質は、親とか大人とか先輩とかにたかろう(笑
＆
この食生活、30代後半以降まで続けると一気に身体にクく可能性が高いので、あくまでも「二十代の頃だから出来る」荒技、だと思っていただければ。