『第32回すくすくスクラム 〜スクラムを学ぶ方法〜』ノート

2012/06/29に開催された『第32回すくすくスクラム 〜スクラムを学ぶ方法〜』のノートです。
"スクラムを学ぶにあたって直面するであろういくつかのケースの中から、自分が話したいケースについてグループを作り、グループ毎に話し合いを行う"というのを2セット行いました。

自分が参加したテーブルの話だけでも、持ち帰れるものがいろいろありました。なのでつい油断してしまったのですが、各テーブルの話し合いの内容については、全く気に留めていなかったという　…自分のノートを整理しているときも、それぞれグループ毎にどんな話をしていたのだろうか、ということがたびたび気になりました。勉強会が終った後に皆でしばらく雑談する時間があったので、そのときに聞いて周ればよかったと思いました。せめて成果物（模造紙）の写真くらい撮っていれば　…誰かのノートに期待します。



◆勉強会の大まかな流れ

1. 勉強会の趣旨の説明
2. ウォームアップ
3. 話し合いのテーマ
4. 話し合いその1
5. 話し合いその2
6. まとめ
7. 勉強会（紹介）LT




◆今日のテーマ"スクラムを学ぶ方法"について

・"Scrumをやる"話ではない
・スクラムやアジャイルで「お客様が何かを作りたい」というときに何をしたらいいのか？というのを学ぶ。
・Scrumの開発手法を現場に導入するためには何が必要なのだろうか？


◇背後にある考え方

・"導入する"ことは現場に非常に依存する
・声の大きい人、力の強い人、同僚にだいぶ依存する
・それを乗り越えることが導入するために必要な要素のうちのひとつである



◆忘れないでほしいこと

・一人で仕事をしているわけではない
・誰のためにものを作るのか？という視点
・Scrumを導入することを目的としてはいけない



◆次のケースから、話し合いたいテーマを決めます

・1. 社内で一人で始めようとするケース
　・1-a. なにから初めて良いかわからない
　・1-b. 上の人をうまく説得できない
　・1-c. スクラムが全ての問題を解決してくれる

・2. 上から言われて、はじめるケース
　・2-a. 権限委譲してくれない
　・2-b. 上司の解釈と微妙に異なる

・3. 誰かと一緒に始めようとするケース
　・3-a. なにから始めてよいかわからない
　・3-b. 友達と解釈が異なる

・4. すでにAgileって言っている人がいる
　・4-a. スクラムマスターがPM
　・4-b. ツールやプラクティスの話しかしない

・5. お客様にはWFといっている場合

・6. 完璧なAgileの開発をしたい

・7. お客様にScrumでやってほしいといわれた

・8. なぜScrumが良いのか分からない

・9. 巻き込み力が足りない



◆話し合い1回目 / なにから始めてよいかわからない

◇考え方
・アジャイルは『ある』『ない』ではなくて度合い
・マインド重要


◇始める
・チームに問題意識があったときに手法を入れるときはうまくいく
・いいタイミングで仕掛けるとアジャイルよくね？と思う人が増える
・先輩に働きかけてそこから推進してもらう


◇問題について
・（問題があるのにそれを）問題だって思ってないことが問題
・（漠然と認識を共有している事柄について）声に出して話をすることは重要
・問題がないところでやっても意味ない。相手がやらされ感を持ってしまう
・問題じゃないときにアジャイルを入れていくのは怖い


◇未解決の疑問
・アジャイルじゃない人が沢山入ってくるときどうするか？
・問題を表面化させることが必要？


◇プラクティスについて
・（スプリントで）実現するフィーチャを決めても、緊急の対応でぐだぐだになる
・インセプションデッキは作るのに時間がかかるけど重要
・コミュニケーションの問題でプロジェクトが炎上した。振り返った結果、朝会をすることになり、それで上手くいった
・バックログが一杯になったら減らすことを決める
→「いらないからやめよう」だと喜ぶ
・フィ－チャ作るチームと既存の問題に対応するチームに分けると、割り込みを回避できる
→でも人数が少ないとそれはできない
・少数人数のチームで一週間毎の振り返りは期間が短い
・振り返りはすごい重要。振り返るとすごいアジャイルになる



◆話し合い2回目 / 巻き込み力が足りない

◇巻き込む自分
・ある程度身銭を切って見せる。そこまでやらないとのってこない
・興味を持った人を引き込む
・根気良く伝えていくと伝わる
・自分がわからないことを押し付けてはいけない。
・誘いのうまい先輩のスキルを盗み、巻き込み力のある人になる


◇巻き込まれる相手
・かっこいい先輩がいると、学ぼうという気になる
・どういう人に働きかけるかによってアプローチが違う
・巻き込み力がある人を巻き込む
・（周囲が受動的な場合）自分がアジャイルできることが前提。やって見せたり、フォローできることが大事
・（周囲が能動的な場合）一緒に学んでいくやり方でもよい


◇巻き込むこと
・ワークショップの写真を見せると興味を持ってもらえる
・信頼をどれだけ稼ぐかが大事。巻き込むというより引っ張っていく
・本を配っても興味ない人はそもそも読まない
・楽しそうな感じを見せることが大事


◇価値観
・うまくいかなかったらやり方を変えたり対象から外す
・休みの日まで仕事のことと嫌がる人はいる
・楽しくないことは続けられないが、成功体験を与えることで続けてもらえる


◇組織
・なんちゃってアジャイルでメタメタになったところは、アジャイルに拒否反応を示す
・社内のあちこちに仲間がいても、各自ばらばらのプロジェクトだと苦戦する
・上司を説得することが重要
・大事なのは強敵と戦わないこと


◇アジャイルについて
・"アジャイルが良い"とは言わない
・"うまくいったこのやり方、実はアジャイル"と持っていく
・アジャイルがバズワード化している
→興味がある人ならアジャイルといってもいい
・そもそもアジャイルはスタンスなので、名前を出す必要はない
・これをやったらアジャイルというのものはない



◆勉強会紹介

◇スクラム道

◇スクラムプロダクトオーナー勉強会

◇すくすくスクラム






すくすくスクラム様、VOYAGE GROUP アジャイル戦略室様、ありがとうございました。

『【shibuya meets tech 4】アナタに一番合うアイデアの生み出し方、 育て方、ゴール』ノート3

2012/06/07に開催された、『【shibuya meets tech 4】アナタに一番合うアイデアの生み出し方、 育て方、ゴール』ノートの最後の1/3です。

20120607 shibuya meets tech vol. 4

講演者

Appcelerator Inc.　増井雄一郎氏

株式会社ユーザーローカル　閑歳孝子氏

司会者
渋谷lab　鈴木氏

主催
渋谷lab

会場
Lightningspot

◆theme / 体験談。開発でつまづいたとき

増井

「Zaimの開発でつまづいたときにどう対処したか？」

閑歳

「どうしたかな？　…すごい考えつくすところがあって、どうしても駄目ならあきらめるというところまでは考えますね。なんとか自力で頑張ろうというところがあって。

ググって駄目だと諦めがつく、その為に見るというのを最近覚えたんですけど　…どうしても分からないところとかをググってみて、誰も解決していないと『あーみんな駄目なんだな』というので諦めがつくという。同じところで悩んでいる人がいっぱいいるんだな、というのが分かるんです」

増井

「僕は平均して5個から10個くらい作りかけのものがあるので　…詰まると他のものにスイッチしして、しばらくたって見直してみるとうまく動いたり、新しいライブラリがでていたり、ライブラリのバージョンアップで解決してくれていたりとか。ストレス解消も兼ねて、躓いたら他のプロジェクトに移ることが多いですね。

閑歳

「私の場合はデザインに逃げますね。デザインも自分でやるので。デザインができていないとすごいモチベーションが低いんです。デザインが入ると『あっ、もう少しでできる』という気分になります。

コードを書いていてちょっとダメかもと思ったら、デザインを入れて　…それで『もう少しでできる』というのと行き来しています」

◆theme / 体験談。日米のビジネスの違い

増井

「ユーザの種類や行動がかなり違います。例えば写真をシェアリングする場合、アメリカなどの国の人は絶対に自分や他の人などを入れて写真をとるんです。食べ物をとるなら食べるところにして絶対に人とものが入るようにしていたりとか　…日本人って基本的にはモノが動物しか撮らないんですよ。ほとんどフレームには顔を入れないって感じで。

そういった部分の違いというのはやってみなければわからないし、それでサービス設計も変わってくるので、そういう意味で海外向けのサービスをリリースするというのは面白かったですね」

閑歳

「プロモーションの違いもあるんですかね？　TechCrunchとかでスタートのページを見るんですけど、日本と明らかにつくりが違うじゃないですか？あっちではこういうのがウケるんだろうな、というのは分かるんですけど、ピンとこなくて…」

増井

「特に思ったのは、海外で載るか載らないかというのはほとんどコネなので。ページを作るのもPR媒体に頼んでいたりするので　…シリコンバレーなんかは、けっこういいものを作ると取り上げてもらえるみたいなイメージがあるのですが、そういうのはほとんどなくて、ほとんど大人とお金の力で解決しているような感じは強く受けました。

もちろんコネだけではいけないと思うんですけど、コネがないと、そもそもいろんな人に見てもらえないというか　…一番始めのパブリシティも確保しにくい。ここは日本より難しいかもしれないですね」

◆theme / 公私の切り分け

増井

「ぜんぜん切り分けてないですね。MobiRubyは会社に話をして最終的に確認をとった上で完全にプライベート、という形でやっていますね」

閑歳

「私は普通の会社員なので、業務時間内は一切自分のことはやらないようにしています。メールも見ないし　…それをやると申し訳ないかなという気持ちがあるので。家に帰ってからと、土日をずっとやっているという感じですかね」

◆theme / 業務外の活動と仕事との相乗効果

閑歳

「ありがたいことにいろいろ呼んでもらったときに社名を言えるので、なんとか役に立っているという気がします。

うちはBtoBの商材を取り扱う会社なので、あまり知ってもらう機会がないのですが、知りあいになった方から仕事に繋がるということがけっこうあったので　…それはありがたいです。

逆の立場からすると、会社でやっていることはアクセス解析なのですが、家計簿もアクセス解析みたいなもので、データを溜めて分析する、しかも分析するっていうところで、いままですごく頭のいい人達が作っためちゃくちゃ難しい製品が多い中で、すごく簡単に見せるというのはけっこう似ていて、、そんなときに今まで仕事でやってきたことが役に立っているかなと思います」

増井

「今の会社に入るきっかけというのが、今の会社の社員がオープンソースの開発をしていて、そこに僕がコミットしていたからなんです。自分でライブラリを作ってリリースしたりしていたことなどが今の職に繋がっていますね」

◆theme / 個性を伸ばす方法

閑歳

「個性？」

増井

「別に個性なんかないですよね？」

閑歳

「自分のこと個性的だと思ったことあります？」

増井

「言われることはありますけどね、自分で好きなようにやっているだけですからね。人と変わったことをやろうと思っているわけではないんですけど」

閑歳

「個性って難しいですよね。何を持って個性なのかっていう」

増井

「世の中のほとんどの人はアプリを自分で作ってリリースしないじゃないですか？じゃあどうして自分がアプリを作ってリリースしたのか、そういうのを延ばす方法について」

閑歳

「メディアにいたせいもあるかもしれないけど、メディア的な考えをすることが若干あって。

個性なのか分からないんですけど、自分のアイデンティティというか、けっこう思っているのはロールモデルを作ったらだめなんじゃん？と思っていて。ロールモデルがいて、そのとおりに歩いてしまうと、それは誰かが歩いた道で、自分じゃないというか。誰かの真似をしているという風になってしまうとちょっともったいないかなと思っていて。

ロールモデルがいないようなところをあえてやっていくというのは、社会的な意味の自分を作るには結構重要じゃないかなと思います」

増井

「基本的には自分のやりたいことだけをやって、自分のやりたくないことをどうやらないですごしていくかがメインなので。

（中略）

そういう風に自分のやりたいことをやりたいようにやる。という感じですね」

閑歳

「みんなは、そういうことを普通はストレートに言わないじゃないですか。それでダメなケースもいっぱいあると思うんですけど　…そうやってやっていくと、能力があがってとか、こういうところが優れているから、なんかこう、パズルのピースみたいに、ここは上がっていてここは下がっているけどこことピッタリ合うというような、ことが分かってくる気がするので、あんまりその自分が本当にやりたいことというのを隠すというか、我慢しない方がいいんじゃないかなーとは思います」

増井

「ただ、そこは何かが飛び出てないと許されないので、そういうために技術的な部分はなるべく担保するようにしていますね」

◆theme / 増井さん個人

増井

「最近は自分の時間のほとんどをMobiRubyに使っています。Rubyは15年くらい使っているんですけど、ぜんぜん貢献（コミットメント）もしていなくて、ここらで何かしたいと思っていた。そういった状態で組み込み用のRubyという新しい実装が出て、まだ触っている人が少ないので、まだ手を出せるところがある。現行のRubyだとみんな手をいれすぎていて、きちんと研究していかないと手をつけられないので　…使える時間の九割くらいをmrubyのデバッグと、MobiRubyを書くのに使っています」

閑歳

「例えば　…キャリアパスとか考えてますか？」

増井

「ぜんぜん考えてないですね。でも、個人的な目標として、今日全部の仕事とかコンピュータが無くなったとしても、明日から仕事ができる、というのが個人的な目標で。そのために、今需要がある技術を持って、どこがその技術を押しているか、それを誰に言えば僕を買ってくれるのか？という三点についてはなるべく常に情報を持っているようにして、何かがあって今もっているものを全て失っても、どこかの会社にしばらく仕事が欲しいんだけど、と言えば仕事がもらえるようには気をつけていますね」

閑歳

「それはプロデュース力というか、自分をうまくコントロールするという感じなんですかね」

増井

「コントロールするというよりは、どちらかというと売り先を探すほうですね。

人と合うのがけっこう好きなので、あちこちの会社にさっきのリストをもって遊びに言ったりとか、そういうのが好きそうな会社があったら、全然関係ない会社でも「ちょっと遊びに行きたいんですけど」と言って遊びに行ったりとか。そういったことはかなり細かくやっていますね」

閑歳

「10年後とか20年後何をしているかとか」

増井

「全然想像つかないですね。そもそもこんなふらふらした生活をするとは考えていなくて。普通は年齢が上がると生活ってどんどん安定するじゃないですか？　ちゃんと就職して、結婚して子供ができてと、ある程度普通に線がわかるじゃないですか。結婚してからずっと不安定さがあがっていってて、どんどん明日がわからなくなる。前は1年後何しているかはだいたい見当がついたのですが、最近は半年後にどこで何の仕事をしているか想像つかないレベルになっています」

閑歳

「それはそっちのほうがぜんぜん楽しいという感じもあるんですよね？」

増井

「そうですね。ぜんぜんそこらへんはストレスにならないので。普通の人はストレスになるらしいのですが僕はストレスにならないので」

閑歳

「1年後の自分が全く同じことをやっていたら、けっこう絶望しますよね？」

増井

「まあそうですね。フリーランスでも、ある程度長い仕事を請けるじゃないですか？　メンテナンスも含めて1年とかって。　僕はメンテナンス仕事が好きじゃないので、単発の仕事を取るんですよ。メンテナンスはその会社に投げられるようにして、受けないんです。Appceleratorには一年半いますが、こういうことは珍しいんです」

◆質疑応答 1.

参加者

「チームでブレストをやるんですけど、なかなか盛り上がらない。盛り上げ役があれこれ言うことで盛り下げることもよくある話で　…そういうときどうやって発想を広げていくのか、また、ブレストはチームで何かを相談していく部分なので、（チームに）対して教えられるようなことで、何かやっていることがあれば」

増井

「基本的にはチームで発想を0からやるのは難しいと思っていて、ある程度幹の部分ができていて、それにどう味付けをするかはできるが、基本的な部分の考え方というのはたぶん、誰かが主題を作って、みんなでどうもっていくかというように持って行くようにしている。さっきのオープンソースの話もそうですけど、基本的には基礎の部分だけは自分できちんと提示できるようにして、それをみんなで議論していこうと。最終的に全然違うものになることもあるのですが、そういう風に心がけています」

閑歳

「私も増井さんと全く同じ意見で、アイデアを出す場合は一人の思い込みやパワーがあるものの方がうまくいっているじゃないかなーと思っていて。幹の部分は一人の人が考えた方がいいかなと、考えています。

ただ、アイデアがでやすい雰囲気とか方向はあると思っていて　…やっぱりルールが決まっているということかな？　例えば、5分で一人ずつ考えましょうというところから初めて、全員で10分間で意見を出し合いましょうとかやって、どんどん意見を入れていって、最後にまとめるとか、そういう時間とやることのルールが始めにしっかり決まっていないと、一人ずつの意見ってなかなかでてこない。やはり声の大きい人が勝ってしまう、ということになりがちなので。

始めは1人ずつ考えさせて、ちょっとずつ輪を大きくしていくというのが、今までやった中ではけっこううまくいくな、と思います」

◆質疑応答 2.

参加者.

「始めに全員でアイデア出しをやる時間はどのくらい？」

閑歳

「はじめのアイデアを出す時間は短いほうがいいんじゃないか？と思っていて。

あまり長くするより、どんどん3分とか5分で　…学生時代にすごいやらされたんですけど、三分って言われて「矢印を使って新しい表現をしろ」みたいなことを1日何回もさせられたりして、

短い期間である程度プレッシャーがある中でやったほうが、ある程度以上は長くとっても一緒だと思うんですよね。

発想してアウトプットを出さなければいけない、というところを最初に鍛えたほうがいいのでは？と思う。自分はそれがあって助かった部分がけっこうあったので。短い時間でどんどん回すやり方を鍛えた方がいいかなと思います」

増井

「僕はあまりみんなで考えることがそんなになくて。ただ、いきなり3分ていわれて考えるのも難しい気がするので、そこは少しずつ時間をせばめていくとか。あとは、急に思いつくというよりは、自分は浅く長く考えるのが多いんですよ。自分で何度も何度も読み返して膨らませるというやり方をするので。ある程度長くとって、その間だらーっと考えているっていう方をとりますね」

閑歳

「あとは、自分では使ったことがないんですけど、アイデア用のトランプみたいなやつとか。アイデアのわけ方とか、同じものを分類するとか、無意識にやっていることが書いてあるような気がするので、そういうツールを使うのも手かなと思います」

◆質疑応答 3.

参加者

「アイデアって出そうとしても出なくって、逆にとりあえずいろいろ作ってみてユーザからだめだしを食らっていく中で、じゃあこここう変えようかな？というひらめきって多いと思います。

なんでこういうことを言うかというと、自分自身がいろんなスタートアップのイベントに出て、アイデアを出そう出そうとして出すのは難しいと。逆に、とりあえず作って小さく回してみて、そこで改良のアイデアが出てくるというのがあって　…アイデアを出した後に検証とか改良とか、そういうポイントについていつも心がけていることは？」

増井

「とりあえずリリースして細かくまわしているプロジェクトがあるのですが、私たちが思っていたこととユーザの行動がかなり違っていて、ある食べ物の写真のシェアリングのアプリケーションでは、レストランとか外食の写真がすごく多いのではないかと思っていたのですが、実際には家で作ったものの写真が多くて。それは予想外だったので、それにともなって戦略とか、アプリケーションの次のバージョンを練り直したり、といったケースがありました。

特に、多くの人に使ってもらいたい場合は、どういったユーザ層に使ってもらうかで、入ってくるフィードバックとか行動が違うのですが、そういったことはリリースしてみないと分からないので、そういった意味では細かくぐるぐる回すのはひとつの手法。逆に、自分が使いたくて作っているものは、僕が作りたいっていうアイデアがあって、それを使ってくれるユーザを探すという感じなので、前者とは検証の方法も違ってくるんじゃないかなと思います」

閑歳

「Zaimは最初、もっとソーシャルっぽいにした方がいいかな？とかいろいろ悩んだのですが　…蓋をあけてみたらみんな全然『ソーシャルとか興味ないっす』みたいな感じの人が本当に多くて。実際に集まってきたユーザのやりたいことと、始めはちょっとずれているんだな、ということを思ったりしました。

最初はtwitterとかfacebookへの投稿ボタンをけっこう大きくしていたんですけど、『外してくれ』といわれたりとか、本当に普通の人が使っているので『共有することが怖い』という感じだったので、今は右上に追いやってしまっていて。逆にカテゴリとか日付を変更するとか、というところを大きく出したりしています。

一方で、細かいバージョンアップと、大掛かりに中身を直すメジャーバージョンアップは、それぞれ別に走らせています。けっこう改良したりすると、ユーザがダイレクトに変わるというか、数字や声が変わるので、ちょっと出してみてからまた改良しようと思っています」

増井雄一郎様、閑歳孝子様、渋谷Lab様、Lightningspot様、ありがとうございました。

『【shibuya meets tech 4】アナタに一番合うアイデアの生み出し方、 育て方、ゴール』ノート2

2012/06/07に開催された、『【shibuya meets tech 4】アナタに一番合うアイデアの生み出し方、 育て方、ゴール』ノートの真ん中の1/3です。ノートパソコンを入手してからはメモも随分と楽になり、分量も増えました。

20120607 shibuya meets tech vol. 4

講演者

Appcelerator Inc.　増井雄一郎氏

株式会社ユーザーローカル　閑歳孝子氏

司会者
渋谷lab　鈴木氏

主催
渋谷lab

会場
Lightningspot

◆theme / アイデアをシンプルにする方法

増井

「『でてきたアイデアをシンプルにするのが難しい』という質問があったのですが」

閑歳

「よくありますね」

増井

「僕はそんなに複雑には考えられないので、あんまり複雑にはならないですね」

閑歳

「私はシンプルにしないといけないと思っていて　…画面上のボタンの数も含めて、ぱっと見て分からないものとか、使われない機能は無くても同じだし、開発の時間ももったい気がします。目に見えるもの全てすぐ分からないと意味がないと思います。

twitterなんかの名言botでもよく言っている『作るには技術が必要、削るには思想が必要』という言葉が好きで、1回作ってしまうと削るときには作るとき以上のすごいパワーが必要なんです。

で、特にお客様がついていると削った後にすごいクレームが来るので、作る前に必要かどうかを精査して、8～9割が欲しいというものは確かに無いとまずいと思いますが、1～2割が欲しいといっているものは思い切ってきったほうがいいと思います」

増井

「仕事だとその1～2割って声が大きかったりするんですよね」

閑歳

「ユーザの人が言っていることと本当のニーズって別だったりするんですよね。言っているものと本当に欲しいものが違うことはよくあって、　…Zaimも最初はiPhoneのキーパッドを使っていたのですが、途中から自作の電卓にしたんです。そうしたら『元に戻してほしい』という声がたくさんあって

…で、いろいろ考えていくと、そのボタンが前より小さくて押しにくいというのが本質的な声で

前のキーパッドがよかったわけではないんですね。だからそれを大きくして、それでそういう声はなくなったんですけど。

そのままそのとおりを聞くのはたぶん間違いの場合が多いんじゃないかな？と思います」

増井

「僕が作るときは自分用なので、他人の声が聞かないんですよね。他の人の意見を聞くと複雑になりがちなので、そこで聞かないというのはある意味1つの方法だと思いますね」

閑歳

「それは使う人が増井さんに合わせてくれるんですよね？」

増井

「そうですね。僕は使ってもらうことが目的ではないので、ユーザーが増えるよりも自分や一部の人が使いやすければいいので」

◆theme / 上から目線でも就職活動ってできるし、相性って大事

増井

「さっきの増井予約システムも、実はアメリカから日本に帰ってくるときにホームページで仕事募集ってやったらオファーが来て。で、オファーをくれた会社に一斉メールで、『僕の予定はこうなってますので、早いもの順で面接に来て欲しい日をサブミットしてください』って、すごい上から目線のメールを送りまして」

閑歳

「もちろん他社は見えないんですよね？」

増井

「他社は見えないです。見えるようにするのもそれはそれで面白いし、予定年収までサブミットしてもらうとかなりえげつない感じがしていいんですけど　…増井予約システムは完全に自分目的で、他の人の考える余地がないのでシンプルになりました。

知っている人には『そんな上から目線の就職活動はない』といわれましたね。

それが駄目で、『アホなこと』と言う会社は入っても続かないので、そういう意味も込めて作っています」

閑歳

「相性が分かるのでいいと思います」

◆theme / どこから作りはじめるかと、どこでモチベーションが下がるか

増井

「『始めの一歩』という質問がありますが、Zaimはどこから作り始めました？」

閑歳

「まず画面を紙ベースで全ページ書いて、その後にログイン前のページを作ったんですけど、ちょっと欲張ってauthを自作したんですよ。そこはすごい大変で　…twitterみたいにサーバとやりとりするみたいなものをいきなり作り始めて、そこで心が病みそうになったんですけど、そこを乗り越えてからはどんどんページができていくのが楽しくて仕方がなくて」

増井

「僕はもう完全に技術始動なので、HTMLより何よりも、技術的に詰まりそうなところのロジックだけ書いて、とりあえず技術検証が終ってから作り始めて　…デザインは最後にデザイナの人にお願いして作ってもらうとか、最後に当てはめることが多いですね」

閑歳

「ものづくりはどのときが一番楽しいですか？」

増井

「技術的に難しいことが分かっているから書き始める、ということが多いので　…始めの1～2週間が一番楽しいですね」

閑歳

「私は逆で、自分が解決できなさそうな問題を見ると『できないんじゃないか？』と不安になるんですけど　…最後の99から100にするところは時間がかかるので心が折れるじゃないですか？完成度を上げていくところとか、出来上がることがもう見えているし、私はそこが大好きなんです」

増井

「僕は出来上がることが見えるとモチベーションがすごい下がるんです。」

閑歳

「それはすごいエンジニアの考え方ですよね」

増井

「そうですね。プロトだけ自分で作って売ったり、他の会社と絡んで仕上げてもらったりするのが、自分としては一番楽ですね」

閑歳

「今回、真逆で面白いですね」

増井

「技術ドリブンなのか、つくりたいものドリブンなのかでけっこう違いますね」

◆theme / ゴールとそこへのアプローチ

増井

「次は『ゴールの設定』という話ですね」

閑歳

「一番始めに言ったことと被ると思うんですけど、何が目的なのかといったところに近いですかね？」

増井

「僕はゴールは全く決めないで作り始めるのですが　…あるサービスのAPIが使いにくくてそのことをエヴァンジェリストに話たら『そんなに言うならお前が作れ』といわれて　…接続するところのAPIを作ったところで飽きてしまって、最終的にはアプリじゃなくてライブラリだけがリリースされたりとか。

ゴールを設定しないので、途中で身近なところをゴールにしてしまうことが多いですね」

閑歳

「それは仕事とかだと大変じゃないですかね？」

増井

「仕事はゴールがはっきりしているので、モチベーションが下がったからと言ってやらないわけにはいかないのですが　…嫌々やっていることが多いですね。

開発中のあるサービスでは、技術的に難しいところは私、それをサービスにするためのフロントの調整部分は人を雇って、という大人の解決方法を模索しています」

閑歳

「私もそうなんですけど、そういうのが好きな人は絶対にいるので、そこがうまく組み合わせればお互いハッピーですよね。私は逆に絶対に超えられない壁があるとすごいストレスになるので。

今やっていることで言えば、使ってもらわないと意味がないところががあり、指標を持とうかなと思っていて、数字をみるようにしています。自分のサービスはダウンロード数やランキング等を毎日届くメールでずっとウォッチしていたり、AppStoreのランキングもいろいろな自分の知っているサービスのランキングも大体見ていて、結局どういうタイミングで上がっているかとか　…家計簿って『心を新たにして』ってことで3月とか12月の末とかにみんなダウンロードしていて。だんだんとみんな諦めていくんですけど　…後は『来月から頑張ろう』ということで月末とか。

そういうのを見て、『これはこのタイミングで出したほうがいいかな？』というのを最近覚えて　…工夫していくのがけっこう好きです。全体的なゴールはあんまりないんですけど、そういう感じでやっています」

増井

「僕はほとんど自分用のアプリなので、自分が作れるようになったところがゴール。最近はもっと酷くて、とりあえずコンソールから使えるようになったらゴールだったりするので　…全く人にお見せできるような状態でないところがゴールだったりします」

閑歳

「コードの美しさみたいなところはどうですか？」

増井

「動くことが主体だったりするので自分でしか使わないものは汚いですが、PukiWikiやMobiRubyみたいに人に見せるものは相当気を使って書いてます。

MobiRubyは英語圏でリリースしていて質問も英語なので　…だったらコードで分かってもらった方が楽なので、質問が来ないように綺麗なコードを書いています。MobiRubyは設計がなかなか決まらなかったりして、何回も書き直したりしています」

閑歳

「それは"楽しい"みたいな感じなんですかね？」

増井

「かなり楽しいですね。MobiRubyは自分の中でも特殊で、海外での自分の認知度を上げて今後の仕事をしやすいようにしようという大きな目標だったり、技術的にも面白そうで自分でできそうな範囲のものだったりという、2つがあったんです。また、ホームページを先に作るなどのいろいろな人に認知してもらうためのしかけもゴールの1つとしてやっている、という点でも特殊ですね」

閑歳

「ゴールじゃないかもしれないですけど、ユーザの声を重視したいと思っていて。

アップデートすると、使い方とか、不具合とか、ありがとうございましたとか、1日30とか40件とか問い合わせが来るんですけど、そういうのでユーザがどう使っているのを知ることがきるんです。逆に来ないと、使ってもらえてないのかな？と不安になったり。

ただ、先ほども言ったように、意見を真に受けて聞くとあまりいいことにならないと思うので、どんなに言われても、本当に何が必要なのかは精査した方がいいと思います。」

増井

「『自分が手を引く』こと、『自分がいなくなってもチームが動く』ことがゴールというプロジェクトもあって、そうすると、ある程度完成させて手を引くことゴールになります。プロダクトを作るところがゴールじゃないということもありうるということです」

増井

「Zaimをサービスとして続ける限り、自分が関わり続けないといけないじゃないですか？そこら辺はどう考えています？」

閑歳

「私はうれしいなー、という風に思っているんですけど。作ることが一番好きなので、それをやりたいというのはあるんですけど、ずっと伸び続けてユーザが一杯になったときは、『自分が自分が』ではなくなってくるのだと思います。

サービスのことを考えると『違う体制とかも含めて考えなければいけないのかな？』と自分ではうすうす考えていて。私は金融系のこととかそこまで分からないので、そういう人がやったほうがいいのであれば、そういう人に任せたほうがいいのかも、とか最近考えるようになりました。」

増井

「場合によっては組織化とか？」

閑歳

「自分のことより、ユーザに良く使ってもらえるか？　ということを考えた方がいいかなと思っています」

増井

「アプリケーションは配布しておしまいですけど、webサービスは止められないじゃないですか？Webサービスは継続することを考えないといけないので、そういった意味でゴールの設定が難しいですよね」

閑歳

「難しいですね　…やめるときがゴールですね。一種のゴール」

◆theme / モチベーション

増井

「僕は飽きるとやめちゃうので　…モチベーションが低くなった時点でやめたり、その段階で手が引けるようにしていたりとか。絶対にモチベーションが続かないことが分かっていたプロジェクトでは組織化させたりとか…　モチベーションを高くしようというよりは、低くなったときにやめられるようにしよう、ということの方が多いですね」

閑歳

「チームビルディングなんかも含めて、一番始めに設計するってことですよね」

増井

「はい」

閑歳

「私は、自分に自身がないというのが大きくて。自分の中にすごい危機感があるんですね。

…『大丈夫なんだろうか？』というところなど、現状に満足できていないところがすごくあって、それがモチベーションの1つになっています。ものすごく優秀な技術者の方がいる一方で、『自分はなにもできないな』というところがすごいあるので、それを少しでも克服するために『人より頑張らないといけないのかな』というのがあります。

ちょっと関係ないかもしれないけど、頑張っている異業種の人を見るといいと思います。自分からは遠い業種だけど、とても頑張っている人を見ると、『自分ぜんぜん頑張ってない。さぼっている』という気分になるので、そこでモチベーションを保てるという　…同業種だと『自分ってこんなにできないんだ』となってしまいリアルな感じになってしまいます」

増井

「僕は単純にコードを書くのが好きなので、モチベーションとか考えたことがないんですね。高校生くらいまで辿ってもコードを書かない日というのが思い出せないくらいコードを書いていて。

そこには何かに頼るモチベーションは無くて、単純にコードを書くのが好きで　…そういう意味では参考にならないんですよね」

閑歳

「そういう意味では天職みたいな…」

増井

「そうですね。コンピュータ以外のことはここ20年くらい何もやっていないですね」

◆theme / アイデアを形にできる人とそうでない人の違い

増井

「『アイデアを形にまで持っていける人とそうでない人の違いというのは何？』という質問があるのですが　…1つは手を動かすかどうかなんですよね、最終的には」

閑歳

「『これは面白い』というものがあるのに、出さないのは逆にもったいないと思います。そんなに欲しいと思っているのに、出さないまま途中で飽きたり日の目を見ないのってもったいないじゃないですか」

増井

「あとは、けっこう自信がないみたいで　…『自分のアイデアを自分としてはたいして面白くない』と思っていたり『これくらいのことはみんな思うでしょ？』的なところで、実際に形にしないというケースがけっこうあるみたいですね」

閑歳

「周りの人が賛同してくれたり、もうあるよっていうことがすぐわかるので、twitterでつぶやいたらいいと思います」

増井

「それはありますね

（中略）

実際に行動するかしないかが、形にできるかどうかの差である、という気がしますね」

増井雄一郎様、閑歳孝子様、渋谷Lab様、Lightningspot様、ありがとうございました。

『【shibuya meets tech 4】アナタに一番合うアイデアの生み出し方、 育て方、ゴール』ノート1

2012/06/07に開催された、『【shibuya meets tech 4】アナタに一番合うアイデアの生み出し方、 育て方、ゴール』ノートの冒頭1/3です。ノートというか、ほとんど会話のようになってますが…

20120607 shibuya meets tech vol. 4

講演者

Appcelerator Inc.　増井雄一郎氏

株式会社ユーザーローカル　閑歳孝子氏

司会者
渋谷lab　鈴木氏

主催
渋谷lab

会場
Lightningspot

◆講演者による自己紹介

◇増井雄一郎氏

• 昔は PukiWiki というオープンソースアプリの開発をしていた
• 10分でRuby on Railsでwebアプリを作れるという、嘘のムービーを作った（けっこう好評だった）
• 四年前、渡米しiPhoneアプリを作る会社に
• いまはTitaniumを作ったAppceleratorにいて、プラットフォームエヴァンジェリストをやっている

◇閑歳孝子氏

• もともと出版社で書く仕事をしていた
• インターネットが好きで書くより作る仕事がしたかった
• 友人の紹介でwebの受託開発をしている会社に
• 4年前に今の会社（ベンチャー）に
• 会社ではアクセス解析を作っている
• 個人でZaimというスマホアプリを作っている
• 考えるところから作るところまでやっている

◆theme / 自分向け vs 一般の人向け

鈴木

「作る前のフェーズではアイデアとか発想が重要だと思うのですが　…アイデア出しで重要だと思っているポイントは？」

閑歳

「私は作れるようになったのがすごく遅かったんです。作りたいけど作れないというストレスが１０年くらいありました。『作れるようになったら、いっぱい作りたいものがあるのに！』というところから発想しているのでちょっとアレなんですけど…

自分でサービスを作るようになったのは、どこにいっても『あなた企画（の人）でしょう？』と思われていて、自分で作れるということを信じてもらえなかったからです。今は全然違うんですけど、始めはそれを証明したいというのもありました。

気をつけているのは『なんでアイデアを出さないといけないのだろう？』ということ。アイデアを生み出す前に『アイデアを出さなければいけないのは何でだっけ？』というところをすごく考えるようにしています。『楽しみで作っているのか？』『ビジネス的な意味で作っているのか？』『目的みたいなものががどこにあるのか？』とか。

もうひとつ気をつけているのは　…自分が一生懸命になれるテーマを見つけるのが一番大変だということです。自分の『これは本当に解決しなきゃいけない』『これは問題だと思っている』と心から思えるような、問題設定みたいなものや夢中になれるものを見つける、ということです。そのテーマを見つけるのが一番重要で、生み出すのはもうちょっと後だと思っています。

自分は作りたいものが決まっていて、『普通の人が使えるものを作りたい』というのがすごく大きい割合です。なるべく多くの人に使ってもらおうと思っていて　…今の時代は自分の母親くらいの年齢の人でもスマホを使いますが、『そういう世代でもぎりぎり使えるかな？』というのが1つの基準になっています。

できれば『それがないと死ぬ』というくらい、その人の重要なテーマになるものを見つけたいと思っていて、最近だとそれがZaimだったんですけど　…そういう形でテーマを決めることが一番重要だと思っています」

増井

「私は、普通の人というより、もっと個人的な悩みでものを作っていて…　自分でやるときにすごく使いにくい、面倒だとか、そういうものを書き留めていって。

私は基本的にエンジニアなので、自動化できるものは全部自動化したいし、人の手でやらなくていいものは全て自動化してしまいたいという。で、繰り返すようなものは少々面倒でも自動化したい。という思いがあるんです。

そういうものをベースにアイデアを出しているのですが　…自分でこんなものを作りたいという、アイデアリストをウェブに公開していまして。Web上にあるToDoリストなのですが、『こんなのあったら面白いな』とか『こんなのやってるのすごく面倒だな』というものを書き溜めています。

例えば『増井予約システムのサービス化』というものがあるんですが。仕事で『スケジュールのやりとりをするときに『打合わせをしましょう。いつといつが空いてますか？』といったことがあると思うのですが、メールでやっていると返事を待っている間に日程が埋まってしまったりして　…何度もやりとりをしなければならないんです。

それをするのがすごく面倒だったので、自分をものに見立てて空いている時間を予約できるようにして、『カレンダーのURLを送るので、僕と打合わせする日を勝手に予約してください。入れてくれればgoogleカレンダーに入りますので』というものを作ってシステム化したりとかしています。

基本は自分が使うもの。他人に使ってもらうものというよりは、自分が使うようなものを中心に作っていますね」

閑歳

「発想が真逆ですよね。どっちもありというか、やりやすいほうをやればいいと思うんですけど　…私は逆にそういう発想でものを作れない人なので」

増井

「逆に僕は他の人を考えるとものを作れないので　…自分が面倒くさいことを自動化したりとか、私的な思いだけです。

僕は技術なので、技術が主体でものをつくることもあって、何か新しい技術がでたら、『それ面白い技術だな。それで何か作ってみようか』とか。

数年前、『node.js』が出始めた頃に『それ使って何が作れるんだろう』と、よくあるチャットを作って遊んでみたりとか、技術主導のときもけっこうありますね」

閑歳

「私の場合、逆に作りたいもののぼんやりとしたイメージがあって、それを実現するためにはどうしたらいいんだろう？みたいな風に考えていって。

私はスキルセットにすごい足りない部分があるので、スマートフォンで家計簿を作りたいと思ったときに『Objective-Cだと書けないところがある。どうしよう？』となって、Titaniumを使おうかなという　…それは本当に、自分のスキルセットとなんとかやりたいことを実現するためのツールとして、探して選んだというところがあって。

本当に、アプローチの仕方は真逆なのかな？という気はしますね」

増井

「自分として『ほかの人むけ』というのはないのですが、人の『こんなのがほしいな？』というものを『じゃあ形にしてみようか』とか『もう少し深堀してみようか』というの話はたまにあります

（ここで、友人の為に考えたサービスの話をする）」

閑歳

「それはどう作られたんですか？」

増井

「いや、それを作るモチベーションがなくて　…作ってはいないですね。面白いだろうな、とは思うんですけど」

閑歳

「聞いていて、私はぽんぽん作れるタイプではないのかな？と思って

…Zaimを作るときも準備期間というか、一番始めに作ろうと思ったときに、TechCrunch.comを1年分くらい読んだんですよ。『シリコンバレーでどういうサービスが流行っていて、いまどういう状態なのか？』『それは日本でどれくらい流行るか？』というのをひたすら見ていて　…で、『どうやったら日本で流行るものが作れるのかな？み』たいなところをひらすら考えて

…で、『家計簿を作ろう』と思ったときも、あまり人には言わないで。ずーっと1人で考えて、外にはあまり出さなくて。これ以上考え付かないというくらいになったら、ちょっとずつ友達とかに聞いていって、そこで始めてブラッシュアップされるというか。ちょっと考えて簡単にでてくるようなものは、いちおう全部を自分で考えてからにしよう　…というような感じですね」

◆theme / 技術ドリブン vs リリースドリブン

増井

「僕は（閑歳氏とは）逆で、webに出しているアイデアリストもそうなんですけど、思いついたら外に書くしtwitterとかにもがんがん書いて。

さらに、さっきのリストはiPadに全部入れてあるので、お客さんと打ち合わせしたときとか、懇親会とかでそれを出して　…人を引っ張り出して話を聞いてですね、でフィードバックを得て、自分で詰めて言って、面白そうなものを他の人のアイデアも含めてやっていくという形で。

基本的に自分で考えるよりは、話して反応を見て考えることが多いですね」

閑歳

「（Zaimは）今は運用なので、そういうスタイルをけっこうするんですけど、始めのアイデア出しのときはそうするのが苦手なのかな？　と。今はユーザからの意見などで助けられている部分もあるので。

…Zaimは一般ユーザというか、あまり詳しくない人を相手にしたかったのですが、そういう人達に

紙ベースの画面イメージを持っていっても、あまり想像が付かないみたいで。『えーこれどうやるの？』みたいな。やっぱり動くものを持っていって初めて、彼女達は『こういうものなのね。ここがダメだと思う』と言ってくれたりするので　…ある程度作っていかないとダメなのかなという意識はけっこうあります」

増井

「僕のアイデアはテック系のものが強くて一般向けではないので、とりあえずフローチャートを見せれば概ね納得してもらえるんです。最悪ホワイトボードがあれば事が成り立つ、というのもありますね」

閑歳

「アイデアの種類によって適切なやりかたがあるのかな？っていうのを、話を聞いていて思ったんですけど」

増井

「このまえニコニコ超会議で話をしたのですが、その時に『作るのは面白いんですけどアイデアがないんです』ってエンジニアがけっこう多かったんです。でも、よくよく聞いてみると自分ではアイデアだと思っていないだけで。『これ使いにくいんです』と言う人に『ではどう改善したらいいと思いますか？』と聞くとけっこうアイデアが出てきたりして。

不満ドリブンというか、『こんなの使いにくい』とか『いつも同じことをやっていて面倒くさい』とか、それを改善していくのは1つのアイデアになるんじゃないかな、と思います」

閑歳

「私はまたけっこう発想が違っていて　…リリースドリブンなんですよ。もしプレスリリースで取り上げられるとしたら、どのように取り上げられるか？とか、どういう見せ方になる？というのを想像しながらやっているというのはありますね」

◆theme / アプリのリリースとその取り上げられ方

閑歳

「機能拡張するときとかも、『これくらいのネタだとプレスには載るけど、これくらいの小ささだと取り上げられないかな？』というのがあるので、リリースになるような合わせ方をするよう気をつけています。

Zaimもアンドロイド版を作っただけではちょっと弱いかなと思ったので、急いでevernote Syncみたいなものをつけて"android + evernote"という形でニュースにしてもらったりとか、けっこう工夫しています」

増井

「そこはリリースすることが目的だから、ですよね」

閑歳

「いや、リーチを上げることが目的だからですね」

増井

「僕は自分が目的なので、自分が使える満足してしまうところがあるので　…あまり他人にどう思われるかよりは、自分として納得できるものを作りたいというのが大きいので。

技術が先行するところもあるし、技術ドリブンなところもあるし、技術として検証したいというところもあるので、そこまで　…リリースまで頭が回らないこともありますね」

閑歳

「そこまでは回さなくてもと思います　…あ、でもこの間出されたRubyの奴とかは？」

増井

「あれは完全に狙っています」

閑歳

「バズるような形で…」

増井

「出しているという」

◆theme / リリースの目的

増井

「いま僕が一番作っているのはMobiRubyという、iPhoneやandroidのアプリをRubyでかけるというツールなのですが、開発キットなので最終的にはオープンソースで出すつもりです。

さっき言ったように、これを作ることそのものが結構目的で　…仕事をするにあたって海外での認知度を上げたい、ということを目的にしているので、今まで自分が作ってきたものとはちょっと方向性が違いますね」

閑歳

「目的がはっきりしていて『どういう玉を投げたら一番よくあたるか』というのを計算してってことですね」

増井

「そういう意味で同じなのは昔作ったPukiWikiで、あれはモノや技術というよりも、自分としては開発手法そのものをやりたくて。オープンソースのエンジニアリングをどう回すかというアイデアがベースもあって、それを検証するために近いところでPukiWikiを作っているという。

PukiWikiを作るチームそのものが成果物で、その副産物としてアプリケーションがあるというような感じになっていますね。なので、アイデアといってもモノがアイデアだったり手法がアイデアだったりいろいろあると思いますね」

◆theme / アイデアを形にするやり方・追い込み方とライバルの蹴落とし方

閑歳

「頂いた質問で多かったのですが、『アイデアを形にするというところで、気をつけるところは？』」

増井

「これすごいは簡単で、朝から晩までコードを書け、と。

MobiRubyには自分個人の時間をほとんど充てていて、僕はお風呂でもコード書いたりするので、

MacbookAirをお風呂の蓋にのっけてずーっと書いてたり　…後は移動中の電車でも基本的にはコードを書いているので、もうひたすら時間を使って形にしているという」

閑歳

「さすがに風呂はやらないですけど、電車はやりますよね。電車で職場までちょうど３０分なんですよ。なので『よし、ヨーイドン！』って言って作るみたいな感じでやっていますね」

増井

「自分ではできないこともたくさんあって　…アイデアがあっても自分で書くのは難しいので、あちこちで話をしていたら『知り合いにそういうことをやっているところがあるので、一緒にやりましょう』とか、そういうこともしていますね」

閑歳

「それはいいですね。そこからアイデアが出てくるというか、元々のアイデアに対してさらにアイデアに対してさらに実現方法が降ってくるという　…口に出すって大事ですね」

増井

「そうですね。僕はプロトまで作って飽きることがすごい多いんですよ。大体、ほとんど完成しないで技術検証が終ったところで飽きるんです。なので、技術検証まで終ったものをその状態で他の会社に売ってしまって、そこで製品にしてもらったこともあります」

閑歳

「私自身は書いたことはないけど、漫画や小説も書き上げるのが難しいのではないか？と思っていて。『ようし、小説を書くぞ！』って中学校二年生くらいのときに1回くらい思ったことがある人ってけっこういると思うんですけど、最後まで書ききった人はあまりいないのではないか？と思っていて。

それと同じで、アプリケーションとかサービスも、最後まで到達してリリースするというのがすごく重要かなと思っていて。私もAppStoreの申請方法とか、アプリやサービスをリリースするまで知らなかったし、何回かやっているうちに勘所がわかってきてなるべく失敗しないようにはなるので　…そういうことをやったことが無いという方は、やってみるとすごい勉強になるのではないかなと思います」

増井

「MobiRubyも技術検証ができた段階でページを作っていて　…あれはある意味、自分を追い込むためと、他の人を蹴落とすため、というのがあって。

先に言ってしまうと作らなければならないというのと、同じことをやろうと思っている人に『もうやっている人がいるから止めよう』と思ってもらうため、というのでページを作っています。」

閑歳

「それはすごいわかります。

私もZaimは1人でやっていたんですけど、コンテストに応募して締め切りが突然できて、そのときは1行もコードを書いていなかったんですけど、なんかデモしなければいけないというので、やり始めたんです。で、最初はウェブサービスにしようと思っていたんですけど、いろいろと友達に聞いたら『今だったらスマートフォンの方がいいんじゃないの？』と言われて、そちらに切り替えた、ということがありました。

後は、先行予約とかは他へのジャブになったりすることもあるし、ユーザのニーズもそこでわかるし、（リリースより）先に（意見を）言ってもらえるので、そこでチューンアップをしたりできるので、けっこうお勧めです」

増井

「僕は10年くらい前にはマニュアルから先に書くというのをよくやっていて、それに合わせてソフトを作るというのをよくやっていました」

閑歳

「仕様書みたいな感じなんですね」

増井

「仕様書というか、マニュアルってユーザのストーリーじゃないですか」

閑歳

「いいですね。マニュアルドリブンですね」

増井

「大学時代はマニュアルドリブンでソフトウェアを作っていました。先にマニュアルで説明してしまって、それを最終的にモノにしていくという形でやっていました」

◆theme / アイデアのスケッチ方法

閑歳

「アイデアを形にする段階でどういうツールを使っていらっしゃるんですか？」

増井

「いや、ぜんぜん普通ですね。　…そういえばマインドマップをよく書くんですよ。今回話す内容もこうやって（iPhoneのアプリで）上げてあったりするんですが、どんどん絞り込んでいくためにマインドマップを書くのはよくやりますね。使うツールはほとんどこれくらいですね」

閑歳

「紙とかペンは使わないんですか？」

増井

「あー、自分の名前を書く以外はここ数年ほとんどないですね」

閑歳

「私は基本、紙なんですよね、あとevernote。

画面の感じを書くのはどうしても紙のほうがうまくいくような気がして　…会社でもそうなんですけど、必ず紙に1枚ずつ書いていくというのをします」

増井

「僕はそういうのもiPadですね。普通の手描きツールで。基本的には全部電子でやっていますね。そうしないとお風呂に持って入れないので」

閑歳

「私も、紙に書いたものも最終的にはpdf化して取り込んでいます」

増井雄一郎様、閑歳孝子様、渋谷Lab様、Lightningspot様、ありがとうございました。

『【shibuya meets tech 4】アナタに一番合うアイデアの生み出し方、 育て方、ゴール』ノート表紙

2012/06/07に開催された、『【shibuya meets tech 4】アナタに一番合うアイデアの生み出し方、 育て方、ゴール』のノートです。ちょっと長すぎたので、ノート自体を3本に分割しました。ここは表紙みたいなものになります。

20120607 shibuya meets tech vol. 4

講演者

Appcelerator Inc.　増井雄一郎氏

株式会社ユーザーローカル　閑歳孝子氏

司会者
渋谷lab　鈴木氏

主催
渋谷lab

会場
Lightningspot

■ノート表紙 

■ノート1. 

• 講演者による自己紹介
• theme / 自分向け vs 一般の人向け
• theme / 技術ドリブン vs リリースドリブン
• theme / アプリのリリースとその取り上げられ方
• theme / リリースの目的
• theme / アイデアを形にするやり方・追い込み方とライバルの蹴落とし方
• theme / アイデアのスケッチ方法

■ノート2. 

• theme / アイデアをシンプルにする方法
• theme / 上から目線でも就職活動ってできるし、相性って大事
• theme / どこから作りはじめるかと、どこでモチベーションが下がるか
• theme / ゴールとそこへのアプローチ
• theme / モチベーション
• theme / アイデアを形にできる人とそうでない人の違い

■ノート3.  

• theme / 体験談。開発でつまづいたとき
• theme / 体験談。日米のビジネスの違い
• theme / 公私の切り分け
• theme / 業務外の活動と仕事との相乗効果
• theme / 個性を伸ばす方法
• theme / 増井さん個人
• 質疑応答 1.
• 質疑応答 2.
• 質疑応答 3.

『【shibuya meets tech 5】ディレクターとデベロッパーの“こそあど”』ノート

2012/06/08に開催された『【shibuya meets tech 5】ディレクターとデベロッパーの“こそあど”』のノートです。ノートというかほぼ全部メモした感じですが　…やはり生の会話には言葉の機微みたいものがあって、それが非常に面白いし、そういうものこそ残しておきたいと思うので、可能な限りノートに取ってしまうという　…削った方がよいかな？と思う箇所は削りました。





20120608 shibuya meets tech vol. 5



講演者

株式会社ミクシィ　鈴木理恵子氏

株式会社バスキュール号　西村真里子氏

司会者
渋谷lab　鈴木氏

主催
渋谷lab

会場
Lightningspot




◆渋谷labって？

pasona techがスマホ開発とweb制作を行うための拠点
デベロッパやクリエータとコミュニケーションの機会を設けたい
技術セミナーをどんどんやっていきたい



◆自己紹介

◇鈴木理恵子氏

・背景
音楽の専門学校の出身
木工（ギターの製作）をしていたが、女性にはそちら関係の就職先が無く…
同じものづくりということで、ITならいろいろ実現できるのでは？と考えた


・mixiへの経緯
受託→SaaSと会社を移っていくなかで、（自分の関わるサービスを）もっと広く多くの人に使ってもらいたい、楽しんでいただく提案をしていきたい、という思うようになり、mixiに転職した。


・やっていること
mixi Platfromを提供し、mixiに関するアプリを作ってもらうという仕事をしている。

※mixi Platformとは？
mixi上のたくさんの情報（つぶやき・日記）を、開発会社に提供するためのAPI。



◇西村真里子氏

・背景

• エンジニア5年。マーケティング2年。
• ちょうど90年代後半に学生をやっていて、や舞台照明をやっていた。
• 留学中に日本の友達と話すときにe-Mailを使っていた
• 大きなステージで照明を作る仕事をしていたが、Flashならもう少し身近に自分の作りたい大きなステージが作れることを知った。
• ITって何かすごいと思った。

・バスキュール号への経緯

いろいろ学ばさせてくれそうな会社ということで、最初にIBMに入った。
次に自分のクリエイティブを活かせるところに行きたいと思い、Flashを作っているMacromedia（現adobe）に転職。
それからグルーポンを経てバスキュールへ。

・こんな会社

• 12年選手の会社
• Flashメインで、インタラクティブ / マルチユーザ向けのコンテンツを作っている
• mixiさんと、いかにユーザが楽しくなるかというサービスを作っている

◇バスキュール号がリリースしたサービス / アプリ

・Fantastic Answer

• 友達とラジオを聴いて楽しむというコンテンツ。
• 大喜利みたいな感じでユーザがネタを投稿すると、ラジオで拾ってもらえる。
• ソーシャル・メディア・ラジオ・友達がmixiのプラットフォーム上で繋がる

・cotto

• mixiの友達とも楽しめるandroid用アプリ。
• デコアプリはいろいろあるが、これは複雑なコミュニケーション無しで使える。

・pelo

• チェックインツール。
• mixiにコネクトできる。
• 位置情報をベースに友達と繋がることができる。
• 海外のものは複雑だったり、mixiとコネクトできるものがなかったりした。

・Social Studium System


・mixi Xmas



◆topic / 現状・仕事の環境・組織体がどういう風になっているのか


鈴木

• 開発は小さな単位に細かく分割し、 それを速いスピードでいる
• チームは専門（機能や技術、サービスなど）毎に細かく分かれている

西村

• iPhone・androidのアプリや受託など、様々なものをやっている
• 何個も帽子をかぶっているような感じ
• 「いろいろな人と仕事ができるので、コミュニケーションとしては風通しがよいかな」
• 手が足りないときはいろんなリソースを使っている

◆topic / 現場の実態ってどうなのよ？

西村
「ディレクションとエンジニアのうまい連携を模索中という質問を頂いています」

鈴木
「永遠の課題ですね」

西村
「あとは、『自分に合ったスキルを身につけるべく現場の内情を知りたい』ということで　…ディレクションとエンジニアの連携、うまくいってますか？」

鈴木
「弊社はわりとうまくいっていると思います」

西村
「私はディレクションとしてお金を儲けなければいけないので、クライアントの意見を『やりますね！』とか言って。それを社内に持っていくと（エンジニアから）『ふざけんなよ』ということがたまにあったり。『かっこいいことやろうよ！』といっても…」

鈴木
「『ちょっと待ってよ』とか」

西村
「そうそう。私とか気合とかノリで行こうとするんだけど、それがすごい嫌われるんですよね」

鈴木
「開発者からすると『ちょっと考えさせてよ』とか？」

西村

「そういうときはどうしたらいいんですかね？

『yes』って言って抱え込んじゃうと、体力勝負で潰れちゃったりとか　…仕事が嫌になってしまう人もいると思うから、『ちょっと待ってよ』とか言ってくれた方がいいと思うんですけど。
mixiさんの方は、企画の方とエンジニアの方で『ちょっとそれ無理だよ』ときちんと言えるようになっているかとか、その辺はどうですか？」

鈴木
「弊社では、プロジェクトをどう廻していくかはチーム（チームリーダやマネージャ）毎で取り組み方が違うんですけど　…大きく見ると、コミュニケーションを蜜にとろうとはみんな言ってますね。開発・企画の方を混ぜてミーティングを毎日やって、『今日何をするか』『もうやったもの』『まだやってないもの』を付箋でホワイトボードに張って。みんなの進捗が分かるようにしながら喋っていたり。で、けっこう大丈夫。それで解消されていることが多いですね」

西村
「企画の人も含めてそういう話をするんですか？」

鈴木
「そういうチームが多いですね」

西村
「毎朝とか？」

鈴木
「朝やっているところも、（一日の）締めでやっているところもあります」

西村
「ちょっと参考にしようと思います。というのは、企画の方で『いっちゃおうよ！』っていうごり押しとかしちゃったりとかして　…（それよりは）なるべく、みんなが協調してできるといいなっていう。本当に模索中ですね」



◆topic / ディレクターと開発者の関係

西村
「今の会社に入って一年くらいなのですが、『おっ』と思うようなことがあって　…企画を客先に持っていく前に、ブレインストーミング等で皆で考えて、『皆の提案を持っていくよ』という風にするようにしていて。そうするとうまく進められるのかな？というのを学びつつあります。

そうやると時間がかかるんですけど、ものづくりの人は自分の意見を反映したいというところがすごい深いと思うので　…私みたいな（ディレクションの）人間はなるべくそういうことをやらないといけないのかな、と。

（参加者に向かって）
どうですか？　私みたいな『やろうぜ！』というような人が来ると、いっしょに考えてくれたりとかしますか？」

参加者
「個人的には全然ありかな、と思っています」

西村
「どんな感じで進めているんですか？」

参加者
「いまはウェブではなくて、業務系のシステムを作っているんですけど、マネージャとプロジェクトリーダーがいる状態で、後は数人のチームで一丸となってやっている感じで。他部署との連携も多いので、話を聞くだけではなくて、きちんとコミュニケーションをとらないといけないと思っています」

西村
「ディレクター側と開発者側で悩んでいるというか『どうしてもうまくいかないんだよな？』『どうしたらいい？』といった悩みを抱えている人はいますか？」

鈴木
「別にディレクション職の方を悪く言うわけでないんですけど、開発の仲間がランチとかでぽろっと言うのは　…ウェブの画面があって、『ここをちょっと変えてよ』というのがあると思うんですけど、ディレクターの方からしたら『見た目がちょっと変わるだけだから、大したことないんでしょう？』という感じだと思うんですけど、稀に裏の仕組みをいろいろと変えないとできないこともあって。『簡単に言うなよ』みたいな愚痴があったりしますね」

西村
「それがすごい怖いなと思うのは、本当にテキストを変えればいい場合と、後ろでバックエンドを呼んでいる場合とを把握しないで言ってしまうことがあって　…テキストを変えるだけなら（開発側は）『オッケー』って感じなんですけど、バックエンドのところに繋がっていて『ふざけんなよ』って顔をされたときには、『しまったー』って思うんですよね。

…どのパターンか分からないっていう時はどう言えばいいんですかね？『変えておいて』じゃない方が？」

鈴木
「『どのくらいかかりますか？』と聞いてくれれば、何日くらいかは言えるので　…そこでディレクションして優先順位を付けてくれたりするとうれしいなーって思います」

西村
「『変えてっ！』じゃなくて、ってことですよね　…自分が本当、ひどい人のような気がしてきた」



◆topic / 組織の規模とコミュニケーション

鈴木
「mixiに入るまでは100人以下の会社にいたので、1つのプロジェクトを動かすにもだいたい4～5人、それにお客様くらいで済んでいたので、あまりコミュニケーションを蜜にとろうという意識はなかったんですけど　…mixiは500人くらいいて、何か1つ変えるにしてもいろんな部署に伺いを立てないと後で大変なことになるので、その辺は気をつけるようになりました」

西村
「私は逆に、何万人規模から何千人　…いまは40人規模の会社に行って。いろいろと面白くて、いろいろ全部自分で見れるって言ったら変なんですけど、私はステップに沿った承認というのが合っていないタイプで。『時代がもう突っ走ってるんだから行こうぜ！』というタイプの、そういうことをやりたい人間なので、今の40人がすごい風通しがいいというか。

でも今は大きい会社だから守られていたというのもひしひしと感じていて。エンジニアとの会話でもそうかもしれないし、社内の会話でも、『いかに今まで守られていたところで仕事をしていて見ていなかったのだろうか？』とか『あー見えてなかったなー』とか　…どんどん学んでいる感じがしますね」

司会
「会社規模って影響するところが大きいですよね」

西村
「大きい会社だから大きいことができるっていうのもありますよね」


（中略）


鈴木
「1000人　…もっと大きい規模の会社の人はいますか？」


（数人が挙手）


鈴木
「むしろ伺いたいくらいですね」

西村
「そういう大きなところでどうコミュニケーションをとれば　…エンジニアとディレクターとか、もしくはエンジニア同士で、どういう形のコミュニケーションで問題解決をしているかというのを」

参加者
「どういう形で　…私は開発でも研究側の方にいて、実際に事業をしている部門とはテレビ会議などを行なっています」

西村
「どちらかというと研究所の方が強い？　…って、変な言い方ですけど」

参加者
「弱いです。お金を稼いでいるのは事業をやっている方なので」

西村
「でも、コアはそこにあるじゃないですか」

参加者
「そうですが、お金を稼いでいる方が強いんです。そこからお金をもらって研究しているので　…とにかく弱い立場で仕事をしています」

西村
「どうやって『なにくそ！』という感じにしていますか？」

参加者
「いや　…メンタル的にきてしまうような人が出るような職場なので」

西村
「…私もちょうど前職でIBMにいたんですけど。そのときも大きな組織だからもどかしくてとか、意見が何重のレイヤで伝わらなかったりとか。メンタルとか壊す方もいて、せっかくスキルがある人達なのにどうしたらいいんだろう？とか　…もともとの同僚がそうなっているのを見ると、どうしたら自分のやりたいことを企業の中でやっていけるのかな？という　…難しい（問題）ですよね？　…そういうときは『飲みに行こう』って言えばいいのかな？」



◆topic / コミュニケーションで心がけることは？

鈴木
「『ディレクターとデベロッパーの立場でコミュニケーションについて普段心がけていることを聞きたいです。気をつけていることをお聞きしたいと思います』。ありますか？」

西村
「我々としては、いいものをつくってお客様に喜んでもらいたいというところがあるので、少なくとも、社内でどんな戦いがあっても、『いいものを作りたい』というビジョンは守っていきたいというのがあります。

それから、『みんなで作っているんだよ』と感じるにはみんなで会話する必要があると思うし、聞かないとみんなが喜んでくれるアイデアはできないと思うので、開発チームでなくとも参加できるように、ブレインストーミングとかで意見を聞くようにしています。

また、やはりビジュアルがあると具体的に話を進めていけるので、（ブレストに）参加するときには、できれば絵を持ってきてもらうようにしています。それを『いま解決しなければいけないのはこういうことですよね？』という点の参考にして話をするようにしています。

そういうのを頻繁にやっています」

鈴木
「私もディレクターに話すときはなるべく絵に落とすように心がけています。

私の周りのディレクターはオープンな人が多いのですが、デベロッパーには『今は触れてくれるな』という雰囲気を出している人がいて。私は喋るタイプですけど、そうでない人もいるので、（そういう人には）システムを使ってお願いや相談をしたり　…人によって（コミュニケーションの手段を）使い分けたりしています」

西村
「それはわたしも気をつけています」



◆ topic  / 盛り上がることの大事さ

西村
「（顧客への提案について。『こうした方がよくない？』というのが盛り上がって）　…なんかみんな調子にのってやって。2週間以上これで盛り上がって、しばらく開発の時間が遅くなったりして。その提案は通らなかったんだけど、みんなで頭の中でシミュレーションしてキャンペーンやろうっていうのがあると、それは他のときにも使えたりするし　…1回とか2回失敗しても、みんなで同じことを考えてみるのはいいことかな、と思います」

鈴木
「普段の業務とは離れるんですけど、社内のイベントで『WC2.5』というのがあるんですね。年に四回、月末の最後の2.5日を使って何かを作ろうという社内ハッカソンをやっているんです。それはエンジニアだけではなくて、企画の人とかデザイナーとか誰でも参加可能で、チームの募って合宿とかやっているんですね。最初は開発の人だけだったんですけど、徐々に企画の人とかも参加するようになって。

徹夜も覚悟でみんなで意見を出し合って。コンテストなので順位がつくんですけど　…商品が出るのでみんなテンションがあがるんですね。かなり根をつめてコミュニケーションしてものをつくります。業務とは全く違うものなのですが、なかなかよい経験だな、と」

西村
「（その中から）サービスになったものもあるんですか？」

鈴木
「あります」

西村
「そういうのっていいですよね。やる気がでますよね」

鈴木
「コミュニケーションっていう意味でも、本音をぶつけあって。時間がないから遠慮しないんですよね　…遠慮しないで言い合うっていうのがなかなかいい体験になっているな、というのがあります」



◆topic / コラボレーション

鈴木
「『異なる職種で見ているものを共有する工夫は？』ということなのですが」

西村
「モックアップとか、実際のシナリオを仮定してみるとか。元々Flashに強い会社なので、AndroidのアプリだとFlashからAIRで書き出して実機で動かしてみるというのはよくやってまして　…これだと職種を超えてクライアントやメディアにも伝わりやすいので、非常に便利だと思っています。コラボレーションやりたいという人達には、『こういう感じになるから、一緒にやってみよう』という感じで使えます」

鈴木
「私はAPIを作る仕事なので、あまり画面というのがないんです。こういうAPIを作りましたというのを企画の人と共有しようにも、文字が出るだけなので全然共有できず、困ったことがあったんです。そういうときは、時間かかるけど『このAPIを使えばこんなアプリができます』という紙芝居みたいなものを自分で作って、意見をもらうように気をつけています」

西村
「絵とかモックとか言ったんですけど、いかに使っている人のリテラシーに合わせるかというところで、その立場の人が普段使っているものに当てはめるのはすごい大切。インサイトをどう使うのかというところはあるし大変だけど、それが見つかるといいなというのがありますよね」

鈴木
「相手の立場になって伝えようとしないとなかなか　…というのはありますよね」



◆topic / ユーザビリティとデータとエンドユーザの関係

鈴木
「これは個人的に聞きたいことなんですけど　…ユーザビリティテストはどうやっていますか？」

西村
「本当に常にやっているというか　…企画段階でもそれが楽しいかどうかはまず社内でやるし、
クライアントにも何回もこういう形ですよね？というのを見せたり、ターゲットに近い人に実際に使ってもらったりとかしています。情報を集めて何回も絵にしたり、モックを作ったりしています。

いまやっているサービスでも、不都合があったところなど結果の分析をしていて　…どういう機能だったらみんなが使ってくれているかというのを見たりしていて、使ってもらえる機能はどんどん良く、使われていない機能は削除してパフォーマンスを上げたり。

1回で終わりじゃなくて、何回もテストして良くしていく、という形でやっています」

鈴木
「そのテスト結果は開発の方などにも共有されているんですか？」

西村
「みんなで共有ですね。逆に調査部隊がいるわけではないので　…エンジニアも『どういうデータが取れるか？』ということを考えながら開発するし、こっちも『どういうレポートがあればいいのか？』というのを考えながら作っていくというのをやっていて。結果を数値で見れるようにしています」

鈴木
「弊社でも全員に公開されているものがあって、それを見て声を上げる開発者もいます。みんなでやることで一体感がでるというところはあると思います」

西村
「データって大切ですよね。結果をちゃんと分析しないといけないというのは最近本当に思っていて　…『作っちゃえばいいじゃん』ではなくて、結果を見てみんなで『どこを変えていこうか？』というのは必要だと思いますね」

鈴木
「私たちの仕事は一般の方がエンドユーザなので結果が見えやすいのですが、業務システムはユーザビリティの量り方が違うかもしれないですね」

西村
「確かに…

（参加者に対して）
業務系でユーザビリティというものはどういう風に扱われるのでしょうか？」

参加者
「正直に言うと、しっかりとは取れていないですね。大まかにやるくらいで　…あとは人的にセミナー的なものを開催してお客様を集めてやる以外にの方法がなくて。サーバ自体をお客様のところにいれてしまうのでデータを取れないと。なので、提出して頂く何かしらの仕組みをとらないといけないのかな？と考えています」

西村
「それよりは、機能とかどれだけ正確に測れるかというのが重要視されるというのもありますよね」



◆topic /  コラボレーションでやってはいけないことって？

鈴木
「『やり方や手法、やってはいけないことを教えていただければ幸いです』　…これは難しい」

西村
「やってはいけないこと　…でも、失敗しなければ何も（はじまらないというか）　…ねえ？」

鈴木
「コラボレーションでやってはいけないこと　…なんでしょう？これ質問された方っていらっしゃいますか？」

参加者
「例えば考え方が違ったりいろいろあると思うのですが　…何かやるにあたってタブー的な、開発者にこれ言ったらだめだよね？とかそういったことを聞ければ」

西村
「私も聞きたいです」

鈴木
「開発者の人って、割と非難されるのって苦手かな、と。

認めて欲しいというか、自分のやっていることに誇りを持っている方が多いので、どちらかと言うと『お世話になっています』『いつもすごいですよね』『信頼しています』『いつも期日どおりありがとうございます』とかそういうのがあると、すごく心の距離が縮まるというか　…そういう一言で、『頼まれていたのはここまでだけど、先までやっちゃいました』とか、そういう方がいるような気がします。逆に、最初から『お前だめ』ってやると心を閉ざすのかな？と個人的には思います」

西村
「『お前だめだよ』って言う人がいるんですか？」

鈴木
「それは（ストレートには）言わないのですが　…別に非難しようと思っているわけではないんだけど、個人攻撃のように感じられるような言い方というか　…コミュニケーションってそういうことがよくあるじゃないですか？（特にエンジニアに対しては）そういうことは気をつけたほうがいいと思います」

西村
「例えばfacebookはある意味スタートアップ的なところから始まっているけど、エンジニアからああいう形にまで築いていたりとか　…いまはエンジニアのほうがかっこいいと思いますよね」

鈴木
「エンジニアにもいろいろな人がいます　…みんな得意不得意があると思います。

私は外に出てお話するのが得意なのでそういうスタンスでやっていますが、そうでない人もいるし、サービスによった開発をしたい人もいれば、言われたものや伝えられたものだけを確実に作るのが得意とか、いろんな人がいます。ただ、そういうものははっきりと分かれているように思いますね」

西村
「話をするのがすごく大切だと思っていて　…エンジニアにもいろいろなタイプがいるというときに、

そのエンジニアは最終的にはディレクタになりたいと言っていて、『だったら一緒にやっていこうよ』という形でやっていき、それはうまくいきました、と。そういうパターンのエンジニアが多いのかな？と思っていたんですが、みんながそれを求めている訳ではなくて。

『俺はこれを完璧に仕上げたいだけだから。別に偉くなりたくない。ただこれは俺に任せてほしい』という人がいて。（最初はうまくいっていなかったのだけど）それを分かってからは、彼のスタンスとコミュニケーションできるようになった　…ということもあって。一瞬でもうまくいかないなー、と思ったら話してみることが大切なんだと思いました。

一緒に仕事をしているのに改めて聞くのも照れくさいんですけどね。ただ、『この人はここを追及したいんだから、こちらの勘違いで変なプレッシャーをかけたらいけないなー』とか、そう思います」

参加者
「逆に開発に言われたくないことは？」

西村
「もう言われ慣れてしまったんですけど、もともとはIBMでエンジニアもやっていて、プロジェクトの中も知っているということで『こいつ現場知らないな』とは言われたくないけど、よく言われますね。
『お前は現場知らないんだから黙ってろ』みたいな。言われたくはないけど、今は実際にそうだし　…過去のプライドはどうでもよくて、今のポジションだけ考えようというのがあります」

鈴木
「開発者がそう言うことはよくあるけど　…よくないことだと思います」

西村
「そこで喧嘩してもどうしようもないし　…『私はこのポジションだから』って切り替えて、『そうだよねゴメン』ってやろうかなとは思いますよね。

…ミーティングルームとかでも喧嘩になると、周りがとても寒いですよね。たまにありません？真剣に喧嘩になったりとか」

鈴木
「あります」

西村
「自分もたまにやってしまうことはあるけど　…後から反省するし、そういうミーティングに行ったときって切ない気持ちになるので、思うことは合っても引こうかな、と」



◆topic /  質疑応答

参加者
「日ごろ、チームでデザイナやテクニカルの方と仕事をしているのですが、チームの中にテクニカルディレクターやアートディレクターという方がいます。そういう人がデザイナやテクニカルを管理しているという中で、下手したらディレクターっていらないんじゃね？と思うことがあります。

テクニカルだけで作っているアプリもたくさんありますし、そういう中でディレクターにしかできないことについて考え方を教えて頂きたいです」

西村
「一番強いのはアートディレクターやテクニカルディレクターです。私は会社に勤めている人間なので、いかに良いサービスをお金にできるか？とか、受託の仕事であれば、次に生かしていけるか？とか　…ちょっとでもお金の換算というか、アートディレクターやテクニカルディレクターが引いた視点を持てればパーフェクトだと思います。でも、アートディレクターやテクニカルディレクターは現場でのアートやテクニカルなことに集中したい（と考えていると思う）し、そうしてほしいし、というところで　…どちらかというと自分はプロデューサとして全体を見ることが多いのですが、クライアントとの関係とか、重要なパイプラインを作ることを自分の価値にしようとしています」

参加者
「それぞれの専門分野に集中してもらえればという…」

西村
「そうですね」

鈴木
「私もそういう目でディレクターさんを見ています。

お金の部分とか、本当に分析や効果測定しやすいデータというのはどういうものなのだろう？ということを考えたりとか、定期的に分析し続けたりとか、（そういうものは）開発者からはなかなか出てこないなと思っていて、そういうところをディレクターにお願いして調整してもらったり、他の人に考えてもらったりして　…開発は開発に専念したほうがいいのかなと思います」





鈴木理恵子様、西村真里子様、渋谷Lab様、Lightningspot様、ありがとうございました。