最近、「スクラム開発やってるよ」っていう現場が増えてきたなと感じる。
そして、「スクラムやってるんだけど上手くいかなくて」という声も多く聞く。
なぜなら、大抵の現場のスクラム開発は
「なんちゃってスクラム開発」
にしかなっていないことがほとんどだから。
スクラムの「ス」の字にもなっていない。
それは、スクラムの基本的な部分を理解もしないまま上辺だけを真似してしまっているからだ。
（しかも、理解できていると思ってやっているからタチが悪いんだけども）
それで、スクラムをやっているつもりになって上手くいかず、「スクラム上手くいかない」と思っているところがほとんどだ。
きちんとしたスクラムをがっつりやってきた人間としては、とても心外なので、
ここでは、本当のスクラム開発ってどういうものなの？というのを伝えておく。
スクラムの知識はある前提でお話しするので、「スクラム開発ってなに？」という人は下記サイトなんかを参照してください。
https://tech.recruit-mp.co.jp/scrum/scrum_introduction/
https://geechs-magazine.com/tag/tech/20160212
http://hackerslab.aktsk.jp/management/ryuzee_scrum_training/
http://hackerslab.aktsk.jp/other/team-building-with-curry/
1.スクラム開発の基本理念
スクラム開発というのはアジャイル開発の代表的な手法の一つだが、どんな開発手法でも、目的は「生産性」と「品質」の２つを上げるためだ。
その２つを上げるために必要なものとしてスクラムで大事だと考えられているのが、おおまかに5つある
1.チームワーク
2.コミュニケーション
3.透明性
4.自立
5.属人化排除
アジャイル開発の中でもスクラムは「チームワーク」というものと「コミュニケーション」というものを重視している。
なぜかというと「生産性」と「品質」を向上させるためにはこの「コミュニケーション」が実はとてもとても大切だからだ。
2.スクラム開発のメリット
2.1.短い期間で、最大限の成果をあげる
スクラム開発では、優先順位の高い機能から順に開発を進めていくので短い期間であっても、あげられる成果が非常に高い。
2.2.作業の工数見積もりが正確になる
ウォーターフォール開発では、「プロジェクトの工数見積もりが上手くいかない」ということがデメリットとしてよく挙げられてきたが、スクラム開発では短い期間ごとに開発を区切り、その単位で計画を立てていくため、作業の工数見積もりは比較的正確になる。
2.3.自立的なチーム作りができる
スクラムとういう言葉はラグビーの「スクラム（みんなで肩を組む）」からきているように「チーム」というものを大切にする。
なぜなら、仕事は一人でしているわけではないからだ。
Googleなども提唱しているように生産性の高さとチームワークの良さは比例する。
そして、チームの一人一人が自分で考え行動し責任感を持って仕事をしていく仕組みになっているのがスクラムだ。
ちなみにチームと言っても馴れ合いをする必要はない。
スポーツでも同じく、良いチームというのは一人ひとりがしっかり自立し、結構孤高だったりする。
その中でもいい具合にコミュニケーションが取れるものだ。
2.4.チーム内で発生している問題の検知が早い
スクラム開発では、日々ミーティングを行う。ミーティングが多くて、エンジニアも疲れるくらいに。
ただし、そうすることで、チーム内で問題が発生している場合でもすぐに検知が出来る。
（ちなみにコミュニケーションがきちんと取れるようになれば、ミーティングもあまりいらなくなる。大抵の現場はコミュニケーションがなっていないので、それを培う部分が大きい）
2.5.早めに軌道修正が出来る
スクラム開発では、作っている機能が正しいか定期的に確認の場を設けるので、もし顧客の要望と違うものを作っていても早めに気付ける。
2.6.職場環境がよくなる
エンジニアがどんどん辞めていく。エンジニアに覇気がない。モチベーションが右肩下がり。エンジニアが休みがち。
現場ではあるあるパターンですが、自分の体験談として、それが結構改善されます。
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を使えばいい。
便利さの影には実は失っているものがとても多くある。