memorandums

日々の生活で問題解決したこと、知ってよかったことなどを自分が思い出すために記録しています。

レジュメを送る前に各自でチェックして欲しいこと

今年度の卒業研究のスケジュールは以下の通りです。既にお知らせしている通りです。

成果物期限提出場所
レジュメ(A4版1枚)1月27日(金曜)16時事務分室
卒業研究発表2月3日(金曜)2限目〜4限目
卒業論文2月10日(金曜)16時事務分室

正月明けに最初にやってくるのがレジュメです。ここでいうレジュメとは卒業論文をA4版1枚にまとめた要約文のことをいいます。収集したレジュメは全員分をまとめて印刷業者に渡して冊子になります。過去のレジュメ集はゼミ室に置いてありますので参考にしてください。

レジュメ作成はこれまでの研究成果をまとめる最初の機会です。ここで文と文の構成を磨き上げることでその後の発表も論文の執筆も楽になります。気合いを入れてしっかり仕上げましょう。

今年は4名と少ないですが例年はゼミに10名近く在籍します。同じような指導を一人一人にするのは大変なので数年前から最低限の指導内容をテキストにして研究室のWebサーバーで公開してきました。

ゼミのサーバーが今後どうなるかわかりませんのでブログに書いておきたいと思います。レジュメを作るとき、また提出する前に必ず一読して「自己点検」してください。

以下、長文になりますが。。。ゼミ生は必ず一読してください。ゼミ室には論文の書き方、文章の書き方、テクニカルライティングに関する書籍をいろいろ置いています。そちらも参考にしてください。


レジュメを提出する前に自己点検して欲しいこと


(1)文章(1文)は可能な限りシンプルに書く。不必要な修飾語はばっさり削除する。極限まで文章を短くする過程を通して自分が伝えたいことの芯、いわゆる「本質」が見えてくる。余計な言い回しや回りくどい表現や文学的な表現を書く人がいる。苦労して読んだけれど何を言っているかわからない文章は読者をいらだたせる。文章をシンプルにすることで読み手の負荷をさげることができる。文章を短くするのは長くするより断然難しい。でも必要かつ大切なこと。

(2)漢字は必要最小限にする。ワープロに慣れた人は何でもかんでも漢字にしたがる。というより変換結果に無関心なのかも知れない。あらためて教科書など手元にあるプロの書いた文章を確認して欲しい。変な漢字はほとんど使わない。例えば、前の文章のほとんども「殆ど」と変換できるけど漢字にはしない。「下さい」「行う」なんかもそう。「思う」なんて論文で見たことがない。見たことのこともよく「事」って書く人がいる。これも避けよう。なぜ漢字を避けるかわかるだろうか。漢字が多くなると文章全体が詰まって息苦しい感じがするため読者が読む気を無くす。あくまで読者が読みやすいようにわかりやすいように配慮することが大切。論文での表現で気をつけたいポイントは以下のリンクで整理してくれている。参考にして欲しい。

Link: リンク:論文に死んでも書いてはいけない言葉30

(3)論文は基本的に「である」調。慣れない皆さんは抵抗があるかもしれないが「だと思います」「思ったり思わなかったり」などとは書いてはいけない。自分の個人的な主張については「と考える」であり、事実については「である」となる。

(4)各章の分量はなるべく均等にすること。分量のバランスが悪い場合は章をわける必要がある。

(5)同じ事柄をあらわすキーワードや表現は統一する。MS-Wordでは警告機能がついている(赤波下線が表示される)ので活用する。

(6)文章がだいたい完成したら、ひと休憩した後に必ず印刷して5回くらいゆっくり声を出して読んでみること。声に出して言いにくいということは、その言い回しを(心の中で)読んでいる読者も言いにくい可能性が高い。なぜ、ゆっくり読むか?答えは考えながら読むからである。何を考えるかは例えば以下のような内容になる。

  • 前後の文章との対応はどうか
  • 説明に飛躍や抜けはないか
  • 説明を急ぎすぎていないか
  • 説明が詳し過ぎて逆にわかりにくくなっていないか?(木を見て森を見ずになっていないか?)
  • 説明の順番は良いか?入れ替えた方がいい?

読者は次に何がくるか予想しながら文章を読む。これを「メンタルモデル」という。ぐぐってみるとわかる。この辺を説明した本もゼミ室にあるので参考にする。

(7)全体を通してのアドバイス。できればストーリー(アウトライン)を考えてから書く。3年次の情報学プロジェクトでもやってきたことを思い出して欲しい。研究には背景があって、研究の必要性が浮き彫りになって、そうした背景(状況)の中にどういう課題があるのか書いて、それに対して新しい技術なりシステムを提案する。次に提案システムの特徴的な機能が当初考えた課題をクリアできたか評価実験で確かめる。実験結果を考察する(どの程度クリアしたかクリアしなかったか、クリアしなかったのはなぜか?など)。これまで書いてきたことを数行でまとめ、考察した事柄をもとに今後やっていくべきことを書く。それぞれの章、節、項のタイトルを書き、それぞれで何を伝えたいか短い文章を補足的に書く。アウトラインが完成したら肉付けする。


以下、各章ごとに簡単にこれまでしてきたアドバイスをまとめる。


■タイトル

タイトルは研究の顔。過不足なくその研究を言い表しているか熟考する。大切なキーワー ドがぬけていないか?十分にわかりやすいか?誤解は生じないか?チェックする。

■1章

背景、課題、この研究で何をするのか、を書く。「多くなっている」など現在わかっている事実を背景として述べるときは、その事実を裏付ける文献を引用する(誰もが知っていることはこの限りではない。読者レベルを想定することが大切)。それを参考文献に入れる。書いてみるとわかると思うがこの章を書くのが一番大変なはず。とにかく気をつけることは、あなたの論文を初めて読む読者が一文一文読み進める様子を想像すること。読み進めながら文章から得た知識を積み重ねて最終的に著者の伝えたいことを読み取ってもらえるかどうか配慮する。

■2章

提案内容の説明、あるいは、分析したなら分析手法や分析の結果わかったことを書く。大切なことはできるだけ1章で書いたこと(課題や背景)と提案機能を対応づけて書く。提案機能の説明は必要かつ十分に。どれくらい十分にすべきか。読者が興味をもったときに再現できるような情報を載せるということ。提案アルゴリズム、使用したオープンソースやライブラリの利用方法、開発環境など。ハードウェアを活用した研究ではシステム構成図や機能ブロック図を掲載するのもよい。全体→詳細、この流れを意識する。

■3章

評価実験を行ったのであればそれを書く。実験は何となくやっても意味がない。1章に書いた課題があるはずである。提案システムが課題解消にどの程度有効であるか確認する必要がある。それが実験である。実験の方法、前提条件、環境、手順などを簡潔に書く。あなたの研究に興味をもった読者が同じ実験をできるように、考えて書く必要がある。実験結果についてはできるだけ定量的に記述する。「まあ、なんとか動きました」なんていうのは意味がないことはわかってもらえると思う。どの程度、十分なのか?どの程度、不十分なのか?なぜ不十分なのか?実験結果がはっきりしていれば、今後の研究方針を考えることがたやすい。

■4章 まとめ/今後

基本的に前章までに書いていないことを書いてはいけない。これは大切。「本研究では、」という書き出しにしよう。繰り返しになるところもあるが「まとめ」の章なのだからしかたがない。こういう課題に対してこういうシステムを提案した。実験の結果、この点は十分、この点は不十分であることがわかった。今後は、不十分とあげた点について○○をしたい。という感じ。

参考文献

これには章番号は不要。1つ以上記述すること。必ず。URLよりは書籍や論文が望ましい。URLを記述する場合はいつ削除されるかわからないこともあり(アクセス日2009年1月24日)と書くことが学会によっては推奨される場合がある。