2009年7月 Archive

リコー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 追記
■ 豆蔵ソフト工学ラボ 超上流ビジネスモデリングの本質
これもよさげ

こんにちは。HIROSSSSSYです。

「南海ファクトリー」を作り始めて、知らぬ間に1年以上が経ってしまいました。


そもそも「南海ファクトリー」はソフトウェア開発の高効率化、開発工程ノウハウの蓄積を目的として立ち上げたのですが、ただの個人ブログになっておりました。


で、ここらで心機一転、ちゃんとしようと思いまして、個人的な活動は、別途新たにドメインを取得しました。


http://www.hirossy.asia/




asiaドメインがとってもお洒落ですね。


こちらのほうでど～でもいいような個人ブログを展開させて頂きますと。





まぁ、南海ファクトリーというのも個人的な活動なんですが、


ソフトウェア開発に関することは、南海ファクトリーにて展開させていただきます。


そして、それ以外の個人的なことや実験や遊びは新ドメインにて展開させていただきます。




全国の数名の定期読者の皆さま、今後ともどうぞよろしくお願い致します。