■ オリジナルソーシャルネットワークの作り方

SNSを使えばこういうメリットがー！みたいな記事は萎えますなあ。なんで萎えるかは分かりませんが。こういうのも萎えません？ぐだーってなる。ひょっとして俺だけっすかね。

萎えるのはそれくらいにして、ここで触れられている Central と Base という考えは、GreeNight 行った後に先輩と話してた内容と一緒だッ（俺は全面的に否定してたが）。開発、がむばってください。

追記：

• ふむWiki:デジタルキャンパスに見る近未来のコミュニケーション

こんなの教えてもらいました。

■ さくらんぼブービーいいよなあ

前から好きだったんだけど、よーやく名前を覚えた。きっと漫☆画太郎先生のファンだと思うんだ。mixiのコミュニティに入ったらムービーがあったのでぺったんこ。

• http://www.zakzak.co.jp/wara/team/06_c.html
• http://www.mxtv.co.jp/line/monday_neta/data/031201/catalog.html

インスタントジョンソン、波田陽区、東京ダイナマイトのコミュニティにも入りました。

■ [本] 業務システムのための上流工程入門―要件定義から分析・設計まで(渡辺 幸三)

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

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

▼

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

一般的な「上流工程」が何を指すのかぼくはよく知らないが、ここでいう「上流工程」ってのは、以下の１＋３のモデルを作ることにあるという。

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

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

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

その場主義

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

細かいことにこだわり杉

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

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

業務モデル

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

機能モデル

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

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

データモデル

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

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

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

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

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

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

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

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

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

教えてエロエロな人。

いろいろ感想

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

■ X51.ORG : 右利きか左利きかは子宮の中で決まる

じゃあもう、強制とかさせないほうがいいですね。

■ 【より良い】データモデリング【モデルを】

あんまり伸びてないけど、日本で唯一のデータモデリングの情報源だと言っていいと思う（言い過ぎ？）。

■ [Agile] XP祭り2004

お、咳さんの資料がアップされとる。

■ 8月1日よりはてなで新スタッフとして参加します。

via はてなダイアリー - ARTIFACT@ハテナ系

へえ。知らんかった。川崎さんとは面識ないんだが、先輩が一緒に合コン行った仲だとかで、横文字で言うならFoFなわけで、これからはてなをもっともっと盛り上げていっていただきたいと思いますです。

■ [tDiary] 「本: 〜」表記を削る（amazon.rb）

以下を追加してみた。

item_name.gsub!(/^.*:\s/,'')

んが、これだと

本: ほげほげ冒険記: 死闘編

の場合、

死闘編

と表示されてしまう罠。どうしたもんかのう。

■ [本] オンナノコのおたしなみ (ダ・ヴィンチブックス)(大田垣 晴子)

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