「気づき」が成功を分ける！「使いやすい」を実現するアプリケーション開発 要件定義から実装まで、事例とチームマネジメント

Webサイトや業務システムの使いやすさは、UIデザインの段階だけで決まるものではありません。ユーザーが手にする「体験」の実体は、実装されたフロントエンドの挙動として提供されるものだからです。

静止画のUIデザインでは問題がないように見えても、ボタン押下後のフィードバック、待ち時間など実装品質の積み重ねが、最終的な「使いやすさ」を大きく左右します。

本セミナーでは、「使いやすさ」の本質を定義し、なぜ意図しない「使いにくさ」が生まれてしまうのか、その原因を要件定義からデザイン、開発、テストまでの各フェーズに沿って解説します。
あわせて、「使いやすいプロダクト」を継続的に生み出すためのチームマネジメントの仕組み作りやコミュニケーションのあり方についても紹介します。

「使いやすさ」を個人の感覚や経験に委ねるのではなく、チーム共通の判断軸とするための考え方を持ち帰っていただける内容です。ぜひお気軽にご参加ください。

主な内容
・ユーザーにとっての「使いやすさ」とは何かを知る
・「使いにくさ」が生じた事例・解決方法
・「使いやすい」プロダクトを作るためのチームマネジメントのポイント

こんな方におすすめ
・UIデザインにはこだわっているものの、実際の利用シーンで使いづらさが残っていると感じている方
・要件定義から実装までのどこで使いやすさが損なわれているのかを、プロダクトマネージャーの視点で整理したい方
・フロント実装によって、想定していた利用体験とズレが生じる理由を理解したい方
・「使いやすさ」を一時的な改善で終わらせず、継続的に高めるチームの進め方を知りたい方

Transcript

1. 「気づき」が成功を分ける！ 「使いやすい」を実現する アプリケーション開発 要件定義から実装まで、事例とチームマネジメント 2026/ 03 / 07 NCDC株式会社
2. 講師紹介 2 フロントエンドをメインに、フルスタックエンジニアとして設計・ 開発業務を担当。また、デザイナーとしてUX/UIデザインを手 掛ける。PMやリードエンジニアとしてのチームマネジメントの 経験も有する。 エンジニアとしてキャリアをスタートさせ、ITコンサルティング・ 学術業界などを経て、NCDCに入社。入社後は鉄道・建設業 界などに携わっている。 エンジニア / UXデザイナー 木村 優里
3. NCDCのご紹介
4. Business 新規事業立ち上げからの伴走 業務改革やIT改革の支援 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation Consultant デザイナーやエンジニアと協力して、新 規サービス立案の支援や新規性の高い システムの要件定義を行う。プロジェクト 全体のマネジメント役も担う。 UX/UI designer UIデザインはもちろん、デザイン 思考やUXデザインのフレーム ワークを用いて上流工程（サー ビス全体のUX設計）を担う。 Engineer モバイルやWeb、クラウド、IoTや AIなど、新しい領域の技術に特 化。つくるだけでなく技術コンサ ルティングができる知見を持つ 者も多数在籍。 ⚫ AWS サービスパートナー ⚫ AWS Lambdaパートナー ⚫ 内製化支援推進AWSパートナー NCDCの事業領域 ⚫ 3領域でサービスを展開 ⚫ 各領域のスペシャリスト を社内に揃える体制 4
5. デジタルビジネス立ち上げを一元的にサポート ⚫ デジタルビジネスに必要な企画から開発まで、一元的に提供しています。 ⚫ スモールスタートでの検証から、本開発・継続的な改善までサポートします。 5 ワークショップを中心とし た合理的なプロセスで、ビ ジネスモデルの検討からUX デザインまで、迅速に行い ます。 関係者が多数いる場合の組 織横断、会社横断のファシ リテーションも得意です。 新規性の高いプロジェクト ではMVP（Minimum Viable Product）を用いた検証を行 うなど、目的に応じて段階 的な開発を企画します。 早い段階でモックやプロト タイプを用意してユーザの 評価を確認します。 ユーザとのタッチポイントとなる各種デバ イスのフロントエンドデザインから、クラ ウドサービスを駆使したバックエンドの開 発まで。多様なテクノロジーをインテグ レーションします。 ⚫ AI / IoT ⚫ モバイル・ウェブ アプリ開発 ⚫ クラウドインテグレーション ⚫ システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を大切にした アイデア・企画 モックやプロトタイプ の開発・検証 システム・アプリ開発 継続的な改善
6. 本セミナーのテーマ 「気づき」が成功を分ける！ 「使いやすい」を実現するアプリケーション開発 要件定義から実装まで、事例とチームマネジメント 6
7. 本セミナーで得られること ⚫ 本セミナーでは以下の知識を得ることができます 7 「使いやすさ」 とは 何なのか 「使いにくさ」 の事例・ 解決方法 「使いやすい」 プロダクトを 作るチーム マネジメント
8. 用語の定義 ⚫ 本セミナーでは各用語を次のとおりの意味で用いる 8 用語 意味 プロダクト ユーザーへ提供されるITサービス全般。 一般的には「システム」「アプリ」とも呼ばれる。 PM プロジェクトマネージャー。 全体管理・要件定義・テストを担当。 デザイナー UI/Webデザイナー。 UIデザインを担当。 エンジニア システムエンジニア、プログラマー。 設計・実装・テストを担当。
9. 「使いやすさ」とは何なのか
10. 本セミナーで得られること ⚫ このセクションでは以下を扱います 10 「使いやすさ」 とは 何なのか 「使いにくさ」 の事例・ 解決方法 「使いやすい」 プロダクトを 作るチーム マネジメント
11. 「使いやすさ」とは何か？ ⚫ 本セミナーにおける定義は以下の通りとする 11 使いやすさ ユーザーがストレスなく、プロダクト上で目的を達成できること 使いにくさ 「使いやすさ」が満たされていないこと
12. 「使いやすさ」が阻害される要因 ⚫ ユーザーの持つ前提と、プロダクトで実現されていることが異なると、 「使いやすさ」が阻害される＝「使いにくい」状態となる ⚫ タスク自体が複雑でストレスを感じる場合もある 12 いつも使っているプロダクトと 同じような動きをするだろうな あれ？思ったのと違う！ 使いにくい！
13. 「使いやすさ」が重要視される理由 ⚫ なぜ「使いやすさ」は重要なのか？ 13 操作が効率化でき、 作業時間が短縮される 1 プロダクトに良い印象を 持ちやすくなる 2
14. 「使いにくさ」はなぜ生まれるのか？ ⚫ 通常プロダクトチームは「使いにくさ」を意図的に設計していない ⚫ あえて使いにくくする場合や、使いにくさを許容する場合を除く ⚫ 解約処理などの回避させたい操作 ⚫ 仕様調整時に運用でカバーすると決まった箇所 14 この画面なら 使いやすいだろう ここはあえて 使いにくくしよう
15. 「使いにくさ」はなぜ生まれるのか？ ⚫ 「使いにくさ」とは、プロダクトチームが気付かなかった箇所で起こる ⚫ ユーザーとの前提の相違による仕様面の問題と、 動作環境が異なり想定外の挙動になっている問題がある ⚫ メンバーは気付いていたが、チーム共有されなかった場合を含む ⚫ 「使いにくさ」を減らすには次の2点が重要となる 15 気付くこと 気付きを プロダクトに 反映すること
16. いつ気付けるのか？ ⚫ プロダクトは、複数の工程に沿って構築される ⚫ 極端にいえば、全てを想定できていれば全てその段階で気付ける ⚫ ただし、全てを想定することは困難と考えたほうが現実的 16 設計 (UIデザイン) 開発 テスト 要件定義 リリース後のフィードバック 「使いやすさ」に ついて特に議論される
17. なぜ事前に気付くことが困難なのか？ ⚫ 各工程では期間と成果物が定められている ⚫ 期間内に成果物を完成させることが第一の目的となる ⚫ 前提となる方針・仕様が未決定のため、決めきれない要素がある ⚫ クリティカルな影響を持つ時期まで、前提の決定が延期されることがある ⚫ チームやメンバーの経験・習熟度により、気付けない観点がある ⚫ PM・デザイナー・エンジニアの各職種においていえる ⚫ 前工程の決定が変更不可である場合、気付いても反映ができない ⚫ またはメンバーが変更不可だと思っている ⚫ 決定に基づいて作業し、気付いても報告されない 17
18. 「使いやすさ」のまとめ 18 「使いやすさ」とは、 ユーザーがストレスなく、 プロダクト上で目的を達成できること 1 ユーザーの前提とプロダクトの挙動が異なると、 「使いやすさ」が阻害され、使いにくくなる 2 「使いにくさ」とは事前に気付かなかった箇所で 起こる場合が多いため、「気付く」ことが重要 3
19. 「使いにくさ」の事例・解決方法
20. 本セミナーで得られること ⚫ このセクションでは以下を扱います 20 「使いやすさ」 とは 何なのか 「使いにくさ」 の事例・ 解決方法 「使いやすい」 プロダクトを 作るチーム マネジメント
21. 「使いにくさ」の事例紹介 ⚫ 架空のプロジェクト管理プロダクト「PRO-KEEPER（プロキーパー）」をもと に、ユーザーが使いにくさを感じたエピソードを紹介 ⚫ プロダクト開発における各工程でどのような改善が可能かを分析する 21 ※ 架空のプロダクトです
22. 事例紹介のユーザー ⚫ 架空のユーザー「小林さん」の視点でエピソードを紹介する 22 名前 小林由依 年齢 28歳 職種 総務（働き方改革 担当者） 業種 老舗メーカー 社歴 1ヶ月（転職） 課題感 早く環境に慣れたい ITスキル 業務ではOffice製品などを使用。 プライベートではiPhoneで各種ア プリを使っている。 IT用語やシステムの仕組みには 疎い。
23. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い ⚫ 小林さんは社内の働き方改革担当者として入社し、まずは社内の実情 を確認する必要があった ⚫ 小林さんはプロジェクト管理プロダクト「PRO-KEEPER」のアカウントを作 成してもらった ⚫ ログイン後、プロジェクト一覧画面を開いた 23
24. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い ⚫ 小林さんはいくつかの条件を入れて、検索ボタンをクリックした ⚫ しかし、画面上は何も変わらない ⚫ クリックできていなかったと思って、再度クリックしたが、それでも画面は 変わらなかった 24
25. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い ⚫ クリックから1分近くが経過し同僚に聞こうかと思ったとき、検索結果が表 示された ⚫ クリック後すぐに結果が表示されると思っていた小林さんは、利用早々 「PRO-KEEPER」を使いにくいと思った 25
26. 検索ボタンを非活性・ローディング中にする 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 26 検索ボタンクリック後、画面上のフィードバックがない 1 検索ボタンクリック後、検索結果表示までの時間が長い 2 検索結果表示までの時間を短くする
27. 工程ごとの要因 ⚫ ここでは工程ごとの要因をよくある一例から考えていく ⚫ 実際になぜ「使いにくい」状態になったかは、プロダクト開発の事情によって 異なる ⚫ リリースまでのどこかで気付いて修正することができれば、その「使いに くさ」はユーザーまでは届かない 27 設計 (UIデザイン) 開発 テスト 要件定義 リリース後のフィードバック ユーザーの声がプロダクトチーム まで届かないことも 使いにくさ 発生！
28. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 28 検索ボタンクリック後、画面上のフィードバックがない 1 要件定義 設計（UIデザイン） 開発 テスト 検索ボタンクリック後の状態変化を 未定義 仕様どおり実装する 機能要件が満たされているか確認 する NG
29. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 29 検索ボタンクリック後、画面上のフィードバックがない 1 検索ボタンクリック後、ローディング 状態・非活性に状態変化とする 仕様どおり実装する 機能要件が満たされているか確認 する OK 要件定義 設計（UIデザイン） 開発 テスト
30. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 30 検索ボタンクリック後、画面上のフィードバックがない 1 検索ボタンクリック後の状態変化を 未定義 検索ボタンの連続クリックによる サーバ負荷増加回避のため、 検索ボタンクリック後に非活性化 機能要件が満たされているか確認 する NG OK 要件定義 設計（UIデザイン） 開発 テスト
31. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 31 検索ボタンクリック後、画面上のフィードバックがない 1 機能要件確認に加えて、 テスト中に気付いた点を修正 要件定義 設計（UIデザイン） 開発 テスト 検索ボタンクリック後の状態変化を 未定義 仕様どおり実装する NG OK
32. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 32 検索結果表示までの時間が長い 2 適切な非機能要件を定義する 想定運用年数・想定事業規模などからデータ総量を算出し、 適切な応答時間を定義して検証を行う。 検索条件やデータ総量を減少させる 検索条件やデータ総量が多い場合、検索負荷が高くなる。 このため、あらかじめ少なく、蓄積しないように設計する。
33. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 33 検索結果表示までの時間が長い 2 適切な非機能要件を定義する 想定運用年数・想定事業規模などからデータ総量を算出し、 適切な応答時間を定義して検証を行う。 検索条件やデータ総量を減少させる 検索条件やデータ総量が多い場合、検索負荷が高くなる。 このため、あらかじめ少なく、蓄積しないように設計する。 プロダクトの拡張により、 増えざるを得ない場合が多い
34. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 34 検索結果表示までの時間が長い 2 要件に沿って設計・UIデザインする 仕様どおり実装する 定義された非機能要件を確認する 非機能要件として応答時間・ 想定データ量が未定義 要件定義 設計（UIデザイン） 開発 テスト NG
35. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 35 検索結果表示までの時間が長い 2 要件に沿って設計・UIデザインする 仕様どおり実装する 定義された非機能要件を確認する 非機能要件として応答時間・ 想定データ量を定義 要件定義 設計（UIデザイン） 開発 テスト OK
36. 【事例1】 検索ボタンクリック後のフィードバックがない・遅い 36 検索結果表示までの時間が長い 2 要件に沿って設計・UIデザインする 仕様どおり実装する 非機能要件として応答時間が 未定義 要件定義 設計（UIデザイン） 開発 テスト 未決定の非機能要件を定義する OK
37. 【事例2】 特定のディスプレイサイズでデザインが崩れる ⚫ 小林さんはプロジェクト一覧で行をクリックし、プロジェクト詳細画面を開 いた ⚫ 小林さんはディスプレイをPCに接続した ⚫ すると画面のデザインが間延びしていることに気付いた 37 項目同士の余白が空きすぎている 入力値に対して項目が広すぎる
38. 【事例2】 特定のディスプレイサイズでデザインが崩れる ⚫ 小林さんは社用スマホで「PRO-KEEPER」にアクセスできることを確認し た ⚫ スマホで横向き表示にしたとき、画面のデザインが崩れていることに気 付いた 38 重なりやズレが生じている はみ出している
39. レスポンシブデザインの対応サイズを増やす 【事例2】 特定のディスプレイサイズでデザインが崩れる 39 特定のディスプレイサイズでデザインが崩れる タブレット対応前 タブレット対応後
40. 【事例2】 特定のディスプレイサイズでデザインが崩れる 40 特定のディスプレイサイズでデザインが崩れる 特定画面サイズ用のUIをデザ インする 仕様どおり実装する 単一対象デバイス・ ディスプレイサイズで要件を確認する 閲覧対象OS・ブラウザ・ ディスプレイサイズが未定義 要件定義 設計（UIデザイン） 開発 テスト NG NG NG
41. 【事例2】 特定のディスプレイサイズでデザインが崩れる 41 特定のディスプレイサイズでデザインが崩れる 仕様どおり実装する 要件定義 設計（UIデザイン） 開発 テスト 閲覧対象OS・ブラウザ・ ディスプレイサイズを定義 OK 定義サイズ内で崩れない UIパターンをデザインする OK 定義されたOS・ブラウザ・ ディスプレイサイズで表示検証する OK
42. 【事例3】 同タブ内で遷移後、戻ると入力項目が消えている ⚫ 小林さんは試しにプロジェクトを登録してみることにした ⚫ 入力を進めていくと「セキュリティ区分」という項目があり、 小林さんは何を選べばいいか分からなかった ⚫ 「詳しくはこちら」をクリックすると、ブラウザの同じタブで説明用画面に遷移した ⚫ 内容を確認してブラウザの戻るボタンをクリックすると、 既に入力済みだった項目が全て消えていた 42 同じタブで遷移 戻ると入力が消えている クリック ① ③ ② ④ 戻るボタンをクリック
43. 同じタブで遷移しても入力情報を保持させる 【事例3】 同タブ内で遷移後、戻ると入力項目が消えている 43 同タブ内で遷移後、戻ると入力項目が消えている 別タブで表示させる 同一画面内で情報表示する
44. 【事例3】 同タブ内で遷移後、戻ると入力項目が消えている 44 同タブ内で遷移後、戻ると入力項目が消えている 要件定義 設計（UIデザイン） 開発 テスト 項目の説明が同画面内で参照 できないUIをデザインする 仕様どおり実装する 機能要件が満たされているか確認 する NG 同一画面内で情報表示する
45. 【事例3】 同タブ内で遷移後、戻ると入力項目が消えている 45 項目の説明が同画面内で参照 できるUIをデザインする 仕様どおり実装する 機能要件が満たされているか確認 する OK 要件定義 設計（UIデザイン） 開発 テスト 同タブ内で遷移後、戻ると入力項目が消えている 同一画面内で情報表示する
46. 【事例3】 同タブ内で遷移後、戻ると入力項目が消えている 46 同タブ内で遷移後、戻ると入力項目が消えている 要件定義 設計（UIデザイン） 開発 テスト 項目の説明リンクのタブ遷移方法 が未定義 仕様どおり実装する 機能要件が満たされているか確認 する NG 別タブで表示させる
47. 【事例3】 同タブ内で遷移後、戻ると入力項目が消えている 47 項目の説明リンクのタブ遷移方法 を別タブと定義 仕様どおり実装する 機能要件が満たされているか確認 する OK 要件定義 設計（UIデザイン） 開発 テスト 同タブ内で遷移後、戻ると入力項目が消えている 別タブで表示させる ドメインが異なる場合は別タブ
48. 【事例3】 同タブ内で遷移後、戻ると入力項目が消えている 48 項目の説明リンクのタブ遷移方法 が未定義 別タブ遷移時のセキュリティ制御 設定を考慮するため、 遷移方法を別タブとして実装 機能要件が満たされているか確認 する NG OK 要件定義 設計（UIデザイン） 開発 テスト 同タブ内で遷移後、戻ると入力項目が消えている 別タブで表示させる <a href=“http://example.com/” target=“_blank” rel=“noopener noreferrer”> ※ noopenerのセキュリティリスクはブラウザ側で対応されているため、 本セミナーの説明からは省略します
49. 【事例3】 同タブ内で遷移後、戻ると入力項目が消えている 49 項目の説明リンクのタブ遷移方法 が未定義 同一サイト内のため、 遷移方法を同タブとして実装 入力項目は内部保持する 機能要件が満たされているか確認 する NG OK 要件定義 設計（UIデザイン） 開発 テスト 同タブ内で遷移後、戻ると入力項目が消えている 同じタブで遷移しても入力情報を保持させる
50. 【事例3】 同タブ内で遷移後、戻ると入力項目が消えている 50 機能要件確認に加えて、 テスト中に気付いた点を修正 要件定義 設計（UIデザイン） 開発 テスト 項目の説明リンクのタブ遷移方法 が未定義 仕様どおり実装する NG OK 同タブ内で遷移後、戻ると入力項目が消えている
51. 「使いやすいプロダクト」を実現するチームマネジメントとは
52. 本セミナーで得られること ⚫ このセクションでは以下を扱います 52 「使いやすさ」 とは 何なのか 「使いにくさ」 の事例・ 解決方法 「使いやすい」 プロダクトを 作るチーム マネジメント
53. 事例で分かった傾向 53 上流工程で「使いやすさ」が考慮されていると 問題が表面化する可能性が下がる 1 工程内で気付きを反映することができれば ユーザーに届く前に「使いにくさ」を修正できる 2 下流工程にならないと気付くことが難しい 「使いにくさ」がある 3
54. チームマネジメントのポイント 54 上流工程で「使いやすさ」が考慮されていると 問題が表面化する可能性が下がる 1 技術的な実現可能性を早期から検討する 上流工程からエンジニアをアサインする プロダクト開発全体における気付きの重要性を合わせる キックオフ時に「使いやすさ」への意識を合わせる デザイン時の想定パターンを増やし、後続影響を減らす デザイン工数の見積もりに余裕を持たせる
55. チームマネジメントのポイント 55 工程内で気付きを反映することができれば ユーザーに届く前に「使いにくさ」を修正できる 2 実装・テストにおける気付きをデザイン観点で適用する 下流工程にもデザイナーをアサインする デザイナーのみでなく、PM・エンジニアも「使いやすさ」を考慮 「使いやすさ」はチームで考えることを意識付けする 気づきがあったとき、それを伝えやすい状態とする 自分の意見を言いやすい雰囲気を作る
56. チームマネジメントのポイント 56 下流工程にならないと気付くことが難しい 「使いにくさ」がある 3 処理速度・実機表示・ブラウザ挙動など 下流でないと気付きにくい観点を蓄積していく Chrome開発者ツールのLighthouseなど 実装後に客観的な指標を利用する スケジュールを考慮し、優先順位をつけて対応する 下流工程の気付きは、不具合とは別に改善点として扱う