以前、Regional Scrum Gathering® Tokyo 2015で参加したワークショップからヒントを得て、アジャイル宣言の背後にある原則に対する振り返りを会社のチームで実施しましたので、その内容を簡単に記録したいと思います。

やったこと

12の原則を1つ1つ扱って、自分たちの行っていること(フローであったり、プラクティスであったり）の何が該当するのか、もしくは矛盾していないか、をチームメンバーでブレストしました

ちなみに、思っていたより大変で、1時間やって話せたのも4つだけでした。改めて真剣に考えると、自分たちの未熟さを痛感して、なかなか辛かったのですが、その分学びも多く、大変有意義でした。

話した内容

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

顧客ってプロダクトオーナーなのか？エンドユーザーなのか？
ソフトウェアの価値って何なのか？（品質？MVP的なもの？）

顧客をエンドユーザーとした場合、顧客満足を最優先にするということは、プロダクトバックログの内容や優先度に対して、それを鵜呑みにするのではなく、それが顧客に対して価値のあるものなのか、という説明（証明）を開発チームとして求めていく、ということではないか

というような議論をしていました。

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

スプリントの後期に要求が変更されたら、どうしてもイラッとしませんか？
なぜ変更する必要があるのか、がちゃんと理解出来れば、歓迎できるかも

ここで言う「要求の変更」は、きっと、仕様がふわふわしてる、みたいな話ではなく、競合の動きとかで商品戦略が変わった上での仕様変更、のような、ちゃんとした理由のある要求の変更なんだろう、と解釈しました。

スプリントプランニングでがっつり計画を作っていたり、しっかり設計をやった後とかに要求が変わると、ついイラッとしてしまうのですが、なぜそのストーリーを実施するのか（=WHY)を忘れてはいけない、ということだろう、という議論をしていました。実装者が満足するために実装するのではなくて、顧客に対して価値を提供するために実装しているのですよ、ということかな、と。

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

プランニングを通じて、大きすぎるタスクは着手前に対処できている
できるだけ不透明なものを無くした状態でスプリントを開始すると良い

こちらは、生産性という点ではまだまだ改善はしていきたいものの、スプリントで決めたタスクを実施することで、達成出来ているな、という感想でした。とはいえ、SCRUMを開始した直後は、プランニングが甘くて辛い思いをしたことがあったので、プランニングをこれからも頑張りましょう、という感じで話をしていました

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

開発チームとしては、一緒に働けていると思っている
プロダクトオーナーとしては、まだステークフォルダーを巻き込めていない

ここの内容は、社内体制にかなり影響を受けてしまっているのですが、現在、プロダクトオーナーが実際の最終ジャッジをする人の代理のような形で動いていることがあり、ここは改善していかなくては、という話をしていました。ただ、開発チームからするとインターフェースとしてのプロダクトオーナーはSCRUMにしっかりコミット出来ているので、仕事はしやすい、ということでした。