NAL’s blog @ 琉球大学情報工学科

新入生向けイベントその3「どの講義をどう登録したら良いか」を説明する履修指導(要認証)が終わりました。昨日のインストール大会でインストールできなかったXcode関連は過半数がドキュメント＋自力で終了してました。それぐらいのドキュメントを用意したシステム管理チームも、自力で進めた新入生も素晴らしいです。まだの学生も2割ぐらい？いるっぽいですが、今日の説明をする前にXcodeのダウンロードをさせておくだけで留めておきました。月曜日にまた集合するイベントがあるので、そこで最後の仕上げをやる予定です。

今日は、e13向けまとめサイト(要認証)の紹介、1年次前期に登録する必要がある科目の説明、そのために実質的に1科目分しか自由度が無いこと、シラバスの検索方法や見方、実際の登録方法、ポイント制、講義毎に受講できる人数上限数との兼ね合い、教職希望者向けの補足といったことの指導がメインでした。10名ぐらいの先輩らが駆けつけてきてくれたお陰で至らない部分の補足は大助かりでした。インストール大会含めてただ働きしちゃってる学生が少なくないですが、適宜声かけしてくれればご飯ぐらいはおごりますよ〜。

昨日（岡崎先生に）実施して貰った数学プレースメントテストの結果、20名弱ぐらいが学科提供の数学基礎演習の受講必須との結論に。苦手なのは苦手だと意識してもらって構いませんが、壁を乗り越えられるよう頑張りましょう。

後半で「16単位未満除籍」等注意事項を説明した後は、各自必修科目を登録申請してみるなり、何を受講するか探すなりして12時前まで先輩ら含めて個別対応して貰ってました。解散前に「まおゆう知ってる人？」と聞いてみた所ちらほら聞いたことがある的な反応が。いくつかカリキュラム内外でのお勧め記事をまとめてると紹介した中の一つがまおゆうの原作（魔王「この我のものとなれ、勇者よ」勇者「断る！」）なんですが、終了後に少なくとも一人は熱烈なファンがいることが判明。アクセスログ眺める限りでは17名(ユニーク数)はアクセスした可能性があるらしい。これだけいたら後はそう遠くないうちに全員に広まるよね？　ということで「お前の目指す丘はどこだ！？」と4年間言い続けるプロジェクト（誰が何と言おうとこれは履修指導です！）が開始です。最後に新入生歓迎LT祭りの紹介もしたし、主催者も紹介したので伝え忘れたものは無いはず。

履修指導には4名が欠席してて、うち1名は事前連絡ありで午後過ぎに個別対応。連絡なかった別の1名も学内にいることが分かったので呼び出して個別対応。残り2名もこの記事書いてる時点で連絡が取れて、無事に講義登録が済んでることを確認できました。事前事後の連絡が無かった学生には報告するよう指導しつつ、一先ずは安心できるようです。

ただ、教務情報システムは落ち過ぎ。アクセス集中し過ぎなのが影響してるのは明らかなんですが、そうなるようにスケジュール組んじゃってるしね。ちょっとあれは改善の余地ありなんじゃなかろうか。年次懇談会ではそういうのも含めて意見収集するので、気になる点があったら忘れずにメモっとこう。

4月から東北に行くあっち〜さんとタイミングが合ったので、壮行会的にランチ。野菜のおいしいお店ということで最初は農場カフェを予定していたんですが、午後が詰まっていることもあってそこよりは少し近めのZumZumに。同じく今月一杯で移動になる野崎さんのプロジェクトで働いてた方ともご一緒して、新2年次になる人に「世の中は怖いよ」的な話で盛り上がりました（半分誇張）。

午後は「情報工学科運営戦略研究会」という名目で、外部の方と情報工学科の将来について「産業界や官はどういう期待をしているか」ということについて意見交換をしてました。JABEE受審してた頃は諮問会議という名前でやってたことに近いですが、今回からの「戦略会議」では必ずしも何かしら抱えている問題について意見を乞うという形に限定せず、より広い視点も含めた話もできるようにということで名称変更しての再スタートとのこと。

今回の話し合いで出てきた「求めている人材像」や「こうしては」という提案的なコメントを以下に列挙してみました。いろんな立場の人の意見をそのまま書いてるので読みにくいかも。これ全てを満足することを目指すのではなく、卒業後の将来像を思い描く際の参考に一つ二つ含めて描いてみるのが良いんじゃないかと。

[ 運営戦略会議で出た意見の例 ]

• 打たれ強い人が必要。叩かれても大丈夫な人。
• 枠にはまらない人。尖った人。皆が同じことやっても全然進まない。
• 問題を解決する前に、問題を設定する力。解けるように問題を作る。叩かれながら直していく。逆風に耐えながら修正していく。
• 自分を信ずる力。Serendipity を大事にして欲しい。幸運をつかむ力。何が幸運かは分からない。後になって初めて「あっ」と気づく。やってみないと分からない。何があっても良い方に考える。
• 総合大学であることを活かして、他学部他学科のことにも目を向けよう。外部のコンテストやプロジェクト等に応募することでもいろんな出会いを体験できる可能性が広がる。
• クラウドの中の人とそれを使う人。中の人だと昔のサーバ班のようなことの巨大版。ネットワークを設計、設定、環境構築できる人。それのスモール版での演習があると嬉しい。使う人だと、例えばSaaSとか。データ解析、ビッグデータからどう付加価値を生み出していくかという人材。統計に強い人への需要が大きい。「解析しました」だけではなく、「繋ぎ合わせてこうしたらもっと良くなりますよ」とか提案できる人。
• 統計については、一通りの解析技術を身につけて適切な技術を選択するというタイプと、新しい手法を提案できるタイプ、できれば両方を身につけて欲しい。新しい手法の提案タイプについては現場の実戦経験が要求されるだろうから、そこは産学連携なりで互いに強調し合う方法もある。
• スマートフォン周りだと、現在はApple Storeとか個人で出せる市場があるので学科なり研究室なりでユーザに提供し、お金を儲けるという所までやって欲しい。何故かというと、エンジニアは自分の視点に寄り過ぎていることが少なくないので、市場が何を欲しているかということを味わって欲しいから。それを体験する中で味わった苦労が役に立つ。
• トップダウンではないが、トップの学生にはサポートしてより高い目標を持ってもらいたい。何も考えずに入学してきた学生には基礎的なもの。学生を一緒くたに語ることはできず、2面性、3面性があるように思う。そういうレベルで層を分けて取り組む必要があると感じている。
• 1年次の段階で、4年間での学習していくプランを考えさせるのはどうか。自分はどういう仕事に就きたいのかということを明文化させるのも良いんじゃないか。最終的にどう卒業してどう働いていくか。
• 向き不向きがあるのは当然だが、修士だけじゃなく大卒にも何らかの形でリーダーになることを期待している。社会では基本的にグループでの作業になるため、少なくともリーダーを経験しておくことで「リーダーに何が求められるか、グループとしてどのように行動すべきか」といったことについて様々な視点が得られるだろう。

P.S.
似たような話題としてはNLP2011, 併設ワークショップ「自然言語処理における企業と大学と学生の関係」も参考になるかと。

NLP2013の前夜祭的なイベントという認識ですが、チュートリアルが終了しました。大会場はテーブル付いてて割と電源も豊富で無線LAN完備。地下鉄の駅出口から徒歩1分。名古屋は地下鉄移動が便利すぎて地図的な位置関係が全く脳内構築されませんｗ

午前中に参加した「言語処理研究におけるソフトウェアの開発と公開」は3部構成。

最初の「研究を進める上で有用なコーディング極意」では、大学というか研究室で繰り返されているであろう負の連鎖（〆切直前に結果の誤りを発見、コード複雑すぎて解読不能、結果が残っていない、etc.）に対してどう取り組んでいるかという話。言語処理100本ノックではUnix的な極意（小さく分解して、細かい部品毎に正しく動くようにし、様々な組み合わせで問題に取り組み、簡単に再現できるようにする）のを自然と学べるように構成を工夫しているらしい。研究室で取り組んでいるだけあって、論文化することを最優先することで「最終的に何をどう用意したら良いか」を一通りこなして初めて振り返られる気づきを得られるという話も。個人的には学部3年次向けの実験としてどう設計しようかと悩んでいるところですが、100本ノックを真似るところからやるのもありかなぁ。

2番目の「研究で開発したコードの公開」では、（検証しているところのみに重点を置いているという意味で）一点突破型の実験コードというレベルと、一般的なソフトウェアというレベルに分けて考え、実験コードでもどしどし公開しようという話。そうしないと再現困難だったりするし、（公開を前提としたレベルでドキュメント化してないと）研究室内でも引き継ぎにくいから財産となりにくく埋もれてしまうよね、と。公開するからには最低でも「結果を再現できる」だけの情報は付けよう。知財の絡みで公開困難なケースでは、バイナリ提供やデモサーバ公開とかいう形もあるよねという話も。

3番目の「企業における自然言語処理と開発手法」では、企業だからこそ求められる（求めていく必要がある）品質を改善・可視化するためにもテストが必須で、結果として「正しく動いているか（ソフトウェアとしての品質）」というテストと「解析結果が正しいか（自然言語としての品質）」を明確に区別し、自然言語の質を高めることに注力することにも役立つという話。今回は「単体テスト」レベルの話で、言語処理の品質、例えば「東京都」という文字を形態素解析させた結果が「東、京都」になるのか「東京、都」になるのかどちらかが正しいかというのはソフトウェア・テストとしては設計不十分で、スタブによる仮モジュール（この例では辞書を設定するとか）の導入や、モックにより関数／メソッドが正しく呼ばれているかを検証することで「ソフトウェア的な意味での品質」をテストしやすくなるよ（その分本当にやりたい言語処理の品質改善に注力できるよ）、と。個人的にはスタブ＆モックするようなレベルでのテストはやったことないのですが、「テストのテスト」が必要そうになりそう点を懸念してしまったり。

午後のチュートリアルは「言語処理の後先（あとさき）」に参加。従来の多くの言語研究（主に心理実験を用いた語彙獲得や認知に関する事例）では元々曖昧な概念である「語彙」が分かりきっている前提で進められているが、そこをあやふやなまま進めてしまって良いのかという問題意識があり、言語だけに特化せず身体を含めたり、そもそも一人だけをモデル化するのではなく二人をモデル化してみないと見えて来ないものがあるよね等、多岐に渡る事例を交えながらの「意味はどこから来てどこえ行くのか」という話。個人的にも賛同している視点で、語彙がそもそもあやふやだという話は

• 認知科学の今井先生が言う所の「連続的に推移する世界はことばによって離散的に分節され、カテゴリーを発見・想像・修正を繰り返すことで多層的かつ重層的に捉える」
• 医学・認知神経学の大槻先生が言う所の「視覚情報では認知できなくとも非視覚情報では認知できたりすることから、入力モダリティ毎に意味システムを構築していると考えざるを得ない」
• 場の言語学で言う所の「身体を通した自己の二重性と即興劇モデルに基づく共存在の深化（身体と身体、身体と環境との相互作用）が主体的な意識を形成し、コミュニケーションが産まれて言語へと発達した」

に共通している話かなと思いながら聞いていました。ジェスチャーに「話をする負担を減らしている側面がありそう」という解釈（できなくもない結果）も面白かった。

終了後は学内にあるスタバで学生の発表資料チェック。晩ご飯はホテル近くで適当に探した手打ちうどん　五城で食べてきました。味噌煮込みうどん美味しかったんだけど、ひょっとして煮込みうどんだと「手打ち」じゃない専用のうどん麺なんだろうか。普通のもちもち触感のうどん麺で煮込みうどん食べたいんだけどな。

以下、参加したチュートリアルのメモです。

• チュートリアル T-a, 言語処理研究におけるソフトウェアの開発と公開

• 研究を進める上で有用なコーディングの極意（岡崎）
• 研究で開発したコードの公開（吉永）
• 企業における言語処理研究・開発（工藤）

チュートリアル T-a, 司会：ニュービッグ グラム (NAIST), 言語処理研究におけるソフトウェアの開発と公開, 岡崎 直観 氏（東北大学）, 吉永 直樹 氏（東京大学）, 工藤 拓 氏（グーグル株式会社）

研究を進める上で有用なコーディングの極意（岡崎）

研究を進める上でのコーディング作法は教えてくれない
　（自然言語において）研究の成果物は知見（論文）であって、作ったソフトウェアそのものではない　ソフトウェアエンジニアの仕事とはかなり違う
　　　対象：仕様が決まっている vs 解かれていない問題
　　　目的：利益を得る vs アイデア（実験結果）を検証

言語処理100本ノック
　小さい処理に分解し結合せよ
　道具を使え
　自分を過信せず検証せよ
　常に検証に備えよ
　研究成果を可視化せよ
　最適化・整理は完成してから
　論文を書いたらコードを整理せよ

naltoma: 学部3年次向け（プログラミング導入は済んでいいるがまだ研究室に配属していない、
　専門が決まっていないという段階）でも、
　普遍的な能力を養うという点では同じ方針でやれそうかしら？

Q: 100本ノックについて、具体的にどうやって演習する？
A: 1週間に1回2時間問題を解いてきて皆でレビューする。
　先輩をチューターにつけて、討論。

研究で開発したコードの公開（吉永）

研究者がコードを公開する意義
　実験結果の再現性を保証
　　公開しないと実質的に再現困難
　ツールとしての共有資産化／研究成果の社会への還元

2種類のレベルでの公開：実験コードとソフトウェア
　実験コード
　　一点突破
　　公開するコードをまとめる／README（再現方法）／使用条件／研究手法と対応付けて公開
　公開できない場合
　　コード・READMEを引き継ぐ
　　バイナリ形式での公開／デモ・実験サーバの提供／代理実行
　公開をためらう場合
　　そのコードで削減される時間があることを意識する　　
　ソフトウェア
　　ソフトウェア化に値する手法はごく一部
　　多様な価値観に晒される

naltoma: うちの学生にも公開前提でやらせてみよう〜。

Q: 論文書き上がる頃にはコードがごちゃごちゃしてて出すのは忍びない。
A: 実験コードレベルで終わるのか、ソフトウェアまでを想定しているのかを
　意識してコーディングしていくことも重要かと思う。
　実験コードについては割り切って出すのが良いのでは。
Q: 仕様固めてから研究しても、研究している間に仕様が変わっていくことは良くある。
A: あまり綺麗なコードといってると研究が進まない。
　時間のある範囲で綺麗なコードで十分では。
　まずは1,2回公開してみると掴めることもある。

Q: プログラムの公開について、言語やインストール方法とか様々あるが。
A: 重要なことだとは思うが、個人的にはC++で書いている。
　できる限りプラットフォーム・フリーにしたいと考えている。
　ダウンロード数を見る限りでは圧倒的に Windows 版が多い。

企業における言語処理研究・開発（工藤）



2種類の品質
　ソフトウェアとしての品質
　自然言語処理としての品質
　　テストの役割
　　　予期せぬ動作と解析誤りの明確な分類
　　　コミュニケーションの道具
　　　人材・プログラムの流動性が活発（弄りやすい／引き継ぎしやすい）

ソフトウェアテスト
　リファクタリング
　テスト駆動開発：失敗するテストをコーディング前に作成
　YAGNI (You ain’t gonna need it)
　　必要になるまで機能追加しない原則
　　コードの不必要な複雑性を排除
　　適度なコードの抽象性はテストによって担保される

解析誤りと正しい動作を混同しない
　テストダブル (Test Double)
　　あるシステムが依存しているコンポーネントを置き換える代用品
　　依存先が常にあるとは限らない
　　スタブとモック
　　　スタブ：決められた動作だけを行う代役（e.g., 必ず false を返す）
　　　モック：メソッド呼び出しの検証を行うための代役（e.g., メソッド呼び出し回数を記録するカウンタ）
　　　stub を inject して mock しながら検証
　依存性の注入 (Dependency Injection)
　　コンポーネント間の依存性を外部から動的に注入できる設計
　　何に依存するかは実行時まで分からない
　　DIコンテナ
　十分なテスト（正しい動作）をすることで、真の解析誤りに注力

評価
　機械的・平均的評価
　回帰テスト：「絶対変換・解析で気無いとまずい」例によるテスト
　ユーザビリティテスト
　見える化

naltoma: テストのテストが必要になったりしそう。
　テストの自動生成でなくても良いけど、テスト作成のコストを下げられないか？

Q: テストについて。大学レベルではそこまで使われるのか。
A: 多分、大学ではやる必要は無い。
　ただし、形態素解析作ってたりすると「当たり前のことを間違える」というケースが多い。
　回帰テスト用意しとくだけでもいろんな応用が効くと思う。

チュートリアル T-c, 司会：丸山 岳彦 (国語研), 言語処理の後先（あとさき）：意味はどこから来てどこへ行くのか．, 齋藤 洋典 氏（名古屋大学）

言語活動／心的活動／意味処理活動／心理実験／脳イメージング／言語と行為の関係
はじめに
　言語と身体（言語処理と非言語処理）
　　身体運動を含む多様な処理を認め、意味を創出し理解する仕組みは「どこから来てどこへ行くのか」。
　　　e.g., ジェスチャー：必ずしも意味を特定する訳には使われないが、未だに使われ続けている。
　意識と脳（意識処理と非意識処理）
　自己と他者（一人の脳と二人の脳）
　　言語は本質的に他人との関わりの中で発展してきた。

語彙と語彙接近モデル
　そもそも語彙／語は曖昧
　心理学での語彙研究：語の連想記憶／語と知能／単語の読み
　　単語優位効果：学習＝概念と概念の結びつき。単語の中にその力が含まれている（？）。
　問い「意味（こころ）は脳のどこにあるのか？」という問いは適切か？
　　そもそもどこか1カ所に貯蔵されているもの？
　従来の語彙接近（lexical access: 単語検索）：限りなく近づくが、到達はしていない。語彙性判断。

　　問いかけ：言語だけが浮き上がってくるのは何故か？
　　問いかけ：手（ジェスチャー）での処理が先に終わってて、後から言葉が修正することもある。
　　残された課題
　　　多感覚入力／複数出力の処理統合。非言語処理、身体運動、意図理解等。
　　　話者/聴取に閉じないモデルの構築。一人の脳から二人の脳へ。

漢字の読み処理
　見える「もの」と見えない「こと」
　漢字「で」研究
　講義の意味理解：少ない情報でより確実な未来を予測する
　読み間違いは目の誤りではなく脳の誤り
　　漢字の形態要素の配置と音韻の両方で起きる。
　　部首の位置と音の確率的な結びつきの知識を持っており、それらの影響を受ける。

発話と身振り
　発話に伴う自発的な身振りは、だれのどのような役に立っているのか？
　　半分は自分のため？
　　表象的身振り（発話と関連する意味的な内容を描く身振り）
　　ビート（意味的な内容を含まず、単純でリズムに乗った身振り）
　　聞き手指向／話して指向 vs 対面パラダイム [Alibali et al., 2001]
　　　話し手は、聞き手が見えない状況でも身振りを算出するか？
　　　　減りはするが、無くならない
　　　　カメラを通した想像条件でも無くならない
　　　盲人同士（見たことも無い）がジェスチャーをする
　ジェスチャーが発話者本人にとってどういう意味があるか？
　　スピーチの負担が減る（？）
　　　e.g., 第2言語ではジェスチャーが増える≒フレーミング（枠組み構築）に使っているのでは

行為と言語化
　ボールを投げる動作／投げるシミュレーション／観察／言語化が同一の機能なのか？
　　10分前にやったことは後続観察課題で想起されるが、それを言語化するとdischargeされる

一人の脳から二人の脳へ（脳機能の連携による意図と共感の算出と理解）
　行為も言語化もせずただ認めるだけで、脳の特定領域が活性化される

naltoma: ヒトと同等のセンサを有するロボット（≒身体を有する何か）を作り得たとして、
　そのロボットが「ヒトと同様に感じ、語彙を獲得し、学んでいく」ためには何が必要だろう？

Q: 漢字の例で、似ている意味、似ている音が間違いに寄与しているのではないか。
A: 漢字に関するデータを見る限り、まず形の類似性が間違いを大きく引き起こす。
　音も引き起こすケースはあるが、音単独では起こらない。そのぐらい、脳は賢い。
　脳はあってるがそれを報告するヒトが（気づかずに）間違うこともある。
　脳は知っているが、explicit にはヒトが知っていないことがある。

ただの一般論ですが、何も考えずにレポートをコピーしてる問題について。

[ 前提: こんなことに労力割きたい訳ではない ]

他人のレポートを参考にするために参照するという行為は、基本的には「他人の視点が得られる」という点で「他の文献を読む」のと大差がないです。そういう意味（参考にするために参照するという意味）で、私自身が担当している実験では「先輩のレポートを参考にするのは良い。ただしその場合には参考文献として示せ。そうでないレポートは盗作なので大幅減点となる」と宣言しています。

「他人のレポートを参考にする」をもう少し掘り下げて書くと、「参考にするために他人レポートを参照する」パターンには、

1. 他人レポートと自分自身の目的が100%合致している。
2. 他人レポートと自分自身の目的が過半数合致している。
3. 他人レポートと自分自身の目的が部分的に合致している。

ぐらいのケースが考えられるかと思います。

学生への課題というケースでは、100%合致しているケースもそこそこあることでしょう。この場合には、レポート全体をコピーすることでも「レポートの目的」は達成することが可能です。ただし、参照したレポートが100%正しい場合の話。冒頭で挙げた問題は参照先の一部が間違っていたケースですね。コピペも一つの技能ですのでそれを磨くことは推奨していますが、参照先が誤っているかどうかも見抜けない程度の理解度（参照度）だと何も磨いていません。結果として、コピーしている学生も、それを採点しようとする教員も、リソースを無駄に使っています。互いにそんなことをしたい訳じゃないよね？

参照するからには、言い換えるとコピーするからにはそれなりに参考文献（ここでは他人のレポート）を読み込み、理解する必要があります。何らかの形で理解度を深めることは無意味じゃないですし、一度理解しようと歩み始めると「レポートの穴」に気づいたり、何でこう考えたのだろうという疑問が湧き出たり、他のアプローチを思いつくなど、「貴方自身のこれまでの体験を加味した何某か」を考え始めます。これが参照（と同時に出典明示）を推奨している理由でもあります。そこには何かしらの歩みがあり、その歩みを事実として第三者が理解できる文書（＝レポート）としてまとめるためにも技術（レポート（報告書）や論文の書き方）が必要ですが、それはまた別の話。少なくとも「こういう意味での歩み」をして欲しいから課題を課していて、レポートを出させています。言い換えると、「歩まない（≒理解しようとしない）」ならそれは「レポートの目的の達成」にはなっていても「レポートを課した目的の達成」にはなっていない、ということです。

やや蛇足ですが、目的が部分的に合致している文献（やオリジナル）を参照する際には別の注意が必要です。少なくとも「参考文献が述べていないことを述べたことにしたり、誤解を生む形で引用する」ようなことは避けましょう。どこからどこまでが参照したもので、自分の意見はここだ、ということが分かるように参照するようにしましょう。そうしないとオリジナルに失礼（場合によっては詐欺）です。

関連記事:

• レポート（報告書）や論文の書き方
• 参考文献に頼ろう
• 参照文献はなぜ必要か : その目的と機能

初mouのつもりが、ランチは日曜＆月曜のみらしい。無念。ということで通堂の台湾ラーメンを初体験しましたが、生姜とニラが多めに入っているのはちょっと嬉しい。

河野先生ツイートによると「エラー出力を気にせずレポートに転記して提出する学生」がいるらしい。1行1行目を通して理解できない所が無いのか気にしてたら気づくはずなんだけど。勿論人間なので「見落としはあり得るけど話聞く限りでは同じレポートコピーしてるっぽいので、単に中身を見る気が無いだけなのかなと。そういうのを広めてる人だけじゃなくそのまんま写してるだけの人も、高い学費払って何したいのか一度振り返ってみた方が良いんじゃないかなー。別に大学卒業することが人生の目標でもないし、時間は有限だし。

卒研だと基本的には最終発表がメインですが、修論では事前の予備審査が一つの山場です。予備審査の時期は、論文提出締め切りの2/10（は休日なので今年は2/8）以降の早い時期で調整することが多く、2/11〜2/15の週で殆どの学生は審査されるのだろうと想像します。最終発表日は通知によると2/28らしい。

予備審査では主査1名（メインの研究指導者）と副査2名（分野が近い先生のこともあればとても遠いことも）の先生を加えた3名の先生に囲まれた状態で合計1時間かけて審査を受けることになります。時間内訳は30分発表（修論説明）し、その後に20分強の質疑応答、その後審査結果を出すことになります。内容によっては「これじゃ修論として不十分なのでホゲホゲを追加すること」といった要求をすることもしばしばで、実際その後の最終発表までの期日を徹夜状態で過ごしてた学生も目にしています。ということで、修論審査を受ける皆さんはそうならないよう今のうちに頑張りましょう。

という時期ではあるんですが、今年は卒論〆切の方が手前にあるので、卒業予定者はそれ以上に頑張らないとマズいですね。卒論の発表会は2/21、2/22ということでもう1ヶ月切ってますね。

明日はソフトウェア技術者サミット in 沖縄　「知のフリマ（拡大版）」というイベントがあるらしいのだけど、イマイチ周知されてない気がするけど、私が気づいていないだけなのかな。

延び延びになってたデザートもんじゃの会をしつつ、河野先生が「プログラミング1（1年生向け必修講義）」を担当してた頃に受講していた人らから当時の様子をあれこれ聞いたり。元々の発端は、プログラミングに限らないのですが、情報工の講義としてどういうのを提供していくか、どういうのが欠けているか、その一例として「プログラミングはアセンブラから教えることで理解しやすくなる？」みたいなことが気になって、該当者から話を聞いてみようというのが切っ掛け。

あれこれ聞いた印象をまとめると、当時の全体構成としては「Perl6割 + Java2割 + アセンブラ2割」ぐらい。Perlで逐次処理＋構造化プログラミング（条件分岐、繰り返し）をやりつつ、TkでGUI。あれこれデジタルな環境に触れつつ「Hello World!」だとあまりにもギャップが大きすぎることや、やるからには目に見える例題が良いよねという方針だったらしい。ここら辺は今のゲーム周りでやってることとそのまま通じてる話じゃないかと。

その延長としてJava Applet3週間ぐらいやってたっぽい。順番的には最後にアセンブラで、レジスタがどうのこうのというのがいきなりでてきて混乱の渦に巻き込まれつつ、2年次の実験（吉田先生のアセンブラ）で「あ、あれはこういうことだったのか！！」と体感するという。数年後に「そういえばこういうことやったな」と気づけるような種まきをしているというのも、河野先生講義の方針と一緒じゃないかと。

という話をあれこれ聞いた結果としては、やっぱり「前提知識無しでいきなりアセンブラはキツそう（最初からアセンブラやったとしてもプログラミングへの取っ付きにくさ解決にはならなさそう）」ということか。20歳を過ぎてからプログラミングを学ぼうと決めた人たちへにもあるけど、大学の強みの一つはpp.87-98にあるような「円を描くように、いろんな分野の知識を積み重ねること」で自分の足で未開の地を歩くための手段を得ることだと思う。何度か書いてるけど「図書館は一つの象徴。Webが広がり根付いてる現時点でもその役割は大きく、図書館という名の「先見者の視点で描いた物語」は面白いし、そこから見つけられるものはいろいろありますね。本一冊/講義1つ/勉強会1つ等でどうにかしようというのが無茶な相談なだけ」なんだよね。

それに対して、世界は広がる一方なので pp.101-121にあるような「どのルートで行くにせよ、どれだけ早く進めるか？→ e.g., 小刻みのステップ」もとても大切な視点だと思う。どこで躓くのかは分からないしね。いろんなレベルの「概念」がありえるけど、それらの繋がりとして次のステップを見つけていくというのは一つのアプローチでしょう。