その本の「はじめに」には、著者の「伝えたいこと」がギュッと詰め込まれています。この連載では毎日、おすすめ本の「はじめに」と「目次」をご紹介します。今日は堀哲也さん、稲荷裕さん、木村秀顕さん、柴㟢秀算さん、廣瀬志保さん、石橋正裕さんの 『誰も教えてくれなかったアジャイル開発』 です。
【はじめに】
「『ちゃんとしたアジャイル』って、やったことないんですよ」
「うちの会社には、アジャイルはまだちょっと早いかもしれませんね」
アジャイル開発といえば、こういった弱気な声ばかりが聞こえてくる。
ビジネスコンサルティングを手掛けるシグマクシスはコンサルティングサービスの一環として、ウオーターフォール型開発で情報システムを構築してきた企業向けに、アジャイル開発の方法を紹介する研修を開催している。受講者は情報システム部門や事業部門の人であり、発注者としてシステム開発プロジェクトを管理・推進する立場にいるケースが多い。冒頭の発言は、そのアジャイル研修でよく耳にする受講者の声である。
1つ目の声は、アジャイル開発の方法論の1つである「スクラム（Scrum）」を厳格に適用したプロジェクトこそが「ちゃんとしたアジャイル」であると捉え、それに対して自分たちが実際に携わっているプロジェクトの実態とのギャップから出た発言であろう。
2つ目の声は、「トップダウンで組織を変革し、アジャイル開発に成功」といった成功事例と自社の状況を比べた結果の、諦めに近い発言である。いずれも、アジャイル開発を実施するうえでの心理的ハードルの高さや、実施した結果を「成功事例」として周りに広めることの難しさを示している。
アジャイル開発の基本的な考え方を17人の著名なソフトウエアエンジニアがまとめ、アジャイル開発の出発点となった「アジャイルソフトウェア開発宣言」が公表されたのが2001年。そこには「プロセスやツールよりも個人との対話を価値とする」「包括的なドキュメントよりも動くソフトウエアを価値とする」「契約交渉よりも顧客との協調を価値とする」「計画に従うことよりも変化への対応を価値とする」とある。
同宣言から20年たった今、様々な文脈で「アジャイル」という単語を目にするようになった。サービス開発から業務改善、組織変革に至るまで、アジャイルの考え方をどう取り入れるかといった方法や実際の成功事例など、多くの情報であふれている。一方で「本家」であるソフトウエア開発についてはどうだろうか。スマートフォンのアプリやゲームなど新しいジャンルでの成功事例は多いものの、「企業の情報システムをアジャイル開発で刷新し、DX（デジタルトランスフォーメーション）に成功した」という類いの事例があふれている状態ではない。
原因は様々あるが、大きなものとして、世にあるアジャイルに関する情報の多くが、開発者向けの技術要素が強いものか、組織論・文化論といった概念的なもので占められており、実際にシステム開発プロジェクトの推進を担当するシステム部門や事業部門の担当者がすぐに使えるノウハウを紹介したものが少ないことがあるだろう。企業の情報システムを担うシステム部門や事業部門の部員にこそ、もっとアジャイル開発を理解し、身近に感じ、そして実践してほしいと我々は考えている。
魔法の杖ではない
シグマクシスのメンバーは企業のシステム開発プロジェクトにおいて、プロジェクトマネジャーを支援しつつプロジェクトを推進する組織である「PMO（プログラム・マネジメント・オフィス）」にビジネスコンサルタントとして参画し、企業と開発ベンダーとの間に立ちながら開発プロジェクトを推進する役割を担うケースも多い。従来はウオーターフォール型開発プロジェクトが多かったが、ここ数年はアジャイル開発プロジェクトにも多数携わるようになった。
プロジェクトを成功させるための準備として我々自身も数々の研修を受講し、書籍を読みあさり、経験者からアドバイスをもらい、成長してきた。そうして臨んだ数々のプロジェクトで得た体験や学びは、「開発者」としてではなく「推進者」としてプロジェクトを成功に導く責務を負った方々にこそ有益なのではと考え、本書を執筆し始めた次第だ。
本書では「アジャイル開発は何でもできる」とは言わない。また「洗練されたアジャイル開発の環境」を紹介することもない。アジャイル開発は魔法の杖ではなく道具をそろえれば成功するわけでもないからだ。ただ我々が数々の実体験から自信を持って言えるのは、アジャイル開発は間違いなく「実際に手の届くところにある現実的な解決手段の1つ」であるということだ。
今回、我々は実体験を「基礎編」「実践編」「応用編」の3つに整理した。「基礎編」では、実際にプロジェクトを推進する現場の視点からアジャイル開発の基本的な考え方を紹介し、教科書通りに進まない場合の対応方法もまとめた。
「実践編」では、きょうから使える現場のノウハウをプロジェクトのシーンごとにまとめた。「応用編」では、ウオーターフォール型開発とアジャイル開発のハイブリッド開発や、ローコード開発やSaaS（ソフトウエア・アズ・ア・サービス）活用、サービス開発におけるアジャイル開発の適用についての注意点を解説している。
必ずしも順番に読んでいただく必要はなく、「今困っているところ」から読み進められるように工夫している。実行できそうな内容を今すぐにでも取り入れていただき、プロジェクトの成功に貢献できれば何より幸いである。
「アジャイル開発」とは
そもそも「アジャイル開発」とは何か。一般には「ソフトウエア工学において迅速かつ適応的にソフトウエア開発を行う軽量な開発手法群の総称」とされている。開発現場寄りに言い換えれば、短い開発サイクルでプログラムをリリースし続け、エンドユーザーのフィードバックを受けながら改修を重ねることで、アウトプットを洗練させていく開発手法だ。
アジャイル開発では、2週間から1カ月ほどの短期の開発サイクルを設定する。これを「イテレーション」または「スプリント」と呼ぶ。プログラムの開発要件を分解し、各イテレーションに割り振る。1イテレーションの中で実装したプログラムをエンドユーザーがその都度確認する。このサイクルを繰り返し、ユーザーにとって価値のあるものを短期間でスピーディーに提供し続ける。
アジャイル開発の特徴とは
アジャイル開発の特徴は、エンドユーザーのフィードバックを受けながら要件やゴール（成果物）を柔軟に変更する点にある。従来のウオーターフォール型開発はプロジェクト開始時に全体の作業計画を決める。一方、アジャイル開発ではプロジェクト開始時点では全体の作業計画は概要にとどめ、直近の計画をつくり込み、これを継続的に見直すことで、全体の作業計画をつくり上げる。その過程で当初イメージしていたゴールが変更になるケースも多い。また、アジャイル開発では、ウオーターフォール型開発のようにドキュメントを網羅的に作成しないため、チームの外からはプロジェクトの状況把握が難しいとされる。
このようなことから、アジャイル開発の手法は、中央集権型で計画重視の組織にはフィットしにくいと考えられており、多くのアジャイル方法論はアジャイル開発を採用するには、まず企業の組織や文化の変革が必要だと説いている。
【目次】
