2017年1月18日に行われた「たまキャリ #1」のセッションで使用したスライドです。

1. 今やWeb制作者じゃなくなった
私の仕事実態
伊原 力也 / BA
2017.01.18 @ たまキャリ #1
#tamacareer

2. @magi1125
• 所属
• BA（ビジネス・アーキテクツ）
シニアインフォメーションアーキテクト
• 他の所属
• HCD-Net 評議委員／認定人間中心設計専門家
• ウェブアクセシビリティ基盤委員会 WG1委員
• 国際ユニヴァーサルデザイン協議会 移動空間PRJ副主査
• クリエイティブユニット mokuva

3. 私の17年間

4. 1999～2016
フロントエンド
情報設計/UI設計
ユーザー調査/分析
2007 20112009 2014

5. フロントエンド
1999：アルバイトでWeb制作（フルCSS）
2004：BA入社（マークアップデザインエンジニア）
2006：スタイルガイド設計・ガイドライン執筆
2008：案件規模拡大＆グローバル化
2011：スマホサイト対応
2014：要件定義、QA（パフォーマンス、アクセシビリティ）

7. 情報設計/UI設計
1999：いわゆる「ホームページの立ち上げ」
2002：ガラケーの占い・待受サイト
2007：製品プロモーションサイト
2009：企業情報系、公共系、ECサイト
2010：イントラ、シミュレータ、ポイントシステム
2011：グローバル、SNS、マルチデバイス
2014：スマホアプリ（ハイブリッド）

9. ユーザー調査/分析
1999：ヒューリスティック評価
2005：アクセスログ分析
2009：プロトタイピング／ユーザビリティテスト
2010：アンケート
2011：ユーザーインタビュー
2012：ペルソナ／シナリオ
2014：ワークショップ

12. フロントエンドからの発想
ユーザー調査
コンテキストの視点
情報設計
イディオムの視点
フロントエンド
マイクロインタラクションの視点
UI
イディオム
コンテキスト
コンセプト

13. 作れる＝試せる、聞ける、推進できる
• 誰かに頼まずともプロトタイピングできる
• 流れや実現性を検討したり試したりできる
• モノがあればプレゼンできる、主導権が握れる

14. 受託側と事業側の両立

15. よく言われる「受託と事業会社の違い」
受託側 事業側
スタイル
さまざまな業種や案件が
並行して進む
いちサービスに
じっくり取り組む
進行
課題を受け、イチから作り、
納期に追われる
課題を設定、少しずつ改善、
目標に追われる
アウトプット
Webやアプリなど
対象物が固定されがち
サービス周辺の
さまざまなものが対象
成果
知りにくい
（納品で区切り、追いにくい）
逃げられない
（区切りなく、追い続ける）

16. 良いとこどりできないのか？
• 受託の面白さ「視野の広がり」
• 様々な業種や案件を経験できる
• 長年の歴史を短期間で吸収できる
• 受託の弱い点「区切り」
• 結果がどうだったのか把握しきれない
• 体験を高めるための Catch & Try ができない

18. 受託というスタイルは死ぬのか?
• 「なにを受託するか」で生死が分かれそう
• 単なる制作だけでは厳しい
• UXデザイナーにおいては、さにあらず
• 事業会社がUXデザイナーを抱えるハードル
• よく知らないものを雇用する難しさ（※解消傾向）
• 第三者の専門家的スタンスの重要さは健在

19. ファシリテーション プロトタイピング
以下あたりをパッケージとして
ユーザー調査 情報設計 UI設計

20. 「中に置いてみませんか？」の試み
受託案件A
20%
受託案件B
30%
事業会社常駐
50%
• 半常駐スタイル（週2日）
• ユーザー調査、コンセプト立案、
プロトタイピング
• 打ち合わせへの参加、
ファシリテーション、立ち話
• 月2回リリースでの継続的な改善
• 他アプリレビュー、設計プロセス提案
• 月額定額制、1年半ほど継続中

21. 早く帰るための選択と集中

22. 私の生活
• 8時～17時で稼働
• こぼれたら自宅作業
• 休日稼働なし
• 有給は月2日取る

25. 効率の最大化
• 相性が良い案件のみに注力する
• 場づくりと成果づくりに注力する
• ワークフローを見直す
• 必要十分なものだけを作る
• 限られた時間で決める

26. 相性が良い案件のみに注力する
自分が短時間で出せるアウトプットから案件を選択する
• 大規模ガバナンスやツール系アプリを選択
• コンセプトを割とロジカルに反映できる
• ダーティなプロトタイピングでも方針を示せる
• 感性に寄りがちな「広告プロモーション系」は回避

27. 場づくりと成果づくりに注力する
作業範囲が適材適所で明確なほうがお互いにハッピー
• 中間資料はなるべく作らない
• 社内承認、開発仕様、証跡といった資料作成は
クライアント担当者にお任せする契約に
• 受託側がやって千本ノックになるより、
会社のルールを知る担当がやったほうが早い

28. ワークフローを見直す
要件が変化する、設計後に気づく、動かしてからわかる…
• 調査→ホワイトボード→プロトタイピング→テスト
• 合意形成の場そのものをメインに
• 議論に必要なネタを集めたり作ったり
• プロトタイプは「舵を取るための道具」

29. 必要十分なものだけを作る
Nice to have is not to have. あるとよい物はない方がよい
• やりすぎず、必要なものを必要なだけ
• 何が必要かを考える時間を大きく取る
• 調査に正解はない、
材料が多いから判断が適切なわけではない
• 設計にも正解はない、
妥当そうな案は作ってみて検討する

30. 限られた時間で決める
持ち帰ると時間が伸びる→生活にしわ寄せ→家が怖い
• とにかく「持ち帰らない」ために
• どこまで決めたら良いのかを先に考える
• ワイヤーフレームではなくラフデザインを作る
• ホワイトボードとデザインツールで積極的に進行
• せめて「あと何があれば決まる」まで進める

31. Frontend ✕ IA / UX
市場 ✕ 生活
デザイン

32. 副作用：少しずつ作れなくなる
• 一見無駄な「大量のインプットと実践」こそが源泉
• フロントエンドの知見、3年前で止まっている
• もうイマドキの「作れる人」ではない
• ブラウザWeb以外の世界に対してどう対応する？
• 学び直しが必要だが…

33. この先生きのこるには？
続きはトークセッションで！
@magi1125