きっかけ
自社で開発しているプロダクトのコアとなる機能の実装をする過程で、多くの学びがありました。
ここではその学びを記録する備忘録としてまとめます。
文言の一貫性
ドラフト段階ですが、メール本文の文面も検討しました。
たとえば「〇〇様」や「〇〇さん」など、敬称の表記揺れが見受けられました。
機能要件が満たせているか、保守性が高いかといった観点に意識が向き過ぎ、細かな文言チェックを怠っていました。
実装中は誤字・脱字・表記揺れが発生しやすいものです。実装がひと段落したら一呼吸おき、文言を再チェックする習慣をつけたいと思います。
既存コードの書き換えの前に影響度を調査する
言うまでもありませんが、既存関数を修正する際はその関数を利用する他機能で正常に動作するかを確認する必要があります。
テストコードが用意されていない現場もあるため、手動でも影響範囲を調査できるスキルを身に付けたいところです。
ユーザーファースト
今回の機能実装では、ドメイン理解・要件整理・状態遷移の設計を入念に行ったため、実装自体は堅牢に仕上がりました（と信じたいところです）。
しかし実装側のイメージに引っ張られ、フロントの UI/UX をユーザー目線で十分に検証できていませんでした。
目標は「機能要件は満たしているがユーザーファーストではない実装」に気付けるようになることです。
そのためには、実装者ではなく、ユーザーとして触ってみる--具体的なユースケースを想定して操作し、無意識下の「あたりまえ」を顕在化させることが大切だと感じました。
UI/UX
ユーザーファーストと重なる部分ですが、もう少し具体的な学びです。
データタイプを選択する画面ではラジオボタンを使っていました。
しかし選択肢は2つのみで互いに排他的だったため、最終的にはトグルスイッチで実装しました。
今後は「選択肢が2つで排他的の場合はトグルで実装できないか」をまず検討できるようになりたいです。
仕様を疑う
実装が複雑になりそうな場合は、使用を変更できないか検討し、提案することも重要だと気づきました。
ビジネス都合ばかりを優先せず、システムファーストで考える場面とユーザーファーストで考える場面を明確に分けられるようになりたいです。
まとめ
今回のコア機能の実装で、技術スキルが一気に向上したと実感しています。
ユーザー目線にはまだ伸び代があるものの、システム要件を確実に満たし、システム品質を保った実装ができる点は、自分の大きな強みだと感じました。
これからもモノづくりを存分に楽しんでいきたいと思います^^