こんにちは！
ALH開発事業部のREIYAです。

今回は、開発エンジニアとして上流工程のプロジェクトにアサインされた場合、どのように仕事を進めるのかを工程ごとにポイントや注意点をまとめてみました。

マガジン追加などで困ったときに見返していただけると幸いです

■案件初期調査

開発業務にてクォーターごとに案件対応をしていくと思いますが、依頼のきた案件について、まずは開発側から調査を行います。

などを調査するかと思います。
その際の注意点や観点などを、私の経験で書き連ねます。

■観点と注意点一覧

■データモデルについて

1対1の場合

1つの入力に対して、1つのカラムが対応する
→1つにしか影響しないので安心感あるね

1対多の場合

1つの入力に対して、多数のカラムに影響がある状態
→既存のデータに対する影響範囲が大きい

神を変えれば、紐づく人間たち全員の思考が一気に変わる.

神
L人間(1)
L人間(2)
L人間(3)
...

多対1の場合

複数の入力に対して1つのレコードのみにしか影響しない状態
→入力元が多いため、影響範囲も広いし、テストすべきオペレーションの種類が増える

どの操作からも結局一つのテーブルや一つのレコードが更新される.

北の扉------
西の扉------
中央の扉----  根源テーブル
東の扉------
南の扉------

多対多の場合

複数の入力によって複数のレコードが変わる
→もっとも面倒なタイプ。状況に応じてしっかり考えましょう

テーブル.

ユーザテーブル1→サービステーブル1, サービステーブル2, ...に紐づく
サービステーブル1→ユーザテーブル1, ユーザテーブル2, ...に紐づく

■見積り

案件が受注可能かの判断などに必要なのが見積りですね。
この工程では「開発するにあたりどの程度の工数がかかるのか」を見積ります。
見積りは、開発側からユーザ側に提示する数字がある種の「正解」となってしまうので「10人月ほしい」なのか、「実際おそらく8人月」なのか、できるかぎり根拠を提示していきたいところです。

■あるはずもない根拠の作り方

詐欺師みたいなタイトルになったぜ。。

1. 過去実績から出したいがそんなものはない場合

過去実績がない新規システムなら、絶対あてにならないけど
・一般的に～
・ステップ数的に～
でやってもよいし、わたしがよくやるのは

です。

2. 過去実績から出せるのでちゃんと数式つかう

以下を基準に、単位あたりの工数を過去実績から計算しておけばよい。

■要件定義・調整

ここで下手な定義をしたり、何かを決め忘れたりすると
「すみません、ここやっぱ無理で。。」とか
「すみません、ここって何がいいですか。。？」とか
まぁそう。みんな大嫌いな手戻りになるわけです。

ということで、要件定義・調整をする際に抑えておきたい観点や注意点をまとめていきます

■調整時の注意点

調整時にやり取りした履歴はすべてドキュメントにしておかなくてはいけません。
スプレッドシート上でQA表にして運用するもよし、会議にて議事録を作成、メールなどで確認を取ったうえで要件書に使うもよしです。

また、開発→ユーザに質問する際には基本的に、選択肢を用意することが重要です。

仮にAAAAでない場合、どちらも選択肢がないのは変わらないが、AAAAっぽい何かが来やすくなります。
また「AAAAでいい？」と聞かれた場合に、もしユーザ側が何でもよければAAAAになるわけですから、回答までのスピードがこっちのが早く、デメリットがない、完全上位互換な質問なので使わない手はありません。

■要件書の観点・注意点

要件書作成時の注意点を以下にまとめました。

また、これらの情報をしっかり次の工程である、設計書に記載しきるところまで確認したい。

■影響範囲に漏れがあったら怖いので...

そもそも案件初期調査の時点で影響範囲の調査や、実現性などは確かめている前提のお話しです。
追加予定のテーブル名でソースGrepなど、当たり前の調査ができていることは前提としています。。

■設計

要件定義書を作成中または完成したのち、設計書を作りますね。

フォーマットなどはシステムごとに決まってしまっていると思いますが「これがあるといいよね」「最低限これがないとな」みたいなものは、フォーマットに合わなくてもチラって追記しちゃうべきです。

経験として「これがあると助かる！」といったものをまとめます。

■そもそも調査するときに設計書だけで完結したいのよ

このボタンおしたら値どうなるんだっけ　と調べたいときどうしますか？
最もダメだけどやりがちな方法が以下です。

一方、設計書が以下のようになっていると、上記の作業は全ていらなくなります。

また、そもそもこの辺が分かっていないと製造ができないはずなので
最初からこういった部分が分かりやすくまとまっているとよいですね。

■必要なもの一覧

■プラスα

以下は、フォーマットになくてもちょいメモとして記載しちゃおうよ！ってくらいなものです。
怒られなければ書いておいたほうがいいと、個人的に思うので是非書いてみてくださいね。

■試験仕様書

完全なウォーターフォールでない場合、だいたい

「要件と設計」を同時にやって
「製造と試験仕様書」を同時にやって

という感じなんじゃないでしょうか。

こういった状態を前提として、試験仕様書を書く際、注意しておきたいところをまとめてみました。
品質にダイレクトで関わりそうな部分なので注意深く作りたいですね。。

■試験観点をつくる観点

どんな観点があればいいのか、いまとなっては先人たちがとてもきれいにまとめてくれているのでまずは以下を参考にしてほしい。

テスト仕様書 | Qiita

観点としてだいたいこう。

■ではテンプレートは

まず試験仕様書の作成と、試験仕様書のレビューがあります。
次に、試験実施して試験仕様書に結果を報告、次に試験結果レビュー。

なので、試験仕様書レビュー欄と、試験結果レビュー欄、が欲しいところですが試験仕様書レビュー欄はさすがにいらないです。
間違ってた時点でなおしましょう。

加えて、追加改修/新規改修にかかわらず、「前回の試験仕様書に新観点を追加」し、カラム「試験実施対象かどうか」を用いることで
いつも同じ観点、粒度を保つことができます。

また、
画面の下のほうに新しい項目追加したので試験観点追加
とした場合
画面の上のほうがバグってないか確認をするときに
いままでの分の「試験実施対象」を「〇」にするだけで済む

必要カラムをまとめると…

とかになるのかと思います。

↓ ↓ ↓　採用サイトはこちら　↓ ↓ ↓

↓ ↓ ↓　ALHについてはこちら　↓ ↓ ↓

↓ ↓ ↓　もっとALHについて知りたい？　↓ ↓ ↓