DXはアジャイルとセット。
と言われますが、アジャイルを推進するのは非常にハードルが高い。アジャイルに固執しすぎることがDX推進の妨げにつながっているのではないか？という疑問がありました。
その疑問に答える話をエンジニアがしているウェビナーがあり、今回はそのウェビナーから得た情報の考察記事です。
「エンジニアが語るDXのホント あらゆるムダを撲滅せよ！～これが0次DX」
アジャイルを推す内容でしたが、ウォーターフォールとアジャイルを客観的に比較したうえで、最終的にはケースバイケースであると締めくくっていました。
アジャイルがDX推進のネックになっている担当者には、非常に参考になるお話かもしれません。
大規模プロジェクト以外はあきらかにアジャイルがよさそう。だが…【ウェビナーの概要】
先日、内製と外製、両方の立場で仕事経験があるエンジニアが「エンジニアが語るDXのホント あらゆるムダを撲滅せよ！～これが0次DX」というウェビナーを開催していました。
主催者・金近さんは、もともと外製メンバーとしてウォーターフォール・請負契約でシステム開発をしており、現在は内製メンバーとしてアジャイルでシステム開発をしているエンジニアです。
ウェビナーでは、ウォーターフォールからアジャイルに開発手法を切り替えたことによる気づき。また、DXとアジャイルの相性の良さについてお話されていました。
実は金近さんも最初、アジャイル開発については「本当にウォーターフォールでシステム開発して大丈夫なのかな…」という不安があったそうです。ですが、外製では利益優先になるため、効率・最小限の開発を追求することになってしまうことから、世の中のためになるシステムが作れないという良心の呵責があり、思い切って転身を決意したとお話されています。
結論は、DXという文脈においてはウォーターフォールは無駄が多く対応しきれない、アジャイルの方が圧倒的に適していると証言。
一方、長年ウォーターフォール開発に取り組んでいた金近さんは、アジャイルに取り組んでみて見えてきたウォーターフォールの良さについてもお話されています。
経済産業省のDXレポートにもアジャイルを推奨する内容が書かれており、内製・アジャイル開発でなければDXは成しえないという論調になっています。
ですが本ウェビナーを通して得られた情報を元に、すこし客観的な目線で「本当にそうなのか？」を整理・まとめてみました。
ポイント① やはり、攻めのITには向いていないウォーターフォール
DXの場合、攻めのITと呼ばれるシステム開発が主流になります。従来主流だったシステム開発は守りのITと呼ばれる基幹システムです。
守りのITである基幹システムは、要件定義・設計・開発・テスト、各工程しっかり完璧に作りこみ開発を進めていく流れなのでリリースまで数年単位の時間が必要になります。上から下に逆戻りせず開発していくウォーターフォール開発で対応していました。
ですが攻めのITは、必要最小限作りこんだらすぐにリリースし、市場の反応を視ながら変化・改善を高速で繰り返していく流れです。短納期・低コスト・毎月毎週といった頻繁なリリースが基本になります。つまり、攻めのITはウォーターフォール開発では対応し切れない・限界があると金近さんは言います。
ウォーターフォールでは対応しきれない主要因は「すべて完璧に作らないとリリースできない点」。要件定義・設計・テスト、各工程完璧に作りこまなければいけないのと同時に、手間がかかるのは下請け企業への契約書。請負契約の場合、下請け企業にタスクを出すことができるのですがその時指示に不備・抜け漏れがあってはいけないため、契約書もまた完璧に作りこまなければならず、さらに時間がかかります。
さらに問題なのは、要件定義書の「重要な部分とそうでない部分の見分けがつかないこと」。顧客の要望がズラッと書かれた要件定義書は、どこに力点が置かれているかわかりません。
結果「とにかく書かれていることすべて作りこむ」ということになります。限られた時間の中で、時間をかけるべき重点ポイントと、そうではないポイントの区別がつかない中で完成させるため「顧客が重点を置いてほしかったポイント」に充分な時間と力をかけず開発されたシステムが出来上がってしまいます。
金近さんはこのことを「お城」にたとえて説明。
「お城」は手段です。顧客が欲しいモノはお城ではなく、お城という手段によって得られる何かです。
絵には3棟のお城が建っていますが、たとえばお城が欲しい理由が「お花畑を見下ろしたい」のであれば、お城は1棟で良いかもしれません。代わりに展望しやすい位置・窓などの設計に力を入れることができます。「いやいや倉庫が欲しいから3棟必要」ということであれば、お花畑の展望機能の作りこみはほどほどに、3棟作ってモノを運び込みやすい設計に力を入れることができます。
このように欲しい理由によって作るものが変わってきます。ですが、要件定義書からは理由が見えてこない。そのため、とりあえず書かれているものを全部作る、ということになり、本当に必要だったかどうか定かではない膨大なコストと時間をかけ、かつ欲しい部分に力が入れられていないシステムが出来上がるということです。
アジャイル開発の場合、顧客とこまめに話し合いながら作るため、重点的に開発すべき部分とそうではない部分を明確にし、握り合って開発していくことができるため、必要最小限のモノをすばやくリリースすることが可能になります。
ポイント② 意欲あるエンジニアは、アジャイル開発を好む
金近さんはウォーターフォール・請負契約時代、要件定義書作成や下請け企業への契約書作成、過度なテストなどにより、エンジニアの本分である「開発」に時間を割くことができない状況にジレンマを感じていました。
また「世の中のためになるものを作りたい」という根底の想いを実現することがむずかしかったと言います。
請負契約の場合、契約金額の中で利益をどう捻出するかになります。そうなると支出を減らすしかなくなり、仕様書に書かれている機能をなるべく最小限の時間で、つまりギリギリのクオリティで開発していくほかなくなります。世の中のためになるモノ作りを実現するにはほど遠い環境の中、良心と現実の板挟みに葛藤していたそうです。
アジャイル・内製の場合、書類作成の時間は必要最小限・開発に重きを置くことが出来ます。また、評価が「いかに顧客に貢献したか」に変わるため、金近さんの本来の願望であった「世の中のためになるものを作りたい」という目的にリーチするそうです。
さらに、ウォーターフォール・請負時代は「要件定義書に書かれているモノを作る」だったため、誰がやっても同じ成果にしかならない点にも不満はあったそうです。どうせなら、自分にしか出来ない仕事がしたい。アジャイル・内製であれば、顧客と話し合い、自分にしかできない仕事を自ら作り出し開発でき「イチ歯車」ではなくなります。
とはいえ、金近さんも最初は「アジャイルで本当にちゃんとしたモノなんかできるのか？ウォーターフォールでキチンとやらないとダメなんじゃないか？」と半信半疑だったと話します。結果、アジャイルで作ったほうが良いモノができることが分かり「ウォーターフォールじゃなければちゃんとしたシステムは開発できない」という固定概念にとらわれていた自分に気づいたそうです。
このお話は、意欲あるエンジニアであればあるほど「アジャイルの方がうまくいく」ということに気づけば、一気にそちらに流れる可能性を示唆しています。つまり、アジャイル・内製開発を浸透させられない企業は、意欲あるエンジニアの力を得ることが出来ないということでもあります。
ポイント③ それでも、ウォーターフォールは必要
一方金近さんは、アジャイル・内製よりもウォーターフォールが優れている点についても述べています。それは「エンジニアの能力に影響されない」点です。
ウォーターフォール・請負の場合、要件定義書に書かれていることを読み取り、それを作れるだけのITスキルさえあればよく、エンジニアを選ばない点が強みです。
また、参画してすぐに力を発揮できる点もウォーターフォール・請負の強み。すべきことが明確に決められているため、参画して2～3日で成果を出し始めることができ、この点はアジャイルでは無理だと話します。
アジャイルは少数精鋭で、それなりの能力を持つエンジニア同志でなければうまく進めることができません。作るものを自分たちで決めていく能力が必要ですし、常時こまめに相談し合いながら開発の方向性を決めていくため、一定レベル以上のエンジニア同士でなければ折り合いがつかない・時間がかかります。
実はここが、すべての企業がアジャイル・内製を推進していくことができないネックポイントです。
現在日本のITエンジニアは109万人。その内、約80万人がシステムインテグレーション業界で、ウォーターフォール・請負で働いています。金近さんのように意欲があり、システムインテグレーション業界から脱却したいと思うエンジニアが増えているとはいえ、実際アジャイル・内製で働ける能力を持つエンジニアは非常に少なく、数パーセントに満たないと言われています。また ”指示通りモノを作る”仕事に居心地の良さを感じているエンジニアが大半です。
つまり、アジャイル・内製で立ち回れるエンジニアは少ない。もうすでにメルカリなどのITメガベンチャーで働いており、アジャイルを成立させるエンジニアの獲得がそもそも困難だということです。
結局のところ、能力のばらつきが障壁にならないウォーターフォールが必要であり、ウォーターフォールで短納期リリースを実現させていく方法を模索しなければならないということです。ウォーターフォールの無駄を生む要因になっているのは「要件定義力」にあるという意見もあり、一概にウォーターフォールがすべてダメという話でもありません。
金近さんも、本ウェビナーではアジャイルを推奨してきたが、アジャイルもウォーターフォールも両方良いところがあり、また手段に過ぎないから、状況に応じてどちらを選ぶか適切に考えることが大事であると結んでいました。
まとめ「どちらが正しいか、という思考は捨てる」
アジャイルか・ウォーターフォールかという議論についてお話されていたウェビナーを題材に、それぞれのポイントを考察してみました。
●必要最小限でリリース、変化・改善を前提とする攻めのITにおいては、アジャイルのほうが適切。ウォーターフォールは時間・コストに無駄が多く出る。
●「世の中のためになるものを作りたい」という意欲あるエンジニアは、開発に時間をしっかりかけることができるアジャイル開発を好む傾向。
●一方、アジャイルに対応できるエンジニアは少ない。エンジニアの能力に左右されないウォーターフォールはまだまだ有用で、ウォーターフォールをうまく活用して回していく方法の模索は現実的に今後も必要。
DXとアジャイルはセットで語られることが多く、実際本ウェビナーでもアジャイルの方が圧倒的にDX・内製との相性が良いことは理解出来ました。
一方、結論としてそれはむずかしい事情があり、補完としてウォーターフォールが存在し続けているという実情をよくよく理解する必要がありそうです。実情を理解せずアジャイル・内製推進が進まないからDXはもう無理、とあきらめてしまう要因になりかねないためです。
アジャイルか、ウォーターフォールか。ここでも、手段を目的化せず、それぞれの一長一短を理解し、どう保管して目的を実現するかを考える力が、いま最も必要なのではないでしょうか。
参照：
「エンジニアが語るDXのホント あらゆるムダを撲滅せよ！～これが0次DX」
パワーポイント資料
執筆者
リビルダーズ編集部
