ユーザーから要件をを引き出す時は、自分なりに仮説を立てて考えた仕様をユーザーに提案し、それについて検討してもらう方が効率的である。

いきなり大規模なシステムを大勢で構築するのは品質面で不安を覚える。最初は少数の優秀な技術者達が中心となってシステムの構想を練り、その中で中核となる機能を実現する。その成果物は、以降に作られる成果物の標準となる。中心となる技術者達が他の技術…

現場に使ってもらえるシステムを作りたければ、何度も現場に足を運び、業務を知る事が大切である。現場の人達と仲良くなり、親身に教えてもらえるような人間関係も構築すべきである。その為にも、技術だけでなく、人格も磨く事を大事である。

業務を理解するには、一度自分で要件定義や基本設計してみると良い。

テストの重要性をメンバーに理解させる事が出来る。 上流工程での不具合が早期発見出来る。 テスト仕様書をプログラミングの参考資料に使える。 テスト工程が省略され難くなる。 テストの準備が早めに出来る。

要件が確定するまで開発に着手してはならない。納期は要件が確定してから調整する。ユーザーに会う度にその話をし、急かされても動じてはならない。

計画書や設計書等の内容を有識者によって見直し、品質を高める。 同じ場所に集まり、資料の内容を見直す事によって、知識の共有を図る事が出来る。 レビューの日程を予め決めておく事により、作業の進捗をコントロールする事が出来る。

テーブル毎にデータのライフサイクル（半永久・年単位・半年・月単位・週単位・日単位・一時等）を決定する。 テーブル毎に更新特性（検索・挿入・更新・削除）や１日の更新量を決定する。 テーブル毎に、現在のデータ量、データのライフサイクル、更新特性…

人命に関わる。 法律に関わる。 社会的な信用に影響を与える。 損害賠償訴訟に発展する。 他のシステムに影響を与える。 復旧する為に多くの時間と人を必要とする。 復旧に手間がかかる。 速度が要求される。 データや画面、帳票を外部に提出する。 データや…

ユーザーと共に確定した出力帳票や出力画面を筆頭に、入力画面、他システムとのインターフェースファイル等からデータを洗い出し、データ一覧表を作成する。データ一覧表は、データID、データ名、ドメイン（データの分類属性）、データの説明等からなる。 関…

完璧な品質を求めるのは現実的でない。ユーザと合意を取りながら、品質特性毎に優先順位付けを行わなければならない。

機能性 信頼性 使用性 効率性 保守性 移植性

属性チェック 桁数チェック 範囲チェック 論理チェック 順序チェック 合計チェック

コード化対象を洗い出す。 コード化対象の特性やデータ量を基にコード構成やサイズを検討する。 データ量の増加や状況の変化に対し、拡張性の側面から見直す。 コード一覧を作成する。 コードの管理方法について検討する。

ユーザー内で要求内容が固まっていない。 ユーザー間で意見が対立している。 ワンマンなユーザーが、他のユーザーの意見を聞かずに、一人で決めてしまう。 仕様が固まった後も強引に仕様追加や仕様変更を言って来る。 業者は叩けば良いと思っている。 責任を…

環境構築の工数を見積もり、日程計画を立てておく。 システム構成（ハードウェア・ソフトウェア・ネットワーク）は、コストが許す限り、本番環境に合わせる。 アカウントは、担当者の役割に応じて各種リソースの利用権限を考慮しながら、設定する。 アカウン…

以下の作業においてチェックリストがあれば、作業漏れを減らす事が出来るので、予め用意しておくと良い。 見積項目 取引手続き 要件定義 作業工程と成果物 設計項目 レビュー項目 環境設定 テスト項目 移行作業 導入作業

レビュー参加者の選定は適切か。 仕様書の構成は過不足無いか。 用語は適切に使われているか。 用語は統一されているか。 ユーザー要件を満たしているか。 画面・帳票・ファイル・テーブルは過不足無く揃っているか。 例外処理は十分考慮されているか。 セキ…

ユーザーに新しいシステムを理解してもらうには、そのシステムによって業務がどのように変わるのか、業務フローを新旧比較すると良い。後でそんなはずではなかったというような事態を避けるためにも、素人にも理解できるような工夫をすべきである。

移行 運用 性能

品質の確保 生産効率の向上 個人依存度の低減 保守性の向上 計画的なプロジェクト運営 成果物の個人差抑制 生産コストの低減 技術力の補完 フレキシブルな開発体制

目的・目標 対象・範囲 前提条件 環境（ハードウェア・ソフトウェア・ネットワーク・） 期間・スケジュール 方法・手順 テストの種類（機能・性能・障害・セキュリティー） 体制・役割分担 会議体 障害記録・障害報告 完了条件

項番 テスト項目（対象機能） テスト条件 期待される結果 テスト結果 テスト実施日時 テスト実施者

テスト仕様書を作成する時に下記の項目をチェックしておく。 ０件テストは行ったか。 エラー時は適切な処理（中断、スキップ等）を行っているか。 処理件数等、ログは出力されるようになっているか。 無駄なログは出力されていないか。 ジョブの処理順序は正…

テスト仕様書を作成する時に下記の項目をチェックしておく。 固定表示項目の位置は正しいか。 固定表示項目の文言は正しく表示されているか。 出力項目の位置は正しいか。 出力項目の値は正しく表示されているか。 出力項目の値の並び順は正しいか。 改ペー…

テスト仕様書を作成する時に下記の項目をチェックしておく。 初期化は正しく行われているか。 固定表示項目の位置は正しいか。 固定表示項目の文言は正しく表示されているか。 入力項目の位置は正しいか。 入力項目のチェックは正しく行われるか。 出力項目…

生産性の高い技術者を採用する。 標準化を進める。 部品化を進める。 使い慣れた開発ツールを採用する。 労働時間をコントロールし、要員の疲労を防止する。 設計ミスを防止し、開発段階での手戻りを無くす。

サーバーやアプリケーションのリプレースは、複雑になってしまったシステム全体を把握し、整理する、またとないチャンスである。

ユーザーの業務を理解している。 ユーザーの要求を引き出せる。 業務の改善提案ができる。 素人にも分かるように説明することができる。 自信を持って仕事をしている。 適切な判断ができる。 ユーザーの立場で考えることができる。

いくら品質を良くする努力をしても、100%トラブルを防ぐことはできない。トラブルが発生したときに備えて準備しておくことが必要である。最悪の事態を想定して、被害を最小限に留めるための方策を考えておく。トラブルのケースやその予防策、事後対策は可能…