こちらの記事は、カケハシ Advent Calendar 2022の22日目の記事になります。

こんにちは。KAKEHASHIでおくすり連絡帳 Pocket Musubi というサービスを開発している牧野です。

この記事では、アジャイルに開発をする中で、リリースまでに数ヶ月を要するプロジェクトを進める場合に意識していることについて書かせていただきます。

小さく完了していく

アジャイル開発を経験したことがあれば アジャイルソフトウェアの12の原則 を読んだことがある人は多いかと思います。

その中で

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
動くソフトウェアこそが進捗の最も重要な尺度です。

という文章があります。

長期のプロジェクトについても、上記のような「価値のあるソフトウェア」を「短い時間間隔」で「動くソフトウェアとして提供する」こと、つまり小さく完了していくことがアジャイルの原則として重要なものなのではないでしょうか。

以下では、数週間の短いサイクルで収まらないプロジェクトにおいて、プロジェクトを小さく完了していく上で取り組んできたことを紹介させていただきます。

短いサイクルで完了でき、かつユーザにとっての価値の単位でユーザーストーリーを作成する

先程紹介したアジャイルソフトウェアの原則の中に

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します

という文章がありました。

長期のプロジェクトを運用する際も、開発対象をいくつものチケットに分けることが多いと思いますが、顧客にとって何かしら価値のある単位でユーザーストーリーを作成するのが望ましいと考えています。

顧客にとっての価値をユーザーストーリーに落とし込むことで、何を達成すればチケットを完了できるのかがわかりやすく、ユーザーストーリー毎にフィードバックを得やすい、といったメリットがあります。

ユーザーストーリーの単位については1~2週間などで完了できるサイズにすることで見積もりやすく、また短いサイクルでフィードバックを得られるため、手戻りや変更に対するリスクを小さくできるかと思います。

エンドツーエンドで対応を完了させていく

ここでいうエンドツーエンドというのは「そのユーザーストーリーの達成に必要なすべての作業」のことです。
例えばモバイルアプリの機能を作っている場合であれば、1スプリントなど特定のタイムボックスの中で、アプリのフロントエンドの実装、バックエンドのAPIの実装の両方が完了するように進めることを指しています。

エンドツーエンドで完了させていくことで、以下のようなメリットがあると考えています。

• 進捗が明確になる動くソフトウェアができて初めて必要な作業が完了していることがわかる
  完了しているものが積み上がることで進捗が見える
  
• 開発チームの認知不可が減る終わっていないものは完了するまで管理が必要
  「この機能の実装ってどういう状態だっけ」みたいな会話が減る
  
• 開発チームとして終わらすべきものに集中しやすくなる皆が別々の作業を進めるのではなく、特定のユーザーストーリーを終わらすことにフォーカスできる
  

エンドツーエンドで対応を完了させるための前提として、開発チームがある程度職能横断型であることが望ましいと考えています。
というのも、ユーザーストーリーの完了に必要な作業の量は、フロントエンドやバックエンドなどの各領域で常に一定ではないからです。

過去にトライしていた方法では、例えばフロントエンドのエンジニアリソースが足りていない場合であれば、

• フロントエンドのタスク完了に必要な作業を細かく分解する例えばプルリクエストとして提出できる単位など
  
• 細かく分けた作業をその領域を専門としてる人しかできない作業
  その領域を専門としてない人でもできる作業
  に分類する
  
• バックエンドのエンジニアが後者の作業を実施する

というようなことを行い、チームとしてユーザーストーリーを完了することにフォーカスするような取り組みを行いました。

もちろんメンバーによって得意・不得意や好き・嫌いもあるのでそのあたりの意志を尊重しつつ、そもそもそういったやり方で進めるのかを含めチームで決めていけるのが良いとは思います。

各ユーザーストーリーの実装が終わったらQAを実施する

多くの開発チームでは、開発プロセスの中にQAが存在すると思います。
ただしライフサイクルが長いプロジェクトだと、ウォーターフォールでの開発のように実装がすべて終わった段階で初めてQAを行うプロジェクトも多いのではないでしょうか。

ユーザーストーリーが完了できたかどうかは、正しく動くことを確認できて判断可能になると思うので、QAについてもユーザーストーリーの完了条件に含めたほうがよいのではと考えています。

特にプロジェクト後半にまとめてQAをに行う場合、仕様漏れや不具合発生に対するリスクが非常に大きくなります。

重要度が高いユーザーストーリーからQAを含めて完了していくようにした場合、仮にそのユーザーストーリーで多くの不具合や仕様漏れが見つかり、想定以上に時間がかかったとしても、以降の開発物のスコープ調整をして予定通りにリリースするなどの調整がしやすくなります。

ユーザーストーリーごとのQAにどの程度リソースを使い品質を担保するのかはチーム毎に様々だと思いますが、不確実性を減らす意味でもQAも短いサイクルで行えるほうが良いのではないでしょうか。

終わりに

長期のプロジェクトを小さく完了していくという観点でいくつか紹介をさせていただきました。
皆さんの開発に何かしらお役に立てれば幸いです。

今回記事を書いていて改めて思いましたが、プロジェクトをどう進めるのが良いかはプロジェクトの性質やプロダクトのライフサイクルによって様々です。 例えばプロジェクトで実現したいことが明確で不確実性が非常に低く、仕様とのズレがでないように作ってリリースすればOK、というプロジェクトであればむしろウォーターフォール開発のほうがより低コストに価値の提供ができるケースもあるとは思います。

そのあたりの進め方については、プロジェクトの性質や要件に合わせ、より最適だと思われるものを選択していくのが良いとは思います。