2012/11/25(日) 大阪マラソン2012を完走してきました。
あ、もちろん42.195km、フルマラソンです。
公式サイト：
http://www.osaka-marathon.com/
今年は計3万人の定員に対し、最終応募数が15万5482人だったそうで、当選倍率は5倍↑です。
昨今のマラソンブームを感じさせる応募者数ですね。。。
そんな中、私も応募して運よく当選！きっと日ごろの行いが良いか(ry
私、大阪の箕面市に実家があるので、帰省を兼ねて参戦できるんですよねー
私自身、小学校3年生から高校卒業までずっと大阪住まいでしたので、青春時代（？）を謳歌した故郷なのです。
あと社会人2年目も1年間ずっと大阪勤務でしたし、去年も3ヶ月ほど長期出張してたので身近な土地です。
んで実家に帰ると、愛犬の散歩が楽しみなのです。
このブログの右側にあるプロフィール欄の写真が愛犬なのです。
室内で飼っているヨークシャーテリアがベースの雑種なんですが、モフモフしてて
人懐っこくて、悶え死にそうになります（ぇ
↓はボールをくわえている愛犬。
さて、今回は26日と27日は休暇を取っているので、23日～27日の5連休を実家で
のんびり過ごしつつ、中日の25日に42kmを激走することになります。
大阪マラソンのコースはこんなカンジ。大阪の名所を走り回るコースになってます。
スタート地点は、小学生や中学生の頃に遠足や社会見学とかでよく行った大阪城公園です。
以下は当日、大阪城公園に入った広場で激写した、朝日に輝く大阪城。朝7時36分。快晴。
さて、今回は今年3回目のフルマラソンになります。
過去2回は完走したものの、タイムは5時間台とお恥ずかしいものになってます。
ただ3年前にバスケでアキレス腱を断裂した際は、もう2度とスポーツできないんじゃないか、と酷く落ち込んだものでしたが、長い治療とリハビリを経てフルマラソンを完走できるほど治癒したことがとても嬉しく思います。
１つのチャレンジでもあったんですよね、フルマラソンが。
大怪我からの復活と、歳をとっても俺はまだやれるんだ、というのを示すためのチャレンジ。
ということで今回もおぼろげながら目標を立てました。
① 42.195kmを完走
② 自己ベスト更新どちらも私にとっては簡単ではありません。。。
①は過去2回の経験から、後半10kmで地獄が待ってることを知ってるので。。。
②ですが、初マラソンが2回目よりタイム良いんですよね。
あのときは「知らぬが仏」ということわざがピッタリ会うんですが、怖いもの知らずでラスト10kmを
ペースメーカーにくっついて激走した結果なんですね。
あの、残り10kmの恐怖を知らないからこそできた走りは今思うと奇跡だったとさえ思えます。
なのでこのときのタイムを破るには、それ相当の走りが要求されます。
・・・
ということで、結果です。順位の下二桁とタイムの秒数は黒塗りで。。。
散々たる結果でした。完走は達成できたものの、ラスト5kmはほとんど歩きでした。
ネットタイムは2回目とほぼ同等の5時間40分台。。。
しかも2回目は6月の初夏だったことを考慮すると、気候に恵まれた今回の方が速くないと。。。
敗因はいろいろありますが、大きく二つ。
(a) 単純な練習不足
(b) 給水と給食の摂取ミス(a)は、そのまんまです。。。
直前2週間は忙しすぎてほとんど走れなかったし、その他の期間も平日は時々早めに帰って40分くらい走るだけでした。
当然30km走とかで足も作っておらず、そのまんまの普段能力で挑んで惨敗した結果です。
(b)は、給水ミスと聞いて、給水が取れなかったことを思い浮かべると思いますが、
逆です。
給水を取りすぎてしまった！しかも
給食もかなりの量を取ってしまった！お腹が途中から重い。。。
いやー、最初の給食ポイントがたしか24kmくらいで来たんですが、そこでの体力の回復力がかなりのものだったんです。
んで、次の給食ポイントでもたくさん食べて、その次の給食ポイントでもたくさん食べて。。。
・・・だって、大阪マラソンって、これまでのマラソンに比べて給食が潤沢で。。。つい。。。
反省。
しかも帰ってから月曜と火曜午前中まで、食中毒のような症状が出て、嘔吐と下痢。。。。
いやー、休暇を取っておいて良かった。
過去2回のマラソンではこんなことなかったんですが、あれだけの参加者がいて、ウィルスとかもらったのかな。。。
半袖Tシャツ１枚で冬空７時間、体力消耗してるのに、うがいとかもしなかったしなぁ。失敗。
あ、走ってるときに途中で元阪神タイガースの赤星選手の横を通って抜きました。
赤星さんはチャリティーランナーで参加されていたんですね。
他にも有名人も多数参加されてたようで、時々沿道の応援者から歓声とか上がったりしてました。
でも、あんま気付かなかった。。。必死だったし。そもそも芸能人に疎いので。
ということで今年最後のマラソンは反省で終わりました。
でも、故郷の大阪で42kmを完走できたことは良かった！諦めずに最後まで走り抜けたのはホント良かったです。
アキレス腱を断裂しても、歳を重ねても、フルマラソン年３回、すべて完走できる自分がいる。
今年のマラソンは終わりましたが、次は来年１月２７日に千葉の館山で開催される館山若潮マラソンにエントリー済みです。
http://www.tateyama-wakasio.jp/index.shtmlこちらは今年１月に初マラソンで走ったコースです。来年１月に、１年前の自分（のタイム）と勝負です。
なんとか勝って、年々進化する自分でありたいと願う今日なのでした。
2012/11/18(日) 「第6回 スタートHaskell2」に参加してきました。
Partake（告知サイト）
http://partake.in/events/c25307be-13e1-4b19-8afd-a2016926f598togetter
http://togetter.com/li/409269放送録画
http://vimeo.com/masterq/videos/
以下の書籍をテキストとした、セミナー形式と演習形式を組み合わせた勉強会なのです。
会場はいつもの IIJ 大会議室 (17階)です。参加者は70人弱でしょうか。
今回は12章と13章が範囲です。とうとう、Haskellの山場（？）であるモナドが出てきます。
私も可能な限り本に目を通し写経して、なんとか予習っぽいことしてから参加しました。
12章、13章の発表の後にそれぞれ、 @kazu_yamamoto さんの補足発表がありました。
■12章 モノイド @apstndb さん
12章はモノイドです。モナドと名前が似ていますね。
newtypeという単語を見て真っ先に
ガン○ムが思い浮かんだ人も多いかと思いますが、そんなアタナはきっと30代！
この日は12章も13章も、単位元とか論理演算とか、集合の概念が多く出てきました。
大学で学んだ日々を思い出します。あの時は集合理論とか、その必要性がほとんどわからないまま
単位を取ってましたが、今だとそのありがたみがちょびっとわかる気がします。
■あなたの知らない Monoid の世界 @kazu_yamamoto さん
（↑クリックすると発表資料に飛びます↑）
FizzBuzzを除算も使わずに実装するモノイドの紹介は興味深いですね。
モノイドの使用時は、選択か連結かを意識することが重要のようです。
■13章 モナドがいっぱい @brain_apple さん
東大生とのこと。秀才ですなー。
あとFunctor, Applicative, Monadを並べて書いてみる説明、良い着眼点ですね。
比較して考えてみることで、似てる部分と異なる部分が際立ちます。
■モナモナ言わないモナド入門 @kazu_yamamoto さん
（↑クリックすると発表資料に飛びます↑）
この発表、去年の「初代スタートHaskell」でもありましたね。今回は第2版だそうです。
タイトルの「モナモナ言わない」とは、「モナド」という言葉を使わずにその概念を説明するためだそうです。
直前の13章発表とこの発表で、モナドが何者か、理解が深まった気がします。たぶん！
次回の14章もモナドなので、復習しよう。
今日は演習はありませんでした。こっからはLTです。
■モナモナ言うモナド入門.tar.gz @hiratara さん
直前にあった @kazu_yamamoto さんの発表スタイルをユニークに流用した内容で、大ウケしてました。
でも圏論、私にはぜんぜんわからん。。。こーゆう理論を使えば、モナドも理論的に説明できるのか。。。
■C83 λカ娘の販促にやってきました @master_q さん
前回に引き続き @master_q さんのLTです。
コミケで関数型言語をターゲットにした同人誌を発売しているとのことで、私も以前、2巻を買いました。
3巻は9月にお茶の水であった関数型言語のイベントで頒布してましたねー。
そんときはすぐ売り切れになってしまって買えませんでした。
4巻はHaskellの処理系をダイエットする、というテーマでストーリを書いているらしく、その一部をユニークに
紹介されていました。コミケでこーゆうスタイルの参加も斬新で良いですねー。
■感想：
一応予習して参加したこともあり、モノイドとモナドの概念はなんとなく理解できた気がします。
発表者のみなさんの説明も、とてもわかりやすかったので大変ありがたかったです。
独学よりはぜんぜん理解が深まりますし、何よりも、こーゆうイベントに参加すること自体が楽しいです。
次回は1月に開催とのことで楽しみです。
願わくは、1/27(日)に被らないことを祈るのみ。この日、千葉の館山でフルマラソン走るのよね。。。
発表者様、運営者様、会場提供者様、ありがとうございましたー
2012/11/13(火) 「LeanStartupNight - Real Startup Dialog -」に参加してきました。
DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/1955?auth_token=KtzNwSR5xptmQrC6sMfRtogetter
http://togetter.com/li/406814場所は有楽町の「ぐるなび」です。参加者は40名くらいでしょうか。
以前Devloveでリーンスタートアップの勉強会が開かれまして、そこで非常に興味を持ったので今回も参加することにしました。ちなみに前回のリーンスタートアップの勉強会について書いたブログはコチラ↓
2012/9/21(金) 「LeanStartupNight - Eternal Rotation! -」に参加してきました。http://makopi23.blog.fc2.com/blog-entry-19.htmlんで、そんときに触発されて以下の書籍を買いました。今も通勤電車の中で読んだりしてます。
最初に、@papanda さんからDevLoveの紹介がありました。
Devloveの根底にあるもの■HangarFlight 飛行気乗りのとって空がまだ未知で危険なものだった時代。
格納庫に集まってお互いの体験を話し合って空を知ろうとした。
・なぜ？からはじめよう。その事象の背景にあるものはなんだろうか
・答えは１つではないし、他人の出した答えがそのまま使えるとは限らない。
・ぬーんと引っかかった所を逃さずに。そこは相違があること。自分の考えの検証になるはず。
■ダイアログ・何かを決めるためのディスカッションとは違う。
・参加者の様々な視点で、物事の意味や仮説を発見するためのもの。
・必要なことはいつもより大目の「うなづき」と「聴く耳」
LeanStartupJapanの和波俊久さんから一言・スタートアップすべての人にやってほしい
・機械的にどんどん最初の芽を生み出してほしい。
・スタートアップ側で一番困っているのは、エンジニアがいないこと。
→ モノができない
・スタートアップ側のみなさんは、スタートアップの魅力を参加者に伝えていただきたい。
---
次は、リーンスタートアップを実践されている4名の方の発表です。
■１．株式会社Pitapat 伊香賀 氏 取締役／プロデューサ
Pitapat紹介http://pitapat.co.jp/index.html・失敗の多い会社なので、今日は反面教師役として。。。
・Pitapatは学生４人で昨年度立ち上げた会社。
・「世界中の人々の心を動かす」サービスを作りたい。
・１月からサイバーエージェントの子会社となった。
・「Pitapt」をリリースして４ヶ月でサービスを終了した。
・今はキクシルというサービスを作っている。
１. 手がけているサービスの内容、そこに込めた信念や思いPitapat・Facebook&iPhoneアプリ
・気になる人を選ぶ → ドキドキ通知が行く → マッチング通知 → わクわくトーク
・失敗に終わった。。。
２．失敗の仮説①想定ニーズの勘違い・想定：知り合いとの交流（友達なんだけどなかなか話せないような人との交流）
・実際：新しい出会い、繋がりを求めてた。身近に感じられる他人との交流とか。
・仮説：
スマホでの知り合いとの交流はFacebookはLineで十分。
ポストFacebookに必要なもの
→ 他人との繋がり、交流できる場、が1個必要ではないか？
②テーマとマッチしない成長エンジン・想定：バイラルで広まる（お金をかけなくても、SNSとかで強力に広がっていくところがチャンス）
・実際：テーマが「恋愛」だったので、周りの人に言いたくない。。。
③継続率の低さ・想定：多くの人とマッチし、またマッチした人と楽しむプラットフォームへ
・実際：マッチしてしばらくしたら飽きてしまう。そもそもマッチすることが少ない。
（1対1のサービスなので、一人が止めてしまうと続かない）
・仮説：
1対1のサービスでは難しい。コミュニティのようにみんながいて、一人でも繋がれる必要がある。
３．今考えているサービス・サービス名：キクシル
・同じ情報でも誰が言ったかによって価値が変わる、という点が、このサービスの価値だと思っている。
・「従来のQ&Aサービス」＋「どんな人が言っているのか」＝キクシル
・具体的には、会社の名前とかを登録して、知り合いではない専門家の人たちに相談できるサービス。
４．リーンにスタートアップする対策(1) A/Bテストの環境の構築
・「社内の議論＜顧客のデータ」
・議論するんじゃなくて、早くデータを見ようよ、という思想に切り替えている。
(2) ブラウザベースで作るMVP
・「完璧なリリース＜改善のしやすさ」
・Objective Cで開発したネイティブアプリから、PHPで開発したでブラウザベースのアプリにした。
・ブラウザベースのMVPでいろいろなサービスを最適化した後で、ネイティブ化しようと考えている。
(3) セグメント別のユーザデータ取得
・「脱・虚栄の評価基準」
・DAU（※）をKPIにしている企業があるが、危ないと感じている。
（※）
DAUとは：
SNSをはじめとするソーシャルメディアやソーシャルアプリなどにおいて、1日にサービスを
利用したユーザー（アクティブユーザー）の数のことらしい。 By IT用語辞典
・DAUを以下４つのセグメントに分割して計測した。
①新規ユーザ
②ビギナーユーザ（ログイン日数15日未満）
③コアユーザ（ログイン日数15日以上）
④カムバックユーザ（ログイン日数１日以上かつ１週間以上ログインしていない）
→コアユーザを増やすことに焦点を置いた。
以下に①②④が③になるのかという仕組みを構築しようとしている。
最後に・自分たちは「世界中の人の心を動かす」ことができると思っている。
・MAKE YOUR HEART BEAT
・なんとかして夢を達成したい。
・私たちだけが成功するんじゃなくて、みなさんの知識を共有することで、IT業界全体の閉塞感を破りたい。
■２．リブ株式会社 工藤博樹 氏 １．手がけているサービスの内容、そこに込めた信念や思い・エンジニアを探している。
・サービス：Merry biz（
http://merrybiz.jp/）
・サービス内容：コアビジネス以外の業務をクラウドソーシングで解決する。
サービスを考えた経緯会社を始めるのにかかる費用って。。。
・登記に必要な費用：25万円くらい
・決算書・申告書作成に必要な費用：8万～25万円くらい
→ 会社をはじめるのってなんでそんな高いのか。
理由：会計士が生計を立てるために、一社から50万円くらい貰わないといけない。
→ 中小企業は経営リソースが無い。お金も時間も無い。さてどうしよう。。。
→ メリービズが肩代わりするので、企業は本業に集中してもらう、というコンセプトで企業した。
How？・会計サービスのプロセスを分解して、適材適所を配置することで効率化を実現する。
（現状は、それぞれのプロセスが最適化できてない）
・まるで隣にスタッフがいるかのような親身なサービスを提供する。
（会計士と話そうとすると、専門用語とか連発で大変なので。。。）
★つまり、事務作業をもっと手ごろに簡単にしたい。
→ 企業が成長をさらに加速させられるようなビジネスにしたい
２．課題と乗り越え方・自分でなんとか調べて実施する
・周りに詳しい人がいないかを探す
・仕方なくお金で解決する初めての決済・物流・サービス・スタジオの立ち上げを１ヶ月半で実現できた。
これができたのは、以下を実施したから。
・調べまくる
・聞きまくる
・実践しまくる
→ あらゆる手を使って課題を乗り越えてきた。
３．開発者への期待ソフトウェア開発者への期待：その１・今はオペレーションがヘビー。。。
→ 圧倒的に煩雑なオペレーションをスケール出来る仕組みを一緒に作り上げる
ソフトウェア開発者への期待：その２・圧倒的ユーザフレンドリーなサービスを作り上げる
（海外だとチャットで聞ける仕組みがあったりする）
４．リーンスタートアップ事例・メリービズの前に、コンシューマ向きのカフェ・コンシェルジュサービスをやろうとしてた。
- コンシューマ向けのカフェに特化したニッチなサービス。
- カフェの込み具合とかもリアルタイムで提供できるサービスがあったらいいな、という思い。
→ やってみた。たけどエンジニアがいなかったので、Twitterで人力で泥臭くやった。
結果：
20件くらいの問い合わせしかない。
→ トランザクションが得られなかった。
→ 計測ができなかった。。。
→ 今年の8月にサービスを閉じた。。。
コンシューマをいきなりやるのは厳しいと思った。
なぜなら、コンシューマ向けサービスは大量のデータを拾って回すことが大事なのに、
エンジニアがいない状況ではそれができないから。
自分ひとりではその仕組みを作ることができない。
BtoBならお客さんが少なくてもきちんとお金になる。ラーニングを得られる。
→ いまそちらにシフトしている。
■３．株式会社Grumee 吉国雄大氏・グルメのサービスをやっているが、ぐるなびさんで発表することになるとは（笑
・グルメコミュニケーションアプリ「Grumee」（
http://grumee.net/）
・人と人、人と飲食店、を繋ぐサービス。
・これからサービスをローンチしようとしている。
・前身
Grumeeの前は、株式会社インテリジェンスで泥臭い営業職をやってきた。
東京で良い営業成績を上げて、会社からMVP賞を貰った。
でも、やりたいサービスがあったのでGrumeeを起業した。
１．サービス紹介・お気に入りの飲食店をマイギャラリーに登録していくセルフサービス。
・自分も友達も、マイギャラリーにお店を貯めていく
・マイギャラリーに登録した内容を、他の人とLineのチャットのような感じで共有出来る。
・Lineのようなベース機能に「ぐるなび」のサービスを載せたのがGrumeeのコンセプトである。
・サービスの特徴：
- 身近な友達がフィルタリングした信頼性の高いお店リストからチョイスできる。
- 身近な友達が、フィルタリングしてくれる。
- チョイスしたお店について、友達にすぐ聞ける、共有できる、友達を誘える、ストックできる。
・お店側
- お気に入りに登録してくれているユーザとチャットでコミュニケーションや情報提供が可能。
- お気に入り登録ユーザ限定に一括送信可能。
- リアルタイムで広告配信が可能。
- 常連のお客様、個人に向けた１対１の対話が可能。
・電話番号だけで繋がれるサービス。チャットやSNSのような要素も兼ね備えている。
・今は、Innovation Weekendというイベントに応募して、そこでの賞を目指して頑張っている。
２．遭遇した課題と乗り越えた工夫(1) 4つの0からスタートした
・ITの知識：0
・IT関連の人脈：0
・Facebookの友達：0
・iPhoneアプリのダウンロード：0
これらを0から1や2にしていくために、以下を実践した。
・ひたすら勉強会にでるようにした。
・有料セミナーとかにも参加して、お金を投資して人脈を作った。
・人脈を作るため、Facebookのメッセージを送りまくった。
・iPhoneアプリをダウンロードしまくって状況分析をした。
これらを実践することで、4つの0が以下のようになった。
・IT関連のブックマーク：100
・IT関連の人脈：200人
・Facebookの友達：680人
・iPhoneのアプリ：100
地道な行動でここまでこれた。
まったく知識が無い中でアプリを作れるようになった。
３．開発者への期待・常識から外れている人間でもできるんだと気付いた。（自分がそうだったので）
・でも、以下だけは思っていて欲しい。
(1) ユーザ視点であってほしい
(2) 自分が使いたいと思うか
(3) インフラとなるサービスを創りたい
(4) やりぬけるか
４．リーンスタッフに関する事例 ・自分の誕生日の11/21にβ版をローンチする予定。
・ここからが私のリーンスタートアップだと思っている。
・現段階はMVPと認識している。
・1～2ヶ月はPDCAをぶち回して改善し、ブラッシュアップして来年正式リリースしたい。
■４．株式会社アゲハ 木下優子 女史１．会社概要とストーリー・2008年4月設立で5年目。
・きっかけは大学院進学と同時に、ユーザイノベーションという研究テーマの延長で企業した。
・価値のある商品を作りたい、という活動をしている。
・理論だけでなく具体的に実行可能なモデルを作っていく必要があるとと思っていた。
・ビジネスプランに落とし込むため、ビジネスコンテストに応募したりした。
→ 国内外で10のアワードを受賞した。
既存のメーカーさんにコンサル的に入るのはビジネス経験がないのでできないと思った。
→ バッグメーカーとして新しいモノづくりに挑戦した。
→ 今から考えると無謀だった。苦労しながらなんとか生き延びてきた。
・ワールドビジネスサテライトで取り上げていただいた。
-社員がアイデアを出すわけではない。
-商品のコンセプトからデザイン、色、大きさなど、すべて消費者の意見を採用する。
-消費者がオンラインでアクセスして簡単に提案が可能できるようにした。
-消費者からの票が集まればすぐに商品化される仕組み。
・バッグメーカーとして、バックがどうやって作られているんだろう？ということから調べた。
職人探し、生産管理から販路開拓・EC販売まで、最初の半年くらい毎日飛び込み営業を
やっていて、断られまくった。
・2年間で49点の人気商品をプロデュースできた。
・遭遇した課題：
革新的な仕組みを志向するあまり、自社でコントロールできる以上に他者の確信をアテにする
仕組みになっていた。（ユーザの声から次々にヒットが生まれる仕組み）
・乗り越えられた理由：
- 創業時から一緒にやっていた田中の一言「私はもっと頑張ってみたい」という一言に勇気が出た。
- 創業時から一貫してビジョンがブレなかった。
・2011年からFacebookを活用したマーケティング支援を強化した。
→ 新しいマーケティングを今も追及している。
２．新サービス企画概要ユーザのアイデアから世の中を変えるような商品・サービスを次々と生み出すようなプラットフォームを作りたいと思っている。
・背景：
過去に３年間に、仕事以外の時間に、同等のものが市場にないために製品改革を行ったことがある人
→ 3.7%（係長や主任として働く人と同じ人数。割と多い人が熱意を持っている）
・この1ヶ月でも、あったらいい、という情報発信は10万件/月ある。
・ユーザ参加型商品開発の全体構造を考えたとき、ユーザに革新的アイデアと熱意を持って製品を開発してもらっても、5%しか他の人に評価されていない。
→ 取り入れるのに躊躇してしまう。
→ これを改善していかないとユーザ参加型商品は難しい。
・アイデアを思いついた人が気軽に投稿できる場所を作りたい。
それに対してすぐに反応する共感のコミュニケーション連鎖がおきていくような仕組みを
作ることによって、企業が集まってくることを前提に考える。
企業が集まれば、もっとアイデアを投稿してくれるようになり、成長できるようになる。
思いついたときにすぐその場で投稿できるような仕組み、投稿したらすぐ反応が返ってくる
仕組みについて議論している。
３．エンジニアさんに期待すること・ビジョンに共感していただけること
・仲間として一緒にわくわく楽しめること
・技術的な視点から、サービス企画やビジネスモデルにも携わっていただき積極的に携わる人
・じっくり議論してわかりあうことをスタンスにしているので、それに合う人
Startup Dialogダイアログでは、参加者が気になり事項を付箋に書き出してそれをホワイトボードに張り出し、分類が似ている人たちで集まって議論を行いました。
私のテーブルでは、以下のテーマについて話し合ったりしました。
・スタートアップでサービス作るとき、エンジニアがいないなら社外から呼んできてもよいのでは？
・スタートアップをやる上で、どんなエンジニアが求められるのか。（スキル等）
実際に企業されている人の話とかも聞けて有意義でした。
最後に、LeanStartupJapanの和波俊久さんから一言・エンジニアとしてどうなるべきか、創業者としてどうあるべきか、という肩書きが出てる時点で違和感がある。
・肩書きに応じて平行で仕事をしている瞬間は、スタートアップではほとんどない。
・イメージとしては、ベンチャーは30日出勤して、プログラマーがコーディングしているのは1日か2日くらい。その期間で、20日間かけてやるような仕事を仕上げるイメージ。
・残りの28日間は、他の人と一緒にいろいろやっているのが、良いチームである。
・肩書きを捨てて、「代打のプロ」のように2打席くらいでホームランを確実に打つプログラマが最高にイケてる人である。
感想：間近にスタートアップで経営されている人の話が聞けたのは刺激的でした。
ダイアログの時間に、実際に起業されている方にお話を伺った際、こんなことをおっしゃっていました。
「スタートアップをやって5年かけて到達する位置に1年で辿り着くために、ビジネススクールに通った。お金を投資して早く高みに辿り着けるなら、躊躇無くその道を選ぶ。それが私のやり方だ」
大体、こんな感じのことをおっしゃっていたかと思います。
なるほどなぁー、と思いました。
あと、その方は一般企業で普段は働きながら、別でスタートアップも平行でされているとのことでした。
いわゆる副業に近い形でしょうが、これも驚きでしたね。
そういう仕組みで回せるポジショニングを考えたスタートアップにしているとのことでした。
私が普段参加しているエンジニアチックな勉強会とは違い、こーゆう勉強会も凄く新鮮ですね。
非常に刺激を受けます。社外の風を感じるヒトトキ。
発表者様、運営者様、会場提供者様、ありがとうございました。
2012/11/8(木) 「Enterprise User eXperience Design - ユーザー中心設計の実践 -」に参加してきました。
DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/1931togetter
http://togetter.com/li/403898【参考資料１】Web戦略を成功に導くためのユーザインタフェース設計プロセス（発表者の論文らしきもの）
http://www.unisys.co.jp/tec_info/tr110/11004.pdf【参考資料２】日本ユニシスの「ユーザビリティ&デザイン」に関するサイト
http://www.unisys.co.jp/services/usability/会場は有楽町の「ぐるなび」さんです。参加者は80名くらいでしょうか。
最近、UX、ユーザエクスペリエンス、という言葉をよく耳にするようになりましたが、UXについてほとんど何も知らない状態でした。
ですので、この勉強会は非常に興味がありました。
セッションは前編と後編の2本立てです。
前編：ユーザ中心設計（UCD）のススメ有家正博氏によるセッションです。内容は以下の資料がベースになっています。
Web 戦略を成功に導くためのユーザインタフェース設計プロセス■１．市場の動向日経コンピュータとかIPAでも、ユーザビリティは取り上げられている。
カスタマーエクスペリエンスという言葉もあがってきている。
国の施策・u-Japan政策（総務省） u-Japanとは、ユビキタスネットワーク社会の実現を目指して総務省が2006年から2010年にかけて実施している、ICT（情報通信技術）を推進するための政策。
http://www.kantei.go.jp/jp/singi/it2/dai3/3siryou40.html・e-Japan 日本政府が掲げた、日本型IT社会の実現を目指す構想、戦略、政策の総体。
http://www.kantei.go.jp/jp/singi/it2/dai3/3siryou40.html
■２．ユーザビリティとユーザエクスペリエンス(1) ユーザビリティの歴史1950～1980年代 ・コンピュータ出現から普及の時代。
・専門家がコンピュータを使えればよかった時代。
1980～2000年代 ・インターネットが普及した。
・UI＆ユーザビリティの時代。
・Webのインタフェースの重要性が認識されてきた。
・ユーザ中心設計（UCD = User Centered Design）
・UCDの提唱者である「Donald Arthur Norman」氏の有名な著書： 誰のためのデザイン？
2000年～現在 ・デジタルネイティブ層の出現（目が肥えている）
・ここからがユーザエクスペリエンスの時代
(2) ユーザビリティユーザビリティはISOの中でも定義されている。
ISO9241-11「特定の利用状況において、特定のユーザーによって、 ある製品が、指定された目標を達成するために用いられる際の、 有効さ、効率、ユーザーの満足度の度合い。」と定義されている。
(3) ユーザエクスペリエンス最近になって、ユーザビリティによる対策で効率の改善はできるが満足度には繋がらない、ということがわかってきた。
そこで出てきたのが「ユーザエクスペリエンス」である。
ユーザエクスペリエンスとは、「ユーザビリティの上位概念」である。
楽しく、面白く、心地よく。
■３．ユーザビリティ・エンジニアリング・プロセスの紹介ユーザビリティ・エンジニアリング・プロセスとは、ユーザインタフェースを設計・開発する際にユーザビリティ要件を満たすための開発手法。ユーザエクスペリエンスを実現するための開発プロセスである。
特徴１．UCD（User Centered Design：ユーザ中心設計）に従った設計手法
２．Web UX 5階層モデル
３．ISEP（Infomation Service Engineering Process）
(1) UCD（User Centered Design：ユーザ中心設計）に従った設計手法UCD（User Centered Design：ユーザ中心設計）とは、製品を利用する人にとって使いやすく魅力的なシステムや商品をデザインするための手法である。
UCDは、技術・機能の中心のものづくりから、利用するユーザを中心とした製品作りを行うためのプロセスとして
1999年にISOで策定された。現在はISO9241に位置づけられる。
UCDは５つのタスクに分かれている。
（冒頭の【参考資料１】より拝借）
１．人間中心設計の必要性の特定
２．利用状況の把握と明示
３．ユーザと組織の要求事項の明示
４．設計による解決案の作成
５．要求事項に対する設計の評価
通常の開発だと５．で終わる。
UCDは、５．で評価して設計したソリューションがユーザの要件を満たしているかがキーとなる。
満たしていなければ、２．や３．に戻ってやりなおす。
(2) Web UX 5階層モデル
（冒頭の【参考資料２】から拝借）
一見するとただの1枚の絵に見えるが、裏には表面、骨格、構造、要件があり、底辺には戦略がある。
(3) The Elements Of User Experience
（冒頭の【参考資料１】より拝借）
1.現状調査 フィールワーク・インタビュー、ヒューリスティック評価をやる。
2.現状分析 調査結果を分析する。
3.ペルソナ作成 分析結果をインプットとしてペルソナを作成する。
4.要件抽出 ペルソナ、シナリオの中から要件を抽出してタスク分析し、画面のデザインをする。
5.プロトタイピング それをインプットとしてプロとタイプを作る。
6.評価 最後に評価する。
このループをユーザが満足するまでやる。
■４．ユーザビリティ＆デザインセンターの紹介・ミッション ユーザ中心設計に基づく、エンジニアリングプロセスを遂行する。
・役割 プロダクトオーナ⇔UX⇒開発
・ユーザビリティ支援組織設立までの歴史 2007年 仮想組織として発足
いろんな部署のメンバーが集まって活動を始めた。
ユーザビリティ原理原則の調査から始めた。
2008年 ユーザビリティ評価項目整備
ユーザビリティ・チェックリストを用意した。
これを作っていくうえで、ユーザビリティとは何だ、というのがわかってきた。
2009年 ユーザビリティ・エンジニアリング検討・整備
効率のよいプロセス、ツール群を整備した。
2010年 ユーザビリティセンターとしての運用支援活動開始
ユーザビリティセンター組織化に向けた企画立案
2011年～ 正式組織化
ユーザビリティ＆デザインセンターとなった。
・きっかけ 某自動車会社のデザイン部門を紹介していただいた。
・Unified Designの取り組みを紹介いただいた。
・デザイン専門部隊による「使いやすさ」を徹底的に研究していて、感銘を受けた。
社内を見つめてみると。。。
CUIが多かった。システム開発にUXを考慮しないといけないのでは、と気付き始めた。
ユーザビリティを考え始めて、ある疑問が沸いた。
１．ユーザビリティの良し悪しを表す基準が無いのでは？
２．芸術的センスが無ければユーザビリティを纏めることはできないのでは？
３．対象ユーザなど前提次第ではユーザビリティは違うんじゃないか？
４．画面レイアウトの彩色は人の好みに左右されるのでは？
まず、ユーザビリティって何だろう？なぜユーザビリティなんだろう？というのを調べてみた。
(1) ユーザビリティってなんだろう？ 顧客満足度の重要な要素である。
ISO-9241-11
ISO-9126-1
(2) なぜユーザビリティなのか？ ・技術が急激に進歩・複雑化している。
→ 使う側の人間に配慮したものづくりの必要性が求められている。
機能の充実と使いやすさはトレードオフ。
・想定利用者ごとに求められるユーザビリティは違う。
→ プロが求めるユーザインタフェースと、一般人が求めるユーザインタフェースは違う。
・ユーザビリティ向上の目的は何か。
→ システム負荷の軽減、ユーザサポート費用の削減、など。
(3) ユーザビリティ向上の費用対効果 2001年頃の、ヤコブ・ニールセンの調査によると、より成果を上げるプロジェクトは、10%を
ユーザビリティ検証費用に使っている、とのこと。
電子政府ユーザビリティガイドラインにも、具体的な費用効果が書かれている。
http://www.kantei.go.jp/jp/singi/it2/guide/security/kaisai_h21/dai37/h210701gl.pdf 非常に数値は大事。なぜUXが有効か、エラい人たちに定量的に説明する時に、良い説得材料になる。
(4) 何が起きているか ・
[米国] リハビリテーション法508条 連邦政府が管理するWeb コンテンツは、障害者にもアクセスできるものでなければならない。
これに違反すると訴えることができる。これをチェックしている機構まである。
・
[欧州] ISO13407 人間中心設計の必要性の特定を求めている
・
[日本] 電子政府ユーザビリティ・ガイドラインの発行 http://www.kantei.go.jp/jp/singi/it2/guide/security/kaisai_h21/dai37/h210701gl.pdf 官公庁系の案件は、このガイドラインに遵守しなければ受注できない。
これらの結果から、前述の疑問に対する解が導けた。
１．ユーザビリティの良し悪しを表す基準が無いのでは？
→ No.
経験則に基づいた評価基準、手法があれば判断可能である。
２．芸術的センスが無ければユーザビリティを纏めることはできないのでは？
→ No.
センス以外の、心理学とか人間工学とかで補完できる。
３．対象ユーザなど前提次第ではユーザビリティは違うんじゃないか？
→ Yes.
ニールセン等の調査結果により確認が可能。
ただし、基本となる人間工学や心理学は普遍である。
４．画面レイアウトの彩色は人の好みに左右されるのでは？
→ No.
レイアウトや配色は根拠に基づいた設計が可能。
⇒ SEでも使いやすいシステムを導け出せるんじゃないか？という道が見えてきた。
(5) 次のステップ １．ユーザビリティ原理原則の調査
２．ユーザビリティ改善施策の試行
３．全社適用活動に向けた活動
⇒ これが一番大変だった。
あと、活動資金を確保するのが大変だった。
UCDが会社に貢献できる、ということをエラいさんに説得するためにいろいろ頑張った。
(6) もっとも大きい課題 ソフトウェア・エンジニアリング・プロセスの中にユーザビリティ・エンジニアリングプロセスを
どのように実行するべきなのか、というのが課題であった。
いろんなタスクを循環して回す、というのを↑の図で説明したが、これはアジャイルに近い。
それに対し、ユニシスはウォーターフォールが主流である。
なぜなら案件が大きすぎてアジャイルで管理しきれないから。
・ウォータフォール型開発の中にどのようにUCDを組み込むのか？
・コストはどうやって見積もるのか？
⇒ どこを探しても明確な方法が見つからない。。。
自分たちで作るしかない。
(7) 新しいユーザインタフェース（UI)の進め方 ・要件定義～論理設計まで ⇒ 委任契約
・物理設計以降 ⇒ 請負契約
⇒ 論理設計までにユーザインタフェースを固めるしかない。具体的には、要件定義で決める。
遅くても論理設計までに固める。
物理設計以降は請負契約になるので変えられない。
(8) そして現在 UsabilityからUser eXperience(UX)へを追求しようとしている。
User eXperience(UX) ・使いやすい
・役に立つ
・好ましい
・価値がある
・見つけやすい
・信頼できる
・アクセスしやすい
これらを体系として、２つをテーマとして活動中。
・ユーザ中心のものづくり
・表現豊かなUI
■５．適用事例・【事例１】技術者向けの社内ポータル
当初、誰向けのシステムなのか全くわからなかった。
→ 「開発者向」ということを明確にし、UCDを回してリニューアルした。
満足度調査をしたら、リニューアル前が30%くらいだったのが、リニューアル後に70%くらいになった。
さらにそこで終わるのではなく、アンケートをして改善をしていった。
・【事例２】コールセンター向けの画面
CUIベースで使いづらい。
→ コールセンターの人にヒヤリングしてUCDを回した。
→ 1画面内で操作したい、というヒヤリング結果を反映してタブ切替できるようにした。
女性がメインなので、女性が好感の持てるデザインにした。
・【事例３】デイトレーダー用の画面
配色を黒から白ベースにした。
取引に必要な情報を常に見えるようにした。
後編：UCDの実践小林誠氏
１．ユーザエクスペリエンスとは 製品やサービスを利用することによってユーザが体感する有意義な体験のこと
(1) 機能がある（Utility） 使いづらい、使えない、機能は満たされているけど。。。
↓
(2) 使いやすい（usability） やりたいことは迷わずにできた。探したい情報がすぐ見つかった。特に不満なく使えた。
ユーザがマイナスとなる感情を減らす、という観点で使いやすさを改善していく。
↓
(3) 嬉しい・楽しい（User eXperience） 嬉しい！楽しい！もっと使いたい！友達に勧めたい！
★使うことで得られる有意義な体験★
ユーザに対してプラスの感情を与えられるものがユーザエクスペリエンス。
現在は、まずは使いやすいシステムを当たり前に提供しましょう、というテーマで活動している。
２．ユーザエクスペリエンスの例(1)Piano Stairs スウェーデンの事例。左が階段で、右がエスカレーター。階段を上ると音が鳴る。
(2) The World's Deepest Bin 世界一深いゴミ箱がコンセプト。ゴミを捨てると7秒くらい、ヒューン～と落ちる音が鳴る。
どちらも、面白さを狙っている事例。実際に使ってもらえる。
階段の方は、66%ほど利用が増えた。
ゴミ箱の方は、同じ見た目のゴミ箱より2倍以上ゴミの収集量が増えた。
ビジネス上の目標に、楽しさを利用しているのがユーザエクスペリエンスでは、と思っている。
３．ユーザエクスペリエンスのハニカム構造 Peter Moville/ June 21,2004
それぞれ、何を最優先にするかを検討する必要がある。
どれか１つ欠けてもユーザエクスペリエンスは実現できない。
ユーザエクスペリエンスの実現のためには、以下を意識していく。・ユーザ中心のモノづくり
・ユーザを知る
・利用目的を知る
・利用状況を知る
・ユーザ要求を知る
⇒
ユーザ中心設計実現するためにはどうすればよいのか、という観点でテクノロジーも考えていく。・表現豊かなUI
・デバイスに応じた最適なUI
・軽量
⇒
HTML5, jQuery４．ユーザ中心プロセス（ISO9241-210）とは・User Centered Design : UCD
・エンドユーザのニーズや要求、制約に着目してUI設計を行う
５．事例紹介省略。。。（というか、ブログ書くのに力尽きた）
★感想：ユーザエクスペリエンスはユーザビリティの上位概念である、ということは始めて知りました。
その程度のことも知らずに参加したんですよね。
要するに、あたりまえ品質の一歩上を行く、ということでしょうか。
デザイン、と聞くとセンスがいるんでしょ？ってなりそうですが、そうではないという話も今日ありましたし、
UXはいろいろ可能性ありそうな話だなぁ、と感じました。
あと、やっぱ、妥協する心が芽生えると、もうそこでUXはムリになるでしょうね。
これから何か作るとき、設計するときには、ユーザ観点をもうちょっと意識してみようと思います。
あと、登壇者さんが、お堅いSIerさんだと、発表資料の公開とか難しいのかな。。。
あとから見直したいときに発表資料がないと、けっこうツライですよね。
発表資料が後で公開されるか否かで、聴講中にどのレベルでメモとればいいかも変わってきますしね。
運営者さん、講演者さん、会場提供者さん、ありがとうございました。
-->
