こんにちは。BASE BANK株式会社 Dev Division にて、 Software Developer をしている東口（@hgsgtk）です。
先日開催された July Tech Festa 2020 にて、「少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方）」という表題で、発表させていただきました。
発表資料
今回の発表資料は、Speakerdeck に公開しています。
発表内容を通じて解決したいことは、 率直に書くと、 数ヶ月前の自分が教えてほしかったことです。数ヶ月前の自分は次のような状況でした。
- 漠然とチーム開発に課題を持っていている
- その課題に対して、アジャイル関連の施策が、有効な気がしているが、一歩踏み出せていない
この資料は、そんな状況を目前としている方々のなにかの役に立てば、と思いまとめたものです。
また、アジャイルと一口に言っても様々な要素が絡んできますが、当該資料は、「チーム環境」に焦点を当てたものです。「An Agile Way: アジャイルの「ライトウィング」と「レフトウィング」」の整理では、アジャイルのレフトウィング（協働でゴールに向かう「チーム環境」）の範囲をスコープとしています。
まずは現状を見る
その状況において、私が出会って解決の糸口となったのは、「みんなでアジャイル ―― 変化に対応できる顧客中心組織のつくりかた」という書籍です。
その中で、次のようなフレーズがありました。
成功するアジャイルの適用は、常に厳しく正直に現状を見ることから始まる。 何がうまくいっていて、何がうまくいっていないのか。アジャイルを今の仕事 のやり方をちょっと変えるだけのことと思っているなら、アジャイルから得られ るメリットもちょっとだけになるだろう。今のやり方を選んだ元になっている現
2章 自分たちの北極星を見つける
そして、章の名前「2章 自分たちの北極星を見つける」にある通り、自分たちが大事にしたい・目指したい目標を、言語化することから始めています。
そこからアジャイルとの親和性を考える
自分たちの現状の課題・目指す方向性を言語化出来ると、アジャイル開発の考え方・取り組み方法との対応を考えることができます。
Manifesto for Agile Software Developmentに示されているアジャイル開発宣言や、「アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法」にて説明のあるような基本的な仕事の進め方、から、その実践の有無を考察しました。
アジャイルプラクティスを漸進的に導入する
すべてのプラクティスを一気に導入することは、手一杯になりますし、一気に生まれた新しい手段・HOWを理解しようとすることに、関心が持っていかれる重力が生まれるでしょう。そのため、優先度にそって、少しずつプラクティスを拡大していくような変遷を、結果的にたどっています。
具体的には、1. チーム自身の検査と適応→2. プロダクトに対する検査と適応というフェーズをたどりました。
ここで取り組み始めたのは、まずチーム自身の検査と適応のリズムを作ることです。
- 1週間の スプリント（イテレーション） を設定、最初に計画（ スプリント計画 ）し、スプリント終了後に、自分たちチームの取り組みについて振り返る レトロスペクティブ を行う
- 見積もりに、相対的な大きさによって図る ストーリーポイント を利用
- 現在の状況を可視化するために カンバン管理 を行う
カンバン管理は、かつてから Asana を使っていたのですが、うまく管理できていませんでした。今回の取り組みでは、アジャイルの境界を開発チーム内としたので、開発作業との親和性を考え、 GitHub Project を利用しました。
それ以外には、日々のコミュニケーションの機会であるデイリースタンディングは、以前から行ってました。
そして、その後、チームが作り出す成果・プロダクトの作り方に対してプラクティスを適用していきました。
- プロダクトへのフィードバックループがより頻繁に回るように、スプリントごとの成果物に対する振り返り（スプリントレビュー）を行う
- フィードバックをもらうために、リリース計画を行う際の前提の考え方を変える（バーティカルスライスでのデリバリーへ）
不確実性を段階的に低減させていく意図
この変遷になった背景には、主に２つの理由を考えていました。
1つ目は、まずは具体的なプラクティスではなく、目標に目を向け、その方法のWHYに着目し、自身の取り組み・振る舞いに対する検査と適応のリズムを作り出すのを優先するという意図。
2つ目は、「アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法」にて紹介されている、開発プロジェクトの不確実性の考え方「 Alexander Lauferの不確実性理論」です。この概念では、プロダクトにおける不確実性を次の２つに整理しています。
- 目標の不確実性 (end uncertainty)
- （開発PJに対応させると、）何を開発するのか、スコープ・プロダクトの性質
- 方法の不確実性 (means uncertainty)
- （開発PJに対応させると、）どうやって開発するのか、技術・スキル・連携方法
すべてのことを一気に片付けようとすると混乱が生まれがちです。そのため、まずは、チームの連携方法や動き方、についての方法の不確実性を低減させ、その後「どういうプロダクトを作るのか」という目標の不確実性を低減させるような取り組みを続ける、フェーズ分けとなりました。
バーティカルスライスでのデリバリーを前提とする
「プロダクトに対する検査と適応」を考えると、その具体的な施策は、プロダクト成果物に対するレビューを行うスプリントレビューが、一つ考えられます。これは、そもそも、イテレーションで生まれる成果物（スクラムの言葉では「インクリメント」でしょうか）に対して、フィードバックが得られるような計画をしていることが前提にあります。その前提において重要なことが、バーティカルスライスでのデリバリーでしょう。
これは、「More Effective Agile “ソフトウェアリーダー”になるための28の道標」という書籍では、より効果的にアジャイルの価値を引き出すための一つの基本原則としても紹介されています。
短いスプリントがうまくいくには、動く機能を少しずつ頻繁にデリバリーする能力をチームが養わなければならない。こうした活動をサポートするために用いられる設計アプローチはバーティカルスライスと呼ばれる。バーティカルスライスは、増分的に機能または価値をデリバリーするために各アーキテクチャ層で変更を行う、というものである。
9.4 基本原則：バーティカルスライスでのデリバリー
つまり、「XxxAPIを実装します」・「テーブルの設計をします」といったレイヤごとの作業ではなくて、「ユーザーとして自身のメールアドレスを変更できる」といったように、一つのフルスタックの機能を指します。
実際に、プロダクトに対する検査と適応のループを回そうとすると、この考え方が必要になってくるため、リリース計画自体もこの考え方を前提にリプランニングをしました。
取り組みを始めてから
実際にこのような取り組みに踏み切ったのは、COVID-19の流行がはじまった今年の春からの話です。しかし、1weekのスプリントを通して、チーム開発についてのフィードバックループが、以前よりも早く回っていることを感じます。
具体的に目に見えるような差で言うと、JTF2020から2月弱前の2020年6月4日に、コネヒトマルシェというイベントで「小さなチームが始めたアジャイル開発」という発表をしました。目指す方向性は変わっていませんが、その中のチームの取り組み・実装方法は改善され、変容を遂げています。
チームやその周りを取り巻く状況は日々変わっていきますが、その不確実性の高い外部要因に対しても、スプリント単位での適応の議論ができているように感じています。
さいごに：July Tech Festa 2020 への謝辞
July Tech Festa 2020とは、2020年7月25日（土）に開催された、カンファレンスです。今回、600名強？の参加申込みがあったとのことした。
ITに関わる全ての人の知的好奇心を満たすお祭りを作りたい。 その思いからJuly Tech Festaは生まれました。 興味のある技術に触れ、普段会えない人の話を聞き、 参加したエンジニアがスキルやキャリアについて考えるきっかけになれば。 そんな場を作ろうと今年も July Tech Festa 2020 を開催します。
個人的な話で恐縮ですが、自分が社会人エンジニアになってから初めてカンファレンス参加したのが、July Tech Festa でした。たしか July Tech Festa 2016だったと思います。その際、「外の世界は想像以上に先へ進んでいる...!」と衝撃を受け、今回のカンファレンステーマであるように「Extend Your Engineering Life!」したことを、強い記憶として思っています。今回、そんなJuly Tech Festaのスピーカーとしてプロポーザルを採択いただいたのは、感慨深い想いでした。
今回、初のオンラインでのカンファレンスのなか、運営スタッフの方々には、この場を借りて感謝申し上げます。ありがとうございました。
