このシリーズでは、実際のシステム運用プロジェクトの中で、アジャイルアプローチの適用を挑戦したコンサルタントの経験をもとに、アジャイルによる業務のアップデートのやり方をレポートします。
とあるお客様企業にERPを導入するプロジェクトに関わっていた経験をもとに、このコラムを書いています。これを書いている時点（2019年8月）では、導入して運用開始してから1年が経過している状態です。
この1年間、運用支援と合わせてそれなりの規模で追加開発のプロジェクトを続けていて、軽微な修正から中規模のものまで月に10～20件の改修をリリースしています。
カットオーバー当初は追加開発や仕様追加が多発し、とにかく最短で改修してすぐリリースして業務への影響を最小化しているような状況でした。日々改修を続けていく中で少しずつ追加の要望対応も増えてきて、そんな中でも同じようなペースでリリースを続けていたのですが、最近ふと気づいたのです。
「これってかなりアジャイルなアプローチなのでは？」と。
そこで「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」に沿って今のプロジェクトでアジャイルアプローチを可能にしている要素、アジャイルアプローチのメリット、デメリットなど気づいたことを共有していきたいと思います。まず第1回として「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」とはそもそもどんなものなのか、ご紹介したいと思います。
アジャイルソフトウェア開発宣言とは？
「アジャイルソフトウェア開発宣言」は、従来型のソフトウェア開発のやり方とは異なる手法を実践していた17名のソフトウェア開発者が2001 年に一堂に会し、それぞれの主義や手法についての議論を通して生み出されました。そこには、彼らがソフトウェア開発を行ううえで重視している「マインドセット」が書かれています。その後、このマインドセットは世界中のソフトウェア開発者達に支持され”アジャイル開発” という名で世に広まりました。
（IPA「アジャイルソフトウェア開発宣言の 読みとき方 」より引用）
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。
すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
https://www.ipa.go.jp/files/000065601.pdf
これを読むとあくまでも「マインドセット」が書かれていることがわかります。
これを読んで「アジャイルやるぞ」となっても、具体的には何をしたらよいかわからない内容です。
ただ、「AよりもBを重視する」という記載には「決してAが不要ということではなく、Bをより大切にしている」というコンセプトが伝わります。
「アジャイル宣言の背後にある原則」
「アジャイル宣言の背後にある原則」は「アジャイルソフトウェア開発宣言」で表明されているマインドセットを実現するために従うことが望ましい原則、つまり根本的・根源的な取り組み姿勢について書かれています。原則は12項目で構成されています。
「アジャイル宣言の背後にある原則」
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
こちらを読むと少し具体性が出てきます。
今のプロジェクトで知らず知らずのうちに重視していた要素が並んでいて、これを読んでやっぱりアジャイルの要素を持ったプロジェクトなのだなと実感しました。アジャイルを目指してプロジェクトを進めたというよりも、今のプロジェクトが置かれた環境の中で最適なアプローチを模索した結果アジャイルになっていった、という方が正しいのですが。
アジャイルソフトウェア開発宣言、もっと詳しく知りたいという方は
IPAが2018年4月に「アジャイルソフトウェア開発宣言の 読みとき方 」という資料を公開していますので是非読んでみてください。
次回以降はこの「アジャイル宣言の背後にある原則」をERP運用支援プロジェクトでどのように実践しているのかを共有していきたいと思います。お楽しみに。
ライター
基幹システム導入PJを中心に、IT導入PJにおけるユーザー側タスクの支援に一貫して携わるビジネスアナリスト。構想策定から導入後の運用安定化支援まで、システム導入のライフサイクル全てに関わる。Scrum Alliance認定スクラムマスター（CSM）。（2021年6月時点）
