Webエンジニアとして働くうえで、「どんな開発体制か」はとても重要ですよね。開発手法・チーム構成・チームのスタンスなどによって、働き方は大きく変わります。

そこでこの記事では、フィードフォースが提供するプロダクトのひとつ「dfplus.io」の開発体制を、PdMに聞いてみました。

スクラム開発をベースにした週次開発サイクル

――さっそくですが、開発チーム構成を教えてください。

Yang　2023年2月現在で、下記のチーム構成になっています。

――このチームがどのように開発を進めているか教えてください。

Yang　スクラム開発をベースに、1週間を1スプリントとして開発サイクルをまわしています。ただ、スクラム開発をチームに合わせて解釈・アレンジしている部分も多くありますので、スクラム開発そのものというよりは、スクラム開発のエッセンスを取り入れた dfplus.io 流の開発スタイルですね。

1週間のチームイベントは以下のとおりです。

それぞれのイベントについて、紹介しますね。

朝会（デイリースクラム）

毎日の朝会では、チームイベントの確認と開発ストーリーの優先度確認を行います。
1週間の開発ゴールを達成できそうかの感触をファイブフィンガーで測り、障害や不安があれば早期に発見する場です。

Progress Review（事業部全体共有）

月曜には、ビジネスサイドも含めた事業部全体で共有会を行っています。
ビジネスサイドからは売上や契約状況を、開発サイドからは開発の進捗を共有する場です。

ビジネスサイドにとっては、開発の状況を把握しておいたほうが精度の高いプレスリリースを出せたり、開発途中の機能を商談でスムーズに説明できるようになります。
開発サイドにとっても、自分たちのつくっているプロダクトがどんなお客さまに使われているのか。売上利益になっているかを知ることは重要だと考えています。

プランニング

週の半ばには、どのような機能をどのようなUX/UIで提供するかを議論するプランニングを行っています。

プランニングにはすべてのエンジニアとデザイナーが参加しており、開発状況によっては、週に2度プランニングを設けることもあります。

ふりかえりKPT

金曜日のふりかえりKPTで、その週の開発ゴールを達成できたかを確認し、Keep・Problem・Tryを書きだします。

KPTを行うことで、その週の学びやカイゼン点を共有し、翌週のスプリントに活かせるようにしています。

大事にしているのは、開発メンバーの「腹落ち感」

――1週間のサイクル・チームイベントを設計するうえで気をつけていることはありますか？

Yang　まず大事にしているのが、メンバー全員がプロダクトとチームについて共通の認識を持つこと。そして、メンバーが腹落ちして開発できることです。

開発メンバーが意思決定の場に参加せずに、「なんか知らないけど目標を決められた」「なんだかよくわからないけどこの機能をつくることになった」という状態ではなかなかモチベーションが上がらないでしょう。

特に、私たちが開発している dfplus.io は BtoB のプロダクトです。ふだん自分たちが使うわけではありませんから、プロダクトを自分ごととしてとらえづらいと思うんです。
ですので、メンバーが納得感・腹落ち感を持って働けるよう、対話・コミュニケーションを大事にしています。

チームの課題を個人のせいにせず、人任せにもしない

――他にチームの特徴はありますか？

Yang　開発の進捗を阻害するものはチームの課題として共有し、解決するスタンスになっています。

例えばある週にAさんの開発進捗が悪かったとしても、Aさんを責めることはありません。また、「それはAさんの問題だから」と解決を人任せにもしません。Aさんの課題をチームの課題としてとらえ、チームで解決策を考える習慣がついています。

――そのような課題は、どのように見つかり、解決されるんですか？

Yang　毎朝の朝会で課題が共有されたり、金曜に行われるふりかえりKPTのP（Problem）として挙げられることもあります。

チーム内には認定スクラムマスターもいるので、アジャイル・スクラムのエッセンスである「細かくふりかえってカイゼンを行う」ことがチームで浸透しています。アジャイルソフトウェア開発宣言は、チームのDNAになっていますね。

より強いチームにするために、トラックナンバー問題を解決したい

――開発チームの特徴がよくわかりました。最後に、チームの課題はありますか？

Yang　属人性が高いことですね。いわゆるトラックナンバー問題があると思います。

Yang　ここ数年、退職するメンバーも少なく、同じメンバーで開発をつづけてきたために発生している課題です。
ノウハウが個人に閉じてしまっていたり、暗黙のルール的なものが生まれてしまっていたり。あとは単純にリソースが不足していたりと、いくつかの理由が重なって、属人性が高くなってしまっています。

――トラックナンバー問題は、どう解決するつもりなのでしょうか？

Yang　ひとつは王道ですが、ドキュメントを整備して暗黙のルールをなくすことです。
数年間退職者が出ず、業務の引継ぎ資料を用意する必要性がなかったこともあり、ドキュメント化があまりされていなかったんですよね。これではいけないと思い、少しずつドキュメント化を進めています。

もうひとつが、チームの不得意領域の底上げですね。下記が、チームメンバーのスキル合計を簡易的に表したものです。

――デザイン・フロントエンド領域がヘコんでいるように見えます。

Yang　そうなんです。なかでもフロントエンド領域の強化が開発チームとしての大きな課題です。
この課題を解決するために、これまでバックエンド開発を担っていたメンバーが、フロントエンド領域の技術を習得して領域横断的に開発できるよう進めています。

ですが、それでもまだまだ足りないので、中途採用でフロントエンドエンジニアを募集中です。
コミュニケーションを大事にしたチーム開発を行いたい方にはとても良い環境だと思います。ぜひ、ご応募お待ちしています！

――お話ありがとうございました。少しでも興味を持たれた方は、下記リンクをぜひお読みください。

※2023年3月追記：おかげさまで、下記ポジション充足しました！！