XP祭りでアジャイルについて考えたこと
9月6日に「XP祭り2014」というイベントをのぞいてきました。
「XP」といっても「Windows XP」ではなく「eXtreme Programming」の方です。まあ、Windows XPでお祭りやりたいエンジニアはいないでしょうが(←XPの絶滅宣言が出たらお祭りやりたいって人はいるかもしれん)。
こういったイベントにはほとんど参加したことがないんですが、知人に「こういうイベントがあるよ」と教えられて、サイトをのぞいてみたら、アジャイル開発に関する講演があるということだったので、ちょっと興味が湧いたので出かけてみました。
アジャイル開発に関してはちょっと興味があって、何冊か本を読んでみたんですが、「やり方としてはものすごくおもしろそうだけど、本当にうまくいくのか?」という疑惑しか浮かばなかったんですよ。わたしはマネージメント方面の仕事をやったことがないので、それを実際に切り盛りする難易度を見積もれないんですね。
で、それを実際にマネージメントしている方のお話がうかがえれば、もうちょっと何かがつかめるのかなあ、という期待を抱いて出かけたわけです。
なぜ、そんなにアジャイル開発というものに興味があるのかというと、ウォーターフォール育ちなわたしは、それで失敗した例をいくつもみてきて、でも、それはウォーターフォールだったから失敗したのか? という疑問を持っていて、その解に対するひとつの手がかりとして、アジャイル開発に興味が向かったわけです。
「だったらどうすればよかったの?」というのは、答えが出ない疑問だとはわかっていますし、それを考えたところでどうなるものでもないんですが、なんとなく気になっていたというか、ちょっとしたひっかかりがあるというか……。
さて、当日、わたしが聴いたアジャイルに関する講演は以下のふたつです(リンク先は2つともSlideShareです)。
・鈴木雄介さん「アジャイルを手放して得られたこと」
・倉貫義人さん「なぜアジャイル開発はうまくいかないのか?」
実をいうと、このふたつのスライドを紹介させていただくだけで、このコラムの目的は十分に果たせているような気がするので、文章が長すぎだろ、と思う方はここらへんでUターンをお願いします。
倉貫さんが講演の中で「なぜアジャイルは失敗すると思いますか?」という質問を投げかけていらしたので、講演の感想の前に、わたしのアジャイルもどきな体験談をさせていただきます。
■ ■ ■
以前、アジャイル的な開発をしたことがあります。なぜ、「的」なのかというと、本人たちが「アジャイルしようぜ!」と誓い合ってそういうことをはじめたわけではなく、なんとなくそういうやり方になった、というだけのことなので、「アジャイルやりました!」というのが気恥ずかしいからです。
そのアジャイルもどきの仕事の進め方は、
1.お客様との折衝役のSEが週に1回、客先にうかがい、モックアップをみせたうえで、要望をきいてくる
2.SEとわたしが、要望を呑むか、方向性を変えてもらうよう頼むか、蹴りだすかを検討する
3.わたしが次回打ち合わせにみせるためのモックアップをつくりつつ、仕様が決まった部分のつくりこみをする
4、SEは客先に提出する用のドキュメントをつくりつつ、全体設計を練り直しつつ、インフラまわりを整備しつつ、その他いろいろやってる
5.1に戻る
ものすごくおおざっぱにいうとこんな感じでした。
このやり方はまず、客先の担当者さんが週に1回の打ち合わせにきっちりつきあってくださる、というのが前提です。これがまずハードル高いです。わたしが知る限り、そういう担当者さんはめずらしいです(苦笑)。
というわけで、つきあってくださるだけでも大変にありがたいお客様ではあるんですが、これがまあ、仕様がやたらぶれます。「やっぱり3週間前のあれの方がよかったかな」というのがざらに発生します。で、「3週間前のあれ」は「1週間前に決めたあれ」と仕様的に衝突したりします。「そこをなんとか」と言われてSEが帰ってきて、どうすれば両方を成り立たせることができるか、でふたりで頭を抱えます。知恵を絞りあってそこをなんとかした解決案を持って参上すると、「やっぱり今のままでいいや」とか言われるわけです。
個人的には、そうやってぶれてしまう心情は理解できるんですよ。システムってのは高いですし、出来上がったシステムの出来は担当者さんの社内での評価に直結しますし、ものによっては会社の収益まで左右させてしまいますから、そう簡単には妥協できませんものね。
でも、プログラマとしては、そうやって仕様がうろうろし続けると、本当に疲れるし、ヘコむし、コードが荒れます(←荒れたコードについては仕様が確定した後でリファクタリングの時間をもらうことで解決しました)。
あまりにも仕様変更が激しかったので、SEさんに「いつひでみさんがキレるかと、内心はらはらしてた」と言われました。うん、本当はキレたかった(笑)。
それでもわたしがキレなかったのは、「こんなシステム使えない」と言われたくなかったからです。
その言葉を聴きたくないがためだけに、わたしは仕様変更につきあい続けました。
結果として、営業サイドから「お客様から不満も不具合もあがってこないから、追加の儲けがまったくでてこない」という、ありがたいお言葉を頂戴したシステムができあがったのでした(←お客様に不満を抱かせた方が儲かるというのも不思議な話ではある)。
というわけで、個人的には「がんばってよかった」と思える仕事でした。ですから、これは失敗例ではなく成功例の部類でしょう。
しかし、このやり方は正直しんどい、と思いました。1週間ごとに締め切りがやってくるようなものですから、休むまもなく攻め立てられている気分になってきます。これは、お客様を含めたメンバー全員が自主的にがんばらないと、いろいろと破綻するな、というのが正直な感想でした。
ウォーターフォールはある意味、プログラマは流されていればいいわけですから、「自主的」にがんばらなくてもいいわけです。まあ、「無理やり」にがんばらされますけど、がんばらされる分には「給料もらってるから仕方ない」程度のモチベーションで十分です。
だけど、みんなが自主的にがんばる、というのはものすごく難しいことです。だって、複数の人間がいれば、必ず、がんばれない人やがんばりたくない人が含まれるものじゃないですか。最初のうちはがんばれてたけど途中で力尽きることもありますし。
全員がゴールまでがんばり続けられるだけの、システム開発に対する使命感とか、チームに対する愛着とか、そういったものが必要に思えて、もしそれが正解だとしたら、アジャイル開発というのはおそろしくハードルの高いやり方なんじゃないかな、というのが、わたしの正直な感想でした。
■ ■ ■
前置きが長すぎてすみませんでした。本題に入ります。
鈴木さんと倉貫さんのお話には、共通点があったように思います。
超意訳ですが、「アジャイルはただの道具。道具のために人を動かそうと思った時点で失敗する」ということです。
そして、「理想と現実は違うという現実を受け入れつつ、理想を現実化するための歩みを止めない、という覚悟がないとやってけない」ということです(←これまた超意訳です)。
アプローチの仕方は違っていても、つきつめれば目指すところは同じなんだろうか、と帰りの電車の中でお二方の講演について考えていたら、ある結論に達しました。
ものすごく簡単にまとめちゃえば、「ユーザーさんも、開発者も、みんなで幸せになろうよ! みんなで幸せになるために、みんなでがんばろうよ!」ってのを目指してるんだな! と(←超意訳から超結論に達した)。
なるほど、みんながこれを目指して、これにたどりつけると思うことができれば、みんなが自主的にがんばれますよ。
だって、みんな幸せになりたいもの!
お客様は使えるシステムが欲しいし、エンジニアは使えるシステムをつくった、と胸を張って言いたいんですよ。利害は基本的に一致しているはずなんです。でもそれがすれ違う。予算や納期の問題だったり、コミュニケーションの問題だったり、理由は様々ですけど、決定的にすれ違う。おまけにエンジニア間でもやっぱりすれ違う。
だから、すれ違うということを前提に、知恵を出し合いながら試行錯誤しつつ、なんとかみんなが幸せになれるルートを探そう! という理想を掲げるところからはじめようよ、と。そして、その理想が叶うのなら、ウォーターフォールだろうが、アジャイルだろうが、名前も付いてない何かだろうがかまわない、ということなんだろうとわたしは納得しました。
わたしはマネージメントという仕事にはほぼノータッチでここまでやってきたので、こんな能天気な結論が出せるんでしょうし、それを実行にうつすのがどれだけ大変かは、想像はできても実感はできません。
マネージメントで苦労されている方々にとっては、「気軽に言うな」って感じでしょうけれども、わたしはこの答えにたどりつくことができて、ものすごくうれしかったんです。
わたしは本が好きですけれど、ご本人の声でその経験や意見をうかがえる講演というものは、本よりもずっとダイレクトに伝わる何かがあるな、と思いました。それもひとつの収穫でした。お二人がものすごくお話しがうまい、というのもあるんでしょうけど。
ところで、気が付くと講演内容がまったく伝わらない文章になってますね。すみませんが、他にちゃんとしたイベントレポートを書いていらっしゃる方がいますので、そちらをお読みください(←丸投げ)。
最後に、XP祭りの主催者の皆様に感謝を申し上げます。とても興味深いお話しを聞かせていただきました。ありがとうございました。
コメント
仲澤@失業者
老人プログラマの仲澤です。
エクストなんたらもウォターなんちゃらも、
クライアントから要求されたことはありませんねぇ。
まぁ「やりたいようにやってくれ」って言われるのが普通。
とは言うものの当然ユーザー要望はインタビューします。
しかし、それを聞いて作るのは要件一覧ではありません。
実現される世界の「原理」を洞察してに文書化するわけです。
これを「経典」と言ったり「シナリオ」と言ったりします。
これを基にその他の設計文書やらプロトやらが作られるわれですね。
でも、作成された基本設計やらUI設計やらは1~2年でオワコン化します。
そこにはその点で可能なソリューションしか含まれないからですね。
問題なのは何年か後、現時点のソリューションを聞かせてほしい。
というユーザー要望があることです(忙しいので今はやめてくれって時に多い)。
「経典」には本質的な問題点と、理想的な解決方法が記述されているので、
結局生き残ってしまうのですね。