1. はじめに
一つの画面がユーザーに届けられるまでには、思っている以上に多くの工程があります。企画からパブリッシングの依頼、開発、テストまで、一つの流れとしてつながっています。今回は、パブリッシングを除くほとんどの工程を自分で担当して進めました。
この記事は、成果物の紹介というより、その過程を振り返る記録です。一つのサイクルを実際に経験しながら、どのようなことを悩み、どこで難しさを感じ、次に何を改善できるのかを整理してみたいと思います。
2. 企画 — 開発者ではなくユーザーの視点から
企画段階で最も悩んだのは、ユーザーの利用フローでした。開発をしていると、実装が単純な方向へ自然と考えが傾くことがあります。しかし、ユーザーが実際にどのような操作を繰り返すのかを、まず思い浮かべるようにしました。
代表的な例が、一覧で項目の状態を変更する機能でした。開発者の視点では、行をクリックして詳細画面へ移動し、値を変更して保存する方法が最も単純です。画面構成も明確で、実装の難易度も低くなります。
しかし、実際の利用シナリオを考えてみると、ユーザーは複数の項目を確認しながら、状態をすばやく変更することが多くありました。詳細画面を何度も行き来する方法では、項目数が増えるほど不要なクリックや画面遷移が繰り返し発生します。
そこで、一覧画面から直接状態を変更できるインライン編集方式を選択しました。実装では、行単位の状態管理、保存に失敗した際の復旧処理、楽観的更新などの追加作業が必要でした。開発工数は増えましたが、ユーザーが繰り返し行う作業を減らすことができました。
もちろん、すべての意思決定をユーザーの利便性だけで行うことはできません。スケジュールや工数という現実的な制約もあります。ただ、どのような選択をするにしても、その理由を明確に認識しておくことが重要だと感じました。ユーザー体験のために受け入れた選択なのか、スケジュール上の妥協なのかを区別できれば、その後の改善方針もより明確になるからです。
3. パブリッシングの依頼 — 伝えることより重要なのは整理すること
今回のサイクルで最も多くを学んだのは、パブリッシングの依頼プロセスでした。パブリッシング自体は専任チームが担当しましたが、私の役割は単に作業を引き渡すことではなく、相手が作業できる状態に整理することでした。
当初は、画面の機能や構成を説明するだけで十分だと思っていました。しかし、実際の協業では、私が当然だと思っていた情報が相手にとってはそうではない場合が多くありました。画面の状態や動作方式、例外的な状況に対する基準が明確でなければ、自然に追加の議論や修正作業が発生しました。
もう一つ感じたのは、作業を始める前に十分な共通認識を持つことが重要だということでした。それぞれが頭の中に描いている画面は少しずつ異なる可能性があるため、事前にすり合わせておかなければ、作業後に再調整するコストが思った以上に大きくなりました。
結局、パブリッシングの依頼は単なる引き渡し業務ではありませんでした。自分が理解した内容をどれだけ明確に整理し、共有できるかが、協業の効率を大きく左右しました。今回の経験を通して、協業で発生する多くの問題は、作業能力の問題ではなく情報伝達の問題である可能性があることを実感しました。
これからは作業を依頼する前にもう一度内容を整理し、相手も同じイメージを描いているかを確認するプロセスに、より多くの時間を使うことになりそうです。
4. 開発 — 準備ができているほどシンプルになる
今回の作業では、開発工程自体は大きな困難もなく進みました。バックエンドとフロントエンドの両方を自分で担当しましたが、予想していたほど行き詰まる場面は多くありませんでした。
当初はその理由を深く考えていませんでしたが、振り返ってみると、開発がスムーズだったのは前の段階である程度方向性が整理されていたからでした。何を作るべきか、画面がどのような状態を持つべきか、ユーザーがどのような流れで機能を利用するのかが、比較的明確になっていました。そのおかげで開発中は、新しい決定を下すよりも、すでに整理された内容を実装することに集中できました。
フロントエンドとバックエンドを同時に担当したことも役立ちました。通常はAPIインターフェースやデータ構造を調整するプロセスが必要ですが、今回は一つの流れとして捉えながら作業できました。フロントエンドで必要な形式を考慮してAPIを設計でき、反対にバックエンドの構造を理解したうえで画面を実装することもできました。
今回の経験を通して、開発の難易度はコードを書く瞬間だけで決まるものではないということを、改めて感じました。前の段階でどれだけ考え、整理したかが、その後の開発プロセスの複雑さを大きく左右しました。開発が簡単だったという事実よりも、なぜ簡単に進められたのかを振り返る機会となりました。
関連する事例を調べてみると、開発よりも設計や画面定義に多くの時間を投資するチームがあるという話が印象に残りました。最初は開発速度が遅く見えるかもしれませんが、実際には実装段階での修正コストを大幅に減らし、全体のリードタイムを短縮する方法でした。
今回の作業を進める中で、なぜそのような方法を選ぶのかを少し理解できました。開発段階でスムーズに進められた理由も、実装工程より前の段階で多くの決定が行われていたからでした。
5. テスト — 思ったより不足していた最後の工程
最も心残りがある工程は、テストでした。
今回は別途テストコードを作成せず、完成した画面を直接確認する方法で検収を行いました。機能が多くない状況では十分に可能な方法であり、実際に大きな問題なく終えることができました。
ただ、作業を終えて振り返ってみると、テストが人の記憶に大きく依存していると感じました。画面が増え、修正が繰り返されるほど、以前確認した機能を再度チェックしなければならない場面が増えていきます。現時点では対応可能な範囲ですが、規模が大きくなるほど同じ方法を維持するのは難しそうでした。
特に、正常な画面フローは自然に確認する一方で、データがない場合やエラーが発生した場合のような例外的なケースは、比較的見落としやすいことも感じました。開発中はこうした状態を十分に考慮したつもりでしたが、いざ検収段階になると、正常なシナリオに集中してしまうことが多くありました。
振り返りをまとめる中で、他のチームのテスト方法も調べてみました。すべての機能をテストコードで管理するのではなく、ユーザーが最も頻繁に利用する主要フローだけを自動化し、残りは手動検収を併用する方法が、思った以上に多く使われていました。特に、E2Eテストで主要シナリオだけを検証したり、Storybookを活用して画面の状態を管理したりする事例が印象的でした。
まだ現在のプロジェクト規模に対しては少し早い選択かもしれませんが、繰り返し検収する作業が増えるのであれば、十分に検討する価値のある方法だと感じました。すべてを一度に変えるのではなく、今の方法に小さな安全策を一つずつ追加していく方向が現実的だと思います。
6. おわりに
今回の作業で最も意義があったのは、一つの画面がユーザーに届けられるまでの過程を、最初から最後まで経験できたことです。
以前は、企画、パブリッシング、開発、テストをそれぞれ独立した段階として考えていたように思います。しかし、全工程を実際に経験することで、それぞれの段階が強くつながっていることを実感できました。前の段階で整理された内容は次の段階をスムーズにし、反対に曖昧だった部分は、後になるほど大きなコストとなって返ってきました。
また、別の役割の視点から考える機会も得られました。単に依頼を送り、結果を受け取る立場ではなく、どのような情報が必要で、どの部分で困難が発生するのかを少しながら理解できるようになりました。そのおかげで、協業の過程で何をさらに準備すべきかについても、多くを学ぶことができました。
今回の振り返りは、成果物の記録というより、過程の記録に近いものです。何を作ったのかも重要ですが、それが作られる過程を一度最後まで経験できたことのほうが、より大きな収穫でした。次は今回見つかった不足している部分を少しずつ補いながら、より良い一つのサイクルを作っていきたいと思います。
jun