著作一覧 |
妻が図書館で借りてきておもしろかったらしくおれにも貸してくれたので読んだ。
確かにおもしろくて、一気に読んだ。
設計したエンジンを搭載したロケットの打ち上げに失敗したせいで干された研究者が、町工場を経営している親父が倒れたのをきっかけに研究所を退所して経営を引き継いで7年。
大口得意先に取引を打ち切られたところに、特許侵害の訴状が届く。と読み始めると、あっという間に危機的状況に陥ってしまう。
それが伏線となって、町工場のいい加減な特許の書き方の見直しをすることになり(というあたりで、経済小説ということがわかる)取得したばかりのバルブの特許に付随情報を付け加える。
まさにその時、ロケットエンジンを開発した大企業が、その特許に抵触していることに気付く(最初に出願した時点ではまったく問題なかったのだが、付加された条件に引っかかった)。かくして、その特許を買うか、ライセンスを受けるかという話となり、あまり登場しない第二の主役が登場する。
中小企業の経営もの(人情話と特許紛争、家族運営、企業買収、大学の人脈を使ったあれこれとか、いろいろな要素が盛りだくさん)としては、実にうまい作品で読後感も悪くない。もっとも、こういう作品を読むと中小企業って面倒だなぁという印象を受けてしまうのだった。
珍しく(もないかも知れないが珍しく感じた)銀行から出向してきている経理マンが実に良いやつで、あまりこういう方向に話は進まないけど、そのくらい貸し渋りとかで苦しんで、こういう小説で溜飲を下げる人がいるのかなぁとか不思議に感じたとか、大企業の嫌がらせで苦しんでいてこういう小説で溜飲を下げる人がいるのかなぁとか(といっても大企業は大企業として普通に書いているので、人数多ければ良いやつもいるし、性格は悪くても評価するときは客観性重視とか、上のほうの地位に昇った人間は是是非非の鋭い感覚と素早い損得勘定ができるしと、当然なことを当然に描いていて単なる子供用の勧善懲悪観には堕していないけど、それがこのジャンルの作品では当然なのだろう)、ここ数十年読んでいないジャンルだけに興味深かった。
で、奥付みると週刊ポストに連載していたとか書いてあって、はて、どういう読者層なのだろう? と不思議になる。
いずれにしろ、普通に良くできた小説でおもしろかった。
Herokuの本を読んでいて、2章の途中でおもしろい記述に出会った(出会ったところでいろいろ考えたので突然書き始めたので、本文でどう展開されるのかはわからない)。
Professional Heroku Programming (English Edition)(Kemp, Chris)
(図を除けばKindle Paperwhiteで普通に読める(辞書ひけるのは便利だね)ので、Kindle版がお勧めなのかなぁ。前に戻って読み返すのは遅くて死ねるけど)
そこでは、スチュアートブランド(ホールアースカタログの人)のHow Buildings Learnという本からアーキテクトのフランクダフィという人が導いたコンセプトが紹介されている。
How Buildings Learn: What Happens After They're Built (English Edition)(Brand, Stewart)
レイヤリングをペース(持続時間/成長速度)ベースで考えるというものだ。
家そのものは30年というタームで変える。それより早く変えることはすでに何か問題だ。一方、部屋の中の壁紙は5年くらいたったら変えたくはないかな。では机の上のランプは?
同じことをソフトウェアポートフォリオに当てはめたらどうだろうか?
レイヤリングといえば、MVVCとか、MVCとかがすぐに頭に浮かぶ。
MVCのVは比較的早いサイクルで変えても良い。Mの中には変わってほしくないマスター系と変わる必要がそれなりにあるフロー系がある。Cは基本、変わることを想定すべきではない。
ということは、ペースベースと責務ベースのレイヤリングは重なるところ(コントローラ)もあるが、直交している箇所(ビューとモデルの一部)もある。
開発-テスト-配備サイクルを考えた場合、ペースベースのレイヤリングは良い分離方法と考えられる。
(と、メモ)
ジェズイットを見習え |