#Agile はじめてのアジャイル開発がおわった

はじめてのアジャイル開発がおわった。

毎日続けてきたスタンドアップミーティングは、1日15分程度ながら一番効果が大きかったように思います。

チームで仕事をすること、そしてその要である「コミュニケーション」は、会話なしに成り立たないことを改めて痛感しましたし、プログラムが「思った通り」に動かず「書いた通り」に動くように、プロダクトもまた「思った通り」に出来上がらず「話した通り」に出来上がることも思い知らされました。

マラソンであれば、ゴールに向かって走っていれば全員同じ場所にたどり着くことができますが、ソフトウェア開発というものは、ただ闇雲に走っていると、ゴールだと思っていた地点がみんなバラバラだった。なんてことがあり得るわけで。

タイムスパン毎のゴール設定はチームに張りと達成感を与える

人生においても、1日の目標、1年の目標、10年の目標と、タイムスパン(期間の長さ)によって答えが変わるように、同じゴールでも、期間ごとにそれぞれのゴールを設定することを常とするアジャイル開発は、チームに「張り」と「達成感」を与えてくれました。

「6ヶ月で家を建てる」という仕事を例にすると、

  • 長期ゴールは「6ヶ月で家を建てる」こと。
  • 中期ゴールは「1か月で骨組みを完成させる」こと。
  • 短期ゴールは「2週間で土地購入/建築業者に発注する」こと。

となります。

ここで、ゴールが「6ヶ月で家を建てる」しか設定されていなければ、土地を買う前に「あたらしいベッド」が届いてしまう危険すらありえます。

これは極端な例ですが、「やらなければならないこと」「できないこと」、「今やっても意味が無いこと」を考えておくことの重要性はアジャイル開発から学びました。

ソフトウェアは柔らかい=変わるもの

アジャイル開発では、「プロダクトバックログ」と呼ばれる「製品に必要な要件一覧」を作ることから始まります。

そして、この一覧は「常に最新の状態に保つ」ことが推奨されています。

要件は変わります。

それは、使う人のためかもしれませんし、作る人のためかもしれません:p

スタート地点で作ったゴールへの地図は、2週間後には地獄への入り口に変わる可能性があることも意味します。

怖いですね。

"if"を"畏怖"と誤変換しそうですね。

このプロダクトバックログを見直すタイミングは、どこが最適なのでしょうか。

私たちは、短期ゴール(2週間)を1区切りとして、全体で打合せをおこないながら、プロジェクトの優先順位や、要件を再確認し、調整してきました。

地図のアップデートです。これは非常に大きな効果をもたらしました。

頭の中で考えていた「必要なもの」は、実際に作り始めてみると「そんなに必要じゃないな」とか「時間をかける割に魅力が少ない」だとか「作れねーよ:(」とか、わかり始めます。

そんなとき、要件の優先度を下げたり、不要なものを削除したり、もっと魅力的な機能を追加したりすることで、プロジェクトをより良い状態に保てました。

2週間という区切り

2週間、実働日数だと10日。

これをひとつの目安にプロジェクトに短期ゴールを設定しました。

つまり、

「10個の機能を作るのに必要な時間は?」という質問を

「10日で作れる機能は?」に変えたわけです。

100日後という先の見えないゴールが、10日後というイメージしやすいゴールに変わるこのコペルニクス的転回。

10日という時間でできることを、プロダクトバックログの中から自分たちで選ぶわけです。

期間を固定する「タイムボックス」という考え方が、開発者に「張り」を与えました。

小さな目的を何度もゴールする喜び

10日という限られたタイムボックスに入れる仕事は、ほどよいサイズに細分化されています。

1日で完了する仕事もあれば、5日間、または10日間かかる仕事もあります。

アジャイル開発での、タイムボックスに含める仕事の粒度は、1日で完了する(大きくても2日)であることが推奨されています。

1つの要件をタスクにうまく分割するのは、経験が必要だなと感じましたが、分割されたタスクは完了させるまでの期間が短く、完了させるたびに小さな達成感を与えてくれます。

この「小さな達成感」が、開発のリズムや、プログラマーのモチベーションを小さいながら向上させるいい働きをしてくれたように感じました。

タスクは、ポストイットに書き込まれ、ホワイトボードにすべて貼られて「Todo/Doing/Done」の状態で管理されていました。

取り掛かったタスクを、Todo→Doingに移動させ、

完了したタスクを、Doing→Doneに移動させるというアナログな行動も「完成に近づいている」という実感を与えてくれました。

Appleのブレストに学ぶアジャイル精神

Appleデザイナーのブレストはキッチンテーブルを囲んで──垣間見えた秘密の仕事場 (1/2) - ITmedia ニュース

Appleデザイナーのブレストはキッチンテーブルを囲んで──垣間見えた秘密の仕事場 (1/2) - ITmedia ニュース「われわれは常に疑い、常に疑問を持ち続けている」

「良いものができると"信じ"、常に"疑い"続けること。」

アジャイル開発を通じて、この言葉はアジャイルの精神をよく表しているのではないかと思います。

その一歩が道となる

今回のプロジェクトが私にとっての初アジャイルだったわけですが、プロジェクト初期に勇気を出して「アジャイル開発を試して見ませんか」と提案してよかった。

アジャイル開発もプログラムのように「思った通り」に進みませんでしたが、人生だって同じ「やってみなくちゃ始まらない」んですから、始めたいけど悩んでいる「むっつりアジャイル」な方は、飛び込んじゃいましょう。

ただ、やると決めたら全力で。

完璧じゃなくてもいいから、全力で。

全力で取り組んでいないのに「向いてない」「できなかった」と判断するのは、何においてもいけません。

最後は上から目線になっちゃいましたが、たった1回のアジャイル開発は、猫を獅子に変えるくらいのインパクトがあるということで大目に見てください。

次回以降のプロジェクトもアジャイル開発していきたいので、これからもう一度復習の意味を兼ねて色んな資料を読み漁りたいとおもいます。

Enjoy!Agile