満足せる豚。眠たげなポチ。

しかし、ソースコードには、さらに他の利用者がいることを忘れてはいけません。2、3ヵ月後、何かの変更を加えるために誰かがコードを読もうとするかもしれません。この利用者の存在は、軽視されがちですが、実際には最も重要なのです。コンピュータがコンパイルするのに余分な CPU サイクルがちょっとかかったからといって誰が気に留めるでしょうか。これに対して、プログラマがコードを修正するのに1週間かかったとなると、これは問題となります。コードを理解できれば、わずか1時間で済んだかもしれないのです。

プログラムを動作させようということに必死で、将来の開発者のことを考えていられないというのでは問題です。

「リファクタリング - プログラミングの体質改善テクニック」（Martin Fowler著）　第2章　リファクタリングの原則(P56)より

業務システムを長期で使っていくことを考えると、開発のコストをいかに小さく抑えるかというのは非常に重要だ。特に毎日の資金繰りに困らない程度の規模の企業であれば、初期投資のコストも大事だがメンテを 10 年続けたときに全体でいくらかかるのかという視点が大事になる。（あまりまともに試算されている例を知らないが。）

業務システムを開発するのに必要な視点は複数あるが、コンピュータサイエンスの視点よりも上位の視点（コンピュータサイエンスも含んでしまうという程度の意味であり、価値が上という意味ではない）としてこのメンテナンス可能性という視点が必要だと思う。

ひがさんが「メンテナブルなコード」という表現を使って同じような主張をしているが、「システムをメンテナンス可能にし続けておくための全体の仕組み」を作ることが重要だ。（たぶん、ひがさんはそれをフレームワークで実現できると考えているから、コードという表現になるのだと思う。こちらも参照。）

「どこで何をしているか」「ある目的のことを変えたいときはどこを変えるべきか」「ある箇所を変えた場合の影響はどの範囲に出るか」といった内容が容易に把握できるような状態を維持し続ける必要がある。そのために、ソフトウェアアーキテクチャやドキュメント（無用な誤解を避けるためにあえて設計書とも仕様書とも呼ばない）、人の採用、トレーニングプログラム、開発プロセスなどの全体の仕組みを最適化し続けていかなければならない。

それを実現するためには多くのスキルが求められる。プログラマーであることを目的とするのではなくて、プロフェッショナルであることを目的とするならそのスキルを身に付けることが必要になる。（だって、自分でやらないと誰もやってくれないのがふつうだし。）

色々なツールを知ることや使えるようになることももちろん大事だけど、どんな目的に貢献させるのかを意識しながら複数のツールを組み合わせて活用していくスキルというのはこれからもっと重要になっていくと思う。

ということで、日々の非プログラミング系の仕事のプロセスをプログラミングに模して、さらにそれをリファクタリングしようという codemaniax さんのエントリを読んでいて共感したので、最近考えていたことをメモしてみた。これも衰えない技術だよな。

ちょっと遅いけど、On Off and Beyond のコメント欄からメモ。

RSSを能動的に巡回する人は少数派だとか、今後もRSSリーダー使用者が増えるはずがないとか、よく誤解している人が居ますが。それは一面的な見方で。RSSは能動的ではなく、検索エンジンやツールによって間接的に使われることになると思います。つまりユーザーは意識せずにRSSを使うようになる。そのときは全文配信RSSのほうがSEO的にも有利になるかも 「RSS購読者の何割が本当にブログを読んでいるか」

という otsune さんのコメント。

RSS配信しない企業サイトのニュース、プレスリリースなんてゴミ同然という時代になるわけか。

3/9のエントリについて、いくつか言及を頂いたので紹介。ちなみに私自身の考えはこちら。

違いは何か。実ははっきりしています。「本気度」です。いつでも変更できますよ、というステータスだと、必死で詳細まで見ないのです。ここで決めたことがリリースされるのだ、となった途端に急に詳細まで考え抜くようになります。〆切重要。

もうすぐ春だよはぶにっき [仕事]仕様の確認方法

僕はもともと、ドキュメントじゃ確認できる内容には限界あるから、使ってもらって判断してもらう、ということには同意できたんだけど、使ってもらってであっても、本気度が足りないと全然フィードバックが受けられないというのも現実で。

m_pixyの読書日記 [dev][RD]お客様の本気度

いきなり真打登場という感があるのですが、「本気度」。たしかにこれはあります。なんで本気にならないんでしょうね？やっぱり締切りなんでしょうか。

一方で「本気になって仕様を検討するときに何をどう見ればわからない」というのはある気がしています。ユーザーの人は業務のプロではあるけれどシステム仕様を書くプロではないので。じゃ、誰がプロかっていうとやっぱりシステム作る人になるんじゃないかと。

ユーザーが本気になって仕様を確認したときに、動作するプログラムと紙の仕様書（ガチガチのもアジャイルなのも含めて広い意味での仕様を記した何かしらのもの）のギャップはどこに残るのか？（残らないのか？）が新たな疑問。

スタロジ流だと限りなく「残らない」に近いスタンスですね。残るけど、それは紙では実現不可能な部分という。

そうか。たしかにここまで割り切ってしまえば残りの部分（見えてないと仮定できる部分）の見通しはかなりよくなるなぁ。少し前進した感あり。ありがとうございます。

このズレが重いな。だから、ユーザを巻き込めという話になるのか。XPやなんかでも言われてるけど、このこと自体は開発方法論には関係しないはず。ただ、方法論としてユーザを巻き込むということを明示しているからアジャイルはイイ！って話になってるのかと思ったり。

m_pixyの読書日記 [dev][job]ユーザが本気になるタイミングと、開発側が本気になるタイミング

「リーンソフトウェア開発」を読んでいて私もこれを感じました。単純に開発サイクルが短いというのは強制的に巻き込む機会が増えるな、と。（厳密には「方法論としてユーザを巻き込むということを明示」の指されている話とは少し違いますが、言いたいところは近い。はず。）

最後に頂いたトラックバックから。

ぼくは「仕様決めのときになくて、顧客テストのときにある」のは「動くアプリケーション」と「それまでのコミュニケーションで培ってきた信頼関係」だと思う。受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。その上で、実際に動くアプリケーションを使って検証するから、この仕様は正しいと判断できるのだと思う。

TECH-moratorium ： テクモラトリアム [SD]顧客テストにはあって、仕様決めのときにはないもの

なるほど。たしかに丸っきり初対面から始めたようなプロジェクトだと仕様決めるにしても「空気を読みつつ」みたいなところはありますね。（身に覚えあり。その態度を反省した覚えもあり。）

「受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。」の部分がちょっと理解しきれなかったのですが、仕様と実装アプリの動作にずれが出ているという内容かな。そして、それをコミュニケーションですり合せている。と。（違うかも）文脈的に「この仕様は正しいと判断できるのだと思う。」の部分に掛かる理由にもなっているはずですし、もうちょっと突っ込んで聞いてみたい内容です。

あと、「動くアプリケーション」というのはなんだかんだ言ってやっぱり強いですね。Ruby まつもとさんの「ソースがドキュメントだ。 バグも完全に記述されている」ではないですが、たしかに仕様の誤り・漏れも含めてすべて実装されているというのは強いです。あとはそれを作るのはタダじゃないというコストの問題ですか。

最後のオチとしては、

逆に、お付き合いが長かったり、そのシステムに専念できるお客さまだったり、既存システムのリプレース案件の場合は、仕様決めの段階できっちりと詰めるアプローチが有効だと思う。特に、仕様のほとんどが計算式な金融系のシステムなんかはそうだろう。重要な仕様は事前に十分に検証でき、結果的にリスクも下がると思う。

にど真ん中で当てはまる案件をやっているにも関わらず、こんな問題提起をしている自分が居たり。やっぱ単なる本人の力不足か！

3/9の話の続き。

ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている（だからテストでは指摘ができる）のにそれを完全に正確に伝えられないのだろう？」というもの。（略）「顧客テストにはあって、仕様決めのときにはないものはなんだろう？」「その本質的な違いはどこにあるんだろう？」

顧客テストと仕様決めでの本質的な違いは「網羅性」なんじゃないか。そう思ってる。

仕様決めのときはお互い想定で進んでいる部分があって、要は詰めが甘い。顧客テストになると実際に動くものができているので、隅から隅まで動かせる。わかってるようでわかってない部分とか、なんとなくこれで大丈夫と思ってたような部分での問題が全部表面化するのではないか？

その視点だと Goya の UI スケッチだとか、あるいは他の宗派の同系統手法でもいいけど、手法を真似るだけじゃなくてそれによって何をやらないといけないかが明確に見えてくる気がする。

たとえば、こんなものが見落とされているはずなので重点的にチェックする。

• 状態によって変わる動作（想定されるすべての状態について検討したか）
• そのあり得る組み合わせとしての操作ストーリー
• 条件が false の場合のすべての動作
• 条件の網羅性（条件を満たさないものにはどんなものがあって、それらは本当に条件に含まれなくても正しいのか）

上記を見ると当然確認しているべきものでもあって、レベルの低い話になってしまっているのだけど、それでも実際漏れるのは「当然であるはずのところ」から抜け漏れが出てしまっている。当然のことをより意識して都度気にしながら確認できる仕組みが必要。（少なくともぼくには）

上記を考えるにあたって、顧客テストと仕様決めの時点で何が違うかを考えてみたので併せて公開しておく。

それぞれに少しずつ意見があって、結局網羅性に行き着いている。

• (時間軸上の)タイミング
  本当に顧客の得られる情報量が変化しているケースは仕方がないが、そうでもないケースもよく見かける。これは仕様決めの時点では顧客は何らかの理由での細部まで調査確認をする必要がないと判断しているのでは？では、その理由は？
• 顧客の求められる役割
  そもそもの顧客の態度自体が違う？だとすればなぜ？それは私がコントロールできる？また、仕様決め時点なりに真剣に検討しているようでも、顧客の頭の中では想定外の（望んでいる動作と違う）動きが顧客テスト時に発見されることもある。なぜ想定外の動きだったんだろう？
• 検証物
  仕様書が「顧客の想定している使い方のケース」をすべて網羅していれば、理屈上プログラムはそれを実装しただけのはず。プログラムが顧客に見せられるものと同じものを仕様書として見せられるのでは？今仕様書からは漏れ、プログラムでは顧客が気が付けるものがあるとすれば、それは単に仕様書がそれについて正確に言及していないか、顧客がそれを見落としているのではないか？

最後の方は思考過程を丸投げしているようなエントリになってしまったけれど、「いかに仕様化するか？」というのが最近のテーマだったので良い機会だし文章にしてみた。

「リーンソフトウェア開発」P219から。

システムが、顧客の意図どおり動くことを確認するテストは「顧客テスト」という名前で呼んだ方がよい。それは、テストの目的が、顧客がシステムに期待したとおりシステムが動くことを確かめるためだからである。

そう。そのとおりだ。そして、本書ではその顧客テストを短いサイクルタイムで複数回を行うことでリスクを軽減するというアプローチを取る。

その主張も正しい。一つの解決策として非常に参考になる。

だけど、ここで一つ大きな疑問がある。顧客はなぜ「顧客テスト」をするとしっかり仕様の漏れ、ミスを発見できるんだろう？

ちょうど今日もそうだった。すでにシステムはリリース間近。まさに「顧客テスト」が行われていた。そして発覚した仕様の漏れ。

その対応自体はけっきょく事なきを得たのでここで話題にはしないけれど、不思議なのはその仕様はけして「ビジネス環境の変化」で昨日今日浮上したなんてものではなくて、当初にレビューをしている時点で分かっていて然るべき内容だった。

これは結論から言ってしまえば仕様のヒアリング漏れであり、端的には「しっかりやれ自分」てところに反省点は行き着く。それはデブサミの羽生さんの名言「仕様変更なんてないんです」を持ち出すまでもなく、そのとおり。そう考えないと前進しないし。

ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている（だからテストでは指摘ができる）のにそれを完全に正確に伝えられないのだろう？」というもの。言い換えると、「顧客は欲しいシステムの必要な動作を本当は知っている。仕様を決めている時点でそれを正確に引き出すにはどんなサポートができるのだろう？」という疑問だ。

さらに質問形式を続けると、「顧客テストにはあって、仕様決めのときにはないものはなんだろう？」「その本質的な違いはどこにあるんだろう？」

リーンソフトウェア開発で述べられている「動くものを提供する」というのもたしかに「顧客テスト」を早めるという意味で有効なサポートになりそうだ。

でも、目下抱いている疑問への直接の解答にはならないんだよな。

自分の今の仮説も明日さらすつもりだけど、まずは読んでくれた方、ご意見など頂けるととてもうれしいです。

ちなみに「仕様変更なんてないんです」の意味については、こことかこことか参照。

リーンソフトウエア開発〜アジャイル開発を実践する22の方法〜

posted with amazlet on 07.03.08

メアリー・ポッペンディーク トム・ポッペンディーク 平鍋 健児 高嶋 優子 佐野 建樹
日経BP社 (2004/07/23)
売り上げランキング: 59630

amazlet.com で詳細を見る

これ、わかるなぁ。私は Ruby 使い始めて、Ruby のライブラリ見たり、るびまの青木さんの添削みたりしてどんどん書き方が変わった。

最初、こういうのがきれいだと思った。

int  axe      = 3 ;
int  exe      = 4 ;
int  longname = 8 ;
long lonlon   = 1L;

が、へたなプログラムほどこういう書き方をしているのを目にして、次の書き方へ移行した。

int axe = 3;
int exe = 4;
int longnmae = 8;
long lonlon = 1L;

http://arton.no-ip.info/diary/20070222.html#p04

以前職場で教わった「きれいなコード」って全処理の構造をコメントで書いたりしてた。ある程度の処理の単位ごとに手動で項番振って「○○処理」とか「○○を××する」みたいなコメント書いて。今思うとなんともアレだけど、当時は大まじめにインデントそろえたり最初にコメント書いたりしてた。

リーンソフトウェア開発を読んでいる。長い間書棚の肥しにしていたのだけど、正直バカだった。すばらしい内容。

読みながら、デブサミ2007での羽生さんの講演を思い出す。「スタロジはウォーターフォール」はある意味でブラフで実は最もLeanに近いところを狙っているよなぁと思う。語義に惑わされず原義の宣言に戻れば agile でもあるし。ウォーターフォールってのは、単に「イテレーションベースでインクリメンタルな開発はしていない」っていう手法の問題だよな。

読んでて初めて気づいたけど、リーンソフトウェア開発って平鍋健児さんが共訳している。何にしてももっと早く読んでおけばよかったな。

リーンソフトウエア開発〜アジャイル開発を実践する22の方法〜

posted with amazlet on 07.03.05

メアリー・ポッペンディーク トム・ポッペンディーク 平鍋 健児 高嶋 優子 佐野 建樹
日経BP社 (2004/07/23)
売り上げランキング: 99757

amazlet.com で詳細を見る

まつもとさんの「まつもとゆきひろ氏のＨＳＰに対する見解について」に対する反応のエントリを読んで、非常に興味深かった。ただし、メインテーマとはまったく関係ないところで。（つまり、HSP 自体の言語としての価値や意義はまったく今回の話の対象外。）

興味を惹かれたのは次の一文。

まあ、「正しい言語」とか存在しないんだけど、それでも「良い言語」と「そうでない言語」はあると思う。しかし、「そうでない言語」であっても当面の目的を果たすのに十分であれば、ユーザを引きつけられるということか。

言語デザイナーの方の感じる「良い言語」とユーザの求める「良い言語」にズレが生じたときに、プログラミング言語でもイノベーションのジレンマ的な現象が起きるのかな、という興味を持ったのだ。（それは必ずしも「良いプログラミング言語」ではないだろうけど。）

ただ、よく考えてみると、プログラミング言語における破壊的イノベーションは、いわゆる総プログラマ社会と同じ話なのかもしれない。

振り返ってみれば J2EE に対する軽量コンテナのように、要求と設計のギャップとそれに対する対抗技術というのはこれまでも存在したし、そもそも Ruby だってできることを全部やるのではなくてある面で削ぎ落としているから、楽しいプログラミング言語になっている。

その一方で、例えば Rails のように DSL 的に働く Helper や plugin を大量動員して開発量は減らすという、フレームワーク＋カスタマイズ型の流れというのも明らかに方向性として出てきている。（もちろん、Java系のフレームワーク＋XML 設定ファイルというのもフレームワーク＋カスタマイズだろう）

この流れがぐーっと進んで、しかも導入の敷居が下がると、どこかで懐かしの（？） End User Conputing との再開を果たして、よく言われる総プログラマ社会に突入をするのかもしれない。（そういえば、 Salesforce.com がやっていることはまんまこれだな。どちらかというと、ERP からの流れなのだろうけど。）

まぁ、他にも何やらもやもや考えたけど、もう一つまとまんなかったので、途中までで投げてしまおう。

はてブで「おお、Gmailはこれで完璧になった」という記事が注目を集めている。

Plagger のクライアントとして Gmail が好まれているのでもわかるけれど、Gmail のインターフェースやユーザビリティはたしかに好ましい。ぼくも普段使いのメーラーとして頻繁に使っている。

ただ、本当に注目しないといけないのは、

まぁ、まだGmailはβテスト中なわけで、バックアップもなしに使う方が悪いのである。

• Gmailがメールを捨てている
• Gmailがメールを捨てている(2)

使うときには、十分に気をつけて。

Ringo's Weblog さんで紹介されていた Tim Berners Lee の提案書が面白い。一読されることをオススメします。素晴らしい文書をご紹介・翻訳して下さっている ringo さんに感謝。

1990年にTim Berners Leeが提出した、最初のWebブラウザ開発の提案文書は、優れたプロジェクト・マネジメントの手本となる文書である。

と書かれているとおり、何かが目を見張るほど卓越した提案書というわけではないが、非常にバランスが取れ、よく練られた内容の提案書になっている。（特殊な技法が使われていてスペシャルな存在になっているとかいう類ではなくて、ベーシックなスキルの積み重ねで全体として高品質な提案書になっている。）

個人的に好きな点は、

• 見通し：やりたいこと、やりたくないこと
• やらないこと

この言い回しは、技術文書だとわりと見かけるのだけど、他の界隈ではあまり見ない気がする。たとえば、スコット・アンブラーの「アジャイルモデリング」でも、『アジャイルモデリングとは何であり、何でないか』という項があり、わかりやすかった。ぜひ取り入れたい書き方だ。

# 「見通し」の部分は原文の scope のニュアンスが絶妙で、相手がプログラマであれば、そのままスコープと呼んでしまいたい気がする。「対象（範囲）」だと重たいんだよなぁ。「照準」だといくぶん良いけど、やっぱりスコープの方が良いよなぁ。

はぶさんの WEB+DB PRESS Vol.21 のセルフ焼直しが素晴らしい。

以下、個人的ポイント。本文の要点ではないのであしからず。

ポイントその１。

ですが、それとは別にインスタンスライフサイクルを示すためのIdentifierの導入が必要だといってるのです。

中々すべてを得心できず、「我ながらあったま悪いなぁ〜」と思いながら、WEB+DB PRESS 読みまくったことを思い出します。けっきょく CRUD と One Fact in One Place の話だというのを理解するのに何十回と読むことになりました。

ポイントその２。

また実際の運用に入ったら、コード体系変更のリスクが予想以上に高いことに気付きます。疎結合を考えたときに、ID導入は実利として有効です。

ほんとに。考えて調整して運用で回避して、あるいは回避するためのアドホックなコードを練り込んで。

ってコストを考えると、考えずにとりあえず ID にしときゃいいじゃん。それでほとんど考えずに流れ作業的に解決できるじゃんと思います。

考えるコストと調整するコストってのは馬鹿にならないです。

判断の DRY 重要。

ポイントその３。

なので業務フローの定義ってのが本当に重要になる。それはデータフローじゃないんです。データが流れるんじゃなくてデータの状態が業務フローに沿って遷移していくということです。

あー、これはすごいわかるなー。

ってことで、最後は DHH の Why bother? で締め。(スライドの「これでよくね?」は名訳。)

そして、あえてこっちをおすすめする。

Web+DB press (Vol.21)

posted with amazlet on 06.08.30

技術評論社 (2004/06)
売り上げランキング: 280,774

amazlet.com で詳細を見る

と、思ったらもう在庫切れなんですね。総集編もないようだし。おとなしく ERDレッスン をおすすめしておきます。

楽々ERDレッスン

posted with amazlet on 06.08.30

(株)スターロジック 羽生 章洋
翔泳社 (2006/04/18)

amazlet.com で詳細を見る

仕事をしている中で、 Windows のネットワーク周りの知識と知恵が物理的にも論理的にも弱点になっているのに気付く。

んで、 Google に聞いてみて「 Windows2003 Server による社内ネットワークの構築」を発見。

まさにこれだよ！という気持ちと、あー、こんな基本的なこともわかっていなかったなんて・・・という気持ちとで複雑。。

あとは、基本でこの辺か。。

@ITの連載「ITアーキテクトを探して（9）」から。

例えばプロジェクトマネージャのように、システム開発全体を指揮するのもITアーキテクトですし、

！？
そうだったの？

まあまあ、相手は常務だ。きっと突然ITなんてわけわからんものに放り込まれて困っているだけさ、と納得して読み進めるとまた驚き。

私はもともとプログラマから始まり、ずっと技術畑を歩んできた人間です。

どうやら、私のITアーキテクト感は改める必要があるようです。

いや、冗談じゃなくてこれとか見ても、常務の言われることの方が正しいんだもの。

うん、やっぱり私はpragmatic programmerとpragmatic problem solverを目指すんでそういうよくわからん世界は近づかないようにします。
近いニュアンスを込めるにしても、システムのdesignerでありたいなぁ。

今さら気付いたってことは、初めてちゃんとITアーキテクトってものに関する記事を読んだんだな。

お願い
海外の書籍とか記事では実は目指すべきソフトウェアアーキテクトがちゃんと書かれているとか、そういう情報あったらぜひコメントください。

こちらは迷わず即予約注文。

WEB+DBPRESSで羽生さんの記事を読んで以来、佐藤正美氏のRAD本も買うわ、SQL書き方ドリルも当然買うわ、WEB+DBPRESSの特別総集編で過去記事漁るわ、と脇は固めてきたけれど、ようやく真打登場というかんじですね。

ま、これすら”Before DI”だってことですが、まずは基礎から固めないとね。今から到着が楽しみです。

楽々ERDレッスン

posted with amazlet on 06.04.15

(株)スターロジック 羽生 章洋
翔泳社 (2006/04/18)

Amazon.co.jp で詳細を見る

ニュースによると、「システム開発大手５社、仕様書共通化」だそうで。

そうは言っても、客先指定のフォーマットがある場合もあるし、大体フォーカスが、

５社は、各社バラバラだった記載方法を共通化して「業界標準」の仕様書を定め、不具合が生じた際のコスト負担について最初の仕様書を決定する段階で明確にすることにした。

にあたっている時点でなんかもう期待できない。

そういう方向性の標準化は明らかなアンチパターンでは。

以下が文中の大手５社なので、業務系のSIerの方は関わってくる所がないかチェックしてみましょう。

• ＮＴＴデータ
• 富士通
• ＮＥＣ
• 日立製作所
• 東芝ソリューション

おお。これはいいかも。

ちょうど引継ぎシーズンであれやこれやあるんで、やってみるか。

via 「マジカ」でお仕事の引継ぎ

なんだか今日はWeb2.0な記事をいくつか見たので、ひさしぶりにこういう話題にコメント。(ここで言う「いくつか」は「一つ二ついくつか」というレベルなので注意。)

火元はR30さんとそこで紹介されているasahi.comの記事だろうか?

どうもWeb2.0と経済活動の話が入り組んで、どこへ抜け出したいのかよくわからないのだが、とりあえず、「Web2.0的なもの」の話をするなら、そこで取り上げるものがどんな価値を生み出すのかを提示しないと、「うん、そうだね。2.0ぽいよね」みたいな話で終わってしまうと思う。

たとえば、del.icio.usであれば広くなり過ぎたWebに対して、その箱庭を自分で作れることに価値があったのだと思う。ただ、その箱庭にはAPIが付いていて、外の世界(別の人の箱庭)につながっていたりして、今までは見ることができなかった"他人の眼で見たWeb"を見ることができたりした。(複数の他人の眼によるWebも含めて)

「こりゃ、おもしろい。しかも便利!すばらしいよね。しかも、技術面でもおもしろい点がいくつかあるんだよ。」というのが一つの視点。

もう一つの視点が、Googleの広告すら載せないdel.icio.usがどうやってやりくりしているのか、という視点。

これも日々少しづつ変化しているし、シリコンバレーの文化に負う部分が大きいので、現時点で言えることがすべてではないのだけれど、Web2.0と言われるようになった最近の変化として感じることがある。

それは、情報サービス(なんだこの単語)というものの将来価値がこれまで以上に非常に大きく評価される状態になったということ。大前研一氏が新資本論で主張し、見えない大陸の特徴として挙げていた「マルチプル経済」がさらに極端になっている。

前述のdel.icio.usがYahoo!に買収されたのもその一例だ。別にIPOを目指さなくてもサービスとそれを生み出す人材が魅力を感じさせれば、ひょっとしたらPC数台に数人しかいない企業が破格の金で売れるかもしれない。

サービスも含めて「売りモノ」として認識できるようなものがなくても、個人にとっては十分に巨額といえる金を生み出せる可能性が拓けている。(この状態が良い姿かは別の問題。ただ、事実としてdel.icio.usもFlickrもIPOを必要とせず売り渡すに十分な額の提示を受けたということに注目する必要はあると思う。)

マルチプルの種になる程度の株価すら必要がなくなっている事実は、可能性と感じるか、それとも虚業と受け取るかは人様々だろうけど、ぼくは買収している人々は誰よりも敏感なパラノイアだからこそ、今その時点で買収をしかけているのだと解釈している。IPOをする頃にようやく価値を測る。それじゃToo Late.だという判断なんだろう。

ここに真性のパラノイアではなくて、単なるお金に敏感な人が大勢絡んでくると、たしかにバブル化しやすいのだろうけど、その本質の部分で今の傾向が単なる踊らされている状況だとは思えない。経済活動としても今後の一つの方向性を示していると思う。(必ずしも目新しくはないけど。ステップが一つ進んだというイメージ。)

ここまでだと、Web2.0のスペシャルな部分というのはあまりない。

どうしてここまで騒がれるかというのは、この二つをぼやかしつつ密につないだところに理由があるような気がする。

Webのスケールっていうのはとてつもなくパワフルで、それに使われるのではなくて、そのパワーを使役するためにはどうすればいいの?という疑問に対して、そのためのいろいろな視点というのがWeb2.0というキーワードで提供された。

で、一方でマルチプルに将来価値を評価されるような企業は例外なくWebのスケールを意識してサービスを提供できる企業だという傾向があった。(その最高峰が会社の戦略自体にWebのスケールに対する目的意識を組込みまくったGoogle?)

それぞれは別々の現象を描いているんだけど、そこを短絡的に結んで「じゃ、Web2.0儲かるじゃん!」みたいな変な走り方をしてしまった(あるいは意図的にさせた)のかな、と思う。そこを目的にしちゃうと何もないのにね。

うだうだ書いたけど、まとめにしては陳腐なのでそろそろ止め。

Life is beautifulさんの

• ソフトウェアの仕様書は料理のレシピに似ている
• 知的労働者には「組織を移る力」がある

を読んでの感想。

あと、併せて読んだ話は下の二つ。どこかで話が重なる部分があるかも。

• 浮ついた「ギーク」への説教（※老害注意）
• プログラマとして

産業としてのSIerについて語りたいのか、プログラミングスタイルについて語りたいのか。それはさておくとしても、少なくとも誰のために何を作る話をしているのかははっきりしないと意味がないんじゃないかと思います。

もちろん、一般論としてのプログラミングスタイルとしてどちらがより優れたものが作れるのかなんていうのは議論するまでもないです。

ただ、その上でスケールしやすいパッケージ系のソフトウェアビジネスについての話なのか、それとも儲けの上限が決まっていて一人一殺形式だからスケールしにくいSIビジネスについての話なのか、というのははっきりしないと抽象論で終わってしまって、「上流下流の分離いくない。以上、おわり」みたいな話になってしまうわけです。(中島さんのエントリがそうだったとは言いません。ただ、このエントリを受けてこのように短絡的に理解する人は大勢出たのではないかと思います。)

例えば、パッケージ系のソフトウェアビジネスであれば、Googleを作ったり、WindowsやOfficeを作れば、天井知らずの儲けが期待できるわけです。それならば、優秀なデザインをできる天才ハッカーを集めて最高のサービスで最大の利益を目指すことも一つの有効な戦略だと思います。

しかし、SI業ではそうはいきません。ある一社の要望を受けて、天才プログラマがGoogleばりのスーパーな製品を作ったとしましょう。それでも、このすばらしいプログラムはビジネスとしてはスケールを生みません。品質や製品としてのデザインの優位性、メンテナンスまでを考えた場合のコストパフォーマンス、すべてがすばらしいかもしれません。それでも、その一つの仕事が何百億の時価総額を生むことは絶対にないのです。なぜなら、それを使うお客さんにとって、それは何百億を生み出すものではないですから。

プログラミングスタイルとしてあるべき姿と、産業としてビジネスとして妥当な姿を混ぜて議論してはいけないです。(妥当は語弊があるかも。必要悪というか、仕方ないというか、少なくとも現在のところは残念ながらベターな選択肢を見出しているところが少ないとでもいうべきか。)

実際、優秀なプログラマと一山いくらのプログラマの生産性の違いは20倍なり100倍なりあるでしょう。開発速度だけでなく、品質、保守でのコストを考慮するともっとあるかもしれません。

それでも、そんな優秀なプログラマの人数がSI業の需要に対して足りているとは思えません。そうなると、ビジネス上の判断として、一つの対応として、上流下流の分離なり、人月30万の人海戦術なりで物事を進める必要があるわけです。たとえ悪手に見えようと。

批判すべきは、それが結果として期待されたレベルで成立していないことです。それはたとえばJoelの言葉を借りれば、マニュアルを整備してSI業をスケールさせようとしたのに、スケールしなかったというような点を批判すべきなのです。

マニュアルが悪い、段取りが悪い。だから、一山いくらのプログラマでもどうにかお客さんが望む成果を出せるだけの「より良い段取り」を作ろうじゃないか。そんな提案が必要なのだと思いますし、実際にSI業を真摯にとらえている人の中ではたとえばGoyaのような動きが出てきたりしているわけです。(Goyaはまさによりよい段取りという方向性だと思います)

一方で、SI業をスケールしやすいパッケージビジネスにしようという動きの急先鋒としてSalesforce.comがあったりします。GoyaやSalesforce.comが成功するかはわかりません。ただ、正しい現状認識に基づいて少しでも前進しようという動きに見えます。

後記。そんな私の最近はCODE COMPLETEとオブジェクト指向入門(OOSC)と格闘中。趣味でモノヅクリをしている人としては、本当は同意したい部分も多々あるのだけど、仕事としてサービスを提供して対価をもらっている身としては安易に同意もできずエントリしました。

※Goyaについて

• こことか
• こことか
• WEB+DB PRESS Vol.31とか

Web+DB press (Vol.31)

posted with amazlet on 06.03.30

技術評論社 (2006/02)

amazlet.com で詳細を見る

年の暮れだからこそ、今年の技術的なトレンドへ乗り遅れないように復習をしたいもの。

Web2.0が脚光を浴びた2005年。とりあえずこの5つの分野から苦手分野をきっちり潰していきたいと思います。（多分にぼくの偏見と苦手分野の重視が影響している点はご了承ください。）

• Ajax
• Ruby on Rails
• HTML/CSS
• Javascript
• 正規表現

ということで、おすすめの書籍やサイトを総括。

Ajax

2005年はこれしかないでしょう。猫も杓子もAjaxと連呼した年でした。

Ajax: Web アプリケーション開発の新しいアプローチ
http://antipop.gs/docs/translations/ajax.html
これがなくちゃ始まらないですから。

Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ
http://satoshi.blogs.com/life/2005/06/ajax.html
文系の人はまずこれから読むのをオススメします。

Ajax reconsidered (英語)
http://www.adambosworth.net/archives/000044.html
http://www.adambosworth.net/archives/000045.html
Adam BosworthもAjaxについてごにょごにょ言ってました。

prototype.js v1.3.1 の使い方
http://www.imgsrc.co.jp/~kuriyama/prototype/prototype.js.html

prototype.js version 1.4.0系でのEnumerableの使い方
http://www.onflow.jp/blog/archives/2005/11/prototypejs_ver.html

作って理解するAjax
http://itpro.nikkeibp.co.jp/article/COLUMN/20051104/224040/
http://itpro.nikkeibp.co.jp/article/COLUMN/20051125/225193/
http://itpro.nikkeibp.co.jp/article/COLUMN/20051215/226333/

Remote Scripting with AJAX (英語)
http://www.xml.com/pub/a/2005/08/19/ajax.html
http://www.xml.com/pub/a/2005/08/22/ajax.html

Ajax on Rails (英語)
http://www.onlamp.com/lpt/a/5944

10 Places You Must Use Ajax (英語)
http://www.sourcelabs.com/blogs/ajb/2005/12/10_places_you_must_use_ajax.html
すべてに同意はしないけど参考に。

あとは、興味深い実装など。

prototype.js の Ajax.Responders.register
http://d.hatena.ne.jp/secondlife/20051119/1132326795

YukiWiki で Ajax を使って編集途中の文書を自動保存
http://blog.woremacx.com/2005/09/yukiwiki_ajax.html

Ajax を使った KWIC (KeyWord In Context)
http://chasen.org/~taku/software/ajax/kwic/

Ajax を使った 日本語 IME + KWIC
http://chasen.org/~taku/software/ajax/imekwic/

Ajax を使った手書き文字認識
http://chasen.org/~taku/software/ajax/hwr/

Ajax を使った日本語 Full IME
http://chasen.org/~taku/software/ajax/fullime/

ajaxで「戻る」「進む」（feedbringerをremixin' #7）
http://mizzy.org/web/feedbringerRemixing07.html

map.rails2u.com
http://map.rails2u.com/

買った本。

JavaScript & DHTMLクックブック―Webエキスパート必携テクニック集

posted with amazlet on 05.12.18

ダニー グッドマン Danny Goodman 村上 列
オライリージャパン (2004/01)
売り上げランキング: 1,845

amazlet.com で詳細を見る

WEB+DB PRESS Vol.27

posted with amazlet on 05.12.18

WEB+DB PRESS編集部
技術評論社 (2005/06/24)
売り上げランキング: 6,638

Amazon.co.jp で詳細を見る

伊藤直也さん＆増井雄一郎さんが記事を書いていたので。

期待している本。

Ajax 実装のための基礎テクニック

posted with amazlet on 05.12.18

増井 雄一郎 深津 貴之 川崎 有亮 台場 圭一
技術評論社 (2006/02/03)

Amazon.co.jp で詳細を見る

Pragmatic Ajax

posted with amazlet on 05.12.18

Ben Galbraith Dion Almaer Justin Gehtland
Pragmatic Bookshelf (2006/03/15)

Amazon.co.jp で詳細を見る

http://pragmaticprogrammer.com/titles/ajax/index.html
"Pragmatic"の看板に期待して。

Ruby on Rails

Ruby on Rails: David Heinemeier Hanssonへのインタビュー
http://capsctrl.que.jp/kdmsnr/wiki/transl/?AnInterviewWithDHH
O'REILLY NETWORKのインタビュー記事の邦訳。Railsに関してはDHHの話を読むのが一番だと思います。

ひそかに人気を集める開発ツール「Ruby on Rails」--無駄な複雑性の省略を目指す
http://japan.zdnet.com/news/devsys/story/0,2000052522,20089998,00.htm
CNET News.comの記事の邦訳。誰もが「ひそかに」じゃないだろう、と突っ込んだ。

Rolling on Ruby on Rails - Japanese Translation -
http://blog.livedoor.jp/zep716/archives/24182409.html
ONLamp.comのCurt Hibbsの記事の邦訳。というか、うちのエントリ。

簡単Ruby on Railsの決定版？ - Instant Rails -
http://blog.hacklife.net/archives/50190377.html
これまたうちのエントリ。でもほんとに便利ですよ。

railsのacts_as_taggableで簡単にtagging実装
http://d.hatena.ne.jp/secondlife/20050829/1125242011

RailsのInflector
http://blog.bmedianode.com/2005/08/railsinflector.html
「悪名高き（？）「personがpeopleになる」仕様の実装箇所」とのこと。

webアプリケーションテストツール seleniumがヤバすぎる
http://d.hatena.ne.jp/secondlife/20050525/1116947520
Railsでseleniumに関する記述。

Railsの最適化に関する10の事柄
http://d.hatena.ne.jp/secondlife/20051025/1130211403

Rails pluginの作り方
http://d.hatena.ne.jp/secondlife/20051101/1130850457
gorouさんの記事ばかりになってきた（笑）

Ruby on Rails (PDF)
http://ll.jus.or.jp/2005/files/lldn2005-rails.pdf
高橋征義さんがRailsの特徴をまとめた資料。LLDN2005の資料らしい。

ログインジェネレータいろいろ
http://d.hatena.ne.jp/drawnboy/20051022/1129946815

Full Theme Support in Rails, Revisited (英語)
http://www.mattmccray.com/archives/2005/10/26/full-theme-support-in-rails-revisited/
http://rubyforge.org/projects/theme-generator/
Raisのテーマジェネレータ。使ったことはないけど気になっているので。

REST on Rails (英語)
http://www.xml.com/pub/a/2005/11/02/rest-on-rails.html

RESTified Rails Controller (英語)
http://microformats.org/discuss/mail/microformats-rest/2005-November/000042.html

Top 12 Ruby on Rails Tutorials (英語)
http://www.digitalmediaminute.com/article/1816/top-ruby-on-rails-tutorials
Railsチュートリアルをまとめたエントリ。

What Is Ruby on Rails (英語)
http://www.onlamp.com/pub/a/onlamp/2005/10/13/what_is_rails.html
Curt HibbsがRailsについてまとめにまとめまくった内容。

Agile Web Development With Rails: A Pragmatic Guide (The Facets of Ruby Series)

posted with amazlet on 05.12.18

David Thomas Daivd Heinemeier Hansson Leon Breedt
Pragmatic Bookshelf (2005/09/22)
売り上げランキング: 3,522

Amazon.co.jp で詳細を見る

WEB+DB PRESS Vol.28

posted with amazlet on 05.12.18

WEB+DB PRESS編集部
技術評論社 (2005/08/25)
売り上げランキング: 5,447

Amazon.co.jp で詳細を見る

HTML/CSS

この辺からぐんと苦手度がアップして取り上げ方がいいかげんに。たぶんターゲットが全然絞れていないと思います。むしろ突っ込みまくっていいサイトを教えて頂けると助かります。

XHTMLの最適化手法
http://www.cybergarden.net/blog/2005/12/xhtml_optimization.html

便利な早見表 CSS HTML Javascript など色々
http://www.goodpic.com/mt/archives2/2005/09/_css_html_javas.html

CSS 入門
http://blog.so-net.ne.jp/nakagami/2005-10-19

Dynamic HTML Styling
http://members.at.infoseek.co.jp/dhtml_s/

Cascading Style Sheets and Dreamweaver CSS Reference Sites (英語)
http://www.dreamweaver-templates.org/css-resources.htm

訪問済みリンクを一工夫する
http://www.lucky-bag.com/archives/2005/09/visited_link.html
訪問済みリンクにチェックを入れて明示する

左側にスクロールバー
http://www.stylish-style.com/csstec/hi-level/leftbar.html

ブラウザ別CSSハック一覧表
http://codeweb.seesaa.net/article/7658025.html

10 Tips To A Better Form (英語)
http://particletree.com/features/10-tips-to-a-better-form/

CSS Hacks and IE7 (英語)
http://www.positioniseverything.net/articles/ie7-dehacker.html

この分野で読んだ本は、

スタイルシート スタイルブック

posted with amazlet on 05.12.18

有坂 陽子 長谷川 恭久
翔泳社 (2004/02/11)
売り上げランキング: 19,264

amazlet.com で詳細を見る

Javascript

これまた苦手。Rails使っていてもサーバーサイドのロジック組むよりもクライアントサイドを組むのに手間取りまくってます。同じく突っ込み大歓迎。

JavaScript: 世界で最も誤解されたプログラミング言語
http://d.hatena.ne.jp/brazil/20050829/1125321936

naoyaのはてなダイアリー - prototype.js でデザインパターン
http://d.hatena.ne.jp/naoya/20050813/1123919908
http://d.hatena.ne.jp/naoya/20050813/1123921179
http://d.hatena.ne.jp/naoya/20050813/1123922039
http://d.hatena.ne.jp/naoya/20050813/1123923325
http://d.hatena.ne.jp/naoya/20050813/1123924312
http://d.hatena.ne.jp/naoya/20050813/1123961196
http://d.hatena.ne.jp/naoya/20050813/1123963135
http://d.hatena.ne.jp/naoya/20050814/1124000780
http://d.hatena.ne.jp/naoya/20050817/1124279450

初心者でも使えてプログラマでも困惑するJavaScript
http://d.hatena.ne.jp/m-hiyama/20050803/1123041897

プログラマのためのJavaScript
http://d.hatena.ne.jp/m-hiyama/20050808/1123486683
長期連載の目次ページでもある。

実践JavaScriptリファクタリング
http://la.ma.la/blog/diary_200510060733.htm
http://la.ma.la/blog/diary_200510062243.htm

Data::JavaScript::Compactor
http://d.hatena.ne.jp/naoya/20050928/1127884800
「余計な空白を落としたりコメントを削除したり改行を削除したりしてJavaScript のソースを短くするモジュール」

Javascript+HTML のデザインパターン
http://yohei-y.blogspot.com/2005/09/javascripthtml.html

Virgo - Library
http://www.graviness.com/virgo/classlibrary/

ruby.js
http://whytheluckystiff.net/clog/ruby/rubyDotJs.html
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/117184
http://openjsan.org/doc/f/fl/flgr/ruby/js/0.4.0/

Javascript ActiveRecord
http://www.kiko.com/jsactiverecord/

ブラウザ上でお絵かき
http://nanto.asablo.jp/blog/2005/09/27/89628

E4X (ECMAScript for XML)
http://www.kmonos.net/wlog/49.php#_1520050427

JSON入門
http://d.hatena.ne.jp/brazil/20050915/1126709945

JSON/簡単なテスト:基本
http://jsgt.org/ajax/ref/test/json/test1.htm

JavaScript 入門
http://blog.so-net.ne.jp/nakagami/2005-10-25-1

del.icio.us direc.tor
http://johnvey.com/features/deliciousdirector/

あとはもうとにかくここ( http://la.ma.la/blog/ )とかここ( http://la.ma.la/js/ )とかここ( http://del.icio.us/ma.la/javascript )とか見まくればいいと思います。

買った本。

JavaScript

posted with amazlet on 05.12.18

デイビッド フラナガン David Flanagan 村上 列 垰井 正雄 安藤 進
オライリー・ジャパン (2000/12)
売り上げランキング: 4,639

Amazon.co.jp で詳細を見る

JavaScriptビジュアル・リファレンス

posted with amazlet on 05.12.18

シーズ
エムディエヌコーポレーション (2004/11)
売り上げランキング: 29,745

Amazon.co.jp で詳細を見る

正規表現

Webで公開されているアプリケーションを見ていて感じたのが、うまいプログラミングをしている人は正規表現を使いこなしているということ。冗長になりがちなところが正規表現でごにょごにょっと解決されているから、他のロジックがきれいに見やすくなっているんですよね。ということで、今年はいいかげん避けて通れないかなぁと思いました。これまでは適当には使い散らかしていたんですが、ちゃんと勉強してみることにします。

ということで、最後にこれから買う本。

詳説 正規表現 第2版

posted with amazlet on 05.12.18

Jeffrey E.F. Friedl 田和 勝
オライリー・ジャパン (2003/05/26)
売り上げランキング: 19,679

amazlet.com で詳細を見る

Life is beautifulさんの次世代Officeの話へ脊髄トラバしてみる。

ブルーオーシャン的なアプローチとしては、「ドキュメントなんて飾りです。偉い人にはそれが分からんのですよ」戦略とかおもしろいかも。

そもそもオフィスでドキュメントを扱おうというのは紙を使って仕事をしていた時代の名残でしかなくて、実は個別のドキュメントって本質的には必要じゃない。

オンデマンドで元となるデータから好き勝手な形式で作り出せた方が、同じようなドキュメントの元データをあちこちでメンテナンスする手間が省けていいんじゃない？コストもぐーんと下がりますよ。ってベネフィットを売り込んでみる。

まず、『けっきょく会社で使うドキュメント（紙、電子ファイルに関わらず）って企業の中で扱われている何らかのデータのビューでしかない』という主張をドーンと打ち出す。

そして、すべての生データはモデルとして扱われ、都度表現する現在のドキュメントは随時ビューとして好き勝手な形で、それこそファイルフォーマットなんてお好きなように発行しまくりますよ？と新しいツールにだまされやすい層を狙ってみる。もちろんERPとかMVCとかアルファベット3文字で煙に巻きつつ。

----

とここまで書いて、言っていることの9割はsalesforce.comがやれそうな気がした。よって、Office製品の一番のライバルはsalesforce.comだという結論で。

※　ちょっとまじめに追記すると、ドキュメントって時間軸の中のある時点を切り出して誰かに対してその時の説明なり状況を担保する役割で使われるケースが多いので、モデルの方で更新の履歴はすべて追える必要がある。過去のものもいつでも発行できますよ、って保証しないと皆必ずローカルへ丁寧に保存するな。

突っ込まれる前にさらに追記しとく。

このぼくのエントリ、ブルーオーシャン戦略の本来の定義からは外れていると思います。単なる同一業種、新しい価値軸での挑戦ですね。

そもそも脊髄反射なのでブルーオーシャン戦略なアプローチを取って検証した話ではありません。未読の方の誤解を招きそうな、”悪意のマーケティング用語・ブルーオーシャンの誤用”です。そんなわけで”ブルーオーシャン的”としときました。

とても良い本なのですが、わかりやすい言葉だけが一人歩きしているので、未読の方はぜひ書籍で読まれることをお薦めします。正面衝突せずに新しい価値軸でサービスを考えるための実践的なフレームワークが書かれています。

ブルー・オーシャン戦略 競争のない世界を創造する

posted with amazlet on 05.12.18

W・チャン・キム レネ・モボルニュ 有賀 裕子
ランダムハウス講談社 (2005/06/21)
売り上げランキング: 55

amazlet.com で詳細を見る

Alex BosworthがDelimagesというちょっと面白いサービスをリリースしていました。
http://www.sourcelabs.com/blogs/ajb/2005/12/delimages.html

delimagesは、del.icio.usのブックマークから、ファイルの拡張子がjpgのものを集めて、その画像を表示するサービスです。

del.icio.usにはjpgに対するブックマークを意味するsystem:filetype:jpgというタグがあり、そのブックマークを一覧表示することができます。

delimagesは、ブックマークとして一覧表示するのではなくて、実際のブックマークされた画像を一覧表示するものです。

例えば、ネコに関するjpg画像へのブックマークを集めて見てみるとこんな風になります。癒されます。

del.icio.usのシステムが提供しているsystem:filetype:jpgという仕組みと、タグというメタデータそのものを組み合わせてWebから自分のほしいデータを抽出してくるという流れがうまく言えないけれど可能性を感じました。非常に目新しい！というわけではないですが、面白いです。

最近の一連の流れ*1を見ていて思ったこと。

「なんであの馬鹿共はこんなに優れたテクノロジーを使おうとしないんだ！」

「それは、君が思っているよりも彼らは賢いからだよ。」

この考え方をなくしたらテクノロジーは終わりだと思う。

さげすまれてまで”手段”を使おうという人はいないんだから、分を知らないといけないということで。

*1: 自分の頭の中で一連にまとめただけで、世間的にはまったく一連ではなかったりする

「過去記事と話題がかぶる記事を探してひたすらTBを打てば、あら不思議、アクセスアップですよ。」って記事を書いたYahoo!ブログとはてなの空気の違いが笑えた。まぁ、正直元記事書いた人には災難。気の毒でもある。

http://b.hatena.ne.jp/entry/http://blogs.yahoo.co.jp/nonakajun/777584.html

個人的にははてなブックマークの方に気持ちは近いのだけど、livedoorブログとかいう腑抜けたブログサービス*1に住んでいる者としては、はてブユーザーの意見が偏りまくっているのもすごいもんだと感心した。

あまり自分たちが良貨だと思っていると、悪貨に駆逐されちゃうかも。livedoorなんかは悪徳業者やらオレオレルールのブログがはびこりまくってるし。最後ははてな総モヒカン化で最後の砦になるのかな。

ともあれ、スケーラブルで”文化的に”セキュアな仕組みってのはむずかしいね。

*1: いや、実はカスタマイズしまくれるし、けっこう重宝してますが。

「設計者の発言」さんの「ユーザがなかなか仕様を決めてくれないって？」をとても興味深く読みました。

「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。（略）問題はどちらかといえば設計者の側にある。

で始まるこのエントリでは、設計者がユーザの反応を見ながら提案内容をどんどん修正し最終案としてまとめるという、「インタラクティブなやりとり」が必要という主張がされています。

ただ、この話は仕様決めと要件定義をごちゃまぜにしている部分があるように思います。たしかに実際に作業を進める上では、この二つがフェーズとして重なることもよくあります。ただ、少なくともエンジニアの頭の中では明確に切り分ける必要があると思っています。

そして、このエントリで言われる「インタラクティブなやりとり」が必要になるのはどちらかというと要件定義の時です。ユーザの目的に沿ったシステムをイメージしてもらうためにラフなシステムのイメージを描いては捨てながら、だんだんと具体化していくのはたしかに要件定義で有効な方法だと思います。

一方で、仕様決めでは実は答えは決まっています。仕様決めの最終的なアウトプットとして必要なのはシステムが作れるレベルまで具体化されたスペックです。

「オンラインで支払いまで完了できるようにしたい」というのが要件で、「OKを押したら支払い画面へ行きます」「キャンセルのときはTop画面へ戻ります」「入力不備の際は再度入力画面へ移動します。入力不備の条件はhogehogeです」というのが仕様です。そして、これをやるにはMVCでこうやってhogeって・・・というのが設計です。

なので、実は仕様のアウトプットの正確な姿を一番よく知っているのはエンジニアなのです。お客さんは何がわかればシステムが作れるのかは知りません。だからこそエンジニアが必要なわけです。

この辺りの課題を解決するのには「仕様の仕様」を提示するのがいいかなと思っています。「自分が必要としているアウトプットはこのレベルです。」というのをユーザーに提示して穴埋め問題式で仕様を決めてもらうのです。「○○のときは××である」というのをずらーっと並べて一つ一つ詰めていくことになるのですが、この一覧をそのままユーザーに突きつけるのは不親切なので、頭の中の一覧を一つ一つわかりやすい表現で確認していくのがいいようです。

「○○が××になるのはどんなときですか？」「じゃあ、△△のときはこうなるんでしょうか？」「□□のときは●●ですかね？」といったかんじで実装できるレベルまで仕様を詰めていくわけです。（繰り返しになりますが、話の中では要件と仕様と設計の話が行ったり来たりしがちなので、自分の頭の中ではきっちりとラベルを貼って今どんな話をしているか判別する必要があります。）

これをやらずに「ユーザーが仕様をきっちり出してこない！」と憤慨するのはエンジニアの怠慢かスキル不足なのだと思うのですよ。（誰に言ってんだか）

水かけても仕方ないので、トラックバックはしない。ただ、自分のWeb2.0とやらへの姿勢として書いておく。某所の2エントリを読んでの話。

Web2.0的であることが目的ではなく、「ビジネスとしての競争力がどの手段で最大化されるか」が一番のテーマであり、そのための手段にWeb2.0的なもので良い手段となれるものがあるか、という検討をすべきではないか。

たとえば、「ビジネスを円滑に進めるための、ボーダレスに情報を共有できる組織・仕組み作り」が目的あり、そのための手段としてブログやWikiが使えるんじゃない？ってアプローチになるはず。（じゃあ顧客にプレゼンするのにツールをプレゼンしても意味がない、というのは当然。）

はてなのようにイノベーションを起こし続けることが存在意義になってしまっているポジションの企業はともかく、実地のビジネスに使うのであればWeb2.0は相当に考え抜いて使わないとまさにBuzz化すると思う。

どうも要素技術に引っ張られすぎなのではないだろうか。（と、技術者でコード書いたりしているやつが言ってみる）

ちなみに

＞はてなのようにイノベーションを起こし続けることが存在意義になってしまっているポジション

これ、否定的な意味ではない。現時点のポジションでは、今のはてなの姿勢は正しいと思う。大前研一氏がいうところのマルチプル経済が働くから。ただ、これが飛躍のきっかけであるが故に少なくとも「他人の起こしたイノベーションに遅れを取れない立場になってしまった」とも言えると思っている。（あくまでマルチプル経済を原動力とするならば、という仮定の話。イノベーション企業であろうとするならば、この限りではない。）

なんか、ブクマで言いっ放しは卑怯者のすること！みたいな意見もあるようなので否定的意見はブログに書いておく方向で。

マジカセミナーのメモを一つ忘れてた！

条件分岐の話メモ。

if文（のような条件分岐）の３つの役割は、

• エラーチェック
• ルール（Y/Nを返す）
• フロー制御

のいずれかに分類される。

それぞれごっちゃに混ぜてコードを書いちゃいかんよ、って話。

感覚として使い分けていた部分もあり、いや、あやしいなって部分もあり、いやいや、結局即答できなかったんでわかっちゃいないな、と大人しくメモって帰ってきました。

で、Web2.0どころか思い切り足下の、目の前の問題を解決するためのツール、マジカのセミナー行きました。

って話の前振りだったはずなのに、ムダに前振りが長くなりすぎた！

えー、まずはマジカすばらしい。他の優秀なツールと同じく、使い道を見誤らなければとてもすばらしいツールだと思う。

エンジニアリングの限界とかの言葉でごまかされがちな部分に切り込める武器になりそう。

心残り。

• マジカの実績（規模、期間、人数）の辺りが時間切れ＆自分自身のその後の都合で質問できなかったこと。25日の方で聞いてみよう。
• いわゆる「本社型」の組織でのシステム開発でのマジカの使い方を突っ込んで聞いてみたかったけど、これも聞けず。ToBeありきで発注元本社（＝AsIsは当然反映済みという前提）というスタイルとマジカとの相性、とか。

WEB+DB PRESS Vo.25の記事よりもかなり洗練されたなーという印象。

Web+DB press (Vol.25)

posted with amazlet on 05.11.11

技術評論社 (2005/02)
売り上げランキング: 28,979

amazlet.com で詳細を見る

てことで、一通り読んではいるのだけど、もう一度、二度、三度と読んでみよう。

はぶにっきの[マジカ]タグ

あと

はぶにっきの[Goya]タグ

どうでもいい話ですが、初めて羽生さんを拝見しましたが、SQL書き方ドリルのお写真よりも大分迫力ある方でしたよ。。とても「ZGIIが・・・」と書いている方と同一人物には見えませんでした。

あちこちでどんどん本質的でなくなっていくWeb2.0論が（悪い意味で）おもしろい。

『特に深い意味はない。要素には注目すべき点がある。今後のWebで必須になってくる部分で事業へ活かせるものは、真剣に検討しろ。しかし、あとはBuzz。』

ってことでいいのでは？

個人的には、おそらくTim O'Reillyとか梅田さんとかの自覚的”おっちょこちょい”の人が「わっ」と言ったことに対して、字義どおりにおっちょこちょいな人が「わっわっわわー！！」と妙に大騒ぎになっているかんじが笑える。

積極的に参加はしないけど、笑えるので、まぁ、いいか、と。

codemaniaxさんのエントリやmojixさんの「ニューウェイヴ」や「イケメン」のエントリは気持ちとして近かった。

エンジニアの目指すべきものってのは、「テッキーのテッキーによるテッキーのためのテクノロジー」なのだろうか？

僕はそうは思わない。Web2.0的なものは手段であって目的ではない。

そういう意味で、「Web2.0」というラベルが一人歩きすること、そしてそれによってエンジニアが一喜一憂（右往左往）している様に不安を禁じえない。

「価値の本質」をもっと突き詰めなければ。

Web2.0的言説に乗りづらい理由
http://d.hatena.ne.jp/codemaniax/20051106/1131274997

「Web 2.0」とは、ニューウェイヴと同じように、新しい動向をなんでも放り込んでおくためのコンセプトだ。

Web 2.0は 「ニューウェイヴ」 なのだ
http://mojix.org/2005/10/03/155810

それは技術タームというにはあまりにも包括的で漠然としており、むしろ「マーケティング用語」だ。オライリー自身が主催する「Web 2.0カンファレンス」を盛り上げるための「バズ（buzz）・マーケティング」という側面もあった。

「Web 2.0」 は 「イケメン」 と同じく、格付けのための概念だ
http://mojix.org/2005/11/10/074358

だからこそ、「ニューウェイヴはなぜすごいか」を騒ぐんじゃなくて、「Aztec Cameraのどの点が天才的でどの要素が20年後の人の心も打つのか」を語らないといけないわけだ。（あとは、まずWeb2.0のAztec Cameraを見つけないとね。）

これは単なる憶測だけど、Tim O'Reillyは"Ajax"という単語が巻き起こした動きような意味で、"Web2.0"という単語で一連の自分の主張（しかもけっこう古いものも含まれる）に楔を打ちたかったんだと思っている。"Open Source Paradigm Shift"(2003)と呼んでいた頃に比べるとかなりTim O'Reillyの中での主張も固まってきていて、意地悪な言い方をするとそれに匹敵するくらい新しいコンセプトは生まれていない。"Open Source Paradigm Shift"のコンセプトに沿ってそれが甚だしく成長していっているのが現在だと思うので、一端"Web2.0"という括りで区切ったんじゃないかな。

TBを頂いたので、エントリしておきます。

すでに受付は締め切られておりますが、ミーハーな人大喜びなオールスターメンバーで開催される第八回XML開発者の日がパネルディスカッションのお題募集をしているそうです。

参加される方は「案を出していただいた方は当日開かれる宴会に参加可能！」に釣られて応募してみてはいかがでしょうか？

個人的には突然「見慣れない場所の物語」を発表されたハテナオヤ先生の心象風景についてあれこれ語ってほしいところです。岩明均のカササギの話かと思いました。（あちら側に真実はあったんでしょうかねぇ？＜カササギの方）

七夕の国 (1)

posted with amazlet on 05.11.07

岩明 均
小学館 (1997/06)
売り上げランキング: 146,140

amazlet.com で詳細を見る

飲み会参加したいので、とりあえずマジメにお題を考えてみるとします。（gorouさんと高橋さんがいるからぜひRuby or Rails話を聞きたいけどダメだろうなぁ。）

del.icio.usで見かけたのだけど、Googleの新サービスが予定されているらしい。

Google Base: All your base are, in fact, belong to us
http://arstechnica.com/news.ars/post/20051025-5480.html

Google Base is Google's database into which you can add all types of content. We'll host your content and make it searchable online for free.

Examples of items you can find in Google Base:

• Description of your party planning service
• Articles on current events from your website
• Listing of your used car for sale
• Database of protein structures

You can describe any item you post with attributes, which will help people find it when they search Google Base. In fact, based on the relevance of your items, they may also be included in the main Google search index and other Google products like Froogle and Google Local.

ずいぶんと思い切った内容だ。

”ぐぐるたんのニセインターネット”の「ぐぐるたんは、なにか新しいアイディアを実現するときに、自分の持っているニセインターネットを活用できる。」では飽き足らないらしい。

これで全面的にGoogleがあらゆるサービスのデータを握るようになったら、「インターネットの検索サービスGoogle」から「インターネットとはGoogleで検索したもの」という存在へ、つまりニセインターネットがホンモノインターネットへ化けてしまう。（あるいはインターネットのミドルウェアという存在。まさにインターネットのIntel Insideだ。）

たしかに仕事でOutlookを使わざるを得ないときなんかに、Gmail並の検索性能がないことにイライラしたりすることはある。

だから、

Think about it. When using eBay or Craigslist, how often do you think "I wish I could search this with Google"?

という気持ちはよくわかる。これは便利だろう。

便利だけど、はたしてこれを”インターネット”が許すのか。今後の動きがとても興味深い。（そもそもこれって本当にサービス開始されるのかも含めて）