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

新しい患者さんが治療をして欲しいといってこられました。初の外来患者さんです。今回の患者さんのプロフィールは以下のとおりです。では、ちょっと見てみましょう。

エーロン先生、はじめまして。「しげ」と申します。

今秋にAEに挑戦しようと思いますが、論文対策をどのように進めていけば良いかわからず、是非ともドクターエーロンのお世話になりたいと思い、ご連絡させていただきました。

AEは昨年も受験したのですが、論文の出来が悪く撃沈しました。
今まで他の試験は独学で進めてきましたが、論文となると「正解」が明確でないため、自分で書いたものが良いのか悪いのかわからず、成果があまり出ません。
よろしくご指導？（治療）願えませんでしょうか？

簡単ですが私のプロフィールをまとめておきます。
ハンドルネーム：シゲ
取得資格：情報処理2種、1種
職業（担当業務）：SE（ソフトウェア設計、開発・プロジェクト管理）
経験年数：10年

なるほど。SEの本道を歩んでらっしゃる。これはAEに相応しい方ですね。私より、論文を書いて送ってくるようにいいました。そしてら１週間弱で送ってきましたよ。関心関心。

エーロン先生こんにちは、しげです。

先日は早速お返事ありがとうございました。
遅くなりましたが前回ご指示されましたとおり
論文を送りますので、治療のほど宜しくお願い
いたします。

　題材は　平成12年度午後�U　問１

　です。　お忙しいとは思いますが、宜しくお願いいたします。

平成12年度午後�U　問1といえば、エーロンもある資格系スクールのテキストに模範解答を依頼された問題ですな。データベースの設計ネタだね。これは、AEにとって重要な分野ですね。問題を見てみましょう。

問１　データ中心アプローチ技法によるシステム設計について

　企業における情報化が進むにつれ、全社的なデータ管理の必要性が高まってきている。そこで、データを共有資源と見なし、データ処理を標準化するデータ中心アプローチ技法によるシステム設計が有効となってきた。
　データ中心アプローチ技法では、正規化された新論理モデルをそのまま新物理モデルにすることが望ましい。しかし、実際のシステムにおいては処理効率の悪化、データの管理部門の相違による統合の非現実性、データベース管理の複雑化などの問題点が発生し、作成された新物理モデルが必ずしも現実的であるとは限らない。
　
　これらの問題点を解決し、現実の業務処理に耐えうる新物理モデルを作成するためには、非正規化が必要となる場合がある。

　例えば、処理効率を改善するために、参照系の処理では重複データや導出データを保有したり、更新系の処理では細分化されたデータベースを統合して更新回数を削減したりする。

　反面、重複データの保持やデータベースの統合は、データの整合性やセキュリティの観点から問題となることが多い。したがって、これらの相反する要求を満足するために、非正規化するデータの選定や方法には十分な注意を払わなければならない。
　
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

ではさっそく。患者さんの論文を見てみましょう。

平成12年　午後�U　問1　データ中心アプローチ技法によるシステム設計について

論文
設問ア
1． システム化の目的と概要
(1)システム化の目的
私はソフトウェア会社に勤務するＳＥである。今回、大手自動車販売会社のＡ社システム開発を担当することになった。
Ａ社は複数の営業所と本社からなり、現行は大型汎用機を使用したオンラインシステムが稼動していた。しかし、近年では不要となった機能の増大や、不要データ量の増大に起因しレスポンスタイムの悪化が問題となっていた。その為、Ａ社ではクライアントサーバ型のシステムへの移行を行うと伴に、必要システムの見直し、保有データの見直しを行い、システムのスリム化及びレスポンスタイムの向上を計画していた。
私は当該システム開発において受注管理サブシステムと月次処理サブシステムについてアプリケーションエンジニアとして参画し、システム分析・設計〜システムテストまでを担当した。

(2)システムの概要
　私の担当した受注管理サブシステムは、各営業所にて販売した受注情報を営業スタッフがオンライン画面より入力する機能を有し、Ａ社システム内でも受注情報の発生元となる重要な機能のひとつであった。入力する情報は車種やオプション部品、塗色、納期などの詳細な情報となり、1件あたりの受注に対して大量のデータとなることが想定された。
　又、月次処理サブシステムでは月中に入力されていた受注情報を色々な角度より集計し、管理職の経営戦略資料として役立てる予定である。今回のシステム開発では、新たに各営業所の管理職向けに営業所別の集計資料と営業スタッフ別の集計資料を新設することとなった。
そして、システムを大型汎用機からクライアントサーバ型に移行することにより、現行では月1回固定であった月次処理を営業所の任意のタイミングにて処理できるようにする事とした。

設問イ・ウ
２．システム化の問題点
私は既存システムのデータベースを元に、データ中心アプローチ技法を使用し、新論理モデル及び新物理モデルを作成し、受注情報を管理する3つのテーブル（受注基本情報、受注詳細情報、受注オプション情報）を作成した。その際、以下のような問題が発生した。
(1) 受注管理情報サブシステムの問題点
　受注管理サブシステムでは顧客要求によりデータ入力のターンアラウンドタイムに10秒という制約が設けられていた。私は、新たに作成したデータベースに対しプロトタイプを使用した試験を実施した。その結果1件単独での処理では問題が無いが、入力が集中する月末を想定したテストにおいては12秒かかることが判明し処理効率の悪化が問題となった。これは、正規化されたテーブルのうち受注オプション情報を追加する処理に予想以上の時間がかかっていることが原因であり、およそ1件の受注情報に対し5件程度のデータであるが、入力の集中する月末時には何百件もの追加データが発生するためである。
(2) 月次処理サブシステムの問題点
　月次処理サブシステムでは営業スタッフ別の集計処理結果を情報提供する。しかし、営業スタッフ情報を有する人事サブシステムではリアルタイムに人事異動、退職などの情報が反映されるため、月末時点ではすでに人事情報が反映されている可能性があった。その為、月末時の人事マスタでは正確な営業スタッフ情報が得られず、データ管理部門の相違による統合の日現実性が問題となった。

３．問題点の解決策と採用理由

(1) 受注管理サブシステムの解決策と採用理由
私は月末に集中する入力処理の処理時間を短縮すべく、データベースの見直しの実施と、オプション部品の発生件数調査を顧客に依頼した。これは、新物理モデルでは、大量に発生する受注オプション情報の追加処理に時間がかかっており、追加処理のトランザクション回数を削減することで処理時間の短縮が図れると考えたからである。その結果、1件の受注データに対し、平均で5件程度の受注オプション情報が発生することがわかった。私は、別テーブルとして保有していた受注オプション情報を受注基本情報に5件まで保有できるように非正規化を行い、受注入力時に平均7回発生していた追加トランザクションを平均2回に削減することが出来た。その際、6件以上発生した受注オプション情報は別テーブルに保有することで対応させ、12秒かかっていた月末時の処理も平均9秒にまで短縮することに成功した。

(2) 月次処理サブシステムの解決策と採用理由
月次処理サブシステムでは入力された受注情報の内営業スタッフコードより人事サブシステムの人事情報を取得する機能であった。しかし、正確な情報が得られないため、私は受注基本情報テーブル内に営業スタッフ情報を盛り込むように新物理モデル及び受注機能の変更を行った。これらの変更を行うことにより受注情報入力時点での営業スタッフ情報が取得可能であり、受注に対する営業スタッフ情報は移行の変更処理が発生することが無いため、機能要件を満たすことが出来た。しかし、重複して人事情報を保有することはセキュリティの面から問題があると考え、機能の変更と同時にセキュリティの確保を行う必要があった。私は、この問題を解決するために�@ファイアウォールを設け外部へのデータ流出を防ぐ。�Aデータベース（月次処理自体）へのアクセスに各営業所の課長職以上のアクセス権限を設ける。�B不要となった受注情報、月次集計結果は毎月外部媒体へのバックアップ取得後早急に削除することとし、セキュリティの確保を行った。

４．新物理モデルの評価と今後の改善点
(1)新物理モデルの評価
　今回作成した新物理モデルは月末に処理が集中することや人事情報が得られないなどの問題を解決した上で、現在でも無事に稼動している。レスポンスタイムについても当初計測した時間より遅くなることは無く顧客要求を満たした新物理モデルとなったと思われる。
(3) 今後の改善点
　今回のシステムではシステムのスリム化とレスポンスタイムの向上が目的であり、不要機能の削減やデータ保有の見直しである程度は改善したが、複数台のサーバ機の設置やデータベースの分散保有などの水平負荷分散、垂直負荷分散を利用したシステム改善が今後の課題であると思われる。

いかがですか？他の論文患者の方はどう思われますか？では早速治療を開始しましょう・・・（以下次回）

全体的な構成は○です。論文のアウトラインもいいです。ただし、細部まで見ると、お小言がありますのでよく聞いて下さい。まず設問アのシステムの目的から・・・

設問ア
1． システム化の目的と概要
(1)システム化の目的
私はソフトウェア会社に勤務するＳＥである。今回、大手自動車販売会社のＡ社システム開発を担当することになった。
Ａ社は複数の営業所と本社からなり、現行は大型汎用機を使用したオンラインシステムが稼動していた。しかし、近年では不要となった機能の増大や、不要データ量の増大に起因しレスポンスタイムの悪化が問題となっていた。その為、Ａ社ではクライアントサーバ型のシステムへの移行を行うと伴に、必要システムの見直し、保有データの見直しを行い、システムのスリム化及びレスポンスタイムの向上を計画していた。
私は当該システム開発において受注管理サブシステムと月次処理サブシステムについてアプリケーションエンジニアとして参画し、システム分析・設計〜システムテストまでを担当した。

　本当にこの目的だったんでしょうか？もし本当にシステムのスリム化及び、レスポンスタイムの向上が目的だったら、非常に面白みに欠ける展開になりますよね。考え方として、スリム化やレスポンスタイムの向上は表面的な目的に過ぎず、その奥にもっと大きなものがあるはずです。スリム化されると何がメリットなの？どうしてレスポンスタイムを向上させなくてはならないのか？よく分かりません。どちらもいいことであるのは直感的に分かるのですが、システムを再構築しなければならない理由とは思えません。

　また、なぜ、クラサバにするのかも分かりません。クラサバと汎用機だったら、クラサバの方が時間かかることもあるじゃないですか？クラサバのチューニングはやっかいです。DBMSのオプティマイザ（ちがったっけ？）次第です。あとはブラックボックスでAEのレベルではなかなか難しいですよね。クラサバを選択した理由が弱いです。

　あと、ここの目的は、「データ分析をしたいから」を持ってきて全面的に訴えるほうがウケマス。出題の趣旨は「データの共有化→データは資産→データをいつでも取り出せる→データ分析して経営に役立たせる。」ことが背景にあります。（見え見え）あなたの論文は、データ分析が書いてあるのですが、前面には出てきません。ですから、後ろのつながりが窮屈になってきます。私ならこう書きます

　このシステムの目的は、自動車販売情報を共有化して、販売スタッフに自由に分析させ、オプションの組み合わせや色などの年齢別の売れ筋を把握させ、営業に生かすことである。そのため、データ項目の共通化が必須であった。私は、データ中心アプローチで分析していくことが効果的と考えた。また、ユーザーのデータ分析作業はRDBをSQLで利用することにし、各種検索、分析ツールの種類の多さやなども考慮し、今回は、クライアント・サーバを選択した。

ちょっと、綺麗な文書ではないですが、こんな趣旨のほうが、論点がはっきりします。

なぜ、システム再構築が必要だったのか？
なぜ、クラサバなのか？
なぜ、データ中心アプローチなのか？
が分からないと、採点者も理解できないのです。では次に・・・（以下次回）

(2)システムの概要
　私の担当した受注管理サブシステムは、各営業所にて販売した受注情報を営業スタッフがオンライン画面より入力する機能を有し、Ａ社システム内でも受注情報の発生元となる重要な機能のひとつであった。入力する情報は車種やオプション部品、塗色、納期などの詳細な情報となり、1件あたりの受注に対して大量のデータとなることが想定された。
　又、月次処理サブシステムでは月中に入力されていた受注情報を色々な角度より集計し、管理職の経営戦略資料として役立てる予定である。今回のシステム開発では、新たに各営業所の管理職向けに営業所別の集計資料と営業スタッフ別の集計資料を新設することとなった。
そして、システムを大型汎用機からクライアントサーバ型に移行することにより、現行では月1回固定であった月次処理を営業所の任意のタイミングにて処理できるようにする事とした。

アンダーラインのところなんですが、ホストで月１回で固定的な集計資料を作成していたのを、営業所のえらい人向けに随時処理できるようにするという理解でいいですよね。つまり、自由検索できる仕組みが必要だったんですね？だから、RDBが必要で、ホストではRDBも検索ツールも少ないから、クラサバにしたんですか？おそらくそういうことですね。

ちなみに、このデータ（受注情報）は、営業店で販売用データ分析に使うと理解しましたけど、本社（商品企画部門、マーケティング部門）では使わないんですか？別に論文にいれてほしいということではないんですけど。これだけのデータを本社で使わないのはなんかもったいないなあと思ってしまいます。

受注情報は、受注（売上の早期把握）として重要なデータであることは間違いありませんが、それに加え、顧客の嗜好を分析するために細かいデータも入力していくんですよね？それってほんとに本社が使わないのかな？売れている色やオプションなどを「特別限定車」とかで利用できると思うんですけど。車素人の私はそう考えてしまいます。

大分勝手なことをいっていますが、まあ、この時期にしては良くかけていると思います。でも、絶対合格したいならさらにレベルをアップしていく必要があると思うんです。そういう意味でアドバイスしています。

システムの目的と概要を良くリンクさせ、インパクトの強いシステム開発目的＋概要にしたら、採点者も乗ってくるとおもうんです。なんていうか・・・夢のあるシステム開発というか？

「最近は、顧客の嗜好も細分化（言葉がいまいちかも・・・）しており、たとえばRV車でも高級、アクティブ、ファミリーと多様化し、オプションもさまざまである。セールススタッフの顧客への提案を充実させるため、詳細データの蓄積＋セグメンテーション分析がこれまで以上に重要になってきた。そこでA社は・・・」という感じですか。

あくまで、経営に資するシステムを計画して、「私が、諸処の問題をクリアしていった」という態度がよいのではないでしょうか？アプリケーションエンジニアは、システム開発屋ですが、真のシステムの目的を理解しているべきです。（一般論として）真の目的があやふやで、よいシステムは作れないと思います。でも、このシステムは、本当にレスポンスタイムが目的だったのかも知れませんが。

ここまでは以上の感想を持ちました。では、次に・・・（以下次回）

２．システム化の問題点
私は既存システムのデータベースを元に、データ中心アプローチ技法を使用し、新論理モデル及び新物理モデルを作成し、受注情報を管理する3つのテーブル（受注基本情報、受注詳細情報、受注オプション情報）を作成した。その際、以下のような問題が発生した。
(1) 受注管理情報サブシステムの問題点
　受注管理サブシステムでは顧客要求によりデータ入力のターンアラウンドタイムに10秒という制約が設けられていた。私は、新たに作成したデータベースに対しプロトタイプを使用した試験を実施した。その結果1件単独での処理では問題が無いが、入力が集中する月末を想定したテストにおいては12秒かかることが判明し処理効率の悪化が問題となった。これは、正規化されたテーブルのうち受注オプション情報を追加する処理に予想以上の時間がかかっていることが原因であり、およそ1件の受注情報に対し5件程度のデータであるが、入力の集中する月末時には何百件もの追加データが発生するためである。
(2) 月次処理サブシステムの問題点
　月次処理サブシステムでは営業スタッフ別の集計処理結果を情報提供する。しかし、営業スタッフ情報を有する人事サブシステムではリアルタイムに人事異動、退職などの情報が反映されるため、月末時点ではすでに人事情報が反映されている可能性があった。その為、月末時の人事マスタでは正確な営業スタッフ情報が得られず、データ管理部門の相違による統合の日現実性が問題となった。

　なぜ、データ中心アプローチを使ったのでしょうか？データ中心アプローチは一般的にデータの共有化に向く、変更につよいと言われています。反面、デメリットとしては、データ標準化が面倒、データ管理が面倒といわれています。機能中心、データ中心のどちらかを選択するには理由があるはずです。当然、問題では「データ中心」を問われているので、「データ中心アプローチを採用した。」というのは○なんですが、説得力がある理由がないと、採点者から「とりあえず、点数を上げたいために書いている見透かされます。

前回に指摘した通り、このシステムが、営業所のスタッフや本社スタッフが分析用にも使う目的が前面に出れば、当然データの標準化が必須なので、「データ中心アプローチ」の価値があります。

また、このシステムが、「機能の統廃合が激しい」特徴をもっていれば、「比較的安定しているデータ構造に着目して「データ中心アプローチ」を採用した。」と書けると思います。

このシステムは、どういう特徴があるのか分かりませんが、データ分析を前面に出すなら以下のイメージで書けばよいでしょう。

　このシステムの目的の１つに販売促進、新商品開発用分析がある。したがって、データ利用者がデータを取り出し易くするためには、データの標準化が必須であった。このため、私はデータ中心アプローチを使うこととした。データ中心アプローチは標準化、以降のデータ管理に手間がかかるが、今回の目的達成のためには必須であった。そこで、データ管理者を設け、ルールを作成し、徹底することにした。

　まあ、アンダーラインの部分までしつこく書かなくてもいいと思うのですが、もし、字数を増やすのに自信がないなら、これくらいしつこく書くのもいいでしょう。次にターンアラウンドタイム10秒の件ですが、10秒の制約で12秒かかることがそんなに大きな問題なんでしょうか？確か目標数値は大事ですが、2秒はネットワークの負荷やCPUの状態によっても左右されてしまう数値です。このシステムが人命にかかわるもの、2秒の違いが大きな損失に繋がるもの、顧客の目の前で入力し、結果を顧客に伝えなければならないものなら納得するのですが、記述を見る限り、スタッフが受注情報を1日のどこかでまとめて入力すればよいようなそんなシステムだと思います。それで、2秒の違いで問題なのかな？と思ってしまいます。

実際そうなら、もうちょっと誇張して、10秒の制約のところ、20秒近くかかったと記述したらどうでしょう。10秒に対し20秒ならだれまが、「ああ、チューニングが必要だな」と考えると思います。そうすると、面倒な説明も要らず、「だから、正規化を崩す必要があったんですよ。」とスムーズに繋がるのではないでしょうか？

それともう一つよく分からないことがあります。

　月次処理サブシステムでは営業スタッフ別の集計処理結果を情報提供する。しかし、営業スタッフ情報を有する人事サブシステムではリアルタイムに人事異動、退職などの情報が反映されるため、月末時点ではすでに人事情報が反映されている可能性があった。その為、月末時の人事マスタでは正確な営業スタッフ情報が得られず、データ管理部門の相違による統合の非現実性が問題となった。

　いいたいことは分かります。月末時点では、人事情報は最新分しか保有していない（常に最新分に更新されるよね、マスタは普通）ので、月中で異動したスタッフのデータが正しくその営業所のデータとして把握できないということですよね。

これは、どんなシステムでもあたりまえのことです。でも、そのことが「データ管理部門の相違による統合の非現実性」というのは、「ちょっといいすぎ？」と思います。

もし、そうなら、世の中の全てのシステムは統合の非現実性を持ったシステム」になってしまいます。一般的に、人事情報、組織の情報は集中管理されているのが普通ですよね。他のシステムで人の情報や組織の情報を必要とす時は、それらのシステムから連動してもらったり、直接データベースを参照するのが普通です。今回しげさんが問題といっていることは、午後�Tの問題などでしばしば出題されるようなことです。多くの場合、簡単な対処で対応できます。正規化をおおきく崩す理由ではないと思います。

確かに、データ管理部門は相違しているでしょう。でも、非現実性と言い切ってしまうと採点者が「えっ？」と思ってしまうと考えられます。「データ管理部門の相違による統合の非現実性」は、もっと生々しくどろどろした理由があってはじめて成立するのかなと思います。

たとえば、ある会社に大きく２つの系列（A群とB群）のシステムがあり、それぞれ２つの組織がデータ管理をしているとします。それぞれは問題なく稼動しているのですが、そのA群を組替える必要があったとします。せっかくだから、データを標準化をしたいと考えますが、B群は膨大なシステム変更が発生してしまうようなケースです。また、A群はリアルタイム更新ですが、B群はマンスリーでゆっくり更新すればよいケースなどもそうかも知れません。そういう場合、データベースを全て正規化してつくりかえることよりも、違う方法（B群のデータの参照用DBを作成し、データ連動して、日次で更新する。結果的に２重データ管理となります。）の方が現実的だと考えられますし。

非現実という言葉はかなり重々しい言葉です。簡単には解決できず、コストや労力が多くかかり、経営判断で「無理だ」と思うようなケースに始めて適用できるものなあと思います。（以下次回）

３．問題点の解決策と採用理由

(1) 受注管理サブシステムの解決策と採用理由
私は月末に集中する入力処理の処理時間を短縮すべく、データベースの見直しの実施と、オプション部品の発生件数調査を顧客に依頼した。これは、新物理モデルでは、大量に発生する受注オプション情報の追加処理に時間がかかっており、追加処理のトランザクション回数を削減することで処理時間の短縮が図れると考えたからである。その結果、1件の受注データに対し、平均で5件程度の受注オプション情報が発生することがわかった。私は、別テーブルとして保有していた受注オプション情報を受注基本情報に5件まで保有できるように非正規化を行い、受注入力時に平均7回発生していた追加トランザクションを平均2回に削減することが出来た。その際、6件以上発生した受注オプション情報は別テーブルに保有することで対応させ、12秒かかっていた月末時の処理も平均9秒にまで短縮することに成功した。

次に解決策を検討しましょう。

・・・データベースの見直しの実施と、オプション部品の発生件数調査を顧客に依頼した。これは、新物理モデルでは、大量に発生する受注オプション情報の追加処理に時間がかかっており、追加処理のトランザクション回数を削減することで処理時間の短縮が図れると考えたからである。

考え方や動きとしては○ですね。ただし、細かいことを言うと、「・・・データベースの見直しと・・・を顧客に依頼した。」とありますが、「データベースの見直しを行うために・・・・を調査した。」と書いた方がスムーズに読めます。

「調査する前にデータベースの見直しを実施？何を実施したんだろう？」ということになるかもしれなので。あと、「顧客に依頼」とありますが、実際には顧客に依頼するのでしょうけど、「自分が調査した。」と書くべきです。顧客に依頼することも調査の一環ですから、特に顧客にやってもらったと書かなくてもいでしょう。もしどうしても顧客を絡ませたいのなら「私は顧客の協力を受け、・・・・調査を行い、その結果を元にデータベースの見直しを行った。」と書いてください。あくまで、ご自身が主体的に動いて問題を解決していくスタンスがよいです。

私は、別テーブルとして保有していた受注オプション情報を受注基本情報に5件まで保有できるように非正規化を行い、受注入力時に平均7回発生していた追加トランザクションを平均2回に削減することが出来た。その際、6件以上発生した受注オプション情報は別テーブルに保有することで対応させ、12秒かかっていた月末時の処理も平均9秒にまで短縮することに成功した。

正規化方法としては分かり易くてよいです。6件以上は別のテーブルにするのもよく考える手ですね。これでいいと思うのですが、こういう非正規化を行ってしまうと、データ分析時に扱いづらくなるんです。あなたは経験ありませんか？採点者のレベルは高いと思うので、以下のようなことを書いておけるといいのですが・・・・・・

「このような非正規化を行った場合、更新処理時間の問題は解決されるものの、データの取り出しが困難になることが予想された。このため、私は、オプション関連のデータ分析用にこのテーブルを加工することとした。オプション部品の分析用テーブルはデイリーバッチで作成することにした。これにより、更新時間もユーザーの利用も解決することができた・・・

ここはこんな感じですね。では次に（以下次回）

(2) 月次処理サブシステムの解決策と採用理由
月次処理サブシステムでは入力された受注情報の内営業スタッフコードより人事サブシステムの人事情報を取得する機能であった。しかし、正確な情報が得られないため、私は受注基本情報テーブル内に営業スタッフ情報を盛り込むように新物理モデル及び受注機能の変更を行った。これらの変更を行うことにより受注情報入力時点での営業スタッフ情報が取得可能であり、受注に対する営業スタッフ情報は移行の変更処理が発生することが無いため、機能要件を満たすことが出来た。しかし、重複して人事情報を保有することはセキュリティの面から問題があると考え、機能の変更と同時にセキュリティの確保を行う必要があった。私は、この問題を解決するために�@ファイアウォールを設け外部へのデータ流出を防ぐ。�Aデータベース（月次処理自体）へのアクセスに各営業所の課長職以上のアクセス権限を設ける。�B不要となった受注情報、月次集計結果は毎月外部媒体へのバックアップ取得後早急に削除することとし、セキュリティの確保を行った。

４．新物理モデルの評価と今後の改善点
(1)新物理モデルの評価
　今回作成した新物理モデルは月末に処理が集中することや人事情報が得られないなどの問題を解決した上で、現在でも無事に稼動している。レスポンスタイムについても当初計測した時間より遅くなることは無く顧客要求を満たした新物理モデルとなったと思われる。
(3) 今後の改善点
　今回のシステムではシステムのスリム化とレスポンスタイムの向上が目的であり、不要機能の削減やデータ保有の見直しである程度は改善したが、複数台のサーバ機の設置やデータベースの分散保有などの水平負荷分散、垂直負荷分散を利用したシステム改善が今後の課題であると思われる。

ではつぎに・・・

重複して人事情報を保有することはセキュリティの面から問題があると考え、機能の変更と同時にセキュリティの確保を行う必要があった。私は、この問題を解決するために�@ファイアウォールを設け外部へのデータ流出を防ぐ。�Aデータベース（月次処理自体）へのアクセスに各営業所の課長職以上のアクセス権限を設ける。�B不要となった受注情報、月次集計結果は毎月外部媒体へのバックアップ取得後早急に削除することとし、セキュリティの確保を行った。

重複して人事情報を保有することはセキュリティの面から課題があると主張してますね。でもちょっと待ってください。問題からキーワード抽出はいいのですがちょっと出題者の意図と違うようです。出題文では・・・

反面、重複データの保持やデータベースの統合は、データの整合性やセキュリティの観点から問題となることが多い。したがって、これらの相反する要求を満足するために、非正規化するデータの選定や方法には十分な注意を払わなければならない。

と書いてあります。つまり、

重複データの保持・・・データの整合性に問題があることが多い。
データベースの統合・・・セキュリティの観点から問題となることが多い

といっているんです。しげさんが、重複データが発生したと主張するなら、整合性をとるのに苦労したので、こういう対策を考えたという主張をすべきなんです。ここでの模範解答は、もしデータ重複なら、「参照系だから問題ないんです」。みたいなことをと書けばいいしデータベース統合でセキュリティに問題なら、ファイアウォールでなく、「ユーザーヴューを使った」とすべきでしょう。

設問ウはこんな感じでいです。
ということで、診断結果を言います。

�@文章（論述）は上手いです。
�Aアウトラインもいいです。
�B字の綺麗さ、読みやすさは分かりません（電子データなので）
�Cキーワードの取り入れ方もいいです。
�D課題は、問題文の読みこなし方かな。

ここで指摘されたことをよく理解し、後5回くらい書けば合格できると思います。
厳しいことを言いましたが、この時期でこれくらいかければいいと思います。
ちなみに、私は平成10年秋に合格しましたが、3ヶ月前にプロの先生に見ていただいたときは散々でした。でも大丈夫。かならずかけるし、合格論文になります。頑張ってください。

（NAOKI先生の診断）

予告とおり、昨年の患者で見事合格したNAOKI先生の見立てを照会します。ではNAOKI先生お願いします。

しげさん。初めましてNaokiです。

論文読みました。
全体的には良いのではないでしょうか。

特に構成面では、
全体システム概要
　↓
問題１
問題２
　↓
工夫と解決１
工夫と解決２
　↓
反省点

と王道をいっており
「問題１の解決はどこへいってしまったの？みたいなことがなく」
よくまとまっています。

私の去年の今ごろのとは比べ物にならない良い論文だと思います。
（意味不明、支離滅裂な論文が得意技だったので）

ですが．．．エーロンホームページの卒業生としては、
「絶対合格」の太鼓判は押せません。

初めての診断なので少々荒療治になるかもしれませんが、
私なりに診ていきます。

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
［診断（若葉マークつき）］

しげさんの論文から設計部分となる人体でいうなれば「骨」のみを抜いてみます。

＜しげさん論文の骨＞
設問ア
１．システムの目的と概要

�@大手自動車販売の営業所からのオンライン処理をＣ／Ｓへ再構築する。

�Aシステムのスリム化およびレスポンスタイムの向上を計画

�B受注データは大量

�C受注データは経営戦略資料として役立てる予定。

設問イ
２．システム化の問題点

�D受注データが受注明細も含めると大量のデータとなり、
10秒の目標が12秒になってしまった。

�E月次処理サブシステムの人事情報がデータ管理部門が異なるため
上手いこといかない。

３．問題点の解決策と採用理由
�F受注明細データを受注データに繰り返し項目として持たせ、更新回数を減ら
すことで、9秒にまで短縮することに成功。

�G月次処理サブシステムはセキュリティの問題をはらんでいたが以下の対策
でセキュリティ確保
・ファイアウォール
・データベースへのアクセス制限
・不要となった受注情報、月次集計結果は毎月外部媒体へバックアップ
設問ウ
４．新物理モデルの評価と今後の改善点
�HレスポンスもOK、人事情報が得られない問題は解決。

�I複数台のサーバ機の設置、分散データベースの改善が今後の課題である。

では、骨をポイントに読み進んだ感想を書きます。

設問ア
�@�A�B�Cでは、
ああ、Ｃ／Ｓ開発とレスポンス対策をしたいんだな。
受注情報がメインですね。
データは経営戦略に利用されるってことだな情報系データベースの非正規化なんかが
でてくるのかな？ワクワク。

設問イ
�D目標10秒で繁忙期に12秒だったら、もう少しじゃないかお手並み拝見といこう。

�E受注情報になんで社員の人事情報が必要なんだろう？

�F受注情報の書き込みを5件とではなくて10件くらいにしたらもっと短くなるのでは．．．
それにしても12秒が10秒目標で9秒になった、
うーん、実際の数字を挙げてくれたのはいいけど、
ネットワーク負荷でどうとでも転がってしまう可能性のある数字だな。
押しとしては弱いですね。

�G　�Eの説明もよく分らなかってけど、ここの説明もよくわかんないな〜。困った。

ファイアウオールってインターネットと社内システムの間において社内ネットワークを守るもののはずなのに、なんで社員からのアクセスを警戒してるのかな？

データベースへのアクセス制限を人事異動ごとに付け直すのも大変だろうロールとかで部門ごとにアクセス権とか与えてはどうだろうか？

結構短い周期でデータを削除するんだな。取り出すのに不便にならないのかな？
それとも、ある時期を過ぎると、あまり使わないデータなのかな？うーんわかんない。

それにしても、営業部門と人事部門の共有データの関係が良くわからなかったな〜。

設問ウ
�Hは解決の内容の繰り返しですね。
�Iは複数台のサーバを置いて負荷分散したい「えっ気づいてるならば、更新系処理のパフォーマンス向上に大いに役立つのに」なんで今回やらなかったんだろう。
あれ、経営戦略の話は結局でてこなかった。残念。

「うーーーん。」

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
［診断結果］

しげさん気を落ち着けて聞いてください。
論文を診断した結果は、

（１）問題に引っかかりそうなキーワードが並んでる。

（２）更新処理の非正規化、部門間のデータについてのデータ中心アプローチについて
　　　掘り下げ不足のため不明点が多い。
　　　ドクターエーロンの診断にも同様のくだりがありましたね。

（３）設問ウは基本的に無いものねだり的なエンディングです。
　　　例えば試験管が、「ままそこまでやらなくても君〜。なかなか向上心があるやな
　　　いか」と思わせることです。
　　　ですから、今やれそうなことは今後の展望としてはＮＧです。

一番考えて欲しいことは（２）です。
論文の主張点であるここの骨が細いッス。
「骨粗しょう症ですね（冗談）。」

骨さえしっかりしていればかなり良い感じになると思いますよ。

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
［処方］
ここで問題に立ち返ってみたいと思います。

企業全体での情報化にはデータ中心アプローチが有効です。
データ中心アプローチでは正規化されたデータを扱うのが一般的です。
しかし、時には正規化、非正規化を取捨選択することも考えなければいけません。
更新処理や検索処理について正規化、非正規化をあなたはどう考えどちらを選択しましたか？一般的には正規化しますが、非正規化することも時には有効です。
非正規化するデータの選定や方法について納得する理由を添えて書いてね。

と問われています

しげさんが経験した実務のことはとりあえず置いといて、
次のＱを自問し原点にかえってみてください。

Ｑ１．データ中心アプローチはどんな場面で行われどんな効果を期待するものでしょう？Ｑ２．正規化、非正規化をするのはなぜでしょうか？またどんな場面でしますか？
Ｑ３．更新系・参照系処理と正規化・非正規化の関連はどうなっているでしょうか？

そしてご自分の論文を読み返してみてください。
骨太にしてみてください。

またエーロン氏もおっしゃているように、この問では参照系処理に焦点を当てたほうが
勝算は高い、書き易いと思います。（私も参照系処理のパフォーマンスと導出データ項目を含んだ非正規化を題材に書きました。）
無理にではありません。更新系でもいけると思いますので掘り下げるのもひとつの方法です。

色々偉そうなことをいってすみません。
若葉マークつき診断ですので、参考程度にお願いします。
「しげさん！お大事に、期待してます。」　では

　　　　　　　　　　　　
　　　　　　　　　　　　論文治療クリニック（番外編）三連星氏のお小言

エーロンのページに遊びにきてくれる三連星さんがしげさん論文にコメントしてくれましたよ。三連星さんは辛口ですので、ためになるお小言が聞けますよ。では、どうぞ・・・・・・

エーロン様

こんばんわ　三連星＠技術士建設部門の患者（長期治療中）です。

現在俎板にのせられているシゲさん（経験年数10年）の論文ですが、
私の見立ては、「視野狭窄症」です。
システムの一部を担当したにもかかわらず、システム全体とのかかわりについて
触れられていません。

槍玉にあげるのは設問アとウです。
設問イは、パス。（私は、ＤＢは苦手だからなあ。）

設問アを私が書くとこうなるかな？
．．．．：．．．．１．．．．：．．．．２．．．．：
１．システムの目的と概要
(1) システムの目的
　Ａ社は大手自動車販売会社であり、本社および５０の
営業所がある。社内の基幹システムは大型汎用機による
オンラインシステムを使用しており、売上販売管理・人
事管理等に利用している。昨今の社会情勢の変化により、
顧客の嗜好も多様化しており、販売オプションの種類が
大幅に増加している。セールススタッフの顧客への提案
を充実させるため、詳細データの蓄積およびセグメンテ
ーション分析がこれまで以上に重要になってきた。そこ
で、汎用機の老朽化による更新の際に、経営戦略を立案
するために受注情報を多元的に解析する機能を追加する
ことにした。あわせて、売上販売管理システム・人事シ
ステム等が各々独立してデータを使用していたのを改め、
データを一元管理し統合することで多角的に分析できる
ようにシステム変更した。
(2) システムの概要
　システム全体は、受注情報入力・経理・人事・在庫管
理・月別売上集計・経営分析の各サブシステムで構成さ
れている。本システムの特徴は、受注情報にオプション
部品等の詳細情報が多量にあることがあげられる。今回
の仕様変更は、データ構造の見直し、月別売上集計サブ
システムにおいて任意のタイミングで集計可能とするこ
と、営業スタッフ別の集計、および経営分析サブシステ
ムの新設である。
(3) システム開発に間する私の役割
　ソフトウェア会社のＳＥとして、受注情報入力および
月別売上集計サブシステムの開発を行なった。またデー
タ構造の見直しは、私を含む各サブシステム開発責任者
が合同で行なった。
 (25×30=750字)


○文章のコメント

設問ア
(1)文章の長さ
　原文は、ピッタリ800字(=32行)です。本番でこのとおりに書いたとすると、漢
字を忘れてひらがなで書いただけでうっかりすると行数がオーバーし、沈没しま
す。(32行オーバーは厳禁です。)最大字数に対し、８割程度(=650字、２６行)書
けばそれで良いのです。そして、
・箇条書き
・章が変われば１行空白行を入れてしまう
・図表で埋める（ポンチ絵で良い。入れるなら細部にこだわらずなるべく簡単に
書く。そうしないと、文章で埋めるのより時間がかかってしまう。）
という手段で行を稼いでしまうのもアリです。
って、私のヤツも30行あるから長すぎる、かな？　でも、(3)を設問イの初頭に
持っていくという手も使えるので、800字オーバーになる恐れはありません。

(2)目的
「レスポンスの改善」だけで、一般会社がシステム改良を行なうのは考えにくい
のでこちらをシステム更新理由としました。「レスポンスの改善」なら、前フリ
として、「オプションの種類と数が当初予想より大幅に増えた」「データ入力追
加項目を増やすという小改良を数回ほどこしたためレスポンスが悪化した」のよ
うな理由が欲しいところ。
細かいことですが、「複数の営業所と本社」でなくて、
「本社と複数の営業所」です。
また、営業所数を概数で良いので示す必要あり。

(3)システム概要
システム概要は、全体構成を示す必要があるのにそれが抜けています。

(4)その他
私の文章では、クラサバでなくて汎用機システムになってしまいますね。
分散データ配置を話題にしているわけでないので、まあいいか。
新旧とも汎用機システムで押し通すか、旧システムもクラサバだったことに
してしまうか、いずれかがbetter、かな？

設問イ
＞経営分析について書かれていない
という意見もありますが、そのサブシステムにはタッチしていないことでクリ
ア。

設問ウ
原文で可もなく不可もなし、といったところでしょうが、
ここで書くのは、
１．サブシステムの問題解決のための変更点が、システム全体にどのような影響
（プログラム開発に対する困難さ・レスポンス・ファイル容量等）を及ぼしたか
２．今なら（＝技術の進歩等を考慮して。）どうするか
ではないのでしょうか。
　特に、今回の目玉は第一正規化崩しだから、入力サブシステムにとどまらず経
営分析サブシステムに大きく波及するはずです。だから、あの改良法で良いのか
どうか部分的手法としてもひっかかりますが、システム全体からみた考察が加え
られていないのは？？？です。


長々と書きましたが、私自身は高度はゼロ勝だし、論文をデッチアゲるのもメン
ドイ（ダムの設計では、どんなに間違ったことが起きてもダメだあ.....）の
で、今回も論文は技術士以外は敵前逃亡です。

では。

３人の人間からコメントしましたが、大体、ポイントは一緒だったと思いますよ。３人が見て３人によいといわせれば大体合格論文になりますよ。ぜひ、がんばってくださいね。