PHPでブラウザテストの自動化！ Facebookの作ったツール「php-webdriver」で人生がときめく (サンプルコード付き)

こんにちは、コネヒトでPHP書いたりしています金城(@o0h_)ともうします。烏龍茶が好きです。

(テスト自動化おじさんの弊社内におけるイメージ)

突然ですが！ 皆さんも、自分の実装についていまいち自信が持てない時はございませぬか。
「あの実装・・頭をよぎる不安・・眠れない夜・・・・」そんな気分で毎日を過ごしていませんか？
「誰かに許して欲しい、安心をください」。
そんな時はテストを書きますよね。緑色が好きな人、この界隈には私だけではないはずです！

ただ、どうしても検査しづらいな〜どうやって試せば良いかな〜と悩ましい時もあるのではないかと。
「エンドユーザーが直接触るのってブラウザでしょ、だったら実際にブラウザを使った操作が滞りなく可能なら問題ないよね・・」とか、考えたことありませんか？
ここで闇堕ちしたプログラマは、ぽちぽちとhttp://localhostを開いたGoogle Chromeをマウスで弄って、束の間の平穏を得るのです。(身に覚えがあります)

ただ、これって恐ろしく面倒くさいし不安定だし絶対に毎回やらない手順です。
誰か勝手にやってくれ！

それ、Seleniumでできるよ

「ブラウザの操作をプログラマブルにしたい、しかもPHPで書きたい」。
それを実現する技術がございます。 百聞は一見にしかず、ということで「PHPがブラウザを動かしているサマ」を実際にご覧ください。

最初にCakePHPのテストコマンドを実行させた以降は、キーボードもマウスも一切触っていません。こういった、「ページを開いて→指定した要素をクリックして→フォームに値を入力して→送信ボタンを押して→フォームの送信結果をみる」という操作及び検査ができるのです。
しかも、非常にシンプルかつ短い行数のコードで実現で！！
実際に上記動画にて叩いたコードを参照しながら、ご紹介したいと思います。

サービスの成長を止めたらあかん！『よりよいCSS設計』を考えよう！

はじめまして！デザイナーのきよえし(@kiyoe_furuichi)です。 ママリ、ママリQ のUIデザインとフロントコーディングを担当しています。最近暑すぎて溶けそうです。スイカたべたい！

さて今回は、爆速で拡大成長中のママリが行っている『よりよいCSS設計のための開発手法』についてまとめてみました。

『よりよいCSS設計』を考える

「あれ？スタイル効かない…!importantしよ♡」

身の回りでこのようなことは起きていませんか…？ 意図しないことが頻繁に起こる場合『CSS設計』の見直しが必要かもしれません。

私たちは普段からサービスを成長させていくにあたって『よりよいCSS設計』とはなにかを考え、チーム内で検討し、改善をおこなっています。
そんな私たちが実践している開発手法や取り組んでいることについて、いくつかご紹介していきたいと思います。

きっかけ

はじめに、私が『よりよいCSS設計』を考えはじめたのは、他のエンジニアさんと一緒にフロント開発をすることになったときに自分の不甲斐なさを感じたのがきっかけでした。
これまでひとりでデザイン/フロント実装を受け持っていた経験しかなく、他のエンジニアさんが書いたコードをレビューする、また私が書いたコードをレビューして頂くことが初めてのことでした。そこでいかに自分の書き方が負の遺産を生み出す書き方をしていたかを知って、悔しくなったので改めてCSSのことを勉強し直しました。
それを機にCSSの書き方や、設計について深く興味を持つようになり、今ではサービスにとってそれが『よりよい設計』であるか、またその設計がユーザー体験(開発者含め)、にとってどう良いのかを考える『CSSおねえさん』へと進化しました！

CSS Architecture

私たちの考える『よいCSS設計』の定義は、色々検討した結果、1番納得感のあるPhilip Waltonさんが提案するCSS Architectureをベースとして考えることにしました。

CSS Architectureでは、以下のようなCSS設計をする上で目指すべき4つのゴールを掲げています。 他にもバッドプラクティスの改善方法など、よりよい設計のためのポイントがいくつか提案されています。

1.『予測しやすいこと』

追加や更新をしたスタイルがちゃんと期待通りに振る舞うことのできる設計にしましょう。 そのスタイルが意図していない箇所に影響を与えないようにすること。

2.『再利用しやすいこと』

スタイルは、ボタンやフォームなど機能ごとに細かく分離した設計にしましょう。 再利用性のあるコードを書くことで再度同じUIを作成する場合、新しく追加する手間がなくなります。

3.『保守しやすいこと』

要素を追加・更新したことによって、既存のスタイルをリファクタリングするようなことが起こらない設計にしましょう。

4.『拡張しやすいこと』

サイトの規模が大きくなっても、複数の開発者がメンテナンス・管理しやすい設計にしましょう。

これらをまとめると、『メンテナブルな設計』が、よいCSS設計のゴールであると考えられます。 CSSは書くのがかんたんな分、破綻しやすいので運用・管理をしっかりと考えた設計にすることが大切ですね。

ちなみにCSS Architectureはどんな環境で設計するにおいても(他言語においても)参考になるお話なので、読んでおくと幸せになれるかもしれません！

参考 :
CSS Architecture
Hiroki Taniさんの日本語訳 CSS Architecture

私たちが実践している『CSS設計の開発手法』

私たちの開発環境では、CSSの設計ガイドラインとしてFLOCSS(フロックス)、コーディング規約にGoogle HTML/CSS Style Guideを採用しています。 ただ、これらに完全に準拠しているわけではなく、それぞれの考え方をベースとして自社の環境に合うものを取捨選択しています。

FLOCSSを用いたCSS設計

ママリではつい先日、CSS設計のガイドラインとしてFLOCSS(フロックス)を採用しました。 現在は要素の追加・変更時などに、FLOCSSに沿った設計となるようリファクタリングを行っています。

FLOCSSとは？

BEMの命名、MCSSやSMACSSのレイヤー設計などの考え方を組み合わせた『CSS設計ガイドライン』です。メロン本で有名ですね！ CSS ArchitectureがCSS設計の目指すべきゴールで、FLOCSSは破綻しやすいCSSをコンポーネント(部品)として扱うことによって、再利用性や保守性を高めるCSSの設計ガイドラインです。

参考 :
FLOCSS
CSS設計の教科書 (メロン本)

FLOCSSを使うメリット

個人的に使ってみて感じたものですが以下のメリットがあるかなと思います！

• 学習コストが低いこと。とりあえずメロン本を読めば大丈夫！
• 日本製なのでほかのガイドラインと比べて取り組みやすかった。
• OOCSSをベースに作られているので、エンジニアにとっても構造の理解がしやすい
• Objectは先頭に .c-* や .p-* などのプレフィックスをつけるので直感的に構造の把握ができる。

コーディング規約

Google HTML/CSS Style Guideとは？

Googleが提案するHTML/CSSの『コーディング規約』です。命名規則、インデントやスペースの開け方などが細かく定められています。

参考 :
Google HTML/CSS Style Guide
「Google HTML/CSS Style Guide」を適当に和訳してみた |

コーディング規約は、Google HTML/CSS Style Guideを採用しています。 コードの書き方も『よりよいCSS設計』を目指すことにおいて考えるべき要素のひとつと考えています。特に複数の開発者がコードを管理する場合、『コードの読みやすさ』を考えることはとても大切です。
インデントやプロパティの記述などが揃っているだけでも全体のコードを読んで理解するまでの早さって結構変わるんですよね。
現状単独での開発行っているとしても将来的にメンバーが増えることが見込まれるのであれば、何かしらの規約を設けて『オレオレコード』とならないように整形するのがベターかとおもいます！

社内コーディング規約

他にも社内でのコーディング規約として以下を定めています。

たとえば、

• サイズの単位は基本的に px で書く。
• class名で使用する単語はなるべく省略しない。
• Role of threeにのっとって、各違う箇所で３回同じ要素を使用する場合は、再利用することを検討する。(リファクタリング)
• jsで使用するclassはスタイルを適用するclassとは別に付与する。
• jsで使用するclassはわかりやすく先頭に .js-* プレフィックスをつける。

他にも、開発の中でこれは？というものがあれば都度相談しあって、ルールを更新しています。

『よりよいCSS設計』を生み出す

さて、いかがでしたでしょうか。 今回ご紹介した内容が、みなさんの『よりよいCSS設計』を考える上で、お役にたてると幸いです。

私たちも模索をしながら日々『よりよいCSS設計』について改善を行っています。 現段階で、これだ！な答えはまだありませんが、実装する中で意識していることがあります。

『もし明日から10人、100人のエンジニアを採用して共にママリの開発をすることになったとき、ひとりひとりが容易にコードを理解できる設計であること。いかなるときも、成長のスピードを止めないために、バトンを渡しやすい環境を維持し続けること。』です。

例えば、明日から新しいエンジニアがジョインしてくれるかもしれない → ここの要素ちょっとわかりずらい気がするからコメントをしっかりめに書いておこう。みたいに この先、どうなっていくかを想像してコードを書くことができるようになると思います。

ゴールとしては『メンテナブルな設計』を目指すことに変わりはないですが、なぜそれが必要なのかを意識的に想像することで、もっと普段から『よりよく』書けるようになれると思います。

その小さな積み重ねや、コードは一時的な実装のために書くのではなく、サービスの成長のために書く、といった想いを持つことは自然と『よりよいCSS設計』を生み出すことにつながるのではないでしょうか。

今後も引き続き『よりよいCSS設計』について考えていきたいと思います！

また、みなさんもあらためて考えてみませんか？

おわりに

Connehito.incではいけてるエンジニアとデザイナーを募集してます！
爆速で拡大成長中のサービスのCSS設計をいっしょに構築しませんか？？

ぜひラフにランチでも〜！よろしくお願いします！

www.wantedly.com

コネヒト社の女性向けサービスを支える女神 〜海未編〜

初めまして、コネヒト所属のラブライバー田村(@Utmrer)です。 今日は「CTO以外もブログ書けよ」ってことで私が弊社の女性向けサービス（ママリ・ママリQ）を支える女神についてご紹介致します。

弊社のサービスを支える女神たち

現在、弊社のサービス開発は次の3人の女神たちによって支えられています。

• コミュニティマネジメントを効率化することり
• DeveloperとDirectorを繋ぐ花陽(はなよ)
• Pull Requestの質を高める海未(うみ)

今日は海未についてご紹介致します。

海未が生まれるまで抱えていた問題

弊社のサービスは去年まで私とCTOの2人のエンジニアによって開発されていましたが、春からはμ'sのように新しくエンジニア入ってきて以前の倍以上のエンジニアによって開発されています。
人数が増えたのはいいのですが、Pull Requestのレビューに関して以前よりも情報共有の不足が起こり易くなりました。

• このPull Requestってなんのためにやるんだっけ？
• この実装で十分なんだっけ？
• 重点的にレビューするべきなのはどこなんだろう？

このようなPull Requestのコンテキストをレビュアーが把握していないというケースがありました。

海未が生まれるまでの解決策

そこで最初に導入したのがクックパッドさんのこの記事に書いてある「目的」と「やったこと」を書くスタイルです。
これによって「なぜこのPull Requestが作られたのか」を把握できるようになりました。
ここで私は思います。
「いちいちメモ帳からコピペするのめんどくさいですね…」

めんどくさいなら自動化する

メモ帳からコピペしてくるのがめんどくさいのでPull Requestを作る時に勝手に入力してくれるChrome Extensionを作りました、それが海未です。
Pull Requetを作るページの#pull_request_bodyを探して次のような典型分を入力します。

## 目的


## やったこと


## 追うべき数値


## 関連するIssue


## チェック項目
- [ ] File Changedのセルフレビュー
- [ ] Conflictを解消したか

定型文の各項目は下記のような内容です。

目的

ここには「なぜこのPull Requestが作られたか」を書きます。この項目は抽象的で要求仕様であることが多いです。

やったこと

ここには実際に行った実装の内容が入ります。ロジックの内容を書いたりして、レビュアーはこの項目に書かれている通りに実装されているかをレビューします。

追うべき数値

弊社ではリリースされた機能は必ず振り返ります。振り返りの仕方などは以前に弊社CTOの島田が公開した独身男性のためのデータドリブン講座にて紹介しています。

tech.connehito.com

ここにどのような数値を追うべきか、その値がいくつだと「良い結果」と判断するか、などを書きます。

関連するIssue

Pull Requestがトピックブランチからさらに切られたトピックブランチだった場合、親ブランチが何なのかを把握しなければレビュー出来ない場合があります。
その場合にここにブランチが切られた流れを書くことでレビュアーは事前知識を得ることが出来ます。

チェック項目

これは一度セルフチェックすれば無くなるようなコミュニケーションを少なくするためです。
「ここスペルが違います」「改行の量が明らかに多いです」「こんなの破廉恥(はれんち)です！」など、こういった単純なミスは極力事前に減らしたいですね。

サンプル

このテンプレートにそって実際に作るとこんな感じになります。

海未を導入して

海未を導入することによってコピペするという作業が効率化された上に、Pull Requestのクオリティが上がりレビューコストが下がって作業効率が上がったと実感しています。
なぜ海未という名前なのかというと、「Pull Requestのdescriptionをちゃんと書こう」と注意するのって誰だろうと考えた時に海未ちゃんだったんです。
ほら、聞こえませんか？
「穂乃果(ほのか)、Pull Requestのdescriptionはちゃんと書かないといけませんよ。」
という海未ちゃんの声が…。

おわりに

私は自動化厨なので1日に何回もやる作業があればすぐツールを作ります。花陽やことりもそういったツールなので機会があればご紹介したいと思います。
また、弊社では効率化ツールを9人まで増やしてくれるラブライバーを募集しています。
興味がある方は是非ラブライブの話をしに来て下さい。

ラブアローシュート！

「お父さん - お母さん + チューハイ = ビール！？」word2vecで女性向けQ＆Aサイトを解析してみた

こんにちは！

CTOの島田(@tatsushim)です。 前回のブログでは「データドリブン」開発手法について触れさせていただきました。
今回はIVS CTO Night & Dayで発表させていただいた内容についてご紹介したいと思います。
IVS CTO Night & Dayは、CTO及び技術責任者のためカンファレンスです。
GREE CTO 藤本さんのKeynoteに始まり、様々な技術責任者の方とディスカッションさせていただく濃い3日間でした。
非常に学びが多かったです。運営の皆様有難う御座いました。
初日にLTをする機会をいただきましたので、word2vecについて発表させていただきました。

こちらの発表内容について解説していきます。

そもそもword2vecとは？

ざっくり言うと、単語同士の関係性をベクトルとして表現し、そのベクトルを利用して類似度の計算や足し引きを可能にしたものです。 テキストだとちょっとイメージしにくいので具体的な例で見ていきましょう。

こちらの例ではFrance - Paris + Tokyo = Japanになるそうです。 直感的には理解できても、なんとなく不思議ですね。ちょっと整理してみましょう。

「France - Paris」の部分は「ある都市を首都とする国」を表しています。 そこに首都を足してみます。今回は「Tokyo」です。
その結果、 東京を首都とする国、つまり「Japan」が導き出されます。
このような単語同士のたし引きを可能にしたのがword2vecです。

ママリQでword2vecしてみる

ママリサービスは日本で妊娠・出産で悩む人の5,6人に1人が月1アクセスする、社会的にもインパクトのあるサイトになってきました。
ママリQにはたくさんの質問と回答のテキストが存在しています。
女性向けコミュニティサイトで飛び交っている会話を対象にやってみたら、どんな結果が出るでしょうか？
word2vecに使ってみて出た面白い結果を3つ程ご紹介したいと思います。

1. 公立 - 息子 + 娘 = 私立

• 女の子の方が学校を選ぶ際に私立の可能性を検討するのでしょうか？

2. お父さん - お母さん + チューハイ = ビール

• お父さんはやっぱりビール好きなんですね。
• ちなみに私はウーロン茶をロックで飲みます。

3. 可愛い - 息子 + 娘 = 可愛い

• 息子さんでも娘さんでも結局可愛いんですね。

word2vecをプロダクトにどう活かしていくか？

一般的には類義語検出に使用することができます。
今後社内では質問の中で最も良い回答を抽出したり、ママリQ内のコミュニティにおいて、適切な質問者と回答者をマッチングするエンジンの開発に利用したいと考えています。
最近はCategory2Vecなど、派生した研究も出ていて非常に興味深いです。またこちらのブログで関連研究も取り上げさせていただくかもしれません。
word2vecに限らず、新しい技術にドンドンチャレンジし、ユーザーのために技術力を高めていく過程をこちらのブログで発信していきます。

参考リンク

word2vec - Tool for computing continuous distributed representations of words

お知らせ

word2vec等も含め、技術力を高め合いながら社会にインパクトを与えたいエンジニアを募集しています。
まずはランチなどご一緒しながらカジュアルにお話させてください。

「なんとなく」でサービス開発をしてませんか？ 急成長中のスタートアップ３社が語る「データドリブン」開発手法レポート！

はじめまして。Connehito CTOの島田(@tatsushim)と申します。 弊社でも開発者ブログを通じて、ユーザーのために使用している技術や開発手法等についてご紹介させていただくことになりました。 今後ともよろしくお願いします！
さて、早速ですが先日「データドリブン勉強会」という勉強会を開催させていただきました。 元々30名での開催予定だったのですが、予想を超える申込数があり、最終的には80名の方々に応募いただきました。 抽選で漏れてしまった方々もいらっしゃいましたので、こちらにレポートをまとめて少しでも当日の内容を共有できればと思います。

イベントの内容

ユーザーファーストをどう実現してる？データドリブンで急成長中のスタートアップ3社が語る開発手法

「データドリブン勉強会」とは、データドリブンで行うサービス開発についてのエンジニア向け勉強会です。
「自分自身が、開発しているサービスのターゲットユーザーでない」という3社のトップエンジニアの方々に開発手法の話を聞きながら、より良いユーザーファーストの実現方法を探りました。

タイムスケジュール

発表者	内容
開場	受付
荒川千華（フリーランス）	開演の挨拶
島田達朗（Connehito株式会社 CTO）	独身男性のためのデータドリブン講座
米山諒 (株式会社 LiB 開発担当取締役)	1 → 10 を創る開発基盤
今村雅幸（株式会社 VASILY CTO）	BigQueryを用いたデータ活用基盤の紹介
堀内康弘 (株式会社 LiB 非常勤取締役 社外CTO), 島田達朗, 今村雅幸, 米山諒	パネルディスカッション
懇親会	軽食とアルコールをご用意いたします

各社のプレゼンテーション

1. 独身男性のためのデータドリブン講座

Connehito, Inc CTO 島田達朗 (@tatsushim)

まだまだ荒削りなのですが、男性である私をはじめとする開発チームがどのように妊娠・出産・子育てに疑問を持つ女性向けのサービスを開発しているかをご紹介させていただきました。 ざっくり言うと以下の3つの要点に絞れるかなと思います。

• 振り返りをしないと自分たちが行った施策が良かったのか悪かったのかわからない
• デプロイしっぱなしではなく、振り返りができる仕組みを持とう
• 弊社ではGithub上に「Review」という振り返り専用のリポジトリを運用し、そこで振り返りを行うようにしている

2. 1 → 10 を創る開発基盤

LiB, Inc 開発担当取締役 米山諒 (@yuliiさん)

Lib 開発担当取締役の米山さんによる発表です。

• Security上外部に出せないものもあるのでトラッキングツールは内製
• A/B Testはcookpad製のchankoを利用している
• 早く飛ぶなら銀でも金でも普通の弾丸でも良い。とにかくデプロイ回数(トライの数)が大事。

3. BigQueryを用いたデータ活用基盤の紹介

VASILY, Inc CTO (@kyunsさん)

今回会場提供をしていただきました、株式会社 VASILY CTOの今村さんによる発表です。
※ 当日のプレゼンテーションはアップロード予定がないとのことでしたので、当日の発表内容と似た発表資料をここでご紹介させていただきます。

• Localyticsでアプリの全行動データをS3へアップ
• その全行動データをBigQueryに入れてるから見たいデータをいつでも高速で集計可能
• BigQueryは安い。iQONの規模で月に1万円いかない（すごい）

パネルディスカッション (モデレーター Gumi元CTO 堀内さん)

堀内さんの手慣れた進行でデータドリブンに関係するトピックは進み、非常に学ぶことが多かったパネルディスカッションになりました。 例えば、「企画のPDCAの回し方について」というトピックについては以下のようなお話が挙がりました。

企画のPDCAの回し方について

堀内 : 実際どういう風なチームで、どんなツールを使って施策を実行しますか？

今村 : 僕らの場合は何か企画だったり施策を行うときは、必ずハッカー、ハスラー、デザイナーのトライアングルを組むようにしています。これが「どういうチームで」という部分に対応しますね。その3人で話し合って、一緒に企画を出す感じです。実行するときに使うツールとしては、Trelloを使っています。 情報共有はQiitaチームを使っています。誰がやるのか、どうやるのか、結果どういうことが予測されるのか、結果どうだったのかみたいのを一枚にまとめる感じですね。スケジュールがかなり細かく切れるものはBacklogにまとめています。

堀内 : その企画のキックって誰がやるんですか？

今村 : キックは僕だったり社長自身だったりというところですね。あとは日々アプリの改善をやっているチームがいるので、主にそこから社内に日々上がってくる改善プランっていうのを全部集めて、優先度をつけて、「これやろう」って決める感じですね。

堀内 : 米山さんお願いします。

米山 : ウチは僕とかが（企画を）作ったりとか、あとはマーケ担当しているメンバーがあれやりたい、これやりたいみたいなのを出してきたりだとか。場合によってはエンジニアやデザイナー自身からも「こういうUIの方が良いんじゃないか」とかタスクを挙げてもらったりして、実施してる感じです。実施に関しては、僕がエンジニアなところもあってですね、あっちこっちツールを使うと管理が面倒になるので、なるべくGithubに集約しています。やっている施策は基本A/Bテストを回すことですね。フォームの順番並べ替えたりとか、色を変えたりとか。そういうのをchankoを使いながらグルグルPDCA回してます。Aというオリジナル、現在動いているものがあって、Bというパターンで新しい施策を行う際に、chankoが便利なのは、Bの方でプログラムのエラーが発生してると、勝手にそれを検知してA（オリジナル）を表示してくれるので、試そうと思ってるものが動かなくても、サービスへの影響はないので結構ライトに実験できるんです。なので、どんどんデプロイしちゃおうよという感じで施策を回しています。

堀内 : 有難うございます。島田さんのところはどうでしょうか？

島田 : はい、まずどういう風はチームでという部分ですが、まだ私達のチームは規模が小さくてですね、社員が5名で、社長を除く残りの4名がエンジニア・デザイナーというチームで開発しています。それで全員サービスに対して意見を出していく形ですね。ツールについてですが、個別のissue管理は米山さんと同じくいろんなツールを使わずGithubに集約しています。あと、エンジニアのリソースを使わずにA/BテストするためにOptimizely使ったりもしてます。

堀内 : 結構施策をしようとするといろんなところから意見が出てくると思うんですね。それで良さそうなものは全部やりたいけど、すべてはできない。そういうときの優先順位付けってどうされていますか？その辺り工夫してることとかあれば教えてください。

島田 : うちで言えば、優先度順位付けにはGoogle Spreadsheetを使ってます。重要度、タスクの重さ(工数)、それとそれを緊急でやるべきかどうかを入力して、その3つの掛け算を数値に落とします。その数値でソートすれば優先度がひと目でわかるので、その上から潰していくイメージですね。

堀内 : なるほど。それはかなりデータドリブンですね（笑）米山さんはいかがでしょうか？

米山 : うちは、優先順位のジャッジだけは僕が握ってますね。うちは今常駐でエンジニアが6名いまして、他にもマーケターや、もっというと社長が「あれやりたい」とか言い出すと収集がつかなくなるので、ちょっと基本的には「黙っててください」的な感じで（笑）やりながら、僕の方でKPIの中でやっぱり一番ボトルネックになっている部分を中心に優先順位をつけています。優先順位自体はGithubのissueの中でなんとかやろうとしてまして、milestoneで優先順位付けをしながらエンジニア同士で目線が揃うようにしています。

堀内 : 今村さんはいかがでしょうか？

今村 : そうですね、今僕らの会社の規模は50人くらい、エンジニアが20人くらいなんですが、結構社内でものすごい数の企画が走っているんですね。たぶん施策だけでいうと・・・3, 40くらい走っているんですね。それで、Trelloを見ながらユーザーに対してインパクトがあるもの順にやっていく感じでやっていますが・・・わりかしカオスな感じですね（笑）もちろんロードマップを作ってやっていますが、毎日何が起こるかわからないという中なのでわりかし柔軟にその優先順位を変えていますね。

堀内 : なるほどですね。誰かが判断しなければならないタイミングもあると思うので、その際にはここにいらっしゃるCTOの方々等が判断されたりするわけですね。

企画のPDCAの回し方自体にもフィードバックが必要

このパネルディスカッションを通し、組織のフェーズやエンジニアの人数に応じて、それぞれのスタイルがあることを強く感じました。
それらは組織の規模やカルチャーに依存する部分もあるので、数学の公式のような正解はありません。

例えば弊社の規模の場合、社員の大半がエンジニアであり、サービスの仕様にも密に関われる状態です。
結果として、各自がサービスに対して「俺の（私の）サービスだ！自分の手で、人の生活に良い影響を与えている」というオーナーシップをもって開発に取り組む環境を構築できていると思います。

良い環境を構築しつつも、弊社のGoogle Spreadsheet使った優先度順位付けにもまだ課題はあり、 実は勉強会登壇後に社内のエンジニアから挙がった声を反映させ、新たな要素を加えて現在運用を試しています。（上手くいくようでしたらまたこちらでご報告しますね）
組織やサービスの成長と共に、企画から振り返りまでのやり方もダイナミックに成長させていく。
そしてそれが結果的にサービスをより良くするサイクルに結びつくと考えています。

参加者のご意見

• 気になっていた、企画・開発の回し方の具体的な事例が聞けて良かった。
• スタートアップの規模の違いによる、それぞれの取り組み方は参考になる点が多かった。
• 男性ユーザーとの違いにそれぞれの苦労がみえて面白かった。

など様々なご意見いただきました。有難う御座いました。 「 アンケート書くときにテーブルがなかったので、書きにくかった」というご意見もあり、ここは反省点でした・・・。次に活かします！

今後

アンケートから「第2回があれば是非参加したい」というお声をいただきましたので、また違う切り口で発表できるコンテンツがあれば開催したいと思っております。

謝辞

一緒に登壇していただいた、荒川さん、今村さん、米山さん、旅人CTOの堀内さん、会場提供のVASILYさんとスタッフの方々、そして参加して下さった皆さん、まことに有り難うございました。

最後にちょっとだけお知らせ

弊社ではデータドリブンでプロダクトを一緒に開発してくれるエンジニアを募集しています。
まずはランチなどご一緒しながらカジュアルにお話させてください。