崖っぷちの男

たぶん技術っぽいネタ。ブログ名が決められない

今さらアジャイルに触れ始めた俺が読んでみた『Head First ソフトウェア開発』

 結論からいうと、「俺もアジャイルな開発やりたい ! …でも環境的に難しい。…それでも参考にできることはあるはず 」です。




 最近 twitter で「もっとチームで仕事がしたいなー」みたいなことを呟いたりしていたのですが、その理由はアジャイルソフトウェア開発」というやつについて知り始めたからだったりします。


 「アジャイル」や「XP」「スクラム」といった言葉や、一部の「プラクティス」と呼ばれるものはネットで見かけたりして知っていたのですが、かなり断片的な知識しかありませんでした。そんな中、XP祭り2011 というイベントがあることを知りました。




 XPが何なのかも知らない素人が「XP祭り」に行くのもどうかと思いましたが、「これをきっかけに知っていけばいいか」と思って敢えて行ってみました。結果…やっぱり知らないことが多すぎて、正直ついていけないところがありました。一方で、自分は知らないけど XP 関係の人なら常識のこと、というのが何となく分かりました。


 また言葉は知らなくても、ビジュアル的に興味を持てるセッションや発表がありました。自分が印象に残ったものをとりあえず 2 つだけ挙げます:

三周まわったおれたちのアジャイル

@kwappa さんのセッションのスライドです。21ページ目から写真が出てくるのですが、dwango さんの色々なチームで行なわれているアジャイルなプラクティスの紹介になっています。単純に dwango さんの社内がおもしろそうなのもありますが、実際に使われているホワイドボードの写真なんかが出てきて、何かよく分からないけどおもしろそうな気がしました。

タスクボード観察日記 / XP祭り2011 LT動画 - Taskboard Retrospective - YouTube

 @daipresents さんの発表で、楽天さんのあるプロジェクトで使われたタスクボードの変化をひたすら撮った動画です。これも正直見たときはよく分かりませんでしたが、何となくおもしろいなーと思いました。


 こういった実際の現場を写したものを見ると、ちょっとアジャイルが身近なものに思えてきました。




 それからしばらくして、図書館で手に取ったのがこの本でした。


Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本

Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本


 この本はよく考えたらセッションなどで紹介されていた気がするのですが、その時はすっかり忘れていました。この本をぱらぱらめくった時、「あ、これアジャイルな開発のやり方を解説した本やん ! 」と思いました。

この本のいいところ

 この本がおもしろいのは、「アジャイルな開発の本です」とは全く書いていないところです。「ソフトウェア開発の手法とはアジャイルな開発のことだ」と言っているかのようです。


 全体としては架空のプロジェクトについて、架空のチームメンバーたちと一緒に自分も学んでいくといった形の本になっています。エクササイズも多く、見積りをやったり、Javaのコードを書いたりします。おもしろいのは「エクササイズは飛ばさないでちゃんとやれ」と書いてあることです。手を動かさなきゃ頭に入らないということです。また本によってはどこからでもリファレンス的に読める本、というのがあったりしますが、この本は最初に「途中から読むのでなく、最初から通して読まないとダメ」と書かれています (まあテスト駆動開発のとことかそこだけ先に読んでも役に立ちましたが)。


 扱っている内容は広く浅くという感じで、ユーザーストーリーを作るところから、見積りをしたり、ストーリーをタスクに分けたり、ホワイドボードで現状の可視化をしたり、コードをリファクタリングしたり、テストコードを書いたり、ビルドスクリプトを作ったり、CIツールを使ったり、バグをとったりと一通りのことはでてきます。


 見積りについては、最初の要件では期限に間に合わず、人を増やしても間に合わないだとか、途中で客から急に仕様の追加を頼まれるとか、ある程度「あるある」な内容が書かれていてそれなりにリアルです。

この本のよくない所

 Amazon の評価にも書かれているんですが、誤植が多い気がします。見積りの計算の練習問題で「これ答え間違ってない ?」ってやつがあったり、クラスの図で同じクラスが複数存在したりで何でこのミスに気付かなかったの…と思うレベルのミスがあります。ミスは仕方ないとして、訂正を載せたWeb上のページがないのが痛いです (あったらごめんなさい…) 。このせいもあってか、この本の日本のAmazonでの評価は5つ星中2つ星です (レビュー2件) 。ちなみに原本はアメリカのAmazonで5つ星中4.5、レビュー数は22件です。

アジャイル開発について思うところ

 まずおもしろいと思うのは、「細かい仕様は固めずに開発してしまう (設計を繰り返す) 」ところ。「仕様はどうせ変わるんだから、変化に対応できるように作りましょう」というのはその通りだなと思います。客の本当に望んでいる仕様を開発前から100%固められるかといえば、不可能だと思います。「客自身が自分の欲しいものを把握できているとは限らない」というのもその通りで、実際とりあえず開発を始めて詳細はあとで、というのはよくある話です。そのため開発したものを都度、客に見せて確認をとっていくというのは合理的な話だと思います。


 ただし、上のようなことを実現するには、都度の見積りが欠かせません。アジャイルな開発では、途中での仕様の変更は OK だけど、そのかわりそれを行なうための工数や優先度をちゃんと確認して、変更するなら他のストーリー / タスクがこんだけ後ろにずれますよ、というのを客に分かってもらう必要があるみたいです。そのためには見積りまくらないといけなくて、そこに結構時間をとられるような気がします。


 そしてもっと現実的なところとして、客の理解がなければこの開発方法はできない、というところが壁になってきます。ストーリーを考えてもらったり、優先度をつけてもらうのも理解あってのことですし、客は客側でアジャイルで開発する会社に依頼するときにやっぱりアジャイルについて知っておかなければいけないと思います。


 そして自分に当てはめれば、多重請負の中で外注さんや一次請けの会社、一次請けの外注と連携する必要があり、本に出てくるような単純な客と開発会社の関係ではない、というところが問題になってきます。客とのやりとりは一次請けがやっている時など、本当の客とはコミュニケーションをとれません。外注さんに一部開発を依頼している場合は、タスクボードはもっと複雑になるような気がします。上で挙げた dwango さんや楽天さんは顧客が非常に近い上に自分たちで開発しているからこそアジャイルな開発ができているんだと思います。


 でも、じゃあ無理だよね、で終わるのはもったいないと思いました。参考にできるところは色々あるはずです。


 プラクティスについて、社内でタスクの状況を可視化したり、朝夕の短いミーティングあたりは開発会社であろうと客と開発の間にいる会社であろうと可能ですし、役に立つと思います。コーディングについていえばテスト駆動開発やビルドスクリプト、CIツールも普通に役立ちそうです。


 客がストーリーや優先度をつけてくれなくても、こっちから作って見せて確認をとることならできないことはないです。またリリースについて、客がいちいち確認しないとしても、いつでも動くものが見せられるようにしておく、というのは開発者にとっても安心して開発ができると思います。


 そして何より、客への姿勢として「客が望むものをできるだけ作れるよう努力する」というところを参考にできればいいだろうなと思います。もちろん、最初に仕様を固めて、「仕様変更するなら追加で金がかかります」というのが自分の会社のとりあえずのお金にとっては間違いなくいいとは思うんですが、「最初に仕様に入れてなかったからできませんよ ? 」「今さら変えてなんていっても遅いですよ ? 」と客に言い続けるのは何だかなあという気がします。最終的に、とりあえず会社のお金を守るのか、それとも客の印象を良くしたり、信頼を得るんだったらどっちがいいのか、やってみないと分からないことだなと思います。自分としては、みんなができるだけ満足できるようなものが作れたらいいな、と思うので、アジャイルの考え方を参考にしたいです。




 いつになくだらだらと書いてしまいましたが、とりあえず『Head First ソフトウェア開発』はおすすめできると思います。アジャイルのことはまだちゃんと分かっていないし、アジャイルって書いてるけど XP についての話をしてたりするかもしれませんが、そこら辺はまた勉強していきます。