エンジニアにできること？できないこと？お願いしたいこと？ Silverlightを囲む会 in 東京 #4 尾上 雅則 1. 自己紹介 2. 開発の現場から 3. エンジニアとして出来る事・出来ない事・お 願いしなくてはならないことの境界 4. プロセスとUXと品質特性 5. まとめ • UXについて考える動機 尾上 雅則(おのうえ まさのり) 28歳目前 C#er ◦ WPF/Silverlight/Windows Phone/Windows Forms/ASP.NET/SQL Server Blog ◦ The sea of fertility – http://ugaya40.net Twitter ◦ @ugaya40 MVVMer ◦ 設計パターン ◦ For WPF/Silverlight/WindowsPhone7 MVVMパターンの普及を狙っています。 WPF/Silverlight/WindowsPhone7でのMVVMパターンの動機 付けは完了していますが、 そもそもWPF/Silverlight/WindowsPhone7を採用する動 機は何か？それがUXについて考え始めるきっかけでした。 • ３つの移植事例から考える • UX(ユーザー体験) 操作性も含めて本当に完全な移植を求められた。 イカしたデザインになっただけ。 ただの移植 リッチクライアントにした意味もなく・・ 当然・・・・ 操作性も含めて本当に完全な移植を求められた。 デザインもイケていなかった。 ただの移植 リッチクライアントにした意味もなく・・ 操作性もよくなり、デザインも非常によく、ブラウザ上 で操作しているのにスタンドアロンアプリと間違えるレ ベル。 リリース されず！ GradeUp! 行ける・・ 構造的な分類(UX構造)で事例を振り返ってみた Usaful 有用性 Findable 検索性 Useful 使いやすさ Valuable 価値 Credible 信頼性 Desirable 好ましさ Accessible 辿りやすさ Facets of the User Experience Semantic Studios http://semanticstudios.com/publications/semantics/000029.php WebシステムをSilverlightに移植して不評だった事例 Usaful 有用性 Findable 検索性 Useful 使いやすさ Desirable 好ましさ Valuable 価値 Accessible 辿りやすさ 見た目以外ほとんど Credible 信頼性 何も考慮していなかった 確かに見た目は大事ですけど。 ハードウェアをWPFに移植して好評だった事例 Usaful 有用性 Useful 使いやすさ Valuable 価値 Accessible 辿りやすさ Findable Desirable 検索性 想定ユーザーは 好ましさ Credible 移植元ハードウェアの操作に習熟していた。 信頼性 Desirable(好ましさ)に考慮はなかったが、ほかの 要素をバランスよく提供できていた。 ActiveXグループウェアをSilverlightにリプレイスして お蔵入りした事例。使いやすさが０なばかりに。。 Usaful 有用性 Desirable 好ましさ Valuable 使いやすさが０なばかりに、価値を失い、 Findable 検索性 価値 Accessible 辿りやすさ Credible そして誰もいなくなった。 信頼性 他の経験と併せて振り返ってみて ◦ いわゆるUX(ユーザー体験) ◦ UXを構成する要素・特性には当然いろいろな分類があるが、 少なくとも各要素・特性について少しでもごく常識的な配慮 をしていれば特に問題になることはなさそう。 ◦ しかし全く考慮していない特性が存在すると、その特性がほ かの特性を引きづり、結果的に大きな手戻り工数を出現させ たり、場合によってはシステムそのものをなかったことにし てしまいかねない。 なぜこうなったのか？ ◦ 現場ではみんなもちろん出来る限りのことをしていたつもり だった。 ◦ 力が足りなかったというのは簡単 ◦ では何の力が足りなかったのか？ ◦ メンバのスキル依存問題？そうと言えばそう。 ◦ 同じ間違いを起こさないためにはどういった対策をとればよ いか？ • エンジニアとして出来る • 最低限の努力 エンジニアに できないことはなぜエンジニア にできないのか • • ごく常識的な事がまず浮かぶ まず品質は最低限のUX。そしてそのための設計 ◦ 品質は大きくわけて２つの視点に分類できる。 ◦ 内部品質 設計仕様とプログラムの一致具合 ◦ 外部品質 ユーザー要求と設計仕様の一致具合 → エンジニアはこちらの意識が弱い事が多々ある。 コードは設計書じゃない。 ごく常識的な事がまず浮かぶ プロジェクトの一員として行える努力 ◦ みんなが快適に作業できるようなプロセスの提案 → 結果的に品質が上がることが多い ◦ 通っていないコミュニケーションパスは通す → コミュニケーションストレスは大きくメンバーの士気にかか わる。 ◦ 愚痴る前に出来る事はたくさんあります。 出来ない事 → 提案が却下されて代替もなく身動きが取れなくなった時 それがエンジニアに出来ない事。 お願いしたい事 ◦ エンジニアの職責の外にあること？ → え、それ自分でやっちゃだめなの？？？？？？？？？ そもそもエンジニアの職責って何で決まるの？ 広義のプロセスでは？ そもそもプロセスは何で決まるのか？ ソフトウェアの品質特性とは？ プロセスとは？ ◦ プロジェクト全体の形を規定。あるいはビジネスの形を規定 ◦ プロジェクトの立ち上がり方からフェーズの分け方・各 フェーズでの納品物の定義etc… プロジェクトの状態を客観的に評価・整理できるように進行を分 割し、定量的な評価試みることを可能にするもの。 ◦ いわゆるダブルチェックや手順書の運用etc… 不確定要素(個人のスキル依存など)を極力取り除く努力 プロセスとは？ ◦ 一つのシステムにおいて、ユーザー要求と同時・あるいはそ れより前に存在しているルートインプット ◦ 他のルートインプットとしては予算・物理的金銭的なビジネ ス制約などがある。 ◦ ルートインプットは、ユーザー要求の受け入れ方すらも決定 する。 → ユーザー要求が明確にUXを要求するように なってきたのであれば 各種ルートインプットも変化して当然では？ 単純に、「じゃあ外部設計(基本設計)で、ユーザーとモッ クを検討する時間をとろう！」と言って出来る場合はよい がそれが通らない事も多い。 UXを考慮したシステムのためのプロセスをしっかりと作 るべきだと思う。 しっかりとしたプロセスとして構築し、自社の、あるいは 業界の商品としたい。 ではそのプロセスを構築するためのインプットは？ そのプロセスは何を満たすためにあるの？ プロセスが満たしたいのは、 プロセス構築のためのインプットとなるのは、 ソフトウェアが満たすべき品質特性だと僕は考えてい ます。 そして現在よく使われる品質特性ではUXのためのプ ロセス構築には足りないのではないか？ ユーザー要求を機能要件・非機能要件に分類し導出 ◦ 機能要件 ◦ 非機能要件 性能 信頼性 拡張性 セキュリティ Usaful 有用性 Useful 使いやすさ Valuable 価値 Findable 検索性 Desirable 好ましさ Accessible 辿りやすさ Credible 信頼性 →Desirable(好ましさ)、もしかしたらUsable(使いやすさ) を満たすシステム構築のプロセスとして欠けていませんか？ もともと要求を明示された後の話だけどアーキテクチャ決 定要因 技術制約 ビジネス制約 品質特性 ◦ ◦ ◦ ◦ ◦ ◦ 可用性 変更容易性 性能 堅牢性 テスト容易性 使用性 機能要件 Usaful 有用性 Useful 使いやすさ Valuable 価値 Findable 検索性 Desirable 好ましさ Accessible 辿りやすさ Credible 信頼性 →Desirable(好ましさ) を満たすシステム 構築のプロセスとして欠けていませんか？ 要求を受け入れる段階から UXのための特性を意識してプロセスが構築されるべき。 そしてそのためのインプット(プロセスが満たすべき特 性)があるべき。 以降僕からの提案になります。 機能性 信頼性 使用性 効率性 保守性 移植性 各特性には副特性が定義されている。例えば・・・ 使用性 移植性 • 理解性 • 設置性 • 習得性 • 共存性 • 運用性 • 置換性 • 魅力性 Desirable(魅力性)につい ても特性としてきちんと考 慮されている。 また、設置場所や時間の経 過によってシステムの価値 に変動があることまで考慮 されている。 機能性 効率性 Usaful 有用性 信頼性 保守性 Useful 使いやすさ Valuable 価値 Findable 検索性 Credible 信頼性 使用性 移植性 Desirable 好ましさ Accessible 辿りやすさ ISO9126は事前に挙げた UX構造を副特性を含める ことですべて内包します。 僕はISO9126こそ UXを考慮したシステム構 築プロセスのインプット として活用すべきだと 思っています。 現場での経験からUXについて考えるようになり ました。 人依存・スキル依存をそれで良しとするならば、 下請け構造でのチーム開発を必須とするシステム 開発の現場はずっと何かにおびえなければなりま せん。 UXを考慮したシステム構築において、まず考え るべきことはUXを考慮できるプロセスの改善で はないかと僕は思っています。
© Copyright 2024 ExpyDoc
