要求開発 Archive

お盆休みを挟んで、再開することにすることにする。
最初は１ヶ月ぐらいで完結させたかったんだけど、要求開発って習得にすんごく長い期間がいるんだろうなと思い始めた。

まあ、まだどなたかの公開資料を読んでログをとってるだけなので、地道に進めていくとする。


リコーITソリューションズ株式会社さんの技術資料、「要求開発超入門」を読んでいる。
以下は読んだログ。

要求開発方法論オーバービュー

• 要求開発方法論について

要求開発方法論は、バージョン0.6と1.0がある。
要求開発方法論は、要求開発を実践する人が見るガイドライン。
やり方、考え方、手順が書かれている。

• 要求開発方法論の構成要素

1．モデル
見える化を行うための道具。
モデルは業務フローやユースケース図などの図で表される
2．プロセス
手順と目的。
「準備フェーズ」「立案フェーズ」「デザインフェーズ」「シフトフェーズ」がある。

• 要求開発方法論のストラクチャ

1．モデル・ストラクチャ
モデルを書く際にモデルをどのような視点で描くかという視点(ビュー)の分類構造を示す。
「戦略ビュー」「サービスビュー」「プロセスビュー」「情報ビュー」がある。
戦略ビュー
ビジネス戦略やIT戦略の見える化を行いこたつモデルの中で合意を得る。
プロジェクトを企画してプロジェクト戦略を立てるためのビュー。
BSC戦略マップやゴール記述書で表される。

サービスビュー
プロジェクトで業務改革・改善やシステム開発を行うための対象をサービスという観点で切り出す。プロジェクトで取り扱うドメインの全体を把握するためのビュー。
ビジネスユースケース図、システムユースケース図で表す。

プロセスビュー
サービスビューとして切り出された業務改革・改善やシステム開発を行うための業務対象が
どのような手順で進めていくかを示す。業務フロー図として表す。

情報ビュー
サービスビューとして切り出された、業務改革・改善やシステム開発を行うための業務対象の中に存在する重要な概念用語の関係を概念モデルとしてかく。
用語の統一化。普遍的な業務構造が理解できる。


2．プロセス・ストラクチャ
プロセスの全体構造を示した概念的な図。
横軸をフェーズ、縦軸をPDCAとしたマトリクスを作成し、マス組み一つ一つの箱の中にアクティビティが用意されている。
これをプロセスキャビネットと呼んでいる。

プロセスキャビネットの中身についての挿絵が入る。


ここまで

リコーITソリューションズ株式会社様の記事
要求開発超入門Volume6  要求開発とは何か

を読んでみては、ここにポイントを吐き出してるっす

-----

要求は在るものではなく、開発するものである

ビジネスの視点でシステムの要求を捉える必要がある。
そのために必要とされる考え方が要求開発である。

要求開発では、「要求は在るものではなく、開発するものである」と唱えられる
要求開発は「要求開発アライアンス」という団体によって考え方が提唱されている


要求開発

ここまでに話した以下のようなビジネスの中でITを活用する際に生じる問題を解決するために考えだされた。

vol.1 ビジネスの視点でIT企画・開発を行っていない
vol.2 要求はユーザーが持っているという勘違い
vol.3 業務の見える化手法とプロセスが未成熟
vol.4 ビジネスとITがキレてしまっている
vol.5 エンジニアリングがビジネスの価値を向上させていない

米国Standishグループの調査では、システムに作り込んだ機能のうち、
結果として利用されているのは36%である。
全体の3分の2が役に立っていない。

要求開発はシステム企画の段階からRFPの作成まで、一貫して「目的と手段の連鎖」を"見える化"していくプロセスである。


要求開発アライアンスの活動

要求開発アライアンスは、要求開発の開発と普及を行う非営利団体である。


要求開発宣言

要求開発宣言とは、要求開発という考え方を実施していく際にもっとも大切にしている考えを宣言としてまとめたもの。


[要求開発宣言の図]


要求開発の活動

要求開発は、システム開発の前段階において、ビジネス戦略やビジネスプロセスの企画の見える化を行いながら、IT要求に落とし込んでいくという活動をいう。


要求開発方法論

要求開発を学習、実践する人たちに向けて開発した方法論。
別名Openthology


コタツモデル

コタツモデルとは、みんながコタツに入って、次のビジネスを話し合い、そこに必要とされるビジネスの要求やシステムの要求を考えていきましょうという象徴。

コタツモデルは要求開発においては、もっとも大切にしたい考えなのです。

-----


vol.6にしてやっと「要求開発とは何か？」という話に。
そして後半は、「要求開発アライアンス」という団体の勧誘的な内容www

要求開発は、どうやら「要求開発アライアンス」という団体が編み出した考え方と方法論のセットなんですね。んで、もっとも大切なのは、コタツモデルを構築することだと。
ほう。

リコーITソシューションズ様の技術情報を読んでいます。
それは要求開発について考えるための予備知識をつけているからなのさっ。


今日Vol.5 元気のないエンジニア

以下ログ

ITエンジニアの元気がなくなった

理由の一部に「ユーザーから評価されない」とか「エンジニアリングを学んでもソフトウェア開発に自信が持てない」といった話がある。


技術・人・心を強くする

技術、人（コミュニケーション）、心（やりがい、気づき、情熱）の3つをバランスさせる。
この3つはそれぞれ多くの問題や課題があり、改善・向上させる必要がある
ここでは「技術」にフォーカスして話を進める


ITエンジニアが元気をなくす原因

納得感のないソフトウェアエンジニアリング

現在の開発方法が未熟なために、設計コストが開発コストに含まれていなかったり、開発者の勉強の時間は計算されていない。そりゃ納得いかない。

「正しくない要求を正しく作る」→ モチベーションガタ落ち
開発ルールが形骸化しすぎる→なんのためにやっている作業なのかが分からなくなり、思考停止

ユーザーの価値をもたらすための開発のあり方を、要求開発をきっかけにみんなで議論し、開発ルールもかえていくことが必要。エンジニアの自信を取り戻す過程では、気づきや、仕事に対する情熱も与える必要有り。それはそれぞれの心を強くするということ。

元気がなければクリエイティブな仕事などできるはずがない。


--------
感想

元気があれば、なんでもできる。
お客さんに満足してもらって充実感を得る。すばらしい。
これは要求開発に限った話ではないですね。

「正しくないものを正しくつくる」という悲しい話にならないように
きちんと要求開発しよう。そしてその後の開発プロセスもみんなで議論しよう。と。

何も知らない後輩に対して、「いろいろ失敗してここに至っているんだ」というのをどう伝えるのか？という問題もありますね。これ。そんなに簡単な話じゃないぞ。。

リコーITソリューションズ株式会社さまの技術情報を読んでいる。
読んだログをここに吐き出している。
後に整理する。たぶん。


ビジネス価値を創出できないシステム


コンピューターシステムはビジネス価値を高めるものである


システム開発者は牢屋に閉じこもる

システム開発者は「システム開発」というみえない枠に収まり、そこの中にとどまって、「要求クレー」と叫んでいる。だから要求に対する提案が開発側からは的確に出ない。と思われる。


ビジネス価値を高めるようなITが作れない原因

[図が入る]

図は要求開発の全体像を説明するもの。

図の上段はビジネス（ビジネス戦略とビジネスオペレーション）
図の下段はシステム（システム要求とシステム設計）
下段のシステム要求の根拠(What)は、上段のビジネス側に存在する。
システム開発者が下段に留まり、上段をみないのであれば失敗する。
全体をみること。


ビジネスを戦場に戦う

システム化した後の結果イメージがもっと早い段階で予測できればそれに対する変更やチューニングが容易になるのです。
最近のビジネスでは、ITによりビジネス価値が拡大することが多くあります。そのほとんどの現象として、目的自体（要求）が価値を持つのではなく、目的（要求）の手段（IT化方式）によって価値が決まることが多いのです。また、手段のチューニングこそが価値をもたらしていると僕は思っています。

手段のチューニングによってビジネス価値は高まる。


-----


おー。最後いいですね。響きました。今まで読んだ記事の中で一番良い文章！
まとめるとこんな感じですね

• システム化した後の結果イメージを早い段階で予測できるようにする
• それによって手段のチューニングが容易になる
• 手段のチューニングによってビジネス価値が高まる

前半の話はなかなか難しいところがある。
お客さんのビジネスに首を突っ込めということだから。首の突っ込み方を間違えると、すごく良くないことが起こる気がするな。。。
首の突っ込み方は、ちょくちょく出てきたOpenthologyなんだろうかね。
まだまだ予備知識足りないね。

昨日からの続きで、リコーITソリューションズ株式会社さまの情報を元に、「要求開発」についての予備知識をお勉強中。
いつか自分の仕事にも落とし込みたい。とは思っていないくもない。

いまここをよんでいる

-----
以下読んだログ

最近は業務の "見える化" が流行している

システム開発を行う前に、業務を見える(分かる)ようにして、その中で必要な箇所をIT化していく取り組みのことであるが、同時に業務を理解し、問題課題を解決するためにも非常によいこと。

でも、見える化はうまくいかないことが多い

失敗例(1) 業務の非 "見える化"

業務の "見える化" を行わずに進めてしまうこと
要求を、点ではなく面で捉えること。

失敗例(2) ASIS業務を "見える化" しているだけ

ASIS業務(現状の業務)を "見える化" し、それを元にシステム要求を出してしまった。
これは、プロジェクトのゴールを見極め、みんなで共有してから業務フローを書くべし！書くべし！



先の見えない業務の "見える化"
業務フローを書く際に、その範囲と作業量を誤って、膨大な業務フローを書いたが管理／活用できなくてごみになる。
これは、戦略をたてるべし。小さく始めて、一通りプロジェクトを進める。サイクルを回す。そして展開する。そういった戦略が必要。

絵に描いた餅
ToBe(新規業務)として業務フローを書いたが、非現実的になった。
ToBe業務の見える化は、覚悟するためにある。覚悟できない見えるかは無駄。


ここまで
-------


おもしろいね
続きはまた明日よむと思う

リコーITソリューションズ株式会社さまの技術情報ページ

要求開発超入門 を読んで要求開発は何なのかを探ってみる。

「我々は元気の出るプロジェクトを始めました」と書いてある。楽しみ。

volume 2 は、「うまくいかない要求定義」だそうだ


-----
以下内容の要約

なぜ、要求定義はうまくいかないのか？

契約的問題
ウォーターフォール開発では、ソフトウェア開発の最初の段階で(１ヶ月などの期間を切って、ユーザーにシステム要求を提示してもらい、開発会社がそれを元にシステム要求仕様を提示する。その時に受注金額が決まる。あらかじめ開発予算が決まっているときも多々あるので、発注側と受注側で要求を受ける・受けないという交渉が行われる。
このやり方には問題があり(図示)、ITシステムのビジネス上での活用方法がわからないのに、要求を出さないと損だとばかりに、無理やり要求を出してしまう。結果、半分も「使われない機能」ができあがってしまう。
ユーザーがしっかり要求を持っている訳ではない。ユーザーは業務をどのように行っているかは知っていても、ITを使ってどのように効率化するか？や新しい価値を生み出す方法はわからない。
システム開発側も、ユーザーの業務上の問題や課題が完全にわかる訳ではない。


要求の定義と要求の評価では見ているところが違う

[4コマ漫画が入る]
ユーザー：お魚を食べたい（収穫したい）
ユーザー：お金がかからない方法で、木と糸と針金を使って・・・
開発者：数日後に釣り竿を作って持ってくる
ユーザー：僕の要求とちがう〜！網がよかったのに〜

[別の図が入る]

要求を定義する段階では、「木と糸と針金をつかってお魚を穫る」だったのが、
要求を評価する段階では、「網でお魚を穫る」になっている。

これらからわかることは
本来ならば要求とは、手段が連鎖した全体的な系列を理解しなければならないということ。
ユーザーは、最初の段階では、網のイメージをはっきりと説明できなかった。
また、開発者も釣竿を考えたのだが、針金で針を作ってしまったり、浮きもない竿でどうやってつればいいかも分からないまま開発に着手した。
もっと最初から、結果イメージが予測できていればこういうことになりにくいはずである。


volume3につづく
-----


感想
そうですね。其のとおりですね。
次回どうなるのか〜

リコーITソリューションズ株式会社さまの技術情報ページ

要求開発超入門 を読んで要求開発は何なのかを探ってみる。
「我々は元気の出るプロジェクトを始めました」と書いてあるし、楽しみ。


volume 1 は、「失敗するシステム開発」だそうだ

-----
以下内容の要約(メモ)

ソフトウェアシステムはなぜ失敗する？

原因は次のようなものがある
・システムの要求があいまい
・システム化がなぜ必要か明確に定義されていない
・業務を理解せず開発を始めた
・開発の期間と予算不足
・しっかり設計されていない
・設計期間を十分にとったのに、設計が役に立たなかった
・テスト不十分
・長期間の開発中にユーザーの要求が変わってしまった
・完成したがユーザーが望んでいるものではなかった

なぜこのような問題がシステム開発の前段階で起こったのか？

[ビジネス(木)とシステム(木の実)の図示]

ビジネスが木ならば、コンピューターシステムは木の実。
なのでビジネスで、いつ、誰が、何を、誰に、どのようにしてサービスを提供することで
何らかの付加価値をもたらそうとしているのかをデザインする必要があり、コンピューターシステムとしてその一部を要件定義し設計する。

最近では、コンピューターシステム開発のノウハウが徐々に洗練されつつある。
しかし、ビジネスのデザインについてはまだ洗練されていない。

volume2につづく

-----

感想

昨日までによんだ記事もそうだけど、要求開発って、システム開発が失敗するという前提で話を進めることが多いね。まあ、続きは明日よもう

要求開発の勉強をしています。今は予備知識を勉強中でして、メモ代わりに書いています。
このポストは これ を読んでメモと感想を書いています。

じゃ前回の続き


■プロジェクトの初陣を乗り切る

現場力を獲得するための4つのポイントの2番目。
どんなプロジェクトでも立ち上げ当初は混沌とする。

要求開発も関係者の利害がそれぞれ異なっているという不安定な状態から始まる。

そういった状態からいちはやく脱出し、チームがPDCAサイクルをきちんと回し始めるようにマネジメントすることが大切。

■要求開発を失敗させる2つの病気

一つ目は「情報過多症」
プロジェクトの初期段階では、とにかく多くの情報を関係者から引き出すので、大量の情報に圧倒されてうまく整理できず、身動きがとれなくなる。

二つ目は「情報認知不全」
重要な要求をチームが見落としてしまう。発見が難しく、ずっと後になってから問題が発覚するので、タチが悪い。

■プロジェクトの全体像を共有する

それらの病気を予防,早期発見&治療 し、プロジェクトの初陣を乗り越えるにはどうすれば？
それは「プロジェクトの全体像を共有する」ことで解決させよう。

「カオスから秩序を作るために」の図が入る。

プロジェクトの全体像を共有し、以下のポイントを押さえよう

1.プロジェクトの目的とゴールを明確にする
2.プロジェクトのプロセスをチームメンバーに十分に理解してもらう
3.プロジェクトにおいて各人に期待する役割を、期間中、個別にきちんと伝え続けること
4.プロジェクトのマイルストーンを設定し、必ず達成するという強い意志を持つこと
5.プロジェクトの優先事項を先に決めておき、意思決定の判断材料として用いること
6.対象業務のコンテキスト(業務の全体像)を把握。開発のスコープを決めること


ここまで。
今回は感想なし。

要求開発の予備知識勉強中。

前回の続きをよむ


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


以下読んだログ。


■方法論に魂を入れる

「要求開発」というコンセプトを実現して、お客様にとって本当に価値のあるシステムを構築するためには、それを実行できるだけの能力を現場が獲得することが不可欠です。この現場力の獲得のことを筆者は「方法論に魂を入れる」と呼んでいます。

ほう。実践して自分のものにしろということか。


■プロジェクトを成功させる2つの要素

1つめ：ゴールに至るまでのシナリオを入念に練り上げること

ゴールに至るまでの道のりを開発関係者全員で明確化し、共有することが大事。
質の高いシナリオ(道のり)を作るために「方法論」を活用する。


2つめ：シナリオを確実に実行できる力をもつこと

シナリオをいかに実行するのか？ここが一番難しい。


■現場力を獲得するための4つのポイント

1. 要求開発チームのコア能力を鍛える
　　　コア能力1) ロジカルシンキング能力
　　　コア能力2) 本質をつかみとって可視化する能力
　　　コア能力3) ファシリテーション能力
　　　PDCAサイクルをきちんと回す

2. プロジェクトの初動を乗り切る
3. 顧客の業務をよく理解する
4. 優先順位付けと短時間のフィードバック

計画を達成させるPDCAループとは別で、もう一つのループが必要
もう一つのループとは、「Problem finding（問題発見）」→「Display（可視化）」→「Clear（問題解決）」→「Acknowledge（確認）」。

このループをPDCAサイクルのD（Do）の段階で実施し、ダブルループを形成させる



以上ここまで


ここから感想

この記事はつまんないなー。って書くと筆者さんに失礼ですね。

要求開発を実際に行う方法やポイントについての記述ではなく、「いかにうまく進めるか？」という進行上のポイントについての記述だったのが個人的に残念。
せっかくなので第三回も読むけど。。

筆者の言う「魂を入れる」ことが大事というのは、とてもよくわかる。
プロジェクトを成功に導くのは、最終的には「やり抜く根性」が必須になるのはとても共感しました。


あい。以上。

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


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

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

以下読んだ時のメモっす

-----

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

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


とりあえず順番に読む


■要求開発とは

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

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

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


■原因は何か

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

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

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

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

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

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


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

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

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

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

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

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

-----


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


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

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

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

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

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


以上

システム開発における各工程について、もう一度見つめ直してみるとする。
なにかが見えてくるかも。なにも見えてこないかも。



というわけでまずは要求開発。要件定義という言葉でもいいと思う。



このあたりが参考になりそう

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


■ リコーITソリューションズ 要求開発超入門


■ 豆蔵 要求開発


■ ITPro ビジネス・モデリング道場
要求開発アンチパターン



■ 要求開発アライアンス


とりあえず全部読んでみよう。それからどうするか考える。


2009.07.24 追記
■ 豆蔵ソフト工学ラボ 超上流ビジネスモデリングの本質
これもよさげ