2024.12 - Qiita Night 2024 LT 資料
https://increments.connpass.com/event/335090/
-----
教訓その１）３回以上繰り返し発生する作業は仕組み化する
『積み上がり続ける「とりあえず手動で対応しよか」』
現状維持バイアスの罠：“選択肢が多いほど、人は現状維持の方向に傾くと言う事実が証明されている”
日常的なオペレーションにおいて、発生頻度が低い作業は、エンジニアが手動でコマンドを実行して対応することが多い。➡︎ 手動対応は徐々に積み重なり、結果として本来注力すべき開発業務を圧迫する。
“ 複数の選択肢が提示された場合、現状維持を選択しがちである “
システムの機能要件を定義する際は、運用に必要な機能も漏れなく考慮する。特に、定常的なオペレーション作業は機能として実装することを検討する。
作業が3回以上発生することが予測される場合は、仕組み化を検討する。その上で、自動化や他チームへの移譲など、最適な方法を選択する。
「トイルの削減」に計画的に工数を確保できる仕組みを整える。
教訓その２）リファクタリングを起点に考えない。
『終わりが見えない大規模リファクタリング』
サンクスコストの罠：“意味も持たなくなってしまったような意思決定を何とか正当化しようとして、本来選ぶべきではない選択肢を選ぶ”
技術的負債の解消を目指し、コア機能のリファクタリングに着手。しかし、プロダクト要件との乖離が徐々に生まれ、技術的な懸念も浮上。進むも退くも辛い状況に...➡︎ これまで進めてきたリファクタリングを全戻しする。
リファクタリングは、プロダクトの方向性と整合性を取りながら進める。現行システムと目指すべき姿の両方を明確に定義し、適切な範囲で実施する。
ドメインエキスパートの知見は重要だが、それだけでは十分ではない。システムの技術的な制約や実装上の課題も含めて、ドメインを包括的に理解する。
リファクタリングは、あくまでもシステム改善の手段の一つである。プロダクトの目標達成における位置づけを明確にし、その効果と影響を慎重に評価する。
教訓その３）新しい技術やツールの導入は運用面もしっかり考慮する
『導入担当者と同時に消えゆくシステム』
確証バイアスの罠：“その時点で抱いた直観や観点を裏付けるような情報しかあなたは受け入れず、反対意見などには耳を貸さない”
注目を集めていた新しい言語とフレームワークを一部機能に導入。しかし、主導していたエンジニアがチームを去った後、残されたチームは改修や運用保守への対応に苦心することになる。➡︎ 既存の言語スタックへ書き換えられる。
新しい技術に関心を持ち探求することは大切。ただし、その興味が確証バイアスとなり、本来必要な検討事項を見落とさないよう注意する。
新しい技術へのチャレンジは重要だが、本番環境への導入では運用面の検討が不可欠。特にエンドユーザーへの影響が想定される機能は慎重に判断する。
教訓その４）いかなるシステムにおいて最も重要な機能は信頼性である
『レイテンシ改善を後回しにした矢先、襲いかかる大量アクセス』
フレーミングの罠：“問題の理解の仕方次第で、取るべき選択肢が大きく変わってくる”
新機能の開発を優先する中で、レイテンシや可用性といったシステムの信頼性指標の可視化や改善への取り組みが後回しとなる。➡︎ 想定外の大量アクセスにより鳴り響く、嬉しい悲鳴とインフラの悲鳴
ビジネス指標の改善だけを追いかけるのではなく、エンドユーザーへの価値提供を多角的に捉え、信頼性も含めた総合的な課題設定を心がける。
新機能の企画段階から、非機能要件も価値提供の重要な要素として位置付ける。機能開発と信頼性は、トレードオフではなく両輪として捉える。
新機能か信頼性かという二項対立の思考ではなく、両者の価値を意識する。
教訓その５）過去経験や他社事例に囚われず、事実ベースの思考を心掛ける
『会社の規模や実態に馴染まない、プラクティスの導入』
アンカリングの罠：“人は一番最初に得た情報にどうしてもこだわってしまう”
過去の成功体験や他社事例という「最初の情報」に縛られすぎると、現状に最適な判断を見失う可能性がある。事実に基づく分析と建設的な議論を通じて、より良い選択肢を探る。
一見同じような課題に見えても、実際の状況は大きく異なることがある。過去の経験は参考程度に留め、現状分析を丁寧に行おう。
技術プラクティスは進化し続けている。過去の常識に固執せず、現代における有効性を見極め、導入の判断を行う。
他社の成功事例に引きづられることなく、自社の規模や実態に即した判断を心がける。
教訓その６）見積もりは当てない、解き明かす
『やっぱり足りない、工数の見積もり』
見積もりと予測にまつわる三つの罠：“「自信過剰の罠」「安全第一主義の罠」「偏った記憶の罠」
見積もりは、予測して終わらせず、完璧さを追い求めるでもなく。チームの特性や傾向を科学的に捉え、継続的な改善を重ねていくプロセスを考える。
「自信過剰の罠」：過去の経験や実績に基づく過信が、安易な見積もりを生む。「似たような機能を作った経験がある」「このチームなら簡単」という思い込みには注意。
「安全第一主義の罠」：必要以上のバッファは、チームのモチベーションとフロー状態を妨げ、プロジェクト全体の推進力を失わせる場合もある。過度に慎重な見積もりが、かえってプロジェクトの効率を下げていないか意識する。
「偏った記憶の罠」：印象的な成功や失敗の経験が、現在の判断に過度な影響を与える。過去の特定の出来事に引きずられず、現状に即した判断を心がける。
9ma3r
bkeepers
eileencodes
kneath
matthewcrist
tenderlove
bermonpainter
denniskardys
destraynor
thekraken
smashingmag
bluesmoon
sugarenia
