はじめに

モダンなフロントエンドの開発サイクルについて考えてみました。
まず、開発サイクルを図にしてみましたので、ご覧ください。

開発サイクルの流れは図で表した順番になります。
この開発サイクルは、ウォーターフォール、アジャイル両方に対応しています。
また、個人開発、チーム開発どちらでも実践可能です。

では、流れをお伝えしたところで、１つ１つ補足していきます。

技術選定

技術選定は、要求・要件にあった技術を選定をする工程です。
図についてですが、インプットが横にあるのは、技術選定をするために要求・要件をインプットする必要があるためです。

実績がない（扱ったことがない）技術に関しては、この工程で技術検証もします。

また、フレームワークの選定もこの工程ですることになりそうです。
開発チームのスキルセットに合わせて、開発者とコミュニケーションを取りながらフレームワークを選定しましょう。

スケルトンの作成

技術選定が終わったら、スケルトンを作成します。
スケルトンとは、プログラムの骨組みのことです。
別の言葉で言い換えると、スキャフォールド（足場）、テンプレートとかになるでしょうか。

スケルトンを作成したら、開発の補助となるツールもインストールすることをお勧めします。
なぜなら、プログラムの品質に関わってくるからです。

具体的な例をあげると

などです。

なども入れるとさらに品質が上がるでしょう。（他にフロントエンドを開発する上で便利なツールがあったら教えてください。）

ツールについての説明は割愛させていただきます（ツールについて知りたい方はリンクを参照してください）が、 Storybook については後ほど出てくるので簡単に説明します。

Storybook は、一言で言ってしまうと、コンポーネントのカタログです。
「アプリケーションにコンポーネントを組み込まなくても」、画面のパーツの見た目、動作を確認することができます。
つまり、開発者は、要求・要件、APIの仕様について知らなくても、コンポーネントの仕様を理解するだけで、画面のパーツを実装することができます。

また、「アプリケーションにコンポーネントを組み込まなくても」ということは、アプリケーションについての理解は必要がなくなります。つまり、開発者の追加があった場合でも、即戦力となることができます。

ツールの導入に関しては、学習コストはかかりますが、この学習コストは品質とトレードオフなのではないでしょうか？

CI/CD の構築

CI/CD の構築は非常に大事です。
生産性をあげることができます。

CI/CD の構築の工程では、アプリケーションのビルド・デプロイと Storybook のビルド・デプロイを自動でするようにします。トリガーは、開発者がレビューを依頼するとき、つまり、プルリクエストを作成したときに CI/CD が走るようにします。
開発者によるアプリケーションおよび、 Storybook を手動でデプロイするコストがなくなり、開発者はより開発に専念することができます。

プログラム設計

モダンフロントエンドの開発では、少なくとも以下のプログラム設計はした方が良いでしょう。

ページ一覧
コンポーネント一覧
状態管理

設計方法は多種多様だと思いますが、１つの例として以下の記事を参考にしてください。

また、プログラム設計を行うメリットについてですが、いくつかあると思います。
まず、思いつくのが、開発チームの意識合わせでしょうか。
開発者は、要求・要件定義書や、ワイヤーフレーム、API仕様書をインプットして、実装方法をイメージします。
プログラム設計をすることによって、この実装方法のイメージの認識を合わせることができます。

もちろん、個人開発の場合でも、メリットはあります。
プログラム設計をすることで、開発者の実装方法が整理されます。
プログラム設計書は、開発する上での地図になるので、実装の誤りや、手戻りなどがなくなります。

それから、実装という大きなタスクの単位を分割することができます。
ページ一覧、コンポーネント一覧、状態管理とプログラム設計したことにより、実装の単位が明確になります。
この実装の単位を１つのタスクとすることにより、開発者の迷う時間をなくすことができます。

コーディング

プログラム設計が終わったら、いよいよコーディングの工程に入ります。
コーディングは、基本的にプログラマーが行います。
プログラマーは、情報をインプットし、要件を満たすように実装します。

この工程で重要なのは、品質の担保です。
コーディングはプログラマーの数だけ、プログラムの書き方があります。
品質を担保するには、チーム内で実装の差異を少なくすることです。
なので、コーディング中のソースコードは常にチームが見れることが大事です。

Git Hub にはドラフトプルリクエストという、コーディング中のソースコードを共有する仕組みがあります。
差異を少なくするためには、この仕組みを利用して、プログラマー同士でコミュニケーションをする必要があります。

Unit テスト

プログラマーが、コーディングを完了したら、動作確認つまり、Unit テストをする必要があります。
画面の実装をしたのであれば、 Storybook で動作確認を行い、状態管理の実装をしたのであれば、テストコードを実装しましょう。

プルリクエスト

プログラマーは、Unit テストをパスしたら、プルリクエストを作成します。

CI/CD の構築の工程で、プルリクエストが作成されたら、アプリケーションおよび、 Storybook のビルド・デプロイを自動でするように設定しました。

プログラマーは、デプロイされたアプリケーションと Storybook の URL をプルリクエストに記載します。（この作業も自動化すると、なお良いでしょう。）

さらに、デプロイされたアプリケーションは成果物となります。つまり、プルリクエストが作成されると、成果物が生成されます。URL を共有することによって、フィードバックを短いスパンで受けることができます。

レビュー

レビュアーは、デプロイされたアプリケーションまたは、 Storybook で動作確認を行います。
問題なければ、レビュアーはプルリクエストを承認し、プルリクエスト作成者にマージをお願いしましょう。

Integration テスト

Integration テストはなぜか軽視されがちな印象があります。
Integration テスト仕様書は、要求・要件定義書や、ワイヤーフレームを作成した開発者に作成を依頼しましょう。

インプット

ここまでは、開発の工程について説明しました。ここでは、インプットについて説明します。

以下の工程を行うためには、情報のインプットが必要になります。

技術選定
プログラム設計
コーディング
レビュー

情報というのは、要求・要件定義書、ワイヤーフレームなどになります。

アウトプット

アウトプットは、アプリケーション、 Storybook になります。

おわりに

次回は、プログラム設計からレビューまでの回し方について考えてみたいと思います。
図のベージュの部分です。