klisを卒業して3年目のエンジニアがklisを振り返る
この記事はklis Advent Calendar 2016の18日目の記事になります。
なぜ書こうと思ったのか
理由は2つで、1つは「klis」(知識情報・図書館学類のこと。Knowledge of Library Sciencesだったっけ?)という文字を見た瞬間に懐かしくていいなと思ったからです。2つめはおせっかいながら後輩にメッセージを送りたいなと。klisからエンジニアになる人ってそんなに多くないと思うので、そんな人から見てklisとはどうだったのかという話があっても面白いかなと。
簡単な経歴
話を進めていく上で多少私のことも話しておかないと温度感が伝わらなさそうなので簡単にどんな人なのかを話したいと思います。
大学時代
日々のプログラミング課題にひぃひぃ言ってました。プログラミングはそんなに得意ではなかったですが面白かったのでシステム主専攻に進みました。
将来なろうと思った職業は司書→公務員→リサーチャー or エンジニアというようにいろいろ寄り道しましたが最終的にエンジニアを選択しました。
社会人になってから
入社研修も含めるとAndroid開発、webアプリ開発(一応サーバサイド、フロントエンド両方)、iOSアプリ開発、検索チューニングを広く浅くやっています。あとグロースハックを担当していたこともありました。一番長くやっているのはiOSアプリ開発です。業務で使った言語はSwift, Objective-C, Java, Ruby, Python, JavaScriptです。
私がklisで学んだことを振り返る
klisでホントいろんなこと学んだなと思います。図書館に関すること、主にRubyを使ったプログラミング、経営、数学、調査法…。文系理系に囚われない幅広い授業は大変でもありましたが面白くもありました。
klisを振り返って良かったと思うこと
エンジニア観点で「この知識を学べて良かったな」と思うのは大きく分けて3つあります。
1つはもちろんプログラミング系の知識です。変数って何?から始まり全文検索システムやチームで考えたシステムを作るというのは仕事の知識に直結します。私の場合はwebアプリ開発と自然言語処理の知識は業務に直結したのでよかったです。
2つめは経営学です。プロダクトライフサイクル (PLC)は開発をする上で頭に入っていた方が良いものですし、会社・組織とはどのようなものなのかを学ぶこともできました。あと確かリーダーシップの話も授業であったような気がするのでマネージャーになるときには役立ってくると思っています。経営学検定初級を受けておいたのも良かったかもしれません。
3つめは調査法です。私は量的調査法、質的調査法、多変量解析を取っていました。プロダクトをより良くしていこうと考えた時に、手っ取り早いのは量的調査ですが、「なぜ」を知るためには質的調査も行わなければなりません。そうやって集めたデータは分析をすることになるわけですが、本当にその結果に隠されているのは1つの変数だけなのかなどと考えて分析しています。学んだ手法がそのまま役に立っているというわけではありませんが、抑えるべきポイントは学べたと思っています。
klisを振り返ってイケてなかったと思うこと
エンジニア観点で「これはちょっと...」と思うのは大きく分けて2つあります。
1つめは、とりあえず書いて動かしてみるというところに終始していて、プログラミングの基礎概念的な話はあまり聞けなかった気がすることです。例えばオブジェクト指向とは何かという非常に重要な概念についての説明はなかった気がします(たぶん)。なので私は入社するあたりになってからオブジェクト指向を理解し始めました。
2つめは、言語の特性を理解する機会がなかったことです。基本はRubyでのプログラミングでしたが授業によってはPHP, Java, Perlを使っており、なぜ言語を変える必要があるのかを理解しておらず「書き方が変わって大変だなー」くらいにしか思っていませんでした。
あとは入社してから同期と自分を比較して圧倒的に実装力のなさを感じましたが、それはklisが悪いというわけではなく、本人の努力不足による部分が大きいかなと思っています。はい。
もしもエンジニアを目指すなら
やっておくべきこと
普段からコードの意味を理解しながら書くようにしましょう。普段web上のコードを特に何も考えずコピペしていたりしないでしょうか。意味も考えずコピペするのはとても危険です。web上に載っているコードは必ずしも合っているとは限りません。今は誰でも記事公開できちゃいますからね。なんならAppleが動かないサンプルコードあげてたことありましたしね。コピペ自体が悪いというわけではないですが意味を理解して自分のコードに落とすようにしましょう。
やっておくと良いこと
きれいなコードを書くという意識を持ちましょう。あまりうまい例えではありませんが学校の授業のノートを取る場合、色やインデントをうまく使って書かれたノートと、とりあえず要素が詰まっていればいいと言ってツメツメに書いたノート、どちらの方が良いノートでしょうか。もちろん前者ですよね。開発をする上で読みやすくよく、リファクタリングされたコードを書くことは大切です。例え開発者が自分だけでも、過去の自分が何やってるかわからないときってたまにありますからね。。。きれいなコードを書くにあたってリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニックは非常に参考になります。エンジニアの必読本です。
総合科目(という言い方だっただろうか?)や一般の授業で他学の授業を積極的に取るのもいいと思います。私は芸専の色彩の授業や情報科学のインターフェース系の授業は今も役立っているなと思います。体系立って教えてくれるのは大学で最後だと思うので、気になる授業があったら(移動は大変だろうけど)取ってみるといいと思います。
あと今思えば学生のうちに勉強会やカンファレンスに行っていたら意識は変わったかもしれないなと思っています。私はconnpassを毎日チェックしていて週1とかの頻度で勉強会に行っていますが、結構刺激を受けます。「こんな便利なものがあるのかー使ってみよー」「他者、他人がこんなすごいことやってるのに自分は...」などなどいろいろ思います。学生のうちにこんな刺激を受けていたらもっと勉強頑張ったんじゃないかとは思うんですよね。学生が行ってもいい勉強会やカンファレンスはちょいちょいあるので(遠くて大変だと思うけど)行ってみるといいと思います。
最後に
まあつまり総合的に考えると広く学べてよい学科だったと思います。なので「大学の授業とかたるい」とか思う気持ちもあるかもしれませんが、ぜひちゃんと聞いて知識を身に着けてほしいなと思います。
何か聞いてみたいことなどあれば@akatsuki174までお気軽にどうぞ。