ソフトウェア開発（リーンとアジャイル） その１ からの続きです。
「アジャイル（Agile）」が広く知られるようになったのは、2001年に「アジャイルソフトウェア開発宣言」が出されてからです。
1990年代の中頃から、ユーザーと開発者が緊密な協力関係を結びながらソフトウェアを開発するための手法が登場し始めていました。「Scrum（スクラム）」や「XP（eXtreme Programming）」といった開発手法です。これら手法の関係者が集まって世に問うたのが、アジャイルソフトウェア開発宣言です。
アジャイル宣言、その歴史
同宣言では「よりよい開発方法を見つけ出す」活動を通じて、「包括的なドキュメントよりも動くソフトウェア」や「計画に従うことよりも変化への対応」などに価値を置くことをうたっています。特に「計画に従うことよりも変化への対応」は、すべてのアジャイル開発手法が共通に挙げる目的の1つです。
その背景には、2000年頃からのインターネットの爆発的な普及があります。ITとソフトウェアがビジネスの中心に位置するようになると同時に、企業におけるビジネスの変革スピードが、ますます速くなっていきました。そこでの米国企業は、「アジャイルでしか生き残れない」という状況に直面していたわけです。この状況は現在のデジタルシフトでも同じです。
日本でのアジャイル開発は、2005年ごろから先進的な取り組みが始まり、2009年には「アジャイルジャパン」というイベントが開かれています。懐かしいですね。
アジャイルは、開発者の間に徐々に浸透し、一部の開発者コミュニティではアジャイルが常識になっていきます。2010年代に入ると、ITサービスをビジネスの中心に据える先進的企業の開発現場で、アジャイル開発の採用事例が少しづつですが増えていきました。
現在では、ITサービス系企業においては、DevOps（開発と運用の統合）やCI（継続的インテグレーション）／CD（継続的デリバリー）など、アジャイルと同義の手法が広く採用されるようになっていると言ってよい状況だと思います。
アジャイル開発における代表的な手法には、Scrum、XPのほか「ユーザー機能駆動開発（FDD）」などがあります。どこに力点を置くか、どんなツールを使うかが異なるものの、すべての手法の考え方は、以下の点で共通です。
（1）できるだけ開発スコープを小さく分割する
（2）優先度順に繰り返し型で開発する（イテレーション開発）
（3）何度もリリースする
（4）すべてにおいて変更を前提に考える
ここではScrumを題材に、アジャイル開発の進め方を説明します。
アジャイルの代表的手法「Scrum」は日本発
Scrumは、Jeff Sutherland（ジェフ・サザーランド）氏らが1993年頃に提唱したソフトウェア開発手法ですが、そのコンセプトは日本発です。1986年、日本の研究者が日本企業と米国企業の組織を比較分析した研究論文において、自由度が高い日本発の開発手法を“ラグビーのスクラム”にたとえて紹介したのが始まりです。それをSutherland氏らが開発手法に採り入れたのです。
その発端からも分かるように、Scrumは「チームで仕事を進めるためのフレームワーク」です（図1）。ラグビーのフォーメーション同様、チームワークを重視するのが特徴で、技術的な仕組みではありません。これに対しXPは、プログラマー中心の開発手法で、技術的な実践を重視しています。
図1：一般的なScrumの実施手順
持つべき機能を洗い出し優先順位を付ける
Scrumでは、プロダクトが持つべき機能を「ユーザーストーリー形式」などで記述します。ユーザーストーリーは、利用者となる“顧客の視点”でプロダクトの要件を簡単に記述したもので、「役割／ペルソナ」「機能／性能」「ビジネス価値」によって表現されます。具体的には「コマースサイトのユーザーとして、商品を検索でき、それは、欲しい商品をすぐに見つけるためである」というように書き出します。
書きだしたユーザーストーリーは優先順位に応じて並び替え、開発順序を決めていきます。その際、全体像をプロジェクトチーム全員で共有するためのツールとして「ユーザーストーリーマッピング」があります。ユーザーストーリーを時系列と優先度の2軸でマッピングし、プロダクトが満たすべき要件仕様を整理します（図2）。
図2：ユーザーストーリーマッピングのイメージ
個別の開発規模は、開発チームが見積もります。ToDoリストに相当する「プロダクトバックログ」も、開発初期にすべてを確定して要求を固定するのではなく、開発を進める中で変化していきます。プロダクトバックログは、「プロダクトオーナー」と呼ばれる、その製品の責任者を中心に作成します。プロダクトオーナーの役割は、その製品の価値を最大化することです。開発チームと協力し、価値の最大化を図ります。
2〜4週を1単位に開発を繰り返す
実際の開発は、期間を固定して計画・実行する「スプリント」という単位で実施します。一般的な期間は2～4週間が多く、初日に「プランニングミーティング」を開き、直近2週間のタスクを計画します。
各スプリントでは、プロダクトバックログの優先順位の高いものの中から、そのスプリントで開発するスプリントバックログをプロダクトオーナーと開発チームが合意して決定します。この優先順位の高いプロダクトバックログこそが、第1回で取り上げたリーン・スタートアップにおける「MVP（Minimum Viable Product）」、すなわち製品出荷に最低限必要な機能に相当します。
開発チームは、そのスプリントで開発すると決めたバックログ項目の具体的な作業となる「スプリントバックログ」を計画し、それに沿って開発します。そして毎日、「デイリースクラム」を実施します。
デイリースクラムは、スプリント期間中のチームの状況を共有するためのミーティングです。通常は朝に行うので「朝会」と呼びます。短時間で「昨日やったこと」や「今日やること」、そして「起こっている問題」などを報告します。
スプリントの最終日には、プロダクトオーナーが成果物を確認する場「スプリントレビュー」を開催します。そこでは必ず、実際に動くアプリケーションを使って成果を確認します。
最終日にはスプリントの振り返りを実施します。そのスプリントで良かった点や改善すべき点、その要因と改善策などを各メンバーで議論し合い、次回のスプリントに活かすようにします。
ソフトウェア開発のリスクを小さいうちに潰していく
ここで、もう一度、アジャイル、そしてScrumが何のためにあるのかに立ち返ってみましょう。それは「無駄なものを作らない」ということです。
ソフトウェア開発には、さまざまなリスクがあります。正しく動かないシステムを作ってしまう“品質のリスク”、いつまでたっても稼働できない“スケジュールのリスク”などです。しかし、なによりも決定的な失敗を招くのは無駄なものを作ってしまうリスクです。正しく動いたとしても、それを誰も使ってくれなければ、そのために投入したコストはすべて無駄になってしまうからです。
有名な統計として「典型的なシステムでは、45%の機能は全く使われていない、さらに19%もめったに使わない」があります（『Chaos Report、Standish Group、2000』）。つまり、開発コストのおよそ60%は無駄な機能のために使われているということです。そのリスクを避けるために、Scrumでは、可能な限り優先度が高いものから順に開発していくのです（図3）。
図3：製品の有効性に関するリスク
優先度の決定において、最も大きな役割を占めるのが、前述のプロダクトオーナーです。日本の企業では、優先度などの判断が、個人ではなく組織的に依存する比率が高いだけに、プロダクトオーナーには、その判断を促進するファシリテータとして、（1）会社組織の意思決定プロセスの促進、（2）社内の現場部門との調整、といった役割が強く求められます（図4）。
図4：プロダクトオーナーの役割
リーン・スタートアップが求める組織は“顧客指向”
リーン・スタートアップは、新規ビジネスの開発を、ムダを排除しながら進めるためのマネジメント手法です。とはいえ、リーン・スタートアップだけでアイデアを生みだせるわけではありません。将来のビジネスにつながる最初のアイデアは考え出さなければなりません。
従来の製品開発型のプロセスでは、まずは製品コンセプトを作り、そこから長い開発期間をかけて、ようやく商品として市場に投入してきました。しかし、多数の製品／サービスが市場にあふれている現在では、顧客を第一に考える“顧客志向”に則った製品開発が不可欠になっています（図5）。
図5：従来の製品開発と顧客志向による開発プロセスの違い
顧客指向の開発プロセスに沿って新たなサービスを作り出すためには、それを生み出すチーム自体が“顧客志向”でなければなりません。すなわち、そのようなチームのメンバーをどう選び出すかが重要だということです。チームのメンバーは、新規事業を生み出すことへの強い意思、つまりアントレプレナーシップ（起業家精神）が必要なことはもちろん、さまざまな能力を求められます。
アジャイル開発における組織と役割は明確に定められている
アジャイル開発に対しては、ウォーターフォール型の開発に比べ、非常に自由なイメージがあるようです。しかし実際には、チームの規律が重視され、そこで果たすべき役割が明確に定められています。たとえば（1）プロダクトオーナー、（2）スクラムマスター、（3）チームなどです。
（1）プロダクトオーナー
開発するプロダクトに対する最終決定権と責任を持ち、製品価値の最大化のために正しい決定を下す。チームに製品のビジョンを伝え、製品の優先順位リストである「プロダクトバックログ」を目に見える形で最新に保ち、スクラム全体をリードする。
（2）スクラムマスター
チームをゴール達成へ導くためにチームの自律的な行動を引き出し、チームの生産性を高めるために障害物を取り除く。指示命令型よりもファシリテーター型でなければならない。
（3）チーム
開発に携わるすべての人のこと。通常は7～8人前後が適切な規模とされる。これに対し、ウォーターフォール型開発では、担当工程別に、概要設計者や詳細設計者、実装者、テスターといった役割が決まっている。
これらの役割の中で、アジャイルにおいて最も重要なのがプロダクトオーナーです（図6）。システム開発の視点だけからみれば、プロダクトオーナーは「開発チームに要求を出すだけの人」と誤解されがちです。ですが実際のプロダクトオーナーは、新しいビジネスを開発するためのリーダーでなければなりません。
図6：プロダクトオーナーを中心とした組織を構成する
筆者の経験では、プロダクトオーナーには現業部門で優秀かつ意欲的な人がアサインされるものの、現業部門の業務を担当させたまま新規事業開発に携わらせてしまうケースが見られます。その方が優秀であればあるほど、現業に忙殺され、Scrumの会議に参加できなくなり、プロジェクト自体が停滞してしまうことが少なくありません。
Scrumでは「プロダクトオーナーはスクラムチームの一員であり、基本的に専任でなければならない」という規律があります。つまり、新規事業プロジェクトのリーダーにとって最も大事なことは、チームの一員としてプロジェクトに専念できる環境が用意されることです。
ここで、リーン・スタートアップとアジャイル開発の関係を整理すると図3のようになります。システム開発の内製化が進んでいる企業であれば、いずれもが社内のメンバーで構成されますが、システム開発を外注している企業においては、企業のビジネス開発に携わるチームと、ITベンダーが用意するアジャイル開発チームが“車の両輪”になりプロジェクトを進めていかなければなりません。
図7：リーン・スタートアップとアジャイル開発（Scrum：スクラム）の対応関係
ウォーターフォール型では発注者と受注者が利益相反の関係に
図3に示したように、プロダクトオーナーが双方のチームを率いるとはいえ、ソフトウェア開発を担当するITベンダーは一般に、発注元である企業とは別の目的を持っています。すなわち、自身の売り上げであり利益の確保です。それは「より少ない業務量（経費）で、より多くの売り上げを得る」ことで達成されます。
発注者と受注者が利益相反の関係にあることは、ウォーターフォール型では明確です（図8）。発注者は要求事項をできる限り正確に低コストで開発させようとしますが、受注者は、リスクを最小限に抑えなければならないからです。
図8：ウォーターフォールモデルでの利益相反のイメージ
結果、要求事項が細部まで明確になるまで見積もりを出さない、ビジネス上の成功とは関係なく要求通りに開発し、当初の要求にない変更はすべて別料金を要求する、といったことが起こるのです。
これに対しビジネスチームの目的は、開発したソフトウェアによって生み出されるサービスを使って将来のビジネスを作り出すことです。
ただ日本のIT部門の多くが、長年に渡りコストセンターに位置付けられ、システムの運用・保守費用をいかに削減するかに注力せざるを得なかったのではないでしょうか。システム基盤をクラウドに移行するという技術的な解決策を積極的に採用することもなく、ITベンダーに工数単価の削減を要求し続けるだけのIT部門も散見されました。
企業とITベンダーの長期的な共存関係が不可欠
では、アジャイル開発なら発注者と受注者の相反関係は回避できるのでしょうか。
リーン・スタートアップやアジャイル開発におけるチームの目標は、「決定した仕様に沿ったソフトウェアを、より多くの工数をかけて、より少ないコストで開発すること」ではありません。「無駄なく、より速く、より良いものを作り出す」ことこそが目標です。そこにこそ、ビジネスチームとアジャイル開発チームが一体感を持て、プロジェクトを成功に導くための鍵があると筆者は考えています。
2018年末のIT業界は、労働者不足や働き方改革など、さまざまなニーズが顕在化したことで、ビジネス面では活況を呈しています。一方でIT業界自身の人材不足という課題もあります。人件費や人材採用コストの高騰に悩まされ、ITベンダーの側から保守契約の継続を断るという、従来では全く考えられないようなケースまでが多発しています。
ソフトウェアは、発注者である企業と受注者であるITベンダーが、長期的な共存関係を継続できてこそ、より良いシステムが構築・運用できるはずです。デジタルシフトにおいては特に、ITベンダー側にビジネスに対する深い理解がなければ成功は望めません。
※この記事は以前、Webメディア（（DIGITAL X（デジタルクロス） | インプレス社））に連載したものを、最近の自分の問題意識とともに手直ししてまとめ直したものです。あと何回かにわけて書いて行きたいと思います。
ソフトウェア開発（リーンとアジャイル） その３ に続きます。