見出し画像

【永久保存版】開発エンジニア上流工程指南書

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

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

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


■案件初期調査


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

・業務上どんな目的で実装するか
・システム的に実現可能か
・現行システム的に実現すべきか、沿っているか
・モデルの変更が必要そうか、ソリューションさえ変えれば実現可能か
・どの程度の規模になりそうか(別途見積りは行うが一応把握しておきたい)

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

■観点と注意点一覧


業務上の目的	大まかにでも把握しておきたい	システムによるので割愛 実現可能か	そもそもロジックが製造可能か	現状の情報だと実現できない業務ロジックとかね データモデル	テーブル追加なら画面とテーブルのデータ関係が1対1か1対多かなど	マスタ画面とマスタテーブル追加とか、めんどうなのは多対多のパターンかも。 規模感	いきなり1Q分で無理そうな規模なら注意だよ	システム基盤追加する系なら今Qにて基盤のみ、次Qにてロジック入れる、とか増員するとか 他シス影響	扱うデータが自システムのみで触るものならいいけど、他システムからの変更があり得るなら注意。他シスで実現可能かどうかも確認が必要。	自システムでのみ使う値だけがある画面に、他システムから参照される値があったりしたら影響確認しないといけないね IF	システム連携の改修ならIF修正有無が大切。ないならなしでいいけど外結はするよね	IFの形は変わらないが連携項目が追加になる、など 影響範囲と改修必要一覧	漏れなく調べること

■データモデルについて


1対1の場合

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

【例】
マスタテーブル「名前マスタ」があり
画面「名前マスタメンテナンス」があって
画面からの入力をテーブルに更新するだけ など

1対多の場合

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

【例】
1つのマスタ項目を、複数のレコードが見ている

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

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

多対1の場合

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

【例】
複数入力が1つのテーブルにつながっている

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

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

多対多の場合

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

【例】
双方向に参照先が多数ある状態

テーブル.

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


■見積り


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

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


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

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

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

機能ごとに、規模感でサイズをつけて、概算するって方法

です。

【例】
====まずサイズの定義========================
担当者の経験や自分自身の経験として判定。
要件定義~試験終了まで

わりと軽いぞ→Sサイズ→15人日程度とする
まぁ重たいな→Mサイズ→30人日程度とする
でかいぞこれ→Lサイズ→50人日程度とする
=========================================
10機能必要だとして...
Sサイズ:3機能→45人日
Mサイズ:5機能→150人日
Lサイズ:2機能→100人日
計:295人日 = 約15人月

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

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

要件定義でのの機能数	ユーザ目線のやつ	要件定義の工数 画面的/バッチ的な機能数	システム目線のやつ	要件定義/設計工数、製造工数 試験数	粒度違うと困るね。。	試験工数 問合せ対応の件数とか、会議とかの数	-	管理工数 成果物作成数	粒度がそろっていないことがほとんどなのであんま役に立たないが一応	全般

【例】
過去のもので
>要件として3機能、要件定義に5人日かかった
→5÷3で1.7
→1機能あたり、要件定義に1.7人日かかる。

1Qでは>要件として3機能、要件定義に5人日かかった
→1機能あたり、要件定義に1.7人日かかる。
2Qでは>要件として2機能、要件定義に4人日かかった
→1機能あたり、要件定義に2人日かかる。

→→1.7と2を平均して、1.9人日なので
→→★1機能あたり、要件定義に1.9人日かかる。

■要件定義・調整


要件定義とは…
開発案件について「どういった実装を行いますか」という
ユーザ↔開発間の、認識合わせ、お約束、取り決め、これって言ったよな、の言質をとるドキュメント...です。

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

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

■調整時の注意点


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

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

【例】
〇「文言はAAAAでよいでしょうか?」
×「文言は何にすればよいでしょうか?」

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

しかし
バリデーションや業務上の仕様で決まる値範囲などのように、さすがにこちらで選択肢を用意できない質問の場合は仕方ないので、この質問方法は避けるのがいいです。

■要件書の観点・注意点


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

業務での実装目的	基本的に絶対あるので、開発側も一応把握しておこう 鳥観図	改修が必要な部分に色がついているといい。改修なしだが試験はする部分は違う色とか。 他シス影響についてわかること	IF修正はないが試験はするなどでも記載しておこう 開発スケジュールについて記載	大まかでよいので書く。未定の場合は予定ですって書いとけ 業務要件が修正されるかどうか	ユーザ側で運用方法を変える必要があるなら書いておく。使うのはユーザだからね 画面表示項目のカラム名	必ずユーザから来た文字列をコピペ。手打ちして間違えたら失業すると思え 画面表示メッセージ文言	必ずユーザから来た文字列をコピペ。手打ちして間違えたら失業すると思え 画面追加項目値(編集可)の値範囲やバリデーション	編集可能な追加項目は絶対に必要。最初に確認 ロジック改修のフロー図とか	あったら見やすいしわかりやすい。まぁ時間ないなら設計の時でいい テーブルカラム追加	イメージ図とかcsvとかはっつけとけ。とりあえず提示する! 影響範囲がすべて記載されている	まず影響範囲の調査漏れがないことが前提 付随して改修する箇所を全部提示	あとから、勝手な仕様変更とか言われたら責任とれないのでね 要件書を見てすべての必要改修がわかること	別に改修予定の成果物名一覧とか書いちゃってもいいと思うぞ。要件書は神なんだ ユーザと調整したやり取りの記録	スプレや議事メモなどがあれば添付なりパスを記載しておきたい。

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

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


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

■設計


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

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

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

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


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

1.画面のボタンを見に行く
2.挙動だけ確認したいなら打鍵したりdevツールみたりで終わり
3.どのテーブル更新?とかを調べるため、ボタンの挙動のメソッドを確認する
4.使用メソッドの定義元に飛び、どのテーブル使うか、どのシステム連携するかを追ってメモ
5.網羅したとき、調査結果のドキュメントができあがる

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

1.画面設計書にボタン位置や項目定義、画面イメージがある
2.画面設計書の機能説明に、画面押下時の挙動の説明がある
3.画面設計書の機能説明に、登場テーブル(CRUDだとなおよい)と連携APIや向き先システムがある
4.画面設計書の機能説明に、登場テーブル(CRUDだとなおよい)と連携APIや向き先システムがある
5.そもそもそれが設計書です

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

■必要なもの一覧


<画面の場合>
・画面遷移図
・画面イメージ
・項目定義
・機能一覧
・機能説明-挙動
・機能説明-登場テーブル
・機能説明-登場テーブル-抽出条件
・機能説明-使用API-対向システム名とか
・機能説明-使用API-リクエストとレスポンス

<バッチの場合>
・フロー図
・各フローでの挙動(日本語でロジック)
・各フローでの登場テーブル
・各フローでの登場テーブル-抽出/参照条件

■プラスα


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

・業務上でどんな目的で使われる機能なのか
・いつ何の要件で実装されたか(設計書の更新履歴とは別でちょいちょい書いてあると何かと役立つ)
・実装上、今後まずいぞってたぐいの注意点(上限オーバーしたらエラーになるなどが対策されていない点)
 →JavaソースのアノテートコメントでいうXXXみたいな感じ

■試験仕様書


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

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

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

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

■試験観点をつくる観点


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

テスト仕様書 | Qiita

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

・入力値のパターン全部網羅
 バリデーションが値範囲なら、境界値highと境界値low、正常代表値、異常代表値、とかを確認。
 バリデーションが文字数なら、...など。

・件数の上限について確認する場合、100件が上限ならその前後とかも確認。

・性能的に商用にて1000件とかで運用されるなら、2000件はどうなのか、とか。

・タイムアウト系
 API中に他のAPIとかやる場合、内側でタイムアウトしても外側が包括しているか、など。

・期待値について
 かならず明確に。
 期待値が違う場合は、いくら似てても別ケースとして試験を作ったほうが良い。
 似てるからいいやで試験不足してバグになったらえらいことに

■ではテンプレートは


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

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

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

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

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

・項番
・試験区分
・機能区分1
・機能区分2(適宜変えよう)
・試験手順
・期待値や確認手順
・実施対象かどうか
・必要な証跡の種類
・確認結果
・確認者名
・確認日時
・バグチケット記載欄
・証跡レビュー結果
・証跡レビュワー名
・証跡レビュー日時
・備考欄

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



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


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


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




この記事が参加している募集

#企業のnote

with note pro

12,294件

みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!