iOSアプリチームの設計の取り組みについて

iOSエンジニアの二木です。

iOSアプリチームでは、開発する機能について積極的に設計や設計レビューを行うようにしています。
数年前までは、実装する前にどういう作りにするか簡単に検討するものの、
検討すべきことがあまり検討できてなかったり、機能を作るまでの全体的な作りがイメージできていなかったりと、エンジニアよって設計の粒度は様々でした。
結果、いろいろな問題が発生したという過去があります。

今回はここ数年で取り組んできたアプリ設計について、発生した問題も含めて紹介したいと思います。

過去に発生した問題

実装前にあまり設計行わず実装フェーズに入った結果、過去に発生した問題は以下の通りです。

• 設計フェーズで検討していないことによる問題が後工程で発覚して、対応の検討から始める必要性が出てきた
• アプリ仕様をうまく設計方針に反映できていない
• アプリの作りが複雑になってしまい、エンハンスが難しい
• 機能の役割が整理できていないため、1箇所バグを修正すると別の場所でバグが出る
• 独自に同じような処理を複数作ってしまっている

このような問題があり、これまで個人に依存してた設計フェーズを見直し、チームとして設計スキルを上げていくため、設計フェーズに力を入れていくことにしました。

設計を始める前に発生した問題

設計に力を入れていこうと決めたものの、いざ設計を始めるとなると、これまでの開発の進め方と違うところがあり、すぐに進められないという問題が発生しました。エンジニアからも設計に対する意見が出たので、その内容と対策の一部を紹介したいと思います。

【意見1】

どういう点に注意して設計してよいかわからない

【対策】

意見の内容としては、これまであまり設計をやったことがないため、設計で検討する内容がよくわからないということでした。それを受け、設計経験から設計観点を作成し、設計時に必要な観点をまとめて共有しました。設計観点には以下のような内容があります。

<設計観点（※一例）>

• モジュールに共通の機能を持たせる場合、モジュール間を疎結合にできているか
• アプリの複数のイベント発生契機を考慮できているか
• APIをコールするタイミングが検討できているか
• エラーハンドリングを検討できているか
• Viewについてシンプルな構造になるよう設計できているか
• 機能の改修時に影響範囲が洗い出せていて、それを踏まえた上で修正方針が立てられているか
• 今後よく利用しそうな機能について共通化を検討し、利用されることを意識した作りを設計できているか
• 複雑な設計になりそうな場合、APIもしくは仕様を調整することで回避できないか
• 機能の役割や範囲を意識できているか
• ガイドラインに反した作りになっていないか

【意見2】

設計書をどう記載すればよいかイメージできない

【対策】

この意見の内容としては、設計内容を設計書に書いてと言われても、どう記載してよいかわからないということでした。設計時によく検討する項目について、設計書のフォーマットに項目を用意し、その項目に従って設計内容を記載しやすいようにした。（意見1で作成した設計観点を参考にしてもらった上で、設計書の体裁を考えることや設計書そのものを書くことではなく、その内容自体の思考に集中できるようにしました。）

設計書の項目内容は主に以下の通りです。

<設計書の項目内容>

1.機能概要
→ アプリの要件を元に開発する機能の概要を整理してまとめます。
2.設計方針・詳細設計
→ 1でまとめた機能毎に設計方針を決定し、詳細な設計を記載します。
（※複雑なフローになる機能がある場合はシーケンス図にまとめ整理します。）
3.ライフサイクル
→ アプリのライフサイクルに基づく処理の実行を整理します。
4.アクション
→ ユーザーアクションによる処理の実行を整理します。
5.エラー処理
→ 起こり得るエラーを洗い出し、エラーハンドリングの処理を整理します。
6.特記事項
→ 1〜5に当てはまらない特記事項を記載します。
7.API項目対応表
→API通信が発生する場合にAPIレスポンス項目をチェックし、アプリ側の処理を整理します。

設計の取り組みによる効果

設計の取り組みを初めて、少しずつですが効果が出てきているように思います。
私はEAPのプロダクトの開発を担当していますが、そこで感じた効果をまとめてみました。

• 設計時に機能を整理することにより、自分の仕様理解度が見えるようになった。
• 設計段階で仕様の調整の必要性に気がつくようになり、早い段階でエスカレできるようになった。
• 実装フェーズでの考慮漏れの発生が少なくなった。
• 設計方針をまとめることにより、必要な部分はiOS/Android間で方針を合わせることができるようになった。
• 設計フェーズによりアプリの作りについて考える契機ができ、設計に対する意識も変化した。
• エンジニア間のコミュニケーションや情報共有が増えた。
• 単体テストのためのインプットになり、何をテストするべきかがより明確になった。

また設計フェーズでは、設計自体で終わるのではなく、その設計した内容についてフィードバックを受けたり、悩んでいる設計内容についてディスカッションしチームで解決したりできるよう、設計レビューを設けることにも取り組んでいます。

さいごに

ここまで設計の取り組みを話してきましたが、開発現場を見ているとまだまだ課題があるように感じています。
設計力が身に付けば、設計した内容をソースコードに落とし込むだけなので、効率がよくなるように思いますが、プロジェクトの状況やエンジニアの得意分野は様々なので、うまく進められるように設計フェーズも工夫していく必要があると感じています。

よりよいプロダクトを開発していくために、必要なことは今後も積極に取り組んでいきたいと思います。