前提
- 書き手はアジャイルについて詳しくなく、"正しいアジャイルとは？"といったこともよくわかっていないです。
- そのため、アジャイル"っぽい"としていますが、そもそもそれはアジャイルではないと言われる可能性もあることを承知した上で書いていますので、ご了承ください。
- ただ嘘を書きたいわけでは全くないので、気になる点があればコメントいただければと思います。
アジャイル"っぽい"とは?
- 新しい案件へのアサインの相談で、アジャイルっぽい進め方をする案件という話。
- 案件概要で提案書を使って、実装したい機能の概要とおおまかなスケジュールについて説明を受けた。
- 後日、別にいる案件担当者から案件の詳細をMtgで説明を受ける予定。
- ここでQCDのうち、CとDが確定しているアジャイルってどういうことだろう？と疑問が湧く。
※まだ案件詳細を聞いていないので、以下から書き手の推測を含みます。
-
まずアジャイル"っぽい"ってなんだろうというところを考えるところから始めてみます。
-
アジャイルとはなんぞやという記事はqiita検索をかけるとたくさん出てきますね。
-
また、アジャイルってこう思われているよねという記事も出てきます。
-
-
これらの記事を統合するとアジャイル"っぽい"と呼ばれる案件は以下のような特徴がありそうだと推察できそうです。
-
一旦の完成をもって動作確認、うまく動かない部分を修正しつつ最終的に正しいものにする。
- 上記をスプリントとみなしてしまう。
- 要求から機能、非機能要件（周辺の関連システム仕様を含む）が抜け漏れが想定されるため、柔軟に対応してほしい
- 上記をスプリントとみなしてしまう。
-
進捗管理やドキュメントを楽にできる。
- 計画を容易に変更して良い、ドキュメントより動作するコードといった部分を上記のように解釈してしまう。
- 契約期間が決まっている案件で計画の自由度は高くない（PMに期間内でできないので途中で終わりですor追加で契約期間伸ばしてくださいって言ってもらえますか？）
- ドキュメントに全てを残すことはもちろん難しいが、他メンバーやクライアント担当者、将来システムを運用するメンバーのため、いざというときの免責か否かの判断材料のためなど役に立つ場面がまだまだ多い（自分だけでそのシステムをずっと運用し続けますか？）
- 計画を容易に変更して良い、ドキュメントより動作するコードといった部分を上記のように解釈してしまう。
-
一旦の完成をもって動作確認、うまく動かない部分を修正しつつ最終的に正しいものにする。
アジャイル"っぽい"案件って。。。
- 上記２点がアジャイル"っぽい"案件だとすると、結構大変になりそうな案件だと予想されそうです。。。(あくまで勝手な予想)
アジャイル"っぽい"案件への向き合い方
(タイトル回収です)
- 大変になりそうな案件に対して、１メンバーとしてどう向き合う予定かという方針です。（案件終わった時にどうだったかもできれば書きたいです。）
- ウォーターフォールに基づき計画をし、手順をちゃんと踏む、ドキュメントを書き起こす
- 基本的には、ちゃんと要件を確認し要件定義書を書き起こす、設計書を記載し担当者にレビューしてもらう、単体テストや結合テストで要件や設計を満たしていることを確認するというウォーターフォールに基づいた方法を実直に行うことが必要に思われます。
- 早めの対応を心がける
- ウォーターフォールになるべく従いつつ、アジャイル"っぽい"と言われている以上、要件や仕様の抜け漏れが発生することは踏まえておくべきだと思われます。であれば、それらに対応できるようなバッファを意識的に作る必要があり、スプリントもどきのような対応ができる状況を作っておく方が精神衛生的に良さそうに思います。
- 全てを複数人が確認できるシステムに記録する
- 実際、全てを記録することはできませんが、仕様の検討内容や設計書の修正履歴、担当者の承認など残せるものは残しておくことで自分の身を守ることができる（かも）。
- 環境に反映したリソースもバージョン管理ツールを利用して、AWSインフラであればCfn+CodeCommit、アプリでもCodeCommitを利用することでいつ、なにを、なぜ反映したか分かるような状態を作っておく。
- AWS Configなども設定することでいつ、どのリソースが反映、修正されたか追跡できるようにしておく。
- ウォーターフォールに基づき計画をし、手順をちゃんと踏む、ドキュメントを書き起こす
まとめ
- アジャイル"っぽい"案件に対しても、通常の案件と同じことをしっかりと行うことで対応できそう。
- ただ、怪しい部分もあるので早めに怪しい箇所や不明な箇所を潰していくような動きをすることが求められそう。
参考URL