skillup

技術ブログ

ドキュメント作成 プロジェクト管理

プロジェクトごとのフェーズでやっておいたほうが良いと思うこと

投稿日:2021年12月5日 更新日:

またプロジェクトの途中ではありますが、自分の中で要件定義〜外部結合の始まりまでのフェーズを経験して思ったことなど

全般

  • 文字や口頭だけで仕様のやりとりをすると認識の齟齬や問題点が出にくくなるため、基本的にはデータとケースによるコミニケーションを取るようにする。
  • それぞれのフェーズで完璧に要件が絞りきれる、設計が完了することは少ないため、必ずバッファや対応策を考えておく。(今回では詳細設計以降に発覚した仕様が全体の3〜4割)
  • ドキュメントの重複を極力避けるようにし、1つの情報を複数の箇所に書かないようにする(API仕様書と詳細設計書など)。
  • コードとドキュメントを連動させることができるようにし、変更の未反映などが残りにくいようにする。
  • 自動化ツール(API仕様書からサンプルを出す、テーブル定義書からDDL作成、Excelからinsert文やupdate文を作る)を時間の余裕のある時に作っておく。
  • 変更を前提としたドキュメント作成や告知方法、運用フローをとるようにする。
  • ルールを極力少なくして、漏れや作業側の疲弊をさせないようにする。
  • 設計と製造の完全な分離は難しいと思う(ドキュメントだけで完全な意思疎通は難しいため。)
  • パフォーマンスは後回しにされがちだが、考慮していないと外結自体がすすまないことが多いため、単体時にある程度のデータ量を考慮して進めておくことが大事(PG修正発生することが多い)

要件定義

やりたいことを文言だけでやると認識の齟齬が出やすいので、画面(簡単なモックがあればベスト)とケースごとのサンプルデータのやり取りをすること、いかにデータのコミュニケーションを取れるかが鍵だと思う。

テーブル定義書がなくともデータのコミニケーションは取れると思います。

基本設計

画面設計、テーブル定義書とIFの作成がメイン。

要件定義に引き続き、データのコミュニケーションを中心に行う。

また技術的に新規技術はこの段階で調べておく(ある程度実機での調査が必要。)

IFの細かいルールについてはAPI仕様書に関する注意事項を参考に。

詳細設計

要件定義、基本設計書に引き続きデータのコミュニケーションを中心に行う。

  • 作るドキュメントはAPIのシーケンス図のみでOK(文だとわかりにくい・・、ログはこの中に入れてしまう)。
  • 変更や修正があることを前提に設計する。
  • ドキュメント間のルールやフォーマットのテンプレートなどを作っておき、人での作業差分を減らす
  • 複数入力を避けるドキュメントにする。
  • この時点でテストデータを作っておき、製造側の負担を減らせるようにする。(できればユーザーに近い人に意見をもらえるとベスト)

製造

  • 規約ツールを入れて人チェックを減らす
  • 状態確認を迅速に行えるようにする(主にマイグレーションも含むデータ確認や設定ファイルのテンプレート化)
  • 設定ファイルやIFの活用などでローカル用と開発環境、ステージング用を分けるようにしておく。実際に試験が始まってから環境切り替えの確認コストがバカにならない。
  • 仕様がわかる人間によるテストデータ作成に重きをおく(プログラムを書くよりもデータを作るのと確認のほうが時間がかかるため)。
  • 仕様変更があることを前提にプログラムを組む、体制の変更をとる。
  • できればxUnitテストを入れて、Excelからデータを読み込めるようにしておく。
  • 単体テストまえに環境構築&正常系や稼働確認をしておく(最初の疎通確認で時間がかかる・・ってケースが多々ある)。
  • 認証ロジックや制限などはテスト用のものを考える(テスト時は認証処理を不要にする、ゆるくする、有効期間を長くするなど。)

単体テスト〜内部結合

項目整備に関してはテスト項目の作り方(縦項目について)テスト仕様書の必要な項目の定義など(横項目の定義)を参照。

  • 製造段階でデータを用意しておき、すぐにはじめられるようにしておく
  • できれば人でなく、機械的にできる手段も採用する。(特にバリデーションや単体モジュールのInOutの検査など組み合わせが非常に多いケースで有効。完全な自動化は逆に効率が落ちるのでやめる)
  • 異常系を発生させるコードやデータ投入SQLをあらかじめ用意しておく。(あるいは手順をしっかり書いて置く)
  • できればサンプルではなく、開発段階で良いので外部とつながるようにしておくのが望ましい。(いきなりブロック項目があって進まない・・・ということが起こりがち。なかなか難しいかもですが・・・)
  • 仕様的なデータ投入もそうだが、生きたデータ(実際のケースに近いデータ)のレビューができたほうが良い
  • プレ的な環境での結合を用意しておく(いきなり外部結合で繋がらない、始められない・・というケースが現実的に多い)
  • できれば文字だけでなく、通話ツールで担当者間で連絡を取れるようにしておくのがベター
  • データ作成ツール(技術的な面でも、仕様的な面でも)を余裕のある段階で作って置くべき
  • 外結が始まる前にできるだけ大量データのテストかつ生きたデータを作れるようにしておく。想定されているテストデータの量が全然違って、テスト初日に全く動かない・・・ということが起こりがち。
    一覧系であればSQLやロジックを根本から変えることになるし、過去にはプルダウンの項目が万単位でフリーズなんてこともありました。また地図のSQLとか特別なものの場合も技術調査しておいたほうが良いかも・・・
  • 外結の初期段階でブロック(そのせいで他の試験項目に移れない)を出さないことが大切。

外部結合

  • 仕様不備が発覚することも多々あるが、仕様変更対応期間をずらす、必須でなければ次フェーズに回すなどできればベター。
  • 単体テスト〜内部結合に引き続き、できれば文字だけでなく、通話ツールで担当者間で連絡を取れるようにしておくのがベター(コミニケーションロスが大きい)
  • 見たいログを見る技術をこの段階で調査しておくこと(大人数で繋ぐとログの発見だけでも困難になる。)
  • サーバーダウンが結構あるため、回避策を要検討。
  • デプロイ時の手順を単純にし、できるだけこまめなデプロイが簡単にできるようにしておく。(CD系のツールがあればベスト)
  • ロジックの大規模な変更は無理だが、エラーコードやログ文言など微調整したいものは変更を用意にしておく(できれば外部ファイル化しておくと融通がきく)
    テスト期間中、原因の特定などに時間がかかることが多いため、エラーメッセージを明確化して置くことはかなり大切。

総合試験

  • 一般的にはシナリオテスト(ユーザーの想定の使用ですすめる)、負荷テスト、セキュリティテストが一般的
  • この段階でPG見直しになることが結構ある。(ループ系が見直しになることが多い)
  • 特にデータ量が想定と違うと最悪テーブル設計の見直しになることがあるため、最低限データの桁程度は押さえておく
  • コードレビュー時にセキュリティテストを見込んだチェックをしておく(SQLインジェクション対策など)
  • JMeterなどで負荷を加えたときにどのような事態になるかを確認しておく

-ドキュメント作成, プロジェクト管理
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

外結〜運用フェーズでの気をつけることなど

外結以降のフェーズで注意することなど。(主に障害発生時の原因切り分け) Contents1 エラーの情報伝達に関して2 ログの見方3 デプロイ4 タスクコミュニケーション(タスク管理ツール)5 チャッ …

no image

APIに関して

RESTAPIのルーティングで気をつけることなんぞを。 直近のプロジェクトではRESTAPIを作ることが多かったんですが気をつけることなんぞを。 Contents1 仕様書はソースから2 ツール3 命 …

no image

単体テスト仕様書について

おそらく開発者が書きたくないものの筆頭になるかと思う単体テスト仕様書ですが、うまく使うと有益なコミニケーションツールになります。 Contents1 ユーザーのフロー体験・説明書2 前提となるデータ3 …

no image

CI/CDに関する取り組み

CI/CDに関して知識としては5年以上昔から持ってましたが、実際にプロジェクトの中に取り組むことができるようになったのはつい最近なので、 取り込みが現実的なものに関してどのように取り組んでいくかといっ …

no image

テスト項目の作り方(縦項目について)

テスト項目の作り方について。 単体テスト書のレビューをしていて、なるべく効率的に網羅的にできるテスト仕様書の作成について。 納品物としてではなく、開発の高速化と品質をあげるためのテスト仕様書を。 Co …

アーカイブ