自分が思うアジャイル開発とは？

# 初めに
アジャイル開発のプロジェクトへ参画することが度々あります。
しかし、これが本当にアジャイル？というプロジェクトも
多々見ることがあります。
この記事では自分が思うアジャイル開発の理想と
実際にどんなものなのかを調べてまとめたいと思います。
※個人の見解がありますので、これが正解という訳ではありません。

# アジャイル開発って？
検索で「アジャイル開発とは」で調べてみました。
アジャイル（Agile）とは、直訳すると
「素早い」「機敏な」「頭の回転が速い」という意味。
アジャイル開発は、システムやソフトウェア開発における
プロジェクト開発手法のひとつで、大きな単位でシステムを区切ることなく、
小単位で実装とテストを繰り返して開発を進めていきます。
従来の開発手法に比べて開発期間が短縮されるため、
アジャイル（素早い）と呼ばれています。

文章的にはこう紹介されています。

# 実際の経験談（プロジェクト開始時）
実際に経験して分かりましたが、
最初に述べた通り、
アジャイル開発と言いながら、そうではない案件があったり、
その通りにやっている案件があったり様々でした。
ただ、流れはそれなのかな？という感じですかね。

- ストーリーポイントで作業量を見積もる
スプリント（以下SP）単位で設計、開発、テストと行うので、
ある程度範囲は決めないといけません。
その作業の範囲を決める為に、ストーリーポイントというので
見積を行いました。
実際の動きはこんな感じです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1991436/931e8a8a-2437-0ab6-d59a-3cd35f94f046.png)
見積時は、各作業に対してストーリーポイントを割り振りました。

- 各作業を見積もる
次に、各作業に対しての見積を行います。
ストーリーポイントに収まるかどうかが大事です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1991436/122c8a71-8c36-d50a-cc13-48917b858c52.png)

割り振った後、お客様に報告。
この後、スプリントが始まり、作業が開始されます。

- 各スプリントの最終日
各SPの最終日はお客様とのレビューを実施しました。
筆者が体験した案件では、実際の成果物をお客様に
見せる形での報告でした。
以下の図のように作業Aに対する機能が実現できたことを
お客様に対して報告しました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1991436/74b1bb7c-ece1-9470-0ede-02bde313e6a5.png)

- 終わらなかった作業は？
実際に間に合わなかった作業については、申し送りという形で
次のSPに持ち込むこともありました。
もちろん、申し送りするにしても、正当な理由を説明しなければなりません。
筆者の場合は、テスト工程でのテスト用のプログラム作成が
間に合わないことがありましたね。
単体試験自体は完了していましたが・・・
ちゃんと理由を説明して次SPに持っていくように承認してもらいました。
※品質担保の為に、テストプログラムのカバレッジを出していたので、
それが時間かかりましたね。。。
最終的には、全SPが終わるまでに全てを提出できるようにしました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1991436/add0ee5e-90d3-b6fa-0847-98d97ac128da.png)

- 次のSPに向けて
冒頭の方で記載したストーリーポイントでの作業量の見積を行う前に
各作業自体にどれくらいのストーリーポイントを要するか
それ自体の見積を行いました。
それによって、与えられたストーリーポイント内で作業が
完了するかどうかの判断も行ってきました。

- 実際に経験して
開発者にとっては、見積もったストーリーポイント内で
作業をする訳ですから、そこまで負担が大きくかからない感じでした。
とはいえ、案件の開始直後は、他チームとの開発環境の足踏み、
アーキテクチャとの開発相談など、やることが多くて
プロジェクトの波に乗るのが難しかったです。
案件内で無駄作業も結構ありましたね。
波に乗ることができたのは、ある程度開発環境が整ってからですね。

:::note info
ストーリーポイントとは
実装するのに必要なコストを見積もるための単位のこと
- ユーザストーリーとは
システムがユーザーにとってどのような
価値をもたらすのかを示すもの
:::

# 実際の体験談（プロジェクト半ば～終盤）
プロジェクトも進んでいくと、
アジャイル開発での案件も大分慣れた感じでした。
後半はある程度出来上がった物に対する要望や
不具合の改修などを行うことが多かったですね。

- 前半では
とりあえず、建前上、機能的に要件を満たしているものができました。
とはいえ、何気なく作った訳でもなく、
SPの終わりにお客様とレビューで実物を見てもらい
お客様と一緒に形にしていったものが出来たという感じです。

- 作業の見積について
チーム毎のストーリーポイントは決まっています。
その中で、優先度が高いものからストーリーポイントを消化していきます。
ただし、何でもかんでも優先度が高いものから解決するのではなく、
あくまでストーリーポイントに収まる範囲で見積もります。
ですので、この時点では、余ったストーリーポイントで
優先度中小をこなしていった感じでした。
後の流れは、前半と変わらず、テスト工程も同じようにやっていきました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1991436/41930115-2c5c-8e21-0a5a-47c24844239f.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1991436/9313fc02-68c9-7768-93ab-9f38f438d20e.png)

- プロジェクト入った感想
結果的には色々ありましたが、プロジェクトは無事に終了。
運用後も、アジャイル開発と同じ流れで不具合の改修や改善要望
更には、追加機能の開発などお客様と長い付き合いになったり
ならなかったりですかね。
筆者はテスト完了と同時に退席しましたが。

# 理想なアジャイルとは？
個人の見解もありますが、自分にとっては
先ほどの説明したものが理想的なアジャイルと考えます。
１チーム辺り、７～８人。
残業も時と場合ぐらいで、最初からフルであった訳ではなく、
月の稼働時間も180時間以内に収められたかなと思います。
とにかく、運用としてはベストでゃないでしょうか。

# アジャイル・・・？
人それぞれと言ってしまえばそれまでかもしれませんが、
これはアジャイルなのか、と感じるプロジェクトもありました。
- 期限があっての見積
確かに依頼があってのモノづくりに対しては期限はあります。
そこは当たり前だと思います。
そもそも、期限があっての作業なのでしょうか？
その為のストーリーポイントがありますので、
ストーリーポイント内に収まらない作業に対しては、
きちんと報告し、タスクのスケジュールの見直しをするべきと考えます。
決して「じゃあ、この期限でよろしく」というのが
アジャイルではないと思います。

- ウォーターフォールではない
アジャイル開発とウォーターフォールの違いは以下の図の通りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1991436/86c0e132-a4f5-9564-0430-7872bf670894.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1991436/39e06ce9-d62d-202f-dee0-8638b0833e16.png)
上の図が、ウォーターフォール、下はアジャイルの作業の流れです。
違いは、部分ごとにリリースをしているところです。
ここから分かることは、部分的にリリースをしているので、
上位クラスの方も進捗を把握していることです。
決してスパンの短いウォーターフォールという訳ではありません。
このリリース部分がアジャイルでは大事な部分だと思います。

# お世話になったツール
アジャイル開発をする上で助けてもらったツールなどを紹介します。
- Jira
[公式サイト](https://www.atlassian.com/ja/software/jira)
アジャイル開発する際に課題管理をするのに便利でした。
課題の管理はタスク毎に管理できるのでスケジュール把握にも優れています。
- confluence
[公式サイト](https://www.atlassian.com/ja/software/confluence)
開発や環境構築のナレッジを貯めたり、成果物の管理、
会議の議事録を残すなど知識やノウハウをwikiみたいに
残すのに便利なものでした。
- プランニングポーカー
チーム内でストーリーポイントを見積もる時に
どれくらいのポイントがいいかチーム全体で話し合うときに利用しました。
- AWS
ご存じ、アマゾンのサービスです。
Gitと連携してソースコードをレビュー、コミットなどに利用してきました。

他にも色々な便利なものがあると思いますが、
筆者がアジャイルで使ったことがあるのはこちらのものでした。
# まとめ
今回、アジャイルを経験して学んだことをまとめました。
慣れていない部分もあり、実際に運用するのは
なかなか一筋縄ではいかないと思います。
いざ、自分が上級な立場になった時は
今回のまとめたことを参考に、良い部分は真似をして
悪い部分は反省点として活かしたいと思います。