大規模システム開発プロジェクトにおけるux - ipa · 2019-04-01 ·...

大規模システム開発プロジェクトにおけるUX品質設計プロセスの適用とその効果～既存のUX/HCD手法では対処できない大規模プロジェクト現場特有の課題とその実践的解決法の事例～

SEC高信頼化技術適用事例セミナー

2016年 8月 24日

NECソリューションイノベータ株式会社

イノベーション戦略本部

森口昌和

3 © NEC Corporation 2015

自己紹介

森口昌和（NECソリューションイノベータ株式会社）

スマートデバイスやRIA、最近ではVR/ARなどの最新技術を中心に、製造・流通・医療・金融・社会インフラなど、NECが携わる様々な分野で、UXエキスパートとして現場開発支援＆価値創出支援を担当

主な業務

UX設計支援／HCDプロセス適用支援／UXコンサル

最先端技術を用いた新価値創造および新事業創出

関連資格

人間中心設計推進機構認定人間中心設計専門家

著書

「スマートデバイスのUXデザイン～事例から学ぶ失敗しないアプリ設計術～」、日経BP社、2013/12


本日の概要

多数の手戻り

あいまいな要件定義

顧客からのクレーム

そこで…

UX（ユーザーエクスペリエンス）に注目した独自手法を導入

プロジェクトの画面・機能上の問題を、約 40％抑えることに成功

結果として

※過去のプロジェクトから推定された予測値

1. UX代表画面・機能を予め決める、顧客体験型設計法

2. 直感理解型UI標準を用いた、UX共有手法

UX/HCD手法のBtoB－SI現場実践例の紹介

大規模プロジェクトだからこその苦労話


目次

背景「大規模」なプロジェクトとは

問題プロジェクトで発生する問題の定義

今回注目したプロジェクトの問題

アプローチ既存のUX手法

現場課題を解決したアプローチ

解決方法１．顧客体験型設計法

２．直感理解型UI標準

提案手法の独自ポイント

適用結果・評価

発展成果を方法論化

まとめ

UX問題が発生

開発現場上の問題が発生

既存のUX手法を適用

独自のUX設計プロセス適用

問題を抑制

解決フロー


「大規模」なプロジェクトとは

NECグループだけでなく、それ以外の企業も参画

開発にはオフショアとして、中国を利用

プロセスとしては、一般的なウォーターフォール型のシステム開発工程で実施

対象： 2年以上継続する開発者数100人超えのプロジェクト

今回改善対象としたのは、以下の2つの大規模プロジェクト

1 2

企画／提案要件定義外部設計内部設計製造テスト

※上図は一般的な開発工程を概略した図であり、実際のプロセスとは多少異なります。

生産管理システム

製造業務系

需要予測・引き合い・受注などの生産計画をはじめとし、調達・製造から在庫・出荷までの工程をシステム化。ERPパッケージをベースとし、柔軟で俊敏な業務を実現。

営業管理システム

基幹業務系

商品情報について、企画・編成・セールス・契約をはじめとして、売上・請求・確認まで一括してシステム化。既存パッケージをベースとし、顧客の営業に最適化。

利用者：数千人規模画面数：100超え


プロジェクトで発生する問題の定義

今回は問題を、UX問題、UI問題、バグの３つに定義

UX問題

UI問題

バグ

「ヒト」の属性で発生する、遅延や手戻りなどのプロジェクト問題

主観的な要素が統一されていない状況で発生しやすい

感情、性格、経験の違い、組織風土などが原因

「モノ」の属性で発生する、遅延や手戻りなどのプロジェクト問題

客観的な要素が統一されていない状況で発生しやすい

動作、内容、見た目、ユーザビリティなどが原因

そもそもシステムが動作しないという根本的な問題

テスト量が少ないと発生しやすい

※色んな見方があるが、今回は下記で定義する


今回注目した問題

2. 情報共有の不確かさ! 意見や解釈がバラバラ

! 人によって理解度が異なる

これまで取り組んできた20個のプロジェクトを分析した結果、大きな手戻りにつながる問題点として、以下の2つのUX問題が主立っていた。

1. 顧客ニーズの理解・抽出不足! 機能重視で求める体験が把握できていない

! 顧客の潜在的なニーズが明確になっていない

20プロジェクト619件の問題点を調査

軽微な問題

UX問題 UI問題バグUX問題のほうが、UI問題よりも重大な事故につながる問題の割合が大きい。

2つのUX問題

239件

38件

342件重大な問題


既存のUX手法の適用を検討

企画／提案要件定義外部設計内部設計製造テスト

• カスタマージャーニーマップ、UXマップ

• 構造化シナリオ法

• ヒアリング、フィールドワーク

• ペルソナ

• ストーリーボード、KA法

• 上位下位分析

• アクティングアウト、プロトタイピング

• モックアップ

• ユーザーテスト

• ブループリント

開発プロセスに適用できる、主なUX手法

新たに、既存のUX手法の開発現場適用上の課題が発生! お客様側に、わざわざ時間を割いてもらえない。

! システム上だけでなく、その企業の文化・風土上の制約がある。

! お客様もわれわれも、工数や期間が限られている。

※他にも多数の手法があり、弊社で適用できた一部のみ挙げています。

既存のUX手法を適用すると、UX問題が削減されると仮定したが…


既存のUX手法の適用が難しい例

エンドユーザーの行動や心理を、システムを利用する時系列順に可視化し、システム全体のUXを俯瞰する手法

! 作成に時間がかかる。

! 専門的で、お客様から理解を得るのが難しい。

! レビュー時間をもらうのが難しい。

• カスタマージャーニーマップ

1)バリューシナリオ、2)アクティビティシナリオ、3)インタラクションシナリオ、という3段階のブレイクダウンシナリオを用いて、個々の画面・機能のUXを明確にする手法

• 構造化シナリオ法

! 作成や適用に時間がかかる。

! 開発プロセスのドキュメントにはなく、社内外に受け止められにくい。

モデルユーザーが、特定の目的を達成するための効果を、一連のストーリーとして絵コンテ化するなどし、UXを共感しやすくまとめる手法

• ストーリーボード

（例）


現場のUX問題を解決するためのアプローチ

そこで、独自のUX設計プロセスを、2つ適用

○ 画面・機能を、検索・一覧・詳細といった一般分類でなく、ユースケース・作業者・行動といった“体験”で分類。

○ 画面内は、ユーザーのITリテラシーに合わせ、わかりやすさ使いやすさを統一。

○ 多数のステークホルダがいて、多数の機能が必要なときは、上記体験に沿って機能をグルーピング。

○ 開発者が持つ機能目線を、上記体験目線になるように、UI標準ドキュメントを整備。

○ 優先度や重要度などのUXを直感的に理解できるようドキュメントのレイアウトで工夫。

☆ コンシューマでなく、業務向けであるため、行動の一定の偏りに注目

☆ 代表画面を決めることで、少ない時間で顧客ニーズを把握可能

1. UX代表画面・機能を予め決める、顧客体験型設計法


☆ 情報共有の確実性を高めることで、工数や期間が限られている中での、製造における手戻りをできるかぎり短縮

顧客ニーズ

情報共有


１．UX代表画面・機能を予め決める、顧客体験型設計法（１／４）

○ “機能”ではなく、ユーザーの“体験”を重視

○ 同じ「一覧画面」であっても、その画面に期待する「ユースケース・作業者・行動」によって、代表画面を分類

例えば、100行の製品情報一覧画面において、1行の不良製品を見つける作業と、100行の工程推移を俯瞰するのでは、求めている“体験”が異なる。

☆ “体験”を重視して、画面・機能を分類することで、「思っていた機能と違う」という顧客ニーズとのブレを削減

※生産管理システムの「代表画面設定表」より

“体験”が類似している画面を整理したファイルの一部。この図では、検索・一覧・詳細といった機能ベースではなく、ユースケースや担当ベースで分類。


１．UX代表画面・機能を予め決める、顧客体験型設計法（２／４）

! あるプロジェクトでは当初、「製品情報を一覧する画面：１画面」という要求しかなかったが、実際には、後から別の画面が追加され、その分の手戻りが発生してしまっていた。

○ 今回は事前にUXを分析およびヒアリングし、一覧画面には2つの体験が必要であることを事前に検出。それぞれ別の画面を予め見積もることで、手戻りが発生することはなかった。

△ ただし、体験は画一的ではないため、いくら分析やヒアリングをしても、本当にお客様に適した集約は難しい。今回は、集約するために、お客様先に常駐し、業務内容や困っていることを常に把握して対応。ここをより効率化するのは今後の課題。

製品情報一覧画面において、工程上の不良製品を見つける作業では、

個々の数値を重視する。

同じく製品情報一覧画面であっても、工程上の作業推移を俯瞰する作業で

は、数値ではなくグラフを重視する。

（例）「製品情報：一覧画面」の体験比較


１．UX代表画面・機能を予め決める、顧客体験型設計法（３／４）

機能はあっても、ユーザーはどこをどうしたらいいかわからない。

ユーザーのITリテラシーに沿ったインタラクションを設計し、ユーザーの“体験”を統一。

○ 登録できる箇所をわかりやすく。○ ボタンを押すとどうなるかを一意でわかりやすく。○ 画面におけるメインの作業をわかりやすく。


１．UX代表画面・機能を予め決める、顧客体験型設計法（４／４）

! これまでのプロジェクトの画面設計において、ステークホルダが多くなると、画面内にできるだけ多くの機能を入れようとする方針になることが多かった。ただし、その設計は一部のユーザーのみに利点があるもので、メインユーザーは、自分の必要とする情報しか必要としない（左図参照）。

○ 今回、多くの機能があることは維持しつつ、機能を“体験”に合わせてグルーピングすることで、ユーザーが迷わない設計を実現。

※パレートの法則

この例の場合、管理者と実作業者、メインユーザーが2人いるため、それぞれが良く使う検索機能で、2つの検索エリアにグループ分けをした。

※画面のヘッダ


２．直感理解型UI標準を用いた、UX共有手法（１／３）

例１ポップアップメッセージで、「Error: 1011」

開発者「エラー出してるし、エラーコードも載せているから問題ない」

ユーザー「何が起きたか、何のエラーかわからない…」

→ 体験に合わせると、「品目番号の書式が間違っています。」がわかりやすい。

ただそれが開発者側には受け止めにくい。

開発者側の主な問題は、機能目線

例２用語の違い：「品目番号」「品目ID」「ナンバー」「製品コード」…

開発者「全部同じ。設計書に書いている」

ユーザー「何を示しているの？マニュアルにも書いていない…」

→ 体験に合わせると、すべてを統一すべきである。また、一意にわかる用語にするべきである。

ただそれが開発者側には受け止めにくい。


２．直感理解型UI標準を用いた、UX共有手法（２／３）

開発者側の理解に向けた課題! 作業者の入れ替わりが頻繁 ← 教育しても去っていく

! 顧客要件の理解不足 ← 開発で精いっぱい

! 個々の作業が忙しく、情報共有に乏しい ← 時間がない

! 作業者ごとに技術力が異なる ← 浸透しない

従来の手法お客様の要求やヒアリング結果を説明し、理解させる。

何が重要か説明する。

ユーザーエクスペリエンスやユーザビリティの重要さを教育する。

マネージャーと要件を随時共有する。

従来の説明や教育では、大規模プロジェクトに適さない


２．直感理解型UI標準を用いた、UX共有手法（３／３）

イメージで直感的に意思共有できる、直感理解型UI標準を提案

直感理解型UI標準のメリット○ 教育しても去っていく → 要求の優先度が一目でわかるようにレイアウトを工夫

○ 開発で精いっぱい → 開発するUIごとに設定

○ 時間がない → 短時間で理解できるよう直感理解を考慮

○ 浸透しない → 一つのドキュメントで管理・指示できるよう作成

※一部表現や体裁を変えています。

オートコンプリート機能ユーザが文字を入力するたびに、推測される単語を一覧表示し、ユーザに選択させる。一覧は、部分一致で検索された結果を画面に収まる範囲で表示するようにする。

20件程度が妥当。パフォーマンスによっては表示数を変更してもよい。ユーザの入力に応じて、リアルタイムに一覧が更新される。

入力したテキストが、完全一致で１つしかリストに存在しないときに矢印をクリックした場合、テキストを何も入力していない状態のリストを表示する。

オートコンプリートは、パフォーマンス対応のため、製品名称や顧客名称など、適用する要素が予め決められている。

（例）UI標準－入力部－オートコンプリートUIごとに、要件を整理。優先度や重要度といったUXも一目でわかるよう色やサイズを設定。ヒアリング結果も随時追加し、１つのマスタードキュメントとして管理。

イメージをそのまま開発しても、基本的な体験は実現できるよう考慮。


適用結果（１／３）スケジュールで観る問題の抑制効果

画面・機能だけでなく、他の設計・開発の問題抑制にも影響

３月４月５月６月７月

システム開発

基盤開発構成・方式設計

運用設計

導入設計

分析サービス設計

業務機能設計

画面ＵＩ設計詳細設計

実装方式設計実装標準

プロトタイプ開発設計標準策定

※一部表現や内容を変えています。

画面UI設計が予定通り進捗しただけでなく、業務機能設計、サービス設計の検討漏れ発見にも貢献

顧客体験型設計法

直感理解型UI標準

開発や設計で、作業者が多数入れ替わる中、顧客要件を維持するのに効果を発揮

生産管理システムの開発関連スケジュール


適用結果（２／３）個々のUX問題に対する抑制効果１

１．個人の問題適用結果

(1) 画面デザインについてさまざまな意見が出て、なかなか決まらない。 △ 削減 ※

(2) ドキュメントのボリュームが大きく、設計担当者が一部しか読まない。 △ 削減

(3) ドキュメントの解釈の違いにより、設計者で画面にバラつきが出る。 △ 削減

２．チームの問題

(4) ドキュメントのボリュームが大きく、設計、標準化チームのレビュー時間が不足する。 △ 削減 ※

(5) 画面活用方針が不明確のまま進み、画面標準の検討が遅れる。 ○ 解決

(6) 画面デザイン標準を適用したが、標準どおりにできていない。 ○ 解決 ※

(7) チームごとに画面のバラつきがある。 ○ 解決

(8) ドキュメントの修正が、徹底されない。 × 未解決 ※

※プロジェクトが組織だって適用すると、より効果が増加。

実際の大規模プロジェクトにおいて、15件中11件のUX問題を抑制

営業管理システム開発プロジェクトへの適用結果

! 確認されたUX問題は、15件○ 解決、または削減されたUX問題は、11件

※完全に無くなることはなかったが、進捗に影響が出るほどは確認されなかった問題に対し、「削減」と定義。


適用結果（２／３）個々のUX問題に対する抑制効果２

実際の大規模プロジェクトにおいて、15件中11件のUX問題を抑制

３．全体の問題適用結果

(9) 組織的な制約などにより、既存システムの評価やヒアリングが十分できない。 × 未解決

(10) 限られた時間で、複雑・広範囲な業務内容の把握が難しい。 △ 削減

(11) ドキュメントの説明不足により、設計部門から問い合わせが多発する。 △ 削減

(12) 設計が進まないと決められず、仮決めしたドキュメントで、のちに不整合が発生する。 △ 削減 ※

(13) 業務背景や根拠の理解不足で、お客様の希望実現の可否が判断できない。 △ 削減 ※

４．制約による影響

(14) 設計が進んでいて、ドキュメントによる修正の影響範囲が大きくなる。 × 未解決

(15) 全体方針に従うことで、効率の低下や遂行に支障をきたす業務がある。 × 未解決

※プロジェクトが組織だって適用すると、より効果が増加。

※完全に無くなることはなかったが、進捗に影響が出るほどは確認されなかった問題に対し、「削減」と定義。

営業管理システム開発プロジェクトへの適用結果

! 確認されたUX問題は、15件○ 解決、または削減されたUX問題は、11件


適用結果（３／３）過去のプロジェクトに対する定量効果

解決可能個別解決が必要 UX問題全体

148 件（43%） 194 件（57%）合計 342 件

解決可能な問題の一例

○ 「弱視者の読み上げソフトで対応できていない。」

○ 「メイン作業である承認がどこまで完了したかわかりにくい。」

○ 「戻るボタンについての規定がない。」

○ 「一度メニューに戻るのは、作業上効率が悪い。」

○ 「エラーメッセージのタイミングによって、誤読してしまう可能性がある。」

個別解決が必要な問題の一例

! 「製造オーダと工程の入力値が連動するため、片方だけ修正する際に効率が悪い。」

! 「コード入力後に、登録キーを押す手順がわからない。」

! 「編集画面において、操作手順がわからない。」

! 「一部の画面において、用語の意味がわからない。」

メイン作業、および全体に関するコアな問題については、削減および解決可能。

ニッチな機能、個別画面については、これまでどおり個別に対応する必要がある。

画面・機能上の問題を、約 40% 抑えられる見込み

※ 前述した既存の20プロジェクトの342件のUX問題に対し、今回の提案で解決できた要件をピックアップした結果

例えば、弱視者などのアクセシビリティは直感理解型UI標準で定義できる。また、承認作業といった特定の体験は顧客体験型設計法で分類できる。


成果を方法論化

○成果を共有するため、大規模プロジェクトへのUX設計プロセスの適用について、フロー図にまとめ、個々の作業を定義し、フレームワーク化

○社内で共有することで、一般SEでもUX設計プロセスが適用できる基盤を構築

※フロー図（一部）

※作業定義一覧（一部）

※留意事項（一部）

○よく起こりうる問題点を留意事項として整理し、方法論活用を促進

○遵守状況を数値化し、各作業の優先度・重要度などの改良も継続

（例）画面デザイン： 91%もの画面に問題画面単位で4.03個の機能に問題


まとめ

大規模なプロジェクトの「失敗」につながる、2つの重要なUX問題を検出した。

1. 顧客ニーズの理解不足

2. 情報共有の不確かさ

! ただ、従来のUX手法では、限られた工数や期間、そして開発現場の実情に合わない問題があった。

○ そこで、2つの独自のUX設計プロセスを適用した。

1. UXを代表する画面・機能を予め決める、顧客体験型設計法


☆ その結果、このフェーズのプロジェクトが問題なく進行しただけでなく、画面・機能以外の問題も抑制し、予測されるリスクも約40％抑えられることが検証できた。

☆ 現在、この成果はフレームワーク化し、社内のUX設計プロセス基盤として運用されている。

課題

△ UXの開発現場適用はまだ理解がされにくい。コスト増ではなく、むしろコスト減になることを、より定量的にアピールしていく必要がある。

△ フレームワーク化しても、一般SEが利用するにはまだ抵抗がある。よりこれまでの開発プロセスに浸透する仕組みに改良していく必要がある。

大規模システム開発プロジェクトにおけるux - ipa · 2019-04-01 ·...

Documents