[要求開発] 連載1「要求開発とは何か？」をよむ

とりあえず順番に読んでみることにすることにすることにすることにする。


■ ThinkIT 要求をシステム開発に正しく反映させるには

まず手始めに ThinkIT の 要求をシステム開発に正しく反映させるには という連載を読む。

以下読んだ時のメモっす

-----

連載第1回は「要求開発とは何か？」

著者はウルシステムズの河野さんという人。2006年の記事。
ウルシステムズって「売るシステム」って意味かな？っていう勝手な妄想。


とりあえず順番に読む


■要求開発とは

要求開発とはその名の通り、クライアントの「要求」を「開発」することを意味します。
中略
間違ったものをいくら正しく作っても、完成したものが役に立たないのはある意味当たり前なのです。中略
その問題を根本的に解決しようと思ったら、最初の時点で要求を正しく把握する。

著者自身の経験から、最初のインプットが間違っているといくら制作の段階で頑張ってもお客様には満足してもらえないことを認識。
また、開発の生産性は大きく向上しているのに、顧客満足度は昔と比べて大して向上していない。

技術者が技術を磨いても、知恵を絞っても、また、よりよい開発方法論を議論しても、要求を正しく理解できなければすべてがムダになり、お客さんは満足してくんない。怖い。


■原因は何か

で、昔から上記の問題点は指摘されていた。
でもなかなか改善されない。それはなぜか？について「企業経営の要素」という図を用いて解説。

企業経営において、まず頂点に「ビジョン」というものがある。
その次にビジョンを達成するための「戦略」がある。
戦略を実現するために「業務(オペレーション)」がある。
そのオペレーションを支えるのが「ITシステム」。

で、システム開発が失敗する原因は2つある

1) そもそもきちんと「戦略」にそって「業務」のオペレーションをできている企業というのが、実はそれほど多くない
2) システム開発側の技術が未熟

ところで「要求定義」「要件定義」ではなく、「要求開発」という言葉を使うのは、
前者では、お客さん側で要求が既に正しく明確であることが前提であるかのようなニュアンスである
後者では、「開発」という言葉を用いて、要求をお客さんとSIERが一緒に考えようというニュアンスがある

要求開発のルーツは、ビジネスモデリングであり、モデリングの品質を向上させる過程で産まれたもの


■なぜ今まで要求開発をしてこなかったか？

SIベンダーというのは、「顧客からでてきた要件定義に対して請け負う」というスタイルでこれまでやってきたように思います。だから、お客様と一緒に要求を正しくしていこうという発想になりづらいのです。

システム開発の契約形態や商習慣が要求開発を行う風土ではなかった
お客さん側の意識変革も必要。

クライアントとベンダーがお互いを信頼して「一緒に良いシステムを作っていこう」という関係にならないと、要求開発を実行するのはなかなか難しいと思います。

社長から「在庫を半分に削減しろ」というミッションが来た場合の例を挙げる。
多くの開発者は、「業務的な問題だからシステムには関係ない」とスルーしがちであるが、
在庫を半減させるためにシステムが担う役割を考えることが本来のあるべき姿である。

要求開発方法論(Openthology)という図が登場。
一番大事なのは「ビジネス価値」「ビジネス要求」「システム要求」の3つの要求。
「システム要求」の上位目的として「ビジネス要求」がある。さらにその上位に「ビジネス価値」がある。
これらは階層構造として考える。
これらは企業経営の要素三角形ともリンクしている。（戦略はビジネス価値をあらわす）
ビジネス価値とは、「在庫を半減させる」「納期を半分にする」など

-----


ここまで。
ここからは感想。


言ってることはよくわかりました。

開発の目的を明確にすることは要件定義をやるうえでの重要なポイントだし。
要求開発の場合は、開発の目的自体がそもそもクライアントの戦略に沿ったものかというチェックまでするわけですね。

システム開発に限らず、Webサイト制作でも、アプリ制作でも通用するね。

てかこういう考え方はすでに採用してるよね。gd社。

気になったのは、
・要求開発フェーズって幅広いけど、受注前にやることと受注後にやることを混同しないようにしないといけないなと。いや、要求開発って、実際の制作とは別にお金をもらうんだろうかね？もらえるの？？
・数百万円規模の開発に適用するには、ポイントだけを押さえた簡略形式の方法論が必要になりそう。


以上