自己紹介
TANAKA SYUHEI
IT業界10年目のシステムエンジニアです。
IT系中堅企業→大手企業→大手企業と転職を繰り返し、現在はフリーランスのシステムエンジニアとして活動中です。
システムエンジニア未経験者の講師もしています。
自分がIT業界に未経験で入った時、こんなことを知っていたら良かったな的な情報を掲載します。
これからエンジニアやフリーランスを目指す人に役立てば幸いです。
みなさんへメッセージ
大手企業や中小企業で要件定義をしてきた経験者として、これまでの失敗経験を踏まえ、改善提案（アドバイスや考え方）を掲載します。
これから要件定義を始める人。
既に要件定義をしている人。
このようなエンジニアに役立てば幸いです。
目次
なぜ、課題一覧をつくるのか？
check
要件定義漏れを防ぐためです。
要件定義では、発注側と受注側の認識漏れで、しれっと機能が実装されることがあります。
要件定義→設計→実装→テストと進み、テスト時になって気付くケースもあります。
その場合、しれっと実装された機能について双方で打ち合わせしたり、修正したり、再テストしたり、余分な工数がかさみます。
システム開発のスケジュールを圧迫することもあります。
このようなことを防ぐために課題一覧は必要です。
課題一覧に何を書くのか？
check
要件定義の疑問点を書きます。
発注側と受注側で、システムの仕様について質問を書きます。
課題一覧は、
・いつまでに
・誰が
・何を決めるか
・確認結果はどうだったか
があれば充分です。
どうやって、課題一覧を使うのか？
check
課題一覧は、いつまでに誰が何を決めないといけないか、を把握して使います。
要件定義は、システム開発のスケジュールに沿って進みます。
いつまでに誰が何を決めるか、が大きなポイントです。
課題一覧を使って、一つ一つの課題を解決していきましょう。
最後に
今回、要件定義に関する現場レベルの情報を掲載しました。
「良かったな」と思う点があれば、みなさんの現場でも活用してください。
それでは、また別の記事でお会いしましょう。