2005年の技術的なトレンドに乗り遅れないための5つのテーマ

by tanabe on December 21, 2005

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

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エキスパート必携テクニック集
ダニー グッドマン Danny Goodman 村上 列
オライリージャパン (2004/01)
売り上げランキング: 1,845


WEB+DB PRESS Vol.27
WEB+DB PRESS Vol.27
posted with amazlet on 05.12.18
WEB+DB PRESS編集部
技術評論社 (2005/06/24)
売り上げランキング: 6,638

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

期待している本。

Ajax 実装のための基礎テクニック
増井 雄一郎 深津 貴之 川崎 有亮 台場 圭一
技術評論社 (2006/02/03)

Pragmatic Ajax
Pragmatic Ajax
posted with amazlet on 05.12.18
Ben Galbraith Dion Almaer Justin Gehtland
Pragmatic Bookshelf (2006/03/15)

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)
David Thomas Daivd Heinemeier Hansson Leon Breedt
Pragmatic Bookshelf (2005/09/22)
売り上げランキング: 3,522

この本は今年一番の収穫。Rails開発者のDHHが書いているだけあり、Railsらしい開発手順でRailsを使うためのノウハウがたっぷり詰まっている。

WEB+DB PRESS Vol.28
WEB+DB PRESS Vol.28
posted with amazlet on 05.12.18
WEB+DB PRESS編集部
技術評論社 (2005/08/25)
売り上げランキング: 5,447

前にも紹介したけどやっぱり日本語の書籍ではこの解説が今のところベストかな。高橋さんの文章は本当にわかりやすいです。

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

この分野で読んだ本は、

スタイルシート スタイルブック
有坂 陽子 長谷川 恭久
翔泳社 (2004/02/11)
売り上げランキング: 19,264

とてもわかりやすかったです。わかっている人には物足りない内容かもしれません。

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
JavaScript
posted with amazlet on 05.12.18
デイビッド フラナガン David Flanagan 村上 列 垰井 正雄 安藤 進
オライリー・ジャパン (2000/12)
売り上げランキング: 4,639

JavaScriptビジュアル・リファレンス
シーズ
エムディエヌコーポレーション (2004/11)
売り上げランキング: 29,745

これはもうma.laさんが薦めてたから。ただそれだけで買いました。これからは本の帯に「アルファギークが使う」とか入れればいいと思います。

正規表現

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

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

詳説 正規表現 第2版
詳説 正規表現 第2版
posted with amazlet on 05.12.18
Jeffrey E.F. Friedl 田和 勝
オライリー・ジャパン (2003/05/26)
売り上げランキング: 19,679

  

一足早く2006年を予言する。

by tanabe on December 19, 2005

2006年は"portable gadget meets Web2.0"がテーマになる!

携帯電話はもちろんのこと、iPodやNintendoDS、PSP、W-ZERO3のようなポータブルデバイスが非常に元気になっている。ネットワークを利用する環境もずいぶんと整備されてきており、2006年はポータブルデバイスでソーシャルネットワーキングがキャズムを越える。かも。

と言ったモン勝ちで断言してみるテスト。

別に深い内容はないもののハッタリをかましてみる。もし当たったら来年の今頃に一人で騒ぐ。(たぶん忘れてるけど)

  

Officeを駆逐する「ドキュメントなんて飾りです。偉い人にはそれが分からんのですよ」戦略

by tanabe on December 18, 2005

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

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

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

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

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

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

----

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

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

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

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

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

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

ブルー・オーシャン戦略 競争のない世界を創造する
W・チャン・キム レネ・モボルニュ 有賀 裕子
ランダムハウス講談社 (2005/06/21)
売り上げランキング: 55

  

どうぶつの森はmixiより面白い?もしくは「カナダプレイ」って何?な話

by tanabe on December 18, 2005

もういしたにさんのこの記事を読んでからどうぶつの森が欲しくてたまらない。どうぶつの森も気になるが、このエントリ自体も秀逸だ。

どうぶつの森ってなんでこんなにおもしろいわけ?・ネットワーク編
http://mitaimon.cocolog-nifty.com/blog/2005/12/post_c417.html

どうぶつの森ってなんでこんなにおもしろいわけ?・共生編
http://mitaimon.cocolog-nifty.com/blog/2005/12/post_71b9.html

あと文中リンクされているこの開発者インタビューも色々と興味深かった。
http://www.nintendo.co.jp/nom/0511/12/index.html

渡辺聡さんも「もっと言わないといけないのはいしたにさんは凄いということかもしれない」と言っている

いい歯磨きの仕方ばかりブクマをしている場合ではないのだ。

おいでよ どうぶつの森
任天堂 (2005/11/23)
売り上げランキング: 7,477


ニンテンドーDS ピュアホワイト
任天堂 (2005/03/24)
売り上げランキング: 56

  

うーん、なんだかなぁ。

by tanabe on December 17, 2005

うーん、こいつをどう受け取ればいいのやら。困ったのでとりあえずネタにしてみる。

言及リンクのないトラックバックを受けるのはそれほどめずらしくもないのだけど、これほど堂々としたのは正直初めてだ。

うちの該当エントリはこちら。(うーん、どんな単語で検索してこのエントリを引っ掛けたんだろう。むしろそれが気になる。) http://blog.hacklife.net/archives/50014410.html#trackback

そしてトラックバック元のエントリはこちら。
http://www.fujisue.net/archives/2005/12/post_1004.html

なんと現役の民主党議員の方からのトラックバック。社会的なポジションや実名&顔を公開していることを考えると、悪意のトラックバックとも思えない。リスクを理解していたら、まともな損得勘定があればやらないだろう。

おそらくご本人が書かれているわけでもないと思うので、担当の方は「言及リンクをしないTrackBackはspamと同じ」という考え方があるのを知ってもらって、今後の方針を検討されることを薦めます。

そんなわけで、「現役民主党議員・●●がトラックバックスパム!」というセンセーショナルなタイトルも一度は考えたもののとりあえず自粛。

ちなみに、マジレスしておくと

私は、現在好調なわが国製造業をもっと強くなっていただくため、技術者/研究者と経営者の間にあるコミュニケーションの壁(例えば、使っている用語が違うなど)を無くすのが技術経営だと思っています。

従って、技術者/研究者だけでなく、現在の経営者が技術を解るように教育することも必要だと確信しています。

はどうですかね。

橋渡しをする人はある程度必要だと思いますが、むしろ経営・技術のそれぞれで有能なスペシャリストである方がチームとしては強いと思います。(製造業の技術者ではないですが。)

経営者の方は技術者なり研究者なりが言っていることの裏付けとしてまともなロジックがあるのかどうかのジャッジができれば、十分ではないかと。詳しくはこの辺参照。(よって、そのジャッジすら危ういというレベルを憂いているのであれば、同意。)

  

動的型言語と言っても in Ruby

by tanabe on December 14, 2005

ある nakagami の日記のnakagamiさんがPerl/PHP/Pythonを例に動的型付けの話を書かれていました

同じネタをRubyでなぞってみます。

5 / 2
=> 2

5.0 / 2
=> 2.5

"5" / 2
=>NoMethodError: undefined method `/' for "5":String

うーん、美しい。背景のロジックが明快なのは落ち着きますね。

一方で、5 / 2なんだから、当然2.5だろう、という算数として当然の結果が返ってくる方が親切だという気持ちも分かる気はします。ただ、私もPython/Rubyスタイルの方が好みです。

ちなみに、5は整数型を表すクラス(厳密にはFixnum)から作成されたインスタンスで、5.0はFloatを表すクラス(Float)から作成されたインスタンスです。Rubyでは演算子もクラスのメソッドとして定義されている("5 / 2"は"5./(2)"と同義)ので、「5 / 2」はあくまで整数の結果を返し、「5.0 / 2」はあくまでFloatで結果を返すわけです。

プログラミング言語の型についての話は、Rubyまつもとさんの「まつもと直伝 プログラミングのオキテ 第4回」がオススメです。

※ ちなみに -5 / 2 は -3 を返します。

  

del.icio.usをメタデータとして使ったdelimages

by tanabe on December 14, 2005

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から自分のほしいデータを抽出してくるという流れがうまく言えないけれど可能性を感じました。非常に目新しい!というわけではないですが、面白いです。

  

なんで馬鹿共は優れたテクノロジーを使おうとしないのか。

by tanabe on December 06, 2005

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

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

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

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

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

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

  

はてなムラとYahoo!サマと。

by tanabe on December 06, 2005

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

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

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

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

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

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

  

決まらない仕様には「仕様の仕様」を出そう。(あるいは要件と仕様と設計の話)

by tanabe on December 04, 2005

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

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

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

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

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

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

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

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

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

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

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

  

ふと気付くと

by tanabe on December 04, 2005

12月に入ってた。ぼんやりしているうちにここの更新を半月くらいさぼってたんだなぁ。