目次
研究の手続きについて
このページはログインしていない人にも公開されます
在籍者は内部情報を記入しないように注意してください
本・論文の捉え方
図書と知識の階層(辞書・百科事典等)
- 小項目主義と大項目主義
- wikipediaを含む一般的な百科事典は研究の出発点として使ってはいいけど,参照源として使われることは基本ありません
- とりわけ技術的な分野において,入門書ではなく,オリジナルを参照すること
- 専門分野に入ると,こんなものが(まぁ)有効
- 専門事典
- ハンドブック
-
- 読めるシリーズは他にもどこかに存在するかもしれない
- アクセスできる書籍はアカウントによるらしい
- 当然ながら英語(日本語のものある?)
-
- 専門分野の百科事典
- 言語系なら意外とStanford Encyclopedia of Philosophyは使えるかも
- 分野や研究の位置づけを確認するときは,目次も含めてとても大事
- 図書と論文のバランスを注意
- 専門分野に進むにつれ,論文の重要性が増す
- 当該分野のレイヤーをきちんと把握すること
「広げる」段階と「絞り込む」段階
広げる段階に相当するプロセスの習慣化
- 普段から自分のテーマに関わるものを読んでおく。広い範囲で読む。
- テーマを選べるときに読むもの
- 教科書とか
- 日本語は目立たないが,英語の場合,モノグラフシリーズのタイトルをチェック
- 最初の場合はかなり無駄をしますが,学ぶための大切なプロセス
本・論文の読み方
5層の読み
- 文字通り論理展開を追う(論理式に落とすつもりで)
- 新情報・旧情報の識別に注意
- 外延集合を常に想像すること(疑似外延集合でもよい。その場合,1レベル下のカテゴリを数える。)
- 重要情報(キーワード)を書き出す
- キーワード間の論述構造(論理関係)と概念構造(論述関係)を捉える
- キーワードを定義で置き換えることによって見える
- 論述のまとまり(段落を目安)は「何について」という指示的要約を与える(各段落の役割・機能)
- 「何について何を言ったか」という報知的要約(各段落の内容の要約)
- より大きなまとまりを俯瞰的要約(目次の再構成)
- 可能な構造もいじってみる
最終的には以上を 1 path で出来るとよいが、それまでは各層ごとに読み直す。 自分がわかる範囲にしかわからないことを避けよう。
研究の管理とメモ一般
電子的なもの
- ディレクトリの階層
- README(最低限のログ情報など)
- ファイル名に日付
- checksum
※ディレクトリ階層以外はgit
で代用できる
紙媒体のもの
- ページ番号を振って cross reference 可能にする
- 文献番号を付けること
- 日付を記入する
ゼミの準備・質疑・フォロー
- 資料:フォーマットを決めておく
- タイトル
- 日付
- 名前
- ページ番号
- 発表練習:説明の技術と「言葉」、大切なのは前者
- 説明の技術は,読みの5層と対応する形
- 発表・質疑の心得
- 発表資料のどの部分に関してかを参照して,質問する
- 自分が論じていることと,議論の関係を明確にする
- フォローアップ
- 資料や発表の連続性を明示する(前回までと比べた今回の進捗・変更点)
- 前回のコメントを踏まえる
文献の調べ方
- 東大では
-
- 「インターネットで文献などの学術情報を探すためのゲートウェイ」
-
- 「東京大学OPACや,東京大学で利用できる電子ジャーナルやデータベースを一つの検索窓でまとめて検索」
-
- 「東京大学にある図書や雑誌を探す」
-
- 定番検索システム(大学以外)
- 図書館のデータベースをベースにしたもの
- 大学図書館CiNii Books
- CiNii Booksと関係ないが,2017年3月28日付きCiNii ELS事業が廃止されたらしいので,国の方針としては,電子化された論文pdfの掲載は今後J-STAGE一本化?(未確認)
- 国会図書館NDL-OPAC
- 世界中の図書館WorldCat.org
- 書籍,ジャーナル情報をベースに
-
- 日本語不可,機関アカウント
「何を探せばいい?」という場合
- キーワードを探す
-
- 「国立情報学研究所(NII)が提供する無料の情報サービスで,江戸期前から現代までに出版された膨大な書物を対象」
- 連想検索ができる
- 連想検索とは,「文書と文書のことばの重なり具合をもとに,ある文書(検索条件)に近い文書(検索結果)を探し出す検索技術」
- 紙媒体
- 図書館でブラウジング
- 論文誌を読む
- 文献の参考文献リスト
- 芋づる式の2つの問題:時間のギャップ(その間の文献をカバーできない)と,トピックシフトの可能性(テーマが偏ってしまう)
- ハンドブック,事典類
-
- 機関アカウント
-
-
-
- 科学研究費助成事業データベース
- 研究分野,関連キーワード,研究概要などが見れる
- 言語系(自然言語処理も含む)ならもう一つの邪道(?)がある
- LinguistListで current calls を見てテーマを決めることもできる
文献の管理
- 文献管理の基本
- 文献管理の目的は、必要なときに必要な文献を必要な形式で取り出すことです。
- 書誌情報、文献ファイル、メモをきちんと管理しましょう。
- 文献管理システムを使うと便利です。
- いろいろありますが、機能はどれも十分なので好きなものを選びましょう。
- Mendeleyを使用するときのTips
- 文献のジャンルやキーワードでタグ付け
- 執筆中の論文ごとにフォルダわけ
- PDFファイルの自動改名を設定 (author_year_title.pdfなど)
- フォルダごとにBibTeXファイルを書き出し (TeXが参照するディレクトリへ書き出すとベター)
- 引用するときにCitation Keyを設定 (BibTeXを使う場合)
研究室での情報共有
研究室などのチームで共有される情報は、その有効期間に着目して2つに大別できる。
- フロー情報
- 有効期間の短い時事的な情報(ex. 休講情報、ゼミの日程)
- 新しい情報によって古い情報を押し流していく
- ストック情報
- 有効期間の長い保存版の情報(ex. 事務手続、必読論文リスト)
- 情報の発行時期よりも内容ごとに整理されているべき
それぞれに適したツールの活用が望ましい。
フロー情報の共有ツール
- メーリス
- メーリングリストの略(ML)
- MLアドレスに送信したメールがリストに登録されたメールアドレス全てに一斉送信される
- (テキストメッセージの主流化でメールが滅びる日がいつか来る?)
- 良くも悪くも「お手紙」
- ある程度のボリュームの情報をパッケージングして共有できる
- 正式な情報っぽさがある (pros)
- 書くのにちょっと敷居がある (cons)
- Google Group やフリーML?とか
- 大学によっては学内で何かしら提供がある
- グループチャット
- チャットルームに招待されたユーザが短いメッセージをやり取りする
- 例:各国のデファクトツール(消費者・一般向け)
- 日本:LINE
- 中国:WeChat
- 欧米:WhatsApp
- 一度に送信するテキストは短めなのでちょっとしたことでも共有しやすい (pros)
- たのしい雑談ができる (pros?)
- 通知がうるさい (cons)
- 前のメッセージが絶望的に見つけにくい (cons)
- そこでSlack!
- 企業向けグループチャットサービスの1つ
- 通知設定を細かく制御できる
- チーム内でトピックごとに別のルームを作れる
- メッセージ検索機能が優秀
- Webサービス、Botとの連携で便利な機能(ex. MTG日程通知、サーバへの命令)
- メーリスの転送
- 今日の各図書館の開館時間
- 教育学研究科学生支援チームHPの更新通知
- 研究室HP・Wikiの更新通知
- 総合ゼミ他研究室イベントのリマインド
ストック情報
- Wiki
- 一連の HyperText 文書を Web ブラウザから作成・編集・削除できるシステム
- 登録ユーザであれば誰でも編集でき、その履歴が保存される
- 集団内の情報を構造化して共有するのに適したツール
- 本研究室ではレンタルサーバに dokuwiki という Wiki システムを構築
- 巷にあまりよい無料サービスがない
- 強いて言えば…
- Trello (Wikiではないが)
- クラウドストレージ
- どんなファイルでも置くことができ、インターネット経由で中身を閲覧できる保管庫
- PDF、Officeファイル、画像、映像、音楽…
- ほとんどのサービスはストレージを個人に紐つけている(チームの金庫的なものは少ない)
- 研究室で1つのストレージを開設して運用(本当はこれも個人ベースのサービス)
- 院生全員が同じクラウドストレージサービスを使っていればビルトインのフォルダ共有で足りる
データやプログラムの共有
オープンデータリポジトリ
(研究の)データをオープンに公開して、研究者みんなで使えるようにしよう運動 = オープンデータ
ある地点の温度測位データ◯年分、何かの生き物のゲノム情報、テキストコーパス、匿名患者のfMRIデータ、無数の笑顔写真のパック…などさまざま。
サービスの例:
- Mendeley Data: なんでも
- DataCite: なんでも
- Figshare: 図表中心
ソースコードリポジトリ
- GitHub
- BitBucket
- GitLab (GitHub clone for self hosting)
データとコードの管理
コード、あるいはより一般的にテキストファイルは、昨今git
でバージョン管理するのがデファクトになった。
git
は個人で使う範囲では、例えるならリッチな「名前をつけて保存」。
あるフォルダ(ディレクトリ)について、今のファイルとサブフォルダの状態(バージョン)をまるごと保存し、それにメモをつけることができる(コミット)。
これを積み重ねると、あるファイルにいつどんな変更を自分がしてきたかわかるようになる(ログ、ヒストリー)。
また、同じフォルダで並行して複数の別バージョンを管理することもできる(ブランチ)ので、論文執筆の文脈で例えると、先行研究のまとめ方の方針が2つあって迷っているときに、2つの似たようなファイルやフォルダを作るのではなく、まとめ方Aの状態とまとめ方Bの状態を1つのフォルダのなかに維持し、適宜その状態を切り替えながら並行して執筆してみるというようなことができる。
日本語のわかりやすいガイドで有名なものは サルでもわかるGit入門。 その他、検索するといろいろ出てくるので、いろいろ読むと良い(なかなか1回ではわからない)。
gitで管理されたフォルダはgithubでホスティングするのもデファクトになった。 ただしgithubにアップロードするとすべてパブリック(公開)となることに注意。 学生であれば申請によりgithubでもプライベートリポジトリを持つことが無料で可能になる。 代替サービスのBitBucketならもともとプライベートリポジトリが無料なので、そちらを使うのも手である。
また、あらゆるデータは必ず物理的に異なる場所に、最低でも3箇所バックアップを取ることを推奨する。 たとえばローカル、USBメモリ(外付けHDD)、クラウドストレージ(Dropboxなど)に保存すると、どこかで何かあったときに復元できる可能性が高まる。
調査協力依頼や調査対象への連絡
学校への調査依頼(フィールドワーク・アンケートなど)
- 電話・メールでアポをとる
- 校長などに依頼状を書く必要があれば必要事項を書き、申請する
- 訪問までに時間がかかる場合があるので、時間に余裕を持つ
- 調査に対し、対応し慣れている学校とそうでない学校があるので、明確な調査目的を説明できるようにしておく
- 相手側になるべく負担をかけないよう、十分に配慮する
- 調査対象校には、研究成果を提示する
- お礼を忘れずに
図書館への調査依頼(貴重資料閲覧など)
- 電話・メールでアポをとる(メールの方がよい)
- 訪問・資料閲覧の許可が下りるまでに時間がかかる場合があるので、時間に余裕を持つ
- 研究目的・研究概要を図書館員の方(たいていはレファレンス担当者)に事前説明をしておく(資料・研究機関を紹介してもらえるかも)
- 人脈を持つ