ものづくり革命 -- パーソナル・ファブリケーションの夜明け ([著]ニール・ガーシェンフェルド, [版]Softbank Creative)

(p.24)
2002年にスタートしたファブラボは、(・・・中略・・・)装置と消耗品にかかった初期費用は 1 施設あたりおよそ 2 万ドルだった。(・・・中略・・・)学外で活動して驚いたのは、それだけの対価を払ってもいいから同様のラボを作ってほしいという要望があつこちからあったことだ。

ここで言う「ファブラボ」とは、この本のもと(ネタ)になった「(ほぼ)あらゆる物をつくる方法」という MIT での講座で使われた施設のこと(この講座は 1998 年に開始された)。正確にはそれと同等の機能を MIT の外で、つまり一般の人々に提供するために作られた施設のこと。

「(ほぼ)あらゆる物をつくる」ことのできる施設って一体どんなものなのか? 著者は言う、

(p.23)
第1世代のファブラボは、三次元構造物の構成要素となる二次元形体を切り出すレーザーカッター、コンピュータ制御のナイフを作ってフレキシブルな接続回路やアンテナを切り出すサインカッター、回転する切削工具を三次元的に動かして基盤や精密部品を作るフライス盤、論理を埋め込む微小な高速のマイクロコントローラをプログラミングするためのツールから構成されている。

これだけも道具(と材料)が 200 万円ほどで手に入るってことだ。200 万円は高いようにも思えるけれど、それで「(ほぼ)あらゆる物」が作れるようになるなら、どうよ? 欲しいだろう? ただ、日本の空間コストの高さを考慮に入れると、ファブラボを置く場所に、その何倍もの出費が必要になりそうだけど。一部屋というかガレージだなあ。

現代は、ハードであれソフトであれ、個人が本当に欲しいモノを作れる時代になったのだと著者は言う。クルマ 1 台分の投資で(場所のことを無視すれば)可能になるそれを、「パーソナルファブリケーション」と呼ぶ。

(p.29)
パーソナルファブリケーションを実現するうえで最大の障害は、(・・・中略・・・)パーソナルファブリケーションが可能であるという知識の欠如だ。

この本を読むまでは、わたし自身、こんなことが可能だなんて思ったこともなかった。自分だけに価値のある物(この場合はハードな、つまりソフトとは違って手で触れられる実体を持ったモノ)を作ることができるなんて。同じことがソフトウェアについても言えるのかも。現在では、プログラミングするために必要な環境は、ものにもよるけれど、ほとんど投資の必要なくそろえることができる。数万円のノートPCが 1 台あればプログラミングには十分なのだ(インターネットへの接続もあった方が良い)。それを知らないばかりにプログラミングなんて自分とは縁のない行為なんだと思っている人は多いのかもしれない。

Amazon からの「おすすめ」の奥深くで見つけるまで、この本についてはまったく存在を知らなかった。知らなかったことが残念だ。もっと早くこの本に出会いたかった。5年前とは言わない、せめて翻訳が出版された 2006 年 2月に読みたかった。そうしたら、今はもっと違う場所にいたかもしれない。そう思えるぐらいインパクトがある。

これはとても良い本だ。ベストセラーになってないのが不思議なぐらい。エンジニア(技術者)は、ソフトでもハードでも「モノづくり」に関わる人は、みんなこれを読むべきだ。いや、むしろ「読まなければならない」っていうぐらいの扱いで。

ものづくり革命 パーソナル・ファブリケーションの夜明け

ニール・ガーシェンフェルド, 糸川 洋
ソフトバンククリエイティブ ( 2006-02-11 )
ISBN: 9784797333145
おすすめ度:

mnbiのバインダーで詳細を見る

MediaMarker

オブジェクト指向入門 ([著]バートランド・メイヤー, [監訳]二木厚吉, [訳]酒匂寛/酒匂順子, [版]アスキー出版局)

「Design by Contract」について知るため「7章 ソフトウェア構築への体系的アプローチ」をざっと読み。この本、すでに第2版の翻訳も出ている(手元にもある)けれど、まずは原点である第1版の方から確認。

ちなみに、第1版では「契約による設計(DbC)」ではなく「契約によるプログラミング(Programming by Contract)」と表記されている。むろん、意味するところは同じ。

DbCとは・・・以下の3つの条件を表明(assertion)することである。

• 事前条件 (precondition)
• 事後条件 (postcondition)
• クラス不変表明 (class invariant)

事前条件は、ルーチン(関数、メソッド、などなど)を呼び出す側を束縛するもので、呼び出しても良い状態を定義する。事後条件は、呼び出されるルーチン側を束縛し、制御を呼び出し側に返すときに保証しなければならない状態を定義する。クラス不変表明とはインスタンス(個々のオブジェクト)の状態に関係なく、満たされていなければならない条件のこと。

ごく簡単にまとめると、クラス/ライブラリを提供する側と使う側で決まりを作って守りましょう、ということ。単純に提供する側だけに関係する手法ではない。事前条件の確認は呼び出し側の責任とされている。

Eiffel ではこれらをスマートに記述する文法と、実行時の確実なサポートがあるのかもしれない。C/C++なら(Javaも?) assert マクロで引数チェックのようなテクニック(というかコーディング規約かもね)で実現することだし、xUnit なんかの単体テストで確認する方法もある。クラス不変表明は内部状態へのアクセスが必要だとするとクラスの外部から確認するのは難しいだろうね。となると assert 方式か。言語と環境によってはアスペクトを使うっていう手もある(らしい)。

プレファクタリング -- リファクタリング軽減のための新設計 ([著]Ken Pugh, [訳]木下哲也/有限会社 福龍興業, [版]オライリー・ジャパン) #2

3章を読んだ。ざっとまとめると・・・

アーキテクチャは大事(3.1)。インターフェイスはしっかり決めよう、できれば「Design by Contract」で(3.2)。入力として渡されたデータは検証しないと(これはDbCの裏)(3.3)。暗号のようなコードはやめて(3.4 & 3.5)。コピペすんな(3.6)。記録を残せ、とくに意図/理由/意思を書き残せ(3.7 & 3.8)。いきあたりばったりでエラー処理するな(3.9)。局所的な最適化に夢中になるな(3.10)。(一個飛ばして; 3.11)。ツールはプログラマの代わりにはならない(3.12)。

3.11 は「スプレッドシートの難問」。ここだけ、この章でかなり異質な印象を受ける。他の節ほどわかりやすくない。はっきり言えばわかりにくい。それでも著者の主張を読み取ってみると・・・

ここで言う「スプレッドシートの難問」とは、プログラミングの設計においてしばしば行うことになる選択が、表形式のデータに対して「行」、「列」のどちらからアクセスするかという問題でモデル化できる、ということ。

最初の2つの例(図3-1と3-2)は表形式のデータそのままでわかりやすい。ただ、それがどうした、と思ってしまいがち。一方で「グラフィックス(3.11.1)」と「誰が責任者か(3.11.2)」は、これが最初の2つの例と設計上の選択において、同じ構造を持っているということは直観的にはわかりにくい。文章で指摘されてもわからないかも。それどころか、図3-3のような表に描かれても何が言いたいのか、わからない可能性もある。

繰り返すが、この節の主張は「設計上の選択が、スプレッドシート(表)に行、列のどちらからアクセスするか、という問題と同型である」ということ。そして、正解は状況によって変わるんだということ。普遍的な解答はない、と。

プログラマにできることは、「これは典型的な"スプレッドシート問題"である。今回のシステムに対する○×△という要求を考慮して、ここでは"行"によるアクセスを選択する」という設計における選択の理由(意図)を記録しておくことだけ。そうすれば後からその記録を読んだ別のプログラマが、その意図をより明確に理解することができる。ただし「スプレッドシートの難問」モデルを知っていれば。モデルって言葉がアレなら「パターン」でも良い。

プレファクタリング -- リファクタリング軽減のための新設計 ([著]Ken Pugh, [訳]木下哲也/有限会社 福龍興業, [版]オライリー・ジャパン)

作業机の隅に積み上げられた本の中にあったもの。気が向いたので、ちょっと読んでみる気になった。

1章「プレファクタリングの概要」と2章「非常に多くの言葉で表されるシステム」を読み終わったところ。

プレファクタリングとは何か? 1章を読んでわかる範囲で書くと「ソフトウェア開発における様々な経験をもとにした知識を指針として、リファクタリングが少なくなるように、あるいはしやすくなるようにプログラムを設計・実装すること」となるか。ちょっと長いか。一言で書くなら・・・「きちんと作りましょう」ってことだな。

その経験をもとにした知識の中でも、中心になるのが「3つの極度」として挙げられているもの。すなわち:

1. 極度の抽象化 (Extreme Abstraction)
2. 極度の分離 (Extreme Separation)
3. 極度の読みやすさ (Extreme Readability)

2章ではサンプルシステムのユースケース定義というか分析が書かれているのだけど、はやくも「極度の抽象化」の一端が現れる。要は、ADT (Abstract Data Type)を使いましょう、ということで、「極度の」というのは基本データタイプ(C++やJavaの int とか)を一切使わずに考えろ、ということ。さらに String も基本データ型と見なすぞ、となる。これがリファクタリングを少なくするかどうかは微妙だけど、ADT の使用を徹底しておけばリファクタリングしやすくなることは確かだ。

分離と読みやすさはまだ出てきていない。分離は「関心事の分離」だからわかるけれど、それの「極度(Extreme)」なものって何だろう? 読みやすさの「極度」になると、ちょっと見当が付かない。

コードコンプリート 第2版 (上) (下) ([著]スティーブ・マコネル, [訳](株)クイープ, [版]日経BP)

第1部 基礎を固める/第1章ソフトウェアコンストラクションへようこそ、を読んだ。馴染みの薄い「コンストラクション」という言葉が使われているのだけど、「コンストラクション」とは「プログラミング」と同じ意味で使う、と書いてある。定義しなければならないような言葉を使うのは何故だろう。何か目的があるのか?

ともあれ、p8より引用:

・・・古典的な研究は、コンストラクションにおける個々のプログラマの生産性には10倍から20倍もの開きがあることを示している・・・本書では、最も優れたプログラマが既に取り入れているテクニックを、すべてのプログラマが習得できるように手助けする。

この本に書かれている内容をマスターすれば最も優れたプログラマの一人になれるということ。目次を見る限りでは網羅的だし、上巻下巻合わせたページ数と重量のことを考えれば各項目の記述も豊富なのだろう。きっと良いプログラマになれるだろう。とはいえ、この分量ではこれからプログラミングを学ぼうという人は気後れするかも。(最も)優れたプログラマへの道は遠い。

目次を眺めると、下巻の方がおもしろそうだ。

良い悪いは別にして、プログラミングの本と言えば「ソフトウェア作法」と「プログラム書法」(あとは K&R ぐらい)しかなかった頃が懐しい。