skillup

技術ブログ

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

設計業務での改善点など

投稿日:2021年7月4日 更新日:

比較的大規模なプロジェクトの設計段階で思ったことなど。

明確なゴールを決める

会議や打ち合わせのたびにポツポツと問題点が出てきてしまい、設計などがひっくり返る、なかなか決まらないことが多い場合、ユースケースから満たすべきテストケースを割り出し、そのテストケースを満たすことをゴールと考えると良いのではないかと思います。理想論かもしれないが・・・・

プログラムを造らない段階でもデータイメージは想定することが可能なため、テストケースの想定は可能なはず・・。

理想論を追求しすぎるといつまでたっても決まらないことが多いため、ある程度現実的な案を考えましょう。

どうしたら「ゴールになるのか」という点を明確に設けるように。

レビュー時はチェックリストを設ける

レビューのたびにポツポツと問題点が出てくる場合、仕様、ドキュメントの体裁的なことに関して、チェックポイントを決めておくと内容に差異がなくなると思います。

チーム内での情報の情報共有方法を考える

チーム内での仕様の認識に齟齬が出るのは仕方ないかもしれませんが、各人でレビューをしあう、説明をし合うなどして、一人の人間が仕様を握っているということがないようにしておくと良いと思います。

データのテストパターンが一番現実的だと思います。

出来るだけ情報の同期ができる便利なツールを使う

1つの資料の情報の変更が、別の資料にも影響されるような資料を作るのが良いでしょう。

Excelであればなるべく関数やマクロを使い、手作業での修正量を押さえることが必要。(1つの修正で何箇所も修正が発生するような事態をなるべく避ける)

開発時と連携できるような資料がベスト(コードからドキュメントが開発できるなど)

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

執筆者:


comment

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

関連記事

no image

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

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

no image

バッチスクリプトで気をつけたい点

実務でバッチ処理を作る際に気をつけるべきと思ったこと。 基本的にエラーをいかに捉えていかにログに吐くかを最初に考える。まずはエラーありき。失敗するもの、想定した値がこない、あるいは値がないを前提として …

no image

使える設計書作成に関して

私自身、この仕事を7〜8年やっておりますが、設計書作成については常に悩まされておりました。 設計書のメリット・デメリットとしては以下のようなものですかね。 メリット メンバー間での仕様の認識を統一でき …

no image

EntityとValue Objectについて

ドメイン駆動設計に関して勉強しています。参考にしている本がやたら難しいんで、トピックごとにネットで調べつつ進めていくのがよさげです。 今回はEntityとValueObjectについて Content …

no image

ファジープロジェクト対策 その1

5月ぐらいから着手していたプロジェクト(顧客管理ソフト)が終焉を迎え、検証段階に入ったので、記して置きたいことなど。 数ヶ月程度ですが、自分が携わったプロジェクトの中では過去最大クラスのものでした。 …

アーカイブ