X(Twitter) Zenn GitHub RSS 共有

一時保存場

作成日時：2025-07-23
更新日時：2025-10-17

別の文書やカテゴリに振り分けていないメモの集合。

人間の脳をPCに例えたらこんな感じ

ToDo

memo

メモとは

金銭の話

どういう風に清算している？
稼働の上限と下限は？
売り上げに密接に関連する情報なのになんで連携しないの？

ストレージ

Content-Security-Policy

unsafe-inlineは使用しない。
定義するとすべてのinlineスクリプトを許容する。
nonceかhashを使う。

どうしても避けられない場合のみunsafe-inlineを使う。

Content-Security-Policyは基本OR定義。

Content-Security-Policy (CSP) - HTTP | MDN

ServiceパターンとUseCaseパターンの違い

前者はあるドメインに対する操作の集合。
後者は1操作または1ユースケース。

【Laravel】Serviceについて/Usecaseとの違い/簡単な実装 #Laravel - Qiita

ユースケースからサービスを呼ぶ。

アーキテクチャにもよるが、サービスはコントローラーから呼ばれない。
Springのサービスはユースケースを兼ねている。

Springのサービスクラスはファットになるので、ユースケースを使って1APIにつき1クラスのほうが好き。
Springの文脈で言えば、1コントローラーに1サービス

投機的実行

ピラミッド原則

縦は抽象と具体、whyとreason
横は演繹か帰納

So, What / Why So

スコープ

やること　と　やらないこと
話すこと　と　話さないこと
対象　と　対象外

大体の不幸は乖離

現実と理想の乖離
現実と認識の乖離
現実と認知の乖離

AWSでなくとも

安いVPS上にDocker載せれば？
あとはドメインと証明書

でもAWSのほうが楽。
考えることが少なくて済むし、
情報はネットですぐ出てくる。
スケールアップとかも。

予算次第だね。

DB

インデックスの見直し

スケールアップ

readが多いならスケールアップよりスケールアウト？
スペックを下げて台数を増やす

チーム間の情報連携不足による障害が多発しすぎている
コンウェイの法則、ハイラムの法則

言われたことをただやるだけならもうAIでいい。
付加価値をつけろ

markdownはidomatic。
直感的で読みやすい。
読み手がMarkdownに慣れているなら認知負荷を下げられる

バリューチェーン
人事もPVも同じ
まずは認知、そのあとに誘導

コンテキストの共有

顧客との会話や仕様の決定など。
全部コンテキストの共有が重要では。

デスマーチ

デスマートは無茶なQCDSの要求から発生する。
ならば、どう防ぐか。

パラフレージング

相手の話を要約して相手に返す。
相手は受け入れられていると感じる。
ついでに確認、合意を得られる効果もある。

帳票

下記に該当するならば、サーバーで出力。

そうでないならば、フロント。
速度とコストが良く、サーバーの負荷なし。
HTMLがわかればメンテできる。

いつの情報を出すべきか。

造語症

勝手な言葉を作るな。認知負荷になる。
ラベリングはメリットがあるが、それを他者との会話に使用する場合は説明しなければならない。

要件を詰めるのが自分の仕事だ。

ドメイン

上代(じょうだい): 販売価格
下代(げだい): 仕入価格

虚無

人間はカスである。
虚無主義か？否である。
虚無主義は価値が無いと言っている。
俺のは「カス」という負の価値があると言っている。

性悪説のほうが近い。

会話

声は大きくハキハキと。
汚い言葉は使わない。
伝わらなければ、意味が無い。

マイナス系の言葉を発するな。
声が小さいから誤解される。
なるべく喋んな。
黙して語ることなし。

顧客と正当化

顧客は正当化で洗脳する。
材料は超上流工程。
「本来の目的を達成するため」が材料となる。
「納期に間に合わないからスコープを減らしたい」ではなく「目標を実現するために、お客さんに現時点における最大限の価値のある製品を渡す」
前者だと請負契約を盾に攻撃してくる。

サポート

サポートは担当者名ではなく「サポートチーム」を記載
個人の負担を減らすのと、担当者名の一貫性を保持しなくても済む

デイリースクラム

メンバーの話をちゃんと聞く
デイリースクラムに必要なのは、何かしらの不安や阻害要因の発見

乱数

JavaのRandomはタイミング次第で被りうる。
SecureRandomかUUIDを使う。

ドキュメント

やはり、形容詞や副詞は曖昧性が入り込む。
要件定義ではやめろ。

プロマネ

シフトレフト

さっさとプロトを作って、早い段階でユーザーに見せろ。

論文

AIの活用で納期短縮とか。
具体的な作業として、セキュリティやルール作成、ステークホルダーへの説明や上長への確認など。

伝達に関して

声は大きく明瞭に。
汚い表現は使わず、正確に。
ドキュメントライティングと同じく、伝わらなければ意味が無い。

営業

資格に関して

SES営業において、エンジニアの資格の有無は顧客との交渉に使えないというが、使おうとしないだけでは。
「取れと言ったら数日で取りました」
「(顧客の)利益を上げるために取得しました」
などの文脈を与えたらどうなるか。

正当化

顧客は正当化で洗脳する。材料は超上流工程。
仮にスコープ変更の交渉をする場合、
「このままだと間に合わないので、この機能は落とします」
「超上流工程における目的を達成するためにスコープを変更します。お客さんのためです。」
どちらが受容されやすいか。後者。

他人は正当化で操れ。

心理学

バイアスや正当化なくして人間は判断できるのか
→できない。
多かれ少なかれバイアスや正当化が影響を与える。

Java

基本的に最新バージョンでよい。
パフォーマンスや記述法などにおいて。
ただし、フレームワークが対応しているかに注意。

25

思想

システム開発とは合意形成を繰り返す作業である。

決して自分だけの判断で作業を進めてはならない。
それはシステム開発における最悪の愚行といえる。

バリューチェーン

自身の給料は会社の利益から出る。
会社の利益は顧客の予算から出る。
顧客の予算は顧客の利益から出る。

故に圧倒的当事者意識で顧客の利益を追求する。
顧客に予算を上げる余裕が無ければ、会社の利益は上がらない。

k8s

環境変数には暗号化した値を格納する。
k8sの公開鍵で暗号化できるらしい。

不安

思考の状態遷移

思考の状態遷移を回したら、合意形成に移る

スクラムとかアジャイル

知識の共有が大事。
目的意識とか。

SECIモデル - Wikipedia

プログラミングは価値提供の手段であって、目的ではない

UXや利益が目的。

DevOpsの重要性

インフラチームと開発チームに分けたら情報連携が遅い
もしくは対応してくれなかったり

組織

メンバーがコロコロ変わる組織では、知識は蓄積しない。

GraphQL

ドッグフード

作っているシステムを自ら使う。
チーム内からの要求分析。

OODA

曖昧な状況下で使える。
PDCAは曖昧な状況下では計画が立てられない。

EKS

cron的にバッチを動かすことができる。(CronJob)
終わったらリソースが消える。(残す設定もある)
費用を最小にできそう。

ec2が余っていれば余剰リソースで実施してもいいけど。

pending

しばらく止めていたk8sを動かそうとすると、
止まっていたcronJobが一気に動き出し複数のpodがpendingになるかもしれない。
(リソースを割り当てられない状態)

podを消しても、また新しく作られる。
Jobが残っているため。
PendingのPodを停止・削除するには、Podの親であるJobリソースを削除。

# 実行中のJobを確認
kubectl get jobs

# 該当のJobを削除（関連するPodも同時に削除される）
kubectl delete job <job名>

コストが跳ね上がりそうなので、止めていたk8sを動かすときは注意する。

事前抑止

k8sに関して。
cronjobが含まれるk8sを久しぶりに起動したら、
cronjobに登録していたバッチが異常なほど大量に立ち上がり、
大量のpending状態のpodができた。

これはstartingDeadlineSecondsがnilかつconcurrencyPolicyがallowであるため、
本来なら停止期間中に動いていたら起動していた分のバッチが一気に立ち上がったためか。

→あってるっぽい。
下記の設定を見直す。

CronJob | Kubernetes
Cron JobでstartingDeadlineSeconds設定のすすめ

阻害要因をつぶす

提案型質問。

何をすれば”それ”は可能となるか。
何が必要か、何をしなければならないか。

FOMO

FOMO - Wikipedia

技術的負債

さっさと返済しろ。

技術的負債の四象限 - Martin Fowler’s Bliki (ja)

EC2とFargate

EC2

Fargate

自分の職場だと？

Lambdaで動かしたくないバッチはFargate。k8sかEventBridgeで動かす。
24時間動かしたり、古臭いシステムはEC2でいいや。

物流

DB

ALTER文が終わらない可能性を考えろ
VACUUMとかも。

レビューと報連相の重要性

システム開発は合意形成を繰り返す作業である。
曖昧なまま作業を進めてはならない。

誰とも合意を得ずに作業を進めた場合、それは手戻りや障害を引き起こしかねない。
自分だけが正しい作業だと思っていても、顧客/チーム/システムからすれば間違っている可能性がある。

故にレビューと密な報連相を行う。
自身の作業の妥当性を、他者を介して検証する。

全てに対して「本当に正しいか」疑い、少しでも怪しければ相談する。

SNSで他者を攻撃する人間

SNSで他者を攻撃する人間は、

何者にもなれないがために
たまたま目についた大きなものを
安全圏から攻撃することによって
何者かになれた気になるという
虚しい営みを繰り返す生物

である。

その営みが許されるのは学生までである。
何故ならば、学生は何者かになるのが難しいためだ。
能力が未熟で、成し遂げる財力も無く、親や学校の束縛がある。
故に許される。
ある意味、その営みは成長の過程とも言える。
昔のパンク・ロックのように、反体制・社会や親への反抗などもこれにあたる。

「何者である」とは何か。
それは自己肯定感を有することである。
自己を肯定する理由はなんでも良い。

他者を攻撃する人間はこれらすらない。
自己肯定感が低い。自分に価値が無いと考えている。
常に何かしらの強迫観念に襲われている。
つまり余裕が無い。
これも他者を攻撃する理由の一つとも考えられる。

「何者かになる」というのは、一見、他者からの評価によって決まると思いがちだ。
しかし、他者は一切関係ない。
自分が自分自身をどう思うかである。

自己肯定感がある(=何者かになっている)ならば、他者を攻撃する必要はないし、
そもそも気にしない。

スプリント中の障害

現在のスプリントを中止して即時対応。
重要度・緊急度が低ければ次のスプリントで修正。

チケット駆動開発

チケット駆動開発の本を読んだがあまり響かなかった。
当り前の内容だったため。

タスク管理の話だった。
スクラムにおける、バックログとタスクボード周りの話。
計測(障害要因分析とかリードタイムとか)に関してはレトロスペクティブあたり。

タスクをチケットに起票して管理するのは当たり前。
チケットの肝は如何に”わかる”文章を書くか。

ドキュメント・ライティングとスクラムの本を読んだほうがためになる。

翻訳

業務アプリで翻訳ツールを使うな。
翻訳サーバにデータ飛ぶから。

SESとして働く

会社と顧客の利益を追求して働け。
これは、会社と顧客のために働けとは言っていない。
自分のために働け。
他者はどうでもいい。
自分のために、他者に貢献しろ。

生きるためには金が要る。
給料は、会社の利益から出る。
会社の利益は、顧客の利益から出る。

金を得たいならば、会社と顧客の利益を追求する。
そうすれば、手元に入る金は増える。
(もし努力によって増えた利益が給料に還元されない会社なら、辞めればいい)

SESを対象として具体的に考える。
金が無い顧客に単価交渉をして、単価UPができるか？
単価を上げるためには、顧客の利益を上げなければならない。

圧倒的当事者意識で、顧客のビジネスを考える。
「システムを開発するだけ」では、何も評価されない。
提案をしろ。

対象のプロダクトにおいて、顧客の利益増加に繋がりそうな機能を考えて提案しろ。
インフラに無駄なコストが掛かっているなら、コスト低減案を出せ。
出向先のシステム開発体制の問題と改善案を出せ。
善を追求しろ。

自身を商品と見立て、狩野モデルで考える。
自身の作業は、当り前品質と一元的品質を満たし、魅力品質を顧客に提供しているか。

会社と顧客の利益を追求して働け。