RON_wanwan
2020年06月26日更新 790 Views

日本企業へのアジャイル開発導入

アジャイル開発では、ソフトウェアの機能を、短期間で、細切れに、リリースしていくアプローチをとります。この開発手法の導入を試みている/検討中の日本企業が増えていることと感じますので、下記備忘録。
内製開発を進めている企業もあることと思いますが、自社では企画・プロジェクト管理等が中心で、実際の開発はITベンダーに発注している企業も多いことと思うので、今回はそういった企業の観点(顧客側)で情報を整理してみます。

何故アジャイル開発手法が注目を浴びているのか?

・市場のニーズは日々変化し複雑化している。それに柔軟に対応しなければならない。
・新たなビジネスモデルを展開する企業の台頭。大企業にも焦りがある。
など、まず対応スピードを強化していくニーズが挙げられることと思います。

ただ上記に加え、アジャイル開発手法の特徴である、仮説検証しながらPJを進めビジネス価値最大化を目指していく、というアプローチが、注目を集めている理由ではないでしょうか。

どれぐらいの日本企業が取り組んでいるのか?

下記はガートナージャパンが発表した、日本国内におけるアプリケーション開発に関する調査結果である。
<調査概要>
・2018年4~6月に従業員数20人以上の日本企業を対象に実施。
・回答者はユーザー企業のITリーダー有効回答企業数715社。
・アプリケーション開発手法を下記のよう3つに分類し調査。
 1. ウォーターフォール型開発:従来の明確で固定された要件を扱う手法。
 2. 反復型開発:段階的なウォーターフォールで進め、各段階の後にフィードバックを行う手法。
 3. アジャイル型開発:期間とリソースのみを固定し、スコープは固定しない手法。

※個人的には上記2、3、の定義はあまり明確でない印象。アジャイル開発といいつつ、連続的なミニウォーターフォールを行っている企業もあるかと。

<調査結果>
図:各開発手法に関する現在および今後の方針
スクリーンショット 2020-06-24 15.31.18.png
出典:ガートナー (ITデマンド・リサーチ)/調査:2018年5月
https://www.gartner.com/jp/newsroom/press-releases/pr-20190221

・ウォーターフォール型を「採用中」と回答した割合が43% (継続/拡大28%、縮小15%) と最も多い結果。
・反復型が16% 。(継続/拡大15%、縮小1%)
・アジャイル型を「採用中」という回答率は17%。 (継続/拡大15%、縮小2%)

<特筆点>
・ウォーターフォール型で「採用中:縮小」と回答した割合は15%となっていることから、徐々にウォーターフォール型開発を縮小していく意向が現れている。
・反復型では9%、アジャイル型では13%が「未採用:採用予定あり」がとなっていることから、非ウォーターフォール型手法採用が今後も拡大するものと予想される。

アジャイルとは何か?

アジャイル(Agile)とは、直訳すると「素早い」「機敏な」という意味になりますが、迅速かつ柔軟にソフトウェア開発を行う、開発手法群の総称です。2001年当時軽量のソフトウェア開発を提唱していた17名の有識者たちによって、「アジャイルソフトウェア開発宣言」が策定されました。

<アジャイルソフトウェア開発宣言> 一部抜粋
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。

出典:アジャイルソフトウェア開発宣言
https://agilemanifesto.org/iso/ja/manifesto.html

ただ、アジャイル開発の特徴って下記が大きいのではと思います。
<アジャイル開発の特徴>
・反復的な仮説検証型アプローチ
開発期間を短期間に区切り、細かく分割した機能を、繰り返し開発していく。顧客には動くソフトウェアを見せながら、認識を合わせつつ進める。
・確保されたスコープの柔軟性
スコープは固定せず、工数・期間のみを固定する。その決められた作業量の中で、要件の優先度を適宜見直しながら、優先度の高いものから柔軟に対応していく。
・顧客を巻き込み構築される体制
顧客もメンバーの一員となり関連ベンダーとチームを組成し協業体制を構築する。チーム内では、共通のビジネスゴールを目指す。

アジャイルとウォーターフォールの違い

下記図は総務省の令和元年版情報通信白書にて記載されている、アジャイルとウォーターフォールの違いを示したものです。

スクリーンショット 2020-06-25 15.19.09.png

出典:総務省(2019)「デジタル経済の将来像に関する調査研究」ITmedia エンタープライズ記事を基に作成
https://www.soumu.go.jp/johotsusintokei//linkdata/r01_04_houkoku.pdf

上記からも見て取れるよう、
ウォーターフォール開発は、工程を「要件定義」「設計」「開発」「テスト」に分割し、開発を進めていきます。基本的に前工程に戻ることはなく、上流の要件定義で全てを計画し、そこで定義されたものを全て計画通り開発することを目指します。(仕様・要件の途中変更は想定されていない)リリースのタイミングは全工程が完了した後となります。

一方アジャイル開発では、期間を区切って(イテレーション、フレームワークによってはスプリントとも呼ばれる)細かく機能を分割し、開発を進めていきます。1イテレーションは1~2週間程度が一般的で、イテレーションごとに機能をリリースすることを目指します。リリースのタイミングも早く、各イテレーションのテスト結果も踏まえることができるので、工数を抑えた不具合への対応や、ビジネス価値最大化に向けた変更、改善が行えます。

<その他の比較>

ウォーターフォールアジャイル
思想事前に全て計画。決まったものは全て計画通り開発。顧客にとってのビジネス価値最大化を重視。計画を柔軟に変更しながら開発。
見積スコープを固定し必要な工数と期間を見積もる。工数・期間を固定し見積もる。そこで定義された作業量の中で、対応可能なスコープをやっていく。
契約請負契約(成果物責任有)準委任契約(成果物責任無)*請負で対応するケースもあるそうです。個人的には途中の仕様変更を前提とするアジャイル開発手法において、事前の成果物定義ができない中、請負契約で対応するのは難しいのではと思ってしまいます。
チーム顧客、要件定義、開発、テスト、と工程毎に担当者が異なる。スキル・役割を考慮しながらメンバーを固定でアサインし、チームを組成。そのチームでイテレーション(全工程)をまわしていく。顧客もチームに参加する。*顧客は、短期間で開発されてくる機能のレビューや、優先順位の再検討等を担う訳だが、ビジネス部門とIT部門の双方からの参画するのが望ましいと思われる。
ドキュメント工程ごとにメンバーが変わるので、基本的にドキュメントベースでPJを進める。工程ごとにメンバーは変わらないので、運用保守やシステム拡張に関するものなど、必要なもののみ作成する。

アジャイル開発導入の難しさ

色々あることと思うのですが、まず思いつく点を記載しておきます。

<導入時の難しさ>
・不確実性を許容できない日本企業
前述の通り、アジャイル開発ではスコープの固定が行われません。つまり、何がいつできるか分からないままPJを立ち上げることとなります。従来のウォーターフォールのプロセスでは、事前に全てが計画された上で見積を取得し、その価格妥当性の検証を行い、投資対効果を含め経営に説明しPJ開始を迎えることが多かったことと思います。アジャイルではこの不確実性を、経営レベルを含め合意していく必要が生じます。

・「アジャイル」に対する麗しき誤解
アジャイル開発手法を新たに導入する場合、その企業内で「アジャイル」という言葉が一人歩きし、誤解を持っている関係者がいる可能性があります。社内経営層を含めたステークホルダー間の認識を合わせた上、PJを始める必要があります。

<よくある誤解>
・アジャイルでは計画は不要で、まずはやってみることが大切?
確かに「アジャイル・マニュフェスト」には「計画に従うことよりも変化への対応を、価値とする」という記載がありますが、計画が不要と書いている訳ではありません。アジャイル開発では、ウォーターフォール開発以上の綿密な計画が必要となります。短期間のイテレーションごとに、動くソフトウェアの開発を求められるものなので、この数週間の過ごし方が細かに計画される必要があることはご理解いただけることでしょう。ただ作業の進捗に沿って必要な計画を行っていく流れになるので、各詳細計画はイテレーション開始時のプランニングにて作成されます。

・アジャイルでは自由に要件を変更して良い?
イテレーション内で実装中となっている機能に対して、要件変更をすることはできません。繰り返しですが、数週間での機能リリースを目指している中なので、当然のことかと思います。途中でビジネス価値の高い要件変更が生じた場合は、次のイテレーション以降で対応することとなります。その場合は通常、顧客がビジネス価値に基づき、固定されたチームの作業量を鑑み、優先順位の低い要件を削ぎ落とし入れ替えを実施(=優先順位の見直し)することとなります。単に「追加要件を押し込む」といった行為は回避する必要があります。 etc...

他にも、アジャイルでやればコストって下がるよね?というコメントも耳にすることがありますが、コスト削減を重視するのであれば、ウォーターフォール開発で仮説検証なく一気に開発してしまった方が効率的と言えるでしょう。ただ、アジャイルの場合、少ない機能で目指す価値が達成できるとなれば、当初の要件を削ぎ落とすことがあるので、場合によってはコスト削減に繋がることがあるかと思います。

その他参考文献

アジャイル開発への道案内
片岡 雅憲 (著), 小原 由紀夫 (著), 光藤 昭男 (著), 日本プロジェクトマネジメント協会 (編集)

関連記事

割り込みタスクは自律神経使って疲れるから午後3時ぐらいにスラック通知オフにして作業に集中しようという趣旨
2020年06月23日
ホームへ戻る