システムの分析と設計の力を養うレポートの作成

：1999年度情報システム特論での実践

上智大学　理工学部　機械工学科

情報システム講座　

伊藤　潔

1999年8月5日

　　この３年ほど，理工学研究科博士前期課程での情報システム特論の講義について，その進め方，レポートの出し方について，受講生のシステムの分析と設計の力を養うよう，新しい実践を行っている．すなわち，受講生各自がそれぞれ提案する情報システムを対象システムとして，その分析や設計に，講義で習った内容を使っていくことを毎回行う．

＜自分が展開する対象システムの提案＞

　まず，講義の第１回目のレポートとして，各自これから展開する対象システムを挙げさせる．

＜１９９９年度の第１回目の課題＞

　産業用あるいは社会用Application（例えば，計測制御システム，生産管理システム，交通管制システムなど）を1つ挙げて簡単なスペックを示す(10行程度)．

　◎ビジネスapplication（銀行システム，座席予約システムなど）は，対象としない．

　◎単一のコンピュータのみからなるのではなく，複数のコンピュータからなる分散システムであること（どのような分散システムかを明示）

　◎研究で使っている実験装置／システムでも可

　◎今後，ここで各自が提案したシステムをもとに毎回のレポートを作成する．

　◎このシステムは，今後の作業のためのたたき台であり、細かいスペックは後の作業中に決定・変更しても構わない．

　◎過去のレポートや他人のレポートを写した場合，即刻，受講不可．

　◎電子メールで添付ファイルも活用する．

＜毎回の講義＞

　講義は，情報処理に関する基礎的ではあるがかなりしっかりした本を使う．ソフトウェア工学やシステム生産技術の教科書ではない，普通の情報処理の本である．これをできる限り多く説明する．試験をするわけでないから，覚えることを強制しない．

＜毎回の演習＞

　毎回の講義の残り１５分程度，その講義で得た内容に基づいて時間内の簡単な演習を行う．講義内容に即していれば，講義を聴いていれば，あるいは講義と少し距離があっても，想像力を働かせれば，自分で解ける演習である．

＜毎回のレポート＞

　第１回のレポートで提案させた対象システムを様々な角度から分析・設計させる．毎回，システム構成，構成要素，システム内外のデータ／信号，データベース，要求分析，設計，プログラム構造などについて，講義で説明している教科書の内容に関係付けて展開させる．但し，その日に習った講義の内容を全て利用するわけではない．そのレポートに何が必要であるかを判断するのも重要な訓練である．

　電子メールの添付ファイルで圧縮して提出させる．評価結果は限定の利用のWebに貼り出した．この辺のリテラシも副次効果として各自，身に付いたと思う．

　このレポートで，過去のレポートや他人のレポートを写した場合，即刻，受講不可とする．さらに，レポートの書き方も独自性を要求している．内容も表現も，各自のオリジナリティを求める．この辺を曖昧にしておくと，著作権などに決してsensitiveになり得ない．

＜学生の負担＞

　ここまで書いてくると，受講生の負担はどうなるか，という声が必ず聞こえてくる．結論を言えば，負担はかなりのものである．それは構わない．受講生のためである．教員の負担，これもかなりのものである．しかし，教員としては，受講生が様々な答えを書いてくるので極めて興味深く読めるし，こちらもいろいろな物の見方を再認識できる．電子メールによる提出なので，出張先でも読める．今年は，講義をした次の日から，米国出張が一度あったが，出先のテキサスでレポートを興味深く読み採点評価した．

　講義で試験はしないから，知識の詰め込みは不要なので，負担は軽いと私は思う．しかしながら，いかんせん，受講生は，小学校以来，偏差値と試験の幾多の難関を経てきたのだから，試験で知識を試される方がむしろ楽と思う人が多いのかもしれない．人によっては，ある種のカルチャーショックを感じる可能性がある．習った知識を如何に活用するかを，演習とレポートで訓練されようとするのだから，やはり負担はかなり大きい．それでいいと思う．

　毎回の演習については，その内容よりも演習の存在自体がかなり「負担」であろう．内容により◎○△×が付くし，そもそも，毎回出席しなければならない．この形態の演習がなくて毎回のレポートだけ行なった年度もあるが，講義に来ないでレポートだけ出すという学生が，講義に受けている学生と同数以上だった．彼らが出したレポートは△×になる割合も多く，なぜ△×になるのかの問い合わせや質問も，講義に出ないこの学生達から多かった．これはいただけないし，私の講義の趣旨に合わない．1999年度は毎回の演習も課した．この演習の内容が実は，毎回のレポートを書く上でジワリと効く内容にしている．当然レポート提出のみという学生は来なくなった．受講生の負担はかなり大きい．でもそれでいいのではないだろうか．

　毎回のレポートの負担，これはかなり大きい．提案させた対象システムを各自が様々な角度から分析・設計する．提出後１～２日で，内容を評価して◎○△×が付く．どれとして同じレポートは存在しない．これがかなりきつい．でもこれが学生にとって一番ためになると私は確信している．

＜講義の趣旨＞

　毎回の実習やレポートを含めた，この講義の趣旨を次のように考えている．

１．情報処理の勉強は，知識偏重ではなく，具体的な事物やシステムに思いを巡らせて進めることが，結局よい理解につながる．この講義では，できれば自分の身近にある，現実のシステムを各自の対象システムとして提案し，講義で基礎事項を習いながらそれが対象システムではどうなっているのかを各自で考えて，毎回分析・設計する．

２．ビジネスapplicationではなく，産業用／社会用applicationを対象システムとする．FAのシステムでもよいし，NC周りでも，衛星通信システムでもよい．受講生は，機械工学専攻と電気・電子工学専攻だから，情報専攻とは異なるが，システム応用分野を持ちやすい．彼らは，単なる入出力機器だけではなく，センサやアクチュエータも含む広範な機器をも情報システムの構成要素として，自然に認識できる．ビジネスシステムについては，様々な本で言い尽くされていると思われるので，興味ある課題が出にくい．

３．対象システムの分析や設計を講義で習った側面から行うが，その際にその教科書に解答が書いてあるわけでもない．また，参考書を調べて公式を見つけて計算してというタイプのレポートではない．

４．システムの分析・設計は解が必ず１つある問題ではなく，自分で調べて考えて答えを求めていく問題である．世の中のシステムの開発というのは，そのようなものでしょう．

５．対象システムが異なれば課題が同じでも答えが異なる．書き方も同じにはならないはずである．例えば，あるシステムの構成を記述せよというレポートで，対象が一緒だから，答えも書きようも他の人と大差がないのが成り行きなのだが，互いに似ているということになる．この講義では，このようなことを受講生に言わなくてもいいように，対象システムを各自異なるようにした．

６．最終のレポートで受講生が書いてくれたが，レポートの出来・不出来という判断基準はあっても，「これが理想のレポート」という基準はない．システムは多次元性を本来有するものである．多次元で100%の出来というのは，追求はすべきだけれど，本来，これらの次元での達成度にはトレードオフが存在する．それがシステムの設計の本質である．

７．システムを自分で分析・設計するプロセスの概要を学ぶ．そのシステムには何が必要であり何が問題なのかを各自深く考える訓練をさせたい．

８．これも受講生が書いてくれたが，レポートで、枚数を多く書けば良い評価を得られるような採点はしない．枚数は少なくてもそのレポートのアイディア（発想）をレポートの評価に反映する．また，レポートの書き方にオリジナリティがあることも重要な評価となる．対象システムが各自異なるから内容は自ずと異なる．この時もし書き方を真似ては，せっかくの内容も台無しである．

　1999年度は26名の大学院生（＋学部生１名のオブザーバ）が最終レポートまで提出でき良い成績を獲得した．システムに対する彼らのものの見方がきっと変化したと，私は確信している．大変な労力を必要とするレポートであったが，受講生には，システム分析と設計を楽しんでもらえたでしょうか？同等の人数の院生が受講を断念したのは，返す返すも，残念である．

　この講義での以上の進め方を今後も続けたいと考える．

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