SimpleBoxes

アジャイルソフトウェア開発・スクラム会議導入に対する経過観察

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~うちの会社では、ソフトウェア開発にアジャイル的な手法を取り入れています。

その一環という訳ではないのですが、半年ほど前から私のチームでは、毎朝 10 分程度の立ち会議、いわゆる「スクラム会議」を行っています。

まだ導入して半年。その効果を評価できる段階にあるのかどうかは、正直なところ分かりません。とりあえず、今のところ、うまく回っているような感じです。

スクラム会議では……

  • 前日 (前回のミーティングから) やったこと
  • 今日 (次のミーティングまでに) やること
  • 障害になっていること

参加者全員が順に報告しあいます。厳格に持ち時間を決めていませんが、一人 5 分以上話すことは非常にまれです。

私の個人的な印象では、スクラム会議のポイントは「情報の共有」にあるのではない感じがします。

もちろん、情報の共有という側面もあります。詰まっている (障害になっている) 部分を早くに把握でき、迅速なバックアップにつながる場面もあるでしょう。

ただそれよりも、やったこと・やることをアウトプットする習慣がつくようになるというのが、ポイントではないかと個人的に感じています。

「スクラム会議」という名目で、各人が「今日はこれをやります」と他の参加者に対して宣言するわけです。これは一種の強制力として働きます。

やったことを報告することで、各人に進捗度合を認識してもらう効果があります。それ自体も重要なポイントになりますが、進捗度合いを認識することで、今後の作業の見積りがより正確になるという効果が期待できます。

先にも言ったとおり、評価できる段階にあるのかはまだ分かりませんが、とりあえず、今のところ「スクラム会議」には好感触を持っています。ただし、チームサイズが大きくなっていると破綻する可能性が高いような気もしていて、そこら辺は今後の課題といったところでしょうか。

大人数になってきたら、一人当たりの持ち時間を厳格に制限したりなどの工夫が必要になってくるかもしれません。

このエントリーをはてなブックマークに追加

スポンサーリンク

<< Xcode 4 の導入と Xcode 3 との併用 :: お疲れ…… >>