Gaming Life

一日２４時間、ゲームは１０時間

GUIフレームワーク探しの旅の果てにWPFにチャレンジしている

C# WPF

GUIフレームワークを探して三千里

数年前から使い勝手の良いGUIツール作成用のフレームワークを探している。

今自分は、ゲームを作るならUE4かOpenSiv3D（それとUnity）を使い、CLIツールや少し込み入ったスクリプトの実装にはPythonを使っている。たまにProcessingやシェルスクリプトを使うこともある。プログラムを真面目に書くようになってもうすぐ４年、こんな具合に「これを作るならこれを使う」といった流れが確立しつつあるのだが、GUIツールの実装に使える、自分の肌にあったフレームワーク・ライブラリには出会えていない。

最初に試したのはQt。クロスプラットフォームなGUIツールで最もよく使われているフレームワークの一つだと思う。映像・ゲーム業界的にも広く使われているフレームワークで、就職活動中、中途のツールエンジニアの採用要項に「Qtの使用経験○年以上」と書かれているのを頻繁に見かけた。

www.qt.io

挑戦の結果、Qtを極めるのは断念した。理由としては独自のQMakeというビルドシステムが理解できなかったこと、専用IDEであるQt Designerにどうしても馴染めなかったこと、そして何より必要なストレージ容量が多すぎた（おおよそ20GBから40GB）ことが挙げられる。特に最後の必要な容量の多さは致命的で、ただでさえ莫大な容量が必要になるUE4を使っているのに、それに加えてQtを入れておく余裕は自分のPCにはなかった。

次に試したのがOpenSiv3D。本来はゲーム開発に使うのが主なフレームワークだが、モダンなC++で書ける上、開発者が日本人でサポートも充実してることからこれでGUIツールが作れないかなーと考えた。

これも結果は断念。最低限のUIパーツは揃っているが、まだまだGUIアプリケーション開発に投入するには機能不足だった。何よりデザイナーを使ってウィジェットを配置出来ないのが不便だった。（なおOpenSiv3Dはオープンソースで開発されているので自分で実装する、という手もあったが、そんな技術力ななかった）

他にPyQt（QtのPythonバインディング）も試したが、動的型付け言語でGUIを作るというのがどうも気持ち悪くなって諦めている。

そんなこんなで色々と迷走した挙げ句、今はWPF(Windows Presentation Foundation)に挑戦している。WPFとは、Microsoftが開発したGUI開発用のフレームワークで、主にC#やVB、そしてXAMLというUI配置を簡単に表現できるマークアップ言語で実装できる。WPFの歴史は意外と古く、2006年頃から使えたらしい。

WPFというと自分は「Windowwsでしか動かない」「Windowsフォームに取って代わる程の人気が出なかった（UWPと並ぶ）残念な子」「よく知らないけど.NET一族のひとつらしい」ぐらいの認識を持っていた。特にWindowsでしか動かないというのが、せっかく開発したツールもMac使いが多い（と勝手に思っている）デザイナーに使ってもらえず終いになってしまうのでは、という考えにさせてしまい、これまでチャレンジしてこなかった。

だが2019年に、クロスプラットフォームなフレームワークである.NET CoreがWPFをサポートすることが発表され、WPFでWin / Linux / macOSに対応したGUIツールが開発できるようになっていた

（追記）と思ったら、.NET Coreに対応しただけでWPFはWindowsでしか動かないらしい。びえん。

codezine.jp

これはやるしかないだろう、とWPFに挑戦することにした。

（ちなみに.NET Fremeworkと.NET Coreは今後統合され、.NET 5として新生。新たにUIクロスプラットフォームフレームワークが公開されるらしい。UWPと同じ運命を辿らなければ良いなあ）

触ってみての所感

まだWPFを触り始めて数日程度しか立っていないが、とにかくC#が難しい。多少なりUnityの経験があるのでなんとかなるだろうと思っていたが、C++、Pythonには無い構文、当然のように使うことが求められる大量のインターフェース、参照型と値型の違いなどなど予想以上に苦しめられている。C++より難しいんじゃねえのこの言語。

ただ、WPFそのものは想像以上に使い勝手が良い。日本語ドキュメントが充実していないのは玉に瑕だが、直感的に使えて、かつVisual Studioとの相性が抜群に良いので、今後もWPFの学習を続けたいと思えた。C++書くときもコレくらいVisual Studioが仕事してくれたらなあ……

参考にしている資料

チュートリアルとして、こちらのサイトの資料を使っている。プログラミング自体の経験が浅い人には難しすぎるが、ある程度の経験がある人なら非常に参考になる資料だと思う。

http://kisuke0303.sakura.ne.jp/blog/?p=340

また、WPFが推奨している開発スタイル（デザインパターン？）であるMVVMについては、下記のページで紹介されているリンクを主に見て勉強している。まだ全部は見切れていないが……

https://qiita.com/usada-kumi/items/046c9a43b15b9e376198

結び

以上、WPFに挑戦しているよという話でした。ブログに記事として上げた以上は、これまでの挑戦のように途中で断念することなく、何かしらツールを完成させて、ここで公開できるといいなぁ。

Visual Studio 2019でプロジェクトを複製して別名をつける方法

Visual Studio

DirectXの入門本を進めている際、Visual Studio 2019において、いま作っているプロジェクトをコピーして、それに別名をつけた上でソリューションに追加したくなったのでそのメモ。

ようはこういう事↓。

f:id:ai_gaminglife:20200502152146p:plain

手順

  1. エクスプローラーを開き、コピーしたいプロジェクトファイル（.vcxprojなど）が入ったフォルダをまるごと同じ階層にコピー。
  2. コピーしたフォルダに別名をつける
  3. コピーしたフォルダを開いて、その中にある、.vcxprojファイル、.vcxproj.filtersファイル、.vcxproj.userファイル全ての名前を、先程コピーしたフォルダにつけた名前に変える。
  4. Visual Studioを開き、コピー元のプロジェクトを開く。
  5. ソリューションエクスプローラー上で、ソリューションアイコン上で右クリック→追加→既存のプロジェクトを選ぶ。
  6. 先程コピーしたフォルダの中にある.vcxprojファイルを選択する。
  7. 完了

C++のRange-based for文（範囲for文）で逆順に走査するイテレータを自作した

C++

モチベーション

Pythonのfor文は、C++でいうところのRange-based for文、C#で言うところのforeachと同等の動作をする。つまり、

    for (int i = 0; i < 10; i++) {}

のようなforが存在しない。

Pythonのfor文において、iterable objectをenumerate メソッドに渡すと、添字付きRange-based forができる。

    l = [100, 200, 300]
    for i, num in enumerate(l):
        print(i, num)
    # 0 100
    # 1 200
    # 2 300

これが非常に便利なのでC++でも同じ事ができないかなーと調べてみると、あった。

reedbeta.com

（リンク先に載っている実際のソースコードはここには載せない）

というわけでC++のRange-based for文でもPythonの enumerate 同等の、インデックス付き走査が可能ということが分かった……

と、ここで終わってはクソ記事もいいとこなので、この実装を参考に逆順に走査するイテレータを自作することにした。

仕様

まず、リンク先の実装で問題なところを挙げてみる。

  1. operator++ の返り値がvoidになっている
  2. std::begin や std::end の形でイテレータを取得しているので、ユーザが独自に定義したiterable objectに対応できない（わざわざ std::begin 、 std::end をオーバーラップしなければならない）
  3. beginとendの型が違う場合に対応していない (C++17でbeginとendの型が違っても動作するようになった。詳しくは↓の記事で）

cpprefjp.github.io

今回の実装では 面倒なので 3. の問題については無視することにした。

また逆順に走査するためには、対象のiterable objectは rbegin と rend 、つまり逆イテレータを持っていなければならない。従って SFINAE を使って rbegin rend を持たないオブジェクトを渡した時はコンパイルを通さないような実装とした。

実装

(2020/04/12/18:30 コメントでの指摘通りに修正）

    template <typename Range,
              typename reversed_iterator = decltype(std::declval<Range>().rbegin()),
              typename = decltype(std::declval<Range>().rend())>
    constexpr auto Reversed(Range&& range) {
        struct iterator {
            reversed_iterator iter;
            bool operator!= (const iterator& end) const { return iter != end.iter; }
            auto& /* void */ operator++() { ++iter; return iter; }
            auto& operator*() const { return *iter; }
        };
        struct iterator_wrapper {
            Range iterable;
            auto begin() {
                return iterator{ iterable.rbegin() };
            }
            auto end() { 
                return iterator{ iterable.rend() };
            }
        };
        return iterator_wrapper{ std::forward<Range>(range) };
    }

wandbox.org

operator++の戻り値について

operator++の行に謎のコメントが残っている。

    auto& /* void */ operator++() { ++iter; return iter; }

実は今の実装のままだと、MSVCではコンパイルが通らない。

調べてみると、どうやら現在のgccのvectorの実装では vector::begin() をデクリメントしても、エラー終了しないらしい（当然Undefined Behaviorなので本来はやるべきでない）。一方MSVCの場合、 vector::begin() をデクリメントした時点で、 can't decrement vector iterator before begin というエラーメッセージと共にエラー終了する。

そのため、この関数をMSVCで使いたいときは、悪い実装ではあるがoperator++の実装を以下の通りに変える必要がある。

    /* auto& */ void operator++() { ++iter; /* return iter; */ }

参考サイト

Python-Like enumerate() In C++17

C++ 範囲ベースforに自分で作ったclassを対応させる - ゲーム作りは楽しい

Visual Studio 2019でCatchを使ったC++単体テストを実現する

C++

Cppmap で紹介されていたC++用単体テストフレームワークであるCatchをVisual Studio 2019で使ってみたので、その導入に関するメモ。

github.com

はじめに

説明のために、Visual Studio 2019 (以下VS2019) で、空のプロジェクトを作成。整数を受け取り2倍の値を返す関数 int mul2(int) を作る。

f:id:ai_gaminglife:20200329110451j:plain

次に単体テストを実行するためのプロジェクトを追加で作成する。今回は、テスト用のプロジェクトの名前を TestProjectとした。

f:id:ai_gaminglife:20200329110504j:plain

Catchの導入

TestProject以下に空のヘッダファイル catch.hpp を作成する。

続いて、Catchの公式リポジトリ から、 single_include/catch2/catch.hpp を見つけ、その中身を全コピーする。catch.hppは include ディレクトリ以下にも存在するが、こちらではない。私はこれに気づかず時間を潰してしまった。

次にTestProject以下に Test.cpp を作成し、以下を記述する。

    #define CATCH_CONFIG_MAIN
    #include "catch.hpp"

これでCatchの導入完了。

単体テストの実行

TestProject以下に、最初に作成した mul2() 関数をテストするための testMul2.cpp を作成する。

そこで catch.hpp と、 mul2() を実装したヘッダファイルをincludeする。

    #include "catch.hpp"
    #include "../HelloCatch2/mul2.hpp"

あとは、適当にテストケースを書いて、TestProjectをスタートアッププロジェクトに指定してから実行すればOK。

f:id:ai_gaminglife:20200329110544j:plain

もし、他に作成した関数について単体テストしたければ、TestProject以下にcppファイルを作成し、そこで #include "catch.hpp すればよい。

毎回HelloCatch2プロジェクトで作成したヘッダファイルを参照パスで指定してincludeするのは面倒なので、TestProjectのアイコンを右クリックして VC++ディレクトリ->インクルードディレクトリ から、HelloCatch2プロジェクトで作成するヘッダファイルを置くディレクトリを、インクルードパスに指定すると良い。

参考サイト

github.com

あなたの話はなぜ「通じない」のかを読んだ

読書メモ

ある記事で「あなたの話はなぜ通じないか」（ちくま文庫）が絶賛されてた。ここしばらく、卒論の執筆等で「伝わる日本語」を書く・話すことの難しさに悩んでいたこともあり記事を読み終わった後即購入（kindle版がおよそ500円と破格の安さで買えたというのもある）。卒論を書き終わって余裕ができたので2、3日で一気に読んだ。

あなたの話はなぜ「通じない」のか (ちくま文庫)

あなたの話はなぜ「通じない」のか (ちくま文庫)

で結論から言うと、非常に素晴らしい本だった。就職を目前に控える今、この本が読めて心底良かったと思っている。恐らく今後の人生で何度か読み返すことになるだろう。

この手の本にありがちなのは、小手先だけのテクニックをひたすらに紹介すること。「理科系の作文技術」、「数学文章作法」に代表されるような文書執筆のハウツー本等ならそれでもよいが、会話はそうはいかない。個人的な考えではあるが、目の前にいる相手に対して小手先だけのテクニックを使って物事を伝えては、相手を思う通りに動かしてやろうという浅ましさが前面に出てしまい、相手に伝えたいことを伝えられないどころか、嫌悪感を与えてしまいかねない。

本書では、作者の実体験に基づいた、物事を伝えるために必要となる心構え・考え方を丁寧に説明し、その後で「伝わる」会話のテクニックを教えてくれる。そのため本書を通じて小手先だけのテクニックではなく、血の通った、相手に嫌悪感を与えないような会話術を得ることができる。

メディア力こそ話が通じる一番の基礎

本書で一貫して言われていることは、「自分のメディア力を上げる」ことこそが話が通じる一番の基礎であるということ。その例として……

ついに宇宙とコンタクト（日本経済新聞）
ついに宇宙とコンタクト（東京スポーツ）
いかがだろうか？右の二つは同じことを言っている。でも違う意味にみえてしまう。
―『あなたの話はなぜ「通じない」のか』

本書冒頭より引用。こう明快で面白い例を出されると「ちょっとこの本を読んでみるか」と思わされてしまう。

「メディア力を高める」というと、今の時代だとSNSで数万以上のフォロワーがいる、相当以上の稼ぎがある……などが思い浮かぶ。しかし本書で言うところの「メディア力を高める」とはそういうことではない。

自分の聞いてもらいたいことを聞いてもらえるメディアになる。
「メディア力を高める」とは、そういう意味だ。少し引いた目で、外から見た自分をとらえ、それを「こう見てほしい」という自分の実像に近づけていくことだ。
―『あなたの話はなぜ「通じない」のか』

SNS全盛の時代、実際の自分以上に自分を良く見せようと見栄を張ったりしがちである（もちろん私自身も）。見栄を張っていると、外から見た相手があなたに抱く期待値は実際以上のものとなり、結果それ以下のパフォーマンスしか出せないあなたは幻滅されてしまう。

見栄を張らず、等身大の自分を相手に見せていれば、相手はあなたに過度な期待はしなくなる。相手の期待に沿うパフォーマンスを発揮できれば、あなたへの信頼は高まり、新たな仕事を貰える。これを繰り返していけば、「あの人なら間違いない」と思ってもらえ、自然とあなたの発言の影響力は強くしていける。

ただし、ただ仕事を黙々とこなせばよいわけではない。周囲からみて、あなたがどう仕事をしているのか見えていなければ、周りは憶測であなたの仕事を評価してしまう。

伝えなきゃ、伝わらない。
―『あなたの話はなぜ「通じない」のか』

周りに自分を正当に評価してもらうには、自己発信が不可欠だ。あなたの仕事ぶりを理解してくれている人は、あなたの発言・意見に真摯に耳を傾けてくれる。

この話は私に非常に刺さった。就職を目前に控える今、この後会社の戦力になれるのかどうか不安になっている。この不安を紛らわすために、実際には出来ないことを「出来る」と見栄を張っていたことは否定できない。それでは後々、自己評価と他者からの評価、出来ることとやりたいことの乖離に苦しめられることに気づけた。焦ることなく、見栄を張らず、やれることを少しずつ広くしていけるようにしていきたいと思う。

「問い」を鍵に物事を考える

自問自答を粘り強く繰り返すと、いずれ「あ、そうか！」という発見、つまり「意見」を見つけることが出来る。これこそが考えるという作業なのである、と本書では解説している。5W1Hを意識して、ちょっと頑張れば手が届きそうな「問い」をいくつも洗い出せば、問題をほぐしていける。

こうした「問い」を鍵にした「考える」テクニックとして、自分にインタビューするように考えを進める、という手法を提案している。インタビューは「問い」を投げる順番や構成を工夫しなければならない。いい「問い」を見つけるための考え方や訓練方法は第二章で色々挙げられている。

正論の難しさ

正論を拒むのは、人間の本能かもしれないと私は思うようになった。正論は強い、正論には反論できない、正論は人を支配し、傷つける。人に何か正しいことを教えようとするなら、「どういう関係性の中を言うか？」を考え抜くことだ。それは、
正論を言うとき、自分の目線は、必ず相手より高くなっているからだ。
― 『あなたの話はなぜ「通じない」のか』

最近私は、間違っていることをキツめの言葉で指摘することが多い。幸いなことに、それが原因で人間関係がこじれたということはないが、新生活を始めるにあたって、このままでは良くないことに気付かされた。

信頼関係を築けていない人から、上から目線で指摘されるのは不快なことだ。こちらの都合を全く無視した正論は相手の心を打つことはない。

「共感」を入り口とした意見・コミュニケーションは、正論と比べてずっと相手の感情に届く。「共感」とは、相手と同じ目線で物事を捉えるということ。同じ問題意識を持ち、同じような責任感を持ってくれる人との間で生まれる連帯感は、意見を伝えることに大いに役立つ。

今後正論を言いたくなるときは、一呼吸おいて、「なぜ」相手はそう考えるに至ったのか、冷静に考えるようにしたいと思う。また、自身の意見を言う際には、相手を傷つけることなく、さりとて、嘘やごまかしはせずに言い回し等を工夫して伝えるようにしていきたい。

まとめ

研究室生活を送る中、教授には「プレゼンはとにかく認知負荷を下げろ」と言われ続けてきた。本書を通じてその言葉の真に意味するところがわかった気がする。認知負荷の高いプレゼンは、そのデザイン・レイアウトが良くないだけでなく、プレゼンしたい内容についての自問自答が不足していて、それを相手に理解してもらえるほど自分が理解していないのだ。このようなプレゼンを続けていては、自身の信頼、本書で言うところの「メディア力」は欠損していく一方だ。本書で学んだ相手に伝える技術と、それを鍛えるトレーニング方法を実践して、自分の言いたいことを嘘偽りなく、素直に相手に伝えられるようにしていきたい。

最近読んだ本・漫画を振り返る 2020/1・2月編

読書メモ

3回目となった読書振り返りシリーズ。年明け以降、海外に出張したり、学会発表したり、引っ越しの準備をしたり、卒論を書いたり……と忙しい日々が続いていたため、ここ2ヶ月はあまり読書できていない。そのため、もう一ヶ月読み溜めてから本記事を投稿しようと思っていたが、2年以上毎月ブログ更新を続けているのに、今月は（ブログに書ける）ネタが無いため、今月この記事を投稿することにした。 [:contents]

前回の記事はこちら↓

ai-gaminglife.hatenablog.com

IT系

オブジェクト指向入門 第2版 原則・コンセプト

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

研究室に転がっていたので読んでみた。といっても今の自分が読むにはかなり厳しかったので、下に挙げる記事で推奨されていた3、6、11章あたりをつまみ読みしただけ。

blog.shibayu36.org

古典的名著として知られているだけあり、これまで読んできたプログラム設計に関する記事・書籍の元ネタになっているような話題・用語が散見された。特に「第3章 モジュール性」はこれまでぼんやりとしか捉えていなかった「よいモジュール」とはなんぞや、というのが言語化されていてためになった。「第11章 契約による設計」はC++23以降でcontracts が導入されるらしいので、C++23をgccがサポートする頃もう一度読みたい。

また、本著を読むにあたっては以下の記事が参考になった。特に「PHP7で堅牢なコードを書く」は、必見。PHPのコードが理解できない自分でも活かせる知見が沢山。

そろそろドメイン駆動設計を読みたいなぁ。

speakerdeck.com

masuda220.hatenablog.com

ビジネス書

20歳までに知っておきたかったこと

20歳のときに知っておきたかったこと スタンフォード大学集中講義

20歳のときに知っておきたかったこと スタンフォード大学集中講義

2~3ヶ月かけてゆっくり読んでいた本。自己啓発系の本へのアレルギーを取り除こうと思い買った。買って満足できた一冊。今後は「自己啓発系とかw」と、食わず嫌いせずに良い本は積極的に読みたい。ただし○リ○○○が書くようなペラペラな自己啓発本はNOな。

最終章に書かれていた「自分や他人の間違いにもっと寛容で、失敗も学習プロセスの一環だと思えばよかった」というアドバイスが染みた。人生やり直せるならこの本を高校時代、あるいは大学1年の頃に読んでおきたかった。

見やすい資料の一生使えるデザイン入門

一生使える見やすい資料のデザイン入門

一生使える見やすい資料のデザイン入門

超有名なSlideshareで公開されているスライドデザイン資料の書籍版。お試しで入ったkindle Unlimitedで読めたので、移動中の高速バスで読んでいた。まぁわざわざ本を買うまではしなくていいと思う。ただ、○ソデザインなスライドをPowerpoint、Keynoteで作る人を教育する目的で買い与えるのは良さそう。

www.slideshare.net

横井軍平ゲーム館 ← 今回のオススメ

横井軍平ゲーム館: 「世界の任天堂」を築いた発想力 (ちくま文庫)

横井軍平ゲーム館: 「世界の任天堂」を築いた発想力 (ちくま文庫)

今回のオススメ枠。旅先の梅田の本屋で見つけて即買いした本。「枯れた技術の水平思考」で有名な任天堂の横井軍平氏のインタビューをまとめた記事。これと岩田元社長のインタビューまとめ本をあわせて読めば、任天堂がなぜ世界的企業にのし上がったのかがわかる。

全てを一人でやらず専門家の集団を作ればより良いものが作れる、全体を見渡せる知識を持っておく、最新技術を使いたがる技術者のエゴ・プライドを捨てるなど、非常に多くのことが学べた。これをゲームPGとして就職する前に読めたのは非常に良かった。

岩田さん 岩田聡はこんなことを話していた。

岩田さん 岩田聡はこんなことを話していた。

まとめ

今回は4冊。最近は技術書ばかりを読むのではなく、ビジネス書も読むようになってきた。色々と学びがあり、食わず嫌いは良くないなとしみじみ。就職してからも週1冊程度のペースで読書していけると良いなぁ。

私は大学院に進まないけど理系は基本大学院進んだほうがいいよって話

雑記

最近は大学卒業間近で引っ越し準備を進めなければならない&来週学会発表が控えていることもあり、非常に忙しい日々が続いている。ただ、大学の仕事に追われ続け苦しい日々が続いているというわけではない。Prime Videoで鬼滅の刃を見たり、本を読んだり……。また、年始にはインド・コルカタで開催された国際学会に参加した。

遊んでる画像しかねぇ……

実はこれが自身初の海外旅行。まさか人生初の海外がインドになるとは夢にも思っていなかった。助手という立場での参加であったこともあり、気楽に街の中を丸一日観光していられる程には楽しむことができた。

雑談終わり。

大学院のススメ

冒頭でも触れたが、現在地方駅弁大・工学部の大学四年生の私は、今年の３月に卒業予定である。国立大の理系というと、一般的に大学院に進むことが多い（例：岐阜大学の機械工学科は大学院進学率8割超え）。そんな中私が就職という選択をとったのは、ひとえにゲーム会社に内定を頂けたからである。

ai-gaminglife.hatenablog.com

入学時点でゲーム会社への就職をひとつの目標としていた自分が、学部時点でゲーム会社に内定を頂いてしまってはそりゃ大学院進学という選択が消えるに決まっている。

就職という選択自体に後悔はないし、なんなら研究室配属直後はみんな大学院なんか行かずに就職すればいいのにと思っていた。しかし、1年間通して研究に取り組み、何度か学会に参加した今、考えは変わっている。

ほぼ全ての理系大学生は、大きな理由がない限り大学院に進むことを勧める。

研究とは本来何年もかけて一つのことを追求してようやく成果を得られるもの。それなのに素人の大学生が一年間で成果を得ることは困難である。実際自分も、今取り組んでいる研究は中途半端なまま、まだ顔も知らぬ後輩に託さねばならないことが確定している。おまけに就活は、一般的に研究室正式配属前の大学3年の冬から始まるそんなズブの素人を「高度な理系教育を受けた人材」として企業は採用してくれない。理系として評価してもらいたいのなら、基本的には、大学院に進まねばならない。

大学院に進むメリットはまだある。国際学会を始め、個人ではまず行けないところに、大学のお金で参加することができる。

当然学会に参加するには、事前に険しい研究生活と論文執筆を、授業を受けながら続けなければならない。だが、学会に参加することで、貴重な体験をすることが可能だ。

（ちなみに学部生ながらインドの国際学会に連れて行ってもらえたのは人手不足など色々複雑な事情がありまして……）

研究室選択の基準はテーマ<教授の人柄

よく言われることだが、研究室選択で重視すべきは、「研究テーマ」よりも「教授の人柄」である。これは他の研究室に配属された同期の話を聞いてしみじみ感じている。

全くもって興味の持てない研究なら別だが、多少なり興味がある研究テーマで、人柄の良い教授の研究室と、研究テーマに非常に興味があるが人柄最悪の教授の研究室を比較すれば、選ぶべきは前者だ。教授の性格が悪いと、いくらやりたい研究でも人間関係で悩まされ、高いモチベーションを保つことができない。

なお、研究室配属前の学部生が勘違いしがちなのは、教授が熱心・講義が厳しい=ブラック研究室だと思ってしまうことである。これは必ずしもイコールではない。熱心なのは、面倒見が良いからだったりする。拘束時間が長いと思っているのは、単に所属している学生が高いモチベーションで研究に取り組んでいるだけなのかもしれない。私は時々「研究室が辛いー」だの「論文修正が終わらない」だのでぼやいているのは、いい意味で教授の面倒見がいいせいである。

ちなみに、個人的なブラック研究室の基準は、

教授の性格最悪・拘束時間長い > 教授が学生の面倒をほとんど見ない放置系研究室 > 拘束時間が極端に長い研究室

放置系研究室は非常に厄介。他所から放置系であることに気づくのは困難であり、かつわかり易いパワハラを受けているわけではないので大学に通報しても中々動いてもらえない。放置系研究室を避けたければ、事前に教授ではなく所属している学生に話を聞くべきである。

終わりに

色々言ってみたが、所詮私は学部で卒業する人間。大学院に進むか悩んでいる人は、実際に大学院生に話を聞いてみたりするべき。これから研究室配属が待っている後輩らが良い研究室に配属され、満足いく研究生活が送れることを祈ります。