やるためにやっておく | trueの技術日誌

溜まっていた課題を翌日に持ち越し、予定通り就寝して早朝に取り組むという社会人典型を実践できた。これまでは難しいと考えていたことが、徐々に習慣として定着しつつあるように感じる。

この変化がなぜ起きているのかは説明できない。一方で、日々の小さな約束を守ることが継続の土台になっている可能性はある。

Uzabase

実装の並列化に着手する前段階で想定以上に時間を消費した。

主な要因は、テストの扱いに対する理解不足だった。現在の業務範囲では変更の影響範囲が限定的であるにもかかわらず、必要以上に広い範囲の確認を行っていた。また、テストそのものだけでなく、mainブランチとの差分解消や競合対応といった周辺作業も工程に含まれることを十分に見積もれていなかった。

今回の経験から、実装作業だけでなく、その前後に発生する付随タスクも含めて開発工程として捉える必要があると分かった。今後は、変更箇所と影響範囲を把握した上で適切なテストを選択し、競合が発生しやすい状況を事前に避ける進め方を意識したい。

アーキテクチャの技術スタック選定は概ね順調に進んだ。

まずアプリケーションの特性から必要条件を整理し、その条件を満たす技術候補を調査する形で検討を進めた。技術そのものから入るのではなく、解決すべき問題や要求から逆算して選定できた点は有効だった。

一方で、プロダクト設計に関する議論では十分に貢献できなかった。個別の機能や仕様に対する提案を行ったものの、プロダクト全体の文脈や利用者体験との接続が弱かったためである。

後から振り返ると、User Lifespanのような利用者の行動プロセスに沿って整理すれば、より構造的に議論へ参加できた可能性がある。ただし、その場で適用できるほど習熟していなかった。

現在は、経験によって獲得される設計上の判断をどのように形式知化できるかに関心がある。将来的には、ユーザー行動や要件整理のフレームワークをより明示的な手順へ落とし込み、設計支援や自動化につなげられないか検討したい。