開発の考え方をウォーターフォール→アジャイルにRebuild

渡会健氏:みなさん、こんにちは。マネジメントソリューションズの渡会と申します。これから、「アジャイルで実際に困ったからこそアジャイルをRebuildした話」ということで講演させていただきたいと思います。よろしくお願いいたします。

(会場拍手)

最初に、私の自己紹介。この自己紹介の中にも、けっこうRebuildしたことが入っています。

最初の20年は、プロジェクトマネージャー、バリバリのウォーターフォールでやっていました。ところが2008年にPM(プロジェクトマネジメント)のコンサルとしてお仕事をしていた時にアジャイルに出会ってしまって、そこからもう開発の考え方のRebuildを自分の中でしちゃったということで、ここからは先は、ずっとアジャイルばかりやっています。

最初、何をやっていたかというと、アジャイルができそうな小さな会社を探して、そこで組織作りの最初のBuildをしました。ここの会社にはだいたい10年弱いましたが、PO (プロダクトオーナー)とか、プロキシPOとか、スクラムマスターの立場で、20案件ぐらいやらせてもらいました。

この「Agile Japan」でしゃべったり、いろいろなことをしていると、PMI(Project Management Institute, Inc.)のアジャイル研究会の代表になっちゃったり、IPAのワーキンググループに呼ばれたりだんだんしてきました。

100人ぐらいのSIerでずっと開発しているという立場から、どんどんどんどん、個人的な仕事が増えてきてしまったので、2018年にアジャイルコーチに転身しました。

2020年に、今いるマネジメントソリューションズに入社しました。この会社でも、最初からアジャイルでみんなやっていたわけではなかったので、中小のSIerでやっていた時のようにRebuildしていって、組織をどんどん作っていきました。1人から始めて、今4年経ちましたが、15、6名ぐらいまでメンバーを増やしてお仕事をさせていただいています。

マネジメントソリューションズの事業紹介

簡単に弊社の紹介です。弊社は、プロジェクトマネジメント実行支援をする会社なんですが、その中のデジタルをやっているところでアジャイルを支援させていただいています。

コーチング、コンサルティング、トレーニングというありきたりなサービスをやっているのですが、私が今まで経験してきた内容をノウハウとしてメンバーに伝えて、それでお仕事をさせていただいています。

特徴的なところは、我々はもともとマネジメントの会社であることです。アジャイルはITシステム開発、アジャイルソフトウェア開発宣言から始まったところもあって、どうしてもこのイメージが強いのですが、最近では、それだけではない、例えば材料開発だったり、業務プロセス改善だったり、新規事業の立ち上げをやったり、そういったところでのアジャイルを適用させていただくことが多くなっていて、ビジネス寄りの仕事が、ちょっと若干増えています。

“ITシステムではないアジャイル”が広がってきている

ビジネス寄りな仕事という意味で、今言ったソフトウェアの開発以外の事例だと、世界的に有名なのは、イーロン・マスクのSpaceX社のロケット。再利用するために着陸するところ、大事なところから作っていく、みたいなことをしていましたし(※1)、あとは、スウェーデンの戦闘機もアジャイルで作っている。(※2)

海外だけでやっているかというと、日本のJAXAも「はやぶさ」2号機をアジャイルで作っている。(※3)やはりこういったビジネスというか、ITシステムではないアジャイルがそれなりに広がってきているんじゃないかなと思います。

アプローチにおける、アジャイルとウォーターフォールの違い

どんどん機運が高まってアジャイルを導入していただいているところはけっこう増えてはきているものの、なかなか続けられない。

なんでかな? と思った時に、ちょっと誤解があったりとか、そういったところでなかなか次へ突破できないんじゃないかなというところがあって、今回そういったものを諦めてしまった人たちでも、もう1回チャレンジできるようにということで、私の今までの経験を書籍にまとめて出していたりします。

みなさまのアジャイルのRebuildに少しでも役立てればなと思って、今回はその中から4つほど中身を紹介したいと思っています。

1つ目。ありきたりですが、「そのアジャイル、本当に必要ですか?」というところで、このあたりはみなさんもよくご存じだと思うので、そんなに詳しくやりませんが、「ウォーターフォールってどういうやり方?」は、ゴールがはっきり見えている。はっきり見えているから、そこに行くまでのルートも、たぶんがんばって予想すれば予想できる。

一直線に効率的な計画を立てて、変更さえなければそこをうまく突っ走ることができるので、たぶん一番安くできると思うんですね。変更さえなければ早くできると思うんですね。

ところが最近はそういう案件ばっかりじゃないですよね。そうなった時、アジャイルの考え方が出てきます。アジャイルは何をするかというと、小さく計画を立てて、そこまで行った経験と、その時に見える新しい情報を取り入れて計画をどんどんRebuildしていく。

短い計画を立てては、実行して、反省して、新しい情報を取り入れて、Rebuildしていく。これを繰り返していって最終的なゴールに近づいていく。こういうやり方の差があります。

ビジネス観点における、アジャイルとウォーターフォールの違い

今のはアプローチの観点の違いですが、じゃあ、ビジネスの観点ではどうか? ウォーターフォールは、例えば「10億円の売上を上げたい」という目的で始めた時に何をするかといったら、10億円が儲かるための作戦をいっぱい考えます。「たぶん、これとこれとこれとこれがあればできるんじゃないかな?」と考えます。

10個ぐらいアイデアを考えたら、その10個を全部やって、最後の最後でそれが正解だったかどうかがわかる。いわゆる投資の回収が最後になっちゃうんですね。

一方、アジャイルはどうするかというと、同じように10億円を儲けるためのアイデアを考えた時に、全部の詳細を考えるんじゃなくて、その中で、10億円に近づけるアイデアはないかなと考えて、それだけを作るんですね。全部フルセットじゃないかもしれないけれど、それだけを作る。それで世の中に出す。

世の中に出すので、そこで一応回収ができるわけですよ。それを続けていく。稼ぎながら新しいものを作っていくことができるというビジネスの観点がある。

仮説を出しながらやっていく中で、市場と対話しながらやることができるので、例えば、最初に考えたアイデアがうまくいった。2番目のアイデアがあまりうまくいかなかったとしたら、「1番目と2番目のアイデアの差はどこだろう?」と考えて、まったく新しい3番目のアイデアをやることもできる。こういった特徴があります。

あと、全部作らなくても10億円にたどり着ければ、目的が達成できれば、終わりにすることができる、こういうのが特徴です。

ものづくり観点における、アジャイルとウォーターフォールの違い

ものづくりの特徴だと、(スライドを示して)これは有名な絵ですが、自動車。移動することの正解が自動車。正解が自動車とわかっているのであれば、バラバラのパーツでどんどん作っていってガッチャンコしたほうが効率がいいですよね。

ですが、最終的に移動する正解が自動車とは限らない、この先もあるかもしれないとなると、いろいろと試行錯誤して決めていく。もしかしたら今は自動車かもしれないけど、次は空飛ぶ自動車かもしれないし、ほかのものかもしれないということができるのもアジャイルの特徴。

それぞれの特徴は以下になります。

アジャイルを理解した上で選択している欧米と、 理解せずにアジャイルを採用できない日本

ここをどうしていくかというところで、IPAのデータによると、実はアメリカですら全社的に(アジャイルを)使っているところはないんです。

なんとなく欧米ではもうアジャイルでしかやっていない、ウォーターフォールはまったくやっていないんじゃないというイメージがあるかもしれませんが、実際のデータは、(スライドを示して)こう。

事業部のどこかで使っているというのでも55パーセントしかない。「日本のIPAが調べたからそうなんじゃない?」というと、実はPMI(Project Management Institute, Inc.)が出しているレポートでも同じような状態になっている。

割合を見てみると、ウォーターフォールが45パーセント、アジャイル、ハイブリッドがそれぞれ26パーセントと26パーセントで半分ぐらい。

おそらくウォーターフォールをやっている人たちもアジャイルを選択できて、自分たちのプロジェクトに合わせてウォーターフォールを選んでいるんじゃないかなと思いますが、日本のデータ、IPAのデータを見るとぜんぜん少ないですよね。ぜんぜん選択肢になっていない。

だから私としては、アジャイルをもうちょっと選択肢として認めてもらいたいということでいろいろと今活動しています。

同じことですが、どちらが優れている、優れていないという話ではなくて、それぞれの特徴も踏まえて、目の前のプロジェクトを成功させるために必要なやり方を選んでほしい、そういった選択肢のRebuildをしていただきたいなと思っています。

従来型のロールとアジャイル型ロールはどう違うか?

その中の1つの例を言うと、ロールのRebuildみたいなこともしています。従来型の開発では、なんでもかんでもプロジェクトマネージャーが決めていますよね。見積、計画、進捗管理、それからどういったものを、どっちの方向に向かうかということも。

ほかにも、細かい、どういったものを作るべきかということも、考えるのは別の人かもしれませんが、決定する、決断するのは、全部プロジェクトマネージャーがやっています。そのため、主役型のリーダーシップのタイプを用いることが多い。

ウォーターフォールでそうなっていると、プロジェクトマネージャーがすごく優秀で、キャパシティもたくさんある方であれば、なんとか成功する確率が高いのですが、これだけやることが多いとやはりなかなかうまくいかない。

メンバーの人たちがどれだけ優秀でも、プロジェクトマネージャーがちょっとしくじると、プロジェクトが失敗しちゃうみたいな危険性をはらんでいる。

だからアジャイルでは、見積、計画立案、進捗管理みたいなのは開発チーム自身がやりましょうとなっています。何を作るべきか、どっちの方向へ進むべきか、プロダクトのことを考えるのはプロダクトオーナーがやりましょう。実際にどういうスペックのレベルでどう作るのかも開発チームで決めましょう。

それをするためにスクラムマスターがサーバントリーダーシップで支えましょう、みたいに分担してやっていく。ロールをRebuildしているというところがアジャイルの特徴の1つかなと思っています。

これは私が活動しているIPAでも似たようなことを言っているので、(スライドを示して)こちらを参考にしていただければと思います。

※1 出展元
https://news.mynavi.jp/techplus/article/flight_proven-3/
※2 出展元
https://2019.agilejapan.jp/session.html#l-03
https://2019.agilejapan.jp/2019/session/ten2-1_Scrum.pdf
※3 出展元
https://www.pmi.org/learning/library/rock-hoppers-japan-space-agency-applied-lessons-learned-land-jumping-robots-asteroid-11485

(次回へつづく)