チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

アジャイル原則の振り返り

経緯

今年7月にTeamSpiritにジョインしたYINです。日本とシンガポールを跨ぐプロダクト開発組織の責任者をしています。 公式ブログにての初投稿になりますが、アジャイルの話題をテーマにしたいと思います。

実は自分は、入社の時からTeamSpiritのアジャイル開発の高い浸透具合に感心しています。

例えば社内全てのプロダクトに対して、全開発チームがスクラム手法をフルに活用している事にしています。 ディリースクラム、スプリント計画、レトロスペクティブ、スプリントレビュー、リファインメントなどのイベントがほぼ教科書通りに実施されていて、2005年からスクラムプロセスをずっと適用してきた人間としては、本当に嬉しいかぎりです。

なお、社内ツール系も、基本的にJIRAでEPIC/STORY/TASKの進捗を記録し、ConfluenceやFigmaやMiroなどのコラボレーションドツールでドキュメントを管理して、作業効率向上に大変貢献しています。

今回年末のアドベントカレンダーの記事参加との経緯もあって、せっかくなので今のスクラム活動の棚卸しをしてみたいと思います。

例えば、同じような事をずっとやっていると、ルーチンワーク化、マンネリ化してしまう事があるでしょうか? スクラムマスターはチームを守っているにも関わらず、スクラム原理主義者と呼ばれる事があるでしょうか?

この時に、一旦原点のアジャイル12原則に帰って、振り返るといいと思います。

アジャイル宣言の背後にある原則

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

そもそも顧客満足度や(自分たちが思っている顧客ニーズではなく)本質の顧客ニーズが分からないと、 「価値のあるソフトウェア」かどうかは判断できないので、より顧客との協調が必要になります。 現状のアセスメントとしては、まだまだ不十分です。

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

こちらは変化に対してある程度対応しているので、特に大きな課題がないと思われます。

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

基本的に3ヶ月でメイジャーリリースしていて、柔軟にマイナーリリースとパッチリリースも対応しているので、合格になります。

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

「ビジネス側の人」の定義によりますが、現在の開発プロジェクトに直接に参加していないと思われます。 顧客との協調の面ではもっと改善したいところです。

5 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

「意欲に満ちた人々」については特に大丈夫ですが、お互いの信頼関係が足りているかと言われると少し不安になります。 マネジメント業務的には、メンバーへの支援が一番のミッションなので、引き続き改善していきたいと思います。

6 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

コロナ禍の中は、基本的に在宅勤務で、相手の顔が見えないコミュニケーションスタイルになっています。 しかしスプリント計画やレトロスペクティブやリファインメントなどの場合は、フェイス・トゥ・フェイスが有効である事なので、 感染対策を取って物理出社した方がいいと考えています。

7 動くソフトウェアこそが進捗の最も重要な尺度です。

進捗管理について、「動くソフトウェア」という指標がなかったと思われますので、どう測っていくかは、今後の課題になります。

8 アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

持続可能な開発していると思われるので、特に大きな課題がないと思われます。

9 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

「設計に対する不断の注意」については何をしているかは気になります。 技術負債を可視化にしていますか? 性能改善と向上していますか? 新しい技術を取り入れていますか? 情報セキュリティの脆弱性を解決していますか? 継続的に設計をアップデートしていく事は大きな課題になります。

10 シンプルさ(ムダなく作れる量を最大限にすること)が本質です。

シンプルを追求しているか微妙だがある程度が出来ていると思われます。

11 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

最近は「自己組織的なチーム」より「自己管理的なチーム」が望ましいとの説がありますが、現状はある程度が出来ていると考えています。 これからも自律的に成長可能なエンジニアリング組織作りにしていきたいと思います。

12 チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

二週間スプリントの感想を述て、「効率を高める」目的の振り返りをしていないケースはよく見かけます。 振り返りの目的にを忘れずに心がけます。

まとめ

毎日スクラムをやっていると、原則やそもそも論などを忘れる事はよくありますが、アジャイル原則を定期的に振り返って、改善の過程も継続に記録していきたいと思います。