Enterprise User eXperience Design - ユーザー中心設計の実践 -

メモ

http://devlove.doorkeeper.jp/events/1931 の当日書きなぐりメモ

ユーザ中心設計（UCD）による、ユーザーインターフェース開発のススメ（前編）

市場の動向、顧客の状況

ユーザビリティとユーザエクスペリエンス

ユーザビリティ・エンジニアリング・プロセス

  • とは？
  • UDXとは
    • 使いやすく魅力的なシステムや商品をデザインする
  • UCDとは ISO9241–210
  • The Elements of UX
    • 表面、骨格、構造、要件、戦略
  • プロセス
    • 現状調査→現状分析→ペルソナ作成→要件抽出→プロトタイピング→評価→（満足するまで循環）

デザインセンターの設立

  • プロダクトオーナーと開発側に
  • 2007年に設立。2011年に正式組織化。
  • きっかけ。自動車会社のデザイン部門。UnifiedDesign。
  • 疑問
    • 評価軸がないのでは？
    • 美的センスがいるのでは
    • ユーザ前提によって異なるのでは？
  • 米国の例
  • 日本でも

最も大きな課題

  • ソフトウェア開発プロセスにどのようにユーザビリティ・エンジニアリング・プロセスをとりいれる？
    • ウォーターフォールにどうやってUCDとはを組み込む？
    • コストはどうやって見積もる？
    • どこを探しても答えが見つからない。
  • 要件定義後に、UI設計、UIガイドライン。
    • プロトタイピングがない。だめ。
  • 要件定義工程にて実施。プロトタイピングもやる。（準委任契約でやる。）
    • 現在は一部開発でやっている。

ユーザ中心設計（UCD）による、ユーザーインターフェース開発のススメ（後編）

UXとは

  • 機能がある Utility → 使いやすい Usability → 嬉しい・楽しい User Experience
  • UXの例 → iPhone、Piano Stairs、World’s Deepest Bin
  • ビジネス上の目的が裏にある。
  • UXのハニカム構造

適用事例

Selenium 2 (WebDriver) でinput項目に日本語を入力する

<後日追記>
解決しました。
Selenium 2 (WebDriver) でinput項目に半角カナを入力する

以下元記事
--------
テスト自動化を本気でやらねばと思って、Selenium 2 (Selenium WebDriver) の検証をはじめてみました。

@ITの記事（iPhone／Android含むブラウザ自動テストの最終兵器Selenium WebDriverとは）を参考にインストールして、「ブラウザ勝手に起動したすげー」「画面勝手に操作してくれるすげー！」「スクリーンショット自動でとれるすげー！！」って無邪気に感動していたのですが、一瞬で壁にぶち当たりました。


テスト対象Webページのinput項目（テキストボックス）にどうやって日本語入力すればいいの？？


WebDriver.sendKeys() はメソッド名のとおり、キーシーケンスを送るだけなので日本語は送れません。
つまりこれ↓はダメ。

driver.findElement(By.id("foo")).sendKey("テキスト入力");



ググってみてもなぜか同じ悩みを持つ人が見つからなかったので、ええい、ということで「Webdriver.get() メソッドにjavascriptスキームを渡して、JavaScriptを無理やり送る（いわゆるブックマークレット）」という無茶な方法を思い立って、試してみました。
つまりこう。

driver.get("javascript:(function(){document.getElementById('foo').value='テキスト入力'})();");
// jQueryが入ってるページならこれ↓でも。
driver.get("javascript:(function(){$('#foo').val('テキスト入力')})();");



思いの外ちゃんといける。

こんな感じで↓メソッド化して、、、

protected void inputTextById(WebDriver driver, String id, String inputText) {
    driver.get("javascript:(function(){$('input[type=text]#" + selector + "').val('"+ inputText + "')})();");
}


よしおk！
ってほんとにいいのかな？？この方法、これはこれで色々応用できそうなのでいいですが、日本語入力については、もっとちゃんとしたやり方があるような気が・・・。うーむ。


＜30分後追記＞
と思って改めて調べてたら、クリップボードを経由する方法があるみたい。明日試してみよう。

SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道

メモ

http://devlove.doorkeeper.jp/events/1733 の参加時かきなぐりメモ

業務系SEの今後について 〜消費税増税と年金問題が与える影響

自己紹介

  • 外資系M&A
  • 流通系上場企業の役員
  • ITベンダーの役員
  • キャリアの共通点

現在の社会状況 マクロ

  • 年寄りが増える
    • 清算価値が現象
  • 社会的コストの増大
    • 社会インフラの維持コストの問題
      • 公共事業で景気維持というスタイルの後遺症
      • ランニングコストを考えていない
    • 全体パイの縮小均衡
      • 人口減、売上の減少、コスト削減の圧力

現在の社会状況 個人

  • 年金問題
  • 消費税の増額
  • 実質所得は減少する

産業別人口

  • 日本人のIT技術者は多い
  • でも給料は安い

IT業界

  • PGの生産性は、10倍以上の開きがある。
  • であれば、できるやつの給料をあげろ
  • 本当に？
  • 他の業界ではあっても三倍。
  • なぜ差がない？
    • そんなにずれたら商売にならない。
  • なぜ差が出る？
  • そもそもばらつきがひどくないか？
    • 参入障壁がない。
    • 受託が、人数で数合わせをしているモデル（できなくても無理やり）

そこで経営層は普通どう考える？

  • できるやつの給料を上げる前に、できない奴の給料を下げる。
  • でも実態は、、、「できない奴の給料を上げないついでに、できるやつの給料も適用に据え置く」
    • 他人が給料あがったことのマイナスは、自分の給料が上がったことでは補えない
  • つまり、「人が多く、給料がやすい」+「能力のばらつきがひどい」→据え置き

ITのありかた

  • SI自体が成り立たないという現実
    • 人力で大規模SIに頼る現実
  • かつ、一人あたりの賃金が上がる要素はゼロに近い
  • ノーチラスは、人を増やさない。なぜなら給料を上げられないから

SIの現実

  • SI屋
    • 単純な売上増を安易なSIで稼ごうとする。
  • ユーザ層
    • ITリソースを外部から調達すれば良い
    • ITは本業ではない、と公言するユーザ様に顕著
  • この需要と供給で成立してきた。
    • 「市場としてのビジョン」は皆無。
    • 市場を維持しようというモチベーションが薄い
    • IT 業界特有
    • 結果として成立しているだけ
    • 「なくなるときに簡単になくなる」

業務系SEの現実

  • 認識すべき背景
    • マーケットとして厳しい
    • 企業環境として給与は上がりづらい
    • 年金・消費税の問題
  • 「どうすべきか？」
    • マーケットがどう変化するか
    • 変化するマーケットにどう自分自身をビッドするか
    • 賭けるチップは手元にある？

マーケットがどう変化するか

  • SIビジネスは縮小する
    • ゼロにはならない
  • 中規模・小規模SIの増加
  • SI自体の数の現象

変化するマーケットにどうビッドするのか

  • 少ない人員で回せる仕組みが必要になる
    • 100人月→70人月
    • 50→20
  • ある程度マルチでできることが必要になる
    • 能力のある人間が1.5役
    • 単一能力ではなく、複数の領域でのノウハウ
      • レビューをまわして、
  • 業務屋のニッチな仕事はむしろ増える
    • 物流システムは、倒産しやすい
    • 業務知識の豊富な人材が必要

手持ちのチップは十分か

  • 手持ちの武器は何が必要か
    • カードは多ければ多いほどいい
    • 最強–1のカードを目指す
  • スーパースターになる必要はない

エンジニアとしてのキャリアパス

  • 単一の道で最強をめざす
    • おすすめしない
    • 日本で最強はない
  • 複数の道で最強–1をめざす
    • おすすめする
    • 90点を100にするではなく、30を90に。
    • 50では妥協しないが、100はめざさない
  • それ以外は
    • 転職する

経験値として

  • 歴史は繰り返している
  • 車輪の作り直し
    • 作るべきかどうか、と再考する。（「作れる」は重要）
  • 流行に飲まれるな
    • 一回退いた上で、自分なりに咀嚼して「目的をもって」取り組む

何もしないとどうなるか

  • まずは実質所得が下がる
  • SIビジネスは縮小する
  • モチベーションとか、生きがいたおか、そういった精神的な充足のまえに生きるのがつらい

いままでと何が違うのか？

  • 座っていても大丈夫という時代は本当になくなる
  • SNS等のつながりで情報の流れが早い
    • 選択肢の幅
    • 競争の激化
  • 企業の壁が薄くなる
  • 勉強するモチベーションと、自分の脳力をどう評価するのか、ということが非常に重要になる

何をカードにするか

  • 設計
    • 普通の設計
      • 要素技術に依存しない
    • 例外処理を拾えること
      • やりすぎても、やらなくても死ぬ。程度を抑える。
    • 設計時点でパフォーまんすボトルネック
  • アーキ
    • すべての基本はI/O
      • 架空物理改装をちゃんと理解
      • 限界を理解
      • パフォーマンスはアーキで決まる
    • 障害設計から考える
    • 「何が何をするのか」がわかるようにしておく
  • アプリ
    • 基本はPM
      • WF、WBS、課題管理
    • 要素技術の共通点
    • 書き過ぎないこと
      • 書かない技術
      • 少ない人数でどうするか
      • 手をどう離すか
  • インフラ
    • とにかく情報収集
      • ただし枝葉はいい
    • ネットワークの基礎技術は抑えること
    • ハード
  • 運用（継続開発）
    • 設計が命
      • 運用設計は絶対一度は経験すること
      • 今まで見えなかったものが見える
    • CIのマスター
    • コスト意識
  • 基礎技術
    • 「計算」についての基本知識
      • 計算量
      • 確率統計
      • 計算とはなにか
    • 「品質」についての基本知識
      • 品質は作りこむもの
      • 手法は様々だが、完璧なものはない
      • 「予見可能性が高いもの」 = 「品質が高い」。
        • どうなるかわからないもの
    • 論文は読めるようになっておくこと
      • 巨人の肩に乗るべき
  • 業務系ノウハウ
    • 「考える」
      • なぜこういう仕組みになっている？
      • 書籍を読む。基礎知識を積む
    • 「聞く」
      • なぜなのか？
      • いやがられるけどめげない
    • 「応用する」
      • 大事なのは個々の仕様ではない
      • 「考え方」を学ぶこと
        • 考え方には文化がある
        • 感覚。センス。
        • 顧客の印象もよい
      • 「考え方」を常識にとらわれず転用する。

Q&A

  • 少数精鋭部隊がどうやって受けられるのか？
    • 受けないほうがいい
    • 大規模のSI自体を見直す
    • 受注側が発注拒否している
  • 大手SIerにいたままそうやって？
    • 中でちゃんと提案する。
    • ケンカ別れは簡単
    • こうしてったほうがいいですよ。
    • 部の意見はこうだ、で経営層にかけあう
  • エンドユーザ側にたってイノベーションを起こせないか？
    • それはある。
    • その人のモチベーションを維持するのが難しい
    • コストもまっさきに切られる。
    • R&D部隊
    • 実際のユーザ企業にはいると、ギャップはあるよ。
    • ヤル気のある取締役
  • USのユーザ企業は流動性が高い。すぐに首切れる。日本ではどうする？
    • 別の業務をやらせる。
    • PMを必ずやっているのはIT業界ぐらいだ。
  • シュリンクするSIの受け皿は？
    • コアな人間を引きぬく
  • 質の悪い人材をどうやって引き上げる
    • 論理的にものが書ける人間をとる
    • 二年間しっかりトレーニング
    • できないなら取るな
  • お金がないけどやる、のはどうすればいい
    • やるな。SIの悪いところ
    • やるなら投資だから、回収計画を上に立てさせる。

Google HTML/CSS Style Guide が勉強になった

はてブのホッテントリにあがってた

Google HTML/CSS Style Guide が良かったです。これそのまま業務プロジェクトのガイド、規約として適用できるよようなすてきなドキュメントでした。

読んでて勉強になったものもいくつかあったのでメモしておきます。

#JavaScript Style Guide もあるみたいなので読んでみよかな。JavaのStyle Guideもあればいいのになぁ。

プロトコル省略

General Style Rules > Protocol のところ。

Omit the protocol from embedded resources.
Omit the protocol portion (http:, https:) from URLs pointing to images and other media files, style sheets, and scripts unless the respective files are not available over both protocols.
Omitting the protocol—which makes the URL relative—prevents mixed content issues and results in minor file size savings.

こんな書き方できんのね。便利。

オプショナル・タグ

HTML Style Rules > Optional tags のところ。

Omit optional tags (optional).
For file size optimization and scannability purposes, consider omitting optional tags. The HTML5 specification defines what tags can be omitted.
(This approach may require a grace period to be established as a wider guideline as it is significantly different from what web developers are typically taught. For consistency and simplicity reasons it is best served omitting all optional tags, not just a selection.)

これはかなり衝撃でした。Optional Tagについてほとんど何もしらなかったので、特にhtml、head、bodyが省略可能なのに衝撃。 確かにこのへんのタグは書かなくても文脈上自明やな・・・。自明な文書構造セマンティクスは省略するシンタックスシュガー的記法。便利。

でも理解の浅い人が、文書構造を意識してない汚いHTMLを書く原因にもなりそう・・・。

この記事も面白かった。
HTML5でのタグの省略は結構考えられている件