パパパパッカソンに参加した話し（会場とか運営の方とか良かったよって話し）
関西初上陸『パパパパッカソン』、パはパ・リーグのパ。「パ・リーグと遊ぶ」ためのハッカソン
主催は『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）、その中でも刺さったのが「問いを立てる能力のある人」。
例えば、プロジェクトなどでゴールが設定されてた場合、そのゴールを疑う人。なぜなぜ？を繰り返す人。
ほなこのへんで
メモを見なが箇条書きしてたら、結局冒頭の気付きについては触れたり触れなかったり。まぁ個人メモだしいっか。
仕事の報酬とは何か～人間成長をめざして～（読書メモ）
社会人になって16年。「何のために仕事をしているのか？」と聞かれると、「自分のことを必要だと思ってもらい続けるため」と答えてる。
自分なりにはフラットな返答だけど、何となくネガティブに受け取れなくもない。
もちょっと整理したいなと思いふと手に取った本の読書メモ。
書によると、仕事の報酬とは、大きくは「目に見えない報酬」。これは「収入」や「役職」といった目に見えるものではない。また、これは決して失われることのない尊い報酬。
具体的には
- 能力
- 仕事
- 成長
この3つのこと。
それぞれの説明は、以下の通り。
「能力」
一生懸命に仕事をすると、職業人としての「能力」が身に付く。
良い仕事を残そうとする努力を通じて、職業人としての「能力」が磨かれる。
「能力」って言葉は、何となく先天的な印象を受けるけれど、技術のように鍛錬で身に付き、磨かれるものという解釈。
このあたりは、「GRIT」に通じるものがあるなと（愚直にやり続けるのが能力。一方で能力のある人を神格化して努力をしないのはクソだ的な）
「仕事」
一生懸命に仕事をすると、良い「仕事」を残すことができる。
職業人としての能力を磨くことによって、優れた「仕事」を残すことができる。
なんとも禅問答のような。。。
「成長」
一生懸命に仕事をすると、人間として「成長」できる。
実感しやすいのは「仕事」なのかな。たとえば去年と今の自分で、どんな仕事が任されているのかが、報酬のものさしになるのかも。
あらためて再整理
上記3つも含め、報酬には2種類ある｡
1つめは、「自ら求めて得るべき報酬」（「能力」「仕事」「成長」）
2つめは、「結果として与えられる報酬」（「収入」「役職」）
書曰く、収入や役職といった「結果として与えられる報酬」を自ら求めて得ようとするからオカシくなると。
なるほどなるほど。確かに、結果として与えられるものを欲しがったり、コントロールしにいくアプローチをとるのは、心も体も疲弊しそうだ。
自分でコントロールできる領域。適性に苦労しながら「得よう」とすべき領域。それを見極めることが大切っぽい。
「能力」について、もう少し詳しく
我々は、「腕を磨く」ということそのものに、無条件の「喜び」を感じるからです。
一昔前、我が国の企業には、その喜びがありました。
朝から晩まで一生懸命に働き、残業、残業で仕事をしていると、どんどん自分の能力が高まっていく、という喜びがあった。
そして、職場には、その「目に見えない報酬」を「報酬」として実感させてくれる瞬間があった。何か。上司の一言です。
今はこの「腕を磨く」ということが、自分の商品価値を高めるための手段になっているので、このことが報酬と感じられ辛いのだと。
ある種、ブラック企業臭がしなくもないけれど、心理的に満たされることの重要性については、そうだよなと。
また、能力を磨くのは時間かかるので、これを「自ら求めて」得ようとすると、性急になって逆に能力が磨かれないよ、とも。
確かに。これは個人に対しても言えることだし、企業やマネジメント側に対しても、気付きを与えてくれる指摘だと感じた次第。
このことに関して、刺さった言葉を引用。
一流のプロフェッショナルは、するべき努力を、愚直なほどに、している。
彼らは、決して、「近道」や「広き門」など信じていない。
能力を磨くうえでのコツは？
それは「師匠」を見つけること。師匠を見つけ、「呼吸」（「リズム感」と「バランス感覚」）、「着眼」（経験から反省するための視点のようなもの（と解釈した））、「心得」の3つを学ぶべし。
ばっくりとは、やっぱり自分の中に無いものは他人を頼って身に付ける。その際、自分の中の何に課題意識を持ち、どうアプローチするかを学ぶ。みたいなことかと理解。
ちなみに、師匠を探す際に大切なのは「一芸」という視点。誰もが一芸に秀でているので、周囲は師匠だらけだよって話し。
「仕事」について、もう少し詳しく
我々が、仕事を通じて創り上げ、顧客に提供しているのは、単なる「商品」ではない。それは「作品」である。
どうすれば「作品」を残すことができるのか。
それは、前述した「腕を磨く」だけでは成し得ない。
我々が仕事を通じて残すものは、実は「作品」ではありません。
「共同作品」です。
ひとりじゃできない。周囲と創り上げていくってことですね。
では、その「共同作品」を創り出すためには、何が求められるか。
「共感」です。
ばっくりとは、仕事とは集合知であり、いろいろな人の「知識」や「知恵」を集め、新しい「知識」や「知恵」を生み出すことであると。
そうだよなーと。共感しまくり。
「成長」について、もう少し詳しく
「成長」は、ある意味で「最高の報酬」である、と。
「人間としての成長」とは何か。
それを、一言で述べておきましょう。
「心の世界に処す力」
？（むむ？）
ここで言う「力」には2つあって、1つは「心の世界を感じる力」、1つは「心の世界に働きかける力」。
？？（むむむむむ？？）
ここで言う「心の世界には」3つあると。
- 自分の心の世界
- 相手の心の世界
- 人間集団の心の世界
さらに。それれらの世界それぞれに「表面意識の世界」と「無意識の世界」がある。
例えば、「腕を磨こう」と努力する。しかし、それなりに努力しているつもりでも、少しも腕が磨かれない時がある。
この時、自分の心の中を見つめると、心の奥深くに「早く手軽に腕を磨きたい」という安易な気持ちがあることに気付く。
この安易な気持ちが、地道な努力を怠らせていることに気付く。
この気付きがあった時に、成長を遂げることができると。
また、自分は腕が上がったという慢心が生まれたり、良き仕事がしたいという想いが自己のエゴに依る「達成願望」から発せられた時（あるいは、本当は自分がコミットしていないビジョンを周囲に語るような時）、相手の共感が得られなかったり、仲間の心に火がつかず、上手くいかない局面に立たされることがある。
こうした、自分・相手・仲間の無意識の世界を感じる力。
仕事で問題に突き当たる時、その悩みや苦しみ、葛藤を通じて、「心の世界を感じる力」を身に付ける。
この力を身に付けた時に実感するのが、仲間の心の世界は、自分の心の世界の「鏡」であるということ。
自分が心を閉ざすならば、必ず、仲間も心を閉ざす。
自分が仲間に感謝するとき、なぜか、仲間の感謝が伝わってくる。
なので、自分の心の世界を変えるアプローチをとれば、周囲も変わる。
このことは、前述した2つめの力「心の世界に働きかける力」のことであり、心の世界を感じられたならば、2つめの力を得ることも決して難しくないと。
他にも、「心の生態系」という概念が書かれていて、ばっくりとは「チームビルディング」のようなこと。マネージャー次第でチームの生産性やモチベーションが変わる。みたいな話し、などなど。
ボリューム的に読みやすいけれど、だいぶ思想寄りの語り口調で好き嫌いが分かれるかも。
また、2008年に書かれた少し古い本ということもあり、「今の風潮はお金だよね」みたいな決めな雰囲気もあり、ちょっと違和感を感じる箇所もたまにあるけれど、書かれている内容は、ここ最近（僕が見る範囲の）の本と本質的には同じこととが書かれていて、いつの時代も悩みは一緒なのだな。
最初の「何のために仕事をするのか？」の返答、「自分のことを必要だと思ってもらうため」について。
これには能力が必要だし、すなわち仕事をいただき続けることだし、成長し続けないとこのことは成し得ない。何となく整理の視点をいただけた気がしました。
