Scalaのクラス定義がコンストラクターと一体になっている構文にとまどった方も多い（多くはいないかな？）のではないでしょうか。 私も最初何故このような構文なのかが分かりませんでした。でも最近このconstructorが関数プログラミングとオブジェクト指向の…

私がScalaを使い始めて「何でかな〜」と奇異に感じるScalaの構文がいくつかあります。 しかし使い込んでいるうちになるほどね〜〜と感心するものも多くあります。今回から何回かに分けてそのような構文をご紹介したいと思います。 （解釈は私の独断と偏見が…

このケースはパッケージベンダーなどをイメージしているが、一番一般化して語るのが難しいものである。ここでの想定は要件定義者とその開発者が同じ会社であるという想定で述べる。この場合要件定義者と開発者の間には契約関係が存在しないので要件定義とし…

システムを開発する側の立場に立つと二つの側面が要件定義書に求められる。 ・見積もり可能な情報があること ・実現する機能範囲が明確になること■見積もり可能な情報があること 見積もりを作成するにあたっては戦略的な価格設定、もしくは内部工数を積み上…

A.システム開発を発注する立場（ユーザ企業など）この場合システム開発を発注する立場から、見積もり可能な内容が記述されたものがユーザ企業にとっての要件定義と考えることができる。これは正式な発注まではユーザ企業主導の要件定義で、SIerなどのシステ…

先(http://d.hatena.ne.jp/good_way/20080221/1203601549)に見てきたように要件定義は様々な目的で使われる。その各々のプロジェクトにおいて最適な要件定義となるためには次のような考え方がある。「要件定義書をもとに要件を説明でき、聞き手がそれを理解…

ある人に初音ミクというのを教えてもらった。 音楽関係にはとんと縁が無いが、このソフトを作ったクリプトンフューチャーメディア(http://www.crypton.co.jp/)の伊藤さんとは１０年くらい前に一度仕事をしたことがあり、面識があった。そこが開発したソフト…

要件定義は大きく分けて３つの立場から使われる。 A.システム開発を発注する立場 大手ユーザ企業など B.システム開発を受注する立場 SIerなど C.上記両方の立場を併せ持つ パッケージベンダーなどこの３社の各々の立場で要件定義の内容は微妙に変わる。（A）…

昨年の夏からコツコツとまとめていた要件分析の資料「リレーションシップ駆動要件分析」がまとまった。また、それに合わせて専用サイト（http://www.rdra.jpn.org）も準備ができた。モデルを使った要件定義に興味のある方は是非一度目を通して頂けると幸いで…

通常システム開発後のドキュメントと言えば設計書が一般的ですが、その設計書はキングファイル数冊分になるのが普通です。それはそれで保守の時に使用できますが、大手ユーザ企業のシステム部門は、実際に保守作業を自分たちで行うことはまれで、それらの設…

ユーザ企業のシステム部門の役割はその会社のビジネスをＩＴの技術を使って支援することです。 もしくはもっと積極的にＩＴを使ってビジネスを成功させることです。 ユーザ部門と一緒にビジネスにＩＴをどのように使用するか検討する必要があります。 ユーザ…

大手のユーザ企業の場合は継続的にシステム開発案件があります。そして、システム部門はシステム保守や開発などの現場作業は、パートナー会社に委ねているのが一般的です。そのようなシステム部門においては、稼働しているソフトウェアだけではなく、要件定…

要件定義フェーズの成果物はそのままSIベンダーへの見積もり用の資料(RFPなど)になるのが普通です。 このことがまた要件定義の混乱のもとになります。発注者としてのユーザ企業の立場では予算取りがあるので「システム開発費を全額決めてしまいたい」という…

大手ユーザ企業での要件定義は、通常従来その会社が独自に行っていた方式を踏襲するか、もしくは担当者の経験の範囲で独自の方式で行っているのが普通だと思います。また、ユーザ企業のシステム部門で要件定義が難しい場合はSIベンダーがその要件定義から参…

要件定義をスムーズに進めるためにはいくつかの視点が必要がある。上流工程の作業というものは明確な達成点が無いことから、どうしてもスケジュールが延びてしまうことや、成果物の品質が担当者によってばらばらになってしまう傾向がある。これらをうまくコ…

要件定義においてAs-ISとToBeの資料がごちゃ混ぜになっているケースを多く見かける。現状調査などで業務フローをつくりそれをベースに新システムを考えることが多いが、そのAs-Isとして作製した業務フローがいつしかTo-Beの業務フローとして認識されてしまう…

システム開発の上流工程において、よく以下のようなことが強調されている。 ・ゴールを明確にすることが大事だ。 ・システムのビジネス価値を明確にする必要がある。これは私もコンサルティングの場でよく口にするが、本当に重要なことはどこまでそれを突き…