2009年8月 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エンジニアが元気をなくす原因

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

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

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

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

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


--------
感想

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

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

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