今回は開発の方法論についての記事です。アジャイル開発のセミナーに参加して、実際にアジャイル開発している現場を見学して驚きました。なんでって、みんな楽しそうに開発をしているんです。遊んでいるわけではなく、ちゃんと仕事しているのに、現場の雰囲気がすごくよくて、いままで経験してきた開発とは異なる環境でした。
アジャイルにすれば、すべからくそうなるとは思いませんが、『開発する』ということを考え直すきっかけになりました。
私が衝撃を受けたポイントを紹介していきます。
・驚き１：みんなが設計開発している
現在主流の開発方式では役割分担が重視されています。設計担当、実装担当、テスト担当、運用担当など、あらゆる工程で担当が分けられていてそれぞれ担当の作業を遂行することをミッションとしています。
一方アジャイルでは多能工という言葉があり、設計、実装、テストまで、担当ということはなく、チームとして参画した人はどんな作業もやる（できるようになる）ということがあります。 つまり、みんながそれぞれ少しずつ設計し、実装し、テストします。
すべての工程をチームメンバーが少しずつ作業をすることでいくつかメリットがうまれます。
- 属人化のリスクが軽減される
- スキルトランスファーの手間が省ける
- メンバーのスキルアップのハードルが下がる
作業担当を設けるとその人した作業しなくなる（その人に任せた方が早い）みたいな状況が生まれやすくなります。そんな状況になった後で属人化を排除しようとと思ったら、いままで積み上げたものを整理する必要があるのでかなり大変です。最初からチームメンバーで少しずつ情報を共有していれば、誰か特定の人しか知らないという状況が生まれづらくなるし、引き継ぎの時も複数人で洗い出しが可能になります。
少しずつ作業するということは、作業単位が小さくなるということでもあるので、スキルや作業を教えるのが少し楽になるし早い段階でレビューも可能になります。さらには、教える側の手間も軽減されるし、教えてもらう方はスキルアップのハードルが下がります。
アジャイルはチームのメンバーが自立して作業ができるチーム（自己組織化されたチーム）で全員の力を合わせて開発する手法なのです。
・驚きPoint２：タスクはチームメンバーが決める
一例ですが、ソフトウェア開発で手間で負荷が高いものと考えたときに、テスト時のエビデンスの取得、品質指標の取得などのソフトウェア開発の結果を報告する資料の作成があります。お客様に成果を報告する上では重要な作業なのですが、足かせになっていると個人的には感じる部分もあります。
一方アジャイルではタスクをチームメンバーで決めることができます（というか決めます） 。テストをしない、品質を検定しないということではなく、お客様を含めて合意した内容をタスクとするのです。
なぜそうするかというと、ソフトウェア開発者がお客様に提供するのは設計資料でも作業の妥当性を示すエビデンスでも、品質の報告書でもありません。「動くソフトウェア」こそがお客様に提供すべき価値だからです（アジャイルソフトウェア開発宣言） 。
お客様のことを考えた時に、限られた時間を不必要な作業に割くことはデメリットでしかありません。お客様の価値に紐付かない作業であるならそれをタスクとしないということです。
標準化で決まっているから、社内プロセスで決まっているから、それに従わないといけない。そんな状況に出会ったことはありませんか？従う従わないもチームで議論して決めるべきだというのがアジャイル開発の在り方です。
・まとめ
私の驚いたポイントを２点あげさせてもらいました。いずれも今まで私が参画してきたプロジェクトのやり方とは全く別のやりかたでした。すべてが新鮮で適用するためには仕事のやり方を大きく変える必要があるなと感じました。
驚きポイント２に関連しますが、アジャイルでは作成するソフトウェアを除いて納品成果物を定義しません。ソフトウェア以外の成果物はチームで決めます。これは一例ですが、アジャイル開発にはソフトウェアの開発部分に関してのルールがほとんどありません（驚きポイント３ですかね・・・） 。
書いてあるのはコミュニケーションの取り方や時間の使い方、チームビルドについてなどで、すべてはチームの自立性に任せるとあるのです。ソフトウェアの開発スピードが高速化している中でいままでのやり方で適応できるのか、アジャイルのような柔軟性、適応性があるプロジェクト運営方法がよいのか考えさせるセミナーでした。
以下にアジャイルソフトウェア宣言とアジャイルソフトウェア開発の原則を記載します。
アジャイルソフトウェア開発宣言
プロセスやツールより個人との対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
https://agilemanifesto.org/iso/ja/manifesto.html
アジャイルソフトウェア開発の原則
１．顧客満足を最優先し価値あるソフトウェアを早く継続的に提供します。
２．要求の変更はたとえ開発の後期であっても歓迎します、変化を味方につけることで、お客様の競争力を引き上げます。
３．動くソフトウェアを２、３週間から２、３か月というできるだけ短い間隔で璃々0須します。
４．ビジネス側の人と開発者はプロジェクトを通して日々一緒に働かなければなりません。
５．意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え、仕事が無事終わるまで彼らを信頼します。
６．情報を伝える最も効率的で効果的な方法は対面で話をすることです。
７．動くソフトウェアこそが進捗の最も重要な尺度です。
８．アジャイルプロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
９．技術的卓越性れれた設計に対する不断の注意が機敏さを高めます。
１０．シンプルさが本質です。
最良のアーキテクチャ、要求、設計は自己組織的なチームから生み出されます。
チームが最も効率を高めることができる方法を定期的に振り返りそれに基づいてやり方を最適化します。
https://agilemanifesto.org/iso/ja/principles.html
・参考文献
- 見える化大作戦『WEB+DB PRESS』vol.111 2019. p.72-96.
- 『わかりやすいアジャイルソフトウェア開発の教科書』( 前川 直也 (著), 西河 誠 (著), 細谷 泰夫 (著)、 SBクリエイティブ(2013/3/26))
- アジャイルソフトウェア開発宣言の 読みとき方 – IPA