なんだかよくわかりませんが一人で調査企画設計開発デバッグと全部やらされたのでこの経験を共有できればと思います。
アプリケーションと言ってもスマホ系アプリではありません。
その時にどんなことを意識して作ったか簡単に書いていこうかと思います。
調査
自社がどういったことをしたいのかを様々な人から話を聞き、市場を調査します。
市場で使えそうなもの、自社で何がしたいかを考えながら最初は広く浅く。調査が進んだら、ターゲットに対して集中して調査していきます。
企画の意見出し
まずアイディアが出たら紙にどんどん書いていきましょう。
ブレインストームとかで付箋を使ってアイディアを出すこともあると思います。
自論ですが、PCとかで意見を出していると、タイピングする段階で自分の意見をある程度まとめて打つことになるので、アイディア出しの段階では向いていません。とりあえず、意見を出す。見栄えのいい意見ではいいアイディアは出ません。
自分から見て「泥臭い・みっともない・古臭い」と思った意見でも考え方を変えるだけでいいアイディアになるかもしれません。実際、今の技術でできることを考えてみると思った以上にできそうだなと思えました。
企画のプレゼン
今度は企画を決めるためにプレゼンテーションをおこないます。
特にプレゼンで気をつけてやるよりも自分がやりたいことをアピールしていかに会社がやりたいものに近づけて言うかが大事です。だいたいここで修正とかダメ出しをたくさんもらいます。
設計
企画を通したらハードの条件は○○にしてソフトは○○にして etc...を決めていきます。
今回は社内でお試しで使うものだったので大体は勝手に決めて作っていきました。
最初は紙に書いて次第に清書していく段階でXMLなどで書式を整えていきます。
開発
設計書通りに進めていきます。基本ここの段階で詰まった場合は設計がおかしいとコーディング中に気づいた事が多かったです。
設計段階で修正するよりもここの段階で修正することは大変でした。
オブジェクトの相互関係とかを見直して問題ないかを確認したりしなければならなかったからです。
修正したことで要らなくなったオブジェクトも出てきて、クラス図の見直しがかなり辛かったです。
ここは経験もある程度必要なんだろうと思って進めていきました。
デバッグ
なんだかんだここが一番めんどくさいと思いました。
GUIのデバッグもそうですし単体テストで取り除いたバグでも結合して見ると思わぬエラーが出てきて「なんでだ〜！」ってオフィスでつぶやいてたためヤバイ人認定されかけていたそうです。
基本的に単体テストをして問題ないメソッドはバグはなく結合時に期待どおりの入力をメソッドに与えていなかったため起きたものがほとんどでした。
GUIのデバッグは今流行りのRPAとかでやらせて楽したいと思いましたが、デバッグのためにRPAを作ると本末転倒なきがしてました。
GUI系のデバッグで楽する方法ってないんですかね。
レビューを受ける
バグを取り除いたアプリケーションを多くの人に見てもらいます。
イメージと違うから微調整してとか、機能の使い方がわからないから機能ごとにページを分けてくれとか言ってることが初めと変わっていて内心あなた方がこうしろって言ったでしょうに！って思ってました。
ここの段階で言われるのは見栄えの問題であってアプリのシステムについて口出されることは殆どありませんでした。
レビューでいい評価を受けたければ見栄えをとりあえず整えるといいですよ！
修正とレビューの繰り返し
言われたことには心を無にして作成すると楽ということに３回目のレビューで悟りました。
修正はいいんですが修正したあとのデバッグが大変でした。
GUI系のデバッグを(ry
完成
OKをもらってアプリケーションを公開しました。
作ってみて、営業の人に新しいアイディアが出たなど言われて嬉しい経験をさせていただきました。
あとはこれがなんの意味あるのとか言われますが、基本的にエンジニアの人に言われたのは辛かったです。
自分の会社だけですかね？
あとはアプリケーションが停止しないように公開期間の間はメンテナンスをしてあげるのが続きそうです。
最後に
開発をする際、いちばん大事な箇所はこれって決められないのですが、企画と設計は一番時間をさいて行うべきだ中って思いました。
企画のアイディアが変だと完成しても心無いこと言われますし、設計が間違っていると修正のコストが掛かってしいます。
また、近年ペーパーレス化が進んでいますが、じっくり読んで理解したいもの意見の書き出しは紙に書いていったほうが理解できますし、進行が早いです。お勧めします。
新卒でこんな事は普通しないとは思いますが、今後開発していく中で少しは役立てればと思います。