18-12-09 大学における情報学
夏ごろに「ひつじがランクアップするには」というお題をもらっていた気がするので、大学における情報学との比較を軸に考えてみました。
情報系専門学校生向けの文書です。
不正確な具体例も混ざっていると思うので、なんとなく言いたいことが伝わればよいです。
大学における情報学
「大学の情報系の学科ではプログラミングの授業がない」というのがたびたび話題に上がります。
まずはこの件の本質を考察してみます。
大学における情報学は、学科名としては情報科学、情報工学、社会情報学などに分かれますが、だいたい次のような内容に分かれると思います。(雑)
計算機
アルゴリズム (機械学習、画像処理など)
プログラミング言語、データベース (を作る側)
セキュリティ
ユーザー インターフェイス
VR, AR (の仕組みを作る側)
社会への応用
ビジネス イノベーション
ユーザー エクスペリエンス
VR, AR 活用
最近では「社会への応用」の部分も大学で研究されることが増えています。
いずれにせよ、大学における学問とは「新しい発見または価値を生み出すこと」を志向します。
少なくとも大学院以降で執筆する論文では、何らかのオリジナリティが求められます。
ただし、学部4年の卒業論文でオリジナリティを生み出すことは難しいため、指導教官が課題や手順を設定することもあります。論文執筆が課されないこともあります。
大学生として卒業研究に取り組む前提として、情報学という分野を網羅的に知っておかなくてはなりません。
授業でプログラミングばかり扱っていたのでは知識不足になるでしょう。
数学科で解析学を専門にするにしても、代数学や幾何学の基礎は必要です。
プログラミング言語、プログラミング環境、アプリケーション開発技法などは、情報工学のほんの一部に過ぎないことがわかります。ちなみに大学のアルゴリズムの教科書を見てみると、BASIC や擬似コードが書かれていたりします (単に古いせいかもしれません)。
企業でプログラミング未経験者を募集して社内研修でプログラマを量産しても、短期間でそのレベルには到達できないことが想像できます。
私の知る限り、情報系出身者はプログラミング言語にもかなり詳しいです。卒業研究ではプログラミングせざるを得ないですから。
陥りがちな罠
情報学以外の学生が IT 業界に入ると陥りがちな考え方として、例えば次のようなものがあります。
多くのプログラミング言語を使えるようにする、そしてそれを優位性と思う
プログラミング「言語」を、プログラミング「ツール」とは別のものと見なす
自身の好みで優劣を論じる
多くのプログラミング言語を学んだ結果、得られたものが「そのプログラミング言語を使った仕事ができる」というだけでは十分とはいえません。「言語間における機能の共通性に気付く」であれば OK です。
使いこなせるようになったり、その宣伝をしたりしても、自身の人材としての価値を (相対的に) 高めることにはなりません。
プログラミング言語や開発ツールがその人自身の成果ではないからです。
プログラミング言語を作る側でなければ「プログラミング言語が専門」とは名乗れないでしょう。
概念の重視
情報学では概念・抽象化をより重視します。
「プログラミング言語」の上位概念は「プログラムを作るための道具」です。
同じことが実現できるのであれば、言語である必要はないのです。
不毛な議論に陥りやすいのは、以下に挙げるようなパラダイムの優劣について議論することです。
手続き型、宣言型、オブジェクト指向、関数型、コードの自動生成 (AltJS なども含む)、・・・
多くの開発手法が「同じことを二度繰り返さない」の精神を持ち、所詮は機械語に対する構文糖衣に過ぎないことを理解すると途端に腑に落ちると思います。
プログラミング言語は機械語に対する構文糖衣 (syntactic sugar) に過ぎない
プログラミング言語は、プログラミングの概念に対する実装である
分岐、ループ、コレクションなど
「概念を理解する」と「概念を理解せずに使う」は別の行為である
同じ概念を達成できていれば、その実装は実質同じものである
ビジュアル (GUI) か、テキスト (コード) か
具象を2種類以上経験して考察するとよい
「銅鑼右衛門に会話で仕様を伝えるとアプリを作ってくれる」というのも「プログラムを作るための道具」に含まれるでしょう。
伸太「銅鑼右衛門ー、新しい道具作ろうぜ！お前道具を作るための道具な！」
その他、細かい内容は下の「付録：技術補足」の章に書きました。
引用) 抽象化することで寿命が伸びる、具体的なものは寿命が短い
オリジナリティ
プラットフォームに依存する内容など、(時間を要するかもしれないが) 調べればできる程度の知識では人材としての優位性にはならないでしょう。
引用) 論理的思考能力等を会社で育てるのは難しく、逆に開発に直結する部分は会社で教えることが比較的容易である
これは、同じ役割を担当できる人材の代替はどれだけ少ないか (希少性) と言い換えられます。
あえて地獄専用、バッドノウハウ専用の人材になるというのもありだとは思います。
とくに学生時代は最初の就職先が決まる時期であり、有限の時間で何をするかが影響してきます。不毛な議論に時間を費やすべきではありません。この先何年にもわたって自分がオリジナリティを出せる分野は何かを問い続けましょう。
なお、大学ではレポートや発表など、深い考察が必要となる試練の場をカリキュラムとして提供している、というのもレベルアップに寄与していると思います。
世の中に存在しなかった何かを生み出したという感覚を経験していることがポイントで、近年の企業でもこれを重視するようになってきています。この経験がないと、なかなか的確な事業を企画することができず、二番煎じ (他社がやったからうちもやる) を繰り返すことになってしまいます。
研究や製品開発ができる人か、与えられた仕様のプログラムだけを作る人か、という違いです。
いま理解できなくても、一年後に再び読むと多少は理解できるようになるでしょう。
ちなみに私は吹奏楽を高校から9年間やっていましたが、与えられた譜面をもとに演奏するだけでは新しいものを生み出している実感がなく、興味がなくなりました。プログラミングも同じですね。いま興味を持つとしたら「曲を作る」「楽器を作る」「楽器を文字入力装置として使う」とかでしょうか。
付録：技術補足
(1) プログラミングの機能
多くのプログラミング言語で現在既に実装されている機能の範囲で議論するのは面白いとは思いません。
大学の情報工学で論じるなら、「将来あるとよいプログラミングの機能」ならよいでしょう。
その一例として、形式的検証・定理証明が挙げられます。
現状の静的型付け言語でも部分的には形式的検証をしていることにはなります。
(2) パラダイムの相互変換
例えば、UI の表示を手続き型のコードで書いたとしても、部品やツールを作るタイプの人が再利用性を目的としてリファクタリングすると宣言型になります。
このように、抽象化することでパラダイムが変換されることがあります。
同様に、雑多な情報も整理すればデータベース、そしてオブジェクト指向となります。
(3) ツリー構造
字句解析を経験した人は分かると思いますが、ソースコードを字句解析した結果はツリー構造になります。
.NET では Expression Tree (式木) という言葉があり、まさにツリー構造を表しています。
したがって、手続き型言語のソースコードを XML で保存する (あるいは、Scratch のように GUI で表現する) ことは自然な選択肢であると考えられます。むしろコンパイラを実装する人にとってはそのほうが楽でしょう。
ちなみに、こちらのツールを作ったときは処理を XML (XAML) で記述していました。