新プロジェクトをスクラム組んで進めるために、エンジニアチームで取り組んだ事前準備

こんにちは、ローソンデジタルイノベーション（LDI）でエンジニアやっている岡崎 裕樹です。

LDIで新しく始めるプロジェクトを本格的にスクラムを組んだアジャイル開発で進めようとしています。
ただ、まだプロジェクトは企画段階なので、この期間にエンジニアチームとしては、アジャイルを始めるうえでの事前準備をしているところです。今回は、その取り組みについて書こうと思います。

TL; DR

スクラム開発というと、スプリントを数週間で区切って、スプリント終わりにはユーザーストーリーに即した形で何らかのリリースを行い、フィードバックを受けながら短い間隔でサービスを少しづつ改善していくというような形をとります。

リリースサイクルが速いということは、必然的にテストやリリース作業の回数が多くなることになります。そこで問題になるのは、こういった作業も地味に時間がかかり、回数を重ねるほどバカにならない工数がかかることです。ここに長い時間をとられてしまうと、設計・開発にあてる時間がなくなってしまうことから、リリース時に繰り返し行う作業を自動化して、品質を維持しつつ作業時間の削減は必須と言っても過言ではないです。

今、我々エンジニアチームは、本格的プロジェクトが開始するまでに、この問題に対応すべく、技術的な調査、インフラの構築を行っています。

今回は、ここで行っていた改善活動についてかいつまんで紹介します。

ちなみに、それぞれの内容についての技術的な深掘りはこの記事ではなく、こちらで紹介しているので、よければこちらも御覧になってください。（今後も適宜投下予定）

CI/CD環境を整えよう！！

上にも書きましたが、リリースサイクルを上げるうえで、テストやデプロイなど自動化できる所はどんどんしていかないと、ここで時間を忙殺されてしまい、スクラムを回すどころではなくなってしまいます。

継続的インテグレーションの必要性は分かっていても、実際にうまくできるかという話になると言葉を詰まらせる所は多いのではないでしょうか。

特にプロジェクトの途中から導入しようとするとなかなか難しい所があります。今回は、プロジェクトを新しく始めるので、基盤やアーキテクチャを見直してCI/CDがやり易い形で始められるので、この機会にしっかりした環境を整えるべくCI/CD基盤を作り始めています。

• ユニットテストを自動実施、テストレポートの出力と、エラー時は通知を出すようにする
• ソースをコミット後、Lintを掛けてエラーが出たら pull request を出せないようにする
• リリースモジュールの自動ビルド
• βデプロイ
• 本番環境へのデプロイは間違って出ると怖いので、ここは手動でやる

こんな事が出来ることを目標に現在それを出来る環境を構築中です。

ちなみに自分がやっているように書いてますが、調べてくれているのは別のメンバーです。これが他人の褌で相撲を取るというやつなんですかね、、、いい感じに作ってくれていてとても心強いです。

アーキテクチャを見直し、開発言語を選定しよう！！

もともと作っていたアプリの、開発開始が結構古いこともあり、言語は iOS は Objective-C（部分的にSwift化はしています）、Android は Java （こちらも部分的に Kotlin化してます）がベースとなっており、アーキテクチャもMVCとなっています。

この形態で開発を経験されたエンジニアであれば、痛いほどわかるかと思いますが、 ViewController が肥大化して、テストも書きづらく、正直メンテナンス製が良いとは口が裂けても言えないです。
（あくまで個人の感想です）

また、Java ならまだ耐えられますが、Objective-C は正直苦行以外のなにものでもないです。
（あくまで個人の感想です）

ご存知のかたも多いと思いますが、これらの代替えとしてより良いものは世の中に沢山（？）あります。「既存のやり方に固執せずに変化を受け入れなければ成長はない」とどこかの偉い方が言っていた様な気がするので、スピード感をもって設計、実装、テストを行える開発言語とアーキテクチャに見直すことにしました。

言語に関しては、iOS はSwift 、AndroidはKotlinを採用します。この辺は今更新しいとはちょっと言いづらい所ですが、サーバーサイドも見直したいという事になり、 Go言語を採用できないかという事で学習コストや実用性などの調査をしました。

また、アーキテクチャとしては、Clean Architectureをベースとして、レイヤーわけして各々の役割を明確化しつつ、レイヤー毎に依存性を薄くしてFatなつくりを無くすことで、拡張性、メンテナンス性をあげることを目標としています。

現在、これらは調査を終えて、実際に簡単なサンプルを作ってその有効性の共有をしました。
あとはもう少し実務的な所に寄せる際のテクニックなどを洗練させるべく深掘りしています。

今後の展開、Sprint0 に向けて

方向性や考え方に差がでてもうまく回せないので、アジャイルとは、スクラムとは何かを認定スクラムマスターから講習を受けたりすることもこれから予定しています。

他にも、ツールの選定をしたりと事前準備としてはかなり手厚くやらせてもらってます。

本格的なプロジェクトの開始はこれからで、この先プロセスを進めていく中でも良いところは残し、悪いとろこを洗い出して改善していくということを振り返りながら実施していきます。そのため、今書いている内容も1，2ヶ月後には陳腐化しているかもしれないですが、その柔軟性こそアジャイル開発では大事にしなければ行けない所だと考えます。

LDIでは、プロセスの改善を共に考え、同じ目的を共有してサービスを作り上げるメンバーを捜しています。この記事を見て少しでもLDIに興味を持ってくれた方、ぜひお話ししましょう！