近年、企業のデジタルにおける競争が激化しており、アジャイル・スクラム開発を採用する企業が増えています。しかし、アジャイル・スクラム開発の理解が不十分だったこと等が原因で、逆にエンジニアの生産性が落ちるなどの課題を抱えてしまっているケースも多発しています。そんなスクラム開発を導入・実践・成功している女性エンジニアに、メリットだけでなくデメリットなども含めリアルな部分についてお話伺いました。
U.T氏プロフィール：
東京女子大学を卒業後、IT業界に興味がありエンジニアとしてSES企業に就職。その後、株式会社情報戦略テクノロジーに転職。Androidの開発をメインに担当しながら2つのプロジェクトに参画し、日々スクラム開発の中でお客様のプロダクト開発を推進している。
臨機応変で柔軟性のあるアジャイル開発はマーケットに随時対応できる開発手法
アジャイル開発は機能の小単位で改善を繰り返す手法
アジャイル開発とは、システム構築やソフトウェア開発をするときのプロジェクト開発手法の一つで開発期間がスピーディーなのが特徴です。機能単位の小さなサイクルで、計画から設計・開発・テストまでの工程を繰り返すことにより開発をすすめます。
アジャイル開発は、従来の開発方法に比べて、小単位で創り小単位で改善を繰り返していく方法です。そのため臨機応変で柔軟な対応が可能となり、動くものを創るスピードが早いことが特徴です。
一方で最終的な完成形を見通せないため、予算も柔軟性を求められます。
工程ごとに綿密に管理して進めるウォーターフォール開発
ウォーターフォール開発とは、「要件の定義（目的）」「設計（外部、内部、プログラム）」「実装（プログラミング）」「テスト」「運用」という各工程を分割して開発を進めていきます。それぞれの工程を工程ごとに決められた技術者が担当します。また各工程ごとに抜け漏れがないかどうかを綿密に管理しながら進めていきます。
そのためアジャイル開発のように予算がブレることは基本的にありません。「前の工程には戻らないこと」を前提として開発を行うため、もし後工程になって仕様変更や修正が必要になった場合、大幅に開発が遅れることもあります。
アジャイル開発手法のスクラムはチームの一体感のラグビー用語に由来
スクラムとは
アジャイルの開発手法の一つで工程の枠組みであり工程や技法ではありません。チーム一体となってプロジェクトを遂行して行くことに重点を置くことから、ラグビーのスクラムが語源になっています。
スクラム開発は、開発期間の単位である「スプリント」を基準に行います。スプリントは、開発を少しずつ区切って進めるため、期間を短く設定することが多く、約1週間~4週間を基準にしています。
その期間内で、スプリントプランニング（スプリントで何を達成するかを計画する）、デイリースクラム（開発メンバー同士で毎日短時間、スプリントゴールを達成するためにうまく進んでいるかを確認し、再計画する）、実装、レビューを行います。
ISTのスクラムを使用している現場のエンジニアの声による事例紹介
-スクラムを採用している現場はどういった現場ですか？
私は1つの企業様の中で２つのプロダクトを担当しています。プロダクト事にチームが分かれており、15名のチームと10名のチームでそれぞれスクラムを採用しています。チームはプロダクトオーナーやスクラムマスター、エンジニア、デザイナーで構成されています。
私は15名のチームではAndroid開発のリードエンジニアとして、また10名チームの方では機能横断的な役割をしています。10名チームではAndoroidだけではなくiOSのアプリだったりWebの開発だったり、バックエンドの開発をしたりとすべてに手を付ける形で動いています。臨機応変に縦横無尽に動き回っているイメージです。
-スクラムでの開発のメリットとデメリットを教えて下さい
スクラムは都度設計して実装の繰り返し行うので、後の実装で前に実装した部分にも修正変更が起きる、手戻りが発生する部分はデメリットかなと思いますね。
しかしそれ以上のメリットを感じていて、短いスプリントの中で開発を進めていくと実はスピードは従来の開発よりも上がります。
今のように時代の変化の速さによるサービスの変更や、ユーザーの要求への臨機応変に反応しなければ勝てない時代にはとても向いていると思います。
また、週次や隔週で開催しているスプリントプランニング（スプリントで何を達成するかを計画する）で要件を決め、設計を考えるのですが、その設計時にプロダクトオーナーが実現したい事に対して開発側からもこうしたほうがいいんじゃないかと提案できます。
逆にウォーターフォールだと要件が決まりきった後に各工程を順番に進めます。そのため設計工程以降ではプロダクトオーナーと要件について話し合うことは滅多にありません。
スクラムでは単純に上で決めて降りてきたものを作るというよりもプロダクトオーナーも含めて一緒に創り上げていくことで、エンジニアもプロダクトにも愛着をもって取り組めるのでより良いものが出来ると思います。そこも大きなメリットだと思います。
実際にBtoB向けサービスのアプリ開発に携わった時に、要件決めからWebフロントやバックエンドまで関わることが出来てサービス丸ごとに関わることが出来た開発は自分も一緒に作ったんだという気持ちが強いので責任感も強くなりますし、愛着も沸きました。個人的には機能横断型の開発をしているのでそれぞれが自分の能力の成長に繋がるといった点もいいなと感じています。
-スクラムに向いている開発はどのようなものだと思いますか？
良くも悪くも仕様が固まっていないものが向いていると思います。例えば、日常的に競争が激しく臨機応変さが常に求められるスマホアプリの開発などです。
その対応能力は開発側としてはチーム全体でスキルアップを図れるので、技術的に成長したいという意欲があるチームには向いていると思います。
お客様側は、要件を決めるためにはそれなりに技術的な前提知識が必要になります。要件の項目を決めることはすぐに出来ることですが、そこに付随した異常系（エラー）だったり機能的なことは、要件を決める人からは見えづらい部分で後々には障害になりやすいですね。
そこは慣れている方であれば先に課題を洗い出せると思いますが、慣れていない方であればエンジニアと一緒に会話を交わしながら逐一、要件を決めていけるスクラムがあっていると思います。
-実際の現場でどのように運用していますか？
現在の現場では、プロジェクト管理ツールはMicrosoftのAzureDevOpsというサービスを使用しています。
AzureDevOpsは、タスクを管理できるボード機能やGitを管理する機能もあります。CICD機能、テストケースを管理するテストプラン機能もありすごく便利です。
通常だと色々なツールを導入するのですが、そうすると各タスクの紐づいて発生する作業などの管理が手間になります。しかし、AzureDevOpsを使えばそういった「今回の作業はこのタスクに紐づいて結果このCICDが動いているよね」といったものが見えやすく、開発側も全員が同じ認識を持てるためスムーズに進めることができます。
-スクラムを運用したプロジェクトで実現好例はありますか？
要件が決まっていないような見切り発車の状態でも開発を行えるのがスクラムのいいところで、PoC（実証実験）でとりあえず始めてみようというような思い付きベースの開発でも形にできます。
実際に私が担当したアプリでも、初めはPoC（実証実験）でFlutterを使用して作成したアプリがその後製品として収益を上げ続けられるということが分かり、そこから本格的にAndroidとiOSのネイティブアプリに作り直して管理画面も作ることもしています。
内製チームとして初めてお客様先に直接利益がでるもの、収益をあげられる開発プロジェクトだったのでとても嬉しかったです。これもスクラムだからできたことだと思います。
-アジャイル開発成功の秘訣はどういった部分だと思いますか？
アジャイル開発では短期間で設計から実装を繰り返し行うので、とにかくチーム間でのコミュニケーション、チームワークが非常に大事になってきます。ウォーターフォールだと各工程で担当者が決まっているので前後の工程のことを考えないのですが、アジャイル開発だと全部を一気通貫で考え、開発を行います。
全員で同じものを作るため、全員が同じものを同じだけ理解していないと開発を進めることが難しくなります。スクラムの取り組みの中で大事な視点として「振り返り」があります。設計から実装してリリースして振り返りをしてと、この流れを何度も繰り返し行います。
その振り返りで今回良かった点、課題になる点などを全員で話し合います。それを繰り返すことで開発内容がどんどんブラッシュアップされていきます。この振り返りが単に形骸化してしまうと、どうしてもチームとして成長できないですし、良いものも作れないですよね。そのため振り返りをしっかり行えるお互いのコミュニケーションがとても大事だと思います。
毎週の短期的な振り返りだけだとどうしてもプロダクトのことに集中してしまうのですが、中長期的な振り返りをチームで行うことで自分たちの成長やチームとしてのあるべき姿というものも見えてきますし、チームとしての成長を促すためにも中長期的な振り返りも必要な事だと思います。
また、特にコミュニケーションの取り方は意識していて、会議の時はなるべくカメラをオンにして顔出しで参加しています。その理由は、今のようなリモート環境だからこそ相手がどう思っているか、今言った発言に対してどういう感情を抱いているのかわからないと、チームとして動けないからです。
また、初めから積極的にコミュニケーションが取れない方もいると思うので、そういう時はこちらから相手にどう思いますか？と聞いてみたりとコミュニケーションを促したりしています。
-コロナ環境により生まれた課題はありますか？
リモートワーク環境になってから2つのチームのうちの片方はDiscordやMicrosoftTeamsを使ったりしてコミュニケーション取っているので問題ないのですが、もう一方のチームの状況を把握しづらくなったなと感じています。
これまでは同じ空間で働いていたのでわざわざチャットを追いかけなくても現状を把握できていましたが、今は主にチャットなのでどうしても自分のタスクもこなしながら常に情報を拾い続けることは難しいなと思います。
同じ内製チーム同士で分断が起きてしまうという状況を解決するために2週間に1回、勉強会や共有会をチーム合同で行っていて、お互いのチームで良かった点や課題をシェアしてもらっています。技術力だけでなくチーム力での成果を上げるスクラムだからこそ、互いのコミュニケーションはとても重要だと日々感じています。
執筆者
リビルダーズ編集部
