Design Reviews . .Iterate, Iterate, Iterate!

By Russ Finney

設計レビュー；繰り返し、繰り返し、繰り返し！

Once the business design has started to gel into a complete vision of the either the new or enhanced system, several stages of review should have been conducted. Hopefully, the business clients have had the opportunity to participate and provide input throughout the screen and report prototyping sessions (which are in essence a review and enhancement exercise). In addition, each team member probably will have been through several reviews and revisions of his or her individual design assignments.
一旦、業務設計が新/改良システムの全体像に固まり始めたら、何回かに分けてレビューを行なわなければならない。出来るだけエンドユーザーを画面や報告書のプロトタイピングセッションに参加させ、意見を述べる機会が与えられる必要がある(これが評価と機能強化に当たっての重要なポイントである)。加えて、個々のチームメンバーは、自分の担当部分についてレビューと変更を何度か行なう事になる。

Throughout this effort, each of the analysts should be striving toward the design of a system which ultimately blends into a cohesive whole. Checks should be conducted frequently to access the level of consistency, commonalty, and standardization the team is achieving. Some suggested review points (within the total review cycle) which can assist in increasing the quality of the business design are listed below:
この間、各アナリストは、システムの設計が最終的にひとつの完成品に結合されて行く様、働きかける必要がある。チームが目指している一貫性、共有性、標準化のレベルの評価を適宜実施しなければならない。業務設計の品質を高めるのに有効な (全体のレビューサイクルにおける)レビューのポイントが提案されているので、以下に示す。

Initial Design Team Reviews
設計チームによる一次レビュー

These give the functional design teams a chance to review their own first cuts of the screen/form and report layouts. The initial screen/form and report layouts should be individually produced from the business requirements with only a minimal amount of direction. These initial reviews give the various team members a chance to see each other's ideas and to discuss common standards and approaches. In addition, any glaring database omissions can be identified for resolution, and any existing data element changes can be requested.
これは、機能設計チームにとって、自分達の画面／帳票・報告書レイアウトの一次案を見直す機会となる。最初の画面／帳票・報告書レイアウトは、殆ど条件を付けずに業務要件から別々に作成されたものである。この様な初期のレビューでチームのメンバーは、互いの考えを知り、共通の規準と手法について議論していく。さらに、大きなデータベースの欠落が発見・追加されたり、既存のデータ項目の変更が求められる事もあるだろう。

Design Team Revision Meetings
設計チームによる修正会議

During these meetings, the teams should conduct follow-up reviews of the revised screen and report layouts. Each layout should be compared to the project's common functionality and consistency standards, and any final changes should be identified. These meetings should be conducted as often as necessary, until the team feels it has produced a high enough quality product to use as a baseline in the prototyping sessions. The meetings should again provide a forum for the discussion of enhancements to the evolving database design.
この種の会議を行なっている間、チームは、修正された画面と報告書のレイアウトについてフォローアップ・レビューを行なわなければならない。全てのレイアウトは、プロジェクトに共通の機能と一貫性の基準に照らし合わされ、最終変更点が明記されておく必要がある。プロトタイピングセッションで十分使える品質に成ったとチームが思える迄、この会議は、必要に応じて何度も開かれなければならない。会議はまた、進行中のデータベース設計を強化する話し合いの場ともなる。

Prototyping Sessions
プロトタイピングセッション

These give the business clients the opportunity to review the baseline screen prototypes in a structured, focused setting. Additional business requirements, information omissions, new screen functionality, and operational enhancements can all be identified and put into both the system design as well as the evolving prototypes.
ここでエンドユーザーは、きちんと整備され、目的に応じた環境で、基本的な画面のプロトタイプを評価する機会が与えられる。追加の業務要件、情報の欠落、画面の新機能、操作性の改善等全てが確認され、システム設計と改良中のプロトタイプの両方に盛り込まれる事になる。

Cross Team Reviews
チーム間レビュー

If multiple teams are working on individual sub-systems which must either work from a common database or pass information back and forth, it becomes critical that review and issue resolution meetings are scheduled on either a regular or on an as-needed basis. The existence of this open communication can't be stressed enough! If invalid assumptions about any of the other system's data requirements, functionality, or timing are not uncovered until the last minute, all of the teams share equal risk of unpleasant surprises surfacing, potentially impacting the relevance of their current design work.
複数のチームが、共通のデータベースを使っていたり情報を相互に遣り取りするサブシステムを担当している場合、レビューや懸案解決の会議を開く事は、定期的か適宜かは別にして、非常に重要である。このオープンなコミュニケーションの必要性に付いて強調し過ぎる事は決してない！もし、ほかのシステムのデータ要件、機能、タイミングなどについての誤解が最後の最後まで明らかにならなかったら、困った不測の事態が起き、作業中の設計の妥当性を脅かす危険に、チームの全員が等しくさらされるのである;

Final Walk-Thrus and Approvals
最終ウォークスルーと承認

When a final draft of the completed Business Design is ready, one last review with everyone (business clients as well as the design team members) is in order. This may be accomplished by making one last pass through the screens and reports, or by just determining resolutions for all of the outstanding issues and reviewing the final decisions on all of the others. Whatever method is chosen, it is important to conduct some type of activity to get everyone paging through the these final results in order to stimulate feedback and closure.
完成した業務設計の最終草稿が出来ると、全員が(エンドユーザーもデザインチームのメンバーも一緒に)参加する最後レビューが待っている。これは、最後にもう一回だけ画面や報告書を見てみたり、ただ単に、未処理の懸案事項全ての対策やその他の案件の決着を確認する事で済まされるかもしれない。何れにせよ重要なのは、フィードバックを促し早く決着をつける為、全員が最終結果に目を通す様に実施する事である。

The key point to remember about this process is that it is iterative and ongoing. Different parts of the system, or even just different screens and reports may be at different points in the review cycle at any one time. This is fine as long as the overall design process is headed toward that all-important common, unified, cohesive whole!
この作業が繰り返しの積み重ねである事を、頭に入れておいた方が良い。何時の時点をとっても、システムのいろいろな部分もしくは画面や報告書が、レビューサイクルの異なる段階にある。全体の設計作業が、共通性、統合性、結合性の全てを満たす完成品に向かっている限り、これは問題ない!

The Issues get Intense
懸案事項の重要性

During the requirements gathering stage, the issues tended to be high level, and simply writing them down on a list for resolution was adequate. At this stage, however, an even greater level of discipline is required. Ths issues collected during the prototyping sessions, team review meetings, and walk-thrus must be categorized, recorded, and tracked. In many cases, these issues represent genuine requirements which can't be lost on a scrap of paper buried in someone's briefcase. Now is the time to formalize these issues into an easily maintainable database to which the whole team has access.
要件収集段階では、懸案事項は高次のものが多く、単にチェックリストに書き留めるだけで良かった。しかし、ここでは、さらに多くの作業を必要だ。プロトタイピングセッション、チームレビュー会議、ウォークスルーの間に集められた懸案事項は、分類、記録、追跡されなければならない。これらが真の要件になるケースが多いので、紙の切れ端にメモされ、誰かのブリーフケースの中に埋もれたまま紛失する事は、許されない。この時こそ、これらの懸案事項を格納した管理の容易なデータベースを作り、チームの全員がアクセス出来る様にする良い機会である。

Listed below are some of the items which should be recorded for each individual issue:
以下は、個々の懸案事項に必要な記録項目である。: