今さら聞けない？アジャイル開発の基本的で深〜いお話

こんにちは、SOMPO Digital Labです。

私たちSOMPO Digital Labは、2016年に発足した組織で、日本国内のみならず海外グループ会社を含め、グループ全体のデジタルトランスフォーメーションの実現に向け、既存事業の変革と新規事業の創出に取り組んでいます。

中でも「Sprintチーム」と呼ばれるデザイナーとエンジニアで組織された内製開発部隊では、SOMPOグループの種々の事業に関わる様々なプロダクト開発にチャレンジしています。

そんな「Sprintチーム」ですが、全てのプロジェクトにおいてアジャイル開発を取り入れているのはもちろん、グループ全体へ向けたアジャイル開発研修に講師として登壇したりと、アジャイル開発の良さを積極的に社内外へ広めています。エンジニアであれば誰しも耳にしたことがあるアジャイル開発ですが、「体系立てて学ばないまま、何となく業務で使ってる」「アジャイル開発について、今さら聞けないことがある」と思っている方はいませんか？

今回は、疑問や不安を感じながらアジャイル開発をしている人、そして実はまだアジャイル開発をやったことがない人にピッタリの内容になっています。Sprintチームでエンジニアを統括する阪さんが丁寧にお答えしているので、どうぞ最後までご覧ください！

◆お話を伺ったメンバー◆

阪　倫嘉
SOMPO Digital Lab　Sprintチーム　チーフエンジニア「モバイル！SOMPO」事業においてはネイティブアプリの開発だけでなく、グループ会社や協力会社との調整も含めた、エンジニアリング全体の統括を行う。趣味はドラクエウォークとソロ映画館。

監修：木村　一統
SOMPO Digital Lab　Sprintチーム　リードエンジニア
LIghtPASS / WiTH Health事業においては、リリース前の初期段階から携わるエンジニア。その後も両プロダクトの開発・運用に邁進する。
趣味はトレッキングと3Dモデリング。

今さら聞けない人のために、アジャイル開発とはどんな開発手法なのか、あらためて教えてください。

阪　：
まずアジャイル開発の対比となる開発手法として、ウォーターフォール開発があるのは皆さんご存じですよね。昔からある伝統的なシステム開発手法なのですが、これは設計や実装、テストなど、各工程ごとに区切って順番に進める手法です。

一方、アジャイル開発ではそれらの工程を区切ることなく、何度も行ったり来たりしながら進めていきます。ウォーターフォール開発では、完成した後に求められるものと違うものが出来上がったことが判明したり、後ろの方の工程で問題が発覚する場合があり、そうなるとプロダクトやプロジェクト全体に対するリスクが大きくなってしまい危険です。

そのような事態を避けるためになるべくリスクヘッジしようという考えから、アジャイル開発が登場したと言われています。「小さく作り、細かくリリースすることでリスクを最小化していきましょう」というのがアジャイル開発のベースの考え方ですね。

ここからはアジャイル開発とウォーターフォール開発の違いについて深掘りしていきます。まず、プロセスはどんな風に異なってくるのでしょうか？

阪　:
ビジネス部門の人たちとの関わりというところが一番大きな違いじゃないかなと思っています。ウォーターフォール開発では、最初の要件定義や設計の段階までは関与してくれるのですが、その後は受け入れテストまでビジネス部門の人は登場しない場合が多いです。

なのでエンジニアサイドでは、「ビジネス部門で決定した内容に沿うよう、開発から実装までを頑張る」といったのが従来のスタイルではないでしょうか。

つまり、フェーズ毎に誰が何をするのかが決まっている、ビジネス部門とエンジニアが完全に分離して仕事をしているのがウォーターフォール開発の特徴と言えます。そのため「なんか違う」って気付くのが、受け入れテストのタイミングなんですよね。

それに比べてアジャイル開発では、ビジネス部門もエンジニアも同じチームとして常にコミュニケーションを取りながら進めていきますし、一部分だけでも実装できたらレビューしてもらうといった細かいサイクルで回していきます。ここが最大の違いであり、アジャイル開発の強みだと感じています。

開発に携わるメンバーに違いはありますか？

阪　:
そうですね、適する人材や担う役割など、いろいろな違いがありますね。まず担う役割についてお話しすると、ウォーターフォール開発では、コードを書く人やテストをする人など、エンジニア部門の中でもさらに仕事を細分化して割り振っていきます。

反対にSprintチームで実践しているアジャイル開発では、要件定義から実装してテストするところまで基本的には一人で担当してもらいます。つまり、なるべくその方一人で責任を持つことになります。これだけを聞くとネガティブに思われてしまうかもしれませんが、実は良い面もあって、全プロセスを一貫して担当することができるので、上から下まで齟齬が発生しづらく、品質も維持することができます。


木村：
適する人材としてはどんな人でしょうか？


阪　：
プロダクトについて、自分事として捉えられるような人が、適していると思いますね。実際に、「言われたものだけ作っていたいです」というような人はSprintチームにはいないですし。

さらに言うと「何故作るのか」というところにまで興味を持てる人が良いと思います。Sprintチームのエンジニア社員は「何故作るのか」というところに積極的に意見を言いますし、業務委託のメンバーも「どう作るか」にはちゃんと意見を言ってくれる人が多いですね。

木村：
私からも少し補足すると、アジャイル開発って結構チームワークですし、ビジネスサイドのメンバーとも密接に関わる必要があるんですよね。なのでエンジニア部門もビジネス部門も一緒に参加して議論するような機会が日常的にある、ということを知っておいてもらえたらと思います。

阪　：
今の木村さんのお話は、私が先ほどお話しした「コミュニケーション重視」や「機能に責任を持つ」といった内容とも繋がっていて、要件定義や開発、品質保証などは一人で一貫して担当しますが、それで問題ないかどうかは、ビジネス部門やデザイナー、他の開発者、システムアーキテクチャ担当なども含めて、みんなで進めていきましょうという感じです。

それぞれの開発スピードに違いはありますか？

阪　：
同じメンバーがアサインされる前提であれば、ウォーターフォール開発もアジャイル開発も、それぞれのスピードにそんなに変わりはないと思っています。

ただ、開発スタイルの違いから、「一通り動くようになる状態」になるのは、アジャイル開発の方が早いと言えますね。なぜならアジャイル開発では、大枠を作って動くように見せていって、その後に細かい部分を作っていったり、機能を増やして横展開していったりという流れになるので、まず先に部分的でも動作の確認ができるという意味では、アジャイル開発の方が早くなります。

開発自体がそんなに早いかと言われると、圧倒的に差が出るわけではなく、最終的なゴール地点に到達するまでの時間はそんなに変わらないんですけどね。ですが、不確実性を除去できるというのがアジャイル開発の特徴なので、「やってみたら何か違う」という問題が最後に出るのか、最初の方に出せるのかっていうところの早さは、絶対的に違ってきますよね。

木村：
そうすると、スケジュールの組み方もちょっと違ってきそうですね。

阪　：
そうなんです。アジャイル開発のスケジュールは、現実的なところを目指していきつつも、実際はそれより少し早くなったり遅くなったりで調整するといった感じです。あとはローンチを優先するのであれば機能スコープを調整したり、充実度を調整したりと、スケジュールに対して柔軟性は高いんじゃないでしょうか。逆にウォーターフォール開発では「計画通りのものを出さないとダメ」という進め方なので、全てのリスクをバッファーとして組み込んだスケジュールの立て方になってしまいますね。

最後に、コスト面ではどんな違いがありますか？

阪　：
ウォーターフォール開発は基本的に外注してやる場合が多いので、計画している期間が長くなればなるほどコストが高くなっていくのが一般的だと思います。

次にアジャイル開発ですが、コストが高くなるのかと言うと「よく分からない」というのが正直なところです(笑)。コスト優先なのか、それとも機能の充実度が優先なのかっていうのは、そのプロジェクトの内容次第なので、プロジェクトそれぞれで変わってくると思います。

アジャイル開発でよく使用する手法に「トレードオフスライダー」というものがあって、これは「納期を優先するのか、機能の充実を優先するのか」を決めるのに用いる手法です。

Sprintチームでも実際に「このプロジェクトでは何を重視するんだろう」というのを最初にプロジェクトメンバーで決めるのですが、その際には「トレードオフスライダー」を使用しながら適切に判断していっているんですよ。

木村：
ちなみにコミュニケーションコストといった側面でも違いはありますか？

阪　：
そこは全然違いますね。エンジニアにとって、アジャイル開発の方がコミュニケーションコストというのはどうしても増える傾向はあると思います。

例えばウォーターフォール開発の場合は、エンジニアはコードを書いてテストするだけの場合が多いですが、アジャイル開発では「この作り合ってますか？」「この仕様合ってますか？」「こういうトレードオフありますよ」という風に、常にビジネス部門とコミュニケーションを取る必要が出てくるので、アジャイル開発の方がコミュニケーションコストは発生すると思います。

ちなみにプロジェクトによってアジャイル開発の向き・不向きはありますか？

阪　：
世間では一般的に「大規模なプロジェクトほどアジャイル開発には向いていない」と考えられているようなのですが、個人的には全てアジャイル開発でやれると思いますし、アジャイル開発でやった方が良いという考えです。

ただ、プロジェクトの規模が大きくなると、その方法論と統制が難しくなってくるという意見もあり、それについては理解できるところもあります。もし、大規模なプロジェクトでエンジニア100名集めましょうとなった時に、全員が全員コミュニケーション好きのエンジニアではないと思いますし、ある程度人数規模をスケールしていった場合は、細分化して割り振らないと難しい人も出てくるとは思います。

木村：
その辺りがクリア出来ると仮定したら、大規模な開発であってもアジャイル開発の方が良いということですね？

阪　：
そうですね。木村さんみたいに忖度力があってコミュニケーションが好きで、コードもバリバリ書くぜっていう人が200人くらいいれば、もう200人にスケールしてアジャイル開発やっちゃえばいいなって思ってます(笑)。

木村：
そんな高い評価をいただいていたとは(笑)。

ところでアジャイル開発のデメリットは、どんなものが考えられるでしょうか？

阪　：
コミュニケーションが多い分、やっぱり気苦労も多いですよね。ウォーターフォール開発では自分の領域だけに責任を持てばいいのですが、アジャイル開発だと各工程の相互作用があるので、そこで発生した事象についての対応が必要になってきます。

では反対に、阪さんが思う「アジャイル開発のメリット」は何ですか？

阪　　：
メリットは色々あると思うのですが、一番のメリットだと感じているのは、「よりユーザーに向き合うことができる開発」ということですね。アジャイル開発というのは、ユーザーのメリットや満足といったことがベースになっている開発だと思うんです。

より早くユーザーに使ってもらって、より早くフィードバックをもらって、より早く改善していきたいっていう。そういった姿勢で向き合えるところが、とても良い開発手法だなって感じています。

逆にやっぱりウォーターフォール開発でやる場合は、どうしても「プロジェクトを終わらせる・完成させる」ということが目的になってしまうので、その向き合い方の違いが、アジャイル開発の最大の魅力じゃないですかね。

お二人とも、ありがとうございました！

今回は、Sprintチームのエンジニアである阪さんと木村さんにお話いただきました。

この記事が皆さんにとって、アジャイル開発を捉え直すきっかけになったら嬉しいです。次回の記事では、アジャイル開発のより実践的な話に焦点を当ててインタビューしていきます！どうぞ「SOMPOホールディングス」をフォローしてお待ちください。

Sprintチームでは現在、エンジニアを募集しております。今回のインタビューを読んで、Sprintチームに少しでも興味を持っていただけましたら、ぜひ「話を聞きに行きたい」よりカジュアル面談にご応募ください！

カジュアル面談では、働く環境や今後のキャリアについて、自由にお話しすることができます。少しでも気になった方は、私たちと一緒にお話ししてみませんか？

SOMPOホールディングスでは、今後も様々な社員やプロジェクトを紹介する記事を掲載していきますので、次回もどうぞお楽しみに。