読者です 読者をやめる 読者になる 読者になる

アジャイルという教典を文化が壊す

Twitterでもブツブツ言っていたが、最近アジャイルのトレーニングを受けた。海外で。
参加してたメンバーは主にEU圏内とポーランド・ロシアあたりの人々で講師はアメリカ人。参加者はプロダクトマネージャからジュニアプログラマまで全員みたいな感じ。CTOもいましたね…
欧州と米では開発文化はかなり違っていて、一口に言ってしまえば欧州はプロセスがプロセスとして成り立たないレベルで自由なことが多いようだ。あんまりプロセス事態に興味がないかんじ。もちろん納期とかもゆるゆるでアメリカ以上にリリース日が遅れまくる。会社の人達は基本的なスキルは高いけど属人性を好むところがあり、いつまでたっても自分の手からタスクを離さない。情報の共有文化があまりない。コミュニケーションは基本口頭で、Skypeとかは使うけどあんまり好きじゃないようだ(これはいろんな国から来ているということもあるが、欧州人は基本的にあまり文字のコミュニケーションが好きじゃない。母国語が英語でない場合が多いせいだと思う)。

トレーニングではScrumとKanbanがメインだった。僕はウォータフォールからなかなか抜け出せない古い開発プロセスで開発を回している日本の会社ではScrumはわりと馴染みが良いかなと思っているが、ごりごりにピュアScrumをやろうとすると失敗するだろうなと思ってた。基本的にScrumってスプリントの部分ばかりフォーカスされて、その前のとこは?っていったら「完璧な仕様があります」「完璧な要求があります」みたいな感じで紹介されるじゃないですか。あれって非現実的だよね、みたいな。


ちなみにこのトレーニングではそこら辺が曖昧な状態での開発方法を扱っており、結局スプリント開始前のフェーズではみんなで膝を突き合わせて大きめのバックログを作るところにフォーカスをおいていたので、アメリカではすでに死屍累々を乗り越えて今に至るのだろうと思われる。
バックログの作り方は基本的に昔の要求分析と同じかなぁと思うが、ひとまずミッションステートメントを作って最終的なゴールと優先順位をおおまかに明確化して、そこから必要なバックログ(いわゆる要求ですね)を出していくので、新規開発ではここをしっかりやっていればあまりブレることはなさそう。要求を作っていく作業ってのは誰でもできるわけではなく、こういう時にSysMLとかは役に立つのだが、欧米ではそういうツールがあんまりはやってないのでそのへんの説明はなし。後で書くけどツールを使わない彼らのやり方は今後やっぱり問題になっていくだろうなと僕は思っている。
バックログができたらあとは日本でよく紹介されているScrumのやり方ですね。基本的に残業をしない欧州ではデイリーミーティングをやれば工数と期日がだいたい予測できるが、残業の多いアメリカと日本じゃどうなんだろうなと僕は思ったりする。


そんで面白かったのがもう一個のカンバン。変な日本語の読み方がいっぱい出てくるからいちいち笑うのだが、要するに優先順位をつけて上からタスクを流れ作業で処理していきましょうという工場の業務フローをソフトウェア開発に持ち込んだものだ。利点は期日どおりにリリースできること(もし終わっていないタスクがある場合も気にせずリリースする)。
講師がこれはすごいって賞賛していたのだが、みなさんどう思いますかね。僕は全然すごくないと思います。ってか当たり前すぎるじゃんみたいな。そもそもこれはフローであってプロセスじゃないから、Scrumの問題点を解決してくれるすごい開発プロセスには成り得ない。そもそもすでに優先順位が定まっているタスクが存在していることが前提であって、そうじゃなかったらグダグダになりまくりだろうという。もちろんその辺はScrumのスプリントに入る前の作業できちんと議論したうえでスプリント中にKanbanを使用するということらしいのだが、それでもねぇ…っていう。そもそもタスクを分解して流れ作業にするより、ある意味のある単位での要求を一人または数人で最初から最後まで仕上げるほうが生産性も品質も高まるってのが最近の日本のはやり(?)じゃないですか。なに逆行してんだっていう。



ただこのトレーニングを一番後ろから見てたんだけど、Kanbanに対する食付きがすごいのね。細々とグループワークがあったのでその様子を見る限りも、なんかKanbanは新しい何か、みたいな受け止められ方をされている。
でもよく考えると、欧米の人たちって、というか特に欧のひとたちっていうのは「プロセスを守る」という部分が非常におろそかなので、逆にKanbanみたいな思想を導入したほうが失敗が少ないのかもしれないなと思ったりした。これはどういうことかっていうと、彼らはプロセスやコスト・期日・仕様・設計ありとあらゆるものをおろそかにするが、その代わり要求されているものをできるだけ最善な形で出そうとする努力は惜しまない。品質に関しては元がいい加減なのでそれなりなのだが(テスト仕様とかひどいもんだ)、それでも彼らなりに最善をつくすべきだとは思ってるみたい。
つまり「要求を満たすこと>品質>その他>>>>>>期日」で、要求を満たすための議論は非常に活発に行われる。上下関係は一応あるけれども、上下関係があるから言えないというのもないし(中傷はしませんけどね)、関係性がフラットなのも日本とは違う。


いくつか問題があるとすれば、基本的にみんなスキルが高いという前提で話が進むので(なのでプロセスが不要)、抽象的な話のまま議論が終わったりすることと、エビデンスを残す習慣がない。議事録は残さないし、ドキュメントは嫌いだし、あとこれは欧州限定なのだがアメリカ人よりものいいが抽象的なので、欧州系の文化で育っていないと彼らがなにに満足して、なにで合意に至ったのかよくわからないことがある。そしてそれゆえにその後ちょっと具体的な話になった時に意見の相違が出てくることがあるのだ。これでXMLでもなんでもいいんだけどツールを使って限りなく具体化するということをやっていればよいのだが、議論しちゃえば早いでしょという感じでつかわない。そしていつの間にか仕様が変わっている。
基本的なスキルが高ければそれでいいのだが、要求をきちんと実装に落とせないタイプがいたり、ジュニアデベロッパーのほうが多かったりすると問題が続出する結果となる。テストも穴だらけなので品質は微妙なものが出てくる。
これが欧州のやり方だ。


アメリカはもうちょっとプロセスがしっかりしてるんじゃないかなと思うのだが(飽きもせず開発プロセスを発明してるし)、議論が当たり前のように行われるフラットなチームではこういうことが起こりやすいのかもしれない。
逆に日本だと絶対にいる「プロセス通りじゃない!」って怒るタイプの人がプロセス通りに物事をすすめることに貢献するし、テストがクソ緻密すぎてコストがかさみまくったりするが、一応あんまりにも予想できないものが出てくることはないような感じがする。もちろん開発中に明らかにダメなものを指摘できずにクソ化していく経過を見ることはできるし、出てくるものが妙にしょぼかったりもするのだが、一応は出した要求通りのものが出てくるのが日本だ。期日通りかどうかは微妙なところだが、そもそもスケジュールがタイトすぎる開発現場のほうが多いと思うのでその辺は気にしなくていい気がする。というか日本のスケジュール感で見積もったものを欧州でやらせようとすると多分三倍くらい時間がかかるな。出てくるものはちょっと豪華になるかもしれないが、どうしようもないクソになってしまっている可能性もあるので注意が必要だ。小さな開発チームでビジョンを共有していれば逆に素晴らしい物が出てくる可能性もあるが、ちょっとチームが大きくなるととたんに欧州は仕事が回らなくなる。



ぼくは思うのだが、結局ダメなプロジェクトはどんなプロセスを使っても駄目だし、文化に合わないプロセスはどんなに安全なプロジェクトでもダメにする。そしてその国や文化圏に応じて気をつけるべきことは違っている。
欧州に足りないのは決まったことを守るという視点、日本に足りないのはダメなものをダメだと指摘して、建設的な議論をするチームの文化。逆にいえばそれさえあれば、たとえウォータフォールでも、というかプロセスさえなくたってものづくりはうまくいくんじゃないだろうか。