「本記事はQmonus Value Streamの投稿キャンペーン記事です。」

はじめに

今回記事投稿キャンペーンを通して「アプリケーション開発に注力する工夫」というテーマについて過去を振返り、僕の開発環境が根本的かつ圧倒的に改善された体験として、この「アジャイルの魅力」をテーマとした記事の執筆に至りました。

個人的な経験から、開発に注力したい と悩まれている方の多くは、
「開発に注力できる工夫を取り入れたいけど、"改善"の優先度が低く、工夫を取り入れるために試行錯誤できる余力がない、、、」
という悩みを持たれている方が多くいるのではないかなと思っています。

そういった課題の根本解決の例として、僕の経験をもとに、
アジャイル開発を通して、エンジニア自身の力で "開発に注力できる工夫を取り入れられる環境" を維持し続けられる　様になった経験についてお伝えできればと思っています！

対象の読者

ユーザーにとって価値のあるサービス開発に注力できてない と感じる方
開発環境を改善したい と思ってる方
ウォータフォール開発でなんとなく開発 をしている方、または 度重なる仕様変更にフラストレーションを抱く 方
ウォータフォール開発とアジャイル開発の違いはリリース期間にあると認識している方
アジャイル開発に興味があるが実践したことない方、またはアジャイル開発を実践しているがあまり良さを感じられていない方

バックグラウンド

僕は元々SIer企業にてPM/PL兼エンジニアとして、ウォータフォール開発 と アジャイルもどきの開発 (リリーススパンを単に二週間定期にした開発)手法を経験してきました。
その後、自社サービス系の企業へ転職し、内製開発のエンジニアとして　アジャイルスクラム開発 を経験した際、それまでのアジャイル開発に関する理解が全く本質でなかったと感じる体験をしました。

開発効率と開発体験が大きく改善され、本当の意味で プロダクトの開発、つまり ユーザーにとって価値のあるサービスや機能を作ること へ注力できる様になったと感じています。

この記事で伝えたいこと

アジャイル開発の価値は「リリースまでのスパンが短く、早く市場に機能を出せる」こと？
よくアジャイルはプロジェクトマネジメント視点で、この短期間のリリースの価値にフォーカスされることが多いですが、実際にはそれは アジャイルの文化による副産物 だと言えます。

アジャイル開発の本質的な価値は、実は "アジャイルというボトムアップの文化" にあります。

この ボトムアップの文化　は　エンジニア発信の継続的な改善を促進 し、環境やメンバーの変化に応じて柔軟に進化 していくことができます。エンジニアがエンジニア自身で常に最も効率的に作業しやすい環境へと変えていく ことで、 常にエンジニアの力を100%引き出し続け、チームとしての力を最大化し続けてくれます。

この記事を通して、この アジャイル とその ボトムアップの文化 が生み出す価値について興味を持って頂き、少しでも多くの方が 改善に注力できる環境を、エンジニア自身の手で作り上げられる きっかけになったら嬉しいと思っています。

(参考: https://agilemanifesto.org/iso/ja/manifesto.html)

アジャイル開発の価値

アジャイル開発 を一言で言い換えると、ボトムアップの開発手法 と言えます。
対話を重視し、より良いプロダクトを目指して、エンジニア発信の改善を繰り返していく、変化を受け入れる比較的に柔軟な開発手法と言われています。

アジャイル開発の開発チームのマインド

アジャイル開発では、一般に下記の様なチーム体制で開発が進みます。

プロダクトオーナー
スクラムマスター
開発チーム

(引用: https://www.atlassian.com/ja/agile/scrum/roles)

アジャイル開発では、"スプリント" と呼ばれる二週間など短いスパンで、下記のようなミーティングを繰り返し実施していきます。

スプリント計画
スプリントレビュー
デイリーミーティング

特に、スプリントレビュー ミーティング内では、スプリント内で実施した内容を振り返り、良かった点や改善すべき点などについて、エンジニアがボトムアップで議論していきます。これらミーティングを通して、各スプリントで自然とPDCAサイクルを実施する文化が醸成されていきます。

アジャイル開発における 開発チーム では、作り出す機能やプロダクトに責任を持ち、ユーザーにとって継続的に価値あるものを提供し続けるマインド を持ち、下記の様な議論が活発になされることになります。

ユーザーにとって価値がある機能/プロダクトになっているか
より効率的に開発するにはどうすべきか
現状の/将来的な開発にリスクはないか

このマインドはエンジニアとしてシステムを開発する上で本質的で重要なポイントですが、日々のスケジュールなどに追われる環境下で、意外と忘れられがちなポイントなのではないかなと思っています。

ウォーターフォール開発からアジャイル開発のマインド変化

では、ウォーターフォール開発をしていたエンジニアが アジャイルの開発 に移行することでどんな変化が生まれるのでしょうか？

ウォーターフォールとアジャイル

ウォータフォール開発 は、 トップダウンの開発手法 です。
決まった要件に基づいて設計・開発・テストを効率的に進めるという、手戻りをすることを良しとしない比較的に 堅い開発手法 であり、一般に半年や一年などの長いスパンでリリース計画を組み、特定のスコープの機能を断続的にリリースをする手法です。

一般に ウォーターフォール開発 と アジャイル開発 の大きな違いとして、リリースのスパン に焦点が置かれますが、これは単なる付加価値であり、本質的な価値は開発手法の変化による マインドの変化 にあると思っています。

マインドシフト

ウォーターフォール開発では、要件定義や設計、開発など工程を分けて、それぞれFIXした成果物とスケジュールの中で開発をするため、エンジニアはどうしても視座が下がりやすく、とにかく期間に合わせて求められた機能を完璧に作るという、職人的なマインドを持ちやすい環境下にあります。

しかし、アジャイル開発をしていくためには、この様な職人的なマインドから、「ユーザーにとって価値あるものを作る、そのためにエンジニアとして何をする必要があるか」ということを エンジニアそれぞれが考えなければならないボトムアップの思考 へとマインドシフトが必要になります。

この職人的なマインドを残したままだと、曖昧な要件や見通しの悪さに「何を作ればいいかわからない」、「要件が曖昧」、「品質が悪くなるから作れない」などといった、サービスの価値創出の前段階で躓き、アジャイルの本来の価値を体験できなくなってしまいます。

マインドの変化が持たらす価値

では、この　ボトムアップのマインドの変化 が開発にどんな好影響をもたらすのでしょうか？

ウォータフォール開発では、開発の遅延をどこで吸収すべきかや、どの機能を落とすべきか、いつまでに何を完了させるか、要件修正の影響範囲などといった暫定策の議論が多く交わされた印象ですが、
アジャイル開発では、イテレーションが多いため「根本的に何が問題で、次のスプリントからどう改善していくか」という議論を各スプリントレビューで継続的に話し合い続けることになります。そのため、根本的な問題を解消できていない 暫定策ではなく、恒久策 を必然的に検討していかなければなりません。

また、恒久的な対策であっても、技術や周辺環境の変化とともにすぐに廃れてしまうことも少なくありません。そのため、定期的に改善を繰り返し続ける仕組みは不可欠であり、対話や議論を繰り返して継続的な改善を行なっていくことこそがアジャイルの文化であり、最も重要な価値になります。

これらの議論の中では、「品質が悪いのでテストカバレッジをあげるべき」、「テストカバレッジをあげるために過剰に工数がかかっていないか」、「CIを導入して品質を担保すべき」、「恒久的な改善を取り入れる工数が足りていない」など、開発者発信の改善案を話し合われていきます。

この様な継続的な改善を続ける仕組みは、
環境やメンバーに応じて柔軟に進化していき、常にエンジニアが最も効率的に作業しやすい環境へと自分たちで変えていき、エンジニアの力を100%引き出し続け、チームとしての力を最大化してくれます。

開発手法の選択ミスマッチとアジャイルへの移行

ここまで聞くと、アジャイル開発 を選択すべき開発方式と言っている様に聞こえますが、ウォータフォール開発 と アジャイル開発 はどちらが良いという絶対的な評価はありません。

ウォータフォール開発とアジャイル開発の適性

(出典: https://www.galk-jp.com/blog/agile-development-waterfall/)

開発手法の適正

下記の表は前の章で説明したウォータフォール開発とアジャイル開発をまとめたものですが、この表を見ても分かる通り、「ウォータフォールとアジャイルどちらが適した開発か」は開発の規模や目的、スキルセットなど様々な要因によって異なります。

	ウォータフォール開発	アジャイル開発
文化	トップダウン	ボトムアップ
柔軟性/堅牢性	堅牢(手戻りをすることを良しとしない)	柔軟(変化を受け入れる)
リリース期間	長期(半年~一年)	短期間
継続性	断続的	継続的
適正	金融など要件が決まっているシステムや、大規模なシステムなど、堅実に開発を進めたいプロダクト	スタートアップなど変化が激しい業界のシステムや、小規模なシステムなど、柔軟に開発を進めたいプロダクト

開発手法のミスマッチ

ただ、日本ではこれらの適性とは関係なく、仕様変更発生の確率が高いにも関わらずウォータフォール開発`を採用してしまうというミスマッチ が起こっているケースが数多く存在すると思います。こう言ったミスマッチは後工程における仕様変更や、柔軟さを確保するための過剰な設計などを引き起こしてしまいます。

では、なぜ日本ではウォータフォール離れしににくく、こういった開発手法と適性のミスマッチが発生してしまうのでしょうか。 まずは、その要因について次の章で考えていきたいと思います。

ウォータフォール開発を選択してしまう日本の開発現場

前の章で述べた通り、日本では開発手法の適正によらず、ウォーターフォール開発 が採用されやすく、アジャイル開発 があまり浸透していません。この要因について、まずは世界と日本におけるアジャイル開発の採用率を比較しながら考察していきたいと思います。

世界と日本におけるウォータフォール/アジャイル開発

海外では一般にアジャイルによる開発がメジャーといわれていますが、日本ではまだまだウォーターフォールよる開発が一般的で、アジャイルが検討される機会は多くありますが、採用まで至らなく、まだウォータフォール離れできていないのが現状かと思います。

実際、IPAの出している下記のDX白書2023では、
アメリカにおけるアジャイルの採用率(※1)は70-80%程度であるにも関わらず、日本ではまだ30%程度に留まっているとのデータがあります。
(※1: アジャイルの採用率 は全面的に取り入れていると一部取り入れているを合わせたパーセンテージを示しています。)

(参考: https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108041.pdf)

この差異には、日本のリスクを取らない保守的な考えが新しい手法を採用できないことが要因など、色々と諸説ありますが、日本特有のシステム外注の文化 が一つの大きな要因になっていると経験を通して感じています。

日本は終身雇用の文化があるため、基本的には人材を企業側から減らすことができないため、事業フェーズに合わせたスケーラブルな人件費のコントロールが難しく、外注という手段で期間的にスケーリングをする必要があります。

実際に、下図のデータを見てわかる通り、日本では 内製による自社開発 が25%程度を占めており、海外の53%と比較し、多くのシステムが 外注もしくはSaaS により開発されているということがわかります。

(参考: https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108041.pdf)

システム外注時には、「いつまでに何を作る」と言うことを要件定義時に明確化して合意をとりやすい ウォータフォール開発 が採用しやすくある傾向にあります。しかしこれは あくまで企業や文化の都合であり、開発するシステムの事業に適した選択とは言えません。

開発手法のミスマッチが引き起こすトラブル

上記の様に事業に適さない開発手法を選択してしまった場合、事業(ビジネス)側としては、事業や環境変化により、周囲環境や状況の変化に応じた柔軟な変更が必要 となるため、当然としてウォータフォール開発を進めている間にも要件変更をしたいケースが発生します。
一方で 開発側としては、ウォータフォール開発として、変更や手戻りを良しとしないため、プロジェクトマネジメントではこの変更を上手く調整する必要 が発生します。

要件の変更が拒否されれることは事業変化に対応できず開発したプロダクトと事業環境のミスマッチを引き起こし、要件の変更を受け入れることは手戻りの発生によるプロジェクト品質の低下を引き起こす、といったどちらも引けない議論の結果、事業側か開発側どちらかが妥協をせざる負えないシステム開発がなされることになります。

アジャイルへの移行

アジャイル移行への障壁

ここまで アジャイル開発の価値 や 開発手法選択のミスマッチ についてご説明しました。
恐らくこの記事を読んで頂いている多くの方は、「そうは言っても、自分は開発手法を変えられる様な役割ではない、、、」と思っているのではないかなと思います。

私も実際、SIerにいた際にはPM(PL)もしていましたが、開発手法を選択する というステップを踏んだことはなく、新しいプロジェクトがスタートしたらWBSを引いて自然と実績のあるウォーターフォール開発を選択しており、そこで　最適な開発手法を選択する という決定権はありませんでした。

では、どうしたらビジネスにあった "ビジネスに適した開発手法"へ移行できるのでしょうか。

アジャイル移行へのステップ

繰り返しになりますが、アジャイルは文化　です。
エンジニア発信のボトムアップで改善を続ける文化が、リリース頻度の改善やCI/CD、DevOpsなどを生み出していきます。

なので、まずは2週間に1回など定期的なスパンで 振り返りミーティング を設定してみるところから初めて見てください。
その 振り返りミーティング の中で、その定期的なスパンを振り返り、エンジニアからボトムアップでプロジェクトの中で良かった点や改善が必要な点について是非話し合って見てください。

きっと、その ボトムアップの議論 を通して、「リリースの頻度が少ない」、「改善に使う工数が確保できていない」など多くの議論がなされ、開発者発信の改善案を話し合い、エンジニア自身でエンジニアが100%開発に注力できる環境に少しずつ近づけていくことができる様になります。

この ボトムアップの文化　さえ醸造することができれば、もう アジャイルの価値 は体験できるかと思います。その継続的な議論の末に、もし「そもそもウォータフォール開発がプロジェクトに適していないのでは？」というボトルネックに辿り着いた際には、ボトムアップの文化 が組み込まれた開発手法である アジャイル開発 のテンプレートに則ったやり方、つまり アジャイル開発 へとシフトしていくことができるかと思います。

最後に

この記事を通して、
"開発"に注力しすぎ、"改善"に目を向けられていない と感じるエンジニアの方が、エンジニア自身の力で 100%の力を発揮し続けられる環境を醸成し続けていける様になる　と良いなと思います！
長い文章になりましたが、最後までご覧いただきありがとうございました！

宣伝

会社員として働く側、下記の様なサービスを個人/チームで作っています！良かったら、ぜひ使ってみてください！