はじめに
はじめまして。石元湧也と申します。
私自身20代も終盤に差し掛かり、これまで様々な逆境や困難に直面してきました。この間も友人とレストランへ行った際に店員さんを呼び掛けても無視され続けてしまい恥ずかしい思いをしてしまいました。こういった困難が立ちはだかった際に、ダーウィンが『進化論』で「最も強い者が生き残るのではなく、唯一生き残るのは、変化する者である」とおっしゃっている通り、大事なのは臨機応変に対応できる力だと学んできましたので、なんとか喉が痛いフリをして乗り切ることが出来ました。
ソフトウェア開発でも同様に大事なのは、臨機応変に対応する力かと思うので、不具合や修正に柔軟に対応できるアジャイルでの開発について、私の体験談をお話します。
アジャイル開発とは？
ソフトウェア開発における柔軟性と迅速さを重視した手法のこと
アジャイル開発は、何か単一の開発手法を指すわけではなく、似たような開発手法に共通した価値観と行動原則のことを指しています。それを体現するさまざまな手法があるというわけです。
主な手法にスクラム、エクストリーム・プログラミング（XP）、カンバンなどあります。自分が経験したアジャイル開発はスクラムでした。
ウォータフォール開発との違い
ウォーターフォール開発のプロジェクト推進では、最初にすべての要求を集めます。その後に、それらの要求の工数がどれくらいかかるか、どれくらいのコストが発生するのかを見積り、各フェーズごとにしっかりと工程判定しながら進めて行きます。
一方、アジャイル開発のプロジェクト推進では、最初に期間と工数を決めます。その後に、大事な要求から順番に対応していくので、重要なものほど先に作成でき、成果が目に見えやすいです。
また、ウォーターフォール開発では、開発途中で仕様の変更が発生すると、1つ手前の工程から見直しする必要があり諸々と工数がかかりますが、アジャイル開発だと「了解です！」の一言で対応可能です（※あくまでウォーターフォールかつ契約でスコープをキッチリ目でしている状況との比較をイメージしています）。柔軟ですね。
スクラムとは？
スクラムとは前述の通りアジャイル開発手法の1つです。
スクラムのルールはスクラムガイドで定義されています。
1980年から提唱された方法で今でも定期的に更新されています。
私の新卒の際に、PDCAサイクルを回して仕事の質を向上させていきなさいと学んだように、スクラムのルールもPDCAサイクルを回して常に改善されていっているのかもしれませんね。
アジャイル開発用語
私の経験をお話するにあたり、アジャイル開発独自の用語が色々と出てきますので、
主要な用語について記載しておきます。
- インセプションデッキ
- メンバーが各々の意見を持ち寄って共通認識をつくり出すための対話の場
- プロダクトバックログ
- 開発対象のソフトウェアに対する要求のバックログのこと
- スプリント
- 1週間から4週間サイクルの反復
- このスプリントをぐるぐる回していくのがスクラム
- スプリントバックログ
- スプリント目標の達成に必要なタスクのリストのこと
- ストーリーポイント
- タスクを完了させるために必要な工数の見積もりを示す測定単位のこと
- ベロシティ
- スプリントで完了したストーリーポイントの総計のこと
- デイリースクラム
- 日毎の進捗確認ミーティング
- スプリントレビュー
- ステークホルダーやプロジェクトオーナーを見せたりしフィードバックを貰う会議
- スプリントレトロスペクティブ
- スプリントの最後にその時のスプリントの動きについて反省会（KPT）を行う会議
- プランニングポーカー
- チームで相対見積りを行う際に実施する見積手法
事前準備
本格的にスクラム開発をしていくためにみんなで事前準備していきます。
プロ野球選手のイチローも「準備と言うのは言い訳の材料となり得るものを排除していくこと。 そのために考え得るすべてのことをこなしていく」とおっしゃっているので、イチローを見習い、しっかりと準備を進めて行きます。
1.メンバーの役割分担
私たちの場合、スクラムメンバー数は6人でした。
ちなみにアジャイル開発メンバーは通常5人から9人までが適当とされていますので、活動人数は効果が出やすい人数ですね。
それぞれのスクラムメンバーの役割の認識合わせを行い、役割は以下になりました。
- PO（プロダクトオーナー）：1名
- 役割：ステークホルダーの要望を受け取り、要件の確認を行う人
- SM（スクラムマスター）：1名
- 役割：チームの管理を行う 一緒に開発はしない、各MGのファシリを行う人
- DEV（開発メンバー）：4名 ⇒自分はココ
- 役割：実際に手を動かして開発する人
2.インセプションデッキで認識合わせ
メンバーそれぞれの役割が決まったら、アジャイル開発を実施する目的や意義について、インセプションデッキという手法でメンバー全員の認識合わせていきます。
最初の段階でメンバー内での全体感に認識のズレがあると、その後どんどんそのズレは広がってしまいます。
はじめに時間を使って共通認識を合わせることで進むべき道のりを合わせていくのです。
https://dev.classmethod.jp/articles/inception-deck/
3.アジャイル開発で利用するツールの決定
メンバーの認識が合ったら、利用するツールを決めていきます。
スクラム開発では、Excelやメモ帳で管理だと不便なので管理しやすいツールを選定します。スクラム開発の便利ツールは、色々と世の中に出回っているのでそれを利用していきます。便利な世の中になりました。
私たちが利用したツールは主に2つです。
（1）進捗管理ツール
利用したツール：JIRA
主にプロダクトバックログの管理に利用しておりました。
カンバンボードがあるので、タスクの一覧が把握しやすかったです。
直感的に利用できるので、使いやすさもありました。
https://www.atlassian.com/ja/software/jira
（2）ドキュメント管理ツール
利用したツール：Confluence
デイリースクラムなどの各スクラムイベントで利用しました。
チーム内で決めたルールを記載し、ここで管理しました。
https://www.atlassian.com/ja/software/confluence
私たちがやった事前準備は以上となります！
では、待ちに待ったスクラム開発を進めて行きます。
スプリントのルーティーン
私たちは、2週間で1スプリントとし約4カ月間やり続けました。
上の図の1回転で1スプリントです。
ここからは、とあるスプリントの2週間の動きをお話します。
【1週目】月曜日
午前：スプリントプランニング(2H)実施
スプリントプランニングでは、各メンバーの進捗状況や本スプリントで実施する開発内容を決めます。メンバーそれぞれの本スプリントで作業に割り当てられる工数をみんなで共有します。そして、チームとして実施したいプロダクトバックログからPOが決めた優先度を基に、スプリントバックログを作成し、どのタスクを誰が実施するかみんなで決めます。
どのタスクを実施するのか決まったら、午後からタスクをこなしていきます。
1回目のスプリントでは2週間もあるから余裕をもってタスクをこなしておりましたが、何度かスプリントを回していくにつれて、この段階でどんどん進めて行かないと間に合わないことを学びました。
よく夏休みの宿題と確定申告は、早めに取り掛かるのがよいと言いますが、スクラム開発も同じです。最初から全力疾走していきます。
【1週目】火曜日 ～ 金曜日
午前：デイリースクラム（日次）で実施
デイリースクラムでは各メンバーのタスクの進捗状況や困っていることがあれば共有していきます。
デイリースクラム以外は、自分に割り振られたタスクを実施していきます。タスクは、他の開発メンバー2名のレビューを経て完了としていました。他の開発メンバーからのレビュー依頼が来た時には、最優先に対応することで、タスクの停滞が発生しないように心掛けてました。この火曜日～金曜日の進捗が芳しくないと次週出せるものが無くなるので、引き続き全力疾走してタスクを進めて行きます。
不明点が出てきた時には、すぐに解消できるよう常にチームメンバーと共にGoogle Meetに待機してました。そうすることで、すぐに声掛けできコミュニケーションがとりやすかったです。
【2週目】月曜日
午前：バックログリファインメント（2h）
次のスプリントで実施する内容をチームメンバーで話し合いです。
それぞれのタスクの工数はみんなで見積ります。
見積方法としてはプランニングポーカーという手法で実施します。
https://www.mof-mof.co.jp/blog/column/agile-estimation-planning-poker
ストーリーポイントの基準として、1画面＋1APIの開発タスクを5ポイントと決めてました。
【2週目】火曜日 ～ 水曜日
午前：デイリースクラム（日次）で実施
そろそろスプリントも大詰めです。この時期になると、スプリントプランニングで決めたタスクがすべて完了するのか見えてくるので、期限内に完了するか、どこまでスプリントレビューで見せるかデイリースクラムで話し合います。
【2週目】木曜日
午前：デイリースクラム（日次）で実施
SM(スクラムマスタ)がスプリントレビューで話す開発概要の資料を1~2P用意し、デイリースクラムの中で確認します。
その上で、今日中にどこまでタスクが達成するか話し合い、なんとかしてレビューまでに間に合わせます。「百里を行く者は九十を半ばとす」という昔習った言葉を思い出して、馬車馬のようにタスクを進めます。
【2週目】金曜日
午前：スプリントレビューを実施
ステークホルダーを集め、スプリント中に実施したことを共有します。
成果物の概要をSM(スクラムマスタ)が説明し、詳細は開発メンバーが話します。実際に開発したものをステークホルダーにも共有し、実際に操作してもらったりもします。データ送付の仕組みはどうなっているのかとか、やっぱり画面デザインを変えてほしいなど様々な意見が出てきますので、さらに改修が必要な場合は、プロダクトバックログに積み上げていくことになります。
午後：レトロスペクティグ（2h）を実施
KPT形式でチームメンバー全員参加の反省会です。この場で出てきた反省は、次のスプリントで適宜改善していきます。
また今回のスプリントのベロシティも計測しておきます。毎回15ポイントくらいでした。
このベロシティを以て、『【1週目】月曜日』に戻ります。
スクラム開発の反省点
スクラム開発では、常にアウトプットが出てるので成果を見せやすい反面、常に結果を求められているので、開発・テストが思うように進まないと焦燥感に襲われます。
２週間ごとに納期が迫ってくるイメージです。
毎日、太陽ってこんなに早く沈むんだと、時の流れの早さに感心しました。小説『走れメロス』でメロスは、「少しずつ沈んでいく太陽の、十倍も早く走った」とのことですが、残念ながら自分は、友を人質に取られていなかったので、そこまで早く動けませんでした。
今思うと、ベロシティを下げることへの忌避が強すぎたのかもしれません。オーバーワークでベロシティを下げないようにするのではなく、なぜベロシティが下がっているのかをチーム全員で深堀りして話し合い、改善して行けたらよかったなと思いました。
まとめ
アジャイル開発を通して、学んだ柔軟性や迅速さは、ソフトウェア開発のみにとどまらず、プロジェクト管理や業務改善などの仕事においても活かすことが出来るかと思います。
これを読んだすべての方へ今後の携わる仕事での何かの参考になれば幸いです。