動的型付け (スクリプト) 言語では、データ型のチェックが実行時にしか行われないため、プログラムの妥当性検証・デバッグといった作業が困難になります。 例えば、Ruby でプログラムを書いていて、次のようなバグに悩まされたことのある人は多いのではないでしょうか。

• Integer オブジェクトを参照しているべき変数が、他の型のオブジェクトを参照している。
• そのオブジェクトが「いつ」「どこで」代入されたものなのか分からない。

この手のバグは、問題の発生 (不正な型の代入) と発覚 (エラーの発生) の位置が離れてしまうので、非常に厄介。 発生箇所を絞り込むのが難しいため、プログラムを広範囲に渡って見直すハメになります。

ウェブサービスを構築するために使用できるソフトウェア, ツールには様々な選択肢がありますが、これまでに私が手掛けてきたもの (→参照) は概ね、以下のような構成になっています。 (このサイトが置かれているサーバもこの構成です。)

諸事情により、OSが Red Hat Linux になったり、データベースが Oracle や MySQL, SQLite などになったこともありますが、基本的な構成は変りません。 (というか、移植性を意識して、そうなるようにプログラムを組んでいます。)

こうしたプラットフォームに依存しないシステム設計が「売り」でもあります。 予め環境に制約などがある場合であっても、最小の手間で構築を致しますので、そうした案件がございましたら、是非ともご用命ください。

来週月曜日から、市内のソフトウェア開発を行っている会社を訪問して回る予定ですが、その際に必要となる営業資料を作成中です。

とりあえず、名刺 (左図) は100枚ほど用意しましたが、もちろんこれだけでは足りません。

「何ができるの？」「今までどんなことしてきたの？」など、発注を考える側が知りたいと思う情報を過不足なく載せた資料を作らなければならないのですが、これが難しいもの。 あまり技術的なことを長々と書いても読む気が失せるだけですし、かと言って、プロを相手にあまりに端折った説明をしても信用を損ねてしまいます。

まだまだやるべきコト・考えるべきコトはいっぱいあるようです。

新しく仕事を始めるにあたっては、どうしてもサーバが必要となります。 そんなわけで、さくらインターネットのVPSを借りることにしました。

OSは、業務でもプライベートでも使い慣れている FreeBSD を選択。 ここに、Apache, Postfix, Dovecot, PostgeSQL 等々のソフトウェアをインストールし、これらを適切に設定しなければならないのですが、これが想像していたよりも大変な作業です。 前の職場にいたときは専門のスタッフが管理するサーバを何気なく利用していましたが、自分でその作業を全部やるとなると、これがいかに大変なことかが分かりますね。

かく言う現在も、Postfix のSMTPまわりの設定に不備があるらしく、メールが上手く送信できないので、目下調査中です。 サーバの設定にばかり時間をかけているわけにもいかないので、さっさと片付けてしまいたいところなのですが...。

はじめまして。 今月より、ここ山梨県甲府市でフリーランスで活動を始めた 成田 祥 と申します。

五月末までは、福島県は会津若松市のとあるIT企業で働いていましたが、諸事情により独立することとなりました。

業務としては主に、Microsoft Visual C++ を用いた Windows アプリケーション (サーバ/クライアント型含む) の開発や、Ruby を試用したウェブ (CGI) サービスなどを手掛けてきました。 珍しいところでは、SensAble Technologies 社が提供する触覚デバイス PHANToM の制御プログラムなども書けたりします。 Omni (GHOST: General Haptic Open Software Toolkit) と Desktop (Open Haptic SDK) 両方の開発経験があります。

知人のツテなどの一切ない状態でのスタートですので、これから積極的に営業活動を行っていく予定です。 ソフトウェアの設計・構築の案件がございましたら、是非お声掛けください。 電話番号, メールアドレス等は、こちらに掲載しております。

私たちが普段行っているソフトウェア・システム開発には、他の製造業と大きく違う点があります。 それは、モノができあがるまでに掛かるコストの殆どが人件費であるということ。 他の製造業において、原材料, 加工に使われる電気, 洗浄のための水など費用が占める割合を考えれば、これはかなり特殊な形態です。 (厳密に考えるならば、そうした費用も最終的には人件費に行き着くわけですが、ここでは措いてください。)

ところで、この「人件費」とはいったい何でしょうか？ 辞書的な定義を引くならば、人を雇用することによって発生する費用のことですが、そうした言い換えはあまり実用的とは言えません。 その性質に着目した理解の仕方をするならば、それぞれの被雇用者が有しているエネルギーや知識・技術といった所謂「労働力」を調達するためのコストである、と言えるでしょう。

この労働力のうち、使われたエネルギーあるいは、為された (物理的な) 仕事については、定量的な評価が可能であるため、支払われた賃金に見合っているかどうかということは比較的容易に判断することができます。 その一方で、知識あるいは技術と呼ばれるものについては、それを定量的に計測することは極めて難しく、実際問題としては不可能と言わざるをえないでしょう。 例えば、二人の技術者がいたとき、その知識の差を数値で表すことは可能でしょうか？ あるプログラミング言語を習得することによって、どの程度の技術向上が見込めるかについての客観的な評価法は存在するでしょうか？ そのような方法論の確立を目指して、これまでも標準化や規格化, 資格・認定制度の導入などが数多く試みられてきましたが、私の見るところでは、そのどれもが技術者の力量あるいは価値を定量的に示す基準として機能しているとは言い難いのが現状です。 また、あるノウハウを手に入れるために必要となる投資 (金額, 時間) はどれほどか、という問題についても、未だ実用に耐える精度を備えた計算方法はありません。

そうした、知識・技術を獲得・評価することの難しさについては、これまでも何度かこの日記で書いてきました。

• [2011/02/07] 抜け落ちるもの
• [2010/03/22] 知識の集め方
• [2009/08/17] 近道を求めない
• [2008/01/15] 創造力の正体
• [2007/07/23] 思考の価値

それ故、私には今や、このテーマについて新しく語るべきことはあまりなかったりします。 その替わりといっては何ですが、個人的に気に入っている、ある古いジョークを紹介したいと思います。

固定翼の飛行機は、揚力を得たり、舵を利かせるために、その翼に当たる風を必要とします。 この風が得られなくなり、パイロットが機の状態を制御できなくなってしまうのが、いわゆる失速 (ストール) と呼ばれる現象。 このような、コントロールを喪失した状態の発生をいかにして防ぐか、あるいは、そこからどれだけ早く復帰するか、ということは、工学において非常に重要な課題です。

「結局のところ、ストールから抜け出す時間だ」ティーチャは答えた。

散香のようなプッシャ・タイプはプロペラが後ろにある。 一方の翠芽はプロペラが前にあるトラクタ・タイプだ。 プロペラが作った風を、機体で受け止めているトラクタは、メカニズムとしては効率が悪い。 ところが、機体が失速して、頭を下げて落ち始めたときには、速度がある程度まで達しないと舵が利かないけれど、そのとき、トラクタはプロペラが作り出す風を翼の舵に当てることができるから、舵が早く利き始める。 極端な場合、速度がまったくゼロのときだって、プロペラを高速に回して舵を大きく切れば、姿勢を制御できる。

『ナ・バ・テア』/ 森 博嗣

自動車に搭載されているABSもその一例。 フルブレーキをかけても、タイヤをロックせず、ハンドルを切ることで進行方向を制御できる (つまり、舵が利く) ように設計された機構です。

あくまで私の個人的な意見ですが、自動車や飛行機だけでなく、私たち人間の心理・行動の制御についても、この工学の理論を適用することで、見えてくるものがあるのではないでしょうか。

東日本大地震発生から5日が経ちました。 各被災地では未だ混乱が続いており、今このときも、被災者の安否情報を求め、いたたまれない思いをしている人々が全国にどれだけいることでしょう。

昨日まで、私もその一人でした。 津波によって壊滅的被害を受けた宮城県気仙沼市に住む弟と、地震発生から4日が経っても、一向に連絡が取れず、現地の被害状況に鑑みて、半ば諦めてもいました。 幸いにして、昨日本人から実家に連絡があり、その無事を確認できたのですが、それまでの4日間は、本当に気が気ではありません。 何でもよいから彼の消息に関する情報が得られないものかと、寸暇を惜しんで情報収集を試みていました。

その際、速報性に優れるメディアとしてテレビに大きく頼っていたのですが、時間が経つにつれて、私はその災害情報の報道の在り方に大きな苛立ちを感じ始めました。 というのも、テレビがそれを観ている多くの人が真に求めているであろう情報、即ち冒頭でも述べた、被災者の安否情報を伝えることについて、とても消極的だからです。

ソフトウェア開発の工程は大きく分けて、要件定義, 設計, コーディングの三段階からなります。 (実際には、その後にテスト, デバッグなどの段階が続きますし、これらも明確に区別されるわけではなく、互いに絡み合っている部分もありますが、「作る過程」の説明としては大きく外してはいないはず。) これらの段階においては、「何を」「どのように」作るかということが順次決定されていきます。 そこで決められた事項は、仕様書や設計図として文書化され、開発に携わるメンバの間で共有されることになるわけですが、この共有の際に零れ落ちてしまう、あるいは、作る過程では確かにあったのに、完成品からは抜け落ちてしまうものがあります。

例えば、データベースの仕様書には、各テーブルに属するカラムの名前, データ型や、それらが満たすべき制約については、逐一正確に書き込まれます。 しかし、それらの事項がどのような理由・経緯によって決定されたのかということについては、ドキュメントは何も教えてはくれません。 書きあがったプログラムを眺めても、例えば関数名や引数の並びについて、何故そのようになったのか、ということは分からないようになっているのが一般的です。 それらすべてを挙げ連ね、その経緯について事細かに記述することも原理的には不可能ではありませんが、実際にそれを行ったとすれば、おそらく管理しきれぬ程に莫大な量のドキュメントができあがるはず。 (軽く見積もっても、現在のオーダから二桁は上の量になると考えられます。) その情報の洪水の中にあって、本来の仕様書や設計図に書き込まれていた重要な情報は、その他の数限りない、瑣末な情報に埋もれて見えなくなってしまうことでしょう。

けれども、ソフトウェア開発の知識・技術の本質とは、こうした「作る過程」における「瑣末なもの」の中にこそある、と私は考えています。

テクノロジーの進歩についての語りにおいて、よく引用されるフレーズに「クラークの三法則」の第三法則があります。

Any sufficiently advanced technology is indistinguishable from magic.
(高度に発達した技術は魔法と区別がつかない。)

Arthur C. Clarke

近年の映像・音声認識技術の向上や、様々な入力デバイス (タッチパネル, リモートコントローラなど) の普及によって、エンドユーザ層がこれまで抱いていた「コンピュータはとっつきにくいもの」という認識は急速に緩和されているように観察されます。 こうした社会の流れの中にあって、「技術」はその原理や本質をブラックボックスの内部に隠蔽していき、魔法としての装いを強めてきました。 世の中に魔法が満ち溢れ、誰もそれを不思議とは思わない社会は、もはやSFでもファンタジーでもなく、実現のものとなりつつあると言えるでしょう。

とは云え、現実には魔法などというものが存在しないということは、皆様もご存知の通り。 あらゆるモノゴトの振る舞いが例外なく (私たち人間さえも) 物理法則によって支配されている以上、どんな魔法にも必ずタネと仕掛けがあります。 「魔法に見えること」と「魔法であること」は、決してイコールではありません。