要求定義

2021/07/20

アジャイルプロセスの要求定義とウォーターフォールのそれ

アジャイルに対する私の認識

アジャイルプロセスでは、週、または2週単位程度で開発期間を区切り、その期間内でできる機能を高速に開発していくというのが一般的かと考えています。
その期間には、要求定義の期間も含まれると認識していますので、かなりの短期間になる認識です。
その期間内に、ユーザーが認識できる、またメリットを少しでも感じられる機能を開発する必要があるわけですから、かなり大変だろうと考えています。

たとえば、

続きを読む "アジャイルプロセスの要求定義とウォーターフォールのそれ" »

2021/06/16

システム開発会社をパートナーとみなさない発注者には気をつけよう

以前から、こうした事件は起こっているわけだが、野村證券とIBMの訴訟合戦は最高裁まで行くことになったらしい。

よくある現状踏襲

日経コンピュータの「フォーカス」というコーナーで読んだ、野村證券とIBMの訴訟合戦。
記事を拝見する限り、いわゆる「現状踏襲」に固執するあまり、要求追加と仕様変更が多発して制御不能になるパターン。
システム導入の際、現状踏襲するべき部分というのは確かにゼロではない。
ただ、それに固執するあまり、システム導入による業務改善がなされないというのは良くある話である。

 

続きを読む "システム開発会社をパートナーとみなさない発注者には気をつけよう" »

2020/02/23

要求定義工程で結ばれる「準委任契約」の変更点

Pak86_iphonetomemo20140313_tp_v要求定義工程では、通常、「準委任契約」が結ばれます。これまでの民法では「完成責任がない」履行割合型という形態でした。きちんと時間を使って働いたことが証明できれば、請求できるという契約です。

つまり、要求定義工程は「未完成のまま」終わることもできたということです。実際、要求定義という工程は「無」から「有」を作り出す部分がありますので、一体どのくらいの時間がかかるのか、完成とはなにかというのがわかりにくい工程でもあるため、準委任契約が適切とも言えます。

が、2020年4月に施行される民法改正でこの準委任契約に変更があります。

 

続きを読む "要求定義工程で結ばれる「準委任契約」の変更点" »

2020/01/26

要求定義の不備が増加傾向にあるという記事を読んだ

ちょっと半年くらい前の記事なので、半年で大きく変わっている可能性もゼロではないが、それほどは変わっていないだろうと予想する。

日経コンピュータの記事によると、1980年代に17%だった「ユーザーが要件をまとめられない」というのが、2010年代には34%の2倍になっている。また、「ベンダーが要件を理解できない」というのも1990年代には12%だったが、22%に増えている。

深刻なのは、「ユーザーが要件をまとめられない」という方であろう。

 

続きを読む "要求定義の不備が増加傾向にあるという記事を読んだ" »

2019/12/25

アジャイル開発での要求定義は爆発に注意か

ある企業の要求定義の事例を聞いてきた。その企業ではこれまでウォーターフォール型の開発をしてきたとのことだったが、はじめてアジャイル開発を取り入れて進めたらしい。

1ヶ月もしないうちに、モックアップができあがったそうで、ここまでは良かったらしい。レビューしたことで、現場からも意見がたくさん出てきたとのことだった。が、良かったのはここまでだったらしい。

 

続きを読む "アジャイル開発での要求定義は爆発に注意か" »

2019/11/25

知っていると使えるかも!要求に優先順位をつける3つの方法

システム開発の要求定義をしていると、予算を超えるような要求の数になってしまい、「これは優先順をつけないとできあがらないな」ということがよく起こります。

ユーザーがその優先順位をつけてくれるといいのですが、つけ方が分からないとか、とにかく全部やってくれと言い張るとかすることもあるので困りものです。後者の場合には、システム開発から手を引いたほうがエンジニア側としては安全な場合が多いのではないでしょうか。

もし、ユーザー側の人間なら、そこはちゃんと優先順位をつけてあげたほうがいいでしょう。これは「譲歩」することではなく、「協力」することです。なので、積極的に優先順位をつけてプロジェクトがうまくいくように進めたいところです。

 

続きを読む "知っていると使えるかも!要求に優先順位をつける3つの方法" »

2019/10/25

要求はできるだけたくさんのレベルの人に聞く

要求定義研修でよく質問されるのが、

「どの程度の範囲で要求をヒアリングしたり、掘り起こしたりすべきか」

というものです。実際、この質問は「ヒアリングを適当なところで切り上げられないか」という効率面を考えたものです。しかし、要求のヒアリングを効率面だけで判断すると、

要求が漏れることで、追加要求が発生して開発工程の後戻りが起こる

ことになります。ですから、可能なら、要求はたくさんのレベルのところから引き出す必要があります。

 

続きを読む "要求はできるだけたくさんのレベルの人に聞く" »

2019/08/25

要求をよく理解するには、実現方法ではなく、要求の理由を知ること

慣れないシステムエンジニアが要求定義、要件定義をするときに陥りがちな、ちょっとした罠について、お話したいと思います。それは、「実現方法や実装方法を考えてしまうこと」です。

 

システムエンジニアはシステムを作ることを主要な業務としているので、顧客の要求を耳にするとどうしても「動やったらできるだろう」という方向に行きがちです。ですが、要求定義、要件定義ではそれよりも大切なことがあります。

 

 

続きを読む "要求をよく理解するには、実現方法ではなく、要求の理由を知ること" »

2019/07/25

要求の大風呂敷を広げた方が「後出しじゃんけん」的要求は減る

新しい要求がどんどん出てきてしまうと、システム開発予算をオーバーしてしまうため、プロジェクトマネージャやSEの方々は要求を抑え込みがちです。それもひとつの妥当な選択であることは議論を待ちませんので、否定するつもりはまったくありません。

 

ただ、怖いのは開発が進んでいってから出される要求追加と変更です。最初からわかっていた要求を、開発が進んでから出されるのはとても困ります。できれば、そうしたことは避けたいというのも自明ではないかと思います。

 

 

続きを読む "要求の大風呂敷を広げた方が「後出しじゃんけん」的要求は減る" »

2019/06/25

要求を引き出す4つの方法には偏りがある

システム開発時に要求を引き出す方法は主に4つあります。ユーザー側から見て「受動的」か「能動的」かで区分すると、受動的なものとして、「ヒアリング・インタビュー」と「プロトタイピング」があります。能動的なものとして「ワークショップ」と「絵コンテ」があります。

 

それぞれ見てみましょう。

 

続きを読む "要求を引き出す4つの方法には偏りがある" »

より以前の記事一覧

最近のトラックバック