見出し画像

小さいチームでシステム開発する時の「どうなってほしいか」リストのススメ

こんにちは。TAM UX/UIチーム エンジニアの佐賀です。
主にWebアプリケーションの要件定義、設計、実装などを担当しております。

UX/UIチームに入る前はSIerでのパッケージシステム導入や、医療系基幹システムの開発に携わっていました。自分のまわりもほぼ全員が「エンジニア」と呼ばれる職種の人間で、作業は良くも悪くもルーティン化されており、どのフェーズでどこまでやる、というのが何となく共通認識として存在している現場で過ごしてきました。

UX/UIチームでは異なる職種間&クライアントも含め開発や制作を進めていきます。職種や業界をまたいで意思疎通をする、というのがチームに入りたての私にとっては難しく、自分の中では「こうかな?」と考えていても「勘違いだった!」と反省することもありました。(今でも多々あります。)
また、少人数でプロジェクトを進行する場合、一人ひとりが越境して取り組む場面も多くあります。説明するためだけの資料を作り込む時間が惜しい…とも感じました。

そんな職種を超えて濃い&迅速なコミュニケーションを必要とする現場では「どうなってほしいか」を関係者の中でリスト化することをおすすめいたします。

画面遷移図だけで動作の認識を合わせることは難しい?

UX/UIチームでよく目にする画面遷移図。うまく作成すればとっても便利でわかりやすい資料です。設計中に仕上がってくると「おおっ!」とテンションも上がります。ただ、画面遷移図は全体像が把握しやすい一方、詳細な仕様の記載は省かれています。シンプルなWebサイトであれば、画面遷移図だけでも十分かも知れません。パーツの出し分けや、フロントエンドでの複雑な処理、入力欄のバリデーションがあるなどの場合は、主に担当エンジニアが詳細設計書などの別資料にまとめます。


エンジニア向け設計書はUX/UIデザイナー、顧客にとって難しい?

詳細設計書はエンジニアにとって重要な資料ですが、それ以外の関係者からは敬遠されがちです。目を通してくれる人もいますが、詳細設計書を見て認識のズレや誤りを指摘することはハードルが高く、問題をスルーしてしまう可能性が大きくなります。

アカウント詳細

詳細設計書のイメージ(一部)。各画面、機能ごとに分けて記載される。データベースの値などが記載されている。

詳細設計書

シーケンス図などが登場する場合も。全員で理解を深めるにはコストがかかってしまう。
クライアントに対する説明用に資料を作成する、という手もあるといえばあります。が、必要以上に資料が増えすぎる、仕様が変わるたび資料の更新が発生するなどの手間も発生します。個人的にはあまりおすすめしません。

作ってみよう「どうなってほしいか」リスト

画面遷移図や機能一覧などを作り込む作業と並行して進めましょう。特別なツールやフォーマットは必要ありません。

「どうなってほしいか」リスト(例)

どうなってほしいかリスト

Dropbox Paperに箇条書きにしてみただけ。PJ管理システムのwikiなどに記載するもよし。実装目線でなく、使う側からみてどうなっていたらいいのかが分かるような書き方だと全員が理解しやすい。

クライアント・ディレクター・デザイナー・エンジニア、関係者全員が参照できる場所に置く
「どうだったっけ?」と思ったとき、関係者から参照できる場所に置きましょう。プロジェクト管理ツールのwikiや、オンラインドキュメントなどを活用しましょう。

「どうなってほしいか」は具体的に
あまりにふわっとした内容でリストを作成すると開発フェーズに入ってから「あれ?」と再確認になってしまうこともあります。以下に例を挙げます。

(例1)「戻る」ボタンはどこに戻るのか
「戻る」というボタン、さまざまなWebサイトで見かけることが多いので上流工程では流してしまいがちですが、どこに戻るのか確認しておきましょう。ブラウザバック、トップページ、何らかの一覧ページなど、戻り先が無数に考えられてしまう場合もあります。
※画面遷移図で表現できる場合はリスト化しなくてもOKです

(例2)名前を表示したい。さて、名前とは
会員サイトなどでは名前が表示されるページも多くあります。「名前を表示」と言っても、名字のみ、氏名、名字と名前の間にスペース、氏名とは別のニックネーム、敬称をつける?など、無数にパターンが考えられてしまいます。

要件の変更 or 実装時に不都合があった場合は速やかに共有し、リストを見直そう
要件の変更は常にあるものですし、実装時に初めて気がつく不都合などもあるかも知れません。その場合、関係者に相談の上すみやかに共有し、リストを更新しましょう。

まとめ

「どうなってほしいか」リストは一画面だけ、この機能だけ、といった感じで部分的に始められますし、特別なツールもいりません。設計〜開発時のモヤモヤ解消につながれば幸いです。

画像4

佐賀 奈穂子 / Naoko Saga
エンジニア
2017年より在籍。開発案件を中心に上流からバックエンド実装までを担当。
UX/UIチーム内のテクニカル的相談にのったりもしています。

この記事が気に入ったらサポートをしてみませんか?