須田のスクラム元年の所感

この投稿は Jsys Advent Calendar 2019 の 21 日目の記事です。

前の投稿は soyoil 氏のゲームボーイサウンド入門でした。記事内にある再生ボタンを押した瞬間 PC がぶっ壊れたのかと焦りましたが仕様でした。

はじめに

こんにちは。Google Home に「仕事に合う曲を流して」とお願いしたところ「Google Play Music で仕事 OFF モードの J-POP を流します」と返され、すこぶるポップな曲が流れる自室でキーボードを叩いている須田です。皆さまいかがお過ごしでしょうか。

主専攻実験でenPiTを履修したのを皮切りに、2019 年は僕にとってスクラム開発元年でした。今回は、スクラムに初めて触れた人間がスクラムで成功したり失敗したりした話を書きたいと思います。

スクラムとは

スクラムとは、ソフトウェアの開発技法の一つで、近年盛んに取り入れられている技法です。原典はこちらです。公式認定の和訳 PDFも配布されています。

スクラムそのものを解説しだすとそれだけで本が 1 冊書けてしまうので本投稿では詳細な説明は省きますが、猛烈に雑に説明すると以下のような感じです。

  • チーム全体で足並み揃えてガッとやる
  • 製品に必要な要素を書き出して順番に並べニヤニヤする
  • 固定された期間(スプリント)を切ってモリモリと開発する
  • スクラムガイドに設定されたイベントをペッとやる

スクラムは開発技法のフレームワーク的な立ち位置です。アプリケーション開発にフレームワークを使うときは、フレームワークに従う範囲内で自分で工夫して自分に合うようにカスタマイズしますが、スクラムもそれと同様、スクラムガイドで定義された範囲の中で自分たちの開発スタイルに合うよう様々な工夫をすることができます。

出会い

唐突ですが、僕は不必要な横文字が嫌いです。「コンセンサスを取る」とか「ショートノーティスで申し訳ないです」とかそういう文脈じゃないのに言ってくる人間とは友だちになれる気がしません。「意見を一致させる」「急なお知らせで申し訳ないです」と言えばいいじゃないか。何をカッコいい人ぶっているんだ。

そんなことを 365 日 24 時間思っている僕なので、「アジャイル」とか「スクラム」とかいう言葉に対しても「アジャイル(笑)」「スクラム(笑)」と斜に構えた態度を取っていました。

さて、ときは 2019 年 4 月。筑波大学情報科学類では、3 年生の 4 月に主専攻実験を決める必要があります。僕も例外ではなく、テーマ一覧とにらめっこしつつ何を履修するべきか考えました。するとテーマ一覧の中に燦然と輝くこのテーマが。

PBL 形式によるネットワークサービス開発(enPiT)

春 AB と春 C の期間前半は各自が自習ベースでシステム開発のための基礎技術を学びます。 その後、春 C の1週間に集中演習を実施し、アジャイルなチーム開発について学びます。

すごくムズムズする。「PBL」ってなんだよ。こんなゆるふわそうなテーマに実はあるのか?「アジャイル(笑)」君もいるじゃないか。よし、ここは一つ履修してバカにしてやろう。

こうして、僕はスクラム開発を学ぶ主専攻実験「enPiT」を履修したのでした。これが僕のスクラムとの出会いです。

enPiT 春〜夏 チーム開発

主専攻実験 enPiT ではチームを組んで実際に製品を開発します。初めに履修学生各々が持ち寄った「解決したい課題」を元に、気になる課題に集ってチームを構成します。選んだ課題を元に、どうすれば解決できるのかを考え、製品の設計・開発を行っていきます。

スクラムでは、「プロダクトバックログ」というものが非常に重要なものとして扱われます。「プロダクトバックログ」とは製品に必要な要素を洗い出し、製品にとって重要度が高い順番に羅列したものです。製品を開発する際は、羅列した要素の上から順番に実装を進めていきます。こうすることで、開発中の製品に常に最大の価値を与え続けることができます。

さて、僕が所属していたチームではある種の Web アプリケーションを開発することになりました。

ある程度の規模の Web アプリケーションを作るとなるとユーザの認証をしなければいけないことがほとんどです。僕が普段個人で開発するときは「どうせ後で必要になるなら」「割と基盤的な機能だし」と、ユーザのログイン周りをかなり初期から実装することが多いです。

ところがこの主専攻実験 enPiT はスクラム開発の実験。「ユーザのログインは必要だよね〜」と当然のように話していたところ、講師の一人に言われました。

「それは君たちの製品の最も味が濃い部分なのかい?」

と。たしかに、ユーザがログインできるからと言って課題は 1mm も解決されません。必要か不必要かより、課題の解決のためにどれだけ重要かを元に開発順序を決めることがスクラム開発では重要なのです。

freee 株式会社 インターン

夏休みは freee 株式会社にインターンに参加させてもらいました。2 週間のプログラムで、実際の開発現場に入って製品の開発に携わるという内容のものです。

これはおそらく偶然なのですが、僕が配属されたチームはかなりスクラムに忠実な開発スタイルを取っていました。僕のチームでは 2 週間を 1 スプリントとしており、運がよいことに僕が配属された 2 週間はスプリントにピッタリ合致していました。

インターン初日、簡単な入社説明会を終えるとチームメンバーは会議室でスプリント計画ミーティングをしていました。後半しか見られなかったのが残念ですが、ザックリとしたタスクの洗い出しをやっていたように思います。

enPiT での開発では、スプリント内での開発はほぼスケジュールどおりに進みました。まだ製品は開発途中なので運用中の製品からのバグはありませんし、社会と隔絶された大学内での実験なので波風が立つことはほぼ皆無です。しかし実社会での製品開発は面白いほどスケジュールどおりに進みません。表面化こそしないもののバグは大小含めて山のように見つかり、外部に頼んだ仕事は期日どおりに返ってきません。

スクラムではこういった事態に柔軟に対応するため、デイリースクラムというイベントが設定されています。デイリースクラムは毎日決められた時間・場所で 15 分間開くミーティングで、進捗報告や次のデイリースクラムまでにやることの報告、何か開発に関わる問題があるかの報告などの報告を行います。デイリースクラムのタイムリミットは 15 分ですが、デイリースクラム内で何か問題が報告された場合、デイリースクラム直後に問題を解消するための話し合いがもたれることもあります。

僕が所属していたチームではデイリースクラムが極めて効果的に機能しており、非常に感動しました。僕のチームは、何も知らない僕がインターンとして参加していることで非常にイレギュラーな状態になっていましたが、デイリースクラムで現況を報告することでスプリント全体としてスムーズに開発が流れていたように感じました。

スプリントレビューもスクラムガイドに忠実に行われていて感動しました。スプリントレビューとは、スプリントの最後に行われるスプリントの反省会のことで、そのスプリントでどんな開発が進み、製品に対して新たにどんな価値を付与できたのかを議論するミーティングです。このミーティングにはステークホルダーたるいわゆる「偉い人」や営業周りの人、他チームの人も参加して活発な議論が交わされていました。

Feedal

僕が開発に参加しているエンジニア向けの情報収集サービス「Feedal」でも、一時期スクラム開発を導入していたことがありました。

これは結論から言うとスクラム開発が失敗しました。

Feedal は学生のみのチームです。しかもメンバー全員がそれぞれかなり多忙で、Feedal に対して割ける時間はメンバーによってもタイミングによってもまちまちでした。スクラム開発では、一定の期間を区切りその中でタスク管理を行います。スプリント管理の前提は開発チームメンバーの参加度合いが予測可能なことです。メンバーがどれだけ Feedal に時間を使えるかが不透明な状態では、スプリントの計画を立てることはできません。Feedal では一応スプリント計画ミーティングの時間を持っていましたが、どう頑張っても計画どおりに開発することはできませんでした。

ただ、メンバーの予定をうまく調整するとか目標を引き下げるとか、スクラム開発を回す方法はいくつかあったはずです。それでも上手くいかなかった最大の理由は、スクラム開発への意識の低さがあると思います。これは偏にスクラムマスター(スクラムを上手く回すよう調整する役割の人)である僕が悪いと思っています。

多くの開発技法と異なり、スクラムはエネルギーを持ってスクラムを動かす必要があります。スプリント計画ミーティングやスプリントレビュー、レトロスペクティブ(チームとしてのスプリント反省会)などは時間をかけた重たいイベントです。スクラムを導入する以上はこれらのイベントを着実にこなしていく必要があり、これらをサボるとその瞬間スクラムは崩壊します。

企業などが責任を持ってスクラムを運用するならばまだ良いと思いますが、ごく少人数のゆるいチーム開発でスクラムを導入するのは少々覚悟が必要なのかなと感じました。

また、そもそも Feedal のような 4 人だけのチームでスクラム開発を用いるメリットはあまり大きくないのかもしれないなとも感じました。

Jsys に活かせるのか

少なくとも僕がいた代の Jsys にスクラムを導入するのは現実的に無理でしょう。メンバーの参加度合いはバラバラ、実行委員会の特性からしても仕様変更が多すぎてお話になりません。Jsys のメンバー全員が開発内容に対してコンスタントに積極的であればまだ可能性はありますが、そういうわけでもありません。メンバーもそれぞれ忙しいですし、スクラムイベントをこなせるようには思えません。

ただ、スクラム開発からいくつか活かせる部分はあるように思います。

例えばプロダクトバックログのようなものは定義しても良いでしょう。プロダクトバックログはタスクの羅列ではなく、製品に必要な要素の羅列です。羅列する粒度をタスクほど細かくしてしまうと管理が非常に面倒くさくなりいずれ破綻しますが、プロダクトバックログのレベルの粒度であればまだ管理はしやすいと思います。「あと何を作れば完成なのか」がメンバー間で共有できるのはモチベーション維持にも向いていると思います。

他にも、スプリントレビューは活かせる部分かもしれません。学園祭実行委員会には「総会」と呼ばれる委員会の会員全員が集う場がありますが、この場で「前回の総会から今までにどんな機能が追加されたのか」「次の総会までに何をやるつもりなのか」あたりは報告すると楽しいかもしれません。そのためには常に会員全員が製品を見られるようにする必要がありますが、そうすること自体にも意味があると思います。

最後に

4 月から今まで約 8 ヶ月の間スクラムに関してはそこそこ真面目に考えてきたつもりですが、まだまだ分からないこともあり、自分の中で何がベストプラクティスなのかはさっぱり分かっていません。

今後、スクラム開発の経験値をさらに積んだり他の開発技法の開発チームに携わったりしてスクラムに対する見方が変わったり進化したりすることは大いに考えられます。

来年のどこかの Advent Calendar でも開発技法に対する考えをポエムにできれば良いなと思っております。

ところで

久々にこんなにクソ長いつまらない文章を書いてしまい自分でもビックリしています。俺ってこんなにつまらない文章書けたんだ。まだうんこの話のほうが面白いぞこれ。マジで。