Sasuke Financial Labにおいて、初のスクラム開発をした一年。
スクラム導入前後の定量的比較をしたかったのですが、そもそも数値としてのデータが残っていませんでした。
スクラム以前からプロジェクトに参画していたメンバーに限り、前後でどう変わったかを定性的に調査するため、アンケートしてみました。
元々少ない人数＋メンバーの入退もあり、エンジニアが一名、企画系が3名、デザイナーが2名という構成になりました。
(なお、チームはエンジニアだけでなく、企画デザインエンジニア全員でスクラムをやってきました。)
偏りがあることはご承知おきください。
人生初の真面目なアンケートで、恣意的な設問になってないだろうかなど、不安なところもありますが、ぜひ見てみてください。
アンケート結果の前に前提資料から
アンケートの目的
スクラムを導入し、以前の「開発が進まなかった状態」は改善した現在(マスター視点では改善を感じている)。
その効果を確認するアンケートとして実施。
スクラムに期待した価値：
開発ルールの敷設とコミュニケーション改善によって、開発が前へ進行するようにしたい。
作業手戻りをなくしたい。開発進行のルールがないので作りたい。
チームメンバー各人が他部署とも話しやすい状況をつくり、全員が同じ情報にアクセスできるようにしたい。
スクラム導入以前の状況
- 他部署の仕事内容を互いに理解できていない
- 部署を超えたコミュニケーションが薄い
- ゆえに実装が手戻りし、前に進まない
- コミュニケーション/開発がうまくいっていないことは各部署が問題と自覚していた
- 全体を取り仕切る人(マネージャー、ディレクターなど)が不在、音頭とる人がいない
- 採用するにも時間がかかるため、現在のリソースからそこにあたる人材をアサインする必要があったが、適当な人物がいない
- 開発進行に関わる明確なプロセス、ルールが存在しない
- PLと企画のみでクローズに開発方針が決まり、一部のメンバーがそれぞれ断片的に情報を持っている状態
- 開発ゴールが曖昧/今後の開発ロードマップが不在
アンケート結果
スクラム導入前と比較して、現在は仕事がしやすくなったと思いますか。
1:仕事しづらくなった 9:仕事しやすくなった
結果： 全体で以前よりも仕事がしやすくなったと回答。
- 要件定義の時間が短くなった。
- 要件が確定していなくてもデザイン、コーディングで進行できることが増えた。
- 2週間を区切りにしてスケジュール管理ができるようになった。
- ルールが明確になった。
- ベロシティが縛りになってやりづらい部分がある。
- 部署を跨いで一つのゴールを設定できるようになった。
- 部署を跨いで共通認識をもつためのツールができた。
- 問題点を挙げやすくなった。
- エンジニアだけが認識していた「開発のコスト感」がプロジェクト全体に共有された。
- プロジェクト全体の方針、タスク量、優先順位がわかりやすくなった
手戻りについて。現在はどのくらい変わりましたか
1:少なくなった 9:多くなった
結果： 半数以上が少なくなった一方、かわらない、むしろ増えた人も。
- 手戻りが発生した際にも、都度、依頼や修正することに抵抗が少なくなった気がする
- 初めから関係者全員の合意を取りに行く考え方が身についた
- 手戻りは減ったが、要件が曖昧なところはそのままなため、作業は減っていない印象。
- 要件決めの議論から先に進まないという事態は減った。
- mtg時間が減り、作業時間が増えたため、手戻りがあった場合でも対応できるリソースは増えた。
- 仕様確定の合意以降は手戻りが少なくなった。
- 仕様確定までのフローは増えた。
🧑💻 開発の早い段階からの合意形成意識の向上や、プロジェクト全体の合意を都度とることで、作業が前へ進行するようになったといえる。
企画〜実装まで、計画の進行はどのように変わりましたか。
1:遅くなった 9:速くなった
結果： 変わらない、少し速くなったが半々
- 以前に比較して計画・段取りができるようになった
- 計画に時間をかける分、実作業時間が減少。やや速くなった感触。
- 要件定義の時間が減って、少し速くなった。
- 要件未確定のまま進むこともある点については改善が必要。
🧑💻 進みはあまり変わらないが、時間配分が変わったという意見が多い。
開発上の問題の発見頻度はどう変わりましたか。
1:少なくなった 9:多くなった
結果： 多くなったが半数以上、少なくなった人も
開発上の問題の解決速度はどう変わりましたか。
1:遅くなった 9:速くなった
結果： 全体で解決まで少し速くなった
以前に比べ、情報の透明性はどう変わりましたか。
1:見えづらくなった 9:見えやすくなった
結果: 変わらない方が少数、大半が見えやすくなった
- チケットで回す意識が向上した
- 進捗が見えやすくなった。以前は見えづらかったため、進捗が気になっても確認できなかったが、それも少なくなった。
- あまり変わらない。
- タスクは見えるので誰が何をしているかよく見えるようになった。
- タスク処理のための情報が足りないためにコミュニケーションロスが発生している気がする。
- 会議時間が減って、作業リソースをとれるから、コミュニケーションロスがあっても吸収できている。
- 同じチームの人が何をしているか、Backlogを参照すると把握できるようになった。
🧑💻 情報の透明性が上がり、問題の発見頻度は向上。発見した問題に対しての対処速度も少し上がっている。
他部署とのコミュニケーションの質は変わりましたか？
1:悪くなった 9:良くなった
結果： 全体で「良くなった」
開発を進める上で、他部署の人と意見が対立することはありますか。
1:無くなった 2:頻発している
結果： あまり変わらない/少し増えたが半数以上。少なくなった人も
他部署とのコミュニケーション頻度は変わりましたか。
1:減った 9:増えた
結果： コミュニケーション頻度は全体的に高まった
コミュニケーション頻度が変わった結果、内容についてはどう変わりましたか、詳しくお聞かせください
ex: 意思疎通ができるようになった、意見が対立するようになった、タスクや課題の見落としが減った/増えた、変わらなかったetc
- 意思疎通ができるようになった
- 素早く問題が解決するようになった。
- 何かを始める前に事前に相談できるようになった。結果、行き違いと手戻りが減少した。
- 他部署との相談が増えた結果、仕様の決定が速くなった。
- 相談しても要件が噛み合わないことは依然起こる。
- 要件定義が曖昧なために発生するコミュニケーションは減り、すり合わせとスクラムイベントにおけるコミュニケーションは増えた。
- 対立ではなく、交渉/すり合わせの時間は増えた。
- 合意をとりつける時間ができたので、増えたのは悪いことではないと感じる。
🧑💻 全体的にコミュニケーションは増えた結果、意思疎通ができるようになり、開発の進まない無駄な時間が減少している様子。
他部署の仕事に対する理解度は変わりましたか
1:よりわからなくなった 9:理解が深まった
結果： 全体的に大きく理解が深まっている
- 立場上、知らなくてはならないことというスタンスで理解を深めた。
- 関わりの少なかったカスタマー部門などからデータをもらうことが増えた。
- 他部署の内容がわかるようになった故に、忙しい時には協力することが増えてきた気がする。
- タスク量が把握しやすくなった
🧑💻 コミュニケーション頻度と合わせ、他部署の仕事進行に対する理解が深まっている。
その他、スクラムについて変化したこと、気づいたことなどあればお聞かせください。
- スクラム(イベント？)のためだけに使うコストを減らしたい。作業者負荷が高めと感じる。
- 2週間を区切りとすることで、プロジェクトが前に進むようになってきている。
- プロジェクト全体で期日(2週間単位)の共通認識が生まれた。
コのほけん！PJのスクラム開発における改善点や要望を教えてください
- ツールとしてスクラムが存在するが、プロジェクト的な視点が欠けているように見える。
- スクラム中心の進行がすこし面倒に感じることもあった。
- 今よりもチームの人数を減らす方がうまく行く気がする。ミーティング時間やコミュニケーションの複雑さを減らしたい。
- スクラムとしては人数が多い。少数に減らしたい。
- プロジェクトが進むにつれて、何を実行したいかが曖昧になっていく傾向があるため、その点をフォローできる仕組みが欲しい。
- 顧客視点の価値でなく、早期のリリースが目的になることが多い。
🧑💻 全体的に、小さい単位でのチーム分け・開発進行を望む声が多い。これまでの仕事で、コミュニケーションコストを減らすのは良い結果を生み出せるという実感を得られているものと思われる。
ここまでマスター一年やってきての感想
スクラムマスターの視点としては、スクラムルールの適切なコーチングは、完璧にはやりきれなかったと感じています。
しかし、以前の分断されたコミュニケーションは改善し、現在は部署を超えたコミュニケーションが頻繁に行われています。
この一年「情報を持った人に話を聞けば、相談すればわかる」ということを、メンバー全員が強く実感したはずと感じています。それは、一年間に25回以上行ってきたレトロスペクティブの中で、メンバーそれぞれから何度も出た「コミュニケーション不足」の言葉からも明らかで、そこから出た改善施策こそが、現在のコミュニケーション頻度に現れていると私は思いました。
コミュニケーション不足が解消し、合意形成できれば、それで開発は進んでいくことができたわけです。
スクラムのルールの設定も効きましたが、チーム全体に方向性を示し、牽引する人がいるかという点、そここそが重要だったと感じています。
その点では、少々強引ながら、全てのチームメンバーを巻き込んで、一つのルールで進行したという点だけは少なくとも良策だったのではないかと、自分としては捉えています。