以前から、建築業界とシステム業界というのは共通点が結構あるな～と考えていました。作る対象物は違えど設計、構築といった仕事の進め方もそうだし、大手ベンダー＝ゼネコン、多重請負とかの業界構造もです。で、今ミッドタウンの21-21DESIGNSIGHTでやっているフランク・ゲーリー展に行ってみようと思った訳です。
　正直、その斬新なデザインは賛否両論あるかと思いますが、筆者が驚いたのは、昔は模型を作っては壊してを繰り返して設計していたのが、今ではデザインコンセプトを模型で確認した後はコンピューターで3Dモデリングし、決められた予算範囲内でデザインを妥協することなく最適な資材構成となるようシミュレーションを繰り返して決定しているという事です。それにより、建築資材の数や搬入時期までを決める事で施工時のコストまでも最適化し、複数の施工業者が見積もっても誤差は0.5%とか。スゲエ！と思ってしまいました。ようするに、それを実現できるソフトウェアを開発した人であるということなんです。建築業界はまったく解らないですが、こういうやり方は一般的なのでしょうかね？国立競技場とかこの人に任せればよかったのにと思いますけど。。
　で、建築とシステム開発の違いについて、フランク・ゲーリー展を見た後に筆者が感じた所ですが、建築では、住宅からビルやホールとか構築対象物の規模が解りやすいという事と、建築での施工業者なる位置付けの仕事がシステム開発に存在しているか？という事です。
　システムの規模って、誰が見ても大規模なものもあれば、それ程でもないものってかなりあるように思いますが、その規模の判断が人それぞれな気がします。大抵大手ベンダーに依頼すれば大規模と見なされていませんかね？クリティカルなシステムだって、例えば５種類のデータしか扱わないのであればそれは対した複雑さは無いはずなんです。また、扱うデータ量が膨大だとしても実装されたシステムを多数のサーバに配置するだけなので、インフラ含めアプリもちゃんと設計されていれば開発自体のコストは何も変わりません。
　あと、施工業者という点では、所謂上流下流といった分け方をしている場合、プログラマーは施工業者みたいなものだという考え方を持っている人もいると思いますが、それを当てはめた方がよいケースは極少数でしかないと筆者は考えます。どちらかというとプログラマーは施工業者というより建築資材供給者の位置づけに近いと思いますが、システムでは１つの設計＝１つのプログラムみたいなものです。同じものを量産するという概念がありません。すごく似ている機能が多数存在する事もありますが、それを一つまたは最小限にできないなら設計に問題があるはず。であれば、何を作るべきかを把握しているであろう設計者自身がプログラムを書く方が品質が高く、また分業する事によるコミュニケーションコストも最小化できるはずです。
　システム開発に施工業者が存在していないと考えの元では、建築家フランク・ゲーリーにとってのデザイン活動範囲は、システム開発全ての活動範囲と一致しており、構築対象物は違えど、システム開発におけるプログラミングはデザインという活動範囲に含まれているという事になります。施工業者的であるのは多数のサーバで構成された場合におけるインフラ側の仕事だけではないでしょうか？
　筆者の立場では、今は一人か極少数で開発をしているので、これは注文住宅を自身で設計・施工している工務店の大工みたいなものですかね。こういう戸建レベルの規模の開発案件って結構存在しているはずなんですが、欲しているものの実際の規模と受注側が考えているその規模のズレを注文側が感じるとる事を出来るかという所になります。でも、大規模と言われた物を小規模であると主張するのは結構タイヘンなんですよね。発言に対し全てのリスクを引き受ける気合い！がなければ、なかなか言える事では無いかもしれません。別の方法として、一つのシステムを戸建てレベルの集合体と分割することも出来ますけど、構築後の保守フェーズまで考慮するとこちらもタイヘンかなあ。。

　ここ数か月、筆者はとあるシステムベンダーが構築したWebアプリケーションのフレームワークで作成された既存システムのソースを流用して、新規のWebサービスを作ってました。この既存システムは、新規開発から既に１０年近く経過し、その間いろいろと変更・追加があったようです。フレームワーク自体はstruts1＋Spring＋ibatisという構成の上にさらにベンダー独自の実装で構成されたものです。そのベンダーさんに使用許諾を頂きましたが、特にリファレンスとかは無いのでソースを読みながらフレームワークを理解しながらの開発となりました。
　結果、３か月近く開発し、作ったアプリは現在ビジネス要件を満たし動く状態になってきましたが、こういう経験の無い枠組みの中で作るのは思ったよりも結構時間が掛かってしまうものだなあという印象です。一から作れと言われたらそりゃもっともっと時間が掛かるでしょうが。。
　最初、やはり時間の経過でしょうか、今さらこの構成？という感じでしたが、現在は良くできてるなあという思いもあります。ベンダーが作ったフレームワークって知ってる人からすると、結構時間が掛かる調べものの時間がないので、慣れてる人からすれば、ホントに工数を節減できたり、正確な工数を見積もったりできているんだとは思います。ただ、気持ち的には今さらstruts1系？とかここでの経験は他では使えないなどいろいろな感情が絡んでしまい、また、ソースの切り貼りみたいな作業も多く、モチベーションが低下してしまったのは否定できません。Javaの場合は流行り廃りがあるとはいえ、このようなフレームワークは、利用している方からするとシステム更新しない限りずっと使い続けるしかないのはしょうがない事ですが。
　時間の経過と言えば、最大なのはメインフレーム、いわゆるホストと呼んでいるものも一種のフレームワークと呼んでいいと思います。筆者の場合、最初がオープン系畑だったので、前職の時にホスト(zOS)と関わった時は、最初は違和感ありましたが、しばらくして良くできているなあと感じてきました。主にCobolソースとJCLの整然としたリソース構成は、雑然としたオープン系と比較するときれいに見えてきます。80桁×24行しかない画面もむしろ潔いよいです。。
　とはいえ、ホストのような自由度の無いガチガチなタイプがいいか、ちょっとぐちゃぐちゃ感はあるけど自由度のあるタイプがいいのかというと、もちろん筆者は後者の方が断然好きです。

最近あまり読まなくなりましたが、以前はよくソフトウェア関連書を読んでいました。
関連書と言っても、テクニカルなものでなく、トム・デマルコとかワインバーグといった、辛口でウイットに富んだエッセイみたいなタイプの方です。
特にワインバーグの「ライト、ついてますか」がすごく好きです。これはソフトウェア関連書に分類されているので、大きい本屋のコンピューター関連書の陳列棚に置いていたりいなかったりですが、中身はまったくコンピューターと関係なく、サブタイトル「問題発見の人間学」の通り、真の問題を発見する事の重要性について面白い寓話で説明してくれている内容です。どっちかというとビジネス書とか自己啓発本の方に置いておけば、既に３０年近く前の本とはいえ、結構売れるんじゃないかなと思うんですが、その手の本と比べるとちょっと値段が高いかな。。
仕事の打合せに出ていて、たまに問題が行ったり来たり跳ねたり飛んだりしてるなと感じる時によく思い出す本です。

ソフトウェア関係の書籍としてはあまりにも有名な「人月の神話」の冒頭に、プログラムをプログラミング製品（汎用性を持つデザイン、文書化、テスト等）にすると元の最低３倍のコストがかかり、プログラミングシステム（コンポーネントとしての使用に耐えうるようにするという事か）となるには、こちらも３倍かかるので、これら双方を兼ね備えたプログラミングシステム製品は結果９倍以上になるという記述があります。
で、現在ここでいうプログラミングシステム製品って何があるんだろうと考えますが、OSやJavaのようなプラットフォームしか思い当りませんね。
筆者のような日本にいる「システムエンジニア」と言われる人々は何を作っているのかと考えますと、企業内で使用されるシステムとかWEBサービスとかの構築がメインなんじゃないでしょうか？これらは、上記でいうところのプログラミング製品というものにも当てはまらないように思われます。文書化されてはいても、殆どの場合それを使う為では無く、どう作るか、またはどう作ったかという設計書としての文書だし、テストにしても到底あり得ないケースまで考慮してテストやったり、その為の実装したりってあまりやらないでしょ。
という事で、筆者の場合は特に個々の機能について見積もりをしない前提である為、「人月の神話」の世界にあるような大規模なシステム製品を作っている訳ではなく、参考になる所もあるけど、当てはまらない事が多いように感じました。
結局のところ、どこまでやるかがそのコストになるので、どこまで整理されたシステム構成にするか、どこまで完璧にテストするか、どこまで大多数の人が読める文書を作るかといった判断は、全て予定されたスケジュールと用意されたコストによってある程度決まってしまいます。結果的に「人月の神話」では無く、「人月の制約」の中で必要な機能を全てちゃんと用意した上で上記のような要素に対応するしかないのです。でも、それは全然悪い事では無いと思います。特に筆者のような仕事は、製品を作っているのではなく、エンジニアリングサービスを提供しているからです。
他者が書いた１システム全体のソースを読んでいると、そのような状況が何となく想像されますね。メンバー構成とか役割分担の仕方とか、テストで特に不具合が多かった箇所とか、アーキテクト的な全体を構成する立場の人がいたかとか。一番難しいのは全体の構成でしょうね。人によって読みやすいコードって多分違うので、コンセプトを理解した上でないと、良し悪しの判断さえ出来ないでしょう。