弊社iOSアプリにアーキテクチャを導入してみた ~計画編~

はじめに

サーバサイドチームに所属している丁(てい)です。

前回の記事で弊社のiOSアプリにアーキテクチャを導入する前の状況とアーキテクチャを導入してどう変わったのか？をスーパーざっくりご紹介させていただき、その記事を皮切りにアーキテクチャ導入過程の紆余曲折記事を順番に書いていくことを予定していたのですが、その後全く気が向かず長いこと放置していました。

4月に入り気候も少し暖かくなってきたこともあり気が向いてきたので、本日はアーキテクチャ導入当初のお話をもう少し詳しくお話しできればと思いますので、気が向いた方は暫しの時間お付き合いいただけますと幸いです。

導入計画の策定

アーキテクチャを導入しよう！ということは決まりましたが、意気込みだけでは何も前に進みません。 そう、何をどうしていくのか？という計画が必要になります。 そこでまずはこんな項目を網羅した導入計画書を作成しました。

・目的
 　・アーキテクチャを導入することの素晴らしさについて嘘をつかない程度に誇張表現を交えつつ400字程度でまとめた。
・方針
 　・MVP+CleanArchitectureを採用するメリットなどをなるべくわかりやすく400字程度でまとめた。
・進め方
 　・担当者が誰でどの画面から着手してどの順番で進めていく。。。などをもっともらしい文章で800字程度でまとめた。
・ガント
 　・進め方をベースに週単位、月単位でスケジューリング。

実際のガントイメージ f:id:jmty_tech:20210427155317p:plain

この導入計画書はチーム内の意識共有のためという側面ももちろんありますが、主目的は他部署に対する説明です。

アーキテクチャ導入はリファクタリングの範疇なので長期的視点に立つと生産性の向上に大きく寄与するのですが、短期的には特に非エンジニアの方から見るとメリットをいまいち把握することが難しいです。

また画面単位で大きく手を入れることになるのでその期間は該当画面に対するエンハンス案件を回すことが難しくなり、仮にビジネスサイドの人が「この画面の改修案件進めたい！！！！」って思っても、「いやいや今リファクタリング中だから無理っす。。。」というなんとも気まずい空気を作り出す危険性を孕んでいます。

そう言った認識齟齬や納得材料として非エンジニアの方にもある程度納得いただけるように少し時間をかけて導入計画書を作成して他組織に展開して同意を獲得する作業を一番最初に行いました。

ここで一番効果があったのはやはりガントをある程度ちゃんと引き共有して、該当画面の作業期間中は事前にエンハンス案件検討から外してもらえるように調整できたことで、組織間コンフリクトを少なく抑えることができたことだと思います。

回帰テストケースの作成

計画書を作って全体共有もして、さあいよいよ待ちに待ったコーディングだ！！！。。。とは残念ながら行きません。

アーキテクチャが適用されていない画面にアーキテクチャを適用しようとするとかなり膨大な修正となり、(Objective-Cで作られてる画面など)場合によっては完全リプレースとなる大掛かりな修正となります。

アーキテクチャが適用されていない画面はほぼ全てのビジネスロジックがViewControllerに無秩序に記述されているのでその部分にガッツリ手を加えるとビジネスロジックが簡単に壊れることは想像に難くありません。

また画面の仕様を全て表す仕様書などがあればそれを拠り所とすることは可能かもしれませんが、日本全国津々浦々のどのシステム開発現場においても、現状の機能と寸分違わない仕様書の存在は都市伝説だと思っています。（偏見） ※ 日々刻々と変わっていく仕様を全てドキュメントに落としていくのは無駄という側面もありますしね。

したがってアーキテクチャ適用後もビジネスロジックの挙動に変化がないことを何かしらの手段で担保する必要があるのですが、我々は画面別に回帰テストケースを作ることで担保する方針としました。

回帰テストケースイメージ f:id:jmty_tech:20210427155011p:plain

ここで言う回帰テストケースとは「画面の全ての機能を網羅したぽちぽちテストケース」のことを指します。 ※ 「ぽちぽちテスト」とは自動テストじゃなく人間の手で行う動作確認テストのことを指しますが、この言葉を使ってるのは私だけかもしれません。

実装者はまず担当画面の仕様をくまなく洗い出すために以下の二つの切り口で画面の全機能を洗い出していきます。

  • FatViewControllerを頑張って読み解いて機能を洗い出す
  • 対象の画面をぽちぽち触りまくって見てソースリーディングで見落とした機能がないかを洗い出す

もしソースが綺麗に分割されていて洗練されていたら後者の作業は必要なかったかもしれませんが、残念ながらそうではなかったので非常に地味でつらい作業ですがこの過程を無視することはできませんでした。

この地味で孤独できつい作業を一通り終えて乗り越えたらいよいよ本番のアーキテクチャ適用作業に取り掛かることができるようになります。

今回のまとめ

iOSアプリへのアーキテクチャ適用に関する記事の2回目ですが、いまだにXcodeのXの字も出てきませんね。

ただし広範囲にわたるソースコードの改修は関係各所至るところに大きな影響を与えるので、前準備をしっかりすることがかなり重要なキモとなります。

今回ご紹介させていただいた内容の範疇だと以下の2点ですかね。

  • リファクタリングをスムーズに進めるためには計画をしっかりと立てて、他部署への共有をしっかりとしましょう。
  • 大規模改修の際はできるだけ緻密なテストケースを作りましょう。(回帰テストケースは仕様書と同様にその後の画面改修の仕様に追いつかせるのが大変(無理？)という課題はありますが。。。)

次回はいよいよ導入編に入る予定ですが、また気が向かない期間が長くなりそうな予感はしてます。

気が向いたら書こうと思いますので、その時にはまたお付き合いいただけますと幸いです。