アジャイルのための第一歩に僕が選んだこと - アジャイルジャパン2012富山サテライト
3/16にアジャイルジャパン2012が開催されました。本講演は今年は大阪会場で、大阪以外にも各地でサテライトが開催されました。僕は富山サテライトで参加です。
セッションのテーマ
僕のセッションのテーマは今の開発現場にどうやったらアジャイルを組み込めるか？ということです。タイトルは「できるアジャイル」
アジャイルをシステム開発の現場に導入するにはいくつか壁があります。とくに受託開発をしている現場に導入する場合、「契約」という大きな壁が立ちはだかります。いち開発者という立場でこれに立ち向かうのはさながらドン・キホーテのように思えるかもしれません。
これをどうにか一歩アジャイルに踏み出すにはどうしたらよいかという話をしました。
アジャイルとは何ぞ？
アジャイルとは何か？これを改めて問うてみましょう。アジャイルの原典というとアジャイルソフトウェア開発宣言です。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
http://agilemanifesto.org/iso/ja/
認めながらも、私たちは右記のことがらにより価値をおく。
これが、アジャイルです。アジャイルというのは思想なんですね。価値観なんです。そしてこの価値観を実践するための方法論がアジャイルプロセスなんです。アジャイルが目的でアジャイルプロセスが手段。
なので、プロセスばかりに注目して導入してもそれはアジャイル足りえません。アジャイルという目的を持たないでプロセスだけ導入してもダメなんです。
アジャイルをアジャイルしよう
僕がまず強調したのはアジャイルを取り入れることを一気にやろうとしないこと。ウォーターフォール的にアジャイル開発できる開発チームを作ろうとしたなら、その過程がアジャイルではない。ハードランディングはダメです。開発ができる状況を維持しつつ変化を取り込んでいきましょう。
そして、そのための第一歩として僕がチョイスしたのは「お客さんに動くソフトウェアを触ってもらう」ということです。
とりあえず、第一歩としてコレだけをまずやろう、という話です。
どのように触ってもらうか
一括受注している場合、途中で勝手にプロダクトとしてモノをリリースするというのは都合が悪いんです。最初からそういう契約になっていればまだしも、一括受注している場合、見積をして、発注が来て、設計をして、開発をして、テストをして、納品して、検収してもらって、そして初めてお金が払われるわけです。
この契約の流れを変えるというのはいち開発者には難しいことでしょう。
ですから、とりあえず、プロダクトではなくプロトタイプという体でモノを触ってもらうというのを努力目標としました。あくまでプロトタイプですよという建前ですね。これは大人の事情というか、方便のようなものですが、まずはそれでもいいのでお客さんに触ってもらう。触ってもらってフィードバックをもらう。これをアジャイル導入の第一歩としました。
変化への対応
変化への対応について、強調したのは「お金は請求してください」ということです。お客さんが追加でこういうことをしたいという分には、無料で対応するわけではなく「これぐらいの費用がかかりますね」という話をして下さいということを言いました。
なぜか。じゃないと会社が許さないからです。僕らは霞を食べて生きているわけではないので、タダ働きするわけにはいきません。お客さんが価値あるソフトウェアを作るために僕らに追加の仕事を依頼するなら、当然、仕事の報酬を請求してください。
追加の依頼が有償であるなら、そしてその報酬が妥当であれば、会社は変化を受け入れることに反対することはまずないでしょう。アジャイルの精神を取り入れるために、報酬の心配をしなくていいようにしましょう。
落とし穴
変化への対応をするのはいいのですが、お客さんが仕様変更するに至った経緯をちゃんと記録しましょう。これは歴史書として流れが見えるようにまとめる必要があります。
それは堂々巡りを避けるためでもあり、あるいは不当に瑕疵であると言われないための予防線でもあります。未来への議論のために過去の流れを残しておきましょう。さもなくば、往々にして過去にやった議論を再度蒸し返して無駄な時間を費やすことになります。目的はあくまで未来の議論のためです。
