X(Twitter) Zenn GitHub RSS 共有

マインド

作成日時：2025-07-22
更新日時：2025-07-22

技術的負債

これらがある場合にのみ借りることができる。
返済計画もないのに借りるのは、ただのカス。

simple is best

余計な機能は付けない
シンプルな方が解りやすい
その代わり変更しやすい体制を
adr, design doc, test, code

システム化の対象

クラスもテーブルもヒト・モノ・コトを表せ

ファインマンテクニック

説明する人がいないならば、脳内の自分に対して説明する。
ある意味、アクティブラーニングの最下層「人に教える」を行っていると言える。

完了条件を書く

曖昧性

曖昧性は排除しなければならないが、完全に排除することはできない。
汚いコードは排除しなければならないが、完全に排除することはできない。

永遠にそれら排除する努力をし続けなければならない。
シーシュポスの神話

言葉

言葉の解析に相手の頭を使わせてはならない
作業指示ならば作業内容を、
報告ならば報告内容が
明確に伝わらなければならない。
作業指示や報告の、文章そのものの解析に相手の頭を使わせてはならない
認知負荷と曖昧性を産む

相手に合わせた話し方

変更しない

変更は不具合を持ち込む
だからなるべく変更はしない
→OCP

作業をするなら目的を定めろ

何がしたいのか
負荷試験をするならどういったデータを作ってどう登録し、どういう指標を取るのか。

コーディング規約 / コードレビュー / 設計書

設計書が無いと属人化を招く。実装者にしか分からんから。
設計書が無くてもコードを見ればいいが規約やレビューがなされていなければ可読性が低い。

情報連携

チームへの外部打合せ内容の展開は絶対。
チーム間の情報連携も必須。
コンウェイの法則。

抽象

結論専攻は”抽象”を先に説明する。
次の段落で具体的に話す。
抽象≒概要≒要約

文脈/単語/目次

どうすればできるかではなく

何ができるかを知っておく
後者のほうが提案可能性が広がる→
https://findy-code.io/media/articles/event-twada-250514

セキュリティ対策できないから受注しないって

ただの機会損失だろ

余計なものは顧客に見せない

体制は疑問提起から生まれる

「じゃあこうしよう」が、具体化されたものが体制。

言語こそPJで一番曖昧性を持つ

文章から如何に曖昧性を除去できるか。
「何を言っているか」を考えるリソースを創造的な思考に使わせる。
その為に、明確な意思疎通が必要。

「何故」を説明する。
同意と共通認識を得る。

形容詞と副詞を排除し、定量的に伝える。

正しさは文脈に依存する

だからBOSCARとADR。

未知の未知とアジャイル

早く失敗することで「未知の未知」を知る。

圧倒的当事者意識

超上流工程を考える。

privateメソッドが多いとそのクラスの責務が重たいサイン
関心の分離の観点でクラスを設計するとprivateは無くなる
⇒テストしやすい

その他

セキュリティを重視する

既存パッケージに対して、金融系の顧客から導入依頼が来たとする。
金融系なので高いセキュリティ要件が求められる。

しかし、現状のシステムは脆弱性に塗れており、要件を満たすようにするには
コストがかかる。
そのため、新しい顧客の導入は見送った。

もし、現状のシステムのセキュリティが堅牢であるならば
新しい顧客に導入できた。

機会損失に過ぎない。

コードは綺麗に

汚いコードはリードタイムが延びる。
新たなバグを埋め込む原因となりうる。
障害発生時の調査時間も延びる。

横の情報連携を綿密に行う

フロントとバックでの認識のすれ違いにより、障害が発生する。
コンウェイの法則。

負荷テストをする

何故やらない？
案の定、本番障害発生。
CPUとメモリが100%になったじゃん。

アラートを設定する

何故アラートを設定しないのか。
上記のトラブルも顧客からの連絡で発覚した。

本番で障害が発生した際の初動が遅れるし、原因分析も難しくなる。

コスト最適化をする + CI/CDの構築

何故やらないのか。
いちいち手動でデプロイするのはコストの無駄 + オペミスによる本番障害を起こす。

ECSとか使えば自動化できる。
顧客の業務時間が終わったなら、サーバも落としておく。

凝集度

とにかく凝集度を高める。
アナロジー⇒DBも。
DBはクラス設計とでも思えばいい。

LCOM=1 ⇒クラス
全再利用 ⇒コンポーネント

メソッド、クラス、パッケージ、ライブラリ、システム(マイクロサービス)
全レイヤーにおいて高凝集であることが、高品質なサービスを作る原則ですかね

全てが高凝集であり、他の変更の影響を受けないように
関心の分離
KISに繋がる

高凝集、疎結合
メンバーは少なく、引数少なく
関心事の分離
ファサード

凝集度を高め小さく行う

真っ先にコストの話をする