ウォータフォールはやめて2024年の開発をやろう！
今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。
最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。
ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。
もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。
最初に自分的な結論を書いておくと「2024年の開発とは開発プロセスが無い事である」ということになります。最初に現在行っている開発スタイルを振り返って、自分がなぜそういう考え方になったかをこのブログでシェアしてみたいと思います。
現在の開発スタイル
おそらく私のチームの開発の進め方は特に特殊なものではなく秘密もありません。普通に世間で知られているやり方をやっています。会社で共通の開発プロセスとかは定義されていません。各チームが自分たちなりに好きに決めてやります。標準もありません。
開発の進め方
アジャイル以降の伝統である、Sprint のスタイルで開発を進めています。うちのチームは２週間ぐらいでしたが１カ月を試してみようという話もあります。開発のタスクの管理は、Azure DevOps の Kanban を使っています。このKanban は相当よく出来ています。Spring の区切りごとに Sprint planning をします。このタスクの中に、スペックを書いておいたり、タスクを書いておいたりします。Teams で議論したときはそのリンクを貼っておくこともあります。
この日までにマネージャが Kanban を精査してくれていて、この日までに完成してないのものは、続けて次の Sprint でやるのか、やめるのか、後回しにするのか、他の人にアサインするのかなどを話をしながら決めていきます。新しいタスクもアサインしますが、現在の各メンバーの状況を見て、優先順位の高いものから「これやってみようか」というノリでアサインしていきます。ポイントは無理に全部やり切ろうとしないことだと思います。
フェーズも見積も無い
特にフェーズとかはありません。何か大きなリリースの時は、大体このころまでに、Bug bash を始めようということをざっくり決めたりはすることもあります。（ただ、進捗がおもったほどでなかったら状況に合わせて柔軟に変更します）開発のライフサイクルにおいて、常に・仕様の明確化/デザイン/コーディング/テスト/リリース/オペレーションをやり続けている感じで、それらを行き来しています。
優先順位は常に変動しますし、この Sprint でそのタスクがやり切れるものなのかは誰にもわかりません。タスクが難しいとか、もう少し時間がかかるとわかったら、優先順位に影響することがありますのでそういうフィードバックを得て、次の決定をしていきます。
だから特に見積とかもしません。物理的にできないものはできないので、終わった時点が終了で、開発のベロシティも特に測定していません。
開発でやることに関しては、ＰＭチーム（プロダクトのコンセプト、戦略などを決めて、外部に広めたり様々なの対応もしてくれる）と、マネージャ、開発者、リーダーシップなどで話をしながら最終的にものすごーく粗いレベルのものが期ごとに決まるという感じです。大体今季これやろうぐらいのざっくりとしたものです。ここでも見積もりはありませんし、出来なければ、それを継続するのか、次の期もやるのかを考えます。
チームの概念
チームはかなり個人商店の集まりという感じです。１人のマネージャごとに持ってるコンポーネントがいくつかあって、そのメンバーはそのコンポーネントを分担する感じです。
基本的に個人がフィーチャーを持ったら、その人が、仕様の明確化から、デザイン、コーディング、テスト、リリース、アラートやディテクター作りなどなんでもやっています。ただ、うちのチームでは Buddy 制にしていて、１つのコンポーネントに対して２人いる感じになっています。これは、休暇を誰かがとてっても問題ないようにとか、PullRequestのレビューで、誰もレビューが出来なくて承認されないとかの問題を防ぐ効果があります。自分の能力を超えるとき、知識が居るときはミーティングするなどして他の人の助けを借ります。ただ、自分が主体になってやります。
マネージャの役割
マネージャは、何かの指示、課題管理、進捗管理をする人ではありません。今の時代だと、タスクは Kanban などのソフトウェアで管理されていますので、そこにあまり時間を使う意義がありません。課題が生まれたら、タスクまたはバグにして 優先順位をつけて Kanban にぶち込んでおきます。
それよりも、マネージャの仕事は、「アンブロック」です。開発メンバーが開発中にブロックされたらそれを助けてくれます。例えば、PullRequest作ったけど、レビューしてくれる人が居ないからマージできない。このタスクをやるには自分の知恵が足りない、開発システムがうまくセットアップ出来ない、開発は様々な理由でブロックされますが、こんな時にマネージャはアンブロックつまり、そういう問題解決を助けてくれて、開発がブロックされないようにしてくれます。
マネージャで技術を知らない人は一人もいなくて、自分よりレベルの高いエンジニアがマネージャになってくれる感じです。ちなみにマネージャになっても給料は変わらないらしく、マネージャになる人もいれば、一旦なったけどまた、個人開発者 (Individual Contributor) に戻る人もいるので、人次第です。
理解・調整・整合性をとるスキル
もう一つ大きな役割が、「全体の整合性」です。先ほどの言った通り、個人商店なので、各人がそれぞれいろんな様々なことをやっています。もしかすると、この機能を実装したら、違うマイクロサービスで影響が出るかもしれません。だからマネージャは、開発者がやっていることを技術的に理解して、各個人がやっていることをつないでくれます。言葉で書くと簡単ですが、これは見ていて頭が下がります。めっちゃ大変やと思います。
そもそも、自分がやってることを理解するだけでも大変なのに、チーム全体が何やってるかを理解して整合性をとってくれるわけです。他のチームを巻き込む必要があるときは、開発者自らやることもありますが、マネージャも入れるようにして、コンテキストを共有しておきます。つまり、全体的な整合性をマネージャがしっかり担保してくれています。
こういうことをしっかりマネージャがやってくれるので、開発者は自分の仕事にフォーカス出来ている気がします。もちろん、他にも評価とかマネージャの仕事はありますが、開発の進め方のところに関するところだけピックアップしてみました。
品質管理
品質管理チームというものは存在しません。遠い昔には存在したそうですが、今は開発者になったようです。（ちなみに私のメンターのクリスはもともとテストエンジニアだったけど、ある時組織がなくなって開発者になったといっていました。）
じゃあ、どういう方法で品質を確保しているかというと次のものです。結論からいうとそんなものは無いです。「管理」っぽいものを上げるとすると下記のものです。
デザインやPull Request のレビュー
自動化されたテストスイート
Bug Bash
という感じでしょうか。どれも重要だと思いますが、デザインや、Pull Request のレビューはとても重要ですが、そんな厳重なものではありません。デザインに関しては、開発者が手を上げてイケてるエンジニアにレビューしてもらうものですし、Pull Request のレビューはそれが無いとマージされないようになっているので必要ですが、この質が重要になります。つまり、ゴリゴリのエンジニアでないとコードの品質を見極めるのは無理だと思うので、エンジニア同士でレビューという事になるわけです。
あと、とても大切なものは、自動化だと思います。人がマニュアルテストをするのは重要ですが、それよりも、如何に自動化するかが重要なポイントになります。そうでないと、どうやって、コードの変更に耐えるのでしょう？テスト仕様書を作るより、自動テストの仕組みを作りましょう。
私の環境だと、小さなクラウドのようなマイクロサービスの集まりを、自動でインフラごとデプロイして、E2Eのテストスイートが複数のシナリオについて自動で流れるようになっています。品質管理の専門家がレビューとかではなくて、こういう環境の場合、如何に自動化してテストするかが重要です。テストは１回きりで終わらないので、クラウドのプラットフォームのようなクリティカルなシステムだとより重要です。紙に頼っている場合ではありません。Bug Bash はこちらをどうぞ。
構成管理
今は誰も困ってないと思いますが、もちろん、GitHub, Azure DevOps のリポジトリなどを使えば今は問題ありませんね。
リリース
継続デプロイは使っていません。というのも、クラウドプラットフォームの性質上、変更をして、プラットフォームが動かなくなると、世界中の企業のシステムが停止するということが普通に起こるからです。すべてのシステムがこうすべきと思いませんが、このように相当にクリティカルなシステムの場合の参考になれば…
めっちゃ普通ですが、デプロイは自動化されていますが、単純ではありません。何しろクラウド自体をデプロイしますし、その個別のパーツは個別でもデプロイも出来るようになっています。アプリケーションの様々のレイヤでデプロイされる可能性があります。ある環境だけで発生する問題もあるかもしれません。
ですので、よく知られたカナリアリリースという方法をとって、世界中のリージョンを分けて、部分ごとに段階を分けてリリースして、アラートが通知されないかをチェックしたり、新しい機能をリリースした時は、最初に社内しか使われないリージョンにデプロイされた時点で評価したりします。
また、フィーチャーフラグを使って機能が問題が起きたらOFFに出来るようにしておいたり、リリースしてから、フィーチャーフラグをカナリアの段階の一つ一つでタイミングをずらしてTurn Onしたりします。これも障害が起きた時の問題を最小限にするための工夫です。
本番運用
開発と運用は永遠に続くイメージです。うちのチームでは、DevOps スタイルで、開発者が運用も行います。もちろん１００％ではなく、世界中の優秀なエンジニアがサポートしてくださって、それでもわからない障害はこちらに来てエンジニアが交代で調査しています。開発者が直接そういうことを体験することで、自分の書いた悪いコードがインシデントの数となって帰ってきますので、良い習慣なのだと思います。
開発者の仕事として重要なこととして、機能を開発するとアラートや障害の検出や監視をするツールの開発もセットになっていて開発するという感じです。また、インタラクティブなTrouble Shooting Guide も書いておき、自分たちまで回ってくる障害の数を減らそうとします。
ただ、開発して最初のうちはアラートとか False Positive が大量に出たりします。でもこれで良いという考えてそれを調整したり、時には無効化したりしながらちょうどいい感じになるまで調整します。私のマネージャ曰く”アラートは、無いより無駄に沢山通知される方がまし。気づけるから”とのことです。
ドキュメント
ドキュメントは、User のためのドキュメントは相当しっかりしています。ドキュメントの専門の人もいますが、書くこともあります。
開発の前に各ドキュメントは特に決まりはありませんが、開発者がそうすると楽なので、そんなに分厚くないデザインドキュメント（数ページ）を Word で書いてWebでシェアをしてコメントをもらって、レビューの会を自分で開いて、イケてるエンジニアの脳みそを借りる感じであくまで開発者主体です。
先ほど書いたような Trouble Shooting Guide は自分の負荷を減らすためにも重要です。
自分が整理するため、他の人に渡すために、楽をするために、アーキテクチャのドキュメントを自ら書くことはあります。ただ、強制とかプロセスで決まっているとかではありません。
開発プロセスは気にされない
ざっくりと、どんな感じで開発しているのかを書いてみましたが、特に特殊なことは何も無いし、ものすごい秘密が隠されているわけでもありません。おそらくこれが最新の開発手法というわけでもないでしょう。ただそれでいいと思います。
私がアメリカに来て、今の会社に勤めてどんな開発方法論なのか興味深々でしたが、そんなものはありませんでしたし、誰も気にしていない感じでした。ただし、自分たちの仕事がどうやったらちゃんと、楽にできることには熱心でした。だから開発のやり方というのは少しづつ毎年変化しています。ここに書いたのも数年で全然違うのになるかもしれません。
私は、日本に居るときは開発プロセスの専門家で、アメリカからくる本に最新のプロセス・考え方が重要なんだろうなぁとか思っていました。
世界の変化に対応する
でも、こっちにくるとびっくりするぐらい誰も気にしていません。最新とか新しいとかどうでも良いです。やっていることは、今ある技術や問題に合わせて、常に自分たちなりの問題を見つけてそれを地道に少しづつ振り返って改善しているだけだからです。一つの問題を解決したら次の問題がでてきます。
先ほど書いたような、最新の開発のやり方や知識が役に立たないと言っているのではなく、そういうものは「導入するもの」ではなく、「参照するもの」だと思うのです。つまり、自分のチームの抱える問題が、そういう本を読むと、他の人が先に解決しているかもしれなくて、それがヒントになるかもしれないという観点です。
人に頼り・人中心の開発の進め方
また、私が上記で説明したような進め方は、「標準化」とか、「誰でも出来るように」という方向を目指すのとは正反対で、めっちゃ人に依存している方法で、ある意味個々人のパワーに頼り切っています。
その理由を考えてみるとやはりテクノロジーの進化があると思います。私はC#を書くことが多いですが、C#が誕生した２０００年と比べると、生産性も性能も比較にならないほど上がっていると思います。言語自体が毎年進化していますし、IDEの進化も強力で、Visual Studioの高性能さにいつも呆れます。しかも、最近は Copilot の AI まであります。開発ツールも、当時なかったGitHub や、自動化で使えるパイプライン、インフラストラクチャの自動化の仕組みやツール、クラウドの登場でインフラ自体の調達のスピードもその頃と比較になりません。
２０２４年に合った開発のやり方は？
つまり、一人の開発者で出来ることが加速度的に毎年上がっていってるので、単純なことはもはややる必要がありません。それは自動化できます。ですので米国の各社は、いいエンジニアを採用して、１０名ぐらいの少ないチームを沢山作って開発をしているのだと思います。だから近年の開発は、個人にある意味依存しているのだと思います。マネジメントのスタイルが変わっているのも、今はチームとして最も生産性の良くなるのが、各個人のエンジニアの生産性が高くなるように障害物を排除して、彼ら・彼女らに考えてもらって、任せるのが今の時代のツールや技術にとって、最も生産性が高いのだと思います。そして、昔沢山やっていたマネジメントの仕事も今は不要になってるものも沢山あります。ツールやサービスの進化はすごいですね。
２０２４年のツールや技術に合わせた開発をやろう
だから、私は言いたいのは、ウォータフォールとか、アジャイルとか言ってないで、2024年のツール、技術、に合わせた開発をしませんか？というのが思う事です。これだけツールや、技術がゴリゴリに変わったらやり方が変わるのは当然です。現場や状況は様々で画一的な正解はありません。
重要なのは今自分が居ている現場で、今のやり方に固執せず、それを毎年如何に改善して時代に合わせて変化させていくかが唯一重要なことな気がします。それはＡＩの登場によってそれはもっと変化していくでしょう。
世の中明日には変わりませんし、一気に変えるのは大変ですが、チームが出来る速度で何かを小さく積み重ねれば１年後振り返ると大きな違いになっていると思います。
開発の状況は現場によってすべて違うし、開発しているものによっても異なるので、自分たちで考えて、試して、フィードバックを得て少しづつ改善するしか手がありません。もちろん他の会社がどんなやり方をしているだろう？と学ぶのはもちろん有効だと思います。でもあくまで主体は自分たちのチームだと思います。
こういうのが出来るのはお前のチームがたまたま優秀だからだという方もよくおられました。
自分はわからないですが、リクルートの時から、そういうことを考慮してリクルートしているのだとしたらどうでしょうか？ただ、必要だから１０人やとうより、しっかりとコンピュータサイエンスを勉強した人を採用するスタイルを要求しているとしたらどうでしょうか？世界はすぐには変わりませんが、方向を少しかえるだけで数年後には大きな差になることをよく目にします。
テクノロジーに合わせるのか現状にあわせるのか？
こちらにいるとテクノロジーに合わせていろんややり方や仕組みが毎年のように変わっていくのが当たり前に見えますが、日本にいるときだとあまりそういう感覚ではなく、現状にテクノロジーを合わせに行く感じがありました。でもそれだとテクノロジーのパワーを生かせないのは当然だと言えます。
それを「今までこうやってた」から、「ビジネスがこうだから」、「商習慣がこうだから」、「上司が許さないから」といってあきらめてしまうのはあまりにもったいなくありませんか？今の技術やツールは１０年前、いや５年前と比べての格段の進化をしています。私だったら少なくとも、自分が使えるツールは全部つかって、楽に、たのしく開発をして、より多くの価値を出したいです！
じゃあどうしたらいいだろう？
もし、読んでくださった皆さんが同じように思うけど、どうしようも出来ないと思ったらどうしたらよいでしょうか？
例えばウォータフォールだけをやっている職場があるとしたら最初の一歩はどうしたらいいでしょうか？そんな急に変えるのは大変ですので、このブログに書いた通り、新しいツールが置き換えられる事、今の技術だと非効率なところを少しづつ変えていけばいいです。定期的に今の技術と照らし合わせた改善点を見つけて、どうやったら少しでも楽になるのかを、実際に少しづつ変更していけばいいです。これなら特にたいへんでもないと思いますが、「変化」に対して方向性を向けるだけで将来が大きく変わってきます。
シーケンシャルとイテレーティブ
ウォータフォールを現状やっている場合から2024年の開発への一番大きな転換は、現在の成果物を中心としたフェーズのアプローチを開発者中心のイテレーティブなものに変えてくステップだと思います。ここは素直にプロのアジャイルコーチを雇うのが良いと思います。
これは、イテレーティブへの転換をするにあたって、今のリソースを考えるとアジャイルコーチが適任と思うのであり、別に皆さんのプロジェクトがアジャイルをやるべきと言っているわけではありません。ただ、はじめてなら、素直に真似してやってみるといろいろ学びがあるのでお勧めではあります。
そして、失敗しても問題なさそうな小さなプロジェクトで試して経験を積むのが良いと思います。現在の開発は特定の開発のやり方が無いので現場に合わせて最適化するのが解だと思うのですが、残念ながら先のブログで書いた通りソフトウェア開発においてはウォータフォールはメリットがありません。ソフトウェア開発に向いていません。また、ウォータフォールでは先ほど言っていたような小さな改善をしていくステップが非常にやりにくいという理由もあります。今ウォータフォールだったとしても現状を嘆いても仕方がないので、そういう背景を踏まえていまの状態からどうやったら小さな改善ができるか考えましょう。
だから、基本的に現在では現場で今の技術に合わせて改善していく状態に持っていくために、シーケンシャルからイテレーティブの変換は済ませておきましょう。後は自分たちなりにやればオッケーだと思います。
開発現場は自分のもの
ここでポイントは二つあります。一つは、アジャイルコーチは全能でなく、みなさんの状況をよくわかっているはずがないので、彼らの経験と脳みそを借りて、自分たちの開発の進め方を考えていく、つまり自分で考えて主体性をもって実行するところです。
二つめはちょっと失敗したからといってすぐに元に戻さない事。普通初めてやることは経験値が無いので失敗しても当たり前ぐらいに思っているマインドセットの方が新しいことを導入しやすくなります。最初はだれでも経験がなくてわけがわかってないので、素直に真似するのが個人的にはお勧めです。
重要なのはそこからフィードバックを受けて改善していくことです。自分の同僚のクリスは、ペインポイントが見つかると改善できることが見つかるから嬉しいと言っていました。このシーケンシャルから、イテレーティブへの移行はいろいろな意味で大きな転換です。
だからプロの力を借りて契約形態や社内の標準、他チームとの同期とかにも調整を入れる必要があるので、気長に取り組んでください。
辞めるのもコントリビューション
もし、自分にそんな権限はないとか、めんどくさいとか、そういう理由があった時は、素直に辞めて、そういう開発が出来るところに行くこともお勧めです。一番いまいちなのは、我慢してアクションを起こさない事だと思います。もちろん今の自分がしあわせなら特になにもしなくていいと思います。
ただ、いつまでも今の技術にそぐわない開発を続けるところがあっても、人が集まるからビジネスになるから今もそうなのであって、そういうところから脱出するというのも、立派な意思表示ですし、業界への貢献だと思います。そうすることで、古い開発を続けていたら、開発者が集まらないということになってくると思います。
エンジニアの給料が最近少しづつあがってきているのもそういうことに気づき始めている人が増えているからだと思います。
コミュニティに参加する
それもしたくない場合、もしくはそうでなくても、私のお勧めは、自分のお気に入りの「開発コミュニティー」に参加することです。そうすると、すでにそういう２０２４年の開発をやってる人に会えますし、沢山の優秀で熱心でパッションあふれる人に会うことが出来て、どうしようもないと思えたことが、いろんな方法があることに気づかさせてくれます。それだけではなく、沢山の学びも得て同僚に差をつけることも可能なので一石二鳥です。そして、自分が自由になる機会もそこにいくと結構落ちていたりしますのでめっちゃくちゃお勧めですよ！日本では毎日のように技術コミュニティが開催されていてめっちゃうらやましいです。
ちなみに私が最初に本を書く機会を得たのも技術コミュニティでした。さまざまな人によって自分の狭い考え方がアンブロックされたことが１回や２回ではありません！もしよかったら、是非お気に入りの技術コミュニティを見つけて参加してみてください！
最後にちょっとだけ宣伝を。自分が書いた本がありがたいことにもうすぐ９万部に到達します。自分としたら１０万部はきりがいいのでそうなったらなぁと思うのでよかったらご協力くださいまし。三流エンジニアの私が米国の開発現場で周りの優秀な人々を観察して学んだこと、日本と米国で働いた時の違いなどについて書いてみました。よかったらどうぞ！
この記事が気に入ったらサポートをしてみませんか？
コメント