iOS/Androidアプリを突貫工事で開発するときにやって良かった!悪かった!こと まとめ

ここ5年間で上場企業さんのアプリを30本ほど、新規開発・エンハンスを行なってきました。
基本はWebAPIを仕様したアプリで、たまにIoT系のアプリを作っていました。

開発規模は、半分がひとりぼっちで開発、そのほかがアプリ開発者がiOS,Android合わせて2-4人ぐらいでやっていた案件が多かった気がします。
アプリ開発ということもあり、それなりにタイトなスケジュールで開発してきたので、突貫で開発する時に各工程ごとにやって良かったとこ、悪かったことをメモっておきます。

• 要件定義にはほとんど関わってきていないので、それ以下の工程での話になります。
• 受託開発かつ、ほとんど設計書がない開発(RFP・API・デザイン系書類のみ)をしてきたのでちゃんとした開発会社さんで開発している方々には全く参考にならない内容です
• 主機能の動作品質>=納期>>>バグがあっても問題のない機能の品質>>ソース品質>>>>引き継ぎ 順に優先して開発しています。納品時はソースの品質よりも機能が動くことが最優先されるためこの順番付けです。

今後も特に気を付けたいことは太字

開発前

良かったこと

1. 納期、正常系品質、コード品質、異常系の品質、デザイナーが作成したデザインの再現レベル、など納期・コストにか関わる部分の必須度合い、優先度を確認しておく。
   （例えばニュースアプリで金融アプリ並みの品質チェック、セキュリティー考慮をしても無駄な場合が多いとか）

2. ワイヤーフレームレベルでモックアプリを作成してクライアントさんとのアプリ動作、画面概要の認識合わせ

• 画面が足りない、すごく使いにくい、致命的な認識齟齬などを早めに発見できた

1. エラー処理周りの早期仕様決定

• 突貫でも、エラー周りの仕様だけはクライアントさんとどうするか決めておくと開発中に心が楽になる
• また、エラー周りを後回しにすると複数人開発時は開発中にものすごい手戻りが発生して危険

1. WebAPI開発側のスケジュールと想定される品質の確認

• APIと連携するアプリは,API側がダメだとアプリもダメになってしまうので、スケジュール、API側の開発品質を考慮した上で開発スケジュールを組む必要がある。（アプリとサーバーAPIの開発会社が違う場合は特に）
• APIが動く前提で進めると基本的に終わるので、APIの動作確認期間を確保しておく

1. デザインのスケジュールと、遅れた時の対応を確認

• 最近の案件では、デザインの納期遅延の確率が80%を超えているため、デザインが遅れる前提でスケジュールを引く
• デザインの遅れの許容範囲をあらかじめ決めておき、そこを超えたら開発のスケジュールが必ず遅れると、偉い人とネゴっておくとベスト！

1. デザイナーが作成したデザインの実現性の確認

• 標準UIから外れるデザインの場合、工数が10倍以上に膨れ上がる場合があるので早めにチェックする

1. 動作保障端末、OS、画面回転対応を有無を確実に決めておく

2. 明らかに無理なスケジュールの案件は門前払いをする

3. クライアントさんの話を鵜呑みにしない

• クライアントさんはアプリに詳しくない場合が多いため
• 開発側に都合がよく、クライアントさん側にも魅力がある様な仕様で進めていく

1. 類似アプリをインストールして調査しておく
2. クライアントさんが既に公開しているアプリがあればインストールして軽く使ってみる

悪かったとこ

1. デザイン部分を作り込んだモックアプリでの顧客とのアプリ動作、画面概要の認識合わせ

• Storyboardで作成するとView周りはそこそこのものがすぐにできるので、開発前に作ってクライアントさんに確認を取ってもらったのですが、クライアントさんが各機能の中身よりUIを先に決めたがってしまったので肝心の機能周りがTBDだらけになってしまった。
• クライアントさんにアプリ開発ってWebと変わらないくらいすぐできると思われた
• また、だた単純に不必要な工数を使ったような気がした

1. iOSとAndroidの仕様を無理に合わせた
2. スマホとタブレットの違いをしっかりと把握せずにタブレット専用アプリの見積もりをした

開発中

良かったこと

1. 車輪の再発明を原則しない（特にModel周り）

• バグが増えるだけなので絶対に行わない。案件内でやるのは時間の無駄。

1. 実装内にTODOが残らない様に実装順番を調整する

• 突貫案件でTODOすると確実に忘れる

1. モックAPIの作成

• 固定Jsonレスポンスを返すモックがあると開発中に便利!!

1. 設計書を作らない

• クライアントさんの気分で仕様がコロコロ変わり、メンテしきれなくなるので作らない
• 必要な案件の場合は逆起こしで対応

1. 案件ごとに実装方法を変えてみる

• 常に同じ方法で実装していると、良い実装方法を考えなくなるので、あえていつもと異なる実装方法を試す。何よりいつも同じだと飽きる。
• ただし、余裕がない時は、鉄板の実装方法を使う

1. 規模に応じてソース管理の方法を少し変える

• 一人の時はdevelopブランチのみで開発、複数人の時はチケットor機能ごとにブランチを切る

1. ユニットテストを組まない

• コロコロ仕様が変わる状態で、UTを作るのは時間が勿体無いのでやりません。工数もない！
• 小規模なフルスクラッチの開発で、UTを書かないと品質が担保できないケースはないので問題なし
• Model、エラー処理、再帰的なロジック周りはなるべく自動化を行い、テスト無しで品質を保てる様に実装する
• 自動化出来ない部分については手動でテストを必ず実施する

1. 週2回はできたところを全体を軽くテストする

• ただし、細部のテストをしてもソースをいじったら無駄になるのでサクッと終わる程度のテストのみに絞る

1. 複数人開発時は開発リーダを立てる
2. 開発メンバの経歴をあてにしない
3. 必要以上に拡張性を意識しない

• アプリによっては拡張性よりも、とにかく安くしたいお客さんもいるので、今後継続開発がなさそうな案件は、拡張性を優先するよりもテスト工数が下が理想な開発方法をとる

悪かったとこ

1. モックソースを本番へ流用

• バグが紛れ込んだり妥協した実装が混ざるのでぶち壊した方が開発後半が楽になる気がします

1. 過剰なコメント入れ

• 時間がない案件では、ソースないのコメントの管理まで手が回らない。コメントは必要最低限に。

1. 社内の人が作成した車輪の再発明コードの再利用(どうしても必要な場合は別)

• バグが入っている上に、OSSの下位互換でしかない場合がほとんどなので使用しない

1. 小規模アプリの複数人での開発

• 無駄に時間がかかるだけ。どうしても複数人でやりたいのであれば、実装する人、コードレビュー&品質管理に分ける
• だいたい完成したら引き継ぎを兼ねてテスト、バグ潰ししながら2,3人で

テスト

良かったこと

1. 開発者以外の人もテストする

• 開発者+仕様をある程度知っている人の組み合わせが安定したテストになりやすい

1. iOS,Android開発者同士でクロステストをする
2. 各OSごとにバグりやすい点をまとめた表を事前に作成し、とりあえずテストをしておく
3. フリーテストの時間を明示的に設ける
4. TestFlight など活用できるものはなるべく使う
5. テスト中はブランチごとにアプリのバージョン付けを行いどのバージョンでバグったか管理する
6. 厳密なテストを行う前に、クライアントさんに実装完了した仕様で問題がないか正常系の動作確認をしていただき、コミットさせる

悪かったとこ

1. 開発者のみでテストをする
2. 過剰にエラー系のテストをする

• リリース環境でほぼ起こらない部分のテストはクリティカルな部分(ログイン周りなど)を除いて行わない

1. テスト仕様書のみのテストをする

• テスト仕様書でテストを網羅できるわけがないので、フリーテストでカバーする

まとめとしては、突貫案件には突貫なりの開発の進め方があると思うので、規模、スケジュールに応じて開発、プロジェクトの進め方をカスタムしていくといいのかもしれません。

ねれない勢いで書きなぐったので、何か思いつくごとに加えていきます。。。