論文治療クリニック（外来）

またまた、患者がこられました。論文治療クリニックも忙しくなってきましたよ。

エーロン先生。はじめまして。
えび天★と申します。
私は、今秋のAEを目指して勉強しています。

AEの受験は、今回が初めてです。取りあえず準備論文を書くとよいと
聞き、夏休みを利用して１作作成してみました。初めて書いたのですが、
論文自体、大学の卒業論文以外書いたことがなく、頑張ったのですが、
トータル４日ほど費やしました。
ただ書いては見たものの、評価してくれる人がいません。文章を人に
見せるのは恥ずかしいのですが、なんとか合格したいので、添削をよ
ろしくお願いします。

ちなみに、私のプロフィールです。

年齢：30
職種：制御系SE(SE歴１年未満)
関連資格：ソフトウェア開発技術者、ネットワークスペシャリスト

業務のほうは、つい最近までプログラマをしてました。その為、
SEとしての経験は殆どありません。昇格と同時に設計にも携わるように
なり、その知識を身に付けたくて受験します。また、制御系仕事を
してるので、DB、アプリケーション関連の経験は殆どありません
(プログラマ時代を含めて)。そのため、論文を書けそうな問題を
選んでひとまず書いてみました。

いきなりのお願いですが、よろしくお願いします

はいはい論文治療では患者を選びませんよ。さっそく見せにきてください。

エーロン先生、こんばんは。
えび天★です。いきなりの論文添削のお願いを承諾していただき、ありがとうございます。

早速ですが、論文を送ります。添削のほど、よろしくお願いします。

問題は、Ｈ１０−問２ 「プロトタイピングの活用について」です。

こんどはH10「プロトタイピングの活用について」ですか。昨年の「読む講義」では、具体的な処方をしていたんですが、今はどっかにいってます。これもAEには重要ですね。では、問題見てみましょう。

問２　プロトタイピングの活用について

　プロトタイピング活用の目的は、プロトタイプを作成して開発すべきシステムの機能を早期に実証することによって、ユーザニーズに合致したシステムをより効率的に開発することである。
　プロトタイピングにおいては、開発者による検証のためにプロトタイプを作成する場合や、開発者とともにエンドユーザが機能を評価する目的でプロトタイプを試用する場合がある。

さらにプロトタイプは、評価・検証後に使い捨てにされる場合や、そのまま最終システムの骨格として使われる場合などがある。
　
プロトタイピングを活用することによって、一般的に次のような効果が期待できる。


　　　　　・エンドユーザの潜在的なニーズを掘り起こし、より効果的な機能をもつ情報システムが構築できる。
　　　　　・システム開発の初期工程でユーザニーズの確認がより正確にできるので、後工程でシステム設計の仕様変更が減少する。
　　　　　・システムの機能、性能、操作性などが事前に検証でき、開発リスク低減に役立つ。

反面、従来のアプローチよりも余分な費用・期間を要する場合もあるので、活用に際しては、目的、検証課題を明確にし、最適な方法で実施することが重要である。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

では、論文見せてください。

Ｈ１０−問２ 「プロトタイピングの活用について」
−−−−５−−−−10−−−−15−−−−20−−−−25
●火力プラント保守システム

１−１　システム概要

　火力プラントにおいて、各部品の損傷は事故を招く。
この為、これを未然に防ぐ為には、各部品の寿命前に交
換を行う必要がある。プラントにおいて、その部品は多
数あり、その寿命は異なる。これらの部品の交換（保守
）日時と部品毎寿命とその場所を管理するのが本システ
ムである。
　本システムはＣ／Ｓ型であり、保守履歴を集中管理す
るサーバと、プラント各所に配置され、任意の場所の保
守履歴をサーバより引き出し表示するクライアントで構
成される。尚、クライアント側アプリケーションは、グ
ラフィカルにプラントを図示し、部品毎に保守緊急度に
応じて色分けして表示する機能を持つ。主なユーザは、
現場保守担当者であり、定期的にデータを参照し、保守
計画、部品調達計画を立てる。
　私は、本システム構築に際し、設計のリーダとして参
画し、基本設計を担当した。

１−２　プロトタイプについて

　プロトタイプは、システムのターンアラウンドタイム
を計測するためのものである。処理は、大量の保守履歴
データに対し、検索を行い、結果を画面にグラフィカル
に表示するものである。このプロトタイプは更に、サー
バ側データベースとグラフィック描画ルーチンに分けら
れ、それぞれについて、ユーザ要求のレスポンスタイム
をクリアする為、各処理の時間短縮をする必要があった
。
　プロトタイプは、チューンナップ及び改良を度々行う
為、データベース部分を除き、成長型プロトタイプには
耐えないと判断し、基本的には使い捨て型プロトタイプ
とすることに決定した。

２　ターンアラウンドタイム計測用プロトタイプ

２−１　プロトタイプの目的

　Ｃ／Ｓ方式により、そのレスポンスタイムが焦点とな
る。この為、プロトタイプを作成しシステムの性能を、
事前に評価する必要があった。
　本プロトタイプは、開発者向けの性能評価に使用する
目的であったが、ユーザより同時にユーザインターフェ
ースの確認も行いたいとの要望があった。しかし、目的
が異なる為、別のプロトタイプとして作成することとし
、本プロトタイプでは、性能評価に目的をを絞って検証
することにした。
　ユーザよりデータ検索・表示時は、グラフィック描画
中の更新画面をユーザに見せないよう、要求があった。
その為、データ取得〜グラフィック描画を完了した後、
一気に画面を切り替える必要があった。この為、システ
ム性能をレスポンスタイムではなく、ターンアラウンド
タイムで評価することにした。ターンアラウンドタイム
の内訳は、データ取得時間、グラフィック描画時間の２
点である。この時間についてはユーザより５秒との要求
があった為、この時間をクリアする様、データベース設
計及びグラフィック描画をチューンナップする方法を取
った。
　検証方法は、プロトタイプに時間計測用のコードを埋
め込み、時間を計測することでシステム性能を検証する
ことにした。また、要求開始時、データ取得時、描画完
了時の３箇所に埋め込み、データ取得時間、グラフィッ
ク描画時間を別々に計測できるようにし、ボトルネック
となっている処理の判別を容易にした。
　尚、回線については、システム内で閉じており、また
十分な帯域を確保している為、トラフィックについて特
に考慮する必要はなかった。

２−２　効果があった点

　テストデータとして、画面平均描画部品点数として５
００点分のデータを用意した。このデータを用いてプロ
トタイプを稼動させ、データベースの非正規化とグラフ
ィック描画をＯＳのシステムコールを用いない独自ルー
チンに改良した結果、目標の５秒以内のターンアラウン
ドタイムを実現した。
　特にデータベース設計は、本システムの要であった為
、早期に完成させることができ、再設計による工数増大
のリスクを抑えることができた。また、グラフィック描
画ルーチンは、後述するが、完成度が高かった為、部品
化の後、正規システムに流用することで、同じく工数の
削減へとつながった。

２−３　工夫した点

　プロトタイプ作成後のユーザを交えたレビューにより
、過去の全保守履歴の表示は必要ないと判明した。そこ
で、データベースの部品テーブルに、最新の保守履歴フ
ィールドを直接追加することで、参照回数を減らすこと
で高速化を図った。また、データ量、画面描画点数も減
ることなり、高速化につながった。これによりターンア
ラウンドタイムの短縮が図れた。
　グラフィック描画部については、完成度が高かった為
本開発に再利用可能と判断した。しかし、今後の保守、
バージョンアップを見据えて品質を高める必要があった
。そこで、モジュール構造のみを再利用し、新たにコー
ディングを行うことで品質の向上を図った。再度のコー
ディングにより性能劣化の可能性があったため、コーデ
ィングに際しては、デバッグコードを入れてパフォーマ
ンスの計測を行えるように指示した。結果、若干性能が
向上する結果となった。
　また同時にサーバ及びクライアントマシンの性能につ
いてのチューンナップも行った。クライアントマシンに
ついては、描画時にリソースを大量に消費することに伴
うスワッピングが発生していた為、メモリを増強し、こ
れをなくすことによって性能を向上させた。

３−１　評価

　本システムの核となるデータベース設計を、ユーザか
らの要求性能をクリアする形で出来たため、後の工程を
スムーズに行うことができた。特にチューニングの為の
再設計を行わずに済んだ為、後工程への影響がなく、開
発リスクの低減に役立った。
　また、グラフィック描画部については、プロトタイプ
を再利用することによって、性能はそのままに、品質を
向上させることに成功した。

３−２　改善点

　今回、特に考慮しなかったことだが、プロトタイプの
動作環境について、サーバの最頻時におけるレスポンス
についての検証を行わなかった。この様な点を考慮し、
システムを本稼動に近い環境で動作させることで、より
精度の高い検証を行えるようにしたい。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上

火力プラントですか。こういう専門的なのは、普通の人間じゃ分からないから、説明するのが難しいんですね。論文採点者も同じ。分かり易く説明して、ポイントをつかんでもらうのが重要なんですね。ではさっそくNAOKI医師に診察を受けていただきましょう。

Naokiです。

えび天さん はじめましてさっそく診てみましょう。私も初心者なので大目に見てくださいね。

プロトタイプの問題ですね。
ＳＥはよくやるし、ユーザも「プロトタイプを作成します」というと一様に喜ぶんです。問題としても出題される可能性は高いですね。なぜでしょうか？それは、みなさん勘違いしやすいからだと思います。

＞プロトタイプは、システムのターンアラウンドタイム
＞を計測するためのものである。

本当にそれだけでしょうか、ＵＩの確認とかにも使うのではないでしょうか？
問題文にもそのような説明がありますね。色々な視点があります。
色々な視点があるなかで、今回私はこういう理由でこの視点で対応しました。
と主張するのは良いことですが、可能性を考えずにこうだといいきってしまうのは、狭い視野しかもっていないのかな？と思われてしまいます。

＞ユーザより同時にユーザインターフェ
＞ースの確認も行いたいとの要望があった。しかし、目的
＞が異なる為、別のプロトタイプとして作成することとし
＞、本プロトタイプでは、性能評価に目的をを絞って検証
＞することにした。

プロトタイプの目的です。今回のメインですね。
ここで決めないといけません。プロトタイプは良いところ悪いところあります。
良いところはえび天さんのおっしゃるように性能を早い段階でつめることができることで後工程にリスクを持ち込まずにすみます。

しかし本当に良いことばかりでしょうか？
余分な作業が発生する点、ここでは明記されていませんでしたが、どこまでプロトタイプで検証したらＯＫまたは次のフェーズに進むということを最初から明確にしておかないとずるずると長引くおそれがあります。

性能評価のプロトタイプの場合は目標値をクリアしたら終わりとか、期間がいつまでとかに決めておかないと研究室の実験になってしまいます。目標値、期限について、また目標値をクリアできないと見切るポイントについて事前に目的とともに決めておく必要があります。

特にＵＩのプロトタイプなんかは期限、ポイント、目標値を決めておかないと。
ずるずると「ユーザの要件をあれもこれもと盛り込む」、「プロトタイプの目的があらぬ方向へ発散する」はめにならないとはいえません。

ユーザ要件を早期に掘り起こすことが目的なのですから、最初から渋いことをいうのもどうかと思いますよね。そこは「ユーザとの共通認識を明確にし健全にシステム開発してきましょう」ということだと思いますよ。
そこのところのすったもんだを記述できればかなり強いですよね。

えび天さんの記述内容もここをポイントに深く掘り下げることをお勧めします。
いきなり「性能要件に絞った．．．目標の５秒以内のターンアラウンドタイムを実現した。」では、ちょっと。
「ユーザがインタフェース確認したいという要望」はどこへ。。。
「もっと苦労話が聞きたかった」という感じですね。

あと３．工夫した点では、話が性能向上のほうへ寄っていています。
プロトタイプのことではなくて、その後に行ったレビューでうまいこと不具合を発見できたという流れになっていますね。みなさんに何度もいいますが「題意は外さない」ことを気をつけてください。

おわりに．．．

「題意を外さない」なんて、偉そうなことをいいましたが、気が付くと私も得意な書きやすい内容に摩り替えて書いていってるんですよね、そういう時って、やっぱり題意にあうような経験や主張が少ないということの現われだど思うんですよ。なにが試験にでるかわかりませんが、お互い試験日までこれぞと思った経験や主張を完璧に展開できるよう悶々とするしかなさそうですね。

では　お互いがんばりましょう。

NAOKI医師ありがとう。院長はまだゆっくり見れていません。近いうちに診察しますのでもう少しお持ち下さい。（以下次回）