いまさら聞けない“スクラム開発”ってどんなもの？
アジャイル開発の一つ、スクラム開発について説明をしていきますが、その前に、簡単にアジャイル開発について説明します。
アジャイル開発手法は、全体をいくつかの機能に分け、各機能ごとに設計→開発→テスト→確認を繰り返します。まずプロトタイプを作ったり、お客様に細かく段階的に確認してもらい、後で大きな仕様変更が発生しないようにすることが目的の一つでもありますが、大きな手戻りがなくなる分、一々お客様に見せながら進むことで、大量の小さな要望や仕様変更が際限なく発生していく可能性があり、開発費を考えながら、うまくお客様と折り合いながら進めていくことが重要になります。
アジャイル開発は、「細かく確認することで手戻りが少なくなる」と簡単に書いてある書籍やサイトが多いですが、細かく確認するがゆえに、思いもよらない方向に話しが進みがちなため、開発工数が予想外に膨らむことが多々あります。お客様だからと言って何でもかんでも聞き入れない、よく上司と相談の上、進める必要があるでしょう。
私は20件以上のアジャイルプロジェクトを見てきましたが、そのうちちゃんと成功していたプロジェクトはたったの3件だけです（ウォーターフォールは100件以上見ていますが、成功率はそんなに低くはありません）。
プロトタイプ等を作りながら進めるのはいいことだが、仕様を確定する要件定義書は、プロジェクトの範囲を担保する非常に重要なものなので、これがおろそかにされるということは、テストの品質を保つこともできなくなり、じゃあ、品質を担保するものはなんなのかという重要な問題も、なんとなく決めないまま進んでいくことで最終的に悲惨な結果を招くことになっていくのではないでしょうか？
では最近、さまざまな企業で採用されることの増えている“スクラム開発”の基礎知識について取り上げてみたいと思います！
スクラム開発ってどんなもの？
ソフトアウェアの開発には、従来の主流であるウォーターフォール開発と、2000年あたりから採用する企業の増加しているアジャイルソフトウェア開発の、主に2つの手法があります。
アジャイルソフトウェア開発では、一か所に集まった少人数の開発チームが、目的の達成のために協力しあいながら作業を進めます。また、ウォーターフォール開発のように、一度決定した計画を絶対のものとはしません。各メンバーや関係者からのフィードバックを定期的に得ながら、柔軟に計画を調整し、さらに一度にまとめてすべての機能を作るのではなく、1つの期間ごとにいくつかの機能を追加開発していく手法です。
アジャイル開発には、ソフトウェアプロセスから無駄を取り除くことを目的とした「リーン開発」や、ドメインのモデルを作成を基礎とする機能駆動型開発（FDD）など複数の手法がありますが、スクラム開発はアジャイル開発の代表的な手法の一つで、中でも“チームのコミュニケーションを重視した手法”であることが特徴で、次のような要素を持っています。
■スクラム開発の要素
・プロダクトへの要望を優先順位ごとに並べかえ、その順に機能を作る。
・固定の短い期間（1～4週間程度）の単位で開発を区切り、その中で計画を立てる。
・プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認しあう。
・作っている機能が正しいかどうか、定期的に確認の場を設ける。
※『スクラム（Scrum）開発』：
ラグビーで両陣が、8名ずつ肩を組んで一つの集団を作り、ぶつかり合う際のフォーメーション「スクラム」が語源。その姿から集団が力を合わせることを”スクラムを組む”と表現することもある。
スクラム開発のいいところって何？
それでは、スクラム開発はどのような点が優れているのでしょうか？
■短い期間で、最大限の成果をあげる
スクラム開発では、優先順位の高い機能から順に開発を進めていきます。そのため短い期間であっても、あげられる成果が非常に高いのです。
■作業の工数見積もりが正確になる
ウォーターフォール開発では、「プロジェクトの工数見積もりが上手くいかない」ということがデメリットとしてよく挙げられてきました。
それもそのはずで、ウォーターフォール開発ではプロジェクトの最序盤の段階で数か月・数年も先のことを見積もりするため、そもそも難易度が極端に高いのです。スクラム開発では短い期間ごとに開発を区切り、その単位で計画を立てていくため、作業の工数見積もりは比較的正確になります。人は、数週間先くらいのことであれば予想しやすいからです。
■自立的なチーム作りができる
スクラム開発では短く区切った開発期間ごとの工数見積もりを、各開発メンバーが自分で立て、期限を切ります。それに対しチームからの了承を得て進行するため、より一層各自に責任が発生するのです。セルフマネジメントはもちろん、自分のタスク以外も、チームの成果として計画を達成するにはどうしたらいいかを全員で考える必要があるので、それぞれの視野が広がり、自立的なチーム作りが促進できます。
■チーム内で発生している問題の検知が早い
スクラム開発では、日々ミーティングを行います。その中で、「困っていること」や「分からないこと」を素直に話すことが推奨されているのです。そのため、チーム内で問題が発生している場合でもすぐに検知することが出来ます。
■早めに軌道修正が出来る
ウォーターフォール開発では、プロジェクトの最終盤にならなければ、顧客は動いているプロダクトを見ることが出来ません。そのため、納品した後に「思っていたものと違う！」とトラブルになるケースがよく発生していました。スクラム開発では、作っている機能が正しいか定期的に確認の場を設けるため、もし顧客の要望と違うものを作っていても早めに気付けるのです。
続きは以下よりお読みください。
geechs
3.スクラム開発のデメリット
どんなものでも魔法の神器はない。メリットもあれば、もちろんデメリットもある。
3.1.差し込みに弱い
スクラムは２週間などの開発スパン（スプリントという）を決めて、そのスプリント中にどれだけの量をこなすかをまず決め、細かいタスクをみんなで出していき、各タスクにどれだけ時間がかかりそうか見積もりをし、最終的にスプリント内でやりきれそうか判断し、開発をしていく。
（小さいウォーターフォールに近い。）
そうすることで、稼働が高かったり低かったり上下することなくエンジニアも安心して仕事が出来、精神や体調を崩すことも少なくなりる。
（いきなり全速力で走ると怪我しやすいのと一緒）
さらには、スプリントという形で毎回区切りをつけることで、エンジニア側も「開発のリズム」をつけることができ、達成感も感じることが出来、目の前のタスクに集中することができる。
（仕事をする上で達成感というのはかなり大事なポイント）
また、スクラムでは、ベロシティというものを測る。
ビジネス要件に対して、どれだけの開発規模になるかざっくりと「ポイント」というものをつけ、スプリントが終わった段階でどれだけのポイントをこなせたか測るものだ。
なので、突然の差し込みタスクなどが頻発するとベロシティが乱高下してきちんと測れなくなってしまうし、リズムが崩れ、集中力も途切れがちになり生産性の低下を招く。
だから、差し込みはPO（プロダクトオーナー）やSM（スクラムマスター）が率先して受け付けない（次スプリントに回すなど）ように努める必要がある。
3.2.チームメンバーがころころ変わると辛い
スクラムではベロシティを測り、自分たちがどれだけこなせたかを可視化し、エンジニアに達成感を与える。達成感がまたモチベーションに繋がり、自立性を高め、生産性にも繋がっていく。
しかし、チームメンバーがよく抜けたり入ったりすると教育が必要だったりで工数が取られたりとベロシティが乱高下するし、リズムも崩れ、わけのわからない状態に陥る。
3.3.チームのスキルレベルがバラバラすぎると辛い
スクラム開発では、ビジネス要件をもとにみんなで細かいタスクに落とし込んでいく。
タスクには、何時間でこなせるか工数見積もりをつけるが、これがスキルレベルに差がありすぎると辛い。
なぜなら、タスクは誰でも取れるのが理想だからだ。
スクラムでは生産性を上げるためにも「自立や向上」を目指している。
そのためには、属人化を出来るだけ排除する必要がある。
属人化を排除するためには技術的な部分でも「透明性」が不可欠だ。
（１つの要件に１人が対応するパターンだと、その機能がその人しか分からないということになるし、その人がやった方が早く終るので結局属人化していく）
それなのに１時間で終わる人もいれば８時間かかる人もいるとなると辛くなる。
そうなるとフラットにしていくまでにかなり時間がかかる。
3.4.最初のうちは既存の開発スタイルより効率が落ちる事が多い
ミーティングがやたら多い。これは自立性を高め、コミュニケーション力を鍛えて活発にし、チームの一体感を持たせ、お互いの理解があっているか確かめて認識齟齬を防ぎ、サービスの機能理解を深めるというのが目的。
なので、その分実際の開発に使える時間は少なくなる。
3.5.期限が決まっているものに弱い
スクラムでは、ビジネス要件に対して、どれだけの開発規模になるかざっくりと「ポイント」というものをつける。
そして、それをもとに「ベロシティ」というものを測る。
ベロシティは２週間などの開発スパン（スプリントという）を決めて、そのスプリント中にどれだけのポイントのものをこなせたか測ったもの。
ベロシティが何ポイントかを見る事で、生産性が上がったかどうかの指標になったり、次のスプリントでどれだけの量をこなせそうかという指標にもなる。
さらに正確にベロシティを測るため＆リズムを崩さないためにも残業はオススメしていない。
またスクラムというのは、「終わらなかったら仕方なし」というスタイルだ。
だから、期限が決まっていて「絶対にこの期限まで終わらせろ！」という事が多い現場には向かない。
3.6.コミュ障やただタスクをこなしたいだけのエンジニアには辛い
どんどんコミュニケーションを取っていくので、コミュ障には辛いだろう。
ただ、私も最初は人前で何話していいか分からず上がってしまうようなタイプだったので、慣れでしかない。
しかし、ウォーターフォールのエンジニアに多いように、ただタスクをこなしたいだけのエンジニアには無理かもしれない。
そもそもの向上心がない人には向かない。
4.なんちゃってスクラムの例
4.1.コミュニケーションはミーティングなど必要な時だけ取る
マネジメントとエンジニア間やエンジニア同士にも言えるが、そもそも、コミュニケーションがなんなのかを分かっていない。
「話す」「伝える」「聞く」という事がコミュニケーションではない。
（ちなみにコミュニケーションの専門家である営業の世界では、「聞く」ではなく、「聴く」という傾聴が大事だとされている）
これは、交渉事でも同じだが、コミュニケーションというのは「必要な事を伝える前」から始まっている。
日々どうでもいい事を話して関係を深め、いざという時の話を伝えやすくするために風通しをよくしたり、場の雰囲気をなごませるために笑いを取ったり、そういうのも含めてやっとコミュニケーションが出来ていると言える。
前にスクラムやっているという現場のマネージャーがいたが、無表情で淡々と話すだけの人だった。
いや、絶対スクラム出来てないよね。そもそもが分かってないよね。と思う。
4.2.スクラム初心者なのに勝手にカスタマイズする
スクラム開発には「こうしてね」というフレームワークがある。
実は、これはとてもよく考えられているものだ。
だから、ひとつ崩せば他も崩れていく。
それなのに「こういうためのものね」と分かった気で勝手に独自でやってしまったりする。
ちなみに空手の型で上段受けというものがある。
これって、シンプルだが実はとても考えられている受け方だったりする。
腕の角度や捻り、上げる軌道といった細かい部分がかなり大事だったりする。
でも、初心者のうちはそんなこと分からない。経験しないと気づかないことも多々ある。
だから初心者のうちは言われた事をその通りやるのが実は一番だ。
「守破離」というものがあるようにまずは形を守り、分かってきたら自分流に崩し、身についたらそもそも必要なんてない。
それなのに理解した気になりいきなり崩す。
そして、上手くいかないと愚痴をこぼす。
そんなもん上手くいかなくて当たり前だ。
4.3.タスク管理をトレロやJIRAでやっている
なぜだか、エンジニアの多くは便利だからとPCの中で済ませようという方向に進むようだ。
しかし、そういう人はそもそもが分かっていない。
生産性を高めるにはコミュニケーションが大事だと言っている。
透明性が大事だと言っている。
PCの中で済ませてしまうなんて、コミュニケーションとは言えない。
私がオススメするのは付箋を貼っていく「リアルなタスクボード」だ。
コミュニケーションを活発にしたいなら絶対にこれしかない。
なぜかというとタスクを取る時に「必ずボードの前まで動く」必要があるからだ。
実は、生理学的にも体を動かすことで口を動かしやすくなる。喋りやすくなるのだ。
そして、みんなが動くことで場の空気が流れる。
場の空気が流れるとコミュニケーションが生まれやすくなるのは心理学的にも実証済みなことだ。
これは、トレロやJIRAでは絶対に生まれない。
さらにタスクは１時間２時間単位で切っていくのが良いため、トレロやJIRAでは絶対に「全体像」が見えない。
何が終わっていて、何が残っているのか、パッと見て分かるのは「リアルなタスクボード」でしかありえない。
もちろん、コミュニケーションが活発に取れるようになり、全体像を見れるようになったら、トレロやJIRAを使えばいい。
便利さの影には実は失っているものがとても多くある。
コメントはまだありません