IT / システム部門の方とお話をするのですが、苦労が絶えないのは相変わらず要件定義のようです。開発になるとパソコンに向かうことが多くなるので技術者という感じですが、要件定義は対人業務です。ストレス解消法も良く話題になります・・
要件定義には、コミュニケーション能力とドキュメンテーション能力（とストレス耐性）が求められます。業務要件を言われた通りに丸写しすればいいというものではなく、システム化、シンプル化のインタラクティブな現場対応が必要です。コンピュータは賢くありません。だからといって闇雲に要望を切り捨てたら使えないシステムになります。実現性、工数などを勘案して、賢くないコンピュータを不便でない程度にブラッシュアップして、費用対効果に見合うようにするのですが、実は要件定義で大方結果が出てしまいます。*
設計フェーズで見直すという考え方もあるのですが、予算が決まっている以上、要件を膨らます訳にはいかないのです。要件精査でもたついたら設計フェーズの時間が削られてしまいますし、そもそも忙しい業務の合間をぬって検討会に参加してもらった業務部門のキーメンバーとの関係にひびが入るなど、デメリットばかりです。
すべては無理にしても要件検討会のその場その場で問題処理をしてしまわないと時間切れになります。データもあいまいでは困るので定義を明らかにしていきます。データ間の依存関係、上下関係も大事です。幹をクリアにしないと例外要件なんかまず出てきません。
プロジェクトは要件定義開始2週間が勝負です。最初の2週間でセッションをリードできれば要件定義をスケジュール通りに進めることが出来ます。失敗するプロジェクトは、要件定義が終わっていないのに時間切れで次のフェーズに進めている場合が多いです。設計フェーズで吸収しよう、ということですが、設計フェーズの方が投入工数は増えるので進捗の遅れのインパクトが大きくなります（工事進行基準廃止！）。要件定義が終了しているモジュールから五月雨式に設計に入ろう、としますが、データモデルを共有している以上、影響が伝播します。結局、設計修正、手戻りが発生し二重コストになります。データモデルが確立していない段階でのアジャイル開発が失敗するのはこの点にあります。MVC ( Model, View, Controler ) のModelについてはウォータフォールに利があります。データモデルを精査するためにはユースケース（システム利用、操作仕様）の理解が必要で、業務シーンではその重要なインプットの一つに業務フロー（業務フロー）があります。
業務フロー図にやり取りされるデータは定義されているでしょうか？失敗しない要件定義の分かりやすい Howto を一つアドバイスさせて頂くとしたら、
業務フロー上のデータを精査
することです。あまりうるさく言われていないようですが、成功のカギの一つです。
大変かもしれませんが、必ず報われる苦労ですので。是非一度レビューしてみて下さい。
永島志津夫
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します
* 顧客サービスですから、ここをうまくお話ししないと仕事が終わってしまいます。状況をフェアに説明し理解を得て、妥協点に落ち着かせる交渉事でもあります。
