プログラミング教育における構造化チャートの再評価
川島 秀樹 *
* 保健医療経営大学 教授 , 博士（経済学） E-mail：[email protected] ＜研究ノート（Research Note）＞要 旨
2008 年から新設大学で情報処理関連授業を行っている．学生に論理的な思考能力をつけさせるには，プログラミング の授業が適しているが，ゆとり教育の影響や文系大学のプログラミング軽視などによって，難しいと感じる学生が増えてい るように思われる．企業の新人教育と違って，学生は将来プログラマやＳＥになるという明確な目標を持っている訳ではなく， プログラム理解に重点を置く授業方法に変えることにした． プログラミング教育で実践したのは，「プログラム仕様書をきっちり書かせて理解させ，プログラム・ソースのコーディン グ作業を進めた」ことである．そのために構造化チャートを利用し，その中でも日本電気の SPD や情報処理試験で利用 する擬似言語を用いた．授業アンケートの出席カードを用いて評価状況をみると，授業の内容変更（仕様書の書き方を理 解させること）によって，楽しい，理解できると感じた学生が増加していること実感した．以上からプログラミング教育にお いては，ドキュメントの作成能力や表現力を養成し，構造化チャートを利用することが効率的であると思われる．最後に， 擬似言語表記を使った構造化仕様書の提案をしている． Keywords：プログラミング授業，構造化手法，SPD，擬似言語，UML． はじめに 2008 年に開学した保健医療経営大学で，学生に情報 処理関連の授業を行っている．本学は久留米の聖マリア 病院が設立した新設大学で，医療の経営マネジメントス タッフを育成することを目的とし，医療や経済・経営は もちろんのことＩＴにも精通した情報基礎教育を実施し ている．授業科目は表１のとおりである． 文系学部であるために，情報系学部と比べると専門演 習を除いて基礎的な授業が主体である．しかし，設立時 にプログラミングの授業を２科目導入したのは，学生が 病院などの医療機関に就職後，必ずシステム導入の仕事 を経験するので，プログラミングの基礎を理解すれば， システムの要求定義，システムテスト，システム運用が 楽になるという考えからである． 学生に論理的な思考能力をつけさせるには，プログラ ミングの授業を履修させるのが適していると思われる． 表１ 保健医療経営大学 情報処理関連科目 ・情報処理入門（ＰＣ演習） [30]（必修） （Windows,Word,Excel,PowerPoint,Access,HPB） ・コンピュータ概論（ＩＴ基礎） [15] ・プログラミング基礎Ａ（ＶＢ ） [15] ・プログラミング基礎Ｂ（Ｃ言語） [15] ・情報科学Ⅰ（基本情報技術者養成）[15] ・情報科学Ⅱ（基本情報技術者養成）[15] ・医療情報学（医療情報技師養成） [15] ・経済工学（データ分析の基礎） [15] ・基礎演習（プレゼンテーション） [15] ・専門演習Ⅰ（Excel VBA） [15] ・専門演習Ⅱ（DB，アルゴリズム） [15] ・専門演習Ⅲ（NW，システム分析） [15] [n] は授業のコマ数1．授業での問題 大 学 2 年 生 対 象 の プ ロ グ ラ ミ ン グ 基 礎 Ａ（Visual Basic）の授業を 2 年担当して，過去に経験がある企業 の新人教育との違いが次第に明確になってきた．大学教 育の場合 1 コマ 1.5 時間の 15 回で 22.5 時間，企業の新 人研修（日本ユニシス）の場合，言語 COBOL の習得に 1 日 7 時間の 12 日間で計 84 時間の集中講義が行われた． 言語は違うが，どちらもプログラム初心者を対象にし ている．新人研修だと将来プログラマやＳＥを目指して いるのに対して，学生の場合将来何かに役立てようとい うケースが多い．それに，プログラミングは難しいとい う思い込みが最初にある．学生に授業をしながら，以下 の三点に特徴があることがわかった． 1）ゆとり教育の影響 2002 年からのゆとり教育の影響で，小・中学校の教 科書で算数・数学の基礎事項を理解しないケースが増え た．たとえば 2 進数の計算は，「桁の繰り上げ処理」を 理解することであるが，そういった基礎力が不足してい ることがあげられる．高等学校においても，数学Ⅱ B， 数学Ⅲ，生物，化学，物理などの理科系科目を取らない 学生が多くいる．これによって論理的能力を身につけな い学生が増え，情報処理関連の選択授業を敬遠する傾向 にある．選択授業でも，プログラミングのアルゴリズム を理解できない学生が 10 数年前と比較すると増えてい る． また，全般的に生活が豊かになるにつれ，学生にハ ングリー精神が無くなってきていることもあげられる． 20 ～ 30 年前では，ゲームなどのプログラムを開発して 億万長者になりたいという学生が，どこの大学にも数名 いたと思われる． 2）プログラミングの軽視 パソコンのビジネスソフトが登場し始めた 1980 年代 後半に比べると，マイクロソフトの Excel や Access が 相当に充実したことにより，プログラミングを行って， 昔ながらのデータ処理を行うことが少なくなった．その ため，文系の大学において，コンピュータの授業が少な くなっている．表 2 は九州地区経済・経営・商学部系の 主要大学の情報処理関連授業を各大学のホームページ・ シラバスより調査したものである．（一般授業：○，ゼミ： △） 大学ゼミでの授業実施を除いて，プログラミングの授 業を行っているのは約 28%であった．アルゴリズムな どのプログラム設計を教えている授業はほとんどないこ とがわかる． 文系大学の学生は，パソコン操作ができれば，情報処 理をマスターしたと考える傾向にある．表 2 からも，ほ とんどの大学で情報処理操作の授業（ＰＣ演習など）を 行っている． 授業で 16 進ダンプツールを使った採取方法を教えた ら，「それが何をするのか」と学生から質問されたこと があった．プログラミングを学んでいる学生だったら， ファイルを作成したときに中身をみる最良のツールであ ることが理解できると思われる． 表２ 九州地区主要大学プログラミング授業 ３）テキストの例題を打ち込むだけで満足 ここ 2 年間の授業で最も多かったのが，テキストの例 題を，そのままソースに書き込み実行するパターンで ある．テキストの付録のソースをダウンロードできる Web サイトもあるので，要領の良い学生はそれをダウ ンロードし，コピー＆ペーストする始末である． しかしながら，ロジックや使用するシンタックス（文 法的な規則）の意味を十分理解することをしないで，「実 行結果が正しく出た」と喜んでいたのでは，いつまでたっ ても上達しない．プログラム・ソースを考えながら打ち 込むという作業を面倒くさいという学生が増加したよう に思われる． ２．授業での実施内容変更 １）プログラム仕様書の書き方を理解させる 1 年目（2009 年度）は，企業の新人研修と同じような レベルで授業を進めた．文法的な規則をしっかり教え， NO 本学 Ａ Ｂ 学部 保健医 療経営 経済 法 （公共 政策） 経済 経済 法文 経済 経済 商 経済 商 経営 経済 商 経済 商 経済 商 情報処理 （操作） アルゴリズム プログラミング 科目名 1 2 3 4 Ｃ Ｄ Ｅ Ｆ Ｇ Ｈ Ｉ Ｊ Ｋ ○ ○ ○ × ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ △ × ○ VB2005C ／ C Java Java Java VB × × × × × × × × × × × × × × × × × × × × × ○ × × × × × × ○ ○ ○ × × 5 6 7 8 9 10 11 12
VB2005 入門テキスト（笠原 2006）に従って，文法をきっ ちり教えて，多くの演習問題を解かせた．そうすると，「た だ問題を解いて完成させればよいという学生が増え，ロ ジックの内容を理解できないままに，デバックしている のが目についた． そのため，2 年目（2010 年度）からは，プログラム仕 様書をきっちり書かせて理解させ，プログラム・ソース のコーディング作業を進めた．プログラム仕様書は，一 般的に用いられる構造化手法で，日本電気の SPD（遠 藤 1992）を使った．SPD 以外に有名なものとしてＮＴ Ｔの HCP，日立の PAD，富士通の YAC Ⅱなど（付録１） がある．これらは，日本工業規格に「プログラム構成要 素及びその表記法」として制定されている． ところで，こういった仕様書を Word などで記述する のに，一般的にフローチャートを使うのであるが，ルー プ処理がわかりづらいこと，条件文にさまざまな書き方 があることから，構造化チャートを使用した．また，処 理内容を図形（四角 , 菱形，丸等）の中に Word などで 書くのが好きでなかったので，SPD を利用したプログ ラム設計を学生に教えた．授業のおわりでは，SPD だ けではなく，情報処理試験に使われる擬似言語の記述形 式（付録 2）を用いて記述した．ただ，擬似言語は記述 にコードをそのまま書き写す傾向にあるので，少し細か すぎて学生にはわかりにくかったようだ．ロジックの中 では，繰り返しと条件分岐は極めて注視する必要があ る．それを解りやすくする為に SPD を使用したのであ り，できるだけ簡便に日本語としての意味が通るように した． 企業の新人研修では，プログラミングの前にアルゴリ ズムなどのプログラム設計を 3 日～ 5 日間（21 時間～ 35 時間）程教えている．本来は，大学でそういった講 座を開講すべきであったのだが，文系学部の一般授業で は不可能であった． ２）構造化手法の利点 構造化手法は，30 年も前から利用されている．花田 (2005) によれば以下の特徴を持っている．①データの構 造を階層的に記述する（データ構造）．②処理の概要と 詳細とを対応づけながら階層的に記述する（処理構造）． ③制御の流れを記述する（制御構造）．④データと処理 との関係を明記する．これらの特徴により，アルゴリズ ムを容易に理解することが出来る． ところが，Java や C# などの言語を使った場合に， オブジェクト指向設計手法を採用するので，データと 処理を分けて設計する構造化手法は時代遅れであり， データと処理をオブジェクトの中にまとめて考えるカ プセル化に馴染まないのではないかという批判（テク ノロジックアート 2010a）もある．オブジェクト指向の UML(Unified Modeling Language) は，要求定義や概要 設計の場合極めて有用であると考えられる． しかし，コーディング作業時に使われる「シーケンス 図」（図 1 参照，テクノロジックアート 2010b）は，繰 り返しと条件分岐の記述を簡潔・明瞭に表現することに 弱く，わかりにくいと思われる．また，詳細クラス図も 同様である． 図 シーケンス図例（チケット予約アプリケーション） 出典：テクノロジックアート 2010b
近年，杉浦他 (2005) はプログラム教育に HCP チャー トを使用している．その論文の中で，分かりやすい HCP チャートを議論することによって，プログラムを 制御構造から捉える思考だけではなく，プログラムを論 理構造から捉える思考を養うことができると述べてい る． また，プログラムの論理構造は，処理の目的をコメン トに記述し，目的別にまとめた処理をモジュールによっ て表現できる．これが人にわかりやすいプログラムに繋 がると述べている． ３．授業アンケートから １）出席カード 本学では授業終了前の 5 分間，今日の講義の復習のた めに，感動した内容や，質問事項，理解できなかった内 容を，A6 版の出席カード（図 2 参照）に書かせている． 学生が，難しかったと感じた場合，次の時間にフィード バックして再度教えている．こういった単純なことが， 学生との距離を縮めることになると感じている． ところで，2009 年授業の出席カード ( 受講者 8 名 ,55 件 ) と 2010 年授業の出席カード（受講者 8 名，109 件） を使って，その感想を表 3 のような内容（①楽しい②理 解できる③頑張りたい④エラー頻発⑤大変だった⑥難し い）に分類した．2009 年度は，出席カードに感想を書 かない学生や授業の履修取消をした学生（2 人）がいる ので，出席カードの件数は少ない． また，本学にＦＤ委員会の学生授業アンケートがある が，項目にオール 5 やオール 3 をつける学生が多いので， 恣意的で信用できない一面があり，それを利用しなかっ た． 図２ 出席カード 表３ 出席カード内容 図３ 出席カード内容 レーダチャート 表 3 の出席カードの内容（2009 年～ 2010 年）をみると， 楽しいと感じた学生が 16.4％から 23.9%へ，理解できる と感じた学生が 3.6％から 33.9%増加した．また，大変だっ たと感じた学生は 16.4%から 6.4%へ，難しいと感じた学 生は 43.5%から 22.0%へ減った． 図 3 のレーダチャートは，2010 年度からの授業の内 容変更（仕様書の書き方を理解させること）によって， 楽しい，理解できると感じた学生が増加していることを 明確に示している． ３）仕様書中心の授業展開の長所 仕様書中心の授業は，日本語の表現が豊かになり，目 的がはっきりし，理解することができる．多くの模範プ ログラムを読んで，構造化チャートに記すことによって， 相当の実力をつけることができた．また，処理パターン のアルゴリズムを理解できた． ４）仕様書中心の授業展開の短所 短所として，仕様書の書き方の時間を確保することに よって，授業が前年の 2/3 くらいしか進まなかったこと を挙げることができる．そのため，学生に解かせる演習 問題を削減せざるをえなかった． それに，学生は企業の新人研修のように精力的にプロ グラムが書けるわけではない．学生には，基本的なロジッ クを教えるのが精いっぱいで，情報処理試験の問題を解 くレベルが目標となってしまう．なぜなら，学生に授業 後居残りをさせて，じっくりとプログラムを完成させる 環境が少なくなっているからである． 出席カード内容 2009 年 2010 年 楽しい 9 16.4% 26 23.9% 理解できる 2 3.6% 37 33.9% 頑張りたい 5 9.1% 8 7.3% エラー頻発 6 10.9% 7 6.4% 大変だった 9 16.4% 7 6.4% 難しい 24 43.6% 24 22.0% 計 55 100% 109 100%
４．擬似言語表記を使った構造化仕様書の提案 情報処理技術者試験では，構造化プログラミングの定 着により，フローチャートではなく「擬似言語」が導入 されている．これは，「順次」「判断」「反復」の 3 種類 の構造を使用して，アルゴリズムを明確に表現したもの である．擬似言語の特徴として大滝 (2009) によれば，① コーディングしやすい文章で論理構造が表現できる．② 日常語の自由な表現で記述できる．③論理構造は構造化 定理に従うとある． 2 年目のプログラミング授業や専門演習では，SPD や HCP など一部の IT 企業が使っている構造化チャート よりも，情報処理技術者試験で採用している擬似言語 を使って，誰もが明確に理解でき，ワープロソフト等 （Word, 一太郎）にも記述しやすいようにした． まず，擬似言語の記述形式に SPD の記述形式を使う ことである．次に，処理記述においては処理の階層的表 現を重視し，「何をするか」それを実現するために，ルー プや振り分けなどの制御構造をまとめ上げた．階層の上 位レベルに「どのように繰り返すか」，「どうやって振り 分けるか」を記述した．さらに，プログラム・コードと の対応がわかりやすくなる程度に詳細化したら，そこで 詳細を止めることにした．必ずしも一つの処理が一つの ステートメントに対応する必要はなく，全体としての流 れがわかるようにした． 記述方法としては以下のとおりである． １）順次構造 命令の記述であり，「・」を先頭につける． ・処理１ ・処理２ ２）判断構造 条件を指定して処理を分岐する．条件には以下のもの がある． 「=」「>」「<」「>=」「<=」「≠」 ①二分岐選択 ②多分岐選択 ②後判定繰り返し処理 ③繰り返し処理 ３）反復構造 ①前判定繰り返し処理 擬似言語表記を使った構造化仕様書は，専門演習の授 業で活用している．SPD や HCP のように書き方を講習 しなくても，擬似言語問題の演習を解くことによってマ スターできる． また，ホワイトボードや Word などにも記述しやすく， 特に繰り返し処理が理解できたという意見が出席カード の感想文から確認できた． ５．結語 まとめと今後の課題 以上から，プログラムを教える時に，プログラム仕様 書の書き方を中心に教えるというのは，学生の興味や理 解度に大きな効果があると思われる．本来は，ドキュメ ントの作成能力や表現力を養成する必要があるのかもし れない．ここでは，プログラムの言語にかかわらず，そ ういった基礎力養成が授業で必要であると感じた． 今後の展開としては，構造化チャートを利用したスキ ルが，UML などのオブジェクト指向に有用であり，わ かりにくい日本語の文書表現に最適であることを明らか
にしたい． 付録 付録 １ 構造化チャート事例． 付録 ２ 擬似言語の記述形式 出典 : 日本工業規格 標準調査会 JIS 検索 「プログラム構成要素およびその表記法 〔宣言，注釈及び処理〕 記述形式 ○ ・変数 ← 式 ・手続（引和，…） 条件式 処理 条件式 処理１ 条件式 処理 条件式 変数：初期値，条件式，増分 処理 処理２ 処理 /＊文 ＊/ 説明 手続，変数などの名前，型などを宣言する。 単岐選択処理を示す。 条件式が真のときは処理を実行する。 双岐選択処理を示す。 条件式が真のときは処理１を実行し、 偽のときは処理２を実行する。 前判定繰返し処理を示す。 条件式が真の間，処理を繰り返し実行する。 繰返し処理を示す。 開始時点で変数に初期値（式で与えられる） が格納され，条件式が真の間，処理を繰り返 す。また，繰り返すごとに、変数に増分（式 で与えられる）を加える。 後判定繰返し処理を示す。 処理を実行し，条件式が真の間，処理を繰り 返し実行する。 手続を呼び出し，引数を受け渡す。 変数に式の値を代入する。 文に注釈を記述する。 処 理 参考文献 [1] 遠藤裕香，(1992),『構造化プログラム設計図法 SPD わ かりやすいプログラムへの招待状』，共立出版． [2] 大滝みや子 ,(2009),『基本情報技術者 大滝みや子先生 のかんたんアルゴリズム解法―流れ図と擬似言語』,リッ クテレコム． [3] 笠原一浩，(2006)，『Visual Basic 2005 入門』，ソフト バンククリエイティブ． [4] 杉浦学・松澤芳昭・大岩元，(2005)，『プログラミング 教育における HCP チャートの再評価』，第 46 回プログ ラム・シンポジウム 情報処理学会 p217-219． [5] テクノロジックアート，(2010a)，『UML の 特 徴 』， http://www.tech-arts.co.jp. [6] テクノロジックアート，(2010b)，『 改 訂 3 版 基 礎 UML』，株式会社インプレスジャパン． [7] 長野広宣，東基衛，(1987)，『プログラム構成要素及 び その 表 記 法 』，Information Processing Society of Japan ,Vol 28,No 9．
[8] 花田收悦著 ,(1983)，『プログラム設計図法』， 企画センター．
