skillup

技術ブログ

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

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

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

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

全般

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

要件定義

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

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

基本設計

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

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

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

詳細設計

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

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

製造

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

単体テスト〜内部結合

項目整備に関してはテスト項目の作り方(縦項目について)テスト項目の作り方(縦項目について)を参照。

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

外部結合

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

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

執筆者:


comment

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

関連記事

no image

仕様の把握で見るポイント

新しい現場に入って技術的な部分はもとより仕様の把握などでポイントになる点などを。 Contents1 ER図2 ステータス変更3 プレイヤー(イベント)整理4 タイムテーブル5 マトリックス表6 ダミ …

no image

データベースのテスト環境作成

現在作っているシステムのリリースが近づいており、本番に近い環境を作成しお客様に見てもらうことに。 こういった手順はマニュアル化しておいたほうが楽だろうと思い、自分的にメモ 1 現状運用されているデータ …

no image

テスト仕様書の必要な項目の定義など(横項目の定義)

前回はテストの項目をどのように作るか(分類するか)だったんですが、今回はテスト仕様書などを作る際に必要な項目の定義をまとめてみようかと。 テスト仕様書を作るとしたら前回は縦(バリデーションの組み合わせ …

no image

ドキュメント作成(要件定義〜設計)のポイントについて

4月から新しいプロジェクトが始まり仕事がドキュメント作成(要件確認書、基本設計、詳細設計)などをしております。この仕事自体が自分にとってあまりなじみのないものだったので、そこで思ったことなどを。 Co …

no image

プログラムからとExcelからのテストデータ作成

テストデータの作成ですが、プログラムから作成するケースとExcelからシコシコ作ってSQLをがんと入れる場合があります。Excelつってもマクロを使ったりするんでプログラムですし、実際にはPHPとEx …