nanapi勉強会
http://nanapi.doorkeeper.jp/events/16392
- デザインのためのデザイン: nanapi 上谷 真之
- グラフィックデザインソフトをアンインストールしよう: BEENOS 山本 郁也
- 外部から組織に加わるデザイン: STANDARD inc. 鈴木 智大
- デザイナーとエンジニアの良い関係: Bracket 河原 香奈子
- 「個」から「集」のデザインへ: nanapi 木村 真理
デザインのためのデザイン: nanapi 上谷 真之
- デザインのためのデザインとは
- 良いデザインを生むためのデザイン= 組織デザイン
- (組織全体よりは)開発チームを主語とした組織デザイン(の話)
- 「デザインは、デザイナーに任せるには重要すぎる」(IDEO社のCEOの人)
- いいプロダクトにはいいチームが不可欠
- 全員でデザインする組織へ
- 良いデザインを生むためのデザイン= 組織デザイン
起こりがちな問題
- 暗黙知の蔓延
- 例:情報設計やインタラクションデザインの品質担保をするのはだれ?
- メンバーの熱量が低い
- 例:分業化やトップダウン型が過剰で、メンバーが受け身になる→自走力(考える力、意欲)が低い
- コミュニケーションロスが多い
- 例:対立が頻繁に起こるなど。共通の価値観がなく方向性がばらついて対立してしまう
nanapiでの対策
文化が不可欠!
- 開発体制の大幅な変更
- 暗黙知の排除
- 職種の再整理
- 言葉の再定義
- 社内勉強会の開催
-
開発体制の大幅な変更
- リーダーをおかないことにする
- 旗振り役は兼務。ファシリテーターとして配置
- ユニットのKPIをチームで追う
-
暗黙知の排除
- すべての行動を明確に、徹底的に説明する風土を作る
- 全員が主体性をもち自然に間違いを正す
-
職種の再整理
- デザイナーやエンジニア等、持つべきスキルとマインドを再整理
- 暗黙的な部分をなくして、誰がどこで活きるのか明確化
- 規模感:小さいほうがいいのでは
- 縦割りでOKなスキルと横断して持つべきスキルがそれぞれある
- ユニットのKPIをチームで追うことで、意識を共通化できている
-
言葉の再定義
- バズワードは定期的な見直しが必要
- 認識のズレはDisCommunicationを産み、アウトプット品質の低下
- 価値観は変化していくので定期的にモニタリングして共通言語を定める
- 社内ヒアリングしてみるとずれが視覚化されていい
-
社内勉強会
- 座学
- 社内で共通認識を形成しメンバーの視座を高めること
- バズワードは極力使わない
組織デザインのアンチパターン
- 独裁政権を作る
- 個を伸ばす(ではなくチームをのばす
- 最後までやりきらない(時には周りを巻き込んで粘り強く進めること
いいデザイナーとは
- スキルだけでなくマインドセットが豊かであること
- 本質を捉えて考えぬくことができる
- マクロ視点/ミクロ視点。状況に合わせて柔軟に視点を変える。俯瞰して咀嚼し、質の高いコミュニケーションに変える。
-
ゴールの設定力(どこまでブレイクダウンして具体化できるか)が高い
- nanapi 上谷 真之
- デザイナー 兼 CCO
- 受託系制作会社でWebデザイナー、教育系スタートアップで色々、とか
- 人材育成、採用を含む組織デザインと、(たまに)サービス開発
- nanapi 上谷 真之
グラフィックデザインソフトをアンインストールしよう: BEENOS 山本 郁也
- 狭義のデザインから広義のデザインへ
- デザインの対象は多岐にわたる
- グラフィックデザイン、インターフェースデザイン、ソフトウェアデザイン、ワークショップデザイン、組織デザイン、ビジネスデザイン、エクスペリエンスデザイン、サービスデザイン、コミュニケーションデザイン、ソーシャルデザイン…
- デザイナーは何になればいいのか、何をする人なのか
- コミットメント問題(オデッセウスの鎖)
- 誘惑に負けないよう自分を縛り付けることによって解決
- コミットメント問題(オデッセウスの鎖)
- 「◯◯する人だ」と見られないようにするには
- 一番頼っていたスキルを捨てる(=ツールを捨てる)。そのときに何ができるか?
- コンフォートゾーン、できることしかしない状況から脱する
- あらたな武器を身につけよう
あちらサイドに寄っていくには、 向こうの言葉で話すことが大事!
- BEENOS 山本 郁也
外部から組織に加わるデザイン: STANDARD inc. 鈴木 智大
受託開発である以上、いつかは離れなければならない。受託開発としての心構えとは。
Vingowリニューアル
-
表面的課題
- iOS7対応
- ブランドイメージ改善
- ユーザービリティ
- なんとなく追加された機能の整理
-
潜在的課題
- 開発プロセスの標準化(手戻り
- スピード感が失われかねない
- デザイナーの数不足
- 同じ問題が再発しうる
- あったらいいなで機能が追加される(指針がぶれてる
- 開発プロセスの標準化(手戻り
いろいろタスクをこなす中で裏でやっていたこと
- まず一人と仲良くなる
- いきなり全員は無理、成功体験と事例を作ることで組織の内部に楔を売っておく
- 実装のことを共通言語にしながらコミュニケーション
- デザインについて考えられる時間の確保
- 手戻りすると実現不可
- やったこと
- プロトタイピングツール
- 詳細な指示書
- 細かな実装
- 成果を出す
- 短期的成果
- エンジニアに時間が生まれ、ビジュアルやインタラクションについて提案してくれるようになった
- 中期的成果
- ファシリテーションがしやすくなった
- 他のメンバーも意見を聞いてくれるようになる
- ファシリテーションがしやすくなった
- 長期的成果
- デザイナー以外の人もデザインに関わる文化が芽吹く
- 短期的成果
まとめ
- まずは一人か二人を味方につけよう
- 相手が新しいことに取り組む時間を作ろう
- 成果を出そう、成功体験を持ってもらおう
- 鈴木 智大
- 受託開発
- iOSアプリケーションの情報設計、UIデザインを担当している
デザイナーとエンジニアの良い関係: Bracket 河原 香奈子
デザイナーの悩み
- どこからどこまでがデザイナーの仕事?
- デザインの意図が伝わらない、実装されたものがなんか違う
だいたいコミュニケーション不足に起因する
- あるある例
- 「あとは実装よろしく」で丸投げ
- 矛盾や実装の困難
- 興味を持ってもらえない
- 「あとは実装よろしく」で丸投げ
- stores.jpにおけるデザイナーの役割:「むかうべきビジョンを具現化する役割」
- 具体的なものを作れるという強みを活かした振る舞い
- 例:ストア同士のフォロー・フォロワー関係
- プロダクトになかった概念なので、 プロトタイピングに時間をかけた
- ツールもいろいろ試しながら。
プロトタイピングに時間をかけたことでコミュニケーションが生まれた
- モックをつねに共有しながら薦めたメリット
- チーム内から意見が出やすくなった
- 矛盾に気づいてもらえる
- 開発を並行できる
- スピードアップ
- 共通理解をつくれる
- 未完の状態からプロセスを共有することでやろうとしていることを伝えられる
- アウトプットも良くなった
- プロセスの改善がアウトプットを改善する
- チーム内から意見が出やすくなった
コミュニケーションをしよう
- 未完成のデザインを晒そう
- やり方は臨機応変、意識的に変えていこう(相手や状況に合わせて
- エンジニアの様子を観察してみる
- 悩んでるようなら、デザインがイケてない可能性を考えてみる
- Bracket 河原 香奈子
- Stores.jpのデザインを受託
「個」から「集」のデザインへ: nanapi 木村 真理
- emosiの開発フローを通してチーム作りについて考える
開発フロー
- よくあるパターン
- ディレクターが要件定義してデザイナーがUI作ってエンジニアが実装
- デザイナーは見た目を作る人、他の人は関わらない
- ウォーターフォールな縦割り
- emosiチームのメンバー構成
- デザイナー
- サーバサイドエンジニア
- フロントエンドエンジニア
- emosiチームの進め方
- 要件定義までは3人みんなで
- それ以降は分担
- デザイナーは「チームの中で たまたま デザインが得意な人」という位置づけ
- メリット
- 全員が考える人
- プロトタイプを大量に試せる
- アンチパターンを見つけやすい
「「個」から「集」のデザイン」とは
-
ペーパープロトタイプは全員で
- エンジニアも参加
- 誰がやっても差がでないのが(・∀・)イイ!!
- 活発な意見が飛び交う、遠慮しないですむ
- おアンチパターンを潰せる
-
UI改善も全員で
- 例:全員でファンネル分析
- メリット
- アイデア増える
- 数字ベースで話せる
- 自走すべきところは任せる
- 自走すべきところとは
- ビジュアルデザイン
- フィードバックアニメーション
- モックツールの導入検討
- 自動化
- メリット
- アウトプットぶれにくい
- スピードとクオリティ両立
- コミュニケーションコスト低減
- 自走すべきところとは
- nanapi 木村 真理
- デザイナー
- Web受託制作会社5年ちょい
- nanapi3年ちょい
comments powered by Disqus