著作一覧 |
技評の細谷さんからいただいた(ありがとうございます)羽生さんの『はじめよう! 要件定義』を読んだ。
これは良い。広い範囲でお勧めする。
何が良いかと言うと3点はある。
1) ほぼ誰でもわかる(読める)実用的な本だ。
世の中には2種類の実用的な本がある。1つはアカデミック寄りな本で、もう1つは実社会向きの本だ。たとえば「関数型プログラミング-数学から実学へ」とあれば前者で、「明日から仕事に使えるちょろいぜHaskel!」なら後者だ。で、Excelの使い方やメールの書き方や歩き方については普通後者しかなく(前者があってもろくなものではなさそうな気がする)、関数型プログラミングやビジネスモデリングなら前者しかない(後者があったとしても役に立たなさそうだ)。
でも、本当は逆で、どうでも良いことこそきちんと理屈立てて容易に使いたいし、理屈立ったものは安全なのではしょりにはしょった学習方法で誰でも使えるようにするべきだ。
この本は、要件定義という実社会の要請があることに対して後者に近いかたちで書かれている(かわいいイラストが効果的だ)。なんというか、15000円の書籍を読み120万円のトレーニングを受けて客先に出ていくような内容を、はじめよう! というノリの2000円を切った(税込だと知らない)本で必要十分以上に学べる。
学べることは「なんのために」の理解と、「何をするべきか」の知識と、「どうやるか、どの順番か」の段取りの組み方だ。深入りしそうになると、参考書を読めで終わるが、それで良いと思う。
2) 練られている
とにかく読んでいて、手順と各手順で何をやるか、その目的は何か、何が出力されるかに強い説得力がある。
良いことが書いてあっても「この通りにできるなら話が早いけど……」、みたいな本もいろいろあるが、1)からこの本は理解が容易なので、できないほうがむしろおかしいと思う。
一番良いのは、受注側は最低でもこの本の内容を叩き込んでから、要件定義に入る前に発注者側に対してこの本を教科書にした3日から長くても1週間くらいの事前レクチャーを行ってから作業を始めることだろう(プロジェクト参加者全員による読書会みたいな形式が良さそうな予感)。
とくに読んでいて、ああーなるほど! と感服したのは、最後の要件定義後のラップアップフェーズの章で、過去のあるプロジェクトを思い出して反省した。
3) 短い
1)とも関るが、たかだか180ページ弱、イラスト多数、字は大き目、往復1.5時間くらいの電車の中で3日かからずに読み終わった。でも内容が薄いわけではない。端的な説明で、要件定義という作業全体の進行方法が練られているから、これで十分なのだろう(もっと食わせろと感じるところはあるが、足りない!と感じるところはほとんど無いし、そう感じるのは完璧主義の罠にハマっているだけかもしれない)。
読み始めて、面倒くさくなって途中で読むのをやめるというのを最悪とするならば、この短さは、最善のための重要なファクターとなっている。
----------------------------
読んでいて、うむ! と思った点:
データベースをプロセスに挟むことで、中抜きが実現できて、それが効率化だという指摘(P.85)
導出ルールを明示すること(P.116)。いや、まったくその通り。これは忘れてあとで痛い目に合うので、強調してあるのは実に良い。
統一は後回し。フレームワークの第一歩は3つの事例というのがあるけど(この本関係ない)、3つは作ってから共通化/統一については考えろというのは、本当に正しい。絶対に予見はできないし、すべきではない(強度が脆弱なものが共通基盤となると、間違いなく砂上に楼閣を作ることになる)。本当にその通り(P.120)。
ないがあるの検証(P.150)。正しい。本当に正しい。困っちゃうくらいに正しくて、困ることがしばしばある。
ロールごとにワークセット(本書の用語だけど、メインフレームでのジョブに近いかな)を別にするほうが、ワークセット内でロールによって分岐するより良い(P.156)。なんか正しいように感じる。これと上の3つ作ってから共通化というのは同じ問題を扱っているようだ。
要件定義の成果発表用想定問答集(P.162)。うむ、素晴らしい。
----------------------------
とはいえ、さすがに短すぎたり端折り過ぎたり、なんじゃこりゃ?という点もあった。
P.55 サンプルをいくつか作ったので眺めろと書いてあるが2つしかない。もう少し欲しい。
P.61 この時点でセキュリティ計画を入れておかないとまずい(が、そういうレベルのシステムが想定されているのではないかも知れない)。
P.114 シノニムとホモニムの図解が逆のような。
・他の本を読めというのは、薄さのためには良いことだし、具体的な書名を出さないのもそれはそれで良いと思うのだが、ERD入門だけは具体的な書名が出てくるところが(羽生さんが自信をもって進められる「他の本」だということはあるかも知れないけど)ちょっと我田引水だなと感じた。
---------------------------
きちんと分析手法を学んだ人であっても、普通の顧客に理解できるようにするという点で、そうでなければ確実に、この本は参考になると僕は思う。お勧めです。
ジェズイットを見習え |
ご無沙汰しておりますです。面白そうなので読んでみます。おまけですが、文脈からみると、s/深掘りがされているという意味でもない/深掘りがされていないという意味でもない/、なのかなと思いました。
お久しぶりです! 食い足りないとこもあるなぁという意味を含めているので/の左ではあるんですよ。とは言え、そこが良さなんですよね。
書き直してみました。どうもありがとうございます!
これはおもしろそうな本ですね。買ってみます。読んでみます。<br><br>>フレームワークの第一歩は3つの事例というのがあるけど<br>マーチンファウラー氏もいってましたね。<br>http://capsctrl.que.jp/kdmsnr/wiki/bliki/?HarvestedFramework
ご感想ありがとうございます(^^)<br><br>こちらが気にしてる箇所をズバリ撃ちぬかれて感服&オソロシヤですw<br><br>シノニムとホモニムの件、ご指摘のとおりです(T_T) 手元に情けないケアレスミスの痕跡がががorz<br>増刷が叶った折には修正します。<br>P.61のセキュリティ計画もおっしゃるとおりなんですが、モヒカン怖くて端折りました(^^;<br>サンプル2つになったのは、大人の事情、とさせてください。この件、実は色々とあるのですが、本文を合わせて修正しておけば良かったなぁと思っております。<br><br>我田引水は、、、スミマセン、拙著、売れてないものですから(^^;;<br><br>ともあれ、本当にありがとうございますm(_ _)m<br>今後ともよろしくお願いいたします。
いえいえ、良い本を頂けてうれしいです。まさに一気読みです。それにしても、ERD入門が売れてないって、いくらRDBが流行ではない(でも基本中の基本ですよね)といっても、それはもったいないなぁ。本書だって形を変えたDOAによるシステム構築(だと僕は解釈したけど)だし、どう転んでもデータ抜きにシステムはあり得ないのになぁ(とERD入門が売れていないということに憤りを感じたりして)。
msさん、良い本ですよ! フレームワークの3つの事例は http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/evolve.html ですね(おそらくマーティンファウラーもこれを読んだのではないかなぁ)。
artonさん。買いました、読みました、良い本でした!<br><br>3つの事例は、この記事が元ネタなのですね。と著者をみてRalph Johnsonですか。<br>教えていただきありがとうございます。