小ゼミの学生質問が，少なくなってきたように思います．
背景知識がなくても，いや，背景知識を持っていないからこそ，言うことのできる，質問のパターンを，考え直してみました．
取り上げた事柄が，研究全体のどこに位置づけられるかを尋ねる
例：
- MySQLをシステムで使用するとおっしゃっていましたが，どんなデータを格納しているのでしょうか?
- コレコレを用いて精度向上をする，とのことでしたが，実験結果から，導入した手法が有用だったと結論づけて，いいのでしょうか?
開発したシステムの発表で，使用しているソフトウェアを列挙しているスライドがあれば，それぞれの用途をよく聞き，一番分かりにくかったものを取り上げて尋ねてみましょう．
一つのシステム開発では，ソフトウェアや既存データ（コンテンツ）を組み合わせて構成するものです*1．組み合わせ方は，発表時に言ってくれるかもしれませんし，明示されないこともあります．
「研究」に着目すると，開発（実装）はその一部であり，研究成果とするには，課題の選定*2，実験計画，実験，結果分析も必要となります．
そういうふうに，全体と部分，目的と手段というふうに分けて考えてみたとき，ジグソーパズルでいう「ピース」を，無理矢理はめているようなゼミ発表をしていることが，あるかもしれません*3．
そういうところを気づいて，教えを乞う形で尋ねれば，質疑応答が充実することでしょう．
使う人の立場で，質問する
例：
- このシステムの利用者像は，どうなるのでしょうか?
- 出来上がりのグラフに書かれていることが，膨大なのですが，これは，ここからこのように見ていって，関心がある言葉の周辺にあるものを理解していけば，いいのでしょうか?
発表する先輩は，実装の技術は高くても，必ずしも，使う人の立場に立って作り込むということまではしていないことがあります．
「作ってから考える」ように見える発表に対しては，質問するあなたが「使う人」や「売り込む人*4」になってみて，使うため，売り込むために何を明確にすればいいかを，質問にするといいでしょう．
数量化を試みる
例：
- 前処理時間は，今回使用したデータで，どのくらいだったのでしょうか?
- スケールアウトで性能を向上させるとのことでしたが，100台つないで100倍の性能になるとは思えないのです*5．何倍くらいになるのでしょうか?
研究発表で，数量化（数値化，定量化）ができそうだけど特に言われてなければ，質問のチャンスです．
数値にできそうなこととして，「時間」「（物理的な）空間」「メモリサイズ」「ディスク容量」「計算機台数」「実験協力者数」「実験期間」などがあります．検索システムでは，上の例のように，検索に先立って行われる前処理に着目するのも，一つの方法です．
数値を教えてもらったら，もしかしたら改善の余地があるのではないかと考えてみるのも，良い心がけだと思います．
（おまけ）好ましくない質問パターン
例：
- 質問の形をしたコメントになっている．
- 質問したら終わった気になる．
- 答えに対して，リアクションを示さない．
一つひとつ補足すると，「質問の形をしたコメント」は言い放ちたいことがあるときに使用するものであり，ゼミでの後輩から先輩への質問としてはよくありません．
質問したら，答えをよく聞き，自分の知りたいことだったのかどうかをチェックしましょう．不十分なら，掘り下げて尋ねるべきです．
回答に納得したら「わかりました」，納得いかなくても他の人に質問してもらうなら「えっと…ちょっと考えてみます」などを言い，発表者・司会者にシグナルを送るようにしましょう．
「良い質問＞悪い質問＞無い質問」という不等式を頭の片隅に入れ，ゼミの質疑応答を楽しめるようになってください！
*1:「Webで動かすデータベースシステム」を例に，構成要素を可能なだけ挙げて，関係図を作ってみるのは，良い勉強になると思います．クライアント側も忘れずに．
*2:「解決する価値のある課題であることの確認」と言い換えてもいいでしょう．
*3:むしろよく見かけるのは，より小さい（もちろん間違った）パーツをはめていて，そのパーツがぐらぐら動いているような話の内容，でしょうか．
*4:「設計開発の際から，売ることを考えるべきでは?」と思う人がいるかもしれないので，付け加えると，「あなたが経緯はともかくとして営業の部署に異動し，売り込まないといけない商品を見て，売り込みに行く前にセールスポイントを考え，必要なら開発者にアドバイスをもらう」というシチュエーションが，考えられます．
*5:通信によるロスがあるから．
