Help us understand the problem. What is going on with this article?

【SES】ドナドナされる時の面談時に地雷案件をなるべく避けるための確認ポイント7選(iOS/Androidアプリ開発)

私は、客先常駐でアプリを開発、保守するのをメインに5年ほどお仕事してきました。
iOSとAndroidのどちらかを担当して、機能やスケジュールの提案をしつつ、もくもくと開発していることが多いエンジニアです。

常駐のため、現場が変わるごとに面談があり(法律なんか知らん)、その度にやばそうな雰囲気の出てる案件は基本的に避けるようにしています。
現場に入る前の面談で、これを確認すれば、地雷案件を少し回避できるポイントがなんとなくわかってきたので、メモっておきます。
※あくまで個人的な指標であって、なんの根拠もないです!!

保守案件の場合は、アプリのストア評価を確認

保守案件で、ストアの評価が低いアプリは可能な限り参画を回避します。

理由は、

  • ストアの評価が低いものは、内部の品質が基本的に低い
  • 新たな開発はできずに、既存バグの修正に追われて疲弊する
  • ただのバグ修正ではスキルがつきにくい
  • クソコードを見ると発狂する(コントローラにAPIリクエストが入っているとか無理)
  • ひどい場合、gitすら使ってない
  • その他色々

だからです。
何より、過去に低評価アプリを3つほど、保守・機能追加を担当して、すごく苦労したので

アプリのアーキテクチャーを確認

  • 全てをControllerに実装するアーキテクチャ
  • MVC
  • MVVM
  • VIPER
  • CleanArchitecture
  • など

色々とありますが、開発するアプリのアーキテクチャが決まっている場合があるので、確認します。

保守開発の案件で、既存のアーキテクチャを教えていただけることがあるのですが、
なぜか「CleanArchitecture」を使用してると言われるプロジェクトは、クラス名だけCleanArchitectureで、中身はぐちゃぐちゃの地雷が多いです。

経験上、「CleanArchitecture」と「全てをControllerに実装するアーキテクチャ」は避けたい対象となっています。

常駐先の会社さんにアプリ開発をできるプロパーさんがいるか確認

受託開発の新規作成案件で、アプリを開発できるエンジニアさんがいない会社が受けた場合、要件定義や見積もりでやらかしている可能性がかなり上がります。
Web画面を作る感覚でアプリの見積もりをしてしまった案件の場合は、開発工数がそもそも足りていない場合が多くあるイメージです。

見積もりが多い分には、常駐する側としては問題ないのでが、やらかしている可能性が高い案件の場合が多いので、なるべく避けるのがおすすめです。

開発者を複数人募集している案件は、他のメンバーのスキルを確認

最近の案件は、1アプリを2~3人くらいで新規開発をする案件がそこそこあるイメージです。
ただし、複数人開発と言えど、

  • 新人さん(2年未満)
  • アプリを一人で作ったことのない人

が相方として参画しそうな場合は、申し訳ないですが確実に避けるようにしています。
(他の人の面倒を見るのは避けたい。ただし、面倒を見る費用をもらえる場合は別途相談)

また、開発規模の割に人数が多い案件の場合は、
スキルの低い人間を集めて、クライアントへの見積もりをカサ増ししている案件が多いです。
(できる人が1人で2ヶ月できるのを、4人で半年とか)
結局、できる人間が全て作るハメになるので、避けるようにしています。

SIer系は避ける

会社さんによりますが、古いルールとかに縛られていることがあるので、近づかないほうがいいイメージ。
特にスーツ必須のところは、ちょっと怖い。
※うちは、違うぜ!だ感じの会社さんはごめんなさい。経験上は、どうしても多いのです。

フロアのエンジニアの残業状況を確認

面談の際に常駐先のエンジニアの残業状態を確認します。
残業をしている人が多い場合は、だらだら仕事する癖がついている or 仕事量がおかしい 現場の可能性が高いので、なるべく避けます。

質問は、自分から質問すると残業を避けたがるエンジニアのイメージがつく気がするので、営業から質問してもらえるようにお願いするのがベストです。

スクラム開発の場合に、スクラムの前提を満たしているか確認

最近流行っているスクラム開発を取り入れている案件がそこそこ出てきました。
ただし、スクラムをやる上で、前提条件を満たしていない案件が多いので注意が必要です。

  • 全機能ができる納期がある????
  • スキルがバラバラすぎる
  • クライアントがスクラム開発に乗り気ではない(POさんがいないとか)
  • スクラムを銀の弾丸と思っている人がいる(スクラムだから開発に成功するとか)

(前提条件を満たしていない時点で、スクラムではないと思いますが。。。)

また、これは個人的な都合ですが、以下の点でスクラム開発はちょっとやりにくいところがあります。

  • 作業見積もりをごまかしにくい
  • 最初に一気に開発して、開発期間の最後の方でゆっくりすることがしにくい(開発期間の余ったところでだらだらするのが趣味のため)
  • 全員バラバラの所属で、ガッチリとしたチームプレーはちょっとめんどい

色々、ネガティブなことを書いてますが、うまくはまっているスクラム開発は色々と新しいことができて楽しいのでおすすめです!!

開発環境の確認

  • Mac/PCの簡単なスペック(メモリ8GBじゃ辛い)
  • iPhoneなどの実機の有無

などを念の為確認すると、あとで開発中にイライラするのを防げるかもしれないです。

まとめ

色々書きましたが、結局は現場に参画してみないとわかりません。
iOSアプリを開発すると聞いていて、Androidアプリを開発することはよくあるので。。。
スキルが複数ある場合は、しれっと他の案件にすり替わってることがあるので、回避不可能です。

わざわざ、大変だったり辛い現場に行くのは勿体無いので、
お金をもらえながら、楽しくてスキルのつける現場になるべく行けるように、これからも頑張って面談していく予定です。

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away