フロントエンドエンジニアから見たアジャイル開発

アジャイル開発を導入してから、2つのプロダクトをリリースしました。
今回は、実際に体験した所感をフロントエンジニアの視点でまとめてみたいと思います。

アジャイル開発とは？

アジャイル開発は開発手法の1つとなります。
アジャイルとは、「素早い」「機敏な」という意味を持ちます。
小単位で実装とテストを繰り返していくことで、それまでの主流であったウォーターフォール型開発に比べて、開発期間を短縮することができます。
そのため、ウォーターフォール型開発に代わる新たな手法としてアジャイル開発が注目されています。

ウォーターフォール型開発

ウォーターフォール型開発では、機能全体で大きく「計画＞設計＞実装＞テスト」を行います。
納品や公開日時にスコープして開発することが多いです。

メリット

スケジュールが立てやすく、進捗状況も明確となるため、プロジェクト全体の進捗の管理がしやすい。

デメリット

1つ1つの工程を漏れなく終わらせる必要があるため、仕様の変更やに弱く、後戻りがし辛い開発と言われる。
要件や仕様に変更などが出た場合には、後の工程への影響が大きい。

向いているプロジェクト

• 規模が大きいプロジェクト
• 品質を重視するプロジェクト

アジャイル開発

「アジャイル開発」を行う手法の中でも、今回は「スクラム」を採用しました。
スクラムではスプリントと呼ばれる「計画＞設計＞実装＞テスト」を1～4週間のサイクルと設定し、リリースを繰り返し行います。
作っている機能に関して定期的に確認を行うため、チームのコミュニケーションが重要となります。

メリット

開発するプロダクトに必要な機能を優先順位ごとに並べかえ、その順番で開発していく。
最小単位での開発を行うため、早い段階で「動くもの」を公開・テストできる。
短期間でサービスを公開することができ、開発段階でも顧客のニーズを取り入れたブラッシュアップが行える。

デメリット

常に改修を繰り返すため、方向性がブレやすくなる。
全体像を把握しにくく、スケジュール管理が難しい。

向いているプロジェクト

• いち早くサービスインしたいプロジェクト
• 要件の全体像が未確定なプロジェクト
• 開発中で仕様の変更や新しい機能が追加される可能性の高いプロジェクト

スプリントでの開発の進め方

新サービスや新機能を開発する際の進め方をご紹介します。

開発には大きく、3つの役割があります。

• プロダクトオーナー(プロダクトマネージャー)
• デザイナー
• エンジニア(フロントエンド/バックエンド)

(※チームとしては他にもありますが、今回の話に主に関わる役割をあげています)

大まかな開発のフローは、上記のようになります。
アジャイル開発では、この図の1つめ「プロダクトオーナーが方向性を決める」から6つめ「レビュー」までを1つのスプリント内に行い繰り返して回していくことが重要です。
携わった案件では、1週間（5営業日）を1スプリントとし、5日目はレビュー＆リリース日としていました。
リリースが完了すれば、次のスプリントのプランニングを行ったのち、スプリント開始・・と、繰り返していきます。

尚、スプリントのはじめにプランニングを行いますが、そのスプリント内で予定されている機能が完成できなくても、スプリントは延長されません。 定められた期間内で、開発チームはスプリントバックログの開発に集中します。

はじめてのスプリント開発をして感じたストレス

スプリント期間内に設計からリリースまでを行う

1スプリントの期間を1週間と定めましたが、実際にスプリントでの開発をやってみると1週間は短く、この開発期間に慣れるまでが大変でした。
各役割で適切なタイミングで、メンバーそれぞれが適切に動く必要があるため、スプリント開始時にしっかりとすり合わせて計画を立てる必要があります。

計画と工数の分解でつまずく

1スプリントにこなせる作業の最適工数が分かりませんでした。
どのレベルの機能を何日で作ることが出来る、何スプリントあればリリースできるのかは、開発内容と工数毎に管理して少しずつ掴んでいきました。
また、大きな機能を実装する場合には、「いつその機能をリリースするのか、必要なのか」「そのためには何スプリントで作業を分けるのか」を考える必要があります。
無理なスケジュールを立ててしまうと、スプリント内に収まらない、収めるために無理をする、チェックが甘くバグが見つかるなどが起こります。

• 「あれ？このスプリントでここまで公開予定なのに、この作業がまだ終わってないやん」（テスト不可）
• 「あれ？この数値ってバックエンドで計算するの？フロントエンドで計算するの？」（設計・共有漏れ）
• 「あれ？バグってる？直してるとスプリントレビューに間に合わない」（次スプリントに作業が跨る）

開発～レビューでつまずく

短期間で開発を行うためには、待ち時間は極力なくしたいです
そのために、作業を分けて行う必要も出てくるのですが、計画時に漏れがあるとレビューが行えずスプリントの意味をなさなくなってきます。
リリースを行って常にPDCAを回すこともアジャイルの目的の1つです。そのため、レビュー時に「画面上で見せられるもの」を用意することも大切です。

• 「あれ？今スプリントの予定作業が終わったはずなのに、レビューに出せる形のものはない」（プロダクトオーナー・ステークホルダーにアピールできるものがない）

ストレスを軽減するために行ったフロントエンド的な工夫

慣れないスプリント内で、短時間に手早く開発を進めるため、フロントエンドエンジニアとして下記を行ってみました。

フロントエンドとバックエンドの分離

開発をしていると機能の追加、修正は多々発生します。
アジャイル開発をするうえでもそれは変わらず、スプリント毎にPDCAを回すためスプリント単位で見た目が変わることもあります。
HTMLとデータの結合は頭を悩ませる問題であり、データ1つ変わった時点で「データ修正のための工数（バックエンド）」「データを出力するHTMLの修正工数（フロントエンド）」が発生します。

ここで発生する工数を削減するために、WebAPIを用いてバックエンドとフロントエンドを分けた開発を行いました。
データの作成と出力を分離することで、発生した変更や修正が影響を及ぼす範囲が少なくなります。
開発を行うにあたっては、APIの開発が終わらなくてもフロントエンドからテストができるように、ダミーデータを返すAPIサーバーを用意しました。

1. バックエンドの開発を行っている時点では、フロントエンドはダミーデータで出力を用意。
2. バックエンドのAPIが完成したら、ダミーから本データのAPIにつなぎ先を変更する。

これにより、フロントエンドとバックエンドが並行で開発を行うことが出来ます。

フロントエンドとバックエンドを分ける利点

• データの再利用性が高まる
• フロントエンドとバックエンドを並行で（別チームで）開発できる
• フロントエンドとバックエンドがそれぞれリリースでき、リリースが簡単になる

共通デザインは、パーツごとに管理

PLAN-Bでは、「デザイナー」と「フロントエンドエンジニア」として職域が分かれています。
デザインをサイトへ反映するのでデザイナーではなく、フロントエンドエンジニアの担当となります。
デザイナー⇒フロントエンドエンジニアの作業伝達を早めるために、デザイン時にルールを定めさせてもらい、HTML/CSS作成時にもそのルールに沿って作成を行いました。

クラス指定の一例）

• ボタンは四角形をベースとする・・・class=”c-btn”
• 色を変えたい場合には色に応じたクラスを振る・・・緑ならば　 class=”c-btn　c-btn__green”
• ボタンが機能を表す場合には、その機能をクラスに振る・・・矢印なら　 class=”c-btn　c-btn__arrow” のクラスを付与

上記のように、ルールを定めて共通認識を持っておくことで「こういう意味合いのパーツは、このルールを使う」という約束事が出来ます。

そのため、キッチリとしたデザインがなくとも、「どこに」「どのような意味合いの要素が」「どの組み合わせで使うのか」ルールに沿ったclassを用意しておけば、デザイナーのデザイン工数も、フロントエンドエンジニアのコーディング時間も短縮することが出来ます。

また、ルールをシンプルにすることで、フロントエンドエンジニアだけでなく、バックエンドエンジニアでも一定のクオリティを保ち要素の追加を行うことが出来ます。

自分の役割以外の作業にも首を突っ込んで進捗確認

MTGでは各役割が、「いつまでに」「どの段階まで」作業するのかを確認することを徹底しました。
それにより、自分の作業に影響するものであれば、手持ちの作業を前後させるなどして調整を行うことが出来ます。
問題が起こって開発がストップしているものがあれば、POを交えて相談し、早い段階でスプリントから落とす（機能実装を次にずらす／開発自体を見直す）ことも提案しました。

スプリントをスムーズに進めるためのポイントまとめ

まだまだ、スプリントをスムーズに進めるためには、見直す必要のあることも多いですが、アジャイル開発が少しずつ形になってきました。
最後にここまでで上げたポイントも含めて、「ここに気を付けたらスムーズにアジャイル開発できた」をまとめます。

スプリント計画時点で、ある程度のすり合わせを完了させる

• 打ち合わせながら見た目や配置などデザインのラフを作成してその場で共有
• 調査が必要なものや、不確定要素は早めにアラートを出す
• 工数が必要な作業はスプリント計画に入れる

仕様の決定には、じっくり時間を作り手を抜かない

• スプリントで達成しなければいけないのはどの機能かを開発に入る前にしっかりとすり合わせる
• スプリント内では完了できない大きさの作業はスプリントを跨いで分割を行う
• スプリントで計画したこと“以外”は、スプリント内で行わない

機能はしっかりと最適に分解し、スプリントで達成可能な範囲におさめる

• 遅れや問題が起こればすぐにアラートを出す

誰が、どのタイミングで何をするか、コミュニケーションを行う

• 開発時にも席を近くに置くなどして、それぞれの作業の相談など連携をとれる状態をつくる

工数を減らす工夫

• デザインの共通化、フロントエンドでもHTMLを配置できる工夫を行う

アジャイル開発を行ってリリースしたサービス

本当に必要な機能だけを集めたSEOツール「SEARCH WRITE（サーチライト）」

https://searchwrite.jp/

新時代インフルエンサーマーケティングプラットフォーム「Cast Me!（キャストミー）」

https://service.boujee.jp/