UX KANSAI #02 オブザベーション（2017.7.8）
約半年ぶりの UX KANSAI。
久々の学びの場は激反省に終わりましたよ。
本日のテーマは『オブザベーション』。オブザベーションとは質的調査のひとつ。
質的調査とは？
定量と定性でいうところの後者。顕在と潜在でいうところの後者。質的調査にも種類があり、ばっくりとは以下３つ。
- 自分でやる「参与観察」
- 人がやっているのを見る「オブザベーション」
- 人がやっているのを見て、聞いちゃう「エスノグラフィティー」
本日はふたつめのお勉強。
オブザベーションのいいとこ
例えば、サイトのユーザー調査。
実際にユーザーにサイトを使ってもらう。
使ってもらって、ただただ観察。
観察して「あれ？なんでこの人こんなことしてんの？」って気になる箇所見つける。
しばらく後に「なんでこんなことしたの？」って聞く。
この「すぐ聞く」のが大事。
体験から時間が経って後に、インタビューとかで思い出してもらいながら聞いても、ホンネ（ニーズ）は出てこないそうな。
何で後から聞いてもホンネは出てこないの？
理由は２つ。
１つめは、人は「忘れる」から。これは本能的な自己防衛機能なので仕方なし。
２つめは、大変なことがあっても人は鍛錬で乗り越えるから。乗り越えた後だとその時の困り事は言語化できない（PCのキーボードとか。くそ不便なのに、みんな慣れちゃってる）
ゼリーの課題を解決するデザインを考えるワーク
他にもいろいろインプットがあり、ワークへ。
私は2016年に UX KANSAIを受講していたため、OBとしてオブザーバー（見学？）的な立場で参加させていただいたのですが、まぁこれがなんともヒリヒリするような受講になりまして。。。
今年の受講生のみなさんはとても優秀で、なんとも鋭い視点を持った発表が続きます。
OB陣は発表の予定はなかったのですが、急遽発表することに。
発表結果は「一年勉強してこれか。情けねーよ」とは、浅野先生のコメント。
ぐぅの音も出ません。おっしゃるとおり。
去年の自分と、今年の自分
ほんと「去年１年何してたん！？」を突きつけられ、なんともトホホな心境。
とは言え、去年と今年で多少自分の中に変化が生まれてて、反省点（自分の何がダメだったか）を言語化できるようになった（去年はただ「何かモヤモヤする」っていうことしか言ってなかったw）。
今回の反省点は以下３点。
最終ゴールをイメージせずに作業しちゃうよね
何時までに○○を考えないと、って言われているのに、それをイメージせずに議論開始。それは議論ではなく、もはやお喋り。
ゴールを見据えていれば、自然と役割分担しよう！とか進め方どうする！とかお題が出てくるだろうに、それがあまりなかった。
ユーザーを限定的に考えちゃうよね
今回のワークショップでは、自分ともう一人が被験者（ユーザー）としてサービスを利用したのだけれど、この２人のことしか考慮しない検討内容になっていた。
てか、スタンスが舐めてるよね
うまく言えないけれど、OBっていう立ち位置は、私自身を舐めた態度にさせてしまうような。反省（受講生じゃないので本気度が違う、みたいな？？）
う～ん。最初の２つは去年から言われてたな（汗）。うん。でも自覚できたのは収穫だ！
教育とは
最後に、先生がおっしゃっていたこと。
「教育はカスタマサービスじゃない」
「飢えた者に魚を与えるのではなく、魚の採り方を教えるって言うでしょ？」
刺さったなー。去年の自分は飢えてたなー。でも今日は飢えてなかったなー。もはや参加資格ないじゃんねー。
ということで、あらためて教育を受ける者として、いろいろ反省しよーっと。参加してよかった（「勝ちの途中の負け」な日だった！）
パパパパッカソンに参加した話し（会場とか運営の方とか良かったよって話し）
関西初上陸『パパパパッカソン』、パはパ・リーグのパ。「パ・リーグと遊ぶ」ためのハッカソン
主催は『filament』。『filament』が運営するコワーキングスペース『TheDeck』で開催する自社主催では初のハッカソン。
関西でハッカソンと言えばココ！という会社が主催とうことだけあって、イベントの構成もホスピタリティもクオリティも凄かった。
子連れOK
これは凄い。こんなこと大々的に言うハッカソンは今まで見たことない。
会場にはテントがあったりゲームがあったり。他にも『ロボホン』あるし、お店のスタッフさんが気にかけてくれるし。
子どもと遊びたいけど、ハッカソンにも行きたい！そんなパパさんはむちゃくちゃいると思う。
テーマのおもしろさ
（私は野球に疎いのでそこは省きますが）健康というテーマがあった。ハーバード公衆衛生大学院イチロー・カワチ教授主宰 SHL（ソサエティアンドヘルスラボ）の方のキーノートがあり、健康がいかに大事かを知ることができた。
※内容からは逸れますが、プレゼンがむちゃくちゃお上手。ユーモアを交えながら聞く人をグイグイ引き寄せる。勉強になります。
チームビルディングの手厚いサポート
各人でアイデアを出し合い、面白いと思ったアイデアに星をつける。多く星がついたアイデアに、「これやりたい人！」とこの指とまれ方式でメンバーを集めチームができる。
各人のアイデアをチェック
おもしろいと思ったアイデアに★マーク
★の多いアイデア発案者によりアピールタイム
今回 2日間の開催ということもあり、1日だけの参加者もチラホラ。途中で人がいなくなるのって残されたメンバーは結構大変なのだけれど、そのあたりも上手く運営側がフォローしながら 6チームが結成。
チーム組めた！（良かった）
食事
昼食も夕食もむちゃくちゃおいしかった（けどコメント割愛。食事の豪華さはマストではない（と個人的には考える）ため）
メンター＆メンタリングタイム
ハッカソン常勝のデザイナーさんに加え、数々のハッカソンを主催してきた運営会社の代表自らがメンターに。
ハッカソンあるあるのアドバイス（通信を使ったデモなら動画撮った方がいいとか）や、視点の提供など、プレゼンがうまくいくように一緒に考えてくれる。
ガジェット（と提供者のホスピタリティ）
まだ市場に出ていない富士通のセンサーシューズ、リストバンドが音楽を奏でる「SecaiOngaque［セカイオンガク］」など観ているだけでわくわくするガジェットが。
シリコンハウスさんが出張貸し出し＆販売に。シリコンハウスさんにおいては、半田付けにアドバイスいただいたり、さくらのクラウドさんと繋いでくれたり、本当に多大なご協力をいただきました。
さくらのクラウド・植木さんについては、歯医者に行く途中だったのに何度もTheDECKに足を運んでいただきサポートいただきました（デバイスとの相性で、結果的に取り入れられなかったものの、その献身的な姿勢に感動しました）
24時間、場所を提供
私のチームのメンバーも泊り込みで徹夜していたのだけど、なんと運営側（って『filament』の代表の方だけど）も一緒に徹夜。適宜アドバイスを行うなどクオリティアップ、参加者のモチベーション維持に努められていました。
プレゼンにはもれなく解説が付いてくる
これは面白かった。プレゼンが終わるごとに、前出のハッカソン常勝メンターが解説をしてくれる。内容がおもしろいだけでなく、「なるほど～」と参考になるものばかり（※私がプレゼンで留意いていたことをズバっと言われてギクっとしました（汗））。
納得の審査
たまーにある「なんであそこが優勝？」。でも、今回は審査基準も明確で後腐れない感じ（参加者としては非常に重要）。今回、残念ながら受賞は無く「うそ～ん！」と思っていたのだけれど、懇親会でいただいたフィードバックや、その後 facebookでいただいたコメントなどがあり、「そりゃそうだよな～」と納得。
これってとても重要で、基本的には評価は受け入れるたちなのだけれど、過去1回だけ全然納得のいかない審査結果（ノーアイデア、だらだら課題を喋っただけ。しかも周知の。でも優勝。関係者だからか？ってのがあった）を経験したときには、そりゃーもぉ。。。荒れますよね。
なんだか長くなったのでこれまで！ハッカソンで得た気付きなどは、また後日書く！
MBSハッカソン決勝（観戦席から）
落ちたくせに忘れ物をして運営側にご迷惑をかけるという（汗）。
忘れ物引取りついでに、決勝観戦席も予約させていただきました（後者は後付だけどメイン）。
時間の都合で結果発表まで残れず、京都への帰路でこのブログ書いてます（ので、どこが優勝か知りません）。
3行感想
- ハッカソンでも「ユーザー体験」
- 作れる人が、一番偉い
- 地道な検証、心に響く
審査員からの質問で気になったのが
- 「このアクションのモチベーションは？」
- 「どんなユーザー体験を想定している？」
- 「こうしてみても楽しいかも」
という実際の利用イメージを前提としたコメント。
当然っちゃあ当然だけど、ハッカソンに限らず、企画っぽいことをするうえで結構抜けがちな観点かと。
で、実際動くものを見ると、ほんと感動！
どのチームもアイデアソンで見ていたので完成形は何となくイメージできたものの、やっぱり動くものを見ると、印象もだいぶ変わる。
最後にプレゼンされていた「漫才VR」というチーム。
“ラフ次元”さんという芸人さんがプランナーを努めるチームで、VRで漫才体験ができるというもの。
“ラフ次元”さんのネタがむちゃくちゃおもしろいってのもあるけれど、デモが凄かった（会場からお「お～」の声が）。
体験者はツッコミ担当。VRのボケ担当につっこむのだけれど、つっこむ台詞を三択から選び、あと胸まわりを叩くツッコミには腕の加速度を計測、頭をはたくツッコミには手首のスナップを計測し、それを採点化するなど、随所に組み込まれたエンジニア魂にも萌えました。
ほんで作れる人が一番偉い！この1週間でこれだけのプロダクトを作ったエンジニアさん、デザイナーさんはごいごいす。
あと、漫才VRのチームとは別に、“ラフ次元”さんのツッコミ担当の方も別チームで決勝に進んでいたのだけれど、この人すごい。なんと街に繰り出し250人にアンケートをとっていた。
それを動画で流しプレゼンで使用。とても説得力のあるプレゼンでした。
テンション上がった状態で書いているので適当な文章ですが、やっぱMBSハッカソンはすごいなー。来年は決勝いきたい！
審査員、ほんと豪華Σ（ﾟдﾟlll）
ネーミングが秀逸、林家pay。寄付苦手なジャパニーズでも気軽に芸人さんにおひねりフィンテック。
人気番組より。にわかな俳句ブームをしっかりキャッチ。句碑を訪れると人気の先生（なんだっけ？）からコメントがもらえる。
茶屋町をゾンビがハック。ゾンビを倒したりワクチン手に入れたり、ワクワクする体験イベント。
ロケに行ったお店を教えてくれて、道案内までしてくれるアプリ。デモでは実際に外に出てリアルタイム中継する行動力とエンタメ力。あと、取材したお店に対して、事前にプロデューサーの方は色々話しを聞いていて、貴重な情報を持っているという話しはトリビア。
ロボットが一緒にテレビを見てくれる体験を提供。ロボットむちゃかわいい。学生さんチーム。クオリティの高さにおっちゃんビビったよ(個人的には一番可能性を感じたチーム。学生さんのロボ愛すごく、適切な課題も貰っていた。審査員はすごい人達ばっかなのに、ほんと真剣に誠実にフィードバックしてくれる）
事前に250人にアンケート。アイデアも実装も行動力も兼ね備えたスーパーバランスチーム。
学生だけのチーム。賢いうえに熱い情熱。この子らが社会人になるのかと思うと、居心地の良い窓際探しちゃうよね。
素晴らしいプレゼン。素晴らしいアイデア。素晴らしい実装力でした。漫才VR。
時間の都合で帰路へ。
ハッカソンはやっぱり楽しい！
ITプロジェクトを失敗させる方法～失敗要因分析と成功への鍵～（読書メモ2：提案・受注編）
前回に引き続き、今回は「提案・受注段階での失敗」について。
この工程は「超上流」と呼ばれ、プロジェクトに失敗をもたらす大きな要因となる工程。
事業や業務の検討から要件定義まで（システム化の方向性、システム化計画、要件定義）を行います。
ここで超重要事項が 2点。
- 経営戦略とIT戦略の一致
- ユーザー企業内での合意形成
上記について、ユーザー企業（クライアント）の経営者が責任を持って積極的に関与（ユーザー企業による主体的な要件の決定・明確化）することがポイント。
本書では、失敗の要因を発注側（ユーザー企業）、受注側（ベンダー企業）それぞれで整理されている。
発注側（ユーザー企業）における失敗要因と成功への鍵
失敗要因は主に 9つ。
①経営者の関与が弱い
昨今のITシステムは経営戦略と密接なかかわりがあります。経営戦略と乖離したIT戦略は企業にとって価値を生み出すことは難しいといえます。
ここで大切なのが経営者の思いは当然ながら、そのこことに対する合意形成。思いだけ語って後は部下任せ、だと上手くいかない。
②ユーザー側に取りまとめ役が不在
昨今のプロジェクトはステークホルダーが多く複雑なため、ユーザー側にユーザー内の関係者を取りまとめ合意を形成する担当者が必要。
決裁者が席を外した瞬間に担当者が愚痴をこぼすようであれば、それはまさに修羅の道の始まりですね。。
③要件を取りまとめる技術や人材の不足
要件定義の責任はユーザー企業にあり。以下のような問題を解決しないと、しわ寄せはベンダへ。
表面的な同意をつくろうために、定めるべき仕様の決定を曖昧なままにしたり、先延ばししたりする。
調査・検討が不十分で、機能要件や非機能要件に漏れがある。
要件定義書の表現が不十分かつ曖昧で、内容が生活に伝わりづらい。
④適切なRFPを作成する技術や人材の不在
⑤組織全体が強いプレッシャーを受けている
ゆとりのない中で生まれたプロジェクトは根拠の無い楽観性によっているのでリスク対応策もまったく講じられていないことが少なくありません。
週末にブログ書けるくらいのゆとりは丁度良いのかな。
⑥組織内の上層部に政治的な争いや不安定な人間関係がある
ITプロジェクトの本質的な目的は、企業価値を高めるためにあるのですが、このような企業においては社内競争のための道具として使われてしまうためです
個人的には、二人以上の人間が集まれば政治が生まれるので、これは仕方の無いことだという解釈（政治を超越して信頼してもらえる人間になれれば一気に解決するのだけれど、、、）。
⑦独裁的な企業でボトム<ミドル>アップのフィードバックがかからない
遅れを「遅れ」と言えない雰囲気。
⑧ベンダ企業の能力を適切に評価できない
⑨ベンダに丸投げし、無理な契約条件を強いる
「超上流」工程（案件によっては外部設計も）の契約に対して請負をベンダに強いることは無理がありますし～（中略）～請負契約にしてしまうとユーザー側は「まる投げ」した感じを持ち、責任感が弱くなりますし、ベンダ側はできるだけ請け負う作業の範囲を狭めたいという意志が働きます。
協調が必要な工程で対立関係になってします。恐ろしや。
受注側（ベンダ企業）における失敗要因と成功への鍵
失敗要因は主に 6つ。
①「成功させること」ではなく「受注すること」が目的になっている
売上を上げるため、多少無理をして受注する。曖昧含みの受注なもんだから後工程で綻びがでる。開発工程（請負）で正式見積りをしても、概算見積りを超える額は認められない。結果大赤字、お客様からの信頼も失う。
という事例が、本書には書かれていました（汗）
②自分の言動が与える影響力を経営者が理解していない
影響力のある人は無邪気に発言したちゃダメ。強い人の言葉を聞くと下の人は思考停止になって、表面上の言葉面だけで動いちゃうって話し。
③問題の先送り
ユーザー企業との安易合意形成を行うために（とりあえず受注するために）利害関係の不一致を曖昧にして問題を先送りにしてしまうことがあります。
例えば、要件が確定していないにもかかわらず、5,000万円という予算の範囲内で仕様を調整するという、極めて安易な合意形成をしてしまう（って事例が書かれてた）。
④間違った顧客思考
御用聞きは顧客思考じゃないよって話し。
ITプロジェクトに関してはユーザー企業に対して単なるイエスマンになることは間違った顧客思考だと言えます。これは提案・受注段階においても同じです。ユーザー企業の仕事の出し方や契約のしかたに問題があると思えば、そこも含めて提案する必要があるといえます。ここをスムーズに乗り越えるためには、ベンダ企業に対話能力や質問する能力が必要となります。
⑤リスクに対するレビューが行われていない
見積り段階での、リスクの洗い出し、リスク分析、リスク対策の立案が必要。
これが行われない理由はいくつかあるが、「受注する」ことが目的になっているケースは、まず行われない。
⑥受注審査のルールや手順が確立されていない
成功への鍵：プロジェクト内プロジェクト「提案・受注プロジェクト」の立ち上げ
しかし、多くのベンダ関係者にとって、提案・受注活動は営業というルーティンワークですので、ユーザー企業のプロジェクトを成功させるという観点でかかわっているケースは少ないと思われます。しかし、このことがプロジェクトの失敗に影響を与えていることは否めません。すなわちベンダ企業のこの段階でのかかわり方が、プロジェクトの成功に対して少なからず影響を与えているのです。そうであるなら、この経営活動については、営業活動というベンダのルーティンワークとしてとらえるのではなく、サブ・プロジェクトとしてマネジメントする必要があります
ベンダ側のメインとなる関係者が以下をきちんと理解する必要がある。
- ユーザー企業の経営戦略やプロジェクト（システム化）の目的
- 自社にとっての目的
後者について大切なのが、「財務的視点」からの目的ではなく、「業務プロセスの視点」や「学習と成長の視点」に関する目的を設定すること。
自分とこの話し（問題先送りソリューション）
最後にちっちゃな体験談を。
プロジェクトも進み、「不安なことがあればこれが最後の言うチャンス」というMTGを開いた時の話し。
「素直にゲロっちゃいなよ！」というメッセージをこめて、閉じられた空間で『ゲロルシュタイナー』という炭酸水を用意してMTGをしたことがあった。
上司にはスベリ扱いされたものの（涙）、多少みんなの舌は滑らかになっていたのではと自画自賛（アイデアをくれたＹ井氏に感謝）。
ITプロジェクトを失敗させる方法～失敗要因分析と成功への鍵～（読書メモ1）
『ITプロジェクトを失敗させる方法～失敗要因分析と成功への鍵～』
2008年発行と少し古い本ですが、本書によるとプロジェクトの半数以上が失敗しているとか。
ITプロジェクトの成功率に関するいくつかの調査結果を見ると、その成功率は30％～50％という結果が出ています。つまり、ITプロジェクトの半数以上が失敗に終わっているということになります。
数字の出所が気になるところですが、興味深いテーマ。
目次は以下の通り。今回は「1.」の議事メモ。
- ITプロジェクトは、なぜ失敗するのか
- 提案・受注段階での失敗
- 立ち上げ・計画段階での失敗
- 実行段階での失敗
- 終了段階での失敗
失敗の種類
まずは「失敗」の定義から。以下いずれかに当てはまるものは失敗（残念）。
- 納期遅れ
- 予算超過
- 品質粗悪
- 利用されず廃棄
- プロジェクトの中止
- 関係者の疲弊
「4.」については、爆速でβ版をリリースして高速PDCAを回す過程の話であれば失敗ではないだろうと思わなくもないけれど、規模によっては確かに「失敗」と定義されて然り。
失敗要因分析の4つの切り口
プロジェクトの前提条件。これを捉えたうえで「どう成功を目指すか」なんだろうなと。
①ITプロジェクトの特徴
- 結局は「人間業」であること。能力や体調、モチベーションが多分に影響する。
- （ハンドリングが難しいけれど）仕様の曖昧性を許容する必要がある（創造的な作業であるため走りながら考える）。 etc
ゼロからイチを生み出す、ある種 宿命のようなものだと解釈（「仕様の曖昧性を許容」は個人的には大きな気付き）。
②ITプロジェクトを取り巻く環境
プロジェクト＝茨の道としか捉えられない（笑）
- コンピューター・システムが利用される領域が広がり、要求が多様化。要求の把握が困難に。
- プロジェクトが企業の存亡をかけたものになり、外部環境の変化とスピードにあわせて仕様を変える必要がある。
- 効率化と分業化の難しさ。そうせざるを得ないのだけれど、「問題やリスクが共有されない」「作業分担の隙間で発生する作業を誰も引き受けない」などの問題が出がち。etc
③ステークホルダー（利害関係者）の影響
顧客（ユーザー）、ベンダー、プロジェクトマネージャー、プロジェクトチーム・メンバー、全ステークホルダーとの協業体制が必須。無関心や丸投げはダメ絶対。
④プロジェクトの段階
大きく以下のフェーズに分かれる。
- 提案・受注段階
- 立ち上げ・計画段階
- 実行段階
- 終了段階
それぞれの分析は、また別記事で。
チームのことだけ、考えた。（読書メモ）
ひとりでできる仕事なんて無い。
今まで経験した仕事は、チーム単位で動くケースがほとんど。
世の流れもそうなっていると聞いた（「昔はエースにぶら下がっていればよかったけれど、これからは集合知で戦う時代」by UX KANSAI浅野先生）
働くうえで「チーム」のことは無視できなさそう。
まだビジネスパーソンを辞めるつもりはないので、「チーム」について知るべく知人に教えてもらった本を読んだ。
読後の感想は「『チーム』はあてがわれるものではなく、全員が『チーム』になるための努力をする必要がある」。
当たり前すぎる感想に見えるけれど、自分自身の中で「チーム」の意味が捉えられたことが、とても大きな収穫だった。
チームとは
のっけから本書ではなく、別からの引用（汗）。
ゼミの活動を効率的にするにはどうすればいい？──チーム運営に必要な基礎を学ぶ「チームワーク創造メソッド」 | ベストチーム・オブ・ザ・イヤー
グループというとジャニーズのイメージ。ジャニーさんによって集められたっていう受け身な感じというか。チームは目的意識を持って、自分の意志で集まった人たちというイメージがあります。
「確かに、スポーツは勝利することを目的として集まっているから、“サッカーグループ”とか“野球グループ”とは言いませんよね」と話し、「グループは、家族や地域社会といった『集団』のことを言いますが、『チーム』は、企業や部活動のような『目的を達成するための集団』のことを言います。」
目的あってのチームだと理解。
続いて本書から。
こちらには「チーム」の成立条件が定義されています。
チームには「共通のビジョン」「チームの構成員」「役割分担」「仕事の連携」の4要素が必要
前出のブログの「目的」もそうだけど、意外と「ビジョン」などの大前提が抜けがちという印象。
というのも、社内では配属によって、社外では偶然居合わせた人たちで「チーム」が組まれる。そのため、大前提である「目的」や「ビジョン」がなくてもチームっぽく立ち居振る舞える（でも、実はこの時点では「チーム」ではなく、ただの人の集まり）。
目指すものをの共通認識を持つ。まずはそれがチームビルディングの第一歩か。
チームワークとは
チームでワークすること。つまり「仲間と働くこと」であり、それには良し悪しがある。
チームワークの良し悪しを決めるのは、「効果」「効率」「満足」「学習」の4要素であること。
それまで私は、チームワークが良い状態とは、単純に「成果物が多い」状態だと考えていた。しかし、がむしゃらに働いて成果を上げるだけの非効率なチームが、果たしてチームワークが良いと言えるのか。メンバーの満足度が低くて解散寸前なのにチームワークが良いと言えるのか。学びが少なく、メンバーの成長につながっていないのに、チームワークが良いといえるのか。
また、前出のブログによると、
チームワークとは、チームのメンバーが目標（理想）を達成するために役割を分担し協働すること。
（一般的に）会社では自分の意志ではなく配属によってチームに属することが多い。
それなのに、成果の上がるチームとそうでないチームが存在する。
メンバーの能力云々という観点はあるものの、以下のように同じ人でもチームが変わるとダメになるという調査結果や、チームワークには『心理的安全性』が必要だという話しもある。
ありきたりの表現だけど、メンバー全員が同じ方向を向き、互いににホスピタリティを持ち合いながら、一人ひとりが活き活きとしているチームこそが、チームワークを良くできるのだろう。
大切なのは「多様性」
サイボウズでは「100人100通り」の働き方ができる。一人ひとりの個性は違うのだから、それを受け入れる「多様性」が重要で、それを大切にすることでチームワークが上がる。
社員一人ひとりにすでに「多様性」が存在しているので、それを受け入れるのが先決だと。
今、目の前にいる従業員がそもそも一人ひとりまったく違う存在だと考え、彼らの個性を制限している障壁を取り除いていく。すでに社員は多様であり、それを一律的な規則で働かせてるのをやめるだけである。
以前は受け入れられなかった人を採用し、活躍の場所を作れるようになる。言葉としては、ダイバーシティよりもインクルージョン（包括性、一体性）に近い。個性を受け入れる力だ。
多様性ある組織に必要な2つのこと
ここまで読んでると、チームワークを良くするための取り組みは組織側だけのように感じてしますが、そうではない。
個々人でも大切にすべき2つのことがある。
「公明正大」
「嘘をつかない」ということ。自分とは違う個性をもった人と協業するのだけら、せめて正直に。嘘つかれるとややこしい。
似た言葉に「誠実」があるが、そうではない。「誠実」は人にとって捉え方が異なり、曖昧さが残る。一方で「嘘をやめよう」は捉え方のブレは少なく、全員で共通認識を持てる。
「自立」
自分で選択し、自分で責任を取る覚悟を持つ。言い換えると、「人のせいにしない」。
自分の理想をきちんと言語化し、周囲に伝える。自立を実現するためには「質問責任」と「説明責任」を果たす必要がある。
質問責任とは、自分が気になったことを質問する責任であり、自分の理想を伝える責任であり、その結果、自分の理想が叶わなかったとしても受け入れる責任である。
説明責任とは、自分が行った意思決定について説明する責任であり、他のメンバーからの質問に応える責任である。
冒頭で書いたとおり、チームは会社や上司があてがってくれるものではない。参加しているメンバー一人ひとりも、当然役割を担っている。
最後に（「人間は理想に向かって行動する」）
チームやチームワークから書きたかったので後回しにしましたが、本では最初の方に書かれている、青野氏がたどり着いたたった一つの経営の基本法則について。
「理想」とは、その人が望んでいる未来だ。すべての人は、自分が望んでいる未来に向かって行動する。
なぜ社員が辞めるのか。それは、辞めることで理想を実現したいからだ。
その理想を聞き出し、実現するための課題を考え、それを遂行していけばいい。課題を遂行しても実現できないのであれば、あきらめてもらうしかない。不満を口にする社員に対し、感情的に対応する必要はまったくない。
この法則に気付いたおかげで、サイボウズに一体感がない原因も理解できるようになった。サイボウズには共通の理想がないのだ。従業員がそれぞれバラバラの理想を持ち、バラバラに活動しているのだ。
このことに気付き、青野氏は全社共通の理想を決めることから始めます。
本書はサイボウズ創業当初から現在の遍歴の中で、どうやって今の組織を作り上げてきたかをトレースするもの。大きくは、以下の流れで会社を立ち上げ（建て直し）ます。
- 組織のあり方定義
- 個人のあり方定義
- 物事の進め方、議論・検討の仕方のフレームワーク決め
- 意思決定フローの整備
- 個々人のモチベーションアップメソッドの確立
- 評価制度の整備
個人的な発見は、「5.」のモチベーションの課題があった場合、解決策として思いつくのは「6.」の評価制度。でも、そうではなくて、目を向けるのはもっと上位のことだということ（「1.」や「2.」まで遡って、組織と個人の理想時点でミスマッチが起きている場合、それ以降のことに着手しても、根本的な解決には至らない）。
前述のチームの成立条件を見ても確かにそうだなと。
自分が属している人の集まりは「チーム」になれているのか。
また、自分自身が「チーム」を作るアプローチをしているのか。考えさせられる本でした。
よいサービス・製品のための、UXデザインの考え方
2/10(金)午後に半休をいただいて大阪へ。「UXデザイン」を学ぶべくこちらのセミナーに参加。
セミナーは3部構成。
気付き、発見、得られたことは3つ。
- 「答えが無い」という事実。このことをちゃんと捉える重要性
- 答えはないけど、ビジネスにおいては成果を出せばそれが正解
そして最後に
- 私が、UX（デザイン）を「打出の小槌」として捉えていたこと
モノからコトへ。機能に価値があるとする「グッズ・ドミナント・ロジック」から、体験に価値があるとする「サービス・ドミナント・システム」へ。コトは顧客に提供されるもの。モノはコトの構成要素。
詳細説明は、他人様のブログを拝借。。。
さらにグッズ・ドミナント・ロジックには問題があります。まず、私たちが物を買うのは、物自体がほしいのでありません。私たちがほしがっているのは、物を消費・使用することで得られる便益（ベネフィット）だったり、ブランド・セルフイメージの向上・社会的なつながりなど目に見えないものだったり、体験・経験だからです。
企業と顧客がそれぞれのリソースを活用して、価値が生まれます。つまり、価値は一方的に提供されるのではなく、共創されるのでした。これを「価値共創」といいます。そして、共創される価値は受益者（顧客）によってそれぞれ違うものになります。なぜなら、顧客によってリソース・身を置く環境などが異なるからです。共創される価値は「文脈価値」と呼ばれます。
サービスを考えるうえでコンテクストが重要。ただ、ユーザーごとにコンテクストが違う。
例えば、ランチ。一人だとコンビニの300円くらいのサラダとか。でも、友達と一緒なら1,500円のランチもいく。
この「複雑なこと」を捉えるのがとても重要
※理解を深めるために。少し古い記事ですが「サービス・ドミナント・ロジック」の事例（あとで読む←読んでないんかい）
「サービス・ドミナント・ロジック観点のビジネスモデル」│株式会社イー･エージェンシー
「知らんがな」（※「調査が重要」の意）
ユーザーの複雑なコンテクストを捉えなきゃなんないので、ぱっと出のアイデアとかどーでもいい。
何につけ「調査」が必要。しかも定性的な質的調査。大きく 3つ。
- 社会生活への参加：参与観察
- 対象社会の生活の直接観察：オブザベーション
- 社会生活に関する聞き取り：エスノグラフィ
エスノグラフィについては浅野先生のブログを拝借。。。
UX 関西 #02 エスノグラフィ（前編フィールドワーク） | 経験デザイン研究所
私は親子でお弁当を食べる人々を見に来た。
まずは写真を撮るのでは無くて、じっくり観察して「その場のルール」を見つける
顕著な例をひたすら撮るのでは無くて「そのルールが正しいのか？」問いを持って観察しよう。
視ながら観察の精緻化を行うのだ。
そこで新しい「発見」があるかもしれない。
おお、みんな同じ弁当を食ってる。
観察が終了したら、分析は帰ってからやる。
まずは、バイアスがかかるので現場では分析をしない。
ただただ観察する「エスノグラフィ」。対してモノを触ってもらいながら質問しまくる「デプスインタビュー」（リズ・サンダースのクリエイティブキットとか）。
※デプスインタビューの説明ではありませんが、とても気づきの多い記事だったので、インフォバーン井登氏の記事を記載させていただきます。
インタビューの全体像は、、、またもや浅野先生のブログを拝借。。。
半構造化インタビューと非構造化インタビュー | 経験デザイン研究所
調査あるある
『トライアンギュレーション（方法論的複眼）』が必要だよって話し。
調査をしても、例えば上司やクライアントに「でもそれって特定の人だけの話しだよね？」って一蹴されるあるある。
これは上司やクライアントの理解が良くないのではなく、データの出し方が下手なだけだと。
大事なのは『トライアンギュレーション（方法論的複眼）』前出の3つの方法を駆使して、複数の視点が提示できれば相手も納得できる。
不動産の営業さんはニーズをうまく引き出す
ユーザーに「何が欲しいですか」って聞くのは愚問だった話し。
自分の住みたいところを言語化できる人はいない。
例えば引っ越し前と似た雰囲気に住みたいと思っている人に対して、適当な場所に連れていく。
そこでの反応（例えば「ん～、、、もうちょっと静かな方がいいなぁ」とか）を見て、いくつかの場所に連れていって、3回目くらいで当てると。
クックパッドでの取り組み
どこまで書いていいのか分からないのでちょろっとだけ。倉光さんのお話しで印象的だったキーワードをピックアップ
「UX」という言葉を使わない
UXって言っちゃうと具体性がなくなるので、「料理する人の、どんな料理体験？」「何に困っている？何があれば？どう解決する？」ということを具体的に言語化するのが大切だと。
UXデザインにおいてはユーザーを知ることが大前提であること、ユーザーは自分のニーズを言語化できないのでそれをしっかり捉えること、さらにそれをきちんと共有すること。
いろいろ大切な要素が盛り込まれた言葉だな～。
ユーザーの言うことは聞かない
、、、は言い過ぎですが、例えば「使いにくい」というユーザーについて、よくよく調査してみると、そもそも利用目的・求めるものが違ったと。
ついついユーザーの声に縋っちゃいたくなりますが、ユーザーの声を、（複数の視点をもったうえで）どう解釈するのかが大切だなと感じました。
今後生き残る人材
ラーニグバーの中で「UXデザインを学ぶうえで適切はありますか？」という質問が。
いくつかあったのですが（気になった人は、UX KANSAIにいけばいいw）、その中でも刺さったのが「問いを立てる能力のある人」。
例えば、プロジェクトなどでゴールが設定されてた場合、そのゴールを疑う人。なぜなぜ？を繰り返す人。
ほなこのへんで
メモを見なが箇条書きしてたら、結局冒頭の気付きについては触れたり触れなかったり。まぁ個人メモだしいっか。
