🤔

うちのチームはアジャイルでやってますと言える条件とは

2020/10/24に公開

マネジメント

ポエム

開発

idea

はじめに

IT企業にはソフトウェア開発方法論という概念があります。
有名どころとしてまずウォーターフォールがあり、その次に有名どころ、およびトレンドであり対義語のような存在としてアジャイル開発があります。
他の方法論もありますが、この2大巨塔のどちらの派閥として自分は仕事をしているのか、そんな哲学の話です。

現実には、能力の不足、納期の不足、人員の不足により理論値とは程遠い何かとして日々を過ごしているチームが大半ではないでしょうか。
要件定義フェーズや開発フェーズなんて綺麗に分かれていない、少なくともウォーターフォールではない。
かといってアジャイル開発ですと言い張る自信もない、なんなんだこの体制は。
自分は今までそんな感覚でエンジニアとしての日々を過ごしてきました。
某銀行のようなガチガチの大規模案件の経験が無いのもあります。

だがしかし、なんだかんだ、何をもってアジャイルなのかを詳細に理解していない、カオスと思いつつも案外アジャイルだったのかもしれない。
そろそろ一開発者ではなくチームの体制とか考える必要も出てきたし勉強しないと...
そんな状態に陥ったのでアジャイル開発について整理するメモを残します。

アジャイルソフトウェア開発宣言

アジャイルとは何ぞやってひとはwikipediaを読みましょう。
そもそもアジャイル開発は自然発生的な概念ではありません。
アジャイルソフトウェア開発宣言が提唱されたことに始まります。

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。



Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas



© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。

ミーティングすることがアジャイルなのか

プロセスやツールよりも個人と対話を、

この部分の解釈は迷いましたがミーティングの頻度の話ではないでしょう、少なくとも今は。
アジャイルソフトウェア開発宣言の作成は2001年、もう20年物の宣言書になろうとしています。

タスク管理ツールやコミュニケーションツールの進化に伴い、対面のミーティングでないと損失されるものは日々少なくなっていくでしょう。
また今はリモートワークも広まっていますし...

この宣言の本質は「顧客が本当に求めているもの」が開発プロセスやツールに振り回され見失われる事を意味するものと思われます。
よくある事例として、要件定義書を作る作業担当は要件定義書を作ることが目的となり、ガントチャートを作ればガントチャートを作ることが目的となる、誰のため、何のためにこの作業をやっているのか、プロジェクトの成功なんてそれぞれの担当者の視界に入っていない。
そんな人物を見たことがある、はたまた自身の身に覚えがあるという人は多いと思います。

また、要件定義担当と実装担当、テスト担当での意思疎通、はたまたバックエンドとフロントエンドなどのチーム間での情報共有が各フェーズの成果物としてのドキュメントのみである場合の情報損失に対する警鐘でもあるでしょう。

包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を

この部分も「顧客が本当に求めているもの」と実態の乖離という側面で解釈すると筋が通ります、アジャイルソフトウェア開発宣言の作者が最も忌み嫌っていることは、形式や開発フロー、官僚的な組織体系に囚われて要求の本質を見失う事ではないでしょうか。

速ければアジャイルなのか

包括的なドキュメントよりも動くソフトウェアを

アジャイルとは機敏という意味でウォーターフォールは遅いので対義語、というものではなく、明確にウォーターフォール開発に対するアンチテーゼとして産まれた宣言があるが故に、ウォーターフォールとアジャイルは比較されるわけです。

さてこの宣言には2カ月で動くものを納品しますという宣言はありません。
一方アジャイルソフトウェアの12の原則には

動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。

と記載があります。
従って早いスパンでのリリースは要件定義やドキュメンテーションに膨大な時間が割かれる事、また時間をかけて作成した要件が的外れであることへの対抗手段であり、目的ではないと考えられます。

極論、超高速で要件定義書、詳細設計書を仕上げ、それらに従い開発を行えば、スタートから2カ月でリリースしてもそれはウォーターフォールであると言えることになります。
（まあそれができたら素晴らしい事でアジャイルの本質を捉えていないとダメなんて事は一切ないと思いますが）

包括的なドキュメントよりも動くソフトウェアを

大義はここにあります、「形式として仕様書がしっかり存在するという事実」が仕事として求められる文化がある時点で100％純粋なアジャイルであるとは言い難く、仕様書より成果物が重視される文化を顧客に、内部に作っていく事が求められます。

アジャイルにドキュメントは不要なのか

動くソフトウェアを重視する一方で、アジャイル開発宣言は

左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく

と明記してある通り、完成さえすれば仕様書も設計書も不要である、というような暴論ではありません。
成果物の挙動が仕様なのかバグなのか判断できなくなるようなカオス状態はリリースが高速だろうと体制がアジャイルだろうと論外でしょう。
そのような状況に陥らない程度にはあるべき仕様、設計が明記されている必要があります、結局バランス感覚が大事ですね。

また、開発メンバーの追加、変更があった時に

環境構築の手法がまとまっていない。
開発環境、ステージング環境の情報が人に聞かないとわからない。
人が離脱すると失われるノウハウがある。

といった状況の言い訳に、「うちのチームはアジャイルなんで」と言えるかというとNOという事になります。
それはただの駄目なチーム運営です。

アジャイルに契約交渉は不要なのか

契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を

いつまでに何をリリースするのか、プロジェクトマネジメントにおいてこれを決めることが顧客の満足度、プロジェクト運営の成否を左右する重要な要素と言えるでしょう。
顧客の求める納期に対し、どこまで要望を飲めるのかを正確に見積もり、明確に約束できないとプロジェクトは炎上します。
その為ウォーターフォールでは明確に「何を」作るのがプロジェクトの契約なのかを定義します。
要件定義フェーズで決めたこと以上のことは開発しないのが原則です。
一方そのような決定を重視すると、要件の変更に対する柔軟性が損なわれます。
アジャイルソフトウェアの12の原則には変更要求を受け入れることが明示されています。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

これは開発の柔軟性がビジネスの競争力に影響を及ぼすことが明らかであり、
本質的な開発チームの役割は顧客のビジネスを成功に導くことである、という意味でしょう。

では顧客の要望を無策に全て受け入れるとどうなるのか、膨れ上がる要件、増え続けるタスク、変わらない納期、考えるまでもありません、死にます。
開発手法がなんであれ「いつまでに何を」が曖昧だと炎上する危険性が消えることはありません、顧客の期待値を制御する意味での契約交渉は依然として必要です。

そこでアジャイルチームが約束することは「いつまでに」リリースするかです。
「デモバージョンを何月に納品する」
「月に2回のバージョンアップデートを行う」
これらの約束ありきで、期限に対してどのような機能変更、バグFixを盛り込んでいくかは柔軟に対応する、という方針がアジャイル的契約交渉と言えるでしょう。

まとめ

ここまで書いてだいぶわかってきました、
結局のところ、ビジネスパートナーとして顧客の成功に最大限貢献する手法を考える、という事が開発方法論の本質であり、アジャイル開発とはそのための提案の一つなわけですね。
アジャイルがウォーターフォールより優れているのか否かは今回触れないことにします。

自分のチームはなんとなく良い感じに動いているわけではなく、アジャイルであると言う為に必要なポイントは、

顧客、チームとの目的共有がドキュメントのみに依存しない、一丸となった体制を構築している
「設計書の納品」など形式的な作業はあくまでも手段であり目的としない
顧客要求を成果物の形で確認する文化ができている
リリース時期を明確にしている、リリース時期を軸にやること、やらないことが決まる
といった所だと思いました。

※開発のライフサイクルが長くて2～3カ月であるというのは言うまでもない前提条件です。
なお私は専門家でも何でもないです。
この記事はアジャイルソフトウェア開発宣言およびググって出てきたものを自分なりに解釈した結果をまとめたものです。

参考情報
NEC アジャイル開発～顧客を巻き込みチーム一丸となってプロジェクトを推進する～
富士通ソフトウェアテクノロジーズアジャイル開発とは
 HP 「開発手法」だったアジャイルはここまで進化した
 住友電工情報システムアジャイル開発（アジャイルソフトウェア開発）