要件定義が難しい理由
・隠れていた事実を明らかにするだけではなく、ステークホルダーの主観から事実を作り上げていく必要があるから

心構え

• ハイペースを心がける
• 要件定義での失敗は後に響く
• 顧客に期待しない
  • 「すべきだ」「当然だ」はやめること
  • 精神衛生上良くない
  • 要求は曖昧であるもの
  • あまりにも困った顧客の場合は見切りをつけること
  • 良い顧客を大切にすること
• イメージを構築する
• 知識は詰め込めるだけ詰め込むこと
• わかってること、わかってないことを意識すること
• 曖昧さを無理に排除しないこと
• 知的労働で急かしても生産性は向上しない
  • 無理な残業をしない
  • 残業は生産性の低下を招く、すればするほど低下する
  • プレッシャーを与えると最初だけ生産性は向上する
  • 問題の発生しゃ開発側の責任と認識すること
  • もしものための備えを感気ておくこと
  • 契約によってリスク管理を行うことを意識すること
  • 契約は自社をまおる最後の防波堤
  • 要件定義を準委任契約とし、それ以降を請負契約とすること。またはそのための方針を検討すること
    • 要求をあらいだしてから開発を開始する
  • 追加の変更要求が発生した倍は、費用と納期の再見積もりを可能とするような契約を結ぶこと
  • 仕様の追加と変更の判定基準を明確にすること

問題へのアプローチ

細分化

検討漏れを減らす効果がある。

いつの間にか膨張する仕様

問題

• 要求を最大限受け入れる文化である。
• 顧客からの要求はルールを破っていても受け入れる文化
• マネージャーが顧客第一。
• 開発メンバーが善意から勝手に機能を追加している。
• 開発メンバが技術的興味から勝手に機能を追加している。

対策

• プロジェクトの目的と優先順位を明確にする
• 顧客優先の思考がプロジェクトに有益であるか判断する
  • 開発側に問題意識がない
    • 担当者を交代する

問題

• ちょっとした追加であれば影響はないと思う。
• 追加によってプロジェクトに影響があると考えていない
• あれば良い機能、あれば便利な機能でもなんでも要求しなければ損だと考えている。

解決

• リソースに変化がない以上、一つの要求にさけるリソースがすくなくなることを説明する
• リソース不足のため、プロジェクトのリスクが高まることを説明する。
• あればよい機能は削除か別の開発に回すことを提案する

現行でも明確なルールがない業務をシステムかしようとしている
原稿の業務のルールを細部まで洗い出せていない
システム化が難しい業務を対象にしている。
・ルールを明らかにする
・無理をせずに諦めるか延期を提案する
・コンピュータは臨機応変な作業がにがて

システムのあるべき姿が明確に固まっていない
開発したいシステムが事前に仕様を決めにくいもの
・膨張しやすいものなので顧客に理解していただく
・期間を厳格に区切る。

どの要求を優先するか決める
どのステークホルダーを優先するか決める

要求を精査する仕組みがない
削除する仕組みがない
要求の出所が一元化されていない

銀の弾丸を求めないこと。
全てを優先することはできない。

無駄なドキュメントを悪性しないこと

• 最初から完璧な設計書を書くことは無駄に繋がる。
• 後で作成はあとであればあとであるほどよい。実装後が理想
  • 個人的には微妙
  • 認識整合のためのドキュメントはメモ書き程度で良い
• 最終成果物に直接貢献しない中間成果物を作成しないこと

基本的に認識が甘かったり、責任などが曖昧になっていることが共有の問題に見える

• 決めたことがシステムになること
• 仕様を変更したり、追加すると時間がかかったり他への影響がある。
• システムを作るめんどくささ