論文治療クリニック

エーロンの論文治療クリニックへようこそ。このクリニックでは、論文試験に悩み苦しんでいる患者さんを適切に治療しますよ。最初の方どうぞ。

お願いいたします。どうも論文の具合が悪くて・・・だるいんです。


ふむふむ。だいぶお疲れのご様子ですね。AE試験は何回受験されましたか？


2回ほど・・・・でも論文でだめでした。なんか、何書いても合格するように思えないんです。もう憂鬱で・・・AE試験受験するのやめようかなあなんて。会社でもやる気が起こらないんです。


いけませんねえ。それは重症ですね。ちょっと、見せてもらいましょうか。


お願いいたします。私の書いた論文です・・・実はこのテーマなんですが・・・

《デザインレビューによるユーザニーズの確認について》

　ビジネス環境の変化や情報技術の進歩を背景に、システムに対するユーザニーズはますます複雑化・高度化してきている。

　ユーザニーズに適合したシステムを提供するためには、システム分析・要求定義・外部設計の各フェーズでレビュー工程を設定し、ユーザニーズがそのシステムの設計に的確に反映されていることを確認する必要がある。

　デザインレビューは、これらの各フェーズで作り出される成果物を通して、機能、性能、操作性、信頼性、安全性、運用、保守、移行などの設計がユーザニーズに合っているか、いかに実現されているかをチェックするために実施される。また、ヒューマンインタフェースや性能を評価するには、ドキュメントのレビューだけでは限界があるため、これを補うものとしてプロトタイピングによる評価方法なども用いられる。
　デザインレビューを成功させるためのポイントとしては、次のような事項が挙げられる。

・ユーザと開発部門とが共通の認識をもてるようなドキュメントを作成する。

・目的に合わせたレビュー方法を選択する(ウォークスルー、インスペクション、ラウンドロビンなど)。

・ユーザと開発部門が一体となった共同作業を実施する。

このような作業を行ったうえで、レビュー結果を確実にフォローアップすることが重要である。

あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

設問ア
　あなたが開発に参画したシステムについて、ユーザニーズの特徴とそのシステムの概要を、800字以内で述べよ。

設問イ
　あなたはユーザニーズの実現度合いをチェックするために、どのフェーズのレビューを最も重視し、どのような方法でレビューを実施したのか。レビューを効率的・効果的に実施するために工夫した点を中心に具体的に述べよ。

設問ウ
　レビューの結果(指摘された誤り、不明点、改善点など)に関して、どのようにフォローアップしたか、具体的に述べよ。

ほう。レビューネタですね。これは、AEにとっては重要な技術を含んでいますから、腕の見せ所ですね。
では引き続き、内容を見せてもらいましょう。


はい。どうぞ・・・痛くないですか？


荒療治が必要な場合は、心が痛くなることもありますよ。ではみてみましょう。

（設問ア）外国金融先物システムの概要

　現在私は損害保険会社A社のシステムエンジニアとして勤務している。今回、外国金融先物システムを開発する事になり、私がシステム設計とプロジェクト管理を行うことになった。

1-1　システムの概要
　Ａ社は損害保険会社であり、膨大な外貨建資産投資を行っている。外貨建資産のリスクヘッジ手段として金融先物商品の利用が有効であるが、Ａ社ではこれまで投資部門にあまりノウハウがなかったため、投資手段としては利用されていなかった。しかし投資上必要不可欠の判断のもと、投資を開始するにあたり、管理システムを開発する事になった。Ａ社には既に外国資産管理システムが存在し、６年前から稼働していたが、外国資産は商品種類が多く、かつ国ごとに制度が異り複雑であるため、数年かけて順次開発をおこなっていた。開発済のエリアはまだ少なく、今回の金融先物システムは、初のリスクヘッジ商品管理システムであり、社内的にも重要視されていた。

1-2　システムの特徴
　外国資産管理システムはホストコンピュータ上で稼動しているシステムで、２０台の端末と専用線で接続されており、該当システムもこの環境で運用される。システムの機能としては、商品属性登録、取引管理、残高管理、伝票作成、経理システムへの連動、各種管理資料作成機能等である。将来的には社内監査部門システムにも連動する計画もあった。投資はシステム完成を待って開始されることになっており、できるだけ早く稼働させることが至上課題であった。

（設問イ）重視したレビューとその工夫
2-1　私の問題意識
　　該当システムを構築する上での課題は以下の通りであった。
　　�@６ヶ月で稼働させる。
　　�A既存の外国資産管理システムの基盤で開発する。
　開発メンバーは入社２、３年のシステムエンジニア７人と私、そしてプログラマー１０人であったがシステムエンジニアの経験が比較的浅く、早期稼働には生産性向上策が必要と感じた。また、外国金融先物はこれまで私が担当した商品の中で最も複雑であり、早期稼働のためには実現機能の絞り込みが不可欠であった。さらに複数のセクションにまたがる開発になるため開発途中で後戻りをおこさないことが早期稼働の前提になると考えていた。以上から、私は今回の開発で以下の事項が重要と考えた。

(1)システムエンジニアの生産性向上策
(2)システム実現機能の絞り込み。
(3)関係部門への遅延のない情報開示

2-2　私の工夫
上記の問題意識を背景として、私は次に述べる方策を具体的に実施した。

2-2-1　ユーザー部門での事務研修を兼ねた要件定義
　私は他のシステムエンジニアと一緒にユーザー部門に駐在し、商品知識の吸収、事務管理方法の吸収を図り、同時に人間関係の構築をおこなった。この機会に投資部門長とも頻繁に話をして、将来的な投資戦略、ユーザー側の人員計画等、システム開発のポイントとなる情報を手に入れることができた。

　2-2-2　開発関連文書のワープロ化　
　Ａ社では開発関連文書を手書で作成することが多く開発時の関連文書は多種になることから、生産性が低いと感じていた私は今回はすべてワープロで作成するように指示した。そうすることで１つの文書を様々なフォーマットで使い回しでき、効率的だと考えた。ユーザーへの帳票・画面の確認時も、今までは設計用紙に手書きをして時間がかかっていたが、表計算で作成し、ユーザー確認・了承後そのままプログラマに渡して開発するようにした。　画面・帳票サンプルの確認が早期にできるようになりユーザー部門からも好評であった。

　2-2-3要件定義マスター文書の作成・運用
　これまでＡ社ではエリア別に要件定義を行い関連部門長宛に「開発決裁書」を送付、承認を受けることになっていた。しかし、ユーザー側の担当者が確認するまでには時間がかかりすぎて要件が変わってしまっている事態もあり、しばしば後戻りの原因になっていた。このため、私は以下の通りにすることを提案し、実施した。

(1)最初に概要のみ記述した「開発決裁書」を関連部門長に送付・承認を受ける。
(2)要件定義の結果の実施事項を「開発詳細内容」文書として１つの文書にすべての内容を記述し関連部門の担当者宛に送付する。

(3)ユーザーへのレビューはこの文書を使用して行い、問題ない場合は関連部門の担当者から部門長に説明、承認を受ける。

(4)内容に不具合があれば、修正文を迅速に差し替えて再度部門長に承認を受ける。　　この結果、システム部門とユーザー部門の認識が常に一致している状態になり、認識相違による開発の後戻りを起こさず、スムーズな開発が実現できた。

（設問ウ）私の工夫の評価と今後の課題
3-1　私の方策の評価
ユーザーでの事務研修により私を含めたシステムエンジニアに外国金融先物商品の具体的イメージができ、また現行システムの問題点等が認識できた。これにより、よりユーザーの立場でシステムを構築できたと評価している。一月の研修で人間関係もよく　なり、その後もスムーズな交渉ができた。また、ユーザー部門長から、今後の投資戦略を聞き今後追加が予想される商品を考慮して、拡張性の高いシステムを構築できた。
「決裁書」の方式変更では、最後までユーザーとの認識のずれを起こさず、後戻りを発生させなかったことを評価している。文書のワープロ化は現在Ａ社の標準化となり、社内的にも生産性向上に寄与できたと自負している。

　3-2　今後の課題

�@標準化の重要性
Ａ社の外国資産管理システムは数年をかけてサブエリアを追加しているために、開発担当者も異なり１つのシステムにも関わらずユーザーインタフェースや設計思想に一貫性がないなど問題を含んでいる。今後は仕様標準化を徹底することがシステムの陳腐化　を防ぐ１つの手段と考え、率先して実行したい。
�Aユーザーの立場にたったシステム構築の重要性
今回はユーザーの立場にたったシステムを極力目指したが、このことを肝に銘じて、Ａ社の他のシステムエンジニアにも教育していくことが重要だと痛感している。

うーむ。これはなかなかいやはやなんとも？


そんなに悪いですか？


この論文もしかして、事前に作成していませんでした？なんか、問題の趣旨に遠いような気がするんですが？


よくわかりますね。ある論文対策本に事前準備をしろと書いてあったので、その内容を書きました。


テーマは意識していますか？


良く覚えていませんが、確かかなり古い本だったと思いますけど。


やっぱり！　この論文テーマは旧特種時代のものですよ。それを使って論文準備しましたね。


テーマって重要なんですか？とりあえず字数を書けばよいと思っているのですが、だから、問題文はあまり読まず、準備論文に最も近いテーマを選び、ひたすら書いています。そうしないと時間が足りなくなりじゃありませんか？準備をせず、当日の問題文をよく読んで論文を書ける人なんているんですかね。文書がうまけりゃいいんじゃないですか？


うーん。相当重症ですね。末期症状ですよ。余命３ヶ月の論文重病患者に認定します。早速隔離病棟で治療をします。

《隔離病棟にて》


よかったですね。もう少しで手遅れになるところでした。確認ですけど、論文の事前準備はいつもあのような感じで、１つの準備物を展開しようとなさっているのですよね。


はい。昔から論文試験には事前準備が必要と言われてきましたし、本番で論文を書くことは難しいと考えていますから・・・でも、事前に多くの準備はできないので、１つの論文で展開するのがいいと思っているんですが・・・・間違っていますか？これしかないでしょう？


うーん。どうも昔の話が今も同じだと思われる風潮があるなあ。いかんいかん・・・・・・


え、ちがうんですか？間違っていますか？


確かに、旧特種の時代は、割とそれでもよかったんですよね。いまより、限定的でなかったんですよ立場が・・・・・

現在の情報処理試験は、立場（役割）が分かれて定義されていますよね？たとえば旧特種はリーダーSE（上級SE）を意図して考えられていた試験なんですね。だから、今のAE、PM、ANの立場を１つで試験を行っていたんですね。だから、割と試験問題も緩やかで、システム開発上の工夫を書け、管理上の工夫を書けというふうに、個人の工夫を評価する論文試験だったわけです。当然、今も工夫を問われるんですけど、漠然とした工夫でなくて、「分散DB設計上のユーザーとの確執を回避するための工夫」とか、修飾語がながいんですよ。

今は、分業が必要だから・・・AE、PM、ANに分かれたんで、それぞれの役割が通常もっいる基本技能・・・AEだったらDB設計、PMだったらプロジェクト管理、ANだったら損益観点とかそういう観点を細かく要求されるんですよ。だから、事前準備の仕方もちょっと違ってくるんじゃないのかなというのが最近の論文治療界の定説なんですけどね.


1つの論文例をアレンジする方法ではだめなんですか？


少なくとも、何を受験するかで論述する内容はまったくちがうんですから、試験区分ごとに違う準備になることは明らかですね。では、同じ区分・・・たとえばアプリケーションエンジニアを準備する場合はどうでしょう。

試験は３テーマのうちから１題を選ぶ形態ですよね。その３つは全然問われていることが違いますよね。そんな状態なのに事前準備した論文をアレンジしていくのは結構難しいと思いますよ。

大体、よく失敗することの１つに「準備論文へ固執症候群（シンドローム）」があります。


怖そうな論文病ですね。


はい、典型的な完全準備依存症です。事前に１つそれなりに綺麗な（自分で満足のいく）ものを用意できたとすると、本試験のテーマに関係なく、その準備論文を本番で再現しようとする病気です。

固執してしまうんですね。でも、そんなのは美しいけれども、合格論文ではなくただの偶像ですよ。これを繰り返すと中毒になり、本試験のテーマやキーワードを忘れ、ひたすら準備論文を思い出して書くだけの悲しい状態になってしまいます。


怖いですね。自己満足の世界ですか・・・・この場合の治療法は？


そうですね。準備をするのは必要なんですが、もっと違う準備をして、リハビリを重ねつつ治療するんです。それは凄く効果的な治療法なんですよ。


はあ　ぜひ治療してください。


そんなに焦らずに・・・・あなたはもっと基本的な治療が必要なんですよ。あなたは「試験問題無関心症」ですから、それから治療しないいけません。では、治療に入ります。今から論文問題を見せますから、本試験と思って論文記述の再現をしてください。いいですかいきますよ。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

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

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

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


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

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

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

プロトタイピングですね。プロトタイピングは一度使ったことがあります。すぐかけますよ。えーと　販売管理システムだったなあ。

プロトタイプは有用だった。でも自分でやろうと思ったのでなく、上司がやれっていったからいやいややったんだったなあ。めんどくさかったなあ。設問アはかけそうだけど、設問イはどう書こうかなあ。いいや。そのときの状況を思い出して書こう。最初に・・・・


はい。ストップ。だからあなたは「試験問題無関心症」なんですよ。


なんですか？　問題ありますか？


あなた、問題文よく読んでいないでしょう？出題も理解していませんね？だからだめなんです。


失礼なこといいますね（怒）　ちゃんと読んでますよ。プロトタイピングのこと何でも経験したこと書けばいいんでしょ！それくらい私だってわかりますよ。こうみえても１０年SEやっているんですから。


ふー　困った人ですね？いいですか？なぜ、出題者が問題文を苦労してたくさん書いているのか分かりませんか？もしプロトタイプに関して何でも書いていいなら、問題文は１行で終わりますよ。「プロトタイプに関して書きなさい」とだけね。でも、違いますよね？

＊＊＊＊＊＊＊＊＊＊＊＊

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

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


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

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

＊＊＊＊＊＊＊＊＊＊


出題者も好きでこんなたくさん書いているわけではないんですよ。わざわざね。これにはちゃんと理由があるんですよ。

うーん。なるほど・・・・確かに。ぜひ、処方してください。お願いします。


あなた、さき私に反抗しましたね。だから駄目です。今日はお帰りください。あなたのようなわからずやには私の処方はできません。


先生　申し訳ありません。反省いたしております。ちゃんということ聞きますから・・・先生のいうとおり勉強しますから、ぜひ治療を続けてください。先生に見捨てられると、私は不治の論文患者のまま生きていかなくてはならなくなります。どうか抜本的治療をお願いします・・・


あなた・・・英伊　駄目男（えいいー　だめお）さんでしたね。いいですか。一番重要なのは、素直に人のいうことを聞き入れることなんですよ。自分でいくら自信があっても、論文はかけない人が多いんです。ですから、どうしてかけないのかを分からずに、毎年同じことを繰り返してしまうんです。論文試験はメンタルな部分も大事なんですよ。誰か合格者に相談または、添削、指導してもらうことが必要なんです。

わからずやには合格が難しいんです。人に聞くことができない頑固ものは「論文引きこもり」になってますます合格できないんです。ですから、あなたの処方はまずこれです。

�@合格者に素直に指導してもらう柔軟な心になる。頑固な性格をかえる。

これが第一の処方です。これが効いてくれば、後の処方が良く効くようになり、ますますよい循環になり早く退院できますよ。いかがですか？この処方を受け入れますか？

・・・そうだったんですか。私はわからずやでしたか・・・先生有難うございます。私いままで、この「重度論文疾患患者」になるまで、自分の思うとおりにやってました。それが手遅れ寸前まで論文病が進行してしまった原因なんですね。これからは心を入れ替えます。


そうですか。分かっていただけましたか。それではこれから本格的な治療を施しますよ。ただし、この「論文治療」は保険がききませんよ。いいですか？


はい。結構です。貯金がありますから大丈夫です。先生　昨年「重度論文疾患患者」を9人治療し、見事社会復帰させたメスさばきでお願いします。ドクターエーロン　私を治療してください。


そこまでおっしゃるなら、やりましょう。あなたの場合は、根本から治療が必要です。まず最初に必要な治療は、「設問対応回答不能症」の治療です。この病気は、出題者が設問を設定しているのに、それを上手く読み取れない恐ろしい病気です。この治療を行います・・・では、先ほどのレビュー問題を題材に治療しましょう。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

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

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

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


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

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

この問題に対し、解答（論述）すべき項目の構成（大項目）を記載してください。いいですか？私の言っている意味がわかりますか？つまり　解答用紙の見出しを設定してほしいのです。では、始めてください。


うっいきなり言われると少し家で考えさせてください。


駄目です。ここで考えなくては意味がありません。よく考えてみてください。本試験のときは、問題配られてすぐこの作業をしなくてはいけないんですよ。本試験の時に「家でよく考えて・・・は通用しないんです。ですから、これも治療なんですが、いかに早く問われていることを適切に把握できるがが必要なんです。

《処方》
　問題をみて、すぐに問われていることを把握する訓練をする。


分かりました。これも訓練なんですね。


そうです。本来、人間はぐうたらですから、後で考えたい。家でゆっくり考えたい、。そのうちに・・・というのが多いんです。でも、多くの場合、試験直前になって「やっぱり時間がなかった。来年はしっかり勉強しよう！」と思ってあきらめてしまうんです。でも、そんなことでは、来年も同じ。その時点で来年も負けなんです。今年精一杯やっても、この試験は受からないんです。合格率6から7％ですから。だから、今年絶対合格するくらい準備して、来年合格するくらいがやっとなんです。来年になって、「絶対合格したとおもったのに・・・今年は合格しないわけがない！」くらい思えれば、気持ち的に買っているんです。そうなって始めて合格できるんです。分かりますか？

《処方》
　そのうち・・・では絶対合格しない。試験はなんでもそうだが、気持ちが大切。こんな簡単な試験自分が合格できないわけがないと思うくらいでちょうどよい。


そうですか。私は負けていました。早速訓練に入ります。

まず、設問アと設問イと設問ウに大きく分かれますよね。ですから大きく、第1章から第3章までを用意することでいいと思います。また、設問アは、プロトタイプを使ったシステムの概要を問われていますね。

設問イは、どういうプロトタイプを作ったかを書きます。具体的に手順などを書きます。設問ウは感想と振り返りですよね。どこが大変だったかを書きます。そうすると、章立ては・・・・

第1章（設問ア）

　・プロトタイプを使ったシステムの概要

第2章（設問イ）

　・プロトタイプの内容

　・プロトタイプを作った手順

第3章（設問ウ）

　・感想と振り返り

こんな感じで後は、思い出しながら書いていきます。こんな感じでいかがでしょう？


さあ、治療をスタートしますよ。まず、「設問ア」からですが・・・

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

あなたが開発に参画したシステムの概要とどのようなプロトタイプを作成したかについて、800字以内で述べよ。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

これは簡単ですよね。この中では２つのことを問われいますよね。まず、�@開発に参画したシステムの概要、�Aどのようなプロトタイプを作成したかです。でも、設問だけ読むと、漠然としているので、どうとでも記述できますよね。システムの概要なんかどうとでも書けるし、どのようなプロトタイプを作成したかっていうことも、それなりに経験があれば記述できますよね。でもね。そうやって設問アから調子に乗って書き出すと、後でひどいことになるんですけど、分かりますか？


そうなんですか？設問アから一気に書き出すのではないのですか？私は、設問アが一番書きやすいので、記述になれる意味でも、最初にいっきに書き出します。そうしないと不安で。とにかく、早く書き出さないと不安なんですよ。


まあ、わからんでもないですけどね。あなたは「反射的設問ア記述開始症」の疑いが強いですね。設問アは書きやすいし、とりあえずかけるからなんとか論述スタートできるんですよ。でもね。それはあくまで気がするだけです。後でひどいことになるんですよ。設問アだけを見て書き始めると。なぜって？それは、設問は独立していない、コバンザメのような設問だからなんですよ〔何のこっちゃ？）　設問イの構成の前ふり的要素が強く、設問イで何を書くか決めていない段階で設問アだけとりあえず書き始めることは難しいんです。具体的にいいますと・・・・

「設問アは、設問イを記述するためのつなぎ」なんです。

《ポイント・・・設問アは設問イのつなぎであり、設問イを読んでいただくための大いなる前ふりである。》


ん？　つなぎ？　前ふりですか？　それって、もしかしたら、設問イに面白いことが書いてあるので、読んでくださいよっていう機能を設問アに持たせるってことですか？


英伊さん。よかったですね。だんだん治療の成果が出来きました。そのとおりですよ。そのことに気づいてほしいんです。いいですか、設問イは本論ですから、そこでは、多くの場合、具体的なものを論述していく必要があるんです。でも、設問イでいきなり具体的に記述すると採点者には、背景やどうしてそういうことになったのかわからないんです。考えても見てください。背景が良く分からないことの具体策を記述されても、よいのか悪いのか判断できないんですよ。

そう考えて、設問アの意味を理解すれば、なるほどと思いますが、多くの場合、設問アは、システムの概要やどういうものを作成したか述べよという出題構成になっていますよね。

今回の場合は以下のとおり考えればいいはずです。

＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊＊＊＊＊＊

設問イで聞かれているのは、�@プロトタイプの目的と�A効果があった点、�B効果を引き出すための工夫

この３つですね。一方、設問アで聞かれているのは、�@システムの概要、�Aどんなプロトタイプを作成したか

ですね。設問イには、具体的なことを書かなくてはならないのですが、これをサポートするために設問アではいろいろ配慮しなくてはなりません。ここでの設問アの役割は・・・


役割は？　導入の意味があるんでしたよね。設問イでプロトタイプの目的、効果、工夫を書きやすくするため、に設問アに説明を入れるんですね。単にシステム概要を書いて、プロトタイプを作りましたじゃ駄目なんですね。


だいぶ分かってきましたね。それでは、論文構成を一緒に見直しましょうか。以下を良く見てください。

まず、設問アの解答を第１章としましょう。同じく設問イを第2章、設問ウを第3章とします。
-----------------------------------------------
第1章（設問ア）

第2章（設問イ）

第3章（設問ウ）
-----------------------------------------------
次に、詳細化していきます。問題をよく読みますと以下の記述があります。

＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊＊＊＊＊＊

設問アで問われていることは、システムの概要とどのようなプロトタイプを作成したかの2点ですね。そうですね。ですから、それを素直に解答論述の中項目とします。

-----------------------------------------------
第1章（設問ア）
　1-1　システムの概要
　1-2　どのようなプロトタイプを作成したか

第2章（設問イ）

第3章（設問ウ）
-----------------------------------------------
設問イで問われていることは�@活用したプロトタイプの目的、�Aプロトタイプ活用によって特に効果があった点�Aの効果を出すために工夫をした点ですね。これを素直に中項目とします。
また、設問ウは、�@あなたの評価、�Bさらに活用するための改善を問われていますね。これをとにかく素直に解答論構成に書いていくだけです。

-----------------------------------------------
第1章（設問ア）
　1-1　システムの概要
　1-2　どのようなプロトタイプを作成したか

第2章（設問イ）
　2-1　活用したプロトタイプの目的
　2-2　プロトタイプ活用によって特に効果があった点
　2-2　プロトタイプの効果を出すために工夫した点

第3章（設問ウ）
　3-1　私の評価
　3-2　さらに活用していくための改善方策について

------------------------------------------------


これを最初にするんです。そうすれば、問われていることに対して的外れな解答をせずに済むのです。さあ、英伊さん　次のステップに移って結構ですよ。


はい。この範囲で自由に書けばいいのですね。では早速・・・

ちがーう！全然直ってない。ほんとに重症ですね・・・


まだなにか問題があるのでしょうか？自分の論理を自由に書いてなにが悪いのでしょうか？


英伊さん。何度もいいますが、何故問題文があるのだと思いますか？なぜ、たくさんの記述があるのか・・・これにはわけがあるんです。いいですか。論文を書くのはあなた一人ではないんですよ。多くの受験者が書くんです。その中から、合格者を出すわけです。採点は機械ではないんです。人間が行うんです。試験で重要なのは主観でなく客観性です。ですから、試験採点側としては、出来るだけ同じ土俵で見れるような論文を書いて欲しいんです。分かりますか？


うーん。ということは、制約を設けたり、記述誘導をするということかなあ。


英伊さん。何度もいいますが、何故問題文があるのだと思いますか？なぜ、たくさんの記述があるのか・・・これにはわけがあるんです。いいですか。論文を書くのはあなた一人ではないんですよ。多くの受験者が書くんです。その中から、合格者を出すわけです。採点は機械ではないんです。人間が行うんです。試験で重要なのは主観でなく客観性です。ですから、試験採点側としては、出来るだけ同じ土俵で見れるような論文を書いて欲しいんです。分かりますか？


うーん。ということは、制約を設けたり、記述誘導をするということかなあ。


そうです。分かってきたじゃないですか。多くの受験者に同じ方向を向けさせ、その枠の中で競ってもらうのが午後�Uなんですよ。ですから、問題文に制約条項をたくさん入れるほうが都合がいいのです。問題を見れば、制約は分かるはずです。その中で、あなた自身の個性を出せばいいんです。ちょっと問題文見ましょうよ。

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

　プロトタイピング活用の目的は、プロトタイプを作成して開発すべきシステムの機能を早期に実証することによって、ユーザニーズに合致したシステムをより効率的に開発することである。
　プロトタイピングにおいては、開発者による検証のためにプロトタイプを作成する場合や、開発者とともにエンドユーザが機能を評価する目的でプロトタイプを試用する場合がある。さらにプロトタイプは、評価・検証後に使い捨てにされる場合や、そのまま最終システムの骨格として使われる場合などがある。
　
プロトタイピングを活用することによって、一般的に次のような効果が期待できる。


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

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

いいですか。解説していきますよ。

プロトタイピング活用の目的は、プロトタイプを作成して開発すべきシステムの機能を早期に実証することによって、ユーザニーズに合致したシステムをより効率的に開発することである。

制約�@として・・・

この出題では、プロトタイプは上記の目的で存在していると言い切っているんです。だから、これ以外の目的で使ったという論述をしてはいけないんです。それは、あなた自身が目的を理解していなくてはならないんです。あなた自身がプロトタイプも目的を理解し、開発の特徴を鑑み、あなた自身が導入し、開発を成功させたこと書かなくてはならないんです。間違っても

・「上司から使えといわれた」　とか
・「ユーザーから作ってくれといわれたのでしかたなく・・・」とか
・「最初から使うことが決まっていたので、何の違和感なく・・・」とか

書いてはいけないんです。もし、この手の論文を書けば、あなたの答案は間違いなく闇に葬られる悲しい運命となるでしょう。

この問題では、「プロトタイピングは開発すべきシステム機能の早期確認のために使った・・・」と書くべきなんです。そうなってくれば、設問アには・・・

・「このシステム開発の特徴は新しい機能を多数構築する必要があったことである。早期に確認出来なければ、後戻りが発生し、期限内に納品できない危険性があった」とか

・「このシステム開発の特徴は細かいユーザーニーズが多く予想されたことである。、このニーズを早期に確認し、管理していかないと上手くいかないと思った」とか

の記述が必要になるんです。この記述があって始めて、設問イに「だから、早期確認の手法としてプロトタイプが必要だった」と主張できるんです。「こういう特徴のあるシステム開発だったので、それを上手くやるために○○の手法を使った」という論述が説得力を持つんです。どうですか？

なんか、これまでの鬱状態が嘘のようです。体がすっきりしてきました。


でしょう。では次に・・・

プロトタイピングにおいては、開発者による検証のためにプロトタイプを作成する場合や、開発者とともにエンドユーザが機能を評価する目的でプロトタイプを試用する場合がある。さらにプロトタイプは、評価・検証後に使い捨てにされる場合や、そのまま最終システムの骨格として使われる場合などがある。

［キーワード］

さて、この段落はなんのためにあるんでしょうか？

プロトタイプには・・・
�@開発者の検証のためのもの
�Aユーザーが機能を評価するためのもの

があり、さらに・・・

�@使い捨てのもの
�A残るもの（稼動用システムとして流用されるもの）

があるんですよ。といっています。英伊さん、この記述をどう思われます。


なんか、とても親切ですね。プロトタイプとはこういうものだということを書いてくれてますね。


でしょう！これが制約とキーワードなんです。論述には、これらのことを入れて書いて欲しいんですよ。出題者は。ですから設問イには・・・

・「このシステムは新規機能が多くあった。私を含め、開発要員はこ新規機能を実現する技術に関するノウハウが不足していたので、出来るだけ早い段階で検証する必要があった。このため、開発者の検証を目的としたプロトタイピング手法で早期確認する方法がよいと判断した。

・「さらに、このシステムは細かいユーザーニーズを実現する必要があった。私はユーザーニーズを早期に確認しておかないと後工程での後戻りが発生し、期限内での稼動が実現できないと考えていた。このため、ユーザーニーズを早期に確認できる仕掛けを検討し、プロトタイプを使用することとした。プロトタイピングは、段階でユーザーの目に見える形で提供出来、ユーザーの真のニーズを引き出せる効果があると考えたからである。

これで、出題者が意図している制約もキーワードも埋め込めるんです。あとは・・・使い捨てと流用方も埋め込む必要があります。英伊さん。あなたはもう、病気が治っているんです。ほら、自分の手は自由に動くんです。ゆっくりエンピツを動かして見てください。もう不自由ではないんです。あなたにはかけるんです。


本当に、私はなおっているんでしょうか？私も自分の手でかけるんでしょうか？・・・・なんていうことでしょうか！私の手が書いています。先生、書けます。私かけるんです。

［使い捨てを選択したと書く場合はこうですね・・・］

プロトタイプには使い捨て型と流用型があるが、私は使い捨て型を利用した。なぜなら、今回は、出来るだけ早くユーザーニーズを確認する必要があったこと、ユーザーの使い勝手を確認するのみでよく、レスポンスタイムの体感までを必要としなかった。出来るだけ早く大枠を提供すればよかったので、実際のシステムとしてでなく、PCの汎用ソフトで作成すれば十分目的を達成できたからである。

［流用方を選択したと書く場合はこうですね・・・］

プロトタイプには使い捨て型と流用型があるが、私は流用型を利用した。なぜなら、今回は、出来るだけ早くユーザーニーズを確認する必要があったことに加え、レスポンスタイムの体感までを必要としていたからである。これを実現するためにはある程度の新システムの作りこみが発生してしまう。後工程の効率化を考えれば、多少時間はかかっても、実際のシステムの一部として作りこむ方が得策と判断した。このため、プロトタイプの完成までは多くの要因をその作成に振り向けるような工程管理を行った。

英伊さん。よく頑張りましたね。あなたは既に病人から立ち直ろうとしています。もう最後ですが、設問イとウの骨子を書いてみて下さい。

はい。先生　見ていてください。

＜設問イ＞

�@プロトタイプの目的
　このシステムは新規機能が多くあった。私を含め、開発要員はこ新規機能を実現する技術に関するノウハウが不足していたので、出来るだけ早い段階で検証する必要があった。このため、開発者の検証を目的としたプロトタイピング手法で早期確認する方法がよいと判断した。さらに、このシステムは細かいユーザーニーズを実現する必要があった。私はユーザーニーズを早期に確認しておかないと後工程での後戻りが発生し、期限内での稼動が実現できないと考えていた。このため、ユーザーニーズを早期に確認できる仕掛けを検討し、プロトタイプを使用することとした。プロトタイピングは、段階でユーザーの目に見える形で提供出来、ユーザーの真のニーズを引き出せる効果があると考えたからである。

�A特に効果があった点
　私はユーザーニーズの実現度を評価してしてもらうため、ユーザーのリーダークラスと担当者を集め、プロトタイプを使った評価の場を設けた。ここで効果があったのは、ユーザーの真のニーズを掘り起こせたことである。ユーザーニーズの収集は主にリーダークラスへのヒヤリングで行ったが、実際の評価会では、担当者からの意見が多く集まった。当然、リーダークラスは担当者に確認しながらユーザーニーズを取りまとめたのであるが、実際にプロトタイプを使って実際の担当者が使うことで、細かい仕様追加が発見できたのである。仮にこのような評価会を実施していなければ、システムテスト時に大きなゆり戻しが発生していたはずであり、プロトタイプを使ったことは非常に効果的であった。

�B効果を引き出すための工夫点
　前述の通り、私はニーズを提出したリーダークラスだけでなく、実際の担当者に使ってもらうことが重要と考え、評価会を実施した。また、当日に効率的な試用が行えるよう、事前にシナリオを用意し、ユーザーを誘導した。さらに事後に評価結果をまとめて提出してもらうよりも、試用した直後の意見を確認すべきと考え、試用の後に評価会議を開催し、鮮度のの高い意見を収集することなどの工夫をした。このため、評価会は活発な意見交換がなされ、私の目的は十分実現できたと考えている。
＜設問ウ＞
�@評価
　今回の場合、ユーザーのニーズを早期に十分確認することがポイントであったので、それを実現するための具体的方策に工夫を重ねた。前述の通り、その目的は達成でき、開発全体をスムーズにすすめることが出来た。その意味で評価できると考えている。

�Aさらに活用するための改善点
　今回のようなケースでプロトタイピングが果たす役割は大きいと感じた。当社（○○社）では、今までプロトタイピングを使うことがほとんどなかった。今後も類似特徴を持つシステム開発多くあると考えている。この経験を共有化していくために、プロトタイピングの注意点、運営方法などを標準化していき、開発リスクを低減する手法として自分のみでなく、全社的な活用を計っていける仕組みが必要と考えている。

先生　どうですか。私完治していますか？


手術は成功しました。数日のリハビリ後、退院してください。よく頑張りましたね。直らない論文病はないんです。必ず直ります。それを常に肝に命じてください。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　［英伊　駄目男さんの治療完了］