hirotobeat

前書き

現在、所属している企業でフロントエンドエンジニアとして、UI周りのリプレイスを行なっております。
プロダクト開発の体制は、下記の体制でサービス開発に臨んでいます。

現状、スクラム体制での開発は細々したものは以前から経験しておりましたが、自身が主軸となって実際にフロント領域をリードしつつ、リプレイスという大きなプロジェクトを進めていくのは、初めての経験です。また、UXデザイナーを交えたコンポーネント定義などを行い、Atomic Designに沿って実装を進めている段階です。

チーム体制

プロダクトオーナー
スクラムマスター
バックエンド
フロントエンド
UXデザイナー

※各領域１人で構成された体制です。

一番重要なこと

プロダクト開発チームはユーザーに価値を届けること、それが最優先にかがげています。

通常、エンジニアは完全なコード、計画通りの進行に、ステークホルダーは機能の充実に目が行きがち。
でも、これらはあくまで手段であって、目的ではないということを共通認識として持っています。

ユーザーからすれば、内部実装がどれだけきれいであっても、それ自体に価値はありません。
求めているのは、自分の問題が解決されるという結果だけということです。

※保守運用面で内部実装だ綺麗であることは認知不可を下げるため、開発を行う上では重要です。

スクラム開発：理想とのギャップ

スクラム開発の最も難しいところ。それは経験のないことへの見積もりです。

必要なコンポーネントが足りなかった
チームの経験が浅い領域での開発

こんな状況では、完璧なチケット作成や正確な見積もりは、正直言って難しいし、今ここに苦しんでいます。
なるべく乖離を生まないように思考を凝らしていますが、まだここの見積もり精度は正直甘いです。

現実的な対応：まず動くものを

不確実性に直面したとき、最も優先度の高い価値を届けることです。

なのはまず動く状態のものを作成してユーザーに価値提供をすること。

完璧主義に走ると、期限は破られ、ユーザーを待たせることになります。
「動くもの」があれば、早めにフィードバックをもらって軌道修正できます。

もちろん、これは技術的負債を生み出します。
でも、それは計画的に返済すべき「戦略的負債」と考えましょう。

技術負債との付き合い方

技術負債は悪ではなく、うまく活用すべきツールです。

意図的に選ぶ：「仕方なく」ではなく「戦略的に」選択する
返済計画を持つ：いつ、どう解消するかの見通しを立てる
オープンにする：チーム内で共有し、隠さない

予想外の障害への対応

予期せぬ問題が発生したとき、どう対応する？

早めに共有：問題を隠さず、素早くチームに伝える
スコープの見直し：必要なら優先順位を再検討する
最小実装を考える：コア機能だけでも届ける方法を探る

大切なのは、完璧な実装より「約束した価値」をどうにかして届けるという姿勢だと考えております。

まとめ

プロダクト開発で最も大切なのは「ユーザーへの価値提供」。

完璧なコードや完璧な見積もりを追求するより、まずは動くものを提供し、フィードバックを得ながら改善していく。

技術的負債は時に必要な選択であると考えており、これは決して悪いものではない。

ユーザーが求めているのは完璧なコードではなく、自分の問題が解決されること。

この原点を忘れなければ、日々の判断はグッとシンプルになるのかなと感じました。

プロダクト開発における最近の考え