小関順二の「間違いだらけのプロ野球」(何年度版かは不明)だったと思うのですが、こんなことが書かれていました。かつてダイエー(知らない人もいるかもしれませんが、ソフトバンクの前身です)が城島をドラフト一位指名したことを絶賛する記事でした。

ダイエーが駒大進学の決まっていた城島を強引に指名したことを褒めていたのではありません。こんなことは日常茶飯事ですし、褒められたことではありません。

当時、ダイエーには吉永という捕手がいました。晩年、巨人に移籍したので、それで覚えている人もいるかもしれません。wikipediaに成績が載っているので、リンクを張っておきます。

• http://ja.wikipedia.org/wiki/%E5%90%89%E6%B0%B8%E5%B9%B8%E4%B8%80%E9%83%8E

城島をドラフト指名した年(1994年)、吉永は25才、ベストナインに選ばれています。捕手でありながら、三割近い高打率と二桁本塁打を三年連続で達成しています。25才という年齢を考えると、正捕手は10年安泰と思ってもおかしくない成績です。しかし、現実は、ダイエーは城島をドラフトで指名し、城島はほどなく吉永から正捕手の座を奪います。

凡庸なフロントであれば、吉永で正捕手安泰と考え、ドラフト下位で控え捕手を指名しようと考えます。自軍に10年安泰の正捕手がいれば、ドラフト上位で投手や野手を指名しようと考えるのは不思議ではありません。しかし、当時のダイエーはそんな守りのドラフトはしませんでした。その年一番良いと思った選手(城島のことです)を果敢に採りにいきました。この姿勢を小関順二は絶賛します。

ポジションが被ろうが、才能があると見込めばドラフト指名していく姿勢こそが、強いチーム作りに必要だと小関順二は説きます。事実、その後のダイエー(現ソフトバンク)は強いチームになりました。

この点に関してプログラマも同じです。才能あるプログラマならいつでも採りに行くべきです。才能あるプログラマの採用に関して、ポジションの空きなんて関係ないからです。才能を見込めば、やらせる仕事がなくても、採りにいきます。暇でしばらく遊ばせておくことになったとしても、それがなにか問題あるのでしょうか。プログラマの理想の採用とはそういうものです。

「動かなくてもいいから、動きそうなコードをかいてください。」 「動きそうも無いのに動くコードはいらない。」

Q1.「動きそうなコード」とはどういうコードですか？

動きそうもないのに、動くコードとは？

元の発言はシニカルで逆説的な言い方をしています。ぼくはシニカルで逆説的な表現が好きなのです。それを説明するのは野暮というもので、ぼくは野暮なことが嫌いです。嫌いですが、聞かれたので、蛇足をつけたします。

プログラムである以上、最終的には動かないと意味はありません。これは当然です。それでも敢えて、動くことより、読めるコードに価値があると倒錯した表現を使いました。「動きそうなコード」とは、人間が読めるコードであり、人間が理解できるコードです。

読めて理解できるコードであれば、例えそれが動かないコードだったとしても、動かせます。実行速度が遅ければ、速くできるかもしれません。下手なコードでも、読んで理解できれば改善できます。読んで理解するには、読み手の技量も重要ですが、とにかく、コードは人間が読んで理解できなければ存在価値が無いと思っています。

逆に、動作はしても、読んで理解できないコードは、保守できません。

他人の書いたコードを読んで理解するには一定の技量が必要で、これは実は想像以上に難しい技術です。だから、なんでもかんでも誰が読んでも容易に理解可能にすべき、というほど理想は求めていません(人も時間も有限です)。ただ、せめて自分が書いたコードぐらいは読めて理解できてほしいと思います。部外者から見ると信じられないかもしれませんが、自分の書いたコードがなぜ動いているか理解できていないのではないか、と思えるプログラマも世の中にはいます。忘れた、という次元の話ではありません。忘れるのは誰でもあります。昔自分で書いたコードが読めなくなっていることもあります。そういう次元ではなく、今、目の前で自分で書いているコードそのものを理解していないプログラマがいるのです。そんなんでプログラムは動くのかと思うかもしれませんが、困ったことに動くこともあるのです。

Q2. エレガントなコードを求めるのはどうしてですか？

誤解があるようです。エレガントの言葉の定義にもよりますが、別にエレガントなコードは求めていません。もちろん、エレガントなコードを否定もしません。エレガントなコードが美しいコードの意味だとすると、美しいに越したことはないですが、美しさよりも読めて理解できることの方を重視します。1の繰り返しになりますが、読めて理解できれば、下手なコードでも美しくできるかもしれないからです。

ぼくはプログラミングに関して原理主義者の側面もありますが、少なくとも大規模ソフトウェア開発に関しては現実主義者です。全てのコードに完璧さと美しさを求めたりはしません。コードには、カオスから守るべき領域とカオスを内包する領域の両方があることを認めています。カオスから守るべき部分、別の言い方をすると変化の影響を受けにくい部分は徹底的に守ります。守る防波堤(境界)がインターフェースです。だからインターフェースが重要です。カオスを内包する部分、別の言い方をすると変化を受け入れる部分も必要です。ここを見誤って、コードのあらゆる箇所に完全さを求めると窮屈なコードになります。コードには手を抜く部分も必要なのです。もっとも、手の抜き方は見かけほど簡単ではありません。

Q3. 「可能性」がありそう、と思われるエンジニアに共通点ってありますか？ あったらいくつでも教えてください。

社会にうまく適応できない人の方が良いプログラマになる気もしますが、偏見かもしれません。時代も変わるし、変なチェック項目を作られるのが嫌ので、回答しません。

Q4. 尊敬している人と、その理由

rms

世界を変えたから。大衆に迎合しないから。信念のために戦うことを辞さないから。

salesforceのTour de Force Tokyo(-ツール・ド・フォース-)に行ってきました。

• http://www.salesforce.com/jp/events/crm-events/2008-07-03.jsp

去年のGoogle Developer Dayでは昼食も夕食もでました。今年のGoogle Developer Dayではどちらも無くなりました。salesforceのTour de Force Tokyoは昼食も夕食もでました。この論評は差し控えます。

開発者向けセッションを聞いてきました。

ApexとVisualforceを、MVC的に説明すると次のようになります。

• カスタムオブジェクト...RDBでのテーブルスキーマ定義相当。model相当
• コントローラ...Apex言語で記述。後述するように、伝統的MVCのcontrollerと言うより、ビジネスロジック層に見えます
• ページ...PHPやJSPのようなファイル。サーバで処理されて結果はクライアントへのレスポンスになります。view相当
• コンポーネント...JSPで言うところのカスタムタグ(ライブラリ)。コントローラから渡されたデータ(model)を参照します。view相当

構成はWebアプリの伝統的スタイルに準拠しています。Javaで言えば、カスタムオブジェクトがRDBを隠蔽する層で、言わばエンティティ層と思ってよいでしょう。ページがJSPファイル、コンポーネントがカスタムタグファイルです。

少し変則的なのは、ページ(MVCのviewそのもの)に、対応するコントローラを記述させる部分です。伝統的MVCでの、controllerとviewの参照関係と逆方向に感じます。これは、「コントローラ」(以下、カッコ付きコントローラはsalesforceの固有名詞のコントローラ)の用語の使い方の問題だと思います。「コントローラ」はサービス層もしくはビジネスロジック層に近くて、伝統的MVCのmodel寄りです。伝統的controllerはフレームワークに隠蔽されています。ページに記述する「コントローラ」への参照は、伝統的controllerに解釈させる宣言的記述(viewがどのmodelに依存するかの宣言)と見なせます。

ページには<apex:foo>のような独自カスタムタグを書けますが、それ以外は、普通のHTMLです。CSSもJavaScriptも書けますし、望むならばFlashも埋め込めます。仕組み自体はJSPやPHPと同じです。つまり、サーバが中身を解釈して、その出力はブラウザへのレスポンス(普通はHTML)になります。

ページの記述の自由度の高さがsalesforceを際立たせるポイントです(ビュー周りの開発環境を総称して、salesforceではVisualforceと呼んでいます)。

ユーザにページ相当のファイルをポストさせて、それをサーバサイドのビューとして使う仕組み自体は誰でも作れます。例えば、RailsでユーザにERbのコードをポストさせて、それを表示に使うアプリは10分で書けるでしょう。しかし、それを愚直にやると、普通はセキュリティホールだと認識されます。

実現できることと、それを現実的に機能させることには大きな差があります。

Googleも登場当時、サーチエンジンが特別に奇特なサービスではありませんでしたが、高速に、そしてずっと高速にやり続けていることが凄い点です。同様に、salesforceも、ユーザにサーバサイドで動くコードをポストさせる仕組みを、きちんと動作させ続けていることが凄い点です。

ちなみに、情報ソースが一ヶ所なので、信頼度はその程度と思ってほしいですが、salesforceのサーバは、月に2,3回程度はメンテナンスのために停止するようです(停止は事前予告あり)。もしsalesforceが24時間365日ノンストップだったら、負けましたとあやまるしかないですが、幸いなことにそこまで進化はしていないようです。

「ページ」相当の機能は、facebookも同様の仕組みを提供しています(FBML)。これはこれで両者とも凄いのですが、salesforceが行っちゃったなと思うのがApexコードです。これは、サーバで動作するビジネスロジック層(上に書いたように、salesforceは「コントローラ」と呼んでいました)をユーザに自由に書かせる機能です(正確に用語を使うとApexはそのための言語)。これも、仕組みだけなら誰でも作れます。ブラウザからperlのコードをポストさせて、CGIとして実行させる仕組みと言えば、実現の簡単さがイメージできるはずです。しかし、普通はできません。現実の様々な障害(セキュリティやパフォーマンス)が多すぎるからです。しかし、salesforceはやってしまいました(Google App Engineよりずっと先に実現)。

Notesもユーザがアプリを作成して、サーバ上で動作させる仕組みがあります。機能だけを見ればsalesforceを凌駕しています。しかし、今、IBMがNotesの開発実行環境をPaaS(Platform as a Service)としてインターネットに公開できるでしょうか。恐くてできないはずです。社内アプリなら開発者の自己責任ですが、インターネットへの開発環境の公開はそうもいきません。

サーバサイドで実行することの意味は、サーバのCPU資源を利用できる利点もありますが、一番の利点はサーバ上のストレージへのアクセスです。事実、Webサービス(いわゆるWeb APIを使ったアプリ)と比較した利点として、トランザクションをサポートしている点をApexコードの利点だと強調しています。

ApexはORMを持っています。SOQLはSQLに似たyet anotherクエリ言語です。

次のようにLINQっぽく書けるのがクールです。個人的には、LINQっぽい方がActiveRecordのようなメソッドで頑張る記法より好きです。

// 記憶で書いているコード
List<Contact> contacts = [SELECT FirstName FROM Contact];
for (Contact contact : contacts) {
   System.debug(contact.FirstName);
}

• http://adnblog.salesforce.co.jp/2007/04/salesforce_4d59.html

にあるように、SOQLはjoinを明示的には指定できませんが、限定的に似たようなことは書けるようです。

似たような話を、最近facebookのAPIで見ました(Associations)。

• http://wiki.developers.facebook.com/index.php/Data_Store_API_documentation

この辺りの話は、「クエリをどう記述するか」という問題点につながり、興味深い点がある気がしていますが、まだ自分の頭の中で整理しきれていません。整理できたら、何か書きます。現状は、SQLより優れたクエリ記法には感じていませんが。

追記

そういえばコードを書くデモがほとんど失敗しませんでした。コードを書くデモって失敗率高いのですが。今年のGoogle Developer Dayのデモの失敗率の高さと対照的でした。

先日、salesforce.comのTour de Force Tokyo(-ツール・ド・フォース-)に行ったことを書きましたが、その場でコードを書いてすぐに動かすデモがなかなか素晴らしい出来でした。しかし、会場は静かなままです。途中、プレゼンター(外国人)が自分で拍手して、会場の拍手を促す場面すらあって涙を誘いました(これを無視するほど、会場の日本人も冷たくはなく、拍手で応えていました)。

Google Developer Dayで、ステージ上の及川氏が、「こういう風にデモが成功した時、海外では拍手で讃える文化があるので、是非、みなさんもお願いします」と言って拍手を促していたのを思い出しました。

海外ではどれほどのものかと思って参考に見たのが、これです(2008年はあまり面白くないので2007年)。

• http://jp.youtube.com/watch?v=PZoPdBh8KUs

良くもまあ、こう求めに応じて律義に拍手するものです。教祖と信者なのであまり参考にならないかもしれませんが。教祖がcool?と言うたびに拍手喝采です。君たち、パブロフの犬か、と毒づきたくなります。

とは言え、拍手があるだけで、たいしたことの無い技術も世紀の大発表に聞こえてきます。参加した信者も幸福な気分を味わっているのでしょう。

こういう展開の文章で、これが日経の記事なら、日本人は拍手で讃えるマナーを身につけるべきだ、とか、素直に称賛を与えない文化が日本のソフトウェアをダメにしているのだ、など、説教臭い精神論や憂国の士をきどった論調にでもなるところですが、アリエルエリアは日経ではないので、そんな展開にはしません。

精神論が嫌いというわけではなく、単に、日本人が身の丈に合わないことを無理して不自然にやっている姿を見るのが嫌いだからです。拍手が自然にでないのなら、それはそういうものです。自然にできないことを無理して始めるのは、見ていて痛々しいので嫌いです。

でも、できないのは先陣を切って拍手をすることで、誰かが拍手をした時にそれに追随するのは、多くの日本人が自然にできるようです(観察による経験則)。なので、ここは割り切って、日本で行うプレゼンでは、拍手屋を雇ってしまうべきです。内輪の関係者に頼めばコストゼロです。バイトを雇ってもコストはたかが知れています(コンパニオンの女性のコストを削れば捻出できるでしょう)。拍手のタイミングは、上のビデオを一本見れば、だいたい理解できるはずです。拍手屋が率先して拍手すれば、おそらく他の日本人もついてきます。

そんなのヤラセじゃないか、と文句を言う人もいるかもしれませんが、別に誰が傷つくわけでも、誰が損をするわけでもありません。平凡なプレゼンを凄いと勘違いしてしまう危険性が損だ、と主張する人がでてくるかもしれません。そんな人はどうせもっと色々なところで騙されているので誤差の範囲です。

ただ、ヤラセが丸見えなのは気持ちのいいものではありません。内輪ウケは、拍手がないより興醒めです。このため、内輪の関係者に拍手をさせてコストを浮かせるよりは、部外者の拍手屋の方が良いでしょう。拍手屋にはヤラセと見えないための努力もしくはスキルが必要です。周りも気づかないフリをする優しさが必要です。

• http://www.ariel-networks.com/blogs/airone/

リリースノート

• http://www.ariel-networks.com/downloads/releasenote/project_a_v4.html
• http://www.ariel-networks.com/downloads/releasenote/multischedulerv4.html

v4.8.4から間が空いていますが、機能追加はありません。バグ修正版です。機能追加版のメジャーバージョンは開発中なのでしばしお待ちください。

バグ修正版と言っても、ブランチで作業したバグ修正版としては、過去、最大の難易度でした。

v4.8.5の作業中は、会社で、cvsレポジトリふたつ、svnレポジトリひとつ、家に帰ってからsvnレポジトリ三つをフォローする日々でした(六つのレポジトリはすべて別物。svnのうちひとつはソースコードではなくドキュメント)。頭のコンテキストスイッチが多すぎて、能率が悪い気がしました。

なにかミスりそうな気がしたので、そのために行った対策が、コンパイルしないことでした。

当然、最終的にはコンパイルしますが、普通ならコンパイルして動作させるタイミングで、そこから2,3日、コンパイルせずにコードを見直す作業をしました。コンパイルエラーがゼロだろうと思うまでコードを見直してから、やっとコンパイルしました。コンパイルエラーは2ヵ所ありましたが、ひとつはinclude洩れで、これは最初から目で見つけようと思っていないので、事実上はコンパイルエラーひとつでした。ゼロのつもりでコンパイルしたので、ひとつあったのは負けですが、修正量がそれなりにあった割にはまあまあです。

普段、コンパイラで見つけられるバグはバグではない、という立場です。つまり、コンパイラで見つけられるバグは、人間ではなくコンパイラに見つけさせるべき、という考えです。なので、今回の行動は普段の言動に反しています。

今回のように、コンパイルエラーがゼロだと自信が持てるまで徹底的にコードを見直して、ようやくコンパイルする、というのも悪くないと感じました。コードを見直している間、論理バグも結構見つけられるからです。もっとも、効率を考えると、必ずしも全員には奨められません。

Railsで書いているコードもあるのですが、対照的にいい加減です。テストコードなんて一行もありません。書いては動かして、実行時エラーがあれば直す、それだけです。実行時エラーはかわいいもので、型の不一致による、エラーが起きないバグなど、悲しい思い満載です。適当でもなんとかなっているのは、Rubyの良さかもしれませんし、単にコードが少ないからだけかもしれません。

先週の金曜日にワークスとの共同勉強会がありました。題材はGrailsでした。諸般の事情により資料の公開はできません。GroovyもGrailsも基本的にゼロ知識で聞いたので、どちらの知識も僅か1時間程度の知識という前提で以下を読んでください。

Grailsの感想は、くやしいけど良くできている、です。くやしがるいわれは何もないのですが。今、何の偏見も予断も持たずに、Ruby on RailsとGrailsを見たら、Grailsを選んでしまいそうです。現実には、偏見と予断があるので、Railsを選択しています。

RubyとGroovyを見比べても、Groovyの方が良く見えてしまいます。Groovyは、書こうと思えば変数の型を明示できたり、Javaのクラスをそのまま使えたり、リテラル表現の簡易さはRubyと同程度にできそうだったりと、良いところだらけです。Rubyの方が良いところって何があるんだろう、と考えてしまうほどです。たぶん、あると思いますが。Rubyの良いところを探すために、Groovyを調べるのも不毛なので、特にGroovyを調べてはいません。

RailsとGrailsの違いで気づいたことのひとつが、Grailsの方は明示的なクラスの継承を書かない点です。Railsでは、例えばデータベースのテーブルに対応するモデルクラスは、次のようにActiveRecord::Baseクラスを継承して書く必要があります。

class User < ActiveRecord::Base
end

こう書くことで、usersという名前のテーブルを探して、必要なインスタンス変数やメソッドをUserクラスに定義します。

内部的にはinheritedという、子クラスが作られた時に呼ばれるコールバック関数がRubyにあり、Railsはそれを利用してします。次のコードを実行すると、Derivedクラスを定義したタイミングで、親クラスのinheritedメソッドが呼ばれます。

class Base
  def self.inherited(subclass)
    p subclass
    p subclass.class
  end
end

class Derived < Base
end

ActiveRecord::Baseクラスのself.inheritedメソッドで、子クラス(上の場合だとUserクラス)への参照と名前が分かるので、名前からテーブルを探して、子クラスを改造します。

Grails(Groovy)の内部的な仕組みは知りません。

もう一点、RailsとGrailsの違いで気になったのは、用語の差です。Railsのappディレクトリの下には、controllers、helpers、models、viewsの4つのディレクトリがあります。このうち、helpersはビューの下請け処理用のディレクトリなので、置いておきます。その他は、いわゆるMVCアーキテクチャの用語そのままです。

Grailsはcontrollers、domains、services、viewsの4つのディレクトリがあります(helpersがあったかは未確認)。GrailsのdomainがRailsのActiveRecordに相当します。個人的には、Grailsの区分の方が好みです。

Railsのアプリで、いわゆるビジネスロジック的な処理をどこに書くべきかを最初迷いました。viewsの下に書くのは論外なので、controllersの下かmodelsの下です。コントローラが太るのは好みに合わないので、消去法でmodelsの下になりました。しかし、個人的には、データベースと結び付いたクラスとそうでないクラスの間に線を引きたいと思いました。そのため、modelsディレクトリの下にfoo_service.rbのような、サービスクラスを作ることに決めました。

Grailsのことは知りませんでしたが、Grailsと似た区分をしていたことになります。もっとも、Grailsの「ドメイン」の用語の使い方は微妙です。ドメインがそのままデータベース定義に等価になるのは、用語として微妙に感じます。ActiveRecordパターンだからそういうものだ、と言われてしまうと返す言葉も無いのですが。

個人的な用語の好みは、データベースへのアクセス層と、Webアプリのロジックを提供する層のふたつに分けて、前者をエンティティ層、後者をサービス層と呼ぶスタイルです。ビジネスロジック層とサービス層に分けて、サービス層は薄いAPI層であるべきだという反論もあるかもしれません。その辺の宗教論争をする気はありませんが、個人的には、データベースに結び付いた層とそれ以外、という2層で充分だと思っています。つまり、Grailsの区分と同じということです。

勉強会の中でコントローラクラスのインスタンス化の話がでました。Railsのコントローラクラスのインスタンスオブジェクトは、リクエストごとに生成されます。JavaのServletでコントローラクラスがシングルトンオブジェクトなのと対照的です。

一見、リクエストごとにインスタンスを生成するRailsは非効率に見えます。実際には、コントローラクラスのインスタンスは軽いのであまり問題にならないはずです。更にもうひとつ仕掛けがあります。Railsのコントローラクラスのインスタンスは、そのままビューから参照されるコンテキストの役割も負います。Spring Frameworkの用語を使うと、「狭義のモデル」の役割を、Railsのコントローラクラスは負っているのです。ビューから参照したい状態があれば、Railsのコントローラオブジェクトは、ビューに渡すコンテキストオブジェクトを新たに作るのではなく、自分自身のプロパティに状態を持たせます。JavaのServletのコントローラしか知らない人にとっては驚きの動作ではないでしょうか。この動作により、結局、リクエストごとに必要なインスタンス化の回数はRailsでもJava Servletでも同程度になる気がします。裏は取っていませんが、Grailsのコントローラクラスのインスタンス化の仕組みもRailsと同じだと思います。

勉強会の中でクロージャの話題がでました。クロージャとクラスメソッドの関係について書いておきます。最初に結論を書くと、クロージャとクラスメソッドはそもそも異なる概念ですが(なので、関係ありますか、と聞かれたら関係無いが答えです)、クロージャを使うとクラスメソッド的なことが実現できます。クラスメソッド的なことを実現するのに、(C++やJavaのような)暗黙のthisパラメータによる手法以外に、クロージャでも実現できる、ということです。

クロージャを教科書的に言えば、「関数+環境」です。「関数」の部分は関数オブジェクトでも関数ポインタでもどちらで考えても構いません。「環境」は教科書的な意味はともかく、関数が定義された場所のスコープで見えている変数と考えてください。結果的に、クロージャは、関数が定義されたスコープで見える変数の状態を持った関数になります。「状態」は本当は「環境」と別に定義された専門用語ですが、ここでの状態は、一般用語に近い用語で考えてください。クラスのメソッドも、ある意味、状態を持った関数です。クロージャで、クラスベースのメソッドと同様のことができるのが想像できると思います。もちろん、クラスメソッドを実現するには、thisポインタの方が効率的でしょう。なので、Groovyのクラスメソッドがクロージャという点に関しては、理屈上の問題は無いと思いますが、真偽に関しては不明です。

2008年は空前のEmacsブームが到来しています。その発端のひとつと噂されるSoftware Design 2008年2月号の特集「Emacsマスターへの道」の原稿を公開しました。

• http://dev.ariel-networks.com/articles/software-design-200802/

Webで読むのは見づらいと思うので、テキストファイルも置いてあります。それぞれの画面の下の方にリンクがあるので、ダウンロードしてEmacsで読んでください。

買っていない人は、今からでも遅くないので、Software Design 2008年2月号を購入することをお薦めします。第一特集がHinemosなので買わなかった人もいると思いますが、第二特集のEmacsだけで元が取れます。

• http://gihyo.jp/magazine/SD/archive/2008/200802

• http://type.jp/job/detail.do?id=81838

こんなの始めました。

求人広告と言えば求人広告なのですが、今までアリエルが行ってきた求人とは少し趣向が違います。プロ野球に例えれば、従来は即戦力重視(表向きはポテンシャルで採用することもあると言ってきましたが、本音を言うとそんな余裕はありませんでした)だったのに対し、今回の育成プログラムは、将来性のある高校生をドラフトする、イメージです。

アリエルはそれほど余裕のある会社になったのか、と聞かれると、違います、が正直な答えです。が、少しは将来を見すえた採用ができるようになりました。

野球のようにファームで2,3年鍛える、ほどの余力はありません(そんな会社はIT系でどこにも無いと思います)。育成プログラムの期間は3ヶ月間です。入社後、3ヶ月間の実習期間があります。社内の一部の人はSICPを教えたいと息巻いています。希望があればSICPの講義があると思いますが、個人的には、教えるのはJavaでいいのじゃないかと思っています。この辺は採用した人を見て決めます。

ぼくは、プログラミングに特別な才能が必要だとは思っていません。神格化しておくと幸福な気分には浸れますが、そう思い込まなければいけないほど若くもないのです。かと言って、努力も無しに安易にできるとも思っていません。プログラミングにはその考え方も含めて、一種の技法があります。格好つけて言うと、メチエとでも言うべきものです。これを身につけるには、一定の訓練と意志の力が必要です。例えると、マラソンを2時間ちょっとで走るには、特別な才能や大いなる犠牲が必要だと思いますが、マラソンを完走するだけなら、特別な才能が無くても、また人生全てを賭けるほどの犠牲を払わずとも可能な気がします(おそらく)。プログラミングは後者に近いものです。特別な才能は無くてもいいですが、一定期間の訓練と意志の力は必要です。

まったくの初心者が3ヶ月間でプログラミングできるようになりますか?、と聞かれたなら、それは無理でしょう、がぼくの答えです。決まりきった定型処理を埋めるだけのプログラミングはできるようになると思いますが、そもそもそんな仕事はアリエルにはありません。なぜなら、決まりきった定型処理のコードなら、自動生成するプログラムを作るなりして、その作業自体を無くす方向で考えるからです。

世の中の一部のIT系企業は、初心者歓迎だとか、未経験者でもプログラミングできるようになります、などと宣伝しています。あれは失礼ではないかと思います。誰でもできる作業をやらせますよ、と宣言しているように聞こえるからです。

最初は誰でも初心者で未経験者ではないか、と言うかもしれません。今回、業務でのプログラミング経験は問いません。ただし、趣味でも学校でもプログラミングをまったくしたことの無い人は、上記に説明した理由により採用する可能性はありません。ひとつだけ例外があります。過去、なんらかの創作活動、絵画、音楽、小説、漫画、エッセー(ブログ)、なんでもいいですが、に熱中かつ継続していて、コンピュータやプログラミングに目が向かなかった、という人なら、未経験者でも採用するかもしれません。逆に、最も採用から縁遠い人は、過去、なんの創作活動の経験もなく、プログラミングを始めたこともないのに、プログラミングぐらいなら自分でもできるのではないかと無根拠に思い込んでいる人です。最初の一歩ぐらい自分で踏み出してください。

ここまで読んで、立派な人しか応募できないと思わせてしまったらごめんなさい。立派な人なら育成なんて必要ないのです。漠然と想像している人物像は、プログラミングの本を買って、文法や概念はなんとなく分かったので、意気込んで何か凄いモノを作ってみようと思ってみたものの、何から手をつけていいか良く分からなくなってしまった人です。

リンク先にある問題は解けなくても気にしないでください。なぜなら、ぼくも間違えたからです。