はじめに
こんにちは、新卒で入社してもうすぐ3年目に突入するみのみのです。
ここ半年ほど、担当プロジェクトの新米PMとして奮闘していました！📚
慣れないながらも試行錯誤し、辿り着いたアジャイルソフトウェア開発について書いてみたいと思います。
世の中のPM業をしている方、だけでなく開発者の方にとっても普段のお仕事の改善に繋がるかもしれません。
最後までお付き合い頂けますと幸いです💌
そもそもアジャイルソフトウェア開発って？
アジャイルソフトウェア開発とは、短期間で実装・リリースを繰り返し、顧客満足度の最大化を図るプロジェクト開発手法です。
そして、アジャイルソフトウェア開発を行う上で重視したいマインドセットとして
「アジャイルソフトウェア開発宣言」があります。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
出典：アジャイルソフトウェア開発宣言
ちょっとわかりにくい表現かもしれませんが、
左記のことがらよりも、右記のことがらを重要視したほうが、不確実な状況下で価値を生み出しやすいというように読み替えるとわかりやすいかもしれません。
また、アジャイルソフトウェア開発宣言の背後には１２の原則があります。
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
出典：アジャイル宣言の背後にある原則
ここから読み取れる重要なマインドはなんでしょうか。
簡単そうに見えて、やってみると難しいようなマインドです。
・要求の変更を歓迎する
・短い期間でリリースを繰り返す
・開発者とシステムに携わる人は密に連携を行なう
・現場で使えるソフトウェアであることが価値である
・技術的な妥協はしない
・問題を解決するための方法をチームで考え、決定し、臨機応変に変える
これらのマインドを紐解くことで見えた、システム開発の性質は下記と考えました。
・すばやく届ける必要がある。
・システムとは完成するまで不確実なものである。
なので、変化に対応できるように準備しておく必要がある。
・100％顧客のニーズを捉えた完璧なものを届けることは不可能だ。
なので、届けた時点において顧客にとって最大限の価値を発揮することを目指す。
・エンジニアは技術職であるからこそ、顧客との意思疎通が難しいことがある。
なので、連携をとりながらプロジェクトを進めていく必要がある。
すばやく届けるためのプロジェクト計画
アジャイルでは、イテレーションと呼ばれる一定期間の開発サイクルを繰り返し、細かくリリースをします。
そこで、次のイテレーション期間でなにをどうやるかの計画が大切です。
限られたリソースのなかで、どう優先順位をつけるのか。
・要望▶ほぼ無限
・時間▶有限
・予算▶有限
・品質▶有限
答えは「要望」を調節することです。
ときとして要望は大きな「カタマリ」として訪れます。
しかし、その要望すべてが本当に必要なのでしょうか？
本当に必要なものを見極める
「要件」とは「必要な条件」を意味します。
しかし、分厚い要件定義書に書かれている１～２割の機能さえあれば、
案外想定していた通りのビジネス上の利益を得られるといわれています。
では残りの８割はなんなのでしょうか？
これらは、「要件」とは呼べません。
タスクの見積もり
さて、タスクの調節をしたところで、さっそく見積もりをしてみましょう。
どのように見積もるのがよいでしょうか？
アジャイルでは前提として「見積もりはあてずっぽうである」と考えます。
初期段階の、不確かな情報しかないなかで、正確な見積もりは不可能なのです。
リリース間近になって（検証がある程度おわって）だんだんと確実になっていくのです。
相対見積もりのすゝめ
アジャイルソフトウェア開発の名著といわれているアジャイルサムライでは下記のQ.が例に挙げられています。
Q. 8枚のクッキーと10枚のクッキーを食べるのにかかる時間はどのくらいでしょうか？
1枚のクッキーを食べるのに10秒かかります。
・・・これなら、大体予想がつきますね。
外れたとしても、大幅に外れることはなさそうです。
では、こちらはどうでしょうか？
Q. 風船を６つ膨らませるのにかかる時間は？
Q. １組のトランプから足りない１枚を探し出せる時間は？
Q. ２つのサイコロを振ってぞろ目を出すのにかかる時間は？
うーん・・なかなかイメージしづらいですね。
このように、人間は相対見積もりならある程度うまくこなせるのです。
「相対サイズで見積もる」というシンプルな原則がアジャイルな見積もりと計画づくりの真髄なのです。
何も基準がないところで、お肉の重さ100gを測るのでは一般人はお肉のプロには勝てませんが
基準のお肉があれば、相対的なお肉の重さを測るとなると、一般人でもプロに劣らない正確さになるそうです。
必要なもの：チームのベロシティ
タスクの相対見積もり
タスクを優先順に並べて、チームで相対見積もりをしてみましょう。
工数ではなく、相対で見積もるのです。
基準となるタスクを１つ掲げて、それにくらべて大きいか、小さいか、どのくらいの規模感のタスクなのかをざっくりと考えてみます。
私たちのチームではポイント（pt）という単位を使って見積もりをしています。
タスクごとにフィボナッチ数列を使って、プランニングポーカー形式で数字を出し合っています。
プランニングポーカーとは、各自の思うタスクの規模を「せーの」で一斉に提示する工数見積もり手法です。
意見が分かれたら話し合いを行い、最終的なポイントを決めます。
このとき、誰も責めたり、否定したりしてはいけません。
ざっくりとした見積もりのなかで、その人が何を考え、何が見えたのか、素直にきくのです。
こうして見積もったタスクたちを優先順ですすめていきます。
毎月続けると、チームが１イテレーション期間で何ポイントぐらい達成できるか、わかってきます。
１イテレーション期間で達成できる範囲のことを「ベロシティ」といいます。
ベロシティの算出と、相対見積もりができるようになれば、プロジェクト計画が上手につくれるようになります。
プロジェクト計画時のポイント
ベロシティ＝プロジェクト計画 とするのは危険です。
想定外のタスクや、定型業務のことも見積もりにいれなければなりません。
そうすると、大体プロジェクト計画時はベロシティの４～５割を達成目標とするのがちょうどいいといわれています。
プロジェクト計画がうまくいくために
現在、プロジェクトは計画通り順調に進んでいるのだろうか？
計画ができたら、進捗を把握する必要があります。
進捗を把握するためには、プロジェクトの状況を可視化する必要があります。
可視化の有名な手法としては「カンバン」がありますね。
カンバンは、トヨタ自動車株式会社の生産管理から発祥した管理方式です。
プロジェクト管理においては、チーム全体で個人のタスクを共有して管理する方法として使用され、
「作業前」「作業中」「作業完了」などといったステータスに各タスクを貼り付けて表示します。
私たちのチームでも、各タスクの状態をチーム全員が常に見える状態にし、チームの進捗状況を日々確認するようにしています。
こうすることで、タスクの進捗を調整したり、早い段階で技術的な相談やリリース日の相談、調整ができるようになります。
おわりに
今回は「アジャイルソフトウェア開発」について特にプロジェクト計画部分を紹介しました。
しかし、これらを実践・導入したからといってそのプロジェクトはアジャイル開発手法である、とは言えません。
アジャイルソフトウェア開発の各イベントを実施しているからアジャイル開発なのか？ テストを先に書けばテスト駆動開発なのか？ そうではないですよね。
アジャイルはあくまでも思想であり、その思想に基づくプラクティスが用意されているだけにすぎません。
世界に同じプロジェクトは２つとないのですから、自分の頭で考え続け、改善を繰り返し続けていくことこそが、アジャイルソフトウェア開発手法のマインドセットだといえます。
参考文献
アジャイルサムライ − 達人開発者への道
著者：Jonathan Rasmusson 著／西村直人・角谷信太郎 監訳／近藤修平・角掛拓未 訳
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
著／西村 直人 (著)・永瀬 美穂 (著)・ 吉羽 龍太郎
弊社の風土として
私は、タスク管理業務をしていくうえで、なにかうまいやり方はないかと思い、アジャイルソフトウェア開発に辿り着きました。
提案し、実際に導入していくことができ、日々試行錯誤しながら、よりよいプロジェクトを目指すという経験ができました。
自ら学び、実際に提案し、学んだことを実践してみたい、そんな若手の背中を押してくれる先輩たちがいます😊
☆スタイル・エッジ・グループでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！
recruit.styleedge-labo.co.jp
