はじめに
当方、大したことないエンジニアですので一般論と照らし合わせると、
「そんなわけないでしょ」とか「そんなの間違ってる」等々
様々引っかかる方もいらっしゃるでしょう。
しかし、実際に現場で出くわしたものから得られるものをシェアしてこそ、
Qiitaっていいなと思うのです。
Q.システム要件定義はどうして失敗するの？
まず、ここで私の言うシステム要件定義とは、所謂基幹業務を対象としています。
つまり、業務ありきのシステムということになります。
基幹業務のシステムに関わる方ならわかって頂けるかと思いますが、
システムが業務に振り回されてデザインを損ねる、というのはよくあるパターンだと思います。
話を戻して、、システム要件定義は往々にして失敗してしまいます。
というか、私は成功した経験がまだありません。
ちょっと自分に区切りが良いタイミングだったので、どうして上手くいかなかったんだろう、
と振り返ってみたのが今回の記事です。
A.業務とシステムには大きな隔たりがあるのです。
まぁ、そうですよね。と言っても始まらないので、改善点を考えてみます。
そもそも、基幹業務の要件定義、特に大規模となると一体どこから手を付けたらいいの？
って人が大半です。
前述の通り、業務とシステムを見比べることができるものが必要です。
俺たちはコレをシステム化するんだ！という羅針盤が無ければ海難事故間違いなしです。
業務→システム化の必須アイテム
１．業務フロー
何はともあれまずはこれです。これがないと始まりません。
失敗する要件定義は、大概ここで失敗しています。
業務フローが間違っているとか、業務フローに描かれていない業務があるとか(怒)
まぁ、私が直近で対応したPJでは業務フローが存在しなかったんですが。
これでは成功しようがありませんよね。
まさに前述の羅針盤がない状態です。
２．DFD
どんな業務を通してどんなデータフローとなるのか、要件定義時に確認しないといけません。
ここで、各業務でどのようなデータパターンが存在するのか洗い出すことが、
システムテストの精度を高める大きな要因となります。
ほんとに工数が足りないとき、業務フローにデータパターンをぶら下げて、
どこに画面を用意するか、どこをバッチ処理にするのか検討してみました。
突貫でしたがなかなか効果がありました。
足りなくね？
はい、足りないです。
他にも要件定義をする上で必要な、エンジニアが用意しなければならないドキュメントは多々あります。
本記事では「まずこれ絶対必要だよね？」というものに絞っています。
まだまだ未熟者ですので、この記事を見て「もっとこういうの準備した方がいいよ」と感じられた方、
どしどしコメント頂きたいです。
実務から得られる知見に勝るものはないと思っていますので、
様々にご活躍されている方々からの意見、貴重に受け止めさせていただきます。
忘れがち、次フェーズ準備
要件定義が終わったからと言って、いきなり基本設計は始められません。
間違ってもいきなり機能単位のWBSなんて引いてはいけません。
基本設計では何を成果物とするのか？どこまで書くの？
全体のジョブネット誰が作るんだ？
いやいや、まずは画面とバッチ一覧だ！
とか、基本設計の出だしで大紛糾してしまいます。
結局、何が必要なの？
IPA等も参考にして、準備すればいいです。
ただ、世の中にはその全てのドキュメントを用意する工数がない、
また業務そのものがとても複雑で整理そのものに工数/期間が掛かるものがあります。
実際、私がそんな状況で一体何をミニマムマストとして仕事を進めればよいのか、
非常に困ってしまいました。
今振り返ってみて、今回は本当に最低限、絶対いるよ！という事象に絞りました。
基本設計では？
基本設計のお話はまた別の機会として、今回の記事では要件定義に関わる部分を記載してみました。
拙いですが、また基本設計の巻を書いてみます。