Notices by ପ(0w0)ଓ@Ahiro (0w0@qiitadon.com), page 3

そんなバカな…Qiitadonに来るような人類が、こんなにキュートなイラストを描くなんて…（強固な偏見）

「自分の種類は『鈍器』なのか、『刃物』なのか、あるいは他の『何か』なのかみたいなことを普段から意識すると人生の役に立つよ」みたいなことはよく言うな。
巨大な鉄塊が「僕は日本刀さんのように切れ味がないからダメなんです…目の細かい研ぎ石とか使って努力してはいるんですけど...」とか言ってるパターンをよく見かけるけど、別にお前で相手の頭を叩けば即死だし、「そこはがんばらなくてもいいぞ」みたいな。
あるいは布が「鉄塊さんは固いだけいいじゃないですか…僕なんてふよふよで…どう生きていけばいいのか…」とか言っているので、「鉄塊は持ち歩いてたら職質されるけどお前は持ち運びやすいしサッと絞め殺せるぞ」みたいな。（何もかもが不穏な例え）

（恐縮するよと氏を挟んで恋の鍔迫り合いが今まさに行われようとしていた）

「工数はマネージャーが管理する事柄なのでプレイヤーは工数を一切意識しなくてもよい」という論説はよく出てくるけど、これは極端な見方だと思っている。
プレイヤーが実際に「プログラミングを最前線で『プレイ』」する以上は、プレイヤーにしか見えない風景というのは間違いなく出てくる。（いわゆる「やってみたらダメだった」「納得のいく説明はしにくいけど、エンジニア的になんかダメな予感がする」みたいなやつ）
大体の場合、「後に響く工数のズレ」というのはこういう小石で転んだことによる骨折が原因だったりする。プレイヤーは小石を踏まえた「俺が思う雑な工数予測」を持っておいて、それをどんどんマネージャーにぶつけた方がPJの質は上がる。（もちろん、マネージャーも「なんかダメだと思うんですよね」はヒアリングして内情を引きずり出すべき）
ただ、「プレイヤーが全てを自己管理し、正確無比に達成しろ」は確実に間違い。プロジェクトを俯瞰していない人間が全体最適を踏まえた結論を導き出せる訳がないし、プレイヤー全員に強制させたらオーバーヘッド出まくりでコストメリットが立たない。
多様な立場の意見を混ぜることが大事。

先に出したツイアカの人は、どうも「早すぎる最適化」の話がしたいらしいのだが、これが結局難問なんだよね。「『早すぎる』って何よ？俺は早すぎると思わないが？？？」みたいな宗教戦争の話になる。マネージャと工数握るだけでは厳しい場面も少なくない、というのが僕の感想。
「早すぎた」かどうかは「結果」と「その解釈」が決める、いわゆる結果論の話になりがち。最適化がバグを減らした客観的指標を駆使しても「俺は今回の最適化は必要なかったと思う、最適化しなければもっとコストメリットが出てた筈だ」というヤツは出てくる。逆に緻密なDDDベースの設計モデルが、ビジネスに乗っけてみたら「モデルの解釈がなんか違うぞ」みたいな話になって全面改訂、でも「この設計は皆で緻密に考えたんだから正しいんだ」みたいな欺瞞が出てきて更改が進まずビジネスが沈没、というパターンもあり得る。
ステークスホルダー同士で方向を決めて、結果を「現実」に問い、ズレを直視して修正するしか道はない。

「情報統合思念体の思考形態はRDBなので、DBマンは情報統合思念体に向いてる」って知り合いの情報統合思念体が言ってました

「コードの適切さ」はロジカルに積み上げられた原則の集積かというとビジネス的にはそうではないという認識。例えばオブジェクト指向を扱うコストメリットが立たないという確度の高い予測が立てば（例えば確保出来る人員が新人だけで、かつシステムも使い捨てる場合）、適切なコードは「手続き的」な可能性もありうる。
「チームの成熟度」や「技術知ったか上司が裁量握ってる」とか「予算」とか、多種多様な変数を踏まえて導き出された解が「コードの適切さ」。これは差配するときの基本原則にしてる。
ただし、この見極めは極めて難しく自己欺瞞に陥りやすいので、結局は原則に寄せた方がコストメリットは立ちやすい。これは差配した結果としての経験則。

カジュお茶でいい雰囲気になるんだけど保守案件にstruts2がいるみたいな話になってピリッとする「採れたかも委員会」

ぽむさんがよとさんのストーカーなのは公然の事実だけど、実はばななさんもずっとやらしい目でよとさんを見てたよね。ぼく知ってるんだ、本当は前から「あわよくば」と思ってるって...（中途採用に関わる健全な話題）

子育て経験者みたいな書きぶりだが子供はいない、なのに子育てスキルが高いので周囲から隠し子疑惑が上がるマンです。（世を忍ぶ仮の弟と歳が離れてただけﾀﾞﾖ…）

今でもあるかわかんないけど、ひよこクラブみたいな雑誌にはオマケで「子供の病気大百科」みたいなのが付いてくることがあって、
これは川崎病みたいなレアな難病も網羅してる謎の充実度がありオススメです。わけわからん謎の病気にかかった時にも役立つし、ふつうに読み物としても面白い。

乳児のトイレはお むつ取れるまでは自律的コントロールが難しいので、周期性を獲得するまではガーゼなどを準備して入浴、周期性獲得後は時間を見計らうのがよろしいかと愚考します

情報工学系の学生はTech系企業に取られて死亡、世間の企業も高価なフルスクラッチのシステムから安価で小回りが効くソリューションに軸足を移し、中〜小規模のシステム開発需要は激減。
ただでさえ無い技術力が益々低下し、システム開発ができなくなったSIerが生き残るには…

さあ！僕と契約してRPAエンジニアになってよ！！人◕ ‿‿ ◕人

すごく大ざっぱにまとめると、SIerは「心理的安全性を下げることで売上げの大きさを作るスキーム」だということだよ。一見非合理的で苦しい現場が絶えない理由は、それがマクロスケールで見ると合理的だからなんだ。
誰も苦しい状況を改善しようとしないのが不思議だと思っていたかい？地獄を改善しないといけないという使命感に駆られていたかい？
逆だよ！キミはむしろ組織の成長を妨げるような真似をしてしまっていたんだ！でも大丈夫、キミはもう社会の仕組みを完全に理解した！これでキミもボクらの仲間入りさ！さあ、僕と契約して人売りプロジェクトマネージャになってよ！人◕ ‿‿ ◕人

SIerがエクスキューズ駆動開発になりがちな理由は、一括請負という伝統的手法が顧客とベンダ間の「立場の違い」を強化するから、と解釈している。
これが何故是正されなかったかと言うと、コミュニケーションコストは「人月」というわかりやすい概念に比べて、自信の説明容易性が低いから。
言い換えれば、顧客から見えない領域で「売上げを膨らませやすい」。
これはかなり邪悪な発想なので、全てのベンダが意識的にやっている訳ではない。しかし、ビジネススキームがそうなっている以上、「結果的に」それをやったベンダが生き残りやすい傾向は出てきてしまう。意味不明なSIerの風土の起源は大体ここから、という認識。

SIer内で技術投資が効かなかったりするのも同じ理由。工数が減れば売上げが落ちるので、よい技術は自然淘汰される。

立場が違う人間が多いほど思想のコンバートが必要になるので、実体としては「わかりやすいエクスキューズ作り」はどこかで必要になるっすな。一方、「エクスキューズ作り」はコミュニケーションコストそのものなので、会計のようなクリティカルな分野以外では出来るだけ減らした方がよいとは思う。

怒られを基準に仕事をする習慣が続くと、「怒られない仕事」だけが上手になっていき、無駄に分厚いマニュアルを作ったり、とりあえず体制側に立つためにルールを大声で叫ぶようになったりします。
これがシステム開発に波及した結果が、安心と信頼のCOBOLを永久に使い続ける、「書き損ねない」為にDRY無視したコピペだらけの設計書を作る、長大なExcelエビデンスを作ったりするといった「とりあえず怒られないようにがんばりました」というSIer的所作になるわけですね。
これを僕は「エクスキューズ駆動開発（言い訳駆動開発）」と呼んでいます。

またみんなで闇のはなししてる…(´・ω・`)

「人の役に立て」と言われたとき、「『お前は努力不足だ』と暗に言っている」いう解釈は一つの仮説に過ぎなくて、

・本当に努力していない
・こちらは適切な振る舞いをしているけど、評価者がそれを適切に評価する術を持っていない
・評価者は実のところ振る舞いを認めているが、周囲から「彼は努力していないので指摘して欲しい」と言われ、仕方なくやっている
・努力してないし、評価者も適切に評価できない
・とりあえず嫌いなのでこき下ろしている
・単なる口癖

など、多種多様なバリエーションが考えられるので、自分の知るメタ情報を並べて真意を探る感じかなあ。それで、本当に間違っているのは自分なのであれば修正するし、悪意があるなら心の中で唾を吐くのが0w0スタイル。

確かに自分を分離する行為は離人症とか解離性人格障害を誘発するので、あまりにも強烈なストレスならちょっと危なげな印象はあるな。