今回お話しするのは、筆者の新卒入社一年目での出来事についてです。
はじめに
筆者は、新卒で某メーカーの子会社（現在は他グループに買収され、子会社では無くなっている）に入社しました。入社一年目にもかかわらず、とあるデバイスとWi-Fi通信しファイル送受信・操作などを行うiOSアプリの開発メンバにアサインされました（Androidアプリ開発も並行して行われており、それは他の先輩社員が担当していました）。ただし、開発メンバは自分のみ、先輩はフォローすると言いながらも別プロジェクトの作業で手が塞がっている、といった状態でスタートしました。
初のiOSアプリ開発
一年目からひとりで任されるって、入社時点ですでにスキルを持っていたんですね！と思われるかもしれませんが、一切そんなことはありません。ガチガチの初心者が1人で某メーカーの製品向けのアプリを作成していたのです。製品自体はクライアントが製造し、筆者サイドはアプリのみ開発する、という形のプロジェクトでした。
Xcodeを使ってアプリをビルドする、という基本的なことからネットで調べ、なんとか独力で開発を進めることになります。
わからないことだらけ
当然、作業をしていても全くわからないことだらけです。Objective-Cの基本もっわからないまま、Apple公式のサンプルやチュートリアルのページを参考にしながらつぎはぎでアプリを作成していました。
当然、壁にぶちあたります。
- 画面遷移が思った通りにいかない
- 画面を重ねすぎてアプリがめちゃくちゃ重くなる
- 写真を扱う機能の実装方法がよくわからない（大きい画像を操作するとメモリ不足で死ぬ）
などなど、毎日のように初心者ならではの壁にぶち当たりますが、先輩に質問しても「わからない、調べてみて」の一言。筆者は英語を読むスキルだけは多少（ほんとうにちょっとですが）備わっていたため、当時からStackOverflowなどのページで調査したりしてなんとか解決しながら進みました。
評価フェーズ
さて、ある程度実装が進みテストに移ることになりますが、ここで大量の課題が発生します。それは、「Android/iOSアプリ間で微妙に動作が違う」という点です。
入社一年目のど素人が当然こんなこと考えられておらず、以下のような差が生まれてしまっていました。
- エラーダイアログを出すタイミング
- エラーダイアログを閉じた後の画面遷移
- http通信のタイムアウト時間やアプリ側でエラーと判定する条件
などなど、Androidアプリ担当メンバと細かい点まですり合わせを行なえていないまま実装が進んでいたのです（当然仕様書なんて適当なものしか存在していません）。
今振り返ると、プロジェクト管理をしていた先輩や、Androidアプリ担当していた方が新人をフォローしてやれよ、と思いますが、先輩方は他のプロジェクトを兼任されていたので手が回っていなかったんだろうと思います。
システムテスト
前述した課題を乗り越え、なんとか実際のデバイスと接続してのシステムテストが行われました。ご推察のとおり、今まで出て来なかったような課題が出てきます。最終的にはハード側に原因があったのですが、当時は何が原因かわからず、httpのパケットキャプチャまでして原因究明にあたりました。
原因を突き詰め、クライアントに説明しても「ハードではnaosenaiからアプリ側でなんとかしてほしい」の一言。泣きそうになりながらなんとかアプリ側で対処する方法を見つけ、スマホアプリを直していくのでした。
当時はクライアントとの折衝は先輩社員が行っていたため、この点もどのような話し合いがあったのかわかりませんが、それであればスケジュール調整や費用請求などすべきだろうと今では思います。
ギリギリのスケジュール
これまでのような話が重なって起きていたにもかかわらず、スケジュールはプロジェクト立ち上げ当初から変更がありません。当然デスマーチと呼ばれる状態になります。
筆者も１５０時間弱残業した月がありましたが、会社のルールで最大１２０時間までしか残業時間がつけられないため、実際は夜中まで働いているのに勤務管理表上は定時退社したことにするなどしていました。今思うと労基にいえば残業代もらえるような気もしますが・・・
デスマーチを乗り越えリリースへ
いろいろありましたが、なんとかアプリリリースへ漕ぎ着けました。会社としてはたしか８００万円ほどの赤字でプロジェクトが完了していたと思います。プロジェクトマネジメントしていた先輩は経営層への報告を強制されるなど、大変そうだったのは覚えています。
なんでこうなったのか？
開発当初は余裕のあるスケジュール、開発規模だったのです。ふりかえると、クライアントからの要望がどんどん膨らみ、開発当初の見積もりから逸脱した内容だらけだったにもかかわらず、そのまま依頼をすべて受けてしまっていたのです。たしかに、ちょっと頭のおかしいクライアントではありましたが、マネジメントに問題のあったプロジェクトだと断言できます。
課題のあるプロジェクトは上司へ報告し、リソース調整やクライアントの折衝を補助するなどの助け船を出す仕組みが存在いていたのですが、おそらくマネージャがそれをできていなかった、または課長がフォローしてくれなかった、のどちらかだとは思います。
学び
一年目から辛い思いをしましたが、開発スキルだけでなく色々なことを学ぶことができたと思います。振り返ってみると、ある意味良い経験だったなとも思いますし、今では笑い話にしているぐらいなのでメンタルにもそこまで影響はなかったと思います。（ただ、当時持病が悪化したタイミングがあったので、多少の影響はあったのかもしれませんが・・・）
この話から、みなさんも以下の点には気を付けてアプリ開発をすすめていきましょう
- 同じ仕様のアプリを作る場合は、認識齟齬がないようにしましょう
- Flutterなどを用いたクロスプラットフォーム開発なら解決するかもしれませんが、ケースによってはネイティブコードを書くことになるので注意は必要
- クライアントへ見積もりを提示する際は、前提条件を明記する
- あとから出てきた追加要望や仕様変更を切り分け、客先との折衝に用いる武器となる
- クライアントからの要望は簡単に受けない
- もちろん、簡単なものはCS（顧客満足度）のために受けても良いと思いますが、やりすぎは厳禁
- 出来ないものは出来ない、わからないものはわからないと正直に言う
- これも場合によるかもしれませんが、打ち合わせの中でわからなければ、「持ち帰って回答します」といった形で宿題にさせてもらうなどしましょう
コメントを残す