Hatena::Groupbugrammer

蟲!虫!蟲!

Esehara Profile Site (by Heroku) / Github / bookable.jp (My Service)
過去の記事一覧はこちら

なにかあったら「えせはら あっと Gmail」まで送って頂ければ幸いです。
株式会社マリーチでは、Pythonやdjango、また自然言語処理を使ったお仕事を探しています

2013-06-30

[] 人工無能について興味を持ち始める 03:12

始めに

 実は、ちょこちょこと機械学習について調べているのですが、元文系である自分としては、数式であったりとか、アルゴリズムの理解とかが大変な感じで、理解がなかなか追いつかない感じです。

 「機械学習」は、一般的には「人工知能」の分野の一つ、みたいに捉えていますが、その一方で「人工無能」と呼ばれる一連のシステムがあります。

 もちろん、「人工知能」と「人工無能」という概念は、よく調べる限りだと余り対立するわけではなく、どのように、「知能」というものに対してアプローチしていくかという違いになるようです。

 例えば、wikipediaを見てみると、「人工知能」がボトムアップ、つまり普段から人間がやっているような、

トライアンドエラーであったり、フィードバックをしたりしながら、知能を形成していくようにアルゴリズムを組むのに対して、「人工無能」の場合であるならば、「トップダウン」で、「知能というのはこういうものである」というように組んであげるといった違いがある、と言えるのでしょうか。

 最も簡単な「人工無能」の最小単位というものを考えてみましょう。ある出力が入ってきたら、自分が所持する文字列のリストから、ランダムに結果を返すというものだと思います。簡単に、Pythonの場合の実装を考えてみましょう。

# -*- coding: utf-8 -*-
import random


def reply():
    answers = [
        u'ふむふむ',
        u'それで?',
        u'もっと具体的には?',
        u'ちょっと違うと思うな',
        u'別の観点から考えよう',
        u'とてもいい視点だね',
        u'あとは何が足りないかな']
    print answers[random.randint(0, len(answers) - 1)]


def start():
    while 1:
        command = raw_input('>>>')
        reply()
        if command == 'exit':
            break


if __name__ == '__main__':
    start()
    print 'Bye :) .'

 さて、ここで人工無能が突きつける一つの事実があります。それは、人工無能の、この単純なアルゴリズム自体が、順番によって、一瞬だけ「知能がある」という錯覚を私たちに与えてしまうということです。要するに、「知能があるかどうか」ということを、判断しているのは、私たちの側であるということに気がつかされます。

 例えば、文章の場合、人工知能的なアプローチだと、如何に与えられた言葉を解析するのか、という問題が出てきます。いわゆる自然言語処理と呼ばれる分野です。そこから色々なアプローチを使って、重要そうな文章であったり、あるいは、その中からトピックを探し出したり、ということを行なったりします。

 しかし、人工無能の場合、果たして、私たちが入力している文章自体を理解するべきなのかといった問題も含まれて来ます。もちろん、それだけでは何にも使えないので、何かの単語が入っていたならば、という条件であったり、あるいは「こういう文章の並びならこうしろ」というような条件を与えます。

中国人の部屋の問題

 ところで、ジョン・サールという哲学者が、文章を理解することについての思考実験をしています。それを『知能の謎 認知発達ロボティクスの挑戦 (ブルーバックス)』という本から引用してみましょう。

 部屋に閉じ込められたサールは、外部から中国語で書かれた質問カードを与えられる。まったく中国語を知らないサールは、この質問を中国語で応えて外部にカードを出力しなければならない。この部屋には質問に応えるためのたくさんの中国語カードが常備されており(これを常識的知識のデータベースとよんでもよいだろう)、また「こういう中国語記号が来たらこういった中国語のカードを並べよ」などと細かく示されたルールブックもある。ルールブックは英語でかかれているのでサールも読めるとしよう。もしサールがこのルールブックに乗っとってきちんと作業をすれば、外部にいる人は「ここには中国語に堪能な人が入っているに違いない」と思うだろう。だが、サール自信が中国語を理解しているとはいえないのではないか?サールはこの思考実験で、チューリング・テストに合格するような機械であっても「考えている」とはいえないのではないか、と反論したのである。(p.80)

 長くなりましたが、ざっくりとまとめてしまうならば、ここで提起されている問題は、「ルールの束を運用すること」と「理解する」ということには隔たりがあるのではないか、ということです。

 人工知能の場合において、この問題がどのように扱われているのかはわかりませんが、しかし人工無能というのは、むしろ「中国人の部屋」の問題に近い状態です。人工無能の場合は、単なる「ルールの束」を運用しているに過ぎません。ですが、私はむしろ、この「ここには中国語に堪能な人が入っているに違いない」という錯覚のほうが重要のように感じるのです。

 そのことについて、次に書いてみましょう。

問題解決と問題発見

 ちょっとした、人工知能関連の本を読んだ人ならわかる通り、人工知能の最初の関心というのは、問題解決と、それにまつわる検索の問題がまっさきに来ます。人工知能の本っぽく言うならば、「問題の表現」であり、そのために状態空間表現というのが使われます。「問題」は「初期状態」と「目標状態」と「規則」によって定義されます。

 ちょっとややこしいですが、例えば降順ソートのことを考えてみましょう。目の前にランダムに引かれたトランプのカードを、小さい数の順に並べるといったことを考えた場合を考えてみます。

 例えば、カードが[1, 12, 9, 5]という形で渡された場合、これが初期状態になります。目標状態は[1, 5, 9, 12]になるでしょう。この場合は、どちらかというと、一番効率の良い規則を考えることになるかと思われます。

 ソートアルゴリズムに関しては色々とあると思うのですが、ここは一つ、人工無能が持ちうる実装の一つとして、ランダム性というのを取り上げてみようと思います。それは、ネタアルゴリズムとして有名なボゴソートです。

 ボゴソートというのは、初期状態である配列をランダムに並べなおし、それをソートされているかどうかチェックし、もしソートされていないならまた配列をランダムにしなおす、といったようなことをするソートのことで、非常に効率の悪いソートとして良く知られています。下に、サンプルコードを載せておきます。

# -*- coding: utf-8 -*-
import random


def _bogosort(init_array, times):
    work_array = []
    while len(init_array) > 0:
        target_pop = random.randint(0, len(init_array) - 1)
        work_array.append(init_array.pop(target_pop))
    if not check_sorted(work_array):
        return False, work_array, times
    else:
        print "Times: %d" % times
        print work_array
        return True, work_array, times


def bogosort(init_array):
    is_sorted, result, times = _bogosort(init_array, 1)
    while not is_sorted:
        is_sorted, result, times = _bogosort(result, times + 1)
    return times


def check_sorted(check_array):
    previous = None
    for i in check_array:
        if previous is None:
            previous = i
            continue
        if previous > i:
            return False
        previous = i
    return True


if __name__ == "__main__":
    times = []
    for i in range(100):
        times.append(
            bogosort([4, 9, 2, 1, 5, 12]))
    bogosum = sum(times)
    print "Means:"
    print bogosum / len(times)

 このように、ランダム性自体が、問題解決としてはあまりいいものではない、という側面があることが確認できると思います。

 しかし、逆に問題を作る側としてはどうでしょうか?

 例えば、Haskellのテストの方法に、QuickCheckというテスト方法があります。どういうものなのか、については本物のプログラマはHaskellを使う - 第17回 QuickCheckでデータ駆動型テストを行う:ITproを見ていくとして、要するにテストデータをランダムに作成して、それらをデータとして使うわけです。これらの問題をあぶり出していくときには、むしろこういうランダム性のほうが有効であることがあります。

 また、Loguelikeと言われるゲームがあります。有名なところだと、Nethack、あるいは「トルネコの大冒険」ときけばピンと来るでしょう。殆どのゲームに関してはランダムが関わっています。よりよいランダムを実装することによって、問題を作ることには長けている部分があるように感じます*1

 他にも、Twitterの初期のころからマルコフ連鎖を使うことによって、面白い文章を生成するという圧縮新聞もあります。マルコフ連鎖が出てくると、少し確率の話も出てくるのですが、このあたりのアルゴリズムの不完全さを利用して、逆にコンテンツを作り出すという部分は面白いかもしれません。

遺伝的アルゴリズムによる突然変異

 とはいえ、人工知能のことに対してランダム性がない、というのはフェアではないでしょう。上記で「問題を解決するさいに〜」という話をしましたが、遺伝的アルゴリズムでは、ランダム性を上手く取り入れています。その部分はどういうところかというと、突然変異の部分です。

 実装したことがないので、詳しいところはよくわからないのですが、解説書を読む限りだと、遺伝子に類似するデータを、選択・交叉していくのが基本なんだそうですが、しかしこれだけだと、もしものときに偏りが生じる可能性が出てくる。なので、たまに突然変異をしてあげることによって、その偏りを無くそうというアプローチだそうです。

 ここはまだ全然勉強していない半端者の想像でしかないのですが、例えばある経路を最適解として実行していた場合、実際の最適解は、実はその実行とは全く違う形をとっていたとき、「ある経路」にいつまでもこだわり続けると、最適解にたどり着くことができない。なので、乱数を与えてあげることによって、その最適解へと飛ぶのだそうです。

まとめ:ランダム性をどのように取り入れるのか

 だんだんまとまりが無くなってきましたし、もう長すぎるので、今日は一度筆を起きたいと思いますが、自分がなぜ「人工無能」に惹かれるのかといえば、上記のように、いわゆる「推論」であったり「解決」であったり「分析」といったような部分ではない、もう少し創造的な関わりとして、人工無能的なアプローチは使えそうなのではないか、というのがするわけです。

 きっかけがあったらアイデアが出てくるのですが、そのきっかけを作るのが案外難しいというのがあります。そのきっかけを作るという意味では、上記の意味でのランダム性という部分に惹かれるわけです。

 このあたりについては、「エキスパートシステム」、つまり専門家の代わりをして、必要な知識を見付け出してユーザーに与えるといったような分野の問題とも絡んでくるのかなあ、とは思うのですが、今日は夜が遅くなりましたので、またの機会に書ければと思います。

*1:ただ、本当にランダムのほうがいいのか。例えば、レベルデザイナーがちゃんと設計したステージのほうが、ランダムで生成されるものよりも満足度が高いという話はあるそうです

2013-06-26

[]頑張る企業の皆さんに「バタリ制度」を提案します 19:16

はじめに

 一度ぶっ倒れてから、今日にかけて、昼休みの間に20分程度の仮眠を取るようにしているのですが、いつの間にか周りの人も10分間の仮眠であったり、机での仮眠を取るようになり始め、仮眠文化みたいなものが生まれつつあります。もしかしたら、他の人は激務であったり、そういうことで疲れているのかもしれませんが、自分の場合は、他のバイトをやっていたころから、仮眠を取らないと、体力が持たない、という欠点があります。

 似たような文化として、例えば「シエスタ」というのがあげられるかと思います。元々スペイン語であるこのシエスタは、どうやらWikipediaによれば長時間の昼休みのことを言うらしいのですが、「昼寝」という意味でも使われることがあるそうで、自治体でもシエスタ制度を取り入れているところがあったりします。

 ただ、「シエスタ制度」というのは、自分からすると、如何にも「海外から輸入された文化」という感じがして、余り馴染まない印象を持ちます。自分は昼寝が大好きですが、「シエスタ」と呼ばれると、なんだか違うかなーという印象を持ったりします。

 そこで、もうちょっと自然な形に出来ないものか、と思って考えたのが「バタリ制度」というものです。おれがかんがえたさいきょうの「バタリ制度」の概要は下の通りです。 

概要

  • 10分を1単位とし、各人6単位の範囲内で「バタリ」することができる。
  • 「バタリ」する期間として、1単位のみのバタリをすることも可能であり、また6単位全てを使った「長時間バタリ」も可能。
  • バタリを酷使する時間帯は自由。というのも、「ちょっと休まないと無理」という時間はいつだって訪れるものだから。
  • バタリする場所に関しては、「常識の範囲内」で自由。

なぜ「バタリ制度」なのか

 「バタリ」は、いわゆる「倒れるとき」の擬音からきているのですが、どうして上のようなことを考えたのか、というと、それは労働時間と生産性の問題です。

 何かの記事で読んだのですが、例えば、工場内で休憩時間を与えずに闇雲に働かせた場合と、休憩時間を間間に挟んだ場合、前者よりも後者のほうが、ミスが少なく、また作業効率も上がったという話がありました。直接の記事ではないですが、時々5分間休むと効果的、という記事をみつけました。

 つまり休憩時間を与えるということは、経営者の「慈悲」ではなく、むしろ経営的に合理的な判断であるとも言えるようです。自分が昔、派遣先で働いていた工場でも、3時間に一回、10分程度の小休憩を挟むなどをして、リフレッシュをおこなっていました。

 また集中力に関しても、集中できる時間というのは、50分から90分のようで、それ以上は脳が集中できなくなったりするみたいです。実際に、心身の都合によって病院にかかったときに、医者にアドバイスとして、「一時間に一回くらいは、仕事のことを忘れる時間を作ったほうがいいですよ」という助言も頂きました。

根強いファンのいるポモドーロテクニック(25分だけそのタスクに集中し、5分休むというのを繰り返す。ポモドーロはトマト型キッチンタイマーから来たらしい)にしても、休憩を細かく挟むことによって、安定した作業をできるようにしています。

 以上をまとめると、細かい休憩というのは、悪いことではなく、むしろ作業効率や、作業の精度を高めるために必要なことだと結論できるかと思います。

 当然のことながら、集中して作業に取り組み、作業が一段落したあとだったりすると、頭がぼんやりしたり、あるいはちょっとフラフラとしたりします。そこで、気兼ねなく「バタリ」することができれば、次の作業にリフレッシュできる、という理屈なわけです。

 また、休憩を取ることに慣れていない人でも、「バタリ」という言葉を使うことによって、「休憩を取らざるを得ない」というニュアンスが生まれて、罪悪感無しに休憩が取れる気がします(本当に、そういう気がするだけですが)。

まとめ

 というわけで、偉そうに「提案」という書き方をしてしまいましたが、少なくとも我が社(株式会社マリーチ)においては「制度的」なものとして定着しているわけではありませんので、採用してくれたら嬉しいなあ、とか思ったりする今日この頃です。

2013-06-11

[]ジェネラリストエンジニアというもの 22:54

前書き

 以前にも、社内の中で「業務開始前に10分間のWeb用語説明プレゼンをやるのがとてもよかったのでお薦めします - 蟲!虫!蟲! - #!/usr/bin/bugrammer 」という話を書いたのだけれども、解説したあとに、その説明を聞いた人がRedmineWikiにその解説を書く、ということをやっている。最近になって、その解説も増えてきたので、「だったらブログにしたほうがいいんじゃないか」という話になり、ブログの話が進行している。

 その中で、社内でブログの記事を二人一組のチームで分けている。一人は文章を担当し、もう一人はイラストを担当するという構成だ。自分はそれこそ少しくらいであるならば、イラストが描けるということになり、イラスト担当にまわった。(記事自体はそのうち公開される……と思う)

 恥ずかしながら、自分は元々中学生か高校時代は漫画家を目指していた時期はあった。それは、一般的に言われる「黒歴史」ではある。今も、たまにジャポニカの自由帳を使って、漫画を描きたくなる時期というのが何度かある。それは本当に趣味の範囲だから公開は殆どしてはいないが、そういう経験がこういうときに生きているのかなあ、と思うと、不思議な気持ちになる。

 たぶん、見聞きした限りだと、一口に「エンジニア」と呼ばれる職業の有りかたにも二つあると感じる。一つは「スペシャリストエンジニア」というものだ。他のことはともかくとして、一つのことを極めるということだ。例えばPHPのことなら何でも聞いてくれ、という状態であったり、JavaScriptなら仕様を読みこなしているぜ、とかそういうタイプの人間だ。

 もう一つの有りかたとして、「ジェネラリストエンジニア」というありかたがあるんだろうな、とも思う。

 ジェネラリストエンジニア、というのはちょっと一口に説明すると難しい。というのも、本来的な意味で「ジェネラリストエンジニア」というのは、たぶん存在しにくいとは思う。例えば、自分の場合であるならば、Pythonを基本とし、djangoを使ってサイトを構築している。そういう風に、何かしらの「専門性」は必要ではある。

 このブログで何度も書いている通り、自分はいわゆる「スペシャル」なエンジニアにはなりにくいと感じることは思う。もちろん、そこへの努力は惜しまないし、ある引っかかりというものは必要だ。しかし、何処かで、やはり何処かはみ出してしまう部分が存在しているとは思う。

 もちろん、人間というのは、どこかしら「スペシャル」な部分と「ジェネラル」な部分というのを持ち合わせている。知人のエンジニアも絵が上手いのだが、滅多にその様子を見せない。たぶん、そういう側面はあまり見せる必要がないからだと感じているからだろう。

「ジェネラルさ」が必要な部分と、「スペシャル」が必要な部分と

 これは企業風土にもよると思うし、その企業が作っているプロダクトにも依存している部分で、どちらが求められるのか、という点は大きい。例えば、ゴリゴリのHadroopフレームワークを作っているとか、内部エンジンを作っているという場合、やはりどうしても「スペシャル」な部分を求められると思う。

 しかし、自社の場合なんかはそうなのだけれども、基本受託開発をしつつ、新規サービスの考案をやったりするとなると、単純に「スペシャル」を雇うというわけにもいかないし、また「スペシャル」であると、タスクが落ち着いたときに手持ち分沙汰になってしまう可能性が高い。

 そういう意味では、「ジェネラル」な部分は割ときいてきたりする。上記の場合なら絵をそこそこ描けるという部分であったり、あるいはアイデア出しのときに、どういうフレームワークがあるのか、とかいったような。つまり、「普段はやらないけど、いざとなったらタスクを出せる」という状態というのは、割と大切な部分であるという気がする。

 あともう一つとして、本人がどちらのほうが能力を発揮しやすいかという問題もあると思う。例えば、Rubyをいじっているだけで幸せになる人であったり、Railsのコードを読んでいるだけで、楽しくなる人というのもいると思う。

 俺もコードを読むほうだとは思うんだけど、しかしいろんなところに目移りしやすいという側面は否めない。Pythonを軸にしつつ、いろんなところに絡んでいく。もちろん、知識だけじゃ駄目だから、実装してちゃんと確認するという作業も大切ではあるが、しかし直接プログラムとは関係ないアフォーダンスの議論とか読んだりして喜んだりするほうが楽しいという意味では、やはりジェネラルに触れると思う。(アフォーダンスの議論が重要ではない、というわけではないが)

まとめ

 取りとめも無い話ではあるが、自分が「スペシャル」になるのか、それとも「ジェネラル」なのか、そしてその辺を企業と絡めて、どのように働いていくのかというのは割と重要な話であるよなーという気がしている。そして、自分はどちらかというとジェネラルよりなのかもしれないなーと思いながら、社内ブログ用にイラストを描いたりしているのだった。

2013-06-10

[]「君は好きで毎日プログラミングできるのか」と問われて 01:31

 今日は、取りとめのない話を。

 ***

 今の会社に入る前に、当然のことながら、いろんな会社に面接を受けにいったことがあった。その中でも今の指標になっているというか、引っかかっている言葉がある。 それは、AndroidでゴリゴリとGameを開発している会社に面接を受けにいったときに聞かれた言葉だ。

 この会社では、面接前に簡単なテストがありました。簡単なノードを生成して、それらを操作するというアルゴリズム的な問題で、当時はそれほど腕もなかった自分は、ヒーヒー言いながら、プログラムを提出し、無事面接まで辿り着いたのでした。

 その会社のビルは小奇麗で、一階にカフェのような打ち合わせスペースがあり、そこで面接をされました。当時の汚いが動くプログラムを見せたりしました。今考えると恥ずかしいようなプログラム(というか、はっきり言われましたが「サンプルコード」みたいなものでした)だったと思う。で、色々と最近読んでいる本などの話をしているうちに、ふと、こういうことを聞かれた。

 「君は好きで毎日プログラミングしているか」

 実は、このとき前の会社で、ずーっとプログラミングし続けていたので、「少しコードのことから離れたい」と思っていた時期であったので、「ちょっと暫くは休んでいます」という話をしていた。そうすると、次のような返事が来たのであった。

 「この世界には、寝る間を惜しんでプログラムを書くのが好きな人達がいる。そういう人たちと渡っていくことはできるの?」

 この問いかけは、プログラマーになろうと思った自分にとっては、素直に「なるほど、そういうものなのか」と思わされた発言だった。その後、なにかAndroidアプリを作ったら送ってくれ、というお言葉を頂いたのちに、特にきっかけもなくなった。ただ、この言葉から、「とりあえず一ヶ月の間、継続した作品を作ってみよう」と思い立ち、それなりにコードを量産した結果、いまの会社に勤めることになるわけだけれども、今でもこの言葉については少し考えたりする。

 たぶん、今でも、仕事以外で自分がやりたい何かしらのWebサービスを作ったり、Prologを使ったりする自分としては、たぶん人並にはプログラムは好きだし、書いていても疲れないんだろう、とは思う。それは一ヶ月の間によって「意外とプログラムを書くことは苦ではない」とは思ったので、そうだと思う。

 どんな世界でもそうだが、俺が傍目から見たプログラマーの世界というのは、ある種の「情熱」みたいなものを持っている人々が集まっていることがわかりやすく示されている場所だなあ、と思っていた。もちろん、仕事だけコードを書いて、休日はゆっくりするという人々もいることは否定しないし、それは一つの有りかただ。しかし、上記の問いが俺に刺さってしまったのは、やっぱり何処かで「ここで頑張っていこう」という決心があったからなんだろうと思う。

 もちろん、「毎日のようにプログラミングをする」ということが大切なことではないとは思いつつ、「寝る間も惜しんでプログラムする人」であったり、あるいはそれこそ「小学生のころからプログラム環境に触れ続けてきた人」というのがいる中で、自分が「優秀なプログラマーになっている」という姿は想像できない。もちろん、自分なりに自分のプログラマ像を目標にしているわけだが、やはり「普通のプログラマー」を超えた自分というのを想像できない。むしろ、そういう優秀な人たちの足を引っ張らなかったり、あるいは自分が考えていることを形にするという、そういう有りかたでいいのかもなと思う。

 そうやって働いているときにも、「君は好きで毎日プログラミングしているのか」という言葉が突き刺さる。

 たぶん、それは「業務のプログラム」だけでは足りない、と何処か心の中で思っているからだ。もちろん、業務のプログラミングで学ぶことはたくさんあるし、それを使って自分のアプリを使っている。しかし、業務には業務のフレームワークというのが存在する。その業務のフレームワークから一つ付け足すためには、ある程度、「業務とは関係ないところで、技術で無責任に遊ぶ」という部分が重要になると思う。実際、このような技術で無責任に遊んだことが業務に生かされたことは多々あった。

 遊ぶ中で、失敗するにしろ、成功にするにしろ、それは経験値になった。練習は、たぶん「どうしたら失敗するのか」を学ぶところでもあるとは思う。最近でも、仕事が忙しくて趣味のコードが書けなくなったとき、少し不安になったりしていた。「ああ、もしかしたら自分の力は鈍っているのかもしれない」という不安に襲われたりした。

 だからといって、俺はエンジニアとして「毎日プログラミングを好きでしていること」ということは、あんまり重要視していないかもしれない。職務の場合、それこそ「そこそこ綺麗に、簡潔に、早くコードを書ければ」それでOKだと思っているかだ。しかし、たぶんそこに到達するためにはまだまだ遠いのかもしれない。だから、自分は経験を積むために、毎日書き続ける必要があるのだろう。ただ、普通のWebエンジニアになるために。

 そのたびに、「まだ君は好きで毎日プログラミングできるかい?」という問いが返ってくるのだった。

2013-05-29

[]28歳のとき、プログラマーとして全く使い物にならなかったときのこと 18:35

 Web系の会社を解雇されて思った事

 上のはてな匿名ダイアリーの記事を見ていたら、そういえば、一年前は全くプログラマーとして使えなかったときのことを思い出した。今は、プログラマーとして、淡々と業務をこなしているつもりだけれども、一年前はそうではなかった。そのときにお世話になった某社には不義理をはたらき、大変申し訳なく思いつつ、当時のことを思い出しながら書こうと思う。当時のことを思うと、今も胃が痛い。

プログラムが出来る」という錯覚

 自分は本格的にプログラマーをやろうと思ったのは28歳の頃だった。プログラマーになろうと思った理由は、「プログラム自体は、そこそこ書いた経験があった」ということ、また「パソコンに触ることが苦にならない」趣味ということだった。また、他のエッセイを読んで、「常に勉強し続ける必要がある」と書いてあったが、勉強自体もそれほど苦にならないので、適性はある程度あるかな、と思っていた。

 とりあえず、プログラマーを目指すにあたってやったことと言えば、毎日コードを書くことではあったが、それらのコードは、単純に思いつきで書きなぐったものであり、一日二日でやっつけ程度に書いたものであった。そのとき、俺は少なくとも「プログラムが出来る」と思い込んでいた。いや、事実としてプログラムは出来たかも知れないが、しかし、それが現場で通用するかどうかは、全く考えていなかった。

 知り合いのつてで、とある会社にアルバイトとして入ることになり、実務をまかされることになった。しかし、俺はコードを書くのが遅かった。というより、何かしらまかされたプロジェクトを完結することが出来なかった。なぜ解決できないのかわからないまま、ひたすらコードを書いていた。それこそ、帰宅してからもずっと、持ち帰りという形で、コードを書いていた。で、あるとき、俺は出社が出来なくなって、無断欠勤が多くなり、そのまま解雇という形になった。全くもって最悪だった。クズである。

プログラムが出来る」ということと、「プロジェクトを終わらせること」の溝

 で、俺はまた無職に戻るわけだが、なぜ当時、このような大失敗になったのか。それは自分の不甲斐なさも、多少はあるだろう。しかし、大きな問題は、俺が「プログラムが出来る」ということと、「プロジェクトを終わらせる」ということの間にある、深い溝みたいなのを全く理解していなかった、この一点だ。

 「プロジェクトを終わらせる」とは何かといえば、具体的には、どんな機能が必要で、そのためには、どのようにプロジェクトを進めていけばいいか、ということだ。

 今となっては当然のように感じるが、当時は、趣味のプログラムの延長であることは疑いようもない事実であった。趣味のプログラミングというのは、どういうことかといえば、例えば一つの挙動に拘ったり、あるいは自分がやりたいことから手を付け始める、といったようなことだった。要するに、全体を把握し、そこから最適な手を打つのではなく、細部や部分にこだわってしまうということであった。つまり、自分に「マネージメント」という部分が不足していた。それが原因であった。

 なので、当時やったことといえば、何かしらのサービスを一ヶ月間書き続けることだった。その中で、チケット駆動開発であったり、MVCに分けることが如何に重要か、ということを学んだりした。そして、クソみたいなコードを書いて、クソみたいな罰を受けるのも自分であることを学んだ。とにかく、ただ書いた。俺には経験が足りなかった。

「わからないこと」がわからない

 当時も、先輩方は「わからないことがあったら聞きなさい」ということは言ってくれていた。しかし、多くの優秀な人間が勘違いしている部分が一点ある。それは、「本当にわからないことは、そのわからない部分すらわからない」ということだ。なぜ自分がつまづいているのか、なぜこんなに遅いのか、なぜこんな状態になっているのか……そして、さらに最悪なことに、なんらかの機能は「実装できてしまう」ため、さらになぜこんなことになっているのか、ますますわからなくなる。これは泥沼であった。

 だが、その泥沼が泥沼であることをしていなかった。俺はそのまま沈んで窒息した。

いまのこと、そしてむかしのこと

 匿名ダイアリーの書き主がどうなるかは知らないが、俺が今思うに、プログラム自体に関しては続けてよかった、と思う。今、プログラマーとして優秀かどうかは微妙であり、とりあえず足を引っ張らないように頑張ろう、という程度である。

 自分がやったことが普遍的に通用するのかどうかは微妙であるか、とにかく何かしらのサービスを一ヶ月間書き続けること、特に「プロジェクト」として管理しながら書き続ける方法は、自分にとっては一番力がついた方法だったように感じる。一日、二日で書いたコードというのは、あとで読み返しもしないし、直したりもしない。しかし、実際に起こりうる状態というのは、読み返したり、直したりすることだ。

 また、githubに触れ、他のコードを少しずつ読んだりしていた。というのも、他の人々はどのように書いているのか興味があったからだ。自分のコードがクソだとするならば、クソではないコードとはなんなのか?そして、クソみたいなコードも読んだ。そこには、自分がしてはいけないことが書いてあると思ったからだ。余裕があったら他の言語についても勉強したりした。

 元の匿名ダイアリー主がどう思うかは知らないが、俺は失敗した。そして、今プログラマーとして、なんとか一年間頑張っている。今後、どうなるかはわからない。そのときはそのときで、また考えるしかないのだろう。

RyuichiXPRyuichiXP2013/05/30 10:13匿名ダイヤリーを書いた本人です。俺の味方をしてくれてありがとうございます。
分からない人は分からない事が分からないと言う点には同意です。