こんにちは。ネオシステムの高橋です。
今回は、ウォーターフォール開発において必要なメンバーの役割をまとめました。
その中でも、特に要件定義フェーズで誰が何をすべきかまとめています。
皆さんが参画しているプロジェクトのチームメンバーに不足がないか、確認してみてください。
目次
- プロジェクトチームの階層
- 各役割の説明
- プロジェクトオーナーの役割
- プロジェクトマネージャー(PM)の役割
- 業務部門の役割
- 開発部門の役割
- ベンダーの役割
プロジェクトチームの階層
基本的な役割は以下の7つです。
シンプルなピラミッド型の絵を描きましたが中にはこんなプロジェクトもありました。
- 業務部門と開発部門それぞれにPMがいるケース
- ベンダーにもPMがいるケース
- 運用業務もベンダーが行うケース
- プロジェクトオーナーとPMの間にプロジェクト推進者がいるケース
各役割の説明
ここからは要件定義をする際の各役割について詳しく見ていきます。
プロジェクトオーナーの役割
まずはプロジェクトオーナーの役割から見ていきましょう。
プロジェクトオーナーは冒頭のピラミッドでいうところの最上位の役割です。
ビジネス構想・システム構想をプロジェクトに浸透させる
積極的に要件定義プロジェクトに参画し、ビジネス構想・システム構想を伝達しともに考えましょう。また、業務変革の権限を業務部門に委譲するなどビジネス改革の強い意志を明確に示しましょう。
現場の基本的思考は業務のムダ・ムラ・ムリの改善であり、大きな変化を嫌う保守的な傾向を示すこともあるため、意見の衝突を防ぐためにも想いをプロジェクト全体に伝える必要があります。
本当に必要な人をアサインする
要件定義では、人員を増やしても必ずしも進捗に影響を与えるとは限りません。人員ではなく、その人に十分な期間を与えることが成功のポイントになります。
既存システムの現状を認識する
システムをリビルドする（作り直す）には、既存業務やシステムの知識が必要です。
具体的に「現行機能」を定義できないのであれば、要件定義は終了できないことになります。
プロジェクトマネージャー(PM)の役割
次にPMの役割を見ていきます。
PMはピラミッドでいうと中間の層にあたります。
プロジェクトオーナーからの要求とエンドユーザーからの要求をコントロールする
プロジェクトオーナーが掲げるビジネス構想・システム構想をともに考え、業務部門と開発部門を軌道に乗せてあげましょう。
①「計画立案と実行」②「監視・コントロール」③「評価、完了判断」の責任を担う
例えば
- 「膨らむ要求をいかにコントロールするか」
- 「要件定義の品質をどう担保するか」
- 「要件定義の完了をどう判断するか」 etc.
※PMの役割の詳細はこちらの記事を参照してください
PMに必要なスキル
PMはその名の通りプロジェクト全体を管理する人ですので、以下のスキルが求められます。
マネジメントスキル
いかに少ないコスト、限られた納期で品質の高いものを提供できるか？（もしくは質の悪いものにならないための対策を練られるか？）
- システムに不具合が発生しない
- 現場から苦情が少ない
- 機能変更に柔軟に対応できる
テクニカルスキルと問題分析・解決スキル
現場の専門的知識とITの専門的知識を組み合わせて、問題解決やビジネス改革を提案することができるか？
- 現場からの要求から根本的な問題を発見できる
- 開発に使われている技術を理解している
- チームメンバーの負担を軽減できるようにサポートしている
コミュニケーションスキル
円滑な情報共有ができ、リーダーシップを発揮できるか？
- 質の高い(開催する意義がある)会議が開かれている
- チームメンバーのモチベーションが高い
- チームメンバーから信頼がある
PMを目指している方は参考にしてみてください。
業務部門の役割
次は業務部門です。業務部門はプロジェクトメンバーの中で、エンドユーザに一番近い部門を指しています。
経営・業務に貢献する
システム投資の目的は、システムの開発が完了したかではなく、経営や業務にどれだけ貢献するかです。これは実際にシステムを開発する人の問題ではなく、業務部門の問題となります。
ビジネスプロセス改革・改善
ビジネスや業務のプロセスが変わらないのに、システムだけ最新のものに置き換えることには意義がないと言えます。具体的なビジネスプロセス全体を作り上げなければなりません。
リーダー(課題担当者リーダー)の用意
要求仕様の提示責任者、システムの検証責任者を用意する必要があります。
システムは業務の一部であり、どのようなシステムを作成するか、そしてそのシステムからどのような効果を引き出すかはリーダーの責任です。
当然、すべての要件定義がシステムでできるわけではないが、システム開発をシステム部門だけの仕事にせず、リーダーが自分のこととして捉える「態勢」を作ることが大切です。
現行システムの理解と課題発見
現行システムの実態を正しく理解し、要件定義に反映しているかを意識しなければなりません。
システム開発時点で想定していなかった使い方をされている場合や、使われていない機能もでてきます。こういったことが起きると、利用者からみてシステムやベンダ企業に対する満足度が低くなってしまいます。
システム開発の前段階で、開発の目的を整理、分析する期間を設けることが望ましいでしょう。
- 「次期システムには何を期待するのか」
- 「今のシステムで使用されていない機能はないか」
- 「数年前の開発時と異なり現在の環境にふさわしくない機能はないか」
現地のヒアリングと合意形成
「もっと効率的な、もっと利用者に喜んでもらえる機能や仕組みがないか」を、関係者にヒアリングすることも重要です。
現場の方針、意見、課題などについて漏れなく綿密に把握し、できることとできないことを取りまとめて合意形成にもっていく責任があると言えます。
現場ではなく、企業全体の利益を考え合意形成に望みましょう。
開発部門の役割
次は開発部門です。開発部門は実際にシステムを製造する部隊であるため、技術的なスキルが求められます。
既存システムの状況の明確化
既存システムが肥大化し複雑になったとき、システムの再構築を起案する必要があります。
パラダイムシフト
ビジネス視点で情報化やシステム活用を考え推進していきましょう。
エンドユーザーの業務を理解し、業務に対して価値あるシステムを提案していくことも重要ですが、エンドユーザーの業務の要求を鵜呑みにして言われたとおりのシステムを作るだけでは経営や業務に貢献するシステムとは呼べない場合もあります。
ベンダー企業の選定
現実問題として要件定義にITベンダの協力は欠かせず、そのベンダを適切に選定する責任があります。
ユーザ企業は、本当に自企業の課題解決や要件定義に協力してくれる価値あるベンダ企業を選ぶための明確な基準を設定しておく必要があります。
ベンダーの役割
最後はベンダーの役割です。ベンダーもプロジェクトの一員としてやるべきことがあります。
ユーザ企業課題解決貢献
お客様のビジネス課題をお客様と一緒に考え、ソリューション、ビジネス価値を提供する企業へと変化する必要があります。
そのためには要件定義に入り、IT技術活用を提案していく姿が理想です。
要求仕様の凍結
要件定義の完了時点で要求仕様が凍結できるようにユーザ企業、ベンダー企業ともに努力することが重要です。
決まらない要求仕様を統制するためにはスコープの広がりや要求量、変更量を把握し、ベースラインを定めて適切な要求量、変更量の管理を実施しましょう。
まとめ
今回は要件定義における各メンバーの役割について整理しました。
自分は役割を果たせているのか、要件定義がうまくいかない原因はどこにあるのか、などなどお役に立てれば幸いです。
次の記事は、要件定義におけるプロジェクトマネージャーの役割について詳しく載せたいと思いますので併せて読んでみてください。