■「分かる」ための対策その2:まともな議論をする
ある程度「分かった」知識をお客様への提案へと仕上げるためには，何人かで議論して提案をまとめることがとても重要です．
異なるアイディアを持ち寄って議論することでより深く「分かる」ことができ，理解の間違いも修正できるからです．
しかし，このような理解を深めるための議論（＝「まともな議論」）は，当初，新卒たちはまったくできませんでした．なぜなら，彼らはそもそも『まともな議論がそういうものか，習ったこともなければ見たことすらなかった』からです．
彼らの知っている議論は，複数のアイディアから1つを選ぼうとする作業でしかなく，議論と言うよりも討論と言った方が適切なものでした．
そのため，たとえば，3人がそれぞれA，B，Cの3つの提案を考えて持ち寄って議論した場合，彼らはその中から一番いい提案を1つ選んで皆の提案とするか，意見が合わなかった場合は簡単に議論を打ち切っていました．これでは，議論の意味がほとんどありません．
これに対する対策は単純で，必要とされている議論（＝「まともな議論」）とはどういうものかを彼らに教えました．つまり，A，B，C3つの提案を持ち寄って議論した場合，A，B，Cの提案のいいところを組み合わせたり悪いところを直したりして，どれよりも優れた新しいDの提案を作らないと意味がないと教え，彼らに実践してもらいました．
(略)
あらためて説明すると，「まともな議論」とは，何かを選ぶ議論ではなく，勝ち負けを決める議論でもなく，複数人の知識を合わせ新しい何かを生み出すための議論です．「まともな議論」をするためには，知識レベルももちろん重要なのですが，それ以上に「全員が1つの目的に向かう」「勝ち負けを目指さない」という議論に望む『姿勢』の方がより重要です．
(槙島和紀『企業の教育現場からの報告 頭がいいのに「分かる」ことができない新卒たち』, 情報処理, Vol.52, No.3, pp.363-364)
シスコで，新卒研修をしていく中で著者が知ったという，これまでの教育（大学に限らず）に欠けている点の指摘です．「情報処理」については，前に熟達者の書くコードでも取り上げました．今月の学会誌には，「プログラミング，何をどう教えているのか」の記事が3つあって，いずれも企業の方の報告となっています．学生に知識・技能を身につけさせて社会に送り出す者にとって，耳の痛い指摘がいくつもあります．
個人的に，議論のしかたはもっといろいろあってよいと考えますので，上記の「まともな議論」を「すりあわせ」*1に置き換え，感じたことを書くことにします．
まず思うに，「すりあわせ」の重要性は理解できます．その行為を知らない学生（に限らず）に指導することについても，悪いことではないでしょう．
実際，「すりあわせ」を大学教育の中で行うことは，可能です．自分の範囲なら，1年の基礎教養セミナーや，研究室の前期ゼミ・後期ゼミで，取り入れられそうです．研究の中では，卒業研究のテーマなど，1年の活動を左右する大きなところへの適用はリスクを伴いますが，手法やシステム化の検討では，有用なようにも感じます．
なのですが，ゼミで実施する「すりあわせ」活動は，それを一，二度，経験するにとどまり，学内外で積極的に活用しようとする学生は，ほとんどいないのではないかとも考えます．
その理由として2点が考えられます．評価と，最初に持ち寄る案（たたき台，とっかかり）です．
まず，大学を含む教育において，グループワークの成果物が評価される機会が非常に少ないのです．成績は，グループでも研究室でもなく，学生個人につけられます．科目の点数のほか，「協調性がある」といった所見に現れる程度です．
企業なら，この社員は社内でどこの部署に配属されどんな成果に関わったかを，記録に残せるのかもしれませんが，大学においては，研究室配属までは何をしてきたかをほとんど問われませんし，チームワークで素晴らしい成果を上げたからといってそのチーム全員が同時にある研究室に配属されるなんてことも，まずありません．
2番目の理由に行きます．「A, B, C」という提案を出させるのが，大変なのです．一つのテーマ（解決すべきこと）に対して，3人が別々の提案A, B, Cを出すというのが，現実離れしているのです．
ここでまた私の活動範囲に限定しまして，お題だけを与えて3人の学生が，異なっていて，かつそれぞれ比較検討して「すりあわせ」る価値のある案を持って来ることができるかというと，容易ではありません．安易な設定だと，“かぶり”ます．本から取ってきた，いわゆるtoy problemの中に，いい問題があるかどうか，そしてそういう問題を学生たちに与え，考えさせることに，価値があるかどうか…*2．
かぶってでも各学生が案を持ち寄れれば，いいほうです．特に指示せず，複数人の学生が議論すると，どうなるかですが，一つの（これがもっともよく起こる可能性とまでは言い切れませんが）パターンは，「誰かが言い出すのを待つ」です．そして学生の誰か，もしくはテーマを与える側が，Xを言うと，他の人はそれをベースに，磨き上げを試みるのです．X, X', X'', ...といった感じで，最終的な結論，「Xなんとか」に至ります．
もちろんこの流れでは，受け身で行動する人間を産むことになります．また成果を見ても，どうしても最初のXが持つ考え方（「（設計）思想」と呼んでもいいでしょう）に引きずられ，その壁を破ることはできません．
「すりあわせ」る能力を身につけさせるには，手法，だけじゃないなあ，WHY/WHAT/HOWを言うだけではなく，そういう行動をすることで，実際にその議論に関わった人が喜びを得た経験や実績，具体的には，それによって画期的な製品に至っただとか販路が広がっただとか，権威ある賞を得ただとかいった実例も，必要ではないかと思います．
新卒研修においては，予習として，そういう事例が書かれた名著または名エッセイを読ませることでしょうかね*3．
自分の「すりあわせ」経験を一つ：
逆算してスケジュールを立てた例
DBゼミへのアドバイス・2008年度版7
ゼミではないんですが，自分が関わったスケジュール管理の例を，出してみますかね．
3人の教員で，毎週，学生向けの問題を作ることになりました．
1回あたり，小さいのなら3問．大きければ1問の問題に，取り組んでもらいます．
問題文コンテンツがない…新規に創らないといけない…状況で，それぞれの先生はそれぞれ業務を抱えているので，まずは毎週こなせるように，日程の大枠を考えました．
水曜日の授業だったのですが，その週の月曜日に，問題内容を確定させ，事務に印刷を依頼すること，そしてその問題文案は1週前の月曜日にメールで流して相互にチェックするとなりました．
1回の授業の問題を3人で作る，ではなく，各回で担当者を決めておき，問題数も，そのときの担当の先生にお任せとしました．
あと，問題文を作るのは，TeXでもWordでもよく，PDFのファイルをやりとりしました．TeXやWordを交わすのなら，作成者以外の人が，手軽に修正できることになります．質を高めるならそのほうがいいかもしれませんが，PDFを原則とすることで，作成者のお考えを尊重しようという暗黙のルールを作りました．
といっても，授業期間終了後には，ソースを含めて集約しました．とりまとめ役は僕が引き受けまして，1人はWord，2人はTeXでしたが，文字コードはEUC-JPとShift JISと，てんでばらばらでした．
そうそう，1週間を「内部レビュー」の期間としたわけですが，はじめのころはなかなか意見がでなかったものの，途中から，意見が出るようになって，そうなってくると，問題文を創る人，修正したほうがいいと思った人との間で，せめぎあいですね．
…と，引用してみたけど，やっているのはX, X', X'', ...だなあ．ちなみにCプログラミング演習（現・Cプログラミング基礎演習）のことです．
*1:摺り合（わ）せ（すりあわせ）の意味 - goo国語辞書
*2:「価値があるかないか」といえば，あります．注意するのは，「その種の問いを与え，考えさせることよりも，身につけさせるべきことがあるのではないか」です．小中高の教育において，ナニナニが必要だという声で導入し，教員が疲弊する一方で児童生徒本人には定着しているとは言いがたいのと同様の構図です．
*3:DIMEを定期購読していますが，カラフルな商品紹介だけでなく，モノクロで文字が多いとはいえ，製品化までの苦労が書かれた記事にも目を通しています．そういえば学生には，年度末の大掃除に合わせて処分するよう，指示してしまったなあ…．
