# 目次
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び，
そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
本書の内容は，オープンソースモデルに従い，
ほぼ無制限で利用が可能です．
クリエイティブ・コモンズ表示3.0の条件下で，
自由に使用することができるのです．
つまり，どのエッセイも，
著者の名前を明記すれば，自由に転載，改変が可能であるということです．
ーー"はじめに"から抜粋 pXII
もし，他のエッセイを読みたい場合には，
記事末のリンクを辿るか，
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．
Twitter Account: 97 Things Bot
また，元の英文によるエッセイを読みたい方は，
こちらを参照して下さい．
Contributions Appearing in the Book - Programmer 97-things
12. コードは設計である ライアン・ブラッシュ (Ryan Brush)：『プログラマが知るべき97のこと』
想像してみてください．
ある朝目覚めた時，
建設業の世界に世紀の大革命が起きていたとしたら．
信じがたいほど仕事が早く，
コストの安いロボット達が
すべての作業をしてくれるようになっていたとしたら．
ロボット達は素材を何も無い所から合成できる上，
動くためのエネルギーコストもほぼゼロです．
そして何か不具合があったとしても，
自分自身を修理できます．
更に素晴らしいのは，
正確な図面をこちらで容易する必要がないということです．
大まかな青写真だけ渡しておけば，
ロボット達はそれを元に
人間の介入や手助けなしに，作業をしてくれます．
つまり，建設コストを無視出来るほど，小さくできるということです．
もし，そんなことが起きたら，
建設業者にどれほどの影響が及ぶかはすぐにわかるでしょう．
影響は実際の建設を行う施工業者だけに留まりません．
さらに「上流」にも影響は及ぶでしょう．
施工のコストがゼロに近くなった時，
建築士，設計士と呼ばれる人たちの仕事はどう変わるのでしょうか？
今はまだ，ある建設プロジェクトに投資するか否かを決める前に，
物理的な模型を作るか，
コンピュータでモデルを作るかして，
事前に細かく検討を重ねる必要があります．
しかし，施工のコストが実質上ゼロになったとしたら，
誰がわざわざそんなことをするでしょうか？
設計が杜撰でで途中で工事がうまくいかなくなったとしても，
それがどこが問題だったのかを確かめ，
また魔法のロボット達にゼロから新しい建物を作らせればいいのなら，
大した問題にはなりません．
事前に模型やモデルを作るような方法は廃れることになります．
代わりに，十分な設計をしないまま作り始め，
何度も失敗しながら改良を重ね，
徐々に完成に近づけていく，
というやり方が主流になります．
そうゆうやり方をしたとしても，
少なくとも出来上がったものの表面を見るかぎり，
設計を十分にしてから作り始めた場合との違いは
ほとんどわからないでしょう．
作業にどれくらい時間を要するか，
事前に予測するようなことは
急激に減るに違いありません．
建築にかかるコストは，
設計にかかるコストよりも
容易に計算できます．
建築コストは，資材や部品の単価，
組立作業にかかるコストが判れば，
あとはそれを掛け算，足し算するだけでだいたいわかるからです．
そして，
この計算しやすいコストが，
限りなくゼロに近づいていくとしたら，
コストの読みにくい設計作業に時間をかけるインパクトが
相対的に大きくなるでしょう．
その結果，設計には時間をかけずとにかく早く作る，
という方法が採られるようになり，
作業がいつからいつまでかかるのかを正確に予測して
スケジュールを立てるという方法は採られなくなります．
もちろん，資本主義社会ですから
厳しい競争原理はそのまま残ります．
建築コストが事実上ゼロになれば，
その後は，設計の作業を他より早く完了させられる企業が
市場で優位に立つでしょう．
設計の早さが，企業の競争力の源泉になるわけです．
できあがったものを設計に詳しくない人が見ても，
設計が良いか悪いかは良くわからないでしょう．
早く出来る方が明らかに有利だとなれば，
必然的に，
素人目にわかるような問題がなければ，
それでよしとされることが増えるでしょう．
人の生死にかかわるようなプロジェクトでは，
もっと慎重な設計が行われることもあると思います．
しかし，多くの場合，
十分な設計はなされず，そのせいで消費者が苦しむことが増えます．
購入した建物にあれこれ問題が起きるからです．
でも，企業の側はロボットさえ派遣してしまえば，
安く簡単に修理，修復できるので，
それで良いと考えてしまいます．
結局，
建築コストの劇的な低下により，
品質が低下する
という，
直感に反した事態を招くことになってしまうのです．
本書の読者は，
この話を聞いても驚かないかもしれません．
同じ事はすでにソフトウェアの世界で起きているからです．
私たちは，
「コードを書くことは設計をすることである」
ということ
機械的な作業などではなく，
創造的な仕事なのだということ
を肝に命じることが必要だと思います．
それをよく考えれば，
ソフトウェア開発がなぜ今，危機に陥っているか，
その理由がわかるでしょう．
なにより危機に陥っているのは設計です．
作る人間の能力を越えるほどの高度な製品，
複雑な設計が求められていて，
しかも製品をいち早く市場に出せという圧力が強いような状況では，
設計が不十分なまま製品が作られることがどうしても多くなるのです．
はたしてどうすればいいのでしょうか？
ヒントは，
先に書いた建設業の世界にあるのではないか，
と私は思います．
建設の世界では，「模型」を作りますが，
これはソフトウェア開発における
「自動テスト」
にあたると考えます．
多数の過酷なテストに耐えるものであると証明されない限り，
設計が完了したとはみなさないようにするのです．
テストをより有効なものにするためには，
大規模システムの巨大な状態空間に圧倒されないような方法を
考える必要がありますが，
言語や設計手法の改善を図れば，
きっと希望が見えてくるでしょう．
決して忘れてはいけないのは，
優れた設計には優れた設計のできる「人間」が必要である，
ということです．
そういう人間になるためには，
技術の習得のために相当の努力が必要になります．
コーディング能力も例外ではありません．
■著者データ
[ライアン・ブラッシュ(Ryan Brush)]
Cerner社*1に1999年から勤務する優秀なエンジニアであり，
ディレクタも務める．
特に強い関心を寄せているのは，ITの医療えの応用である．
関連記事
1．分別のある行動 Seb Rose：『プログラマが知るべき97のこと』 - MY ENIGMA
2．関数プログラミングを学ぶことの重要性 Edward Garson：『プログラマが知るべき97のこと』 - MY ENIGMA
3．ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne：『プログラマが知るべき97のこと』 - MY ENIGMA
4．コーディング規約を自動化する Filip van Laenen：『プログラマが知るべき97のこと』 - MY ENIGMA
5．美はシンプルさに宿る Jorn Olmheim：『プログラマが知るべき97のこと』 - MY ENIGMA
6．リファクタリングの際に注意すべきこと Rajith Attapattu：『プログラマが知るべき97のこと』 - MY ENIGMA
7．共有は慎重に Udi Dahan：『プログラマが知るべき97のこと』 - MY ENIGMA
8. ボーイスカウト・ルール Robert C. Martin：『プログラマが知るべき97のこと』 - MY ENIGMA
9. 他人よりまず自分を疑う Allan Kelly：『プログラマが知るべき97のこと』 - MY ENIGMA
10. ツールの選択は慎重に Giovanni Asproni：『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
*1:医療情報システムを扱う国際的な企業．Cerner - Wikipedia, the free encyclopedia
