Archive of posts from yyyy-07-22

これはテレビドラマ版の焼き直しと言えるでしょう。チェロ奏者（加藤剛）が医者（山崎努）になったくらいで、あとの設定はほぼ同じ。

決定的に違うのは、寅さんの母親役のミヤコ蝶々。これが素晴らしい。あの母にしてこの子あり、というくらいのパワフルな母ちゃん。2人の喧嘩が凄まじい。これを「男はつらいよ エピソード2／ミヤコ蝶々の攻撃」と呼びたいね。

叔父ちゃん叔母ちゃんの旅行先の旅館で番頭をしていた寅さん、という珍しい展開の本作。いつものくるまやの面子に代わって、旅館のメンバが寅さんにツッコミを入れる形になっている。この形をとることで、寅さんが全国どこでも「いつも通り」だということがよく分かるようになっている。

また、本作では、寅さんが実は弱いということが判明する。庭で博に殴られ、若者のナイフを見てはビビる。威勢はいいけど、身体は弱いみたいだ。

難点といえば、無理な展開が多々ある。たとえば、知らないテキ屋の娘の芸者が借金のカタに妾に行く、というすぐには理解できない設定をいきなり持って来るのは反則だと思う。

『すぐに使える!自分でできる株式会社設立 改訂版』

会社法の説明から設立後の届出まで一通り載ってる。とりあえずこれだけで十分。

不安だったら（あるいは面倒だったら）、司法書士に相談するといい。
平均すると30万円くらいだけど、
電子定款を使って25万円くらいでやってくれるところがあるので、
そゆとこを選ぶといい。

『起業したらまっさきに読む経理の本』

設立のところ以外にも社会保険やら労災保険やら給与の支払いやらが載ってる。
あと、簿記3級程度の仕訳の説明とか。こないだまで顧問税理士がいなかったのでかなり重宝してた。とりあえず税理士は早く見つけよう。

現代のクンフーですよこれは。すげーよ。

amazon.co.jpのレビューに

マッハでもなくマトリックスでもない最強のカンフー映画

というのがありましたが、まさにッ!!!

ティーザー見て、天下一武道会形式かと思って、今まで手をつけずにいた自分が恥ずかしい。

ストーリーに関してはいたって普通なんだけど、クンフー映画にしてみればものすごく凝ったものになっている。ストーリーを中心に見ても、十分、鑑賞に堪えうる。

でも完全版じゃないそうなので

完全版が出たらまた見る。

トラウマのシーンすごかったなあ。こっちまでうえーってなっちゃったよ（弱）。

読了。薄い本なので細かいところには立ち入っていないが、上流工程の「ある種の形」を提示してくれている貴重な本。これが妥当かどうかはぼくには判断つかない（そもそも上流という言葉が気に入らない）。

デザインパターンと称した章もあるが、これもぼくにはなんのこっちゃいな、という感じ。分かるひとには分かるのでしょうが。ぼくの感想は以下のようなもの。

▼

上流工程がボトルネックになっていると氏は述べる。
優秀なプログラマが自分のために開発したソフトウェアと優秀なプログラマがお客様のために開発したソフトウェアとでは、後者のほうが圧倒的に時間がかかることからもそれは明らかだと言う。
また、上流と下流で分担すれば、単価の高い上流工程に専念することも可能となり、結果として会社全体の利益も上がると言う。

一般的な「上流工程」が何を指すのかぼくはよく知らないが、ここでいう「上流工程」ってのは、以下の１＋３のモデルを作ることにあるという。0, ‘画像の説明’, nil, [350,307]

絵を説明すると、まず業務フロー図をDFD（実際はイベントを付記したDFDもどき）で描き、次にデータモデルを作る（IEもどきで表記）。次に文章形式で業務モデルを記述し（これは後にマニュアルとなる）、最後にその業務モデルに沿った形でシステムの画面イメージを作っていく（外部設計）。

本書の最後にストーリー仕立てでその構築方法が記されてあるので、是非一読されたい。

この工程そのものについてコメントできるほどぼくは知識を持ち合わせていないので、おおッと思ったポイントだけ書いておこう。

その場主義

以上のモデルのラフデザインを、お客さまとのセッションを通じてホワイトボードに殴り書きしていく。ここが非常に感銘を受けた。アジャイルだぜこれ。これを氏は「その場主義」と呼ぶ。そのセンスの無さがまた魅力である。

細かいことにこだわり杉

オブジェクト倶楽部の納涼祭で、一部、話題騒然となった「マジックは新品を」「モデリングは似顔絵である」「曲線は美しい」などの迷言が、コラムとして紹介されている。面白いので是非読んでおこう。DFDやIEをカスタマイズするところに、氏のビジュアルへのこだわりが見える……反面、こんなこと言ってるとキワモノ扱いされてしまうようにも思う（それはそれで楽しいが）。

つーか、データモデルのひとたちって自分で記法を作っちゃうのよね、あれって悪い風習だと思うYO。

業務モデル

この存在が重要。システムを構築しても、それをどうやって使えばいいのかが分からなければどーしよーもない。ユースケース記述がマニュアルになりますよーという話は聞くが、あんなマニュアル読めたもんじゃない。氏は分かりやすく、更新しやすいマニュアルを作れと述べる。おお、これはまさにWikiの出番じゃないか。

機能モデル

機能モデルは、それまでのデータモデル、業務モデル、それからドメインの知識（およびパターン）でもって構築していくべしとのこと。ここでデータモデルがしっかりしてれば、更新すべきじゃないデータを画面を表示させることなどを防止できるとかなんとか。
でもね、アーキテクチャを考えない画面イメージなんてどーかと思うんだよ。右クリックしたら「修正」メニューが出てきて……なんてHTMLでどーやるの？ 逆に、もっと簡単な操作方法があるだろうけど、このウンコ仕様書にはこう書いてあるから、こうやったーみたいなのもあるでしょう。

業務アプリのユーザビリティが総じて醜悪なのは、こういうところからきてるんじゃないかなあ、と思う。

データモデル

この薄い本じゃあ足りない。他の本を参照するといいと思う。デザインパターンを紹介しますつって、いくつかの「パターン」を紹介してるんだけど、なんのことやら？よく分からん。

上流工程の成果物で、合見積もりをとらせる

本書で提案されているのは、上流工程で出した成果物を根拠にして、下流工程担当業者に見積もりを出させるという方法だった。この場合、上流を担当した業者と違う業者でもOK。というか、違う業者でもOKになるような成果物を書くことが上流担当者の役目と言い切る。おおー。素晴らしい。

でもね、こんなことあり得るの？

だいたいプロジェクトが開始するきっかけって、どういうものがあるのかぼくはよく知らないのだよ。いちおう、こんな感じだろうと思ってはいるのだけど…。

1. 営業さんが案件をとってきて一括受注（上流、下流とも）
2. n次受け（下流）
3. 入札（はて？）

で、だ。(1)の場合に合見積もりなんてーのは存在するのか。存在するとしたら、何を根拠に見積もるのか。やっぱ人月とかそういう感じ？

(2)の場合、仮に合見積もりが存在するとしたら、何らかの仕様書が根拠になるのだろう。だけど、大元の1次受け（上流）は何を根拠にすべての作業を見積もりをしてるの？（結局、(1)と一緒の話になる？）

(3)の場合、クライアントのRFPが根拠となると思うんだが、RFPの成果物と上流工程の成果物って一緒なのかどうなのか。はて？

教えてエロエロな人。

いろいろ感想

• ここで作られたドキュメントをもらっても、また最初からクラス図書いたりするんだろうなあ。
• 別の本で「業務システムでは第三正規化で十分、なんてのは嘘っぱちだ！」という記述があったので、今度はそのへんについて読んでみたい。

このときまで大田垣せいこだとは思ってもみなかった。てっきり、はるこだと思ってました。そんなせいこさんが、いつものように淡々と語ります。どーでもいいようなことが意外と大切だったりするのであります。