IDEA and Players

ベンチャー企業で働く変なエンジニアが勝手なことを書きまくるブログ

変なエンジニア、2013 Feb, Startup Weekend Tokyoに参加する! 二日目の巻(前編)

前回のブログの続きです。
Startup Weekend Tokyo体験記、二日目の分をお届けします。
でもその前に、前回のブログを読んでいない方のために一応あらすじを。


〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 ※BGM: ST●R W●RSのOP曲
脱・SW童貞のために立ち上がった一人の勇者・オレ。
そしてオレに導かれ、数奇な運命を経て集結した四人の男女(被害者)たち。
彼らに課せられた使命。それは「失敗を共有し、共感し、笑い飛ばす」という前代未聞のサービスを作り上げること。
待ち受ける幾多の困難を前にして、彼らの胸に去来する思いは、愛、友情、はたまた悔恨の涙か!?
さあ、彼らの運命や如何に!? どどーん

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

・・・調子に乗りました。ごめんなさい。

冗談はさておき。
SWTokyo二日目は、このイベントの全日程の中で私たちチームがもっとも悩み、苦しみ、迷い続けた一日でした。
そういう意味ではこの日、私たちはもっともStartup Weekendらしい時間を過ごしたと言えるかもしれません。
他のチームの方々がどのような思いで過ごしたのかは我々が知る由もありませんが、案外みんな同じような気分を味わったんじゃないでしょうか?

あまりに濃密な時間を過ごしたため、この体験記のブログも二日目だけは前編・後編に分ける必要がありました。あらかじめご了承ください。
ともあれ、我ら「Shippai on the go」チームの面々が初日の深夜から二日目に辿った軌跡をお届けしたいと思います。

最初の問題:「失敗共有のニーズはあるのか?」

初日のチーミング終了後、我らチーム一同は会場付近の居酒屋に移動。乾杯もそこそこに、さっそく作戦会議をすることに。
当然ながら、最初に私たちが立証しなければならない仮説はコレ。「ユーザは失敗を共有したいのか?」

「失敗は誰にとっても恥ずかしいもの。それをわざわざ人目に晒すヤツなんているのかよ!?」
もっともな疑問です。これまでの人生で失敗慣れしている私はだいぶ平気ですが、その感覚を人に押し付けるのは独りよがりというものでしょう。
そこで、まずはチーム内で決を取ってみることに。

「この中で自分の失敗を他人に話して平気なヤツはいるの?」と聞くと、私、そして関西系三人組のHiroさん、Junさん、O女史が迷うことなく挙手。ひとり、沖縄出身のiOSプログラマー、Yuuheiさんだけが手を挙げず。「え、だって恥ずかしいじゃんw」と常識的な反応です。

しかしながら、この通り、調査結果を踏まえると、80%の割合で失敗について許容的な人々がいることがわかりました・・・。
・・・って、ちがう!
このチームの面子は特異すぎる!

ほとんどが関西系! こいつらなら笑いを取るためならスカイツリーの上からだって飛び降りかねない!(偏見丸出し)

というわけでここは明日、街中に繰り出してみて、その辺の人にインタビューしてみようじゃないか、ということに相成りました。
ま、当然ですな。

第二の問題:「マネタイズはどうするか?」

さて、インタビューをするにしてもそれなりにしっかりとした質問を用意しておかないと、正しい回答が引き出せないだろう、と考えた私たちは質問のシナリオについてあれやこれやと話し合いました。
ところが、それまでオニオンリングをぱくついていたO女史が突如、怒ったように言い放つじゃありませんか。

「だ・か・ら〜、マネタイズはどうすんのよ? 言っとくけど、ちゃんとビジネスモデルを考えておかないと、ぜったいに優勝できないよ!? いいの、それで?」

さすがStartup Weekend Osaka前回優勝者のO女史。このイベントを知り尽くした者のならではの発言です。その言葉の重みに残りの一同は思わず頭を抱えました。そりゃあ、そうでしょう。あたかも鉛を黄金に変えるがごとく、失敗をお金に変える方法がそう簡単に思いつくようなら、誰も苦労なんかしませんて。

書籍化ビジネス

しかし、じつを言うと、ビジネスモデルのアイデアがまるでなかったわけではないんですよね。このほんの少し前、会場で知り合った親切なフランス人、Madjidことマジさんがこっそり教えてくれたのが、フランス発の類似サービス、
VDM(http://www.viedemerde.fr/)

VDMは失敗談をユーザから集めて、本として出版したり、アプリにしたりして儲けているとのこと。おおっ、ぴったりじゃないか!
この話を聞いて自然と思い出されたのが、日本は宝島社が出版している「VOW」という超有名な本。


※「VOW」についての詳しく知りたい方はこちら:http://portal.nifty.com/2010/06/09/d/

ユーザから愉快な失敗談を集め、こんな風に書籍化して儲ける、というのはどうだろうか?と、私たちも当然、考えたわけですよ。

しかし、このアイデア、どうにもインパクトが弱い。
本屋の売り上げがこれだけ低迷しているこのご時世、書籍化で儲けるってのはあまりにも心許ない商売です。
たとえアプリとして売るにしても、そんなに太い儲けになるとは到底思えません。

禁断の「めぐみ」モデル

やはりここは、何としてでも斬新かつ強力なビジネスモデルを考え出さなくてはなりません。
というわけで、誰ともなく発案した禁断のアイデア。それが「めぐみ」モデル、別名「投げ銭」モデルでした。


※「投げ銭」と言えばもちろんこの人w

他人の失敗に、人ならば誰でも少しくらいは同情するでしょう。いや、当然するはずです、人として!
ならば、そういった失敗に対して善意の寄付をしてくれる人だっているかもしれない!

いや、何も大きな金額じゃなくてもいいんです。百円とか、十円とか、小さな気持ちでいい。
それを投げ銭的に、失敗の持ち主の心を癒すために「めぐんで」あげる。
「めぐんだ」人には相手に対するちょっぴりの優越感。失敗を投稿した人には少しのお金。そして、運営側はそこから手数料をいただく、と。

やった、究極のビジネスモデルができたーーーーーーっ!!!

しかし、ちょっと待て! なんだかやっていることが賽銭泥棒みたいじゃないか?
善意の寄付金から一部をちょろまかす、そんな義援金詐欺みたいな行為が許されるのか? 人として!

そんな良心的な声がメンバーの間から自然と持ち上がったのは言うまでもありません。
産声を上げる間もなく、この黒魔術は封印されることになりました。

だめだ、やはりビジネスモデルが見つからない・・・。

とにもかくにも、多くの課題を残したまま、我々は翌日早朝の集結を約し、各自家路に着いたのでした・・・。

特捜指令!ビジネスモデルを探せ!!

二日目の早朝、SWTokyoの会場が開く前、少しでも多く作戦を練ろうと、都内某所に再び顔を揃えた「Shippai on the go」の仲間たち。
この日に行う予定だった通行人への突撃インタビュー、その質問内容などを一通り確認し終えた後、私たちの話題は自然と「ビジネスモデルはどうするか?」という問題に移って行きました。

「だから言ったでしょ! このアイデアはマネタイズがクソすぎやって!」と、相も変わらず念仏のように言い続けるO女史。えーい、まったくうるさいヤツだ。
「だから、なんとかなるって言ってるだろーが!」と虚勢を張って言い返す私。しかし、昨晩までの自信はとうに消え失せ、自分でもその言葉に説得力があるとは思えるはずもなく。
チームそろって会場に向かう電車の中でも、私の頭の中は、マネタイズ、マネタイズ、とただそればかりに。まったくこれまでの人生、これほどまでにお金儲けについて考えたことがあったでしょうか?

共感 vs 学び

二日目のイベント開始。早速、自分たちのチームの席を確保すると、引き続きビジネスモデルについて議論が続きます。
ここで「失敗共有サービス」というネタが私とかぶっていたという、Junさん(23才・リア充系男子)が口火を切りました。

「ぼくがやりたかった失敗共有って、なんか笑いとかそんなんじゃなくて、失敗を学びに変えて人を成長させる、とかそんなコンセプトだったんですが、そっちのほうがマネタイズしやすいんじゃないですか?」

・・・何という大人な発想。そして何という的確な意見。とても十才以上も年下の男とは思えません。

この発言を受けて、チームのみんなからは次々とアイデアが出されました。

・著名人の失敗談なら、みんな聞きたいだろうから課金してくれるんじゃないのか? たとえば孫正義とか、ホリエモンとか。
・就活とか婚活のようにニーズが高そうな領域の失敗談なら、ユーザが課金してくれるんじゃないのか?
・失敗のデータを大量に蓄積できたら、マーケティング会社とかに売れたりしないか?

などなど。

ビジョン vs マネタイズ

うーむ、たしかに"学び"を軸にした方が芽がありそうな感じがあります。
しかしながら、その分なんだかお固い感じにもなってきました。

サービスから「笑い」要素がなくなってしまえば、それは私が本来抱いていたビジョンとは少し違ったものになってしまいます。
私はこの世界を駆動させている根本原理は、人間の感情とか共感とか非言語的な何かだと思っているので、そこに踏み込むようなサービスを作りたいとつねづね思っていました。
しかし、そういった不確かなものを相手にすると、確実なマネタイズを考えるのがどんどん難しくなってしまうのも、また事実。
ここは背に腹は変えられない、と私は自分に言い聞かせましたよ。

さらなるアイデア出しをメンバーに任せ、私はひとまず、ユーザから集めた失敗データがマーケティング用の商材として売る事ができそうなのか、会場にいる人々に聞いて回ることに。
他のチームを順繰りに回って「すいませーん、マーケティングに詳しい人、いないっすかー?」と聞いていきました。こうやって書くと、なんだか酒屋が注文でも取っているみたいですね。傍目にも怪しいおっさんが、作業中の皆様を煩わせた事、この場を借りてお詫び致しますw

そうやって数人の意見を頂戴した後、さらにもう少し粘ってみようとして、最後にお話を聞いたのがSWTのオーガナイザー、グプタさんでした。
グプタさん、じつはピッチの時から私のアイデアを面白いと思っていたとのこと。なんとも嬉しい限り。

そしてこのときの会話は、私にとって非常に印象に残るものとなりました。グプタさんが私に話してくれたことをなるべく正確に書き起こしてみます。

「今の時代、情報がどんどん簡単に手に入れられるようになっているでしょう? だから、知識とかそういったものは、どんどん価値が下がっていると思います。
 失敗について言えば、すでに東大の先生が失敗学のデータベースを作って無料で公開してます。
 それに、失敗について学びたいなら人は伝記とかの本を読むことのほうが多いでしょう。そういったものが競合相手です。だから、サービスの方向性を"学び"に向けるのは私はオススメしません。
 ハードルを上げてしまうかもしれませんが、共感とか非言語的な価値を掘り起こしていったほうが可能性は膨らむと思いますよ」

自分がもやもやと考えていたことを、誰かがさらっと説明してくれたときの爽快感、経験したことがある人にならきっとわかってもらえるでしょう!
私はグプタさんに手短にお礼を言うと、急いでチームの元に戻り、自分の決意をみんなに伝えました。

「ごめん、やっぱ、笑いだ! 共感をベースにしたサービスでもう一度、考え直そう!」


※その時のチームの反応。しかも四人分。

「・・・で、マネタイズは?」と、呆れたような顔をしてO女史。まったく、お前の興味はそれだけか?

私は少し考えてから、口を開きました。
「・・・こうなったら奥の手だ。

黒魔術の封印を解く!

一同「エーーーーーッ!?」

(後編につづく)

変なエンジニア、2013 Feb, Startup Weekend Tokyoに参加する! 一日目の巻

とうとう、あこがれのイベント、Startup Weekend Tokyoに参加してきました!
いやね、ベンチャー企業に身を置いているくせに、このイベントに参加したことがないっていうのが、じつは前から密かにコンプレックスだったわけですよ。
なにしろスタートアップ界隈ではこのイベント、超有名ですからね。周囲には参加済みの方々も多いし、同僚の一人なぞこのイベントで優勝したことさえあるくらい。

ってな強迫観念に捉われて、悶々とすること数ヶ月。そんな折に、地元・東京で開催されるのを知った以上、もはや言い逃れはできません。
仕事も週末の予定もすべて投げ出して、脱・SW童貞を目指して突っ走ることを決意したわけです。
そしたら、同僚で前回のStartup Weekend Osaka優勝者のデザイナー・O女史が「じゃあ、私もまた参加するわー」などと言い出しやがる。

いきなりの強力なライバル登場に、動揺を隠し切れない自分。
「てめーは一度、優勝してんじゃねーか。今回は大人しく引っ込んでろ!」
などと一回りも年下の女性に食ってかかる私もそうとうアレですな。

一方、「また勝たせてもらいますわー。藤井さん、敵じゃないっすわー」と、まるで余裕のO女史。ぐぬぬ、となる自分。
そんなこんなでStartup Weekendへの初参戦、早くも暗雲立ちこめてまいったわけで。

戦いの始まり

金曜日の仕事を終えた後、O女史と「帰れ」「いや、お前が帰れ」などとイガミ合いながらも共に会場へ。
会場に着くと、まずは国際色の豊かさにびっくり。まあ、サイトがオール英語で、しかも場所が東京とくればある程度予想はしてましたけどもね。
しかも、皆さん超絶フレンドリーw


※方々に名刺を渡しまくるオレ。名刺通り魔の異名はダテではない。

「皆サーン、元気出シテイキマショー!」とかやたらに叫ぶ金髪の兄ちゃんもいるし、とにかくすごい熱気!
缶ビールですっかり良い気分になった私もテンションが上がりまくり、手当り次第にしゃべりまくり、O女史にドン引きされる始末。

「藤井さーん、エンジニアのくせに変にコミュ力高いっすわー、引きますわー、ホント」
えーい、ほっとけ。

ミニゲーム

その後、アイスブレイクを兼ねてやったミニゲームで、会場はかなりカオスな雰囲気になりました。
ミニゲームのルールは簡単。即席で8~9人のチームを作り、与えられたキーワードの組み合わせをもとに、会社のロゴ、ビジネスプラン、コンセプトをチーム内でブレストして作り上げるというもの。
キーワードはその会場内での公募。自分は「牛丼」とか割と無難(?)なキーワードを出したんですが、隣の金髪兄ちゃんはこともあろうに「かめはめ波!」とか言いやがるw
いやあ、ドラゴンボールのワールドワイドっぷり、マジぱねえっすw


※ミニゲーム中の会場

そうやって出された20個のキーワードのうち、各チームで二つを選ぶんですが、これが早い者勝ちという情け無用の過酷なルール。それを聞いた途端、みんながホワイトボード目がけて猛ダッシュ!
そりゃあ、「かめはめ波」とかが当たったらシャレにならないものw

ちなみに私たちのチームで選んだのは「夕焼け」+「Snow」。うーん、ポエミィ。
夕焼けに雪、とくればこれはもうロマンチックしかない!という独断と偏見により、恋人達のためのロマンチックコンサルタントというアイデアをみんなで考え出しました。なにしろ、ロマンチック、これほど今の日本に足りていないものはありませんから!(力説)


※ミニゲームの発表順番を決めるためにジャンケンするオレ。しかもこの後、負ける。


※ロマンチック・コンサルタントについて力説するオレ。

そして「かめはめ波」+「フンドシ」という禁断のキーワードを引き当てたチーム・・・私が思わず心の中で合掌したのは言うまでもありません。

エレベータピッチ

抱腹絶倒のミニゲームで否が応でも会場が盛り上がったところで、時計の針も進み、いよいよ希望者によるエレベータピッチ祭りへと突入。
つまり、自分が考えてきたビジネスアイデアをみんなの前で1分以内に説明するわけです。

もちろん私も挑みましたよ。ピッチ苦手だけども、せっかくならイベントの醍醐味を堪能しないとね。

そんな私が考えてきたのは「失敗を共有して、共感し、笑い飛ばすサービス」というもの。
いやあね、黒歴史の数では決して他人に劣らない私だからこそ考え出せるアイデア、と言っても過言ではないでしょう。
こういった黒歴史も人生のその時々では辛いものですが、過ぎてしまえば良い思い出、酒の席の笑い話ですからね。そういう世界観ってもっと広く作れないかなー、と思ったのがきっかけ。


※「失敗共有サービス」についてピッチするオレ。「いままでたくさんのビジネスアイディアが出てきましたね。でも、ほとんど失敗すると思いますよ。失敗したって良いんです!」と言ったら、会場のみんなが笑ってました。

ま、O女史には「そのアイデア、マネタイズがクソすぎやん!」とか言われましたけどもね。
いいんですよ、ビジョンさえドーンと高くぶち上げておけば、ビジネスモデルなんざ後でどうにでもなります!(多分)

投票


※投票のため壁に貼り出されたアイデアの数々

さて全員のピッチが終わったところで、いよいよ投票の時間になりました。
投票のルールはいたってシンプル。一人三票の付箋紙を持ち、その三票を好きなアイデアに貼りつけていくというもの。
自分で自分のアイデアに投票してもOK。
同じアイデアに三票全部を投票してもOK。
そして、最低でも七票取れなくては、そのアイデアは失格。

私はどうしたかって? 三票全部、自分に入れましたよ。当然! これで、残り四票!
その後、だれか自分のアイデアに投票してくれまいか、と首を長くしていましたが、これがなかなか投票されない。
もうとっくに七票以上獲得しているアイデアもあるのに、一体どうして!? 「失敗」というネガティブイメージはやはりヒットしないのか?
などとヤキモキしている間も無情にも時間は過ぎていきます。もはやこれまでか、と思われた矢先、ピッ、ピッ、ピッと付箋紙が貼られたじゃありませんか! これで、あと一票!
祈るような気持ちで待ち続けること数分、ようやく待ち望んでいた最後の一票が投じられました。そして投票終了。
結果として、ギリギリ合格ラインの七票をゲットすることができました!(しかも、そのうちの三票が自分票というw)

まあ、なんだ? 結果オーライ!?

一方で自信満々だったO女史はまさかの落選。
「しまったー。ビジネスモデルが高度すぎて上手くピッチできんかったー」とは彼女の言。
早々のライバル退場に、思わずほくそ笑む私。

チーミング


※落選を免れたので、意気揚々とチームメンバーを募集するオレ。心なしか周囲の人々の視線が冷たい気が・・・

しかし、投票で生き残ったとしても安心するのはまだ早かった!
なにしろ、次はアイデアを一緒に実現してくれる仲間を募集しなくてはならない。もしも、一定数のチームメンバーが集まらなかったら、これまた失格。うーむ、なんというイバラの道・・・。

「失敗」というネガティブ・イメージのせいか、やはり、どうしても引きが弱い。しかし、世の中にはいるんですよね、こんな馬鹿げたアイデアのために集まってくれる怖いモノ知らずがw

・Hiroさん(Hastler)・・・
 「40才、独身」をネタにたびたび会場の笑いを取っていたナイスガイ。繰り出すネタはネガティブなのに、人柄はめっぽう明るい東京在住の関西人。
 LOVE理論の伝道師として、怪しいDVDとか出会い系情報とかをこっそり教えてくれます。
 Hiroさん、あんたは男だよ!

・Junさん(Hastler)・・・
 関西出身のリア充系好青年。なんと彼とはアイデアがかぶってしまっていたらしい。こんなネガティブなアイデアをかぶせてくるとは見かけによらず、なんとも侮れない青年であります。しかも、急遽差し替えてピッチしたアイデアがゲイ専用SNSFacebookならず「Gay's book」w
 同じアイデアだったんなら一緒にやろう!とチームに誘ったんですが、今考えると何とも末恐ろしい男だわw

・Yuuheiさん(Hacker)・・・
 iOSプログラマー。ピッチでは「世界一ネガティブなCEOになりたい」と話してました。まさに我がチームにうってつけの逸材(私がチームに誘った時、少々迷惑そうな顔をしていましたが)。
 わざわざ沖縄からやってくるという見かけによらない行動力が素敵です。あと名刺入れとか、小物がきれいなオシャレさんです。

これで私を入れて四人。Hastler×2、Hacker×2。
しかし、足りない! この私の壮大な世界観を実現するためにはどうしてもデザイン、それもかなり高度なオバカ・デザインが必要なのです!
そんなオバカ・デザインができるヤツと言えば、思い当たる人材はただ一人。

私は所在なげに立っているO女史に近づくと、腕を引っ張りました。「おい、手伝ってくれよ!」
「はあ!?」と、O女史。「だって、そのアイデアは絶対負けるでしょ! マネタイズがクソすぎやし!」
「わかってねーな! デザインさえよけりゃ後は何とでもなるんだよ! 黙って力貸せ!」
といった押し問答をしばらく続けること数分、最後には「しゃーないなー、もー」と、O女史がとうとう折れてくれたのでした。ふっふっふっ。

こうして、Hastler×2、Hacker×2、Designer×1のドリームチーム「Shippai on the go」が発足したのでした。


※チームメンバーの定員を達成して、晴れて承認を受ける「Shippai on the go」


※ドリームチーム「Shippai on the go」の面々

それにしてもこのアイデアにして、5人のうち3人までが関西系ってのはいったいどういう因縁なんだ!? おかしいよ、関西w!

一日目を終えて

そんなこんなで一日目を終えたのですが、たったの数時間なのに、この濃密さはどうだ!
初日だけで本当に色々なことが起こり過ぎw こんなことが後二日も続くのか!?
ともあれ様々な危機を乗り越え、ようやく船出をした我がチームの行方はどうなるのか? まて、次回!

二日目(前編)はこちら
二日目(後編)はこちら
最終日はこちら

非モテ系エンジニアがデザインとかUI/UXについて勉強してみた

先日、非モテ系エンジニアの身でありながらヒカ☆ラボのUI/UX勉強会に参加してきました。
ちなみに、私にはデザイナーのようにイケてるセンスはありません。むしろ、服装のセンスなど嫁から「この金正日がっ!!」と罵倒されるほどです。
しかし、最近スタートアップに関わる中でデザインとかUI/UXについて色々と思うところが出てきたので、今回の勉強会について振り返りながらその辺りをまとめてみたいと思います。

つくるべきモノをつくる、という話。そして、エンジニアの役目について

株式会社ジェネシックスの藤井幹大さん、坂田晃一さんが自分たちのお仕事をどのように進めているのか、かいつまんで話してくれたんですが、これがじつに実践的な内容でものすごく参考になりました。

特にデザインの進め方として、リーンスタートアップから取り入れた仮説検証のプロセスをぐるぐる回す、という話は、スタートアップ界隈の人間としては「おおっ!」という感じ。
UXデザイン定義書なるものに、まずは具体的なペルソナを決めて書くところなんか、一見するとコレは何かのお芝居の台本なのか、という印象でしたね。
だって人物像の定義に「ITベンチャーで働く総合職。そろそろ情報の発信源となって周りを引っ張っていく必要あり」とか書いてあるんだものw 誰だそれ?w

逆に言えば、そこまで具体的にユーザをイメージして、ユーザ側の課題は何か、ゴールは何か、ということを明確にしてから作るのがデザインなんだ、KPIを計測して自分たちが設計したとおりに機能していなければそれはデザインとして失敗なんだ、というプロ意識の現れなんだろうと理解したわけです。
なんだか「推測するな、計測せよ」という技術者の大命題が思い出されて、思わぬ親近感。

あと、特にスマホアプリの場合、ちょっとした動きも含めてユーザ体験なので、たとえばPhotoshopとかで動かない絵を描いてもそれがデザインにはならないんだ、という話には大いに共感しました。これ、今後はUIについてもエンジニアの責任というのが段々スタンダードになっていく(というより、もうなってる)という話なので、今まで「デザインに興味がない」などと言っていた技術者はけっこう大変になっていくだろうなー、という予感。
いや、自分もセンスはないんですけどw

そういえば、懇親会でお話を聞いた方々のお一人が、アプリの情報設計も実装も自分がやるけど、見た目のお化粧だけはデザイナーさんにやってもらう、と言っていたなー。「私の仕事は実装だけです」なんて、もはや言ってられないよなー、と切実に感じましたよ。

UI/UXって言葉が使われすぎているんじゃね?という話

次に、千葉工業大学の安藤先生がUI/UXDについて講演してもらったのですが、これまた面白かった。*1

あと、すいません、副題は若干嘘が入っていますw でも話にも出たし、最近、わりと自分もそう思う。

真っ先に自分の心をとらえた話題が、UXとUXDをごっちゃにするなってこと。
UXはユーザの個人的な体験。
UXD(User Experiense Designing)はユーザの体験を計画し、それを量産する仕組みを作ること。
やばい、モヤモヤしていたことが言葉でくっきりきっかり説明されるのってやっぱ気持ちがいいわー。

UXDにはたとえば製品がもたらす一時的な体験はもちろん、広報とかで生み出すサービスのイメージなども含まれる、という話を聞いて思わずウンウンとうなずき続ける自分。
この話を聞いたときに今は亡きSteve Jobsが繰り広げた、伝説の「Think different」キャンペーンも、長期的かつ量産的にユーザの体験を計画した、という意味でUXDだったんだなー、と妙に感動・納得したんですよね。

あと、UI/UXという言葉が商業的に消費されていることについて、安藤先生は懸念を示されていました。
その時に引き合いに出された話が、こちらの記事「UIの改悪がUXを改善させる場合」

この記事を読んだとき、自分は単純に「へー、そういう発想もあるのかー」と感心したくらいなんですが、安藤先生はUXの本来の意味を見失っている、と指摘されたんですよね。
「歩く距離を増やしたら、苦情が減った? だからUXが向上した? じゃあ、お年寄りに長い距離を歩かせるのが良いユーザ体験なの? 馬鹿なの?」
と、まあ本当はもっとご丁寧な口調だったんですが、昨今の言葉だけで中身が空の「UI/UX」には憤懣やるかたないご様子で。
このお叱りの言葉は、かなり胸に突き刺さりましたね。もっとユーザについて想像しろよ、数字なんかじゃなくてさ、と言われたみたいで。

「良い体験が何かということを想像できない人間が、他人の良質なユーザ体験を計画できるはずがない」
この言葉が、深い。

この話、最近スタートアップ界隈で流行りのリーンスタートアップなどの、ちゃんとKPIを計っていこう、データドリブンで方向性を見出そう、というアプローチに対して、そういったプロセスはもちろん大事だけども、そもそも到達しようとしているビジョンとか体験とかが抜け落ちたら、人間不在の、ただのデータ至上主義になっちゃうよ、と釘を刺されたように感じられて、心の中で「うおおおっ!!」となりましたよ。

さらに、UXDに携わるものには高い倫理観が求められる、とも仰っていたのが印象的でしたね。
たとえば、某サービスの退会手続きが複雑怪奇でめんどくさいのは有名な話ですが、倫理観がないと「退会者が少ない」=「優れたUI/UX」みたいな、傍目には絶対にありえないような結論にたどり着いちゃったりするわけですから。

他にも「UI/UXは二項対立的に語られる物ではない」とか「デザインとは、ユーザの無意識の期待に報いること」とか、言葉がいろいろと刺さりまくりましたよ。
ごっつぁんです。

最後に

この他にも、パネルディスカッションとか、いろいろと面白い話があったんですが、さすがに全部は書き切れません。
あと、五十嵐悠紀さんの3D技術を使ってぬいぐるみを作る話とかかなりスゴい発表もあったんですが、自分の勉強目的とは微妙にマッチしなかったので、スルーさせていただきました。
この場を借りて、講演をして下さった皆様と主催して下さったレバレジーズの皆様にお礼を申し上げます。

今回、あらためて考えたのは「デザインって何だろう?」ってことですね。

私は自身がプログラマーであるせいか、この世界の最小構成要素は「情報」だと思ってます。「情報」って言っちゃうと味気ないけど、そこにはお金とか、人間の感情とかも全部含まれているので、むしろエネルギーと表現した方がよいかも。経済学なんて、人間社会のエネルギー学みたいな印象があるし。

で、最近はなんだか、デザインって結局、そういった「エネルギー」とか「情報」を的確に伝えることじゃないかって思えてきたんですよね。こう書くと、なんか配管工事みたいだけど、人間とか社会とかを含めたシステムに対する理解がなければ仕事ができない点で違う。*2

プログラムを書くこともコンピューターという特定のシステムへの理解に依存したデザインであることには変わりはないし、たとえば街中を歩いていると、そこら中に誰かによって計画され、実際にデザインされたもので満ちあふれているわけで、自分の手で何かを作り出したいと切望している人間の一人として、デザインというのは本当に心が躍るテーマだなー、と思います。*3

そして、今回あらためて学んだことはこれ。
私たちみんながデザインして、連結された配管はどこにつながっているのか?
私たち、人間に、だったんですね。

*1:なお、安藤先生が講演で使用したスライドは、[http://www.slideshare.net/masaya0730/uiux15uxd-16215263:title=こちら]から見れます。

*2:あるいは、配管工のシステムに対する理解度は、デザイナーのそれと近い可能性もあるけど。

*3:ちなみに私のお気に入りのデザイン成果物は「コンビニ」です。アイデアとか流通の仕組みを含めてですが。

公開バグ票:Rails3+HerokuでJavaScriptの挙動がdevelopment環境と異なる問題

技術者らしく、たまには技術ネタでブログを書こうw
というわけで、最近弊社サービスの開発中で実際に踏んだバグがなかなか面白かったので、分析と解決までの経緯を振り返りも兼ねてこちらにもまとめておきます。
バグの解析って、苦しいけどけっこう好きなんですよね。いろいろと仮説を立てて推理したりする過程がゲームみたいで楽しいというか。
まあ、ネタ的に技術者にしかわかってもらえないでしょうが、知ったことじゃありません、はい。
というわけでいってみよー。

事象:お問い合わせフォームが消える!?

弊社サービスのコラボ(http://www.collabo.in/)のWebページを見るとわかりますが、画面の右側にお問い合わせフォームの見出しタブが常に表示されていて、クリックされるとにゅにゅーっと伸びる仕組みになっています。

ω・`)チラ ←なんか、これに似ている気がする。

ところがあるとき、このお問い合わせフォームのタブが画面のロード完了と同時に、みるみるFadeOutしてついには消えてしまう、という問題が発生。

ω・`)
・`)
)彡サッ

↑こんな感じ。左右逆だけど。

開発環境ではそんな問題が出てなかったのに、本番環境(Heroku)ではそうなるってのは、一体、どういう了見だ!?
というか、こういうバグがあったときこそのお問い合わせフォームだろう!
お問い合わせフォームが消えてどうする! 恥ずかしがり屋さんか、君は!

※ちなみに、本来はステージング環境で摘出するべきだったんですが、バグがあまりに内向的な子だったんで気づくのが遅れました。ホントにすみません。

仮説1:Sprocketsが悪い?

コラボはRails3で実装しています。
で、開発環境(development)と本番環境(production)でJavaScriptの挙動が違う、となるとまずAssetsまわりの設定または処理に何らかの問題があるのでは、と最初は考えました。
特にdevelopmentではバラバラにJSファイルを読み込んでいたのを、productionではSprocketsがそれらをひとつのJSファイルに結合、かつ圧縮・難読化してくれるので、その過程で挙動が変わる何かが起こったのではないか、と疑ったわけです。

Chromeの開発者ツールで該当個所のHTMLを確認すると、属性として「style="display: none;"」が勝手に追加されているのがわかりました。これは、JQuery.hide()が呼び出された場合と同じです。

作戦1:Chrome開発者ツールでイベントを捕捉

探し出すべき犯人は、HTMLに勝手にstyle="display: none;"を追加した何らかのコードです。
そこで、DOMの属性が変更された際のイベント("DOMAttrModified")をキャプチャー、スタックトレースを遡ればそのコードにたどり着けると考えました。
これはChromeの開発者ツールを使えば簡単にできます。

ただ厄介なのが、事象発生のタイミングが画面のロード時の一回限りなので、あらかじめブレークポイントを仕込んでおくことが難しいということ。
そこでJSファイルの先頭に、

debugger;

の一文を仕込んでおくことにしました。
こうしておけばこのコードを読み込んだ時点で開発者ツールが起動するので、楽々とブレークポイントを仕込むことができます。
その後、コード実行を再開させれば見事、犯人が網にかかる、ってわけ。事件解決、めでたしめでたし。

この時点で、私の頭の中では西武警察のエンディングテーマが流れ始めていたんですが、世の中というもの、そう甘くはないようです。

実際にやってみたところ、どうも「debugger;」が読み込まれて開発者ツールが起動し、JavaScriptのコード実行が停止されるまでに若干のタイムラグがあるらしく、その間にある程度のコードは実行されてしまうようなんですよね。
なので、開発者ツールがようやく起動したと思ってDOM属性を確認しても、あわれ、すでに「style="display: none;"」が追加された後。
このバグ、言うなれば、すさまじいスピードで壁に落書きをして、人が来る前に逃げ去るような奴です。
どんなに急いで駆けつけても、残されているのはただ落書きだけ、犯人の姿は影も見えず。えーい、おのれ。

仮説2:他のJavaScriptが悪い?

それにしても「debugger;」を仕込んでいるのに、それより先のコードが実行されてしまう、などということがあってよいのかしらん。
それより他に読み込んでいるFacebookTwitterとかのJSが悪さをしている可能性が高いかも、などと考え始めたのがこの辺りから。
※しかし・・・思考経路を振り変えてみると、自分以外の誰かが悪いはず、という思い込みがアリアリだな、自分w。

この仮説を検証するのは簡単で、HTMLから自社開発のJSファイルの読み込みを削除し、かつ、他のJSファイルはそのままの状態で、同じ問題が発生するかどうかを確かめればいいわけです。

で、やってみました。・・・すると、バグ事象も消えた!

つまり、TwitterFacebookも悪くないんです。疑ったりして、ホントごめんなさい。
ともあれこれで、バグは自社開発のソースの中に潜んでいる、ということだけはハッキリしたわけです。
まずは一歩前進。

作戦2:開発環境で条件を揃えてみる

さて、Chromeの開発者ツールでのデバッグが頓挫したため、次の作戦を考える必要が出てきました。
で、考えたのは「開発環境でバグを再現してみよう」作戦。まさに王道。

バグを再現しようとする過程で原因がわかることも多いですからね。
そこで、
${RAILS_ROOT}/config/environments/development.rb
を次のように修正して、development環境でもproduction環境と同じJSファイルをSprocketsに生成してもらおうと考えました。
諸事情により、"rails server -e production"だとローカルでは起動しないので。

    • [修正前]
  # Do not compress assets
  config.assets.compress = false

  # Expands the lines which load the assets
  config.assets.debug = true
    • [修正後]
  # Disable Rails's static asset server (Apache or nginx will already do this)
  #config.serve_static_assets = false
  config.serve_static_assets = true

  # Compress JavaScripts and CSS
  config.assets.compress = true

  # Don't fallback to assets pipeline if a precompiled asset is missed
  config.assets.compile = false

  # Generate digests for assets URLs
  config.assets.digest = true

基本的にproductionの設定ファイルから該当する個所をコピペしただけですが、serve_static_assetsだけはtrueにしておかないと、RailsがJSファイルを返却してくれなくなるので注意が必要です。
あと、あらかじめ"rake assets:precompile"を叩いて、JSファイルを結合しておくことも忘れずに。

これで、本番環境と同じJSファイルが生成されて、開発環境でも同じバグ事象が発生するはず・・・と思ってやってみると、バグ再現せず。
なぜ!?

仮説3:生成されるJSファイルが開発環境と本番環境でちがう?

ここで、そもそも開発環境と本番環境で、Sprocketsがまるで異なったJSファイルを生成しているのでは、という疑惑が急浮上してきました。
そこで本番環境のJSファイルと、作戦2で生成した開発環境のJSファイルを比較したところ、ありましたよ、犯人の姿が。

$ diff application-96518f0f.js application-994c381a.js | head
2c2
<  * jQuery JavaScript Library v1.9.0
---
>  * jQuery JavaScript Library v1.8.3
8c8
<  * Copyright 2005, 2012 jQuery Foundation, Inc. and other contributors
---
>  * Copyright 2012 jQuery Foundation and other contributors
12c12
<  * Date: 2013-1-14

application-96518f0f.jsが本番環境のもの、application-994c381a.jsが開発環境のものです。
見ればわかる通り、JQueryのバージョンが1.8.3から1.9.0へと変更されています。

見つけた、犯人!
=> 直接原因:JQueryのバージョン違い

なぜなぜ分析1:なぜJQueryのバージョンが違うのか?

しかし、捜査はここで終わりではありません。
なぜなら、JQueryのバージョンがどうして違っているのか、まだ理由がわかっていないからです。

Railsの場合、JQueryのバージョンはjquery-railsというgemのバージョンに紐づいているので、JQueryのバージョンが違うということはこのgemバージョンが開発環境と本番環境で違う、ということになります。
実際にHerokuにデプロイした時のログと、開発環境のGemfile.lockに記述されているjquery-railsのバージョンを比べると次のように違っていました。

開発環境:v2.1.4
本番環境:v2.2.0

しかし、これはおかしな話なんです。
そもそも、こういったgemのバージョンを含めた管理のために、Rails3ではbunlderというものを使っているのですから。
各gemのバージョンをFixするためにbundlerが自動で生成してくれるのが、Gemfile.lockというファイル。
こいつさえgitのリポジトリに含めておきさえすれば、Heroku側で"bundle install"された時にもbundlerがGemfile.lockを読み取って、本番環境でも開発環境と同じバージョンのgemが使用されるはずでした。
しかし、実際にはバージョンが違っているわけです。つまり、さらなる原因追跡が必要です。

=>第二の問題:Gemfile.lockによるgemのバージョン指定が無効になっている

なぜなぜ分析2:なぜGemfile.lockで指定されたバージョンのgemがHerokuで使用されないのか?

なんでだよ、Heroku。
ちゃんとGemfile.lockをリポジトリに入れて、pushしているよ。なのに、なんで無視するのさ!
などと、思わず心の中で突っ込みを入れながらも、Herokuのドキュメントをあたってみたところ、見つけたのがこちら

すぐに目を引いたのが、この文章。

This ensures that all gems specified in Gemfile, together with their dependencies, are available for your application. Running bundle install also generates a Gemfile.lock file, which should be added to your git repository. Gemfile.lock ensures that your deployed versions of gems on Heroku match the version installed locally on your development machine.

ふむふむ、そうだよね。そのはずだ。
しかし、そのすぐ下に書いてある文章で思わず硬直。

If the platforms section of your Gemfile contains Windows entries, such as mswin or mingw, then the Gemfile.lock file will be ignored.

な、なんだってー!!

そして実際にコミットされたGemfile.lockを確認したところ、まさにドンピシャ。

 PLATFORMS
   ruby
   x86-mingw32

"x86-mingw32"ってあるじゃん、おい!

あー、思い出したわー。
弊社サービスの開発当初は私、自宅のWindowsで作業しとったんですよ。その頃は事務所も無かったので・・・。
でー、VirtualBoxとかで動作確認するのが遅くて嫌だったので、RubyInstallerでWindows側にRubyを入れて動かしていたんですよね。
でも、そのうちgemの一部がWindows非対応だったり、いろいろ面倒くさいことが多くなってきたのでVirtualBox上で開発したり、現在愛用のMac Book Airで開発したりするようになったわけです。
この時の負の遺産が、まさかこんなところで現れるとはねー。

つまりは
「開発環境はデプロイ先の環境と合わせろや、このボケがっ!!」
ってことですねー。
まー、基本ですよねー・・・。

スンマセンしたっ!!。

まとめ

というわけで、今回のバグについてまとめてみます。

まず、バグの真の原因は、次の通り。
・Gemfile.lockのPLATFORMセクションにWindows指定のエントリが記載されていたため、バージョン不整合を引き起こしていた。

対して、得た教訓は次の通り。
・開発環境はデプロイ環境と極力、合わせること。
 ※当たり前。本当は開発環境もLinuxにするべきかも知れないけど、Macも一応FreeBSD系ということで許容範囲かな、と思ってる。
  それくらいのさじ加減はあってもいい。

・Herokuのデプロイした時のログをちゃんと確認すること。
 ※といっても、いちいち目視確認なんかやってられないので、bundle installの時のログとGemfile.lockとの突き合わせ確認を自動化したいところ。

とまあ、サービス的にはあんまりヤバくないけど、解析したらばそれなりに奥深い、という技術者のブログにはお誂え向きのバグでしたねー。
もちろん本当にやばいバグだったら、こんなとこに書きませんけどねw

ココまで読んだ物好きなあなたも、きっと様々なバグと出会ってきたのでしょうw
何かしらご参考のなったとしたら、嬉しい限りです。

プログラムの数だけ、バグとの出会いがある。さて、次はどんな出会いが待っているのでしょう・・・

そんな出会い、全然うれしくないけどなっ!!

ド底辺エンジニアが今日を生き抜くための3つの作法

私もエンジニア、という職についてから今年で十年目になりました。
高校卒業後、二十代も半ば過ぎまでいろいろな職業を転々としていた身*1としては、よくまあ十年も続けることができたなー、と感慨もひとしお。
振り返ってみると、大卒でも専門卒でもない、技術が一流なわけでもない私がこの業界で生き延びるには、やっぱりそれなりに工夫というか、考え方というか、戦い方が必要だったなー、と思う訳で、そのあたりについて、ここらでまとめてみようかと思います。
記事の目的としては、これからIT業界で働こう、と思っている学生さんとかの参考になったらいいなー、というくらい。
でもま、これは私が自分の置かれた状況に合わせて決めた処方箋なので、他の人の役に立つかどうかは一切保証いたしませんがw

1.火中の栗を拾う

開発にはトラブルがつきもの。というか、バグのないプログラムが存在しないのと同様に、問題のないプロジェクトなんてこの世には存在しないでしょう。
でも自分の考えだとすでに顕在化している問題って、じつはあまり重要じゃないと思うんですよ。問題として認識できているのならば、それはただ対処すべきタスクにすぎないわけですから。
今まで関わったプロジェクトの経験で言うと、バグを含めて問題を次々に見つけて、早い段階で叩き潰していけてるなーという実感があるときは大抵上手くいっているとき。そういう場合は、発生しうる問題を先読みして、あらかじめ手を打っておくという余裕すら生まれるので、正のループが生じやすいんですよ。

逆に怖いのは、なんか「シーン・・・」とした雰囲気のあるプロジェクト。
まず末端まで落ちてくる情報が極端に少ない、さらには大抵はメンバー間のコミュニケーションも少ない、上からの指示とかに誰もダメ出ししない(できない)、それなのになぜか打ち合わせとかが無駄に長くなったりするw
よくわからないけど何か良くないことが起こり始めている、という感じ。そして、開発メンバーの一部は薄々それに気がつき始めているのだけど、誰も声を上げようとしない、という雰囲気。そんなとき、開発者の本能が声を限りに叫び始めるわけです。「ヤバい!これはヤバい!」ってww

それでも、この世にはスケジュールという物があるので、それとなく開発を進めていくことになるわけですが、当然ながらそのまま平穏無事に終わることはまずありません。大抵は開発も後半に差し掛かったころに、それまで何となくキナ臭いなー、と感じていたことが次々と顕在化して、一気に炎上。
開発者の体制とかリソースとかの許容量を超えるほどの仕事量となって、怒濤のごとくふりかかってくるわけです。はい、めでたくデスマーチ発生。

そんな不毛な状況で過重労働に耐え、うつになったり、病気になったりするなんて誰だってイヤですよね。
だからそうなる前に、たとえ一作業者の立場であったとしても「何かがおかしい」と感じたら、一度立ち止まってじっくり考えてみるべきです。今、自分のまわりで何が起こっているんだろう、何が問題になっているんだろう、と。
そして問題の原因がわかってきたら、周囲の雰囲気なんぞに飲まれたりせず、まずは自分自身がその問題に向かって行動を始めないといけないんですよ。
もちろん、それは自分の手に負えるような問題じゃないかもしれません。でも、何かできることがあるはずです。

何だっていいんです。
たとえばそれは、冗談を言って周囲の人を笑わせることもかも知れませんし、上司に嫌な顔をされても気にせず、直談判することかも知れません。あるいは勝手にパッチのプログラムを書いたりすることかも知れません。

自分から真っ先に行動すれば周囲の仲間も勇気づけられて行動し始めるでしょう。そうすればプロジェクトが少しずつ良い方向へと向かって行くはずです。
他人の指示ではなく、自分自身がプロジェクトを救うんです。強い心で火中の栗を拾いに行きましょう。

2.「知らない」「やったことがない」を恐れない

自分から問題にぶつかっていく覚悟ができたとしても、やっぱり自分にはできないこと、知らないことがこの世にはゴマンとあるわけです。
私なんてほぼ未経験でこの業界に入ってきたもんですから、それはもう、その手の壁なんて日常茶飯事ですよ。いやー、まいったまいったw
だから逆の発想をすることにしたんです。知らないこと、やったことがないことが目の前に立ちふさがった時は、それはちょうど今、学ぶべき機会がやってきたんだ、とね。

それこそ、はぐれメタルがあらわれた、って感じです。
逃がすものかよ、経験値。

すでに誰かが上手にやっていることを、初心者としてレベル1からやっていくというのは、いろいろと心理的な抵抗がありますよね。
恥ずかしかったり、失敗してかっこ悪い思いをしたり。
自分のように恥の多い人生を送ってきて、そういった感覚が他人様よりだいぶ麻痺しているような奴でも、たまに穴があったら入りたくなるわけですからね。わかります。

でも、別に何かの専門家になれとか、世界でトップクラスの人間になれってわけじゃないんですから。
ただ解決したい問題が目の前にあって、そのために不足している知識やら経験やらを埋めることができればいいってだけなので、もっと気楽に、かつドライに考えればいいんです。

それに新しいことを学ぶ、というのは本当に楽しい経験です。
新しく学んだことが、今まで自分がやってきたことや考えてきたことに、また違った「気づき」を与えてくれて、それが楽しいんです。
今までの視点で見えていた世界とは、まったく違う形で世界を見ることができた時の興奮って、経験がある人にならきっとわかってもらえるでしょう。

だから、私はこう言いたい。
まだ、知らないこと。まだ、やったことのないこと。
かかってきやがれ。

3.一歩、前に出る

日本人は長年の間、和を重んじてきたせいか、やっぱり大人しい人が多いな、とよく思います。日本人の礼儀正しさや奥ゆかしさ、そういった気質・美質はものすごく好きだし、自分も日本人の一人として誇りに思ってもいます。
でもIT業界に身を置くなら、いっそ野蛮人になったほうが仕事がしやすいのでは、と思えてくるんですよね、これがww

とくに私のようにキャリアとか技術力にこれといったアピールがない人間が一番やってはいけないこと、それは横並びの列に加わることです。
自分の力に自信がない人ほど本能的に集団の中に身を潜めて安全を図ろうとするわけですが、この戦略にはどうしようもない欠陥があります。
それは、ただでさえ少ないチャンスにますますありつけなくなることです。

仕事は、すでに実績のある人に優先的に回されるものです。その仕事をこなせば、それがまた実績となってその人の信用値が高まります。
その結果、その人にはどんどん重要な仕事が与えられて、その人自身も成長するし信用もますます高まるという正のループになるわけです。

では最初に実績のない奴はどうしたらいいんでしょう。集団の中で息を潜めて待っていればいいんですか? そのまま死ぬ気ですか。

答えはひとつだけ。集団を抜け出し、前に出ましょう。
「自分にならできる!」と強気に言いましょう。実績なんかなくたって。

最初はドブさらいのような仕事しかもらえないかも知れません。それでも文句を言わず、誠実にこなしましょう。
そして、その実績を武器に、また次の機会を狙っていくんです。もしも段々と重要な仕事がもらえるようになってきたら、もうこっちのもの。
その頃になると信用力とか、組織内の政治力みたいなものが徐々に身についてくると思うので、それらもすべて駆使してどんどん上を狙って行きましょう。
もともと武器はそう多くはないんです。使えるものはすべて使いましょう。

戦い方は人それぞれでいいんです。戦う、という決意さえあれば。
勇気を出して、前に向かいましょう。

最後に

日頃、仕事をしながら考えていることを文章にするだけ、と思っていたのに、いざ書いてみると思い入れが強くて、めちゃくちゃ時間がかかってしまいました。
しかも長いww

あえて技術的なスキルがどうこうという話は書きませんでしたが、最後にひとつだけ。
当然ですがエンジニアをやる以上、プログラミングスキルや技術に対する知識は必要です。それもけっこう高いレベルで。
したがって、そういったスキルがなくてもこうすれば食うには困りませんよ、という話じゃないのでそこだけはお間違えのないよう。
エンジニアに技術スキルがあるのは当たり前のことです。

でも技術だけで勝負するってのは、たとえばF1レーサーになるとか、プロボクサーで王者になるとか、そういったことと同じくらい厳しい道のりだと自分は感じているので、プラスαの領域で自分の伸びしろがあるなら、そこをどんどん開拓して勝負していこうというマインドに私はなりましたね。
自分よりも優秀な人々がひしめき合うこの世界で、自分の価値をどう作り出し、社会に届けていくのか。
そういったことを考えるのも、エンジニアの仕事じゃないだろうか・・・などと書いてきれいにまとめてみる。

It is not the strongest of the species that survives, nor the most intelligent that survives.
It is the one that is the most adaptable to change.
━━ Charles Darwin

記事の内容について、ご意見、ご批判、その他なんでもあればぜひともご一報ください!

*1:私の経歴とか生い立ちとかについては、ちょっと黒歴史が多すぎてここにはイチイチ書き切れません。飲み会の席とかでよくネタにするので知っている人は知っているでしょうけどw

SIer系エンジニアがベンチャーで働き始めるとぶつかる壁のリスト

元ド底辺SIerの私が心機一転、スタートアップに参加して約1年半が立ちました。
今後の自分の仕事を占う意味でも、ここらで自分がこれまでに感じたこと、悩んだこと、考えたことを整理しておこうかと思います。
もしも現在、SIer系の仕事をされていて、いずれはベンチャーで働いてみたいという人の参考になればもちろん嬉しいのだけど、ベンチャーってのは本当に千差万別で、ここで書いたことがそのまま他のベンチャー企業に当てはまるとは限らない、ということだけはご了承を。

「仕様」って言うな!

最初の問題はこれ。
SIerにとって「仕様」って言葉は絶対的な意味があるわけですよ。
お客様から要求を聞いて、要件を定義して、「はい、コレコレこういうもの作りますよ。この製品ではこういうことができます。逆にこういうことはできません。よろしいですか?」と約束した結果が仕様だから当然と言えば当然。だからこそ、仕様を定めることに多くの時間と労力を費やすわけです。最終的に納品してみたら、「え、何コレ? こんなものを作ってくれなんて言ってない!!(怒)」とか言われるとか、まーありえないですよね、ふつーw
当時、聞かされた言葉に「バグか、それとも仕様か。そのどちらかしかない」というものがありますが、これこそまさにSIerの命題を言い表しているような気がしてなりません。

しかし、ベンチャーでは「仕様」という言葉を使っちゃダメなんですよ。
なぜなら仕様なんてハナから存在しないから。そもそもベンチャー企業には最初、顧客すらいないんですからね。

あるのはアイデアとかビジョンとかそういったものだけ。それをブレイクダウンしていき、やがて最初の製品として具体化する段階ではたしかに仕様らしきものは定めなくてはならないけど、それはあくまで一時的なものだと言うことを理解する必要があります。
ベンチャーにとっては製品=実験なので、実験の結果によっては素早く修正、ときには丸ごと破棄することさえしなきゃいけません。
SIerの「仕様がすべて」みたいなマインドだとそういった動きについていけないです。それに自分から積極的にアイデアを出し、バグとかのリスクも承知の上で一種の冒険心を持って開発していく、ということもまずできなくなるでしょう。それでは、ベンチャーとしては致命的です。

自分も最初の頃は、「この画面のリスト表示の順序はどういった仕様にしましょうかね?」みたいな質問をしてましたよ。今考えると馬鹿みたいですが、それだけ前職の思考法に染まっていたし、重要なことだと思っていたわけです。
それにしても「仕様」って言葉には、「約束通りコレコレこういうものを作ったんです。それ以外のことは私は知りません!」という責任回避的な意味合いが感じられて仕方がない。まあ、当時は自分もよく使っていたわけですけどねw

ともあれベンチャーで働くならば、自分の頭の中から「仕様」という言葉は削除しておいたほうがいいでしょう。

「品質」ではなく「価値」

SIerの場合の品質とは大体、お客様が希望するものと一致した製品を作り、かつバグがない状態で納品することです。だからこそ、膨大な手間ひまをかけてテストをし徹底的にバグを取り除く訳です。よく言われていることの一つとして、製品に「バグがない」ということを証明するのは、それこそ何億年も費やしても絶対にできないわけですが、とにかくものすごい努力を費やして、その可能性をゼロへと近づけていくわけです。もしもバグによってお客様に経済的損失を与えようものなら責任問題、ひいては賠償問題にまで発展しますからね。当然と言えば、当然のことです。
しかし、納品した後にバグがでない限りは、お客様がその製品を使って最終的にはビジネスゴールに達成できたかどうかまでは責任は持たない、というのが普通でしょう。

一方でベンチャーの使命は、新しい価値、ひいてはビジネスモデルを生み出すことです。
たとえまったくバグのないプログラムを書いたとしても、それが誰にも使われなければ意味がないんですよ。
バグがあってもいい、というわけではないけどベンチャーで働く際には「品質」という言葉の意味をもう一度考え直す必要があるわけです。

何かの本で読んだ話ですが、その昔、初期のMySpaceではHTMLサニタイジングのバグがあって、ユーザが自由に任意のHTMLを自分のプロフィール画面に入れこむことができたらしいんですよね。でも、それがむしろ「自分にぴったりのプロフィール画面が作れる!」とアメリカの女子高生の間で話題になって、MySpaceが広まる要因になったそう。
HTMLサニタイジング漏れなんてセキュリティ観点から見るととんでもないバグで、こんなものSIer系エンジニアからすると、どんな吊るし上げを食らうかわかったんもんじゃない、と想像するだに恐ろしい事態なわけですが(笑)、このエピソードは「バグがない」といったことよりも、ベンチャー企業がフォーカスしなければならない重要なことが他にあるんだ、ということを示す良い例だと思います。

SIer出身のエンジニアはバグに対する恐怖が他の業界のエンジニアに比べて大きいような気がするんですが、その恐怖心を克服して価値とかビジネス的なチャンスに対して意識的にアクセルを踏み込んでいかないといけません。
とは言っても基本的にはバグが出ていいはずもないので、トレードオフを意識しながらクリティカルなところはちゃんとテストを書いておくとか、ちゃんとCI的な環境は用意しておくとか、そういった目配りも重要です。
でも、カバレッジをとにかく100%にするだとか、盲目的に条件網羅試験をするといったようなことはやめましょう。そんなの、ただの自己満足ですから。

スピード、そして作らないこと

スピード、超重要。いや、SIerにだって重要ですよ。だって納期が短いもん(笑)
しかし、違うんです。SIerの場合、納品物の対価としてお金を頂くわけですから、「そんなもの作っても無駄だから開発しません」というジャッジはしにくいわけです。最終的な顧客満足度を引き上げるために、あえてそう物申す剛毅な業者もいるかもしれませんが、基本的にはお客様が欲しいと思う物を作って、結果としてお金が頂ければそれに越したことはないわけで。
なので、SIer系エンジニアは「とにかく作ろう」というマインドになりがち。少なくとも私はそうでしたね。

もちろん素早く形にすることも重要。でも同じくらい重要なのが、作らないという決断をすること。
作るより、作らない方がそらもう格段に速いので。
でも、じつは日頃から色々と情報収集をしていないと「作らない」という意思決定は難しいんですよね。
自分も、ライブラリとか、類似サービスとかの存在をただ知らなかったために作り始めはしたものの、後で存在を知って「ああ、しまった」となったことが何度かありました。
いや、ちゃんと事前にリサーチはしてますよ。しかしまあ、調査しきれない場合もあるので、やはり日頃からの蓄積が重要ということですよね。

あと自分たちのビジネスゴールを含めて、目的意識を明確に持たないとなかなかそういった思考になっていかない。
ベンチャー領域にやってきて、ビジネスゴールの重要さが身にしみましたが、以前はあまりそういったことを考えていませんでしたね。
まあ、SIerのビジネスゴールは顧客満足度を維持しながら納品してお金を頂くことなので、あまり深く考える必要がなかったというのもありますけど。

ともあれ、そういったことを含めて、一番速くゴールにたどり着ける方法をいつも考えないといけませんよってことで。

「分業」より「協力」

SIerの特に多人数が関わる開発の場合、一人一人の役割分担が明確になっていて、効率のよい分業の仕組みが構築されていることが多いと思います。
※というか、そのように体制が構築できていないとしたら、マネージャーの管理責任が問われるでしょうw
しかしながら、そういった体制を長年続けていると、決められた範囲はやるけど、それ以外は一切手を出さないというマインドにどうしてもなりがちです。
そりゃあ、担当外のところに手を出して、結果としてバグを作り込んじゃったら責任を追及されますからね。とても割に合わないw

ところがベンチャーではこういった分業はできません。そもそも、何をするべきか?がわかっていないことだってあるんですから。
自分たちなりに仮説を立て、施策を考えて、やってみて結果を確認する、の繰り返し。
SIerの大規模プロジェクトで事前に作業をすべて洗い出して、工程表を作成しておく、とか今思い出すともう世界観が違いすぎるのですよw
人員だって絶対的に足りないし、対処すべき問題は大抵は複合領域上に存在していて、プログラミングなどの専門知識だけでどうにかできるわけじゃありません。

「それ、マーケティングの領域でしょ。おれ、プログラマーだし」
「そこのHTMLはデザイナーの言われたとおりにしただけ」

みたいな不毛をやっている余裕、ベンチャーにはないんですよ。
重要なのは「自分の強み」を生かしながら、互いに協力しようという姿勢です。たとえ専門外でも下手くそでも、他の仲間にその余力がなければ自分から手を出していかないと仕事が回らないんです。「俺、そんなのやったことねーよ」とかすぐ口にする人はベンチャーには来ない方がいいです。きっと、すぐに心が折れますから。

必要性に気がついたら、まずは自分自身で行動するようにしないと「〇〇が何々をしてくれない」「××がないと仕事ができない」という不満ばかりがたまってしまいます。
何もないところから始めるのがベンチャーなんですから。文句を言ったって始まらんのですよ。

そういったことの一例として、私は毎週、事務所のトイレ掃除することにしています。
事務所の掃除をメンバーに呼びかけた手前、他人がやりたがらないところを引き受けたというわけ。結果、他の仲間たちもしぶしぶ掃除をしてくれていますw

最後に

なんか書いてみたら、思いのほか長文になってしまった。
読み返してみると、なんだかSIerという業種をdisっているような内容になってしまいましたが、そんな思いは全然なく、ただ色々と違うんだよ、ということが言いたかったのです。
SIer時代に叩き込まれ、身につけた論理思考力とかマネジメント力、分析力はきっちり血肉となって今の自分を支えてくれています。あの時代に自分が周囲の人々に助けられ成長したように、ベンチャーという異なった領域でも大きく力を伸ばしていきたいと考えてます。

(苦|楽)しいぜ、ベンチャー!

記事の内容について、ご意見、ご批判、その他なんでもあればぜひとも藤井までご一報ください!

2013/1/15 追記

わりと身近な人向けに近況報告をかねて書いた記事が、想像以上にたくさんの人に興味を持ってもらえたことに、正直驚きながらも感謝でいっぱいです。

頂いたはてブコメントを眺めていて印象的だったのは、SIer業界に対する批判のように受け止められていることが多いな、ということ。
まあ私の書き方もあるのでしょうが、単純に自分がSIer->ベンチャーとフィールドを移した際に、どうしても考えや仕事の仕方を変えなければいけなかった点についてまとめただけなので、各業界についてどーだこーだという気は私自身ありません。
たかだか私の数年やそこらの経験が、すなわち業界の一般解だとは到底思えませんので。

ただ、読んで下さった方々の感想は大変良い刺激になりました。「そういう見方もあるのかー」と感心することもありました。
この場を借りて、私の拙い文章につきあって下さった皆様にお礼を申し上げます。ありがとうございました!

それにしても働き方とか、業界ネタとかに興味を持っている人はけっこう多いのだなー。
よし、調子にのってまた書こう!w

思いついたサービスのネタ

今年のアイデア、今年のうちに。
というわけで、Facebook上のこの投稿でお約束した通り、私が考えついた新サービスのネタを晒しちゃいます。

ちなみに、突っ込みは大歓迎です。ビシバシとお願いします!

サービスについて

とりあえず、めちゃくちゃ簡単なスライドを作ってみたので、まずはこちらをご参照ください。


今回の実験結果

スライドを見ていただければわかると思いますが、じつはFacebookでの投稿がすでにサービスのプロトタイプだったのでした。
結果として、今回の実験では私の100人弱のFBお友達のうち、この記事を書いている時点で17人の方々からフィードバックを頂くことができました。すごい!
まずは皆様のご協力に感謝いたします。

それにしても今回の反応は、他の投稿と比較してもかなりいい成績ですね。
※まあ、普段の自分のメディア力が貧弱すぎる、という話もありますがw・・・。

なんだか、この辺りはすごくWorkしそうな気がしてきた。

ビジネスモデル

知らん!
・・・と言いたいところですが、それではあんまりにアレなのでいくつか。

「ユーザ個人が自分の行動について意思決定する際に、事前にマーケティングしたい欲求があるのではないか?」
今回考えたことのひとつがコレです。
※こういうの専門用語でなんて言うんだろう? そもそも用語があるのか? パーソナル・マーケティングとか?

なので、ユーザ個人のマーケティング行動を支援する対価として課金ができないかな、と。
基本はフリーミアムだけど、課金ユーザは他人からのフィードバックをより素早く、より多く集められるとかそんな感じ。
このへん、現実性があるかどうか自信は今ひとつ。

サービスの狙い

最近の自分が考え続けていることのひとつに、「行動する勇気はどうやって作られるのか?」ということがありまして。

まず第一に、成功体験が自信や勇気の根拠になる、これはまあ間違いないと思っているわけです。
でも、行動したからこその成功体験なのであって、そもそもそういった体験が希薄な人はどうすりゃいいの、という疑問が自分には常にあるわけで。

成功体験がない→自信がもてない、勇気がない→行動しない→さらに成功しない体質へ
という負のループ。
※自分もこのループにハマっていた時期がかなりあったので、とても他人事とは思えないw

これを覆すには、小さな成功体験を生み出し、少しずつ積み重ねていくしかないのではないか、と考えた結果、こういうサービスが頭の中で生まれたわけです。
計画→期待→実行→承認→次の計画という正のループ。

行動しない人々が、行動するように。
自信のない人々が、自信を持つように。

これこそ、自分がベンチャーで働いている理由のひとつなんだよな。

最後に

今回の結果を踏まえて、次段階のプロトタイプを年始の時間を使って組んでみようと考え中です。
ご助言、フィードバックなどあれば是非とも藤井までお知らせください。