gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

「空っぽの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 」なので。
ちゃんと噛み砕いていかないと、割と大きく齟齬が起きる上に、齟齬った時にあんまり幸せにならないので、ちょいと言及してみたい、かと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*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さんのタスクの詰まり的に無理
・納期的に無理
の2つは割と関係性があるので、まとめて。
いや単純に「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:これが営業1~3年生あたりが、おずおずと聞いてきたら、接客で鍛えた柔らかく丁寧なやりとりで、にこやかに優しく対応しますがねw

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

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

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

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

                            • -

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

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

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

自炊するんなら米代

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

残りを日割り

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

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

雑貨まわり

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

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

食事

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

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

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

どっちにしても「炭水化物メイン」の食事になりやすいんだけど、まぁ廉価にいくなら仕方が無い。
タンパク質は、親とか大人とか先輩とかにたかろう(笑

この食生活、30代後半以降まで続けると一気に身体にクく可能性が高いので、あくまでも「二十代の頃だから出来る」荒技、だと思っていただければ。

「アルルの女」あるいは職人の片思い

元ネタは、こちら。

この本のP157から始まるお話に出てくる「アルルの女」というたとえが、なんというか、心に「グっ」ときたので。
細かい話は本を買って読んでみてください……どうも物理が流通してるか怪しいんで、電子書籍のほうがよいかも、ですが。

………で終わると「なんのことやら」ってなるので、少しだけかいつまんで。

服屋のセルジュ坊ちゃんが、二人の職人に仕立ててもらった2枚のシャツの優劣を「業界の重鎮」に見てもらった時に。
重鎮は、職人の片方である織部のシャツのほうを「アルルの女」と例えました。

2枚のシャツの差異(の一つ)は、ボタンホールを手縫いで仕上げているかミシンで仕上げているか、の差。
織部は、ボタンホールまで手縫いにこだわってつくってました。

セルジュの「手縫いのほうが職人として優れているってこと?」という問いに、重鎮はこう、答えます。

「いや 一概にそうとも言えない。
 ボタンホールは手縫いなら多少丁寧で頑丈に仕上がる事以外は機能的に大した違いはない
 手間の割に賃金も知れたものだから数をこなしてようやく酒代程度になるくらいだ
 むしろミシン縫いの方が時間もコストも抑えられるので客に喜ばれる場合もある」

では、なぜ織部は「それでも手縫いにしたんだろう?」というセルジュの問いに。
先ほど例えた「アルルの女」の話が展開されます。

「ドーデの"アルルの女"は
 一人の純朴な青年に死を選ばせ
 彼の母親や婚約者を悲しみのどん底に落としながら
 件の"アルルの女"はただの一度も作中に登場しない」

そうして、横に居る女性(エレナ)が、その先の言葉を紡ぎます。

「社長はボタンホールに職人の片思いを見たのですね」

社長は、その言葉をうけて、こう続けます。

「ボタンホールを念入りにやった所で 客に褒めて貰える訳ではない
 手を抜こうと思えば抜ける所を妥協しないのは客への心尽くしであり
 その姿勢を貫く事は職人のプライドでもあるのだ」

いやまぁ勿論「心尽くしの尽くしがいのあるお客様に限る」ような気はするのですが。
また、プログラミングの場合「"何を"妥協しない」事が正解なのか*1、ってのはあるのですが。

おいちゃん個人としては、そういう気持ちをずっと忘れずにいたいなぁ、と思うので。
ふとしたタイミングで、この話を書いてみたいなぁ、と思ったので、書いてみました。

*1:当然「考える」事である。間違っても「手を動かす」事じゃない

コスト計算って「色々な意味で」大切だよねぇ

元ネタは、 https://twitter.com/zacky1972/status/1067383578177155072 から始まる、一連のツイート。
全体で1文になっていると思われるので、「URIの群れ」を書いてから、文章を一気に。

https://twitter.com/zacky1972/status/1067383578177155072
https://twitter.com/zacky1972/status/1067384132068495360
https://twitter.com/zacky1972/status/1067384399627411456
https://twitter.com/zacky1972/status/1067384716553203712
https://twitter.com/zacky1972/status/1067385079175950336
https://twitter.com/zacky1972/status/1067385448706695168
https://twitter.com/zacky1972/status/1067385778492268545
https://twitter.com/zacky1972/status/1067386225818927104
https://twitter.com/zacky1972/status/1067386554811801600
https://twitter.com/zacky1972/status/1067387199480459264
https://twitter.com/zacky1972/status/1067387556969406464

しばしばTwitter界隈その他であふれている「経営者は◯◯をエンジニアに支給するのが当然である」みたいな主張。私に言わせれば「お花畑」と言うしかない。以下,なぜこの主張がお花畑なのかを説明する。
理由はシンプル。では貴方はもし◯◯が支給されたとしたら,その費用をはるかに上回る利益をもたらすことが出来るのですか? 具体的に提案してください,経営者に! ということ。
キチンと具体的な提案をしているにも関わらず,受け入れられないのだとしたら,その時初めて貴方の意見を聞きましょう。
貴方はそうではなく,ただ愚痴をTwitterに垂れ流しているだけではないですか? それで◯◯が支給されると思っているならお花畑ですよ!
経営者が◯◯を支給しないのは,その投資をするだけの価値がないと考えているからです。悔しかったら価値を提案しましょう。
もし価値ある提案をしているにもかかわらず,全く聞く耳を持ってくれないのであれば,転職もやむなしかもしれません。だがちょっと待て! その「価値ある提案」は独りよがりではないですか?
その「価値ある提案」は,会社の利益につながりますか? 顧客が喜ぶことですか? 経営者が抱える課題を解決することですか?
そういう提案をするには経営者が何を見て何を聞いて何を考えて何をしようとしているのかに思いをはせる必要があります。それが経営者視点です。
ビジネスの基本は,相手にとって価値があることを提案して実行することに対価が払われるということです。自分にとっての価値じゃないんです。
そのことに真剣に取り組んでいるのにも関わらず耳を傾けない職場であるならば,それは転職フラグです。そのときは今まで提案してきた価値の話を,面接等でアピールすると良いですよ。心ある企業ならばそんな貴方を受け入れてくれます。
そういうわけで「◯◯が支給されない」と嘆く暇があったら,それを上回る価値を提案して◯◯を勝ち取ってください!以上!

色々と、興味深いかなぁ、っと。

まず
・経営者にお金を出させたいんなら、ちゃんと「彼らに響く」プレゼンしようよ!!
って主張は、それ自体は特に違和感もなく、基本的には「そう思うなぁ」と思う所であります。金額にもよりますが。

その辺を前提にして。
「経営者は◯◯をエンジニアに支給するのが当然である」のあたりについては、まぁ結局の所「程度問題 / 金額次第」にはなるのですが、
ただまぁとはいえ、この一連のつぶやきが、なんとなし、例えば http://kumagi.hatenablog.com/entry/exit-from-ntt とかをきっかけであると考えると。
基本的には「"コスト"って、別に"その場で支払うお金"だけじゃないんだよ?」とか思ってみたりする可能性が高いかなぁ、とか思ってみたりするのです。

かみ砕いて。

では貴方はもし◯◯が支給されたとしたら,その費用をはるかに上回る利益をもたらすことが出来るのですか? 具体的に提案してください,経営者に! ということ。
キチンと具体的な提案をしているにも関わらず,受け入れられないのだとしたら,その時初めて貴方の意見を聞きましょう。

この辺なんですが。
この話って、一見すごく「妥当」に見えるんですが。
・提案するために、その下準備の為にかかる有形無形のコスト(技術者側にも、経営陣側にも)
・その「提案」の内容を理解出来る程度の経営陣の技術的背景:特に「質」に関する感覚
が抜けてるんだか欠けてるんだかオミットされてるんだか、ってな可能性が想起される上に。
それが支給されない事による
・モチベーションの低下とかに起因する、短期的なロス
・「その人材」が流出する等の、中長期的なロス
・評判やら風評やらといった類いの、間接的なロス
とかが、割と馬鹿にならない可能性が高いかなぁ、と、考える訳です。

なので。

経営者が◯◯を支給しないのは,その投資をするだけの価値がないと考えているからです。悔しかったら価値を提案しましょう。

という話なのですが、もしかしたら「提案した"価値"が理解出来ない程度に以下略な、上の方であったり会社の風習や空気や慣習や因習」である可能性も、あるわけです。
ちなみに、一度そういった「空気」が形成されると「なまなかなことでは覆せない」ってのは、以前に https://gallu.hatenadiary.jp/entry/20070123/p1 とか https://gallu.hatenadiary.jp/entry/20080319/p1 とかで、「場」という単語を使って書いております。
まぁ、それ以前に「なんでこの程度のものにまでわざわざ"提案"しなきゃなんないの?」といった金額感のもの、である可能性もあるわけで、その辺も気になる所です。

もし価値ある提案をしているにもかかわらず,全く聞く耳を持ってくれないのであれば,転職もやむなしかもしれません。だがちょっと待て! その「価値ある提案」は独りよがりではないですか?

この辺も、結構な危険フラグ。
「提案」が独りよがりである可能性は、勿論あるのですが。ただじゃぁ「ジャッジする経営陣側の視点」は、独りよがりだったり無能だったり的外れだったり、は、しないんですかねぇ?

その「価値ある提案」は,会社の利益につながりますか? 顧客が喜ぶことですか? 経営者が抱える課題を解決することですか?
そういう提案をするには経営者が何を見て何を聞いて何を考えて何をしようとしているのかに思いをはせる必要があります。それが経営者視点です。

「提案する価値が生み出す利益」が、「それは実際には十分な価値がある」のに、理解できないかもしれない。例えば「中長期に向けてのコスト削減」とか「クォリティアップによる利益の向上」とか、理解できない経営者も、ごく稀に、わずかながらに、存在します。
「顧客が喜ぶ」事のメリットが理解できない、なんてのは、正直「よくある話」。言い方を変えると「目線が、顧客ではなく社内政治に向けられているので、結果として"顧客が喜ぶ"事にメリットを見いだせない」なんてケースが、皆無、とは言えないと思う事も無いわけではなくて。
「経営者が抱える課題」以前に、「それが支給されないことによる困り事」は、経営者が「認識も出来ない」状態、かもしれない。「現場の困り事を真剣に解決する」なんて事は、「それが十分な経営上のメリットがある」にしても*1、そこを真剣に着手できる経営者が、どれくらいいるんだろう?? と。

だとすると、当然ながら「響くわけがない」。
ただ、響かない理由が「提案の失敗"ではない"」んだとしたら、苦労して提案した現場側は、どう感じるんでしょうかね?

ビジネスの基本は,相手にとって価値があることを提案して実行することに対価が払われるということです。自分にとっての価値じゃないんです。

これはYes。です。
つまり「ビジネスの基本は,相手にとって価値があることを提案して実行することに対価が払われるということです。経営陣にとっての価値じゃない」とも言えるんです。
「相手」って単語、なんか一方通行になってないかなぁ??

そのことに真剣に取り組んでいるのにも関わらず耳を傾けない職場であるならば,それは転職フラグです。そのときは今まで提案してきた価値の話を,面接等でアピールすると良いですよ。心ある企業ならばそんな貴方を受け入れてくれます。

うん。だから、「気づけた」人は、転職してるんじゃないかなぁ? と。

もう少し、コストの多寡のあたりを突っ込んで。

例えば「◯◯」が
・もっそ高価で、ちょっとどう考えても簡単に捻出できるようなものではない
ケースの場合。例えば「スパコンが欲しいなぁ」とか「AWSインスタンスを万単位で24時間フル稼働で使ってほにゃららをぶんまわす実験したいなぁ」とか。
そういったようなケースであれば、それはまぁ勿論「提案」も必要でしょうしっつか会社の場合、その先にある「稟議」とか「予算確保」とか、色々と必要だと思われます。
そのクラスの要求を「お願いしたけど駄目だった!!」って言っても「そりゃまぁ、そんな金、出ねぇべさ」って突っ込まれて終わるような気がする(苦笑
まぁだから「稟議通せれば出せる会社さん」に、一定の「いいなぁ、行きたいなぁ」感が出たりするんでしょうが。

一方で
・数千円~いっても1万ちょいで可能なもの
の場合。まぁよしんばエンジニア全員が「それを欲しがる」と仮定して。イメージとしては「メモリの増設」とかそれくらい。
そこを許可するのに「生み出す価値を提案しろ」とか言われると、多分、エンジニアは「サイレントクレーマー」になって。
何一つ文句も言わず、不満を表現せず、ただ「その場から立ち去るのみ」で、気がつけば「(有能なのが)一通りいなくなっている」とかって状況になりかねない訳です。
で、エンジニアが居なくなれば当然
・出来る事が限られてくるからビジネスチャンスが減る
・有能なのがいなくなるからより一層ビジネスチャンスが減る
・求人にコストがかかる
・新しく入った人への教育などにコストがかかる
・下手にネットで「あの会社、まともなメモリ増設すらやってくれない」とか風評が立つと、より一層のコストがかかる(か、エンジニアが寄りつかなくなる)
等など、人事系にとって「頭痛が痛い」状況は、なんぼでも思いつくわけなんですね。

幾分両極なお話をしましたが、つまりは「金額による」お話、でしかないので。
あとは「その会社の懐具合」とかがどうなってるか次第、という、身も蓋もないお話でございます。

いやまぁ確かに「ナニもせずにただ自分の欲だけのために際限なく何かをねだる」タイプのエンジニア()も、見ているので。
もしそーゆーのを見て言っているんだとすると、気持ちがわからんでもないのですが。

ただ、つぶやきを拝見している限りだと。「◯◯」のコストの多寡によらず論調を展開しているように見えるので。もしそうだとすると
・経営者の色々を、割と過剰に高く見積もっている可能性
・「提案」にかかるコストを度外視している可能性
・それらの支給に「価値ある提案」をMustにしている事に対する問題、をオミットしている可能性
・そもそもとしての「◯◯」に必要な金額の多寡が頭にない可能性、または「思い込みで一定以上の金額のみ」を暗黙の了解にしている可能性(で、その「暗黙」が、全員の共通認識とは限りません)
など、色々な事が想起されてしまうんですね。

いやまぁ少しだけ暴言を吐くと。
「エンジニアのガチな会話について行けるくらいの実力と知識を、経営陣が持ってから、言おうよ」とか、思ってみたりもするわけで。

勿論「お金」ってのは「わかりやすい価値」なのですが。
「それ以外の、価値」ってのを、もう少ししっかりとみないと、色々とアウトになりやすいんじゃないかなぁ、と、思ってみたり。

その辺の「中長期の視点視野戦略、有形無形のコスト含め、諸々を併せ持って考えられる」のが、本当の「経営者視点」なんじゃないんですかねぇ?

*1:いや実際、大抵は"ある"んだけど

なぜ「質問」をしないんだろう? 或いは「コード絶対領域」に対する考察

比較的「古い」御仁やら現場やら、に多いように思われるタイプなのですが。
現象としては
・似たような関数やメソッド、下手したら定数までも、をあちこちにcopyして書き散らかす
というのがありまして。
端的に「物凄く、反DRYな感じ」で、おいちゃんとしては「お好まない最たるモノ」の一つ、でございます。

そういったコードをつぶさに観察していくと見てとれるのが
・とにかく、自分の手の届く所に、コピペを含めて全部持ってくる
という行為であることが多くて。
言い方を変えると「他の人とライブラリを共有する」って事を、一切、やらないんですね。

その辺を「コード絶対領域*1」とか呼称してみようか、と思います。
絶対領域、という単語については、「スカートとニーソックスの間の領域」のほうではなくて、「何人にも侵されざる聖なる領域(心の壁)」のほう、を意図しております。

自分の書いたコードは「自分のコード絶対領域」な一方で、他人の書いたコードは「他人のコード絶対領域」なので。
「他人のコード絶対領域のライブラリは使わない」。面倒なんでコピペとかはするんだけど、「自分のコード絶対領域」に持ち込んでからじゃないと、使わないし使えない。
大体、そんな感じでコードをくみ上げて行きます。

そうするとどうなるかってぇと
・同じ機能を持つ、似たような関数があちこちに散らかる
ので、そりゃもぉ大騒ぎ。メンテとか、夢のまた夢でございます。

いやまぁ、そういう風になってしまう背景が、見てとれなくもないんですが。
具体的には、以下のあたりがAND条件で一通りそろったりすると、やむを得ないケースが、無くもないです。

まず「複数社が混在している」か、或いは少なくとも「複数のエンジニアが混在している」環境で。
かつ、その複数に対して「質問が出来る空気でもなく」「質問を投げても返ってこない(か、下手したら怒られる)」環境で。
かつ、全体仕切りがまともに動いていないために「俯瞰した視点を持っている人」がいなくて。
かつ、そのプロジェクトに対する「権限」は全く所持していなくて。
かつ、「責任だけは十全に背負わされる」ので、「防御的開発」をせざるを得なくて。

この辺が揃うと。
他の人が作ったライブラリに下手に依存するコードを書いて「そのライブラリがいつの間にか仕様変更があった」時に、「仕様変更を言ってこなかった相手」ではなく「勝手に使ったこっちが悪い」になってしまうので。
そーゆー環境下で「その現場に限って"コード絶対領域"を発動する」事については、一定の配慮とか理解とか、が、必要だと思うのです。

っつか「責任も権限もないのにカイゼンをしろ」とか、どんだけブラックなんだよ、的な。

ただ。
「そーゆー環境に長いこと居る」とか「"そーゆー環境に長いこと居る"人から教わった」とかで、「コード絶対領域を"普通の事だ"」とか認識されてしまうと、色々と困ったり困ったり殺意が沸いたりするんですねぇ。
っつかそれ、基本的に「防御的開発」に属する技法なので、端的に「プロジェクトがまともに終わらないことを前提にした技法」だよ?。

一方で「そんだけ、闇の深い現場があちこちにあるんだろうなぁ」とか思いつつ。
「闇落ちした開発者」って、その闇をあちこちに散らかしたりしてくるので、それはそれで、浄化したり聖別したり昇華させたり、なんらかの「ナニカ」が必要なんだろうなぁ、とか思ってみたりするですよ。

とりあえずおいちゃんが推奨するのは「まず、質問をちゃんとしようよ」とか言っていたりするのですが。
まぁそもそも「学問とは問い方を学ぶことである」とか、一時期は「質問力」なんて言葉が出てるくらい、「的確に質問をする」ってのは、それなりに難しいもんだと思うんですが。
その辺はやっぱり「鍛えないと」どうにもならないので、まずは「沢山質問をしてみる」からstartして、問い方を学んでいくしかないと思うんですよねぇ。

なので、まずは「とにかく"質問しろ"」と。
「どのように質問するか」の前に「思い込みで答えを出してしまって"質問すること"をしない」ってのを、割とよく見かけるので。

………それを考えると「ある程度丁寧に、しっかりと質問が出来ること」ってのは、開発者のレベルの高低を図る、よい指針の一つなのかもしれないなぁ、などと、思ってみたり。