【建設予定地】『Rakuten Technology Conference 2012 - System Development, Culture and "Shikatanai" By Masa Nakamura』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、Masa Nakamura氏の講演『System Development, Culture and "Shikatanai"』のノートです。


※開催一ヵ月後を目処に公開致します。

【建設予定地】『Rakuten Technology Conference 2012 - Exploring User Wish Through Mindmapping By Kenji Hiranabe』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、平鍋健児氏の講演『Exploring User Wish Through Mindmapping』のノートです。

※開催一ヵ月後を目処に公開致します。

【建設予定地】『Rakuten Technology Conference 2012 - Design Thinking By Jeff Patton』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、Jeff Patton氏の講演『Design Thinking』のノートです。

※開催一ヵ月後を目処に公開致します。

『Jeff Pattonと平鍋健児が語る、価値創出のプロセス「ユーザーストーリーマッピング」』ノート

2012/10/17に開催された『Jeff Pattonと平鍋健児が語る、価値創出のプロセス「ユーザーストーリーマッピング」』のノートです。



◆開催概要

◇登壇者
・Jeff Patton氏
・平鍋健児氏

◇会場提供
・楽天

◇共催
・アギレルゴコンサルティング

◇提供
・永和システムマネジメント

◇本日のアジェンダ
・Jeff Patton Lecture(50min)
・Conversation! Jeff & Kenji(60min)


◆はじめに

◇Jeff Patton氏
・デザインとソフトウェアにはただ1つ正しい道は存在しないと思っていて、活動している。
　→20年以上にわたって活動
・ユーザーストーリーマッピングの考案者
　→2001年から12年以上やっている

◇平鍋健児氏
・20年以上オブジェクト指向ソフトウェア開発の経験
・10年以上アジャイルソフトウェア開発の経験
・チェンジビジョンでastahを開発して提供
・「Jeffとは長い付き合い。今日は楽しみにしている」

◇Jeff Patton氏の経歴と今日の話について
・アジャイル界ではアジャイルユーザエクスペリエンスの人だと認識されている
・80年代、美術学校に通っていたことがあった
　→ソフトウェア開発業界にいったらユーザインタフェースのデザインの仕事を任された
・ストーリーマッピングの実践について話をしている
　→12年前(2001年)から
・ソフトウェアを理解するための有意なやり方 = ストーリー
・ストーリーマップの話をする為には、まずユーザストーリーを理解してもらう必要がある


◆ユーザーストーリーの話

◇導入
・2000年、サンフランシスコでKent Beckとプロジェクト
　→xpを教えてもらった
・xpでは伝統的な要求は使わない
　→ストーリーを使う
・Kentは伝統的なソフトウェア開発の大きな問題に対してストーリーを使おうとした
　→うまく書かれていない仕様はソフトウェア開発を阻害する
　→→ストーリーは効果的にコミュニケーションするためのもの

◇ケーキの話
・cakeWrecksというウェブサイト
　→ケーキに書かれた文字を写真にしたもの
・間違った指示がどれだけ面白いケーキを作るか、というサイト
・ケーキに書いてある文字の例
　→best wishes suzanne / under neat that / we will miss you
　　（underneath = 下線を引いてという指示）
　→Congraturations / Three Times
　　（3回繰り返して）
　→I want Sprinkles
　　（カラフルなトッピングをかけて）
→Nuts Allergy / Happy Birthday Peter
　　（ナッツアレルギーです）
→Leave Blank
　　（何も書かないで）
・ケーキの間違いは面白い

◇面白いではすまないものもある
・Mars Climate Orbiterという火星探査機
　→火星の軌道にのらずに爆発
・ポンドとメートルの単位換算をしなかったという失敗
　→コミュニケーションミスが原因で起こった

◇このような問題についてKent Beckは考えた
・解決策はシンプル
　→「さあ、ドキュメントを書くことはやめて、話すことから始めよう」

◇ストーリーのアイデアはシンプル
・欲しいソフトウェアのことを何かカードに書く
　→何を書いてもよい
・それを見て話しあう(conversation)
　→どんなソフトウェアが必要か正確に決められる
・"We should get together and I want to hear your story"
・ストーリーをカードに書く
　→互いに言い合うため
・書くのではなく語ろう
・アイデアはシンプル
　→だからといって簡単なわけではない

◇ストーリーのフローはシンプル
・カードには何が書いてあってもいい
1. 会話する
2. 何か気がついたら書く
3. それを説明する
4. 聞いた人は相手が欲しいものをイメージする
5. そして質問する
　→会話は質問すること
6. ユーザーとデベロッパーは理解を共有する
・"何を作るか？"を共有するということ
　→開発者が独自に想像してものを作るのとは全く異なる
・共通の理解を通じて、何が欲しいのかの理解に達する
　→ユーザー「何を作るかについて詳細に話すことはできない。でも何が欲しいのかはある」
　→デベロッパー「何が欲しいかは分からない。でも作り方を詳細に話すことはできる」

◇ストーリーのシンプルなアイデア
・動かないものを書いたり描いたりすることはしない
→Conversationする
・アジャイルプロセスでは少ないドキュメントで行う
　→Conversationして少しの絵や単語を書く
　→→そうして「何を作るのか？」という理解を促進する

◇プロセスの始まり
1. カードによるConversation
2. Confirmation
3. そしてカードを書く
　→作るものの詳細について沢山ディスカッションする
・Ron Jeffriesの3C
　→『XPエクストリーム・プログラミング導入編』に書いてある
　→→Card
　→→Conversation
　→→Confirmation

◇開発の流れはこんな感じ
1. ソフトを作り始める
2. 話しあった2人以外も見る
3. それを見てもっと話し合いこと・疑問や答えがでてくる
4. 完全じゃないことや変えたいことが出てくる
5. それをカードに書く

◇アリスター・コーバーンが言っていたこと
・「ストーリーは3枚書け」
　1枚目 : 必要なもの
　2枚目 : 1枚目をFIX（直す）するもの
　3枚目 : もう一回FIXするためのもの
　→3回書かないとストーリーにはならないということ

◇今までのソフトウェア開発とアジャイルなソフトウェア開発の違い
1. ソフトウェアを作る
2. 後から変更の必要がわかる
　→今まで：悪い要求で失敗とされる
　→アジャイル：学びとされる

◇Kent Beckが書いたこと
・「ソフトウェア開発にもっとも大きなダメージを与える最悪の単語は"requirement"である」
　・だから話をして学び、作るべきソフトウェアについて書く、というサイクルを行う
　→問題に対するパーソナル(?)な解決策である

◇ストーリーの壁
・Conversationは2人で話しをするもの
　→「私が必要なもの」
　→「私が作れるもの」
・でも周りにはたくさんのステークホルダーがいる
　→それぞれの観点から話しをする
　→→「リターンはどのくらい？」
　→→「ビジネスの何を改善する？」
　→→「進捗はどうなっている？」
・実際にはたくさんのステークホルダーがいる

◇カードの最初のアイデア
・「カードは会話のきっかけ」
　→詳しく書くのではなく、会話を発生させるもの
　→話して出てきた詳細はカードの裏に書く
　→→でもステークホルダーがたくさんいると裏側ではすまない

◇カードは「何について話すか？」のためのもの
・図書館にある"カード目録"を考える
　→本自体は別のところにある
・カードは会話を引き出すためのもの
・沢山の人との会話の結果はカードに書けない
　→wiki, sharepointでもオンラインのドキュメンテーションに書く
　→→少し複雑。当初のものよりちょっと悪くなってしまった

◇ストーリーの大きさ
・「大きさ」はいつでも大切
・ユーザーは気に入ったものを書く
　→ユーザーに大きさは関係ない
　→開発者は正確な大きさを知りたがる
　→→イテレーションに収まるよう細かくする
・ビジネスリーダーは、ビジネスの効果が分かるものを好む
　→ロードアップにフィットするサイズになる
・ストーリーは1つのサイズで書けるものではない
　→それぞれのステークホルダーにナチュラルなサイズがある
　→それぞれに必要なサイズが違うということ

◇みんなストーリーが嫌い
・開発者なら開発できる、QAならテストなど、それぞれ自分の欲しがる形がある
　→専門家にはそれぞれのやり方があるということ
　→それぞれ必要なサイズが違う
・ストーリーの登場によって皆が同じ話しができるようになった
　→ストーリーは、誰から見ても『自分が欲しいものとはちょっと異なる』ということ
　→→皆に対して不完全になっている

◇ストーリーの大きさと価値
・ストーリーはそれぞれ価値がないといけない
　→でも1つ1つは出荷可能ではないし完全でもない
・集まって1つになって、デリバリ可能となる
・ユーザーストーリーはより小さいストーリーに分割される
　→全体になってはじめて1つの価値があるということ
・より上位の視点からユーザストーリーを見る手法が必要だということ
　
◇ストーリーと開発サイクル
1. 最初は大きな機能の話
2. 沢山の会話をして小さいパーツとしてのストーリに分解する
　→ユーザストーリをパイプライン(sprint)を通れるくらいにシュリンクさせる
3. 優先順位をつける「これは最初のリリース」「これは次」
　→ここでUIや受け入れテストなどの細かい話がでてくる
4. ここから開発者が出てきて「まだ大きい。イテレーションに入らない」
　→もっと細かくする
5. 小さいストーリーが完了する
　→価値のあるパーツ（ユーザに見せて正しさを検証できるくらいのもの）ができる
　→→でも、チェックボックスが付いた、なんてものをユーザは見たくない
6. ユーザの目からみて価値のある大きさにまとめてから、見てもらう
　→それを一つ一つ検証(validate)
7. 最後の大きな1つのソフトウェアになる

◇ストーリー = 岩みたいなもの
・割ると沢山の岩になる
→でも頻繁には砕かない

◇ゲーム : アステロイド
・ルール
0. 宇宙を岩が飛んでいる
1. 岩を打つと砕けてあちこちに飛んでいく
2. 砕けた岩を打つと、それもくだけて飛んでいく
3. 何回か細かくすると石は消滅する
4. そうやって全ての石（岩）を消滅させればおｋ
5. 岩にぶつかるとゲームオーバー
・このゲームでは、大きい石を何回も打つのは悪いやり方
　→小さい石がたくさんでてきてすぐゲームオーバー
　→大きなストーリを早いうちに細かくくだくのも同じ

◇ストーリーは素晴らしい発明
・Conversationで共通の理解をするためのもの
・書類は間違いがち

◇ソフトウェア開発でもっとも難しいもの
・「そもそも何が作りたいのか」ということを理解すること
　→フレデリック・ブルックス（人月の神話の人）が言っていた
・コミュニケーションは難しいがそれ以上
・「何を作るか」と言うことは「人が欲しいもの」「作るものが何なのか」を理解すること
　→それが一番難しいこと


◆ユーザーストーリーマッピングの話

◇ユーザーストーリーマップとは何か

左右：Workflow ワークフロー
上下：Details 詳細やオプションとなるストーリー



・構造上の特徴は2つ
1. 左右はユーザの視点からみた物語
2. 上下はバリエーションやオプション
・一番上が一番大きな岩
　→話の背骨になっている
　→細かいものはその石に紐付けられて下にいる
・上（ユーザのアクティビティ）
　→タスク（背骨）をいくつかまとめたもの
・書いて動かしているうちに会話が生まれる
　→それが重要
・マップができるということは会話ができたということ
　→マップは会話の足跡
・マップにシールでタグ付けすることもできる
　→リスクに対する評価や、やる/やらないなど

◇ユーザーがストーリーマップから見るもの
・「この機能は2日」とかそんなものは見ない
・ユーザーはもっと大きなストーリーの流れを見る
　→使っている様子が分かるように書く
　→→そこから会話が生まれ、Detailsに新たなカードが加わっていく

◇ストーリマップはシンプルさを保っている
・ストーリマップはとてもシンプル
　→そこに何を書いてもいい
・「UMLにして他の情報かけるようにしろ」という人もいる
　→そうはしない。そうしてシンプルさを保っている

◇ストーリーのスライス
・基準となる線を用意し、ストーリーを上下にスライスする
　→スライスにカードを割り当てその中でカードを動かし、各スライスのゴールを決める
1. 機能単位で分割線を引き（スライスの作成）、ストーリーを各スライスに割り当てていく
2. 重要な機能のスライスからこなす
（3. スライスが完了すれば、ユーザに価値のある大きさで提供ができる）

青い線がスライス


◇ユーザーストーリーマッピングとは何か？
・ストーリーはバラバラになるので、以下の難しいことをやる必要が生じる
　→全体を考える
　→小さいものを組み合わせて1つにする
　→→これは難しい
・これも難しい
　→全体としてどういう機能があるか
　→細かいアイテムってどういう価値があるものなの？
　→→バックログアイテムを細かく見ていくときにここで苦労する
・解決策としてストーリマッピングを提唱している

◇世界中から写真を送ってもらっている
・いろいろな世界から「クールだろ」と写真が送られてくる
・本どおりではなく、それぞれにあったやり方でやっている

◇平鍋さんの気付き
・ケントベックが提唱していたストーリーとは
　→話すこと
　→「As a xxx In order to...」というフォーマットのことではない（それが悪いわけではない）
・アジャイルに見せるときに、ビジュアルが持っている強さ　






Jeff Patton様, 平鍋健児様, 永和システムマネジメント様, ・アギレルゴコンサルティング様, 楽天様、ありがとうございました。

【チラシの裏】【201203】勉強会に参加するようになって1ヵ月後に書いたメモ

　過去メモを掘り返したら出てきた。2012/03辺りのもの。書いた細かい日時は残ってない。

　メモなのでまとまりがなく、全体としてふわっとした仕上がりになっている。「勉強会からどのように/何について影響を受けるか？」という点について思ったことを表現すべく言葉を繋いでいるのは自分でもなんとなく分かる。

　いろいろと思うところや、突っ込みを入れたい箇所などあるが、「半年前の自分というのは、半分くらいは他人みたいなもの」と考えれば、まあ別にいいか…


～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

　いろいろと考える概念や方法論などがあり、それらを学んだりしているわけだが　…自分の中の大局感がなくなってる感じがしない？

　何かについて考えているとき、1つ粒度を上げて考えて見ると、 物事ってもっと自由に　…というか、1つ下の粒度で見てるときより明らかに手札が沢山あることに気が付いたりするんだけど、今の自分って見てる粒度が若干小さすぎるんじゃない？

　「こういう技法があって、それはこういう考え方で、こういう手順で」　…というのをただただ積み重ねても、よいソフトウェアにはならないような気がする。もっと根底にある大きな価値観みたいなものを常に意識して、何か判断に迷うようなことがあった場合にそこに立ち返ることができなければ本当の意味でよいソフトウェアを作るところには至らないというか。

　ただただ良い方法論のかたまりだけ、見たいな人間になっても、それでできあがるエンジニアっていうのは哲学的ゾンビ的な何かにすぎないような気がする。

　…なんでこんなこと思ったかというと、大まかに2点あるような気がする。ここ一ヶ月で20個いかないくらいの勉強会に参加したのだが、だんだんメモを取る理由が判らなくなってきたのだ。

　というか、「言ってることは大まかに同じじゃない？」という気がしてきている。勿論テーマやそこで学んでいる内容は全然違うのだが、勉強会が持っている（そしてそこから私が受ける）影響っていうのは、源泉を辿っていくとすべからく同じところに繋がっているような気がするのだ。そこさえぶれなければ、後で好みの問題でしかないっていう。

　あと、Jonathan Rasmussonの話を聞いたのは大きい。彼の書いたアジャイルサムライは読みやすいし、人を鼓舞するような何かがあって、あの本はそういうものでできあがっている。そんな本を書いた彼の話を聞いていて思ったのは　…本の背景（彼の頭の中や考え方）には、あの本に記載されていることの何倍も複雑な考え方や人間性があり、それは一冊の本（その中には一貫性があるようにという縛りがある）の持っているコンテキストに即する形で、ほんの一部だけが文面に織り込まれているのだということ。

　彼の話を聞いていると、本に書いてあることについての意図や、ベースになる考え方など、本当に奥行きがあることがわかる。まず、そういうものが彼の中にある。で、それを踏まえて、読み手に適切な印象を与えるために、彼の中の引き出し（本人が知っている知識だけではなくて、感情に働きかけるための書き方なども含めて）を選んでいるのだな、というか。

　だとしたら、本の内容っていうのはただ鵜呑みにするのではなくて、その背景にある著者の人間性や、その本が参照している源泉（さっき言ったよね？）が、何なのかっていうことを意識して知るように努めなければ、読む意義って実はあんまりないんじゃないですか？　っていう。

　「知識を集めるのが目的で、カタログ的に読めばいいよね？」っていう読み方は勿論あるけど、「もっと深いところまで感化されるっていうのが本質じゃない？」っていうのが上の考えから導かれた、私なりの本の読み方ということになる。

　で、技術書って読み方に慣れてくると、そこにある考え方や方法のエッセンスを抜くのがうまくなったりするんだけど、もっと源泉のところも同じように読み取るコツがあるのではないかな？とも思う。

　今回は"Agile Japan", "Agile do it!", "Agile Samurai Dojo Gathering"という3つイベントに参加でき、また一ヶ月みっちり勉強会に参加し、それだけの時間を通して学び続けた。その中で、上記のような認識に至るくらいの影響を受けた。

　この、私が影響を受けたところっていうところに関して、もっと私の認識が見るかされていて、「自分が何について影響を受ける感じになっているのか」という点、私自身が自覚的であれば、もっと効率よく影響されることができるというか。

　こういう言葉にならないようなところを、影響受けるようにはどうすればいいのか？　っていう。よくよく考えると無理なような気もするけど、突破口になるような概念はあるんじゃない？　っていう気もしている。



～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

また半年後くらいに見返すと、いろいろと思うことなどあるのだろうなー。

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

2012/10/09に開催された『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』のノートです。

SIをやっている人には是非読んでほしいです。私のノート作成スキルを割り引いてもさておいても　…です。

※(2012/10/10追記)上の文について、言葉の選び方が不適切だったので修正致しました。「私の資料作成能力の限界で、okachimachiorz1様の伝えたいことの半分も伝わっていないかもしれない。だけど、それでも読む価値がある内容です」ということが、上の文で私が言いたかったことです。申し訳ないです。


◆今日の勉強会について

◇今日の構成
・最初にokachimachiorz1様の話を40分くらい
・その後休憩を挟んで来ている人達で感想、深く聞きたいということを皆で話合う
・Q&A

◇この回をやろうと思った経緯
・okachimachiorz1様のブログを一生懸命呼んでいるうち、その内容が自分の仕事の話になっていた
・自分が危機感を持てる内容になっていた
・そういう文を書く人の話を聞きたいと思ってお願いした


◆本編

◇はじめに
・どちらかというとAsakusaやHadoopの人
・SIの話ははじめて

◇自己紹介
・元々はITの人ではない
・ハゲタカファンドの人だった
　→バブル崩壊後、日本が買い叩かれたときに買い叩く側の仕事をした
・次に上場している流通企業でCIO, CTOをやった
　→ユーザ企業のインハウス
・その後ウルシステムズ
　→コンサル・SIでは食べられないので業務系のミドルウェアを作って売っていた
・キャリアとしてはマネジメントの方が長い
　→働いている人の給与・コストを考えざるを得ない立場である
　→自分も手は動かしているが、どこでも人件費の問題に突き当たる

◇エンジニアのキャリアは難しい
・前の会社では優秀なSEをコンサルにしていた
　→前の会社にはエンドとしてのエンジニアのキャリアがないということ
　→→NAUTILUSの設立にはエンジニアのエンドのことも考えている

◇日本の現状
・年寄りが増える
　→勉強していくことが必要だがそういう人も少ない
　→年を取るとアウトプットが減っていく（手を抜かないと体が持たない）
・社会的コストが増大する
　→公共事業で景気維持というスタイルを20年続けている
　→公共事業には立法が必要。単年度単位で行う
　→→2～3年後のことは誰も考えない（ランニングのコストは考慮されない）
・結果とつじつまが合わない
　→ランニングのコストが考慮されていない社会インフラ（情報システム）が残り続ける
　→橋などは壊れるが社会インフラ（情報システム）は壊れない
・人口が減る
　→総生産が減るので売り上げが減る
　→→利益の確保に走る
　→→コスト削減
・これらが社会全体の流れ

◇年金問題
・スキームとして成立していない
　→払っても戻ってこない
　→若者には遠慮しない
・消費税の増税
　→5%には直間比率を変えるという名目が合った
　→8%, 10%の増税にはそれがない
　→所得がそのまま減少する
・「都内で一家を構えて、嫁さんと子供を食べさせるには　…額面年収1000万＋貯蓄5000万ないと厳しい」

◇ITサービス産業について
・ユーザ企業におけるITエンジニアの就業人口について
　→米国は他国と比べて圧倒的に多い
　→日本はベトナムやロシアと比べると多い
・しかし給与は相対的に低い
　→IT業界は人が多すぎ
　→IT業界は給与が安い
　→→これが世界と比較した場合の現状

◇プログラマの生産性は低い人と高い人で10倍以上違うという
・これは本当だと思っている。実際にある
　→だからできる奴の給与をあげろ、と言われる
　→そうしないと携帯ゲーム業界に行ってしまう

◇本当にそんなに生産性が違うのか？
・他の業界ではそう言われない
　→会計士
　→流通
　→→SIと同じ労働集約型の産業
　→→あっても生産性の差は3倍くらい
　→→→そんなに差はない
・そもそも労働集約産業で10倍もずれたら商売にならない
　→これは異常
　→でもIT業界では散見されている
　→→COBOLでは10倍もなかった
　→→そして今はもっと開いている

◇なぜそんな差が？
・能力が高い = 生産性が高いのは事実
　→できる人の設計やコードは別格
・そもそもばらつきが酷い
　→言葉がでないくらい
　→→それは参入障壁がないから
　→→その辺の人を連れてきて書かせたりすることが普通にある
　→→「なんでこんな人連れてきたの？」「10人月で計算しているんで…」
・優秀な人の生産性が高いというより低い人が多すぎるのでは？
　→「これはないよね」という（酷い）コードを見たことがない人はこの中にはいないと思う
　→→差が非常に激しい

◇これはよろしくない
・いい人の足を引っ張ると言う話ではない

◇では、この状態を経営者層はどう考えるか？
・経営者層はできる奴の給与を上げたりはしない
・経営者層はできない奴に合わせる
　→下の給与を下げるか首を切る
　→できる奴の給与も適当に据え置く
　→→人間の給与はモチベーションでは上がらない。むしろ劣る
　→→ライバルが上がるとモチベーションが落ちるが、自分が上がってもこの程度か…としか思わない
　→→マネジメントは一斉に上げるしかない
　→→→できない奴を入れると全体が上がらなくなるということ

◇SIは基本的には成り立たない
・人が多すぎて給与が安い
　→人力の大規模SIに頼る現実はなかなかなくならない
・だが若年層人口が減っている
　→労働集約的産業は行き詰っている
・人件費の扱いを考える
　→一人当たりの賃金が上がる要素はゼロに近い
　→経営者はできるSEの給与を上げたいと思っている
　→でもできない。現実にはそうせざるを得ない
　→→大規模SIを商売にしているところはそうなってしまう
・NAUTILUSが小規模なのは給与を上げやすいから
　→積極的にそういう選択をせざるを得ない時代になっている

◇SIの現実。マーケットの現状
・単純な売り上げ増をSIで稼ごうとする
　→一度こちらに振ると脱却が難しい
　→特に上場会社
　→→右肩上がりの成長圧力がある会社で顕著
・ユーザ層は内製したいというが…
　→結局は丸投げ
　→→ITは彼らの本業ではない
　→→外部から調達すればよいという考えがある
　→だからといって無くてよいわけではない
　→→だが、そういった社内の声があっても実際には入れられない
　→→ITは間接部門なので真っ先に切られる立場
・需要と供給がこの中途半端な状態で成立している
　→どちらもお互いのことを考えてない
　→市場をよくしようというモチベーションが薄い
　→お互いのビジネスモデルを理解していない
　→→結果として成立しているだけ
　→→この市場は、なくなるときには簡単になくなる
・マーケットを維持しようとするインセンティブなプレイヤーにない
　→崩れても持ち直そうとする人がいない
・かなり厳しい

◇参入障壁を上げて、できる人でやろうとすればよかった
・でも、人でスケールアウトするモデルをとってしまった
　→にっちもさっちもいかなくなった
・どうすべきか真剣に考えないといけない
　→SIが行き詰った後どうするのか？
　→そのとき何をかけるか？
　→そもそもかけるものがあるか？
　→手持ちの札をどうふやすか？
・↑がSI系のエンジニアには必要になってくる

◇私は何をやったか？
・いいエンジニアの受け皿を作ろうと思った
　→こういう会社がもっとできるべきだと思っている

◇マーケットはどう変化していくか？
・"SIは終わコン"という説がある
　→同意する
　→だが0にはならない
　→現状は覆らない
　→だが縮小する
・単純な投資の先送り
　→中規模・小規模SIの増加
　→→投資余力の減少から規模の縮小が始まる
　→見積もりをミスると赤字がどんとでる
　→市場だけで決めてしまうので不経済が発生している
・先送り案件が増えると
　→投資自体がシュリンクする
・運用や追加補修の増加

◇少ない人数でどう回すかを真剣に考えるべき
・100人月を80人月でとか
　→アジャイルは答えではない
　→どうムダなくやるかをユーザと話をして、説得できないといけない
　→→ミスなく効率よくできないと駄目
　→そのためには個々人のレベルが高くないと駄目
　→→1人1.5役くらいやらないと厳しい

◇私が関わったプロジェクトの9割は失敗していた
・でも、できるPMが複数入ってサポートすると成功する
・エラーを摘出して修正するスピードが速いプロジェクト
　→そういうのはリスク管理ができる
　→excelの表に書いてリスク管理とか本当に意味ない
　→報告書を書けばリスク挙がってくるの？
・実質的なリスク管理は1人ではできない
　→その人よりレベルが高い人が見ないと分からない
　→そういう人が見て気付くだけでも全然違う
　→→だから、皆でやって壁に貼ってというアジャイルのスタイルは良い

◇業務系のニッチな仕事が増える
・ユーザが丸投げできなくなっていく
　→仕事を切り分けて出すようになる
・ちょっと間違えると大変なことになる
・流通は死亡率が高い
　→一見簡単に見える
　→でもそのとおりやっても業務は回らない
　→→それは例外処理の塊だから
　→→その取り決めのルールが非常に多い
・知らずに入ると大変なことになる
　→業務知識が必要になる
　→エンタープライズの例外系を知っている人がいないと厳しい
　→→厳しいけど、そこできっちり回るならエキサイティングで楽しい仕事ができる

◇手持ちのチップは充分か？何が必要か？
・1枚の最強のカードは「複数の"最強-1"のカード」には勝てない
　→最強のカードには沢山のコストがかかるが、"最強-1"は実は真面目にやればいける。
　→最強の手前を目指す
　→スーパースターになる必要はないが、複数の組み合わせでいけば強い

◇チップ
・この中で複数あったら強い
→設計
→アーキテクチャ
→アプリ
→インフラ
→運用
→基礎技術
→業務系ノウハウ
・そういう人がいたら欲しいでしょ？

◇エンジニアとしてのキャリアパス
・日本だけで最強を目指しても仕方がない
　→それはガラパゴスになってしまう
・90点を100点にするのではなく、30点を90点にする
　→50点では妥協しないが、100点は目指さない
・それができなかったら？
　→給与も上がらないし、SIの現状がこんなもの
　→→転職したほうがよい

◇経験知として
・歴史は繰り返す
　→汎用機->オープン->クラウド
・繰り返すたび、車輪の作り直しになる
　→作り直す必要はあるか？
　→でも作り方は知っておいた方がよい
　→知らなくて作るのは最悪
・流行に飲まれるな
　→Hadoop. HTML5, 関数型…
　→1回退いた上で自分なりに咀嚼し、「目的を持って」取り組むこと
　→何のために必要？　何のために使う？

◇何もしないとどうなるか
・実質的所得が下がる
　→税率とかで
　→これは決定的
・SIビジネスが縮小する
　→「モチベーションが上がらない」とか言ってられなくなる
　→あと5年以内に、「食べていけるのか？」というレベルになる
　→→消費税の5%は半端じゃない。手取りがざっくり減る

◇今までと何が違うのか
・座っていても大丈夫と言う時代が本当になくなりつつある
　→大企業でも倒産や合併の憂き目にある
・SNSなどのつながりで情報の流れが早い
　→自分の状況がわかる
　→選択肢が広がる
　→競争相手が日本全体になっている
　→→今までは会社だったけど、そうではない
・企業の壁が薄くなっている
　→個人を守れなくなっている
・個人は
　→モチベーションをどうするか
　→自分の能力をどう評価するのかが非常に重要になる


「自分で作らないと、夢も希望もない」


◆何をカードにするか

◇設計
・普通の設計ができるようにしておく
・画面・データモデル・バッチ
・正常系は馬鹿でもできる
・例外系が重要
　→やりすぎるときりがない
　→やらなくても死ぬ
　→程度を抑える
・きちんとした設計なら設計時点でパフォーマンスがわかる
・適度にやる感覚を理解する

◇アーキテクチャ
・全ての基本はI/O
　→どうすれば限界まで出せるか
　→どこがボトルネックか？
・障害のことを考えていないI/Oが多い
　→ここは性能とトレードオフになる
・今は（一般的に）複雑すぎる
　→どこで何をしているかがわかるアーキテクチャが作れると強い

◇アプリ
・ただ書くだけではない
　→wfで設計・実装・テストできる。こういう基本的なことが大事
　→書く量をコントロールしないといけない
・みんな書きすぎる
　→書かない技術を極めたほうがよい
　→リファクタリングしている暇なんか普通はないよ？
　→→最初から少なく書く
・コードから手をどう放すか、ということを常に意識する

◇インフラ
・とにかく情報収集
　→すごい勢いで変わる
　→仕様、マニュアルが変わる
・基礎技術を押さえる
　→物理階層
　→プロトコル
　→設計
　→障害
　→パフォーマンス
　→セキュリティ
・最後はI/O
　→パフォーマンス
　→対障害
　→→追えるように

◇運用
・できると強い
　→一度は経験すること
　→今まで見えなかったものが見える
・継続的なインテグレーションのマスター
　→システムは使われてなんぼ
　→生きているシステムはどんどん変わる
・コスト意識を持つこと
　→運用コストは馬鹿にならない
　→分かると非常に強い

◇基礎技術
・計算は絶対
　→計算量の計算ができないとか…
　→確率・統計を知らないとか…
　→→高校生～大学生レベルでいいので抑えておく
・品質
　→昔よりは言われるようになっている
　→品質 = テストではない
　→→もっとトータルなもの
　→出来上がるものではなく作りこむもの
　→→「予見可能性が高いもの（どういう挙動か分かりやすいもの）」が品質が高いと考える
　→→バグの量は関係ない。バグがあることが明確ならそれは品質が高い
・論文
　→すらすらじゃなくても読めるようにしたほうがよい
　→我々は巨人の肩に乗るべき

◇業務系
最終的にはエンドユーザには絶対に勝てない
でも（業務知識を）盗むことはできる
・考えることが大事
　→なんでこういう仕様に？
　→→何か理由がある
　→前提の基礎知識は知っておく
　→→会計なら簿記
　→→最適化ならORとか
・聞く
　→とにかく聞く
　→捕まえて聞く
　→→「こうなってるはずだと思うんですけど？」と聞くこと
　→→「どうなってるんですか？」ではない
・応用する
　→業務知識は仕様ではなく考え方。文化
　→"アカウンティングのセンス"みたいなものがある
　→→そのセンスがある人が見たときに、どう考えても直感的におかしいものとか
　→→会計のマインドがあれば全員が分かる。「これは筋が悪い」
　→そのセンスを何とかつかむ
　→→なんでそうなっているかが分かるようにする
　→その根底にある考え方を常識にとらわれず転用する
・これをやるだけでお客様の信頼が全く違う
・そうすれば、ヘルプで入っても見た瞬間に「これがおかしい」と分かる


◆質疑応答

Q.
非常に大きなユーザ企業の仕事は、少数精鋭の規模では請けられない場合があると思う。
そういうものを受けられるようにし、成長していくためにはどういうことをやっていけばいいのか？

A.
・原則からいくと受けないほうがよい
・少数精鋭がそういう仕事を受けに行くのは自殺行為になる
・どういう形態なら受けられるかということを話し合うべき
　→ユーザが「そういう発注はできない」というなら受けない
・「大規模SIが成り立つか？」と言うこと自体をユーザが考えないといけない
　→だってほとんどが失敗している
・大手ですら、ユーザからの内示が出た後に拒否するケースが出てきている
・そもそもユーザが大規模の案件を発注するのか？というのもある
　→インクリメンタル
　→パーティション
　→サービス
で発注するとか


Q.
大手だからまっとうな経験が積めないわけではないし、そこでしかできないこともある。
でも、配属によってはまともな経験ができないことがあって、そういう人はSIが無くなると死んでしまう。
そういうことを考えたときに大企業の中にいる人は何をすべきなのか？

A.
・中でちゃんと提案すること
・喧嘩別れは簡単
・「このままでは具合が悪い」ということを、個人ではなく部の意見としてきちんと話をする
　→1人の意見で話をもっていっても「お前が言っているだけ」で終わる
・部の意見なら、経営層も話合う力量がある
　→話し合えないなら全員辞めればよい


Q.
「マクロで見たとき日本でSIやるのは厳しい」というのがここでのコンセンサスだと思う。
生き残りの作戦として、エンドユーザに入ってITを軸としたイノベーションを起こすというのはアリだと思うがどうか？

A.
・そうだと思う
・でも、ユーザサイドから見るとそういう人のモチベーションを維持するのは難しい
　→ITの投資は景気が悪くなると真っ先に削られる
　→努力が簡単に否定される
　→→それでもモチベーションが維持できるか？という問題
　→→→それでも頑張れるのであればエンドユーザに行くのはありだと思う


Q.
（上の質問の続き）現場上がりの人がCIO, CTOになっているような会社を探せばあるのではないか？

A.
・ユーザにはR&D部隊があるようなところにいけばあるのでは？
・でも「まずは現場に行け」という話になる
・ある例
　→技術のある人間をまず現場に送った
　→彼は棚卸しをさせられた
　→結局2日で辞めてしまった
・中の人間とある程度コンタクトをとって、中の情報を取って行く
　→オーナーやトップがきちんと見ているということがカルチャーとしてあるか。
　→それから現場としてどうなっているか。
　→→そういうことを調べてから行くならよいのでは？

Q.
アメリカはユーザ企業の比率が高いと言う話があった。
でも、それは解雇が簡単だから開発フェーズごとに人数が変えられるという話。
日本では、開発のフェーズごとに人数が変わるところをSIがバッファしているというのがある。
ここの問題を解決しないと、シュリンクするSI業界に人材が取り残されて給与だけが下がっていくと言う状態になるのでは？

A.
・USがインハウスであれだけ人を取れるのは人材の流動性が高いから
・では日本ではどうなるか？
　→別の業務をさせる（製造業なら現場とか）
・ただ、IT系で優秀な人は違ってくる
　→会計・流通と比べてIT系で違うのは、どこでもプロジェクトマネジメントをやっているということ
　→ユーザは驚くほど線を引かない
　→→それをやるだけでもかなりプラスになる
　→IT企業にはそれがあるが、それをユーザに提供していないのが現状
　→ITできちんとやれる人は企画系（スタッフ）なら力を発揮できる
　→→きちんとしたマネジメントならそう考える
・でもそういう枠が沢山あるわけではない


Q.
SIがシュリンクしたときに取り残されたユーザも困る。そのときのユーザの出口は？
SIが倒産したときにユーザはどうすればよいのか？

A.
・エンドユーザがそういうときどうするか？
　→引き抜きにかかる
　→人ごと受ける
・それは今まで払ってこなかったコスト
　→「これだけかかる」「もうどうにもならない」ということを社長に話す
・こういうときに外部不経済が発生してしまう
・『基幹系で先遅りしてベンダとべったり』だと、それが原因で倒産することもありえる
・お互い打つ手なしと言う感じ


Q.
そもそも情報工学に人気がなく、内定がない人がSIに入ってきている。
SIとして質を上げるためには何をすればよいか？

A.
・まずはそういう人を取らない
・きちんとテストをやるとか
　→三角形のテストとか、だいたい書けない
　→→書ける人からとっていけばよい
・論理的に考えられ、日本語が書けて、でたらめでないコードが書ける
　→それでよい
　→後は2年間教育に放り込めばなんとかなる
・テストして適当な人がいなければ取るべきではない


Q.
ユーザ自体にお金がない。でもシステムを構築したい。
こういう場合、結果的にダンピングされる。
ユーザ「来年の予算は決まりました」
会社「受ければこれだけの利益になります。だからやれ」
で、いくつかのプロジェクトで赤字になったりして会社からいろいろ言われる。
どうすれば？

A.
・やるべきではない
　→お金がないけどやってくれというのをやるのがそもそもの問題
　→上が「やれ」というなら「赤になるぞ」ということをきちんと言わないといけない
・赤字は赤字
　→自分の手足を食べているというだけの話
　→それを下に投げている時点で経営層失格
・お客様との付き合いとして取らないといけない場合
　→それは投資
　→どこで回収するかをきちんと決めてもらわないといけない
・赤字だからダンピングでも受けてしまう
　→そうやってきたのがSIがこうなっている原因でもある
・「赤字になってどうするかを考えるのは自分の仕事ではない。俺はその分の給与を貰っていない」と言ってよい





okachimachiorz1様, DevLove様, 日本マイクロソフト様、ありがとうございました。

『Experience Vision のはじめかた』ノート

2012/09/26に開催された『Experience Vision のはじめかた』のノートです。

DevLoveは今日で93回目とのこと。あと7回で大台です！

◆山崎和彦様 - 自己紹介

　

　◇経歴

　

　　・京都工芸繊維大学で工業デザインを専攻

　

　　・クリナップからIBMへ

　

　　・IBMでは工業デザインからソフトウェアのインタフェースデザインへ。ユーザエクスペリエンスデザインセンターを作った。

　

　　・その後はコンサルティングとして、UCDやUXを伝える活動

　

　　・そして千葉工業大学へ

　

　IBM時代にアメリカ人の同僚が言っていた。「アメリカでは家に帰ってから勉強している。大学も単位辺り2万円でとれて、5年かけてMBAが取れたりする、向こうでは余暇としてそういう生き方ができる」

　そういう生き方に興味を持って、神戸芸術工科大学・東京大学で手法を学び、現場で実践していった。いまも商品戦略ウェブ戦略パッケージングなどもやっている。

　

　

　◇執筆活動

　

　　やり方をまとめることの大事さを思い、本も書いた。

　

　　・使いやすさのためのデザイン

　

　　・情報デザインの教科書

　　　→この分野を学ぶための教科書として作った。

　

　　・プロダクトデザイン

　　　→教えることが先生毎に違って、どうなの？と思って出した。工業デザインって、どこでも聞くけど、教科書がない。僕らが始めて作ったという自信ができた。

　

　本として出版することで手法や考え方を使ってもらう。

　自分が学んで経験したことを使ってもらえることで、社会に役に立ったと言う実感がある。

　今日もその延長にある。

　

　

◆エクスペリエンスビジョンについて - どういったものか

　

　◇エクスペリエンスビジョンについて

　

　　・ビジョン提案手法のフレームワークである

　

　　・新しいビジョン・サービスを構築するために役立つという視点から作った

　

　　・ユーザの本質的体験から見た、ユーザがもっと喜ぶような新たな体験を与えるため、本質的な価値と展望を探ることが目的

　

　　・本質的欲求からはじめ、上位の価値やサービスを考える

　

　　・エクスペリエンスビジョンのプロセスを全部使わなくても、全体像がつかめるようなテンプレートがある

　

　

　◇エクスペリエンスビジョンの歴史

　

　　・エクスペリエンスビジョンは5年かけて作った

　

　　・ワークショップや合宿で実証していったら5年かかった

　

　　・いい手法はどんどん取り入れていきたかったから5年かかった

　

　　・世の中にあるものは使い、無いものは考え出した

　

　

　◇エクスペリエンスビジョン本について

　

　　・エクスペリエンスビジョンで使用するテンプレートはダウンロード可能

　

　　・本を持っていなくても落とせる

　

　　・エビ本には、エクスペリエンスビジョンの適用事例・教育事例・ワークショップ事例も書いてある。

　

　

　◇既存の手法をどんどん取り入れたことについて

　

　　・手法を考えた人は、それを使えば世の中を変えるような書き方をしてしまう。でもそれは嘘

　

　　・手法は一部分でしかない

　

　　・いろんな手法を上手く使いこなす。エクスペリエンス・ビジョンにはそういう役割を持たせている。

　

　

　

◆エクスペリエンスビジョンについて - 関連領域との関わり

　

　◇ビジネスとエクスペリエンスビジョン

　

　　・エクスペリエンスビジョンにはビジネスの観点もある

　

　　・ユーザとビジネスの両方を見ている

　

　　・モノを売っている人がどうやってサービスに転換していくか？など

　

　

　◇HCDとエクスペリエンスビジョン

　

　　・エクスペリエンスビジョンでは勿論HCDを使っている

　

　　・エクスペリエンスビジョンはユーザの価値に基づいて企画やエンジニアが提案するアプローチを取っている

　

　　・今までのHCDはユーザのニーズを受けるものだった

　

　　・今までのHCDは問題解決に寄っていた

　

　　・欧米のHCDの使い方やデザイン思考のアプローチを見ると、HCDはイノベーションの源泉としても使える

　

　　・HCDには問題解決と提案型の2つの使い方があり、それはプロジェクトに応じて使い分ければよい

　

　

　◇シナリオとエクスペリエンスビジョン

　

　　・構造化シナリオを取り入れていることはエクスペリエンスビジョンの特徴

　

　　・シナリオができればユーザの本質的価値を評価できる

　

　　・シナリオを使えば、きちんとしたウェブサイトなどを作ることなく価値を調査することができる

　

　　・戦略的にやるときはバリューシナリオまでやるけど、日々のプロジェクトはインタラクションシナリオで留めたりとか　…そういう使い方もできる

　

　　・ユーザ視点->プロトタイプ、ビジネス視点->ビジネスモデル、の形でシナリオの視覚化ができる

　

　

　

◆バリュー（本質的な価値）について

　

　◇エクスペリエンスビジョンでは

　

　　・構造化シナリオ手法を使い、段階的に明らかにしていく。

　

　　・フレームワーク上では、上半分をユーザ・下半分をビジネス。それを真ん中のシナリオでつないでいる。

　

　

　◇バリューなどの上位概念について取り組むということ

　

　　・これが曖昧だったりレベルが低かったりすると、いいアイデアが埋もれる

　

　　・そういうことはすごくある

　

　　・戦略作りはすごく大事

　

　　・プロダクトを作って、じゃあ2年~3後はどうするのか？ということが書いてない企画がほとんど。

　

　　・半年後の製品をただ考えるのと、ユーザの慣れも考慮したうえで2年～3年後のことを考えるのでは全然違う

　

　　・企画書は自分のウェブサイトや製品のことしか書いてない。戦略は戦略部門の話で別、となってしまう

　

　　・そういう中では新しいことをやるのは難しい

　

　　・新しいことには投資もリスクもある。それは単体の投資では回収できないことが多い

　　　→だから、上のレベルで目標設定することが重要

　

　

　

◆ユーザについて

　

　◇ユーザの本質的価値を知るためには

　

　　・提供価値分析やKA法という手法がある

　

　　・目の前の事象に対して、ユーザの価値や心の声を見つけ出していく

　

　　・潜在ニーズはフォトエッセイや行動観察で明らかにする

　

　　・顕在ニーズは日記や質問

　

　

　◇ユーザ設定

　

　　・ビジネスを考えるのであればステークホルダーも必要

　

　　・ステークホルダー = ビジネスに影響を与える人

　

　　・優先順位をつけて、具体的な対象ユーザを明確にする

　

　

　

◆シナリオについて

　

　◇シナリオとは？

　

　　・シナリオはモノとヒトの関係を表すことができる

　

　　・仕様書にはモノのことしか書いてない

　

　　・シナリオは日本語が読めれば分かる

　

　　・仕様書は専門家が見ないと分からない

　

　　・シナリオを介せばエンジニアとデザイナーが互いにコミュニケーションできる

　

　

　◇構造化シナリオについて

　

　　・シナリオを階層化していることがポイント。

　

　　・バリューシナリオ（ユーザの価値 / なぜ？）

　　　→バリューシナリオ：新規性・魅力がポイント

　　　→ユーザ・ビジネスにとっての価値

　　　→ユーザにとっての本質的欲求がビジネス提供者の提供方針がベースになる

　

　　・アクティビティシナリオ（ユーザの行動 / 何を？）

　　　→バリューシナリオの1シーン

　　　→ユーザの活動の全体が分かるように描く

　　　→ペルソナはこの段階ではっきりしている必要がある

　　　→有用性・便利さがポイント

　

　　・インタラクションシナリオ（ユーザの操作 / どうやって？）

　　　→効率・全体としての使いやすさがポイント

　　　→アクティビティシナリオの1タスク

　　　→具体的なモノ、その使い方を書いていく。

　

　　アクティビティシナリオとインタラクションシナリオの違いについて。アクティビティは人の行動なのでモノははっきりしていない。逆に、インタラクションはモノがはっきりしている。例えば、朝気持ちよく起きるのはアクティビティで、それを照明器具でやるというのがインタラクション。

　

　

　◇シナリオの評価方法

　

　　・ユーザの側面からの評価方法（代表的なもの）

　　　→魅力性・新規性・有効性・効率性。

　　　→魅力と新規は満足度に関係する

　　　→有効と効率は便利さに関係する

　　　→どれを評価するのかはプロジェクトの段階で変わる。例えばバリューの段階なら効率性より魅力性や新規性を見る。

　

　　・ビジネスの側面からの評価方法

　　　→戦略性・事業性・市場性・実現可能性・社会性

　　　→例えば、最初のバリューの段階で戦略を評価し、アクティビティで市場性を見て、操作で実現可能性を見る

　　　→3年後の話を考える時に操作性の話をするのは違う

　

　

　

◆エクスペリエンスビジョン・情報デザインに関して出てきた話

　

　◇問題解決と提案

　

　　・問題解決のプロジェクトは必要だけど、それだけじゃダメ

　

　　・新しいものやこれまでなかったものを考えるためにはユーザの本質に立ち返って、エンジニアからユーザに提案することが必要

　

　　・ただ提案するだけではなくて、ユーザの立場から提案することが重要

　

　　・ユーザの価値に基づいてビジョンを考えると新しいものが見える

　

　

　◇企画提案書について

　

　　・技術・実現可能性がポイント

　

　　・総合的なビジネス企画を立案する

　

　　・製品やサービスに対するユーザ要求仕様をまとめる

　

　　・ユーザ視点から見た仕様の根拠を書く

　

　　・うれしい体験 - 「HCDから見たポイント」「差別化・新規性・魅力」を書く

　

　

　◇本質的な価値の見つけ方

　

　　・本質的な価値を見つけるのは難しい

　

　　・バリューシナリオを作って共感度を見ていくのがよい方法だと思っている

　

　　・シナリオ作りならお金がかからないので、そこを評価して価値を見つけていけばいい

　

　　・何もないところからブレストしても仕方がない

　

　　・砂金取りと同じで数を打たないと駄目。

　

　　・新しいものはどこにあるかわからないので、広くユーザにアプローチすることが大事

　

　　・そのためにはできるだけ簡単な形で聞く方がよい

　

　　・シナリオは完全なプロトタイプよりも量が作れる

　

　　・シナリオなら「こんなものも？」という、プロトタイプでは（費用と優先順位的の兼ね合いで）試せないようなものについても調査ができる

　

　

　

◆もう少し周辺の話

　

　◇ゲームチェンジについて

　

　　・同じ土俵で戦うと安くて効率のよいところには勝てないというのがある

　

　　・そういうとき、欧米ではゲームチェンジを使う

　

　　・アメリカは自分達でルールをどんどん作っている

　

　　・改良だけで日本がやっていくのは今後難しいのではないか

　

　　・目の前の問題を解決するのではなくて、ユーザに本当に必要なものを長い目で見て戦略を立てることが大切なのではないか

　

　　「新しい目覚まし時計をデザインして？」と言われると、既知の固定された記憶の中でデザインしてしまう。そうではなく「朝、気持ちよく起きることができる体験をデザインして？」とすると、1つ上のレベルで考えることができ、もっと自由な提案ができる。チェンジゲームというのはそういうこと。

　

　

　◇スケッチとプロトタイプの違い

　

　　・散策的にアイデアを作るのがスケッチ

　

　　・検証的なものがプロトタイプ

　

　

　◇新しいサービスの確かめ方

　

　　・イベントを1回だけやる。ユーザにとってうれしいかどうかはそれだけで判断できる

　

　

　◇アクティングアウトの使い方

　

　　・いろいろある。実際に設計者が使ってみるとか。

　

　

　◇クイック＆ダーティ

　

　　・クイック＆ダーティに実験することがすごく大事

　

　

　◇構造化シナリオはウォーターフォールっぽくない

　

　　・アジャイルとシナリオは近い

　

　　・どこまで深くやるか？という違いだけの話。

　

　　・アジャイルはソフトウェアまで作るが、（エクスペリエンスビジョンでは）クイックにシナリオ・プロトタイプを作って済ませる

　

　　・クイックに作るのが大事

　

　

　◇心配していること

　

　　googleが自動運転の車を街で走らせ、実証的に走り方をプロトタイピングしている。日本は法律上そういうことが絶対にできないと言われている。iRobotもろうそくが倒れたら火事になるからできなかった。そういう日本人の潔癖さが、機会を遠ざけていることを心配している。 

　

　

　◇異文化

　

　　アメリカでは、新しい発想をするためには異文化の人がいないという認識をする人が多い。技術者・マーケティングの人・デザイナー　…そういう人が混ざることで新しいものができるという発想が大事だと思う。 

　

　

　

　

　

山崎和彦様, DevLove様, ありがとうございました。