こんにちは。スパイダープラスで開発チームのEMを担当している細矢です。
近年、ソフトウェア開発においてアジャイル開発の考え方が浸透し、「うちのチームもアジャイルです！」という言葉を耳にする機会が増えました。
とはいえ、「これから導入を検討している」というチームや、「始めてはみたものの、本当に上手くいっているのだろうか？」と悩んでいるチームも、まだまだ多いのではないでしょうか。
この記事では、そういった方々に向けて、弊社での最近の取り組みをご紹介します。アジャイル開発をこれから始める方、そして既に始めているけれどもしっくりきていないと感じている方にとって、「はじめの一歩」を踏み出すヒントになれば幸いです。
この記事はこんな人におすすめです
- これからアジャイル開発やスクラムを始めようとしている方
- スクラムを導入してはみたものの、なんだか形骸化していると感じている方
- チームの目的意識を再確認し、パフォーマンスを向上させたいと考えているマネージャーやリーダーの方
1. あなたのチームは大丈夫？アジャイル開発の「よくある落とし穴」
「アジャイル開発でやっています」
以前と比べると、アジャイルやスクラムという言葉を耳にする機会が増えたと思います。
しかし、その実態はどうでしょうか。
- 日々の朝会が、リーダーへの進捗報告タイムになっている…
- スプリントレビューが、ただの成果発表会で、フィードバックが出てこない…
- 振り返りはやっているけど、効果的な改善につながっていない気がする…
もしこういったことに「あるある…」と感じたなら、あなたのチームはアジャイル開発やスクラムの「やり方（How）」だけを取り入れて、それらのイベントをただ “やっているだけ” になっているサインかもしれません。
このような状況に陥る原因は、多くの場合、次の問いをチームで共有できていないことにあります。
それは、「なぜ、私たちはアジャイル開発をするのか？（Why）」です。
2. “How”の学習から見えてきた、「”Why”がなければ始まらない」という気づき
弊社EM内で、組織全体の開発プロセスを改善しようという動きが始まりました。
その一環として、今後開発チームにアジャイルやスクラムの考え方を取り入れていくために、まずは私たちEM自身が理解を深めることから始めました。
その第一歩として選んだのが、名著『SCRUM BOOT CAMP THE BOOK』の輪読会です。
輪読会の中で、こういった点は大事だよねというポジティブな気づきも多かったのですが、スクラムの考え、実践方法を学ぶうちに、自分たちの現場に当てはめた時のリアルな疑問が次々と湧いてきたのです。
「実際に誰がどの”ロール”を担当するといいんだろう？」
「オフショアや業務委託のメンバーもいるし、兼任も多い。この体制でスクラムができるのかな？」
「そもそも、なんでアジャイル開発にするとうまくいくんだっけ？ 」
これらの疑問は、EM陣がアジャイル開発やより良い開発へ関心があるからこそ出てきたものでした。
そういった議論のなかで、EM内でも「なぜアジャイルを導入するのか」についての考えが一人ひとり異なり、共通の認識が持てていないことに気がつきました。
そのため、このままスクラムの学習や実践に進んだとしても、大きな効果は得られないかもしれないと感じました。
「How（やり方）」を学べば学ぶほど、「Why（なぜやるのか）」という土台の重要性が浮き彫りになってきたのです。
この根本的なもやもやを解消しない限り、前に進めない。それが、私たちの共通認識でした。
※ここで「How」と表現しましたが、これは『SCRUM BOOT CAMP THE BOOK』に方法論しか書かれていないという意味ではありません。本書でスクラムを学ぶなかで、「そもそも、なぜ自分たちのチームにアジャイルが必要なのか？」という根本的な「Why」の議論が不足していることに気づいた、という文脈で用いています。
3. 共通の認識を手に入れるために。「Why」を見つける勉強会で話したこと
そこで、自分自身過去にアジャイル、スクラムを推進、実践してきた経験があったので、スクラムについてのインプットだけではなく、アジャイルの「Why（なぜやるか）」を考えるための勉強会を始めました。
輪読会で出たような疑問の答えは、どこかのやり方をそのまま真似したら解決するわけではありません。自分たちのチームが「どんな状態を目指したいのか」「何を大切にして開発を進めたいのか」を定義し、そのためにアジャイルや周辺領域の考え方をどう活かすかを考えることが不可欠です。
以下は、勉強会で扱ったテーマを、皆さんのチームでも使える「問い」の形でご紹介します。
各テーマについては深く扱った記事などがたくさんあると思いますので、気になったものは調べながら自分のチームだとどうかな？というところを考えてみてください。
【問い①】不確実性にどう向き合うか？
ソフトウェアの開発は不確実性がとても高い領域にあり、最初に立てた計画通りに進まない可能性の方が高いです。
では、どのように計画や見積もり、日々の開発を行うと良いでしょうか？
変化を前提とし、それに素早く適応することで顧客価値を最大化する。これがアジャイルの根幹です。
そのためには、動くソフトウェアを短いサイクルで作り、多くのフィードバックから学び、そこから価値につながるように改善していく必要があります。
勉強会で実際に出た話題：一見明確そうな要求の中から不確実な部分を見つけていくにはどうしたらいいのか？
- 「お客様、営業、企画、開発チームではそれぞれ視点が異なり、特定の人だけでは気づけない部分がありますよね」
- 「開発チーム内にインフラなど各領域の有識者がいない場合、どのように連携するか、あるいはチーム構成そのものをどう考えるべきか」
といったように、議論はチーム設計の話にも広がりました。
どのようにしたら事前に気がつけるか、フィードバックを得やすいかというのも大切なポイントになります。
【問い②】本当の「自己管理型チーム」とは？
スクラムでは、チーム自身が計画を立て、実行し、改善していく「自己管理」が求められます。
あなたのチームでは、「どうしたらいいですか？」ではなく、「こうしませんか？」という声が、役職に関係なく誰からでも上がっていますか？
そのためには、リーダー・マネージャーからチームへ適切な権限・責任の移譲が行われていることが絶対条件になります。
権限・責任の移譲とは「丸投げ」ではありません。適切な権限・責任の移譲はできていますか？
【問い③】私たちはどこへ向かうのか？（プロダクトゴール）
チームが自律的に動くためには、共通の目的地が必要です。
「私たちが作っているプロダクトは、〇〇という価値を顧客に届けるものです」と、チーム全員が同じ説明ができますか？
明確なプロダクトゴールが、日々の開発や迷った際の拠り所になります。
【問い④】まずは「知る」ことから始めよう（透明性）
問題を発見し、改善するためには、チームの状態を誰もが理解できる状態、「透明性」が欠かせません。
チームメンバーのAさんが言う「このタスク終わりました」と、Bさんが言う「終わりました」は、全く同じ状態を指していますか？
自分のタスクは終わったけど、他の人のタスクはわからないという状況になっていませんか？
「完了の定義」を合わせたり、お互いの状況を理解しやすい仕組みを作ることは、透明性を高めるために重要なことです。
この状態を作った先に、助け合いながらチーム一丸となってゴールを目指すという状況が生まれてきます。
勉強会で実際に出た話題：デイリースクラムで工夫していることはある？
- 「司会を持ち回りにしてはみたものの、うまく質問を引き出せないと、単なる情報共有で終わってしまい対話が生まれないことがあります」
- 「ただ進捗を聞くのではなく、こちらから問いを投げかけてチームで一緒に考えられるようにしています」
- 「『ゴールに向けて協力し合う必要がある』という意識づくりも大切ですよね」
といった工夫や意見が交わされました。
仕組みを作るだけではなく、継続して積み重ねていくことも大事になってきます。
【問い⑤】安心して失敗できるチームになるために（心理的安全性）
良いプロダクトは、健全な議論から生まれます。
あなたのチームには、「そのやり方、もっと良い方法があるかも」「この仕様、本当にユーザーのためになる？」と、安心して言える雰囲気はありますか？
仲が良いことが心理的安全性が高いチームではありません。
何を言ってもこのチームなら受け止めてもらえると思える状態であれば、価値を最大化するために活発な議論がチームから生まれてきます。
とはいえ、議論が生まれる前には雑談ができるなど会話しやすい状況も必要になってきます。
勉強会で実際に出た話題：チーム内では活発な議論ができるが、より広い範囲（チーム外）に広げていくためにはどうしたらいい？
- Slackでの広い範囲での雑談とかができるといい？でも広い範囲では話しづらいとかあるよね
- チーム内だとモブプロとか、勉強会で話す場が増えて、話しやすくなった。
- 雑談したくないという人もいるよね
- 雑談をしようという目的の場ではなく、モブプロしよう、技術の話をしよう、など別の目的も持ちつつ、実は雑談も目的でしたというのも良いと思う
仕組みを作ること、日々の取り組みの中で話す場を増やすこと、どんな人がいるのかなども含め、様々な工夫の仕方がありそうです。
4. まとめ：アジャイル開発のはじめの一歩は、「対話」から
アジャイル開発やスクラムは「銀の弾丸ではない」とよく言われるように、導入すれば必ず成功するわけではありません。
その効果を最大限に引き出すためには、手法を導入する前に、チームとしてのあり方を定め、「なぜやるのか」を対話し、共通の認識を得ることが不可欠です。
私たちもより良い開発をするためにはという点で、この勉強会や様々な取り組みを通して「どのような開発を目指していくのか」をディスカッションしていく予定です。
もしこの記事を読んでくださっている方の中に、これからアジャイルやスクラムを始めようとしている方や、導入してはみたもののうまくいかないと感じている方がいらっしゃれば、ぜひツールやプラクティスを導入する前に、チームで時間をとってこの問いから話し合ってみてください。
「私たちは、開発を通じてどんな状態を目指したいのだろうか？」
最後に、スパイダープラスでは仲間を募集中です。スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。ご覧いただき、ありがとうございます。
