読者です 読者をやめる 読者になる 読者になる

ペライチ(peraichi)公式ブログ

『ペライチ』のサービスに関するお知らせや運営スタッフの日常をお伝えします。

決済プランチーム座談会 #3 作り手目線とユーザ目線の違いについて&気になることリストの話

 

 

f:id:peraichi:20170117171142j:plain

橋田(はっしー 写真右):代表。今回のモデレータ

香月(かっきー 写真左):プロダクトマネージャー兼エンジニア。

小川(写真中央):デザイナー。

 

シリーズでお届けしています、この企画。前回の記事はこちらです。

blog.peraichi.com

 

橋田:

あとはですね、全然別の話になるんですけど、キックオフ飲み会とかやりましたよね?

 

香月:

やりましたね。はい。

 

橋田:

あれ、何でやろうと思ったんでしたっけ?

 

香月:

あれは、本当に短納期プロジェクトだったので、メンバーに先ず、そのプロジェクトの意義っていうことを理解してなぜこれをこの短納期でやる必要があるのかっていうのをちゃんと浸透させたかったっていうのと、あとやっぱり、短期間で一気に走り抜ける仲間なので、その信頼関係の構築というか顔合わせ含めて、お互いのことを知ろうという目的でやりました。

 

橋田:

やるぞーみたいなノリでやるしかないから。

 

小川:

やるしかなかったからですからね。

 

橋田:

あとは、その他何かありますか?香月さん。

 

香月:

その他でいうと、工夫したところというか。

 

橋田:

スケジュール組むときに意識したこととかも知りたいです。

 

香月:

そうですね。スケジュールを組むときに意識したことでいうと、やっぱりさっき言ったことと被るんですけど、テストがすごい重要ですと。2ヶ月のうち4分の1をテストに使うっていうスケジュールを引いたんです。半月テストに全部がっつり使いますと。オシリの半月は全部テストやるから実質1ヵ月半で作り上げなきゃいけないっていう。オシリが1ヵ月半後ですよっていうかたちになって、結構それによって皆の意識がもう危機感が全然変わったって感じです。

 

一同

(笑い)

 

橋田:

1ヵ月半で、今このくらいの仕様でもうちょっと増えるかもしんないみたいなところをやりきるのか。これを取締役が言うのはどうかと思うんですけど。

 

小川:

仕様を固めてるときなど、調べれば調べるほど、どんどんやることが増えていくんですよ。

 

橋田:

横で見てて、そういう印象がありました?

 

香月:

タスクリストの中から毎週Pull Requestを出してマージされてるはずなんだけど、毎週定例ミーティングでなんかタスクリストが増えていくんですよ。

 

橋田:

怖いっすね。

 

香月:

だから一気にやりつつ、戦いですよね。積みあがるタスクとの。多分このやり方は本当に1ヵ月半ぐらいだからできたっていう感じですね。

 

橋田:

ぎりぎりだったっていう。なるほどですね。ありがとうございます。

 

香月:

あと他のことで言うと、今回のプロジェクトに限らない話なんですが、普段プロダクト開発をするときに、事前のユーザーヒアリング、ユーザーテストを行うようにしています。要は最初の工数でプロトタイプを作ってユーザーテストをするという進め方ですね。今回もたまたま1ヶ月半って決めてやっていたものの、外的な事情で、要は決済のAPIの承認が下りるか下りないかみたいな話があって、それによって、結果、後ろ倒しになったんです。リリース日が。なので、余裕が若干できました。その時間ではっしーがテストして

 

橋田:

そうそう、やったよね。

 

香月:

翔さん(取締役の山下)とかに触ってもらってフィードバックをもらうっていう会をやったんですけど、すごく色んなフィードバックをもらって、要は、ここが全然分かりにくいとか、結構大きくUIを変えなきゃいけないとかそういうフィードバックをもらって、やっぱりテストって大事なんだなっていうことをすごく実感しました。

 

橋田:

そこはやっぱ織り込んでいきたかったよね。結果としてできたから良かったっちゃ良かったけど。

 

香月:

やっぱり、もっとタイトだと辛いよね。

 

橋田:

そうですね。ありがとうございます。ちょっと話を変えますが、意図せずハマったところとか苦労したところってどういうとこでした?

 

香月:

意図せずハマったところで言うと、結構PMの僕がボトルネックになることが多くて。エンジニアタスク、デザインタスク、テスターのテストみたいなところ以外全て僕がやってたんです。で、PM兼ディレクター的な感じでやってたんですけど、やっぱり仕様変更とか要件の変更とかが、プロジェクトを進める中でどうしても出てきてしまって、普段の日常業務もあるなかでそれが積みあがっていくとどうしても手が足りなくなって、結構オーバーフローするという感じでした。

 

橋田:

他のプロジェクトも見てるからね。それがつらいよね。

 

香月:

そうですね。そこが結構はまってたんですけど、やっぱりさっきのテスターの働きが大きかった。自走できる人なので、自分でぽいぽい。

 

橋田:

いやー、超助かるよね。

 

香月:

タスクを上げてくれたりとか。イシューを積み上げてくれるっていうところがあって、彼女がすごい大きかったです。働きとしては。

 

橋田:

本当、予想外にすごい良かったと聞いてますね。

 

香月:

で、API仕様書が膨大過ぎで予想外だったっていうのも。

 

一同

(笑い)

 

橋田:

いや、流石に読めなかったよね。あれは辛い。

 

香月:

そうですね。

 

橋田:

なるほど。良く分かりました。小川さん、何かありました?

 

小川:

予想外ではないんですけど、やっぱこのペライチの決済って、他に無いサービスじゃないですか。他のECサイトとかはやっぱり、商品ありきでページが付随みたいな感じなので、色んなサイトを参考にしたけど、丁度ペライチに合うみたいなぴったりくるやつはやっぱり無かったんで。

多分、新しいかたちだから、結構そこの設計とかUIに大分苦労しました。フローが一本道じゃないんですよね、ペライチは。先に商品を登録してページを作ったのもあるし、ページ作ってからっていうのもあるし。

さっきのユーザーヒアリングも話が出たんですけど、それでやっぱりその辺の課題が明確になって、ちょっと1本道の例を示してあげようみたいな感じで、1番最初にこういったフローで作りましょうよみたいなのは、今回間に合って作ることができました。

 

橋田:

なるほど。ありがとうございます。あとは、他は何か、2人共に聞きたいんですけど。作業を進めたりプロジェクトを進める上で、工夫したところってどういうことがありましたか?じゃ、かっきーから。

 

香月:

結構、スクラム的なことを今までやったことが無かったんですけど、今回意識したのは、結構頻繁にミーティングを組んで、細かく改善していくっていうことを意識していて、週3で本当のスクラムだったらもっと頻度が高いと思うんですけど、週3で定例ミーティングをとってプロジェクトの進捗確認やったりとか、今困ってることとかの共有とかをしながら進めていったんですけど、それがトライとして良かったなっていうのはあります。結構、一気に1日の進む量が多いんですよ。一気に進めたので。なので、結構壁にぶち当たったりする頻度が高くって。

 

橋田:

確かに、5人がフルパワーで毎日進めていくと、1日5人日。2日で10人日。ぐらい進んでるから、割と進むんですよね。

 

香月:

本当は毎日やるぐらいでも良かったかもしれないですけど、週3なのは業務委託の人が週3だったので。頻繁にミーティングしていたのが良かったかなっていう感じですね。

 

橋田:

他にはありますか?

 

香月:

あとは、ある程度形になってきてユーザーテストをしたっていのは、やっぱり良くて、実際に作り手の目線だと、ユーザーがどこで止まるかっていのが抜け落ちちゃうことが多いんです。

 

橋田:

あー。

 

香月:

作ってると。結局これでいけるだろうと思ってUX考えて作ってるので、実際に全然知らない他人に使ってもらわないと分からない部分って結構あって。人がどう感じるかっていうのはなかなか難しいところなんですよね。そういう意味でいうと。

 

橋田:

マジでそうだよね。

 

香月:

なのでやっぱり、ユーザーテスト、ユーザーヒアリングをしながら進めるっていうのはすごく大事にしたほうが良いかなって。

 

橋田:

時間があるから、もちろんその、例えばProttみたいなプロットタイミングツール使ってテストするっていうのをやるだろうし、今回は時間があんまり無いので、できてきた部分からテストをするとか。ちょっと動くようになったら触ってもらうとか。すごく、1番早く改善できるよなっていうふうに思いました。

他にありますか?小川さん、どうですか?

 

小川:

僕が意識したのはやっぱり、時間が短かったんで、特に人数が少ないんで、多分1人が止まっちゃうと全体が止まっちゃうと思うんです。なので、自分の抱えてるもののなかでも、ここが止まっちゃうと進まないとかボトルネックになる部分は極力先につぶして。

あとは、今回お願いするデザイナーが1人だったんですけど、どういった部分が得意かっていうのを見極めて、極力得意な部分をやってもらったほうがスピードが速いので。そういう部分を極力振るようにしてもらいました。

 

橋田:

今ここで話してる3人はいわゆるコミット度が高い社員の人たちなのだけど、相方の人は週3とかで多分そうじゃない。一緒に組んでたんだと思うんだけど、そういう人たちが上手く働きやすいようにタスクを調整したり玉拾いをしたりとか、そういったことを意識すると、プロジェクトのボトルネックがなくなって、速く進みやすいかなみたいなのがありますよね。



小川:

そうですね。自分がやるっていうよりは、上手く100%の実力を発揮してもらうっていうことに意識を置いて、そこに注力するみたいな。

 

橋田:

プレイングマネージャーっぽい発言。でも、本当に大事ですね。確かにそうだな。分かりました。意見が言いやすいみたいなのがあったと思いますけど。僕はその会に毎回参加はしていなかったけれども、気になることとかそういったことを意見を言ったりとか、そういうのを書き込める場所があったりとかっていうのはすごく良いように外から見てて思ったんだけど。多分、そういうのって、最初からやってたんでしたっけ?

 

香月:

今回のプロジェクトのトライとしてやったって感じです。気になることリストみたいなやつも、最初はやってなかったかな。途中からできた気がします。やっぱフワフワしたアイデアベースのものとか、これは議論したほうが良いよねみたいなものとか、あとはタスクベースのものとか。いろんな種類の塊があるんですけど、皆が思い思いのものが。それを気軽に放り込める場所を作ったっていうのがすごい良くって。

 

橋田:

今って、それすぐにドライブで見れましたっけ?

 

香月:

今、見れると思いますよ。ただ、今、気になることリストではなくて他のシート名なんです。決済ガント。ガントチャートの横にあるのかな?あった。これが気になるリストで。毎回のミーティングでそれについてそれをタスク化するのか、それとも次のフェーズでやるのかを検討していきます。

 

f:id:peraichi:20170117171949p:plain

 

橋田:

そうこれ!それを毎回打ち合わせのときに拾ってこれどうする?っていうのをカジュアルに話せるように。

 

香月:

そうです。

 

橋田:

そこからタスクにもなるし、ちょっとこれは良いかなみたいなものは置いておくみたいな。

 

香月:

そうですね。

 

橋田:

これをやって、やっぱり他の人が気付かないことに気付きやすくなるとか、そういうことがあるのかな。

 

香月:

そういうことがありますね。

 

橋田:

ほんと良いトライだよね。なんか、会社としてもどんどんそういうこと仕組み化したいよね。

 

(続きます)

決済プランチーム座談会 #2 チームの話

 

f:id:peraichi:20170110121044j:plain

橋田(はっしー 写真右):代表。今回のモデレータ
香月(かっきー 写真左):プロダクトマネージャー兼エンジニア。
小川(写真中央):デザイナー。

 

シリーズでお届けしています、この企画。前回の記事はこちらです。

blog.peraichi.com

 

橋田:

ちょっと次のテーマなんですけど、社内にいるエンジニア・デザイナーの中から、チームを作る、それから作業分担するみたいなところについて聞いていきたいんですけど、チームって何人ぐらいでどういう役割の人がいました?

 

香月:

チームは、PM1人、エンジニア1人、デザイナーが2人、あとはテスターが1人です。

 

橋田:

先ず最初にチームを作ると同時に、というかその前の時点でさっきの設計の話があって、設計をやりながら、どういうチームを作ろっかみたいな話をしてたと思うんだけど、例えば、さっきもちょっとあった、それぞれの役割分担をもうちょっと細かく教えて欲しいんですけど。

 

香月:

PMが僕なんですけど、僕は実際に工数管理とかスケジュールひいたりとか仕様決めのところをメインでやっていて。

 

橋田:

コードは書きました?

 

香月:

コードも書きました。エンジニアと一緒にサーバーサイドのコードを一緒に書いてました。あとは…

 

橋田:

つまりプレイングマネージャー

 

香月:

ですね。エンジニアっていうと、サーバーサイドエンジニアが僕以外にもう1人いて、彼に決済のAPI連携のところを全部お願いしてました。

 

橋田:

API連携っていうのは、もうちょっと詳しく説明して欲しいんですけど、つまり、裏側に決済サービスがあって。

 

香月:

その上位接続先の決済サービスとペライチをつなぎこむAPIです。

 

橋田:

なるほど。そこの作りをやってもらったと。

 

香月:

はい。

 

橋田:

あとは、他の役割の人でいうと。

 

香月:

デザイナーが、主に小川さんに全体のUXの設計をしてもらっていて、もう1人デザイナーの方はフロントのエンジニアリングもできる人なので。

 

小川:

そうなんですね。僕が本当に全体のUIの設計とか画面の仕様書を作って、最初の最初は自分がコーディングとかまでやるつもりだったんですけど、もう1人のデザイナーの方が、デザインもコーディングもできる方なんで

 

香月:

本当、器用だよね。

 

小川:

器用ですね。幅広くできるので、ほぼほぼ実装のほうはもう一人のデザイナーに一任して、僕は全体のクオリティとか、あとは本当にちっちゃい画像とか作るっていう、完全に上手い具合に分業ができたんです。

 

香月:

良い分業体制だよね。

 

小川:

はい。大分スピードも速くできたし、それぞれがやることに集中できたんで、クオリティは高くできたかなと思っています。

 

橋田:

でもって、もう1人。

 

香月:

テスターです。

 

橋田:

テスターって何する人ですか?

 

香月:

テストをしまくる人です。

 

橋田:

はいはい。

 

香月:

女性のエンジニアの方に入ってもらって進めたんですけど、要は決済サービスなので、不具合やセキュリティ的な脆弱性があるとユーザーさんにすごく迷惑がかかってしまうので、そこの部分をテストを入念にやろうと決めて、今回からテスターという役割を入れることにしました。彼女には、作った機能を片っ端からテストしてもらい、不具合や仕様バグを洗ってもらいました。

 

橋田:

はい。ただの動作確認をする人ではなくて、仕様のところから、ここ怪しいんじゃないのみたいな突っ込みとかがあったり。

 

香月:

そうです。ユーザーがどう感じるか含めたUXの部分や、ちょっとした文言が適切なのかとか。そういう細かいところまで全部見てもらいました。

 

橋田:

ていうか、そこまでやってもらうことって、想定してた?

 

香月:

いや、想定してないです。

 

橋田:

良かったこと、だよね。想定してなかったけど、彼女の能力が高くて。

 

香月:

そうです。

 

橋田:

そういう突っ込みもばしばししてくれたのが嬉しい。

 

f:id:peraichi:20170110121129j:plain

 

 

香月:

元々想定して役割でいうと、テスターエンジニアとして入ってもらって、いわゆるEtoEのテストですね。マニュアルテストっていうんですけど、ブラウザーを通した動作確認っていうのを、Seleniumを使って自動化してもらって、それをテストをしまくると。何回も走らせて不具合が出ないかどうかを検証するっていうのをペライチの新しい機能、決済サービス全体を通して仕様を作ってやってもらうということを想定してたんですけど。もちろん、それをやってもらうなかで、想定していなかった仕様バグを見つけたりとか、UXに突っ込みを入れたりとか。

 

橋田:

いやー、彼女のバリューが超ヤバかったよね。いわゆるベンチャーではって話になるかもしれないんだけど、人数が少ないところって個々の能力が本当に重要だし、例えば僕らがこれお願いしますっていった以外のことでクオリティが上がることとか。で、能力を発揮してくれる人が重要かなと。本当に彼女に入ってもらって良かったと思うし、あとは、自走できる人が最強ってよく言うと思うんですけど、今回の例で本当にそうだなと思って。クオリティ良くするために、それ以外の仕事もガンガンやる。つまり、仕様バグだったりUXのところだったり文言のあたりの細かいところもどんどん突っ込んでくれて、皆納得感あるんですよ。そこがすごく良かったよね、入ってもらって。

 

ちょっと話を戻しますけど、その他、例えばテスター以外の部分でいうと、サーバーサイドのエンジニアリングは、2人でどういうふうに進めてたんですか?

 

香月:

2人で役割を決めて進めました。特に決済機能のAPIっていうのがドキュメント量が半端じゃなかったんです。

 

橋田:

あれ、何ページぐらいあったんだっけ?

 

香月:

100ファイルぐらいあって。

 

橋田:

100ファイル??

 

香月:

ページじゃなくて。20ページぐらいのドキュメントが100ファイルぐらいあって。

 

橋田:

やばいやばいやばい。それだけで何ヶ月かかるんだっていう話だね。

 

香月:

そうなんです。なので、APIの部分はサーバーサイドエンジニアの方さんに全てお願いしていました。

 

橋田:

しょうがないよね。

 

香月:

2人で読み込んでも費用対効果が下がるだけなので。

 

橋田:

やるしかない。

 

香月:

そこは分業にして、彼にAPI周りを全部って形でお願いしました。で、僕のほうでいうと、最初、スピード感を出すために一気に作り上げるところで、僕がCakePHPのbake(編集注:CakePHPMVCを自動生成するスクリプト。対話式に作れるのが特徴。)を全部やりました。テーブルを作って、要は基礎の骨組みだけを作るみたいな感じで。あとは、先ずAPI連携が必要な部分っていうのをタスクとして洗い出して彼にお願いするのと、それ以外のところで、それにAPI実装に伴って必要になってくる部分の設計と実装も彼にお願いしました。僕はそれ以外のAPIがあんまり関わらない部分の実装っていうのをやってきました。

 

橋田:

なるほどね。あとは、デザイナー。2人いたと思うんですけど、役割はちょっとさっき軽く話したと思うんですけど、他に何か実装とか進め方ってどんな感じでした?

 

小川:

さっきの話を詳しくいうと、今回、時間がなかったんで、極力手戻りをしたくなかったんです。なので、画面の仕様書をしっかりかためて、作っては定例のミーティングでエンジニア含めてディスカッションしてました。

 

橋田:

何日に1回ぐらいやってました?

 

香月:

2日に1回ですね。

 

小川:

やっぱり仕様上できないものとかあるじゃないですか。ここはこういうふうに本当はしたいけどって。で、そのまま作っちゃってあとでできないってなると、やっぱり手戻りが大きくなっちゃうので、先ず画面仕様書でしっかりと話し合って。あと、そこで疑問があれば直ぐに聞ける環境だったので、ここはこういったときにどういうものが入ってくるんですかとか、そういうのをしっかり詰めて、極力仕様書の完成度を上げてからデザインをやるもう一人のデザイナーにUIを作ってもらい、コーディングをお願いしました。UIのデザインに関しては、基本は本当におまかせで。最初に1個作ってもらったんですけど、それを見たときに、全然いけるなと思ったので。

 

橋田:

そこがスムーズにいったのは良いですね。

 

小川:

そうですね。逆にそこが複数になったときは、本当にUIとかデザインの設計もしっかり作らなきゃバラバラになっちゃうんでいけないんですけど。今回、良い意味で、関わった人数が少なかったので、ほぼ、そういったガイドラインを作らずとも暗黙知的な感じで進めていけましたので。

 

橋田:

そこは普段から一緒にやってるってとこが結構大きかったですね。

 

小川:

大きかったですね。もう一人のデザイナーがよく隣でやってたんで、ちょっと教えてとか、これどうしますっていうのは気軽に聞けたんで。

 

続きはこちら!

blog.peraichi.com

決済プランチーム座談会 #1 プロジェクト立ち上げ

こんにちは!ペライチ代表の橋田です。

ペライチでは決済機能を昨年11月にリリースしたのですが、その開発で色々あったので、そういったお話を座談会形式でお話していきたいと思います!

結構ボリュームありますので、何回かに分けてお話して行きたいと思います。

 

登場人物

f:id:peraichi:20170105120003j:plain

橋田(はっしー 写真右):代表。今回のモデレータ

香月(かっきー 写真左):プロダクトマネージャー兼エンジニア。

小川(写真中央):デザイナー。

 

橋田:

それでは、決済チームの決済プロジェクトの座談会を始めたいと思います。よろしくお願いします。

 

一同

よろしくお願いします。

 

橋田:

今、登場人物としましては、私、代表の橋田とエンジニアリーダーの香月とデザイナーの小川さんがいるんですけど、この3人に加えて他にもまだメンバーがいたと思うんですよね。なので先に、どういうプロジェクトでどういうメンバーでどういう目的で決済プロジェクトって始めたんだっけというところから。かっきー(香月)に説明してもらおうかな。

 

香月:

決済プロジェクトは、ペライチの掲げる「”つくれる”のその先へ」っていうビジョンを掲げていて、ユーザーさんがページを作れるだけじゃなくて、その先にページを通して、事業や自分のビジネスが上手くいったりとか目的を達成してもらう、課題を解決してもらうっていうことを考えています。ペライチ決済では、その「”つくれる”」の部分ではなく「”つくれる”のその先へ」の「その先へ」の部分の1つとして、ユーザさんが自分のページで物を売れるようにしたいですというニーズに応えるためのプロジェクトです。

 

橋田:

良いですね。なんか、壮大ですね!

 

香月:

きっかけとしては、ウチの山下(取締役・ビジネスサイド担当)がネット通販業界や決済業界のプロフェッショナル2人とペライチを通して決済ができるようになったらこういう未来があるよねというような話が出たらしくてその2人を巻き込み最優先でやろうと言い出しました。

開発陣としても事業インパクトが大きいと判断して優先順位を高めて2ヶ月で整えました。

 

橋田:

なるほどね。

 

香月:

で、経営陣にその話が来たときに、それで良いんじゃないのっていう話になって、一気に進めましょうということになって立ち上がりました。そこからはもう、ペライチの他のプロジェクトの優先度を全部下げて、決済プロジェクトを優先度をマックスにして走り出したんですが、最初は少人数で、僕香月がPMで、デザイナーの小川さん、あとはサーバーサイドエンジニア1名、UIデザイナーの1名の4人で走り出しました。

 

橋田:

なるほど。ベンチャーの意思決定の話っていうのが結構色んな人に聞かれるんですけど、例えば、今のざっくりとしたプロジェクトの目標とかタイミングっていうのがあって、その上で、決めて直ぐ作るみたいな感じだったと思うけど、そこに至った経営陣の意思決定ってどういうのがあったんだっけ?

 

香月:

経営陣の意思決定としては、次の資金調達に向けて、ARPU(一人あたりの売上単価)を上げる次の一手を求めていたときに、ある程度確実性が高くて、数字も上がりそうだなっていうプロジェクトとして決済プロジェクトが最適だなという判断でこれをすすめることに至りました。

 

橋田:

経営陣で、意思決定するときに気にしてる大事なポイントってあります?

 

香月:

事業に与えるインパクトとそれを実現するためにかかるリソースっていうのの兼ね合いで決めてます。なので、インパクトが大きければ大きいほど良いんですけど、大きいほど工数がかかりがちなので、なるべく最小の工数で事業インパクトが大きいものを起こせる機能を新しいプロジェクトとして進めるようにしています。

 

橋田:

なるほど。今回6月とかに意思決定して、7月ぐらいから直ぐスタートして、8月までに作りきるみたいな最初のスケジュールだったと思うんだけど、それってすごくベンチャーっぽいなと思っていて、その決定ができたのって何でだろうかとか。結論から言うと、普通だったらあんまりそういう決定できないと思うんですよ。既存で動いているものもあるし、それをゴリっと変えて、チームをいきなり作って走らせるって、普通難しいなって思うんですけど。そこってどう?

 

香月:

少人数だからじゃないですかね。

 

橋田:

例えば、プレーヤーの立場に立つと、今やってるものを止めてとか、せっかくやってたのに遅らせて、お前明日からこれやれみたいに言われたら、絶対に反発が起きると思うんですけど。それってウチの会社だったら何で今できるんですかね?

 

香月:

それで言うと、経営陣と現場のメンバーの距離が近いからですね。

 

橋田:

小川さん、ぶっちゃけどう思います?普通だったら、小川さんもフル稼働してるじゃないですか。その中で、やっぱりこう決めたから明日からこうするわみたいな言われたときに、ちょっとモヤっとしないですか?



小川:

単なる思い付きとか経営陣がちょっとやってみたいとか、そこに理由がなければ、それは何でってことにはなります。でもさっきの話の通り、何で今それをやるかが明確になっているので、それを考えたときにやっぱり自分たちはサービスを良くしたりとかユーザを増やしたいっていう気持ちがあるので、全然納得して進められましたね。

 

橋田:

納得感ですよね。結局。

 

小川:

そうですね。

 

橋田:

チームとしてこれが大事だよっていうことが同じ、というかすり合わせができているかどうかなので。デザイナーとしてこれが大事だとかエンジニアとしてこれが大事だとかビジネスサイドとしてこれが大事みたいなのがあると思うんですけど、そこのお互いのすり合わせが短時間でも、もしくはずっと築いてきた関係値の中で、もしくはチームの雰囲気としてそれができているのであれば、お互い納得感あって進められるっていう感じなのかな。で、大きい組織になればなる程、それがやり辛くなってくるよねみたいな話なのかなと思うんだけど。

 

小川:

距離が近いんで、そういったバックグラウンドが共有できているので、やるべきことが明確になりますね。

 

橋田:

了解です。もう1個テーマとしては、スケジュール短いじゃないですか。で、色々やりたいと思うんだけど、僕の記憶では、例えば最低限のものを最速で作って出すみたいな感じのコンセプトで進めて、残りはあとでやろうみたいな感じだと思うんですけど、そこら辺についてちょっと、どういうふうにそれを決めていったかとか話してもらえますか。

 

香月:

別のプロジェクトとしてEC系の会社さんと組んで新しいプランを出すというものが走っていたのですが、広報インパクト的にリリースのタイミングを併せた方が良いよねという話になりました。で、問題があって、そのリリース日っていうのが2ヶ月後ですと。その2ヶ月しかないなかで、いかに作っていくかというところを考えてやらなきゃいけなかったんですけど。先にケツがほぼ決まってたって話だよね。それで工夫したところで言うと、最初、スピード感をもたせたかったので、全部、僕(香月)のほうで、そのプロジェクトが決まってから、要件定義、設計、データベースのテーブル設計、全ての仕様みたいなところを全部がーっと詰めて。

 

橋田:

それ、どのぐらい時間かけてやった?何週間ぐらい?

 

香月:

それは、サーバーサイドエンジニアと色々ディスカッションしながら進めて、1週間ぐらいですね。

 

橋田:

一週間か。大分詰めたよね。

 

香月:

結構、大きな、それだけでテーブル数が10数テーブル増えるぐらい。

 

橋田:

結構あるね。そうだよね。

 

香月:

はい。結構大掛かりなプロジェクトになってたので、それだけで結構時間かかりましたね。ただ、その中でもプロジェクトメンバーのエンジニアを巻き込んで初速を出す事をかなり意識しました。そこから実装に入ったときは、最初、僕とそのエンジニアと2人で二人三脚で始めていて、お互いにお互いのソースコードをレビューし合うみたいな感じで、ドンドン相手にこれレビューしてくださいっていうのを送り付けるみたいな感じで。

 

橋田:

送り付ける。怖いよ。

 

一同

(笑い)

f:id:peraichi:20170105120529j:plain

 

香月:

スピード重視でプロトタイプみたいなのを作り上げていった感じです。

 

橋田:

期限が決まっている段階で、どれを作る、作らないみたいな判断って、どういう基準でやっていました?

 

香月:

どれを作る、作らないかの判断でいうと。

 

橋田:

判断基準は皆気になると思うんですよ。

 

香月:

とにかく、これは必要だよね、これはまだ必要ないよねみたいな。1番最初に出すにあたって最低限何が必要かっていうことをディスカッションして決めました。

 

橋田:

例えばどういうことですか?最低限必要な機能って。

 

香月:

最低限ショップオーナーの立場で、自分が作ったページで決済機能が出るっていったときに、どういう機能が必要なのかっていうテーマでディスカッションしたりとか。例えば購入できることは最低限必要だよねとか。例えば他の決済サービスでは商品登録時に画像も一緒に登録する仕様になってるものが多いですが、ペライチの場合画像はページ内に配置出来るので、商品画像登録は必要ないよねとか。

 

橋田:

そこが全然、他とは違うんだよね。

 

香月:

そうですね。そういう意味では、他のサービス、色々、いわゆる競合となるようなサービスを調べて、色んなところを参考にさせてもらったんですけど、ペライチはやっぱりペライチ独自の仕様というか。設計になっているので、それに合わせて最小で何を作るかっていうのを決めたって感じですか。

 

橋田:

ということはつまり、期限があって最小のものを作る。でも、色々やりたいことが出てくるから、それをフェーズ2、フェーズ3みたいにして、この次ではこれやりたいよねみたいなリストはあったりするよね。

 

香月:

そうですね。プロジェクト全員が見れるスプレッドシートがあるんですけど、そこに気になることリストみたいなのを作っておいて、気になることとか、次、こういう機能あったら良いんじゃないかみたいなのをどんどんそこに各々が入れていけるような感じにしましたね。で、それを定例の会議で整理するっていう運用をしていました。

 

続きはこちら!

blog.peraichi.com

【エンジニア必見!】CTOが語る、プロダクトを急成長させるための秘訣

イベント・セミナー

f:id:peraichi:20161221151932p:plain

みなさん初めまして!10月からペライチにてエンジニアインターンをしております加藤です!

 

今回、2016年11月29日(火)に株式会社ミクシィ様のイベントスペースにて弊社、ホットスタートアップ主催の第1回CTO Talk「CTOが語る、プロダクトを急成長させるための秘訣」が開催されました!エンジニアを目指す身からすれば「CTO」は神的存在です。そんな「神ってる」CTOの方々がどのように自分たちのプロダクトを成長させてきたのか。その秘訣をレポートしていきたいと思います!

 

f:id:peraichi:20161221135444j:plain

メインテーマ

  1. 開発スピードを上げる取り組み
  2. スピードアップを実現するチーム・組織の作り方
  3. 技術者が経営にどれだけ携われているのか

 

そして、今回は下記の4名の方々によるCTOトークが行われました!

 

モデレーター

和田修一氏

f:id:peraichi:20161221152110j:plain

2009年に株式会社nanapi(旧株式会社ロケットスタート)の取締役CTOに就任し、nanapiを中心とした開発やマネージメントなどを担当。2014年に株式会社nanapiを売却後はエンジニアとして新規のサービス開発に携わる。現在担当している技術分野はiOSアプリ開発。また、個人では他社のアドバイザーや顧問なども務める。

 

パネラー

横澤佑輔氏

f:id:peraichi:20161221152142j:plain

nomad イタンジ株式会社 取締役CTO

1983年生まれ。日本電子専門学校卒業、産業技術大学院大学人間中心設計修了。大日本印刷株式会社グループにて通販や定期購読のフルフィルメントシステムの企画構築。株式会社ゲオホールディングスグループにて各種インターネットサービスの開発を経て2014年4月よりイタンジ株式会社に入社。

 

岡利幸氏

f:id:peraichi:20161221152231j:plain

yenta 株式会社アトラエ 取締役 CTO

2007年にアトラエの新卒一期生として入社後、転職サイトGreenの立ち上げの新規営業として3年間従事した後、エンジニアに転向して復数の新規事業を開発して事業責任者を務め、現在はCTO兼新規事業統括としてTalentBaseやyentaの責任者を務める。

 

香月雄介氏

f:id:peraichi:20161221152714p:plain

ペライチ 株式会社ホットスタートアップ 取締役 共同創業者

中央大学卒業後、制作会社にてiOSエンジニアとして勤務。その後1年ほどフリーランスを経てベンチャー企業に取締役CTOとして加入し、バーティカルメディアの立上げを行う。2014年取締役兼共同創業者として株式会社ホットスタートアップを創業。2015年4月「ペライチ」をリリース。

 

以上4名の方に今回の3つのメインテーマについてお話していただきました。登壇者のみなさんの経歴が多種多様なので、様々な視点のお話が伺えたので、それぞれの質問に対しての意見をパネラーごとにまとめてみました!

 

f:id:peraichi:20161221135550j:plain

 

開発スピードを上げるためにしていることとは?

プロダクト開発において大切になってくるのが、「開発スピードをどう上げるか」。これはプロジェクトマネージャー(PM)なら必ず悩む課題であると思います!

 

横澤氏「どうやって市場を捉える開発をしていくかの方が課題。」

開発スピードをボトルネックだとは考えておらず、それとは違う点がプロダクト開発する上での課題になるのではないかと考えている。その課題とは、「書いたコードが市場を捉えているかどうか」。イタンジでは、エンジニアであってもPMと営業を兼任する様な事もあり、要件定義と開発を同じ人が実施することも多い。その結果、書いたコードが市場を捉えているかどうかをエンジニア自身がダイレクトに感じることができている。そのような取り組みを通して、まずは市場を捉えるコードを書けているかを重視している。

 

岡氏「作る前にイメージの可視化をする。」

アトラエでは、なるべく少人数のチームでプロジェクトを回すようにしており、特に新規事業の立ち上げ時などであれば、ベストは3〜6人程度。アトラエでは新規事業を立ち上げるのもエンジニアであることが多く、エンジニアが企画などをすることが当たり前になっている。プロダクトの性質によって差はあるが、企画段階でイメージをデザインにしたり、コードで書いたりと目に見えて手に取れる形にしてプロトタイプの段階でUXやサービス価値などのブラッシュアップができるようにしている。このプロセスを経て開発に入ったプロジェクトでは、全員がUXや価値まで全てを理解した状態で開発ができるため、開発スピードも早くなるし開発中の変化も臨機応変に対応できる。

 

月氏「各プロジェクトに権限を移譲。」

ペライチでは各プロジェクトに権限を移譲することでスピードを上げている。基本的に開発をする際は細かいプロジェクトに割り、それぞれのプロジェクト内で方向性などは決めてもらっている。しかし、ペライチでは業務委託の方の数が社員に比べて多い。最終的な意思決定は社員で行なっているため、そこでレビュー待ちが溜まっている状態で、そこのフローの改善は今後の課題としても上がっている。

 

最初の質問から解が異なっていて面白いですね!開発スピードをあげることを意識する中で、いかに質も落とさず実行していくかがカギになるようですね!



f:id:peraichi:20161221135645j:plain



スピードアップを実現するチーム・組織の作り方

チームをまとめる人にとってここが難しいところなのではないでしょうか?チームの作り方次第で開発スピードには大きく影響が出てくるので、是非彼らが取り組んでいることを聞いてみましょう!

 

月氏「ビジョンの共有が大事。」

チームを信用していないと権限を委譲するなんてことはできない。それを可能にしているのが、「ビジョンの共有」。会社が何をビジョンとして掲げ、何を大事にし、何を目指しているのかを全員に浸透させるために、毎朝会社のビジョンと価値観の読み上げをやっています。これにより、どのようなビジョンを社として掲げているかの理解ができるため、組織作りの上でビジョンの共有を重要視している。

 

岡氏「エンジニア未経験だからこそこだわりがない。」

アトラエでは未経験からエンジニアになっているメンバーが多く、しかもそのメンバーがリードエンジニアとして活躍をしている。このことが影響してか、エンジニアとしての役割を意識しすぎないなど、マイナスになるようなこだわりをもっていない。技術に固執しすぎず、プロダクトの成長や価値の向上だけにフォーカスして建設的な議論ができる人々を採用・育成することを大事にしている点である。また、自分がもともと営業として入社しており、そこからエンジニアになったため、営業・エンジニアのモチベーションの源泉が違うことや、それぞれが持つ価値や特性などを理解しているので、そこを考えながらチームづくりをしている。

 

横澤氏「ボトムアップによるビジョン作り。」

創業メンバーの退任等、会社としての根幹が揺れ動いてきた過去の経緯もあり、創業時に定められたビジョンやバリューが会社の進化や変化についてこれていない状況になっていた。その状況を変えるために、実際の行動によって文化を作ってきたメンバーによってボトムアップでビジョンとバリューを見直した。ボトムアップにより、自分たちが何をするべきかを全員が熟考、再考した上でビジョンとバリューが再定義されており、社員一人ひとりの頭に根付いている為、トップダウンでビジョンを共有する必要はあまり無い状態になっていた。それは各社員がしっかり考えるという環境になっており、それがイタンジのチームを作っているものでもある。

 

チーム作りにおいては、組織に規模やその会社の特徴、歴史などで大きく変わってくるのがわかりますね!

 

f:id:peraichi:20161221135817j:plain

 

技術者が経営にどれだけ携われているのか

技術者が経営に携われるかどうかで会社の雰囲気だけでなく、方向性なども大きく変わることがあるので、実際のところみなさんはどれくらい携われているのでしょうか?



岡氏 「エンジニアがやりたいことをできる環境作り。」

経営側から技術面に関しての制度やルールは要求することは全くといっていいほどない。そのためエンジニアが率先して組織づくりや必要があればルール作りを行い、自分たちで組織を作る風土にしている。現在の経営メンバーも半数が技術者なので、エンジニアがやりたい、やるべきことができる環境づくりも当たり前のようにしている。また、技術者が新しく挑戦したいことには、明らかにおかしいという点がなければ基本的には口を挟まずに任せるようにしている。



横澤氏 「実力以上の意思決定においての課題。」

現在は常勤役員が二人なので自分に50%の裁量権があるため経営にはしっかり携わることができている。しかし、技術的な意思決定については自分に偏ってしまい、意思決定のキャップに成り得ることが課題。現状では大規模なことを決定する際には外部の人にアドバイスを頂いているが、今後は自分の実力以上の観点からの技術的意思決定を、どのように出来るかを考えなくてはいけない。

 

月氏 「創業メンバー3人の役割分担。」

経営に関しては、創業者が自分を含めて3人おり、それぞれの役割分担を明確にして、お互いの判断を信頼しているため役割内の経営的判断であれば任せ合っている。そのため、経営の意思決定などの面で衝突を起こすことはほとんどない。技術的な意思決定においては、その技術領域において自分より技術力のある現場のメンバーに一任することも多い

 

今回パネラーとしてお話をされた3名の方々は、技術者として経営に携われている印象を受けました!その先に課題などは当然あるものの、技術者でありながら経営面も支えているという点はすごいの一言に尽きます!そして、パネルトークの後の懇親会では様々な業界で活躍されている方々とお話しする機会もあり、普段は接する機会がない方々だったので懇親会もすごく充実した時間でした!

 

f:id:peraichi:20161221142558j:plain

f:id:peraichi:20161221142648j:plain

f:id:peraichi:20161221142733j:plain

いかがでしたでしょうか?今回の第一回CTOトークでは業界も規模も様々な会社の方々にお越しいただきそれぞれの状況などについてお話いただきました!やはりCTOを務めている方々は自分たちのやり方を持ってそれぞれの課題に取り組んでいることがよくわかりました!

f:id:peraichi:20161221142743j:plain

 

CTOトークは第二回も2016年春頃に開催予定なので、興味がある方は是非お申し込みしていただければと思います!

 

ペライチのエンジニア向けイベントにお申込みいただいたことない方は、connpassのペライチグループから[メンバーになる]を押して頂けると、最新のイベントが立ち上がったときにメールで通知が行きますので、是非押してくださいね!

 

簡単ウェブページ作成サービス『ペライチ』内で、『PIXTA』の素材1640万点を購入・利用可能に!

新機能 お知らせ ペライチ プレスリリース

こんにちは、ペライチの藤田彩月です。

この度、株式会社ホットスタートアップは、ピクスタ株式会社が運営するインターネット上でデジタル素材を仕入から販売まで行うオンラインマーケットプレイスPIXTA』のAPI(画像の検索・購入機能)と連携いたしました。

これにより、ペライチのページ作成画面上で、PIXTA』の素材1640万点の内、好きな写真やイラストを購入し、そのままページへ反映できるようになりました!

f:id:peraichi:20161201121003p:plain

 

 

「誰でも・カンタンに・素早く」スマホ対応のウェブページが作成できるサービス『ペライチ』を開発・運営する株式会社ホットスタートアップは、2016年12月1日より、ピクスタ株式会社が運営するインターネット上でデジタル素材を仕入から販売まで行うオンラインマーケットプレイスPIXTA』のAPI(画像の検索・購入機能)と連携することにより、ペライチのページ作成画面上で、好きな写真やイラストをPIXTAで販売する画像素材の内、1640万点以上の中から購入し、そのままページ反映ができるようになります。

 

 

本連携の概要

ペライチがPIXTAAPI(画像の検索・購入機能)と連携したことにより、ペライチのユーザーがページ作成画面上で、PIXTAで販売される画像素材の内、1640万点以上の中から好きなものを探し購入、その素材をそのままページへ反映できるようになります。

これによって、写真やイラスト等のページ作成に必要な素材をペライチ内で完結して揃えられ、今まで以上に魅力的なページを素早く作成できるようになります。

 

 

◆本連携の特長

特長①

今まで写真やイラストの用意ができずお困りのユーザーにとっては、ページの表現の幅が格段に広がります。

※ ペライチの同一アカウント内におけるすべてのページで無期限でご利用いただけます。

 

特長②

購入した写真やイラストをそのままページに反映できるため、短時間で、ストレスなく、お好みのウェブページを作成することができます。

※ 画像のフレームやフィルタ加工、レイアウト編集もペライチ上で簡単にできます。

※ ペライチ内で購入された写真・イラストは、ペライチで作成したページ内でのみご利用いただけます。

 

 

ペライチ内での画像検索・購入・利用時のイメージ

f:id:peraichi:20161201121224p:plain

                           〈イメージ1_”画像検索”〉

 

f:id:peraichi:20161201121335p:plain

                    〈イメージ2_”選択した画像の詳細確認”〉

 

f:id:peraichi:20161201121418p:plain

                           〈イメージ3_”画像購入”〉

 

f:id:peraichi:20161201121445p:plain

                     〈イメージ4_”ペライチページへの反映”〉

 

 

▼「誰でも・カンタンに・素早く」スマホ対応のウェブページが作成できる『ペライチ』

運営:株式会社ホットスタートアップ

ページURL:https://peraichi.com/

デザインやHTMLなどの専門知識や技術が不要で、「誰でも・カンタンに・素早く」目的に応じたウェブページを無料から作れるサービスです。パソコンとネットさえあれば、スマホタブレットで見る際も自動で対応し、プロがデザインしたようなページを直感的に作成できます。専門知識や技術がなく、時間と費用をかけずに効率よく作りたい法人や個人を主な対象としています。最近ではSEO効果も高いことで評判です。2015年4月のリリース以降、SNSや口コミを中心に拡散し、25,000以上のあらゆる業界の法人や個人に利用されています。

 

 

◆連携企業

ピクスタ株式会社

「個人が生み出すオンリーワン」を支援したいという想いから、2005年8月に創業。誰もが参加できるフラットな投稿スタイルで、高品質・低価格な写真・イラスト・動画のデジタル素材をインターネット上で売買できるデジタル素材のマーケットプレイスPIXTA」(ピクスタ)を2006年5月に開設。現在、日本国内最大級のストックフォトサイトに成長し、20万人以上のクリエイターによる2000万点以上の素材を販売しています。2015年には東証マザーズに上場。API連携もスタート。2016年からは、新規事業として出張撮影マッチングサービス「fotowa(フォトワ)」も開始。個人の才能を発揮できる機会の最大化を目指し、アジアNo.1のクリエイティブ・プラットフォームを目指しています。

ホームページ:https://pixta.co.jp/

PIXTAhttps://pixta.jp

fotowa:https://fotowa.com/

 

 

【株式会社ホットスタートアップについて】

所在地   :〒150-0042 東京都渋谷区宇田川町36-6 ワールド宇田川ビル 6F A号

事業内容  :Webサービス「ペライチ」の開発・運営

代表者   :橋田一秀

ホームページ:http://hotstartup.jp/

 

【本件に関するお問い合わせ先】

株式会社ホットスタートアップ

担当者:山下翔一 藤田彩

所在地:〒150-0042 東京都渋谷区宇田川町36-6 ワールド宇田川ビル 6F A号

TEL :03-6455-0498

MAIL  :yamashita@hotstartup.jp