こんばんは、堀井です。
突然ですがこのブログのコンセプトって「仕事をしつつ趣味を全力で楽しめるか？」でやっています。4ヶ月近くお仕事を続けられてはいますし、その傍らであれやこれやと趣味も楽しめているので今のところ問題はなさそうです。
ただ肝心のお仕事内容をあまりお喋りしていなかったので今日はそんなお仕事の話です。
前回の記事はこちら
久しぶりにお仕事の話 - アラサーからのプログラマー生活
40日間も経っていたんですね。
ここから何か学べたのでしょうか。
ちなみに私の所属している案件はウォーターフォール型開発なのですが、その流れはこの通り。
- 要求定義
- 仕様書作成
- 内部設計
- 開発
- テスト
- 運用
今回は「電卓プログラムを作る」と言う前提を基として説明していきます。
要求定義
「ボタンを押したら自動で計算してくれるプログラムが欲しい」
要件定義と言ったりもします。
お客さんが何をしたいかってことですね。
ここでもし互いの認識がズレると手戻りが発生します。
上司から受けた指示と自分の認識が違っているとすっげえ叱られるのと同じですね。
曖昧な指示出して怒るのはやめてくれ。
仕様書作成
今の所こことテストに一番時間をかけるイメージがあります。
「四則演算のボタンと=ボタン、あとMR, M+, M-が必要」
「四則演算のボタンを押したら右上に今までの計算を表示する」
お客さんからの要望を基にして、どんな仕様にするか文章化します。
内部設計
「任意の数字を押して+ボタンを押したら、変数firstに任意の数字が代入される」
「その後-ボタンを押したら、加算を減算に変える処理を行う」
などなど細かいところを行います。
と書いていると、意外と電卓って色々細かい処理が行われて面白いですね。
「初心者はまず電卓を作れ」と言われる意味がわかったような気がします。
いずれSwiftかJavaかで作ってみたいな。
演算子の上書きはString型の変数operatorとか作ってボタンを押すたびに書き換えればいいのかな？
うーん、考え始めると楽しいかも。
開発
未経験者が想像しがちな場所。
仕様書に沿って書くこの仕事は全体の1〜2割しかない･･･。
「Aさんには演算部分、BさんにはUIを担当してもらおう」となった場合、AさんBさんが共通の認識を持っていないといくら素晴らしいコーディングをしたところで無駄になってしまいますもんね。
一人で開発する分にはどうでもいいんですけれど、複数人だとここが問題。
ここがしっかりしていないせいでポシャった同人ゲームは数知れず、だと思う。
バージョン管理ツールとかも共通で、それぞれの技術も同レベルじゃないといいプログラムは書けそうにない（他の人が書いたコードが読めない状態が発生するため）と考えると複数人でゲームを作っている人、本当にすげえ。
テスト
「足し算処理を行ったら本当に加算されるか？」
「一番最初に演算子を入力した場合何が起こるか？」
「いきなりMRを押した場合、エラーは起きないか？*1」
などなど項目は色々あります。
それぞれ問題ない旨を調べないといけません。
ここも時間がかかります。
特に組み込みだとリコールで全回収とか言う羽目になるため、時間をかけて精査しないといけない部分。
リリース
ようやく市場で回ります。
iPhoneアプリならAppStoreにあげられると言う感じ。
ここでユーザーがエラーを見つけた場合、開発側にエラーログを送るように設定していたらバッチを当てたりしてバグを解消しやすくなりそうですね。
多分やっているんじゃないでしょうか・・・？
今の業務では上記の開発とテストに携わっています。
1関数追加するだけの仕様でも、他の関数に影響を及ぼさないかの調査が膨大になっています。
実際のコーディングは正味1時間もかかっていないのですが、調査はもう何週間と続いています･･･（納期がゆっくりと言うことと、自分の非力さが非常に強く影響をしていますが、ベテランなら多分1週間もあれば終わります）。
こう言うことが起こると言うことは予想していたのですが、開発がほとんどだと思いながら業界に入った人は辞める原因になりそうですね。
事前に勉強しようにも専門的な用語が多すぎて調べ方もわからないと言う現象が起きるし･･･。
そんな業界内部のあれこれが詳しく書いてあるような本ってないのでしょうか？あったら一度読んでみたいです。
今後も業界を目指す人へ現実を突きつける？記事を書いていきたい。
それではまた次回。
*1:staticでなく、且つ0で初期化するなどがないとnullかエラーを返すはず。もしエラー処理も書かれていなかった場合、悲惨なことになる。
