Facebookで知り合いが、急に昔の予約システムの”ピン”のことを述べたので、それはマルスだろうと2,3のURLをコメントした。
で、ふと、手元にマルスのことを書かれた本があったので読み直してみた。
マルス（正確にはその中での105というシステム）の開発プロジェクトで中心的な役割を担った名内氏の著作。
補論として31ページに渡って、マルス105プロジェクトのことが述べられている。
ちなみに名内氏は、その後日立製作所→日立システムアンドサービス（現：日立ソリューションズ）取締役社長に就任され、顧問を経て平成17年退任。
"業務機能仕様書"なるものが国鉄（発注側）から提出され、曖昧な所を日立側が指摘したそうだ。本には「システム稼動後、『こっちは客ではないか。なんで業者の担当からこき使われるかと思った』と懐かしげに話していただけたが、多分その時点では腹も立てられ、戸惑われたことと思うし、申し訳なかったと思う。」と記してある。
”線仕様”という言葉を用いているが、”＊＊の時にどうする”は点仕様で、”＊＊でない、＠＠の時”、”＊＊でない、％％の時”のように非該当（非正常）の時の挙動を述べていくのを線仕様と称して、その記述を掘り下げたいったそうだ。（用語化してることや、その用語がなんかすんなり受け止められて、改めて驚いた。）
なお読み直して少し新鮮に感じたのは、スパイラル方式の方が優れていると言われているけど、一括請負などでは仕様を決めドキュメントを固めてから開発に入る方がよいとの記載。スパイラル方式→アジャイル方式と、置き換えて考えてみるのは良い事と思う。
一部は「国鉄との共同責任」という契約にしたそうだ。請負契約でもなければ、、、、。なるほど！と、ちょっと感心。ちなみに国鉄との共同責任という契約は、これっきりだそうだ。（逆に言えば、他のユーザーとはこのような契約もあったということ。）
よくアジャイルなどで契約のことが話題になったりするけど、話題になるだけど、どう解決するとか前に進まない場合が多い。大昔に既にそんなことを解決してるのだから、現代人も自分たちで解決すればすむだろうにと思ってしまう。
あと”下ごしらえ”という言葉が登場する。結合テスト前に結合テストの項目が準備済み、そんな話。今だと、当たり前と思う人とそうでない人、後者の人がいるから厄介だ。なお、こっちの”下ごしらえ”という言葉もなかなか良い。
ほかに、ログのテストでの利用や「疎通」で喜ぶんじゃなくて「完通」で喜びなさいなど、実際実行してることが多いだろうが、確認する意味で役立つことがポツリポツリある。
ちなみに、日立ソリューションズのサイトに名内氏の特集ページがある。結構たくさんの種類の情報が掲載されている。（ただし、全部の回の閲覧のためには会員登録が必要。）
http://www.hitachi-solutions.co.jp/psw/feature_list/nauchi.html
マルスは結構以前のシステムだし、その開発は文献やテレビ（特にプロジェクトX）に取り上げられている。温故知新で、他を含めて昔のプロジェクトを勉強してみるも悪くないと考える。なんか昨今は、プロジェクトは失敗するとのマスコミ記事を鵜呑みにしすぎてて、色んな過去の創意工夫を封じ込めてるような気がしてならない。マルスを振り返って、ふとそんなことを思った。
