※なべはるさん、谷垣さんはフィードフォースを卒業されました

こんにちは、人事のなべはる（id:nabeharuj）です。
先日、きりみんさん（id:kirimin）の下記ブログを読んで感銘を受け、筆をとりました。

特になるほど！と思ったのが下記です。

それってまさにフィードフォースのことだ！と感じたので、きりみんさんの記事にしたがって、優秀なマネージャーと開発体制がそろっていることをアピールしたいと思います。

優秀なエンジニアが足りてない（いないとは言ってない）

本題に入る前に。
手前みそながら、フィードフォースには優秀なエンジニアが多数在籍をしていると思っています。
ただ、既存事業の成長や新規事業への挑戦など、会社としてやりたいことに対して充分な人員がそろっているとは言えず、きりみんさんの記事どおり「優秀なエンジニアが足りていない」状況です。
また、いわゆるエンジニア界隈での有名人的な知名度の高いエンジニアは在籍していません。そういったスターエンジニアが在籍している企業と比較すると、採用競争においては不利といえます。

そんなフィードフォースですが、「ポテンシャルのあるプロダクトがあるか」「優秀なマネージャーが在籍していて、きちんとプロダクトの開発フローが上手くいっているか」についてはアピールできるし、アピールすべきだ！と感じたのでそれらについて紹介していきます。

堅実な成長を続け、大きく伸びるポテンシャルを秘めたプロダクト

フィードフォースでは、5つの主要なプロダクトがあります。ここではそのうちの1つ「dfplus.io」をご紹介します。
dfplus.io は、企業のマーケティング担当者・広告担当者がカンタンにデータフィードを運用できるようにするためのサービスです。

2016年12月にリリースされた dfplus.io の直近1年の売上推移は下記のとおり。
まだまだ売上総額は大きくないですが、積み上げ型のビジネスモデルで堅実に売上・利用企業数を伸ばしています。

B2Bで、かつマーケター向けサービスなのでエンジニアからの知名度はゼロですが、上記のように着実に成長しており、これから大きく成長するポテンシャルを秘めています。

サービスサイトには導入事例の紹介も多数紹介されており、「Excel での管理から解放されて作業時間が1/10に、広告運用の改善施策の実行回数が5倍以上になった」という嬉しい声もいただいています。

アジャイル＆スクラムをベースにした開発プロセス

そんな dfplus.io の現在の開発チーム構成は下記のとおり。

開発プロセスは、いわゆるアジャイル＆スクラム開発をベースに進めています。

1スプリントの時間配分と役割分担はざっくり下記のとおりです。

開発プロセスとしては上記のとおり一般的なやり方を踏襲していますが、一般的なやり方を踏襲すればうまくいくわけではないのがチーム開発の難しいところ。
ここでは、チーム開発するうえで特に気をつけている・工夫しているポイントを4つ紹介します。

メインタスクは3ヵ月に1つ

サービス開発をしていると、ついついあれも作りたいこれも作りたい…とやりたいことがあふれてきますが、リソースが限られている以上すべてを作るわけにはいきません。
いろいろなことに手を広げた結果、顧客に提供する価値がぼやけてしまっては元も子もないので、 「いまいちばん顧客に提供すべき価値は何か？」 から逆算したメインタスクを1つ定め、原則としてその開発に集中するようにしています。
開発に3ヵ月以上かかる場合は、「3ヵ月でどこまでできていればいいか」と要件を分解することで、「この3ヵ月はこれをやる」と集中できる状態にしています。

定めたメインタスクの実現を最優先にしつつ、UI改善や既存機能の改善タスクを少量混ぜ込んでいき、最終的な四半期の開発内容が決まっていきます。

決める人が決まっている・なぜそう決めたかを説明する

企画・要件定義のフェーズではプロダクトマネージャーとデザイナー・エンジニアが議論しながら要件（実現したいユーザーストーリー）をつくっていきます。
真剣に議論した結果、意見が割れたり全員の意見を反映させるのは難しいことは当然あります。
そうしたときに、「決める人が決まっていること」 と 「なぜそう決めたかを説明すること」 が重要なポイントです。
dfplus.ioチームの場合は、「決める人」はプロダクトマネージャーの谷垣（通称がっきー）。谷垣が最終的な決断をして、その決断理由をメンバーに説明しています。

dfplus.io プロダクトマネージャー 谷垣（がっきー）

先日、dfplus.ioチームの開発体制について Slack で話題になったとき、チームメンバーから下記の発言がありました。開発チームメンバーとプロダクトマネージャーとの信頼関係がみてとれますね。

（"さすガッキー"のスタンプとか、メンバーとの関係性がにじみ出てます）

メンバー間の情報の非対称性をなくす

dfplus.ioチームでは、プランニングにすべてのエンジニアが参加して議論しています。
プランニングにも全員参加することで情報の非対称性をなくし、結果的に開発スピードが早くなっているようです。また、プランニングの内容は必ずドキュメントに残し、参加できなかったメンバーや後から見返す際に齟齬がないようにしています。
ただ、このやり方はエンジニアが6名と少数のチームだからこそワークしていることで、今後メンバーが増えたら最適なやり方は変わるかもしれません。

スプリントごとにふりかえり・カイゼン

上記のような取組みは、チーム発足当初からできていたわけではありません。
チームが立ち上がってから現在まで約3年の間、「要件の考慮漏れや甘い見積もりが原因のリリース延期」「実装者への要件伝達がうまくいかずに手戻りが頻発」「プロダクトマネージャーがふんわり要件のままプランニングに臨んで総ツッコミされる」などなど、いろいろな問題が発生していました。
そういった問題を、毎週のふりかえりKPTでチームの課題として共有し、少しずつカイゼンを行った結果いまのチームがあります。
現在のチームには認定スクラムマスターの資格を持ったメンバー（ロールはスクラムマスターではなくエンジニア）がいるので、ふりかえり手法自体も日々カイゼンしながら取り組んでいます。
また、発生した問題はチームの課題であって特定の個人を責めることはしない、という風土も課題解決・カイゼンを促進しています。

以上、dfplus.ioチームの開発体制についてまとめてみました。
今回はきりみんさんの記事を読んで脊髄反射でババっとまとめましたが、こうして言語化してみるとチームの個性と試行錯誤の積み重ねで今のやり方があることが分かり、とても興味深かったです。
プロダクトマネージャーとエンジニアがどう信頼関係を築いたのか？とか、企画と開発を並列ってどうやってるの？とか、書きたいことはまだまだたくさんありますが、きりがないので今日はこのあたりにしておきます。

▼一緒に「働く」を豊かにする仲間を募集しています▼