仕事の流れ3：要件定義
前回に引き続き、仕事の流れ解説シリーズの第3回です。第3回は、「要件定義」フェーズについてです。
第1回、第2回はこちら。
仕事の流れ解説シリーズとしては、今回で最終回となります。自身の仕事がたった3回にまとまってしまうことに少し驚きを感じましたが、まあ要約するとそんなものなのでしょう(^_^;)
それでは、解説していきます。
目次
要件定義とは
「要件定義」は、IT業界でよく使われる言葉です。
私は前職がハードウェア設計者であったため、業務コンサルタントになって初めて聞く言葉でした。意味はそのままで、「要件」を「定義」することです。
「要件」とは、辞書によると、
- 大切な用事
- 必要な条件
などの意味があります。
業務コンサルタントが使う「要件」とは、2つ目の「必要な条件」の意味です。このフェーズで言う「必要な条件」とは何なのかと言うと、1つは、業務に必要な条件、もう1つは、システムに必要な条件、です。業務コンサルタントとして「定義」するのは、1つ目の「業務に必要な条件」です。
では、「業務に必要な条件」とは何か。前フェーズの「業務モデリング」で決めた解決策を、「〇〇という業務ができること」という表現に直したものです。言い換えると、「その業務が成立するために必要な条件」です。
このフェーズでは、定義した業務フローの1つ1つに対し、その業務が成立するために必要な条件を定義し、お客様と合意していきます。既に、課題、解決策、実行計画が前フェーズまでで立案されているので、「要件定義」の難易度は、それまでに比べると高くありません。ですので、経験の浅い若手コンサルタントが、まず最初に放り込まれるフェーズであることも多いです。システム構築での手戻りを減らすために、このフェーズでシステムエンジニア（通称SE）もプロジェクト体制に入って、検証を同時に行いながら進めていくこともあります。
以上から、要件定義では、業務コンサルタントとして求められる役割が前フェーズまでとは異なり、「プロジェクト管理」が中心となります。
「プロジェクト管理」については、次章で詳しく解説しますが、プロジェクトの目的達成に向けて、スコープ定義や課題管理、スケジュールの進捗管理などを行います。
ちなみにですが、上述した「システムに必要な条件」をプロジェクトの中心となって定義していくのが、ITコンサルタントであり、SEです。場合によっては、業務コンサルタントでも、システム要件まで定義支援する場合があります。
PMO支援が多い
前述したように、このフェーズでの業務コンサルタントの役割としては、プロジェクト管理がメインになります。
このプロジェクト管理を専門に担う役割を、
PMO＝Project Management Office
と言います。
PMOで必要な考え方、知識は、PMBOK＝Project Management Body Of Knowledgeとして体系化されています。プロセスを管理することで、プロジェクトを成功に導くという考え方です。
この中では、以下のような管理領域が定義されています。
関連する資格として、PMPという国際資格もあります。各管理内容詳細については、ここではご説明しませんので、気になる方は「PMBOK」「PMP」でググってみて下さい。
教科書的な解説はこのくらいにして、業務コンサルタントがこの知識をどう使っているのかについて紹介します。
この知識を使ってプロジェクトを管理する役割がPMOであり、業務コンサルタントは、要件定義フェーズでこの役割を担う、もしくはその支援を行うことが多いです。PMBOKの領域を見ても分かりますが、やっていることは、いわゆるプロジェクトマネージャーの仕事と同じです。特に、ステークホルダーが多く、リスクも高い大規模プロジェクトで、PMOが導入されることが多いです。
そこでは、上記のPMBOKの知識体系に基づき、プロジェクトルールを作成し、メンバーと共有することで、スムーズなプロジェクトの遂行を行います。
プロジェクトルールでは、このプロジェクトの対象業務、あるいはシステムはどの範囲までなのか（スコープ管理）、どういう計画で進んでいくのか、また進捗はどのように測定するのか（スケジュール管理）、どのような体制で、誰から誰に、どんな会議体でどんな情報を伝達するのか（コミュニケーション管理）、などを規定します。
これらは普通にやっていると、きちんとルール化されることは少なく、これまでの経験に基づき、何となく進捗管理をして、何となく決めた定例会議を行っていたりします。
ただその方法だと、今どんな状況で、どんな課題やリスクがあるかや、いつどんな目的でどんな会議をやっているのかなどが共有できず、様々なステークホルダーから疑問、質問が挙がってくるため、非常に非効率な進め方になってしまいます。また、課題やリスクも見過ごされてしまい、プロジェクトの失敗に繋がりやすくなります。
このようなことを防ぐため、PMBOKによって体系化した知識と成功実績を持つ業務コンサルタントにPMO支援の依頼が来るわけです。
システム要件まで考えられるコンサルタントは希少
PMO支援が多いのですが、適任者がいないということで、要件定義の中でもIT寄りの検討に参画することもあります。
普通、業務コンサルタントといえば、業務要件定義まで支援し、システム要件定義以降はSEが主体になって進めていきます。逆に言うと、システム要件まで考えられる業務コンサルタントは、とても貴重な存在になります。なぜなら、システム要件を考えられるということは、その業務を実現できるかの検証を行えているということだからです。構想企画で描いた改革後の業務イメージを、実際にシステムで実現するとするとどうなるかを考えるからです。
要は、最初に考えた改革のコンセプトは「絵に描いた餅」ではなく、きちんと「現実的に業務をどう変えていくか」まで落とし込んでいける、ということです。
ではなぜ、ここまで出来るコンサルタントは貴重なのでしょうか。それは、必要な知識が広範、専門的で、なおかつ実践的だからです。知っているだけではダメですし、経験しているだけでもダメ、両方が必要になります。なかなかハードルが高いですが、そんな知識と経験を身に付けると、逆にそれがコンサルタントとしての優位性になります。
まとめ
最後にまとめます。
- 要件定義とは、新業務に変えるために、
業務やシステムに必要な条件を定義すること
- システム要件定義まで支援することができれば、
とても貴重な存在になる
あと、蛇足ですが、仕事の流れを紹介してしまって、僕の仕事が無くならないのかと思う方もいらっしゃるかも知れませんが、その心配はありません。なぜなら、重要なのは、仕事のプロセスではないからです。
ここまで解説しておいて、何を言い出すのかと思われるかも知れません。 実際は、業務コンサルタントとしては、専門的な業務知識や実務経験が何よりも強みになり、それは簡単に他の人が真似できるものではないのです。仕事のプロセスだけ真似しても、決してうまくいかないということです。もちろん、コンサルタントとしての基礎的なスキルも必要ですし。
とは言え、将来コンサルタントになりたい方や、業務コンサルタントに仕事をお願いしようと考えておられる方に参考となる情報なのではと考え、解説してみました。
それでは、今回はここまでです。これで、全3回に渡った仕事の流れ解説シリーズを終わります。
次回は、皆さんが最も興味があるであろう、コンサルタントで必要なスキルについて解説したいと思います。論理的思考や、仮説思考、ファシリテーション、ドキュメンテーションなどですね。
ビジネスに携わられている方はもちろん、プライベートでも役立つスキルだと実感しているので、参考にしていただければと思います。
では、また次回。
