- シンプルなゴールの意識(各フェーズでもこれらを定義。数値目標や具体的なアウトプットがあればよい)
- 仕様に関して文字や口頭だけで仕様のやりとりをすると認識の齟齬や問題点がでやすいため(人によって認識の差が出てしまう)、基本的にはデータとケース(あるいは図)によるコミニケーションを取るようにする。
- 優先度の定義(一般的には納期)
- 用語や言葉の定義が各人でゆれないように、統一しておくこと
- それぞれのフェーズで完璧に要件が絞りきれる、設計が完了することは少ないため、必ずバッファや対応策を考えておく。(今回では詳細設計以降に発覚した仕様が全体の３〜４割)
- ドキュメントの重複を極力避けるようにし、１つの情報を複数の箇所に書かないようにする(例えばAPI仕様書と詳細設計書で複数の情報が同じ箇所に書かれているなどがないように)。 コードとドキュメントを連動させることができるようにし、変更の未反映などが残りにくいようにする。(プロジェクトによっては理想論かも・・・マクロ使えればある程度実現は可能か・・)
- 自動化ツール(API仕様書からサンプルを出す、テーブル定義書からDDL作成、Excelからinsert文やupdate文を作る)を時間の余裕のある時に作っておく。コードと設計書の乖離を防ぐ手段。
- 変更を前提としたドキュメント作成や告知方法、運用フローをとるようにする。変更の検知をどのように行うか。定期の告知などが一般的。
- ルールを極力少なくして、漏れや作業側の疲弊をさせないようにする。
- 設計と製造の完全な分離は難しいと思う(ドキュメントだけで完全な意思疎通は難しいため。)
- パフォーマンスは後回しにされがちだが、考慮していないと外結自体がすすまないことが多いため、単体時にある程度のデータ量を考慮して進めておくことが大事。 (パフォーマンスを考慮して、データ量により、PG修正発生することが多い)
- 各フェーズごとの成功の定義(できれば数値化などで各人の認識がわかれないことが望ましい)
- 理想との差分をモニタリングできるように
- 手段を目的化させない(曖昧なまま技術選定をしない)
- 計画は守るものではなく、使うもの(フィードバックとモニタリングが目的)
- 要件はなにか？
- 具体よりもお客さんの本質の悩みにフォーカスする。本当にその機能は必要か？別のよりより改善策があるのではないか？
- その機能がない場合、どのような作業をしているのか？
- 困っていることは何かをフォーカスする？
- その機能が使われる時間、場所、使う人、ケース、頻度、解決した場合の理想的な状況は？(簡単な絵がかければベスト)
- やりたいことを文言だけでやると認識の齟齬が出やすいので、画面(簡単なモックがあればベスト)とケースごとのサンプルデータのやり取りをすること、データと図のコミュニケーションを取れるかが鍵だと思う。
- 業務に関して流れやフローが書けるか
- 特に現場担当者などの人に入ってもらい、「生きたデータ」を提供してもらえると良い(仕様的にOKでも、現実的にあり得ないデータだと状況が想定しにくい。)
- 要件の優先度を考えているか？
- 作るのが難しい(時間がかかる)機能の場合、代替案や他の優先順位などが考えられないか？
- 思いつきやなくてもいいものではないか？あれもこれもやりたいとなっていないか
- 大きなコストを払っても欲しい機能か？全て最優先はありえない・・
- コストなどは数値をともなった客観性のあるものか？
- 反対意見などがないか
- 本当にシステム化する必要があるか？人がやった方が楽な場合も・・・
- ある程度、要件定義段階の失敗例をこの段階で集めておく
- 画面設計、テーブル定義書とIFの作成がメイン。
- 要件定義に引き続き、データのコミュニケーションを中心に行う。
- IF設計など
- この段階での齟齬は後半のスコープへの影響が大きい。修正の影響が可能なようにしておく。
- 基底部分の作り込みはあらかじめおこなっておく
- 修正された場合、影響度の少ない作り込みにしておく(特に規定部分)
- 大まかな技術選定をこの段階で決めておく(メリデメの理解)
- また技術的に新規技術はこの段階で調べておく(ある程度実機での調査が必要。)
- 画面に関して
- 入力する情報をなるべく少なくする
- 目の導線にしたがって1つの情報のみが目に入るようにする(入力欄が画面中に散らばることがないように)
- 情報が多い場合、適宜分割する。やむを得ない場合項目のグルーピングを行う
- 制御フローが複雑すぎる作りになっていないか
- 要件定義、基本設計書に引き続きデータのコミュニケーションを中心に行う。
- 作るドキュメントはAPIのシーケンス図のみでOK(文だとわかりにくい・・、ログはこの中に入れてしまう)。
- 変更や修正があることを前提に設計する。(特に基底部分)
- ドキュメント間のルールやフォーマットのテンプレートなどを作っておき、人での作業差分を減らす。複数入力を避けるドキュメントにする。
- この時点でテストデータを作っておき、製造側の負担を減らせるようにする。(できればユーザーに近い人に意見をもらえるとベスト)
- 規約ツールを入れて人チェックを減らす
- 状態確認を迅速に行えるようにする(主にマイグレーションも含むデータ確認や設定ファイルのテンプレート化)
- 設定ファイルやIFの活用などでローカル用と開発環境、ステージング用を分けるようにしておく。実際に試験が始まってから環境切り替えの確認コストがバカにならない。
- 仕様がわかる人間によるテストデータ作成に重きをおく(プログラムを書くよりもデータを作るのと確認のほうが時間がかかるため)。
- 仕様変更があることを前提にプログラムを組む、体制の変更をとる。
- できればxUnitテストを入れて、Excelからデータを読み込めるようにしておく。(難しければ一部でもOK。あくまで作業軽減が主目的。)
- 単体テストまえに環境構築&正常系や稼働確認をしておく(環境構築コストを考慮に入れてないようなケースが結構あり、最初の疎通確認で時間がかかる・・ってケースが多々ある)。
- 認証ロジックや制限などはテスト用のものを考える(テスト時は認証処理を不要にする、ゆるくする、有効期間を長くするなど。)
- 項目整備に関してはテスト項目の作り方(縦項目について)、テスト仕様書の必要な項目の定義など(横項目の定義)を参照。
- できれば人でなく、機械的にできる手段も採用する。(特にバリデーションや単体モジュールのInOutの検査など組み合わせが非常に多いケースで有効。完全な自動化はケースによっては逆に効率が落ちるのでやめる)
- 異常系を発生させるコードやデータ投入SQLをあらかじめ用意しておく。(あるいは手順をしっかり書いて置く)
- できればサンプルではなく、開発段階で良いので外部とつながるようにしておくのが望ましい。(いきなりブロック項目があって進まない・・・ということが起こりがち。なかなか難しいかもですが・・・)
- 仕様的なデータ投入もそうだが、生きたデータ(実際のケースに近いデータ)のレビューができたほうが良い
- エビデンスがいる場合は作業効率化をいろいろと考えておく必要がある
- プレ的な環境での結合を用意しておく(いきなり外部結合で繋がらない、始められない・・というケースが現実的に多い)
できれば文字だけでなく、通話ツールで担当者間で連絡を取れるようにしておくのがベター - データ作成ツール(技術的な面でも、仕様的な面でも)を余裕のある段階で作って置くべき。欲しいデータをすぐに投入できるように。
- 外結が始まる前にできるだけ大量データのテストかつ生きたデータを作れるようにしておく。想定されているテストデータの量が全然違って、テスト初日に全く動かない・・・ということが起こりがち。
- 一覧系であればSQLやロジックを根本から変えることになるし、過去にはプルダウンの項目が万単位でフリーズなんてこともありました。また地図のSQLとか特別なものの場合も技術調査しておいたほうが良いかも・・・
- 外結の初期段階でブロック(そのせいで他の試験項目に移れない)を出さないことが大切。
- 仕様不備が発覚することも多々あるが、仕様変更対応期間をずらす、必須でなければ次フェーズに回すなどできればベター。
- 単体テスト〜内部結合に引き続き、できれば文字だけでなく、通話ツールで担当者間で連絡を取れるようにしておくのがベター(コミニケーションロスが大きい)
- 見たいログを見る技術をこの段階で調査しておくこと(特定しやすい情報が入っているか。大人数で繋ぐとログの発見だけでも困難になる。)
- サーバーダウンが結構あるため、回避策を要検討。
- できればベンダーごとに複数の環境があることが望ましい・・・テストする際初期化を行う必要があるため
- デプロイ時の手順を単純にし、できるだけこまめなデプロイが簡単にできるようにしておく。(CD系のツールがあればベスト)
- ロジックの大規模な変更は無理だが、エラーコードやログ文言など微調整したいものは変更を容易にしておく(できれば外部ファイル化しておくと融通がきく)
- テスト期間中、原因の特定などに時間がかかることが多いため、エラーメッセージを明確化して置くことはかなり大切。
- 一般的にはシナリオテスト(ユーザーの想定の使用ですすめる)、負荷テスト、セキュリティテストが一般的。
- この段階でPG見直しになることが結構ある。(パフォーマンス、負荷にからむもので見直しになることが多い。多い点としてはSQLをGroupByするもの。chunkメソッドでメモリ節約をするなど)
- 特にデータ量が想定と違うと最悪テーブル設計の見直しになることがあるため、最低限データの桁程度は押さえておく
- コードレビュー時にセキュリティテストを見込んだチェックをしておく(SQLインジェクション対策など)
- JMeter(大量アクセスを可能にするツール)などで負荷を加えたときにどのような事態になるかを確認しておく
- 「要件定義のヒアリングリスト４２７」
- 「「なぜ」で始める要件定義」
- 「図解 これ以上やさしく書けない プロジェクトマネジメントのトリセツ」