アジャイルの反対はウォータフォールでは無いんじゃない？という話
先日ふとSNSを眺めていると、「アジャイル」と「ウォータフォール」はあうあわないがあるので、使い分けるのが吉的な意見を見てなんだかもやっとした気分になった。
正直アメリカに来てから「ウォータフォール」を見たことが無い。確かに日本にいたときは使われていた。最近はさすがに「アジャイル」がだんだん主流になっていく流れも見える気がするが、
アジャイルが「主流」という感じすらしっくりこない。なんでだろう？アメリカでもアジャイルは「主流」ではない。
日本にいたときの個人的な開発方法論のイメージ
日本に居たときは、実際にウォータフォールが沢山あった。ただし、自分はソフトウェア開発には「ウォータフォール」が効率が良いとは一切感じられなかったので、そのことを書いたら結構炎上した。
simplearchitect.hatenablog.com
日本に居る時のイメージは、自分的にはこんなイメージだった。ウォータフォールと、アジャイルという軸があって、アジャイルが１００％合わないものもあるけど、基本的にアジャイルのスタイルの方がソフトウェア開発にあっていて、プラクティスが合わない場合は工夫するけど、ウォータフォールは役に立たないというイメージ。でも実際には現場にはウォータフォールのプロジェクトはある。
自分が特にいまいちだと思ったのは、このプロセスのイメージ。今のソフトウェアスタックで、ドキュメントだけで設計とかはっきり言ってありえない。危険すぎる。昨日動いていた昨日が、何もコード変えなくても動かなくなってしまうこともあり得るのがクラウド時代のソフトウェアだ。（とはいえ、そこには必ずロジカルな原因が存在するが）それぐらい見通しが難しいものをコードに触れず設計できるとかは絶対にありえないと思う。これは実際にコードを書いている人ならみんなそう思うレベルのことだと思う。
アメリカに来てからの開発方法論のイメージ
実際にアメリカに来てから、世界規模のクラウドのプロダクトチームのデベロッパとして仕事をしている。私はこっちに来るまではアメリカは技術レベルが高いし、アジャイルカンファレンスでは、日本のカンファレンスより圧倒的に進んでる発表がなされているので、ほとんどの会社が「アジャイル」なんじゃないかと思ったが、そうではなかった。ただし、ウォータフォールでやっているチームは見たことが無い。じゃあ、開発方法論はどういうイメージかというとこんな感じ。 ウォーターフォールとか、アジャイルとか、乗っかれる枠組みがあって、それに従うというより、自分たちの課題があって、その課題の解決のためにどうしよう？そんな時に、参照できるアイデアが沢山あって、それが「アジャイル」だったり「ソフトウェアエンジニアリングやパターン」だったり、「研究論文」だったり、「事例やベストプラクティス」だったりする。だから先進的なプロダクトを開発しているチームでも、アジャイルプラクティス的観点でみると改善の余地が沢山あったりもする。
だから、そもそもの出発点が、「自分のチームの課題」があって、その解決策を探っているのであって型があるわけではない感じ。だから、開発のやり方なんてものは、しょっちゅう変わっていくというイメージ。ただ、「ウォータフォール」はもはや誰も参照してないようなイメージ。自動車が発達した後の「馬車」みたいな感じ。
アジャイルの対極にあるものとは？
アジャイルは 2000年当時はやっていた重厚長大なプロセスのアンチテーゼ的なところがあったが、実際のところ現在のソフトウェア開発によくフィットしたプラクティスが多い。ただし、考え方が合わないこともある。それは、例えば失敗できないものだったり、フィードバックサイクルが長いものだったり、多くのシステムとの連携があるものだったりする。私がやっている例でいうと、例えばライブラリや、Extension のリリースはアジャイルがピッタリ。もうゴリゴリにアジャイルのプラクティスが効きまくる。だから、フルアジャイルみたいな状態で開発する。
アジャイルが合わないものとしては、例えば、プラットフォームのインフラを制御するコードのデプロイみたいなものがある。これはリリースサイクルが１か月以上かかることもざらで、失敗したときの影響度はとんでもない。ライブラリや、extension なら、あるバージョンがバグがあっても、古いバージョンに固定すればいいだけだし、修正もPushしたら終了だ。しかし、プラットフォームのインフラを制御するコードとなると本番でのテストすら難しく、テストのためのインフラをデプロイするのすら大変であり、時間もかかる。かかわっているチームが多ければ、こっちがインターフェイスでミスをすれば、その修正のサイクルが長くなる。だから、失敗したらリリースが、２か月先とかになりかねないので、慎重にテストしたり、しっかりテストケースを作ったりコードを書いたり設計を何度も行き来して見直したりする。検証するべきものが見えたら、それを自動化したりする。
Subject Matter Expert
クラウドプラットフォームのような複雑で、デプロイを失敗したらとてつもなく多くの人に影響するけど、実際の本番では試せないようなソフトウェアの場合、つまり、アジャイルが合わないものの場合、今の我々がどういう解決方法をとっているか？というと、名前を付けるとすると「SubjectMatterExpert」モデルといえるかもしれない。実際にわれわれはその問題を解決するために様々なプラクティスを使う。結局我々が知りたいのはデプロイの前に「ちゃんと動くと思われるアプリケーション」を作ることだ。「完全に動く」と保証は残念ながらできない。どんなに慎重になったとしても。しかし、そこに極限までに近づけるように努力をする。
- カナリアリリース
- コード、要求仕様、デザイン、テストを行ったり来たりして、設計を確実にする
- 本番に最も近いインフラ自体をデプロイしてテストをする
- 自動化されたテストで検証する
- ソフトウェアエンジニアリングや、パターン、ベストプラクティスなどを参照する
あと、一つ、我々がよく使う手として、「SubjectMatterExpert」という考え方がある。クラウドの中身をすべて把握している人間はおそらくいない。複雑すぎるのだ。きっと皆さんのコードベースでも正直そうだろう。だから、自分が開発したコードを中心に、「それについて一番知っている人」を「SubjectMatterExpert」と呼ぶ。
だから、ソフトウェアの設計や実装を確実なものにするために、「SubjectMatterExpert」とディスカッションをする。例えば「Linux Consumption Plan のインフラ」のエキスパートに、自分が、考えている設計やコードをシェアしてディスカッションする。デベロッパ自体がそれを自分きっかけで行う。特に早い段階で。そうしたら、いろんな落とし穴を避けることが出来る。すごくダイナミックなコミュニケーションなので、「誰が、どのことを知っているか？」というのが重要で、それが開発のスピードと確実性を増す。自分が「すべてを把握しようとしない」と思うことも結構重要だと思う。そうでないと、何かのことについてディープになり、他者に貢献ができないからだ。
小さな最初の一歩
日本の開発現場のカルチャー的にいきなりは難しいかもしれないが、本当に世界に通用するアプリケーションを作るためには、枠組みに乗っかるのではなく、初めの一歩として「自分のチームの課題」が何であり、「どうやって解決するか？」という観点でやっていることを見直すのはどうだろうか？結局のところ「自分で考える」しかない世界でだから、ソフトウェアエンジニアの給料は高いのだ。すべての過去のアイデアはリファレンスでしかない。もちろん学ぶ価値はとてもある。そして、開発のやり方は頻繁に変えてもいいもので、今までのやり方を踏襲するほうがよっぽど危険だ。
アメリカに来てから、ソフトウェアの開発だけではなく、ソフトウェアの仕組み、ビジネスプロセスが頻繁に変わるのを何回も見てきた。日本に居る時は「現場が反対する」とかいってなかなかそういうものは変えずらかったが、こちらだと、しょっちゅう変わるし、かわるものなので、「前と違う」とか誰も言わない。新しいのがきたらそれに慣れるだけだし、「前と同じインターフェイスにしてほしい」とかいうのはそういう変化に対応できないということなので、ファイアーされても仕方がない。文化的な違いがあるが、日本で本当にデジタルトランスフォーメーションをガンガンに進めたいのなら、そういうところから変えていかないとうまくいかない気がするし、実際にそういう会社も日本で増えている気がするので、私が日本に帰るときにはそういう職場が沢山あるといいなと思う。そして、そっちの方がきっと、ずっとエキサイティングだし、会社にとってもいいんじゃないかな？
