X(Twitter) Zenn GitHub RSS 共有

開発関連のメモ

作成日時：2026-03-15
更新日時：2026-03-15

さっさと確認する

後工程の手戻りは悲惨

W字モデル
動くもの、つまり分かりやすいものを見せてイメージを共有

疑問に思ったら、まず考える。
資料やWikiを確認して考える。

分からなかったら、すぐに聞く。
仕様が不明なまま作業を進めるのは自殺行為である。

分かっても、念のために聞く。
自身の考えの妥当性は他者によってしか検証できない。
疑問に思った時点で曖昧性を孕んでいる。

すぐに聞く。
「もうすぐ定例だから」と溜めずにすぐに聞く。
その疑問点は他者の作業の手戻りに発展する可能性があるから。

そもそも定例で仕様の話をするな。
参加者全員に関係のある内容だったらいいが、
そうでない場合は無駄な時間を過ごすことになる。
(と言ったが、自分自身いまの現場で定例時に仕様の話をよくするので猛省)

仕様の話をするならば、定例の後に枠を作って関係者のみで話す。

→スタンドアップミーティング

もっともよいコーディングは、実装しないこと。
コーディングはビジネス上の目標を達成するための手段でしかない。

ブルックスの法則に関して

適切な管理下であれば人員追加は有効。

でも基本的に適切なマネジメントをしている組織は炎上しない。
なので、ブルックスの法則は常に正しくなる。

リーン

さっさと作って
さっさとFBをもらい
さっさと直す

リアルタイム議事録によるずれの修正

会話者が話しながら議事録を作ったほうがいいのでは。
リアルタイムで認識の齟齬を検出できるし。
そのまま資料として残せる。

ビッグバンリリース

細かく分けて統合したほうがバグが出ないよね。
30の機能を一気に追加するより、3つのスプリントに分けて10ずつ追加したほうが、統合時のバグを減らせる。
スクラムの手法は正しい。

ステークホルダーが関わりやすい場の構築

心理的安全性然り

変更しなければ壊れることは無い

しかし、機能を追加しなければ競合他社に負けるし、
セキュリティ的にもよろしくない。

デプロイ

デプロイ頻度を挙げれば、最善との乖離をすぐ検出できるし、ビッグバンリリースも防げる。
すぐに直せる状態となる。

障害対応

WhyとHowの周知

プロジェクト開始時に明確にしておくべき。

キャンベル

「顧客からの問い合わせを減らす」と言って、お問い合わせフォームを消して「問い合わせ0です！」ってなるか？
目的はUXの改善では。

メンター

経験年数が離れている人間をメンターにしてはいけない。
技術の呪いがある。
間にミドルを入れて、プロキシ・メンターにするならばマシ。

シンプルならば設計書は詳細に書かなくてもいい

SESはコンサルの素養が必要になってくるのでは

コーディングはAIがやってくれるし。
AIに対するINPUT、システムの方向性を決める能力が求められるのでは。

提案力とまともな文書を書く能力が必須か。

「正しい」が常に正しい保証はない

常に検証しろ。
検証が面倒ならばブレることが少ない原理・原則を学べば？

負債

負債の返済が楽なら破産する奴はいねーよ
さっさと技術的負債は無くせ
もしくはさっさと返せ

情報の保持

LLMにしても、障害対応にしても、開発にしても
結局は情報を文書として残し保守しなければならない。
SECI、情報の共有。

問題なし

「問題なし」と思っても
それはあなたの中だけの話であって
他者、システム的に「問題が無い」という保証はない。
自身の行動や成果物の妥当性は、他者によってしか検証できない。
そのためのレビューや報連相。

設計書

合意のための道具

もしかして～ですか

というインタビューは相手の要求を捻じ曲げて、本来の要求を取れなくなる