総合演習（２）

こんにちは、ヒゲです。

研修最後の課題である総合演習ですが、今日は設計書のレビューが行われました。

朝９時から始まって、ようやく先ほど終わったところです。
休憩時間を除いても実に８時間もの長時間レビューでした。

ちなみに「レビュー」というのは、設計書など成果物の妥当性について確認するための会議のこと。
○○歌劇団とか、そういうのではありません。
会社でラインダンス、という図もなかなか楽しそうではありますが・・・。

課題は、顧客のメールアドレスを管理するシステムの作成です。
顧客のメアドを登録・修正・削除・表示できるようにする、というもので、これまでに学習したＣ言語とデータベースの知識を組み合わせて実現します。

今日は普段クライアント先に常駐している先輩社員数名が戻ってきて、レビューア（チェック役のこと）を務めました。

傍から様子を伺っていると、レビューアの容赦ない指摘がビシビシ飛んでいたようです。

自分達が「これでよし！」と思っていた設計書の問題点を次々と指摘されてちょっとヘコんでいるのか、新人たちは若干肩を落し気味です。

でも、彼らは気付いてませんが、これは例年通りの光景です。

厳しい指摘をするのも、仕事としてシステムを作る・プログラムを書くということを決して安易には考えないで欲しい、という先輩社員からのメッセージなんですよね。

プログラムでなくてもいいのですが、大学までは「何かを作りなさい」という課題が出たときに、その作り方はかなり自由度が高かったのではないでしょうか。

モノさえ出来ればＯＫで、その作成プロセスまでは問われないことが多かったのではないかと思います。

一方、仕事としてのシステム開発では、各プロセスで顧客やその他関係者からの細かいチェックを受けます。

例えば設計書の内容についても、それなりに書けていればＯＫということはなく、

無駄のない設計になっているか？
不具合が起こりにくい設計になっているか？
メンテナンスがしやすい設計になっているか？
誰が見ても同じように解釈できる設計になっているか？

といったことが問われます。

今日のレビューでも、おそらくこれらの点に関しての指摘が多かったのではないかと思います。

それと、設計書作成の段階で質の高い設計書が書けていれば、その後の工程（プログラミング・試験）が楽になります。

逆の言い方をすれば、設計書の質が悪いと後に地獄が待っているわけです。

その意味では、設計書の段階で厳しく揉まれてブラッシュ・アップされた方がいいわけですね。

ということで、今日は意気消沈気味の新人たちですが、後日振り返ってみた時に、今日のレビューア達の厳しさの意味を理解するんだと思います。