本記事ではこれからスクラム開発を始めようとする方、スクラムに興味のある方に向けて記事をまとめます。僕自身は認定スクラムマスターでもあり、開発の現場でもスクラムで開発を行なっています。その経験も踏まえてお話してみます。
ソフトウェアの開発手法
ソフトウェア開発手法についてまずはお話します。スクラムはアジャイル開発手法の一つになりますが他の方法と比較して全体を俯瞰してみてみましょう。全ての手法の話はしませんがよく知られている手法について取り上げてみます。なお以降は下記書籍を参考にしつつまとめています。
ウォーターフォールモデル
ウォーターフォールモデルは日本では現在もよく利用される開発手法です。各フェーズがきっちり分かれておりシンプルであるため把握しやすいことが利点であり、一旦決めたことを粛々と行うだけで良いケースにおいてはマッチする手法でしょう。
しかしソフトウェアの開発においては要求、技術の変化が開発中であっても頻繁に起こります。ウォーターフォールモデルではそうした状況にはなかなか対応が難しいでしょう。僕自身はウォーターフォールモデルで開発をした経験はありませんが国内のSIerなどではこういった手法は利用されています。
出典：ウォーターフォールモデル
V字モデル
V字モデルではウォーターフォールモデルよりも特にテストフェーズの捉え方が細かくなっています。図を見るとわかりますが単体テスト、結合テスト、システムテスト、受け入れテストとウォーターフォールモデルでは一括りにされていたテストフェーズについて細かく分類されていますね。(下記図ではコードレビューのフェーズがありますが一般的にはV字モデルの中ではあまり記載されないように思います)また、定義に関わるフェーズとテストフェーズの紐付けも図内で示されている点もV字モデルの特徴です。単体テストに始まり結合テスト・・・と部分から確認を行い徐々に全体を確認する、という流れが示されています。
出典：https://webrage.jp/techblog/v_shaped_mode/
アジャイル開発
アジャイル開発という言葉は開発手法の名称ではありません。変化に迅速に対応することを目指した軽量な開発手法の総称になります。そのためアジャイル開発手法といったときにはその具体的な手法は様々ありますがそれらに共通する特徴として以下のようなことがあります。
- 短期間に活動を繰り返し、段階的に開発を進める
- 活動の中で積極的にユーザとやりとりを行う
そのときそのときのベストエフォートで成果物(システム)を提供するというアプローチです。
下記図がアジャイル開発手法には様々あることを示しています。日本でも知られている手法としてリーン、XP、そしてスクラムについて記載がありますね。
出典：Agile Scrum Methodology: Complete Guide for Developers and Testers
こちらのイラストではアジャイルという木の幹を中心にKanban、Scrum、XP、Lean、FDDが表現されていますね。この木のイメージで覚えて頂くとアジャイルとスクラムの関係はわかりやすいですね。
スクラム
それではアジャイル開発手法の一つであるスクラムというフレームワークについてお話します。全体を把握するにはこちらの図が一番わかりやすいでしょう。
出典：アジャイル開発
いくつか聞きなれない用語があると思いますが、ある期間(1〜4週間程度、スプリントと呼びます)で開発＆リリースを繰り返す流れになります。そしてアジャイル開発手法の特報としてユーザとのやりとり、段階的な開発を行うための仕組みもフレームワークの中で定義されています。
詳細な手法までは本記事では記述しませんがスクラムというフレームワークの最もいい点として軽量なフレームワークであるという点があると僕は考えています。軽量な、という点がどういう意味かというと、フレームワークについてまとめたドキュメントが非常にコンパクトである、つまりルールが非常に少ないという点が一つあるでしょう。
スクラムについて書籍は数多くありますが公式なドキュメントというのは実は一つだけです。日本語にも翻訳されているのはありがたいですね。
出典：スクラムガイド - Scrum Guides
20ページもないドキュメントです、でもここにはしっかりとスクラムのルールが全て記載されています。書店で販売されているスクラムの本も素晴らしい書籍が数多くありますがこちらの公式ドキュメントも興味がある方はぜひ一読頂くといいと思います、ボリューム少ないですしね。
なおスクラムについての書籍を読みたい方には下記書籍もお勧めです。
スクラムについては上述した通りルールが少なく軽量なフレームワークである反面、実際の現場で実践することは非常に難しいです。そういった意味で僕自身は日本ですでに現場でスクラムを実践してきた方々の経験が記述されたスクラム実践入門をお勧めします。一部書籍の目次を引用します。
第６章 GMOペパボの事例 -どのように導入したか- 第７章 mixiの事例 -導入失敗からの立てなおし- 第８章 -大規模開発、業務委託への適用- 出典：スクラム実践入門
様々な企業での実際の導入事例を知ることができ参考になる書籍です。僕自身も現場で初めてスクラムマスターとしてチーム立ち上げをしていた際には何度もこちらの本を読み返していました。書籍全体は実際にスクラムを実践してきた方々が連名で執筆していますのでタイトル通り非常に実践的な書籍になっています。ぜひ一読ください！
日本とスクラム
さて、最後は少し視点を変えて日本でのスクラムの実践状況についてデータでみてみましょう。下記はIPAが2012年に公開した認定スクラムマスターの人数についてのグラフです。
出典：非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書
2012年のデータのため若干古いですが他の国と比べ日本では認定スクラムマスターの人数が圧倒的に少ないことがわかります。認定スクラムマスターが少ない、ということはスクラム、アジャイル開発をしている開発現場が日本では非常に少ないということが推測できます。
さて、データからも実際にアジャイル開発が日本ではあまり行われていなさそう、ということがわかりました。
それはなぜでしょうか？
この点については多くの議論があります。よく言われる話としては以下でしょう、非常によくまとまっている記事だと思います。
外注を多用する日本のソフトウェア開発では、アジャイル開発を導入しにくいのが原因のひとつと言われています。 出典：なぜ日本でアジャイルが普及しないのか、ウォーターフォール型開発の問題点とアジャイル開発との違い
アメリカではソフトウェアに対する投資が自社開発（内製）とパッケージソフト開発で3分の2であり、ITエンジニアの7割以上がユーザー企業に属しているという特徴があります。（IPA:非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書） 出典：なぜ日本でアジャイルが普及しないのか、ウォーターフォール型開発の問題点とアジャイル開発との違い
日本の商習慣としてもシステムを外注することは一般的ですし、SIerなどに所属するITエンジニアも非常に多いですからこれらは納得の理由かと思います。僕自身も、なぜ日本ではアジャイル開発が進まないのですか、と聞かれたら同じ回答をします。
しかし、他の国の方々から見るとそれは違うように見えているようです。スクラム等の開発手法の導入を支援する企業というのは多数存在するのですがそういった企業に属する方々からの意見を抜粋します。(記事ではアジアでアジャイル開発導入が進まない理由、という視点で話がされています)
アジャイルでは，財布の紐を握る人たちに対して，不都合な事実を伝えられることが必要になります。アジャイルテクニックが開発された西洋に比較して，服従や尊敬，“顔を立てる”ことを重視するアジアの文化では，これが決定的に困難なのです。 出典：アジャイルはなぜアジアで普及しないか
文化的に予測可能性に親しんでいる人たちは，将来は予測できると信じようとします。そのため彼らは，人々やリソースに対して，その予測を実現するように求めます。一方でスクラムの利用者たちは，ソフトウェア開発が扱うような複雑で創造的なシステムでは，予測は不可能であることを知っています。その結果は，劣悪なソフトウェア，守れないスケジュール，資金の浪費，開発者のモチベーション低下という，悲惨なものになるのです。 出典：アジャイルはなぜアジアで普及しないか
商習慣の視点だけでなく文化的な視点からもアジャイル開発が日本で普及しにくい理由はありそうだ、ということですね。僕自身もこの記事を読むまではこういったことは考えもしませんでした。なかなか面白い話ですね。
[おまけ]Udemyのスクラム基礎講座
Udemyではスクラムについてのオンラインセミナー【アジャイル開発】スクラム基礎講座が提供されています。学習内容は以下の通りです。スクラムについて学びたい方などへおすすめです。
学習内容
- プロジェクトでどのようにスクラムを適用すればよいかわかる
- スクラムでビジネスに価値をもたらす方法
- スクラムでプロジェクトを効率的に遂行する方法
- スクラムの概念を身に着ける
- スクラムに使えるツールを知る
- スクラムの価値、基本概念、３つの柱をマスターする
- スクラムの歴史を理解する
- スクラムとウォーターフォールの違いを理解する
こちらは約4時間のオンラインセミナーになっています。Udemyは僕もよく使うのですがコンテンツも豊富でおすすめです。実績のある方々から教えてもらえるのはいいですよね。
まとめ
最後はスクラムを取り巻く現状のようなお話をしてみましたがどうでしたでしょうか。
僕自身はスクラムが唯一の素晴らしい開発手法だと考えているわけでもありませんし、それぞれの現場や事情にあった手法を選択するといいと考えています。ただ、要求や状況の変化に柔軟に対応できる開発手法としてアジャイルは実績を積み重ねており、その中でスクラムというフレームワークはその中心的な役割をになっています。そのため、スクラムというフレームワークを理解し、うまく活用する、ということソフトウェアの開発において重要だと僕は考えています。
それでは以上です、スクラムに興味のある方の参考になれば嬉しいです。
