いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
要件は現場に聞かない
企業を取り巻く変化に柔軟に対応する基幹系を構築するためには、要件定義の段階から従来とは異なるアプローチが必要である。それは「利用部門の声を基に要件定義をしない」ことだ。 経営統合やM&A、事業の大幅な転換などを予測するのは簡単ではない。かといって、今までのように利用部門の意見だけを聞いて要件定義をしていては、現状の業務効率化を優先するばかりで、変化に対応しづらい従来型の基幹系になってしまう。 柔軟な基幹系の構築に必要なのは、企業の進む方向性や提供すべきサービスなど、将来の基幹系に必要な要件をできるだけ盛り込むことだ。経営者や企画部門、取引先、顧客など様々な声を取り入れることで可能になる（図1）。特に、社外との接点がある基幹系では、顧客ニーズや市場動向を要件に取り入れることが必須である。 実際、物流大手の山九や、「LOWRYS FARM」「GLOBAL WORK」などカジュアル衣料を手がける
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
